Bug#663336: shnsplit: can't be forced to split with no split points given

2024-08-21 Thread Alexey Sergushichev
Hi Andreas,

I haven't been using this tool, I guess, for at least 10 years :) I'm not
that interested in this fix anymore, and can't confirm if the bug is still
present.

Also, I don't know how to the bug with `wontfix`. If you could do it
instead, that would be great.

Thanks,
Alexey

On Wed, Aug 21, 2024 at 2:20 AM Andreas Tille  wrote:

> Control: tags -1 - patch
>
> Hi Aleksey,
>
> since shntool came up in the Bug of the Day[1] I tried to apply all
> patches provided and close according bugs.  Unfortunately your patch
> does not apply to the latest upstream version any more.  If you are
> continuously interested in this feature it would be great if you would
> provide a MR to the repository on Salsa[2].  Otherwise please tag the
> bug `wontfix`.
>
> Thanks a lot for your patch anyway
>Andreas.
>
>
> [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
> [2] https://salsa.debian.org/debian/shntool
>
> --
> https://fam-tille.de
>


Bug#1078583:

2024-08-13 Thread Alexey Kuznetsov
Duplicate of #1078556

-- AK



Bug#1078556: bash: 5.2.21-2.1 to 5.2.21-2.1+b1 breaks printf %.2f .1

2024-08-12 Thread Alexey Kuznetsov
Even worse when you try:

LC_ALL=C bash -c "printf '%.0f\n' 1.1"
-
173320084109970710593010218833648600600653512807741911907522891341063031
2117357922027417552523683781429428063902803100232279567016412626035
72504349300740698967135845237369265827309950484943433842847565886086009
0010844381602963990222579244296916726653378439564783760483403573151
23152271907670933866106779776348480753882012301707187264841972472015276
82906059388941882622456823311606990281918997616714720593937063030869632
78386805719447880404337602573318220362207722350807613718898914979976644
28313851725493628037341172759699758248359652652951769925935734763979993
72384831001757905989076727323976308919459523189506173723653693696254573
05624425684825377316058770608377615585484863898948223175641726481765716
2932794228265608541767666199199763245234021519977145511706624


or even larger output (3-10 times). Arch report:

https://gitlab.archlinux.org/archlinux/packaging/packages/bash/-/issues/3

-- AK



Bug#1076193: linux-image-6.9.7-amd64: fuse-overlayfs cusing kernel to crash during suspend

2024-07-12 Thread Alexey Kuznetsov

Package: src:linux
Version: 6.9.7-1
Severity: normal

Dear Maintainer,

Using fuse-overlayfs on tmpfs (/dev/shm/[folder]) causing system to 
freeze during suspend / resume cycle. With kernel message:


[60730.265604] task:systemd-sleep state:D stack:0 pid:88748 ppid:1 
flags:0x4002

[60730.267480] Call Trace:
[60730.269418] 
[60730.271199] __schedule+0x351/0xa20
[60730.273102] ? __ia32_sys_tee+0xd0/0xd0
[60730.274827] schedule+0x5d/0xe0
[60730.276542] wb_wait_for_completion+0x82/0xb0
[60730.278412] ? dequeue_task_stop+0x70/0x70
[60730.280135] sync_inodes_sb+0xda/0x2b0
[60730.281958] ? __ia32_sys_tee+0xd0/0xd0
[60730.283632] iterate_supers+0x85/0xe0
[60730.285397] ksys_sync+0x40/0xa0
[60730.287002] ksys_sync_helper+0x13/0x80
[60730.288597] pm_suspend.cold+0x126/0x35e
[60730.290276] state_store+0x68/0xd0
[60730.291765] kernfs_fop_write_iter+0x11b/0x1f0
[60730.293304] vfs_write+0x241/0x400
[60730.294638] ksys_write+0x6b/0xf0
[60730.295916] do_syscall_64+0x58/0xc0
[60730.297302] ? exit_to_user_mode_prepare+0x3c/0x1c0
[60730.298552] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[60730.299869] RIP: 0033:0x7f74082f4190
[60730.301228] RSP: 002b:7fff12152e88 EFLAGS: 0202 ORIG_RAX: 
0001
[60730.302451] RAX: ffda RBX: 0004 RCX: 
7f74082f4190
[60730.303688] RDX: 0004 RSI: 7fff12152f70 RDI: 
0004
[60730.304731] RBP: 7fff12152f70 R08: 0007 R09: 
558b894ce590
[60730.305098] R10: f664a9c3885c4633 R11: 0202 R12: 
0004
[60730.305447] R13: 558b894cc2d0 R14: 0004 R15: 
7f74083ca9e0

[60730.305780] 

Steps to reproduce:

mkdir -p /dev/shm/test/up
mkdir -p /dev/shm/test/tmp
mkdir -p /dev/shm/test/data

fuse-overlayfs -o 
"static_nlink,noacl,upperdir=/dev/shm/test/up,lowerdir=$HOME/.mozilla/firefox/,workdir=/dev/shm/test/tmp" 
/dev/shm/test/data


firefox --profile /dev/shm/test/data/c9933.default

systemctl suspend

-- Package-specific info:
** Version:
Linux version 6.9.7-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.3.0-1) 13.3.0, GNU ld (GNU Binutils 
for Debian) 2.42.50.20240625) #1 SMP PREEMPT_DYNAMIC Debian 6.9.7-1 
(2024-06-27)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.9.7-amd64 
root=UUID=a90dee0b-b4d0-429f-a078-8eda0b36abcd ro mitigations=off


** Not tainted

** Kernel log:
[ 7.388652] [drm] VCN decode is enabled in VM mode
[ 7.389091] [drm] VCN encode is enabled in VM mode
[ 7.390743] [drm] JPEG decode is enabled in VM mode
[ 7.391231] Console: switching to colour dummy device 80x25
[ 7.391248] amdgpu :03:00.0: vgaarb: deactivate vga console
[ 7.391251] amdgpu :03:00.0: amdgpu: Trusted Memory Zone (TMZ) 
feature enabled

