search

lineageos4microg / docker-lineage-cicd

Docker microservice for LineageOS Continuous Integration and Continous Deployment
https://hub.docker.com/r/lineageos4microg/docker-lineage-cicd
GNU General Public License v3.0
492 stars 194 forks source link

No New Builds for Any Lineage for Micro G Devices #166

Closed YoungRiker closed 3 years ago

YoungRiker commented 3 years ago

What is going on with Lineage for Micro G? Is the project continuing or not? A yes/no or alternatively additional info would be very much appreciated.

Jonny007-MKD commented 3 years ago

Yes, the last build was uploaded at 2021-02-05. @spolack? #159

HJMVR commented 3 years ago

I really hope that this project is still alive.

tokariu commented 3 years ago

it's been 2 month without any updates for most devices and without any information about the issue why that's the case (if you have information please tell us!) anyone who is involved with the project: please give us information about the status. we need to know whether this project: a) is going to be updated (at all) b) ETA when (if so) c) project is dead, we shall look for other ROM options with up2date security levels.

not knowing anything is the worst situation.

kurt-by commented 3 years ago

Despite the many contributes, running the build server is a one-man-show at the moment. Maybe we get a new round of builds next week.

bananer commented 3 years ago

@kurt-by can we do anything to improve this situation and to ensure this project remains alive? contributions of code, time or money?

kurt-by commented 3 years ago

@bananer now you can help with code https://github.com/lineageos4microg/android_prebuilts_prebuiltapks/issues/47

kurt-by commented 3 years ago

@bananer thank you @YoungRiker 17.1 builds are running now in alphabetical order.

martin-v commented 3 years ago

:+1: Thanks to both of you for your work!

Is there anything more we can help? e.g.: is it possible to find the build logfiles somewhere to investigate failing builds proactive?

YoungRiker commented 3 years ago

Thanks all!

uok commented 3 years ago

Looking at https://download.lineage.microg.org it seems the newest builds stopped at April 16th, most other device builds are dated March. It would be great to get this project going again! Looking for v18.1 for jasmine_sprout and can help testing. Thanks!

antoinevth commented 3 years ago

Actually, all devices have a build dated from April, except 5 of them. jasmine_sprout just got promoted to 18.1, so I guess it will get its build during the next 18.1 builds.

Iey4iej3 commented 3 years ago

+1 Thanks to both of you for your work!

Is there anything more we can help? e.g.: is it possible to find the build logfiles somewhere to investigate failing builds proactive?

Build logs would help, of course.

Iey4iej3 commented 3 years ago

Looking at https://download.lineage.microg.org it seems the newest builds stopped at April 16th, most other device builds are dated March. It would be great to get this project going again! Looking for v18.1 for jasmine_sprout and can help testing. Thanks!

I proposed more frequent builds. There might be difficulties to build frequently. I suppose that twice a month might be acceptable, but once a month would lead to problems now if there are issues in that build.

uok commented 3 years ago

@antoinevth, thanks for checking, I'm just trying to understand the build cycle. For example: device "pioneer" already has 2 MicroG v18.1 builds (April 4h and 11th) while last "jasmine_sprout" build dates back to March 28th. Also I don't understand how they "match" the dates of regular Lineage builds, where "pioneer" has 4 Lineage v18.1 builds (April 2nd, 8th, 15th, 22nd)

Iey4iej3 commented 3 years ago

@antoinevth, thanks for checking, I'm just trying to understand the build cycle. For example: device "pioneer" already has 2 MicroG v18.1 builds (April 4h and 11th) while last "jasmine_sprout" build dates back to March 28th. Also I don't understand how they "match" the dates of regular Lineage builds, where "pioneer" has 4 Lineage v18.1 builds (April 2nd, 8th, 15th, 22nd)

It is possible that the builds are still triggered manually.

amo13 commented 3 years ago

Looks like new builds are available again!

uok commented 3 years ago

