Bug#1067084: ruby-sigar: FTBFS on arm{el,hf}: /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"

[Praveen Arimbrathodiyil]

On Mon, 18 Mar 2024 09:13:47 +0100 Sebastian Ramacher 
 wrote:

Justification: fails to build from source (but built successfully in the past)
This packaged can be removed once ruby-eye is removed. RM request filed 
for its only reverse dependency ruby-eye.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068230: [Debian-on-mobile-maintainers] Bug#1068230: automatic suspend regression with gnome-settings-daemon 46

[Praveen Arimbrathodiyil]

On 3/4/24 8:26 PM, Guido Günther wrote:

Thanks for checking! Please always make sure you check for inhibitors
(`gnome-session-inhibit -l`, `systemd-inhibit -l`) to make sure nothing
left a suspend/sleep inhibitor blocking this.


I noticed it happening for a few days and across multiple reboots (I 
doubt inhibitors persist across reboots). Then switched to plasma mobile 
and it started working. Then I reported the issue and switched back to 
phosh (since plasma mobile was too unstable, many things keep crashing 
all the time) and noticed the regression is gone.


Another thing I noticed is after multiple suspend resume cycles, modem 
stop working and then I need a force power off and reboot with hard ware 
switch (may be this was the actual cause instead of regression). Normal 
shutdown just hangs with the plymouth screen there.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068230: automatic suspend regression with gnome-settings-daemon 46

[Praveen Arimbrathodiyil]

On Tue, 2 Apr 2024 08:04:12 -0400 =?UTF-8?Q?Jeremy_B=C3=ADcha?= 
 wrote:

On Tue, Apr 2, 2024 at 8:03 AM Jeremy Bícha  wrote:
>
> On Tue, Apr 2, 2024 at 5:31 AM Pirate Praveen  
wrote:
> > Recently automatic suspend stopped working. I think this was after gnome 
settings daemon 46 was available. Some background
> > https://salsa.debian.org/Mobian-team/devices/librem5-support/-/issues/7
> >
> > Not sure if phosh needs some adjustments with recent changes in gnome 
settings daemon. For now assigned to both.
>
> Do you have phosh 0.37 or higher installed yet?

Correction: Do you have phosh 0.37.0-2 or 3.7.1-1 installed?
I still have phosh 0.36.0-1 but auto suspend started working again. So 
it was probably fixed in a recent kernel update.


Closing this.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068230: automatic suspend regression with gnome-settings-daemon 46

[Pirate Praveen]

Package: gnome-settings-daemon,phosh
severity: serious

Recently automatic suspend stopped working. I think this was after 
gnome settings daemon 46 was available. Some background



Not sure if phosh needs some adjustments with recent changes in gnome 
settings daemon. For now assigned to both.


On kde plasma mobile, automatic suspend still works, so this appears to 
be gnome specific regression.

Bug#1025084: ruby-graphlient fails to rebuild after updating ruby-faraday to upstream

[Pirate Praveen]

Control: fixed -1 0.7.0-1

On Wed, 7 Feb 2024 14:03:34 +0530 Praveen Arimbrathodiyil 
 wrote:

Control: severity -1 serious

On Sun, 18 Jun 2023 13:14:21 +0530 Pirate Praveen 
 wrote:
> 
> Since ruby-faraday-middleware is deprecated, we should update to 
> graphlient 0.7

ruby-faraday 2 is in unstable now.


Fixed in ruby-graphlient 0.7.0

Bug#1063654: ruby-graphql-errors - upstream dead and incompatible with ruby-graphql 2.x

[Pirate Praveen]

Package: ruby-graphql-errors
Version:  0.4.0-2
Severity: serious

source package has 1 unsatisfiable build dependency

Build dependencies in unstable cannot be satisfied on amd64 
because: unsatisfied dependency on ruby-graphql (< 2)


Last commint was 4 years ago and 
https://github.com/exAspArk/graphql-errors has a banner "This repository 
has been archived by the owner on Apr 8, 2020. It is now read-only."


This was originally packaged as build dependency for ruby-graphlient 
which no longer needs it.

Bug#1052730: marked as pending in ruby-delayed-job

[Praveen Arimbrathodiyil]

Control: tag -1 pending

Hello,

Bug #1052730 in ruby-delayed-job reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-delayed-job/-/commit/44203fe9814deb7de9c88d266aafc3f63f6850ba


Fix invalid time zone US/Eastern error (Closes: #1052730)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1052730

Bug#1052730: ruby-delayed-job: FTBFS: ERROR: Test "ruby3.1" failed: ArgumentError:

[Pirate Praveen]

Control: forwarded -1 
https://github.com/collectiveidea/delayed_job/pull/1203


On Tue, 26 Sep 2023 14:40:49 +0200 Lucas Nussbaum  wrote:


Relevant part (hopefully):
>  ArgumentError:
>Invalid Timezone: US/Eastern


Forwarded fix upstream 
https://github.com/collectiveidea/delayed_job/pull/1203

Bug#1063478: gem2deb rails assets smoke test should handle links or skip the test during build

[Pirate Praveen]

Control: severity -1 important

On 9/2/24 6:48 PM, Pirate Praveen wrote:
Without libjs-underscore in build depends, the test should fail, but it 
is passing.


ruby-rails-assets-underscore source package includes underscore.js and 
it is replaced by symlink to libjs-underscore only in dh_install stage 
so rake assets:precompile can still find it.


So it looks like gem2deb test is working as expected, but we still need 
to figure out a way out for symlinks. May be we should just link them in 
the build target itself as a solution. If that is the recommended 
solution, we can close this bug with a note in dh_ruby documentation.

Bug#1060658: [Debian-on-mobile-maintainers] Bug#1060658: megapixels don't start could not find any config file

[Pirate Praveen]

On 16/01/24 10:01 pm, Arnaud Ferraris wrote:

Hi,

Le 12/01/2024 à 10:37, Pirate Praveen a écrit :

Package: megapixels
Version: 1.7.0-1
Severity: grave

Running megapixels from commandline on mobian trixie fails with this error

/usr/share/megapixels/config/purism,librem5r4.ini not found.


This is expected, megapixels doesn't support the L5 (yet?).


I was looking at a blog post for QR code readers and mega pixel was 
mentioned


https://forums.puri.sm/t/qr-code-scanning-via-megapixels/14408

Found another reference now https://blog.brixit.nl/megapixels-2-0/

but seems this never finished.

Bug#1060658: megapixels don't start could not find any config file

[Pirate Praveen]

Package: megapixels
Version: 1.7.0-1
Severity: grave

Running megapixels from commandline on mobian trixie fails with this 
error


/usr/share/megapixels/config/purism,librem5r4.ini not found.

Bug#958682: node-jsonld: Remove dependency to node-request

[Pirate Praveen]

On Sun, 29 Oct 2023 21:37:08 +0100 Jonas Smedegaard  wrote:

Yes, I still want to work on node-jsonld - I will make time to look at
this soon...


yarnpkg 4.0.2 was recently uploaded to unstable, so this and 
node-matrix-js-sdk are the only remaining reverse dependencies for 
node-request. We have an ack from its maintainer to remove it 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958692#42 so this is 
the only real blocker remaining to remove node-request.

Bug#1053799: golang-github-libgit2-git2go: no upstream support for latest libgit2

[Praveen Arimbrathodiyil]

On Sun, 5 Nov 2023 07:07:21 +0800 Shengjing Zhu  wrote:

git2go is packaged for building gitaly. gitaly upstream has dropped
the git2go dependency.
Ref: https://gitlab.com/groups/gitlab-org/-/epics/9092


gitaly in salsa dropped this dependency. Once gitlab 16.4 is ready, this 
will be uploaded to experimental along with gitlab. Then once it is 
reuploaded to unstable, we can request removal of this package from the 
archive.



So IMO you can start libgit2 transition, and bump this bug's severity.

--
Shengjing Zhu




OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1058596: [Pkg-javascript-devel] Bug#1058596: yarnpkg broken on bookworm - yarnpkg --help fails with TypeError: commander.on is not a function

[Praveen Arimbrathodiyil]

On 13/12/23 9:13 pm, Praveen Arimbrathodiyil wrote:



On 13/12/23 8:54 pm, Praveen Arimbrathodiyil wrote:

On 13/12/23 8:52 pm, Yadd wrote:

since severity is grave, please prepare an update for stable also


Yes, I'm backporting the updated patch.


Proposed it to release team as #1058615


and uploaded to https://people.debian.org/~praveen/yarnpkg/ until we get 
the approval from release team (need this immediately for gitlab).


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1058596: [Pkg-javascript-devel] Bug#1058596: yarnpkg broken on bookworm - yarnpkg --help fails with TypeError: commander.on is not a function

[Praveen Arimbrathodiyil]

On 13/12/23 8:54 pm, Praveen Arimbrathodiyil wrote:

On 13/12/23 8:52 pm, Yadd wrote:

since severity is grave, please prepare an update for stable also


Yes, I'm backporting the updated patch.


Proposed it to release team as #1058615


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1058596: [Pkg-javascript-devel] Bug#1058596: yarnpkg broken on bookworm - yarnpkg --help fails with TypeError: commander.on is not a function

[Praveen Arimbrathodiyil]

On 13/12/23 8:52 pm, Yadd wrote:

since severity is grave, please prepare an update for stable also


Yes, I'm backporting the updated patch.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1058596: yarnpkg broken on bookworm - yarnpkg --help fails with TypeError: commander.on is not a function

[Praveen Arimbrathodiyil]

Control: fixed -1 1.22.19+~cs24.27.18-4

On Wed, 13 Dec 2023 20:39:39 +0530 Pirate Praveen  
wrote:

We should backport the patches in unstable to bookworm as well.


Updating the fixed info.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1058596: yarnpkg broken on bookworm - yarnpkg --help fails with TypeError: commander.on is not a function

[Pirate Praveen]

Package: yarnpkg
Version: 1.22.19+~cs24.27.18-2
severity: grave
justification: breaks any options passed to yarnpkg

yarnpkg install also fails with similar errors due to incompatible 
node-commander


We should backport the patches in unstable to bookworm as well.

# cat /usr/share/nodejs/yarn-error.log
Arguments:
  /usr/bin/node /usr/bin/yarnpkg --help

PATH:
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Yarn version:
  1.22.19

Node version:
  18.13.0

Platform:
  linux x64

Trace:
  TypeError: commander.on is not a function
  at Object.run (/usr/share/nodejs/yarn/lib/cli/commands/help.js:75:13)
  at run (/usr/share/nodejs/yarn/lib/cli/index.js:494:30)
  at /usr/share/nodejs/yarn/lib/cli/index.js:732:24

npm manifest:
  No manifest

yarn manifest:
  No manifest

Lockfile:
  No lockfile


# yarnpkg --frozen-lockfile install
TypeError: _commander(...).default.optionFor is not a function
at /usr/share/nodejs/yarn/lib/cli/index.js:355:88
at Array.findIndex ()
at _callee$ (/usr/share/nodejs/yarn/lib/cli/index.js:352:38)
at tryCatch 
(/usr/share/nodejs/@babel/runtime/helpers/regeneratorRuntime.js:44:17)
at Generator. 
(/usr/share/nodejs/@babel/runtime/helpers/regeneratorRuntime.js:125:22)
at Generator.next 
(/usr/share/nodejs/@babel/runtime/helpers/regeneratorRuntime.js:69:21)
at asyncGeneratorStep 
(/usr/share/nodejs/@babel/runtime/helpers/asyncToGenerator.js:3:24)
at _next 
(/usr/share/nodejs/@babel/runtime/helpers/asyncToGenerator.js:22:9)

at /usr/share/nodejs/@babel/runtime/helpers/asyncToGenerator.js:27:7
at new Promise ()

Bug#1056298: riseup-vpn dns configuration don't work with systemd-resolved

[Pirate Praveen]

package: riseup-vpn
severity: grave
version: 0.21.11+ds1-5+b4

It misses a dependency on openvpn-systemd-resolved and on boomworm it 
was working after installing it. But on mobian trixie, which has 
systemd-resolved installed by default (through mobian-base), dns 
resolution fails when riseup vpn is connected.


error log attached



;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; no servers could be reached

Bug#1055880: kaidan missing two dependencies

[Pirate Praveen]

Package: kaidan
version: 0.9.1-1
severity: grave
justification: fails to start

Though fix is easy, missing dependencies are

qml-module-org-kde-kquickimageeditor and
qml-module-org-kde-kirigami-addons-labs-mobileform

After installing these manually, kaidan starts as expected.

Bug#958692: node-matrix-js-sdk: Remove dependency to node-request

[Pirate Praveen]

On 2/11/23 10:27 PM, Hubert Chathi wrote:

On Sun, 29 Oct 2023 22:43:55 +0530, Praveen Arimbrathodiyil 
 said:


On Fri, 24 Apr 2020 13:52:39 +0200 y...@debian.org wrote:

Upstream has deprecated node-request:
https://github.com/request/request/issues/3142 It can be replaced by
node-got



Hi Jonas, Hubert,



Are you planning to update matrix-js-sdk? We'd like to remove
deprecated node-request from the archive and this package is a
blocker.


I don't currently have time to update matrix-js-sdk.  Feel free to
remove it from testing so that it doesn't block anything else.  I can
always upload a new version later.



This is already not in testing for 525 days. We can't remove a package 
from the archive if any package (build) depends on it.

Bug#958682: node-jsonld: Remove dependency to node-request

[Praveen Arimbrathodiyil]

On Fri, 31 Dec 2021 13:17:07 +0100 Yadd  wrote:

Hi,

updating node-jsonld is enough to fix this issue:


Hi Jonas,

Are you planning to update node-jsonld?

Else we can simply remove this package from Debian since it seems 
useless (no reverse dependencies).


This is blocking removal of deprecated node-request.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#958692: node-matrix-js-sdk: Remove dependency to node-request

[Praveen Arimbrathodiyil]

On Fri, 24 Apr 2020 13:52:39 +0200 y...@debian.org wrote:

Upstream has deprecated node-request:
https://github.com/request/request/issues/3142

It can be replaced by node-got 





Hi Jonas, Hubert,

Are you planning to update matrix-js-sdk? We'd like to remove deprecated 
node-request from the archive and this package is a blocker.


thanks
Praveen


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002901: node-request-capture-har is a wrapper around deprecated node-request

[Praveen Arimbrathodiyil]

On Fri, 31 Dec 2021 13:02:44 +0100 Yadd  wrote:

Package: node-request-capture-har
Version: 1.2.2-2
Severity: serious
Tags: upstream security
Justification: security
X-Debbugs-Cc: Debian Security Team 

node-request-capture-har is usable only as a wrapper around deprecated
node-request. Then it should be removed from Debian bookstorm.




yarnpkg 4.x in experimental no longer depends on this package. So once 
we reupload that to unstable, we can file rm request for this package.


We are pretty close to the unstable reupload 
https://lists.debian.org/debian-js/2023/10/msg00080.html


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1042967: nheko crashes on first launch in arm64 (librem 5)

[Pirate Praveen]

Package: nheko
Version: 0.11.3-2+b1
severity: grave
justification: makes the app unusable

I initially noticed this on mobian bookworm (then I switched to 
chatty). Now I can reliable reproduce it on trixie as well.


Crash log attached.

To reproduce rm -rf .local/share/nheko .config/nheko .cache/nheko
and run nheko from terminal

First noticed when I reinstalled, flatpack also fails same way so looks 
like an upstream issue.


Second time, nheko starts but initial sync never completes. Both chatty 
and gomuks works with same matrix id.


[2023-08-03 17:42:55.678] [ui] [info] Restoring window size 0x0
[2023-08-03 17:42:55.759] [ui] [info] WebRTC: initialised GStreamer 1.22.4
[2023-08-03 17:42:55.883] [ui] [info] jdenticon plugin not found.
[2023-08-03 17:42:57.976] [ui] [info] starting nheko 0.11.3
[2023-08-03 17:42:57.986] [ui] [info] Unity service available: false
Error: signal 11:
nheko(_Z17stacktraceHandleri+0x40)[0xd55ee940]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xa06be7ac]
nheko(+0x973940)[0xd5433940]
nheko(+0x977090)[0xd5437090]
nheko(+0x9783bc)[0xd54383bc]
/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0(+0x55270)[0x9da25270]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x148)[0x9d83a6c8]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(+0x5aaa0)[0x9d83aaa0]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x34)[0x9d83ab44]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x54)[0x9deef6d8]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x13c)[0x9de89d2c]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x98)[0x9de933f8]
nheko(main+0xd14)[0xd526b684]
/lib/aarch64-linux-gnu/libc.so.6(+0x26dc0)[0x9d2a6dc0]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98)[0x9d2a6e98]
nheko(_start+0x30)[0xd526c770]
Error: signal 6:
nheko(_Z17stacktraceHandleri+0x40)[0xd55ee940]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xa06be7ac]
/lib/aarch64-linux-gnu/libc.so.6(+0x7fd30)[0x9d2ffd30]
/lib/aarch64-linux-gnu/libc.so.6(gsignal+0x1c)[0x9d2b9e2c]
nheko(_Z17stacktraceHandleri+0xd8)[0xd55ee9d8]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xa06be7ac]
nheko(+0x973940)[0xd5433940]
nheko(+0x977090)[0xd5437090]
nheko(+0x9783bc)[0xd54383bc]
/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0(+0x55270)[0x9da25270]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x148)[0x9d83a6c8]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(+0x5aaa0)[0x9d83aaa0]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x34)[0x9d83ab44]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x54)[0x9deef6d8]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x13c)[0x9de89d2c]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x98)[0x9de933f8]
nheko(main+0xd14)[0xd526b684]
/lib/aarch64-linux-gnu/libc.so.6(+0x26dc0)[0x9d2a6dc0]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98)[0x9d2a6e98]
nheko(_start+0x30)[0xd526c770]

