Bug#1069465: marked as pending in libeatmydata
Control: tag -1 pending Hello, Bug #1069465 in libeatmydata reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/libeatmydata/-/commit/8e4f521eeb66bcd581b519a8673327f6d07431f1 Add patch to fix FTBFS on 32 bits with a t64 env Closes: #1069465 Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/1069465
Bug#1038910: marked as pending in licenseutils
Control: tag -1 pending Hello, Bug #1038910 in licenseutils reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/licenseutils/-/commit/62bfbf1c06e8d0325a58ccf4845c551281f68915 Switch to libcurl4-nss-dev (Closes: #1038910) (this message was generated automatically) -- Greetings https://bugs.debian.org/1038910
Bug#1036959: rasdaemon: invalid Maintainer field
Source: rasdaemon Version: 0.6.8-1 Severity: serious v0.6.8-1 of this package has this in d/control: Maintainer: Russell Coker , Taihsiang Ho This is against Policy as there should only be one entity in this field. Also, as you noticed, this confused DDPO (actually carnivore) a lot... -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1031297: marked as pending in diffoscope
Control: tag -1 pending Hello, Bug #1031297 in diffoscope reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/reproducible-builds/diffoscope/-/commit/61f7c2b394c9134ee0f280a65a8e2efa97ee58c4 autopkgtest: only install appt and dexdump on architectures where they are available Closes: #1031297 Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/1031297
Bug#1022731: marked as pending in inkscape
Control: tag -1 pending Hello, Bug #1022731 in inkscape reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/multimedia-team/inkscape/-/commit/85111214dbea5476906d9512f48d9422fac40790 Skip 4 tests that are known to fail, but it should be fine. Closes: #1022731 Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/1022731
Bug#1012572: android-platform-frameworks-base: FTBFS with protobuf 3.20.1+
Hello Roger,
On Fri, Jun 10, 2022 at 09:48:06PM +0900, Roger Shimizu wrote:
> I tried your patch by installing protobuf in experimental
> and confirmed it builds well, and all tests are also OK.
> Will upload after protobuf 3.20 (or later) hits unstable.
> Thanks for your support!
You uploaded this patch to experimental, however I see no sign of v13 to
be uploaded to unstable anytime soon.
Can you please apply this same patch also in unstable?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1012818: inkscape: Please update for Poppler 22.06
On Fri, Sep 30, 2022 at 12:49:29PM +0200, Mattia Rizzolo wrote: > On Thu, Sep 29, 2022 at 08:03:26PM +0200, Miroslav Kratochvil wrote: > > > Oh, inkscape 1.2.1 does build with the latest poppler > > > > Hi all, > > I recently noticed that inkscape (1.1.2-3+b1 from testing) crashes when > > opening any PDF files; quick debug showing that the crash happens in > > poppler. My best-guess reason now is because the binary actually loads 2 > > different versions of poppler. > > I'm about (=> during the day) to upload to unstable 1.2.1+really1.1.2-1, > reverting 1.2.x back to 1.1.x. Or so I thought, but i get other extra test failures now… (both with 1.1.2 and 1.2.1), so I guess this is not happening today :( -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1020091: marked as pending in diffoscope
Control: tag -1 pending Hello, Bug #1020091 in diffoscope reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/reproducible-builds/diffoscope/-/commit/2f2d803f989082d5701576871e9c300a5126f78d Use pep517 and pip to load the requirements this is somewhat hacky. Probably a better solution for the future is to move to pyproject.toml instead of setup.py, and parse that here. Closes: #1020091 Gbp-Dch: Short Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/1020091
Bug#1012987: marked as pending in libpodofo
Control: tag -1 pending Hello, Bug #1012987 in libpodofo reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/libpodofo/-/commit/4523284f7c2d19a81351ae6b35947acd499c4c07 Fix declaration of operator<< for PoDoFo::PdfString (Closes: #1012987) (this message was generated automatically) -- Greetings https://bugs.debian.org/1012987
Bug#1012987: libpodofo: ftbfs with GCC-12
Hello,
On Mon, Jul 25, 2022 at 10:45:49PM +0900, yokota wrote:
> Hello Debian libpodofo maintainer,
> I maintain Debian Calibre which uses libpodofo.
>
> I make FTBFS fix to Debian libpodofo at:
> https://salsa.debian.org/debian/libpodofo/-/merge_requests/2
>
> Please examine this merge request.
I saw it and I'm leaning towards rejecting that patch.
See also me asking upstream for a real patch here:
https://sourceforge.net/p/podofo/mailman/podofo-users/thread/Yt0dvCmE/ISNNwI3%40mapreri.org/#msg37684942
At the very least, I'd prefer fedora's patch better since it disable
specific tests and not the whole file the failing test lives in…
But I really don't like either.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1012496: inkscape: FTBFS on arm64, ppc64el, s390x
Source: inkscape Version: 1.2-1 Severity: serious Tags: ftbfs Forwarded: https://gitlab.com/inkscape/inkscape/-/issues/3554 https://buildd.debian.org/status/fetch.php?pkg=inkscape=arm64=1.2-1=1653329867=0 https://buildd.debian.org/status/fetch.php?pkg=inkscape=ppc64el=1.2-1=1653326620=0 https://buildd.debian.org/status/fetch.php?pkg=inkscape=s390x=1.2-1=165123=0 signature.asc Description: PGP signature
Bug#1011626: Nearly no icons since several releases
Control: severity -1 minor On Wed, May 25, 2022 at 02:25:21PM +0100, Klaus Ethgen wrote: > Severity: grave Hardly. Please don't over-inflate severities. > Since several time, incscape has the same icon for most functions what > makes it nearly impossible to find a function. (See screenshot) > > The error is the same than in gimp for several times. > > With gimp I found that it is the missing png icons. There are only svg > icons left what seems to be not possible to use in GTK. That's clearly untrue, this is actually the first time I heard of such problem. GTK can handle SVG icons just fine. > ii librsvg2-common2.52.5+dfsg-3+b1 This package is required to render SVG icons, so it's good you at least have it, even if it's a version that doesn't match the current one. Regardless, please try running: /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders and verify that you have a section such as this: "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so" "svg" 6 "gdk-pixbuf" "Scalable Vector Graphics" "LGPL" "image/svg+xml" "image/svg" "image/svg-xml" "image/vnd.adobe.svg+xml" "text/xml-svg" "image/svg+xml-compressed" "" "svg" "svgz" "svg.gz" "" " https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1010526: [xml/sgml-pkgs] Bug#1010526: libxml2: CVE-2022-29824: integer overflows in xmlBuf and xmlBuffer
On Tue, May 03, 2022 at 05:43:50PM +0200, Salvatore Bonaccorso wrote:
> CVE-2022-29824[0]:
> | In libxml2 before 2.9.14,
I'm uploading 2.9.14 in a few minutes, taking care of this for unstable
and bookworm, but if you believe this bug deserves to be fixed through
-security, I'd ask if you can take care of that yourselves.
Otherwise I'll submit a pu next week.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1010276: [Debian-med-packaging] Bug#1010276: parasail: compiles something extra (or less) depending on the CPU features available
On Sun, May 01, 2022 at 10:50:16AM +0200, Étienne Mollier wrote:
> Upstream implements run time
> CPU detection to avoid baseline violation on older CPU.
Great! Thank you for confirming this bit. I figured it might be the
case, but I didn't verify it myself (as I noted in my first email).
> So I identified three todo items:
> 1. address reproducibility issue likely caused by find|head;
Note that `sort` is locale dependant, so if that's really the proper way
to do it (tbh doing find|head feels *very* brittle to me… it's probably
better if you can think of a better way to achieve whatever that piece
of code is doing), remember to prepend LC_ALL=C.UTF-8 to the sort call.
> 2. fix avx512 support for amd64 architecture;
> 3. disable execessive build artifacts for i386 architecture.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1010276: parasail: compiles something extra (or less) depending on the CPU features available
Source: parasail
Version: 2.5+dfsg-3
Severity: serious
User: reproducible-bui...@lists.alioth.debian.org
Usertags: cpu
Hi!
While working on the “reproducible builds” effort [1], we have noticed
that your package "parasail" doesn't build reproducibly.
In fact, it seems that depending on the type of CPU it builds on,
sometimes there are slightly different files. For example, on an i386
system:
- usr/lib/i386-linux-gnu/libparasail_novec_table.a
- usr/lib/i386-linux-gnu/libparasail_sse41_rowcol.a
- usr/lib/i386-linux-gnu/libparasail_avx2_table.a
or in an amrhf system:
- usr/lib/arm-linux-gnueabihf/libparasail_novec.a
- usr/lib/arm-linux-gnueabihf/libparasail_novec_rowcol.a
sometimes are there or not.
I'll have to remember you that building differently depending on the CPU
features of the build host is not allowed by Policy.
Furthermore, I notice that amongst the i386 build, there are files such
as
- usr/lib/i386-linux-gnu/libparasail_sse2.a
- usr/lib/i386-linux-gnu/libparasail_sse41.a
that makes me wonder if the program is unconditially using SSE
instructions on i386, that would be a baseline violation; but since I
haven't verified if those features are used unconditially I'm not filing
this report about this, however please do check.
[1]: https://wiki.debian.org/ReproducibleBuilds
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#935088: giflib: diff for NMU version 5.2.1-2.2
Control: tags 935088 + patch Control: tags 935088 + pending Dear maintainer, I've prepared an NMU for giflib (versioned as 5.2.1-2.2) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- diffstat for giflib-5.2.1 giflib-5.2.1 changelog |9 + libgif7.symbols |1 + patches/giflib_quantize.patch | 22 ++ patches/series|1 + 4 files changed, 33 insertions(+) diff -Nru giflib-5.2.1/debian/changelog giflib-5.2.1/debian/changelog --- giflib-5.2.1/debian/changelog 2021-06-07 14:41:34.0 +0200 +++ giflib-5.2.1/debian/changelog 2022-04-14 16:06:15.0 +0200 @@ -1,3 +1,12 @@ +giflib (5.2.1-2.2) experimental; urgency=medium + + * Non-maintainer upload. + * Add patch from Fedora (giflib_quantize.patch) to reinstate +GifQuantizeBuffer into giflib.so. Closes: #935088 + * Re-add the symbols in libgif7.symbols. + + -- Mattia Rizzolo Thu, 14 Apr 2022 16:06:15 +0200 + giflib (5.2.1-2.1) experimental; urgency=medium * Non-maintainer upload. diff -Nru giflib-5.2.1/debian/libgif7.symbols giflib-5.2.1/debian/libgif7.symbols --- giflib-5.2.1/debian/libgif7.symbols 2019-08-18 11:55:51.0 +0200 +++ giflib-5.2.1/debian/libgif7.symbols 2022-04-14 16:06:15.0 +0200 @@ -54,6 +54,7 @@ GifFreeSavedImages@Base 5.1 GifMakeMapObject@Base 5.1 GifMakeSavedImage@Base 5.1 + GifQuantizeBuffer@Base 5.1 GifUnionColorMap@Base 5.1 _ClearHashTable@Base 5.1 _ExistsHashTable@Base 5.1 diff -Nru giflib-5.2.1/debian/patches/giflib_quantize.patch giflib-5.2.1/debian/patches/giflib_quantize.patch --- giflib-5.2.1/debian/patches/giflib_quantize.patch 1970-01-01 01:00:00.0 +0100 +++ giflib-5.2.1/debian/patches/giflib_quantize.patch 2022-04-14 16:05:56.0 +0200 @@ -0,0 +1,22 @@ +Description: Move quantize.c back into libgif.so +Origin: other, fedora https://src.fedoraproject.org/rpms/giflib/c/109bf038d703a471b857aba44af673be103d7079 +Bug: https://sourceforge.net/p/giflib/bugs/142/ +Bug-Debian: https://bugs.debian.org/935088 + +diff -rupN giflib-5.2.1/Makefile giflib-5.2.1-new/Makefile +--- giflib-5.2.1/Makefile 2019-06-24 18:08:57.0 +0200 giflib-5.2.1-new/Makefile 2019-10-01 13:02:33.227952230 +0200 +@@ -29,11 +29,11 @@ LIBPOINT=0 + LIBVER=$(LIBMAJOR).$(LIBMINOR).$(LIBPOINT) + + SOURCES = dgif_lib.c egif_lib.c gifalloc.c gif_err.c gif_font.c \ +- gif_hash.c openbsd-reallocarray.c ++ gif_hash.c openbsd-reallocarray.c quantize.c + HEADERS = gif_hash.h gif_lib.h gif_lib_private.h + OBJECTS = $(SOURCES:.c=.o) + +-USOURCES = qprintf.c quantize.c getarg.c ++USOURCES = qprintf.c getarg.c + UHEADERS = getarg.h + UOBJECTS = $(USOURCES:.c=.o) + diff -Nru giflib-5.2.1/debian/patches/series giflib-5.2.1/debian/patches/series --- giflib-5.2.1/debian/patches/series 2019-08-25 18:10:35.0 +0200 +++ giflib-5.2.1/debian/patches/series 2022-04-14 16:06:08.0 +0200 @@ -1 +1,2 @@ 30_link_utils_dynamically.diff +giflib_quantize.patch signature.asc Description: PGP signature
Bug#1006132: ifrench-gut: please stop build-depending on myspell-tools
Hi,
On Thu, Feb 24, 2022 at 01:51:58PM +0100, Agustin Martin wrote:
> I also wonder how relevant is myspell-fr-gut compared to
> hunspell-fr-classical, hunspell-fr-comprehensive and
> hunspell-fr-revised. If it is no longer needed it could be made a
> transitional package to hunspell-fr making this particular problem
> disappear (although not others).
That's probably for the best.
And if we go that way we should file a bug against firefox-l10-fr (and
firefox-esr and thunderbird) to change their Recommends.
But what about the ispell dictionary? src:ifrench provides a Quebec's
variant, that I can't believe to be similar to the GUTemberg variant,
even with me not knowing a single word of French.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#287371: [xml/sgml-pkgs] Bug#287371: xsltproc: Probable memory leak (when using document()?)
On Thu, Feb 10, 2022 at 01:08:33PM +0100, Vincent Lefevre wrote:
> This is no different than CVE-2013-0338 and CVE-2013-0339[*]. The
> point is that from a small document, one can exhaust the memory
> of the machine. CVE-2013-0338 and CVE-2013-0339 are about entity
> expansion, but there are the same consequences with just loading
> data in memory.
>
> [*] https://www.openwall.com/lists/oss-security/2013/02/22/3
If you believe so, and you confirmed that it hasn't been fixed in the
past 15 years, could you please either (or both):
* report it to mitre's CVE form
* report it in https://gitlab.gnome.org/GNOME/libxml2/-/issues
?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1006134: myspell: do not ship with bookworm
Source: myspell Version: 1:3.0+pre3.1-24.2 Severity: serious Tags: bookworm sid Control: block -1 by 1006131 1006132 We don't want to release myspell with bookworm. The only 2 packages that Build-Depends on myspell-tools are marked as blockers. Anything else that I found only uses myspell-tools as an alternative where hunspell-tools is preferred first. Since there are only 2 rev deps, we'd rather not introduce transitional packages or such (as suggested in #898746). This bug will become an RM bug soon, possibly after the above blockers are fixed. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1006132: ifrench-gut: please stop build-depending on myspell-tools
Source: ifrench-gut
Version: 1:1.0-32.1
Severity: serious
Dear maintainer,
we plan to remove src:myspell really soon, and together with it also
the package "myspell-tools".
Your package still depends on it.
Please see whether you can move whatever the package is doing to
hunspell-tools, or otherwise please tell us src:hunspell maintainers how
that is not possible for you.
Thank you for maintaining ifrench-gut.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1006131: rus-ispell: please stop build-depending on myspell-tools
Source: rus-ispell
Version: 0.99g5-27
Severity: serious
Dear maintainer,
we plan to remove src:myspell really soon, and together with it also
the package "myspell-tools".
Your package still depends on it.
Please see whether you can move whatever the package is doing to
hunspell-tools, or otherwise please tell us src:hunspell maintainers how
that is not possible for you.
Thank you for maintaining rus-ispell.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#997359: marked as pending in inkscape
Control: tag -1 pending Hello, Bug #997359 in inkscape reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/multimedia-team/inkscape/-/commit/22960b0b09d0f476a93f98e1ff90f5114ace8dec Add patch from upstream to fix a crash when inkscape is run with --batch and a gui is not available Closes: #997359 Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/997359
Bug#1002532: pygments breaks ruby-pygments.rb autopkgtest: UTF-8 != ASCII-8BIT
On Fri, Jan 21, 2022 at 03:51:02PM +0100, Alexandre Ghiti wrote:
> I can't find how to create a MR in salsa, can you pull directly from here:
>
> https://salsa.debian.org/alexghiti/ruby-pygments.rb/-/tree/int/alex/2.3.0
>
> It successfully built in my PPA, if you need any more modification, do
> not hesitate.
Ah, another thing. Please be careful with the version you pick.
You used 2.3.0+ds-1ubuntu1, which is *higher* than what I'll be
uploading, namely 2.3.0+ds-1.
Furthermore, in your PPA you used 2.3.0+ds-1ubuntu2, which would also
conflict with an eventual -1ubuntu done in the offical ubuntu archive.
I'd recommend you used something like -0ppa1 or -0ubuntu1~ppa1 or
somesuch.
(in this case this is of no consequence, but just something to note).
Lastly, I noticed that you haven't even touched the changelog. In this
case there was even a new copyright holder, so it really should have
been updated.
I didn't add you to the paragraph of d/copyright, as I assume you are
doing this under your paid time, and I don't know what's Canonical's
rules regarding copyright here. If needed/wanted, just send me a note
and I'll update the copy in git.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1002532: pygments breaks ruby-pygments.rb autopkgtest: UTF-8 != ASCII-8BIT
Hi Alex! Please take note that the Debian BTS doesn't subscribe automatically posters to a bug report, so you need to explicitly CC people that you want to message! (Grahm pointed me to your reply ^^) Also, I'm happy to have pointed out to tools and things you weren't aware of! :) On Fri, Jan 21, 2022 at 03:51:02PM +0100, Alexandre Ghiti wrote: > On Fri, 21 Jan 2022 12:08:27 +0100 Alexandre Ghiti > wrote: > > On Thu, 20 Jan 2022 18:50:33 +0100 Mattia Rizzolo wrote: > > > * You did a ton of patch wrangling, including deletion, renaming, > > > rebasing, etc. which is all fine, except that the way you did it > > > obscures quite a bit what you did. Why did you drop the numbers from > > > the patches? Do you have --no-patch-numbers as you gbp-pq default or > > > something? > > > > I changed the patches names since they were different: I fixed that in > > my coming MR. Thanks for gbp that I did not know neither. Indeed, those patches from before were handled by gbp-pq, which basically uses `git format-patch` instead of plain dep-3 headers. I must admit that I prefer the original DEP-3, however that makes the gbp-pq import/export more noisy. But well, that's fine. > > > * why requiring gem2deb >=1 ? that's already in bullseye as well in > > > focal, so why did you feel the need to add the version? (that's also > > > not in the changelog) > > > > I simply copied the debian/ directory from the previous version that I > > got from pull-lp-source, I did not use git...I'll use git in the > > future, thanks. Ah, I see indeed that the current package has that thing. mh. Sorry I didn't notice that. Normally it's fine to base some work in the released package, however especially for team-maintained packages, it might be more useful and helpful to do the work in git nowadays, even if that exposes the submitter to the mess that is git maintenance in debian (where different teams have different workflows and different tools). > > > Could I ask you to submit a MR on top of it, with at least commits > > > separating the deletion, refresh and rebasing of patches (and eventual > > > new ones, I can't tell at a glance if any new patch appeared…) also > > > separated. > > > https://salsa.debian.org/ruby-team/ruby-pygments.rb > > > > > It's on its way :) > > I can't find how to create a MR in salsa, That's because you create a new repo instead of clicking the "fork" button on the original project. GitLab allows for MR to be created only in forks. > can you pull directly from here: > > https://salsa.debian.org/alexghiti/ruby-pygments.rb/-/tree/int/alex/2.3.0 > > It successfully built in my PPA, if you need any more modification, do > not hesitate. That looks fine! I'm going to massage the changelog a bit, but besides that it looks cool! Thank you! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1002532: pygments breaks ruby-pygments.rb autopkgtest: UTF-8 != ASCII-8BIT
Hi Alex,
On Thu, Jan 06, 2022 at 11:19:00AM +0100, Alexandre Ghiti wrote:
> As the current version we have is from 2017, I bumped the version of
> this package to the latest available version: I updated the patches,
> removed the ones that do not apply anymore, updated the build system
> and dependencies. The result is available in my PPA [2] and fixes the
> issue we encounter here.
>
> Can you consider pulling this?
Thank you for this!!
I had a look at your work, however I couldn't help but notice that:
* the .orig you used looks odd, much larger than what I get from uscan
(despite yours is also using a different compression, so repacked).
* You did a ton of patch wrangling, including deletion, renaming,
rebasing, etc. which is all fine, except that the way you did it
obscures quite a bit what you did. Why did you drop the numbers from
the patches? Do you have --no-patch-numbers as you gbp-pq default or
something?
* why requiring gem2deb >=1 ? that's already in bullseye as well in
focal, so why did you feel the need to add the version? (that's also
not in the changelog)
As such, I went ahead and re-imported the repacked origin I got myself
in git.
Could I ask you to submit a MR on top of it, with at least commits
separating the deletion, refresh and rebasing of patches (and eventual
new ones, I can't tell at a glance if any new patch appeared…) also
separated.
https://salsa.debian.org/ruby-team/ruby-pygments.rb
Thank you for your work!! :)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1003542: scribus-doc: please update to 1.5.7
On Tue, Jan 11, 2022 at 05:43:30PM +0100, Andreas Beckmann wrote: > Package: scribus-doc > Version: 1.5.6.1+dfsg-1 > Severity: serious > Tags: sid bookworm > > Hi, > > please update scribus-doc to 1.5.7 to match the scribus version in the > archive: > > scribus | 1.5.7+dfsg-5 | unstable | source, > amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x > scribus-doc | 1.5.6.1+dfsg-1 | unstable/non-free| source, all Sure, but… what triggered such overinflated severity? Aren't these kind of things wishlist normally? Especially because the changes are really not so interesting: https://salsa.debian.org/debian/scribus-doc/-/commit/09b8fa9b004f59a7639b9c770dcfdb1c73162e5a -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Mon, Jan 10, 2022 at 02:21:48PM -0500, Andres Salomon wrote: > On 1/10/22 05:01, Mattia Rizzolo wrote: > > On Sun, Jan 09, 2022 at 11:23:20PM -0500, Andres Salomon wrote: > > > Btw, https://salsa.debian.org/dilinger/chromium/-/tree/stable is my branch > > > with cleaned-up commits. That's what I'll use for the NMU, which I'm > > > preparing now. > > If you all agree, you could finalize the tree, then I'll build again, > > after which I could sponsor this after a couple days of testing. > > > > I see that you changed debian/copyright compared to the one I used in my > > build here, so I'll export the orig tarball again. (normally with > > Michel we'd share the sha256 of one's produced tarball to check we are > > building with the same thing, so please share yours?) > > > Thank you so much for testing! The sha256 that I have is > cca093107bf6991b4777889012646455f8e520b446c9f27250653f98ed4bb7e0 Cool, this matches with the new tarball I produced. Guess I'll restart a build with the stable branch now then. BTW, my current build (from the v97 branch), just crashed on me. Not sure where, and I couldn't quickly reproduce it either; I was just clicking ont he "extension bar", but I'm not even sure what I was doing.. just saying :) > I don't need a sponsor (I'm a developer), but thank you for the offer. Ah! Apologies! I didn't look your name up, and I just assumed so from the n...@debian.org address. Well, happy then, less "work" for me :D > Btw, hopefully Michael is just currently busy and is still interested in > working on chromium? I ralized that riku retaired formally last month (indeed, please drop him from Uploaders, I also opened a bug (as MIA team) against chromium last month). About Micheal, that's unclear to me: he stated less than one year ago that he would keep working on chromium, but he really is not answering to anybody... so well, even if he is still interested, in a case as big as chromium I think you really needs to show consideration and be at least reachable. Though it might just be my own opinion. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1003530: lintian: Hangs when checking some .dsc file
On Tue, Jan 11, 2022 at 07:29:32AM -0500, Boyuan Yang wrote:
> I just notice that lintian will never finish when checking some specific
That's not correct.
> https://mentors.debian.net/package/fcitx5-table-extra/ shows the lintian check
> result to be " lintian took too much time to run ".
I actually never saw lintian *hang*. It just got quite slow.
Specifically, on mentors.d.n we set a timeout for lintian of 30 minutes.
We really don't want the whole site to spend hours processing an
incoming packages...
Notably, in mentors we don't use `-X cruft` to bypass the slowest
codepath in lintian, that can easily go over the 30 minutes time.
> I am not 100% sure about the severity, but endless hang could be serious. Feel
> free to let me know if you have any questions.
IMHO, this could just be merged with that other bug (that I'm not
looking up) about the cruft check being slow.
Did you try running lintian yourself to actually verify it hangs
somewhere?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sun, Jan 09, 2022 at 11:23:20PM -0500, Andres Salomon wrote:
> Btw, https://salsa.debian.org/dilinger/chromium/-/tree/stable is my branch
> with cleaned-up commits. That's what I'll use for the NMU, which I'm
> preparing now.
If you all agree, you could finalize the tree, then I'll build again,
after which I could sponsor this after a couple days of testing.
I see that you changed debian/copyright compared to the one I used in my
build here, so I'll export the orig tarball again. (normally with
Michel we'd share the sha256 of one's produced tarball to check we are
building with the same thing, so please share yours?)
Regarding the git repository/team on salsa. What would you all think
about asking the salsa admins to bypass the team admins (gilbert and
riku) that have been silent all this time?
When Micheal started taking over, I didn't want to be too involved so I
didn't ask to be added to team together with him, but I suppose I got
sucked in by this matter a bit too much.
Otherwise I wonder about simply creating a new repository under debian/.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sun, Jan 09, 2022 at 12:56:28AM -0500, Andres Salomon wrote: > > On 1/8/22 15:57, Mattia Rizzolo wrote: > > On Thu, Jan 06, 2022 at 02:55:20AM -0500, Andres Salomon wrote: > > > If you want to try with chromium 97; it now builds as an official build, > > > so > > > those DCHECKs shouldn't even be compiled in. It also supports wayland > > > automatically, in case that's related to your slowdowns. > > > > > > https://salsa.debian.org/dilinger/chromium/-/tree/v97 > > I wanted to do this, but could it be that this version is for some > > reason taking much more space than the previous one? Here I have ~40 GB > > free, and v96 built just fine (though I wasn't looking when it was > > running), but now this failed already twice due to ENSPC. > > > > I'll try looking for someplace more spacy but it's odd :) > > > > Yeah, I think it's the debugging info; it's also breaking lld. It's a result > of enabling official build, I'm working on it. I see. Well, it took me longer than I would have liked, but I finally got a build out of that v97 branch (commit 2c2685aee67a677c85dd752aea08a7e571312116). This one looks fully functional, gmail is as reactive as it used to be (u.U after a few days with v96 and that slowness, now it feels so much better lol) in the past, and after ~15 minutes of random usage it hasn't crashed on me yet! \o/ It also fixed a problem I had with v93 where document google sheets would look totally blank... so double happy now! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Thu, Jan 06, 2022 at 02:55:20AM -0500, Andres Salomon wrote:
> If you want to try with chromium 97; it now builds as an official build, so
> those DCHECKs shouldn't even be compiled in. It also supports wayland
> automatically, in case that's related to your slowdowns.
>
> https://salsa.debian.org/dilinger/chromium/-/tree/v97
I wanted to do this, but could it be that this version is for some
reason taking much more space than the previous one? Here I have ~40 GB
free, and v96 built just fine (though I wasn't looking when it was
running), but now this failed already twice due to ENSPC.
I'll try looking for someplace more spacy but it's odd :)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Fri, Jan 07, 2022 at 06:34:06AM -0300, Leandro Cunha wrote: > > > I also haven't heard from anyone on the chromium team yet - should I > > > add myself as an uploader and do a normal (non-NMU) upload? Do any of > > > them care? > > > > Without hearing from them, adding yourself to Uploaders would be > > inappropriate. > > If there is no response from someone on the team and someone wants to continue > the work, how is it done? I was thinking about it when I read this email. https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging Plus, I suppose, the technical committee has the power to enforce maintainer changes (though I don't think this has been used in… at least a decade?). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Thu, Jan 06, 2022 at 02:55:20AM -0500, Andres Salomon wrote:
> If you want to try with chromium 97; it now builds as an official build, so
> those DCHECKs shouldn't even be compiled in. It also supports wayland
> automatically, in case that's related to your slowdowns.
>
> https://salsa.debian.org/dilinger/chromium/-/tree/v97
Thank you, let's try with this.
I've just started the build! :)
Also thanks for handling the py2 thing, however you should be aware that
build-depending on python-is-python3 is also not allowed :3
(however I personally prefer that than to have to inject an old binary..)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Wed, Jan 05, 2022 at 01:52:33PM +0100, Mattia Rizzolo wrote:
> I suppose I'll see how it goes in the coming few days.
So it's not crashing but it's being unbearably slow in gmail, to the
point that I just wasn't able to type a mail there, while throwing one
CPU core to 100%.
Also it was kind go generally slow in several other sites, compared to
v93. Always compared to v93, it takes far longer (and by far much much
more CPU) to reopen the whole session (I keep ~50 tabs in 3 windows open
all the time, trusting the browser to reopen them where I left when I
close it).
I didn't mesure anything and I don't have any numbers to share, but
that's what I see.
At least, it looks like it has not been leaking as much memory as v93
was (that in this regard was buggier than v90).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Tue, Jan 04, 2022 at 06:46:46PM -0500, Andres Salomon wrote: > On 1/4/22 15:15, Mattia Rizzolo wrote: > > On Tue, Jan 04, 2022 at 02:50:20PM -0500, Andres Salomon wrote: > > > I pushed a commit to the skip-a11y-checks branch, please give that a try. > > > I > > > need to take a look at other distributions that are shipping chromium to > > > see > > > if they're just disabling DCHECKs outright, or what. > > Just took a look at fedora, arch, and ungoogle-chromium debian packaging. > They're all setting is_official_build=true, which completely disables those > DCHECKs. We should probably set it like that as well, although the > dcheck_is_configurable=true thing that I added to the skip-a11y-checks > branch should at least allow the DCHECKs to not be fatal - so there's no > need to restart your build. So, this one at least didn't crash on me as soon as I started. Also, it looks like the saved passwords that went away came back, so I reckon perhaps the local storage format changed in the upgrade, so v93 wasn't able to see them anymore, or something similar. I suppose I'll see how it goes in the coming few days. Thank you for your work! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Tue, Jan 04, 2022 at 02:50:20PM -0500, Andres Salomon wrote:
> Okay, that's funny - appears to be a fatal error due to being run under gdb.
Well, it was also crashing outside of gdb ^^
> I pushed a commit to the skip-a11y-checks branch, please give that a try. I
> need to take a look at other distributions that are shipping chromium to see
> if they're just disabling DCHECKs outright, or what.
build started...
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
)] Cannot use V8 Proxy resolver in single process mode. [413:413:0104/174404.300230:FATAL:render_process_host_impl.cc(4227)] Check failed: host->GetBrowserContext() == browser_context (0x645f47d0 vs. 0x658dcb30) Single-process mode does not support multiple browser contexts. Thread 1 "chromium" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 49 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 #1 0x74653536 in __GI_abort () at abort.c:79 #2 0x5d79e9e5 in base::debug::BreakDebuggerAsyncSafe() () #3 0x5d6ea9f4 in logging::LogMessage::~LogMessage() () #4 0x5d6eaffe in logging::LogMessage::~LogMessage() () #5 0x5aba348a in content::RenderProcessHostImpl::IsSuitableHost(content::RenderProcessHost*, content::IsolationContext const&, content::SiteInfo const&) () #6 0x5aba4733 in content::RenderProcessHostImpl::GetExistingProcessHost(content::SiteInstanceImpl*) () #7 0x5aba5b71 in content::RenderProcessHostImpl::GetProcessHostForSiteInstance(content::SiteInstanceImpl*) () #8 0x5acb37dc in content::SiteInstanceImpl::GetProcess() () #9 0x5ab7b3c4 in content::RenderFrameHostManager::CreateRenderFrameHost(content::RenderFrameHostManager::CreateFrameCase, content::SiteInstance*, int, mojo::PendingAssociatedRemote, base::TokenType const&, bool) () #10 0x5ab7b235 in content::RenderFrameHostManager::InitRoot(content::SiteInstance*, bool) () #11 0x5aa4d59e in content::FrameTree::Init(content::SiteInstance*, bool, std::__cxx11::basic_string, std::allocator > const&) () #12 0x5ad1a896 in content::WebContentsImpl::Init(content::WebContents::CreateParams const&) () #13 0x5ad0cbb1 in content::WebContentsImpl::CreateWithOpener(content::WebContents::CreateParams const&, content::RenderFrameHostImpl*) () #14 0x5ad0c8b1 in content::WebContents::Create(content::WebContents::CreateParams const&) () #15 0x608c633b in ProfilePickerView::Init(Profile*) () #16 0x608c61f0 in ProfilePickerView::OnSystemProfileCreated(Profile*, Profile::CreateStatus) () #17 0x5a62fec0 in base::internal::Invoker, std::allocator > const&, web_app::InstallResultCode), base::WeakPtr >, void (std::__cxx11::basic_string, std::allocator > const&, web_app::InstallResultCode)>::RunOnce(base::internal::BindStateBase*, std::__cxx11::basic_string, std::allocator > const&, web_app::InstallResultCode) () #18 0x5d399bcb in ProfileManager::CreateProfileAsync(base::FilePath const&, base::RepeatingCallback const&) () #19 0x608c4442 in ProfilePickerView::Display(ProfilePicker::EntryPoint) () #20 0x6076c476 in StartupBrowserCreator::LaunchBrowserForLastProfiles(base::CommandLine const&, base::FilePath const&, bool, Profile*, std::vector > const&) () #21 0x6076df14 in StartupBrowserCreator::ContinueProcessingCommandLineAfterEarlyWebAppCheck(base::CommandLine const&, base::FilePath const&, Profile*, bool, Profile*, std::vector > const&) () #22 0x6076bcd8 in StartupBrowserCreator::ProcessCmdLineImpl(base::CommandLine const&, base::FilePath const&, bool, Profile*, std::vector > const&) () #23 0x6076ae30 in StartupBrowserCreator::Start(base::CommandLine const&, base::FilePath const&, Profile*, std::vector > const&) () #24 0x5d1b86ef in ChromeBrowserMainParts::PreMainMessageLoopRunImpl() () #25 0x5d1b7ea8 in ChromeBrowserMainParts::PreMainMessageLoopRun() () #26 0x5a6b6ddc in content::BrowserMainLoop::PreMainMessageLoopRun() () #27 0x5acd2c36 in content::StartupTaskRunner::RunAllTasksNow() () #28 0x5a6b69ca in content::BrowserMainLoop::CreateStartupTasks() () #29 0x5a6b9598 in content::BrowserMainRunnerImpl::Initialize(content::MainFunctionParams const&) () #30 0x5a6b4e22 in content::BrowserMain(content::MainFunctionParams const&) () #31 0x5d176f7d in content::ContentMainRunnerImpl::RunBrowser(content::MainFunctionParams&, bool) () #32 0x5d1768df in content::ContentMainRunnerImpl::Run(bool) () #33 0x5d17419a in content::RunContentProcess(content::ContentMainParams const&, content::ContentMainRunner*) () #34 0x5d174a8b in content::ContentMain(content::ContentMainParams const&) () #35 0x555558e0d721 in ChromeMain () #36 0x746547ed in __libc_start_main (main=0x58e0d5f0 , argc=11, argv=0x7fffdd38, init=, fini=, rtld_fini=, stack_end=0x7fffdd28) at ../csu/libc-start.c:332 #37 0x58e0d52a in _start () -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Mon, Jan 03, 2022 at 01:39:21PM +0100, Mattia Rizzolo wrote:
> On Sun, Jan 02, 2022 at 06:53:52PM +0100, Mattia Rizzolo wrote:
> > > > the v96 branch of https://salsa.debian.org/dilinger/chromium
> >
> > FWIW, I'm trying to build it myself as well
>
> Here it started chrashing as soon as I tried to open a new tab, and
> after that it refuses to load my main profile (but it loads others).
After rolling back, it seems to have nuked all of the saved passwords
and login information I had (I don't know if this is only an effect of
the rollback and they are actually there somewhere), as well as all
cookies.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sun, Jan 02, 2022 at 06:53:52PM +0100, Mattia Rizzolo wrote: > > > the v96 branch of https://salsa.debian.org/dilinger/chromium > > FWIW, I'm trying to build it myself as well Here it started chrashing as soon as I tried to open a new tab, and after that it refuses to load my main profile (but it loads others). Here is what it prints on the console: mattia@warren /tmp % chromium [3249439:3249439:0103/133254.120313:ERROR:power_monitor_device_source_stub.cc(11)] Not implemented reached in virtual bool base::PowerMonitorDeviceSource::IsOnBatteryPower() [3249485:3249485:0103/133254.419923:ERROR:gpu_init.cc(457)] Passthrough is not supported, GL is desktop, ANGLE is [3249485:3249485:0103/133254.445016:ERROR:sandbox_linux.cc(376)] InitializeSandbox() called with multiple threads in process gpu-process. [3249439:3249468:0103/133258.019370:ERROR:chrome_browser_main_extra_parts_metrics.cc(226)] crbug.com/1216328: Checking Bluetooth availability started. Please report if there is no report that this ends. [3249439:3249468:0103/133258.020176:ERROR:chrome_browser_main_extra_parts_metrics.cc(229)] crbug.com/1216328: Checking Bluetooth availability ended. [3249439:3249468:0103/133258.020199:ERROR:chrome_browser_main_extra_parts_metrics.cc(232)] crbug.com/1216328: Checking default browser status started. Please report if there is no report that this ends. [3249439:3249468:0103/133258.284415:ERROR:chrome_browser_main_extra_parts_metrics.cc(236)] crbug.com/1216328: Checking default browser status ended. [3249439:3249439:0103/133259.591406:FATAL:accessibility_paint_checks.cc(60)] Check failed: node_data.GetNameFrom() == ax::mojom::NameFrom::kAttributeExplicitlyEmpty (kAttribute vs. kAttributeExplicitlyEmpty) 0x55c6fb7c92d0: BookmarkButton is focusable but has no accessible name or placeholder, and is not explicitly marked as empty. BrowserRootView -> NonClientView -> OpaqueBrowserFrameView -> BrowserView -> TopContainerView -> BookmarkBarView -> BookmarkButton #0 0x55c6ef3a2d79 (/usr/lib/chromium/chromium+0x824bd78) #1 0x55c6ef2d2353 (/usr/lib/chromium/chromium+0x817b352) #2 0x55c6ef2ed596 (/usr/lib/chromium/chromium+0x8196595) #3 0x55c6ef2edffe (/usr/lib/chromium/chromium+0x8196ffd) #4 0x55c6f1fd483a (/usr/lib/chromium/chromium+0xae7d839) #5 0x55c6f1fc7e92 (/usr/lib/chromium/chromium+0xae70e91) #6 0x55c6f1fcb985 (/usr/lib/chromium/chromium+0xae74984) #7 0x55c6f1fcb7a8 (/usr/lib/chromium/chromium+0xae747a7) #8 0x55c6f25a21bc (/usr/lib/chromium/chromium+0xb44b1bb) #9 0x55c6f1fc86ec (/usr/lib/chromium/chromium+0xae716eb) #10 0x55c6f1fcc72c (/usr/lib/chromium/chromium+0xae7572b) #11 0x55c6f0a59f58 (/usr/lib/chromium/chromium+0x9902f57) #12 0x55c6f05f0b71 (/usr/lib/chromium/chromium+0x9499b70) #13 0x55c6f063ef56 (/usr/lib/chromium/chromium+0x94e7f55) #14 0x55c6f063e891 (/usr/lib/chromium/chromium+0x94e7890) #15 0x55c6f0704e02 (/usr/lib/chromium/chromium+0x95ade01) #16 0x55c6f0705928 (/usr/lib/chromium/chromium+0x95ae927) #17 0x55c6eeead34a (/usr/lib/chromium/chromium+0x7d56349) #18 0x55c6ef3421cd (/usr/lib/chromium/chromium+0x81eb1cc) #19 0x55c6ef3632d6 (/usr/lib/chromium/chromium+0x820c2d5) #20 0x55c6ef362a88 (/usr/lib/chromium/chromium+0x820ba87) #21 0x55c6ef363892 (/usr/lib/chromium/chromium+0x820c891) #22 0x55c6ef2f655f (/usr/lib/chromium/chromium+0x819f55e) #23 0x55c6ef363e28 (/usr/lib/chromium/chromium+0x820ce27) #24 0x55c6ef322a15 (/usr/lib/chromium/chromium+0x81cba14) #25 0x55c6ec2baa33 (/usr/lib/chromium/chromium+0x5163a32) #26 0x55c6ec2bc9de (/usr/lib/chromium/chromium+0x51659dd) #27 0x55c6ec2b7e32 (/usr/lib/chromium/chromium+0x5160e31) #28 0x55c6eed79f7d (/usr/lib/chromium/chromium+0x7c22f7c) #29 0x55c6eed798df (/usr/lib/chromium/chromium+0x7c228de) #30 0x55c6eed7719a (/usr/lib/chromium/chromium+0x7c20199) #31 0x55c6eed77a8b (/usr/lib/chromium/chromium+0x7c20a8a) #32 0x55c6eaa10721 ChromeMain #33 0x7f7cbdfd17ed __libc_start_main #34 0x55c6eaa1052a _start Task trace: #0 0x55c6f0705676 (/usr/lib/chromium/chromium+0x95ae675) #1 0x55c6ef58b1c0 (/usr/lib/chromium/chromium+0x84341bf) #2 0x55c6ef5b62dc (/usr/lib/chromium/chromium+0x845f2db) IPC message handler context: 0xB99CF134 Crash keys: "total-discardable-memory-allocated" = "8388608" "gpu-gl-renderer" = "Mesa Intel(R) HD Graphics 520 (SKL GT2)" "gpu-gl-vendor" = "Intel" "gpu-generation-intel" = "9" "gpu-vsver" = "4.60" "gpu-psver" = "4.60" "gpu-driver" = "21.2.6" "gpu-devid" = "0x1916" "gpu-venid" = "0x8086" "ui_scheduler_async_stack" = "0x55C6F0705676 0x55C6EF58B1C0" "extension-1" = "oboonakemofpalcgghocfoadofidjkkk" "num-extensions" = "1" "switch-12" = "--origin-trial-disabled-features=CaptureHandle" "switch-11" = &qu
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote: > > I've got 96.0.4664.110 building on both bullseye and sid Trying it, I see it still build-depends on python-jinja2. That package is now gone, so it's not actually buildable in sid anymore. Correlated, do you know how long do they plan on keeping using python2? That's plainly unsuitable, it really is not going to last much longer in debian. > > the v96 branch of https://salsa.debian.org/dilinger/chromium FWIW, I'm trying to build it myself as well (after injecting an old python-jinja2 and an old python-markupsafe). > Alright, crashes are solved and the packages are now usable. After some > cleanups (listing CVEs in changelogs, This doesn't seem to be done as of the current tip of you v96 branch. > merging/pushing a bunch of > commits in my branch, possibly dropping strong stack protection from > builds to silence warnings from older clang versions, and going through > lintian errors/warnings), it should be ready to upload. TBH, I don't think I am able to judge the appropriateness of most of those changes... Though I suspect I could close most of my eyes and upload it to unstable: can't be much worse than what we have... > How should I handle this? NMU to sid, let people try it out, and then > deal with buster/bullseye? Upload everything all at once? Procedure would be NMU to unstable first, IMHO. > I also haven't heard from anyone on the chromium team yet - should I > add myself as an uploader and do a normal (non-NMU) upload? Do any of > them care? Without hearing from them, adding yourself to Uploaders would be inappropriate. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#999806: pygattlib: diff for NMU version 0~20201113-1.1
Control: tags 999806 + pending Dear maintainer, I've prepared an NMU for pygattlib (versioned as 0~20201113-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- diffstat for pygattlib-0~20201113 pygattlib-0~20201113 changelog |8 patches/multiple-boost-python.patch | 27 +++ patches/series |1 + 3 files changed, 36 insertions(+) diff -Nru pygattlib-0~20201113/debian/changelog pygattlib-0~20201113/debian/changelog --- pygattlib-0~20201113/debian/changelog 2020-12-23 09:44:47.0 +0100 +++ pygattlib-0~20201113/debian/changelog 2022-01-02 15:38:19.0 +0100 @@ -1,3 +1,11 @@ +pygattlib (0~20201113-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix misbuild with multiple supported Python3 versions. Closes: #999806 +Thanks to Steve Langasek for the patch. + + -- Mattia Rizzolo Sun, 02 Jan 2022 15:38:19 +0100 + pygattlib (0~20201113-1) unstable; urgency=medium * Initial Release. (Closes: #977950) diff -Nru pygattlib-0~20201113/debian/patches/multiple-boost-python.patch pygattlib-0~20201113/debian/patches/multiple-boost-python.patch --- pygattlib-0~20201113/debian/patches/multiple-boost-python.patch 1970-01-01 01:00:00.0 +0100 +++ pygattlib-0~20201113/debian/patches/multiple-boost-python.patch 2022-01-02 15:37:47.0 +0100 @@ -0,0 +1,27 @@ +Description: fix libboost detection with multiple python versions + pygattlib always links against the first libboost_python.so it finds. + When building for multiple python versions, this is wrong; it should link + against the one matching the version of python we're building for. +Author: Steve Langasek +Bug-Debian: https://bugs.debian.org/999806 +Last-Update: 2022-01-02 + +Index: pygattlib-0~20201113/setup.py +=== +--- pygattlib-0~20201113.orig/setup.py pygattlib-0~20201113/setup.py +@@ -11,12 +11,8 @@ + + + def get_boost_version(out=None): +-if out is None: +-out = subprocess.check_output( +-r"ldconfig -p | grep -E 'libboost_python.*\.so '", shell=True) +- +-ver = os.path.splitext(out.split()[0][3:])[0].decode() +-return ver ++return 'boost_python%s%s' \ ++% (sys.version_info.major, sys.version_info.minor) + + def tests(): + # case: python3-py3x.so diff -Nru pygattlib-0~20201113/debian/patches/series pygattlib-0~20201113/debian/patches/series --- pygattlib-0~20201113/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ pygattlib-0~20201113/debian/patches/series 2022-01-02 15:37:18.0 +0100 @@ -0,0 +1 @@ +multiple-boost-python.patch signature.asc Description: PGP signature
Bug#1002403: marked as pending in dput-ng
Control: tag -1 pending Hello, Bug #1002403 in dput-ng reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/dput-ng/-/commit/61fd1927ceb830119aa762167fb54d4eae38bc19 Switch to jsonschema as validictory is deprecated Closes: #1002403 (this message was generated automatically) -- Greetings https://bugs.debian.org/1002403
Bug#1001016: telegram-desktop: Version in stable (2.6.1) becoming unusable
While thinking this, please also consider that this is the first time ever that telegram broke its API in such strong backward incompatible way. In the past it only added features that, at most, prevented old clients to display the newest type of messages, hardly something RC. Please don't be too quick in judging telegram not stable-worthy just for one breaking APi change. On Sat, 18 Dec 2021, 10:33 pm Paul Gevers, wrote: > Dear Nicholas, > > On Fri, 03 Dec 2021 20:11:10 +0300 Nicholas Guriev > wrote: > > Release managers do not happy with huge updates after Debian freeze. > > And for good reasons (also remember that upgrades only come every two > months or so, even longer for oldstable). > > If telegram-desktop is useless in stable and isn't supportable in > stable, you should request it's removal from stable ($(reportbug > release.debian.org)). > > Also, if I read you correctly I think we should stop shipping > telegram-desktop in testing as it seems you can't support it for long in > any Debian stable release. Maybe you should look for supporting the > users via https://fasttrack.debian.net/ > > Paul > > PS: the argument about firefox-esr is valid, but we consider that an > unavoidable exception (not shipping a web-browser sounds like a bad idea). >
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Mon, Dec 06, 2021 at 08:53:37PM +0100, Paul Gevers wrote:
> I have good experience with some of my upstreams where they supported me by
> adapting their build system to enable building without the bundled/vendored
> dependencies. Has this been tried? Would it be worth pursuing?
It has been, yes.
I was looking when Micheal reported a few bugs (after my prodding) to
get a few build issues solved (actual FTBFS when building with specific
build flags). Even those bug reports were completely ignored with no
answer whatsoever; the patches also ignored.
I'm led to believe the chromium team is not really playing with the
community at all, rather they are just following their internal bug
tracker instead.
Likewise, they are obviously not interested in supporting anything that
is not the official Google Chrome build (if it can even said they are
"supoprting" that).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
> Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> > The problem really is lack of maintenance. In my opinion, chromium deserves
> > an active *team* to support it in Debian.
[..]
> > We'll not ship it in bookworm unless we see steady uploads
> > in unstable and we see security uploads in stable.
FWIW, as the person currently sponsoring the (few) uploads thatt happen,
I also approve of this.
I had some hopes for the current "team" (m)ilbert and Michel), but
gilbert's mail even started bouncing, and Micheal became less and less
responsive :( - I understand it's a complicated package so yes, there
needs to be a real team: I also recommend you require an active (as
gilbert is not) DD in the team that actually maintains chromium (so not
me who just sponsor the uploads).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1000210: marked as pending in devscripts
Control: tag -1 pending Hello, Bug #1000210 in devscripts reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/devscripts/-/commit/8246ebbe2b4aac700b8a5e4358e4152e71979737 Revert "uscan: Assign $newfile_base a filename, not a URL, when filenamemangling" This reverts commit 9e65c07737425748e396291d9c20442d11b0641b. Closes: #1000210 Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/1000210
Bug#1000210: [regression] uscan die: filenamemangle failed
This is not the problem here really. It's the different matching base. Together with the previous versification I also verified that such filenamemangle (like systemd's) don't match anymore. That's equally problematic (if not more!) than the program exiting with an error. I can agree however you want that it's a bad design, but that has been the specification since the start and it can't change without a format bump. I plan to revert Hugh's commit in the next days to solve this, reopening the previous bug and pending a better fix. On Sat, 20 Nov 2021, 11:02 pm Yadd, wrote: > Le 20/11/2021 à 13:36, Mattia Rizzolo a écrit : > > On Sat, Nov 20, 2021 at 01:14:23PM +0100, Yadd wrote: > >> Le 20/11/2021 à 12:23, Mattia Rizzolo a écrit : > >>> So, effectively, the change broke the specification. > >> > >> It looks like the specification was not good. A filename isn't an URL > > > > Be that as it may, we can't break something like that without a version > > bump, IMHO. > > > > So we need a different fix for #993585. > > > > Either way, I think it's unrelated to your discovery that it could > > potentially overwrite a file, isn't it? > > We could perhaps just warn for now on bad filenamemangle >
Bug#1000210: [regression] uscan die: filenamemangle failed
On Sat, Nov 20, 2021 at 01:14:23PM +0100, Yadd wrote:
> Le 20/11/2021 à 12:23, Mattia Rizzolo a écrit :
> > So, effectively, the change broke the specification.
>
> It looks like the specification was not good. A filename isn't an URL
Be that as it may, we can't break something like that without a version
bump, IMHO.
So we need a different fix for #993585.
Either way, I think it's unrelated to your discovery that it could
potentially overwrite a file, isn't it?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#1000210: [regression] uscan die: filenamemangle failed
Yadd: Looking better, I think we do have a small problem here: On Fri, Nov 19, 2021 at 08:16:37PM +0100, Michael Biebl wrote: > uscan info: Looking at $base = https://github.com/systemd/systemd-stable/tags > with > $filepattern = .*/v?(\d\S*)\.tar\.gz found > $newfile = > https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz > $newversion = 249.7 > $lastversion = 249.6 > uscan info: Matching target for downloadurlmangle: > https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz > uscan info: Upstream URL(+tag) to download is identified as > https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz > uscan info: Matching target for filenamemangle: v249.7.tar.gz > uscan die: filenamemangle failed for v249.7.tar.gz at > /usr/share/perl5/Devscripts/Uscan/Output.pm line 60. ... > uscan info: Looking at $base = https://github.com/systemd/systemd-stable/tags > with > $filepattern = .*/v?(\d\S*)\.tar\.gz found > $newfile = > https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz > $newversion = 249.7 > $lastversion = 249.6 > uscan info: Matching target for downloadurlmangle: > https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz > uscan info: Upstream URL(+tag) to download is identified as > https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz > uscan info: Matching target for filenamemangle: > https://github.com/systemd/systemd-stable/archive/refs/tags/v249.7.tar.gz > uscan info: Filename (filenamemangled) for downloaded file: > systemd-249.7.tar.gz I went to better read the relevant documentation: filenamemangle=rules Generate the upstream tarball filename from the selected href string if matching-pattern can extract the latest upstream version from the selected href string. Otherwise, generate the upstream tarball filename from its full URL string and set the missing from the generated upstream tarball filename. That text is very confusing to me, but it does say that the rules, in some cases, are matched against the full URL. In particular, it means that any matching-pattern that has ".*" as leading characters will most likely have a full URL here to match against. So, effectively, the change broke the specification. This apparently came as a result to https://bugs.debian.org/993585 - which was really complaining about pgpsigurlmangle but it ended up affecting filenamemangle too. In fact, I believe reverting 9e65c07737425748e396291d9c20442d11b0641b fixes this bug, but probably reopens that other one. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1000182: python-jira: network access during the build
ies with the following issues:
|intersphinx inventory 'https://ipython.readthedocs.io/en/stable/objects.inv'
not fetchable due to :
HTTPSConnectionPool(host='ipython.readthedocs.io', port=443): Max retries
exceeded with url: /en/stable/objects.inv (Caused by
NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution'))
|WARNING: failed to reach any of the inventories with the following issues:
|intersphinx inventory 'https://docs.python.org/3.7/objects.inv' not fetchable
due to :
HTTPSConnectionPool(host='docs.python.org', port=443): Max retries exceeded
with url: /3.7/objects.inv (Caused by
NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution'))
|WARNING: failed to reach any of the inventories with the following issues:
|intersphinx inventory 'https://pip.readthedocs.io/en/stable/objects.inv' not
fetchable due to :
HTTPSConnectionPool(host='pip.readthedocs.io', port=443): Max retries exceeded
with url: /en/stable/objects.inv (Caused by
NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution'))
|WARNING: failed to reach any of the inventories with the following issues:
|intersphinx inventory
'https://requests.kennethreitz.org/en/master/objects.inv' not fetchable due to
:
HTTPSConnectionPool(host='requests.kennethreitz.org', port=443): Max retries
exceeded with url: /en/master/objects.inv (Caused by
NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution'))
Even *attempting* network access is forbidden for Debian main packages,
see Policy §4.9 "Main building script: debian/rules":
For packages in the main archive, required targets must not attempt
network access, except, via the loopback interface, to services on
the build host that have been started by the build.
[1]
https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-2025/013319.html
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#996878: python3-prelude: python3 import prelude throws an ImportError exception
Control: found -1 5.2.0-3
Contrl: tags -1 bullseye bookworm unstable
On Wed, Oct 20, 2021 at 09:14:31AM +0200, Francois Lesueur wrote:
> Version: 5.2.0-4
You filed this with the version in bookworm, but your test was done in
bullseye (and I also verified this affects bullseye), so marking the bug
as such.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#998911: node-string-width: file conflict with node-slice-ansi
yep, that, sorry. I mean it's missing a Replaces. On Wed, Nov 10, 2021 at 3:24 PM Axel Beckert wrote: > > Hi Mattia, > > Mattia Rizzolo wrote: > > Control: reopen -1 > > > > On Wed, Nov 10, 2021 at 03:01:11PM +0100, Axel Beckert wrote: > > > I also noticed just now that I got it the wrong way around in that > > > comment: These headers need to go into node-slice-ansi, not into > > > node-string-width. But luckily Mattia got it right: > > > > > > Mattia Rizzolo wrote: > > > > Without too many checks, I believe node-slice-ansi should have a > > > > Breaks+Replace: node-string-width (<< 4.2.3+~9.2.2-1) > > > > I also noticed that the last upload seems to have added Breaks but not > > Conflicts. I don't think that's enough (haven't tested). > > I think you mean "Replaces". Breaks and Conflicts are AFAIK "either or". > > Regards, Axel > -- > ,''`. | Axel Beckert , https://people.debian.org/~abe/ > : :' : | Debian Developer, ftp.ch.debian.org Admin > `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 > `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo
Bug#998911: node-string-width: file conflict with node-slice-ansi
Control: reopen -1
On Wed, Nov 10, 2021 at 03:01:11PM +0100, Axel Beckert wrote:
> I also noticed just now that I got it the wrong way around in that
> comment: These headers need to go into node-slice-ansi, not into
> node-string-width. But luckily Mattia got it right:
>
> Mattia Rizzolo wrote:
> > Without too many checks, I believe node-slice-ansi should have a
> > Breaks+Replace: node-string-width (<< 4.2.3+~9.2.2-1)
I also noticed that the last upload seems to have added Breaks but not
Conflicts. I don't think that's enough (haven't tested).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#998911: [Pkg-javascript-devel] Bug#998911: node-string-width: file conflict with node-slice-ansi
On Wed, Nov 10, 2021 at 02:13:46PM +0100, Yadd wrote:
> you reopened this bug, however node-string-width is really fixed in
> version 4.2.3+~9.2.2-1 (no more is-fullwidth-code-point). What should I do ?
Without too many checks, I believe node-slice-ansi should have a
Breaks+Replace: node-string-width (<< 4.2.3+~9.2.2-1) though I'm not
sure (please double check!)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#997359: Inkscape crashes when running as batch without X11
Control: forwarded -1 https://gitlab.com/inkscape/inkscape/-/issues/2899 On Sun, Oct 24, 2021 at 06:57:14PM +0200, Ole Streicher wrote: > On 24.10.21 18:29, Mattia Rizzolo wrote: > > Since you managed to reproduce it and all, could you perhaps consider > > forwarding it yourself on https://gitlab.com/inkscape/inbox ? > > I would prefer if you could do it. I am not very familar with inkscape, and > the icon creation here is almost the only case where I use it. > > You did not use the "--batch-process" option. If you add this, you get the > crash. From the man page, this option is mandatory for batch processing. Oh! Indeed, with that I could reliably reproduce it! Sent upstream. Thank you! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#938628: marked as pending in taskd
Control: tag -1 pending Hello, Bug #938628 in taskd reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/tasktools-team/taskd/-/commit/b31b5d718d901e4cea0edd24a23397b42b038852 d/control: Remove perl and python from Build-Depends (Closes: #938628) The resulting .deb is bit-by-bit identical even after removing both perl and python from Build-Depends. (this message was generated automatically) -- Greetings https://bugs.debian.org/938628
Bug#997359: Inkscape crashes when running as batch without X11
On Sun, Oct 24, 2021 at 05:14:19PM +0200, Ole Streicher wrote:
> Inkscape is used during the debian-astro package to create a png icon
> from the original svg image. This now crashes:
:(
> This is the backtrace:
>
> (gdb) bt
Since you managed to reproduce it and all, could you perhaps consider
forwarding it yourself on https://gitlab.com/inkscape/inbox ?
> This happend before in #959885, but was not really reproducible.
And it still is not for me:
(sid_amd64-dchroot)mattia@barriere ~ % inkscape --export-filename=foo.png
/usr/share/inkscape/templates/about_screen.svg --export-type=png ; echo return
code: $?
Unable to init server: Could not connect: Connection refused
Failed to get connection
** (inkscape:15042): CRITICAL **: 16:28:52.226: dbus_g_proxy_new_for_name:
assertion 'connection != NULL' failed
** (inkscape:15042): CRITICAL **: 16:28:52.226: dbus_g_proxy_call: assertion
'DBUS_IS_G_PROXY (proxy)' failed
** (inkscape:15042): CRITICAL **: 16:28:52.226:
dbus_g_connection_register_g_object: assertion 'connection != NULL' failed
Background RRGGBBAA: b1b1b100
Area 0:0:750:625 exported to 750 x 625 pixels (96 dpi)
return code: 0
(sid_amd64-dchroot)mattia@barriere ~ %
:\
it totally is not crashing; sure it's dumping noise, but still
succeeding at its job.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#995928: acorn: doc directory shipped by both binaries
Hi release team, concerning this bug, I'd like to hear advice from you on how you'd best like to see this fixed in stable. The current bug causes trouble for reproducible builds operations (basically, it throws away all build involving node-acorn in bullseye). See the last paragraph on my thoughts about the potential solutions; I'm happy to implement what you think would be best. On Fri, Oct 08, 2021 at 12:07:36PM +0200, Mattia Rizzolo wrote: > Source: acorn > Version: 8.0.5+ds+~cs19.19.27-3 > Severity: serious > Control: fixed -1 8.5.0+ds+~cs23.9.6-2 > > This happens in bullseye: > > root@warren:/# apt install node-acorn > ... > The following NEW packages will be installed: > libbrotli1 libc-ares2 libicu67 libnghttp2-14 libnode72 libuv1 node-acorn > node-debbundle-acorn node-xtend nodejs > ... > root@warren:/# apt install --reinstall node-debbundle-acorn > ... > (Reading database ... 12963 files and directories currently installed.) > Preparing to unpack .../node-debbundle-acorn_8.0.5+ds+~cs19.19.27-3_all.deb > ... > Unpacking node-debbundle-acorn (8.0.5+ds+~cs19.19.27-3) over > (8.0.5+ds+~cs19.19.27-3) ... > (Noting disappearance of node-acorn, which has been completely replaced.) > Setting up node-debbundle-acorn (8.0.5+ds+~cs19.19.27-3) ... > The following package disappeared from your system as > all files have been overwritten by other packages: > node-acorn > Note: This is done automatically and on purpose by dpkg. > > > This is due to node-acorn shipping /usr/share/doc/node-acorn (type: > symlink) which is *also* shipping by node-debbundle-acorn (type: > directory). > dpkg seems to always overwrite the symlink anyway, but it doesn't detect > that it's gone until later when reinstalling it. > > > To be honest, I'm not sure what was the wanted situation, but I *think* > the symlink is just wrong. Looking at the content of the > /usr/share/doc/node-acorn/ directory as present in node-debbundle-acorn, > I think that is the appropriate content. So, probably, the best fix is > to just get rid of the symlink from node-acorn, however that would leave > the package totally empty, which dpkg is not totally thrilled about. > So more likely at least the 2 symlinks of copyright and > changelog.Debian.gz in /usr/share/doc/node-acorn could be moved from > node-debbundle-acorn to node-acorn, so effectively shipping the > directory from both packages. > > > > This is fixed in 8.5.0+ds+~cs23.9.6-2 by moving everything to node-acorn > and turning node-debbundle-acorn into a pure transitional package. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#995928: acorn: doc directory shipped by both binaries
Source: acorn Version: 8.0.5+ds+~cs19.19.27-3 Severity: serious Control: fixed -1 8.5.0+ds+~cs23.9.6-2 This happens in bullseye: root@warren:/# apt install node-acorn ... The following NEW packages will be installed: libbrotli1 libc-ares2 libicu67 libnghttp2-14 libnode72 libuv1 node-acorn node-debbundle-acorn node-xtend nodejs ... root@warren:/# apt install --reinstall node-debbundle-acorn ... (Reading database ... 12963 files and directories currently installed.) Preparing to unpack .../node-debbundle-acorn_8.0.5+ds+~cs19.19.27-3_all.deb ... Unpacking node-debbundle-acorn (8.0.5+ds+~cs19.19.27-3) over (8.0.5+ds+~cs19.19.27-3) ... (Noting disappearance of node-acorn, which has been completely replaced.) Setting up node-debbundle-acorn (8.0.5+ds+~cs19.19.27-3) ... The following package disappeared from your system as all files have been overwritten by other packages: node-acorn Note: This is done automatically and on purpose by dpkg. This is due to node-acorn shipping /usr/share/doc/node-acorn (type: symlink) which is *also* shipping by node-debbundle-acorn (type: directory). dpkg seems to always overwrite the symlink anyway, but it doesn't detect that it's gone until later when reinstalling it. To be honest, I'm not sure what was the wanted situation, but I *think* the symlink is just wrong. Looking at the content of the /usr/share/doc/node-acorn/ directory as present in node-debbundle-acorn, I think that is the appropriate content. So, probably, the best fix is to just get rid of the symlink from node-acorn, however that would leave the package totally empty, which dpkg is not totally thrilled about. So more likely at least the 2 symlinks of copyright and changelog.Debian.gz in /usr/share/doc/node-acorn could be moved from node-debbundle-acorn to node-acorn, so effectively shipping the directory from both packages. This is fixed in 8.5.0+ds+~cs23.9.6-2 by moving everything to node-acorn and turning node-debbundle-acorn into a pure transitional package. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#995162: cannot install together with i386
On Thu, Sep 30, 2021 at 09:27:50PM +0200, Giovanni Mascellani wrote:
> Thanks for the info. Unless I am mistaken, this means that any package which
> installs a shared PNG breaks at every binNMU, unless the binNMU is for all
> architectures. Wouldn't it be better if dh_strip_nondeterminism used the
> last sourceful upload as reference timestamp? Was this option considered?
It has been considered, but I can tell you that it's _much_ more complex
than just that. For starters, there would be a huge layer violation in
doing so: the timestamp to use in the normalization comes from dpkg.
Also, normalizing to the previous sourceful upload date is quite likely
to resurface other bugs such what https://bugs.debian.org/843773 tried to fix.
I can add that there are quite many other packages affected by this
(currently 58 binaries), and regularly they cycle as they are binNMUed
and then re-uploaded. Fortunately this pretty much only affects -dev
and some perl-* packages, and not many people try to cross-coinstall
those packages (as opposed to pure libraries), so the bug doesn't
resurface too often.
I'll leave with the relevant "toolchain" bug: https://bugs.debian.org/969501
(which is what I consider a very valid technical non-full solution of
the problem), and what realistically is the one final solution:
https://bugs.debian.org/894441
Realistically, package-wise, I think they would good by not placing PNGs
in arch:any packages, that would side-step this issue. And it's the
proper thing to do anyway so why not. More than that, I don't think
they should bother excessively unless somebody reports them.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Bug#994741: regression tests: skipped vs failed
So, I think I "found" the problem, will need to verify. But I wanted to drop a few lines as reply here: On Thu, Sep 23, 2021 at 07:30:25AM -0700, ian_br...@mail.ru wrote: > Does that not suggest that the problem is some peculiarity of the build > environment, rather than any specific problem with the Inkscape code? It does. But it doesn't mean that it shouldn't be investiaged properly. FYI, here comes an *inkscape* bug as well, though it's not on amd64 like the one you are concerned about. https://gitlab.com/inkscape/inkscape/-/issues/2821 > Comparing the build logs for v1.0.2 and v1.1, one discovers that the > reason that this is not a problem for v1.0.2 is that this specific test > apparently does not exist in that version. And is a very good thing they added the test. It is very much not a reason to dismiss their reasults. > Unable to init server: Could not connect: Connection refused > Failed to get connection > ** (inkscape:2024671): CRITICAL **: 15:19:35.442: > dbus_g_proxy_new_for_name: assertion 'connection != NULL' failed > > ** (inkscape:2024671): CRITICAL **: 15:19:35.442: dbus_g_proxy_call: > assertion 'DBUS_IS_G_PROXY (proxy)' failed > > ** (inkscape:2024671): CRITICAL **: 15:19:35.442: > dbus_g_connection_register_g_object: assertion 'connection != NULL' failed > end_font_face_cb: font face rule limited support. > font-family : 'GeomTest'; > src : url(fonts/GeomTest-gzipped-SVG-glyphs.otf) > end_font_face_cb: Added font: > /<>/testfiles/rendering_tests/fonts/GeomTest-gzipped-SVG-glyphs.otf > Background RRGGBBAA: ff00 > Area 0:0:110:40 exported to 110 x 40 pixels (96 dpi) > Pixbuf::create_from_file: Unrecognized image file format >() > Pixbuf::create_from_file: Unrecognized image file format >() > Pixbuf::create_from_file: Unrecognized image file format >() > 1589 > text-gzipped-svg-glyph FAILED > text-gzipped-svg-glyph-large SKIPPED > > > Why is a "connection" necessary to retrieve a font file from a "url"? > And why should the "server" then "refuse" it? Is this not expecting > entirely too much from a mere package-build server? It's not. a server-client is simply one very common software structure, and the way dbus works. > How does D-Bus come into this mess? what's wrong with dbus? > Surely the resources provided by the > filesystem should be all that is required for compilation and regression > testing? This is not some kind of network client, or if it somehow is, > that functionality should not be required to just build the distribution > package. nothing in there talks about *network*. But doesn't mean that different pieces of software can't talk to each other locally through other means. > Again, note that this particular test was not present in previous > versions, which is why it never caused a problem before. Again, so what? Just for your information, what I figured after a while is that, in that failing build the following weird things are happening, compared to my local build: * there is no dbus installed But the build log has: -- Found dbus-1, version 1.12.20 -- Found dbus-glib-1, version 0.112 so, mh... it install the library it wants alright, but not the dbus service itself. * there is no libfontconfig1-dev But I need to check if something actually need it; at least at configure step it doesn't seem to be checked. * there is no librsvg2-(2|common|dev) It should not need the dev library, but I suspect the librsvg2-common is *the* one package that normally triggers the shared-mime-info dpkg trigger, that is what I suspect is causing the test to fail. * it's using graphicsmagic instead of imagemagick, which is probably the cause of all of the above This points to, at the very least, a bunch of missing build-dependencies that are probably pulled in by imagemagick normally (but not by graphicsmagic, which is set as Provides:imagegick but it's really way too different…). And, perhaps, a lack of some checking at configure time on the inkscape side. I don't know why in experimental graphicsmagic is pulled in, but given the different dependency resolver than unstable it's not quite surprising. I'll now try to reproduce it locally given these new hints and hopefully come back with something working. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#994741: regression tests: skipped vs failed
On Wed, Sep 22, 2021 at 03:31:36PM +0300, Andrius Merkys wrote: > On 2021-09-21 20:03, Mattia Rizzolo wrote: > > Then, concerning the ftbfs of 1.1. I know of it of course. Just that > > I've been busy over the past month. I'm as weirded out by that test > > failure as you, especially since I couldn't reproduce it anywhere else. > > But no, I'm not going to ignore a test failure just because it's skipped > > in other architectures for different reasons: I'll need more convincing > > reasons. > > Thanks Mattia for letting us know you are working on it. Have you tried > building inkscape with network disabled? ?? of course. that's basically standard building env for me since I use pbuilder. by contrast, know that the debian buildds do *not* disable the network. Anyway, I'm first going to upload 1.1.1 to experimental today and see how that goes, otherwise I'm going to start debugging more. There is also another failure I need to take care of, as building in ubuntu exposed an unaligned memory access that causes bus errors in armhf (when run in a arm64 cpu). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#993638: [xml/sgml-pkgs] Bug#993638: libxml2: XHTML 1.0 validation is broken
On Mon, Sep 20, 2021 at 11:41:38AM +0200, Vincent Lefevre wrote: > Please also make sure that the NEWS file is up-to-date; see my other > message. This is also useful for the user when getting regressions > in general (possibly from bug fixes like here). I'm not sure I'd like to add such item to the Debian's NEWS. It would stop updates for too many users that most likely are not affected. For now, you are really the only one that brought up this issue. > BTW, the error message should be more detailed, e.g. saying which > entity and which URI. This would have made debugging so much easier. > But that's a separate issue; I'll report a bug upstream if this has > not already been done. It hasn't been done, so you should raise a bug with them if you think they should. > I'm wondering whether this check for invalid redeclarations of > predefined entities should also go to Debian/stable since it fixes > an integer overflow at the same time: > > https://gitlab.gnome.org/GNOME/libxml2/-/issues/217 > > Any security issue related to that? AFAIK not yet at least. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#993638: marked as pending in libxml2
Control: tag -1 pending Hello, Bug #993638 in libxml2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/xml-sgml-team/libxml2/-/commit/09914caee210cebce062ea771d37c3865b6fd5bd Add a Conflicts against the old w3c-dtd-xhtml, that contains a .dtd that is not validating anymore Closes: #993638 Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/993638
Bug#993638: [xml/sgml-pkgs] Bug#993638: libxml2: XHTML 1.0 validation is broken
On Mon, Sep 20, 2021 at 03:55:39AM +0200, Vincent Lefevre wrote: > Control: retitle -1 libxml2: XHTML 1.0 validation is broken with > w3c-dtd-xhtml's xhtml-special.ent file > > This should be reproducible with w3c-dtd-xhtml's xhtml-special.ent file. > The summary of the actual issue is below. Yes, indeed it is. > > The errors correspond to amp and lt. > > > > Now, I don't know whether the new libxml2 version is too picky, > > or there was a real issue with the old entity files (ignored > > by all parsers until now?). I bisected libxml2: 01411e7c5ea0fff181271e092f46a2138c3720ec is the first bad commit commit 01411e7c5ea0fff181271e092f46a2138c3720ec Author: Nick Wellnhofer Date: Mon Feb 8 20:58:32 2021 +0100 Check for invalid redeclarations of predefined entities https://gitlab.gnome.org/GNOME/libxml2/-/commit/01411e7c5ea0fff181271e092f46a2138c3720ec So it's clearly intentional of libxml2 to be more picky now, and flag this issue in the old dtd. > > In the latter case, I think that > > there should be a Breaks against w3c-dtd-xhtml. On its way. Thanks for your help in debugging this issue. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#994307: marked as pending in libxml2
Control: tag -1 pending Hello, Bug #994307 in libxml2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/xml-sgml-team/libxml2/-/commit/ecf1b93b9949a816321a9e9a1e88f8e671bfc2f8 Stop building the python3-libxml2-dbg package. Closes: #994307 Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/994307
Bug#993638: [xml/sgml-pkgs] Bug#993638: libxml2: XHTML 1.0 validation is broken
On Sun, Sep 19, 2021 at 09:45:19PM +0200, Vincent Lefevre wrote: > On 2021-09-19 19:15:54 +0200, Mattia Rizzolo wrote: > > I can never manage to download DTDs from w3.org (how could you?!), so, > > taking your testcase and a copy of the same DTD: > > The DTD is provided by Debian, no need to download it. But you need to instruct xmllint to use said DTD, it won't by its own decision to pick a random DTD from the filesystem. I also know how to use apt-file myself: | % apt-file search xhtml1-strict.dtd | dita-ot: /usr/share/dita-ot/demo/h2d/dtd/xhtml1-strict.dtd | erlang-erl-docgen: /usr/lib/erlang/lib/erl_docgen-1.1.1/priv/dtd/xhtml1-strict.dtd | kate5-data: /usr/share/katexmltools/xhtml1-strict.dtd.xml | libpxp-ocaml-dev: /usr/share/doc/libpxp-ocaml-dev/examples/namespaces/xhtml1-strict.dtd.gz | librdf-rdfa-parser-perl: /usr/share/perl5/auto/share/dist/RDF-RDFa-Parser/catalogue/www.w3.org/MarkUp/DTD/xhtml1-strict.dtd | w3-recs: /usr/share/doc/w3-recs/html/www.w3.org/TR/2002/REC-xhtml1-20020801/DTD/xhtml1-strict.dtd.gz | w3c-sgml-lib: /usr/share/xml/w3c-sgml-lib/schema/dtd/REC-xhtml1-20020801/xhtml1-strict.dtd | xemacs21-basesupport: /usr/share/xemacs21/xemacs-packages/etc/psgml-dtds/xhtml1-strict.dtd | xmlcopyeditor: /usr/share/xmlcopyeditor/dtd/xhtml1-strict.dtd | % indeed the one I used is the one from xmlcopyeditor (I picked a random package, trusting that said .dtd is actually the same as all of the above). > > mattia@warren /tmp/tmp/xml % xmllint --dtdvalid xhtml1-strict.dtd --nonet > > --noout test.html > > I/O error : Attempt to load network entity > > http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd > > test.html:2: warning: failed to load external entity > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; > > C//DTD XHTML 1.0 Strict//EN" > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; > > > >^ > > mattia@warren /tmp/tmp/xml % > > > > which looks good to me. > > An I/O error is not good. Your system appears to be broken. My system is fine. That error message is only a red herring due to --nonet, and indeed the return code of xmllint is 0. If you prefer, I can modify the DOCTYPE and do this instead, so there won't be "I/O error"s and the return code is clear: mattia@warren /tmp/tmp/xml % cat test.html http://www.w3.org/1999/xhtml;> title text mattia@warren /tmp/tmp/xml % xmllint --noout --nonet test.html ; echo $? 0 mattia@warren /tmp/tmp/xml % dpkg -l libxml2|tail -n1 ii libxml2:amd64 2.9.12+dfsg-4 amd64GNOME XML library mattia@warren /tmp/tmp/xml % -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#993638: [xml/sgml-pkgs] Bug#993638: libxml2: XHTML 1.0 validation is broken
Control: tag -1 unreproducible
On Sat, Sep 04, 2021 at 03:40:17AM +0200, Vincent Lefevre wrote:
> After the upgrade to 2.9.12+dfsg-3, XHTML 1.0 validation is broken.
> There was no such issue with 2.9.10+dfsg-6.7.
Actually, I can't reproduce it.
And, honestly, I think that if really didn't work I would have heard
quite a lot of noise by now.
> $ xmllint --noout --loaddtd --valid test.html
> error : xmlAddEntity: invalid redeclaration of predefined entity
> error : xmlAddEntity: invalid redeclaration of predefined entity
I can never manage to download DTDs from w3.org (how could you?!), so,
taking your testcase and a copy of the same DTD:
mattia@warren /tmp/tmp/xml % l
total 68
-rw-r--r-- 1 mattia mattia 260 Sep 19 19:02 test.html
-rw-r--r-- 1 mattia mattia 26450 Sep 6 2014 xhtml1-strict.dtd
-rw-r--r-- 1 mattia mattia 12055 Sep 6 2014 xhtml-lat1.ent
-rw-r--r-- 1 mattia mattia 4293 Sep 6 2014 xhtml-special.ent
-rw-r--r-- 1 mattia mattia 14167 Sep 6 2014 xhtml-symbol.ent
mattia@warren /tmp/tmp/xml % cat test.html
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml;>
title
text
mattia@warren /tmp/tmp/xml % xmllint --dtdvalid xhtml1-strict.dtd --nonet
--noout test.html
I/O error : Attempt to load network entity
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
test.html:2: warning: failed to load external entity
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
^
mattia@warren /tmp/tmp/xml %
which looks good to me.
This is with the current 2.9.12+dfsg-4.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#991606: marked as pending in ruby-libxml
On Tue, Aug 31, 2021 at 10:49:05AM -0400, Sergio Durigan Junior wrote: > On Tuesday, August 31 2021, Mattia Rizzolo wrote: > > > On Mon, Aug 30, 2021 at 09:54:29PM +, Sergio Durigan Junior wrote: > >> Bug #991606 in ruby-libxml reported by you has been fixed in the > >> Git repository and is awaiting an upload. You can see the commit > >> message below and you can check the diff of the fix at: > >> > >> https://salsa.debian.org/ruby-team/ruby-libxml/-/commit/93e491e68dfef33329834820e45e911d01e3d89c > > > > I haven't tried, but doesn't this cause the tests to fail with libxml2 > > << 2.9.12, such as what's currently in unstable? > > Yes, it would cause regressions with libxml2 2.9.10. This should only > be uploaded when libxml2 2.9.12 is also uploaded to unstable. I think I > should have made it clearer in the changelog; sorry about that. if that's true, then you likely should add a build-depends on the newer libxml2. fwiw, I just uploaded libxml2 2.9.12 to unstable, so please go ahead with the upload. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#991606: marked as pending in ruby-libxml
On Mon, Aug 30, 2021 at 09:54:29PM +, Sergio Durigan Junior wrote:
> Bug #991606 in ruby-libxml reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
>
> https://salsa.debian.org/ruby-team/ruby-libxml/-/commit/93e491e68dfef33329834820e45e911d01e3d89c
I haven't tried, but doesn't this cause the tests to fail with libxml2
<< 2.9.12, such as what's currently in unstable?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#991606: ruby-libxml: test failures with libxml2 2.9.12
On Fri, Aug 20, 2021 at 11:20:38PM +0530, Pirate Praveen wrote:
> Control: forwarded -1 https://github.com/xml4r/libxml-ruby/issues/172
>
> On Wed, 28 Jul 2021 15:35:58 +0200 Mattia Rizzolo wrote:
> > Source: ruby-libxml
> > Version: 3.2.0-1
> > Severity: serious
>
> Do we keep serious severity for failure only in experimental? Don't we wait
> till libxml2 2.9.12 hits unstable to raise severity?
mh no.
sev:serious is very appropriate for something that is just about to land
in unstable RSN :)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#991606: ruby-libxml: test failures with libxml2 2.9.12
Source: ruby-libxml Version: 3.2.0-1 Severity: serious Tags: sid bookworm Dear maintainer, running autopkgtest against libxml2/2.9.12 (as currently found in experimental) fails: https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-libxml/13882963/log.gz -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8
On Sun, Jun 13, 2021 at 05:14:31PM +0200, Francesco Poli wrote:
> Hello,
> is there any progress on this [bug]?
I kinda lost track of it after I handled it in inkscape (since it's not
effectively out of my concerns).
Are there any other affected packages? If so, they probably ought to
tighten their dependencies.
(though I still think poppler should do something to fix this issue, but
as Ivo said, it's too late for bullseye).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8
On Wed, Apr 14, 2021 at 02:22:54PM +0200, Ivo De Decker wrote:
> > So, if that's what you think, should I upload an inkscape with a manual
> > dependency on libpoppler-glib8 >= 20.09.0?
>
> Yes, that would be useful.
I've just uploaded a new inkscape with this as its only change.
https://salsa.debian.org/multimedia-team/inkscape/-/commit/0a6972eebee178f90109c96e568cdce51b7b0276
And I've confirmed with a binary debdiff that the final Depends line in
the .deb is as expected.
It's probably a good idea if you could age the upload so it doesn't wait
20 days, and unblock it (since it's a key package).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8
On Sun, Apr 11, 2021 at 08:02:20PM +0200, Ivo De Decker wrote: > There is a theoretical and a practical aspect to this issue. From a > theoretical point of view, the dependency relations should not be stricter > than necessary, to allow partial upgrades and to avoid complicating > migration to testing of library transitions. Then again, I believe the project at large is moving towards stricter-than-necessary dependencies (see the implied dh_makeshlibs -V in dh compat 12, lintian nagging about the Build-Depends-Package in .symbols files, etc). I also don't believe a stricter dependency between libpoppler102 and libpoppler-glib8 would have any of the issue you mention. > It would create the desired dependency, but I'm not sure if this is better > than just manually adding it to the 2 remaining packages we are aware of > (especially at this stage of the freeze). > For now, though (and especially for bullseye), I think we should accept > that we aren't going to solve this issue in general. The best we can do, is > to try to fix obvious cases where we are aware of the issue. In other cases, > we'll probably need to advise our users to do a full upgrade instead of a > partial one. So, if that's what you think, should I upload an inkscape with a manual dependency on libpoppler-glib8 >= 20.09.0? (mhh, is there a way to do this without writing it in d/control?). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#980642: diagnostics: diff for NMU version 0.3.3-12.1
Dear maintainer,
I've prepared an NMU for diagnostics (versioned as 0.3.3-12.1). The diff
is attached to this message.
Since this package is in the LowNMU list, it's already uploaded.
Regards.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
diffstat for diagnostics-0.3.3 diagnostics-0.3.3
changelog | 10 ++
control |2 +-
patches/no-ltdl-convenience.patch | 25 +
patches/series|1 +
rules |1 -
5 files changed, 37 insertions(+), 2 deletions(-)
diff -Nru diagnostics-0.3.3/debian/changelog diagnostics-0.3.3/debian/changelog
--- diagnostics-0.3.3/debian/changelog 2016-12-04 09:54:25.0 +0100
+++ diagnostics-0.3.3/debian/changelog 2021-02-16 11:43:01.0 +0100
@@ -1,3 +1,13 @@
+diagnostics (0.3.3-12.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS due to using a convenience copy of ltdl. Closes: #980642
+Thanks to Dennis Filder for the patch.
+ * Drop explicit Build-Depends on automake1.11, the default automake version
+is good for this package. Closes: #865142
+
+ -- Mattia Rizzolo Tue, 16 Feb 2021 11:43:01 +0100
+
diagnostics (0.3.3-12) unstable; urgency=low
* Bump Standards Version to 3.9.8 (no changes)
diff -Nru diagnostics-0.3.3/debian/control diagnostics-0.3.3/debian/control
--- diagnostics-0.3.3/debian/control 2016-12-04 09:54:25.0 +0100
+++ diagnostics-0.3.3/debian/control 2021-02-16 11:40:47.0 +0100
@@ -1,7 +1,7 @@
Source: diagnostics
Priority: extra
Maintainer: Michael Tautschnig
-Build-Depends: dpkg-dev (>= 1.16.0~), debhelper (>= 9), automake1.11 | automake (>= 1:1.9), pkg-config, libtool, libltdl-dev (>= 2.4.2-1~), libace-dev (>= 5.7.7-3) [!hurd-i386], dh-autoreconf
+Build-Depends: dpkg-dev (>= 1.16.0~), debhelper (>= 9), automake, pkg-config, libtool, libltdl-dev (>= 2.4.2-1~), libace-dev (>= 5.7.7-3) [!hurd-i386], dh-autoreconf
Standards-Version: 3.9.8
Section: libs
Homepage: http://forsyte.at/software/diagnostics
diff -Nru diagnostics-0.3.3/debian/patches/no-ltdl-convenience.patch diagnostics-0.3.3/debian/patches/no-ltdl-convenience.patch
--- diagnostics-0.3.3/debian/patches/no-ltdl-convenience.patch 1970-01-01 01:00:00.0 +0100
+++ diagnostics-0.3.3/debian/patches/no-ltdl-convenience.patch 2021-02-16 11:32:47.0 +0100
@@ -0,0 +1,25 @@
+Description: Disable AC_LIBLTDL_CONVENIENCE and use the distro's ltdl
+ For some reason configure.ac enables AC_LIBLTDL_CONVENIENCE which is
+ rather pointless in a distro that comes with its own ltdl and also
+ interferes with the build (#980642). This patch disables that.
+Author: Dennis Filder
+Bug-Debian: https://bugs.debian.org/980642
+Last-Update: 2021-02-10
+
+--- diagnostics-0.3.3/configure.ac
diagnostics-0.3.3/configure.ac
+@@ -29,9 +29,11 @@ AC_PROG_LN_S
+ AC_PROG_MAKE_SET
+ AC_PROG_AWK
+ # new libtool versions:
+-# LT_INIT
+-# LTDL_INIT
+-AC_LIBLTDL_CONVENIENCE
++LT_INIT
++LTDL_INIT
++
++#AC_LIBLTDL_CONVENIENCE # disabled as this is pointless/redundant in
++# # a distro shipping its own ltdl (see also: #652201)
+ AC_WITH_LTDL
+ AC_PROG_LIBTOOL
+
diff -Nru diagnostics-0.3.3/debian/patches/series diagnostics-0.3.3/debian/patches/series
--- diagnostics-0.3.3/debian/patches/series 2016-12-04 09:54:25.0 +0100
+++ diagnostics-0.3.3/debian/patches/series 2021-02-16 11:32:11.0 +0100
@@ -4,3 +4,4 @@
gcc-warns-successfully
gcc-6-destructor-is-noexcept
test-run-cleanup
+no-ltdl-convenience.patch
diff -Nru diagnostics-0.3.3/debian/rules diagnostics-0.3.3/debian/rules
--- diagnostics-0.3.3/debian/rules 2014-07-07 13:42:50.0 +0200
+++ diagnostics-0.3.3/debian/rules 2021-02-16 11:33:00.0 +0100
@@ -27,7 +27,6 @@
--prefix=/usr --mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
--disable-update-makefiles \
- --with-ltdl-include=/usr/include --with-ltdl-lib=/usr/lib/$(DEB_HOST_MULTIARCH) \
CXXFLAGS="$(CXXFLAGS)" # LDFLAGS="-Wl,-z,defs"
override_dh_auto_test:
signature.asc
Description: PGP signature
Bug#835340: Bug#938076: python-pymetar: Python2 removal in sid/bullseye
On Sat, Feb 06, 2021 at 08:37:45PM +0100, gregor herrmann wrote: > > Find attached the full debdiff and the filtered debdiff with only the > > debian/* files. > > > > I tried to find a balance between doing all necessary changes and not > > completely overhauling the packaging. It seems that the resulting > > binary package works, both the commandline script and the module in > > ipython3, but as I'm not a python person I'd welcome reviews and > > suggestions for improvement. > > I don't feel confident uploading this NMU myself but I'd like to see > python-pymetar in bullseye. Very quickly looking at the filter diff for debian/*, that looks just fine. But it's too late for bullseye. Without an autopkgtest (which I'm not going to write myself not knowing the package), this will go over the 12th, and as such won't be due to the freeze policy. > Is this something the Debian Python Team could take over? I'll keep a tab open to review and sponsor the nmu (but anybody feel free to beat me). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#980922: debian-games: please move to the new name udd-mirror.debian.net
Package: debian-games Version: 3.2 Severity: serious Hi! Looking at codesearch.debian.net, it looks like debian-games is the only package using the name public-udd-mirror.xvm.net in its src/debian_games_updater.py. Please change: conn = connect( database='udd', port=5432, host='public-udd-mirror.xvm.mit.edu', user='public-udd-mirror', password='public-udd-mirror') to: conn = connect( database='udd', port=5432, host='udd-mirror.debian.net', user='udd-mirror', password='udd-mirror') to help us deprecate the former name. As announced in https://lists.debian.org/debian-qa/2020/11/msg00011.html we don't plan to remove public-udd-mirror.xvm.mit within less than a year. I'm filing this bug as RC, as I wouldn't want this package to break during the course of bullseye if it's released as it is and then the old hostname gets retired. If you consider that script unimportant then feel free to downgrate the severity. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#975494: marked as pending in vdirsyncer
Control: tag -1 pending Hello, Bug #975494 in vdirsyncer reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/vdirsyncer/-/commit/7ec60c089c8232bccd63f32d42b346868286bb07 Add patch to replace deprecated getiterator() by python3.9 compatible iter() Closes: #975494 (this message was generated automatically) -- Greetings https://bugs.debian.org/975494
Bug#976935: marked as pending in inkscape
Control: tag -1 pending Hello, Bug #976935 in inkscape reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/multimedia-team/inkscape/-/commit/2e2b302c34c7be0dad92a1cbd1b30fafcb73d8b5 Switch build system from cmake+make to cmake+ninja. + Fixes FTBFS with a very high level of parallelism. Closes: #976935 Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/976935
Bug#980038: marked as pending in kodi
Control: tag -1 pending Hello, Bug #980038 in kodi reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/multimedia-team/kodi-media-center/kodi/-/commit/e15c8192e58fbaf94b1aabcf78864d90bf8678af Refresh cdatetime-std-chrono topic (Closes: #980038) Imported as: git format-patch --stdout master..HEAD -- . \ ':(exclude)tools/depends' \ ':(exclude)xbmc/platform/darwin' \ ':(exclude)xbmc/platform/win32' \ 1>../cdatetime-std-chrono.patch Signed-off-by: Vasyl Gello (this message was generated automatically) -- Greetings https://bugs.debian.org/980038
Bug#970580: marked as pending in licenseutils
Control: tag -1 pending Hello, Bug #970580 in licenseutils reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/licenseutils/-/commit/094384f75e270a30cf9cd58f60065585d2b02cd0 Add patch to prevent a segfault when trying to download license files that have been redirected Closes: #970580 Thanks: handsome_feng for the patch Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/970580
Bug#977083: pristine-tar: fails to checkout when there are multiple source tarballs
Control: reassign -1 git-buildpackage
Control: forcemerge 917789 -1
On Fri, Dec 11, 2020 at 01:39:35AM +0530, Pirate Praveen wrote:
> Package: pristine-tar,git-buildpackage,devscripts
> Control: found -1 pristine-tar/1.49
> Control: found -1 devscripts/2.20.5
> Control: found -1 git-buildpackage/0.9.20
> severity: serious
please, how could this be serios for either of them…
> I'm filing against all 3 possible packages which might have a bug here.
>
> Example package node-mermaid. It fails on all packages that uses multiple
> source tarballs. (gitlab is another example and many node packages use
> multiple source tarballs).
>
> These are usually created with gbp import-orig --pristine-tar
>
> We have to always fall back to 'apt source' command whcih makes pristine-tar
> useless in these situations.
>
> I think origtargz should try apt source when pristine-tar fails.
>
> I'm not sure if it fails only with tar.xz though.
>
> $ origtargz
> pristine-tar: successfully generated
> ./node-mermaid_8.7.0+ds+~cs27.17.17.orig-webpack-node-externals.tar.xz
> pristine-tar: successfully generated
> ./node-mermaid_8.7.0+ds+~cs27.17.17.orig-stylis.tar.xz
> pristine-tar: successfully generated
> ./node-mermaid_8.7.0+ds+~cs27.17.17.orig-strip-css-comments.tar.xz
> pristine-tar: successfully generated
> ./node-mermaid_8.7.0+ds+~cs27.17.17.orig-slugify.tar.xz
> pristine-tar: successfully generated
> ./node-mermaid_8.7.0+ds+~cs27.17.17.orig-scope-css.tar.xz
> pristine-tar: successfully generated
> ./node-mermaid_8.7.0+ds+~cs27.17.17.orig-sanitize-url.tar.xz
> pristine-tar: successfully generated
> ./node-mermaid_8.7.0+ds+~cs27.17.17.orig-khroma.tar.xz
> pristine-tar: successfully generated
> ./node-mermaid_8.7.0+ds+~cs27.17.17.orig-is-regexp.tar.xz
> pristine-tar: successfully generated
> ./node-mermaid_8.7.0+ds+~cs27.17.17.orig-escaper.tar.xz
> pristine-tar: successfully generated
> ./node-mermaid_8.7.0+ds+~cs27.17.17.orig-entity-decode.tar.xz
> pristine-tar: successfully generated
> ./node-mermaid_8.7.0+ds+~cs27.17.17.orig-crypto-random-string.tar.xz
> fatal: ambiguous argument 'cb3a82caf3951fbab382b5a0d7dbdd7936bee2c4^{tree}':
> unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git [...] -- [...]'
> fatal: not a valid object name:
> cb3a82caf3951fbab382b5a0d7dbdd7936bee2c4^{tree}
> tar: This does not look like a tar archive
> tar: Exiting with failure status due to previous errors
> pristine-tar: command failed: git archive --format=tar
> cb3a82caf3951fbab382b5a0d7dbdd7936bee2c4\^\{tree\} | (cd
> '/tmp/pristine-tar.x11yV6IWxf' && tar x)
See #917789 - that's what you are seeing.
gbp import-orig does extra things (that honestly I don't understand why
they are needed), and plain pristine-tar can't checkout a tarball, as
the tree id recorded are something that is build especially by gbp. You
need to use `gbp export-orig` to export such tarballs.
> $ pristine-tar checkout ../node-mermaid_8.7.0+ds+~cs27.17.17.orig.tar.xz
> fatal: ambiguous argument 'cb3a82caf3951fbab382b5a0d7dbdd7936bee2c4^{tree}':
> unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git [...] -- [...]'
> fatal: not a valid object name:
> cb3a82caf3951fbab382b5a0d7dbdd7936bee2c4^{tree}
> tar: This does not look like a tar archive
> tar: Exiting with failure status due to previous errors
> pristine-tar: command failed: git archive --format=tar
> cb3a82caf3951fbab382b5a0d7dbdd7936bee2c4\^\{tree\} | (cd
> '/tmp/pristine-tar.JY3lejdcNL' && tar x)
If you wish to use `pristine-tar checkout` see #917789 that contains a
way to hack the .id files so that pristine-tar can do its work again
directly, without the help from gbp.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#958912: marked as pending in devscripts
Control: tag -1 pending Hello, Bug #958912 in devscripts reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/devscripts/-/commit/cfba366c772d1761f5e31c9ac332718e5d9043fe test_debchange: skip Ubuntu tests when there is no known development release, like right after an Ubuntu release. Closes: #958912 Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/958912
Bug#964592: libjson-rpc-cpp: diff for NMU version 0.7.0-1.1
Control: tags 964592 + patch
Control: tags 964592 + pending
Dear maintainer,
I'm sponsoring an NMU prepared by Baptiste Beauplat for libjson-rpc-cpp
(versioned as 0.7.0-1.1) and uploaded it to DELAYED/2.
Please feel free to tell me if I should delay it longer.
Regards.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
diffstat for libjson-rpc-cpp-0.7.0 libjson-rpc-cpp-0.7.0
changelog |8 +
control|4
patches/0002-Fix-FTBFS-with-libmicrohttpd-0.9.71.patch | 77 +
patches/series |1
4 files changed, 88 insertions(+), 2 deletions(-)
diff -Nru libjson-rpc-cpp-0.7.0/debian/changelog libjson-rpc-cpp-0.7.0/debian/changelog
--- libjson-rpc-cpp-0.7.0/debian/changelog 2016-08-16 10:20:11.0 +0200
+++ libjson-rpc-cpp-0.7.0/debian/changelog 2020-10-08 22:45:52.0 +0200
@@ -1,3 +1,11 @@
+libjson-rpc-cpp (0.7.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS with libmicrohttpd 0.9.71 (Closes: #964592)
+ * debian/control: Requires libmicrohttpd-dev (>= 0.9.71)
+
+ -- Baptiste Beauplat Thu, 08 Oct 2020 22:45:52 +0200
+
libjson-rpc-cpp (0.7.0-1) unstable; urgency=medium
* Imported Upstream version 0.7.0
diff -Nru libjson-rpc-cpp-0.7.0/debian/control libjson-rpc-cpp-0.7.0/debian/control
--- libjson-rpc-cpp-0.7.0/debian/control 2016-08-16 10:20:11.0 +0200
+++ libjson-rpc-cpp-0.7.0/debian/control 2020-10-08 22:45:52.0 +0200
@@ -7,7 +7,7 @@
libargtable2-dev,
libcurl4-openssl-dev | libcurl4-nss-dev,
libjsoncpp-dev,
- libmicrohttpd-dev
+ libmicrohttpd-dev (>= 0.9.71)
Standards-Version: 3.9.8.0
Section: libs
Homepage: https://github.com/cinemast/libjson-rpc-cpp
@@ -200,7 +200,7 @@
libjsonrpccpp-common0 (= ${binary:Version}),
libjsonrpccpp-server0 (= ${binary:Version}),
libjsonrpccpp-stub0 (= ${binary:Version}),
- libmicrohttpd-dev,
+ libmicrohttpd-dev (>= 0.9.71),
${misc:Depends}
Description: development files for JSON-RPC C++ framework
This package provides all required developer resources like header-files
diff -Nru libjson-rpc-cpp-0.7.0/debian/patches/0002-Fix-FTBFS-with-libmicrohttpd-0.9.71.patch libjson-rpc-cpp-0.7.0/debian/patches/0002-Fix-FTBFS-with-libmicrohttpd-0.9.71.patch
--- libjson-rpc-cpp-0.7.0/debian/patches/0002-Fix-FTBFS-with-libmicrohttpd-0.9.71.patch 1970-01-01 01:00:00.0 +0100
+++ libjson-rpc-cpp-0.7.0/debian/patches/0002-Fix-FTBFS-with-libmicrohttpd-0.9.71.patch 2020-10-08 22:45:52.0 +0200
@@ -0,0 +1,77 @@
+From: Baptiste Beauplat
+Date: Thu, 8 Oct 2020 22:44:11 +0200
+Subject: Fix FTBFS with libmicrohttpd 0.9.71
+
+Closes: #964592
+Bug: https://github.com/cinemast/libjson-rpc-cpp/issues/298
+---
+ src/jsonrpccpp/server/connectors/httpserver.cpp | 2 +-
+ src/jsonrpccpp/server/connectors/httpserver.h | 2 +-
+ src/test/testhttpserver.cpp | 4 ++--
+ src/test/testhttpserver.h | 4 ++--
+ 4 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/src/jsonrpccpp/server/connectors/httpserver.cpp b/src/jsonrpccpp/server/connectors/httpserver.cpp
+index 40d3c5e..d1bad41 100644
+--- a/src/jsonrpccpp/server/connectors/httpserver.cpp
b/src/jsonrpccpp/server/connectors/httpserver.cpp
+@@ -119,7 +119,7 @@ void HttpServer::SetUrlHandler(const string , IClientConnectionHandler *hand
+ this->SetHandler(NULL);
+ }
+
+-int HttpServer::callback(void *cls, MHD_Connection *connection, const char *url, const char *method, const char *version, const char *upload_data, size_t *upload_data_size, void **con_cls)
++MHD_Result HttpServer::callback(void *cls, MHD_Connection *connection, const char *url, const char *method, const char *version, const char *upload_data, size_t *upload_data_size, void **con_cls)
+ {
+ (void)version;
+ if (*con_cls == NULL)
+diff --git a/src/jsonrpccpp/server/connectors/httpserver.h b/src/jsonrpccpp/server/connectors/httpserver.h
+index 075962c..0f66423 100644
+--- a/src/jsonrpccpp/server/connectors/httpserver.h
b/src/jsonrpccpp/server/connectors/httpserver.h
+@@ -71,7 +71,7 @@ namespace jsonrpc
+
+ std::map urlhandler;
+
+-static int callback(void *cls, struct MHD_Connection *connection, const char *url, const char *method, const char *version, const char *upload_data, size_t *upload_data_size, void **con_cls);
++static MHD_Result callback(void *cls, struct MHD_Connection *connection, const char *url, const char *method
Bug#958598: triggerhappy: diff for NMU version 0.5.0-1.1
Control: tags 958598 + patch
Control: tags 958598 + pending
Dear maintainer,
I'm sponsoring an NMU by Baptiste Beauplat for triggerhappy (versioned
as 0.5.0-1.1) and uploaded it to DELAYED/2. Please feel free to tell me
if I should delay it longer.
Regards.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
diffstat for triggerhappy-0.5.0 triggerhappy-0.5.0
changelog | 13 +
compat|1 -
control |3 ++-
rules |2 +-
4 files changed, 16 insertions(+), 3 deletions(-)
diff -Nru triggerhappy-0.5.0/debian/changelog triggerhappy-0.5.0/debian/changelog
--- triggerhappy-0.5.0/debian/changelog 2016-08-30 09:26:25.0 +0200
+++ triggerhappy-0.5.0/debian/changelog 2020-10-07 12:03:39.0 +0200
@@ -1,3 +1,16 @@
+triggerhappy (0.5.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix Build-Depends on deprecated dh-systemd (Closes: #958598)
+- Replace debhelper by debhelper-compat
+- Bump debhelper-compat to 13
+- Remove debian/compat file
+- Remove dh-systemd dependency
+- Remove systemd dh addon
+- Add missing ${misc:Pre-Depends}
+
+ -- Baptiste Beauplat Wed, 07 Oct 2020 12:03:39 +0200
+
triggerhappy (0.5.0-1) unstable; urgency=medium
* add new upstream release 0.5.0 (Closes: #834637, #835980)
diff -Nru triggerhappy-0.5.0/debian/compat triggerhappy-0.5.0/debian/compat
--- triggerhappy-0.5.0/debian/compat 2016-08-30 09:26:25.0 +0200
+++ triggerhappy-0.5.0/debian/compat 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-9
diff -Nru triggerhappy-0.5.0/debian/control triggerhappy-0.5.0/debian/control
--- triggerhappy-0.5.0/debian/control 2016-08-30 09:26:25.0 +0200
+++ triggerhappy-0.5.0/debian/control 2020-10-07 12:03:39.0 +0200
@@ -2,7 +2,7 @@
Section: utils
Priority: extra
Maintainer: Stefan Tomanek
-Build-Depends: debhelper (>= 9), linux-libc-dev, pkg-config, libsystemd-dev, dh-systemd (>= 1.5)
+Build-Depends: debhelper-compat (= 13), linux-libc-dev, pkg-config, libsystemd-dev
Standards-Version: 3.9.8
Homepage: https://github.com/wertarbyte/triggerhappy
Vcs-Git: https://github.com/wertarbyte/triggerhappy.git
@@ -10,6 +10,7 @@
Package: triggerhappy
Architecture: linux-any
+Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}, libsystemd0
Description: global hotkey daemon for Linux
Triggerhappy watches connected input devices for certain key presses
diff -Nru triggerhappy-0.5.0/debian/rules triggerhappy-0.5.0/debian/rules
--- triggerhappy-0.5.0/debian/rules 2016-08-30 09:26:25.0 +0200
+++ triggerhappy-0.5.0/debian/rules 2020-10-07 12:03:39.0 +0200
@@ -4,4 +4,4 @@
export DEB_BUILD_MAINT_OPTIONS=hardening=+all
%:
- dh $@ --with=systemd
+ dh $@
signature.asc
Description: PGP signature
Bug#971220: marked as pending in dput-ng
Control: tag -1 pending Hello, Bug #971220 in dput-ng reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/dput-ng/-/commit/7d38f31e9f89332cd72ba926d6b413e607890e74 sphinx: drop duplicated NoSuchConfigError object in the sphinx config Closes: #971220 Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/971220
Bug#970580: licenseutils: Memory access error
Control: forwarded -1 https://savannah.nongnu.org/bugs/?59157 On Sat, Sep 19, 2020 at 10:24:38AM +0200, Mechtilde Stehmann wrote: > At the first start I got > > licensing gpl: got unexpected response code 302 from > www.gnu.org/licenses/gpl.txt > > I also tested more options and get "Memory access error" > > No option gives a result thank you, forwarded upstream at the above URL. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#936941: marked as pending in libxml2
Control: tag -1 pending Hello, Bug #936941 in libxml2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/xml-sgml-team/libxml2/-/commit/38ac8993eb1448fba0814ae07e846f7d359b Drop Python2 support This reverts commit ca594ede70250ec42e08f5747a191ff57d1e08e2. Closes: #936941 (this message was generated automatically) -- Greetings https://bugs.debian.org/936941
Bug#968756: inkscape: Inkscape crash on multiple undo-redo actions
On Fri, Aug 21, 2020 at 01:53:32AM +0200, Anon1336 wrote: > At first, I thought it was a one-time bug so I tried using the bpo. > Once again, under the same conditions, Inkscape crashed. Finally, I > tried using the 1.0 AppImage (to test "sterile" and see if this was > Debian-specific or Inkscape in general). The result is the same. Since > it wasn't a "world-ender" bug, I went back to using the native Debian > bpo and decided to just save a lot (side-note: auto-save and recovery > still occasionally fails). Since you tried the AppImage and reproduced with that as well, could you consider filing a bug report upstream directly at https://gitlab.com/inkscape/inbox ? Also, I'm uploading now 1.0-5 to backports, if you could see whether that also triggers this crash it would be useful (1.0-2 disable a bunch of asserts that might or might not be relevant). > The errors (see below) point to the problem being Inkscape-specific (the core > lib), so it's very concerning that there's this "domino effect". > > Here's the relevant dmesg outputs: > inkscape[18142]: segfault at 148 ip 7efbfefec5db sp 7ffb9620 > error 4 in libinkscape_base.so[7efbfe58a000+bb] > traps: inkscape[28062] general protection fault ip:7efbfeed39a1 > sp:7ffb8520 error:0 in libinkscape_base.so[7efbfe58a000+bb] > > If I have time, I'll try running Inkscape and Thunar from two consoles and > try to reproduce the error. Hopefully it'll shed some light on it. Hopefully > still, I won't need to. Likewise, if you can get a stacktrace it usually helps nailing down where the bug is. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#963322: marked as pending in dput-ng
Control: tag -1 pending Hello, Bug #963322 in dput-ng reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/dput-ng/-/commit/de3d28aca4bb688195496331e4a27ff692ec1777 tests: carry over PATH to the dpkg-buildpackage process. Closes: #963322 Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/963322
Bug#962221: Fixes for CVE-2020-13696 (#962221)
On Wed, Jul 08, 2020 at 09:07:25AM +0100, Jeremy Sowden wrote:
...
> The new upstream release added extra checks to ensure that the object at
> the end of the path is a device file of the right sort before opening
> it:
...
> However, the error messages still leak information, allowing the user to
> test for the existence of arbitrary files:
...
> The patch changes the error messages to prevent this:
...
Oh, I think I understand now. So I reckon with the extra patch this CVE
is fixed.
I'm going to upload this soon :)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#962221: Fixes for CVE-2020-13696 (#962221)
On Mon, Jul 06, 2020 at 09:07:31PM +, Vasyl Gello wrote:
> I pushed the modernized package however
..however it fails to build :)
dh_auto_install
install -d /build/xawtv-3.107/debian/tmp
make -j4 install DESTDIR=/build/xawtv-3.107/debian/tmp
AM_UPDATE_INFO_DIR=no
make[1]: Entering directory '/build/xawtv-3.107'
/usr/bin/install -c -d -m 755 /build/xawtv-3.107/debian/tmp/usr/bin
/usr/bin/install -c console/dump-mixers console/record console/showriff
console/showqt console/streamer console/webcam console/scantv console/ttv
console/radio console/fbtv console/v4l-info
/build/xawtv-3.107/debian/tmp/usr/bin
/usr/bin/install -c -m4755 -o root console/v4l-conf
/build/xawtv-3.107/debian/tmp/usr/bin
/usr/bin/install: cannot change ownership of
'/build/xawtv-3.107/debian/tmp/usr/bin/v4l-conf': Operation not permitted
make[1]: *** [console/Subdir.mk:100: install] Error 1
make[1]: Leaving directory '/build/xawtv-3.107'
dh_auto_install: error: make -j4 install DESTDIR=/build/xawtv-3.107/debian/tmp
AM_UPDATE_INFO_DIR=no returned exit code 2
make: *** [debian/rules:6: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
this is related to the addition of Rules-Requires-Root. When run
without fakeroot it's not possible to run such `chmod` commands. In
fact, they are most likely always wrong to run them anyway…
> there are two errors claiming two libs are not compiled against libc and
> several
> others missing requured prerequisites. I have not figured yet how to fix
> these,
> maybe you know?
I'll see them when I can fully build the package ;)
In d/copyright, that boilerplate-y thing you copied into the Comment
field, IMHO you should just get rid of it. Also, it's missing many of
the years in the copyright claims: a copyright claim without a year is
at most an legal headache and at worst invalid.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#962221: Fixes for CVE-2020-13696 (#962221)
On Mon, Jul 06, 2020 at 05:10:30AM +, Vasyl Gello wrote:
> Thanks for contributing the security release! I checked your changes and
> pushed them to the team repo.
> I do not have an upload rights, so CCing Sebastian and Mattia.
Sure,
but could either of you do a bunch of housekeeping work as well, like:
* bumping dh compat
* drop --dbgsym-migration
* drop the .menu files
* would be awesome to have the copyright file rewrote using dep-5
*
Also, the commit adding the CVE patch mentions "partial fix", as does
the sec-tracker page. Can anybody explain shortly what's with that,
where is the full fix (if there is), and how come the LTS upload claims
this to be fully fixed instead (CCing the LTS team and the uploader for
this).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#936805: kodi: Python2 removal in sid/bullseye
A few people are already working on kodi 19, and packages will start to appear in a few days in experimental. Actually there are related packages in NEW: dav1d was accepted a couple days ago, shairplay and libudfread. They are not compulsory dependencies, so not strictly blocking, but they were uploaded for kodi to link against them. On Sun, 5 Jul 2020, 5:51 pm Nicholas D Steeves, wrote: > Hi, > > On Fri, Aug 30, 2019 at 07:22:18AM +, Matthias Klose wrote: > > Package: src:kodi > > Version: 2:17.6+dfsg1-4 > > Severity: normal > > Tags: sid bullseye > > User: debian-pyt...@lists.debian.org > > Usertags: py2removal > > > > Python2 becomes end-of-live upstream, and Debian aims to remove > > Python2 from the distribution, as discussed in > > https://lists.debian.org/debian-python/2019/07/msg00080.html > > > > Your package either build-depends, depends on Python2, or uses Python2 > > in the autopkg tests. Please stop using Python2, and fix this issue > > by one of the following actions. > > > > [snip] > > This bug will be solved when updating to Kodi ≥ 19, which prominently > declares it migrated to Python 3. Of course some plugins might not be > py3 ready, so it's probably time to stage the kodi-without-py2 > packages in experimental and report bugs upstream. > > The Python Team is moving ahead with making at py2 dep RC for low > popcon leaf packages this week, and while there isn't a roadmap > (afaik), I suspect this bug will become serious this fall (2020). > > Thanks, > Nicholas >
Bug#961216: inkscape: symbol resolution problem
Control: reassign -1 libglibmm-2.4-dev 2.56.0-1
So, talking with people over at the Gnome team, this came out:
On Fri, May 22, 2020 at 10:30:20AM +1000, Peter Eckersley wrote:
> However this somehow fixed the problem?
>
> $ sudo apt-get build-dep inkscape
...
> The following packages will be upgraded:
...
> libenchant-2-2 libglibmm-2.4-1v5 libgtkspell3-3-0 liblcms2-2
↑↑
> > _ZN3Gio11Application35set_option_context_parameter_stringERKN4Glib7ustringE
So, that set_option_context_parameter_string thing comes from Glib 2.56,
but you have this piece of glibmm at 2.54 according to your initial
post.
Indeed it seems that your system had a broken update in the past, with
way too many old packages still laying around. I think you shold take
your time to fix it up and properly fully upgrade your system to
whatever distribution you are targetting. Whilst this bug can be fixed,
there is not that much support around for such half-upgraded systems.
The bug actually lies in libglibmm-2.4-1v5 which is not propagating the
proper versioned dependency, so I'm reassigning this bug to them. After
that inkscape will need a rebuild to pick it up, whever it will be.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#948074: din FTBFS: cannot find X11/X.h
I know that at the start of the year some reorganization within the X11 packages caused down FTBFS while files where being moving around. I recommend you just close this bug. FTR, it also builds in reproducible-builds testing. On Sun, 14 Jun 2020, 12:33 am Sudip Mukherjee, wrote: > Hi Helmut, > > On Fri, Jan 03, 2020 at 06:48:06PM +0100, Helmut Grohne wrote: > > Source: din > > Version: 5.2.1-6 > > Severity: serious > > Tags: ftbfs > > > > din fails to build from source in unstable on amd64. A build log ends > > with: > > I tried building it today and there was no build failure. > > > +--+ > | Summary > | > > +--+ > > Build Architecture: amd64 > Build Type: full > Build-Space: 79072 > Build-Time: 30 > Distribution: unstable > Host Architecture: amd64 > Install-Time: 65 > Job: din > Machine Architecture: amd64 > Package: din > Package-Time: 97 > Source-Version: 5.2.1-6 > Space: 79072 > Status: successful > Version: 5.2.1-6 > > > > Can you please retry the build and confirm. > > -- > Regards > Sudip > >
Bug#961532: devscripts: Missing package relation with pristine-tar (used by origtargz)
Control: severity -1 minor On Mon, May 25, 2020 at 08:02:59PM +0200, Axel Beckert wrote: > to my surprise the devscripts has no package relation with pristine-tar > nor is it mentioned in devscripts' long package description despite > origtargz uses it unconditionally. pristine-tar is though mentioned in > the origtargz(1) man page and changelog.Debian.gz. > > origtargz though ignores any errors from the pristine-tar (not sure if > feature or bug ;-), so a missing pristine-tar binary is not noticed > during usage as origtargz just falls back to other acquisition methods. It's a documented feature. origtargz tries to obtain the tarball, and just falls back through several retrival methods. As such, the pristine-tar is entirely optional. > I hence suggest as fix for this bug to add pristine-tar to either > Suggests or Recommends and mention it in the long package description as > optional (but IMHO for origtargz recommended) dependency of origtargz. Done, as recommends. See the README file for a description of the whole thing (which is then partially mirrored in the long description) > So while the RC severity is theoretically correct due to a missing > package relation, I have no issue if someone prefers to downgrade this > bug to e.g. important as it IMHO is not needed to prepare a devscripts > upload now just because of this bug report. Indeed, RC is way too overblown for such optional feature :3 Thank you for your report! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#961532: marked as pending in devscripts
Control: tag -1 pending Hello, Bug #961532 in devscripts reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/devscripts/-/commit/ed0eb494a53928894ac66d446e5505ad01d87296 Add pristine-tar to the Recommends for origtargz Closes: #961532 Signed-off-by: Mattia Rizzolo (this message was generated automatically) -- Greetings https://bugs.debian.org/961532
Bug#961216: inkscape: symbol resolution problem
Control: tag -1 moreinfo unreproducible On Thu, May 21, 2020 at 11:34:49PM +1000, Peter Eckersley wrote: > Package: inkscape > Version: 1.0-1 > Severity: grave > Justification: renders package unusable > > $ inkscape > inkscape: symbol lookup error: > /usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so: > undefined symbol: > _ZN3Gio11Application35set_option_context_parameter_stringERKN4Glib7ustringE I can't reproduce this. That symbol is Gio::Application::set_option_context_parameter_string(Glib::ustring const&) which obviously comes from this library you are also listing: > libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 > (0x7f7eda043000) Which seems to be installed: > ii libglib2.0-0 2.64.2-1 Regardless it's odd, obviously it works for me and many other people, such bug would have drawn many others to complain. Please double check your Glib installation… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