[ 7.391254] amdgpu :03:00.0: amdgpu: MODE2 reset
[ 7.391833] [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, 
fragment size is 9-bit
[ 7.391838] amdgpu :03:00.0: amdgpu: VRAM: 512M 0x00F4 - 
0x00F41FFF (512M used)
[ 7.391841] amdgpu :03:00.0: amdgpu: GART: 1024M 0x 
- 0x3FFF

[ 7.391847] [drm] Detected VRAM RAM=512M, BAR=512M
[ 7.391848] [drm] RAM width 128bits DDR4
[ 7.391938] [drm] amdgpu: 512M of VRAM memory ready
[ 7.391944] [drm] amdgpu: 7697M of GTT memory ready.
[ 7.391956] [drm] GART: num cpu pages 262144, num gpu pages 262144
[ 7.392040] [drm] PCIE GART of 1024M enabled.
[ 7.392043] [drm] PTB located at 0x00F41FC0
[ 7.392416] [drm] Loading DMUB firmware via PSP: version=0x01010027
[ 7.392800] [drm] Found VCN firmware Version ENC: 1.20 DEC: 5 VEP: 0 
Revision: 3

[ 7.392805] amdgpu :03:00.0: amdgpu: Will use PSP to load VCN firmware
[ 7.450057] audit: type=1400 audit(1720772121.355:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=753 comm="apparmor_parser"
[ 7.454656] audit: type=1400 audit(1720772121.359:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="libreoffice-xpdfimport" pid=755 comm="apparmor_parser"
[ 7.460091] audit: type=1400 audit(1720772121.363:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=744 
comm="apparmor_parser"
[ 7.463631] audit: type=1400 audit(1720772121.367:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" 
pid=745 comm="apparmor_parser"
[ 7.463643] audit: type=1400 audit(1720772121.367:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="nvidia_modprobe//kmod" pid=745 comm="apparmor_parser"
[ 7.468533] audit: type=1400 audit(1720772121.371:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="passt" pid=748 
comm="apparmor_parser"
[ 7.475163] audit: type=1400 audit(1720772121.379:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" 
pid=747 comm="apparmor_parser"
[ 7.475465] audit: type=1400 audit(1720772121.379:9): apparmor="STATUS" 
operation="profile_load" profile="

Bug#1054607: btrfs-progs: btrfs prop set causing system to reboot

2023-12-31 Thread Alexey Kuznetsov


cat /proc/asound/cards
 0 [PCH]: HDA-Intel - HDA Intel PCH
  HDA Intel PCH at 0x5121 irq 140
 1 [HDMI   ]: HDA-Intel - HDA ATI HDMI
  HDA ATI HDMI at 0x50e2 irq 141



sudo setfattr -n compression -v zstd /dev/snd/pcm*
setfattr: /dev/snd/pcmC0D0c: Operation not supported
setfattr: /dev/snd/pcmC0D0p: Operation not supported
setfattr: /dev/snd/pcmC0D2c: Operation not supported
setfattr: /dev/snd/pcmC1D10p: Operation not supported
setfattr: /dev/snd/pcmC1D3p: Operation not supported
setfattr: /dev/snd/pcmC1D7p: Operation not supported
setfattr: /dev/snd/pcmC1D8p: Operation not supported
setfattr: /dev/snd/pcmC1D9p: Operation not supported


seems fine, no reboot.



Bug#1054607: btrfs-progs: btrfs prop set causing system to reboot

2023-12-29 Thread Alexey Kuznetsov
It have been fixed in https://github.com/kdave/btrfs-progs/issues/699

I can answer you later about kernel / driver related solution.



Bug#1056543: isenkram: No new firmware package with requested firmware detected (but firmware files are missing)

2023-11-22 Thread Alexey Kuznetsov
On Wed, Nov 22, 2023 at 8:39 PM Petter Reinholdtsen  wrote:

> [Alexey Kuznetsov]
> > Thanks. In future releases can isenkram also use an apt-file database
> > or similar in addition to build-in database?
>
> It is using the similar appstream, and firmware packages are expected to
> populate it with the relevant information.  I believe requiring apt-file
> in addition will increase the disk foot print too much, and slow down
> 'apt update' too much to be the default setup.
>
> The 'appstreamcli what-provides firmware:runtime ipw2100-1.3-p.fw'
> command is supposed to return the relevant package as registered in
> appstream.  Is it not working?  If so, the fix need to be done in the
> firmware package.
>
> --
> Happy hacking
> Petter Reinholdtsen
>

It is working. Huge output https://paste.debian.net/1298974/


Bug#1056543: isenkram: No new firmware package with requested firmware detected (but firmware files are missing)

2023-11-22 Thread Alexey Kuznetsov
On Wed, Nov 22, 2023 at 7:57 PM Petter Reinholdtsen  wrote:

> [a...@me.com]
> > isenkram-autoinstall-firmware reporting no new packages need to be
> > installed but firmware files are missing.
>
> Look like the ipw2100-1.3.fw file was added to the archive after the
> last update of the firmware list in isenkram.  Thank you for the heads
> up.  I'll upload an updated edition to unstable.
>
> > Same as 'isenkram-pkginstall-l' showing empty list.
>
> This uses the appstream metadata, but is not mapping loaded kernel
> drivers firmware files (only present module and modalias information
> mapped to packages using appstream), so this is expected.
>
> --
> Happy hacking
> Petter Reinholdtsen
>

Thanks. In future releases can isenkram also use an apt-file database or
similar in addition to build-in database?

-- AK


Bug#1026091: cpu

2023-10-29 Thread Alexey Kuznetsov
I ran btrfs benchmark tests to find out which compression is better for
specified CPU. Turns out this CPU can't handle zstd compression.

File size of 400MB compressing using zstd measuring with 2KB/sec speed
and seems never can finish the job.

# sudo ./btrfs-benchmark 
btrfs-progs v6.2

...

1   992.00MiB  /dev/ram0

setup:  435MiB 0:01:27 [5,00MiB/s]
[=>] 100% 
 none:  435MiB 0:00:30 [14,5MiB/s]
[=>] 100% 
none 30730ms 14869026/sec 100% (456925184) E:0
  lzo:  435MiB 0:00:43 [9,92MiB/s]
[=>] 100% 
lzo 44995ms 10155021/sec 62% (284934144) E:3822
   zlib:1:  435MiB 0:02:19 [3,13MiB/s]
[=>] 100% 
zlib:1 150413ms 3037803/sec 45% (205955072) E:1668
   zlib:2:  435MiB 0:02:50 [2,56MiB/s]
[=>] 100% 
zlib:2 176573ms 2587740/sec 44% (201863168) E:1444
   zlib:3:  435MiB 0:02:56 [2,46MiB/s]
[=>] 100% 
zlib:3 185409ms 2464417/sec 43% (198782976) E:1392
^C   zstd:1: 30,3MiB 0:01:35 [2,71KiB/s] [==> 
]  6% ETA 0:21:10


https://gitlab.com/axet/homebin/-/blob/debian/btrfs-benchmark



Bug#1026091: zstd only

2023-10-25 Thread Alexey Kuznetsov
Issues is only zstd related. lzo /boot compression works / boots.

-- AK



Bug#1053559: Feature: argon2id support

2023-10-06 Thread Alexey Kuznetsov
> Luckily we managed to fit most initrds into 4GB now so we're probably
> safe for now if you don't do crazy things like high-memory password
> hashing.

argon2id is memory dependent key. Recommended key size (memory
requirements, not the key it self) are 1GB in heap size.

Here is my desktop machine. Memory map using following script (it
showing blocks more then 1MB in size).

dmesg | awk '/usable/ && /BIOS-e820/ && match($0, /mem ([0-9a-z]+)-([0-
9a-z]+)/,aa){s=strtonum(aa[1]);e=strtonum(aa[2]);if(e-
s>1024*1024)printf("0x%x-0x%x %dGB\n",s,e,((e-s)/1024/1024/1024))}'

0x10-0x35f3cfff 0GB
0x1-0x4bfff 14GB

It is clear here is no space below 4GB. And argon2id will most likely
fail on that machine if here is no >4GB grub support.

> I have absolutely no idea what you're saying, but as you may have
seen
> by the recent CVE again, we have a lot of problem with code quality
and
> need to minimize the attack surface as much as reasonably possible.

I'm sorry. I should be more clear and polite here. I see that FDE (full
disk encryption) is more secure, since I do not have to deal with
signing kernels and init.rd data. Also having FDE reducing the EFI
partition size significantly. So, in ideal world here will be only LUKS
disk encryption, and EFI would support decryption of disk, which will
resolve all CVE grub related issues at once.



Bug#1053559: Feature: argon2id support

2023-10-06 Thread Alexey Kuznetsov
> Feel free to land the support upstream, but it's not something that
> we should be shipping downstream.

I report upstream. But seems like it not going to be fixed anytime
soon. So, I share my smartmem.patch here. But I have no idea how it
works here at Debian. Maybe I better to keep it as is, rebuilding grub
locally.

> Going forward, for secure boot, our focus is not on adding things,
but on removing
> existing things like f2fs file support again. It stands to reason
> that encrypted /boot should not be supported either as there is no
> practical use case (it is security by obscurity) and you are better
> served by an unencrypted boot with a pre-built signed initrd or
> a MOK-signed initrd (or really UKI), and decrypting untrusted data
> hence is unnecessary danger.
> 

Saying things I put in my pocket are untrusted, but items gaven to me
by other guys with sign, are trusted?! That how security treated here
at debian from all members?

Beside security point, having hudge many GB boot partition with all
kernel installed is a pain. I keep my EFI under 50MB for binaries to
boot.



Bug#1053559: Feature: argon2id support

2023-10-06 Thread Alexey Kuznetsov

Package: grub-efi-amd64-bin

Dear Maintainer,

I managed to install argon2i patches from Arch repo and it works!
But argon2 may fail on some system due to lack of memory error and
makes some systems unbootable.

In short: grub2 by default on x64 machines only allocates memory only
from first 4GB (0x1000) physical address to avoid EFI bugs (which
are very common, when programmers EFI using 32bit register for pointers,
which as result causing EFI to crash when system sends x64 bit pointers
during IO proc calls). As result not every machines has enough (1GB 
continuous) memory for argon2id keys. So we need allocate memory from 
higher regions >4gb. I wrote a smartmem.patch (hack, since it need more 
work).


You need argon_*.patch:

* https://aur.archlinux.org/packages/grub-improved-luks2-git

smartmem.patch (allow to allocate >4gb if original allocation <4gb
fails)

This is my original conversation (about smartmem.patch >4gb patch):

* https://savannah.gnu.org/bugs/index.php?64471

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/luks / btrfs 
rw,noatime,ssd,discard,space_cache=v2,subvolid=5,subvol=/ 0 0
/dev/nvme0n1p2 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 
0 0
/dev/sdb1 /media/axet/4GB btrfs 
rw,nosuid,nodev,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0
/dev/sda1 /media/axet/1TB btrfs 
rw,nosuid,nodev,relatime,space_cache,subvolid=5,subvol=/ 0 0

*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi

function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}

if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod btrfs
cryptomount -u 9aa58ce3e29149ccaa3ceb12a9f0af1c
set root='cryptouuid/9aa58ce3e29149ccaa3ceb12a9f0af1c'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 
--hint='cryptouuid/9aa58ce3e29149ccaa3ceb12a9f0af1c' 
92475bc2-c978-4f26-9e6b-7bc1dde85cd4

else
search --no-floppy --fs-uuid --set=root 92475bc2-c978-4f26-9e6b-7bc1dde85cd4
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod btrfs
cryptomount -u 9aa58ce3e29149ccaa3ceb12a9f0af1c
set root='cryptouuid/9aa58ce3e29149ccaa3ceb12a9f0af1c'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 
--hint='cryptouuid/9aa58ce3e29149ccaa3ceb12a9f0af1c' 
92475bc2-c978-4f26-9e6b-7bc1dde85cd4

else
search --no-floppy --fs-uuid --set=root 92475bc2-c978-4f26-9e6b-7bc1dde85cd4
fi
insmod png
if background_image 
/usr/share/desktop-base/emerald-theme/grub/grub-16x9.png; then

set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class 
gnu --class os $menuentry_id_option 
'gnulinux-simple-92475bc2-c978-4f26-9e6b-7bc1dde85cd4' {

load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod btrfs
cryptomount -u 9aa58ce3e29149ccaa3ceb12a9f0af1c
set root='cryptouuid/9aa58ce3e29149ccaa3ceb

Bug#1053275: (no subject)

2023-09-30 Thread Alexey Kuznetsov

Recent patch:

* 
https://gitlab.com/axet/homebin/-/blob/debian/dbuild.d/bookworm/devscripts/mk-build-deps.patch


Also devscripts failed to build without:

* 
https://gitlab.com/axet/homebin/-/blob/debian/dbuild.d/bookworm/devscripts/build.patch


-- AK



Bug#1053275: devscripts: mk-build-deps failed to build i386 packages on amd64 host

2023-09-30 Thread Alexey Kuznetsov

Package: devscripts
Version: 2.23.4
Severity: normal

Dear Maintainer,

the script copy Build-Depends into Depends. But those are not the same 
fields. Build-Depends parsed differently by apt then Depends. For most 
cases it is the same. But when you specify Build-Depends as for example 
python3-mako apt will install python3-mako:all arch. But when this build 
dependency moved into Depends with out arch specification, apt will try 
to install python3-mako:i386. and since here is no python3-mako:i386 
install will failed.


Following should work on amd64:

apt build-dep mangohud
apt build-dep mangohud:i386
mk-build-deps mangohud
mk-build-deps -a i386 mangohud

This patch / hack fixing the behaviour:

diff --git a/scripts/mk-build-deps.pl b/scripts/mk-build-deps.pl
index 8b35e7e..f09ae9b 100755
--- a/scripts/mk-build-deps.pl
+++ b/scripts/mk-build-deps.pl
@@ -425,7 +425,7 @@ if ($opt_install) {
my (@pkg_names, @deb_files, @buildinfo_files, @changes_files, %uniq);
for my $package (@packages) {
if ($uniq{ $package->{deb_file} }++ == 0) {
- push @pkg_names, $package->{package};
+ push @pkg_names, $package->{package}.":".$package->{arch};
push @deb_files, $package->{deb_file};
push @buildinfo_files, $package->{buildinfo_file};
push @changes_files, $package->{changes_file};
@@ -514,16 +514,6 @@ sub build_equiv {
$hostarch = $opt_hostarch;
}

- if ($packagearch eq "all") {
- if ($buildarch ne $hostarch) {
- die
-"build architecture \"$buildarch\" is unequal host architecture 
\"$hostarch\" in which case the package architecture must not be \"all\" 
(but \"$hostarch\" instead)\n";

- }
- } elsif ($packagearch ne $hostarch) {
- die
-"The package architecture must be equal to the host architecture except 
if the package architecture is \"all\"\n";

- }
-
my $build_profiles = [split /\s+/, ($ENV{'DEB_BUILD_PROFILES'} // "")];
if (defined $opt_buildprofiles) {
$build_profiles = [split /,/, $opt_buildprofiles];
@@ -560,6 +550,10 @@ sub build_equiv {
$dep->{archqual} = $buildarch;
}
}
+ my $str = `apt-cache showsrc "$dep" | grep-dctrl --show-field 
Package-List - | awk '\$1 == "$dep" && /arch=all/{print \$1}'`;

+ if ($str ne "") {
+ $dep->{archqual} = "all";
+ }
return 1;
};
deps_iterate($positive, $handle_native_archqual);
@@ -574,6 +568,14 @@ sub build_equiv {
$buildess .= ", crossbuild-essential-$hostarch:$buildarch";
}

+ use File::Temp ();
+ my $temp = File::Temp->new();
+ print $temp
+"
+$pkgname ($opts->{version}) unstable; urgency=low
+
+ * First version
+";
my $readme = '/usr/share/devscripts/templates/README.mk-build-deps';
open EQUIVS, "| equivs-build $args-"
or die "$progname: Failed to execute equivs-build: $!\n";
@@ -581,7 +583,9 @@ sub build_equiv {
. "Priority: optional\n"
. "Standards-Version: 3.7.3\n\n"
. "Package: $pkgname\n"
- . "Architecture: $packagearch\n"
+ . "Architecture: any\n"
+ . "Multi-Arch: same\n"
+ . "Changelog: $temp\n"
. "Depends: $buildess, $positive\n";

print EQUIVS "Conflicts: $negative\n" if $negative;
@@ -603,10 +607,17 @@ sub build_equiv {
my $v = Dpkg::Version->new($version);
# The version in the .deb filename will not contain the epoch
$version = $v->as_string(omit_epoch => 1);
- my $deb_file = "${pkgname}_${version}_${packagearch}.deb";
+ my $debarch;
+ if ($packagearch eq "all") {
+ $debarch = "$buildarch";
+ } else {
+ $debarch = "$packagearch";
+ }
+ my $deb_file = "${pkgname}_${version}_${debarch}.deb";
my $buildinfo_file = "${pkgname}_${version}_${hostarch}.buildinfo";
my $changes_file = "${pkgname}_${version}_${hostarch}.changes";
return {
+ arch => $debarch,
package => $pkgname,
deb_file => $deb_file,
buildinfo_file => $buildinfo_file,



-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
DEBEMAIL=a...@me.com
DEBFULLNAME="Alexey Kuznetsov"

-- System Information:
Debian Release: 12.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-10-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages devscripts depends on:
ii dpkg-dev 1.21.22
ii fakeroot 1.31-1.2
ii file 1:5.44-3
ii gnupg 2.2.40-1.1
ii gpgv 2.2.40-1.1
ii libc6 2.36-9+deb12u1
ii libfile-dirlist-perl 0.05-3
ii libfile-homedir-perl 1.006-2
ii libfile-touch-perl 0.12-2
ii libfile-which-perl 1.27-2
ii libipc-run-perl 20220807.0-1
ii libmoo-perl 2.005005-1
ii libwww-perl 6.6

Bug#1051362: Bug is absent if file structure exist? initial data import)

2023-09-20 Thread Alexey G. Petrov
I have used version 3.6 from github and import some data. Then I have
started debain version 3.5 and all is work pretty good (and import of
data too). It's possible that there were problemv with creation dirs of
files in config or data directory.



Bug#1051362: goldencheetah: Crashes during initial data import

2023-09-06 Thread Alexey G. Petrov


Package: goldencheetah
Version: 1:3.5-1.1
Followup-For: Bug #981223


Dear Maintainer,

I have same problem. The  Golden Cheetah crashed repeatedly at the point just 
before it would
complete the import and switch to the main window.

I think that GDB backtrace can be useful

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (350, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (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 goldencheetah depends on:
ii  libc6  2.37-7
ii  libgcc-s1  13.2.0-3
ii  libical3   3.0.16-1+b1
ii  libkmlbase11.3.0-10
ii  libkmldom1 1.3.0-10
ii  libqt5bluetooth5   5.15.10-2
ii  libqt5charts5  5.15.10-2
ii  libqt5concurrent5  5.15.10+dfsg-3
ii  libqt5core5a   5.15.10+dfsg-3
ii  libqt5gui5 5.15.10+dfsg-3
ii  libqt5multimedia5  5.15.10-2
ii  libqt5network5 5.15.10+dfsg-3
ii  libqt5opengl5  5.15.10+dfsg-3
ii  libqt5serialport5  5.15.10-2
ii  libqt5sql5 5.15.10+dfsg-3
ii  libqt5sql5-sqlite  5.15.10+dfsg-3
ii  libqt5svg5 5.15.10-2
ii  libqt5webkit5  5.212.0~alpha4-33
ii  libqt5widgets5 5.15.10+dfsg-3
ii  libqt5xml5 5.15.10+dfsg-3
ii  libstdc++6 13.2.0-3
ii  libusb-0.1-4   2:0.1.12-32
ii  libvlc51:3.0.18-dmo9
ii  zlib1g 1:1.2.13.dfsg-3

goldencheetah recommends no packages.

goldencheetah suggests no packages.

-- no debconf information

GDB bt

Thread 1 "GoldenCheetah" received signal SIGSEGV, Segmentation fault.
QColor::operator= (this=this@entry=0x57545a08, color=...) at 
painting/qcolor.cpp:2932
Download failed: Недопустимый аргумент.  Continuing without source file 
./src/gui/painting/qcolor.cpp.  


   
2932painting/qcolor.cpp: Нет такого файла или каталога.
(gdb) bt
#0  QColor::operator=(QColor const&) (this=this@entry=0x57545a08, 
color=...) at painting/qcolor.cpp:2932
#1  0x557b191d in Card::setData(RideItem*) 
(this=this@entry=0x575458e0, item=0x0) at Charts/OverviewWindow.cpp:562
#2  0x557b3850 in OverviewWindow::rideSelected() (this=0x56bdaf20) 
at Charts/OverviewWindow.cpp:305
#3  0x736fb74d in doActivate(QObject*, int, void**) 
(sender=0x56bdaf20, signal_index=10, argv=0x7fffc510) at 
kernel/qobject.cpp:3937
#4  0x736f454f in QMetaObject::activate(QObject*, QMetaObject const*, 
int, void**) (sender=, m=m@entry=0x56711da0 
, local_signal_index=local_signal_index@entry=3, 
argv=argv@entry=0x7fffc510) at kernel/qobject.cpp:3985
#5  0x55d39262 in GcWindow::rideItemChanged(RideItem*) (this=, _t1=) at moc_GoldenCheetah.cpp:492
#6  0x55d3a9bb in GcWindow::qt_metacall(QMetaObject::Call, int, void**) 
(this=this@entry=0x56bdaf20, _c=_c@entry=QMetaObject::WriteProperty, _id=4, 
_a=_a@entry=0x7fffc610) at moc_GoldenCheetah.cpp:450
#7  0x55d3aa35 in GcChartWindow::qt_metacall(QMetaObject::Call, int, 
void**) (this=this@entry=0x56bdaf20, 
_c=_c@entry=QMetaObject::WriteProperty, _id=, 
_a=_a@entry=0x7fffc610) at moc_GoldenCheetah.cpp:662
#8  0x55d2e8c6 in OverviewWindow::qt_metacall(QMetaObject::Call, int, 
void**) (this=0x56bdaf20, _c=QMetaObject::WriteProperty, _id=, _a=0x7fffc610) at moc_OverviewWindow.cpp:578
#9  0x736d12ba in QMetaProperty::write(QObject*, QVariant const&) const 
(this=this@entry=0x7fffc6a0, object=object@entry=0x56bdaf20, value=...) 
at kernel/qmetaobject.cpp:3287
#10 0x736f9de8 in QObject::setProperty(char const*, QVariant const&) 
(this=this@entry=0x56bdaf20, name=name@entry=0x55e08041 "ride", 
value=...) at kernel/qobject.cpp:4109
#11 0x55867b82 in HomeWindow::tabSelected(int) 
(this=this@entry=0x56f4d2e0, index=index@entry=0) at 
Charts/HomeWindow.cpp:401
#12 0x55871422 in HomeWindow::restoreState(bool) 
(this=this@entry=0x56f4d2e0, useDefault=, 
useDefault@entry=false) at Charts/HomeWindow.cpp:1467
#13 0x55872042 in HomeWindow::selected() (this=0x56f4d2e0) at 
Charts/HomeWindow.cpp:301
#14 0x55b9833a in TabView::selectionChanged() (this=0x57635950) at 
Gui/TabView.h:57
#15 0x736fb74d in doActivate(QObject*, int, void**) 
(sender=0x577bd4b0, signal_index=20, argv=0x7fffcc40) at 
kernel/qobject.cpp:3937
#16 0x736f454f in QMetaObject::activate(QObject*, QMetaObject const*, 
int, void**) (sender=, m=m@entry=0x5671bd80 
, local_signal_index=local_

Bug#1051152: RFP: cli-visualizer -- console alasa/pipewire spectrum visualizer

2023-09-03 Thread Alexey Kuznetsov
Package: wnpp
Severity: wishlist

* Package name: cli-visualizer
  Version : 1.7
  Upstream Contact: Darby Payne
* URL : https://github.com/dpayne/cli-visualizer
* License : (MIT)
  Programming Lang: (C++)
  Description : console alasa/pipewire spectrum visualizer

Command line visualizer. Supports mpd, with experimental support for alsa and 
pulseaudio.



Bug#1032177: (no subject)

2023-08-18 Thread Alexey Kuznetsov

Try run

LD_DEBUG=libs

And tell us if you see any errors.

-- AK



Bug#984623: fixed 1.0.4

2023-04-14 Thread Alexey Kuznetsov

Fixed in 1.0.4

--
AK



Bug#1034107: RFP: xmpppy -- XMPP implementation in Python

2023-04-10 Thread Alexey Nezhdanov
Hi.

I wasn't maintaining the project for at least 12 years. But there are
indeed several people who move it forward. You might have better luck
contacting them on the GitHub issue tracker.

You might also consider doing the debian maintainer work (porting,
packaging, etc) yourself (as I did about 15 years ago). Finding someone
who'll upload the package for you is usually not a problem.

Best regards,
Alexey Nezhdanov.

‪Am So., 9. Apr. 2023 um 07:15 Uhr schrieb ‫أحمد المحمودي‬‎ <
aelmahmo...@users.sourceforge.net>:‬

> Package: wnpp
> Severity: wishlist
>
> * Package name: xmpppy
>   Version : 0.7.1
>   Upstream Author : Alexey Nezhdanov 
> * URL : https://github.com/xmpppy/xmpppy
> * License : GPL-3
>   Programming Lang: Python
>   Description : XMPP implementation in Python
> Python 2/3 implementation of XMPP (RFC3920, RFC3921).
> This is a set of modules providing functionality for writing
> XMPP-compliant clients or server components in Python.
> This library was initially designed as "rework" of jabberpy library but
> lately become a separate product.
> Unlike jabberpy it is distributed under the terms of GPL.
>
> This was previously removed from Debian (formerly python-xmpp) because
> it was no longer updated by upstream. Yet Alexey has continued
> maintaining it on GitHub, and has added Python3 support.
>
> At least the jabber weechat plugin (provided by weechat-scripts) uses
> it.
>
> --
> ‎أحمد المحمودي (Ahmed El-Mahmoudy)
>  Digital design engineer
> GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
> GPG Fingerprints:
>  6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
>  8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7
>


Bug#1031671: gnome-shell: Some applications always lose focus

2023-02-25 Thread Alexey Morsov
Package: mutter
Version: 43.3-3
Followup-For: Bug #1031671

Dear Maintainer,

After upgrading to 43.3 in sid after switching input (Super-space) after
overlay windows lose focus. Comnfirm with firefox, gedit, emacs, nautilus etc.

Upstream bug https://gitlab.gnome.org/GNOME/mutter/-/issues/2626


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

Kernel: Linux 6.1.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF8, LC_CTYPE=ru_RU.UTF8 (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 mutter depends on:
ii  adwaita-icon-theme43-1
ii  gnome-settings-daemon-common  43.0-4
ii  gsettings-desktop-schemas 43.0-1
ii  libc6 2.36-8
ii  libgles2  1.6.0-1
ii  libglib2.0-0  2.74.5-1
ii  libmutter-11-043.3-3
ii  libwayland-client01.21.0-1
ii  libx11-6  2:1.8.3-3
ii  libxcomposite11:0.4.5-1
ii  mutter-common 43.3-3
ii  zenity3.44.0-1

mutter recommends no packages.

Versions of packages mutter suggests:
ii  gnome-control-center  1:43.4.1-1
ii  xdg-user-dirs 0.18-1

-- no debconf information


signature.asc
Description: PGP signature


Bug#1027879: ITP: cri-o -- implementation of the Kubernetes CRI to enable using OCI compatible runtimes

2023-01-04 Thread Alexey Lukyachuk
Package: wnpp
Severity: wishlist

* Package name: cri-o
  Version : 1.26
  Upstream Author : Multiple Authors
* URL : https://cri-o.io/
* License : Apache 2.0
  Programming Lang: Golang
  Description : implementation of the Kubernetes CRI to enable using OCI 
compatible runtimes

Also I want to quatate RFP 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979702):

cri-o provides an alternate runtime to containerd to run pods and containers in 
Kubernetes.
cri-o provides the following avantages:
- lightweight, specifically target to kubernetes, so it has a clear 
compatibility matrix with k8s
- uses systemd by default as cgroup driver instead of cgroupfs, which is a 
better choice than 
cgroupfs when the init system is systemd (see 
https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cgroup-drivers)

FWIW cri-o is used as container runtime in the Suse and Red Hat Kubernetes 
offerings.

Upstream expressed interessed to have cri-o package in Debian, but in the end 
provided its own package
on the OpenSuse Build Service (having to unvendor the dependencies being the 
challenge)



Bug#1026086: -installed

2022-12-14 Thread Alexey Sitnikov
Also there is no reaction for "--installed":

# apt-cache depends --installed libdbus-1-3
libdbus-1-3
  Depends: libc6
  Depends: libsystemd0
*libelogind0*

# apt-cache policy  libelogind0
libelogind0:
*  Installed: (none)*
  Candidate: 246.9.1-1+debian1
  Version table:
 246.9.1-1+debian1 990
990 http://mirror.insacom.cl/debian bullseye/main amd64 Packages


Bug#1024260: apt: An easy way to install only security updates

2022-11-16 Thread Alexey Salmin
Package: apt
Version: 2.0.9
Severity: wishlist

Dear Maintainer,

Please provide an easy one-line way to only install security updates.
This scenario is essential for the docker images. People need the
security updates but not the bloated image from other updates.

There's an interest for this feature in the community [1][2]. Current
solutions are bulky which makes them less likely to be adopted. Most
people just stick to outdated base images and install no updates at all.
This is very unfortunate and not good for the security in general.

I see two way how this could be done in a general non-hacky way:
1) Support "Suite" filter as a command-line option in apt-get.
2) Provide a separate sources-security.list into the default install,
then users can pick it with the '-o Dir::Etc::SourceList' option.

I'm not sure about the option (1), but option (2) looks very simple and
nevertheless would greatly improve the availability of security updates.

[1] 
https://serverfault.com/questions/270260/how-do-you-use-apt-get-to-only-install-critical-security-updates-on-ubuntu
[2] 
https://askubuntu.com/questions/194/how-can-i-install-just-security-updates-from-the-command-line

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^postgresql-";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";
APT::Periodic::Unattended-Upgrade "1";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "touch 
/var/lib/apt/periodic/update-success-stamp 2>/dev/null || true";
APT::Update::Post-Invoke-Success:: "[ ! -f /var/run/dbus/system_bus_socket ] || 
/usr/bin/dbus-send --system --dest=org.debian.apt --type=signal /org/debian/apt 
org.debian.apt.CacheChanged || true";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null || true; 
fi";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w 
/var/lib/command-not-found/ -a -e /usr/lib/cnf-update-db; then 
/usr/lib/cnf-update-db > /dev/null; fi";
APT::Update::Post-Invoke-Success:: 
"/usr/lib/update-notifier/update-motd-updates-available 2>/dev/null || true";
APT::Update::Post-Invoke-Stats "";
APT::Update::Post-Invoke-Stats:: "[ ! -f /usr/lib/ubuntu-advantage/apt-esm-hook 
] || /usr/lib/ubuntu-advantage/apt-esm-hook post-invoke-stats || true";
APT::Install "";
APT::Install::Post-Invoke-Success "";
APT::Install::Post-Invoke-Success:: "[ ! -f 
/usr/lib/ubuntu-advantage/apt-esm-hook ] || 
/usr/lib/ubuntu-advantage/apt-esm-hook post-invoke-success || true";
APT::Install::Pre-Invoke "";
APT::Install::Pre-Invoke:: "[ ! -f /usr/lib/ubuntu-advantage/apt-esm-hook ] || 
/usr/lib/ubuntu-advantage/apt-esm-hook pre-invoke || true";
APT::Archives "";
APT::Archives::MaxAge "30";
APT::Archives::MinAge "2";
APT::Archives::MaxSize "500";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.

Bug#1023887: Acknowledgement (systemd:amd64 (252-2 -> 252.1-1) brakes suspend/resume)

2022-11-13 Thread Alexey Kuznetsov
Bug title should be renamed to * "suspend / resume"


Bug#1023887: Acknowledgement (systemd:amd64 (252-2 -> 252.1-1) brakes system/resume)

2022-11-11 Thread Alexey Kuznetsov
System info / logs

* http://linux-hardware.org/?probe=59aa7d31d8


Bug#1004308: smokeping: New upstream version 2.8.2 needs to be packaged

2022-10-15 Thread Alexey Vazhnov
Gabriel, please check 
https://salsa.debian.org/debian/smokeping/-/merge_requests/5

I think you should subscribe to notifications in 
https://salsa.debian.org/debian/smokeping (there is a "bell" button
with notification settings) to not miss another merge requests.

What is our next step (even without Nginx configuration file)?



Bug#1004308: smokeping: New upstream version 2.8.2 needs to be packaged

2022-09-17 Thread Alexey Vazhnov
I've tested Smokeping 2.8.2 in `Devuan GNU/Linux 5 (daedalus/ceres)` (based on 
Debian testing 12 bookworm), it works
without errors.

How to:

I created a .deb package in `Debian GNU/Linux 11 (bullseye)` by commands like 
these:

```
sudo apt-get -V --no-install-recommends install devscripts git-buildpackage 
equivs
gbp clone 'https://salsa.debian.org/debian/smokeping.git'
cd ./smokeping
mk-build-deps --install --root-cmd sudo --remove
git status
# Remove new untracked files:
rm smokeping-build-deps_2.8.2-1_amd64.buildinfo 
smokeping-build-deps_2.8.2-1_amd64.changes
gbp buildpackage
```

and installed `smokeping_2.8.2-1_all.deb` together with Nginx, I took 
configuration from
https://gitlab.com/vazhnov/smokeping_nginx

No `libobject-result-perl` installed, but Smokeping works!



Bug#1017426: libnss3: Uninitialised value was created by a stack allocation

2022-08-16 Thread Alexey Kuznetsov
On Tue, Aug 16, 2022 at 10:17 AM Mike Hommey  wrote:

> On Tue, Aug 16, 2022 at 09:59:30AM +0300, Alexey Kuznetsov wrote:
> > On Tue, Aug 16, 2022 at 9:50 AM Mike Hommey  wrote:
> >
> > > On Tue, Aug 16, 2022 at 09:06:20AM +0300, Alexey Kuznetsov wrote:
> > > > On Tue, Aug 16, 2022 at 9:00 AM Mike Hommey  wrote:
> > > >
> > > > > On Tue, Aug 16, 2022 at 08:30:07AM +0300, a...@me.com wrote:
> > > > > > Package: libnss3
> > > > > > Version: 2:3.79-1
> > > > > > Severity: normal
> > > > > >
> > > > > > Dear Maintainer,
> > > > > >
> > > > > > debuging valgrind pidgin with result:
> > > > > >
> > > > > > ==804198==  Uninitialised value was created by a stack allocation
> > > > > > ==804198==at 0xB089DC0: ssl3_MACEncryptRecord
> (ssl3con.c:2104)
> > > > > >
> > > > > > line correspopnds to the ssl3_MACEncryptRecord
> > > > >
> > > > > Looking at the code, it would seem to be a false positive, but I
> might
> > > > > have overlooked something, but you haven't pasted the most
> interesting
> > > > > parts of the valgrind output...
> > > > >
> > > > > Mike
> > > > >
> > > >
> > > > This output comes exactly from valgrind. No usual stack trace.
> Before and
> > > > below are different issues.
> > > >
> > > > BTW pidgin crashing sometimes, and only issues I can record points
> to the
> > > > nss library.
> > >
> > > Usually, "Uninitialised value was created by a stack allocation" is the
> > > reason for the error, with a stack trace, that comes above it. That's
> > > the most crucial information. Without that, we don't know what is
> trying
> > > to use that unitialized value.
> > >
> >
> >  Ok .Let me restart pidgin. It 100% reproducible. Only thing you need is
> to
> > install dbgsym for glibc, nss3, pidgin and add frew irc and jabber
> accounts
> > (I also using matrix plugin). Command would be:
> >
> > G_SLICE=always-malloc valgrind --num-callers=30 --track-origins=yes
> pidgin
> > 2>&1 | tee 123.log
> >
> > https://paste.debian.net/1250580/
>
> Can you reproduce with 3.81-1 in unstable?
>
> For posterity, the useful information:
>
> ==837133== Syscall param socketcall.sendto(msg) points to uninitialised
> byte(s)
> ==837133==at 0x5A153D6: __libc_send (send.c:28)
> ==837133==by 0x5A153D6: send (send.c:23)
> ==837133==by 0xB083527: pt_Send (ptio.c:2002)
> ==837133==by 0xB01DFF7: ssl_DefSend (ssldef.c:105)
> ==837133==by 0xB0229C0: ssl_SendSavedWriteData (sslsecur.c:452)
> ==837133==by 0xB006839: ssl3_SendRecord (ssl3con.c:2568)
> ==837133==by 0xB006C2C: ssl3_FlushHandshakeMessages (ssl3con.c:2774)
> ==837133==by 0xB006C2C: ssl3_FlushHandshake (ssl3con.c:2747)
> ==837133==by 0xB00F5E4: ssl3_SendFinished (ssl3con.c:11944)
> ==837133==by 0xB00FB79: ssl3_SendClientSecondRound (ssl3con.c:8191)
> ==837133==by 0xB011A7A: ssl3_HandleServerHelloDone (ssl3con.c:8061)
> ==837133==by 0xB011A7A: ssl3_HandlePostHelloHandshakeMessage
> (ssl3con.c:12568)
> ==837133==by 0xB011A7A: ssl3_HandleHandshakeMessage (ssl3con.c:12479)
> ==837133==by 0xB014A74: ssl3_HandleHandshake (ssl3con.c:12653)
> ==837133==by 0xB014A74: ssl3_HandleNonApplicationData (ssl3con.c:13188)
> ==837133==by 0xB0153C0: ssl3_HandleRecord (ssl3con.c:13529)
> ==837133==by 0xB01B500: ssl3_GatherCompleteHandshake (ssl3gthr.c:561)
> ==837133==by 0xB01B500: ssl3_GatherCompleteHandshake (ssl3gthr.c:449)
> ==837133==by 0xB022A80: SSL_ForceHandshake (sslsecur.c:382)
> ==837133==by 0xADCC8D6: ssl_nss_handshake_cb (ssl-nss.c:371)
> ==837133==by 0x1824B1: pidgin_io_invoke (gtkeventloop.c:73)
> ==837133==by 0x54BBA9E: g_main_dispatch (gmain.c:3417)
> ==837133==by 0x54BBA9E: g_main_context_dispatch (gmain.c:4135)
> ==837133==by 0x54BBE57: g_main_context_iterate.constprop.0
> (gmain.c:4211)
> ==837133==by 0x54BC10E: g_main_loop_run (gmain.c:4411)
> ==837133==by 0x4C57B29: gtk_main (in
> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.33)
> ==837133==by 0x145D7B: main (gtkmain.c:948)
> ==837133==  Address 0x1b82e246 is 534 bytes inside a block of size 1,553
> alloc'd
> ==837133==at 0x484582F: realloc (vg_replace_malloc.c:1437)
> ==837133==by 0xB2114A1: PORT_Realloc_Util (secport.c:101)
> ==837133==by 0xB01E1

Bug#1017426: libnss3: Uninitialised value was created by a stack allocation

2022-08-16 Thread Alexey Kuznetsov
On Tue, Aug 16, 2022 at 9:50 AM Mike Hommey  wrote:

> On Tue, Aug 16, 2022 at 09:06:20AM +0300, Alexey Kuznetsov wrote:
> > On Tue, Aug 16, 2022 at 9:00 AM Mike Hommey  wrote:
> >
> > > On Tue, Aug 16, 2022 at 08:30:07AM +0300, a...@me.com wrote:
> > > > Package: libnss3
> > > > Version: 2:3.79-1
> > > > Severity: normal
> > > >
> > > > Dear Maintainer,
> > > >
> > > > debuging valgrind pidgin with result:
> > > >
> > > > ==804198==  Uninitialised value was created by a stack allocation
> > > > ==804198==at 0xB089DC0: ssl3_MACEncryptRecord (ssl3con.c:2104)
> > > >
> > > > line correspopnds to the ssl3_MACEncryptRecord
> > >
> > > Looking at the code, it would seem to be a false positive, but I might
> > > have overlooked something, but you haven't pasted the most interesting
> > > parts of the valgrind output...
> > >
> > > Mike
> > >
> >
> > This output comes exactly from valgrind. No usual stack trace. Before and
> > below are different issues.
> >
> > BTW pidgin crashing sometimes, and only issues I can record points to the
> > nss library.
>
> Usually, "Uninitialised value was created by a stack allocation" is the
> reason for the error, with a stack trace, that comes above it. That's
> the most crucial information. Without that, we don't know what is trying
> to use that unitialized value.
>

 Ok .Let me restart pidgin. It 100% reproducible. Only thing you need is to
install dbgsym for glibc, nss3, pidgin and add frew irc and jabber accounts
(I also using matrix plugin). Command would be:

G_SLICE=always-malloc valgrind --num-callers=30 --track-origins=yes pidgin
2>&1 | tee 123.log

https://paste.debian.net/1250580/


Bug#1017426: libnss3: Uninitialised value was created by a stack allocation

2022-08-15 Thread Alexey Kuznetsov
On Tue, Aug 16, 2022 at 9:00 AM Mike Hommey  wrote:

> On Tue, Aug 16, 2022 at 08:30:07AM +0300, a...@me.com wrote:
> > Package: libnss3
> > Version: 2:3.79-1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > debuging valgrind pidgin with result:
> >
> > ==804198==  Uninitialised value was created by a stack allocation
> > ==804198==at 0xB089DC0: ssl3_MACEncryptRecord (ssl3con.c:2104)
> >
> > line correspopnds to the ssl3_MACEncryptRecord
>
> Looking at the code, it would seem to be a false positive, but I might
> have overlooked something, but you haven't pasted the most interesting
> parts of the valgrind output...
>
> Mike
>

This output comes exactly from valgrind. No usual stack trace. Before and
below are different issues.

BTW pidgin crashing sometimes, and only issues I can record points to the
nss library.


Bug#1010177: r8168-dkms: dkms build failed on kernel 5.17

2022-04-25 Thread Alexey Morsov
Package: r8168-dkms
Version: 8.049.02-1
Severity: grave
Tags: ftbfs
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

update linux-image to 5.17

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

apt full-upgrade

   * What was the outcome of this action?

r8168-dkms does not build for this version of kernel


   * What outcome did you expect instead?

working ethernet driver


dkms log

DKMS make.log for r8168-8.049.02 for kernel 5.17.0-1-amd64 (x86_64)
Пн 25 апр 2022 21:33:59 MSK
make: вход в каталог «/usr/src/linux-headers-5.17.0-1-amd64»
  CC [M]  /var/lib/dkms/r8168/8.049.02/build/r8168_n.o
  CC [M]  /var/lib/dkms/r8168/8.049.02/build/r8168_asf.o
  CC [M]  /var/lib/dkms/r8168/8.049.02/build/rtl_eeprom.o
  CC [M]  /var/lib/dkms/r8168/8.049.02/build/rtltool.o
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c: In function ‘rtl8168_proc_open’:
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:1736:50: error: implicit
declaration of function ‘PDE_DATA’; did you mean ‘NODE_DATA’?
[-Werror=implicit-function-declaration]
 1736 | int (*show)(struct seq_file *, void *) = PDE_DATA(inode);
  |  ^~~~
  |  NODE_DATA
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:1736:50: warning: initialization
of ‘int (*)(struct seq_file *, void *)’ from ‘int’ makes pointer from integer
without a cast [-Wint-conversion]
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c: In function
‘rtl8168_get_mac_address’:
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:24136:34: error: assignment of
read-only location ‘*(dev->dev_addr + (sizetype)i)’
24136 | dev->dev_addr[i] = RTL_R8(tp, MAC0 + i);
  |  ^
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c: In function
‘rtl8168_set_mac_address’:
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:24167:19: warning: passing
argument 1 of ‘memcpy’ discards ‘const’ qualifier from pointer target type
[-Wdiscarded-qualifiers]
24167 | memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
  |~~~^~
In file included from /usr/src/linux-
headers-5.17.0-1-common/include/linux/string.h:253,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/bitmap.h:11,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/cpumask.h:12,
 from /usr/src/linux-
headers-5.17.0-1-common/arch/x86/include/asm/cpumask.h:5,
 from /usr/src/linux-
headers-5.17.0-1-common/arch/x86/include/asm/msr.h:11,
 from /usr/src/linux-
headers-5.17.0-1-common/arch/x86/include/asm/processor.h:22,
 from /usr/src/linux-
headers-5.17.0-1-common/arch/x86/include/asm/timex.h:5,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/timex.h:65,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/time32.h:13,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/time.h:60,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/stat.h:19,
 from /usr/src/linux-
headers-5.17.0-1-common/include/linux/module.h:13,
 from /var/lib/dkms/r8168/8.049.02/build/r8168_n.c:43:
/usr/src/linux-headers-5.17.0-1-common/include/linux/fortify-string.h:212:37:
note: expected ‘void *’ but argument is of type ‘const unsigned char *’
  212 | __FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t
size)
  |   ~~^
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:24169:32: warning: passing
argument 2 of ‘rtl8168_rar_set’ discards ‘const’ qualifier from pointer target
type [-Wdiscarded-qualifiers]
24169 | rtl8168_rar_set(tp, dev->dev_addr);
  | ~~~^~
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:566:59: note: expected ‘uint8_t *’
{aka ‘unsigned char *’} but argument is of type ‘const unsigned char *’
  566 | void rtl8168_rar_set(struct rtl8168_private *tp, uint8_t *addr);
  |  ~^~~~
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c: In function ‘rtl8168_resume’:
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:28654:32: warning: passing
argument 2 of ‘rtl8168_rar_set’ discards ‘const’ qualifier from pointer target
type [-Wdiscarded-qualifiers]
28654 | rtl8168_rar_set(tp, dev->dev_addr);
  | ~~~^~
/var/lib/dkms/r8168/8.049.02/build/r8168_n.c:24184:26: note: expected ‘uint8_t
*’ {aka ‘unsigned char *’} but argument is of type ‘const unsigned char *’
24184 | uint8_t *addr)
  | ~^~~~
cc1: some warnings being treated as errors


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

Bug#995927: duplicate

2021-11-04 Thread Alexey Kuznetsov
Duplicate of:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982956

I have exactly the same issues and 'bisected' to the same problematic
commit you are referring to.

-- AK


Bug#982956: kernel bug report

2021-11-03 Thread Alexey Kuznetsov
Just created kernel bug report:

https://bugzilla.kernel.org/show_bug.cgi?id=214933

-- AK


Bug#982956: building recent kernel

2021-11-03 Thread Alexey Kuznetsov
Building a recent kernel without a bugous patch makes a working machine!

[v5.10.70] + [debian patches 5.10.70-1_bpo10+1] + [revert 69a74aef8]

Suspend / resume works!

-- AK


Bug#982956: git bisect report

2021-11-03 Thread Alexey Kuznetsov
git bisect pinpoint the following commit:


Bisecting: 0 revisions left to test after this (roughly 0 steps)
[69a74aef8a18eef20fb0044b5e164af41b84db21] e100: use generic power
management

Author: Vaibhav Gupta 
Date:   Mon Jun 29 14:59:43 2020 +0530

e100: use generic power management

With legacy PM hooks, it was the responsibility of a driver to manage
PCI
states and also the device's power state. The generic approach is to let
PCI core handle the work.

e100_suspend() calls __e100_shutdown() to perform intermediate tasks.
__e100_shutdown() calls pci_save_state() which is not recommended.

e100_suspend() also calls __e100_power_off() which is calling PCI helper
functions, pci_prepare_to_sleep(), pci_set_power_state(), along with
pci_wake_from_d3(...,false). Hence, the functin call is removed and wol
is
disabled as earlier using device_wakeup_disable().


Full git bisect log:


git bisect start
# good: [219d54332a09e8d8741c1e1982f5eae56099de85] Linux 5.4
git bisect good 219d54332a09e8d8741c1e1982f5eae56099de85
# bad: [841fca5a32cccd7d0123c0271f4350161ada5507] Linux 5.10.1
git bisect bad f12366d9f172c4fc84cd114801b87588cb663074
# good: [219d54332a09e8d8741c1e1982f5eae56099de85] Linux 5.4
git bisect good 219d54332a09e8d8741c1e1982f5eae56099de85
# good: [bce159d734091fe31340976081577333f52a85e4] Merge tag
'for-5.8/drivers-2020-06-01' of git://git.kernel.dk/linux-block
git bisect good bce159d734091fe31340976081577333f52a85e4
# bad: [fbc1ac9d09d70859eee24131d667e01e3986e368] tools/cgroup: add
memcg_slabinfo.py tool
git bisect bad fbc1ac9d09d70859eee24131d667e01e3986e368
# good: [a5c6a1f0fe1d182489864b708fa472d0333b39d4] Merge branch
'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
git bisect good a5c6a1f0fe1d182489864b708fa472d0333b39d4
# good: [ecfd7940b8641da6e41ca94eba36876dc2ba827b] Merge tag 'usb-5.9-rc1'
of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
git bisect good ecfd7940b8641da6e41ca94eba36876dc2ba827b
# bad: [c1055b76ad00aed0e8b79417080f212d736246b6] net: thunderx: initialize
VF's mailbox mutex before first usage
git bisect bad c1055b76ad00aed0e8b79417080f212d736246b6
# good: [9b7b0d1a395d54c12be9f18d1bf7be06aecaa785] sctp: pass a kernel
pointer to sctp_setsockopt_peer_addr_params
git bisect good 9b7b0d1a395d54c12be9f18d1bf7be06aecaa785
# good: [1d8e5b0f3f2c6d05697f8192aac7255e6be1e715] net: stmmac: Support WOL
with phy
git bisect good 1d8e5b0f3f2c6d05697f8192aac7255e6be1e715
# bad: [99f47abd9f7bf6e365820d355dc98f6955a562df] fsl/fman: use 32-bit
unsigned integer
git bisect bad 99f47abd9f7bf6e365820d355dc98f6955a562df
# good: [4bb540dbe442ec5e4b48af8aed12663e0754bbe2] Merge branch
'for-upstream' of git://
git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
git bisect good 4bb540dbe442ec5e4b48af8aed12663e0754bbe2
# bad: [6f3de75cdf60c1b859bc8c1904d25889c00d7bbe] Merge tag
'mac80211-next-for-davem-2020-07-31' of git://
git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
git bisect bad 6f3de75cdf60c1b859bc8c1904d25889c00d7bbe
# bad: [c6886957d2d959d5217994cd08d59c816fc23e70] Merge branch '1GbE' of
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue
git bisect bad c6886957d2d959d5217994cd08d59c816fc23e70
# bad: [c6886957d2d959d5217994cd08d59c816fc23e70] Merge branch '1GbE' of
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue
git bisect bad c6886957d2d959d5217994cd08d59c816fc23e70
# bad: [c6886957d2d959d5217994cd08d59c816fc23e70] Merge branch '1GbE' of
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue
git bisect bad c6886957d2d959d5217994cd08d59c816fc23e70
# good: [6fc8c827dd4fa615965c4eac9bbfd465f6eb8fb4] tcp: syncookies: create
mptcp request socket for ACK cookies with MPTCP option
git bisect good 6fc8c827dd4fa615965c4eac9bbfd465f6eb8fb4
# bad: [90105264a60d39f7a332b7acfe8038c2a01e1ae2] igb: Remove unnecessary
usages of memset
git bisect bad 90105264a60d39f7a332b7acfe8038c2a01e1ae2
# good: [bac66317284350176b087ac44b0e4266770a659e] ixgbevf: use generic
power management
git bisect good bac66317284350176b087ac44b0e4266770a659e
# bad: [4b6bafb9e1d4d1eb16df0942abf455726c88c811] e1000: Remove unnecessary
usages of memset
git bisect bad 4b6bafb9e1d4d1eb16df0942abf455726c88c811


Related 'git bisect' bug report:

  *
https://lore.kernel.org/git/163b01f2-ddc0-c551-5462-e8f80fb7c...@gmail.com/T/#u


-- AK


Bug#982956: next report

2021-10-31 Thread Alexey Kuznetsov
I've tested following:

v5.0.2
v5.2.17
v5.3.15
v5.4.19

with debian patches applied, and compiled for Pentium M CPU - suspend /
resume working fine!

compiling:

v5.10.70
v5.10.1

makes 'task blocked for..." appear. Seems like this is 5.10 kernel issue.

I'm trying kernel git 'bisect' for the first time, to find the exact bug
causing this issue. Wish me luck!

-- AK


Bug#980963: in package dpkg marked as pending

2021-10-25 Thread Alexey Brodkin
Hi Guillem,

On Thu, 03 Jun 2021 06:47:23 +0200 Guillem Jover  wrote:
> Bug #980963 in package dpkg reported by you has been fixed in
> the dpkg/dpkg.git Git repository. You can see the changelog below, and
> you can check the diff of the fix at:
> 
> https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=0d134cdcb
> 
> ---
> arch: Add support for ARCv2 CPU
> 
> This is based on the ARCv2 32-bit little-endian hard-float ISA.
> 
> Closes: #980963
> Based-on-patch-by: Alexey Brodkin 
> 

Just a polite reminder. It would be really great to get a new upload of dpkg
so that we may finally start adding ARC bits in pieces in other packages.

Regards,
Alexey


Bug#995195:

2021-10-01 Thread Alexey Brodkin
Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=28408


Bug#982956: next report

2021-09-30 Thread Alexey Kuznetsov
I checked again vmlinuz-4.19.0-14-686 kernel and it works fine. Note sure
why it failed back then (maybe my mistake). But all recent kernels from
'bullseye', 'bookworm' and 'sid' failed. Last tested from 'bookworm' failed:

linux-image-5.14.0-1-686_5.14.6-2_i386.deb

-- AK


Bug#989442: [Pkg-openssl-devel] Bug#989442: Debian: openssl: Add ARC target

2021-09-20 Thread Alexey Brodkin
Hi Sebastian,

On Mon, 30 Aug 2021 21:12:57 +0200 Sebastian Andrzej Siewior 
 wrote: 
> control: found -1 1.1.1g-1 
> control: tags -1 + pending 
> 
> On 2021-08-30 19:30:07 [+0200], To Alexey Brodkin wrote: 
> > On 2021-08-30 16:37:11 [+], Alexey Brodkin wrote: 
> > > On Thu, 3 Jun 2021 19:14:24 + Vineet Gupta 
> > >  wrote: 
> > > > This is needed to bootstrap arc port. 
> > > > Patch attached. 
> > > 
> > > Ping! 
> > 
> > Urgh. Sorry, thanks for the ping. 
> 
> I pushed it to the unstable/experimental branch so it will be part of 
> the next upload. 
>  https://salsa.debian.org/debian/openssl/-/commits/debian/unstable 
>  https://salsa.debian.org/debian/openssl/-/commits/debian/experimental 
> 
> Feel free to yell if something ain't right. 

I hate to say it, but there's something subtly wrong 😉
It was ARC (which used to mean "Argonaut RISC core") but not AVR 32.

>   * Add avr32, patch by Vineet Gupta (Closes: #989442).

-Alexey



Bug#994473:

2021-09-16 Thread Alexey Brodkin
Suggested fix is available in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994287


Bug#994172: patch, did't work

2021-09-16 Thread Alexey Kuznetsov
My guess was to limit the memory map returned by e820 by size of 20M
manually. So, I did patch grub source code with following:


diff --git a/grub-core/kern/i386/pc/mmap.old b/grub-core/kern/i386/pc/mmap.c
index c0c3c35..0eb76d9 100644
--- a/grub-core/kern/i386/pc/mmap.old
+++ b/grub-core/kern/i386/pc/mmap.c
@@ -134,6 +134,10 @@ grub_get_mmap_entry (struct grub_machine_mmap_entry
*entry,
   else
 entry->size = regs.ecx;

+  if (entry->addr == 0x0010) {
+entry->len -= 0x134;
+  }
+
   /* return the continuation value */
   return regs.ebx;
 }


But that did not succeed. Grub still works slowly. Does anyone know why
kernel with 'mem=2020M' argument works fast, and the same memory map does
not fix grub 'slow down' issue?

-- AK


Bug#994402: binutils-source: Re-enable building of ARC cross-binutils

2021-09-15 Thread Alexey Brodkin
Package: binutils-source
Version: 2.37-6
Severity: normal
Tags: patch

Dear Maintainer,

W/o newer dpkg we cannot correctly build cross-Binutils for ARC
as target architecture won't be recognized. And so we disabled it
with [1]. And once new dpkg gets uploaded we're ready to re-enable this one
with a patch below.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994287

-Alexey

--->8---
--- a/debian/rules
+++ b/debian/rules
@@ -116,14 +116,11 @@
 install_binary = install -m 755 -s --strip-program="$(STRIP)"
 
 NATIVE_ARCHS ?= amd64 i386 arm64 armhf armel ppc64el s390x
-NATIVE_ARCHS += alpha hppa ia64 m68k powerpc ppc64 \
+NATIVE_ARCHS += alpha arc hppa ia64 m68k powerpc ppc64 \
riscv64 sh4 sparc64 x32
 NATIVE_ARCHS += hurd-i386 kfreebsd-amd64 kfreebsd-i386
 #NATIVE_ARCHS += nios2 or1k s390 sparc
 
-# Once dpkg with ARC support is uploaded, add "arc" as well
-#NATIVE_ARCHS += arc
-
 # don't generate the control file entries for native packages which are never
 # built. Only valid for Ubuntu. The autopkg testers get confused otherwise
 ifneq ($(distribution)-$(CROSS_ARCHS),Ubuntu-)
@@ -140,12 +137,10 @@
 # DEB_HOST_ARCH is filtered-out later anyway, do not test here.
 CROSS_ARCHS ?= amd64 i386 x32 \
s390x ppc64el arm64 armhf armel \
-   alpha hppa m68k \
+   alpha arc hppa m68k \
powerpc ppc64 sh4 sparc64 \
ia64 riscv64 \
kfreebsd-amd64 kfreebsd-i386 hurd-i386
-# Once dpkg with ARC support is uploaded, add "arc" as well
-#  arc
   else ifeq ($(DEB_HOST_ARCH),arm64)
 CROSS_ARCHS ?= amd64 armel armhf i386 ppc64el riscv64 s390x x32
   else ifeq ($(DEB_HOST_ARCH),ppc64)
--->8---


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages binutils-source depends on:
ii  make4.2.1-1.2
ii  python3 3.8.2-0ubuntu2
ii  texinfo 6.7.0.dfsg.2-5
ii  zlib1g-dev  1:1.2.11.dfsg-2ubuntu1.2

binutils-source recommends no packages.

binutils-source suggests no packages.



Bug#994287: binutils-source: Disable building cross-binutils for ARC until dpkg upload

2021-09-15 Thread Alexey Brodkin
Package: binutils-source
Version: 2.37-6
Severity: normal
Tags: patch

Dear Maintainer,

ARC support introduced via [1] enabled builds of cross-binutils
for ARC, but with older dpkg which doesn't know ARC architecture
it leads to buold failures see [2].

Let's disable building of cross-binutils for ARC until dpkg with
so much needed fix [3], [4] gets uploaded.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994190
[2] https://buildd.debian.org/status/logs.php?pkg=binutils&ver=2.37-6&arch=all
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980963
[4] 
https://salsa.debian.org/dpkg-team/dpkg/-/commit/0d134cdcb0dcc6b21fa7926964c1426a5821181d

-Alexey

>8
--- a/debian/rules
+++ b/debian/rules
@@ -119,7 +119,10 @@
 NATIVE_ARCHS += alpha hppa ia64 m68k powerpc ppc64 \
riscv64 sh4 sparc64 x32
 NATIVE_ARCHS += hurd-i386 kfreebsd-amd64 kfreebsd-i386
-#NATIVE_ARCHS += arc nios2 or1k s390 sparc
+#NATIVE_ARCHS += nios2 or1k s390 sparc
+
+# Once dpkg with ARC support is uploaded, add "arc" as well
+#NATIVE_ARCHS += arc
 
 # don't generate the control file entries for native packages which are never
 # built. Only valid for Ubuntu. The autopkg testers get confused otherwise
@@ -137,10 +140,12 @@
 # DEB_HOST_ARCH is filtered-out later anyway, do not test here.
 CROSS_ARCHS ?= amd64 i386 x32 \
s390x ppc64el arm64 armhf armel \
-   alpha arc hppa m68k \
+   alpha hppa m68k \
powerpc ppc64 sh4 sparc64 \
ia64 riscv64 \
kfreebsd-amd64 kfreebsd-i386 hurd-i386
+# Once dpkg with ARC support is uploaded, add "arc" as well
+#  arc
   else ifeq ($(DEB_HOST_ARCH),arm64)
 CROSS_ARCHS ?= amd64 armel armhf i386 ppc64el riscv64 s390x x32
   else ifeq ($(DEB_HOST_ARCH),ppc64)
>8

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages binutils-source depends on:
ii  make4.2.1-1.2
ii  python3 3.8.2-0ubuntu2
ii  texinfo 6.7.0.dfsg.2-5
ii  zlib1g-dev  1:1.2.11.dfsg-2ubuntu1.2

binutils-source recommends no packages.

binutils-source suggests no packages.



Bug#994211: libgc-source: Add ARC support

2021-09-13 Thread Alexey Brodkin
Package: libgc-source
Version: 8.0.4-3
Severity: normal
Tags: patch

Dear Maintainer,

Dear Maintainer,

Please consider adding support of ARC architecture with
a patch below. It's a back-port of upstream change [1]
which will be a part of the next release whenever it happens.

This is needed as we work on a Debian port for ARCprocessors.

[1] 
https://github.com/ivmai/bdwgc/commit/968818a12c361a3a7fa6e8d8b851d04847335e58

-Alexey

--- a/include/private/gcconfig.h
+++ b/include/private/gcconfig.h
@@ -658,6 +658,10 @@ EXTERN_C_BEGIN
 #   define NONSTOP
 #   define mach_type_known
 # endif
+# if defined(__arc__) && defined(LINUX)
+#   define ARC
+#   define mach_type_known
+# endif
 # if defined(__hexagon__) && defined(LINUX)
 #define HEXAGON
 #define mach_type_known
@@ -2812,6 +2816,21 @@ EXTERN_C_BEGIN
 #   endif
 # endif /* X86_64 */
 
+# ifdef ARC
+#   define CPP_WORDSZ 32
+#   define MACH_TYPE "ARC"
+#   define ALIGNMENT 4
+#   define CACHE_LINE_SIZE 64
+#   ifdef LINUX
+# define OS_TYPE "LINUX"
+# define LINUX_STACKBOTTOM
+# define COUNT_UNMAPPED_REGIONS
+# define DYNAMIC_LOADING
+  extern int __data_start[] __attribute__((__weak__));
+# define DATASTART ((ptr_t)__data_start)
+#   endif
+# endif /* ARC */
+
 # ifdef HEXAGON
 #   define CPP_WORDSZ 32
 #   define MACH_TYPE "HEXAGON"

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect



Bug#994175: duplicate

2021-09-13 Thread Alexey Kuznetsov
duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994172

-- AK


Bug#994190: binutils-source: Add ARC support

2021-09-13 Thread Alexey Brodkin
Package: binutils-source
Version: 2.37-5
Severity: normal
Tags: patch

Dear Maintainer,

Even though ARC architecture is long supported in upstream Binutils,
we need to exaplicitly set default target configuration which
will match GCC [1] & our expectation in Debian based on discussion here [2].

And while at it let's add Binutils for ARC to available cross-tools.

Both items should be solved with a patch below.

Alexey

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989453
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980963

>8
diff --git a/debian/rules b/debian/rules
index 45187fb..cc6342b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -135,7 +135,7 @@ ifeq ($(DEB_SOURCE),binutils)
   same_source  = yes
   ifneq (,$(filter $(DEB_HOST_ARCH), amd64 i386 x32))
 # DEB_HOST_ARCH is filtered-out later anyway, do not test here.
-CROSS_ARCHS ?= amd64 i386 x32 \
+CROSS_ARCHS ?= amd64 arc i386 x32 \
s390x ppc64el arm64 armhf armel \
alpha hppa m68k \
powerpc ppc64 sh4 sparc64 \
@@ -182,6 +182,7 @@ ifneq (,$(ADT_TEST_TRIGGERS))
 endif
 endif

+HOST_ARCHS_arc = amd64 i386 x32 arm64 ppc64el
 HOST_ARCHS_armhf = amd64 i386 x32 arm64 ppc64el
 HOST_ARCHS_armel = amd64 i386 x32 arm64 ppc64el
 HOST_ARCHS_arm64 = amd64 i386 x32 ppc64el
@@ -480,6 +481,8 @@ SET_MULTIARCH_ENV = \
$(if 
$(DEB_TARGET_MULTIARCHX32_$1),DEB_TARGET_MULTIARCHX32=$(DEB_TARGET_MULTIARCHX32_$1))
 \
$(if 
$(DEB_TARGET_MULTIARCHN32_$1),DEB_TARGET_MULTIARCHN32=$(DEB_TARGET_MULTIARCHN32_$1))

+CONFARGS_TARGET_arc= --with-cpu=hs38_linux
+
 CONFARGS_TARGET_sparc  = --enable-targets=sparc64-linux-gnu
 CONFLICTS_TARGET_sparc = -VextraConflicts="libc6-dev-sparc64 (<< 
2.2.5-7)"
>8



-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages binutils-source depends on:
ii  make4.2.1-1.2
ii  python3 3.8.2-0ubuntu2
ii  texinfo 6.7.0.dfsg.2-5
ii  zlib1g-dev  1:1.2.11.dfsg-2ubuntu1.2

binutils-source recommends no packages.

binutils-source suggests no packages.



Bug#994175: bios and efi tests

2021-09-13 Thread Alexey Kuznetsov
I've tested my second laptop with grub in bios and efi modes.

Grub2 with bios boot also fails to use 'cutmem' command with 'overflow
detected'.

Same region under efi boot more works fine!

It is possible here is a cutmem bug under bios boot mode.

-- AK


Bug#994172: grub2 cutmem not working propertly

2021-09-13 Thread Alexey Kuznetsov
Package: grub2
Version: 2.04-20
Severity: normal

Dear Maintainer,

Hello!

My old notebook has memory issues and requires to cut last 20M memory
region to work propertly (no matter how much installed 1G or 2G I had to
cut last 20M)

>From kernel perspective it looks like this:

[ 0.00] BIOS-provided physical RAM map:
[ 0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[ 0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[ 0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[ 0.00] BIOS-e820: [mem 0x0010-0x7f73] usable
[ 0.00] BIOS-e820: [mem 0x7f74-0x7f74] ACPI data
[ 0.00] BIOS-e820: [mem 0x7f75-0x7f7f] ACPI NVS
[ 0.00] e820: remove [mem 0x7e40-0xfffe] usable
[ 0.00] Notice: NX (Execute Disable) protection missing in CPU!
[ 0.00] user-defined physical RAM map:
[ 0.00] user: [mem 0x-0x0009fbff] usable
[ 0.00] user: [mem 0x0009fc00-0x0009] reserved
[ 0.00] user: [mem 0x000e-0x000f] reserved
[ 0.00] user: [mem 0x0010-0x7e3f] usable
[ 0.00] user: [mem 0x7f74-0x7f74] ACPI data
[ 0.00] user: [mem 0x7f75-0x7f7f] ACPI NVS

If this region is not removed my notebook works SUPER slow and every
click takes few seconds to process. Same affects grub2. If region in use
grub2 takes 2 minutes to boot into kernel. I recorded youtube video:

https://youtu.be/BlTii6QL5oY

I know grub2 has a 'cutmem' command which is not working propertly. When
I issue a:

'cutmem 0x7e4 0x7f73'

grub2 reports no change in 'lsmmap' output, which is not correct! I
tested 'cutmem' on my second notebook with efi loader, and cutmem
affects 'lsmmap' output with 'BADRAM regions' printed out.

fast logs:

https://linux-hardware.org/?probe=59b41381ed

slow logs:

https://linux-hardware.org/?probe=28a5b48a05

'grub-legacy' works fine, no slow downs!

I report it on grub2 bug tracker with no response:

https://savannah.gnu.org/bugs/index.php?61148


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda1 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/loop0 /snap/core/11609 squashfs ro,nodev,relatime 0 0
/dev/loop4 /snap/librepcb/516 squashfs ro,nodev,relatime 0 0
/dev/loop2 /snap/core18/2123 squashfs ro,nodev,relatime 0 0
/dev/loop1 /snap/core/11422 squashfs ro,nodev,relatime 0 0
/dev/loop3 /snap/core18/2069 squashfs ro,nodev,relatime 0 0
/dev/loop6 /snap/openscad/112 squashfs ro,nodev,relatime 0 0
/dev/loop5 /snap/librepcb/272 squashfs ro,nodev,relatime 0 0
/dev/loop7 /snap/openscad/133 squashfs ro,nodev,relatime 0 0
/dev/loop8 /snap/snapd/12881 squashfs ro,nodev,relatime 0 0
/dev/loop9 /snap/snapd/12706 squashfs ro,nodev,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0) /dev/disk/by-id/ata-FUJITSU_MHV2120AH_NT59T7C2S0BV
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="4"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi

function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}

if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint-ieee1275='ieee1275//disk@0,msdos1' --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'
8a9a2822-70c7-45c0-a01b-379c952d190d
else
search --no-floppy --fs-uuid --set=root 8a9a2822-70c7-45c0-a01b-379c952d190d
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the t

Bug#982956: linux-image-5.13.0-trunk-686 (5.13.12-1~exp1)

2021-09-12 Thread Alexey Kuznetsov
I've tested suspend / resume with 'linux-image-5.13.0-trunk-686
(5.13.12-1~exp1)' - not working!

Kernel freezes with the same error. Full logs at:

https://linux-hardware.org/?probe=04307947ae

(dmesg.1 logs for 'task blocked')

I'm using Debian 11 clean installation with Debian 10 kernel (Buster,
linux-image-4.19.0-17-686). Same configuration Debian 11 with
'linux-image-5.13.0-trunk-686 (5.13.12-1~exp1)' from experimental for
testing.

-- AK


Bug#993893: libxcrypt-source: Update symbols for ARC to match its real glibc minver 2.32

2021-09-07 Thread Alexey Brodkin
Package: libxcrypt-source
Version: 4.4.25-2
Severity: normal
Tags: patch
Usertags: rebootstrap

Dear Maintainer,

In 4.4.25-2 version ARC symbols were added,
but since before very recenly we used back-ported glibc 2.31 for ARC
those aforementioned symbols were generated while building with glibc 2.31.

But now glibc 2.32 is available in Unstable and moreover it's
set as a "minver" for ARC, see [1] we need to update ARC symbols.
Otherwise on libxcrypt building 2.32-based symbols get reported as missing.

[1] https://salsa.debian.org/md/libxcrypt/-/blob/master/lib/libcrypt.minver#L63

Please pardon me that extra noise, but I'm still ramping-up on Debian stuff
and keep making stupid mistakes here and there.

Below is a diff against 4.4.25-2:
-->8
diff --git a/debian/libcrypt1.symbols.arc b/debian/libcrypt1.symbols.arc
index 4a22dd3..ebbbc05 100644
--- a/debian/libcrypt1.symbols.arc
+++ b/debian/libcrypt1.symbols.arc
@@ -1,10 +1,10 @@
 libcrypt.so.1 libcrypt1 #MINVER#
 #include "libcrypt1.symbols.common"
- GLIBC_2.31@GLIBC_2.31 1:4.1.0
- crypt@GLIBC_2.31 1:4.1.0
- crypt_r@GLIBC_2.31 1:4.1.0
- encrypt@GLIBC_2.31 1:4.1.0
- encrypt_r@GLIBC_2.31 1:4.1.0
- fcrypt@GLIBC_2.31 1:4.1.0
- setkey@GLIBC_2.31 1:4.1.0
- setkey_r@GLIBC_2.31 1:4.1.0
+ GLIBC_2.32@GLIBC_2.32 1:4.4.25
+ crypt@GLIBC_2.32 1:4.4.25
+ crypt_r@GLIBC_2.32 1:4.4.25
+ encrypt@GLIBC_2.32 1:4.4.25
+ encrypt_r@GLIBC_2.32 1:4.4.25
+ fcrypt@GLIBC_2.32 1:4.4.25
+ setkey@GLIBC_2.32 1:4.4.25
+ setkey_r@GLIBC_2.32 1:4.4.25
-->8


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect



Bug#993786: gcc-defaults-ports: Please add cross-compilers for ARC

2021-09-06 Thread Alexey Brodkin
Source: gcc-defaults-ports
Version: 1.190
Severity: normal
Tags: patch

Dear Maintainer,

Now when we work on Debian port for ARC processors it's very handy to have
a cross-compiler and ideally crossbuild-essential for ARC.

Please refer to the following patch which adds ARC to the list of
generated cross-compilers.

-Alexey

diff --git a/debian/rules b/debian/rules
index 57c332e..a4102c6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -208,12 +208,12 @@ ifneq (,$(filter $(DEB_HOST_ARCH), i386 kfreebsd-i386 
hurd-i386))
 endif
 DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

-all_archs  = alpha amd64 armel armhf arm64 hppa i386 ia64 m68k mipsel mips64 
mips64el or1k powerpc powerpcspe ppc64 ppc64el riscv64 s390 s390x sh4 sparc 
sparc64 x32 hurd-i386 kfreebsd-amd64 kfreebsd-i386
+all_archs  = alpha amd64 arc armel armhf arm64 hppa i386 ia64 m68k mipsel 
mips64 mips64el or1k powerpc powerpcspe ppc64 ppc64el riscv64 s390 s390x sh4 
sparc sparc64 x32 hurd-i386 kfreebsd-amd64 kfreebsd-i386

 gcc9_archs = powerpcspe
-gcc10_archs  = alpha amd64 armel armhf arm64 hppa i386 ia64 m68k mipsel mips64 
mips64el or1k powerpc ppc64 ppc64el riscv64 s390 s390x sh4 sparc sparc64 x32 
hurd-i386 kfreebsd-amd64 kfreebsd-i386
+gcc10_archs  = alpha amd64 arc armel armhf arm64 hppa i386 ia64 m68k mipsel 
mips64 mips64el or1k powerpc ppc64 ppc64el riscv64 s390 s390x sh4 sparc sparc64 
x32 hurd-i386 kfreebsd-amd64 kfreebsd-i386

-gnat_archs  = alpha amd64 armel armhf arm64 hppa i386 ia64 m68k mipsel mips64 
mips64el or1k powerpc powerpcspe ppc64 ppc64el s390 s390x sh4 sparc sparc64 x32 
hurd-i386 kfreebsd-amd64 kfreebsd-i386
+gnat_archs  = alpha amd64 arc armel armhf arm64 hppa i386 ia64 m68k mipsel 
mips64 mips64el or1k powerpc powerpcspe ppc64 ppc64el s390 s390x sh4 sparc 
sparc64 x32 hurd-i386 kfreebsd-amd64 kfreebsd-i386
 gnat9_archs  =

 # CV_XXX is the complete version number, including the release, without epoch
@@ -321,7 +321,7 @@ go_multilib_archs = $(filter $(go_archs), $(filter-out 
armel armhf, $(multilib_a

 d_multilib_archs = $(filter-out armel, $(multilib_archs))

-ada_archs = alpha amd64 arm64 armel armhf hppa i386 ia64 m68k \
+ada_archs = alpha amd64 arc arm64 armel armhf hppa i386 ia64 m68k \
mips64 mipsel mips64el mipsn32 mipsn32el \
mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el \
powerpc ppc64 ppc64el riscv64 s390 s390x sh4 sparc sparc64 \
@@ -344,6 +344,7 @@ m2_archs = alpha amd64 arm64 armel armhf i386 ia64 \

 HOST_ARCHS_alpha = amd64 i386 x32
 HOST_ARCHS_amd64 = arm64 i386 ppc64el x32
+HOST_ARCHS_arc = amd64 i386 x32
 HOST_ARCHS_armhf = amd64 i386 x32 arm64 ppc64el
 HOST_ARCHS_armel = amd64 i386 x32 arm64 ppc64el
 HOST_ARCHS_arm64 = amd64 i386 x32 ppc64el
@@ -393,7 +394,7 @@ ifeq (,$(CROSS_ARCHS))
 endif
   else # -ports package
 ifneq (,$(filter $(DEB_HOST_ARCH),amd64 i386 x32))
-  CROSS_ARCHS  ?= alpha hppa m68k ppc64 riscv64 sh4 sparc64 \
+  CROSS_ARCHS  ?= alpha arc hppa m68k ppc64 riscv64 sh4 sparc64 \
$(if $(filter $(vendor), Ubuntu),, powerpc) \
$(if $(filter $(DEB_HOST_ARCH), amd64 i386), x32)
 else ifeq ($(DEB_HOST_ARCH),arm64)

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect



Bug#993466: libxcrypt-source: Add symbols for ARC

2021-09-01 Thread Alexey Brodkin
Package: libxcrypt-source
Version: 4.4.25-1
Severity: normal
Tags: patch
Usertags: rebootstrap

libxcrypt fails to build for ARC because of missing symbols.
Please consider including the following symbols file:

$ cat debian/libcrypt1.symbols.arc
libcrypt.so.1 libcrypt1 #MINVER#
#include "libcrypt1.symbols.common"
 GLIBC_2.31@GLIBC_2.31 1:4.1.0
 crypt@GLIBC_2.31 1:4.1.0
 crypt_r@GLIBC_2.31 1:4.1.0
 encrypt@GLIBC_2.31 1:4.1.0
 encrypt_r@GLIBC_2.31 1:4.1.0
 fcrypt@GLIBC_2.31 1:4.1.0
 setkey@GLIBC_2.31 1:4.1.0
 setkey_r@GLIBC_2.31 1:4.1.0
$

-Alexey

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect



Bug#992091: python3.9: Add arc-linux-gnu triplet

2021-08-30 Thread Alexey Brodkin
Hello!

On Wed, 11 Aug 2021 15:34:09 +0300 Alexey Brodkin  
wrote: 
> Source: python3.9 
> Severity: normal 
> Tags: patch upstream 
> 
> Dear Maintainer, 
> 
> There's a new triplet for ARCv2 processors "arc-linux-gnu" 
> defined here https://wiki.debian.org/Multiarch/Tuples. 
> 
> With addition of this triplet to Python3 it becomes buildable for ARC. 
> Attaching a simple diff that implements proposed change. 

Gentle reminder - This is needed for Debian port for ARC.

-Alexey



Bug#989442: Debian: openssl: Add ARC target

2021-08-30 Thread Alexey Brodkin
On Thu, 3 Jun 2021 19:14:24 + Vineet Gupta  
wrote: 
> Source: openssl 
> Severity: normal 
> Tags: patch 
> 
> Hi, 
> 
> This is needed to bootstrap arc port. 
> Patch attached. 

Ping!

-Alexey



Bug#992091: python3.9: Add arc-linux-gnu triplet

2021-08-30 Thread Alexey Brodkin
On Wed, 11 Aug 2021 15:34:09 +0300 Alexey Brodkin  
wrote: 
> Source: python3.9 
> Severity: normal 
> Tags: patch upstream 
> 
> Dear Maintainer, 
> 
> There's a new triplet for ARCv2 processors "arc-linux-gnu" 
> defined here https://wiki.debian.org/Multiarch/Tuples. 
> 
> With addition of this triplet to Python3 it becomes buildable for ARC. 
> Attaching a simple diff that implements proposed change. 
> 
> -- System Information: 
> Debian Release: bullseye/sid 
>   APT prefers focal-updates 
>   APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
>'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
> Architecture: amd64 (x86_64) 
> 
> Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores) 
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
> (charmap=UTF-8) 
> Shell: /bin/sh linked to /usr/bin/dash 
> Init: unable to detect 

Ping!

-Alexey



Bug#989440: Debian: gmp: add support for arc

2021-08-30 Thread Alexey Brodkin
On Thu, 3 Jun 2021 19:00:30 + Vineet Gupta  
wrote: 
> Source: gmp 
> Severity: normal 
> Tags: patch 
> 
> Hi, 
> 
> To bootstrap arc port we need symbols file update in gmp. 
> Patch attached. 

Ping!

-Alexey



Bug#989443: Debian: libffi: update symbols for ARC

2021-08-30 Thread Alexey Brodkin
On Thu, 3 Jun 2021 19:51:25 + Vineet Gupta  
wrote: 
> Source: libffi 
> Severity: normal 
> Tags: patch 
> 
> Hi, 
> 
> This is needed to bootstrap arc port. 
> Patch attached. 

Ping!

-Alexey



Bug#989444: Debian: jemalloc: add arc support

2021-08-30 Thread Alexey Brodkin
On Thu, 3 Jun 2021 21:10:28 + Vineet Gupta  
wrote: 
> Update: upstream change has just now been merged. 

Ping!

-Alexey



Bug#989453: Gentle ping

2021-08-28 Thread Alexey Brodkin
This is just a gentle reminder - we need this for ARC port for Debian.
As Vineet has mentioned Wiki was properly updated.

Is there anything else blocking this one?

-Alexey

X-Debbugs-CC: 
linux-snps-...@lists.infradead.org,guil...@debian.org,hel...@subdivi.de


Bug#992762: feedreader, feedly account error

2021-08-23 Thread Alexey Osadchy

Package: feedreader

Version: 2.10.0


When i select feedly account get error:

{"errorCode":403,"errorId":"ap1int-sv2.2021082300.276869","errorMessage":"must 
use https"}



I am using Linux dell 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 
(2021-08-03) x86_64 GNU/Linux.




Bug#992091: python3.9: Add arc-linux-gnu triplet

2021-08-11 Thread Alexey Brodkin
Source: python3.9
Severity: normal
Tags: patch upstream

Dear Maintainer,

There's a new triplet for ARCv2 processors "arc-linux-gnu"
defined here https://wiki.debian.org/Multiarch/Tuples.

With addition of this triplet to Python3 it becomes buildable for ARC.
Attaching a simple diff that implements proposed change.

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff --git a/configure b/configure
index 1252335472..7f735e99c7 100755
--- a/configure
+++ b/configure
@@ -5231,6 +5231,8 @@ cat >> conftest.c <

Bug#982956: still present

2021-06-04 Thread Alexey Kuznetsov
Debian 9 issue fixed for 4.19.0-16-686-pae.

Debian 10 issue still presents in vmlinuz-5.10.0-7-686-pae

-- AK


Bug#984997: [debian-mysql] Bug#984997: mariadb-server-10.5: database password passed in cleartext both on commandline and in environment

2021-03-15 Thread alexey . yurchenko

Hello,

I would agree that passing secrets on the command line is insecure and 
in this case unnecessary, there is an easy fix for that and it will be 
implemented.


Speaking of environment, AFAIK on modern systems it can be read only by 
sufficiently privileged user, so I don't see how it is less secure than 
a file (which will have to have the same permissions as 
/proc//environ). Could you elaborate how is it less secure than 
using --defaults-extra-file?


AFAIK xtrabackup/mariabackup script does not support passing passwords 
via file descriptor, so that option does not seem to be practical.


Kind regards,
Alex

On 2021-03-14 13:20, Marc Lehmann wrote:

On Thu, Mar 11, 2021 at 09:49:03PM +0200, Otto Kekäläinen
 wrote:

Thanks for looking into this and reporting it. Could you be a bit more
specific what the context is, who can view the command?


This is a rather old and wlel-known type of security issue.

Typically any local user can view the password. This data is also often
exposed in monitoring output, http status pages, smtp and so on.

The comandline and environment are simply the wrong places to expose
secret data - passwords should never be shown on screen in cleartext.

(That includes the environment, btw. storing secrets in environment
variables is similarly insecure).


How do you suggest the password would be passed?


The typical method that is employed in practise is passing it via a 
file
descriptor. A bit less secure is using a (non-world-readable) file, 
e.g.

using --defaults-extra-file.




Bug#984953: libgtkmm-3.0-1v5: GParted crashes on Gdk::Pixbuf::get_width() const ()

2021-03-10 Thread Alexey A Nikitin
Package: libgtkmm-3.0-1v5
Version: 3.24.2-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: moonwal...@syrius.us

Dear Maintainer,

I attempted to launch GParted and saw it crash immediately after initially 
showing its window
I attempted to delete all /root/.gtkrc*, /root/.config/gtkrc*, and 
/root/.config/gtk-3.0/settings.ini
files, as I had configured Breeze as GTK theme and I thought maybe that has 
something to do with the crash
since console does spam theme-related warning messages. That did visibly reset 
the GTK theme for GParted,
but the crash was still there.

I'm also attaching the core dump from the run before my attempt to reset GTK 
theme.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Foreign Architectures: i386

Kernel: Linux 5.8.5-0.40-1-pinebookpro-hwaccel (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgtkmm-3.0-1v5 depends on:
ii  libatkmm-1.6-1v5 2.28.0-3
ii  libc62.31-9
ii  libcairomm-1.0-1v5   1.12.2-4
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.7-1
ii  libglibmm-2.4-1v52.64.2-2
ii  libgtk-3-0   3.24.24-3
ii  libpangomm-1.4-1v5   2.42.1-1
ii  libsigc++-2.0-0v52.10.4-2
ii  libstdc++6   10.2.1-6

libgtkmm-3.0-1v5 recommends no packages.

libgtkmm-3.0-1v5 suggests no packages.

-- no debconf information



Bug#980963: dpkg: Please add ARC architecture

2021-03-03 Thread Alexey Brodkin
Hi Helmut,

> On Sat, Feb 06, 2021 at 07:25:35PM +0000, Alexey Brodkin wrote:
> > Any chances to get updates on this one some time soon?
> 
> No. The triplet cannot be changed once added. Therefore, the addition is
> often deferred. The absence of the triplet can easily be worked around.
> A bootstrap can be prototyped already. A major missing piece though is
> glibc 2.32 being packaged in Debian. That likely is a prerequisite for
> resolving this bug.

Well not sure why there's a dependency on glibc as w/o ARC target support
in dpkg nothing could be built for ARC. For example I did built Binutils
with fixed dpkg.

> Things that often need architecture-specific support for a new
> architecture include:
>  * guile-X.Y (cross support)
>  * libgc

Above 2 are not [yet] supported but seems to be easy ones.

>  * libxcrypt (symbols)

Not sure about "libxcrypt" (whatver that means), but libgpg-error supports ARC 
since 2018, see:
https://github.com/gpg/libgpg-error/commit/48c8f8ddfc80551db7615e1eb3555c1dc3f6a657

>  * nspr

Done in 2019, see 
https://hg.mozilla.org/projects/nspr/rev/cc73b6c7dab2e8053533e1f2c0c23dc721e10b76

>  * openssl (packaging)

Not sure what needs to be done here as I know we build a lot of complex
things with OpenEmbedded/Yocto and openssl libs are being built for sure.

> Are any of these fixed or confirmed working for arc?

See above, quite some do work.
 
-Alexey


Bug#982956: Acknowledgement (linux-image-4.19.0-14-686-pae: task blocked for more)

2021-02-20 Thread Alexey Kuznetsov
Can be bug at here (same symptoms):

https://gitlab.freedesktop.org/drm/intel/-/issues/2905

-- AK


On Wed, Feb 17, 2021 at 3:03 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 982956:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982956.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Kernel Team 
>
> If you wish to submit further information on this problem, please
> send it to 982...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 982956: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982956
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>


Bug#980963: dpkg: Please add ARC architecture

2021-02-06 Thread Alexey Brodkin
Hello,

Any chances to get updates on this one some time soon?

Regards,
Alexey


Bug#981139: frr: OSPF crashes after sh ip ospf interface lo

2021-01-26 Thread Alexey
Package: frr
Version: 7.4-1+b1
Severity: normal
Tags: upstream

Dear Maintainer,

*** 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 ***


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

Kernel: Linux 5.10.0-2-amd64 (SMP w/1 CPU thread)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages frr depends on:
ii  adduser   3.118
ii  iproute2  5.10.0-3
ii  libc-ares21.17.1-1
ii  libc6 2.31-9
ii  libcap2   1:2.44-1
ii  libcrypt1 1:4.4.17-1
ii  libjson-c50.15-1
ii  libpam0g  1.4.0-2
ii  libreadline8  8.1-1
ii  libsystemd0   247.2-5
ii  libyang1  1.0.184-2
ii  logrotate 3.18.0-1

Versions of packages frr recommends:
ii  frr-pythontools  7.4-1

Versions of packages frr suggests:
pn  frr-doc  

-- Configuration Files:
/etc/frr/daemons changed:
bgpd=yes
ospfd=yes
ospf6d=yes
ripd=yes
ripngd=yes
isisd=yes
pimd=yes
ldpd=yes
nhrpd=yes
eigrpd=yes
babeld=yes
sharpd=yes
pbrd=yes
bfdd=yes
fabricd=yes
vrrpd=yes
vtysh_enable=yes
zebra_options="  -A 127.0.0.1 -s 9000"
bgpd_options="   -A 127.0.0.1"
ospfd_options="  -A 127.0.0.1"
ospf6d_options=" -A ::1"
ripd_options="   -A 127.0.0.1"
ripngd_options=" -A ::1"
isisd_options="  -A 127.0.0.1"
pimd_options="   -A 127.0.0.1"
ldpd_options="   -A 127.0.0.1"
nhrpd_options="  -A 127.0.0.1"
eigrpd_options=" -A 127.0.0.1"
babeld_options=" -A 127.0.0.1"
sharpd_options=" -A 127.0.0.1"
pbrd_options="   -A 127.0.0.1"
staticd_options="-A 127.0.0.1"
bfdd_options="   -A 127.0.0.1"
fabricd_options="-A 127.0.0.1"
vrrpd_options="  -A 127.0.0.1"


-- no debconf information

backtrace:
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7efea3d15537 in __GI_abort () at abort.c:79
#2  0x7efea3d1540f in __assert_fail_base (fmt=0x7efea3e7e128 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", assertion=0x7efea3fb241a "node->lock > 0", 
file=0x7efea3fb240e "lib/table.h", line=258, function=) at 
assert.c:92
#3  0x7efea3d24662 in __GI___assert_fail (assertion=0x7efea3fb241a 
"node->lock > 0", file=0x7efea3fb240e "lib/table.h", line=258, 
function=0x7efea3fc7de0 "route_unlock_node") at assert.c:101
#4  0x7efea3f85853 in ?? () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#5  0x7efea3f8644b in route_next () from 
/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#6  0x55f38a6df28f in ?? ()
#7  0x55f38a6dfb5d in ?? ()
#8  0x55f38a6e019f in ?? ()
#9  0x7efea3f33fec in ?? () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#10 0x7efea3f356d7 in cmd_execute_command () from 
/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#11 0x7efea3f358d6 in cmd_execute () from 
/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#12 0x7efea3f90345 in ?? () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#13 0x7efea3f909d1 in ?? () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#14 0x7efea3f938f0 in ?? () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#15 0x7efea3f8ae76 in thread_call () from 
/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#16 0x7efea3f52aa8 in frr_run () from 
/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#17 0x55f38a6a1b02 in main ()



Bug#981099: RFP: cudatext -- Cross-platform GUI code editor

2021-01-26 Thread Alexey Torgashin
Package: wnpp
Severity: wishlist

* Package name: cudatext
  Version : 1.122.6.0
  Upstream Author : Alexey Torgashin 
* URL : http://uvviewsoft.com/cudatext/
* License : MPL 2.0
  Programming Lang: Pascal (Free Pascal)
  Description : Cross-platform GUI code editor

CudaText is a cross-platform text editor, written in Lazarus. It is open source
project and can be used free of charge, even for business. It starts quite
fast: ~0.3 sec with ~30 plugins, on Linux on CPU Intel Core i3 3Hz. It is
extensible by Python add-ons: plugins, linters, code tree parsers, external
tools. Syntax parser is feature-rich, based on EControl engine (though not as
fast as in some competitors).

- why is this package useful/relevant?
It is cross-platform and FOSS code editor. Analog to Sublime Text (which is not
free). Has advantages over Sublime.
It has active Linux users.

- is it a dependency for another package?
no.

- do you use it?
yes.

- if there are other packages providing similar functionality, how does it
compare?

Geany, Kate editor. Both are having much less features. Both don't support same
OS range: Linux, Windows, *BSD, macOS.

- how do you plan to maintain it? inside a packaging team
I want to help with this.



Bug#980963: dpkg: Please add ARC architecture

2021-01-24 Thread Alexey Brodkin
Package: dpkg
Version: 1.19.7ubuntu3-1~202101232134~ubuntu20.04.1
Severity: wishlist
Tags: patch

Dear Maintainer,

ARC architecture seem to match requirements for being added to the dpkg
(https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F):

 * GNU triplet is there since 2013,
   see: 
https://git.savannah.gnu.org/cgit/config.git/commit/?id=986360de6e412cbed27dbe2dbfb64ddbd18e7370
 * Binutils, GCC & uClibc support ARC for many years now,
   glibc 2.32 finally gained ARC support, see 
https://lists.gnu.org/archive/html/info-gnu/2020-08/msg2.html 

Please see attached patch which implements reqested change.

-Alexey
>From 96523e18473b56743bf2f7d308c2d786f337e52e Mon Sep 17 00:00:00 2001
From: Alexey Brodkin 
Date: Sun, 24 Jan 2021 00:34:52 +0300
Subject: [PATCH] Add ARC architecture

---
 data/cputable | 2 ++
 scripts/t/Dpkg_Arch.t | 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/data/cputable b/data/cputable
index 9f2a8e0e4..114a66ecb 100644
--- a/data/cputable
+++ b/data/cputable
@@ -20,6 +20,8 @@ i386  i686(i[34567]86|pentium)32  
little
 ia64   ia64ia6464  little
 alpha  alpha   alpha.* 64  little
 amd64  x86_64  (amd64|x86_64)  64  little
+arcarc arc.*   32  little
+arceb  arc arceb.* 32  big
 armeb  armeb   arm.*b  32  big
 armarm arm.*   32  little
 arm64  aarch64 aarch64 64  little
diff --git a/scripts/t/Dpkg_Arch.t b/scripts/t/Dpkg_Arch.t
index a3a9e6fee..aa0d97a21 100644
--- a/scripts/t/Dpkg_Arch.t
+++ b/scripts/t/Dpkg_Arch.t
@@ -16,7 +16,7 @@
 use strict;
 use warnings;
 
-use Test::More tests => 16836;
+use Test::More tests => 17762;
 
 use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch
 debarch_eq debarch_is debarch_is_wildcard
@@ -174,7 +174,7 @@ is(gnutriplet_to_debarch(undef), undef, 'undef gnutriplet');
 is(gnutriplet_to_debarch('unknown-unknown-unknown'), undef, 'unknown 
gnutriplet');
 is(gnutriplet_to_debarch('x86_64-linux-gnu'), 'amd64', 'known gnutriplet');
 
-is(scalar get_valid_arches(), 539, 'expected amount of known architectures');
+is(scalar get_valid_arches(), 569, 'expected amount of known architectures');
 
 {
 local $ENV{CC} = 'false';
-- 
2.25.1



Bug#979633: lightsquid: all of log lines skipped by date filter

2021-01-09 Thread Alexey V. Simbarsky
Package: lightsquid
Version: 1.8-6
Severity: important

Dear Maintainer,

All of log lines skipped by date filter (at year 2021).
Posssible solution:
- correct value of "$filterdatestop" variable (file "lightparser.pl", line 69)
  Instead of:
  my $filterdatestop =timelocal(59,59,23,31,12-1,2020-1900)+1000;
  There should be (at least):
  my $filterdatestop =timelocal(59,59,23,31,12-1,2030-1900)+1000;

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-12-amd64 (SMP w/12 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.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 lightsquid depends on:
ii  apache2 [httpd]  2.4.38-3+deb10u4
ii  libdbi-perl  1.642-1+deb10u1
ii  libgd-perl [libgd-gd2-perl]  2.71-2
ii  perl [libtime-local-perl]5.28.1-6+deb10u1

lightsquid recommends no packages.

lightsquid suggests no packages.

-- Configuration Files:
/etc/apache2/conf-available/lightsquid.conf changed [not included]
/etc/cron.d/lightsquid changed [not included]
/etc/lightsquid/lightsquid.cfg changed [not included]

-- no debconf information



Bug#966291: nexet report

2020-10-01 Thread Alexey Kuznetsov
I did rebuild debian kernel (linux-source-5.4 == 5.4.19-1~bpo10+1) with
ubuntu 5.4.0-26-generic and it works again. And tested kernel for a few
days - no corruption!

Looks like something wrong with original debian config which causes random
data loss on my SSD. Attaching diffconfig's.

config-5.4.19 - debian source code compiled with ubuntu config
config-5.4.0-0.bpo.4-amd64 - debian default kernel
config-5.4.0-26-generic - ubuntu kernel

/usr/src/linux-headers-5.4.19/scripts/diffconfig config-5.4.19
config-5.4.0-26-generic  > ~/debian-5.4.19-ubuntu-5.4.0-26-generic.txt

/usr/src/linux-headers-5.4.19/scripts/diffconfig config-5.4.0-0.bpo.4-amd64
config-5.4.19  > ~/debian-5.4.0-0.bpo.4-debian-5.4.19.txt

Maybe anyone can suggest which configs / values should I try to enable /
disable.

-- AK


debian-5.4.19-ubuntu-5.4.0-26-generic.txt.gz
Description: application/gzip


debian-5.4.0-0.bpo.4-debian-5.4.19.txt.gz
Description: application/gzip


Bug#966291: Next report

2020-09-28 Thread Alexey Kuznetsov
I've tried ubuntu kernel + debian os (full os with only ubuntu kernel as
external package) and try to use it for a few days. It works! I can say it
is a debian kernel issue and not a package base issue.

Debian 10.6 + Ubuntu kernel 5.4.0-26-generic

'diffconfig debian ubuntu' attached.

-- AK


diff-config-debian-ubuntu.gz
Description: application/gzip


Bug#966291: More details

2020-08-17 Thread Alexey Kuznetsov
Debian run of hwprobe: https://linux-hardware.org/?probe=a0a3771b15

It feels like debian writes a random sectors with random data at SSD for no
reason.

This is common apt error (package name varying) while SSD failing under
Debian:


...

Preconfiguring packages ...
dpkg: warning: files list file for package 'golang-1.11-go' missing;
assuming package has no files currently installed
dpkg: unrecoverable fatal error, aborting:
 files list file for package 'bison' is missing final newline
E: Sub-process /usr/bin/dpkg returned an error code (2)

...

Smartmon 6.6:  NVMe Status 0x02



root@axet-laptop:/home/axet# smartctl -a /dev/nvme0n1
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-5.4.0-0.bpo.4-amd64] (local
build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:   HFM512GDJTNG-8310A
Serial Number:  CD9AN74501410AR62
Firmware Version:   80001C00
PCI Vendor/Subsystem ID:0x1c5c
IEEE OUI Identifier:0xace42e
Controller ID:  1
Number of Namespaces:   1
Namespace 1 Size/Capacity:  512 110 190 592 [512 GB]
Namespace 1 Formatted LBA Size: 512
Local Time is:  Mon Aug 17 14:38:11 2020 MSK
Firmware Updates (0x16):3 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x0016): Wr_Unc DS_Mngmt Sav/Sel_Feat
Maximum Data Transfer Size: 64 Pages
Warning  Comp. Temp. Threshold: 81 Celsius
Critical Comp. Temp. Threshold: 82 Celsius
Namespace 1 Features (0x02):NA_Fields

Supported Power States
St Op Max   Active Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +   3.5000W   --0  0  0  05   5
 1 +   2.4000W   --1  1  1  1   30  30
 2 +   1.9000W   --2  2  2  2  100 100
 3 -   0.0350W   --3  3  3  3 10001000
 4 -   0.0035W   --3  3  3  3 10005000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 + 512   0 0
 1 -4096   0 0

=== START OF SMART DATA SECTION ===
Read NVMe SMART/Health Information failed: NVMe Status 0x02



Smartmon 7.1



smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-0.bpo.4-amd64] (local
build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:   HFM512GDJTNG-8310A
Serial Number:  CD9AN74501410AR62
Firmware Version:   80001C00
PCI Vendor/Subsystem ID:0x1c5c
IEEE OUI Identifier:0xace42e
Controller ID:  1
Number of Namespaces:   1
Namespace 1 Size/Capacity:  512 110 190 592 [512 GB]
Namespace 1 Formatted LBA Size: 512
Local Time is:  Mon Aug 17 14:43:03 2020 MSK
Firmware Updates (0x16):3 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x0016): Wr_Unc DS_Mngmt Sav/Sel_Feat
Maximum Data Transfer Size: 64 Pages
Warning  Comp. Temp. Threshold: 81 Celsius
Critical Comp. Temp. Threshold: 82 Celsius
Namespace 1 Features (0x02):NA_Fields

Supported Power States
St Op Max   Active Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +   3.5000W   --0  0  0  05   5
 1 +   2.4000W   --1  1  1  1   30  30
 2 +   1.9000W   --2  2  2  2  100 100
 3 -   0.0350W   --3  3  3  3 10001000
 4 -   0.0035W   --3  3  3  3 10005000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 + 512   0 0
 1 -4096   0 0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:   0x00
Temperature:38 Celsius
Available Spare:100%
Available Spare Threshold:  10%
Percentage Used:27%
Data Units Read:37 476 420 [19,1 TB]
Data Units Written: 26 897 901 [13,7 TB]
Host Read Commands: 513 568 341
Host Write Commands:506 327 841
Controller Busy Time:   3 846
Power Cycles:   478
Power On Hours: 621
Unsafe Shutdowns:   56
Media and Data Integrity Errors:0
Error Information Log Entries:  0
Warning  Comp. Temperature Time:0
Critical Comp. Temperature Time:0
Temperature Sensor 1:   38 Celsius
Temperature Sensor 2:   37 Celsius

Error Information (NVMe Log 0x01, max 256 entries)
No Errors Logged


root@axet-laptop:/home/axet# tun

Bug#966291: Next report

2020-08-16 Thread Alexey Kuznetsov
>From 26 Jul 2020 to 14 Aug I used to run Ubuntu 20.04. And have no issues
with 'debsums -c' nor 'Path of Exile' self check. Then I reinstall debian
completely (clean super duper install) using debootstrap and keep it
running since. Two days later. On a day (today) 16 aug I ran booth debsums
and POE PackCheck.exe and it failed:


Checking pack file Content.ggpk...
/Art/particles/ground_effects_v2/desecrated_maligaro/rot_03.dds hash isn't
in sync. Repaired.
/Art/particles/ground_effects_v2/desecrated_maligaro hash isn't in sync.
Repaired.
/Art/particles/ground_effects_v2 hash isn't in sync. Repaired.
/Art/particles hash isn't in sync. Repaired.
/Art hash isn't in sync. Repaired.
/ShaderCacheD3D11.packed/15.dat hash isn't in sync. Repaired.
/ShaderCacheD3D11.packed hash isn't in sync. Repaired.
Fatal error: Your pack file has become corrupted. Currently the only way to
fix this is to delete Content.ggpk and download it again by running the
client.


Looks like Debian + my ssd has serious issues and not working
properly together. I have no idea what to do next. Dmesg log attached. I
also run logwatch on my debian distro and it did not report any issues.

5.4.0-0.bpo.4-amd64

-- AK


dmesg.log.gz
Description: application/gzip


Bug#966291: Crashed on the first day

2020-07-25 Thread Alexey Kuznetsov
Filesystem got corrupted on the first day of using debian and
5.4.0-0.bpo.4-amd64. It probably somehow related to debian kernel patches?
I'll keep using debian 5.4 until next crash. Then I'll get back to ubuntu
for longer period of time.

-- AK


Bug#962105: znc: CVE-2020-13775

2020-06-03 Thread Alexey Sokolov
03.06.2020 11:25, Salvatore Bonaccorso пишет:
> Source: znc
> Version: 1.8.0-1
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> The following vulnerability was published for znc.
> 
> CVE-2020-13775[0]:
> | ZNC before 1.8.1-rc1 allows attackers to trigger an application crash
> | (with a NULL pointer dereference) if echo-message is not enabled and
> | there is no network.
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2020-13775
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13775
> [1] https://github.com/znc/znc/commit/2390ad111bde16a78c98ac44572090b33c3bd2d8
> 
> Please adjust the affected versions in the BTS as needed, if my
> understandig of the isuse is correctly then this was only introduced
> in 1.8.0 while fixing another bug related to echo-messages, please
> double check though.

Correct. MITRE changed the suggested description and left that and a few
more details out. https://wiki.znc.in/ChangeLog/1.8.1 has a better text.

> 
> Regards,
> Salvatore
> 


-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Bug#951647: libmstch-dev: Library configuration is misplaced

2020-02-19 Thread Nikolov Alexey EXT
Package: libmstch-dev
Version: 1.0.2-2
Severity: important
Tags: patch

Dear Maintainer,

While trying to link up a CMake project with this library, an error occured:

```
CMake Error at /usr/lib/cmake/mstch/mstch-config.cmake:1 (include):
  include could not find load file:

/usr/lib/cmake/mstch/mstch-targets.cmake
```

This is because the *mstch-targets.cmake* is being installed into multiarch
location, which is introduced by the *fix-lib-dir* patch.

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libmstch-dev depends on:
ii  libboost-dev  1.67.0.1

libmstch-dev recommends no packages.

libmstch-dev suggests no packages.

-- no debconf information


fix-lib-dir
Description: fix-lib-dir


Bug#951321: liblog4cplus-dev: Library metadata file is missing

2020-02-14 Thread Nikolov Alexey EXT
Package: liblog4cplus-dev
Version: 1.1.2-3.2
Severity: important
Tags: patch

Dear Maintainer,

While trying to link up a CMake project with this library, an error occured:

```
-- Checking for module 'log4cplus'
--   No package 'log4cplus' found
CMake Error at /usr/share/cmake-3.13/Modules/FindPkgConfig.cmake:452 (message):
  A required package was not found
Call Stack (most recent call first):
  /usr/share/cmake-3.13/Modules/FindPkgConfig.cmake:622 
(_pkg_check_modules_internal)
  src/CMakeLists.txt:9 (pkg_check_modules)
```

This is because the *log4cplus.pc* file is not packaged.

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU:ru (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages liblog4cplus-dev depends on:
ii  liblog4cplus-1.1-9  1.1.2-3.2

liblog4cplus-dev recommends no packages.

liblog4cplus-dev suggests no packages.

-- no debconf information

--- log4cplus-1.1.2/debian/liblog4cplus-dev.install	2016-08-08 14:02:11.0 +0300
+++ log4cplus-1.1.2-new/debian/liblog4cplus-dev.install	2020-02-14 14:36:16.973646620 +0200
@@ -2,3 +2,4 @@
 usr/include/log4cplus/*
 usr/lib/*/liblog4cplus.a
 usr/lib/*/liblog4cplus.la
+usr/lib/*/pkgconfig/*


Bug#940132: linux-image-5.2.0-2-amd64: Freeze when zram hits mem_limit

2019-09-12 Thread Alexey Pikalev
Package: src:linux
Version: 5.2.9-2
Severity: normal

Hello,

How to reproduce:
1. set up zram with mem_limit that we can hit, like 10MB or so
2. get system to start swapping there, for example put a large random file in 
tmpfs and attempt to lock large portion of memory with memtester
System freezes with swap write errors

If we do not set mem_limit then that process gets killed by OOM just fine.
My guess is that the way mem_limit works by denying swap writes is somehow 
blocking Linux OOM triggers?

Thanks

-- Package-specific info:
** Version:
Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-21)) #1 SMP Debian 5.2.9-2 (2019-08-21)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.2.0-2-amd64 
root=UUID=a548c59c-2eb5-451a-86a6-50e11befaed1 ro quiet

** Not tainted

** Kernel log:

** Model information
[1.692152] scsi host6: ahci
[1.692308] scsi host7: ahci
[1.692448] ata3: SATA max UDMA/133 abar m4096@0xfc032000 port 0xfc032100 
irq 24
[1.692457] ata4: SATA max UDMA/133 abar m4096@0xfc032000 port 0xfc032180 
irq 24
[1.692465] ata5: SATA max UDMA/133 abar m4096@0xfc032000 port 0xfc032200 
irq 24
[1.692531] ata6: SATA max UDMA/133 abar m4096@0xfc032000 port 0xfc032280 
irq 24
[1.692539] ata7: SATA max UDMA/133 abar m4096@0xfc032000 port 0xfc032300 
irq 24
[1.692547] ata8: SATA max UDMA/133 abar m4096@0xfc032000 port 0xfc032380 
irq 24
[1.692879] PCI Interrupt Link [LNKB] enabled at IRQ 10
[1.692934] virtio-pci :00:06.0: virtio_pci: leaving for legacy driver
[1.693926] virtio-pci :00:07.0: virtio_pci: leaving for legacy driver
[1.697127] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
[1.697394] PCI Interrupt Link [LNKA] enabled at IRQ 11
[1.700614] 8139cp :00:05.0 eth0: RTL-8139C+ at 0x(ptrval), 
52:54:00:88:e3:90, IRQ 11
[1.703679] 8139too: 8139too Fast Ethernet driver 0.9.28
[1.708829] ACPI: bus type USB registered
[1.708856] usbcore: registered new interface driver usbfs
[1.708864] usbcore: registered new interface driver hub
[1.708901] usbcore: registered new device driver usb
[1.714140] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[1.717706] uhci_hcd: USB Universal Host Controller Interface driver
[1.717935] input: VirtualPS/2 VMware VMMouse as 
/devices/platform/i8042/serio1/input/input3
[1.718850] uhci_hcd :00:01.2: UHCI Host Controller
[1.718857] uhci_hcd :00:01.2: new USB bus registered, assigned bus 
number 1
[1.718881] uhci_hcd :00:01.2: detected 2 ports
[1.718994] uhci_hcd :00:01.2: irq 11, io base 0xc140
[1.719130] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001, 
bcdDevice= 5.02
[1.719131] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[1.719132] usb usb1: Product: UHCI Host Controller
[1.719133] usb usb1: Manufacturer: Linux 5.2.0-2-amd64 uhci_hcd
[1.719134] usb usb1: SerialNumber: :00:01.2
[1.719224] hub 1-0:1.0: USB hub found
[1.719231] hub 1-0:1.0: 2 ports detected
[1.719980] input: VirtualPS/2 VMware VMMouse as 
/devices/platform/i8042/serio1/input/input2
[1.769811] 8139cp :00:05.0 ens5: renamed from eth0
[1.772491] virtio_blk virtio2: [vda] 41943040 512-byte logical blocks (21.5 
GB/20.0 GiB)
[1.773342]  vda: vda1 vda2 < vda5 >
[1.850666] ata2.01: NODEV after polling detection
[1.851145] ata2.00: ATAPI: QEMU DVD-ROM, 1.1.0, max UDMA/100
[1.853302] scsi 1:0:0:0: CD-ROMQEMU QEMU DVD-ROM 1.1. 
PQ: 0 ANSI: 5
[2.007014] ata3: SATA link down (SStatus 0 SControl 300)
[2.007259] ata7: SATA link down (SStatus 0 SControl 300)
[2.010040] ata5: SATA link down (SStatus 0 SControl 300)
[2.010273] ata4: SATA link down (SStatus 0 SControl 300)
[2.010509] ata6: SATA link down (SStatus 0 SControl 300)
[2.010766] ata8: SATA link down (SStatus 0 SControl 300)
[2.050873] usb 1-1: new full-speed USB device number 2 using uhci_hcd
[2.066596] sr 1:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
[2.066600] cdrom: Uniform CD-ROM driver Revision: 3.20
[2.067790] sr 1:0:0:0: Attached scsi CD-ROM sr0
[2.245049] usb 1-1: New USB device found, idVendor=0409, idProduct=55aa, 
bcdDevice= 1.01
[2.245051] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2.245053] usb 1-1: Product: QEMU USB Hub
[2.245055] usb 1-1: Manufacturer: QEMU
[2.245056] usb 1-1: SerialNumber: 314159-:00:01.2-1
[2.247134] hub 1-1:1.0: USB hub found
[2.248097] hub 1-1:1.0: 8 ports detected
[2.374200] PM: Image not found (code -22)
[2.461671] random: fast init done
[2.550868] usb 1-1.1: new full-speed USB device number 3 using uhci_hcd
[2.610429] EXT4-fs (vda1): mounted filesystem with ordered data mode. Opts: 
(null)
[2.699975] usb 1-1.1: New USB device found, idVendor=0627, idProduct=0001, 
bcdDevice= 0.00

Bug#929967: CMake: use TBBConfig instead of FindTBB

2019-06-04 Thread Alexey Veprev
Package: libtbb-dev
Version: 2018~U6-4
X-Debbugs-CC: ti...@debian.org

TBB provides a TBBInstallConfig CMake module to generate TBBConfig files
for packages:
see description here
https://github.com/intel/tbb/blob/tbb_2019/cmake/README.rst#tbbinstallconfig

TBBConfig files are automatically invoked by CMake when you use
"find_package(TBB <...>)" (just like FindTBB.cmake module).

Some advantages of TBBConfig in comparison with FindTBB.cmake:
1. TBBConfig provides imported targets which can be used in modern CMake
style (while current FindTBB.cmake provides variables).
2. TBBConfig works for the exact package, it won't look for TBB stuff in
other places except the specific one.
3. Generator of TBBConfig files is maintained on TBB side that allows to
align usage model across different distributions.

TBBInstallConfig is already used
- in Homebrew tbb formula:
https://github.com/Homebrew/homebrew-core/blob/master/Formula/tbb.rb#L35..L38
- in TBB packaging script (which is used in conda-forge, for example):
https://github.com/intel/tbb/blob/tbb_2019/build/build.py#L157..L167


Bug#928214: mingw-w64 GCC is built without linker plugin support making LTO unusable

2019-04-29 Thread Alexey Izbyshev

Package: gcc-mingw-w64
Version: 21.2

Hi!

I've discovered that mingw-w64 GCC in Debian is configured without 
linker plugin support:
$ x86_64-w64-mingw32-gcc -x c - -flto -fno-fat-lto-objects <<<'int 
main() {}'

cc1: error: -fno-fat-lto-objects are supported only with linker plugin

This makes LTO unusable in many real-world cases. Consider the following 
example:


$ grep . *.c
foo.c:int foo() {return 42;}
main.c:int main() {return foo();}
$ x86_64-w64-mingw32-gcc -flto -O2 foo.c main.c -c
$ x86_64-w64-mingw32-ar cr app.a main.o foo.o
$ x86_64-w64-mingw32-gcc -flto -O2 app.a
$ x86_64-w64-mingw32-objdump -d a.exe | grep ':' -A 5
00402c30 :
  402c30:   48 83 ec 28 sub$0x28,%rsp
  402c34:   e8 d7 e9 ff ff  callq  401610 <__main>
  402c39:   90  nop
  402c3a:   48 83 c4 28 add$0x28,%rsp
  402c3e:   e9 0d e9 ff ff  jmpq   401550  # 'foo' is 
not inlined


Note that 'foo' is not inlined because the archived object files weren't 
processed by LTO (they were processed by the linker as normal objects 
because they are "fat" LTO objects, i.e. they contain both normal object 
code and GCC IR).


$ x86_64-w64-mingw32-gcc -flto -O2 main.o foo.o
$ x86_64-w64-mingw32-objdump -d a.exe | grep ':' -A 5
00402c30 :
  402c30:   48 83 ec 28 sub$0x28,%rsp
  402c34:   e8 d7 e9 ff ff  callq  401610 <__main>
  402c39:   b8 2a 00 00 00  mov$0x2a,%eax # Good, 'foo' 
is inlined!

  402c3e:   48 83 c4 28 add$0x28,%rsp
  402c42:   c3  retq

In this case, legacy LTO implementation was used: GCC driver looked at 
the objects and called its 'lto-wrapper' helper. But it can't do that 
with archives.


This misconfiguration is caused by the incorrect use of 
'--with-plugin-ld' GCC configure option (or its strange behavior, 
depending on how you look at it):


$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu 
--prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' 
--infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' 
--libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode 
--disable-dependency-tracking --prefix=/usr --enable-shared 
--enable-static --disable-multilib --with-system-zlib 
--libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib 
--enable-libstdcxx-time=yes --with-tune=generic 
--with-headers=/usr/x86_64-w64-mingw32/include 
--enable-version-specific-runtime-libs --enable-fully-dynamic-string 
--enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada 
--enable-lto --with-plugin-ld --enable-threads=win32 
--program-suffix=-win32 --program-prefix=x86_64-w64-mingw32- 
--target=x86_64-w64-mingw32 --with-as=/usr/bin/x86_64-w64-mingw32-as 
--with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic 
--enable-libstdcxx-filesystem-ts=yes

Thread model: win32
gcc version 8.3-win32 20190406 (GCC)

The problem is that "--with-plugin-ld" expects a linker path as the 
value, but if it's not given, the value becomes 'yes' and is then tested 
for plugin support, without much success (lookup "checking linker plugin 
support" in 
"https://buildd.debian.org/status/fetch.php?pkg=gcc-mingw-w64&arch=amd64&ver=21.2&stamp=1555227419&raw=0";).


This option is actually not needed since there is no need to use an 
"alternative" linker for plugins: the one that is passed with 
"--with-ld" will do. I've checked manually that if I remove 
"--with-plugin-ld" from the configuration of gcc-mingw-w64 source 
package, the linker plugin support is detected properly.


Ubuntu packages are also affected by this problem. I've checked that 
OpenSUSE Tumbleweed packages are not affected (they don't use 
"--with-plugin-ld").


I suggest to remove "--with-plugin-ld" from GCC configuration options.

Thanks!

-Alexey



Bug#912491: pysiogame: Please migrate to python3-pygame

2019-04-17 Thread Alexey Loginov
It can be built with python3-pygame, but pysiogame has new name - eduactiv8:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927312



Bug#927312: Pysiogame changed name on eduactiv8

2019-04-17 Thread Alexey Loginov
Package: pysiogame
Version: pysiogame_3.60.814

There is aduactiv8:
https://sourceforge.net/projects/eduactiv8
https://github.com/imiolek-ireneusz/eduActiv8

Files for Debian:
https://build.opensuse.org/package/show/home:imiolek-i/eduActiv8#



Bug#927054: clvmd is missing for debian buster

2019-04-14 Thread Alexey Shvetsov
package: lvm2
package: clvmd

Hi!

Seems like clvmd functionality is missing for debian buster (while it
present in stretch)

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov, PhD


Bug#927026: Please enable CONFIG_MD_CLUSTER for linux packages in Buster

2019-04-13 Thread Alexey Shvetsov
Package: linux

Hi!

Is it possible to enable CONFIG_MD_CLUSTER=m in release kernel configs for
Debian 10. This option enables possibility to create raid1 or raid10 for
shared storage systems (like sas multipath jbods + hba) and operate with it
in master master mode using HA tools like corosync, pacemaker and dlm.

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov


Bug#925270: znc unwisely advertises exact Debian version

2019-03-22 Thread Alexey Sokolov
22.03.2019 8:08, Uli Schlachter пишет:
> Hi,
> 
> On 22.03.19 00:53, T. Joseph Carter wrote:
>> <-- nick (~u@h) has quit (Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in)
>> <-- nick (~u@h) has quit (Quit: ZNC 1.6.6+deb1ubuntu0.1 - http://znc.in)
>> <-- nick (~u@h) has quit (Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in)
>>
>> And one counter-example of how changing the default might be a good idea:
>>
>> <-- nick (~u@h has quit (Quit: ZNC - https://znc.in)
> 
> This behaviour goes back to [1], I think. Before that, ZNC would do the
> second kind of quit message. Commit [1] introduced an option called
> "HideVersion", which defaults to "false". If this option is "false", the
> function CZNC::GetTag() *always* includes version information. When set
> to "true", CZNC::GetTag() only includes version information when told so
> by its caller (seems to be: only the web interface for logged-in users).

No, before that commit, ZNC sometimes did expose the version, sometimes
did not. That commit made it consistent, and configurable.

I made it false by default to follow example of other software which
exposes its version, e.g. nginx.

> When I proposed to restore the old behaviour and instead to make
> "HideVersion" also not include the version when explicitly told
> otherwise, I was told that this is the way it is supposed to work.
> 

AFAIR, the patch you proposed caused it to always hide the version, even
for logged in users, and in znc --version

> Anyway: Set "HideVersion = true" in your znc to get rid of the version
> information. Webadmin can modify this setting, but controlpanel can not.
> 
> If wanted, Debian could patch src/znc.cpp to change the default for
> m_bHideVersion to true (the line looks like "m_bHideVersion(false)").
> 
> Cheers,
> Uli
> 
> [1]:
> https://github.com/znc/znc/commit/f9a45076690990f75a14315db4f456e750073723
> 


-- 
Best regards,
Alexey "DarthGandalf" Sokolov



Bug#923424: Build yafaray with qt5

2019-02-27 Thread Alexey Loginov
Package: yafaray
Version: yafaray_0.1.2+really0.1.2~beta5-2

There is qt5: https://github.com/YafaRay/Core



Bug#922813: Update pianobooster (qt4->qt5)

2019-02-20 Thread Alexey Loginov
Package: pianobooster
Version: pianobooster_0.6.7~svn156

There is pianobooster-0.7.0 with qt5 support:
https://github.com/captnfab/PianoBooster
and debian branch: https://github.com/captnfab/PianoBooster/tree/debian



Bug#922812: Update lybniz on lybniz 3

2019-02-20 Thread Alexey Loginov
Package: lybniz
Version: lybniz_1.3.2

There is lybniz-3:
https://github.com/thomasfuhringer/lybniz



Bug#791400: [yagf] Please update to 0.9.5

2019-02-13 Thread Alexey Loginov
Please update on qt5 branch:
http://svnweb.mageia.org/packages/cauldron/yagf/current/



Bug#921602: Update biogenesis

2019-02-06 Thread Alexey Loginov
Package: biogenesis
Version: 0.8

There is biogenesis-0.9:
https://sourceforge.net/projects/biogenesis/files/biogenesis/0.9/
There is manual:
https://sourceforge.net/projects/biogenesis/files/user%20manuals/
If manual is installed, then it is available offline.

spec file: 
http://svnweb.mageia.org/packages/cauldron/biogenesis/current/SPECS/biogenesis.spec?view=markup



Bug#916298: steam: should depend on steam-devices

2019-01-27 Thread Alexey Morsov
On Sun, Jan 27, 2019 at 12:23:54PM +, Simon McVittie wrote:
> On Sun, 27 Jan 2019 at 12:35:08 +0300, Alexey Morsov wrote:
> > steam-device now conflict with steam-launcher on those files
> > /lib/udev/rules.d/60-steam-input.rules
> > /lib/udev/rules.d/60-steam-vr.rules
> 
> steam-devices is a Debian package; steam-launcher is a Valve-provided
> package. Please do not mix the two. Either install Steam from Debian,
> or install it from Valve's apt repository (which is intended for Ubuntu).
> 
> smcv

I have steam package installed from debian non-free repo. But after
steam-launcher removed due to conflict with steam-devices i have no
.desktop file to launch steam client. 

How can i resolve this? Purge all steam package from system and install
them from debian repo ?



signature.asc
Description: PGP signature


Bug#920601: steam-devices conflict with steam-launcher

2019-01-27 Thread Alexey Morsov
Package: steam-devices
Version: 1.0.0.59-2
Severity: normal
Tags: a11y

Dear Maintainer,

sudo apt install steam-launcher
Reading package lists... Done
Building dependency tree
Reading state information... Done
Recommended packages:
  jockey-common
The following NEW packages will be installed:
  steam-launcher
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
1 not fully installed or removed.
Need to get 0 B/2???902 kB of archives.
After this operation, 3???053 kB of additional disk space will be used.
(Reading database ... 231191 files and directories currently installed.)
Preparing to unpack .../steam-launcher_1.0.0.59_all.deb ...
Unpacking steam-launcher (1.0.0.59) ...
dpkg: error processing archive /var/cache/apt/archives/steam-
launcher_1.0.0.59_all.deb (--unpack):
 trying to overwrite '/lib/udev/rules.d/60-steam-vr.rules', which is also in
package steam-devices 1.0.0.59-2
Errors were encountered while processing:
 /var/cache/apt/archives/steam-launcher_1.0.0.59_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)



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

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

steam-devices depends on no packages.

Versions of packages steam-devices recommends:
ii  steam  1.0.0.59-2

steam-devices suggests no packages.

-- no debconf information



Bug#920600: steam-devices conflict with steam-launcher

2019-01-27 Thread Alexey Morsov
Package: steam-devices
Version: 1.0.0.59-2
Severity: normal
Tags: a11y

Dear Maintainer,

sudo apt install steam-launcher
Reading package lists... Done
Building dependency tree
Reading state information... Done
Recommended packages:
  jockey-common
The following NEW packages will be installed:
  steam-launcher
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
1 not fully installed or removed.
Need to get 0 B/2 902 kB of archives.
After this operation, 3 053 kB of additional disk space will be used.
(Reading database ... 231191 files and directories currently installed.)
Preparing to unpack .../steam-launcher_1.0.0.59_all.deb ...
Unpacking steam-launcher (1.0.0.59) ...
dpkg: error processing archive /var/cache/apt/archives/steam-
launcher_1.0.0.59_all.deb (--unpack):
 trying to overwrite '/lib/udev/rules.d/60-steam-vr.rules', which is also in
package steam-devices 1.0.0.59-2
Errors were encountered while processing:
 /var/cache/apt/archives/steam-launcher_1.0.0.59_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)



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

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

steam-devices depends on no packages.

Versions of packages steam-devices recommends:
ii  steam  1.0.0.59-2

steam-devices suggests no packages.

-- no debconf information


Bug#916298: steam: should depend on steam-devices

2019-01-27 Thread Alexey Morsov
Package: steam-devices
Version: 1.0.0.59-2
Followup-For: Bug #916298

Dear Maintainer,

steam-device now conflict with steam-launcher on those files
/lib/udev/rules.d/60-steam-input.rules
/lib/udev/rules.d/60-steam-vr.rules




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

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

steam-devices depends on no packages.

Versions of packages steam-devices recommends:
ii  steam  1.0.0.59-2

steam-devices suggests no packages.

-- no debconf information



Bug#917643: Acknowledgement (zram-tools uses outdated by 7 years approach in setting up zram thread count)

2018-12-29 Thread Alexey A Nikitin
I have also submitted an upstream bug report (
https://github.com/highvoltage/zram-tools/issues/3), but considering the
last commit is from three years ago I'm not holding my breath that it gets
addressed.

Alexey

--
This message was created with 100% recycled electrons


On Sat, Dec 29, 2018 at 5:48 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 917643:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917643.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Jonathan Carter 
>
> If you wish to submit further information on this problem, please
> send it to 917...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 917643: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917643
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>


  1   2   3   4   5   6   7   >