[Bug 1825505] Re: Missing location names on gnome panel

[Prasanna V. Loganathar]

This seems to be fixed in one of the updates of late. @jerareyoshi -
could you confirm?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1825505

Title:
  Missing location names on gnome panel

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-clocks/+bug/1825505/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1835645] Re: apt sources should be able to understand release variables

[Prasanna V. Loganathar]

@juliank - *my suggestion is use variables in apt, which provides an
option. It's not forcing a design decision of how it must be done.
Fedora/RHEL is a good example of where it works and dispels your empty
argument that it causes a terrible user experience.

However, based on your comment, the disagreement that you have _is your
opinion_, without having the choice, which is what makes for a terrible
user experience.

Also, I suggest considering or encouraging an open minded discussion,
rather than switching status to the thread to "Opinion" without any
community engagement whatsoever. I find this a bit disturbing to engage.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1835645

Title:
  apt sources should be able to understand release variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1835645/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1835645] Re: apt sources should be able to understand release variables

[Prasanna V. Loganathar]

@juliank - my suggestion is use variables in apt provides an option.
It's not forcing a design decision of how it must be done. Fedora/RHEL
is a good example of where it works and has dispels your empty argument
that it causes a terrible user experience.

However, based on your comment, what disagreement is your opinion,
without having the choice, which is what makes for a terrible user
experience.

Also, I suggest considering or encouraging an open minded discussion,
rather than switching status to opinion without community engagement
whatsoever. I find this a bit disturbing to engage.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1835645

Title:
  apt sources should be able to understand release variables

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1835645/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1835645] [NEW] apt sources should be able to understand release variables

[Prasanna V. Loganathar]

Public bug reported:

apt sources conventionally use a fixed release name. But this causes
both adding repos as well as upgrading an unnecessarily painful
experience. For instance, adding a simple package requires adding the
keys with `apt-key` and then adding the repo, and then apt update/apt
install. 3 different steps also complicate install scripts. Distros like
fedora, RHEL handle this rather gracefully with `releasever` which makes
for a consistent experience.

Similarly, updating ubuntu on desktops every 6 months causes unnecessary
waste of time, having to upgrade the sources with say "bionic" to
"disco", and such in the apt sources. Currently, ubuntu attempts this on
a superficial level by just changing swapping out the release names for
what it can, and disabling the others. This is both fragile and causes
an inconsistent upgrade experience.

I think it's time that this is simplified, and potentially handled by
apt utilising release variables and names from `/etc/os-release`.

In case of upgrades, I personally think it's completely okay to use a
releasever variable based external repo that doesn't exist yet (and
might start working once upstream catches up), rather than just disable
it. However, using ubuntu release models, releasever ideally has the
option of utilising an option of LTS, so some external packages that
only does this conservatively on LTS can target a repo source url that
does just that (while this seems fragile technically, practically it
works as most LTS repos work rather well)

In case of Debian, the above problem is actually not as magnified due to
slower release and consistent names like `stable`, `oldstable` and
`testing`, which makes upgrading not as big a task, however affects
ubuntu release models far more significantly.

I'm marking this as a bug, since I think this is a significant UX dent
for today's distros - so much that other most significant other distros
don't have such a painful experience.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: apt 1.8.1
ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8
Uname: Linux 5.0.0-20-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
CurrentDesktop: GNOME
Date: Sun Jul  7 13:05:04 2019
InstallationDate: Installed on 2019-06-23 (13 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
SourcePackage: apt
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2019-06-29T23:49:14.971566

** Affects: apt
 Importance: Undecided
 Status: New

** Affects: apt (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: apt (Debian)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug disco

** Also affects: apt
   Importance: Undecided
   Status: New

** Also affects: apt (Debian)
   Importance: Undecided
   Status: New

** Description changed:

  apt sources conventionally use a fixed release name. But this causes
  both adding repos as well as upgrading an unnecessarily painful
  experience. For instance, adding a simple package requires adding the
  keys with `apt-key` and then adding the repo, and then apt update/apt
  install. 3 different steps also complicate install scripts. Distros like
  fedora, RHEL handle this rather gracefully with `releasever` which makes
  for a consistent experience.
  
  Similarly, updating ubuntu on desktops every 6 months causes unnecessary
  waste of time, having to upgrade the sources with say "bionic" to
  "disco", and such in the apt sources. Currently, ubuntu attempts this on
  a superficial level by just changing swapping out the release names for
  what it can, and disabling the others. This is both fragile and causes
  an inconsistent upgrade experience.
  
  I think it's time that this is simplified, and potentially handled by
  apt utilising release variables and names from `/etc/os-release`.
  
  In case of upgrades, I personally think it's completely okay to use a
  releasever variable based external repo that doesn't exist yet (and
  might start working once upstream catches up), rather than just disable
  it. However, using ubuntu release models, releasever ideally has the
  option of utilising an option of LTS, so some external packages that
  only does this conservatively on LTS can target a repo source url that
  does just that (while this seems fragile technically, practically it
  works as most LTS repos work rather well)
  
+ In case of Debian, the above problem is actually not as magnified due to 
+ slower release and consistent names like `stable`, `oldstable` and `testing`, 
which makes upgrading not big a task, however affects ubuntu
+ release models far more significantly.  
+ 
+ 
  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: apt 1.8.1
  ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8
  Uname: Linux 5.0.0-20-generic x86_64
  ApportVersion: 

[Bug 1834748] Re: shotwell crashed with SIGSEGV in library_window_switch_to_page

[Prasanna V. Loganathar]

** Summary changed:

- shotwell crash on startup
+ shotwell crashed with SIGSEGV in library_window_switch_to_page

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1834748

Title:
  shotwell crashed with SIGSEGV in library_window_switch_to_page

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1834748/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1834764] [NEW] dleyna-renderer-service crashed with SIGABRT in prv_control_point_stop_service

