Hi Adrian,
sure - here's the bug report on kernel.org:
https://bugzilla.kernel.org/show_bug.cgi?id=188201
Regards,
Timo
Adrian Chadd schrieb am 18.11.2016 22:22:
> hiya!
>
> Can you file a kernel.org bug mentioning this?
>
> thanks!
>
>
> -a
>
>
> On 18 November 2016 at 01:30, Timo Sigu
From: Rafał Miłecki
Recent refactoring introduced a regression. It ignored second argument
of make_support_list function which was originally true for C2600. The
new generic build_image function always passes false.
This patch allows specifying trailing char in a device specific info. It
also sw
From: Rafał Miłecki
Our current implementation is pretty old and uses some pre-standard/old
ANSI C style that triggers warnings like:
warning: call to function 'MD5_Init' without a real prototype
[-Wunprototyped-calls]
This is caused by declarations specified in a following way:
src/md5.h:60:6:
On 19.11.2016 19:42, Jo-Philipp Wich wrote:
> $version = the base version number, e.g. 16.11 - this is what I'd like to
be the main identifier
> $nickname = the symbolic name for a release branch, e.g. "Rolling Rabbit"
- due to its arbitrary nature I do not want it to be part of directories or
Some other consideration when thinking about tags:
Ideally we should rewrite the feeds.conf.default in the repository to
pin down the specific revisions used for the feeds which means that we
should likely produce automatic commits + automatic tags prior to
issuing the binary build.
This can happ
Hi David,
> does it really make sense to make a branch instead of just tagging
> commits? Is there really an expectation that there will be different
> changes in a release branch vs the mainline (especially for feeds, I can
> see an argument for the lede source in that you may backport some fixes
Hi Luiz,
> We need both: branch for the new release and tag the released commit
> and each subrelease (ex: x.y.2)
as mentioned in my other mail to Hannu we can automatically emit tags
for builds we publish but keep in mind that this will likely only work
for the base repository and not for the ex
Hi Hannu,
sorry that some things where confusing, the mail was written in a hurry.
> I would prefer to have clear branches like "lede-16.11" for all the
> repos. Tags will not be sufficient when updates are made to the packages
> after the release and people compile new builds.
I too think that
I like your release approach in general.
I would prefer to have clear branches like "lede-16.11" for all the repos.
Tags will not be sufficient when updates are made to the packages after the
release and people compile new builds. (case for branch arises when a package
has after a release firs
We need both: branch for the new release and tag the released commit
and each subrelease (ex: x.y.2)
---
Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org
On Sat, 19 Nov 2016, Jo-Philipp Wich wrote:
Hi all,
I am currently on working on automating the required steps to cut a
proper release - in order to make this process as standardized and
repeatable as possible, I intend to script any required steps to avoid
the need for manual setup tasks as mu
Hi all,
I am currently on working on automating the required steps to cut a
proper release - in order to make this process as standardized and
repeatable as possible, I intend to script any required steps to avoid
the need for manual setup tasks as much as possible.
Ideally I want to reach a poin
From: Paul Wassi
Add board 'dockstar' to known fw_env-configurations.
Signed-off-by: Paul Wassi
---
In order to get fw_printenv / fw_setenv working out-of-the-box on
a dockstar, the /etc/fw_env.config file is needed. This file is usually
created by uci-defaults/30_uboot-envtools but it currentl
13 matches
Mail list logo
