[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

Nicolas Chauvet  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #14 from Nicolas Chauvet  ---
@Andrea
Please set the fedora-review flag to +
Thx

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

Andrea Musuruane  changed:

   What|Removed |Added

  Flags||fedora-review+

--- Comment #15 from Andrea Musuruane  ---
(In reply to Nicolas Chauvet from comment #14)
> @Andrea
> Please set the fedora-review flag to +
> Thx

Ops... sorry. Done!

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #16 from Andrea Musuruane  ---
(In reply to Ben Rosser from comment #13)
> - Remove static subpackage, move static library into devel subpackage.

When a package only provides static libraries you MAY place all the static
library files in the *-devel subpackage. When doing this you also MUST have a
virtual Provide for the *-static package:

%package devel
Provides: foo-static = %{version}-%{release}

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #18 from Nicolas Chauvet  ---
git manually created.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #17 from Ben Rosser  ---
> When doing this you also MUST have a virtual Provide for the *-static package:

Whoops, good catch. Fixed.

Spec URL: https://mars.arosser.com/fedora/dwarffortress/rpmfusion/dfhack.spec
SRPM URL:
https://mars.arosser.com/fedora/dwarffortress/rpmfusion/dfhack-0.44.05-2.r1.fc27.src.rpm

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #13 from Ben Rosser  ---
I've updated the spec with these fixes:

- Update to latest upstream release, add various review fixes.
- Remove static subpackage, move static library into devel subpackage.
- Remove re-definition of dist tag for EPEL.
- Use make_build instead of make smp_flags macro.
- Remove BR on git.
- Add comment to upstream ticket about isoworld issues/patches.
- Generate dfhack-doc subpackage, excluding documentation build script.

For reference, here's the SRPM I plan to import:

Spec URL: https://mars.arosser.com/fedora/dwarffortress/rpmfusion/dfhack.spec
SRPM URL:
https://mars.arosser.com/fedora/dwarffortress/rpmfusion/dfhack-0.44.05-1.r1.fc27.src.rpm

(Unfortunately there seems to be an issue with pkgdb at present, so I'm not
able to request the package).

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #12 from Ben Rosser  ---
Thanks for the review! I will take care of those issues.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

Andrea Musuruane  changed:

   What|Removed |Added

 Blocks|3   |4

--- Comment #11 from Andrea Musuruane  ---
I finally completed the review. There are some simple issues but I trust you
will handle the mandatory ones before committing.

Package is APPROVED!


Package Review
==

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated


Issues:
===

- Please rememeber you MUST remove this section:
# On CentOS, we want to strip the ".centos" bit of the dist tag.
# Credit to
https://serverfault.com/questions/688485/rpm-dist-tag-not-behaving-as-documented
# This should go away when the package is imported to RPM Fusion
%if 0%{?rhel} == 7
%define dist .el7
%endif

- This BR should no longer be needed: git

- All patches SHOULD have an upstream bug link or comment
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment

- When a package only provides static libraries you MAY place all the static
library files in the *-devel subpackage.
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Packaging_Static_Libraries_2

- %docdir contains a non documentation file:
/usr/share/doc/dfhack/docs/build.sh. You MUST not ship it. You can use the
%exclude directive.

- Please use %make_build instead of "make %{?_smp_mflags}"

- Large documentation MUST go in a -doc subpackage. Large could be size
  (~1MB) or number of files.
  Note: Documentation size is 1300480 bytes in 53 files.
  See:
 
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Documentation

- You SHOULD updated to the latest release (v0.44.05-r1)


= MUST items =

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[-]: Development (unversioned) .so files in -devel subpackage, if present.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

Generic:
[!]: Package is licensed with an open-source compatible license and meets
 other legal requirements as defined in the legal section of Packaging
 Guidelines.
 Not a problem, since this is package will go to RPM Fusion nonfree
[x]: License field in the package spec file matches the actual license.
[x]: License file installed when any subpackage combination is installed.
[x]: If the package is under multiple licenses, the licensing breakdown
 must be documented in the spec.
[x]: Package does not own files or directories owned by other packages.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package makes every effort to avoid having multiple, separate, 
 upstream projects bundled together 
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[x]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
 names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[X]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
 Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
 one supported primary architecture.
[x]: Rpmlint is run on all rpms the build produces.
 Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the
 license(s) in its own file, then that file, containing the text of the
 license(s) for the package is included in %license.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
 beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
 work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #10 from Ben Rosser  ---
Thanks for taking a look!

> IIRC using the %setup macro is the preferred way to unpack additional sources.
> http://www.tldp.org/HOWTO/RPM-HOWTO/build.html

> Do you think it is possible?

So I'd like to do this, but it wasn't immediately obvious if there was a good
way to do so, which is why I didn't initially. Based on my limited
understanding of the setup macro it seems like I would have to:

a) Remove the empty submodule directory from the git repo.
b) Extract each archive using %(auto)setup into a new directory.
c) Move the extracted directory to wherever it needs to be in the repo.