[Prasanna V. Loganathar]

Public bug reported:

gdb stack traces and debug info:

```
GNU gdb (Ubuntu 8.2.91.20190405-0ubuntu3) 8.2.91.20190405-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/dleyna-renderer/dleyna-renderer-service...
Reading symbols from 
/usr/lib/debug/.build-id/dd/7d69822fa7381525e3e1eccc937adb0280ae4c.debug...

warning: core file may not match specified executable file.
[New LWP 13570]
[New LWP 13571]
[New LWP 13572]
[New LWP 13573]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/dleyna-renderer/dleyna-renderer-service'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f8923935d40 (LWP 13570))]
(gdb) bt
#0  0x7f89263abed7 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f892638d535 in __GI_abort () at abort.c:79
#2  0x7f89263f4726 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f892651a952 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7f89263fb59a in malloc_printerr (str=str@entry=0x7f892651c638 "double 
free or corruption (fasttop)") at malloc.c:5352
#4  0x7f89263fd534 in _int_free (av=0x7f892654cc40 , 
p=0x558beb95cd60, have_lock=) at malloc.c:4274
#5  0x7f8926581311 in prv_control_point_stop_service () at server.c:723
#6  0x7f89268af658 in  () at 
/usr/lib/x86_64-linux-gnu/libdleyna-core-1.0.so.3
#7  0x7f89267d9958 in g_main_context_dispatch () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x7f89267d9d48 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x7f89267da042 in g_main_loop_run () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x7f89268af83c in dleyna_main_loop_start () at 
/usr/lib/x86_64-linux-gnu/libdleyna-core-1.0.so.3
#11 0x558bea696dac in main (argc=, argv=) at 
daemon.c:93
(gdb) info frame
Stack level 0, frame at 0x7fff03582900:
 rip = 0x7f89263abed7 in __GI_raise (../sysdeps/unix/sysv/linux/raise.c:50); 
saved rip = 0x7f892638d535
 called by frame at 0x7fff03582a30
 source language c.
 Arglist at 0x7fff035827d8, args: sig=sig@entry=6
 Locals at 0x7fff035827d8, Previous frame's sp is 0x7fff03582900
 Saved registers:
  rip at 0x7fff035828f8
(gdb) info registers
rax0x0 0
rbx0x7fff03582a50  140733249497680
rcx0x7f89263abed7  140227028631255
rdx0x0 0
rsi0x7fff035827e0  140733249497056
rdi0x2 2
rbp0x7fff03582b30  0x7fff03582b30
rsp0x7fff035827e0  0x7fff035827e0
r8 0x0 0
r9 0x7fff035827e0  140733249497056
r100x8 8
r110x246   582
r120x7fff03582a50  140733249497680
r130x1000  4096
r140x7f8926ad8000  140227036151808
r150x2032
rip0x7f89263abed7  0x7f89263abed7 <__GI_raise+199>
eflags 0x246   [ PF ZF IF ]
cs 0x3351
ss 0x2b43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) thread apply all bt

Thread 4 (Thread 0x7f89226b8700 (LWP 13573)):
#0  0x7f892647f2e9 in syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7f8926824b1a in g_cond_wait_until () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f89267ab0c1 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f89267ab681 in g_async_queue_timeout_pop () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f89268033a1 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f892680293d in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x7f892655c182 in start_thread (arg=) at 
pthread_create.c:486
#7  0x7f8926485b1f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7f89230bd700 (LWP 13572)):
#0  0x7f8926479729 in __GI___poll (fds=0x558beb93dd60, nfds=2, 

[Bug 1834748] Re: shotwell crash on startup

[Prasanna V. Loganathar]

Here's the gdb stack trace:

```
$ gdb /usr/bin/shotwell ./core.3036 
GNU gdb (Ubuntu 8.2.91.20190405-0ubuntu3) 8.2.91.20190405-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/shotwell...
Reading symbols from 
/usr/lib/debug/.build-id/de/5ef1027f855c42246be8090cc8484e5f2123ac.debug...
[New LWP 3036]
[New LWP 3051]
[New LWP 3088]
[New LWP 3084]
[New LWP 3085]
[New LWP 3087]
[New LWP 3134]
[New LWP 3089]
[New LWP 3086]
[New LWP 3049]
[New LWP 3093]
[New LWP 3094]
[New LWP 3091]
[New LWP 3090]
[New LWP 3110]
[New LWP 3095]
[New LWP 3092]
[New LWP 3074]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `shotwell'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f306a883d40 in g_menu_model_get_n_items () from 
/lib/x86_64-linux-gnu/libgio-2.0.so.0
[Current thread is 1 (Thread 0x7f3066bb1b00 (LWP 3036))]
(gdb) where
#0  0x7f306a883d40 in g_menu_model_get_n_items () at 
/lib/x86_64-linux-gnu/libgio-2.0.so.0
#1  0x7f3069e60c31 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#2  0x7f3069e615ab in gtk_application_window_set_show_menubar () at 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#3  0x558796026d17 in library_window_switch_to_page 
(self=self@entry=0x558798503f70, page=page@entry=0x5587987ef8c0) at 
../src/library/LibraryWindow.vala:1310
#4  0x558796029065 in library_window_switch_to_import_queue_page 
(self=0x558798503f70) at ../src/library/LibraryWindow.vala:951
#5  0x5587960c42b6 in run_system_pictures_import 
(external_exclusion_manifest=) at ../src/main.vala:246
#6  0x5587960c42b6 in run_system_pictures_import 
(external_exclusion_manifest=) at main.c:1837
#7  0x5587960c4de7 in library_exec (mounts=, 
mounts_length1=) at ../src/main.vala:205
#8  0x5587960c5654 in _vala_main (args=, 
args_length1=) at ../src/main.vala:460
#9  0x558795fba3f0 in main (argc=, argv=) at 
../src/main.vala:347
(gdb) thread apply all bt

Thread 18 (Thread 0x7f3064a34700 (LWP 3074)):
#0  0x7f30692f8729 in __GI___poll (fds=0x5587981858f0, nfds=1, 
timeout=25000) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f306a678bf6 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f306a678d1c in g_main_context_iteration () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f3064d35ffd in  () at 
/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#4  0x7f306a6a187d in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f30693db182 in start_thread (arg=) at 
pthread_create.c:486
#6  0x7f3069304b1f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 17 (Thread 0x7f30477fe700 (LWP 3092)):
#0  0x7f30692fe2e9 in syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7f306a6c393f in g_cond_wait () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f306a64a0db in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f306a6a2217 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f306a6a187d in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f30693db182 in start_thread (arg=) at 
pthread_create.c:486
#6  0x7f3069304b1f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 16 (Thread 0x7f3045ffb700 (LWP 3095)):
#0  0x7f30692fe2e9 in syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7f306a6c393f in g_cond_wait () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f306a64a0db in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f306a6a2217 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f306a6a187d in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f30693db182 in start_thread (arg=) at 
pthread_create.c:486
#6  0x7f3069304b1f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 15 (Thread 0x7f300700 (LWP 3110)):
#0  0x7f30692f8729 in __GI___poll (fds=0x7f3004007030, nfds=3, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f304c0569f1 in  () at /lib/x86_64-linux-gnu/libpulse.so.0
#2  0x7f304c048260 in pa_mainloop_poll () at 
/lib/x86_64-linux-gnu/libpulse.so.0
#3  0x7f304c0488ae in pa_mainloop_iterate () at 
/lib/x86_64-linux-gnu/libpulse.so.0
#4  0x7f304c048960 in pa_mainloop_run () at 

[Bug 1834748] Re: shotwell crash on startup

[Prasanna V. Loganathar]

Ok, looks my core dump is corrupted. Marking as "incomplete", as there's
nothing actionable here without it.

** Changed in: shotwell (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1834748

Title:
  shotwell crash on startup

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1834748/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1834748] [NEW] shotwell crash on startup

[Prasanna V. Loganathar]

Public bug reported:

Random crash on startup

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: shotwell 0.30.2-0ubuntu2
ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8
Uname: Linux 5.0.0-20-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
CurrentDesktop: GNOME
Date: Sat Jun 29 22:37:24 2019
InstallationDate: Installed on 2019-06-23 (5 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
SourcePackage: shotwell
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: shotwell (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug disco

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1834748

Title:
  shotwell crash on startup

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1834748/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 137981] Re: Cheese : If two v4l devices exist there is no way to choose the correct one

[Prasanna V. Loganathar]

Ended up hitting this on my Thinkpad X1. Integrated Camera is always
been chosen, and Cheese always seems to reset the settings on each
startup even if I change it manually using gsettings.

This is a pretty basic UX high priority bug that's somehow not been
payed attention for over a decade since 2007?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/137981

Title:
  Cheese : If two v4l devices exist there is no way to choose the
  correct one

To manage notifications about this bug go to:
https://bugs.launchpad.net/cheese/+bug/137981/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 137981] Re: Cheese : If two v4l devices exist there is no way to choose the correct one

[Prasanna V. Loganathar]

^*Integrated IR Camera always selected as default -- instead of the
actual webcam.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/137981

Title:
  Cheese : If two v4l devices exist there is no way to choose the
  correct one

To manage notifications about this bug go to:
https://bugs.launchpad.net/cheese/+bug/137981/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1825505] Re: Missing location names on gnome panel

[Prasanna V. Loganathar]

^ If this is indeed directly related, I'd guess the priority has to be
moved up.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1825505

Title:
  Missing location names on gnome panel

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-clocks/+bug/1825505/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1813403] Re: Better kernel core dump defaults [switch to systemd-coredump]

[Prasanna V. Loganathar]

** Summary changed:

- Better kernel core dump defaults
+ Better kernel core dump defaults [switch to systemd-coredump]

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1813403

Title:
  Better kernel core dump defaults [switch to systemd-coredump]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1813403/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1825505] [NEW] Missing location names on gnome panel

[Prasanna V. Loganathar]

Public bug reported:

Since, ubuntu 19.04 the panel on the gnome is missing names of some
items of the clock items. This happen, both on upgrade or fresh install.
Happen with the live image as well.

Steps to reproduce: 
- Install gnome-clocks
- Log in/restart gnome-shell to make sure gnome panel includes the clocks
- Add clocks
- Specific clock items like "New York, New York", "Singapore, Singapore" don't 
show the names.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: gnome-clocks 3.32.0-1
ProcVersionSignature: Ubuntu 5.0.0-13.14-generic 5.0.6
Uname: Linux 5.0.0-13-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
CurrentDesktop: GNOME
Date: Fri Apr 19 16:05:26 2019
InstallationDate: Installed on 2019-01-01 (108 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
SourcePackage: gnome-clocks
UpgradeStatus: Upgraded to disco on 2019-04-19 (0 days ago)
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2019-01-15T04:51:59.517661

** Affects: gnome-clocks (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug disco

** Attachment added: "Screenshot of missing items"
   
https://bugs.launchpad.net/bugs/1825505/+attachment/5256999/+files/gnome-clocks-missing.jpg

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1825505

Title:
  Missing location names on gnome panel

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-clocks/+bug/1825505/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1812387] Re: tmux crashes on tpm init

[Prasanna V. Loganathar]

Reproduction steps again, for reference:

1. docker run -it --rm prasannavl/tmux-launchpad-bug-1812387
2. tmux
3. Alt + e + I
4. exit (Don't wait for tpm to finish)
5. tmux
6. Alt + e + I (again)

Wait for the tpm completion message, and visible tmux crash with [lost
server] message on console.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1812387

Title:
  tmux crashes on tpm init

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tmux/+bug/1812387/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1812387] Re: tmux crashes on tpm init

[Prasanna V. Loganathar]

I've updated the docker image prasannavl/tmux-launchpad-bug-1812387 to
only use ubuntu-repo based tmux-plugin-manager.

It still crashes with "[lost-server]". Same steps as above should work.

**Dockerfile:**

```
FROM ubuntu:18.10

RUN apt update && apt dist-upgrade -y && \
apt install tmux tmux-plugin-manager git tree -y && \
ulimit -c unlimited

COPY tmux.conf "/root/.tmux.conf"
CMD bash
```

**tmux.conf:**

```
# set prefix: Alt + e
set -g prefix M-e
# Let's bind this too, so that repeated
# presses work, esp. when nesting.
bind -n M-e send-prefix

# start window numbering at 1
set -g base-index 1
# start pane numbering at 1
set -g pane-base-index 1

# use mouse
set -g mouse on
setw -g mode-keys vi

# Use Alt-arrow keys WITHOUT PREFIX KEY to switch panes
bind -n M-Left select-pane -L
bind -n M-Right select-pane -R
bind -n M-Up select-pane -U
bind -n M-Down select-pane -D

set -g @scroll-down-exit-copy-mode off
set -g @scroll-without-changing-pane on
set -g @emulate-scroll-for-no-mouse-alternate-buffer on

# plugins
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @plugin 'tmux-plugins/tmux-copycat'
set -g @plugin 'tmux-plugins/tmux-pain-control'
set -g @plugin 'tmux-plugins/tmux-prefix-highlight'
set -g @plugin 'tmux-plugins/tmux-open'
set -g @plugin 'tmux-plugins/tmux-yank'
set -g @plugin 'nhdaly/tmux-better-mouse-mode'
set -g @plugin 'tmux-plugins/tmux-logging'

