Bug#1068753: live-build: Should not install raspi-firmware on x86_64

[Vasudev Kamath]

Roland Clobus  writes:

> Control: severity -1 normal
> Control: tags -1 +pending
> Control: tags 1065640 +pending
> Control: merge -1 1065640
>
> Hello Vasudev Kamath,
>
>> Built the live image for bookworm using live build (on bookworm as well as 
>> from unstable).
>
> Note that the version which is on bookworm will not be updated.
>
Yes that is understood.

>
>   The built
>> image incldes raspi-firmware which is not meant for x86_64. I was installing 
>> some dkms module which
>> will regenerate initrd etc and that failed with below error
> ...
>> The only way to fix this situation was to remove raspi-firmware in the live 
>> image. For now I'm working
>> around the situation using following hook file which I use during live image 
>> build
> ...
>> Can we avoid installing it on x86 architecture by default. If some one needs 
>> it they can pull
>> it.
>
> The issue has already been fixed, it is just not yet released.
> You can use the version from the git repository as details here:
> https://wiki.debian.org/ReproducibleInstalls/LiveImages
>
Thanks will consider using repo directly instead of packages when we do
our builds.

>
>> It was claimed to be fixed by 12.2 in this [1] but it probably only fixed 
>> official live images
>> but not the live build? There is also another ticket [2] but does not give 
>> proper details so created
>> a new one
>
> Instead of creating a new bug, you could have sent a mail to the old one 
> with your additional information. I've merged both bug reports.
>

Yes I could have used reportbug to followup but it flashed to me after
sending the mail.

>
> The official Debian live images got fixed for 12.2, because the official 
> images use the git repository for live-build instead of the .deb-package.
>
I see. Sorry for confusion as I was not aware how the debian live images
are built and also there was no information on it being fixed in git in
original report which was filed against debian-live virtual package.

>
>> Let me know if any other information is needed from my side.
>
> Please wait a while, a few other changes are pending and then a new 
> release can be made.

Sure no worries. I will start using repo instead of pre-built version in
our setup.

>
> With kind regards,
> Roland Clobus

Thanks,
Vasudev

Bug#1068753: live-build: Should not install raspi-firmware on x86_64

[Vasudev Kamath]

Package: live-build
Version: 1:20230502
Severity: important

Dear Maintainer,

Built the live image for bookworm using live build (on bookworm as well as from 
unstable). The built
image incldes raspi-firmware which is not meant for x86_64. I was installing 
some dkms module which
will regenerate initrd etc and that failed with below error

update-initramfs: Generating /boot/initrd.img-6.1.0-13-amd64
W: Couldn't identify type of root file system for fsck hook
live-boot: core filesystems dm-verity devices utils udev blockdev dns.
raspi-firmware: missing /boot/firmware, did you forget to mount it?
run-parts: /etc/initramfs/post-update.d//z50-raspi-firmware exited with return 
code 1
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned 
error exit status 1
Processing triggers for libc-bin (2.36-9+deb12u2) ...
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1) 

The only way to fix this situation was to remove raspi-firmware in the live 
image. For now I'm working
around the situation using following hook file which I use during live image 
build

#!/bin/sh

set -eu


raspi_installed=$(apt-cache policy raspi-firmware | grep Installed: | awk 
'{print $NF}')
if [ "$raspi_installed" != "(none)" ]; then
apt-get remove --purge -y raspi-firmware
fi

Can we avoid installing it on x86 architecture by default. If some one needs it 
they can pull
it.

It was claimed to be fixed by 12.2 in this [1] but it probably only fixed 
official live images
but not the live build? There is also another ticket [2] but does not give 
proper details so created
a new one

Let me know if any other information is needed from my side.

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


Thanks and Regards,
Vasudev Kamath


-- Package-specific info:

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

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

Versions of packages live-build depends on:
ii  debootstrap  1.0.134

Versions of packages live-build recommends:
ii  apt-utils   2.7.11
ii  bzip2   1.0.8-5.1
ii  cpio2.15+dfsg-1
ii  cryptsetup  2:2.7.1-1
ii  file1:5.45-2+b1
ii  live-boot-doc   1:20230131
ii  live-config-doc 11.0.4
ii  live-manual-html [live-manual]  2:20151217.2
ii  rsync   3.2.7-1+b2
ii  systemd-container   255.4-1+b1
ii  wget1.24.5-1
ii  xz-utils5.6.1+really5.4.5-1

Versions of packages live-build suggests:
ii  e2fsprogs  1.47.0-2+b1
pn  mtd-utils  
ii  parted 3.6-3

-- no debconf information

Bug#1032771: libzim7: Package name is wrong, should be 'libzim'

[Vasudev Kamath]

Hi Emmanuel,

I’m no loner active maintainer of zimlib but I’m just talking from
pacakaging convention followed by Debian - a library is named based on
lib where major version is major part of
soname. And that is precisely followed here libzim7 indicating 7 as major
release number.

I don’t think rename is needed and don’t see your point as well. As eg
glibc is called libc6 libbpf is called libbpf0 and so on.

I don’t think renaming is needed and even worth to follow here which
requires at least a distro release to get rid of old name ans transition
packages.

That is my opinion also having an extra 7 doesn’t hurt. People can search
package by libzim and description should give information of same.

Thanks and Regards
-- 

Vasudev Kamath
http://copyninja.info
copyninja@{frndk.de|vasudev.homelinux.net}

Bug#1018818: bpfcc: FTBFS with libbpf 1.0.0

[Vasudev Kamath]

Control: fixed -1 0.25.0+ds-1

Hi Sudip,

Thanks for the report new upstream release is fixing this issue and I've
already uploaded new version and is building fine against all release
architecture. So closing this bug.

Thanks and Regards,
Vasudev

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Vasudev Kamath]

Aurelien Jarno  writes:

> Hi,
>
> On 2022-09-26 09:45, Vasudev Kamath wrote:
>> And post removing /usr/lib version of libc it seems to work fine and no
>> crash is happening.
>> 
>> └─(09:44:30 on master)──> expr   
>>  
>>   1 ↵ ──(Mon,Sep26)─┘
>> expr: missing operand
>> Try 'expr --help' for more information.
>> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
>> └─(09:44:39 on master)──>
>
> Thanks for all the details. It's great that your system is now fixed. Do
> you have an idea why libc6 2.34 ended up in /usr/lib/x86_64-linux-gnu?
> I do not see any explanation from the glibc side. Did you attempt a
> usrmerge migration that failed after moving some files, or do you think
> it's unrelated? 
>

I seriously did not have a clue why system was in this state. I had
installed system back in 2019 and just keep updating. Also it was not
just glibc, a whole bunch of packages were in this state and it took me a
while to fix the entire system. (Had to write script to automate entire
process).

I don't remember me attempting to install usrmerge but not sure if it
came via some dependency and failed to install. Feels weird why system
was in such a state.

Cheers,
Vasudev

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Vasudev Kamath]

Vasudev Kamath  writes:

> Post installation of usrmerge this output is changed
>
> └─(09:37:07 on master)──> ls -ld /lib/x86_64-linux-gnu/libc.so.6  
>   
> 1 ↵ ──(Mon,Sep26)─┘
> -rwxr-xr-x 1 root root 2061320 Sep 23 01:32 /lib/x86_64-linux-gnu/libc.so.6
> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
> └─(09:37:20 on master)──> ls -ld /usr/lib/x86_64-linux-gnu/libc.so.6  
>   
> ──(Mon,Sep26)─┘
> -rwxr-xr-x 1 root root 2049032 Sep 11 03:35 
> /usr/lib/x86_64-linux-gnu/libc.so.6
> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
> └─(09:37:25 on master)──> ls -ld /lib 
>   
> ──(Mon,Sep26)─┘
> drwxr-xr-x 9 root root 4096 Sep 26 09:32 /lib
> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
> └─(09:38:14 on master)──>
>
> So looks like my system is not in sane state. Do I need to just delete
> /usr/lib/ libc and try this?.

From objdump -p output it looks like /lib version is the 2.35

3 0x00 0x069691b2 GLIBC_2.32
GLIBC_2.31
34 0x00 0x069691b3 GLIBC_2.33
GLIBC_2.32
35 0x00 0x069691b4 GLIBC_2.34
GLIBC_2.33
36 0x00 0x069691b5 GLIBC_2.35
GLIBC_2.34
37 0x00 0x0963cf85 GLIBC_PRIVATE
GLIBC_2.35

and /usr/lib version is 2.34

GLIBC_2.30
33 0x00 0x069691b2 GLIBC_2.32
GLIBC_2.31
34 0x00 0x069691b3 GLIBC_2.33
GLIBC_2.32
35 0x00 0x069691b4 GLIBC_2.34
GLIBC_2.33
36 0x00 0x0963cf85 GLIBC_PRIVATE
GLIBC_2.34

And post removing /usr/lib version of libc it seems to work fine and no
crash is happening.

└─(09:44:30 on master)──> expr  

1 ↵ ──(Mon,Sep26)─┘
expr: missing operand
Try 'expr --help' for more information.
┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
└─(09:44:39 on master)──>

Cheers,
Vasudev

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Vasudev Kamath]

Vasudev Kamath  writes:
>
> └─(09:09:40 on master)──> ls -ld /lib 
>   
> ──(Mon,Sep26)─┘
> drwxr-xr-x 9 root root 4096 Sep 23 14:37 /lib
> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
> └─(09:12:50 on master)──> ls -l /lib/x86_64-linux-gnu/libc.so.6   
>   
> ──(Mon,Sep26)─┘
> -rwxr-xr-x 1 root root 2049032 Sep 11 03:35 /lib/x86_64-linux-gnu/libc.so.6
> ┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
> └─(09:13:06 on master)──> ls -l /usr/lib/x86_64-linux-gnu/libc.so.6   
>   
> ──(Mon,Sep26)─┘
> -rwxr-xr-x 1 root root 2049032 Sep 11 03:35 
> /usr/lib/x86_64-linux-gnu/libc.so.6
> ┌─(~/.emacs.d)─
>
> Is it that if I install usrmerge and then upgrade libc it should work?

Post installation of usrmerge this output is changed

└─(09:37:07 on master)──> ls -ld /lib/x86_64-linux-gnu/libc.so.6

1 ↵ ──(Mon,Sep26)─┘
-rwxr-xr-x 1 root root 2061320 Sep 23 01:32 /lib/x86_64-linux-gnu/libc.so.6
┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
└─(09:37:20 on master)──> ls -ld /usr/lib/x86_64-linux-gnu/libc.so.6

──(Mon,Sep26)─┘
-rwxr-xr-x 1 root root 2049032 Sep 11 03:35 /usr/lib/x86_64-linux-gnu/libc.so.6
┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
└─(09:37:25 on master)──> ls -ld /lib   

──(Mon,Sep26)─┘
drwxr-xr-x 9 root root 4096 Sep 26 09:32 /lib
┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
└─(09:38:14 on master)──>

So looks like my system is not in sane state. Do I need to just delete
/usr/lib/ libc and try this?.

Cheers,
Vasudev

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Vasudev Kamath]

>
> I have looked at the coredump you sent me:
>
> $ eu-unstrip -n --core 
> core.expr.1000.d5ff83e0fd69439497afd17511de3417.85280.166392358300
> 0x5604c0781000+0x1e000 
> b919757cbc30fbb64b14498222499d972fd80acd@0x5604c0781368 . - /usr/bin/expr
> 0x7fbfabc0+0x201000 
> ef3afb43092687d7fcc8167fabdee73f4a3287f1@0x7fbfabc00380 - - 
> /usr/lib/x86_64-linux-gnu/libc.so.6
> 0x7ffdc5bde000+0x1000 c35c947b072ff69b395cd326b83b24630f2c5065@0x7ffdc5bde54c 
> . - linux-vdso.so.1
> 0x7fbfac04c000+0x362b8 
> a03c3b14d371da908a3f22007b3f0c73d1f9f634@0x7fbfac04c248 
> /lib64/ld-linux-x86-64.so.2 - ld-linux-x86-64.so.2
> 0x7fbfabfc9000+0x80bc8 
> 25c73b398493c695a013a6d9d493a8316aac0fa0@0x7fbfabfc9248 
> /usr/lib/x86_64-linux-gnu/libgmp.so.10 - libgmp.so.10
>
> ef3afb43092687d7fcc8167fabdee73f4a3287f1 
>   => comes from libc6 version 2.34-8
> a03c3b14d371da908a3f22007b3f0c73d1f9f634
>   => comes from libc6 version 2.35-1
>
> So the crash is likely due to a mismatch between glibc. I believe this
> is due to an issue with usrmerge as the paths reported by your core file
> seems to show that your system is merged, while reportbug says
> "merged-usr: no".
>
> By using a non usrmerged system, with libc6 2.34-8 duplicated in both
> /lib/x86_64-linux-gnu/ and /usr/lib/x86_64-linux-gnu, and upgrading it
> to libc6 2.35-1, I am able to reproduce your issue with expr:
>
> $ expr
> *** stack smashing detected ***: terminated
> Aborted

Interesting. I had put init-system-helpers on hold because it was
reported with some issue and I see usrmerge package is not installed on
my system.

usrmerge:
  Installed: (none)
  Candidate: 31
  Version table:
 31 500
500 http://deb.debian.org/debian sid/main amd64 Packages
500 http://deb.debian.org/debian sid/main i386 Packages
 30+nmu1 -1
100 /var/lib/dpkg/status

>> > And if I understand you right the stack smashing
>> > is from "autoreconf --version".
>> > But I could not find it executing any "expr" processes in my test VM.
>> 
>> Actually just invoking autoconf was crashing and just executing expr itself 
>> was also crashing. If needed I can install latest libc and provide any 
>> required information. Do let me know
>
> Before trying to upgrade again, we should ensure your system is in a
> sane state. Could you please send us the output of:
>
> ls -ld /lib
> ls -l /lib/x86_64-linux-gnu/libc.so.6
> ls -l /usr/lib/x86_64-linux-gnu/libc.so.6

└─(09:09:40 on master)──> ls -ld /lib   

──(Mon,Sep26)─┘
drwxr-xr-x 9 root root 4096 Sep 23 14:37 /lib
┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
└─(09:12:50 on master)──> ls -l /lib/x86_64-linux-gnu/libc.so.6 

──(Mon,Sep26)─┘
-rwxr-xr-x 1 root root 2049032 Sep 11 03:35 /lib/x86_64-linux-gnu/libc.so.6
┌─(~/.emacs.d)─(vasudeva.sk@bhrigu:pts/8)─┐
└─(09:13:06 on master)──> ls -l /usr/lib/x86_64-linux-gnu/libc.so.6 

──(Mon,Sep26)─┘
-rwxr-xr-x 1 root root 2049032 Sep 11 03:35 /usr/lib/x86_64-linux-gnu/libc.so.6
┌─(~/.emacs.d)─

Is it that if I install usrmerge and then upgrade libc it should work?

Thanks and Regards,
Vasudev

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Vasudev Kamath]

> Hello Vasudev,
> ok, reverting back would explain reportbug using version 2.34-8.
> 
> But was this core taken at a time where all libc packages
> should have been at 2.35-1 ?
> Then I don't understand that "Module" line,
> which shows the build-id from 2.34-8.

Ah sorry I did coredumpctl debug post reverting the libc6. But core file 
attached is taken when actual 2.35 was installed.

> 
> And if I understand you right the stack smashing
> is from "autoreconf --version".
> But I could not find it executing any "expr" processes in my test VM.

Actually just invoking autoconf was crashing and just executing expr itself was 
also crashing. If needed I can install latest libc and provide any required 
information. Do let me know

Thanks and Regards 
Vasudev

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Vasudev Kamath]

Hi Aurelien, 

Old libc is because I reverted it as some scripts I use and autoconf as well 
were breaking.

I assume I have mentioned in report that a downgrade solved crash. If I missed 
sorry about that.

Sorry for top posting as I’m replying from my pho e 

Sent from my iPhone

