Bug#1019786: closed by Debian FTP Masters (reply to Laszlo Boszormenyi (GCS) ) (Bug#1019786: fixed in wxsqlite3 3.4.1~dfsg-6)

[Olly Betts]

On Sun, Sep 18, 2022 at 06:03:32PM +, Debian Bug Tracking System wrote:
> Closes: 1019786
> Changes:
>  wxsqlite3 (3.4.1~dfsg-6) experimental; urgency=medium
>  .
>* Transition to wxwidgets3.2 (closes: #1019786).
>* Mark wxsqlite3-doc Multi-Arch foreign.

Thanks for the upload to experimental.

Updating wxsqlite3 to a new wxWidgets release series requires a
mini-transition as reverse dependencies need updating to match - e.g.
see https://bugs.debian.org/750619 for the wxsqlite transition we did
for the wxWidgets 2.8 -> 3.0 transition.

It appears that there's now only a single reverse dependency, codelite,
which is orphaned so I've updated it and uploaded to experimental too.

Cheers,
Olly

Bug#1020272: ITP: wormhole-william -- End-to-end encrypted file transfer. A magic wormhole CLI and API in Go (golang).

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: wormhole-william
  Version : 1.0.6-1
  Upstream Author : Peter Sanford
* URL : https://github.com/psanford/wormhole-william
* License : Expat
  Programming Lang: Go
  Description : End-to-end encrypted file transfer. A magic wormhole CLI 
and API in Go (golang).

 wormhole-william

 wormhole-william is a Go (golang) implementation of magic wormhole
 (https://magic-wormhole.readthedocs.io/en/latest/). It provides secure
 end-to-end encrypted file transfers between computers. The endpoints are
 connected using the same "wormhole code".

 wormhole-william is compatible with the official python magic wormhole
 cli tool (https://github.com/warner/magic-wormhole).

 Currently, wormhole-william supports:

  * sending and receiving text over the wormhole protocol
  * sending and receiving files over the transit protocol
  * sending and receiving directories over the transit protocol

This is a dependency of termshark 2.4.0. It will be team maintained by the go
team.

Bug#1020271: ITP: golang-nhooyr-websocket -- Minimal and idiomatic WebSocket library for Go

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-nhooyr-websocket
  Version : 1.8.7-1
  Upstream Author : Anmol Sethi
* URL : https://github.com/nhooyr/websocket
* License : Expat
  Programming Lang: Go
  Description : Minimal and idiomatic WebSocket library for Go

 websocket is a minimal and idiomatic WebSocket library for Go.

 Highlights

  * Minimal and idiomatic API
  * First class context.Context (https://blog.golang.org/context) support
  * Fully passes the WebSocket autobahn-testsuite
(https://github.com/crossbario/autobahn-testsuite)
  * Single dependency
(https://pkg.go.dev/nhooyr.io/websocket?tab=imports)
  * JSON and protobuf helpers in the wsjson
(https://pkg.go.dev/nhooyr.io/websocket/wsjson) and wspb
(https://pkg.go.dev/nhooyr.io/websocket/wspb) subpackages
  * Zero alloc reads and writes
  * Concurrent writes
  * Close handshake (https://pkg.go.dev/nhooyr.io/websocket#Conn.Close)
  * net.Conn (https://pkg.go.dev/nhooyr.io/websocket#NetConn) wrapper
  * Ping pong (https://pkg.go.dev/nhooyr.io/websocket#Conn.Ping) API
  * RFC 7692 (https://tools.ietf.org/html/rfc7692) permessage-deflate
compression
  * Compile to Wasm (https://pkg.go.dev/nhooyr.io/websocket#hdr-Wasm)

This is a dependency for wormhole-william, which is in turn a dependency for
the new release of termshark. This package will be team maintaned by the go
team.

Bug#1020270: ITP: golang-debian-vasudev-gospake2 -- Go SPAKE2 Implementation

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-debian-vasudev-gospake2
  Version : 0.2.1+git20210510.d916299-1
  Upstream Author : Vasudev Kamath 
* URL : https://salsa.debian.org/vasudev/gospake2
* License : Expat or GPL-3
  Programming Lang: Go
  Description : Go SPAKE2 Implementation (library)

 Implementation of SPAKE2 key exchange protocol which interoperates with Rust
 Haskell and Python versions.

 This package defines the behavior of group and its element as package groups.
 It also implements 2 groups ed25519 and multiplicative group over integer as
 2 packages. SPAKE2 calculation uses ed25519 as default group and
 allows user to switch to group of his choice.

This is a dependency for wormhole-william, which is in turn a dependency for
the new release of termshark. This package will be team maintaned by the go
team.

Bug#830913: debian-policy: Allow amd64 systems without /lib64

[Russ Allbery]

Javier Serrano Polo  writes:

> Some amd64 systems do not have /lib64, although they can run programs
> with the interpreter set to /lib64/ld-linux-x86-64.so.2 . It would be
> nice if Debian could allow such systems. In section 9.1.1, where it
> says:

> The execution time linker/loader, ld*, must still be made
> available in the existing location under /lib or /lib64

> "must" should be "should".

You reported the above bug six years ago, and it looks like it never
received a reply.  I'm sorry about that!

I'm confused by this bug report, though.  What does "some amd64 systems"
mean in this context?  It looks to me like the amd64 libc6 package
provides /lib64/ld-linux-x86-64.so.2, so a Debian amd64 system would
satisfy this.  Is there some alternate libc6 package available in Debian
that does things differently?  Or are you thinking of some sort of
container or other type of restricted system?

Also, in this case, how does this work?  Is the path somehow remapped at
the kernel level?  (If so, I'm wondering if that would qualify as "made
available" for the purposes of Policy anyway.)

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

Bug#953911: debian-policy: clarify documentation of "Closes: #NNNNNN" changelog syntax

[Russ Allbery]

"Daniel Shahaf"  writes:

> Here's a revision of the patch incorporating the feedback so far:

Thank you for this patch!  I confirmed that your description matches the
regular expression.  This has now been applied for the next release of
Debian Policy.

> [[[
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 1d870d9..1c71525 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -151,9 +151,9 @@ used here to separate groups of changes, if desired.
>  If this upload resolves bugs recorded in the Bug Tracking System (BTS),
>  they may be automatically closed on the inclusion of this package into
>  the Debian archive by including the string: ``closes:  Bug#n`` in
> -the change details.  [#]_ This information is conveyed via the
> -``Closes`` field in the ``.changes`` file (see
> -:ref:`s-f-Closes`).
> +the change details, where ``#n`` is the bug number.  [#]_ This
> +information is conveyed via the ``Closes`` field in the ``.changes``
> +file (see :ref:`s-f-Closes`).
>  
>  The maintainer name and email address used in the changelog should be
>  the details of the person who prepared this release of the package. They
> @@ -860,10 +860,19 @@ should not exist a file ``debian/patches/foo.series`` 
> for any ``foo``.
>  
> /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
>  
> -   Then all of the bug numbers listed will be closed by the archive
> +   That is: The string should consist of the word ``closes:`` followed by
> +   a comma-separated list of bug numbers. Bug numbers may be preceded by
> +   the word ``bug`` and/or a ``#`` sign, as in
> +   ``Closes: 42, bug#43, #44, bug 45``.
> +   
> +   The list of bug numbers may span multiple lines.
> +
> +   All of the bug numbers listed will be closed by the archive
> maintenance software (``dak``) using the version of the changelog
> entry.
>  
> +   The words ``closes:`` and ``bug`` are not case sensitive.
> +
>  .. [#]
> In the case of a sponsored upload, the uploader signs the files, but
> the changelog maintainer name and address are those of the person who
> ]]]

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

Bug#1020269: mirror submission for mirror.iranserver.com

[Reza Bojnordi]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.iranserver.com
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Reza Bojnordi 
Country: IR Iran, Islamic Republic of
Location: iran
Comment: I have changed my repository 
 
 please check




Trace Url: http://mirror.iranserver.com/debian/project/trace/
Trace Url: 
http://mirror.iranserver.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.iranserver.com/debian/project/trace/mirror.iranserver.com

Bug#1020268: mirror submission for mirror.iranserver.com

[Reza Bojnordi]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.iranserver.com
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Reza Bojnordi 
Country: IR Iran, Islamic Republic of
Location: iran
Comment: I have changed my repository 
 
 please check




Trace Url: http://mirror.iranserver.com/debian/project/trace/
Trace Url: 
http://mirror.iranserver.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.iranserver.com/debian/project/trace/mirror.iranserver.com

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Ansgar  writes:

> I would like to recommend packages to use tmpfiles.d(5) to manage
> creating directories in locations such as /var or /etc instead of
> maintainer scripts.

> It could also be used to create trivial files below /var that should be
> recreated if deleted by accident (such as atd's sequence number which is
> currently created by the maintainer script).

Hi all,

Here's where I think we currently are with this proposal:

* There should no longer be any blocker to adding a dependency on
  systemd-tmpfiles since systemd-standalone-tmpfiles exists.

* So far as I can tell, dh_installtmpfiles adds the correct stanza to the
  postinst script for a service to run systemd-tmpfiles after the package
  has installed its tmpfiles.d fragment.  I believe that addresses
  creating these files on installation on systems without any init system?
  (Obviously if tmpfs file systems are subsequently reset on such a
  system, there is nothing in place to recreate these tmp files, but I
  think that's expected and not something we can address?)

* Guillem plans to add support to dpkg to register these files properly as
  package-associated files and also handle creation of the files.  This is
  great, and I am 100% in favor of it.  I don't think that blocks this
  change; to the contrary, I think this change is a good incremental step
  towards that world, since it moves temporary file creation out of
  maintainer scripts into a declarative syntax.  dpkg can then either
  consume the same syntax or packages can later convert that syntax to
  whatever dpkg uses, depending on how the dpkg implementation works,
  which will be a simple and easy-to-detect migration that Lintian can
  diagnose.

Therefore, I don't see anything blocking adopting this as a policy now,
and it seems like an obviously good idea to me.

Am I missing something?  If not, I think the next step is for someone to
propose wording.

In order to handle installations that have no init system, I think we may
have to require that the dependency be listed as:

systemd-standalone-tmpfiles | systemd-tmpfiles

to avoid trying to install systemd into an init-free chroot.  Maybe I have
that wrong?  Currently, dh_installtmpfiles doesn't add a dependency at
all, probably because it assumes that the package will use a fallback to
create the files in cases without an init system?  Either way, we should
address this in the Policy wording, and then encode that in
dh_installtmpfiles if needed.

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

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Russ Allbery]

Control: reassign 924401 base-passwd,base-files
Control: clone 924401 -1
Control: reassign -1 Essential packages only provide functionality after being 
configured
Control: tags -1 patch

Hi all,

Trimming the recipient list to just the relevant maintainers and those who
proposed and (I believe) seconded a change.

This is a very long bug with a *ton* of very useful information about
bootstrapping Debian that I hope someone will capture and document
somewhere, but after reviewing the whole thing, I believe there is only
one actionable change for Policy buried in the middle of it.  It's also
currently assigned to three different packages, and I certainly don't feel
entitled to close the broader issue by applying that change.  Therefore,
I'm going to remove debian-policy from this bug, and create a new bug to
handle just the proposed Policy change discussed below.

(For what it's worth, I love Guillem's idea of converting more maintainer
scripts into declarative metadata and getting out of the problen that
way.)

Helmut Grohne  writes:

> I think at least Guillem and Santiago were arguing that policy should
> not be applied to bootstrap. While I don't like that view, I do find it
> reasonable. It can be made explicit in section 3.8 quite easily:

>  Since dpkg will not prevent upgrading of other packages while an
>  ``essential`` package is in an unconfigured state, all ``essential``
>  packages must supply all of their core functionality even when
> -unconfigured. If the package cannot satisfy this requirement it must not
> +unconfigured after being configured at least once.
> +If the package cannot satisfy this requirement it must not
>  be tagged as essential, and any packages depending on this package must
>  instead have explicit dependency fields as appropriate.

This change looks correct to me based on the discussion in the bug but I
don't know enough to independently confirm that.  I believe Santiago
effectively seconded this change in:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924401#91

It needs one more second.  Ideally, I'd like this to be someone else who
has a lot of understanding of the semantics of essential packages
(Guillem, for instance).  Alas, due to the ordering of the BTS actions,
you may have to hunt down the cloned bug against debian-policy to second
it.

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

Bug#897980: chromium-bsu: on play mode, after the first left click, game loose focus of mouse

[Charles Plessy]

Le Wed, Mar 24, 2021 at 10:58:24AM +0800, Paul Wise a écrit :
> 
> Are you using a Wayland desktop? If so, please log out and try it with
> an X11 desktop, or tell SDL to switch to using Wayland instead of X11:
> 
> env SDL_VIDEODRIVER=wayland chromium-bsu

Hi Paul,

same problem here, and setting the environment variable as you showed
allowed to move the fighter while firing.

Unfortunately, the mouse movements are buggy, as sometimes they are
transiently limited in the horizontal or vertical range of the screen
that they can cover.

I can not tell if it is a separate bug or a side effect of the
workaround you proposed above.

If the environment variable setting is the correct solution for this
bug, how about changing `/usr/games/chromium-bsu/` to a script that
checks for something like `$XDG_SESSION_TYPE == 'wayland'` and
sets `SDL_VIDEODRIVER=wayland` accordingly if true ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#975631: debian-policy: window manager: remove reference to Debian menu

[Russ Allbery]

Ansgar  writes:

> Section 11.8.4 "Packages providing a window manager" still references
> the Debian menu.  But the Debian menu is deprecated.

> I suggest to remove the reference, for example with the patch below.

> --- a/policy/ch-customized-programs.rst
> +++ b/policy/ch-customized-programs.rst
> @@ -345,13 +345,7 @@ Packages that provide a window manager should declare in 
> their
>  alternative for ``/usr/bin/x-window-manager``, with a priority
>  calculated as follows:
>  
> --  Start with a priority of 20.
> -
> --  If the window manager supports the Debian menu system, add 20 points
> -   if this support is available in the package's default configuration
> -   (i.e., no configuration files belonging to the system or user have to
> -   be edited to activate the feature); if configuration files must be
> -   modified, add only 10 points.
> +-  Start with a priority of 40.
>  
>  -  If the window manager complies with `The Window Manager Specification
> Project `_,

Yes, this looks right to me.  Seconded.

I considered whether instead of starting with a priority of 40, we should
instead bump the priority if the window manager supports the desktop
specification, but I think this is a place where the structure of X
environments has changed over the years.  It used to be that the window
manager was what handled application menus, but now that's normally done
by some other component of the desktop environment, or even just some
toolbar app or other type of plugin that the user has chosen, and the
window manager may be just a window manager.

Given that, I don't think there's anything useful we can say here about
menu management.  Old-school window managers that don't use a desktop
environment (fvwm2, for instance) may implement support for desktop files,
or for the Debian menu system for that matter; newer ones are likely to
not handle menus at all and expect some other component to deal with that.

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

Bug#991984: Please document minimal environment variable needed for sensible-utils

[Russ Allbery]

"Bastien Roucariès"  writes:

> Dear Maintainer,

> For now $env -i sensible-utils, fail due to $HOME and $TERM not set.

> I am for now working around HOME not set in sensible-utils core, but
> posix [1] documentation does not document really the value that should
> be set for a correct behavior of program.

> Nevertheless:
> - we should expect that PATH is set to a sensible value (note that it depends
>   of the shell), but nevertheless not setting PATH is not really safe
> - HOME may not be set. If set the value may be incorrect (su -)
> - TERM may not be set. If set the value may not be correct
> - USER may not be set. If set the value may be incorrect (su -)

> So I will like to have a footnote saying that
> sensible-pager/sensible-editor etc, should test if they work under env
> -i, and if they do not work fallback to return 126 (according to shell
> documentation Command invoked cannot execute), thus allowing
> sensible-utils to fallback to vi that is safe and tested under env -i

I think it is a fine idea to attempt to support those situations in
sensible-editor and sensible-pager and document them there, but I'm not
sure what Policy change you're asking for here or why this would be a
matter for Policy.

Policy does not mandate any specific behavior for sensible-editor and
sensible-pager other than that they will implement the EDITOR and PAGER
environment variable checking for you.  I think that's best left to the
maintainer of those programs to decide.

We also don't expect that the editor or pager invoked following the rules
in Policy 11.4 (and, by extension, sensible-editor and sensible-pager
themselves) will work in unusual situations, such as ones without standard
environment variables set.  We can't: the user is free to set EDITOR and
PAGER to anything they chose, including programs not in Debian.  So you
can't really expect any particular behavior from whatever EDITOR or PAGER
is set to.  Maybe it will fail with a helpful error code, maybe it will
start and not work but not exit, maybe something else entirely will
happen.  This is really outside of our control.

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

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Guillem Jover]

On Sun, 2022-09-18 at 18:01:38 -0700, Russ Allbery wrote:
> Guillem Jover  writes:
> 
> > Oh! I've completely missed this all this time, I think because that
> > feels very weird given that it has no synopsis and the text is added
> > already on the first line on the spec. :/
> 
> Other formatted fields with the same semantics are Source, Disclaimer, and
> Comment.  I don't think there are any fields in debian control files with
> those semantics (Description is the only formatted field and it has a
> synopsis), but there are several of them in copyright files.
> 
> Source is another ongoing minor problem, since it's *usually* a URL but is
> not required to be one, and sometimes a textual description of the source
> is needed.  Here too, a structured format would have been nicer, so that
> you could have something like:
> 
> source:
>   urls:
> - https://example.com/foo
> - https://example.org/foo
>   comment: >-
> The foo-rewrite script was originally posted to comp.unix.sources in
> 1992 but otherwise has no source other than the Debian package.

I think Disclaimer and Comment do not seem as problematic because they
tend to contain descriptive prose. For Source it's true that it's
weird as it seems to indeed want to have two different semantics
depending on the content, and considering the current deb822 format,
perhaps having used two different field names might have been better
as you alluded with your YAML example, say Source-Urls (line-based list),
and Source-Comment (formatted text). Such split still seems feasible
and backwards compatible right now though.

But see below.

> > Right, the problem I see is that applying this formatting to a field
> > that has no special treatment for the first line just after the field
> > name seems very unintuitive, because the first line does not contain an
> > additional prefixing space, or if it does no one is adding it!
> 
> > It feels very weird to me that all these would be equivalent:
> 
> >   Copyright: Something long that might trigger some wrapping behavior
> > Other thing very long that might not be clear behaves as the above
> > More
> 
> > and
> 
> >   Copyright:  Something long that might trigger some wrapping behavior
> > Other thing very long that might not be clear behaves as the above
> > More
> 
> > and
> 
> >   Copyright:
> > Something long that might trigger some wrapping behavior
> > Other thing very long that might not be clear behaves as the above
> > More
> 
> I think my brain just assumes that all whitespace after the colon of a
> field name and before the first non-whitespace character is ignored, so
> doesn't have a problem with that, but I can see why it would be confusing.

Just to try to clarify to make sure we are on the same page (if we are,
sorry for the obvious!). What I find confusing is that the semantics
of the field imply different line-wrapping semantics depending on leading
spaces, and because there's no synopsis, the first line is supposed to
act just like the rest, but if spaces are ignored, then how do you
select either of the line-wrapping behaviors for the first line? Also
because adding such spaces after the colon look like typographic errors
to me somehow.

So I think what seems most confusing to me is that for formatted-text
fields with no synopsis, the first line is being used at all, because
that messes with the intuition on how the Description field operates.

> > Otherwise, if the current semantics are retained, at least for me, the
> > first line behavior really needs to be clarified.
> 
> Yes, we should distinguish between formatted text with synopsis and
> formatted text without synopsis more clearly.

Yes.

> Or, you know, just propose
> a new YAML format which would make it trivial to clean up all of these
> problems *and* would provide first-class editor support and easy parsing
> in every major programming language.  :)  But that's WAY bigger than this
> bug.

Ahem, yeah. :)

> > If we end up switching the field semantics, that seems it might cause
> > unnecessary modification churn, given that I (not sure whether other
> > people have done this before than me as well) at least have "instigated"
> > unintentionally this type of change in several places (packages I
> > maintain, golang/prometheus team), including tooling (AFAIR dh-make and
> > dh-make-golang), and other people might have also picked this up too. :/
> 
> I think making the field a line-based list is the obviously correct thing
> to do.  It's just not backward-compatible, so we will have to face the
> question of how we handle a version bump in the copyright file (and of
> course figure out if we're going to deal with all of the other requests
> that would require a version bump).

I was thinking that perhaps an easy way out, might be to say that if
the field contains an empty first line (nothing after the colon), then
it's line based, otherwise it's considered formatted text. Which makes
things 

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Sean Whitton]

Hello,

On Sun 18 Sep 2022 at 05:34PM -07, Russ Allbery wrote:

> Sean Whitton  writes:
>> On Mon 19 Sep 2022 at 12:45AM +02, Guillem Jover wrote:
>
>>> So, personally, I'd be happy to fully switch to stanza TBH, because it
>>> seems more specific to our use, probably easier to search for, and
>>> it's shorter.
>
>> I think this is fine for Policy to do.
>
> I vote for switching to stanza.  Paragraph is going to be confusing when
> talking about package descriptions, which often have multiple paragraphs
> in the normal English meaning of the term.

Yes, I had this example in mind too.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1016750: [Sbcl-bugs] Heap exhaustion problem with SBCL 2.2.6 on armel, armhf

[Sean Whitton]

Hello,

On Sat 27 Aug 2022 at 03:15PM -04, Douglas Katzman wrote:

> I suspect that the heap exhaustion is corrected for this release.
> Also I think this particular GC invariant failure is not of the utmost 
> importance. It seems
> directly related to the heap exhaustion which leaves things in an 
> inconsistent state such
> that 'gc_gen_report_to_file' does not work. It's unfortunate that such is the 
> case, but it is
> what it is.  I would have far been more worried about a GC failure on its 
> own.  Let's see
> how things go after you pull in newer source.

Just to report back, it still fails with 2.2.8.  I'll proceed to disable
the test.

https://ci.debian.net/data/autopkgtest/testing/armhf/c/cl-ironclad/26219482/log.gz

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Russ Allbery]

Guillem Jover  writes:

> No problem. Then in that case I guess I'll try to prepare/commit such
> revert patches for the tooling during this week or so.

For whatever it's worth, I'm not sure that I would bother, even though I
share with you the general desire to be correct about things like this.

While semantically such fields are incorrect according to the
specification, in practice I don't believe any format-aware reader exists.
The files are read by humans or by scripts that likely don't care about
this fine distinction.  As evidence, I note that no one had previously
noticed that this formatting is technically incorrect.

I think it would be fine to leave them and have this be fixed by a future
format change, even if it takes a while.

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

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Guillem Jover]

On Sun, 2022-09-18 at 18:04:00 -0700, Russ Allbery wrote:
> Guillem Jover  writes:
> > BTW, just to make this clear, if this feels like it might not be decided
> > quickly on the Debian policy side, then I'll prepare/commit changes to
> > revert this behavior from tooling that I've previously introduced, until
> > and if this changes again. Otherwise if the feeling is that this might
> > get decided quickly, then I'd prefer to avoid the flip-flopping behavior
> > change (but not to be taken as "current-practice" pressure to swindle
> > the decision! And I'm happy to do it in this case anyway if that makes
> > people feel better about it).
> 
> I have an entirely unpredictable schedule for Debian work, unfortunately,
> so I truly don't have any idea how long this will take.

No problem. Then in that case I guess I'll try to prepare/commit such
revert patches for the tooling during this week or so.

Thanks,
Guillem

Bug#1020266: gimp: GIMP crash frequently

[Marcelo Laia]

Package: gimp
Version: 2.10.32-1+b1
Severity: normal

Dear Maintainer,

GIMP crash randomly and frequently. I don't know what is that reason.

```
GNU Image Manipulation Program version 2.10.32
git-describe: GIMP_2_10_32
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
12.1.0-8' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-
languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-
major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-
included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-
verify --enable-plugin --enable-default-pie --with-system-zlib --enable-
libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto
--enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-
abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-
none=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-
amdhsa=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-gcn/usr --enable-offload-
defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-
gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Debian 12.1.0-8)

# Libraries #
using babl version 0.1.96 (compiled against version 0.1.92)
using GEGL version 0.4.38 (compiled against version 0.4.38)
using GLib version 2.73.3 (compiled against version 2.72.3)
using GdkPixbuf version 2.42.9 (compiled against version 2.42.9)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.50.9 (compiled against version 1.50.9)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Falha de segmentação

Stack trace:
```

# Stack traces obtained from PID 265373 - Thread 265373 #

[New LWP 265377]
[New LWP 265378]
[New LWP 265379]
[New LWP 265380]
[New LWP 265381]
[New LWP 265383]
[New LWP 265422]
[New LWP 265437]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__GI___libc_read (nbytes=256, buf=0x7ffd957e2af0, fd=20) at
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id   Frame
* 1Thread 0x7fdea638b380 (LWP 265373) "gimp-2.10"  __GI___libc_read
(nbytes=256, buf=0x7ffd957e2af0, fd=20) at ../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7fdea5a29640 (LWP 265377) "worker" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3Thread 0x7fdea5228640 (LWP 265378) "worker" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4Thread 0x7fde9640 (LWP 265379) "worker" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7fde9f1e7640 (LWP 265380) "gmain"  0x7fdea6efda3f
in __GI___poll (fds=0x55f3a7c0a070, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
  6Thread 0x7fde9e9e6640 (LWP 265381) "gdbus"  0x7fdea6efda3f
in __GI___poll (fds=0x55f3a7c1a880, nfds=3, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
  7Thread 0x7fde88bff640 (LWP 265383) "async"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  8Thread 0x7fde821ff640 (LWP 265422) "swap writer"syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  9Thread 0x7fde811fd640 (LWP 265437) "pool-gimp-2.10" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

Thread 9 (Thread 0x7fde811fd640 (LWP 265437) "pool-gimp-2.10"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7fdea72ba690 in g_cond_wait_until () at /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#2  0x7fdea7234871 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fdea7234e61 in g_async_queue_timeout_pop () at /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#4  0x7fdea729148d in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7fdea7290c0d in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x7fdea6e87b27 in start_thread (arg=) at
./nptl/pthread_create.c:435
ret = 
pd = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140593625814592,
7552038779474641910, 140593625814592, 0, 140594259720352, 0,
-7533614536699444234, -7533547386010106890}, mask_was_saved = 0}}, priv = {pad
= {0x0, 0x0, 

Bug#1019981: subversion: "svn propedit" loses changes in case of a network failure / remote attack

[Vincent Lefevre]

On 2022-09-18 21:07:16 -0400, James McCoy wrote:
> Control: severity -1 normal
> Control: tag -1 - security
> 
> On Mon, Sep 19, 2022 at 02:53:24AM +0200, Vincent Lefevre wrote:
> > Yes. What happens is that svn retrieves the current property value
> > from the server, puts it in a file "/tmp/svn-prop.tmp" and runs an
> > editor on this file. The user modifies this file and quits the
> > editor. Then svn normally updates this property on the server
> > (from the modified svn-prop.tmp) and removes this temporary file.
> > The issue is that svn removes this file even when the update fails.
> 
> Ok.  I don't see this as either "critical" or a security issue.  "Data
> loss" implies the actual versioned data is corrupted/lost.

I disagree. New data are also valuable data. And contrary to
versioned data, there is no way to retrieve them from a backup.

Perhaps not a security issue because any temporary network failure
can affect svn. But note that the most common case is a remote attack
(at least with Debian's default sshd configuration). On my server, I
can see that since September 11, a "beginning MaxStartups throttling"
occurred 3 times (each case apparently due to an attack from a single
IP, according to the logs).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Russ Allbery]

Guillem Jover  writes:
> On Sun, 2022-09-18 at 22:56:16 +0200, Guillem Jover wrote:
>> On Sun, 2022-09-18 at 10:58:20 -0700, Russ Allbery wrote:
>>> Russ Allbery  writes:

 I would happily apply a version of 0002 that only changes Files and
 leaves Copyright alone.

>> I can split that up, for an incremental update yes. Will send later.

> Attached.

Thanks, applied.

> BTW, just to make this clear, if this feels like it might not be decided
> quickly on the Debian policy side, then I'll prepare/commit changes to
> revert this behavior from tooling that I've previously introduced, until
> and if this changes again. Otherwise if the feeling is that this might
> get decided quickly, then I'd prefer to avoid the flip-flopping behavior
> change (but not to be taken as "current-practice" pressure to swindle
> the decision! And I'm happy to do it in this case anyway if that makes
> people feel better about it).

I have an entirely unpredictable schedule for Debian work, unfortunately,
so I truly don't have any idea how long this will take.

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

Bug#1020265: ITP: postgresql-pgml -- PostgresML is an end-to-end machine learning platform installed and operated as a PostgreSQL extension.

[Lev Kokotov]

Package: postgresql-pgml
Severity: wishlist
Owner: Lev Kokotov 
X-Debbugs-Cc: debian-de...@lists.debian.org, l...@hyperparam.ai

* Package name: postgresql-pgml
  Version : 2.0.0
  Upstream Author : PostgresML Team 
* URL : https://postgresml.org
* License : MIT
  Programming Lang: Rust, Python
  Description : PostgresML is an end-to-end machine learning platform 
installed and operated as a PostgreSQL extension.

PostgresML is a PostgreSQL extension that adds machine learning into the
database. It allows to train dozens of algorithms directly on tables and
views, and to query for predictions using only SQL. It's written in Rust
for maximum performance and safety, and calls out to Python via PyO3 for 
backwards
compatibility with Scikit-Learn and other Python machine learning
libraries.

- Relevenace

This package is a PostgreSQL extension so it can be used by anyone who
uses PostgreSQL, a popular RDBMS.

- Maintenance

The package will be maintained by the PostgresML team. We are not
looking for co-maintainers, but will welcome anyone who wants to help us
or participate in its the maintenance and development.

Bug#1019981: subversion: "svn propedit" loses changes in case of a network failure / remote attack

[James McCoy]

Control: severity -1 normal
Control: tag -1 - security

On Mon, Sep 19, 2022 at 02:53:24AM +0200, Vincent Lefevre wrote:
> On 2022-09-18 14:40:36 -0400, James McCoy wrote:
> > You're saying that the change you were preparing was lost, but nothing
> > was actually changed in svn, right?
> 
> Yes. What happens is that svn retrieves the current property value
> from the server, puts it in a file "/tmp/svn-prop.tmp" and runs an
> editor on this file. The user modifies this file and quits the
> editor. Then svn normally updates this property on the server
> (from the modified svn-prop.tmp) and removes this temporary file.
> The issue is that svn removes this file even when the update fails.

Ok.  I don't see this as either "critical" or a security issue.  "Data
loss" implies the actual versioned data is corrupted/lost.

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

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Russ Allbery]

Guillem Jover  writes:

> Oh! I've completely missed this all this time, I think because that
> feels very weird given that it has no synopsis and the text is added
> already on the first line on the spec. :/

Other formatted fields with the same semantics are Source, Disclaimer, and
Comment.  I don't think there are any fields in debian control files with
those semantics (Description is the only formatted field and it has a
synopsis), but there are several of them in copyright files.

Source is another ongoing minor problem, since it's *usually* a URL but is
not required to be one, and sometimes a textual description of the source
is needed.  Here too, a structured format would have been nicer, so that
you could have something like:

source:
  urls:
- https://example.com/foo
- https://example.org/foo
  comment: >-
The foo-rewrite script was originally posted to comp.unix.sources in
1992 but otherwise has no source other than the Debian package.

Ah well.

> Right, the problem I see is that applying this formatting to a field
> that has no special treatment for the first line just after the field
> name seems very unintuitive, because the first line does not contain an
> additional prefixing space, or if it does no one is adding it!

> It feels very weird to me that all these would be equivalent:

>   Copyright: Something long that might trigger some wrapping behavior
> Other thing very long that might not be clear behaves as the above
> More

> and

>   Copyright:  Something long that might trigger some wrapping behavior
> Other thing very long that might not be clear behaves as the above
> More

> and

>   Copyright:
> Something long that might trigger some wrapping behavior
> Other thing very long that might not be clear behaves as the above
> More

I think my brain just assumes that all whitespace after the colon of a
field name and before the first non-whitespace character is ignored, so
doesn't have a problem with that, but I can see why it would be confusing.

> Otherwise, if the current semantics are retained, at least for me, the
> first line behavior really needs to be clarified.

Yes, we should distinguish between formatted text with synopsis and
formatted text without synopsis more clearly.  Or, you know, just propose
a new YAML format which would make it trivial to clean up all of these
problems *and* would provide first-class editor support and easy parsing
in every major programming language.  :)  But that's WAY bigger than this
bug.

> If we end up switching the field semantics, that seems it might cause
> unnecessary modification churn, given that I (not sure whether other
> people have done this before than me as well) at least have "instigated"
> unintentionally this type of change in several places (packages I
> maintain, golang/prometheus team), including tooling (AFAIR dh-make and
> dh-make-golang), and other people might have also picked this up too. :/

I think making the field a line-based list is the obviously correct thing
to do.  It's just not backward-compatible, so we will have to face the
question of how we handle a version bump in the copyright file (and of
course figure out if we're going to deal with all of the other requests
that would require a version bump).

And I have packages where individual copyright lines are longer than 80
columns, so we either have to require unwrapped lines greater than 80
columns (which I'd rather not do), or we have to define line wrapping
semantics for line-based lists, which adds yet more irritating ugliness to
the deb822 format.  Probably just "if the line is indented by more than
one space, it's a continuation for the previous line" I guess.

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

Bug#1019981: subversion: "svn propedit" loses changes in case of a network failure / remote attack

[Vincent Lefevre]

On 2022-09-18 14:40:36 -0400, James McCoy wrote:
> You're saying that the change you were preparing was lost, but nothing
> was actually changed in svn, right?

Yes. What happens is that svn retrieves the current property value
from the server, puts it in a file "/tmp/svn-prop.tmp" and runs an
editor on this file. The user modifies this file and quits the
editor. Then svn normally updates this property on the server
(from the modified svn-prop.tmp) and removes this temporary file.
The issue is that svn removes this file even when the update fails.

Note: I'm using the "svn+ssh" scheme. I don't know whether this bug
also occurs with the https scheme (I cannot try).

The issue can be reproduced by creating a wrapper script to ssh and
using

  SVN_SSH=/path/to/this/script svn propedit ...

Before quitting the editor, change this script to "exit 1" in order
to simulate a ssh failure.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Russ Allbery]

Guillem Jover  writes:

> I've been considering naming debian/control something like
> «Debian template source package control file», as that is used to
> generate both the source and binary control files. And always
> prefixing with Debian, so that would end up as:

>   * debian/control: «Debian source package template control file»
>   * .dsc:   «Debian source package control file»
>   * DEBIAN/control: «Debian binary package control file»

> This also removes the «master» usage in dpkg, for me for the same
> reasons as I covered at
> .

I like this.  It took a bit for my brain to adjust to it because
"template" felt wrong, but the more I thought about it, the more I think
that's correct and it's pointing out an error in my default way of
thinking about packages.

> File contents
> -

> We have references to the various parts being called as «paragraphs»,
> «stanza», «blocks», but this seems to be more of an issue with dpkg, as
> the usage in the Debian policy is quite clear and uniform now, so I'll
> at least try to remove the «block» usage there, stanza has the nice
> property of being shorter and policy already mentions that this is
> currently a common alias, so I might keep paragraph and stanza for now
> in dpkg.

> The other thing affecting dpkg and debian-policy is how the parts
> within the control files are referred to. We have for example:

>   dpkg   → «general section of control info file»
>«source stanza»
>   policy → «general paragraph»

>   dpkg   → «package's section of control info file»
>   policy → «binary package paragraphs»

> So, how does «source package paragraph» and «binary package paragraph»
> (of the «template control file») sound instead?

As mentioned in the other thread, I think source package stanza and binary
package stanza (of the template control file) sound great.

Obviously a patch to Policy would be delightful, but it's not blocking.
Just let us know if that's more than you have time for.

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

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Russ Allbery]

Sean Whitton  writes:
> On Mon 19 Sep 2022 at 12:45AM +02, Guillem Jover wrote:

>> So, personally, I'd be happy to fully switch to stanza TBH, because it
>> seems more specific to our use, probably easier to search for, and
>> it's shorter.

> I think this is fine for Policy to do.

I vote for switching to stanza.  Paragraph is going to be confusing when
talking about package descriptions, which often have multiple paragraphs
in the normal English meaning of the term.

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

Bug#1020264: polyml FTBFS with glibc 2.34

[Adrian Bunk]

Source: polyml
Version: 5.7.1-4
Severity: serious
Tags: ftbfs bookworm sid experimental

https://buildd.debian.org/status/logs.php?pkg=polyml=5.7.1-4%2Bb2

...
In file included from /usr/include/pthread.h:33,
 from locking.h:44,
 from processes.h:38,
 from sighandler.cpp:103:
sighandler.cpp:561:6: error: missing binary operator before token "("
  561 | #if (PTHREAD_STACK_MIN < 4096)
  |  ^
...

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Sean Whitton]

Hello,

On Mon 19 Sep 2022 at 12:45AM +02, Guillem Jover wrote:

> I went for paragraph, because dpkg has some instances of it already in
> docs and code (and stanza only in code), and mainly because the Debian
> policy uses almost exclusively paragraph for this with a single
> mention of "stanza" in a footnote to mention it's a common alias or
> similar.

Hmm, I see.

> So, personally, I'd be happy to fully switch to stanza TBH, because it
> seems more specific to our use, probably easier to search for, and
> it's shorter.

I think this is fine for Policy to do.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1020263: ggcov FTBFS: 1/21 tests passed

[Adrian Bunk]

Source: ggcov
Version: 0.10-4
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=ggcov=0.10-4%2Bb1

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
(cd test && ./runtest)
Running tests
hostname: "x86-ubc-01"
date: "20220918T235758"
uname -s: "Linux"
uname -m: "x86_64"
uname -r: "5.10.0-18-amd64"
head -1 /etc/os-release: "PRETTY_NAME="Debian GNU/Linux bookworm/sid""
CC: "g++"
which g++: "/usr/bin/g++"
g++ --version: "g++ (Debian 12.2.0-2) 12.2.0"
CXX: "g++"
which g++: "/usr/bin/g++"
g++ --version: "g++ (Debian 12.2.0-2) 12.2.0"
ERROR: (test000) testrunner failed, see log
ERROR: (test001) no output files from tggcov
ERROR: (test002) no output files from tggcov
ERROR: (test004) no output files from tggcov
ERROR: (test005) can't compile foo.C
ERROR: (test006) no output files from tggcov
ERROR: (test007) no output files from tggcov
ERROR: (test008.0) no output files from tggcov
ERROR: (test009) no output files from tggcov
ERROR: (test010) no output files from tggcov
ERROR: (test011.1) no output files from tggcov
ERROR: (test013) no output files from tggcov
ERROR: (test014) no output files from tggcov
ERROR: (test015.a001) no output files from tggcov
ERROR: (test016.1) no output files from tggcov
PASS: (test021) unit test for libpopt / fakepopt.c
ERROR: (test026) no output files from tggcov
ERROR: (test029) no output files from tggcov
ERROR: (test030) no output files from tggcov
ERROR: (test033) no output files from tggcov
ERROR: (test034) no output files from tggcov
Total: 1/21 tests passed
make[1]: *** [debian/rules:35: override_dh_auto_test] Error 1

Bug#1020262: bamfdaemon segmentation faults.

[terroreek]

Package: bamfdaemon
Version: 0.5.6+repack-1
Severity: important
X-Debbugs-Cc: terror@gmail.com

Dear Maintainer,

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

   * What led up to the situation? 
   - Applied latest updates
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   - found that the bamfdaemon.service was not starting.  When I manually run 
/usr/libnexec/bamf/bamfdaemon I get a segmentation fault



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

Kernel: Linux 5.19.9-1-siduction-amd64 (SMP w/48 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bamfdaemon depends on:
ii  libbamf3-20.5.6+repack-1
ii  libc6 2.34-8
ii  libgdk-pixbuf-2.0-0   2.42.9+dfsg-1
ii  libglib2.0-0  2.73.3-3
ii  libgtk-3-03.24.34-3
ii  libgtop-2.0-112.40.0-2
ii  libstartup-notification0  0.12-6+b1
ii  libwnck-3-0   43.0-1
ii  libx11-6  2:1.8.1-2

bamfdaemon recommends no packages.

bamfdaemon suggests no packages.

-- no debconf information

Bug#1020259: sysvinit-core: missing manpage takeover handling

[Andreas Beckmann]

On 19/09/2022 01.40, Adam Borowski wrote:

I can't reproduce either; sample run:


install manpages-{es,fr,hu,pl}/bullseye
install sysvinit-core/sid

  Selecting previously unselected package initscripts.
  Preparing to unpack .../initscripts_3.05-5_all.deb ...
  Unpacking initscripts (3.05-5) ...
  Selecting previously unselected package sysvinit-core.
  Preparing to unpack .../sysvinit-core_3.05-5_amd64.deb ...
...
  Adding 'diversion of /usr/share/man/es/man8/init.8.gz to 
/usr/share/man/es/man8/init.8.dist by sysvinit-core'
  Adding 'diversion of /usr/share/man/es/man8/halt.8.gz to 
/usr/share/man/es/man8/halt.8.dist by sysvinit-core'
  Adding 'diversion of /usr/share/man/es/man8/poweroff.8.gz to 
/usr/share/man/es/man8/poweroff.8.dist by sysvinit-core'
  Adding 'diversion of /usr/share/man/es/man8/reboot.8.gz to 
/usr/share/man/es/man8/reboot.8.dist by sysvinit-core'
  Adding 'diversion of /usr/share/man/es/man8/runlevel.8.gz to 
/usr/share/man/es/man8/runlevel.8.dist by sysvinit-core'
  Adding 'diversion of /usr/share/man/es/man8/shutdown.8.gz to 
/usr/share/man/es/man8/shutdown.8.dist by sysvinit-core'
  Adding 'diversion of /usr/share/man/es/man8/telinit.8.gz to 
/usr/share/man/es/man8/telinit.8.dist by sysvinit-core'
...
  Unpacking sysvinit-core (3.05-5) ...
  dpkg: error processing archive 
/var/cache/apt/archives/sysvinit-core_3.05-5_amd64.deb (--unpack):
   trying to overwrite '/usr/share/man/es/man5/initscript.5.gz', which is also 
in package manpages-es 4.10.0-1
...

Andreas

Bug#1017262: golang-github-anacrolix-dms: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/anacrolix/dms github.com/anacrolix/dms/dlna github.com/anacrolix/dm

[Mathias Gibbens]

Control: tags -1 + fixed-upstream patch

  I have attached a patch that fixes the cause of this FTBFS -- a
simple syntax error in dlna/dms/dms_unix_test.go. This has been fixed
upstream for a while, so another fix could be to package the current
version of this library.

  Looking at this bug was part of my DD application process, where I
was asked to find and fix an existing bug, and submit the fix as a
patch to the BTS. That's why I haven't directly committed the fix to
the salsa repo, even though I'm part of the Go Packaging Team. :)

Mathias
From: Mathias Gibbens 
Description: Fix a simple syntax error; already fixed upstream
diff --git a/dlna/dms/dms_unix_test.go b/dlna/dms/dms_unix_test.go
index a1be6fd..75803fb 100644
--- a/dlna/dms/dms_unix_test.go
+++ b/dlna/dms/dms_unix_test.go
@@ -15,7 +15,7 @@ func TestIsHiddenPath(t *testing.T) {
 	for path, expected := range data {
 		if actual, err := isHiddenPath(path); err != nil {
 			t.Errorf("isHiddenPath(%v) returned unexpected error: %s", path, err)
-		] else if expected != actual {
+		} else if expected != actual {
 			t.Errorf("isHiddenPath(%v), expected %v, got %v", path, expected, actual)
 		}
 	}

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

Bug#1020259: sysvinit-core: missing manpage takeover handling

[Adam Borowski]

On Mon, Sep 19, 2022 at 12:56:16AM +0200, Thorsten Glaser wrote:
> On Mon, 19 Sep 2022, Andreas Beckmann wrote:
> 
> > usr/share/man/es/man8/runlevel.8.gz
> 
> How can that be? They are diverted from preinst, positively this one.

I can't reproduce either; sample run:
https://angband.pl/tmp/piu_sysvinit-core.html


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `

Bug#1020259: sysvinit-core: missing manpage takeover handling: initscript.5, inittab.5

[Andreas Beckmann]

On 19/09/2022 00.56, Thorsten Glaser wrote:

On Mon, 19 Sep 2022, Andreas Beckmann wrote:


usr/share/man/es/man8/runlevel.8.gz


How can that be? They are diverted from preinst, positively this one.


False positive on my side (I reported all potentially conflicting files, 
since dpkg will fail on the first and not report further conflicts). 
initscript.5 and inittab.5 seem to be the remaining culprits, but they 
are no longer shipped by the current versions of manpages-xx. With 
sysvinit-core being the only provider of these files, Breaks+Replaces: 
manpages-{es,fr} (<< 4.15.0-9~), manpages-{hu,pl} (<< 1:4.15.0-9~) might 
be sufficient, no need for further diversions. (Version taken from 
bootlogd.)



Andreas

Bug#1020213: libatk1.0 pulls in at-spi2-core

[Samuel Thibault]

Antoine, as a reminder: mails sent to n...@bugs.debian.org are *not*
cc-ed to the submitter. I have bounced your answer to Dominick.

Antoine Le Gonidec via Pkg-a11y-devel, le dim. 18 sept. 2022 20:38:35 +0200, a 
ecrit:
> On Sun, 18 Sep 2022 09:59:01 +0200 Dominick Grift 
>  wrote:
> > libatk1.0-0 (2.46.0-1) pulls in at-spi2-core (and
> > gsettings-desktop-schemas). It would be really nice if we could
> > opt out of at-spi2-core. at-spi2-core is very intrusive and by itself it
> > does not add any value.
> 
> at-spi2-core is only a recommended dependency of libatk1.0-0, not a hard 
> dependency:
> 
> $ apt depends libatk1.0-0
> libatk1.0-0
>   Depends: libc6 (>= 2.4)
>   Depends: libglib2.0-0 (>= 2.62)
>   Recommends: at-spi2-core
> at-spi2-core:i386
> 
> You should be able to remove at-spi2-core, or prevent its installation, and 
> keep libatk1.0-0 installed at the same time.

Indeed.

That being said, it's true that since recommends are pulled by default,
this can be pulling by default more than desired.  The reason for
the recoommends was only that the atk translated messages are now in
at-spi2-core.mo files, shipped by at-spi2-core.  I have now uploaded a
2.46.0-2 version that adds a new package, at-spi2-common, to contain
them, which atk can thus depend on without trouble.  That will have to
go through NEW, though.  I have increased the severity of this bug to
prevent the migration to testing in the meanwhile.

Thanks for the report,
Samuel

Bug#1020102: golang-github-mattn-go-runewidth: FTBFS: dh_auto_test: error: cd _build && go test -vet=off -v -p 8 github.com/mattn/go-runewidth returned exit code 1

[Mathias Gibbens]

  I'm not 100% certain, but I expect this failure is due to the new
version of unicode-data that was just uploaded to unstable a couple of
days ago.

Mathias


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

Bug#1020261: gimp: GIMP crashes when interacting with text

[Lorenzo Rodrigues Costa]

Package: gimp
Version: 2.10.32-1+b1
Severity: normal
X-Debbugs-Cc: lorenzorodrigues...@gmail.com

Dear Maintainer,

A crash occurs when I try to interact with text that I've inserted.

Steps to reproduce:
1. Open image;
2. Select the text tool and insert text;
3. Try to interact with it by: changing font size, changing color, resizing the 
text box.

Unlike bugs #376821 and #869514, I can insert the text just fine, but by doing 
one the actions that I've mentioned (there could be more that I simply didn't 
observe yet), the program crashes. Also, it happens with either antialiasing 
enabled or disabled.

Debug data given by GIMP (when trying to change font size):

```
GNU Image Manipulation Program version 2.10.32
git-describe: GIMP_2_10_32
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 
12.1.0-8' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-12 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin 
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-gcn/usr
 --enable-offload-defaulted --without-cuda-driver --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Debian 12.1.0-8) 

# Libraries #
using babl version 0.1.96 (compiled against version 0.1.92)
using GEGL version 0.4.38 (compiled against version 0.4.38)
using GLib version 2.73.3 (compiled against version 2.72.3)
using GdkPixbuf version 2.42.9 (compiled against version 2.42.9)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.50.9 (compiled against version 1.50.9)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Falha de segmentação

Stack trace:
```

# Stack traces obtained from PID 48998 - Thread 48998 #

[New LWP 48999]
[New LWP 49000]
[New LWP 49001]
[New LWP 49002]
[New LWP 49003]
[New LWP 49004]
[New LWP 49005]
[New LWP 49009]
[New LWP 49043]
[New LWP 49093]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__GI___libc_read (nbytes=256, buf=0x7ffcef9b30b0, fd=17) at 
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id  Frame 
* 1Thread 0x7fc09fe72380 (LWP 48998) "gimp-2.10"  __GI___libc_read 
(nbytes=256, buf=0x7ffcef9b30b0, fd=17) at ../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7fc09f10d640 (LWP 48999) "worker" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3Thread 0x7fc09e90c640 (LWP 49000) "worker" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4Thread 0x7fc09e10b640 (LWP 49001) "worker" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7fc09590a640 (LWP 49002) "worker" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  6Thread 0x7fc09d90a640 (LWP 49003) "worker" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  7Thread 0x7fc097e12640 (LWP 49004) "gmain"  0x7fc0a08fda3f in 
__GI___poll (fds=0x56189bba27e0, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  8Thread 0x7fc097611640 (LWP 49005) "gdbus"  0x7fc0a08fda3f in 
__GI___poll (fds=0x56189bbb81b0, nfds=3, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  9Thread 0x7fc072dff640 (LWP 49009) "async"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  10   Thread 0x7fc071dfd640 (LWP 49043) "pool-gimp-2.10" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  11   Thread 0x7fc0725fe640 (LWP 49093) "swap writer"syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

Thread 11 (Thread 0x7fc0725fe640 (LWP 49093) "swap writer"):
#0  

Bug#1020260: bitcoin FTBFS: test failure

[Adrian Bunk]

Source: bitcoin
Version: 22.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=bitcoin=22.0-1%2Bb1

...
FAIL: tests
===

test count = 64
random seed = 6388444144dae7d2c5fc175f9e60b0b9
Failure 10 on 30 1d 02 03 bc ff ff 02 16 00 fb ff ff ff ff ff 00 c0 ff 07 00 00 
ff ff ff ff ff ff ff ff ff 
src/tests.c:5776: test condition failed: ret == 0
FAIL tests (exit status: 134)


Testsuite summary for libsecp256k1 0.1

# TOTAL: 2
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See ./test-suite.log

make[7]: *** [Makefile:1287: test-suite.log] Error 1

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Guillem Jover]

On Sun, 2022-09-18 at 14:53:30 -0700, Sean Whitton wrote:
> On Sun 18 Sep 2022 at 10:28PM +02, Guillem Jover wrote:
> 
> > So, how does «source package paragraph» and «binary package paragraph»
> > (of the «template control file») sound instead?
> 
> Can we standardise on 'stanza', please?
>
> I thought that was already standard, and "paragraph" is for prose.

I was also thinking about whether I'd prefer paragraph or stanza, and
the latter seems more specific to deb822 "blocks", and as you say
paragraph seems more for prose.

I went for paragraph, because dpkg has some instances of it already in
docs and code (and stanza only in code), and mainly because the Debian
policy uses almost exclusively paragraph for this with a single
mention of "stanza" in a footnote to mention it's a common alias or
similar.

So, personally, I'd be happy to fully switch to stanza TBH, because
it seems more specific to our use, probably easier to search for, and
it's shorter.

Thanks,
Guillem

Bug#1020259: sysvinit-core: missing manpage takeover handling

[Andreas Beckmann]

Package: sysvinit-core
Version: 3.05-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

The following manpages still cause file conflicts on upgrades from
bullseye:

manpages-es:
usr/share/man/es/man5/initscript.5.gz
usr/share/man/es/man5/inittab.5.gz
usr/share/man/es/man8/runlevel.8.gz
manpages-fr:
usr/share/man/fr/man5/initscript.5.gz
usr/share/man/fr/man5/inittab.5.gz
usr/share/man/fr/man8/halt.8.gz
usr/share/man/fr/man8/init.8.gz
usr/share/man/fr/man8/runlevel.8.gz
manpages-hu:
usr/share/man/hu/man5/inittab.5.gz
manpages-pl:
usr/share/man/pl/man5/initscript.5.gz
usr/share/man/pl/man5/inittab.5.gz
usr/share/man/pl/man8/halt.8.gz
usr/share/man/pl/man8/init.8.gz
usr/share/man/pl/man8/runlevel.8.gz
usr/share/man/pl/man8/shutdown.8.gz

Please note that manpages-hu and manpages-pl have an epoch of '1:',
in case you need to add Breaks/Replaces.

cheers,

Andreas

Bug#1020258: Acknowledgement (elpa-elscreen: fails to install: libgccjit.so: error: error invoking gcc driver)

[Andreas Beckmann]

Control: reassign -1 elpa-elscreen,emacs
Control: found -1 1.4.6-9
Control: found -1 1:28.1+1-3

As I'm seeing this error in a few more emacs packages, this could also 
be a problem (missing dependency?) on the emacs side...


Andreas

Bug#1020258: elpa-elscreen: fails to install: libgccjit.so: error: error invoking gcc driver

[Andreas Beckmann]

Package: elpa-elscreen
Version: 1.4.6-9
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up elpa-elscreen (1.4.6-9) ...
  Install emacsen-common for emacs
  emacsen-common: Handling install of emacsen flavor emacs
  Install apel for emacs
  install/apel: already byte-compiled for emacs, skipped
  Install elpa-elscreen for emacs
  install/elscreen-1.4.6: Handling install of emacsen flavor emacs
  install/elscreen-1.4.6: byte-compiling for emacs
  
  In toplevel form:
  elscreen-color-theme.el:25:1: Error: Native compiler error: (lambda 
( arg0 arg1) (let ((f #'recenter)) (funcall f arg0 arg1))), "Loading 
/etc/emacs/site-start.d/00debian.el (source)...
  Loading /etc/emacs/site-start.d/20apel.el (source)...
  Compiling 
/root/.emacs.d/eln-cache/28.1-488c146b/subr--trampoline-726563656e746572_recenter_0.eln...
  ld: cannot find crti.o: No such file or directory
  libgccjit.so: error: error invoking gcc driver
  Debugger entered--Lisp error: (native-ice \"failed to compile\" 
\"/root/.emacs.d/eln-cache/28.1-488c146b/subr--tramp...\" \"error invoking gcc 
driver\")

comp--compile-ctxt-to-file(\"/root/.emacs.d/eln-cache/28.1-488c146b/subr--tramp...\")

comp-compile-ctxt-to-file(\"/root/.emacs.d/eln-cache/28.1-488c146b/subr--tramp...\")
comp-final1()

load-with-code-conversion(\"/tmp/emacs-int-comp-subr--trampoline-726563656e746...\"
 \"/tmp/emacs-int-comp-subr--trampoline-726563656e746...\" nil t)
command-line-1((\"-l\" 
\"/tmp/emacs-int-comp-subr--trampoline-726563656e746...\"))
command-line()
normal-top-level()
...

This test was performed in a minimal chroot with --no-install-recommends

cheers,

Andreas


elpa-elscreen=1.4.6-9_emacs.log.gz
Description: application/gzip

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Sean Whitton]

Hello,

On Sun 18 Sep 2022 at 10:28PM +02, Guillem Jover wrote:

> So, how does «source package paragraph» and «binary package paragraph»
> (of the «template control file») sound instead?

Can we standardise on 'stanza', please?

I thought that was already standard, and "paragraph" is for prose.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1020257: libuhd4.3.0-dpdk-tests: ships files in /usr/lib/uhd/tests/4.2.0/

[Andreas Beckmann]

Package: libuhd4.3.0-dpdk-tests
Version: 4.3.0.0+ds1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libuhd4.3.0-dpdk-tests.
  Preparing to unpack .../libuhd4.3.0-dpdk-tests_4.3.0.0+ds1-1_amd64.deb ...
  Unpacking libuhd4.3.0-dpdk-tests (4.3.0.0+ds1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libuhd4.3.0-dpdk-tests_4.3.0.0+ds1-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/uhd/tests/4.2.0/dpdk_port_test', which is also 
in package libuhd4.2.0-dpdk-tests 4.2.0.1+ds1-1+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libuhd4.3.0-dpdk-tests_4.3.0.0+ds1-1_amd64.deb

I don't think it was intended to ship files in the "old" location.


cheers,

Andreas


libuhd4.2.0-dpdk-tests=4.2.0.1+ds1-1+b1_libuhd4.3.0-dpdk-tests=4.3.0.0+ds1-1.log.gz
Description: application/gzip

Bug#1020256: pkg-haskell-tools FTBFS: error: Couldn't match expected type

[Adrian Bunk]

Source: pkg-haskell-tools
Version: 0.12.3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=pkg-haskell-tools=0.12.3%2Bb1

...
[4 of 4] Compiling Main ( src/make-all.hs, 
dist-ghc/build/make-all/make-all-tmp/Main.o )

src/make-all.hs:317:58: error:
• Couldn't match expected type ‘O.ParseError’
  with actual type ‘Maybe String -> O.ParseError’
• Probable cause: ‘ShowHelpText’ is applied to too few arguments
  In the third argument of ‘parserFailure’, namely ‘ShowHelpText’
  In the expression:
parserFailure (prefs idm) opts ShowHelpText mempty
  In an equation for ‘failure’:
  failure = parserFailure (prefs idm) opts ShowHelpText mempty
|
317 | let failure = parserFailure (prefs idm) opts ShowHelpText 
mempty
|  
-e: error: debian/hlibrary.setup build --builddir=dist-ghc returned exit code 1
 at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 852.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup build 
--builddir=dist-ghc returned exit"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 596
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup build 
--builddir=dist-ghc") called at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm 
line 470
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "build", 
"--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 650
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:158: build-ghc-stamp] Error 25

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Guillem Jover]

Hi!

On Sun, 2022-09-18 at 22:56:16 +0200, Guillem Jover wrote:
> On Sun, 2022-09-18 at 10:58:20 -0700, Russ Allbery wrote:
> > Russ Allbery  writes:
> > > I would happily apply a version of 0002 that only changes Files and
> > > leaves Copyright alone.
> 
> I can split that up, for an incremental update yes. Will send later.

Attached.

> > Or, perhaps even better, one that changes Copyright the way that you did,
> > but just adds an extra space.  I think that's the simplest compromise
> > between what you're trying to accomplish and the field definition.
> 
> If we end up switching the field semantics, that seems it might cause
> unnecessary modification churn, given that I (not sure whether
> other people have done this before than me as well) at least have
> "instigated" unintentionally this type of change in several places
> (packages I maintain, golang/prometheus team), including tooling
> (AFAIR dh-make and dh-make-golang), and other people might have also
> picked this up too. :/

BTW, just to make this clear, if this feels like it might not be
decided quickly on the Debian policy side, then I'll prepare/commit
changes to revert this behavior from tooling that I've previously
introduced, until and if this changes again. Otherwise if the feeling
is that this might get decided quickly, then I'd prefer to avoid the
flip-flopping behavior change (but not to be taken as "current-practice"
pressure to swindle the decision! And I'm happy to do it in this case
anyway if that makes people feel better about it).

Thanks,
Guillem
From 6c74ff53624595267215405edaf09ab3146d5b93 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 18 Sep 2022 18:10:59 +0200
Subject: [PATCH] copyright-format: Wrap and sort -sat Files field

Do not place entries on the first line with the field name, and place
one item per line, so that adding or removing entries generates as
minimal a diff as possible, and avoids modifying unrelated lines. Use
a single space so that the indentation is always uniform among all
fields.
---
 copyright-format-1.0.xml | 42 ++--
 debian/copyright | 18 +++--
 2 files changed, 40 insertions(+), 20 deletions(-)

diff --git a/copyright-format-1.0.xml b/copyright-format-1.0.xml
index 0f86a76..d5d2bbe 100644
--- a/copyright-format-1.0.xml
+++ b/copyright-format-1.0.xml
@@ -316,19 +316,23 @@ Upstream-Contact: John Doe john@example.com
 
   
 Example files paragraphs
-Files: *
+Files:
+ *
 Copyright: 1975-2010 Ulla Upstream
 License: GPL-2+
 
-Files: debian/*
+Files:
+ debian/*
 Copyright: 2010 Daniela Debianizer
 License: GPL-2+
 
-Files: debian/patches/fancy-feature
+Files:
+ debian/patches/fancy-feature
 Copyright: 2010 Daniela Debianizer
 License: GPL-3+
 
-Files: */*.1
+Files:
+ */*.1
 Copyright: 2010 Manuela Manpager
 License: GPL-2+
 
@@ -401,12 +405,14 @@ License: LGPL-2.1
 
   
 recurrent license
-Files: src/js/editline/*
+Files:
+ src/js/editline/*
 Copyright: 1993, John Doe
1993, Joe Average
 License: MPL-1.1
 
-Files: src/js/fdlibm/*
+Files:
+ src/js/fdlibm/*
 Copyright: 1993, J-Random Corporation
 License: MPL-1.1
 
@@ -1261,7 +1267,8 @@ Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Source: ftp://ftp.example.com/pub/games
 Upstream-Name: X Solitaire
 
-Files: *
+Files:
+ *
 Copyright: 1998 John Doe 
1998 Jane Smith 
 License: GPL-2+
@@ -1298,39 +1305,46 @@ Source: https://www.example.com/code/venus
 Upstream-Name: Planet Venus
 Upstream-Contact: John Doe 
 
-Files: *
+Files:
+ *
 Copyright: 2008, John Doe 
2007, Jane Smith 
2007, Joe Average 
2007, J. Random User 
 License: PSF-2
 
-Files: debian/*
+Files:
+ debian/*
 Copyright: 2008, Dan Developer 
 License: permissive
  Copying and distribution of this package, with or without modification,
  are permitted in any medium without royalty provided the copyright notice
  and this notice are preserved.
 
-Files: debian/patches/theme-diveintomark.patch
+Files:
+ debian/patches/theme-diveintomark.patch
 Copyright: 2008, Joe Hacker 
 License: GPL-2+
 
-Files: planet/vendor/compat_logging/*
+Files:
+ planet/vendor/compat_logging/*
 Copyright: 2002, Mark Smith 
 License: MIT
  [LICENSE TEXT]
 
-Files: planet/vendor/httplib2/*
+Files:
+ planet/vendor/httplib2/*
 Copyright: 2006, John Brown 
 License: MIT2
  Unspecified MIT style license.
 
-Files: planet/vendor/feedparser.py
+Files:
+ planet/vendor/feedparser.py
 Copyright: 2007, Mike Smith 
 License: PSF-2
 
-Files: planet/vendor/htmltmpl.py
+Files:
+ planet/vendor/htmltmpl.py
 Copyright: 2004, Thomas Brown 
 License: GPL-2+
 
diff --git a/debian/copyright b/debian/copyright
index 357ae48..21a514b 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -7,7 +7,8 @@ Comment: Complete copyright notices for all contributors to the various
  For a more thorough (but still incomplete) list of contributors who may
  have a copyright 

Bug#969631: can base-passwd provide the user _apt?

[Johannes Schauer Marin Rodrigues]

Hi Colin,

Quoting Colin Watson (2022-09-16 23:30:11)
> Coming back to this thread, I think I've reached the conclusion that
> trying to migrate the uid is too risky due to the various weird and
> wonderful things that might need to be changed to match, and it makes
> more sense to just add the uid and leave existing systems alone.
> 
> The patch you posted earlier has a couple of problems (a missing colon,
> and I think it makes more sense to set nogroup as _apt's primary group
> rather than gid 42 which is in fact the "shadow" group), but I've gone
> ahead and committed this:
> 
>   
> https://salsa.debian.org/debian/base-passwd/-/commit/dc157c65936b15b44d359fcbd10481f101bd9c15
> 
> I tested this both by making a stock chroot and then upgrading
> (preserved existing uid), and by using "sudo mmdebstrap --hook-dir
> /usr/share/mmdebstrap/hooks/file-mirror-automount --include
> ./base-passwd_3.6.1_amd64.deb unstable unstable" to ensure that the new
> version is installed first (used uid 42).
> 
> Last call for objections before upload!

I've rebuilt base-passwd with above patch and applied the following patch to
apt:

https://salsa.debian.org/apt-team/apt/-/merge_requests/260

I can confirm that with these two changes, I can create a working minimal
chroot.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Guillem Jover]

Hi!

On Sun, 2022-09-18 at 10:42:28 -0700, Russ Allbery wrote:
> Guillem Jover  writes:
> 
> > These are the set of changes I keep doing to the debian/copyright files
> > I end up touching. While some could be characterized as a subjective
> > style issue, I've tried to give as close as possibly objective :)
> > rationale for every and each of the changes in the commit messages which
> > I'll summarize here.
> 
> Thanks!  I have applied these changes for the next release except for
> patch 0002 (applying wrap-and-sort -sat).
> 
> I agree with patch 0002 for Files, but unfortunately I believe it's
> incorrect for Copyright.  You're treating Copyright as if it were a
> line-based list field, but for better or worse (I think probably for
> worse) the current specification says that it's a formatted field.

Oh! I've completely missed this all this time, I think because that
feels very weird given that it has no synopsis and the text is added
already on the first line on the spec. :/

> This means that your change to, for example:
> 
> Copyright:
>  2008 John Doe 
>  2007 Jane Smith 
>  2007 Joe Average 
>  2007 J. Random User 
> 
> means that the semantic content of that field is now:
> 
>  2008 John Doe  2007 Jane Smith 
>  2007 Joe Average  2007 J. Random User
>  
> 
> and a format-aware display engine should show it as such.  This is the
> reason why lines are indented: that makes them verbatim lines per the
> formatting specification in
> https://www.debian.org/doc/debian-policy/ch-controlfields#s-f-description

Right, the problem I see is that applying this formatting to a field
that has no special treatment for the first line just after the field
name seems very unintuitive, because the first line does not contain
an additional prefixing space, or if it does no one is adding it!

It feels very weird to me that all these would be equivalent:

  Copyright: Something long that might trigger some wrapping behavior
Other thing very long that might not be clear behaves as the above
More

and

  Copyright:  Something long that might trigger some wrapping behavior
Other thing very long that might not be clear behaves as the above
More

and

  Copyright:
Something long that might trigger some wrapping behavior
Other thing very long that might not be clear behaves as the above
More

> I would agree with changing the definition of Copyright to a line-based
> list, although in order to do so we'd have to figure out the implications
> of a format change in the specification, and we should also flesh out the
> definition of a line-based list to explain how to handle a line that's
> longer than the normal wrap length.

Right, I'd prefer this too, but obviously that is more involved than
what this report intended to be. So I guess it should be detangled
into another request.

Otherwise, if the current semantics are retained, at least for me, the
first line behavior really needs to be clarified.

On Sun, 2022-09-18 at 10:58:20 -0700, Russ Allbery wrote:
> Russ Allbery  writes:
> > I would happily apply a version of 0002 that only changes Files and
> > leaves Copyright alone.

I can split that up, for an incremental update yes. Will send later.

> Or, perhaps even better, one that changes Copyright the way that you did,
> but just adds an extra space.  I think that's the simplest compromise
> between what you're trying to accomplish and the field definition.

If we end up switching the field semantics, that seems it might cause
unnecessary modification churn, given that I (not sure whether
other people have done this before than me as well) at least have
"instigated" unintentionally this type of change in several places
(packages I maintain, golang/prometheus team), including tooling
(AFAIR dh-make and dh-make-golang), and other people might have also
picked this up too. :/

Thanks,
Guillem

Bug#1020254: libghc-propellor-doc: Depends: haddock-interface-35 but it is not installable

[Sebastian Ramacher]

Package: libghc-propellor-doc
Version: 5.13-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bookworm

$ apt install libghc-propellor-doc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libghc-propellor-doc : Depends: haddock-interface-35 but it is not installable
E: Unable to correct problems, you have held broken packages.

Cheers
-- 
Sebastian Ramacher

Bug#1020253: libghc-lambdabot-trusted-doc: Depends: haddock-interface-35 but it is not installable

[Sebastian Ramacher]

Package: libghc-lambdabot-trusted-doc
Version: 5.3-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bookworm

$ apt install libghc-lambdabot-trusted-doc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libghc-lambdabot-trusted-doc : Depends: haddock-interface-35 but it is not 
installable
Recommends: libghc-oeis-doc but it is not going 
to be installed
Recommends: libghc-quickcheck-safe-doc but it 
is not going to be installed
Recommends: libjs-mathjax but it is not going 
to be installed
E: Unable to correct problems, you have held broken packages.

Cheers
-- 
Sebastian Ramacher

Bug#1020252: libghc-hashmap-doc: Depends: haddock-interface-35 but it is not installable

[Sebastian Ramacher]

Package: libghc-hashmap-doc
Version: 1.3.3-3
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bookworm

$ apt install libghc-hashmap-doc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libghc-hashmap-doc : Depends: haddock-interface-35 but it is not installable
  Recommends: libghc-hashable-doc but it is not going to be 
installed
  Recommends: libjs-mathjax but it is not going to be 
installed
E: Unable to correct problems, you have held broken packages.

Cheers
-- 
Sebastian Ramacher

Bug#1020251: libghc-raaz-doc: Depends: haddock-interface-35 but it is not installable

[Sebastian Ramacher]

Package: libghc-raaz-doc
Version: 0.2.1-2
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

$ apt install libghc-raaz-doc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libghc-raaz-doc : Depends: haddock-interface-35 but it is not installable
   Recommends: libghc-vector-doc but it is not going to be 
installed
   Recommends: libjs-mathjax but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Cheers
-- 
Sebastian Ramacher

Bug#1020250: hugo does not depend on golang package

[Enrique Garcia]

Package: hugo
Version: 0.102.3-1
Severity: important
X-Debbugs-Cc: cqu...@arcor.de

I have tried to install the hugo website creator but as soon as I run "hugo" it
complains with the following message:

Error: failed to download modules: exec: "go": executable file not found in
$PATH

Installing package "golang" solved the issue. Looks like according to the
package page https://packages.debian.org/sid/hugo the hugo package suggest
golang-any. However, when typing apt install hugo I don´t see that suggestion.
Moreover, I think that a full dependency would be better, because hugo does not
work if go is not installed (AFAIK)


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

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

Versions of packages hugo depends on:
ii  libc6 2.34-7
ii  libsass1  3.6.5+20211226-1
ii  libwebp7  1.2.2-2+b1

Versions of packages hugo recommends:
ii  git  1:2.35.1-1

Versions of packages hugo suggests:
ii  asciidoctor   2.0.16-2
pn  golang-any
ii  npm   8.18.0~ds1-1
ii  pandoc2.9.2.1-3+b2
ii  python3-docutils  0.17.1+dfsg-2

-- no debconf information

Bug#1020249: gnome-core: Switch to PipeWire

[Jeremy Bicha]

Package: gnome-core
Version: 1:42+7
Severity: wishlist
X-Debbugs-CC: pipew...@packages.debian.org
Tags: pending bookworm sid

Debian GNOME 11 used PIpeWire for video as required by GNOME for
remote screen sharing on Wayland. By late 2022, most GNOME distros
have also enabled PipeWire as the default audio server. I recommend
that we do that for Debian 12.

Unfortunately, we can't use alternate dependencies because people
upgrading won't be switched to our recommended default. However,
PipeWire does implement the PulseAudio API and it seems unlikely for
typical users to have any need to attempt to disable PipeWire to use
pure PulseAudio instead.

If that is needed, PipeWire uses systemd user services. The Debian
wiki probably should be updated to show how to disable those services
and install the required PulseAudio packages instead. Or maybe someone
could create a Debian package to handle that instead.

Of course, it's not required for anyone to install gnome-core to use
GNOME on Debian. But at that point, you're on your own.

References
---
https://wiki.debian.org/PipeWire
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/home

Thank you,
Jeremy Bicha

Bug#1018156: nftables: list ruleset shows negative ipv6 address

[Jeremy Sowden]

On 2022-08-25, at 23:14:12 -0500, Ross Johnson wrote:
> Package: nftables
> Version: 0.9.8-3.1
> Severity: normal
> X-Debbugs-Cc: r...@homemail.org
> 
> Dear Maintainer,
> 
> As shown below, I created a file call "junk" that makes a few simple nftables 
> chains.
> When I list the chains, nftables shows what looks like a negative number in 
> the last one.
> I would expect it to show the canonical form of ff00::/8 as given in the 
> previous line.
> This simple example is extracted from a complex script to show the problem 
> concisely.
> 
> root@biden:/srv/nftables# cat junk
> #!/usr/sbin/nft -f
> 
> flush ruleset
> table ip6 whatever {
>   chain junk {
> ip6 saddr ff00::/8 drop
> ip6 saddr fe80::/10 drop
> ip6 saddr { ff00::/8, fe80::/10 } drop
>   }
> }
> root@biden:/srv/nftables# /sbin/nft -f junk
> root@biden:/srv/nftables# /sbin/nft list ruleset
> table ip6 whatever {
>   chain junk {
>   ip6 saddr ff00::/8 drop
>   ip6 saddr fe80::/10 drop
>   ip6 saddr { fe80::/10, 
> ff00::-::::::: } drop
>   }
> }
> root@biden:/srv/nftables# 

I've sent a patch upstream to fix this, but one thing to point out is
that what we see here is not a garbled address with a negative number
embedded in it, but a range (ff00:: to ::...:).  It's more
obvious (to me at least) with an IPv4 prefix.

  ip saddr { 10.0.0.0/8, 192.0.0.0/2 } drop

becomes:

  ip saddr { 10.0.0.0/8, 192.0.0.0-255.255.255.255 } drop

J.


signature.asc
Description: PGP signature

Bug#1020248: debian-policy: Clarifying nomenclature for control file names

[Guillem Jover]

Package: debian-policy
Version: 4.6.1.1
Severity: wishlist

Hi!

This is a followup from my comment at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998165#43

To summarize, we have IMO confusing naming and nomenclature for the
various control files and paragraphs/stanzas, and this is even
confusing me when having to deal with dpkg code, so I'd like to give
these more clear and unambiguous new names, and I'd very strongly
prefer to agree on the same naming for Debian policy and dpkg, to
avoid further and worse confusion (even though they currently do not
match exactly anyway, but I'd prefer to not make it worse…).

Just for reference and to give some context, I've got the following
WIP branches, trying to clarify the names in documentation and in the
API on, which I'll probably rework (split/merge) and reword as needed,
so do not take them as anything set in stone:

  
https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/clarify-control-filenames
  
https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/deb822-field-types


File descriptions
-

For example we have:

  * debian/control:
policy → «Source package control file»
dpkg   → «Debian source packages' master control file»

  * .dsc:
policy → «Debian source control file»
dpkg   → «Debian source packages' control file»

  * DEBIAN/control
policy → «Binary package control files»
dpkg   → «Debian binary packages' master control file»

These are quite confusingly close.

I've been considering naming debian/control something like
«Debian template source package control file», as that is used to
generate both the source and binary control files. And always
prefixing with Debian, so that would end up as:

  * debian/control: «Debian source package template control file»
  * .dsc:   «Debian source package control file»
  * DEBIAN/control: «Debian binary package control file»

This also removes the «master» usage in dpkg, for me for the same
reasons as I covered at
.


File contents
-

We have references to the various parts being called as «paragraphs»,
«stanza», «blocks», but this seems to be more of an issue with dpkg, as
the usage in the Debian policy is quite clear and uniform now, so I'll
at least try to remove the «block» usage there, stanza has the nice
property of being shorter and policy already mentions that this is
currently a common alias, so I might keep paragraph and stanza for now
in dpkg.

The other thing affecting dpkg and debian-policy is how the parts
within the control files are referred to. We have for example:

  dpkg   → «general section of control info file»
   «source stanza»
  policy → «general paragraph»

  dpkg   → «package's section of control info file»
  policy → «binary package paragraphs»


So, how does «source package paragraph» and «binary package paragraph»
(of the «template control file») sound instead?


If I've missed any other problematic nomenclature, I'm happy to
discuss and update those on the dpkg side.

Thanks,
Guillem

Bug#1012243: paperwork-gtk: export broken: cairo.Error: error occurred in libfreetype

[Thomas Perret]

Sorry it seems I totally missed this bug report.

I couldn't reproduce the bug on my systems even on a clean virtual
machine installation.

I found one vaguely related upstream issue[0] but it doesn't mention
libfreetype so I don't think it's relevant to that case.

Are you exporting the original PDF or with page-by-page processing?
Does it fail with both export methods?

Does it fail to export with any document?
If not, do you have any document that fails to export that you can
publicly share? I think that could come from a font in the document you
try to export (since libfreetype looks involved).

--
Thomas

[0]: https://gitlab.gnome.org/World/OpenPaperwork/paperwork/-/issues/942


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020247: RFS: minidb/2.0.7-1 -- simple SQLite3-based store for Python objects

[Maxime Werlen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: minidb
   Version : 2.0.7-1
   Upstream Author : Thomas Perl 
 * URL : https://thp.io/2010/minidb/
 * License : ISC
 * Vcs : https://salsa.debian.org/mwerlen/minidb
   Section : python

The source builds the following binary packages:

  python3-minidb - simple SQLite3-based store for Python objects

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/m/minidb/minidb_2.0.7-1.dsc

Changes since the last upload:

 minidb (2.0.7-1) unstable; urgency=medium
 .
   * New upstream release
   * Updated Standards-Version to 4.6.1

Regards,

Maxime

Bug#1020246: apt install hoogle takes forever on armel, armhf and i386

[Paul Gevers]

Source: haskell-hoogle
Version: 5.0.18.3+dfsg1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, since the upload of 
version 5.0.18.3+dfsg1-1, installing hoogle runs until it hits an 
autopkgtest timeout after 50 minutes. I tried it manually on armel, this 
is where it seems stuck:


root 3366746  1.6  0.2  69888 60196 pts/4S+   14:39   0:03  | 
   \_ apt install hoogle
root 3371147  0.1  0.0   9960  3320 pts/5Ss+  14:40   0:00  | 
   \_ /usr/bin/dpkg --status-fd 19 --configure --pending
root 3371793  0.0  0.0   2216   780 pts/5S+   14:40   0:00  | 
   \_ /bin/sh /var/lib/dpkg/info/hoogle.postinst configure
root 3371794  0.0  0.0   2216  1472 pts/5S+   14:40   0:00  | 
   \_ /bin/sh /usr/sbin/update-hoogle
root 3371872  100  0.2 145620 67852 pts/5Sl+  14:40   2:11  | 
   \_ /usr/bin/hoogle generate 
--database=/var/lib/hoogle/databases/default.hoo --local=/usr


E.g.:
https://ci.debian.net/data/autopkgtest/unstable/i386/h/haskell-hoogle/25829597/log.gz

Setting up gcc-12 (12.2.0-1) ...
Setting up gcc (4:12.2.0-1) ...
Setting up ghc (9.0.2-3) ...
update-alternatives: using /usr/bin/runghc to provide 
/usr/bin/runhaskell (runhaskell) in auto mode
update-alternatives: using /usr/bin/ghc to provide 
/usr/bin/haskell-compiler (haskell-compiler) in auto mode

Setting up ghc-doc (9.0.2-3) ...
Setting up libghc-setlocale-doc (1.0.0.10-1) ...
Setting up hoogle (5.0.18.3+dfsg1-1) ...
Converting databases...autopkgtest [00:05:33]: ERROR: testbed failure: 
timed out 


As these tests are marked tmpfail, they are retried over and over again. 
I'll add them to our rejectlist until this bug is fixed.


Don't hesitate to contact us if you need more help on the infra side.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#965041: [Pkg-openssl-devel] Bug#965041: Bug#965041: libssl3: Please stop building legacy provider

[Sebastian Andrzej Siewior]

On 2022-09-18 21:06:59 [+0200], Kurt Roeckx wrote:
> I'm not sure that having the legacy provider automatically enabled by
> default when it's installed is a good idea. That means once it's
> installed, all applications have it by default. I think it needs to be
> enabled per application.

The only legitime users are applications that need rc4/3des (or others)
for legacy reasons like I need to access this.

> I think the same goes for fips. Only applications that need it, and
> probably support a library context should enable it. I don't know enough
> details currently about fips, but I think applications need to provider
> an approved RNG, and /dev/random is no longer acceptable.
> But upgrading the fips provider should be as easy as possible,
> just installing a new version. So I think we need to provider at least
> some config file should have the hash in it.

I'm not 100% sure but based on blured memory rng with get_random() for
seed as we use it is a compile time option. But then I'm not sure if it
can be provided for fips needs by a provider or so.
Anyway, what do we do here?

Do we keep everything as-is and just add something like 
.include /etc/ssl/providers.d/

to openssl.cnf to support custom providers? While outsourcing the legacy
providers to its own package sounds nice, the downside is, as you say,
that once it is enabled by installed package it is enabled for everyone.
Not to mention the bug reports where the enabled legacy providers don't
work because the package is missing.

> Kurt

Sebastian

Bug#971607: Guacamole Server new upstream version 1.4.0 on mentors.debian.net

[Helmar Gerloni]

Dear Maintainer,

upstream is currently on version 1.4.0.

I uploaded an updated package to

https://mentors.debian.net/package/guacamole-server/

Maybe this helps to update the package in Debian. If there is more I can do 
just let me know.

Regards,Helmar.

Bug#1020058: musescore-sftools: FTBFS: ld: CMakeFiles/sf3convert.dir/sfont.cpp.o: undefined reference to symbol 'vorbis_block_clear'

[Thorsten Glaser]

tags 1020058 + pending
thanks

Hi Lucas,

>Relevant part (hopefully):
>> /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
>> -D_FORTIFY_SOURCE=2 -std=c++0x -g -fPIC -fPIE -Wl,-z,relro -Wl,-z,now 
>> -Wl,--as-needed -rdynamic CMakeFiles/sf3convert.dir/sfconvert.cpp.o 
>> CMakeFiles/sf3convert.dir/sfont.cpp.o CMakeFiles/sf3convert.dir/xml.cpp.o -o 
>> sf3convert  /usr/lib/x86_64-linux-gnu/libQt5Xml.so.5.15.4 -lvorbisenc 
>> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.4
>> /usr/bin/ld: CMakeFiles/sf3convert.dir/sfont.cpp.o: undefined reference to 
>> symbol 'vorbis_block_clear'
>> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libvorbis.so.0: error adding symbols: 
>> DSO missing from command line

this was rather confusing at first, but apparently this message
means that an explicit -lvorbis is expected because while -lvorbisenc
brings it in (DT_NEEDED) for the symbol, the linker, at some point,
switched from GNU to OpenBSD semantics in not following these any more
(which is a good thing).

The actual cause, however, was that pkg-config is now only Recommends
instead of Depends from the -dev B-Ds, so the machinery was unable to
find libvorbis.

Adding an explicit B-D on a pkg-config implementation (I use pkgconf
now, first time) fixes this; upload follows. Maybe this helps others
whose packages have similar problems.

Thanks,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec

Bug#995626: RFP: librust-gtk4 -- Rust bindings of GTK 4

[James McCoy]

On Sun, Oct 03, 2021 at 01:11:14PM +0200, Jonas Smedegaard wrote:
> * Package name: librust-gtk4
>   Version : 0.3.0
>   Upstream Author : gtk-rs Project members
> * URL : https://github.com/gtk-rs/gtk4-rs/
> * License : Expat
>   Programming Lang: Rust
>   Description : Rust GTK 4 bindings
> 
> Safe Rust bindings for GTK 4, a multi-platform GUI toolkit.
> 
> This package is needed to package helvum.

$ rmadison rust-gtk4
rust-gtk4  | 0.3.1-1   | testing| source
rust-gtk4  | 0.3.1-1   | unstable   | source

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

Bug#1019235: lintian: 'licence' is not a misspelling

[Thorsten Glaser]

Package: lintian
Version: 2.115.3
Followup-For: Bug #1019235
X-Debbugs-Cc: t...@mirbsd.de

Spotted this too, please fix it, licence is proper English spelling,
not oversea barbarian dialect.


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

Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils2.38.90.20220713-2
ii  bzip2   1.0.8-5
ii  diffstat1.64-1
ii  dpkg1.21.9
ii  dpkg-dev1.21.9
ii  file1:5.41-4
ii  gettext 0.21-9
ii  gpg 2.2.39-1
ii  intltool-debian 0.35.0+20060710.5
ii  iso-codes   4.11.0-1
ii  libapt-pkg-perl 0.1.40+b1
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-1+b2
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-4
ii  libclone-perl   0.45-1+b2
ii  libconfig-tiny-perl 2.28-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.9
ii  libemail-address-xs-perl1.05-1
ii  libencode-perl  3.19-1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-2
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-2
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.12-1
ii  libmldbm-perl   2.05-3
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.122-1
ii  libperlio-gzip-perl 0.20-1
ii  libperlio-utf8-strict-perl  0.009-1+b1
ii  libproc-processtable-perl   0.634-1+b1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1
ii  libsereal-encoder-perl  5.001+ds-1
ii  libsort-versions-perl   1.62-2
ii  libsyntax-keyword-try-perl  0.27-1
ii  libterm-readkey-perl2.38-2
ii  libtext-levenshteinxs-perl  0.03-5
ii  libtext-markdown-discount-perl  0.13-1+b1
ii  libtext-xslate-perl 3.5.9-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-2
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b3
ii  liburi-perl 5.12-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1
ii  libyaml-libyaml-perl0.84+ds-1
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.10.2-3
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.34.0-5
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xz-utils5.2.5-2.1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#965041: [Pkg-openssl-devel] Bug#965041: Bug#965041: libssl3: Please stop building legacy provider

[Kurt Roeckx]

On Sun, Sep 18, 2022 at 07:09:05PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-07-16 08:46:43 [+0200], Kurt Roeckx wrote:
> > On Thu, Jul 16, 2020 at 03:57:17AM +0100, Dimitri John Ledkov wrote:
> > > 
> > > openssl package could ship `.include /etc/ssl/providers.d/` in ssl.conf.
> > 
> > That would actually make sense.
> > 
> > We could use the include thing to ship a config file for the
> > fips module with the correct hash in it.
> 
> Kurt, what do we do here?
> Split /usr/lib/*/ossl-modules/legacy.so into its own package which is
> part of src:openssl and adds a config snippet.

I'm not sure that having the legacy provider automatically enabled by
default when it's installed is a good idea. That means once it's
installed, all applications have it by default. I think it needs to be
enabled per application.

I think the same goes for fips. Only applications that need it, and
probably support a library context should enable it. I don't know enough
details currently about fips, but I think applications need to provider
an approved RNG, and /dev/random is no longer acceptable.
But upgrading the fips provider should be as easy as possible,
just installing a new version. So I think we need to provider at least
some config file should have the hash in it.


Kurt

Bug#1020221: linux-image-5.10.0-18-amd64: no sound on Acer Chromebook Spin 11 R751T (google reef device)

[no2spam]

On Sun, 18 Sep 2022 18:23:48 +0200
Diederik de Haas  wrote:



Hi,

Thanks for responding.
Yes, you are correct - sound doesn't work even on 5.19 kernel. I've tried 
kernels 5.15, 5.16, 5.17, 5.18 without luck.

I've mentioned 5.19 kernel output as it selects different drivers from 5.10 and 
seems to look for google reef related SOF topology file.



debian 5.10.140 loads the following driver:

[   20.444527] snd_hda_intel :00:0e.0: DSP detected with PCI 
class/subclass/prog-if info 0x040100
[   20.474985] da7219 i2c-DLGS7219:00: Using default DAI clk names: 
da7219-dai-wclk, da7219-dai-bclk
[   20.474994] da7219 i2c-DLGS7219:00: Invalid micbias pulse level
[   21.400901] snd_soc_skl :00:0e.0: DSP detected with PCI 
class/subclass/prog-if info 0x040100
[   21.402273] snd_soc_skl :00:0e.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   22.077993] HDMI HDA Codec ehdaudio0D2: Max dais supported: 3


kernel 5.19 loads:
[5.070897] da7219 i2c-DLGS7219:00: Using default DAI clk names: 
da7219-dai-wclk, da7219-dai-bclk
[5.070919] da7219 i2c-DLGS7219:00: Invalid micbias pulse level
[5.181117] snd_hda_intel :00:0e.0: DSP detected with PCI 
class/subclass/prog-if info 0x040100
[5.386487] snd_soc_skl :00:0e.0: DSP detected with PCI 
class/subclass/prog-if info 0x040100
[7.094171] snd_soc_skl :00:0e.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[7.898666] HDMI HDA Codec ehdaudio0D2: Max dais supported: 3
[7.920335] snd_soc_skl :00:0e.0: Direct firmware load for 
5a98-reef-reef-8-tplg.bin failed with error -2
[7.920345] snd_soc_skl :00:0e.0: tplg fw 5a98-reef-reef-8-tplg.bin load 
failed with -2, trying alternative tplg name bxt_da7219_mx98357a-tplg.bin
[7.920382] snd_soc_skl :00:0e.0: Direct firmware load for 
bxt_da7219_mx98357a-tplg.bin failed with error -2
[7.920385] snd_soc_skl :00:0e.0: tplg bxt_da7219_mx98357a-tplg.bin 
failed with -2, falling back to dfw_sst.bin
[7.920417] snd_soc_skl :00:0e.0: Direct firmware load for dfw_sst.bin 
failed with error -2
[7.920420] snd_soc_skl :00:0e.0: Fallback tplg fw dfw_sst.bin load 
failed with -2
[7.920422] snd_soc_skl :00:0e.0: Failed to init topology!
[7.920424] snd_soc_skl :00:0e.0: ASoC: error at snd_soc_component_probe 
on :00:0e.0: -2
[7.920451] bxt_da7219_max98357a bxt_da7219_mx98357a: ASoC: failed to 
instantiate card -2
[7.920573] bxt_da7219_max98357a: probe of bxt_da7219_mx98357a failed with 
error -2


As I understand the problem is matching kernel driver with the right Apollo 
Lake SOF driver from firmware-sof-signed (v1.7-1) package. But Sound Open 
Firmware is too complicated for me.




> On Sunday, 18 September 2022 13:02:47 CEST no2spam wrote:
> > Package: src:linux
> > Version: 5.10.140-1
> >
> > dmesg of Liquorix 5.19 kernel on the same machine (using Antix-21
> > (Debian bullseye without systemd):
>
> Why do you think the output of some 'random' 5.19 kernel is relevant
> for a bug in Debian's 5.10.140 kernel?
>
> If it does work with a different (newer or older) Debian kernel, that
> would be useful to know.
>
> FWIW: I did look through the dmesg output and I got the impression it
> didn't work with the 'random' 5.19 kernel either.

Bug#1020245: ITP: node-libpq -- Node.js native bindings to the PostgreSQL libpq C client library

[Yadd]

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

* Package name: node-libpq
  Version : 1.8.12
  Upstream Author : Brian M. Carlson
* URL : https://github.com/brianc/node-libpq
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js native bindings to the PostgreSQL libpq C client 
library

node-libpq attempts to mirror as closely as possible the C API provided by
libpq and provides the absolute minimum level of abstraction.  It is
intended to be extremely low level and allow you the same access as the
libpq in C.

This package is needed to update node-postgres (node-pg) and close #1020132

Bug#1020228: usrmerge: fails to install on overlayfs

[Luca Boccassi]

On Sun, 18 Sep 2022 18:07:31 +0200 Ansgar  wrote:
> On Sun, 18 Sep 2022 16:15:28 +0200 Helmut Grohne 
wrote:
> [usrmerge on overlayfs]
> > 
> > I recommend turning the check around. First actually attempt to
perform
> > the conversion. If that happens to fails, check for overlayfs and
> > conditionally emit the helpful message. That way, conversion
actually is
> > performed when it can be performed. When it cannot be performed, we
> > cannot do anything about it anyway.
> 
> What fails in the rename in `convert_directory`; see section
"renaming
> directories" in linux' Documentation/filesystems/overlayfs.rst. That
> happens after some conversion steps are already performed. So I don't
> think we should drop the check entirely.
> 
> As a compromise one could:
> 
> a) Require an environment variable to be set to disable the check.
> 
> b) If overlayfs is detected, try calling rename in the check, e.g.,
>    perl -e '
>    rename("/sbin", "/sbin~usrmerge~");
>    rename("/sbin~usrmerge~", "/sbin");
>    '
>    Plus some error handling for:
>    - overlayfs specific problem when this fails with EXDEV
>  (i.e., what the check is supposed to catch)
>    - any other reason this fails.
> 
>    Maybe also use some other directory instead of /sbin, but
>    it has to exist on the underlaying filesystem, not the overlay to
>    catch the problem we want to catch.

That sounds sensible to me, this seems to work, please review:

https://salsa.debian.org/md/usrmerge/-/merge_requests/6

-- 
Kind regards,
Luca Boccassi


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

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Sean Whitton]

Hello,

On Sun 18 Sep 2022 at 03:11PM +02, Helmut Grohne wrote:

> Hi,
>
> On Sat, Sep 10, 2022 at 11:57:48PM +0200, Johannes Schauer Marin Rodrigues 
> wrote:
>> From my side, I'd be fine with the TC pausing any action on this issue and
>> waiting for our mail to d-devel first. This is assuming that if there is no
>> opposition to the DPKG_ROOT idea, that Steve then also has no objection 
>> against
>> merging our patch.
>>
>> Helmut, what do you think?
>
> I think that the CTTE is so slow that there is no need to pause in any
> way. The d-devel thread seems rather boring, so we may as well move
> ahead.
>
> Let me restate that I see this as a procedural issue. I believe that a
> maintainer has an obligation to communicate in a reasonable way. For
> instance, we file RC bugs when the maintainer address bounces. I argue
> that maintainer communication isn't working for pam. Even if more
> arguments against DPKG_ROOT pop up now, I kinda find it late on
> procedural grounds.
>
> So no, let's not pause this. Nothing has changed really. While Steve did
> reply, that doesn't happen to please Sam. If the three weeks expired
> today, I would have referred it to the CTTE as well.

You'll have seen it, but for the benefit of others, at our meeting this
week we decided that we will review the patch and determine whether we
have a consensus about applying it during our next monthly meeting.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1020213: libatk1.0 pulls in at-spi2-core

[Antoine Le Gonidec]

On Sun, 18 Sep 2022 09:59:01 +0200 Dominick Grift  
wrote:

libatk1.0-0 (2.46.0-1) pulls in at-spi2-core (and
gsettings-desktop-schemas). It would be really nice if we could
opt out of at-spi2-core. at-spi2-core is very intrusive and by itself it
does not add any value.


at-spi2-core is only a recommended dependency of libatk1.0-0, not a hard 
dependency:

$ apt depends libatk1.0-0
libatk1.0-0
  Depends: libc6 (>= 2.4)
  Depends: libglib2.0-0 (>= 2.62)
  Recommends: at-spi2-core
at-spi2-core:i386

You should be able to remove at-spi2-core, or prevent its installation, and 
keep libatk1.0-0 installed at the same time.

Bug#1019981: subversion: "svn propedit" loses changes in case of a network failure / remote attack

[James McCoy]

On Sun, Sep 18, 2022 at 02:18:22AM +0200, Vincent Lefevre wrote:
> (The "critical" severity is in part because the data loss was
> triggered by a remote attack, though the data loss may occur
> with any kind of network failure.)
> 
> I wanted to edit a log message with
> 
>   svn pe --revprop svn:log -r 151946
> 
> (not just a minor change, I was replacing text by a much longer text),
> but got an immediate error from SSH after quitting the editor:
> 
> kex_exchange_identification: read: Connection reset by peer
> Connection reset by 155.133.131.76 port 22
> svn: E170013: Unable to connect to a repository at URL 'svn+ssh://mysvn'
> svn: E210002: To better debug SSH connection problems, remove the -q option 
> from 'ssh' in the [tunnels] section of your Subversion configuration file.
> svn: E210002: Network connection closed unexpectedly
> 
> Subversion apparently does not keep a copy of the text (contrary to
> the case of a commit, which leaves a svn-commit.tmp file), so the
> whole new text was lost!!!

You're saying that the change you were preparing was lost, but nothing
was actually changed in svn, right?

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

Bug#1019787: silverjuke: Please transition to wxwidgets3.2

[Dr. Tobias Quathamer]

Am 16.09.22 um 22:05 schrieb Scott Talbert:

Patch sent:
https://salsa.debian.org/debian/silverjuke/-/merge_requests/1

Regards,
Scott


Hi Scott,

great, thanks! Merged & uploaded.

Regards,
Tobias



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011210: reverse dependencies

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Roger,

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

Checking reverse dependencies...
# Broken Depends:
android-platform-art: dexdump [amd64 arm64 armhf i386]
  dexlist [amd64 arm64 armhf i386]
android-platform-frameworks-base: android-libandroidfw-dev [amd64 arm64 
armel armhf i386 mips64el mipsel]


# Broken Build-Depends:
android-platform-art: android-libbacktrace-dev (>= 1:29)
  android-libcutils-dev (>= 1:29)
  android-libziparchive-dev (>= 1:29)
android-platform-frameworks-base: android-libutils-dev (>= 1:29)
  android-libziparchive-dev (>= 1:29)
android-platform-system-extras: android-libbase-dev (>= 1:10.0.0+r36-1~)
android-libcutils-dev (>= 1:10.0.0+r36-1~)
android-libsparse-dev (>= 1:10.0.0+r36-1~)
android-platform-system-core-headers (>= 
1:10.0.0+r36-1~)
android-platform-system-tools-aidl: android-libbase-dev (>= 10.0.0+r36~)
android-libcutils-dev (>= 10.0.0+r36~)
android-platform-system-tools-hidl: android-libbase-dev (>= 1:10.0.0+r36~)
android-libcrypto-utils-dev (>= 
1:10.0.0+r36-3~)
android-liblog-dev (>= 1:10.0.0+r36~)
android-libutils-dev (>= 1:10.0.0+r36~)


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


  Thorsten

Bug#1015833: sbuild: would be helpful to be able to override the autopkgtest options

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Julian Gilbey (2022-09-18 18:54:10)
> On Wed, Sep 14, 2022 at 08:13:08AM +0200, Johannes Schauer Marin Rodrigues
> wrote:
> > Hi,
> > 
> > On Fri, 22 Jul 2022 08:25:25 +0100 Julian Gilbey  wrote:
> > > The sbuild(1) manpage says:
> > > 
> > >--autopkgtest-opt=options
> > >   Pass the specified option directly to autopkgtest in 
> > > addition to
> > >   the options already passed by sbuild. [...]
> > > 
> > > and similarly for --autopkgtest-opts.  However, my ~/.sbuildrc
> > > specifies default autopkgtest options, and I sometimes need to
> > > override those.  It would be very helpful if there was a command-line
> > > option to pass the specified options *instead of* the options already
> > > passed by sbuild, for example if I am building a package for a stable
> > > update.
> > > 
> > > The same applies for all of the autopkgtest related options, such as
> > > --autopkgtest-virt-server-opt.
> > 
> > which options are different if you are building for a stable update?
> 
> I have in my .sbuildrc:
> 
> $autopkgtest_opts = ['--apt-upgrade', '--', 'lxc', '-s', 
> 'autopkgtest-testing'];
> 
> For a stable update, I instead need
> 
> $autopkgtest_opts = ['--apt-upgrade', '--', 'lxc', '-s', 
> 'autopkgtest-stable'];

did you try putting the following into your ~/.sbuildrc:

$autopkgtest_opts = ['--apt-upgrade', '--', 'lxc', '-s', 'autopkgtest-%r'];

> But in general, the idea that it is impossible to override settings from a
> configuration file seems an unfortunate design choice.

That is correct. But letting sbuild run autopkgtest is also a bad design
choice. Since the $autopkgtest_opts are a list of options, it would also be bad
to let the command line options just replace what was already set. So then you
need some sort of interface that lets you add or remove arbitrary stuff. This
can become very complicated very fast. We can also not change this now because
sbuild is also heavily used from scripts that now rely on the existing
functionality.

If you just want to switch between stable and testing, consider using the %r
escape in your ~/.sbuildrc.

If you want to do more complex stuff, consider using the SBUILD_CONFIG
environment variable.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1006818: eye: (autopkgtest) failure on non-amd64

[Lev Lamberov]

Hi Jonas,

Вт 06 сен 2022 @ 16:10 Jonas Smedegaard :

> Quoting Lev Lamberov (2022-09-06 14:00:55)
>> Hi Jonas,
>> 
>> Сб 03 сен 2022 @ 21:19 Jonas Smedegaard :
>> 
>> >> The autopkgtest caught that the package is not functional on !amd64:
>> >> 
>> >> (buster_arm64-dchroot)bunk@amdahl:/tmp$ eye.pvm 
>> >> /usr/bin/eye.pvm: 3: exec: /usr/lib/swi-prolog/bin/x86_64-linux/swipl: 
>> >> not found
>> >> (buster_arm64-dchroot)bunk@amdahl:/tmp$ 
>> >> 
>> >> Changing Architecture: from "all" to "any" might be a reasonable option.
>> >
>> > In my understanding, this is a bug in SWI Prolog, in that when
>> > generating a so-called "intermediate code file" it embeds an
>> > arch-specific path to the interpreter instead of the arch-independent
>> > symlink in PATH: /usr/bin/swipl
>> >
>> > @Lev: What do you think?  Is it possible to patch SWI Prolog to embed an
>> > architecture-agnostic path for executing intermediary files?
>> 
>> SWI-Prolog supports three different pre-compiled formats: qlf, boot.prc,
>> and user created states. The first two do not include paths to the
>> interpreter. Looks like eye relies on the third one. I've asked upstream
>> about the possibility to embed an arch-independent path to such user
>> created states and got the answer that sometimes it is not a good idea,
>> because these states may differ due to conditional compilation. I've
>> looked into eye and looks like it does not (at least curretly, or I was
>> not able to spot it) use conditional compilation on various
>> architectures. So, I think it is probably save to embed arch-independent
>> path to the interpreter. SWI-Prolog upstream pushed a commit to support
>> this feature, but one should enable it explicitely with a command-line
>> option when running swipl to generate pre-compiled file of this kind
>> (like, swipl -o myexe --emulator=/usr/bin/swipl -c mycode.pl). I will
>> add this patch to the swi-prolog in Debian in the near future (probably,
>> I will have some time for it on the coming weekend, also I plan to
>> finish packaging a new upstream stable release, 8.4.3, where Debian is
>> at 8.4.2 at this point). I'll let you know when you can experiment with
>> eye concerning this change.
>
> Cool!  Thanks a lot!

Finally, I've just uploaded swi-prolog 8.4.3 including patch to allow
setting path to the interpreter.

Cheers!
Lev

Bug#1020244: fonts-urw-base35: A monospaced font shouldn't have ligatures

[Markus Hitter]

Package: fonts-urw-base35
Version: 20200910-4
Severity: important
X-Debbugs-Cc: m...@merchantsedition.com

Dear Maintainer,

* What led up to the situation?

Installing and using font Nimbus Mono in a programming oriented text
editor.

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

Type words which expose ligatures in font Nimbus Mono. For example
'office' or 'affected'.  Verified in Gedit and Geany.

* What was the outcome of this action?

Several characters, like 'ffi' or 'ff', get squeezed into the width of
a single character.  That's counterproductive, as the whole point of a
monospaced font is to use the same width for every character.

* What outcome did you expect instead?

Character sequences like 'ffi' to be three characters wide.  Character
sequences like 'ff' to be two characters wide.

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

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

Versions of packages fonts-urw-base35 depends on:
ii  xfonts-utils  1:7.7+6

fonts-urw-base35 recommends no packages.

Versions of packages fonts-urw-base35 suggests:
pn  fonts-freefont-otf | fonts-freefont-ttf  
pn  fonts-texgyre

-- no debconf information

Bug#1020243: debian-policy: Use OpenPGP instead of PGP

[Russ Allbery]

Guillem Jover  writes:

> Another minor patch I had laying around, switching references to the
> OpenPGP specification instead of to the specific PGP implementation.

Thanks, applied.

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

Bug#1020233: btrfs-progs: new upstream version

[Adam Borowski]

On Sun, Sep 18, 2022 at 05:58:01PM +0200, Christoph Anton Mitterer wrote:
> Package: btrfs-progs
> Version: 5.19-1

> There's a new 5.19.1 out which fixes amongst others an annyoing
> error message when checking a fs with free space chache v2.

Yeah I know; there's an udeb freeze at this moment, though.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#1018604: Missing chrome or resource URL: resource://gre/modules/UpdateListener.jsm

[Florian Kolter]

Hello,
 
the same bug affects firefox 104.0-1 and 104.0.2-1 (without esr).
 
Many sites/tabs crash firefox reproducibly.
What works is firefox --safe-mode. I found no other workaround or working 
config so far.
 
I get these errors, not sure if it is one error or a combination of two:
 
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
Missing chrome or resource URL: resource://gre/modules/UpdateListener.sys.mjs
ATTENTION: default value of option mesa_glthread overridden by environment.
Redirecting call to abort() to mozalloc_abort
ExceptionHandler::GenerateDump cloned child 2261888
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.

Best regards,
Florian

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Russ Allbery]

Russ Allbery  writes:

> I would happily apply a version of 0002 that only changes Files and
> leaves Copyright alone.

Or, perhaps even better, one that changes Copyright the way that you did,
but just adds an extra space.  I think that's the simplest compromise
between what you're trying to accomplish and the field definition.

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

Bug#1020240: Fwd: Re: gnome-terminal | error when using --profile as parameter (#7930)

[Michael Ott]

Bug fixed in gitlab

-- 
CU  
 
  Michael
  
-- 
    ,''`.   
   : :' :   Michael Ott 
   `. `'    e-mail: michael at k-c13 dot org
 `-

Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich derNutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--- Begin Message ---


Issue was closed by Christian Persch 
Issue #7930: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7930

-- 
Reply to this email directly or view it on GitLab: 
https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7930
You're receiving this email because of your account on gitlab.gnome.org.


--- End Message ---

Bug#1020243: debian-policy: Use OpenPGP instead of PGP

[Guillem Jover]

Package: debian-policy
Version: 4.6.1.1
Severity: minor
Tags: patch

Hi!

Another minor patch I had laying around, switching references to the
OpenPGP specification instead of to the specific PGP implementation.

Thanks,
Guillem
From 4dd6c1ef7c487fe2cd293e8fbddfdc898e0e9199 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 23 Dec 2021 07:11:55 +0100
Subject: [PATCH] Use OpenPGP instead of PGP

The standard is called OpenPGP, PGP instead is a specific
implementation. And while depending on the context (such as filename
extensions) using .pgp is better and more neutral than using some
other implementation specific extension (such as .gpg), in this context
the text refers to the generic OpenPGP signatures.
---
 policy/ch-controlfields.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index daff424..533abba 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -212,7 +212,7 @@ The fields in this file are:
 Debian source control files -- ``.dsc``
 ---
 
-This file consists of a single paragraph, possibly surrounded by a PGP
+This file consists of a single paragraph, possibly surrounded by an OpenPGP
 signature. The fields of that paragraph are listed below. Their syntax
 is described above, in :ref:`s-controlsyntax`.
 
@@ -261,7 +261,7 @@ Debian changes files -- ``.changes``
 
 The ``.changes`` files are used by the Debian archive maintenance
 software to process updates to packages. They consist of a single
-paragraph, possibly surrounded by a PGP signature. That paragraph
+paragraph, possibly surrounded by a OpenPGP signature. That paragraph
 contains information from the ``debian/control`` file and other data
 about the source package gathered via ``debian/changelog`` and
 ``debian/rules``.
-- 
2.37.2

Bug#1020242: wireplumber: volume on default sink is too high after waking from suspend

[Eric Cooper]

Package: wireplumber
Version: 0.4.11-5
Severity: normal

I'm not sure wireplumber is at fault here, but this has only started
happening since I switched from pulseaudio to pipewire a few days ago.
I usually have my default volume at about 30%, according to
pavucontrol. But when I wake my computer up after it suspends due to
inactivity, the volume is much higher, around 75%.

It doesn't happen when I manually suspend the computer though, at
least not when I wake it after a few seconds.

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

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

Versions of packages wireplumber depends on:
ii  init-system-helpers   1.64
ii  libc6 2.34-7
ii  libglib2.0-0  2.73.3-3
ii  libpipewire-0.3-0 0.3.57-1
ii  libwireplumber-0.4-0  0.4.11-5
ii  pipewire  0.3.57-1

Versions of packages wireplumber recommends:
ii  pipewire-pulse  0.3.57-1

Versions of packages wireplumber suggests:
pn  libspa-0.2-bluetooth  
pn  wireplumber-doc   

-- no debconf information

Bug#1019139: ITP: zpaqfranz -- Swiss army knife for backup and disaster recovery

[Stephen Kitt]

Hi,

On Tue, 13 Sep 2022 22:09:10 +0200, Bastian Germann  wrote:
> X-Debbugs-Cc: sk...@debian.org
> 
> On Sun, 04 Sep 2022 14:53:45 +0200 root  wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Franco Corbelli 
> > 
> > * Package name: zpaqfranz
> >   Version : 55.14
> >   Upstream Author : Franco Corbelli 
> > * URL : https://github.com/fcorbelli/zpaqfranz
> > * License : MIT
> >   Programming Lang: C, C++
> >   Description : Swiss army knife for backup and disaster recovery
> > 
> > Like 7z or RAR on steroids,with deduplicated "snapshots" (versions)
> > Conceptually similar to Mac time machine, but much more efficiently
> > Keeps backup always-to-always, no need to ever prune (CryptoLocker)
> > Easily handles millions of files and TBs of data, non-latin support
> > Cloud backups with full encryption, minimal data transfer/bandwidth
> > Data integrity check CRC32+XXHASH|SHA-1|SHA-2|SHA-3|MD5|XXH3|BLAKE3
> > Thorough data verification, multithread support (real world 1GB+/s)
> > Specific zfs handling functions,full multiplatform interoperability
> > Particularly suitable for minimal space storage of virtual machines
> > 
> > Windows, FreeBSD, OpenBSD, Linux, MacOS, Solaris, OmniOS and others
> > 
> > 
> > __
> > This is a fork of zpaq 7.15 (already in Debian) which was abandoned 
> > by the developer (Matt Mahoney) in 2016.  
> 
> As zpaqfranz is supposed to be a compatible replacement for zpaq,
> I suggest to make it the new upstream of the existing zpaq package.
> 
> Stephen, any opinions on this?

I agree, this should replace zpaq. In fact Franco Corbelli asked me about
this quite a while ago but I never looked into it in detail, sorry about that!

Franco, if you need help getting this into Debian, feel free to ping me, I’d
be happy to review and sponsor your package, or help you package zpaqfranz if
appropriate.

Regards,

Stephen


pgpV1cOha_4V7.pgp
Description: OpenPGP digital signature

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Russ Allbery]

Guillem Jover  writes:

> These are the set of changes I keep doing to the debian/copyright files
> I end up touching. While some could be characterized as a subjective
> style issue, I've tried to give as close as possibly objective :)
> rationale for every and each of the changes in the commit messages which
> I'll summarize here.

Thanks!  I have applied these changes for the next release except for
patch 0002 (applying wrap-and-sort -sat).

I agree with patch 0002 for Files, but unfortunately I believe it's
incorrect for Copyright.  You're treating Copyright as if it were a
line-based list field, but for better or worse (I think probably for
worse) the current specification says that it's a formatted field.  This
means that your change to, for example:

Copyright:
 2008 John Doe 
 2007 Jane Smith 
 2007 Joe Average 
 2007 J. Random User 

means that the semantic content of that field is now:

 2008 John Doe  2007 Jane Smith 
 2007 Joe Average  2007 J. Random User
 

and a format-aware display engine should show it as such.  This is the
reason why lines are indented: that makes them verbatim lines per the
formatting specification in
https://www.debian.org/doc/debian-policy/ch-controlfields#s-f-description

I would agree with changing the definition of Copyright to a line-based
list, although in order to do so we'd have to figure out the implications
of a format change in the specification, and we should also flesh out the
definition of a line-based list to explain how to handle a line that's
longer than the normal wrap length.

(In retrospect, I really regret not supporting YAML as the syntax for this
file.  I know YAML has a lot of problems, but it provides an unambiguous
representation of constructions like this, whereas deb822 has a lot of
gaps.)

I would happily apply a version of 0002 that only changes Files and leaves
Copyright alone.

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

Bug#1016262: vmmlib: FTBFS: hashtable.h:1208:18: error: expected unqualified-id before ‘(’ token

[Ying-Chun Liu (PaulLiu)]

Hi all.

Updated debdiff.

Thanks,
Paul
diff -Nru vmmlib-1.0/debian/changelog vmmlib-1.0/debian/changelog
--- vmmlib-1.0/debian/changelog 2021-01-02 09:15:59.0 +0800
+++ vmmlib-1.0/debian/changelog 2022-09-18 16:28:02.0 +0800
@@ -1,3 +1,14 @@
+vmmlib (1.0-2.3) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix FTBFS (Closes: #1016262)
+- Remove debian/patches/fix_ftbfs_gcc8.patch
+- Update debian/patches/fix-makefile to not use f2c related headers.
+- Add debian/patches/fix-quaternion.patch for not returning value in
+  void function.
+
+ -- Ying-Chun Liu (PaulLiu)   Sun, 18 Sep 2022 16:28:02 
+0800
+
 vmmlib (1.0-2.2) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru vmmlib-1.0/debian/patches/fix_ftbfs_gcc8.patch 
vmmlib-1.0/debian/patches/fix_ftbfs_gcc8.patch
--- vmmlib-1.0/debian/patches/fix_ftbfs_gcc8.patch  2018-10-29 
19:46:59.0 +0800
+++ vmmlib-1.0/debian/patches/fix_ftbfs_gcc8.patch  1970-01-01 
08:00:00.0 +0800
@@ -1,142 +0,0 @@
-Description: Fix FTBFS on gcc-8
- There are several build failed due to min/max/abs defined somewhere.
- We have to undef it to let it uses those from 
-Author: Ying-Chun Liu (PaulLiu) 
-Bug-Debian: https://bugs.debian.org/834472
-Last-Update: 2018-10-25
-Index: vmmlib-1.0/include/vmmlib/vector.hpp
-===
 vmmlib-1.0.orig/include/vmmlib/vector.hpp
-+++ vmmlib-1.0/include/vmmlib/vector.hpp
-@@ -1,6 +1,10 @@
- #ifndef __VMML__VECTOR__HPP__
- #define __VMML__VECTOR__HPP__
- 
-+#undef min
-+#undef max
-+#undef abs
-+
- #include 
- #include 
- #include 
-Index: vmmlib-1.0/include/vmmlib/quaternion.hpp
-===
 vmmlib-1.0.orig/include/vmmlib/quaternion.hpp
-+++ vmmlib-1.0/include/vmmlib/quaternion.hpp
-@@ -757,7 +757,7 @@ quaternion< T >::operator-=( const vecto
-   x() -= xyz.x();
-   y() -= xyz.y();
-   z() -= xyz.z();
--  return *this;
-+  //return *this;
- }
- 
- 
-Index: vmmlib-1.0/tests/tensor3_test.cpp
-===
 vmmlib-1.0.orig/tests/tensor3_test.cpp
-+++ vmmlib-1.0/tests/tensor3_test.cpp
-@@ -1,5 +1,9 @@
- #include "tensor3_test.hpp"
- 
-+#undef max
-+#undef min
-+#undef abs
-+
- #include 
- #include 
- 
-Index: vmmlib-1.0/tests/tucker3_tensor_test.cpp
-===
 vmmlib-1.0.orig/tests/tucker3_tensor_test.cpp
-+++ vmmlib-1.0/tests/tucker3_tensor_test.cpp
-@@ -1,5 +1,9 @@
- #include "tucker3_tensor_test.hpp"
- 
-+#undef min
-+#undef max
-+#undef abs
-+
- #include 
- #include 
- 
-Index: vmmlib-1.0/tests/qtucker3_tensor_test.cpp
-===
 vmmlib-1.0.orig/tests/qtucker3_tensor_test.cpp
-+++ vmmlib-1.0/tests/qtucker3_tensor_test.cpp
-@@ -1,4 +1,6 @@
- #include "qtucker3_tensor_test.hpp"
-+#undef min
-+
- #include 
- #include 
- 
-Index: vmmlib-1.0/tests/tucker3_exporter_importer_test.cpp
-===
 vmmlib-1.0.orig/tests/tucker3_exporter_importer_test.cpp
-+++ vmmlib-1.0/tests/tucker3_exporter_importer_test.cpp
-@@ -1,4 +1,5 @@
- #include "tucker3_exporter_importer_test.hpp"
-+#undef min
- #include 
- #include 
- #include 
-Index: vmmlib-1.0/tests/cp3_tensor_test.cpp
-===
 vmmlib-1.0.orig/tests/cp3_tensor_test.cpp
-+++ vmmlib-1.0/tests/cp3_tensor_test.cpp
-@@ -1,4 +1,5 @@
- #include "cp3_tensor_test.hpp"
-+#undef min
- #include 
- #include 
- #include 
-Index: vmmlib-1.0/tests/t3_hosvd_test.cpp
-===
 vmmlib-1.0.orig/tests/t3_hosvd_test.cpp
-+++ vmmlib-1.0/tests/t3_hosvd_test.cpp
-@@ -1,3 +1,4 @@
-+#undef min
- #include "t3_hosvd_test.hpp"
- #include "vmmlib/t3_hosvd.hpp"
- 
-Index: vmmlib-1.0/tests/t3_hooi_test.cpp
-===
 vmmlib-1.0.orig/tests/t3_hooi_test.cpp
-+++ vmmlib-1.0/tests/t3_hooi_test.cpp
-@@ -1,3 +1,4 @@
-+#undef min
- #include "t3_hooi_test.hpp"
- #include "vmmlib/t3_hooi.hpp"
- 
-Index: vmmlib-1.0/tests/t3_hopm_test.cpp
-===
 vmmlib-1.0.orig/tests/t3_hopm_test.cpp
-+++ vmmlib-1.0/tests/t3_hopm_test.cpp
-@@ -1,3 +1,4 @@
-+#undef min
- #include "t3_hopm_test.hpp"
- #include "vmmlib/t3_hopm.hpp"
- #include 
-Index: vmmlib-1.0/tests/t3_ihopm_test.cpp
-===
 vmmlib-1.0.orig/tests/t3_ihopm_test.cpp
-+++ vmmlib-1.0/tests/t3_ihopm_test.cpp
-@@ -1,3 +1,4 @@
-+#undef min
- #include "t3_ihopm_test.hpp"
- #include "vmmlib/t3_ihopm.hpp"
- #include 
-Index: vmmlib-1.0/Makefile

Bug#1020240: gnome-terminal: error when using --profile as parameter

[Michael Ott]

Hi Jeremy!

> Do you mean it works with 3.45.90-1?
Exately.

> https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues
And I will do it

CU
  Michael

> Control: tags -1 +upstream
> 
> On Sun, Sep 18, 2022 at 12:57 PM Michael Ott  wrote:
> > It works with previous version
> 
> Do you mean it works with 3.45.90-1?
> 
> Could you report this upstream?
> 
> https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues
> 
> Thank you,
> Jeremy Bicha
CU  
 
  Michael
  
-- 
,''`.   
   : :' :   Michael Ott 
   `. `'e-mail: michael at k-c13 dot org
 `-

Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#1019542: reverse dependencies

[Thorsten Alteholz]

Hi Roland,

On 18.09.22 18:48, Roland Rosenfeld wrote:
For the records here are the bug reports I filed: 


great, thanks for doing this and thanks for the explanations.

  Thorsten

Bug#1020238: debian-policy: Spacing an typographical cleanups

[Russ Allbery]

Guillem Jover  writes:

> I'm attaching a few patches fixing spacing and typographical issues.
> For the quotes fix, I personally highly prefer UTF-8 character pairs
> such as «», “”, ‘’, but went with the conservative ASCII ones '' as that
> tends to cause less opposition. But I'm happy to convert these to some
> of the UTF-8 ones if you prefer.

Thank you!  Applied for the next release.

I have a minor bias against the UTF-8 quotes only because they're more
annoying to type with a typical US keyboard, while agreeing that they're
typographically more correct.

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

Bug#1020082: scons: FTBFS: make: *** [debian/rules:10: binary] Error 25

[Mats Wichmann]

On Sun, 18 Sep 2022 09:38:58 -0700 Bill Deegan 
 wrote:

SCons 4.0.1 is fairly old and doesn't seem to be compatible with Python
3.10.
The latest SCons 4.4.0 is available and works fine with Python 3.10



> The full build log is available from:
> http://qa-logs.debian.net/2022/09/17/scons_4.0.1+dfsg-2_unstable.log


Specifically, the ActionTests.py unittest file tests for 
version-specific bytecode strings, so newer Pythons that an SCons 
version does not know about will always fail that specific test. Current 
SCons 4.4 understands through Python 3.11.

Bug#965041: [Pkg-openssl-devel] Bug#965041: Bug#965041: libssl3: Please stop building legacy provider

[Sebastian Andrzej Siewior]

On 2020-07-16 08:46:43 [+0200], Kurt Roeckx wrote:
> On Thu, Jul 16, 2020 at 03:57:17AM +0100, Dimitri John Ledkov wrote:
> > 
> > openssl package could ship `.include /etc/ssl/providers.d/` in ssl.conf.
> 
> That would actually make sense.
> 
> We could use the include thing to ship a config file for the
> fips module with the correct hash in it.

Kurt, what do we do here?
Split /usr/lib/*/ossl-modules/legacy.so into its own package which is
part of src:openssl and adds a config snippet.

> Kurt

Sebastian

Bug#1020240: gnome-terminal: error when using --profile as parameter

[Jeremy Bicha]

Control: tags -1 +upstream

On Sun, Sep 18, 2022 at 12:57 PM Michael Ott  wrote:
> It works with previous version

Do you mean it works with 3.45.90-1?

Could you report this upstream?

https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues

Thank you,
Jeremy Bicha

Bug#1020082: scons: FTBFS: make: *** [debian/rules:10: binary] Error 25

[GCS]

Control: tags -1 +pending

On Sun, Sep 18, 2022 at 6:42 PM Bill Deegan  wrote:
> SCons 4.0.1 is fairly old and doesn't seem to be compatible with Python 3.10.
> The latest SCons 4.4.0 is available and works fine with Python 3.10
 Indeed, the update is long overdue. Will try to do that tomorrow.

Regards,
Laszlo/GCS

Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes

[Guillem Jover]

Package: debian-policy
Version: 4.6.1.1
Severity: wishlist
Tags: patch

Hi!

These are the set of changes I keep doing to the debian/copyright
files I end up touching. While some could be characterized as a
subjective style issue, I've tried to give as close as possibly
objective :) rationale for every and each of the changes in the
commit messages which I'll summarize here.

The main drive is for uniformity in formatting (compared to the
recommended GPL notice example), minimization of diff delta on changes
(the same we seem to be converging with wrap-and-sort -sat), making
the notice future-proof (by using an URL instead of a postal address),
and moving the Debian-specific filesystem location reference into a
Comment to not confuse with the actual upstream/in-code notice. Then
there's the placement of the Source field, which I guess is the
possibly more style/subjective one, but that's one that seems to also
be triggering some OCDish button or similar. :)

This change was implemented on top of the spacing and typographical
patches and seems to depend on changes in there.

Thanks,
Guillem
From 600aabb1a2235396db5fce4240ac0751258fcf7f Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 18 Sep 2022 18:05:57 +0200
Subject: [PATCH 1/6] copyright-format: Place Source field after Format field

These both contain URLs, are the most important references, and nicely
align, so it's nice to get them as early as possible in the file.
---
 copyright-format-1.0.xml | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/copyright-format-1.0.xml b/copyright-format-1.0.xml
index d29c490..3d5c672 100644
--- a/copyright-format-1.0.xml
+++ b/copyright-format-1.0.xml
@@ -271,9 +271,9 @@
   
 Example header paragraph
 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Source: https://www.example.com/software/project
 Upstream-Name: SOFTware
-Upstream-Contact: John Doe john@example.com
-Source: https://www.example.com/software/project
+Upstream-Contact: John Doe john@example.com
   
 
 
@@ -1265,8 +1265,8 @@ also delete it here.
 package):
 
   
 
@@ -1339,10 +1329,9 @@ Files:
 Copyright:
  2008 Dan Developer 
 License: permissive
- Copying and distribution of this package, with or without
- modification, are permitted in any medium without royalty
- provided the copyright notice and this notice are
- preserved.
+ Copying and distribution of this package, with or without modification,
+ are permitted in any medium without royalty provided the copyright notice
+ and this notice are preserved.
 
 Files:
  debian/patches/theme-diveintomark.patch
@@ -1380,26 +1369,22 @@ License: PSF-2
  [LICENSE TEXT]
 
 License: GPL-2+
- This program is free software; you can redistribute it
- and/or modify it under the terms of the GNU General Public
- License as published by the Free Software Foundation; either
- version 2 of the License, or (at your option) any later
- version.
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
  .
- This program is distributed in the hope that it will be
- useful, but WITHOUT ANY WARRANTY; without even the implied
- warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
- PURPOSE.  See the GNU General Public License for more
- details.
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
  .
- You should have received a copy of the GNU General Public
- License along with this package; if not, write to the Free
- Software Foundation, Inc., 51 Franklin St, Fifth Floor,
- Boston, MA  02110-1301 USA
+ You should have received a copy of the GNU General Public License along
+ with this package; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA.
  .
- On Debian systems, the full text of the GNU General Public
- License version 2 can be found in the file
- '/usr/share/common-licenses/GPL-2'.]]>
+ On Debian systems, the full text of the GNU General Public License
+ version 2 can be found in the file '/usr/share/common-licenses/GPL-2'.]]>
   
 
   
diff --git a/debian/copyright b/debian/copyright
index eef116a..d80be52 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -99,15 +99,15 @@ Copyright:
 License: GPL-2+
 
 License: GPL-2+
- This manual is free software; you may redistribute it and/or modify it
- under the terms of the GNU General Public License as published by the
- Free Software Foundation; either version 2 of the License, or (at your
- option) any later version.
+ This manual is free software; you may redistribute it and/or modify
+ it under the terms of the GNU 

Bug#1015833: sbuild: would be helpful to be able to override the autopkgtest options

[Julian Gilbey]

Hi Josch,

On Wed, Sep 14, 2022 at 08:13:08AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Hi,
> 
> On Fri, 22 Jul 2022 08:25:25 +0100 Julian Gilbey  wrote:
> > The sbuild(1) manpage says:
> > 
> >--autopkgtest-opt=options
> >   Pass the specified option directly to autopkgtest in addition 
> > to
> >   the options already passed by sbuild. [...]
> > 
> > and similarly for --autopkgtest-opts.  However, my ~/.sbuildrc
> > specifies default autopkgtest options, and I sometimes need to
> > override those.  It would be very helpful if there was a command-line
> > option to pass the specified options *instead of* the options already
> > passed by sbuild, for example if I am building a package for a stable
> > update.
> > 
> > The same applies for all of the autopkgtest related options, such as
> > --autopkgtest-virt-server-opt.
> 
> which options are different if you are building for a stable update?

I have in my .sbuildrc:

$autopkgtest_opts = ['--apt-upgrade', '--', 'lxc', '-s', 'autopkgtest-testing'];

For a stable update, I instead need

$autopkgtest_opts = ['--apt-upgrade', '--', 'lxc', '-s', 'autopkgtest-stable'];

But in general, the idea that it is impossible to override settings
from a configuration file seems an unfortunate design choice.

Best wishes,

   Julian

Bug#1020240: gnome-terminal: error when using --profile as parameter

[Michael Ott]

Package: gnome-terminal
Version: 3.46.1-1
Severity: important

Dear Maintainer,

Running gnome-terminal from konsole:
gnome-terminal --profile=additional

Error messages:
# TerminalSettingsList* terminal_settings_list_new(GSettingsBackend*, 
GSettingsSchemaSource*, const char*, const char*, const char*, 
TerminalSettingsListFlags): assertion 'schema_source != nullptr' failed
# char** terminal_settings_list_dupv_children(TerminalSettingsList*): assertion 
'TERMINAL_IS_SETTINGS_LIST (list)' failed
# g_strv_length: assertion 'str_array != NULL' failed
# Profile 'additional' specified but not found. Attempting to fall back to the 
default profile.
# TerminalSettingsList* terminal_settings_list_new(GSettingsBackend*, 
GSettingsSchemaSource*, const char*, const char*, const char*, 
TerminalSettingsListFlags): assertion 'schema_source != nullptr' failed
# char* terminal_settings_list_dup_default_child(TerminalSettingsList*): 
assertion 'TERMINAL_IS_SETTINGS_LIST (list)' failed
# char** terminal_settings_list_dupv_children(TerminalSettingsList*): assertion 
'TERMINAL_IS_SETTINGS_LIST (list)' failed
# g_strv_length: assertion 'str_array != NULL' failed
# Failed to parse arguments: No profile with UUID or name "(null)" exists
michael@k-c13:~$ gnome-terminal --profile=additional
# TerminalSettingsList* terminal_settings_list_new(GSettingsBackend*, 
GSettingsSchemaSource*, const char*, const char*, const char*, 
TerminalSettingsListFlags): assertion 'schema_source != nullptr' failed
# char** terminal_settings_list_dupv_children(TerminalSettingsList*): assertion 
'TERMINAL_IS_SETTINGS_LIST (list)' failed
# g_strv_length: assertion 'str_array != NULL' failed
# Profile 'additional' specified but not found. Attempting to fall back to the 
default profile.
# TerminalSettingsList* terminal_settings_list_new(GSettingsBackend*, 
GSettingsSchemaSource*, const char*, const char*, const char*, 
TerminalSettingsListFlags): assertion 'schema_source != nullptr' failed
# char* terminal_settings_list_dup_default_child(TerminalSettingsList*): 
assertion 'TERMINAL_IS_SETTINGS_LIST (list)' failed
# char** terminal_settings_list_dupv_children(TerminalSettingsList*): assertion 
'TERMINAL_IS_SETTINGS_LIST (list)' failed
# g_strv_length: assertion 'str_array != NULL' failed
# Failed to parse arguments: No profile with UUID or name "(null)" exists

It works with previous version






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

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

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


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (710, 'unstable'), (670, 'testing'), (660, 'experimental'), (600, 
'stable'), (500, 'stable-security'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.99~git20220715-1
ii  dbus-x11 [dbus-session-bus]   1.14.99~git20220715-1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-3
ii  gnome-terminal-data   3.46.1-1
ii  gsettings-desktop-schemas 43~rc.1-1
ii  libatk1.0-0   2.46.0-1
ii  libc6 2.35-0experimental3
ii  libgcc-s1 12.2.0-2
ii  libglib2.0-0  2.73.3-3
ii  libgtk-3-03.24.34-3
ii  libpango-1.0-01.50.10+ds-1
ii  libstdc++612.2.0-2
ii  libuuid1  2.38.1-1
ii  libvte-2.91-0 0.70.0-1
ii  libx11-6  2:1.8.1-2

Versions of packages gnome-terminal recommends:
ii  gvfs   1.50.2-2
ii  nautilus-extension-gnome-terminal  3.46.1-1
ii  yelp   42.1-2

gnome-terminal suggests no packages.

-- no debconf information

Bug#1019542: reverse dependencies

[Roland Rosenfeld]

Hi,

> > Checking reverse dependencies...
> > # Broken Depends:
> > inventor: libinventor1
> > pokerth: pokerth-data
> >
> > # Broken Build-Depends:
> > gcc-3.3: gsfonts-x11
> 
> I'll file bug reports against these three packages, requesting to
> replace the dependency on gsfonts-x11 with one on fonts-urw-base35 (or
> some alternative to both of them).

For the records here are the bug reports I filed:

libinventor1: #1020236
pokerth-data: #1020237
gcc-3.3: #1020239

Greetings
Roland

Bug#1020224: grub2 2.06-3~deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1020224 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: grub2
Version: 2.06-3~deb11u2

Explanation: don't strip Xen binaries so they work again

Bug#1020239: gcc-3.3: build-depends on gsfonts-x11 should be replaced by fonts-urw-base35

[Roland Rosenfeld]

Source: gcc-3.3
Version: 1:3.3.6ds1-34
Severity: normal

Dear Maintainer,

we are currently removing the old gsfonts-x11 package and replace it
by fonts-urw-base35, which contains the real fonts (replaces gsfonts)
as well as the symlinks and fonts.scale/fonts.alias voodoo, which is
needed for using the fonts in X11.

Your source package gcc-3.3 currently Build-Depends on gsfonts-x11.
It would be a good idea to change this dependency to fonts-urw-base35
(or for backward compatibility to fonts-urw-base35 | gsfonts-x11).
For the release of bookworm this shouldn't be a problem, since we ship
a dummy package gsfonts-x11 depending on fonts-urw-base35, but it
would be a good idea to change the dependency anyway soon.

Except this, I'm curious, what this Build-Depends is good for at all.
The package gsfonts-x11 doesn't ship fonts itself but depends on the
gsfonts package (shipping Type1 fonts) and makes them available to
X11.  From my point of view this is only useful for some desktop
environment using X11 but should not be used in Build-Depends.

Greetings
Roland