run -b "/usr/share/tmux-plugin-manager/tpm"

```

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1812387

Title:
  tmux crashes on tpm init

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tmux/+bug/1812387/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1813403] Re: Better kernel core dump defaults

[Prasanna V. Loganathar]

** Description changed:

  Currently,
  
  `$ sysctl kernel.core_pattern`
  
  gives
  
  `kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P`
  
- This should be considered a bug, since a minimal version of ubuntu
- (server, core etc) and more notoriously when run from containers, this
- will just error out, with no core dump being produced, due to the
- absence of apport. Adding to the problem, is with container where you
- can't just change it per container, and should be changed from the host.
- I think using apport (a non essential package) as a default without
- thought as to it's absence is not robust design.
+ This is usually fine, however, when run from containers or lxc this will
+ just error out, with no core dump being produced, due to it being
+ disabled. Adding to the problem: with container or lxc, you can't just
+ change it per container, and should be changed on the host. And it's not
+ reasonable to expect apport in all containers either. Since, this is a
+ common problem, I think it's important to consider a change in the
+ default handling.
  
  There are multiple options to deal with this:
  
- 1. Drop apport as default and switch to a simple file in either
- /var/crash (this requires creating /var/crash as a part of the
- installation as it's currently created by apport), or /tmp
+ 1. Drop apport as default core_pattern handler and switch to a simple
+ file in either /var/crash (this requires creating /var/crash as a part
+ of the installation as it's currently created by apport), or /tmp and
+ let apport handle the core dump after the fact, and report it.
  
  2. Switch to systemd-coredump, and default to it, since it already does
  this very well and provides "coredumpctl" which is much nicer to work
  with. systemd-coredump also is a part of the systemd suite of utils and
  doesn't pull in a larger dependency as apport -- which to date, isn't as
  robust (I still have "core" files being left all over the place due to
  the fact that apport reset's itself and crashes during startup aren't
  handled properly). This also has a nice advantage of unifying the OSS
  community in terms of coredump handler. apport can handle things from
  the core dumps that systemd generates, further on desktops.
  
  3. Employ a tiny helper script, as the default core dump handler, which
  looks for specified programs such as "apport", "abrt", systemd-coredump"
  and pipes to them, or pipes it to /var/crash, or /tmp during it's
  absence. This does have the disadvantage of growing with it's own
  config, rather quickly.
  
  That being said, I highly suggest option 2 be used in the upcoming
  versions, and apport be a layer sitting on top of the coredumps
  generated by systemd-coredumps by either hooking into it, or by watching
- it's folders. I've started to remove apport and switch to systemd-
- coredump in all my server images as well, as apport seems to mostly be
- more of a nuisance. However, this also makes it difficult to report to
- launchpad, as apport currently cannot readily take an existing core dump
- file and do the reporting (though I suppose this should be possible
- providing the right arguments?).
+ it's folders.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sat Jan 26 20:33:55 2019
  InstallationDate: Installed on 2019-01-01 (25 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.apport.crashdb.conf: [modified]
  mtime.conffile..etc.apport.crashdb.conf: 2019-01-15T04:51:59.517661

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1813403

Title:
  Better kernel core dump defaults

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1813403/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1813403] Re: Better kernel core dump defaults

[Prasanna V. Loganathar]

** Description changed:

  Currently,
  
  `$ sysctl kernel.core_pattern`
  
  gives
  
  `kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P`
  
  This should be considered a bug, since a minimal version of ubuntu
  (server, core etc) and more notoriously when run from containers, this
  will just error out, with no core dump being produced, due to the
  absence of apport. Adding to the problem, is with container where you
  can't just change it per container, and should be changed from the host.
  I think using apport (a non essential package) as a default without
  thought as to it's absence is not robust design.
  
  There are multiple options to deal with this:
  
- 1. Drop apport as default and switch to a simple file in either /var/crash 
(this requires creating /var/crash as a part of the installation as it's 
currently created by apport), or /tmp
- 2. Switch to systemd-coredump, and default to it, since it already does this 
very well and provides "coredumpctl" which is much nicer to work with. 
systemd-coredump also is a part of the systemd suite of utils and doesn't pull 
in a larger dependency as apport -- which to date, isn't as robust (I still 
have "core" files being left all over the place by apport, mostly in my home 
folder). This also has a nice advantage of unifying the OSS community in terms 
of coredump handler. apport can handle things from the core dumps that systemd 
generates, further on desktops.
- 3. Employ a tiny helper script, as the default core dump handler, which looks 
for specified programs such as "apport", "abrt", systemd-coredump" and pipes to 
them, or pipes it to /var/crash, or /tmp during it's absence. This does have 
the disadvantage of growing with it's own config, rather quickly.
+ 1. Drop apport as default and switch to a simple file in either
+ /var/crash (this requires creating /var/crash as a part of the
+ installation as it's currently created by apport), or /tmp
  
+ 2. Switch to systemd-coredump, and default to it, since it already does
+ this very well and provides "coredumpctl" which is much nicer to work
+ with. systemd-coredump also is a part of the systemd suite of utils and
+ doesn't pull in a larger dependency as apport -- which to date, isn't as
+ robust (I still have "core" files being left all over the place due to
+ the fact that apport reset's itself and crashes during startup aren't
+ handled properly). This also has a nice advantage of unifying the OSS
+ community in terms of coredump handler. apport can handle things from
+ the core dumps that systemd generates, further on desktops.
+ 
+ 3. Employ a tiny helper script, as the default core dump handler, which
+ looks for specified programs such as "apport", "abrt", systemd-coredump"
+ and pipes to them, or pipes it to /var/crash, or /tmp during it's
+ absence. This does have the disadvantage of growing with it's own
+ config, rather quickly.
+ 
+ That being said, I highly suggest option 2 be used in the upcoming
+ versions, and apport be a layer sitting on top of the coredumps
+ generated by systemd-coredumps by either hooking into it, or by watching
+ it's folders. I've started to remove apport and switch to systemd-
+ coredump in all my server images as well, as apport seems to mostly be
+ more of a nuisance. However, this also makes it difficult to report to
+ launchpad, as apport currently cannot readily take an existing core dump
+ file and do the reporting (though I suppose this should be possible
+ providing the right arguments?).
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sat Jan 26 20:33:55 2019
  InstallationDate: Installed on 2019-01-01 (25 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.apport.crashdb.conf: [modified]
  mtime.conffile..etc.apport.crashdb.conf: 2019-01-15T04:51:59.517661

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1813403

Title:
  Better kernel core dump defaults

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1813403/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1811732] Re: dunst crashed with SIGSEGV in xdgSearchableConfigDirectories()

[Prasanna V. Loganathar]

** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1811732

Title:
  dunst crashed with SIGSEGV in xdgSearchableConfigDirectories()

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dunst/+bug/1811732/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1765002] Re: baloo_file_extractor crashed with SIGABRT in qt_message_fatal()

[Prasanna V. Loganathar]

** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1765002

Title:
  baloo_file_extractor crashed with SIGABRT in qt_message_fatal()

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/baloo-kf5/+bug/1765002/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1813601] Re: tree and better recursive directory sizing

[Prasanna V. Loganathar]

Hi Ian,

Thank you for the reply. I appreciate it :) .. However I think you may
have replied to an older version of the bug description. I did miss the
"--du" option initially, but then had updated the description
accordingly.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1813601

Title:
  tree and better recursive directory sizing

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tree/+bug/1813601/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1813601] Re: tree and better recursive directory sizing

[Prasanna V. Loganathar]

** Description changed:

  Currently `tree -dh`/`tree -h` simply shows the size of the directory
  nodes that tend to be 4K in a default ext4 installation with 4K block
  sizes. While this is not very useful in terms of UX, it does however
  have it's use by not spending a whole lot of IO on calculating recursive
  sizes. However, in addition to the current mode, it would be great to
  have an option, that recursively adds up the size of the its contents
  and displays the total size of the directory (inclusive of all hidden
  and dot files), instead of just the directory node size.
  
  UPDATE: There's the "--du" option, that the upstream author was gracious
  enough to point out to me. This is great and solves the problem in
  theory.
  
  But in practice, when used with large trees (for example the $HOME
  folder), the usefulness vanishes rather quickly due to the following
  reasons:
  
  1. Output is usually very large. So, it isn't very practical to use this
  option in non-automated scenario. So we probably want to limit depth
  with "-L" in most occasions.
  
  2. However, while using "-L", "--du" behaves in a way where it only
- calculates partial sizes for the leaf trees, that are larger than the
- given depth. So, this limits it's practical usefulness as well.
+ calculates partial sizes for the leaf trees that are larger than the
+ given depth. While this is probably the best default to have, with the
+ exception of some specific scenarios where this is what is required,
+ this limits it's practical usefulness as well with most large trees.
  
- 3. While the above is technically a right decision for the same reasons
- as tree defaulting to just show size of the directory as block sizes,
- this is misleading since there's no way to differentiate what's a
- partial size, and what's the correct real calculation in the above
- scenario.
+ 3. In the above scenario, the problem is compounded by the fact that one
+ can easily be mislead, since there's currently no way to differentiate
+ what's a partial size, and what's the correct real calculation of the
+ full size.
  
  POTENTIAL SOLUTIONS:
  
- 1 & 2. It would nice to have an additional option that calculates the forces 
the tree traversal for the calculating sizes alone, so that real sizes are 
displayed when used along with the "-L" option. This can also be in the form of 
another depth, that default to say "-1", meaning a full traversal, or positive 
numbers for limiting the size traversals. 
-  
- 3. This can easily be solved by suffixing the size with something, for the 
sake of a better suffix "*". 
+ 1 & 2. It would be nice to have an additional option that calculates the
+ forces the tree traversal for the calculating sizes alone, so that real
+ sizes are displayed when used along with the "-L" option. This can also
+ be in the form of another depth, that default to say "-1", meaning a
+ full traversal, or positive numbers for limiting the size traversals.
  
+ 3. This can easily be solved by suffixing the size with something, for
+ the sake of a better suffix "*".
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: tree 1.7.0-5
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Mon Jan 28 18:49:37 2019
  Dependencies:
   gcc-8-base 8.2.0-7ubuntu1
   libc6 2.28-0ubuntu1
   libgcc1 1:8.2.0-7ubuntu1
   libidn2-0 2.0.5-1
   libunistring2 0.9.10-1ubuntu1
  InstallationDate: Installed on 2019-01-01 (27 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  SourcePackage: tree
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.apport.crashdb.conf: [modified]
  mtime.conffile..etc.apport.crashdb.conf: 2019-01-15T04:51:59.517661

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1813601

Title:
  tree and better recursive directory sizing

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tree/+bug/1813601/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1813601] Re: tree and recursive directory sizing

[Prasanna V. Loganathar]

** Description changed:

  Currently `tree -dh`/`tree -h` simply shows the size of the directory
  nodes that tend to be 4K in a default ext4 installation with 4K block
  sizes. While this is not very useful in terms of UX, it does however
  have it's use by not spending a whole lot of IO on calculating recursive
  sizes. However, in addition to the current mode, it would be great to
  have an option, that recursively adds up the size of the its contents
  and displays the total size of the directory (inclusive of all hidden
  and dot files), instead of just the directory node size.
+ 
+ UPDATE: There's the "--du" option, that the upstream author was gracious
+ enough to point out to me. This is great and solves the problem in
+ theory.
+ 
+ But in practice, when used with large trees (for example the $HOME
+ folder), the usefulness vanishes rather quickly due to the following
+ reasons:
+ 
+ 1. Output is usually very large. So, it isn't very practical to use this
+ option in non-automated scenario. So we probably want to limit depth
+ with "-L" in most occasions.
+ 
+ 2. However, while using "-L", "--du" behaves in a way where it only
+ calculates partial sizes for the leaf trees, that are larger than the
+ given depth. So, this limits it's practical usefulness as well.
+ 
+ 3. While the above is technically a right decision for the same reasons
+ as tree defaulting to just show size of the directory as block sizes,
+ this is misleading since there's no way to differentiate what's a
+ partial size, and what's the correct real calculation in the above
+ scenario.
+ 
+ POTENTIAL SOLUTIONS:
+ 
+ 1 & 2. It would nice to have an additional option that calculates the forces 
the tree traversal for the calculating sizes alone, so that real sizes are 
displayed when used along with the "-L" option. This can also be in the form of 
another depth, that default to say "-1", meaning a full traversal, or positive 
numbers for limiting the size traversals. 
+  
+ 3. This can easily be solved by suffixing the size with something, for the 
sake of a better suffix "*". 
+ 
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: tree 1.7.0-5
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Mon Jan 28 18:49:37 2019
  Dependencies:
   gcc-8-base 8.2.0-7ubuntu1
   libc6 2.28-0ubuntu1
   libgcc1 1:8.2.0-7ubuntu1
   libidn2-0 2.0.5-1
   libunistring2 0.9.10-1ubuntu1
  InstallationDate: Installed on 2019-01-01 (27 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  SourcePackage: tree
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.apport.crashdb.conf: [modified]
  mtime.conffile..etc.apport.crashdb.conf: 2019-01-15T04:51:59.517661

** Summary changed:

- tree and recursive directory sizing
+ tree and better recursive directory sizing

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1813601

Title:
  tree and better recursive directory sizing

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tree/+bug/1813601/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1813601] [NEW] tree and recursive directory sizing

[Prasanna V. Loganathar]

Public bug reported:

Currently `tree -dh`/`tree -h` simply shows the size of the directory
nodes that tend to be 4K in a default ext4 installation with 4K block
sizes. While this is not very useful in terms of UX, it does however
have it's use by not spending a whole lot of IO on calculating recursive
sizes. However, in addition to the current mode, it would be great to
have an option, that recursively adds up the size of the its contents
and displays the total size of the directory (inclusive of all hidden
and dot files), instead of just the directory node size.

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: tree 1.7.0-5
ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
Uname: Linux 4.18.0-13-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.10-0ubuntu13.1
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Jan 28 18:49:37 2019
Dependencies:
 gcc-8-base 8.2.0-7ubuntu1
 libc6 2.28-0ubuntu1
 libgcc1 1:8.2.0-7ubuntu1
 libidn2-0 2.0.5-1
 libunistring2 0.9.10-1ubuntu1
InstallationDate: Installed on 2019-01-01 (27 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
SourcePackage: tree
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2019-01-15T04:51:59.517661

** Affects: tree (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug cosmic

** Description changed:

  Currently `tree -dh`/`tree -h` simply shows the size of the directory
  nodes that tend to be 4K in a default ext4 installation with 4K block
- sizes. While this is not very useful in terms of UX, it does however
- serves it's purpose by not spending a whole lot of IO on calculating
- recursive sizes. However, in addition to the current mode, it would be
- great to have an option, that recursively adds up the size of the its
- contents.
+ sizes. While this is not very useful in terms of UX, it does however has
+ it's use by not spending a whole lot of IO on calculating recursive
+ sizes. However, in addition to the current mode, it would be great to
+ have an option, that recursively adds up the size of the its contents
+ and displays the total size of the directory (inclusive of all hidden
+ and dot files), instead of just the directory node size.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: tree 1.7.0-5
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Mon Jan 28 18:49:37 2019
  Dependencies:
-  gcc-8-base 8.2.0-7ubuntu1
-  libc6 2.28-0ubuntu1
-  libgcc1 1:8.2.0-7ubuntu1
-  libidn2-0 2.0.5-1
-  libunistring2 0.9.10-1ubuntu1
+  gcc-8-base 8.2.0-7ubuntu1
+  libc6 2.28-0ubuntu1
+  libgcc1 1:8.2.0-7ubuntu1
+  libidn2-0 2.0.5-1
+  libunistring2 0.9.10-1ubuntu1
  InstallationDate: Installed on 2019-01-01 (27 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  SourcePackage: tree
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.apport.crashdb.conf: [modified]
  mtime.conffile..etc.apport.crashdb.conf: 2019-01-15T04:51:59.517661

** Description changed:

  Currently `tree -dh`/`tree -h` simply shows the size of the directory
  nodes that tend to be 4K in a default ext4 installation with 4K block
- sizes. While this is not very useful in terms of UX, it does however has
- it's use by not spending a whole lot of IO on calculating recursive
+ sizes. While this is not very useful in terms of UX, it does however
+ have it's use by not spending a whole lot of IO on calculating recursive
  sizes. However, in addition to the current mode, it would be great to
  have an option, that recursively adds up the size of the its contents
  and displays the total size of the directory (inclusive of all hidden
  and dot files), instead of just the directory node size.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: tree 1.7.0-5
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Mon Jan 28 18:49:37 2019
  Dependencies:
   gcc-8-base 8.2.0-7ubuntu1
   libc6 2.28-0ubuntu1
   libgcc1 1:8.2.0-7ubuntu1
   libidn2-0 2.0.5-1
   libunistring2 0.9.10-1ubuntu1
  InstallationDate: Installed on 2019-01-01 (27 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  SourcePackage: tree
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.apport.crashdb.conf: [modified]
  mtime.conffile..etc.apport.crashdb.conf: 2019-01-15T04:51:59.517661

-- 
You received this 

[Bug 1813403] Re: Better kernel core dump defaults

[Prasanna V. Loganathar]

** Package changed: procps (Ubuntu) => ubuntu

** Description changed:

  Currently,
  
  `$ sysctl kernel.core_pattern`
  
  gives
  
  `kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P`
  
  This should be considered a bug, since a minimal version of ubuntu
  (server, core etc) and more notoriously when run from containers, this
  will just error out, with no core dump being produced, due to the
  absence of apport. Adding to the problem, is with container where you
  can't just change it per container, and should be changed from the host.
  I think using apport (a non essential package) as a default without
  thought as to it's absence is not robust design.
  
  There are multiple options to deal with this:
  
  1. Drop apport as default and switch to a simple file in either /var/crash 
(this requires creating /var/crash as a part of the installation as it's 
currently created by apport), or /tmp
- 2. Switch to systemd-coredump, and default to it, since it already does this 
very well and provides "coredumpctl" which is much nicer to work with. 
systemd-coredump also is a part of the systemd suite of utils and doesn't pull 
in a larger dependency as apport -- which to date, isn't as robust (I still 
have "core" files being left all over the place by apport, mostly in my home 
folder). This also has a nice advantage of unifying the OSS community in terms 
of coredump handler.
- 3. Employ a tiny helper script, as the default core dump handler, which looks 
for specified programs such as "apport", "abrt", systemd-coredump" and pipes to 
them, or pipes it to /var/crash, or /tmp during it's absence.
+ 2. Switch to systemd-coredump, and default to it, since it already does this 
very well and provides "coredumpctl" which is much nicer to work with. 
systemd-coredump also is a part of the systemd suite of utils and doesn't pull 
in a larger dependency as apport -- which to date, isn't as robust (I still 
have "core" files being left all over the place by apport, mostly in my home 
folder). This also has a nice advantage of unifying the OSS community in terms 
of coredump handler. apport can handle things from the core dumps that systemd 
generates, further on desktops.
+ 3. Employ a tiny helper script, as the default core dump handler, which looks 
for specified programs such as "apport", "abrt", systemd-coredump" and pipes to 
them, or pipes it to /var/crash, or /tmp during it's absence. This does have 
the disadvantage of growing with it's own config, rather quickly.
  
- And add a sysctl.d default rule here, or more cleanly a separate package
- that does exactly this on option 3.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
- Package: procps 2:3.3.15-2ubuntu1
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sat Jan 26 20:33:55 2019
  InstallationDate: Installed on 2019-01-01 (25 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
- SourcePackage: procps
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.apport.crashdb.conf: [modified]
  mtime.conffile..etc.apport.crashdb.conf: 2019-01-15T04:51:59.517661

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1813403

Title:
  Better kernel core dump defaults

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1813403/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1813403] Re: Better kernel core dump defaults

[Prasanna V. Loganathar]

** Description changed:

  Currently,
  
  `$ sysctl kernel.core_pattern`
  
  gives
  
  `kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P`
  
- This should be considered a bug, since a minimal version of ubuntu or
- even debian, and more notoriously when run from containers, this will
- just error out, with no core dump being produced, due to the absence of
- apport. Adding to the problem, is with container where you can't just
- change it per container, and should be changed from the host. I think
- using apport (a non essential package) as a default without thought as
- to it's absence is not robust design.
+ This should be considered a bug, since a minimal version of ubuntu
+ (server, core etc) and more notoriously when run from containers, this
+ will just error out, with no core dump being produced, due to the
+ absence of apport. Adding to the problem, is with container where you
+ can't just change it per container, and should be changed from the host.
+ I think using apport (a non essential package) as a default without
+ thought as to it's absence is not robust design.
  
  There are multiple options to deal with this:
  
- 1. Drop apport as default and switch to a simple file in either /var/crash 
(this requires creating /var/crash as a part of the installation), or /tmp
- 2. Switch to systemd-coredump, and default to it, since it already does this 
very well and provides "coredumpctl" which is much nicer to work with. 
systemd-coredump also is a part of the systemd suite of utils and doesn't pull 
in a larger dependency as apport -- which to date, isn't as robust (I still 
have "core" files being left all over the place by apport, mostly in my home 
folder). This also has a nice advantage of unifying the OSS community in terms 
of coredump handler. 
+ 1. Drop apport as default and switch to a simple file in either /var/crash 
(this requires creating /var/crash as a part of the installation as it's 
currently created by apport), or /tmp
+ 2. Switch to systemd-coredump, and default to it, since it already does this 
very well and provides "coredumpctl" which is much nicer to work with. 
systemd-coredump also is a part of the systemd suite of utils and doesn't pull 
in a larger dependency as apport -- which to date, isn't as robust (I still 
have "core" files being left all over the place by apport, mostly in my home 
folder). This also has a nice advantage of unifying the OSS community in terms 
of coredump handler.
  3. Employ a tiny helper script, as the default core dump handler, which looks 
for specified programs such as "apport", "abrt", systemd-coredump" and pipes to 
them, or pipes it to /var/crash, or /tmp during it's absence.
+ 
+ And add a sysctl.d default rule here, or more cleanly a separate package
+ that does exactly this on option 3.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.10
  Package: procps 2:3.3.15-2ubuntu1
  ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
  Uname: Linux 4.18.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.10-0ubuntu13.1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sat Jan 26 20:33:55 2019
  InstallationDate: Installed on 2019-01-01 (25 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  SourcePackage: procps
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.apport.crashdb.conf: [modified]
  mtime.conffile..etc.apport.crashdb.conf: 2019-01-15T04:51:59.517661

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1813403

Title:
  Better kernel core dump defaults

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1813403/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1813403] [NEW] Better kernel core dump defaults

[Prasanna V. Loganathar]

Public bug reported:

Currently,

`$ sysctl kernel.core_pattern`

gives

`kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P`

This should be considered a bug, since a minimal version of ubuntu or
even debian, and more notoriously when run from containers, this will
just error out, with no core dump being produced, due to the absence of
apport. Adding to the problem, is with container where you can't just
change it per container, and should be changed from the host. I think
using apport (a non essential package) as a default without thought as
to it's absence is not robust design.

There are multiple options to deal with this:

1. Drop apport as default and switch to a simple file in either /var/crash 
(this requires creating /var/crash as a part of the installation), or /tmp
2. Switch to systemd-coredump, and default to it, since it already does this 
very well and provides "coredumpctl" which is much nicer to work with. 
systemd-coredump also is a part of the systemd suite of utils and doesn't pull 
in a larger dependency as apport -- which to date, isn't as robust (I still 
have "core" files being left all over the place by apport, mostly in my home 
folder). This also has a nice advantage of unifying the OSS community in terms 
of coredump handler. 
3. Employ a tiny helper script, as the default core dump handler, which looks 
for specified programs such as "apport", "abrt", systemd-coredump" and pipes to 
them, or pipes it to /var/crash, or /tmp during it's absence.

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: procps 2:3.3.15-2ubuntu1
ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17
Uname: Linux 4.18.0-13-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.10-0ubuntu13.1
Architecture: amd64
CurrentDesktop: GNOME
Date: Sat Jan 26 20:33:55 2019
InstallationDate: Installed on 2019-01-01 (25 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
SourcePackage: procps
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2019-01-15T04:51:59.517661

** Affects: procps (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug cosmic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1813403

Title:
  Better kernel core dump defaults

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1813403/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1812387] Re: tmux crashes on tpm init

[Prasanna V. Loganathar]

Reference attachment: Dockerfile


** Attachment added: "Dockerfile"
   
https://bugs.launchpad.net/ubuntu/+source/tmux/+bug/1812387/+attachment/5232555/+files/Dockerfile

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1812387

Title:
  tmux crashes on tpm init

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tmux/+bug/1812387/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1812387] Re: tmux crashes on tpm init

[Prasanna V. Loganathar]

Reference attachment: tmux.conf

** Attachment added: "tmux.conf"
   
https://bugs.launchpad.net/ubuntu/+source/tmux/+bug/1812387/+attachment/5232556/+files/tmux.conf

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1812387

Title:
  tmux crashes on tpm init

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tmux/+bug/1812387/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1812387] Re: tmux crashes on tpm init

[Prasanna V. Loganathar]

Hi Christian,

Alright, did a little more digging. It looks like incomplete
installation of tpm/tpm plugins, or some race condition with multiple
tpm execution that's causing the crash. I put it as docker image for
convenience.

How to reproduce the bug:
 
1. docker run -it --rm prasannavl/tmux-launchpad-bug-1812387
2. tmux
3. Alt + e + I
4. exit (Don't wait for tpm to finish) 
5. tmux
6. Alt + e + I (again)

Wait for the tpm completion message, and visible tmux crash with [lost
server] message on console.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1812387

Title:
  tmux crashes on tpm init

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tmux/+bug/1812387/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1812387] Re: tmux crash while installing tmux plugin manager

[Prasanna V. Loganathar]

Note: You probably might want to set `ulimit -c unlimited` before any of
the above to make the system generate the core dumps.

** Information type changed from Private to Public

** Summary changed:

- tmux crash while installing tmux plugin manager
+ tmux crashes on tpm init

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1812387

Title:
  tmux crashes on tpm init

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tmux/+bug/1812387/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1812753] Re: gnome-control-center crash

[Prasanna V. Loganathar]

Hi Sebastien, I'm afraid I'm not entirely sure. I had this crash dump
again and again in a clean installed laptop that's up to date for the
last couple of weeks. So, thought I'll file it. Please do feel free to
close it if you think it may be redundant.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1812753

Title:
  gnome-control-center crash

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1812753/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs