Bug#961834: New release

[john faulk]

Hello everyone,
its been a while since this was last discussed, and it seemed tagging
a new release was pre-requisite to being added back to debian. Thus, I
have forked the fork, and tagged a release, shown below:
https://github.com/MrReplikant/clearlooks-phenix/releases/tag/7.0.2

I am doing this as such to volunteer to be the guardian of this
release until someone more willing/capable/knowledgeable of theming is
able to take over from me. my hopes is that this will allow
clearlooks-phenix to be allowed back into the repo.

if there are any questions or concerns, please do not hesitate to contact me

-John

Bug#1064346: Source is missing errors on HTML source files

[Shriram Ravindranathan]

Thanks, Soren.

It looks like most of these files have just one or two lines that are 
extremely long.


These are mostly README files. Most of them seem to have this 
github-markdown.css 
 
minified and pasted in them. While others have the sources that were 
used to generate them listed in the same folder.


Should I copy these sources into the d/missing-sources directory?

On 21/02/24 2:28 am, Soren Stoutner wrote:

The question is if the long lines in these HTML files are actually indications
that the HTML files are not the original source.  This usually happens in one
of two cases.

1.  The files have been minified.
2.  The files were originally created in another format and converted to HTML.

Sometimes HTML files naturally have long lines.  If you look at the
descriptions of the lintian warnings, they acknowledge that this is an
imperfect check that will result in some false-positives.  If that is the
case, the HTML files are the original source, and they have not been minified,
then you can override these warnings with a description as to why.

On Tuesday, February 20, 2024 9:08:17 AM MST Shriram Ravindranathan wrote:

Hello mentors,

I am getting a few lintian "source-is-missing" errors for some HTML
files. These HTML files are infact present in the source code but they
have too many lines which triggers a
"very-long-line-length-in-source-file" lintian tag and that in turn
causes the "source-is-missing" error.

Most of the info I could find in the policy manual and in the forums
pertained to binary files that were included in the source, the strategy
these resources suggested were
1. Repack upstream tar with the source code of these files
2. Add the source code to the d/missing-sources directory

I don't think either of these are viable options in my case. I was
wondering whether it would be okay to suppress these errors. Is there
any other way to solve this?

--
Shriram Ravindranathan




--
Shriram Ravindranathan



OpenPGP_0xFC7E951A7BEF0836.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061437: firefox-esr: Fails to build with Python 3.12 as default

[Mike Hommey]

On Tue, Feb 20, 2024 at 11:59:11PM -0500, Jeremy Bícha wrote:
> Amin Bandali collected several other fixes that were necessary for
> mozjs115 to build with Python 3.12 beyond the one that I noticed was
> included in 115.8.
> 
> You can find them in the python3.12 patches in
> https://salsa.debian.org/gnome-team/mozjs/-/tree/debian/115/master/debian/patches
> 
> (Note that mozjs115 is partially stripped down so I can't guarantee
> that even those patches are complete for firefox-esr's needs.)
> 
> Therefore, I presume we will need to reopen this bug, but I have not
> tried building firefox-esr myself.

I've totally built Firefox 115esr with python 3.12 without those
patches. At quick glance, they touch code that is not involved during
the build.

Mike

Bug#1064382: ITP: coremltools -- tools for Core ML model conversion, editing, and validation

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: coremltools
  Version : 7.1
  Upstream Authors: Apple Inc. 
  URL : https://github.com/apple/coremltools
* License : BSD-3-Clause
  Description : supporting tools for Core ML model conversion, 
editing, and validation
 This is Core ML Tools (coremltools) to convert machine learning models 
from
 third-party libraries to the Core ML format. This Python package 
contains the

 supporting tools for converting models from training libraries.

Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed

[Alban Browaeys]

The 405 status was locally and manually fixed by applying the "webdav
migration" implemented upstream in merge request 146.

That is in ~/.config/goa-1.0/accounts.conf for my owncloud provider,
add "remote.php/webdav" to the "https://nextcloud.domain/; in the "Uri"
key.
I also create CalDavUri and CardDavUri from the "Uri" key but appending
"remote.php/dav" to them instead of "remote.php/webdav".
I got the clue from the issue "critical when testing new WebDav support
on existing nextcloud account: g_uri_peek_scheme: assertion 'uri !=
NULL' failed"
https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/276 ).


The fix: "goabackend: migrate existing WebDAV
accounts"https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/merge_requests/146
It is merged in 3.49.1 (while Debian is 3.49.0).

Note that 3.49.1 also includes a migration to GTK4 and API changes
which would breaks gnome-control-center 45 "Bump soname?"
https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/291
Though we have gnome-control-center 46~alpha-2 in trixie and 46~beta-1
in sid, I don't know which gnome-control-center 46 release was ported
to this API (as I have 1:46~alpha-2 currently I believe it is not
ported yet as it works with gnome-online-accounts 3.49.0).

Might be the best way for now is to port the merge request 146 to
3.49.0 in Debian trixie.

The API breakage in gnome-control-center was done in "goabackend: port
to GTK4"
https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/merge_requests/142
which is merged into 3.49.1.

Cheers,
Alban

On Sat, 27 Jan 2024 08:11:10 +0100 Alban Browaeys 
wrote:
> Package: gnome-online-accounts
> Version: 3.49.0-1
> Severity: important
> 
> 
> I upgrade gnome-online-accounts from 3.48.0-2 to 3.49.0-1, I still
had
> Nextcloud ok in gnome-control-center (Settings) 1:46~alpha-2.
> Then on one box I rebooted, then I got "Credential have expired" for
> Nextcloud in Settings. Trying to authenticate anew gave me "Error
> connecting to WebDAV server: Authentication failed".
> 
> I then tried on the other box, which still had nextcloud login ok,
where
> I also upgraded gnome-control-center but did not yet restart it, to
> kill goa-daemon and restart it. Then I ended up with the same error
as
> wiht the box I rebooted.
> 
> Settings output is:
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: GSocketClient: Starting new address enumeration
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: lookup_by_name_with_flags_async: starting new lookup for
cloud.prahal.homelinux.net with GTask 0x5581b3e13eb0, LookupData
0x5581b3ce9500
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: lookup_by_name_with_flags_async: starting new lookup for
cloud.prahal.homelinux.net with GTask 0x5581b3d76160, LookupData
0x5581b3d1c5b0
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: GSocketClient: Address enumeration succeeded
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: GSocketClient: Starting TCP connection attempt
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: GSocketClient: TCP connection successful
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: GSocketClient: Starting application layer connection
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]: GLib-
GIO: GSocketClient: Connection successful!
> janv. 27 07:59:10 hermes org.gnome.Settings.desktop[131923]:
GoaBackend: goa_dav_client_check(): response (0x5581b422b970, 405)
> 
> Note the 405 status.
> Could it be my old Nextcloud version does not support a method call
from
> goa 0.49.0?
> 

Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed

[Jeremy Bícha]

On Tue, Feb 20, 2024 at 8:18 PM Alban Browaeys  wrote:
> gnome-control-center 46~beta-1 is supposed to already be ported to the
> new gnome-online-accounts gtk4 API, from
> " online-accounts: port to new API"
> https://gitlab.gnome.org/GNOME/gnome-control-center/-/commit/80fcc8c2f26f7561538418fc5d72e18ecbbe512b
> so I believe that in sid gnome-control-center 46~beta-1, managing
> accounts from gnome-online-accounts should already broken.
> But installing this sid version, I can still show all accounts details
> with gnome-online-accounts 3.49.0. I can also remove and adda kerberos
> account.

The new gnome-online-accounts API was implemented in
gnome-control-center upstream version 46.beta.1. In Debian, we adjust
the first . to ~ to make 46~beta.1 (to ensure that 46~beta sorts lower
than 46.0). The downstream Debian version is the part of the version
number after the final - . So, 46~beta-1 is actually upstream's
46.beta instead of 46.beta.1. The final -1 just means this is the
"first" Debian revision for that upstream version. Sorry, that it is
so confusing here.

Yes, we intentionally did not package 46.beta.2 (or beta.1) yet
because of how disruptive the new gnome-online-accounts version will
be. It will take some time to think about how to handle it.

Thank you,
Jeremy Bícha

Bug#1064376: RM: ganglia -- ROM; Unmaintained upstream, better alternatives exist

[Marcos Fouces]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: mar...@debian.org
User: ftp.debian@packages.debian.org
Usertags: remove

Bug#1060829: Bug#1061384: acl2: add support for loongarch64

[Camm Maguire]

Greetings, and thanks for your reports!  GCL is the key to porting these
programs and more.  Is there any remote ssh access to a machine on which
I may implement this?

Take care,

zhangdandan  writes:

> Source: acl2
> Version: 8.5dfsg-5
> Severity: wishlist
> Tags: patch
> User: debian-loonga...@lists.debian.org
> Usertags: loong64
>
> Dear maintainers,
>
> Maybe we need to add LoongArch support in
> books/kestrel/x86/parsers/parse-pe-file.lisp.
> Refer to riscv64, please consider the patch I have attached.
> If you have better modification suggestions, please help us fix this patch.
>
> I would like to remind you that the compilation dependency of acl2 is
> not yet satisfied. Depends on the gcl ( >= 2.6.14-1) package when 
> compiling acl2.
> If you have any questions, you can contact me at any time.
>
> thanks,
> Dandan Zhang
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#1042955: zzzeeksphinx: please make the output reproducible

[James Addison]

Followup-For: Bug #1042955
Control: forwarded -1 https://github.com/sqlalchemyorg/zzzeeksphinx/issues/23

Bug#1064381: ITP: elfkickers -- collection of programs that access and manipulate ELF files

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: elfkickers
  Version : 0+git20240221+ds
  Upstream Authors: Brian Raiter 
  URL : https://github.com/BR903/ELFkickers
* License : GPL-2-or-later
  Description : collection of programs that access and manipulate 
ELF files

 This distribution is a collection of programs that are generally
 unrelated, except in that they all deal with the ELF file format.
 .
 The main purpose of these programs is to be illustrative and
 educational -- to help fellow programmers understand the ELF file
 format and something of how it works under the Linux platform. For the
 most part, these programs have limited real-world utility.
 .
 With the exception of shared use of the elfrw static library, each
 program is independent of the others. There is no other shared code
 between them, and they all take slightly different approaches to
 handling ELF files.

Bug#1064343: tput sgr0 adds uncalled-for codes

[Adam Borowski]

