Bug#1061182: libsdl2: native gamecube controllers are unsupported because `--enable-hidapi-libusb` is not set

[Brian Smith]

Package: libsdl2
Version: 2.28.5+dfsg-3
Severity: wishlist
Tags: newcomer
X-Debbugs-Cc: 315kol...@mozmail.com

Dear Maintainer,

As of https://github.com/libsdl-
org/SDL/commit/c528615626d9f7789a5681a946cb3d5bd5d68c2c, SDL2 supports gamecube
controllers using the Switch/Wii U USB GameCube controller adapter. To use
this, however, one must build SDL using `--enable-hidapi-libusb`.

I was able to get this working on my machine by using apt source, editing the
`confflags` in `rules` to include `--enable-hidapi-libusb`, installing `libusb-
dev` and `libusb-1.0-0-dev`, and building with `dpkg-buildpackage`.

I'd love to hear any thoughts about adding `--enable-hidapi-libusb`.

Thank you so much for your time!

- Brian


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.11-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libsdl2-2.0-0 depends on:
ii  libasound2  1.2.10-3
ii  libc6   2.37-13
ii  libdecor-0-00.2.2-1
ii  libdrm2 2.4.120-1
ii  libgbm1 23.3.3-3
ii  libpulse0   16.1+dfsg1-3
ii  libsamplerate0  0.2.2-4
ii  libwayland-client0  1.22.0-2.1
ii  libwayland-cursor0  1.22.0-2.1
ii  libwayland-egl1 1.22.0-2.1
ii  libx11-62:1.8.7-1
ii  libxcursor1 1:1.2.1-1
ii  libxext62:1.3.4-1+b1
ii  libxfixes3  1:6.0.0-2
ii  libxi6  2:1.8-1+b1
ii  libxkbcommon0   1.6.0-1
ii  libxrandr2  2:1.5.2-2+b1
ii  libxss1 1:1.2.3-1

libsdl2-2.0-0 recommends no packages.

Versions of packages libsdl2-2.0-0 suggests:
ii  xdg-utils  1.1.3-4.1

-- no debconf information

Bug#1020957: RFP: gcadapter-oc-kmod -- Kernel module for overclocking the Nintendo Wii U/Mayflash GameCube adapter.

[Brian Smith]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: 51vd21...@mozmail.com

* Package name: gcadapter-oc-kmod
  Version : 1.4
  Upstream Author : Hannes Mann 
* URL : https://github.com/HannesMann/gcadapter-oc-kmod
* License : GPL
  Programming Lang: C
  Description : Kernel module for overclocking the Nintendo Wii U/Mayflash 
GameCube adapter.

Bug#919508: ITP: warewulf -- systems management suite for Linux clusters

[Brian Smith]

Hi Francesco,

On Sun, Jan 3, 2021 at 5:53 AM Francesco Poli  wrote:
>
> On Sat, 2 Jan 2021 14:08:45 -0600 Brian Smith  
> wrote:
>
> [...]
> > This fell by the wayside due to the reasons discussed in this bug.
> > Changing to RFP.
>
> That's very sad.
> Thanks anyway for starting the packaging effort.
>
> Is your incomplete work in progress stored somewhere (for instance in a
> public version control repository), so that other people interested can
> take advantage of what you have already done?

https://github.com/SystemFabricWorks/debian-warewulf3

The following build command works on stretch:

$ gbp buildpackage

I had intended to clean this up before publishing it. As far as the
current state is concerned, I believe it does provision debian stretch
-- to some degree.

>
> Is there a better alternative to warewulf?

For Debian, not that I am aware of. xCat seems to get a lot of
attention. I haven't used it, and the documentation says "Ubuntu".

> [Perceus] seems to be a basically dead project.
> I am not aware of any other similar systems...
> What are you currently using to manage an HPC cluster, if I may ask?
>

The cluster that I administrate is not production. That one is
"managed" through manual configuration of dhcpd, etc.

This begs the question : "Why don't I use my own packaging of
warewulf?" The packaging wasn't completed and the requirements for
this cluster change on a regular basis. The lack of interest in
warewulf discouraged me from going further down that road.

Wish i had a better answer for you.

> [Perceus]: see <http://moo.nac.uci.edu/~hjm/Perceus-Report.html>
>
>
>
> --
>  http://www.inventati.org/frx/
>  There's not a second to spare! To the laboratory!
> . Francesco Poli .
>  GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
--
Brian T. Smith
System Fabric Works
Senior Principal Engineer
bsm...@systemfabricworks.com
GPG Key: 0xB3C2C7B73BA3CD7F

Bug#919508: ITP: warewulf -- systems management suite for Linux clusters

[Brian Smith]

Hi Francesco,

On Sat, Jan 2, 2021 at 4:34 AM Francesco Poli  wrote:
>
> Hello Brian,
> I wonder what's the status of the work in progress packaging of
> warewulf.
>
> I would be very happy to see it properly packaged and included in the
> official Debian main archive.
>
> Please let me know.
> Thank you for what you have done so far and for what you are doing!
>
>

This fell by the wayside due to the reasons discussed in this bug.
Changing to RFP.

> --
>  http://www.inventati.org/frx/
>  There's not a second to spare! To the laboratory!
> . Francesco Poli .
>  GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE



-- 
Brian T. Smith
System Fabric Works
Senior Principal Engineer
bsm...@systemfabricworks.com
GPG Key: 0xB3C2C7B73BA3CD7F

Bug#957468: Can this be closed?

[Brian Smith]

Can BTS #957468 be closed?

-- 
Brian T. Smith
System Fabric Works
Senior Principal Engineer
bsm...@systemfabricworks.com
GPG Key: 0xB3C2C7B73BA3CD7F

Bug#957468: libpsm2: ftbfs with GCC-10

[Brian Smith]

I have uploaded libpsm 11.2.185-1, which addresses this bug.

As requested, I'm leaving Bug #957468 open.

-- 
Brian T. Smith
System Fabric Works
Senior Principal Engineer
bsm...@systemfabricworks.com
GPG Key: 0xB3C2C7B73BA3CD7F

Bug#925141: Should rdma-core be a dependency of ibverbs-providers or libverb1

[Brian Smith]

On Thu, Mar 21, 2019 at 3:51 AM Christian Ehrhardt
 wrote:
>
> > ibverbs is provided by rdma-core project.
> > Is it a separate package in your case?
>
> No it is part of the same src package.
>
> > Yes, you need libmlx4, libmlx5 and libibverbs.
> > It is described in the doc:
> > http://doc.dpdk.org/guides/nics/mlx5.html#prerequisites
>
> Well that is the problem, we fulfill that prereq already.
> libmlx4, libmlx5 and libibverbs are installed by dependencies already
> and thought all the time that would be good enough.
>
> But we got told that we also need the package rdma-core [1] itself to
> be installed to be useful.
> That was a discussion with the subject "Please help us to verify DPDK
> 17.11.5 for Ubuntu 18.04/18.10" with Mellanox test people.
> Fortunately I keep you on CC on those - so maybe you can find it
> somewhere in your inbox and contact the other Mellanox people on that
> thread.
> After that you might help to translate their request into our terms please?
>
> The question is:
> a) what exactly is (binary package) rdma-core [1] needed for in that scenario
> b) if (a) would be generally true we wondered why it had to be a dep
> of the DPDK packages and not of e.g. libibverbs1 itself
> That is why we opened this bug for discussions
>
> [1]: https://packages.debian.org/sid/rdma-core
>

rdma-core configures modprobe for ib/rdma modules, installs some
helper daemons and installs some udev rules. It certainly makes
administration of the server an easier task, but it isn't *required*
when configuring a Debian server for rdma and user-space ibverbs.

Perhaps libibverbs should recommend rdma-core?

-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: 0xB3C2C7B73BA3CD7F

Bug#919508: ITP: warewulf -- systems management suite for Linux clusters

[Brian Smith]

Hi Roland,

On Thu, Jan 31, 2019 at 3:10 AM Roland Fehrenbacher  wrote:
>
> >>>>> "BS" == Brian Smith  writes:
>
> Hi Brian,
>
> while I appreciate your initiative, I'm a bit skeptical about the
> inclusion of warewulf in Debian for the following reasons:
>
> a) Development in the project has stalled for quite a while. It used to
> be basically a one-man show driven by Gregory M. Kurtzer who now runs a
> startup (https://www.sylabs.io/) pushing the singularity container
> software.
>

Agreed that the github repository is not seeing a lot of new development work.
They are responding to issues and incorporating pull requests. The warewulf
project doesn't look dead.

>
> b) The software is quite complex and involves system components which
> are rather security critical. Given that we cannot count on upstream
> concerning fixing security issues, I consider it a substantial risk that
> we might have a hard time struggling with critical security bugs.
>

The major security problem I found is the use of embedded software tarballs
that would not be receiving any security updates unless addressed specifically
by warewulf developers. The work I have done removes the warewulf dependency
upon the embedded tarballs and uses the binaries delivered by the
standard Debian
packages.

I'm still going through the scripts, so there my be glaring issues
that I'm not aware of.
Searching the web hasn't revealed any major security discussions
regarding warewulf.
If there is a link to such an article or you wish to specify what you
found, please let me
know.

>
> c) Given its complexity, the software is also rather involved
> concerning its packaging process. Hence, I believe it only makes sense to
> include it in Debian if there is a strong commitment from you and at
> least one other DD for the long-term maintenance.
>

I had hoped to share my work with the Debian community. If there is
little support
for including the package, then I agree that the ITP is a wasted effort.

