date:20231223

Bug#1059385: r-cran-ggally: autopkgtest regression

2023-12-23 Thread Graham Inggs

Source: r-cran-ggally
Version: 2.2.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Since the upload of 2.2.0-1, r-cran-ggally fails its own autopkgtests
[1].  I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-ggally/testing/amd64/


118s == Failed tests

118s -- Error ('test-ggnet.R:231:5'): examples
--
118s Error in `asIgraph(n)`: could not find function "asIgraph"
118s Backtrace:
118s x
118s 1. \-GGally::ggnet(asIgraph(n)) at test-ggnet.R:231:5
118s -- Error ('test-ggnet2.R:265:5'): examples
-
118s Error in `asIgraph(n)`: could not find function "asIgraph"
118s Backtrace:
118s x
118s 1. \-GGally::ggnet2(asIgraph(n), color = "group") at test-ggnet2.R:265:5
118s
118s [ FAIL 2 | WARN 0 | SKIP 27 | PASS 415 ]
118s Error: Test failures
118s Execution halted
119s autopkgtest [06:14:59]: test run-unit-test: ---]

Bug#1059382: kitty: Text rendering change

2023-12-23 Thread Nilesh Patra




Hi Weasley,

On 24 December 2023 8:58:14 am IST, Wesley Schwengle  
wrote:
>Package: kitty
>Version: 0.31.0-3
>Severity: normal
>X-Debbugs-Cc: wes...@schwengle.net
>
>Dear Maintainer,
>
>On Debian stable version 0.26.5 of kitty is running, on testing/unstable this
>is 0.31.0. In 0.28.0 a change in text rendering is made by upstream, this is
>mentioned in the changelog.
>
>
>Text rendering change: Use sRGB correct linear gamma blending for nicer font
>rendering and better color accuracy with transparent windows. See the option
>text_composition_strategy for details. The obsolete macos_thicken_font will
>make the font too thick and needs to be removed manually if it is configured.
>(#5969)
>
>I didn't spot it and went in full bisect mode to figure out which commit caused
>it. I found it and could relate it to the Changelog entry.

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

>The issue is that on a dark background with light text everything is made bold,
>whereas previously this was not bold. I think it is wise to inform users that
>`text_composition_strategy legacy` restores the old defaults (similar to the
>version in stable) and/or refer to the manual page:
>
>https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.text_composition_strategy
>
>If kitty can read a system-wide config it might be set there.

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

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

Thanks,
Nilesh

Bug#634127: still has CPU use problems and no way to manage it

2023-12-23 Thread Russell Coker

https://longnow.org/ideas/controlling-nature-might-be-in-our-nature/

This is an example of a web page that uses a lot of CPU time, on a laptop with 
a i5-6300U running KDE with Wayland it takes 50% of a CPU core for the total 
of the WebKitWebProces and epiphany processes and it makes kwin_wayland take 
over 10% when the above web page is visible.  To reproduce this the web page 
in question has to be in a foreground tab and the web browser window has to be 
visible.  Putting another tab in the foreground or putting another window in 
front of the browser reduces it to almost zero.

On a PinePhonePro this page takes almost 100% of a CPU core between the two 
processes for Epiphany and runs the battery out quickly.

Having the same page open in Google Chrome doesn't take any noticeable CPU 
time on my laptop.

Also epiphany doesn't seem to have an equivalent to the SHIFT-ESC in Chrome to 
bring up a browser task list.  It would be good to have something like that.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#1059352: src:apt: fails to migrate to testing for too long: autopkgtest regression on armhf

2023-12-23 Thread Paul Gevers


Hi Julian,

On 23-12-2023 20:40, Julian Andres Klode wrote:

I know this is automated but I feel lije it would be sensible to scan


It's *mostly* automated.


the logs for well known bugs so that you don't end up filing bugs
against every package broken by valgrind's missing support for the new
NOP sequences in binutils.


I do *some* minor triaging, but I didn't know this to be a common 
problem. Where do you think I should have picked this up?


Anyways, this bug is already closed (when I submitted) and because apt 
is a key package, it doesn't even do anything against apt, so the bug 
serves mostly for tracking purposes.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058522: (no subject)

2023-12-23 Thread Lev Lamberov

Hi Jeremy,

Чт 21 дек 2023 @ 15:06 Jeremy Sowden :

> On 2023-12-21, at 11:21:48 +, Jeremy Sowden wrote:
>> On 2023-12-21, at 11:10:28 +0500, Lev Lamberov wrote:
>> > Since I cannot reproduce the bug, I'm downgrading the severity of
>> > this bug report.
>> 
>> I cloned the git repo, ran `gbp buildpackage --git-pbuilder` and
>> reproduced it (log attached).  I'll see if I can work out what's going
>> on.

Thanks for your input. I double checked this bug report both under
git-pbuilder and sbuild. E. g., here is the sbuild environment:

$ sudo sbuild-shell unstable
I: /bin/sh
# bash
(unstable-amd64-sbuild)root@shakva:/# du --version
du (GNU coreutils) 9.4
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjörn Granlund, David MacKenzie, Paul Eggert,
and Jim Meyering.
(unstable-amd64-sbuild)root@shakva:/# exit

But I still cannot reproduce the bug. Don't know...

Best,
Lev

Bug#1059384: ipv6calc: IPv6 link-local multicast with transient flag not detected as ll

2023-12-23 Thread Linus Lüssing

Package: ipv6calc
Version: 4.1.0-0.1
Severity: normal
X-Debbugs-Cc: linus.luess...@c0d3.blue

Dear Maintainer,

With the following I'm getting the "Address type" as expected:

```
$ echo "ff02::123" | ipv6calc -i
Address type: multicast, link-local
Registry for address: reserved(RFC4291#2.7)
Interface identifier: :::0123
Interface identifier is probably manual set
```

However when setting the transient flag then ipv6calc is not able to
detect it as link-local anymore:

```
$ echo "ff12::123" | ipv6calc -i
Address type: multicast
Registry for address: reserved(RFC4291#2.7)
```

I would have expected an "Address type" with "link-local" in the second
example, similar to the output of the first command

Regards, Linus

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 ipv6calc depends on:
ii  libc6  2.37-12
ii  libmaxminddb0  1.8.0-1

ipv6calc recommends no packages.

Versions of packages ipv6calc suggests:
ii  bind9-host [host]  1:9.19.17-1

-- no debconf information

Bug#1059383: neomutt: conffiles not removed: /etc/neomuttrc.d/smime.rc /etc/neomuttrc.d/gpg.rc

2023-12-23 Thread Paul Wise

Package: neomutt
Version: 20231103+dfsg1-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ p=neomutt ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | grep obsolete
neomutt: obsolete-conffile /etc/neomuttrc.d/smime.rc
neomutt: obsolete-conffile /etc/neomuttrc.d/gpg.rc
 /etc/neomuttrc.d/smime.rc d25e75a8d59c32061f275fb823da07a1 obsolete
 /etc/neomuttrc.d/gpg.rc fa01d034c3ba43eb0899bcca8e8b4903 obsolete

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages neomutt depends on:
hi  libc6 2.37-12
ii  libgnutls30   3.8.2-1
ii  libgpgme11    1.18.0-4+b1
ii  libgsasl18    2.2.0-2
ii  libgssapi-krb5-2  1.20.1-5
ii  libidn2-0 2.3.4-1+b1
ii  liblmdb0  0.9.31-1
ii  liblua5.4-0   5.4.6-1
ii  liblz4-1  1.9.4-1
ii  libncursesw6  6.4+20231209-1
ii  libnotmuch5   0.38.2-1
ii  libpcre2-8-0  10.42-4
ii  libsqlite3-0  3.44.2-1
ii  libtinfo6 6.4+20231209-1
ii  libtokyocabinet9  1.4.48-15
ii  libzstd1  1.5.5+dfsg2-2
ii  sensible-utils    0.0.20
ii  zlib1g    1:1.3.dfsg-3

Versions of packages neomutt recommends:
ii  locales  2.37-12
ii  mailcap  3.70+nmu1

Versions of packages neomutt suggests:
ii  aspell 0.60.8-6
ii  ca-certificates    20230311
ii  exim4-daemon-light [mail-transport-agent]  4.97-2
ii  gnupg  2.2.40-1.1
ii  ispell 3.4.05-1
ii  openssl    3.1.4-2
pn  urlview    

Versions of packages neomutt is related to:
ii  neomutt  20231103+dfsg1-1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#1056764: grub-efi-amd64: can't boot with GRUB 2.12~rc1-12

2023-12-23 Thread Nicolas Haller


Hi Mate,

Sorry for the delay, I was abroad and wasn't able to work on your questions.

I tried to add the set debug=linux and the rmmod peimage by editing the 
command list Debian deploys and this is what I get:


---
   Booting a command line

error: no such module  <= I guess that's about the rmmod peimage
Loading Linux 6.5.0-4-and64 ...
loader/efi/linux.c:101:linux: UEFI stub kernel:
loader/efi/linux.c:102:linux: PE/COFF header @ 0082
loader/efi/linux.c:128:linux: LoadFile2 initrd loading enabled
loader/efi/linux.c:495:linux: kernel file size: 9120128
loader/efi/linux.c:497:linux: kernel numpages: 2227
loader/efi/linux.c:514:linux: kernel @ 0x72a51000
Loading initial ramdisk ...
loader/efi/linux.c:416:linux: Using LoadFile2 initrd loading protocol

Press any key to continue...
---

And that's it.
Let me know if you need me to do more tests.

Thanks

--
Nicolas

On 2023-11-26 04:01, Mate Kukri wrote:

Hi Nicolas,

The mechanism used to load the kernel has changed from GRUB 2.06 to
GRUB 2.12, it is possible that there are unfortunate bugs in either in
GRUB and/or your firmware that is stopping the new mechanism from
loading the kernel.

Would you be able to attempt these two things to gather some information?

- Run `set debug=linux`, then `linux
PATH_TO_KERNEL_THAT_FAILS_TO_BOOT`. The output of the Linux command
should contain extra information with the debug mode enabled.

- (Make sure to have Secure Boot disabled), then run `rmmod peimage`
at the GRUB console, and then try running your boot entry (or
alternatively edit the boot entry with E and add that command on top).

Mate Kukri

On Sat, Nov 25, 2023 at 10:45 PM Nicolas Haller  wrote:


Package: grub-efi-amd64
Version: 2.06-13
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

My old laptop (Lenovo 11e) runs Sid and all was right before I updated
it the other day (I don't do that very often). After that upgrade, GRUB
wasn't able to load any kernel with the pretty much generic error
"Error: can't load image". The version of GRUB was 2.12~rc1-12.
If I try to boot again, GRUB tells me that I need to load the image
first (I guess it somehow ignores the linux command and sends that when
trying to load the initrd).

I tried to reinstall grub, grub-install /dev/sda, update-grub, reinstall
the kernel, update-initramfs from the rescue mode but nothing worked.
The "file" command was able to read the vmlinuz file and none seemed
truncated. The system has one partition with both / and /boot and isn't
running out of space.
I did not see any error message during those operation besides GRUB
saying it wasn't able to update EFI parameters.

I don't know if there is a way to get more logs or error message during
the boot explaining why it wasn't able to load the image.

I tried to get the last version of GRUB from Bookworm, that is
2.06-13, and now I'm able to boot. The kernel version did not change,
   the only change I did is to downgrade GRUB (and dependencies apt was
   asking for).

I'm not sure which GRUB package I should use for reporting so I took the
one that seems the most specific to my system. Apologies if it is not
correct.

Let me know if you need more info.

Thanks,

--
Nicolas Haller

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

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

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


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda2 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

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

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

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

export menuentry_id_option

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

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

Bug#1059382: kitty: Text rendering change

2023-12-23 Thread Wesley Schwengle

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

Dear Maintainer,

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


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

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

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

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

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

Cheers,
Wesley


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

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

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

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

Versions of packages kitty suggests:
pn  imagemagick  

-- no debconf information

Bug#896016: strace: please make the build reproducible

2023-12-23 Thread James Addison

Source: strace
Followup-For: Bug #896016
X-Debbugs-Cc: la...@debian.org, reproducible-b...@lists.alioth.debian.org

Looking at the Reproducible Builds build history[1] for strace on Debian,
all _successful_ builds I see between Y2019 and today, across all four
architectures listed (amd64, arm64, armhf, i386) have produced reproducible
results.

As a result of that, I agree that the Apr 2018 fix[2] (released Jun 2018)
mentioned by Chris has provided reproducibility for strace.

Unfortunately there are plenty of FTBFS failures -- mostly test timeouts on
some architectures, alongside libfaketime errors that seem to affect i386 --
but those seem like separate problems.  Perhaps we could close this bug?

[1] - 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/strace.html

[2] - 
https://github.com/strace/strace/commit/fc8294cbc2ac907737d85abca55b854bd426ab50

Bug#1059278: systemd: CVE-2023-7008

2023-12-23 Thread Jan Erik Petersen

Hi,

I'm the reporter of the bug at
https://github.com/systemd/systemd/issues/25676. I'm sorry that I have
to add to the bug at this time.

The commit[0] that was determined to have introduced this vulnerability
is incorrect. Looking at the relevant diff[1] the commit merely
introduced the use of the `FLAGS_SET` macro, but did not change the flag
being read from the incorrect variable `t`. In the fix[2] this was
changed to `dt`.

Note that the vulnerability has been previously reported[3] in March
2020 on systemd v243+v244. Hence systemd v248 is definitely not the
first version introducing the vulnerable code.

In fact, I have reproduced the issue right now on both Debian buster
(10.13) with systemd 241-7~deb10u10 and Debian bullseye (11.8) with
systemd 247.3-7+deb11u4.

I assume the vulnerability was introduced with the initial version[4] of
the `dns_transaction_requires_rrsig` function, which already read the
flag from `t`. This would have been in systemd v229, but I did not test
any version older than v241.

I would add this information to the GitHub issue, but it has been
locked. Perhaps a systemd contributor could relay this update, so that
the misleading information does not spread.

Regards,
Jan Erik Petersen

[0]
https://github.com/systemd/systemd/commit/6f055e43b817b66e6d4f6e4022f0a115dc35651b
[1]
https://github.com/systemd/systemd/commit/6f055e43b817b66e6d4f6e4022f0a115dc35651b#diff-d63d6fd38d6a715e4ca052fc0fb65eda859f3822dbddffa4a87a3ee872e25eafL2621
[2]
https://github.com/systemd/systemd/commit/3b4cc1437b51fcc0b08da8cc3f5d1175eed25eb1

1 2 >

1 - 100 of 105 matches

Mail list logo