I sent this originally on 9th November 2017 but have had no reply and having just checked don't see it in the mailing-list archive!
Once again I'm re-applying due to allowing my membership to lapse in August 2016 due to extensive offline commitments. https://launchpad.net/~tj 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. My previous return: On 04/05/12 13:28, C de-Avillez wrote: > On Thu, 3 May 2012 16:15:44 -0700 > Brian Murray <[email protected]> wrote: > >> On Tue, May 01, 2012 at 09:25:04PM +0100, TJ wrote: >>> Due to other commitments I allowed my membership (2006-2010) of the >>> bugcontrol team to lapse some time ago. I'm now in a position to >>> devote time to bug-control once more and am therefore requesting >>> membership. >>> >>> 1. I'm always polite and cannot recall ever having a bad experience >>> with a bug reporter. I signed the code of conduct in 2006. >>> >>> 2. I have read and understand the documentation and have applied it >>> extensively to bugs over a long period of time. I've re-read it now >>> to ensure I'm up to date. >>> >>> 3. Sensitive data such as passwords 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. >>> >>> 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. >>> >>> 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. >>> >>> 5.1. HIGH. [Precise] sudo. Abort in libpam-mount due to >>> pam_open_session() not being called. >>> >>> Analysis and tracing revealed this as a high importance bug because >>> it shows that sudo was not calling pam_open_session() when a valid >>> cached timestamp was present. This could theoretically expose new >>> vectors for privilege escalation. >>> >>> https://launchpad.net/bugs/927828 >>> >>> 5.2 NORMAL/HIGH. [Lucid] ubuntuone-client. Ubuntuone-client software >>> wont start. >>> >>> This was an 'annoyance' bug but also very visible to affected users >>> since it prevented access to ubuntu-one. I delved into the Python >>> code and identified a coding problem, published a corrective >>> workaround, and alerted the Ubuntu One team. >>> >>> https://launchpad.net/bugs/666608 >>> >>> 5.3 HIGH. [Oneiric, Precise] mountall. could not mount >>> /dev/mapper/cryptswap1 >>> >>> This was a high importance bug that prevented encrypted swap being >>> mounted during boot. I was able to figure out a method of tracing >>> the early start-up to aid running and monitoring the processes >>> manually. That led to revealing one underlying cause (there were >>> two). I was able to develop a fix which was polished by Steve >>> Langasek. It also caused me to write analysis scripts to determine >>> the most efficient patch. It turned out the bug report covered 2 >>> distinctly different problems which masked each other. >>> >>> https:/launchpad.net/bugs/874774 >>> >>> 5.4 HIGH. [Oneiric] casper, upstart. PXE/NFS boot requires "IPAPPEND >>> 2" in PXE menus >>> >>> For those affected this is of high or critical importance since it >>> caused a failure to boot of PXE clients. This affected my network >>> so I was the original reporter too. A simple report detailing a >>> package which broke existing functionality after upgrade without >>> any warning. This would mainly affect network and systems >>> administrators. >>> >>> https://launchpad.net/bugs/923219 >>> >>> 5.5 HIGH. [Feisty onwards] apache2 2.1.5+. TCP_DEFER_ACCEPT causes >>> random HTTP connection failures in load-balanced web-server farms >>> >>> In a web server-farm scenario that is fronted by hardware >>> load-balancers, in this case Juniper Redline aka DX, where the >>> load-balancers are configured to use TCP multiplexing (holding open >>> and re-using HTTP connections to the web servers) there exists the >>> potential for random, unexplained and untraceable connection >>> failures. >>> >>> This bug was high priority for the e-commerce retailer since it >>> affected payment transactions amongst other things. I spent over a >>> week working on it, writing custom C tools and custom kernels, >>> until I was able to finally identify the cause (weakly written >>> standards and poor implementation) and suggest a fix (a one line >>> Apache config change). >>> >>> https://launchpad.net/bugs/134274 >> While these bugs aren't the typical sort of triage that we see your >> research into the bugs is phenomenal. Additionally, I recall your >> previous work and would be happy to have you back in the team. >> >> Barring any objections I'll add you next week. > +1 > > ..C.. _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
