<Grommish>
Slimey: Ah, neggles decided on a fractal pattern for whatever reason :) (probably because he could).. it's a test package for verifying rust-lang on a target
<Slimey>
lol oh
atomiclycursed has joined #openwrt-devel
minimal has quit []
grid has joined #openwrt-devel
atomiclycursed has quit [Remote host closed the connection]
<Pepes>
Ok, I will do. I didn't want to annoy anyone with my email that's why I mentioned hauke directly on GH
<ynezz>
I would normally merge them, but AFAIK hauke plans to tag 21.02.2 today if the builds looks good, so don't want to delay it with more merges
<neggles>
Grommish: yay!
<mangix>
hmm sounds like ksmbd's not going to get merged then
Misanthropos has quit [Ping timeout: 480 seconds]
<f00b4r0>
jow: ping?
<neggles>
ynezz: 5.15 is definitely the next LTS, it's always the last release of the calendar year, and it will be the kernel for ubuntu 22.04 which more than meets gregkh's annoying noncommittal requirements
goliath has quit [Quit: SIGSEGV]
<neggles>
Slimey: yeah i just ganked some code i found in a gist, fractals were the first-ish thing that came to mind for "what needs floats"
<ynezz>
Pepes: I've just reviewed that PR#5043, what's the other one, I can't see it tagged with 21.02
<Pepes>
ynezz: Thanks! There is no PR for mac80211 since hauke is doing some magic (just kidding) in the official repository: https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.git/ so it is a question if adding patches to OpenWrt is better or even reach Hauke how it is possible to help him on this one with some Wi-Fi highlighted issues
<Pepes>
and then just simply bump the version
eduardo010174 has joined #openwrt-devel
slh has quit [Ping timeout: 480 seconds]
slh64 has quit [Ping timeout: 480 seconds]
slh has joined #openwrt-devel
slh64 has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
<jow>
I really don't get the reason why apk imposes such strict version format requirements
robimarko has joined #openwrt-devel
<jow>
it's a little bit as if they want to enforce packages to adopt semantic versioning
<aparcar>
jow: I'll ask but your guess seems right, semantic versioning could be the goal
<robimarko>
Borromini: Just saw that you had questions about RB5009 yesterday
<jow>
(the strcmp() each part was too simple, the shorter token has to be leading-zero-padded to the length of the longer one, so "99" vs. "100" becomes "099" vs. "100"
<aparcar>
jow: how do we teach apk that `master` is bigger than `21`?
<jow>
otherwise 99 > 100
<robimarko>
We have a patched RouterBoot with enabled UART, so that can be flashed using jailbroken ROS, via CH341A or you can boot it via XMODEM on UART
<jow>
aparcar: strcmp("master", "000021") > 0
<neggles>
jow: it checks the tokens individually, so it'd be 99.99, which has the benefit of never being a valid version
<jow>
neggles: yeah and why should I use a version that is not a valid version
<neggles>
however
<neggles>
that's interesting
<neggles>
apk version -t master.21.02.22025.79016 master.99.99.22025.79016 reports =
<jow>
lilely because internally invalid == invalid
<neggles>
nup, it prints nothing if it's invalid
<neggles>
i think? i should be checking exit codes
<aparcar>
neggles: so it's broker overall...
<neggles>
not quite
<aparcar>
try version --check
<neggles>
ah yes
<neggles>
invalid
<neggles>
thankyou
<neggles>
so if you put
<neggles>
_git
<neggles>
at the end of the version number it ignores everything that comes after
<neggles>
ah not quite
<neggles>
i think the idea is that you set the version of git packages to <your next major version>_alpha<some monotonically incrementing thing>
<neggles>
aparcar / jow: perhaps use XX.13.YYDDD.SSSSS for master builds? it will read higher than any YY.MM.P.YYDDD.SSSSS build (from a release) but could be problematic if there's more than one release in a year (unlikely?)
<stintel>
are there any WiFi6 USB adapters with Linux + monitor mode support?
gladiac has quit [Quit: k thx bye]
<rsalvaterra>
stintel: Do you want a unicorn to go with that? :)
gladiac has joined #openwrt-devel
<rsalvaterra>
Tough combination…
<stintel>
nbd: if qosify_dscp_default[2] = { 0xff, 0xff } and I do not have dscp_default_tcp set, how come all non-specified ports are using DSCP value 144 in /sys/fs/bpf/qosify_data/tcp_ports ?
<stintel>
a few reboots down the line again hitting [ 39.841573] jffs2: cannot read OOB for EB at 01ea0000, requested 8 bytes, read 0 bytes, error -77
<stintel>
so did nobody ever hit this yet because pure luck?
<stintel>
in a previous boot I saw this: [ 37.578144] jffs2: warning: (2251) jffs2_sum_write_data: Not enough space for summary, padsize = -990
reiffert has quit [Ping timeout: 480 seconds]
<ynezz>
hauke: while working on wolfssl version bump for 19.07 I've noticed, that ustream-ssl isn't ABI version aware in master/19.07/21.02 and I'm working on a fix, this is probably important fix for 21.02 as well
<stintel>
ok I have the exact same issue on my other unit
<ynezz>
jow: can you please review http://sprunge.us/p7jjV9 (ustream-ssl: make library ABI version aware)
<cotequeiroz>
ynezz: I don't think it will work with uclient-fetch as is: https://git.openwrt.org/?p=project/uclient.git;a=blob;f=uclient-fetch.c;h=282092e2f556a54c9a74366840231c57450c1428;hb=HEAD#l516
<ynezz>
actually don't know how to handle that uclient-fetch dynloading, we would probably need to use some fixed version string and pass it from CMake define, which seems very brittle to me
<ynezz>
so the ABIVERSION in uclient-fetch would need to match ABIVERSION in ustream-ssl
Tapper has quit [Ping timeout: 480 seconds]
<cotequeiroz>
ynezz: wolfssl looks good. As for libustream, I would leave it without a version, creating a dogma not to change the current API--only use new names. Introduce ABI-version symbols. Then uclient-fetch (and other users) should just check the existence of that symbol to decide if it is compatible or not.
<ynezz>
but if you have libustream-ssl linked against wolfssl 4.7.0, how could another one linked against wolfssl 5.1.1 coexist?
<ynezz>
you would need different filename, don't you?
<jow>
yes
<cotequeiroz>
Yeah
<jow>
lesson learned: deal with lirbary vesioning before the fact :)
<ynezz>
:D
<jow>
and we should really recnsider wolfssl
<jow>
I didn't thoroughly track that tpic recently but from what I gathered it appeared to be *very* volatile with little regard for long term stability
<jow>
as in, maintaining some version with a fixed api/abi for some time
Gaspare has joined #openwrt-devel
<ynezz>
yes, if they didn't improved that, then we should reconsider it
<cotequeiroz>
They seem to be chasing many moving targets: openssl, plus the different applications they have to acommodate
srslypascal is now known as Guest69
srslypascal has joined #openwrt-devel
<ynezz>
we've told them, that this is insane and they've promised to improve it
<stintel>
that's the u-boot code that does the checks
<rsalvaterra>
eduardo010174: I don't see the patch in linux-netdev at all. If this was a hack, I wouldn't mind. However, since is supposed to be a patch for upstream, I'd *really* like to see it merged upstream first, and *then* backported to 5.10.
<eduardo010174>
rsalvaterra after search only find this links, original https://lkml.org/lkml/2021/3/22/496 and depends for link in the description
<eduardo010174>
probably you is correct and it's not in "Awaiting Upstream"
mattytap has quit [Ping timeout: 480 seconds]
<rsalvaterra>
I'm pretty sure it hasn't been sent upstream.
<eduardo010174>
I agree
<nbd>
stintel: here's my suggestion: create a fake squashfs image header that is very short. place it after the kernel image
<nbd>
make the kernel partition fixed size
<nbd>
e.g. 4 MB or something like that
<nbd>
use the area after that for ubi
<nbd>
boot loader only checks the size and checks if there is data present at the end of the fs
<nbd>
i guess this was made to detect if flashing an image was aborted
<rsalvaterra>
eduardo010174: There. Now it's explicit.
<stintel>
nbd: thanks, will have a go at it
<stintel>
already had fixed kernel partition of 4MB in my UBI attempt
<stintel>
hmmmz, don't really remember how this all worked in combination with fit images
<nbd>
i looked at your image building code
<nbd>
the fs is simply appended to the image
<nbd>
so you can leave the kernel as-is
<nbd>
and instead of appending the rootfs, you append the fake header + padding to 4 MB
<nbd>
then the ubi part
Tapper has joined #openwrt-devel
aleksander has joined #openwrt-devel
<eduardo010174>
rsalvaterra: Thanks. Now it's wait for others.
Guest33 is now known as Rayyan
eduardo010174 has quit [Remote host closed the connection]
<stintel>
bash: line 1: /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/bin/mksquashfs-lzma: No such file or directory
<stintel>
this is from tools/squashfs
<stintel>
any idea why this wouldn't be buikt ?
<stintel>
ah, that's only built for ath79
Tapper has quit [Ping timeout: 480 seconds]
<Grommish>
stintel: ping. You wouldn't have a mips_24kc/mipsel_24kc test bed, would you?
<stintel>
I do
<Grommish>
stintel: Any chance you'd be willing to run this float-test ipk on them? neggles wrote it to help test rust-lang output crossed bins. mips64 requires kernel fpu being set
<Grommish>
It'll either work or SIGILL from the missing float instructions hehe
<stintel>
ask me again in 3h
<Habbie>
Grommish, i have a mips_24kc 19.07 that i can try things on
<Habbie>
Grommish, or if you're very patient, i could have a 21.02 or master mips_24kc
<Habbie>
Grommish, but stintel is likely a better bet in that case
<Grommish>
Habbie: But it's very cool to know it at least works on 19.07. rust-lang should be like any other C/C++ compiled though, as long as I set it up right
<stintel>
> The boot files which are used by WatchGuard are proprietary and does not use the files noted. WatchGuard Development will need to make a change to the code so that it can boot with the noted files. This will take some time to get completed, I will post the links to the files once they have been updated.
<stintel>
right
<stintel>
neggles: WatchGuard support be trolling us or what? I told them if they refuse to comply I'll report them to the copyright owners, gpl-violations.org and SFC
cmonroe has joined #openwrt-devel
cmonroe_ has quit [Ping timeout: 480 seconds]
owrt-1907-builds has quit [Remote host closed the connection]
owrt-2102-builds has quit [Remote host closed the connection]
owrt-snap-builds has quit [Remote host closed the connection]
owrt-2102-builds has joined #openwrt-devel
owrt-1907-builds has joined #openwrt-devel
owrt-snap-builds has joined #openwrt-devel
dansan has quit [Remote host closed the connection]
mangix has joined #openwrt-devel
mangix has quit [Remote host closed the connection]
<Grommish>
and, I could use a aarch64 target to pick for testing if you have one off the top of your head
ecloud has joined #openwrt-devel
danitool has joined #openwrt-devel
goliath has joined #openwrt-devel
<stintel>
Grommish: I have aarch64 too
<stintel>
but ugh google drive, can we simply add that thing to the packages feed for the time being ?
<Grommish>
stintel: If you also want to build out the toolchain to build the package
<Grommish>
stintel: That's just the ipk.
<stintel>
> Yes that is true but these are not what is being used to Boot the system, you can see in your details the WatchGuard U -Boot which is the propriety.
<stintel>
wtf
<ynezz>
Proprietary GPL v2.0 or later
<hauke>
Pepes: ynezz: I plan to tag 21.02 today
<stintel>
> As I stated we are modifying the GPL software so that the appliance can boot up with the U-Boot - At current this is not possible, once we have removed the WatchGuard software we will provide you with the GPL version which will boot the appliance.
<hauke>
I will look into wireless update in the next days
<hauke>
there are also some patches pending on the backportes list
<stintel>
Grommish: is there a wget-able URL for those ipk's?
<Grommish>
stintel: Dunno.. Gimme a min and I'll just repo them
<stintel>
Grommish: I responded to the thread
<stintel>
but that's what I meant with add it to the packages feed: it will be built by the buildbots and anyone can just opkg install it
<stintel>
no google drive nor the need to provide a wgetable url :)
<Grommish>
stintel: It requires rust-lang, which the build bot woukdn't have and wnt' be in packages for a long time, if ever
<stintel>
oh
<Grommish>
But, You raise a good point about repo and versioning control on my end
<Grommish>
Yah, that's a rust-lang bin you ran :D
<stintel>
I did not realize it's built with rust
<Grommish>
It does work for the arches I've verified at least
<Grommish>
I hadn't bothered to rerun check after the update :D and I never expected to put it up hehe
Borromini has joined #openwrt-devel
<stintel>
rsalvaterra: # logread
<stintel>
Illegal instruction
<stintel>
hmmm, netifd/udhcpc problem ... when a router transitions to backup state, it runs "ifdown wan" ... apparently that doesn't stop netifd or udhcpc from renewing the lease later on, hijacking the lease from the active router and causing all kinds of weirdness
<stintel>
imo these calls should never fail, and if they do, we should try to fix them, and giving the full call including the json is the only useful thing to help tracking that down
<stintel>
I'll sit on it for a bit longer, probably send a patch for review in the coming days
Luke-Jr has quit [Ping timeout: 480 seconds]
eduardo010174 has joined #openwrt-devel
eduardo010174 has quit [Remote host closed the connection]
Borromini has quit [Quit: Lost terminal]
arnd has quit [Read error: Connection reset by peer]
arnd has joined #openwrt-devel
al has quit [Ping timeout: 480 seconds]
al has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
Thagabe has quit [Quit: Connection closed for inactivity]
GNUmoon has joined #openwrt-devel
<neggles>
stintel: i saw there'd been a reply but i didn't open it yet
<neggles>
> WatchGuard will need to create GPL builds with the boot files, all existing boot files are WatchGuard proprietary so our Development team has to adjust the system to use the boot file. This will take some time and we will update the case once we have a GPL build with a boot file.
<neggles>
I am going to give them the benefit of the doubt and assume that "all existing boot files are WatchGuard proprietary" is *meant* to be "all existing u-boot binaries and source trees contain watchguard proprietary code"
<neggles>
which is fine *if* their proprietary code is only interfacing via the u-boot API which explicitly has an exclusion
<neggles>
...it doesn't seem to be, but
<neggles>
Grommish: interesting that it reports a 0x0 terminal :P
<Grommish>
neggles: Tera-Term
<Grommish>
neggles: over roll-over console
<neggles>
odd, it should be able to read out the dimensions, but idk if teraterm implements that part of the protocol
<neggles>
PuTTY does
<Grommish>
Does report correctly on a ssh connection though
<neggles>
i am glad i clamped the minimum output size to 64x64 then :P
<neggles>
the crate i'm using for terminal info has another function which indicates whether there's terminfo or not
<neggles>
should probably use that so it doesn't say '0x0 terminal' but meh details
<Grommish>
I'm building a test package for aarch64, and then x86 I think, which will then circle me back to arm :(
<neggles>
I suspect on 32-bit you'll have Problems
<neggles>
since i'm using float64s
<Grommish>
neggles: Works for mips/mipsel *shrug*
<neggles>
neat
<Grommish>
Even worked under 19.07
<neggles>
I should be checking to see if the system is 32 or 64-bit
<neggles>
or i should just search/replace f64 with f32 and see if it makes any difference to the output
<neggles>
i suspect not
<neggles>
it does not
<Grommish>
I wouldn't think it would make a difference to the output, but unless I run into issues, no reason to "fix" it unless you want to. Once i build the toolchains out, it's trivial to rebuild the test package
<Grommish>
I'm still trying to decide how best to handle arm and how it's laid out in the build system
<neggles>
iirc i came up with some fairly simple rules for that which don't require much to be changed/updated
cotequeiroz has quit [Remote host closed the connection]