[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

mining system information of bugs



Hi, cat staff and useless humies!

I've done some data mining on bug reports that include a "System
Information" section that reportbug adds.

This information is notoriously corrupted and/or includes write-in stuff.  I
tried to do my best to recover data when it could be done unambigously; many
corruptions are obvious (like "=" -> up to "=3D3D3D"), others are mangled
beyond recognition.  All the percentages below thus use non-null non-"unable
to determine"/etc count as 100%.  The data is up to bug #850909 filed
2017-01-11 05:39:02 (took me a while to write this, sorry).

Graphs below might be unreadable if your mail client's chosen font lacks the
U+2800..U+28FF range, and fallback font is pre-stretch FreeFont Mono; this
is the case for libvt terminals on the default install.  The prose should be
enough, I hope.



+=========+
| ᴄʜᴀʀᴍᴀᴘ |
+=========+
The main thing I was looking for is the use ratio of ancient locales. 
Here's the graph of "charmap" field other than UTF-8, excluding unconfigured
(aka C) (mojibake->mojibake is no regression).  As reportbug started
including charmap information late, a good part of the transition is lost
-- Oct 2004 already has 43% UTF-8.

max=51%; X scale: month
⠀⠀⢠⠀⠀⠀⣀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⣄⣾⠀⠀⣦⣿⣿⡄⠀⡆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⢠⣿⣿⣄⡇⣿⣿⣿⡇⠀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣷⣿⣿⣿⣇⡄⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⡇⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣷⡇⡀⢀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣷⢸⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣸⣿⣀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣶⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣧⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣾⣧⣤⣶⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡇⡀⠀⠀⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣷⣤⣾⣇⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣧⣿⣦⣠⣷⣄⣰⣠⡀⢀⠀⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣷⣾⣷⣷⣠⡀⠀⠀⡀⢸⣿⡄⠀⠀⠀⠀⠀⡄⣠⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣾⣿⣾⣿⣿⣶⣴⣤⣠⣷⣷⣿⣧⣰⣴⡄⣤⣀⣀⣀⣀⣠⣄⣀⣄⢀⢰⡀⣀⣀⣀⢀
Oct 2004                                                          Jan 2017

Enlarged:
max=7%; X scale: month
⠀⡄⡆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⣿⡇⠀⠀⠀⠀⠀⠀⠀⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⣿⣧⠀⠀⠀⠀⠀⢰⢀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⡀⣿⣿⡄⠀⠀⠀⢰⢸⢸⣿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣷⣿⣿⣷⡆⡄⠀⢸⣸⣸⣿⠀⡀⡄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡄⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣷⣿⡆⣿⣿⣿⣿⡄⣿⣷⢠⡄⢠⠀⡀⡀⣦⠀⢰⠀⠀⡇⠀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣼⣷⣿⣿⣿⣿⣿⣿⣾⣦⣧⣿⣼⣶⣶⣆⡆
Jan 2012               Jan 2017
Avg for 2016+: 0.8%.



+======+
| ɪɴɪᴛ |
+======+
While, as expected, releases that defaulted to sysvinit get gradually
replaced, resulting in a downwards trend, things look differently if we
look at unstable only: after a forced transition (much of which is again
lost because of system information added late), somewhere around the start
of 2016 it plateaued and didn't move except for noise since.

17 reports with upstart and 4 with runit are a rounding error.

max=44%; X scale: week
⠀⣇⠀⢰⠀⡆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⣿⠀⢸⢸⡇⠀⠀⠀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⣿⢰⣾⣸⣷⠀⠀⠀⡇⠀⡆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⣿⢸⣿⣿⣿⠀⡆⠀⡇⠀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⢠⣿⣿⣿⣿⣿⠀⡇⢀⡇⡀⡇⠀⠀⠀⠀⠀⠀⡄⠀⡇⠀⠀⢠⠀⠀⠀⠀⠀⠀⠀⡇⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⣼⣿⣿⣿⣿⣿⠀⣿⣼⡇⣧⣧⡀⡀⠀⠀⡀⠀⡇⡆⣧⠀⡄⢸⠀⢸⠀⠀⢀⠀⠀⡇⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡆⠀⠀⡀⠀⠀⠀⢀⠀⠀⠀⠀
⣿⣿⣿⣿⣿⣿⣦⣿⣿⣿⣿⣿⣇⡇⡇⡄⣿⠀⣧⡇⣿⡇⡇⢸⡇⢸⡀⠀⣾⡆⠀⡇⢸⣠⢸⠀⠀⣤⠀⠀⠀⡀⠀⠀⡇⠀⠀⡇⠀⠀⡄⣾⡀⡄⠀⡆
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡇⣿⣷⣿⣤⣿⣧⣿⣷⡇⢸⣿⣼⡇⡀⣿⣿⣤⣷⣾⣿⢸⡇⡆⣿⣠⡇⡄⣿⡄⢠⡇⡆⠀⣧⣠⠀⡇⣿⡇⡇⣤⡇
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣷⣿⣿⣿⣿⣿⣿⣿⣿⡇⣿⣿⣿⣧⣷⣿⣿⣿⣿⣿⣿⣼⡇⣷⣿⣿⣿⣷⣿⣧⣼⣇⣧⡆⣿⣿⣴⡇⣿⡇⡇⣿⡇
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣷⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣇⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣇⣿⣿⣿⣧⣿⣇⣷⣿⡇
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⡇
Dec 2014                     ↑                  Jan 2017
Avg for 2016+: 14%.



+=======+
| ꜱʜᴇʟʟ |
+=======+
It's /bin/sh not the interactive shell -- that's what reportbug says.

        2014    2015    2016+
-----+-------+-------+-------+
dash   15316   12509   12296
bash    1505     823     705
lksh      83      75      80
mksh      21      13
zsh        1



+==========+
| ʟᴀɴɢᴜᴀɢᴇ |
+==========+
2016+:

 en    | 7307
 de    | 1753
 fr    | 1316
 C     | 1028
 es    |  275
 it    |  229
 ru    |  212
 POSIX |  170
 ja    |  151
 pt    |  107
 pl    |   99
 zh    |   80
 fi    |   51
 nl    |   50
 cs    |   41
 el    |   24
 bg    |   21
 hu    |   21
 ca    |   17
 da    |   17
 sv    |   17
 nb    |   13
 he    |   12
 sl    |    9
 gl    |    8
 ro    |    8
 is    |    6
 sk    |    6
 eu    |    5
 be    |    4
 lt    |    4
 ml    |    4
 ar    |    3
 th    |    3
 uk    |    3
 fo    |    2
 ia    |    2
 id    |    2
 mn    |    2
 nn    |    2
 tr    |    2
 eo    |    1
 et    |    1
 ko    |    1
 nds   |    1
 zen   |    1



+======+
| ᴀʀᴄʜ |
+======+
Reportbug reports architecture as "arch (uname -m)" (no parentheses if both
are the same); there's a bunch of reports with "uname -m" -- I guess some
derivative produces them this way.

2016+:

amd64           11558
i386            1124    (i686 881, x86_64 229, i586 14)
armhf           110     (armv7l 106, armv6l 1, aarch64 1, qemu 2)
x32             58
kfreebsd-amd64  52
powerpc         42      (ppc 33, ppc64 9)
hppa            34
armel           26      (armv5tel 25, armv6l 1)
arm64           19      (aarch64 18, qemu 1)
hurd-i386       16
ppc64el         15
mips64el        6
sparc64         6
mipsel          5       (mips64 4, mips 1)
kfreebsd-i386   4
mips            4       (mips64 2, qemu 2)
s390x           2
ppc64           1
ia64            1
Mangled/derivative:
x86_64          48
armv7l          27
armv6l          9
i686            9



+===============+
| ꜰᴏʀᴇɪɢɴ ᴀʀᴄʜꜱ |
+===============+
Lots of noise, thus only tidbits.  2016+:

57% of amd64 have i386.

Only 148 of i386 have amd64, despite 229 (per above) running an amd64
kernel.  Shouldn't they do upgrades?



+=========+
| ɴᴏɴ-SMP |
+=========+
No way to reliably tell apart single-CPU machines/VMs from mangled and
write-ins.  The 2016+ count is, with this caveat:

 amd64 (x86_64)    |  66
 powerpc (ppc)     |  29
 i386 (i686)       |  26
 armel (armv5tel)  |  25
 i386 (i586)       |  12
 armv6l            |   9
 mips64el (mips64) |   4
 mipsel (mips64)   |   4
 armhf (armv7l)    |   3
 armel (armv6l)    |   1
 i386 (x86_64)     |   1
 armhf             |   1
 i686              |   1
 armhf (armv6l)    |   1
 mips (mips64)     |   1
(out of 13031 reports on Linux -- kfreebsd doesn't report SMP)

Among those obviously misidentified as non-SMP is #849815, which is somehow
the only report on WSL :/



Anything else you'd want me to get?  Core counts for >1?  UTC hours or days
of week when bugs are filed?  Kernels that've been in the archive vs those
that haven't?


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11


Reply to: