[REGRESSION 2014-08] Volume up/down keys, printScreen key and some shortcuts randomly stop working

[Teo]

All of a sudden, the volume keys from the keyboard have stopped working.

The volume control on the top right corner of the screen does work if used with the mouse.

I have both an external usb keyboard with dedicated volume + and - keys, and the builtin laptop keyboard where the volume +/-keys are the combination of the Fn key plus the up/down arrows.

All these used to work up to a few minutes ago. Now none of them works.
I think they stopped working with the last reboot.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-32-generic 3.13.0-32.57
ProcVersionSignature: Ubuntu 3.13.0-32.57-generic 3.13.11.4
Uname: Linux 3.13.0-32-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: teo 2303 F.... pulseaudio
 /dev/snd/pcmC0D0p: teo 2303 F...m pulseaudio
CurrentDesktop: Unity
Date: Tue Aug 5 23:13:35 2014
HibernationDevice: RESUME=UUID=ff7e702a-a05a-47fd-8c14-551e81f9e9e3
InstallationDate: Installed on 2013-10-11 (298 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MachineType: Acer Aspire V3-571G
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-32-generic.efi.signed root=UUID=5830b30e-69e8-4bb4-8a2b-bc2b43c7414a ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-32-generic N/A
 linux-backports-modules-3.13.0-32-generic N/A
 linux-firmware 1.127.5
SourcePackage: linux
UpgradeStatus: Upgraded to trusty on 2014-05-24 (73 days ago)
dmi.bios.date: 10/15/2012
dmi.bios.vendor: Acer
dmi.bios.version: V2.07
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: VA50_HC_CR
dmi.board.vendor: Acer
dmi.board.version: Type2 - Board Version
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: V2.07
dmi.modalias: dmi:bvnAcer:bvrV2.07:bd10/15/2012:svnAcer:pnAspireV3-571G:pvrV2.07:rvnAcer:rnVA50_HC_CR:rvrType2-BoardVersion:cvnAcer:ct10:cvrV2.07:
dmi.product.name: Aspire V3-571G
dmi.product.version: V2.07
dmi.sys.vendor: Acer

[Brad Figg (brad-figg)]

This change was made by a bot.

[penalvch (penalvch)]

Teo, thank you for reporting this and helping make Ubuntu better. As per http://us.acer.com/ac/en/US/content/drivers an update to your BIOS is available (2.21). If you update to this following https://help.ubuntu.com/community/BiosUpdate does it change anything? If it doesn't, could you please both specify what happened, and provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

Please note your current BIOS is already in the Bug Description, so posting this on the old BIOS would not be helpful. As well, you don't have to create a new bug report. As well, you don't have to create a new bug report.

For more on BIOS updates and linux, please see https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette .

Once the BIOS is updated, then please mark this report Status Confirmed.

Thank you for your understanding.

[Teo (teo1978)]

OMG please, don't be ridiculous. As I said, the very same keys on the very same keyboard were working until yesterday and the bios is the same, so this has nothing to do with the bios.

Also, I now notice that the "printscreen" key doesn't work either (any more)

[Brad Figg (brad-figg)]

This change was made by a bot.

[Teo (teo1978)]

:O Oddly, after rebooting the issue disappeared...

[penalvch (penalvch)]

Teo, it still needs to happen. Please do not toggle the Status until it's completed as noted in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1353129/comments/4 .

[Teo (teo1978)]

What needs to happen?

That I update the bios? That's definitely not going to happen (what needs to happen is that ubuntu provide a decent way of upgrading bios without relying on booting other OSes).

And there's no reason why you should need me to update the bios, when this regression has happened without any change in the bios.
On the same bios, everything was working, then the regression appeared. A reboot fixed it, but I guess it may reappear at any time.

This policy of ignoring bugs just because they're reported on a bios that has an update available is simply ridiculous, especially when there's no good reason to think that the bios is related (and even if that was the case).

[teo1978 (teo8976)]

I had a few reboots without observing the issue.

Now, after resuming from an hibernation (not suspension), the issue has reappeared. I don't know if hibernation is what triggers the issue or if it is just intermittent.

Could you please forget the bios bullshit and mark this bug as confirmed and assign it the proper importance (High at the very least) so that it can be triaged?

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Teo (teo1978)]

It's no surprise that Ubuntu is still what it is as long as bug reports get managed this way.

This issue is intermittent, happens randomly, and is a regression (i.e. has started happening at a certain update, never happened before).
Ignoring it just because the reporter doesn't have the latest bios is ridiculous.

This is most probably not even in Linux; I chose linux just because I have no idea what package it belongs to, and there's no generic "ubuntu" package to report bugs against.

[penalvch (penalvch)]

Teo, please do not add random packages to this report. While this report isn't being ignored, as previously outlined to you, bugs can manifest themselves after package upgrading due to an outdated BIOS.

[Teo (teo1978)]

I did not add a *random* package. I added the most generic one that I could think of, as this is probably not in the linux package, and the linux package is the one that has this stupid policy of not taking bug into consideration unless they are reported on the latest bios.

[Rolf Leggewie (r0lf)]

I just ran into this in my vivid test installation (no, just like the OP, I will not jump through silly hoops requested from the penalv-bot only to have the issue at hand ignored). Setting to 'confirmed' and 'affecting me'. In fact, my computer hung after I tried the volume keys.

As with almost any kernel bugs, don't hold your breath for Ubuntu providing a fix, though. It seems the kernel team's only job is to introduce bugs not present upstream. Your best bet is to test the mainline kernel provided by Ubuntu and if the problem if you can reproduce the kernel there as well then report it upstream. Ubuntu won't ever bother and the only way to fix things in Ubuntu is to fix them upstream. Sad but true in case of the kernel.

Just like the OP, the problem was gone after a reboot. I came to this ticket because I experienced bug 1354180 and that ticket referenced this one.

[Rolf Leggewie (r0lf)]

Readding unity to the ticket since bug 1354180 is being triaged there as well

[penalvch (penalvch)]

Rolf Leggewie, please do not add bug tasks unless you can point to the code precisely that is at fault. If you have a bug in Ubuntu, and so your problem and hardware may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into the default Ubuntu kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
https://wiki.ubuntu.com/Kernel/Policies/DuplicateBugs
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

As well, please do not announce in this report you created a new bug report.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Rolf Leggewie (r0lf)]

On 18.12.2014 04:53, Christopher M. Penalver wrote:
> Rolf Leggewie, please do not add bug tasks unless you can point to the code precisely that is at fault.

Yadda, yadda.

Dude, you must be by FAR the single most-hated guy on LP. You must hear to get lost and leave people alone at least a good dozen times a day, don't you? Why don't you do that? You are NOT helping the project, even though you might think you do.

Ever heard of triaging? That's the part people like me do BEFORE they can point to the exact location of where the problem is. That's what the status of 'new' and 'incomplete' and even 'confirmed' are actually for. Even you must know that. So take your "unless" and shove it! You and your self-invented rules are the cancer of LP. Take your bot and take a hike and leave people actually interested in fixing problems in Ubuntu alone. I've been doing this work since before you even knew of Ubuntu. I just didn't make up any stupid rules and put them in a wiki so I could ostracize and alienate everyone.

[penalvch (penalvch)]

Rolf Leggewie, thank you for your comment. First, I wanted to apologize if you were offended by my removing the bug task you added, or words I chose to use. It was not meant to anger you, but there has been no technical evidence presented so far that this is a unity instead of a linux kernel issue.

Hence, instead of personally attacking me, being rude, trolling me, making baseless accusations, ranting, etc. why don't you speak to the technical root cause of this issue, since by changing the bug task again despite what I have posted, you purport to know more about this then I.

Why exactly is this a unity (userspace) issue, versus a linux kernel (or something else) one? Typically if one updates the kernel and multiple keys go out (especially regarding two completely different functionality areas sound and print screen) that is much more correlated to a kernel space/xorg/hardware issue versus userspace. I've personally experienced keys not working after kernel updates, and have had functionality restored by a BIOS update on one particular hardware, and a kernel update on another.

Thank you for your understanding, and I look forward to your response.

[Rolf Leggewie (r0lf)]

Teo, with all the links that the penalv-bot had been spewing about he forget the one that might actually be helpful. Please have a look through https://wiki.ubuntu.com/Hotkeys/Troubleshooting and see if you can gather some information that would be helpful in nailing this issue down. It would certainly be appreciated if you updated your BIOS but since this is a regression I'm happy to continue triage with you absent that update. Take the above wiki page with an eye to giving you helpful information (such as the reference to the xev command) but not being gospel.

From what I understand you only experience this issue temporarily and haven't found a way to systematically reproduce it. That's been my experience as well. I see you experienced this on trusty which is my main operating system as well, but I've only experienced the problem once while booted into my vivid testing environment. Obviously, I don't use that so often.