Bug#1030932: golang-github-go-enry-go-license-detector: FTBFS on mipsel: test failures

[Pirate Praveen]

Control: fixed -1 4.3.0+git20221007.a3a1cc6-3

On Thu, 13 Jul 2023 23:49:56 +0800 Shengjing Zhu  
wrote:

> You look at the wrong log, it's golang-github-hhatto-gorst, not
> golang-github-go-enry-go-license-detector.
> It FTBFS on buildd currently.

After increasing the timeout to 150m, the build is now succeeding on 
armel and mipsel.


https://buildd.debian.org/status/fetch.php?pkg=golang-github-go-enry-go-license-detector=armel=4.3.0%2Bgit20221007.a3a1cc6-3=1689278197=0

https://buildd.debian.org/status/fetch.php?pkg=golang-github-go-enry-go-license-detector=mipsel=4.3.0%2Bgit20221007.a3a1cc6-3=1689281650=0

Bug#1030932: golang-github-go-enry-go-license-detector: FTBFS on mipsel: test failures

[Pirate Praveen]

On Thu, Jul 13 2023 at 11:49:56 PM +08:00:00 +08:00:00, Shengjing Zhu 
 wrote:

Control: reopen -1



Thanks, I noticed the failure on buildd and was going to reopen it and 
found you did it aready.



Hi,

On Thu, Jul 13, 2023 at 6:09 PM Pirate Praveen 
 wrote:


 On Thu, 9 Feb 2023 14:40:48 +0100 Sebastian Ramacher
  wrote:
  > Source: golang-github-go-enry-go-license-detector
  > Version: 4.3.0+git20221007.a3a1cc6-1
  > Severity: serious
  > Tags: ftbfs
  > Justification: fails to build from source (but built 
successfully in

 the past)
  >
  >
 
https://buildd.debian.org/status/fetch.php?pkg=golang-github-go-enry-go-license-detector=mipsel=4.3.0%2Bgit20221007.a3a1cc6-1%2Bb2=1675941345=0

  >

 This looks like a temporary error, last build was passing

 
https://buildd.debian.org/status/fetch.php?pkg=golang-github-hhatto-gorst=mipsel=0.0%7Egit20181029.ca9f730-2%2Bb6=1681037294=0


You look at the wrong log, it's golang-github-hhatto-gorst, not
golang-github-go-enry-go-license-detector.
It FTBFS on buildd currently.



Thanks for pointing out the mistake. I was looking at both failures and 
got confused.

--
Shengjing Zhu

Bug#1030955: golang-github-hhatto-gorst: autopkgtest failure

[Pirate Praveen]

On Thu, 13 Jul 2023 21:24:53 +0530 Nilesh Patra  
wrote:

> Control: tags -1 patch
>
> On Thu, Jul 13, 2023 at 03:10:40PM +0530, Pirate Praveen wrote:
> > On Fri, 10 Feb 2023 00:07:51 +0200 Adrian Bunk  
wrote:
> > > The Ubuntu diff contains a patch that looks like a workaround 
(untested).

> >
> > This patch says data directory is reserved for golang autopkgtest 
in Ubuntu.
> > Is this the same on debian too? If yes, that looks like a bad idea 
to me.

>
> AFAIK, it uses the standard AUTOPKGTEST_TMP directory which is the
> standard across debian. I got the same impression on skimming through
> dh-golang code.
>
> As far as fix for your package is concerned, it is as simple as 
avoiding
> to remove entire data directory (which is just 28K in size). I'm 
able to get

> autopkgtests passing locally. Patch pasted
> inline.

Thanks. I guess I was over enthusiastic to suppress

I: golang-github-hhatto-gorst-dev: 
package-contains-documentation-outside-usr-share-doc 
[usr/share/gocode/src/github.com/hhatto/gorst/data/autopep8.readme.rst]


and did not notice the autopkgtest failure then.

I'm uploading the fix you suggested.

Bug#1030955: golang-github-hhatto-gorst: autopkgtest failure

[Pirate Praveen]

On Fri, 10 Feb 2023 00:07:51 +0200 Adrian Bunk  wrote:
> The Ubuntu diff contains a patch that looks like a workaround 
(untested).


This patch says data directory is reserved for golang autopkgtest in 
Ubuntu. Is this the same on debian too? If yes, that looks like a bad 
idea to me.

Bug#1034565: fixed in 0.23

[Pirate Praveen]

Control: fixed -1 0.23.1-3

Bug#1034565: ftbfs tests fail on ppc64el and mips64el

[Pirate Praveen]

On Tue, 18 Apr 2023 17:08:34 +0530 Pirate Praveen  
wrote:

> Failures:
>
>1) Prometheus::Client::Helper::MmapedFile file does not exist 
creates

> a file with minimum initial size
>   Failure/Error: expect(File.size(subject.filepath)).to
> eq(subject.send(:initial_mmap_file_size))
>
> expected: 4096
>  got: 16384
>
> (compared using ==)
>   # ./spec/prometheus/client/helpers/mmaped_file_spec.rb:30:in
> `block (3 levels) in '

Fixed upstream in 0.20 and 0.23 is being uploaded to experimental. We 
can close this once we confirm the failures are fixed.

Bug#1039916: ruby-derailed-benchmarks: autopkgtest needs update for new version of ruby-memory-profiler: Could not find 'memory_profiler' (~> 0)

[Pirate Praveen]

On Thu, 29 Jun 2023 16:03:13 +0200 Paul Gevers  
wrote:


> 
┌──┐

>   19s │ Checking Rubygems dependency resolution on ruby3.1
>  │
>   19s
> 
└──┘

>   19s  19s GEM_PATH= ruby3.1 -e gem\ \"derailed_benchmarks\"
>   19s /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in
> `rescue in block in activate_dependencies': Could not find
> 'memory_profiler' (~> 0) among 102 total gem(s) 
(Gem::MissingSpecError)

>   19s Checked in

This is fixed upstream but the new upstream version adds a new 
dependency dead_end gem. Also gitlab has moved this dependency from 
production to test group in Gemfile, so we can remove this once the 
dependency is dropped from gitlab.

Bug#1033705: golang-gitaly-proto: autopkgtest regression: test dependency ruby-gitaly-proto doesn't exist

[Pirate Praveen]

On Thu, 30 Mar 2023 19:19:44 +0200 Paul Gevers  
wrote:

> autopkgtest [15:18:15]: test command1: preparing testbed
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Correcting dependencies...Starting pkgProblemResolver with broken 
count: 1

> Starting 2 pkgProblemResolver with broken count: 1
> Investigating (0) autopkgtest-satdep:amd64 < 0 @iU K Nb Ib >
> Broken autopkgtest-satdep:amd64 Depends on ruby-gitaly-proto:amd64 <
> none @un H >
>Removing autopkgtest-satdep:amd64 because I can't find
> ruby-gitaly-proto:amd64

