On 10/21/21 9:11 AM, Rui Salvaterra wrote:
isl.gforge.inria.fr has been dead since early this month [1]. Switch to
libisl.sourceforge.io for the time being.
[1] https://groups.google.com/g/isl-development/c/JGaMo2VUu_8
Signed-off-by: Rui Salvaterra
---
Acked-by: Paul Spooren
Note: this
which
should be used on the many many open PRs on master branch. I’d therefore kindly
ask you to wait for the next release.
Best,
Paul
> On 20. Oct 2021, at 13:01, Paul Spooren wrote:
>
> Hi all,
>
> Hauke an me plan to tag 21.02.1 this Friday.
>
> Motivation is the rec
Hi Luka,
> On 28. Oct 2021, at 07:08, Luka Logar wrote:
>
> Hi,
>
> I've submitted a set of patches in Februray to enable certificate/two factor
> authentication for LuCI.
>
> I guess, there is no will to accept those patches?
Could you please send me those patches again I can’t seem to fin
> On 6. Dec 2021, at 13:37, Paul D wrote:
>
> Could coreutils in rust be interesting for this project? (memory safety, at
> least at a later date)
I think long term rust routers would be of interest, did you already do some
rather research? From a first looks it seem to miss a shell which i
Hi all,
Kernels for the next release are looking pretty good; except for six targets we
got everything running on 5.10! Thanks to everyone who contributed and tested!
The following five target support Kernel 5.10 and need testing:
- ath25
- bcm63xx
- layerscape
- octeon
- octeontx
If you own t
Hi,
> I would be fine to remove the arc770 and the ipq807x targets.
I removed ipq807x for now, arc770 should receive a patch within the next days.
> There is no hardware available on the consumer market supported by arc770 and
> I think archs38 is the successor anyway. If someone wants to add s
Hi all,
Back at the Hamburg meeting in 2019 and a succeeding vote we decided to migrate
over to a self-hosted GitLab instance. Some years passed and nothing really
happened so I’d like to give this another go.
None of the OpenWrt project members is willing to setup and maintain a GitLab
instan
Hi,
Looking at openwrt.git I find seven targets with the source-only tag. The tag
means the build infrastructure skips building the targets. Does it make sense
to carry those target in tree or should we move them to our target archive?
- lantiq/falcon
- oxnas/ox810se
- malta/le64
- malta/le
- m
Which project is this for? I don’t see a devices.txt in openwrt.git.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
.com/gitea/tea
[17]: https://github.com/cli/cli
> On 7. Jan 2022, at 10:34, Paul Spooren wrote:
>
> Hi all,
>
> Back at the Hamburg meeting in 2019 and a succeeding vote we decided to
> migrate over to a self-hosted GitLab instance. Some years passed and nothing
> real
Hi Sam,
>
> A big thank you for doing this.
Half the fun.
>
> Must confess: I was unaware of the ~16k issue body character limit when
> I proposed SourceHut. Did you find a public bug report or feature
> request about that? (I looked just now. Could not find one myself, but
> perhaps my sear
Hi Michael,
> "Codeberg e.V. is a registered non-profit association based in Berlin,
> Germany"
> So, this makes me feel better.
I’ll write them an email asking for their long term ideas of maintaining Gitea.
Just because is a “e.V.” and in Germany doesn’t make it super sustainable,
trustworth
Hi Florian,
> I have now been persuaded to share my thoughts on the subject as well.
Thank you.
> Why not gitlab?
> Here we can take the services (GIT, CI/CD, ISSUE-Tracking) from them.
Some people don’t like the particularly “bloated” interface of GitLab but I
agree, they offer the stuff we’r
Hi Etienne,
>>
>> Currently we’re facing an issue[1] from our heterogeneous buildbot setup[2]
>> that partly uses outdated runners missing packages installed host packages,
>> causing them to upload broken SDKs at random.
>
> My understanding is that buildbot runner are docker containers now s
Heads up
> Hi,
>
> I herewith close this vote. Future votes or vote changes should not change
> the result.
>
> The switch to GitHub Issues was accepted, 20 out of 37 eligible voters are in
> favor.
>
> Additionally, 4 are against, 7 stayed neutral and 6 did not participate the
> vote.
>
>
Hi all,
For the last year or so[1] I’ve been working on replacing the package manager
OPKG with APK (Alpine Package Keeper)[2]. Different from our OPKG fork is APK
an actively developed project. OPKG is replaced entirely, both on device as
well as the build system.
Using some CI I started to b
> It works quite fine, and it's harmless.
I’d do that and bump the target to 5.10. that should give us a good chance to
fork soonish
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-deve
People writing the release notes and change logs are busy. I’ll try to write
the announcement later today with Hauke if he has the time.
> On 24. Feb 2022, at 11:59, Seo Suchan wrote:
>
> both are taged 7 days ago and it look target is built feb 18 and package
> builder passed taged commit, s
Hi,
The OpenWrt community is proud to announce the second service release of
OpenWrt 21.02. It fixes security issues, improves device support, and brings a
few bug fixes.
We recently moved our bugs to GitHub, please report issues over there (after
checking that nobody else posted the same issu
> On 27. Feb 2022, at 12:12, Petr Štetiar wrote:
>
> From: Perry Melange
>
> The freifunk feed is being removed becasue
> a) it is an external project and the OpenWrt team does not have access to it.
> b) upon original addition of the feed, there was only a very weak tendency for
> the additi
> On 28. Feb 2022, at 08:34, Rosen Penev wrote:
>
> __bswap_32 is a GNU extension.
>
> Signed-off-by: Rosen Penev
> —
Seems to fix the compile issue on my Mac.
Acked-by: Paul Spooren
If people change things in tools/, please use GitHub PRs. I added a CI to
compil
> On 28. Feb 2022, at 09:51, Rosen Penev wrote:
>
> On Mon, Feb 28, 2022 at 12:43 AM Paul Spooren wrote:
>>
>>
>>
>>> On 28. Feb 2022, at 08:34, Rosen Penev wrote:
>>>
>>> __bswap_32 is a GNU extension.
>>>
>>> Si
Hi
> On 27. 02. 22 15:29, Paul Spooren wrote:
>> Isn’t it bad to backport package (or even feed) removal?
>
> This feed was removed before OpenWrt 21.02-rc1 was released, but it was you,
> Paul, who asked if it could be backported to OpenWrt 19.07 based on this
> commen
Hi team,
> On 19. Feb 2022, at 19:21, Phillip Lougher wrote:
>
> On Sat, Feb 19, 2022 at 4:01 PM Felix Fietkau wrote:
>>
>> On 19.02.22 16:54, Stijn Tintel wrote:
>>> Drop the -processors argument from the mksquashfs4 call, so it will use
>>> all available processors. This dramatically reduces
> On 28. Feb 2022, at 12:35, Stijn Tintel wrote:
>
> On 28/02/2022 13:22, Paul Spooren wrote:
>> Hi team,
>>
>>> On 19. Feb 2022, at 19:21, Phillip Lougher
>>> wrote:
>>>
>>> On Sat, Feb 19, 2022 at 4:01 PM Felix Fietkau wrote:
&
Hi,
> On 3. Mar 2022, at 16:44, Petr Štetiar wrote:
>
> Marcel Telka [2022-03-02 06:59:49]:
>
> Hi,
>
>> I tried to rebuild my firmware using new 19.07.9 imagebuilder on a CentOS 7
>> host and it failed with this error:
>
> sorry for the breakage.
>
>> [mktplinkfw2] rootfs offset aligned t
Dear all,
as discussed during our last member meeting, there is now a feature freeze in
place! Please don't commit any major changes until the planed branch around
March 20th.
After the branch heavy changes (i.e. Kernel 5.15) can be merged, for now we
should work on bugs and finish up `firewal
Hi Rich,
> On 23. Mar 2022, at 11:30, Rich Brown wrote:
>
> The Apple "RPM Tool" is great for measuring network responsiveness.
>
> High numbers from the tool (measured in round-trips per minute - or "RPM")
> show your network is responsive, even when it's heavily loaded with traffic.
> This
> On 23. Mar 2022, at 12:57, Rich Brown wrote:
>
> Bjørn,
>
> Thanks for these comments.
>
>> On Mar 23, 2022, at 8:34 AM, Bjørn Mork wrote:
>>
>> There is no need to read anything from a file or device. You can just
>> serve the same memory buffer in a loop.
Thanks, I’ll check that in ca
Looks good to me. I’m just wondering if LuCI will pull in dnsmasq et al again
for release builds.
> On 25. Mar 2022, at 13:42, Hauke Mehrtens wrote:
>
> The tc package does not exits any more, it was split into tc-tiny,
> tc-full and tc-bpf. Include tc-bpf by default into realtek images.
>
>
I extended the reasoning in the commit message and merged this as discussed in
IRC
> On 28. Feb 2022, at 11:49, Paul Spooren wrote:
>
>
>
>> On 28. Feb 2022, at 12:35, Stijn Tintel wrote:
>>
>> On 28/02/2022 13:22, Paul Spooren wrote:
>>> Hi te
> On 29. Mar 2022, at 12:45, Hauke Mehrtens wrote:
>
> On 3/25/22 17:35, Paul Spooren wrote:
>> Looks good to me. I’m just wondering if LuCI will pull in dnsmasq et al
>> again for release builds.
>
> Stijn tested this on top of OpenWrt 22.03 branch successfully
Hi,
> To investigate the issue of non-reproducible kernel images accross
> buildhosts I compated the files build by OpenWrt's buildbots with
> Paul's rebuilder script running on his (Aarch64) Mac.
Sorry there was a misunderstanding. I’m building on macOS to find extra issues
but the “rebuild” fi
Hi,
>> +$(SED) -i $(LINUX_DIR)/Makefile -e
>> 's/--build-id=.*/--build-id=0x$(LINUX_VERMAGIC)/g’
This doesn’t fly since LINUX_VERMAGIC (based on .vermagic) is based on the
Kernel configuration and only available after the Configuration step. I moved
it from the Prepare to the end of Config
Hi,
> On 5. Apr 2022, at 21:33, Bjørn Mork wrote:
>
> Daniel Golle writes:
>
>> You probably meant LDFLAGS_vmlinux because from what I understand
>> KBUILD_LDFLAGS_MODULE only applies when building modules but not when
>> linking vmlinux.
>> As ld only cares about the last mentioned --build-id
> On 18. Aug 2022, at 16:07, Stijn Tintel wrote:
>
> On 18/08/2022 17:03, Thibaut wrote:
>>> Le 18 août 2022 à 15:40, Stijn Tintel a écrit :
>>>
>>> On 16/08/2022 20:00, Thibaut VARÈNE wrote:
Disabling this build tunable breaks build and seems unrealistically
likely to be fixed.
>>>
t step".
>>
>> Cheers,
>> Thibaut
>>
>> [1] https://github.com/openwrt/openwrt/issues/9580
>
> OK, in that case, let's await at least one more ACK and we can start
> with this.
Per request:
Acked-by: Paul Spooren
>
> Thanks,
> Stijn
> On 11. Aug 2021, at 11:58, Florian Eckert wrote:
>
> With the commit 5876d6a62fc0ae5799e7d9c896356f75c99a6f0a the command under
> `/usr/sbin/grub-bios-setup` has been moved to its own package named
> `grub-bios-setup`.
>
> The script `81_upgrade_bootloader` under `/lib/preinit` is used by a
Hi,
While I initially thought that $(AUTORELEASE) would be a nice feature to avoid
the standard review comment “Please bump the PKG_RELEASE”, it turned into a
massive increase of bandwidth usage: Every checkout of openwrt.git and package
feeds needs to be a full clone instead of a shallow one t
Hi all, please find our notes from yesterdays meeting below:
https://openwrt.org/meetings/20221130
Feel free to comment in this thread.
Sunshine,
Paul
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/lis
on the following subtargets:
> * cortexa9 (Turris Omnia - 03f41b1eb2f15ab06d5800274be6a67c64e2a629)
> * cortexa72 (MikroTik RB5009UG+S+IN)
>
> Signed-off-by: Stijn Segers
> ---
Acked-by: Paul Spooren mailto:m...@aparcar.org>>
> target/linux/mvebu/Makefile | 3 +--
> 1 file cha
> Nicholas
>
>
> All the best,
> Nicholas
>
> Nicholas Smith
> NB Embedded Pty Ltd
> nicho...@nbembedded.com
> ABN: 54 663 236 940
>
> Book a Meeting
>
>
> On Fri, 2 Dec 2022 at 06:22, Paul Spooren wrote:
>>
>> Hi all, please find our note
Hi,
I created a very basic script which should be extended to show all
hardware information needed. Once that works I'd package it.
https://forum.openwrt.org/t/script-convert-device-information-to-yaml/53516
Best,
Paul
On 1/12/20 11:47 AM, Paul Spooren wrote:
Hi all,
some time
ondition to use `generic` if the subtarget
is empty.
Tested for the kirkwood target.
Signed-off-by: Paul Spooren
---
include/image.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/image.mk b/include/image.mk
index 46d592e8dc..fd04d4020b 100644
--- a/include/ima
behaviour the option JSON_INDIVIDUAL_JSON_INFO
can be set.
Signed-off-by: Paul Spooren
---
Makefile| 6 ++
config/Config-build.in | 24 +
include/image.mk| 9 +---
scripts/json_overview_image_info.py | 33
Hi,
This PR refactors the JSON creation to store individual files in
$(KDIR)/tmp and create an single overview file called `profiles.json` in
the target dir.
As before, this creation is enabled by default only for the BUILDBOT.
To archive the previous behaviour the option JSON_INDIVIDUAL_JSON_
Hi,
for the last few days I get the following error for multiple targets,
would it be possible to rerun the snapshot servers to rebuild the
package `iw`?
$ make manifest PROFILE="devolo_dvl1750e"
[...]
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies
implementation used the functions `json.dumps()` which seem
to have caused broken files. Now the `pathlib` library is used to deal
with files and the `json` library only reads/writes into variables.
Tested via buildroot & ImageBuilder on ath79/generic.
Signed-off-by: Paul Spooren
---
v2:
* One ins
.
Thanks, included in v3
On 3/1/20 3:48 AM, Paul Spooren wrote:
JSON info files contain machine readable information of built profiles
and resulting images. These files where added via 881ed09ee6e2. They are
useful for firmware wizards and script checking for reproducibility.
Currently all JSON
On 01.03.20 02:34, Petr Štetiar wrote:
Paul Spooren [2020-02-29 16:48:50]:
FYI:
$ grep JSON .config
CONFIG_JSON_OVERVIEW_IMAGE_INFO=y
$ cat bin/targets/imx6/generic/profiles.json
{}
This problem occurs also fox x86, the problem is that the image function
is not properly called
Hi,
A first step could be to establish a *versions.json* file at the root of
downloads.openwrt.org! The file would allow to check if a device still runs
the latest release. JSON seems common enough and is well supported by LuCIs
JavaScript implementation and also via jshn.sh on a CLI/script leve
implementation used the functions `json.dumps()` which seem
to have caused broken files. Now the `pathlib` library is used to deal
with files and the `json` library only reads/writes into variables.
Tested via buildroot & ImageBuilder on ath79/generic.
Signed-off-by: Paul Spooren
---
v2:
* One ins
This problem occurs also fox x86, the problem is that the image function is
not properly called. Maybe because IMX6 only offer a default target but no
profiles, resulting in an empty profiles.json file - I think. I started
(based on Lynxis draft) reworking the x86 so it creates also JSON files[0
Hi,
Thinking on which info the client side would need, I would remove the
minors info if we can just skip to latest.
Yes, if we always skip to the latest anyway the "latest" key could
contain that version and the rest is simply interpolated. When wanting
to cover release candidates we could us
Hi Petr,
On 02.03.20 23:12, Petr Štetiar wrote:
Paul Spooren [2020-03-02 16:19:05]:
- .IGNORE: $(BIN_DIR)/$(call IMAGE_NAME,$(1),$(2))
[...]
$(BIN_DIR)/$(call IMAGE_NAME,$(1),$(2)): $(KDIR)/tmp/$(call
IMAGE_NAME,$(1),$(2))
- cp $$^ $$@
+ -cp $$^ $$@
The prefixed dash
` files is created as it would be empty anyway.
As before, this creation is enabled by default only if `BUILDBOT` is set.
Tested via buildroot & ImageBuilder on ath79/generic, imx6 and x86/64.
Signed-off-by: Paul Spooren
---
v2:
* One instead of three CONFIG options
* Only created `profiles
Hi team,
based on @tmn505 and @lynxis great work[0][1] I created a rebased hybird
version upgrading the x86 image creation code to use `image.mk`!
I created the patch on Github.com[3], but as it is such a core component
I can also send the patch to the list...
It works and boots via qemu and doc
On Sat Mar 7, 2020 at 1:34 AM PST, Petr Štetiar wrote:
> Paul Spooren [2020-03-05 12:26:03]:
>
> Hi,
>
> > +json_overview_image_info: FORCE
> > + WORK_DIR=$(BUILD_DIR)/json_info_files \
> > + TARGET_DIR=$(BIN_DIR) \
> > + $(SCRIPT_DIR)/js
no JSON info files were created, no
`profiles.json` files is created as it would be empty anyway.
As before, this creation is enabled by default only if `BUILDBOT` is set.
Tested via buildroot & ImageBuilder on ath79/generic, imx6 and x86/64.
Signed-off-by: Paul Spooren
---
v2:
* One instea
On Wed Mar 11, 2020 at 2:12 AM PST, Petr Štetiar wrote:
> Paul Spooren [2020-03-10 18:11:21]:
>
> > + $$(_TARGET): $(BUILD_DIR)/json_info_files/$(call
> > IMAGE_NAME,$(1),$(2)).json
> > + $(BUILD_DIR)/json_info_files/$(call IMAGE_NAME,$(1),$(2)).json:
> > $(BIN_D
no JSON info files were created, no
`profiles.json` files is created as it would be empty anyway.
As before, this creation is enabled by default only if `BUILDBOT` is set.
Tested via buildroot & ImageBuilder on ath79/generic, imx6 and x86/64.
Signed-off-by: Paul Spooren
---
v2:
* One instea
On Thu Mar 12, 2020 at 2:55 AM PST, Paul Spooren wrote:
> JSON info files contain machine readable information of built profiles
> and resulting images. These files where added via 881ed09ee6e2. They are
> useful for firmware wizards and script checking for reproducibility.
>
> Cur
aciej Nowak
[rebase, adjusted commit title]
Signed-off-by: Paul Spooren
---
package/boot/grub2/Makefile | 31 +++
.../boot/grub2/files}/grub-early.cfg | 0
target/linux/x86/image/Makefile | 30 +-
3 files changed, 39 inser
redefining them.
* For subtargets create device definitions with basic packages set.
Signed-off-by: Tomasz Maciej Nowak
[rebased]
Signed-off-by: Paul Spooren
---
config/Config-images.in | 18 +-
include/image.mk | 1 -
target/linux/x86/Makefile
patches are added to keep consistency with current
behaviour.
[0]: https://patchwork.ozlabs.org/cover/1024165/
Paul Spooren (6):
x86/grub2: move grub2 image creation to package
x86: switch image generation to new code
x86: remove obsolete legacy profiles
x86: use qemu-image command from
Rely on device profiles instead for packages selection.
Signed-off-by: Tomasz Maciej Nowak
[rebase, adjusted commit title]
Signed-off-by: Paul Spooren
---
target/linux/x86/64/profiles/000-Generic.mk | 15 --
.../linux/x86/generic/profiles/000-Generic.mk | 19
=416cccf398e9589e3de386e05b61b1c46cace20d#l51
Signed-off-by: Paul Spooren
---
include/image-commands.mk | 7 +++
target/linux/x86/image/Makefile | 14 ++
2 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/include/image-commands.mk b/include/image-commands.mk
index 37cb083bbf
The previous image generation code would always gzipped images.
This patch changes the behaviour and only compresses images when
selected in menuconfig.
Signed-off-by: Paul Spooren
---
target/linux/x86/image/Makefile | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a
it still finds the file.
Signed-off-by: Paul Spooren
---
scripts/qemustart | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/qemustart b/scripts/qemustart
index dbb8deddaf..9ce03901aa 100755
--- a/scripts/qemustart
+++ b/scripts/qemustart
@@ -255,7 +255,7
Hi,
wan't squashfskit4 created as a workaround for an inactive upstream
maintainer? Wouldn't it make sense to move back to upstream now that it
is more up to date than our fork?
Best,
Paul
On Thu Mar 19, 2020 at 2:22 AM PST, Robert Marko wrote:
> From: Robert Marko
>
> In order to build squashf
On Sat Mar 21, 2020 at 5:41 AM PST, Alexander 'lynxis' Couzens wrote:
> Hi Paul,
> Hi Robert,
>
> > Sorry, I did not know about that situation but after a look it seems
> > that squashfs-tools is more up to date that the fork.
> > There has been a 4.4 release and couple of patches each month to it.
The x86 image generation was refacted via cb007a7bf6 and accidently not
included `geode.mk` when selected as subtarget.
Now the file is included and image compilation for x86/geode works
again.
Thanks to Russell Senior for reporting the
problem and suggesting a patch!
Signed-off-by: Paul
In the geode subtarget all default x86 features were overwritten via :=
instead of extending them via +=.
This patch fixes the inheritance and thereby the compilation of
x86/geode target.
Compile tested x86/geode.
Signed-off-by: Paul Spooren
---
target/linux/x86/geode/target.mk | 2 +-
1 file
With the recent rework of the x86 image creation the f2fs/ext4 based
overlays dissappeared as their are not copied by default.
This commit follows the implementation of malta and armvirt to copy the
overlays as well.
Signed-off-by: Paul Spooren
---
target/linux/x86/image/Makefile | 10
The previous rework of x86 image creation broke the `vdi` images. ussell
Senior came up with this patch to fix the
padding.
Tested with x86/64 with Docker (squashfs), qemustart (ext4/squashfs) and
virtualbox (ext4/squashfs).
Signed-off-by: Paul Spooren
---
target/linux/x86/image/Makefile | 10
With the recent rework of the x86 image creation the f2fs/ext4 based
overlays dissappeared as their are not copied by default.
This patch enables the creation of rootfs files for ext4 and squashfs
and stores it next to the combined images.
Signed-off-by: Paul Spooren
---
v2:
* Use generic
> >> typo in title and missing "R" in name directly above.
Ack
>
> This script is for only your typical block devices, no MTD involved.
>
> > Looks like you should rather fix the logic setting
> > CONFIG_TARGET_IMAGE_PAD.
>
> This has been removed with
> https://git.openwrt.org/d03ef97c1b57b2b558
Hi team,
I hope everyone is fine & healthy and can use the time in quarantine to
finally review those important patches I sent!
Based on recent events regarding COVID-19 the Battlemesh and the OpenWrt
developer meeting will not take place in May this year.
it's really nice and necessary to m
Tested on mvebu and fixes opkg issue the issue for me, thanks!
Best,
Paul
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
identical except for a `,`
replacement with `_`, which is due to Makefile naming limitations.
Signed-off-by: Paul Spooren
---
This is just a first step, we should follow the device tree identifier
for all other PROFILE as well.
target/linux/mvebu/image/cortexa9.mk | 56
`.
This patch uses Perls `uniq` function to add the profiles only once to
`.profiles.mk`.
Signed-off-by: Paul Spooren
---
scripts/target-metadata.pl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/target-metadata.pl b/scripts/target-metadata.pl
index ee0ab5a718
The ImageBuilder was never really updated to work with alternative names
of 4ee3cf2b5a, this patch makes the alternative names visible when
running `make info`. Also I can now cross of "Do something with Perl"
from my bucket list.
Paul Spooren (3):
scripts: target-metadata don'
Currently the alternative consumer names for devices are stored in the
description only or as a joint string in `Target-Profile-Name`. This
adds a new variable called `Target-Profile-AltNames` to store the
alternateive names as a quoted list: "" "" ""
Signed-off-
With the introduction of `Target-Profile-AltNames` the ImageBuilder
should show these names to allow users to find their devices without
knowing the name used in the OpenWrt build system.
Signed-off-by: Paul Spooren
---
target/imagebuilder/files/Makefile | 1 +
1 file changed, 1 insertion
On Wed Apr 1, 2020 at 5:02 AM PST, wrote:
> Hi,
>
> > > How about patching device's DTSes and include 'manufacturer,model'
> > there instead (in front of the existing ones)? Scripts in 'basic-files'
> > would also
> > need to be fixed but this way we save this (in my opinion) misuse of
> > 'DEVIC
as well.
Signed-off-by: Paul Spooren
---
phase1/master.cfg | 8
1 file changed, 8 insertions(+)
diff --git a/phase1/master.cfg b/phase1/master.cfg
index 792f9b3..6ff827d 100644
--- a/phase1/master.cfg
+++ b/phase1/master.cfg
@@ -925,6 +925,14 @@ for target in targets
first mirror to offer
worldwide fast download speeds by default. If the CDN goes down for
whatever reason, the script jumps to the next available mirror and
downloads requested files as before (in regional varying speed).
Signed-off-by: Paul Spooren
---
scripts/download.pl | 1 +
1 file changed, 1
work or -n.
Using --prebuild or -p will download the OpenWrt image from docker hub.
[0]:
https://forums.docker.com/t/modify-a-file-which-mount-as-a-data-volume-but-it-didnt-change-in-container/2813/14
Signed-off-by: Paul Spooren
---
scripts/docker-run-rootfs.sh | 96 +++
as well.
Signed-off-by: Paul Spooren
CC: Jo-Philipp Wich
---
v2:
* Removed the `haltOnFailure` options as this may break the current
builds if the merge script show any unexpected errors in the buildbot
environment. This option should be added again once the script proofs
working
list, therefore the for loop won't run.
Signed-off-by: Paul Spooren
CC: Petr Štetiar
---
scripts/json_overview_image_info.py | 2 --
1 file changed, 2 deletions(-)
diff --git a/scripts/json_overview_image_info.py
b/scripts/json_overview_image_info.py
index 5ed829249b..a1418e366d 10
On Wed, 2020-04-08 at 21:09 +0200, Petr Štetiar wrote:
> Paul Spooren [2020-04-08 08:57:13]:
>
> > v2:
> > * Removed the `haltOnFailure` options as this may break the
> > current
> > builds if the merge script show any unexpected errors in the
> > build
Hi all,
I was wondering if there are some best practices for configuration
management of OpenWrt devices. I understand that it is fairly easy to
get/restore a backup of the etc/config folder, but though maybe there
are some smarter ways.
Ideally a local state (e.g. git repository) would deploy mu
.
Signed-off-by: Paul Spooren
---
target/linux/x86/image/Makefile | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile
index 7a474e7a6e..77516a4a9d 100644
--- a/target/linux/x86/image/Makefile
+++ b/target/linux
x27;t need to keep track of two different names for the same
device.
Additionally running devices now know which profile was used to create
the running firmware, instead of requiring an additional mapping.
Signed-off-by: Paul Spooren
---
This is just meant as a RFC, in case the idea is good I
Hi Li Zhang,
thank you very much for the contribution! Please stick to the device
tree naming schema of `manufacture,model` when adding devices to
OpenWrt. In this case the device should be called `glinet,gl-vm1000`
instead of just `gl-mv1000`.
For the device profile (inline commented below), ple
options or at least disable-able via a option?
On Mon, 2020-04-06 at 01:53 -1000, Paul Spooren wrote:
> OpenWrt now has a CDN for sources at sources.cdn.openwrt.org which
> mirrors sources.openwrt.org.
>
> Downloading sources outside Europe or US (mainland) could
> result in
The buildroot and SDK both require `libncurses-dev` to be installed on
the system, however the ImageBuilder uses precompiled binaries.
This patch changes the prerequirements checks to skip the
`libncurses-dev` part if running as ImageBuilder.
Signed-off-by: Paul Spooren
---
include/prereq
work or -n.
Using --prebuild or -p will download the OpenWrt image from docker hub.
[0]:
https://forums.docker.com/t/modify-a-file-which-mount-as-a-data-volume-but-it-didnt-change-in-container/2813/14
Signed-off-by: Paul Spooren
---
scripts/docker-run-rootfs.sh | 103 +++
`.
This patch uses Perls `uniq` function to add the profiles only once to
`.profiles.mk`.
Signed-off-by: Paul Spooren
---
v2:
* Instead of importing the entire MoreUtils library only copy the
`uniq` function.
scripts/target-metadata.pl | 11 ++-
1 file changed, 10 insertions(+), 1
Forgot to annotate, the v2 adds a description of the NETWORK_PREFIX to the usage
message.
On Tue, 2020-04-14 at 14:39 -1000, Paul Spooren wrote:
> The script allows to run a OpenWrt x86/64 rootfs in no time. It is
> possible to access the web interface and SSH via 192.168.1.1.
>
&
301 - 400 of 611 matches
Mail list logo