[Rolf Leggewie (r0lf)]

@penalv-bot: I will not even try to reason with you, because you have amply demonstrated over the years you cannot be reasoned with and all you are concerned about is to get tickets "off-radar". My interest is in fixing problems not in closing tickets or reasoning with unreasonable people.

I am in no way claiming to know this is a bug in unity. I'm not even claiming this is a bug. I'm merely setting to confirmed because the effects of this ticket affect more than one person. I'm triaging in unity because the kernel team never deals with their tickets anyhow and because there is a resident bot there whose sole interest is to close tickets and not to fix or triage problems. The status of this ticket can easily be updated as necessary and as new information comes in. You are free to redirect your attention now to more pressing tasks, thank you.

[penalvch (penalvch)]

Rolf Leggewie, first, please again stop being rude by calling me a bot. As you have signed the Ubuntu Code of Conduct, and as a Ubuntu community member representing Ubuntu Bug Control, you have attested to be someone who is respectful, and considerate. However, calling me a bot, unreasonable, etc. does align with this at all. As well, incessantly claiming the kernel team doesn't deal with tickets is in direct contradiction to all the bugs fixed in linux (Ubuntu). At your convenience, please review the 7000+ bugs fixed there -> https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=FIXRELEASED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.upstream_target=&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search .

Despite this, regarding the article you quoted, I've followed it to get my bugs resolved, have steered others who have a non-buggy BIOS to it, and if you would care to check the changelog, contributed to it. These were the reasons I asked Teo for a BIOS update.

As well, could you also please provide a technical detail on how you are confirming this bug when you don't have the same hardware, and you can't reproduce this issue in the same release as the original reporter?

Also, how would mis-tasking this into Unity be helpful to getting a fix released in linux, or have linux developers look at it?

Given how you said you aren't claiming this is a bug in Unity, but your actions are contradicting this by assigning this solely to the Unity package, unless you have a sound technical reason, or procedure advised to you as a member of Ubuntu Bug Control, could you please re-assign this back to linux (Ubuntu) given this would be the appropriate place for a fix to land as applicable?

Thank you for your time and consideration in this matter, and I look forward to your response.

[Andrea Azzarone (azzar1)]

Teo can you reproduce the same problem on different shells (gnome shell, gnome classic, etc)?

[teo1978 (teo8976)]

Can't tell, sorry.
I only use Unity, and as i mentioned this only occurs sporadically, very rarely, and with no way to reproduce at will that i know of. (I did see it again not long ago, btw)
So even if i tried a given shell for the sake of it, i couldn't but wait for ages for it to happen or not.

It's true that there's no technical evidence that this may belong to Unity.
There is equelly no evidence at all that this may nelong to kernel, either. I originañly reported this agaonst linux because i have no clue what package is responsible, and there doesn't seem to exist a generic "ubuntu" package to report bugs (not with apport at least)

If there's some package responsible for keyboard layout settings that would be a better bet in my opinion

I used to report bugs to linux when i didn't know the package in the hope that people with more knowledge would retriage them. Until i found out there's this stupid policy for all linux bugs of not even looking at it if the OP doesn't have the latest bios

[teo1978 (teo8976)]

I won't say sorry for the typos (typing from mobile) because i'd edit my comment if i could.

[Rolf Leggewie (r0lf)]

@Teo, for the future, you can also report bugs against Ubuntu itself without pre-assigning any package at all.

[Alberto Salvia Novella (es20490446e)]

Christopher M. Penalver:
 > As well, having the outdated BIOS upgraded would be a great
 > step, as well as having the mainline kernel tested to this issue.

In my own experience BIOS are usually very buggy and trigger many
issues. I know of 3 bugs in my own computer BIOS.

Rolf Leggewie:
 > He and I would like to find the cause of this without your constant
 > interference.

Taking decisions slowly by consensus is what usually works the best. But
sometimes those are so trivial or so uncertain that taking one without
entering in too much discussion is a better choice, as the opposite
would mean spending most of the time in topics that really doesn't
matter at all.

When that happens, because Ubuntu is a meritocratic community, the
Canonical staff has always the last word. And everyone should accept that.

Christopher M. Penalver:
 > If you find something I've done alienating, I deeply and sincerely
 > apologize for this. I will reflect on the intent of this e-mail, and
 > how to better my triaging approach. My intentions are only to get to
 > the technical root cause of a particular report, and follow the
 > guidelines already set out by the respective teams whose packages I
 > triage.