On Tue, Feb 20, 2024 at 07:41:42PM +0100, Sven Joachim wrote:
> > On Tue, Feb 20, 2024 at 04:15:30PM +0800, Paul Wise wrote:
> >>$ tput sgr0 | hd
> >>  1b 28 42 1b 5b 6d |.(B.[m|
> >
> > Here's the culprit.  The code you asked for is "\e[0m" -- shortenable to
> > non-canonical but valid "\e[m", which is the second half of tput's output.
> >
> > What you did not ask for, is "\e(B", which is not allowed in UTF-8 mode,
> > and in non-Unicode world would switch to an ancient "US" charset.
> 
> Maybe that is true for the Linux console, but we are talking about xterm
> here.

It's not a property of the terminal, but of ECMA-35.

And what "xterm" are you talking about?  tput has no way to know the
terminal on the other side, as the string TERM=xterm (and
TERM=xterm-256color) applies to over a hundred different terminals using
tens of different code bases.  And you can't even blame their authors, as:
 * most Unices stopped maintaining their terminfo databases (eg. Solaris
   still hasn't learned about TERM=linux.  Solaris is no longer relevant now
   but was relevant for most of that time frame.)
 * even if the databases were maintained, a new terminal would become useful
   only several years after it gets released (as the terminfo entry would
   need to be deployed on every box you might possibly ssh into, with
   failure mode being complete breakage of any terminfo-using program)
Thus, putting aside historic terminals, there are only three TERM values:
 * linux
 * rxvt (used by its derivatives like aterm)
 * xterm (everything else)
(Skipping decorations like -256color which most programs hard-code anyway. 
I thus had to implement 256 color fallbacks in the kernel in 2016; it seems
that eg. 24-bit color is moving the same way.)

> > Putting aside arguments if this code is allowed or not (eg. the author of
> > Putty has strong feelings on the matter), it's very clearly not what you
> > asked for, thus the real bug is on tput's side.

> > Thus:
> > "tput sgr0" should produce sgr0, not setusg0 sgr0.
> 
> It does of course produce sgr0, i.e. it emits whatever escape sequence
> $TERM's terminfo entry declares as sgr0.  In the case of xterm-256color,
> sgr0=\E(B\E[m.

And it's that entry what's wrong.  sgr0 means "\e[0m" (or "\e[m"); see
eg. docs for real xterm: https://www.xfree86.org/current/ctlseqs.html

> The reason for including \E(B here is that sgr0 should cancel the
> effects of a previous smacs (start alternate character set) sequence and
> thus includes the rmacs (end alternate character set) escape sequence.

Then it combines two completely different concepts in one label.  SGR is
for character attributes, G0/G1 are for encoding.

> People are relying on this behavior, see #595484 for instance.

Seems like an XKCD 1172 case.

> Closing the bug, because everything works as intended.

...

Well, I'm not going to fight a BTS war, but I don't agree with your
decision.

I'll work around this misbehaviour (as it's no extra work for me: I need
to handle legitimately occuring G0/G1 changes anyway).  Still, it is a bug
even if its severity is negligible: thanks to PuTTY's author's stubborness
no maintained software uses G0/G1 anymore.

Thus, the only real fallout is bloating terminal output.  It's still too
slow on serial links or inferior terminals (I felt bad about Scaleway's
web console just hours ago); saving three bytes per sgr0 is not much but
it is a very frequently used sequence.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄

Bug#1064369: gobject-introspection dropped versioned dependency on python3

[Jeremy Bícha]

On Tue, Feb 20, 2024 at 6:27 PM Simon McVittie  wrote:
> It's unfortunate that Ubuntu is trying to go directly from
> gobject-introspection 1.78.1-6 to 1.79.x, without ever getting the higher
> 1.78.1-x revisions that are in Debian testing: that would have decoupled
> the introduction of new binary packages from the GLib 2.79.x and Python
> 3.12 transitions.

Unfortunately, gobject-introspection 1.78.1-13 was uploaded a few
hours after Ubuntu started the Python 3.12 transition which has not
quite finished. We also thought that it was getting late to not have
gotten glib into Ubuntu so we synced glib 2.79 which then forced us to
get gboject-introspection 1.79 too. So glib can't migrate without
gobject-introspection which has to wait for python3-defaults to
migrate.

https://salsa.debian.org/gnome-team/gobject-introspection/-/merge_requests/14

I think there are few enough packages involved that we can manually
trigger the autopkgtests we need this week since I got the meson
ppc64el autopkgtest to pass.

Thank you,
Jeremy Bícha

Bug#1060326: #1060326,RM: obs-studio [ppc64el] -- ROM; unsatisfied build-dependency

[James Lu]

Hi,

Forwarding this along to maintainers of the affected packages. If 
there's no objection, I can look at opening those RM bugs.


(Chiming in here as I'm also affected by obs-studio being kicked from 
testing with looking-glass)


Best,
James

On Sun, 14 Jan 2024 17:16:55 + (UTC) Thorsten Alteholz 
 wrote:

Control: tags -1 + moreinfo

Hi IOhannes,

there are reverse dependencies that need to be taken care of:


Checking reverse dependencies...
# Broken Depends:
obs-3d-effect: obs-3d-effect
obs-advanced-scene-switcher: obs-advanced-scene-switcher
obs-ashmanix-blur-filter: obs-ashmanix-blur-filter
obs-ashmanix-countdown: obs-ashmanix-countdown
obs-color-monitor: obs-color-monitor
obs-command-source: obs-command-source
obs-downstream-keyer: obs-downstream-keyer
obs-gradient-source: obs-gradient-source
obs-move-transition: obs-move-transition
obs-ptz: obs-ptz
obs-scene-as-transition: obs-scene-as-transition
obs-scene-collection-manager: obs-scene-collection-manager
obs-scene-notes-dock: obs-scene-notes-dock
obs-scene-tree-view: obs-scene-tree-view
obs-source-clone: obs-source-clone
obs-source-copy: obs-source-copy
obs-time-source: obs-time-source
obs-transition-table: obs-transition-table
obs-vintage-filter: obs-vintage-filter
obs-websocket: obs-websocket

# Broken Build-Depends:
looking-glass: libobs-dev
obs-3d-effect: libobs-dev (29 >=)
obs-advanced-scene-switcher: libobs-dev (26.1.2 >=)
obs-ashmanix-blur-filter: libobs-dev
obs-ashmanix-countdown: libobs-dev (29 >=)
obs-color-monitor: libobs-dev (29 >=)
obs-command-source: libobs-dev (29 >=)
obs-downstream-keyer: libobs-dev (29 >=)
obs-gradient-source: libobs-dev (29 >=)
obs-move-transition: libobs-dev (28.0.1 >=)
obs-ptz: libobs-dev
obs-scene-as-transition: libobs-dev (29 >=)
obs-scene-collection-manager: libobs-dev (28.0.1 >=)
obs-scene-notes-dock: libobs-dev (29 >=)
obs-scene-tree-view: libobs-dev (29 >=)
obs-source-clone: libobs-dev (29 >=)
obs-source-copy: libobs-dev (29 >=)
obs-time-source: libobs-dev
obs-transition-table: libobs-dev (29 >=)
obs-vintage-filter: libobs-dev (29 >=)
obs-websocket: libobs-dev (26.1 >=)


In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


   Thorsten




OpenPGP_0x2EC3F60DE71C0B9D.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057533: qpid-proton-j-extensions: FTBFS with default Java 21

[tony mancill]

On Fri, Feb 16, 2024 at 04:10:16PM +1300, Vladimir Petko wrote:
>  [1] 
> https://salsa.debian.org/java-team/qpid-proton-j-extensions/-/merge_requests/1

Merged and uploaded.  Thank you for patch!

Bug#1052138: RFS: ukui-kwin/5.27.5-1 [ITP] -- UKUI window manager gl utils library

[Aron Xu]

Hi,

On Tue, 20 Feb 2024 14:43:22 +0800 MouseZhang  wrote:
> Hi,
>
> Thanks for your inquiry regarding the package.
>
> > * Which version of the original kwin is used?
> Based on version 5.27.5 of the original kwin.
>

OK, please document that somewhere in your release.

> > * What is missing from the original kwin and why is a fork needed?
> The decision to fork the original kwin was driven by specific needs and 
> requirements that were not fully met by the original project.
> This fork allows us to tailor the window manager more closely to our specific 
> features within the UKUI environment.
> 1. Tablet Mode Support: We have incorporated support for the UKUI tablet 
> mode, which differs from the existing tablet mode mechanism in KWin. 
> Therefore, corresponding modifications are required to adapt to our desktop 
> environment.
> 2. Virtual Keyboard: We have developed a virtual keyboard, but the current 
> window layering in KWin does not fully meet our needs. Particularly, when 
> using the virtual keyboard for text input, pop-up windows such as QCompleter 
> often obscure the virtual keyboard. To address this issue, we need to add a 
> new window layer to ensure that the virtual keyboard always displays above 
> popup windows.
> 3. Custom Protocols: To fulfill the application requirements in the UKUI 
> environment, we have added or modified certain protocols, such as the blur 
> effect with gradual intensity changes.
> 4. Window Snapping Functionality: We have implemented a window snapping 
> feature similar to that in Windows 11, which allows users to manage windows 
> more efficiently.
> 5. Global Gestures: We have replaced the original edge gestures in KWin with 
> global gestures, such as using a four-finger swipe to invoke search.
> 6. Dependency Management: We aim to release UKUI without some of the 
> dependencies associated with the Plasma desktop environment, while still 
> using KWin as our window manager and Wayland compositor.
> 7. X11 Support: We require continued support for X11 and plan to develop new 
> features to ensure flexibility and compatibility of UKUI across various 
> systems.
>

Understood.

> > * What changes have been made based on the original kwin?
> Currently, ukui-kwin only replaces the name and does not conflict with the 
> original kwin.
> In order to meet the Ubuntu DebianImportFreeze deadline, we hope to first 
> introduce ukui-kwin into the Debian repository and then proceed with 
> functionality transplantation. The existing kwin repository used by the UKUI 
> desktop environment is located at https://gitee.com/openkylin/kwin, which 
> includes the aforementioned functionality. However, this conflicts with the 
> original kwin, so we need to fork ukui-kwin. Subsequently, the functionality 
> will be transplanted into UKUI-Kwin (https://gitee.com/openkylin/ukui-kwin).
>

But this does not sound like a reason to just rename and release - if
the reasons behind forking it aren't addressed to some certain extent,
it makes little to no sense to duplicate it in the archive. Therefore
I'd vote my -1 regarding this upload.

Thanks,
Aron

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

[Matt Marjanovic]

Package: grub-efi-amd64
Version: 2.12-1
Followup-For: Bug #1056764
X-Debbugs-Cc: mad...@mir.com

Dear Maintainer,

FYI, I experienced a pretty similar problem today:  failure to boot after
upgrading to 2.12-1.

Machine:  Lenovo Thinkpad T460p
   BIOS:  2.36 (initially)
  UEFI boot (without SecureBoot enabled)

Upon reboot, after showing the Lenovo splash screen, the system would just
drop into the BIOS setup screen.  My eventual workaround was to boot into
rescue-mode via a Debian 12.5 installer on a USB flashdrive and reinstall
the older grub (bookworm's 2.06-etc) from that.

I did upgrade the BIOS after that (from 2.36 -> 2.37, via fwupdmgr), but
I do not remember if I tried grub 2.12-1 again after that.  (By then, I was
just wanting to get some work done.)

-mm


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/mentos--vg-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda4 /boot ext2 rw,relatime 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 video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  
6c2d2f8f-084d-4291-927b-8a0a77ffa9ba
else
  search --no-floppy --fs-uuid --set=root 6c2d2f8f-084d-4291-927b-8a0a77ffa9ba
fi
font="/grub/unicode.pf2"
fi

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

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  
6c2d2f8f-084d-4291-927b-8a0a77ffa9ba
else
  search --no-floppy --fs-uuid --set=root 6c2d2f8f-084d-4291-927b-8a0a77ffa9ba
fi
insmod png
if background_image /grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-19f8d973-adaa-4fa2-8fb4-74ac2cc923f9' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  
6c2d2f8f-084d-4291-927b-8a0a77ffa9ba
else
  search --no-floppy --fs-uuid --set=root 
6c2d2f8f-084d-4291-927b-8a0a77ffa9ba
fi
echo'Loading Linux 6.6.15-amd64 ...'
linux   /vmlinuz-6.6.15-amd64 root=/dev/mapper/mentos--vg-root ro  
quiet rd.driver.blacklist=nouveau nouveau.modeset=0 modprobe.blacklist=nouveau 
no_console_suspend modprobe.blacklist=mei_wdt rd.driver.blacklist=mei_wdt 
acpi_osi=Linux
echo'Loading initial ramdisk ...'
initrd  /initrd.img-6.6.15-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 

Bug#1059236: closed by Gianfranco Costamagna (Re: Bug#1057954: RFS: nanomsg/1.2+dfsg-1 [ITA] -- nanomsg utilities)

[Phil Wyett]

Control: reopen -1

On Tue, 2024-02-20 at 08:12 +, Gianfranco Costamagna wrote:
> Hello,
> 
> > I think I need advice here. I am tempted to breaks replace and upgrade all 
> > to
> > libnanomsg6
> > and then work with upstream on SONAMES etc. How would you and Tobias 
> > proceed?
> 
> yes, this is correct. Change soname and go for experimental, and ask upstream 
> to change
> soname only
> if symbols are changed.
> 
> G.

Hi Gianfranco,

This is now done and ready for review.

Regards copyrights that pop-up i.e.:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059236#16

This is the original author, now working under their company name.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




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

Bug#1061599: gnome-online-accounts: cannot login to Nextcloud 26.0.7 since 3.49.0-1 - http 405 method not allowed

[Alban Browaeys]

On Wed, 21 Feb 2024 01:43:11 +0100 Alban Browaeys 
wrote:
> Note that 3.49.1 also includes a migration to GTK4 and API changes
> which would breaks gnome-control-center 45 "Bump soname?"
> https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/291
> Though we have gnome-control-center 46~alpha-2 in trixie and 46~beta-
1
> in sid, I don't know which gnome-control-center 46 release was ported
> to this API (as I have 1:46~alpha-2 currently I believe it is not
> ported yet as it works with gnome-online-accounts 3.49.0).
> 


gnome-control-center 46~beta-1 is supposed to already be ported to the
new gnome-online-accounts gtk4 API, from
" online-accounts: port to new API"
https://gitlab.gnome.org/GNOME/gnome-control-center/-/commit/80fcc8c2f26f7561538418fc5d72e18ecbbe512b
so I believe that in sid gnome-control-center 46~beta-1, managing
accounts from gnome-online-accounts should already broken.
But installing this sid version, I can still show all accounts details
with gnome-online-accounts 3.49.0. I can also remove and adda kerberos
account.

Cheers,
Alban

Bug#1064380: RFS: jpeginfo/1.7.1-1 [Team] -- Prints information and tests integrity of JPEG/JFIF files

[肖盛文]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "jpeginfo":

* Package name : jpeginfo
Version : 1.7.1-1
Upstream contact : [fill in name and email of upstream]
* URL : https://www.kokkonen.net/tjko/projects.html
* License : GPL-3
* Vcs : https://salsa.debian.org/debian-phototools-team/jpeginfo
Section : graphics

The source builds the following binary packages:

jpeginfo - Prints information and tests integrity of JPEG/JFIF files

To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/jpeginfo/

Alternatively, you can download the package with 'dget' using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/j/jpeginfo/jpeginfo_1.7.1-1.dsc


Changes since the last upload:

jpeginfo (1.7.1-1) unstable; urgency=medium
.
* Team upload.
* New upstream version
* d/copyright:
- update copyright year info to 2024
- change upstream License to GPL-3
* use upstream make install
- d/rules: delete override_dh_auto_install target
- delete d/install d/manpages
* d/rules:
- add export DEB_BUILD_MAINT_OPTIONS = hardening=+all
- add override_dh_autoreconf target
* remove d/patches, no more use
* d/watch: add opts=pgpsigurlmangle=s%$%.sig%
* add d/clean
* add d/u/metadata
* add d/u/signing-key.asc

Regards,

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064343: tput sgr0 adds uncalled-for codes

[Paul Wise]

On Tue, 2024-02-20 at 19:41 +0100, Sven Joachim wrote:

> Maybe that is true for the Linux console, but we are talking about xterm here.

It is actually gnome-terminal, but I guess that doesn't change things,
I presume gnome-terminal emulates xterm faithfully enough.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1064016: fixed in adwaita-icon-theme 46~beta-2

[Amy Kos]

Thank You for the explanation.
My prior suggestion is not worthwhile.


What names is it looking for?


lxqt-config/lxqt-config-appearance looks for:

left_ptr_watch -> progress
size_fdiag -> nwse-resize
d9ce0ab605698f320427677b458ad60b -> help

None of these cursors are high-visibility.
The hash-based alias is likely not visible at all.

I'll try to contact LXQt upstream to address this minor issue.

I would prefer not to have too many aliases that have been specifically 
rejected upstream


Right. I fully agree.

Cheers,
Amy

Bug#1064369: gobject-introspection dropped versioned dependency on python3

[Simon McVittie]

On Tue, 20 Feb 2024 at 23:15:09 +0100, Matthias Klose wrote:
> On 20.02.24 22:50, Simon McVittie wrote:
> > What is the situation that is going wrong in autopkgtest? Can you perhaps
> > provide a log?
> 
> see
> https://autopkgtest.ubuntu.com/packages/m/meson/noble/ppc64el
> 
> the one triggered by python3-defaults/3.12.1-0ubuntu1
> gobject-introspection/1.79.1-1

Do you mean b2bf9aa6-b7bf-4f75-a69c-d2292de2ebbe, requested by you with
those two packages as triggers, which failed like this?

377s autopkgtest [20:34:18]: test exhaustive: preparing testbed
...
559s The following packages have unmet dependencies:
559s  gobject-introspection : Depends: python3 (< 3.12) but 3.12.1-0ubuntu1 is 
to be installed
559s  python3-dev : Depends: python3 (= 3.11.4-5ubuntu1) but 3.12.1-0ubuntu1 is 
to be installed
559s E: Unable to correct problems, you have held broken packages.
559s autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt 
install on test deps directly for further data about failing dependencies in 
test logs
559s exhaustive   FAIL badpkg

It isn't clear to me why that one is failing. apt seems to have started
by trying to install gobject-introspection_1.78.1-6, even though it had
--apt-pocket=proposed=src:python3-defaults,src:gobject-introspection on the
autopkgtest command-line - which I would have expected would make all binary
packages from src:gobject-introspection have 1.79.1-1 as the candidate
version?

Is it possible that autopkgtest might be adding pins for all of the
binary packages built by src:gobject-introspection in noble that will
take those binary packages from -proposed, but without adding similar pins
for the binary packages that were newly added in -proposed? Or some similar
interaction?

It's unfortunate that Ubuntu is trying to go directly from
gobject-introspection 1.78.1-6 to 1.79.x, without ever getting the higher
1.78.1-x revisions that are in Debian testing: that would have decoupled
the introduction of new binary packages from the GLib 2.79.x and Python
3.12 transitions.

> The problem is, that the -bin package is new and that no rdeps know about it
> yet.

rdeps are not meant to depend on the -bin package directly (it's meant
to be an implementation detail of the main g-i package), so any solution
that involves adding the -bin package to rdeps' dependencies seems like
the wrong thing. Ideally, all rdeps continue to not know about it.

smcv

Bug#1064378: libevolution: identified for time_t transition but no ABI in shlibs

[Michael Hudson-Doyle]

Package: libevolution
Version: 3.50.3-1
Severity: important
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainers,

Analysis of the archive for the 64-bit time_t transition[0][1]
identifies libevolution as an affected package, on the basis that the
headers could not be compiled and analyzed out of the box using
abi-compliance-checker[2], so we have to assume it's affected (also, a
quick manual peek at the headers suggests that the package very likely
to be affected by the transition!)

However, libevolution's shlibs file declares a dependency on a library
package name that contains no ABI information:

$ cat DEBIAN/shlibs
libeabutil 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libeabwidgets 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libecontacteditor 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libecontactlisteditor 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libecontactprint 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libemail-engine 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libessmime 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-addressbook-importers 0 libevolution (>= 3.50.3), libevolution (<< 
3.51)
libevolution-calendar-importers 0 libevolution (>= 3.50.3), libevolution (<< 
3.51)
libevolution-calendar 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-mail-composer 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-mail-formatter 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-mail-importers 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-mail 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-shell 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-smime 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libevolution-util 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
libgnomecanvas 0 libevolution (>= 3.50.3), libevolution (<< 3.51)
$

It is therefore not obvious that we should rename the package to
'libevolution-t64' as part of this transition.

Looking at the archive, the only packages that depend on this package
are also built from the evolution source package.

Since there is no self-evident thing to do with the library package
name here, we will not be handling this package as part of the mass
NMUs.  Instead I am filing a serious bug because partial upgrades from
bookworm to trixie on 32-bit architectures (e.g. upgrading
libevolution without also upgrading evolution-plugin-bogofilter) will
result in ABI skew and may result in broken behavior.

Cheers,
mwh

[0] https://wiki.debian.org/ReleaseGoals/64bit-time
[1] https://lists.debian.org/debian-devel/2024/01/msg00041.html
[2] 
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-16T21%3A19%3A00/logs/evolution-dev/base/log.txt


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

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

Bug#1064379: kexec-tools: Request to pull v2.0.28 for loong64 architecture.

[Ming Wang]

Package: kexec-tools
Version: 1:2.0.27-1
Source Version: 1:2.0.27-1
Severity: wishlist
Tags: fixed-upstream
User: debian-de...@lists.debian.org
Usertags: loongarch64

Dear kexec-tools maintainers,

I found that currently there are build errors with kexec-tools for loong64 
architecture,see[1].
The upstream code has been fixed, see [2]. v2.0.28 already contains relevant 
patch.

So is it possible to pull kexec-tools-v2.0.28 for loong64?

[1]: https://buildd.debian.org/status/package.php?p=kexec-tools=sid
[2]: 
https://github.com/horms/kexec-tools/commit/ab3a70af85679bbc5efe63057c7f65365ed6e748

thanks,
Ming

Bug#1064378: libevolution: identified for time_t transition but no ABI in shlibs

[Jeremy Bícha]

On Tue, Feb 20, 2024 at 7:24 PM Michael Hudson-Doyle
 wrote:
> It is therefore not obvious that we should rename the package to
> 'libevolution-t64' as part of this transition.
>
> Looking at the archive, the only packages that depend on this package
> are also built from the evolution source package.

evolution-ews also depends on libevolution. However, evolution and
evolution-ews have such a strict dependency on evolution-data-server
that I agree that I don't think any change will be necessary for
evolution. Note that evolution-data-server is getting its libraries
renamed for the time transition.

I also expect to do an evolution 3.52 transition soon after the time
transition completes.

Thank you,
Jeremy Bícha

Bug#1062995: tslib: NMU diff for 64-bit time_t transition

[Martin Kepplinger]

Am Sonntag, dem 04.02.2024 um 10:51 + schrieb Steve Langasek:
> Source: tslib
> Version: 1.22-1
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
> 
> NOTICE: these changes must not be uploaded to unstable yet!
> 
> Dear maintainer,
> 
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> tslib as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
> 
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
> 
> Since turning on 64-bit time_t is being handled centrally through a
> change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it
> is
> important that libraries affected by this ABI change all be uploaded
> close
> together in time.  Therefore I have prepared a 0-day NMU for tslib
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
> 
> Please find the patch for this NMU attached.
> 
> If you have any concerns about this patch, please reach out ASAP. 
> Although
> this package will be uploaded to experimental immediately, there will
> be a
> period of several days before we begin uploads to unstable; so if
> information
> becomes available that your package should not be included in the
> transition,
> there is time for us to amend the planned uploads.
> 
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C, 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)

hi Steve,

in general, tslib only ever uses time_t differences, so apart from one
glitch when wrapping around, the library will continue to work after
2038 as-is.

I'll look at what `__TIMESIZE` currently is on 32bit archs. But given
the low-impact this has for tslib functionality-wise, I'd rather find
the correct change (any help appreciated), and increment LT_CURRENT.

So: where do I start in order to comply with your scripts? do I simply
add `D__USE_TIME_BITS64` to CPPFLAGS?

thanks,

   martin

Bug#1062022: dcmtk: NMU diff for 64-bit time_t transition

[Michael Hudson-Doyle]

On Wed, 31 Jan 2024 at 22:03, Mathieu Malaterre  wrote:

> Hi,
>
> On Wed, Jan 31, 2024 at 1:09 AM  wrote:
> > If you have any concerns about this patch, please reach out ASAP.
> Although
> > this package will be uploaded to experimental immediately, there will be
> a
>
> Are you going to nuke my work on dcmtk 3.6.8 transition ?
>

Hi,

Sorry for the late reply. No, we are not going to nuke your work on the
transition. We still expect to NMU dcmtk to unstable along with the other
packages to avoid creating a dependence on your timetable, but you should
be able to ignore those changes when you do your transition in unstable.

Cheers,
mwh

Bug#1064346: Source is missing errors on HTML source files

[Soren Stoutner]

Shriram,

1.  For anything that has the unminified source in the upstream tarball, I 
would just create a 
lintian override with a comment listing the full path to the source for each 
file.  You can see 
an example of how this can be done here:

https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/source/lintian-overrides?ref_type=heads[1]

Typically you only copy the source to the debian/missing-sources directory when 
it is not 
included in the upstream tarball and you have had to acquire it from another 
place.

2.  The github link below includes an embedded font in woff format.  Typically, 
fonts like 
this would be considered compiled, so a separate font source would be needed.  
However, 
I’m not sure what the Debian guidance for dealing with an HTML embedded font 
like this.  
If someone else on mentors doesn’t know, I would recommend you ask on 
debian-legal.

As these are mostly README files, and if it becomes difficult for you to 
acquire the source 
for some of them, you might consider excluding those you can’t get the source 
for, at least 
temporarily, using Files-Excluded in debian/copyright (and then running uscan, 
which will 
produce a modified tarball that does not include the problematic files).  For 
example, see:

https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/copyright?
ref_type=heads[2]

Whether this is a good option depends on how helpful those README files are for 
the users 
of your package.  If you go this route, you should add +dfsg to the version of 
your package 
to indicate that the upstream tarball has been repackaged to remove files that 
are not free 
(or for which the source is not available).

Soren

On Tuesday, February 20, 2024 8:23:41 PM MST Shriram Ravindranathan wrote:
> Thanks, Soren.
> 
> It looks like most of these files have just one or two lines that are 
> extremely long.
> 
> These are mostly README files. Most of them seem to have this 
> github-markdown.css 
>  
> minified and pasted in them. While others have the sources that were 
> used to generate them listed in the same folder.
>
> Should I copy these sources into the d/missing-sources directory?

-- 
Soren Stoutner
so...@debian.org


[1] 
https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/source/
lintian-overrides?ref_type=heads
[2] 
https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/copyright?
ref_type=heads


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

Bug#1057536: tiles-autotag: FTBFS with default Java 21

[tony mancill]

On Fri, Feb 16, 2024 at 04:22:14PM +1300, Vladimir Petko wrote:
> Hi,
> 
> The issue is caused by the outdated version of the byte-buddy. Upgrading it
> to 1.14 should solve the issue.
> The issue can be worked around by adding -Dnet.bytebuddy.experimental=true
> to the argLine in maven-surefire-plugin.

FTBFS with Java 21 fixed via the work-around for now.

Bug#1063842: openssh-server: Binding to a static IPv6 address causes sshd to fail at bootup

[bert]

Thanks for the info on making a persistent change, this is helpful as a 
workaround for now.

I had previously tried to make it start after networking or networkmanager, 
without success. It seems it doesn’t wait for DAD.

It would be better if SSHD didn’t give up in scenarios like this, and kept 
retrying to start. For hosts without physical access, a lack of SSHD can be a 
big problem. 

Firewall rules are not always desirable, as enabling the firewall (and 
especially conntrack) can incur a significant performance hit, or introduce 
other problems. Systems acting as routers, or being used for network scanning 
for example.

There are also other reasons to bind to specific addresses, for instance if you 
want to run something else on the same port but a different address.

In any case binding to a specific address is a documented feature of OpenSSH, 
so it should be usable.

Bug#1033352: sbuild: autokpgtest-virt-server needs host $HOME

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Christian Kastner (2023-03-23 09:53:05)
> Attempting to build a package with the autopkgtest-virt-podman backend fails
> because of what I suspect is an issue with $HOME directory handling. podman
> needs $HOME on the host to find containers, but it defaults to
> /sbuild-nonexistent, which I guess is meant for the target enviromnent.

is this a duplicate of #1061388?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1064383: geeqie could depend-on/recommend webp-pixbuf-loader for animated webp support

[Bence Romsics]

Package: geeqie
Version: 1:2.2-1
Severity: normal
X-Debbugs-Cc: bence.roms...@gmail.com

Dear Maintainer,

On my Debian SID system geeqie can display animated webp files if
webp-pixbuf-loader is also installed. However the geeqie package
metadata does not seem to refer to this in any way. And without
webp-pixbuf-loader geeqie shows only a broken file icon for an
animated webp file.

Maybe the geeqie package could recommend or depend on
webp-pixbuf-loader.

Version of webp-pixbuf-loader:
ii  webp-pixbuf-loader:amd64  0.2.4-2+b1

The upstream bug that made me realize geeqie can display animated webp:
https://github.com/BestImageViewer/geeqie/issues/1086

An animated webp file I used to test:
https://mathiasbynens.be/demo/animated-webp-supported.webp

Thanks in advance,
Bence Romsics

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

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

Versions of packages geeqie depends on:
ii  geeqie-common1:2.2-1
ii  libarchive13 3.7.2-1
ii  libc62.37-15
ii  libcairo21.18.0-1+b1
ii  libdjvulibre21   3.5.28-2+b1
ii  libexiv2-27  0.27.6-1+b1
ii  libffmpegthumbnailer4v5  2.2.2+git20220218+dfsg-2+b1
ii  libgcc-s114-20240201-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libglib2.0-0 2.78.3-2
ii  libgspell-1-21.12.2-1
ii  libgtk-3-0   3.24.41-1
ii  libheif1 1.17.6-1
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  libjxl0.70.7.0-10.2+b1
ii  liblcms2-2   2.14-2
ii  liblua5.3-0  5.3.6-2
ii  libopenjp2-7 2.5.0-2+b2
ii  libpango-1.0-0   1.51.0+ds-4
ii  libpangocairo-1.0-0  1.51.0+ds-4
ii  libpoppler-glib8 22.12.0-2+b1
ii  libraw23 0.21.2-2
ii  libstdc++6   14-20240201-1
ii  libtiff6 4.5.1+git230720-4
ii  libwebp7 1.3.2-0.4
ii  sensible-utils   0.0.20

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.4.7-1+b1
ii  exiftran 2.10-5
ii  exiv20.27.6-1+b1
ii  imagemagick  8:6.9.12.98+dfsg1-5+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.12.98+dfsg1-5+b1
ii  librsvg2-common  2.54.7+dfsg-2
ii  zenity   4.0.1-1

Versions of packages geeqie suggests:
ii  gimp 2.10.36-2
ii  libjpeg-turbo-progs [libjpeg-progs]  1:2.1.5-2+b2
pn  xpaint   

-- no debconf information