hanetzer has quit [Quit: WeeChat 3.7.1]
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 99.7% packages reproducible in our current test framework.)
minimal has quit [Quit: Leaving]
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
<owrt-snap-builds> Build [#799](https://buildbot.openwrt.org/master/images/#builders/8/builds/799) of `x86/64` failed.
dangole_ has quit [Quit: Leaving]
danitool has quit [Ping timeout: 480 seconds]
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 99.7% packages reproducible in our current test framework.)
<owrt-snap-builds> Build [#768](https://buildbot.openwrt.org/master/images/#builders/18/builds/768) of `mvebu/cortexa9` failed.
ptudor has quit [Ping timeout: 480 seconds]
ptudor has joined #openwrt-devel
valku has quit [Quit: valku]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
<Znevna> morning
<owrt-snap-builds> Build [#767](https://buildbot.openwrt.org/master/images/#builders/53/builds/767) of `bcm27xx/bcm2711` failed.
owrt-snap-builds has quit [Remote host closed the connection]
owrt-snap-builds has joined #openwrt-devel
<ynezz> I've just removed that sunshine-02 buildworker
csrf has quit [Read error: Connection reset by peer]
csrf has joined #openwrt-devel
<ynezz> hopefully it's going to work with just sunshine-01
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (100.0% images and 99.7% packages reproducible in our current test framework.)
owrt-2203-builds has quit [Remote host closed the connection]
owrt-2203-builds has joined #openwrt-devel
<owrt-2203-builds> Build [#217](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/65/builds/217) of `tegra/generic` failed.
<owrt-2203-builds> Build [#215](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/26/builds/215) of `ramips/rt305x` failed.
<Znevna> 0o
<owrt-2203-builds> Build [#215](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/38/builds/215) of `bcm47xx/generic` failed.
<owrt-2203-builds> Build [#216](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/55/builds/216) of `bcm47xx/legacy` failed.
<owrt-2203-builds> Build [#218](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/41/builds/218) of `apm821xx/nand` failed.
<owrt-2203-builds> Build [#215](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/37/builds/215) of `ramips/rt3883` failed.
<owrt-2203-builds> Build [#217](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/48/builds/217) of `mediatek/mt7629` failed.
<owrt-2203-builds> Build [#217](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/36/builds/217) of `sunxi/cortexa8` failed.
<opty> o_O
<owrt-2203-builds> Build [#212](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/20/builds/212) of `ramips/mt7621` failed.
<owrt-2203-builds> Build [#216](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/43/builds/216) of `mvebu/cortexa9` failed.
<owrt-2203-builds> Build [#214](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/30/builds/214) of `octeon/generic` failed.
<owrt-2203-builds> Build [#216](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/74/builds/216) of `mpc85xx/p2020` failed.
<owrt-2203-builds> Build [#212](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/42/builds/212) of `lantiq/xway_legacy` failed.
<owrt-2203-builds> Build [#217](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/22/builds/217) of `bcm4908/generic` failed.
<owrt-2203-builds> Build [#217](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/46/builds/217) of `omap/generic` failed.
<owrt-2203-builds> Build [#216](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/35/builds/216) of `bcm53xx/generic` failed.
<owrt-2203-builds> Build [#215](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/21/builds/215) of `bcm63xx/smp` failed.
<owrt-2203-builds> Build [#213](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/75/builds/213) of `kirkwood/generic` failed.
<owrt-2203-builds> Build [#225](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/9/builds/225) of `armvirt/32` failed.
<owrt-2203-builds> Build [#216](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/23/builds/216) of `ath79/nand` failed.
<Znevna> well, at least they all fail ;P
<owrt-2203-builds> Build [#216](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/50/builds/216) of `apm821xx/sata` failed.
<owrt-2203-builds> Build [#216](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/66/builds/216) of `zynq/generic` failed.
<owrt-2203-builds> Build [#215](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/68/builds/215) of `mediatek/mt7623` failed.
<owrt-2203-builds> Build [#218](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/19/builds/218) of `ipq806x/generic` failed.
<owrt-2203-builds> Build [#214](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/31/builds/214) of `bcm27xx/bcm2710` failed.
<owrt-2203-builds> Build [#219](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/47/builds/219) of `bcm27xx/bcm2708` failed.
<owrt-2203-builds> Build [#217](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/58/builds/217) of `realtek/rtl839x` failed.
<owrt-snap-builds> Build [#788](https://buildbot.openwrt.org/master/images/#builders/4/builds/788) of `x86/generic` failed.
floof58 is now known as Guest1701
floof58 has joined #openwrt-devel
Guest1701 has quit [Ping timeout: 480 seconds]
torv is now known as Guest1703
torv has joined #openwrt-devel
Guest1703 has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest1705
srslypascal has joined #openwrt-devel
srslypascal is now known as Guest1708
srslypascal has joined #openwrt-devel
rua has quit [Quit: Leaving.]
Guest1705 has quit [Ping timeout: 480 seconds]
<owrt-snap-builds> Build [#765](https://buildbot.openwrt.org/master/images/#builders/44/builds/765) of `mediatek/mt7622` failed.
Guest1708 has quit [Ping timeout: 480 seconds]
<ynezz> ok so sunshine-01 needs to be disabled as well
owrt-snap-builds has quit [Remote host closed the connection]
owrt-snap-builds has joined #openwrt-devel
srslypascal has quit [Quit: Leaving]
bookworm has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
srslypascal has joined #openwrt-devel
cbeznea has joined #openwrt-devel
<russell--> there seems to be some split-brain going on with tls/ssl libraries (libcurl defaults to mbedtls, libustream-wolfssl), what's the preference these days?
<stintel> I recently switched my dumb AP builds to mbedtls since hostapd now has support for it
<slh> curl is not a default package, but wpad(-base) is, which -currently- depends on wolfssl; but is likely to swiotch to mbedtls 'soon'
<stintel> iirc we want to switch from wolfssl to mbedtls by default because of the continuous issues with wolfssl
<stintel> haven't noticed any problems since doing the switch a week ago
srslypascal has quit [Ping timeout: 480 seconds]
<russell--> thanks
srslypascal has joined #openwrt-devel
<owrt-2203-builds> Build [#216](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/26/builds/216) of `ramips/rt305x` completed successfully.
<owrt-2203-builds> Build [#218](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/36/builds/218) of `sunxi/cortexa8` completed successfully.
<owrt-2203-builds> Build [#218](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/48/builds/218) of `mediatek/mt7629` completed successfully.
<owrt-2203-builds> Build [#216](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/38/builds/216) of `bcm47xx/generic` completed successfully.
<owrt-2203-builds> Build [#218](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/65/builds/218) of `tegra/generic` completed successfully.
<owrt-2203-builds> Build [#216](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/37/builds/216) of `ramips/rt3883` completed successfully.
<owrt-2203-builds> Build [#219](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/41/builds/219) of `apm821xx/nand` completed successfully.
<owrt-2203-builds> Build [#217](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/43/builds/217) of `mvebu/cortexa9` completed successfully.
<dwfreed> ynezz: ^ whee
<owrt-2203-builds> Build [#213](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/20/builds/213) of `ramips/mt7621` completed successfully.
<mrkiko> Too many build successes. I think we need some version bumps
danitool has joined #openwrt-devel
<\x> 23rc1?
<mrkiko> :D was thinking about some packages version dump, but I was joking
robimarko has joined #openwrt-devel
<dhewg> mrkiko: was it you with the dsl firmware idea to fetch those from the vendor partition?
<mrkiko> dhewg: yes
<dhewg> ok :) I think that's a pretty nice idea, it could even be a generic solution, since other platform/drivers are affected by the same annoying problem
<dhewg> and if we had that we could just overlay mount that or something in that direction, so that the files survice a sysupgrade
<dhewg> are you planing to work on it or was that just an idea?
<dhewg> -c+v
<Znevna> yes yes version bump mt76
<mrkiko> dhewg: it was just an idea actually... but even so, I don't know if we can push that so far. I didn't analyse the content of the flash from an initramfs, but I suspect firmware files are just placed in the avm_fs partition in this case, so you are going to want to remove it anyway
<owrt-2203-builds> Build [#217](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/74/builds/217) of `mpc85xx/p2020` completed successfully.
<dhewg> the vendor fw only existed a few minutes for me, but from extracing it I think it was just part of their rootfs, files in /lib/firmware
<\x> neggles: Redmi AX3000/CR8808/CR8806 https://i.imgur.com/j5ukbwb.jpg so three models, one direct from xiaomi, two are ISP provided models, CRXXXX should be china telecom
<dhewg> but I mean we could just add a firmware partition for openwrt and cp them there
<\x> thats another 7981 there, but no usb is no good for me
<neggles> neat
<robimarko> ynezz: what would be the minimum specs for a buildbot?
<neggles> i preordered a GL-MT3000
<neggles> because yolo
<mrkiko> dhewg: oh, sure yes
<\x> also, typical xiaomi fashion nowadays, no shell on ttl
<\x> ahaha
<neggles> boooo!
<neggles> and presumably locked u-boot
<\x> but hey it seems isps are getting this cheap or something
<neggles> i need to find someone i can palm off this GL-SFT1200 to...
<\x> the earlier one from qihoo (360T7) is also using this chip
<owrt-2203-builds> Build [#218](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/22/builds/218) of `bcm4908/generic` completed successfully.
<owrt-2203-builds> Build [#218](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/46/builds/218) of `omap/generic` completed successfully.
<robimarko> Ansuel: Wait, reproducible build is still not running in verbose mode
<owrt-2203-builds> Build [#225](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/10/builds/225) of `realtek/rtl930x` completed successfully.
<neggles> so many succeeds
<neggles> i should set something up to automate builds of my non-upstreamable things
<gch981213> That Xiaomi router uses an 8-pin SPI-NAND and the CH347 USB to SPI bridge is really chip. I'm just not sure if using a soldering iron and a heat gun counts as a valid OpenWrt installation method :P
<neggles> i'm sorry what
<gch981213> I mean: remove the flash from the board, write the bootloader with a flash programmer and solder it back.
<neggles> oh
<neggles> no that's a completely legitimate openwrt installation method
<owrt-2203-builds> Build [#217](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/55/builds/217) of `bcm47xx/legacy` completed successfully.
<owrt-2203-builds> Build [#217](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/35/builds/217) of `bcm53xx/generic` completed successfully.
<neggles> also most of the time you don't need to desolder the flash chip
<neggles> varies, though.
<\x> this one is wson8
<\x> so youll have to hold the clip
<owrt-2203-builds> Build [#218](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/58/builds/218) of `realtek/rtl839x` completed successfully.
<neggles> i have a... special... clip for wson8
<owrt-2203-builds> Build [#226](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/9/builds/226) of `armvirt/32` completed successfully.
<\x> if a clip works, sometimes just clipping on these turns on the thing....
<neggles> yeah
<neggles> though sometimes it doesn't turn it on enough for the SoC to actually boot!
<\x> sometimes theres a pulldown/pullup whatever on these
<owrt-2203-builds> Build [#217](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/66/builds/217) of `zynq/generic` completed successfully.
<gch981213> I'm using a TP-Link TL-XDR3230 (mt7622+mt7915) with OpenWrt. I'm too lazy to crack the vendor firmware so I started with -ubootmod.
<neggles> it's fun flashing a device while it sits there blinking an angry status LED
<neggles> having failed to load the SPL
<neggles> (I'm a bad person, I know)
<owrt-2203-builds> Build [#220](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/47/builds/220) of `bcm27xx/bcm2708` completed successfully.
<owrt-2203-builds> Build [#214](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/75/builds/214) of `kirkwood/generic` completed successfully.
<\x> would be nice to desolder the thing and then replace it with an soic8 clampshell
<neggles> have done that a few times too
<\x> and just use soic from there, but thats too much work imo
<neggles> eh, depends? sometimes the LOTES clamshells will line up okay with a WSON footprint
<owrt-2203-builds> Build [#275](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/2/builds/275) of `oxnas/ox820` completed successfully.
<owrt-2203-builds> Build [#217](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/23/builds/217) of `ath79/nand` completed successfully.
<owrt-2203-builds> Build [#225](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/6/builds/225) of `mpc85xx/p1020` completed successfully.
<owrt-2203-builds> Build [#216](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/21/builds/216) of `bcm63xx/smp` completed successfully.
<\x> yeah theyll line up properly, its nearly the same size
<neggles> and if i'm pulling a chip off a board, odds are i'm going to need to do it more than once
<owrt-2203-builds> Build [#219](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/19/builds/219) of `ipq806x/generic` completed successfully.
<neggles> wson-8 clamshells cost a bomb though, and reasonably large SOIC-8 SPI NAND is expensive
<\x> i remember theres those wson8/soic8 to dip8, theyre tall but it looks like itll fit there
<neggles> i got a new oscilloscope today, got it all set up, applied keygen'd keys to turn the 100mhz scope into a 500mhz scope
<neggles> then realized... i don't actually have anything i need to probe right now
<neggles> :(
<owrt-2203-builds> Build [#215](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/31/builds/215) of `bcm27xx/bcm2710` completed successfully.
<oliv3r[m]> doe sthe term 'RXI-300' ring any bells to anyone?
<mrkiko> neggles: :D
<neggles> context?
<oliv3r[m]> I just got the RTL9310 datasheet, and the block diagram states 'MIPS interAptive System -> RXI-300' The RXI-300 connects to two Lexra Busses, and houses a ROM controller, SRAM controller, RXI-310 DRAM controller and SPI controller
<neggles> ah
<oliv3r[m]> so I'm thinking RXI and RXI-310 are IP blocks from some MIPS vendor? kinda like ARM has arm blocks?
<neggles> that's the mips equivalent of AXI
<neggles> yeah
<owrt-2203-builds> Build [#221](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/17/builds/221) of `ipq40xx/generic` completed successfully.
<neggles> ah sorry, not equivalent of AXI, AXI is a bus
<robimarko> Ansuel: And reproducible builds are failing because of: #include <asm/types.h>
<neggles> but yeah it's an IP block on the ASIC
<gch981213> \x: BTW you are right that ISPs are getting these. They are bundled with broadband plans for new users.
<robimarko> They cannot find it
<\x> gch981213: thats a good thing, it makes these cheap as hell
<\x> v nice
<neggles> mrkiko: at least the probe compensation output looks nice :P https://lounge.neggl.es/uploads/9d41cf26443108e7/image.png
<robimarko> oliv4r[m]: You got some new contacts?
<oliv3r[m]> I do :)
<\x> gch981213: finally we are off mt7621a ahaha
<neggles> hahaha
<neggles> no we're not
<gch981213> Lol.
<neggles> the MT7621A will never leave us alone
<oliv3r[m]> a US firm wants openwrt support, and an ODM that actually makes the switches, gave them docs :)
<neggles> it will haunt us until 2030 mark my words
<robimarko> So you hit the holy grail
<oliv3r[m]> they are also sending me a 24 and 48 port POE switch
<\x> come on, you dont have to remind me that mt7621a with wifi7 is possible neggles
<robimarko> \x: Dont you even speak of that
<oliv3r[m]> they, seems to include register information; and they are ok with putting register information on svanheule.net/realtek :)
<robimarko> So you hit the best ODM ever, they usually require pretty much everything they can think of in the NDA
<robimarko> In the hopes that you will just give up on docs
<neggles> I mean, people are still making devices with QCA9531s in them
<oliv3r[m]> yeah, the NDA only said 'don't share these files'
<neggles> so technically
<neggles> you could print them to PDF
<robimarko> Damn, thats a good deal
<oliv3r[m]> well they are doing second-hand NDA
<neggles> and that's not sharing *those* files... :P
<oliv3r[m]> how about, converting it to odf, removing the watermarkers, resave it as pdf
<neggles> i pull watermarks out with acrobat preflight :P
<oliv3r[m]> (if only I could remove the watermark from the pdf with some tools :p)
<oliv3r[m]> opening it in libreoffice worked, but i'd have to do it on a 'per page' basis
<neggles> um
<robimarko> I mean, just selectively sharing the data is probably good enough to avoid the NDA
<owrt-2203-builds> Build [#225](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/14/builds/225) of `ramips/mt7620` completed successfully.
<neggles> you can decompress it with pdftk
<neggles> then edit the raw postscript stream
<robimarko> Somebody has some experience with this:)
<oliv3r[m]> its not even compressed; but editing the raw postscript is horrendously difficult I found :p
<neggles> 99% chance that all the watermark objects are the exact same colour and alpha
<neggles> I do this *all the time*
<oliv3r[m]> i tried removing some stuff to see if I could easily find the bits, but nope
<neggles> there must only be like four or five different bits of software that companies use to put these watermarks on because with about five acrobat preflight fixups I can purge 90% of them
<oliv3r[m]> ok, if you take https://github.com/libc0607/Realtek_switch_hacking/blob/files/RTL8196E-VEx-CG_Datasheet_1.1.pdf and give it a shot and teach me, i'd much appreciate it
<oliv3r[m]> it follows the exact same realtek way of doing things
<neggles> oh I already have a realtek preset lmao lets see if it matches
<neggles> hmmm nope little different than usual
<neggles> one moment...
<owrt-2203-builds> Build [#215](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/30/builds/215) of `octeon/generic` completed successfully.
<neggles> how's that?
<neggles> 664 objects removed
<neggles> the silly part is most of the time I'm not even doing this for NDA reasons, the watermarks are just ugly and make things hard to read
<oliv3r[m]> lol yeah
<oliv3r[m]> so, now I would like to do it, but without acrobat :p
<oliv3r[m]> unless I can't install it on linux :p
<neggles> I think there's a linux acrobat? (i'm using it because i still have an educational email address, so i get all the adobe products for about 8 bucks a month)
<neggles> but yeah i've been meaning to work out a way to do this without it
<neggles> all i'm doing is matching on "constant alpha for fill" and "color value for fill" properties
<neggles> it's incredibly rare for there to be any element in the document other than the watermark with the same alpha/colour values, mostly because the watermarking software seems to always use incredibly arbitrary values
<neggles> e.g. this one uses color values of 0.8/0.8/0.8 with alpha of 0.7
<neggles> the most common is to use 0.0 color values, and 0.3 alpha
<oliv3r[m]> but could you tell me how the object would look like in text (e.g. I can open the file in a text editor, but there's soo much in there, it's hard to find what I'm looking at
<neggles> lets see
<oliv3r[m]> i'm looking at both files now, one thing I do see, that acrobat did, is repplace \n with \r\n
<neggles> it also compressed it
<oliv3r[m]> oh and sometimes with just \r lol
<oliv3r[m]> ahh ok
<oliv3r[m]> so why can I read the 'endstram' and 'endobj' markers?
<neggles> control characters aren't compressed, only content :)
<owrt-2203-builds> Build [#216](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/68/builds/216) of `mediatek/mt7623` completed successfully.
<oliv3r[m]> Ah ok; the original pdf had a comment on the second line though that was interesting: %verypdf.com whatever that is
<neggles> probably the website they used to strip the "edit protection"
<oliv3r[m]> ahh right
<neggles> which ghostscript used to let you easily do, but now it mangles the doc as it goes through
<neggles> pdftk uncompress, cursed sed command, pdftk compress
<oliv3r[m]> so all I need is the cursed sed command :D
<neggles> workin' on it :P
<neggles> are the PDFs "edit locked" ?
<neggles> such an asinine level of "protection"
<mrkiko> neggles: pdftk may help on that
<dhewg> maybe this is helpful to archive that https://qpdf.readthedocs.io/en/stable/json.html
<oliv3r[m]> i don't know; i'm decopmressing them first
<dhewg> never tried it though
<neggles> mrkiko: it sure does
<Znevna> yet another "DISABLE IPv6!! topic /me grabs popcorn
<neggles> you have to modify the pdftk code slightly if you want it to remove the protection for you wholesale, though
<neggles> in order to not get C&D'd by adobe they had to make it actually verify the edit password before allowing you to set/unset one
<oliv3r[m]> heh, i did qpdf --decrypt --object-streams=disable in.pdf out.pdf and the file got smaller :D
<neggles> it will have re-DEFLATE'd it probably :P
<neggles> but yeah the watermark tools seem to also be horribly inefficient.
<neggles> `qpdf --stream-data=uncompress` should work too
<oliv3r[m]> the json is double the size :) but much more readable :D
<oliv3r[m]> sadly, my knowledge ends here, as all I see is lots of ... numbers and letters without meaning :)
<oliv3r[m]> lets see
<oliv3r[m]> they are converting things to hex with xxd and then use sed to remove it
<oliv3r[m]> grep -o $WATERMARK_HEX $UNCOMPRESSED_HEX
<oliv3r[m]> the thing seems to be, those watermarks aren't pure 'text' or at least, I can't find them in the json output
<neggles> oliv3r[m]: `qpdf --stream-data=uncompress --qdf RTL8196E-VEx-CG_Datasheet_1.1.pdf RTL8196E-VEx-CG_Datasheet_1.1_qp.pdf`
<oliv3r[m]> that's how i uncompressed it :)
<neggles> qdf
<neggles> not json
<oliv3r[m]> i did both
<oliv3r[m]> just to see
<neggles> go to line 6565
<oliv3r[m]> actually, didn't see the --qdf flag
<oliv3r[m]> U used --decrypt
<neggles> QDF is regular postscript/pdf but it's been reshuffled to be easier to edit
<neggles> you only need `--decrypt` if it's a "(SECURED)" pdf, and i think qpdf will still require you to give it the password
<oliv3r[m]> qpdf --stream-data=uncompress --qdf --decrypt --object-streams=disable
<oliv3r[m]> is what I used, and its fine
<neggles> you might want to open it up and make sure object-streams=disable didn't delete anything :P
<neggles> like bitmaps :P
<oliv3r[m]> ahh right better drop that flag then :p
<neggles> anyway, with it QDF'd, assuming that process is repeatable, line 6545 thru 6584 is one of the watermarks
<f00b4r0> Znevna: disable ipv6 topic?
<oliv3r[m]> excellent, let me look at this
<oliv3r[m]> obj 97 i got there, just like you
<oliv3r[m]> RICHPOWER SHENZHEN which also matches what the watermark states
<f00b4r0> that's rich
<neggles> yeah this is one of the more lame watermarks
<neggles> it's just a text box
<oliv3r[m]> yeah, but! with that qpdf line I have actually found the watermark :) before, I couldn't find any of the watermark strings
<neggles> usually they flatten the text to vectorized paths of individual characters
<oliv3r[m]> %% Contents for page 1; %% Original object ID: 52072 0 whatever that means
<neggles> that's a QDF comment
<oliv3r[m]> so I can just delete the whole block
<mrkiko> it's strange to see other people faithing with pdf as I do sometimes, even tough never that deeply
<neggles> yes, from `97 0 obj` to `endobj`
<neggles> then run `fix-qdf` on the file
<oliv3r[m]> so now the hard part is 'automate this' but you know what, I odn't mind spending 20 minutes to do it :p
<neggles> well
<neggles> what you're looking for is the
<neggles> '0.8 0.8 0.8 rg' line
<neggles> nothing else (in this doc at least) is set to those colour values
<oliv3r[m]> https://paste.neggles.dev/FZgER is what i got
<mrkiko> May someone send mte the link of the dynalink wrx36 official forum thread?
<neggles> oliv3r[m]: yeah but they won't all be completely identical i don't think
<f00b4r0> Znevna: oh, i just saw. *sigh*
<neggles> hmmm
<neggles> i have an idea and it is cursed please hold
<oliv3r[m]> i could automate it for me now with sed, by doing delete on match + line numbers X match - linenumbers Y
<oliv3r[m]> getting the match is trivial, just search for 'confidential' for example
<neggles> i would be finding `0.8 0.8 0.8 rg` then searching backwards for a line ending in `obj`, forwards for a line of `endobj`, and deleting those lines inclusive
<oliv3r[m]> true, but my sed-foo is not strong enough
<neggles> this is awk territory
<neggles> or, what i'm about to try
<neggles> which is A Cursed Python Script
<oliv3r[m]> well should be easy in vim too
<oliv3r[m]> hmm, so :-11,30d doesn't work, as that just deleted 30k lines
<oliv3r[m]> :.-11,.+31d seems to do the trick though; so search, delete
<oliv3r[m]> tac | sed '/banana/I,+2 d' | tac could work e.g. first do everything before without tac, then everything after with tac; a bit cumbersome but easy enough
<oliv3r[m]> or vim can even do it appearantly :) g/banana/.-2,.d so i'll play with that
<oliv3r[m]> :g/^0.8 0.8 0.8 rg$/.-11,.+31d seems to have done the trick :)
<oliv3r[m]> sadly, the resulting pdf is now broken :(
<oliv3r[m]> RTL9300-CPU-MemoryController-Peripherals-Datasheet_v0.1.pdf:9723: expected object 133 is what fix pdf is complaining about. Whihc isn't strange, as that is exactly the object I deleted (as it was the watermark)
robimarko has quit [Quit: Leaving]
robimarko has joined #openwrt-devel
<oliv3r[m]> So it's not that simple, I removed the content of the object (on page 1 only) so I only have 133 0 obj\nendobj fix pdf is happy, but evince now shows page 1 as completly blank. links seem to work though (as I get the mouse behavior)
<Znevna> f00b4r0: boy, this is a neverending subject
<Znevna> switched my vm storage controller to virtio-scsi, feels snappier
<owrt-2203-builds> Build [#217](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/50/builds/217) of `apm821xx/sata` completed successfully.
borek has joined #openwrt-devel
<oliv3r[m]> neggles: or, I just replace the text, and set the transparancy/color to something dumb :p
<mrkiko> Znevna: are you using libvirt or something or qemu ?
<Znevna> nah
<Znevna> virtualbox
<Znevna> win host
<mrkiko> Znevna: are you under Linux?
<robimarko> And that is not ultra slow?
<mrkiko> oh ok, sorry
<Znevna> mrkiko: win10 host, ubuntu 20.04 guest
<Znevna> robimarko: no
<mrkiko> robimarko: works pretty well in my experience (one instance=;had strange crashes rebooting the vm in win11 until I updated vbox
<oliv3r[m]> is there an easy way to not include a file when the asembler is running? E.g. in my header file I want to include bitops.h, but not when it's doing .S files, (i'll manually define BIT() for that if needed).
<robimarko> mrkiko: I gave up on Windows long time ago
<mrkiko> robimarko: I as well, infact I am using that on a $dayjob scenario
<mrkiko> robimarko: but if I need to browse the web with a screen reader, a windows VM can be a dirty and quick solutions rather than installing the graphical tools on Linux and so on
<robimarko> True
rua has quit [Quit: Leaving.]
<mrkiko> And infact - that's why I wanted to implement a different u-boot behaviour for 7530 avoiding the windows recovery tool, but of course it's desired to trigger recovery by pressing a button and to test that I need UART
<robimarko> f00b4r0: Do you by chance know the HW requirments for new buildbots?
<f00b4r0> robimarko: ballpark for phase1 (not looked at phase2 yet). To be comfortable you need, per worker, about 50G storage, about 30G RAM, about 12-16 cpus.
<f00b4r0> you can do with less, but there will be less headroom for future workloads imho.
<robimarko> f00b4r0: Thats a bit out of my price range
<f00b4r0> you don't need very modern cpus actually
<robimarko> I could probably afford 8 core/24GB Ampere with 100GB of storage
<gch981213> Wow that's a lot...
<gch981213> We can't really use ARM buildbots can we?
<robimarko> Why not?
<robimarko> I was building OpenWrt in my CI on those Ampere just fine
<gch981213> I have access to two Huawei servers that's doing nothing.
<gch981213> robimarko: X86 SDK and ImageBuilder
<robimarko> Arent we cross-compiling those anyway?
<f00b4r0> I'm running off of Ivy Bridge CPUs
<robimarko> I dont really have conditions to host anything locally
<f00b4r0> and in fact my older generation (I think it's nehalem EP or something) performed as well if not better as the sandy bridge ones.
<f00b4r0> (which I used before switching to ivy)
<f00b4r0> Westmere EP
<robimarko> With todays and future electricity prices all of the cheap servers are out of picture
<gch981213> robimarko: No. The tools in SDK/ImageBuilder are either copied from host system or build for the host.
<f00b4r0> robimarko: of course the other issue is that at full load, these mchines will draw quite a bit of power, and that's not cheap
<robimarko> Well, at least we could use these Ampere ones for all other targets
<f00b4r0> (which is one of the reasons why I worked on optimizing the buildbot system)
<gch981213> robimarko: I don't mean x86 targets
<gch981213> I mean the SDK/ImageBuilder we built for any target can only run on the same architecture as the build host.
<f00b4r0> robimarko: the other important points are connectivity (you want a reasonably fat pipe) and reliability (UPS)
<robimarko> gch981213: I am not getting the issue
<dhewg> oliv3r[m]: poked at it a bit while waiting for a build, and this works for me: qpdf --json --json-stream-data=file in.pdf out.json; for i in `grep -Hi confidential *.json-*|cut -d':' -f1`; do cp /dev/null $i; done; qpdf --json-input out.json out.pdf
<robimarko> f00b4r0: Another reason why I dont want nor can host locally
<f00b4r0> makes sense
<f00b4r0> gch981213: that would only affect phase2. Phase1 builds everything from scratch.
<f00b4r0> but indeed, it wouldn't be able to build the sdks
<f00b4r0> for x86
<f00b4r0> (at least probably not as is)
<gch981213> We used to have a powerpc buildbot producing PPC SDK/ImageBuilder which nobody can use.
<gch981213> I forgot who provided those
<stintel> o/
<f00b4r0> yep, makes sense. Can't cross build sdk/ib
<gch981213> stintel: Ah :)
<robimarko> Well, I can only afford to rent Ampere VM per month
<robimarko> x86 is crazy expensive
rua has joined #openwrt-devel
<robimarko> And these Ampere cores are quite fast even on the free quad core tier
<mrkiko> sorry, I can't understand - the imagebuilder/sk for mips can run only on mips hosts in phase2? The reason why it works from openwrt git tree is because we cross both phases?
<mrkiko> sorry, understood now
<gch981213> mrkiko: No. the imagebuilder/sk 'from mips host', not 'for mips target'
netprince_ has joined #openwrt-devel
<mrkiko> gch981213: thanks
Ansuel has joined #openwrt-devel
<oliv3r[m]> dhewg: so i had the problem that stuff was ending up completly blank; but replacing text works; so i'll do something along those lines
<dhewg> yeah, there's crap left, but that's at least a handy oneliner :)
bluew has quit [Ping timeout: 480 seconds]
<oliv3r[m]> qpdf --stream-data=uncompress --qdf --decrypt | sed is what i'm going for now
netprince has quit [Ping timeout: 480 seconds]
<robimarko> f00b4r0: Current buildbots are choking, we really need some new capacity
<f00b4r0> robimarko: I will reenable mine next sunday if all goes according to plan
<f00b4r0> and I will be able to add another 2
<f00b4r0> but I would very much like that we switch to the new buildbot, which will share the workload more efficiently across release/master
<robimarko> That would be nice
<f00b4r0> there's also the question that should be evaluated of whether we actually need to build master on every other commit or so.
<f00b4r0> given the amount of CI that we do, I think it makes less sense now.
<robimarko> As I said, I can offer that Ampere VM to add to the pool
<robimarko> And yeah, maybe build once a day max
<f00b4r0> robimarko: but as gch981213 pointed out, that won't do.
<robimarko> Well, that sucks
<oliv3r[m]> is the churn on master so high? I would say you deff. want to always run on anything that's about to get merged, but I see that a lot of branches get a lot of (needless?) builds on every push
<robimarko> x86 is getting damn expensive these days
<Ansuel> we should really consider that offer about donatic some server to the project... hope it will be sorted out in the next meeting...
<f00b4r0> oliv3r[m]: i've made a case that we don't need to build that often
<f00b4r0> but so far my case hasn't prevailed.
<robimarko> We really dont
<robimarko> As everything is first built in CI anyway
<f00b4r0> Ansuel: well we declined equinix. Imho that wasn't very smart, we're sending the message that we can afford to decline offers.
<robimarko> Wait, why?
<robimarko> Its not like cloud providers are throwing themselves
<oliv3r[m]> I don't know how fine-grained you can tweak github; but on gitlab; you can ensure 'nothing gets merged without CI approval'; then on branches, often it is enough to do linting and some basic compile tests only
<oliv3r[m]> yeah but running CI on master instead of 10 times a day, only once a day, sounds like a lot; but your Ci is breaking on the 1000 of branches that it runs on
<oliv3r[m]> the 'ready for merge' flag should be used on branches heavily, only run CI when a maintainer/reviewer has set that label
<dwfreed> robimarko: sometimes cloud providers just have to be asked; eg Linode
<robimarko> f00b4r0: that reason makes no sense
<dwfreed> oliv3r[m]: CI runs on GitHub, we don't care about wasting their CPU; this is distinct from full builds
<f00b4r0> robimarko: don't tell me ;P
<robimarko> What is the amount of donations anyway?
<robimarko> I doubt those can cover a single month of a 8 core VM
<Ansuel> btw robimarko https://forum.openwrt.org/t/snapshots-fail-to-build-because-of-llvm-bpf/141017/8 imho something is wrong with the header passed
<robimarko> Ansuel: No idea, but gcc-multilib makes it work
<dwfreed> Linode will *donate* VMs if asked
<robimarko> I guess we should ask them then
<dwfreed> marketing@linode.com
<Znevna> sorry for the intrusion, is it even possible to use iptables with fw4?
<Ansuel> my concern is... should that be the right solution? seems strange that we compile bpf toolchain and we need host header for it to work
<robimarko> Probably we should point it to the toolchain include
<Ansuel> i mean a better solution would be just follow the patch in that link
<Ansuel> and include the header by patching xdp-tools
<robimarko> That does the same thing as just having gcc-multilib does
<Ansuel> without the extra dep and the additional package tho
<dwfreed> or just make the symlink in the toolchain build?
<f00b4r0> dwfreed: problem is, what kind of VM would they "donate". If that's a 4 cpu VM on 1000% overcommit baremetal, that's not going to help much...
<dwfreed> f00b4r0: whatever you ask for
<f00b4r0> then let's ask
<dwfreed> often times what'll happen is they'll just make you an account set to 100% discount, and tell you "please don't spend more than equivalent $$$$ per month without asking first"
<robimarko> That sounds like the ideal scenario
<oliv3r[m]> neggles: for your stash of post-its somewhere: while, yes this uses vim; should be trivial to rewrite to sed, should be pipe-able, but this works for now:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/TnOoxvpXSxYKVWabSXsOzFRg>)
<dwfreed> that's how the OFTC account is
cbeznea has quit [Read error: Connection reset by peer]
<oliv3r[m]> do we have a openwrt gist or something where we can post something like htat?
cbeznea has joined #openwrt-devel
<oliv3r[m]> anyway, Allt he docs I have are now watermark free :) so I'm happy now to be able to read ther egister descriptions :)
<mrkiko> ok guys, this is a call for you: can you point me to the most difficult (but not too expensive) devices to solder an UART to? I may have found some cooperations, and the person asked me for some samples. Give me the worst deices :D
<f00b4r0> dwfreed: thing is, we're talking 100% cpu load 24/7. I suspect that's not going to be as trivial for them
<dwfreed> f00b4r0: they have dedicated instances
<robimarko> Well, if they just give us XYZ credits
<dwfreed> where "dedicated" means they don't oversubscribe CPU
<robimarko> That will fund dedicated machines like dwfreed pointed
<dwfreed> (all other resources are already not oversubscribed)
<f00b4r0> sounds like it can't hurt to ask indeed.
<dwfreed> dedicated instances are specifically intended for those "we use 100% load of all cores 24/7" cases
<f00b4r0> but generally speaking, we can already reduce our workload by several orders of magnitude simply by building master a bit less actively.
wvdakker_ has joined #openwrt-devel
<dwfreed> yeah, you should definitely do that too
<dwfreed> make snapshot a 'nightly' kind of thing
<robimarko> That only leaves the question of who is the lucky soul to poke at Linode
<robimarko> And yeah, I would limit building to max 1 time ad ay
<f00b4r0> i suppose there should be a consensus. If someone comes up later and say "no linode ain't kosher", we're really going to torpedo the project's reputation
<neggles> oliv3r[m]: it turns out to not be as simple as deleting the objects :/
<dwfreed> the only disclosure I have to make is I used to work for them almost 10 years ago
<dwfreed> and they recently got bought by Akamai
<oliv3r[m]> neggles: no but removing those 5 lines of content works :p
wvdakker has quit [Ping timeout: 480 seconds]
wvdakker_ is now known as wvdakker
Znevna has left #openwrt-devel [#openwrt-devel]
<robimarko> Well, considering there are less and less of cloud guys are the big ones are buying anything smaller I would say we cant be picky
cbeznea has quit [Read error: Connection reset by peer]
cbeznea has joined #openwrt-devel
<dwfreed> yeah, at least they're not owned by Amazon, Google, or Microsoft
<oliv3r[m]> a bit of moot though; as we heavily rely on github ;)
<dwfreed> and Akamai purchased Linode to expand their compute capabilities, so Linode's really not going to get eliminated anytime soon
<dwfreed> (Akamai recently announced they're making huge investments to further expand Linode into more datacenters, utilizing existing Akamai resources)
<robimarko> So they are going all in
<dwfreed> yeah
<Ansuel> robimarko can you check if asm/types.h is present in the toolchain staging directory?
<robimarko> Ansuel: Well, I nuked that build folder along with Debian container
<Ansuel> rip
<dhewg> built a fresh toolchain this morning, and I do have ./staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-12.2.0_musl_eabi/include/asm/types.h
<robimarko> But, xdp-tools and other bpf stuff is built by LLVM?
<Ansuel> well found this
<Ansuel> looks like we made multiple ""fix"" for the problem and still it's broken
<robimarko> I have LLVM building now on ipq807x as that was the easiest, lets see if it has asm/types.h
<dhewg> it's a kernel header
<dhewg> toolchain/kernel-headers/ cp'ies the kernel header files to TOOLCHAIN_DIR
<dhewg> maybe move it somewhere else and point both compilers to it?
<Ansuel> thing is that bpf-headers should provide whatever headers we need
<Ansuel> we have asm-generic but we don't have asm in uapi
<oliv3r[m]> is there any secrey way I can use GENMASK and BIT macro's in .S assembly files? I can't include bitops, otherwise I'd have tor edefine BIT and GENMASK in my header; but i'm sure i'm not the first to want/need this?
<robimarko> I think the kernel actually renamed that to asm-generic
<Ansuel> find | grep asm/types.h
<Ansuel> ./arch/mips/include/uapi/asm/types.h
<Ansuel> ./user_headers/include/asm/types.h
<Ansuel> ./arch/mips/include/asm/types.h
<Ansuel> mips is there as it should be good for all
<Ansuel> from here
akanouras has joined #openwrt-devel
<Ansuel> there is probably something wrong here
<Ansuel> and xdp-tools is getting configured wrongly
<karlp> dhewg: any idea what the blue dot in the middle of the atlantic for "everythign" is meant to mean on that "akamai turns linode up past 11" link?
<karlp> "distributed" is the blue dot apparently
<akanouras> Hi all, how can I stop the 22.03.3 SDK from recompiling Python and all its dependent packages every time I compile my python package using "make package/python-mypackage/compile" ?
<karlp> looks like I'll even get iceland sometime.
<karlp> unless that just means they have akamai caching stuff, which wouldnt be new
<jow> akanouras: make menuconfig, Advanced configuration options (for developers) ---> [ ] Automatic removal of build directories (NEW)
<jow> akanouras: untick that option
<dhewg> oh, bpf-headers has its own set of kernel headers
<Ansuel> yep and that should be used but for some reason xdp-tools is still using host stuff
<dhewg> if I read that patch correctly it doesn't forward BPF_CFLAGS from include/bpf.mk?
<dhewg> why's it not doing BPF_CFLAGS="$(BPF_CFLAGS) -I$(BPF_HEADERS_DIR)/tools/lib"" instead
<neggles> oliv3r[m]: https://paste.neggles.dev/R38qq
<neggles> i now know
<neggles> far more about postscript than i would like to
<Ansuel> dhewg any idea how to install bpf toolchain without compiling them?
<dhewg> CONFIG_USE_LLVM_HOST=y
<Ansuel> doesn't work...
<dhewg> which is what I because because llvm takes ages
<Ansuel> unless i'm missing some package
<dhewg> prolly that
<Ansuel> do you have a list by chance?
<dhewg> I do remember that debian's llvm packages are weird somehow
<Ansuel> using ubuntu
<dhewg> iirc you need to install llvm-dev
<dhewg> yeah same there
<Ansuel> libbpf support: FORCE_SYSTEM_LIBBPF is set, but no usable libbpf found on system
<dhewg> this is on my local debian http://sprunge.us/sYSO9T
<dhewg> that works for me
<dhewg> and I'm using qosify, so its always used for me
Ryncewynd has joined #openwrt-devel
<neggles> oh and mrkiko too - see above :P
<neggles> pikepdf is a bit opaque and obtuse but it does the job
<dhewg> neggles: does my oneliner work on your pdfs?
<neggles> ummm which one was that
<neggles> i got lost in python for like 2 hours
<dhewg> hehe, this one: qpdf --json --json-stream-data=file in.pdf out.json; for i in `grep -Hi confidential *.json-*|cut -d':' -f1`; do cp /dev/null $i; done; qpdf --json-input out.json out.pdf
<neggles> ah, no
<neggles> i don't think?
<neggles> lets see
<Ansuel> fk this i'm doing it... compiling llvm again...
<neggles> ansuel please
<neggles> you're better than this :P
<akanouras> jow: That did it, thank you very much!
<slh64> mrkiko: dynalink https://forum.openwrt.org/t/dynalink-dl-wrx36-askey-rt5010w-ipq8074-openwrt-support/110454/475 BT home hub 5a is quite difficult, soldering to small/ fragile vias, TP-Link archer c2600 as well, solder points hidden under the SOCs rf can, missing components to retrofit, level shifter for 1.8V
<neggles> i think my qpdf is old
<neggles> qpdf: unrecognized argument --json-stream-data=file
<dhewg> sounds like that, that arg spits out one json file per stream, so messing around with standard tools becomes easy
<dhewg> like cp /dev/null for those watermarks hehe
<neggles> `WARNING: in.pdf (offset 2301800): error decoding stream data for object 14553 0: stream inflate: inflate: data: incorrect header check`
<slh64> mrkiko: but I'm sure there's even worse. the dynalink shouldn't be too bad, case can be opened without too much fuss, pre-populated serial header - as long as you have a matching connector (2mm? spacing, don't have that device myself)
<neggles> tbh that's what my python script there is doing
<neggles> but it's filtering based on the color
<neggles> slh64: there's the OC200, too - needs a teeny weeny level shifter soldered in
<neggles> but we've got that one working-ish already
<neggles> (and it is also kind of lame)
<stintel> kind of? very lame ;)
<Ansuel> [64/3517] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Locale.cpp.oautoreconf:
<Ansuel> here we go again -.-
<stintel> my attempts to overwrite the RSA key in the OC200's SPI-NOR and then signing the OpenWrt image got nowhere
<mrkiko> slh64: thanks a lot, you gave me some good examples
<mrkiko> slh64: the person helping me works on data recovery stuff actually, and wanted to know how complicated it can get to help me out with router UART ports soldering and flash access
<Ansuel> robimarko chose a color for ipq807x tag
<Ansuel> actually no they should be all blue
Znevna has joined #openwrt-devel
<Znevna> I've pushed a button haven't I x.x
<robimarko> Ansuel: Blue is calming
<f00b4r0> ;)
<robimarko> Ansuel, BTW NSS-DRV is working quite good
<robimarko> Its reducing the CPU usage drastically
<robimarko> And we are just pushing the traffic through it, not really offloading anything
<mrkiko> robimarko: purple
<mrkiko> robimarko: or magenta
Tapper has joined #openwrt-devel
<gch981213> Is that some software engineering stuff?
<Habbie> "Complete innovate phase"
<Habbie> carefully dosed innovation
<f00b4r0> it looks like VC pitch bs
<Habbie> it looks like the plans i find in our Jira
<f00b4r0> i've seen worse.
<Habbie> or Confluence
<robimarko> Its so nice to see development reinvented
<f00b4r0> ;)
<mrkiko> neggles: how does the RSA key thing work? :D
<mrkiko> neggles: I mean - is it used by the bootloader to check kernel+rootfs or what?
<oliv3r[m]> hah, it's a plantuml version of the clock tree of the RTL9300 CPU :p
mrkiko has quit [Quit: leaving]
csrf has quit [Ping timeout: 480 seconds]
<Ansuel> ERROR: tools/llvm-bpf failed to build.
<Ansuel> -.-''''
owrt-snap-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-snap-builds has joined #openwrt-devel
mrkiko has joined #openwrt-devel
<oliv3r[m]> so much fun :)
<owrt-snap-builds> Build [#769](https://buildbot.openwrt.org/master/images/#builders/10/builds/769) of `bcm63xx/smp` failed.
<dhewg> don't underestimate the build times if you wanna build llvm for ci or buildbot, is that really what you wanna do?
<owrt-snap-builds> Build [#773](https://buildbot.openwrt.org/master/images/#builders/27/builds/773) of `mpc85xx/p1020` failed.
<owrt-snap-builds> Build [#813](https://buildbot.openwrt.org/master/images/#builders/3/builds/813) of `at91/sam9x` failed.
<owrt-snap-builds> Build [#312](https://buildbot.openwrt.org/master/images/#builders/77/builds/312) of `realtek/rtl839x` failed.
<owrt-snap-builds> Build [#771](https://buildbot.openwrt.org/master/images/#builders/17/builds/771) of `ramips/rt305x` failed.
<owrt-snap-builds> Build [#767](https://buildbot.openwrt.org/master/images/#builders/14/builds/767) of `bcm63xx/generic` failed.
<mrkiko> dhewg you're so right... so much I actually configured the buld to use host llvm / clang
<dhewg> yeah, and on top its build folder is huge and linking it requires a shitton on memory due to lto
<Ansuel> i'm scared guys
<Ansuel> now i'm running with no multicore since i think on linking it goes oom
<dhewg> that will speed things up lol
<mrkiko> Ansuel: how much RAM memory? maybeyou said it whileI was disconnected from IRC
<Ansuel> it's a wsl instance so it does have some default limits
<Ansuel> i was having fun with a scammer on ebay so i didn't check where it failed but when i rechecked the console llvm was failed....
<dhewg> ohboi, what are you doing to yourself
<dhewg> wsl _and_ llvm
<dhewg> the pain
<Ansuel> wsl2 so it's actually just a vm
<oliv3r[m]> Ansuel: pff, I have a 12 year old PC (running arch/docker) and it worked just fine :)
<Ansuel> ok with -j1 the thing took ages to compile...
<dhewg> I'm not sure what you're trying to solve, but there's CONFIG_HAS_PREBUILT_LLVM_TOOLCHAIN too
<dhewg> and wasn't that prebuilt thing hosted somewhere?
<Ansuel> trying to bisect the xdp-tools problem...
valku has joined #openwrt-devel
<Ansuel> ok nice i manage to repro
<Ansuel> how xdp-tools works on buildbot o.O
<Ansuel> i'm confused now
<Ansuel> warning: /home/ansuel/openwrt-ansuel/openwrt/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-12.2.0_musl_eabi/include: linker input file unused because linking not done
<Ansuel> and host is used /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
<stintel> Wed Jan 18 14:47:03 2023 daemon.debug avahi-daemon[3928]: sendmsg() to ff02::fb failed: Network unreachable
<stintel> keep hitting this
<stintel> while ping6 ff02::fb works fine
<stintel> anyone a clue what's up with that?
<Ansuel> mhhh in theory they use socket or something like that so it may be a permission problem
<Ansuel> avahi user doesn't have access
<stintel> hmmm it's running as user nobody but I'm not finding where this is configured
<Ansuel> it's the default
<Ansuel> you should try to run as root and check if the same problem is there
<stintel> yes but how
<stintel> I don't find the option
<stintel> ah
<stintel> --no-drop-root
<stintel> same problem
<stintel> confirmed in ps output it's running as root
<stintel> guess I'm gonna have to modify the code to add more info to that error message
<Ansuel> yep but i'm afraid they will use socket shared stuff so it's nothing custom
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 99.6% packages reproducible in our current test framework.)
<robimarko> We have an epidemic of builders failing on git rev-parse
<Ansuel> guess caused by the buildbot restart?
<f00b4r0> the gitcheckout step is probably the culprit. I've pruned that in the rework.
<owrt-snap-builds> Build [#445](https://buildbot.openwrt.org/master/images/#builders/73/builds/445) of `imx/cortexa7` completed successfully.
minimal has joined #openwrt-devel
<stintel> Wed Jan 18 15:14:44 2023 daemon.debug avahi-daemon[1768]: sendmsg() to ff02::fb failed: Network unreachable (fd: '12', flags: '0')
<owrt-snap-builds> Build [#761](https://buildbot.openwrt.org/master/images/#builders/35/builds/761) of `mvebu/cortexa72` completed successfully.
<stintel> lrwx------ 1 root root 64 Jan 18 15:13 /proc/1768/fd/12 -> socket:[9855]
<stintel> sl local_address remote_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops
<stintel> 33: 00000000000000000000000000000000:14E9 00000000000000000000000000000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 9855 2 00000000ac88767e 0
<Ansuel> wonder if there is a problem in the socket creation ?
<stintel> so I found the socket at least
<Ansuel> is the address correct?
<stintel> the address is 0
<stintel> dunno what that means
<stintel> the only socket in /proc/net/udp6 with port 14e9 (5353) also has local and remote address 0
<stintel> and I'm not seeing the error there
<stintel> maybe this is some missing kernel option
<stintel> +on my workstation
<robimarko> f004br0: I have been seeing this failure on more and more builds
<robimarko> Usually in batches
<Znevna> 0o
<Ansuel> i'm starting to think llvm is including host header
<Ansuel> any idea how to check clang default include?
<robimarko> You mean when its building on host?
<Ansuel> yes
<robimarko> I mean, building LLVM itself?
<robimarko> Cause, that is supposed to use host headers isnt it?
<f00b4r0> robimarko: the step disrupts the normal git step from buildbot, which then ends up in an abnormal state which is caught by gitverify, which is what you see failing.
<f00b4r0> anyway, this is supposed to be fixed.
<robimarko> I am eagerly waiting for ipq807x images, but it failed 2 times already on weird stuff like this
<stintel> some posts claim this is due to firewall, but this image doesn't have iptables nor nftables installed, nor does it have any netfilter kmods
<stintel> if (ipv6_only_sock(sk)) return -ENETUNREACH;
<stintel> hmmm both the openwrt device and my workstation have net.ipv6.bindv6only = 0
Acinonyx has joined #openwrt-devel
<owrt-snap-builds> Build [#125](https://buildbot.openwrt.org/master/images/#builders/80/builds/125) of `mediatek/filogic` completed successfully.
Acinonyx_ has quit [Ping timeout: 480 seconds]
<ynezz> robimarko: I've added 15 build workers to cleanup that mess, so hopefully soon
<Ansuel> ynezz any idea what happen ?
<ynezz> those are ephemeral build workers based on hetzner VPSes, so they start building from clean state, from scratch
<ynezz> and there is probably some issue in that git rev-parse step so it fails once
<ynezz> on the clean build worker, thats it
<robimarko> ynezz: thanks
<Ansuel> robimarko now that i think about it yes it's correct and expected that it does user host header
<Ansuel> but it's not ok if they are also included for package compile i guess
<robimarko> Correct
<Ansuel> and this is the problem linux/types.h is used instead of the one that should provide bpf-header i think
<Ansuel> for some reason this should provide linux/types.h
<Ansuel> -I$(BPF_HEADERS_DIR)/include
<Ansuel> but /usr/include/linux/types.h is used
<dhewg> BPF_CFLAGS from bpf.mk should have everything you need
<dhewg> as I mentioned earlier, the patch you linked to might have removed those
<Ansuel> they don't fix it it seems
<dhewg> no idea why that modifies created files in the build dir though
<owrt-snap-builds> Build [#800](https://buildbot.openwrt.org/master/images/#builders/8/builds/800) of `x86/64` completed successfully.
<dhewg> can you verify those flags are still used?
<Ansuel> dhewg any hint on how to do that?
<dhewg> not rly, but the patch reads like those should be in $BUILD_DIR/config.mk
<stintel> maybe it's because of CONFIG_IPV6_MROUTE=y or CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y
<stintel> gonna build with that disabled
<Ansuel> config.mk have that on the last line
<Ansuel> BPF_CFLAGS += -I/home/ansuel/openwrt-ansuel/openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/bpf-headers/tools/lib
<dhewg> what if you use 'BPF_CFLAGS="$(BPF_CFLAGS) -I$(BPF_HEADERS_DIR)/tools/lib"'
<Ansuel> this in config_var or the build/configure?
<dhewg> 85,14 +85,18 @@ CONFIGURE_VARS
<Ansuel> nope same thing
<dhewg> BPF_CFLAGS in config.mk should be rather long now?
<dhewg> there's CompileBPF in bpf.mk too, maybe that needs to be extended?
<Ansuel> openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/bpf-headers/arch/mips/include/generated -I/home/ansuel/openwrt-ansuel/openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/bpf-headers/include -I/home/ansuel/openwrt-ansuel/openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/bpf-headers/arch/mips/include/uapi -I/home/ansuel/openwrt-ansuel/openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/
<Ansuel> BPF_CFLAGS="-nostdinc -isystem /home/ansuel/openwrt-ansuel/openwrt/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-12.2.0_musl_eabi/include -I/home/ansuel/openwrt-ansuel/openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/bpf-headers/arch/mips/include -I/home/ansuel/openwrt-ansuel/openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/bpf-headers/arch/mips/include/asm/mach-generic -I/home/ansuel/openwrt-ansuel/
<Ansuel> bpf-headers/arch/mips/include/generated/uapi -I/home/ansuel/openwrt-ansuel/openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/bpf-headers/include/uapi -I/home/ansuel/openwrt-ansuel/openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/bpf-headers/include/generated/uapi -I/home/ansuel/openwrt-ansuel/openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/bpf-headers/tools/lib -I/home/ansuel/openwrt-ansuel/
<Ansuel> D__TARGET_ARCH_mips -mlittle-endian -fno-stack-protector -Wall -Wno-unused-value -Wno-pointer-sign -Wno-compare-distinct-pointer-types -Wno-gnu-variable-sized-type-not-at-end -Wno-address-of-packed-member -Wno-tautological-compare -Wno-unknown-warning-option -fno-asynchronous-unwind-tables -Wno-uninitialized -Wno-unused-variable -Wno-unused-label -O2 -emit-llvm -Xclang -disable-llvm-passes -I/home/ansuel/openwrt-ansuel/openwrt/
<Ansuel> openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/bpf-headers/tools/testing/selftests -I/home/ansuel/openwrt-ansuel/openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/bpf-headers/samples/bpf -include linux/kconfig.h -include asm_goto_workaround.h -I/home/ansuel/openwrt-ansuel/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/xdp-tools-1.2.9 -D__KERNEL__ -D__BPF_TRACING__ -DCONFIG_GENERIC_CSUM -
<Ansuel> staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/bpf-headers/tools/lib"
<Znevna> we can all agree that those logs look better in a pastebin? :P
<dhewg> that's long, alright
<Ansuel> totally sorry
<Znevna> surprised the server didn't boot you xD
<dhewg> well, dunno then, but gotta run, good luck
<Ansuel> rip thanks for the help
torv has quit [Remote host closed the connection]
<stintel> ok looks like it's related to avahi trying to send packet on the wpan0 interface
<stintel> I can probably just ignore that
<stintel> hmmmz, or not, removed wpan0 and still seeing it
<stintel> sigh
torv has joined #openwrt-devel
dangole has joined #openwrt-devel
<owrt-snap-builds> Build [#789](https://buildbot.openwrt.org/master/images/#builders/4/builds/789) of `x86/generic` completed successfully.
<owrt-snap-builds> Build [#770](https://buildbot.openwrt.org/master/images/#builders/10/builds/770) of `bcm63xx/smp` completed successfully.
<owrt-snap-builds> Build [#814](https://buildbot.openwrt.org/master/images/#builders/3/builds/814) of `at91/sam9x` completed successfully.
<owrt-snap-builds> Build [#766](https://buildbot.openwrt.org/master/images/#builders/44/builds/766) of `mediatek/mt7622` completed successfully.
<owrt-snap-builds> Build [#766](https://buildbot.openwrt.org/master/images/#builders/67/builds/766) of `sunxi/cortexa8` completed successfully.
<owrt-snap-builds> Build [#769](https://buildbot.openwrt.org/master/images/#builders/25/builds/769) of `rockchip/armv8` completed successfully.
<Ansuel> dhewg btw BPF_CFLAGS are totally not used
<owrt-snap-builds> Build [#776](https://buildbot.openwrt.org/master/images/#builders/20/builds/776) of `gemini/generic` completed successfully.
<owrt-snap-builds> Build [#3](https://buildbot.openwrt.org/master/images/#builders/81/builds/3) of `ipq807x/generic` completed successfully.
<owrt-snap-builds> Build [#273](https://buildbot.openwrt.org/master/images/#builders/79/builds/273) of `ipq40xx/chromium` completed successfully.
<dhewg> Ansuel: huh something is fishy, eh. gonna take a peek
<Ansuel> dhewg in short what i discover... CONFIGURE_VARS won't apply any BPF_CFLAGS and everything from host is used
<Ansuel> with the current build/configure
<Ansuel> stuff is appended to config.mk
<Ansuel> and that way flags are actually appended to the xdp-tools source compilation
<Ansuel> but adding all of them result in a big amount of compilation error...
<Ansuel> VERY FUN
<owrt-snap-builds> Build [#313](https://buildbot.openwrt.org/master/images/#builders/77/builds/313) of `realtek/rtl839x` completed successfully.
<owrt-snap-builds> Build [#772](https://buildbot.openwrt.org/master/images/#builders/17/builds/772) of `ramips/rt305x` completed successfully.
<karlp> jow: luci-base, status->firewall points to "nftables" (luci-mod-status->view/status/nftables.js) and that requires tools.firewall... but that file is only inside luci-app-firewall?
<owrt-snap-builds> Build [#774](https://buildbot.openwrt.org/master/images/#builders/27/builds/774) of `mpc85xx/p1020` completed successfully.
<karlp> I get a 404 loading the page, but I dont't think I've done anything wrong per se?
<karlp> (I don't have luci-app-firewall installed, obviously, it's not a selected dependency or anything)
<dhewg> Ansuel: not just that... PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace
<owrt-snap-builds> Build [#768](https://buildbot.openwrt.org/master/images/#builders/14/builds/768) of `bcm63xx/generic` completed successfully.
<owrt-snap-builds> Build [#758](https://buildbot.openwrt.org/master/images/#builders/31/builds/758) of `layerscape/armv8_64b` completed successfully.
<Ansuel> dhewg eh problem is that it's proably a mix in our including stuff and their... but thing is that bridger and qosify doesn't suffer from this with our BPF_CFLAGS so i really don't know if there is something wrong in our include
<dhewg> dunno, all this looks specific to this package
<owrt-snap-builds> Build [#768](https://buildbot.openwrt.org/master/images/#builders/53/builds/768) of `bcm27xx/bcm2711` completed successfully.
<dhewg> way to annoying :qa!
noltari has quit [Quit: Bye ~ Happy Hacking!]
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
<Ansuel> dhewg the xdp-tool source is a mess
<Ansuel> ...
<Ansuel> but is fixable
<Ansuel> example
<Ansuel> __attribute__ ((noinline))
<Ansuel> to __attribute__ ((__noinline__))
<jayk> wonder what causes AMDGPU linker errors when building openwrt
<dhewg> Ansuel: it is, and I'm not touching that mess
<dhewg> but the mess starts at the bpf kernel headers
<Ansuel> also each subdir enforce their own special cflags o.O
<Ansuel> i fixed all the compilation error
<Ansuel> we should move
<Ansuel> -target $(BPF_ARCH)-linux-gnu
<Ansuel> to the BPF_CFLAGS
<Ansuel> or the header doesn't have a way to select mips defines
<Ansuel> with that it's just a matter of disabling Werror cflags and fix some small error in xdp-tools
<Ansuel> also we use xodeload for xdp...
<Ansuel> bad
<dhewg> maybe, but that may not be sufficient. it may produce non working binaries
<Ansuel> nha things are working currently by luck by using host header and gcc-multiplib
<Ansuel> for xdp-tools we are not using bpf headers at all
<dhewg> indeed, but that is prolly the solution
<dhewg> i.e. hack xdp-tools to use CompileBPF
noltari has joined #openwrt-devel
<dhewg> my favorite stacks, some dependency that's hacked to make it work for some environment and everything that doesn't utilizes that doesn't werk
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 99.6% packages reproducible in our current test framework.)
cbeznea has quit [Quit: Leaving.]
<dhewg> or maybe wipe xdp's headers/ and force it to use OpenWrt's
<robimarko> Ansuel: We are down to only XDP packages not building and libltdl7 not being reproducible
<Ansuel> what is libtld7 o.o
<robimarko> No idea
cbeznea has joined #openwrt-devel
<Ansuel> /home/ansuel/openwrt-ansuel/openwrt/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/bpf-headers/include/net/flow_offload.h:324:4: error: use of undeclared identifier 'KBUILD_MODNAME'
srslypascal is now known as Guest1755
srslypascal has joined #openwrt-devel
Guest1755 has quit [Ping timeout: 480 seconds]
cbeznea1 has joined #openwrt-devel
cbeznea has quit [Read error: Connection reset by peer]
noltari has quit [Quit: Bye ~ Happy Hacking!]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
cmonroe has quit [Quit: Textual IRC Client: www.textualapp.com]
noltari has joined #openwrt-devel
noltari has quit []
Ryncewynd has quit [Read error: Connection reset by peer]
noltari has joined #openwrt-devel
Ryncewynd has joined #openwrt-devel
noltari has quit [Quit: Bye ~ Happy Hacking!]
cmonroe has joined #openwrt-devel
Ryncewynd has quit [Quit: Leaving]
Borromini has joined #openwrt-devel
Thagabe has joined #openwrt-devel
<Thagabe> Howdy
netprince_ has quit [Read error: Connection reset by peer]
borek has quit [Ping timeout: 480 seconds]
<Ansuel> ok well now i need some tester for xdp-tools :D
cbeznea1 has quit [Quit: Leaving.]
noltari has joined #openwrt-devel
noltari has quit []
noltari has joined #openwrt-devel
csrf has joined #openwrt-devel
<dhewg> "fun" he said
<Ansuel> :D
<Ansuel> well the thing is half done... i drop Werror but we should really enforce other stuff...
<nbd> Ansuel: with those fixes it even builds on macos now :)
<Ansuel> oh wow
<nbd> the approach looks good to me
<robimarko> You have a weird sense of fun, but thanks for hunting this craziness down
<Ansuel> can someone test it?
<neggles> mrkiko: the RSA key thing on the OC200? IIRC the stock firmware's update script looks for a somewhat weird signature format, signed with a key whose public key is just stored in flash (there's no signature verification in u-boot)
<Ansuel> >:(
<neggles> i mean the only xdp program pair I've written so far is absolutely cursed
<neggles> how would you forward packets between two NIC ports *without* using a bridge
hauke has quit [Quit: WeeChat 3.7.1]
<neggles> bridges don't handle 90Gbps of 150-byte packets very well, you see
<robimarko> Well, it looks like I am gonna be in a position to investinga using ebpf for dhcp snooping
<robimarko> Mind you, newer wrote an ebpf program so far
hauke has joined #openwrt-devel
<neggles> xdp would probably be good for that https://github.com/xdp-project/BNG-router/tree/main/dhcp-relay
<robimarko> Thanks for that
bookworm has joined #openwrt-devel
hauke has quit [Quit: WeeChat 3.7.1]
hauke has joined #openwrt-devel
bluew has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
robimarko has quit [Quit: Leaving]
Thagabe has quit [Remote host closed the connection]
Thagabe has joined #openwrt-devel
Ansuel_ has joined #openwrt-devel
<Ansuel_> love my isp that decide to kill my connection on 00:15 due to maintenance
Ansuel has quit [Ping timeout: 480 seconds]
Ansuel has joined #openwrt-devel
Ansuel_ has quit [Read error: Connection reset by peer]
Ansuel_ has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]