PPA: discussion and progress tracker

[beaumanvienna]

Status so far:

Updated keys at launchpad (https://launchpad.net/~beauman)

First draft version to build mednafen based on debuild, as alternative to our current build script:

https://github.com/beaumanvienna/RetroRig/commit/5f6683d2f00bc1ae41b27efb0d0c25175c6e4964

It's currently just building the existing mednafen version 0.9.33 from Ubuntu/Utopic and will be a starting point to merge changes into this package.

[mdeguzis]

I guess I should have looked inside the existing Mednafen deb package for hints. Good work! I got stuck when I looked at XBMC, and it didn't fit the Ubuntu guide of "./configure, make, make install" in what they had. I know how to build XBMC of course, so the extra steps to set the prefix, bootstrap, and so on that you may want to do, I wasn't sure how to put them into the package. Thank you for keeping your steps to make the PPA files in that script. I really appreciate it.

[beaumanvienna]

The prefix goes into debian/rules, see this nice tutorial: https://wiki.debian.org/IntroDebianPackaging

Alright Professor. I have to confess, I'm also not 100% sure how all this works. I have now made an alternative script that generates basically the same debian package we had before as well. The only difference is that it's now using debuild. Something tells me that this is a good thing, but I currently don't know why :-D

What's actually the final goal? To have those three files (mednafen_0.9.36.2-R1.dsc, mednafen_0.9.36.2.orig.tar.bz2 and mednafen_0.9.36.2-R1.debian.tar.xz) available for upload and have debuild generate a package out of them?

An other thing that puzzles me is bazaar. Actually, I currently believe, that Github as source repository could equally be used. It can be defined in the dsc-file by a Vcs-Browser: tag. But how to set the branch then??

[mdeguzis]

It's completely fine to learn by example and expand on it. How else do you think I started this whole thing? I then build on my knowledge by seeking out answers and tinkering with code. Remember, I am not a "programmer" by nature or desire (most programmers do that trade primarily and it is their focus and expertise). I merely like interesting problems, Linux/Unix, and can be very resourceful I suppose.

Well....if Mednafen and XBMC are put into a PPA withing reasonable time that you see fit, then great! If you want to refne and understand the packages, PPA process, and code more for a 1.0 release, then I'm fine with that too. We have working packages without a PPA, so it's not as if we are hurting to have these put int, but of course its a very nice thing to have, and I wholeheartedly appreciate you keeping track of your build steps in files so I and future maintainers/colloboraters can view them.

That last "bizzare" paragraph about "Bizaar" (pun intended!) is noted. I know you specify the beta bracnch by using the root URL:

https://github.com/ProfessorKaos64/RetroRig/tree/beta

Files will follow this convention:

https://github.com/ProfessorKaos64/RetroRig/blob/beta

Maybe that will help. Great work JC.

[beaumanvienna]

Thanks for the URLs, maybe that's a way how to just download the files I need, instead of downloading the complete project history.

The bootstrap command we need for xbmc also goes into debian/rules. It looks like this http://slexy.org/view/s2VB4FCxYd

So the debian/rules file is a meta makefile, that controls the overall build. I will probably have to use it too, to run automake -fi for mednafen, which updates the makefiles inside the code tree for the SDL2 library.

My next step will be to generate our mednafen version with debuild.

[beaumanvienna]

I have uploaded mednafen to the PPA now, but the software get's rejected.

This is the mail I got from

Rejected:
File mednafen_0.9.36.2.orig.tar.bz2 already exists in Primary Archive for Ubuntu, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
Files specified in DSC are broken or missing, skipping package unpack verification.

The options we have now are:

a) use the actual mednafen_0.9.36.2.orig.tar.bz2 file on launchpad and supply a patch for it. I've already downloaded it with pull-lp-source mednafen. The current version is 0.9.36.2-2, this means mednafen_0.9.36.2.orig.tar.bz2 plus patches. b) switch our version to 100.9.36.2 c) rename our mednafen package (not necessarily the binary) to mednafen-retrorig

Any opinions on this?

[mdeguzis]

Can't you just rename the tarball to another name? Add retrorig to it. Pull down the tarball from source, and rename it after downloaded. That .orig noted in the file is what the debian packaging system makes the old tarball before it packs you a new one. That is as much as I understand it so far. I think the idea of suggesting a patch isn't bad at all, but give the above a try. I'm not sure about updating the version, unless you have tested that already?

Thank you JC -pk-

[beaumanvienna]

Hey, thanks for the tip!

I added an other .1 to the version. This would be our patch level.

With compliments from my PPA:

Accepted:
OK: mednafen_0.9.36.2.1.orig.tar.bz2
OK: mednafen_0.9.36.2.1.debian.tar.gz
OK: mednafen_0.9.36.2.1.dsc
-> Component: main Section: games

