search

sugarlabs / sugar-live-build

Configuration for Debian Live Build to make a Sugar Live Build
Other
6 stars 12 forks source link

"build" on 32-bit Debian fails: "empy not found" #15

Closed martinwguy closed 4 years ago

martinwguy commented 4 years ago

commit 961d11d801820ad1b9fe7c7d669d01965b0fdcfe Date: Tue Mar 17 17:31:17 2020 +1100

Running the wonderful "build" script on a Debian buster x86 32-bit system to make SoaS for 32-bit CPUs, it fails running

cd /usr/src/sugar-artwork
sh autogen.sh

in the chroot (exit 1), and running that script manually with

echo "cd /usr/src/sugar-artwork && sh autogen.sh" | sudo chroot chroot

it says "empy not found". Adding

python-empy

to

src/config/package-lists/desktop.list.chroot

makes the build succeed. I don't know if this is 32-bit-build-related or not.

On a clone of current master commit 961d11d801820ad1b9fe7c7d669d01965b0fdcfe Date: Tue Mar 17 17:31:17 2020 +1100

srevinsaju commented 4 years ago

Weird, python3-empy exists on https://github.com/sugarlabs/sugar-live-build/blob/961d11d801820ad1b9fe7c7d669d01965b0fdcfe/src/config/package-lists/desktop.list.chroot#L14, I wonder why its not being detected. Its surely not because its a 32-bit

martinwguy commented 4 years ago

python3-empy yes, but python-empy no - it must be using python2 to run that script.

Yes, I get exactly the same problem on a 64-bit Debian buster system, with the same fix:

soas+python-empy-patch.txt

Incidentally, on boot, after choosing the color for XO, it opens the Journal instead of giving the circular array of items, with no apparent way to get out of the Journal. I see that the generated 64-bit hybrid ISO image is different from the distributed one (21MB bigger!). Do I need to add a list of activites maybe, and if so, which and where? Thanks -M

srevinsaju commented 4 years ago

For debian, there are many activities on https://udd.debian.org/dmd/?pkg-sugar-devel%40lists.alioth.debian.org, you can see some of the activities which are packaged by debian developers. @quozl would be better at explaining where to obtain the activities, and verify the information I provided.

quozl commented 4 years ago

It is nothing to do with 32-bit.

You most likely have installed Python 2. In consequence, AM_PATH_PYTHON in configure.ac selects it, and so $PYTHON is /usr/bin/python2, and the subsequent check for the em module searches the Python 2 installation. This is the expected result. You must install the em module for whatever version of Python is first found, and that's what the error implies.

I tested with a bare directory on a system with both Python 2 and Python 3 installed;

$ mkdir
$ echo AC_INIT([sugar-artwork],[0.117],[],[sugar-artwork]) > configure.ac
$ echo AM_PATH_PYTHON >> configure.ac
$ autoconf -i
$ ./configure
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.7/dist-packages
checking for python extension module directory... ${exec_prefix}/lib/python2.7/dist-packages

sugar-artwork does not specify a Python version, and accepts either Python 2 or Python 3. So it isn't selecting python2 by itself, autoconf is doing it. Nothing in sugar-artwork requires a specific Python version.

Adding the python-empy package is a reasonable workaround.

The Journal over the Home View is a bug in Metacity. Workaround is to press F3 key. Use a later version. On the most recent Sugar Live Build, according to the package list I used 3.34. Debian Testing now has 3.36.

Do not use the Debian packages of activities with Sugar Live Build, they are not intended for this use. The activities will be shown by using F3 key. To install more activities, edit your Sugar Live Build file auto/config.

srevinsaju commented 4 years ago

oh okay, I apologize giving wrong information :sweat:

quozl commented 4 years ago

it's okay, it was clear that your information was speculative. :grin:

martinwguy commented 4 years ago

Thanks. May I ask how you make the recent Sugar Live Builds?

