Bug#1003855: RFS: kotlin-mode/20210917git0-1 [RFP] -- Emacs major mode for kotlin

[Nicholas D Steeves]

Hi Joshua,

Joshua Peisach  writes:

> Hi Nicholas,
>
> The pristine-tar branch is already pushed. And finals won't be happening 
> until April ish
>
> https://salsa.debian.org/emacsen-team/kotlin-mode/-/tree/pristine-tar
>
>
> Is something missing?

Ah, sorry, I was scanning for a 0.*~ prefixed version and communicated
poorly.  This is needed to defend against the use of an epoch whenever
upstream switches to a tagging stable version, ie 20210917git0 sorts
higher than 1.0.0.

The cause of this was overriding uscan's "pretty" option in
debian/watch.

I made the necessary fixups and uploaded.  Please review the changes at
your leisure :-)


Cheers,
Nicholas

P.S. I chose to enforce xz compression because you're using uscan's git
mode, which makes the argument for github release tarballs
nonapplicable.  For some reason your copy of uscan downloaded an
orig.tar.gz instead of an orig.tar.xz, and this gbp.conf will prevent
"what is going on?!" moments from emerging.


signature.asc
Description: PGP signature

Bug#1007888: libnftables1: add a debian symbols file for API tracking

[Steve Beattie]

Package: nftables
Version: 1.0.2-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch


In Ubuntu, the attached patch was applied to detect and track API
changes to libnftables1.

  * debian/libnftables1.symbols:
- create a symbols file to ensure the API does not accidentally
  change over time (LP: #1965464)


Thanks for considering the patch.

*** /home/steve/tmp/tmpnuvlt8uz/nftables_1.0.2-1ubuntu1.debdiff
diff -Nru nftables-1.0.2/debian/libnftables1.symbols 
nftables-1.0.2/debian/libnftables1.symbols
--- nftables-1.0.2/debian/libnftables1.symbols  1969-12-31 16:00:00.0 
-0800
+++ nftables-1.0.2/debian/libnftables1.symbols  2022-03-17 18:14:57.0 
-0700
@@ -0,0 +1,25 @@
+libnftables.so.1 libnftables1 #MINVER#
+ nft_ctx_add_include_path@Base 0.9.2
+ nft_ctx_add_var@Base 1.0.0
+ nft_ctx_buffer_error@Base 0.9.2
+ nft_ctx_buffer_output@Base 0.9.2
+ nft_ctx_clear_include_paths@Base 0.9.2
+ nft_ctx_clear_vars@Base 1.0.0
+ nft_ctx_free@Base 0.9.2
+ nft_ctx_get_dry_run@Base 0.9.2
+ nft_ctx_get_error_buffer@Base 0.9.2
+ nft_ctx_get_optimize@Base 1.0.2
+ nft_ctx_get_output_buffer@Base 0.9.2
+ nft_ctx_new@Base 0.9.2
+ nft_ctx_output_get_debug@Base 0.9.2
+ nft_ctx_output_get_flags@Base 0.9.2
+ nft_ctx_output_set_debug@Base 0.9.2
+ nft_ctx_output_set_flags@Base 0.9.2
+ nft_ctx_set_dry_run@Base 0.9.2
+ nft_ctx_set_error@Base 0.9.2
+ nft_ctx_set_optimize@Base 1.0.2
+ nft_ctx_set_output@Base 0.9.2
+ nft_ctx_unbuffer_error@Base 0.9.2
+ nft_ctx_unbuffer_output@Base 0.9.2
+ nft_run_cmd_from_buffer@Base 0.9.2
+ nft_run_cmd_from_filename@Base 0.9.2


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

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


signature.asc
Description: PGP signature

Bug#994489: vim-scripts: consider including eregex.vim (PCRE patterns)

[Christoph Anton Mitterer]

Ah... my bad :D

Thanks,
Chris.

Bug#1007887: vim: Remove "Depends: xxd" from vim-common

[James McCoy]

Source: vim
Version: 2:8.2.3995-1
Severity: normal

xxd has been its own package since 2016-09-10.  Packages that were
(Build-)Depending on vim-common for xxd should transition.  This bug
will be used to track that progress.


-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.gtk3
/usr/bin/vim is /usr/bin/vim.gtk3
/usr/bin/gvim is /usr/libexec/neovim-qt/gvim

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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 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

Bug#1007885: cyrus-imapd: Replace vim-common Build-Depends with xxd

[James McCoy]

Source: cyrus-imapd
Version: 3.6.0~beta2-1
Severity: normal

xxd has been its own package since 2016-09-10, so it's no longer
necessary to Build-Depend on vim-common.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 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

Bug#1007018: systemd: Creates broken symlink to stub-resolv.conf since v250

[Arnaud Rebillout]

> I guess to preserve the status quo ante, we should indeed just remove 
this new file systemd-resolve.conf.


I also think it's the good short-term solution, ie. to go back to how it 
was before v250, until a better solution is found.


> e.g. by splitting of systemd-resolved into a separate package.

It sounds reasonable, I did a quick search and found that it's what 
Fedora did a while ago: 
https://src.fedoraproject.org/rpms/systemd/pull-request/52


This being said, grepping for 'resolved' in the systemd.spec file, one 
can see that there's more subtleties, eg:


1. Remove /etc/resolv.conf symlink if systemd-resolved is uninstalled:

-> 
https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec#_898


2. They don't seem to use the tmpfiles to create the /etc/resolv.conf 
symlink:


-> 
https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec#_924


Cheers,

  Arnaud

Bug#1007884: bullseye-pu: package glewlwyd/2.5.2-2+deb11u2

[Nicolas Mora]

Package: release.debian.org
Severity: important
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

(Please provide enough information to help the release team
to judge the request efficiently. E.g. by filling in the
sections below.)

[ Reason ]
Possible buffer overflow on signature verification during webauthn assertion

[ Impact ]
Possibility of denial of service

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Check the length of the signature before verifying it

[ Other info ]
CVE ID request pending
Description: Fix buffer overflow
Author: Nicolas Mora 
Forwarded: not-needed
--- a/src/scheme/webauthn.c
+++ b/src/scheme/webauthn.c
@@ -2336,12 +2336,24 @@
 break;
   }
   
-  if (!o_base64url_decode((const unsigned char 
*)json_string_value(json_object_get(json_object_get(json_object_get(j_scheme_data,
 "credential"), "response"), "signature")), 
json_string_length(json_object_get(json_object_get(json_object_get(j_scheme_data,
 "credential"), "response"), "signature")), sig, _len)) {
-y_log_message(Y_LOG_LEVEL_DEBUG, "check_assertion - Error 
o_base64url_decode signature");
+  if (!o_base64_decode((const unsigned char 
*)json_string_value(json_object_get(json_object_get(json_object_get(j_scheme_data,
 "credential"), "response"), "signature")), 
json_string_length(json_object_get(json_object_get(json_object_get(j_scheme_data,
 "credential"), "response"), "signature")), NULL, _len)) {
+y_log_message(Y_LOG_LEVEL_DEBUG, "check_assertion - Invalid signature 
format");
 ret = G_ERROR_PARAM;
 break;
   }
   
+  if (sig_len > 128) {
+y_log_message(Y_LOG_LEVEL_DEBUG, "check_assertion - Invalid 
signature");
+ret = G_ERROR_PARAM;
+break;
+  }
+
+  if (!o_base64_decode((const unsigned char 
*)json_string_value(json_object_get(json_object_get(json_object_get(j_scheme_data,
 "credential"), "response"), "signature")), 
json_string_length(json_object_get(json_object_get(json_object_get(j_scheme_data,
 "credential"), "response"), "signature")), sig, _len)) {
+y_log_message(Y_LOG_LEVEL_DEBUG, "check_assertion - Error 
o_base64_decode signature");
+ret = G_ERROR;
+break;
+  }
+
   memcpy(data_signed, auth_data, auth_data_len);
   memcpy(data_signed+auth_data_len, cdata_hash, cdata_hash_len);
   

Bug#994489: vim-scripts: consider including eregex.vim (PCRE patterns)

[James McCoy]

On Fri, Mar 18, 2022 at 02:09:34AM +0100, Christoph Anton Mitterer wrote:
> Hey.
> 
> That's really very sad to hear.
> 
> I think actually the opposite would be good.
> 
> Just as with any addons for Firefox/Thunderbird, GNOME, Cinnamon, etc.
> ... having these as proper Debian packages

I think you're misunderstanding what I meant.  dh_vim-addon is a helper
for packaging Vim addons.  I'd prefer people to use that to create
Debian packages for addons they want and maintain them in Debian.

The thing I dislike is amalgamation packages like vim-scripts, because
they just become a dumping ground of random things that _someone_
requested but no additional help in maintenance.

They also are more difficult to gauge when aspects should be retired,
since there are only metrics for the whole package.

That's why I plan to split vim-scripts itself into individual packages,
likely dropping some of the addons in the process.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1007767: python3-httpx: Need h11 0.11+

[Sandro Tosi]

On Wed, Mar 16, 2022 at 8:57 AM Matthias Urlichs  wrote:
>
> Package: python3-httpx
> Version: 0.22.0-1
> Severity: important
> X-Debbugs-Cc: sm...@smurf.noris.de
>
> Please teach httpx that it needs to depend on h11 >>0.11.

i think this is more a problem in httpcore than httpx, given the
latter has no direct dependencies on h11

> Error while testing:
>
> self = http://localhost:40923', CLOSED, Request 
> Count: 1]>
> request = 
>
> async def _receive_response_headers(
> self, request: Request
> ) -> Tuple[bytes, int, bytes, List[Tuple[bytes, bytes]]]:
> timeouts = request.extensions.get("timeout", {})
> timeout = timeouts.get("read", None)
>
> while True:
> event = await self._receive_event(timeout=timeout)
> if isinstance(event, h11.Response):
> break
>
> http_version = b"HTTP/" + event.http_version
>
> # h11 version 0.11+ supports a `raw_items` interface to get the
> # raw header casing, rather than the enforced lowercase headers.
> >   headers = event.headers.raw_items()
> E   AttributeError: 'list' object has no attribute 'raw_items'

what exactly were you running that caused this issue?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#994489: vim-scripts: consider including eregex.vim (PCRE patterns)

[Christoph Anton Mitterer]

Hey.

That's really very sad to hear.

I think actually the opposite would be good.

Just as with any addons for Firefox/Thunderbird, GNOME, Cinnamon, etc.
... having these as proper Debian packages (instead of everyone
downloading them on personally) not only gives in principle security
support coverage, but also some level of protection because a possible
attacker can no longer selectively send out hacked versions to only
certain users, but would rather hit *all* (Debian) users, which makes
it more likely that an attack is ever noticed.


Cheers,
Chris.

Bug#919598: zlib: copyright file needs updating

[Mark Brown]

On Thu, Jan 17, 2019 at 07:14:00PM +0100, Kai Pastor, DG0YT wrote:

> a) the zlib 1:1.2.11.dfsg-1 copyright file claims to be based on sources
> from zlib-1.0.4.tar.gz which is obviously wrong.

That's just descriptive stuff about the creation of the package
transferred over from the free form changelog.

> The win32 directory is how I came here: I'm building for Mingw from the
> Debian sources, which now fails. Is the removal of the win32 directory
> neccessary? I do see the restrictions established in win32/DLL_FAQ.txt.
> However, I don't think these restrictions are removed by removing this file.
> They may apply to the DFSG sources as well, even with the win32 dir removed.

I can't immediately see why it was removed, I don't even see
which restrictions you're referring to in the DLL FAQ.  It could
*probably* be added back, though there might be something I'm
missing.


signature.asc
Description: PGP signature

Bug#1007883: python3-sphinx: Dependent packages fail with 'no module named ipython_genutils'

[Jérémy Lal]

Package: python3-sphinx
Version: 4.3.2-1
Severity: important

When doing a rebuild of python-xarray, jupyter-notebook,
these FTBFS showed up:
https://bugs.debian.org/1007850
https://bugs.debian.org/1007880

It seems the issue comes from sphinx ?

Regards,

Jérémy

Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1

[Daniel Kahn Gillmor]

On Thu 2022-03-17 17:49:04 +, Adam D. Barratt wrote:
> On Sat, 2022-02-19 at 22:24 -0500, Daniel Kahn Gillmor wrote:
>> On Sat 2022-02-19 17:09:21 +, Adam D. Barratt wrote:
>> > Control: tags -1 + confirmed d-i
>> > 
> [...]
>> > That looks fine to me, but will need a d-i ack as the package
>> > builds a
>> > udeb; tagging and CCing accordingly.
>> 
>> Understood -- i'll wait for a d-i ack before uploading.
>
> As we're getting very close to the window for 11.3 closing, please feel
> free to upload.

I've just uploaded gnupg2/2.2.27-2+deb11u1 to bullseye now.  Please let
me know if there are any problems.

thanks for your ongoing work maintaining debian stable!

 --dkg


signature.asc
Description: PGP signature

Bug#1007882: RM: rust-weedle/0.12.0-2 rust-wasm-bindgen-webidl/0.2.75-1

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

James McCoy and I have been working on updating the rust-nom package from
version 5 to version 7, this is needed to enable ICMP support in sniffglue and
I belive it is also needed to facilitate packaging of alacritty.

In addition to the rust-nom package (which is currently version 5.x in testing
and version 7.x in unstable) there is a rust-nom-4 package providing version
4.x and a rust-nom-3 package providing version 3.x. It would be possible to
introduce a rust-nom-5 package as well but I don't think it's justifiable to
introduce yet another version at this time.

All but one of the reverse (build-)dependencies of nom 5.x have been ported to
nom 7.x, either by new upstream versions or by patching. That leaves
rust-weedle. rust-weedle has a single reverse (build-)dependency
rust-wasm-bindgen-webidl, neither of them are currently used by any applications
in Debian.

The version of rust-weedle currently in testing is the latest upstream version
and depends on nom 5.x. I tried patching it to use nom 7.x but failed to do
so, I also filed a bug report upstream but got no response. 

I then decided to try patching rust-weedle to use nom 4.x since that would at
least avoid introducing yet another version of nom to the archive. I did so
by reverting the upstream commit porting it from 4.x to 5.x. The tests passed
and I uploaded it as rust-weedle 0.12.0-2.

Unfortunately after uploading it I discovered that the autopkgtest for
rust-wasm-bindgen-webidl failed and it became clear that my upload of
rust-weedle had caused an API break. I attempted to try and adjust the
patch to avoid the API break but was not successful, I don't think the version
with the API break can be considered fit for release.

At that point I filed bug 1007026 to give the rest of the rust team a chance
to comment on the issue and said that if noone objected I planned to file
a removal request with the release team.

I now request that rust-weedle and rust-wasm-bindgen-webidl are removed from
testing so that rust-nom and it's reverse dependencies can migrate.

-- System Information:
Debian Release: 10.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Bug#1007881: nedit: Keyboard stops working if nedit has opened several files, and one is then closed

[Van Snyder]

Package: nedit
Version: 1:5.7-3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Open several files with nedit, then close one

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

Open separate files with separate instances of nedit.

   * What was the outcome of this action?

Mostly, this keeps the keyboard working, but sometimes, even if a nedit
instance is editing only one file, the keyboard stops working.

   * What outcome did you expect instead?

I expect the keyboard to continue to work.

I downloaded nedit 5.7 source and tried to compile it. If I link it
dynamically, the same problem occurs. The problem is probably in a
library that
nedit uses, or in the way that nedit is using it. I cannot link it
statically.
ld produces hundreds of "undefined reference" errors.

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


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

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

Versions of packages nedit depends on:
ii  libc6 2.31-13+deb11u2
ii  libx11-6  2:1.7.2-1
ii  libxm4    2.3.8-3
ii  libxt6    1:1.2.0-1

Versions of packages nedit recommends:
ii  xfonts-100dpi  1:1.0.4+nmu1.1
ii  xfonts-75dpi   1:1.0.4+nmu1.1

Versions of packages nedit suggests:
pn  csh  

Bug#1007880: python-xarray: FTBFS generating docs: nbsphinx no module named ipython_genutils

[Jérémy Lal]

Source: python-xarray
Version: 2022.03.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

It fails in a clean sid chroot with:

Could not import extension nbsphinx (exception: No module named 
'ipython_genutils')


Jérémy

Bug#1007840: [notmuch-slurp-debbug] notmuch-slurp-debbug should use "notmuch insert"

[Sean Whitton]

Hello,

On Thu 17 Mar 2022 at 06:18PM -04, Daniel Kahn Gillmor wrote:

> Hi Sean, thanks for the prompt response.
>
> On Thu 2022-03-17 11:34:32 -0700, Sean Whitton wrote:
>> On Thu 17 Mar 2022 at 01:51PM -04, Daniel Kahn Gillmor wrote:
>>> For backward compatibility, if a "maildir" configuration variable is
>>> present, it could fall back to the old form of insertion, but emit a
>>> warning that it is doing so.
>>
>> How about using 'notmuch insert --folder=' if the old config
>> key is present, and not issuing a warning?
>
> The trouble with that is that --insert is defined "relative to the
> top-level directory given by the value of database.mail_root.", whereas
> the maildir is a full filesystem path.
>
> Seems better to me to do a deprecation cycle.  It's noisier short term,
> but cleaner longterm.
>
> The other open question here is that "notmuch insert" on its own
> defaults to delivering at the top level, whereas notmuch-slurp-debbug
> wants to use the "inbox" folder just below the top level.
>
> I'm personally fine with the default delivery location changing, but if
> you think we ought to default to something like --folder=inbox
> --create-folder i'd be willing to do that too.

I was thinking that some users might want to ensure the new mail goes
into a particular subdirectory, as they can do at present (I know
Vagrant does this, for example).  You can do that with your new
insert_args, but why not support both ways?  We just File::Spec::abs2rel
the old configuration key and use it.

Most people won't want to pass any tags, this way the user doesn't have
to go read notmuch-insert(1), and we also get backwards compatibility
for free.

> If we go the --folder=inbox --create-folder route, then we'd need to
> decide whether the passthrough arguments would *append* to
> --folder=inbox --create-folder, or whether they would *replace*
> --folder=inbox --create-folder.  I'd lean toward replacement in that
> case.
>
> Also, what would you like this configuration key to be named?  I was
> thinking "insert_args".

Fine with me.

> d) if messages are placed by default via "--folder=inbox
>--create-folder", how should the config key interact with the default
>args?
>   (if we get to this question, i prefer replacement)

Replacement is okay with me.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007823: scotch breaks opm-grid autopkgtest: Failed to build dune-autopkgtest

[Markus Blatt]

Hi,

will look into this in more detail tomorrow, but it seems like the problem
might be in dune-common. The error is triggered during a CMake run that
uses FindMETIS.cmake (shipped with libdune-common-dev) and that fails.

Markus

Bug#1007840: [notmuch-slurp-debbug] notmuch-slurp-debbug should use "notmuch insert"

[Daniel Kahn Gillmor]

Hi Sean, thanks for the prompt response.

On Thu 2022-03-17 11:34:32 -0700, Sean Whitton wrote:
> On Thu 17 Mar 2022 at 01:51PM -04, Daniel Kahn Gillmor wrote:
>> For backward compatibility, if a "maildir" configuration variable is
>> present, it could fall back to the old form of insertion, but emit a
>> warning that it is doing so.
>
> How about using 'notmuch insert --folder=' if the old config
> key is present, and not issuing a warning?

The trouble with that is that --insert is defined "relative to the
top-level directory given by the value of database.mail_root.", whereas
the maildir is a full filesystem path.

Seems better to me to do a deprecation cycle.  It's noisier short term,
but cleaner longterm.

The other open question here is that "notmuch insert" on its own
defaults to delivering at the top level, whereas notmuch-slurp-debbug
wants to use the "inbox" folder just below the top level.

I'm personally fine with the default delivery location changing, but if
you think we ought to default to something like --folder=inbox
--create-folder i'd be willing to do that too.

>> When the old method is *not* used, we could add a passthrough option
>> that lets the user append arbitrary arguments to "notmuch insert",
>> which would also conveniently solve #995842.
>
> Nice.

If we go the --folder=inbox --create-folder route, then we'd need to
decide whether the passthrough arguments would *append* to
--folder=inbox --create-folder, or whether they would *replace*
--folder=inbox --create-folder.  I'd lean toward replacement in that
case.

Also, what would you like this configuration key to be named?  I was
thinking "insert_args".

So, four questions:

a) how to deal with existing maildir configuration key?
(i prefer emitting a warning and falling back to old behavior)

b) what should the config key be named?
(i prefer "insert_args")