ruby-gitaly-proto used to be provided by ruby-gitaly binary package 
built from this source package. But ruby-gitaly binary package is now 
built from gitaly source package which does not provide 
ruby-gitaly-proto.


This was originally packaged as a dependency of gitlab-shell, which no 
longer need golang-gitaly-proto-dev build dependency.


So we can remove this package. I will file an rm request once the build 
dependency is removed from gitlab-shell in unstable.

Bug#1039915: ruby-benchmark-memory: autopkgtest needs update for new version of ruby-memory-profiler: Could not find 'memory_profiler' (~> 0.9)

[Pirate Praveen]

Control: fixed -1 0.2.0-1

On Thu, 29 Jun 2023 16:01:57 +0200 Paul Gevers  
wrote:

> Currently this regression is blocking the migration of
> ruby-memory-profiler to testing [1]. Of course, ruby-memory-profiler
> shouldn't just break your autopkgtest (or even worse, your package), 
but
> it seems to me that the change in ruby-memory-profiler was intended 
and

> your package needs to update to the new situation.

ruby-benchmark-memory 0.2.0-1 was ready in experimental, but missed a 
reupload to unstable. I'm reuploading it to unstable now.

Bug#1040405: ruby-gollum-lib: incompatible with newer ruby-rouge

[Pirate Praveen]

On Wed, 5 Jul 2023 16:44:31 +0200 Gianfranco Costamagna 
 wrote:

> Can you please have a look?

We no longer need ruby-gollum-lib for gitaly, so requested removal of 
ruby-gollum-lib in #1040461.

Bug#1039950: LoadError: cannot load such file -- spamcheck/spamcheck_pb

[Praveen Arimbrathodiyil]

Package: ruby-spamcheck
version: 1.10.1-1
severity: grave
Control: tags -1 help

When trying to install gitlab 15.11.6 (still in progress in salsa) it 
fails with


LoadError: cannot load such file -- spamcheck/spamcheck_pb

We need to build spamcheck_pb.rb using 
https://gitlab.com/gitlab-org/gl-security/security-engineering/security-automation/spam/spamcheck/-/blob/main/Makefile#L26


gitaly rules file has an example of how this is done for ruby-gitaly.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037409: golang-golang-x-exp ftbfs with gccgo-go (both gccgo-12 and gccgo-13)

[Pirate Praveen]

Package: src:golang-golang-x-exp
Version: 0.0~git20221028.83b7d23-2
Severity: serious

Building with golang-any changed to gccgo-go to force gccgo on amd64, 
build fails with error. Full build log attached. Either this should be 
fixed or dependency should be updated to golang-go instead of golang-any.


golang.org/x/exp/maps
# golang.org/x/exp/maps
src/golang.org/x/exp/maps/maps.go:10:10: error: expected ‘(’
   10 | func Keys[M ~map[K]V, K comparable, V any](m M) []K {
  |  ^
src/golang.org/x/exp/maps/maps.go:10:13: error: invalid character 0x7e 
in input file

   10 | func Keys[M ~map[K]V, K comparable, V any](m M) []K {
  | ^
src/golang.org/x/exp/maps/maps.go:11:9: error: expected ‘]’
   11 | r := make([]K, 0, len(m))
  | ^
src/golang.org/x/exp/maps/maps.go:11:9: error: expected ‘;’ or newline 
after top level declaration

src/golang.org/x/exp/maps/maps.go:12:9: error: expected declaration
   12 | for k := range m {
  | ^
src/golang.org/x/exp/maps/maps.go:14:9: error: expected declaration
   14 | }
  | ^
src/golang.org/x/exp/maps/maps.go:15:9: error: expected declaration
   15 | return r
  | ^
src/golang.org/x/exp/maps/maps.go:16:1: error: expected declaration
   16 | }
  | ^
sbuild (Debian sbuild) 0.85.2 (11 March 2023) on mahishi

+===+
| golang-golang-x-exp 0.0~git20221028.83b7d23-2 (amd64) Mon, 12 Jun 2023 
12:47:20 + |
+===+

Package: golang-golang-x-exp
Version: 0.0~git20221028.83b7d23-2
Source Version: 0.0~git20221028.83b7d23-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-24a3fad7-52f9-45d5-ba4b-67774cece214'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/golang-golang-x-exp-PqPMEI/resolver-ugb2fS' with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://deb.debian.org/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/pravi/forge/go-team/golang-golang-x-exp_0.0~git20221028.83b7d23-2.dsc 
exists in /home/pravi/forge/go-team; copying to chroot
I: NOTICE: Log filtering will replace 
'build/golang-golang-x-exp-PqPMEI/golang-golang-x-exp-0.0~git20221028.83b7d23' 
with '<>'
I: NOTICE: Log filtering will replace 'build/golang-golang-x-exp-PqPMEI' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 13), dh-sequence-golang, gccgo-go (>= 
2:1.18~), gccgo-13, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 13), dh-sequence-golang, gccgo-go 
(>= 2:1.18~), gccgo-13, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [609 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [670 B]
Get:5 copy:/<>/apt_archive ./ Packages [702 B]
Fetched 1981 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  autoconf automake autopoint autotools-dev bsdextrautils cpp-13 debhelper
  dh-autoreconf dh-golang dh-strip-nondeterminism dwz file gcc-13 gccgo-12
  gccgo-13 gccgo-go gettext gettext-base groff-base intltool-debian
  libarchive-zip-perl libdebhelper-perl libelf1
  libfile-stripnondeterminism-perl libgcc-13-dev libgo-12-dev libgo-13-dev
  libgo21 libgo22 libhwasan0 libicu72 libmagic-mgc libmagic1 libpipeline1
  libsub-override-perl libtool libuchardet0 libxml2 m4 man-db po-debconf
  sensible-utils
Suggested packages:
  autoconf-archive 

Bug#1021583: golang-gitlab-gitlab-org-labkit: FTBFS (test failure): gitlab.com/gitlab-org/labkit/metrics/http_round_tripper

[Pirate Praveen]

Control: fixed -1 1.17.0-1

On Tue, 11 Oct 2022 13:24:32 +0200 Cyril Brulebois  
wrote:

> Source: golang-gitlab-gitlab-org-labkit
> Version: 1.16.0-1
> Severity: serious
> Justification: FTBFS
>
> Hi,
>
> While preparing an update for the golang-github-gin-gonic-gin 
package,

> I noticed golang-gitlab-gitlab-org-labkit FTBFSes within unstable
> (with or without the updated golang-github-gin-gonic-gin package).
>

1.17.0-1 in experimental builds fine. I'm reuploading it to unstable.

Bug#1034996: libomemo0: missing Breaks+Replaces for libomemo-dev when upgrading from bullseye

[Pirate Praveen]

On Thu, 27 Apr 2023 14:59:11 +0200 Helmut Grohne  
wrote:

> Package: libomemo0
> Version: 0.8.1-1
> Severity: serious
> Justification: dpkg unpack error
>
> Attempting to unpack libomemo0/0.8.1-1 from Debian bookworm
> on a minimal Debian bullseye with libomemo-dev/0.7.0-1
> installed, causes an unpack error from dpkg due to
> /usr/lib/x86_64-linux-gnu/libomemo.so being contained in both 
packages.

>
> | (Reading database ... 12426 files and directories currently 
installed.)

> | Preparing to unpack ./libomemo0_0.8.1-1_amd64.deb ...
> | Unpacking libomemo0:amd64 (0.8.1-1) over (0.7.0-1) ...
> | dpkg: error processing archive ./libomemo0_0.8.1-1_amd64.deb 
(--unpack):
> |  trying to overwrite '/usr/lib/x86_64-linux-gnu/libomemo.so', 
which is also in package libomemo-dev:amd64 0.7.0-1

> | Processing triggers for libc-bin (2.31-13+deb11u5) ...
> | Errors were encountered while processing:
> |  ./libomemo0_0.8.1-1_amd64.deb
>
>
> Please ensure that libomemo0 has sufficient Breaks and Replaces 
declarations.

>
> Helmut
>
>

I could add the Breaks and Replaces, but looks like moving .so link out 
of -dev package is wrong as per lintian warning.


W: libomemo0: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libomemo.so 
[usr/lib/x86_64-linux-gnu/libomemo.so.0.8.1]
W: libomemo0: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libomemo.so.0.8.1 
[usr/lib/x86_64-linux-gnu/libomemo.so]


This was moved to libomemo-dev in commit 
6ebca2f07eed072226503432b6149e671341f2c4 Should we move back 
libomemo.so to libomemo-dev ?

Bug#1034565: ftbfs tests fail on ppc64el and mips64el

[Pirate Praveen]

Package: ruby-prometheus-client-mmap
Version: 0.17.0+spec-1
Severity: serious
Control: forwarded -1 
https://gitlab.com/gitlab-org/ruby/gems/prometheus-client-mmap/-/issues/43


Version in testing is not affected as we did not have tests enabled.

Failures:

  1) Prometheus::Client::Helper::MmapedFile file does not exist creates 
a file with minimum initial size
 Failure/Error: expect(File.size(subject.filepath)).to 
eq(subject.send(:initial_mmap_file_size))


   expected: 4096
got: 16384

   (compared using ==)
 # ./spec/prometheus/client/helpers/mmaped_file_spec.rb:30:in 
`block (3 levels) in '


  2) Prometheus::Client::MmapedDict#initialize empty mmap'ed file is 
initialized with correct size
 Failure/Error: expect(File.size(tmp_file.path)).to 
eq(tmp_mmaped_file.send(:initial_mmap_file_size))


   expected: 4096
got: 16384

   (compared using ==)
 # ./spec/prometheus/client/mmaped_dict_spec.rb:19:in `block (4 
levels) in '


  3) Prometheus::Client::MmapedDict#initialize mmap'ed file that is 
above minimum size is initialized with the a page size

 Failure/Error: expect(tmp_file.size).to eq(4096);

   expected: 4096
got: 16384

   (compared using ==)
 # ./spec/prometheus/client/mmaped_dict_spec.rb:34:in `block (4 
levels) in '


Full build logs 
https://buildd.debian.org/status/fetch.php?pkg=ruby-prometheus-client-mmap=ppc64el=0.19.1-1=1681745611=0 
https://buildd.debian.org/status/fetch.php?pkg=ruby-prometheus-client-mmap=mips64el=0.19.1-1=1681745649=0


Forwarded upstream at 
https://gitlab.com/gitlab-org/ruby/gems/prometheus-client-mmap/-/issues/43


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034230: fail2ban: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Pirate Praveen]

Control: tags -1 patch

On Tue, 11 Apr 2023 15:43:51 +0200 Andreas Henriksson 
 wrote:

> Wrong path is used at:
> https://sources.debian.org/src/fail2ban/1.0.2-1/debian/rules/#L50
>
> Note that the path will likely change again in the future, so rather
> than hard-coding a path please consider finding the path via:
> pkg-config --variable=systemdsystemunitdir systemd
>
> (Note: you'll need to build-dep on pkg-config and systemd, for
> systemd.pc)
>
> Regards,
> Andreas Henriksson
>
>

Attaching a patch, the git repo seems to be in an inconsistent 
state/diverged from the archive.


diff --git a/debian/control b/debian/control
index fe386199..0b8c5421 100644
--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,8 @@ Build-Depends:
  , python3-pyinotify
  , sqlite3
  , 2to3
+ , pkg-config
+ , systemd
 Homepage: https://www.fail2ban.org
 Vcs-Git: https://salsa.debian.org/python-team/packages/fail2ban.git
 Vcs-Browser: https://salsa.debian.org/python-team/packages/fail2ban
diff --git a/debian/rules b/debian/rules
index a2dd769c..3c0391ef 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,7 +16,7 @@ export PYBUILD_DISABLE_python2=1
 
 DESTDIR=$(CURDIR)/debian/fail2ban
 PYVERSION=$(shell py3versions -dv)
-
+SYSTEMD_SYSTEM_UNIT_DIR = $(shell pkg-config --variable=systemdsystemunitdir systemd)
 override_dh_clean:
 	rm -rf fail2ban.egg-info
 	-rm debian/fail2ban.init
@@ -45,11 +45,11 @@ override_dh_install:
 	install -d $(DESTDIR)/usr/share/bash-completion/completions
 	install -m 644 files/bash-completion $(DESTDIR)/usr/share/bash-completion/completions/fail2ban
 	: # Install systemd files