Doing this (multi-line operation) five times seemed painful when I could
instead do it in one line per submodule with tar --strip-components=1. That
being said, I can go ahead and and migrate to it if that would be preferred (or
required by policy).

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #9 from Andrea Musuruane  ---
(In reply to Ben Rosser from comment #8)
> I finally got around to working on this.

Hi Ben!
Sorry for taking so long just to have a look.

> The dfhack build process creates an include file, "git-describe.h", which
> contains the commit hash information that gets incorporated into the version
> strings. Rather than patch the build process not to use this file, which
> seemed overly invasive, I just wrote a new script (prepare-dfhack-release)
> to generate it and prevented cmake from doing so.

I'm glad to see that the size of the src.rpm has been greatly reduced.

BTW, I guess you can drop BR'ing git from:

BuildRequires:  git, gcc, cmake, zlib-devel, mesa-libGL-devel

> The new script still does a (recursive) clone of the dfhack repository. It
> then extracts all the relevant git information and uses it to create
> git-describe.h (which I include in the spec as a separate Source:). It also
> prints out the "%global commitX ..." lines for each submodule.

It seems fine to me. Just add some instructions on how to use the
"prepare-dfhack-release" script. 

It should be enough to edit the first line: 
# To update dfhack to a new release, first run "prepare-dfhack-release
RELEASE_NAME"

> The spec, then, refers to all 6 github URLs (dfhack and then 5 submodules).
> The dfhack release is looked up by tag; the submodules by commit hash. I
> think this is much cleaner than what was being done before.

I agree. It's also more readable now.

IIRC using the %setup macro is the preferred way to unpack additional sources.
http://www.tldp.org/HOWTO/RPM-HOWTO/build.html

Do you think it is possible?

> I believe I incorporated your other comments as well. And I've updated to
> the latest upstream release (0.44.03-beta1, supporting the newest release of
> Dwarf Fortress).

I'll try to make a full review in the coming days.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #8 from Ben Rosser  ---
I finally got around to working on this.

The dfhack build process creates an include file, "git-describe.h", which
contains the commit hash information that gets incorporated into the version
strings. Rather than patch the build process not to use this file, which seemed
overly invasive, I just wrote a new script (prepare-dfhack-release) to generate
it and prevented cmake from doing so.

The new script still does a (recursive) clone of the dfhack repository. It then
extracts all the relevant git information and uses it to create git-describe.h
(which I include in the spec as a separate Source:). It also prints out the
"%global commitX ..." lines for each submodule.

The spec, then, refers to all 6 github URLs (dfhack and then 5 submodules). The
dfhack release is looked up by tag; the submodules by commit hash. I think this
is much cleaner than what was being done before.

I believe I incorporated your other comments as well. And I've updated to the
latest upstream release (0.44.03-beta1, supporting the newest release of Dwarf
Fortress).

Spec URL: https://mars.arosser.com/fedora/dwarffortress/rpmfusion/dfhack.spec
SRPM URL:
https://mars.arosser.com/fedora/dwarffortress/rpmfusion/dfhack-0.44.03-1.beta1.fc27.src.rpm

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #7 from Andrea Musuruane  ---
(In reply to Ben Rosser from comment #6)
> > Isn't it possible to patch sources? Please remember that RPM Fusion 
> > builders will > need to download these data every time you request a build.
> 
> > Isn't it feasible to ship git submodules in the following way?
> > https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Submodules
> 
> Well, there are 5 submodules, and they don't really have release tags that
> are in sync with the main repository. I certainly could include them all as
> separate Source: archives, but that seemed tedious, and since I needed the
> .git metadata anyway... but you're right that it's a lot of data to have to
> carry for little gain.

If it isn't feasible, it's OK to rebuild a tarball.

> I guess I could write a script that generates the right %commitX lines for
> the submodules and writes the output of "git describe --tags --abbrev=8
> --long" to a patch. Then at build time the patch is used to get the right
> version information.
> 
> Does this approach seem like a reasonable solution?

I think a simple patch to be independent of git data is enough. 

The output of "git describe ..." can be placed in the spec file as a variable.

> > And this one too:
> > Provides:   bundled(protobuf)
> 
> I can check again, but the last time I tried to figure this out it was not
> really possible to figure out which version of protobuf was actually bundled
> (hence my comment in the spec). The version number didn't appear to be in
> any obvious place in the sources. The revision history for the bundled
> libraries isn't ideal either, because at some point 5 years ago they were
> moved from elsewhere in the project into their current directory:
> https://github.com/DFHack/dfhack/commits/master/depends/protobuf/google
> 
> The FPC recently ruled that, if it's not possible to determine the version
> number, it is not needed in a bundled provides. See this ticket:
> https://pagure.io/packaging-committee/issue/696. So, that's the approach I
> took.

It can be "the oldest version that seems reasonable as the reason we're doing
this is to tell when a library contains issues that have been fixed in newer
upstream versions".

The following one seems to be the commit that included protobuf for the first
time:
https://github.com/DFHack/dfhack/commit/494a4202dfbede6fa3a9069334458fe7c08dd9d4

Version is in "library/depends/protobuf/google/protobuf/stubs/common.h":

// The current version, represented as a single integer to make comparison
// easier:  major * 10^6 + minor * 10^3 + micro
#define GOOGLE_PROTOBUF_VERSION 2004001

i.e. version=2.4.1.

Protobuf files were later moved -as you noted- in this commit:
https://github.com/DFHack/dfhack/commit/eb4757043b12764f20c6bd1a6edc12201f74b2ce#diff-5c3353c6afb85d60c93ec649d1f426a0

Today "common.h" can be found at:
https://github.com/DFHack/dfhack/blob/master/depends/protobuf/google/protobuf/stubs/common.h

Version there is still the same.

So I assume you can specify 2.4.1.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #6 from Ben Rosser  ---
> Isn't it possible to patch sources? Please remember that RPM Fusion builders 
> will > need to download these data every time you request a build.

> Isn't it feasible to ship git submodules in the following way?
> https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Submodules

Well, there are 5 submodules, and they don't really have release tags that are
in sync with the main repository. I certainly could include them all as
separate Source: archives, but that seemed tedious, and since I needed the .git
metadata anyway... but you're right that it's a lot of data to have to carry
for little gain.

I guess I could write a script that generates the right %commitX lines for the
submodules and writes the output of "git describe --tags --abbrev=8 --long" to
a patch. Then at build time the patch is used to get the right version
information.

Does this approach seem like a reasonable solution?

> And this one too:
> Provides:   bundled(protobuf)

I can check again, but the last time I tried to figure this out it was not
really possible to figure out which version of protobuf was actually bundled
(hence my comment in the spec). The version number didn't appear to be in any
obvious place in the sources. The revision history for the bundled libraries
isn't ideal either, because at some point 5 years ago they were moved from
elsewhere in the project into their current directory:
https://github.com/DFHack/dfhack/commits/master/depends/protobuf/google

The FPC recently ruled that, if it's not possible to determine the version
number, it is not needed in a bundled provides. See this ticket:
https://pagure.io/packaging-committee/issue/696. So, that's the approach I
took.

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #5 from Andrea Musuruane  ---
Some other comments.

"licenses" is spelled as "licences" in the description. You should use American
spelling and not British spelling:
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Summary_and_description

The following Provides should be versioned.
Provides:  stonesense

And this one too:
Provides:   bundled(protobuf)
https://fedoraproject.org/wiki/Bundled_Libraries#Requirement_if_you_bundle

In this comment, macros should be quoted:
# Move data out of %{_libdir}/dfhack and into %{_datadir}/dfhack.

Rpmlint notes about "mixed-use-of-spaces-and-tabs (spaces: line 10, tab: line
190)"

The following files have the executable bit set and it must be removed
BasicApi.proto
Basic.proto

The .gitignore file must not be packaged in the -devel rpm (you can use the
%exclude directive)

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #4 from Andrea Musuruane  ---
Hi Ben,
sorry for the late reply.

I have several doubts about how the Source tarball is created.

The first thing is the tarball snapshot I made using your script is different
from the one included in the SRPM. Specifically git data is different.

BTW, always put instruction on how to run the script in the spec file.
https://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code

Then I find very inefficient to ship git data (now almost 100Mb but it will
continue to grow over time).

Moreover, if I'm not mistaken, git data are used just to be able to run 
git describe --tags --abbrev=8 --long

and get the following string 
0.43.05-r2-0-g48a61420

100Mb of data just to get 22 chars?

Isn't it possible to patch sources? Please remember that RPM Fusion builders
will need to download these data every time you request a build.

Isn't it feasible to ship git submodules in the following way?
https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Submodules

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #3 from Ben Rosser  ---
It seems that the cluster providing acm.jhu.edu has ran into some issues. The
spec and SRPM are, for the moment, also available at the following URL. 

Spec URL: https://rubble.brosser.net/fedora/dwarffortress/rpmfusion/dfhack.spec
SRPM URL:
https://rubble.brosser.net/fedora/dwarffortress/rpmfusion/dfhack-0.43.05-7.r2.fc26.src.rpm

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

--- Comment #2 from Ben Rosser  ---
> The build-dfhack-tarball script is not shipped inside the src.rpm file but 
> you must provide it.

Whoops. It was always my intention to include it in the dist-git repository but
apparently I missed this detail.

Reuploaded, with build-dfhack-tarball added as Source3. I have not bothered
bumping the release for this change.

Spec URL:
https://www.acm.jhu.edu/~bjr/fedora/dwarffortress/rpmfusion/dfhack.spec
SRPM URL:
https://www.acm.jhu.edu/~bjr/fedora/dwarffortress/rpmfusion/dfhack-0.43.05-7.r2.fc28.src.rpm

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

Andrea Musuruane  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #1 from Andrea Musuruane  ---
Hi Ben,

The build-dfhack-tarball script is not shipped inside the src.rpm file but you
must provide it.

"There are several cases where upstream is not providing the source to you in
an upstream tarball. In these cases you must document how to generate the
tarball used in the rpm either through a spec file comment or a script included
as a separate SourceX:. "
https://fedoraproject.org/wiki/Packaging:SourceURL#Referencing_Source

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

Andrea Musuruane  changed:

   What|Removed |Added

 Blocks|2   |3


Referenced Bugs:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=2
[Bug 2] Tracker: New packages awaiting review
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3
[Bug 3] Tracker: Packages under review.
-- 
You are receiving this mail because:
You are on the CC list for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

Andrea Musuruane  changed:

   What|Removed |Added

 CC||musur...@gmail.com
   Assignee|rpmfusion-package-review@rp |musur...@gmail.com
   |mfusion.org |

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

Ben Rosser  changed:

   What|Removed |Added

 Blocks||2


Referenced Bugs:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=2
[Bug 2] Tracker: New packages awaiting review
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639
Bug 4639 depends on bug 3953, which changed state.

Bug 3953 Summary: Review request: dwarffortress - A single-player procedurally 
generated fantasy game
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3953

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

[Bug 4639] dfhack - Memory hacking library for Dwarf Fortress and a set of tools that use it

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4639

Ben Rosser  changed:

   What|Removed |Added

 Depends on||3953


Referenced Bugs:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=3953
[Bug 3953] Review request: dwarffortress - A single-player procedurally
generated fantasy game
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org