Date   

Re: u-boot policy for CIP

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 16/03/17 12:07, Chris Paterson wrote:
Hello all,

I’m bringing a discussion I’ve started in other places here as it will
benefit from wider participation.

As you know the aim of CIP is to maintain not just the Kernel, but a
number of other ‘core packages’. One of these is u-boot.

For the Kernel the project will provide super long term support for a
chosen version. For u-boot this will be harder to achieve as

a)there are no ‘LTS’ versions of u-boot to base our ‘SLTS’ version on;

b)a lot of hardware providers tend to use forks for their platforms,
rather than add full functionality upstream.

Ideally CIP should choose a version of u-boot and use it when
testing/verifying the CIP Kernel on the reference hardware. How we
actively maintain that version (bug fixes/security patches/features?) is
another question. Given that most devices in the field won’t have a way
to update u-boot in the field (security issues/practicalities), I think
‘SLTS’ support for u-boot may not be required. Perhaps we just tag a
version of u-boot at the launch of a new CIP Kernel and stick with it?

How do we decide what u-boot version to support? Currently it looks like
the BBB platform are shipped with 2014.04 and the Renesas platform is
shipped with 2013.01. That said, it looks like there is upstream support
for BBB [1], but how the feature set compares to the version shipped
with the platform I don’t know. There is also support for some Renesas
platforms [2], but not for the exact board CIP will be using.

Do we want to push Ti/Renesas to ensure there is full support for their
boards upstream? When this is done do we pick the first version that
includes this support to work with? Or do we just stick with the vendor
provided forks?

Is there a particular feature set that CIP requires?

Forgive my random ramblings, I appreciate there are a lot of different
questions here!
Slightly related to this topic, Ben H. gave a talk/Q&A about hardware support in Debian Stable back in DebConf13

Link: https://www.youtube.com/watch?v=oLTs1ikQR5E


[1] https://github.com/u-boot/u-boot/tree/master/board/ti/am335x

[2] https://github.com/u-boot/u-boot/tree/master/board/renesas

Kind regards, Chris



_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: Kernel feature support

Hidehiro Kawai
 

Hello Agustin and Ben,

From: cip-dev-bounces@lists.cip-project.org [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Agustin Benito
On 09/03/17 15:33, Ben Hutchings wrote:
We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?
Answering this question is important to discard features in 4.4 that are
not of CIP interest so we can severely reduce the amount of effort that
we will need to do in terms of fixes analysis, security etc. in the future.

Please take some time to provide feedback.
I attached a defconfig for one of our products running on 4.4.12.
This config is based on omap2plus_defconfig, and a diff from
omap2plus_defconfig is also attached.

Currently, each config item has not been prioritized yet, and it
may contain non-important items. Please treat our defconfig
as a reference at this point.

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group


Re: Kernel feature support

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2017-03-23 at 16:32 +0000, Chris Paterson wrote:
[...]
From an SoC vendor point of view, ideally we'd like the interfaces
provided by the reference platform to be included. As support for our
CIP reference platform is not yet mainlined, I can't provide the
exact .config yet. However it will likely be very similar to
shmobile_defconfig [1].
[...]

Thanks, I'll look through this config.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: Kernel feature support

Ben Hutchings <ben.hutchings@...>
 

On Fri, 2017-03-24 at 03:39 +0000, 河合英宏 / KAWAI,HIDEHIRO wrote:
[...]
I attached a defconfig for one of our products running on 4.4.12.
This config is based on omap2plus_defconfig, and a diff from
omap2plus_defconfig is also attached.

Currently, each config item has not been prioritized yet, and it
may contain non-important items. Please treat our defconfig
as a reference at this point.
Thanks, this is useful.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: u-boot policy for CIP

Mauerer, Wolfgang
 

Hi Chris,

On 16.03.2017 13:07, Chris Paterson wrote:
Hello all,



I’m bringing a discussion I’ve started in other places here as it will
benefit from wider participation.



As you know the aim of CIP is to maintain not just the Kernel, but a
number of other ‘core packages’. One of these is u-boot.



For the Kernel the project will provide super long term support for a
chosen version. For u-boot this will be harder to achieve as

a) there are no ‘LTS’ versions of u-boot to base our ‘SLTS’ version on;