> Because of these points I wouldn't be in favor of including warewulf in
> Debian. I looked at it myself about a possible inclusion in our own
> cluster OS Qlustar for a while, but didn't find it suitable for
> basically the above reasons.
>
> Please note, this is only my personal opinion and if the majority of the
> Debian HPC team thinks otherwise, I have no problem with it. I just
> think it's better to have this discussion now, rather than after you have
> done all the work and it possibly would have been in vain ...
>

Thanks for responding and bringing up your concerns. I'm having to do the
packaging and fixes already for my own project. Getting it fully vetted and
suitable for upload is, obviously, a much bigger effort.

>
> Cheers,
>
> Roland
>
> BS> Package: wnpp Severity: wishlist Owner: "Brian T. Smith"
> BS>  X-Debbugs-CC:
> BS> debian-de...@lists.debian.org, debian-...@lists.debian.org
>
> BS> * Package name : warewulf
> BS>   Version : 3.8.1 Upstream Author : Gregory M. Kurtzer
> BS>   
> BS> * URL : https://warewulf.lbl.gov/
> BS> * License : BSD-3-Clause-like
> BS>   Programming Lang: Perl, Bourne, Bash Description : Systems
> BS>   management suite for Linux clusters
>
> BS> Warewulf is an operating system management toolkit designed to
> BS> facilitate large scale deployments of systems on physical,
> BS> virtual and cloud-based infrastructures. It facilitates elastic
> BS> and large deployments consisting of groups of homogenous
> BS> systems.
>
> BS> Compute nodes are managed via the warewulf suite that is
> BS> installed to a head node. The head node executes services used
> BS> to provision the operating system to compute nodes, which
> BS> execute an iPXE agent.  The essential services are tftpd, dhcpd,
> BS> httpd and nfsd.  Warewulf consists of a set of scripts which
> BS> automate configuration of these services via a command-line
> BS> interface.
>
> BS> The upstream Warewulf source package includes embedded source
> BS> tarballs for parted, ipxe, e2fsprogs, busybox, libarchive and
> BS> unionfs. Thus, the upstream builds include binary code for these
> BS> packages that are already available for Debian. A goal of this
> BS> project is to remove these embedded packages from the build and
> BS> ship packages that target the "all" architecture.
>
> BS> Warewulf's upstream build also includes packaging of a compute
> BS> node initrd image, created from the embedded packages. The
> BS> Debian package will not include an initrd image. Rather, a
>   

Bug#919508: ITP: warewulf -- systems management suite for Linux clusters

[Brian Smith]

Package: wnpp
Severity: wishlist
Owner: "Brian T. Smith" 
X-Debbugs-CC: debian-de...@lists.debian.org, debian-...@lists.debian.org

* Package name: warewulf
  Version : 3.8.1
  Upstream Author : Gregory M. Kurtzer 
* URL : https://warewulf.lbl.gov/
* License : BSD-3-Clause-like
  Programming Lang: Perl, Bourne, Bash
  Description : Systems management suite for Linux clusters

Warewulf is an operating system management toolkit designed to
facilitate large scale deployments of systems on physical,
virtual and cloud-based infrastructures. It facilitates elastic
and large deployments consisting of groups of homogenous systems.

Compute nodes are managed via the warewulf suite that is installed
to a head node. The head node executes services used to provision
the operating system to compute nodes, which execute an iPXE agent.
The essential services are tftpd, dhcpd, httpd and nfsd.
Warewulf consists of a set of scripts which automate configuration
of these services via a command-line interface.

The upstream Warewulf source package includes embedded source
tarballs for parted, ipxe, e2fsprogs, busybox, libarchive and
unionfs. Thus, the upstream builds include binary code for
these packages that are already available for Debian. A goal
of this project is to remove these embedded packages from
the build and ship packages that target the "all" architecture.

Warewulf's upstream build also includes packaging of a compute
node initrd image, created from the embedded packages. The
Debian package will not include an initrd image. Rather, a
script to create the initrd image via mkinitramfs and custom
hooks will be used by the administrator to build the compute
node initrd image after installing warewulf to the head node.
This technique has the benefit of easing an administrator's
task of updating the initrd image, when necessary.

Warewulf is used by administrators who need to manage clusters
of linux computers, and also by those who need to deploy
operating system images over a LAN. I use it in my development
environment for these purposes.

I plan to maintain Warewulf within the debian-hpc team, of
which I am a member. As my role is Debian Maintainer, the initial
upload will require assistance from a sponsor.

Bug#919494: ITP: warewulf -- systems management suite for Linux clusters Inbox x

[Brian Smith]

Package: wnpp
Severity: wishlist
Owner: "Brian T. Smith" 

* Package name: warewulf
  Version : 3.8.1
  Upstream Author : Gregory M. Kurtzer 