> On 24-Sep-2022, at 03:21, Aurelien Jarno  wrote:
> 
> Hi,
> 
>> On 2022-09-23 21:28, Bernhard Übelacker wrote:
>>> On Fri, 23 Sep 2022 14:45:07 +0530 Vasudev Kamath  
>>> wrote:
>>> Package: libc6
>>> Version: 2.34-8
>> 
>>> I upgraded libc6 to latest released 2.35-1
>> 
>>>Module ld-linux-x86-64.so.2 with build-id 
>>> a03c3b14d371da908a3f22007b3f0c73d1f9f634
>>>Module libc.so.6 with build-id 
>>> ef3afb43092687d7fcc8167fabdee73f4a3287f1
>>>Module libgmp.so.10 with build-id 
>>> 25c73b398493c695a013a6d9d493a8316aac0fa0
>>>Module expr with build-id 
>>> b919757cbc30fbb64b14498222499d972fd80acd
>> 
>> 
>>> Versions of packages libc6 suggests:
>>> ii  debconf [debconf-2.0]  1.5.79
>>> pn  glibc-doc  
>>> ii  libc-l10n  2.35-1
>>> ii  libnss-nis 3.1-4
>>> ii  libnss-nisplus 1.3-4
>>> ii  locales2.35-1
>> 
>> 
>> 
>> Hello Vasudev,
>> I wonder if this libc6 installation is completed.
>> Because the bug report mentions version 2.34-8 from testing,
>> but e.g. locales and libc-l10n is 2.35-1.
>> 
>> Also searching for a package containing the debug information
>> for the build-id from the modules listing returns currently
>> the version 2.34-8 from testing.
>> 
>> But the build-id for ld-linux-x86-64.so.2 points to 2.35-1.
>> 
>> Maybe the libc package installation got interrupted?
> 
> Good catch. I also noticed that the libraries seems to be located in
> /usr/lib/x86_64-linux-gnu/, which is typical of a usrmerge system, but
> reportbug says "merged-usr: no".
> 
> Vasudev, you should probably check that you do not have too versions of
> the glibc on your system, one in /lib/x86_64-linux-gnu/ and another one
> in /usr/lib/x86_64-linux-gnu/ without the /lib -> usr/lib symlink.
> 
> Regards
> Aurelien
> 
> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net

Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"

[Vasudev Kamath]

Package: libc6
Version: 2.34-8
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I upgraded libc6 to latest released 2.35-1

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

After upgrade noticed autoreconf --version was failing with **stack smashing 
detected** message.
But in general looks like triggered by expr command. From the coredumpctl got 
following

   Message: Process 85280 (expr) of user 1000 dumped core.

Module linux-vdso.so.1 with build-id 
c35c947b072ff69b395cd326b83b24630f2c5065
Module ld-linux-x86-64.so.2 with build-id 
a03c3b14d371da908a3f22007b3f0c73d1f9f634
Module libc.so.6 with build-id 
ef3afb43092687d7fcc8167fabdee73f4a3287f1
Module libgmp.so.10 with build-id 
25c73b398493c695a013a6d9d493a8316aac0fa0
Module expr with build-id 
b919757cbc30fbb64b14498222499d972fd80acd
Stack trace of thread 85280:
#0  0x7fbfabc8983c n/a (libc.so.6 + 0x8983c)
#1  0x7fbfabc3da52 raise (libc.so.6 + 0x3da52)
#2  0x7fbfabc28469 abort (libc.so.6 + 0x28469)
#3  0x7fbfabc7dc18 n/a (libc.so.6 + 0x7dc18)
#4  0x7fbfabd18c62 __fortify_fail (libc.so.6 + 0x118c62)
#5  0x7fbfabd18c40 __stack_chk_fail (libc.so.6 + 0x118c40)
#6  0x7fbfabc8449d n/a (libc.so.6 + 0x8449d)
#7  0x7fbfac06c893 n/a (ld-linux-x86-64.so.2 + 0x20893)
#8  0x7fbfac067f2f n/a (ld-linux-x86-64.so.2 + 0x1bf2f)
#9  0x7fbfac069b21 n/a (ld-linux-x86-64.so.2 + 0x1db21)
#10 0x7fbfac068948 n/a (ld-linux-x86-64.so.2 + 0x1c948)
ELF object binary architecture: AMD x86-64

Back trace from gdb

#0  0x7fbfabc8983c in ?? () from /usr/lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x7fbfabc8983c in ?? () from /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7fbfabc3da52 in raise () from /usr/lib/x86_64-linux-gnu/libc.so.6
#2  0x7fbfabc28469 in abort () from /usr/lib/x86_64-linux-gnu/libc.so.6
#3  0x7fbfabc7dc18 in ?? () from /usr/lib/x86_64-linux-gnu/libc.so.6
#4  0x7fbfabd18c62 in __fortify_fail () from 
/usr/lib/x86_64-linux-gnu/libc.so.6
#5  0x7fbfabd18c40 in __stack_chk_fail () from 
/usr/lib/x86_64-linux-gnu/libc.so.6
#6  0x7fbfabc8449d in ?? () from /usr/lib/x86_64-linux-gnu/libc.so.6
#7  0x7fbfac06c893 in dl_main (phdr=, phnum=, 
user_entry=, auxv=) at ./elf/rtld.c:2562
#8  0x7fbfac067f2f in _dl_sysdep_start 
(start_argptr=start_argptr@entry=0x7ffdc5baaa40, 
dl_main=dl_main@entry=0x7fbfac069db0 ) at 
../sysdeps/unix/sysv/linux/dl-sysdep.c:140
#9  0x7fbfac069b21 in _dl_start_final (arg=0x7ffdc5baaa40) at 
./elf/rtld.c:507
#10 _dl_start (arg=0x7ffdc5baaa40) at ./elf/rtld.c:596
#11 0x7fbfac068948 in _start () from /lib64/ld-linux-x86-64.so.2
#12 0x0001 in ?? ()
#13 0x7ffdc5bacd78 in ?? ()
#14 0x in ?? ()


   * What outcome did you expect instead?

  expr should not have crashed.

I'm attaching the core file from the systemd-coredump. Also post this I 
downgraded libc6 to 2.34-8 from snapshots and
no more crash is detected.

If anything more is needed do let me know.

Thanks and Regards
Vasudev


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

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

Versions of packages libc6 depends on:
ii  libgcc-s1  12.2.0-3

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.3-1+b1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.79
pn  glibc-doc  
ii  libc-l10n  2.35-1
ii  libnss-nis 3.1-4
ii  libnss-nisplus 1.3-4
ii  locales2.35-1

-- debconf information:
  glibc/upgrade: true
  glibc/restart-services:
  glibc/kernel-not-supported:
* libraries/restart-without-asking: true
  glibc/disable-screensaver:
  glibc/restart-failed:
  glibc/kernel-too-old:


core.expr.1000.d5ff83e0fd69439497afd17511de3417.85280.166392358300.zst
Description: application/zstd

Bug#1019248: linux: Enable EDAC module for Intel Icelake (10nm processors)

[Vasudev Kamath]

Source: linux
Version: 5.10.127-1
Severity: important

Dear Maintainer,

Recently when testing the newer Icelake servers in our DC we noticed that EDAC 
module is not
available in Debian for Intel Icelake (10nm processor). This is needed for 
utilities like rasdaemon
to work properly on new processor.

The module should be compiled by setting following option

CONFIG_EDAC_I10NM=m

Please consider doing it for Debian Bullseye as well as we are using this as 
base distribution.

Thanks and Regards,
Vasudev

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

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

Bug#995289: foolscap: ready for upload

[Vasudev Kamath]

Hi Andrius,

Andrius Merkys  writes:

> Hello,
>
> I have removed unneeded files from python3-foolscap binary package.
> Furthermore, there was an issue with building package with
> git-buildpackage, which I solved by updating the certificates used for
> tests.
>
> The package is ready for the upload now. If it is OK, I can upload it
> myself.

Sorry this message some how missed my inbox and did not notice till
today. I'm new to python team and I will let you do the upload.

I will wait for couple of days for your response else I will prepare and
upload the same.

Thanks and Regards,
Vasudev

Bug#987295: closed by Vasudev Kamath (Re: profile-bpf: 3 warnings generated)

[Vasudev Kamath]

Jacobo Nájera  writes:

> Hi,
>
> Thanks Vasudev
>
> I tried on a fresh install with Bullseye:
>
>
> Sampling at 49 Hertz of all threads by user + kernel stack... Hit Ctrl-C 
> to end.
> In file included from :2:
> In file included from /virtual/include/bcc/bpf.h:12:
> In file included from include/linux/types.h:6:
> In file included from include/uapi/linux/types.h:14:
> In file included from include/uapi/linux/posix_types.h:5:
> In file included from include/linux/stddef.h:5:
> In file included from include/uapi/linux/stddef.h:2:
> In file included from include/linux/compiler_types.h:69:
> include/linux/compiler-clang.h:51:9: warning: '__HAVE_BUILTIN_BSWAP32__' 
> macro redefined [-Wmacro-redefined]
> #define __HAVE_BUILTIN_BSWAP32__
>  ^
> :4:9: note: previous definition is here
> #define __HAVE_BUILTIN_BSWAP32__ 1
>  ^
> In file included from :2:
> In file included from /virtual/include/bcc/bpf.h:12:
> In file included from include/linux/types.h:6:
> In file included from include/uapi/linux/types.h:14:
> In file included from include/uapi/linux/posix_types.h:5:
> In file included from include/linux/stddef.h:5:
> In file included from include/uapi/linux/stddef.h:2:
> In file included from include/linux/compiler_types.h:69:
> include/linux/compiler-clang.h:52:9: warning: '__HAVE_BUILTIN_BSWAP64__' 
> macro redefined [-Wmacro-redefined]
> #define __HAVE_BUILTIN_BSWAP64__
>  ^
> :5:9: note: previous definition is here
> #define __HAVE_BUILTIN_BSWAP64__ 1
>  ^
> In file included from :2:
> In file included from /virtual/include/bcc/bpf.h:12:
> In file included from include/linux/types.h:6:
> In file included from include/uapi/linux/types.h:14:
> In file included from include/uapi/linux/posix_types.h:5:
> In file included from include/linux/stddef.h:5:
> In file included from include/uapi/linux/stddef.h:2:
> In file included from include/linux/compiler_types.h:69:
> include/linux/compiler-clang.h:53:9: warning: '__HAVE_BUILTIN_BSWAP16__' 
> macro redefined [-Wmacro-redefined]
> #define __HAVE_BUILTIN_BSWAP16__
>  ^
> :3:9: note: previous definition is here
> #define __HAVE_BUILTIN_BSWAP16__ 1
>  ^
> 3 warnings generated.
>
>
> uname
>
> Linux 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29) x86_64 GNU/Linux

Ok this seems to be related to kernel version because in Debian unstable
I don't see this warnings generated. Will check this with upstream.

Thanks and Regards,
Vasudev

Bug#996961: bpfcc-tools: biosnoop fails to print the SIZE field correctly on bullseye

[Vasudev Kamath]

Control: fixed -1 0.24.0+ds-1

Hi Rich,

Sorry for the delayed response. This is no longer an issue in latest
version of bpfcc-tools. Hence closing the bug.

Thanks and Regards,
Vasudev

Bug#987295: profile-bpf: 3 warnings generated

[Vasudev Kamath]

Control: fixed -1 0.24.0+ds-1

Hi Jacobo,

Sorry for delayed response. I checked with latest version of bpfcc-tools
and this is no longer an issue. So closing this bug.

Thanks and Regards,
Vasudev

Bug#1010346: linux-image-cloud-amd64: Enable CONFIG_FB_EFI=y in Buster Cloud Kernel

[Vasudev Kamath]

Package: linux-image-cloud-amd64
Version: 4.19+105+deb10u15
Severity: important

Dear Maintainer,

Booting a KVM based VM with UEFI enabled using Buster image with cloud kernel 
will have
a non working VNC console. Console seems to be frozen on debugging we figured 
out that 
its because buster cloud kernel does not have CONFIG_FB_EFI enabled.

This issue is not present in Bullseye kernel as it was enabled in following 
commit [1].
Can we also enable same option for Buster cloud kernel?. Else for using VNC 
like console
VM image needs to be running regular kernel (linux-image-amd64).


[1] 
https://salsa.debian.org/kernel-team/linux/-/commit/aa2bac77ef935f38b64a080a29318792c895eb12

Thanks and Regads,
Vasudev

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

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

Versions of packages linux-image-cloud-amd64 depends on:
pn  linux-image-5.17.0-1-cloud-amd64  

linux-image-cloud-amd64 recommends no packages.

linux-image-cloud-amd64 suggests no packages.

Bug#976960: systemd: Please package systemd-userdbd and systemd-homed

[Vasudev Kamath]

Hi Michael,

> I still fail to see the use-case for homed, tbh and the current
> implementation still requires quite a few hacks (see the fosdem 2020
> talk of Lennart and the problems e.g. with SSH keys).

> Atm this appears more like a tech-preview/demo and I don't feel
> comfortable yet supporting it.
> This can be reconsidered in bookworm.

Its been a long time from this reply. Can it now be considered to be
supported in Debian?. Even if its tech-preview/demo it will be useful
for users who want to experiment with new stuff.

By not shipping we are blocking people from experimenting things given
that systemd is core component of OS.

Cheers,
Vasudev

Bug#1002291: bpfcc: Fails to build with libbpf/0.6.1-1

[Vasudev Kamath]

Sudip Mukherjee  writes:

> On Tue, Feb 22, 2022 at 4:12 AM Vasudev Kamath  wrote:
>>
>> Sudip Mukherjee  writes:
>>
>> > You are trying to build 0.24.0+ds and I am rebuilding 0.22.0+ds-2 to test. 
>> >  :)
>> >
>> > Can you rebuild 0.22.0+ds-2 and verify.
>>
>> Err yes. It works with 0.22.0. I was preparing 0.23.0 and then 0.24.0.
>> Both of which fails as of now. Not sure what should be done.
>
> I think, since it works with 0.22.0 I will update libbpf in unstable.
> I am guessing the previous FTBFS was fixed by libbpf in this release.
> But now bpfcc has messed up something.
> If you are ok, then I can update libbpf and then you can ping the
> bpfcc upstream about the FTBFS with latest bpfcc with latest libbpf.

Yes please go ahead. I will wait for the new upload a bit more. If it
still does not work I will ping the upstream.

Cheers,
Vasudev

Bug#1002291: bpfcc: Fails to build with libbpf/0.6.1-1

[Vasudev Kamath]

Sudip Mukherjee  writes:

> You are trying to build 0.24.0+ds and I am rebuilding 0.22.0+ds-2 to test.  :)
>
> Can you rebuild 0.22.0+ds-2 and verify.

Err yes. It works with 0.22.0. I was preparing 0.23.0 and then 0.24.0.
Both of which fails as of now. Not sure what should be done.

Cheers,
Vasudev

Bug#1002291: bpfcc: Fails to build with libbpf/0.6.1-1

[Vasudev Kamath]

Sudip Mukherjee  writes:

> I have now uploaded libbpf/0.7.0 to experimental, can you please try
> building bpfcc and let me know if it works for you.
>

I'm ending up getting different error now related to deprecation.

