Re: Bug#901578: opa-basic-tools
- To: Brian Smith <email@example.com>
- Cc: debian-hpc <firstname.lastname@example.org>
- Subject: Re: Bug#901578: opa-basic-tools
- From: Mehdi Dogguy <email@example.com>
- Date: Sun, 02 Dec 2018 12:14:33 +0100
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <CAC=5+HrOeM1b5=wFzSwjk2-q_GKNAXUSr2N=n8QqbTau72a67A@mail.gmail.com>
- References: <email@example.com> <CAC=5+Hqeub072ywe7uKvNfnhypFvU3GkA+5fvNuZZPs3xYYjEA@mail.gmail.com> <CAC=5+Hp4oV8BUK0+yZ=_cmJkzxPpRqT8uTTAiAvoqEqaeLVQCw@mail.gmail.com> <CAC=5+HrOeM1b5=wFzSwjk2-q_GKNAXUSr2N=n8QqbTau72a67A@mail.gmail.com>
Sorry for not replying sooner.
On 2018-11-09 22:22, Brian Smith wrote:
Hi debian-hpc people,
On Thu, Nov 8, 2018 at 3:18 PM 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's in-box opa-basic-tools exhibits the same behavior described by
Does anyone have thoughts on this bug? It blocks opa-ff from migrating
Similarly to how other network interfaces are managed, I do not think it
desirable to give regular users ability to manage opa network
is up to the system administrator to fine-tune that if he wishes so.
I agree with your conclusion in the bugreport.
I have a minor remark about handling such bugreports in Debian's BTS
is nothing intuitive about this): Since there is no bug in the package
and no fix
was integrated, the bug should not be marked as fixed in -2. BTS's way
such cases is to:
1) mark this bugreport as "not found" in version
2) tag it "wontfix"
3) close the bugreport, with an explanation.
#901578 is only missing step 1 (modulo removing the annotation about the
version, i.e. -2).