b) a lot of hardware providers tend to use forks for their
platforms, rather than add full functionality upstream.
thanks for raising this question. The problem you describe does not just
exist for U-Boot, but also for many other components that we will be
looking into.



Ideally CIP should choose a version of u-boot and use it when
testing/verifying the CIP Kernel on the reference hardware. How we
actively maintain that version (bug fixes/security patches/features?) is
another question. Given that most devices in the field won’t have a way
to update u-boot in the field (security issues/practicalities), I think
‘SLTS’ support for u-boot may not be required. Perhaps we just tag a
version of u-boot at the launch of a new CIP Kernel and stick with it?
I also assume that updating the bootloader is currently not required
for many appliances, so it suffices to ensure it is labelled properly
and can be (slt) re-produced for these cases.

However, things change when networking features of U-Boot come
into play. These are usually used during product development, but
I imagine that certain (IoT-class) devices will use such features more
in the future. For these cases, it would be desirable to have something
like a CIP standardised update process for the boot loader besides
a SLTS version. Do member companies plan to employ these features
for other than development/debugging purposes in the future?

If the boot loader is part of a secure/trusted boot scenario, the
ability to update U-Boot will also become more important, but that
depends on the threat models.

To me, it seems important to collect information from the members
on U-Boot use-cases, and then decide if and what further action is
necessary. For Siemens at least, I would not be able to come up with a
definitive set of requirements without asking around in the company.




How do we decide what u-boot version to support? Currently it looks like
the BBB platform are shipped with 2014.04 and the Renesas platform is
shipped with 2013.01. That said, it looks like there is upstream support
for BBB [1], but how the feature set compares to the version shipped
with the platform I don’t know. There is also support for some Renesas
platforms [2], but not for the exact board CIP will be using.



Do we want to push Ti/Renesas to ensure there is full support for their
boards upstream? When this is done do we pick the first version that
includes this support to work with? Or do we just stick with the vendor
provided forks?
Having upstream support for the HW components is a critical precondition
for me. CIP has committed to working with the upstream projects as
closely as possible, and maintaining code outside is usually a good
recipe for disaster... Unless there's a really compelling reason
for sticking with a vendor fork, which I cannot think of any in our
context, we should always start from the upstream projects.
Or, in other words: Companies should usually be pushed to bring their
changes upstream, I'm not aware of any case where this has created more
problems than it has solved issues.



Is there a particular feature set that CIP requires?
that is something we would have to define. I again guess it makes sense
to collect configurations from products of the member companies, as the
in-company variability will already likely be substantial.

Best regards, Wolfgang




Forgive my random ramblings, I appreciate there are a lot of different
questions here!





[1] https://github.com/u-boot/u-boot/tree/master/board/ti/am335x

[2] https://github.com/u-boot/u-boot/tree/master/board/renesas



Kind regards, Chris



_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: u-boot policy for CIP

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2017-03-16 at 12:07 +0000, Chris Paterson wrote:

I’m bringing a discussion I’ve started in other places here as it will
benefit from wider participation.
Thank you. I have limited knowledge of u-boot, but I did work on it
recently to add support for a new board.

[...]
Ideally CIP should choose a version of u-boot and use it when
testing/verifying the CIP Kernel on the reference hardware.
We should certainly pick one version for each reference board.

How we actively maintain that version (bug fixes/security
patches/features?) is another question. Given that most devices in the
field won’t have a way to update u-boot in the field (security
issues/practicalities), I think ‘SLTS’ support for u-boot may not be
required. Perhaps we just tag a version of u-boot at the launch of a
new CIP Kernel and stick with it?
If u-boot is configured to use network boot, or to require
authentication of its environment or boot images, or authentication to
interrupt boot (CONFIG_AUTOBOOT_KEYED=y), then it is sometimes handling
untrusted input and might need security updates. Otherwise it probably
does not.

