Hey, I am not the only one waiting for this?!
Last edited by a moderator:
The software side
- Thread starter aTc
- Start date
So I forked makepkg into makepnd and produced PND under dchrt.
Even though makepkg is 3k lines of bash, I was surprised that it dint depend on pacman pretty much at all, and was quite depressed how little effort I had actually do.
Here is recipe:
# Maintainer: Jari Vetoniemi <mailRoxas <at> gmail <dot> com>
pkgname=milkyhelper
pkgver=3.0.6
pkgrel=6
pkgdesc="Package manager for PND repositories"
url="http://github.com/Cloudef/libpndman"
license=('WTFPL')
depends=('jansson' 'curl' 'openssl' 'expat' 'bzip2')
source=('milky.sh' 'startup.conf'
'icon.png' 'milky1.png' 'milky2.png' 'milky3.png'
'git+git://github.com/Cloudef/libpndman.git')
icon=('icon.png')
screenshot=('milky1.png' 'milky2.png' 'milky3.png')
executable=('milky.sh')
category=('Settings/PackageManager')
md5sums=('90c73f9c56b5214d652c0e64448b8b01'
'6e03ccb492c9510c4a9ea3f50756244e'
'66c00447bc5abacd02bbfdd81a57d6c8'
'3a039fe54507fdf57111aa33958b4ead'
'e7ac3042801b8104d389fb9ce1f393e1'
'5749c26c777cc2e1ebfa587d75534a7a'
'SKIP')
build() {
cd libpndman
git submodule update --init --recursive # jansson is not in opkg
cmake -DCMAKE_INSTALL_PREFIX=/usr -DLIBPNDMAN_BUILD_STATIC=ON .
make
}
package() {
cd "$srcdir/libpndman"
make DESTDIR="$pkgdir" install
install -m755 "$srcdir/milky.sh" "$pkgdir/"
install -m644 "$srcdir/startup.conf" "$pkgdir/"
install -m644 "$srcdir/milky"{1,2,3}".png" "$pkgdir/"
install -m644 "$srcdir/icon.png" "$pkgdir/"
}
# vim: set ts=8 sw=2 tw=0 ft=sh syn=sh :
And here is output PND:http://cloudef.eu/pnd/milkyhelper-3.0.6-6-armv7.pnd
(and yes, it works)
All the makepkg features also work that don't depend on pacman. I already inserted hook to call different package managers and am thinking of supporting, pacman, opkg and apt-get (build dependencies).
(Runtime dependencies are not the context of current pnd system here, recipe however would copy missing libraries in default os to the PND or static link)
These kinds of recipes would go to some centralized site (see AUR).
There would be way to contribute improvements to them by community members as well, to fix such things as the famous control mappings and such.
This would also encourage people send patches that should not be in recipe to upstream. (be in recipe of course until accepted)
Of course you could generate deb from this too, but for that I would separate the PND specific script files to post_package_pnd() or something, since they are not needed in .deb (or any other distro specific format).
Even though makepkg is 3k lines of bash, I was surprised that it dint depend on pacman pretty much at all, and was quite depressed how little effort I had actually do.
Here is recipe:
# Maintainer: Jari Vetoniemi <mailRoxas <at> gmail <dot> com>
pkgname=milkyhelper
pkgver=3.0.6
pkgrel=6
pkgdesc="Package manager for PND repositories"
url="http://github.com/Cloudef/libpndman"
license=('WTFPL')
depends=('jansson' 'curl' 'openssl' 'expat' 'bzip2')
source=('milky.sh' 'startup.conf'
'icon.png' 'milky1.png' 'milky2.png' 'milky3.png'
'git+git://github.com/Cloudef/libpndman.git')
icon=('icon.png')
screenshot=('milky1.png' 'milky2.png' 'milky3.png')
executable=('milky.sh')
category=('Settings/PackageManager')
md5sums=('90c73f9c56b5214d652c0e64448b8b01'
'6e03ccb492c9510c4a9ea3f50756244e'
'66c00447bc5abacd02bbfdd81a57d6c8'
'3a039fe54507fdf57111aa33958b4ead'
'e7ac3042801b8104d389fb9ce1f393e1'
'5749c26c777cc2e1ebfa587d75534a7a'
'SKIP')
build() {
cd libpndman
git submodule update --init --recursive # jansson is not in opkg
cmake -DCMAKE_INSTALL_PREFIX=/usr -DLIBPNDMAN_BUILD_STATIC=ON .
make
}
package() {
cd "$srcdir/libpndman"
make DESTDIR="$pkgdir" install
install -m755 "$srcdir/milky.sh" "$pkgdir/"
install -m644 "$srcdir/startup.conf" "$pkgdir/"
install -m644 "$srcdir/milky"{1,2,3}".png" "$pkgdir/"
install -m644 "$srcdir/icon.png" "$pkgdir/"
}
# vim: set ts=8 sw=2 tw=0 ft=sh syn=sh :
And here is output PND:http://cloudef.eu/pnd/milkyhelper-3.0.6-6-armv7.pnd
(and yes, it works)
All the makepkg features also work that don't depend on pacman. I already inserted hook to call different package managers and am thinking of supporting, pacman, opkg and apt-get (build dependencies).
(Runtime dependencies are not the context of current pnd system here, recipe however would copy missing libraries in default os to the PND or static link)
These kinds of recipes would go to some centralized site (see AUR).
There would be way to contribute improvements to them by community members as well, to fix such things as the famous control mappings and such.
This would also encourage people send patches that should not be in recipe to upstream. (be in recipe of course until accepted)
Of course you could generate deb from this too, but for that I would separate the PND specific script files to post_package_pnd() or something, since they are not needed in .deb (or any other distro specific format).
Last edited by a moderator:
Linux-SWAT
Forum Addict!
- Joined
- Feb 13, 2010
- Messages
- 9,194
Oh, there's also a makepkg in Arch ?
Is it related to Slack's one ?
Is it related to Slack's one ?
Might be, it has bit of history:
https://projects.archlinux.org/pacman.git/tree/scripts/makepkg.sh.in
ShleeDragon
Pro-Catflip
- Joined
- Aug 28, 2010
- Messages
- 1,749
Last edited by a moderator:
skeezix
Internal Development
That is the coolest thing I've seen all day
rSl
tealifted
- Joined
- Nov 19, 2005
- Messages
- 1,141
arch's aur/makepkg is really great!
imho http://archlinuxarm.org/platforms/armv7/ti would be a nice place for the new pyra os.
imho http://archlinuxarm.org/platforms/armv7/ti would be a nice place for the new pyra os.
Linux-SWAT
Forum Addict!
- Joined
- Feb 13, 2010
- Messages
- 9,194
Not the same.
Last edited:
Rockthesmurf
Advanced Member
Things I like about the .PND system include:
I'm not against all these new options being explored, and hope cool things will come out of them, but I just felt a bit like the PND and OS/firmare system is receiving close inspections for all its problems, and it obviously had problems, but certainly any new systems needs to also make sure it inherits all the good things about the current set up (as every good thing it fails to implement, just ends up as a bad thing/problem for the new system). I don't think I've posted anything here that hasn't already been said, but I wanted to just 'get behind' the above ideas.
With regards to doing this stuff early, and people making a positive attempt to improve things, I salute you, and thank you, always amazes me what a great community we have here, with people devoting spare time to improve the project.
- Having a repo/store where I can browse what is available, see screenshots, read descriptions and view comments, even more so that the information/comments is specific to the Pandora version, typically I don't give a hoot about a desktop Linux comments for a PND I am downloading
- Being able to download PND's from my Windows PC, copy to SD card, insert into my Pandora, have it show up in the menu, and play
- Not being restricted to internal storage
- Being able to hot swap SD cards
- Things 'just working' (maybe there are occasional issues, but rare, the usual case is copy PND, run it, no problems, no dependency craziness, no special knowledge required)
- Simple to build (this is quite a long time out of date, but https://github.com/Scraft/jamplus/blob/master/bin/modules/c-compilers/pandora-gcc.jam is what the build system I uses to build PNDs from scratch, it was implemented in a few hours)
- Making the Pandora feel a bit special and console/handheld like (maybe this seems silly, but I don't really have so much interest in a handheld that is just 100% Linux PC, with nothing special, part of the fun for me as a developer is implementing a few bits here and there to get my software running on a new device). Notice I said at the start that this is a list of things I like, I'm not saying everyone has to agree with this point (or any others)
- As a non OS/firmware developer, I don't know (and from an end users perspective) don't care, about the problems the maintainers have, I like the fact it just works, it doesn't nag me for updates every time I switch it on, when there is an update it is easy to get and install, and doesn't seem to break anything. It maybe held together with sticky tape and string but on the whole, I don't care. Yes of course I understand the problems with this, and know ultimately it holds somethings back. But what I am trying to say is that having a perfect system for building firmware/OS's/whatever is important, but not the be-all and end-all.
- Given the hardware constraints seems to run reasonably (less of a concern for the new hardware by the looks of things)
- Really nice to have a 'proper' OS that you can boot to, build stuff, grab packages, not worry about space to install stuff (I run from a SD)
- Feels a bit more 'grown' up
- I have found it easier to find information on how to do various things under Slackware (guess it is more widely used?)
I'm not against all these new options being explored, and hope cool things will come out of them, but I just felt a bit like the PND and OS/firmare system is receiving close inspections for all its problems, and it obviously had problems, but certainly any new systems needs to also make sure it inherits all the good things about the current set up (as every good thing it fails to implement, just ends up as a bad thing/problem for the new system). I don't think I've posted anything here that hasn't already been said, but I wanted to just 'get behind' the above ideas.
With regards to doing this stuff early, and people making a positive attempt to improve things, I salute you, and thank you, always amazes me what a great community we have here, with people devoting spare time to improve the project.
vinipsmaker
Member
According to http://boards.openpandora.org/topic/15574-confliting-requirements/#entry311187 and _wb_, this feature won't be available to Pyra. Maybe.
EDIT:
Just to make clear: you'll need to connect the Pyra to the internet to be able to do software installation.
Last edited by a moderator:
slaeshjag
¯\_(ツ)_/¯
Well, according to Cloudef, pandora users with windows, and especially developers on windows, doesn't exist ;P
skeezix
Internal Development
One of the interesting things is people thinking debs are better than pnd, say; they are different entirely, not comparable. More to point, people need to consider why pnds are the way they are.. It was not randomly chosen buts, though much of it was due to limitations.
A few of the issues have nothing to do with lnd as a system, just how most people roll them; this is a question of policy, strong standards and validation .. And limits.
We wanted pandora apps to work; with swappable media and limited space we needed a cart like system. Given limited space and a desire not to break apps over time for example, it was Assumed people would pad pnds with libs and versions .. The firmware had to have old stuff or risk breaking things (update where abi is compatible which is most core)..
People in turn wanted tight small pnds; these are at odds
So for that one example it might be unintuitive to some .. Need to think through what we want and how to enforce it; this whole set of discussion topics is needed, and someone needs to record consensus; and someone has to make tough calls that are right, and not popular..
Other concerns we had were performance; couldn't use zip since in-memory drivers sucked; couldn't do .ar because of this or that, and so on.
Theres a lot of hard won lessons in pnd that people are quick to dismiss. Thats okay, we need new ideas we'll muddle through, w've got -time- for once, and more devs than last time. The biggest mistake by far before was C sending dev units out -after- the original ship date; he thought software would be easy, thought nothing of it. Poor notaz and djw carried it all, alone till then. The rest of us came in late, and it was said we had a couple of weeks at most, to design the userspace and we invented pnds etc. then it slid and slid and slid and we'd have done different if we knew we had months
This time is different
A few of the issues have nothing to do with lnd as a system, just how most people roll them; this is a question of policy, strong standards and validation .. And limits.
We wanted pandora apps to work; with swappable media and limited space we needed a cart like system. Given limited space and a desire not to break apps over time for example, it was Assumed people would pad pnds with libs and versions .. The firmware had to have old stuff or risk breaking things (update where abi is compatible which is most core)..
People in turn wanted tight small pnds; these are at odds
So for that one example it might be unintuitive to some .. Need to think through what we want and how to enforce it; this whole set of discussion topics is needed, and someone needs to record consensus; and someone has to make tough calls that are right, and not popular..
Other concerns we had were performance; couldn't use zip since in-memory drivers sucked; couldn't do .ar because of this or that, and so on.
Theres a lot of hard won lessons in pnd that people are quick to dismiss. Thats okay, we need new ideas
we'll muddle through, w've got -time- for once, and more devs than last time. The biggest mistake by far before was C sending dev units out -after- the original ship date; he thought software would be easy, thought nothing of it. Poor notaz and djw carried it all, alone till then. The rest of us came in late, and it was said we had a couple of weeks at most, to design the userspace and we invented pnds etc. then it slid and slid and slid and we'd have done different if we knew we had months This time is different
Rockthesmurf
Advanced Member
Seems like a step backwards to me... the Pandora has the problem that the Wifi is very badly broken (sure some people on some configurations can use it fine, but there are also others that can't use Wifi with multiple Pandoras tested on multiple Wifi points) so I guess that makes the Pandora even more reliant on being able to copy PND's over from a PC, if this is fixed then maybe Wifi becomes a little better, but the Wifi will need to be both really stable/reliable and also really fast (as downloading at 1 MB/s at least) otherwise large downloads are going to be painful.
Sigh; well I hope it is safe to assume that there is enough sense that that can't possibly be deemed as a final solution? I've never owned a device that requires my desktop OS to be Linux, and I am surely not going to be the only one.
If the choices are keep the current Pandora set up, or move to something where you can't offline download, can't easily copy to SD and are forced to use a Linux desktop, I'd vote for keep the current system, as the current system sounds really bad compared to what we already have! I just hope that we are currently in the early days, and overtime the various highlighted problems are going to be resolved.
It certainly sounds to me like my hopes/desires align quite closely with ED's.
Last edited by a moderator:
ptitSeb
Serial Porter
Nonsence. Doing that would be suicide.
Oh really? So I guess I either doesn't exist, or I'm not a dev.
Last edited by a moderator:
Exactly. I want to keep the PND system and improve it, along with standard Debian which allows updating and installing standard stuff onto the internal storage (mainly OS).
Have you released anything yet, as proof you're a dev?
Last edited:
SeeThruHead
Member
- Joined
- Dec 23, 2010
- Messages
- 112
Would be nice if the pyra could come as close to a debian desktop as possible. If it could be used jusy like you would any ordinary debian install. That being said minimenu and a pnd system would be nice but not as important as on Pandora assuming it gets close to a real debian pc.
ptitSeb
Serial Porter
Yeah, I'm working on itHave you released anything yet, as proof you're a dev?
Look at this picture:
. My gigahertz Pandora is on my local network on Wifi, And I am connected from my Windows main machine using SSH 2*times (left screen is compiling using cmake, probable a PPSSPP release, I don't remember), et also developping using Notepad++ (but I also use Geany from time to time) using SMB share from the Pandora.So when I'm on the move, everything is still on my Pandora so I can continue compiling and editing sources...
Last edited by a moderator:
