[Bug 970972] Review Request: cuisine - Chef-like functionnality for
Fabric
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=970972
Package Review <package-review(a)lists.fedoraproject.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |needinfo?(nils.fedora@anoth
| |erhomepage.org)
--- Comment #8 from Package Review <package-review(a)lists.fedoraproject.org> ---
This is an automatic check from review-stats script.
This review request ticket hasn't been updated for some time. We're sorry
it is taking so long. If you're still interested in packaging this software
into Fedora repositories, please respond to this comment clearing the
NEEDINFO flag.
You may want to update the specfile and the src.rpm to the latest version
available and to propose a review swap on Fedora devel mailing list to increase
chances to have your package reviewed. If this is your first package and you
need a sponsor, you may want to post some informal reviews. Read more at
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group.
Without any reply, this request will shortly be considered abandoned
and will be closed.
Thank you for your patience.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
3 years, 7 months
[Bug 1350884] Review Request: mspgcc - Rebase of GCC for the MSP430
to TI / Red Hat upstream
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1350884
--- Comment #46 from Brandon Nielsen <nielsenb(a)jetfuse.net> ---
(In reply to Andy Mender from comment #45)
> I'm wondering whether perhaps it's not possible to split this into multiple
> SPEC files and tackle each component separately? For instance, to do
> msp430-elf-binutils or msp430-elf-gdb first. For instance, here the packager
> focused on gdb alone: https://bugzilla.redhat.com/show_bug.cgi?id=1859627
The source used for the specfile in this review is _not_ the vanilla GCC / GDB
/ binutils upstream, it is a bespoke version done by Mitto Systems for TI and
ships GCC / GDB / binutils all in one tarball. A lot of the work has been
upstreamed, but there are still differences. I could redo the work of comment
#4 to document what still differs, but ultimately I think most developers would
prefer using something as close as possible to what TI provides, which is why
I'm not okay with the current state of the specfile, the resulting binaries
would not work with Makefiles targeting the TI provided blobs (which is
probably >99% of them). As mentioned above, I've been short on time to
investigate this behavior.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
3 years, 7 months
[Bug 1878902] New: Review Request: naga - Simplified Java NIO
asynchronous sockets
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1878902
Bug ID: 1878902
Summary: Review Request: naga - Simplified Java NIO
asynchronous sockets
Product: Fedora
Version: rawhide
Hardware: All
OS: Linux
Status: NEW
Component: Package Review
Severity: medium
Priority: medium
Assignee: nobody(a)fedoraproject.org
Reporter: loganjerry(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: package-review(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Spec URL: https://jjames.fedorapeople.org/naga/naga.spec
SRPM URL:
https://jjames.fedorapeople.org/naga/naga-3.0-15.20150330git054a930.fc34....
Fedora Account System Username: jjames
Description: Naga aims to be a very small NIO library that provides a handful
of java classes to wrap the usual Socket and ServerSocket with asynchronous NIO
counterparts (similar to NIO2 planned for Java 1.7).
All of this is driven from a single thread, making it useful for both client
(e.g. allowing I/O to be done in the AWT-thread without any need for threads)
and server programming (1 thread for all connections instead of 2
threads/connection).
Internally Naga is a straightforward NIO implementation without any threads or
event-queues thrown in, it is "just the NIO-stuff", to let you build things on
top of it.
Naga contains the code needed to get NIO up and running without having to code
partially read buffers and setting various selection key flags.
NOTE: The naga package was previously in Fedora. This is a re-review due to it
being absent for some months.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
3 years, 7 months
[Bug 1350884] Review Request: mspgcc - Rebase of GCC for the MSP430
to TI / Red Hat upstream
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1350884
Brandon Nielsen <nielsenb(a)jetfuse.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(nielsenb@jetfuse. |
|net) |
--- Comment #44 from Brandon Nielsen <nielsenb(a)jetfuse.net> ---
No real progress.
The post to the devel list went nowhere. I have been unable to modify the
cross-gcc specfile to build a compiler for the MSP430 that generates a binary
that runs on actual hardware. It is possible I'm not correctly compiling
newlib. I have not had a chance to compare the resulting assembly versus a
working compiler. Trying to get it working consumes a lot of CPU time, actual
time, and disk space. I only really have the latter. Given the lack of response
I've mostly abandoned the idea for now.
As for this review, I still need to add the check step. I'm also still trying
to figure out why the '-B/usr/bin/msp430-elf-' is required. It breaks a lot of
existing Makefiles. Hopefully I'll get a chance to dig into that all more this
week.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
3 years, 7 months