[Bug 2064176] Re: LXD fan bridge causes blocked tasks

[Wesley Hershberger]

** Attachment added: "apport.linux-image-6.5.0-28-generic._9l2i4n1.apport"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2064176/+attachment/5772647/+files/apport.linux-image-6.5.0-28-generic._9l2i4n1.apport

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

Title:
  LXD fan bridge causes blocked tasks

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


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

[Kernel-packages] [Bug 2064176] Re: LXD fan bridge causes blocked tasks

[Wesley Hershberger]

** Attachment added: "apport.linux-image-6.5.0-28-generic._9l2i4n1.apport"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2064176/+attachment/5772647/+files/apport.linux-image-6.5.0-28-generic._9l2i4n1.apport

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2064176

Title:
  LXD fan bridge causes blocked tasks

Status in linux package in Ubuntu:
  New

Bug description:
  Hi, cross posting this from
  https://github.com/canonical/lxd/issues/12161

  I've got a lxd cluster running across 3 VMs using the fan bridge. I'm
  using a dev revision of LXD based on 6413a948. Creating a container
  causes the trace in the attached syslog snippet; this causes the
  container creation process to hang indefinitely. ssh logins, `lxc
  shell cluster1`, and `ps -aux` also hang.

  Apr 29 17:15:01 cluster1 kernel: [  161.250951] [ cut here 
]
  Apr 29 17:15:01 cluster1 kernel: [  161.250957] Voluntary context switch 
within RCU read-side critical section!
  Apr 29 17:15:01 cluster1 kernel: [  161.250990] WARNING: CPU: 2 PID: 510 at 
kernel/rcu/tree_plugin.h:320 rcu_note_context_switch+0x2a7/0x2f0
  Apr 29 17:15:01 cluster1 kernel: [  161.251003] Modules linked in: nft_masq 
nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 vxlan 
ip6_udp_tunnel udp_tunnel dummy br
  idge stp llc zfs(PO) spl(O) nf_tables libcrc32c nfnetlink vhost_vsock vhost 
vhost_iotlb binfmt_misc nls_iso8859_1 intel_rapl_msr intel_rapl_common 
kvm_intel kvm irqbypass crct10dif
  _pclmul crc32_pclmul virtio_gpu polyval_clmulni polyval_generic 
ghash_clmulni_intel sha256_ssse3 sha1_ssse3 virtio_dma_buf aesni_intel 
vmw_vsock_virtio_transport 9pnet_virtio xhci_
  pci drm_shmem_helper i2c_i801 ahci 9pnet vmw_vsock_virtio_transport_common 
xhci_pci_renesas drm_kms_helper libahci crypto_simd joydev virtio_input cryptd 
lpc_ich virtiofs i2c_smbus
   vsock psmouse input_leds mac_hid serio_raw rapl qemu_fw_cfg vmgenid nfsd 
dm_multipath auth_rpcgss scsi_dh_rdac nfs_acl lockd scsi_dh_emc scsi_dh_alua 
grace sch_fq_codel drm sunrpc
   efi_pstore virtio_rng ip_tables x_tables autofs4
  Apr 29 17:15:01 cluster1 kernel: [  161.251085] CPU: 2 PID: 510 Comm: nmbd 
Tainted: P   O   6.5.0-28-generic #29~22.04.1-Ubuntu
  Apr 29 17:15:01 cluster1 kernel: [  161.251089] Hardware name: QEMU Standard 
PC (Q35 + ICH9, 2009)/LXD, BIOS unknown 2/2/2022
  Apr 29 17:15:01 cluster1 kernel: [  161.251091] RIP: 
0010:rcu_note_context_switch+0x2a7/0x2f0
  Apr 29 17:15:01 cluster1 kernel: [  161.251095] Code: 08 f0 83 44 24 fc 00 48 
89 de 4c 89 f7 e8 d1 af ff ff e9 1e fe ff ff 48 c7 c7 d0 60 56 88 c6 05 e6 27 
40 02 01 e8 79 b2 f2 ff
  <0f> 0b e9 bd fd ff ff a9 ff ff ff 7f 0f 84 75 fe ff ff 65 48 8b 3c
  Apr 29 17:15:01 cluster1 kernel: [  161.251098] RSP: 0018:b9cbc11dbbc8 
EFLAGS: 00010046
  Apr 29 17:15:01 cluster1 kernel: [  161.251101] RAX:  RBX: 
941ef7cb3f80 RCX: 
  Apr 29 17:15:01 cluster1 kernel: [  161.251103] RDX:  RSI: 
 RDI: 
  Apr 29 17:15:01 cluster1 kernel: [  161.251104] RBP: b9cbc11dbbe8 R08: 
 R09: 
  Apr 29 17:15:01 cluster1 kernel: [  161.251106] R10:  R11: 
 R12: 
  Apr 29 17:15:01 cluster1 kernel: [  161.25] R13: 941d893e9980 R14: 
 R15: 941d80ad7a80
  Apr 29 17:15:01 cluster1 kernel: [  161.251113] FS:  7c7dcbdb8a00() 
GS:941ef7c8() knlGS:
  Apr 29 17:15:01 cluster1 kernel: [  161.251115] CS:  0010 DS:  ES:  
CR0: 80050033
  Apr 29 17:15:01 cluster1 kernel: [  161.251117] CR2: 5a30877ae488 CR3: 
000105888003 CR4: 00170ee0
  Apr 29 17:15:01 cluster1 kernel: [  161.251122] Call Trace:
  Apr 29 17:15:01 cluster1 kernel: [  161.251128]  
  Apr 29 17:15:01 cluster1 kernel: [  161.251133]  ? show_regs+0x6d/0x80
  Apr 29 17:15:01 cluster1 kernel: [  161.251145]  ? __warn+0x89/0x160
  Apr 29 17:15:01 cluster1 kernel: [  161.251152]  ? 
rcu_note_context_switch+0x2a7/0x2f0
  Apr 29 17:15:01 cluster1 kernel: [  161.251155]  ? report_bug+0x17e/0x1b0
  Apr 29 17:15:01 cluster1 kernel: [  161.251172]  ? handle_bug+0x46/0x90
  Apr 29 17:15:01 cluster1 kernel: [  161.251187]  ? exc_invalid_op+0x18/0x80
  Apr 29 17:15:01 cluster1 kernel: [  161.251190]  ? 
asm_exc_invalid_op+0x1b/0x20
  Apr 29 17:15:01 cluster1 kernel: [  161.251202]  ? 
rcu_note_context_switch+0x2a7/0x2f0
  Apr 29 17:15:01 cluster1 kernel: [  161.251205]  ? 
rcu_note_context_switch+0x2a7/0x2f0
  Apr 29 17:15:01 cluster1 kernel: [  161.251208]  __schedule+0xcc/0x750
  Apr 29 17:15:01 cluster1 kernel: [  161.251218]  schedule+0x63/0x110
  Apr 29 17:15:01 cluster1 kernel: [  161.251222]  
schedule_hrtimeout_range_clock+0xbc/0x130
  Apr 29 17:15:01 cluster1 kernel: [  161.251238]  ? 

[Bug 2064176] [NEW] LXD fan bridge causes blocked tasks

[Wesley Hershberger]

Public bug reported:

Hi, cross posting this from
https://github.com/canonical/lxd/issues/12161

I've got a lxd cluster running across 3 VMs using the fan bridge. I'm
using a dev revision of LXD based on 6413a948. Creating a container
causes the trace in the attached syslog snippet; this causes the
container creation process to hang indefinitely. ssh logins, `lxc shell
cluster1`, and `ps -aux` also hang.

Apr 29 17:15:01 cluster1 kernel: [  161.250951] [ cut here 
]
Apr 29 17:15:01 cluster1 kernel: [  161.250957] Voluntary context switch within 
RCU read-side critical section!
Apr 29 17:15:01 cluster1 kernel: [  161.250990] WARNING: CPU: 2 PID: 510 at 
kernel/rcu/tree_plugin.h:320 rcu_note_context_switch+0x2a7/0x2f0
Apr 29 17:15:01 cluster1 kernel: [  161.251003] Modules linked in: nft_masq 
nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 vxlan 
ip6_udp_tunnel udp_tunnel dummy br
idge stp llc zfs(PO) spl(O) nf_tables libcrc32c nfnetlink vhost_vsock vhost 
vhost_iotlb binfmt_misc nls_iso8859_1 intel_rapl_msr intel_rapl_common 
kvm_intel kvm irqbypass crct10dif
_pclmul crc32_pclmul virtio_gpu polyval_clmulni polyval_generic 
ghash_clmulni_intel sha256_ssse3 sha1_ssse3 virtio_dma_buf aesni_intel 
vmw_vsock_virtio_transport 9pnet_virtio xhci_
pci drm_shmem_helper i2c_i801 ahci 9pnet vmw_vsock_virtio_transport_common 
xhci_pci_renesas drm_kms_helper libahci crypto_simd joydev virtio_input cryptd 
lpc_ich virtiofs i2c_smbus
 vsock psmouse input_leds mac_hid serio_raw rapl qemu_fw_cfg vmgenid nfsd 
dm_multipath auth_rpcgss scsi_dh_rdac nfs_acl lockd scsi_dh_emc scsi_dh_alua 
grace sch_fq_codel drm sunrpc
 efi_pstore virtio_rng ip_tables x_tables autofs4
Apr 29 17:15:01 cluster1 kernel: [  161.251085] CPU: 2 PID: 510 Comm: nmbd 
Tainted: P   O   6.5.0-28-generic #29~22.04.1-Ubuntu
Apr 29 17:15:01 cluster1 kernel: [  161.251089] Hardware name: QEMU Standard PC 
(Q35 + ICH9, 2009)/LXD, BIOS unknown 2/2/2022
Apr 29 17:15:01 cluster1 kernel: [  161.251091] RIP: 
0010:rcu_note_context_switch+0x2a7/0x2f0
Apr 29 17:15:01 cluster1 kernel: [  161.251095] Code: 08 f0 83 44 24 fc 00 48 
89 de 4c 89 f7 e8 d1 af ff ff e9 1e fe ff ff 48 c7 c7 d0 60 56 88 c6 05 e6 27 
40 02 01 e8 79 b2 f2 ff
<0f> 0b e9 bd fd ff ff a9 ff ff ff 7f 0f 84 75 fe ff ff 65 48 8b 3c
Apr 29 17:15:01 cluster1 kernel: [  161.251098] RSP: 0018:b9cbc11dbbc8 
EFLAGS: 00010046
Apr 29 17:15:01 cluster1 kernel: [  161.251101] RAX:  RBX: 
941ef7cb3f80 RCX: 
Apr 29 17:15:01 cluster1 kernel: [  161.251103] RDX:  RSI: 
 RDI: 
Apr 29 17:15:01 cluster1 kernel: [  161.251104] RBP: b9cbc11dbbe8 R08: 
 R09: 
Apr 29 17:15:01 cluster1 kernel: [  161.251106] R10:  R11: 
 R12: 
Apr 29 17:15:01 cluster1 kernel: [  161.25] R13: 941d893e9980 R14: 
 R15: 941d80ad7a80
Apr 29 17:15:01 cluster1 kernel: [  161.251113] FS:  7c7dcbdb8a00() 
GS:941ef7c8() knlGS:
Apr 29 17:15:01 cluster1 kernel: [  161.251115] CS:  0010 DS:  ES:  
CR0: 80050033
Apr 29 17:15:01 cluster1 kernel: [  161.251117] CR2: 5a30877ae488 CR3: 
000105888003 CR4: 00170ee0
Apr 29 17:15:01 cluster1 kernel: [  161.251122] Call Trace:
Apr 29 17:15:01 cluster1 kernel: [  161.251128]  
Apr 29 17:15:01 cluster1 kernel: [  161.251133]  ? show_regs+0x6d/0x80
Apr 29 17:15:01 cluster1 kernel: [  161.251145]  ? __warn+0x89/0x160
Apr 29 17:15:01 cluster1 kernel: [  161.251152]  ? 
rcu_note_context_switch+0x2a7/0x2f0
Apr 29 17:15:01 cluster1 kernel: [  161.251155]  ? report_bug+0x17e/0x1b0
Apr 29 17:15:01 cluster1 kernel: [  161.251172]  ? handle_bug+0x46/0x90
Apr 29 17:15:01 cluster1 kernel: [  161.251187]  ? exc_invalid_op+0x18/0x80
Apr 29 17:15:01 cluster1 kernel: [  161.251190]  ? asm_exc_invalid_op+0x1b/0x20
Apr 29 17:15:01 cluster1 kernel: [  161.251202]  ? 
rcu_note_context_switch+0x2a7/0x2f0
Apr 29 17:15:01 cluster1 kernel: [  161.251205]  ? 
rcu_note_context_switch+0x2a7/0x2f0
Apr 29 17:15:01 cluster1 kernel: [  161.251208]  __schedule+0xcc/0x750
Apr 29 17:15:01 cluster1 kernel: [  161.251218]  schedule+0x63/0x110
Apr 29 17:15:01 cluster1 kernel: [  161.251222]  
schedule_hrtimeout_range_clock+0xbc/0x130
Apr 29 17:15:01 cluster1 kernel: [  161.251238]  ? 
__pfx_hrtimer_wakeup+0x10/0x10
Apr 29 17:15:01 cluster1 kernel: [  161.251245]  
schedule_hrtimeout_range+0x13/0x30
Apr 29 17:15:01 cluster1 kernel: [  161.251248]  ep_poll+0x33f/0x390
Apr 29 17:15:01 cluster1 kernel: [  161.251254]  ? 
__pfx_ep_autoremove_wake_function+0x10/0x10
Apr 29 17:15:01 cluster1 kernel: [  161.251257]  do_epoll_wait+0xdb/0x100
Apr 29 17:15:01 cluster1 kernel: [  161.251259]  __x64_sys_epoll_wait+0x6f/0x110
Apr 29 17:15:01 cluster1 kernel: [  161.251265]  do_syscall_64+0x5b/0x90
Apr 29 17:15:01 cluster1 kernel: [  161.251270]  ? 

[Kernel-packages] [Bug 2064176] [NEW] LXD fan bridge causes blocked tasks

[Wesley Hershberger]

Public bug reported:

Hi, cross posting this from
https://github.com/canonical/lxd/issues/12161

I've got a lxd cluster running across 3 VMs using the fan bridge. I'm
using a dev revision of LXD based on 6413a948. Creating a container
causes the trace in the attached syslog snippet; this causes the
container creation process to hang indefinitely. ssh logins, `lxc shell
cluster1`, and `ps -aux` also hang.

Apr 29 17:15:01 cluster1 kernel: [  161.250951] [ cut here 
]
Apr 29 17:15:01 cluster1 kernel: [  161.250957] Voluntary context switch within 
RCU read-side critical section!
Apr 29 17:15:01 cluster1 kernel: [  161.250990] WARNING: CPU: 2 PID: 510 at 
kernel/rcu/tree_plugin.h:320 rcu_note_context_switch+0x2a7/0x2f0
Apr 29 17:15:01 cluster1 kernel: [  161.251003] Modules linked in: nft_masq 
nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 vxlan 
ip6_udp_tunnel udp_tunnel dummy br
idge stp llc zfs(PO) spl(O) nf_tables libcrc32c nfnetlink vhost_vsock vhost 
vhost_iotlb binfmt_misc nls_iso8859_1 intel_rapl_msr intel_rapl_common 
kvm_intel kvm irqbypass crct10dif
_pclmul crc32_pclmul virtio_gpu polyval_clmulni polyval_generic 
ghash_clmulni_intel sha256_ssse3 sha1_ssse3 virtio_dma_buf aesni_intel 
vmw_vsock_virtio_transport 9pnet_virtio xhci_
pci drm_shmem_helper i2c_i801 ahci 9pnet vmw_vsock_virtio_transport_common 
xhci_pci_renesas drm_kms_helper libahci crypto_simd joydev virtio_input cryptd 
lpc_ich virtiofs i2c_smbus
 vsock psmouse input_leds mac_hid serio_raw rapl qemu_fw_cfg vmgenid nfsd 
dm_multipath auth_rpcgss scsi_dh_rdac nfs_acl lockd scsi_dh_emc scsi_dh_alua 
grace sch_fq_codel drm sunrpc
 efi_pstore virtio_rng ip_tables x_tables autofs4
Apr 29 17:15:01 cluster1 kernel: [  161.251085] CPU: 2 PID: 510 Comm: nmbd 
Tainted: P   O   6.5.0-28-generic #29~22.04.1-Ubuntu
Apr 29 17:15:01 cluster1 kernel: [  161.251089] Hardware name: QEMU Standard PC 
(Q35 + ICH9, 2009)/LXD, BIOS unknown 2/2/2022
Apr 29 17:15:01 cluster1 kernel: [  161.251091] RIP: 
0010:rcu_note_context_switch+0x2a7/0x2f0
Apr 29 17:15:01 cluster1 kernel: [  161.251095] Code: 08 f0 83 44 24 fc 00 48 
89 de 4c 89 f7 e8 d1 af ff ff e9 1e fe ff ff 48 c7 c7 d0 60 56 88 c6 05 e6 27 
40 02 01 e8 79 b2 f2 ff
<0f> 0b e9 bd fd ff ff a9 ff ff ff 7f 0f 84 75 fe ff ff 65 48 8b 3c
Apr 29 17:15:01 cluster1 kernel: [  161.251098] RSP: 0018:b9cbc11dbbc8 
EFLAGS: 00010046
Apr 29 17:15:01 cluster1 kernel: [  161.251101] RAX:  RBX: 
941ef7cb3f80 RCX: 
Apr 29 17:15:01 cluster1 kernel: [  161.251103] RDX:  RSI: 
 RDI: 
Apr 29 17:15:01 cluster1 kernel: [  161.251104] RBP: b9cbc11dbbe8 R08: 
 R09: 
Apr 29 17:15:01 cluster1 kernel: [  161.251106] R10:  R11: 
 R12: 
Apr 29 17:15:01 cluster1 kernel: [  161.25] R13: 941d893e9980 R14: 
 R15: 941d80ad7a80
Apr 29 17:15:01 cluster1 kernel: [  161.251113] FS:  7c7dcbdb8a00() 
GS:941ef7c8() knlGS:
Apr 29 17:15:01 cluster1 kernel: [  161.251115] CS:  0010 DS:  ES:  
CR0: 80050033
Apr 29 17:15:01 cluster1 kernel: [  161.251117] CR2: 5a30877ae488 CR3: 
000105888003 CR4: 00170ee0
Apr 29 17:15:01 cluster1 kernel: [  161.251122] Call Trace:
Apr 29 17:15:01 cluster1 kernel: [  161.251128]  
Apr 29 17:15:01 cluster1 kernel: [  161.251133]  ? show_regs+0x6d/0x80
Apr 29 17:15:01 cluster1 kernel: [  161.251145]  ? __warn+0x89/0x160
Apr 29 17:15:01 cluster1 kernel: [  161.251152]  ? 
rcu_note_context_switch+0x2a7/0x2f0
Apr 29 17:15:01 cluster1 kernel: [  161.251155]  ? report_bug+0x17e/0x1b0
Apr 29 17:15:01 cluster1 kernel: [  161.251172]  ? handle_bug+0x46/0x90
Apr 29 17:15:01 cluster1 kernel: [  161.251187]  ? exc_invalid_op+0x18/0x80
Apr 29 17:15:01 cluster1 kernel: [  161.251190]  ? asm_exc_invalid_op+0x1b/0x20
Apr 29 17:15:01 cluster1 kernel: [  161.251202]  ? 
rcu_note_context_switch+0x2a7/0x2f0
Apr 29 17:15:01 cluster1 kernel: [  161.251205]  ? 
rcu_note_context_switch+0x2a7/0x2f0
Apr 29 17:15:01 cluster1 kernel: [  161.251208]  __schedule+0xcc/0x750
Apr 29 17:15:01 cluster1 kernel: [  161.251218]  schedule+0x63/0x110
Apr 29 17:15:01 cluster1 kernel: [  161.251222]  
schedule_hrtimeout_range_clock+0xbc/0x130
Apr 29 17:15:01 cluster1 kernel: [  161.251238]  ? 
__pfx_hrtimer_wakeup+0x10/0x10
Apr 29 17:15:01 cluster1 kernel: [  161.251245]  
schedule_hrtimeout_range+0x13/0x30
Apr 29 17:15:01 cluster1 kernel: [  161.251248]  ep_poll+0x33f/0x390
Apr 29 17:15:01 cluster1 kernel: [  161.251254]  ? 
__pfx_ep_autoremove_wake_function+0x10/0x10
Apr 29 17:15:01 cluster1 kernel: [  161.251257]  do_epoll_wait+0xdb/0x100
Apr 29 17:15:01 cluster1 kernel: [  161.251259]  __x64_sys_epoll_wait+0x6f/0x110
Apr 29 17:15:01 cluster1 kernel: [  161.251265]  do_syscall_64+0x5b/0x90
Apr 29 17:15:01 cluster1 kernel: [  161.251270]  ? 

[ceph-users] Re: Remove an OSD with hardware issue caused rgw 503

[Wesley Dillingham]

What you want to do is to stop the OSD (and all its copies of data it
contains) by stopping the OSD service immediately. The downside of this
approach is it causes the PGs on that OSD to be degraded. But the upside is
the OSD which has bad hardware is immediately no  longer participating in
any client IO (the source of your RGW 503s). In this situation the PGs go
into degraded+backfilling

The alternative method is to keep the failing OSD up and in the cluster but
slowly migrate the data off of it, this would be a long drawn out period of
time in which the failing disk would continue to serve client reads and
also facilitate backfill but you wouldnt take a copy of the data out of the
cluster and cause degraded PGs. In this scenario the PGs would be
remapped+backfilling

I tried to find a way to have your cake and eat it to in relation to this
"predicament" in this tracker issue: https://tracker.ceph.com/issues/44400
but it was deemed "wont fix".

Respectfully,

*Wes Dillingham*
LinkedIn 
w...@wesdillingham.com




On Fri, Apr 26, 2024 at 11:25 AM Mary Zhang  wrote:

> Thank you Eugen for your warm help!
>
> I'm trying to understand the difference between 2 methods.
> For method 1, or "ceph orch osd rm osd_id", OSD Service — Ceph
> Documentation
>  says
> it involves 2 steps:
>
>1.
>
>evacuating all placement groups (PGs) from the OSD
>2.
>
>removing the PG-free OSD from the cluster
>
> For method 2, or the procedure you recommended, Adding/Removing OSDs — Ceph
> Documentation
> <
> https://docs.ceph.com/en/latest/rados/operations/add-or-rm-osds/#removing-osds-manual
> >
> says
> "After the OSD has been taken out of the cluster, Ceph begins rebalancing
> the cluster by migrating placement groups out of the OSD that was removed.
> "
>
> What's the difference between "evacuating PGs" in method 1 and "migrating
> PGs" in method 2? I think method 1 must read the OSD to be removed.
> Otherwise, we would not see slow ops warning. Does method 2 not involve
> reading this OSD?
>
> Thanks,
> Mary
>
> On Fri, Apr 26, 2024 at 5:15 AM Eugen Block  wrote:
>
> > Hi,
> >
> > if you remove the OSD this way, it will be drained. Which means that
> > it will try to recover PGs from this OSD, and in case of hardware
> > failure it might lead to slow requests. It might make sense to
> > forcefully remove the OSD without draining:
> >
> > - stop the osd daemon
> > - mark it as out
> > - osd purge  [--force] [--yes-i-really-mean-it]
> >
> > Regards,
> > Eugen
> >
> > Zitat von Mary Zhang :
> >
> > > Hi,
> > >
> > > We recently removed an osd from our Cepth cluster. Its underlying disk
> > has
> > > a hardware issue.
> > >
> > > We use command: ceph orch osd rm osd_id --zap
> > >
> > > During the process, sometimes ceph cluster enters warning state with
> slow
> > > ops on this osd. Our rgw also failed to respond to requests and
> returned
> > > 503.
> > >
> > > We restarted rgw daemon to make it work again. But the same failure
> > occured
> > > from time to time. Eventually we noticed that rgw 503 error is a result
> > of
> > > osd slow ops.
> > >
> > > Our cluster has 18 hosts and 210 OSDs. We expect remove an osd with
> > > hardware issue won't impact cluster performance & rgw availbility. Is
> our
> > > expectation reasonable? What's the best way to handle osd with hardware
> > > failures?
> > >
> > > Thank you in advance for any comments or suggestions.
> > >
> > > Best Regards,
> > > Mary Zhang
> > > ___
> > > ceph-users mailing list -- ceph-users@ceph.io
> > > To unsubscribe send an email to ceph-users-le...@ceph.io
> >
> >
> > ___
> > ceph-users mailing list -- ceph-users@ceph.io
> > To unsubscribe send an email to ceph-users-le...@ceph.io
> >
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Re: [GNC] Nothing Wrong

[Wesley Werner]

Hello.

I too am a happy GnuCash user. I use it for my personal financing, and while 
still learning, find the application a delight to use. Thanks to everyone 
involved. Your effort is much appreciated!

Wesley

On 24 April 2024 6:59:18 am AEST, Jim Muchow  wrote:
>I want you maintainers and developers to know that I run GnuCash just
>fine and don't have problems. I very much appreciate such a great free
>product. Thanks.
>
>I kinda wanted to make this an annual thing but I have not been
>consistent about this and for that I apologize. Also this is not
>response to any one or more of the problem reports. Just a note of
>thanks.
>___
>gnucash-user mailing list
>gnucash-user@gnucash.org
>To update your subscription preferences or to unsubscribe:
>https://lists.gnucash.org/mailman/listinfo/gnucash-user
>-
>Please remember to CC this list on all your replies.
>You can do this by using Reply-To-List or Reply-All.
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Bug#1068008: rustc: Please package rust 1.75 or higher

[Wesley Schwengle]

Hello all,

On Tue, Apr 23, 2024 at 06:32:04AM +0900, Mike Hommey wrote:
> On Mon, Apr 22, 2024 at 10:24:09PM +0200, Fabian Grünbichler wrote:
>
> >
> > I am sorry to say that I don't expect us to be caught up with 1.75
> > (which is 5 trips through bin-NEW, one of them bigger than usual cause
> > of the merge, and probably 20-40h of rebasing and testing work on my
> > end) until at least the end of May :( I will make sure to include the
> > requirements of thunderbird/firefox if things get stuck in NEW for too
> > long.
> 
> And by end of May, we'll be close to the upstream release of rustc 1.79...
> 
> Is there anything we can do to make things better? Presumably, the
> src:cargo merge should help here, at least a little (because cargo being
> outdated has also been another source of recurring problems).

I second the "Is there anything we can do the make things better?". Are there
things we can do now already, that might speed up packaging rust to
1.77/1.78/1.79 besides waiting the t64 migration to be completed?

I can offer a day a week in help if needed.

Cheers,
Wesley

[OPSAWG] Tsvart last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11

[Wesley Eddy via Datatracker]

Reviewer: Wesley Eddy
Review result: Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.


Thank you for responding to my prior review comments; the latest copy looks 
fine to me.


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Bug#1069114: apt installs package without confirmation

[Wesley Schwengle]

Package: apt
Version: 2.9.1
Severity: important
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

Testing the new apt UI with freeplane showed a rather interesting bug. Apt will
now install a package without confirmation if all the deps are met. 

I triggered this like so:

apt install freeplane # shows confirmation y/n
apt remove freeplane  # shows confirmation y/n
apt install freeplane # doesn't ask for confirmation and just starts installing

See https://asciinema.org/a/3KX3A1hshGiHL0qx42QFsMJQ5 for the behavior in
action.

-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


-- (/etc/apt/preferences.d/buster present, but not submitted) --


-- (/etc/apt/preferences.d/chrome present, but not submitted) --


-- (/etc/apt/preferences.d/docker-ce present, but not submitted) --


-- (/etc/apt/preferences.d/firewalld present, but not submitted) --


-- (/etc/apt/preferences.d/kernel present, but not submitted) --


-- (/etc/apt/preferences.d/libssl present, but not submitted) --


-- (/etc/apt/preferences.d/mozilla present, but not submitted) --


-- (/etc/apt/preferences.d/nodejs present, but not submitted) --


-- (/etc/apt/preferences.d/oldstable present, but not submitted) --


-- (/etc/apt/preferences.d/steam present, but not submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/docker.sources present, but not submitted) --


-- (/etc/apt/sources.list.d/endpoint-verification.sources present, but not 
submitted) --


-- (/etc/apt/sources.list.d/google-chrome.sources present, but not submitted) --


-- (/etc/apt/sources.list.d/mozilla.sources present, but not submitted) --


-- (/etc/apt/sources.list.d/nodesource.sources present, but not submitted) --


-- (/etc/apt/sources.list.d/signal-xenial.sources present, but not submitted) --


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'testing'), (100, 'experimental'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii  adduser 3.137
ii  base-passwd 3.6.3
ii  debian-archive-keyring  2023.4
ii  gpgv2.2.40-3
ii  libapt-pkg6.0t642.9.1
ii  libc6   2.37-17
ii  libgcc-s1   14-20240330-1
ii  libgnutls30t64  3.8.5-2
ii  libseccomp2 2.5.5-1
ii  libstdc++6  14-20240330-1
ii  libsystemd0 255.4-1+b1

Versions of packages apt recommends:
ii  ca-certificates  20240203

Versions of packages apt suggests:
ii  apt-doc 2.9.1
ii  aptitude0.8.13-6
ii  dpkg-dev1.22.6
ii  gnupg   2.2.40-3
ii  powermgmt-base  1.37

-- debconf-show failed

Bug#1068848: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Wesley Schwengle]

Hi

On Fri, Apr 12, 2024 at 09:04:23AM +0200, Jan Katins wrote:
> Subject: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1
> Package: cryptsetup
> Version: 2:2.7.2-1
> Severity: normal
> 
> After a recent apt upgrade, my system failed to unlock. After a
> ctrl-alt-del, I got to the console and there it showed an error about
> libgcc_s.so.1 not available and aborting.
> 
> Thankfully, I still had a other initrd around (I guess due to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065698, yay for
> bugs!).
> 
> I snooped around in the source code a bit and found that libgcc_s
> seems to be dlopened and is special cased:
> https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/master/hook-functions?ref_type=heads#L248-249
> (original bugreport:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254). So my guess
> is that nothing depends on libpthread either anymore, and this is the
> case: `lsinitramfs initrd.img-6.7.9-amd64 |grep thread` shows no
> libpthread (actually nothing). I fixed it now by installing a
> update-initramfs hook (thanks to
> https://groups.google.com/g/linux.debian.bugs.dist/c/4fi2HaOEC_M):

I had the same issue a while back, because of the t64 transitioning I chaulked
it up to that. I fixed it as described in Ubuntu bug:

https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594

Cheers,
Wesley

Bug#1068848: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Wesley Schwengle]

Hi

On Fri, Apr 12, 2024 at 09:04:23AM +0200, Jan Katins wrote:
> Subject: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1
> Package: cryptsetup
> Version: 2:2.7.2-1
> Severity: normal
> 
> After a recent apt upgrade, my system failed to unlock. After a
> ctrl-alt-del, I got to the console and there it showed an error about
> libgcc_s.so.1 not available and aborting.
> 
> Thankfully, I still had a other initrd around (I guess due to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065698, yay for
> bugs!).
> 
> I snooped around in the source code a bit and found that libgcc_s
> seems to be dlopened and is special cased:
> https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/master/hook-functions?ref_type=heads#L248-249
> (original bugreport:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950254). So my guess
> is that nothing depends on libpthread either anymore, and this is the
> case: `lsinitramfs initrd.img-6.7.9-amd64 |grep thread` shows no
> libpthread (actually nothing). I fixed it now by installing a
> update-initramfs hook (thanks to
> https://groups.google.com/g/linux.debian.bugs.dist/c/4fi2HaOEC_M):

I had the same issue a while back, because of the t64 transitioning I chaulked
it up to that. I fixed it as described in Ubuntu bug:

https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1958594

Cheers,
Wesley

[RBW] Re: Grant’s Mointain

[Wesley]

Apparently the actual steepest road mile in California is nearby: Mix 
Canyon Road, which ascends Mt. Vaca. I found this out after I rode up and 
wondered whether it just seemed extra steep to me because I live in the 
flat Central Valley.
-Wes

On Friday, April 12, 2024 at 8:11:31 AM UTC-7 George Schick wrote:

> For those of you living in the Bay Area, which is the steepest, longest 
> climb, the one up Mt. Diablo or the one up Mt. Hamilton?
>
> On Friday, April 12, 2024 at 9:07:51 AM UTC-5 campyo...@me.com wrote:
>
>> Another photo from the upcoming “36 Views of Mt Diablo.” Taken this 
>> morning on my way to San Francisco for a ride around the Bay. 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/450e8bea-aa2c-4b54-9795-d044c8ce52bcn%40googlegroups.com.

[RBW] Re: Looking to buy: V brakes and levers

[Wesley]

Whoops, forgot the 
link: 
https://www.universalcycles.com/shopping/product_details.php?id=107924=37

On Friday, April 12, 2024 at 12:27:27 PM UTC-7 Wesley wrote:

> You can't get better value than these: $33 for brakes, levers, cables, and 
> housing. I use them on my commuter and they're perfectly cromulent.
> -W
>
> On Friday, April 12, 2024 at 8:35:55 AM UTC-7 Hoch in ut wrote:
>
>> I’m building up a vintage MTB frame. Looking for decent v brakes with 
>> levers. Nothing too expensive as this is a cheap frame. Thanks. 
>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/ee0babbf-94f6-4596-ac36-2ba42cceff2cn%40googlegroups.com.

[RBW] Re: Looking to buy: V brakes and levers

[Wesley]

You can't get better value than these: $33 for brakes, levers, cables, and 
housing. I use them on my commuter and they're perfectly cromulent.
-W

On Friday, April 12, 2024 at 8:35:55 AM UTC-7 Hoch in ut wrote:

> I’m building up a vintage MTB frame. Looking for decent v brakes with 
> levers. Nothing too expensive as this is a cheap frame. Thanks. 

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/002ddd9a-d794-4b23-b2ba-3f082ac8e329n%40googlegroups.com.

[ceph-users] Re: Setting S3 bucket policies with multi-tenants

[Wesley Dillingham]

Did you actually get this working? I am trying to replicate your steps but
am not being successful doing this with multi-tenant.

Respectfully,

*Wes Dillingham*
LinkedIn 
w...@wesdillingham.com




On Wed, Nov 1, 2023 at 12:52 PM Thomas Bennett  wrote:

> To update my own question, it would seem that  Principle should be
> defined like this:
>
>- "Principal": {"AWS": ["arn:aws:iam::Tenant1:user/readwrite"]}
>
> And resource should:
> "Resource": [ "arn:aws:s3:::backups"]
>
> Is it worth having the docs updates -
> https://docs.ceph.com/en/quincy/radosgw/bucketpolicy/
> to indicate that usfolks in the example is the tenant name?
>
>
> On Wed, 1 Nov 2023 at 18:27, Thomas Bennett  wrote:
>
> > Hi,
> >
> > I'm running Ceph Quincy (17.2.6) with a rados-gateway. I have muti
> > tenants, for example:
> >
> >- Tenant1$manager
> >- Tenant1$readwrite
> >
> > I would like to set a policy on a bucket (backups for example) owned by
> > *Tenant1$manager* to allow *Tenant1$readwrite* access to that bucket. I
> > can't find any documentation that discusses this scenario.
> >
> > Does anyone know how to specify the Principle and Resource section of a
> > policy.json file? Or any other configuration that I might be missing?
> >
> > I've tried some variations on Principal and Resource including and
> > excluding tenant information, but not no luck yet.
> >
> >
> > For example:
> > {
> >   "Version": "2012-10-17",
> >   "Statement": [{
> > "Effect": "Allow",
> > "Principal": {"AWS": ["arn:aws:iam:::user/*Tenant1$readwrite*"]},
> > "Action": ["s3:ListBucket","s3:GetObject", ,"s3:PutObject"],
> > "Resource": [
> >   "arn:aws:s3:::*Tenant1/backups*"
> > ]
> >   }]
> > }
> >
> > I'm using s3cmd for testing, so:
> > s3cmd --config s3cfg.manager setpolicy policy.json s3://backups/
> > Returns:
> > s3://backups/: Policy updated
> >
> > And then testing:
> > s3cmd --config s3cfg.readwrite ls s3://backups/
> > ERROR: Access to bucket 'backups' was denied
> > ERROR: S3 error: 403 (AccessDenied)
> >
> > Thanks,
> > Tom
> >
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

[ceph-users] Re: PG inconsistent

[Wesley Dillingham]

check your ceph.log on the mons for "stat mismatch" and grep for the PG in
question for potentially more information.

Additionally "rados list-inconsistent-obj {pgid}" will often show which OSD
and objects are implicated for the inconsistency. If the acting set has
changed since the scrub (for example an osd is removed or failed) in which
the inconsistency was found this data wont be there any longer and you
would need to deep-scrub the PG again to get that information.

Respectfully,

*Wes Dillingham*
LinkedIn 
w...@wesdillingham.com




On Fri, Apr 12, 2024 at 6:56 AM Frédéric Nass <
frederic.n...@univ-lorraine.fr> wrote:

>
> Hello Albert,
>
> Have you check the hardware status of the involved drives other than with
> smartctl? Like with the manufacturer's tools / WebUI (iDrac / perccli for
> DELL hardware for example).
> If these tools don't report any media error (that is bad blocs on disks)
> then you might just be facing the bit rot phenomenon. But this is very rare
> and should happen in a sysadmin's lifetime as often as a Royal Flush hand
> in a professional poker player's lifetime. ;-)
>
> If no media error is reported, then you might want to check and update the
> firmware of all drives.
>
> Once you figured it out, you may enable osd_scrub_auto_repair=true to have
> these inconsistencies repaired automatically on deep-scrubbing, but make
> sure you're using the alert module [1] so to at least get informed about
> the scrub errors.
>
> Regards,
> Frédéric.
>
> [1] https://docs.ceph.com/en/latest/mgr/alerts/
>
> - Le 12 Avr 24, à 11:59, Albert Shih albert.s...@obspm.fr a écrit :
>
> > Hi everyone.
> >
> > I got a warning with
> >
> > root@cthulhu1:/etc/ceph# ceph -s
> >  cluster:
> >id: 9c5bb196-c212-11ee-84f3-c3f2beae892d
> >health: HEALTH_ERR
> >1 scrub errors
> >Possible data damage: 1 pg inconsistent
> >
> > So I find the pg with the issue, and launch a pg repair (still waiting)
> >
> > But I try to find «why» so I check all the OSD related on this pg and
> > didn't find anything, no error from osd daemon, no errors from smartctl,
> no
> > error from the kernel message.
> >
> > So I just like to know if that's «normal» or should I scratch deeper.
> >
> > JAS
> > --
> > Albert SHIH 嶺 
> > France
> > Heure locale/Local time:
> > ven. 12 avril 2024 11:51:37 CEST
> > ___
> > ceph-users mailing list -- ceph-users@ceph.io
> > To unsubscribe send an email to ceph-users-le...@ceph.io
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Bug#1068616: libanyevent-i3-perl: Version is outdated compared to the gitrepo

[Wesley Schwengle]

Package: libanyevent-i3-perl
Version: 0.17-3
Severity: important
Tags: upstream
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,


See: https://github.com/i3/i3/issues/5986

The version of AnyEvent::I3 is 0.17 on CPAN while the git repo has version
0.18.

Could you grab the version from the git repo?

Many thanks!



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'testing'), (100, 'experimental'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libanyevent-i3-perl depends on:
ii  libanyevent-perl  7.170-2+b5
ii  libjson-xs-perl   4.030-2+b3
ii  perl  5.38.2-3.2

libanyevent-i3-perl recommends no packages.

libanyevent-i3-perl suggests no packages.

-- debconf-show failed

Re: [RBW] Re: Ron's Ortho... stem question

[Wesley]

For folks who want a higher rise on these stems, my setup combines a 
super-tall quill-to-threadless adapter 
(https://www.somafabshop.com/shop/soma-high-rider-xl-quill-28-6-22-2-290mm-4984)
 
with a 1990s Trek "System 2" stem (for 
instance: https://i.ebayimg.com/images/g/hT8AAOSwzWBi7UKa/s-l400.jpg) which 
are often available on eBay. I think there are "System 1" and "System 3" of 
similar lengths, too (mine is 150mm).
-Wes

On Monday, March 11, 2024 at 3:43:41 PM UTC-7 Jordan Rosenblum wrote:

> Not unlike other folks, I found the width of the Ortho's demanded a longer 
> stem than I use with Bosco and Tosco bars. Another option that I think sits 
> somewhere between a face-plater and other single bolt stems are the Ritchey 
> Force made by Nitto stems of the 90's, which you can occasionally find in 
> even longer lengths. They are steel with a single bolt—and very pretty. The 
> downside is that they don't have a ton of rise. As the poster above 
> mentions, I have successfully used a Ritchey 25.4 clamp diameter stem with 
> the 26.0 Ortho's, which were very secure—though I don't presume any 
> knowledge of whether this is long-term safe. 
>
> I saw this post just as I was prepping a for-sale post of similar stems on 
> another forum. If Chris or other folks are interested, the following are up 
> for grabs, I am going to create a new post so that I don't derail the 
> thread. These include a 120mm 25.4 faceplate stem, Ritchey 25.4 stems in 
> 150 and 170mm(),  and a Ritchey 135mm, 26.0 (might be what you're 
> looking for). Regardless, if you don't need a long steering column, I 
> highly recommend the Ritchey Force stems if you can scrounge up the size 
> that would work for you.
>
> Jordan in Portland, Oregon
>
> [image: IMG_6005.jpg]
> [image: IMG_6011.jpg]
>
>
>
>
>
> On Monday, March 11, 2024 at 1:39:02 PM UTC-7 rmro...@gmail.com wrote:
>
>> For what it is worth Ron used 25.4 clamp size stems and claims & claims 
>> they work great. Got to spread that clamp I guess.
>> Sent from my iPhone
>>
>> On Mar 11, 2024, at 12:09 PM, El Sapo  wrote:
>>
>> 
>>
>>
>> Wish I would have understood the issues with the 26 mm handlebar clamp 
>> prior to purchasing the Ortho Bar. No megusta.The pics posted by iamKeith 
>> don’t show that his hair, beard, and hip vibe are much greater riding the 
>> bike with ortho bars.
>> On Monday, March 11, 2024 at 7:50:27 AM UTC-7 Chris K wrote:
>>
>>> Thank you all for the pics and advice! Very helpful.
>>>
>>> I'm putting these bars on a 1985 Trek 870. As Riv says on their 
>>> cardboard geo charts "don't obsess", but geometrically this old frame is 
>>> not terribly far off some Riv models, setting aside, of course, bb drop and 
>>> stack (1985 Trek 870: 21.8" frame, 71º hta, 71.5º sta, 58.0 tt, 48.5 cs, 
>>> 5.0 drop, 52.7 stack, 40.6 reach).
>>>
>>> My current set-up is Choco bars and an 8cm Dirt Drop. The height feels 
>>> fine, just slightly above saddle height, and the reach isn't bad either but 
>>> could be ~1" longer. I'm fairly upright but can lean in and grip forward as 
>>> needed. I just like the idea of more width and more flare.
>>>
>>> Are these details helpful? I'm maybe leaning toward the 135mm Faceplater 
>>> based on your replies, but that does seem long!
>>> On Sunday, March 10, 2024 at 5:48:02 PM UTC-6 Dan wrote:
>>>
 [image: IMG_9267.jpeg]I’ve got these bars lined up for my Appaloosa 
 build. 
 My local bike shop had a NOS Velo Orange Grand Cru stem in 120mm that 
 looks pretty perfect. It’s 26.0, and having no rise should be slightly 
 longer in reality than its length number suggests. I’m hoping that the 
 wider clamp section will help it to grip the bars well too, despite the 
 single bolt. 


 On Monday 11 March 2024 at 03:33:24 UTC+10:30 Chris K wrote:

> Hey all, I've got some Ortho Bars in my cart and looking for stem 
> advice from those who use this bar. Obv there are multiple fit and frame 
> factors that play into something like this, but curious what people are 
> generally going with. Here are the options I'm deciding between:
>
> - Faceplater 110mm
> - Faceplater 135mm
> - Tallux 12cm
>
> Will the 110 Faceplater be too short?
>
 -- 
>>
>> You received this message because you are subscribed to the Google Groups 
>> "RBW Owners Bunch" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to rbw-owners-bun...@googlegroups.com.
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/rbw-owners-bunch/f184e534-6809-40e7-9930-81c5d5b61ca3n%40googlegroups.com
>>  
>> 
>> .
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails 

Re: [RBW] Re: How do I know when a saddle fits?

[Wesley]

I just want to preface that I am confused but in no way mad:
I made a couple of replies in this thread that were deleted by the 
moderator(s) and I am confused as to why. Apparently I broke some group 
rule(?) and I'd like to avoid doing so in the future so would appreciate 
getting some guidance from the mods. Thanks!
-Wes

On Thursday, March 28, 2024 at 8:46:29 PM UTC-7 Emily Guise wrote:

> Hey all, thanks so much for your insights! I'm local to Portland OR, and 
> there is a bike fitter in town, Pedal PT, who also does physical therapy. 
> I've been wondering if I should get a fit with them, and it seems like I 
> should look into it more seriously.
>
> My travel/adventure/distance bike is a Bike Friday, and that's the one I'd 
> get fit. I do tend to like the flatter saddles, and usually ride with the 
> nose titled up. A challenge is that I have very long arms and legs but a 
> shorter torso. Anyone with a similar body type have any advice?
>
> I have tried women's specific saddles- I tried a Terry Liberator for a 
> while, but it was just SO hard, even though the cutout was fantastic. The 
> same with the Brookses, I always felt like I was sitting on the metal edge 
> or the leather was as unforgiving as wood and as uncomfortable. I'm trying 
> out Riv's new plastic saddle on my Platypus right now. It's sort of 
> comfortable but also feels maybe not quite wide enough. I'll have to give 
> it a few more weeks. 
>
>
> On Thursday, March 28, 2024 at 7:22:12 AM UTC-7 John Dewey wrote:
>
>> Roberta, have you experimented with a cut-out saddle? 
>>
>> Jock
>>
>> On Tue, Mar 26, 2024 at 12:20 AM Roberta  wrote:
>>
>>> The Philadelphia Trek store can measure sits bones. Perhaps there is one 
>>> near you to give you some direction?
>>>
>>> I prefer a flat top like the B68 to a rounder top B17. I also have wide 
>>> sits bones, so B17 too narrow for me.   I tilt the saddle nose up, so I’m 
>>> sitting on the flat back part of the saddle.  Otherwise I slide to the 
>>> front sitting on the nose part, and that is very irritating.  Where are you 
>>> sitting on the saddle?
>>>
>>> Also take notice where the seams of your underwear are when you’re 
>>> riding as sit bones on seams are irritating. 
>>>
>>> Roberta
>>> Philadelphia 
>>>
>>> On Wednesday, March 20, 2024 at 4:00:24 PM UTC-4 Emily Guise wrote:
>>>
 Hello folks, I come to the group with a dilemma. I've never had a 
 saddle that I could ride for longer than 20 miles comfortably. I've always 
 ended up with sore sit bones, numb soft tissue, or both. This has really 
 limited my ability to go on longer trips and after my five day ride on the 
 C canal trail last Sept, it was more apparent than ever I need to find a 
 saddle that won't hurt. 

 I've tried dozens of saddles over the last 15 years- leather, plastic, 
 cutouts, no cutouts, wide, medium, softer, harder, you name it. :( Most of 
 the saddles that have stayed on my bikes for longer than a month have a 
 central cut out, are on the wider side, and plastic. They're good for 
 around town, but that's it. I've never had my sit bones measured. 

 It occurred to me recently that because I've never had a truly 
 comfortable long-distance saddle, I have no idea how one feels. So I 
 figured I'd ask the group. How did The One saddle feel for you? Did it 
 "disappear"? Was it love at first sit? Did it need to be adjusted a lot 
 before finding the ideal position? Is there a certain amount of miles you 
 ride before it becomes uncomfortable? 

 I'd love to hear the group's collective wisdom so I know what to look 
 for in the next saddle I try out. Thanks! 


 -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "RBW Owners Bunch" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to rbw-owners-bun...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/rbw-owners-bunch/a93cb530-6ec0-4fcd-894a-868948892b91n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/bc7f76a0-eabc-466a-9f82-2e28866d133an%40googlegroups.com.

Re: [RBW] Re: How do I know when a saddle fits?

[Wesley]

If you've thought leather saddles felt too hard and wooden, I recommend 
going for an aggressive break-in that breaks the rules you'll often hear 
about being minimal with anything you put on the saddle. So if you still 
have a Brooks that you thought was uncomfortable, here is what I do to 
break them in fast and soft:

- Work mink oil into the leather with all your strength, alternating 
between massaging it in with your thumbs and then flexing the leather up 
and down between your fingers. Really soften it up, focussing on the 
sit-bone areas.
- Give the saddle a deep soak and then ride it wet. It will stretch and 
soften immediately, and very quickly begin to adapt to your shape.

Some folks say to avoid stuff like this because it makes the leather 
stretch, but in my opinion that stretched and well-softened leather is what 
makes a leather saddle comfortable. Maybe they wear out faster (I haven't 
worn one out after five years) but even so, a comfy saddle that you wear 
out is better than a painful saddle that you never use.
-Wes

On Thursday, March 28, 2024 at 8:46:29 PM UTC-7 Emily Guise wrote:

> Hey all, thanks so much for your insights! I'm local to Portland OR, and 
> there is a bike fitter in town, Pedal PT, who also does physical therapy. 
> I've been wondering if I should get a fit with them, and it seems like I 
> should look into it more seriously.
>
> My travel/adventure/distance bike is a Bike Friday, and that's the one I'd 
> get fit. I do tend to like the flatter saddles, and usually ride with the 
> nose titled up. A challenge is that I have very long arms and legs but a 
> shorter torso. Anyone with a similar body type have any advice?
>
> I have tried women's specific saddles- I tried a Terry Liberator for a 
> while, but it was just SO hard, even though the cutout was fantastic. The 
> same with the Brookses, I always felt like I was sitting on the metal edge 
> or the leather was as unforgiving as wood and as uncomfortable. I'm trying 
> out Riv's new plastic saddle on my Platypus right now. It's sort of 
> comfortable but also feels maybe not quite wide enough. I'll have to give 
> it a few more weeks. 
>
>
> On Thursday, March 28, 2024 at 7:22:12 AM UTC-7 John Dewey wrote:
>
>> Roberta, have you experimented with a cut-out saddle? 
>>
>> Jock
>>
>> On Tue, Mar 26, 2024 at 12:20 AM Roberta  wrote:
>>
>>> The Philadelphia Trek store can measure sits bones. Perhaps there is one 
>>> near you to give you some direction?
>>>
>>> I prefer a flat top like the B68 to a rounder top B17. I also have wide 
>>> sits bones, so B17 too narrow for me.   I tilt the saddle nose up, so I’m 
>>> sitting on the flat back part of the saddle.  Otherwise I slide to the 
>>> front sitting on the nose part, and that is very irritating.  Where are you 
>>> sitting on the saddle?
>>>
>>> Also take notice where the seams of your underwear are when you’re 
>>> riding as sit bones on seams are irritating. 
>>>
>>> Roberta
>>> Philadelphia 
>>>
>>> On Wednesday, March 20, 2024 at 4:00:24 PM UTC-4 Emily Guise wrote:
>>>
 Hello folks, I come to the group with a dilemma. I've never had a 
 saddle that I could ride for longer than 20 miles comfortably. I've always 
 ended up with sore sit bones, numb soft tissue, or both. This has really 
 limited my ability to go on longer trips and after my five day ride on the 
 C canal trail last Sept, it was more apparent than ever I need to find a 
 saddle that won't hurt. 

 I've tried dozens of saddles over the last 15 years- leather, plastic, 
 cutouts, no cutouts, wide, medium, softer, harder, you name it. :( Most of 
 the saddles that have stayed on my bikes for longer than a month have a 
 central cut out, are on the wider side, and plastic. They're good for 
 around town, but that's it. I've never had my sit bones measured. 

 It occurred to me recently that because I've never had a truly 
 comfortable long-distance saddle, I have no idea how one feels. So I 
 figured I'd ask the group. How did The One saddle feel for you? Did it 
 "disappear"? Was it love at first sit? Did it need to be adjusted a lot 
 before finding the ideal position? Is there a certain amount of miles you 
 ride before it becomes uncomfortable? 

 I'd love to hear the group's collective wisdom so I know what to look 
 for in the next saddle I try out. Thanks! 


 -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "RBW Owners Bunch" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to rbw-owners-bun...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/rbw-owners-bunch/a93cb530-6ec0-4fcd-894a-868948892b91n%40googlegroups.com
>>>  
>>> 

Re: [RBW] Re: How do I know when a saddle fits?

[Wesley]

Hey Emily,
I'm also a long legs, short torso person. My experience is that I need to 
use a ridiculously tall stem with a short extension, but that doesn't 
really apply in your case because the Bike Friday stem must already have 
odd proportions.

More importantly, if your complaint with Brooks saddles has been their 
hardness, I'd advise breaking all the rules of breaking-in a leather 
saddle. Work mink oil into the leather until it softens. Give the saddle a 
deep soak and ride it wet. You want to really get the leather stretching 
and softening. It's how I like my leather saddles and they do still last 
for many years (I've had mine for five years and I don't see any evidence 
it is wearing out.) It really makes a big difference and the saddle will 
start adapting to your shape in the first few rides.

I hope this helps!
-Wes

On Thursday, March 28, 2024 at 8:46:29 PM UTC-7 Emily Guise wrote:

> Hey all, thanks so much for your insights! I'm local to Portland OR, and 
> there is a bike fitter in town, Pedal PT, who also does physical therapy. 
> I've been wondering if I should get a fit with them, and it seems like I 
> should look into it more seriously.
>
> My travel/adventure/distance bike is a Bike Friday, and that's the one I'd 
> get fit. I do tend to like the flatter saddles, and usually ride with the 
> nose titled up. A challenge is that I have very long arms and legs but a 
> shorter torso. Anyone with a similar body type have any advice?
>
> I have tried women's specific saddles- I tried a Terry Liberator for a 
> while, but it was just SO hard, even though the cutout was fantastic. The 
> same with the Brookses, I always felt like I was sitting on the metal edge 
> or the leather was as unforgiving as wood and as uncomfortable. I'm trying 
> out Riv's new plastic saddle on my Platypus right now. It's sort of 
> comfortable but also feels maybe not quite wide enough. I'll have to give 
> it a few more weeks. 
>
>
> On Thursday, March 28, 2024 at 7:22:12 AM UTC-7 John Dewey wrote:
>
>> Roberta, have you experimented with a cut-out saddle? 
>>
>> Jock
>>
>> On Tue, Mar 26, 2024 at 12:20 AM Roberta  wrote:
>>
>>> The Philadelphia Trek store can measure sits bones. Perhaps there is one 
>>> near you to give you some direction?
>>>
>>> I prefer a flat top like the B68 to a rounder top B17. I also have wide 
>>> sits bones, so B17 too narrow for me.   I tilt the saddle nose up, so I’m 
>>> sitting on the flat back part of the saddle.  Otherwise I slide to the 
>>> front sitting on the nose part, and that is very irritating.  Where are you 
>>> sitting on the saddle?
>>>
>>> Also take notice where the seams of your underwear are when you’re 
>>> riding as sit bones on seams are irritating. 
>>>
>>> Roberta
>>> Philadelphia 
>>>
>>> On Wednesday, March 20, 2024 at 4:00:24 PM UTC-4 Emily Guise wrote:
>>>
 Hello folks, I come to the group with a dilemma. I've never had a 
 saddle that I could ride for longer than 20 miles comfortably. I've always 
 ended up with sore sit bones, numb soft tissue, or both. This has really 
 limited my ability to go on longer trips and after my five day ride on the 
 C canal trail last Sept, it was more apparent than ever I need to find a 
 saddle that won't hurt. 

 I've tried dozens of saddles over the last 15 years- leather, plastic, 
 cutouts, no cutouts, wide, medium, softer, harder, you name it. :( Most of 
 the saddles that have stayed on my bikes for longer than a month have a 
 central cut out, are on the wider side, and plastic. They're good for 
 around town, but that's it. I've never had my sit bones measured. 

 It occurred to me recently that because I've never had a truly 
 comfortable long-distance saddle, I have no idea how one feels. So I 
 figured I'd ask the group. How did The One saddle feel for you? Did it 
 "disappear"? Was it love at first sit? Did it need to be adjusted a lot 
 before finding the ideal position? Is there a certain amount of miles you 
 ride before it becomes uncomfortable? 

 I'd love to hear the group's collective wisdom so I know what to look 
 for in the next saddle I try out. Thanks! 


 -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "RBW Owners Bunch" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to rbw-owners-bun...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/rbw-owners-bunch/a93cb530-6ec0-4fcd-894a-868948892b91n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 

[ceph-users] Re: Slow ops during recovery for RGW index pool only when degraded OSD is primary

[Wesley Dillingham]

Initial indication shows "osd_async_recovery_min_cost = 0"  to be a huge
win here. Some initial thoughts. Were this not for the fact that the index
(and other OMAP pools) were isolated to their own OSDs in this cluster this
tunable would seemingly cause data/blob objects from data pools to async
recover when synchronous recovery might be better for those pools / that
data. I can play around with how this affects the RGW data pools. There was
a Ceph code walk thru video of this topic:
https://www.youtube.com/watch?v=waOtatCpnYs it seems that perhaps
osd_async_recovery_min_cost may have previously been referred to as
osd_async_recover_min_pg_log_entries (both default to 100). For a pool with
OMAP data where each or some OMAP objects are very very large this may not
be a dynamic enough factor to base the decision on. Thanks for the feedback
everybody!


Respectfully,

*Wes Dillingham*
LinkedIn <http://www.linkedin.com/in/wesleydillingham>
w...@wesdillingham.com




On Wed, Apr 3, 2024 at 1:38 PM Joshua Baergen 
wrote:

> We've had success using osd_async_recovery_min_cost=0 to drastically
> reduce slow ops during index recovery.
>
> Josh
>
> On Wed, Apr 3, 2024 at 11:29 AM Wesley Dillingham 
> wrote:
> >
> > I am fighting an issue on an 18.2.0 cluster where a restart of an OSD
> which
> > supports the RGW index pool causes crippling slow ops. If the OSD is
> marked
> > with primary-affinity of 0 prior to the OSD restart no slow ops are
> > observed. If the OSD has a primary affinity of 1 slow ops occur. The slow
> > ops only occur during the recovery period of the OMAP data and further
> only
> > occur when client activity is allowed to pass to the cluster. Luckily I
> am
> > able to test this during periods when I can disable all client activity
> at
> > the upstream proxy.
> >
> > Given the behavior of the primary affinity changes preventing the slow
> ops
> > I think this may be a case of recovery being more detrimental than
> > backfill. I am thinking that causing an pg_temp acting set by forcing
> > backfill may be the right method to mitigate the issue. [1]
> >
> > I believe that reducing the PG log entries for these OSDs would
> accomplish
> > that but I am also thinking a tuning of osd_async_recovery_min_cost [2]
> may
> > also accomplish something similar. Not sure the appropriate tuning for
> that
> > config at this point or if there may be a better approach. Seeking any
> > input here.
> >
> > Further if this issue sounds familiar or sounds like another condition
> > within the OSD may be at hand I would be interested in hearing your input
> > or thoughts. Thanks!
> >
> > [1] https://docs.ceph.com/en/latest/dev/peering/#concepts
> > [2]
> >
> https://docs.ceph.com/en/latest/rados/configuration/osd-config-ref/#confval-osd_async_recovery_min_cost
> >
> > Respectfully,
> >
> > *Wes Dillingham*
> > LinkedIn <http://www.linkedin.com/in/wesleydillingham>
> > w...@wesdillingham.com
> > ___
> > ceph-users mailing list -- ceph-users@ceph.io
> > To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

[ceph-users] Slow ops during recovery for RGW index pool only when degraded OSD is primary

[Wesley Dillingham]

I am fighting an issue on an 18.2.0 cluster where a restart of an OSD which
supports the RGW index pool causes crippling slow ops. If the OSD is marked
with primary-affinity of 0 prior to the OSD restart no slow ops are
observed. If the OSD has a primary affinity of 1 slow ops occur. The slow
ops only occur during the recovery period of the OMAP data and further only
occur when client activity is allowed to pass to the cluster. Luckily I am
able to test this during periods when I can disable all client activity at
the upstream proxy.

Given the behavior of the primary affinity changes preventing the slow ops
I think this may be a case of recovery being more detrimental than
backfill. I am thinking that causing an pg_temp acting set by forcing
backfill may be the right method to mitigate the issue. [1]

I believe that reducing the PG log entries for these OSDs would accomplish
that but I am also thinking a tuning of osd_async_recovery_min_cost [2] may
also accomplish something similar. Not sure the appropriate tuning for that
config at this point or if there may be a better approach. Seeking any
input here.

Further if this issue sounds familiar or sounds like another condition
within the OSD may be at hand I would be interested in hearing your input
or thoughts. Thanks!

[1] https://docs.ceph.com/en/latest/dev/peering/#concepts
[2]
https://docs.ceph.com/en/latest/rados/configuration/osd-config-ref/#confval-osd_async_recovery_min_cost

Respectfully,

*Wes Dillingham*
LinkedIn 
w...@wesdillingham.com
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

[Bug 2059848] Re: Error in the calendar as shown in the print I attached

[Wesley Alves]

** Attachment added: "bug.webm"
   
https://bugs.launchpad.net/ubuntu/+bug/2059848/+attachment/5761449/+files/bug.webm

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

Title:
  Error in the calendar as shown in the print I attached

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


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

Bug#940151: unattended-upgrades: i configure my unattended-upgrade conf with following Origins:

[Wesley Schwengle]

Hi,

> Unattended-Upgrade::Allowed-Origins {
> "o=Debian, a=stable";
> "o=Debian Backports, a=buster-backports"; };

The problem with the example is that it uses a=CODENAME-backports and not
a=stable-backports. The a= should be n= or codename= when using the CODENAME.

I've created PR https://github.com/mvo5/unattended-upgrades/pull/359 for this.

Cheers,
Wesley

[Ubuntu-x-swat] [Bug 2059848] [NEW] Error in the calendar as shown in the print I attached

[Wesley Alves]

Public bug reported:

The error happens when I click on the last days of the calendar

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: xorg 1:7.7+23ubuntu2
ProcVersionSignature: Ubuntu 6.5.0-26.26~22.04.1-generic 6.5.13
Uname: Linux 6.5.0-26-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log'
CasperMD5CheckResult: pass
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Sat Mar 30 16:28:25 2024
DistUpgraded: Fresh install
DistroCodename: jammy
DistroVariant: ubuntu
ExtraDebuggingInterest: No
GraphicsCard:
 Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 
Series] [1002:68f9] (prog-if 00 [VGA controller])
   Subsystem: Hightech Information System Ltd. Cedar [Radeon HD 
5000/6000/7350/8350 Series] [1787:5220]
InstallationDate: Installed on 2024-03-29 (0 days ago)
InstallationMedia: Ubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 
(20240220)
MachineType: Semp Toshiba Informatica Ltda STI 007467
ProcEnviron:
 LANGUAGE=pt_BR:pt:en
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=pt_BR.UTF-8
 SHELL=/usr/bin/zsh
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.5.0-26-generic 
root=UUID=cffe7efc-9ab3-4fe8-93ad-c666ead76093 ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/05/2012
dmi.bios.release: 8.15
dmi.bios.vendor: American Megatrends, Inc.
dmi.bios.version: 1.0
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: STI 007467
dmi.board.vendor: Semp Toshiba Informatica Ltda
dmi.chassis.type: 3
dmi.chassis.vendor: Semp Toshiba Informatica Ltda
dmi.modalias: 
dmi:bvnAmericanMegatrends,Inc.:bvr1.0:bd09/05/2012:br8.15:svnSempToshibaInformaticaLtda:pnSTI007467:pvrRev.10/00:rvnSempToshibaInformaticaLtda:rnSTI007467:rvr:cvnSempToshibaInformaticaLtda:ct3:cvr:skuToBeFilledByO.E.M.:
dmi.product.family: To Be Filled By O.E.M.
dmi.product.name: STI 007467
dmi.product.sku: To Be Filled By O.E.M.
dmi.product.version: Rev. 10/00
dmi.sys.vendor: Semp Toshiba Informatica Ltda
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 23.2.1-1ubuntu3.1~22.04.2
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:21.1.4-2ubuntu1.7~22.04.8
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20210115-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1

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


** Tags: amd64 apport-bug corruption jammy ubuntu wayland-session

** Attachment added: "Gravação de tela de 30-03-2024 16:33:37.webm"
   
https://bugs.launchpad.net/bugs/2059848/+attachment/5760874/+files/Grava%C3%A7%C3%A3o%20de%20tela%20de%2030-03-2024%2016%3A33%3A37.webm

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

Title:
  Error in the calendar as shown in the print I attached

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


___
Mailing list: https://launchpad.net/~ubuntu-x-swat
Post to : ubuntu-x-swat@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-x-swat
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2059848] [NEW] Error in the calendar as shown in the print I attached

[Wesley Alves]

Public bug reported:

The error happens when I click on the last days of the calendar

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: xorg 1:7.7+23ubuntu2
ProcVersionSignature: Ubuntu 6.5.0-26.26~22.04.1-generic 6.5.13
Uname: Linux 6.5.0-26-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log'
CasperMD5CheckResult: pass
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Sat Mar 30 16:28:25 2024
DistUpgraded: Fresh install
DistroCodename: jammy
DistroVariant: ubuntu
ExtraDebuggingInterest: No
GraphicsCard:
 Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 
Series] [1002:68f9] (prog-if 00 [VGA controller])
   Subsystem: Hightech Information System Ltd. Cedar [Radeon HD 
5000/6000/7350/8350 Series] [1787:5220]
InstallationDate: Installed on 2024-03-29 (0 days ago)
InstallationMedia: Ubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 
(20240220)
MachineType: Semp Toshiba Informatica Ltda STI 007467
ProcEnviron:
 LANGUAGE=pt_BR:pt:en
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=pt_BR.UTF-8
 SHELL=/usr/bin/zsh
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.5.0-26-generic 
root=UUID=cffe7efc-9ab3-4fe8-93ad-c666ead76093 ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/05/2012
dmi.bios.release: 8.15
dmi.bios.vendor: American Megatrends, Inc.
dmi.bios.version: 1.0
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: STI 007467
dmi.board.vendor: Semp Toshiba Informatica Ltda
dmi.chassis.type: 3
dmi.chassis.vendor: Semp Toshiba Informatica Ltda
dmi.modalias: 
dmi:bvnAmericanMegatrends,Inc.:bvr1.0:bd09/05/2012:br8.15:svnSempToshibaInformaticaLtda:pnSTI007467:pvrRev.10/00:rvnSempToshibaInformaticaLtda:rnSTI007467:rvr:cvnSempToshibaInformaticaLtda:ct3:cvr:skuToBeFilledByO.E.M.:
dmi.product.family: To Be Filled By O.E.M.
dmi.product.name: STI 007467
dmi.product.sku: To Be Filled By O.E.M.
dmi.product.version: Rev. 10/00
dmi.sys.vendor: Semp Toshiba Informatica Ltda
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 23.2.1-1ubuntu3.1~22.04.2
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:21.1.4-2ubuntu1.7~22.04.8
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20210115-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1

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


** Tags: amd64 apport-bug corruption jammy ubuntu wayland-session

** Attachment added: "Gravação de tela de 30-03-2024 16:33:37.webm"
   
https://bugs.launchpad.net/bugs/2059848/+attachment/5760874/+files/Grava%C3%A7%C3%A3o%20de%20tela%20de%2030-03-2024%2016%3A33%3A37.webm

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/2059848

Title:
  Error in the calendar as shown in the print I attached

Status in xorg package in Ubuntu:
  New

Bug description:
  The error happens when I click on the last days of the calendar

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: xorg 1:7.7+23ubuntu2
  ProcVersionSignature: Ubuntu 6.5.0-26.26~22.04.1-generic 6.5.13
  Uname: Linux 6.5.0-26-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log'
  CasperMD5CheckResult: pass
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Mar 30 16:28:25 2024
  DistUpgraded: Fresh install
  DistroCodename: jammy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: No
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 
Series] [1002:68f9] (prog-if 00 [VGA controller])
 Subsystem: Hightech Information System Ltd. Cedar [Radeon HD 
5000/6000/7350/8350 Series] [1787:5220]
  InstallationDate: Installed on 2024-03-29 (0 days ago)
  InstallationMedia: Ubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 
(20240220)
  MachineType: Semp Toshiba Informatica Ltda STI 007467
  ProcEnviron:
   LANGUAGE=pt_BR:pt:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=pt_BR.UTF-8
   SHELL=/usr/bin/zsh
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.5.0-26-generic 
root=UUID=cffe7efc-9ab3-4fe8-93ad-c666ead76093 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/05/2012
  dmi.bios.release: 8.15
  dmi.bios.vendor: American Megatrends, Inc.
  dmi.bios.version: 1.0
  dmi.board.asset.tag: To Be Filled By O.E.M.
  dmi.board.name: STI 007467
  dmi.board.vendor: Semp Toshiba 

[Desktop-packages] [Bug 2059848] [NEW] Error in the calendar as shown in the print I attached

[Wesley Alves]

Public bug reported:

The error happens when I click on the last days of the calendar

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: xorg 1:7.7+23ubuntu2
ProcVersionSignature: Ubuntu 6.5.0-26.26~22.04.1-generic 6.5.13
Uname: Linux 6.5.0-26-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log'
CasperMD5CheckResult: pass
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Sat Mar 30 16:28:25 2024
DistUpgraded: Fresh install
DistroCodename: jammy
DistroVariant: ubuntu
ExtraDebuggingInterest: No
GraphicsCard:
 Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 
Series] [1002:68f9] (prog-if 00 [VGA controller])
   Subsystem: Hightech Information System Ltd. Cedar [Radeon HD 
5000/6000/7350/8350 Series] [1787:5220]
InstallationDate: Installed on 2024-03-29 (0 days ago)
InstallationMedia: Ubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 
(20240220)
MachineType: Semp Toshiba Informatica Ltda STI 007467
ProcEnviron:
 LANGUAGE=pt_BR:pt:en
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=pt_BR.UTF-8
 SHELL=/usr/bin/zsh
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.5.0-26-generic 
root=UUID=cffe7efc-9ab3-4fe8-93ad-c666ead76093 ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/05/2012
dmi.bios.release: 8.15
dmi.bios.vendor: American Megatrends, Inc.
dmi.bios.version: 1.0
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: STI 007467
dmi.board.vendor: Semp Toshiba Informatica Ltda
dmi.chassis.type: 3
dmi.chassis.vendor: Semp Toshiba Informatica Ltda
dmi.modalias: 
dmi:bvnAmericanMegatrends,Inc.:bvr1.0:bd09/05/2012:br8.15:svnSempToshibaInformaticaLtda:pnSTI007467:pvrRev.10/00:rvnSempToshibaInformaticaLtda:rnSTI007467:rvr:cvnSempToshibaInformaticaLtda:ct3:cvr:skuToBeFilledByO.E.M.:
dmi.product.family: To Be Filled By O.E.M.
dmi.product.name: STI 007467
dmi.product.sku: To Be Filled By O.E.M.
dmi.product.version: Rev. 10/00
dmi.sys.vendor: Semp Toshiba Informatica Ltda
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 23.2.1-1ubuntu3.1~22.04.2
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:21.1.4-2ubuntu1.7~22.04.8
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20210115-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1

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


** Tags: amd64 apport-bug corruption jammy ubuntu wayland-session

** Attachment added: "Gravação de tela de 30-03-2024 16:33:37.webm"
   
https://bugs.launchpad.net/bugs/2059848/+attachment/5760874/+files/Grava%C3%A7%C3%A3o%20de%20tela%20de%2030-03-2024%2016%3A33%3A37.webm

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/2059848

Title:
  Error in the calendar as shown in the print I attached

Status in xorg package in Ubuntu:
  New

Bug description:
  The error happens when I click on the last days of the calendar

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: xorg 1:7.7+23ubuntu2
  ProcVersionSignature: Ubuntu 6.5.0-26.26~22.04.1-generic 6.5.13
  Uname: Linux 6.5.0-26-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.5
  Architecture: amd64
  BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log'
  CasperMD5CheckResult: pass
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Mar 30 16:28:25 2024
  DistUpgraded: Fresh install
  DistroCodename: jammy
  DistroVariant: ubuntu
  ExtraDebuggingInterest: No
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 
Series] [1002:68f9] (prog-if 00 [VGA controller])
 Subsystem: Hightech Information System Ltd. Cedar [Radeon HD 
5000/6000/7350/8350 Series] [1787:5220]
  InstallationDate: Installed on 2024-03-29 (0 days ago)
  InstallationMedia: Ubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 
(20240220)
  MachineType: Semp Toshiba Informatica Ltda STI 007467
  ProcEnviron:
   LANGUAGE=pt_BR:pt:en
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=pt_BR.UTF-8
   SHELL=/usr/bin/zsh
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.5.0-26-generic 
root=UUID=cffe7efc-9ab3-4fe8-93ad-c666ead76093 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 09/05/2012
  dmi.bios.release: 8.15
  dmi.bios.vendor: American Megatrends, Inc.
  dmi.bios.version: 1.0
  dmi.board.asset.tag: To Be Filled By O.E.M.
  dmi.board.name: STI 007467
  dmi.board.vendor: Semp Toshiba Informatica Ltda
  

[Bug 2059848] [NEW] Error in the calendar as shown in the print I attached

[Wesley Alves]

Public bug reported:

The error happens when I click on the last days of the calendar

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: xorg 1:7.7+23ubuntu2
ProcVersionSignature: Ubuntu 6.5.0-26.26~22.04.1-generic 6.5.13
Uname: Linux 6.5.0-26-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log'
CasperMD5CheckResult: pass
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Sat Mar 30 16:28:25 2024
DistUpgraded: Fresh install
DistroCodename: jammy
DistroVariant: ubuntu
ExtraDebuggingInterest: No
GraphicsCard:
 Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 
Series] [1002:68f9] (prog-if 00 [VGA controller])
   Subsystem: Hightech Information System Ltd. Cedar [Radeon HD 
5000/6000/7350/8350 Series] [1787:5220]
InstallationDate: Installed on 2024-03-29 (0 days ago)
InstallationMedia: Ubuntu 22.04.4 LTS "Jammy Jellyfish" - Release amd64 
(20240220)
MachineType: Semp Toshiba Informatica Ltda STI 007467
ProcEnviron:
 LANGUAGE=pt_BR:pt:en
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=pt_BR.UTF-8
 SHELL=/usr/bin/zsh
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.5.0-26-generic 
root=UUID=cffe7efc-9ab3-4fe8-93ad-c666ead76093 ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/05/2012
dmi.bios.release: 8.15
dmi.bios.vendor: American Megatrends, Inc.
dmi.bios.version: 1.0
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: STI 007467
dmi.board.vendor: Semp Toshiba Informatica Ltda
dmi.chassis.type: 3
dmi.chassis.vendor: Semp Toshiba Informatica Ltda
dmi.modalias: 
dmi:bvnAmericanMegatrends,Inc.:bvr1.0:bd09/05/2012:br8.15:svnSempToshibaInformaticaLtda:pnSTI007467:pvrRev.10/00:rvnSempToshibaInformaticaLtda:rnSTI007467:rvr:cvnSempToshibaInformaticaLtda:ct3:cvr:skuToBeFilledByO.E.M.:
dmi.product.family: To Be Filled By O.E.M.
dmi.product.name: STI 007467
dmi.product.sku: To Be Filled By O.E.M.
dmi.product.version: Rev. 10/00
dmi.sys.vendor: Semp Toshiba Informatica Ltda
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 23.2.1-1ubuntu3.1~22.04.2
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:21.1.4-2ubuntu1.7~22.04.8
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20210115-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1

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


** Tags: amd64 apport-bug corruption jammy ubuntu wayland-session

** Attachment added: "Gravação de tela de 30-03-2024 16:33:37.webm"
   
https://bugs.launchpad.net/bugs/2059848/+attachment/5760874/+files/Grava%C3%A7%C3%A3o%20de%20tela%20de%2030-03-2024%2016%3A33%3A37.webm

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

Title:
  Error in the calendar as shown in the print I attached

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


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

[RBW] Re: FS: Rosco Platypus - 60cm - $1600

[Wesley]

Hey Erik, please help us out by saying where you and the Rosco Platy live. 
Thanks!
-Wes

On Saturday, March 30, 2024 at 8:34:31 AM UTC-7 Erik wrote:

> If this one is no longer available, I have a 60cm Rosco Platy complete or 
> frame I am getting ready to post for sale.  
>
> On Thursday, March 28, 2024 at 10:02:23 PM UTC-7 snipp...@gmail.com wrote:
>
>> Did you sell this? 
>>
>> On Saturday, March 2, 2024 at 10:58:22 AM UTC-8 benjamin...@gmail.com 
>> wrote:
>>
>>> Parting ways with my nearly new Rosco Platypus. Located in Chicago. More 
>>> pictures available upon request.
>>>
>>> Deore 11-speed crankset (32t/175mm crankarms)
>>> Deore 11-speed derailleur
>>> Deore 11-speed cassette (11-42)
>>> Deore 11-speed chain
>>> Microshift 11-speed thumbie
>>> Deore v-brakes/levers
>>> SKS b65 fenders
>>> Continental 700x50mm tires
>>> Ergon GC1 grips
>>> 65cm Rivendell Tosco bars with Nitto 31.8mm quill stem (4-bolt/removable 
>>> faceplate)
>>> Alex DM21 rims w/novatec hubs[image: IMG_1489.jpg]
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/36900af6-330a-4e30-88f7-c1d3f3e90fffn%40googlegroups.com.

Bug#1068047: Suspicious commit merged in 2021 from account responsible for xz backdoor

[Wesley Schwengle]

On Fri, Mar 29, 2024 at 07:24:13PM -0700, Russ Allbery wrote:

> So far it looks like no one has been able to figure out an obvious way
> for this to be exploitable, but I wanted to make sure that you were
> aware of this upstream issue:
> 
> https://github.com/libarchive/libarchive/pull/1609
> 
> The author of this commit is the same GitHub account that was used to
> create the xz backdoor. Upstream has merged a revert of this change at:
> 
> https://github.com/libarchive/libarchive/pull/2101
> 
> It may be worth expediting getting this change into Debian in case the
> potential attacker knows something that we don't. However, I don't have
> any reason to currently believe that this is a security vulnerability,
> so I've kept the severity at important and not applied the security tag.

I also noticed this, I send an e-mail to secur...@debian.org about it,
921847da-a715-42c4-b87d-e8a1f0fb5...@schwengle.net. FWIW, this also impacts
Debian stable. The commit can be found in tags: v3.7.2 v3.7.1 v3.7.0 v3.6.2
v3.6.1 v3.6.0. Debian stable ships 3.6.2-1

Cheers,
Wesley

Bug#1068008: rustc: Please package rust 1.75 or higher

[Wesley Schwengle]

Package: rustc
Version: 1.70.0+dfsg1-9
Severity: wishlist
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,


I was trying to build a rust package from source when I noticed they use
traits. Async traits are supported as of 1.75. It would be beneficial to Debian 
that
we can start developing rust with these traits.

Currently upstream sits at 1.77.x, it would be nice if we could get at least to
1.75 , but 1.77.x would be preferred.

https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html


Many thanks and cheers,
Wesley

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'testing'), (100, 'experimental'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rustc depends on:
ii  binutils  2.42-4
ii  gcc   4:13.2.0-7
ii  libc6 2.37-15.1
ii  libc6-dev [libc-dev]  2.37-15.1
ii  libgcc-s1 14-20240315-1
ii  libstd-rust-dev   1.70.0+dfsg1-9

Versions of packages rustc recommends:
ii  cargo0.70.1+ds1-3
ii  llvm-16  1:16.0.6-24

Versions of packages rustc suggests:
ii  clang-16  1:16.0.6-24
pn  lld-16

-- debconf-show failed

Bug#847983: apt: Sid Apt-Pinning ignoring other Release than Experimental

[Wesley Schwengle]

On Tue, Dec 13, 2016 at 08:43:35AM +, Adam D. Barratt wrote:
> On 2016-12-12 20:25, Perl wrote:
> >* What led up to the situation?
> >I noticed, since long time ago, that I was not anymore able to use
> >Apt-Pinning for installing packages from Stable and Testing Releases.
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> >  Everytime I try to use "APT-Pinning", I do not get what I want.
> >  Even if I try /testing or -t testing, or any Release other than
> >  Experimental, I only get error or Experimental list of packages.
> >  Finally, apt-cache policy only return Sid and Experimental
> > packages.
> >* What was the outcome of this action?
> >  If I try
> > "apt-cache show -t testing linux-image-amd64"
> >  OR
> > "apt-cache show linux-image-amd64/testing"
> >  I get this with apt-get:
> > E: Release 'testing' for 'linux-image-amd64' was not found
> > E: No packages found
> 
> Well, the only testing sources.list entries listed in your report are:
> 
> > #Testing
> > deb-src http://ftp.fr.debian.org/debian/ testing main non-free contrib
> > deb-src http://ftp2.fr.debian.org/debian/ testing main contrib non-free
> 
> So I'm not sure where you're expecting apt to find information about
> *binary* packages in testing from.

I agree with this statement and I think we can close this bug because of it.

Cheers,
Wesley

[RBW] Re: I have questions

[Wesley]

When I go on a two day ride, I just put my phone in airplane mode. It (a 
five-year-old iPhone) will stay charged for more than a week that way. When 
I need to use it for anything other than a camera, I take it off airplane 
mode. As Max suggested, you can also carry an external battery for charging 
in a pinch.
-Wes
On Tuesday, March 19, 2024 at 6:10:14 PM UTC-7 Bicycle Belle Ding Ding! 
wrote:

> I have had some of the same questions tumbling about in my brain as I wait 
> for the last of the parts for my Gravel & Travel Platy. I just got back 
> from a warm and delightful weekend of cycling in Philadelphia. I, a newly 
> minted Michigander, was happy to return to the shire, and for that, I was 
> welcomed with Second Winter. 
>
> Michigan is over here, doing me dirty. 
>
> I’m prevailing upon you to humor me and answer my questions, because a lot 
> of you are having spring and flowers and sunshine, so this is the least you 
> could do!
>
> I got the 50 cm Platy to take on trips. Will fit in the van better, will 
> fit on Amtrak, be easier to shove in elevators, that sort of thing. But the 
> tires I have on hand are 48 mm Gravel Kings. They are almost new. I’m 
> considering taking a train to a ride this summer, but that means no Racing 
> Platypus, only the purple one can fit. Can 48 mm tires do a 15-17 mph road 
> ride pace? I have 42 on all my other bikes. Would 48s be slow? The ride is 
> a 2 day event, 100 miles total. I’d like to keep the tires if I could, 
> because they’re new and they are fat enough to also double as gravel tires, 
> should I decide to do a gravel ride again. But I do more road rides than 
> anything else, and if those 48s will cripple me, I’ll go back to 42s. 
> What’s the consensus?
>
> Basket straps. I have the Nitto Basket Rack and even though I’ve disliked 
> it in the past, I figure it’s pretty and I already own it and I might need 
> a front rack for travel. But do I really have to put the ugly strap from 
> bar to basket? Is the Nitto Basket Rack safer than the Mark’s Rack? I know 
> Sergio was thrown when his Mark’s Rack loosened and hit the front tire and 
> he’s missing significant chunks of front teeth! What is everyone doing 
> about their front racks?
>
> Lights. I have an Edelux light. It’s not the right color for this build, 
> but it’s perfectly good. But sometimes I think, “wouldn’t it be nice to 
> have a light that would charge your phone?” The Sinewave Beacon 2 will do 
> just that, but it sounds like it’s not a great road light. What are people 
> using to charge phones on long rides away from home?
>
> I ordered my wheels today. This, because J at the Velocity booth in Philly 
> talked me into them when he heard about the theme of my build. Here’s a 
> sneak peek.
>
> And thanks for helping me out here! It’s good to hear people’s experiences 
> and points of view!
> Leah
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/98e5b063-54ba-4456-b662-abc52f95be34n%40googlegroups.com.

[RBW] Re: How do I know when a saddle fits?

[Wesley]

On my most comfortable saddle, I generally start noticing irritation of the 
skin over my sit bones after about 5 hours. Obviously, that's only an issue 
on long rides. This is a well-broken-in Brooks, but it was fairly 
comfortable since new (I worked some flex into the sit bone areas by 
massaging it with mink oil.) I am not expecting to ever have a saddle that 
is painless no matter how long I ride, and I generally don't wear padded 
shorts.
-Wes

On Wednesday, March 20, 2024 at 1:00:24 PM UTC-7 Emily Guise wrote:

> Hello folks, I come to the group with a dilemma. I've never had a saddle 
> that I could ride for longer than 20 miles comfortably. I've always ended 
> up with sore sit bones, numb soft tissue, or both. This has really limited 
> my ability to go on longer trips and after my five day ride on the C 
> canal trail last Sept, it was more apparent than ever I need to find a 
> saddle that won't hurt. 
>
> I've tried dozens of saddles over the last 15 years- leather, plastic, 
> cutouts, no cutouts, wide, medium, softer, harder, you name it. :( Most of 
> the saddles that have stayed on my bikes for longer than a month have a 
> central cut out, are on the wider side, and plastic. They're good for 
> around town, but that's it. I've never had my sit bones measured. 
>
> It occurred to me recently that because I've never had a truly comfortable 
> long-distance saddle, I have no idea how one feels. So I figured I'd ask 
> the group. How did The One saddle feel for you? Did it "disappear"? Was it 
> love at first sit? Did it need to be adjusted a lot before finding the 
> ideal position? Is there a certain amount of miles you ride before it 
> becomes uncomfortable? 
>
> I'd love to hear the group's collective wisdom so I know what to look for 
> in the next saddle I try out. Thanks! 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/4ccc04c2-4fd4-49e7-aaa5-20f548348fc3n%40googlegroups.com.

[ceph-users] Re: Mounting A RBD Via Kernal Modules

[Wesley Dillingham]

I suspect this may be a network / firewall issue between the client and one
OSD-server. Perhaps the 100MB RBD didn't have an object mapped to a PG with
the primary on this problematic OSD host but the 2TB RBD does. Just a
theory.

Respectfully,

*Wes Dillingham*
LinkedIn 
w...@wesdillingham.com




On Mon, Mar 25, 2024 at 12:34 AM duluxoz  wrote:

> Hi Alexander,
>
> Already set (and confirmed by running the command again) - no good, I'm
> afraid.
>
> So I just restart with a brand new image and ran the following commands
> on the ceph cluster and the host respectively. Results are below:
>
> On the ceph cluster:
>
> [code]
>
> rbd create --size 4T my_pool.meta/my_image --data-pool my_pool.data
> --image-feature exclusive-lock --image-feature deep-flatten
> --image-feature fast-diff --image-feature layering --image-feature
> object-map --image-feature data-pool
>
> [/code]
>
> On the host:
>
> [code]
>
> rbd device map my_pool.meta/my_image --id ceph_rbd_user --keyring
> /etc/ceph/ceph.client.ceph_rbd_user.keyring
>
> mkfs.xfs /dev/rbd0
>
> [/code]
>
> Results:
>
> [code]
>
> meta-data=/dev/rbd0  isize=512agcount=32,
> agsize=33554432 blks
>   =   sectsz=512   attr=2, projid32bit=1
>   =   crc=1finobt=1, sparse=1, rmapbt=0
>   =   reflink=1bigtime=1 inobtcount=1
> nrext64=0
> data =   bsize=4096   blocks=1073741824, imaxpct=5
>   =   sunit=16 swidth=16 blks
> naming   =version 2  bsize=4096   ascii-ci=0, ftype=1
> log  =internal log   bsize=4096   blocks=521728, version=2
>   =   sectsz=512   sunit=16 blks, lazy-count=1
> realtime =none   extsz=4096   blocks=0, rtextents=0
> Discarding blocks...Done.
> mkfs.xfs: pwrite failed: Input/output error
> libxfs_bwrite: write failed on (unknown) bno 0x1ff00/0x100, err=5
> mkfs.xfs: Releasing dirty buffer to free list!
> found dirty buffer (bulk) on free list!
> mkfs.xfs: pwrite failed: Input/output error
> libxfs_bwrite: write failed on (unknown) bno 0x0/0x100, err=5
> mkfs.xfs: Releasing dirty buffer to free list!
> found dirty buffer (bulk) on free list!
> mkfs.xfs: pwrite failed: Input/output error
> libxfs_bwrite: write failed on xfs_sb bno 0x0/0x1, err=5
> mkfs.xfs: Releasing dirty buffer to free list!
> found dirty buffer (bulk) on free list!
> mkfs.xfs: pwrite failed: Input/output error
> libxfs_bwrite: write failed on (unknown) bno 0x10080/0x80, err=5
> mkfs.xfs: Releasing dirty buffer to free list!
> found dirty buffer (bulk) on free list!
> mkfs.xfs: read failed: Input/output error
> mkfs.xfs: data size check failed
> mkfs.xfs: filesystem failed to initialize
> [/code]
>
> On 25/03/2024 15:17, Alexander E. Patrakov wrote:
> > Hello Matthew,
> >
> > Is the overwrite enabled in the erasure-coded pool? If not, here is
> > how to fix it:
> >
> > ceph osd pool set my_pool.data allow_ec_overwrites true
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Bug#1066856: apt: please update the URLs in the man pages

[Wesley Schwengle]

Hi,

> In the apt-cache(8) man page:
> 
> http://www.research.att.com/sw/tools/graphviz/ gives a "Page Not Found"
> error.
> 
> http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html should be
> changed to
> https://www.rw.cdl.uni-saarland.de/people/sander/private/html/gsvcg1.html

I fixed these URI's in git, see merge commit 
1c1d8b26f067e7a1f7740718c0ded84ec8a386cb and i

I didn't put closes: #number in one of the commit messages. Anyways, its fixed
and released in apt 2.7.14. Thanks for reporting the bug.

Cheers,
Wesley

Bug#1067472: firefox-esr: Firefox and Firefox ESR should implement update-alternatives and provide a seperate binary

[Wesley Schwengle]

Package: firefox-esr
Version: 115.9.0esr-2
Severity: wishlist
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

I went digging for how firefox works on Debian because I want to make a partial
switch from Google Chrome to firefox. There are some things that could be
improved I think. Mainly by starting to make use of update-alternatives.

I want to start of with by saying this bug is more or less a combination of
bugs #1001724 and #1033594. They both address why I have this wish, for
different reasons.

/usr/bin/firefox is a wrapper script to which looks for $FIREFOX.real, where
$FIREFOX is assuming, firefox. It looks for command firefox, which may be
something else if the user has a wrapper script itself in their PATH and this
than misses its target, #1001724 in short.

The easy way to solve this is IMO a update-alternatives group for firefox like
Google Chrome does (via the Google repo). They have an update-alternatives
group, aptly named `google-chrome', which provides `/usr/bin/google-chrome' and
as a user you can change this to have google-chrome-{unstable,beta,stable} as
your google-chrome. Instead of the wrapper script, firefox-esr should provide
firefox-esr. The firefox package should provide firefox-stable (or similar) and
install itself at a higher level than firefox-esr. This way the firefox binary
"overrides" the ESR. At least, that is my take on it, feel free to swap the
priorities around.

It would be nice if the upstream firefox packages, also adhere to this, eg,
firefox-nightly is already installed as firefox-nightly, but doesn't add an
update-alternatives.

Another reason, besides the wrapper script, is that firefox doesn't really put
profiles in a different path, eg, `~/.config/firefox-nightly',
`~/.config/firefox', etc etc. They however in their compatibility.ini, eg in
`~/.mozilla/firefox/rqowq6li.default-esr/compatibility.ini', you can see a
LastPlatformDIr, which is for the nightly version:

  LastPlatformDir=/usr/lib/firefox-esr

Now, when I run `readlink -m /usr/bin/firefox-nightly' it returns
`/usr/lib/firefox-nightly/firefox'. The LastPlatformDir is the dirname of the
binary. Now, with a propper update-alternative I can also do this on the binary
`/usr/bin/firefox', as this will point to `/etc/alternatives/firefox', which in
turn links to `/usr/bin/firefox-nightly', which is
`/usr/lib/firefox-nightly/firefox'. I can do a little bit of magic with some
shell scripts to startup firefox profiles for different versions.

The wrapper script blocks this from working:

  $ readlink -m /usr/bin/firefox
  /usr/bin/firefox

I hope to see this wish become reality :)


Cheers,
Wesley





-- Package-specific info:

-- Extensions information
Name: Add-ons Search Detection
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Firefox Alpenglow theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Picture-In-Picture
Location: /usr/lib/firefox-esr/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: System theme — auto theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled

Name: Web Compatibility Interventions
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: WebCompat Reporter
Location: 
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled


-- Addons package information
ii  firefox-esr115.9.0esr-2 amd64Mozilla Firefox web browser - 
Extended Support Release (ESR)

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'testing'), (100, 'experimental'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_

Bug#1067441: chromium: Unable to sync profile

[Wesley Schwengle]

Package: chromium
Version: 122.0.6261.128-1
Severity: important
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

I've started up Chromium and want to sync my Google account.

* Create new profile
* Login to Google (succesfully)
  Within Google.com you are known, myaccount.google.com shows your details
* Click on the profile button of your browser
* Clock on "Turn sync on"
* Follow the login sequence
* Notice error in the console:

[29150:29150:0321/112903.702701:ERROR:turn_sync_on_helper.cc(256)] Cannot turn 
Sync On for invalid account.
[29150:29150:0321/112950.431580:ERROR:turn_sync_on_helper.cc(256)] Cannot turn 
Sync On for invalid account.

Doing the same action with the builds of Google itself everything works fine,
tested this with the browsers listed below.

The bug is also present on bookworm, where I tested it with 
122.0.6261.128-1~deb12u1

Cheers,
Wesley


google-chrome-stable:
  Installed: 123.0.6312.58-1
  Candidate: 123.0.6312.58-1
  Version table:
 *** 123.0.6312.58-1 900
900 https://dl.google.com/linux/chrome/deb stable/main amd64 Packages
100 /var/lib/dpkg/status
google-chrome-beta:
  Installed: 123.0.6312.46-1
  Candidate: 123.0.6312.46-1
  Version table:
 *** 123.0.6312.46-1 900
900 https://dl.google.com/linux/chrome/deb stable/main amd64 Packages
100 /var/lib/dpkg/status
google-chrome-unstable:
  Installed: 124.0.6356.2-1
  Candidate: 124.0.6356.2-1
  Version table:
 *** 124.0.6356.2-1 900
900 https://dl.google.com/linux/chrome/deb stable/main amd64 Packages
100 /var/lib/dpkg/status



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'testing'), (100, 'experimental'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common  122.0.6261.128-1
ii  libasound2t641.2.11-1+b1
ii  libatk-bridge2.0-0t642.51.90-4
ii  libatk1.0-0t64   2.51.90-4
ii  libatomic1   14-20240315-1
ii  libatspi2.0-0t64 2.51.90-4
ii  libc62.37-15.1
ii  libcairo21.18.0-2
ii  libcups2t64  2.4.7-1.2+b1
ii  libdbus-1-3  1.14.10-4+b1
ii  libdouble-conversion33.3.0-1+b1
ii  libdrm2  2.4.120-2
ii  libevent-2.1-7t642.1.12-stable-8.1+b1
ii  libexpat12.6.2-1
ii  libflac12t64 1.4.3+ds-2.1
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b2
ii  libgbm1  24.0.3-1
ii  libgcc-s114-20240315-1
ii  libglib2.0-0t64  2.78.4-5
ii  libgtk-3-0t64 [libgtk-3-0]   3.24.41-3
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  libjsoncpp25 1.9.5-6+b2
ii  liblcms2-2   2.14-2+b1
ii  libminizip1t64   1:1.3.dfsg-3.1
ii  libnspr4 2:4.35-1.1+b1
ii  libnss3  2:3.99-1
ii  libopenh264-72.4.1+dfsg-1
ii  libopenjp2-7 2.5.0-2+b3
ii  libopus0 1.4-1+b1
ii  libpango-1.0-0   1.52.1+ds-1
ii  libpng16-16t64   1.6.43-3
ii  libpulse016.1+dfsg1-3+b1
ii  libsnappy1v5 1.1.10-1+b1
ii  libstdc++6   14-20240315-1
ii  libwebp7 1.3.2-0.4+b1
ii  libwebpdemux21.3.2-0.4+b1
ii  libwebpmux3  1.3.2-0.4+b1
ii  libwoff1 1.0.2-2+b1
ii

Bug#1067060: kde-spectacle: Typo in man page, fixed upstream

[Wesley Schwengle]

Package: kde-spectacle
Severity: minor
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

someone on #debian on libera noticed a small typo in the man page. It is fixed
upstream:

https://github.com/KDE/spectacle/commit/992d197d34a0f04ac259e34b2e1e7a821eaff519

Cheers,
Wesley

-- System Information:
Debian Release: 12.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldstable-security'), (500, 
'stable'), (10, 'oldoldstable'), (10, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kde-spectacle depends on:
pn  kio   
ii  libc6 2.36-9+deb12u4
pn  libkf5configcore5 
pn  libkf5configgui5  
pn  libkf5configwidgets5  
pn  libkf5coreaddons5 
pn  libkf5dbusaddons5 
pn  libkf5globalaccel-bin 
pn  libkf5globalaccel5
pn  libkf5guiaddons5  
pn  libkf5i18n5   
pn  libkf5kiocore5
pn  libkf5kiogui5 
pn  libkf5kiowidgets5 
pn  libkf5newstuff5   
pn  libkf5notifications5  
pn  libkf5purpose-bin 
pn  libkf5purpose5
pn  libkf5service-bin 
pn  libkf5service5
pn  libkf5waylandclient5  
pn  libkf5widgetsaddons5  
pn  libkf5windowsystem5   
pn  libkf5xmlgui5 
pn  libkimageannotator0   
pn  libqt5core5a  
pn  libqt5dbus5   
pn  libqt5gui5 | libqt5gui5-gles  
pn  libqt5printsupport5   
pn  libqt5widgets5
pn  libqt5x11extras5  
ii  libstdc++612.2.0-14
pn  libxcb-cursor0
pn  libxcb-image0 
pn  libxcb-util1  
ii  libxcb-xfixes01.15-1
ii  libxcb1   1.15-1
pn  qdbus-qt5 

kde-spectacle recommends no packages.

kde-spectacle suggests no packages.

Bug#1067060: kde-spectacle: Typo in man page, fixed upstream

[Wesley Schwengle]

Package: kde-spectacle
Severity: minor
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

someone on #debian on libera noticed a small typo in the man page. It is fixed
upstream:

https://github.com/KDE/spectacle/commit/992d197d34a0f04ac259e34b2e1e7a821eaff519

Cheers,
Wesley

-- System Information:
Debian Release: 12.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldstable-security'), (500, 
'stable'), (10, 'oldoldstable'), (10, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kde-spectacle depends on:
pn  kio   
ii  libc6 2.36-9+deb12u4
pn  libkf5configcore5 
pn  libkf5configgui5  
pn  libkf5configwidgets5  
pn  libkf5coreaddons5 
pn  libkf5dbusaddons5 
pn  libkf5globalaccel-bin 
pn  libkf5globalaccel5
pn  libkf5guiaddons5  
pn  libkf5i18n5   
pn  libkf5kiocore5
pn  libkf5kiogui5 
pn  libkf5kiowidgets5 
pn  libkf5newstuff5   
pn  libkf5notifications5  
pn  libkf5purpose-bin 
pn  libkf5purpose5
pn  libkf5service-bin 
pn  libkf5service5
pn  libkf5waylandclient5  
pn  libkf5widgetsaddons5  
pn  libkf5windowsystem5   
pn  libkf5xmlgui5 
pn  libkimageannotator0   
pn  libqt5core5a  
pn  libqt5dbus5   
pn  libqt5gui5 | libqt5gui5-gles  
pn  libqt5printsupport5   
pn  libqt5widgets5
pn  libqt5x11extras5  
ii  libstdc++612.2.0-14
pn  libxcb-cursor0
pn  libxcb-image0 
pn  libxcb-util1  
ii  libxcb-xfixes01.15-1
ii  libxcb1   1.15-1
pn  qdbus-qt5 

kde-spectacle recommends no packages.

kde-spectacle suggests no packages.

[ceph-users] Re: activating+undersized+degraded+remapped

[Wesley Dillingham]

You may be suffering from the "crush gives up too soon" situation:

https://docs.ceph.com/en/quincy/rados/troubleshooting/troubleshooting-pg/#crush-gives-up-too-soon

You have a 5+3 with only 8 hosts, you may need to increase your crush
tries. See the link for how to fix

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn <http://www.linkedin.com/in/wesleydillingham>


On Sun, Mar 17, 2024 at 8:18 AM Joachim Kraftmayer - ceph ambassador <
joachim.kraftma...@clyso.com> wrote:

> also helpful is the output of:
>
> cephpg{poolnum}.{pg-id}query
>
> ___
> ceph ambassador DACH
> ceph consultant since 2012
>
> Clyso GmbH - Premier Ceph Foundation Member
>
> https://www.clyso.com/
>
> Am 16.03.24 um 13:52 schrieb Eugen Block:
> > Yeah, the whole story would help to give better advice. With EC the
> > default min_size is k+1, you could reduce the min_size to 5
> > temporarily, this might bring the PGs back online. But the long term
> > fix is to have all required OSDs up and have enough OSDs to sustain an
> > outage.
> >
> > Zitat von Wesley Dillingham :
> >
> >> Please share "ceph osd tree" and "ceph osd df tree" I suspect you
> >> have not
> >> enough hosts to satisfy the EC
> >>
> >> On Sat, Mar 16, 2024, 8:04 AM Deep Dish  wrote:
> >>
> >>> Hello
> >>>
> >>> I found myself in the following situation:
> >>>
> >>> [WRN] PG_AVAILABILITY: Reduced data availability: 3 pgs inactive
> >>>
> >>> pg 4.3d is stuck inactive for 8d, current state
> >>> activating+undersized+degraded+remapped, last acting
> >>> [4,NONE,46,NONE,10,13,NONE,74]
> >>>
> >>> pg 4.6e is stuck inactive for 9d, current state
> >>> activating+undersized+degraded+remapped, last acting
> >>> [NONE,27,77,79,55,48,50,NONE]
> >>>
> >>> pg 4.cb is stuck inactive for 8d, current state
> >>> activating+undersized+degraded+remapped, last acting
> >>> [6,NONE,42,8,60,22,35,45]
> >>>
> >>>
> >>> I have one cephfs with two backing pools -- one for replicated data,
> >>> the
> >>> other for erasure data.  Each pool is mapped to REPLICATED/ vs.
> >>> ERASURE/
> >>> directories on the filesystem.
> >>>
> >>>
> >>> The above pgs. are affecting the ERASURE pool (5+3) backing the
> >>> FS.   How
> >>> can I get ceph to recover these three PGs?
> >>>
> >>>
> >>>
> >>> Thank you.
> >>> ___
> >>> ceph-users mailing list -- ceph-users@ceph.io
> >>> To unsubscribe send an email to ceph-users-le...@ceph.io
> >>>
> >> ___
> >> ceph-users mailing list -- ceph-users@ceph.io
> >> To unsubscribe send an email to ceph-users-le...@ceph.io
> >
> >
> > ___
> > ceph-users mailing list -- ceph-users@ceph.io
> > To unsubscribe send an email to ceph-users-le...@ceph.io
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

[ceph-users] Re: activating+undersized+degraded+remapped

[Wesley Dillingham]

Please share "ceph osd tree" and "ceph osd df tree" I suspect you have not
enough hosts to satisfy the EC

On Sat, Mar 16, 2024, 8:04 AM Deep Dish  wrote:

> Hello
>
> I found myself in the following situation:
>
> [WRN] PG_AVAILABILITY: Reduced data availability: 3 pgs inactive
>
> pg 4.3d is stuck inactive for 8d, current state
> activating+undersized+degraded+remapped, last acting
> [4,NONE,46,NONE,10,13,NONE,74]
>
> pg 4.6e is stuck inactive for 9d, current state
> activating+undersized+degraded+remapped, last acting
> [NONE,27,77,79,55,48,50,NONE]
>
> pg 4.cb is stuck inactive for 8d, current state
> activating+undersized+degraded+remapped, last acting
> [6,NONE,42,8,60,22,35,45]
>
>
> I have one cephfs with two backing pools -- one for replicated data, the
> other for erasure data.  Each pool is mapped to REPLICATED/ vs. ERASURE/
> directories on the filesystem.
>
>
> The above pgs. are affecting the ERASURE pool (5+3) backing the FS.   How
> can I get ceph to recover these three PGs?
>
>
>
> Thank you.
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Bug#626251: apt-get source gets confused by multiple versions in a list

[Wesley Schwengle]

on control system 
at:
https://salsa.debian.org/debian/dovecot.git
Please use:
git clone https://salsa.debian.org/debian/dovecot.git
to retrieve the latest (possibly unreleased) updates to the package.
Skipping already downloaded file 'dovecot_2.3.21+dfsg1-3.dsc'

$ apt-get source -t unstable dovecot
Reading package lists... Done
Selected version '1:2.3.21+dfsg1-3' (unstable) for dovecot
NOTICE: 'dovecot' packaging is maintained in the 'Git' version control system 
at:
https://salsa.debian.org/debian/dovecot.git
Please use:
git clone https://salsa.debian.org/debian/dovecot.git
to retrieve the latest (possibly unreleased) updates to the package.
Skipping already downloaded file 'dovecot_2.3.21+dfsg1-3.dsc'

$ apt-get source -t testing dovecot
Reading package lists... Done
Selected version '1:2.3.21+dfsg1-2' (testing) for dovecot
NOTICE: 'dovecot' packaging is maintained in the 'Git' version control system 
at:
https://salsa.debian.org/debian/dovecot.git
Please use:
git clone https://salsa.debian.org/debian/dovecot.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 9597 kB of source archives.
Get:1 https://deb.debian.org/debian testing/main dovecot 1:2.3.21+dfsg1-2 (dsc) 
[4076 B]

This all seems to be working as expected. I hope you agree with me :)

This is all tested on the current unstable code, but given that I thought this
looked a lot like #607999 I'm (perhaps wrongfully) assuming this is also fixed
on bookworm.

Cheers,
Wesley

Bug#607999: 'apt-get source $src' fails

[Wesley Schwengle]

Hi all,

On Wed, Feb 28, 2024 at 11:01:53AM +0800, Tianyu Chen wrote:
> In apt-get(8):
> The arguments are interpreted as binary and source package names. See the
> --only-source option if you want to change that.
> I think this bug should be closed now?
> Best regards,
> Tianyu Chen @ deepin

I think this bug can be closed indeed. In apt 2.6.1 (bookworm) 2.7.13+b1 (sid)
this seems to be fixed.

On bookworm:
$ apt-get source --only-source dovecot -t oldstable
Reading package lists... Done
Selected version '1:2.3.13+dfsg1-2+deb11u1' (oldstable) for dovecot
NOTICE: 'dovecot' packaging is maintained in the 'Git' version control system 
at:

$ apt-get source --only-source dovecot
Reading package lists... Done
NOTICE: 'dovecot' packaging is maintained in the 'Git' version control system 
at:
https://salsa.debian.org/debian/dovecot.git
Please use:
git clone https://salsa.debian.org/debian/dovecot.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 9499 kB of source archives.
Get:1 https://deb.debian.org/debian bookworm/main dovecot 1:2.3.19.1+dfsg1-2.1 
(dsc) [4166 B]

$ apt-get source dovecot
Reading package lists... Done
NOTICE: 'dovecot' packaging is maintained in the 'Git' version control system 
at:
https://salsa.debian.org/debian/dovecot.git
Please use:
git clone https://salsa.debian.org/debian/dovecot.git
to retrieve the latest (possibly unreleased) updates to the package.
Skipping already downloaded file 'dovecot_2.3.19.1+dfsg1-2.1.dsc'
Need to get 9495 kB of source archives.
Get:1 https://deb.debian.org/debian bookworm/main dovecot 1:2.3.19.1+dfsg1-2.1 
(tar) [1637 kB]

On sid:
$ apt-get source dovecot -t testing
Reading package lists... Done
Selected version '1:2.3.21+dfsg1-2' (testing) for dovecot
NOTICE: 'dovecot' packaging is maintained in the 'Git' version control system 
at:
https://salsa.debian.org/debian/dovecot.git

apt-get source dovecot-core
Reading package lists... Done
Picking 'dovecot' as source package instead of 'dovecot-core'
NOTICE: 'dovecot' packaging is maintained in the 'Git' version control system 
at:
https://salsa.debian.org/debian/dovecot.git
Please use:
git clone https://salsa.debian.org/debian/dovecot.git
to retrieve the latest (possibly unreleased) updates to the package.
Skipping already downloaded file 'dovecot_2.3.21+dfsg1.orig-pigeonhole.tar.gz'
Need to get 7910 kB of source archives.
Get:1 https://deb.debian.org/debian unstable/main dovecot 1:2.3.21+dfsg1-3 
(dsc) [4090 B]

$ apt-get source --only-source dovecot -t stable
Reading package lists... Done
Selected version '1:2.3.19.1+dfsg1-2.1' (stable) for dovecot
NOTICE: 'dovecot' packaging is maintained in the 'Git' version control system 
at:
https://salsa.debian.org/debian/dovecot.git

$ apt-get source dovecot-core -t stable
Reading package lists... Done
Picking 'dovecot' as source package instead of 'dovecot-core'
Selected version '1:2.3.19.1+dfsg1-2.1' (stable) for dovecot

I think this all works as intended. If you feel this is incorrect, feel free to
reopen the bug.

Cheers,
Wesley

[RBW] Re: Friction Shifting Issues with my Old Clem

[Wesley]

Sounds like an issue my wife had about a year ago. We tried a lot of random 
ideas, like snugging up the cassette lockring (on the theory that the cogs 
were loose and wobbling a bit). In the end, a new chain made the shifting 
work perfectly again. Good luck.
-Wes

On Wednesday, March 13, 2024 at 8:40:52 PM UTC-7 Vincent Tamer wrote:

> I have an on going issue with my friction shifting setup on my 2016 
> complete Clem.
>
> I believe this will be my third cassette replacement now. Each time the 
> two smallest cogs are damaged/stripped for some reason, so that when I 
> pedal there is some crunching & ghost shifting. I cannot pedal with full 
> force on the first two gears.
>
> I’ve had issues with this since day one and I have a feeling it is due to 
> the 2016 complete clem’s shifting setup even though I’ve had it adjusted 
> and have explained to two different bike technicians.
>
> The shifter setup is odd, Riv even commented on how it was a little 
> strange in the Clem intro Pdf that was floating around for the longest time 
> (cannot find it now). I'm hoping someone knows what I'm talking about!
>
> These suntour shifters are set up in a reverse position and that they have 
> some kind of ratcheting mech in them. The clicks don’t always coincide with 
> a shift and maybe that has created some bad friction shifting form on my 
> part. Outside of that I’m at a loss for why I am having issues with 
> stripped cogs. 
>
> I’m considering switching to an indexed set up even though I don’t want to 
> but before I do, does any one have any wisdom they can shed on this 
> situation? Thank you!
>
> Pics are attached, of the whole bike (for fun) and of the shifter. I'll 
> grab some shots of the gears as well when I can.[image: 
> DSCF7718_sml.jpg][image: 
> shifter.jpg]
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/5e99bf7b-9d23-4d8a-b207-bef24257306fn%40googlegroups.com.

Bug#1043465: reportbug: apt install produces errors when run from a non-existing directory

[Wesley Schwengle]

Control: reassign 1.21.22 debconf

On Fri, Aug 11, 2023 at 04:07:11PM +, t3atwv+9rzw960a1ydj0@cs.email wrote:
> Dear Maintainer,
> 
> It doesn't matter which package you try to install, I'm using 'hello' as an 
> example of a very simple package with no dependencies.
> 
> If you try to run an `apt install` command while you are in a directory that 
> has been deleted, you will get error messages.
> 
> Example command:
> $ mkdir /tmp/hello; cd /tmp/hello; rmdir /tmp/hello; sudo apt install hello
> 
> You get an output that includes these lines:
> sh: 0: getcwd() failed: No such file or directory
> sh: 0: getcwd() failed: No such file or directory
> sh: 0: getcwd() failed: No such file or directory
> sh: 0: getcwd() failed: No such file or directory
> sh: 0: getcwd() failed: No such file or directory
> cannot fetch initial working directory: No such file or directory at 
> /usr/sbin/dpkg-preconfigure line 73.
> cannot fetch initial working directory: No such file or directory at 
> /usr/sbin/dpkg-preconfigure line 159.
> 
> The package installs successfully, but the messages are still not something 
> the user should see.

This is actually a debconf bug as the warnings/errors are emitted by
/usr/sbin/dpkg-preconfigure.

I don't fully agree that this is a bug but I'll let the debconf folks decide
over that. I think it is quite useful to have this information in case things
would go wrong because being in a non-existent directory might not be a normal
situation.

The reproduction path can be slightly adjusted to:
mkdir /tmp/hello; cd /tmp/hello; rmdir /tmp/hello; sudo 
/usr/sbin/dpkg-preconfigure hello

I can verify that the behavior is present on bookworm and unstable.

Cheers,
Wesley

Bug#1065831: document package specifiers for `upgrade`

[Wesley Schwengle]

On Wed, Mar 13, 2024 at 09:44:02AM +0100, Miguel Angel Rojas wrote:
> Hi there,
> 
> > If "apt upgrade" is saying that it removes packages, that is a bug, yes.
> 
> @david: it is not a bug, apparently.
> 
> To put everything in a nutshell:
> 
>- "apt upgrade" can remove packages

No. Without a package as an argument it won't.

>- "apt upgrade" accepts specific packages to be upgraded

To be installed if not installed yet, removed, downgraded or upgraded if
already installed depending on your arguments. For example `apt upgrade foo-
bar+ baz=version toto/archive' will remove foo, add bar, install, up- or
downgrade baz and the same for toto and it will upgrade packages where it can.

> Therefore, this behaviour is expected and documentation needs to be
> modified.
> 
> In the meantime, while the documentation is modified, can some developer
> provide some explanation to the current "apt upgrade" behaviour? (*)

Julian provided an explanation in #74, 20240312113620.ga1944...@debian.org

> whereas `apt upgrade foo` first does the normal install argument handling and
> then runs an upgrade, so `foo` could also be a new package that is not
> currently installed to hint the solver if it is unable to find a solution.



> (*) I'm a bit confused because I don't know which of the people involved in
> this bug are actually a developer of the apt package ;)

I'm not a Debian developer, never been. Just someone who submitted a patch or
two.

Cheers,
Wesley

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Wesley Schwengle]

On Tue, Mar 12, 2024 at 11:40:01AM +0100, Julian Andres Klode wrote:

> On Mon, Mar 11, 2024 at 10:12:33PM -0400, Wesley Schwengle wrote:
> > I do not know what the bug here is, it could be one of these options:
> > 
> > 1) apt-get/apt upgrade accepts packages to upgrade where the docs state it
> >doesn't. The behaviour needs to change to not accept packages.
> > 
> > 2) apt-get/apt upgrade accepts packages and removes packages to satisfy deps
> >where the docs state it doesn't. The behaviour need to change to not 
> > remove
> >any packages. There is a small edge case where you can say: `apt upgrade 
> > foo
> >bar-'. Technically, it shouldn't remove packages, yet you want and 
> > instruct
> >it to remove bar.
> 
> The behavior is correct if potentially unexpected, but it should be
> documented better.

Thanks, it was option 3) Works as intended, documentation needs to be updated.

> > FWIW, aptitude does not remove packages where you call `aptitude 
> > safe-upgrade
> > foo'. It does remove packages when you call `aptitude full-upgrade foo'. It
> > also removes bar when you run `aptitude safe-upgrade foo bar-'. 
> 
> That is an entirely different command; `aptitude safe-upgrade foo`
> upgrades (only) `foo`, whereas `apt upgrade foo` first does the normal
> install argument handling and then runs an upgrade, so `foo` could also
> be a new package that is not currently installed to hint the solver if
> it is unable to find a solution.

Ahhh. I was under the impression that they had a similar intent.

On a related note: While debugging I also noticed apt's update and apt-get's
update are also slightly different. apt-get will not allow for new packages to
be installed whereas apt's version does allow this. You get apt's behaviour
with the --with-new-pkgs switch in apt-get's version of upgrade.

Cheers,
Wesley

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Wesley Schwengle]

On Mon, Mar 11, 2024 at 11:32:24PM +0100, Miguel Angel Rojas wrote:
> > I see. It looks like `apt upgrade ' behaves as `apt install
> > '. Which (to me) is unexpected behaviour, as the man page is
> quite
> >clear on its behaviour (man 8 apt-get):
> 
> Well, clearly it shouldn’t. To begin with, “apt install” should mark a
> package as manual installed while “apt upgrade” shouldn’t (my assumption).
> And you’re right that “apt install” can remove a package if needed to
> satisfy dependencies.
> 
> On top of that, documentation clearly states that “apt upgrade” should not
> remove any package, but it does when you specify an individual package to
> upgrade.
> 
> If this is not the expected behavior, maybe this is a bug (unless I am
> missing something here).

I do not know what the bug here is, it could be one of these options:

1) apt-get/apt upgrade accepts packages to upgrade where the docs state it
   doesn't. The behaviour needs to change to not accept packages.

2) apt-get/apt upgrade accepts packages and removes packages to satisfy deps
   where the docs state it doesn't. The behaviour need to change to not remove
   any packages. There is a small edge case where you can say: `apt upgrade foo
   bar-'. Technically, it shouldn't remove packages, yet you want and instruct
   it to remove bar.

FWIW, aptitude does not remove packages where you call `aptitude safe-upgrade
foo'. It does remove packages when you call `aptitude full-upgrade foo'. It
also removes bar when you run `aptitude safe-upgrade foo bar-'. 

I'll leave this for the maintainers to answer.

Cheers,
Wesley

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Wesley Schwengle]

On Mon, Mar 11, 2024 at 10:48:53PM +0100, Miguel Angel Rojas wrote:
> Hi Wesley, David,
> 
> > You keep saying `apt upgrade' yet your command was `apt full-upgrade'.
> 
> Yes, maybe it didn't express itself properly. After your suggestion about
> not using "apt full-upgrade" during this t64 migration, I followed your
> advice and used only "apt upgrade" for individual upgrades. I was referring
> to this comment you made below:

Ah, and I meant upgrading as individually installing packages ala: `apt install
foo'. I get the confusion now :)

> Now, If I type"apt upgrade" doesn't give me any option to update anything:

Ok, that is expected behaviour.

> But, in some situations, as you mentioned, individual package upgrades can
> work and remove some problems. So what I did was to try some "apt upgrade"
> on individual packages from that list. This time I try the ppp package:
> 
> # apt upgrade ppp
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Calculating upgrade... Done
> The following packages were automatically installed and are no longer
> required:
>  linux-headers-6.6.15-amd64 linux-headers-6.6.15-common
> linux-image-6.6.15-amd64 linux-kbuild-6.6.15
> Use 'apt autoremove' to remove them.
> The following packages will be REMOVED: <--- PACKAGE TO BE REMOVED
>  libpcap0.8
> The following NEW packages will be installed:
>  libpcap0.8t64
>
> [snip]
>
> The following packages will be upgraded:
>  ppp
> 1 upgraded, 1 newly installed, 1 to remove and 22 not upgraded.
> Need to get 511 kB of archives.
> After this operation, 15.4 kB disk space will be freed.
> ,
> 
> As you can see here, I'm typing "apt upgrade ppp" and it removes a package
> in this case: libpcap0.8 (sometimes more packages are removed).
> 
> Which is good, because libpcap0.8 is replaced by libpcap0.8t64 (as expected
> in this t64 migration) but "apt upgrade ppp" is REMOVING a package (which
> contradicts the specification).

I see. It looks like `apt upgrade ' behaves as `apt install
'. Which (to me) is unexpected behaviour, as the man page is quite
clear on its behaviour (man 8 apt-get):

upgrade
   upgrade is used to install the newest versions of **all** (emphasis mine)
   packages currently installed on the system from the sources enumerated in
   /etc/apt/sources.list.

It shouldn't accept the arguments you feed it, apt-get has the same
"feature". And with an install you do remove packages to satisfy the deps.

Cheers,
Wesley

Bug#1066056: vokoscreen-ng: Change depends to allow pipewire/pipewire-pulse

[Wesley Schwengle]

Package: vokoscreen-ng
Version: 3.7.0-1
Severity: wishlist
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

apt-cache depends vokoscreen-ng

[snip]
Recommends: pulseaudio
[snip]

Could you add an OR here with pipewire and/or pipewire-pulse?

Many thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'experimental'), (500, 'testing'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vokoscreen-ng depends on:
ii  gstreamer1.0-plugins-good   1.24.0-1
ii  libc6   2.38-6
ii  libgcc-s1   14-20240303-1
ii  libglib2.0-0t64 [libglib2.0-0]  2.78.4-4
ii  libgstreamer1.0-0   1.24.0-1
ii  libpulse0   16.1+dfsg1-3+b1
ii  libqt5core5t64 [libqt5core5a]   5.15.10+dfsg-7.2
ii  libqt5dbus5t64 [libqt5dbus5]5.15.10+dfsg-7.2
ii  libqt5gui5t64 [libqt5gui5]  5.15.10+dfsg-7.2
ii  libqt5multimedia5   5.15.10-2+b2
ii  libqt5network5t64 [libqt5network5]  5.15.10+dfsg-7.2
ii  libqt5widgets5t64 [libqt5widgets5]  5.15.10+dfsg-7.2
ii  libqt5x11extras55.15.10-2+b1
ii  libstdc++6  14-20240303-1
ii  libwayland-client0  1.22.0-2.1+b1
ii  libx11-62:1.8.7-1

Versions of packages vokoscreen-ng recommends:
ii  gstreamer1.0-libav 1.24.0-1
ii  gstreamer1.0-pulseaudio1.24.0-1
ii  libqt5multimedia5-plugins  5.15.10-2+b2
pn  pulseaudio 

Versions of packages vokoscreen-ng suggests:
ii  gstreamer1.0-plugins-bad   1.24.0-1
ii  gstreamer1.0-plugins-ugly  1.24.0-1
ii  gstreamer1.0-vaapi 1.24.0-1
ii  intel-media-va-driver  24.1.0+dfsg1-1

-- no debconf information

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Wesley Schwengle]

Hi Miguel,

On Mon, Mar 11, 2024 at 05:09:47PM +0100, Miguel Angel Rojas wrote:
> > I do not know, at times I'm also wondering why it doesn't do it, but I
> didn't
> > take time to look at the code to understand what the resolver is doing.
> Also,
> > it was sort of expected. I think we can probably solve this is a more
> > controlled manner. With the current t64 transitioning in unstable it is
> > difficult to track down. Many updates so the situation now may differ
> from the
> > situation in an hour from now.
> 
> Yes, it is confusing for me too. Without considering this t64 migration,
> “apt upgrade” should *NOT* remove any package (just upgrading a package to
> a newer version or install new dependencies). But it is removing packages
> right now! i.e. again, with this t64 migration, it makes the old libraries
> to be uninstalled and install the new *t64 version.
> 
> Any thoughts why “apt upgrade” is removing packages even when documentation
> says it shouldn’t? or is it a bug?

You keep saying `apt upgrade' yet your command was `apt full-upgrade'. As said
earlier, full-upgrade does indeed remove packages to be able to perform an
upgrade. I haven't seen `apt upgrade' do that. So I cannot comment on apt doing
something wrong when it isn't :)

Cheers,
Wesley

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Wesley Schwengle]

Hello Miguel,

On Mon, Mar 11, 2024 at 09:50:12AM +0100, Miguel Angel Rojas wrote:

> >This problem isn't because of apt, the problem is that gdb-minimal/gdb
> >  dependencies cannot be satified. A full-upgrade is the equivalent of a
> >  dist-upgrade which will remove packages to resolve the dependencies. The
> > problem you are facing is the t64 transition[1][2] where not all packages
> are
> >  transitioned.
> 
> I haven't detected any "gdb | gdb-minimal dependencies that can't be
> satisfied at this point. Everything seems to be OK with those packages.

No, there is (or was) something going on with the dependencies of gdm-minimal
for sure. I think it is related to libdebuginfod1, which has a t64 variant.
This one has a dependency to libelf1 and libdw1. Now the libdebuginfod1t64
depends on libelf1t64 and libdw1t64. These two replace libelf1 and libdw1, the
former having a relative high count of reverse dependencies.

> >  My advice to you is: don't expect full-upgrade to work until the
> transitioning
> >   is done.
> 
> You nail it here! I have managed to upgrade package by package but it is a
> tedious process until the whole transition is completed. 

