Re: live test system

Hi Paul (cool name!), > Another live system with openwrt master with various openwrt PRs that come > in, integrated under some predictable URL (https://host/pr2). Some kind > of capability to tweak settings live, or see the console output. ( Does owrt > run well in docker as a guest? )

Re: some github runner failers

> On Feb 15, 2024, at 00:12, Paul D wrote: > > https://github.com/openwrt/packages/actions/runs/7908507874/job/21587828762?pr=23415 > > for various platforms > > errors: > > > #4 [internal] load metadata for > docker.io/openwrt/rootfs:i386_pentium-mmx-openwrt-23.05 > #4 ERROR: no match

Re: ustream-ssl ABI_VERSION usage

Hi, > On Feb 12, 2024, at 14:30, Petr Štetiar wrote: > > Jo-Philipp Wich [2024-02-12 14:09:27]: > > Hi, > >> Ideally all packages specifying an ABI version should ship versioned .so >> files >> as well. > > I would like to point out, that ustream-ssl is dynamically loaded library[1], > so

ustream-ssl ABI_VERSION usage

Hi, While working on using APK instead of OPKG, I started to look into ABI versions of different packages and found that ustream-ssl always install libustream-ssl.so , with no ABI version attached. > $(INSTALL_DATA) $(PKG_INSTALL_DIR)/usr/lib/libustream-ssl.so

Re: [VOTE] New member proposal: Robimarko (Robert Marko)

Hi, > On Jan 30, 2024, at 19:15, Christian Marangi (Ansuel) > wrote: > > Robert is active in OpenWrt since 2017 and with some recent stats, he > has more than 310 commits merged in OpenWrt. > He also have uncounted Reviewed-by tag on various PR and merged commits > and generally helps in

Re: Are we still use md5 as default as password hash?

all new >> passwds to use new hash (shell or luci), but won't upgrade without user >> changing it first. but we'd better expose and set USE_BCRYPT of busybox >> option to be able to use bcrypt here (not sure routers cpu can handle it >> as it's made to be slow though. >> >

Re: Are we still use md5 as default as password hash?

Hi, > however Busybox doesn't configed to use those and still use md5 as > default, while we bring other hash algos into flash anyway: Does the following do the trick? diff --git a/package/utils/busybox/Config-defaults.in b/package/utils/busybox/Config-defaults.in index b3c3f9a0b2..5ae8dd5622

Re: Real name vs. known identity in contributions

Hi one-d-wide, > Unfortunately I was refused to contribute under my usual nickname due to > real-name-only rule I adopted the `submitting-patches` page and create PRs for both openwrt.git and packages.git. Thanks for reminding me of this. https://github.com/openwrt/packages/pull/23084

[PSA] forum.archive.openwrt.org moved to static copy

Hi all, As part of the ongoing migration away from the old mirror-01 server I copied the old forum today to a static git repository[1]. It’s now hosted as a GitHub page. Since they don’t support IPv6[2] I may move it to another provider in the near future. For now you may clone the repository

Re: PKG_MAINTAINER_HANDLE

Hi Paul, > PKG_MAINTAINER:=Joe Bloggs > PKG_MAINTAINER_HANDLE:=github: @joe; https://forum.openwrt.org/u/joe/ > > Plan B > > co-opt existing PKG_MAINTAINER field, but perhaps it's possible? > > e.g: > > PKG_MAINTAINER:=Joe Bloggs , github: @Joe I think for that you could use a Codeowners

RFC pkgs.staging.openwrt.org

Hey all, tl;dr checkout https://pkgs.staging.openwrt.org/ As some may experienced, openwrt.org is slow an one (of many reasons) is that it stores and renders tables with all packages. Based on feedback the experience is neither convincing nor does it perform well within a DokuWiki. After

Re: Maintenance of openwrt.org and CDN for downloads

ould be able to serve 1PB/a, so ideally nothing that is limited to 1-2 TB per month. Thanks for ideas! Please enjoy the new download speeds including HTTP/3. Sunshine, Paul [1]: https://openwrt.org/downloads#mirrors > On Dec 13, 2023, at 17:10, Paul Spooren wrote: > > Dear all, >

Re: Maintenance of openwrt.org and CDN for downloads

package managers… Please report on issues and problems, ideally only to the openwrt-adm list. Thanks everyone for using OpenWrt! Best, Paul > On Dec 13, 2023, at 17:10, Paul Spooren wrote: > > Dear all, > > I plan to upgrade our wiki (openwrt.org <http://openwrt.org/>)

Maintenance of openwrt.org and CDN for downloads

Dear all, I plan to upgrade our wiki (openwrt.org ) next Sunday, 17th of December. I’m expecting just a short downtime since a successful upgrade already happened on a staging instance. In case you urgently need to lookup information, please use the staging instance during

Battlemesh x OpenWrt meeting in Cyprus?

Hi all, While attending this years Battlemesh in Spain some fellow mesh people asked why there weren’t more OpenWrt people around. I’m guessing it was mostly due to the lack of communication in advance, so I’d like to raise the topic here: Are people from the OpenWrt community, specially

Re: Adding a new x86 image or related packages to the default x86 image

>> On 2023-09-14, Paul Spooren wrote: >>> >>> I’d like to merge the PR which adds the Mellanox Spectrum SN2100 to >>> OpenWrt[1]. In its current state a new x86 image would be added next >>> to the generic x86 image. Another approach is to add all re

Re: [PATCH v2 firmware-utils] add dlink-sge-image for D-Link devices by SGE

> On Nov 2, 2023, at 20:16, Sebastian Schaper > wrote: > > This tool will encrypt/decrypt factory images requiring the "SHRS" header > e.g. COVR-C1200, COVR-P2500, COVR-X1860, DIR-878, DIR-882, ... > > Encryption is loosely based on a series of blogposts by ricksanchez [1] > and the provided

Re: [PATCH firmware-utils] add dlink-sge-image for D-Link devices by SGE

Hello, > On Jun 23, 2023, at 14:06, Sebastian Schaper > wrote: > > This tool will encrypt/decrypt factory images requiring the "SHRS" header > e.g. COVR-C1200, COVR-P2500, COVR-X1860, DIR-878, DIR-882, ... > > Encryption is loosely based on a series of blogposts by ricksanchez [1] > and the

Re: [PATCH] x86 64: Add new device Cordoba Edge Platform

Hi, We kind of don’t add image just to contain extra drivers. Extra UCI defaults for eth ordering are fine but please don’t add an extra image if it just contains 1-2 extra packages, installable via the ImageBuilder or OPKG. > >> On Oct 23, 2023, at 8:52 PM, Xiaojun Liu wrote: >> >> Add new

Re: Adding a new x86 image or related packages to the default x86 image

Hi, > I'd suggest to stick to a single x86_64 image for maintenance and testing > reasons alone I agree. Furthermore, x86 devices have often no device identity like other devices using device tree do. With the current implementation, the attended sysupgrade service would be broken since on

Adding a new x86 image or related packages to the default x86 image

Hi, I’d like to merge the PR which adds the Mellanox Spectrum SN2100 to OpenWrt[1]. In its current state a new x86 image would be added next to the generic x86 image. Another approach is to add all related packages to the default image. Either way creates a working image. I remember that

Re: Reserving USERID

Hi, > Is explicit better or not? And if it is better, how do I go about reserving > values that won't get stepped on? Who is our Numbers Czar, who is our IANA? I always used Gentoos numbers[1] whenever I added something. Since Clixon is not part of that list, maybe use something that’s not

Call for help with sysupgrade.openwrt.org maintainance

Hey all, some long time ago I attended a Google Summer of Code and created this service som may know called sysupgrade.openwrt.org. Essentially it’s an API for OpenWrt ImageBuilders. Instead of downloading them and its dependencies, you request a firmware image by specifying version, installed

Re: [VOTE] commit access for PolynomialDivision (Nick Hainke)

the onboarding. Best, Paul > On 25. Apr 2023, at 19:59, Paul Spooren wrote: > > Hi all, > > After talking to Nick directly and asking during the last developer meeting a > few minutes ago, I’d like to start a vote on granting Nick commit access. > > With more than 300 commits i

Meeting Notes April 2023

Hi all, another month, another meeting -> https://openwrt.org/meetings/20230425 Happy first of May, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Mark lantiq and omap as source only

Hi all, I haven’t seen much progress happening regarding bringing the targets lantiq or omap to Kernel 5.15. That fact is currently the last blocker for branching another release. Instead of postponing another release I’d like to mark both targets as source-only and do the 23.05 branch,

Re: [OT] Additional container registry mirror [Was: Re: Sunsetting the Docker `openwrtorg` org (not `openwrt` org)]

Hi all, >> I've not done any prior research about all viable options yet, but quay.io >> looks so far as my favorite option. Any objections/ideas? I added quay.io as a third registry (next to docker.io and ghcr.io ). By doing so I found that there seem to

Re: 22.03.4 and 21.02.6 were officially announced 3 days ago, but only partially.

Hi, > On one hand: >* two threads were posted in the "Release and security announcements” > section of the OpenWrt forum >* the OpenWrt.org front page has been updated with links to the new > versions >* the release notes are no longer WIP >* the firmware selector has the new

OpenWrt 22.03.4 and 21.02.6 released

Hi all, As many of you already figured, two new stable releases are out! Please consider a timely update unless you’re running certain devices of the ipq40xx target[1]. -> 22.03.4 Release Notes: https://github.com/openwrt/openwrt/releases/tag/v22.03.4 Changelog:

Sunsetting the Docker `openwrtorg` org (not `openwrt` org)

Hi all, I’d like to disable the `openwrtorg` organization on Docker.io . It was initially created since some unknown entity registered `openwrt` without using it. After some clarification with the Docker team they thankfully granted us access to the account. By migrating

Re: next OpenWrt 22.03 and 21.02 minor release

Hi all, Last night we tagged two new point releases for the 22 and 21 releases. I’m traveling right now but will try to write the release notes later today. Best, Paul > On 7. Apr 2023, at 18:31, openwrt-de...@matthias-larisch.de wrote: > >  >> >> Mateusz Jończyk wrote on 06.04.23 14:18:

Meeting Notes March 2023

Hi, Another month, another developer meeting - short and sweet: https://openwrt.org/meetings/20230328 Best, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: next OpenWrt 22.03 and 21.02 minor release

> On 28. Mar 2023, at 09:09, Joseph Mullally wrote: > >> If we should backport more changes please create a pull request on >> github, send a patch with the 22.03 or 21.02 prefix to the mailing list >> or send a mail with a link to the master commit we should backport as an >> answer to this

Re: Docker is sunsetting Free Team organizations

Hi, I requested sponsoring from Docker, let’s see how it goes. While at it, I’d remove openwrtorg entirely instead of not updating it. I don’t thing we get sponsoring for both orgs and it’s just confusing. Best, Paul > On 17. Mar 2023, at 12:00, Paul Spooren wrote: > > Hi all, >

Re: Docker is sunsetting Free Team organizations

Hi all, > > we don't mirror it elsewhere. > >> (gitlab/github) >> docker.io/openwrtorg/imagebuilder >> docker.io/openwrtorg/sdk >> docker.io/openwrtorg/rootfs I’d sunset openwrtorg and only use “openwrt”. > >> Do we want to apply for "Docker-Sponsored Open Source Program" >>

Meeting notes 21st February 2023

Hi all, with a bit of a delay the notes of the last meeting. Nothing special came up, mostly a recap of what happened over the month. https://openwrt.org/meetings/20230221 Best, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org

OpenWrt project mirrors on GitHub

Hi all, All project from git.openwrt.org are now mirrored over to GitHub to allow further use of the CI and better visibility. I’d like to get some opinions on enabling Issues (aka GitHub bug tracker). Right now issues are enabled since other “subprojects” like odhcpd and mt76 have their own

Anyone working on porting OpenSSL to v3.x?

Hey all, We’re still using OpenSSL 1.1.x within OpenWrt and during the last developer meeting we were wondering if anyone is working on porting it over to v3.x? If so please share your status, thanks! Best, Paul ___ openwrt-devel mailing list

Meeting Notes February

Hi all, We had another meeting, please find the notes below: https://openwrt.org/meetings/20230124 Sunshine, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Developer Meeting November 2022

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 notes fro

Re: [PATCH] mvebu: switch default kernel to 5.15

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 c

Developer Meeting November 2022

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

[RFC] dropping of $(AUTORELEASE) feature

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

Re: [PATCH] target/x86: add grub2-bios-setup to DEFAULT_PACKAGES

> 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

Re: [PATCH] build: always set CONFIG_IPV6

p". >> >> 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 > >

Re: [PATCH] build: always set CONFIG_IPV6

> 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.

Re: [PATCH/RFC] kernel-defaults.mk: get rid of BuildID

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

Re: [PATCH/RFC] kernel-defaults.mk: get rid of BuildID

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

Re: [PATCH/RFC] kernel-defaults.mk: get rid of BuildID

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”

Re: [PATCH v2 3/3] realtek: Fix tc default package

> 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

Re: [PATCH] image: let mksquashfs4 use all processors

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

Re: [PATCH v2 3/3] realtek: Fix tc default package

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. > >

Re: Seeking RPM Server package for OpenWrt

> 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

Re: Seeking RPM Server package for OpenWrt

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. >

Feature Freeze

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

Re: imagebuilder for 19.07.9 fails

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

Re: [PATCH] image: let mksquashfs4 use all processors

> 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 wrot

Re: [PATCH] image: let mksquashfs4 use all processors

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

Re: [PATCH 19.07] feeds.conf.default: remove freifunk feed

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

Re: [PATCH] firmware-utils: fix compilation with macOS

> 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. >>> >>>

Re: [PATCH] firmware-utils: fix compilation with macOS

> 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 com

Re: [PATCH 19.07] feeds.conf.default: remove freifunk feed

> 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

OpenWrt 21.02.2 Second service release

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

Re: what stop 21.02.2 and 19.07.9 from offically released?

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,

Re: bcm63xx kernel 5.10

> 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

[RFC] ApkWrt

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

[VOTE CLOSED] Use GitHub issues instead of bugs.openwrt.org

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. > >

Re: Switch issues and CI to GitHub

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

Re: Switch issues and CI to GitHub

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

Re: Switch issues and CI to GitHub

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,

Re: Switch issues and CI to GitHub

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

Re: Switch issues and CI to GitHub

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 > really ha

Re: [PATCH 2/2] devices: Add Cypress CYW43455

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

Status of source-only targets

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 -

Switch issues and CI to GitHub

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

Re: [RFT] Kernels for next release

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

[RFT] Kernels for next release

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

Re: coreutils

> 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

Re: LuCI client certificate authentication

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

Re: [RFC] 21.02.1 backports

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

Re: [PATCH] tools/isl: update the download URL

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

[RFC] 21.02.1 backports

Hi all, Hauke an me plan to tag 21.02.1 this Friday. Motivation is the recent breakage (and fix) of HTTPS secured by Let's Encrypt certificates. More information is available in the commit message[0] of the fix. Please post your backport requests here so we can determine what's possible to

Re: Release goals for 22.XX

Hi Martin, On 10/19/21 7:26 PM, Martin Schiller wrote: On 2021-10-20 04:47, Paul Spooren wrote: For now layerscape is still on 5.4 without Kernel 5.10 support. Is anyone planing to add support? Please reach out. As I had already written on 08 October, I am already working on it. Thereby I

Re: Release goals for 22.XX

On 10/5/21 12:32 PM, camden lindsay wrote: Is - ipq807x  a typo? i don't see this target in the snapshots... is it really ipq806x? many thanks On Tue, Oct 5, 2021 at 3:14 PM Paul Spooren <mailto:m...@aparcar.org>> wrote: Hi all, based on my overview[1] things are movin

Re: Release goals for 22.XX

On 10/9/21 9:57 PM, Russell Senior wrote: "Sergey" == Sergey Ryazanov writes: Sergey> I am in the process of migrating ath25 to the 5.10 Sergey> kernel. Initial build was trivial. But I need to restore the Sergey> Marvel swconfig driver that was lost during the initial 5.10 Sergey> kernel

Re: uml: drop target

On 10/8/21 5:54 AM, Sergey Ryazanov wrote: Hello Paul, thank you for posting this to ML. On Fri, Oct 8, 2021 at 12:05 PM Paul Spooren wrote: as previously posted on GitHub[1] I'd like to remove the UML target since it seems broken, isn't offered by our buildbots and it's purpose

Re: Release goals for 22.XX

Hi, --- %< --- based on my overview[1] things are moving forward and being tested, great! What about the targets that did not see any 5.10 ambitions yet? Specifically: - arc770 - archs38 I just got an email from synopsys and they'll contribute Kernel 5.10 patches for

Re: Release goals for 22.XX - procd-seccomp and procd-ujail

On 10/7/21 8:31 AM, Hauke Mehrtens wrote: On 10/7/21 8:51 AM, Paul Spooren wrote: On 9/29/21 10:28, Hauke Mehrtens wrote: Hi, The OpenWrt 21.02 release is done and we should plan the next release. We already talked about this in the last meeting, see https://openwrt.org/meetings/20210920

uml: drop target

Hi, as previously posted on GitHub[1] I'd like to remove the UML target since it seems broken, isn't offered by our buildbots and it's purpose for testing can be replaced by using qemu. Is anyone here actively using UML and would like to keep it? Best, Paul [1]:

Re: Release goals for 22.XX - procd-seccomp and procd-ujail

On 9/29/21 10:28, Hauke Mehrtens wrote: Hi, The OpenWrt 21.02 release is done and we should plan the next release. We already talked about this in the last meeting, see https://openwrt.org/meetings/20210920 To monitor the current state I created this wiki page based on the wiki page from

Re: Release goals for 22.XX

> On 5. Oct 2021, at 12:33, Robert Marko wrote: > > On Wed, 6 Oct 2021 at 00:08, Paul Spooren wrote: >> >> Hi all, >> >> based on my overview[1] things are moving forward and being tested, >> great! What about the targets that did not see

Re: Release goals for 22.XX

Hi all, based on my overview[1] things are moving forward and being tested, great! What about the targets that did not see any 5.10 ambitions yet? Specifically: - arc770 - archs38 - ath25 - bcm47xx - bcm4908 - ipq807x - layerscape - pistachio - uml Is anyone aware of people working on those

Re: Release goals for 22.XX

On 9/30/21 10:01, Nick wrote: On 9/30/21 21:43, Daniel Golle wrote: On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote: On 30/09/2021 01:19, Nick wrote: On 9/29/21 22:28, Hauke Mehrtens wrote: kernel 5.10: We should get all targets to kernel 5.10. All targets which are not on

Re: [PATCH v2] base-files: restore status of system-services after sysupgrade

On 1/12/21 12:05, Sven Roederer wrote: Am Dienstag, 12. Januar 2021, 13:01:45 CET schrieb Adrian Schmutzler: Hello, You don't have to run such complicated script. Just restore /etc/rc.d/ directory after upgrade. Well, that depends on how we want to deal with new services. If I upgrade from

[PATCH v2 2/2] base-files: reduce number of `mkdir` calls

/` explicitly after subfolders of `/etc/` were already created. Signed-off-by: Paul Spooren --- package/base-files/Makefile | 36 +++- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/package/base-files/Makefile b/package/base-files/Makefile index

[PATCH v2 1/2] base-files: reduce `sed` calls

The `sed`-script shouldn't be called multiple times, especially not with the same files. This commit merges all files together in a single `sed`-script call. Signed-off-by: Paul Spooren --- package/base-files/Makefile | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

[PATCH] README: add download section

The *Firmware Selector* was build to simplify users finding suitable images for their devices. Let's give it more visibility so unleashing your home router becomes an easier thing. Signed-off-by: Paul Spooren --- This is a cross post[1] but since it's quite a public change I want it to have some

Re: [PATCH] base-files: make os-release symbolic link absolute

On 9/9/21 19:53, Florian Eckert wrote: * resolv.conf -> /tmp/resolv.conf * /tmp/TZmtab -> /proc/mounts For consistency, this should also apply to `/usr/lib/os-release`. Is there any other reason than consistency to change this? Yes, I have to elaborate on that. I have a small script that

[PATCH] base-files: reduce `mkdir` and `sed` calls

with partly the same files. Signed-off-by: Paul Spooren --- package/base-files/Makefile | 42 ++--- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/package/base-files/Makefile b/package/base-files/Makefile index 58ad08c63a..af5c0e6b00 100644 --- a/package

Re: [PATCH] base-files: make os-release symbolic link absolute

On 9/8/21 02:50, Florian Eckert wrote: The file `/etc/os-release` is currently a relative link to `../usr/lib/os-release`. The follwing links on my `/etc` are also absolute: * localtime -> /tmp/localtime * resolv.conf -> /tmp/resolv.conf * /tmp/TZmtab -> /proc/mounts For consistency, this

  1   2   3   4   5   6   >