mednafen (0.9.36.2.1) trusty; urgency=medium

* patched for SDL2 and added dual-head support

https://launchpad.net/~beauman/+archive/ubuntu/retrorig/+packages

[mdeguzis]

Ok i'll note this patch level structure on the Mednafen wiki page. Probably after we hit 1.0, I will likely start a Debian branch, and start to build branches for other distros, only has time allows or more can help. Sure, not 100% will transition, but it should be possible to do all this in another distro.

[beaumanvienna]

Check it out, it was successful! :-DDD

Yes, other distros would be nice, like Deepin for my co-workers ;-)

[mdeguzis]

I will check this out tomorrow, as when I leave work today I must leave right away to go to a concert. No development work for me tonight :(

Yes, we will evaluate all sorts of things after we hit a milestone 1.0. After this release (0.9.5), one of my biggest goals is to fix up the gp_autodetect_xbmc.sh.testing helper script to work with all gamepads. If time allows, I will still look at this while we beta test this release.

[beaumanvienna]

What I about xbmc? Do you still like to package it? Or should I take care of this while I'm at it?

Oh, and speaking of xbmc, I haven't changed the splash screen issue yet. I'll get to this tomorrow.

[mdeguzis]

Take care of xbmc while you're at it. I would very much like to learn from your and your experiences (past how far I got before) so I can benefit and improve on how to do this myself. When time allows of course, and after the more busy work is out of the way. The splash screen works well, just had a few times it would show up black, but after a few times it got more consistant I think. If there is a way to scale the image / stretch automatically, that would be nice. But no biggie if not. I see then why XBMC devs chose a black background haha.

[beaumanvienna]

Alright! Next thing for me will be to move xbmc to the PPA. I'll release the splash screen changes as patch level six and just how they are right now. You have probably noticed that the changes are totally straight forward, it's just a different file the gets loaded for RetroRig. I'm not sure what that issue is you have, but maybe you had that all the time and it only got revealed by the new sleep delay.

I checked the PPA installation, it's looks totally normal, all functions OK. I'll issue my next pull request when I'm done with xbmc PL6, but if you like to test the PPA based mednafen version right now, you can use sudo add-apt-repository -y ppa:beauman/retrorig.

[mdeguzis]

As long as you keep the build script up to date, this will work fine. I still want to keep a copy of the packages on LibreGeek.org for good measure. I can make them myself when you date the script if need be. I love PPAs but at the same time, I must account for a backup plan. Kind of like someone building you a hosie bit having the schematics if you want to build another. Hopefully you get what I mean. Haha

[beaumanvienna]

I've committed the PPA build script and supplemental files for xbmc to here: https://github.com/beaumanvienna/RetroRig/commit/1f4fd04c841b89eb83d86fd5a17a638d58f8d946

It should compile now after I changed the format from quilt to native. My VM hang up during compile when it was starting to use swap memory. The rules file (https://github.com/beaumanvienna/RetroRig/blob/beta/supplimental/xbmc/rules) is just the absolute minimum right now, I noticed that it was not fetching the ffmepg stuff during configure, so I should merge some of the original contents back in.

[EDIT] Upps, this is still debug code: https://github.com/beaumanvienna/RetroRig/blob/beta/supplimental/build-xbmc-ppa.sh#L67 https://github.com/beaumanvienna/RetroRig/blob/beta/supplimental/build-xbmc-ppa.sh#L86

[beaumanvienna]

Good news!

xbmc now also compiles on launchpad!

After a little longer fight (https://launchpad.net/~beauman/+archive/ubuntu/retrorig/+builds?build_text=&build_state=all) it's finally working.

The missing item was the repositories dependency on wsnipex/xbmc-fernetmenta-master, see https://launchpad.net/~beauman/+archive/ubuntu/retrorig and open "Technical details about this PPA".

The successfully build xbmc package still has the wrong version number. It should be 13.1.6, but for this I still have to look into xbmc about its fullscreening behavior.

I can now prepare my next pull request, to change the download server for mednafen and xbmc from libregeek.org to the PPA. Do you want to keep the libregeek.org downloads in some kind in the source code? Maybe commented-out or activated by a special argument to retrorig_setup.sh? Or should I just delete it?

The build script is now split up into two targets: source and compile: https://github.com/beaumanvienna/RetroRig/blob/beta/supplimental/build-xbmc-ppa.sh

[mdeguzis]

Good work. Did you hear about the next "XBMC" being called "Kodi"? Guess they had name troubles with other devs or something. For some reason at work, on IE8, I cannot open the build log, but i trust your judgement. I would request the static downloads the PPA packages replace just be commented out with a small note that this is now handled by a PPA. Just a short one line sentence. At some point, I will remove them. I have a love/hate relationship with PPA's, I like them for what they can provide with ease, but I distrust them at times. The fact you are willing to keep the build scripts for them, makes me feel a lot better, I really appreaciate that.

The build-xbmc.sh script is very good. Your attention to detail and workflow is defintely appreciated. I wonder if I built the package, would my GPG key even allow me to upload, or do you have to approve my key?

Thank you JC!

[beaumanvienna]

Yes, I heard about the name change. Good for us! If they rename everything to kodi (/usr/lib/kodi, /usr/share/kodi, etc) we can even have both version installed in parallel.

I understand your bias against PPAs. It's less tested software, it get's less attention and has a less official character. Compared to libregeek.org it additionally provides the source code though. That is actually an improvement.

I forgot to copy the splash screen for native xbmc.

Good question about your gpg key! I was going to ask you if we should share a PPA. This is possible, see https://launchpad.net/~team-xbmc. Anything you want to upload right now?

[mdeguzis]

Yes, I heard about the name change. Good for us! If they rename everything to kodi (/usr/lib/kodi, /usr/share/kodi, etc) we can even have both version installed in parallel.

I can't believe that didn't occur to me. Nice!!!! If that works out, that will be a positive change for us. Yes, I do want to do PPA's, at least for Ubuntu. When we maybe move to other distros, maybe it will be easier ot package hahaha. As long as the build script used to make the PPA is kept in supplemental/ or else where, that is ok by me.

Nothing I want to upload right now. My GPG key should show up here:
https://launchpad.net/~mdeguzis

The SSH key would need changed or a new one, since that was my test VM. But the PGP key is there. This can wait, I am in no hurry to shank up this process when it's in its early stages. There will be time to learn more about PPA's on my side.

[beaumanvienna]

I just moved my keys from my China-VM to my desktop rig. That works. Just tar .gpg in your home folder.

I could prepare a packaging script for stella. I understood that the latest SVN version works best for you. If you like to, you can then upload it! I mean just to get you a little closer to the PPA business...

[mdeguzis]

I'd rather not keep two PPA's for the project. Do you think we should just have one as well? Would that entail uploading to the same PPA you have? I can look at the build script for the XBMC PPA build, and try that with Stella, once looked over for small changes if need be. I'll give it a try. Stella follows the classic './configure, make, make install' so it is easier. I know you started from an existing Deb pacakge, but I'm hoping to have this process figured out personally from scratch. I just need to stop messing with other bugs and stuff haha. I found a few issues last night and corrected them, among other things like replacing references to /home/test/RetroRig and such in emulator config files to "installdir_temp"

On Wed, Aug 6, 2014 at 8:15 AM, Jens-Christian notifications@github.com wrote:

I just moved my keys from my China-VM to my desktop rig. That works. Just tar .gpg in your home folder.

I could prepare a packaging script for stella. I understood that the latest SVN version works best for you. If you like to, you can then upload it! I mean just to get you a little closer to the PPA business...

— Reply to this email directly or view it on GitHub https://github.com/ProfessorKaos64/RetroRig/issues/74#issuecomment-51326428 .

Michael DeGuzis Email: mdeguzis@gmail.com Website: http://www.libregeek.org Linked In Resume/Profile http://www.linkedin.com/profile/view?id=124915388&trk=nav_responsive_tab_profile

[beaumanvienna]

OK, shall we then share my PPA? This should be possible, we just have to find out how this works.

You don't want to start the packaging stuff from scratch. It's not so much about the build script, which basically just copies files from RetroRig to the packaging folder. It's more about what these files contain.

I personally prefer to start from a working situation and then with baby steps for the changes.

The documentation on the packaging process is quite poor. There's a lot of stuff out there how the Ubuntu guys want us to do development. This is all based on bazaar and has nothing to do with our source control system. One page I do recommend is here: https://wiki.debian.org/IntroDebianPackaging

You start with two files: stella.dsc and stella.debian.tar.gz. This will save you a lot of time. See http://packages.ubuntu.com/utopic/stella

In build-stella-ppa.sh you need to checkout the source code from subversion as folder 'stella', strip out any version control information like .svn, and compress it to stella[YOURVERSION].orig.tar.gz. Rename stella.dsc to stella[YOURVERSION].dsc. Unpack stella.debian.tar.gz and move debian/ to stella/.

You need to update debian/changelog with the right version number and some comments for your changes. debian/rules should be straight forward if it's just configure/make/make install. Delete any patches and the series file, which controls patches to be applied. In debian/control you just adjust the maintainer and home page. If debuild complains about missing upstream software, you change the format from quilt to native in debian/format. That's it!

Don't stop fixing bugs and messing around with other things! That's great work you do there :-D

[beaumanvienna]

All packages are online -- this issue can be closed