Re: lnav/0.7.0-2: FTBFS on mips, powerpc, s390x and sparc

2014-04-02 Thread Patrick Baggett
Seems like a tiny fix, as mentioned by the owner tstack in
line_buffer.cc(185). Upstream should be able to do this easily.

this-lb_file_time = *((int32_t *)gz_id[4]);

should be something to the effect of:

this-lb_file_time = (gz_id[4]) | (gz_id[5]  8) | (gz_id[6]  16) | (
gz_id[7]  24);

to reassemble the 32-bit value regardless of native byte order. Also, it
will removing the warning from type-punning that happens when you
do *((int32_t *)something);


On Wed, Apr 2, 2014 at 2:53 PM, Salvatore Bonaccorso car...@debian.orgwrote:

 Dear mips, powerpc, s390x and sparc porters

 (Please CC me on replies as I'm not subscribed to the port
 mailinglist).

 I'm contancting your porter lists as I have a FTBFS which seems
 specific to the big endian architecture.

  [1] https://buildd.debian.org/status/package.php?p=lnav

 Upstream has pointed me in his comment in [2] in some direction to be
 investigated.

  [2] https://github.com/tstack/lnav/issues/93

 Can some of you help me with this issue? Thanks in advance already.

 Regards,
 Salvatore


 --
 To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/20140402195325.GA30197@eldamar.local




Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

2013-10-02 Thread Patrick Baggett
I'm interesting in helping on ia64. I'm not fluent in ia64 assembly, but I
can get around pretty well. I'm very experienced in C/C++/Java and
debugging. I've got a fully functional system running Xorg/Mesa3D/sound, so
I can reproduce, test, and fix issues as time permits.

Patrick Baggett


On Wed, Oct 2, 2013 at 2:45 AM, Niels Thykier ni...@thykier.net wrote:

 Hi,

 The final results are in:

 Summary table:
 Arch   || DDs || NMs/DMs || Other || Total
 ---++-++-++---++--
 armel  ||  3  ||   0 || 1 ||4
 armhf  ||  3  ||   1 || 2 ||6
 hurd-i386  ||  5  ||   0 || 3 ||8
 ia64   || *0* ||   0 || 3 ||3
 kfreebsd-amd64 ||  4  ||   0 || 2 ||6
 kfreebsd-i386  ||  4  ||   0 || 2 ||6
 mips   ||  1  ||   0 || 1 ||2
 mipsel ||  1  ||   0 || 1 ||2
 powerpc[1] || (1) ||   0 || 2 ||   2.5?
 s390x  || *0* ||   0 || 0 ||   *0*
 sparc[2]   ||  1  ||   0 || 0 ||1

 [1] The (1) and .5 is from a I am not primarily a porter [...]-remark,
 so I wasn't sure how to count it.

 [2] By the looks of it, if sparc was replaced by sparc64, we could be
 looking at 3 in the Other-column rather than 0.

 NMs/DMs include DMs and people currently in NM process.  The Other
 column may include people who said they would like to become porters
 (but would need to be introduced to the job) and thus may imply some
 active recruiting from the current porters.  This is at least true for
 hurd-i386.



 The current policy says that we require 5 developers (i.e. DDs) for
 release architectures[AP], so based on that only amd64, i386 and
 hurd-i386 would pass this requirement.  It is quite possible we need to
 revise that requirement, but most of the architectures would (still) do
 well to attract a few more (DD) porters.
   I have attached a file with my notes of who are behind those numbers.
  If your name is missing or you believe I have miscounted something[CD]
 for an architecture listed in the table above, please reply to this
 email *promptly* (CC'ing me explicitly is fine) with your concerns or
 corrections.

 At this time, I have *not* updated the arch qualification table yet.  I
 will do that in a couple of days.  We will also follow up on this in the
 next bits from the release team.

 ~Niels

 [AP] http://release.debian.org/jessie/arch_policy.html

 [CD] I may (or may not) have been caffeine-deprived when I did the
 counting.  You are free to make assumptions about whether that has
 affected my ability to do addic^Htion or parsing your email(s) properly.