-	install -d $(DESTDIR)/usr/lib/systemd/system/
+	install -d $(DESTDIR)$(SYSTEMD_SYSTEM_UNIT_DIR)
 	install -d $(DESTDIR)/usr/lib/tmpfiles.d
-	install -m 644 build/fail2ban.service $(DESTDIR)/usr/lib/systemd/system
+	install -m 644 build/fail2ban.service $(DESTDIR)$(SYSTEMD_SYSTEM_UNIT_DIR)
 	install -m 644 files/fail2ban-tmpfiles.conf $(DESTDIR)/usr/lib/tmpfiles.d
-	install -d $(DESTDIR)/usr/lib/systemd/system
+	install -d $(DESTDIR)$(SYSTEMD_SYSTEM_UNIT_DIR)
 	: # Install default jail enabler
 	install -m 644 debian/debian-files/jail.d_defaults-debian.conf $(DESTDIR)/etc/fail2ban/jail.d/defaults-debian.conf
 	dh_install

Bug#1031716: Generating stricter dependencies on python3-protobuf rdeps

[Pirate Praveen]

On Tue, 7 Mar 2023 12:09:35 +0200 Adrian Bunk  wrote:
> 2. packages using python3-protobuf (e.g. python3-bernhard) ship files
>that were generated with protobuf-compiler during their build
>(e.g. /usr/lib/python3/dist-packages/bernhard/pb.py )

Can this generation be moved to postinst and use a dpkg trigger to 
regenerate it when protobuf is updated?


An example is 
https://sources.debian.org/src/node-constants-browserify/1.0.0%2Bdfsg-8/debian/postinst/


Though it would mean runtime dependency on protobuf-compiler.

Bug#999726: ruby-omniauth-shibboleth: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: Failure/Error: expect(last_response.status).to eq(302)

[Pirate Praveen]

On Tue, 10 May 2022 01:14:01 +0530 Mohd Bilal  
wrote:

> If you feel there's any other
> workaround for this please suggest. The upstream hasn't been active 
and

> I dont think they'll have new version anytime soon

as discussed in 
https://git.fosscommunity.in/debian-ruby/TaskTracker/-/issues/192#note_9797 
we can remove dependency on omniauth-shibboleth from gitlab and request 
removal from archive.


Removing the dependency here 
https://salsa.debian.org/ruby-team/gitlab/-/commit/a7773b9ac08a3c341982129c201d3a254f4561cb


I will file ROM shortly.

Bug#1019643: ruby-omniauth-oauth2-generic: FTBFS with ruby3.1: ERROR: Test "ruby3.0" failed: Failure/Error: expect(last_response.headers["Location"]).to match(%r{redirect_uri=https%3A%2F%2Fmy_se

[Pirate Praveen]

Control: forwarded -1 
https://gitlab.com/satorix/omniauth-oauth2-generic/-/issues/37


On Mon, 12 Sep 2022 22:08:30 -0300 Antonio Terceiro 
 wrote:
> We are about to start the ruby3.1 transition in unstable. While 
trying to

> rebuild ruby-omniauth-oauth2-generic with ruby3.1 enabled, the build
> failed. This does not look related to ruby3.1 though, as the failure
> happens yet at the ruby3.0 tests.

This looks like a test only failure as gitlab confirmed everything 
works with ruby 3.0 here 
https://gitlab.com/gitlab-org/gitlab/-/issues/386908


The upstream seems inactive though, still reported as 
https://gitlab.com/satorix/omniauth-oauth2-generic/-/issues/37

Bug#980316: Update on packaging corepack

[Pirate Praveen]

On Tue, Mar 21 2023 at 09:06:41 PM +01:00:00 +01:00:00, Paul Gevers 
 wrote:

Hi Pirate,

Thanks for reaching out.

On 20-03-2023 16:44, Pirate Praveen wrote:

I request bookworm-ignore tags for these bugs (as such there is
no immediate breakage, just unmaintained upstreams for these 
packages).


> yarnpkg: 980316,958686, 1002902, 980316
> node-har-validator: 1024575
> node-request: 956423
> node-request-capture-har: 1002901

As the packages in question are key packages, we can't easily remove
them. Hence adding a bookworm-ignore tag doesn't really change the
situation in bookworm in any way. Hence, the question is whether 
fixing

it now and adding an exception is better or worse than letting the bug
ship in bookworm. If I understand correctly, than the required change
would mean a new complex package (corepack) which (again, if I
understand correctly) is considered also by you as inappropriate at 
this

time. If you confirm my understanding, I agree that those bugs can be
marked bookworm-ignore (I already marked them as bookworm-can-defer,
which is less strong and less official).


We won't be able to complete corepack in a few weeks or months. So we 
have to ship bookworm with these bugs and get this fixed in time for 
trixie.




Paul

Bug#980316: Update on packaging corepack

[Pirate Praveen]

On Thu, 16 Mar 2023 10:23:53 +0100 Israel Galadima 
 wrote:

> Hi,
>
> Michael and I have done some packaging work for corepack.
> Of note, we have updated clipanion and packaged some dependencies of
> proxy-agent.
>
> Although, some of our work is awaiting uploads because of the freeze.
>
> Regards.

We tried to update yarnpkg as part of an outreachy project (in two 
rounds), but we could not complete it in time for bookworm. As shared 
by Israel, we made some good progress and we hope to be able to do it 
in trixie. I request bookworm-ignore tags for these bugs (as such there 
is no immediate breakage, just unmaintained upstreams for these 
packages). Hopefully we can handle any security updates ourselves.


Additionally, even though yarnpkg itself is old, the presence of the 
package makes it easy to obtain a newer yarnpkg. In gitlab, I already 
use the packaged yarnpkg command to install a newer yarnpkg[1]. It is 
also very common in nodejs world to use specific version of yarnpkg for 
each project, these are typically installed in .yarn directory for each 
project.


yarnpkg: 980316,958686, 1002902, 980316
node-har-validator: 1024575
node-request: 956423
node-request-capture-har: 1002901

[1] 
https://salsa.debian.org/ruby-team/gitlab/-/blob/master/debian/rake-tasks.sh#L44

runuser -u ${gitlab_user} -- sh -c 'yarnpkg set version berry'

Bug#1029851: marked as pending in ruby-globalid

[Praveen Arimbrathodiyil]

Control: tag -1 pending

Hello,

Bug #1029851 in ruby-globalid reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-globalid/-/commit/c3eff264772d745dbce5bab8ca88112ab2107699


Fix CVE-2023-22799 (Closes: #1029851)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1029851

Bug#1029851: marked as pending in ruby-globalid

[Praveen Arimbrathodiyil]

Control: tag -1 pending

Hello,

Bug #1029851 in ruby-globalid reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-globalid/-/commit/c3eff264772d745dbce5bab8ca88112ab2107699


Fix CVE-2023-22799 (Closes: #1029851)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1029851

Bug#1031441: Potential RM candidate ?

[Pirate Praveen]

On Mon, 13 Mar 2023 23:17:02 +0530 Mohd Bilal  
wrote:

> Hello,
>
> The upstream[1] for ruby-github-api has been inactive for over 2 
years

> now and this is affecting other packages like ruby-oauth2[2] and
> ruby-faraday[3] from migrating.
>
> $ reverse-depends -b ruby-github-api
> Reverse-Build-Depends
> * ruby-jeweler
>
> $ reverse-depends -b ruby-jeweler
> No reverse dependencies found
>
> So should we remove these 2 packages ? or as a workaround we could 
relax
> the versions in Gemfile to actually fix this bug since the Debian 
source

> doesn't ship the upstream test suite.

I think we can remove these two packages.

Bug#1032048: d3-dsv-tools: Dangling symlinks in /usr/bin/

[Pirate Praveen]

On Mon, 27 Feb 2023 00:51:52 +0100 Axel Beckert  wrote:
> Package: d3-dsv-tools
> Version: 1.1.1-8
> Severity: grave
> Justification: renders package unusable
>
> $ symlinks -tv /usr/bin* | fgrep dangling
> dangling: /usr/bin/csv2json -> ../share/nodejs/d3-dsv/bin/dsv2json.js
> dangling: /usr/bin/csv2tsv -> ../share/nodejs/d3-dsv/bin/dsv2dsv.js
> dangling: /usr/bin/dsv2dsv -> ../share/nodejs/d3-dsv/bin/dsv2dsv.js
> dangling: /usr/bin/json2csv -> ../share/nodejs/d3-dsv/bin/json2dsv.js
> dangling: /usr/bin/json2dsv -> ../share/nodejs/d3-dsv/bin/json2dsv.js
> dangling: /usr/bin/tsv2csv -> ../share/nodejs/d3-dsv/bin/dsv2dsv.js
> dangling: /usr/bin/json2tsv -> ../share/nodejs/d3-dsv/bin/json2dsv.js
> dangling: /usr/bin/dsv2json -> ../share/nodejs/d3-dsv/bin/dsv2json.js
> dangling: /usr/bin/tsv2json -> ../share/nodejs/d3-dsv/bin/dsv2json.js
>
> Looking at where those files actually might be, I figured that the
> symlinks probably should point to the same target without the .js
> suffix — or that those files need to be renamed:
>
> /usr/share/nodejs/d3-dsv/bin/dsv2dsv
> /usr/share/nodejs/d3-dsv/bin/dsv2json
> /usr/share/nodejs/d3-dsv/bin/json2dsv

debian/nodejs/links should be modified to drop the .js suffix.



since master branch is used for experimental, a new branch for bookworm 
should be created from debian/1.1.1-8 tag


> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (600, 'testing')
> merged-usr: yes
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not 
set

> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> LSM: AppArmor: enabled
>
> Versions of packages d3-dsv-tools depends on:
> ii  node-d3-dsv  1.1.1-8
> ii  nodejs   18.13.0+dfsg1-1
>
> d3-dsv-tools recommends no packages.
>
> d3-dsv-tools suggests no packages.
>
> -- no debconf information
>
>

Bug#1029523: ruby-net-http-persistent want Ruby (~> 2.1)

[Pirate Praveen]

Control: severity -1 important

On Thu, 23 Feb 2023 21:33:31 +0100 Paul Gevers  
wrote:

> Hi,
>
> On Tue, 24 Jan 2023 00:21:06 +0530 Pirate Praveen
>  wrote:
> >   net-http-persistent (~> 3.0, >= 3.0.0) was resolved to 3.1.0,
> > which depends on
> > Ruby (~> 2.1)
>
> This doesn't seem to be an issue on reproducible builds [1] when
> building ruby-faraday. Does that make sense?

Only bundler or rubygems checks this dependency requirement. It might 
just work fine on ruby 3.1. For now the easiest fix was to update to 
4.0 (for gitlab, where this bug appeared - in gitlab postinst, we use 
bundle install --local to verify all dependency requirements are 
satisfied), in which upstream has removed this constraint. May be we 
can ignore it for now (lowered the severity, as gitlab is not in 
bookworm).

Bug#1016732: [Pkg-javascript-devel] Bug#1016732: Please help to reproduce (Was: shiny-server: server-function? don't run)

[Pirate Praveen]

On ഞാ, ഫെബ്രു 26 2023 at 02:33:31 രാവിലെ 
+05:30:00 +05:30:00, Pirate Praveen  wrote:



On ഞാ, ഫെബ്രു 26 2023 at 02:24:00 രാവിലെ 
+05:30:00 +05:30:00, Nilesh Patra  wrote:

On Sun, Feb 26, 2023 at 12:46:15AM +0530, Pirate Praveen wrote:
Thanks for the pointer. However, unfortunately even after propagating
the "-t" flag with coffee, the generated code does not work to fine 
(the

UI is not functional).

For now I have vendored coffee1 generated code itself. Do you have 
any

other ideas?


I can see we are using rollup to generate iife format files, which 
may not be what npm dist tarball ships.


https://salsa.debian.org/js-team/node-sockjs/-/blob/master/debian/rules#L8

Upstream directly uses the output from coffee 
https://salsa.debian.org/js-team/node-sockjs/-/blob/master/Makefile#L9


You could play around with rollup output format options I think. Try 
umd format or try using webpack. You will have to inspect the npm 
dist tarball to see what format it has. Copying Akshay if he has some 
ideas.


Since we are using only lib directory in node, ignore the rollup part 
above. In sockjs 0.4 rc1 they removed coffee script dependency, so one 
thing we can try is to see if sockjs 0.4 rc1 works with shiny-server, 
though getting a new upstream version to bookworm may be a hard thing, 
but it may be a better option that vendoring what we have right now.

Bug#1016732: Please help to reproduce (Was: shiny-server: server-function? don't run)

[Pirate Praveen]

On ഞാ, ഫെബ്രു 26 2023 at 02:24:00 രാവിലെ 
+05:30:00 +05:30:00, Nilesh Patra  wrote:

On Sun, Feb 26, 2023 at 12:46:15AM +0530, Pirate Praveen wrote:
Thanks for the pointer. However, unfortunately even after propagating
the "-t" flag with coffee, the generated code does not work to fine 
(the

UI is not functional).

For now I have vendored coffee1 generated code itself. Do you have any
other ideas?


I can see we are using rollup to generate iife format files, which may 
not be what npm dist tarball ships.


https://salsa.debian.org/js-team/node-sockjs/-/blob/master/debian/rules#L8

Upstream directly uses the output from coffee 
https://salsa.debian.org/js-team/node-sockjs/-/blob/master/Makefile#L9


You could play around with rollup output format options I think. Try 
umd format or try using webpack. You will have to inspect the npm dist 
tarball to see what format it has. Copying Akshay if he has some ideas.

Bug#1016732: Please help to reproduce (Was: shiny-server: server-function don't run)

[Pirate Praveen]

On Sun, 12 Feb 2023 23:16:06 +0530 Nilesh Patra  
wrote:
> Sorry for pinging you again, but would you be able to take a look at 
this please?

> I don't know enough coffeescript to be able to check this and it'd be
> awesome if you could consider taking a look.

Coffeescript 2 creates ESM format js by default, adding -t option to 
coffee command should give you the old ES5 javascript like coffeescript 
1.x


See 
https://salsa.debian.org/js-team/node-sockjs/-/blob/master/Makefile#L11

Bug#1030873: ruby-coffee-script is deprecated, please remove the dependency

[Pirate Praveen]

Package: ruby-jekyll-coffeescript
Version: 1.2.2-3
severity: serious
Control: block 1019927 by -1

ruby-coffee-script is deprecated #1019927 and we are trying to remove 
it from bookworm.


coffee command line provided by coffeescript package still works (and 
using node version via webpack is recommended by rails), so using that 
could be an option, or alternatively if ruby-coffee-script is still 
useful, someone will need to take over the upstream maintenance.

Bug#1030870: Drop unneeded dependency on ruby-coffee-script

[Pirate Praveen]

Package: tdiary-core
Version: 5.2.3-1
Severity: serious
Justification: ruby-coffee-script is deprecated and we want to remove 
it in bookworm

Control: block 1019927 by -1

ruby-coffee-script is deprecated (#1019927) and we'd like to remove it 
from bookworm (this and ruby-jekyll-coffeescript are the lats two 
packages still depending on ruby-coffee-script).


It looks 
https://salsa.debian.org/ruby-team/tdiary/-/blob/master/tdiary.gemspec 
does not list ruby-coffee-script, so it should be easy to drop it from 
Depends.


If you really want to use coffeescript in this package, you can still 
use the coffee command line (which also supports -t option to generate 
ES5 output, which is no longer the default in coffeescript 2).

Bug#1019927: Remove ruby-coffee-script - deprecated upstream

[Pirate Praveen]

On Fri, 16 Sep 2022 16:38:52 +0530 Pirate Praveen 
 wrote:
> As per upstream [1], this project is deprecated and last release was 
on
>  Apr 7, 2015 (7 years ago), so I think we should try to remove it 
from

> bookworm, but if we can't get there close to freeze, we can ask for
> bookworm-ignore or lower severity.

Current list of dependencies (with dependencies removed from ruby-blade 
and ruby-hamlit):

Reverse-Depends
===
* ruby-jekyll-coffeescript
* tdiary-core

Reverse-Build-Depends
=
* ruby-sprockets

Bug#1019924: Remove build dependency on ruby-blade

[Pirate Praveen]

Control: rettile -1 remove ruby-coffee-script* dependencies
Control: reassign -1 src:ruby-blade

On Fri, 16 Sep 2022 16:13:41 +0530 Pirate Praveen 
 wrote:

> Package: src:rails
> Version: 2:6.1.7+dfsg-1
> Severity: important
> Control: forwarded -1 https://github.com/rails/rails/pull/45546
>
> ruby-blade depends on now deprecated ruby-coffee-script and rails is
> only reverse build dependency of ruby-blade. Upstream has already 
moved

> to rollup, filing this to track progress of ruby-blade removal.

An alternate solution here is to drop ruby-coffee-script and 
ruby-coffee-script-source dependencies from ruby-blade as rails 
switched to using coffee commandline (provided by coffeescript/node 
package).

Bug#1005628: add fixed version info

[Pirate Praveen]

Control: fixed -1 5.2.0+dfsg-2

Bug#981878: ruby-gitlab-pg-query downloads from the internet during the build

[Pirate Praveen]

On Tue, 22 Feb 2022 21:16:22 +0100 Paul Gevers  
wrote:

> Hi Pirate,
>
> On Sun, 07 Mar 2021 00:47:46 +0530 Pirate Praveen
>  wrote:
> > Once ruby-pg-query is accepted
> > and its reverse dependencies switch to the new package, I will 
request

> > removal of this package.
>
> What's the status on this?

ruby-gitlab-pg-query can be removed now. ruby team will soon file RM 
requests for packages we don't want to keep in the archives. 
https://lists.debian.org/debian-ruby/2023/02/msg00010.html has the list.


> Paul
> PS: please CC, I'm not subscribed

Bug#1019927: Remove ruby-coffee-script - deprecated upstream

[Pirate Praveen]

May be with rails 7.1, we may be able to remove coffee_script
https://github.com/rails/rails/issues/46292#issuecomment-1332882941

Bug#1029523: there is a new upstream major version that relaxes ruby requirement

[Pirate Praveen]

so updating to 4.0.1 could fix this
https://github.com/drbrain/net-http-persistent/blob/75574f2546a08aa2663b06a2e005bcf2ee304f13/Rakefile#L16

Bug#1029523: ruby-net-http-persistent want Ruby (~> 2.1)

[Pirate Praveen]

Package: ruby-net-http-persistent
Severity: grave
Justification: unable to install gitlab or use with bundler

Just add this to Gemfile.
gem "telesign"

and run,
bundle install --local
Don't run Bundler as root. Bundler can ask for sudo if it is needed, 
and installing your bundle as root will

break this application for all non-root users on this machine.
[DEPRECATED] This Gemfile does not include an explicit global source. 
Not using an explicit global source may result in a different lockfile 
being generated depending on the gems you have installed locally before 
bundler is run. Instead, define a global source in your Gemfile like 
this: source "https://rubygems.org;.

Resolving dependencies...
Bundler found conflicting requirements for the Ruby version:
 In Gemfile:
   Ruby

   telesign was resolved to 2.2.3, which depends on
 net-http-persistent (~> 3.0, >= 3.0.0) was resolved to 3.1.0, 
which depends on

   Ruby (~> 2.1)


This comes from the gemspec
https://salsa.debian.org/ruby-team/ruby-net-http-persistent/-/blob/master/net-http-persistent.gemspec#L23

Bug#1029459: hp-plugin crashes when trying to download plugin with error NameError: name 'get_distro_std_name' is not defined. Did you mean: 'get_distro_name'?

[Pirate Praveen]

Control: severity -1 important

On Mon, Jan 23 2023 at 04:57:16 PM +00:00:00 +00:00:00, Brian Potkin 
 wrote:

On Mon 23 Jan 2023 at 01:39:46 +0530, Pirate Praveen wrote:


 Package: hplip
 Version: 3.22.10+dfsg0-1
 Severity: grave
 Justification: makes it unusable

 $ hp-plugin

 HP Linux Imaging and Printing System (ver. 3.22.10)
 Plugin Download and Install Utility ver. 2.1

 Copyright (c) 2001-18 HP Development Company, LP
 This software comes with ABSOLUTELY NO WARRANTY.
 This is free software, and you are welcome to distribute it
 under certain conditions. See COPYING file for more details.


 HP Linux Imaging and Printing System (ver. 3.22.10)
 Plugin Download and Install Utility ver. 2.1

 Copyright (c) 2001-18 HP Development Company, LP
 This software comes with ABSOLUTELY NO WARRANTY.
 This is free software, and you are welcome to distribute it
 under certain conditions. See COPYING file for more details.

 QSocketNotifier: Can only be used with threads started with QThread
 Checking for network connection...
 Downloading plug-in from:
 Traceback (most recent call last):
   File "/usr/share/hplip/ui5/plugindialog.py", line 248, in
 NextButton_clicked
 status, download_plugin_file, error_str =
 
self.pluginObj.download(self.plugin_path,self.plugin_download_callback)


 
^^^
   File "/usr/share/hplip/installer/pluginhandler.py", line 257, in 
download

 core = core_install.CoreInstall()
^^
   File "/usr/share/hplip/installer/core_install.py", line 240, in 
__init__

 self.passwordObj = password.Password(ui_mode)
^^
   File "/usr/share/hplip/base/password.py", line 94, in __init__
 self.__readAuthType()  # self.__authType
 ^
   File "/usr/share/hplip/base/password.py", line 119, in 
__readAuthType

 distro_name = get_distro_std_name(os_name)
   ^^^
 NameError: name 'get_distro_std_name' is not defined. Did you mean:
 'get_distro_name'?
 Aborted


Thank you for you report, Pirate Praveen.

My attempt with

  sh -i hplip-3.22.10-plugin.run

failed over an ssh link. This is an upstream issue.
get_distro_std_name is not used in hplip-3.22.6.
Please report at

  https://bugs.launchpad.net/hplip/+bugs



If you are already familiar with launchpad, can you file it?


I would query the severity of grave rather than
imortant. Plugin files can be installed with

  sh hplip--plugin.run --tar vxf
  python3 installPlugin.py



Lowered severity to important. Though we probably have to document it 
somewhere more visible until this is fixed.



Regards,

Brian.

Bug#964607: Massive update necessary

[Pirate Praveen]

On Thu, 25 Nov 2021 18:54:24 +0100 Daniel Leidert  
wrote:
> This gem is out-of-date. Upstream is at 3.2.2, which requires 
packaging for
> google-cloud-translate-v2 and google-cloud-translate-v3 and updating 
google-

> cloud-core to >= 1.6. The tests require packageing google-style.

This is a leaf package, likely packaged for loomio. I think we can 
ignore this for bookworm. May be we should use a usertag to mark such 
packages which can ignore rc bugs for bookworm (it could be useful in 
future if loomio packaging is revived, since upstream is still active, 
we can probably keep it in unstable).

Bug#1008468: marked as pending in ruby-jquery-atwho-rails

[Praveen Arimbrathodiyil]

Control: tag -1 pending

Hello,

Bug #1008468 in ruby-jquery-atwho-rails reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-jquery-atwho-rails/-/commit/d5a92ae76665588545aee0af4a93850431af8c91


Copy assets during build instead of symlink (Closes: #1008468)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1008468

Bug#1029459: manually editing the file fixes the issue

[Pirate Praveen]

after replacing get_distro_std_name(os_name) with get_distro_name() in 
/usr/share/hplip/base/password.py


the plugin got installed


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029459: after downloading the plugin manually and trying to install, it still fails

[Pirate Praveen]

Downloaded from 
https://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/


$ ./hplip-3.22.10-plugin.run
Verifying archive integrity...  100%   All good.
Uncompressing HPLIP 3.22.10 Plugin Self Extracting Archive  100%

HP Linux Imaging and Printing System (ver. 3.22.10)
Plugin Installer ver. 3.0

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Plug-in version: 3.22.10
Installed HPLIP version: 3.22.10
Number of files to install: 64

note: Using PyQt5
QSocketNotifier: Can only be used with threads started with QThread
Traceback (most recent call last):
  File "/tmp/selfgz92927/./plugin_install.py", line 276, in 
ok = installPlugin()
 ^^^
  File "/tmp/selfgz92927/./plugin_install.py", line 85, in installPlugin
passwordObj = password.Password(mode)
  ^^^
  File "/usr/share/hplip/base/password.py", line 94, in __init__
self.__readAuthType()  # self.__authType
^
  File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
distro_name = get_distro_std_name(os_name)
  ^^^
NameError: name 'get_distro_std_name' is not defined. Did you mean: 
'get_distro_name'?


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029459: hp-plugin crashes when trying to download plugin with error NameError: name 'get_distro_std_name' is not defined. Did you mean: 'get_distro_name'?

[Pirate Praveen]

Package: hplip
Version: 3.22.10+dfsg0-1
Severity: grave
Justification: makes it unusable

$ hp-plugin

HP Linux Imaging and Printing System (ver. 3.22.10)
Plugin Download and Install Utility ver. 2.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.


HP Linux Imaging and Printing System (ver. 3.22.10)
Plugin Download and Install Utility ver. 2.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

QSocketNotifier: Can only be used with threads started with QThread
Checking for network connection...
Downloading plug-in from:
Traceback (most recent call last):
  File "/usr/share/hplip/ui5/plugindialog.py", line 248, in 
NextButton_clicked
status, download_plugin_file, error_str = 
self.pluginObj.download(self.plugin_path,self.plugin_download_callback)


^^^
  File "/usr/share/hplip/installer/pluginhandler.py", line 257, in download
core = core_install.CoreInstall()
   ^^
  File "/usr/share/hplip/installer/core_install.py", line 240, in __init__
self.passwordObj = password.Password(ui_mode)
   ^^
  File "/usr/share/hplip/base/password.py", line 94, in __init__
self.__readAuthType()  # self.__authType
^
  File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
distro_name = get_distro_std_name(os_name)
  ^^^
NameError: name 'get_distro_std_name' is not defined. Did you mean: 
'get_distro_name'?

Aborted



OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020913: looks like a temporary issue during ruby 3.1 transition

[Pirate Praveen]

Control: fixed -1 2.2.0-1

likely caused by ruby-google-protobuf in experimental not being rebuilt 
with ruby 3.1. This built fine in buildd after ruby-google-protobuf was 
reuploaded to unstable.

Bug#1028730: fixed in last upload and built on buildd

[Pirate Praveen]

Control: fixed -1 1.7.0+dfsg-6

Bug#1005634: marked as pending in ruby-leaflet-rails

[Praveen Arimbrathodiyil]

Control: tag -1 pending

Hello,

Bug #1005634 in ruby-leaflet-rails reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-leaflet-rails/-/commit/b4c8407616018a3cec32852087f0c0c075d355cc


Copy assets instead of symlink (Closes: #1005634)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1005634

Bug#979955: marked as pending in ruby-rails-assets-jquery-fullscreen-plugin

[Praveen Arimbrathodiyil]

Control: tag -1 pending

Hello,

Bug #979955 in ruby-rails-assets-jquery-fullscreen-plugin reported by you has 
been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-rails-assets-jquery-fullscreen-plugin/-/commit/b607e78db32addb9abc59076b85a2f2aa5f8ed7c


Switch build dependency to uglifyjs (from node-uglify) (Closes: #979955)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/979955

Bug#1005631: new restriction in rubygems: installing symlink pointing to parent path not allowed - causes ruby-handlebars-assets to ftbfs

[Pirate Praveen]

On Fri, 03 Jun 2022 21:52:17 +0530 Pirate Praveen 
 wrote:

> May be we can copy during build and replace it by symlink in install?

This fixes the earlier issue, but now some tests fail

# Running:

..E.E..E

Finished in 18.138080s, 1.5437 runs/s, 2.4810 assertions/s.

 1) Error:
HandlebarsAssets::HamlbarsTest#test_render_haml:
ArgumentError: wrong number of arguments (given 2, expected 0..1)
   /usr/lib/ruby/vendor_ruby/temple/engine.rb:44:in `initialize'
   
/<>/lib/handlebars_assets/handlebars_template.rb:106:in 
`new'
   
/<>/lib/handlebars_assets/handlebars_template.rb:106:in 
`choose_engine'
   /<>/lib/handlebars_assets/handlebars_template.rb:26:in 
`prepare'

   /usr/lib/ruby/vendor_ruby/tilt/template.rb:99:in `initialize'
   /<>/test/handlebars_assets/hamlbars_test.rb:23:in `new'
   /<>/test/handlebars_assets/hamlbars_test.rb:23:in 
`test_render_haml'


 2) Error:
HandlebarsAssets::HandlebarsTemplateTest#test_multiple_frameworks_with_ember_render:
ArgumentError: wrong number of arguments (given 2, expected 0..1)
   /usr/lib/ruby/vendor_ruby/temple/engine.rb:44:in `initialize'
   
/<>/lib/handlebars_assets/handlebars_template.rb:106:in 
`new'
   
/<>/lib/handlebars_assets/handlebars_template.rb:106:in 
`choose_engine'
   /<>/lib/handlebars_assets/handlebars_template.rb:26:in 
`prepare'

   /usr/lib/ruby/vendor_ruby/tilt/template.rb:99:in `initialize'
   
/<>/test/handlebars_assets/tilt_handlebars_test.rb:14:in 
`new'
   
/<>/test/handlebars_assets/tilt_handlebars_test.rb:14:in 
`render_it'
   
/<>/test/handlebars_assets/shared/adapter_tests.rb:191:in 
`test_multiple_frameworks_with_ember_render'


 3) Error:
HandlebarsAssets::HandlebarsProcessorTest#test_multiple_frameworks_with_ember_render:
ArgumentError: wrong number of arguments (given 2, expected 0..1)
   /usr/lib/ruby/vendor_ruby/temple/engine.rb:44:in `initialize'
   
/<>/lib/handlebars_assets/handlebars_template.rb:106:in 
`new'
   
/<>/lib/handlebars_assets/handlebars_template.rb:106:in 
`choose_engine'
   /<>/lib/handlebars_assets/handlebars_template.rb:64:in 
`call'
   /<>/lib/handlebars_assets/handlebars_template.rb:49:in 
`call'
   
/<>/test/handlebars_assets/handlebars_processor_test.rb:14:in 
`render_it'
   
/<>/test/handlebars_assets/shared/adapter_tests.rb:191:in 
`test_multiple_frameworks_with_ember_render'


28 runs, 45 assertions, 0 failures, 3 errors, 0 skips
rake aborted!
Command failed with status (1)

Bug#1005631: marked as pending in ruby-handlebars-assets

[Praveen Arimbrathodiyil]

Control: tag -1 pending

Hello,

Bug #1005631 in ruby-handlebars-assets reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-handlebars-assets/-/commit/e639cd916a1a6c1a9aefa47fe95802ff821a307d


Copy assets instead of symlink and simplify rules (Closes: #1005631)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1005631

Bug#1005630: marked as pending in ruby-markdown-it-html5-embed

[Praveen Arimbrathodiyil]

Control: tag -1 pending

Hello,

Bug #1005630 in ruby-markdown-it-html5-embed reported by you has been fixed in 
the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-markdown-it-html5-embed/-/commit/0bdc052bb9cdb231b84c3c6fd867405201584f41


Copy system assets during build instead of symlink (Closes: #1005630)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1005630

Bug#979962: marked as pending in ruby-rails-assets-favico.js

[Praveen Arimbrathodiyil]

Control: tag -1 pending

Hello,

Bug #979962 in ruby-rails-assets-favico.js reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-rails-assets-favico.js/-/commit/5468315597885ca20b6bf18b94f44d5ac1fb880d


Drop obsolete build dependency on node-uglify (Closes: #979962)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/979962

Bug#979936: marked as pending in ruby-rails-assets-perfect-scrollbar

[Praveen Arimbrathodiyil]

Control: tag -1 pending

Hello,

Bug #979936 in ruby-rails-assets-perfect-scrollbar reported by you has been 
fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-rails-assets-perfect-scrollbar/-/commit/a28b608e1f6f77dc6a1ae87849bd5c6691d44129


Drop obsolete build dependency on node-uglify (Closes: #979936)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/979936

Bug#1028201: riseup-vpn unable to find a usable polkit agent under phosh

[Pirate Praveen]

Package: riseup-vpn,phosh
severity: grave

On mobian under phosh (librem 5), riseup-vpn gives error.
output of riseup-vpn attached.

phosh provides polkit-1-auth-agent

phosh 0.23
riseup-vpn 0.21.11+ds1-2+b1

No systray icon available.
qml: flavor: riseup-vpn
QSystemTrayIcon::setVisible: No Icon set
QObject::connect: No such signal QPlatformNativeInterface::systemTrayWindowChanged(QScreen*)
2023/01/08 18:44:03 Client expects anon auth
2023/01/08 18:44:03 Checking for updates...
qml: delay...
2023/01/08 18:44:14 Get "https://downloads.leap.se/RiseupVPN/linux/lastver": net/http: TLS handshake timeout
2023/01/08 18:44:14 Fetching MOTD for riseup.net
2023/01/08 18:44:16 There are 4 pending messages
2023/01/08 18:44:16 firewall stop
2023/01/08 18:44:17 Fetching gateways...
2023/01/08 18:44:17 Cannot find any usable polkit
2023/01/08 18:44:17 ERROR: no polkit
qml: errors, setting root.error
qrc:/components/InitErrors.qml:39: ReferenceError: splashSpinner is not defined
qrc:/components/InitErrors.qml:38:13: QML PropertyChanges: Cannot assign to non-existent property "visible"
qml: errors, setting root.error
qml: errors, setting root.error
2023/01/08 18:44:38 Close: cleanup and vpn shutdown...
2023/01/08 18:44:38 firewall stop
2023/01/08 18:44:38 openvpn stop

Catched signal(2): quitting

Bug#1024627: Acknowledgement (gitlab: Fails to install)

[Pirate Praveen]

On Tue, Nov 22 2022 at 02:39:40 PM +01:00:00 +01:00:00, Kurt Roeckx 
 wrote:
fasttrack contains a 1.7.3 version that's new enough. The 1.8.0 
version

from backports is too new it seems, and it what gets installed when
you just do: apt install gitlab



Some of the version requirements for omniauth-oauth2 is too strict, 
which should be fixed. But as a workaround, you can install 1.7.3 
version, till we fix this properly.

Bug#1021265: golang-github-libgit2-git2go ftbfs with libgit2 1.5

[Pirate Praveen]

Package: golang-github-libgit2-git2go
Version: 33.0.9-2
Severity: serious
Control: forwarded -1 https://github.com/libgit2/git2go/pull/929

This is also seen in autopkgtest failure 
https://ci.debian.net/data/autopkgtest/unstable/amd64/g/golang-github-libgit2-git2go/26651971/log.gz


Upstream recently merged https://github.com/libgit2/git2go/pull/929 and 
hopefully they will release a new version.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021113: libgrpc22 in experimental needs a rebuild with newer libabsl

[Pirate Praveen]

Package: libgrpc22
Severity: serious
Version: 1.44.0-3

Setting up sbuild-build-depends-dose3-dummy (0.invalid.0) ...
(I)Doseparse: Parsing and normalizing...
(I)Dose_deb: Parsing Packages file -...
(I)Dose_common: total packages 69949
(I)Dose_applications: Cudf Universe: 69949 packages
(I)Dose_applications: --checkonly specified, consider all packages as 
background packages

(I)Dose_applications: Solving...
output-version: 1.2
native-architecture: amd64
report:
-
 package: sbuild-build-depends-main-dummy
 version: 0.invalid.0
 architecture: amd64
 status: broken
 reasons:
  -
   missing:
pkg:
 package: libgrpc22
 version: 1.44.0-3
 architecture: amd64
 unsat-dependency: libabsl20210324:amd64 (>= 0~20210324.2-1)
depchains:
 -
  depchain:
   -
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: amd64
depends: ruby-grpc:amd64 (>= 1.42~)
   -
package: ruby-grpc
version: 1.44.0-3
architecture: amd64
depends: libgrpc22:amd64 (>= 1.44.0)

background-packages: 69948
foreground-packages: 1
total-packages: 69949

Bug#1015302: Upgrading 14.10.5 to 15.0.4 aborts on db:migrate

[Pirate Praveen]

2022, ജൂലൈ 19 12:05:37 PM GMT+02:00, "Patrick Matthäi" ൽ 
എഴുതി
>Package: gitlab
>Version: 15.0.4+ds1-1
>Severity: serious
>
>Hey,
>
>on upgrading gitlab I always end up with this error:
>
>(1055 rows) = Did not find any relations. ]
>+ echo gitlab_production database is not empty, skipping gitlab setup
>gitlab_production database is not empty, skipping gitlab setup
>+ runuser -u gitlab -- sh -c /usr/bin/bundle exec rake db:migrate
>Attention: used pure ruby version of MurmurHash3
>/usr/share/gitlab/lib/gitlab.rb:47: warning: already initialized constant 
>Gitlab::APP_DIRS_PATTERN
>/usr/share/gitlab/lib/gitlab.rb:47: warning: previous definition of 
>APP_DIRS_PATTERN was here
>/usr/share/gitlab/lib/gitlab.rb:48: warning: already initialized constant 
>Gitlab::VERSION
>/usr/share/gitlab/lib/gitlab.rb:48: warning: previous definition of VERSION 
>was here
>/usr/share/gitlab/lib/gitlab.rb:49: warning: already initialized constant 
>Gitlab::INSTALLATION_TYPE
>/usr/share/gitlab/lib/gitlab.rb:49: warning: previous definition of 
>INSTALLATION_TYPE was here
>/usr/share/gitlab/lib/gitlab.rb:50: warning: already initialized constant 
>Gitlab::HTTP_PROXY_ENV_VARS
>/usr/share/gitlab/lib/gitlab.rb:50: warning: previous definition of 
>HTTP_PROXY_ENV_VARS was here
>== 20220213103859 RemoveIntegrationsType: migrating ===
>rake aborted!
>StandardError: An error has occurred, all later migrations canceled:
>

On two of my test machines, it was successful. May be you can try running the 
migration manually with --trace option.

gitlab-rake db:migrate --trace

May be ask upstream as well.

Bug#1001554: marked as pending in node-mocha

[Praveen Arimbrathodiyil]

Control: tag -1 pending

Hello,

Bug #1001554 in node-mocha reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/js-team/node-mocha/-/commit/45f27df031e0200763abed7fc5a1c65014a7d77e


Webpack 5 is not able to target web and es5 simultaneiously

Closes: #1001554


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1001554

Bug#1009598: marked as pending in node-postcss-loader

[Praveen Arimbrathodiyil]

Control: tag -1 pending

Hello,

Bug #1009598 in node-postcss-loader reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/js-team/node-postcss-loader/-/commit/b4cbdbcc4e9b9a5a96a7c6762515bc836df07e82


Update minimum version of webpack to 5.0~

Closes: #1009598


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1009598

Bug#995722: Not running tests because tests miss source code is not useful

[Pirate Praveen]

On വെ, ഒക്ടോ 8 2021 at 10:31:16 രാവിലെ +0200 
+0200, Thomas Goirand  wrote:

On 10/7/21 11:40 AM, Pirate Praveen wrote:



 On 7 October 2021 3:02:55 am IST, Thomas Goirand  
wrote:

 On 10/6/21 6:53 PM, Pirate Praveen wrote:

 [adding -devel]

 On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 
+0200, Jonas Smedegaard

  wrote:

 Quoting Yadd (2021-10-06 11:43:40)

  On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
  > Source: src:node-lodash
  > Version: 4.17.21+dfsg+~cs8.31.173-1
  > Severity: serious
  > Justification: do not compile from source
  >
  > Dear Maintainer,
  >
  > The vendor directory should be emptied
  >
  > The debug version is compiled without source (lintian warn) 
and

 moreover the
  > rest of file are already packaged
  >
  > grep -R vendor * gives only a few hit that could be cured by
 symlinking
  >
  > Bastien
  Hi,

  this files are used for test only, maybe severity could be 
decreased.


 I find the severity accurate: Relying on non-source code is a 
severe
 violation of Debian Policy, not matter the purpose of relying on 
it.


 I think we should change the policy here. Running tests helps 
improve
 the quality of the software we ship. Many times the vendored code 
is
 used to ensure the code does not break in a specific situation. I 
don't

 think reducing test coverage in such situations is really helpful.


 Right, running tests helps improve the quality of software we ship.
 Which is why you probably need to test using what's shipped in 
Debian

 rather than using a vendored source-less code.


 We are not shipping the source less code.


You are: Debian also ships source code.


I meant, not shipping in any binary package. Though as Russ mentioned 
in his reply. I will propose a GR.


 This is used only during tests. I don't think we are not gaining 
anything by removing tests here. Just making it harder for the 
package maintainer to run tests.


You would not gain anything by removing tests, but you would win by
making these tests completely free software.


I am just saying it increases the work required to run tests and when 
disabling tests is an option, the incentive is to disable tests.


 If we rely on non-free code for tests, that's really bad too, and 
that
 must be avoided just like we're avoiding source-less code 
everywhere

 else in Debian. The policy shall not change, please.



 The code is not non-free here, just a specific version of a Free 
Software code built outside Debian.


We build from source...


We build the binary packages from source. I don't think it is useful to 
extend that to tests without considering the tradeoffs involved.


 I think tools required for tests should be considered separately 
from tools required to compile. I think it should be treated similar 
to test data.


I don't agree.


ok, lets see how the whole project feels via a GR and settle it. I just 
expressed my opinion, you expressed yours and we need to make a 
decision now.


 What you are proposing would require the package maintainer to 
adapt these tests to versions available (many times with different 
API versions) in Debian and the easier choice is disabling tests.


No. I believe it's ok to have an embedded version of the JS files in 
the
upstream code. This is a *very* different issue, please do not mix 
them.

What I don't like is using a minified version of the JS files. That's
*very* easy (hum... trivial?) to add a non-minified version in your
Debian folder, and use that for tests. You don't care if running the
tests is a little bit slower (because using a source-full version), 
do you?


I don't think you really understand the complexities here. Building the 
minified version is not just running the minifier against the non 
minified code. The non minified code itself is generated using many 
other tools (typescript, transpiled using babel, bundled using rollup 
or webpack etc - many times the versions of these tools are very much 
different versions as well).




However, there's this:

On 10/7/21 6:17 PM, Richard Laager wrote:
 Running tests against vendored dependencies one isn't going to use 
at

 run-time is of limited usefulness.


Best is, if you can, use the library packaged separately, in Debian,
both for tests, and runtime. This way, you do ensure that:
- patching Debian for security is still a thing
- the package can run with the Debian version of the lib



You are completely missing the reality here as well. The runtime 
dependencies are already used from the packaged versions. These 
vendored libraries are used only to create specific test cases or 
sometimes using alternative implementations to test the shipped code.


I think it's less grave than just saying "oh, we don't care about 
these

binary blobs, there's just for tests...". It's even worse, because by
using a different version for tests and runtime, you're faking 
tests...




See above. All runtime dependencies are packaged a

Bug#995722: Not running tests because tests miss source code is not useful

[Pirate Praveen]

On 7 October 2021 3:02:55 am IST, Thomas Goirand  wrote:
>On 10/6/21 6:53 PM, Pirate Praveen wrote:
>> [adding -devel]
>> 
>> On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 +0200, Jonas Smedegaard
>>  wrote:
>>> Quoting Yadd (2021-10-06 11:43:40)
>>>>  On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
>>>>  > Source: src:node-lodash
>>>>  > Version: 4.17.21+dfsg+~cs8.31.173-1
>>>>  > Severity: serious
>>>>  > Justification: do not compile from source
>>>>  >
>>>>  > Dear Maintainer,
>>>>  >
>>>>  > The vendor directory should be emptied
>>>>  >
>>>>  > The debug version is compiled without source (lintian warn) and
>>>> moreover the
>>>>  > rest of file are already packaged
>>>>  >
>>>>  > grep -R vendor * gives only a few hit that could be cured by
>>>> symlinking
>>>>  >
>>>>  > Bastien
>>>>  Hi,
>>>>
>>>>  this files are used for test only, maybe severity could be decreased.
>>>
>>> I find the severity accurate: Relying on non-source code is a severe
>>> violation of Debian Policy, not matter the purpose of relying on it.
>> 
>> I think we should change the policy here. Running tests helps improve
>> the quality of the software we ship. Many times the vendored code is
>> used to ensure the code does not break in a specific situation. I don't
>> think reducing test coverage in such situations is really helpful.
>
>Right, running tests helps improve the quality of software we ship.
>Which is why you probably need to test using what's shipped in Debian
>rather than using a vendored source-less code.

We are not shipping the source less code. This is used only during tests. I 
don't think we are not gaining anything by removing tests here. Just making it 
harder for the package maintainer to run tests.

>If we rely on non-free code for tests, that's really bad too, and that
>must be avoided just like we're avoiding source-less code everywhere
>else in Debian. The policy shall not change, please.
>

The code is not non-free here, just a specific version of a Free Software code 
built outside Debian.

I think tools required for tests should be considered separately from tools 
required to compile. I think it should be treated similar to test data.

What you are proposing would require the package maintainer to adapt these 
tests to versions available (many times with different API versions) in Debian 
and the easier choice is disabling tests.

I think blindly applying a rule without thinking of any consequences is bad 
too. Just because it is bad in one situation does not mean it will be bad in 
every situation. We should evaluate pros and cons of each situation before 
making a decision. Blind faith is more suitable for religions and not for a 
project like ours.

I think a nocheck build profile which excludes these files from build is 
sufficient to ensure we are not using these to create binary package. This way 
we guarantee only packages in main is used to generate the binary, but still 
allows to run tests optionally making it easy to find problems, especially 
during transitions. Currently when tests are missing transitions are harder 
because we can't find breakages easily since tests are disabled.

The current policy is not making Debian better.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#995722: Not running tests because tests miss source code is not useful

[Pirate Praveen]

[adding -devel]

On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 +0200, 
Jonas Smedegaard  wrote:

Quoting Yadd (2021-10-06 11:43:40)

 On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
 > Source: src:node-lodash
 > Version: 4.17.21+dfsg+~cs8.31.173-1
 > Severity: serious
 > Justification: do not compile from source
 >
 > Dear Maintainer,
 >
 > The vendor directory should be emptied
 >
 > The debug version is compiled without source (lintian warn) and 
moreover the

 > rest of file are already packaged
 >
 > grep -R vendor * gives only a few hit that could be cured by 
symlinking

 >
 > Bastien
 Hi,

 this files are used for test only, maybe severity could be 
decreased.


I find the severity accurate: Relying on non-source code is a severe
violation of Debian Policy, not matter the purpose of relying on it.


I think we should change the policy here. Running tests helps improve 
the quality of the software we ship. Many times the vendored code is 
used to ensure the code does not break in a specific situation. I don't 
think reducing test coverage in such situations is really helpful.

Bug#995702: Updating caniuse-lite (was: Re: TypeError: Cannot read property 'prefix_exceptions' of undefined)

[Pirate Praveen]

On തി, ഒക്ടോ 4 2021 at 03:17:03 വൈകു +0200 +0200, 
Dominik George  wrote:

Hi,

concerning the update of node-caniuse-lite, I fixed upstream's
deployment script, so that uscan will find new upstream versions
again:

  https://github.com/browserslist/caniuse-lite/issues/84

Shall I update caniuse-lite and upload the new version once uscan is
satisfied again?



Yes, please. You can take a snapshot of the git commit manually (the 
commit logs have version in comments) if you don't want to wait for 
next version. From next version we can continue using uscan.



Cheers,
Nik

Bug#995702: [Pkg-javascript-devel] TypeError: Cannot read property 'prefix_exceptions' of undefined

[Pirate Praveen]

On 4 October 2021 6:02:19 pm IST, Dominik George  
wrote:
>>   - let autoprefixerData = { browsers: agents, prefixes: dataPrefixes }
>>   + let autoprefixerData = { browsers: agents.agents, prefixes: dataPrefixes 
>> }
>
>It's
>https://github.com/browserslist/caniuse-lite/commit/fde289588b2ccb129ba3d1552134be2c78fee8b7
>
>So, this happened with a recent update of node-autoprefixer, because
>the new autoprefixer relies on the new API of caniuse-lite.
>
>caniuse-lite should, and will at some point, be updated in Debian as
>well. However, this will break node-browserslist, because that relies
>on the old API. Oh the joy!

Is there a new version of browserslist that uses the new API?

>Proposal:
>
> 1. Add a patch to node-autoprefixer to use the old API
> 2. Add a version constraint to the node-caniuse-lite dependency in
>node-autoprefixer (<< 1.0.30001226~)
> 3. Report a bug against node-caniuse-lite to update to the current
>upstream version, with a gentle hint on what will break if updated
> 4. Once updated, drop the patch, and remove the version constraint
>
>@ JavaScript team, shall I proceed with that?

I think updating node-caniuse-lite and patching node-browserslist may be 
better. But if that is difficult, you can go ahead with this.

BTW I had noticed the breakage while updating gitlab and filed a bug, but did 
not get time to dig deeper. Thanks for these details.

>-nik

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#995487: ruby-autoprefixer-rails: broken build, breaks gitlab

[Pirate Praveen]

Package: ruby-autoprefixer-rails
version:10.3.1.0+dfsg1+~cs14.6.19-1
Severity: grave

gitlab 14.1 installation fails when using this version. Exact error message 
will be shared after reproducing the error (filing rc bug to block migration to 
testing), downgrading to 10.2 worked.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#995073: gitlab: yarnpkg fails with error An unexpected error occurred: "Release not found: 2.4.2".

[Pirate Praveen]

On 26 September 2021 8:14:08 pm IST, Ondrej Zary  wrote:
>> yarn 3.0 needs nodejs 12. So this was a work around used to force yarn
>> 2.x. Looks like there is no way to install 2.x versions of yarn anymore :(
>>
>> So we will have to update minimum version of nodejs to 12 (already done
>> for latest versions in bullseye) and use yarn set version berry. I guess
>> you will have to use nodejs from official repos or we will have to
>> backport nodejs 12 to buster.
>
>I've built nodejs 12 and added "yarnpng set version berry" before
>"yarnpkg set version 2.4.2".
>It downloaded tons of random crap from somewhere during the "fetch step".
>Is that normal?

Not sure which packages it pulls in that step.

>Otherwise it seems to work.
>Webpack failed, as always...3 kinds of errors this time.
>
>Installing node modules...
>(node:22064) [DEP0005] DeprecationWarning: Buffer() is deprecated due to 
>security and usability issues. Please use the Buffer.alloc(), 
>Buffer.allocUnsafe(), or Buffer.from() methods instead.
>Resolving berry to a url...
>Downloading 
>https://github.com/yarnpkg/berry/raw/master/packages/berry-cli/bin/berry.js...
>Saving it into /var/lib/gitlab/.yarn/releases/yarn-berry.js...
>Updating /var/lib/gitlab/.yarnrc.yml...
>Done!
>➤ YN: Retrieving 
>https://repo.yarnpkg.com/2.4.2/packages/yarnpkg-cli/bin/yarn.js
>➤ YN: Saving the new release in .yarn/releases/yarn-2.4.2.cjs
>➤ YN: Done in 1s 327ms
>➤ YN: ┌ Resolution step
>➤ YN0061: │ document-register-element@npm:1.14.3 is deprecated: V0 is gone and 
>the best V1 polyfill is now @ungap/custom-elements
>➤ YN0061: │ axios@npm:0.20.0 is deprecated: Critical security vulnerability 
>fixed in v0.21.1. For more information, see 
>https://github.com/axios/axios/pull/3410
>➤ YN0061: │ urix@npm:0.1.0 is deprecated: Please see 
>https://github.com/lydell/urix#deprecated
>➤ YN0061: │ smooshpack@npm:0.0.62 is deprecated: Package moved to 
>@codesandbox/sandpack-client
>➤ YN0061: │ resolve-url@npm:0.2.1 is deprecated: 
>https://github.com/lydell/resolve-url#deprecated
>➤ YN0061: │ uuid@npm:3.3.2 is deprecated: Please upgrade  to version 7 or 
>higher.  Older versions may use Math.random() in certain circumstances, which 
>is known to be problematic.  See https://v8.dev/blog/math-random for details.
>➤ YN0061: │ popper.js@npm:1.16.1 is deprecated: You can find the new Popper v2 
>at @popperjs/core, this package is dedicated to the legacy v1
>➤ YN0061: │ querystring@npm:0.2.0 is deprecated: The querystring API is 
>considered Legacy. new code should use the URLSearchParams API instead.
>➤ YN0032: │ fsevents@npm:2.3.2: Implicit dependencies on node-gyp are 
>discouraged
>➤ YN0032: │ fsevents@npm:2.3.2: Implicit dependencies on node-gyp are 
>discouraged
>➤ YN0032: │ evp_bytestokey@npm:1.0.3: Implicit dependencies on node-gyp are 
>discouraged
>➤ YN0002: │ apollo-link-batch@npm:1.1.15 doesn't provide graphql (pf2c3f), 
>requested by apollo-link
>➤ YN0002: │ bootstrap-vue@npm:2.17.3 doesn't provide jquery (p8724c), 
>requested by bootstrap
>➤ YN0002: │ bootstrap-vue@npm:2.17.3 doesn't provide vue (p74d19), requested 
>by portal-vue
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides @babel/core (p8d5b6) 
>with version 0.0.0, which doesn't satisfy what babel-loader requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides popper.js (pb3b3d) with 
>version 0.0.0, which doesn't satisfy what bootstrap requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (p02edf) with 
>version 0.0.0, which doesn't satisfy what portal-vue requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (pa125f) with 
>version 0.0.0, which doesn't satisfy what tiptap requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (p6c5ff) with 
>version 0.0.0, which doesn't satisfy what @gitlab/ui requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (p4a08d) with 
>version 0.0.0, which doesn't satisfy what @tiptap/vue-2 requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (pc6a59) with 
>version 0.0.0, which doesn't satisfy what @toast-ui/vue-editor requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (p082e1) with 
>version 0.0.0, which doesn't satisfy what tiptap-extensions requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (paa947) with 
>version 0.0.0, which doesn't satisfy what vue-resize requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (p1dfac) with 
>version 0.0.0, which doesn't satisfy what vuex requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue-template-compiler 
>(pb49ea) with version 0.0.0, which doesn't satisfy what tiptap requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue-template-compiler 
>(p659ff) with version 0.0.0, which doesn't satisfy what tiptap-extensions 
>requests
>➤ YN: │ Some peer dependencies are incorrectly met; run yarn explain 
>peer-requirements  for details, where  is the 

Bug#995073: gitlab: yarnpkg fails with error An unexpected error occurred: "Release not found: 2.4.2".

[Pirate Praveen]

On 25/9/21 11:11 PM, Ondrej Zary wrote:
> Package: gitlab
> Version: 13.12.9+ds1-1~fto10+1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
> installing gitlab 13.12.9+ds1-1~fto10+1 on buster amd64 fails with:
>
> Installing node modules...
> Resolving 2.4.2 to a url...
> error An unexpected error occurred: "Release not found: 2.4.2".
> info If you think this is a bug, please open a bug report with the 
> information provided in "/var/lib/gitlab/yarn-error.log".
> info Visit https://yarnpkg.com/en/docs/cli/policies for documentation about 
> this command.

yarn 3.0 needs nodejs 12. So this was a work around used to force yarn
2.x. Looks like there is no way to install 2.x versions of yarn anymore :(

So we will have to update minimum version of nodejs to 12 (already done
for latest versions in bullseye) and use yarn set version berry. I guess
you will have to use nodejs from official repos or we will have to
backport nodejs 12 to buster.




signature.asc
Description: OpenPGP digital signature

Bug#994624: libreoffice fail to start with error undefined symbol: _ZNK11LanguageTag20getGlibcLocaleStringESt17basic_string_viewIDsSt11char_traitsIDsEE

[Pirate Praveen]

Package: libreoffice
Version: 1:7.2.1-1
Severity: grave
Justification: the package is unusable

$ libreoffice
/usr/lib/libreoffice/program/soffice.bin: symbol lookup error: 
/usr/lib/libreoffice/program/libmergedlo.so: undefined symbol: 
_ZNK11LanguageTag20getGlibcLocaleStringESt17basic_string_viewIDsSt11char_traitsIDsEE

Bug#993964: gitaly 14.0 fails to start with error panic: failed to open gzip reader: EOF

[Pirate Praveen]

On ബു, സെപ്റ്റം 8 2021 at 10:46:06 വൈകു 
+0530 +0530, Pirate Praveen  wrote:
Sep 08 16:02:18 gitlab gitaly[4823]: panic: failed to open gzip 
reader: EOF


Fixed by updating golang-goprotobuf to 1.5.2 (Thanks to Nilesh for help 
with troubleshooting).

Bug#993964: gitaly 14.0 fails to start with error panic: failed to open gzip reader: EOF

[Pirate Praveen]

Package: gitaly
Version: 14.0.10+dfsg-1
Severity: grave

gitaly 14.0.10 from https://wiki.debian.org/gitlab/devel fails to start 
and


journalctl -xel -u gitaly --no-pager

gives the following error

Sep 08 16:02:18 gitlab gitaly[4823]: panic: failed to open gzip reader: 
EOF

Sep 08 16:02:18 gitlab gitaly[4823]: goroutine 1 [running]:
Sep 08 16:02:18 gitlab gitaly[4823]: 
gitlab.com/gitlab-org/gitaly/internal/praefect/protoregistry.init.0()
Sep 08 16:02:18 gitlab gitaly[4823]: 
gitlab.com/gitlab-org/gitaly/internal/praefect/protoregistry/protoregistry.go:32 
+0x227
Sep 08 16:02:18 gitlab systemd[1]: gitaly.service: Main process exited, 
code=exited, status=2/INVALIDARGUMENT

Bug#993818: ruby-nokogiri: WARNING: Nokogiri was built against libxml version 2.9.12, but has dynamically loaded 2.9.10

[Pirate Praveen]

Package: ruby-nokogiri
Version: 1.11.7+dfsg-2
Severity: serious
Justification: migration to testing blocked

autopkgtest for cewl is failing in testing

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cewl/15073435/log.gz

terceiro on irc:
this type of warning is a PITA; I usually patch them out
(after checking that the package does work with whatever version we 
have in debian :))
just checked, the dependency is automatically generated; probably 
patching to remove the check and warning is the way to go

Bug#993817: ruby-licensee: autopkgtest regression on 9386

[Pirate Praveen]

Package: ruby-licensee
Version: 9.14.1-3
Severity: serious
Control: forwarded -1 https://github.com/licensee/licensee/issues/503

Autopkgtest regression on i386 is blocking the migration to testing

https://ci.debian.net/data/autopkgtest/testing/i386/r/ruby-licensee/15051694/log.gz

Reported upstream https://github.com/licensee/licensee/issues/503

Bug#991606: ruby-libxml: test failures with libxml2 2.9.12

[Pirate Praveen]

Control: forwarded -1 https://github.com/xml4r/libxml-ruby/issues/172

On Wed, 28 Jul 2021 15:35:58 +0200 Mattia Rizzolo  
wrote:

> Source: ruby-libxml
> Version:  3.2.0-1
> Severity: serious

Do we keep serious severity for failure only in experimental? Don't we 
wait till libxml2 2.9.12 hits unstable to raise severity?


> Tags: sid bookworm
>
> Dear maintainer,
>
> running autopkgtest against libxml2/2.9.12 (as currently found in
> experimental) fails:
> 
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-libxml/13882963/log.gz



Reported upstream here https://github.com/xml4r/libxml-ruby/issues/172

Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require

[Pirate Praveen]

2021, ഓഗസ്റ്റ് 10 5:44:35 PM IST, Pirate Praveen ൽ 
എഴുതി
>
>
>2021, ഓഗസ്റ്റ് 10 12:44:39 PM IST, "László Böszörményi (GCS)" 
>ൽ എഴുതി
>>Control: tags -1 +pending
>>
>>Hi Pirate,
>>
>>On Mon, Aug 9, 2021 at 8:51 PM Pirate Praveen  
>>wrote:
>>> Can you upload this change? Or if you are okay with this change, I can
>>> upload it as well. Once this is fixed, I can switch back to the
>>> packaged version (currently using gem install google-protobuf as work
>>> around).
>> Sure, I can. Will do it soon.

Thanks.

>>> I had seen this bug earlier
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989774 but I thought
>>> it was something similar/related to
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966653 (between, this
>>> bug also seems to be fixed with newer protobuf/grpc versions in
>>> experimental).
>> You know, my question is, how and why it was and still working for
>>3.12.4 but nor for 3.17.3?

One change that I can think of is adding noruby build profile between these two 
versions.

>>Regards,
>>Laszlo/GCS

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.