<dhewg>
it's pretty nice that one doesn't have to do a single thing for master and use ci on private forks
<Ansuel>
but honestly i would do 11426... publish the tools container.... hardcode.... and backport to stable release
<Ansuel>
the hardcode part is not trivial since I will have to introduce some args and deny building if the author is not openwrt
<dhewg>
I never used it, but isn't the sdk just that in another shape?
<Ansuel>
yes and no
<Ansuel>
the benefits of this is that you will have a full buildroot ready to use and do whatever changes you need
<Mangix>
faster ci?
<Ansuel>
Mangix with 11652 we would use container with toolchain directly installed so the github cache will use only for ccache
<Ansuel>
and cache toolchain is flawed since buildbot will recompile and change hash for every build
<Ansuel>
ideally i would like to check if there is a way to have something like the precompiled host tools even for the toolchains... that way if something change down the line the package is just recompiled
<Ansuel>
well for sure that line needs to be updated to match correct abi version
<Ansuel>
but yes you theory may be correct
<dhewg>
even if all his packages are bumped and hence depending on the new version, will opkg wipe the old one?
<dhewg>
this shouldnt be a new problem
<Ansuel>
that can be tested but i think not
<dhewg>
and I don't know of a global solution for this problem
<Ansuel>
postinst script that wipe any old version of the lib
<dhewg>
ok good, so maybe bump all that crap manually now? :\
<Ansuel>
but they should be all recompiled due to the changed abi
<dhewg>
and I think they are
<dhewg>
but since the version isnt bumped, a local opkg wont fetch&install
<dhewg>
I assume at least
<dhewg>
which is why I wanna know if `opkg install --force-reinstall` fixes it
<dhewg>
as we saw, EXTRA_DEPENDS has a ">= $DATE" feature, we really could use a "== ABI_VERSION" one
<dhewg>
every package is compiled against a specific abi, not more or less
<Ansuel>
but how wpad works with wolfssl abi
<Ansuel>
it should be a similar problem
<dhewg>
iirc there was a "bump all packages which use wolfssl" commit some time ago
<dhewg>
ee47a28cec01c7943238bae45f65a98e4fc9abbe
<Ansuel>
yes just notice that
<dhewg>
how annoying
<Ansuel>
oh well not that much
<dhewg>
still, we tried pretty hard to not break anything and then there's this silly issue
<Ansuel>
it's just abi hell
<Ansuel>
so i guess grep -rnw . -e libiwinfo
<dhewg>
`git grep` is your friend
<dhewg>
I posted a list where the user reported the issue
<Ansuel>
they are all the package?
<dhewg>
i think so
<dhewg>
the lua bindings are unchanged, so we can ignore those I think
aiyion_ has quit [Remote host closed the connection]
aiyion_ has joined #openwrt-devel
<philipp64>
couple of questions about x86 partitions... what .config setting decides if you have MBR or GPT? and on an existing MBR system, can it be converted after-the-fact to GPT? I guess on the running system you use gptfdisk and... what else? I guess grub needs to be reinstalled... what arguments?
<Ansuel>
waiting for ci to complay for packages release to replace them
<dhewg>
nice, thanks for taking care or it!
<tmn505>
philipp64: 1) that's per image setting, not definiable; for 64 subtarget has defined *-efi image, it passes GUID to $(SCRIPT_DIR)/gen_image_generic.sh (https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/x86/image/Makefile#l51). 2) It probably can be converted but I don't know how it will behave, didn't test. 3) gptdisk should suffice but make sure to set PART/UUID to what expets
<tmn505>
kernel as rootfs. 4) https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/x86/base-files/lib/upgrade/platform.sh#l61. Before doing any of that on running system better try it out in VM first.
<philipp64>
I was just looking at 4 trying to figure out what args to use...the device.map isn't obvious...
<tmn505>
yeah, for me it also was not clear at first, but it was so long ago I would need to trace now what goes where
<tmn505>
especially since grub-bios-install was undocumented when I worked with it, don't know if that changed
Renaud11232 has joined #openwrt-devel
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
Renaud11232 has quit [Quit: Page closed]
dansan has joined #openwrt-devel
valku has joined #openwrt-devel
Borromini has joined #openwrt-devel
c0xc has joined #openwrt-devel
gladiac has quit [Quit: k thx bye]
<philipp64>
tmn505: no idea what the "device map" is supposed to be...
<tmn505>
philipp64: the map should contain mapping of bios disk names to linux device (may be an disk image), example: (hd0) /dev/sda. TBF I don't know if when installing to GPT disk it's still necessary. https://www.gnu.org/software/grub/manual/grub/grub.html#Device-map
<philipp64>
the bootloader upgrade script still uses it...
srslypascal has quit [Ping timeout: 480 seconds]
<philipp64>
tmn505: do you know when/how platform.sh decides to convert the image from MBR (msdos) to GPT?
<tmn505>
philipp64: there is no conversion, either You use GPT (*-efi) image or MBR (no suffix) one
Borromini has quit [Quit: Lost terminal]
srslypascal has joined #openwrt-devel
<philipp64>
hang on... /sbin/sysupgrade contains:
<philipp64>
COMMAND='/lib/upgrade/do_stage2'
<philipp64>
and that's in package/base-files/files/lib/upgrade/do_stage2... and it contains:
<philipp64>
platform_do_upgrade "$IMAGE"
<tmn505>
that's common for all targets, there's nothing speciffic for x86
<tmn505>
if You mean how platform.sh distinguishes what image has been fed, check line nr 58 in platform.sh (part_magic_efi "/dev/$diskdev" && parttable=gpt) and later how it's used
<philipp64>
so potentially any sysupgrade can invoke platform_do_upgrade() which can invoke platform_do_bootloader_upgrade() ...
<tmn505>
genrally yes
<tmn505>
*generally
<philipp64>
ah. so it will only install GPT on an EFI platform?
<philipp64>
that seems like an unnecessary limitation.
<tmn505>
well no one has tested if it works MBR -> GPT and other way around
<philipp64>
I tried to create device.map by hand and run the same grub-bios-setup commands, but it craps the bed with:
<philipp64>
grub-bios-setup: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
<philipp64>
grub-bios-setup: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
<tmn505>
philipp64: don't know what that exactly means. Older images might have different partition layout, what's fdisk -l output of the disk You are trying to install to
<tmn505>
?
Ryncewynd has quit [Quit: Leaving]
<tmn505>
philipp64: LOL, as I just had an x86 system with OpenWrt booted with MBR image on USB stick got the *-efi image from same compilation and fed it to sysupgrade... it worked.
<tmn505>
so it seems it didn't work at first, but at some point someone fixed it alog the way or I was mistaken the whole time.
<tmn505>
probably yes, but as I said, I don't know how it'll behave
<tmn505>
with older partition layout
<slh>
there are quite a few gotchas with GPT on BIOS systems, while it 'should' all work, some early UEFI firmwares that didn't even expose their EFI persona to the outside and were legacy-CSM-only crap out badly when they see GPT. some need an 'active' partition on the protective mbr, some mustn't have that, lots of fun
oftcrandomnick has joined #openwrt-devel
<oftcrandomnick>
hello
<slh>
yes, you very often get it to work, but depending on the target board, you will have to prepare the image differently
<oftcrandomnick>
Ansuel please can you tell me if its good to return this AP i bought as the return window is closing soon :(
<_2in2>
Hello, I'm trying to figure out how to correctly define nand partition in the device tree. I get the 3 main partitions to show up but I just can't figure out how to make ubi work with them.
<slh>
oftcrandomnick: unless /you/ feel confident to do 98% of porting/ development work, it's probably better to return it - there's no one else with that hardware to do it for you. while it 'should' be reasonable, it still needs doing (and can't be done remotely over the internet)
<slh>
and there's always a latent risk that the vendor nailed shut u-boot and shell access
<oftcrandomnick>
slh how can I verify that vendor shut u-boot and shell access
<slh>
only by trying
<oftcrandomnick>
slh I can put time in it, but I am not sure where to start as I only know basic of C language
<slh>
really, if you need to ask, you won't get it done. it's as simple as that. yes, you can port a device from zero knowledge, but it would be a (very) steep learning curve
<oftcrandomnick>
where can I send the hardware to have it ported?
<slh>
if you have time, ambition and pocket money to accept failure, by all means - go for it. if not, reduce your list of purchases to already supported devices
<oftcrandomnick>
well, i have some money I can spend on this for porting, i have give couple hours here and there