It's not by running plain "build", as that picks up metacity 3.30 from buster, an eariler version than your latest build's 1.3.34, and (for example) dbus 1.12.20, the same as in buster, while your package list has 1.12.16, an older version!

I've tried editing auto/config to use Debian testing ("bullseye") to get metacity (now) 3.38, but the repository doesn't contain packages python-{empy,decorator,dbus,cairo,dateutil,gi-cairo,pygame} and eliminating all python- packages to make it use python3 for everything give further errors which I haven't traced the cause of yet.

I'd appreciate further clues, or ideas in which direction I should be going, as getting a working SoaS on 32-bit laptops would enable us to recycle all those old laptops to make OLPC happen for children in our part of the world

Thanks again

M
quozl commented 4 years ago

Thanks. May I ask how you make the recent Sugar Live Builds?

According to my notes and filesystem, on 17th March I cloned the repository, made customisations, ran schroot to activate a Debian Buster context, then typed ./build. I've a local branch release-20200317 which contains my customisations that I did not wish to push to GitHub, due to it being a redistribution of a Metacity binary package for which I'd have to comply with the license. Looking at my customisations, they were;

It's not by running plain "build", as that picks up metacity 3.30 from buster, an eariler version than your latest build's 1.3.34, and (for example) dbus 1.12.20, the same as in buster, while your package list has 1.12.16, an older version!

Debian Buster has changed since then, with a new release of dbus made, so the package list will be different.

I've tried editing auto/config to use Debian testing ("bullseye") to get metacity (now) 3.38, but the repository doesn't contain packages python-{empy,decorator,dbus,cairo,dateutil,gi-cairo,pygame} and eliminating all python- packages to make it use python3 for everything give further errors which I haven't traced the cause of yet.

Debian Testing (bullseye) does indeed remove Python 2 support, (a decision of the Debian Project), so there will be lots of things that will need changing. I've not tried iterating on this yet. Debian Testing ran Sugar fine last I checked a few weeks ago, is there any reason why you can't use it by itself without using Sugar Live Build?

I'd appreciate further clues, or ideas in which direction I should be going, as getting a working SoaS on 32-bit laptops would enable us to recycle all those old laptops to make OLPC happen for children in our part of the world Thanks again M

Fedora SoaS won't support 32-bit CPUs now. A decision of the Fedora Project.

You might also look at OLPC OS 20.04.0, which is a rebuild of Ubuntu 20.04 (LTS) with Sugar and a selection of activities added.

martinwguy commented 4 years ago

Debian Testing (bullseye) does indeed remove Python 2 support

Hum. It still includes python2.7 and a slew of other python- packages... but not python-empy!

is there any reason why you can't use it by itself without using Sugar Live Build?

It's not for me (except for fun) as I'd like to be able to hand out Live CDs or DVDs that people can boot (and copy for friends) as a quick and easy way to spread the OLPC work and revitalise old laptops.

You might also look at OLPC OS 20.04.0, which is a rebuild of Ubuntu 20.04 (LTS) with Sugar and a selection of activities added.

Thanks, I'll check that out too.

In general, you might consider making the SLB distribution iso's 32-bit builds instead of 64, as that would increases the number of target systems, especially in poorer areas, 32-bit images also run on 64-bit CPUs anyway and use slightly less RAM, and I can't see Sugar apps making use of more that 4GB of available RAM. That would also have let me find a ready solution, though I am happy to contribute where I can.

Blessings

M

quozl commented 4 years ago

Debian Testing (bullseye) does indeed remove Python 2 support

Hum. It still includes python2.7 and a slew of other python- packages... but not python-empy!

Yes, a consequence of removing Python 2 support. It also does not include python-jarabe which is the Python 2 build of the Sugar shell, nor python-sugar3, which is the Sugar Toolkit. Debian Project is succeeding in implementing their plan. Consequence is that without adding external software, Debian Bullseye will not run Python 2 Sugar activities.

