Well, this sounds cool. Thank you for opening the world of Vagrant to me. I think I am doing this right. I have run the commands and am waiting with this as my last output:
==> default: -- Graphics Type: vnc ==> default: -- Graphics Port: -1 ==> default: -- Graphics IP: 127.0.0.1 ==> default: -- Graphics Password: Not defined ==> default: -- Video Type: cirrus ==> default: -- Video VRAM: 9216 ==> default: -- Sound Type: ==> default: -- Keymap: en-us ==> default: -- TPM Path: ==> default: -- INPUT: type=mouse, bus=ps2 ==> default: Creating shared folders metadata... ==> default: Starting domain. ==> default: Waiting for domain to get an IP address... It's been sitting there for quite some time and an htop shows 2 of my cores spinning at 100% occupied by qemu... I noticed the vnc reference at localhost and tried to connect to that and sure enough, I get connected to a boot screen which last says: Booting from Hard Disk... But nothing else happens? Should I keep waiting? Do I need to escalate permissions to root? Do I need to add my username to some new vagrant group? Do I need to reboot my box for my dnf install stuff to "take"? Any advice would be appreciated. Looking forward to adding this to my toolbox once I learn. Troy On 7/20/19 9:28 PM, Greg Hellings wrote: > https://app.vagrantup.com/ppc64le/boxes/fedora30 > > That should allow you to bring up a local VM with Fedora 30 on ppc64le > using Vagrant. Only works on systems with a libvirt backend to Vagrant > (sudo dnf install vagrant vagrant-libvirt should do the trick on a > Fedora workstation, followed by "vagrant up --provider=libvirt" if it > doesn't default to that provider on a standard "vagrant up"). > > The build error was in Rawhide, though, and seems to have been due to > changes in the headers. Errors from a similar cause have come and gone > from time to time in the past. Sometimes they come and go in automated > builds in a transient manner. I don't know if you'll see it when you > try or not when you try. > > --Greg > > On Sat, Jul 20, 2019 at 10:36 PM Troy A. Griffitts > <scr...@crosswire.org <mailto:scr...@crosswire.org>> wrote: > > Anyone have access to a PPC64LE box I can play on? > > On 7/18/19 12:04 AM, Jaak Ristioja wrote: > > Yes, it is a sizeable patch. Although there might be hacks > around this > > issue, getting rid of the reserved identifiers and using the > fixed-width > > types from <cstdint> seems to be the correct approach to take. > > > > I'm not even sure the patch applies correctly to Sword SVN > trunk, but > > since this issue has long been fixed in Sword++, I referred to this > > commit in hopes to accelerate this getting fixed for Sword as > well. I > > think it would not benefit anyone if Sword was left failing on > Fedora > > rawhide. > > > > > > +Jaak > > > > > > On 18.07.19 06:47, Greg Hellings wrote: > >> That is a rather sizeable patch. I don't want to just apply it > wholesale to > >> the Sword engine without some input from people who know more > about the > >> code than I do. It should, however, be workable if Troy doesn't > have a more > >> permanent fix in mind. > >> > >> --Greg > >> > >> On Wed, Jul 17, 2019 at 4:52 PM Jaak Ristioja <j...@ristioja.ee > <mailto:j...@ristioja.ee>> wrote: > >> > >>> In Sword++ we fixed [1] this by using the fixed-width integer > types > >>> provided by <cstdint>. Note also that some certain names > containing > >>> underscores are reserved to the C++ implementation [2], e.g. names > >>> beginning with underscores and names containing adjacent > underscores. > >>> > >>> > >>> Best regards, > >>> Jaak > >>> > >>> > >>> [1]: Feel free to integrate > >>> > >>> > > https://github.com/swordxx/swordxx/commit/3934674fd8db1302c7777c323c0a56235292d6d7 > >>> back to Sword. In Sword++ most of these type names were later > prefixed > >>> with std::, e.g. std::uint64_t instead of plain uint64_t. > >>> > >>> [2]: See https://stackoverflow.com/a/228797 for a good summary > on this. > >>> > >>> > >>> On 17.07.19 17:52, Greg Hellings wrote: > >>>> I got an automated report this week that Sword 1.8.1 has > begun failing to > >>>> build on ppc64le architecture with type redefinition errors. > The errors > >>> are > >>>> reported here: > https://bugzilla.redhat.com/show_bug.cgi?id=1730318 > >>>> > >>>> To copy from that link, the relevant error is: > >>>> > >>>> /usr/include/asm-generic/int-l64.h:29:25: error: conflicting > >>>> declaration 'typedef long int __s64' > >>>> 29 | typedef __signed__ long __s64; > >>>> | ^~~~~ > >>>> > >>>> /usr/include/asm-generic/int-l64.h:30:23: error: conflicting > >>>> declaration 'typedef long unsigned int __u64' > >>>> 30 | typedef unsigned long __u64; > >>>> | ^~~~~ > >>>> > >>>> I try to shy away from knowing too much about C's typing > system. I can > >>>> easily locate the places in our code where we are defining > those types > >>>> ourself. However, I don't want to mess up proper detection and > >>>> definition of them in a patch if I can help it. > >>>> > >>>> --Greg > >>>> > >>>> > >>>> _______________________________________________ > >>>> sword-devel mailing list: sword-devel@crosswire.org > <mailto:sword-devel@crosswire.org> > >>>> http://www.crosswire.org/mailman/listinfo/sword-devel > >>>> Instructions to unsubscribe/change your settings at above page > >>>> > >>> > >>> _______________________________________________ > >>> sword-devel mailing list: sword-devel@crosswire.org > <mailto:sword-devel@crosswire.org> > >>> http://www.crosswire.org/mailman/listinfo/sword-devel > >>> Instructions to unsubscribe/change your settings at above page > >>> > >> > >> _______________________________________________ > >> sword-devel mailing list: sword-devel@crosswire.org > <mailto:sword-devel@crosswire.org> > >> http://www.crosswire.org/mailman/listinfo/sword-devel > >> Instructions to unsubscribe/change your settings at above page > >> > > > > _______________________________________________ > > sword-devel mailing list: sword-devel@crosswire.org > <mailto:sword-devel@crosswire.org> > > http://www.crosswire.org/mailman/listinfo/sword-devel > > Instructions to unsubscribe/change your settings at above page > > _______________________________________________ > sword-devel mailing list: sword-devel@crosswire.org > <mailto:sword-devel@crosswire.org> > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page > > > _______________________________________________ > sword-devel mailing list: sword-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