Confirmed! Running jasmine_sprout 18.1 and all Micro G checks are green :heavy_check_mark: Thanks to all devs and contributors, this is a great project :+1:

cyko69 commented 3 years ago

No builds after 10.05.2021 02:37 (PL2), still waiting for whyred to be build.

martin-v commented 3 years ago

It looks like a lot of builds are failing again, the latest new build is PL2 2021-05-10, but a lot of devices don't have the May build yet. So I come back to my last question (@kurt-by): https://github.com/lineageos4microg/docker-lineage-cicd/issues/166#issuecomment-808172886

Akruidenberg commented 3 years ago

When will the new builds for cedric be available? 18.1 is out for this device. (moto g5)

cRaZy-bisCuiT commented 3 years ago

There are no more builds for lavender. The latest MicroG build is:

The latest LineageOS official build (non-MicroG) is:

In addition: The official LineageOS builds are already 18.1, while the latest MicroG build is still stuck at 17.1

What could we do to help to keep the builds automated running? Is there any kind of user interaction needed? Please advice. And please do also make the developement cycle a little more transparent to us. This is like a black box.

Thank you very much.

Iey4iej3 commented 3 years ago

Note that the pull request https://github.com/lineageos4microg/docker-lineage-cicd/pull/178 has not been merged. Maybe the developers are busy.

thrillfall commented 3 years ago

Looks like this horse is dead for now.

How about reviving it? Can somebody recommend a service where we could run the docker build containers and make the resulting images public? From my own experience it'll take at least 300GB storage and 32GB memory for a build during runtime

amo13 commented 3 years ago

You could turn an old laptop into a build server, keep it connected and running and dedicate it to that task. 300GB of storage should not be a problem and getting up to 32 GB RAM might well work with a big swap file on SSD. I'd be willing to help set up the OS, but I can't help with anything related to docker and the actual lineage build process.

Iey4iej3 commented 3 years ago

Looks like this horse is dead for now.

How about reviving it? Can somebody recommend a service where we could run the docker build containers and make the resulting images public? From my own experience it'll take at least 300GB storage and 32GB memory for a build during runtime

In addition, we first need maintainers - there are several unmerged pull requests which contain important bug fixes...

cRaZy-bisCuiT commented 3 years ago

And we also don't have the official signing keys I assume. No idea what went wrong here.

bananer commented 3 years ago

I'm happy to announce that this horse is not quite dead just yet!

I was invited to join the project as maintainer with access to the build server. Stay tuned!

Iey4iej3 commented 3 years ago

I'm happy to announce that this horse is not quite dead just yet!

I was invited to join the project as maintainer with access to the build server. Stay tuned!

Will your own pull requests be merged soon?

Shiandow commented 3 years ago

@bananer When you have access could you remove the latest builds for channel? The last build results in the SIM not working. See https://github.com/lineageos4microg/l4m_website/issues/77 for more info.

Iey4iej3 commented 3 years ago

A new round of building seems starting. Congratulations!

bananer commented 3 years ago

I merged most pull requests earlier, the updated image is available on docker hub.

Note that the round of builds which was started today still uses the old image, so #176 will not yet be fixed in them.

samsapti commented 3 years ago

Maybe a dumb question, but how does the building of L4M work? Does the build server(s) just pull the latest build of upstream LOS, apply the L4M patches, build the OS and push it to the downloads website, or how does that work?

A new round of building seems starting. Congratulations!

Does that mean that all devices will be built, or only some of them?

Iey4iej3 commented 3 years ago

I merged most pull requests earlier, the updated image is available on docker hub.

Note that the round of builds which was started today still uses the old image, so #176 will not yet be fixed in them.

Oh, that is a bit disappointing.

Iey4iej3 commented 3 years ago

Maybe a dumb question, but how does the building of L4M work? Does the build server(s) just pull the latest build of upstream LOS, apply the L4M patches, build the OS and push it to the downloads website, or how does that work?