Christopher, you have been too kind. Managing an irrational situation in
a rational way is like asking someone to change religion: it won't work.

As rule of thumbs, if someone treats you steadily disrespectful there's
no single reason for continuing the business. Because there's no single
excuse for mistreating other people.

In those cases the most appropriate answer I have found is the
following, which for me feels like letting go a big weight:

Rolf Leggewie (http://tinyurl.com/p2eflk5):
 > Yadda, yadda.
 >
 > Dude, you must be by FAR the single most-hated guy on LP. You must
 > hear to get lost and leave people alone at least a good dozen times a
 > day, don't you? Why don't you do that? You are NOT helping the
 > project, even though you might think you do.

<http://tinyurl.com/7yaoc62>

[Alberto Salvia Novella (es20490446e)]

When you have upgraded your BIOS, if this bug reproduces again, please set this bug status back to confirmed. Thank you.

[Mathieu Trudel-Lapierre (cyphermox)]

There were mentions of it happening after a resume from hibernate. Teo, could you please confirm whether or not you've used hibernate again and if it has triggered the bug? You mention later that it happens randomly, but I just want to make it very certain that it can't be reliably triggered by hibernation... rather than assuming anything.

To pinpoint this to an update that could have caused this issue, it would be useful to have /var/log/apt/history.log for 2014-08-05 and a few days earlier, if you still have that; along with if you remember when the computer had last been rebooted before you did last reboot you mention in this bug report. I realize this is a long time ago, but if you remember, or if you usually shut down your computer every few days, etc. then it can help figuring out from the apt history log whether a specific package was updated around the same time and could be the cause of the issue, or be a trigger for a BIOS bug.

Meaningful packages could still be acpi-support, linux, etc...

Thanks!

[teo1978 (teo8976)]

> if someone treats you steadily disrespectful there's
> no single reason for continuing the business. Because there's no single
> excuse for mistreating other people.

That's funny. Have you ever considered how dismissing tons of bug reports just because they don't meet some rigid criteria is actually disrespectful to those who took the time to report them, if not to users who simply suffer from them? And in the case at hand, even to people (and I'm not talking about myself, obviously) who are actively trying to help triage it.

[teo1978 (teo8976)]

> Teo, could you please confirm whether or not you've used hibernate again and if it has triggered the bug?
> You mention later that it happens randomly, but I just want to make it very certain that it can't be reliably
> triggered by hibernation... rather than assuming anything.

I'm sorry, I can't confirm nor discard that.
I can definitely say that resuming from hibernation does not _systematically_ trigger the issue, that is, it is not a _sufficient_ condition to trigger the issue, but I can't tell for sure whether it is a _necessary_ condition. In other words, I have certainly hibernated and resumed many times without observing the issue, but I can't tell for sure if every time I observed the issue it was after resuming from hibernation.

[teo1978 (teo8976)]

apt log history

[teo1978 (teo8976)]

> along with if you remember when the computer had last been rebooted before you did last reboot you mention in this bug report.

Sorry, no idea. I usually only suspend and resume. I only shut down when I have to carry the laptop somewhere, in which case I either actually shut down or just hibernate. Regarding pure reboot (as opposed to shutdown) I almost never do that unless I'm forced to (e.g. when the prompt to do so becomes really annoying or when the OS is misbehaving beyond telling).

[teo1978 (teo8976)]

In reply to

> @Teo, for the future, you can also report bugs against
> Ubuntu itself without pre-assigning any package at all.

I'll try next time.
I gave up trying that long ago because
1)
$ ubuntu-bug ubuntu
dpkg-query: no packages found matching ubuntu

2) The "Report a bug" link used to point to an annoying page full of bla bla bla, and I got tired of sorting out the path of links that would eventually land you to the page for reporting a bug (I see it nows points directly to it)

3) A few times I tried by doing "ubuntu-bug linux" (or whatever other package) from the terminal and then check the "I don't know" radio button instead of the named package, but the result was the same as choosing the given package.

[Alberto Salvia Novella (es20490446e)]

teo1978:
> That's funny. Have you ever considered how dismissing tons of bug
> reports just because they don't meet some rigid criteria is actually
> disrespectful to those who took the time to report them, if not to
> users who simply suffer from them?

Why do you think asking to upgrade your BIOS is rigid criteria?

teo1978:
> And in the case at hand, even to people (and I'm not talking about
> myself, obviously) who are actively trying to help triage it.

That's me!