is there any reason why you can't use it by itself without using Sugar Live Build?

It's not for me (except for fun) as I'd like to be able to hand out Live CDs or DVDs that people can boot (and copy for friends) as a quick and easy way to spread the OLPC work and revitalise old laptops.

Okay, so you would be content with a Debian Live Build provided it booted directly into Sugar. That's exactly what Sugar Live Build is for, but it goes one step further and uses the latest version of Sugar available from Sugar Labs instead of the latest available for Debian.

You might also look at OLPC OS 20.04.0, which is a rebuild of Ubuntu 20.04 (LTS) with Sugar and a selection of activities added.

Thanks, I'll check that out too.

It is also 64-bit. At OLPC we cannot contract-manufacture 32-bit laptops, as the chip industry no longer produces the critical parts. It would be a few hours work for a developer to rebuild the packages for 32-bit and issue an OLPC OS for 32-bit. It isn't something I can see myself doing in the time I'm paid to work.

In general, you might consider making the SLB distribution iso's 32-bit builds instead of 64, as that would increases the number of target systems, especially in poorer areas, 32-bit images also run on 64-bit CPUs anyway and use slightly less RAM, and I can't see Sugar apps making use of more that 4GB of available RAM. That would also have let me find a ready solution, though I am happy to contribute where I can. Blessings M

I agree. I'm happy for someone else to do that, but I don't have any plans to do it myself. Why don't you do it, join Sugar Labs as a member, get a shell account for uploads to download.sugarlabs.org, and maintain Sugar Live Build for all of us?

martinwguy commented 4 years ago

nor python-sugar3, which is the Sugar Toolkit.

Though it does have python3-sugar3, so we can hope in that...

It would be a few hours work for a developer to rebuild the packages for 32-bit and issue an OLPC OS for 32-bit.

Thanks to your generous help, I've succeeded in building the system I wanted by dumping metacity-3.34 packages into it as you said. I had tried adding the relevant packages from bullseye, but ended up in dependency hell :-0

I'm happy for someone else to do that, but I don't have any plans to do it myself. Why don't you do it, join Sugar Labs as a member, get a shell account for uploads to download.sugarlabs.org, and maintain Sugar Live Build for all of us?

It's already so close to working that I can hope that shouldn't be too hard. At the very least I could mention in the README the few issues it has and how to work round them to get a working iso.

What I'd like is for people to be able to follow SLB's README and have it work for them, but from what you say, that either means 1) persuading the debian metacity maintainer to update buster to 3.34, 2) including those three binary packages for all architectures in SLB, or 3) updating to bullseye and translating all python2-dependent activities into python-3, which I guess would be the long-term goal. I see the Python2-dependent activities are included in the SLB tree and there is a tool "2to3" to do this. Or make a fake "python" that runs 2to3 and uses python3 :)

Re: 2), What was the licensing issue that you mentioned, about including the working metacity version in SLB? It appears to be under the GPL.

M
quozl commented 4 years ago

Thanks to your generous help, I've succeeded in building the system I wanted by dumping metacity-3.34 packages into it as you said. I had tried adding the relevant packages from bullseye, but ended up in dependency hell :-0

I'm pretty sure, but can't confirm, that I downloaded the bullseye source package and built it on buster. Commands such as apt source metacity and apt build-dep metacity, and debuild -us -uc.

It's already so close to working that I can hope that shouldn't be too hard. At the very least I could mention in the README the few issues it has and how to work round them to get a working iso.

Please raise issues for these in case they can be solved another way? This issue already solved.

? What I'd like is for people to be able to follow SLB's README and have it work for them, but from what you say, that either means 1) persuading the debian metacity maintainer to update buster to 3.34,

Yes, raise bug, offer fix as patch in bug, wait.

2) including those three binary packages for all architectures in SLB, or

Could also automate the download and build of the Metacity source package from Debian. Unpleasant because we'd be fixing a problem here that should really be fixed over there.

