cooler
Crew Member
 
Posts: 123
Likes: 120
|
Post by cooler on Apr 20, 2021 19:11:55 GMT
I am for ARM architecture as next step I agree actually. An arm version would be good.
How about a foot one? 
I for one thought that the decision to drop the Chromebooks version was a wise one.
I too think that a Debian base would be really cool... it seems to me that Ubuntu is heading in a direction not that good (for a minimalist system) with the flatpaks..
|
|
enigma9o7
Crew Member
 
Posts: 1,054
Likes: 1,108
Member is Online
|
Post by enigma9o7 on Apr 20, 2021 19:59:43 GMT
I personally think it would be cool to be able to run Bodhi on something like rpi400. The distro it ships with is debian based using pixel desktop based on lxde. So I think it's doable. And there are other distros that work on arm devices, mainly intended for touchscreen, like manjaro with plasma mobile. But being cool and possible doesn't mean it doesn't take time tho. And as far as I know nobody on bodhi team even has such a device. However if somebody with an rpi or other arm device wanted to step up and do the work, I bet rest of team would do what they can to support it. Would have to build all packages in bodhi repo for arm and maintain them, including any new packages that are added for bodhi legacy 6 to support debian.
|
|
|
Post by majpooper on Apr 21, 2021 16:20:37 GMT
I would expect the amd64 versions would work from b5main and/or b6main. You can use a web browser to browse and download (or get exact url if modifying script) if you want to try.
Yeah - that was obvious and I did that from the start but it still blew up - but upon further scrutiny I found something rather strange; Throughout the entire script everywhere there was supposed to be the letter "r" there was a space - for example control was cont ol and so on. I don't know if this was the script or my VM. Anyway I edited the script to correct for all the missing "r" characters and ran it again - no joy. But this could be because I have now somehow corrupted the whole process by re-running the script a second time on top of the faulty script. I will start over again in a new VM later when I have some time and will probably run the script commands manually so I can see line by line what may be the problem. I get it though . . . I am trying to run a process designed for 32bit on a 64 bit system which was not your intent.
|
|
enigma9o7
Crew Member
 
Posts: 1,054
Likes: 1,108
Member is Online
|
Post by enigma9o7 on Apr 21, 2021 18:21:55 GMT
I'm guessing the r you're tlaking about must be related to line endings.
How did you obtain the script? If I copy and paste from the first post using linux web browser into text editor, works for me. If you wget from pastebin with that trim command from first post, that fixes the line endings issue on pastebin and also works for me.
If you're trying to adapt the script tho you shouldn't test everything at once. Just run it up to the first time you do something different and nothing after there, so you can see if there's any error and what you need to do about it. Then resolve it at command line and then make sure script is good. Easiest to test in VM cuz you can reset to clean and start over easily to.
But if not using a VM, I'd ssh from another computer so you have scrollback! there is no scrollback in tty. so when you first install debian you can check the box to install ssh, or if you didnt, just sudo apt install ssh, then you can ssh in from another computer.
|
|
|
Post by majpooper on Apr 23, 2021 2:00:37 GMT
If you wget from pastebin with that trim command from first post, that fixes the line endings issue on pastebin and also works for me. Good2go - have Moksha 64bit installed on Debian Bullseye.
Not sure how I jacked it up the first time but started with a clean VM and used the wget per the first post and all went well this time . . . . but I thought that is what I did the first time as well - obviously not.
Edited the gomoksha.sh with nano replacing i386 with amd64 and only used the first four steps - I can tweak moksha to my liking from there.
Bodhi is fine being based on Ubuntu . . . . for now. And I get the "Debian is stable but not the latest and greatest app version" thing - kind of. But I, personally, will trade latest and greatest for Debian stability as a base for Bodhi performance all day long without the worry of where Conical is going with Ubuntu . . . I guess I am paranoid.
EDIT: Now that I have played with this some I recommend anyone using this at least use the script down to step #6. You can pick and choose the stuff you want in #5 and edit #6 for the themes you like but they definitely do make life much easier.
This is a fantastic tool if you are a Moksha and Debian fan.
THX! Enigma
|
|
enigma9o7
Crew Member
 
Posts: 1,054
Likes: 1,108
Member is Online
|
Post by enigma9o7 on Apr 24, 2021 19:31:59 GMT
Looks like debian just released an RC ISO too!
[Updated Links in first post]
|
|
|
Post by majpooper on Jun 5, 2021 17:34:52 GMT
I may have gotten in over my head here but I really like the concept of an Ubuntu-less Bodhi or put another way a Debian Moksha. So I modified enigma's excellent script to install Moksha on a Debian 11 Bullseye amd64 based system. I made a few other modifications to the script in terms of applications installed but nothing significant. I works great and I have tested it in a VM (several times which I typically do) and now have it on my travel laptop an old ThinkPad T400 (Dual Core with hardly any cache - threw in a cheap 120G SSD and two 4G RAM sticks I had left over from another laptop upgrade) and it runs like a very nicely - snappy is the word. However here is the glitch: I tried to install gdebi (I should have done this during the install) It fails with unmet-dependencies bodhi-bins-default. I can live without gdebi or I suppose do a fresh install but I am wondering is there a URL I can wget to load bodhi-bins-default?
EDIT: I must add after looking at the script I shot myself in the foot by commenting out installing some apps such as gdebi thinking I would add my own set of apps from Moksha. For the most part this worked fine.
|
|
enigma9o7
Crew Member
 