A new round of building seems starting. Congratulations!

Does that mean that all devices will be built, or only some of them?

I guess that every round of building is for all devices, and for some of previous buildings, only some of these devices had updates because the building failed.

samsapti commented 3 years ago

Maybe a dumb question, but how does the building of L4M work? Does the build server(s) just pull the latest build of upstream LOS, apply the L4M patches, build the OS and push it to the downloads website, or how does that work?

A new round of building seems starting. Congratulations!

Does that mean that all devices will be built, or only some of them?

I guess that every round of building is for all devices, and for some of previous buildings, only some of these devices had updates because the building failed.

Okay, where do you see which builds failed and which succeeded?

bananer commented 3 years ago

Maybe a dumb question, but how does the building of L4M work? Does the build server(s) just pull the latest build of upstream LOS, apply the L4M patches, build the OS and push it to the downloads website, or how does that work?

Mostly, yes. This repository contains the code which executes these steps inside a docker container.

Does that mean that all devices will be built, or only some of them?

The currently running round of builds was started mostly to demostrate to me how the build server works internally. IIRC it will only build 18.1 devices.

Right now I don't yet have access to the build server nor a precise plan on how to continue running the builds in the future. Bear with me for a few days please, periodical builds for as many devices as we can support will come again soon.

bananer commented 3 years ago

Okay, where do you see which builds failed and which succeeded?

At the moment you can only see the zip files as results of successful builds

samsapti commented 3 years ago

@bananer if there's anything I can do, I'd be happy to help. I'm familiar with Linux server management and Docker, as well as some minor software development in Java.

cRaZy-bisCuiT commented 3 years ago

I can also help do deploy a CI/CD Pipeline which is automatically building new images and informs you about the status.

Iey4iej3 commented 3 years ago

By the way, if the builds are out once a month, then I would suggest that we apply the security patches every two months, so that there are two builds with the same security patch level, if possible. Otherwise, it would be troublesome if the package has a bug, since new Android does not allow us to revert to a nandroid backup with an earlier security patch level.

samsapti commented 3 years ago

By the way, if the builds are out once a month, then I would suggest that we apply the security patches every two months, so that there are two builds with the same security patch level, if possible. Otherwise, it would be troublesome if the package has a bug, since new Android does not allow us to revert to a nandroid backup with an earlier security patch level.

@Iey4iej3 I see your point, but from a security perspective I would prefer having security patches applied as soon as possible. ROMs like LOS/L4M are already quite vulnerable by themselves (due to lack of verified boot, unlocked bootloader etc), so not having the latest security patch would worsen the issue IMO.

Also, why can't one revert to a NANDroid with an earlier security patch, if everything is wiped/formatted before reverting? Is something in the firmware or something updated with security patches which makes this impossible, or how does that work?

bananer commented 3 years ago

Security patches are merged by the LineageOS maintainers on their own schedule.

kurt-by commented 3 years ago

Security patches are merged by the LineageOS maintainers on their own schedule.

You are right. Kernel security patches are merged by device maintainers. The security patch level you see in settings is from platform. Its usually merged by haggertk in the first half of each month

Iey4iej3 commented 3 years ago

By the way, if the builds are out once a month, then I would suggest that we apply the security patches every two months, so that there are two builds with the same security patch level, if possible. Otherwise, it would be troublesome if the package has a bug, since new Android does not allow us to revert to a nandroid backup with an earlier security patch level.

@Iey4iej3 I see your point, but from a security perspective I would prefer having security patches applied as soon as possible. ROMs like LOS/L4M are already quite vulnerable by themselves (due to lack of verified boot, unlocked bootloader etc), so not having the latest security patch would worsen the issue IMO.

Also, why can't one revert to a NANDroid with an earlier security patch, if everything is wiped/formatted before reverting? Is something in the firmware or something updated with security patches which makes this impossible, or how does that work?

I am still not sure whether my understanding is correct, but it seems to me that, in order to restore a NANDroid backup with an earlier security patch level, we need to at least format /data partition because, if I understand correctly, the encryption key is encrypted with respect to the security patch level (I looked at this document).

It seems much harder to format /data which wipes the internal storage. In my use case, it is even more complicated because I have work profiles (I did not even try to restore the backups of work profiles before).

On the other hand, as we see, it seems impossible to manipulate the application of security patches. However, I don't understand how large the vulnerability is. I understand that these vulnerabilities exist theoretically (but as well as laptops with verified boot in UEFI disabled and no lock on the bootloader GRUB), but I don't know how these come into the real world, given that Android phones are not like servers with a lot of ports open.

samsapti commented 3 years ago

It seems much harder to format /data which wipes the internal storage. In my use case, it is even more complicated because I have work profiles (I did not even try to restore the backups of work profiles before).

@ley4iej3 when you do NANDroid backups, you usually backup /data as well, so wiping it shouldn't be a concern. Is it technically hard, or what do you mean by harder?

Iey4iej3 commented 3 years ago

It seems much harder to format /data which wipes the internal storage. In my use case, it is even more complicated because I have work profiles (I did not even try to restore the backups of work profiles before).

@ley4iej3 when you do NANDroid backups, you usually backup /data as well, so wiping it shouldn't be a concern. Is it technically hard, or what do you mean by harder?

The usual backup (to be precise, today's TWRP backups are not really NANDroid) does not backup the internal storage (at least in TWRP). If there were no work profile, then I should also backup the internal storage, which is just a bit more cumbersome (I don't know whether I need to use tar to backup the internal storage in order to keep the correct permissions - note that the current permission of the internal storage is a bit more complicated than it used to be; and I don't know whether the existence of SELinux would complicate it more).

The work profile complicates more because seemingly I need to recreate the work profile with the same user id, and then restore the backup. I don't know how to do that in practice (I am using Shelter).

samsapti commented 3 years ago

The usual backup (to be precise, today's TWRP backups are not really NANDroid) does not backup the internal storage (at least in TWRP). If there were no work profile, then I should also backup the internal storage, which is just a bit more cumbersome (I don't know whether I need to use tar to backup the internal storage in order to keep the correct permissions - note that the current permission of the internal storage is a bit more complicated than it used to be; and I don't know whether the existence of SELinux would complicate it more).

The work profile complicates more because seemingly I need to recreate the work profile with the same user id, and then restore the backup. I don't know how to do that in practice (I am using Shelter).

I've done backups with TWRP in the past, which backed up internal storage as well, tho I think that you need to enable encrypted backups to have it backup internal storage. Restoring that backup was no problem as well. I don't think I had a work profile, so can't say anything about that tho.

Iey4iej3 commented 3 years ago

The usual backup (to be precise, today's TWRP backups are not really NANDroid) does not backup the internal storage (at least in TWRP). If there were no work profile, then I should also backup the internal storage, which is just a bit more cumbersome (I don't know whether I need to use tar to backup the internal storage in order to keep the correct permissions - note that the current permission of the internal storage is a bit more complicated than it used to be; and I don't know whether the existence of SELinux would complicate it more). The work profile complicates more because seemingly I need to recreate the work profile with the same user id, and then restore the backup. I don't know how to do that in practice (I am using Shelter).

I've done backups with TWRP in the past, which backed up internal storage as well, tho I think that you need to enable encrypted backups to have it backup internal storage. Restoring that backup was no problem as well. I don't think I had a work profile, so can't say anything about that tho.

Unfortunately, the official FAQ says explicitly that it is impossible to back up the internal storage through GUI.

bananer commented 3 years ago

Started a new round of builds for all devices, with fix for #176

Wyrrrd commented 3 years ago

Are there efforts to bring 17.1 devices up to pace, or are they deprecated?

(Asking for my a5y17lte, which is now afraid of being finally abandoned after barely surviving the last update shortage...)