It seems possible that some fixes might be needed to improve
reliability, e.g. if boot timing changes as hardware gets older.

How do we decide what u-boot version to support? Currently it looks
like the BBB platform are shipped with 2014.04
I have a new BBB that came with 2015.10 installed. So we cannot be
certain that a particular model of board will always be shipped with the
same version!

and the Renesas platform is shipped with 2013.01. That said, it looks
like there is upstream support for BBB [1], but how the feature set
compares to the version shipped with the platform I don’t know. There
is also support for some Renesas platforms [2], but not for the exact
board CIP will be using.

Do we want to push Ti/Renesas to ensure there is full support for
their boards upstream? When this is done do we pick the first version
that includes this support to work with? Or do we just stick with the
vendor provided forks?
I don't have an opinion on whether CIP should provide support for
u-boot, beyond the testing it will get through booting each kernel to be
tested. If we do, I would prefer not to include vendor forks as this
could greatly increase the maintenance effort.

Is there a particular feature set that CIP requires?
[...]

For testing purposes we will need at least an unauthenticated command
prompt (CONFIG_AUTOBOOT_KEYED=n), networking and TFTP support. That
probably isn't a complete list.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: Kernel feature support

Gernot Hillier <gernot.hillier@...>
 

On 15.03.2017 17:18, Agustin Benito Bethencourt wrote:
Hi,

On 09/03/17 15:33, Ben Hutchings wrote:
We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?
Answering this question is important to discard features in 4.4 that are
not of CIP interest so we can severely reduce the amount of effort that
we will need to do in terms of fixes analysis, security etc. in the future.

Please take some time to provide feedback.
Sorry for the late reply!

Please find attached an x86 kernel configuration from early product
development using kernel 4.4.

This product uses nearly-COTS server hardware due to needed computation
power, but also comes with nice embedded requirements like longterm
maintenance - and as a special need, real-time support, so we use
Linux-Ipipe/Xenomai here.

This means two things:
* many included drivers (especially in net and storage) are only
activated "to be prepared" for future hw replacements
* Feel free to either include Xenomai on your list as a used "kernel
feature" or to ignore the related options.

So same as with the config from Hidehiro Kawai: please let me know if
you need prioritized list of drivers or other features!

--
Kind regards,
Gernot Hillier

Siemens AG, Corporate Competence Center Embedded Linux


Re: Kernel feature support

Jan Kiszka
 

On 2017-03-27 12:31, Gernot Hillier wrote:
On 15.03.2017 17:18, Agustin Benito Bethencourt wrote:
Hi,

On 09/03/17 15:33, Ben Hutchings wrote:
We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled? Or would you prefer to specify your needs at a
slightly higher level?
Answering this question is important to discard features in 4.4 that are
not of CIP interest so we can severely reduce the amount of effort that
we will need to do in terms of fixes analysis, security etc. in the future.

Please take some time to provide feedback.
Sorry for the late reply!
Fell through my cracks as well, just sending out another internal call
for more product configs. One is attached already, derived from
github.com/siemens/meta-iot2000.


Please find attached an x86 kernel configuration from early product
development using kernel 4.4.

This product uses nearly-COTS server hardware due to needed computation
power, but also comes with nice embedded requirements like longterm
maintenance - and as a special need, real-time support, so we use
Linux-Ipipe/Xenomai here.

This means two things:
* many included drivers (especially in net and storage) are only
activated "to be prepared" for future hw replacements
* Feel free to either include Xenomai on your list as a used "kernel
feature" or to ignore the related options.
Xenomai is not in CIP scope right now (though Siemens would welcome
anyone interested in collaborating on it).

