Re: Issues w/ kexec-tools when building images (redux)
Il giorno mer 8 mag 2024 alle ore 00:03 Philip Prindeville via openwrt-devel ha scritto: > > 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. > > > -- Forwarded message -- > From: Philip Prindeville > To: openwrt-devel@lists.openwrt.org > Cc: > Bcc: > Date: Tue, 7 May 2024 16:00:37 -0600 > Subject: Issues w/ kexec-tools when building images (redux) > Hi, > > Sorry, had to add filters to turn DMARC off when sending mailing list mail…. > > I fetched/rebased recently and now I’m not able to build images. It fails in > kexec-tools, which is odd, because that’s not selected and nothing depends on > it. > > philipp@ubuntu22:~/lede$ grep kexec-tools .config > # CONFIG_PACKAGE_kexec-tools is not set > philipp@ubuntu22:~/lede$ > > Here’s how the build reliably fails: > > make[3]: Entering directory '/home/philipp/lede/package/boot/kexec-tools' > rm -f > /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built > touch > /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built_check > make -C /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28 > DESTDIR="/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/ipkg-install" > all install > make[4]: Entering directory > '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' > x86_64-openwrt-linux-musl-gcc -mcmodel=large -I./purgatory/include > -I./purgatory/arch/x86_64/include -I./util_lib/include -I./include -Iinclude > -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-13.2.0_musl/lib/gcc/x86_64-openwrt-linux-musl/13.2.0/include > -c -MD -o purgatory/arch/i386/entry32-16.o purgatory/arch/i386/entry32-16.S > purgatory/arch/i386/entry32-16.S: Assembler messages: > purgatory/arch/i386/entry32-16.S:23: Error: 64bit mode not supported on > `i386'. > make[4]: *** [Makefile:128: purgatory/arch/i386/entry32-16.o] Error 1 > make[4]: Leaving directory > '/home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28' > make[3]: *** [Makefile:133: > /home/philipp/lede/build_dir/target-x86_64_musl/kexec-tools-2.0.28/.built] > Error 2 > make[3]: Leaving directory '/home/philipp/lede/package/boot/kexec-tools' > time: package/boot/kexec-tools/compile#0.23#0.07#0.27 > ERROR: package/boot/kexec-tools failed to build. > make[2]: *** [package/Makefile:129: package/boot/kexec-tools/compile] Error 1 > > I’m building for x86_64/generic on HEAD. > > Any ideas? And who is the maintainer for kexec-tools? > I feel this might be a straight regression from a kernel bump. I monitor the faillogs and kexec-tools appeared only recently... Would be good to understand what commit caused this. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility
Il giorno mar 7 mag 2024 alle ore 18:53 Enrico Mioso ha scritto: > > Hello all!! > > is there any chance we can merge any form of this patch? > The device it is related seems pretty popular and one of the rare devices > supporting VDSL, 35B profile and with nice specs. > Even tough I can understand it is not desirable to maintain this patch > indefinitely should that be the case, I don't think leaving it out of OpenWrt > is the right answer. > Also due to the fact this seems, in my opinion, one of these things that can > act as barrier to entry for a typical setup (at least when VDSL is involved). > > Thanks a lot to all of you for your great work. > For everyone involved, I would really love if we can move here https://github.com/openwrt/openwrt/pull/15421 and test the alternative patch. It does have a different and more restricted approach. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question to recent Qualcomm CVEs
Il giorno mar 30 apr 2024 alle ore 15:04 Kalle Valo ha scritto: > > Robert Marko writes: > > > On Tue, 30 Apr 2024 at 10:48, Kalle Valo wrote: > > > >> > >> Robert Marko writes: > >> > >> > On Mon, 29 Apr 2024 at 15:37, Sven Eckelmann wrote: > >> >> > >> >> On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote: > >> >> > It's quite strange that they updated 2.5.0.1 branch first but my > >> >> > understanding that there should be updates for the newer 2.7.0.1 > >> >> > branch > >> >> > as well (2.7.0.1 branch is also in linux-firmware). > >> >> > >> >> Yes, I also told them in the support ticket that this is from an older > >> >> branch > >> >> than what is currently shipped in linux-firmware.git. But they told me > >> >> that they are working on newer versions (whatever that means) - but they > >> >> wanted to handle first the update to ATH.11.4 (2.5.0.x) and then > >> >> step-by-step release it for newer firmware branches. It seem like that > >> >> would be > >> >> up to 2.9.0.x - no idea why there is no (public) 2.10.x/2.11.x for the > >> >> AP > >> >> SoCs. > >> > > >> > I would like to point out that IPQ6018 doesn't even have anything > >> > newer than 2.5.0.1 available publicly. > >> > >> But I do see WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 for IPQ6018: > >> > >> https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/tree/main/IPQ6018/hw1.0/2.7.0.1/WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1?ref_type=heads > >> > >> And that release seems to be also in linux-firmware: > >> > >> File: ath11k/IPQ6018/hw1.0/q6_fw.mdt > >> Version: WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 > >> > >> Am I missing something? Or did you mean IPQ5018 which only has a release > >> from 2.6.0.1 branch? > >> > >> https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware/-/tree/main/IPQ5018/hw1.0?ref_type=heads > > > > Ah yes, sorry for the confusion, I meant to say newer than 2.5.0.1 > > that actually works. > > All of the newer public FW than 2.5.0.1 that we tried in OpenWrt will > > just crash, we had the same issue with 2.6 and 2.7 FW on > > IPQ8074 and it was fixed in 2.9.0.1 but there is no 2.9.0.1 public for > > IPQ6018. > > Ah, is the issue you are talking about this bug: > > https://bugzilla.kernel.org/show_bug.cgi?id=216515 > > Or is this another issue? > Yes we wasted a good time on that and we concluded that 2.6.0 and 2.7.0 introduced breaking change in how the BDF was parsed that were fixed in 2.9.0 restoring support for legacy BDF. I think almost all ipq60xx suffer from this... Only a Qnap 301 worked with 2.6.0 - 2.7.0 (that was ipq807x) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Issue after changing from xz to zstd
Il giorno sab 6 apr 2024 alle ore 21:46 Hartmut Birr ha scritto: > > Hi, > > I did change the Makefile for dnsmasq in the way that I give: > > PKG_SOURCE_URL:=git://thekelleys.org.uk/dnsmasq.git > PKG_SOURCE_PROTO:=git > PKG_SOURCE_DATE:=2024-03-27 > PKG_SOURCE_VERSION:=550c368adea12b312f83686c61f9015c122046c2# Treat cache > insertion failure of DNSKEY and DS records as another resource problem and > fail validation with suitable logging. > PKG_MIRROR_HASH:=284a34bdb967ec8a9dff132df065ca64e9a1819d79bb8cecee1af001e22d626c > > Before changing to zstd, the generated source tar ball contains a file > 'VERSION' with content '$Format:%d$'. This does match the dnsmasq git > repository. After changing to zstd, VERSION contains ' (HEAD, origin/master, > origin/HEAD, master)'. > > Any idea why VERSION is manipulated? > > I generate automatically a patch which modifies VERSION to see the commit > hash via logread. Applying the patch doesn't work any more. > > dnsmasq/patches/999-dnsmasq-version.patch: > diff --git a/VERSION b/VERSION > index 998eb1f..9977908 100644 > --- a/VERSION > +++ b/VERSION > @@ -1 +1 @@ > -$Format:%d$ > + (master, v2.90deb2-8-g550c368, head) > Hi, thanks for pointing this out, although your situation is special and a downstream situation it was worth investigating it. We confirmed that the change is correct and this is expected and it was actually wrong previously. The format works and requires an associated tag to the commit. Passing an untagged hash results in what you are observing. This is git archive handling and nothing done wrong on our hand. Soo your solution was working due to us doing things in a special way (and ignoring .gitattributes) A more robust solution (and what I'm suggesting you to change), is to make use of the Prepare define and just remove the VERSION file and generate one of your own. It should permit you to make things more maintainable and even remove the downstream patch. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
> On 27/03/2024 10:53, Paul D wrote: > >> lets make a vote > > > > > > So... what's necessary for a vote to start? > > > > Why this insistence on a vote while the discussion is still going on ? > Why this interest in cut other people's opinion while there is stuff to > be discussed and may change others idea. > It is not because a certain direction seems to be the way to go that a > discussion should be abruptly stopped and not let everything that has to > be discussed happen. > > (I fixed the toppost) What is there to discuss? We had this problem from what 4 month now? And there wasn't a single progress on this. Also IMHO there isn't anything to discuss... The thing is simple. Do we accept nickname in SoB or we require Real Name (or something that resemble it?) Also lets not be confused, my intention of doing the vote is to finally take a decision on this and not to cut any kind of discussion or opinion. Indeed I'm just saying, lets discuss on what to vote and just do it instead of continuing this "status-quo". ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
> > > My 2 cent on the problem of permitting nick is that if we accept that, > > some funny guy might use nickname like "ExtraHardCockSucker" > > and we wouldn't have anything to say about it and have to accept > > it if the contribution is correct. > > > > Using Real name prevents that (on 99% of the case) > > Examples of the case are (quoting an italian name) > > "Antonio Bocchino" where bocchino means in italian blowjob... > > It's a funny surname but still less worse than "UltraBoobsLover" kind. > > > > Other project even use an entire google form to make user sign DCO > > and insert all kind of info. > > > > Even though humour is good, nobody is advocating this, nor have I seen > it in the wild. Allowing nicks does not mean that all have to be > allowed. Exercise judgement and common sense. > > My examples were extreme but another nickname of mine is Christo, from Christian and I have read on IRC people that got offended by my profile pic and this nickname... But again mine were just some reason of why I still think real name is the correct way. Honestly I'm still confused what was the big idea on the kernel to permits nickname... Some month ago I had like 6 reviewers that were angry with me using Ansuel Smith instead of my real name (and me having to change the SoB losing at least 3 years of kernel contributions) But again lets make a vote and put and end to this. It's causing more confusion with some commits being accepted and then someone yelling on IRC. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: here we are again: real name 'discussion'
Il giorno mer 27 mar 2024 alle ore 13:33 Paul D ha scritto: > > > a) It's a policy change and not a code change. > > Policy changes require a vote > > Then take a(nother) vote. > Honestly due to the conflicts, lets just take a vote and be done with it. Members seem to participate more so it should not be a problem. My 2 cent on the problem of permitting nick is that if we accept that, some funny guy might use nickname like "ExtraHardCockSucker" and we wouldn't have anything to say about it and have to accept it if the contribution is correct. Using Real name prevents that (on 99% of the case) Examples of the case are (quoting an italian name) "Antonio Bocchino" where bocchino means in italian blowjob... It's a funny surname but still less worse than "UltraBoobsLover" kind. Other project even use an entire google form to make user sign DCO and insert all kind of info. > https://lists.openwrt.org/pipermail/openwrt-devel/2024-January/042063.html > > > > b) Just because the kernel changed their interpretation of DCO > > requirements doesn't mean this automatically applies to OpenWrt > > contribution policy. > > https://openwrt.org/submitting-patches > > > > c) It's completely unclear what the new intended requirements are. > > For whom? Sorry, I do not understand what you're getting at here. > > > The Kernel's "clarification" regarding this topic is *very* vague in my > > opinion. What does "known identity" even mean? Known to whom, and to > > what degree? > > Do not conflate vague with abstract. The thing we care about here is an > email address. Can anyone know it? Yes. Can everyone know it? Yes. Can > two people have an identical email address? No. ( This is distinct from > two people *using* one email address ). > > Lavabit shut down over the FBIs pursuit of a single email address > (namely Snowden). If an email address is good enough for the FBI, it's > good enough for DCO. > > " > A real name does not require a legal name, nor a birth name, nor any > name that appears on an official ID (e.g. a passport). > " > > > > If somebody contributes with his GitHub handle, does that already count > > as known? > > When they're backed by en email address, yes. > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Vote: New member proposal linusw (Linus Walleij)
From: Petr Štetiar Hi, Linus is renowned in the FOSS community primarily for his exceptional contributions to the Linux kernel, where he maintains an impressive array of subsystems, drivers, and architectures. He has been contributing to OpenWrt for about six years already and given that we have been readily embracing his contributions without further scrutiny, I believe it's time to officially invite Linus to join our team. The vote will conclude in 21 days, ending on March 18, 2024. Cheers, Petr --- This is forward also to devel mailing list in case some member missed the vote on adm mailing list. The vote started 2024-02-26. If any member wants to participate please replay to both adm and this mail to prevent any kind of problem by missing votes. The progress on this vote can be tracked here [1]. [1] https://openwrt.org/voting/2024-02-new-member-linusw#stats ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [VOTE] New member proposal: Robimarko (Robert Marko)
> > 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 everything related to IPQ (ipq806x, ipq40xx and > ipq807x) and some mvebu targets. > > He did the conversion of ipq40xx target to DSA and made possible the > introduction of the ipq807x target by sorting all the QSDK downstream > patch and pushing them upstream. > > With his help, also the ipq60xx is very close on getting merged and > actually used permitting support of even more device for OpenWrt. > > Also he is almost always reachable on IRC openwrt-devel and never had > a problem in coordinating and collaborating with him. > > I think Robert is a good addition to our team and would massively help > me (Ansuel) in maintaining each IPQ target and review all the related > PR on github and patchwork. > I would like to add Robert to the OpenWrt committers team. > > The vote shall be concluded within 14 days. (13/02/2024) Vote ended. - 23/40 Participants. Quorum reached. - 23 yes. https://openwrt.org/voting/2024-02-new-member-robimarko All welcomes Robert Marko as a new member of the OpenWrt Team. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: qca8327/qca8337 switch
Il giorno lun 12 feb 2024 alle ore 17:58 e9hack ha scritto: > > Hi, > > it looks like that this commit > > 997acc7f86ca985cba52f7ea8b72f0661a1e3c52 > generic: 6.1: backport at803x split patches > > breaks devices which using a qca8327/qca8337 switch, because the switch > driver is not longer compiled in. > Would be ideal to know what target are we talking about. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?
Il giorno sab 3 feb 2024 alle ore 18:55 Janusz Dziedzic ha scritto: > > sob., 3 lut 2024 o 13:08 Hauke Mehrtens napisał(a): > > > > Hi, > > > > I track the status of the Linux kernel 6.1 migration in this github > > issue: https://github.com/openwrt/openwrt/issues/14546 > > > > There are still many targets on kernel 5.15 without testing support for > > kernel 6.1 in OpenWrt master. I assume that we need at least 4 months to > > get everything to 6.1 and more or less stable. Kernel 6.1 support is > > also missing for some important targets like lantiq, realtek and ramips. > > > > > > Which kernel should we use for the next major OpenWrt release? > > We have two options and I would like to get some feedback on these: > > > > 1. Do the OpenWrt 24.X release with kernel 6.1. Branch off when all or > > most of the targets are on kernel 6.1 by default. > > 2. Do the OpenWrt 24.X release with kernel 6.6. Branch off when all or > > most of the targets are on kernel 6.6 by default. Do not do any stable > > OpenWrt release which supports kernel 6.1. > > > > Doing a OpenWrt release with multiple kernels cases too much maintenance > > effort from my point of view based on previews experience. > > > > > > I think with kernel 6.1 we can branch off at around May 2024. With > > kernel 6.6 we could probably branch off around September 2024. The final > > release will be out about 2 to 4 months later. > > > > Currently OpenWrt releases are about 1.5 years behind the Linux LTS > > releases. When we use kernel 6.1 for the next release we will continue > > to stay 1.5 years behind. When we switch to kernel 6.6 and do not do any > > release with kernel 6.1 we will probably only stay 10 months behind > > Linux LTS kernels. > > > > There is already a PR requiring kernel 6.6: > > https://github.com/openwrt/openwrt/pull/14357 > > > > > > Currently I would prefer to use kernel 6.6 to get closer to the recent > > Linux LTS releases. > > > > 6.6 for sure if possible. > > Just curious - any reason to not support both or even 5.15? And target > could decide about it in mk? > Eg. newest ATH/QCA that base a lot on newest kernel and backports just > could choose it? > For older one we already have work done - so just change generic > patches directory into generic-kernel_ver? > Or this is more work and problems? > We usually try to stick to a common kernel across all target for stable release for consistency and to prevent and handle regression in the generic target. Also it's really a way to force target on getting updated... If it wasn't for this reason we would probably have stuff stuck at 4.19. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?
Il giorno sab 3 feb 2024 alle ore 16:58 Hauke Mehrtens ha scritto: > > On 2/3/24 15:31, Paul D wrote: > > On 2024-02-03 13:06, Hauke Mehrtens wrote: > >> Hi, > >> > >> I track the status of the Linux kernel 6.1 migration in this github > >> issue: https://github.com/openwrt/openwrt/issues/14546 > >> > >> There are still many targets on kernel 5.15 without testing support > >> for kernel 6.1 in OpenWrt master. I assume that we need at least 4 > >> months to get everything to 6.1 and more or less stable. Kernel 6.1 > >> support is also missing for some important targets like lantiq, > >> realtek and ramips. > >> > >> > >> Which kernel should we use for the next major OpenWrt release? > >> We have two options and I would like to get some feedback on these: > >> > >> 1. Do the OpenWrt 24.X release with kernel 6.1. Branch off when all or > >> most of the targets are on kernel 6.1 by default. > >> 2. Do the OpenWrt 24.X release with kernel 6.6. Branch off when all or > >> most of the targets are on kernel 6.6 by default. Do not do any stable > >> OpenWrt release which supports kernel 6.1. > >> > >> Doing a OpenWrt release with multiple kernels cases too much > >> maintenance effort from my point of view based on previews experience. > >> > >> > >> I think with kernel 6.1 we can branch off at around May 2024. With > >> kernel 6.6 we could probably branch off around September 2024. The > >> final release will be out about 2 to 4 months later. > > > > Do a release using 6.6 - although from past experience this means no > > OpenWrt 24. > > > > 6.6 likely means carrying fewer patches also. > > > > Does this give rise to the potential that some older devices get dropped? > > Linux kernel 6.6 will probably be 5% to 10% bigger than Linux kernel 6.1 > as I have seen it between other LTS kernel versions. > > Maintenance of kernel 6.6 will be easier because we have to carry less > patches and we will be closer to upstream. > > I expect that using kernel 6.6 will push out the next release by about 4 > months. I expect that the first target with kernel 6.6 testing support > will be in master in less than 1 month after we decide to use kernel 6.6 > for the next release. > The most problematic target are as usual the one with most downstream patch... So everything brcm and ath79. Mvebu is slow as it seems there is low interest in it but in theory it should be easy to port... For everything IPQ I will take care of migrating all of them. If we decide for 6.6 we will have the situation of having 3 kernel version? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[VOTE] New member proposal: Robimarko (Robert Marko)
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 everything related to IPQ (ipq806x, ipq40xx and ipq807x) and some mvebu targets. He did the conversion of ipq40xx target to DSA and made possible the introduction of the ipq807x target by sorting all the QSDK downstream patch and pushing them upstream. With his help, also the ipq60xx is very close on getting merged and actually used permitting support of even more device for OpenWrt. Also he is almost always reachable on IRC openwrt-devel and never had a problem in coordinating and collaborating with him. I think Robert is a good addition to our team and would massively help me (Ansuel) in maintaining each IPQ target and review all the related PR on github and patchwork. I would like to add Robert to the OpenWrt committers team. The vote shall be concluded within 14 days. (13/02/2024) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: packet captures of sony's new 80Mbit service?
> > Anyone got a ps4 or ps5 and can take a packet capture at their router? > Dying to know if it is cubic or bbr in particular > > https://entertainment.slashdot.org/story/23/10/05/154219/sonys-high-bitrate-movie-service-is-now-available-on-ps5-and-ps4 > 80 mbps oh boy... the dream for correct streaming of content ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
