search

AsteroidOS / meta-bass-hybris

OpenEmbedded layer that provides libhybris support for the LG G Watch Urbane. (Merged to: https://github.com/AsteroidOS/meta-smartwatch)
GNU General Public License v2.0
11 stars 6 forks source link

Cannot update my watch with OPKG over USB #10

Closed mbistricic closed 4 years ago

mbistricic commented 4 years ago

I have configured a NAT on my computer and configured a default gateway and DNS on my watch. I can ping www.google.com and release.asteroidos.org from my watch. After I try to update with "opkg update" I get following errors: Collected errors:

I have noticed that there is no Packages.gz file in https://release.asteroidos.org/nightlies/ipk/bass/

Can anyone help please?

dalz commented 4 years ago

Same issue on harmony (kw88 pro). When I try to download the files with wget, I get this error:

root@harmony:~# wget https://release.asteroidos.org/nightlies/ipk/all/Packages.gz
Connecting to release.asteroidos.org (89.163.240.209:443)
wget: note: TLS certificate validation not implemented
wget: TLS error from peer (alert code 40): handshake failure
wget: error getting response: Connection reset by peer
ghost commented 4 years ago

We are checking while these files are not served.

mbistricic commented 4 years ago

I would really appreciate to solve this because it is the only way to update my watch - it does not get detected by adb and/or bluetooth.

mbistricic commented 4 years ago

Although I can see Packages.gz in https://release.asteroidos.org/nightlies/ipk/bass/, I still have the same errors on opkg update. I have tried downloading it with wget and got the same errors as dalz: root@bass:~# wget https://release.asteroidos.org/nightlies/ipk/bass/Packages.gz Connecting to release.asteroidos.org (89.163.240.209:443) wget: note: TLS certificate validation not implemented wget: TLS error from peer (alert code 40): handshake failure wget: error getting response: Connection reset by peer

mbistricic commented 4 years ago

Sorry, my bad. The Packages.gz files are in https://release.asteroidos.org/1.0/ipk/ (not nightlies). @ledixus Why don't you just copy them to the https://release.asteroidos.org/nightlies/ipk/ ? I have noticed that the .ipk file names are all identical as in https://release.asteroidos.org/1.0/ipk/. (probably MD5Sum won't match so MD5Sum regeneration will be needed)

FlorentRevest commented 4 years ago

@mbistricic Yocto must have changed the way it outputs an ipk repository. The nightlies server just copies it from the Yocto build directory to release.asteroidos.org. I do not have the time to look into this yet and @ledixus maintains the server but he isn't aware of the details of ipk generation in Yocto. If you want to help, I would recommend either trying to change your opkg config in your watch to match what's on the server, or compile AsteroidOS and figure out what changed with the ipk repository generation so that we can adapt our nightly copying instructions accordingly.

mbistricic commented 4 years ago

@FlorentRevest Thanks for the prompt answer. I will try both of yours recommendations and come back here with the results.

MagneFire commented 4 years ago

From my understanding we are using the deploy directory as the package feed. It looks like the deploy directory for the package manager has changed to the ${WORKDIR}/oe-rootfs-repo when creating the package-index(Package.gz)[0] When analyzing the log files this appears to be true. The index file is located here(/asteroid/build/tmp-glibc/work/sturgeon-oe-linux-gnueabi/asteroid-image/1.0-r0/oe-rootfs-repo/all/Packages)

The solution is to run bitbake package-index manually. This creates a package index for the deploy directory. I tried to do this within a recipe but for some reason it doesn't trigger the do_package_index() function in package-index. Perhaps we can incorporate this command after bitbake asteroid-image for the build server?

References: [0] https://github.com/openembedded/openembedded-core/commit/c7c5f4065c102fde4e11d138fb0b6e25bffe0379#diff-c5130ef47a8c44ef3dc72358e5dd3ed0 [1] https://github.com/openembedded/openembedded-core/blob/warrior/meta/lib/oe/package_manager.py#L221 [4] https://www.toradex.com/community/questions/44861/yocto-bsp30-package-management-not-deploying-packa.html [2] https://github.com/openembedded/openembedded-core/commits/warrior/meta/lib/oe/package_manager.py [3] https://github.com/openembedded/openembedded-core/commits/warrior/meta/lib/oe/rootfs.py

ghost commented 4 years ago

@mbistricic @dalz the Packages.gz files are served now.

@MagneFire thanks for solving it :)

mbistricic commented 4 years ago

Thank you all!!!