Hi
On 2023-11-14, Elliott Mitchell wrote:
> On Wed, Nov 15, 2023 at 05:35:11AM +0100, Stefan Lippers-Hollmann wrote:
> > On 2023-11-14, Elliott Mitchell wrote:
[...]
> > What would be the reason for enabling x32?
> > There is very little upstream buy-in for x32, when this question came
> > up for
On Wed, Nov 15, 2023 at 05:35:11AM +0100, Stefan Lippers-Hollmann wrote:
>
> On 2023-11-14, Elliott Mitchell wrote:
> > Date: Thu, 30 Mar 2023 16:30:49 -0700
> >
> > Full amd64 support isn't really appropriate for most situations
> > OpenWRT is deployed. Whereas x86-x32 seems extremely
On Wed, Nov 15, 2023 at 05:05:00AM +0100, Stefan Lippers-Hollmann wrote:
>
> On 2023-11-14, Elliott Mitchell wrote:
> > Date: Thu, 13 Apr 2023 17:07:20 -0700
> >
> > The SCx200 is part of the Geode platform. As such generic x86
> > doesn't need the driver, but Geode does.
>
> Not objecting
Hi
On 2023-11-15, Stefan Lippers-Hollmann wrote:
> On 2023-11-14, Elliott Mitchell wrote:
> > Date: Thu, 30 Mar 2023 16:30:49 -0700
> >
> > Full amd64 support isn't really appropriate for most situations
> > OpenWRT is deployed. Whereas x86-x32 seems extremely appropriate for
> > these
Hi
On 2023-11-14, Elliott Mitchell wrote:
> Date: Thu, 30 Mar 2023 16:30:49 -0700
>
> Full amd64 support isn't really appropriate for most situations
> OpenWRT is deployed. Whereas x86-x32 seems extremely appropriate for
> these situations. As such enable x86-x32 support.
>
>
Hi
On 2023-11-14, Elliott Mitchell wrote:
> Date: Thu, 13 Apr 2023 17:07:20 -0700
>
> The SCx200 is part of the Geode platform. As such generic x86
> doesn't need the driver, but Geode does.
Not objecting against this patch, just taking it as an opportunity to ask
an orthogonal question...
Are
> Le 14 nov. 2023 à 18:06, Petr Štetiar a écrit :
>
> Thibaut [2023-11-14 14:25:50]:
>
>> I’m sorry, I must have missed the part where we advertised that master
>> snapshots are a maintained 'release' suitable for use in a
>> security-conscious context :)
>
> There is no difference
Thibaut [2023-11-14 14:25:50]:
> I’m sorry, I must have missed the part where we advertised that master
> snapshots are a maintained 'release' suitable for use in a
> security-conscious context :)
There is no difference actually, it applies to all branches/releases, so it
really
doesn't matter
On 11/13/23 21:49, Daniel Golle wrote:
On Mon, Nov 13, 2023 at 07:54:34PM +, Petr Štetiar wrote:
Paul Spooren [2023-11-13 13:30:10]:
Hi,
How about we follow the approach of Alpine Linux[1] and offer a standard, an
extended and a virtual firmware for the x86/64 target?
FYI that pull
Hi,
> Le 14 nov. 2023 à 13:25, Petr Štetiar a écrit :
>
> Thibaut [2023-11-14 10:24:28]:
>
> Hi,
>
>> I don’t follow, what do security fixes have to do with snapshot builds?
>
> OpenWrt builds and deliver package fixes continuosly from the snapshot builds.
>
>> I don’t expect users (that
David Bauer [2023-11-14 10:02:36]:
Hi,
> Is there already a patch series / PR in the works?
AFAIK there is just PR #13924 attempting to workaround #13886
> Otherwise, I'd look into that.
Great, thanks!
Cheers,
Petr
___
openwrt-devel mailing list
Thibaut [2023-11-14 10:24:28]:
Hi,
> I don’t follow, what do security fixes have to do with snapshot builds?
OpenWrt builds and deliver package fixes continuosly from the snapshot builds.
> I don’t expect users (that includes myself) to keep constantly looking at
> the git history to find
> Le 14 nov. 2023 à 09:59, Petr Štetiar a écrit :
>
> Thibaut [2023-11-13 22:20:28]:
>
> Hi,
>
>> GitPoller accepts a single poll interval. What you’re suggesting would
>> require separating each branch, i.e. returning to the previous situation.
>
> IIUC then you can have multiple
Hi Daniel,
Hi Petr,
On 11/13/23 21:49, Daniel Golle wrote:
On Mon, Nov 13, 2023 at 07:54:34PM +, Petr Štetiar wrote:
Paul Spooren [2023-11-13 13:30:10]:
Hi,
How about we follow the approach of Alpine Linux[1] and offer a standard, an
extended and a virtual firmware for the x86/64
Thibaut [2023-11-13 22:20:28]:
Hi,
> GitPoller accepts a single poll interval. What you’re suggesting would
> require separating each branch, i.e. returning to the previous situation.
IIUC then you can have multiple GitPoller instances, so wouldn't something
along this lines work?
> On Nov 13, 2023, at 10:44 PM, Elliott Mitchell wrote:
>
> On Tue, Nov 14, 2023 at 03:44:57AM +, Daniel Golle wrote:
>> On Mon, Nov 13, 2023 at 06:26:04PM -0800, Elliott Mitchell wrote:
>>> On Mon, Nov 13, 2023 at 12:48:14PM +, Daniel Golle wrote:
On Mon, Nov 13, 2023 at
On Tue, Nov 14, 2023 at 03:44:57AM +, Daniel Golle wrote:
> On Mon, Nov 13, 2023 at 06:26:04PM -0800, Elliott Mitchell wrote:
> > On Mon, Nov 13, 2023 at 12:48:14PM +, Daniel Golle wrote:
> > > On Mon, Nov 13, 2023 at 01:30:10PM +0100, Paul Spooren wrote:
> > > >
> > > > How about we
> On Nov 13, 2023, at 7:26 PM, Elliott Mitchell wrote:
>
> On Mon, Nov 13, 2023 at 12:48:14PM +, Daniel Golle wrote:
>> On Mon, Nov 13, 2023 at 01:30:10PM +0100, Paul Spooren wrote:
>>>
>>> How about we follow the approach of Alpine Linux[1] and offer a standard,
>>> an extended and a
On Mon, Nov 13, 2023 at 06:26:04PM -0800, Elliott Mitchell wrote:
> On Mon, Nov 13, 2023 at 12:48:14PM +, Daniel Golle wrote:
> > On Mon, Nov 13, 2023 at 01:30:10PM +0100, Paul Spooren wrote:
> > >
> > > How about we follow the approach of Alpine Linux[1] and offer a standard,
> > > an
On Mon, Nov 13, 2023 at 12:48:14PM +, Daniel Golle wrote:
> On Mon, Nov 13, 2023 at 01:30:10PM +0100, Paul Spooren wrote:
> >
> > How about we follow the approach of Alpine Linux[1] and offer a standard,
> > an extended and a virtual firmware for the x86/64 target?
> >
> > What packages
On Mon, 13 Nov 2023 at 22:21, Thibaut wrote:
>
>
>
> > Le 13 nov. 2023 à 21:32, Petr Štetiar a écrit :
> >
> > Thibaut [2023-11-13 17:26:44]:
> >
> > Hi,
> >
> >> In any case, another way to tackle this problem would be to switch from
> >> continuous builds that starve the build resources to
> Le 13 nov. 2023 à 21:32, Petr Štetiar a écrit :
>
> Thibaut [2023-11-13 17:26:44]:
>
> Hi,
>
>> In any case, another way to tackle this problem would be to switch from
>> continuous builds that starve the build resources to periodic builds that
>> don’t (e.g. once a week),
>
> other
On Mon, Nov 13, 2023 at 07:54:34PM +, Petr Štetiar wrote:
> Paul Spooren [2023-11-13 13:30:10]:
>
> Hi,
>
> > How about we follow the approach of Alpine Linux[1] and offer a standard,
> > an extended and a virtual firmware for the x86/64 target?
>
> FYI that pull request added 27 firmware
Thibaut [2023-11-13 17:26:44]:
Hi,
> In any case, another way to tackle this problem would be to switch from
> continuous builds that starve the build resources to periodic builds that
> don’t (e.g. once a week),
other options:
* add more build workers :-)
* use different GitPoller polling
Paul Spooren [2023-11-13 13:30:10]:
Hi,
> How about we follow the approach of Alpine Linux[1] and offer a standard, an
> extended and a virtual firmware for the x86/64 target?
FYI that pull request added 27 firmware ASIC blobs, thus increased x86/64
image from 10 MiB to 41 MiB, but actually
Hi,
> Le 13 nov. 2023 à 16:55, Hannu Nyman a écrit :
>
> Looks like the release branches might have a too strong priority in the
> combined image buildbot, so that release branches get always built before the
> development main/master.
>
> Recently there has been a steady flow of mostly
On Mon, Nov 13, 2023 at 01:30:10PM +0100, Paul Spooren wrote:
> Hi all,
>
> How about we follow the approach of Alpine Linux[1] and offer a standard, an
> extended and a virtual firmware for the x86/64 target?
>
> What packages specifically is another discussion but the approach could be
>
Hi all,
How about we follow the approach of Alpine Linux[1] and offer a standard, an
extended and a virtual firmware for the x86/64 target?
What packages specifically is another discussion but the approach could be that
standard contains all kmods to get network working on all device, extended
> On Sep 14, 2023, at 5:19 PM, Stefan Lippers-Hollmann wrote:
>
> 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
> On Sep 14, 2023, at 5:19 PM, Stefan Lippers-Hollmann wrote:
>
> Hi
>
> On 2023-09-14, Paul Spooren wrote:
>> 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.
On 11/12/23 20:16, Rosen Penev wrote:
On Sat, Nov 11, 2023 at 1:35 PM Hauke Mehrtens wrote:
This adds support for compiling the code against Mbed TLS 3.0.0.
It still compiles against Mbed TLS 2.28.
The following changes were needed:
* DES and 3DES was removed
*
On Fri, Nov 10, 2023 at 1:31 AM Shiji Yang wrote:
>
> From: Shiji Yang
>
> ASCII MAC address can be handled by nvmem "fixed-layout" now. And all
> related devices were converted to the new "mac-base" layout format.
> It's time to remove this hack.
>
> Signed-off-by: Shiji Yang
Reviewed-by:
On Sat, Nov 11, 2023 at 1:35 PM Hauke Mehrtens wrote:
>
> This adds support for compiling the code against Mbed TLS 3.0.0.
> It still compiles against Mbed TLS 2.28.
>
> The following changes were needed:
> * DES and 3DES was removed
> * mbedtls_pk_context->pk_info is private, use
On Fri, Nov 10, 2023 at 2:27 AM Rafał Miłecki wrote:
>
> From: Rafał Miłecki
>
> Those devices have Ethernet interfaces using base MAC address increased
> by 0x40 in the 3rd indexed byte (00:00:00:FF:00:00). To describe that we
> were using a custom (downstream) "mac-address-increment-byte"
On Sat, Nov 11, 2023 at 1:35 PM Hauke Mehrtens wrote:
>
> Make the linking of the shared library fail when undefined symbols are
> used. Linking undefined symbols in a shared library normally works and
> the linking of the binary using the shared library fails. We also
> compile some example
Felix Fietkau kirjoitti 10.11.2023 klo 16.38:
On 10.11.23 15:21, e9hack wrote:
Too fast. I did reboot with the old version again. The patched version
does work.
Fix pushed, thanks for testing!
- Felix
Thanks,
I tested the current netifd with the fix, and it seems to work ok, again.
On 10.11.23 15:21, e9hack wrote:
Too fast. I did reboot with the old version again. The patched version does
work.
Fix pushed, thanks for testing!
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Too fast. I did reboot with the old version again. The patched version does
work.
Sorry!
Regards,
Hartmut
Am 10.11.2023 um 15:09 schrieb e9hack:
Sorry, but it doesn't solve the issue.
Regards,
Hartmut
Am 10.11.2023 um 14:13 schrieb Felix Fietkau:
I think I found the cause of this
Sorry, but it doesn't solve the issue.
Regards,
Hartmut
Am 10.11.2023 um 14:13 schrieb Felix Fietkau:
I think I found the cause of this regression while looking at the code
again. It seems that the hotplug-added devices are removed too early
based on DEV_EVENT_REMOVE events.
Please try this
Hi Rafal
Your patches for our Dorin & Balin modules are good, many thanks.
You can push the patches upstream.
Best regards & have a nice weekend
Catrinel
-Original Message-
From: Rafał Miłecki
Sent: Friday, 10 November 2023 11:25
To: openwrt-devel@lists.openwrt.org
Cc:
On 10.11.23 13:59, Felix Fietkau wrote:
On 09.11.23 22:31, Hannu Nyman wrote:
e9hack kirjoitti 9.11.2023 klo 17.32:
I face a strange behaviour since commit
516ab774cc16d4b04b3b17a067cbf2649f1adaeb (system-linux: fix race condition
on bringing up wireless devices). After a reboot or a full
On 09.11.23 22:31, Hannu Nyman wrote:
e9hack kirjoitti 9.11.2023 klo 17.32:
I face a strange behaviour since commit
516ab774cc16d4b04b3b17a067cbf2649f1adaeb (system-linux: fix race condition
on bringing up wireless devices). After a reboot or a full restart of
hostapd via 'wifi down; sleep
On Nov. 10, 2023, 9:46 a.m., Rafał Miłecki wrote:
>On 2023-11-10 10:41, Shiji Yang wrote:
>> From: Shiji Yang
>>
>> This patch allow user to perform basic bitwise clear/set operation on
>> OF DT MAC address. We use two new added dt-bindings to specific the
>> MAC address bits clear/set mask.
On 2023-11-10 10:41, Shiji Yang wrote:
From: Shiji Yang
This patch allow user to perform basic bitwise clear/set operation on
OF DT MAC address. We use two new added dt-bindings to specific the
MAC address bits clear/set mask. "mac-address-bitwise-set" can be used
to set bit. And
On 2023-11-10 10:28, Shiji Yang wrote:
From: Shiji Yang
ASCII MAC address can be handled by nvmem "fixed-layout" now. And all
related devices were converted to the new "mac-base" layout format.
It's time to remove this hack.
Oh, I was hoping for that for a long time. Looks great.
--
Rafał
e9hack kirjoitti 9.11.2023 klo 17.32:
I face a strange behaviour since commit
516ab774cc16d4b04b3b17a067cbf2649f1adaeb (system-linux: fix race condition
on bringing up wireless devices). After a reboot or a full restart of
hostapd via 'wifi down; sleep 30; killall hostapd; sleep 5; wifi', only
Hi,
> Le 7 nov. 2023 à 23:25, Rafał Miłecki a écrit :
>
> From: Rafał Miłecki
>
> Allow selecting KERNEL_SLUB_DEBUG and KERNEL_SLUB_DEBUG_ON manually and
> provide detailed help for both.
>
> Signed-off-by: Rafał Miłecki
> ---
> config/Config-kernel.in | 15 +--
> 1 file changed,
lip Prindeville
> Sent: Saturday, October 28, 2023 11:09 AM
> To: Xiaojun Liu
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH] x86 64: Add new device Cordoba Edge Platform
>
> LGTM
>
>
>> On Oct 23, 2023, at 8:52 PM, Xiaojun Liu wrote:
>>
>>
> On Oct 30, 2023, at 11:17 AM, Paul Spooren wrote:
>
> 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.
>
Hi Matt,
> Does the Renesas/RZ U-boot have EFI support enabled ('bootefi' command)?
> Could you try an armsr/armv8 image and see if it boots?
I've just tried:
=> fatload mmc 1:1 0x4800 openwrt-armsr-armv8-generic-initramfs-kernel.bin
32223744 bytes read in 2669 ms (11.5 MiB/s)
=> bootefi
Torsten,
> The question then is: are they similar enough to build from one kernel
> source, or will they require different sets of patches?
RZ includes different subseries, as of today: RZ/G, RZ/V and some new
RZ/T run Linux.
Renesas official SW package is based on the CIP Linux, even though the
Hi Michele,
On Fri, 3 Nov 2023 09:04:08 +0100
Michele Bisogno wrote:
> > is able to handle that at this folder level. Much of the above is
> > "legacy" and does not run OpenWRT(?), but they also seem to aim for
> > Risc-V. There is a platform called "ramips" and the broadcoms each
> > have
> Renesas offers different architectures in their portfolio[1], I haven't
> dug into the OpenWRT build system for this issue yet to tell whether it
> is able to handle that at this folder level. Much of the above is
> "legacy" and does not run OpenWRT(?), but they also seem to aim for
> Risc-V.
> 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
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
On Mon, 30 Oct 2023 21:40:02 +0100
Robert Marko wrote:
> On Mon, 30 Oct 2023 at 10:40, Michele Bisogno
> wrote:
> >
> > Hi,
> >
> > I've been a happy OpenWRT user for many years now, always buying
> > routers that could allow me to run it easily.
Same here :-)
[...]
> >
> > For example,
Hi Matt,
> Does the Renesas/RZ U-boot have EFI support enabled ('bootefi' command)?
> Could you try an armsr/armv8 image and see if it boots?
It does support it but I have never tried it.
> (You will need to start U-Boot from qspi or sd card and OpenWrt from a USB or
> different sd card)
>
>
Hi Michele,
On Mon, Oct 30, 2023, at 8:39 PM, Michele Bisogno wrote:
> Hi,
>
> I've been a happy OpenWRT user for many years now, always buying
> routers that could allow me to run it easily.
>
> I've been working (actually only in my free time as a hobby) on
> porting OpenWRT onto this Renesas
On Tue, 31 Oct 2023 at 10:06, Robert Marko wrote:
>
> To me, the most sense would be to provide one or 2 boards as part of the
> initial
> target but with multiple boot options supported so later boards can be
> easily added.
>
> Personally, GH PR-s are rather good for adding new stuff as it
On Tue, 31 Oct 2023 at 09:56, Michele Bisogno wrote:
>
> Hi Robert,
>
> thanks for the encouragement.
> I'll go for plain "renesas" then.
>
> I am a bit hesitating on when / how to submit patches.
> At the moment the image generated is for the sd card (similar to
> Raspberry Pi) and for a single
Hi,
On Mon, 30 Oct 2023 at 23:11, Hauke Mehrtens wrote:
>
> This fixes compilation with glibc.
>
> _FORTIFY_SOURCE only works with compiler optimizations activated.
> We have to deactivate it when we set -O0.
>
> This fixes the following error message with glibc:
> error: #warning
Hi Robert,
thanks for the encouragement.
I'll go for plain "renesas" then.
I am a bit hesitating on when / how to submit patches.
At the moment the image generated is for the sd card (similar to
Raspberry Pi) and for a single device (RZ/G2L)
However I am planning to support more boot memories
Hi,
Thank you for your guide!
I will resubmit it.
-Original Message-
From: Paul Spooren
Sent: Tuesday, October 31, 2023 1:18 AM
To: Xiaojun Liu
Cc: Philip Prindeville ; openwrt-devel
Subject: Re: [PATCH] x86 64: Add new device Cordoba Edge Platform
Hi,
We kind of don’t add image
On Mon, 30 Oct 2023 at 10:40, Michele Bisogno wrote:
>
> Hi,
>
> I've been a happy OpenWRT user for many years now, always buying
> routers that could allow me to run it easily.
Hi, nice to hear this.
>
> I've been working (actually only in my free time as a hobby) on
> porting OpenWRT onto
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
Hi Philip,
Thank you! Do you know when it will be merged to Openwrt main thread ?
-Original Message-
From: Philip Prindeville
Sent: Saturday, October 28, 2023 11:09 AM
To: Xiaojun Liu
Cc: openwrt-devel@lists.openwrt.org
Subject: Re: [PATCH] x86 64: Add new device Cordoba Edge Platform
On Sun, Oct 29, 2023 at 07:25:38AM +0200, Stijn Tintel wrote:
> On 24/10/2023 15:25, Christian Marangi wrote:
> > On Tue, Oct 24, 2023 at 02:21:35PM +0200, Bjørn Mork wrote:
> >> Christian Marangi writes:
> >>
> >>> Anyway I have also found this [1]... if it does actually works, it might
> >>>
On 24/10/2023 15:25, Christian Marangi wrote:
On Tue, Oct 24, 2023 at 02:21:35PM +0200, Bjørn Mork wrote:
Christian Marangi writes:
Anyway I have also found this [1]... if it does actually works, it might be
THE solution to our specific problem. Wonder if someone can test it on a
sample
On 28/10/2023 20:03, Paul D wrote:
Hi, maybe some housekeeping process is nececssary, but I got this
immediately after I did the usually recommended checkout procedures,
and have been even after a git pull, every time I run make.
The prce package was moved from the base repo to the packages,
Philip Prindeville wrote:
> Thought I sent this earlier but I see no trace of it, so here goes again.
> Here it is again with the link to the build and the extracted logs from one
> of the failing builds:
> https://github.com/openwrt/packages/actions/runs/6629645917/job/18009391257?pr=22359
>
LGTM
> On Oct 23, 2023, at 8:52 PM, Xiaojun Liu wrote:
>
> Add new device Cordoba Edge Platform
> Device name:Cordoba Edge Platform
> hardware specifications: CPU - Intel Atom C3000
> WiFi - mt7915e
>
> Signed-off-by: Xiaojun Liu mailto:xiaojun@silicom.co.il
>
Thought I sent this earlier but I see no trace of it, so here goes again.
Here it is again with the link to the build and the extracted logs from one of
the failing builds:
https://github.com/openwrt/packages/actions/runs/6629645917/job/18009391257?pr=22359
CFLAGS="-Os -pipe -mcpu=8548
On Tue, Oct 24, 2023 at 02:21:35PM +0200, Bjørn Mork wrote:
> Christian Marangi writes:
>
> > Anyway I have also found this [1]... if it does actually works, it might be
> > THE solution to our specific problem. Wonder if someone can test it on a
> > sample repository.
> >
> > [1]
Pfendtner Steffen [2022-10-18 14:38:56]:
Hi,
> We decided to publish our internal fork of the Timesys SBOM Tool we found on
> github. You find our version at: https://github.com/ads-tec/sbom-openwrt
thanks for sharing!
BTW I took that output and drafted first version[1] by extending current
Roger-
Good idea. I think I may have been running firmware for a different
device (E-320N, probably - it appears to have been the base design for
several of their products).
I was hoping you (or someone) could look at the log and say, "Hey, I
know what that is..."
Worth a shot...
Next step -
On Wed, Oct 25, 2023 at 11:31 AM Christian Marangi wrote:
> Hi, I merged this series on main.
Thanks Christian! (I hope it doesn't explode...)
> I hope to have followup for the firmware (hoping it will ever be
> accepted upstream)
Yeah I am working on that.
> and for the hotplug script for
On Mon, Oct 23, 2023 at 08:43:02AM +0200, Linus Walleij wrote:
> XP4xx was deleted because of lack of maintenance in 2020.
>
> In the years since, the upstream Linux support for IXP4xx has
> been rewritten from scratch. It is now pretty well supported
> using device tree and modern subsystems
On Tue, Oct 24, 2023 at 02:25:06PM +0200, Christian Marangi wrote:
> On Tue, Oct 24, 2023 at 02:21:35PM +0200, Bjørn Mork wrote:
> > Christian Marangi writes:
> >
> > > Anyway I have also found this [1]... if it does actually works, it might
> > > be
> > > THE solution to our specific problem.
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi, Bill,
I have a couple of
W dniu 23.10.2023 o 08:43, Linus Walleij pisze:
> This resurrects the support for IXP4xx using device tree
> rather than the old (deleted) board files. The final pieces
> of IXP4xx board files were deleted in Linux v5.19.
>
> Ext4 root filesystems on CF and USB are supported by the
> default
On Tue, 24 Oct 2023 at 17:46, Philip Prindeville
wrote:
>
> Hi,
>
> I'm seeing the following:
>
> https://github.com/openwrt/packages/actions/runs/6621741418/job/17986176198?pr=22362
>
> Specifically:
>
> mips-openwrt-linux-musl-gcc -shared -o libcligen.so.6.4 cligen_object.o
> cligen_callback.o
On Tue, Oct 24, 2023 at 02:21:35PM +0200, Bjørn Mork wrote:
> Christian Marangi writes:
>
> > Anyway I have also found this [1]... if it does actually works, it might be
> > THE solution to our specific problem. Wonder if someone can test it on a
> > sample repository.
> >
> > [1]
Christian Marangi writes:
> Anyway I have also found this [1]... if it does actually works, it might be
> THE solution to our specific problem. Wonder if someone can test it on a
> sample repository.
>
> [1] https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904
Nice! Seems to work.
On Tue, Oct 24, 2023 at 01:40:22PM +0200, Bjørn Mork wrote:
> Ack on the broken history problem.
>
> I don't think it's necessary to keep two separate histories though. The
> main issue is the periodical removal of files keeping parts of history,
> resulting in an increasing number of file names
Ack on the broken history problem.
I don't think it's necessary to keep two separate histories though. The
main issue is the periodical removal of files keeping parts of history,
resulting in an increasing number of file names to follow for the
complete history.
Doing
git mv config-5.15
Thanks for your reminding! I will update my patch to fix these issues.
-Original Message-
From: Philip Prindeville
Sent: Monday, October 23, 2023 1:05 PM
To: Xiaojun Liu
Cc: openwrt-devel@lists.openwrt.org
Subject: Re: Subject: [PATCH] x86 64: Add new device Cordoba Edge Platform
Doesn't this just have ixgbe and igc NIC's? And the mt7915e of course.
Don't think we need the amd-xgbe, bnx2, e1000e, e1000, r8169, tg3 drivers.
The BIOS we've been using has some odd enumeration of the PCI bus, so you might
want to include a patch for
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello Hauke,
On 10/22/23 17:53,
Cc Felix's correct address. Sorry for the noise!
Best,
Sander
On Sun, 2023-10-22 at 17:51 +0200, Sander Vanheule wrote:
> jshn stores a JSON file in the shell environment using a set of
> variable, using the key to an object in the shell variable name. This
> restricts the allowed character set
On 10/22/23 12:31, Alexis Lothoré wrote:
From: Alexis Lothoré
Kernel 6.1 has introduced support for RTW8822BU network adapter, which
is an USB variant of the rtw8822b 802.11ac chipset family.
Build and install the corresponding module in the rtw88 package
Signed-off-by: Alexis Lothoré
---
On Fri, Oct 20, 2023 at 2:52 PM Christian Marangi wrote:
> On Fri, Oct 20, 2023 at 02:48:33PM +0200, Linus Walleij wrote:
> > On Fri, Oct 20, 2023 at 2:32 PM Christian Marangi
> > wrote:
> >
> > > Yes! Would be ideal then we can just bump the linux-firmware package and
> > > reference it there.
On Fri, Oct 20, 2023 at 02:48:33PM +0200, Linus Walleij wrote:
> On Fri, Oct 20, 2023 at 2:32 PM Christian Marangi
> wrote:
>
> > Yes! Would be ideal then we can just bump the linux-firmware package and
> > reference it there.
>
> OK I'll try this.
>
> > What would happen to the additional
On Fri, Oct 20, 2023 at 2:32 PM Christian Marangi wrote:
> Yes! Would be ideal then we can just bump the linux-firmware package and
> reference it there.
OK I'll try this.
> What would happen to the additional source tho? Would it be included in
> the submitted fw?
Yes there are several
On Fri, Oct 20, 2023 at 02:26:30PM +0200, Linus Walleij wrote:
> On Fri, Oct 20, 2023 at 1:33 PM Christian Marangi
> wrote:
> > On Fri, Oct 20, 2023 at 01:15:51PM +0200, Linus Walleij wrote:
>
> > > If there is some rough consensus on this, could someone start
> > > applying these patches,
On Fri, Oct 20, 2023 at 1:33 PM Christian Marangi wrote:
> On Fri, Oct 20, 2023 at 01:15:51PM +0200, Linus Walleij wrote:
> > If there is some rough consensus on this, could someone start
> > applying these patches, apart from patch 10/10 where we might
> > want to do something different?
> >
>
On Fri, Oct 20, 2023 at 01:15:51PM +0200, Linus Walleij wrote:
> If there is some rough consensus on this, could someone start
> applying these patches, apart from patch 10/10 where we might
> want to do something different?
>
I started to merge the first trivial patch that just adds packages and
On Thu, Oct 12, 2023 at 10:42:21AM +0200, Linus Walleij wrote:
> The firmware package for the IXP4xx microcode was deleted but
> the source files are still in the file cache so we can easily
> resurrect it.
>
> The firmware either supports ethernet (the most common) or
> WAN (less common), image
If there is some rough consensus on this, could someone start
applying these patches, apart from patch 10/10 where we might
want to do something different?
If no-one is willing to shepherd IXP4xx I am willing to do commits
but that requires commit access, and I don't think I can
self-nominate for
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Em 16/10/2023 04:32, Bjørn Mork
Hi, that was my mistake - sorry!
Thanks for finding and fixing it :-)
I keep accidentally tapping the R key when jumping over words (E) for some
reason.
"Purging the r's" is something I do quite regularly.
But a 't'? :-D
Regarding the detection of such mistakes:
To retain alphabetical
701 - 800 of 34436 matches
Mail list logo
