Discussion:
Bug#1079642: ITP: mfiutil -- Utility for managing LSI MegaRAID SAS controllers
Add Reply
WHR
2024-08-25 18:40:01 UTC
Reply
Permalink
Package: wnpp
Severity: wishlist
Owner: WHR <***@rivoreo.one>
X-Debbugs-Cc: debian-***@lists.debian.org, ***@rivoreo.one

* Package name : mfiutil
Version : 1.0.15-rivoreo-r1
Upstream Contact: WHR <***@rivoreo.one>
* URL : https://sourceforge.net/projects/mfiutil/
* License : BSD-3-Clause
Programming Lang: C
Description : Utility for managing LSI MegaRAID SAS controllers

A lightweight utility providing basic management functionality for LSI
MegaRAID SAS controllers, ported from FreeBSD.

It works with Linux megaraid_sas driver, and supports 2nd and later
generations of MegaRAID SAS conntrollers.


Additional information:

To my knowledge, this is the only free management tool available for the LSI
MegaRAID SAS conntrollers. With this package readily available will enabling
users to perform usual maintenance tasks on their MegaRAID SAS conntrollers,
without having to run the vendor-provided proprietary tools.

This tool has been tested with following controllers:
* Dell PERC H310 Mini
* Dell PERC H330 Mini
* Dell PERC H710 Mini
* Dell PERC H730 Mini
* Dell PERC H840

I plan to make the first release source tarbell available in next few days;
after that a Debian source package will be created from it.

I didn't find an obvious matching team for this package. I do need a sponsor.
Jérémy Lal
2024-08-25 21:30:01 UTC
Reply
Permalink
Post by WHR
Package: wnpp
Severity: wishlist
* Package name : mfiutil
Version : 1.0.15-rivoreo-r1
* URL : https://sourceforge.net/projects/mfiutil/
* License : BSD-3-Clause
Programming Lang: C
Description : Utility for managing LSI MegaRAID SAS controllers
A lightweight utility providing basic management functionality for LSI
MegaRAID SAS controllers, ported from FreeBSD.
It works with Linux megaraid_sas driver, and supports 2nd and later
generations of MegaRAID SAS conntrollers.
To my knowledge, this is the only free management tool available for the LSI
MegaRAID SAS conntrollers. With this package readily available will enabling
users to perform usual maintenance tasks on their MegaRAID SAS
conntrollers,
without having to run the vendor-provided proprietary tools.
* Dell PERC H310 Mini
* Dell PERC H330 Mini
* Dell PERC H710 Mini
* Dell PERC H730 Mini
* Dell PERC H840
I plan to make the first release source tarbell available in next few days;
after that a Debian source package will be created from it.
I didn't find an obvious matching team for this package. I do need a sponsor.
Hi

Since Peter and I put megactl in debian recently, it would make sense we
help you on this one.
It would be nice to maintain the debianization at
https://salsa.debian.org/debian/mfiutil
I can create the repo if needed.

Jérémy
Petter Reinholdtsen
2024-08-25 22:10:01 UTC
Reply
Permalink
[Jérémy Lal]
Post by Jérémy Lal
Since Peter and I put megactl in debian recently, it would make sense
we help you on this one.
It would be nice to maintain the debianization at
https://salsa.debian.org/debian/mfiutil
I can create the repo if needed.
It seem like a nice tool, indeed. I hope the package will announce its
supported hardware using Appstream provides->modalias entries, to ensure
isenkram will propose to install it on all relevant machines. I assume
the XML file in megactl can be a useful starting point.
--
Happy hacking
Petter Reinholdtsen
Petter Reinholdtsen
2024-08-26 05:20:01 UTC
Reply
Permalink
I built and tested the source on a machine running testing, and it seem
to work fine. According to the compiler there are some potential buffer
overflows:

gcc -I include -std=gnu99 -Wall -Wno-unused-value -Os -c -o mfi_drive.o mfi_drive.c
mfi_drive.c: In function ‘mfi_pdstate’:
mfi_drive.c:160:40: warning: ‘%04x’ directive writing between 4 and 8 bytes into a region of size 7 [-Wformat-overflow=]
160 | sprintf(buf, "PSTATE 0x%04x", state);
| ^~~~
In function ‘mfi_pdstate’,
inlined from ‘mfi_pdstate’ at mfi_drive.c:136:1:
mfi_drive.c:160:30: note: directive argument in the range [3, 4294967295]
160 | sprintf(buf, "PSTATE 0x%04x", state);
| ^~~~~~~~~~~~~~~
mfi_drive.c:160:17: note: ‘sprintf’ output between 14 and 18 bytes into a destination of size 16
160 | sprintf(buf, "PSTATE 0x%04x", state);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mfi_drive.c: In function ‘mfi_pd_inq_string’:
mfi_drive.c:418:57: warning: ‘ ’ directive output may be truncated writing 1 byte into a region of size between 0 and 62 [-Wformat-truncation=]
418 | snprintf(inq_string, sizeof(inq_string), "<%s %s %s serial=%s> %s", vendor,
| ^
mfi_drive.c:418:9: note: ‘snprintf’ output between 14 and 121 bytes into a destination of size 64
418 | snprintf(inq_string, sizeof(inq_string), "<%s %s %s serial=%s> %s", vendor,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
419 | product, revision, serial, rstr);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mfi_drive.c:401:65: warning: ‘ serial=’ directive output may be truncated writing 8 bytes into a region of size between 0 and 62 [-Wformat-truncation=]
401 | snprintf(inq_string, sizeof(inq_string), "<%s %s serial=%s> SATA",
| ^~~~~~~~
mfi_drive.c:401:17: note: ‘snprintf’ output between 17 and 98 bytes into a destination of size 64
401 | snprintf(inq_string, sizeof(inq_string), "<%s %s serial=%s> SATA",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
402 | product, revision, serial);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc -I include -std=gnu99 -Wall -Wno-unused-value -Os -c -o mfi_evt.o mfi_evt.c
mfi_evt.c: In function ‘pdrive_location’:
mfi_evt.c:343:64: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
343 | snprintf(buffer, sizeof(buffer), "%02d(e%d/s%d)", pd->device_id,
| ^
mfi_evt.c:343:17: note: ‘snprintf’ output between 10 and 17 bytes into a destination of size 16
343 | snprintf(buffer, sizeof(buffer), "%02d(e%d/s%d)", pd->device_id,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
344 | pd->enclosure_index, pd->slot_number);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
gcc -I include -std=gnu99 -Wall -Wno-unused-value -Os -c -o mfi_volume.o mfi_volume.c
mfi_volume.c: In function ‘mfi_ldstate’:
mfi_volume.c:59:40: warning: ‘%02x’ directive writing between 2 and 8 bytes into a region of size 7 [-Wformat-overflow=]
59 | sprintf(buf, "LSTATE 0x%02x", state);
| ^~~~
mfi_volume.c:59:30: note: directive argument in the range [4, 4294967295]
59 | sprintf(buf, "LSTATE 0x%02x", state);
| ^~~~~~~~~~~~~~~
mfi_volume.c:59:17: note: ‘sprintf’ output between 12 and 18 bytes into a destination of size 16
59 | sprintf(buf, "LSTATE 0x%02x", state);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Here is a patch to get rid of the compiler warnings.

diff --git a/mfi_drive.c b/mfi_drive.c
index 9f726f3..1450621 100644
--- a/mfi_drive.c
+++ b/mfi_drive.c
@@ -135,7 +135,7 @@ mfi_drive_name(const struct mfi_pd_info *info_p, uint16_t device_id, uint32_t de
const char *
mfi_pdstate(enum mfi_pd_state state)
{
- static char buf[16];
+ static char buf[18];

switch (state) {
case MFI_PD_STATE_UNCONFIGURED_GOOD:
@@ -375,7 +375,7 @@ mfi_pd_inq_string(const struct mfi_pd_info *info)
{
struct scsi_inquiry_data iqd, *inq_data = &iqd;
char vendor[16], product[48], revision[16], rstr[12], serial[SID_VENDOR_SPECIFIC_0_SIZE];
- static char inq_string[64];
+ static char inq_string[121];

memcpy(inq_data, info->inquiry_data,
(sizeof (iqd) < sizeof (info->inquiry_data))?
diff --git a/mfi_evt.c b/mfi_evt.c
index ad22bc8..b43be7e 100644
--- a/mfi_evt.c
+++ b/mfi_evt.c
@@ -334,7 +334,7 @@ simple_hex(const void *ptr, size_t length, const char *separator)
static const char *
pdrive_location(const struct mfi_evt_pd *pd)
{
- static char buffer[16];
+ static char buffer[17];

if (pd->enclosure_index == 0) {
snprintf(buffer, sizeof(buffer), "%02d(s%d)", pd->device_id,
diff --git a/mfi_volume.c b/mfi_volume.c
index cde2bb4..571333c 100644
--- a/mfi_volume.c
+++ b/mfi_volume.c
@@ -44,7 +44,7 @@ MFI_TABLE(top, volume);
const char *
mfi_ldstate(enum mfi_ld_state state)
{
- static char buf[16];
+ static char buf[18];

switch (state) {
case MFI_LD_STATE_OFFLINE:
--
Happy hacking
Petter Reinholdtsen
WHR
2024-08-26 18:10:01 UTC
Reply
Permalink
Post by Petter Reinholdtsen
I built and tested the source on a machine running testing, and it seem
to work fine. According to the compiler there are some potential buffer
gcc -I include -std=gnu99 -Wall -Wno-unused-value -Os -c -o mfi_drive.o mfi_drive.c
mfi_drive.c:160:40: warning: ‘%04x’ directive writing between 4 and 8 bytes
into a region of size 7 [-Wformat-overflow=]
160 | sprintf(buf, "PSTATE 0x%04x", state);
| ^~~~
In function ‘mfi_pdstate’,
mfi_drive.c:160:30: note: directive argument in the range [3, 4294967295]
160 | sprintf(buf, "PSTATE 0x%04x", state);
| ^~~~~~~~~~~~~~~
mfi_drive.c:160:17: note: ‘sprintf’ output between 14 and 18 bytes into a
destination of size 16
160 | sprintf(buf, "PSTATE 0x%04x", state);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mfi_drive.c:418:57: warning: ‘ ’ directive output may be truncated writing 1
byte into a region of size between 0 and 62 [-Wformat-truncation=]
418 | snprintf(inq_string, sizeof(inq_string), "<%s %s %s serial=%s> %s", vendor,
| ^
mfi_drive.c:418:9: note: ‘snprintf’ output between 14 and 121 bytes into a
destination of size 64
418 | snprintf(inq_string, sizeof(inq_string), "<%s %s %s serial=%s> %s", vendor,
|
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
419 | product, revision, serial, rstr);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mfi_drive.c:401:65: warning: ‘ serial=’ directive output may be truncated
writing 8 bytes into a region of size between 0 and 62
[-Wformat-truncation=]
401 | snprintf(inq_string, sizeof(inq_string), "<%s %s serial=%s> SATA",
|
^~~~~~~~
mfi_drive.c:401:17: note: ‘snprintf’ output between 17 and 98 bytes into a
destination of size 64
401 | snprintf(inq_string, sizeof(inq_string), "<%s %s serial=%s> SATA",
|
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
402 | product, revision, serial);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc -I include -std=gnu99 -Wall -Wno-unused-value -Os -c -o mfi_evt.o mfi_evt.c
mfi_evt.c:343:64: warning: ‘snprintf’ output may be truncated before the
last format character [-Wformat-truncation=]
343 | snprintf(buffer, sizeof(buffer), "%02d(e%d/s%d)", pd->device_id,
| ^
mfi_evt.c:343:17: note: ‘snprintf’ output between 10 and 17 bytes into a
destination of size 16
343 | snprintf(buffer, sizeof(buffer), "%02d(e%d/s%d)", pd->device_id,
|
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
344 | pd->enclosure_index, pd->slot_number);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
gcc -I include -std=gnu99 -Wall -Wno-unused-value -Os -c -o mfi_volume.o mfi_volume.c
mfi_volume.c:59:40: warning: ‘%02x’ directive writing between 2 and 8 bytes
into a region of size 7 [-Wformat-overflow=]
59 | sprintf(buf, "LSTATE 0x%02x", state);
| ^~~~
mfi_volume.c:59:30: note: directive argument in the range [4, 4294967295]
59 | sprintf(buf, "LSTATE 0x%02x", state);
| ^~~~~~~~~~~~~~~
mfi_volume.c:59:17: note: ‘sprintf’ output between 12 and 18 bytes into a
destination of size 16
59 | sprintf(buf, "LSTATE 0x%02x", state);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here is a patch to get rid of the compiler warnings.
diff --git a/mfi_drive.c b/mfi_drive.c
index 9f726f3..1450621 100644
--- a/mfi_drive.c
+++ b/mfi_drive.c
@@ -135,7 +135,7 @@ mfi_drive_name(const struct mfi_pd_info *info_p,
uint16_t device_id, uint32_t de
const char *
mfi_pdstate(enum mfi_pd_state state)
{
- static char buf[16];
+ static char buf[18];
switch (state) {
@@ -375,7 +375,7 @@ mfi_pd_inq_string(const struct mfi_pd_info *info)
{
struct scsi_inquiry_data iqd, *inq_data = &iqd;
char vendor[16], product[48], revision[16], rstr[12],
serial[SID_VENDOR_SPECIFIC_0_SIZE];
- static char inq_string[64];
+ static char inq_string[121];
memcpy(inq_data, info->inquiry_data,
(sizeof (iqd) < sizeof (info->inquiry_data))?
diff --git a/mfi_evt.c b/mfi_evt.c
index ad22bc8..b43be7e 100644
--- a/mfi_evt.c
+++ b/mfi_evt.c
@@ -334,7 +334,7 @@ simple_hex(const void *ptr, size_t length, const char *separator)
static const char *
pdrive_location(const struct mfi_evt_pd *pd)
{
- static char buffer[16];
+ static char buffer[17];
if (pd->enclosure_index == 0) {
snprintf(buffer, sizeof(buffer), "%02d(s%d)", pd->device_id,
diff --git a/mfi_volume.c b/mfi_volume.c
index cde2bb4..571333c 100644
--- a/mfi_volume.c
+++ b/mfi_volume.c
@@ -44,7 +44,7 @@ MFI_TABLE(top, volume);
const char *
mfi_ldstate(enum mfi_ld_state state)
{
- static char buf[16];
+ static char buf[18];
switch (state) {
--
Happy hacking
Petter Reinholdtsen
Hello.

I was writing a new section for the man page today. I will commit this patch
by tomorrow. Thanks.
Petter Reinholdtsen
2024-08-26 21:00:01 UTC
Reply
Permalink
[WHR]
Post by WHR
I was writing a new section for the man page today. I will commit this
patch by tomorrow. Thanks.
Good. What is your timeline for getting the package into Debian? I
suspect the deadline to make it to the next stable release is
approaching very quickly. Do you need help with making Debian build
rules, or do you have a draft already?
--
Happy hacking
Petter Reinholdtsen
Jérémy Lal
2024-08-26 23:20:01 UTC
Reply
Permalink
Post by Petter Reinholdtsen
[WHR]
Post by WHR
I was writing a new section for the man page today. I will commit this
patch by tomorrow. Thanks.
Good. What is your timeline for getting the package into Debian? I
suspect the deadline to make it to the next stable release is
approaching very quickly. Do you need help with making Debian build
rules, or do you have a draft already?
--
Happy hacking
Petter Reinholdtsen
Soon. I plan to make source package ready before the end of this month.
Yes, I have a draft.
However, I just received an email that notifys my account creating request
was
rejected, without explanation. Any idea for this?
What did you request access to ?
WHR
2024-08-27 02:10:01 UTC
Reply
Permalink
Post by Jérémy Lal
Post by Petter Reinholdtsen
[WHR]
Post by WHR
I was writing a new section for the man page today. I will commit this
patch by tomorrow. Thanks.
Good. What is your timeline for getting the package into Debian? I
suspect the deadline to make it to the next stable release is
approaching very quickly. Do you need help with making Debian build
rules, or do you have a draft already?
--
Happy hacking
Petter Reinholdtsen
Soon. I plan to make source package ready before the end of this month.
Yes, I have a draft.
However, I just received an email that notifys my account creating request
was
rejected, without explanation. Any idea for this?
What did you request access to ?
I thought it would be nice to create an account at Salsa; but in my
understanding this isn't strictly need. It that right?
WHR
2024-08-27 11:30:01 UTC
Reply
Permalink
Hello.

I'm asking for suggestion of any improvement that should be done in the
non-Debian source tree. For example should the Makefile be having some more
features, that would benefit the Debian build system and possibly others?

In the case of this Makefile btw, I already have a Debian patch to remove
'-Os' from 'CFLAGS; since I want to keep it in non-Debian source package.
Petter Reinholdtsen
2024-08-28 05:50:01 UTC
Reply
Permalink
[WHR]
Post by WHR
I'm asking for suggestion of any improvement that should be done in the
non-Debian source tree. For example should the Makefile be having some more
features, that would benefit the Debian build system and possibly others?
In the case of this Makefile btw, I already have a Debian patch to remove
'-Os' from 'CFLAGS; since I want to keep it in non-Debian source package.
I could have a look. I guess the most important part is to get the
build to use CPPFLAGS, CFLAGS or CXXFLAGS and LDFLAGS, to ensure
hardening is enabled by default.

In which public git repository is the draft Debian packaging?
--
Happy hacking
Petter Reinholdtsen
Petter Reinholdtsen
2024-08-27 05:40:01 UTC
Reply
Permalink
[WHR]
However, I just received an email that notifys my account creating
request was rejected, without explanation. Any idea for this?
I do not know the procedure for approval or rejections on salsa, but
would suspect it is simply an error, perhaps a spam protection process
gone wrong. Did you try to contact the gitlab administrators, for
example via IRC, #salsa on irc.debian.org?
--
Happy hacking
Petter Reinholdtsen
WHR
2024-08-28 07:20:01 UTC
Reply
Permalink
Post by Petter Reinholdtsen
[WHR]
Post by WHR
I'm asking for suggestion of any improvement that should be done in the
non-Debian source tree. For example should the Makefile be having some
more
features, that would benefit the Debian build system and possibly others?
In the case of this Makefile btw, I already have a Debian patch to remove
'-Os' from 'CFLAGS; since I want to keep it in non-Debian source
package.
I could have a look. I guess the most important part is to get the
build to use CPPFLAGS, CFLAGS or CXXFLAGS and LDFLAGS, to ensure
hardening is enabled by default.
In my testing, it seems that GNU Make implicitly used CPPFLAGS for compiling
C sources; although duplicating them in CFLAGS didn't hurt.
Post by Petter Reinholdtsen
In which public git repository is the draft Debian packaging?
None. I havn't started using git for it yet. However I'm trying to upload a
draft onto mentors.
WHR
2024-08-28 07:30:01 UTC
Reply
Permalink
Post by WHR
Post by Petter Reinholdtsen
[WHR]
Post by WHR
I'm asking for suggestion of any improvement that should be done in the
non-Debian source tree. For example should the Makefile be having some
more
features, that would benefit the Debian build system and possibly others?
In the case of this Makefile btw, I already have a Debian patch to remove
'-Os' from 'CFLAGS; since I want to keep it in non-Debian source
package.
I could have a look. I guess the most important part is to get the
build to use CPPFLAGS, CFLAGS or CXXFLAGS and LDFLAGS, to ensure
hardening is enabled by default.
In my testing, it seems that GNU Make implicitly used CPPFLAGS for compiling
C sources; although duplicating them in CFLAGS didn't hurt.
Post by Petter Reinholdtsen
In which public git repository is the draft Debian packaging?
None. I havn't started using git for it yet. However I'm trying to upload a
draft onto mentors.
Uploaded at https://mentors.debian.net/package/mfiutil/
Petter Reinholdtsen
2024-08-28 07:50:01 UTC
Reply
Permalink
[WHR]
Post by WHR
None. I havn't started using git for it yet.
Right. Salsa might be the best choice, then. Did you get any response
from the Salsa admins?
Post by WHR
Uploaded at https://mentors.debian.net/package/mfiutil/
Look like the QA information list already got several suggestions for
improvements. In addition, some comments from me: Is there a reason for
the debhelper 11 level, or could it move to the latest 13? Also, the
Standards-Version should move to 4.7.0. I suspect the package
description should mention Dell PERC and perhaps other rebranded
editions of the LSI controller. Feel free to list me and Jérémy as
uploaders. A Appstream metainfo XML file should be added with the
relevant PCI ids listed.

Besides this, the package look good to me. :)
--
Happy hacking
Petter Reinholdtsen
WHR
2024-08-28 13:00:01 UTC
Reply
Permalink
Post by Petter Reinholdtsen
[WHR]
Post by WHR
None. I havn't started using git for it yet.
Right. Salsa might be the best choice, then. Did you get any response
from the Salsa admins?
They said to try register again. I'm waiting for account approval once again.
Post by Petter Reinholdtsen
Post by WHR
Uploaded at https://mentors.debian.net/package/mfiutil/
Look like the QA information list already got several suggestions for
improvements. In addition, some comments from me: Is there a reason for
the debhelper 11 level, or could it move to the latest 13? Also, the
Standards-Version should move to 4.7.0. I suspect the package
description should mention Dell PERC and perhaps other rebranded
editions of the LSI controller. Feel free to list me and Jérémy as
uploaders. A Appstream metainfo XML file should be added with the
relevant PCI ids listed.
The older versions is due to the package was initially created on a buster
system; will be moved to sid for sure.
WHR
2024-08-29 04:50:01 UTC
Reply
Permalink
Hello.

I have got an account at Salsa:
https://salsa.debian.org/Low-power/
Petter Reinholdtsen
2024-08-29 05:20:01 UTC
Reply
Permalink
[WHR]
Post by WHR
https://salsa.debian.org/Low-power/
Good to hear. I suggest you make the git repo under your own user as a
start. We can look at moving the repo somewhere else later if it make
sense.

(Btw, how did you come up with that user name?)
--
Happy hacking
Petter Reinholdtsen
WHR
2024-08-30 05:30:01 UTC
Reply
Permalink
Hi.

I will finalize the first release by tomorrow, assuming no additional issues
are found in the source tree.

I have updated the Debian packaging repo to the latest upstream version:
https://salsa.debian.org/Low-power/mfiutil/-/tree/master/

[Petter Reinholdtsen]
Post by Petter Reinholdtsen
(Btw, how did you come up with that user name?)
Well, it matches the name I used on other websites (sourceforge, github,
etc.), which I started using 14 years ago.
Petter Reinholdtsen
2024-08-30 06:50:01 UTC
Reply
Permalink
[WHR]
Post by WHR
I will finalize the first release by tomorrow, assuming no additional issues
are found in the source tree.
https://salsa.debian.org/Low-power/mfiutil/-/tree/master/
Good. Is the idea to use git-buildpackage? Do you plan to use
pristine-tar to be able to reproduce the orig.tar.gz file from the git
repo? I notice there is no pristine-tar branch there now.
--
Happy hacking
Petter Reinholdtsen
WHR
2024-08-30 07:10:01 UTC
Reply
Permalink
Post by Petter Reinholdtsen
Post by WHR
I will finalize the first release by tomorrow, assuming no additional issues
are found in the source tree.
https://salsa.debian.org/Low-power/mfiutil/-/tree/master/
Good. Is the idea to use git-buildpackage? Do you plan to use
pristine-tar to be able to reproduce the orig.tar.gz file from the git
repo? I notice there is no pristine-tar branch there now.
I didn't find much information about this; can you point me some
documentations / examples?
WHR
2024-08-31 08:10:01 UTC
Reply
Permalink
Post by Petter Reinholdtsen
Is the idea to use git-buildpackage?
No, I havn't used this.
Post by Petter Reinholdtsen
Do you plan to use
pristine-tar to be able to reproduce the orig.tar.gz file from the git
repo? I notice there is no pristine-tar branch there now.
I have just created a pristine-tar delta for the newly released upstream
source package. This command is pretty easy to use indeed.
Petter Reinholdtsen
2024-08-31 08:50:01 UTC
Reply
Permalink
[WHR]
Post by WHR
No, I havn't used this.
I tried building with 'gbp buildpackage --pristine-tar', but no success:

gbp:error: upstream/1.0.15-rivoreo-r1_rc-20240830-e8b284c is not a
valid treeish

I suspect I lack a tag. There are no tags in my clone, so I suspect you
forgot 'git push --tags'.
Post by WHR
I have just created a pristine-tar delta for the newly released
upstream source package. This command is pretty easy to use indeed.
Very good.

You might also want to create debian/gbp.conf looking like this to
enforce the use of pristine-tar:

[DEFAULT]
pristine-tar = True

Btw, do you know if uptream is in contact with the FreeBSD maintainers
of mfiutil? Look to me like there have been some updates on FreeBSD
that are not inlcuded in the Linux port.
--
Happy hacking
Petter Reinholdtsen
WHR
2024-08-31 09:00:01 UTC
Reply
Permalink
Post by Petter Reinholdtsen
I suspect I lack a tag. There are no tags in my clone, so I suspect you
forgot 'git push --tags'.
Yep.
Post by Petter Reinholdtsen
Btw, do you know if uptream is in contact with the FreeBSD maintainers
of mfiutil? Look to me like there have been some updates on FreeBSD
that are not inlcuded in the Linux port.
The only major update in FreeBSD source that's not included here, is the
support of their mrsas(4) driver; which has been implemented in this port in
a different way (which actually shares with the Linux support code).

Of course I will merge more future improvements from FreeBSD for next
releases.
Petter Reinholdtsen
2024-08-31 09:20:01 UTC
Reply
Permalink
[WHR]
Post by WHR
The only major update in FreeBSD source that's not included here, is
the support of their mrsas(4) driver; which has been implemented in
this port in a different way (which actually shares with the Linux
support code).
Of course I will merge more future improvements from FreeBSD for next
releases.
Good to know. What about passing code the other way? Among other
things, I notice there are lots of endian fixes in the Linux port that
are missing in the FreeBSD port. I guess it would be useful on big
endian FreeBSD machines.

Are you upstream for the Linux port?
--
Happy hacking
Petter Reinholdtsen
WHR
2024-08-31 09:30:01 UTC
Reply
Permalink
[Petter Reinholdtsen]
Post by Petter Reinholdtsen
Good to know. What about passing code the other way? Among other
things, I notice there are lots of endian fixes in the Linux port that
are missing in the FreeBSD port. I guess it would be useful on big
endian FreeBSD machines.
I would like to do so, but I don't think FreeBSD would accept the big-endian
fixes, because neither their mfi(4) nor mrsas(4) driver supports big-endian
hosts in first place.
Post by Petter Reinholdtsen
Are you upstream for the Linux port?
Yes.
WHR
2024-08-31 11:40:01 UTC
Reply
Permalink
Post by WHR
Post by Petter Reinholdtsen
Good to know. What about passing code the other way? Among other
things, I notice there are lots of endian fixes in the Linux port that
are missing in the FreeBSD port. I guess it would be useful on big
endian FreeBSD machines.
I would like to do so, but I don't think FreeBSD would accept the big-endian
fixes, because neither their mfi(4) nor mrsas(4) driver supports big-endian
hosts in first place.
I selected a few other fixes to submit to FreeBSD:
https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_file_loc=https%3A%2F%2Fsourceforge.net%2Fp%2Fmfiutil%2Fcode%2F&bug_file_loc_type=allwordssubstr&bug_status=__open__&bug_status=__closed__&email1=msl0000023508%40gmail.com&emailreporter1=1&emailtype1=substring&product=Base%20System&query_format=advanced
Petter Reinholdtsen
2024-08-31 17:40:01 UTC
Reply
Permalink
[WHR]
Post by WHR
I would like to do so, but I don't think FreeBSD would accept the
big-endian fixes, because neither their mfi(4) nor mrsas(4) driver
supports big-endian hosts in first place.
I guess you might be right, but only way to find out is to try. No idea
if the driver is also available on NetBSD, but if so, guess those might
be interested in endian neutral code.
Post by WHR
https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_file_loc=https%3A%2F%2Fsourceforge.net%2Fp%2Fmfiutil%2Fcode%2F&bug_file_loc_type=allwordssubstr&bug_status=__open__&bug_status=__closed__&email1=msl0000023508%40gmail.com&emailreporter1=1&emailtype1=substring&product=Base%20System&query_format=advanced
Nice. The more code shared with FreeBSD, the easier it is to know that
the code is well tested on more than one platform. :)

I was sad to learn that this tool do not use JBOD like the rest of us.
I would not call single disk RAID0 JBOD myself. :)

I suspect the tool is ready to go into the NEW queue, but would like to
hear from Jérémy on this.
--
Happy hacking
Petter Reinholdtsen
Petter Reinholdtsen
2024-09-05 21:50:01 UTC
Reply
Permalink
[Petter Reinholdtsen]
Post by Petter Reinholdtsen
I suspect the tool is ready to go into the NEW queue, but would like
to hear from Jérémy on this.
Jérémy, did you have time to check out the code?
--
Happy hacking
Petter Reinholdtsen
WHR
2024-09-10 02:40:01 UTC
Reply
Permalink
Hello.

It seems no activtiy in a while. Any progress?
Jérémy Lal
2024-09-10 05:50:01 UTC
Reply
Permalink
Post by WHR
Hello.
It seems no activtiy in a while. Any progress?
Oops, sorry, I just read that. I'm reading
https://salsa.debian.org/Low-power/mfiutil

1. Please use DEP-3 format for patches (missing at least Description,
Forwarded fields)
https://dep-team.pages.debian.net/deps/dep3/
Oddly lintian didn't pick that.

2. It would be nicer to have a debian/watch file

Thanks !
Petter Reinholdtsen
2024-09-10 06:10:01 UTC
Reply
Permalink
Very good to hear from you, Jérémy. Good catch on the patch format and
watch file. I had not noticed those.

I had a new look at the code, and found a typo:

diff --git a/debian/control b/debian/control
index e81ff95..f2e8fa6 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,7 @@ Description: Utility for managing LSI MegaRAID SAS controllers
MegaRAID SAS controllers, ported from FreeBSD.
.
It works with Linux megaraid_sas driver, and supports 2nd and later
- generations of MegaRAID SAS conntrollers.
+ generations of MegaRAID SAS controllers.
.
Examples of supported hardware:
* LSI MegaRAID SAS 92xx series

The debian/mfiutil.metainfo.xml file should probably go upstream, and
not only be a file under debian/. The file should be named based on the
value in component->id, ie 'rivoreo.mfiutil.metainfo.xml' when
installed. The ID should be in reverse DNS notation. Perhaps an ID
like net.sourceforge.mfiutil is better?

With these changes in place, I believe it should be ready to be uploaded
to Debian.
--
Happy hacking
Petter Reinholdtsen
WHR
2024-09-10 13:40:01 UTC
Reply
Permalink
[Jérémy Lal]
Post by Jérémy Lal
1. Please use DEP-3 format for patches (missing at least Description,
Forwarded fields)
https://dep-team.pages.debian.net/deps/dep3/
Oddly lintian didn't pick that.
2. It would be nicer to have a debian/watch file
Hi,

These has been imlemented on https://salsa.debian.org/Low-power/mfiutil

(Just realized last a few messages wasn't CC-ing Jérémy)
Jérémy Lal
2024-09-10 14:10:01 UTC
Reply
Permalink
[Jérémy Lal]
Post by Jérémy Lal
1. Please use DEP-3 format for patches (missing at least Description,
Forwarded fields)
https://dep-team.pages.debian.net/deps/dep3/
Oddly lintian didn't pick that.
2. It would be nicer to have a debian/watch file
Hi,
These has been imlemented on https://salsa.debian.org/Low-power/mfiutil
(Just realized last a few messages wasn't CC-ing Jérémy)
LGTM
Petter Reinholdtsen
2024-09-10 17:30:02 UTC
Reply
Permalink
So, lets upload? Jérémy, can you do it? Who got write access to the
repo?
--
Happy hacking
Petter Reinholdtsen
Jérémy Lal
2024-09-10 17:50:01 UTC
Reply
Permalink
So, lets upload? Jérémy, can you do it? Who got write access to the
repo?
I move it to
salsa.debian.org/debian/mfiutil
and updated Vcs-* fields in debian/control.

@WHR could you request access to that project ?

Meantime I'm uploading it.

Jérémy
Petter Reinholdtsen
2024-09-11 09:20:01 UTC
Reply
Permalink
Very good. I see from <URL: https://ftp-master.debian.org/new.html >
the upload succeded.
--
Happy hacking
Petter Reinholdtsen
Petter Reinholdtsen
2024-09-10 07:20:01 UTC
Reply
Permalink
I forgot to mention how to validate the Appstream XML:

appstreamcli validate-tree debian/mfiutil

When I run it on the current salsa git content, I get these:

mfiutil.metainfo.xml
E: rivoreo.mfiutil:3: cid-is-not-rdns rivoreo.mfiutil
W: rivoreo.mfiutil:~: metainfo-filename-cid-mismatch

✘ Validation failed: errors: 1, warnings: 1, pedantic: 1

The appstream XML parser will thus reject the content, so it need to be
fixed.
--
Happy hacking
Petter Reinholdtsen
WHR
2024-09-10 12:10:01 UTC
Reply
Permalink
The 'control' file and the patch has been updated accordingly.

[Petter Reinholdtsen]
Post by Petter Reinholdtsen
E: rivoreo.mfiutil:3: cid-is-not-rdns rivoreo.mfiutil
W: rivoreo.mfiutil:~: metainfo-filename-cid-mismatch
✘ Validation failed: errors: 1, warnings: 1, pedantic: 1
The appstream XML parser will thus reject the content, so it need to be
fixed.
I'm not very comfortable for using a rDNS name; because the TLD is subject to
change. I already experienced a TLD change for my organization domain name;
thankfully because I never used rDNS names in my programs, this isn't a big
problem.
Petter Reinholdtsen
2024-09-10 12:10:01 UTC
Reply
Permalink
[WHR]
Post by WHR
I'm not very comfortable for using a rDNS name; because the TLD is
subject to change. I already experienced a TLD change for my
organization domain name; thankfully because I never used rDNS names
in my programs, this isn't a big problem.
Please bring up your view with the group maintaining the Appstream
specification. As things stand right now, the Appstream metainfo XML
parser require it, so for the hardware mapping to make it into the
directory for use by isenkram and others, it need to be accepted by
'appstreamcli validate-tree'.
--
Happy hacking
Petter Reinholdtsen
WHR
2024-09-10 12:30:02 UTC
Reply
Permalink
[Petter Reinholdtsen]
Post by Petter Reinholdtsen
Please bring up your view with the group maintaining the Appstream
specification. As things stand right now, the Appstream metainfo XML
parser require it, so for the hardware mapping to make it into the
directory for use by isenkram and others, it need to be accepted by
'appstreamcli validate-tree'.
I understand that.

I have fixed the issue to make the validation pass; please check the latest
commit.

Or perhaps the rDNS name of the next level upstream can be used, eg.
org.freebsd.base.mfiutil. What do you think?
Petter Reinholdtsen
2024-09-10 12:50:01 UTC
Reply
Permalink
[WHR]
Post by WHR
I have fixed the issue to make the validation pass; please check the latest
commit.
Look good. :)
Post by WHR
Or perhaps the rDNS name of the next level upstream can be used, eg.
org.freebsd.base.mfiutil. What do you think?
As far as I understand Appstream, it only need to be unique string.
Given that it is a different code base, I suspect it should not use a
org.freebsd ID.
--
Happy hacking
Petter Reinholdtsen
WHR
2024-09-10 13:20:01 UTC
Reply
Permalink
[Petter Reinholdtsen]
Post by Petter Reinholdtsen
As far as I understand Appstream, it only need to be unique string.
Given that it is a different code base, I suspect it should not use a
org.freebsd ID.
Make sense. I will keep the current ID.

I just created a debian/watch file, available on Salsa; give it a review?
Petter Reinholdtsen
2024-09-10 13:30:01 UTC
Reply
Permalink
[WHR]
Post by WHR
I just created a debian/watch file, available on Salsa; give it a review?
'uscan -v' is happy, then I guess it is good. :)
--
Happy hacking
Petter Reinholdtsen
Loading...