c) where to place the new messages?
(i prefer the "notmuch insert" defaults, but could be
"--folder=inbox --create-folder")

d) if messages are placed by default via "--folder=inbox
   --create-folder", how should the config key interact with the default
   args?
  (if we get to this question, i prefer replacement)

Let me know what you prefer and i'll see whether i can offer a patch in
the coming days.

--dkg


signature.asc
Description: PGP signature

Bug#1007746: buster-pu: package glibc/2.28-10+deb10u1

[Aurelien Jarno]

On 2022-03-17 17:51, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
> 
> On Wed, 2022-03-16 at 00:50 +0100, Aurelien Jarno wrote:
> > A big part of the changes have been in the buster git branch for many
> > months, but I failed to submit the package for a point release up to
> > now. What triggered me to look at it again is breakage in the preinst
> > script when running on kernel x.y.z with z > 255.
> > 
> > In other changes are just an (old) pull from the stable branch,
> > fixing
> > a few important bugs.
> 
> Please go ahead, thanks.
> 
> As glibc produces a udeb, I'm tagging the bug and CCing accordingly.
> 

Thanks for the review despite the close deadline. I have just uploaded
it.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1007714: bullseye-pu: package openssh/1:8.4p1-5+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Tue, 2022-03-15 at 15:20 +, Colin Watson wrote:
> OpenSSH in stable breaks on 32-bit architectures (at least armhf,
> reportedly also i386) after upgrading libc6 to the version in
> bookworm,
> due to changes in its system call interface that affect OpenSSH's
> seccomp sandbox.  See https://bugs.debian.org/1004427.
> 
> [ Impact ]
> Without this change, I'm concerned that sshd may be unavailable
> during
> part of an upgrade from bullseye to bookworm (or even make the
> machine
> inaccessible, if it's headless and the upgrade fails).  Getting the
> sandbox tweak into bullseye at this stage would reduce that risk.
> 

Please go ahead.

As openssh builds a udeb, I'm CCing KiBi and tagging the bug
accordingly.

Regards,

Adam

Bug#1003855: convert RFP to ITP and set owner

[Nicholas D Steeves]

retitle 922934 ITP: kotlin-mode -- Emacs major mode for editing Kotlin files
owner 922934 Joshua Peisach 
thanks

Joshua, please take care to select the *reply to all* function rather
than "reply" in the future, because bug_num...@bugs.debian.org should be
kept in CC.  Debian is developed in the open, and not via private
messages.

Bug#1005949: bullseye-pu: package glibc/2.31-13+deb11u3

[Aurelien Jarno]

On 2022-03-17 17:49, Adam D. Barratt wrote:
> On Tue, 2022-03-15 at 20:33 +, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed d-i
> > 
> > On Thu, 2022-02-17 at 23:15 +0100, Aurelien Jarno wrote:
> > > There are multiple fixes in this upload:
> > > - 4 security bugs
> > > - a fix to avoid preinst script failure when running on kernel
> > > x.y.z
> > >   with z > 255. 
> > > - a fix to avoid changes to /etc/nsswitch.conf to be reverted on
> > > upgrade
> > > 
> > > [ Impact ]
> > > Installation will be left vulnerable to security issues and upgrade
> > > from buster will fail when running recent upstream stable kernels.
> > > 
> > 
> > This looks OK to me, thanks.
> > 
> > As glibc produces a udeb, this will want a KiBi-ack; CCing and
> > tagging
> > accordingly.
> 
> As we're getting very close to the window for 11.3 closing, please feel
> free to upload.

Thanks, I have just uploaded it.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#965459: coinor-ipopt: diff for NMU version 3.11.9-2.3

[Adrian Bunk]

Control: tags 965459 + patch

Dear maintainer,

I've prepared an NMU for coinor-ipopt (versioned as 3.11.9-2.3) and 
uploaded it to DELAYED/15. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru coinor-ipopt-3.11.9/debian/changelog coinor-ipopt-3.11.9/debian/changelog
--- coinor-ipopt-3.11.9/debian/changelog	2019-06-16 13:51:12.0 +0300
+++ coinor-ipopt-3.11.9/debian/changelog	2022-03-17 23:41:30.0 +0200
@@ -1,3 +1,10 @@
+coinor-ipopt (3.11.9-2.3) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/compat: 5 -> 7. (Closes: #965459)
+
+ -- Adrian Bunk   Thu, 17 Mar 2022 23:41:30 +0200
+
 coinor-ipopt (3.11.9-2.2) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru coinor-ipopt-3.11.9/debian/compat coinor-ipopt-3.11.9/debian/compat
--- coinor-ipopt-3.11.9/debian/compat	2014-10-01 15:42:17.0 +0300
+++ coinor-ipopt-3.11.9/debian/compat	2022-03-17 23:41:30.0 +0200
@@ -1 +1 @@
-5
+7

Bug#1007261: bullseye-pu: wolfssl/4.6.0-3_4.6.0+p1-1.debdiff updated

[Felix Lechner]

Hi,

On Thu, Mar 17, 2022 at 11:49 AM Adam D. Barratt
 wrote:
>
> In that case, it would be slightly more conventional to use "4.6.0+p1-
> 0+deb11u1"

Thank you for that advice! I will use 4.6.0+p1-0+deb11u1 instead.

> Well, you control the naming of the orig tarball, so you'd just make it
> match the package.

Without wishing to appear argumentative, I did not seem smart to have
two different tarballs in the archive under the same
wolfssl_4.6.0.orig.tar.gz name.

> Please feel free to upload.

Thanks for that too, and for your hard work on the stable releases!

Kind regards,
Felix Lechner

Bug#969673: g-wrap: please upgrade to guile-3.0 soon, if feasible

[Vagrant Cascadian]

Control: block 969698 by 969673

Hrm. I think I maybe had this backwards, guile-gnome-platform
build-depends on g-wrap... although it's kind of a tangled web, you can
upgrade one without upgrading without causing build failures...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1007773: uwsgi: FTBS with /usr/bin/ld: cannot find -lpcre2-8

[Adrian Bunk]

On Thu, Mar 17, 2022 at 10:25:06AM +0100, Alexandre Rossi wrote:
> Hi,
> 
> > /usr/bin/ld: cannot find -lpcre2-8: No such file or directory
> 
> I've pushed the necessary fix.
> https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/0955366dcf19b7ec9a0134eab1e81ec216d12a96

This change wasn't necessary (but is harmless).

The actual bug (#1007254) was fixed in apache2-dev.

> Thanks,
> 
> Alex

cu
Adrian

Bug#969673: g-wrap: please upgrade to guile-3.0 soon, if feasible

[Vagrant Cascadian]

Control: block 969673 by 969698


signature.asc
Description: PGP signature

Bug#1007717: Native source package format with non-native version

[Lucas Nussbaum]

Hi Ian,

On 15/03/22 at 16:29 +, Ian Jackson wrote:
> Part I - belss continued use of 1.0 native format, for now at least:
> 
>  1. Declare explicitly that there is nothing wrong with a package with
> a native format, but a non-native version number.
> 
>  2. Request that the dpkg maintainer relax the restriction which
> prevents the use of 3.0 native with Debian revision.
> 
>  3. Consequently, declare that the recent MBF on this topic ought not
> to have been filed against packages where simply changing the
> source format does not currently work.  That would include at
> least 1.0 native packages with Debian revisions.
> 
> Part II - bless continued use of 1.0-with-diff, for now at least:
> 
>  4. Declare that sometimes the use of 1.0-with-diff can be the best
> tradeoff between different considerations.  In particular,
> because 1.0 is the only format which botH:
>  (a) Optimises bandwidth and storage by reusing the upstream 
>  data when it hasn't changed.
>  (b) Avoids polluting the working tree (package source code)
>  with [patches], which cause trouble especially with
>git-based workflows.
> 
>  5. Consequently, declare that the recent MBF on this topic ought not
> to have been filed against 1.0 with diff packages, at least
> without some further filter.

I did the MBF mentioned in (5) (about suggesting the move from the 1.0
format to one of the 3.0 formats), and agreed to pause those efforts in
.

However, it might be worth clarifying if the MBF in (3) is mine, or
Guillem's one (with usertag dpkg-mismatch-source-vs-version-format and
user debian-d...@lists.debian.org) about "Mismatched source format vs
source version" (an example bug is #1007088). I think it's mine, but I'm
not sure. It might also be both.

Lucas

Bug#1007879: buster-pu: package libxml2/2.9.4+dfsg1-7+deb10u3

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: car...@debian.org,j...@debian.org

Hi Stable release managers,

libxml2 in buster (as in bullseye, cf #1007878) is affected by CVE-2022-23308,
which can result in denial of service, or potentially though the execution of
arbitrary code if a malformed xml file is processed. But given the near
timeline for the point release, I'm proposing to upload the fix via the
upcoming point release instead.

I verified the fix agains the POC from
https://gitlab.gnome.org/GNOME/libxml2/-/issues/327 .

Full debdiff is attached.

Regards,
Salvatore
diff -Nru libxml2-2.9.4+dfsg1/debian/changelog 
libxml2-2.9.4+dfsg1/debian/changelog
--- libxml2-2.9.4+dfsg1/debian/changelog2021-06-11 18:57:11.0 
+0200
+++ libxml2-2.9.4+dfsg1/debian/changelog2022-03-17 22:04:26.0 
+0100
@@ -1,3 +1,11 @@
+libxml2 (2.9.4+dfsg1-7+deb10u3) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Use-after-free of ID and IDREF attributes (CVE-2022-23308)
+(Closes: #1006489)
+
+ -- Salvatore Bonaccorso   Thu, 17 Mar 2022 22:04:26 +0100
+
 libxml2 (2.9.4+dfsg1-7+deb10u2) buster; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
libxml2-2.9.4+dfsg1/debian/patches/CVE-2022-23308-Use-after-free-of-ID-and-IDREF-attrib.patch
 
libxml2-2.9.4+dfsg1/debian/patches/CVE-2022-23308-Use-after-free-of-ID-and-IDREF-attrib.patch
--- 
libxml2-2.9.4+dfsg1/debian/patches/CVE-2022-23308-Use-after-free-of-ID-and-IDREF-attrib.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libxml2-2.9.4+dfsg1/debian/patches/CVE-2022-23308-Use-after-free-of-ID-and-IDREF-attrib.patch
   2022-03-17 22:04:26.0 +0100
@@ -0,0 +1,195 @@
+From: Nick Wellnhofer 
+Date: Tue, 8 Feb 2022 03:29:24 +0100
+Subject: [CVE-2022-23308] Use-after-free of ID and IDREF attributes
+Origin: 
https://gitlab.gnome.org/GNOME/libxml2/-/commit/652dd12a858989b14eed4e84e453059cd3ba340e
+Bug-Debian: https://bugs.debian.org/1006489
+Bug: https://gitlab.gnome.org/GNOME/libxml2/-/issues/327
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-23308
+
+If a document is parsed with XML_PARSE_DTDVALID and without
+XML_PARSE_NOENT, the value of ID attributes has to be normalized after
+potentially expanding entities in xmlRemoveID. Otherwise, later calls
+to xmlGetID can return a pointer to previously freed memory.
+
+ID attributes which are empty or contain only whitespace after
+entity expansion are affected in a similar way. This is fixed by
+not storing such attributes in the ID table.
+
+The test to detect streaming mode when validating against a DTD was
+broken. In connection with the defects above, this could result in a
+use-after-free when using the xmlReader interface with validation.
+Fix detection of streaming mode to avoid similar issues. (This changes
+the expected result of a test case. But as far as I can tell, using the
+XML reader with XIncludes referencing the root document never worked
+properly, anyway.)
+
+All of these issues can result in denial of service. Using xmlReader
+with validation could result in disclosure of memory via the error
+channel, typically stderr. The security impact of xmlGetID returning
+a pointer to freed memory depends on the application. The typical use
+case of calling xmlGetID on an unmodified document is not affected.
+---
+ result/XInclude/ns1.xml.rdr |  2 +-
+ valid.c | 88 +++--
+ 2 files changed, 56 insertions(+), 34 deletions(-)
+
+--- a/valid.c
 b/valid.c
+@@ -479,6 +479,35 @@ nodeVPop(xmlValidCtxtPtr ctxt)
+ return (ret);
+ }
+ 
++/**
++ * xmlValidNormalizeString:
++ * @str: a string
++ *
++ * Normalize a string in-place.
++ */
++static void
++xmlValidNormalizeString(xmlChar *str) {
++xmlChar *dst;
++const xmlChar *src;
++
++if (str == NULL)
++return;
++src = str;
++dst = str;
++
++while (*src == 0x20) src++;
++while (*src != 0) {
++  if (*src == 0x20) {
++  while (*src == 0x20) src++;
++  if (*src != 0)
++  *dst++ = 0x20;
++  } else {
++  *dst++ = *src++;
++  }
++}
++*dst = 0;
++}
++
+ #ifdef DEBUG_VALID_ALGO
+ static void
+ xmlValidPrintNode(xmlNodePtr cur) {
+@@ -2546,6 +2575,24 @@ xmlDumpNotationTable(xmlBufferPtr buf, x
+   (xmlDictOwns(dict, (const xmlChar *)(str)) == 0)))  \
+   xmlFree((char *)(str));
+ 
++static int
++xmlIsStreaming(xmlValidCtxtPtr ctxt) {
++xmlParserCtxtPtr pctxt;
++
++if (ctxt == NULL)
++return(0);
++/*
++ * These magic values are also abused to detect whether we're validating
++ * while parsing a document. In this case, userData points to the parser
++ * context.
++ */
++if ((ctxt->finishDtd != XML_CTXT_FINISH_DTD_0) &&
++(ctxt->finishDtd != XML_CTXT_FINISH_DTD_1))
++return(0);
++pctxt = ctxt->userData;
++  

Bug#1007878: bullseye-pu: package libxml2/2.9.10+dfsg-6.7+deb11u1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: car...@debian.org,j...@debian.org

Hi Stable release managers,

libxml2 in bullseye is affected by CVE-2022-23308, which can result in
denial of service, or potentially though the execution of arbitrary
code if a malformed xml file is processed. But given the near timeline
for the point release, I think we could additionally benefit from
autopkgtest runs. So I'm proposing to upload the fix via the upcoming
point release.

I verified the fix agains the POC from
https://gitlab.gnome.org/GNOME/libxml2/-/issues/327 .

Full debdiff is attached.

Regards,
Salvatore
diff -Nru libxml2-2.9.10+dfsg/debian/changelog 
libxml2-2.9.10+dfsg/debian/changelog
--- libxml2-2.9.10+dfsg/debian/changelog2021-05-22 08:21:29.0 
+0200
+++ libxml2-2.9.10+dfsg/debian/changelog2022-03-17 21:52:53.0 
+0100
@@ -1,3 +1,11 @@
+libxml2 (2.9.10+dfsg-6.7+deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Use-after-free of ID and IDREF attributes (CVE-2022-23308)
+(Closes: #1006489)
+
+ -- Salvatore Bonaccorso   Thu, 17 Mar 2022 21:52:53 +0100
+
 libxml2 (2.9.10+dfsg-6.7) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
libxml2-2.9.10+dfsg/debian/patches/CVE-2022-23308-Use-after-free-of-ID-and-IDREF-attrib.patch
 
libxml2-2.9.10+dfsg/debian/patches/CVE-2022-23308-Use-after-free-of-ID-and-IDREF-attrib.patch
--- 
libxml2-2.9.10+dfsg/debian/patches/CVE-2022-23308-Use-after-free-of-ID-and-IDREF-attrib.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libxml2-2.9.10+dfsg/debian/patches/CVE-2022-23308-Use-after-free-of-ID-and-IDREF-attrib.patch
   2022-03-17 21:52:53.0 +0100
@@ -0,0 +1,195 @@
+From: Nick Wellnhofer 
+Date: Tue, 8 Feb 2022 03:29:24 +0100
+Subject: [CVE-2022-23308] Use-after-free of ID and IDREF attributes
+Origin: 
https://gitlab.gnome.org/GNOME/libxml2/-/commit/652dd12a858989b14eed4e84e453059cd3ba340e
+Bug-Debian: https://bugs.debian.org/1006489
+Bug: https://gitlab.gnome.org/GNOME/libxml2/-/issues/327
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-23308
+
+If a document is parsed with XML_PARSE_DTDVALID and without
+XML_PARSE_NOENT, the value of ID attributes has to be normalized after
+potentially expanding entities in xmlRemoveID. Otherwise, later calls
+to xmlGetID can return a pointer to previously freed memory.
+
+ID attributes which are empty or contain only whitespace after
+entity expansion are affected in a similar way. This is fixed by
+not storing such attributes in the ID table.
+
+The test to detect streaming mode when validating against a DTD was
+broken. In connection with the defects above, this could result in a
+use-after-free when using the xmlReader interface with validation.
+Fix detection of streaming mode to avoid similar issues. (This changes
+the expected result of a test case. But as far as I can tell, using the
+XML reader with XIncludes referencing the root document never worked
+properly, anyway.)
+
+All of these issues can result in denial of service. Using xmlReader
+with validation could result in disclosure of memory via the error
+channel, typically stderr. The security impact of xmlGetID returning
+a pointer to freed memory depends on the application. The typical use
+case of calling xmlGetID on an unmodified document is not affected.
+---
+ result/XInclude/ns1.xml.rdr |  2 +-
+ valid.c | 88 +++--
+ 2 files changed, 56 insertions(+), 34 deletions(-)
+
+--- a/valid.c
 b/valid.c
+@@ -479,6 +479,35 @@ nodeVPop(xmlValidCtxtPtr ctxt)
+ return (ret);
+ }
+ 
++/**
++ * xmlValidNormalizeString:
++ * @str: a string
++ *
++ * Normalize a string in-place.
++ */
++static void
++xmlValidNormalizeString(xmlChar *str) {
++xmlChar *dst;
++const xmlChar *src;
++
++if (str == NULL)
++return;
++src = str;
++dst = str;
++
++while (*src == 0x20) src++;
++while (*src != 0) {
++  if (*src == 0x20) {
++  while (*src == 0x20) src++;
++  if (*src != 0)
++  *dst++ = 0x20;
++  } else {
++  *dst++ = *src++;
++  }
++}
++*dst = 0;
++}
++
+ #ifdef DEBUG_VALID_ALGO
+ static void
+ xmlValidPrintNode(xmlNodePtr cur) {
+@@ -2607,6 +2636,24 @@ xmlDumpNotationTable(xmlBufferPtr buf, x
+   (xmlDictOwns(dict, (const xmlChar *)(str)) == 0)))  \
+   xmlFree((char *)(str));
+ 
++static int
++xmlIsStreaming(xmlValidCtxtPtr ctxt) {
++xmlParserCtxtPtr pctxt;
++
++if (ctxt == NULL)
++return(0);
++/*
++ * These magic values are also abused to detect whether we're validating
++ * while parsing a document. In this case, userData points to the parser
++ * context.
++ */
++if ((ctxt->finishDtd != XML_CTXT_FINISH_DTD_0) &&
++(ctxt->finishDtd != XML_CTXT_FINISH_DTD_1))
++return(0);
++  

Bug#969673: g-wrap: please upgrade to guile-3.0 soon, if feasible

[Vagrant Cascadian]

Control: block 9696673 by 969698

On 2022-03-16, Vagrant Cascadian wrote:
> On 2020-09-14, Göran Weinholt wrote:
>> Tommi Höynälänmaa  writes:
>>> su, 2020-09-06 kello 15:21 -0500, Rob Browning kirjoitti:
 Please migrate to guile-3.0 as soon as it's feasible. If we can, I'd
 like to have the option to drop guile-2.2 from bullseye, so that we
 won't have to maintain two versions throughout that release.
>
> Upstream g-wrap is unlikely to ever make another release; there has been
> no real development since 2015, with two minor commits as recently as
> 2018:
>
>   https://git.savannah.nongnu.org/cgit/g-wrap.git/log/
>
>
> I talked to daviid on irc about it (possibly the David Pirotte from
> "recent" git commits?), and they suggested to migrate away from g-wrap,
> as it will not be updated to use guile 3.0.

And even if someone managed to patch g-wrap to support guile 3.0, fixing
this bug is blocked by also updating guile-gnome-platform, which is just
as unlikely to be updated to guile 3.0.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#969673: Bug#969703: Mitigated in 0.2.6.1-2

[Vagrant Cascadian]

Control: block 969703 by 969673

On 2020-11-30, Göran Weinholt wrote:
> I've uploaded guile-lib 0.2.6.1-2, which should work with both Guile 2.2
> and Guile 3.0. It depends on guile-3.0 | guile-2.2. I think you can
> cross off guile-lib from your list, but perhaps we can keep the bug open
> since I actually need to remove the guile-2.2 support at some point.

The full resolution to this bug is blocked by updating g-wrap.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1007875: [Pkg-javascript-devel] Bug#1007875: node-use: FTBFS with nodejs experimental/14.19.0

[Yadd]

Hi,

This one isn't related to nodejs 14 but due to pkg-js-tools 0.11 change: 
autobuild failures are no more ignored.

Just to check if files should be rebuilt else add an empty 
override_dh_auto_build.


Le 17 mars 2022 21:37:46 GMT+01:00, "Jérémy Lal"  a écrit :
>Source: node-use
>Version: 3.1.1-2
>Severity: important
>Tags: ftbfs
>
>This package fails to rebuild. Build log is attached.
>
>
>-- System Information:
>Debian Release: bookworm/sid
>  APT prefers stable-security
>  APT policy: (500, 'stable-security'), (500, 'unstable'), (101, 'testing')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
>Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
>Shell: /bin/sh linked to /usr/bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#966068: RFA: emacs-helm-ag -- Silver Searcher integration with Emacs Helm

[Sean Whitton]

control: retitle -1 O: emacs-helm-ag

Hello,

On Wed 22 Jul 2020 at 07:34AM -07, Sean Whitton wrote:

> I request an adoptor for the emacs-helm-ag package.  I haven't been
> using it myself for a while.
>
> This is a team-maintained package, so the adoptor should either replace
> me in Uploaders:, or alternatively take the package out of the team's
> hands.

I hereby orphan emacs-helm-ag.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#952808: RFA: clojure-mode

[Sean Whitton]

control: retitle -1 O: clojure-mode

Hello,

On Sat 29 Feb 2020 at 08:30AM -07, Sean Whitton wrote:

> Package: wnpp
> Severity: normal
>
> I request an adoptor for the clojure-mode package.
>
> This is a team-maintained package, so the adoptor should either replace
> me in Uploaders:, or alternatively take the package out of the team's
> hands.

I hereby orphan clojure-mode.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007877: RM: hothasktags -- ROM; unbuildable for more than a year

[Sean Whitton]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-hask...@lists.debian.org

Please drop hothasktags from sid.  It has been unbuildable for more than
a year and no-one seems sufficiently interested in the package.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007876: node-xxhashjs: FTBFS with nodejs experimental/14.19.0

[Jérémy Lal]

Source: node-xxhashjs
Version: 0.2.2+dfsg-5
Severity: important
Tags: ftbfs

This package fails to rebuild. Build log is attached.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Running with gitlab-runner 14.8.2 (c6e7e194)
  on kapouer mWTn5Dhn
section_start:1647549218:prepare_executor
Preparing the "custom" executor
Using Custom executor...
2022-03-17 21:33:38,672 INFO Starting machine using image unstable
2022-03-17 21:33:38,673 INFO Running systemd-run --setenv=SYSTEMD_SECCOMP=0 
--property=KillMode=mixed --property=Type=notify 
--property=RestartForceExitStatus=133 --property=SuccessExitStatus=133 
--property=Slice=machine.slice --property=Delegate=yes 
--property=TasksMax=16384 --property=WatchdogSec=3min systemd-nspawn --quiet 
--volatile=overlay --directory=/var/lib/nspawn-runner/unstable 
--machine=run-2578204 --boot --notify-ready=yes
Running as unit: run-r8874a5fd26644f68920a29ed0925a2e8.service
section_end:1647549218:prepare_executor
section_start:1647549218:prepare_script
Preparing environment
Running on corossol...
section_end:1647549219:prepare_script
section_start:1647549219:get_sources
Getting source from Git repository
Fetching changes with git depth set to 1...
Initialized empty Git repository in 
/var/lib/nspawn-runner/.build/js-team/nodejs/.git/
Created fresh repository.
Checking out a27fc43c as master-14.x...

Skipping Git submodules setup
section_end:1647549233:get_sources
section_start:1647549233:restore_cache
Restoring cache
Checking cache for node-xxhashjs-build-1...
time="2022-03-17T21:33:54+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=156 revision=13.3.1 version=13.3.1
No URL provided, cache will not be downloaded from shared cache server. Instead 
a local version of cache will be extracted. 
Successfully extracted cache
section_end:1647549234:restore_cache
section_start:1647549234:download_artifacts
Downloading artifacts
Downloading artifacts for build (2576682)...
time="2022-03-17T21:33:54+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=184 revision=13.3.1 version=13.3.1
Downloading artifacts from coordinator... ok    id=2576682 
responseStatus=200 OK token=7T5PxLhx
section_end:1647549238:download_artifacts
section_start:1647549238:step_script
Executing "step_script" stage of the job script
WARNING: Starting with version 14.0 the 'build_script' stage will be 
replaced with 'step_script': 
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26426
$ # Reported in 
https://salsa.debian.org/salsa-ci-team/pipeline/issues/104, # collapsed 
multi-line command
+ [[ -n '' ]]
$ export CCACHE_DIR=${CCACHE_TMP_DIR} # collapsed multi-line command
Get:1 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:2 http://deb.debian.org/debian unstable/main Sources [9639 kB]
Get:3 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:4 http://deb.debian.org/debian unstable/main Translation-en [6762 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-17-1402.17-F-2022-03-16-1412.00.pdiff [76.2 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-17-1402.17-F-2022-03-16-1412.00.pdiff [76.2 kB]
Fetched 16.7 MB in 3s (5682 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  aptitude-common autoconf automake autopoint autotools-dev binutils
  binutils-common binutils-x86-64-linux-gnu bsdextrautils bzip2 cpp cpp-11
  debhelper dh-autoreconf dh-strip-nondeterminism dirmngr dpkg-dev dwz
  fakeroot file g++ g++-11 gcc gcc-11 gcc-11-base gettext gettext-base gnupg
  gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf
  gpgsm groff-base intltool-debian libarchive-zip-perl libasan6 libassuan0
  libatomic1 libb-hooks-op-check-perl libbinutils libboost-iostreams1.74.0
  libc-dev-bin libc6-dev libcc1-0 libclass-method-modifiers-perl
  

Bug#1007875: node-use: FTBFS with nodejs experimental/14.19.0

[Jérémy Lal]

Source: node-use
Version: 3.1.1-2
Severity: important
Tags: ftbfs

This package fails to rebuild. Build log is attached.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Running with gitlab-runner 14.8.2 (c6e7e194)
  on kapouer mWTn5Dhn
section_start:1647545775:prepare_executor
Preparing the "custom" executor
Using Custom executor...
2022-03-17 20:36:16,110 INFO Starting machine using image unstable
2022-03-17 20:36:16,111 INFO Running systemd-run --setenv=SYSTEMD_SECCOMP=0 
--property=KillMode=mixed --property=Type=notify 
--property=RestartForceExitStatus=133 --property=SuccessExitStatus=133 
--property=Slice=machine.slice --property=Delegate=yes 
--property=TasksMax=16384 --property=WatchdogSec=3min systemd-nspawn --quiet 
--volatile=overlay --directory=/var/lib/nspawn-runner/unstable 
--machine=run-2578143 --boot --notify-ready=yes
Running as unit: run-re25ed0fac2a9457e9596977f661b3ffd.service
section_end:1647545776:prepare_executor
section_start:1647545776:prepare_script
Preparing environment
Running on corossol...
section_end:1647545776:prepare_script
section_start:1647545776:get_sources
Getting source from Git repository
Fetching changes with git depth set to 1...
Initialized empty Git repository in 
/var/lib/nspawn-runner/.build/js-team/nodejs/.git/
Created fresh repository.
Checking out a27fc43c as master-14.x...

Skipping Git submodules setup
section_end:1647545791:get_sources
section_start:1647545791:restore_cache
Restoring cache
Checking cache for node-use-build-1...
time="2022-03-17T20:36:31+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=156 revision=13.3.1 version=13.3.1
No URL provided, cache will not be downloaded from shared cache server. Instead 
a local version of cache will be extracted. 
Successfully extracted cache
section_end:1647545791:restore_cache
section_start:1647545791:download_artifacts
Downloading artifacts
Downloading artifacts for build (2576682)...
time="2022-03-17T20:36:31+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=183 revision=13.3.1 version=13.3.1
Downloading artifacts from coordinator... ok    id=2576682 
responseStatus=200 OK token=7T5PxLhx
section_end:1647545795:download_artifacts
section_start:1647545795:step_script
Executing "step_script" stage of the job script
WARNING: Starting with version 14.0 the 'build_script' stage will be 
replaced with 'step_script': 
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26426
$ # Reported in 
https://salsa.debian.org/salsa-ci-team/pipeline/issues/104, # collapsed 
multi-line command
+ [[ -n '' ]]
$ export CCACHE_DIR=${CCACHE_TMP_DIR} # collapsed multi-line command
Get:1 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:2 http://deb.debian.org/debian unstable/main Sources [9639 kB]
Get:3 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:4 http://deb.debian.org/debian unstable/main Translation-en [6762 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-17-1402.17-F-2022-03-16-1412.00.pdiff [76.2 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-17-1402.17-F-2022-03-16-1412.00.pdiff [76.2 kB]
Fetched 16.7 MB in 3s (6001 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  aptitude-common autoconf automake autopoint autotools-dev binutils
  binutils-common binutils-x86-64-linux-gnu bsdextrautils bzip2 cpp cpp-11
  debhelper dh-autoreconf dh-strip-nondeterminism dirmngr dpkg-dev dwz
  fakeroot file g++ g++-11 gcc gcc-11 gcc-11-base gettext gettext-base gnupg
  gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf
  gpgsm groff-base intltool-debian libarchive-zip-perl libasan6 libassuan0
  libatomic1 libb-hooks-op-check-perl libbinutils libboost-iostreams1.74.0
  libc-dev-bin libc6-dev libcc1-0 libclass-method-modifiers-perl
  libclass-xsaccessor-perl 

Bug#1003031: RFA: projectile

[Sean Whitton]

control: retitle -1 O: projectile

Hello,

On Sun 02 Jan 2022 at 04:12PM -07, Sean Whitton wrote:

> I request an adoptor for the projectile package.  I haven't used it for
> some time, as I'm now using the built-in package.el for everything for
> which I used to use projectile.
>
> This is a team-maintained package, so the adoptor should either replace
> me in Uploaders:, or alternatively take the package out of the team's
> hands.
>
> The package is maintained using git-debrebase, using the workflow
> described in dgit-maint-debrebase(7).  That's been working well, so I'd
> encourage any adopter to continue using the tool.

I hereby orphan projectile.  There's nothing wrong with it; there is no
need for an RM or anything.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007874: O: helm-org

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:helm-org

I intend to orphan the helm-org package.

This package is no longer loaded by my init.el and it would be better if
someone who actually uses the package maintains it.  There is nothing
wrong with it; no need for an RM or anything.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007873: O: popup-el -- visual popup user interface library for Emacs

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:popup-el

I intend to orphan the popup-el package.

This package is no longer loaded by my init.el and it would be better if
someone who actually uses the package maintains it.  There is nothing
wrong with it; no need for an RM or anything.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

The package description is:
 popup.el is a visual popup user interface library for Emacs. It
 provides common UI widgets such as popup tooltips and popup menus.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#904242: RFA: debpaste-el

[Sean Whitton]

control: retitle -1 O: debpaste-el

Hello,

On Sun 22 Jul 2018 at 01:46PM +08, Sean Whitton wrote:

> I request an adoptor for the debpaste-el package.
>
> This package is no longer in my ~/.emacs.d/init.el and it would be
> better if someone who actually uses the package maintains it.
>
> This is a team-maintained package, so the adoptor should either replace
> me in Uploaders:, or alternatively take the package out of the team's
> hands.

I hereby orphan debpaste-el.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#904238: RFA: cycle-quotes

[Sean Whitton]

control: retitle -1 O: cycle-quotes

Hello,

On Sun 22 Jul 2018 at 01:42PM +08, Sean Whitton wrote:

> I request an adoptor for the cycle-quotes package.
>
> This package is no longer in my ~/.emacs.d/init.el and it would be
> better if someone who actually uses the package maintains it.
>
> This is a team-maintained package, so the adoptor should either replace
> me in Uploaders:, or alternatively take the package out of the team's
> hands.

I hereby orphan cycle-quotes.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007835: [Pkg-samba-maint] Bug#1007835: samba: Full audit logs all activity instead of selected only -- error after upgrade from buster to bullseye

[Andrew Bartlett]

The names of the functions changed.  Ideally we would have had an alias
when we added to "at" to the end, but nobody added that.  Patches
upstream at:

https://wiki.samba.org/index.php/Contribute

will be accepted, with tests.

This should be correct in the docs now, at least for current versions
(I've not checked 4.13). 

Andrew Bartlett

On Thu, 2022-03-17 at 16:45 +0100, Leszek Dubiel wrote:
> Package: samba
> Version: 2:4.13.13+dfsg-1~deb11u3
> Severity: normal
> 
> After upgrade from buster to bullseye samba full audit started to log
> ALL activity
> despite opitons in /etc/samba/smb.conf stayed the same.
> 
> There are two options in /etc/samba/smb.conf
> 
>   vfs objects = full_audit
>   full_audit:success = mkdir rmdir open rename unlink
> 
> Then I rename file from "old" to "new" and logs show:
> 
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|renameat|ok|/home/leszek/Prywatny/aa/old|/home/l
> eszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|close|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|stat|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|getxattr|ok|/home/leszek/Prywatny/aa/new|user.DO
> SATTRIB
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|get_dos_attributes|ok|/home/leszek/Prywatny/aa/n
> ew
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|file_id_create|ok|26:54616484:0
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|stat|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|sys_acl_get_file|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|sys_acl_get_file|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|get_nt_acl_at|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|stat|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|sys_acl_get_file|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|sys_acl_get_file|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|get_nt_acl_at|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|file_id_create|ok|26:54616484:0
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|stat|ok|/home/leszek/Prywatny
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|file_id_create|ok|26:64129:0
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|stat|ok|/home/leszek/Prywatny
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|chdir|ok|chdir|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|stat|ok|/home/leszek/Prywatny
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|file_id_create|ok|26:54616484:0
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|getwd|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|file_id_create|ok|26:54616484:0
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|realpath|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|connectpath|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|openat|ok|r|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|chdir|ok|chdir|/home/leszek/Prywatny
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|stat|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|file_id_create|ok|26:64129:0
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|stat|ok|/home/leszek/Prywatny
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|fstat|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|create_file|ok|0x80|file|open|/home/leszek/Prywa
> tny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|getxattr|ok|/home/leszek/Prywatny/aa/new|user.DO
> SATTRIB
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|get_dos_attributes|ok|/home/leszek/Prywatny/aa/n
> ew
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|get_alloc_size|ok|0
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|fstat|ok|/home/leszek/Prywatny/aa/new
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|file_id_create|ok|26:54616484:0
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|getxattr|ok|/home/leszek/Prywatny/aa/new|user.DO
> SATTRIB
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|get_dos_attributes|ok|/home/leszek/Prywatny/aa/n
> ew
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|get_alloc_size|ok|0
> Mar 17 16:40:27 wawel smbd_audit:
> leszek|192.168.18.35|fs_file_id|ok|10992394656229373408
> Mar 17 16:40:27 wawel smbd_audit:
> 

Bug#1007872: libc6-dev: getaddrinfo() finds an AF_INET address when hinting AF_UNSPEC, but not when hinting AF_INET

[Robert Martin]

Package: libc6-dev
Version: 2.33-7
Severity: normal

Dear Maintainer,

Under certain circumstances, when calling getaddrinfo with hints.ai_family = 
AF_UNSPEC, the first result is an AF_INET address. When calling it with 
hints.ai_family = AF_INET, however, it returns 251 (No address associated with 
hostname).

Here is a short program that reproduces the issue:
```c
#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[]) {
const char hostname[] = "SomeHostname";
const char service[] = "1433";

struct addrinfo hints, *res;
memset(, 0, sizeof(hints));

int ret = getaddrinfo(hostname, service, , );
assert(ret == 0);
assert(res->ai_family == AF_INET);
freeaddrinfo(res);

hints.ai_family = AF_INET;
ret = getaddrinfo(hostname, service, , );

if (ret != 0) {
printf(gai_strerror(ret));
printf("\n");
} else {
freeaddrinfo(res);
}
return ret;
}
```

I have only been able to reproduce the bug when all of the following criteria 
are met:
- Running in a Docker container on a Windows host
- The hostname is unqualified
- The container's /etc/resolv.conf does not include the correct search option 
to resolve the hostname
- The Windows host is set up to resolve unqualified names by applying the 
correct DNS suffix

getaddrinfo() also returns 251 if the AI_ADDRCONFIG flag is set, even though 
the container has an IPV4 address.

The bug is also present in 2.34-0experimental3.

Symptoms are superficially similar to #854301, but the container is online and 
passing AI_ADDRCONFIG returns no result.

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

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

Versions of packages libc6-dev depends on:
ii  libc-dev-bin2.33-7
ii  libc6   2.33-7
ii  libcrypt-dev1:4.4.27-1.1
ii  libnsl-dev  1.3.0-2
ii  linux-libc-dev  5.16.12-1
ii  rpcsvc-proto1.4.2-4

libc6-dev recommends no packages.

Versions of packages libc6-dev suggests:
pn  glibc-doc 
ii  manpages-dev  5.10-1

-- no debconf information

Bug#1006626: biber: Lots of "Use of uninitialized value" warnings after biber update

[Hilmar Preuße]

Am 17.03.2022 um 08:50 teilte Hilmar Preuße mit:

Am 28.02.2022 um 21:41 teilte Ralf Jung mit:


Hi Ralf,


I reported this upstream at https://github.com/plk/biber/issues/403,
but the maintainer suggested this might be a packaging issues since
they could not reproduce the problem.

I've copied (partially) two commits from upstream dev branch, which 
solve your specific issue. In [1] we have a statement that the test 
suite still generates warnings, so I hope for another patch.


I've pulled (partially) the patches, which solve your issue from 
upstream. These parts do not solve the remaining issues completely, but 
reduce the number of warnings significantly. They will be completely 
gone in one of the next biber versions. A preliminary Debian package is 
here [1].


I'll close your bug in the next upload, I'll wait until 
libencode-eucjpascii-perl has entered Debian to get rid of another build 
warning.


Hilmar

[1] https://freeshell.de/~hille42/biber/
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007717: Native source package format with non-native version

[Felix Lechner]

Hi,

On Thu, Mar 17, 2022 at 11:57 AM Russ Allbery  wrote:
>
> source package format

While everyone is receptive to new labels, I prefer "upload format" or
"archive format". Either one helps us to distinguish the intermediate
product from any workflow objects a maintainer may have.

> single tarball as a source package format

It is also not necessary to "define" unpatched sources in the archive
by how many tarballs they have, or any tarballs at all.

In fact, I wrote a manifest utility that could one day replace tarball
signatures with per-file hashes. The latter remain useful even when
sources are repackaged, because manifests can be cryptographically
daisy-chained in a "chain of custody." Of course, they would be more
often used for patched upload formats.

Kind regards
Felix Lechner

Bug#997231: nfstrace: FTBFS: header_window.cpp:77:82: error: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘time_t’ {aka ‘long int’} [-Werror=format=]

[Gianfranco Costamagna]

control: tags -1 patch pending

The attached debdiff from Ubuntu is going in.

G.diff -Nru nfstrace-0.4.3.2+git20200805+b220d04/debian/changelog 
nfstrace-0.4.3.2+git20200805+b220d04/debian/changelog
--- nfstrace-0.4.3.2+git20200805+b220d04/debian/changelog   2021-08-26 
06:08:31.0 -0400
+++ nfstrace-0.4.3.2+git20200805+b220d04/debian/changelog   2022-03-17 
13:21:02.0 -0400
@@ -1,3 +1,11 @@
+nfstrace (0.4.3.2+git20200805+b220d04-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * debian/patches/0001-analyzers-fix-a-couple-format-errors.patch: Fix
+-Werror=format build errors (LP: #1965155, Closes: #997231).
+
+ -- Nick Rosbrook   Thu, 17 Mar 2022 13:21:02 
-0400
+
 nfstrace (0.4.3.2+git20200805+b220d04-2) unstable; urgency=medium
 
   [ Aurelien Jarno ]
diff -Nru 
nfstrace-0.4.3.2+git20200805+b220d04/debian/patches/0001-analyzers-fix-a-couple-format-errors.patch
 
nfstrace-0.4.3.2+git20200805+b220d04/debian/patches/0001-analyzers-fix-a-couple-format-errors.patch
--- 
nfstrace-0.4.3.2+git20200805+b220d04/debian/patches/0001-analyzers-fix-a-couple-format-errors.patch
 1969-12-31 19:00:00.0 -0500
+++ 
nfstrace-0.4.3.2+git20200805+b220d04/debian/patches/0001-analyzers-fix-a-couple-format-errors.patch
 2022-03-16 12:08:15.0 -0400
@@ -0,0 +1,45 @@
+Description: Fix -Werror=format build errors
+Author: Nick Rosbrook 
+Forwarded: https://github.com/epam/nfstrace/pull/51
+Last-Update: 2022-03-16
+---
+From af1472cfd88a724e7208e0c2534a47d7f40ff2ab Mon Sep 17 00:00:00 2001
+From: Nick Rosbrook 
+Date: Wed, 16 Mar 2022 11:31:00 -0400
+Subject: [PATCH] analyzers: fix a couple format errors
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+A couple mvwprintw() calls result in build errors like:
+
+error: format ‘%d’ expects argument of type ‘int’, but argument 5 has type 
‘time_t’ {aka ‘long int’} [-Werror=format=]
+
+Update these calls to use the correct format specifiers.
+---
+ analyzers/src/watch/nc_windows/header_window.cpp | 2 +-
+ analyzers/src/watch/nc_windows/statistics_window.cpp | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/analyzers/src/watch/nc_windows/header_window.cpp
 b/analyzers/src/watch/nc_windows/header_window.cpp
+@@ -74,7 +74,7 @@
+ time_t shift_time  = actual_time - _start_time;
+ /* tm starts with 0 month and 1900 year*/
+ mvwprintw(_window, HEADER::DATE_LINE, FIRST_CHAR_POS, "Date: \t %d.%d.%d 
\t Time: %d:%d:%d  ", t->tm_mday, t->tm_mon + 1, t->tm_year + 1900, t->tm_hour, 
t->tm_min, t->tm_sec);
+-mvwprintw(_window, HEADER::ELAPSED_LINE, FIRST_CHAR_POS, "Elapsed time:  
\t %d days; %d:%d:%d times",
++mvwprintw(_window, HEADER::ELAPSED_LINE, FIRST_CHAR_POS, "Elapsed time:  
\t %ld days; %ld:%ld:%ld times",
+   shift_time / SECINDAY, shift_time % SECINDAY / SECINHOUR, 
shift_time % SECINHOUR / SECINMIN, shift_time % SECINMIN);
+ wrefresh(_window);
+ }
+--- a/analyzers/src/watch/nc_windows/statistics_window.cpp
 b/analyzers/src/watch/nc_windows/statistics_window.cpp
+@@ -153,7 +153,7 @@
+ }
+ if(canWrite(line))
+ {
+-mvwprintw(_window, line - (_scrollOffset.at(_activeProtocol)), 
FIRST_CHAR_POS + 25, "%d", m);
++mvwprintw(_window, line - (_scrollOffset.at(_activeProtocol)), 
FIRST_CHAR_POS + 25, "%ld", m);
+ }
+ line++;
+ for(unsigned int j = _activeProtocol->getGroupBegin(i); j < 
_activeProtocol->getGroupBegin(i + 1); j++)
diff -Nru nfstrace-0.4.3.2+git20200805+b220d04/debian/patches/series 
nfstrace-0.4.3.2+git20200805+b220d04/debian/patches/series
--- nfstrace-0.4.3.2+git20200805+b220d04/debian/patches/series  2021-08-26 
06:08:31.0 -0400
+++ nfstrace-0.4.3.2+git20200805+b220d04/debian/patches/series  2022-03-16 
11:59:13.0 -0400
@@ -1 +1,2 @@
+0001-analyzers-fix-a-couple-format-errors.patch
 tirpc.patch

Bug#1006052: haskell-*: FTBFS: * Lexical error! The character '#' does not fit here.

[Gianfranco Costamagna]

control: close -1
control: archive -1

Hello, all these bugs are fixed by gtk2hs-buildtools/0.13.8.0-2

Gianfranco

Bug#904239: RFA: deft

[Sean Whitton]

control: retitle -1 O: deft

Hello,

On Sun 22 Jul 2018 at 01:43PM +08, Sean Whitton wrote:

> Package: wnpp
> Severity: normal
>
> I request an adoptor for the deft package.
>
> This package is no longer in my ~/.emacs.d/init.el and it would be
> better if someone who actually uses the package maintains it.
>
> This is a team-maintained package, so the adoptor should either replace
> me in Uploaders:, or alternatively take the package out of the team's
> hands.

I hereby orphan deft.

There's nothing wrong with it; no need for an RM or anything.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#904241: RFA: xml-rpc-el

[Sean Whitton]

control: retitle -1 O: xml-rpc-el

Hello,

On Sun 22 Jul 2018 at 01:45PM +08, Sean Whitton wrote:

> Package: wnpp
> Severity: normal
>
> I request an adoptor for the xml-rpc-el package.
>
> This is a reverse-dependency for another package for which I am
> requesting an adopter, debpaste-el.
>
> This is a team-maintained package, so the adoptor should either replace
> me in Uploaders:, or alternatively take the package out of the team's
> hands.

I hereby orphan xml-rpc-el.

There is nothing wrong with it; no need for an RM or anything.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#904232: RFA: pointback

[Sean Whitton]

control: retitle -1 O: pointback

Hello,

On Sun 22 Jul 2018 at 01:30PM +08, Sean Whitton wrote:

> Package: wnpp
> Severity: normal
>
> I request an adoptor for the pointback package.
>
> This package is no longer in my ~/.emacs.d/init.el and it would be
> better if someone who actually uses the package maintains it.
>
> This is a team-maintained package, so the adoptor should either replace
> me in Uploaders:, or alternatively take the package out of the team's
> hands.

I hereby orphan pointback.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007870: O: sesman

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:sesman

I intend to orphan the sesman package.

This package is no longer loaded by my init.el and it would be better if
someone who actually uses the package maintains it.  There is nothing
wrong with it; no need for an RM or anything.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007869: O: rainbow-delimiters -- Emacs mode to colour-code delimiters according to their depth

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:rainbow-delimiters

I intend to orphan the rainbow-delimiters package.

This package is no longer loaded by my init.el and it would be better if
someone who actually uses the package maintains it.  There is nothing
wrong with it; no need for an RM or anything.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

The package description is:
 rainbow-delimiters is a "rainbow parentheses"-like mode which
 highlights delimiters such as parentheses, brackets or braces
 according to their depth. Each successive level is highlighted in a
 different color. This makes it easy to spot matching delimiters,
 orient yourself in the code, and tell which statements are at a given
 depth.
 .
 Great care has been taken to make this mode fast. You shouldn't see
 any change in scrolling or editing speed when it's on even when
 working in delimiter-rich languages like Clojure or Emacs Lisp. It
 can be used with any language.
 .
 You can customize the colors rainbow-delimiters uses. The default
 colors are intentionally subtle; they are unobtrusive enough to make
 the mode worth looking at even if you usually don't like rainbow
 parentheses modes. A number of major color themes such as Zenburn and
 Solarized have added their own faces for the mode.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007868: O: queue-el

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:queue-el

I intend to orphan the queue-el package.

This package is no longer loaded by my init.el and it would be better if
someone who actually uses the package maintains it.  There is nothing
wrong with it; no need for an RM or anything.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007867: O: parsebib

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:parsebib

I intend to orphan the parsebib package.

This package is no longer loaded by my init.el and it would be better if
someone who actually uses the package maintains it.  There is nothing
wrong with it; no need for an RM or anything.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#904236: RFA: emacs-world-time-mode

[Sean Whitton]

control: retitle -1 O: emacs-world-time-mode

On Sun 22 Jul 2018 at 01:41PM +08, Sean Whitton wrote:

> I request an adoptor for the emacs-world-time-mode package.
>
> This package is no longer in my ~/.emacs.d/init.el and it would be
> better if someone who actually uses the package maintains it.
>
> This is a team-maintained package, so the adoptor should either replace
> me in Uploaders:, or alternatively take the package out of the team's
> hands.

I hereby orphan emacs-world-time-mode.

There is nothing wrong with it; no need for an RM or anything.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#904243: RFA: paredit-everywhere -- cut-down version of paredit for non-lisp buffers

[Sean Whitton]

Hello,

On Sun 22 Jul 2018 at 01:47PM +08, Sean Whitton wrote:

> Package: wnpp
> Severity: normal
>
> I request an adopter for the paredit-everywhere package.
>
> This package is no longer in my ~/.emacs.d/init.el and it would be
> better if someone who actually uses the package maintains it.  FAOD, at
> the time of writing, I am not requesting an adopter for paredit-el and I
> continue to use paredit-el.
>
> This is a team-maintained package, so the adoptor should either replace
> me in Uploaders:, or alternatively take the package out of the team's
> hands.

I hereby orphan paredit-everywhere (not paredit-el).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#901374: RFA: perspective-el

[Sean Whitton]

control: retitle -1 O: perspective-el

Hello,

On Tue 12 Jun 2018 at 10:13AM +01, Sean Whitton wrote:

> I request an adoptor for the perspective-el package.
>
> This package is no longer in my ~/.emacs.d/init.el and it would be
> better if someone who actually uses the package maintains it.
>
> This is a team-maintained package, so the adoptor should either replace
> me in Uploaders:, or alternatively take the package out of the team's
> hands.

I hereby orphan perspective-el.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#995178: glib2.0: autopkgtest failure: glib/memory-monitor-dbus.test (sometimes) times out

[Simon McVittie]

Control: severity -1 normal

On Thu, 17 Mar 2022 at 19:32:39 +0100, Paul Gevers wrote:
> On Mon, 27 Sep 2021 15:47:52 +0100 Simon McVittie  wrote:
> > I'm reporting this with a non-RC severity to avoid disrupting the libffi
> > transition, because if a retry succeeds, we will be able to nudge that
> > transition through without uploading a new version of glib2.0 and resetting
> > the migration countdown. However, it's really RC (as per the release team's
> > RC criteria) so we should fix this after the transition has gone through.
> 
> That transition finished some time ago. So let's raise the severity.

I marked the affected test as flaky in glib 2.70.0-2, so if it sometimes
fails, it's still a bug but should not be disrupting buildd builds or
autopkgtest gating.

It seems to be succeeding in practice, but I haven't looked into whether
anything has changed that would fix it, so leaving it open.

smcv

Bug#904235: RFA: helm-projectile -- Helm integration for Projectile

[Sean Whitton]

Hello,

On Sun 22 Jul 2018 at 01:40PM +08, Sean Whitton wrote:

> Package: wnpp
> Severity: normal
>
> I request an adopter for the helm-projectile package.
>
> This package is no longer in my ~/.emacs.d/init.el and it would be
> better if someone who actually uses the package maintains it (though
> FAOD, at the time of writing I do not seek an adopter for either helm or
> projectile and continue to use both).
>
> This is a team-maintained package, so the adoptor should either replace
> me in Uploaders:, or alternatively take the package out of the team's
> hands.

I hereby orphan helm-projectile.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007866: O: key-chord-el

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:key-chord-el

I intend to orphan the key-chord-el package.

This package is no longer loaded by my init.el and it would be better if
someone who actually uses the package maintains it.  There is nothing
wrong with it; no need for an RM or anything.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007865: O: flx

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:flx

I intend to orphan the flx package.

This package is no longer loaded by my init.el and it would be better if
someone who actually uses the package maintains it.  There is nothing
wrong with it; no need for an RM or anything.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007864: linux-source-4.19: Kernel compilation error when CONFIG_BPF_SYSCALL not set

[David McIntosh]

Package: linux-source-4.19
Version: 4.19.232-1

When attempting to build the kernel without enabling CONFIG_BPF_SYSCALL I
run into the following compilation error:

  CC  arch/x86/kernel/cpu/bugs.o
arch/x86/kernel/cpu/bugs.c: In function 'spectre_v2_select_mitigation':
arch/x86/kernel/cpu/bugs.c:973:34: error: implicit declaration of function
'unprivileged_ebpf_enabled' [-Werror=implicit-function-declaration]
  if (mode == SPECTRE_V2_EIBRS && unprivileged_ebpf_enabled())
  ^
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:309: arch/x86/kernel/cpu/bugs.o] Error
1
make[2]: *** [scripts/Makefile.build:549: arch/x86/kernel/cpu] Error 2
make[1]: *** [scripts/Makefile.build:549: arch/x86/kernel] Error 2
make: *** [Makefile:1060: arch/x86] Error 2

The issue appears to be the security patches applied to include/linux/bpf.h.

In the upstream version of the source the unprivileged_ebpf_enabled
function has a 2nd definition that is included when CONFIG_BPF_SYSCALL is
not set:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/bpf.h?id=v4.19.234#n653

In the debian version of this file the 2nd definition is present but is
omitted unless CONFIG_BPF_SYSCALL is set so it's never included.

Bug#1007863: O: emacs-openwith -- seamlessly open files in external programs with Emacs

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:emacs-openwith

I intend to orphan the emacs-openwith package.

This package is no longer loaded by my init.el and it would be better if
someone who actually uses the package maintains it.  There is nothing
wrong with it; no need for an RM or anything.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

The package description is:
 With this Emacs addon, you can associate external applications with
 files so that you can open them via C-x C-f, with RET in dired, etc.
 .
 You can set your file associations using the customisation interface.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#990802: RFA: propellor -- property-based host configuration management in haskell

[Sean Whitton]

control: retitle -1 O: propellor

On Wed 07 Jul 2021 at 11:29AM -07, Sean Whitton wrote:

> Package: wnpp
> Severity: normal
> Control: affects -1 src:propellor
>
> I am working on a new configuration management system, Consfigurator,
> and recently was able to transfer all my usage of Propellor over to
> Consfigurator.  It would be better for Propellor to be maintained in
> Debian by someone still using it; thus, I request an adopter for the
> propellor package.

I hereby orphan propellor.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#952810: RFH: ebib -- BibTeX database manager for Emacs

[Sean Whitton]

control: retitle -1 O: ebib

On Sat 29 Feb 2020 at 08:57AM -07, Sean Whitton wrote:

> I request assistance with maintaining the ebib package.  Upstream makes
> a lot of releases and I haven't been able to keep up for a while.
>
> A current blocker for updating to a more recent release is that upstream
> changed how their documentation is built.  Fixing this might be an
> interesting project for one of our newer Emacsen Team members; I can
> sponsor uploads.
>
> I still rely on ebib for work and so would like to stay involved in
> maintainance.

I no longer rely on ebib for work.  I hereby orphan the package.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007861: O: epl

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:epl

I hereby orphan the epl package.

This package has not been loaded by my init.el for a long time and it
would be better if someone who actually uses the package maintains it.
There is nothing wrong with it; no need for an RM or anything.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007860: O: spinner-el

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:spinner-el

I hereby orphan the spinner-el package.

This package has not been loaded by my init.el for a long time and it
would be better if someone who actually uses the package maintains it.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007859: O: helm

[Sean Whitton]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emac...@lists.debian.org
Control: affects -1 src:helm

I hereby orphan the helm package.

This package has not been in my init.el for around two years and it
would be better if someone who actually uses the package maintains it.

The package is currently the somewhat-experimental git-debrebase(1), but
it has been working very well for this particular package, so I'd
encourage continuing to use that, and can help someone get up to speed
with using that tool.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1007717: Native source package format with non-native version

[Russ Allbery]

Sam Hartman  writes:
>> "Russ" == Russ Allbery  writes:

> Russ> Switching terminology to completely leave behind the terms
> Russ> with ambiguous meanings isn't a bad idea, but if so we really
> Russ> need a term that captures "is a packaging of an upstream
> Russ> software package with a separate existence" versus "exists
> Russ> solely as a Debian package."  "with-revision" or
> Russ> "without-revision" doesn't feel to me like it does this.
> Russ> Native and non-native do, which is why I was sticking with
> Russ> them, but maybe we can come up with some other equally-good
> Russ> terminology.

> Why do we need that distinction?

I think we need some way to talk about the various things that change
about a package if it is a packaging of an upstream package.  Examples
include a debian/watch file, an upstream metadata file, an upstream
signing key (still useful with single-tarball formats if upstream uses
signed tags, etc.), and provenance information in debian/copyright.

Those things are not tied to the source package format.  We want
provenance information for the upstream source even if you're using a
single tarball as a source package format, but we don't need it if there
is no upstream.

> Looking at current policy, 5.6.12 talks about having a debian revision
> or not having a debian revision.

It seems less useful to me to frame this solely in terms of the version
number format, rather than having the version number format indicate
whether this is a packaging of an upstream source with an independent
existence.  That would imply that if you just omit the debian revision,
you don't need to record the provenance of the upstream source, which
doesn't seem correct.

-- 
Russ Allbery (r...@debian.org)  

Bug#1007261: bullseye-pu: wolfssl/4.6.0-3_4.6.0+p1-1.debdiff updated

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Thu, 2022-03-17 at 11:03 -0700, Felix Lechner wrote:
> Hi,
> 
> On Thu, Mar 17, 2022 at 10:56 AM Adam D. Barratt
>  wrote:
> > That's a non-standard version for a stable update. What version do
> > upstream regard this as?
> 
> 4.6.0+p1

In that case, it would be slightly more conventional to use "4.6.0+p1-
0+deb11u1", but I guess your suggestion is OK too, on the assumption
that there will never be an upload of 4.6.0+p1 to any other suite.

> > (The conventional version string would be 4.6.0-3+deb11u1.)
> 
> That would not match the upstream version and would lead to the wrong
> orig tarball, wouldn't it?

Well, you control the naming of the orig tarball, so you'd just make it
match the package.

> > You don't really need to mention who performed the backport here,
> > FWIW.
> 
> I mentioned it in part to explain the new version string.

OK.

Please feel free to upload.

Regards,

Adam

Bug#1007829: [pkg-netfilter-team] Bug#1007829: arptables - Fails to install: Too many levels of symbolic links

[Alberto Molina Coballes]

Thanks for reporting Bastian,

I've reproduced the issue, but it seems not related to dpkg, arptables
fails to install when iptables isn't installed. I must review and
update arptables postinst script where alternatives are used.

Alberto

Bug#1007840: [notmuch-slurp-debbug] notmuch-slurp-debbug should use "notmuch insert"

[Sean Whitton]

Hello,

On Thu 17 Mar 2022 at 01:51PM -04, Daniel Kahn Gillmor wrote:

> Package: mailscripts
> Version: 0.24-1
> Severity: wishlist
> X-Debbugs-Cc: Jameson Rollins 
>
> notmuch has had an "insert" subcommand since notmuch 0.16 (2013-08-03,
> according to /usr/share/doc/notmuch/NEWS.gz
>
> rather than guessing at maildir paths or whatever, notmuch-slurp-debbug
> should just feed the retreived messages into "notmuch insert".
>
> For backward compatibility, if a "maildir" configuration variable is
> present, it could fall back to the old form of insertion, but emit a
> warning that it is doing so.

How about using 'notmuch insert --folder=' if the old config
key is present, and not issuing a warning?

> When the old method is *not* used, we could add a passthrough option
> that lets the user append arbitrary arguments to "notmuch insert",
> which would also conveniently solve #995842.

Nice.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#995178: glib2.0: autopkgtest failure: glib/memory-monitor-dbus.test (sometimes) times out

[Paul Gevers]

Control: severity -1 serious

On Mon, 27 Sep 2021 15:47:52 +0100 Simon McVittie  wrote:

I'm reporting this with a non-RC severity to avoid disrupting the libffi
transition, because if a retry succeeds, we will be able to nudge that
transition through without uploading a new version of glib2.0 and resetting
the migration countdown. However, it's really RC (as per the release team's
RC criteria) so we should fix this after the transition has gone through.


That transition finished some time ago. So let's raise the severity.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007853: node-stealthy-require: FTBFS with nodejs experimental/14.19.0

[Jérémy Lal]

Source: node-stealthy-require
Version: 1.1.1-5
Severity: important
Tags: ftbfs

This package fails to rebuild. Build log is attached.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Running with gitlab-runner 14.8.2 (c6e7e194)
  on kapouer mWTn5Dhn
section_start:1647537941:prepare_executor
Preparing the "custom" executor
Using Custom executor...
2022-03-17 18:25:41,732 INFO Starting machine using image unstable
2022-03-17 18:25:41,733 INFO Running systemd-run --setenv=SYSTEMD_SECCOMP=0 
--property=KillMode=mixed --property=Type=notify 
--property=RestartForceExitStatus=133 --property=SuccessExitStatus=133 
--property=Slice=machine.slice --property=Delegate=yes 
--property=TasksMax=16384 --property=WatchdogSec=3min systemd-nspawn --quiet 
--volatile=overlay --directory=/var/lib/nspawn-runner/unstable 
--machine=run-2578004 --boot --notify-ready=yes
Running as unit: run-r43d0d5388c26449e948d9fd61b0a9f72.service
section_end:1647537941:prepare_executor
section_start:1647537941:prepare_script
Preparing environment
Running on corossol...
section_end:1647537942:prepare_script
section_start:1647537942:get_sources
Getting source from Git repository
Fetching changes with git depth set to 1...
Initialized empty Git repository in 
/var/lib/nspawn-runner/.build/js-team/nodejs/.git/
Created fresh repository.
Checking out a27fc43c as master-14.x...

Skipping Git submodules setup
section_end:1647537958:get_sources
section_start:1647537958:restore_cache
Restoring cache
Checking cache for node-stealthy-require-build-1...
time="2022-03-17T18:25:59+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=156 revision=13.3.1 version=13.3.1
No URL provided, cache will not be downloaded from shared cache server. Instead 
a local version of cache will be extracted. 
Successfully extracted cache
section_end:1647537959:restore_cache
section_start:1647537959:download_artifacts
Downloading artifacts
Downloading artifacts for build (2576682)...
time="2022-03-17T18:25:59+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=182 revision=13.3.1 version=13.3.1
Downloading artifacts from coordinator... ok    id=2576682 
responseStatus=200 OK token=7T5PxLhx
section_end:1647537962:download_artifacts
section_start:1647537962:step_script
Executing "step_script" stage of the job script
WARNING: Starting with version 14.0 the 'build_script' stage will be 
replaced with 'step_script': 
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26426
$ # Reported in 
https://salsa.debian.org/salsa-ci-team/pipeline/issues/104, # collapsed 
multi-line command
+ [[ -n '' ]]
$ export CCACHE_DIR=${CCACHE_TMP_DIR} # collapsed multi-line command
Get:1 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:2 http://deb.debian.org/debian unstable/main Sources [9639 kB]
Get:3 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:4 http://deb.debian.org/debian unstable/main Translation-en [6762 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-17-1402.17-F-2022-03-16-1412.00.pdiff [76.2 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-17-1402.17-F-2022-03-16-1412.00.pdiff [76.2 kB]
Fetched 16.7 MB in 3s (5841 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  aptitude-common autoconf automake autopoint autotools-dev binutils
  binutils-common binutils-x86-64-linux-gnu bsdextrautils bzip2 cpp cpp-11
  debhelper dh-autoreconf dh-strip-nondeterminism dirmngr dpkg-dev dwz
  fakeroot file g++ g++-11 gcc gcc-11 gcc-11-base gettext gettext-base gnupg
  gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf
  gpgsm groff-base intltool-debian libarchive-zip-perl libasan6 libassuan0
  libatomic1 libb-hooks-op-check-perl libbinutils libboost-iostreams1.74.0
  libc-dev-bin libc6-dev libcc1-0 libclass-method-modifiers-perl
  

Bug#1007852: node-chroma-js: FTBFS with nodejs experimental/14.19.0

[Jérémy Lal]

Source: node-chroma-js
Version: 2.1.1+dfsg-3
Severity: important
Tags: ftbfs

This package fails to rebuild. Build log is attached.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Running with gitlab-runner 14.8.2 (c6e7e194)
  on kapouer mWTn5Dhn
section_start:1647494606:prepare_executor
Preparing the "custom" executor
Using Custom executor...
2022-03-17 06:23:26,724 INFO Starting machine using image unstable
2022-03-17 06:23:26,724 INFO Running systemd-run --setenv=SYSTEMD_SECCOMP=0 
--property=KillMode=mixed --property=Type=notify 
--property=RestartForceExitStatus=133 --property=SuccessExitStatus=133 
--property=Slice=machine.slice --property=Delegate=yes 
--property=TasksMax=16384 --property=WatchdogSec=3min systemd-nspawn --quiet 
--volatile=overlay --directory=/var/lib/nspawn-runner/unstable 
--machine=run-2577003 --boot --notify-ready=yes
Running as unit: run-reb8fa02e8474455aa50946bc6f8428a8.service
section_end:1647494607:prepare_executor
section_start:1647494607:prepare_script
Preparing environment
Running on corossol...
section_end:1647494607:prepare_script
section_start:1647494607:get_sources
Getting source from Git repository
Fetching changes with git depth set to 1...
Initialized empty Git repository in 
/var/lib/nspawn-runner/.build/js-team/nodejs/.git/
Created fresh repository.
Checking out a27fc43c as master-14.x...

Skipping Git submodules setup
section_end:1647494621:get_sources
section_start:1647494621:restore_cache
Restoring cache
Checking cache for node-chroma-js-build-1...
time="2022-03-17T06:23:41+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=156 revision=13.3.1 version=13.3.1
No URL provided, cache will not be downloaded from shared cache server. Instead 
a local version of cache will be extracted. 
Successfully extracted cache
section_end:1647494621:restore_cache
section_start:1647494621:download_artifacts
Downloading artifacts
Downloading artifacts for build (2576682)...
time="2022-03-17T06:23:41+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=183 revision=13.3.1 version=13.3.1
Downloading artifacts from coordinator... ok    id=2576682 
responseStatus=200 OK token=7T5PxLhx
section_end:1647494624:download_artifacts
section_start:1647494624:step_script
Executing "step_script" stage of the job script
WARNING: Starting with version 14.0 the 'build_script' stage will be 
replaced with 'step_script': 
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26426
$ # Reported in 
https://salsa.debian.org/salsa-ci-team/pipeline/issues/104, # collapsed 
multi-line command
+ [[ -n '' ]]
$ export CCACHE_DIR=${CCACHE_TMP_DIR} # collapsed multi-line command
Get:1 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:2 http://deb.debian.org/debian unstable/main Sources [9640 kB]
Get:3 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:4 http://deb.debian.org/debian unstable/main Translation-en [6764 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-17-0206.17-F-2022-03-16-1412.00.pdiff [53.9 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-17-0206.17-F-2022-03-16-1412.00.pdiff [53.9 kB]
Fetched 16.7 MB in 3s (5824 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  aptitude-common autoconf automake autopoint autotools-dev binutils
  binutils-common binutils-x86-64-linux-gnu bsdextrautils bzip2 cpp cpp-11
  debhelper dh-autoreconf dh-strip-nondeterminism dirmngr dpkg-dev dwz
  fakeroot file g++ g++-11 gcc gcc-11 gcc-11-base gettext gettext-base gnupg
  gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf
  gpgsm groff-base intltool-debian libarchive-zip-perl libasan6 libassuan0
  libatomic1 libb-hooks-op-check-perl libbinutils libboost-iostreams1.74.0
  libc-dev-bin libc6-dev libcc1-0 libclass-method-modifiers-perl
  

Bug#1007849: node-collection-visit: FTBFS with nodejs experimental/14.19.0

[Jérémy Lal]

Source: node-collection-visit
Version: 1.0.0-3
Severity: important
Tags: ftbfs

This package fails to rebuild. Build log is attached.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Running with gitlab-runner 14.8.2 (c6e7e194)
  on kapouer mWTn5Dhn
section_start:1647496096:prepare_executor
Preparing the "custom" executor
Using Custom executor...
2022-03-17 06:48:16,696 INFO Starting machine using image unstable
2022-03-17 06:48:16,696 INFO Running systemd-run --setenv=SYSTEMD_SECCOMP=0 
--property=KillMode=mixed --property=Type=notify 
--property=RestartForceExitStatus=133 --property=SuccessExitStatus=133 
--property=Slice=machine.slice --property=Delegate=yes 
--property=TasksMax=16384 --property=WatchdogSec=3min systemd-nspawn --quiet 
--volatile=overlay --directory=/var/lib/nspawn-runner/unstable 
--machine=run-2577030 --boot --notify-ready=yes
Running as unit: run-re6c091cb88e8444ca5bfff420c37fb8c.service
section_end:1647496096:prepare_executor
section_start:1647496096:prepare_script
Preparing environment
Running on corossol...
section_end:1647496097:prepare_script
section_start:1647496097:get_sources
Getting source from Git repository
Fetching changes with git depth set to 1...
Initialized empty Git repository in 
/var/lib/nspawn-runner/.build/js-team/nodejs/.git/
Created fresh repository.
Checking out a27fc43c as master-14.x...

Skipping Git submodules setup
section_end:1647496111:get_sources
section_start:1647496111:restore_cache
Restoring cache
Checking cache for node-collection-visit-build-1...
time="2022-03-17T06:48:32+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=157 revision=13.3.1 version=13.3.1
No URL provided, cache will not be downloaded from shared cache server. Instead 
a local version of cache will be extracted. 
Successfully extracted cache
section_end:1647496112:restore_cache
section_start:1647496112:download_artifacts
Downloading artifacts
Downloading artifacts for build (2576682)...
time="2022-03-17T06:48:32+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=182 revision=13.3.1 version=13.3.1
Downloading artifacts from coordinator... ok    id=2576682 
responseStatus=200 OK token=7T5PxLhx
section_end:1647496115:download_artifacts
section_start:1647496115:step_script
Executing "step_script" stage of the job script
WARNING: Starting with version 14.0 the 'build_script' stage will be 
replaced with 'step_script': 
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26426
$ # Reported in 
https://salsa.debian.org/salsa-ci-team/pipeline/issues/104, # collapsed 
multi-line command
+ [[ -n '' ]]
$ export CCACHE_DIR=${CCACHE_TMP_DIR} # collapsed multi-line command
Get:1 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:2 http://deb.debian.org/debian unstable/main Sources [9640 kB]
Get:3 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:4 http://deb.debian.org/debian unstable/main Translation-en [6764 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-17-0206.17-F-2022-03-16-1412.00.pdiff [53.9 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-17-0206.17-F-2022-03-16-1412.00.pdiff [53.9 kB]
Fetched 16.7 MB in 3s (6040 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  aptitude-common autoconf automake autopoint autotools-dev binutils
  binutils-common binutils-x86-64-linux-gnu bsdextrautils bzip2 cpp cpp-11
  debhelper dh-autoreconf dh-strip-nondeterminism dirmngr dpkg-dev dwz
  fakeroot file g++ g++-11 gcc gcc-11 gcc-11-base gettext gettext-base gnupg
  gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf
  gpgsm groff-base intltool-debian libarchive-zip-perl libasan6 libassuan0
  libatomic1 libb-hooks-op-check-perl libbinutils libboost-iostreams1.74.0
  libc-dev-bin libc6-dev libcc1-0 libclass-method-modifiers-perl
  

Bug#1007848: node-addressparser: FTBFS with nodejs experimental/14.19.0

[Jérémy Lal]

Source: node-addressparser
Version: 1.0.1+repack-2
Severity: important
Tags: ftbfs

This package fails to rebuild. Build log is attached.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Running with gitlab-runner 14.8.2 (c6e7e194)
  on kapouer mWTn5Dhn
section_start:1647485489:prepare_executor
Preparing the "custom" executor
Using Custom executor...
2022-03-17 03:51:29,775 INFO Starting machine using image unstable
2022-03-17 03:51:29,776 INFO Running systemd-run --setenv=SYSTEMD_SECCOMP=0 
--property=KillMode=mixed --property=Type=notify 
--property=RestartForceExitStatus=133 --property=SuccessExitStatus=133 
--property=Slice=machine.slice --property=Delegate=yes 
--property=TasksMax=16384 --property=WatchdogSec=3min systemd-nspawn --quiet 
--volatile=overlay --directory=/var/lib/nspawn-runner/unstable 
--machine=run-2576842 --boot --notify-ready=yes
Running as unit: run-r99ecf9d5676a44318659ccba2c7c5cd7.service
section_end:1647485490:prepare_executor
section_start:1647485490:prepare_script
Preparing environment
Running on corossol...
section_end:1647485490:prepare_script
section_start:1647485490:get_sources
Getting source from Git repository
Fetching changes with git depth set to 1...
Initialized empty Git repository in 
/var/lib/nspawn-runner/.build/js-team/nodejs/.git/
Created fresh repository.
Checking out a27fc43c as master-14.x...

Skipping Git submodules setup
section_end:1647485504:get_sources
section_start:1647485504:restore_cache
Restoring cache
Checking cache for node-addressparser-build-1...
time="2022-03-17T03:51:45+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=158 revision=13.3.1 version=13.3.1
No URL provided, cache will not be downloaded from shared cache server. Instead 
a local version of cache will be extracted. 
Successfully extracted cache
section_end:1647485505:restore_cache
section_start:1647485505:download_artifacts
Downloading artifacts
Downloading artifacts for build (2576682)...
time="2022-03-17T03:51:45+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=184 revision=13.3.1 version=13.3.1
Downloading artifacts from coordinator... ok    id=2576682 
responseStatus=200 OK token=7T5PxLhx
section_end:1647485508:download_artifacts
section_start:1647485508:step_script
Executing "step_script" stage of the job script
WARNING: Starting with version 14.0 the 'build_script' stage will be 
replaced with 'step_script': 
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26426
$ # Reported in 
https://salsa.debian.org/salsa-ci-team/pipeline/issues/104, # collapsed 
multi-line command
+ [[ -n '' ]]
$ export CCACHE_DIR=${CCACHE_TMP_DIR} # collapsed multi-line command
Get:1 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:2 http://deb.debian.org/debian unstable/main Sources [9640 kB]
Get:3 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:4 http://deb.debian.org/debian unstable/main Translation-en [6764 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-17-0206.17-F-2022-03-16-1412.00.pdiff [53.9 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-17-0206.17-F-2022-03-16-1412.00.pdiff [53.9 kB]
Fetched 16.7 MB in 3s (5951 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  aptitude-common autoconf automake autopoint autotools-dev binutils
  binutils-common binutils-x86-64-linux-gnu bsdextrautils bzip2 cpp cpp-11
  debhelper dh-autoreconf dh-strip-nondeterminism dirmngr dpkg-dev dwz
  fakeroot file g++ g++-11 gcc gcc-11 gcc-11-base gettext gettext-base gnupg
  gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf
  gpgsm groff-base intltool-debian libarchive-zip-perl libasan6 libassuan0
  libatomic1 libb-hooks-op-check-perl libbinutils libboost-iostreams1.74.0
  libc-dev-bin libc6-dev libcc1-0 libclass-method-modifiers-perl
  

Bug#1007845: node-babel7: FTBFS with nodejs experimental/14.19.0

[Jérémy Lal]

Source: node-babel7
Version: 7.17.6+~cs214.260.190-1
Severity: important
Tags: ftbfs

This package fails to rebuild. Build log is attached.


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

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


2576910-node-babel7.log
Description: inode/empty

Bug#1007844: jquery: FTBFS with nodejs experimental/14.19.0

[Jérémy Lal]

Source: jquery
Version: 3.3.1~dfsg-3
Severity: important
Tags: ftbfs

This package fails to rebuild. Build log is attached.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Running with gitlab-runner 14.8.2 (c6e7e194)
  on kapouer mWTn5Dhn
section_start:1647480398:prepare_executor
Preparing the "custom" executor
Using Custom executor...
2022-03-17 02:26:38,617 INFO Starting machine using image unstable
2022-03-17 02:26:38,617 INFO Running systemd-run --setenv=SYSTEMD_SECCOMP=0 
--property=KillMode=mixed --property=Type=notify 
--property=RestartForceExitStatus=133 --property=SuccessExitStatus=133 
--property=Slice=machine.slice --property=Delegate=yes 
--property=TasksMax=16384 --property=WatchdogSec=3min systemd-nspawn --quiet 
--volatile=overlay --directory=/var/lib/nspawn-runner/unstable 
--machine=run-2576766 --boot --notify-ready=yes
Running as unit: run-rbccba5885f7d4f9eb2d83281c9e74f06.service
section_end:1647480398:prepare_executor
section_start:1647480398:prepare_script
Preparing environment
Running on corossol...
section_end:1647480399:prepare_script
section_start:1647480399:get_sources
Getting source from Git repository
Fetching changes with git depth set to 1...
Initialized empty Git repository in 
/var/lib/nspawn-runner/.build/js-team/nodejs/.git/
Created fresh repository.
Checking out a27fc43c as master-14.x...

Skipping Git submodules setup
section_end:1647480413:get_sources
section_start:1647480413:restore_cache
Restoring cache
Checking cache for jquery-build-1...
time="2022-03-17T02:26:53+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=157 revision=13.3.1 version=13.3.1
No URL provided, cache will not be downloaded from shared cache server. Instead 
a local version of cache will be extracted. 
Successfully extracted cache
section_end:1647480413:restore_cache
section_start:1647480413:download_artifacts
Downloading artifacts
Downloading artifacts for build (2576682)...
time="2022-03-17T02:26:53+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=182 revision=13.3.1 version=13.3.1
Downloading artifacts from coordinator... ok    id=2576682 
responseStatus=200 OK token=7T5PxLhx
section_end:1647480416:download_artifacts
section_start:1647480416:step_script
Executing "step_script" stage of the job script
WARNING: Starting with version 14.0 the 'build_script' stage will be 
replaced with 'step_script': 
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26426
$ # Reported in 
https://salsa.debian.org/salsa-ci-team/pipeline/issues/104, # collapsed 
multi-line command
+ [[ -n '' ]]
$ export CCACHE_DIR=${CCACHE_TMP_DIR} # collapsed multi-line command
Get:1 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:2 http://deb.debian.org/debian unstable/main Sources [9639 kB]
Get:3 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:4 http://deb.debian.org/debian unstable/main Translation-en [6764 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-16-2007.25-F-2022-03-16-1412.00.pdiff [45.4 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-16-2007.25-F-2022-03-16-1412.00.pdiff [45.4 kB]
Fetched 16.7 MB in 3s (5690 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  aptitude-common autoconf automake autopoint autotools-dev binutils
  binutils-common binutils-x86-64-linux-gnu bsdextrautils bzip2 cpp cpp-11
  debhelper dh-autoreconf dh-strip-nondeterminism dirmngr dpkg-dev dwz
  fakeroot file g++ g++-11 gcc gcc-11 gcc-11-base gettext gettext-base gnupg
  gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf
  gpgsm groff-base intltool-debian libarchive-zip-perl libasan6 libassuan0
  libatomic1 libb-hooks-op-check-perl libbinutils libboost-iostreams1.74.0
  libc-dev-bin libc6-dev libcc1-0 libclass-method-modifiers-perl
  libclass-xsaccessor-perl 

Bug#1007717: Native source package format with non-native version

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Switching terminology to completely leave behind the terms
Russ> with ambiguous meanings isn't a bad idea, but if so we really
Russ> need a term that captures "is a packaging of an upstream
Russ> software package with a separate existence" versus "exists
Russ> solely as a Debian package."  "with-revision" or
Russ> "without-revision" doesn't feel to me like it does this.
Russ> Native and non-native do, which is why I was sticking with
Russ> them, but maybe we can come up with some other equally-good
Russ> terminology.

Why do we need that distinction?

Looking at current policy, 5.6.12 talks about having a debian revision
or not having a debian revision.

Other parts of policy talk about  what parts of the source package there
are.

Why do we need more than these two distinctions.

I think that current policy has mostly left behind the work native
(although their are a few uses still).
My suspicion is that avoiding native allowed us to get a broader
consensus in the policy process.

Why isn't what we have good enough?

Bug#909124: quilt: Please fail gracefully on 'quilt series' when less(1) is not installed

[Daniel Shahaf]

Control: clone 909124 -2
Control: severity -2 normal
Control: retitle -2 quilt: don't set QUILT_PAGER=less when $LESS is set
Control: tags -2 upstream
Control: found -2 0.66-2.1
Control: tags 909124 upstream patch
Control: found 909124 0.66-2.1
Control: severity 909124 minor

Trent W. Buck wrote on Thu, Mar 17, 2022 at 18:43:20 +1100:
> Trent W. Buck wrote:
> > +++ b/usr/share/quilt/scripts/patchfns
> > @@ -,7 +,7 @@ setup_pager()
> > -   QUILT_PAGER=${QUILT_PAGER-${GIT_PAGER-${PAGER-less -R}}}
> > +   QUILT_PAGER=${QUILT_PAGER:-${GIT_PAGER:-${PAGER:-less -R}}}

Thanks.  I'm posting a patch for this bug (#909124 == #-1), and bumping
it to "minor" after re-reviewing 
.

[[[
--- a/quilt/scripts/patchfns.in
+++ b/quilt/scripts/patchfns.in
@@ -,7 +,7 @@ setup_pager()
 
# QUILT_PAGER = QUILT_PAGER | GIT_PAGER | PAGER | less -R
# NOTE: QUILT_PAGER='' is significant
-   QUILT_PAGER=${QUILT_PAGER-${GIT_PAGER-${PAGER-less -R}}}
+   QUILT_PAGER=${QUILT_PAGER-${GIT_PAGER-${PAGER-/usr/bin/sensible-pager}}}
 
[ -z "$QUILT_PAGER" -o "$QUILT_PAGER" = "cat" ]  && return 0
 
]]]

More below.

> FAILS:  env PAGER=cat quilt series
> WORKS:  env -u LESS PAGER=cat quilt series
> 
> 
> This is actually a separate but related bug in quilt.
> If $LESS is set, quilt ignores $PAGER and forces less.
> This is wrong.
⋮
> 18:38  [ -n "$LESS" -a -z "${QUILT_PAGER+x}" ] && QUILT_PAGER="less 
> -FRX"

Agreed.  If Alice normally uses «export PAGER=less LESS=S» and then sets
PAGER=foo, that's the pager quilt shoult use.

Cloned as -2.  The above patch does _not_ fix it.

> If quilt wants to override the user's requested $LESS,
> it should do so with "export LESS=FRX",
> entirely independent of $QUILT_PAGER'.

This particular approach would be lossy: it would overwrite the user's
value of $LESS.  Instead, quilt could _append_ to $LESS, or pass -R into
less(1)'s argv, or only use $LESS as a hint if PAGER and GIT_PAGER are
also unset and less(1) is installed, or document that the user should
configure their $PAGER / $LESS / $QUILT_PAGER envvars with -R, or…

Cheers,

Daniel

P.S. «sed -i s/Upstream-status/Forwarded/ debian/patches/check_SERIES_exists»
would make that patch's headers compatible with DEP-3 parsers.

> 18:32  And for comparison, "PAGER=cat git diff" *is* working for git in 
> the same environment.
> 18:32  I wonder if quilt is getting confused because $HOME doesn't exist?
> 18:33  Nope.  But "env -i PAGER=cat quilt series" behaves
> 18:34  Bizarre...
> 18:36  Get Fucked.
> 18:36  env -u LESS fixes it
> 18:36  But why?
> 18:37  because quilt is broken I guess
> 18:37  $LESS should be read by less(1), not by quilt(1)
> 18:38  [ -n "$LESS" -a -z "${QUILT_PAGER+x}" ] && QUILT_PAGER="less 
> -FRX"
> 18:38  Ugh.
> 18:39  "env" didn't show anything, because it wasn't exported. We 
> should have used "set" instead.
> 

Bug#1007261: bullseye-pu: wolfssl/4.6.0-3_4.6.0+p1-1.debdiff updated

[Felix Lechner]

Hi,

On Thu, Mar 17, 2022 at 10:56 AM Adam D. Barratt
 wrote:
>
> That's a non-standard version for a stable update. What version do
> upstream regard this as?

4.6.0+p1

> (The conventional version string would be 4.6.0-3+deb11u1.)

That would not match the upstream version and would lead to the wrong
orig tarball, wouldn't it?

> You don't really need to mention who performed the backport here, FWIW.

I mentioned it in part to explain the new version string.

Kind regards,
Felix Lechner

Bug#1007841: node-nodedbi: FTBFS with nodejs experimental/14.19.0

[Jérémy Lal]

Source: node-nodedbi
Version: 1.0.14-2
Severity: important
Tags: ftbfs

This package fails to rebuild. Build log is attached.


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Running with gitlab-runner 14.8.2 (c6e7e194)
  on kapouer mWTn5Dhn
section_start:1647475194:prepare_executor
Preparing the "custom" executor
Using Custom executor...
2022-03-17 00:59:54,825 INFO Starting machine using image unstable
2022-03-17 00:59:54,826 INFO Running systemd-run --setenv=SYSTEMD_SECCOMP=0 
--property=KillMode=mixed --property=Type=notify 
--property=RestartForceExitStatus=133 --property=SuccessExitStatus=133 
--property=Slice=machine.slice --property=Delegate=yes 
--property=TasksMax=16384 --property=WatchdogSec=3min systemd-nspawn --quiet 
--volatile=overlay --directory=/var/lib/nspawn-runner/unstable 
--machine=run-2576703 --boot --notify-ready=yes
Running as unit: run-r1426d705a07c49cbae65398c8c2252ed.service
section_end:1647475195:prepare_executor
section_start:1647475195:prepare_script
Preparing environment
Running on corossol...
section_end:1647475195:prepare_script
section_start:1647475195:get_sources
Getting source from Git repository
Fetching changes with git depth set to 1...
Initialized empty Git repository in 
/var/lib/nspawn-runner/.build/js-team/nodejs/.git/
Created fresh repository.
Checking out a27fc43c as master-14.x...

Skipping Git submodules setup
section_end:1647475210:get_sources
section_start:1647475210:restore_cache
Restoring cache
Checking cache for node-nodedbi-build-1...
time="2022-03-17T01:00:10+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=157 revision=13.3.1 version=13.3.1
No URL provided, cache will not be downloaded from shared cache server. Instead 
a local version of cache will be extracted. 
Successfully extracted cache
section_end:1647475210:restore_cache
section_start:1647475210:download_artifacts
Downloading artifacts
Downloading artifacts for build (2576682)...
time="2022-03-17T01:00:10+01:00" level=error msg="Docker executor: prebuilt 
image will be loaded from /var/lib/gitlab-runner."
Runtime platform    arch=amd64 
os=linux pid=184 revision=13.3.1 version=13.3.1
Downloading artifacts from coordinator... ok    id=2576682 
responseStatus=200 OK token=7T5PxLhx
section_end:1647475213:download_artifacts
section_start:1647475213:step_script
Executing "step_script" stage of the job script
WARNING: Starting with version 14.0 the 'build_script' stage will be 
replaced with 'step_script': 
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26426
$ # Reported in 
https://salsa.debian.org/salsa-ci-team/pipeline/issues/104, # collapsed 
multi-line command
+ [[ -n '' ]]
$ export CCACHE_DIR=${CCACHE_TMP_DIR} # collapsed multi-line command
Get:1 http://deb.debian.org/debian unstable InRelease [165 kB]
Get:2 http://deb.debian.org/debian unstable/main Sources [9639 kB]
Get:3 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index 
[63.6 kB]
Get:4 http://deb.debian.org/debian unstable/main Translation-en [6764 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-16-2007.25-F-2022-03-16-1412.00.pdiff [45.4 kB]
Get:5 http://deb.debian.org/debian unstable/main amd64 Packages 
T-2022-03-16-2007.25-F-2022-03-16-1412.00.pdiff [45.4 kB]
Fetched 16.7 MB in 3s (5986 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  aptitude-common autoconf automake autopoint autotools-dev binutils
  binutils-common binutils-x86-64-linux-gnu bsdextrautils bzip2 cpp cpp-11
  debhelper dh-autoreconf dh-strip-nondeterminism dirmngr dpkg-dev dwz
  fakeroot file g++ g++-11 gcc gcc-11 gcc-11-base gettext gettext-base gnupg
  gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf
  gpgsm groff-base intltool-debian libarchive-zip-perl libasan6 libassuan0
  libatomic1 libb-hooks-op-check-perl libbinutils libboost-iostreams1.74.0
  libc-dev-bin libc6-dev libcc1-0 libclass-method-modifiers-perl
  

Bug#1006888: RFP: sasl-xoauth2 -- XOAUTH2 plugin for libsasl2

[Daniel Kahn Gillmor]

Control: retitle 1006888 ITP: sasl-xoauth2 -- XOAUTH2 plugin for libsasl2
Control: owner 1006888 d...@fifthhorseman.net
X-Debbugs-Cc: Tarick Bedeir 

On Mon 2022-03-07 17:50:20 +, Reuben Thomas wrote:
> Package: wnpp
> Severity: wishlist
>
> * Package name: sasl-xoauth2
>   Version : 0.11
>   Upstream Author : Tarick Bedeir 
> * URL : https://github.com/tarickb/sasl-xoauth2
> * License : Apache-2.0
>   Programming Lang: C
>   Description : XOAUTH2 plugin for libsasl2
>
> A plugin for libsasl2 that implements the XOAUTH2 protocol, as used by GMail
> and some other major email services. This can be used to allow postfix and
> other MTAs that can use libsasl to authenticate to such services.

I understand this is concretely useful, and it looks straightforward to
package.  I aim to package it and upload it to debian.

  --dkg


signature.asc
Description: PGP signature

Bug#1007261: bullseye-pu: wolfssl/4.6.0-3_4.6.0+p1-1.debdiff updated

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2022-03-16 at 15:39 -0700, Felix Lechner wrote:
> wolfssl (4.6.0+p1-1) bullseye; urgency=medium
> 

That's a non-standard version for a stable update. What version do
upstream regard this as?

(The conventional version string would be 4.6.0-3+deb11u1.)

>   * Stable update to address the following vulnerabilities. All fixes
> were
> backported by upstream:

You don't really need to mention who performed the backport here, FWIW.
You can, but it's not necessary.

Regards,

Adam

Bug#1007746: buster-pu: package glibc/2.28-10+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Wed, 2022-03-16 at 00:50 +0100, Aurelien Jarno wrote:
> A big part of the changes have been in the buster git branch for many
> months, but I failed to submit the package for a point release up to
> now. What triggered me to look at it again is breakage in the preinst
> script when running on kernel x.y.z with z > 255.
> 
> In other changes are just an (old) pull from the stable branch,
> fixing
> a few important bugs.

Please go ahead, thanks.

As glibc produces a udeb, I'm tagging the bug and CCing accordingly.

Regards,

Adam

Bug#1007717: Native source package format with non-native version

[Russ Allbery]

Helmut Grohne  writes:

> Do you think it would be impossible to move forward on this matter in a
> consensus-based way?

I don't know.  I have some reasons to be dubious, but it's possible that
I'm being excessively pessimistic.

> Yes, please. Though as is evidenced in the replies to your mail, I would
> try to avoid "native" and "non-native" as much as possible given the
> existing confusion. I suggest using something like with-revision vs
> without-revision and single-tarball (from your mail) vs
> patches-separated to transport the concepts.

Switching terminology to completely leave behind the terms with ambiguous
meanings isn't a bad idea, but if so we really need a term that captures
"is a packaging of an upstream software package with a separate existence"
versus "exists solely as a Debian package."  "with-revision" or
"without-revision" doesn't feel to me like it does this.  Native and
non-native do, which is why I was sticking with them, but maybe we can
come up with some other equally-good terminology.

> More and more, it seems to me that we are looking into design work as
> opposed to picking an existing option.

*I* was doing design work, for sure.  But I'm not a member of the TC.  :)
The point was to offer you a design to consider as part of submitting the
request to the TC.

> In the spirit of consensus: Do you agree that retrying this in a
> consensus-based way is still possible?

If the relevant people required to implement a decision are willing to
tackle it that way, I am certainly willing to participate from the Policy
side.

-- 
Russ Allbery (r...@debian.org)  

Bug#1007840: [notmuch-slurp-debbug] notmuch-slurp-debbug should use "notmuch insert"

[Daniel Kahn Gillmor]

Package: mailscripts
Version: 0.24-1
Severity: wishlist
X-Debbugs-Cc: Jameson Rollins 

notmuch has had an "insert" subcommand since notmuch 0.16 (2013-08-03,
according to /usr/share/doc/notmuch/NEWS.gz

rather than guessing at maildir paths or whatever, notmuch-slurp-debbug
should just feed the retreived messages into "notmuch insert".

For backward compatibility, if a "maildir" configuration variable is
present, it could fall back to the old form of insertion, but emit a
warning that it is doing so.

When the old method is *not* used, we could add a passthrough option
that lets the user append arbitrary arguments to "notmuch insert", which
would also conveniently solve #995842.

   --dkg


signature.asc
Description: PGP signature

Bug#1006888: RFP: sasl-xoauth2 -- XOAUTH2 plugin for libsasl2

[Jameson Graef Rollins]

I too would like to strongly support this RFP.  This is the only thing
that I've found that allows me to connect postfix to the Microsoft
office365.com SMTP server, which now requires OAuth2.  I used the
included debian package to build a deb, which installed no problem, and
worked with postfix out-of-the-box.  The included README is very
complete and helpful.

jamie.

Bug#1005949: bullseye-pu: package glibc/2.31-13+deb11u3

[Adam D. Barratt]

On Tue, 2022-03-15 at 20:33 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
> 
> On Thu, 2022-02-17 at 23:15 +0100, Aurelien Jarno wrote:
> > There are multiple fixes in this upload:
> > - 4 security bugs
> > - a fix to avoid preinst script failure when running on kernel
> > x.y.z
> >   with z > 255. 
> > - a fix to avoid changes to /etc/nsswitch.conf to be reverted on
> > upgrade
> > 
> > [ Impact ]
> > Installation will be left vulnerable to security issues and upgrade
> > from buster will fail when running recent upstream stable kernels.
> > 
> 
> This looks OK to me, thanks.
> 
> As glibc produces a udeb, this will want a KiBi-ack; CCing and
> tagging
> accordingly.

As we're getting very close to the window for 11.3 closing, please feel
free to upload.

Regards,

Adam

Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1

[Adam D. Barratt]

On Sat, 2022-02-19 at 22:24 -0500, Daniel Kahn Gillmor wrote:
> On Sat 2022-02-19 17:09:21 +, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed d-i
> > 
[...]
> > That looks fine to me, but will need a d-i ack as the package
> > builds a
> > udeb; tagging and CCing accordingly.
> 
> Understood -- i'll wait for a d-i ack before uploading.

As we're getting very close to the window for 11.3 closing, please feel
free to upload.

Regards,

Adam

Bug#1007165: [Pkg-privacy-maintainers] Bug#1007165: please import upstream v21.1.0

[Nicholas D Steeves]

Hi Antoine!

Antoine Beaupré  writes:

> On 2022-03-12 09:37:52, Nicholas D. Steeves wrote:
>> Source: txtorcon
>> Version: 20.0.0-1
>> Severity: normal
>> X-Debbugs-Cc: Jérémy Bobbio 
>>
>> Hi,
>>
>> v21.1.0 was released some time ago, and should probably be imported
>> without delay, because this action may speed resolution of #1006102.
>
> NMU welcome, I'd say...
>

Agreed, it looks justified in this case.

>> FYI, txtorcon meets the criteria for salvaging, but this is easy to
>> fix! :-)
>>
>>   https://wiki.debian.org/PackageSalvaging
>
> Interested? :)
>

I'm hoping Jérémy will notice this thread and resume work, since this
would be the ideal resolution.

As for my involvement, sure, yes interested, but I've also started
taking steps to focus on the work that I've already committed to
(specifically Syncthing Tray, which is Qt and full-featured, this
spring/early summer)...so I'd strongly prefer to avoid taking on new
responsibilities.  P.S. We should catch up IRL! :-)

> We could also move it to the python team...
>

Yeah, I think this is the second best option, so have CCed the team in
case someone else wants this fixed asap.

> -- 
> Au nom de l'état, la force s'appelle droit.
> Au main de l'individu, elle s'appelle crime.
> - Max Stirner

Autrement dit, Léviathan de Hobbes ;-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1003855: (everything)

[Nicholas D Steeves]

Hi Joshua,

So, would you like me to take care of converting the RFP to an ITP, and
adding taku0 to the copyright holders?

I'm part of the Debian Emacsen Team so also take care of the other
nitpicks in git; they're not release critical blockers, so go into the
-2 source-only upload.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1006346: cloud.debian.org: bullseye AMIs don't boot on Amazon EC2 Xen instances with Enhanced Networking

[Noah Meyerhans]

>From the upstream discussion on the linux-pci mailing list [*]:

> Yes. My understanding is that the issue is because AWS is using older
> versions of Xen. They are in the process of updating their fleet to a
> newer version of Xen so the change introduced with Stefan's commit
> isn't an issue any longer.
> 
> I think the changes are scheduled to be completed in the next 10-12
> weeks. For now we are carrying a revert in the Fedora Kernel.
> 
> You can follow this Fedora CoreOS issue if you'd like to know more
> about when the change lands in their backend. We work closely with one
> of their partner engineers and he keeps us updated.
> https://github.com/coreos/fedora-coreos-tracker/issues/1066

Ideally we can revert the upstream commit from the stable kernels, since
otherwise Debian users on AWS Xen instance types may be stuck using
older, unsafe kernels.  Especially if we have time to include the change
in the upcoming bullseye and buster point releases.  If the kernel
updates for those stable updates have already been built, though, it
might be too late to matter.  By the time we publish our next kernel
builds, the AWS Xen update may be complete.

noah

* 
https://lore.kernel.org/linux-pci/c4a65b9a-d1e2-bf0d-2519-aac718593...@redhat.com/

Bug#1007837: linux: Missing gpio_zynq in arm64 debian installer initrd

[Michal Simek]

Source: linux
Version: 5.10.84-1
Severity: normal

Dear Maintainer,

I tried the latest arm64 installer on Xilinx SOM board which is using cadence 
macb driver with ethernet phy which required reset over gpio. DT has proper 
description for it but gpio_zynq driver is not the part of installer as built 
in the kernel or as kernel module. It means without this gpio driver installer 
won't get access to ethernet for downloading others package. 
On different Xilinx arm64 board there is no an issue and gpio_zynq driver is 
already on target filesystem.
That's why I would like to ask for adding gpio_zynq also to installer to be 
able to run it on this board.

Thanks,
Michal


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

Kernel: Linux 5.16.0-4-arm64 (SMP w/4 CPU threads)
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

Bug#1006233: transition: poppler

[Sebastian Ramacher]

On 2022-03-16 20:25:42, Jeremy Bicha wrote:
> On Wed, Mar 16, 2022 at 3:42 PM Sebastian Ramacher  
> wrote:
> > As libwebp finally migrated, please go ahead
> 
> Will poppler get entangled with the openldap transition?

It won't. openldap itself should migrate in tonight's run and I'll
postpone the rebuild of gdal long enough.

Cheers

> 
> https://release.debian.org/transitions/html/auto-poppler.html
> 
> Thanks,
> Jeremy Bicha
> 

-- 
Sebastian Ramacher

Bug#1007836: ITP: python-catalogue -- super lightweight function registries for Python3 libraries

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: python-catalogue -- super lightweight function registries for 
Python3 libraries
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: python-catalogue
  Version : 2.0.6
  Upstream Author : ExplosionAI UG
* URL : https://github.com/explosion/catalogue
* License : MIT
  Programming Lang: Python
  Description : super lightweight function registries for Python3 libraries
 catalogue is a tiny, zero-dependencies library that makes it easy to add
 function (or object) registries to your code. Function registries are
 helpful when you have objects that need to be both easily serializable
 and fully customizable. Instead of passing a function into your object,
 you pass in an identifier name, which the object can use to lookup the
 function from the registry. This makes the object easy to serialize,
 because the name is a simple string. If you instead saved the function,
 you'd have to use Pickle for serialization, which has many drawbacks.

Remark: This package is maintained by Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-catalogue