Some of them yes, but often after doing one, you can use `apt upgrade' to
see if it resolved other problems (which in my case it does from time to time).

> But "apt upgrade"
> should not remove any packages according to its documentation (man apt)

That is correct, but you were executing full-upgrade:

> > On Sun, Mar 10, 2024 at 02:13:34PM +0100, Miguel Angel wrote:
> >
> > > # apt full-upgrade
> > > Reading package lists... Done
> > > Building dependency tree... Done
> > > Reading state information... Done
> > > Calculating upgrade... Error!
> > > Some packages could not be installed. This may mean that you have
> > > requested an impossible situation or if you are using the unstable
> > > distribution that some required packages have not yet been created
> > > or been moved out of Incoming.
> > > The following information may help to resolve the situation:

> Why is this t64 upgrade working then as it is removing deprecated packages
> for *t64 packages?

I do not know, at times I'm also wondering why it doesn't do it, but I didn't
take time to look at the code to understand what the resolver is doing. Also,
it was sort of expected. I think we can probably solve this is a more
controlled manner. With the current t64 transitioning in unstable it is
difficult to track down. Many updates so the situation now may differ from the
situation in an hour from now.

> >  This seems to be an more of an actual issue where dependencies are
> declared but
> >apt doing something weird. But that is an issue on bookworm where we
> aren't
> >getting poluted results because of a transitioning.
> 
> I'm glad you were able to replicate in bookworm (stable) it but I don't
> think (at least in this case) it is related to the t64 transition. Same
> errors on both distributions and I checked that gdb dependencies were
> satisfied in unstable (I don't have a system running stable).

I disagree (or agree) to some extent. The gdb-minimal has been held back on my
system for a long time. I removed it after I saw it was a remnant of a KDE
experiment I did. The fact that I can install it now is a change from a couple
of days ago. The bug may be the same, but with how unstable it is now with
this big transition, it's wise to leave it where we are now and break it down
into a more controlled reproduction path, where we don't have so many moving
pieces.

> Appreciate your support.

Yw and good luck!

Cheers,
Wesley

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Wesley Schwengle]

On Sun, Mar 10, 2024 at 02:13:34PM +0100, Miguel Angel wrote:
 
> # apt full-upgrade
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Calculating upgrade... Error!
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  plasma-workspace : Depends: gdb-minimal but it is not going to be installed 
> or
>  gdb
> E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
> held packages.
>

This problem isn't because of apt, the problem is that gdb-minimal/gdb
dependencies cannot be satified. A full-upgrade is the equivalent of a
dist-upgrade which will remove packages to resolve the dependencies. The
problem you are facing is the t64 transition[1][2] where not all packages are
transitioned.

My advice to you is: don't expect full-upgrade to work until the transitioning
is done. You can do `apt upgrade' without too much hassle. If you feel like it
you can inspect individual upgrades possibilities  via `apt list --upgradable'
and upgrade each package individually. That has worked well for me in the past
week with aptitude, but it requires going through many offered solutions.

> I've seen other users are experimenting the same issue:
> https://groups.google.com/g/linux.debian.user/c/7gpQImSH-Cs

This seems to be an more of an actual issue where dependencies are declared but
apt doing something weird. But that is an issue on bookworm where we aren't
getting poluted results because of a transitioning. It differs from yours
because your apt output says "gdb-minimal but it is not going to be installed
or gdb" so apt sees the alternative, but cannot install it either. IMHO, that 
should
be filed as a seperate bug against apt on bookworm. And if possible checked on
testing as well. FWIW, I can reproduce it on bookwork with apt, apt-get and
aptitude, where the latter offers a solution to install gdb and not deinstall
plasma-workspace.

> I don't know why plasma-workspace depends on gdb

I don't know either and that question should be redirected to the
plasma-workspace maintainer.

Cheers,
Wesley

[1] https://lists.debian.org/debian-devel-announce/2024/02/msg0.html
[2] 
https://www.reddit.com/r/debian/comments/1b2ncdn/64bit_time_t_transition_in_progress_in_unstable/

[ceph-users] Re: Ceph-storage slack access

[Wesley Dillingham]

At the very bottom of this page is a link
https://ceph.io/en/community/connect/

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 


On Wed, Mar 6, 2024 at 11:45 AM Matthew Vernon 
wrote:

> Hi,
>
> How does one get an invite to the ceph-storage slack, please?
>
> Thanks,
>
> Matthew
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Re:[cayugabirds-l] geese

[Wesley M. Hochachka]

Based on my understanding about how Merlin Sound ID works, in my opinion the 
answer to your question is "no".  You are wise to not blindly trust that Merlin 
Sound ID found a real Cackling Goose in the flock of geese that you had near 
your house.  There are two aspects of how Merlin Sound ID works that are behind 
my opinion:

  1.
Merlin Sound ID scans through recordings using 3-second-long subsets of an 
entire recording, and within each of these 3-second clips, it assigns each 
vocalization that it can identify to its most likely species.  So, all it would 
take is for one Canada Goose to give a slightly "off" vocalization a single 
time,  or just the right interference from background noise (the microphones 
are phones pick up all sorts of background noise) and "Cackling Goose" could 
pop up as being identified.  You didn't say whether you keep seeing Cackling 
Goose being repeatedly identified, or just a single time during the time that 
Merlin Sound ID was running.  I would tend toward skepticism of any ID that was 
made a single time during the period that Merlin Sound ID is running.
  2.
Behind the curtain, Merlin Sound ID isn't assigning a single species to each 
vocalization that it picks up.  Instead, for every separate vocalization, 
Merlin Sound ID is calculating how close that vocalization is to resembling 
every species for which the Sound ID model has been trained.  So, it is 
possible that Sound ID will consider two species to be very similar in 
likelihood, but the Merlin app only shows you the most likely species 
regardless of whether the most likely, and the second most likely, species 
might both have a very high likelihood of being the species that made the 
vocalization.  In other words, the presentation of information from the Merlin 
Sound ID model can lead to a false impression of certainty in an identification.

   Basically, as with interpretation of output from any machine-learning model, 
human intelligence is required in order to assess whether or not artificial 
stupidity has occurred.

Wesley Hochachka





From: bounce-128062900-3494...@list.cornell.edu 
 on behalf of Marty Schlabach 

Sent: Saturday, March 2, 2024 12:29
To: CAYUGABIRDS-L 
Subject: [cayugabirds-l] geese


One evening earlier this week, a fairly large flock of geese were grazing in 
field well behind our house.  It was almost dark.  I couldn’t see them, but 
could ID Canada and Snow Geese.  I opened Merlin and it IDed Canada, Snow and 
Cackling Geese.



Can I believe Merlin’s ID of the Cackling Geese?



--Marty

===

Marty Schlabach   m...@cornell.edu

8407 Powell Rd. home  607-532-3467

Interlaken, NY 14847   cell315-521-4315

===



--
Cayugabirds-L List Info:
Welcome and Basics<http://www.northeastbirding.com/CayugabirdsWELCOME.htm>
Rules and Information<http://www.northeastbirding.com/CayugabirdsRULES.htm>
Subscribe, Configuration and 
Leave<http://www.northeastbirding.com/CayugabirdsSubscribeConfigurationLeave.htm>
Archives:
The Mail 
Archive<http://www.mail-archive.com/cayugabirds-l@cornell.edu/maillist.html>
Surfbirds<http://www.surfbirds.com/birdingmail/Group/Cayugabirds>
ABA<https://www.aba.org/birding-news/>
Please submit your observations to eBird<http://ebird.org/content/ebird/>!
--

--

(copy & paste any URL below, then modify any text "_DOT_" to a period ".")

Cayugabirds-L List Info:
NortheastBirding_DOT_com/CayugabirdsWELCOME_DOT_htm
NortheastBirding_DOT_com/CayugabirdsRULES_DOT_htm
NortheastBirding_DOT_com/CayugabirdsSubscribeConfigurationLeave_DOT_htm

ARCHIVES:
1) mail-archive_DOT_com/cayugabirds-l@cornell_DOT_edu/maillist_DOT_html
2) surfbirds_DOT_com/birdingmail/Group/Cayugabirds
3) aba_DOT_org/birding-news/

Please submit your observations to eBird:
ebird_DOT_org/content/ebird/

--

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

[Wesley Schwengle]

ing, unstable)]
5)  libglib2.0-0 [2.78.4-1 (now, testing, unstable)]
6)  libglib2.0-0:i386 [2.78.4-1 (now, testing, unstable)]
7)  libpam0g [1.5.2-9.1+b1 (now, testing, unstable)]
8)  libxmlsec1 [1.2.38-1+b1 (now, testing, unstable)]

  Install the following packages:
9)  libapt-pkg6.0t64 [2.7.12+nmu1 (unstable)]
10) libatk1.0-0t64 [2.50.0-1.1 (unstable)]
11) libdb5.3t64 [5.3.28+dfsg2-4.1 (unstable)]
12) libevdocument3-4t64 [45.0-2 (unstable)]
13) libevview3-3t64 [45.0-2 (unstable)]
14) libglib2.0-0t64 [2.78.4-2 (unstable)]
15) libglib2.0-0t64:i386 [2.78.4-2 (unstable)]
16) libpam0t64 [1.5.3-4 (unstable)]
17) libxmlsec1t64 [1.2.39-4 (unstable)]
18) libxmlsec1t64-openssl [1.2.39-4 (unstable)]

  Keep the following packages at their current version:
19) libgspell-1-2 [1.12.2-1+b1 (now, testing, unstable)]
20) libgspell-1-common [1.12.2-1 (now, testing, unstable)]

I haven't committed yet to any solution it gives me, but the last one 
feels like it should be the best


Cheers,
Wesley


--
Wesley Schwengle
E: wes...@schwengle.net

___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel

Bug#1064969: apt: can't upgrade with aptitude

[Wesley Schwengle]

ing, unstable)]
5)  libglib2.0-0 [2.78.4-1 (now, testing, unstable)]
6)  libglib2.0-0:i386 [2.78.4-1 (now, testing, unstable)]
7)  libpam0g [1.5.2-9.1+b1 (now, testing, unstable)]
8)  libxmlsec1 [1.2.38-1+b1 (now, testing, unstable)]

  Install the following packages:
9)  libapt-pkg6.0t64 [2.7.12+nmu1 (unstable)]
10) libatk1.0-0t64 [2.50.0-1.1 (unstable)]
11) libdb5.3t64 [5.3.28+dfsg2-4.1 (unstable)]
12) libevdocument3-4t64 [45.0-2 (unstable)]
13) libevview3-3t64 [45.0-2 (unstable)]
14) libglib2.0-0t64 [2.78.4-2 (unstable)]
15) libglib2.0-0t64:i386 [2.78.4-2 (unstable)]
16) libpam0t64 [1.5.3-4 (unstable)]
17) libxmlsec1t64 [1.2.39-4 (unstable)]
18) libxmlsec1t64-openssl [1.2.39-4 (unstable)]

  Keep the following packages at their current version:
19) libgspell-1-2 [1.12.2-1+b1 (now, testing, unstable)]
20) libgspell-1-common [1.12.2-1 (now, testing, unstable)]

I haven't committed yet to any solution it gives me, but the last one 
feels like it should be the best


Cheers,
Wesley


--
Wesley Schwengle
E: wes...@schwengle.net

Bug#1064919: vokoscreen-ng: Prompts for updates on startup

[Wesley Schwengle]

Package: vokoscreen-ng
Version: 3.7.0-1
Severity: normal
Tags: patch
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

I started up vokoscreen and saw there was an update available for vokoscreen.
When running this app from source that might be great information, but from a
Debian point of view this is unwanted.

I patched vokoscreen-ng with 3 patches, for version 3.5.0 (stable),
v3.7.0 (unstable/testing) and v3.8.0, which would be nice to have in Debian
unstable perhaps?

Patches are attached.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'experimental'), (500, 'testing'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vokoscreen-ng depends on:
ii  gstreamer1.0-plugins-good  1.22.10-1
ii  libc6  2.37-15
ii  libgcc-s1  14-20240201-3
ii  libglib2.0-0   2.78.4-1
ii  libgstreamer1.0-0  1.22.10-1
ii  libpulse0  16.1+dfsg1-3
ii  libqt5core5a   5.15.10+dfsg-7
ii  libqt5dbus55.15.10+dfsg-7
ii  libqt5gui5 5.15.10+dfsg-7
ii  libqt5multimedia5  5.15.10-2+b1
ii  libqt5network5 5.15.10+dfsg-7
ii  libqt5widgets5 5.15.10+dfsg-7
ii  libqt5x11extras5   5.15.10-2+b1
ii  libstdc++6 14-20240201-3
ii  libwayland-client0 1.22.0-2.1+b1
ii  libx11-6   2:1.8.7-1

Versions of packages vokoscreen-ng recommends:
ii  gstreamer1.0-libav 1.22.10-1
ii  gstreamer1.0-pulseaudio1.22.10-1
ii  libqt5multimedia5-plugins  5.15.10-2+b1
pn  pulseaudio 

Versions of packages vokoscreen-ng suggests:
ii  gstreamer1.0-plugins-bad   1.22.10-1
ii  gstreamer1.0-plugins-ugly  1.22.10-1
ii  gstreamer1.0-vaapi 1.22.10-1
ii  intel-media-va-driver  24.1.0+dfsg1-1

-- debconf-show failed
>From eac5373d61b1984b1da8b5a1f019631ff46b4dd2 Mon Sep 17 00:00:00 2001
From: Wesley Schwengle 
Date: Tue, 27 Feb 2024 14:01:25 -0400
Subject: [PATCH] Don't show update information

The application tells a user that an update is available. This is the
opposite of what we want in Debian. We want users to only update when
Debian ships a new .deb. Remove the bits from source.

Signed-off-by: Wesley Schwengle 
---
 src/formMainWindow.ui  | 34 --
 src/information/QvkInformation.cpp | 29 +
 src/information/QvkInformation.h   |  2 --
 3 files changed, 1 insertion(+), 64 deletions(-)

diff --git a/src/formMainWindow.ui b/src/formMainWindow.ui
index 7e17f8cb..e59a4dc3 100644
--- a/src/formMainWindow.ui
+++ b/src/formMainWindow.ui
@@ -2042,40 +2042,6 @@
 

   
-  
-   
-
- 
-  
-   Look for updates
-  
- 
-
-
- 
-  
-   TextLabel
-  
-  
-   true
-  
- 
-
-
- 
-  
-   Qt::Horizontal
-  
-  
-   
-40
-20
-   
-  
- 
-
-   
-  
   

 
diff --git a/src/information/QvkInformation.cpp 
b/src/information/QvkInformation.cpp
index 282a587d..82de9555 100644
--- a/src/information/QvkInformation.cpp
+++ b/src/information/QvkInformation.cpp
@@ -66,11 +66,8 @@ QvkInformation::QvkInformation( QvkMainWindow *vkMainWindow,
 connect( ui->pushButtonPause,SIGNAL( clicked( bool ) ), timerRecord, 
SLOT( stop() ) );
 connect( ui->pushButtonContinue, SIGNAL( clicked( bool ) ), timerRecord, 
SLOT( start() ) );
 
-// Update
+// Debian doesn't need the updates because of the release model
 ui->label_Upate_tab_1->clear();
-ui->label_Upate_tab_4->clear();
-connect( , SIGNAL( signal_newVersionAvailable( QString ) ), this, 
SLOT( slot_newVersionAvailable( QString ) ) );
-connect( ui->checkBoxLookForUpdates, SIGNAL( toggled( bool ) ), , 
SLOT( slot_doDownload( bool ) ) );
 
 // Frames, Format, Codecs
 connect( ui->comboBoxFormat,   SIGNAL( currentTextChanged( QString ) 
), this, SLOT( slot_Format

Bug#1064534: rofi as dmenu replacement

[Wesley Schwengle]

Package: rofi
Version: 1.7.5-0.1+b1
Severity: wishlist
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

I saw a cool thing on /r/unixporn on reddit and it made me look at rofi. I want
to replace it for the dmenu call to dmenu of suckless-tools. However there is
an issue.

rofi states that it is a drop-in replacement for dmenu. If you call rofi as
dmenu, eg by linking it ln -s /usr/bin/rofi /usr/bin/dmenu you get to have all
the toys. This works pretty well as long as you have suckless-tools installed.

Without suckless-tools i3 for example doesn't work correctly. This is because
i3 calls dmenu_run, which is provided by suckless-tools. dmenu_run calls
/usr/bin/dmenu_path which is also provided by suckless-tools.

My question is as follows, is there a way that both suckless-tools and rofi
start providing dmenu (as an update-alternatives) and that both suckless-tools
and rofi depend on a package that is called dmenu-data which provides dmenu_run
and dmenu_path?

I filed this against rofi, because rofi is the one not providing some of the
crucial infra to be a replacement for dmenu.

$ apt-cache depends i3
i3
  Depends: i3-wm
  Recommends: i3lock
  Recommends: suckless-tools
  Recommends: dunst

By implementing the dmenu_path and dmenu_run scripts from suckless-tools the i3
recommends can be either suckless-tools or rofi.

Many thanks!
Wesley



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'experimental'), (500, 'testing'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rofi depends on:
ii  libc6 2.37-15
ii  libcairo2 1.18.0-1+b1
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-3+b1
ii  libglib2.0-0  2.78.4-1
ii  libpango-1.0-01.51.0+ds-4
ii  libpangocairo-1.0-0   1.51.0+ds-4
ii  libstartup-notification0  0.12-6+b1
ii  libxcb-cursor00.1.4-1+b1
ii  libxcb-ewmh2  0.4.1-1.1+b1
ii  libxcb-icccm4 0.4.1-1.1+b1
ii  libxcb-randr0 1.15-1
ii  libxcb-util1  0.4.0-1+b1
ii  libxcb-xinerama0  1.15-1
ii  libxcb-xkb1   1.15-1
ii  libxcb1   1.15-1
ii  libxkbcommon-x11-01.6.0-1
ii  libxkbcommon0 1.6.0-1

rofi recommends no packages.

rofi suggests no packages.

-- no debconf information

Bug#1062772: apt: apt.conf(5) should document all options

[Wesley Schwengle]

Hi Thorsten,


I would expect apt.conf(5) to document any and all configuration
items one can do to apt*, either directly or by other manpages
referenced from “SEE ALSO”.


The man page of apt.conf shows the following:

EXAMPLES
   /usr/share/doc/apt/examples/configure-index.gz is a 
configuration file showing example values for all possible options.


The file location is incorrect (on Debian sid), this should be 
/usr/share/doc/apt/examples/configure-index. It documents all the 
options you can find.


Cheers,
Wesley

--
Wesley Schwengle
E: wes...@schwengle.net

Bug#1064354: steam-installer: Unable to install steam-installer

[Wesley Schwengle]

Package: steam-installer
Severity: important
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

I wanted to install the steam-installer package, this fails:

$ sudo apt-get install steam-installer/unstable
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '1:1.0.0.79~ds-2' (Debian:unstable, Debian:testing [amd64]) 
for 'steam-installer'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 steam-installer : Depends: steam-libs-i386 (= 1:1.0.0.79~ds-2) but it is not 
installable
E: Unable to correct problems, you have held broken packages.

I don't have steam-libs-i386, but I do see steam-libs:

$ apt-cache policy steam-libs
steam-libs:
  Installed: (none)
  Candidate: 1:1.0.0.79~ds-2
  Version table:
 1:1.0.0.79~ds-2 900
900 https://deb.debian.org/debian unstable/main amd64 Packages
500 https://deb.debian.org/debian testing/main amd64 Packages
 1:1.0.0.75+ds-6 10
 10 https://deb.debian.org/debian stable/main amd64 Packages

Which I can also install:
$ sudo apt-get install steam-libs
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  libudev0 nvidia-driver-libs nvidia-vulkan-icd
Recommended packages:
  libasound2-plugins libva-glx2 mesa-vulkan-drivers steam-devices zenity
The following NEW packages will be installed:
  steam-libs
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 18.9 kB of archives.
After this operation, 38.9 kB of additional disk space will be used.
Get:1 https://deb.debian.org/debian unstable/main amd64 steam-libs amd64 
1:1.0.0.79~ds-2 [18.9 kB]
Fetched 18.9 kB in 1s (32.1 kB/s)
Selecting previously unselected package steam-libs:amd64.
(Reading database ... 474365 files and directories currently installed.)
Preparing to unpack .../steam-libs_1%3a1.0.0.79~ds-2_amd64.deb ...
Unpacking steam-libs:amd64 (1:1.0.0.79~ds-2) ...
Setting up steam-libs:amd64 (1:1.0.0.79~ds-2) ...

I tried reinstalled steam-installer, but this failed (as expected, but tried it
none the less):

$ sudo apt-get install steam-installer/unstable
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '1:1.0.0.79~ds-2' (Debian:unstable, Debian:testing [amd64]) 
for 'steam-installer'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 steam-installer : Depends: steam-libs-i386 (= 1:1.0.0.79~ds-2) but it is not 
installable
E: Unable to correct problems, you have held broken packages.

I cannot seem to install it for ANY version of the steam-installer:

$ sudo apt-get install steam-installer/testing
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '1:1.0.0.79~ds-2' (Debian:unstable, Debian:testing [amd64]) 
for 'steam-installer'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 steam-installer : Depends: steam-libs-i386 (= 1:1.0.0.79~ds-2) but it is not 
installable
E: Unable to correct problems, you have held broken packages.

$ sudo apt-get install steam-installer/stable
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '1:1.0.0.75+ds-6' (Debian:12.5/stable [amd64]) for 
'steam-installer'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 steam-installer : Depends: steam-libs (= 1:1.0.0.75+ds-6) but 1:1.0.0.79~ds-2 
is to be installed
   Depends: steam-libs-i386 (>= 1:1.0.0.75+ds-6) but it is not 
installable
E: Unable to correct problems, you have held broken packages.

I've also tried to install it by executing:

sudo dpkg --add-architecture i386

to no avail.




-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'experimental'), 

Bug#1063775: initramfs-tools, and cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead

[Wesley Schwengle]

Small update on the previous message.

It's the same as Debian #1055694, which is upstream bug

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62572


Cheers,
Wesley

--
Wesley Schwengle
E: wes...@schwengle.net

Bug#1063775: initramfs-tools, and cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead

[Wesley Schwengle]

Small update on the previous message.

It's the same as Debian #1055694, which is upstream bug

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62572


Cheers,
Wesley

--
Wesley Schwengle
E: wes...@schwengle.net

[ceph-users] Re: 6 pgs not deep-scrubbed in time

[Wesley Dillingham]

I would just set noout for the duration of the reboot no other flags really
needed. There is a better option to limit that flag to just the host being
rebooted. which is "set-group noout " where  is the servers
name  in CRUSH. Just the global noout will suffice though.

Anyways... your not scrubbed in time warnings arent going away anytime in
the short term until you finish the pg split. In fact, they will get more
numerous until the pg split finishes (did you start that?). If you want to
get rid of the "cosmetic" issue of the warning you can adjust the interval
in which the warning comes up, but I would suggest you leave it since you
are trying to address the root of the situation and want to see the
resolution.



Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn <http://www.linkedin.com/in/wesleydillingham>


On Thu, Feb 1, 2024 at 9:16 AM Michel Niyoyita  wrote:

> And as said before still it is in warning state with pgs not deep-scrubed
> in time . Hope this can be ignored and set those two flags "noout and
> nobackfill" then reboot .
>
> Thank you again Sir
>
> On Thu, 1 Feb 2024, 16:11 Michel Niyoyita,  wrote:
>
>> Thank you very much Janne.
>>
>> On Thu, 1 Feb 2024, 15:21 Janne Johansson,  wrote:
>>
>>> pause and nodown is not a good option to set, that will certainly make
>>> clients stop IO. Pause will stop it immediately, and nodown will stop
>>> IO when the OSD processes stop running on this host.
>>>
>>> When we do service on a host, we set "noout" and "nobackfill", that is
>>> enough for reboots, OS upgrades and simple disk exchanges.
>>> The PGs on this one host will be degraded during the down period, but
>>> IO continues.
>>> Of course this is when the cluster was healthy to begin with (not
>>> counting "not scrubbed in time" warnings, they don't matter in this
>>> case.)
>>>
>>>
>>>
>>> Den tors 1 feb. 2024 kl 12:21 skrev Michel Niyoyita :
>>> >
>>> > Thanks Very much Wesley,
>>> >
>>> > We have decided to restart one host among three osds hosts. before
>>> doing
>>> > that I need the advices of the team . these are flags I want to set
>>> before
>>> > restart.
>>> >
>>> >  'ceph osd set noout'
>>> >  'ceph osd set nobackfill'
>>> >  'ceph osd set norecover'
>>> >  'ceph osd set norebalance'
>>> > 'ceph osd set nodown'
>>> >  'ceph osd set pause'
>>> > 'ceph osd set nodeep-scrub'
>>> > 'ceph osd set noscrub'
>>> >
>>> >
>>> > Would like to ask if this can be enough to set and restart the host
>>> safely
>>> > . the cluster has 3 as replicas.
>>> >
>>> > will the cluster still be accessible while restart the hosts? after
>>> > restarting I will unset the flags.
>>> >
>>> > Kindly advise.
>>> >
>>> > Michel
>>> >
>>> >
>>> > On Tue, 30 Jan 2024, 17:44 Wesley Dillingham, 
>>> wrote:
>>> >
>>> > > actually it seems the issue I had in mind was fixed in 16.2.11 so you
>>> > > should be fine.
>>> > >
>>> > > Respectfully,
>>> > >
>>> > > *Wes Dillingham*
>>> > > w...@wesdillingham.com
>>> > > LinkedIn <http://www.linkedin.com/in/wesleydillingham>
>>> > >
>>> > >
>>> > > On Tue, Jan 30, 2024 at 10:34 AM Wesley Dillingham <
>>> w...@wesdillingham.com>
>>> > > wrote:
>>> > >
>>> > >> You may want to consider upgrading to 16.2.14 before you do the pg
>>> split.
>>> > >>
>>> > >> Respectfully,
>>> > >>
>>> > >> *Wes Dillingham*
>>> > >> w...@wesdillingham.com
>>> > >> LinkedIn <http://www.linkedin.com/in/wesleydillingham>
>>> > >>
>>> > >>
>>> > >> On Tue, Jan 30, 2024 at 10:18 AM Michel Niyoyita >> >
>>> > >> wrote:
>>> > >>
>>> > >>> I tried that on one of my pool (pool id 3) but the number of pgs
>>> not
>>> > >>> deep-scrubbed in time increased also from 55 to 100 but the number
>>> of PGs
>>> > >>> was increased. I set also autoscale to off mode. before continue
>>> to other
>>> > >>

[ceph-users] Re: 6 pgs not deep-scrubbed in time

[Wesley Dillingham]

actually it seems the issue I had in mind was fixed in 16.2.11 so you
should be fine.

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn <http://www.linkedin.com/in/wesleydillingham>


On Tue, Jan 30, 2024 at 10:34 AM Wesley Dillingham 
wrote:

> You may want to consider upgrading to 16.2.14 before you do the pg split.
>
> Respectfully,
>
> *Wes Dillingham*
> w...@wesdillingham.com
> LinkedIn <http://www.linkedin.com/in/wesleydillingham>
>
>
> On Tue, Jan 30, 2024 at 10:18 AM Michel Niyoyita 
> wrote:
>
>> I tried that on one of my pool (pool id 3) but the number of pgs not
>> deep-scrubbed in time increased also from 55 to 100 but the number of PGs
>> was increased. I set also autoscale to off mode. before continue to other
>> pools would like to ask if so far there is no negative impact.
>>
>> ceph -s
>>   cluster:
>> id: cb0caedc-eb5b-42d1-a34f-96facfda8c27
>> health: HEALTH_WARN
>> 100 pgs not deep-scrubbed in time
>>
>>   services:
>> mon: 3 daemons, quorum ceph-mon1,ceph-mon2,ceph-mon3 (age 11M)
>> mgr: ceph-mon2(active, since 11M), standbys: ceph-mon3, ceph-mon1
>> osd: 48 osds: 48 up (since 11M), 48 in (since 12M)
>> rgw: 6 daemons active (6 hosts, 1 zones)
>>
>>   data:
>> pools:   10 pools, 609 pgs
>> objects: 6.03M objects, 23 TiB
>> usage:   151 TiB used, 282 TiB / 433 TiB avail
>> pgs: 603 active+clean
>>  4   active+clean+scrubbing+deep
>>  2   active+clean+scrubbing
>>
>>   io:
>> client:   96 MiB/s rd, 573 MiB/s wr, 576 op/s rd, 648 op/s wr
>>
>> root@ceph-osd3:/var/log# ceph df
>> --- RAW STORAGE ---
>> CLASS SIZEAVAIL USED  RAW USED  %RAW USED
>> hdd433 TiB  282 TiB  151 TiB   151 TiB  34.93
>> TOTAL  433 TiB  282 TiB  151 TiB   151 TiB  34.93
>>
>> --- POOLS ---
>> POOL   ID  PGS   STORED  OBJECTS USED  %USED  MAX
>> AVAIL
>> device_health_metrics   11  1.1 MiB3  3.2 MiB  0 72
>> TiB
>> .rgw.root   2   32  3.7 KiB8   96 KiB  0 72
>> TiB
>> default.rgw.log 3  256  3.6 KiB  204  408 KiB  0 72
>> TiB
>> default.rgw.control 4   32  0 B8  0 B  0 72
>> TiB
>> default.rgw.meta5   32382 B2   24 KiB  0 72
>> TiB
>> volumes 6  128   21 TiB5.74M   62 TiB  22.30 72
>> TiB
>> images      7   32  878 GiB  112.50k  2.6 TiB   1.17 72
>> TiB
>> backups 8   32  0 B0  0 B  0 72
>> TiB
>> vms 9   32  870 GiB  170.73k  2.5 TiB   1.13 72
>> TiB
>> testbench  10   32  0 B0  0 B  0 72
>> TiB
>>
>> On Tue, Jan 30, 2024 at 5:05 PM Wesley Dillingham 
>> wrote:
>>
>>> It will take a couple weeks to a couple months to complete is my best
>>> guess on 10TB spinners at ~40% full. The cluster should be usable
>>> throughout the process.
>>>
>>> Keep in mind, you should disable the pg autoscaler on any pool which you
>>> are manually adjusting the pg_num for. Increasing the pg_num is called "pg
>>> splitting" you can google around for this to see how it will work etc.
>>>
>>> There are a few knobs to increase or decrease the aggressiveness of the
>>> pg split, primarily these are osd_max_backfills and
>>> target_max_misplaced_ratio.
>>>
>>> You can monitor the progress of the split by looking at "ceph osd pool
>>> ls detail" for the pool you are splitting, for this pool pgp_num will
>>> slowly increase up until it reaches the pg_num / pg_num_target.
>>>
>>> IMO this blog post best covers the issue which you are looking to
>>> undertake:
>>> https://ceph.io/en/news/blog/2019/new-in-nautilus-pg-merging-and-autotuning/
>>>
>>> Respectfully,
>>>
>>> *Wes Dillingham*
>>> w...@wesdillingham.com
>>> LinkedIn <http://www.linkedin.com/in/wesleydillingham>
>>>
>>>
>>> On Tue, Jan 30, 2024 at 9:38 AM Michel Niyoyita 
>>> wrote:
>>>
>>>> Thanks for your advices Wes, below is what ceph osd df tree shows , the
>>>> increase of pg_num of the production cluster will not affect the
>>>> performance or crush ? how long it can takes to finish?
>>>>
>>>> ceph osd df tree
>>&

[ceph-users] Re: 6 pgs not deep-scrubbed in time

[Wesley Dillingham]

You may want to consider upgrading to 16.2.14 before you do the pg split.

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn <http://www.linkedin.com/in/wesleydillingham>


On Tue, Jan 30, 2024 at 10:18 AM Michel Niyoyita  wrote:

> I tried that on one of my pool (pool id 3) but the number of pgs not
> deep-scrubbed in time increased also from 55 to 100 but the number of PGs
> was increased. I set also autoscale to off mode. before continue to other
> pools would like to ask if so far there is no negative impact.
>
> ceph -s
>   cluster:
> id: cb0caedc-eb5b-42d1-a34f-96facfda8c27
> health: HEALTH_WARN
> 100 pgs not deep-scrubbed in time
>
>   services:
> mon: 3 daemons, quorum ceph-mon1,ceph-mon2,ceph-mon3 (age 11M)
> mgr: ceph-mon2(active, since 11M), standbys: ceph-mon3, ceph-mon1
> osd: 48 osds: 48 up (since 11M), 48 in (since 12M)
> rgw: 6 daemons active (6 hosts, 1 zones)
>
>   data:
> pools:   10 pools, 609 pgs
> objects: 6.03M objects, 23 TiB
> usage:   151 TiB used, 282 TiB / 433 TiB avail
> pgs: 603 active+clean
>  4   active+clean+scrubbing+deep
>  2   active+clean+scrubbing
>
>   io:
> client:   96 MiB/s rd, 573 MiB/s wr, 576 op/s rd, 648 op/s wr
>
> root@ceph-osd3:/var/log# ceph df
> --- RAW STORAGE ---
> CLASS SIZEAVAIL USED  RAW USED  %RAW USED
> hdd433 TiB  282 TiB  151 TiB   151 TiB  34.93
> TOTAL  433 TiB  282 TiB  151 TiB   151 TiB  34.93
>
> --- POOLS ---
> POOL   ID  PGS   STORED  OBJECTS USED  %USED  MAX AVAIL
> device_health_metrics   11  1.1 MiB3  3.2 MiB  0 72 TiB
> .rgw.root   2   32  3.7 KiB8   96 KiB  0 72 TiB
> default.rgw.log 3  256  3.6 KiB  204  408 KiB  0 72 TiB
> default.rgw.control 4   32  0 B8  0 B  0 72 TiB
> default.rgw.meta5   32382 B2   24 KiB  0 72 TiB
> volumes 6  128   21 TiB5.74M   62 TiB  22.30 72 TiB
> images  7   32  878 GiB  112.50k  2.6 TiB   1.17 72 TiB
> backups 8   32  0 B0  0 B  0 72 TiB
> vms 9   32  870 GiB  170.73k  2.5 TiB   1.13 72 TiB
> testbench  10   32  0 B0  0 B  0 72 TiB
>
> On Tue, Jan 30, 2024 at 5:05 PM Wesley Dillingham 
> wrote:
>
>> It will take a couple weeks to a couple months to complete is my best
>> guess on 10TB spinners at ~40% full. The cluster should be usable
>> throughout the process.
>>
>> Keep in mind, you should disable the pg autoscaler on any pool which you
>> are manually adjusting the pg_num for. Increasing the pg_num is called "pg
>> splitting" you can google around for this to see how it will work etc.
>>
>> There are a few knobs to increase or decrease the aggressiveness of the
>> pg split, primarily these are osd_max_backfills and
>> target_max_misplaced_ratio.
>>
>> You can monitor the progress of the split by looking at "ceph osd pool ls
>> detail" for the pool you are splitting, for this pool pgp_num will slowly
>> increase up until it reaches the pg_num / pg_num_target.
>>
>> IMO this blog post best covers the issue which you are looking to
>> undertake:
>> https://ceph.io/en/news/blog/2019/new-in-nautilus-pg-merging-and-autotuning/
>>
>> Respectfully,
>>
>> *Wes Dillingham*
>> w...@wesdillingham.com
>> LinkedIn <http://www.linkedin.com/in/wesleydillingham>
>>
>>
>> On Tue, Jan 30, 2024 at 9:38 AM Michel Niyoyita 
>> wrote:
>>
>>> Thanks for your advices Wes, below is what ceph osd df tree shows , the
>>> increase of pg_num of the production cluster will not affect the
>>> performance or crush ? how long it can takes to finish?
>>>
>>> ceph osd df tree
>>> ID  CLASS  WEIGHT REWEIGHT  SIZE RAW USE  DATA  OMAP
>>>  META AVAIL%USE   VAR   PGS  STATUS  TYPE NAME
>>> -1 433.11841 -  433 TiB  151 TiB67 TiB  364 MiB  210
>>> GiB  282 TiB  34.86  1.00-  root default
>>> -3 144.37280 -  144 TiB   50 TiB22 TiB  121 MiB   70
>>> GiB   94 TiB  34.86  1.00-  host ceph-osd1
>>>  2hdd9.02330   1.0  9.0 TiB  2.7 TiB  1021 GiB  5.4 MiB  3.7
>>> GiB  6.3 TiB  30.40  0.87   19  up  osd.2
>>>  3hdd9.02330   1.0  9.0 TiB  2.7 TiB   931 GiB  4.1 MiB  3.5
>>> GiB  6.4 TiB  29.43  0.84   29  up  osd.3
&g

[ceph-users] Re: 6 pgs not deep-scrubbed in time

[Wesley Dillingham]

.1 TiB  32.77  0.94   21  up  osd.19
> 21hdd9.02330   1.0  9.0 TiB  2.8 TiB   1.1 TiB  5.5 MiB  3.7
> GiB  6.2 TiB  31.58  0.91   26  up  osd.21
> 24hdd9.02330   1.0  9.0 TiB  2.6 TiB   855 GiB  4.7 MiB  3.3
> GiB  6.4 TiB  28.61  0.82   19  up  osd.24
> 27hdd9.02330   1.0  9.0 TiB  3.7 TiB   1.9 TiB   10 MiB  5.2
> GiB  5.3 TiB  40.84  1.17   24  up  osd.27
> 30hdd9.02330   1.0  9.0 TiB  3.2 TiB   1.4 TiB  7.5 MiB  4.5
> GiB  5.9 TiB  35.16  1.01   22  up  osd.30
> 33hdd9.02330   1.0  9.0 TiB  3.1 TiB   1.4 TiB  8.6 MiB  4.3
> GiB  5.9 TiB  34.59  0.99   23  up  osd.33
> 36hdd9.02330   1.0  9.0 TiB  3.4 TiB   1.7 TiB   10 MiB  5.0
> GiB  5.6 TiB  38.17  1.09   25  up  osd.36
> 39hdd9.02330   1.0  9.0 TiB  3.4 TiB   1.7 TiB  8.5 MiB  5.1
> GiB  5.6 TiB  37.79  1.08   31  up  osd.39
> 42hdd9.02330   1.0  9.0 TiB  3.6 TiB   1.8 TiB   10 MiB  5.2
> GiB  5.4 TiB  39.68  1.14   23  up  osd.42
> 45hdd9.02330   1.0  9.0 TiB  2.7 TiB   964 GiB  5.1 MiB  3.5
> GiB  6.3 TiB  29.78  0.85   21  up  osd.45
> -5 144.37280 -  144 TiB   50 TiB22 TiB  121 MiB   70
> GiB   94 TiB  34.86  1.00-  host ceph-osd3
>  0hdd9.02330   1.0  9.0 TiB  2.7 TiB   934 GiB  4.9 MiB  3.4
> GiB  6.4 TiB  29.47  0.85   21  up  osd.0
>  4hdd9.02330   1.0  9.0 TiB  3.0 TiB   1.2 TiB  6.5 MiB  4.1
> GiB  6.1 TiB  32.73  0.94   22  up  osd.4
>  7hdd9.02330   1.0  9.0 TiB  3.5 TiB   1.8 TiB  9.2 MiB  5.1
> GiB  5.5 TiB  39.02  1.12   30  up  osd.7
> 11hdd9.02330   1.0  9.0 TiB  3.6 TiB   1.9 TiB   10 MiB  5.1
> GiB  5.4 TiB  39.97  1.15   27  up  osd.11
> 14hdd9.02330   1.0  9.0 TiB  3.5 TiB   1.7 TiB   10 MiB  5.1
> GiB  5.6 TiB  38.24  1.10   27  up  osd.14
> 17hdd9.02330   1.0  9.0 TiB  3.0 TiB   1.2 TiB  6.4 MiB  4.1
> GiB  6.0 TiB  33.09  0.95   23  up  osd.17
> 20hdd9.02330   1.0  9.0 TiB  2.8 TiB   1.1 TiB  5.6 MiB  3.8
> GiB  6.2 TiB  31.55  0.90   20  up  osd.20
> 23hdd9.02330   1.0  9.0 TiB  2.6 TiB   828 GiB  4.0 MiB  3.3
> GiB  6.5 TiB  28.32  0.81   23  up  osd.23
> 26hdd9.02330   1.0  9.0 TiB  2.9 TiB   1.2 TiB  5.8 MiB  3.8
> GiB  6.1 TiB  32.12  0.92   26  up  osd.26
> 29hdd9.02330   1.0  9.0 TiB  3.6 TiB   1.8 TiB   10 MiB  5.1
> GiB  5.4 TiB  39.73  1.14   24  up  osd.29
> 31hdd9.02330   1.0  9.0 TiB  2.8 TiB   1.1 TiB  5.8 MiB  3.7
> GiB  6.2 TiB  31.56  0.91   22  up  osd.31
> 34hdd9.02330   1.0  9.0 TiB  3.3 TiB   1.5 TiB  8.2 MiB  4.6
> GiB  5.7 TiB  36.29  1.04   23  up  osd.34
> 37hdd9.02330   1.0  9.0 TiB  3.2 TiB   1.5 TiB  8.2 MiB  4.5
> GiB  5.8 TiB  35.51  1.02   20  up  osd.37
> 40hdd9.02330   1.0  9.0 TiB  3.4 TiB   1.7 TiB  9.3 MiB  4.9
> GiB  5.6 TiB  38.16  1.09   25  up  osd.40
> 43hdd9.02330   1.0  9.0 TiB  3.4 TiB   1.6 TiB  8.5 MiB  4.8
> GiB  5.7 TiB  37.19  1.07   29  up  osd.43
> 46hdd9.02330   1.0  9.0 TiB  3.1 TiB   1.4 TiB  8.4 MiB  4.4
> GiB  5.9 TiB  34.85  1.00   23  up  osd.46
>  TOTAL  433 TiB  151 TiB67 TiB  364 MiB  210
> GiB  282 TiB  34.86
> MIN/MAX VAR: 0.81/1.28  STDDEV: 3.95
>
>
> Michel
>
>
> On Tue, Jan 30, 2024 at 4:18 PM Wesley Dillingham 
> wrote:
>
>> I now concur you should increase the pg_num as a first step for this
>> cluster. Disable the pg autoscaler for and increase the volumes pool to
>> pg_num 256. Then likely re-asses and make the next power of 2 jump to 512
>> and probably beyond.
>>
>> Keep in mind this is not going to fix your short term deep-scrub issue in
>> fact it will increase the number of not scrubbed in time PGs until the
>> pg_num change is complete.  This is because OSDs dont scrub when they are
>> backfilling.
>>
>> I would sit on 256 for a couple weeks and let scrubs happen then continue
>> past 256.
>>
>> with the ultimate target of around 100-200 PGs per OSD which "ceph osd df
>> tree" will show you in the PGs column.
>>
>> Respectfully,
>>
>> *Wes Dillingham*
>> w...@wesdillingham.com
>> LinkedIn <http://www.linkedin.com/in/wesleydillingham>
>>
>>
>> On Tue, Jan 30, 2024 at 3:16 AM Michel Niyoyita 
>> wrote:
>>
>>> Dear te

[ceph-users] Re: 6 pgs not deep-scrubbed in time

[Wesley Dillingham]

I now concur you should increase the pg_num as a first step for this
cluster. Disable the pg autoscaler for and increase the volumes pool to
pg_num 256. Then likely re-asses and make the next power of 2 jump to 512
and probably beyond.

Keep in mind this is not going to fix your short term deep-scrub issue in
fact it will increase the number of not scrubbed in time PGs until the
pg_num change is complete.  This is because OSDs dont scrub when they are
backfilling.

I would sit on 256 for a couple weeks and let scrubs happen then continue
past 256.

with the ultimate target of around 100-200 PGs per OSD which "ceph osd df
tree" will show you in the PGs column.

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 


On Tue, Jan 30, 2024 at 3:16 AM Michel Niyoyita  wrote:

> Dear team,
>
> below is the output of ceph df command and the ceph version I am running
>
>  ceph df
> --- RAW STORAGE ---
> CLASS SIZEAVAIL USED  RAW USED  %RAW USED
> hdd433 TiB  282 TiB  151 TiB   151 TiB  34.82
> TOTAL  433 TiB  282 TiB  151 TiB   151 TiB  34.82
>
> --- POOLS ---
> POOL   ID  PGS   STORED  OBJECTS USED  %USED  MAX AVAIL
> device_health_metrics   11  1.1 MiB3  3.2 MiB  0 73 TiB
> .rgw.root   2   32  3.7 KiB8   96 KiB  0 73 TiB
> default.rgw.log 3   32  3.6 KiB  209  408 KiB  0 73 TiB
> default.rgw.control 4   32  0 B8  0 B  0 73 TiB
> default.rgw.meta5   32382 B2   24 KiB  0 73 TiB
> volumes 6  128   21 TiB5.68M   62 TiB  22.09 73 TiB
> images  7   32  878 GiB  112.50k  2.6 TiB   1.17 73 TiB
> backups 8   32  0 B0  0 B  0 73 TiB
> vms 9   32  881 GiB  174.30k  2.5 TiB   1.13 73 TiB
> testbench  10   32  0 B0  0 B  0 73 TiB
> root@ceph-mon1:~# ceph --version
> ceph version 16.2.11 (3cf40e2dca667f68c6ce3ff5cd94f01e711af894) pacific
> (stable)
> root@ceph-mon1:~#
>
> please advise accordingly
>
> Michel
>
> On Mon, Jan 29, 2024 at 9:48 PM Frank Schilder  wrote:
>
> > You will have to look at the output of "ceph df" and make a decision to
> > balance "objects per PG" and "GB per PG". Increase he PG count for the
> > pools with the worst of these two numbers most such that it balances out
> as
> > much as possible. If you have pools that see significantly more user-IO
> > than others, prioritise these.
> >
> > You will have to find out for your specific cluster, we can only give
> > general guidelines. Make changes, run benchmarks, re-evaluate. Take the
> > time for it. The better you know your cluster and your users, the better
> > the end result will be.
> >
> > Best regards,
> > =
> > Frank Schilder
> > AIT Risø Campus
> > Bygning 109, rum S14
> >
> > 
> > From: Michel Niyoyita 
> > Sent: Monday, January 29, 2024 2:04 PM
> > To: Janne Johansson
> > Cc: Frank Schilder; E Taka; ceph-users
> > Subject: Re: [ceph-users] Re: 6 pgs not deep-scrubbed in time
> >
> > This is how it is set , if you suggest to make some changes please
> advises.
> >
> > Thank you.
> >
> >
> > ceph osd pool ls detail
> > pool 1 'device_health_metrics' replicated size 3 min_size 2 crush_rule 0
> > object_hash rjenkins pg_num 1 pgp_num 1 autoscale_mode on last_change
> 1407
> > flags hashpspool stripe_width 0 pg_num_max 32 pg_num_min 1 application
> > mgr_devicehealth
> > pool 2 '.rgw.root' replicated size 3 min_size 2 crush_rule 0 object_hash
> > rjenkins pg_num 32 pgp_num 32 autoscale_mode on last_change 1393 flags
> > hashpspool stripe_width 0 application rgw
> > pool 3 'default.rgw.log' replicated size 3 min_size 2 crush_rule 0
> > object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode on last_change
> > 1394 flags hashpspool stripe_width 0 application rgw
> > pool 4 'default.rgw.control' replicated size 3 min_size 2 crush_rule 0
> > object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode on last_change
> > 1395 flags hashpspool stripe_width 0 application rgw
> > pool 5 'default.rgw.meta' replicated size 3 min_size 2 crush_rule 0
> > object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode on last_change
> > 1396 flags hashpspool stripe_width 0 pg_autoscale_bias 4 application rgw
> > pool 6 'volumes' replicated size 3 min_size 2 crush_rule 0 object_hash
> > rjenkins pg_num 128 pgp_num 128 autoscale_mode on last_change 108802 lfor
> > 0/0/14812 flags hashpspool,selfmanaged_snaps stripe_width 0 application
> rbd
> > removed_snaps_queue
> >
> [22d7~3,11561~2,11571~1,11573~1c,11594~6,1159b~f,115b0~1,115b3~1,115c3~1,115f3~1,115f5~e,11613~6,1161f~c,11637~1b,11660~1,11663~2,11673~1,116d1~c,116f5~10,11721~c]
> > pool 7 'images' replicated size 3 min_size 2 crush_rule 0 object_hash
> > rjenkins pg_num 32 pgp_num 32 

Bug#1061790: gerbera: Missing files JS files prevent UI from working

[Wesley Schwengle]

Package: gerbera
Version: 2.0.0+dfsg-1
Severity: important
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

I was trying to see how gerbera does m3u playlist support so I installed it
from the repo and tried to access the web UI. What happens is that you only get
to see a login button. Once you click that you get an 404 Not Found error on
http://my.ip:49152/?

When you open http://my.ip:49152 with a developer tool the following files seem
to be missing:

* vendor/tether/tether.min.js
* vendor/md5.min.js
* vendor/font-awesome/fonts/fontawesome-webfont.woff2?v=4.7.0
* vendor/font-awesome/fonts/fontawesome-webfont.woff?v=4.7.0
* vendor/font-awesome/fonts/fontawesome-webfont.ttf?v=4.7.0

I compiled Gerbera from source in $HOME/.local/gerbera and with the same
configuration (abeit a minor change to reflect the change of webroot) the app
works as intented: When enabling the UI and the account you get the
user/password textblocks and you can login.

It seems that the build is not placing the files where one expects them to be.



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'experimental'), (500, 'testing'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.11-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gerbera depends on:
ii  adduser 3.137
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  fonts-lato  2.015-1
ii  init-system-helpers 1.66
ii  libavcodec-extra60 [libavcodec60]   7:6.1.1-1
ii  libavformat60   7:6.1.1-1
ii  libavutil58 7:6.1.1-1
ii  libc6   2.37-14
ii  libcurl3-gnutls 8.5.0-2
ii  libduktape207   2.7.0-2+b1
ii  libebml51.4.5-1
ii  libexif12   0.6.24-1+b1
ii  libexiv2-27 0.27.6-1+b1
ii  libffmpegthumbnailer4v5 2.2.2+git20220218+dfsg-2+b1
ii  libfmt9 9.1.0+ds1-2
ii  libgcc-s1   14-20240127-1
ii  libixml11   1:1.14.18-1
ii  libjs-bootstrap44.6.1+dfsg1-4
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-ui 1.13.2+dfsg-1
ii  libjs-popper.js 1.16.1+ds-6
ii  libjs-prototype 1.7.3-1
ii  libmagic1   1:5.45-2+b1
ii  libmariadb3 1:10.11.6-2
ii  libmatroska71.7.1-1
ii  libpugixml1v5   1.14-0.1
ii  libspdlog1.12 [libspdlog1.12-fmt9]  1:1.12.0+ds-2
ii  libsqlite3-03.45.0-1
ii  libstdc++6  14-20240127-1
ii  libtag1v5   1.13.1-1
ii  libupnp17   1:1.14.18-1
ii  libuuid12.39.3-6
ii  node-js-cookie  3.0.1+~3.0.0-3

gerbera recommends no packages.

Versions of packages gerbera suggests:
ii  chromium [www-browser]121.0.6167.85-1
ii  firefox-esr [www-browser] 115.7.0esr-1
ii  gerbera-doc   2.0.0+dfsg-1
ii  google-chrome-beta [www-browser]  122.0.6261.6-1
ii  google-chrome-stable [www-browser]121.0.6167.85-1
ii  google-chrome-unstable [www-browser]  123.0.6262.5-1
ii  lynx [www-browser]2.9.0rel.0-2
ii  w3m [www-browser] 0.5.3+git20230121-2+b2

-- Configuration Files:
/etc/gerbera/config.xml changed [not included]

-- no debconf information

Bug#1061790: gerbera: Missing files JS files prevent UI from working

[Wesley Schwengle]

Package: gerbera
Version: 2.0.0+dfsg-1
Severity: important
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

I was trying to see how gerbera does m3u playlist support so I installed it
from the repo and tried to access the web UI. What happens is that you only get
to see a login button. Once you click that you get an 404 Not Found error on
http://my.ip:49152/?

When you open http://my.ip:49152 with a developer tool the following files seem
to be missing:

* vendor/tether/tether.min.js
* vendor/md5.min.js
* vendor/font-awesome/fonts/fontawesome-webfont.woff2?v=4.7.0
* vendor/font-awesome/fonts/fontawesome-webfont.woff?v=4.7.0
* vendor/font-awesome/fonts/fontawesome-webfont.ttf?v=4.7.0

I compiled Gerbera from source in $HOME/.local/gerbera and with the same
configuration (abeit a minor change to reflect the change of webroot) the app
works as intented: When enabling the UI and the account you get the
user/password textblocks and you can login.

It seems that the build is not placing the files where one expects them to be.



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'experimental'), (500, 'testing'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.11-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gerbera depends on:
ii  adduser 3.137
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  fonts-lato  2.015-1
ii  init-system-helpers 1.66
ii  libavcodec-extra60 [libavcodec60]   7:6.1.1-1
ii  libavformat60   7:6.1.1-1
ii  libavutil58 7:6.1.1-1
ii  libc6   2.37-14
ii  libcurl3-gnutls 8.5.0-2
ii  libduktape207   2.7.0-2+b1
ii  libebml51.4.5-1
ii  libexif12   0.6.24-1+b1
ii  libexiv2-27 0.27.6-1+b1
ii  libffmpegthumbnailer4v5 2.2.2+git20220218+dfsg-2+b1
ii  libfmt9 9.1.0+ds1-2
ii  libgcc-s1   14-20240127-1
ii  libixml11   1:1.14.18-1
ii  libjs-bootstrap44.6.1+dfsg1-4
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-ui 1.13.2+dfsg-1
ii  libjs-popper.js 1.16.1+ds-6
ii  libjs-prototype 1.7.3-1
ii  libmagic1   1:5.45-2+b1
ii  libmariadb3 1:10.11.6-2
ii  libmatroska71.7.1-1
ii  libpugixml1v5   1.14-0.1
ii  libspdlog1.12 [libspdlog1.12-fmt9]  1:1.12.0+ds-2
ii  libsqlite3-03.45.0-1
ii  libstdc++6  14-20240127-1
ii  libtag1v5   1.13.1-1
ii  libupnp17   1:1.14.18-1
ii  libuuid12.39.3-6
ii  node-js-cookie  3.0.1+~3.0.0-3

gerbera recommends no packages.

Versions of packages gerbera suggests:
ii  chromium [www-browser]121.0.6167.85-1
ii  firefox-esr [www-browser] 115.7.0esr-1
ii  gerbera-doc   2.0.0+dfsg-1
ii  google-chrome-beta [www-browser]  122.0.6261.6-1
ii  google-chrome-stable [www-browser]121.0.6167.85-1
ii  google-chrome-unstable [www-browser]  123.0.6262.5-1
ii  lynx [www-browser]2.9.0rel.0-2
ii  w3m [www-browser] 0.5.3+git20230121-2+b2

-- Configuration Files:
/etc/gerbera/config.xml changed [not included]

-- no debconf information

[ceph-users] Re: 6 pgs not deep-scrubbed in time

[Wesley Dillingham]

Respond back with "ceph versions" output

If your sole goal is to eliminate the not scrubbed in time errors you can
increase the aggressiveness of scrubbing by setting:
osd_max_scrubs = 2

The default in pacific is 1.

if you are going to start tinkering manually with the pg_num you will want
to turn off the pg autoscaler on the pools you are touching.
reducing the size of your PGs may make sense and help with scrubbing but if
the pool has a lot of data it will take a long long time to finish.





Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 


On Mon, Jan 29, 2024 at 10:08 AM Michel Niyoyita  wrote:

> I am running ceph pacific , version 16 , ubuntu 20 OS , deployed using
> ceph-ansible.
>
> Michel
>
> On Mon, Jan 29, 2024 at 4:47 PM Josh Baergen 
> wrote:
>
> > Make sure you're on a fairly recent version of Ceph before doing this,
> > though.
> >
> > Josh
> >
> > On Mon, Jan 29, 2024 at 5:05 AM Janne Johansson 
> > wrote:
> > >
> > > Den mån 29 jan. 2024 kl 12:58 skrev Michel Niyoyita  >:
> > > >
> > > > Thank you Frank ,
> > > >
> > > > All disks are HDDs . Would like to know if I can increase the number
> > of PGs
> > > > live in production without a negative impact to the cluster. if yes
> > which
> > > > commands to use .
> > >
> > > Yes. "ceph osd pool set  pg_num "
> > > where the number usually should be a power of two that leads to a
> > > number of PGs per OSD between 100-200.
> > >
> > > --
> > > May the most significant bit of your life be positive.
> > > ___
> > > ceph-users mailing list -- ceph-users@ceph.io
> > > To unsubscribe send an email to ceph-users-le...@ceph.io
> >
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

[ceph-users] Re: 17.2.7: Backfilling deadlock / stall / stuck / standstill

[Wesley Dillingham]

I faced a similar issue. The PG just would never finish recovery. Changing
all OSDs in the PG to "osd_op_queue wpq" and then restarting them serially
ultimately allowed the PG to recover. Seemed to be some issue with mclock.

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 


On Fri, Jan 26, 2024 at 7:57 AM Kai Stian Olstad 
wrote:

> Hi,
>
> This is a cluster running 17.2.7 upgraded from 16.2.6 on the 15 January
> 2024.
>
> On Monday 22 January we had 4 HDD all on different server with I/O-error
> because of some damage sectors, the OSD is hybrid so the DB is on SSD, 5
> HDD share 1 SSD.
> I set the OSD out, ceph osd out 223 269 290 318 and all hell broke
> loose.
>
> I took only minutes before the users complained about Ceph not working.
> Ceph status reportet slow OPS on the OSDs that was set to out, and “ceph
> tell osd. dump_ops_in_flight” against the out OSDs it just hang,
> after 30 minutes I stopped the dump command.
> Long story short I ended up running “ceph osd set nobackfill” to slow
> ops was gone and then unset it when the slow ops message disappeared.
> I needed to run that all the time so the cluster didn’t come to a holt
> so this oneliner loop was used
> “while true; do ceph -s | grep -qE "oldest one blocked for [0-9]{2,}" &&
> (date; ceph osd set nobackfill; sleep 15; ceph osd unset nobackfill);
> sleep 10; done”
>
>
> But now 4 days later the backfilling has stopped progressing completely
> and the number of misplaced object is increasing.
> Some PG has 0 misplaced object but sill have backfilling state, and been
> in this state for over 24 hours now.
>
> I have a hunch that it’s because of PG 404.6e7 is in state
> “active+recovering+degraded+remapped” it’s been in this state for over
> 48 hours.
> It’s has possible 2 missing object, but since they are not unfound I
> can’t delete them with “ceph pg 404.6e7 mark_unfound_lost delete”
>
> Could someone please help to solve this?
> Down below is some output of ceph commands, I’ll also attache them.
>
>
> ceph status (only removed information about no running scrub and
> deep_scrub)
> ---
>cluster:
>  id: b321e76e-da3a-11eb-b75c-4f948441dcd0
>  health: HEALTH_WARN
>  Degraded data redundancy: 2/6294904971 objects degraded
> (0.000%), 1 pg degraded
>
>services:
>  mon: 3 daemons, quorum ceph-mon-1,ceph-mon-2,ceph-mon-3 (age 11d)
>  mgr: ceph-mon-1.ptrsea(active, since 11d), standbys:
> ceph-mon-2.mfdanx
>  mds: 1/1 daemons up, 1 standby
>  osd: 355 osds: 355 up (since 22h), 351 in (since 4d); 18 remapped
> pgs
>  rgw: 7 daemons active (7 hosts, 1 zones)
>
>data:
>  volumes: 1/1 healthy
>  pools:   14 pools, 3945 pgs
>  objects: 1.14G objects, 1.1 PiB
>  usage:   1.8 PiB used, 1.2 PiB / 3.0 PiB avail
>  pgs: 2/6294904971 objects degraded (0.000%)
>   2980455/6294904971 objects misplaced (0.047%)
>   3901 active+clean
>   22   active+clean+scrubbing+deep
>   17   active+remapped+backfilling
>   4active+clean+scrubbing
>   1active+recovering+degraded+remapped
>
>io:
>  client:   167 MiB/s rd, 13 MiB/s wr, 6.02k op/s rd, 2.35k op/s wr
>
>
> ceph health detail (only removed information about no running scrub and
> deep_scrub)
> ---
> HEALTH_WARN Degraded data redundancy: 2/6294902067 objects degraded
> (0.000%), 1 pg degraded
> [WRN] PG_DEGRADED: Degraded data redundancy: 2/6294902067 objects
> degraded (0.000%), 1 pg degraded
>  pg 404.6e7 is active+recovering+degraded+remapped, acting
> [223,274,243,290,286,283]
>
>
> ceph pg 202.6e7 list_unfound
> ---
> {
>  "num_missing": 2,
>  "num_unfound": 0,
>  "objects": [],
>  "state": "Active",
>  "available_might_have_unfound": true,
>  "might_have_unfound": [],
>  "more": false
> }
>
> ceph pg 404.6e7 query | jq .recovery_state
> ---
> [
>{
>  "name": "Started/Primary/Active",
>  "enter_time": "2024-01-26T09:08:41.918637+",
>  "might_have_unfound": [
>{
>  "osd": "243(2)",
>  "status": "already probed"
>},
>{
>  "osd": "274(1)",
>  "status": "already probed"
>},
>{
>  "osd": "275(0)",
>  "status": "already probed"
>},
>{
>  "osd": "283(5)",
>  "status": "already probed"
>},
>{
>  "osd": "286(4)",
>  "status": "already probed"
>},
>{
>  "osd": "290(3)",
>  "status": "already probed"
>},
>{
>  "osd": "335(3)",
>  "status": "already probed"
>}
>  ],
>  "recovery_progress": {
>"backfill_targets": [
>  "275(0)",
>  "335(3)"
>],
>"waiting_on_backfill": [],
>"last_backfill_started":
>
> 

Bug#1061478: apt: Internal Error, AutoRemover broke stuff, unmet dependencies: linux-headers-6.6.9-amd64

[Wesley Schwengle]

Hi,

TL;DR

One can currently reproduce this behavior on unstable by doing:

```
apt-get install linux-headers-6.6.9-amd64
dpkg -r --force-depends linux-image-6.6.9-amd64-unsigned
apt-get full-upgrade
```

You can fix it by either running:

```
apt-get remove linux-headers-6.6.9-amd64
# or
apt-mark auto linux-headers-6.6.9-amd64
# or but it doesn't make sense
apt --fix-broken install
```

I came across this scenario myself as well and on Reddit. This is my 
take on it.


Around the 11th, linux-image-6.6.9-amd64 was installed. And around the 
18th, linux-image-6.6.11-amd64. During the .9 install I saw similar 
things, I chose to keep everything as is. This caused me to keep running 
on the 6.6.8 kernel at the time.


I think something went wrong with the linux-headers-6.6.9-amd64 and/or 
linux-image-6.6.9-amd64 package. For instance, I didn't have the 
linux-headers-6.6.9-amd64 installed while I had 
linux-headers-6.6.8-amd64 and  linux-headers-6.6.11-amd64 installed. The 
package linux-image-6.6.9-amd64 isn't available in the repositories 
(anymore):


```
$ apt-cache policy linux-image-6.6.9-amd64
linux-image-6.6.9-amd64:
  Installed: (none)
  Candidate: (none)
  Version table:
 6.6.9-1 -1