* URL : https://warewulf.lbl.gov/
* License : BSD-3-Clause-like
  Programming Lang: Perl, Bourne, Bash
  Description : Systems management suite for Linux clusters

Warewulf is an operating system management toolkit designed to
facilitate large scale deployments of systems on physical,
virtual and cloud-based infrastructures. It facilitates elastic
and large deployments consisting of groups of homogenous systems.

Compute nodes are managed via the warewulf suite that is installed
to a head node. The head node executes services used to provision
the operating system to compute nodes, which execute an iPXE agent.
The essential services are tftpd, dhcpd, httpd and nfsd.
Warewulf consists of a set of scripts which automate configuration
of these services via a command-line interface.

The upstream Warewulf source package includes embedded source
tarballs for parted, ipxe, e2fsprogs, busybox, libarchive and
unionfs. Thus, the upstream builds include binary code for
these packages that are already available for Debian. A goal
of this project is to remove these embedded packages from
the build and ship packages that target the "all" architecture.

Warewulf's upstream build also includes packaging of a compute
node initrd image, created from the embedded packages. The
Debian package will not include an initrd image. Rather, a
script to create the initrd image via mkinitramfs and custom
hooks will be used by the administrator to build the compute
node initrd image after installing warewulf to the head node.
This technique has the benefit of easing an administrator's
task of updating the initrd image, when necessary.

Warewulf is used by administrators who need to manage clusters
of linux computers, and also by those who need to deploy
operating system images over a LAN. I use it in my development
environment for these purposes.

I plan to maintain Warewulf within the debian-hpc team, of
which I am a member. As my role is Debian Maintainer, the initial
upload will require assistance from a sponsor.

Bug#901578: opa-basic-tools

[Brian Smith]

> This is not the case with other Linux flavors, such as RHEL. Perhaps there is 
> a
> rules.d file that is missing?

For clarification, this statement was made regarding the
opa-basic-tools package delivered by Intel's IFS distribution for
RHEL.

RHEL's in-box opa-basic-tools exhibits the same behavior described by this bug.

-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: 0xB3C2C7B73BA3CD7F

Bug#910485: Confirm issue with libpsm2-2/11.2.68-1

[Brian Smith]

Hi Mehdi,


On Mon, Oct 29, 2018 at 4:48 AM Mehdi Dogguy  wrote:
>
> Sorry for not replying sooner.
>
> On 2018-10-20 17:54, Brian Smith wrote:
> > The change is in psm2_hal.c. It is a brand new file. Reference the
> > initialization loop at line 246.
> >
>
> Indeed. The solution described in the github issue looks very fine.
> Why not uploading it in Debian? It will solve a real issue for users
> (and reverse dependencies) while giving upstream more time to
> investigate it.
>
> --
> Mehdi

Thank you for looking it over. I'm still working with upstream to get
an approved patch. The proposed patch corrects the symptom that
resulted in this issue, but I can't guarantee it won't cause some
other aberrant behavior.

-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: 0xB3C2C7B73BA3CD7F

Bug#910485: Confirm issue with libpsm2-2/11.2.68-1

[Brian Smith]

The change is in psm2_hal.c. It is a brand new file. Reference the
initialization loop at line 246.

/* Optimization note:
   The following code attempts to initialize two different times:
   First time assumes that the driver is already up, and so it attempts to
   initialize with the loop control variable: wait, set to 0.
   The second time, when wait is set to 1, waits for the driver to come up.
   (When the parameter to: hfp_get_num_units() call below is 0,
   hfp_get_num_units() does not wait for the driver to come up.
   When the parameter is non-zero, the hfp_get_num_units() call below,
   will wait for the driver to come up.) */

It seems like this as addressing an edge case of handling dynamic
device creation or an early psm2 process at the expense of the more
common case where the device is created long before the psm2
application executes and psm2 should fail-fast if the device isn't
present.

psm2_ep_open() takes a timeout parameter via psm2_ep_open_opts. If
psm2_init() needs to wait for devices, then it seems like it should
also take a timeout parameter. That will need to happen upstream, I believe.
On Sat, Oct 20, 2018 at 4:28 AM Mehdi Dogguy  wrote:
>
> On 2018-10-19 19:53, Brian Smith wrote:
> > The problem occurs when the OFI psm2 provider invokes psm2_init() when
> > there are no hfi1 devices present on the system. The call chain
> > eventually invokes hfi1_wait_for_device() with a timeout of 0. That is
> > interpreted as 15000ms.
> >
>
> Actually, that part of the code didn't change at all. I was able to
> reproduce the issue, but I am not actually sure yet from where the
> regression is coming.
>
> --
> Mehdi



-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: 0xB3C2C7B73BA3CD7F

Bug#910485: Confirm issue with libpsm2-2/11.2.68-1

[Brian Smith]

Sorry for my late reply on this issue. The BTS notifications were sent
to spam. I'm looking into adjusting the filters.
-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: 0xB3C2C7B73BA3CD7F

Bug#910485: Confirm issue with libpsm2-2/11.2.68-1

[Brian Smith]

I have confirmed this behavior with libfabric1_1.6.1-5 and
libpsm2_11.2.68-1. There is no existing workaround for the problem,
other than downgrading libpsm2 to 10.3.58-2.

The problem occurs when the OFI psm2 provider invokes psm2_init() when
there are no hfi1 devices present on the system. The call chain
eventually invokes hfi1_wait_for_device() with a timeout of 0. That is
interpreted as 15000ms.

Mehdi filed upstream issue https://github.com/intel/opa-psm2/issues/33.

I am taking this up with Intel support, as a similar issue exists in
the IFS 10.8.0.0.204 RHEL distribution.

-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: 0xB3C2C7B73BA3CD7F

Bug#906485: libpsm2: FTBFS in buster/sid ('%s' directive output may be truncated)

[Brian Smith]

Greetings Santiago,

I have reproduced this issue and am investigating.

Regarding the reproducible build FTBFS, that appears to be an issue
with GNU assembler: build_path_captured_in_assembly_objects. I've been
scratching my head on that one. The only potential solution that I
have come up with is to convert the .S file to inline assembly.

On Fri, Aug 17, 2018 at 2:21 PM, Santiago Vila  wrote:
> Package: src:libpsm2
> Version: 10.3.58-1
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> I tried to build this package in buster but it failed:
>
> 
> [...]
>  debian/rules build-arch
> dh build-arch
>dh_update_autotools_config -a
>dh_autoreconf -a
>dh_auto_configure -a
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/<>'
> sed -e 's/@DEB_HOST_MULTIARCH@/x86_64-linux-gnu/g'  \
> -e 's/@PSM_LIB_VERSION@/1/g'\
> -e 's/@PSM_LIB_MAJOR@/1/g'  \
> debian/libpsm2-2-compat.postinst.in > debian/libpsm2-2-compat.postinst
> sed -e 's/@DEB_HOST_MULTIARCH@/x86_64-linux-gnu/g'  \
> -e 's/@PSM_LIB_VERSION@/1/g'\
> -e 's/@PSM_LIB_MAJOR@/1/g'  \
>
> [... snipped ...]
>
> gcc -g -O2 -fdebug-prefix-map=/<>=. 
> -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
> -Werror=format-security  -pthread -Wall -Werror -msse4.2 -D_DEFAULT_SOURCE 
> -D_SVID_SOURCE -D_BSD_SOURCE -O3 -g3 -Wp,-D_FORTIFY_SOURCE=2 -fpic -fPIC 
> -D_GNU_SOURCE -DNVALGRIND  -funwind-tables -Wno-strict-aliasing 
> -Wformat-security -I. -I/<>/include -I/<>/mpspawn 
> -I/<>/include/linux-x86_64 -I/usr/include/uapi 
> -I/<> -I/<>/opa/.. 
> -I/<>/opa/../ptl_ips /<>/opa/opa_debug.c -MM -MF 
> /<>/build_release/opa/opa_debug.d -MQ 
> /<>/build_release/opa/opa_debug.o
> gcc -g -O2 -fdebug-prefix-map=/<>=. 
> -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
> -Werror=format-security  -pthread -Wall -Werror -msse4.2 -D_DEFAULT_SOURCE 
> -D_SVID_SOURCE -D_BSD_SOURCE -O3 -g3 -Wp,-D_FORTIFY_SOURCE=2 -fpic -fPIC 
> -D_GNU_SOURCE -DNVALGRIND  -funwind-tables -Wno-strict-aliasing 
> -Wformat-security -I. -I/<>/include -I/<>/mpspawn 
> -I/<>/include/linux-x86_64 -I/usr/include/uapi 
> -I/<> -I/<>/opa/.. 
> -I/<>/opa/../ptl_ips -c /<>/opa/opa_debug.c -o 
> /<>/build_release/opa/opa_debug.o
> gcc -g -O2 -fdebug-prefix-map=/<>=. 
> -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
> -Werror=format-security  -pthread -Wall -Werror -msse4.2 -D_DEFAULT_SOURCE 
> -D_SVID_SOURCE -D_BSD_SOURCE -O3 -g3 -Wp,-D_FORTIFY_SOURCE=2 -fpic -fPIC 
> -D_GNU_SOURCE -DNVALGRIND  -funwind-tables -Wno-strict-aliasing 
> -Wformat-security -I. -I/<>/include -I/<>/mpspawn 
> -I/<>/include/linux-x86_64 -I/usr/include/uapi 
> -I/<> -I/<>/opa/.. 
> -I/<>/opa/../ptl_ips -c /<>/opa/opa_time.c -o 
> /<>/build_release/opa/opa_time.o
> gcc -g -O2 -fdebug-prefix-map=/<>=. 
> -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
> -Werror=format-security  -pthread -Wall -Werror -msse4.2 -D_DEFAULT_SOURCE 
> -D_SVID_SOURCE -D_BSD_SOURCE -O3 -g3 -Wp,-D_FORTIFY_SOURCE=2 -fpic -fPIC 
> -D_GNU_SOURCE -DNVALGRIND  -funwind-tables -Wno-strict-aliasing 
> -Wformat-security -I. -I/<>/include -I/<>/mpspawn 
> -I/<>/include/linux-x86_64 -I/usr/include/uapi 
> -I/<> -I/<>/opa/.. 
> -I/<>/opa/../ptl_ips -c /<>/opa/opa_proto.c -o 
> /<>/build_release/opa/opa_proto.o
> gcc -g -O2 -fdebug-prefix-map=/<>=. 
> -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
> -Werror=format-security  -pthread -Wall -Werror -msse4.2 -D_DEFAULT_SOURCE 
> -D_SVID_SOURCE -D_BSD_SOURCE -O3 -g3 -Wp,-D_FORTIFY_SOURCE=2 -fpic -fPIC 
> -D_GNU_SOURCE -DNVALGRIND  -funwind-tables -Wno-strict-aliasing 
> -Wformat-security -I. -I/<>/include -I/<>/mpspawn 
> -I/<>/include/linux-x86_64 -I/usr/include/uapi 
> -I/<> -I/<>/opa/.. 
> -I/<>/opa/../ptl_ips -c /<>/opa/opa_service.c -o 
> /<>/build_release/opa/opa_service.o
> gcc -g -O2 -fdebug-prefix-map=/<>=. 
> -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
> -Werror=format-security  -pthread -Wall -Werror -msse4.2 -D_DEFAULT_SOURCE 
> -D_SVID_SOURCE -D_BSD_SOURCE -O3 -g3 -Wp,-D_FORTIFY_SOURCE=2 -fpic -fPIC 
> -D_GNU_SOURCE -DNVALGRIND  -funwind-tables -Wno-strict-aliasing 
> -Wformat-security -I. -I/<>/include -I/<>/mpspawn 
> -I/<>/include/linux-x86_64 -I/usr/include/uapi 
> -I/<> -I/<>/opa/.. 
> -I/<>/opa/../ptl_ips -c /<>/opa/opa_utils.c -o 
> /<>/build_release/opa/opa_utils.o
> gcc -g -O2 -fdebug-prefix-map=/<>=. 
> -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
> -Werror=format-security  -pthread -Wall -Werror -msse4.2 -D_DEFAULT_SOURCE 
> -D_SVID_SOURCE -D_BSD_SOURCE -O3 -g3 -Wp,-D_FORTIFY_SOURCE=2 -fpic -fPIC 
> -D_GNU_SOURCE -DNVALGRIND  -funwind-tables -Wno-strict-aliasing 
> 

