Bug#1069929: transition: erlang
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: erl...@packages.debian.org Control: affects -1 + src:erlang Hi release team! I'd like to update Erlang for trixie to new major release Erlang 27 which is due in upcoming May or June. Since currently Erlang 25 is in Debian (two major releases short) I expect some failures of rebuilding existing packages (Erlang 27 introduces new expressions, removes some deprecated functions etc.). I've already uploaded erlang 1:27.0+dfsg~rc3 to experimental for testing and started to check if the affected packaged build (at least). My plan is the following: 1. Finish testing all the reverse dependencies with rc3 and upcoming 1:27.0+dfsg, file bugreports. 2. Elang 27 build depends on a few packages which aren't in testing or even in Debian yet: * autoconf (>= 2.72), it is in experimetal at the moment, see [1] * node-fontsource-inconsolata, node-fontsource-lato, * node-fontsource-merriweather, they are used to build documentation (currently Erlang in experimental is built without docs) and sit in NEW (see [2], [3], [4]). By the way is this normal that the are in NEW for two months without any resolution? 3. So after these packages clear unstable, and after 1:27.0.1 is out (June or July 2024), I'll upload Erlang to unstable and likely do a bunch of NMUs to fix remaining bugs. There will be necessary to do quite a few bin-NMUs also. Here is the list of affected packages with short comments where I did some testing: # Broken (not in testing) averell ejabberd ejabberd-contrib (builds fine, depends on ejabberd) erlang-cowboy erlang-p1-pgsql (builds fine, depends on erlang-p1-xml) erlang-ranch erlang-p1-xmpp (builds fine, depends on erlang-p1-xml) erlang-p1-xml # Broken (need patching/updating) erlang-bbmustache erlang-jiffy erlang-luerl erlang-p1-pkix erlang-p1-sqlite3 erlang-p1-tls erlang-p1-utils kamailio (uses only C interface to Erlang, FTBFS is unrelated to Erlang) mochiweb (fix of rebar3 dependencis should help) elixir (patch is ready, also upcoming 1.17 will support Erlang 27 explicitly) rebar3 (updating to 3.23.0 works, have to update dependencies, e.g. erlang-inets is missing for 27) wings3d (patch is ready) yaws (patch is ready) # Broken (need elixir and likely patching/updating) erlang-hex rabbitmq-server # Build as is erlang-asciideck erlang-base64urls erlang-bear erlang-bitsack erlang-cf erlang-cl erlang-cowlib erlang-cuttlefish erlang-erlware-commons erlang-folsom erlang-getopt erlang-goldrush erlang-horse erlang-idna erlang-jose erlang-lager erlang-meck erlang-metrics erlang-mimerl erlang-p1-acme erlang-p1-cache-tab erlang-p1-eimp erlang-p1-iconv erlang-p1-mqtree erlang-p1-mysql erlang-p1-oauth2 erlang-p1-pam erlang-p1-sip erlang-p1-stringprep erlang-p1-stun erlang-p1-yaml erlang-p1-yconf erlang-p1-zlib erlang-poolboy erlang-proper erlang-redis-client erlang-unicode-util-compat erlang-uuid manderlbot neotoma rebar sonic-pi tsung [1] https://tracker.debian.org/pkg/autoconf [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065253 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065254 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065256 The Ben file below should correctly determine the affected packages, but definitely does not cover all possible cases of bad and good packages (some of them require elixir instead of erlang-base, for example) Ben file: title = "erlang"; is_affected = .build-depends ~ /dh-rebar|erlang-dev|erlang-base|rebar|rebar3/; is_good = .depends ~ /erlang-base (>= 1:27/; is_bad = .depends ~ /erlang-base (>= 1:(1|2[0-6])/; -- Sergei Golovan
Bug#1069545: [Pkg-erlang-devel] Bug#1069545: erlang: FTBFS on armel: make[4]: *** [/<>/make/arm-unknown-linux-gnueabi/otp.mk:325: ../pdf/wx-2.2.2.1.pdf] Error 1
notfound 1069545 1:25.3.2.11+dfsg-1 thanks Hi Lucas, Java throwing an out-of-memory exception on armel doesn't count as a bug, I reckon. On the other hand, my previous thought about sufficient memory size on builds is irrelevant because builds build only architecture dependent packages, and erlang-doc is architecture independent. On Tue, Apr 23, 2024 at 10:02 AM Sergei Golovan wrote: > > Version: 1:25.3.2.11+dfsg-1 > > Hi Lukas, > > On Sat, Apr 20, 2024 at 4:27 PM Lucas Nussbaum wrote: > > > > Hi, > > > > During a rebuild of all packages in sid, your package failed to build > > on armel. > > > > [INFO] FOUserAgent - Rendered page #871. > > > Exception in thread "main" java.lang.OutOfMemoryError: Java heap space > > It's an intermittent out-of-memory error. It never occurs on buildds > (I guess they just have more memory available then in the setup you're > using for the archive rebuild). Therefore, I'm closing this bugreport. > > Cheers! > -- > Sergei Golovan -- Sergei Golovan
Bug#795495: marked as done (ITP: elixir-ex-doc -- Documentation generator for Elixir projects)
Hi! I totally forgot to add blocking bugs for this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065253 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065254 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065256 Currently, elixir-ex-doc is waiting for these three packages (node-fontsource-inconsolata, node-fontsource-lato, node-fontsource-merriweather) to be able to be built. On Tue, Apr 23, 2024 at 9:03 PM Debian Bug Tracking System wrote: > > Your message dated Tue, 23 Apr 2024 18:00:11 + > with message-id > and subject line Bug#795495: fixed in elixir-ex-doc 0.32.1+dfsg-1 > has caused the Debian Bug report #795495, > regarding ITP: elixir-ex-doc -- Documentation generator for Elixir projects > to be marked as done. > > This means that you claim that the problem has been dealt with. > If this is not the case it is now your responsibility to reopen the > Bug report if necessary, and/or fix the problem forthwith. > > (NB: If you are a system administrator and have no idea what this > message is talking about, this may indicate a serious mail system > misconfiguration somewhere. Please contact ow...@bugs.debian.org > immediately.) > > > -- > 795495: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795495 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > > -- Forwarded message -- > From: Evgeny Golyshev > To: sub...@bugs.debian.org > Cc: > Bcc: > Date: Fri, 14 Aug 2015 20:25:30 +0300 > Subject: ITP: exdoc -- Documentation generator for Elixir projects > Package: wnpp > Severity: wishlist > Owner: Evgeny Golyshev > > * Package name : exdoc > * Version : 0.8.1 > * Upstream Author : Plataformatec > * URL : https://github.com/elixir-lang/ex_doc > * License : Apache-2.0, BSD-3-clause and MIT > * Programming Lang : Elixir > * Description : Documentation generator for Elixir projects > > ExDoc is a tool intended for generating API documentation in HTML > format from Elixir source code. It was inspired by Erlang's EDoc. > > Regards, > Evgeny Golyshev > > > > -- Forwarded message -- > From: Debian FTP Masters > To: 795495-cl...@bugs.debian.org > Cc: > Bcc: > Date: Tue, 23 Apr 2024 18:00:11 + > Subject: Bug#795495: fixed in elixir-ex-doc 0.32.1+dfsg-1 > Source: elixir-ex-doc > Source-Version: 0.32.1+dfsg-1 > Done: Sergei Golovan > > We believe that the bug you reported is fixed in the latest version of > elixir-ex-doc, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 795...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Sergei Golovan (supplier of updated elixir-ex-doc > package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Sat, 20 Apr 2024 17:39:58 +0300 > Source: elixir-ex-doc > Binary: elixir-ex-doc > Architecture: source amd64 > Version: 0.32.1+dfsg-1 > Distribution: unstable > Urgency: low > Maintainer: Debian Erlang Packagers > Changed-By: Sergei Golovan > Description: > elixir-ex-doc - Tool to generate documentation for Erlang and Elixir projects > Closes: 795495 > Changes: > elixir-ex-doc (0.32.1+dfsg-1) unstable; urgency=low > . >* Initial Release (closes: #795495). > Checksums-Sha1: > 7b7d6de73e9d96c8fe87885d61b0ad6943da2125 2330 elixir-ex-doc_0.32.1+dfsg-1.dsc > c487c045396e56f8697bc1347c24804c0c62ff5c 183012 > elixir-ex-doc_0.32.1+dfsg.orig.tar.xz > b50f8a56378961758ee1ec20884e5d3b413180ec 6568 > elixir-ex-doc_0.32.1+dfsg-1.debian.tar.xz > 4bf3e25818ff61944085253599492a5d5ba64f14 21106 > elixir-ex-doc_0.32.1+dfsg-1_amd64.buildinfo > 60cb184fbce02755e6a89a61b6d30c02529212b0 762080 > elixir-ex-doc_0.32.1+dfsg-1_amd64.deb > Checksums-Sha256: > 0e91ae46fef893f045d4e86a26aaa4172a536e316cb062a8bcc4d497661b827a 2330 > elixir-ex-doc_0.32.1+dfsg-1.dsc > 3326de0571871734459490347d7e781eb9586d1f816d4b5da12b5d1b9d8e 183012 > elixir-ex-doc_0.32.1+dfsg.orig.tar.xz > 3be4bfbfb854509f56efce17304d82ecf241bc70c1831441014d873ee3ee6da3 6568 > elixir-ex-doc_0.32.1+dfsg-1.debian.tar.xz > 5a68509b4cc06b019185e42e7cfbfdce57389d9ca9a8611b072f5e1d8fea4cdb 21106 > elixir-ex-doc_0.32.1+dfsg-1_amd64.buildinfo >
Bug#1067701: [Pkg-erlang-devel] Bug#1067701: FTBFS: _TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64
Hi, Lukas! On Tue, Mar 26, 2024 at 2:42 PM Lukas Larsson wrote: > > This bug has been fixed but not released yet for Erlang. This is the github > PR with the fix: https://github.com/erlang/otp/pull/7952 > > The fix will be part of the Erlang 27 release. Thank you for pointing out the PR request! I'm planning to upload Erlang 27 for trixie, but currently it requires some additional tools missing in Debian. So, I'll add this fix in the meantime for Erlang 25. -- Sergei Golovan
Bug#1036908: expect: Broken use of \c in man page
reassign 1036908 whois 5.5.17 retitle 1036908 whois: Broken use of \c in man page thanks Hi Helge, Sorry for the late reply. It seems to me that you've reported this bug to the wrong package. mkpasswd(1) where you've found the bug is from the whois package, and not from the expect one. I'm reassigning it. On Mon, May 29, 2023 at 12:09 PM Helge Kreutzmann wrote: > > Package: expect > Severity: minor > Tags: upstream > > Dear Debian expect maintainer > > Kindly forward this to upstream, I don't know where to report this > (see also #1036463). > > The usage of \c is in mkpasswd(1) is incorrect. It fails when trying > to use po4a to provide translations of the man pages. Im currently > "patching around this" in manpages-l10n. > > For a full explanation of the problem (the man page is different, but > the problem is the same) see Debian #1036826 and the explanations by > Bjarni, especially in message #25. > > It would be great if you could fix this so that manpages-l10n can > remove our workaround, which slows down our build. > > -- System Information: > Debian Release: 12.0 > APT prefers testing-security > APT policy: (500, 'testing-security'), (500, 'testing') > Architecture: amd64 (x86_64) > > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to de_DE.UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages expect depends on: > ii libc6 2.36-9 > ii libtcl8.6 8.6.13+dfsg-2 > pn tcl-expect > ii tcl8.6 8.6.13+dfsg-2 > > expect recommends no packages. > > Versions of packages expect suggests: > ii tk8.6 8.6.13-2 > > -- > Dr. Helge Kreutzmann deb...@helgefjell.de >Dipl.-Phys. http://www.helgefjell.de/debian.php > 64bit GNU powered gpg signed mail preferred >Help keep free software "libre": http://www.ffii.de/ -- Sergei Golovan
Bug#1065607: erlang-hex: Elixir cannot find hex because it is installed into /usr/lib/elixir/hex
Package: erlang-hex Version: 2.0.5-1+b1 Severity: important Tags: patch Dear Maintainer, Currently, erlang-hex installs its library into /usr/lib/elixir/hex, so Elixir cannot fint it (it searches /usr/lib/elixir/lib by default). While it is possible to circumvent this bug by setting the environment variable ERL_LIBS=/usr/lib/elixir/hex, I think it would be better to place hex into /usr/lib/elixir/lib. The attached patch does exactly that. Also, I can do NMU with this patch if you find it appropriate. -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) -- no debconf information diff -Nru erlang-hex-2.0.5/debian/changelog erlang-hex-2.0.5/debian/changelog --- erlang-hex-2.0.5/debian/changelog 2023-09-20 12:02:13.0 +0300 +++ erlang-hex-2.0.5/debian/changelog 2024-03-07 14:19:36.0 +0300 @@ -1,3 +1,11 @@ +erlang-hex (2.0.5-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Install the package into /usr/lib/elixir/lib instead of +/usr/lib/elixir/hex (closes: #-1). + + -- Sergei Golovan Thu, 07 Mar 2024 14:19:36 +0300 + erlang-hex (2.0.5-1) unstable; urgency=medium * New upstream version. diff -Nru erlang-hex-2.0.5/debian/erlang-hex.install erlang-hex-2.0.5/debian/erlang-hex.install --- erlang-hex-2.0.5/debian/erlang-hex.install 2022-11-20 18:09:06.0 +0300 +++ erlang-hex-2.0.5/debian/erlang-hex.install 2024-03-07 14:17:54.0 +0300 @@ -1 +1 @@ -_build/install/hex/ usr/lib/elixir/ +_build/install/hex/hex/ usr/lib/elixir/lib/
Bug#1065256: ITP: node-fontsource-merriweather -- Merriweather font self-hostable for Node.js
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: node-fontsource-merriweather Version : 5.0.11 Upstream Contact: Ayuhito * URL : https://github.com/fontsource/font-files * License : MIT, SIL-OFL-1.1 Programming Lang: CSS Description : Merriweather font self-hostable for Node.js The node-fontsource-merriweather package contains the Merriweather font and CSS files suitable for self-hosting with Node.js. The NPM package with this font is used by the elixir-ex-doc [1] documentation generator. In fact, elixir-ex-doc sources include precompiled assets (set of templates, Javascript libraries and fonts, see [2]), including Merriweather, but I reckon it's better to rebuild the assets from their sources. The Merriweather NPM package is maintained upstream as a part of a huge monorepository (with more than 1600 fonts), so I decided not to package all of them for Debian, but only those which are to be used by elixir-ex-doc. The package will be maintained by me personally. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795495 [2] https://github.com/elixir-lang/ex_doc/tree/main/formatters/html/dist
Bug#1065254: ITP: node-fontsource-lato -- Lato font self-hostable for Node.js
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: node-fontsource-lato Version : 5.0.18 Upstream Contact: Ayuhito * URL : https://github.com/fontsource/font-files * License : MIT, SIL-OFL-1.1 Programming Lang: CSS Description : Lato font self-hostable for Node.js The node-fontsource-lato package contains the Lato font and CSS files suitable for self-hosting with Node.js. The NPM package with this font is used by the elixir-ex-doc [1] documentation generator. In fact, elixir-ex-doc sources include precompiled assets (set of templates, Javascript libraries and fonts, see [2]), including Lato, but I reckon it's better to rebuild the assets from their sources. The Lato NPM package is maintained upstream as a part of a huge monorepository (with more than 1600 fonts), so I decided not to package all of them for Debian, but only those which are to be used by elixir-ex-doc. The package will be maintained by me personally. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795495 [2] https://github.com/elixir-lang/ex_doc/tree/main/formatters/html/dist
Bug#1065253: ITP: node-fontsource-inconsolata -- Inconsolata font self-hostable for Node.js
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: node-fontsource-inconsolata Version : 5.0.16 Upstream Contact: Ayuhito * URL : https://github.com/fontsource/font-files * License : MIT, SIL-OFL-1.1 Programming Lang: CSS Description : Inconsolata font self-hostable for Node.js The node-fontsource-inconsolata package contains the Inconsolata font and CSS files suitable for self-hosting with Node.js. The NPM package with this font is used by the elixir-ex-doc [1] documentation generator. In fact, elixir-ex-doc sources include precompiled assets (set of templates, Javascript libraries and fonts, see [2]), including Inconsolata, but I reckon it's better to rebuild the assets from their sources. The Inconsolata NPM package is maintained upstream as a part of a huge monorepository (with more than 1600 fonts), so I decided not to package all of them for Debian, but only those which are to be used by elixir-ex-doc. The package will be maintained by me personally. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795495 [2] https://github.com/elixir-lang/ex_doc/tree/main/formatters/html/dist
Bug#1064822: ITP: elixir-makeup-erlang -- Makeup lexer for the Erlang language
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: elixir-makeup-erlang Version : 0.1.3 Upstream Contact: Tiago Barroso * URL : https://github.com/elixir-makeup/makeup_erlang * License : BSD-2-clause Programming Lang: Elixir Description : Makeup lexer for the Erlang language A lexer to highlight Erlang code using Makeup, which is a syntax highlighter written in Elixir. This package is a dependency for elixir-ex-doc, which is used by the Erlang upstream developers to generate documentaion from sources (starting from Erlang 27, which is to be released and uploaded to Debian soon). The package will be maintained by the Erlang team.
Bug#1064821: ITP: elixir-makeup-elixir -- Makeup lexer for the Elixir language
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: elixir-makeup-elixir Version : 0.16.1 Upstream Contact: Tiago Barroso * URL : https://github.com/elixir-makeup/makeup_elixir * License : BSD-2-clause Programming Lang: Elixir Description : Makeup lexer for the Elixir language A lexer to highlight Elixir code using Makeup, which is a syntax highlighter written in Elixir. This package is a dependency for elixir-ex-doc, which is used by the Erlang upstream developers to generate documentation from sources (starting from Erlang 27, which is to be released and uploaded to Debian soon). The package will be maintained by the Erlang team.
Bug#1064820: ITP: elixir-makeup -- Generic syntax highlighter written in Elixir
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: elixir-makeup Version : 1.1.1 Upstream Contact: Tiago Barroso * URL : https://github.com/elixir-makeup/makeup * License : BSD-2-clause Programming Lang: Elixir Description : Generic syntax highlighter written in Elixir Makeup is a generic syntax highlighter written in Elixir. It is suitable for use in code hosting, forums, wikis or other applications that need to prettify source code similar to Pygments. This package is a dependency of elixir-ex-doc which is now used by Erlang developers to generate documentaion from sources (starting from Erlang 27, which is to be released and uploaded to Debian soon). It will be maintained by the Erlang team.
Bug#1064819: ITP: elixir-makeup-c -- Makeup lexer for the C language
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: elixir-makeup-c Version : 0.1.1 Upstream Contact: Boyd Multerer * URL : https://github.com/elixir-makeup/makeup_c * License : BSD-2-clause Programming Lang: Elixir Description : Makeup lexer for the C language A lexer to highlight C code using Makeup, which is a syntax highlighter written in Elixir. This package is a dependency for elixir-ex-doc which is now used by Erlang upstream to generate documentation from sources (starting from Erlang 27, which is to be uploaded to Debian soon). The package will be maintained by the Erlang team.
Bug#1064817: ITP: elixir-earmark-parser -- Pure Elixir Markdown Parser
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: elixir-earmark-parser Version : 1.4.39 Upstream Contact: Robert Dober , Dave Thomas * URL : https://github.com/RobertDober/earmark_parser * License : Apache-2.0 Programming Lang: Elixir Description : Pure Elixir Markdown Parser EarmarkParser is a Markdown parser used by Earmark, which is an Elixir library intended for converting Markdown to HTML. It is a dependency for elixir-ex-doc documentation generator, which is used in Erlang to build documetation from sources starting from Erlang 27. The package will be maintained by the Erlang team.
Bug#1062462: [Pkg-tcltk-devel] Bug#1062462: itk3: NMU diff for 64-bit time_t transition
Hi Graham, On Thu, Feb 1, 2024 at 6:57 PM Graham Inggs wrote: > > Source: itk3 > Version: 3.4.2-3.1 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > itk3 as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). Can you elaborate how exactly you determined that itk3 is affected by time_t size change? As far as I can see in the sources, it doesn't use time_t at all. Cheers! -- Sergei Golovan
Bug#1062461: [Pkg-tcltk-devel] Bug#1062461: itcl3: NMU diff for 64-bit time_t transition
Hi Graham, On Thu, Feb 1, 2024 at 6:57 PM Graham Inggs wrote: > > Source: itcl3 > Version: 3.4.4-2 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > itcl3 as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). Can you elaborate how exactly you determined that itcl3 is affected by time_t size change? As far as I can see in the sources, it doesn't use time_t at all. Cheers! -- Sergei Golovan
Bug#1060702: [Pkg-tcltk-devel] Bug#1060702: tcl-itcl4-dev: incr Tcl programs do not compile with tcl8.7-dev
Hi Rafael, On Sat, Jan 13, 2024 at 11:09 AM Rafael Laboissière wrote: > With the versions of tcl-itcl4-dev (4.2.3-1) and tcl8.7-dev > (8.7.0~a5+dfsg-3) currently in experimental, this simple example does > not work: > > $ echo "#include " > test.c > $ gcc -c test.c -I/usr/include/tcl > In file included from test.c:1: > /usr/include/itcl/itcl.h:144:5: error: unknown type name 'Tcl_Size' > 144 | Tcl_Size len; /* number of values on stack */ > | ^~~~ > /usr/include/itcl/itcl.h:145:5: error: unknown type name 'Tcl_Size' > 145 | Tcl_Size max; /* maximum size of stack */ > | ^~~~ > /usr/include/itcl/itcl.h:164:5: error: unknown type name 'Tcl_Size' > 164 | Tcl_Size num; /* number of elements */ > | ^~~~ > > It does work in unstable. Thank you for the report and for the patch! > > Currently, in experimental, tcl-dev depends on tcl8.7-dev. If this > packages migrate into unstable, then tcl-itcl4-dev will be broken in a > serious way. Hence, I am am hereby setting the severity level to > important. Indeed, tcl-dev depends on tcl8.8-dev in experimental in order to spot this type of bugs. Eventually, Tcl/Tk 8.7 will be released, and then we'll do a big transition of all the Tcl/Tk related packages from 8.6 to 8.7. Your patch will definitely help with it. Cheers! -- Sergei Golovan
Bug#1059002: [Pkg-erlang-devel] Bug#1059002: erlang: CVE-2023-48795
Hi Salvatore, On Tue, Dec 19, 2023 at 11:24 AM Salvatore Bonaccorso wrote: > > Source: erlang > Version: 1:25.2.3+dfsg-1 > Severity: important > Tags: security upstream > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > Hi, > > The following vulnerability was published for erlang. > > CVE-2023-48795[0]: Reading the latest announcement on the Erlang mailing list I've found that there is an update of ssh in Erlang 25 which addresses CVE-2023-48795: https://erlang.org/pipermail/erlang-announce/2023-December/000260.html I will try to backport these changes to Erlang currently in stable if it's necessary. As for the unstable, the newest version will fix this as well. Cheers! -- Sergei Golovan
Bug#1058678: blt: disable jpeg support
severity #1058678 serious thanks Hi Helmut, On Thu, Dec 14, 2023 at 3:18 PM Helmut Grohne wrote: > did you know that blt participates in architecture bootstrap? It's > required for building the Python interpreter for instance and thus far, > this has all worked out well, but now you added a build dependency on > libjpeg-dev. libjpeg-turbo in turn Build-Depends on default-jdk and > while it builds its -java package as an Arch:all package, the jdk > actually is being used as it stuffs jni symbols into the main library, > so really the Arch:any package already requires default-jdk. So now we > have a path from Python to Java. We also have a path from Java to Python > already, so your blt upload introduces a bootstrap dependency cycle and > this is bad. I'm sorry, I wasn't aware about these implications. Meanwhile, I'm setting this bug severity to serious and will fix it as soon as possible. > > I suggest that you temporarily revert this change in unstable to restore > the ability to bootstrap Debian from source. I'll do that. > > Then let's figure out the best way to break the cycle before re-enabling > jpeg support. This has mostly worked earlier, because libjpeg-turbo was > not part of the bootstrap set. Even adding libjpeg-turbo seems fine in > principle, but Java less so. As explained earlier, breaking the cycle > between libjpeg-turbo and Java is harder, because there are > Java-specific symbols in the main library. Making jpeg support optional > in blt seems similarly impractical to me. This is definitely more work > than just enabling jpeg support unfortunately. Do you have more ideas? Can someone investigate if blt is really necessary for Python now? It's a very old unmaintained piece of software, and I think that dependence of Python on it should be a bug. Again, I'll revert the change shortly, but is there any way I can help with untangling Python from blt? Cheers! -- Sergei Golovan
Bug#1057700: ITP: tk9.0 -- Tk toolkit for Tcl and X11, v9.0
Package: wnpp Severity: wishlist Owner: Sergei Golovan X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: tk9.0 Version : 9.0b1rc1 Upstream Contact: Tcl Core Team * URL : https://www.tcl-lang.org/ * License : BSD Programming Lang: C, Tcl Description : Tk toolkit for Tcl and X11, v9.0 Tk is a cross-platform graphical toolkit which provides the Motif look-and-feel and is implemented using the Tcl scripting language. This is a new upstream release with some potential incompatibilities with the older ones, so it's as usual packaged separately. The package will be maintained under Debian Tcl/Tk team. Version 9.0 is in pre-beta stage yet, so I'm planning to upload this package to experimental.
Bug#1038071: [Pkg-erlang-devel] Bug#1038071: esdl: Is a language binding for an obsolete version of SDL
Hi Simon, On Thu, Jun 22, 2023 at 2:15 PM Simon McVittie wrote: > > On Thu, 15 Jun 2023 at 13:32:47 +0100, Simon McVittie wrote: > > esdl is a language binding for SDL 1.2, which is unmaintained upstream > > (superseded by SDL 2). > > > > Is esdl still useful, or should it be removed from Debian? It seems there > > is only one package that depends on it: wings3d. > > wings3d just dropped its dependency on esdl (apparently it wasn't actually > needed in that package), so nothing depends on esdl any more. Maybe esdl > could/should be removed from unstable now? As far as I can see, esdl is just a thin wrapper of SDL 1.2 for Erlang. It can't be easily ported to SDL 2, so probably dropping esdl from Debian is the right thing to do. Cheers! -- Sergei Golovan
Bug#1034244: unblock (pre-approval): lua-readline/3.2-2
Control: tags -1 - moreinfo On Wed, Apr 12, 2023 at 12:04 AM Sebastian Ramacher wrote: > On 2023-04-11 12:15:40 +0300, Sergei Golovan wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > X-Debbugs-Cc: lua-readl...@packages.debian.org > > Control: affects -1 + src:lua-readline > > > > I'd like to upload lua-readline with a bugfix for #1034078 (see [1]). > > Please go ahead and remove the moreinfo tag once the new version is > available in unstable. Done! Cheers! -- Sergei Golovan
Bug#1034244: unblock (pre-approval): lua-readline/3.2-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: lua-readl...@packages.debian.org
Control: affects -1 + src:lua-readline
I'd like to upload lua-readline with a bugfix for #1034078 (see [1]).
[ Reason ]
This upload fixes #1034078. The patch is made upstream and taken
from newly released version 3.3.
[ Impact ]
This bug is a regression in version 3.2 which significantly
worsens user experience (standard Ctrl+D isn't interpreted as EOF).
[ Tests ]
There aren't automated tests, but manual testing using upstream test
code doesn't reveal any other regressions/bugs.
[ Risks ]
The code change is trivial, the bug currently affects the prosody
packhage in a way that its admin cannot simply exit from the
prosody server management console.
[ Checklist ]
[+] all changes are documented in the d/changelog
[+] I reviewed all changes and I approve them
[+] attach debdiff against the package in testing
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034078
unblock lua-readline/3.2-2
diff --git a/debian/changelog b/debian/changelog
index 4456e53..7450934 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+lua-readline (3.2-2) unstable; urgency=medium
+
+ * Fix regression which does not allow to use Ctrl-D (EOF) to close
+readline session (closes: #1034078).
+
+ -- Sergei Golovan Sun, 09 Apr 2023 12:28:12 +0300
+
lua-readline (3.2-1) unstable; urgency=medium
* New upstream release.
diff --git a/debian/patches/eof.patch b/debian/patches/eof.patch
new file mode 100644
index 000..2ac8eeb
--- /dev/null
+++ b/debian/patches/eof.patch
@@ -0,0 +1,39 @@
+Author: Upstream
+Description: Patch restores processing EOF (Ctrl+D), when readline()
+ returns NULL, distinguishable from an empty string.
+Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034078
+
+--- a/C-readline.c
b/C-readline.c
+@@ -65,7 +65,13 @@
+ /* rl_cleanup_after_signal(); rl_clear_signals(); no effect :-( 1.3 */
+ /* lua_pushstring(L, line); */
+ /* 3.2 did lua_pushstring create a copy of the string ? */
+- lua_pushfstring(L, "%s", line); /* 3.2 */
++ /* lua_pushfstring(L, "%s", line); 3.2 */
++ if (line == NULL) { /* 3.3 fix by zash.se, Prosody developer */
++ lua_pushnil(L);
++ } else {
++ lua_pushfstring(L, "%s", line);
++ // lua_pushstring(L, line); should be fine as well
++ }
+ if (tty_stream != NULL) { fclose(tty_stream); }
+ free(line); /* 3.2 fixes memory leak */
+ return 1;
+@@ -135,13 +141,15 @@
+ return 0;
+ }
+
+-static int c_write_history(lua_State *L) { /* filename in, returncode out */
++/* unused ...
++static int c_write_history(lua_State *L) { // filename in, returncode out
+ size_t len;
+ const char *filename = lua_tolstring(L, 1, );
+ lua_Integer rc = write_history(filename);
+ lua_pushinteger(L, rc);
+ return 1;
+ }
++*/
+
+ static int c_history_truncate_file(lua_State *L) { /* filename,num in rc out
*/
+ size_t len;
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..84626e5
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+eof.patch
Bug#1034078: [pkg-lua-devel] Bug#1034078: lua-readline: regression in how EOF is reported
tags 1034078 + pending thanks Hi Kim, On Sat, Apr 8, 2023 at 10:15 AM Kim Alvefur wrote: > > Dear Maintainer, > > The lua-readline package changed how end-of-file is reported back, > which may cause Ctrl-D to no longer behave as expected in programs that > use lua-readline. I confirm the regression. > > I have reported this to the upstream author via email as I did not find > any public bug tracker. I see that upstream has already released version 3.3 with the fix. I cannot bump the Debian package to 3.3 because of the freeze, but I'll try to persuade release team to allow the backported fix to enter testing. Thank you for the bugreport! -- Sergei Golovan
Bug#1032850: blt: Please build with JPEG support
Hi Thomas, On Sun, Mar 12, 2023 at 10:57 PM Thomas Uhle wrote: > > could you please build BLT with JPEG support. For your convenience, > I have prepared a patch in two versions, the first for the packages in > bookworm/sid and the second for the packages in experimental. Thank you for the patch, but I'm afraid it's too late to include this patch to Debian 12 (bookworm) because of the freeze (currently only bugfixes are acceptable and not new features). I'll gladly enable JPEG support in blt for the next testing after releasing bookworm as stable, and then I'll backport it to bookworm. Cheers! -- Sergei Golovan
Bug#1029034: snack: includes non-free source
Hi Thomas, Thank you very much for the patch! It makes the snack package build just fine. I'll do some testing and upload the fixed package shortly! As far as I can tell, there's still time for it to make bookworm (Debian 12). On Sun, Feb 19, 2023 at 12:12 AM Thomas Uhle wrote: > > Dear maintainers, > > I would very much appreciate if this package would be kept in Debian. > That is why I've had a look into the source code and have seen that there > is yet another implementation for a downsampler in jkGetF0.c that is not > proprietary code. And so I was thinking what is good enough to be used > for the estimation of the first formant F0, cannot be bad for doing the > computation to estimate all the others. However, in contrast to the code > from downsample.c, this other downsampler is not using 16-bit integer > values but it is a floating-point implementation. So it is not a drop-in > replacement and I had to rewrite large portions of the two functions > Fdownsample() and highpass(). I also had to make the function do_ffir() > public to be used by the highpass filter implementation and to uncomment > and fix some code in it that was headlined by /* never used */ but is > needed to make the highpass filter implementation working again. > > Long story short, there is a patch attached to this e-mail that I grant > under the license of either GPL2+ (like it is used for the whole project > snack) or BSD (like it is said to be in the headers of jkFormant.c and > jkGetF0.c), whatever suits you, in the hope to save this package from > being dropped. > I have attached two versions of it because I don't know whether the 170 > lines of conflicting proprietary code have to be removed before or can be > replaced by the patch. So applying remove_downsample.c.diff removes the > conflicting lines from jkFormant.c, formant.patch is the actual fix to > make the implementation work again, and formant2.patch is a combination > of both. > > I hope it is not too late. > > Best regards, > > Thomas Uhle -- Sergei Golovan
Bug#1026464: Logos suggestion
Hi! I would like to suggest the attached logos to the desktop-base package. I've just extracted them from the Juliette artwork, so they match the current Emerald theme better. On the other hand, they are white with some degree of transparency. So maybe it'd be better to add some green to them. Cheers! -- Sergei Golovan
Bug#1030329: Proposing NMU
Hi Ralf,
If you don't mind, I'd suggest doing NMU for this bug. I've tested
myself, simply adding pipewire-pulse to the dependencies list allows
osspd to work with pipewire (in the modern Gnome desktop pipewire is
installed by default and cannot be easily replaced with pulseaudio).
The diff for the proposed NMU is attached.
Cheers!
--
Sergei Golovan
diff --git a/debian/changelog b/debian/changelog
index 7ee6387..c13dee7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+osspd (1.3.2-13.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add an alternative dependency of osspd-pulseaudio on pipewire-pulse
+(closes: #1030329).
+
+ -- Sergei Golovan Sat, 04 Feb 2023 15:32:47 +0300
+
osspd (1.3.2-13) unstable; urgency=medium
[Debian Janitor]
diff --git a/debian/control b/debian/control
index fb2112c..3c61196 100644
--- a/debian/control
+++ b/debian/control
@@ -35,7 +35,7 @@ Description: OSS Proxy Daemon: Userland OSS emulation
Package: osspd-pulseaudio
Architecture: linux-any
Provides: osspd-backend
-Depends: pulseaudio, ${misc:Depends}, ${shlibs:Depends}
+Depends: pulseaudio | pipewire-pulse, ${misc:Depends}, ${shlibs:Depends}
Recommends: osspd
Description: OSS Proxy Daemon: PulseAudio backend
OSS Proxy Daemon is a Linux userland OSS sound device (/dev/[a]dsp and
Bug#1030148: [Pkg-tcltk-devel] Bug#1030148: tk8.6: Please switch the order of Recommends, making xterm the fallback for x-terminal-emulator
Hi Lucas, On Tue, Jan 31, 2023 at 7:27 PM Lukas Märdian wrote: > > Dear Sergei, > > please switch the order of tk8.6's Recommends so that xterm is only the > fallback option if nothing else provides x-terminal-emulator. I won't switch the dependencies, but I'll drop the dependency on x-terminal-emulator altogether. It's used only for a menu item, and I think that having raw Tk shell in the user menu is not necessary. In extremely rare cases when a user wants to start the shell manually, they can just execute `wish' in a terminal window. Cheers! -- Sergei Golovan
Bug#1025770: [pkg-lua-devel] Bug#1025770: lua5.4: Provide compiled version of srlua and glue?
done 1025770 5.4.4-3 thanks Hi Jean-Philippe, On Thu, Dec 8, 2022 at 11:30 PM Jean-Philippe Georget wrote: > > Dear Maintainer, > It would be nice to have compiled versions of srlua and glue. > The sources are on https://github.com/LuaDist/srlua As far as I can see, both srlua and glue are not parts of the Lua interpreter, and are some external pieces of software. So they aren't supposed to be included into the lua5.4 package. If one wishes to ship them with Debian, they should do that separately, using the usual procedure (file an ITP or RTP bug to wnpp [1], find a maintainer/uploader, create and upload the packages). So I'm closing this bug report as irrelevant for lua5.4. [1] https://www.debian.org/devel/wnpp/ Cheers! -- Sergei Golovan
Bug#1029034: snack: includes non-free source
Hi Bastian, Thank you for the report! On Mon, Jan 16, 2023 at 9:33 PM Bastian Germann wrote: > > While the file part that is copied from formant.c is okay to be included in > Debian, the part from downsample.c is not. > Please repack the source package getting rid of the file. I don't think that I can remove this code without reimplementing its functionality somehow. So maybe it'd be better to drop the package from Debian. There are two packages that depend on tcl-snack: transcriber and wavesurfer. I guess they'd have to be removed from Debian as well. Cheers! -- Sergei Golovan
Bug#1024721: [pkg-lua-devel] Bug#1024721: dh-lua: stop using libtool-bin
Hi Helmut, Sorry for a delay. On Wed, Nov 23, 2022 at 11:09 PM Helmut Grohne wrote: > > I would like to delete the libtool-bin package. The next paragraph > explains why. You may skip it if you don't care. I support the idea of dropping the libtool-bin dependency for dh-lua. > > I've come up with a patch that creates a libtool when needed in > debian/.dh_lua-libtool. With this patch applied, I can drop the > libtool-bin dependency. I've done a test build of lua-geoip using this > the patched dh-lua and see that it builds successfully without pulling > the libtool-bin package. > > So I went ahead and used ratt to check for possible failures in those > 103 reverse dependencies and found the following failures: > - axtls is broken by my patch, because it injects -laxtls into compiler >flags picked up by configure. > - elektra #956949 > - hamlib is broken by my patch, because it injects a non-existent >object file into compiler flags picked up by configure. > - libguestfs FTBFS on buildds > - lua-apr #935271 > - lua-cyrussasl is broken by my patch, because it injects shell code >into compiler flags picked up by configure and configure passes that >code to the compiler verbatim. > - lua-zip is broken by my patch, because it injects shell code >into compiler flags picked up by configure and configure passes that >code to the compiler verbatim. > - luasocket is broken by my patch, because of a quoting issue in the >generated configure arising from LTCFGFLAGS containing quotes. > - neomutt #1023767 > - rrdtool is broken by my patch, because it injects -lrrd into compiler >flags picked up by configure. As far as I can see, the common problem with the patch is that it picks the CFLAGS and LDFLAGS environment variables (created by the make tool from CLIB_CFLAGS and CLIB_LDFLAGS, which are set in the dh-lib.conf). These variables are used in an additional call of dh_auto_configure which is necessary to generate the libtool binary. But are these variables necessary in this dh_auto_configure call? Maybe we can just clear them before the call? I've tried to use $(H)dh_auto_configure --buildsystem=autoconf --sourcedirectory=$(LBTL_DIR) -- "CFLAGS='' LDFLAGS='' LDFLAGS_STATIC='' and got almost all the broken builds succeed (the nested dh_auto_configure sees the cleared variables, after that the newly created libtool builds the library just fine). One exception is hamlib. It remains broken, I can't figure out what's wrong. > > So applying this patch would make six additional packages FTBFS. Of > those, axtls and rrdtool try adding their library via CLIB_LDFLAGS. Both > of them use a relative path with -L, which becomes invalid in configure. > Adding $(CURDIR) may be a way to go here. hamlib could likewise prefix Unfortunately, hamlib can't be fixed so easily. Something remains wrong. > its object file with $(CURDIR). cyrus-sasl should use $(shell ...) > instead of $$(...) to perform the shell evaluation. Likewise, lua-zip > should use $(shell ...) in place of `...`. Finally, luasocket is > difficult. Getting the quoting through the flags seems next to > impossible, so I'd suggest moving the affected macros to a file and pass > an -include flag via CFLAGS. > > Does this sound like we can move forward with this patch? I know it is > not of the "it just works" kind. After adding the clearing of CFLAGS and LDFLAGS the patch "almost doesn't break anything". If we figure out how to fix the hamlib build, I'll gladly apply the changes in the next upload. Cheers! -- Sergei Golovan
Bug#1024632: [Pkg-erlang-devel] Bug#1024632: Bug#1024632: Bug#1024632: erlang: CVE-2022-37026 Client Authentication Bypass
Hi! On Mon, Dec 12, 2022 at 5:27 PM Sergei Golovan wrote: > > Hi Salvatore, > > On Fri, Dec 9, 2022 at 12:15 AM Salvatore Bonaccorso > wrote: > > > > The upcoming point release for 11.6 is scheduled for 17th with > > uploading window closing the upcoming weekend. If we are confident > > enough about potential regressions, can you make sure the fix land in > > the next bullseye point release? > > Unfortunately, I've found a few regressions in the Erlang test suite, > and I couldn't fix them myself yet. I'll try my best to do that > tonight and tomorrow, but I'm afraid I'd suggest postponing uploading > patched Erlang to stable. I couldn't fix these regressions in the test suite, but it appears that they are present in the latest released Erlang 23 version (23.3.4.18) as well. Therefore, I'm uploading the fix to stable. Cheers! -- Sergei Golovan
Bug#1024632: [Pkg-erlang-devel] Bug#1024632: Bug#1024632: erlang: CVE-2022-37026 Client Authentication Bypass
Hi Salvatore, On Fri, Dec 9, 2022 at 12:15 AM Salvatore Bonaccorso wrote: > > The upcoming point release for 11.6 is scheduled for 17th with > uploading window closing the upcoming weekend. If we are confident > enough about potential regressions, can you make sure the fix land in > the next bullseye point release? Unfortunately, I've found a few regressions in the Erlang test suite, and I couldn't fix them myself yet. I'll try my best to do that tonight and tomorrow, but I'm afraid I'd suggest postponing uploading patched Erlang to stable. Cheers! -- Sergei Golovan
Bug#1024632: [Pkg-erlang-devel] Bug#1024632: erlang: CVE-2022-37026 Client Authentication Bypass
Hi Markus, On Wed, Nov 30, 2022 at 4:15 PM Markus Koschany wrote: > > Hello, > > I have prepared a security update for Bullseye which fixes CVE-2022-37026. > Sergei could you review the update please? I am attaching the debdiff. I'm also preparing a fix for CVE-2022-37026, but I'll gladly consider your patch first. Thank you for the work! -- Sergei Golovan
Bug#1020841: rabbitmq-server: FTBFS with Erlang 25
Source: rabbitmq-server Version: 3.9.13-1 Severity: important Dear Maintainer, I'm about to upload Erlang 25 into unstable. The problem is that rabbitmq-server 3.9.13-1 fails to build from the source. This can be partially explained by the fact that elixir 1.12 does not work with Erlang 25 (elixir requires upgrade to 1.14), but I'd suggest to upgrade rabbitmq-server as well since upstream has released 3.10.7 which officially supports Erlang 25. Cheers! -- Sergei Golovan
Bug#1020839: elixir-lang: FTBFS with Erlang 25
Source: elixir-lang Version: 1.12.2.dfsg-2.2 Severity: important Dear Maintainer, I'm about to upload new Erlang 25 into unstable, and it appears to break the current elixir-lang 1.12.2.dfsg-2.2. It simply fails to build from the source. I don't know if it's possible to quickly fix the current version, but upstream already released 1.14.0 which appears to build fine after minor changes in debian/ directory. I'm attaching a diff with a minimal set of changes necessary to build 1.14.0. So please, upgrade elixir-lang after Erlang 25 is uploaded. Cheers! -- Sergei Golovan diff -Nru elixir-lang-1.12.2.dfsg/debian/changelog elixir-lang-1.14.0.dfsg/debian/changelog --- elixir-lang-1.12.2.dfsg/debian/changelog2022-02-24 14:47:39.0 +0300 +++ elixir-lang-1.14.0.dfsg/debian/changelog2022-09-16 17:28:12.0 +0300 @@ -1,3 +1,10 @@ +elixir-lang (1.14.0.dfsg-1) unstable; urgency=medium + + * New upstream release. + * Switch to rebar3. + + -- Sergei Golovan Fri, 16 Sep 2022 17:28:12 +0300 + elixir-lang (1.12.2.dfsg-2.2) unstable; urgency=medium * Non-maintainer upload. diff -Nru elixir-lang-1.12.2.dfsg/debian/control elixir-lang-1.14.0.dfsg/debian/control --- elixir-lang-1.12.2.dfsg/debian/control 2021-10-12 14:43:19.0 +0300 +++ elixir-lang-1.14.0.dfsg/debian/control 2022-09-16 17:28:12.0 +0300 @@ -10,7 +10,7 @@ erlang-parsetools (>= 1:24.1), erlang-src (>= 1:24.1), git, - rebar + rebar3 Standards-Version: 4.6.0 Vcs-Git: https://salsa.debian.org/eugulixes-guest/elixir-lang.git Vcs-Browser: https://salsa.debian.org/eugulixes-guest/elixir-lang diff -Nru elixir-lang-1.12.2.dfsg/debian/patches/erlang-24.1.patch elixir-lang-1.14.0.dfsg/debian/patches/erlang-24.1.patch --- elixir-lang-1.12.2.dfsg/debian/patches/erlang-24.1.patch2021-10-12 14:48:58.0 +0300 +++ elixir-lang-1.14.0.dfsg/debian/patches/erlang-24.1.patch2022-09-16 17:28:12.0 +0300 @@ -4,12 +4,12 @@ --- a/lib/elixir/test/elixir/exception_test.exs +++ b/lib/elixir/test/elixir/exception_test.exs -@@ -474,6 +474,8 @@ - function :erlang.gt_cookie/0 is undefined or private. Did you mean one of: - -* get_cookie/0 -+ * get_cookie/1 -+ * set_cookie/1 -* set_cookie/2 - """ +@@ -539,6 +539,8 @@ + message = blame_message(:erlang, & &1.gt_cookie()) + assert message =~ "function :erlang.gt_cookie/0 is undefined or private. Did you mean:" + assert message =~ "* get_cookie/0" ++ assert message =~ "* get_cookie/1" ++ assert message =~ "* set_cookie/1" + assert message =~ "* set_cookie/2" end + diff -Nru elixir-lang-1.12.2.dfsg/debian/patches/remove-utf8-warning.patch elixir-lang-1.14.0.dfsg/debian/patches/remove-utf8-warning.patch --- elixir-lang-1.12.2.dfsg/debian/patches/remove-utf8-warning.patch 2021-08-24 16:41:05.0 +0300 +++ elixir-lang-1.14.0.dfsg/debian/patches/remove-utf8-warning.patch 2022-09-16 17:28:12.0 +0300 @@ -6,11 +6,9 @@ Forwarded: no Last-Update: 2018-10-30 -Index: elixir-lang/lib/elixir/src/elixir.erl -=== elixir-lang.orig/lib/elixir/src/elixir.erl -+++ elixir-lang/lib/elixir/src/elixir.erl -@@ -137,11 +137,6 @@ check_endianness() -> +--- a/lib/elixir/src/elixir.erl b/lib/elixir/src/elixir.erl +@@ -137,11 +137,6 @@ check_file_encoding(Encoding) -> case Encoding of diff -Nru elixir-lang-1.12.2.dfsg/debian/patches/series elixir-lang-1.14.0.dfsg/debian/patches/series --- elixir-lang-1.12.2.dfsg/debian/patches/series 2021-10-12 14:47:11.0 +0300 +++ elixir-lang-1.14.0.dfsg/debian/patches/series 2022-09-16 17:28:12.0 +0300 @@ -1,3 +1,3 @@ remove-utf8-warning.patch -remove_rebar3_related_tests.patch +#remove_rebar3_related_tests.patch erlang-24.1.patch diff -Nru elixir-lang-1.12.2.dfsg/debian/rules elixir-lang-1.14.0.dfsg/debian/rules --- elixir-lang-1.12.2.dfsg/debian/rules2021-08-24 16:41:05.0 +0300 +++ elixir-lang-1.14.0.dfsg/debian/rules2022-09-16 17:28:12.0 +0300 @@ -3,6 +3,7 @@ export LANG=C.UTF-8 export LC_ALL=C.UTF-8 export REBAR=/usr/bin/rebar +export REBAR3=/usr/bin/rebar3 export PREFIX=/usr %:
Bug#1014935: [pkg-lua-devel] Bug#1014935: lua5.4: CVE-2022-33099
Hi Salvatore, On Thu, Jul 14, 2022 at 11:06 PM Salvatore Bonaccorso wrote: > > The following vulnerability was published for lua5.4. > > CVE-2022-33099[0]: > | An issue in the component luaG_runerror of Lua v5.4.4 and below leads > | to a heap-buffer overflow when a recursive error occurs. > > Btw, I'm right now not sure about older lua versions. While the patch > im principle I think apply I'm unsure if the issue has introduced in > 5.4 only. Can you double check so we can update the tracker > accordingly? I confirm that the bug is present only in lua5.4, both in stable (5.4.2) and unstable/testing (5.4.4). lua5.3, lua5.2, lua5.1 are not vulnerable. I'll apply the upstream patch to unstable shortly. If you think it's worth a patch in stable, I could prepare it as well. Cheers! -- Sergei Golovan
Bug#1010265: [pkg-lua-devel] Bug#1010265: CVE-2022-28805
found 1010265 5.4.2-1 thanks Hi Moritz, On Wed, Apr 27, 2022 at 2:57 PM Moritz Muehlenhoff wrote: > > This was assigned CVE-2022-28805: > https://github.com/lua/lua/commit/1f3c6f4534c6411313361697d98d1145a1f030fa > http://lua-users.org/lists/lua-l/2022-02/msg1.html > http://lua-users.org/lists/lua-l/2022-02/msg00070.html > > Can you please check whether this also affects the older Lua versions > in the archive? This bug is related to the variables which have been introduced in Lua 5.4, so it doesn't affect the earlier versions. It does affect Lua 5.4.2 in stable though. I'll fix it in unstable shortly. Do I need to prepare a fix for stable? Cheers! -- Sergei Golovan
Bug#999682: [Pkg-erlang-devel] Bug#999682: erlang-mode: Broken symlinks in man/man3
Hi Sebastian. On Mon, Nov 15, 2021 at 12:57 AM Sebastian Olsson wrote: > > Package: erlang-mode > Version: 1:23.2.6+dfsg-1 > Severity: normal > X-Debbugs-Cc: vis...@gmail.com > > Dear Maintainer, > > I installed the erlang package on an Debian bullseye docker container to > perform the following escript: Erlang packages do not come with these manpages. In fact, erlang-mode just contains a link /usr/lib/erlang/man -> /usr/share/man, so I guess your script just tries to copy all manpages to the container. And it breaks if it can't dereference a link. I'm not sure I can do anything about it. But you're welcome to submit bugs to the packages with these symlinks (/usr/share/man/man3/LIST_EMPTY.3 is in manpages-dev for example). Cheers! -- Sergei Golovan
Bug#996437: elixir-lang: FTBFS with Erlang 24.1 (one test fails)
Hi Evgeny. I've missed your first reply somehow, sorry. I'll happily do NMU on the weekend. On Thu, Oct 21, 2021, 16:44 Evgeny Golyshev wrote: > Hi Sergei > > If you don't have time to do the NMU, tell me and I will upload the > package applying your patch. > > -- > Evgeny > > On Mon, 18 Oct 2021 at 14:25, Evgeny Golyshev wrote: > >> Hello Sergei >> >> Thank you for the patch you prepared. It's well done. Feel free to do a >> NMU. >> >> -- >> Evgeny >> >
Bug#996437: elixir-lang: FTBFS with Erlang 24.1 (one test fails)
Source: elixir-lang Version: 1.12.2.dfsg-2 Severity: important Tags: ftbfs patch upstream Dear Maintainer, Currently, elixir-lang fails to build from the source in unstable, because one of its tests fails. See the result [1] from the autopkgtest for details. The problem is not in Elixir itself, but in the test which relies on a specific error message from calling a non-existing function. When building with Erlang 24.1, the error message has changed, so test fails. The attached patch adapts this test to the current error message. Also, I've bumped the build dependencies to Erlang 24.1 (with the new test elixir-land will FTBFS with the older Erlang). If you think it's appropriate, I could do NMU with the proposed changes. Cheers! [1] https://ci.debian.net/data/autopkgtest/testing/amd64/e/elixir-lang/15916413/log.gz -- System Information: Debian Release: 11.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru elixir-lang-1.12.2.dfsg/debian/changelog elixir-lang-1.12.2.dfsg/debian/changelog --- elixir-lang-1.12.2.dfsg/debian/changelog2021-08-24 16:41:05.0 +0300 +++ elixir-lang-1.12.2.dfsg/debian/changelog2021-10-12 14:42:36.0 +0300 @@ -1,3 +1,9 @@ +elixir-lang (1.12.2.dfsg-2.1) unstable; urgency=medium + + * Fix a test to build with erlang 24.1. + + -- Sergei Golovan Tue, 12 Oct 2021 14:42:36 +0300 + elixir-lang (1.12.2.dfsg-2) unstable; urgency=medium * Fix debian/watch diff -Nru elixir-lang-1.12.2.dfsg/debian/control elixir-lang-1.12.2.dfsg/debian/control --- elixir-lang-1.12.2.dfsg/debian/control 2021-08-24 16:41:05.0 +0300 +++ elixir-lang-1.12.2.dfsg/debian/control 2021-10-12 14:42:36.0 +0300 @@ -3,12 +3,12 @@ Priority: optional Maintainer: Evgeny Golyshev Build-Depends: debhelper-compat (= 13), - erlang-crypto (>= 1:22), - erlang-dev (>= 1:22), - erlang-dialyzer (>= 1:22), - erlang-eunit (>= 1:22), - erlang-parsetools (>= 1:22), - erlang-src (>= 1:22), + erlang-crypto (>= 1:24.1), + erlang-dev (>= 1:24.1), + erlang-dialyzer (>= 1:24.1), + erlang-eunit (>= 1:24.1), + erlang-parsetools (>= 1:24.1), + erlang-src (>= 1:24.1), git, rebar Standards-Version: 4.6.0 diff -Nru elixir-lang-1.12.2.dfsg/debian/patches/erlang-24.1.patch elixir-lang-1.12.2.dfsg/debian/patches/erlang-24.1.patch --- elixir-lang-1.12.2.dfsg/debian/patches/erlang-24.1.patch1970-01-01 03:00:00.0 +0300 +++ elixir-lang-1.12.2.dfsg/debian/patches/erlang-24.1.patch2021-10-12 14:42:36.00000 +0300 @@ -0,0 +1,15 @@ +Author: Sergei Golovan +Description: Patch adapts the asserted error message to Erlang 24.1 +Last-Modified: Tue, 12 Oct 2021 14:48:53 +0300 + +--- a/lib/elixir/test/elixir/exception_test.exs b/lib/elixir/test/elixir/exception_test.exs +@@ -474,6 +474,8 @@ + function :erlang.gt_cookie/0 is undefined or private. Did you mean one of: + +* get_cookie/0 ++ * get_cookie/1 ++ * set_cookie/1 +* set_cookie/2 + """ + end diff -Nru elixir-lang-1.12.2.dfsg/debian/patches/series elixir-lang-1.12.2.dfsg/debian/patches/series --- elixir-lang-1.12.2.dfsg/debian/patches/series 2021-08-24 16:41:05.0 +0300 +++ elixir-lang-1.12.2.dfsg/debian/patches/series 2021-10-12 14:42:36.0 +0300 @@ -1,2 +1,3 @@ remove-utf8-warning.patch remove_rebar3_related_tests.patch +erlang-24.1.patch
Bug#996275: [Pkg-erlang-devel] Bug#996275: coturn: FTBFS with OpenSSL 3.0
Hi Kurt, On Wed, Oct 13, 2021 at 9:51 AM Kurt Roeckx wrote: > > On Wed, Oct 13, 2021 at 07:43:26AM +0300, Sergei Golovan wrote: > > > > This is a known issue, see https://github.com/erlang/otp/issues/4577 > > and I'm afraid the fix will come only with the new major Erlang 25. > > It's expected to be released in May 2022. > > As far as I know, there are 2 issues: > - The call to FIPS_mode no longer exists. This has probably never > worked in Debian in the first place, so a possible solution for > that would be just to remove the call. > - Warnings about deprecated functions. Those are just warnings, > the functions aren't going to go away soon, but will at some > point in the future. So this is something we should be able > to ignore until upstream fixes it. > > I currently don't know when the transition will start. Thank you for the info. Then I'll try to make a patch when the transition starts. And drop it, obviously, in favor of the port upstream developers will come up with. Cheers! -- Sergei Golovan
Bug#996275: [Pkg-erlang-devel] Bug#996275: coturn: FTBFS with OpenSSL 3.0
retitle 996275 erlang: FTBFS with OpenSSL 3.0 tags 996275 + upstream forwarded 996275 https://github.com/erlang/otp/issues/4577 thanks Hi Kurt, On Tue, Oct 12, 2021 at 10:39 PM Kurt Roeckx wrote: > > Hi, > > Your package is failing to build using OpenSSL 3.0 with the > following error: > pkey.c:76:14: error: implicit declaration of function FIPS_mode > [-Werror=implicit-function-declaration] >76 | if (!FIPS_mode()) return PKEY_OK; > | ^ This is a known issue, see https://github.com/erlang/otp/issues/4577 and I'm afraid the fix will come only with the new major Erlang 25. It's expected to be released in May 2022. Cheers! -- Sergei Golovan
Bug#994596: [Pkg-tcltk-devel] Bug#994596: tcllib: no calendar module available
Hi Greg. On Sat, Sep 18, 2021 at 1:21 PM greg wrote: > > Package: tcllib > Version: 1.20+dfsg-1 > Severity: normal > X-Debbugs-Cc: gre...@gmx.de As far as I can see in the changelog, the calendar module was explicitly excluded from the installable modules list in 2004 because it was not ready yet. There have been no changes in the module since then, so I don't think it makes sense to install it in Debian. Or, can you confirm its usefulness in spite of what the Tcllib developers say? Cheers! -- Sergei Golovan
Bug#993388: [Pkg-tcltk-devel] Bug#993388: tcl8.6: nested dicts: with lappend you can duplicate and than remove intermediate values
Hi Davide,
As far as I can see, there's nothing wrong with Tcl here. You just
treat a list as a dict, hence the confusion. See this simpler example:
% set M {A B C D C {1 2}}
A B C D C {1 2}
Here, $M contains a list (actually, a string which can be interpreted
as a list). But we can try to interpret it as a dict:
% dict lappend M C 3
A B C {1 2 3}
Here, $M is reinterpreted as a dict, with odd items A, C, C as its
keys, and even items B, D, {1 2} as values. The problem is that there
is the duplicate key C, so Tcl had to drop one of its values (the last
one overwritten the first one upon creation of the dict). After that,
3 was appended to the list {1 2}.
Cheers!
--
Sergei Golovan
Bug#992609: careless upload of Erlang v24 without a transition tracking with the release team (was: rabbitmq-server fails to start after erlang v24 update)
Hi Thomas, On Sun, Aug 22, 2021 at 6:55 PM Thomas Goirand wrote: > > Hi Damir, Sergei, the release team, > > First of all, thanks for your bug report, Damir. > > Debian Bullseye was released on the 14th of Aug. Then Erlang v24 was > uploaded on the 17th. Looking at: > > https://release.debian.org/transitions/ > > I cannot see any transition thingy opened for Erlang. This means that > Erlang was carelessly uploaded to Unstable: Uploading new major version of Erlang does not require a transition. No application needs to be rebuilt against it, and only a minority breaks (those which use removed deprecated features, and they have to be updated or patched anyway). I'm sorry that elixir and rabbit-mq break. > > 1/ Without informing the release team, and defining a schedule for the > Erlang transition I insist that a transition is not necessary. > > 2/ Without rebuilding any reverse dependency, and more specifically, > without caring about RabbitMQ which is kind of a high profile server > application. > > Now, we have Erlang v24 in Unstable which looks like a good target for > RabbitMQ 3.9.4, however, this new version needs a new Elixir release, as > it has a bound of ">= 1.10.4 and < 1.13.0". Elixir as in unstable (ie: > 1.10.3) doesn't work, even when trying to convince RabbitMQ it's ok. Well, I would say that Elixir in Debian is not in a good shape. It lags way behind upstream (which is already 1.12.2, quite a few releases ahead). > > There isn't much I can do now. I'm opening a bug against Elixir, and > I'll have to wait for it to be solved... > > This isn't the first time something like this happen. Could we please > bring some sanity in the way we do things? Sergei, could you please > revert your upload of Erlang v24 in Unstable, and open a release team > bug to get a transition tracker thingy, which is the only sane way to do > things in Debian? > > Not amused... I've uploaded Erlang 24 to experimental months ago. If you know that your software breaks on Erlang upgrade, you could do something already. Cheers! -- Sergei Golovan
Bug#987874: [pre-approval] unblock: osspd/1.3.2-12
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi release team!
I'm writing on behalf of the maintainer of the osspd package (I intend
to sponsor the potential upload).
We'd like to upload the osspd package to fix #986662 (see [1] for
details). The bug is serious as the currently osspd doesn't work at all.
The diff is attached. It includes two other fixes, which are much less
serious, so if you decide that changes are too big for the freeze
time then we'll drop them.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986662
unblock osspd/1.3.2-12
-- System Information:
Debian Release: 10.9
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500,
'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-16-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index c412732..9481d07 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+osspd (1.3.2-12) unstable; urgency=low
+
+ [ Sébastien Noel ]
+ * cherrypick 2 commits from upstream GIT:
++ d/p/GIT-fix-adsp_se.patch
++ d/p/GIT-fix-compiler-warnings.patch
+ * Add workaround for pulseaudio >= 13
+d/p/Hack-to-work-with-modern-PulseAudio.patch (Closes: #986662)
+
+ [ Ralf Jung ]
+ * Switch to debhelper compat level 13.
+
+ -- Ralf Jung Sat, 17 Apr 2021 14:28:09 +0200
+
osspd (1.3.2-11) unstable; urgency=medium
* Update Standards-Version to 4.3.0. No changes needed.
diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index ec63514..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-9
diff --git a/debian/control b/debian/control
index c3cd2da..ee044ca 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,8 @@ Source: osspd
Section: sound
Priority: optional
Maintainer: Ralf Jung
-Build-Depends: debhelper (>= 9.20160709),
+Uploaders: Sébastien Noel
+Build-Depends: debhelper-compat (= 13),
libasound2-dev,
libfuse-dev,
libpulse-dev
@@ -14,6 +15,7 @@ Vcs-Git: git://ralfj.de/osspd.git
Package: osspd
Architecture: linux-any
Multi-Arch: foreign
+Pre-Depends: ${misc:Pre-Depends}
Depends: lsb-base (>= 3.2-14),
osspd-pulseaudio | osspd-backend,
${misc:Depends},
diff --git a/debian/patches/GIT-fix-adsp_se.patch
b/debian/patches/GIT-fix-adsp_se.patch
new file mode 100644
index 000..7316f9c
--- /dev/null
+++ b/debian/patches/GIT-fix-adsp_se.patch
@@ -0,0 +1,24 @@
+From 4c6161d951daa98f6463904f76b3fa2ce7216194 Mon Sep 17 00:00:00 2001
+From: Tejun Heo
+Date: Mon, 21 Feb 2011 11:54:06 +0100
+Subject: [PATCH] adsp_se was incorrectly created with dsp_ops. Create it with
+ adsp_ops.
+
+Reported-by: Aaron
+---
+ osspd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/osspd.c b/osspd.c
+index 37c9b35..df1cfc4 100644
+--- a/osspd.c
b/osspd.c
+@@ -2253,7 +2253,7 @@ int main(int argc, char **argv)
+ param.mixer_major, param.mixer_minor,
+ args.argc, args.argv);
+ if (strlen(param.adsp_name))
+- adsp_se = setup_ossp_cuse(_ops, param.adsp_name,
++ adsp_se = setup_ossp_cuse(_ops, param.adsp_name,
+ param.adsp_major, param.adsp_minor,
+ args.argc, args.argv);
+
diff --git a/debian/patches/GIT-fix-compiler-warnings.patch
b/debian/patches/GIT-fix-compiler-warnings.patch
new file mode 100644
index 000..1424b2b
--- /dev/null
+++ b/debian/patches/GIT-fix-compiler-warnings.patch
@@ -0,0 +1,251 @@
+From 37eb730a452f0ded2ed1c174feb438e3df041581 Mon Sep 17 00:00:00 2001
+From: Miklos Szeredi
+Date: Fri, 11 Nov 2011 14:19:32 +0100
+Subject: [PATCH] fix compiler warnings
+
+---
+ ossp-padsp.c | 3 ---
+ osspd.c | 75 ++--
+ 2 files changed, 44 insertions(+), 34 deletions(-)
+
+diff --git a/ossp-padsp.c b/ossp-padsp.c
+index 1871f5b..3143960 100644
+--- a/ossp-padsp.c
b/ossp-padsp.c
+@@ -972,16 +972,13 @@ static void do_mmap_read(size_t bytes)
+
+ static void stream_rw_callback(pa_stream *s, size_t length, void *userdata)
+ {
+- int dir;
+ size_t size;
+
+ if (s == stream[PLAY]) {
+- dir = PLAY;
+ size = pa_stream_writable_size(s);
+ if (mmap_map[PLAY])
+ do_mmap_write(size);
+ } else if (s == stream[REC]) {
+- dir = REC;
+ size = pa_stream_readable_size(s);
+ if (mmap_map[REC])
+ do_mmap_read(size);
+diff --git a/osspd.c
Bug#986662: ossp-padsp not working with recent Pulseaudio
Hi Ralf, On Fri, Apr 30, 2021 at 2:07 PM Ralf Jung wrote: > > Hi Sergei, > > Our current problem is that we cannot even upload the package to unstable > since > my key in the debian keyring expired (and the updated key missed the April > keyring update), and Sebastien is not yet allowed to upload osspd. > I've done the upload before figuring this out, so now revision 12 is sitting > on > the ftp server and waiting for my key to become valid... > > If you are a DD, maybe you can help by uploading the package for us? I guess > we'd have to prepare a revision 13, but that should be easy. Yes, I'm a DD, sorry if I wasn't clear about this. > > When we prepared the fix, we were not aware that this would become an RC bug, > so > we didn't strive for a minimal fix. Okay. Then I'll open a bugreport with release.debian.org and ask if this not so minimal update can propagate to testing. If yes, I'll reupload it. Cheers! -- Sergei Golovan
Bug#986662: ossp-padsp not working with recent Pulseaudio
Hi Ralf, Sebastien, If you need any help with uploading the osspd package, please let me know. I've looked at the current 1.3.2-12 in Git, and it looks fine with the exception that it adds more changes than the fix of this bug (which is not advisable during freeze periods). So, I'd start to ask the release team if they are willing to grant a freeze exception for the new version prior to upload. Cheers! -- Sergei Golovan
Bug#987400: [Pkg-tcltk-devel] Bug#987397: tcltls: build conflict with openssl requires removal of too many packages
Control: tags -1 - moreinfo The package is uploaded. On Sat, Apr 24, 2021 at 1:43 PM Andrej Shadura wrote: > > Hi, > > On Sat, 24 Apr 2021, at 12:38, Graham Inggs wrote: > > On Fri, 23 Apr 2021 at 13:12, Andrej Shadura wrote: > > > I finally came back from lunch, the latest debdiff and the diffoscope > > > output are attached. > > > > The diffoscope output of a no-change rebuild of 1.7.22-1 and 1.7.22-2 > > should show fewer differences. > > > > I don't see the upload of 1.7.22-2 yet, so in case you were wanting > > pre-approval, please go ahead and upload, and remove the moreinfo tag > > once the new version is available in unstable. > > Right, I should have clarified — I didn't rebuild -1. > > Sergei, will you upload this? I'll only be back at the keyboard in the > evening. > > -- > Cheers, > Andrej -- Sergei Golovan
Bug#987397: [Pkg-tcltk-devel] Bug#987397: tcltls: build conflict with openssl requires removal of too many packages
Hi Andrej, On Fri, Apr 23, 2021 at 1:20 PM Andrej Shadura wrote: > > Hi again, > > On Fri, 23 Apr 2021, at 12:16, Andrej Shadura wrote: > > On Fri, 23 Apr 2021, at 12:13, Sergei Golovan wrote: > > > No, it wouldn't. The point is that there's no need of any patch. An > > > extra option in debian/rules should be sufficient. I'll try it today > > > and commit the fix to salsa if it'll work. Or if it won't then I'll > > > accept your patch. > > I’ve just checked the code and you’re right, it skips directly to the > fallback. I’ll revise the merge request. It's not necessary. I've just pushed the fix to Salsa. Can you ask the release team for the freeze exception? -- Sergei Golovan
Bug#987397: [Pkg-tcltk-devel] Bug#987397: tcltls: build conflict with openssl requires removal of too many packages
Hi Andrej, On Fri, Apr 23, 2021 at 1:07 PM Andrej Shadura wrote: > > Hi, > > On Fri, 23 Apr 2021, at 11:21, Sergei Golovan wrote: > > On Fri, Apr 23, 2021 at 11:27 AM Andrej Shadura wrote: > > > While trying to build your package from the source in quite a minimal > > > container, the Build-Conflicts requirement forced the following packages > > > out: > > > > > > > ca-certificates devscripts git-buildpackage libconfig-model-dpkg-perl > > > > liblwp-protocol-https-perl libsoap-lite-perl libwww-perl > > > > libxml-parser-perl > > > > libxml-sax-expat-perl libxmlrpc-lite-perl openssl osc osc-plugin-dput > > > > osc-plugins-dput python3-certifi python3-requests > > > > > > On my normal system, it forces the removal of 358 packages including a > > > huge number of my development tools, the editor and parts of the desktop > > > environment. > > > > > > Please implement what this requirement was supposed to accomplish in a > > > different way not requiring removing openssl. > > > > Currently, tcltls conflicts with openssl because it tries to generate > > DH pair on the fly, > > which sometimes fails due to lack of entropy on buildds. Though it > > looks like the > > newest tcltls allows one to supply option --enable-deterministic and > > get the same result. > > > > I'll fix this bug after the bullseye's release. Thank you for pointing it > > out. > > Thanks. Would you be okay if I went ahead with a team upload with the patch I > attached if the release team grant me an unblock? No, it wouldn't. The point is that there's no need of any patch. An extra option in debian/rules should be sufficient. I'll try it today and commit the fix to salsa if it'll work. Or if it won't then I'll accept your patch. -- Sergei Golovan
Bug#987397: [Pkg-tcltk-devel] Bug#987397: tcltls: build conflict with openssl requires removal of too many packages
Hi Andrej, On Fri, Apr 23, 2021 at 11:27 AM Andrej Shadura wrote: > > Dear Maintainer, > > While trying to build your package from the source in quite a minimal > container, the Build-Conflicts requirement forced the following packages > out: > > > ca-certificates devscripts git-buildpackage libconfig-model-dpkg-perl > > liblwp-protocol-https-perl libsoap-lite-perl libwww-perl libxml-parser-perl > > libxml-sax-expat-perl libxmlrpc-lite-perl openssl osc osc-plugin-dput > > osc-plugins-dput python3-certifi python3-requests > > On my normal system, it forces the removal of 358 packages including a > huge number of my development tools, the editor and parts of the desktop > environment. > > Please implement what this requirement was supposed to accomplish in a > different way not requiring removing openssl. Currently, tcltls conflicts with openssl because it tries to generate DH pair on the fly, which sometimes fails due to lack of entropy on buildds. Though it looks like the newest tcltls allows one to supply option --enable-deterministic and get the same result. I'll fix this bug after the bullseye's release. Thank you for pointing it out. Cheers! -- Sergei Golovan
Bug#985389: yaws: debug is enabled, which makes the package unusable for production
Package: yaws Version: 2.0.8+dfsg-2 Severity: grave Justification: renders package unusable Dear Maintainer, Currently, yaws is built with debug enabled, which slows it down and clutters its log files. The debug sould be disabled before the bullseye release.
Bug#985124: Acknowledgement (fossil: fails to update schema for older repositories)
Hi Barak,
I did some testing, the patch from
https://www2.fossil-scm.org/fossil/info/d4041437b6f40d0cc62f22d2973498d596af325b1d18fed2dd7584aef733df7a
indeed fixes the bug. I'm attaching the patch, and if you want, I can
do NMU.
--
Sergei Golovan
diff -Nru fossil-2.14/debian/changelog fossil-2.14/debian/changelog
--- fossil-2.14/debian/changelog 2021-01-24 19:12:40.0 +0300
+++ fossil-2.14/debian/changelog 2021-03-13 12:59:32.0 +0300
@@ -1,3 +1,11 @@
+fossil (1:2.14-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * Apply an upstream patch which fixes updating schema for repositories
+created by fossil 1.x (closes: #985124)
+
+ -- Sergei Golovan Sat, 13 Mar 2021 12:59:32 +0300
+
fossil (1:2.14-1) unstable; urgency=medium
* New upstream version
diff -Nru fossil-2.14/debian/patches/series fossil-2.14/debian/patches/series
--- fossil-2.14/debian/patches/series 2021-01-24 19:12:40.0 +0300
+++ fossil-2.14/debian/patches/series 2021-03-13 12:57:08.0 +0300
@@ -1 +1,2 @@
debian-changes
+update-schema.patch
diff -Nru fossil-2.14/debian/patches/update-schema.patch fossil-2.14/debian/patches/update-schema.patch
--- fossil-2.14/debian/patches/update-schema.patch 1970-01-01 03:00:00.0 +0300
+++ fossil-2.14/debian/patches/update-schema.patch 2021-03-13 12:59:32.0 +0300
@@ -0,0 +1,27 @@
+Author: Upstream
+Description: Disable devencive mode when updating schema for repositories created by fossil 1.x.
+
+--- a/src/rebuild.c
b/src/rebuild.c
+@@ -156,17 +156,20 @@
+ /* Search for: length(uuid)==40
+ ** 0123456789 12345 */
+ int i;
+ for(i=10; z[i]; i++){
+ if( z[i]=='=' && strncmp([i-6],"(uuid)==40",10)==0 ){
++int rc = 0;
+ z[i] = '>';
++sqlite3_db_config(g.db, SQLITE_DBCONFIG_DEFENSIVE, 0, );
+ db_multi_exec(
+"PRAGMA writable_schema=ON;"
+"UPDATE repository.sqlite_schema SET sql=%Q WHERE name LIKE 'blob';"
+"PRAGMA writable_schema=OFF;",
+z
+ );
++sqlite3_db_config(g.db, SQLITE_DBCONFIG_DEFENSIVE, 1, );
+ break;
+ }
+ }
+ fossil_free(z);
+ }
+
Bug#985124: fossil: fails to update schema for older repositories
Package: fossil
Version: 1:2.14-1
Severity: grave
Tags: upstream fixed-upstream
Dear Maintainer,
After updating the fossil package to 1:2.14-1, I've found that it fails
to open repositories created a while ago. It emits the following error
message:
SQLITE_ERROR(1): table sqlite_master may not be modified in "UPDATE
repository.sqlite_schema SET sql='CREATE TABLE blob(
rid INTEGER PRIMARY KEY,
rcvid INTEGER,
size INTEGER,
uuid TEXT UNIQUE NOT NULL,
content BLOB,
Database error: table sqlite_master may not be modified: {UPDATE
repository.sqlite_schema SET sql='CREATE TABLE blob(
rid INTEGER PRIMARY KEY,
rcvid INTEGER,
size INTEGER,
uuid TEXT UNIQUE NOT NULL,
content BLOB,
CHECK( length(uuid)>=40 AND rid>0 )
)' WHERE name LIKE 'blob';PRAGMA writable_schema=OFF;}
The message indicates that the repository Sqlite DB is in defencive
mode, and its schema can't be modified using UPDATE.
As far as I can see, this bug is fixed upstream in the following commit:
https://www2.fossil-scm.org/fossil/info/d4041437b6f40d0cc62f22d2973498d596af325b1d18fed2dd7584aef733df7a
which is a part of the 2.15 release.
Please, apply the fix to the fossil package in Debian, as it is now,
fossil is not very usable. I'm sure, the bug is serious enough to grant
a freeze exception.
To reproduce the bug, just create an empty repository using fossil
binary from stretch (1:1.37-1), and try to connect to it using fossil
1:2.14-1:
fossil-1.37 new test.fossil
fossil-2.14 info -R test.fossil
Cheers!
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages fossil depends on:
ii libc6 2.31-9
ii libfuse22.9.9-5
ii libsqlite3-03.34.1-3
ii libssl1.1 1.1.1j-1
ii libtcl8.6 [libtcl] 8.6.11+dfsg-1
ii zlib1g 1:1.2.11.dfsg-2
fossil recommends no packages.
Versions of packages fossil suggests:
ii gnupg 2.2.27-1
-- no debconf information
--
Sergei Golovan
Bug#983829: [Pkg-tcltk-devel] Bug#983829: tk-doc: copyright file missing (policy 12.5)
Hi Andreas, On Tue, Mar 2, 2021 at 4:54 AM Andreas Beckmann wrote: > > Hi, > > a test with piuparts revealed that your package misses the copyright > file, which is a violation of Policy 12.5: > https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information > > From the attached log (scroll to the bottom...): > > 0m15.7s ERROR: WARN: Inadequate results from running adequate! > tk-doc: missing-copyright-file /usr/share/doc/tk-doc/copyright > > MISSING COPYRIGHT FILE: /usr/share/doc/tk-doc/copyright > # ls -lad /usr/share/doc/tk-doc > ls: cannot access '/usr/share/doc/tk-doc': No such file or directory > # ls -la /usr/share/doc/tk-doc/ > ls: cannot access '/usr/share/doc/tk-doc/': No such file or directory Hm. /usr/share/doc/tk-doc should be a symlink to /usr/share/doc/tcl-doc. Looks like it went missing when it was built by a buildd daemon. Thank you for reporting this! -- Sergei Golovan
Bug#947272: blt builds fine with gcc-10
severity 947272 important thanks Hi Holger, On Wed, Dec 30, 2020 at 9:27 PM Holger Levsen wrote: > > On Wed, Dec 30, 2020 at 06:36:23PM +0300, Sergei Golovan wrote: > > There isn't Tcl/Tk 8.7 in unstable yet, only an alpha in experimantal. > > After the Tcl/Tk 8.7 will be released, I'll deal with this bug in > > unstable. > > ah, ok, makes sense. > > probably it would still be nicer to downgrade this bug to severity important > until that tcl/tk version has reached unstable. You're right. Currently this bug does not have any impact on the bullseye release. I'm downgrading its severity. -- Sergei Golovan
Bug#947272: blt builds fine with gcc-10
Hi Holger, On Wed, Dec 30, 2020 at 6:26 PM Holger Levsen wrote: > > Hi Sergei, > > On Wed, Dec 30, 2020 at 05:26:53PM +0300, Sergei Golovan wrote: > > This bug is actually about blt 2.5.3+dfsg-5 and failure to build with > > Tcl/Tk 8.7. So the serious severity is justified. The bug title is > > misleading though, so I'm changing it. Sorry for not doing it sooner. > > ah, cool! > > now I just wonder why it still builds in unstable? There isn't Tcl/Tk 8.7 in unstable yet, only an alpha in experimantal. After the Tcl/Tk 8.7 will be released, I'll deal with this bug in unstable. -- Sergei Golovan
Bug#947272: blt builds fine with gcc-10
retitle 947272 blt: FTBFS with Tcl/Tk 8.7 (>= 8.7.0~a3): error: argument 'argv' doesn't match prototype severity 947272 serious thanks Hi Holger! This bug is actually about blt 2.5.3+dfsg-5 and failure to build with Tcl/Tk 8.7. So the serious severity is justified. The bug title is misleading though, so I'm changing it. Sorry for not doing it sooner. On Wed, Dec 30, 2020 at 5:06 PM Holger Levsen wrote: > > control: severity -1 important > thanks > > Hi Andreas, > > it seems blt builds fine with gcc-10 as can be seen from the recent upload, > so I'm downgrading the severity and am wondering if we should actually close > this bug (=ftbfs with gcc-9). What do you think? > > > -- > cheers, > Holger > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org > ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C > ⠈⠳⣄ > > Dance like no one's watching. Encrypt like everyone is. -- Sergei Golovan
Bug#964073: lintian: Possible false positives for breakout-link for Lua modules
Hi Felix, On Thu, Jul 2, 2020 at 2:22 AM Felix Lechner wrote: > > Hi Sergei, > > On Wed, Jul 1, 2020 at 1:33 AM Sergei Golovan wrote: > > > > Though, the link never goes outside /usr/lib/x86_64-linux-gnu, > > so I would say that this warning is spurious. > > I am not sure who is right, but the warning is not spurious from the > perspective of the original requestor. Bug#243158 cited a scenario > very much like yours as the reason for why the dynamic linker was > confused. As far as I can see, it's a link like /usr/lib/foo.so.1.0.0 -> /usr/lib/somewhere/foo.so.1.0.0 was the concern for bug #243158. Here, Lintian emits a warning for the link which points backward (/usr/lib/ have the real file, /usr/lib//lua have the link). > > Those links also never left /usr/lib. The explanation for breakout-link says that there might be an issue with multi-arch (link may point to another architecture), so I'd just check and wouldn'd show the warning if both the link and the target are located inside one /usr/lib/. > > Like so many bugs in Debian, however, the feature was requested 17 > years ago. At that point, Lua had already been around for ten years > (having arrived in 1993). Do you know when Lua adopted the current > shared object hierarchy and resolution method? I don't know when this layout was introduced in individual packages, I can see that it was implemented in dh-lua in 2012. Cheers! -- Sergei Golovan
Bug#964073: lintian: Possible false positives for breakout-link for Lua modules
Package: lintian Version: 2.82.0 Severity: normal Dear Maintainer, Recently, lintian started to emit the breakout-link warning for a bunch of Lua related packages. A typical structure of a Lua package with a C library is the following: The C library with a symlink (to allow someone to link a program in C to it): /usr/lib/x86_64-linux-gnu/liblua5.1-sec.so.1.0.0 /usr/lib/x86_64-linux-gnu/liblua5.1-sec.so.1 -> liblua5.1-sec.so.1.0.0 The symlink which lets Lua find the library (by require "ssl") /usr/lib/x86_64-linux-gnu/lua/5.1/ssl.so -> ../../liblua5.1-sec.so.1.0.0 Since it points to a higher location in the file system, lintian shows a warning. Though, the link never goes outside /usr/lib/x86_64-linux-gnu, so I would say that this warning is spurious. Can it be fixed in Lintian? I can think of another way of fixing it by reverting the linkage (make /usr/lib/x86_64-linux-gnu/lua/5.3/ssl.so a real file and point the symlink /usr/lib/x86_64-linux-gnu/liblua5.1-sec.so.1.0.0 to it), but I'm not sure it's worth the effort. Cheers! -- Sergei Golovan
Bug#963700: ITP: lua-readline -- GNU readline bindings for the Lua language
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: lua-readline Version : 2.7 Upstream Author : Peter Billam * URL : https://pjb.com.au/comp/lua/readline.html * License : Expat (the same as for Lua itself) Programming Lang: C, Lua Description : GNU readline bindings for the Lua language This Lua module offers a simple calling interface to the GNU Readline/History Library. This package will become a dependency for the Prosody XMPP server strting from the next 0.12 release. It will be maintained under the Debian Lua Team umbrella.
Bug#963192: critcl can't find the critcl_md5 package
Package: critcl
Version: 3.1.17+dfsg-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
Currently, critcl cannot create any C proc because it can't find the
critcl_md5c package:
tclsh8.6 [~] package require critcl
3.1.17
tclsh8.6 [~] critcl::cproc A {} int {return 1;}
can't find package critcl_md5c
while evaluating critcl::cproc A {} int {return 1;}
tclsh8.6 [~]
-- System Information:
Debian Release: 10.4
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500,
'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1,
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-9-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages critcl depends on:
ii build-essential 12.6
ii gcc 4:8.3.0-1
ii tcl 8.6.9+1
ii tcl-dev 8.6.9+1
ii tcl8.6-dev 8.6.9+dfsg-2
ii tcllib 1.19-dfsg-2
Versions of packages critcl recommends:
ii tcl-trf 2.1.4-dfsg3-2+b1
critcl suggests no packages.
-- no debconf information
Bug#963043: elixir: Please, remove the dependency on ${erlang-pcre:Depends}
Package: elixir
Version: 1.10.3.dfsg-1
Severity: normal
Tags: patch
Dear Maintainer,
After you've updated the package to 1.10.3, the dependency on erlang-pcre is
not necessary anymore. I've checked that erlixir built with earlier version
of Erlang (specifically, 21.1.5, the same as the problematic 1.9.1 was built)
passes all the tests when run using Erlang 22.3.3 currently in unstable.
So I suggest to remove the dependency on erlang-pcre- to avoid
rebuilding (either by a source upload or a binNMU) elixir-lang any time the
PCRE library version in Erlang changes.
I've prepared a simple NMU, so if you don't mind, I can do the upload myself.
Cheers!
-- System Information:
Debian Release: 10.4
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500,
'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1,
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-9-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages elixir depends on:
ii erlang-base 1:21.2.6+dfsg-1
elixir recommends no packages.
elixir suggests no packages.
-- no debconf information
diff -Nru elixir-lang-1.10.3.dfsg/debian/changelog
elixir-lang-1.10.3.dfsg/debian/changelog
--- elixir-lang-1.10.3.dfsg/debian/changelog2020-05-06 20:33:40.0
+0300
+++ elixir-lang-1.10.3.dfsg/debian/changelog2020-06-18 12:10:44.0
+0300
@@ -1,3 +1,11 @@
+elixir-lang (1.10.3.dfsg-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Remove the dependency of the elixir binary package on
+erlang-pcre-, because it isn't necessary anymore.
+
+ -- Sergei Golovan Thu, 18 Jun 2020 09:10:44 +
+
elixir-lang (1.10.3.dfsg-1) unstable; urgency=medium
* New upstream release (closes: #959701, #959160, #959988).
diff -Nru elixir-lang-1.10.3.dfsg/debian/control
elixir-lang-1.10.3.dfsg/debian/control
--- elixir-lang-1.10.3.dfsg/debian/control 2020-05-06 20:33:40.0
+0300
+++ elixir-lang-1.10.3.dfsg/debian/control 2020-06-18 12:09:45.0
+0300
@@ -18,7 +18,7 @@
Package: elixir
Architecture: any
-Depends: ${erlang:Depends}, ${erlang-pcre:Depends}, ${misc:Depends}
+Depends: ${erlang:Depends}, ${misc:Depends}
Description: functional meta-programming aware language
Elixir is a functional meta-programming aware language intended primarily for
developing distributed, fault-tolerant and scalable systems. Elixir source
Bug#961653: libguestfs: FTBFS with Erlang 23
Hi Hilko, On Wed, May 27, 2020 at 10:55 PM Hilko Bengen wrote: > > * Sergei Golovan: > > > I'd like to upload Erlang 23 for the bullseye release, but it makes > > libguestfs fail to build from source, because it uses liberl_interface > > which has been removed from the Erlang distribution. > > After briefly chatting with Richard, I have decided to disable building > the Erlang binding, as it has been done for Fedora. I've helped a little bit in porting erlang-guestfs to Erlang 23 (see [1]), so hopefully, you'll be able to restore the functionality in the future, after it'll make into a release. [1] https://github.com/libguestfs/libguestfs/commit/987734fcca101cf782264756f7883cf48430a91b Cheers! -- Sergei Golovan
Bug#961596: Acknowledgement (rebar: Remove -lerl_interface from ERL_LDFLAGS for Erlang 23)
Hi Nobuhiro, I've prepared an updated rebar package at https://salsa.debian.org/erlang-team/packages/rebar/-/tree/master It includes a patch which makes generating ERL_LDFLAGS dynamically: it includes -lerl_interface if it's available. Also, I've updated the formal packagig stuff (VCS headers, debhelper compatibility level, standards version). So, If the changes are good enough for you, I could upload the package. Cheers! -- Sergei Golovan
Bug#961579: stretch-pu: package erlang/1:19.2.1+dfsg-2+deb9u3
On Thu, May 28, 2020 at 12:14 AM Adam D. Barratt wrote: > > Please go ahead. Done, thank you! -- Sergei Golovan
Bug#961652: Acknowledgement (erlang-p1-pam: FTBFS with Erlang 23)
tags 961652 + patch
thanks
Hi Philipp!
I'd like to offer a patch (a rewrite of epam.c) which switches to
libei and seems to work for Erlang 21, 22, 23. It'd be better to check
it upstream though.
Cheers!
--
Sergei Golovan
diff --git a/c_src/epam.c b/c_src/epam.c
index 95e97fb..b7ad488 100644
--- a/c_src/epam.c
+++ b/c_src/epam.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
#include
@@ -99,11 +98,11 @@ static int acct_mgmt(char *service, char *user)
return retval;
}
-static int read_buf(int fd, byte *buf, int len)
+static int read_buf(int fd, const char *buf, int len)
{
int i, got = 0;
do {
-if ((i = read(fd, buf+got, len-got)) <= 0) {
+if ((i = read(fd, (char *)buf+got, len-got)) <= 0) {
if (i == 0) return got;
if (errno != EINTR)
return got;
@@ -114,7 +113,7 @@ static int read_buf(int fd, byte *buf, int len)
return (len);
}
-static int read_cmd(byte *buf)
+static int read_cmd(const char *buf)
{
int len;
if (read_buf(0, buf, 2) != 2)
@@ -150,113 +149,128 @@ static int write_cmd(char *buf, int len)
return 1;
}
-static int process_reply(ETERM *pid, int cmd, int res)
+static int process_reply(erlang_pid pid, erlang_ref ref, int cmd, int res)
{
- ETERM *result;
- ETERM *errbin;
- int len, retval;
+ ei_x_buff result;
+ int retval = 0;
const char *errtxt;
- byte *buf;
- if (res == PAM_SUCCESS)
-result = erl_format("{~i, ~w, true}", cmd, pid);
- else
-{
- errtxt = pam_strerror(NULL, res);
- errbin = erl_mk_binary(errtxt, strlen(errtxt));
- result = erl_format("{~i, ~w, {false, ~w}}", cmd, pid, errbin);
- erl_free_term(errbin);
-}
- len = erl_term_len(result);
- buf = erl_malloc(len);
- erl_encode(result, buf);
- retval = write_cmd((char *)buf, len);
- erl_free_term(result);
- erl_free(buf);
+
+ if (ei_x_new_with_version() != 0) return 0;
+ if (ei_x_encode_tuple_header(, 3) != 0) goto cleanup;
+ if (ei_x_encode_char(, cmd) != 0) goto cleanup;
+ if (ei_x_encode_tuple_header(, 2) != 0) goto cleanup;
+ if (ei_x_encode_pid(, ) != 0) goto cleanup;
+ if (ei_x_encode_ref(, ) != 0) goto cleanup;
+
+ if (res == PAM_SUCCESS) {
+if (ei_x_encode_atom(, "true") != 0) goto cleanup;
+ } else {
+errtxt = pam_strerror(NULL, res);
+if (ei_x_encode_tuple_header(, 2) != 0) goto cleanup;
+if (ei_x_encode_atom(, "false") != 0) goto cleanup;
+if (ei_x_encode_binary(, errtxt, strlen(errtxt)) != 0) goto cleanup;
+ }
+ retval = write_cmd(result.buff, result.index);
+ cleanup:
+ ei_x_free();
return retval;
}
-static int process_acct(ETERM *pid, ETERM *data)
+static int decode_binary(const char *buf, int *index, char **output)
+{
+int type, size;
+long len;
+
+if (ei_get_type(buf, index, , ) != 0) return -1;
+if (type != ERL_BINARY_EXT) return -1;
+
+*output = malloc(size+1);
+if (*output == NULL) return -1;
+if (ei_decode_binary(buf, index, *output, ) != 0) {
+free(*output);
+return -1;
+}
+*(*output+len) = 0;
+return 0;
+}
+
+static int process_acct(erlang_pid pid, erlang_ref ref, const char *buf, int index)
{
int retval = 0;
- ETERM *pattern, *srv, *user;
+ int arity;
char *service, *username;
- pattern = erl_format("{Srv, User}");
- if (erl_match(pattern, data))
-{
- srv = erl_var_content(pattern, "Srv");
- service = erl_iolist_to_string(srv);
- user = erl_var_content(pattern, "User");
- username = erl_iolist_to_string(user);
- retval = process_reply(pid, CMD_ACCT, acct_mgmt(service, username));
- erl_free_term(srv);
- erl_free_term(user);
- erl_free(service);
- erl_free(username);
-}
- erl_free_term(pattern);
+
+ if (ei_decode_tuple_header(buf, , ) != 0) return 0;
+ if (arity != 2) return 0;
+ if (decode_binary(buf, , ) != 0) return 0;
+ if (decode_binary(buf, , ) != 0) return 0;
+
+ retval = process_reply(pid, ref, CMD_ACCT, acct_mgmt(service, username));
+
+ free(service);
+ free(username);
+
return retval;
}
-static int process_auth(ETERM *pid, ETERM *data)
+static int process_auth(erlang_pid pid, erlang_ref ref, const char *buf, int index)
{
int retval = 0;
- ETERM *pattern, *srv, *user, *pass, *rhost;
+ int arity;
char *service, *username, *password, *remote_host;
- pattern = erl_format("{Srv, User, Pass, Rhost}");
- if (erl_match(pattern, data))
-{
- srv = erl_var_content(pattern, "Srv");
- service = erl_iolist_to_string(srv);
- user = erl_var_content(pattern, "User");
- username = erl_iolist_to_string(user);
- pass = erl_var_content(pattern, "Pass");
- password = erl_iolist_to_string(pass);
- rhost = erl_var_content(pattern, "Rhost");
- remote_host = erl_iolist_to_string(rhost);
- retval = process_reply(pid, CMD_AUTH, aut
Bug#961653: libguestfs: FTBFS with Erlang 23
Source: libguestfs Version: 1:1.42.0-1 Severity: normal Dear Maintainer, I'd like to upload Erlang 23 for the bullseye release, but it makes libguestfs fail to build from source, because it uses liberl_interface which has been removed from the Erlang distribution. Unfortunately, I can't suggest any patch to port erl-guestfs to libei, it's not a drop-in replacement, porting would neet substantial work. So, in the meantime, I'd suggest to report this incompatibility upstream, and stop shipping the erlang-guestfs binary package. It can be restored later, when all the porting will be done. Cheers! -- System Information: Debian Release: 10.4 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#961652: erlang-p1-pam: FTBFS with Erlang 23
Package: erlang-p1-pam Version: 1.0.7-1 Severity: normal Dear Maintainer, I'd like to upload Erlang 23 for the bullseye release, but this makes erlang-p1-pam fali to build from source. The problem is that erlang-p1-pam uses liberl_interface which now is obsoleted and removed from the Erlang distribution. Unfortunately, I don't know about any ready-to-use patch which would port epam.c to libei, so this'll require some work. In the meantime, erlang-p1-pam will FTBFS, but the already built one will be usable, because it's linked with liberl_interface statically. -- System Information: Debian Release: 10.4 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages erlang-p1-pam depends on: ii erlang-base [erlang-abi-17.0] 1:21.2.6+dfsg-1 ii libc6 2.28-10 ii libpam0g 1.3.1-5 erlang-p1-pam recommends no packages. erlang-p1-pam suggests no packages.
Bug#961651: erlang-p1-sqlite3: FTBFS with Erlang 23
Package: erlang-p1-sqlite3 Version: 1.1.6-5 Severity: normal Dear Maintainer, I'd like to upload Erlang 23 for the bullseye release, but this makes erlang-p1-sqlite3 fail to build from source because of the usage of the obsolete liberl_interface recently removed from Erlang. Upstream already did some changes (see [1]), so you can take and apply them. [1] https://github.com/processone/erlang-sqlite3/commit/c31585341e9e4667bb54b2cbe1db6a449a2baace -- System Information: Debian Release: 10.4 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages erlang-p1-sqlite3 depends on: ii erlang-base [erlang-abi-17.0] 1:21.2.6+dfsg-1 ii libc6 2.28-10 ii libsqlite3-0 3.27.2-3 erlang-p1-sqlite3 recommends no packages. erlang-p1-sqlite3 suggests no packages.
Bug#961650: erlang-p1-eimp: FTBFS with Erlang 23
Package: erlang-p1-eimp Version: 1.0.14-1 Severity: normal Dear Maintainer, I'd like to upload Erlang 23 for bullseye release, but unfortunately, this makes the erlang-p1-eimp fail to build from source. The problem is that erlang-p1-eimp uses liberl_interface, which has been removed in Erlang 23. Upstream already made the necessary changes (see [1]). I'd suggest to apply them. [1] https://github.com/processone/eimp/commit/7fe680d25426b1808f3c49e77240f3cfd5ef712b -- System Information: Debian Release: 10.4 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages erlang-p1-eimp depends on: ii erlang-base [erlang-abi-17.0] 1:21.2.6+dfsg-1 pn erlang-p1-utils ii libc6 2.28-10 ii libgd3 2.2.5-5.2 ii libjpeg62-turbo1:1.5.2-2+b1 ii libpng16-161.6.36-6 ii libwebp6 0.6.1-2 erlang-p1-eimp recommends no packages. erlang-p1-eimp suggests no packages.
Bug#961596: rebar: Remove -lerl_interface from ERL_LDFLAGS for Erlang 23
Package: rebar Version: 2.6.4-2 Severity: normal Dear Maintainer, I'd like to upload Erlang 23 to Debian for bullseye, so we'll need to make its reverse dependencies working. One of the changes in Erlang 23 is removal of an outdated erl_interface library. Rebar adds '-lerl_interface' to ERL_LDFLAGS, which means that packages will start FTBFS complaining about non-existing library (for example the esdl package doesn't use erl_interface, but still FTBFS with Erlang 23 because of rebar's trying to link it in). I'd suggest to remove -lerl_interface from the default rebar config. Packages that really depend on it will have to adjust anyway. -- System Information: Debian Release: 10.4 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages rebar depends on: ii erlang-asn1 1:21.2.6+dfsg-1 ii erlang-base 1:21.2.6+dfsg-1 ii erlang-crypto1:21.2.6+dfsg-1 ii erlang-dev 1:21.2.6+dfsg-1 ii erlang-dialyzer 1:21.2.6+dfsg-1 ii erlang-diameter 1:21.2.6+dfsg-1 ii erlang-edoc 1:21.2.6+dfsg-1 ii erlang-eunit 1:21.2.6+dfsg-1 ii erlang-reltool 1:21.2.6+dfsg-1 ii erlang-snmp 1:21.2.6+dfsg-1 ii erlang-syntax-tools 1:21.2.6+dfsg-1 ii erlang-tools 1:21.2.6+dfsg-1 Versions of packages rebar recommends: ii git1:2.20.1-2+deb10u3 ii mercurial 4.8.2-1+deb10u1 rebar suggests no packages. -- no debconf information
Bug#961579: stretch-pu: package erlang/1:19.2.1+dfsg-2+deb9u3
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Hi release team! Recently, a weak ciphers vulnerability was discovered in the Yaws web server, and reported as CVE-2020-12872 (see [1] and [2]). It turnes out that Yaws uses the default ciphers provided by Erlang, so I think it's better to fix this bug there. If we consider only Erlang packages in stretch, buster, bullseye/sid then only the version in stretch is vulnerable, so I'd like to propose an update for it. The proposed patch is attached. It's a minimal patch which jusr removes the 3DES based ciphers from the offered list for TLS v1.0. The later Erlang versions do just that - remove these ciphers from the list. If the patch is okay then I'll upload the fixed version. [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12872 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961422 -- System Information: Debian Release: 10.4 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru erlang-19.2.1+dfsg/debian/changelog erlang-19.2.1+dfsg/debian/changelog --- erlang-19.2.1+dfsg/debian/changelog 2019-02-09 01:28:34.0 +0300 +++ erlang-19.2.1+dfsg/debian/changelog 2020-05-26 11:30:58.0 +0300 @@ -1,3 +1,10 @@ +erlang (1:19.2.1+dfsg-2+deb9u3) stretch; urgency=medium + + * Applied a patch which fixes CVE-2020-12872 vulnerability revealed +for the Yaws web server (TLS server offers weak ciphers for TLS 1.0). + + -- Sergei Golovan Tue, 26 May 2020 11:30:58 +0300 + erlang (1:19.2.1+dfsg-2+deb9u2) stretch; urgency=medium [ Andreas Beckmann ] diff -Nru erlang-19.2.1+dfsg/debian/patches/cve-2020-12872.patch erlang-19.2.1+dfsg/debian/patches/cve-2020-12872.patch --- erlang-19.2.1+dfsg/debian/patches/cve-2020-12872.patch 1970-01-01 03:00:00.0 +0300 +++ erlang-19.2.1+dfsg/debian/patches/cve-2020-12872.patch 2020-05-26 11:30:58.0 +0300 @@ -0,0 +1,25 @@ +From: Sergei Golovan +Subject: Patch removes ciphers which are now considered weak + from the default TLS ciphers list. The vulnerability was found + in the Yaws web server and described as CVE-2020-12872. + It is fixed in the later Erlang releases. +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961422 +Forwarded: no + +--- a/lib/ssl/src/tls_v1.erl b/lib/ssl/src/tls_v1.erl +@@ -204,14 +204,6 @@ + ?TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, + ?TLS_RSA_WITH_AES_256_CBC_SHA, + +- ?TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, +- ?TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, +- ?TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, +- ?TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, +- ?TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, +- ?TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, +- ?TLS_RSA_WITH_3DES_EDE_CBC_SHA, +- + ?TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, + ?TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, + ?TLS_DHE_RSA_WITH_AES_128_CBC_SHA, diff -Nru erlang-19.2.1+dfsg/debian/patches/series erlang-19.2.1+dfsg/debian/patches/series --- erlang-19.2.1+dfsg/debian/patches/series2017-03-22 15:31:29.0 +0300 +++ erlang-19.2.1+dfsg/debian/patches/series2020-05-26 11:30:58.0 +0300 @@ -12,3 +12,4 @@ x32.patch cve-2016-10253.patch cve-2017-1000385.patch +cve-2020-12872.patch
Bug#961422: [Pkg-erlang-devel] Bug#961422: yaws: CVE-2020-12872
Hi Salvatore, On Sun, May 24, 2020 at 4:09 PM Salvatore Bonaccorso wrote: > > The following vulnerability was published for yaws. > > CVE-2020-12872[0]: > | yaws_config.erl in Yaws through 2.0.2 and/or 2.0.7 loads obsolete TLS > | ciphers, as demonstrated by ones that allow Sweet32 attacks. > As far as I can see, YAWS just uses the ciphersuite offered by the Erlang ssl application. It indeed includes 3DES based ciphers in Erlang 19.2.1 (in stretch) and in Erlang 17.3 (in jessie), but doesn't do so in Erlang 21.2.6 (in buster) and in later versions (in bullseye, sid and experimental). So, currently, YAWS is vulnerable for jessie and stretch only. > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. I would rather suggest to reassign this bug to erlang-ssl, and fix it there (as not only YAWS can use this list of ciphers). I've already prepared a patch for erlang in stretch, and if you think it's an acceptable way of fixing this bug, I'll inform the release team about it. I wouldn't like to do anything about jessie, since its LTS support comes to an end soon. Sheers! -- Sergei Golovan
Bug#959505: release.debian.org: Is erlang autoremoval is necessary?
Hi Mattia, On Sun, May 3, 2020 at 12:11 PM Mattia Rizzolo wrote: > > On Sun, May 03, 2020 at 09:39:51AM +0300, Sergei Golovan wrote: > > Today, I've got an autoremoval mails for erlang and a whole bunch of related > > packages because of #958841 (see [1] for details). > > > > Is it really necessary to remove erlang and all its reverse dependencies, > > while it's elixir-lang which is the culprit? > > Well, that bug is assigned to *both* erlang and erlang-elixir, and in > fact, the fix was done in erlang, so it really much looks like an erlang > bug? It wasn't really a fix, I just bumped the erlang-pcre virtual package version exactly to make elixir-lang uninstallable because it's broken. > > Now, it seems that wasn't enough, since erlang-elixir still doesn't pass > its autopkgtest with the new erlang; worse, it makes elixir-lang > uninstallable. Elixir-lang (at least its current version in Debian) uses some unstable interface in Erlang, so it's sometimes requires to be rebuilt with the new erlang. As far as I can see now, elixir-lang is basically unmaintained, so nobody will ask for binNMU (it should be sufficient, but I havent't checked this). > > > As far as I can see, removal > > of all erlang related packages (which includes elixir-lang) should lead to > > moving them back except for elixir-lang which is now uninstallable. > > What do you mean with "moving back"? After erlang, elixir-lang and many other packages will be removed from testing, nothing should prevent erlang and other packages to move back again, because there wouldn't be a problem with them in testing anymore. elixir-lang, on the other hand remains uninstallable in unstable (which is fine by me, since it isn't maintained anyway). > > > On the other hand, just removing elixir-lang from testing achieves the same > > outcome without removing/moving back many packages. > > The autoremoval is quite confusing (perhaps actually buggy?) when bugs > are assigned against multiple packages. In fact, only erlang is being > autoremoved, elixir-lang is being removed only due to being a rdep of > erlang. I see that. May be it's a bug in autoremovals. As for now, erlang version in testing isn't buggy, and the bugreport was actually filed against 1:22.3.2+dfsg-1 which was in unstable at the time of the bugreport. > > Please read with more attention the text of the bug: > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958841 > | Due to the nature of this issue, I filed this bug report against > | both packages. Can you please investigate the situation and reassign the > | bug to the right package? > I'm confident that if you reassign this bug to erlang only (and properly > changing the 'found', 'fixed' and 'done' values), nothing > would be autoremoved, simply because that bug won't affect erlang in > testing anymore. It's not a desirable output here. This means that without some changes in elixir-lang new erlang packages will never reach testing. I'm not sure that an unmaintained package should stall development of its reverse dependencies like that. > > Lastly, I recommend you just don't spend too much time on understanding > the autorm situation, rather just fix whatever is broken and make > elixir-lang pass the autopkgtest again; the autorm date is more than a > month away after all. I would say that binNMU would be sufficient for now, but I wouldn't like to constantly monitor this elixir-lang situation. Cheers! -- Sergei Golovan
Bug#959505: release.debian.org: Is erlang autoremoval is necessary?
Package: release.debian.org Severity: normal Hi release team! Today, I've got an autoremoval mails for erlang and a whole bunch of related packages because of #958841 (see [1] for details). Is it really necessary to remove erlang and all its reverse dependencies, while it's elixir-lang which is the culprit? As far as I can see, removal of all erlang related packages (which includes elixir-lang) should lead to moving them back except for elixir-lang which is now uninstallable. On the other hand, just removing elixir-lang from testing achieves the same outcome without removing/moving back many packages. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958841 -- System Information: Debian Release: 10.3 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#958841: erlang breaks elixir-lang autopkgtest: killed
On Mon, Apr 27, 2020 at 11:01 AM Sergei Golovan wrote: > Looks like changes in Erlang regular expressions library broke Elixir > again. Elixir stores internal binary representation of regular > expressions in its compilation phase, and it breaks when Erlang > changes this representation (which happens now and then, since it > isn't supposed to be stable). > > I've already added a virtual package which reflects the version of the > PCRE library Erlang uses (to indicate that Elixir requires > rebuilding), but clearly it's insufficient. I'll have to increment its > version on changes in erl_bif_re.c as well. > > As a long term solution, I'd suggest the maintainer of Elixir to reach > out downstream and suggest not to use unstable interfaces fro regular Sorry, I meant upstream here. > expressions (not precompile them in advance). Also, it seems like Elixir upstream did some enhancements in this area. See the changelog to 1.9.2: https://github.com/elixir-lang/elixir/releases/tag/v1.9.2 Cheers! -- Sergei Golovan
Bug#958841: erlang breaks elixir-lang autopkgtest: killed
Hi Paul! On Sat, Apr 25, 2020 at 10:09 PM Paul Gevers wrote: > > Dear maintainer(s), > > With a recent upload of erlang the autopkgtest of elixir-lang fails in > testing when that autopkgtest is run with the binary packages of erlang > from unstable. It passes when run with only packages from testing. In > tabular form: > >passfail > erlang from testing1:22.3.2+dfsg-1 > elixir-langfrom testing1.9.1.dfsg-1.3 > all others from testingfrom testing Looks like changes in Erlang regular expressions library broke Elixir again. Elixir stores internal binary representation of regular expressions in its compilation phase, and it breaks when Erlang changes this representation (which happens now and then, since it isn't supposed to be stable). I've already added a virtual package which reflects the version of the PCRE library Erlang uses (to indicate that Elixir requires rebuilding), but clearly it's insufficient. I'll have to increment its version on changes in erl_bif_re.c as well. As a long term solution, I'd suggest the maintainer of Elixir to reach out downstream and suggest not to use unstable interfaces fro regular expressions (not precompile them in advance). Cheers! -- Sergei Golovan
Bug#946670: ITP: tcl9.0 -- Tcl (the Tool Command Language) v9.0
Hi YunQiang, On Fri, Dec 13, 2019 at 3:05 PM YunQiang Su wrote: > > Sergei Golovan 于2019年12月13日周五 下午6:30写道： > > > > Package: wnpp > > Severity: wishlist > > Owner: Sergei Golovan > > > > * Package name: tcl9.0 > > Version : 9.0a1 > > I guess the version should be 9.0~a1 For the Debian package it will be. It's an upstream version. Cheers! -- Sergei Golovan
Bug#946670: ITP: tcl9.0 -- Tcl (the Tool Command Language) v9.0
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: tcl9.0 Version : 9.0a1 Upstream Author : Tcl Core Team * URL : http://www.tcl.tk/ * License : (BSD) Programming Lang: (C, Tcl) Description : Tcl (the Tool Command Language) v9.0 Tcl is a powerful, easy-to-use, embeddable, cross-platform interpreted scripting language. It's a new upstream release with major incompatibilities with the earlier ones (8.X), so it has to be packaged separately. The package will be maintained under the Debian Tcl/Tk team. Version 9.0 is in alpha stage yet, so I intend to upload it to experimental at the moment.
Bug#936678: Attachment
Hi Onur, Actually attaching the patch. Cheers! -- Sergei Golovan gumbo-parser_0.10.1+dfsg-2.4.diff Description: Binary data
Bug#936678: Patch & NMU suggestion
tags 936678 + patch thanks Hi Onur, I'd like to suggest a patch which removes the Python 2 support from gumbo-parser. It contains minimal changes I came up with to remove Python 2 and leave anything untouched. If you don't mind, I could do NMU with this patch. Cheers! -- Sergei Golovan
Bug#941124: [Pkg-erlang-devel] Bug#941124:
Hi Evgeny,
On Tue, Oct 1, 2019 at 1:27 PM Evgeny Golyshev wrote:
>
> Hello everyone
>
> I maintain Elixir in Debian.
> Obviously the compatibility between the Erlang's versions has been
> broken. I did a small research and found out that failing autopkgtest
> is the result of Erlang's :re module. Unfortunately, I can't provide
> details for the problem because a deeper study of it can take a lot of
> time which I don't have so far.
> Also I can confirm that rebuilding Elixir against the newest Erlang
> fixes the problem.
I'd like to propose a fix for this bug. It adds a dependency on newly
introduced virtual package erlang-pcre-, which will help to
notice when PCRE is changed.
The patch also utilises ${erlang:Depends} which calculates the dependencies
automatically. By the way, it appears that elixir should depend not only
on erlang-base, but also on a few other erlang related packages (erlang-crypto,
erlang-inets etc.)
If you don't mind, I could make a NMU with these changes (the NMU diff
is attached).
Cheers!
--
Sergei Golovan
elixir-lang_1.9.1dfsg-1.1.nmu.diff
Description: Binary data
Bug#941124: [Pkg-erlang-devel] Bug#941124:
Hi Evgeny,
On Tue, Oct 1, 2019 at 1:27 PM Evgeny Golyshev wrote:
>
> Hello everyone
>
> I maintain Elixir in Debian.
> Obviously the compatibility between the Erlang's versions has been
> broken. I did a small research and found out that failing autopkgtest
> is the result of Erlang's :re module. Unfortunately, I can't provide
> details for the problem because a deeper study of it can take a lot of
> time which I don't have so far.
> Also I can confirm that rebuilding Elixir against the newest Erlang
> fixes the problem.
Here is a simple example which demonstrates the issue.
Just compile it using Erlang 21 backend, and then run with Erlang 22.
The first call to a Regex.run/2 uses the precompiled regex, and will match
only "s", the second call uses the same regex but recompiles it, so it will
successfully match the whole string. (The original Erlang re:run also
succeeds because it isn't precompiled).
# reg.ex
defmodule Reg do
def run do
regex = ~r/[a-z]+/i
IO.puts Regex.opts(regex)
IO.puts Regex.source(regex)
IO.puts Regex.run(regex, "sTrInG")
IO.puts Regex.run(Regex.recompile!(regex), "sTrInG")
IO.puts inspect :re.run("sTrInG", "[a-z]+", [:caseless])
end
end
Cheers!
--
Sergei Golovan
Bug#941124: nmu: elixir-lang_1.9.1.dfsg-1
Hi!
On Mon, Sep 30, 2019 at 10:02 PM Paul Gevers wrote:
> >
> > Apparently, elixir-land needs to be rebuilt against newer erlang 22.1.
>
> That's not the proper way to solve bugs.
Indeed, it seems to me now that it's a bug in packaging Erlang and
Elixir. We'll try to fix it.
>
> > Currently, it doesn't pass autopkgtest (see [1] for details).
> >
> > There were some internal changes in Erlang re module (regular expressions)
> > which
> > triggered the test failure. After a simple rebuild all tests pass again.
>
> This means that either erlang changed something they shouldn't have
> changed (think of software outside of the Debian archive here as well),
> or elixir-lang is buggy and it is using something of erlang that it
> should be using (in its autopkgtest). Please discuss and figure out
> which package needs to fix something and reassign the package to it.
After some digging, I've found that the situation is indeed
documented. Citing from
elixir-lang-source/lib/elixir/lib/regex.ex:
Regular expressions built with sigil are precompiled and stored in `.beam`
files. Precompiled regexes will be checked in runtime and may work slower
between operating systems and OTP releases. This is rarely a
problem, as most Elixir code
shared during development is compiled on the target (such as dependencies,
archives, and escripts) and, when running in production, the code must either
be compiled on the target (via `mix compile` or similar) or released on the
host (via `mix releases` or similar) with a matching OTP, OS and architecture
as as the target.
If you know you are running on a different system that the current one and
you are doing multiple matches with the regex, you can manually invoke
`Regex.recompile/1` or `Regex.recompile!/1` to perform a runtime version
check and recompile the regex if necessary.
It happened that the PCRE library Erlang uses was updated in Erlang 22.1,
so the precompiled regexs (at least some of them) stopped working in the new
runtime. The elixir sources have to be rebuilt to match the PCRE changes
(there's no need to fix anything in the sources because re: API in Erlang
didn't change).
Can it be treated as a bug in Elixir that needs to be fixed? I'm not
sure upstream
will agree.
So, I'd like to suggest the following: I'll add another virtual package
(erlang-pcre-8.43 as for now) reflecting the PCRE version currently in Erlang.
Elixir will depend on it (via ${erlang-pcre:Depends} substitution variable and
the erlang-depends script call in debian/rules). This means that when the PCRE
library updates, elixir temporarily becomes uninstallable and needs a rebuild
(binNMU will suffice in this case).
The PCRE library updates in Erlang infrequently (approximately one
time per year),
so I don't think that it'd be a serious burden to the maintainers.
Alternatively, one could try to convince Elixir authors not to
precompile regex on creation
(or to patch it).
Cheers!
--
Sergei Golovan
Bug#941124: nmu: elixir-lang_1.9.1.dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu elixir-lang_1.9.1.dfsg-1 . ANY . unstable . -m "Rebuild against erlang 22.1" Hi release team! Apparently, elixir-land needs to be rebuilt against newer erlang 22.1. Currently, it doesn't pass autopkgtest (see [1] for details). There were some internal changes in Erlang re module (regular expressions) which triggered the test failure. After a simple rebuild all tests pass again. [1] https://ci.debian.net/data/autopkgtest/testing/amd64/e/elixir-lang/3018464/log.gz -- System Information: Debian Release: 10.1 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#939804: [Pkg-erlang-devel] Bug#939804: erlang: FTBFS on hppa - escript: exception error: bad argument
Hi John,
On Tue, Sep 10, 2019 at 4:58 AM John David Anglin wrote:
>
> I added some printfs to the code.
>
> thr_wrapper: stacksize=0x0
> thr_wrapper: stacksize=0x0
> thr_wrapper: stacksize=0x0
> thr_wrapper: stacksize=0x1
> thr_wrapper: stacksize=0x1
> thr_wrapper: stacksize=0x1
> erts_init_bif_re: =0xf9730748 ERTS STACK LIMIT=0x0
> erts_init_bif_re: =0xf9df6748 ERTS STACK LIMIT=0x0
> erts_init_bif_re: =0xf90b0748 ERTS STACK LIMIT=0x0
> erts_init_bif_re: =0xf908c748 ERTS STACK LIMIT=0x0
This seems to cause the issue since stack limit 0x0 means that it's still
uninitialized, but it's used in a comparison which determines the
direction of stack.
>
> It would seem to me that ERTS_STACK_LIMIT is incorrect. As a result,
> stack_guard_downwards
> is called instead of stack_guard_upwards.
>
> It's also a bit odd that twd->stacksize in thr_wrapper is sometimes 0.
> Think ethr_thr_create
> needs looking at.
May be. As a quick fix I can suggest a separate check for the stack
direction in erl_bif_re.c, here's a patch.
--- a/erts/emulator/beam/erl_bif_re.c
+++ b/erts/emulator/beam/erl_bif_re.c
@@ -90,6 +90,15 @@
return erts_check_above_limit(, limit - ERTS_PCRE_STACK_MARGIN);
}
+__attribute__((noinline)) static int stack_grows_downwards(char *prev_c)
+{
+char c;
+if ( < prev_c)
+return 1;
+else
+return 0;
+}
+
void erts_init_bif_re(void)
{
char c;
@@ -97,7 +106,7 @@
erts_pcre_free = _erts_pcre_free;
erts_pcre_stack_malloc = _erts_pcre_stack_malloc;
erts_pcre_stack_free = _erts_pcre_stack_free;
-if ((char *) erts_ptr_id() > ERTS_STACK_LIMIT)
+if (stack_grows_downwards())
erts_pcre_stack_guard = stack_guard_downwards;
else
erts_pcre_stack_guard = stack_guard_upwards;
I don't think it can be accepted upstream as a permanent fix though. I
think it'd
be better to fix the stack limit initialization somehow.
Cheers!
--
Sergei Golovan
Bug#939804: [Pkg-erlang-devel] Bug#939804: erlang: FTBFS on hppa - escript: exception error: bad argument
Hi John,
On Mon, Sep 9, 2019 at 2:13 PM John David Anglin wrote:
>
> If you know how to reduce one of these regexp problems, I could look again.
> Debugging
> across forks is problematic (i.e., the error doesn't occur in escript).
I seem to find the problematic code. If you look into
erts/emulator/beam/erl_bif_re.c then
you'll find the following lines after line 66:
#define ERTS_PCRE_STACK_MARGIN (10*1024)
# define ERTS_STACK_LIMIT ((char *) ethr_get_stacklimit())
static int
stack_guard_downwards(void)
{
char *limit = ERTS_STACK_LIMIT;
char c;
ASSERT(limit);
return erts_check_below_limit(, limit + ERTS_PCRE_STACK_MARGIN);
}
static int
stack_guard_upwards(void)
{
char *limit = ERTS_STACK_LIMIT;
char c;
ASSERT(limit);
return erts_check_above_limit(, limit - ERTS_PCRE_STACK_MARGIN);
}
void erts_init_bif_re(void)
{
char c;
erts_pcre_malloc = _erts_pcre_malloc;
erts_pcre_free = _erts_pcre_free;
erts_pcre_stack_malloc = _erts_pcre_stack_malloc;
erts_pcre_stack_free = _erts_pcre_stack_free;
if ((char *) erts_ptr_id() > ERTS_STACK_LIMIT)
erts_pcre_stack_guard = stack_guard_downwards;
else
erts_pcre_stack_guard = stack_guard_upwards;
default_table = NULL; /* ISO8859-1 default, forced into pcre */
max_loop_limit = CONTEXT_REDS * LOOP_FACTOR;
erts_init_trap_export(_exec_trap_export, am_erlang, am_re_run_trap, 3,
_exec_trap);
grun_trap_exportp = erts_export_put(am_re,am_grun,3);
urun_trap_exportp = erts_export_put(am_re,am_urun,3);
ucompile_trap_exportp = erts_export_put(am_re,am_ucompile,2);
return;
}
The code
if ((char *) erts_ptr_id() > ERTS_STACK_LIMIT)
erts_pcre_stack_guard = stack_guard_downwards;
else
erts_pcre_stack_guard = stack_guard_upwards;
has been introduces in version 20, and it is used to protect stack
during PCRE calls.
It seems that this stack protection doesn't work for hppa and always
fails. As a result,
every call to a regexp routine fails.
After I remove the erts_pcre_stack_guard assignment, Erlang started to
build on hppa
just fine.
Unfortunately, I don't know anything about stack in hppa architecture,
so I can't offer
a proper fix in this case.
I hope this'll help in debugging and developing a fix.
Cheers!
--
Sergei Golovan
Bug#939804: [Pkg-erlang-devel] Bug#939804: erlang: FTBFS on hppa - escript: exception error: bad argument
Hi John, On Mon, Sep 9, 2019 at 1:33 AM John David Anglin wrote: > > Source: erlang > Version: 1:20.3.8.8+dfsg-1 > Severity: normal > > Dear Maintainer, > > Since version 1:20.3.8.8+dfsg-1, erlang has failed to build on hppa. It > fails with a bad argument exception running escript: I've noticed that, but at the time the bug has been introduced I didn't find a solution too. > > escript /<>/lib/erl_docgen/priv/bin/github_link.escript > diameter_codec.xml \ > "lib/diameter/doc/src/diameter_codec.xml" "NA" ../xml/diameter_codec.xml > escript: exception error: bad argument > in function re:split/3 Looks like something goes wrong with the regexp engine introduced in Erlang 20. We don't see consistent FTBFS until version 21.0, but it's only because re:split/3 hasn't been used during Erlang builds. If you look at YAWS build logs for example (see [1]), you'll see that it started to fail on hppa just at the time Erlang 20 appears. I'll look into this, but I can't promise that it'll be soon. The hppa architecture has pretty low priority now, sorry. [1] https://buildd.debian.org/status/logs.php?pkg=yaws=hppa Cheers! -- Sergei Golovan
Bug#931967: buster-pu: package libtk-img/1:1.4.8+dfsg-1+deb10u1 pre-approval
On Tue, Aug 20, 2019 at 11:20 PM Adam D. Barratt wrote: > > OK, thanks. Please go ahead. Done. Cheers! -- Sergei Golovan
Bug#931968: stretch-pu: package libtk-img/1:1.4.6+dfsg-1+deb9u1 pre-approval
On Wed, Aug 21, 2019 at 1:38 AM Adam D. Barratt wrote: > > Thanks. Please go ahead. Done. Cheers! -- Sergei Golovan
Bug#931968: stretch-pu: package libtk-img/1:1.4.6+dfsg-1+deb9u1 pre-approval
Hi Adam, On Fri, Jul 26, 2019 at 10:46 PM Adam D. Barratt wrote: > > Control: tags -1 + moreinfo > > On 2019-07-13 01:26, Sergei Golovan wrote: > > I'd like to fix #931422 (see [1]) for stretch (the bug is already fixed > > in unstable, see also #931967 [2]). > > > > The diff with the current 1:1.4.6+dfsg-1 is attaced. > > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931422 > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931967 > > The same question applies here as for the buster update, i.e. what is > the practical impact of the change? The answer is the same as for bug 931967. From the user point of view nothing should be changed. Just some images which now cause a segfault when loaded by libtk-img will load just fine. Cheers! -- Sergei Golovan
Bug#931967: buster-pu: package libtk-img/1:1.4.8+dfsg-1+deb10u1 pre-approval
Hi Adam, On Fri, Jul 26, 2019 at 10:32 PM Adam D. Barratt wrote: > On 2019-07-13 01:19, Sergei Golovan wrote: > > I'd like to fix #931422 (see [1]) for buster (the bug is already fixed > > in unstable and prospectively in testing). > > > > The diff with the current 1:1.4.8+dfsg-1 is attaced, it's fairly small. > > What are the implications of the change on functionality and consumers > of the library? To my knowledge, the functionality doesn't change. It definitely doesn't change on a script level, on a C level there are a few internal symbols that won't be available in the fixed library (e.g. TkimgTIFFInitJpeg), though they aren't exported, they aren't listed in `objdump -T libtkimgtiff*.so`, and they aren't supposed to be used by a caller to this library (and noone calls them indeed). > > > Also, I'd like to ask if I should make a source-only or binary upload > > to > > stable (and/or oldstable) now? > > Source-only would be preferred, so long as the .changes filename is > sensible (i.e. *not* _amd64.changes when no amd64 binaries are actually > included). I see, thank you for the info. > > If the issue also affects stretch and you would like to update the > package there, please open a separate appropriately-tagged request to > discuss that. Yes, I did open a separate report, and you've already answered to it. In fact, the original bug was reported to stretch. Cheers! -- Sergei Golovan
Bug#932316: ITP: lua5.4 -- lightweight, embeddable scripting language
Package: wnpp Severity: wishlist Owner: Sergei Golovan * Package name: lua5.4 Version : 5.4.0-alpha Upstream Author : Lua Team * URL : https://www.lua.org/ * License : Expat Programming Lang: C Description : lightweight, embeddable scripting language It's the next major release of Lua. Currently only alpha version is released upstream, so I intend to keep it in experimental for a while. The maintenance will take place under the Lua Team umbrella. -- Sergei Golovan
Bug#931968: stretch-pu: package libtk-img/1:1.4.6+dfsg-1+deb9u1 pre-approval
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Hi release team,
I'd like to fix #931422 (see [1]) for stretch (the bug is already fixed
in unstable, see also #931967 [2]).
The diff with the current 1:1.4.6+dfsg-1 is attaced.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931422
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931967
-- System Information:
Debian Release: 10.0
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'oldoldstable'), (500, 'stable'),
(500, 'oldstable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libtk-img-1.4.6+dfsg/debian/changelog
libtk-img-1.4.6+dfsg/debian/changelog
--- libtk-img-1.4.6+dfsg/debian/changelog 2017-01-17 11:24:03.0
+0300
+++ libtk-img-1.4.6+dfsg/debian/changelog 2019-07-12 17:28:05.0
+0300
@@ -1,3 +1,10 @@
+libtk-img (1:1.4.6+dfsg-1+deb9u1) stretch; urgency=medium
+
+ * Switch from the internal copies of Jpeg, Zlib and PixarLog codecs to the
+libtiff ones (closes: #931422).
+
+ -- Sergei Golovan Fri, 12 Jul 2019 17:28:05 +0300
+
libtk-img (1:1.4.6+dfsg-1) unstable; urgency=medium
* New upstream release.
diff -Nru libtk-img-1.4.6+dfsg/debian/patches/libtiff.diff
libtk-img-1.4.6+dfsg/debian/patches/libtiff.diff
--- libtk-img-1.4.6+dfsg/debian/patches/libtiff.diff2016-04-06
23:11:12.0 +0300
+++ libtk-img-1.4.6+dfsg/debian/patches/libtiff.diff2019-07-12
17:28:05.0 +0300
@@ -327,6 +327,21 @@
TIFFTileRowSize && TIFFScanlineSize && _TIFFsetByteArray &&
TIFFVSetField && TIFFSwabArrayOfShort
) {
+@@ -125,14 +125,10 @@
+ if (Zlibtcl_InitStubs(interp, ZLIBTCL_VERSION, 0) == NULL) {
+ return TCL_ERROR;
+ }
+-TIFFRegisterCODEC (COMPRESSION_DEFLATE, "Deflate",
TkimgTIFFInitZip);
+-TIFFRegisterCODEC (COMPRESSION_ADOBE_DEFLATE, "AdobeDeflate",
TkimgTIFFInitZip);
+
+ if (Jpegtcl_InitStubs(interp, JPEGTCL_VERSION, 0) == NULL) {
+ return TCL_ERROR;
+ }
+-TIFFRegisterCODEC (COMPRESSION_JPEG, "JPEG",
TkimgTIFFInitJpeg);
+-TIFFRegisterCODEC (COMPRESSION_PIXARLOG, "PixarLog",
TkimgTIFFInitPixar);
+ }
+ }
+ return TCL_OK;
--- a/tiff/tiffJpeg.c
+++ b/tiff/tiffJpeg.c
@@ -1599,7 +1599,7 @@
@@ -360,3 +375,25 @@
sp->vgetparent = tif->tif_tagmethods.vgetfield;
tif->tif_tagmethods.vgetfield = ZIPVGetField; /* hook for codec tags
*/
sp->vsetparent = tif->tif_tagmethods.vsetfield;
+--- a/tiff/configure
b/tiff/configure
+@@ -8244,7 +8244,7 @@
+ #---
+
+
+-vars="tiff.c tiffJpeg.c tiffZip.c tiffPixar.c"
++vars="tiff.c"
+ for i in $vars; do
+ case $i in
+ \$*)
+--- a/tiff/configure.in
b/tiff/configure.in
+@@ -75,7 +75,7 @@
+ # and PKG_TCL_SOURCES.
+ #---
+
+-TEA_ADD_SOURCES([tiff.c tiffJpeg.c tiffZip.c tiffPixar.c])
++TEA_ADD_SOURCES([tiff.c])
+ TEA_ADD_HEADERS([])
+ TEA_ADD_INCLUDES([-I\"`\${CYGPATH} \${srcdir}`\"])
+ TEA_ADD_INCLUDES([-I\"`\${CYGPATH} \${tkimg_SRC_PATH}`\"])
Bug#931967: buster-pu: package libtk-img/1:1.4.8+dfsg-1+deb10u1 pre-approval
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi release team,
I'd like to fix #931422 (see [1]) for buster (the bug is already fixed
in unstable and prospectively in testing).
The diff with the current 1:1.4.8+dfsg-1 is attaced, it's fairly small.
Also, I'd like to ask if I should make a source-only or binary upload to
stable (and/or oldstable) now?
-- System Information:
Debian Release: 10.0
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'oldoldstable'), (500, 'stable'),
(500, 'oldstable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libtk-img-1.4.8+dfsg/debian/changelog
libtk-img-1.4.8+dfsg/debian/changelog
--- libtk-img-1.4.8+dfsg/debian/changelog 2019-02-07 14:11:34.0
+0300
+++ libtk-img-1.4.8+dfsg/debian/changelog 2019-07-12 16:35:27.0
+0300
@@ -1,3 +1,10 @@
+libtk-img (1:1.4.8+dfsg-1+deb10u1) buster; urgency=medium
+
+ * Switch from the internal copies of Jpeg, Zlib and PixarLog codecs to the
+libtiff ones (closes: #931422).
+
+ -- Sergei Golovan Fri, 12 Jul 2019 16:35:27 +0300
+
libtk-img (1:1.4.8+dfsg-1) unstable; urgency=medium
* New upstream release.
diff -Nru libtk-img-1.4.8+dfsg/debian/patches/libtiff.diff
libtk-img-1.4.8+dfsg/debian/patches/libtiff.diff
--- libtk-img-1.4.8+dfsg/debian/patches/libtiff.diff2019-02-07
14:11:34.0 +0300
+++ libtk-img-1.4.8+dfsg/debian/patches/libtiff.diff2019-07-12
16:35:27.0 +0300
@@ -327,6 +327,21 @@
TIFFTileRowSize && TIFFScanlineSize && _TIFFsetByteArray &&
TIFFVSetField && TIFFSwabArrayOfShort
) {
+@@ -125,14 +125,10 @@
+ if (Zlibtcl_InitStubs(interp, ZLIBTCL_VERSION, 0) == NULL) {
+ return TCL_ERROR;
+ }
+-TIFFRegisterCODEC (COMPRESSION_DEFLATE, "Deflate",
TkimgTIFFInitZip);
+-TIFFRegisterCODEC (COMPRESSION_ADOBE_DEFLATE, "AdobeDeflate",
TkimgTIFFInitZip);
+
+ if (Jpegtcl_InitStubs(interp, JPEGTCL_VERSION, 0) == NULL) {
+ return TCL_ERROR;
+ }
+-TIFFRegisterCODEC (COMPRESSION_JPEG, "JPEG",
TkimgTIFFInitJpeg);
+-TIFFRegisterCODEC (COMPRESSION_PIXARLOG, "PixarLog",
TkimgTIFFInitPixar);
+ }
+ }
+ return TCL_OK;
--- a/tiff/tiffJpeg.c
+++ b/tiff/tiffJpeg.c
@@ -1599,7 +1599,7 @@
@@ -360,3 +375,25 @@
sp->vgetparent = tif->tif_tagmethods.vgetfield;
tif->tif_tagmethods.vgetfield = ZIPVGetField; /* hook for codec tags
*/
sp->vsetparent = tif->tif_tagmethods.vsetfield;
+--- a/tiff/configure
b/tiff/configure
+@@ -6719,7 +6719,7 @@
+ #---
+
+
+-vars="tiff.c tiffJpeg.c tiffZip.c tiffPixar.c"
++vars="tiff.c"
+ for i in $vars; do
+ case $i in
+ \$*)
+--- a/tiff/configure.in
b/tiff/configure.in
+@@ -75,7 +75,7 @@
+ # and PKG_TCL_SOURCES.
+ #---
+
+-TEA_ADD_SOURCES([tiff.c tiffJpeg.c tiffZip.c tiffPixar.c])
++TEA_ADD_SOURCES([tiff.c])
+ TEA_ADD_HEADERS([])
+ TEA_ADD_INCLUDES([-I\"`\${CYGPATH} \${srcdir}`\"])
+ TEA_ADD_INCLUDES([-I\"`\${CYGPATH} \${tkimg_SRC_PATH}`\"])
Bug#931422: Segmentation fault opening TIFF file
Hi Christopher, On Thu, Jul 4, 2019 at 5:09 PM Christopher Chavez wrote: > > Using Debian 9.9 i386 (32-bit). I am not sure if this bug should instead be > reported against libtiff5 (4.0.8-2+deb9u4). > > A segmentation fault occurs when using the following 3-line script and an > example image obtained from > https://sourceforge.net/p/openil/svn/1479/tree/trunk/Test%20Images/TIF/libtiffpic/quad-jpeg.tif > . I am not aware of any other example images that exhibit the exact same > issue. I confirm the bug. Also in 1.4.8+dfsg-1 which is currently in Debian 10. The bug is introduces by me when I forced libtk-img to use the system-wide libtiff instead of the one bundled with the libtk-img sources. I'll fix it in unstable shortly, and then in stable and in oldstable (it'll be available in the updates repository, and after a while in the next point release). Thank you for the bugreport! -- Sergei Golovan
