* Package name : ppsspp Version : 0.5 Upstream Author : Henrik Rydgård <hrydgard@gmail.com> * URL : http://www.ppsspp.org/ * License : GPL2+ PSPSDK BSD-compatible license Programming Lang: C, C++, Objective-C and Description : ppsspp: A portable PSP emulator. PPSSPP is a PSP emulator written in C++, and translates PSP CPU instructions directly into optimized x86, x64 and (soon) ARM machine code, using an efficient JIT compiler. PPSSPP can thus run on quite low-spec hardware, including stronger Android phones and tablets, as long as there's support for OpenGL ES 2.0. PPSSPP is still in early development, some features like audio playback for ATRAC3+-encoded content is not implemented. Many games, however, are already playable: http://www.ppsspp.org/compatibility.html
Hi John, May I know what is the progress of this ITP? Thanks, Anthony
Hello Anthony! Sorry for the late reply! I was on a trip through South America the past three weeks and had very limited internet access. Anyway, ppsspp is still on my TODO list. I have a working package for an older version [1], but I didn't go ahead and uploaded it back then since there were still some issues with the package. I will look back into it the next weeks. I am currently busy working through everything that has piled up the past three weeks. Adrian
Hi, Are there any progress in this ITP? I had already packed it (I didn't know someone was working on it), the problem is I use 2 packages, one for SDL and other for Qt, so I need to merge them to push to mentors. https://code.launchpad.net/~sergio-br2/ppsspp/debian-sdl https://code.launchpad.net/~sergio-br2/ppsspp/debian-qt These are what I'm using in the PPA, 1.0.1 version. Are you going to work yet in the packaging? PS: they use a different version of ffmpeg, with atrac3+ enabled... I don't know if it's possible to use ffmpeg/libav from the repo.
Hi Sergio! I actually had an almost finished package but at some point I forgot about it because I was busy with other stuff. You mean, you have two packages, one for the SDL and one for the Qt port? In any case, yes, you should merge them. I'm happy to work on the package with you together if you like. You will have to use ffmpeg or libav from the repositories. Embedded libraries, especially something like ffmpeg/libav are a no-no on Debian. Adrian
Hi! I updated a preliminary Qt packaging: http://mentors.debian.net/package/ppsspp-qt It's missing some stuff yet, like shared ffmpeg (works with 2.7.2), cityhash and libpng (>=1.6.x). I don't know if it's worth to package the SDL port, It's not working on ARM hardware and it seems it's not very well maintained. We will need some help in the atlas fonts, I am not sure if those fonts (take a look at tools.patch) covers most of the cases; and maybe it's missing some languages. When it runs the atlas scripts, you can see a lot of characters missing. The source is based in the git version (6fee2b4). They will release 1.1 soon I think. Hey @glaubitz, do you have a good copyright file in your package? Sérgio Benjamim
I updated the source to the latest git commit (dc4fb4c). Upstream will release 1.1 soon I think. Here what I deleted from the source: find . -name "*.vcxproj" -type f -delete find . -name "*.vcxproj.filters" -type f -delete rm -f -r ext/native/ext/libpng17 ext/native/ext/glew ext/native/ext/libzip ext/native/android/libs/com.bda.controller.jar ext/snappy ext/zlib ios pspautotests dx9sdk Windows Blackberry assets/ppge_atlas.zim assets/ui_atlas_lowmem.zim assets/ui_atlas.zim Core/Util/ppge_atlas.cpp Core/Util/ppge_atlas.h UI/ui_atlas.h UI/ui_atlas.cpp assets/Roboto-Condensed.ttf Tools/SaveTool/kernelcall.prx .travis.sh .travis.yml .ycm_extra_conf.py android/ and ext/native/android/ should be deleted too, but ppsspp actually is using some files from there even in desktop (!). https://github.com/hrydgard/ppsspp/issues/7823 I had to add DroidSansThai.ttf in the assets/ folder, there's no package on debian with it. Help are welcome in this package. cheers, sergio-br2
Does it still rely on an embedded version of ffmpeg? I think we will have little chance of getting the emulator accepted into Debian until this issue has been resolved. The code must be patched to use the ffmpeg libraries which are available in Debian. Adrian
The package now use ffmpeg from the system :) https://mentors.debian.net/package/ppsspp Sergio Benjamim
Very good, thank you! I will have a look later this week. Today I'm quite busy. Adrian
About the xbrz license (ext/xbrz/*) Sergio Benjamim-------- Forwarded Message -------- Subject: Re: xbrz license GPL-3+ ? Date: Wed, 16 Sep 2015 11:02:10 +0200 GPL-3 Regards, Zenju
I had a doubt about the license in ext/xbrz/* of ppsspp, it was very dubious, I didn't find this info in the web and I thougth it was better reply this here to have some documentation. btw, the copyright file is done. Sergio Benjamim
The package is updated to 1.1.0.
Hi Sergio! of. Most notably, lintian complains about an embedded libpng: E: ppsspp-sdl: embedded-library usr/games/ppsspp-sdl: libpng N: N: The given ELF object appears to have been statically linked to a N: library. Doing this is strongly discouraged due to the extra work needed N: by the security team to fix all the extra embedded copies or trigger the N: package rebuilds, as appropriate. N: N: If the package uses a modified version of the given library it is highly N: recommended to coordinate with the library's maintainer to include the N: changes on the system version of the library. N: N: Refer to Debian Policy Manual section 4.13 (Convenience copies of code) N: for details. N: N: Severity: serious, Certainty: possible N: N: Check: binaries, Type: binary, udeb N: This might be a false alarm, but you should verify it in any case as the FTP team will most likely reject the package if its binaries contain any embedded libraries. lintian also complains about unused paragraphs in the copyright file: I: ppsspp source: unused-file-paragraph-in-dep5-copyright paragraph at line 254 N: N: The Files paragraph in debian/copyright is superfluous as it is never N: used to match any files. You should be able to safely remove it. N: N: Refer to N: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for N: details. N: N: Severity: minor, Certainty: possible N: N: Check: source-copyright, Type: source N: I: ppsspp source: unused-file-paragraph-in-dep5-copyright paragraph at line 91 I: ppsspp source: unused-file-paragraph-in-dep5-copyright paragraph at line 95 As well as the extended description being too short: I: ppsspp-common: extended-description-is-probably-too-short N: N: The extended description (the lines after the first line of the N: "Description:" field) is only one or two lines long. The extended N: description should provide a user with enough information to decide N: whether they want to install this package, what it contains, and how it N: compares to similar packages. One or two lines is normally not enough to N: do this. N: N: Refer to Debian Developer's Reference section 6.2.1 (General guidelines N: for package descriptions) and Debian Developer's Reference section 6.2.3 N: (The long description) for details. N: N: Severity: minor, Certainty: possible N: N: Check: description, Type: binary, udeb N: Note that the extended description should actually introduce your package to users who have never heard of it before. Thus, your description is actually a bit too short for someone who doesn't know what ppssppp actually is. If you like, you can use my description that I wrote back when I first packaged ppsspp for Debian: Description: A portable PSP emulator ppsspp is a cross-platform emulator for Sony's PlayStation Portable handheld console. The emulator features a built-in just-in-time compiler (JIT) to quickly translate the CPU instructions of the PSP into native code of the host system, thus providing high performance on platforms where the JIT is supported (currently x86 and x86_64, soon ARM). Supported platforms include all major desktop operating systems as well as various smart phone platforms like Android. In case you didn't know, please always run lintian against the changes file of the freshly built binary packages with: lintian -i -E -I --pedantic ppsspp_1.1.0-1_amd64.changes Running lintian against the source changes file or omitting any of the options above may lead to important lintian warnings or errors being missed. Please fix the issues above, then I'll upload ppsspp to unstable. The rest of the package looks fine so far. Well done! Adrian
Hey Adrian, It needs libpng >= 1.6, and it's only in the Experimental :/ Are there any ETA to see it in the Testing repo? Only the SDL port has the libpng embedded, the Qt only uses it to compile the fonts (*.zim files), so I can disable for now the SDL. They are false positive I guess. The files are there, I don't know why it complains. Will see that. Thanks for the feedback.
Then ppsspp should rather go into experimental than unstable. libpng16 will be in testing once the libpng16 transition in unstable has been finished or has reached an acceptable state without breaking everything. However, since this transition hasn't even been announced yet, I can't really say when this is going to happen. You should ask the release team or the libpng maintainer(s) for a date. Or just use experimental. I wouldn't really rush it. If you are pushing it now, you are risking additional work and problems with the package. Once the transition starts, we will just upload the package to unstable which will be accepted instantly since it has already been accepted into experimental by then. Then you should add lintian overrides for these. But you should check the copyright file in case it's not 100% compliant to the Debian copyright file format which might have triggered the lintian warning. Adrian
Hi John and Sérgio, thanks for your precious work on this package! However, I would like to ask you considering switching the discussion in bug #801262, and set yourself as owner of that bug, this way we can avoid double work on the same packages. If you don't intend sponsor the package let me know :) cheers, Gianfranco On Fri, 9 Oct 2015 07:01:29 +0200 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
Adrian, not John. Why should we switch over to the RFS bug report? What would that change and why would there be any double work? I have been in contact with Benjamin for a while now and we are just discussing the issues in public so that others can follow the progress. I don't really expect anyone else to get involved with the package. Don't worry, I will take care of the sponsoring. I do regular sponsoring as you can see from the sponsor stats. Thanks, Adrian
Hi Adrian! (my deep apologies for this mistake) well, it is a common practice to set yourself as RFS bug owner, to avoid people double looking at the same package. I saw the RFS bug, and not the ITP one, and I was going to review it. When I review a package sometimes I start by looking at the ITP, sometimes else I start by looking at the copyright, or the packaging and then the ITP. I could have started looking at it by mistake e.g. because I didn't follow the "look at the ITP first" procedure. thanks a lot for the effort :) so, can I please set yourself as owner of the RFS bug? this way I won't bother you anymore :) (I didn't find any good way to "look at RFS bugs only where nobody is looking at them", if not by setting yourself as owner, as described in [1]) [1] http://mentors.debian.net/sponsor/rfs-howto "If you intend to take care of the sponsoring request until the package is ready for upload, please consider setting yourself as the owner of the bug and tag the bug pending: $ bts owner nnn me@example.com $ bts tag nnn +pending " cheers, and sorry again for the noise! happy hacking! Gianfranco
Well, I can do that. But I am not a big fan of RFS bug reports anyway. I find them redundant to the ITP bug reports. All the discussion that regarding the package review and sponsoring should just be in one bug report instead of two to avoid cluttering. I don't really understand why Sergio filed it anyway. I told him I would take care of the sponsoring for him, so there is no need to make a public request for sponsoring. Adrian
Hi, Sorry, at the time I thought it was somewhat obliged to make a RFS bug :p I'm very noob at these things and I'm trying to understand all these bureaucratic stuff [yet]... Sergio Benjamim
So, I just had a look at the latest package version you put up on mentors and I can't even install the build dependencies: (experimental-amd64-sbuild)root@z6:/# apt-get install libpng16-dev libfreetype6-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libfreetype6-dev : Depends: libpng-dev E: Unable to correct problems, you have held broken packages. (experimental-amd64-sbuild)root@z6:/# How did you manage to build the package on your machine? And is there no way to use an older version of libpng? I don't understand why the PPSSPP developers thought it would be a good idea to build against libpng16 when libpng12 is still the default version. Adrian
Hi, for ages. I fixed it in the dirty way: I installed manually the headers and pkgconfig of 1.6 in the system :) There's no way to use 1.2, upstream is using new features of 1.6, I tried once. --- Sergio Benjamim
I don't even see libpng16-dev in Ubuntu, even in wily, the current development release. libpng is a core library, you can't just brutally upgrade that to a new upstream version without risking breaking anything. You'll risk breaking tons of packages. Something as important as libpng needs a proper transition. Then we're out of luck. There is no way you can upload the package that way to Debian, sorry. Then we'll have to wait until the libpng16 transition has happened. Adrian
Hi, bug #650601 is still sleeping :) well, there is at least two more solutions: 1) target the upload to experimental, where the libpng16 is available 2) embed libpng16 inside the source (well, it is not a suggestion, just a matter of facts) this will still be needed for an unstable upload, while experimental should be good. cheers, G.
No, that's not possible because ppsspp build-depends on libfreetype6-dev which conflicts with libpng16-dev. Try installing libfreetype6-dev and libpng16-dev simultaneously. Haha, that's a good one. You haven't been around here long enough, no? No, it isn't. Could you please stop giving me hints which assume I'm an idiot? I have been doing packaging for a while now. Thanks, Adrian
Hi, well, I am, but I was giving a fact, not saying I would sponsor such hack, just mentioning that $somebody else is already doing that on debian. (if you look to my -mentors sponsoring activities you can see I don't even like shipping a static library, so I really care about security). Look e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650601#354 personally I would like to see the transition start, but with the libstdc++5 ongoing one I don't think -release will ever give an ack for it (modulo somebody working on it) I was trying to give my help, not to make you feel an idiot. sorry if I didn't make my intentions clear. Of course the package is now in a no-go state :( cheers, G.
Embedding a library is an absolute no-go in Debian, particularly with core stuff like libpng. The security team is going to kill you when they find out. The fact that someone managed to sneak their packages with an embedded library into the archive doesn't make it any better. You should talk to the FTP team with a beer over this. They'll tell you how much they have to reject just because people's packaging is sometimes really horrible despite the fact that DDs should know better! We already have several huge transitions going on. I am maintainer and co-maintainer for m68k, sh4, sparc, sparc64 and x32 and I am happy about any transition which is currently not going on yet as transitions cost a lot of pain for us. Yes, that's my whole point. We can upload it like that. As simple as that. A random emulator is not important enough that I start a fight with the security or release team. Adrian
libfreetype6 compiled fine against libpng16, I just had to change control and rules.
But you cannot install libfreetype6-dev and libpng16-dev in parallel as libfreetype6-dev depends on libpng-dev which is provided by libpng12-dev which conflicts with libpng12-dev. Howd did you solve that without manipulating the aforementioned packages or install the build dependencies using --force-depends? Adrian
Looks like the libpng1.6 is about to start, the bug report in question was just updated [1]. Sergio, can you provide an updated ppsspp package? Adrian
well, libpng16 is nowhere near to start, if by start you mean being uploaded to unstable and starting the actual transition.
Well, I've been receiving multiple bug reports through various lists in the past days from the libpng maintainers which asked people to fix their B-D regarding libpng-dev to prepare for libpng1.6 and setting these bugs as blockers for the transition bug. And since Stretch is to be frozen on December, 5th, I'm pretty sure transition is going to start in the near future unless you have any more definitive insider information I don't have. Adrian
note that most (all?) of those bugs are not filed by the maintainer, but by another developer that seems to care more than him (or just have more time to take care of this). furthermore, there are more than one hundred bugs filed to date, and ISTR not all are filed yet. Most of those bugs involves code changes (e.g. FTBFS with libpng1.6), not just swapping build-deps. Those kind stuff takes several weeks, if not months. Anyway, NMUs already started, hopefully we will be able to outline the blockers soon enough. everybody hopes so, me too. we deleyed this for so many years :(
Hi, Since libpng16 is still in experimental, maybe it should be better just comment out the ppsspp-sdl in control and rules, and build just Qt, which uses this version of libpng only in the build time for the atlas and zimtool (and they build the atlas fonts). I think it's better than waiting forever for this update. PPSSPP is almost releasing its version 1.2.0... Sergio Benjamim
Hi, FYI I uploaded yesterday a libpng-dev pointing to libpng16-16 package. In the next few days everything uploaded in experimental will start building against this, and I hope to have a transition inplace in the next few days/weeks. So, ppsspp might have some better chances now to go in Debian. Adrian, do you think you can ask some experimental binNMUs against the new libpng to make stuff installable? that way you will be able to test the package if I remember correctly the situation we have left some months ago. thanks and sorry for the delay, G.
Hi Gianfranco! Sounds great, thanks for all your efforts in the libpng transition! Sure, I'm happy to help. Sergio, do you have a recent version of your package? Btw, I'd also like to help you with Retroarch which you have uploaded to mentors. A friend of mine is interested in having Retroarch in Debian and he asked me to step in. Well, I'm not member on the official buildd team (yet), I'm just controlling ports, so you'd have to ask them for such binNMUs. Yeah, I agree. We should definitely ask for binNMUs. No worries, some things take time! Adrian
Hi, I did very little, most effort was by Tobias :) wonderful! as a starting point, can you please consider having a look to my first review steps? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811214 don't hesitate to set yourself as owner :p ok well, I don't remember exactly what was uninstallable, but I tried an apt-get install libfreetype6 libpng-dev and it worked. it dragged the old libpng12-dev and the new libpng-dev, so in some way both libpng have been successfully installed. So, it might even work without binNMUs if we are enough lucky :) I hope to see it fixed in less than one month, we are still fighting with multiarch stuff [1] (an hint is appreciated!) [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650601#908 I think a non-multiarch libpng would be a mess in Debian thanks! Gianfranco
new ppsspp mentors package need sponsored the package are in very good shape, uses new libpng from system and some fix/hacks in the fonts issues a missing debian root menu (for those desktops that only are window managers) the patches do the best for some system used fixeds, but i doub around the assets, due seems are a string of paths, and removal in code include the ":" that the patches does not take in consideration in last i cannot tested with roms, due not complete compiled in my environment,, i thinkg i must setup a real sid debian environment due i can compiled in chroot but i need to run with roms to see if package works Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Yes, I'm aware of that. I was busy fixing the fallout of the libpng1.6 transition and there is lots of packages that we need to fix. So, please be aware that we have priorities in Debian. Well, I'll look at the package myself first, then decide whether that's actually the case or not. That's not missing. Debian decided a while ago that we're getting rid of the menu infrastructure. I have no idea what you are trying to say. Well, I'm not quite sure why you care about that. The package has to be reviewed by a Debian Developer anyway. So, you don't have to do that. Adrian
(disclaimer to Adrian, I don't want to steal that package to you :) ) Hi Serio, Adrian, FYI, we are currently tracking problems here, feel free to contribute or check here if we already have fixes (or schedule give-backs) https://titanpad.com/SjTUuZTd01 I'm stepping in just because I would like to see if the package builds, to spot libpng1.6 issues. Just some stuff I saw in my quick trip. fonts-droid is a virtual package, either choose fonts-droid-fallback or whatever else lintian overrides are wrong: paragraph at line 101 (override comment: lintian false positives) this is because the copyright has to list from the generic to the specific files so, swapping e.g. Files: Common/Crypto/* Files: Common/Crypto/sha256.* Files: Common/* to Files: Common/* Files: Common/Crypto/* Files: Common/Crypto/sha256.* should fix the issue. Hope this helps, another "nitpick"/issue +find_path(PNG_PNG_INCLUDE_DIR NAMES "libpng16/png.h") please please please use libpng/png.h instead, I don't want another ton of NMUs for the next png transition (also all the includes are wrong #include<libpng/png.h> is completely legit and ok) I leave the other stuff to your sponsor, I tried to keep the review png-related only thanks to you both, Gianfranco
Thanks G. ! Package updated. sergio-br2
Hi Sergio! I'll have a look at ppsspp this weekend. On a sidenote, I think you should reduce the number of packages that you are working on a bit [1]. Having so many packages when you're still new to packaging isn't really the best way of learning the proper techniques. I would advise focusing on a smaller number of packages first and getting these into proper shape so that they get accepted into Debian. Once you have gained enough experience, you can start maintaining more. Adrian
Hi Dear, I just want to know if you, can help me, to transfer the amount of ($6Million). After the transfer we have to share it, 50% for me, and 50% for you. Please let me know if you can help me for more information regarding the transfer. I hope you can work with me honestly? Mr.Saliu Ali,
Hello we are inviting your estimated company for vendor registration and intending partners for Emirates National Oil Company 2023/2024 projects. This projects are open for all companies around the world, if you have intention to participate in the process, please confirm your interest by contacting us through our official email address project-ae@enocvendor-ea.com
Hi all, I had some time to waste today so I took a stab at it. Main issue is ppsspp is shipping *a lot* of embedded libraries. Excluding all those and using the debian ones results in missing two libraries: udis86 [1] and cityhash [2]. udis86 seems pretty dead upstream so I don't know how viable packaging it is [3]. cityhash is just a small hashing library that could more easily distributed if upstream would publish a release [4]. I'd appreciate some advice on how to go from there. My main concern is udis86 because I don't really want to ship a dead upstream just for the sake of packaging ppsspp (without embedded libs). My WIP so far can be found here [5]. regards,--- Matthias Geiger (werdahias) [1] https://github.com/vmt/udis86[2] https://github.com/google/cityhash[3] https://github.com/vmt/udis86/issues/52[4] https://github.com/google/cityhash/issues/39[5] https://salsa.debian.org/werdahias/ppsspp-wip
Hi all, upon doing some quick packaging for cityhash and udis86 I discovered there is *a lot* more missing. 1) gason: just 2 cpp headers, did some quick packaging https://github.com/vivkin/gason 2) SFMT: https://github.com/MersenneTwister-Lab/SFMT 3) two headers taken from https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator 4) xxHash: https://github.com/Cyan4973/xxHash looks doable 5) xBRZ: https://github.com/janisozaur/xbrz looks doable 6) https://github.com/richgel999/jpeg-compressor looks doable 7) https://github.com/MersenneTwister-Lab/SFMT looks doable 8) kirk-engine/libkirk: I think this is https://github.com/ProximaV/kirk-engine-full but it mentions it's also an update, not sure where the original source comes from https://github.com/hrydgard/ppsspp/blob/master/ext/disarm.cpp is apparently also needed, but the website mentioned is a dead link and I couldn't find a source for it. 4-7 look doable, the rest looks like it will be more work imho. Maybe I can make some time at mini debconf hamburg for 4- 7 , but I won't promise anything. Feel free to reply here if you find something I missed/have any clues where the missing sources are. I also don't know if ppssspp will compile if all libraries are provided as debian packages instead of embedded copies. While I strongly tend to the former as packaging practice, it might not be possible to fully devendor ppsspp. As of now I already had to extensively patch cmakelists to force it to look for the debian libraries. regards,--- Matthias Geiger (werdahias)
4) is already packaged so that's one less concern. bye,--- Matthias Geiger (werdahias)
ffmpeg could also be an issue since upstream embeds an ancient version and won't switch to a newer one [1]. Maybe we can steal this patch [2] utilizing ffmpeg 5. Another issue is ppsspp directly referencing absolute header paths, which will require extensive patching. grepping the source code lists the following external headers referenced (i.e patching/packaging needed): - jpge.h and jpgd.h -> 6) - zip.h -> in debian, libzip-dev - vk_mem_allocator ->3), in new - vulkan.h -> in debian, libvulkan-dev - miniwget.h, miniupnpc.h, upnpcommands.h -> in debian, libminiupnpc-dev - basisu_transcoder.h and basisu_file_headers.h -> needs packaging from scratch, [3] - xxhash.h -> in debian, libxxhash-dev - xbrz.h -> contained in the source of https://tracker.debian.org/pkg/xbrzscale , needs to split into an extra package maybe ? - ShaderLang.h -> in debian, glslang-dev - gason, udis86 and cityhash -> 1) needs some cleanup - libkirk I think we might get away by providing all the headers and hope it compiles then :/ [1] https://github.com/hrydgard/ppsspp/issues/15308 [2] https://build.opensuse.org/package/view_file/home:X0F:branches:Emulators/ppsspp/ppsspp-support_ffmpeg5.patch?expand=1 [3] https://github.com/BinomialLLC/basis_universal regards,--- Matthias Geiger (werdahias)