Posts: 1,054
Likes: 1,108
Member is Online
|
Post by enigma9o7 on Jun 5, 2021 19:53:28 GMT
Hmmmm not sure why gdebi would not install after Moksha. That should come from debian bullseye repo with no bodhi/moksha related dependencies that I know of, and if the priorities are set right, apt shouldn't even look in bodhi repo if its in debian bullseye repo, but otherwise it should...
So its weird to me for two reasons, #1 it shouldnt need something from bodhi repo in the first place #2 even if it does, it should have found it.
I suspect some propblem with the pin priority. Did you use the same numbers as the script (100 for stable, 50 for b6main, 10 for unstable)? That worked for me, but I only figured that out for the purpose of this procedure, it was not somethiing I was at all familiar with, so may have not used ideal values.
|
|
|
Post by majpooper on Jun 5, 2021 21:03:20 GMT
OK I will have to test some more - I have been playing around b5maim vs b6main but hadn't a clue RE: the pin priority or what it did so will test that as well.
THX for getting me in the right direction
|
|
enigma9o7
Crew Member
 
Posts: 1,054
Likes: 1,108
Member is Online
|
Post by enigma9o7 on Jun 5, 2021 21:34:35 GMT
I would suggest b6main. Everything in bullseye repo is same or newer version than focal, and b6main may have things that depend on packages with focal or later versions. b5main may contain some too old stuff, the only reason I used it at all in this script was because b6main doesnt contain i386 binaries (only amd64 and all, at least when I wrote this), but for amd64, no need for anything from b5. And also once bl6 releases legacy version, b6 repos will have all the needed i386 packages.
|
|
|
Post by majpooper on Jun 7, 2021 21:11:57 GMT
I have been testing the script with b6main. I am a novice when it comes to scripts so I am probably overlooking something. Anyway I found the b6 repos and incorporated the changes into the script and ran it section by section for amd64. Interestingly enough the b5 .deb packages location and names changed a bit (http://http://packages.bodhilinux.com/bodhi/pool/b5main/e/edbus to http://http://packages.bodhilinux.com/bodhi/pool/b6main/libe/libedbus1) But I seemed to have figured that out - at least they ran and produced no errors.
What puzzes me though is that udisk did not seem to change really at all but editing b5 to b6 produces errors after running sudo wget http://packages.bodhilinux.com/bodhi/pool/b6main/u/udisks/ running dpkg-deb: error: failed to read archive 'udisks_1.0.5-1_amd64.deb': No such file or directory The file definitely exists.
here is what the b6 amd64 modifications to the udisk portion of the script looks like
wget http://http://packages.bodhilinux.com/bodhi/pool/b6main/u/udisks/udisks_1.0.5-1_amd64.deb dpkg-deb -x udisks_1.0.5-1_amd64.deb udisks dpkg-deb -e udisks_1.0.5-1_amd64.deb udisks/DEBIAN sed -i 's/liblvm2app2.2/liblvm2-dev/g' udisks/DEBIAN/control # liblvm2app2.2--> liblvm2-dev fakeroot dpkg-deb -b udisks bullseye-udisks.deb apt install -y ./bullseye-*.deb
|
|
|
Post by majpooper on Jun 7, 2021 21:16:09 GMT
Oh . . . . and the gdebi package not loading I still haven gotten to but that is really minor in that dpkg -i command is just as use useful. I am really more interested in accessing the b6 repos.
|
|
enigma9o7
Crew Member
 
Posts: 1,054
Likes: 1,108
Member is Online
|
Post by enigma9o7 on Jun 8, 2021 4:43:11 GMT
For 64-bit, section 2 would need to be changed. If I were doing it I would probably add bodhi 6 repo to sources, then use `apt download` to get them, instead of wget. (the only reason not to apt install would be because I suspect they would complain about the same missing packages as the 32-bit packages from bodhi 5.1, but I'd of course try just installing them first before messing with them). This is still a hacky method tho, but I learned lots by trying it, but now know more than when I started and so would do other things differently to, but that's the same with everything.... To add bodhi 6 repos, I'd do it the same way I did in step 4, with the 50 priority, just move that to the beginning of step 2.
wget http://packages.bodhilinux.com/bodhi/pool/b6main/b/bodhilinux-keyring/bodhilinux-keyring_2020.12.17_all.deb apt install -y ./bodhilinux-keyring_2020.12.17_all.deb # install key to bodhi 6 repository echo "deb http://packages.bodhilinux.com/bodhi focal b6main" > /etc/apt/sources.list.d/bodhi-b6main.list # add to list echo "Package: * Pin: release n=b6main Pin-Priority: 50" > /etc/apt/preferences.d/bodhi-b6main-pin # make Bodhi repositories low priority apt update # update software database But as I said, I'm no expert with pin-priority, but the goal there was to make it so it only uses bodhi repos when debian repos dont have it.
|
|