ubuntu-bugcontrol team mailing list archive

[Vej <ubuntu@xxxxxxxxxxxxxxxx>]

Hello TJ,

thanks for your effort.

Could you provide another bug report where you worked on and did more communication with other users?

This is because I am having a bit of trouble with the evaluation criterion "Is the applicant respectful and tactful in their communications? ", mostly because most of the bugs you provided are created by yourself, which causes your comments to be more informative descriptions. I would like to see a bug, where you asked some average user for more informations or something like that.

Best regards

Vej


Am 09.11.2017 um 22:28 schrieb TJ:
> Once again I'm re-applying due to allowing my membership to lapse in
> August 2016 due to extensive offline commitments.
>
> I've returned to bug hunting in the last few weeks and would like to
> re-join.  The same thing happened in 2012 so I'm attaching the feedback
> I received then to give some context and history.
>
> 1. I'm always polite and cannot recall having a bad experience with a
> bug reporter. I signed the code of conduct in 2006.
>
> 2. I've read and understand the documentation and have practiced it for
> many years.
>
> 3. Sensitive data such as passwords, pass-phrases or personally
> identifying information (name, account numbers, digital certificate
> keys) can sometimes be found in stack-traces as data in function
> arguments or in the binary data of core dumps and in log files where
> verbose/debug logging by some packages is in operation; e.g.
> systemd.log_level=debug.
>
> 4. I tend to roam the packages tackling bugs that lack love or appear to
> be particularly challenging to analyse and trace. Sometimes they come to
> my attention due to affecting me; other times I might read about them in
> forums or mailing-lists or see them mentioned on IRC where I spend a lot
> of time providing support.
>
> 5. Bugs I've worked on. As well as triaging I generally go after the
> cause of the bug and document my research (for others to follow on) even
> if I can't provide a final bug-fix or work-around. Where I can provide a
> fix I'll publish a patch and debdiff or link a code branch and request
> an SRU where appropriate. My most recent bug activity has been
> relatively minor compared to my historic activity; hopefully it is
> sufficient to demonstrate my ability.
>
> 5.1 ycmd/vim-youcompleteme "[16.04] no autocomplete and multiple errors
> due to expecting different python-bottle version"
>     https://bugs.launchpad.net/ubuntu/+source/ycmd/+bug/1730731
>
>     I'd rate it as 'High', although as the apparent number of users
> (based on lack of bug reports) is approaching 1, maybe it'd be better as
> 'Medium'! This is a subtle Python package API change in python-bottle
> which masquerades as a python version incompatibility issue for
> python2/python3 with vim-nox and vim-youcompleteme ( a Python interface
> to YouCompleteMe - ycmd). For affected vim users it totally breaks
> vim-nox. I tracked related bugs and changes in Debian and discovered a
> patch proposal that solves the issue and added a debdiff to the report.
> I've asked Nish Aravamudan (nacc) to sponsor this.
>
> 5.2 linux/ecryptfs "BUG: unable to handle kernel NULL pointer
> dereference at 0000000000000030"
>      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1728771
>
>      A 'High' for me personally but "Medium" overall, because the
> overlayfs can be built but then processes that call on lower dir files
> are killed and the kernel BUGs. This is an apparently long-standing bug
> from at least v4.4 through v4.13 where ecryptfs as an upper dir in an
> overlayfs causes it. After creating a minimal reproduction test-case I
> reported it in LP and BKO and pointed Tyler Hicks to it who confirmed
> and is now dealing with it.
>
> 5.3 systemd/laptop-mode-tools "System fails to start (boot) on battery
> due to read-only root file-system"
>     https://bugs.launchpad.net/ubuntu/+source/laptop-mode-tools/+bug/1726930
>
>    This is definitely a High because of multiple severe init errors due
> the a conflict causing the rootfs to be returned to read-only mode.
> Based on 15 hours of intense debugging on IRC which eventually revealed
> a regression in systemd/laptop-mode-tools interactions. Removal of
> l.m.t. works around it but isn't ideal. Root cause appears to be the
> systemd developers keep changing the requirements for udev rules and
> long-running processes launched from them, and l.m.t. playing
> whack-a-mole trying to keep up. Ubuntu package versions got caught
> between whacks which broke the interaction. I still have work ongoing
> locally to reproduce it on a system here and figure out which package to
> fix!
>
> 5.4 powerline "default dependancy should be python3-powerline"
>     https://bugs.launchpad.net/hundredpapercuts/+bug/1575802
>
>    This is a Medium since it fails to work and throw out several errors
> for vim-nox on 16.04. One of several regressions due to the
> python2/python3 dependency switch in vim-nox. I've added a debdiff that
> simply adds "Recommends: python3-powerline" for the 16.04 package; this
> is what the 17.10 package is doing.
>
> 5.5 xserver-xorg-input-libinput "Xorg crashed with SIGABRT in
> libinput_device_config_tap_get_finger_count()"
>     https://bugs.launchpad.net/debian/+source/xorg-server/+bug/1655752
>
>   This is a Medium to High because it kills a locked GUI session with
> possible loss of unsaved application data. I didn't have a lot of time
> for this one but I tracked the root cause back to a NULL pointer due to
> an input device being removed and returning on a different input
> devname, found an upstream fix and backported it to prove the fix.