Bug#901578: opa-basic-tools

[Brian Smith]

Package: opa-basic-tools

Sorry for the dup message flood. I received a bounce message from BTS
and tried again. Total n00b.

-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: B3C2C7B73BA3CD7F

Bug#901578: opa-basic-tools

[Brian Smith]

Package: opa-basic-tools

This is caused by 0600 permissions on /dev/infiniband/umad0. See example below.

One item to consider... opaportconfig allows a user to take the port
up and down. In principle, this activity should require root
privilege. Giving go+rw access to umad0 will allow non-privileged
administration of the OPA port.

Perhaps the solution is to add an opareport group, sgid the reports
and apply 0660 perms on umad0? I'm not sure how well that idea would
sit with security folks.

Incidentally, the IFS installer does ask a question about allowing
nonprivileged access to umad.

bsmith@opa10:~$ ls -l /dev/infiniband/umad0
crw--- 1 root root 231, 0 Jun 14 17:31 /dev/infiniband/umad0
bsmith@opa10:~$ sudo chmod a+rw /dev/infiniband/umad0
bsmith@opa10:~$ /usr/sbin/opafabricinfo
Fabric 0:0 Information:
SM: opa4 hfi1_0 Guid: 0x0011750101675b33 State: Master
Number of HFIs: 5
Number of Switches: 1
Number of Links: 5
Number of HFI Links: 5  (Internal: 0   External: 5)
Number of ISLs: 0   (Internal: 0   External: 0)
Number of Degraded Links: 0 (HFI Links: 0   ISLs: 0)
Number of Omitted Links: 0  (HFI Links: 0   ISLs: 0)
---
bsmith@opa10:~$



-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: B3C2C7B73BA3CD7F

Bug#901578: reL opa-basic-tools: reports require root access Inbox

[Brian Smith]

This is caused by 0600 permissions on /dev/infiniband/umad0. See example below.

One item to consider... opaportconfig allows a user to take the port
up and down. In principle, this activity should require root
privilege. Giving go+rw access to umad0 will allow non-privileged
administration of the OPA port.

Perhaps the solution is to add an opareport group, sgid the reports
and apply 0660 perms on umad0? I'm not sure how well that idea would
sit with security folks.

Incidentally, the IFS installer does ask a question about allowing
nonprivileged access to umad.

bsmith@opa10:~$ ls -l /dev/infiniband/umad0
crw--- 1 root root 231, 0 Jun 14 17:31 /dev/infiniband/umad0
bsmith@opa10:~$ sudo chmod a+rw /dev/infiniband/umad0
bsmith@opa10:~$ /usr/sbin/opafabricinfo
Fabric 0:0 Information:
SM: opa4 hfi1_0 Guid: 0x0011750101675b33 State: Master
Number of HFIs: 5
Number of Switches: 1
Number of Links: 5
Number of HFI Links: 5  (Internal: 0   External: 5)
Number of ISLs: 0   (Internal: 0   External: 0)
Number of Degraded Links: 0 (HFI Links: 0   ISLs: 0)
Number of Omitted Links: 0  (HFI Links: 0   ISLs: 0)
---
bsmith@opa10:~$

-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: B3C2C7B73BA3CD7F

Bug#901578: opa-basic-tools: reports require root access Inbox

[Brian Smith]

Package: opa-basic-tools

This is caused by 0600 permissions on /dev/infiniband/umad0. See example below.

One item to consider... opaportconfig allows a user to take the port
up and down. In principle, this activity should require root
privilege. Giving go+rw access to umad0 will allow non-privileged
administration of the OPA port.

Perhaps the solution is to add an opareport group, sgid the reports
and apply 0660 perms on umad0? I'm not sure how well that idea would
sit with security folks.

Incidentally, the IFS installer does ask a question about allowing
nonprivileged access to umad.

bsmith@opa10:~$ ls -l /dev/infiniband/umad0
crw--- 1 root root 231, 0 Jun 14 17:31 /dev/infiniband/umad0
bsmith@opa10:~$ sudo chmod a+rw /dev/infiniband/umad0
bsmith@opa10:~$ /usr/sbin/opafabricinfo
Fabric 0:0 Information:
SM: opa4 hfi1_0 Guid: 0x0011750101675b33 State: Master
Number of HFIs: 5
Number of Switches: 1
Number of Links: 5
Number of HFI Links: 5  (Internal: 0   External: 5)
Number of ISLs: 0   (Internal: 0   External: 0)
Number of Degraded Links: 0 (HFI Links: 0   ISLs: 0)
Number of Omitted Links: 0  (HFI Links: 0   ISLs: 0)
---
bsmith@opa10:~$

Bug#898951: RFS: ibus-kmfl/1.0.8-1 [ITP] -- Please help me for upstream

[Brian Smith]

By the way, you should build with pbuilder to make sure all of your build
dependencies are specified.


On Thu, May 17, 2018 at 1:08 PM, Brian Smith <bsm...@systemfabricworks.com>
wrote:

> I'm not a DD or DM, but here are my comments.
>
> 1) d/README.source and d/README.Debian are not required and should have
> something of consequence in them. The trivial versions that you have
> provided should be removed or updated with useful information.
> 2) uscan doesn't work, so d/watch needs to be fixed.
> uscan warn: In debian/watch no matching files for watch line
>   http://sf.net/p/kmfl/ ibus-kmfl-(.*)\.tar\.gz debian uupdate
> 3) configure complains about a missing ibus package, so it looks like
> d/control needs a Build-Depends update.
> 4) d/control Description could use improvement. Does upstream provide a
> description, possibly in .spec file? My advice is to use that, if available.
>
>
>
>
>
> On Thu, May 17, 2018 at 12:43 PM, kokoye2007 <kokoye2...@gmail.com> wrote:
>
>> Package: sponsorship-requests
>> Severity: normal
>>
>> Dear Maintainer, Mentor and Developer
>>
>>  I am looking for a sponsor for my package "ibus-kmfl"
>>
>>  please improve for my package and allow to upload upstream.
>>  i am follow DFSG and SC, now i am waiting 4 software package.
>>  when i become DD or DM, i will more support at mentor :'(
>>
>>  * Package name: ibus-kmfl
>>Version : 1.0.8-1
>>Upstream Author : kokoye2007 <kokoye2...@gmail.com>
>>  * URL : https://kmfl.sf.net
>>  * License : gpl2
>>Section : utils
>>
>>   It builds those binary packages:
>>
>> ibus-kmfl  - ibus kmfl for linux its windows keyman
>>
>>   To access further information about this package, please visit the
>> following URL:
>>
>>   https://mentors.debian.net/package/ibus-kmfl
>>
>>
>>   Alternatively, one can download the package with dget using this
>> command:
>>
>> dget -x https://mentors.debian.net/debian/pool/main/i/ibus-kmfl/ibus
>> -kmfl_1.0.8-1.dsc
>>
>>
>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers bionic-updates
>>   APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500,
>> 'bionic-proposed'), (500, 'bionic')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 4.15.0-21-generic (SMP w/4 CPU cores)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>>
>
>
> --
> Brian T. Smith
> System Fabric Works
> Senior Technical Staff
> bsm...@systemfabricworks.com
> GPG Key: B3C2C7B73BA3CD7F
>



-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: B3C2C7B73BA3CD7F

Bug#898951: RFS: ibus-kmfl/1.0.8-1 [ITP] -- Please help me for upstream

[Brian Smith]

I'm not a DD or DM, but here are my comments.

1) d/README.source and d/README.Debian are not required and should have
something of consequence in them. The trivial versions that you have
provided should be removed or updated with useful information.
2) uscan doesn't work, so d/watch needs to be fixed.
uscan warn: In debian/watch no matching files for watch line
  http://sf.net/p/kmfl/ ibus-kmfl-(.*)\.tar\.gz debian uupdate
3) configure complains about a missing ibus package, so it looks like
d/control needs a Build-Depends update.
4) d/control Description could use improvement. Does upstream provide a
description, possibly in .spec file? My advice is to use that, if available.





On Thu, May 17, 2018 at 12:43 PM, kokoye2007  wrote:

> Package: sponsorship-requests
> Severity: normal
>
> Dear Maintainer, Mentor and Developer
>
>  I am looking for a sponsor for my package "ibus-kmfl"
>
>  please improve for my package and allow to upload upstream.
>  i am follow DFSG and SC, now i am waiting 4 software package.
>  when i become DD or DM, i will more support at mentor :'(
>
>  * Package name: ibus-kmfl
>Version : 1.0.8-1
>Upstream Author : kokoye2007 
>  * URL : https://kmfl.sf.net
>  * License : gpl2
>Section : utils
>
>   It builds those binary packages:
>
> ibus-kmfl  - ibus kmfl for linux its windows keyman
>
>   To access further information about this package, please visit the
> following URL:
>
>   https://mentors.debian.net/package/ibus-kmfl
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x https://mentors.debian.net/debian/pool/main/i/ibus-kmfl/
> ibus-kmfl_1.0.8-1.dsc
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic-updates
>   APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500,
> 'bionic-proposed'), (500, 'bionic')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-21-generic (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>


-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: B3C2C7B73BA3CD7F

Bug#862754: ITP: libhfi1 -- Userspace driver for Intel Omni-Path fabric interface

[Brian Smith]

I have since learned from Jason Gunthorpe that the upstream URL is
https://github.com/linux-rdma/rdma-core. The current version of that source
is 14-1.

Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
(512) 293-4472
GPG Key: B3C2C7B73BA3CD7F

On Tue, May 16, 2017 at 11:54 AM, Brian T. Smith <
bsm...@systemfabricworks.com> wrote:

> Package: wnpp
> Severity: wishlist
> Owner: "Brian T. Smith" 
>
> * Package name: libhfi1
>   Version : 0.5-23
>   Upstream Author : Intel Corporation 
> * URL : http://www.intel.com
> * License : GPL or BSD
>   Programming Lang: C
>   Description : Userspace driver for Intel Omni-Path fabric interface
> (HFI1).
>
> libhfi1 is a device-specific driver for Intel Omni-Path fabric
> interface hardware for the libibverbs library. This allows
> userspace processes to access the HFI1 hardware directly with
> low latency and low overhead.
> .
> This package contains the loadable plug-in.
> .
> I am an employee of System Fabric Works. SFE has the experience,
> hardware and resources to maintain and test this package.
>

Bug#862374: RFS: hfi1-firmware/0.9-50-2

[Brian Smith]

Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "hfi1-firmware"

 * Package name: hfi1-firmware
   Version : 0.9-50-2
   Upstream Author : Intel Corporation
 * URL : https://downloadcenter.intel.com/
 * License : Proprietary
   Section : non-free/misc

  It builds these binary packages:

hfi1-firmware - Firmware for Gen1 HFI
hfi1-firmware-debug - Firmware for Gen1 HFI (debug)

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/hfi1-firmware


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/non-free/h/hfi1-firmware/hfi1-firmware_0.9-50-2.dsc

  More information about hfi1-firmware can be obtained from
https://github.com/SystemFabricWorks/hfi1-firmware.

  Changes since the last upload:

   * Changed section from misc to non-free/misc.
   * Corrected name of copyright file in package description.

  Regards,
   Brian T. Smith

Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
(512) 293-4472
GPG Key: B3C2C7B73BA3CD7F