Closed mdeguzis closed 10 years ago
Good to hear this :-)
OK, I'll sync my fork with your upstream code and try again from scratch.
I have started to work on packaging now. I found apt-get source xbmc-bin
is a nice way to get a template project.
I have started to work on packaging now. I found apt-get source xbmc-bin is a nice way to get a template project.
Nice..I didn't think of that. I will be really interested to learn from your packaging where I got stumped. Thank you JC
I wonder JC, do think in the future we should look at RetroArch / Libretro? http://emulation-general.wikia.com/wiki/Using_RetroArch
Professor, how shall we proceed with Stella? Noticed you are downloading it from libregeek.org currently. Should I put it to the PPA? Or do you want to keep it on libregeek?
And I would like to ask if you could put keymaps/keyboard.xml (or a shrinked version) to ~/.xbmc for native xbmc controller support. And enable joysticks in the GUI settings?
So maybe I the packaging and you the controls?? :-D
Professor, how shall we proceed with Stella? Noticed you are downloading it from libregeek.org currently. Should I put it to the PPA? Or do you want to keep it on libregeek?
If you want to put that into the PPA, you sure can. I wasn't sure if you could just upload it, or if it must be made from "scratch." After this beta is out, I want to spend some time practicing with your build scripts myself for any future PPA work. Thank you JC
And I would like to ask if you could put keymaps/keyboard.xml (or a shrinked version) to ~/.xbmc for native xbmc controller support. And enable joysticks in the GUI settings?
I will take care of this tonight as well. Just a more sed replacements in the gamepad module, after copying the "default" RetroRig keymap template to .xbmc
So maybe I the packaging and you the controls?? :-D
Sounds like a deal!
Oh I forgot to say. I am going to start trying to do my best reporting your pull request changes to the changelog.md file in this branch, and this would be the same in any other future branch. If you make code changes, simple one-line explanations of what changed, or more if you want in the changelog would be helpful everyone involved that normally would not unpack a debian package. I will do my best.
Oh I forgot to say. I am going to start trying to do my best reporting your pull request changes to the changelog.md file in this branch, and this would be the same in any other future branch. If you make code changes, simple one-line explanations of what changed, or more if you want in the changelog would be helpful everyone involved that normally would not unpack a debian package. I will do my best.
Alright! Will do.
Sounds like a deal!
I'm on it!
Found a solution: antimicro
It hit's Esc, then pauses, then does CTRL+C to end the process that gets left behind in the terminal works well. I might switch from qjoypad to this program in time. Maybe tomorrow I can test it out on PCSX2 after I make the changes for the pull request tonight.
Hello!
I did some testing from scratch today. Looks pretty nice! :-)
All backend programs from our PPA get installed correctly.
Noticed you started to work on the PS2 emulator. That's awesome! If you need any support with this, just let me know.
Some just tiny tiny remarks about this install:
apt-get install pcsx2
could use a -y
Six issues can be closed from my side, which is 40% of the overall issues we currently have:
Excellent! If you confirm those items I can close them.
So. What's next? When are you going to do the controls for native xbmc? After this, we should launch a bigger promotion initiative. I have bought two new PS3 controller, one for a college of mine. About this initiative I was thinking that we could create a dedicated issue named "RetroRig Beta Testing Program". Beta testes should go there and register and later leave feedback. We should post on the reddit, I expect that we get some feedback from there. We can also post at the forums of xbmc and mednafen, but I actually don't expect too much feedback from those. In the mednafen forum we should mention that we are using SDL2 and the dual-head extension, maybe this will raise some interest. For xbmc we should mention the competition to RetroArch and the improved control and dual-monitor support. What's your opinion on this?
Some just tiny tiny remarks about this install:
The config.xml one is fine and normal, since that string you found is replaced after install, and is the same deal as what I do with qjoypad. The different, as you see, is the abolute path to the profile. I can try otherwise, but I had trouble with antimicro using just antimicro --profile PROFILE
due to the antimicrosettings file containing the absolute path itself. I will try to look at this further, but this should not harm anything at all.
As for MESS, what problems is that causing, I do the same thing to the .MAME. Checkout the original here. All this is replaced on install. Post install, it reflects the proper directories. What issues are we getting as a result of this? This might be a good IRC discussion if we still have things to clear up on this subject.
By the way, that solution to make PCSX2 work was one crazy ordeal! Maybe in IRC we can chat about it if you want.
77 "wrong home directory in RCB config.xml / PS3 keys" can be closed from my side
74 "PPA: discussion and progress tracker" can be closed from my side. Do you have any question left concerning the Debian building business and our PPA?
72 "splash screen" can be closed from my side
68 "xbmc doesn't fullscreen after exit" can be closed from my side
48 "sound issues with mednafen and Nouveau" can be closed from my side
36 "miscellaneous stuff" can be closed from my side
All of these can be closed. I love* the splash screen! :D
So. What's next?
Yes, I will get the controls copied into the native keymaps folder, and mark the old keymap (if found) with a .old suffix. I agree about the Beta testing thread, good idea. Once I fix and agree on outstanding issues from this last post, we I will start posting on social channels. If you want to attack the forums, that will help. For XBMC, I think we should note the difference between us and RetroPlayer, since RetroArch is just a frontend, and actually in use be RetroPie, not their solution. They use the libretro backend.
Update
Actually I thought about the idea of adding our controller keymaps to
I worked this in the for the key maps. Some lines are included from before just to keep it in one paste:
# Copy our keymap to the regular .xbmc dotfile directory if it exists:
if [[ -f "$home/.xbmc/userdata/keymaps/keyboard.xml" ]]; then
#backup current file
cp -v "$home/.xbmc/userdata/keymaps/keyboard.xml" "$home/.xbmc/userdata/keymaps/keyboard.xml.old"
# copy in keymap
cp -v "$rootdir/gamepad-cfgs/ps3_blu_controller/keyboard.xml" "$home/.xbmc/userdata/keymaps/"
fi
# First grab MAC Addresses:
# In the config file, the MAC is set to 00:00:00:00:00:00
# set MAC values
PS3_MAC_OLD="00:00:00:00:00:00"
# Replace MAC Address for ***CONTROLLER 1 ONLY!*** This will be used to control XBMC
sed -i "s|$PS3_MAC_OLD|$PS3_MAC_BLU|g" "$xbmc_home/userdata/keymaps/keyboard.xml"
sed -i "s|$PS3_MAC_OLD|$PS3_MAC_BLU|g" "$home/.xbmc/userdata/keymaps/keyboard.xml"
sleep 2s
That should work, but needs tested after I commit soon.
Hi Professor! I had my test today, now I have three days off and can get some work done for RetroRig.
Shall we discuss priorities? I'm currently working on the auto resolution feature and on packaging dolphin. What else we got? Investigate the segmentation fault from Mupen's rice-plugin? Or that one caused by the ACE XBMC theme?
We have a whole lot more open items, anything from that with higher priority than those mentioned above?
Well, I probably should have kept up labeling the issue tickets as low-medium-high. I can do that when I get home. Off the top of my head here are some things:
Steam Launcher with Big Picture (kind of defeats the retro thing, but there are plenty of indie games). I can now easily add this to the settings menu, or place an addon link to the main screen. Problem is, steam always was their xpad userland module, not our controller layouts, so this may have to wait.
I will review all the open tickets tonight, comment if need be, and apply proper tags.
Ok, now that I have wasted time putting Sega CD/32X into the beta, time to get to this list so we can put a call out to folks to test :)
It's good that you still have this call to the beta testers in mind. Can we already today open an issue ticket where beta testers can register and report back?
When it comes to a bigger initiative for calling for beta testers, I have currently so many open items to process, we can wait a bit more with it. Applications I do consider ready for a larger audience are mednafen, mupen64plus and dolphin. Pcsx2, stella, mame and mess, gens, and ppsspp need some more polishing and internal testing. On the other hand, if we make this fact clear to the testers, we could launch a bigger call for beta testing right now.
Even if it's always fun to add new features, after adding gens and Wii support yesterday, we should also think about freezing the current feature set.
Issue ticket opened with text and logo: https://github.com/ProfessorKaos64/RetroRig/issues/109, im still making it, but you can view it now.
On Tue, Sep 2, 2014 at 12:52 AM, Jens-Christian notifications@github.com wrote:
It's good that you still have this call to the beta testers in mind. Can we already today open an issue ticket where beta testers can register and report back?
When it comes to a bigger initiative for calling for beta testers, I have currently so many open items to process, we can wait a bit more with it. Applications I do consider ready for a larger audience are mednafen, mupen64plus and dolphin. Pcsx2, stella, mame and mess, gens, and ppsspp need some more polishing and internal testing.
Even if it's always fun to add new features, after adding gens and Wii support yesterday, we should also think about freezing the current feature set.
— Reply to this email directly or view it on GitHub https://github.com/ProfessorKaos64/RetroRig/issues/73#issuecomment-54109366 .
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
I need to add the RCB xml and a few things to add the Wii support and note it on the wiki. I will try to do that tonight. The config is there for gamecube controllers and the emulator, just need to add the folder creations and RCB code.
I did some cleaning up in our issue tracking system.
@ProfessorKaos64 What about "Something is stalling the final gzip operation" (#38), do you want to keep it? "Joystick movement is disabled after load state - PCSX2" (#84) is also obsolete with the latest version of PCSX2. Please confirm and close this issue. "Either sixad or PPSSPP is reporting incorrect buttons" (#50) needs to be tested again by you, I couldn't reproduce it with the brand new version of ppsspp.
The rest of the issues should be actual problems we need fix.
{ }
, and this prevents me (for some reason) from allowing users to not* reboot after switching to an Xbox 360 controller. I think we would either have to change the logging out of the method I use, or just not use it in that sense.Example (not fixed, but again it is trivial for gameplay): Notice the Start entry reporting "pad1.right" Others are wrong, but that is an obvious error.
Other than that, hmm wondering what other serious things prevent us from pushing the beta into master Ubuntu branch. I think things are ready enough, but if you want me to confirm some things first, that is fine.
38 is only because the commands are encapsulated by curly braces { }
I had that issue as well, when I tried to disable the reboot message when the Kernel was not updated? I solved it by using a temporary file, rather then variables that expire out of the context of the curly brackets.
84 should be already closed if I didn't yet. I think we are ok for now on that one.
I tested that under Utopic yesterday one more time, it's OK. Let's close it.
Other than that, hmm wondering what other serious things prevent us from pushing the beta into master Ubuntu branch. I think things are ready enough, but if you want me to confirm some things first, that is fine.
I suggest we tackle that after your test next week. I have changed yesterday the link direction for the bios of PCSX2, the actual folder is now located in home/Retrorig/BIOS, similar to the other bios files. The bios folder in .retrorig/.config/pcsx2 is a link now. I've also started to test on Utopic, which is already a long story.
I had that issue as well, when I tried to disable the reboot message when the Kernel was not updated? I solved it by using a temporary file, rather then variables that expire out of the context of the curly brackets.
Nice, I'll take a look at that again
I've also started to test on Utopic, which is already a long story.
That's mainly why I chose the slow moving target of 14.04 LTS. Are you just doing some work to see how easy/hard it would be to support it? After this release, I'm much more interested in supporting Arch Linux / Fedora. But yea, that is a entire another animal hahaha.
That's mainly why I chose the slow moving target of 14.04 LTS. Are you just doing some work to see how easy/hard it would be to support it? After this release, I'm much more interested in supporting Arch Linux / Fedora. But yea, that is a entire another animal hahaha.
mednafen, GensGs, ppsspp and PCSX2 are working under Utopic. Mupen complained about one missing dynamic link library (*.so) called libocode.so.something. I found a lib called libocode.20140918.so.something, created a symlink and it worked. For dolphin I did the same for the first three libs it was complaining about, then I gave up. Tried to compile it, didn't work either.
This was at first an intimidating result, after Utopic is just a very tiny step from Trusty. But in the end of the day it's very enlightening. What we are experiencing here is very well applicable to moving to Arch or Fedora. If we proceed with our current solution, the work will be totally overwhelming, and most of all, never ending. I dare say that we would even need different versions for Manjaro and Arch.
The only solution I can think of right now is to link against static libraries (*.a). And in doing so reducing the dependencies to zero. The only backend that is currently doing this is ppsspp. We could then use the launchpad PPA for all systems, not only the Debian derivatives. As I understood you can install apt under Arch, the Debian package format will then be nothing other than an archive.
First thing I need to do now is to get dolphin-emu compiled under trusty, and against static libraries. I've cleaned up the PPA support of RetroRig already, the only last dependecy we had was to falk-t-j. I've copied qsixad over to our PPA, now the only PPA left is our RetroRig repository. I've added a source list that will always look into the trusty folder of the PPA, no matter what Debian variant:
https://github.com/beaumanvienna/RetroRig/blob/Ubuntu-14.04-Beta/scriptmodules/setup.shinc#L235
Long story short, reduce any external dependencies to zero.
How far do you think we are from updating the master branch? the setup debian package can wait until that is worked out, since it is a large change. I lost track of what we need to package :) Do we have a "shopping list" of things to fix yet? Once we iron what needs done yet, and what was done, I will update the Development and Features wiki page.
How far do you think we are from updating the master branch?
We've squashed a lot of bugs lately, I would say it's time to push that to master. Furthermore it's a good idea to establish a baseline. Sure a good thing before the changes for the setup packaging come in.
Do we have a "shopping list" of things to fix yet?
We got the issue tracker at github...
Once we iron what needs done yet, and what was done, I will update the Development and Features wiki page
Excellent!
We've squashed a lot of bugs lately, I would say it's time to push that to master. Furthermore it's a good idea to establish a baseline. Sure a good thing before the changes for the setup packaging come in.
Testing this on my rig right now, then I'll push 0.9.5. I will make a point later tonight to updated the Development and Features page. Take a look at it tomorrow and feel free to add anything you want to focus on for the next release bump.
@beaumanvienna merge is complete for beta into master. Please review the change log and code to amend anything you see wrong. Any questions, ask away! :)
Update
UGH... I forgot to update the splash image. I can get to this tomorrow. Once changed, I will need you to rebuild XBMC for your PPA of course. I saw in the code the comments about the ACE theme images missing. Is this still true? I can look at that tomorrow too if need be.
I have a very* crude change to the version tag on the splash screen. Maybe I'll make that better next week, or if you have a proposed change to the screen you want.
HI Professor! The ACE theme is basically works, I've linked its pictures to ~/RetroRig/Artwork/XBMC. I was thinking we could change this in its config.xml to directly pointing to $scriptdir/Artwork/XBMC.
The new splash screen is good! I'll take care of XBMC/patchlevel 11 this weekend. I'm going back to UTC+2 already tomorrow, it was just one meeting I had to attend :-D For XBMC I also need to change the directory of the script folder. I'm going to link it to ~/.retrorig/scripts, this way the user directory ~/RetroRig stays clean from internal stuff.
You I noticed you closed a lot of issues, very good! Before you pull the beta code into master there's one issue with service rescan
. We need to test in the installation script if the source exists, before copying it to /etc/init.d. I had a blank rescan file on Sunday when I installed RetroRig from the Debian package on my laptop. Speaking of my laptop, I made a little project presentation yesterday for my Chinese co-workers, the actually liked it :-D
Please review the change log and code to amend anything you see wrong
1307 files changed. Pretty hard to review this...
Great on the project presentation! For train control software? And crap...I pushed beta into master. So it can be fixed in beta and well push it to master. This is o my the Debian package right? Hopefully not many even try that yet. Sorry JC.
On October 21, 2014 8:15:28 AM EDT, Jens-Christian notifications@github.com wrote:
HI Professor! The ACE theme is basically works, I've linked its pictures to ~/RetroRig/Artwork/XBMC. I was thinking we could change this in its config.xml to directly pointing to $scriptdir/Artwork/XBMC.
The new splash screen is good! I'll take care of XBMC/patchlevel 11 this weekend. I'm going back to UTC+2 already tomorrow, it was just one meeting I had to attend :-D For XBMC I also need to change the directory of the script folder. I'm going to link it to ~/.retrorig/scripts, this way the user directory ~/RetroRig stays clean from internal stuff.
You I noticed you closed a lot of issues, very good! Before you pull the beta code into master there's one issue with service
rescan
. We need to test in the installation script if the source exists, before copying it to /etc/init.d. I had a blank rescan file on Sunday when I installed RetroRig from the Debian package on my laptop. Speaking of my laptop, I made a little project presentation yesterday for my Chinese co-workers, the actually liked it :-D
Reply to this email directly or view it on GitHub: https://github.com/ProfessorKaos64/RetroRig/issues/73#issuecomment-59918145
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Probably because I cleaned up and repushed the commits...I need to rethink how that's done with git-clean.sh
I messed this one up good O.o
On October 21, 2014 8:25:15 AM EDT, Jens-Christian notifications@github.com wrote:
Please review the change log and code to amend anything you see wrong
1307 files changed. Pretty hard to review this...
https://github.com/ProfessorKaos64/RetroRig/pull/132/files
Reply to this email directly or view it on GitHub: https://github.com/ProfessorKaos64/RetroRig/issues/73#issuecomment-59919201
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Great on the project presentation! For train control software?
For RetroRig of course! :-D Too bad the HDMI connectors of my hotel room are concealed, so it was just a laptop presentation. But they liked it anyway.
I'll do some testing with the master branch on the weekend. You're right, there's no official Debian based version out, so rescan can still be fixed, then we can release an official Debian install package.
We currently have two bugs, that I would like to see fixed pretty soon. One bug is that XBMC's version-checker complains about ACE. People might disable ACE when asked... The second bug is quite severe actually. I noticed this when pairing my PS3 controller to different machines. On the first attempt, the controller will be assigned slot number 2, and controls for XBMC won't work. A work-around is to choose the PS3/USB connection first. After that BT pairing will be fine. I hope to get this fixed in the next two or three weeks, we can push this to master one more time and issue an update.
Hmm I'll look at the pairing tonight. Was this with the debian package or both?
On October 21, 2014 9:18:05 AM EDT, Jens-Christian notifications@github.com wrote:
Great on the project presentation! For train control software?
For RetroRig of course! :-D Too bad the HDMI connectors of my hotel room are concealed, so it was just a laptop presentation. But they liked it anyway.
I'll do some testing with the master branch on the weekend. You're right, there's no official Debian based version out, so rescan can still be fixed, then we can release an official Debian install package.
We currently have two bugs, that I would like to see fixed pretty soon. One bug is that XBMC's version-checker complains about ACE. People might disable ACE when asked... The second bug is quite severe actually. I noticed this when pairing my PS3 controller to different machines. On the first attempt, the controller will be assigned slot number 2, and controls for XBMC won't work. A work-around is to choose the PS3/USB connection first. After that BT pairing will be fine. I hope to get this fixed in the next two or three weeks, we can push this to master one more time and issue an update.
Reply to this email directly or view it on GitHub: https://github.com/ProfessorKaos64/RetroRig/issues/73#issuecomment-59925401
Sent from my Android device with K-9 Mail. Please excuse my brevity.
I should be able to disable the version checker too.
On October 21, 2014 9:18:05 AM EDT, Jens-Christian notifications@github.com wrote:
Great on the project presentation! For train control software?
For RetroRig of course! :-D Too bad the HDMI connectors of my hotel room are concealed, so it was just a laptop presentation. But they liked it anyway.
I'll do some testing with the master branch on the weekend. You're right, there's no official Debian based version out, so rescan can still be fixed, then we can release an official Debian install package.
We currently have two bugs, that I would like to see fixed pretty soon. One bug is that XBMC's version-checker complains about ACE. People might disable ACE when asked... The second bug is quite severe actually. I noticed this when pairing my PS3 controller to different machines. On the first attempt, the controller will be assigned slot number 2, and controls for XBMC won't work. A work-around is to choose the PS3/USB connection first. After that BT pairing will be fine. I hope to get this fixed in the next two or three weeks, we can push this to master one more time and issue an update.
Reply to this email directly or view it on GitHub: https://github.com/ProfessorKaos64/RetroRig/issues/73#issuecomment-59925401
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hmm I'll look at the pairing tonight. Was this with the debian package or both? I should be able to disable the version checker too.
Professor, to be honest I noticed this bug the first time like two month ago, when I bought a second second PS3 controller. It wouldn't connect w/o first being configured for USB. The good news is, this can be easily reproduced when pairing to different machines. It would be great if you could start looking into this! For ACE we can either disable the version checker, or fix it. Maybe the latter way is the best.. I asked FernetMenta about this here.
And, speaking of presenting RetroRig, I hope you do a good job in Ohio! I wanna know what @ChrisLAS and his crew think about it, and hopefully you'll find a lot of beta testers for us :-D
Ok I'll hold on the version checker. I paired 2 controllers many times in the past, so not sure. I'll defintely pair them a few times over to make sure I have things right.
And, speaking of presenting RetroRig, I hope you do a good job in Ohio! I wanna know what @ChrisLAS and his crew think about it, and hopefully you'll find a lot of beta testers for us :-D
I am going to ready my laptop with Ubuntu tonight in case anyone wants to see it. I should have made a shirt with RetroRig on it hahaha, but I'll try to bring it up in conversation.
I just paired two controllers during the setup, confirmed LED's matched correctly, tested XBMC, rebooted, enabled both, and tested again. They both worked just fine. Are you following the prompts literally? On a side note, for now, let's fix these changes in master. When these are fixed and we are satisfied on 0.9.5, i'll merge that into beta for further work.
I had no issue. I did post in the XBMC forum for XBMC 14.0 Helix support on the Ace theme:
http://forum.xbmc.org/showthread.php?tid=205941&pid=1818914#pid1818914
If we need to disable addon notifications temporarily, it may be this chunk in the usedata/guisettings.xml file:
<general>
<addonautoupdate>false</addonautoupdate>
<addonforeignfilter default="true">false</addonforeignfilter>
<addonnotifications default="true">true</addonnotifications>
<settinglevel>1</settinglevel>
<systemtotaluptime>38</systemtotaluptime>
</general>
You need to try this with a controller that hasn't been paired to this adapter before.
You mentioned to setup your laptop for Ohio. Assuming you are using its in-build BT, try to pair your PS3 controller via BT before you try the USB option (The one you used before with your main rig). It won't work. Then use the USB option once, and try to pair with BT again. Then it should work.
I did post in the XBMC forum for XBMC 14.0 Helix support on the Ace theme:
I chimed in as well.
What kind of laptop do you have? Mine got a GTX 850M graphics card. PPSSPP games run awesome, like Ride Racer and TR Anniversary. Full 1080p. Some Wii games run too, like Rayman, but DKCR of course not. ACE Combat for PS2 is also too much.
Are you going to take gamepads to Ohio? Too bad we don't have a booth over there... haha
I have a 2013 Zareason strata, nothing special. It just has Intel HD graphics, but most games work ok.
I just did a 2 controller pair with my laptop. Fresh 14.04 install, internal Bluetooth, and everything worked fine. Now I did fix a synatx error or two tonight, so give it another go.
I did notice that the unity bar is on top on the left after exiting emulators :/
I did notice that the unity bar is on top on the left after exiting emulators :/
Roger that. I'll fix this for PL11. It just needs a XRaiseWindow somewhere.
Did you notice the response in the XBMC forum for ACE? It's genuine, ACE does actually come from Brazil, I think so at least.
I noticed you had an issue with the pre-checks? I actually did mess with the import function. I added line 45-49. The old code only worked for argument scriptmodules/scriptxxx
but not for /usr/lib/RetroRig/scriptmodules/scriptxxx
.
Naw it wasn't your fault. I had a syntax error preventing setup.shinc from loading properly. Oys nice we got a response on Ace. Well have to be more careful upgrading XBMC going forward, but Ace seems to work for our purposes under Helix. Ateast it seems that way thus far :)
Puhh, I thought I had messed it up :-D Anyway, if you find the time, you could maybe check, why the old code didn't work with absolute paths.
When it comes to ACE, I'll try to figure out a way to solve this. Probably this weekend. I actually tried already to change the config.xml of ACE from XBMC.gui v 5.0.0
to XBMC.gui 5.0.1
, but that didn't solve it. I'd like to debug a little into the version checker code, to see what it's actually complaining about. I have to admit that I was aware of that flaw before I issued the PR, I've been testing Helix in my private PPA before.
In general, the best strategy to test changed backends would be to work with an "official" RetroRig PPA, owned by a development group "RetroRig". In our master branch, only this repository would be visible. For the beta branch your and my RetroRig archives would be enabled too. This way we can squash these kinds of bugs first before it hits mainstream. There's a copy option for packages on the launchad pages, to copy an already built package from one repository to an other is just a couple of clicks.
One more thing about Ohio. If you find somebody Arch savvy, you could maybe discuss our concept of supporting it. So far I understood that they have no PPAs. Everything goes into the AUR. Currently we only use pcsx2
and hopefully soon ppsspp
as unmodified versions. Reasons why we had to patch the other backends are mainly multi monitor support, but also fullscreen behavior. I understood that you can group applications in the AUR. From my understanding we need to rename packages, dolphin-emu
for example would become dolphin-emu-retrorig
. It would be great, if we found somebody how could advise us on this topic.
Ok, on a whole, I agree with having a test/master/official PPA. On the subject of Arch Linux, AUR pkgs are easy, and I'm sure I can figure that out.
On a huge note, I was thinking on working on a draft that I will strip out distro-specific functions in setup.shinc, and based on the OS/distro detection you started, transfer the routine to the distro-specific module. Since Debian derivitives are fairly convered, I will like just start with Debian-setup.shinc. My aim, is to then allow us to seperate, what I think, will be an other wise mess of if statements to handle installs for different package managers.
Thoughts? Or just want to see the mess I will show you ? hahah. Maybe that sounds crazy. What ideas do you have for abstracting the setup scripts so we can handle other platforms? The problem is some actions like "service this.thing restart" is not the same obsiously for other distros that may use systemd. What I'm thinking, is attemptting to abstract things like that away, and acting based on the OS being used. So if Ubuntu 14.04 is detected, in the helpers.shinc, there will be a services function that will choose what to do (systemctl, service etc.), based on the flag we set in the OS detection function you made.
Got any other ideas?
My aim, is to then allow us to seperate, what I think, will be an other wise mess of if statements to handle installs for different package managers.
That's very true, very good thinking! Currently we have calls to apt-get
and service
spread all over the place:
http://slexy.org/view/s25urFAWXw
A possible architecture would be to have our current files duplicated in
scriptmodules/deb
scriptmodules/pacman
scriptmodules/OSX
(??)scriptmodules/rpm
and so on.The bad thing is, this is very hard to maintain. Every change would have to be done three times in all subfolders.
A better solution would be to write wrapper functions or aliases for system specific stuff, put that into seperated files like syscalls-deb.shinc
, syscalls-arch.shinc
, syscalls-rpm.shinc
and so on. Only one of those files will be sourced during system detection. These files map things like
alias install_pkg="apt-get install -y"
for Debian based systems OR alias install_pkg="pacman -S"
for Arch/Manjaro respectively.
When it comes to packing for Arch, if we could get our packaging concept double checked it would be good. Currently the only solution I know of is to rename all packages. While xbmc
and xbmc-bin
get installed under Debian-based systems, xbmc-retrorig
and xbmc-bin-retrorig
would need to be installed under Arch. This means again case
statements in our software. Or we rework our PPA and rename everything in there. But then the superseeding would fail. It's absolutely important to remove the original packages. In any case, some decent advice would be highly appreciated.
Yesterday I squashed #133 "Ace theme is not compatible with Kodi 14.0 Helix". Patch level 12 of xbmc is already available in the PPA. I've disabled the GUI dialog complaining about the missing dependencies. I've also moved the Wii motion controller query at the end of rrs_gamepads
. In master, this query will only show up for PS3/BT. Now it always shows up.
Furthermore, I've investigated the segfaulting of the SDL2 version of ppsspp, it turned out some path settings for Linux were missing(or I got them wrong, not sure yet).
For your syscalls shinc idea...that...is...brilliant. I'll conconct something today. We should be OK with the aliases after install since we are giving it a specific name, but I will make sure yo unset them or whichever at the end of the install routine. Great job
On October 25, 2014 4:33:51 AM EDT, Jens-Christian notifications@github.com wrote:
My aim, is to then allow us to seperate, what I think, will be an other wise mess of if statements to handle installs for different package managers.
That's very true, very good thinking! Currently we have calls to
apt-get
andservice
spread all over the place:http://slexy.org/view/s25urFAWXw
A possible architecture would be to have our current files duplicated in
scriptmodules/deb
scriptmodules/pacman
scriptmodules/rpm
and so on.The bad thing is, this is very hard to maintain. Every change would have to be done three times in all subfolders.
A better solution would be to write wrapper functions or aliases for system specific stuff, put that into seperated files like
syscalls-deb.shinc
,syscalls-arch.shinc
,syscalls-rpm.shinc
and so on. Only one of those files will be sourced during system detection. These files map things likealias install_pkg="apt-get install -y"
for Debian based systems ORalias install_pkg="pacman -S"
for Arch/Manjaro respectively.When it comes to packing for Arch, if we could get our packaging concept double checked it would be good. Currently the only solution I know of is to rename all packages. While
xbmc
andxbmc-bin
get installed under Debian-based systems,xbmc-retrorig
andxbmc-bin-retrorig
would need to be installed under Arch. This means againcase
statements in our software. Or we rework our PPA and rename everything in there. But then the superseeding would fail. It's absolutely important to remove the original packages. In any case, some decent advice would be highly appreciated.
Reply to this email directly or view it on GitHub: https://github.com/ProfessorKaos64/RetroRig/issues/73#issuecomment-60475930
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Morning!
I'll conconct something today.
con-what?
Aliases for the commands that only differ in the beginning, function wrappers for those that have arguments enclosed like service $ARG start
.
If the package names are really going to be different on Ubuntu and Arch, we could hook them on variables too. That would save again a lot of if-statements...
Hahah concoct as in "make up something". I'll start work abstracting those wrappers out to "deb, rpm" etc. At least deb right now to get us going. This is something I think I'm good enough to work on hahahah.
@beaumanvienna , here is a thread to respond to all the email we exchanged yesterday. One such thing was the games import. I just imported games yesterday 07/28/2014. Let me know if you still get the issues from a scratch install.
Let me know what else is going on and I'll reply here, not gmail as requested. I'm quite pleased with audio/visual performance with SDL2 in Mednafen.