100 /var/lib/dpkg/status
```

The dependency tree is sorta broken of 6.6.9. The headers have these 
dependencies:


```
$ apt-cache depends linux-headers-6.6.9-amd64
linux-headers-6.6.9-amd64
  Depends: linux-headers-6.6.9-common
 |Depends: linux-image-6.6.9-amd64
  Depends: linux-image-6.6.9-amd64-unsigned
  Depends: linux-kbuild-6.6.9
  Depends: gcc-13
```

Your linux-image-amd64 package depends on:
```
$ apt-cache depends linux-image-amd64
linux-image-amd64
  Depends: linux-image-6.6.13-amd64
```

So now one of your packages is broken. I think it is warrants a look 
into your /var/log/apt/history.log to try to figure out what happened to 
your linux-{image,headers}-* packages around the 11th, 18th and later on.


Cheers,
Wesley

--
Wesley Schwengle
E: wes...@schwengle.net

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

[Wesley Luyten]

Wesley from Mux here. I saw the issue come by.

We'd be happy those API's could get deprecated and unified into the new 
one. 

Our Media Chrome (library, not browser) implementation handles this 
gracefully, some code here 
https://github.com/muxinc/media-chrome/blob/83c1a0f000bc8898971f030bcafa0d6df37cdc34/src/js/controller.js#L636-L636

The Vimeo player uses a variant of https://github.com/bdougherty/BigScreen, 
a similar popular library is https://github.com/sindresorhus/screenfull

Just thought to mention it but iOS never supported the generic fullscreen 
API until very recent 
https://twitter.com/jensimmons/status/1717937227190460797
It always required the webkit prefixed API on the video element (not any 
other element like a div etc )
Y'all are aware of that?
On Wednesday, January 24, 2024 at 6:23:16 PM UTC-6 Thomas Guilbert wrote:

> I opened a support ticket with Mux, and opened an issue for Clappr 
> <https://github.com/clappr/clappr/issues/2136>.
>
> On Wed, Jan 24, 2024 at 3:40 PM Thomas Guilbert  
> wrote:
>
>> I've created a new ChromeStatus entry 
>> <https://chromestatus.com/feature/5111638103687168>, and requested the 
>> privacy/security/debuggability gates for the deprecation trial.
>>
>> I audited a little more than 20 sites from the HTTP Archive. I've found a 
>> few JS player libraries that primarily use the `webkitSupportsFullscreen` 
>> and `webkitDisplayingFullscreen` APIs: Mux and Clappr, and one instance of 
>> PlayerJS.
>> I found websites with a fullscreen button for Mux and PlayerJS, and they 
>> behaved as expected on a build of Chrome without the APIs. The one site I 
>> found using Clappr that had a fullscreen button did not work, both on the 
>> custom build and the latest canary.
>>
>> It also seems like some version of the Vimeo CDN player uses 
>> `webkitEnterFullscreen`: 
>> https://f.vimeocdn.com/p/4.27.1/js/vendor.module.js*.*
>>
>> Thanks,
>> Thomas
>>
>> On Mon, Jan 22, 2024 at 5:31 PM Domenic Denicola  
>> wrote:
>>
>>>
>>>
>>> On Tue, Jan 23, 2024 at 7:55 AM Thomas Guilbert  
>>> wrote:
>>>
>>>> Good point about the most used APIs being the boolean properties! The 
>>>> APIs are now only aliases for the standard non-prefixed fullscreen APIs 
>>>> (see 
>>>> this code for the current implementation 
>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/media/html_video_element.cc;l=418;drc=25705537e65f031d28c1a531046b11914055b7e6>),
>>>>  
>>>> and therefore aren't much of a burden to maintain.
>>>>
>>>> I opened a WebKit standards position here: 
>>>> https://github.com/WebKit/standards-positions/issues/306
>>>>
>>>> I unfortunately do not have access to edit the listed ChromeStatus 
>>>> entry, and the current owner no longer works on Chromium. Should I create 
>>>> a 
>>>> new feature (titled "Deprecation of HTMLVideoElement-specific Prefixed 
>>>> Fullscreen API")? I think the current ChromeStatus entry also covers this 
>>>> API 
>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/fullscreen/element_fullscreen.idl;l=19;drc=047c7dc4ee1ce908d7fea38ca063fa2f80f92c77>
>>>>  
>>>> which I am not trying to deprecate in this Intent.
>>>>
>>>
>>> Yeah, I think a new feature is a good idea. The old feature seems to be 
>>> for the *addition* of the prefixed fullscreen API properties back in 
>>> Chrome 15, whereas a *deprecation/removal* has a different set of 
>>> fields, if I understand correctly.
>>>  
>>>
>>>>
>>>> What's a reasonable sample size of HTTP Archive sites to audit? Should 
>>>> this be a complement/precursor to the proposed Deprecation Trial, or would 
>>>> this sampling be enough?
>>>>
>>>
>>> I recall +Philip Jägenstedt having done some computations in the past 
>>> based on what would actually be statistically significant. But, I couldn't 
>>> find them in this documentation 
>>> <https://www.chromium.org/blink/platform-predictability/compat-tools/> (or 
>>> the linked document 
>>> <https://docs.google.com/document/d/1cpjWFoXBiuFYI4zb9I7wHs7uYZ0ntbOgLwH-mgqXdEM/edit#heading=h.1m1gg72jnnrt>).
>>>  
>>> So, I'll just state that I would be happy with 20 sites.
>>>
>>> I think the deprecation trial is a great complement to have in any case, 

[git-users] Sugar Defender Ingredients: Unraveling the Secrets of Sugar Reduction

[Wesley Virgin]

Sugar Defender Ingredients: Unraveling the Secrets of Sugar Reduction


Sugar, a ubiquitous ingredient in our culinary world, has sparked extensive 
discussions about its detrimental effects on health. Sugar Defender 
Ingredients, This has led to the emergence of sugar defender ingredients, 
substances that aim to reduce or replace added sugar in food products 
without compromising taste or texture. These innovative ingredients hold 
immense promise in curbing sugar consumption and promoting healthier 
dietary choices.

GET YOUR Lean Bliss 75% DISCOUNT NOW  
https://bit.ly/Sugar-Defender--Official

Key Takeaways:
Sugar defender ingredients offer a solution to reduce added sugar in food 
products.

These ingredients can maintain sweetness, texture, and flavor without 
compromising the sensory experience.

Sugar defender ingredients have the potential to positively impact public 
health.

Extensive research and development efforts are underway to discover and 
optimize these ingredients.

Exploring the Realm of Sugar Defender Ingredients
The primary goal of sugar defender ingredients is to mimic the sensory 
properties of sugar, particularly its sweetness. This is achieved through 
various mechanisms, including:

Sweeteners: Artificial sweeteners, such as sucralose, aspartame, and 
stevia, provide sweetness without the caloric content of sugar. They are 
widely used in sugar-free and low-sugar products.

Sugar replacers: Sugar replacers, like polyols (e.g., xylitol, erythritol, 
and sorbitol), bulk sweeteners (e.g., inulin, oligofructose, and resistant 
starch), and natural sweeteners (e.g., monk fruit extract and stevia leaf 
extract), offer sweetness with reduced calories and potential health 
benefits.

Taste modifiers: Taste modifiers, such as flavor enhancers and bitterness 
blockers, can enhance the perception of sweetness and mask undesirable 
flavors, reducing the need for added sugar.

GET YOUR Lean Bliss 75% DISCOUNT NOW  
https://bit.ly/Sugar-Defender--Official

Functional Benefits of Sugar Defender Ingredients
Beyond sweetness, sugar defender ingredients offer several functional 
benefits:

Reduced Calories: Sugar defender ingredients can significantly reduce the 
caloric content of food products, contributing to weight management and 
overall health.

Improved Glycemic Response: Some sugar defender ingredients, like sugar 
replacers, have a low glycemic index, meaning they do not cause a rapid 
rise in blood glucose levels, making them suitable for individuals with 
diabetes or prediabetes.

Dental Health: Sugar defender ingredients can help maintain oral health by 
reducing the risk of tooth decay. Artificial sweeteners, for instance, do 
not promote the growth of bacteria that cause cavities.

Versatility: Sugar defender ingredients can be incorporated into various 
food and beverage products, including baked goods, beverages, 
confectionery, and dairy products.

Scientific Research on Sugar Defender Ingredients
Extensive research efforts are dedicated to understanding the safety, 
efficacy, and potential health effects of sugar defender ingredients. 
Studies have shown:

Safety: Numerous clinical trials and regulatory evaluations have confirmed 
the safety of approved sugar defender ingredients, particularly artificial 
sweeteners.

Glycemic Control: Studies have demonstrated that sugar replacers, such as 
polyols, can help manage blood glucose levels in individuals with diabetes 
or prediabetes.

Weight Management: Some sugar defender ingredients, like artificial 
sweeteners and sugar replacers, have been associated with reduced calorie 
intake and weight loss.

Oral Health: Research suggests that artificial sweeteners can reduce the 
risk of tooth decay and promote oral health.


GET YOUR Lean Bliss 75% DISCOUNT NOW  
https://bit.ly/Sugar-Defender--Official

Challenges and Ongoing Developments
Despite the promising potential of sugar defender ingredients, challenges 
remain:

Taste and Texture: Replicating the taste and texture of sugar remains a 
significant obstacle. Some sugar defender ingredients may have a bitter or 
metallic aftertaste or alter the texture of food products.

Long-Term Effects: While short-term studies have demonstrated the safety of 
sugar defender ingredients, their long-term health effects require further 
investigation.

Regulatory Landscape: Regulatory frameworks for sugar defender ingredients 
vary across jurisdictions, necessitating harmonization and global consensus.

Embracing Sugar Defender Ingredients for a Healthier Future
The drive to reduce sugar consumption and promote healthier dietary choices 
has led to the development of sugar defender ingredients. These ingredients 
offer a range of benefits, including reduced calories, improved glycemic 
response, and dental health benefits. However, challenges related to taste, 
texture, and long-term effects remain. Ongoing research and development 
efforts aim to optimize the sensory properties and safety 

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

[Wesley Eddy]

On 1/17/2024 3:34 AM, mohamed.boucad...@orange.com wrote:
[Med] This can be part of regular code updates. Please note that this 
is not unusual in ipfix (see for example ipv4Options, natevent, etc. 
in https://www.iana.org/assignments/ipfix/ipfix.xhtml which depend on 
an IANA registry).


Ok; do you think the document should explain this in a sentence or two 
for implementers?


If they are not all familiar with details of how ExIDs are used, then it 
seems like a stretch to assume they'll all understand that products need 
to be designed to periodically update ExID definitions.


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

[Wesley Eddy]

On 1/16/2024 11:10 AM, mohamed.boucad...@orange.com wrote:


Are you expecting the implementation to have an exhaustive list of all 
of the ExIDs in use to understand the difference between 2 and 4 byte 
usage?


*/[Med] Yes because otherwise an implem can’t unambiguously identify 
and extract ExIDs. We do provide a pointer to the registered ExIDs:/*


*//*

*/==/*

Additional Information:  See assigned ExIDs at [IANA-TCP-EXIDs].

*/== /*

*//*

*/Please let me know if you still think a clarification is needed to 
the draft. Thanks./*


New ExIDs are able to be added to the IANA registry at any time, just 
via requesting them.  Is an IPFIX implementation expected to 
periodically fetch the registry and reload its known values?




___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

[Wesley Eddy]

The changes look good to me; I just want to make sure you understand one 
of my questions that doesn't look like it was clear enough:


On 1/15/2024 4:13 AM, mohamed.boucad...@orange.com wrote:

- The way an implementation understands the TCP ExIDs may benefit
from slightly more explanation:
   -- In 4.2 and 4.3, is the idea that the implementation is just
sampling the
   16 or 32 bits following the experimental option kind being
indicated, and
   assuming those 2 or 4 bytes to be ExIDs?  From Section 6.2, I
got the sense
   that the implementation is aware of particular ExID values
specifically, to
   know if they should be reported as 2 or 4 byte values.

[Med] 2-byte IDs are reported in tcpSharedOptionExID16 while 4-byte IDs are 
reported in tcpSharedOptionExID32.
Are you expecting the implementation to have an exhaustive list of all 
of the ExIDs in use to understand the difference between 2 and 4 byte 
usage?  I don't quite understand how this is supposed to work at the 
sampling point, since it's the TCP implementation that interprets the 
option and determines whether it is to be interpreted as containing (1) 
no ExID, (2) a 16-bit ExID, (3) a 32-bit ExID. This information is not 
available within the protocol to a third party.  The third party would 
need a list of ExIDs in-use in order to understand them.___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Bug#1060649: minidlna: Typo in debian/minidlna.default

[Wesley Schwengle]

Package: minidlna
Version: 1.3.3+dfsg-0.2+b1
Severity: minor
Tags: patch
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

I was looking into some things regarding minidlna and saw a small typo. Patch
is attached.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'experimental'), (500, 'testing'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.8-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages minidlna depends on:
ii  adduser  3.137
ii  init-system-helpers  1.66
ii  libavformat607:6.1.1-1
ii  libavutil58  7:6.1.1-1
ii  libc62.37-13
ii  libexif120.6.24-1+b1
ii  libffmpegthumbnailer4v5  2.2.2+git20220218+dfsg-2+b1
ii  libflac121.4.3+ds-2+b1
ii  libid3tag0   0.15.1b-14
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  libogg0  1.3.5-3
ii  libsqlite3-0 3.44.2-1
ii  libvorbis0a  1.3.7-1

minidlna recommends no packages.

minidlna suggests no packages.

-- Configuration Files:
/etc/minidlna.conf changed [not included]

-- no debconf information
>From 11cebcbcfbd245590a95e31af4375478e780c880 Mon Sep 17 00:00:00 2001
From: Wesley Schwengle 
Date: Thu, 11 Jan 2024 21:17:57 -0400
Subject: [PATCH] Fix typo in debian/minidlna.default: change systerm to system

Signed-off-by: Wesley Schwengle 
---
 debian/minidlna.default | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/minidlna.default b/debian/minidlna.default
index a4eeaf2..c3b5f38 100644
--- a/debian/minidlna.default
+++ b/debian/minidlna.default
@@ -22,5 +22,5 @@
 
 # Additional options that are passed to the daemon
 # We pass -r option to do soft non-destructive rebuild on every start-up.
-# If your systerm restarts often, you might want to remove this.
+# If your system restarts often, you might want to remove this.
 #DAEMON_OPTS="-r"
-- 
2.42.0.1031.ga492c6355c

Re: [protobuf] Location of proto files in protobuf-kotlin JAR changed to src directory in version 3.25

[Wesley Hartford]

I've just created https://github.com/protocolbuffers/protobuf/issues/15407

Thanks,

Wesley

On Thu, Jan 11, 2024 at 10:35 AM Adam Cozzette  wrote:

> Thank you for the heads-up. That sounds like a real bug we should make
> sure to fix in the upcoming release. Would you mind filing a GitHub issue
> for this so that we can track it?
>
> On Mon, Jan 8, 2024 at 2:17 PM Wesley Hartford 
> wrote:
>
>> Starting with version 3.25.0 the protobuf-kotlin jar includes some common
>> .proto files in the JARs src/google/protobuf directory. Previous version
>> included these files in the google/protobuf directory (without the
>> parent src directory). I haven't been able to find any announcement or
>> explanation of this change. Current and past versions of the protobuf-java
>> JAR include the same .proto files in the google/protobuf directory.
>>
>> Was this change intentional? It caused one of my builds to break because
>> because the contents of the protobuf-kotlin and protobuf-java JAR were both
>> present causing protoc to detect conflicting declarations of the Any type.
>> My build was misconfiguration and has been fixed, but the change in
>> location still seems wrong to me, especially considering the protobuf-java
>> JAR still includes the same files in the original location.
>>
>> Thanks,
>>
>> Wesley Hartford
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Protocol Buffers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to protobuf+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/protobuf/e5c4258b-a233-459b-b33e-af058d56d3c8n%40googlegroups.com
>> <https://groups.google.com/d/msgid/protobuf/e5c4258b-a233-459b-b33e-af058d56d3c8n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/protobuf/CA%2B%2B-c5z8jUrYpWUFQZ8vCWjQgOcxWVQ4OefderQWkZ30%3Dfc5xg%40mail.gmail.com.

[protobuf] Location of proto files in protobuf-kotlin JAR changed to src directory in version 3.25

[Wesley Hartford]

Starting with version 3.25.0 the protobuf-kotlin jar includes some common 
.proto files in the JARs src/google/protobuf directory. Previous version 
included these files in the google/protobuf directory (without the parent 
src directory). I haven't been able to find any announcement or explanation 
of this change. Current and past versions of the protobuf-java JAR include 
the same .proto files in the google/protobuf directory.

Was this change intentional? It caused one of my builds to break because 
because the contents of the protobuf-kotlin and protobuf-java JAR were both 
present causing protoc to detect conflicting declarations of the Any type. 
My build was misconfiguration and has been fixed, but the change in 
location still seems wrong to me, especially considering the protobuf-java 
JAR still includes the same files in the original location.

Thanks,

Wesley Hartford

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/protobuf/e5c4258b-a233-459b-b33e-af058d56d3c8n%40googlegroups.com.

[OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

[Wesley Eddy via Datatracker]

Reviewer: Wesley Eddy
Review result: Ready with Issues

Comments:

- The document is well-written and easy to read.

- Section 6 is really nice and helpful!

Issues:

- The way an implementation understands the TCP ExIDs may benefit from slightly
more explanation:
  -- In 4.2 and 4.3, is the idea that the implementation is just sampling the
  16 or 32 bits following the experimental option kind being indicated, and
  assuming those 2 or 4 bytes to be ExIDs?  From Section 6.2, I got the sense
  that the implementation is aware of particular ExID values specifically, to
  know if they should be reported as 2 or 4 byte values. -- Will any values
  present be reported, or only those which show up in the IANA registry?  I
  assume any values will be reported, even if they are not registered ExIDs,
  since the registry changes over time, and implementations probably don't grab
  periodic updates of it.

Questions:

- This may be alright, but it seemed to me like for interoperability there
should be some way to indicate what an implementation of this IE is doing with
regard to this text in Section 3.1 (where maybe "may" should be "MAY"?):

  Several extension header chains may be observed in a Flow.  These
  extension headers may be aggregated in one single
  ipv6ExtensionHeadersFull Information Element or be exported in
  separate ipv6ExtensionHeadersFull IEs, one for each extension
  header chain.

- In Section 3.3, it seems backwards to me that this Limit IE being True means
that no limitation was applied, whereas False means that it was limited.  If
the WG and implementers are okay with this, I'm not questioning it, but it
seems odd, so I just wanted to make sure this was the intention.

Nits:

- The first paragraph in section 1 should probably mention the specific RFC(s)
for the specified IEs with the noted problems, since it sounds from the
beginning paragraphs of section 3 and 4 like some of those are already being
addressed by the separate ipfix-fixes document.

- Section 1.1, "do no correspond" -> "do not correspond"


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[RBW] Re: "Grant hates toe clips."

[Wesley]

I have SPD mountain pedals on my road bike and tandem. They're very 
important for the tandem, because so much communication happens through the 
pedals. They're less essential for the road bike. I have flat pedals on my 
main (commuter) bike, but bought flat cycling shoes for my rides because 
they have stiffer soles. Chaos (my everyday footwear) are flexible enough 
at the ball of the foot that the pressure was focused on a smallish area, 
and my feet would go numb on long rides.

On Sunday, December 24, 2023 at 5:44:43 PM UTC-8 Patrick Moore wrote:

> First entry in new Blahg. And no, he doesn't; he reports someone's 
> out-of-context judgment.
>
> But I'm curious how many on this RBW list like and use retention and how 
> many don't; and of the former, how many use toe clips and how many use 
> clipless systems -- and what kind.
>
> I'll start: I rode fast for years and thousands of miles in Keds with 
> thick, soft soles and then rubber-soled lace ups of other sorts on 
> un-clipped rat-trap pedals (and even rubber block pedals) until in about 
> 1990 I got my first relatively expensive road bike (1989 Falcon, tout 531C 
> with Sante group) and decided largely because of bike mag content that I'd 
> better get with the retention program. I started with Bata Bikers and clips 
> and straps, graduated to clips and straps and slotted cleats, then pretty 
> quickly switched to the burgeoning varieties of clipless -- Sampson 
> Stratics, Grafton "Erector Set" road and mtb pedals, Speedplay X1s and 
> Frogs, Looks of various sorts, and finally SPDs, road and mtb (by "road" I 
> mean the ones that came out for about 1 season long long ago with the mtb 
> mechanism). 
>
> A couple of years ago I tried platforms with spikes and no-retention shoes 
> but after about a month of annoyance always shifting my foot to find the 
> right position I gave up and went back to SPDs. I've got SPDs on all my 
> bikes though I've got a very nice set of XC Pros + clips and straps + 
> almost-as-new wood-soled Duegis with cleats that I'd like to try -- I found 
> slotted cleats with semi-tight straps easier with a fixed drivetrain than 
> Look Keos -- except that SPDs are so perfect.
>
> So, I've round that having gotten used to retention I find it very hard to 
> give it up. I daresay that this habituation is stronger since so much of my 
> riding is on fixed drivetrains, but I'd still want at least clips and 
> loose-ish straps with rubber soles for any freewheel drivetrain.
>
> But again, SPDs just feel so perfect that I will probably just stay with 
> them.
>
> Best wishes to all for the Christmas season.
>
> Patrick Moore, finishing up a late resume on Xmas eve in ABQ, NM.
>
> -- 
>
> Patrick Moore
> Alburquerque, Nuevo Mexico, Etats Unis d'Amerique, Orbis Terrarum
>
> ---
>
> Executive resumes, LinkedIn profiles, bios, letters, and other writing 
> services
>
>
> ---
>
> *When thou didst not, savage, k**now thine own meaning,*
>
> *But wouldst gabble like a** thing most brutish,*
>
> *I endowed thy purposes w**ith words that made them known.*
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/cd6e7ec8-d849-48f4-9716-305e4bdb56f5n%40googlegroups.com.

Bug#1059382: kitty: Text rendering change

[Wesley Schwengle]

Hi Nilesh

On 12/24/23 03:19, Nilesh Patra wrote:


Thanks for reporting it and taking the time to bisect it as well!


The issue is that on a dark background with light text everything is made bold,
whereas previously this was not bold. I think it is wise to inform users that
`text_composition_strategy legacy` restores the old defaults (similar to the
version in stable) and/or refer to the manual page:

https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.text_composition_strategy

If kitty can read a system-wide config it might be set there.


It can, but honestly I don't want to diverge from upstream here. Everyone may 
not like the said change and enforcing a system wide config for a composition 
change isn't something that I'm willing to do.

If you could, please consider opening up an upstream issue to see if we can 
reach a common ground. If not, I'll just add a d/NEWS entry informing 
users/sysadmin about this change.


I'm fine with adding a d/NEWS entry, that is mainly the reason why I 
reported the bug. I think it's worth a mention because it confused me 
quite a bit :)


Cheers,
Wesley


--
Wesley Schwengle
E: wes...@schwengle.net

Bug#1059382: kitty: Text rendering change

[Wesley Schwengle]

Package: kitty
Version: 0.31.0-3
Severity: normal
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

On Debian stable version 0.26.5 of kitty is running, on testing/unstable this
is 0.31.0. In 0.28.0 a change in text rendering is made by upstream, this is
mentioned in the changelog.


Text rendering change: Use sRGB correct linear gamma blending for nicer font
rendering and better color accuracy with transparent windows. See the option
text_composition_strategy for details. The obsolete macos_thicken_font will
make the font too thick and needs to be removed manually if it is configured.
(#5969)

I didn't spot it and went in full bisect mode to figure out which commit caused
it. I found it and could relate it to the Changelog entry.

The issue is that on a dark background with light text everything is made bold,
whereas previously this was not bold. I think it is wise to inform users that
`text_composition_strategy legacy` restores the old defaults (similar to the
version in stable) and/or refer to the manual page:

https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.text_composition_strategy

If kitty can read a system-wide config it might be set there.

Cheers,
Wesley


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'experimental'), (500, 'testing'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.8-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kitty depends on:
ii  kitty-shell-integration  0.31.0-3
ii  kitty-terminfo   0.31.0-3
ii  libc62.37-13
ii  libdbus-1-3  1.14.10-3
ii  libharfbuzz0b8.0.1-1
ii  liblcms2-2   2.14-2
ii  libpng16-16  1.6.40-2
ii  libpython3.113.11.7-2
ii  libssl3  3.1.4-2
ii  libwayland-client0   1.22.0-2.1
ii  libx11-6 2:1.8.7-1
ii  libx11-xcb1  2:1.8.7-1
ii  libxcursor1  1:1.2.1-1
ii  libxkbcommon-x11-0   1.6.0-1
ii  libxkbcommon01.6.0-1
ii  libxxhash0   0.8.2-2
ii  python3  3.11.6-1
ii  python3.11   3.11.7-2
ii  zlib1g   1:1.3.dfsg-3

Versions of packages kitty recommends:
ii  kitty-doc 0.31.0-3
ii  libcanberra0  0.30-11

Versions of packages kitty suggests:
pn  imagemagick  

-- no debconf information

[ceph-users] Re: Is there a way to find out which client uses which version of ceph?

[Wesley Dillingham]

You can ask the monitor to dump its sessions (which should expose the IPs
and the release / features) you can then track down by IP those with the
undesirable features/release

ceph daemon mon.`hostname -s` sessions

Assuming your mon is named after the short hostname, you may need to do
this for every mon.  Alternatively using the `ceph tell mon.* sessions` to
hit every mon at once.

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 


On Thu, Dec 21, 2023 at 10:46 AM Anthony D'Atri 
wrote:

> [rook@rook-ceph-tools-5ff8d58445-gkl5w .aws]$ ceph features
> {
> "mon": [
> {
> "features": "0x3f01cfbf7ffd",
> "release": "luminous",
> "num": 3
> }
> ],
> "osd": [
> {
> "features": "0x3f01cfbf7ffd",
> "release": "luminous",
> "num": 600
> }
> ],
> "client": [
> {
> "features": "0x2f018fb87aa4aafe",
> "release": "luminous",
> "num": 41
> },
> {
> "features": "0x3f01cfbf7ffd",
> "release": "luminous",
> "num": 147
> }
> ],
> "mgr": [
> {
> "features": "0x3f01cfbf7ffd",
> "release": "luminous",
> "num": 2
> }
> ]
> }
> [rook@rook-ceph-tools-5ff8d58445-gkl5w .aws]$
>
> IIRC there are nuances, there are case where a client can *look* like
> Jewel but actually be okay.
>
>
> > On Dec 21, 2023, at 10:41, Simon Oosthoek 
> wrote:
> >
> > Hi,
> >
> > Our cluster is currently running quincy, and I want to set the minimal
> > client version to luminous, to enable upmap balancer, but when I tried
> to,
> > I got this:
> >
> > # ceph osd set-require-min-compat-client luminous Error EPERM: cannot set
> > require_min_compat_client to luminous: 2 connected client(s) look like
> > jewel (missing 0x800); add --yes-i-really-mean-it to do it
> > anyway
> >
> > I think I know the most likely candidate (and I've asked them), but is
> > there a way to find out, the way ceph seems to know?
> >
> > tnx
> >
> > /Simon
> > --
> > I'm using my gmail.com address, because the gmail.com dmarc policy is
> > "none", some mail servers will reject this (microsoft?) others will
> instead
> > allow this when I send mail to a mailling list which has not yet been
> > configured to send mail "on behalf of" the sender, but rather do a kind
> of
> > "forward". The latter situation causes dkim/dmarc failures and the dmarc
> > policy will be applied. see https://wiki.list.org/DEV/DMARC for more
> details
> > ___
> > ceph-users mailing list -- ceph-users@ceph.io
> > To unsubscribe send an email to ceph-users-le...@ceph.io
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

maxrss using wrong unit in time

[Wesley Moore]

Hi folks,

Just thought I'd draw your attention to this bug since I think I've found the 
cause:
https://bugs.busybox.net/show_bug.cgi?id=15751

It seems that `time` is treating the the `ru_maxrss` value as a count of 
pages[1][2] but it's already in kilobytes[3]:

> ru_maxrss (since Linux 2.6.32)
> This is the maximum resident set size used (in kilobytes).

Regards,
Wes

[1]: https://git.busybox.net/busybox/tree/miscutils/time.c#n125
[2]: https://git.busybox.net/busybox/tree/miscutils/time.c#n284
[3]: https://man7.org/linux/man-pages/man2/getrusage.2.html
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

[ceph-users] Re: Logging control

[Wesley Dillingham]

"ceph daemon" commands need to be run local to the machine where the daemon
is running. So in this case if you arent on the node where osd.1 lives it
wouldnt work. "ceph tell" should work anywhere there is a client.admin key.


Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 


On Tue, Dec 19, 2023 at 4:02 PM Tim Holloway  wrote:

> Ceph version is Pacific (16.2.14), upgraded from a sloppy Octopus.
>
> I ran afoul of all the best bugs in Octopus, and in the process
> switched on a lot of stuff better left alone, including some detailed
> debug logging. Now I can't turn it off.
>
> I am confidently informed by the documentation that the first step
> would be the command:
>
> ceph daemon osd.1 config show | less
>
> But instead of config information I get back:
>
> Can't get admin socket path: unable to get conf option admin_socket for
> osd: b"error parsing 'osd': expected string of the form TYPE.ID, valid
> types are: auth, mon, osd, mds, mgr, client\n"
>
> Which seems to be kind of insane.
>
> Attempting to get daemon config info on a monitor on that machine
> gives:
>
> admin_socket: exception getting command descriptions: [Errno 2] No such
> file or directory
>
> Which doesn't help either.
>
> Anyone got an idea?
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Re: [RBW] Re: Best way to arrange 2-cog manual shifting for "single speed" disc braked bicycle

[Wesley]

Hey Patrick,
Maybe you've already completed your two-speed conversion, but if not, there 
is some useful info in yesterday's Bikesnob 
blog: https://bikesnobnyc.com/2023/11/29/dingle-all-the-way/

The key message is that the Surly single-speed cogs are thicker at the base 
so you could use one for your second cog without needing a spacer. It 
should allow the lockring to fit.
-Wes

On Sunday, October 29, 2023 at 12:42:39 PM UTC-7 Patrick Moore wrote:

> Excellent! Thank you! So there is serendipity in that the lockring threads 
> match standard fw threads. Very good to know.
>
> Now I can simply overhaul that cheap ss freehub -- Redline? -- and don't 
> have to spend $$$ for a DOS; *also* I can use the current 32 t ring with 
> an outer, screw-on 15 t cog for a 65" cruising gear and buy a splined ss 17 
> or perhaps even 18 t cog for a 57" or even 54" sand bogging gear -- if, 
> that is, a QR disc rear wheel allows this.
>
> On Sun, Oct 29, 2023 at 9:49 AM Wesley  wrote:
>
>> Hi Patrick!
>> I don't remember the hub, and I searched my email for hubs I bought in 
>> 2009 – I was only able to find the one I built into the front wheel. 
>> However! This exercise show something loose in my head and I now recall how 
>> I made the monocog into a two-speed (before whatever I did to add a third 
>> cog). I replaced the locking by a fixed-gear cog. Here's a text diagram:
>>
>> Your current setup has: spokes - spacer - splined cog - lockring
>>
>> Change it to: spokes - splined cog - spacer - threaded cog
>>
>> I hope this helps!
>> -Wes
>>
>> On Saturday, October 28, 2023 at 9:51:46 PM UTC-7 Patrick Moore wrote:
>>
>>> Do you recall the hub you used with the unicycle rim? I seem to recall 
>>> BMX freehubs that had room for 2 cogs.
>>>
>>> On Sat, Oct 28, 2023 at 9:16 PM Wesley  wrote:
>>>
>>>> Yeah, it looks marginal to get a second cog in there with a narrower 
>>>> spacer. According to Sheldon Brown, 9-speed cogs want a 2.54 mm spacer 
>>>> between the cogs: https://sheldonbrown.com/cribsheet-spacing.html
>>>>
>>>> I now remember that my monocog became a three speed after I built it a 
>>>> pair of winter wheels (I used a pair of very wide unicycle rims for 
>>>> maximum 
>>>> float). So I probably kept the original when intact and built a new hub 
>>>> into the new wheel. Sorry for not remembering, the bike has been out of my 
>>>> life for about eight years.
>>>>
>>>> -W
>>>> On Saturday, October 28, 2023 at 1:17:17 PM UTC-7 Patrick Moore wrote:
>>>>
>>>>> Wesley: Sorry, I missed this post in the thread volume.
>>>>>
>>>>> I'm pretty sure that my Monocog's freehub body takes only 1 cog; see 
>>>>> photo with single 3/32" cog and 2.5mm spacer: the splines end right after 
>>>>> the spacer.
>>>>>
>>>>> Am I looking at things right? I hesitate to remove the wheel because 
>>>>> getting the tire exactly centered in the chainstays, with 2-3 mm 
>>>>> clearance 
>>>>> a side and the inevitable tire runout, while also adjusting chain tension 
>>>>> is a pain.
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> On Tue, Oct 17, 2023 at 3:56 PM Wesley  wrote:
>>>>>
>>>>>> Hey Patrick,
>>>>>> My recollection of my monocog was that the freehub had room for three 
>>>>>> cogs. I think there were spacers on the hub that covered up most of the 
>>>>>> free hub - remove the locking and you can do adjust the spacers as 
>>>>>> necessary. If yours is the same, then you could just keep that wheel and 
>>>>>> put the additional cogs onto it.
>>>>>>
>>>>>> And, in case I wasn't clear in my earlier response, I think there is 
>>>>>> plenty of adjustment room in the disc brakes to accommodate the rear 
>>>>>> axle 
>>>>>> being adjusted in the dropout.
>>>>>> -Wes
>>>>>>
>>>>>> On Tuesday, October 17, 2023 at 10:44:19 AM UTC-7 Patrick Moore wrote:
>>>>>>
>>>>>>> That's interesting, and after blundering into a few search result 
>>>>>>> pages about money markets and currency conversion I got:
>>>>>>>
>>>>>>> http://www.monebikes.com/read-me/
>>>>>>>
>>>>>>

[ceph-users] Re: Best Practice for OSD Balancing

[Wesley Dillingham]

It's a complicated topic and there is no one answer, it varies for each
cluster and depends. You have a good lay of the land.

I just wanted to mention that the correct "foundation" for equally utilized
OSDs within a cluster relies on two important factors:

- Symmetry of disk/osd quantity and capacity (weight) between hosts.
- Achieving the correct amount of PGs-per-osd (typically between 100 and
200).

Without having reasonable settings/configurations for these two factors the
various higher-level balancing techniques wont work too well/at all.

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 


On Tue, Nov 28, 2023 at 3:27 PM Rich Freeman  wrote:

> I'm fairly new to Ceph and running Rook on a fairly small cluster
> (half a dozen nodes, about 15 OSDs).  I notice that OSD space use can
> vary quite a bit - upwards of 10-20%.
>
> In the documentation I see multiple ways of managing this, but no
> guidance on what the "correct" or best way to go about this is.  As
> far as I can tell there is the balancer, manual manipulation of upmaps
> via the command line tools, and OSD reweight.  The last two can be
> optimized with tools to calculate appropriate corrections.  There is
> also the new read/active upmap (at least for non-EC pools), which is
> manually triggered.
>
> The balancer alone is leaving fairly wide deviations in space use, and
> at times during recovery this can become more significant.  I've seen
> OSDs hit the 80% threshold and start impacting IO when the entire
> cluster is only 50-60% full during recovery.
>
> I've started using ceph osd reweight-by-utilization and that seems
> much more effective at balancing things, but this seems redundant with
> the balancer which I have turned on.
>
> What is generally considered the best practice for OSD balancing?
>
> --
> Rich
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

[ceph-users] Re: OSDs failing to start due to crc32 and osdmap error

[Wesley Dillingham]

So those options are not consistent with the error in the video I linked.

I am not entirely sure how to proceed with your OSDs (how many are
impacted?)

but you may want to try injecting an older osdmap epoch fetched from the
mon in your osdmap injection:

try rewinding 1 epoch at a time from the current and see if that gets them
to start.

Proceed with caution, I would test this as well.

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn <http://www.linkedin.com/in/wesleydillingham>


On Mon, Nov 27, 2023 at 2:36 PM Denis Polom  wrote:

> it's:
>
> "bluestore_compression_algorithm": "snappy"
>
> "bluestore_compression_mode": "none"
>
>
> On 11/27/23 20:13, Wesley Dillingham wrote:
>
> How about these two options:
>
> bluestore_compression_algorithm
> bluestore_compression_mode
>
> Thanks.
>
> Respectfully,
>
> *Wes Dillingham*
> w...@wesdillingham.com
> LinkedIn <http://www.linkedin.com/in/wesleydillingham>
>
>
> On Mon, Nov 27, 2023 at 2:01 PM Denis Polom  wrote:
>
>> Hi,
>>
>> no we don't:
>>
>> "bluestore_rocksdb_options":
>> "compression=kNoCompression,max_write_buffer_number=4,min_write_buffer_number_to_merge=1,recycle_log_file_num=4,write_buffer_size=268435456,writable_file_max_buffer_size=0,compaction_readahead_size=2097152,max_background_compactions=2,max_total_wal_size=1073741824",
>> thx
>>
>> On 11/27/23 19:17, Wesley Dillingham wrote:
>>
>> Curious if you are using bluestore compression?
>>
>> Respectfully,
>>
>> *Wes Dillingham*
>> w...@wesdillingham.com
>> LinkedIn <http://www.linkedin.com/in/wesleydillingham>
>>
>>
>> On Mon, Nov 27, 2023 at 10:09 AM Denis Polom 
>> wrote:
>>
>>> Hi
>>>
>>> we have issue to start some OSDs on one node on our Ceph Quincy 17.2.7
>>> cluster. Some OSDs on that node are running fine, but some failing to
>>> start.
>>>
>>> Looks like crc32 checksum error, and failing to get OSD map. I found a
>>> some discussions on that but nothing helped.
>>>
>>> I've also tried to insert current OSD map but that ends with error:
>>>
>>> # CEPH_ARGS="--bluestore-ignore-data-csum" ceph-objectstore-tool
>>> --data-path /var/lib/ceph/osd/ceph-888/ --op set-osdmap --file osdmap
>>> osdmap (#-1:20684533:::osdmap.931991:0#) does not exist.
>>>
>>> Log is bellow
>>>
>>> Any ideas please?
>>>
>>> Thank you
>>>
>>>
>>>  From log file:
>>>
>>> 2023-11-27T16:01:47.691+0100 7f3f17aa13c0 -1 Falling back to public
>>> interface
>>>
>>> 2023-11-27T16:01:51.439+0100 7f3f17aa13c0 -1
>>> bluestore(/var/lib/ceph/osd/ceph-888) _verify_csum bad crc32c/0x1000
>>> checksum at blob offset 0x0, got 0xb1701b42, expected 0x9ee5ece2, device
>>> location [0x1~1000], logical extent 0x0~1000, object
>>> #-1:7b3f43c4:::osd_superblock:0#
>>>
>>> 2023-11-27T16:01:51.439+0100 7f3f17aa13c0 -1 osd.888 0 failed to load
>>> OSD map for epoch 927580, got 0 bytes
>>>
>>> /build/ceph-17.2.7/src/osd/OSD.h: In function 'OSDMapRef
>>> OSDService::get_map(epoch_t)' thread 7f3f17aa13c0 time
>>> 2023-11-27T16:01:51.443522+0100
>>> /build/ceph-17.2.7/src/osd/OSD.h: 696: FAILED ceph_assert(ret)
>>>   ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy
>>> (stable)
>>>   1: (ceph::__ceph_assert_fail(char const*, char const*, int, char
>>> const*)+0x14f) [0x561ad07d2624]
>>>   2: ceph-osd(+0xc2e836) [0x561ad07d2836]
>>>   3: (OSD::init()+0x4026) [0x561ad08e5a86]
>>>   4: main()
>>>   5: __libc_start_main()
>>>   6: _start()
>>> *** Caught signal (Aborted) **
>>>   in thread 7f3f17aa13c0 thread_name:ceph-osd
>>> 2023-11-27T16:01:51.443+0100 7f3f17aa13c0 -1
>>> /build/ceph-17.2.7/src/osd/OSD.h: In function 'OSDMapRef
>>> OSDService::get_map(epoch_t)' thread 7f3f17aa13c0 time
>>> 2023-11-27T16:01:51.443522+0100
>>> /build/ceph-17.2.7/src/osd/OSD.h: 696: FAILED ceph_assert(ret)
>>>
>>>   ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy
>>> (stable)
>>>   1: (ceph::__ceph_assert_fail(char const*, char const*, int, char
>>> const*)+0x14f) [0x561ad07d2624]
>>>   2: ceph-osd(+0xc2e836) [0x561ad07d2836]
>>>   3: (OSD::init()+0x4026) [0x561ad08e5a86]
>>>   4: main()
>>>   5: __libc_start_main()
>>>   

[ceph-users] Re: OSDs failing to start due to crc32 and osdmap error

[Wesley Dillingham]

What I was getting at was to see if this was somehow related to the bug
described here https://www.youtube.com/watch?v=_4HUR00oCGo

It should not be given the version of ceph you are using but the CRC error
you are seeing is similar.

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn <http://www.linkedin.com/in/wesleydillingham>


On Mon, Nov 27, 2023 at 2:19 PM Anthony D'Atri  wrote:

> The options Wes listed are for data, not RocksDB.
>
> > On Nov 27, 2023, at 1:59 PM, Denis Polom  wrote:
> >
> > Hi,
> >
> > no we don't:
> >
> > "bluestore_rocksdb_options":
> "compression=kNoCompression,max_write_buffer_number=4,min_write_buffer_number_to_merge=1,recycle_log_file_num=4,write_buffer_size=268435456,writable_file_max_buffer_size=0,compaction_readahead_size=2097152,max_background_compactions=2,max_total_wal_size=1073741824",
> >
> > thx
> >
> > On 11/27/23 19:17, Wesley Dillingham wrote:
> >> Curious if you are using bluestore compression?
> >>
> >> Respectfully,
> >>
> >> *Wes Dillingham*
> >> w...@wesdillingham.com
> >> LinkedIn <http://www.linkedin.com/in/wesleydillingham>
> >>
> >>
> >> On Mon, Nov 27, 2023 at 10:09 AM Denis Polom 
> wrote:
> >>
> >>Hi
> >>
> >>we have issue to start some OSDs on one node on our Ceph Quincy
> >>17.2.7
> >>cluster. Some OSDs on that node are running fine, but some failing
> >>to start.
> >>
> >>Looks like crc32 checksum error, and failing to get OSD map. I
> >>found a
> >>some discussions on that but nothing helped.
> >>
> >>I've also tried to insert current OSD map but that ends with error:
> >>
> >># CEPH_ARGS="--bluestore-ignore-data-csum" ceph-objectstore-tool
> >>--data-path /var/lib/ceph/osd/ceph-888/ --op set-osdmap --file osdmap
> >>osdmap (#-1:20684533:::osdmap.931991:0#) does not exist.
> >>
> >>Log is bellow
> >>
> >>Any ideas please?
> >>
> >>Thank you
> >>
> >>
> >> From log file:
> >>
> >>2023-11-27T16:01:47.691+0100 7f3f17aa13c0 -1 Falling back to public
> >>interface
> >>
> >>2023-11-27T16:01:51.439+0100 7f3f17aa13c0 -1
> >>bluestore(/var/lib/ceph/osd/ceph-888) _verify_csum bad crc32c/0x1000
> >>checksum at blob offset 0x0, got 0xb1701b42, expected 0x9ee5ece2,
> >>device
> >>location [0x1~1000], logical extent 0x0~1000, object
> >>#-1:7b3f43c4:::osd_superblock:0#
> >>
> >>2023-11-27T16:01:51.439+0100 7f3f17aa13c0 -1 osd.888 0 failed to load
> >>OSD map for epoch 927580, got 0 bytes
> >>
> >>/build/ceph-17.2.7/src/osd/OSD.h: In function 'OSDMapRef
> >>OSDService::get_map(epoch_t)' thread 7f3f17aa13c0 time
> >>2023-11-27T16:01:51.443522+0100
> >>/build/ceph-17.2.7/src/osd/OSD.h: 696: FAILED ceph_assert(ret)
> >>  ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2)
> >>quincy
> >>(stable)
> >>  1: (ceph::__ceph_assert_fail(char const*, char const*, int, char
> >>const*)+0x14f) [0x561ad07d2624]
> >>  2: ceph-osd(+0xc2e836) [0x561ad07d2836]
> >>  3: (OSD::init()+0x4026) [0x561ad08e5a86]
> >>  4: main()
> >>  5: __libc_start_main()
> >>  6: _start()
> >>*** Caught signal (Aborted) **
> >>  in thread 7f3f17aa13c0 thread_name:ceph-osd
> >>2023-11-27T16:01:51.443+0100 7f3f17aa13c0 -1
> >>/build/ceph-17.2.7/src/osd/OSD.h: In function 'OSDMapRef
> >>OSDService::get_map(epoch_t)' thread 7f3f17aa13c0 time
> >>2023-11-27T16:01:51.443522+0100
> >>/build/ceph-17.2.7/src/osd/OSD.h: 696: FAILED ceph_assert(ret)
> >>
> >>  ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2)
> >>quincy
> >>(stable)
> >>  1: (ceph::__ceph_assert_fail(char const*, char const*, int, char
> >>const*)+0x14f) [0x561ad07d2624]
> >>  2: ceph-osd(+0xc2e836) [0x561ad07d2836]
> >>  3: (OSD::init()+0x4026) [0x561ad08e5a86]
> >>  4: main()
> >>  5: __libc_start_main()
> >>  6: _start()
> >>
> >>
> >>  ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2)
> >>quincy
> >>(stable)
> >>  1: /lib/x86_64-linux-gnu/libpthr

[ceph-users] Re: OSDs failing to start due to crc32 and osdmap error

[Wesley Dillingham]

How about these two options:

bluestore_compression_algorithm
bluestore_compression_mode

Thanks.

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn <http://www.linkedin.com/in/wesleydillingham>


On Mon, Nov 27, 2023 at 2:01 PM Denis Polom  wrote:

> Hi,
>
> no we don't:
>
> "bluestore_rocksdb_options":
> "compression=kNoCompression,max_write_buffer_number=4,min_write_buffer_number_to_merge=1,recycle_log_file_num=4,write_buffer_size=268435456,writable_file_max_buffer_size=0,compaction_readahead_size=2097152,max_background_compactions=2,max_total_wal_size=1073741824",
> thx
>
> On 11/27/23 19:17, Wesley Dillingham wrote:
>
> Curious if you are using bluestore compression?
>
> Respectfully,
>
> *Wes Dillingham*
> w...@wesdillingham.com
> LinkedIn <http://www.linkedin.com/in/wesleydillingham>
>
>
> On Mon, Nov 27, 2023 at 10:09 AM Denis Polom  wrote:
>
>> Hi
>>
>> we have issue to start some OSDs on one node on our Ceph Quincy 17.2.7
>> cluster. Some OSDs on that node are running fine, but some failing to
>> start.
>>
>> Looks like crc32 checksum error, and failing to get OSD map. I found a
>> some discussions on that but nothing helped.
>>
>> I've also tried to insert current OSD map but that ends with error:
>>
>> # CEPH_ARGS="--bluestore-ignore-data-csum" ceph-objectstore-tool
>> --data-path /var/lib/ceph/osd/ceph-888/ --op set-osdmap --file osdmap
>> osdmap (#-1:20684533:::osdmap.931991:0#) does not exist.
>>
>> Log is bellow
>>
>> Any ideas please?
>>
>> Thank you
>>
>>
>>  From log file:
>>
>> 2023-11-27T16:01:47.691+0100 7f3f17aa13c0 -1 Falling back to public
>> interface
>>
>> 2023-11-27T16:01:51.439+0100 7f3f17aa13c0 -1
>> bluestore(/var/lib/ceph/osd/ceph-888) _verify_csum bad crc32c/0x1000
>> checksum at blob offset 0x0, got 0xb1701b42, expected 0x9ee5ece2, device
>> location [0x1~1000], logical extent 0x0~1000, object
>> #-1:7b3f43c4:::osd_superblock:0#
>>
>> 2023-11-27T16:01:51.439+0100 7f3f17aa13c0 -1 osd.888 0 failed to load
>> OSD map for epoch 927580, got 0 bytes
>>
>> /build/ceph-17.2.7/src/osd/OSD.h: In function 'OSDMapRef
>> OSDService::get_map(epoch_t)' thread 7f3f17aa13c0 time
>> 2023-11-27T16:01:51.443522+0100
>> /build/ceph-17.2.7/src/osd/OSD.h: 696: FAILED ceph_assert(ret)
>>   ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy
>> (stable)
>>   1: (ceph::__ceph_assert_fail(char const*, char const*, int, char
>> const*)+0x14f) [0x561ad07d2624]
>>   2: ceph-osd(+0xc2e836) [0x561ad07d2836]
>>   3: (OSD::init()+0x4026) [0x561ad08e5a86]
>>   4: main()
>>   5: __libc_start_main()
>>   6: _start()
>> *** Caught signal (Aborted) **
>>   in thread 7f3f17aa13c0 thread_name:ceph-osd
>> 2023-11-27T16:01:51.443+0100 7f3f17aa13c0 -1
>> /build/ceph-17.2.7/src/osd/OSD.h: In function 'OSDMapRef
>> OSDService::get_map(epoch_t)' thread 7f3f17aa13c0 time
>> 2023-11-27T16:01:51.443522+0100
>> /build/ceph-17.2.7/src/osd/OSD.h: 696: FAILED ceph_assert(ret)
>>
>>   ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy
>> (stable)
>>   1: (ceph::__ceph_assert_fail(char const*, char const*, int, char
>> const*)+0x14f) [0x561ad07d2624]
>>   2: ceph-osd(+0xc2e836) [0x561ad07d2836]
>>   3: (OSD::init()+0x4026) [0x561ad08e5a86]
>>   4: main()
>>   5: __libc_start_main()
>>   6: _start()
>>
>>
>>   ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy
>> (stable)
>>   1: /lib/x86_64-linux-gnu/libpthread.so.0(+0x14420) [0x7f3f1814b420]
>>   2: gsignal()
>>   3: abort()
>>   4: (ceph::__ceph_assert_fail(char const*, char const*, int, char
>> const*)+0x1b7) [0x561ad07d268c]
>>   5: ceph-osd(+0xc2e836) [0x561ad07d2836]
>>   6: (OSD::init()+0x4026) [0x561ad08e5a86]
>>   7: main()
>>   8: __libc_start_main()
>>   9: _start()
>> 2023-11-27T16:01:51.447+0100 7f3f17aa13c0 -1 *** Caught signal (Aborted)
>> **
>>   in thread 7f3f17aa13c0 thread_name:ceph-osd
>>
>>   ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy
>> (stable)
>>   1: /lib/x86_64-linux-gnu/libpthread.so.0(+0x14420) [0x7f3f1814b420]
>>   2: gsignal()
>>   3: abort()
>>   4: (ceph::__ceph_assert_fail(char const*, char const*, int, char
>> const*)+0x1b7) [0x561ad07d268c]
>>   5: ceph-osd(+0xc2e836) [0x561ad07d2836]
>>   6: (OSD::init()+0x4026) [0x561ad08e5a86]
>>   7: main()
>>   8: __libc_start_main()
&g

[ceph-users] Re: About number of osd node can be failed with erasure code 3+2

[Wesley Dillingham]

With a k+m which is 3+2 each RADOS object is broken into 5 shards. By
default the pool will have a min_size of k+1 (4 in this case). Which means
you can lose 1 shard and still be >= min_size. If one host goes down and
you use a host-based failure domain (default) you will lose 1 shard out of
all PGs on that host. You will now be at min_size and so still
readable/writeable. If you lose another host you will now be below min_size
with 3 healthy shards for some subset of PG (those common to the 2 hosts)
will be inactive and therefore not read/writeable. As you can see, the
higher your M the more disks/hosts you can lose before dropping below
min_size.

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 


On Mon, Nov 27, 2023 at 1:36 PM  wrote:

> Hi Groups,
>
> Recently I was setting up a ceph cluster with 10 nodes 144 osd, and I use
> S3 for it with pool erasure code EC3+2 on it.
>
> I have a question, how many osd nodes can fail with erasure code 3+2 with
> cluster working normal (read, write)? and can i choose better erasure code
> ec7+3, 8+2 etc..?
>
> With the erasure code algorithm, it only ensures no data loss, but does
> not guarantee that the cluster operates normally and does not block IO when
> osd nodes down. Is that right?
>
> Thanks to the community.
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

[ceph-users] Re: OSDs failing to start due to crc32 and osdmap error

[Wesley Dillingham]

Curious if you are using bluestore compression?

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 


On Mon, Nov 27, 2023 at 10:09 AM Denis Polom  wrote:

> Hi
>
> we have issue to start some OSDs on one node on our Ceph Quincy 17.2.7
> cluster. Some OSDs on that node are running fine, but some failing to
> start.
>
> Looks like crc32 checksum error, and failing to get OSD map. I found a
> some discussions on that but nothing helped.
>
> I've also tried to insert current OSD map but that ends with error:
>
> # CEPH_ARGS="--bluestore-ignore-data-csum" ceph-objectstore-tool
> --data-path /var/lib/ceph/osd/ceph-888/ --op set-osdmap --file osdmap
> osdmap (#-1:20684533:::osdmap.931991:0#) does not exist.
>
> Log is bellow
>
> Any ideas please?
>
> Thank you
>
>
>  From log file:
>
> 2023-11-27T16:01:47.691+0100 7f3f17aa13c0 -1 Falling back to public
> interface
>
> 2023-11-27T16:01:51.439+0100 7f3f17aa13c0 -1
> bluestore(/var/lib/ceph/osd/ceph-888) _verify_csum bad crc32c/0x1000
> checksum at blob offset 0x0, got 0xb1701b42, expected 0x9ee5ece2, device
> location [0x1~1000], logical extent 0x0~1000, object
> #-1:7b3f43c4:::osd_superblock:0#
>
> 2023-11-27T16:01:51.439+0100 7f3f17aa13c0 -1 osd.888 0 failed to load
> OSD map for epoch 927580, got 0 bytes
>
> /build/ceph-17.2.7/src/osd/OSD.h: In function 'OSDMapRef
> OSDService::get_map(epoch_t)' thread 7f3f17aa13c0 time
> 2023-11-27T16:01:51.443522+0100
> /build/ceph-17.2.7/src/osd/OSD.h: 696: FAILED ceph_assert(ret)
>   ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy
> (stable)
>   1: (ceph::__ceph_assert_fail(char const*, char const*, int, char
> const*)+0x14f) [0x561ad07d2624]
>   2: ceph-osd(+0xc2e836) [0x561ad07d2836]
>   3: (OSD::init()+0x4026) [0x561ad08e5a86]
>   4: main()
>   5: __libc_start_main()
>   6: _start()
> *** Caught signal (Aborted) **
>   in thread 7f3f17aa13c0 thread_name:ceph-osd
> 2023-11-27T16:01:51.443+0100 7f3f17aa13c0 -1
> /build/ceph-17.2.7/src/osd/OSD.h: In function 'OSDMapRef
> OSDService::get_map(epoch_t)' thread 7f3f17aa13c0 time
> 2023-11-27T16:01:51.443522+0100
> /build/ceph-17.2.7/src/osd/OSD.h: 696: FAILED ceph_assert(ret)
>
>   ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy
> (stable)
>   1: (ceph::__ceph_assert_fail(char const*, char const*, int, char
> const*)+0x14f) [0x561ad07d2624]
>   2: ceph-osd(+0xc2e836) [0x561ad07d2836]
>   3: (OSD::init()+0x4026) [0x561ad08e5a86]
>   4: main()
>   5: __libc_start_main()
>   6: _start()
>
>
>   ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy
> (stable)
>   1: /lib/x86_64-linux-gnu/libpthread.so.0(+0x14420) [0x7f3f1814b420]
>   2: gsignal()
>   3: abort()
>   4: (ceph::__ceph_assert_fail(char const*, char const*, int, char
> const*)+0x1b7) [0x561ad07d268c]
>   5: ceph-osd(+0xc2e836) [0x561ad07d2836]
>   6: (OSD::init()+0x4026) [0x561ad08e5a86]
>   7: main()
>   8: __libc_start_main()
>   9: _start()
> 2023-11-27T16:01:51.447+0100 7f3f17aa13c0 -1 *** Caught signal (Aborted) **
>   in thread 7f3f17aa13c0 thread_name:ceph-osd
>
>   ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy
> (stable)
>   1: /lib/x86_64-linux-gnu/libpthread.so.0(+0x14420) [0x7f3f1814b420]
>   2: gsignal()
>   3: abort()
>   4: (ceph::__ceph_assert_fail(char const*, char const*, int, char
> const*)+0x1b7) [0x561ad07d268c]
>   5: ceph-osd(+0xc2e836) [0x561ad07d2836]
>   6: (OSD::init()+0x4026) [0x561ad08e5a86]
>   7: main()
>   8: __libc_start_main()
>   9: _start()
>   NOTE: a copy of the executable, or `objdump -rdS ` is
> needed to interpret this.
>
>
>-558> 2023-11-27T16:01:47.691+0100 7f3f17aa13c0 -1 Falling back to
> public interface
>
>  -5> 2023-11-27T16:01:51.439+0100 7f3f17aa13c0 -1
> bluestore(/var/lib/ceph/osd/ceph-888) _verify_csum bad crc32c/0x1000
> checksum at blob offset 0x0, got 0xb1701b42, expected 0x9ee5ece2, device
> location [0x1~1000], logical extent 0x0~1000, object
> #-1:7b3f43c4:::osd_superblock:0#
>
>  -2> 2023-11-27T16:01:51.439+0100 7f3f17aa13c0 -1 osd.888 0 failed
> to load OSD map for epoch 927580, got 0 bytes
>
>  -1> 2023-11-27T16:01:51.443+0100 7f3f17aa13c0 -1
> /build/ceph-17.2.7/src/osd/OSD.h: In function 'OSDMapRef
> OSDService::get_map(epoch_t)' thread 7f3f17aa13c0 time
> 2023-11-27T16:01:51.443522+0100
> /build/ceph-17.2.7/src/osd/OSD.h: 696: FAILED ceph_assert(ret)
>
>   ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy
> (stable)
>   1: (ceph::__ceph_assert_fail(char const*, char const*, int, char
> const*)+0x14f) [0x561ad07d2624]
>   2: ceph-osd(+0xc2e836) [0x561ad07d2836]
>   3: (OSD::init()+0x4026) [0x561ad08e5a86]
>   4: main()
>   5: __libc_start_main()
>   6: _start()
>
>
>   0> 2023-11-27T16:01:51.447+0100 7f3f17aa13c0 -1 *** Caught signal
> (Aborted) **
>   in thread 7f3f17aa13c0 thread_name:ceph-osd
>
>   ceph version 17.2.7 (b12291d110049b2f35e32e0de30d70e9a4c060d2) quincy

Basic Access for Google Ads API

[Wesley Ferreira]

Hi, 

I've been filling out the form to request basic access for weeks, but I 
haven't received a response. I contacted the Ads API Compliance team, but I 
haven't received a response yet.
We are not getting any feedback from you from any location.
We are developing software for publishing campaigns on Google Ads for large 
retailers.
Can you help me!?

MCC 241-355-4854
Access level: Basic Access

Thanks.

-- 
-- 
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog:
https://googleadsdeveloper.blogspot.com/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

You received this message because you are subscribed to the Google
Groups "AdWords API and Google Ads API Forum" group.
To post to this group, send email to adwords-api@googlegroups.com
To unsubscribe from this group, send email to
adwords-api+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/adwords-api?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Google Ads API and AdWords API Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to adwords-api+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/adwords-api/a01514cf-4ae5-492d-a593-6038f364b61bn%40googlegroups.com.

[ceph-users] Re: Why is min_size of erasure pools set to k+1

[Wesley Dillingham]

" if min_size is k and you lose an OSD during recovery after a failure of m
OSDs, data will become unavailable"

In that situation data wouldnt become unavailable it would be lost.

Having a min_size of k+1 provides a buffer between data being
active+writeable and where data is lost. That inbetween is called inactive.

By having that buffer you prevent the situation of having data being
written to the PG when you are only one disk/shard away from data loss.

Imagine the scenario of 4+2 with a min_size of 4. The cluster is 6 servers
filled with osds

You have brought 2 servers down for maintenance (not a good idea but this
is an example). Your PGs are all degraded with only 4 shards of clean data
but active because k=min_size. Data is being written to the pool.

As you are booting your 2 servers up out of maintenance an OSD/disk on
another server fails and fails hard. Because that OSD was part of the
acting set the cluster only wrote four shards and now one is lost.

You only have 3 shards of data in a 4+2 and now some subset of data is lost.

Now imagine a 4+2 with min_size = 5.

You wouldnt bring down more than 1 host because "ceph osd ok-to-stop" would
return false if your tried to bring down more than 1 host for maintenance.

Lets say you did bring down two hosts against the advice of the ok-to-stop
command your PGs would become inactive and so they wouldn't accept
writes. Once you boot your 2 servers back the cluster heals.

Lets say you heed the advice of ok-to-stop and only bring 1 host down for
maintenance at a time.  Your data is degraded with 5/6 shards healthy. New
data is being written with 5 shards able to be written out.

As you are booting your server out of maintenance an OSD on another host
dies and those shards are lost forever, The PGs from that lost OSD now have
4  healthy shards. That is enough shards to recover the data from (though
you would have some PGs inactive for a bit until recovery finished)

Hope this helps to answer the min_size question a bit.

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn 


On Mon, Nov 20, 2023 at 2:03 PM Vladimir Brik <
vladimir.b...@icecube.wisc.edu> wrote:

> Could someone help me understand why it's a bad idea to set min_size of
> erasure-coded pools to k?
>
> From what I've read, the argument for k+1 is that if min_size is k and you
> lose an OSD during recovery after a failure of m OSDs, data will become
> unavailable. But how does setting min_size to k+1 help? If m=2, if you
> experience a double failure followed by another failure during recovery you
> still lost 3 OSDs and therefore your data because the pool wasn't set up to
> handle 3 concurrent failures, and the value of min_size is irrelevant.
>
> https://github.com/ceph/ceph/pull/8008 mentions inability to peer if
> min_size = k, but I don't understand why. Does that mean that if min_size=k
> and I lose m OSDs, and then an OSD is restarted during recovery, PGs will
> not peer even after the restarted OSD comes back online?
>
>
> Vlad
> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

[ceph-users] Re: blustore osd nearfull but no pgs on it

[Wesley Dillingham]

The large amount of osdmaps is what i was suspecting. "ceph tell osd.158
status" (or any osd other than 158) would show us how many osdmaps the osds
are currently holding on to.

Respectfully,

*Wes Dillingham*
w...@wesdillingham.com
LinkedIn <http://www.linkedin.com/in/wesleydillingham>


On Mon, Nov 20, 2023 at 6:15 AM Debian  wrote:

> Hi,
>
> yes all of my small osds are affected
>
> i found the issue, my cluster is healthy and my rebalance finished - i
> have only to wait that my old osdmaps get cleaned up.
>
> like in the thread "Disks are filling up even if there is not a single
> placement group on them"
>
> thx!
>
> On 20.11.23 11:36, Eugen Block wrote:
> > You provide only a few details at a time, it would help to get a full
> > picture if you provided the output Wesley asked for (ceph df detail,
> > ceph tell osd.158 status, ceph osd df tree). Is osd.149 now the
> > problematic one or did you just add output from a different osd?
> > It's not really clear what you're doing without the necessary context.
> > You can just add the 'ceph daemon osd.{OSD} perf dump' output here or
> > in some pastebin.
> >
> > Zitat von Debian :
> >
> >> Hi,
> >>
> >> the block.db size ist default and not custom configured:
> >>
> >> current:
> >>
> >> bluefs.db_used_bytes: 9602859008
> >> bluefs.db_used_bytes: 469434368
> >>
> >> ceph daemon osd.149 config show
> >>
> >> "bluestore_bitmapallocator_span_size": "1024",
> >> "bluestore_block_db_size": "0",
> >> "bluestore_block_size": "107374182400",
> >> "bluestore_block_wal_size": "100663296",
> >> "bluestore_cache_size": "0",
> >> "bluestore_cache_size_hdd": "1073741824",
> >> "bluestore_cache_size_ssd": "3221225472",
> >> "bluestore_compression_max_blob_size": "0",
> >> "bluestore_compression_max_blob_size_hdd": "524288",
> >> "bluestore_compression_max_blob_size_ssd": "65536",
> >> "bluestore_compression_min_blob_size": "0",
> >> "bluestore_compression_min_blob_size_hdd": "131072",
> >> "bluestore_compression_min_blob_size_ssd": "8192",
> >> "bluestore_extent_map_inline_shard_prealloc_size": "256",
> >> "bluestore_extent_map_shard_max_size": "1200",
> >> "bluestore_extent_map_shard_min_size": "150",
> >> "bluestore_extent_map_shard_target_size": "500",
> >> "bluestore_extent_map_shard_target_size_slop": "0.20",
> >> "bluestore_max_alloc_size": "0",
> >> "bluestore_max_blob_size": "0",
> >> "bluestore_max_blob_size_hdd": "524288",
> >> "bluestore_max_blob_size_ssd": "65536",
> >> "bluestore_min_alloc_size": "0",
> >> "bluestore_min_alloc_size_hdd": "65536",
> >> "bluestore_min_alloc_size_ssd": "4096",
> >> "bluestore_prefer_deferred_size": "0",
> >> "bluestore_prefer_deferred_size_hdd": "32768",
> >> "bluestore_prefer_deferred_size_ssd": "0",
> >> "bluestore_rocksdb_options":
> >>
> "compression=kNoCompression,max_write_buffer_number=4,min_write_buffer_number_to_merge=1,recycle_log_file_num=4,write_buffer_size=268435456,writable_file_max_buffer_size=0,compaction_readahead_size=2097152,max_background_compactions=2",
> >>
> >> "bluefs_alloc_size": "1048576",
> >> "bluefs_allocator": "hybrid",
> >> "bluefs_buffered_io": "false",
> >> "bluefs_check_for_zeros": "false",
> >> "bluefs_compact_log_sync": "false",
> >> "bluefs_log_compact_min_ratio": "5.00",
> >> "bluefs_log_compact_min_size": "16777216",
> >> "bluefs_max_log_runway": "4194304",
> >> "bluefs_max_prefetch": "1048576",
> >> "bluefs_min_flush_size": "524288",
> >> "bluefs_min_log_r