Could also provide the packages for download from another place.

3) updating to bullseye and translating all python2-dependent activities into python-3, which I guess would be the long-term goal

Except Debian Bullseye is not yet released, and not supported until it is released.

I see the Python2-dependent activities are included in the SLB tree and there is a tool "2to3" to do this. Or make a fake "python" that runs 2to3 and uses python3 :)

It isn't that simple. See our Python 3 Porting Guide.

However, all the activities included in the build at the moment are already Python 3. Resulting Python 3-only build would not run any downloaded Python 2 activities, so Browse ought to be patched to remove that feature.

Re: 2), What was the licensing issue that you mentioned, about including the working metacity version in SLB? It appears to be under the GPL. M

Happy to explain.

martinwguy commented 4 years ago

It's bit odd holding an intelligent conversation in a closed issue's comments :) but a few minds are often more so than many, if less well-informed :)

I downloaded the bullseye source package and built it on buster.

Ah, I found it and its friends under http://http.kali.org/kali/pool/main bless 'em!

At the very least I could mention in the README the few issues it has and how to work round them to get a working iso.

Please raise issues for these in case they can be solved another way

OK

the debian metacity maintainer to update buster to 3.34, Yes, raise bug, offer fix as patch in bug, wait.

Good idea. that will be a better long-term solution, as well as fixing everyone's metacities. Do you happen to know what the specific bug is?

2) including those three binary packages for all architectures in SLB, or Could also automate the download and build of the Metacity source package from Debian.

That's be harder for me, as I've only just met live-build and am still boggling at it and at the scripts that drive it

Unpleasant because we'd be fixing a problem here that should really be fixed over there.

That's the way it works...

Could also provide the packages for download from another place.

Well, if it were a sugarlabs location, that'd be secure; using kali's or another repo would introduce another possible point of failure. Or we could include the correct checksum in the build system.

3) updating to bullseye and translating all python2-dependent activities into python-3, which I guess would be the long-term goal

Except Debian Bullseye is not yet released, and not supported until it is released.

True, and Debian releases happen, as they say here, as often as a Pope dies. However, making everything Python3-compatible is also a slow process, so the two events may roughly coincide.

See our [Python 3 Porting Guide]

Yes, I found that subsequently. Not so straightforward.

However, all the activities included in the build at the moment are already Python 3.

Are you sure about that? I did a find..head..grep to assess the Python 2/3 balance and found a lot of #! python and /usr/bin/env python, which gets python2 at present and doesn't go through /etc/alternatives. However that may have been stuff it downloaded during the build as I ran it on a built tree. Either way, there's plenty of it to rework...

Resulting Python 3-only build would not run any downloaded Python 2 activities, so Browse ought to be patched to remove that feature.

I don't understand that. Which feature? If it matters...

  • it is different to the repository license of Public Domain, so the repository would become dual licensed,

Ah. I see.

  • it would be a redistribution of Metacity, so to comply with the GPL we would have to include the source in a form that can be built,

Or say "you can get it from here" I think. Or do we still have to offer to send it on magnetic tape? :)

  • including the source, and the packages, would make clones of this repository much larger; at the moment a clone is 22.49 KiB of objects.

True

I've thought about the offer to maintain SLB, as making an any-Debian-architecture build system would greatly increase its usefulness worldwide, and making an x86 version downloadable would make it much easier for the lion's share of suitable ageing hardware. Who do I contact?

M

quozl commented 4 years ago

It's bit odd holding an intelligent conversation in a closed issue's comments :) but a few minds are often more so than many, if less well-informed :)

We have a mailing list, but lately such discussions have dried up there as well. We have too few developers. Yes, I'm certainly not claiming to be well-informed. If off-topic conversations start in issues, I'm happy to continue them, but they aren't the best way to achieve collective action, because they are small groups.

the debian metacity maintainer to update buster to 3.34,

Yes, raise bug, offer fix as patch in bug, wait.

Good idea. that will be a better long-term solution, as well as fixing everyone's metacities. Do you happen to know what the specific bug is?

When an application asks to be started fullscreen without being maximised or presented to the user, i.e. iconified, Metacity is failing to comply. The Journal is one such application. It has happened at least two or three times in Metacity in the past few years; changes were made without testing this corner case. So I don't have specific bugs or commits. It just keeps breaking. It's a development process issue upstream. I'm resigned to it. If you'd like to find the specific commits, use git bisect on Metacity sources. I've no wish to repeat that work now, given that using a later version of Metacity works.

Could also provide the packages for download from another place.

Well, if it were a sugarlabs location, that'd be secure; using kali's or another repo would introduce another possible point of failure. Or we could include the correct checksum in the build system.

I don't consider Sugar Labs download locations secure. We don't have developer signing setup, and we don't have rigorous controls on access and membership.

However, all the activities included in the build at the moment are already Python 3.

Are you sure about that? I did a find..head..grep to assess the Python 2/3 balance and found a lot of #! python and /usr/bin/env python, which gets python2 at present and doesn't go through /etc/alternatives. However that may have been stuff it downloaded during the build as I ran it on a built tree. Either way, there's plenty of it to rework...

Yes, I'm sure. All the activities included in Sugar Live Build activate the sugar-activity3 wrapper in their .info file, therefore they are executing with Python 3. We do not use the hashbang (#!) and it may not be maintained.

Resulting Python 3-only build would not run any downloaded Python 2 activities, so Browse ought to be patched to remove that feature.

I don't understand that. Which feature? If it matters...

The app store link, "activities", for downloading additional activities into a Sugar environment. We have a Python 2 activity library at https://activities.sugarlabs.org/ but we don't have a Python 3 activity library available yet, though we have some people working on it.

True I've thought about the offer to maintain SLB, as making an any-Debian-architecture build system would greatly increase its usefulness worldwide, and making an x86 version downloadable would make it much easier for the lion's share of suitable ageing hardware. Who do I contact? M

If you want to avoid duplicating anyone else's effort, use the mailing list to announce your intent. Otherwise, just release it on your own GitHub fork, and once you have people who have tested it then we can work through membership and uploading to our downloads server.

martinwguy commented 4 years ago

We have a mailing list,

Yes, I'll pop up there when I have my ideas a little clearer.

they aren't the best way to achieve collective action, because they are small groups.

That corresponds with my experience too. "Keep it on-list" is one mantra.

When an application asks to be started fullscreen without being maximised or presented to the user, i.e. iconified, Metacity is failing to comply.

Another Debian option would to be to suggest a patch to be applied to the

If you'd like to find the specific commits, use git bisect

Erm, yes, I thought of that, but building and booting SLB for each iteration is a bit much, as is devizing an automated test case.

I don't consider Sugar Labs download locations secure.

OK, so the debian archive you found is a better solution

All the activities included in Sugar Live Build activate the sugar-activity3 wrapper

OK

The app store link, "activities", for downloading additional activities into a Sugar environment. We have a Python 2 activity library at https://activities.sugarlabs.org/ but we don't have a Python 3 activity library available yet, though we have some people working on it.

Got it. I assume that a 3-izing initiative is underway, but will also test the list on that subject

Bless

M

quozl commented 4 years ago

If you'd like to find the specific commits, use git bisect

Erm, yes, I thought of that, but building and booting SLB for each iteration is a bit much, as is devizing an automated test case.

Oh, I do not advise doing it that way. For each bisection iteration, rebuild Metacity, replace /usr/bin/metacity, and restart Sugar. Use either an installed Sugar Live Build or an installed Debian Buster system. Not a live-boot system. I prefer to get my test process down under a minute before I start a bisection.

Got it. I assume that a 3-izing initiative is underway, but will also test the list on that subject Bless M

It was, but there has been no significant work for a long time. IRC activity was worked on recently, but that's about all.