DBP repository


I found that when I didn't have write access on an SD card it was when I inserted the card into a different pc and didn't remove it safely. I have never seen this behavior on a different device but purposely safely removing/ejecting the card always made it work.
 
Hi, I have a question regarding dependencies.

So if we have deb dependencies but debian is annoying because the difference between buster and bookworm can be a good major let alone minor version number. How do we handle that in the desktop file? A good example is LUA, on the CorsixTH dbp, it would be liblua5.4 on bookworm, but buster is lua5.3 and I feel the system doesnt handle just having "liblua" (where the version string wouldn't matter)

Is there a nice way to handle this? I find this part very useful for people with dbps with weird dependencies they might not have installed.
 
Not sure if I understand your problem correctly, but when a program needs a specific version of a library, I just include the required libraries directly in my program and assign the path with LD_LIBRARY_PATH.
 
This is the dependency line in the desktop file for a dbp. I know they're not automatically installed at this time, but great way to inform someone of dependency changes.

Problem is, if i set them for buster and you run the dbp on bookworm, they'll never be satisified so will always get a warning on running the file.
 
Luckily it's not that often a specific version of a library is needed. So most cases, a dbp compiled on buster would run fine on bookworm.
I had a similar problem with CaveExpress on buster where liblua 5.2 was needed.
So in these rare cases i think it's still the best solution to include the libraries locally unless someone has an idea how to distinguish the debian version in the dbp's desktop file!
 
including the libraries in the pnd is a handy, good idea. Not at that level just yet but could see how useful that is. Good idea cheers
 
Link errors are quite common in my (limited) dbp experience. And dependencies on unavailable pkg versions. And odd bugs presumably due to changes in dependency behavior. Was thinking something like AppImage might be nice.
 
Hello,
I tried to upload a .dbp, but I always get the message "Upload Failed".
The file is probably too large (5.3 MB).
What is the file size limit? Is it the default php.ini upload_max_filesize of 2MB?

The file that I tried to upload is:
I tried to use this URL in the "Using FTP" input, but that didn't work (I guess because it's http, not ftp). I don't know where to upload it to make it available via ftp.
 
So finally TWO MONTH has made it's way to the Pyra, which means some bigger files still can be uploaded. What's the exact problem with some files always showing upload failed and other files working?
 
So finally TWO MONTH has made it's way to the Pyra, which means some bigger files still can be uploaded. What's the exact problem with some files always showing upload failed and other files working?
that file have been uploaded using the ftp method, not the usual upload one.
I guess the php setting still have to be fixed :(
 
I tried to upload a .dbp, but I always get the message "Upload Failed".

I tried to use this URL in the "Using FTP" input, but that didn't work (I guess because it's http, not ftp). I don't know where to upload it to make it available via ftp.
Using FTP works great when uploading to the DragonBox Pyra - GIT Repositories first. Even very large .dbp files then appear in the Pyra Repository within seconds, because the file is already on the same server.
If you register an account it takes at least Two Months™ for ED to manually activate the account. Contact him via Discord to speed up the process.
 
Why was the ftp upload implemented originally? Was it implemented after the move to the new server, to solve exactly the problem we are talking about? Or was it implemented already earlier, beacause of some other reasons (maybe the normal upload was not reliable enough or something like that)?
 
Since the root cause of the current upload restriction is not the php.ini (ED already checked that), it is probably an Apache2 configuration, some firewall, or something else that we can't think of right now.

Even though the problem is not in the code of the “Pyra Repository,” we could still develop a workaround for the upload restriction. We could use JavaScript to split the upload into chunks and send them to the server piece by piece using Ajax requests. After the server side has collected all the chunks, the PHP code would concatenate all the chunks again.

I don't want to implement this idea right away. I want to wait a little bit longer to see if ED can fix the problem. However, if he can't fix it, this would probably be a last straw to solve the problem once and for all.
 
Back
Top