Bug#1070402:

2024-05-18 Thread Forest
Control: fixed -1 6.8.9-1



Bug#1069077: rockpro64: multiple kernel oops and frequent boot failures

2024-05-17 Thread Forest
Control: fixed -1 6.8.9-1

On Fri, 17 May 2024 12:15:55 +0200, Diederik de Haas wrote:

>Kernel 6.8.9 has recently been uploaded to Unstable which has that commit.
>Can you verify that it indeed fixes this bug?

Indeed, it seems to be fixed there. It usually takes only one or two boots
to show up, but I didn't see it in five reboots with kernel 6.8.9. This
matches what I found while bisecting for the past week.

Note that I have not examined the es8316 driver code or its relationship to
maple_tree. I don't know if the bug was in maple_tree and now fixed, or
still lurks within the driver but is now hidden as a result of the
maple_tree changes. In any case, I'm happy to report that I no longer see it
breaking the OS in this newer kernel.



Bug#1069077:

2024-05-16 Thread Forest
A git bisect reveals it to be fixed by this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f7a59018953910032231c0a019208c4b0a4a8bc3

> maple_tree: make mas_erase() more robust
> 
> mas_erase() may not deal correctly with all maple states.  Make the
> function more robust by ensuring the state is in one of the two acceptable
> states.



Bug#1069133:

2024-05-04 Thread Forest
Control: fixed -1 linux/6.7.12-1



Bug#1069133:

2024-05-04 Thread Forest
fixed -1 linux/6.7.12-1



Bug#1069077:

2024-05-04 Thread Forest
Control: found -1 6.7.12-1



Bug#1070402: linux-image-6.7.12-amd64: bluetooth dualshock 4 playstation controller no longer shows as connected

2024-05-04 Thread Forest
Package: src:linux
Version: 6.7.12-1
Severity: normal
X-Debbugs-Cc: fores...@nom.one

Dear Maintainer,

After upgrading from kernel 6.7.9 to 6.7.12, my DualShock 4 game
controller no longer shows as connected in KDE Plasma.

Contrary to what the GUI says, the device's onboard light seems to
indicate that it is connected, and it works in games. However, since the
GUI believes otherwise, I no longer have an indictor showing the
device's presence, and I can no longer easily turn off the device.

Clicking the Connect button in the GUI yields a failure.

Journalctl shows this new message at device power-on:

  bluetoothd[1143]: Authorization request for non-connected device!?

With the previous (working) kernel, these messages appeared instead:

  kernel: Bluetooth: HIDP (Human Interface Emulation) ver 1.2
  kernel: Bluetooth: HIDP socket layer initialized

Reverting to kernel 6.7.9 fixes the problem.

I suspect this might be the upstream bug (and patch):
https://bugzilla.kernel.org/show_bug.cgi?id=218680

-- Package-specific info:
** Version:
Linux version 6.7.12-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.2.0-23) 13.2.0, GNU ld (GNU Binutils for 
Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.7.12-1 (2024-04-24)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.7.12-amd64 
root=UUID=6643f6c4-094f-40ea-a653-dfe61fd6e05c ro net.ifnames=0 quiet 
cryptdevice=UUID=921508cc-880b-455b-a47f-1f3a6cac6d55:osroot 
root=/dev/mapper/osroot splash

** Not tainted

** Kernel log:
[9.691418] Bluetooth: HCI device and connection manager initialized
[9.691421] Bluetooth: HCI socket layer initialized
[9.691423] Bluetooth: L2CAP socket layer initialized
[9.691425] Bluetooth: SCO socket layer initialized
[9.691451] input: HDA Digital PCBeep as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input19
[9.691505] input: HD-Audio Generic Front Mic as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input20
[9.691544] input: HD-Audio Generic Rear Mic as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input21
[9.691590] input: HD-Audio Generic Line as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input22
[9.691622] input: HD-Audio Generic Line Out Front as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input23
[9.691656] input: HD-Audio Generic Line Out Surround as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input24
[9.691728] input: HD-Audio Generic Line Out CLFE as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input25
[9.691808] input: HD-Audio Generic Front Headphone as 
/devices/pci:00/:00:08.1/:0e:00.6/sound/card2/input26
[9.693320] mt7921e :0b:00.0: enabling device ( -> 0002)
[9.695294] mt7921e :0b:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[9.697686] mt7921e :0b:00.0: ASIC revision: 79610010
[9.700377] usbcore: registered new interface driver btusb
[9.709624] bluetooth hci0: firmware: direct-loading firmware 
mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
[9.709836] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 
20231109191416
[9.779822] mt7921e :0b:00.0: firmware: direct-loading firmware 
mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
[9.779880] mt7921e :0b:00.0: HW/SW Version: 0x8a108a10, Build Time: 
20231109190918a

[   10.035775] mt7921e :0b:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[   10.036227] mt7921e :0b:00.0: WM Firmware Version: 01, Build 
Time: 20231109190959
[   10.069916] mt7921e :0b:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[   10.359539] audit: type=1400 audit(1714845460.171:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/lxc-start" 
pid=1056 comm="apparmor_parser"
[   10.359791] audit: type=1400 audit(1714845460.171:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=1060 comm="apparmor_parser"
[   10.359856] audit: type=1400 audit(1714845460.171:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/libexec/ibus-engine-hangul" pid=1064 comm="apparmor_parser"
[   10.360012] audit: type=1400 audit(1714845460.171:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=1062 comm="apparmor_parser"
[   10.360044] audit: type=1400 audit(1714845460.171:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oosplash" 
pid=1059 comm="apparmor_parser"
[   10.360106] audit: type=1400 audit(1714845460.171:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=1048 
comm="apparmor_parser"
[   10.360183] audit: type=1400 audit(1714845460.171:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="virt-aa-helper" pid=1063 

Bug#1069133:

2024-04-16 Thread Forest
Note that this is a headless system, so there is no other way to display a
prompt or enter the passphrase.

Just in case this was merely a display problem, I tried entering the
passphrase at the serial console despite the missing prompt. It didn't work.



Bug#1069133: linux-image-6.6.15-arm64: luks unlock passphrase prompt is not offered on serial console

2024-04-16 Thread Forest
Package: src:linux
Version: 6.6.15-2
Severity: normal
X-Debbugs-Cc: fores...@nom.one

Dear Maintainer,

When booting with an encrypted root filesystem, the LUKS unlock
passphrase prompt normally appears on the serial console shortly after
the first device-mapper messages. It looks like this:

  Please unlock disk devname_crypt:

After upgrading from kernel 6.1.0-20 (bookworm) to 6.6.15-2 (testing), the
passphrase prompt never appears.

I was only able to continue the boot process because this system happens
to have network access and dropbear-initramfs, for remote unlocking via
ssh.  Were that not the case, it seems the system would be unbootable
with this kernel.

Kernel 6.7.9-2 (unstable) does not have this problem.


-- Package-specific info:
** Version:
Linux version 6.6.15-arm64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 
13.2.0-13) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP Debian 
6.6.15-2 (2024-02-04)

** Command line:
root=/dev/mapper/devname_crypt net.ifnames=0

** Tainted: C (1024)
 * staging driver was loaded

** Kernel log:
[  149.090747] systemd[1]: Started systemd-journald.service - Journal Service.
[  149.254649] systemd-journald[1729]: Received client request to flush runtime 
journal.
[  150.667782] cpu cpu0: EM: created perf domain
[  150.692323] cpu cpu4: EM: OPP:408000 is inefficient
[  150.692622] cpu cpu4: EM: created perf domain
[  150.729385]  cs_system_cfg: CoreSight Configuration manager initialised
[  150.815867] sd 3:0:0:0: Attached scsi generic sg0 type 0
[  150.846507] mc: Linux media interface: v0.10
[  150.854523] coresight-cpu-debug fe43.debug: Coresight debug-CPU0 
initialized
[  150.855314] coresight-cpu-debug fe432000.debug: Coresight debug-CPU1 
initialized
[  150.856041] coresight-cpu-debug fe434000.debug: Coresight debug-CPU2 
initialized
[  150.856798] coresight-cpu-debug fe436000.debug: Coresight debug-CPU3 
initialized
[  150.857544] coresight-cpu-debug fe61.debug: Coresight debug-CPU4 
initialized
[  150.858287] coresight-cpu-debug fe71.debug: Coresight debug-CPU5 
initialized
[  150.869439] spi-nor spi0.0: gd25q128 (16384 Kbytes)
[  150.942070] dw_wdt ff848000.watchdog: No valid TOPs array specified
[  150.971530] Registered IR keymap rc-empty
[  150.972060] rc rc0: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0
[  150.985430] rc rc0: lirc_dev: driver gpio_ir_recv registered at minor = 0, 
raw IR receiver, no transmitter
[  151.005373] input: gpio_ir_recv as 
/devices/platform/ir-receiver/rc/rc0/input1
[  151.008902] Registered IR keymap rc-cec
[  151.009376] rc rc1: dw_hdmi as /devices/platform/ff94.hdmi/rc/rc1
[  151.010046] input: dw_hdmi as /devices/platform/ff94.hdmi/rc/rc1/input2
[  151.031943] rk3288-crypto ff8b.crypto: will run requests pump with 
realtime priority
[  151.032761] rk3288-crypto ff8b.crypto: Register ecb(aes) as ecb-aes-rk
[  151.054216] rk3288-crypto ff8b.crypto: Register cbc(aes) as cbc-aes-rk
[  151.058400] rk3288-crypto ff8b.crypto: Register ecb(des) as ecb-des-rk
[  151.081600] videodev: Linux video capture interface: v2.00
[  151.184800] rk3288-crypto ff8b.crypto: Register cbc(des) as cbc-des-rk
[  151.190566] panfrost ff9a.gpu: clock rate = 5
[  151.202576] rk3288-crypto ff8b.crypto: Register ecb(des3_ede) as 
ecb-des3-ede-rk
[  151.228527] Bluetooth: Core ver 2.22
[  151.229070] NET: Registered PF_BLUETOOTH protocol family
[  151.229535] rk3288-crypto ff8b.crypto: Register cbc(des3_ede) as 
cbc-des3-ede-rk
[  151.229552] Bluetooth: HCI device and connection manager initialized
[  151.230931] Bluetooth: HCI socket layer initialized
[  151.231406] Bluetooth: L2CAP socket layer initialized
[  151.231919] Bluetooth: SCO socket layer initialized
[  151.256807] rk3288-crypto ff8b.crypto: Register sha1 as rk-sha1
[  151.284343] panfrost ff9a.gpu: mali-t860 id 0x860 major 0x2 minor 0x0 
status 0x0
[  151.285070] panfrost ff9a.gpu: features: ,0407, issues: 
,24040400
[  151.285791] panfrost ff9a.gpu: Features: L2:0x07120206 Shader:0x 
Tiler:0x0809 Mem:0x1 MMU:0x2830 AS:0xff JS:0x7
[  151.286827] panfrost ff9a.gpu: shader_present=0xf l2_present=0x1
[  151.309637] rk3288-crypto ff8b.crypto: Register sha256 as rk-sha256
[  151.311614] [drm] Initialized panfrost 1.2.0 20180908 for ff9a.gpu on 
minor 1
[  151.314713] rockchip-rga ff68.rga: HW Version: 0x03.02
[  151.317607] rockchip-rga ff68.rga: Registered rockchip-rga as /dev/video0
[  151.356517] rk3288-crypto ff8b.crypto: Register md5 as rk-md5
[  151.419453] rockchip_vdec: module is from the staging directory, the quality 
is unknown, you have been warned.
[  151.423455] rkvdec ff66.video-codec: Adding to iommu group 1
[  151.427788] rk3288-crypto ff8b8000.crypto: will run requests pump with 
realtime priority
[  151.462746] hantro-vpu ff65.video-codec: Adding to iommu group 0
[  151.464075] hantro-vpu ff65.video-codec: 

Bug#1069077: Re: Bug#1069077: es8316 driver causes kernel oops / panic on rockpro64

2024-04-16 Thread Forest
Control: found -1 6.6.15-2


On Tue, 16 Apr 2024 10:34:45 +0200, Diederik de Haas wrote:

>Can you try the Debian Testing kernel, which is at version 6.6.15?

6.6.15-2 also has the bug.



Bug#1069077:

2024-04-15 Thread Forest
Control: retitle es8316 driver causes kernel oops / panic on rockpro64

Blacklisting the snd_soc_es8316 module in /etc/modprobe.d seems to restore
kernel stability, as far as I have seen from half a dozen reboots.



Bug#1069077: rockpro64: multiple kernel oops and frequent boot failures

2024-04-15 Thread Forest
Package: src:linux
Version: 6.7.9-2
Severity: important
X-Debbugs-Cc: fores...@sonic.net

Dear Maintainer,

The current debian unstable kernel causes a variety of failures that are not
present in the bookworm kernel, on the RockPro64 single board computer. (This
is an arm64 machine built upon the Rockchip rk3399 SoC.)

The system is sometimes able to reach a state where sshd login works, allowing
me to run reportbug, but not always. Regardless of whether it gets that far,
dmesg often contains one or more stack traces, along with messages like these:

  kernel BUG at mm/slub.c:448!
  Internal error: Oops - BUG: f2000800 [#1] SMP

  WARNING: CPU: 2 PID: 0 at kernel/context_tracking.c:128 
ct_kernel_exit.isra.0+0xa0/0xa8

  Unable to handle kernel paging request at virtual address 4daee1bbcd3980fb

I have noticed es8316 driver error messages preceding some of these stack
traces, though I'm not sure if that is always the case.

Sometimes the stack traces appear only once, during boot, and the system
appears to run normally after that. Other times, they appear every few minutes,
and various things like network services and the ability to cleanly shut down,
or even log in at the serial console, fail. In one case, I noticed a message
mentioning a kernel panic in the serial console output when I was trying to
shut down.

Since the worst examples of failure prevent me from logging in, I am unable to
run reportbug to capture information about those cases.

Reverting to linux-image-6.1.0-20-arm64 solves the problem.


-- Package-specific info:
** Version:
Linux version 6.7.9-arm64 (debian-ker...@lists.debian.org) 
(aarch64-linux-gnu-gcc-13 (Debian 13.2.0-18) 13.2.0, GNU ld (GNU Binutils for 
Debian) 2.42) #1 SMP Debian 6.7.9-2 (2024-03-13)

** Command line:
root=/dev/mapper/ console=ttyS2,150n8 net.ifnames=0

** Tainted: DWC (1664)
 * kernel died recently, i.e. there was an OOPS or BUG
 * kernel issued warning
 * staging driver was loaded

** Kernel log:
[   56.250803]  driver_attach+0x2c/0x40
[   56.250809]  bus_add_driver+0x11c/0x238
[   56.250814]  driver_register+0x64/0x138
[   56.250821]  __platform_driver_register+0x30/0x48
[   56.252550]  graph_card_init+0x28/0xff8 [snd_soc_audio_graph_card]
[   56.252565]  do_one_initcall+0x60/0x298
[   56.252574]  do_init_module+0x60/0x218
[   56.252581]  load_module+0x22b4/0x23b8
[   56.252588]  __do_sys_init_module+0x230/0x290
[   56.252593]  __arm64_sys_init_module+0x24/0x38
[   56.252599]  invoke_syscall+0x78/0x100
[   56.252609]  el0_svc_common.constprop.0+0xc8/0xf0
[   56.252617]  do_el0_svc+0x24/0x38
[   56.252624]  el0_svc+0x3c/0x108
[   56.252633]  el0t_64_sync_handler+0x120/0x130
[   56.252639]  el0t_64_sync+0x190/0x198
[   56.256943] Code: 52800024 97fff9b4 a94563f7 17d0 (d421) 
[   56.256952] ---[ end trace  ]---
[   56.256957] note: (udev-worker)[554] exited with irqs disabled
[   56.257262] [ cut here ]
[   56.258816] WARNING: CPU: 2 PID: 0 at kernel/context_tracking.c:128 
ct_kernel_exit.isra.0+0xa0/0xa8
[   56.259633] Modules linked in: snd_soc_audio_graph_card(+) 
snd_soc_simple_card snd_soc_rockchip_i2s evdev snd_soc_spdif_tx 
snd_soc_simple_card_utils snd_soc_es8316 snd_soc_hdmi_codec v4l2_vp9 
rockchip_rga v4l2_h264 videobuf2_dma_contig snd_soc_core v4l2_mem2mem 
sha512_arm64 videobuf2_dma_sg governor_simpleondemand snd_compress 
snd_pcm_dmaengine snd_pcm videobuf2_memops panfrost dw_wdt videobuf2_v4l2 
snd_timer ofpart gpu_sched snd drbg(+) leds_gpio pwm_fan drm_shmem_helper 
spi_nor videodev des_generic ansi_cprng dw_hdmi_i2s_audio dw_hdmi_cec rk_crypto 
ecdh_generic(+) rockchip_saradc gpio_ir_recv rfkill videobuf2_common mc 
crypto_engine ecc nvmem_rockchip_efuse soundcore libdes mtd rockchip_thermal 
coresight_cpu_debug industrialio_triggered_buffer sg kfifo_buf coresight_etm4x 
rockchip_dfi industrialio coresight cpufreq_dt loop efi_pstore configfs 
ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_crypt 
dm_mod dax sd_mod t10_pi xhci_plat_hcd xhci_hcd crc64_rocksoft_generic 
crc64_rocksoft crc_t10dif
[   56.259856]  crct10dif_generic crc64 realtek ahci libahci libata 
rk808_regulator dwc3 scsi_mod udc_core scsi_common fusb302 tcpm ulpi typec 
crct10dif_ce crct10dif_common polyval_ce rockchipdrm polyval_generic dw_hdmi 
dwmac_rk fan53555 cec ghash_ce stmmac_platform rc_core stmmac gf128mul 
dw_mipi_dsi analogix_dp sha2_ce pcs_xpcs pwm_regulator sha256_arm64 
drm_display_helper phylink ohci_platform sha1_ce dwc3_of_simple of_mdio 
gpio_rockchip gpio_keys ohci_hcd ehci_platform drm_dma_helper fixed_phy 
sdhci_of_arasan ehci_hcd sdhci_pltfm drm_kms_helper cqhci dw_mmc_rockchip 
fwnode_mdio phy_rockchip_inno_usb2 phy_rockchip_emmc phy_rockchip_pcie 
phy_rockchip_typec usbcore io_domain pl330 pwm_rockchip spi_rockchip drm 
dw_mmc_pltfm sdhci libphy dw_mmc i2c_rk3x usb_common fixed aes_neon_bs 
aes_neon_blk aes_ce_blk aes_ce_cipher
[   56.274047] CPU: 2 PID: 0 Comm: 

Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]

2023-07-28 Thread forest . owlet
Hi Richard,

I'm sorry for my tardy response.  I just returned from holiday.

On 2023-07-23 05:11, Richard Laager wrote:
> Some questions from upstream, with my commentary added...
> 
>> How busy is this sustem? Is it just a simple client or also a server? If 
>> server, how busy?
This is a server and participates in the NTP Pool project, so the NTPsec
process is fairly busy.  From the logs the server is handling about 1.5
to 1.7 million NTP requests per hour.

>> 
>> From the stack trace, the server side is trying to decode a NTS cookie. Is 
>> this box setup as a NTS server? That needs a certificate and key so it takes 
>> more than just upgrading from bullseye to bookworm.
> 
> It's not, right? We previously established that this is using the stock 
> ntp.conf?
> 
No, it is not configured as an NTS server.

>> What are the chances that a valid NTP request with NTS arrived at this 
>> system? ntpq -c ntsinfo will show counters.
>
I'd say the chances are fairly high that an invalid NTP request with NTS
has arrived.  But the counters are all zero.
cyclone@karita:~$ ntpq -c ntsinfo
NTS client sends:   0
NTS client recvs good:  0
NTS client recvs w error:   0
NTS server recvs good:  0
NTS server recvs w error:   0
NTS server sends:   0
NTS make cookies:   0
NTS decode cookies: 0
NTS decode cookies old: 0
NTS decode cookies old2:0
NTS decode cookies older:   0
NTS decode cookies too old: 0
NTS decode cookies error:   0
NTS KE client probes good:  0
NTS KE client probes bad:   0
NTS KE serves good: 0
NTS KE serves bad:  0
cyclone@karita:~$
 
> It would be good if you could check this. But if an NTS request is crashing 
> ntpd, you might never see non-zero counters.
> 
>> The log file from starting up might be helpful.

Here's the syslog entries from the most recent restart.  I took the
liberty of scrubbing the high portions of the IP addresses.

2023-07-28T06:58:39.890236+00:00 karita ntpd[30320]: INIT: ntpd
ntpsec-1.2.2: Starting
2023-07-28T06:58:39.891073+00:00 karita ntpd[30320]: INIT: Command line:
/usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u
ntpsec:ntpsec
2023-07-28T06:58:39.891132+00:00 karita ntp-systemd-wrapper[30320]:
2023-07-28T06:58:39 ntpd[30320]: INIT: ntpd ntpsec-1.2.2: Starting
2023-07-28T06:58:39.892382+00:00 karita ntp-systemd-wrapper[30320]:
2023-07-28T06:58:39 ntpd[30320]: INIT: Command line: /usr/sbin/ntpd -p
/run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec
2023-07-28T06:58:39.892502+00:00 karita systemd[1]: Started
ntpsec.service - Network Time Service.
2023-07-28T06:58:39.894804+00:00 karita ntpd[30322]: INIT: precision =
0.060 usec (-24)
2023-07-28T06:58:39.895396+00:00 karita ntpd[30322]: INIT: successfully
locked into RAM
2023-07-28T06:58:39.899405+00:00 karita ntpd[30322]: CONFIG: readconfig:
parsing file: /etc/ntpsec/ntp.conf
2023-07-28T06:58:39.899544+00:00 karita ntpd[30322]: CONFIG: restrict
nopeer ignored
2023-07-28T06:58:39.900054+00:00 karita ntpd[30322]: CLOCK: leapsecond
file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
2023-07-28T06:58:39.900121+00:00 karita ntpd[30322]: CLOCK: leapsecond
file ('/usr/share/zoneinfo/leap-seconds.list'): loaded,
expire=2023-12-28T00:00Z last=2017-01-01T00:00Z ofs=37
2023-07-28T06:58:39.900198+00:00 karita ntpd[30322]: INIT: Using
SO_TIMESTAMPNS(ns)
2023-07-28T06:58:39.900262+00:00 karita ntpd[30322]: IO: Listen and drop
on 0 v6wildcard [::]:123
2023-07-28T06:58:39.900367+00:00 karita ntpd[30322]: IO: Listen and drop
on 1 v4wildcard 0.0.0.0:123
2023-07-28T06:58:39.900518+00:00 karita ntpd[30322]: IO: Listen normally
on 2 lo 127.0.0.1:123
2023-07-28T06:58:39.900589+00:00 karita ntpd[30322]: IO: Listen normally
on 3 eth0 xxx.yyy.zzz.201:123
2023-07-28T06:58:39.900662+00:00 karita ntpd[30322]: IO: Listen normally
on 4 lo [::1]:123
2023-07-28T06:58:39.900913+00:00 karita ntpd[30322]: IO: Listen normally
on 5 eth0 [::::5ce7]:123
2023-07-28T06:58:39.901000+00:00 karita ntpd[30322]: IO: Listen normally
on 6 eth0 [fe80:::::dfe%2]:123
2023-07-28T06:58:39.901065+00:00 karita ntpd[30322]: IO: Listening on
routing socket on fd #23 for interface updates
2023-07-28T06:58:39.912520+00:00 karita ntpd[30322]: INIT: MRU 10922
entries, 13 hash bits, 65536 bytes
2023-07-28T06:58:39.912607+00:00 karita ntpd[30322]: INIT: Built with
OpenSSL 3.0.7 1 Nov 2022, 3070
2023-07-28T06:58:39.912652+00:00 karita ntpd[30322]: INIT: Running with
OpenSSL 3.0.9 30 May 2023, 3090
2023-07-28T06:58:39.912976+00:00 karita ntpd[30322]: NTSc: Using system
default root certificates.
2023-07-28T06:58:42.938515+00:00 karita ntpd[30322]: DNS: dns_probe:
0.debian.pool.ntp.org, cast_flags:8, flags:101
2023-07-28T06:58:42.957881+00:00 karita 

Bug#1030129: ca-certificates-java - Fails to install: Error loading java.security file

2023-07-20 Thread Forest
The fixed version has been in Testing for over a week now. Does another step
remain in order to get it into Stable or Backports?

This is blocking the installation of the java runtime on Bookworm systems
(unless, presumably, they upgraded from Bullseye and already had it).



Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]

2023-06-29 Thread forest . owlet
Hi,

Here's a backtrace from the latest ntpsec coredump.

root@karita:/var/lib/systemd/coredump# export
DEBUGINFOD_URLS="https://debuginfod.debian.net;
root@karita:/var/lib/systemd/coredump# coredumpctl debug
  PID: 61726 (ntpd)
   UID: 110 (ntpsec)
   GID: 117 (ntpsec)
Signal: 11 (SEGV)
 Timestamp: Fri 2023-06-30 02:33:27 UTC (59min ago)
  Command Line: /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf
-g -N -u ntpsec:ntpsec
Executable: /usr/sbin/ntpd
 Control Group: /system.slice/ntpsec.service
  Unit: ntpsec.service
 Slice: system.slice
   Boot ID: 0e943a6b0cfe4fdd9e032c3d91c9d58d
Machine ID: 0e50b80b858599a4a8aa8383662e5bb4
  Hostname: karita
   Storage:
/var/lib/systemd/coredump/core.ntpd.110.0e943a6b0cfe4fdd9e032c3d91c9d58d.61726.168809240700.zst
(present)
  Size on Disk: 775.6K
   Message: Process 61726 (ntpd) of user 110 dumped core.

Module libnss_systemd.so.2 from deb
systemd-252.6-1.amd64
Stack trace of thread 61726:
#0  0x7f280d4e0ab3 aesni_set_encrypt_key
(libcrypto.so.3 + 0xe0ab3)
#1  0x7f280d6f3d45 cipher_hw_aesni_initkey
(libcrypto.so.3 + 0x2f3d45)
#2  0x7f280d7397fb cipher_generic_init_internal
(libcrypto.so.3 + 0x3397fb)
#3  0x7f280d7398cb ossl_cipher_generic_einit
(libcrypto.so.3 + 0x3398cb)
#4  0x7f280d60993b EVP_CipherInit_ex (libcrypto.so.3
+ 0x20993b)
#5  0x560b2e1246f3 AES_SIV_Init (ntpd + 0x4c6f3)
#6  0x560b2e1255df AES_SIV_Decrypt (ntpd + 0x4d5df)
#7  0x560b2e10f40d nts_unpack_cookie (ntpd +
0x3740d)
#8  0x560b2e10f85b extens_server_recv (ntpd +
0x3785b)
#9  0x560b2e0f78ce receive (ntpd + 0x1f8ce)
#10 0x560b2e0ed8ea read_network_packet (ntpd +
0x158ea)
#11 0x560b2e0ef3cf input_handler (ntpd + 0x173cf)
#12 0x560b2e0e819f mainloop (ntpd + 0x1019f)
#13 0x7f280d16718a __libc_start_call_main (libc.so.6
+ 0x2718a)
#14 0x7f280d167245 __libc_start_main_impl (libc.so.6
+ 0x27245)
#15 0x560b2e0e84e1 _start (ntpd + 0x104e1)
ELF object binary architecture: AMD x86-64

GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/ntpd...
Reading symbols from
/usr/lib/debug/.build-id/8b/c6f9398efb6b8c446b2d719831f5738d563c84.debug...
[New LWP 61726]

This GDB supports auto-downloading debuginfo from the following URLs:
  
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to
.gdbinit.
Downloading separate debug info for
/lib/x86_64-linux-gnu/libnss_systemd.so.2
Downloading separate debug info for /lib/x86_64-linux-gnu/libgcc_s.so.1
Downloading separate debug info for system-supplied DSO at
0x7ffc94772000
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/ntpd -p /run/ntpd.pid -c
/etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  aesni_set_encrypt_key () at crypto/aes/aesni-x86_64.s:4104
Download failed: Invalid argument.  Continuing without source file
./build_shared/crypto/aes/aesni-x86_64.s.
4104crypto/aes/aesni-x86_64.s: No such file or directory.
(gdb) bt
#0  aesni_set_encrypt_key () at crypto/aes/aesni-x86_64.s:4104
#1  0x7f280d6f3d45 in cipher_hw_aesni_initkey (dat=0x560b2f082b50,
key=, keylen=)
at ../providers/implementations/ciphers/cipher_aes_hw_aesni.inc:37
#2  0x7f280d7397fb in cipher_generic_init_internal
(ctx=0x560b2f082b50,
key=0x10 , keylen=16,
iv=0x0,
ivlen=0, params=0x0, enc=1)
at ../providers/implementations/ciphers/ciphercommon.c:218
#3  0x7f280d7398cb in ossl_cipher_generic_einit (vctx=,
key=, keylen=, iv=,
ivlen=, params=)
at ../providers/implementations/ciphers/ciphercommon.c:228
#4  0x7f280d60993b in EVP_CipherInit_ex (ctx=,
cipher=, impl=impl@entry=0x0, key=,
iv=iv@entry=0x0, 

Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]

2023-06-28 Thread forest . owlet
On 2023-06-28 02:39, Richard Laager wrote:
> The original submitter replied off the tracker (probably by accident). I'll 
> summarize here.
> 
> The ntp.conf he included is the stock ntp.conf.
> 
> He indicated he will try to get a backtrace.

I'm trying to setup ntpsec to get a backtrace.  I installed the
ntpsec-dbgsym package, but I'm not sure that I did it correctly. 
Shouldn't the output from this file command include the text "no
stripped".

root@karita:/home/root# file /usr/sbin/ntpd
/usr/sbin/ntpd: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=8bc6f9398efb6b8c446b2d719831f5738d563c84, for GNU/Linux
3.2.0, stripped
root@karita:/home/root#

Regards,


Roy



Bug#1033917: [pkg-lxc-devel] Bug#1033917: lxc: apparmor profile no longer allows unprivileged guest systemd-logind to start (since bookworm)

2023-04-04 Thread Forest
>What's weird is that the problem was already happening in buster and
>bullseye.

That doesn't seem to be true, AFAICT.  Bullseye (both my usual Bullseye
guest and a freshly installed one) does not exhibit the 25 second hang.  A
freshly installed Buster guest doesn't, either.  Not even with the default
config instead of nesting.conf.

To be precise:  Although Bullseye and Buster do generate apparmor mount
errors in the host's syslog, the 25 second hang is new with Bookworm guests.
Maybe multiple problems are in play here?

>I guess it is plausible that /etc/lxc/default.conf has been updated in
>your upgrade, resetting the lxc-apparmor-profile to something that won't
>work for unprivileged containers.

Nope. I haven't upgraded the Bullseye host machine on which I discovered the
hang, and it occurs on both that host and a newly installed Bookworm host.
Also, I checked default.conf on both hosts just now, and it matches the one
in lxc_5.0.2-1_amd64.deb.

>The missing lines in apparmor rules have been added in
>lxc-default-with-nesting rules of apparmor for lxc 5.

My fresh Bookworm VM has lxc 5, and those four additional lines are present
in /etc/apparmor.d/lxc/lxc-default-with-nesting.  The contents of
/usr/share/lxc/config/nesting.conf are also identical.  Even when including
it in my container config, the 25 second hang persists.

>the solution lies either within LXD
>(which generates custom profiles for each containers), or with creating
>a dedicated apparmor profile that you use only on unprivileged
>containers.

I tried LXD as a workaround.  Turns out it is not a suitable replacement in
my case.

I would be happy to try a modified apparmor profile.  Ideally even get it
added into Bookworm's lxc package, or accepted upstream, so Bookworm doesn't
arrive in this broken state for lxc users.

I tried modifying the apparmor profile based on the host's syslog messages.
Despite using exactly the same mount options that appeared in the logs, the
errors and the 25 second hang persisted.  (And I did remember to reload the
profile with apparmor_parser -r.)  I wonder if the info="failed flags match"
in those syslog messages is supposed to hint that something more is needed.

It seems like we're missing some information here.



Bug#1033917: lxc: apparmor profile no longer allows unprivileged guest systemd-logind to start (since bookworm)

2023-04-03 Thread Forest
Package: lxc
Version: 1:5.0.2-1
Severity: normal
X-Debbugs-Cc: fores...@sonic.net

Dear Maintainer,

After upgrading an unprivileged container from bullseye to bookworm, LXC's
AppArmor profiles are no longer sufficient for the guest's systemd-logind.

This manifests as a 25 second hang when running certain commands (notably
sudo -i and su -) in the container. It also produces a lot of errors in the
host & guest logs.

Before the upgrade to bookworm, the hangs did not occur, and systemd-logind
started without trouble.


-- Host journal:

Apr 02 18:30:01 debtesting CRON[6361]: pam_unix(cron:session): session opened 
for user root(uid=0) by (uid=0)
Apr 02 18:30:01 debtesting CRON[6362]: (root) CMD ([ -x /etc/init.d/anacron ] 
&& if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start 
>/dev/null; fi)
Apr 02 18:30:01 debtesting CRON[6361]: pam_unix(cron:session): session closed 
for user root
Apr 02 18:30:16 debtesting audit[6365]: AVC apparmor="DENIED" operation="mount" 
info="failed flags match" error=-13 profile="lxc-container-default-cgns" 
name="/" pid=6365 comm="(d-logind)" flags="rw, rslave"
Apr 02 18:30:16 debtesting kernel: kauditd_printk_skb: 13 callbacks suppressed
Apr 02 18:30:16 debtesting kernel: audit: type=1400 audit(1680485416.414:324): 
apparmor="DENIED" operation="mount" info="failed flags match" error=-13 
profile="lxc-container-default-cgns" name="/" pid=6365 comm="(d-logind)" 
flags="rw, rslave"
Apr 02 18:30:16 debtesting audit[6369]: AVC apparmor="DENIED" operation="mount" 
info="failed flags match" error=-13 profile="lxc-container-default-cgns" 
name="/" pid=6369 comm="(d-logind)" flags="rw, rslave"
Apr 02 18:30:16 debtesting kernel: audit: type=1400 audit(1680485416.426:325): 
apparmor="DENIED" operation="mount" info="failed flags match" error=-13 
profile="lxc-container-default-cgns" name="/" pid=6369 comm="(d-logind)" 
flags="rw, rslave"
Apr 02 18:30:16 debtesting audit[6373]: AVC apparmor="DENIED" operation="mount" 
info="failed flags match" error=-13 profile="lxc-container-default-cgns" 
name="/" pid=6373 comm="(d-logind)" flags="rw, rslave"
Apr 02 18:30:16 debtesting kernel: audit: type=1400 audit(1680485416.450:326): 
apparmor="DENIED" operation="mount" info="failed flags match" error=-13 
profile="lxc-container-default-cgns" name="/" pid=6373 comm="(d-logind)" 
flags="rw, rslave"
Apr 02 18:30:16 debtesting audit[6377]: AVC apparmor="DENIED" operation="mount" 
info="failed flags match" error=-13 profile="lxc-container-default-cgns" 
name="/" pid=6377 comm="(d-logind)" flags="rw, rslave"
Apr 02 18:30:16 debtesting kernel: audit: type=1400 audit(1680485416.522:327): 
apparmor="DENIED" operation="mount" info="failed flags match" error=-13 
profile="lxc-container-default-cgns" name="/" pid=6377 comm="(d-logind)" 
flags="rw, rslave"
Apr 02 18:30:16 debtesting audit[6381]: AVC apparmor="DENIED" operation="mount" 
info="failed flags match" error=-13 profile="lxc-container-default-cgns" 
name="/" pid=6381 comm="(d-logind)" flags="rw, rslave"
Apr 02 18:30:16 debtesting kernel: audit: type=1400 audit(1680485416.534:328): 
apparmor="DENIED" operation="mount" info="failed flags match" error=-13 
profile="lxc-container-default-cgns" name="/" pid=6381 comm="(d-logind)" 
flags="rw, rslave"