>/<>/src/cc/bcc_btf.cc:178:33: error: invalid application of 
>‘sizeof’ to incomplete type 
>‘btf_ext_vendored::btf_ext_setup_core_relos(btf_ext_vendored::btf_ext*)::bpf_core_relo’
>   178 | .min_rec_size = sizeof(struct bpf_core_relo),
>   | ^~~~
> /<>/src/cc/bcc_btf.cc: In member function ‘int 
> ebpf::BTF::get_map_tids(std::string, unsigned int, unsigned int, unsigned 
> int*, unsigned int*)’:
> /<>/src/cc/bcc_btf.cc:655:30: warning: ‘int 
> btf__get_map_kv_tids(const btf*, const char*, __u32, __u32, __u32*, __u32*)’ 
> is deprecated: libbpf v0.7+: this API is not necessary when BTF-defined maps 
> are used [-Wdeprecated-declarations]
>   655 |   return btf__get_map_kv_tids(btf_, map_name.c_str(),
>   |  ^~~~
>   656 |   expected_ksize, expected_vsize,
>   |   ~~~
>   657 |   key_tid, value_tid);
>   |   ~~~
> In file included from /<>/src/cc/bcc_libbpf_inc.h:5,
>  from /<>/src/cc/bcc_btf.cc:22:
> /usr/include/bpf/btf.h:154:16: note: declared here
>   154 | LIBBPF_API int btf__get_map_kv_tids(const struct btf *btf, const char 
> *map_name,
>   |^~~~
> /<>/src/cc/bcc_btf.cc: In function ‘int 
> btf_ext_vendored::btf_ext_setup_core_relos(btf_ext_vendored::btf_ext*)’:
> /<>/src/cc/bcc_btf.cc:178:33: error: invalid application of 
> ‘sizeof’ to incomplete type 
> ‘btf_ext_vendored::btf_ext_setup_core_relos(btf_ext_vendored::btf_ext*)::bpf_core_relo’
>   178 | .min_rec_size = sizeof(struct bpf_core_relo),
>   | ^~~~
> /<>/src/cc/bcc_btf.cc: In member function ‘int 
> ebpf::BTF::get_map_tids(std::string, unsigned int, unsigned int, unsigned 
> int*, unsigned int*)’:
> /<>/src/cc/bcc_btf.cc:655:30: warning: ‘int 
> btf__get_map_kv_tids(const btf*, const char*, __u32, __u32, __u32*, __u32*)’ 
> is deprecated: libbpf v0.7+: this API is not necessary when BTF-defined maps 
> are used [-Wdeprecated-declarations]
>   655 |   return btf__get_map_kv_tids(btf_, map_name.c_str(),
>   |  ^~~~
>   656 |   expected_ksize, expected_vsize,
>   |   ~~~
>   657 |   key_tid, value_tid);
>   |   ~~~
> In file included from /<>/src/cc/bcc_libbpf_inc.h:5,
>  from /<>/src/cc/bcc_btf.cc:22:
> /usr/include/bpf/btf.h:154:16: note: declared here
>   154 | LIBBPF_API int btf__get_map_kv_tids(const struct btf *btf, const char 
> *map_name,
>   |^~~~
> make[3]: *** [src/cc/CMakeFiles/bcc-shared.dir/build.make:121: 
> src/cc/CMakeFiles/bcc-shared.dir/bcc_btf.cc.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> [ 69%] Building CXX object 
> src/cc/CMakeFiles/bcc-static.dir/bpf_module_rw_engine.cc.o
> cd /<>/obj-x86_64-linux-gnu/src/cc && /usr/bin/c++ -DEXPORT_USDT 
> -DHAVE_EXTERNAL_LIBBPF -I/usr/lib/llvm-13/include/../tools/clang/include 
> -I/<>/src -I/<>/obj-x86_64-linux-gnu/src 
> -I/<>/obj-x86_64-linux-gnu/src/cc -I/<>/src/cc 
> -I/<>/obj-x86_64-linux-gnu/src/cc/frontends/b 
> -I/<>/src/cc/frontends/b 
> -I/<>/src/cc/frontends/clang -I/usr/lib/llvm-13/include -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DCUSTOM_MACRO=true 
> -Wall  -fno-rtti -fPIC -DBCC_PROG_TAG_DIR='"/var/tmp/bcc"' -Wno-unused-result 
> -DLLVM_MAJOR_VERSION=13 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=gnu++14 -MD -MT 
> src/cc/CMakeFiles/bcc-static.dir/bpf_module_rw_engine.cc.o -MF 
> CMakeFiles/bcc-static.dir/bpf_module_rw_engine.cc.o.d -o 
> CMakeFiles/bcc-static.dir/bpf_module_rw_engine.cc.o -c 
> /<>/src/cc/bpf_module_rw_engine.cc
> [ 69%] Building CXX object 
> src/cc/CMakeFiles/bcc-shared.dir/exported_files.cc.o
> cd /<>/obj-x86_64-linux-gnu/src/cc && /usr/bin/c++ -DEXPORT_USDT 
> -DHAVE_EXTERNAL_LIBBPF -Dbcc_shared_EXPORTS 
> -I/usr/lib/llvm-13/include/../tools/clang/include -I/<>/src 
> -I/<>/obj-x86_64-linux-gnu/src 
> -I/<>/obj-x86_64-linux-gnu/src/cc -I/<>/src/cc 
> -I/<>/obj-x86_64-linux-gnu/src/cc/frontends/b 
> -I/<>/src/cc/frontends/b 
> -I/<>/src/cc/frontends/clang -I/usr/lib/llvm-13/include -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 

Bug#1002291: bpfcc: Fails to build with libbpf/0.6.1-1

[Vasudev Kamath]

Hi Sudip,

Sudip Mukherjee  writes:


>
> Reported error:
> In file included from /<>/src/cc/bcc_libbpf_inc.h:5,
>  from 
> /<>/src/cc/frontends/clang/b_frontend_action.cc:37:
> /usr/include/bpf/btf.h: In function ‘bool btf_is_mod(const btf_type*)’:
> /usr/include/bpf/btf.h:463:24: error: ‘BTF_KIND_TYPE_TAG’ was not declared in 
> this scope; did you mean ‘BTF_KIND_TYPEDEF’?
>   463 |kind == BTF_KIND_TYPE_TAG;
>   |^
>   |BTF_KIND_TYPEDEF
> /usr/include/bpf/btf.h: In function ‘bool btf_is_decl_tag(const btf_type*)’:
> /usr/include/bpf/btf.h:493:31: error: ‘BTF_KIND_DECL_TAG’ was not declared in 
> this scope; did you mean ‘BTF_KIND_FLOAT’?
>   493 | return btf_kind(t) == BTF_KIND_DECL_TAG;
>   |   ^
>   |   BTF_KIND_FLOAT
> /usr/include/bpf/btf.h: In function ‘bool btf_is_type_tag(const btf_type*)’:
> /usr/include/bpf/btf.h:498:31: error: ‘BTF_KIND_TYPE_TAG’ was not declared in 
> this scope; did you mean ‘BTF_KIND_TYPEDEF’?
>   498 | return btf_kind(t) == BTF_KIND_TYPE_TAG;
>   |   ^
>   |   BTF_KIND_TYPEDEF
>

I tried building bpfcc 0.23.0 with experimental libbpf and it too
failed. These versions are released with 0.5.0 libbpf. I see that next
release 0.24.0 (not sure when it happens) should work with newer libbpf.
Can we hold uploading newer libbpf to unstable till then?.

Thanks and Regards,
Vasudev

Bug#995352: ITP: tahoe-lafs -- Secure distributed file store

[Vasudev Kamath]

Package: wnpp
Severity: wishlist
Owner: Madhu Adav 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: tahoe-lafs
  Version : 1.16.0rc0
  Upstream Author : The Tahoe-LAFS Software Foundation
* URL : http://tahoe-lafs.readthedocs.io/en/latest/
* License : GPL-2+ with several exceptions or TGPPL1+
  Programming Lang: Python
  Description : Secure distributed file store

 Tahoe, the Least Authority File Store, is a distributed filesystem that
 features high reliability, strong security properties, and a fine-grained
 sharing model. Files are encrypted, signed, erasure-coded, then distributed
 over multiple servers, such that any (configurable) subset of the servers
 will be sufficient to recover the data. The default 3-of-10 configuration
 tolerates up to 7 server failures before data becomes unrecoverable.
 .
 Tahoe offers "provider-independent security": the confidentiality and
 integrity of your data do not depend upon the behavior of the servers. The
 use of erasure-coding means that reliability and availability depend only
 upon a subset of the servers.
 .
 Tahoe files are accessed through a RESTful web API, a human-oriented web
 server interface, and CLI tools.


 Reintroducing tahoe-lafs which was removed earlier because it did not support
 python3. Also filing it on behalf of my colleague. (who is marked owner)

Bug#995289: ITP: foolscap -- object-capability-based RPC system for Twisted Python

[Vasudev Kamath]

Package: wnpp
Severity: wishlist
Owner: Vasudev Kamath 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: foolscap
  Version : 21.7.0
  Upstream Author : Brian Warner
* URL : https://github.com/warner/foolscap/
* License : MIT
  Programming Lang: Python
  Description : object-capability-based RPC system for Twisted Python

 Foolscap (also known as "newpb") contains a new RPC system for Twisted Python,
 combining capability-based security, secure references, flexible
 serialization, and technology to mitigate resource-consumption attacks.


 This is for reintroducing the package which now has Python3 support and is
 a dependency for tahoe-lafs.

Bug#994914: python-autobahn: Please package new upstream release of autobahn

[Vasudev Kamath]

Source: python-autobahn
Severity: wishlist

Dear Maintainer,

We are working on to reintroduce tahoe-lafs to Debian since a new version
with python3 support has been release. New version need autobahn >= 19.5.2. 

Can you please consider updating the package to latest upstream release so we 
will be
unblocked on introducing tahoe again to Debian.

Thanks and Regards,
Vasudev

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

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

Bug#994913: python-eliot: Please package eliot version 1.13.0

[Vasudev Kamath]

Source: python-eliot
Severity: wishlist

Dear Maintainer,

We are working on reintroducing the tahoe-lafs back to Debian now that it 
supports python3.
But newer version of tahoe-lafs needs eliot to be updated to 1.13.0. Here is 
the comment from
the upstream requirements file

# On Python 3, we want a new enough version to support custom JSON encoders.
"eliot >= 1.13.0 ; python_version > '3.0'",

Could you please consider updating eliot to latest upstream release so we can 
be unblocked
to upload tahoe to Debian.

Thanks and Regards,
Vasudev

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

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

Bug#993856: [Pkg-libvirt-maintainers] Bug#993856: libvirt-daemon-system: vfio device passthrough fails with device pools due to apparmor profile

[Vasudev Kamath]

Hi Again,

Vasudev Kamath  writes:
>
> And the network configuration in libvirt domain looks like below
>
> 
>   
>   
>   
>function='0x0'/>
> 
>
> When I start the domain even though domain starts fine VF pass through does 
> not happen and the following
> message is seen in the dmesg output
>
> [11236.601474] audit: type=1400 audit(1630925018.676:49): apparmor="DENIED" 
> operation="open" profile="libvirt-e70e9c2c-110c-401c-982f-cb384d158471" 
> name="/dev/vfio/315" pid=5929 comm=43505520382F4B564D requested_mask="wr" 
> denied_mask="wr" fsuid=64055 ouid=64055
>
> and passthrough does not happen.

Just  wanted to add that this failure happens only with device pool
pass through which is handled by the libvirt. [1]. Normal hostdev pass
through which looks like below works just fine and apparmor does not
cause issue in this case.


  
  

  
  
  



[1] https://libvirt.org/formatnetwork.html

Best Regards,
Vasudev

Bug#993856: libvirt-daemon-system: vfio device passthrough fails with device pools due to apparmor profile

[Vasudev Kamath]

Package: libvirt-daemon-system
Version: 7.6.0-1
Severity: important

Dear Maintainer,

Possibly related bug [1]. Issue is similar to what is explained in this bug 
but is not addressed by the fix which is already present in src:libvirt 7.6 
version.

PS: Though I reporting from unstable machine actual test was done using libvirt 
7.6 
from unstable built for Bullseye. 

I'm defining the network device pool which looks like below


  passthrough
  f152e522-96d1-4a74-8aae-01f94244f8df
  
















  


And the network configuration in libvirt domain looks like below


  
  
  
  


When I start the domain even though domain starts fine VF pass through does not 
happen and the following
message is seen in the dmesg output

[11236.601474] audit: type=1400 audit(1630925018.676:49): apparmor="DENIED" 
operation="open" profile="libvirt-e70e9c2c-110c-401c-982f-cb384d158471" 
name="/dev/vfio/315" pid=5929 comm=43505520382F4B564D requested_mask="wr" 
denied_mask="wr" fsuid=64055 ouid=64055

and passthrough does not happen.

Note that this does not happen if the device pool interface is not present 
during start of domain and hot
attached using below command

sudo virsh attach-device --live --config debian10 network-pool-debian10.xml

To get the above working here is what I did I edited the 
/etc/apparmor.d/libvirt/libvirt-e70e9c2c-110c-401c-982f-cb384d158471 to
add line /dev/vfio/vfio rw, and this is what the changed file looks like

iaas@515-2102020016:~$ sudo cat 
/etc/apparmor.d/libvirt/libvirt-e70e9c2c-110c-401c-982f-cb384d158471
#
# This profile is for the domain whose UUID matches this file.
#

#include 

profile libvirt-e70e9c2c-110c-401c-982f-cb384d158471 
flags=(attach_disconnected) {
  #include 
  #include 
  #
  # for vfio hotplug on systems without static vfio (LP: #1775777)
  /dev/vfio/vfio rw,
}

Post the change I did following

sudo aa-teardown
sudo systemctl restart libvirtd
sudo systemctl restart apparmor

And on the next start device passthrough happens. I'm not sure if what I did is 
right but this seems to work
and I would be happy to see this done in the apparmor profile shipped by 
libvirt.

PS: I'm noob with apparmor all I did was bit of experiment to get the things 
working for my usecase.

If any other information is needed from my side please let me know.


[1] https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1775777


Thanks and Regards,
Vasudev

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

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.77
ii  gettext-base0.21-4
ii  iptables1.8.7-1
ii  libvirt-clients 7.6.0-1
ii  libvirt-daemon  7.6.0-1
ii  libvirt-daemon-config-network   7.6.0-1
ii  libvirt-daemon-config-nwfilter  7.6.0-1
ii  libvirt-daemon-system-systemd   7.6.0-1
ii  logrotate   3.18.1-2
ii  policykit-1 0.105-31

Versions of packages libvirt-daemon-system recommends:
ii  dmidecode3.3-3
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  iproute2 5.13.0-2
ii  mdevctl  0.81-1
ii  parted   3.4-1

Versions of packages libvirt-daemon-system suggests:
ii  apparmor2.13.6-10
pn  auditd  
ii  nfs-common  1:1.3.4-6
ii  open-iscsi  2.1.3-5
pn  pm-utils
ii  radvd   1:2.18-3
ii  systemd 247.9-1
pn  systemtap   
pn  zfsutils

-- Configuration Files:
/etc/libvirt/qemu.conf [Errno 13] Permission denied: '/etc/libvirt/qemu.conf'

-- debconf information:
  libvirt-daemon-system/id_warning: true

Bug#978727: bpfcc: Provide separate package for libbpf-tools?

[Vasudev Kamath]

Hello guys,

Sorry for delaying uploading this version. So I started working on the
libbpf-tools but I'm facing weird error when trying to build the package
in sbuild.

> /usr/sbin/bpftool gen skeleton .output/biolatency.bpf.o > 
> .output/biolatency.skel.h
> libbpf: failed to find BTF for extern 'KERNEL_VERSION': -2
> Error: failed to open BPF object file: No such file or directory

I'm not sure what is happening package builds fine on laptop so I'm
missing something. If you guys know what might be going wrong please let
me know :-).

Thanks and Regards
Vasudev

Bug#892058: Your Debian key is expiring

[Vasudev Kamath]

Felix Lechner  writes:
>
> Please keep in mind that the Debian folks in charge of the keyring
> update it only once a month. That usually happens on the 24th of each
> month. It it just a few days away.
>
> If you like this service, please leave a favorable comment here [2].
> Thank you!

Thanks for this reminder I got saved :-). Last 2 consecutive years I
forgot to update my keys and during DPL election I had to bug Gunnar at
last minute to pull in my key changes.

Cheers,
Vasudev

Bug#978727: bpfcc: Provide separate package for libbpf-tools?

[Vasudev Kamath]

Salvatore Bonaccorso  writes:

> Hi Mika,
>
> On Sat, Feb 13, 2021 at 09:42:53AM +0100, Michael Prokop wrote:
>> * Michael Prokop [Wed Dec 30, 2020 at 11:11:32PM +0100]:
>> 
>> > With the ongoing efforts around BTF and CO-RE (see
>> > http://www.brendangregg.com/blog/2020-11-04/bpf-co-re-btf-libbpf.html),
>> > it would be nice to have a decent and working toolchain for it with
>> > our upcoming bullseye release.
>> 
>> [...]
>> 
>> > So IMO it would be great, if it's possible to ship libbpf-tools on
>> > Debian/bullseye systems without giving it much thoughts due to
>> > dependencies and disk space requirements.
>> 
>> The train for bullseye has left AFAICT, but there are ongoing efforts
>> regarding the packaging for other distributions at
>> https://github.com/iovisor/bcc/pull/3263 and it might make sense to
>> jump onto it.
>
> Yupp, that is the case, from this point on one cannt introduce new
> binary packages even built from an existing source, cf.
> https://lists.debian.org/debian-devel-announce/2021/02/msg2.html .

I waited till now because I thought it will make sense for the upstream
to add some install target and possibly integrate with their CMake so I
don't need to craft more things just to get it installed.

>
> That said would have been nice to have it in bullseye, but let's aim
> for bookworm :).

Definitely I would package it for experimental once the next release
with required changes from the PR pointed is released.

Also though the train for bullseye has left I will still backport this
new libbpf-tools once bullseye is released just like currently I'm doing
it for buster. (All latest releases are in buster backports)


Cheers,
Vasudev

Bug#980296: bpfcc-tools: ${lang}gc-bpfcc and ${lang}stat-bpfcc do not work properly

[Vasudev Kamath]

Vasudev Kamath  writes:

> Ritesh Raj Sarraf  writes:
>
>> Hi Vasudev,
>>
>> On Mon, 2021-01-18 at 09:27 +0530, Vasudev Kamath wrote:
>>> Ritesh Raj Sarraf  writes:
>>> 
>>> > I had fixed this some time ago. Looks like the recent new updates
>>> > needed a
>>> > new adaptation. Thanks for reporting this bug
>>> > 
>>> 
>>> I had fixed a couple of paths before but this one I did not find out.
>>> If
>>> you are not considering fixing this I will go ahead and fix it.
>>> 
>>
>> Please do. I think the commit is this one:
>> ce63c32a4ac81d9a960e36adf160aedb3d7407d0
>>
>> It may just need some checks and re-validation.
>
> I don't see anything changed in the commit. I just reformatted very long
> lines into shorter lines nothing was removed from your code.

Never mind I got where I broke the code. I'm on to fixing this.

Cheers,
Vasudev

Bug#980296: bpfcc-tools: ${lang}gc-bpfcc and ${lang}stat-bpfcc do not work properly

[Vasudev Kamath]

Ritesh Raj Sarraf  writes:

> Hi Vasudev,
>
> On Mon, 2021-01-18 at 09:27 +0530, Vasudev Kamath wrote:
>> Ritesh Raj Sarraf  writes:
>> 
>> > I had fixed this some time ago. Looks like the recent new updates
>> > needed a
>> > new adaptation. Thanks for reporting this bug
>> > 
>> 
>> I had fixed a couple of paths before but this one I did not find out.
>> If
>> you are not considering fixing this I will go ahead and fix it.
>> 
>
> Please do. I think the commit is this one:
> ce63c32a4ac81d9a960e36adf160aedb3d7407d0
>
> It may just need some checks and re-validation.

I don't see anything changed in the commit. I just reformatted very long
lines into shorter lines nothing was removed from your code.

>
>> May be we should also consider using autopkgtest to make sure all
>> utilities are working  as expected.
>
> Yes. Please feel free to add it. I haven't really been on top of
> autopkgtest feature but that's something I know can be very useful.
>
Sure will have a look at this may be at later point of time.

Cheers,
Vasudev

Bug#980296: bpfcc-tools: ${lang}gc-bpfcc and ${lang}stat-bpfcc do not work properly

[Vasudev Kamath]

Hi Ritesh,

Ritesh Raj Sarraf  writes:

> I had fixed this some time ago. Looks like the recent new updates needed a
> new adaptation. Thanks for reporting this bug
>

I had fixed a couple of paths before but this one I did not find out. If
you are not considering fixing this I will go ahead and fix it.

May be we should also consider using autopkgtest to make sure all
utilities are working  as expected.

Cheers,
Vasudev

Bug#957037: biboumi: ftbfs with GCC-10

[Vasudev Kamath]

Michel Le Bihan  writes:

> Hello,
>
> I opened a merge request, but merging all branches into your repo
> might cause issues in the upstream branch in the future due to the
> merge commits. Instead, it will be best to pull all branches from my
> repo into branches of your repo, but without adding merge commits or
> at least without adding them to the upstream and pristine tar
> branches.

Thank you I've given some review comments, please incorporate them. I
think merging all branches will not cause any problems, I've done in
simiar way for bpfcc-tools as well.

Cheers,
Vasudev

Bug#979016: libbpfcc: vendors libbpf

[Vasudev Kamath]

Luca Boccassi  writes:

> Package: libbpfcc
> Version: 0.8.0-4
> Severity: important
> Tags: bullseye patch
>
> Dear Maintainer(s),
>
> libbpfcc vendors and statically links against libbpf, which is now
> available in the Debian archive as a fully maintained shared library.
>
> This is a problem in the upstream CMake files, I've sent a PR to fix it:
>
> https://github.com/iovisor/bcc/pull/3210
>
> I have also prepared a backport and tested it, and opened a MR on Salsa:
>
> https://salsa.debian.org/debian/bpfcc/-/merge_requests/9
>
> This allows to unvendor the library, and only link against it
> dynamically from the packaged version.
>
> Please consider applying it before the bullseye freeze.

Thank you Luca, I've been trying to get this working for some time now
but was failing due to CMakefile issue I even reported the same to
upstream but with little help. Since I was not very well versed in CMake
I gave up.

I will review this and merge it soon.

Cheers,
Vasudev

Bug#957037: biboumi: ftbfs with GCC-10

[Vasudev Kamath]

Michel Le Bihan  writes:

> Le mardi 22 décembre 2020 à 17:35 +0530, Vasudev Kamath a écrit :
>> Jonas Smedegaard  writes:
>> 
>> > Quoting Michel Le Bihan (2020-12-20 17:15:29)
>> > > Le dimanche 20 décembre 2020 à 16:50 +0100, Jonas Smedegaard a
>> > > écrit :
>> > > > Quoting Michel Le Bihan (2020-12-20 16:06:27)
>> > > > > A quick summary of the differences between both repos:
>> > > > 
>> > > > Thanks, that is no doubt helpful!
>> > > > 
>> > > > [ beware: commenting without actually having looked at the
>> > > > code! ]
>> > > Please look at it when you will have time.
>> > 
>> > Most likely no: Instead, please wait for Vasudev to look at it.
>> 
>> I was looking at biboumi repository and did not see any merge
>> requests
>> on it. Jonas do we need to enable something in repo to allow merge
>> requests?.
>> 
> Yes. You need to enable merge requests in the repository settings. They
> are currently disabled.

Done, it took me a while to navigate around the settings. Please raise
MR so I can review.

Cheers,
Vasudev

Bug#957037: biboumi: ftbfs with GCC-10

[Vasudev Kamath]

Jonas Smedegaard  writes:

> Quoting Michel Le Bihan (2020-12-20 17:15:29)
>> Le dimanche 20 décembre 2020 à 16:50 +0100, Jonas Smedegaard a écrit :
>> > Quoting Michel Le Bihan (2020-12-20 16:06:27)
>> > > A quick summary of the differences between both repos:
>> > 
>> > Thanks, that is no doubt helpful!
>> > 
>> > [ beware: commenting without actually having looked at the code! ]
>> Please look at it when you will have time.
>
> Most likely no: Instead, please wait for Vasudev to look at it.

I was looking at biboumi repository and did not see any merge requests
on it. Jonas do we need to enable something in repo to allow merge
requests?.

@Michel/Alberto it would be great if you can raise a merge request. It
will be easier for me to look at the changes faster.
>
>
>> > Now that you joined the team maintaining the package, it is not an 
>> > NMU.
>> > 
>> Should I change that? Somebody would have to add me to debian/control, 
>> but I don't want to rebase my fork on that commit for that change.
>
> My point was more general about when that annotation was needed.
>
> I'll leave the details of handling this concrete changeset to Vasudev.
>

You can add yourself to debian/control and commit that changes. No need
for waiting for some one else to add you there :-).

Please keep me in Cc I might miss the mails otherwise.

Cheers,
Vasudev

Bug#957037: biboumi: ftbfs with GCC-10

[Vasudev Kamath]

Hi Alberto,

> I have checked that current upstream (9.0) builds flawlessly, and made
> my release available at https://salsa.debian.org/aluaces-guest/biboumi
> .

That is great.

> Can I be sponsored so we can upload to at least experimental?

Sure, please raise a merge request against biboumi and I will try to
review your work and sponsor the upload for you. I would be happy if you
can join us in maintaining biboumi. Both me and Jonas are bit busy and
not getting enough time for maintaining biboumi properly.

Cheers,
Vasudev

Bug#976596: bpfcc FTBFS: symbol differences

[Vasudev Kamath]

Hi Adrian,

Adrian Bunk  writes:

> Source: bpfcc
> Version: 0.17.0-7
> Severity: serious
> Tags: ftbfs
>
> This might be due to the LLVM 9 -> 11 transition,
> or for other reasons.
>
> The general problem of shipping symbols files for C++ code
> is discussed at https://wiki.debian.org/UsingSymbolsFiles
>

Thanks for reporting. The page suggests its better not to ship symbols
file for C++ libraries but lintian complains otherwise. Hence the reason
I introduced symbol file. I think I will drop it in the next release as
its becoming painful for me to maintain the symbols file.

Cheers,
Vasudev

Bug#949863: #949863: please enable CONFIG_NET_SWITCHDEV

[Vasudev Kamath]

Vasudev Kamath  writes:

> Salvatore Bonaccorso  writes:
>
>> Hi 
>>
>> On Tue, Sep 15, 2020 at 02:00:51PM +0530, Vasudev Kamath wrote:
>>> Tzafrir Cohen  writes:
>>> 
>>> > Hi,
>>> >
>>> > A patch for fix of the regression is in 4.19.145 (commit 
>>> > 044be307e550b4532960eadabfb6942de96751f0  "net/mlx5e: Don't support phys 
>>> > switch id if not in switchdev mode").
>>> >
>>> > Please enable CONFIG_NET_SWITCHDEV once this is merged to the Buster 
>>> > kernel tree.
>>> >
>>> > -- Tzafrir
>>> 
>>> I just created another ticket as this bug is already archived [1]. And
>>> mail is not getting tracked in the BTS.
>>> 
>>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970350
>>
>> Please have look at 
>> https://salsa.debian.org/kernel-team/linux/-/merge_requests/278 
>>
>> Still it should be evaluated if this has no other impact as it was
>> previously only enabled for armhf.
>
> We are already using this in our production with custom compiled kernel
> based on kernel in 10.4.(one with regression issue still present but
> workaround done manually) (Currently we have 50+ machines running  this
> and will eventually increase it).
>
> I will check this with current buster kernel from 10.5 where regression
> issue fix is applied and update here.

I compiled 10.6 kernel 4.19.152 with your MR patch and tested on our
setup. I can confirm no more regression issue is found on both network
setup we use (bonding and non-bonding).

As for the NET_SWITCHDEV we have this enabled in our production machine
from kernel compiled in 10.3 with this patch. And its been running for 2
months or so without any issue.

Please consider merging this patch and release it as part of Debian 10.7
release.

Cheers,
Vasudev

Bug#949863: #949863: please enable CONFIG_NET_SWITCHDEV

[Vasudev Kamath]

Salvatore Bonaccorso  writes:

> Hi 
>
> On Tue, Sep 15, 2020 at 02:00:51PM +0530, Vasudev Kamath wrote:
>> Tzafrir Cohen  writes:
>> 
>> > Hi,
>> >
>> > A patch for fix of the regression is in 4.19.145 (commit 
>> > 044be307e550b4532960eadabfb6942de96751f0  "net/mlx5e: Don't support phys 
>> > switch id if not in switchdev mode").
>> >
>> > Please enable CONFIG_NET_SWITCHDEV once this is merged to the Buster 
>> > kernel tree.
>> >
>> > -- Tzafrir
>> 
>> I just created another ticket as this bug is already archived [1]. And
>> mail is not getting tracked in the BTS.
>> 
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970350
>
> Please have look at 
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/278 
>
> Still it should be evaluated if this has no other impact as it was
> previously only enabled for armhf.

We are already using this in our production with custom compiled kernel
based on kernel in 10.4.(one with regression issue still present but
workaround done manually) (Currently we have 50+ machines running  this
and will eventually increase it).

I will check this with current buster kernel from 10.5 where regression
issue fix is applied and update here.

Regards,
Vasudev

Bug#942290: libbpfcc: libbcc_bpf.so: needs to link with -lelf

[Vasudev Kamath]

Ritesh Raj Sarraf  writes:

> If you have some spare cycles for bpfcc, it could use your help.
>

I'm bit confused here, is this the upstream issue?. Or I need to patch
the upstream CMake to make sure these linker options are passed?.

Some input appreciated.

Cheers,
Vasudev

Bug#949863: #949863: please enable CONFIG_NET_SWITCHDEV

[Vasudev Kamath]

Tzafrir Cohen  writes:

> Hi,
>
> A patch for fix of the regression is in 4.19.145 (commit 
> 044be307e550b4532960eadabfb6942de96751f0  "net/mlx5e: Don't support phys 
> switch id if not in switchdev mode").
>
> Please enable CONFIG_NET_SWITCHDEV once this is merged to the Buster 
> kernel tree.
>
> -- Tzafrir

I just created another ticket as this bug is already archived [1]. And
mail is not getting tracked in the BTS.

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

Bug#970350: linux: Enable CONFIG_NET_SWITCHDEV in Buster kernel

[Vasudev Kamath]

Source: linux
Version: 4.19.132-1
Severity: normal

Dear Maintainer,

The regression issue which I reported in [1] has been fixed by Mellanox upstream
[2] and is now part of linux-4.19.145-1 [3]. So can we now enable the 
CONFIG_NET_SWITCHDEV
support in Debian Buster?

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949863#43
[2] https://lkml.org/lkml/2020/8/7/451
[3] https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.145


Cheers,
Vasudev


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

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

Bug#965263: debian-installer: Script exected in preseed/late_command on dual CPU socket system sees only Single CPU socket

[Vasudev Kamath]

Vasudev Kamath  writes:

> Geert Stappers  writes:
>
>> On Sat, Jul 18, 2020 at 06:19:55PM +0530, Vasudev Kamath wrote:
>>> 
>>> Please let me know if you need more information.
>>> 
>>
>> Both kernel versions
>
> We mirror Debian repository on daily basis and found this bug with
> latest installer released with Stretch 9.12 and Buster 10.4.
>
> Buster: linux-image-4.19.0-9-amd64 (4.19.118-2+deb10u1)
> Stretch: linux-image-4.9.0-12-amd64 (4.9.210-1+deb9u1)

Is there anything else needed from my side?. I'm just curious to know
why numa node becomes single in installer.

Cheers,
Vasudev

Bug#966229: ITP: protocol -- a simple command line tool for displaying standard network protocol headers

[Vasudev Kamath]

Ben Hutchings  writes:

> On Sat, 2020-07-25 at 08:36 +0530, Vasudev Kamath wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Vasudev Kamath 
>> 
>> * Package name: protocol
>
> I think this name is too generic.

Any suggestions?. I'm bad with choosing names

>
>>   Version : 0.1
>>   Upstream Author : Luis MartinGarcia 
>> * URL : http://www.luismg.com/protocol/
>> * License : GPL-3.0
>>   Programming Lang: Python
>>   Description : a simple command line tool for displaying standard 
>> network protocol headers
>> 
>>  Protocol is a simple command-line tool that serves two purposes:
>>- Provide a simple way for engineers to have a look at standard network 
>> protocol headers, directly
>>  from the command-line, without having to google for the relevant RFC or 
>> for ugly header image
>>  diagrams.
>>- Provide a way for researchers and engineers to quickly generate ASCII 
>> RFC-like header diagrams for
>>  their own custom protocols.
>
> It sounds quite useful though.

Bug#966229: ITP: protocol -- a simple command line tool for displaying standard network protocol headers

[Vasudev Kamath]

Package: wnpp
Severity: wishlist
Owner: Vasudev Kamath 

* Package name: protocol
  Version : 0.1
  Upstream Author : Luis MartinGarcia 
* URL : http://www.luismg.com/protocol/
* License : GPL-3.0
  Programming Lang: Python
  Description : a simple command line tool for displaying standard network 
protocol headers

 Protocol is a simple command-line tool that serves two purposes:
   - Provide a simple way for engineers to have a look at standard network 
protocol headers, directly
 from the command-line, without having to google for the relevant RFC or 
for ugly header image
 diagrams.
   - Provide a way for researchers and engineers to quickly generate ASCII 
RFC-like header diagrams for
 their own custom protocols.

 - why is this package useful/relevant?
   It is useful for observing headers of Standard Network protocol without 
going to need to go through
   wiki page for protocol or from RFC documents.
   It is also helpful to generate RFC like ASCII header diagram for custom 
protocol.

 - how do you plan to maintain it?
   For now myself, might consider later to move it to Python application team.

Bug#965263: debian-installer: Script exected in preseed/late_command on dual CPU socket system sees only Single CPU socket

[Vasudev Kamath]

Geert Stappers  writes:

> On Sat, Jul 18, 2020 at 06:19:55PM +0530, Vasudev Kamath wrote:
>> 
>> Please let me know if you need more information.
>> 
>
> Both kernel versions

We mirror Debian repository on daily basis and found this bug with
latest installer released with Stretch 9.12 and Buster 10.4.

Buster: linux-image-4.19.0-9-amd64 (4.19.118-2+deb10u1)
Stretch: linux-image-4.9.0-12-amd64 (4.9.210-1+deb9u1)

Cheers,
Vasudev

Bug#965263: debian-installer: Script exected in preseed/late_command on dual CPU socket system sees only Single CPU socket

[Vasudev Kamath]

Package: debian-installer
Severity: normal

Dear Maintainer,

I recently moved some code to preseed/late_command script to do the CPU pinning 
for host machine.

Script snippet looks something like below

NODE_CPUS=2
for node in /sys/devices/system/node/node[0-9]; do
cat $node/cpu[0-9]*/topology/thread_siblings_list | sort 
-nu | sed 's/,/\n/' | head -n$NODE_CPUS
done

It captured a sibling core from only node0 of the system. So out of curiosity I 
observed the logs we captured
on rsyslog server and found what I see below

Jul 14 09:45:18 10.33.97.110 in-target: ++ cat 
/sys/devices/system/node/node0/cpu0/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu10/topology/thread_siblings_list 
/sys/devices/system/no
de/node0/cpu11/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu12/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu13/topology/thread_siblings_list 
/sys/devices/system/nod
e/node0/cpu14/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu15/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu16/topology/thread_siblings_list 
/sys/devices/system/node
/node0/cpu17/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu18/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu19/topology/thread_siblings_list 
/sys/devices/system/node/
node0/cpu1/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu20/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu21/topology/thread_siblings_list 
/sys/devices/system/node/no
de0/cpu22/topology/thr
Jul 14 09:45:18 10.33.97.110 in-target: 
system/node/node0/cpu23/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu24/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu25/topo
logy/thread_siblings_list 
/sys/devices/system/node/node0/cpu26/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu27/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu28/topol
ogy/thread_siblings_list 
/sys/devices/system/node/node0/cpu29/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu2/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu30/topolog
y/thread_siblings_list 
/sys/devices/system/node/node0/cpu31/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu32/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu33/topology
/thread_siblings_list 
/sys/devices/system/node/node0/cpu34/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu35/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu36/topology/
thread_siblings_list /
Jul 14 09:45:18 10.33.97.110 in-target: pu37/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu38/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu39/topology/thread_sibling
s_list /sys/devices/system/node/node0/cpu3/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu40/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu41/topology/thread_siblings_
list /sys/devices/system/node/node0/cpu42/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu43/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu44/topology/thread_siblings_l
ist /sys/devices/system/node/node0/cpu45/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu46/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu47/topology/thread_siblings_li
st /sys/devices/system/node/node0/cpu48/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu49/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu4/topology/thread_siblings_list
 /sys/devices/system/n
Jul 14 09:45:18 10.33.97.110 in-target: _siblings_list 
/sys/devices/system/node/node0/cpu51/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu52/topology/thread_siblings_list /sys/devices/
system/node/node0/cpu53/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu54/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu55/topology/thread_siblings_list 
/sys/devices/s
ystem/node/node0/cpu56/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu57/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu58/topology/thread_siblings_list 
/sys/devices/sy
stem/node/node0/cpu59/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu5/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu60/topology/thread_siblings_list 
/sys/devices/syst
em/node/node0/cpu61/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu62/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu63/topology/thread_siblings_list 
/sys/devices/syste
m/node/node0/cpu64/top
Jul 14 09:45:18 10.33.97.110 in-target: 
/devices/system/node/node0/cpu65/topology/thread_siblings_list 
/sys/devices/system/node/node0/cpu66/topology/thread_siblings_list 

Bug#949863: [Vasudev Kamath] Re: Bug#949863: Info received (#949863: please enable CONFIG_NET_SWITCHDEV)

[Vasudev Kamath]

Sending it to BTS to track in bug log.

--- Begin Message ---

[Sending reply to bug so we can have a record of discussion]

[Please keep Ashruth and my colleague in CC while replying]

Tzafrir Cohen  writes:
[snip]
>> 
>> I don't think we should make a config change that hurts users of stock
>> Debian, for the benefit of those using out-of-tree drivers.  And in a
>> stable point release, a known regression like that is unacceptable.
>
> Could you please clarify: is that a regression? That is: in the current
> Buster kernel the problem does not exist?

Yes it looks like regression. Had a discussion with Mellanox (Ashruth
Cced) and looks like its fixed upstream [1]. Currently we found a work
around for this that is to make bonding enabled first and then enable
SR-IOV. This bug happens only if we have enabled SR-IOV on slave
interface  before enabling bond.


Ashruth is [1] the right patch?. If not can you point to right patch?.


Ben if a patch is available in main-stream can that be cherry picked to
stable point release to enable this config option?.

[1] 
https://github.com/torvalds/linux/commit/7ff40a46dd188b83311203e72cedf42eb264fdf1


Cheers,
Vasudev
--- End Message ---

Bug#962791: pristine-tar: pristine-xz failed to reproduce build of ../libvirt_6.4.0.orig.tar.xz

[Vasudev Kamath]

Package: pristine-tar
Version: 1.47
Severity: normal

Dear Maintainer,

Unable to import the new version of libvirt [1]. Seeing following message

bp:info: Importing '../libvirt_6.4.0.orig.tar.xz' to branch 'upstream/latest'...
gbp:info: Source package is libvirt
gbp:info: Upstream version is 6.4.0
gbp:error: Import of ../libvirt_6.4.0.orig.tar.xz failed: Couldn't commit to 
'pristine-tar' with upstream '5d1f17e4035e01548d006d598922650408f56703': 
pristine-xz failed to reproduce build of ../libvirt_6.4.0.orig.tar.xz
(Please file a bug report.)
pristine-tar: failed to generate delta
gbp:error: Error detected, Will roll back changes.
gbp:info: Rolling back branch upstream/latest by resetting it to 
1b6982f1b5d95a81eef1a112d0b1b228d7f910b2
gbp:info: Rolling back branch pristine-tar by resetting it to 
9964e57257fc955481effec950da206799e0cbe1
gbp:error: Rolled back changes after import error.


[1] https://libvirt.org/sources/libvirt-6.4.0.tar.xz

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

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

Versions of packages pristine-tar depends on:
ii  bzip21.0.8-3
ii  libbz2-1.0   1.0.8-3
ii  libc62.30-8
ii  libsys-cpuaffinity-perl  1.12-1+b4
ii  pbzip2   1.1.13-1
ii  perl 5.30.3-4
ii  pixz 1.0.6-3
ii  tar  1.30+dfsg-7
ii  xdelta   1.1.3-9.3
ii  xdelta3  3.0.11-dfsg-1+b1
ii  xz-utils 5.2.4-1+b1
ii  zlib1g   1:1.2.11.dfsg-2

pristine-tar recommends no packages.

pristine-tar suggests no packages.

-- no debconf information

Bug#954290: kexec doesn't do reboots on systemd install?

[Vasudev Kamath]

Khalid Aziz  writes:

>
> kdump relies upon kexec but it is configured separately by kdump-tools.
> kexec works just fine with systemd. It is just the wording of configure
> message in kexec-tools package that is misleading and needs fixing.

Yes that was part of my confusion too. Was wondering it still does not
work well with systemd, which lead me to this bug report.

> If you are not seeing kernel crash dump on panic, take a look at
> /etc/default/kdump-tools file and make sure it is configured
> correctly.

Sure I will have a look at that too. We normally just install
kdump-tools and be done with it. Let me check if there is anything I
need to tweak there.

Cheers,
Vasudev

Bug#954290: kexec doesn't do reboots on systemd install?

[Vasudev Kamath]

Vasudev Kamath  writes:

> In our setup of Debian 9 we noticed many kernel panic which never crash
> dumped so was searching if there is something wrong in our setup and
> came across this bug. While looking at systemd I noticed there is a
> service called systemd-kexec.service which is disabled by default. Is
> this needs to be enabled for kexec to work correctly with systemd?
>
> If this service is needed may be should be enabled on installing
> kexec-tools?

May be I misunderstood relation between kdump-tools and kexec-tools. If
so please ignore above message :-). Was actually looking at [1] which
gave me a feeling that something is missing in my setup and wrote above
mail

[1] https://wiki.archlinux.org/index.php/Kdump

Cheers,
Vasudev

Bug#954290: kexec doesn't do reboots on systemd install?

[Vasudev Kamath]

In our setup of Debian 9 we noticed many kernel panic which never crash
dumped so was searching if there is something wrong in our setup and
came across this bug. While looking at systemd I noticed there is a
service called systemd-kexec.service which is disabled by default. Is
this needs to be enabled for kexec to work correctly with systemd?

If this service is needed may be should be enabled on installing
kexec-tools? 

Cheers,
Vasudev

Bug#961197: debmirror does not clean up temporary files created under /tmp

[Vasudev Kamath]

Package: debmirror
Version: 1:2.33
Severity: normal

Dear Maintainer,

I noticed this behavior initially on the stretch-backports version, but later 
when
I tried the same command on my machine the behavior is reproducible. Below is 
sample 
command I used for testing 

debmirror /var/iaas/mirror/haproxy \
  --host=haproxy.debian.net \
  --root=/ \
  
--dist=stretch-backports-2.0,stretch-backports-2.1,buster-backports-2.0,buster-backports-2.1
 \
  --section=main \
  --arch=amd64 \
  --method=https \
  --passive \
  --diff=none \
  --ignore-release-gpg \
  --verbose

And here is the diff of /tmp by taking snapshot before and after

--- before_debmirror.txt2020-05-21 15:19:30.710068000 +0530
+++ after_debmirror.txt 2020-05-21 15:20:05.976893417 +0530
@@ -1,9 +1,16 @@
+2g8taRZ2Dw
 ansible.log
 buffer-content-i0n7Uo
 buffer-content-wxX59x
+ChfueO3OHV
 emacs1000
+F7OHZC5krQ
 glances-root.log
+GvqWvOOVf5
 mozilla_vasudeva.sk0
+NCDUPNUx3h
+nV70xg9Llw
+ORoXEgAa4H
 publish.log.2
 quassel-sni-hSXRjz
 systemd-private-3261897ec05a471796a734455aaff97c-bolt.service-Wq2hMf
@@ -27,3 +34,4 @@
 tracker-extract-files.116
 tracker-extract-files.65534
 x.582365
+xQAxVhHqgK

These files are either GPG signatures or contents file downloaded from mirror. 
In my case since
I was not noticing this it seems to pile up and emptied the root disk space. 
That is when I noticed 
this. For now in my machine I've a hourly cron job clearing up tmp file but it 
would be good to
have a proper fix for the same.

Please let me know if any further information is needed from my side.

Cheers,
Vasudev



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

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

Versions of packages debmirror depends on:
ii  bzip21.0.8-2
pn  libdigest-md5-perl   
pn  libdigest-sha-perl   
ii  liblockfile-simple-perl  0.208-1
ii  libwww-perl  6.44-1
ii  perl [libnet-perl]   5.30.2-1
ii  rsync3.1.3-8
ii  xz-utils 5.2.4-1+b1

Versions of packages debmirror recommends:
ii  ed 1.16-1
ii  gpgv   2.2.20-1
ii  patch  2.7.6-6

Versions of packages debmirror suggests:
ii  gnupg  2.2.20-1

-- no debconf information


debmirror-tempfile.tgz
Description: Unix tar archive

Bug#937413: pycryptopp: Python2 removal in sid/bullseye

[Vasudev Kamath]

Hi Moritz,

Moritz Mühlenhoff  writes:
>
> Hi Vasudev,
>
> https://github.com/tahoe-lafs/pycryptopp/issues/36#issuecomment-504130020 
> states:
>
> | The Tahoe-LAFS project has decided it is not interested in porting
> | pycryptopp to Python 3. Instead, Tahoe-LAFS is switching to the
> | "cryptography" library.
> | 
> | I don't have any problem with anyone else taking on this porting effort
> | but I'm closing this to reflect the fact that the maintainers have
> | no plans of taking this on.
>
> Given that the now removed tahoe-lafs was the only reverse dependency,
> let's also remove pycryptopp?

Right upstream stopped using it a while ago but I could not get that
change in tahoe-lafs during that time due to dependency on
magic-wormhole lib which was py3 only and could not work with
tahoe-lafs in archive.

I missed  this let me file a bug to get this as well removed from the
archive. Thanks for bringing this up.

Cheers,
Vasudev

Bug#959844: RM: pycryptopp -- ROM; upstream no longer has intent to support python 3

[Vasudev Kamath]

Package: ftp.debian.org
Severity: normal

As mentioned in [1] upstream has moved from pycryptopp to cryptography
library for tahoe-lafs and tahoe was the only dependency using this
package. Since there is no intent by upstream to provide py3 support for
this library I'm requesting its removal from archive.


[1] https://github.com/tahoe-lafs/pycryptopp/issues/36#issuecomment-504130020

Cheers,
Vasudev

Bug#959691: RM: tahoe-lafs -- ROM; python2 only no python3 support is available from upstream

[Vasudev Kamath]

Package: ftp.debian.org
Severity: normal


Requesting the removal of this package as suggested in [1]. Currently
there is no support of Python3 and package is python2 only. Upstream is
working on Python3 package but there is no clear ETA yet on when it will
be ready. I will reintroduce the package once the usptream ports it to
python3.


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

Cheers,
Vasudev

Bug#949863: Info received (#949863: please enable CONFIG_NET_SWITCHDEV)

[Vasudev Kamath]

Ben Hutchings  writes:

> On Mon, 9 Mar 2020 13:58:38 +0200 Tzafrir Cohen  wrote:
>> Hi,
>> 
>> > Also: please consider this change for inclusion in a stable update, if
>> > possible.
>> 
>> I see that this was merged into git. Thanks. What are the chances of
>> this fix getting included into Debian 10.4 to allow OVS off-loading there?
>
> I think it's reasonable, but will need to consult with the release
> team.  In case this should only happen after the change has gone into
> unstable and testing.

Wanted to update my findings on Buster with this patch. We use Mellanox
Connect-X5 series nic (dual port) and have a bonded setup.

Both ports are bonded with 802.3ad and the bond device is put on a
bridge (br0) and br0 gets the IP address.

In this setup with CONFIG_NET_SWITCHDEV enabled bond0 is not placed on
br0 and I see a message:

ifup: can't add bond0 to bridge br0: No data available

This happens with Mellanox inbox driver in Kernel but if I install
latest OFED there is no issue. So I'm not sure how other NIC's behave
with this option enabled.

Cheers,

Bug#951047: udev/rules.d/50-udev-default.rules: Invalid GROUP operation

[Vasudev Kamath]

Michael Biebl  writes:

> Am 23.03.20 um 05:02 schrieb Vasudev Kamath:
>> Michael Biebl  writes:
>> 
>>>>
>>>>
>>>> I see above message in syslog as well. Also this is a fresh Buster
>>>> installation. If you want any more information let me know and I can try
>>>> to provide that.
>>>
>>> Yes, please provide steps how this can be reproduced.
>> 
>> Well every time I reboot I see this message. Other than that I don't
>> have any specific way to reproduce. 
> As said earlier in the bug report, the udev hook provided by the Debian
> udev package uses
>
> SYSTEMD_LOG_LEVEL=$log_level /lib/systemd/systemd-udevd --daemon
> --resolve-names=never
>
> I.e. it should not cause any such error messages.
>
> So I assume your initramfs is modified in a way which overrides the way
> systemd-udevd is started.
> You should investigate in that direction and check how your initramfs is
> assembled.

I've not done any changes to initramfs on this system. It is the default
initramfs which came with Buster installation. I'm seeing this message
from the freshly installed Buster system. I can confirm this give me
some time so I can install it on another box to see if message comes
back.

Cheers,

Bug#951047: udev/rules.d/50-udev-default.rules: Invalid GROUP operation

[Vasudev Kamath]

Control: reopen -1

I also see these messages in the startup and it seems to be originating
from initramfs.

Mar 20 15:41:59 fk-cloud-d3a-ms-1375774 kernel: <1051>[7.441386] 
systemd-udevd[585]: /usr/lib/udev/rules.d/50-udev-default.rules:18: Invalid 
GROUP operation
Mar 20 15:41:59 fk-cloud-d3a-ms-1375774 kernel: <1051>[7.441515] 
systemd-udevd[585]: /usr/lib/udev/rules.d/50-udev-default.rules:19: Invalid 
GROUP operation
Mar 20 15:41:59 fk-cloud-d3a-ms-1375774 kernel: <1051>[7.441640] 
systemd-udevd[585]: /usr/lib/udev/rules.d/50-udev-default.rules:20: Invalid 
GROUP operation
Mar 20 15:41:59 fk-cloud-d3a-ms-1375774 kernel: <1051>[7.441763] 
systemd-udevd[585]: /usr/lib/udev/rules.d/50-udev-default.rules:21: Invalid 
GROUP operation
Mar 20 15:41:59 fk-cloud-d3a-ms-1375774 kernel: <1051>[7.441885] 
systemd-udevd[585]: /usr/lib/udev/rules.d/50-udev-default.rules:22: Invalid 
GROUP operation
Mar 20 15:41:59 fk-cloud-d3a-ms-1375774 kernel: <1051>[7.442007] 
systemd-udevd[585]: /usr/lib/udev/rules.d/50-udev-default.rules:23: Invalid 
GROUP operation
Mar 20 15:41:59 fk-cloud-d3a-ms-1375774 kernel: <1051>[7.442129] 
systemd-udevd[585]: /usr/lib/udev/rules.d/50-udev-default.rules:24: Invalid 
GROUP operation
Mar 20 15:41:59 fk-cloud-d3a-ms-1375774 kernel: <1051>[7.442252] 
systemd-udevd[585]: /usr/lib/udev/rules.d/50-udev-default.rules:25: Invalid 
GROUP operation
Mar 20 15:41:59 fk-cloud-d3a-ms-1375774 kernel: <1051>[7.442428] 
systemd-udevd[585]: /usr/lib/udev/rules.d/50-udev-default.rules:27: Invalid 
GROUP operation


I see above message in syslog as well. Also this is a fresh Buster
installation. If you want any more information let me know and I can try
to provide that.

Cheers,
Vasudev

Bug#948404: glances crashes on startup

[Vasudev Kamath]

Hi Daniel,

Daniel Echeverry  writes:

> On Wed, Jan 08, 2020 at 11:25:05PM -0500, Daniel Echeverry wrote:
>> tags 948404 + moreinfo unreproducible
>> thanks
>> 
>> Hi!
>> 
>> Thanks for your report! Unfortunately I can't reproduce this bug, I install 
>> glances via ap-get install and works fine, However, I think that bug is 
>> related with this other bug[1], One Question, Do you have network interfaces?
>> 
>> Regards.
>> 
>> [1]: https://github.com/nicolargo/glances/issues/1535
>
> Hi!
>
> Excuse me, In the reply, I forgot to cc you, do you see the message? 

Yes I indeed have network interface

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: docker0:  mtu 1500 qdisc noqueue state 
DOWN mode DEFAULT group default 
link/ether 02:42:11:40:33:45 brd ff:ff:ff:ff:ff:ff
8: wlp3s0:  mtu 1500 qdisc pfifo_fast state UP 
mode DORMANT group default qlen 1000
link/ether 64:5a:ed:e8:cc:87 brd ff:ff:ff:ff:ff:ff


But now I can launch glances fine. I'm not sure what really changed. I
did a couple of update of system initially glances from pip was only
getting launched.

I think for now the bug can safely be closed. Thanks for maintaining
glances in Debian

Cheers,
Vasudev

Bug#948404: glances crashes on startup

[Vasudev Kamath]

Package: glances
Version: 3.1.1-1
Severity: grave
Justification: Renders glances use less

Dear Maintainer,

I installed glances from Debian repository and when trying to launch It crashes 
with following stack trace

Error while initializing the ip plugin ('NoneType' object has no attribute 
'split')
Traceback (most recent call last):
File "/usr/bin/glances", line 11, in 
load_entry_point('Glances==3.1.3', 'console_scripts', 'glances')()
File "/usr/lib/python3/dist-packages/glances/__init__.py", line 143, in main
start(config=config, args=args)
File "/usr/lib/python3/dist-packages/glances/__init__.py", line 112, in start
mode.serve_forever()
File "/usr/lib/python3/dist-packages/glances/standalone.py", line 151, in 
serve_forever
loop = self.__serve_forever()
File "/usr/lib/python3/dist-packages/glances/standalone.py", line 138, in 
__serve_forever
ret = not self.screen.update(self.stats, duration=adapted_refresh)
File "/usr/lib/python3/dist-packages/glances/outputs/glances_curses.py", line 
982, in update
self.flush(stats, cs_status=cs_status)
File "/usr/lib/python3/dist-packages/glances/outputs/glances_curses.py", line 
957, in flush
self.display(stats, cs_status=cs_status)
File "/usr/lib/python3/dist-packages/glances/outputs/glances_curses.py", line 
581, in display
self.__display_header(__stat_display)
File "/usr/lib/python3/dist-packages/glances/outputs/glances_curses.py", line 
646, in __display_header
self.display_plugin(stat_display["ip"])
KeyError: 'ip'
 

I tried building newer version of glances from upstream, that too fails with 
same error. I installed glances using
pip (3.1.3) and it works fine. Let me know if I can provide any more 
information. 

Cheers,

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

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

Versions of packages glances depends on:
ii  adduser3.118
ii  init-system-helpers1.57
ii  lsb-base   11.1.0
ii  node-normalize.css 8.0.1-3
ii  python33.7.5-3
ii  python3-future 0.16.0-1
ii  python3-pkg-resources  41.4.0-1
ii  python3-psutil 5.6.7-1

Versions of packages glances recommends:
ii  hddtemp 0.3-beta15-53
ii  lm-sensors  1:3.6.0-2
ii  python3-bottle  0.12.15-2
ii  python3-docker  4.1.0-1
ii  python3-influxdb5.2.0-1.1
ii  python3-matplotlib  3.1.2-1
ii  python3-netifaces   0.10.9-0.1
ii  python3-pysnmp4 4.4.6+repack1-1
ii  python3-pystache0.5.4-6.1

Versions of packages glances suggests:
ii  glances-doc 3.1.1-1
pn  python3-pynvml  

-- no debconf information

Bug#938887: zfec: diff for NMU version 1.5.2-2.1

[Vasudev Kamath]

Sandro Tosi  writes:


>
> I've prepared an NMU for zfec (versioned as 1.5.2-2.1). The diff
> is attached to this message.

Thanks Sandro. I've merged your patch into Git.

Cheers,
Vasudev

Bug#944703: nvidia-graphics-drivers: Vcs-* fields points to non existent location for nvidia-graphics-driver source package

[Vasudev Kamath]

Control: merge -1 903302

Looks like there was already a bug for same purpose and already answered
on why its not publicly available. For now I will work using the source
downloaded from Debian archive.

Cheers,

Bug#944703: nvidia-graphics-drivers: Vcs-* fields points to non existent location for nvidia-graphics-driver source package

[Vasudev Kamath]

Source: nvidia-graphics-drivers
Severity: normal

Dear Maintainer,

Vcs-* fields for nvidia-graphics-drivers points to 
https://salsa.debian.org/nvidia-team/nvidia-graphics-drivers
but going to this link leads to 404 error. I'm unable to checkout the source 
using debcheckout
Can some one point me to the right location till this is fixed?

Cheers,
Vasudev

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

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

Bug#944111: bpftrace fails with message "Creation of the required BPF maps has failed."

[Vasudev Kamath]

Vincent Bernat  writes:

>  ❦  4 novembre 2019 18:55 +0530, Vasudeva Sathish Kamath
>  :

Copying Ritesh who is also the maintainer of the libbpfcc

>
> I get the same results. Also, it doesn't work with a 5.2 kernel either.
> Using "strace -febpf", I see the following:
>
> bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_PERCPU_HASH,
> key_size=2296983664, value_size=8, max_entries=8, map_flags=0x1000 /*
> BPF_F_??? */, inner_map_fd=0, map_name="", map_ifindex=0}, 112) = -1
> EINVAL (Invalid argument)
>
> So, the values seem bogus. libbpfcc has been updated recently and it
> doesn't seem to manage a stable ABI. Just recompiling bpftrace against
> the new one makes it work. I am tempted to just bump the version and
> call it a day.

I can confirm this, I rebuilt the bpftrace and it started working. I
faced similar issue with bpfcc-tools where it was segfaulting on some
function in libbpfcc but then when I built and installed upstream
library it suddenly started working. I think this is similar case.

You can rebuild with a Debian version bump and close this bug.

On a side note: I'm just wondering since all these tools are closely
related (bpfcc-tools, libbpfcc, bpftrace) can we have a team and
co-maintain them.  Asking because till libbpfcc stabilizes whenever a
new version of libbpfcc is to be released we can make sure we will
rebuild the bpftrace and any other dependencies which uses libbpfcc.
I'll be happy to join the team for maintaining these tools.

Cheers,

I

Bug#932781: Bug#932428, Bug#932767, Bug#932781: gnome-shell crashes involving monitor changes

[Vasudev Kamath]

Simon McVittie  writes:

> Control: reassign -1 libmutter-3-0 3.30.2-7
> Control: affects -1 gnome-shell
> Control: tags -1 + moreinfo
> Control: forwarded -1 https://gitlab.gnome.org/GNOME/mutter/merge_requests/538
>
> On Mon, 22 Jul 2019 at 08:18:09 +0200, Jörn Heissler wrote:
>> gnome-shell crashes when I suspend my laptop or when I connect an
>> external monitor or disconnect it.
>
> On Tue, 23 Jul 2019 at 10:06:52 -0400, Felipe Sateler wrote:
>> It appears the cause [of a crash] is unplugging my usb C hub, which in turn
>> has the HDMI connector for the external monitor.
>
> On Tue, 23 Jul 2019 at 10:36:59 +0530, Vasudev Kamath wrote:
>> Closing laptop lid normally puts laptop sleep and I get back my session on 
>> reopen. But after recent update
>> I see that I get logged out and closer inspection revealed that gnome-shell 
>> is crashing
>
> I've found an upstream commit that might be the solution for all of these
> crashes. Please try mutter 3.30.2-8 and gnome-shell 3.30.2-10 when they
> become available in unstable. After upgrading you will need to log out
> and back in (or reboot) for the new code to be used.
>
> The actual fix is in mutter, but the updated gnome-shell has a different
> crash fix, and while you're restarting GNOME anyway we might as well get
> wider testing for the updated gnome-shell too...

Yes I can confirm that this fixes all the crash issue. Thanks Simon.

>
> (Lid-close/suspend seems to be treated as a monitor unplug internally,
> which is why it can cause similar crashes.)

Even the external monitor connection crash is resolved.

Cheers,

Bug#932781: gnome-shell crashed on laptop lid close

[Vasudev Kamath]

Control: severity -1 serious

Increasing severity to serious as this is hampering day to day
productivity. Even connecting secondary display causes GNOME shell to
crash with same crash dump as before.

Cheers,
Vasudev

Bug#932781: gnome-shell crashed on laptop lid close

[Vasudev Kamath]

Simon McVittie  writes:

> Control: tags -1 + moreinfo
>
> On Tue, 23 Jul 2019 at 10:36:59 +0530, Vasudev Kamath wrote:
>> Closing laptop lid normally puts laptop sleep and I get back my session on 
>> reopen. But after recent update
>> I see that I get logged out and closer inspection revealed that gnome-shell 
>> is crashing with following error
>> 
>> [  746.169795] gnome-shell[13847]: segfault at 2300022 ip 
>> 7f3718787e04 sp 7ffd56a0f0b0 error 4 in 
>> libwayland-server.so.0.1.0[7f3718787000+7000]
>
> This looks like the same thing as <https://bugs.debian.org/932428>.
>
>> I managed to get the coredump and backtrace of the same.
>
> To confirm, please could you install libwayland-server-0-dbgsym and
> libmutter-3-0-dbgsym and check this backtrace again?

OK Managed to reproduce same crash and attaching the full backtrace of
the same.

>
>> #2  0x7f9198e77ede in send_xdg_output_events
>> (resource=0x7f9184fc4000, 
>> wayland_output=wayland_output@entry=0x55fa9018cd90, 
>> logical_monitor=logical_monitor@entry=0x55fa926ac9e0, 
>> need_all_events=need_all_events@entry=0, 
>> pending_done_event=pending_done_event@entry=0x7ffca0e09144) at 
>> wayland/meta-wayland-outputs.c:553
>
> If you can type
>
> p *resource

(gdb) p *resource
$1 = {object = {interface = 0x7f5877a155d0, implementation = 0x3c, id = 0}, 
destroy = 0x0, link = {prev = 0x1a0001,
next = 0x7f587831ae60 }, 
deprecated_destroy_signal = {listener_list = {prev = 0x0, next = 
0x564d86380ba0}},
  client = 0x564d85937b40, data = 0x0, version = 0, dispatcher = 
0x7f5808115a10, destroy_signal = {listener_list = {prev = 0x0, next = 0x0}, 
emit_list = {
  prev = 0x0, next = 0x0}}}


Cheers,


[sudo] password for vasudeva.sk:
TIMEPID   UID   GID SIG COREFILE  EXE
Thu 2019-07-25 21:38:01 IST4422  1000  1001  11 present   
/usr/bin/gnome-shell
Fri 2019-07-26 09:15:41 IST   15400  1000  1001   6 present   /usr/bin/emacs-gtk
 vasudeva.sk@bhrigu  ~  sudo coredumpctl gdb 4422 
   ✔  1018  09:16:19
   PID: 4422 (gnome-shell)
   UID: 1000 (vasudeva.sk)
   GID: 1001 (vasudeva.sk)
Signal: 11 (SEGV)
 Timestamp: Thu 2019-07-25 21:37:59 IST (11h ago)
  Command Line: /usr/bin/gnome-shell
Executable: /usr/bin/gnome-shell
 Control Group: /user.slice/user-1000.slice/session-73.scope
  Unit: session-73.scope
 Slice: user-1000.slice
   Session: 73
 Owner UID: 1000 (vasudeva.sk)
   Boot ID: dd6e4472cdef44c284b155d24dafe3e6
Machine ID: feb451d304064b3f8706c8703a20adfd
  Hostname: bhrigu
   Storage: 
/var/lib/systemd/coredump/core.gnome-shell.1000.dd6e4472cdef44c284b155d24dafe3e6.4422.156407087900.lz4
   Message: Process 4422 (gnome-shell) of user 1000 dumped core.

Stack trace of thread 4422:
#0  0x7f5874d53e04 wl_resource_post_event 
(libwayland-server.so.0)
#1  0x7f5877763ede zxdg_output_v1_send_logical_size 
(libmutter-3.so.0)
#2  0x7f58777646fb wayland_output_update_for_output 
(libmutter-3.so.0)
#3  0x7f587776488f on_monitors_changed (libmutter-3.so.0)
#4  0x7f5878318e8d g_closure_invoke (libgobject-2.0.so.0)
#5  0x7f587832c555 signal_emit_unlocked_R 
(libgobject-2.0.so.0)
#6  0x7f58783354ae g_signal_emit_valist 
(libgobject-2.0.so.0)
#7  0x7f5878335b6f g_signal_emit (libgobject-2.0.so.0)
#8  0x7f58776d731f 
meta_monitor_manager_notify_monitors_changed (libmutter-3.so.0)
#9  0x7f58776d9557 meta_monitor_manager_rebuild 
(libmutter-3.so.0)
#10 0x7f584ac6 
meta_monitor_manager_kms_apply_monitors_config (libmutter-3.so.0)
#11 0x7f58776d736c 
meta_monitor_manager_apply_monitors_config (libmutter-3.so.0)
#12 0x7f58776d8334 meta_monitor_manager_ensure_configured 
(libmutter-3.so.0)
#13 0x7f587831b00e g_cclosure_marshal_VOID__BOOLEANv 
(libgobject-2.0.so.0)
#14 0x7f58783190c6 _g_closure_invoke_va 
(libgobject-2.0.so.0)
#15 0x7f587833557d g_signal_emit_valist 
(libgobject-2.0.so.0)
#16 0x7f5878335b6f g_signal_emit (libgobject-2.0.so.0)
#17 0x7f58776c42fd upower_properties_changed 
(libmutter-3.so.0)
#18 0x7f587661e8ee ffi_call_unix64 (libffi.so.6)
#19 0x7f587661e2bf ffi_call (libffi.so.6)
#20 0x7f5878319682 g_cclosure_marshal_generic 
(libgobject-2.0.so.0)
#21 0x7f5878318e8d g_closure_invoke (libgobject-2.0.so.0)
#22 0x

Bug#932781: gnome-shell crashed on laptop lid close

[Vasudev Kamath]

Simon McVittie  writes:

> Control: tags -1 + moreinfo
>
> On Tue, 23 Jul 2019 at 10:36:59 +0530, Vasudev Kamath wrote:
>> Closing laptop lid normally puts laptop sleep and I get back my session on 
>> reopen. But after recent update
>> I see that I get logged out and closer inspection revealed that gnome-shell 
>> is crashing with following error
>> 
>> [  746.169795] gnome-shell[13847]: segfault at 2300022 ip 
>> 7f3718787e04 sp 7ffd56a0f0b0 error 4 in 
>> libwayland-server.so.0.1.0[7f3718787000+7000]
>
> This looks like the same thing as <https://bugs.debian.org/932428>.

Yes the behavior and even stack trace looked same.

>
>> I managed to get the coredump and backtrace of the same.
>
> To confirm, please could you install libwayland-server-0-dbgsym and
> libmutter-3-0-dbgsym and check this backtrace again?
>
>> #2  0x7f9198e77ede in send_xdg_output_events
>> (resource=0x7f9184fc4000, 
>> wayland_output=wayland_output@entry=0x55fa9018cd90, 
>> logical_monitor=logical_monitor@entry=0x55fa926ac9e0, 
>> need_all_events=need_all_events@entry=0, 
>> pending_done_event=pending_done_event@entry=0x7ffca0e09144) at 
>> wayland/meta-wayland-outputs.c:553
>
> If you can type
>
> p *resource
>
> at the gdb prompt, that would also be useful information.

Sadly I'm not having the old core! I don't know what happened though. I
tried to reproduce the issue but this time I have totally different
stack trace. I installed all dbgsym and captured the backtrace with this
mail. Let me know if you need any more information.

Cheers,

   PID: 26913 (gnome-shell)
   UID: 1000 (vasudeva.sk)
   GID: 1001 (vasudeva.sk)
Signal: 11 (SEGV)
 Timestamp: Tue 2019-07-23 18:24:04 IST (8min ago)
  Command Line: /usr/bin/gnome-shell
Executable: /usr/bin/gnome-shell
 Control Group: /user.slice/user-1000.slice/session-71.scope
  Unit: session-71.scope
 Slice: user-1000.slice
   Session: 71
 Owner UID: 1000 (vasudeva.sk)
   Boot ID: dd6e4472cdef44c284b155d24dafe3e6
Machine ID: feb451d304064b3f8706c8703a20adfd
  Hostname: bhrigu
   Storage: 
/var/lib/systemd/coredump/core.gnome-shell.1000.dd6e4472cdef44c284b155d24dafe3e6.26913.156388644400.lz4
   Message: Process 26913 (gnome-shell) of user 1000 dumped core.

Stack trace of thread 26913:
#0  0x7fbc8cc55dc3 n/a (libgbm.so.1)
#1  0x7fbc8230e7d2 n/a (i965_dri.so)
#2  0x7fbc8230e83c n/a (i965_dri.so)
#3  0x7fbc8825257e n/a (libEGL_mesa.so.0)
#4  0x7fbc88241344 n/a (libEGL_mesa.so.0)
#5  0x7fbc8d5cdab0 n/a (libEGL.so.1)
#6  0x7fbc8fd55a31 _cogl_winsys_egl_make_current 
(libmutter-cogl-3.so)
#7  0x7fbc90333e68 meta_renderer_native_create_view 
(libmutter-3.so.0)
#8  0x7fbc90299380 meta_renderer_create_view 
(libmutter-3.so.0)
#9  0x7fbc90336ac9 meta_stage_native_rebuild_views 
(libmutter-3.so.0)
#10 0x7fbc90329595 meta_backend_native_update_screen_size 
(libmutter-3.so.0)
#11 0x7fbc9027f093 meta_backend_sync_screen_size 
(libmutter-3.so.0)
#12 0x7fbc9027ff29 meta_backend_monitors_changed 
(libmutter-3.so.0)
#13 0x7fbc9029230d 
meta_monitor_manager_notify_monitors_changed (libmutter-3.so.0)
#14 0x7fbc90294557 meta_monitor_manager_rebuild 
(libmutter-3.so.0)
#15 0x7fbc9032fac6 
meta_monitor_manager_kms_apply_monitors_config (libmutter-3.so.0)
#16 0x7fbc9029236c 
meta_monitor_manager_apply_monitors_config (libmutter-3.so.0)
#17 0x7fbc90293334 meta_monitor_manager_ensure_configured 
(libmutter-3.so.0)
#18 0x7fbc90ed600e g_cclosure_marshal_VOID__BOOLEANv 
(libgobject-2.0.so.0)
#19 0x7fbc90ed40c6 n/a (libgobject-2.0.so.0)
#20 0x7fbc90ef057d g_signal_emit_valist 
(libgobject-2.0.so.0)
#21 0x7fbc90ef0b6f g_signal_emit (libgobject-2.0.so.0)
#22 0x7fbc9027f2fd upower_properties_changed 
(libmutter-3.so.0)
#23 0x7fbc8f1d98ee ffi_call_unix64 (libffi.so.6)
#24 0x7fbc8f1d92bf ffi_call (libffi.so.6)
#25 0x7fbc90ed4682 g_cclosure_marshal_generic 
(libgobject-2.0.so.0)
#26 0x7fbc90ed3e8d g_closure_invoke (libgobject-2.0.so.0)
#27 0x7fbc90ee7555 n/a (libgobject-2.0.so.0)
#28 0x7fbc90ef04ae g_signal_emit_valist 
(libgobject-2.0.so.0)
#29 0x7fbc90ef0b6f g_signal_emit (libgobject-2.0.so.0)
#30 0x7fbc91026399 n/a (libgio-2.

Bug#932781: gnome-shell crashed on laptop lid close

[Vasudev Kamath]

Package: gnome-shell
Version: 3.30.2-9
Severity: important

Dear Maintainer,

Closing laptop lid normally puts laptop sleep and I get back my session on 
reopen. But after recent update
I see that I get logged out and closer inspection revealed that gnome-shell is 
crashing with following error

[  746.169795] gnome-shell[13847]: segfault at 2300022 ip 7f3718787e04 
sp 7ffd56a0f0b0 error 4 in libwayland-server.so.0.1.0[7f3718787000+7000]

I managed to get the coredump and backtrace of the same. I'm attaching it with 
this bug report.

Cheers,
Vasudev


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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  evolution-data-server3.30.5-1.1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.30.0-7
ii  gir1.2-freedesktop   1.58.3-2
ii  gir1.2-gcr-3 3.28.1-1
ii  gir1.2-gdesktopenums-3.0 3.33.1-1
ii  gir1.2-gdm-1.0   3.30.2-3
ii  gir1.2-geoclue-2.0   2.5.3-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  gir1.2-gnomebluetooth-1.03.28.2-3
ii  gir1.2-gnomedesktop-3.0  3.30.2.1-2
ii  gir1.2-gtk-3.0   3.24.10-1
ii  gir1.2-gweather-3.0  3.28.3-1
ii  gir1.2-ibus-1.0  1.5.19-4+b1
ii  gir1.2-mutter-3  3.30.2-7
ii  gir1.2-nm-1.01.18.0-3
ii  gir1.2-nma-1.0   1.8.22-2
ii  gir1.2-pango-1.0 1.42.4-6
ii  gir1.2-polkit-1.00.105-25
ii  gir1.2-rsvg-2.0  2.44.10-2.1
ii  gir1.2-soup-2.4  2.64.2-2
ii  gir1.2-upowerglib-1.00.99.10-1
ii  gjs  1.54.3-1+b1
ii  gnome-backgrounds3.30.0-1
ii  gnome-settings-daemon3.30.2-3
ii  gnome-shell-common   3.30.2-9
ii  gsettings-desktop-schemas3.28.1-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libcroco30.6.12-3
ii  libecal-1.2-19   3.30.5-1.1
ii  libedataserver-1.2-233.30.5-1.1
ii  libgcr-base-3-1  3.28.1-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgirepository-1.0-11.58.3-2
ii  libgjs0g 1.54.3-1+b1
ii  libglib2.0-0 2.60.5-1
ii  libglib2.0-bin   2.60.5-1
ii  libgstreamer1.0-01.16.0-2
ii  libgtk-3-0   3.24.10-1
ii  libical3 3.0.5-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-3-03.30.2-7
ii  libnm0   1.18.0-3
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpolkit-agent-1-0  0.105-25
ii  libpolkit-gobject-1-00.105-25
ii  libpulse-mainloop-glib0  12.2-4
ii  libpulse012.2-4
ii  libsecret-1-00.18.7-1
ii  libstartup-notification0 0.12-6
ii  libsystemd0  241-7
ii  libx11-6 2:1.6.7-1
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.30.2-7
ii  python3  3.7.3-1

Versions of packages gnome-shell recommends:
ii  bolt  0.7-2
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.30.2-3
ii  gkbd-capplet  3.26.1-1
ii  gnome-control-center  1:3.30.3-1
ii  gnome-user-docs   3.30.2-1
ii  iio-sensor-proxy  2.4-2

Bug#921094: [Pkg-fonts-devel] Bug#921094: fonts-fantasque-sans: Single quote/apostrophe is not clearly readable

[Vasudev Kamath]

Cyril Augier  writes:

> Package: fonts-fantasque-sans
> Version: 1.7.1~dfsg-1
> Severity: important
>
> Hi !
>
> According to the issues on Github, the problem is solved in the higher
> versions.
>
> I installed the latest version from GitHub and it works perfectly.

Which version did you check with?. I'm doubtful to make it to buster but
definitely can be fixed for buster+1.

Cheers,

Bug#774274: fontforge: please use SOURCE_DATE_EPOCH for reproducible font modification time

[Vasudev Kamath]

Theppitak Karoonboonyanan  writes:

> Package: fontforge
> Version: 1:20170731~dfsg-1
> Followup-For: Bug #774274
>
> Dear Maintainer,
>
> This bug still exists for Type 1 font generation, which causes my package
> fonts-sipa-arundina to be unreproducible.
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/fonts-sipa-arundina.html
>
> Creation date timestamps are still taken from build time without obeying
> SOURCE_DATE_EPOCH.
>
> There have been some upstream changes in Fontforge after the version in Sid,
> beginning at this one:
>
> https://github.com/fontforge/fontforge/commit/4e850c134200d5a62bdecdd68a4ee31ef7688360
>
> And the relevant calls to the new GetTime() function have been added here:
>
> https://github.com/fontforge/fontforge/commit/078a1738a86717b46e02276bd85bb76893688eea
>
> So, please update Fontforge in Debian to solve more build reproducibility
> problems.

I currently do not have enough time to figure out patches needed as
there is no official release by upstream. But any help is welcome. If
you know set of patches which is going to fix this issue feel free to
record the commit hashes and I will try to get those applied.

Cheers,

Bug#920708: fonts-b612 segfault and other problems with ufo2otf

[Vasudev Kamath]

Control: tag -1 +moreinfo

Gürkan Myczko  writes:

> Package: python-fontforge
> Version: 1:20170731~dfsg-1
> Severity: normal
>
> Forwarding this to fontforge/python-fontforge:
>
> Hello,
>
> I can indeed reproduce the crash.
> It looks a bug in libfontforge2. (ufo2otf simply calls python-fontforge 
> which in turn uses libfontforge2.)
>
> I think you should report it to the fontforge package maintainers.

Can you please provide more information like a build log showing the
crash?. It will be helpful then for upstream to debug the issue easily.

Cheers,


signature.asc
Description: PGP signature

Bug#917048: cargo: Please drop patch to disable incremental builds on sparc64

[Vasudev Kamath]

John Paul Adrian Glaubitz  writes:

> Hi!
>
> On 12/22/18 12:15 AM, John Paul Adrian Glaubitz wrote:
>> While upstream hasn't fixed the bug yet, I have provided a temporary
>> fix for the bug in #917000 [2]. Once this bug has been fixed, incremental
>> builds work fine on sparc64 and the patch to disable incremental builds
>> in cargo, 2007_sparc64_disable_incremental_build.patch, is no longer
>> needed.
>> 
>> I am therefore setting this bug as blocked by #917000.
> Blocker bug in rustc has been fixed now. Could you remove the sparc64 patch
> to disable incremental builds in the next upload to close this bug?
>
> Then incremental builds will just work on sparc64!

I hope this is not important for buster?. I did not get time to attend
to this till now. But I will fix this and upload to experimental.

Cheers,

Bug#920414: tahoe-lafs: Please package new upstream version 1.13.0

[Vasudev Kamath]

Hi, 
New version needs magic-wormhole lib in py2 but currently it's py3 package. I 
filed a bug but maintainer said he won't be able to do it. If some one can 
package python-magic-wormhole then I can package new version.

Thanks and Regards

On 25 January 2019 2:51:30 PM IST, Elena ``of Valhalla''  
wrote:
>Source: tahoe-lafs
>Version: 1.12.1-5
>Severity: wishlist
>
>Dear Maintainer,
>
>I've noticed that a few months ago upstream released a new version of
>the package:
>
>https://tahoe-lafs.org/pipermail/tahoe-dev/2018-August/009923.html
>
>I realize that there would be very little time, but do you think it
>would be possible to have it in debian buster before the freeze?
>
>-- System Information:
>Debian Release: buster/sid
>  APT prefers testing
>  APT policy: (500, 'testing')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores)
>Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
>LANGUAGE=en_IE:en (charmap=UTF-8)
>Shell: /bin/sh linked to /bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#912062: [Pkg-fonts-devel] Bug#912062: fontforge: segfaults when opening some UFO fonts

[Vasudev Kamath]

Control: forwarded -1 https://github.com/fontforge/fontforge/pull/3358
Control: tag -1 +upstream


Hi Thibaut,

I've forwarded the patch to upstream. If they say it looks good I will
merge the same and release in next update.

Thanks for the patch.

Cheers,
Vasudev

Bug#908961: cargo: debian/rules overrides DEB_BUILD_PROFILES

[Vasudev Kamath]

Hi Helmut,

Helmut Grohne  writes:

> Source: cargo
> Version: 0.29.0-1
>
> debian/rules sets DEB_BUILD_PROFILES. The variable is not meant to be
> changed during build. Changing it can lead to inconsistency between
> tools run by debian/rules and tools run outside debian/rules, but it
> also overrides a user configuration. Please use a different variable for
> skipping tests for certain architectures.
>
> Note that you don't have to check for the nocheck profile. Checking the
> nocheck option is sufficient, because the spec requires that nocheck is
> added to DEB_BUILD_OPTIONS whenever it is present in DEB_BUILD_PROFILES.
> Simply setting DEB_BUILD_PROFILES=nocheck without setting
> DEB_BUILD_OPTIONS is a build profile specification violation.

So setting nocheck to DEB_BUILD_OPTIONS  should be the right approach
right?.

Cheers,

Bug#906539: magic-wormhole: Please provide python-magic-wormhole library its needed by new version of tahoe-lafs

[Vasudev Kamath]

Antoine Beaupré  writes:

> I'm happy to accept patches to ship a Python2 debian package of the
> wormhole library, but I do not have time to make the change myself. NMU,
> patches welcome.

I will see what I can do.
>
> I would also strongly recommend pushing tahoe-lafs to port to Py3
> already. Python 2 will be unsupported by the time our next Debian
> release is published and its future is uncertain, at best.
>

Well I agree but it seems like some dependencies are delaying porting to
python3 hence for the time being it will be good to provide python2 lib
so we can ship newer versions of tahoe-lafs.

Cheers,

Bug#906539: magic-wormhole: Please provide python-magic-wormhole library its needed by new version of tahoe-lafs

[Vasudev Kamath]

Source: magic-wormhole
Severity: important

Dear Maintainer,

I was packaging new version of tahoe-lafs and noticed it won't launch even after
adding magic-wormhole to dependency. Then I noticed magic-wormhole is using 
python3 
and tahoe-lafs still does not support python3.

I propose to provide library of magic-wormhole as separate package like 
python-magic-wormhole
and python3-magic-wormhole and make magic-wormhole binary depend on python3. 
This way tools
need python2 version can still use it.

I'm marking the report as important as this is currently blocking packaging new 
version of
tahoe-lafs.

Cheers,
Vasudev

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

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

-- no debconf information

Bug#897732: patches

[Vasudev Kamath]

Vasudev Kamath  writes:

> Hi Adrian,
>
> Adrian Bunk  writes:
>>
>> Hi Vasudev,
>>
>> are there any remaining problems with
>>   https://salsa.debian.org/debian/ctpp2/merge_requests/1
>> ?
>
> I've merged the changes. I had requested changes from Kunal but I did
> not get notification or got and it got filtered hence failed to notice.
>
>>
>> If there are any issues left that cannot be resolved quickly,
>> for a temporary fix I could do an NMU.
>
> No need for NMU but can you or Jonas upload package?. I use dgit
> push-source --gbp but getting some error on my side. Which I'm not sure
> if its only my case or every one else gets it. 

Uploaded manually and sorry last time missed to Cc the bug.

Cheers,
Vasudev

Bug#904803: pugixml: please update to new version 1.9

[Vasudev Kamath]

Gianfranco Costamagna  writes:

>
> * Non-maintainer upload (Closes: #-1)
>
> * Move vcs to salsa.d.o
>
> * Drop duplicated "section" libs
>
> * Bump std-version to 4.1.5, no changes required
>
> * New upstream release
>
> * Patch refresh
>
> * Update copyright file
>
>
> let me know if I can push the package!

Please feel free to!. And thanks for taking care of the update. I know
I'm bit late in replying but I'm mostly occupied on week days.

Thanks for the upload.

Cheers,
Vasudev

Bug#899124: fa-solid-900.ttf symlinked as fontawesome-webfont.ttf

[Vasudev Kamath]

Alexis Murzeau  writes:

> Hi,
>
> Le 27/06/2018 à 00:21, Alexis Murzeau a écrit :
>> Le 26/06/2018 à 04:13, vasudev-debian a écrit :
>>> I'll have a look. if possible clone from team repo and raise a pr on it.
>>>
>> 
>> I've created 3 PR at [0], one for each branch (in this order: upstream,
>> pristine-tar and master).
>> The 5.0.10+really4.7.0~dfsg orig tar I imported is the same as the one
>> used for 4.7.0~dfsg.
>> Debian/watch file tracks the v4 branch (ignoring v5.*)
>> I've also added a autopkgtest test to ensure symlinks are not broken.
>> 
>> [0] https://salsa.debian.org/fonts-team/fonts-font-awesome/merge_requests
>> 
>> Le 26/06/2018 à 09:26, Sean Whitton a écrit :
>>>
>>> The git history is up to you but resetting the changelog seems like a
>>> really bad idea -- it is confusing to see that there are uploads to the
>>> archive that are not present in the changelog.
>>>
>>> I think you should at least retain d/changelog, even if you reset
>>> everything else (personally, I would keep all the git history).
>>>
>> 
>> I finally kept the full changelog and git history, to not lie the past
>> :) if someone wonders what happened.
>> Thanks for your advices.
>> 
>
> Vasudev, did you get a chance to take a look to the merge requests [0] ?
>
> [0] https://salsa.debian.org/fonts-team/fonts-font-awesome/merge_requests
I've merged and I think Praveen uploaded new version to archive. Hope
this resolves everything.

Alexis thanks a lot for this update

Cheers,
Vasudev

Bug#899124: fa-solid-900.ttf symlinked as fontawesome-webfont.ttf

[Vasudev Kamath]

Hi Alexis, Thomas,

First of all I apologise for not replying in time. I'm bit occupied by
family work so not getting enough time to deal with package.

Alexis Murzeau  writes:

>> 
>> I also would like to highlight that what you're describing here is the
>> workflow of a transition, which is what Debian has been doing for
>> *years*. Not only this is natural in Debian, but it is also very much
>> recommended when breakage occurs.
>> 
>> I'm by the way a bit frustrated that this process is taking so long.
>> This has a huge impact in the maintenance of a big dozen of my packages,
>> since Horizon can't be installed. Reverting is really not a lot of work.
>> Can we get this done soon, as it seems to be the consensus? If the
>> current font-awesome maintainer is busy, maybe someone else (me?) can do
>> the work?

Yes I agree that I should have followed usual transition process but I
did not imagine a font package breaking things in this manner. Of course
its not an excuse but I should have been careful, but what is done is
done now.

>
> @Vasudev, what do you think about this ?
>
> (As far as I'm concerned, I'm ok with this and Thomas said it shouldn't
> be a lot of work to do.)

I've created basic package at ¹. If you or Thomas can adjust the package
as needed and upload it to archive it would be great. Also please
consider adding yourself as uploader as I might not have energy to
maintain additional package.

¹ https://salsa.debian.org/fonts-team/fonts-font-awesomev4

Thanks and Regards,
Vasudev.

--

Bug#884440: zimlib: Please package new 3.1.0 upstream version

[Vasudev Kamath]

On Mon, 11 Jun 2018 at 05:24, Kunal Mehta  wrote:
>
> retitle 884440 Please package new 3.3.0 upstream version
> thanks
>
> upstream is now at 3.3.0. I went ahead and prepared most of the
> packaging for this at
> <https://salsa.debian.org/legoktm-guest/zimlib/commits/master>. Would it
> help if I created a merge request on salsa?

Yes Please and add yourself to uploaders list. I can give out active
maintenance to you as I don't have
time to spend on the package and I don't really use kiwix.

> The remaining tasks should
> be to generate the rest of the symbols files (I'm not sure how to do
> that), and update the changelog.

Please update the symbols file first for your architecture and then
please upload to experimental, once its built on all architectures
please download logs and update symbols for remaining architecture.
[1] should give some idea.

[1]  https://www.eyrie.org/~eagle/journal/2012-01/008.html

>
> This is needed so I can upgrade libkiwix and start packaging the rest of
> the kiwix suite.

Understand.. That's why I'm asking take over the maintenance


-- 

Vasudev Kamath
http://copyninja.info

Bug#899124: fa-solid-900.ttf symlinked as fontawesome-webfont.ttf

[Vasudev Kamath]

Hi Thomas,

I read through and prepared a version to experimental which symlinks
fa-solid-900.ttf as fontawesome-webfont.ttf. I've uploaded it to
experimental, can you please check if this helps?.

@Others Please let me know if this new version in experimental with
suggestion from Thomas improves situation in your cases.

If it improves then I will move this change to unstable.

Cheers,

Vasudev

--

Bug#899124: fonts-font-awesome: completely breaks web applications, with no notice

[Vasudev Kamath]

Pierre-Elliott Bécue  writes:

>
> Hi,
>
> I'm maintaining HyperKitty, and it relies on fontawesome-webfont.ttf and
> FontAwesome.otf from the v4 version. To avoid shipping the files with the
> package, I linked them from the debian's one in d/rules. (see [1])
>
> Do we agree that there is no backward compability for such a case?

Upstream completely dropped ttf files. Now there are 3 variants of
opentype fonts, to provide backward compatibility some one should point
out which version suits best and we can create compatibility link. So as
to not break the package for now. But at some point of time reverse
dependencies need to adjust to new version of font.

Cheers,

Bug#899124: fonts-font-awesome: completely breaks web applications, with no notice

[Vasudev Kamath]

Hi Antonio,

Antonio Terceiro <terce...@debian.org> writes:

> Control: forwarded -1 
> https://salsa.debian.org/fonts-team/fonts-font-awesome/merge_requests/1
>
> On Sun, May 20, 2018 at 06:15:08PM -0300, Antonio Terceiro wrote:
>> Control: reopen -1
>> 
>> On Sun, May 20, 2018 at 10:32:38PM +0530, Vasudev Kamath wrote:
>> > Antonio Terceiro <terce...@debian.org> writes:
>> > > 2) revert the changes in fonts-font-awesome in unstable, upload the
>> > > new release to experimental, and give people a few months to adapt.
>> > 
>> > I'm okay with this solution. I've currently fixed the broken links and
>> > uploaded the fixes. If you would like more time to adapt to the version
>> > 5 of font, I can request its removal from unstable and re-upload old
>> > version to unstable and then upload this new version to experimental.
>> 
>> There is no such thing as requesting removal. you need to upload it with
>> a higher version number, but with the old contents. Something like
>> 5.0.10+really4.7.0-1.
>> 
>> Or maybe not. I will try if I can work things out with the new version,
>> so expect a few patches.
>> 
>> For now I'm reopening this bug (which was not really fixed by your -3
>> upload), and let's see what I can get.
>
> So here it is:
> https://salsa.debian.org/fonts-team/fonts-font-awesome/merge_requests/1
>
> This merge request fixes usage of v5, and add a backwards compatibility
> layer for the v4 when used with CSS (which was the only option in v4
> AFAICT). It also adds autopkgtest to automatically test that the needed
> files are in the right places both for v5 and for v4.

Thanks for this!. I've merged this and pushed new version to unstable.

>
> LESS and SCSS are not handled.

Let's see if any one is really using them, if so we will get bug report.

Thanks and Warm Regards,

Vasudev

--

Bug#899124: fonts-font-awesome: completely breaks web applications, with no notice

[Vasudev Kamath]

Hi Antonio,

Antonio Terceiro  writes:

> Package: fonts-font-awesome
> Version: 5.0.10-1
> Severity: grave
>
> Font-Awesome version completely changed everything, and any web
> applications that use it are now broken unless they go through some
> manual intervention.
>
> https://fontawesome.com/how-to-use/upgrading-from-4
>
> As a maintainer of multiple packages that use Font-Awesome, it would
> have been nice to receive a heads up and be given some time to adapt.
> But instead, now everything is broken and every single web appliction
> package that uses Font-Awesome needs to be changed to cope with the
> changes.

Apologies for the problems created by this upload. I was not aware of
technical efforts involved due to this upgrade as I myself do not use
this font and maintainer only because of some historical reasons.

>
> I'm not sure how to move forward now. IMO either
>
> 1) revert the changes in fonts-font-awesome, and package the new release
> under a new name (e.g.  fonts-font-awesome-5)

Though it might temporarily be a solution I think in long run it will be
burden as font-awesome till 4 will be not maintained.

>
> or
>
> 2) revert the changes in fonts-font-awesome in unstable, upload the
> new release to experimental, and give people a few months to adapt.

I'm okay with this solution. I've currently fixed the broken links and
uploaded the fixes. If you would like more time to adapt to the version
5 of font, I can request its removal from unstable and re-upload old
version to unstable and then upload this new version to experimental.

Let me know if this works for you.

Cheers,
Vasudev

--

Bug#898501: Broken symlinks

[Vasudev Kamath]

Hi all,

First of all sorry for mess I created. I made a silly mistake of not
updating the links file properly before upload. I'm rectifying it now
and will upload the fixed version ASAP.

Second I noted that from the bug report by Antonio that the usage
patterns have changed a lot between 4 and 5. Since I myself do not use
the font and maintain it only because of some historic reason I was not
aware of this. If you think I need to give people some time to adapt
then I can request for removal of current version from unstable and
upload old working version to unstable, and upload this new version to
experimental.

Please let me know what suits better for you. Once again apologies for
the problem created.

PS: If any one is interested in taking care of the font I'm more than
happy to hand over the mantle of maintainer, as I myself don't use this
font I might not be able to make justice for it.

Cheers,

Vasudev

--

Bug#895300: cargo: Please disable incremental-by-default on sparc64

[Vasudev Kamath]

John Paul Adrian Glaubitz  writes:

> Hi!
>
> The attached patch disables incremental builds on sparc64 and resolves
> the issue for me. It would be good if the patch could be applied for
> the time being until we have investigated what causes the issues with
> incremental builds on sparc64.
>
> I will definitely test newer upstream versions of Rust which have received
> some improvements for incremental builds and as well as report a bug
> report upstream if the issue persists.

Thank you for the patch, and sorry for delay in merging it. I'll build
and upload a new version to archive soon.

Cheers,

Bug#888811: dnscrypt-proxy: Please package newer upstream release

[Vasudev Kamath]

Package: dnscrypt-proxy
Version: 1.9.5-1+b1
Followup-For: Bug #11

Dear Maintainer,

There are lot of new release of the package and we are still in old version.
Can you please consider updating the package?.

If you are busy can you make the package team maintained so interested party
can help in keeping package uptodate.

Cheers,

--
Vasudev



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

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

Versions of packages dnscrypt-proxy depends on:
ii  adduser  3.117
ii  libc62.27-2
ii  libltdl7 2.4.6-2
ii  libsodium23  1.0.16-2
ii  libsystemd0  236-3+b1
ii  lsb-base 9.20170808

dnscrypt-proxy recommends no packages.

Versions of packages dnscrypt-proxy suggests:
pn  resolvconf  

-- Configuration Files:
/etc/dnscrypt-proxy/dnscrypt-proxy.conf changed:
ResolverName random
Daemonize no
LocalAddress 127.0.2.1:53


-- no debconf information

Bug#892370: Aerial Bold chosen when it should not be

[Vasudev Kamath]

Hi Wouter,

Wouter Verhelst  writes:

> Package: fonts-arkpandora
> Version: 2.04-1
> Severity: normal
>
> Hi,
>
> fonts-arkpandora contains a number of fonts, amongst which Aerial and
> Aerial Bold.
>
> For some reason, on my system firefox chooses Aerial Bold when it should
> instead choose the regular Aerial font. As a result, almost all websites
> that I visit are displayed in bold. This is rather annoying.

I see, I do not see any specific configuration for this in the
fontconfig file shipped by the fonts-arkpandora package. Do you have any
specific web pages which you found this problem?.

Mean while any one else from fonts team have any idea on this issue?. Is
it related to fontconfig configurations?

Cheers,

--
Vasudev

Bug#891855: fonts-monoid: installs no less than 4000 font files!

[Vasudev Kamath]

Fabian Greffrath <fab...@debian.org> writes:

> Hi Vasudev,
>
> Am Sonntag, den 04.03.2018, 14:59 +0530 schrieb Vasudev Kamath:
>> Feel free to suggest and join in the maintenance work :-). It was long
>> pending and recently I noticed that it could be already built since I've
>> uploaded latest fontforge to our archive. I actually didn't notice the
>> size of deb file until Adam mentioned about it in IRC.
>
> I am already done with implementing my suggested changes. 
Great!.

> While at it, does it make any sense at all to include the variants
> which differ only in line hight? I mean, line hight is usually defined
> by the application rendering the font and it is not that we have any
> means to influence that by explicitely selecting a different font
> style, anyway?

Even I've no idea, I think best to is ship only important one's leaving
out others. If user specifically needs them they can request it via a
bug report.

I actually follow this because some times some variants may not make
sense to end user at all.

--
Vasudev

Bug#891855: fonts-monoid: installs no less than 4000 font files!

[Vasudev Kamath]

Hi Fabian,

Fabian Greffrath  writes:

> Am Donnerstag, den 01.03.2018, 17:36 +0100 schrieb Fabian Greffrath:
>> etc. Another alternative would be to split the packages up by groups
>> of variants, or whatever.
>
> I think I have a better idea: In e.g. the Libreoffice font chooser the
> fonts represent themselves as
>  - Monoid
>  - Monoid HalfLoose
>  - Monoid HalfTight
>  - Monoid Loose
>  - Monoid Tight
>  - Monoisome
>  - Monoisome HalfLoose
>  - Monoisome HalfTight
>  - Monoisome Loose
>  - Monoisome Tight
> i.e. they are grouped by their tracking.
>
> It will probably make sense to split the package up in the same way, so
> we'd be down to "just a few hundred" font files per package.

This is a good idea. We can provide fonts with fonts-monoid-[variant]
and fonts-monoisome-[variant]

>
> Needless to say, probably, but I am a DD and also part of the Debian
> fonts team and I'd love to help discuss and implement a proper solution
> for the package split-up!

Feel free to suggest and join in the maintenance work :-). It was long
pending and recently I noticed that it could be already built since I've
uploaded latest fontforge to our archive. I actually didn't notice the
size of deb file until Adam mentioned about it in IRC.

Cheers,

--
Vasudev

Bug#890211: [Pkg-fonts-devel] Bug#890211: Bug#890211: fonts-noto-hinted: Certain font characters crash Emacs 25

[Vasudev Kamath]

Jonas Smedegaard  writes:

> Hi Chiraag,
>
> Quoting Chiraag Nataraj (2018-02-12 02:00:06)
>> I went to open mpc in Emacs, and my artists (and song titles) are in 
>> multiple languages, including Kannada (the font for which I found this 
>> problem). A very specific character (ಕು) caused Emacs to crash. This 
>> was reproducible multiple times using both the GTK+ and Lucid builds 
>> of Emacs 25.
>> 
>> I uninstalled the package, which prevented the crash (that is, other 
>> fonts - e.g. the ones provided by fonts-knda - do not have this 
>> problem and do not cause Emacs to crash).
>> 
>> I can provide more information if needed.
>
> Interesting!  I will make sure to pass this upstream to the developers 
> of Noto.
>
> Please also file a separate bugreport against emacs, as I am sure they 
> would love to know about the crashing bug on their side (and I don't use 
> emacs myself so cannot sensibly report that on my own).

This is not related to fonts I assume. I had long ago filed bug report
with emacs24 for this ¹. But sadly it got closed as emacs24 went out of
archive (And I did not notice that).

Jonas I think we can safely re-assign this bug to emacs25. In my case
crash was mostly Unicode character (Kannada) specific.


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

Bug#888413: lintian: Don't consider README file under debian/patches as patch file

[Vasudev Kamath]

Chris Lamb  writes:

> tags 888413 + pending
> thanks
>
> Hi Vasudev,
>
>> Please do not consider README file under debian/patches folder as
>> a patch file. 
>
> Thanks for the report! This was already fixed a few days ago in Git
> here:
>
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=4533a5092fe7b9b7e3f8bda2829995a6111906b9
>
> :)

Ah great :-).

Cheers,

--
Vasudev

Bug#888413: lintian: Don't consider README file under debian/patches as patch file

[Vasudev Kamath]

Package: lintian
Version: 2.5.71
Severity: normal

Dear Maintainer,

Please do not consider README file under debian/patches folder as a patch file. 

Several of my packages have a README file in the debian/patches folder which
describes naming convention to be followed while creating new patches. [1]. I 
noticed
that newer lintian emits patch-file-present-but-not-mentioned-in-series for 
README file
which I feel is not correct. Can you please exclude README file from above tag?

Cheers,

--
Vasudev

[1] https://anonscm.debian.org/git/pkg-rust/cargo.git/tree/debian/patches/README

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

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

Versions of packages lintian depends on:
ii  binutils  2.29.90.20180122-1
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.5
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-4
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.73-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.7.6.1-4
ii  patchutils0.3.4-2
ii  perl  5.26.1-4
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information