In general, anything in a config not part of upstream is filtered out
"automatically", I would say. There are switches for out-of-tree
features in the iot2000 config as well (we are still in the process of
upstreaming).


So same as with the config from Hidehiro Kawai: please let me know if
you need prioritized list of drivers or other features!
Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux


Update 2017 wk12

Robert Marshall <robert.marshall@...>
 

Dear CIP friends,

here is the report of those tasks related with Testing and kernel
maintenance that we have been working on the past two weeks:

The whole team has been in Manchester for a week and has taken advantage
of that to have various face2face meetings.

CIP Testing

The following issues are being actively worked on:
* Issue #18 Exported vagrant box for an already loaded instance of CIP -
the size of this instance has been reduced and a script is being
prepared for the initial setup. (Issue #50)
* Issue #43 Refining test so that it uses the kernelci locally built kernel
* Issue #37 prepared checklist for release
* Issue #28 is still being investigated - to either document the
requirement or alter the test script so if necessary it performs a
'manual' login.


* Awaiting edit rights for Robert on the CIP public wiki

* Closed various solved issues
** #16 - Beaglebone black health check failing
** #22 - support arm64 build
** #33 - the VM requiring a weird mixture of debian versions
** #49 - deleted the VagrantFile sets up a USB passthru which is never used
** #47 - document the possible timeouts on the QEMU test


CIP kernel maintenance

* Ben has the VM working under Debian stable

Remember you can:
* Download the beta version of Board at Desk - Single dev VM at the
CIP testing Download page:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipdownload
* All issues/tickets referred in this report can be found in our
gitlab.com testing project:
https://gitlab.com/cip-project/testing/boards

Codethink has published a blog post related with CIP:
https://www.codethink.co.uk/blog/articles/2017/why-codethink-founding-member-civil-infrastructure-platform/

Best Regards

Robert


Re: Update 2017 wk12

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,


Codethink has published a blog post related with CIP:
https://www.codethink.co.uk/blog/articles/2017/why-codethink-founding-member-civil-infrastructure-platform/
it has now been published in the CIP site: https://www.cip-project.org/blog/2017/03/27/member-blog-why-codethink-is-a-founding-member-of-the-civil-infrastructure-platform-a-linux-foundation-initiative


Best Regards

Robert
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: Kernel feature support

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Ben,

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Ben Hutchings
Sent: Thursday, March 09, 2017 11:34 PM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] Kernel feature support

We've previously agreed that not all kernel features (drivers,
filesystems, network protocols, etc.) can be supported in an SLTS
branch. I'd like to start working out what the supported features
should be for the 4.4 branch.

Are members able to share their kernel .config files, showing which
features are enabled?
Please find attached to this e-mail four kernel v4.4 configurations for different architectures and platforms. Some of these kernels contain vendor patches and the PREEMPT RT patch. Also, please note that they were created with 'make ARCH=xxx savedefconfig'.

Or would you prefer to specify your needs at a
slightly higher level?
I prepared a list of kernel config options that I consider the most important among the configs we are using. You can find them in the file config-cip (included in the attached zip file) which is reproduced below:

General setup
CONFIG_POSIX_MQUEUE
CONFIG_HZ_PERIODIC
CONFIG_HIGH_RES_TIMERS
CONFIG_IKCONFIG
CONFIG_IKCONFIG_PROC
CONFIG_CGROUPS
CONFIG_CPUSETS
CONFIG_NAMESPACES
CONFIG_SCHED_AUTOGROUP
CONFIG_BLK_DEV_INITRD
CONFIG_RD_GZIP
CONFIG_SHMEM
CONFIG_SYSCTL_SYSCALL
CONFIG_KPROBES

Processor type and features
CONFIG_SMP
CONFIG_EFI
CONFIG_HOTPLUG_CPU
CONFIG_CRASH_DUMP

System type
CONFIG_ARCH_TEGRA
CONFIG_ARCH_ZYNQ

Filesystems
CONFIG_EXT4_FS
CONFIG_INOTIFY_USER
CONFIG_OVERLAY_FS
CONFIG_VFAT_FS
CONFIG_PROC_FS
CONFIG_SYSFS
CONFIG_TMPFS
CONFIG_SQUASHFS
CONFIG_JFFS2_FS

Networking support
CONFIG_INET
CONFIG_VLAN_8021Q
CONFIG_IPV6

Device drivers
CONFIG_UIO
CONFIG_UIO_PDRV_GENIRQ
CONFIG_USB_EHCI_HCD
CONFIG_USB_XHCI_HCD
CONFIG_USB_STORAGE
CONFIG_USB_HID
CONFIG_USB_NET_DRIVERS
CONFIG_FB
CONFIG_TUN
CONFIG_DEVTMPFS
CONFIG_DEVTMPFS_MOUNT
CONFIG_GPIOLIB
CONFIG_GPIO_SYSFS
CONFIG_GPIOLIB_IRQCHIP
CONFIG_BLK_DEV_RAM
CONFIG_MTD
CONFIG_MTD_BLOCK
CONFIG_MTD_NAND
CONFIG_I2C
CONFIG_SPI
CONFIG_MMC
CONFIG_MMC_SDHCI
CONFIG_INPUT_EVDEV
CONFIG_PPS
CONFIG_E1000E
CONFIG_I40E
CONFIG_IGB

Kernel hacking
CONFIG_FTRACE
CONFIG_FUNCTION_TRACER
CONFIG_PRINTK_TIME
CONFIG_PANIC_ON_OOPS

Some of these kernel config options may be out of scope or too broad. I just provide them for reference.
We may send you more information in the future.

Best regards,
Daniel

--
IoT Technology center
Toshiba Corp. Industrial ICT solutions,
Daniel SANGORRIN


Twitter account

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

maybe we can start the support of our promo efforts with a Twitter account. I would also think about a hashtag

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Minutes of the bi-weekly meeting published 20th March 2017

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

check the minutes: https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_mar202017

Best regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: Twitter account

Noriaki Fukuyasu <fukuyasu@...>
 

Hi Agustin

I think this is a great idea.
The challenge is how to manage the posts (who, what and how often etc).
Anyway, let me think over this.

regards

Nori


On Wed, Mar 29, 2017 at 10:53 PM, Agustin Benito Bethencourt <agustin.benito@...> wrote:
Hi,

maybe we can start the support of our promo efforts with a Twitter account. I would also think about a hashtag

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev



--
Noriaki Fukuyasu

The Linux Foundation
Tel: +81-80-4350-1133
Twitter: nori_fukuyasu
Facebook: linuxfoundationjp

Please visit our web sites:


Re: Twitter account

Mauerer, Wolfgang
 

Hi all,

On 30.03.2017 15:33, Noriaki Fukuyasu wrote:
Hi Agustin

I think this is a great idea.
The challenge is how to manage the posts (who, what and how often etc).
Anyway, let me think over this.
marketing and creating public awareness of our endeavour is
of course good -- keeping up regular activity is going to be the
hard thing. But if we publish

* new software releases (board at desk, kernel)
* member presentations at conferences

we should at least have some base activity. I'm wondering, though,
what we intend to achieve with the account? (except that everybody
needs to have a Twitter account these days, as it seems :))

Thanks, Wolfgang

regards

Nori


On Wed, Mar 29, 2017 at 10:53 PM, Agustin Benito Bethencourt
<agustin.benito@codethink.co.uk <mailto:agustin.benito@codethink.co.uk>>
wrote:

Hi,

maybe we can start the support of our promo efforts with a Twitter
account. I would also think about a hashtag

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk <mailto:agustin.benito@codethink.co.uk>
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org <mailto:cip-dev@lists.cip-project.org>
https://lists.cip-project.org/mailman/listinfo/cip-dev
<https://lists.cip-project.org/mailman/listinfo/cip-dev>




--
Noriaki Fukuyasu

The Linux Foundation
Mail: fukuyasu@linuxfoundation.org <mailto:fukuyasu@linuxfoundation.org>
Tel: +81-80-4350-1133
Twitter: nori_fukuyasu
Facebook: linuxfoundationjp

Please visit our web sites:
http://www.linuxfoundation.jp
http://events.linuxfoundation.jp
http://jp.linux.com



_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Twitter account

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 31/03/17 11:26, Wolfgang Mauerer wrote:
Hi all,

On 30.03.2017 15:33, Noriaki Fukuyasu wrote:
Hi Agustin

I think this is a great idea.
The challenge is how to manage the posts (who, what and how often etc).
Anyway, let me think over this.
marketing and creating public awareness of our endeavour is
of course good -- keeping up regular activity is going to be the
hard thing. But if we publish

* new software releases (board at desk, kernel)
* member presentations at conferences
The above will allow us to have one tweet per month which is not a bad start. I prefer less tweets but relevant than a lot of noise.


we should at least have some base activity. I'm wondering, though,
what we intend to achieve with the account? (except that everybody
needs to have a Twitter account these days, as it seems :))
This is always a good question.

We can focus on:
1.- Increase the number of developers subscribed to our mailing list.
2.- increase the number of developers subscribed to our #IRC channel. Currently we have around 20 people.
3.- Increase the number of downloads of our materials: VM images (tools), slides from conferences.
4.- Increase the viewers of the videos of our conferences.

All the above objectives can be measurable together with the influence that twitter has on them so we can determine goals for 2018 based on the numbers we get in this first 2017.


Thanks, Wolfgang

regards

Nori


On Wed, Mar 29, 2017 at 10:53 PM, Agustin Benito Bethencourt
<agustin.benito@codethink.co.uk <mailto:agustin.benito@codethink.co.uk>>
wrote:

Hi,

maybe we can start the support of our promo efforts with a Twitter
account. I would also think about a hashtag

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk
<mailto:agustin.benito@codethink.co.uk>
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org <mailto:cip-dev@lists.cip-project.org>
https://lists.cip-project.org/mailman/listinfo/cip-dev
<https://lists.cip-project.org/mailman/listinfo/cip-dev>




--
Noriaki Fukuyasu

The Linux Foundation
Mail: fukuyasu@linuxfoundation.org <mailto:fukuyasu@linuxfoundation.org>
Tel: +81-80-4350-1133
Twitter: nori_fukuyasu
Facebook: linuxfoundationjp

Please visit our web sites:
http://www.linuxfoundation.jp
http://events.linuxfoundation.jp
http://jp.linux.com



_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: Twitter account

Mauerer, Wolfgang
 

Hi all,

On 31.03.2017 12:51, Agustin Benito Bethencourt wrote:
On 31/03/17 11:26, Wolfgang Mauerer wrote:
On 30.03.2017 15:33, Noriaki Fukuyasu wrote:

I think this is a great idea.
The challenge is how to manage the posts (who, what and how often etc).
Anyway, let me think over this.
marketing and creating public awareness of our endeavour is
of course good -- keeping up regular activity is going to be the
hard thing. But if we publish

* new software releases (board at desk, kernel)
* member presentations at conferences
The above will allow us to have one tweet per month which is not a bad
start. I prefer less tweets but relevant than a lot of noise.


we should at least have some base activity. I'm wondering, though,
what we intend to achieve with the account? (except that everybody
needs to have a Twitter account these days, as it seems :))
This is always a good question.

We can focus on:
1.- Increase the number of developers subscribed to our mailing list.
2.- increase the number of developers subscribed to our #IRC channel.
Currently we have around 20 people.
3.- Increase the number of downloads of our materials: VM images
(tools), slides from conferences.
4.- Increase the viewers of the videos of our conferences.

All the above objectives can be measurable together with the influence
that twitter has on them so we can determine goals for 2018 based on the
numbers we get in this first 2017.
... which suggests that we should also do after-conference tweets once
any materials (slides, videos) have been published.

