ubuntu-bugcontrol team mailing list archive

[Brian Murray <brian@xxxxxxxxxx>]

I've added you to the team again, welcome back!

Brian

On Fri, Mar 02, 2018 at 09:00:36PM +0000, TJ wrote:
> 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 <brian@xxxxxxxxxx> 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     : ubuntu-bugcontrol@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol
> More help   : https://help.launchpad.net/ListHelp
>

Attachment: signature.asc
Description: PGP signature