[teo1978 (teo8976)]

> Why do you think asking to upgrade your BIOS is rigid criteria?

Asking to upgrade the BIOS is fine.
Refusing to look into the issue unless the BIOS is updated is ridiculous.

Updating the BIOS is a tremendously cumbersome (and risky) process for a user whose main working OS is Ubuntu. Hence most users just won't do that (I won't), which means the bug will expire. And in the vast majority of cases, there won't be a good reason for that because (1) it's extremely unlikely that the issue is caused _solely_ by a bug in the bios; (2) even if updating the bios makes the issue disappear, it doesn't mean that the issue is a bug in the bios; actually it may mean that it is an issue in the software triggered by some peculiarity in the bios that is not even a bug, in which case the issue SHOULD be investigated with the bios that triggers it, in order to fix a bug rather than make it invisible (and perhaps resurface later); (3) even in the event that the bug is triggered by a bug in the bios, chances are that the OS is not responding correctly to the incorrect behavior of the bios, i.e. there could be a bug in the bios _and_ the OS, and finally (4) I remember Ubuntu being announced as "linux for human beings" or something like that: if you really want it to be that, you must assume that there are a lot of machines out there with outdated bioses, and some of their "human being" owners just won't ever update a bios (or have an idea of what it is) until the day when a friendly popup appears allowing them to do it as easily as installing software updates (let's forget for a moment that even upgrading Ubuntu can brick a computer). So, given that the vast majority of bios bugs can almost certainly be worked around by the OS (just think of other OSes that work on machines with the same outdated bios and don't exhibit the issue), the OS should either do that or provide a really stright-forward way to update the bios. The latter may (to some extent) be not in the OS developers' hands ; the former definitely is.

> That's me!
Yes, I guess, but I was referring more specifically to another contributor who has been accused of being rude.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.19 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-rc3-vivid/

[Alberto Salvia Novella (es20490446e)]

If the bug is fixed in the mainline kernel, please set this bug status back to "confirmed". Thank you.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Teo (teo1978)]

I'm not upgrading the BIOS (nonsense requirement) and I'm not testing the mainstream kernel (no time to do that).

That should not be a reason for closing the bug. I have reported it and it's as much as I can do.
This might not even be in the kernel, I reported it against linux just because I have no idea what package is really responsible.

That the OP (in this case me) isn't willing to do additional debugging work doesn't mean the bug should expire, it's not like the person who reports it is the only one affected.

[penalvch (penalvch)]

Teo, by not testing the upstream kernel, you are limiting the developers who are going to look at this to only downstream (Ubuntu) developers. Hence, if you are not willing to help debug this at all, how would you expect any developers to want to work on your issue?

[Teo (teo1978)]

FIRST

>Hence, if you are not willing to help debug this at all, how would you expect any developers to want to work on your issue?

It is not "my" issue, it's everybody's issue. I just happen to be somebody who experienced and reported it.

I don't "expect" anything from any developer if by "expect" we mean "think they should or have to".

But if by "expect" we mean merely "to regard as probable or likely; anticipate", then given that there are developers who work in improving and fixing Ubuntu, whatever is the reason that moves them to devote their effort to make Ubuntu a better software (something I appreciate and for which I'm infinitely grateful), I do "expect" them to be interested in fixing a bug regardless of whether the person who reported it is able (or willing) to do any extra work. Because whether or not I do, the bug is there.

That's what I would do if somebody reported to me a bug in some piece of software I had written (or which I happened to be maintaining)

SECOND
> by not testing the upstream kernel, you are limiting the developers who are going to look at this to only downstream (Ubuntu) developers.

Your are ASSUMING that this is a bug in Linux. I reported it against linux just because I didn't know a way to report it generically (and the ubuntu-bug command doesn't seem to provide a way), but it's not clear at all what package the bug belongs to, so even BEFORE we talk about upstream/downstream, this should be triaged.

[Teo (teo1978)]

By the way:
> by not testing the upstream kernel, you are limiting the developers who are going to look at this to only downstream (Ubuntu) developers.

And by marking it as incomplete and let it expire, you are limiting the developers who are going to look at this to nobody.

[teo1978 (teo8976)]

Users observing issue 1354180 (including me) seem to always observe this issue at the same time, so marking this as duplicate of that one, which has been confirmed.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Rolf Leggewie (r0lf)]

Ubuntu is successfully closing TICKETS again. Hooray!

Too bad that analyzing and fixing PROBLEMS takes such a backseat these days...