-- Guest journal:

Apr 02 18:30:16 lxbox sudo[136]: root : TTY=pts/7 ; PWD=/root ; USER=root ; 
COMMAND=/bin/bash
Apr 02 18:30:16 lxbox sudo[136]: pam_limits(sudo-i:session): Could not set 
limit for 'core' to soft=0, hard=-1: Operation not permitted; uid=0,euid=0
Apr 02 18:30:16 lxbox sudo[136]: pam_unix(sudo-i:session): session opened for 
user root(uid=0) by (uid=0)
Apr 02 18:30:16 lxbox dbus-daemon[97]: [system] Activating via systemd: service 
name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service' 
requested by ':1.2' (uid=0 pid=136 comm="sudo -i")
Apr 02 18:30:16 lxbox systemd[1]: Starting modprobe@drm.service - Load Kernel 
Module drm...
Apr 02 18:30:16 lxbox (modprobe)[137]: modprobe@drm.service: Executable 
/sbin/modprobe missing, skipping: No such file or directory
Apr 02 18:30:16 lxbox systemd[1]: modprobe@drm.service: Deactivated 
successfully.
Apr 02 18:30:16 lxbox systemd[1]: Finished modprobe@drm.service - Load Kernel 
Module drm.
Apr 02 18:30:16 lxbox systemd[1]: Starting systemd-logind.service - User Login 
Management...
Apr 02 18:30:16 lxbox (d-logind)[138]: systemd-logind.service: Failed to set up 
mount namespacing: Permission denied
Apr 02 18:30:16 lxbox (d-logind)[138]: systemd-logind.service: Failed at step 
NAMESPACE spawning /lib/systemd/systemd-logind: Permission denied
Apr 02 18:30:16 lxbox systemd[1]: systemd-logind.service: Main process exited, 
code=exited, status=226/NAMESPACE
Apr 02 18:30:16 lxbox systemd[1]: systemd-logind.service: Failed with result 
'exit-code'.
Apr 02 18:30:16 lxbox systemd[1]: Failed to start systemd-logind.service - User 
Login Management.
Apr 02 18:30:16 lxbox systemd[1]: systemd-logind.service: Scheduled 

Bug#1030917: systemsettings: kcm_users creates new users with shell set to /usr/sbin/nologin

2023-02-08 Thread Forest
Package: systemsettings
Version: 4:5.26.90-1
Severity: normal
X-Debbugs-Cc: fores...@sonic.net

Dear Maintainer,

When creating a new user in the KDE Plasma System Settings: Users panel,
the new user's shell is set to /usr/sbin/nologin in /etc/passwd.
I believe it should be /bin/bash or some other usable default.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages systemsettings depends on:
ii  kio 5.102.0-1
ii  kpackagetool5   5.102.0-1
ii  libc6   2.36-8
ii  libkf5activities5   5.102.0-1
ii  libkf5auth5 5.102.0-1
ii  libkf5authcore5 5.102.0-1
ii  libkf5completion5   5.102.0-1
ii  libkf5configcore5   5.102.0-1
ii  libkf5configgui55.102.0-1
ii  libkf5configwidgets55.102.0-1
ii  libkf5coreaddons5   5.102.0-1
ii  libkf5crash55.102.0-1
ii  libkf5dbusaddons5   5.102.0-1
ii  libkf5i18n5 5.102.0-1
ii  libkf5iconthemes5   5.102.0-1
ii  libkf5itemmodels5   5.102.0-1
ii  libkf5itemviews55.102.0-1
ii  libkf5kcmutils5 5.102.0-1
ii  libkf5kiocore5  5.102.0-1
ii  libkf5kiogui5   5.102.0-1
ii  libkf5kiowidgets5   5.102.0-1
ii  libkf5kirigami2-5   5.102.0-1
ii  libkf5notifications55.102.0-1
ii  libkf5package5  5.102.0-1
ii  libkf5runner5   5.102.0-1
ii  libkf5service-bin   5.102.0-1
ii  libkf5service5  5.102.0-1
ii  libkf5widgetsaddons55.102.0-1
ii  libkf5windowsystem5 5.102.0-1
ii  libkf5xmlgui5   5.102.0-1
ii  libkworkspace5-54:5.26.90-1
ii  libqt5core5a5.15.8+dfsg-2
ii  libqt5gui5  5.15.8+dfsg-2
ii  libqt5qml5  5.15.8+dfsg-2
ii  libqt5quick55.15.8+dfsg-2
ii  libqt5quickwidgets5 5.15.8+dfsg-2
ii  libqt5widgets5  5.15.8+dfsg-2
ii  libstdc++6  12.2.0-14
ii  qml-module-org-kde-kcm  5.102.0-1
ii  qml-module-org-kde-kcmutils 5.102.0-1
ii  qml-module-org-kde-kirigami25.102.0-1
ii  qml-module-org-kde-kitemmodels  5.102.0-1
ii  qml-module-org-kde-newstuff 5.102.0-1
ii  qml-module-qtquick-controls 5.15.8-2
ii  qml-module-qtquick-layouts  5.15.8+dfsg-2
ii  qml-module-qtquick-shapes   5.15.8+dfsg-2
ii  qml-module-qtquick2 5.15.8+dfsg-2

systemsettings recommends no packages.

systemsettings suggests no packages.

-- no debconf information



Bug#1028369: debian-live: screen lock demands a password

2023-01-09 Thread Forest
Package: debian-live
Severity: normal

Dear Maintainer,

While installing from the kde+nonfree debian-live-11.6.0 image,
the screen lock engaged, demanding a password to regain control
of the session.

Of course, since this is a live ISO image, I didn't know the
password. I had to find another computer and search the web
for a while, eventually finding someone who correctly guessed
that the password is "live", before I could continue the
installation.

I suspect this is a mistake, and that there should be no password
set on the live user account.
*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



Bug#983818: linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module

2022-07-31 Thread Forest
On Sun, 31 Jul 2022 12:30:42 +0200, Diederik de Haas wrote:

>From the partial logs you shared it appeared that your network also went down 
>after (quite) some time,

If you're referring to my 5.14.0-1 kernel log, I can't offer any insight, as
I only tried that kernel briefly, nearly a year ago.

If you mean the 5.10 kernel, let me clarify:

1. 5.10 reliably brings up eth0 early enough for dropbear sshd to work. 
2. I ssh to dropbear, enter the LUKS passphrase, and the root filesystem is
unlocked.
3. When eth0 fails, it's always shortly after that, still during system
startup.
4. Once I notice, attach a serial terminal, and reload the kernel module,
eth0 comes up and stays up. It doesn't go down again later.

I find it curious that eth0 comes up reliably and then *sometimes* goes down
shortly afterward.  I don't know if it's completely random or something
later in the startup process is triggering it.

Obviously, a delay between eth0 first coming up and when it goes down could
be partly from the time it takes me to ssh and type a LUKS passphrase.

>What's odd then is that that commit has been applied/backported to the 5.10 
>kernel under commit 97653ba562b9b28e30a3fcff42531e05a434d58c which is part of 
>5.10.82, so also 5.10.127-2 ...

Ah, I didn't notice that patch having been backported with a different
commit ID.  Thanks for mentioning it.



Bug#983818: linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module

2022-07-30 Thread Forest
Control: found -1 5.10.127-2
Control: notfound -1 5.18.14-1
Control: tags -1 - moreinfo

On Sat, 30 Jul 2022 00:19:25 +0200, Diederik de Haas wrote:

>Is this problem still present with a recent 5.10 or (better yet) the 5.18.14 
>kernel from Unstable?

It is still present in recent 5.10 kernels.

5.18.14-1 from unstable hasn't shown the failure in about a dozen boots.
That's encouraging.  I haven't done a bisect, but some relatively recent
commits (e.g. aec3f415) mention dwmac-rk.  Perhaps one of those fixed it?



Bug#1010080: wiki.debian.org: silently fails to create account

2022-04-23 Thread Forest
Package: wiki.debian.org
Severity: important
X-Debbugs-Cc: fores...@sonic.net

Dear Maintainer,

After filling in and submitting the wiki's Create Account form, the wiki
returns me to the last page I was visiting, apparently ignoring my submission
completely.

It doesn't acknowledge that an account was created.
It doesn't show an error message.
It doesn't send me an email confirmation message.
It doesn't show me as logged it.
It doesn't log me in when I use the login form.

It behaves as if I never submitted the New Account form at all.

I am therefore unable to contribute to the wiki.



Bug#983818: linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module

2021-09-26 Thread Forest
Control: tags -1 - moreinfo

>Could you try with the current kernel in unstable?
>We are at 5.14.6-2, which had some rk3399 related changes. 

Did any of those changes arrive after 5.14.0-1?  If so, I suppose I would
have to wait for a newer debian kernel to appear before I could test it.

With 5.14.0-1 (the version in unstable), the results are worse:

Dropbear no longer works.  Error message:
/scripts/init-premount/dropbear: .: line 333: can't open '/run/net-*.conf': No 
such file or directory

Using a serial console for LUKS unlock and then running rmmod dwmac_rk / 
modprobe dwmac_rk no longer brings up eth0.

The dmesg output has changed a bit:
$ egrep 'mac|eth0' dmesg.linux-image-5.14.0-1-arm64 
[5.708873] rk_gmac-dwmac fe30.ethernet: IRQ eth_wake_irq not found
[5.709470] rk_gmac-dwmac fe30.ethernet: IRQ eth_lpi not found
[5.710965] rk_gmac-dwmac fe30.ethernet: PTP uses main clock
[5.712133] rk_gmac-dwmac fe30.ethernet: clock input or output? (input).
[5.713263] rk_gmac-dwmac fe30.ethernet: TX delay(0x28).
[5.714418] rk_gmac-dwmac fe30.ethernet: RX delay(0x11).
[5.716512] rk_gmac-dwmac fe30.ethernet: integrated PHY? (no).
[5.717492] rk_gmac-dwmac fe30.ethernet: cannot get clock clk_mac_speed
[5.719275] rk_gmac-dwmac fe30.ethernet: clock input from PHY
[5.724825] rk_gmac-dwmac fe30.ethernet: init for RGMII
[5.725658] rk_gmac-dwmac fe30.ethernet: User ID: 0x10, Synopsys ID: 0x35
[5.726328] rk_gmac-dwmac fe30.ethernet: DWMAC1000
[5.726802] rk_gmac-dwmac fe30.ethernet: DMA HW capability register 
supported
[5.727511] rk_gmac-dwmac fe30.ethernet: RX Checksum Offload Engine 
supported
[5.728183] rk_gmac-dwmac fe30.ethernet: COE Type 2
[5.728652] rk_gmac-dwmac fe30.ethernet: TX Checksum insertion supported
[5.729275] rk_gmac-dwmac fe30.ethernet: Wake-Up On Lan supported
[5.731134] rk_gmac-dwmac fe30.ethernet: Normal descriptors
[5.731674] rk_gmac-dwmac fe30.ethernet: Ring mode enabled
[5.732192] rk_gmac-dwmac fe30.ethernet: Enable RX Mitigation via HW 
Watchdog Timer
[5.851291] libphy: stmmac: probed
[5.851612] RTL8211F Gigabit Ethernet stmmac-0:00: attached PHY driver 
(mii_bus:phy_addr=stmmac-0:00, irq=POLL)
[5.852504] RTL8211F Gigabit Ethernet stmmac-0:01: attached PHY driver 
(mii_bus:phy_addr=stmmac-0:01, irq=POLL)
[6.639085] rk_gmac-dwmac fe30.ethernet eth0: PHY [stmmac-0:00] driver 
[RTL8211F Gigabit Ethernet] (irq=POLL)
[6.641458] rk_gmac-dwmac fe30.ethernet eth0: Register 
MEM_TYPE_PAGE_POOL RxQ-0
[6.653320] rk_gmac-dwmac fe30.ethernet eth0: No Safety Features support 
found
[6.653364] rk_gmac-dwmac fe30.ethernet eth0: PTP not supported by HW
[6.654183] rk_gmac-dwmac fe30.ethernet eth0: configuring for phy/rgmii 
link mode
[9.760371] rk_gmac-dwmac fe30.ethernet eth0: Link is Up - 1Gbps/Full - 
flow control rx/tx
[9.760429] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  199.685064] rk_gmac-dwmac fe30.ethernet eth0: Link is Down
[  207.195113] rk_gmac-dwmac fe30.ethernet eth0: PHY [stmmac-0:00] driver 
[RTL8211F Gigabit Ethernet] (irq=POLL)
[  207.197673] rk_gmac-dwmac fe30.ethernet eth0: Register 
MEM_TYPE_PAGE_POOL RxQ-0
[  207.206976] rk_gmac-dwmac fe30.ethernet eth0: No Safety Features support 
found
[  207.207681] rk_gmac-dwmac fe30.ethernet eth0: PTP not supported by HW
[  207.208307] rk_gmac-dwmac fe30.ethernet eth0: configuring for phy/rgmii 
link mode
[  210.304576] rk_gmac-dwmac fe30.ethernet eth0: Link is Up - 1Gbps/Full - 
flow control rx/tx
[  210.305423] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready



Bug#992486: docker.io: cgroup v2 defaults break rootless container start & build

2021-08-20 Thread Forest
To be clear, I'm not advocating for more systemd dependencies. It's just
that as things stand today, someone installing docker.io for rootless
containers will find that they simply fail with a cryptic error message.

Maybe Debian's dockerd-rootless-setuptool.sh script should use --exec-opt
native.cgroupdriver=cgroupfs by default?

Better still, maybe this situation should be detected by the software, and
the cryptic error message replaced with an explanation of what is happening
and that it can be fixed with either native.cgroupdriver=cgroupfs or
dbus-user-session?



Bug#992486: docker.io: cgroup v2 defaults break rootless container start & build

2021-08-20 Thread Forest
On Fri, 20 Aug 2021 22:48:18 +0800, Shengjing Zhu wrote:

>Yes. The default mode, which is using systemd to setup cgroup, requires dbus.
>So you need to install dbus-user-session, which will provide 
>/run/user/$uid/bus.
>
>Or you can use cgroupfs mode, which is mentioned in your first mail,
>as a workaround.

In that case, shouldn't Debian's docker.io package document this requirement
for rootless containers? And shouldn't the runc package have Suggests:
dbus-user-session?



Bug#992486: docker.io: cgroup v2 defaults break rootless container start & build

2021-08-19 Thread Forest
On Fri, 20 Aug 2021 12:09:34 +0800, Shengjing Zhu wrote:

>This one looks almost same:
>
>https://github.com/opencontainers/runc/issues/3124

Hm... The conditions in that issue are different (my /proc is not mounted
with a hidepid option) but yes, the docker error message looks similar.

>Could you try command like:
>
>  busctl --user --no-pager status

$ busctl --user --no-pager status
Failed to connect to bus: No such file or directory

When I run it again with strace, I see this system call failing:

connect(3, {sa_family=AF_UNIX, sun_path="/run/user/[UID]/bus"}, 21) = -1
ENOENT (No such file or directory)

The /run/user/[UID]/ directory does exist, both for the current user and
other users, but they do not contain a file named "bus".  Perhaps because
this is a headless server with no desktop sessions at all?

>Also as it's likely upstream issue, could you try Docker Inc's rootless 
>binaries?

I'm afraid I cannot. The policy for this machine is only to run binaries
from debian or built locally.

However, if runc assumes the presence of /run/user/$uid/bus, that does seem
likely to be a problem, does it not?



Bug#992486: docker.io: cgroup v2 defaults break rootless container start & build

2021-08-19 Thread Forest
On Thu, 19 Aug 2021 22:54:41 +0800, Shengjing Zhu wrote:

>It works for me. Here are my docker.service file and cgroup mount
>info. Could you compare the output?

> >docker.service<=

My ExecStart= line includes --storage-driver=overlay, which is needed to avoid
filesystem failures in my containers.  (I remember using overlay2 in the past,
but after running into a bug, I reverted to the older overlay driver.)

My PATH= line is the only other difference. Using yours instead does not fix the
error. (My PATH matches the output of `systemd-path search-binaries-default`.)

Other than that, our docker.service files are the same.


> >cgroup<

Our `mount|grep cgroup` output matches exactly.


> >systemctl<

