Add 1bitpaint

[Eeems]

Still got to figure out what is missing in this build. remarkable-splash didn't have trouble with EPFrameBuffer.

[raisjn]

https://github.com/HiroshiTamura/1bitpaint_for_reMarkable/blob/master/1bitpaint.pro#L29 may be relevant (the link line)

[Eeems]

remarkable-splash also uses that library: https://github.com/ddvk/remarkable-splash/blob/master/remarkable-splash.pro#L5

[raisjn]

notice that it is behind an if statement for 1bitpaint, but it should be on always. i think it wasn't included because when i look for '-lqsepaper' or whatever, i don't see it in the logs.

but if i look at the splashscreen build check, i see:

arm-linux-gnueabihf-g++ -Wl,-O1 -Wl,-rpath,/opt/x-tools/arm-remarkable-linux-gnueabihf/arm-remarkable-linux-gnueabihf/sysroot/usr/lib -o remarkable-splash main.o -lqsgepaper -lQt5Gui -lQt5Core -lpthread

[Eeems]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

[raisjn]

tell it to static build

[matteodelabre]

The spec file in the reMarkable toolchain is called linux-oe-g++, whereas it is called linux-arm-gnueabihf-g++ in the Toltec toolchain, so this condition is not fulfilled when building with the Toltec toolchain. The same thing happens with oxide, which I mitigated using this sed command.

[matteodelabre]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

It looks like libQt5Widgets is not installed on the reMarkable. The current reMarkable toolchain does not contain libQt5Widgets either, as far as I can see. However, the old one did contain it.

[Eeems]

Interesting. Well I guess I'll have to open an issue to get it updated to work with the new toolchain.

[matteodelabre]

Indeed. Also I think it would be less confusing if we removed libQt5Widgets (and other missing Qt libs, if applicable) from the qt image. Moving this suggestion to the toolchain repo.

[Eeems]

Opened HiroshiTamura/1bitpaint_for_reMarkable#2

[Eeems]

@HiroshiTamura hasn't been active on GitHub since May 2019 so I'm not sure we'll be able to get this fixed without forking the project :/

[Eeems]

Looks like they are active on twitter though: https://twitter.com/minordaimyo?lang=en

[LinusCDE]

Anything new on this? We should probably just go ahead and do the changes. Either forking or adding a patch files like done with koreader.

[Eeems]

I haven't taken the time to try to sort out how to rewrite the portions of their code that uses the now-not-included portions of Qt. Feel free to though. I likely won't have time until later this year.

[matteodelabre]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

• makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see Add builddepends metadata field to recipes #85)
• the Python rewrite of the build tooling (Rewrite tooling scripts in Python #211) (needed for Add builddepends metadata field to recipes #85)
• opkg support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

[LinusCDE]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

* makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see #85)
* the Python rewrite of the build tooling (#211) (needed for #85)
* `opkg` support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

That sounds great, but I fear we might start to approach some kind of "vendor locking" if we do that. Normally most apps also work without toltec and we just package them up conveniently. With that change, devs will have it harder to provide installation guidelines or a standalone binary that works without toltec.

While I love toltec, I hesitate have people say "I wanted to install this cool mod X, but I need to install some huge stuff I don't know and might brick my device. Without it the app doesn't work because of missing libraries.". Especially people installing their first mod or ssh'ing in the first time could get thrown off.

[matteodelabre]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Also, Toltec strives to be easy to install (which will be improved by Eeems/toltec-installer) and not too heavyweight, so in its ideal state it would be even easier to use than manually transferring the binary of an app that the user wants to try.

[LinusCDE]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Yes, but developers will have to consider two sets of libraries. Currently one just links against what the oecore toolchain offers and the toltec build will basically be the same.

In the example of QTWidgets tough, people might make the apps toltec only. While I'm not against it, it may make mods that work exclusivly as a toltec package (expecting all the QT libs in /opt) and manual builds harder. If a dev isn't deep into how to build e.g. qt apps, he might not even know how to change it.

Well the previous paragraph made me think, that people who do change the toolchain to our one already know how to make a normal standalone build as well. Only problem might be stuff like toltec having libs, remarkable doesn't, but I think this will be an unavoidable perk of toltecs packages in general.

So while writing my response, I changed my mind and don't mind the custom qt libs anymore. 😄

[raisjn]

are people still interested in this app? (can we close this PR?)

[matteodelabre]

There are more feature-full apps that achieve the same goal, so I don’t think dropping it would have a huge effect. The issue with missing libQt5Widgets on the device will be fixed once the work on a Qt package settles (see #212 & the package/qt branch). The main use I can see for this app is as a test for the Qt package.

@Eeems, since you opened the PR in the first place, do you have any thoughts on this?

Note: If we close this PR, we should also remove it from the list of package requests (#9).

[Eeems]

I would still like to keep this around, especially as a test for package/qt

[Eeems]

Still got to figure out what is missing in this build. remarkable-splash didn't have trouble with EPFrameBuffer.

[raisjn]

https://github.com/HiroshiTamura/1bitpaint_for_reMarkable/blob/master/1bitpaint.pro#L29 may be relevant (the link line)

[Eeems]

remarkable-splash also uses that library: https://github.com/ddvk/remarkable-splash/blob/master/remarkable-splash.pro#L5

[raisjn]

notice that it is behind an if statement for 1bitpaint, but it should be on always. i think it wasn't included because when i look for '-lqsepaper' or whatever, i don't see it in the logs.

but if i look at the splashscreen build check, i see:

arm-linux-gnueabihf-g++ -Wl,-O1 -Wl,-rpath,/opt/x-tools/arm-remarkable-linux-gnueabihf/arm-remarkable-linux-gnueabihf/sysroot/usr/lib -o remarkable-splash main.o -lqsgepaper -lQt5Gui -lQt5Core -lpthread

[Eeems]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

[raisjn]

tell it to static build

[matteodelabre]

The spec file in the reMarkable toolchain is called linux-oe-g++, whereas it is called linux-arm-gnueabihf-g++ in the Toltec toolchain, so this condition is not fulfilled when building with the Toltec toolchain. The same thing happens with oxide, which I mitigated using this sed command.

[matteodelabre]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

It looks like libQt5Widgets is not installed on the reMarkable. The current reMarkable toolchain does not contain libQt5Widgets either, as far as I can see. However, the old one did contain it.

[Eeems]

Interesting. Well I guess I'll have to open an issue to get it updated to work with the new toolchain.

[matteodelabre]

Indeed. Also I think it would be less confusing if we removed libQt5Widgets (and other missing Qt libs, if applicable) from the qt image. Moving this suggestion to the toolchain repo.

[Eeems]

Opened HiroshiTamura/1bitpaint_for_reMarkable#2

[Eeems]

@HiroshiTamura hasn't been active on GitHub since May 2019 so I'm not sure we'll be able to get this fixed without forking the project :/

[Eeems]

Looks like they are active on twitter though: https://twitter.com/minordaimyo?lang=en

[LinusCDE]

Anything new on this? We should probably just go ahead and do the changes. Either forking or adding a patch files like done with koreader.

[Eeems]

I haven't taken the time to try to sort out how to rewrite the portions of their code that uses the now-not-included portions of Qt. Feel free to though. I likely won't have time until later this year.

[matteodelabre]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

• makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see Add builddepends metadata field to recipes #85)
• the Python rewrite of the build tooling (Rewrite tooling scripts in Python #211) (needed for Add builddepends metadata field to recipes #85)
• opkg support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

[LinusCDE]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

* makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see #85)
* the Python rewrite of the build tooling (#211) (needed for #85)
* `opkg` support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

That sounds great, but I fear we might start to approach some kind of "vendor locking" if we do that. Normally most apps also work without toltec and we just package them up conveniently. With that change, devs will have it harder to provide installation guidelines or a standalone binary that works without toltec.

While I love toltec, I hesitate have people say "I wanted to install this cool mod X, but I need to install some huge stuff I don't know and might brick my device. Without it the app doesn't work because of missing libraries.". Especially people installing their first mod or ssh'ing in the first time could get thrown off.

[matteodelabre]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Also, Toltec strives to be easy to install (which will be improved by Eeems/toltec-installer) and not too heavyweight, so in its ideal state it would be even easier to use than manually transferring the binary of an app that the user wants to try.

[LinusCDE]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Yes, but developers will have to consider two sets of libraries. Currently one just links against what the oecore toolchain offers and the toltec build will basically be the same.

In the example of QTWidgets tough, people might make the apps toltec only. While I'm not against it, it may make mods that work exclusivly as a toltec package (expecting all the QT libs in /opt) and manual builds harder. If a dev isn't deep into how to build e.g. qt apps, he might not even know how to change it.

Well the previous paragraph made me think, that people who do change the toolchain to our one already know how to make a normal standalone build as well. Only problem might be stuff like toltec having libs, remarkable doesn't, but I think this will be an unavoidable perk of toltecs packages in general.

So while writing my response, I changed my mind and don't mind the custom qt libs anymore. 😄

[raisjn]

are people still interested in this app? (can we close this PR?)

[matteodelabre]

There are more feature-full apps that achieve the same goal, so I don’t think dropping it would have a huge effect. The issue with missing libQt5Widgets on the device will be fixed once the work on a Qt package settles (see #212 & the package/qt branch). The main use I can see for this app is as a test for the Qt package.

@Eeems, since you opened the PR in the first place, do you have any thoughts on this?

Note: If we close this PR, we should also remove it from the list of package requests (#9).

[Eeems]

I would still like to keep this around, especially as a test for package/qt

[Eeems]

Still got to figure out what is missing in this build. remarkable-splash didn't have trouble with EPFrameBuffer.

[raisjn]

https://github.com/HiroshiTamura/1bitpaint_for_reMarkable/blob/master/1bitpaint.pro#L29 may be relevant (the link line)

[Eeems]

remarkable-splash also uses that library: https://github.com/ddvk/remarkable-splash/blob/master/remarkable-splash.pro#L5

[raisjn]

notice that it is behind an if statement for 1bitpaint, but it should be on always. i think it wasn't included because when i look for '-lqsepaper' or whatever, i don't see it in the logs.

but if i look at the splashscreen build check, i see:

arm-linux-gnueabihf-g++ -Wl,-O1 -Wl,-rpath,/opt/x-tools/arm-remarkable-linux-gnueabihf/arm-remarkable-linux-gnueabihf/sysroot/usr/lib -o remarkable-splash main.o -lqsgepaper -lQt5Gui -lQt5Core -lpthread

[Eeems]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

[raisjn]

tell it to static build

[matteodelabre]

The spec file in the reMarkable toolchain is called linux-oe-g++, whereas it is called linux-arm-gnueabihf-g++ in the Toltec toolchain, so this condition is not fulfilled when building with the Toltec toolchain. The same thing happens with oxide, which I mitigated using this sed command.

[matteodelabre]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

It looks like libQt5Widgets is not installed on the reMarkable. The current reMarkable toolchain does not contain libQt5Widgets either, as far as I can see. However, the old one did contain it.

[Eeems]

Interesting. Well I guess I'll have to open an issue to get it updated to work with the new toolchain.

[matteodelabre]

Indeed. Also I think it would be less confusing if we removed libQt5Widgets (and other missing Qt libs, if applicable) from the qt image. Moving this suggestion to the toolchain repo.

[Eeems]

Opened HiroshiTamura/1bitpaint_for_reMarkable#2

[Eeems]

@HiroshiTamura hasn't been active on GitHub since May 2019 so I'm not sure we'll be able to get this fixed without forking the project :/

[Eeems]

Looks like they are active on twitter though: https://twitter.com/minordaimyo?lang=en

[LinusCDE]

Anything new on this? We should probably just go ahead and do the changes. Either forking or adding a patch files like done with koreader.

[Eeems]

I haven't taken the time to try to sort out how to rewrite the portions of their code that uses the now-not-included portions of Qt. Feel free to though. I likely won't have time until later this year.

[matteodelabre]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

• makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see Add builddepends metadata field to recipes #85)
• the Python rewrite of the build tooling (Rewrite tooling scripts in Python #211) (needed for Add builddepends metadata field to recipes #85)
• opkg support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

[LinusCDE]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

* makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see #85)
* the Python rewrite of the build tooling (#211) (needed for #85)
* `opkg` support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

That sounds great, but I fear we might start to approach some kind of "vendor locking" if we do that. Normally most apps also work without toltec and we just package them up conveniently. With that change, devs will have it harder to provide installation guidelines or a standalone binary that works without toltec.

While I love toltec, I hesitate have people say "I wanted to install this cool mod X, but I need to install some huge stuff I don't know and might brick my device. Without it the app doesn't work because of missing libraries.". Especially people installing their first mod or ssh'ing in the first time could get thrown off.

[matteodelabre]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Also, Toltec strives to be easy to install (which will be improved by Eeems/toltec-installer) and not too heavyweight, so in its ideal state it would be even easier to use than manually transferring the binary of an app that the user wants to try.

[LinusCDE]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Yes, but developers will have to consider two sets of libraries. Currently one just links against what the oecore toolchain offers and the toltec build will basically be the same.

In the example of QTWidgets tough, people might make the apps toltec only. While I'm not against it, it may make mods that work exclusivly as a toltec package (expecting all the QT libs in /opt) and manual builds harder. If a dev isn't deep into how to build e.g. qt apps, he might not even know how to change it.

Well the previous paragraph made me think, that people who do change the toolchain to our one already know how to make a normal standalone build as well. Only problem might be stuff like toltec having libs, remarkable doesn't, but I think this will be an unavoidable perk of toltecs packages in general.

So while writing my response, I changed my mind and don't mind the custom qt libs anymore. 😄

[raisjn]

are people still interested in this app? (can we close this PR?)

[matteodelabre]

There are more feature-full apps that achieve the same goal, so I don’t think dropping it would have a huge effect. The issue with missing libQt5Widgets on the device will be fixed once the work on a Qt package settles (see #212 & the package/qt branch). The main use I can see for this app is as a test for the Qt package.

@Eeems, since you opened the PR in the first place, do you have any thoughts on this?

Note: If we close this PR, we should also remove it from the list of package requests (#9).

[Eeems]

I would still like to keep this around, especially as a test for package/qt

[Eeems]

Still got to figure out what is missing in this build. remarkable-splash didn't have trouble with EPFrameBuffer.

[raisjn]

https://github.com/HiroshiTamura/1bitpaint_for_reMarkable/blob/master/1bitpaint.pro#L29 may be relevant (the link line)

[Eeems]

remarkable-splash also uses that library: https://github.com/ddvk/remarkable-splash/blob/master/remarkable-splash.pro#L5

[raisjn]

notice that it is behind an if statement for 1bitpaint, but it should be on always. i think it wasn't included because when i look for '-lqsepaper' or whatever, i don't see it in the logs.

but if i look at the splashscreen build check, i see:

arm-linux-gnueabihf-g++ -Wl,-O1 -Wl,-rpath,/opt/x-tools/arm-remarkable-linux-gnueabihf/arm-remarkable-linux-gnueabihf/sysroot/usr/lib -o remarkable-splash main.o -lqsgepaper -lQt5Gui -lQt5Core -lpthread

[Eeems]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

[raisjn]

tell it to static build

[matteodelabre]

The spec file in the reMarkable toolchain is called linux-oe-g++, whereas it is called linux-arm-gnueabihf-g++ in the Toltec toolchain, so this condition is not fulfilled when building with the Toltec toolchain. The same thing happens with oxide, which I mitigated using this sed command.

[matteodelabre]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

It looks like libQt5Widgets is not installed on the reMarkable. The current reMarkable toolchain does not contain libQt5Widgets either, as far as I can see. However, the old one did contain it.

[Eeems]

Interesting. Well I guess I'll have to open an issue to get it updated to work with the new toolchain.

[matteodelabre]

Indeed. Also I think it would be less confusing if we removed libQt5Widgets (and other missing Qt libs, if applicable) from the qt image. Moving this suggestion to the toolchain repo.

[Eeems]

Opened HiroshiTamura/1bitpaint_for_reMarkable#2

[Eeems]

@HiroshiTamura hasn't been active on GitHub since May 2019 so I'm not sure we'll be able to get this fixed without forking the project :/

[Eeems]

Looks like they are active on twitter though: https://twitter.com/minordaimyo?lang=en

[LinusCDE]

Anything new on this? We should probably just go ahead and do the changes. Either forking or adding a patch files like done with koreader.

[Eeems]

I haven't taken the time to try to sort out how to rewrite the portions of their code that uses the now-not-included portions of Qt. Feel free to though. I likely won't have time until later this year.

[matteodelabre]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

• makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see Add builddepends metadata field to recipes #85)
• the Python rewrite of the build tooling (Rewrite tooling scripts in Python #211) (needed for Add builddepends metadata field to recipes #85)
• opkg support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

[LinusCDE]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

* makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see #85)
* the Python rewrite of the build tooling (#211) (needed for #85)
* `opkg` support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

That sounds great, but I fear we might start to approach some kind of "vendor locking" if we do that. Normally most apps also work without toltec and we just package them up conveniently. With that change, devs will have it harder to provide installation guidelines or a standalone binary that works without toltec.

While I love toltec, I hesitate have people say "I wanted to install this cool mod X, but I need to install some huge stuff I don't know and might brick my device. Without it the app doesn't work because of missing libraries.". Especially people installing their first mod or ssh'ing in the first time could get thrown off.

[matteodelabre]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Also, Toltec strives to be easy to install (which will be improved by Eeems/toltec-installer) and not too heavyweight, so in its ideal state it would be even easier to use than manually transferring the binary of an app that the user wants to try.

[LinusCDE]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Yes, but developers will have to consider two sets of libraries. Currently one just links against what the oecore toolchain offers and the toltec build will basically be the same.

In the example of QTWidgets tough, people might make the apps toltec only. While I'm not against it, it may make mods that work exclusivly as a toltec package (expecting all the QT libs in /opt) and manual builds harder. If a dev isn't deep into how to build e.g. qt apps, he might not even know how to change it.

Well the previous paragraph made me think, that people who do change the toolchain to our one already know how to make a normal standalone build as well. Only problem might be stuff like toltec having libs, remarkable doesn't, but I think this will be an unavoidable perk of toltecs packages in general.

So while writing my response, I changed my mind and don't mind the custom qt libs anymore. 😄

[raisjn]

are people still interested in this app? (can we close this PR?)

[matteodelabre]

There are more feature-full apps that achieve the same goal, so I don’t think dropping it would have a huge effect. The issue with missing libQt5Widgets on the device will be fixed once the work on a Qt package settles (see #212 & the package/qt branch). The main use I can see for this app is as a test for the Qt package.

@Eeems, since you opened the PR in the first place, do you have any thoughts on this?

Note: If we close this PR, we should also remove it from the list of package requests (#9).

[Eeems]

I would still like to keep this around, especially as a test for package/qt

[Eeems]

Still got to figure out what is missing in this build. remarkable-splash didn't have trouble with EPFrameBuffer.

[raisjn]

https://github.com/HiroshiTamura/1bitpaint_for_reMarkable/blob/master/1bitpaint.pro#L29 may be relevant (the link line)

[Eeems]

remarkable-splash also uses that library: https://github.com/ddvk/remarkable-splash/blob/master/remarkable-splash.pro#L5

[raisjn]

notice that it is behind an if statement for 1bitpaint, but it should be on always. i think it wasn't included because when i look for '-lqsepaper' or whatever, i don't see it in the logs.

but if i look at the splashscreen build check, i see:

arm-linux-gnueabihf-g++ -Wl,-O1 -Wl,-rpath,/opt/x-tools/arm-remarkable-linux-gnueabihf/arm-remarkable-linux-gnueabihf/sysroot/usr/lib -o remarkable-splash main.o -lqsgepaper -lQt5Gui -lQt5Core -lpthread

[Eeems]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

[raisjn]

tell it to static build

[matteodelabre]

The spec file in the reMarkable toolchain is called linux-oe-g++, whereas it is called linux-arm-gnueabihf-g++ in the Toltec toolchain, so this condition is not fulfilled when building with the Toltec toolchain. The same thing happens with oxide, which I mitigated using this sed command.

[matteodelabre]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

It looks like libQt5Widgets is not installed on the reMarkable. The current reMarkable toolchain does not contain libQt5Widgets either, as far as I can see. However, the old one did contain it.

[Eeems]

Interesting. Well I guess I'll have to open an issue to get it updated to work with the new toolchain.

[matteodelabre]

Indeed. Also I think it would be less confusing if we removed libQt5Widgets (and other missing Qt libs, if applicable) from the qt image. Moving this suggestion to the toolchain repo.

[Eeems]

Opened HiroshiTamura/1bitpaint_for_reMarkable#2

[Eeems]

@HiroshiTamura hasn't been active on GitHub since May 2019 so I'm not sure we'll be able to get this fixed without forking the project :/

[Eeems]

Looks like they are active on twitter though: https://twitter.com/minordaimyo?lang=en

[LinusCDE]

Anything new on this? We should probably just go ahead and do the changes. Either forking or adding a patch files like done with koreader.

[Eeems]

I haven't taken the time to try to sort out how to rewrite the portions of their code that uses the now-not-included portions of Qt. Feel free to though. I likely won't have time until later this year.

[matteodelabre]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

• makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see Add builddepends metadata field to recipes #85)
• the Python rewrite of the build tooling (Rewrite tooling scripts in Python #211) (needed for Add builddepends metadata field to recipes #85)
• opkg support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

[LinusCDE]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

* makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see #85)
* the Python rewrite of the build tooling (#211) (needed for #85)
* `opkg` support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

That sounds great, but I fear we might start to approach some kind of "vendor locking" if we do that. Normally most apps also work without toltec and we just package them up conveniently. With that change, devs will have it harder to provide installation guidelines or a standalone binary that works without toltec.

While I love toltec, I hesitate have people say "I wanted to install this cool mod X, but I need to install some huge stuff I don't know and might brick my device. Without it the app doesn't work because of missing libraries.". Especially people installing their first mod or ssh'ing in the first time could get thrown off.

[matteodelabre]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Also, Toltec strives to be easy to install (which will be improved by Eeems/toltec-installer) and not too heavyweight, so in its ideal state it would be even easier to use than manually transferring the binary of an app that the user wants to try.

[LinusCDE]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Yes, but developers will have to consider two sets of libraries. Currently one just links against what the oecore toolchain offers and the toltec build will basically be the same.

In the example of QTWidgets tough, people might make the apps toltec only. While I'm not against it, it may make mods that work exclusivly as a toltec package (expecting all the QT libs in /opt) and manual builds harder. If a dev isn't deep into how to build e.g. qt apps, he might not even know how to change it.

Well the previous paragraph made me think, that people who do change the toolchain to our one already know how to make a normal standalone build as well. Only problem might be stuff like toltec having libs, remarkable doesn't, but I think this will be an unavoidable perk of toltecs packages in general.

So while writing my response, I changed my mind and don't mind the custom qt libs anymore. 😄

[raisjn]

are people still interested in this app? (can we close this PR?)

[matteodelabre]

There are more feature-full apps that achieve the same goal, so I don’t think dropping it would have a huge effect. The issue with missing libQt5Widgets on the device will be fixed once the work on a Qt package settles (see #212 & the package/qt branch). The main use I can see for this app is as a test for the Qt package.

@Eeems, since you opened the PR in the first place, do you have any thoughts on this?

Note: If we close this PR, we should also remove it from the list of package requests (#9).

[Eeems]

I would still like to keep this around, especially as a test for package/qt

[Eeems]

Still got to figure out what is missing in this build. remarkable-splash didn't have trouble with EPFrameBuffer.

[raisjn]

https://github.com/HiroshiTamura/1bitpaint_for_reMarkable/blob/master/1bitpaint.pro#L29 may be relevant (the link line)

[Eeems]

remarkable-splash also uses that library: https://github.com/ddvk/remarkable-splash/blob/master/remarkable-splash.pro#L5

[raisjn]

notice that it is behind an if statement for 1bitpaint, but it should be on always. i think it wasn't included because when i look for '-lqsepaper' or whatever, i don't see it in the logs.

but if i look at the splashscreen build check, i see:

arm-linux-gnueabihf-g++ -Wl,-O1 -Wl,-rpath,/opt/x-tools/arm-remarkable-linux-gnueabihf/arm-remarkable-linux-gnueabihf/sysroot/usr/lib -o remarkable-splash main.o -lqsgepaper -lQt5Gui -lQt5Core -lpthread

[Eeems]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

[raisjn]

tell it to static build

[matteodelabre]

The spec file in the reMarkable toolchain is called linux-oe-g++, whereas it is called linux-arm-gnueabihf-g++ in the Toltec toolchain, so this condition is not fulfilled when building with the Toltec toolchain. The same thing happens with oxide, which I mitigated using this sed command.

[matteodelabre]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

It looks like libQt5Widgets is not installed on the reMarkable. The current reMarkable toolchain does not contain libQt5Widgets either, as far as I can see. However, the old one did contain it.

[Eeems]

Interesting. Well I guess I'll have to open an issue to get it updated to work with the new toolchain.

[matteodelabre]

Indeed. Also I think it would be less confusing if we removed libQt5Widgets (and other missing Qt libs, if applicable) from the qt image. Moving this suggestion to the toolchain repo.

[Eeems]

Opened HiroshiTamura/1bitpaint_for_reMarkable#2

[Eeems]

@HiroshiTamura hasn't been active on GitHub since May 2019 so I'm not sure we'll be able to get this fixed without forking the project :/

[Eeems]

Looks like they are active on twitter though: https://twitter.com/minordaimyo?lang=en

[LinusCDE]

Anything new on this? We should probably just go ahead and do the changes. Either forking or adding a patch files like done with koreader.

[Eeems]

I haven't taken the time to try to sort out how to rewrite the portions of their code that uses the now-not-included portions of Qt. Feel free to though. I likely won't have time until later this year.

[matteodelabre]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

• makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see Add builddepends metadata field to recipes #85)
• the Python rewrite of the build tooling (Rewrite tooling scripts in Python #211) (needed for Add builddepends metadata field to recipes #85)
• opkg support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

[LinusCDE]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

* makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see #85)
* the Python rewrite of the build tooling (#211) (needed for #85)
* `opkg` support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

That sounds great, but I fear we might start to approach some kind of "vendor locking" if we do that. Normally most apps also work without toltec and we just package them up conveniently. With that change, devs will have it harder to provide installation guidelines or a standalone binary that works without toltec.

While I love toltec, I hesitate have people say "I wanted to install this cool mod X, but I need to install some huge stuff I don't know and might brick my device. Without it the app doesn't work because of missing libraries.". Especially people installing their first mod or ssh'ing in the first time could get thrown off.

[matteodelabre]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Also, Toltec strives to be easy to install (which will be improved by Eeems/toltec-installer) and not too heavyweight, so in its ideal state it would be even easier to use than manually transferring the binary of an app that the user wants to try.

[LinusCDE]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Yes, but developers will have to consider two sets of libraries. Currently one just links against what the oecore toolchain offers and the toltec build will basically be the same.

In the example of QTWidgets tough, people might make the apps toltec only. While I'm not against it, it may make mods that work exclusivly as a toltec package (expecting all the QT libs in /opt) and manual builds harder. If a dev isn't deep into how to build e.g. qt apps, he might not even know how to change it.

Well the previous paragraph made me think, that people who do change the toolchain to our one already know how to make a normal standalone build as well. Only problem might be stuff like toltec having libs, remarkable doesn't, but I think this will be an unavoidable perk of toltecs packages in general.

So while writing my response, I changed my mind and don't mind the custom qt libs anymore. 😄

[raisjn]

are people still interested in this app? (can we close this PR?)

[matteodelabre]

There are more feature-full apps that achieve the same goal, so I don’t think dropping it would have a huge effect. The issue with missing libQt5Widgets on the device will be fixed once the work on a Qt package settles (see #212 & the package/qt branch). The main use I can see for this app is as a test for the Qt package.

@Eeems, since you opened the PR in the first place, do you have any thoughts on this?

Note: If we close this PR, we should also remove it from the list of package requests (#9).

[Eeems]

I would still like to keep this around, especially as a test for package/qt

[Eeems]

Still got to figure out what is missing in this build. remarkable-splash didn't have trouble with EPFrameBuffer.

[raisjn]

https://github.com/HiroshiTamura/1bitpaint_for_reMarkable/blob/master/1bitpaint.pro#L29 may be relevant (the link line)

[Eeems]

remarkable-splash also uses that library: https://github.com/ddvk/remarkable-splash/blob/master/remarkable-splash.pro#L5

[raisjn]

notice that it is behind an if statement for 1bitpaint, but it should be on always. i think it wasn't included because when i look for '-lqsepaper' or whatever, i don't see it in the logs.

but if i look at the splashscreen build check, i see:

arm-linux-gnueabihf-g++ -Wl,-O1 -Wl,-rpath,/opt/x-tools/arm-remarkable-linux-gnueabihf/arm-remarkable-linux-gnueabihf/sysroot/usr/lib -o remarkable-splash main.o -lqsgepaper -lQt5Gui -lQt5Core -lpthread

[Eeems]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

[raisjn]

tell it to static build

[matteodelabre]

The spec file in the reMarkable toolchain is called linux-oe-g++, whereas it is called linux-arm-gnueabihf-g++ in the Toltec toolchain, so this condition is not fulfilled when building with the Toltec toolchain. The same thing happens with oxide, which I mitigated using this sed command.

[matteodelabre]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

It looks like libQt5Widgets is not installed on the reMarkable. The current reMarkable toolchain does not contain libQt5Widgets either, as far as I can see. However, the old one did contain it.

[Eeems]

Interesting. Well I guess I'll have to open an issue to get it updated to work with the new toolchain.

[matteodelabre]

Indeed. Also I think it would be less confusing if we removed libQt5Widgets (and other missing Qt libs, if applicable) from the qt image. Moving this suggestion to the toolchain repo.

[Eeems]

Opened HiroshiTamura/1bitpaint_for_reMarkable#2

[Eeems]

@HiroshiTamura hasn't been active on GitHub since May 2019 so I'm not sure we'll be able to get this fixed without forking the project :/

[Eeems]

Looks like they are active on twitter though: https://twitter.com/minordaimyo?lang=en

[LinusCDE]

Anything new on this? We should probably just go ahead and do the changes. Either forking or adding a patch files like done with koreader.

[Eeems]

I haven't taken the time to try to sort out how to rewrite the portions of their code that uses the now-not-included portions of Qt. Feel free to though. I likely won't have time until later this year.

[matteodelabre]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

• makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see Add builddepends metadata field to recipes #85)
• the Python rewrite of the build tooling (Rewrite tooling scripts in Python #211) (needed for Add builddepends metadata field to recipes #85)
• opkg support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

[LinusCDE]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

* makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see #85)
* the Python rewrite of the build tooling (#211) (needed for #85)
* `opkg` support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

That sounds great, but I fear we might start to approach some kind of "vendor locking" if we do that. Normally most apps also work without toltec and we just package them up conveniently. With that change, devs will have it harder to provide installation guidelines or a standalone binary that works without toltec.

While I love toltec, I hesitate have people say "I wanted to install this cool mod X, but I need to install some huge stuff I don't know and might brick my device. Without it the app doesn't work because of missing libraries.". Especially people installing their first mod or ssh'ing in the first time could get thrown off.

[matteodelabre]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Also, Toltec strives to be easy to install (which will be improved by Eeems/toltec-installer) and not too heavyweight, so in its ideal state it would be even easier to use than manually transferring the binary of an app that the user wants to try.

[LinusCDE]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Yes, but developers will have to consider two sets of libraries. Currently one just links against what the oecore toolchain offers and the toltec build will basically be the same.

In the example of QTWidgets tough, people might make the apps toltec only. While I'm not against it, it may make mods that work exclusivly as a toltec package (expecting all the QT libs in /opt) and manual builds harder. If a dev isn't deep into how to build e.g. qt apps, he might not even know how to change it.

Well the previous paragraph made me think, that people who do change the toolchain to our one already know how to make a normal standalone build as well. Only problem might be stuff like toltec having libs, remarkable doesn't, but I think this will be an unavoidable perk of toltecs packages in general.

So while writing my response, I changed my mind and don't mind the custom qt libs anymore. 😄

[raisjn]

are people still interested in this app? (can we close this PR?)

[matteodelabre]

There are more feature-full apps that achieve the same goal, so I don’t think dropping it would have a huge effect. The issue with missing libQt5Widgets on the device will be fixed once the work on a Qt package settles (see #212 & the package/qt branch). The main use I can see for this app is as a test for the Qt package.

@Eeems, since you opened the PR in the first place, do you have any thoughts on this?

Note: If we close this PR, we should also remove it from the list of package requests (#9).

[Eeems]

I would still like to keep this around, especially as a test for package/qt

[Eeems]

Still got to figure out what is missing in this build. remarkable-splash didn't have trouble with EPFrameBuffer.

[raisjn]

https://github.com/HiroshiTamura/1bitpaint_for_reMarkable/blob/master/1bitpaint.pro#L29 may be relevant (the link line)

[Eeems]

remarkable-splash also uses that library: https://github.com/ddvk/remarkable-splash/blob/master/remarkable-splash.pro#L5

[raisjn]

notice that it is behind an if statement for 1bitpaint, but it should be on always. i think it wasn't included because when i look for '-lqsepaper' or whatever, i don't see it in the logs.

but if i look at the splashscreen build check, i see:

arm-linux-gnueabihf-g++ -Wl,-O1 -Wl,-rpath,/opt/x-tools/arm-remarkable-linux-gnueabihf/arm-remarkable-linux-gnueabihf/sysroot/usr/lib -o remarkable-splash main.o -lqsgepaper -lQt5Gui -lQt5Core -lpthread

[Eeems]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

[raisjn]

tell it to static build

[matteodelabre]

The spec file in the reMarkable toolchain is called linux-oe-g++, whereas it is called linux-arm-gnueabihf-g++ in the Toltec toolchain, so this condition is not fulfilled when building with the Toltec toolchain. The same thing happens with oxide, which I mitigated using this sed command.

[matteodelabre]

Okay the build works, but it fails to run on device:

1bitpaint: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory

It looks like libQt5Widgets is not installed on the reMarkable. The current reMarkable toolchain does not contain libQt5Widgets either, as far as I can see. However, the old one did contain it.

[Eeems]

Interesting. Well I guess I'll have to open an issue to get it updated to work with the new toolchain.

[matteodelabre]

Indeed. Also I think it would be less confusing if we removed libQt5Widgets (and other missing Qt libs, if applicable) from the qt image. Moving this suggestion to the toolchain repo.

[Eeems]

Opened HiroshiTamura/1bitpaint_for_reMarkable#2

[Eeems]

@HiroshiTamura hasn't been active on GitHub since May 2019 so I'm not sure we'll be able to get this fixed without forking the project :/

[Eeems]

Looks like they are active on twitter though: https://twitter.com/minordaimyo?lang=en

[LinusCDE]

Anything new on this? We should probably just go ahead and do the changes. Either forking or adding a patch files like done with koreader.

[Eeems]

I haven't taken the time to try to sort out how to rewrite the portions of their code that uses the now-not-included portions of Qt. Feel free to though. I likely won't have time until later this year.

[matteodelabre]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

• makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see Add builddepends metadata field to recipes #85)
• the Python rewrite of the build tooling (Rewrite tooling scripts in Python #211) (needed for Add builddepends metadata field to recipes #85)
• opkg support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

[LinusCDE]

As a more general solution, I’m currently thinking about making a Qt package in Toltec. This could allow us to have more up-to-date versions of Qt, as well as including a precise set of Qt libs which does not change between two rM updates. This is blocked by:

* makedepends support, including Toltec packages, so that Qt-dependent packages can rely on those artifacts (see #85)
* the Python rewrite of the build tooling (#211) (needed for #85)
* `opkg` support in our build toolchain, so that needed packages can be installed into the container before building (this is almost done)

That sounds great, but I fear we might start to approach some kind of "vendor locking" if we do that. Normally most apps also work without toltec and we just package them up conveniently. With that change, devs will have it harder to provide installation guidelines or a standalone binary that works without toltec.

While I love toltec, I hesitate have people say "I wanted to install this cool mod X, but I need to install some huge stuff I don't know and might brick my device. Without it the app doesn't work because of missing libraries.". Especially people installing their first mod or ssh'ing in the first time could get thrown off.

[matteodelabre]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Also, Toltec strives to be easy to install (which will be improved by Eeems/toltec-installer) and not too heavyweight, so in its ideal state it would be even easier to use than manually transferring the binary of an app that the user wants to try.

[LinusCDE]

But apps would still be able to provide binaries that work without Toltec by dynamically linking them to the rM-provided Qt libs, or by statically linking them to the desired libs, wouldn't they?

Yes, but developers will have to consider two sets of libraries. Currently one just links against what the oecore toolchain offers and the toltec build will basically be the same.

In the example of QTWidgets tough, people might make the apps toltec only. While I'm not against it, it may make mods that work exclusivly as a toltec package (expecting all the QT libs in /opt) and manual builds harder. If a dev isn't deep into how to build e.g. qt apps, he might not even know how to change it.

Well the previous paragraph made me think, that people who do change the toolchain to our one already know how to make a normal standalone build as well. Only problem might be stuff like toltec having libs, remarkable doesn't, but I think this will be an unavoidable perk of toltecs packages in general.

So while writing my response, I changed my mind and don't mind the custom qt libs anymore. 😄

[raisjn]

are people still interested in this app? (can we close this PR?)

[matteodelabre]

There are more feature-full apps that achieve the same goal, so I don’t think dropping it would have a huge effect. The issue with missing libQt5Widgets on the device will be fixed once the work on a Qt package settles (see #212 & the package/qt branch). The main use I can see for this app is as a test for the Qt package.

@Eeems, since you opened the PR in the first place, do you have any thoughts on this?

Note: If we close this PR, we should also remove it from the list of package requests (#9).

[Eeems]

I would still like to keep this around, especially as a test for package/qt