Thanks, Wolfgang


Thanks, Wolfgang

regards

Nori


On Wed, Mar 29, 2017 at 10:53 PM, Agustin Benito Bethencourt
<agustin.benito@codethink.co.uk <mailto:agustin.benito@codethink.co.uk>>
wrote:

Hi,

maybe we can start the support of our promo efforts with a Twitter
account. I would also think about a hashtag

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk
<mailto:agustin.benito@codethink.co.uk>
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org <mailto:cip-dev@lists.cip-project.org>
https://lists.cip-project.org/mailman/listinfo/cip-dev
<https://lists.cip-project.org/mailman/listinfo/cip-dev>




--
Noriaki Fukuyasu

The Linux Foundation
Mail: fukuyasu@linuxfoundation.org <mailto:fukuyasu@linuxfoundation.org>
Tel: +81-80-4350-1133
Twitter: nori_fukuyasu
Facebook: linuxfoundationjp

Please visit our web sites:
http://www.linuxfoundation.jp
http://events.linuxfoundation.jp
http://jp.linux.com



_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Recent bug after updating kernelci

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

those of you who are trying to build BAD-SD VM with Vagrant might have noticed that the builds done with kernelci does not appear in the dashboard.

The ticket is here: https://gitlab.com/cip-project/testing/issues/63

Upstream has updated the backend of kernelci and we are looking into how this affects our set up.

In the near future we will provide the VM image so, when upstream updates key parts of the tooling breaking our VM, you will still be able to download and use the image while we adapt to the new changes.

Best Reagrds

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


CIP TSC meeting minutes (3 April 2017)

Yoshitake Kobayashi
 

Hi everyone,

I uploaded the meeting minutes for CIP Technical Steering Committee meeting
held 3 April, 2017 at the following link.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr032017

Past TSC meeting minutes can be find at the following link.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings.

Best regards,
Yoshi


Re: CIP TSC meeting minutes (3 April 2017)

Takuo Koguchi
 

Hi Yoshi,

Regarding to my project-x action item, recipes-kernel for BBB and CycloneV is already posted.

If you copy recipes-kernel to your usual poky build (i.e. DISTRO = poky without meta-debian,)
you will be able to bitbake virtual/kernel.

But it you want to use this recipe with meta-debian, there are some issues.
1) you have to add meta-PROJECTX/conf/local.conf.sample and bblayer.conf.sample manually.
This is my fault. I forgot to include these files. You can copy these files from deby-qemux86-64/meta-PROJECTX/conf

If you do the above, you can bitbake virtual/kernel if the followings are in conf/local.conf
MACHINE="beaglebone"
LINUX_DEFCONFIG="omap2plus_defconfig"

But this is still not what I meant for.
In the above mentioned build my "linux-cip" recipe is not used even if
PREFERRED_PROVIDER_virtual/kernel = "linux-cip"
is defined in local.conf because PREFERRED_PROVIDER _virtual/kernel is overwritten
by meta-debian/conf\/distro/include/debian-preferred-provider.inc:2
to "linux-base"

I hope you can change
PREFERRED_PROVIDER_virtual/kernel = "linux-base"
for
PREFERRED_PROVIDER_virtual/kernel ?= "linux-base"

Unfortunately there are still some issue to build kernel with meta-debian. I am working on it.


Best Regard,

Takuo Koguchi

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org
[mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of KOBAYASHI Yoshitake
Sent: Thursday, April 06, 2017 2:07 PM
To: cip-dev@lists.cip-project.org
Subject: [!][cip-dev] CIP TSC meeting minutes (3 April 2017)

Hi everyone,

I uploaded the meeting minutes for CIP Technical Steering Committee meeting held 3
April, 2017 at the following link.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_apr03201
7

Past TSC meeting minutes can be find at the following link.
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings.

Best regards,
Yoshi


_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

181 - 200 of 7514