Our systemctl status top sections have minor differences:
- Your rootlesskit and /proc/self/exe command lines look truncated.
- My dockerd command line includes --storage-driver=overlay, of course.
- CPU time, pids, and paths are different, of course.


Our systemctl status log messages are quite different.
Starting docker without my workaround yields these messages:

level=warning msg="Unable to find cpu controller"
level=warning msg="Unable to find io controller"
level=warning msg="Unable to find cpuset controller"
level=info msg="Loading containers: start."
level=warning msg="Running modprobe bridge br_netfilter failed with message: 
modprobe: ERROR: could not insert 'br_netfilter': Operation not 
permitted\ninsmod /lib/modules/5.10.0-8-arm64/kernel/net/bridge/br_netfilter.ko 
\n, error: exit status 1"
level=info msg="Default bridge (docker0) is assigned with an IP address 
172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address"
level=info msg="Loading containers: done."
level=info msg="Docker daemon" commit=363e9a8 graphdriver(s)=overlay 
version=20.10.5+dfsg1
level=info msg="Daemon has completed initialization"
level=info msg="API listen on /run/user/[UID]/docker.sock"

Attempting to run a container without my workaround yields these messages:

level=info msg="starting signal loop" namespace=moby 
path=/run/.ro138154868/user/[UID]/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/[CONTAINERID]
 pid=[PID]
level=info msg="shim disconnected" id=[CONTAINERID]
level=error msg="stream copy error: reading from a closed fifo"
level=error msg="stream copy error: reading from a closed fifo"
level=error msg="[CONTAINERID] cleanup: failed to delete container from 
containerd: no such container"
level=error msg="Handler for POST /v1.41/containers/[CONTAINERID]/start 
returned error: OCI runtime create failed: container_linux.go:367: starting 
container process caused: process_linux.go:340: applying cgroup configuration 
for process caused: read unix @->/run/systemd/private: read: connection reset 
by peer: unknown"


> >docker info<

My `docker info` output has several differences from yours:

Context:default
Images: 9
Storage Driver: overlay
 Backing Filesystem: extfs
 Supports d_type: true
Kernel Version: 5.10.0-8-arm64
Architecture: aarch64

Mine also includes some host details at the end (which I assume you
deliberately skipped) and these warnings:

WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
WARNING: No cpu shares support
WARNING: No cpuset support
WARNING: Support for cgroup v2 is experimental
WARNING: No io.weight support
WARNING: No io.weight (per device) support
WARNING: No io.max (rbps) support
WARNING: No io.max (wbps) support
WARNING: No io.max (riops) support
WARNING: No io.max (wiops) support
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
WARNING: the overlay storage-driver is deprecated, and will be removed in a 
future release.


> I think the difference may be the arch, as I'm testing it on amd64.
> Not sure if it's an arm64 specific kernel issue.

Maybe; I don't know much about cgroups. Do they behave differently on
arm64 vs. amd64?

I notice that you're running a kernel package one version behind mine.



Bug#992486: docker.io: cgroup v2 defaults break rootless container start & build

2021-08-19 Thread Forest
Package: docker.io
Version: 20.10.5+dfsg1-1+b5
Severity: important

Dear Maintainer,

After upgrading from Buster to Bullseye, rootless docker containers now fail
to build or start, with the following error message:

Error response from daemon: OCI runtime create failed: container_linux.go:367: 
starting container process caused: process_linux.go:340: applying cgroup 
configuration for
process caused: read unix @->/run/systemd/private: read: connection reset by 
peer: unknown
Error: failed to start containers: mycontainer

The failure seems related to the switch from cgroup v1 to v2 in Bullseye.
I have found two workarounds:

1. Edit ~/.config/systemd/user/docker.service (which was generated by
dockerd-rootless-setuptool.sh), adding this option to the ExecStart command:
--exec-opt native.cgroupdriver=cgroupfs

2. Boot the system with these kernel options:
systemd.unified_cgroup_hierarchy=false
systemd.legacy_systemd_cgroup_controller=false

Since there appears to be a mismatch between how Bullseye manages cgroups v2
and how docker expects them to be managed, my uninformed guess is that one of
them needs to change. Failing that, perhaps dockerd-rootless-setuptool.sh
should be updated to apply workaround #1 when generating new unit files?

(In case you wonder how rootless docker was working on Buster in the first
place, it's because I have been using the Debian Unstable docker.io package
& dependencies on my Buster system for about a year.)

Thanks for your attention.

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.0-8-arm64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages docker.io depends on:
ii  adduser  3.118
ii  containerd   1.4.5~ds1-2
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.31-13
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libsystemd0  247.3-6
ii  lsb-base 11.1.0
ii  runc 1.0.0~rc93+ds1-5+b2
ii  tini 0.19.0-1

Versions of packages docker.io recommends:
ii  apparmor 2.13.6-10
ii  ca-certificates  20210119
pn  cgroupfs-mount   
ii  git  1:2.30.2-1
pn  needrestart  
ii  xz-utils 5.2.5-2

Versions of packages docker.io suggests:
pn  aufs-tools 
pn  btrfs-progs
pn  debootstrap
pn  docker-doc 
ii  e2fsprogs  1.46.2-2
pn  rinse  
ii  rootlesskit0.14.2-1+b3
pn  xfsprogs   
pn  zfs-fuse | zfsutils-linux  

-- no debconf information



Bug#962214: (no subject)

2021-04-29 Thread julien forest
Package: policykit-1 
Version: 0.105-30
State: not installed
Multi-Arch: foreign
Priority: optional
Section: admin
Maintainer: Utopia Maintenance Team
 Architecture: amd64
Uncompressed Size: 335 k
Depends: ... default-logind | logind ...

which itself depends on libpam-systemd or libpam-elogind 

There is no need IMHO to add such a dependency (maybe a recommend).

Regards



Bug#962214: Needles dependencies to policykit

2021-04-24 Thread julien forest
Is there any hope to remove this dependency to policykit-1 which
prevents users who do not want to use systemd to install the current
version of gparted ? 

Best regards, 

Julien



Bug#986440: Please consider Recommends: gstreamer1.0-libav on libfaudio0

2021-04-05 Thread Forest
Package: faudio
Version: 21.02-1

Dear maintainer,

The WMA codec is critical to many games that rely on FAudio, which (in
recent versions) depends on GStreamer to handle that codec.
https://github.com/FNA-XNA/FAudio/commit/7f52bfb66b73cca2522537f45977886958a06324

Unfortunately, the GStreamer plugin that provides that codec is not
installed by default, which leaves gamers with broken sound and no obvious
path to fix it.  Also, folks who upgrade from an older libfaudio0 package
may find their formerly-working games suddenly without sound.

Adding Recommends: gstreamer1.0-libav to the libfaudio0 package would be
helpful here.  Would you please consider it?



Bug#983818: linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module

2021-03-01 Thread Forest
attached PHY driver 
[RTL8211F Gigabit Ethernet] (mii_bus:phy_addr=stmmac-0:00, irq=POLL)
[  161.848648] RTL8211F Gigabit Ethernet stmmac-0:01: attached PHY driver 
[RTL8211F Gigabit Ethernet] (mii_bus:phy_addr=stmmac-0:01, irq=POLL)
[  162.048288] rk_gmac-dwmac fe30.ethernet eth0: PHY [stmmac-0:00] driver 
[RTL8211F Gigabit Ethernet] (irq=POLL)
[  162.068869] rk_gmac-dwmac fe30.ethernet eth0: No Safety Features support 
found
[  162.077369] rk_gmac-dwmac fe30.ethernet eth0: PTP not supported by HW
[  162.085535] rk_gmac-dwmac fe30.ethernet eth0: configuring for phy/rgmii 
link mode
[  165.153892] rk_gmac-dwmac fe30.ethernet eth0: Link is Up - 1Gbps/Full - 
flow control rx/tx
[  165.163627] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

** Model information
Device Tree model: Pine64 RockPro64 v2.0

** Loaded modules:
dwmac_rk
overlay
snd_soc_hdmi_codec
dw_hdmi_i2s_audio
hci_uart
btqca
btrtl
btbcm
btintel
rockchipdrm
sg
dw_mipi_dsi
ofpart
snd_soc_rockchip_i2s
snd_soc_rockchip_pcm
snd_soc_simple_card
snd_soc_simple_card_utils
bluetooth
dw_hdmi
cec
snd_soc_core
spi_nor
governor_simpleondemand
analogix_dp
mtd
evdev
jitterentropy_rng
io_domain
snd_pcm_dmaengine
panfrost
pwm_rockchip
snd_pcm
dw_wdt
leds_gpio
drbg
snd_timer
gpu_sched
drm_kms_helper
ansi_cprng
pwm_fan
snd
ecdh_generic
rfkill
soundcore
rockchip_thermal
ecc
drm
nvmem_rockchip_efuse
pl330
cpufreq_dt
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
algif_skcipher
af_alg
sd_mod
t10_pi
crc_t10dif
xhci_plat_hcd
crct10dif_generic
xhci_hcd
realtek
dm_crypt
dm_mod
ahci
libahci
libata
scsi_mod
rtc_rk808
clk_rk808
rk808_regulator
dwc3
udc_core
roles
aes_ce_blk
crypto_simd
ulpi
cryptd
aes_ce_cipher
fan53555
rk808
crct10dif_ce
crct10dif_common
ghash_ce
stmmac_platform
gf128mul
libaes
stmmac
sha2_ce
pcs_xpcs
sha256_arm64
phylink
sha1_ce
pwm_regulator
of_mdio
dwc3_of_simple
fixed
fixed_phy
ohci_platform
libphy
ohci_hcd
gpio_keys
ehci_platform
ehci_hcd
ptp
sdhci_of_arasan
usbcore
sdhci_pltfm
phy_rockchip_emmc
cqhci
phy_rockchip_pcie
phy_rockchip_typec
phy_rockchip_inno_usb2
sdhci
pps_core
dw_mmc_rockchip
dw_mmc_pltfm
spi_rockchip
i2c_rk3x
usb_common
dw_mmc

** Network interface configuration:
*** /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
# "auto eth0" added to make systemd network-online.target work -forest
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
3: eth0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether c2:cd:eb:ff:70:bf brd ff:ff:ff:ff:ff:ff
inet 10.1.1.112/24 brd 10.1.1.255 scope global dynamic eth0
   valid_lft 85817sec preferred_lft 85817sec
inet6 fe80::c0cd:ebff:feff:70bf/64 scope link 
   valid_lft forever preferred_lft forever

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo: 240   4000 0  0 0  240  
 4000 0   0  0
  eth0:   96620 582000 0  0 073579 
558000 0   0  0


** PCI devices:
00:00.0 PCI bridge [0604]: Fuzhou Rockchip Electronics Co., Ltd RK3399 PCI 
Express Root Port [1d87:0100] (prog-if 00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

01:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 
x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11) (prog-if 01 [AHCI 1.0])
Subsystem: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port 
SATA 6 Gb/s Controller [1b4b:9235]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ahci
Kernel modules: ahci


** USB devices:
Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0003 L

Bug#970573: apt: seems to ignore pin priority when satisfying an install dependency

2020-09-18 Thread Forest
Package: apt
Version: 1.8.2.1
Severity: normal

Dear Maintainer,

When I apt install --simulate docker.io/unstable, apt picks needrestart 3.5-1
to meet a dependency, even though it has a lower pin priority than 3.4-5 and
no package (not even docker/unstable) requires a version newer than 3.1~ .

This surprises me. Is it a bug?

$ apt install --simulate -o debug::pkgProblemResolver=1 docker.io/unstable
NOTE: This is only a simulation!
  apt needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Selected version '19.03.12+dfsg1-4' (Debian:unstable [arm64]) for 'docker.io'
Selected version '2.4.3-1+b1' (Debian:unstable [arm64]) for 'libseccomp2' 
because of 'docker.io'
Selected version '1.0.0~rc92+dfsg1-5' (Debian:unstable [arm64]) for 'runc' 
because of 'docker.io'
Selected version '3.5-1' (Debian:unstable [all]) for 'needrestart' because of 
'docker.io'
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following additional packages will be installed:
  cgroupfs-mount libintl-perl libintl-xs-perl libltdl7 libmodule-find-perl
  libmodule-scandeps-perl libproc-processtable-perl libseccomp2
  libsort-naturally-perl libterm-readkey-perl needrestart runc tini
Suggested packages:
  docker-doc aufs-tools btrfs-progs debootstrap rinse xfsprogs zfs-fuse
  | zfsutils needrestart-session | libnotify-bin iucode-tool
Recommended packages:
  criu
The following NEW packages will be installed:
  cgroupfs-mount docker.io libintl-perl libintl-xs-perl libltdl7
  libmodule-find-perl libmodule-scandeps-perl libproc-processtable-perl
  libsort-naturally-perl libterm-readkey-perl needrestart runc tini
The following packages will be upgraded:
  libseccomp2
1 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
Inst libltdl7 (2.4.6-9 Debian:10.5/stable [arm64])
Inst libseccomp2 [2.3.3-4] (2.4.3-1+b1 Debian:unstable [arm64])
Conf libseccomp2 (2.4.3-1+b1 Debian:unstable [arm64])
Inst runc (1.0.0~rc92+dfsg1-5 Debian:unstable [arm64])
Inst tini (0.18.0-1 Debian:10.5/stable [arm64])
Inst docker.io (19.03.12+dfsg1-4 Debian:unstable [arm64])
Inst cgroupfs-mount (1.4 Debian:10.5/stable, Debian:unstable [all])
Inst libintl-perl (1.26-2 Debian:10.5/stable, Debian:unstable [all])
Inst libintl-xs-perl (1.26-2+b4 Debian:10.5/stable [arm64])
Inst libmodule-find-perl (0.13-1 Debian:10.5/stable [all])
Inst libmodule-scandeps-perl (1.27-1 Debian:10.5/stable [all])
Inst libproc-processtable-perl (0.56-1 Debian:10.5/stable [arm64])
Inst libsort-naturally-perl (1.03-2 Debian:10.5/stable, Debian:unstable [all])
Inst libterm-readkey-perl (2.38-1 Debian:10.5/stable [arm64])
Inst needrestart (3.5-1 Debian:unstable [all])
Conf libltdl7 (2.4.6-9 Debian:10.5/stable [arm64])
Conf runc (1.0.0~rc92+dfsg1-5 Debian:unstable [arm64])
Conf tini (0.18.0-1 Debian:10.5/stable [arm64])
Conf docker.io (19.03.12+dfsg1-4 Debian:unstable [arm64])
Conf cgroupfs-mount (1.4 Debian:10.5/stable, Debian:unstable [all])
Conf libintl-perl (1.26-2 Debian:10.5/stable, Debian:unstable [all])
Conf libintl-xs-perl (1.26-2+b4 Debian:10.5/stable [arm64])
Conf libmodule-find-perl (0.13-1 Debian:10.5/stable [all])
Conf libmodule-scandeps-perl (1.27-1 Debian:10.5/stable [all])
Conf libproc-processtable-perl (0.56-1 Debian:10.5/stable [arm64])
Conf libsort-naturally-perl (1.03-2 Debian:10.5/stable, Debian:unstable [all])
Conf libterm-readkey-perl (2.38-1 Debian:10.5/stable [arm64])
Conf needrestart (3.5-1 Debian:unstable [all])


apt says it picked needrestart 3.5-1 because of 'docker.io'.  But why did it
pick the version with a lower pin priority?  The docker.io package should be
happy with the older, stable, higher-priority version:


$ apt depends docker.io/unstable |grep needrestart
  Recommends: needrestart (>= 3.1~)


Does apt actually see my pin priorities?  Yep:


$ apt policy needrestart
needrestart:
  Installed: (none)
  Candidate: 3.4-5
  Version table:
 3.5-1 100
100 http://deb.debian.org/debian unstable/main arm64 Packages
 3.4-5 500
500 http://deb.debian.org/debian buster/main arm64 Packages


Are my pin priorities correct?  I think so:


$ cat /etc/apt/preferences.d/*pref
Package: linux-image-* linux-headers-*
Pin: release a=unstable
Pin-Priority: 500

Package: *
Pin: release a=unstable
Pin-Priority: 100


Perhaps some other package requires a newer version of needrestart?  Nope:


$ apt rdepends needrestart
needrestart
Reverse Depends:
  Recommends: docker.io (>= 3.1~)
  Suggests: unattended-upgrades
  Depends: freedombox
  Depends: needrestart-session (>= 2.0)
  Recommends: docker.io (>= 3.1~)
  Depends: parl-desktop
  Depends: design-desktop
  Suggests: aptitude-robot
  Recommends: apt-dater-host
  Suggests: unattended-upgrades
  Depends: needrestart-session (>= 2.0)
  

Bug#969015: radicale: ignores umask

2020-08-31 Thread Forest
>When using uwsgi, umask can be applied there.

Does that help anything? The init.d script also applies an appropriate
umask. The problem is that Radicale overrides it.

>I don't fell comfortable applying a backport when upstream don't want to 
>carry it either, and unfortunately it seems I am pretty much alone in 
>maintaining radicale for Debian nowadays :-(

Understood. I guess I'll patch locally and look forward to Bullseye. Thanks
for maintaining the package!



Bug#968519: dropbear-initramfs: race condition prevents launch at boot

2020-08-31 Thread Forest
Thanks, Guilhem.

Is anything more needed from me to get this fixed?



Bug#969015: radicale: ignores umask

2020-08-31 Thread Forest
Upstream have acknowledged the bug and stated that they no longer want to
update Radicale 2.x. The bug is fixed in 3.x. Any chance Debian will move to
the new version soon?

https://github.com/Kozea/Radicale/pull/1096#issuecomment-683684617



Bug#969015: Acknowledgement (radicale: ignores umask)

2020-08-25 Thread Forest
Patch also submitted to upstream:
https://github.com/Kozea/Radicale/pull/1096



Bug#969015: radicale: ignores umask

2020-08-25 Thread Forest
Package: radicale
Version: 2.1.11-6
Severity: normal

Dear Maintainer,

Radicale 2.x ignores its umask when creating .ics and .vcf files.

This interferes with backups, git diffs (when using the git hook), and
anything else that depends on group read permission to access those files.

The problem has been acknowledged and fixed in the 3.x development tree:
https://github.com/Kozea/Radicale/commit/630d49b

However, the fix has not been applied to the 2.x branch.
I am attaching a backport.

-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.7.0-2-arm64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages radicale depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  lsb-base 10.2019051400
ii  python3  3.7.3-1
ii  python3-radicale 2.1.11-6

Versions of packages radicale recommends:
ii  ssl-cert  1.0.39

Versions of packages radicale suggests:
pn  apache2 
ii  apache2-utils   2.4.38-3+deb10u3
pn  libapache2-mod-proxy-uwsgi  
ii  python3-bcrypt  3.1.6-1
ii  python3-passlib 1.7.1-1
pn  uwsgi   
pn  uwsgi-plugin-python3

-- Configuration Files:
/etc/radicale/config changed [not included]
/etc/radicale/logging changed [not included]

-- no debconf information
--- a/radicale/storage.py
+++ b/radicale/storage.py
@@ -792,26 +792,18 @@
 
 @contextmanager
 def _atomic_write(self, path, mode="w", newline=None, sync_directory=True):
-directory = os.path.dirname(path)
-tmp = NamedTemporaryFile(
-mode=mode, dir=directory, delete=False, prefix=".Radicale.tmp-",
-newline=newline, encoding=None if "b" in mode else self._encoding)
-try:
-yield tmp
-tmp.flush()
-try:
+parent_dir, name = os.path.split(path)
+# Do not use mkstemp because it creates with permissions 0o600
+with TemporaryDirectory(
+prefix=".Radicale.tmp-", dir=parent_dir) as tmp_dir:
+with open(os.path.join(tmp_dir, name), mode, newline=newline,
+  encoding=None if "b" in mode else self._encoding) as tmp:
+yield tmp
+tmp.flush()
 self._fsync(tmp.fileno())
-except OSError as e:
-raise RuntimeError("Fsync'ing file %r failed: %s" %
-   (path, e)) from e
-tmp.close()
-os.replace(tmp.name, path)
-except BaseException:
-tmp.close()
-os.remove(tmp.name)
-raise
+os.replace(os.path.join(tmp_dir, name), path)
 if sync_directory:
-self._sync_directory(directory)
+self._sync_directory(parent_dir)
 
 @staticmethod
 def _find_available_file_name(exists_fn, suffix=""):


Bug#968519: dropbear-initramfs: race condition prevents launch at boot

2020-08-19 Thread Forest
On Sun, 16 Aug 2020 23:10:34 +0200, Guilhem Moulin wrote:

>Please also try the attached patch (with and without delay).  If this
>alone doesn't help BUT the addition of some delay *before* running
>configure_networking() fixes the race condition, then this bug should
>probably reassigned to initramfs-tools.

As you suspected, that patch alone does not fix it, but adding a delay at
the point you marked does.  (At least, it worked 8 times in a row.)



Bug#968519: dropbear-initramfs: race condition prevents launch at boot

2020-08-16 Thread Forest
On Sun, 16 Aug 2020 23:10:34 +0200, Guilhem Moulin wrote:

>configure_networking() is run in the backround, yup (and the dropbear
>server is started afterwards if successful) see #806884.  But that's done
>at init-premount stage, after udev and the required modules are loaded.
>Is your network interface brought up by a script in init-premount or
>local-top?

It doesn't appear so.

Both of these dirs are empty:
/etc/initramfs-tools/scripts/{init-premount,local-top}

/usr/share/initramfs-tools/scripts/init-premount contains only the
"dropbear" script from dropbear-initramfs.

/usr/share/initramfs-tools/scripts/local-top contains only "cryptopensc" and
"cryptroot", neither of which look like they bring up a network interface.

>Please also try the attached patch (with and without delay).

Was there supposed to be an attachment? The only one I received is your pgp
signature. I don't see a patch in the bugs.debian.org copy of this thread,
either.



Bug#968519: dropbear-initramfs: race condition prevents launch at boot

2020-08-16 Thread Forest
Package: dropbear-initramfs
Version: 2020.80-1
Severity: important

Dear Maintainer,

About four times out of five, dropbear fails to launch at boot on the
RockPro64 single-board computer. When it fails, I see this message
repeated several times, scattered between various other messages on the
serial console:

  ipconfig: no devices to configure

Finally, this message appears:

  /scripts/init-premount/dropbear: .: line 279:
  can't open '/run/net-*.conf': No such file or directory

The system then proceeds to the luks unlock prompt at the serial console
only, with dropbear not running, so the boot process will not continue
unless I connect a serial console and enter the password that way.

I have tried adding all my ethernet-related driver modules to
/etc/initramfs-tools/modules and rebuilding initramfs, but it
didn't help. I have tried using ip= kernel command line arguments
for a static address instead of DHCP, but that didn't help either.

However, editing /usr/share/initramfs-tools/scripts/init-premount/dropbear
does get it working. Making that script wait for a /run/net-*.conf file to
appear before it calls configure_networking appears to be a solution.
Even just sleeping for a few seconds before the configure_networking call
seems to work, though I don't know how consistently.

Based on this workaround and the fact that the aforementioned error messages
are interleaved with other boot messages, it looks to me like dropbear's
init-premount script is being run in parallel with driver and network setup,
and often executing before the rk3399's onboard ethernet has a chance to
finish initializing.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.7.0-2-arm64 (SMP w/6 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dropbear-initramfs depends on:
ii  busybox  1:1.30.1-5
ii  dropbear-bin 2020.80-1
ii  initramfs-tools  0.137
ii  udev 246-2

Versions of packages dropbear-initramfs recommends:
ii  cryptsetup-initramfs  2:2.3.3-1

dropbear-initramfs suggests no packages.

-- Configuration Files:
/etc/dropbear-initramfs/config changed:
DROPBEAR_OPTIONS="-p 222"


-- no debconf information



Bug#967963: installation failure: rockpro64

2020-08-07 Thread Forest
On Fri, 7 Aug 2020 09:27:14 +0300, Alper Nebi Yasak wrote:
>It's updated now, so the current daily builds should work.

Thank you!

>Can you check /sys/firmware/devicetree/base/chosen/stdout-path 

It contains "serial2:150n8" which I suppose is the expected value
(though maybe not the best choice for this board since the boot firmware
uses 115200).

I tried your suggestion of refreshing screen after boot finished, to clear
the 1.5mbps garbage, but it didn't help.  If the cause is not something in
the installer image, I wonder if it might lie in my serial adapter; it is
supposed to support that speed, but I don't think I've ever tried it before.

Anyway, the main problem I reported is fixed with the new daily builds.
Thanks again!



Bug#967963: installation failure: rockpro64

2020-08-05 Thread Forest
Package: installation-reports

Boot method: SD card
Image version: 
https://d-i.debian.org/daily-images/arm64/20200727-02:25/netboot/SD-card-images/firmware.rockpro64-rk3399.img.gz
Date: 2020-08-05

Machine: RockPro64
Processor: Rockchip rk3399
Memory: 4GB
Partitions: /dev/mmcblk1p1

Output of lspci -knn (or lspci -nn):

00:00.0 PCI bridge [0604]: Fuzhou Rockchip Electronics Co., Ltd RK3399 PCI 
Express Root Port [1d87:0100]
Kernel driver in use: pcieport
01:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 
x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11)
Subsystem: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port 
SATA 6 Gb/s Control

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [E]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[E]

Comments/Problems:

I used the installer image from over a week ago, because d-i.debian.org has
no newer daily images.

Booting with my serial adapter set for 150 bps showed nothing but garbage.
Using 115200 bps instead showed several bootloader messages clearly, and then
nothing but garbage. Editing extlinux.conf to append console=ttyS2,115200n8
to the kernel command line and then setting my serial port to that speed made
kernel boot messages visible and allowed me operate the debian installer.

The installer stopped at the "Download installer components" step,
displaying this message:

"""
No kernel modules were found. This probably is due to a mismatch
between the kernel used by this version of the installer and the
kernel version available in the archive.

You should make sure that your installation image is up-to-date, or -
if that's the case - try a different mirror, preferably
deb.debian.org.
"""

Last lines in the "log" virtual screen:

"""
Jan  1 00:07:07 net-retriever: gpgv: key DC30D7C23CBBABEE was created 18000 
days in the future (time warp or clock problem)
Jan  1 00:07:07 net-retriever: gpgv: key 648ACFD622F3D138 was created 18000 
days in the future (time warp or clock problem)
Jan  1 00:07:07 net-retriever: gpgv: Good signature from "Debian Archive 
Automatic Signing Key (10/buster) "
Jan  1 00:07:07 anna[1474]: 1970-01-01 00:07:07 
URL:http://deb.debian.org/debian//dists/unstable/main/debian-installer/binary-arm64/Packages.xz
 [51000/51000] -> "/tmp/_fetch-url_net-retriever-1476-Packages.1509" [1]
Jan  1 00:07:08 anna[1474]: 1970-01-01 00:07:08 
URL:http://deb.debian.org/debian//dists/unstable/contrib/debian-installer/binary-arm64/Packages.xz
 [32/32] -> "/tmp/_fetch-url_net-retriever-1476-Packages.1530" [1]
Jan  1 00:07:09 anna[1474]: 1970-01-01 00:07:09 
URL:http://deb.debian.org/debian//dists/unstable/non-free/debian-installer/binary-arm64/Packages.xz
 [32/32] -> "/tmp/_fetch-url_net-retriever-1476-Packages.1551" [1]
Jan  1 00:07:09 anna[1474]: WARNING **: no packages matching running kernel 
5.7.0-1-arm64 in archive
"""



Bug#933870: qbittorrent: Qbittorrent 4.1.6 Debian Testing updated 8/4/19 Fails upon start and immediately exits

2019-08-04 Thread Forest Johnson
Package: qbittorrent
Version: 4.1.6-1
Severity: important

Dear Maintainer,


I am using qbittorrent 4.1.6 on Debian Testing, just updated apt fully today
August 4th 2019 @10:05 am Central Time.

Upon Start of Qbittorrent, the application immediately crashes, multiple
attempts lead to the same results.  I get the following errors in commandline
attempting to start it.  I am new to this, and will provide whatever
information I can to assist.

qbittorrent


*
Please file a bug report at http://bug.qbittorrent.org and provide the
following information:

qBittorrent version: v4.1.6

Caught signal: SIGSEGV
Stack trace:
  /lib/x86_64-linux-gnu/libQt5Network.so.5 : ()+0x95b84  [0x7f0b0ce17b84]
  /lib/x86_64-linux-gnu/libQt5Network.so.5 : ()+0x94c49  [0x7f0b0ce16c49]
  /lib/x86_64-linux-gnu/libQt5Core.so.5 : QObject::event(QEvent*)+0xe2
[0x7f0b0cadcd12]
  /lib/x86_64-linux-gnu/libQt5Widgets.so.5 :
QApplicationPrivate::notify_helper(QObject*, QEvent*)+0x81  [0x7f0b0d6a6501]
  /lib/x86_64-linux-gnu/libQt5Widgets.so.5 : QApplication::notify(QObject*,
QEvent*)+0x210  [0x7f0b0d6ad9b0]
  qbittorrent : Application::notify(QObject*, QEvent*)+0x22  [0x5609c12207d2]
  /lib/x86_64-linux-gnu/libQt5Core.so.5 :
QCoreApplication::notifyInternal2(QObject*, QEvent*)+0x179  [0x7f0b0cab3079]
  /lib/x86_64-linux-gnu/libQt5Core.so.5 :
QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)+0x1cb
[0x7f0b0cab605b]
  /lib/x86_64-linux-gnu/libQt5Core.so.5 : ()+0x2bbd53  [0x7f0b0cb04d53]
  /lib/x86_64-linux-gnu/libglib-2.0.so.0 : g_main_context_dispatch()+0x2ae
[0x7f0b0b47c9ee]
  /lib/x86_64-linux-gnu/libglib-2.0.so.0 : ()+0x4ec88  [0x7f0b0b47cc88]
  /lib/x86_64-linux-gnu/libglib-2.0.so.0 : g_main_context_iteration()+0x2c
[0x7f0b0b47cd1c]
  /lib/x86_64-linux-gnu/libQt5Core.so.5 :
QEventDispatcherGlib::processEvents(QFlags)+0x67
[0x7f0b0cb04377]
  /lib/x86_64-linux-gnu/libQt5Core.so.5 :
QEventLoop::exec(QFlags)+0x13b  [0x7f0b0cab1d4b]
  /lib/x86_64-linux-gnu/libQt5Core.so.5 : QThread::exec()+0xb6
[0x7f0b0c901e36]
  /lib/x86_64-linux-gnu/libQt5Core.so.5 : ()+0xc2a27  [0x7f0b0c90ba27]
  /lib/x86_64-linux-gnu/libpthread.so.0 : ()+0x7fa3  [0x7f0b0c82ffa3]
  /lib/x86_64-linux-gnu/libc.so.6 : clone()+0x3f  [0x7f0b0c3e94cf]
Segmentation fault

Thank you for you assistance.

Forest Johnson



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages qbittorrent depends on:
ii  geoip-database 20190724-1
ii  libboost-system1.67.0  1.67.0-13
ii  libc6  2.28-10
ii  libgcc11:9.1.0-10
ii  libqt5core5a   5.11.3+dfsg1-2
ii  libqt5dbus55.11.3+dfsg1-2
ii  libqt5gui5 5.11.3+dfsg1-2
ii  libqt5network5 5.11.3+dfsg1-2
ii  libqt5widgets5 5.11.3+dfsg1-2
ii  libqt5xml5 5.11.3+dfsg1-2
ii  libstdc++6 9.1.0-10
ii  libtorrent-rasterbar9  1.1.13-1
ii  python 2.7.16-1
ii  zlib1g 1:1.2.11.dfsg-1

qbittorrent recommends no packages.

Versions of packages qbittorrent suggests:
pn  qbittorrent-dbg  

-- no debconf information



Bug#929046: RFP: libnvidia-container-tools -- Utility for exposing nVidia hardware to linux containers

2019-05-15 Thread Forest
Package: wnpp
Severity: wishlist

  Package name: libnvidia-container-tools
  Version : 1.0.2
  URL : https://github.com/NVIDIA/libnvidia-container
  License : BSD
  Programming Lang: C
  Description : Utility for exposing nVidia hardware to linux containers

A library and simple command line utility to automatically configure linux
containers for access to nVidia hardware. This enables GPU graphics, compute,
and video features with minimal configuration and without having to install the
nVidia driver in each container. It is designed to be agnostic of the container
runtime.


I have been running games within lxc containers for years, but getting my
nVidia GPU to work with them was a painful process that consumed a lot of time,
required more systems knowledge than should be necessary, occasionally broke
when nVidia restructured their drivers, and practically required installing
(and regularly updating) a copy of the driver package within each container.
People using containers for video encoding, AI, and other graphics-related
applications would likely face the same issues. For most people, navigating it
all is out of reach. With this tool and library, all that nonsense can be
replaced with just a little container configuration. Here's an example for lxc:

lxc.environment = NVIDIA_VISIBLE_DEVICES=all
lxc.environment = NVIDIA_DRIVER_CAPABILITIES=all
lxc.hook.mount = /usr/share/lxc/hooks/nvidia

That's far more accessible and maintainable. More info here:

https://devblogs.nvidia.com/gpu-containers-runtime/



Bug#916755: This appears fixed upstream

2019-01-18 Thread Joshua C. Forest
https://sourceforge.net/p/libcg/libcg/ci/16f2fc1794b4022a937454dfa4463339e36b2520/

It would be awesome if this could get merged in, to fix these issues.
--
Joshua C. Forest
email: jos...@joshuacforest.com
phone: 207-358-0004


Bug#904959: greybird-gtk-theme: png files are symlinked to svg files

2018-07-29 Thread Forest
Package: greybird-gtk-theme
Version: 3.22.8-1
Severity: minor

Dear Maintainer,

Wile trying to figure out why selecting greybird-wall-1920x1200.png was locking
up my background image picker for several seconds, I discovered that the file
is not actually a 1920x1200 image, nor even a png image at all, but a symlink
to an svg file. A similar problem occurs when I switch users via my X display
manager (lightdm) if one of the users has that image selected as his desktop
background.

This isn't the end of the world, of course, but since it is both misleading and
the cause of unresponsive UI, it would be nice if it was replaced with a proper
png.



-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-29-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages greybird-gtk-theme depends on:
ii  gtk2-engines-murrine  0.98.2-2ubuntu1

greybird-gtk-theme recommends no packages.

greybird-gtk-theme suggests no packages.

-- no debconf information



Bug#904789: xfce4-terminal: fails to update utmp; breaks write and who

2018-07-27 Thread Forest
Package: xfce4-terminal
Version: 0.8.7.3-0ubuntu1
Severity: normal

Dear Maintainer,

Would you please add --with-utempter to the package configure rules, and
include libutemper in the dependencies?

Background:

When libvte dropped utmp support, it left xfce4-terminal sessions invisible to
common utilities like "who", "write", along with every script and workflow that
depends on them.  This functionality was later restored via the above build
option, but that option is not enabled by default.  It would be nice to have
these things working again.

https://bugzilla.xfce.org/show_bug.cgi?id=13710



-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-29-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-terminal depends on:
ii  exo-utils   0.12.2-0ubuntu0.18.04.1
ii  libatk1.0-0 2.28.1-1
ii  libc6   2.27-3ubuntu1
ii  libcairo2   1.15.10-2
ii  libgdk-pixbuf2.0-0  2.36.11-2
ii  libglib2.0-02.56.1-2ubuntu1
ii  libgtk-3-0  3.22.30-1ubuntu1
ii  libpango-1.0-0  1.40.14-1
ii  libvte-2.91-0   0.52.2-1ubuntu1~18.04.1
ii  libx11-62:1.6.4-3
ii  libxfce4ui-2-0  4.13.4-1ubuntu1
ii  libxfce4util7   4.12.1-3

Versions of packages xfce4-terminal recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.2-1ubuntu1
ii  dbus-x11 [dbus-session-bus]   1.12.2-1ubuntu1

xfce4-terminal suggests no packages.

-- no debconf information



Bug#882142: fixed in pulseaudio 11.1-3

2017-12-13 Thread julien forest
I can not understand how such a patch can solve the problem ! 

The add of libpam-systemd as a recommendation does not solve anything
for anyone not installing recommendations.

Furthermore, for those who do not want (can not) use systemd (or
at least libpam-systemd),this not solve anything.

Maybe the solution is to create a dependency to one of two subpackages
(libpulse0-libpam and libpulse0-nolibpam for example). The first one
should add the file /etc/pulse/client.conf.d/00-disable-autospawn.conf
as now while the second-one should add the following version of the
same file: 
"# On linux systems, disable autospawn by default
# If you are not using systemd, comment out this line
autospawn=yes
". 

Then libpulse0-libpam should depend on libpam-systemd while
libpul$se0-nolibpam conflicts with it. 

Best regards, 

Julien


On Sat, 25 Nov 2017 15:11:18 + Felipe Sateler 
wrote:
> Source: pulseaudio
> Source-Version: 11.1-3
> 
> We believe that the bug you reported is fixed in the latest version of
> pulseaudio, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 882...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
> 
> Debian distribution maintenance software
> pp.
> Felipe Sateler  (supplier of updated pulseaudio
> package)
> 
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Sat, 25 Nov 2017 10:35:47 -0300
> Source: pulseaudio
> Binary: pulseaudio pulseaudio-utils pulseaudio-esound-compat
> pulseaudio-module-zeroconf pulseaudio-module-jack
> pulseaudio-module-lirc pulseaudio-module-gconf pulseaudio-module-raop
> pulseaudio-module-bluetooth pulseaudio-equalizer libpulse0
> libpulse-mainloop-glib0 libpulse-dev libpulsedsp Architecture: source
> Version: 11.1-3 Distribution: unstable Urgency: medium Maintainer:
> Pulseaudio maintenance team
>  Changed-By: Felipe
> Sateler  Description: libpulse-dev - PulseAudio
> client development headers and libraries libpulse-mainloop-glib0 -
> PulseAudio client libraries (glib support) libpulse0  - PulseAudio
> client libraries libpulsedsp - PulseAudio OSS pre-load library
>  pulseaudio - PulseAudio sound server
>  pulseaudio-equalizer - Equalizer sink module for PulseAudio sound
> server pulseaudio-esound-compat - PulseAudio ESD compatibility layer
>  pulseaudio-module-bluetooth - Bluetooth module for PulseAudio sound
> server pulseaudio-module-gconf - GConf module for PulseAudio sound
> server pulseaudio-module-jack - jackd modules for PulseAudio sound
> server pulseaudio-module-lirc - lirc module for PulseAudio sound
> server pulseaudio-module-raop - RAOP module for PulseAudio sound
> server pulseaudio-module-zeroconf - Zeroconf module for PulseAudio
> sound server pulseaudio-utils - Command line tools for the PulseAudio
> sound server Closes: 882142
> Changes:
>  pulseaudio (11.1-3) unstable; urgency=medium
>  .
>* Use dh_missing instead of dh_install --fail-missing
>* We don't need root to build, so tell dpkg about that with
>  Rules-Require-Root: no
>* Add Recommends: libpam-systemd because otherwise user instances
> are not started (Closes: #882142)
>* Bump Standards-Version (no changes needed)



Bug#854327: pulseaudio: default configuration depends on consolekit

2017-07-11 Thread julien forest
Maybe one should just change the default.pa as follows (not a real
diff but the + lines are just to add): 

.ifexists module-console-kit.so
+.nofail
load-module module-console-kit
+.fail
.endif


It suffices for me to make pulseaudio works without consolekit nor
systemd installed. 

Best regards, 

Julien



Bug#856283: python-inotifyx: add python3 support

2017-03-02 Thread Forest Bond
On Thu, Mar 02, 2017 at 07:47:03PM +0530, Ritesh Raj Sarraf wrote:
> Sending again: I completely missed to add Forest. :-)
> 
> On Mon, 2017-02-27 at 13:09 +, Brian Russell wrote:
> > Package: python-inotifyx
> > Severity: important
> > Tags: patch
> > 
> > Dear Maintainer,
> > 
> > I've updated inotifyx to build a python3 package (tested with python3.5
> > on debian stretch).
> 
> Hello Brian,
> 
> Thank you for the patches. The Debian version is lagging by a release. The
> current upstream release is 0.2.2. But looking at the changes, I'm hoping it
> hasn't much diverged from what you have the patch against. I am including the
> upstream author to get it reviewed/included.
> 
> Unfortunately, I don't think this will make into Debian Stretch as it is 
> frozen
> now and the freeze policy does not allow new packages to enter into the 
> archive.
> 
> 
> 
> Dear Forest,
> 
> Hope you are doing good. Could you please review patches on this bug report ?

Hey yes, I'm well!  I'm afraid I haven't done a very good job keeping up with
inotifyx maintenance.  I will see if I can get these reviewed/applied by this
weekend at the latest.

Thanks,
Forest
-- 
Forest Bond
http://www.forestbond.com/
http://www.rapidrollout.com/



Bug#734100: Fixed in VLC 3.0

2016-11-05 Thread Forest
Remi Denis-Courmont wrote:

>VLC upstream has not approved any patchset on top of VLC 2.2, 

Yes, I know.  Their failure to address this bug is responsible for vlc being
badly broken for a long time now.  I would think this an appropriate reason
to apply a downstream patch.

>the upstream solution is very far from trivial to backport.

Yes, I know.  I saw it.

>At least, all the patches for VLC 2.2 that I´ve seen proposed are all known 
>broken. That is to say that they do fix the symptoms, but they introduce even 
>worse problems that _will_ break VLC for other people.

I appreciate what you're saying, but have you examined my patchset?  It's
not quite the same as any other that I've seen, and I have yet to receive
any criticism of it at all.  If it will cause breakage, I'd like to know
specifically how, so I can either fix it or abandon the effort.  I'd hate to
think it was being prematurely dismissed.



Bug#734100: Fixed in VLC 3.0

2016-11-05 Thread Forest
I applied my patches to the vlc 2.2.2-5 package in ubuntu 16.04 LTS, and
have been using the patched build for the past couple months with no
trouble.  Looks like success to me.

Comments on the upstream bug report are dismissive of vlc 2.x users.  It
would be a shame for us to be stuck with broken audio for the next few
years.

What must be done to have my patches added to debian's vlc package?



Bug#734100: Fixed in VLC 3.0

2016-09-13 Thread Forest
Modestas, in DecoderPlayAudio(), your modified decoder.c patch fails to
unlock the mutex when the loop exits on !p_audio.  On my system, this causes
vlc to become unresponsive when a video ends.

I looked in to 557eaa06 and 5b2de769 as suggested by Rémi, but since they
depend on many other commits and don't appear necessary in my own testing, I
abandoned the effort.

I'm attaching my current patches for review.  One is adapted from git commit
6ae2905e, while the other is copied verbatim from 47f74a83.  As far as I can
tell, they fix the stuttering bug in vlc 2.2.2 and 2.2.4, without causing
new problems.

X-Git-Url: 
https://git.videolan.org/?p=vlc.git;a=blobdiff_plain;f=src%2Finput%2Fdecoder.c;h=fe3cd428c65c18bfbdadb55baf11521afdc2bfc7;hp=83aa5bf54e2c29ad93fae803117558e4fcd0f658;hb=6ae2905ef7fbc7de3a3a4a1bdf8ad6df46ce570a;hpb=5b2de76965ee8b1ab5e3257f8b6d71bbb4e9e3f9

--- a/src/input/decoder.c
+++ b/src/input/decoder.c
@@ -1162,7 +1162,10 @@
 b_paused = p_owner->b_paused;
 
 if (!p_audio)
+{
+vlc_mutex_unlock( _owner->lock );
 break;
+}
 
 /* */
 int i_rate = INPUT_RATE_DEFAULT;
@@ -1180,6 +1183,9 @@
 
 if( unlikely(p_owner->b_paused != b_paused) )
 continue; /* race with input thread? retry... */
+
+vlc_mutex_unlock( _owner->lock );
+
 if( p_aout == NULL )
 b_reject = true;
 
@@ -1199,7 +1205,6 @@
 
 break;
 }
-vlc_mutex_unlock( _owner->lock );
 }
 
 static void DecoderDecodeAudio( decoder_t *p_dec, block_t *p_block )
@@ -1961,11 +1966,10 @@
 
 /* Parameters changed, restart the aout */
 vlc_mutex_lock( _owner->lock );
-
-aout_DecDelete( p_owner->p_aout );
 p_owner->p_aout = NULL;
-
 vlc_mutex_unlock( _owner->lock );
+aout_DecDelete( p_owner->p_aout );
+
 input_resource_PutAout( p_owner->p_resource, p_aout );
 }
 
X-Git-Url: 
https://git.videolan.org/?p=vlc.git;a=blobdiff_plain;f=modules%2Faudio_output%2Falsa.c;h=4e9fd53592d048baa8b57f30df15ab5806139d07;hp=2d1f99e9cb743bca12c6bdf32cc84a92d07fda8b;hb=47f74a83c161173b0d15e95dab8ceb7c97de51b4;hpb=6ae2905ef7fbc7de3a3a4a1bdf8ad6df46ce570a

diff --git a/modules/audio_output/alsa.c b/modules/audio_output/alsa.c
index 2d1f99e..4e9fd53 100644
--- a/modules/audio_output/alsa.c
+++ b/modules/audio_output/alsa.c
@@ -495,6 +495,15 @@ static int Start (audio_output_t *aout, 
audio_sample_format_t *restrict fmt)
 }
 sys->rate = fmt->i_rate;
 
+#if 1 /* work-around for period-long latency outputs (e.g. PulseAudio): */
+param = AOUT_MIN_PREPARE_TIME;
+val = snd_pcm_hw_params_set_period_time_near (pcm, hw, , NULL);
+if (val)
+{
+msg_Err (aout, "cannot set period: %s", snd_strerror (val));
+goto error;
+}
+#endif
 /* Set buffer size */
 param = AOUT_MAX_ADVANCE_TIME;
 val = snd_pcm_hw_params_set_buffer_time_near (pcm, hw, , NULL);
@@ -503,14 +512,22 @@ static int Start (audio_output_t *aout, 
audio_sample_format_t *restrict fmt)
 msg_Err (aout, "cannot set buffer duration: %s", snd_strerror (val));
 goto error;
 }
-
-param = AOUT_MIN_PREPARE_TIME;
+#if 0
+val = snd_pcm_hw_params_get_buffer_time (hw, , NULL);
+if (val)
+{
+msg_Warn (aout, "cannot get buffer time: %s", snd_strerror(val));
+param = AOUT_MIN_PREPARE_TIME;
+}
+else
+param /= 2;
 val = snd_pcm_hw_params_set_period_time_near (pcm, hw, , NULL);
 if (val)
 {
 msg_Err (aout, "cannot set period: %s", snd_strerror (val));
 goto error;
 }
+#endif
 
 /* Commit hardware parameters */
 val = snd_pcm_hw_params (pcm, hw);


Bug#734100: Fixed in VLC 3.0

2016-09-08 Thread Forest
On Mon, 02 Nov 2015 21:16:48 +0200, Rémi Denis-Courmont wrote:

>At least 557eaa06 and 5b2de769 are needed too. I can´t really check deeper in 
>my free time.

Do you mean they're needed to completely fix the bug, or just in order to
make the other two patches to apply cleanly?

I refreshed and applied 6ae2905e and 47f74a83 to vlc 2.2.2 (the current
ubuntu release), and in my initial tests, the bug hasn't resurfaced yet.

For anyone interested in testing my build or grabbing my refreshed patch:
https://launchpad.net/~foresto/+archive/ubuntu/ubuntutweaks/



Bug#828708: xserver-xorg: incorrect keycodes sent by X after upgrade

2016-06-26 Thread Dan Forest-Barbier
Package: xserver-xorg
Version: 1:7.7+15
Severity: important

Dear Maintainer,

I use Debian sid/unstable on an ASUS UX301LA laptop, my main environment is
SLIM + XFCE + AWESOME, and I use the French bépo (dvorak-like) alternative
mapping (pc105, fr, bepo).
After a recent dist-upgrade some non-character keys have been mixed (e.g.
pagedown is now mapped to menu, altgr is now mapped to return, ...).

Since the problem had not appeared until recently, I believe it was caused by a
dist-upgrade I ran on the 21st (the previous ones were on the 8th and 19th, and
contained no Xorg-related packages).
Here is are the X-related upgrades that took place (according to etckeeper):
-xserver-xorg-input-all 1:7.7+14 amd64
+xserver-xorg-input-all 1:7.7+15 amd64
+xserver-xorg-input-libinput 0.19.0-1 amd64
-xserver-xorg-video-nouveau 1:1.0.12-1+b1 amd64
+xserver-xorg-video-nouveau 1:1.0.12-2 amd64


I have tried using the mixed keys on both my display manager (slim) and a blank
user's startx (default XFCE session), and the problem was present.
The problem being present even outside of my personal session's settings
suggests it is not caused by my settings/environment.

I have tried using an external keyboard and using the mixed keys on it, and the
problem was present.
The problem being present even on an external keyboard suggests it is not input
device specific.


Here is the output from 'sudo evtest' on my laptop's keyboard, while inputting
LEFTMETA, ALTGR, and PAGEDOWN:

No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:  AT Translated Set 2 keyboard
/dev/input/event1:  Lid Switch
/dev/input/event2:  Sleep Button
/dev/input/event3:  Power Button
/dev/input/event4:  Video Bus
/dev/input/event5:  PFU Limited  HHKB Professional JP
/dev/input/event6:  ETPS/2 Elantech Touchpad
/dev/input/event7:  Asus Wireless Radio Control
/dev/input/event8:  PC Speaker
/dev/input/event9:  Atmel Atmel maXTouch Digitizer
/dev/input/event10: HDA Intel HDMI HDMI/DP,pcm=3
/dev/input/event11: HDA Intel HDMI HDMI/DP,pcm=7
/dev/input/event12: HDA Intel HDMI HDMI/DP,pcm=8
/dev/input/event13: HDA Intel PCH Headphone
/dev/input/event14: HD WebCam
Select the device event number [0-14]: 0
Input driver version is 1.0.1
Input device ID: bus 0x11 vendor 0x1 product 0x1 version 0xab41
Input device name: "AT Translated Set 2 keyboard"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
Event code 1 (KEY_ESC)
Event code 2 (KEY_1)
Event code 3 (KEY_2)
Event code 4 (KEY_3)
Event code 5 (KEY_4)
Event code 6 (KEY_5)
Event code 7 (KEY_6)
Event code 8 (KEY_7)
Event code 9 (KEY_8)
Event code 10 (KEY_9)
Event code 11 (KEY_0)
Event code 12 (KEY_MINUS)
Event code 13 (KEY_EQUAL)
Event code 14 (KEY_BACKSPACE)
Event code 15 (KEY_TAB)
Event code 16 (KEY_Q)
Event code 17 (KEY_W)
Event code 18 (KEY_E)
Event code 19 (KEY_R)
Event code 20 (KEY_T)
Event code 21 (KEY_Y)
Event code 22 (KEY_U)
Event code 23 (KEY_I)
Event code 24 (KEY_O)
Event code 25 (KEY_P)
Event code 26 (KEY_LEFTBRACE)
Event code 27 (KEY_RIGHTBRACE)
Event code 28 (KEY_ENTER)
Event code 29 (KEY_LEFTCTRL)
Event code 30 (KEY_A)
Event code 31 (KEY_S)
Event code 32 (KEY_D)
Event code 33 (KEY_F)
Event code 34 (KEY_G)
Event code 35 (KEY_H)
Event code 36 (KEY_J)
Event code 37 (KEY_K)
Event code 38 (KEY_L)
Event code 39 (KEY_SEMICOLON)
Event code 40 (KEY_APOSTROPHE)
Event code 41 (KEY_GRAVE)
Event code 42 (KEY_LEFTSHIFT)
Event code 43 (KEY_BACKSLASH)
Event code 44 (KEY_Z)
Event code 45 (KEY_X)
Event code 46 (KEY_C)
Event code 47 (KEY_V)
Event code 48 (KEY_B)
Event code 49 (KEY_N)
Event code 50 (KEY_M)
Event code 51 (KEY_COMMA)
Event code 52 (KEY_DOT)
Event code 53 (KEY_SLASH)
Event code 54 (KEY_RIGHTSHIFT)
Event code 55 (KEY_KPASTERISK)
Event code 56 (KEY_LEFTALT)
Event code 57 (KEY_SPACE)
Event code 58 (KEY_CAPSLOCK)
Event code 59 (KEY_F1)
Event code 60 (KEY_F2)
Event code 61 (KEY_F3)
Event code 62 (KEY_F4)
Event code 63 (KEY_F5)
Event code 64 (KEY_F6)
Event code 65 (KEY_F7)
Event code 66 (KEY_F8)
Event code 67 (KEY_F9)
Event code 68 (KEY_F10)
Event code 69 (KEY_NUMLOCK)
Event code 70 (KEY_SCROLLLOCK)
Event code 71 (KEY_KP7)
Event code 72 (KEY_KP8)
Event code 73 (KEY_KP9)
Event code 74 (KEY_KPMINUS)
Event code 75 (KEY_KP4)
Event code 76 (KEY_KP5)
Event code 77 (KEY_KP6)
Event code 78 (KEY_KPPLUS)
Event code 79 (KEY_KP1)
Event code 80 (KEY_KP2)
Event code 81 (KEY_KP3)
Event code 82 (KEY_KP0)
Event code 83 (KEY_KPDOT)
Event code 85 (KEY_ZENKAKUHANKAKU)
Event code 86 (KEY_102ND)
Event code 87 (KEY_F11)
Event code 88 (KEY_F12)
Event code 89 

Bug#794266: Subscription to 794...@bugs.debian.org successful

2015-11-24 Thread Forest
Problem also exists on my QNAP TS-119P+ running Debian 8.2 (jessie).

I would check my Wake on LAN and Energy-using Products settings if I knew
how.  /usr/sbin/qcontrol doesn't seem to have an option for reporting the
current settings.



Bug#769840: debhelper: fails to build a python3 package

2014-11-16 Thread Forest
Package: debhelper
Version: 9.20131227ubuntu1
Severity: normal

Dear Maintainer,

When packaging a python 3 program, debhelper causes all build targets
(including clean) to fail. The underlying cause seems to be that it insists
on running the python2-only pyversions program to process setup.py, despite
setup.py using python3 syntax, and despite all the obvious signs that it is
a python3 build. For example:

- setup.py starts with #!/usr/bin/env python3
- control contains Build-Depends: python3 (and not python or python2)
- control contains X-Python3-Version: (and not X-Python-Version)
- rules contains %: dh $@ --with python3

The failure occurs regardless of whether the dh command line includes
--with python3.

After quite a bit of groveling through documentation and mailing list archives,
I discovered that adding --buildsystem=pybuild to the dh command line works
around the problem. However, this is not documented in the Debian Python Policy
or apparently anyplace else where it really should appear. For example:

https://www.debian.org/doc/packaging-manuals/python-policy/
https://wiki.debian.org/Python/FAQ
https://wiki.debian.org/Python/
https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#customrules
the dh man page
the debhelper man page

This seems like a pretty big oversight. The Python Policy makes it very clear
that programs should use python 3, but the packaging tools fail when following
that policy:

https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html
Programs should use Python 3, and should not be packaged for Python 2 as well. 
Python 3 should be used for the packaging if the packaging scripts use Python.

If there is a good reason why the tools can't be made to follow the policy,
shouldn't the workaround be documented in an obvious place, at least?

Thanks for your attention.

-- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
'trusty'), (100, 'trusty-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.0-39-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages debhelper depends on:
ii  binutils 2.24-5ubuntu3
ii  dh-apparmor  2.8.95~2430-0ubuntu5
ii  dpkg 1.17.5ubuntu5.3
ii  dpkg-dev 1.17.5ubuntu5.3
ii  file 1:5.14-2ubuntu3.2
ii  man-db   2.6.7.1-1ubuntu1
ii  perl 5.18.2-2ubuntu1
ii  po-debconf   1.0.16+nmu2ubuntu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#717862: dma package leaves behind /etc/mailname after purge

2013-07-25 Thread Forest
Package: dma
Version: 0.9-1

The dma package creates an /etc/mailname file during install, but does not
register it as belonging to the package, and does not remove it when the
package is purged.  Nobody likes packages that leave behind junk like this,
and I'm pretty sure it violates Debian policy.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#578207: b43-fwcutter.config checks DEBCONF_FRONTEND, should check DEBIAN_FRONTEND

2010-04-17 Thread Forest Bond
Package: b43-fwcutter
Severity: minor

Originally reported at
https://bugs.launchpad.net/ubuntu/+source/b43-fwcutter/+bug/500162 .

DEBCONF_FRONTEND is not used. Was Googling it to confirm that no packages
actually use it. This package does:

  if [ $DEBCONF_FRONTEND != noninteractive ]  [ -x /usr/bin/wget ]; then

This hasn't caused any real problems for me personally, but it could
conceivably cause problems for someone.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org


signature.asc
Description: Digital signature


Bug#528598: python-support: fails to act on Python-Depends in the control file

2009-05-15 Thread Forest
On Thu, 14 May 2009 01:05:31 -0700, Forest wrote:

 Do you add ${python:Depends}?
 
 Yes.  ${python:Depends} is on my Depends: line.

I can’t really tell anything except that it works here. Do you have a
source package to share?

It's a proprietary package, so I can't share the whole thing, but I could
share the control file and the relevant part of the rules file.  Would that
help?

Now that I think of it, I could strip out all the proprietary stuff and
share a source package that demonstrates the problem.  Should I attach it to
a bug email?



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#528598: python-support: fails to act on Python-Depends in the control file

2009-05-14 Thread Forest
On Thu, 14 May 2009 08:12:02 +0200, Josselin Mouette wrote:

Le mercredi 13 mai 2009 à 19:07 -0700, Forest a écrit :
 According to /usr/share/doc/python-support/README.gz:
 
 
 If you're depending on another python module, you should not declare
 it in the Depends field, but like this:
 Python-Depends: python-bar (= some.version)
 The appropriate dependencies on python2.X-bar will automatically be
 added.
 

Note that the documentation in 1.0 explains when this (and
python:Provides) is necessary and when this is superfluous.

I'm looking at /usr/share/doc/python-support/README.gz from
python-support_1.0.3_all.deb.  The phrase Python-Depends appears exactly
once in that file, and it doesn't say anything about being superfluous.  Can
you quote the passage you're referring to?

 My debian/rules file includes dh_pysupport. My debian/control file's
 binary package section includes Python-Depends: python-psycopg2.
 However, python-psycopg2 does not get added to my binary package's
 control file.

Do you add ${python:Depends}?

Yes.  ${python:Depends} is on my Depends: line.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#528598: python-support: fails to act on Python-Depends in the control file

2009-05-14 Thread Forest
On Thu, 14 May 2009 09:49:53 +0200, Josselin Mouette wrote:

I think this passage is clear about Python-Depends being needed only if
you use ${python:Provides}, and ${python:Provides} being optional.

Hm... Reading it again, along with the paragraph above it, I can now see
that it only recommends using Python-Depends under certain circumstances.
However, it definitely does not say to avoid Python-Depends under other
circumstances, nor does it explain how Python-Depends is meant to work.  It
would be easy for a reader to assume (as I did based on the older
documentation) that Python-Depends should be used in general, and must be
used under specific circumstances.  I think it could use some clarification.

 Do you add ${python:Depends}?
 
 Yes.  ${python:Depends} is on my Depends: line.

I can’t really tell anything except that it works here. Do you have a
source package to share?

It's a proprietary package, so I can't share the whole thing, but I could
share the control file and the relevant part of the rules file.  Would that
help?



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#528598: python-support: fails to act on Python-Depends in the control file

2009-05-13 Thread Forest
Package: python-support
Version: 0.8.4
Severity: normal

According to /usr/share/doc/python-support/README.gz:


If you're depending on another python module, you should not declare
it in the Depends field, but like this:
Python-Depends: python-bar (= some.version)
The appropriate dependencies on python2.X-bar will automatically be
added.


My debian/rules file includes dh_pysupport. My debian/control file's binary 
package section includes Python-Depends: python-psycopg2. However, 
python-psycopg2 does not get added to my binary package's control file.

Possibly worth noting, I get the following warning when I build my package:
dpkg-gencontrol: warning: unknown information field 'Python-Depends' in input 
data in package's section of control info file

I'm using python-support 0.8.4 on Ubuntu Intrepid.


-- System Information:
Debian Release: lenny/sid
  APT prefers intrepid-updates
  APT policy: (500, 'intrepid-updates'), (500, 'intrepid-security'), (500, 
'intrepid')
Architecture: i386 (i686)

Kernel: Linux 2.6.27-11-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-support depends on:
ii  dpkg1.14.20ubuntu6.2 Debian package management system
ii  python  2.5.2-1ubuntu1   An interactive high-level object-o

python-support recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#484674: mldonkey: Packaging too complex

2009-03-12 Thread Forest Bond
Hi,

On Thu, Mar 12, 2009 at 10:54:10AM +0100, Sylvain Le Gall wrote:
 On Wed, Mar 11, 2009 at 05:32:48PM -0400, Forest Bond wrote:
  On Wed, Mar 11, 2009 at 10:14:25PM +0100, Mehdi Dogguy wrote:
   On  0, Forest Bond for...@alittletooquiet.net wrote:
 * Why all of the Debian-specific utilities in debian/utils?  This is
   just vanity.  Please, ship the upstream software, not your own.

   
   I won't insult the maintainer's job that easily. Their goal is to
   offer a better user experience. They do not modify the original
   behavior of the project (mldonkey). Feel free to not use them.
  
  I was too harsh, you are right.  I apologize.
  
  However, creating non-standard, distribution-specific ways to use the 
  upstream
  software does not improve the user experience, in my mind.  It makes the 
  user
  harder for upstream to support, and so should not be done lightly.
 
 As the primary writer of this utils, I really do not think having so
 much vanity.

As I said above, my wording was too harsh.  Please accept my apology.

 You must understand that the tools provided in debian/utils are used in
 various maintainer script. They are only useful for writing maintainer script.
 They are not intended to be used directly by user. Most of this script can be
 directly replaced by standard mldonkey command. The main difference is that
 the debian/tools utils provide offline command (i.e. without mldonkey
 running). This is only useful when you are configuring the package: the daemon
 must be offline but you must manage its configuration file.
 
 For example, mldonkey_users allow to add user at package configuration
 time. You can also add user when the daemon is running, directly into
 mldonkey (mlnet). Trying to use this tool when the daemon is running is
 a pretty bad idea (TM).

Perhaps the utilities should go in /usr/lib/mldonkey, then, instead of /usr/bin?

-Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org


signature.asc
Description: Digital signature


Bug#484674: mldonkey: Packaging too complex

2009-03-12 Thread Forest Bond
Hi,

On Thu, Mar 12, 2009 at 11:06:33AM +0100, Sylvain Le Gall wrote:
 On Thu, Jun 05, 2008 at 09:39:20AM -0400, Forest Bond wrote:
   * Why does mldonkey-server need an init script?  Yes, it's a daemon,
 but that is merely an implementation detail.  When it comes down to
 it, mldonkey is a *p2p client*.  It should be run by normal users
 when they want to connect to a p2p network.
 
 
 Because this is a daemon and debian require an init-script to run it.

Debian does not require an init script to run museekd.

   * Why the special make invocations?  The configure script suggests
 running `make', but debian/rules runs `make utils opt' or some such
 nonsense.  It fails when I try to build the version from intrepid on
 my hardy box (after backporting and installing the dependencies),
 even though just plain `make' runs perfectly.
 
 Because it works on Debian unstable, the primary target of this package.
 We do not support Ubuntu (at least not directly). 

It is not correct just because it works on one particular version of the
distribution with one particular version of the upstream software.  The
non-standard invocation makes it more difficult for someone else to maintain the
package.  I ran into problems trying to merge a newer version of the upstream
source.  Invoking make as upstream recommends works as expected.

-Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org


signature.asc
Description: Digital signature


Bug#484674: mldonkey: Packaging too complex

2009-03-12 Thread Forest Bond
Hi,

On Thu, Mar 12, 2009 at 10:54:10AM +0100, Sylvain Le Gall wrote:
 On Wed, Mar 11, 2009 at 05:32:48PM -0400, Forest Bond wrote:
  On Wed, Mar 11, 2009 at 10:14:25PM +0100, Mehdi Dogguy wrote:
   On  0, Forest Bond for...@alittletooquiet.net wrote:
 * Why all of the Debian-specific utilities in debian/utils?  This is
   just vanity.  Please, ship the upstream software, not your own.

   
   I won't insult the maintainer's job that easily. Their goal is to
   offer a better user experience. They do not modify the original
   behavior of the project (mldonkey). Feel free to not use them.
  
  I was too harsh, you are right.  I apologize.
  
  However, creating non-standard, distribution-specific ways to use the 
  upstream
  software does not improve the user experience, in my mind.  It makes the 
  user
  harder for upstream to support, and so should not be done lightly.
 
 As the primary writer of this utils, I really do not think having so
 much vanity. You must understand that the tools provided in
 debian/utils are used in various maintainer script. They are only useful
 for writing maintainer script. They are not intended to be used directly
 by user. Most of this script can be directly replaced by standard
 mldonkey command. The main difference is that the debian/tools utils
 provide offline command (i.e. without mldonkey running). This is only
 useful when you are configuring the package: the daemon must be offline
 but you must manage its configuration file.
 
 For example, mldonkey_users allow to add user at package configuration
 time. You can also add user when the daemon is running, directly into
 mldonkey (mlnet). Trying to use this tool when the daemon is running is
 a pretty bad idea (TM).

BTW, who will now maintain these four C programs that exist to support the
least common use-case for this package?

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org


signature.asc
Description: Digital signature


Bug#484674: mldonkey: Packaging too complex

2009-03-11 Thread Forest Bond
Hi,

Sorry for the late reply.

On Fri, Jun 06, 2008 at 11:05:41AM +0200, spiral voice wrote:
  Why does mldonkey-server need an init script?  Yes, it's a daemon,
  but that is merely an implementation detail.  When it comes down to
  it, mldonkey is a *p2p client*.  It should be run by normal users
  when they want to connect to a p2p network.
 
 YVMV, but MLDonkey is also designed to work as a P2P service,
 some people even use it on dedicated download servers, this is
 especially true since MLDonkey contains build-in multiuser functionality.

Hmm.  According to the mldonkey website, it is The p2p client for
Linux/Unix/Windows!.

Can you point me to some documentation of the multiuser functionality?

  Why the special make invocations?  The configure script suggests
  running `make', but debian/rules runs `make utils opt' or some such
  nonsense.  It fails when I try to build the version from intrepid on
  my hardy box (after backporting and installing the dependencies),
  even though just plain `make' runs perfectly.
 
 You may have hit an upstream bug, please post the error messages
 you are seeing with running make utils opt.
 
 I just tested ./configure  make utils opt and it compiled w/o errors.

Right, it seems to depend on the system.  But upstream doesn't recommend running
`make utils opt', they recommend running just `make', so it seems senseless to
bring the problem to them.

-Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org


signature.asc
Description: Digital signature


Bug#484674: mldonkey: Packaging too complex

2009-03-11 Thread Forest Bond
Hi,

On Wed, Mar 11, 2009 at 10:14:25PM +0100, Mehdi Dogguy wrote:
 On  0, Forest Bond for...@alittletooquiet.net wrote:
  mldonkey packaging is way to complicated and bloated.  This is
  unnecessary and causes bugs.
  
   * Why so many debconf questions?
 
 You're right. Maybe we can simplify this a bit. We are currently
 working on this problem. This is the only relevant criticism in this
 bug report. Thus, I'm merging this bug with a similar one.

I'm not sure that it is the only relevant criticism just because it's the only
one you agree with.

   * Why all of the Debian-specific utilities in debian/utils?  This is
 just vanity.  Please, ship the upstream software, not your own.
  
 
 I won't insult the maintainer's job that easily. Their goal is to
 offer a better user experience. They do not modify the original
 behavior of the project (mldonkey). Feel free to not use them.

I was too harsh, you are right.  I apologize.

However, creating non-standard, distribution-specific ways to use the upstream
software does not improve the user experience, in my mind.  It makes the user
harder for upstream to support, and so should not be done lightly.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org


signature.asc
Description: Digital signature


Bug#484674: (no subject)

2009-03-11 Thread Forest Bond
Hi,

 Forest Bond schrieb:
  Can you point me to some documentation of the multiuser functionality?
 
 http://cvs.savannah.gnu.org/viewvc/mldonkey/distrib/multiuser.txt?root=mldonkeyview=markup

Thanks.  It is interesting that mldonkey supports this.  However, I have to
imagine that it is probably not a common use case, right?

Are you an upstream developer?  Have you considered integrating the
Debian-specific utilities upstream?

Anyway (and I'm not sure if this was the case when I first submitted my report),
it looks like the mldonkey-server package at least asks whether or not it
should start mldonkey from the init script.  That is sufficient to keep me
happy.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org


signature.asc
Description: Digital signature


Bug#398010: (no subject)

2008-08-25 Thread Forest Bond
Hi Alastair,

Any news on this?

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org


signature.asc
Description: Digital signature


Bug#483568:

2008-06-26 Thread Forest
I had the same problem on xubuntu hardy, using gdm as my display manager.
The solution was to explicitly set my default session type to Xfce in the
gdm screen, and log in again.

https://bugs.launchpad.net/ubuntu/+bug/231311




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#484674: mldonkey: Packaging too complex

2008-06-05 Thread Forest Bond
Package: mldonkey
Severity: normal

mldonkey packaging is way to complicated and bloated.  This is
unnecessary and causes bugs.

 * Why does mldonkey-server need an init script?  Yes, it's a daemon,
   but that is merely an implementation detail.  When it comes down to
   it, mldonkey is a *p2p client*.  It should be run by normal users
   when they want to connect to a p2p network.

 * Why so many debconf questions?

 * Why all of the Debian-specific utilities in debian/utils?  This is
   just vanity.  Please, ship the upstream software, not your own.

 * Why the special make invocations?  The configure script suggests
   running `make', but debian/rules runs `make utils opt' or some such
   nonsense.  It fails when I try to build the version from intrepid on
   my hardy box (after backporting and installing the dependencies),
   even though just plain `make' runs perfectly.

All of these things make the package much more complicated than it
should be.  Simply trying to backport the package is a process that
takes several hours.

What is the justification for all of this complexity?

-- System Information:
Debian Release: lenny/sid
  APT prefers hardy-updates
  APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 
'hardy-backports'), (500, 'hardy'), (500, 'gutsy')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-14-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org


signature.asc
Description: Digital signature


Bug#81829: Deliver her to pleasure

2008-03-24 Thread rufus Forest

Medical science has made the most amazing of discoveries possible

http://www.Ilkerts.com/
Titties and beavers



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#161432: long an advocate of

2008-03-20 Thread forest tzl-cker
CockImpressiveSophia http://www.Sextiitoo.com




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#245096: article am bandgap

2008-03-17 Thread Forest Katz
Take Prescripitons and Medicaitons asap

www.www.associateartichoke.aura.potorswe.com



it's articleam




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#293897: antoinette bateau abort

2008-03-17 Thread Forest Kirk
Pick up Presrciptions and Meidcations asap

http://ardenbaptiste.badinage.nothyr.com



in antoinettebateau




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#470711: Fixed debdiff

2008-03-13 Thread Forest Bond
Previous debdiff broke installation of examples.  This one fixes it.

-Forest
-- 
Forest Bond
http://www.alittletooquiet.net
diff -u python-fuse-0.2-pre3/debian/changelog 
python-fuse-0.2-pre3/debian/changelog
--- python-fuse-0.2-pre3/debian/changelog
+++ python-fuse-0.2-pre3/debian/changelog
@@ -1,3 +1,10 @@
+python-fuse (1:0.2-pre3-4) unstable; urgency=low
+
+  * Use cdbs python-distutils class.
+  * Build packages for multiple Python versions (Closes: LP#199618).
+
+ -- Forest Bond [EMAIL PROTECTED]  Wed, 12 Mar 2008 22:47:28 -0400
+
 python-fuse (1:0.2-pre3-3) unstable; urgency=low
 
   * Update README.Debian (Closes: #427025).
@@ -16,6 +23,7 @@
 
  -- Sebastien Delafond [EMAIL PROTECTED]  Sat, 26 May 2007 11:38:14 -0700
 
+
 python-fuse (2.5-5) unstable; urgency=low
 
   * Rebuild with new default version of python (Closes: #382915).
diff -u python-fuse-0.2-pre3/debian/rules python-fuse-0.2-pre3/debian/rules
--- python-fuse-0.2-pre3/debian/rules
+++ python-fuse-0.2-pre3/debian/rules
@@ -1,11 +1,9 @@
 #!/usr/bin/make -f
 
-export DH_PYCENTRAL=nomove
-
 DEB_PYTHON_SYSTEM=pycentral
 
 include /usr/share/cdbs/1/rules/debhelper.mk
-include /usr/share/dpatch/dpatch.make
+include /usr/share/cdbs/1/class/python-distutils.mk
 
 STAGING_DIR   := $(CURDIR)/debian/python-fuse
 UPSTREAM_EXAMPLE_DIR  := example
@@ -16,11 +14 @@
-   mkdir -pm755 $(STAGING_DIR)
-
-   python setup.py install --root=$(STAGING_DIR)
cp -r $(UPSTREAM_EXAMPLE_DIR) 
$(STAGING_DIR)/usr/share/doc/python-fuse/examples
-
-   dh_pycentral
-   dh_python
-
-clean:: unpatch
-   rm -fr build
-   find . -name *pyc | xargs rm -f


signature.asc
Description: Digital signature


Bug#470711: [PATCH] modules not built/installed for all Python versions

2008-03-12 Thread Forest Bond
Package: python-fuse
Version: 1:0.2-pre3-3
Refs: https://bugs.launchpad.net/ubuntu/+source/python-fuse/+bug/199618

Looks like this was partially dealt with in the past, but aren't Python modules
supposed to be usable by *all* support Python versions?

debdiff attached.

-Forest
-- 
Forest Bond
http://www.alittletooquiet.net
diff -u python-fuse-0.2-pre3/debian/changelog 
python-fuse-0.2-pre3/debian/changelog
--- python-fuse-0.2-pre3/debian/changelog
+++ python-fuse-0.2-pre3/debian/changelog
@@ -1,3 +1,10 @@
+python-fuse (1:0.2-pre3-4) unstable; urgency=low
+
+  * Use cdbs python-distutils class.
+  * Build packages for multiple Python versions (Closes: LP#199618).
+
+ -- Forest Bond [EMAIL PROTECTED]  Wed, 12 Mar 2008 22:47:28 -0400
+
 python-fuse (1:0.2-pre3-3) unstable; urgency=low
 
   * Update README.Debian (Closes: #427025).
@@ -16,6 +23,7 @@
 
  -- Sebastien Delafond [EMAIL PROTECTED]  Sat, 26 May 2007 11:38:14 -0700
 
+
 python-fuse (2.5-5) unstable; urgency=low
 
   * Rebuild with new default version of python (Closes: #382915).
diff -u python-fuse-0.2-pre3/debian/rules python-fuse-0.2-pre3/debian/rules
--- python-fuse-0.2-pre3/debian/rules
+++ python-fuse-0.2-pre3/debian/rules
@@ -3,24 +3,12 @@
-export DH_PYCENTRAL=nomove
-
 DEB_PYTHON_SYSTEM=pycentral
 
 include /usr/share/cdbs/1/rules/debhelper.mk
-include /usr/share/dpatch/dpatch.make
+include /usr/share/cdbs/1/class/python-distutils.mk
 
 STAGING_DIR   := $(CURDIR)/debian/python-fuse
 UPSTREAM_EXAMPLE_DIR  := example
 DEB_COMPRESS_EXCLUDE  := .py
 DEB_INSTALL_DOCS_ALL  := debian/README.Debian
 
-install/python-fuse::
-   mkdir -pm755 $(STAGING_DIR)
-
-   python setup.py install --root=$(STAGING_DIR)
+install::
cp -r $(UPSTREAM_EXAMPLE_DIR) 
$(STAGING_DIR)/usr/share/doc/python-fuse/examples
-
-   dh_pycentral
-   dh_python
-
-clean:: unpatch
-   rm -fr build
-   find . -name *pyc | xargs rm -f


signature.asc
Description: Digital signature


Bug#138873: Our company in United States helping individuals in online business.

2008-02-29 Thread forest kara
International company Dex. Union Inc is looking for top candidates for a number 
of opportunities: Sales representative, Finance representative. 
We are searching for individuals in United States who have the intellectual 
capacity and interested in good earnings. 
Get job in 3 hours after your answer, and start earning!
No relocation, cell phone and email required. High Salary!
If you're seeking a convenient job location, consistent hours and great 
opportunity for growth than this is the perfect position for you in USA!

Company Details and How to apply? 

Please write: [EMAIL PROTECTED]

Regards Adam Nelson
Dex. Union Inc.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#398010: Please upgrade package

2008-02-05 Thread Forest Bond
Hi,

I understand that Debian is trying hard to maintain a delta from upstream with
this package, and that that is likely the cause of delay.

Can we drop the delta and get this package upgraded, or is that not an option?

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net


signature.asc
Description: Digital signature


Bug#33344: Kings had big ones

2008-01-28 Thread forest georg
they always say that size doesnt matter and i believed them, but they say it 
just not to hurt your ego, which i learned
later on... after getting dumped over a dozen times. now that I increased the 
size of my tool they have no reason not to
like me anymore, and i always enjoy watching their facial expression when they 
unzip those pants 

http://tyrisonsef.com

it's very simple: pop it 3 times a day, and watch what's in your pants increase 
in new lenght and girth within a few
months. i tried it, it worked, you should too you have nothing to lose but 
everything to gain




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#163624: My wife can't keep up.

2007-09-10 Thread Forest Rainey

The thing convinced me were, No side effects, all herbal, no dependence for 
life.
http://emagx.net




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#197156: POP-UP MENU

2007-07-23 Thread Forest

Have you ever hoped to have a pricey Watch?

We have the soulition for you!

We have all the big names 
for a low precentage of the expense.


www.qassdek.com




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#409849: contact lists for Dentists

2007-07-17 Thread Forest cohosh



Here's what we have until Jul 20

MDs in the USA
more than 700,000 records - can be sorted by state or specialty
many different fields, lots of specialties .. $354

USA Hospital Contact List
over 23K administrators on file
full data on high profile execs .. $296

USA Nursing Home Database
more than 31K senior admins, 11 thousand nursing directors
in over 14K US nursing homes .. $193

USA Dentist and Dental Services Listing
Includes 597,000 total records .. $194

Order the MD data and get the other 3 at no additional cost

For more details or to purchase send an email to : [EMAIL PROTECTED] or call 
206-202-3021





Send an email with rem in the subject to discontinue these emails


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#398010: New upstream version with fix

2007-06-27 Thread Forest Bond
New upstream version 0.52.6 resolves this issue, as the patch was accepted.

The new tarball can be extracted from this SRPM:

ftp://download.fedora.redhat.com/pub/fedora/linux/core/test/6.93/source/SRPMS/newt-0.52.6-3.fc7.src.rpm

-Forest


signature.asc
Description: Digital signature


Bug#398010: patch accepted by upstream developers

2007-02-16 Thread Forest Bond
This patch (in a slightly modified form, most likely) has been applied by
the upstream maintainer, but not yet released.

-Forest


signature.asc
Description: Digital signature


Bug#398010: wishlist: popWindow with no refresh

2006-11-10 Thread Forest Bond
Package: newt
Version: 0.52.2-5.1

It is quite possible, although slightly awkward to display multiple windows
using newt/snack, and update an arbitrary window. To do so, one must pop windows
until the window needing updating is the current window, redraw it, and push
the popped windows back on the display. Using this technique, it is desirable to
hold off a refresh until the entire process has been completed, especially when
the user is viewing the UI over a slow-ish network connected shell.

Unfortunately, newt automatically refreshes the screen every time a call to
newtPopWindow is made. This is inconsistent with, e.g., newtShowWindow, for
which an explicit refresh must be performed.

I have a patch to go into debian/patches that allows windows to be popped
without forcing a refresh. This patch will not break current programs using
newt/snack, but allows new programs to make use of the refresh-less popWindow
function. Please save the patch as _pop_window_no_refresh.patch .
diff -Naur newt-0.52.2-old/newt.c newt-0.52.2/newt.c
--- newt-0.52.2-old/newt.c  2006-07-30 11:20:03.0 -0400
+++ newt-0.52.2/newt.c  2006-07-30 11:20:36.0 -0400
@@ -1180,6 +1180,11 @@
  * @brief Remove the top window
  */
 void newtPopWindow(void) {
+newtPopWindowNoRefresh();
+newtRefresh();
+}
+
+void newtPopWindowNoRefresh(void) {
 int j, row, col;
 int n = 0;
 
@@ -1209,8 +1214,6 @@
 SLsmg_set_char_set(0);
 
 newtTrashScreen();
-
-newtRefresh();
 }
 
 void newtGetWindowPos(int * x, int * y) {
diff -Naur newt-0.52.2-old/newt.h newt-0.52.2/newt.h
--- newt-0.52.2-old/newt.h  2006-07-30 11:20:02.0 -0400
+++ newt-0.52.2/newt.h  2006-07-30 11:20:36.0 -0400
@@ -120,6 +120,7 @@
  const char * title);
 int newtCenteredWindow(unsigned int width,unsigned int height, const char * 
title);
 void newtPopWindow(void);
+void newtPopWindowNoRefresh(void);
 void newtSetColors(struct newtColors colors);
 void newtRefresh(void);
 void newtSuspend(void);
diff -Naur newt-0.52.2-old/snack.py newt-0.52.2/snack.py
--- newt-0.52.2-old/snack.py2006-07-30 11:20:02.0 -0400
+++ newt-0.52.2/snack.py2006-07-30 11:20:36.0 -0400
@@ -460,8 +460,10 @@
 
 return _snack.gridwrappedwindow(grid.g, title)
 
-def popWindow(self):
-return _snack.popwindow()
+def popWindow(self, refresh = True):
+if refresh:
+return _snack.popwindow()
+return _snack.popwindownorefresh()
 
 def refresh(self):
 return _snack.refresh()
diff -Naur newt-0.52.2-old/snackmodule.c newt-0.52.2/snackmodule.c
--- newt-0.52.2-old/snackmodule.c   2006-07-30 11:20:02.0 -0400
+++ newt-0.52.2/snackmodule.c   2006-07-30 11:19:29.0 -0400
@@ -53,6 +53,7 @@
 static PyObject * openWindow(PyObject * s, PyObject * args);
 static PyObject * popHelpLine(PyObject * s, PyObject * args);
 static PyObject * popWindow(PyObject * s, PyObject * args);
+static PyObject * popWindowNoRefresh(PyObject * s, PyObject * args);
 static PyObject * pushHelpLine(PyObject * s, PyObject * args);
 static snackWidget * radioButtonWidget(PyObject * s, PyObject * args);
 static PyObject * refreshScreen(PyObject * s, PyObject * args);
@@ -87,6 +88,7 @@
 { openwindow, openWindow, METH_VARARGS, NULL },
 { pophelpline, popHelpLine, METH_VARARGS, NULL },
 { popwindow, popWindow, METH_VARARGS, NULL },
+{ popwindownorefresh, popWindowNoRefresh, METH_VARARGS, NULL },
 { pushhelpline, pushHelpLine, METH_VARARGS, NULL },
 { radiobutton, (PyCFunction) radioButtonWidget, METH_VARARGS, NULL },
 { reflow, (PyCFunction) reflowText, METH_VARARGS, NULL },
@@ -530,6 +532,12 @@
 return Py_None;
 }
 
+static PyObject * popWindowNoRefresh(PyObject * s, PyObject * args) {
+newtPopWindowNoRefresh();
+Py_INCREF(Py_None);
+return Py_None;
+}
+
 static PyObject * messageWindow(PyObject * s, PyObject * args) {
 char * title, * text;
 char * okbutton = Ok;


Bug#98335: Obtained DIplomas in 2 Weeks zoe8C

2006-02-24 Thread Forest Whaley


Lazy to attend exam or classes?

We have Diplomas, Degrees, Masters' or Doctorate
to choose from any field of your interest.

Only 2 weeks require to delivers the prestigious non-accredited
universities paper to your doorstep.

Do not hesitate to give us a call today!
1-484-693-8861


n7b


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#116507: can you see this?

2005-10-02 Thread Forest Hadley
Jesus dude

You'll never guess what happened to me last tuestday.

Basically found alternative date site that doesn't cost a thing.

So many gals are there messaging and meeting eachother.

And chances are there is someone (or more than one) for you.

Although most of them want one-nighters, there are also those who like it 
serious.

your reply to this confirmation message is not needed :~)


http://www.beatingbitches.com/extra/greatdating/




PS:no.more?
http://www.beatingbitches.com/extra/greatdating/getmeoff.php


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#61212: fwd: new link to download Microsoft Windows XP Professional with SP2 Corporate Edition.

2005-05-09 Thread Forest
It's your aptitude, not just your attitude that determines your ultimate 
altitude.
Looking for popular sfotware, but tight on budget?
We are selilng world bestseslers at the chaepest prcices around!
Why so csheap? We don\'t sel\'ll progrmas in a fancy box, with printed 
documentation, etc., meaning we do not shell out on CD manufacturing.
The sosft is only what you get - available for dwonload right after purcshase.
Fast servers with 100mb conection.
Instant Dwonload!
The measure of a man is the way he bears up under misfortune. 
http://zazzo.com.softforless.com The way to get things done is not to mind who 
gets the credit for doing them. You must take action now that will move you 
towards your goals. Develop a sense of urgency in your life.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]


Bug#82474: Upgrade the program for your PC at lower price

2005-02-26 Thread forest britt
If you have more choice,then why not get your wanted PC program discs for
office operation, programming, server maintenance, PC diagnostics, office
administration, finance and graphic design processing at the best internet
prices.
What would you do if you can choose to save hundreds on PC program discs
for office operation, programming, server maintenance, PC diagnostics,
office administration, finance and graphic design processing.

To save hundreds on program installation and system upgrade, you should
choose our site and get PC program discs for office operation, programming,
server maintenance, PC diagnostics, office administration, finance and
graphic design processing.
Our discount site supply you with well-disciplined customer service and low
prices as well. 


http://courteousact.com/d3y/

Looking for low priced PC program discs? Let our low priced and high level
products meet your needs.


of letters, including one from a hospital informing them that a lien has
been placed on their
pull his own pants back up and cinch his belt.What did he do? Reid said
afterward with mock



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]