$ dpkg-query -L nav | grep snmputils.py
- /usr/share/pyshared/nav/portadmin/snmputils.py
- /usr/lib/python2.7/dist-packages/nav/portadmin/snmputils.py
$ patch --dry-run /usr/share/pyshared/nav/portadmin/snmputils.py < 1625.diffbut it seems there's an error
- checking file /usr/share/pyshared/nav/portadmin/snmputils.py
- The next patch would create the file /usr/share/pyshared/nav/portadmin/snmputils.py,
- which already exists! Assume -R? [n] y
- checking file /usr/share/pyshared/nav/portadmin/snmputils.py
- Hunk #1 FAILED at 1.
- Not deleting file /usr/share/pyshared/nav/portadmin/snmputils.py as content differs from patch
- 1 out of 1 hunk FAILED
- checking file /usr/share/pyshared/nav/portadmin/snmputils.py
- Hunk #1 FAILED at 576.
- 1 out of 1 hunk FAILED
- checking file /usr/share/pyshared/nav/portadmin/snmputils.pybut it seems there's also an error
- The next patch would create the file /usr/share/pyshared/nav/portadmin/snmputils.py,
- which already exists! Assume -R? [n]
- Apply anyway? [n] y
- checking file /usr/share/pyshared/nav/portadmin/snmputils.py
- Hunk #1 FAILED at 1.
- 1 out of 1 hunk FAILED
- checking file /usr/share/pyshared/nav/portadmin/snmputils.py
- Hunk #1 FAILED at 576.
- 1 out of 1 hunk FAILED
- checking file /usr/share/pyshared/nav/portadmin/snmputils.pyno luck
- The next patch would create the file /usr/share/pyshared/nav/portadmin/snmputils.py,
- which already exists! Assume -R? [n]
- Apply anyway? [n]
- Skipping patch.
- 1 out of 1 hunk ignored
- checking file /usr/share/pyshared/nav/portadmin/snmputils.py
- Hunk #1 FAILED at 576.
- 1 out of 1 hunk FAILED
$ dpkg-query -L nav | grep dnos_switching_mib.pybut no answer
Ok, the patch is located at: https://patch-diff.githubusercontent.com/raw/UNINETT/nav/pull/1625.diff and can be applied using the instructions kindly written by Espen Lorentzen here: https://sympa.uninett.no/lists/uninett.no/arc/nav-users/2017-08/msg00020.html On 30. nov. 2017 10:31, Vinsonnaud Ludovic wrote:Here's a new answer from Dell*snip*/The customer request is to modify the vlan ID of an interface already on access mode, for me this OID should be used to do that, if you have the possibility to implement it and test it.That is done, good.By the way, if you’re also interested to modify a vlan ID of an interface configured as mode general, you will need also to modify the “allow” parameter :We have not implemented support for general mode. However trunk mode should work. cheers