Bug#1064140: imagemagick: NMU diff for 64-bit time_t transition

[Bastien ROUCARIES]

Hi,

Go ahead ASAP

Bastien

Le sam. 17 févr. 2024 à 17:40, Steve Langasek  a écrit :
>
> Source: imagemagick
> Version: 8:6.9.12.98+dfsg1-5
> Severity: important
> Tags: patch pending sid trixie
> User: debian-...@lists.debian.org
> Usertags: time-t
>
> NOTICE: these changes must not be uploaded to unstable yet!
>
> Dear maintainer,
>
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> imagemagick as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
>
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
>
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for imagemagick
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
>
> Please find the patch for this NMU attached.
>
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.
>
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)

Bug#1063508: ITP: node-long -- Class for representing 64-bit two's-complement integer value

[Bastien ROUCARIES]

Hi all

I have done some work here
https://salsa.debian.org/js-team/node-long/

Yadd could you get a glimpse why the webassembly is not strictly identical ?

Bastien

Le ven. 16 févr. 2024 à 19:16, Bastien ROUCARIES
 a écrit :
>
> Hi,
>
> .
> >
> > I've given access to the js salsa team.
> >
> > [1] https://salsa.debian.org/3v1n0-guest/node-esm2umd/
>
> It is not the node-long tree...
> >

Bug#1063508: ITP: node-long -- Class for representing 64-bit two's-complement integer value

[Bastien ROUCARIES]

Hi,

.
>
> I've given access to the js salsa team.
>
> [1] https://salsa.debian.org/3v1n0-guest/node-esm2umd/

It is not the node-long tree...
>

Bug#1063508: ITP: node-long -- Class for representing 64-bit two's-complement integer value

[Bastien ROUCARIES]

Hi,

Moreover other package embed it and need repacking (after checking)
and filling RC bug:
node-enquirer: /usr/share/doc/node-enquirer/examples/select/select-long.js
node-mongodb: /usr/lib/nodejs/bson/lib/bson/long.js
node-mongodb: /usr/share/nodejs/mongodb/node_modules/bson/lib/bson/long.js
node-webassemblyjs:
/usr/share/nodejs/webassemblyjs/node_modules/@xtuc/long/dist/long.js
node-webassemblyjs:
/usr/share/nodejs/webassemblyjs/node_modules/@xtuc/long/dist/long.js.map
node-webassemblyjs:
/usr/share/nodejs/webassemblyjs/node_modules/@xtuc/long/src/long.js
pipewire-doc: /usr/share/doc/pipewire/html/structspa__pod__long.js
python3-jupyterlab:
/usr/share/jupyter/lab/staging/node_modules/@xtuc/long/dist/long.js
python3-jupyterlab:
/usr/share/jupyter/lab/staging/node_modules/@xtuc/long/dist/long.js.map
python3-jupyterlab:
/usr/share/jupyter/lab/staging/node_modules/@xtuc/long/src/long.js
python3-jupyterlab:
/usr/share/jupyter/lab/staging/node_modules/minimist/test/long.js

Bastien

Le sam. 10 févr. 2024 à 17:28, Marco Trevisan  a écrit :
>
> Hi Bastien,
>
> I checked again, it definitely still has it, however it's completely
> optional so I think we can just do some repackaged sources.
>
> Il giorno ven 9 feb 2024 alle ore 21:33 Bastien ROUCARIES
>  ha scritto:
> >
> >
> >
> > Le ven. 9 févr. 2024 à 04:42, Marco Trevisan  a écrit :
> >>
> >> Package: wnpp
> >> Severity: wishlist
> >> Owner: Marco Trevisan (Treviño) 
> >> X-Debbugs-CC: debian-de...@lists.debian.org
> >>
> >> * Package name: node-long
> >>   Version : 5.2.3
> >>   Upstream Author : Daniel Wirtz 
> >> * URL : https://github.com/dcodeIO/long.js#readme
> >> * License : Apache-2.0
> >>   Programming Lang: JavaScript
> >>   Description : Class for representing 64-bit two's-complement
> >> integer value
> >>
> >>  A Long class for representing a 64 bit two's-complement integer value
> >>  derived from the Closure Library for stand-alone use and extended with
> >>  unsigned support.
> >>  .
> >>  This is a class used by various modules that does not use newer bigint.
> >>  .
> >>  Node.js is an event-based server-side JavaScript engine.
> >>
> >> This is a tiny module that is needed for protobufjs (bug #977564),
> >> although being widely used according to npm stats, I feel it's better to
> >> package it as standalone and not as grouped package.
> >>
> >> Salsa repository is at:
> >>  https://salsa.debian.org/3v1n0-guest/node-esm2umd/-/tree/debian/latest
> >>
> >> Please mark the debian/latest as default branch since I can't change it 
> >> myself.
> >>
> >> The package had a dependency on a very tiny project (esm2umd) that was
> >> just basically a tiny wrapper to babel. I've also prepared the packaging
> >> for it [1], but given that such project has not a clear license (I
> >> mailed the maintainer meanwhile), I preferred to avoid using it, also
> >> because it's really just a script using babel and I have been able to
> >> easily re-implement it, making the build process slightly bigger
> >>
> >> The package needs sponsor, since I'm only a maintainer, but I'll be
> >> happy keeping the maintenance of it.
> >
> >
> > Hi will do but last i checked it has a long line of wasm wirhout source
> >
> > Bastien
> >>
> >>
> >> I've given access to the js salsa team.
> >>
> >> [1] https://salsa.debian.org/3v1n0-guest/node-esm2umd/
> >>

Bug#1063508: ITP: node-long -- Class for representing 64-bit two's-complement integer value

[Bastien ROUCARIES]

Le ven. 9 févr. 2024 à 04:42, Marco Trevisan  a écrit :

> Package: wnpp
> Severity: wishlist
> Owner: Marco Trevisan (Treviño) 
> X-Debbugs-CC: debian-de...@lists.debian.org
>
> * Package name: node-long
>   Version : 5.2.3
>   Upstream Author : Daniel Wirtz 
> * URL : https://github.com/dcodeIO/long.js#readme
> * License : Apache-2.0
>   Programming Lang: JavaScript
>   Description : Class for representing 64-bit two's-complement
> integer value
>
>  A Long class for representing a 64 bit two's-complement integer value
>  derived from the Closure Library for stand-alone use and extended with
>  unsigned support.
>  .
>  This is a class used by various modules that does not use newer bigint.
>  .
>  Node.js is an event-based server-side JavaScript engine.
>
> This is a tiny module that is needed for protobufjs (bug #977564),
> although being widely used according to npm stats, I feel it's better to
> package it as standalone and not as grouped package.
>
> Salsa repository is at:
>  https://salsa.debian.org/3v1n0-guest/node-esm2umd/-/tree/debian/latest
>
> Please mark the debian/latest as default branch since I can't change it
> myself.
>
> The package had a dependency on a very tiny project (esm2umd) that was
> just basically a tiny wrapper to babel. I've also prepared the packaging
> for it [1], but given that such project has not a clear license (I
> mailed the maintainer meanwhile), I preferred to avoid using it, also
> because it's really just a script using babel and I have been able to
> easily re-implement it, making the build process slightly bigger
>
> The package needs sponsor, since I'm only a maintainer, but I'll be
> happy keeping the maintenance of it.
>

Hi will do but last i checked it has a long line of wasm wirhout source

Bastien

>
> I've given access to the js salsa team.
>
> [1] https://salsa.debian.org/3v1n0-guest/node-esm2umd/
>
>

Bug#1038637: closed by Debian FTP Masters (reply to Bastien Roucariès ) (Bug#1038637: fixed in imagemagick 8:6.9.12.98+dfsg1-4)

[Bastien ROUCARIES]

Le lun. 30 oct. 2023 à 11:54, Thomas  a écrit :
>
> This is great, but it looks like the change uses libraw-bin, and not
> libraw-dev? I may be mistaken, but I believe the latter is required for
> compilation?

it already use libraw-dev for compilation since last unstable upload.
I have only changed the last remaining part the suggest binary

Could you cross check ?

If not feel free to reopen this bug

>
> On 30/10/2023 11:21, Debian Bug Tracking System wrote:
> > This is an automatic notification regarding your Bug report
> > which was filed against the imagemagick package:
> >
> > #1038637: Recompile imagemagick with libraw
> >
> > It has been closed by Debian FTP Masters  
> > (reply to Bastien Roucariès ).
> >
> > Their explanation is attached below along with your original report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Debian FTP Masters 
> >  (reply to Bastien Roucariès 
> > ) by
> > replying to this email.
> >
> >
>

Bug#1020358: libmagickcore-6.q16-7: transition gsfonts/gsfonts-x11 --> fonts-urw-base35

[Bastien ROUCARIES]

Le lun. 23 oct. 2023 à 11:45, Vincent Lefevre  a écrit :

> Control: found -1 8:6.9.12.98+dfsg1-2
>
> On 2022-09-20 18:18:23 +0200, fab...@debian.org wrote:
> > you are receiving this bug report, because your package declares a
> > relationship with the gsfonts and/or gsfonts-x11 packages. Both
> > packages have been replaced by fonts-urw-base35 since version
> > 20200910-2 and are now merely transitional dummy packages. In order
> > to make it possible to remove these transitional packages, please
> > adjust the relationships for your package accordingly.
>
> Any news?
>
> This is annoying, because on imagemagick upgrade, aptitude wants
> to reinstall gsfonts, which I had removed.
>

Patch welcome hère. Will apply asap

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

Bug#990028: /usr/bin/mogrify-im6.q16: raw support requires ufraw-batch which is no longer in Debian

[Bastien ROUCARIES]

Hi,

Help is welcome on the imagemagick side. You could step in as a maint
or test salsa tree

Le lun. 24 juil. 2023 à 17:21, Darshaka Pathirana  a écrit :
>
> Hi,
>
> On Fri, 03 Sep 2021 22:00:12 + Debian FTP Masters 
>  wrote:
> > Source: imagemagick
> > Source-Version: 8:6.9.12.20+dfsg1-1
> > Done: Bastien Roucariès 
>
> If just stumbled over this:
>
>   ❯ identify -format "%f: %wx%h\n" "DSC_0597.NEF"
>   identify-im6.q16: delegate failed `'ufraw-batch' --silent --create-id=also 
> --out-type=png --out-depth=16 --output='%u.png' '%i'' @ 
> error/delegate.c/InvokeDelegate/1966.
>   identify-im6.q16: unable to open image 
> `/tmp/magick-vD_smqp7YJHGABZ2bxgam6OJlqxQ5NMN.ppm': No such file or directory 
> @ error/blob.c/OpenBlob/2924.
>
> I am still running Debian/bullseye, but as far as I can see version 
> 6.9.12.20+dfsg1-1 is only in experimental.
> Any plans to bring it to unstable?
>
> Apart from that, imagemagick-6.q16 + imagemagick-6.q16hdri do still have 
> "Suggests: ufraw-batch"[1][2].
> This should be removed.
>
> [1] 
> https://salsa.debian.org/debian/imagemagick/-/blob/debian/lastest/debian/control?ref_type=heads#L200
> [2] 
> https://salsa.debian.org/debian/imagemagick/-/blob/debian/lastest/debian/control?ref_type=heads#L411
>
> And finally: is there a workaround for this problem, as Debian/bullseye + 
> bookworm still seem to be affected by this bug?
> Should we open a new issue or re-open this bug?
>
> Thx for maintaining!
>
> Best,
>  - Darsha

Bug#1037176: ITP: typesense -- Fast, typo-tolerant search engine

[Bastien ROUCARIES]

Le mer. 7 juin 2023 à 08:00, Didier 'OdyX' Raboud  a
écrit :

> Package: wnpp
> Severity: wishlist
> Owner: Didier 'OdyX' Raboud 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
>   Package name: typesense
>   Version : 0.24.1
>   Upstream Contact: TypeSense team 
>   URL : https://typesense.org
>   License : GPL-3
>   Programming Lang: C++
>
> Typo-tolerant search engine optimized for instant search-as-you-type
> experiences and developer productivity. Push data to it and then allow
> users to search through this data via a search UI in a site or app.
>
> I plan to package this under https://salsa.debian.org/debian/typesense.
> If there's a matching packaging team, more than happy to move there!
>

It is useful for dyslexic people. Maybe accessibilty related team ?

Bastien

>

Bug#977027: [Pkg-javascript-devel] Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Bastien ROUCARIES]

Le jeu. 6 avr. 2023 à 11:24, Paul Gevers  a écrit :
>
> Control: tags -1 pending patch
>
> On 06-04-2023 12:54, Paul Gevers wrote:
> > I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5
>
> Please find the debdiffs attached.

Go ahead
>
> Paul
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#977027: [Pkg-javascript-devel] Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Bastien ROUCARIES]

Le dim. 26 mars 2023 à 21:39, Markus Koschany  a écrit :

> Hi Graham,
>
> Am Sonntag, dem 26.03.2023 um 19:28 +0200 schrieb Graham Inggs:
> > Hi Markus
> >
> > On Sun, 26 Mar 2023 at 16:34, Markus Koschany  wrote:
> > > 1. There is no transition needed because only shrinksafe is affected
> by the
> > > new
> > > rhino version.
>
>
> > How did you determine this?
>
> Rhino 1.7.14 was mostly API compatible meaning I only had to fix an issue
> in
> closure-compiler. All other packages can be built from source without
> modifications. I didn't find any other runtime / ABI issues so far.
>
> >
> > > 2. shrinksafe has no reverse-dependencies
> >
> > That is true, but src:dojo has ledgersmb and tt-rss as
> reverse-dependencies.
>
> I used codesearch.debian.net and found only documentation or other minor
> references of shrinksafe in affected packages.
>
> https://codesearch.debian.net/search?q=shrinksafe=1
>
> Since all Java tests in dojo pass after the rebuild and almost all of the
> code
> in dojo is Javascript anyway, I don't see how ledgersmb and tt-rss can be
> affected by the new rhino version. Wouldn't those packages depend on rhino
> in
> some way? To me it seems rhino is only required to build shrinksafe which
> can
> be used for compressing Javascript files. But maybe the dojo maintainers
> can
> chime in here.
>

Yes shrinksafe is only used for compression.

Bastien

>
>
> Regards,
>
> Markus
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>

Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency

[Bastien ROUCARIES]

Le sam. 8 oct. 2022 à 11:00, Niels Thykier  a écrit :

> Hi,
>
> I have BCC'ed debian-devel on this email to ask for input on this bug
> (#903158) and ask parties that are interested to follow up there.  I am
> considering to remove the dependencies for -dbgsym packages on the
> grounds that:
>
>   1) They are too weak when M-A: foreign is involved and they are not
>  always help (see the partial email quote from the bug below)

  2) We now have a debuginfod service, so you do not even have to install
>  dbgsym packages anymore (if you configure gdb to use it).  For the
>  cases where you do install the dbgsym, you still have to manage
>  inter-source dbgsym dependencies manually
>
The second point make me unease... I often debug without an stable internet
connection (embeded).

> As a debhelper maintainer, I willing to either keep the status quo and
> close the bug as wontfix or close the bug by removing the dependencies.
> If you hoping for another outcome, I expect you to be ready to put the
> effort and patches required to reach the outcome.
>

I think wontfix is the way to go but document also in devref...

Bastien

> Thanks,
> ~Niels
>
> On Sat, 4 Aug 2018 21:04:59 +0200 Helmut Grohne  wrote:
> > Hi Niels,
> >
> > On Sat, Aug 04, 2018 at 08:38:00AM +, Niels Thykier wrote:
> > > On Sat, 7 Jul 2018 11:40:54 +0300 "Yuriy M. Kaminskiy"
> > >  wrote:
> > > > I think (at least, 'Multi-arch: foreign' *and* 'Architecture' != all)
> > > > packages should have explicit parent package arch dependency
> > > >Depend: foo:${Arch} (=${binary:Version})
> > > > instead of
> > > >Depend: foo (=${binary:Version})
> > > > Untested patch against debhelper 11.3.5 attached (please review
> > > > carefully, I'm neither M-A nor debhelper expert).
> >
> > Yes, this makes somewhat sense.
> >
> > Personally, I disagree with the Depends though. I've often been in the
> > situation of wanting to debug a foreign core file or remotely attaching
> > to a process on a different system. These dependencies were not helpful
> > at all in these situations. Personally, I'm in favour of making -dbgsym
> > packages dependency-less. I acknowledge that others see things
> > different.
>

Maybe we could have instead of dépends recommand with correct arch ans
depends. Stacktrace will ne complete with bare apt. But package are self
contained. Best of both world.

Bastien

> In any case, we agree that if we want the dependency, then it is
> > presently too weak.
> >
> > [...]
>
>

Bug#993301: prototypejs: FTBFS

[Bastien ROUCARIES]

Le mer. 17 nov. 2021 à 13:02, Andreas Beckmann  a écrit :

> Control: tag -1 moreinfo
>
> On Mon, 30 Aug 2021 12:23:22 + "=?utf-8?q?Bastien_Roucari=C3=A8s?="
>  wrote:
> > Source: prototypejs
> > Severity: serious
> > Justification: 4
> >
> > Dear Maintainer,
> >
> > The source is https://github.com/prototypejs/prototype/tree/master and
> need
> > rake for building...
> >
> > So FTBFS
>
> I can rebuild prototypejs/1.7.1-3.1 in sid and bullseye without
> problems. What errors do you encounter?
>

Yes but this not prefered source of modification...

> There is a new upstream release 1.7.3 (from 2015) available on github.
> Does that version fail?
>
> And how is this related to rake?
>
Sée thé salsa tree un order to understand why i need rake

>
>
> Andreas
>

Bug#996909: [Pkg-javascript-devel] Bug#996909: acorn: Invalid package section for node-debbundle-acorn

[Bastien ROUCARIES]

Go nmu

I will be far from a computer a few days...

Do no t forger to apply to salsa or at least do a merge request

Thanks

Le mer. 20 oct. 2021 à 18:06, Steve Langasek 
a écrit :

> Package: acorn
> Version: 8.5.0+ds+~cs24.17.6-2
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu jammy ubuntu-patch
>
> Hi Bastien,
>
> The latest version of acorn has node-debbundle-acorn listed in Section:
> oldlib.  This is invalid; the correct section name is 'oldlibs'.  In the
> Debian archive, this is not an issue because the Debian archive applies
> overrides to all packages (indeed, I see the archive still lists this
> package as 'Section: javascript'), but in Ubuntu this blocks the binary
> package from being uploaded.  So I have applied the attached patch for
> Ubuntu, which should also be correct for Debian.
>
> Cheers,
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>

Bug#996836: [Pkg-javascript-devel] Bug#996836: node-webpack: webpack embeds binary files in es-module-lexer component

[Bastien ROUCARIES]

Le mar. 19 oct. 2021 à 16:12, Yadd  a écrit :

> Source: node-webpack
> Version: 5.58.2+~cs5.11.7-1
> Severity: serious
> Justification: DFSG
>
> webpack 5.58 uses es-module-lexer. For now, this component is downloaded
> including some binary files (WASM,...). This should be fixed before
> going to unstable.
>

I really hate wasm...

What is the source language ? Rust ?

>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>

Bug#994451: golang-github-containers-common: secomp.json does not include newer syscall used by stable kernel/glibc on arm

[Bastien ROUCARIES]

Le lun. 27 sept. 2021 à 16:08, Reinhard Tartler  a écrit :
>
>
> On Thu, Sep 16, 2021 at 4:18 AM Bastien Roucariès 
>  wrote:
>>
>> Package: golang-github-containers-common
>> Version: 0.33.4+ds1-1
>> Severity: critical
>> Tags: upstream
>> Forwarded: 
>> https://github.com/containers/common/commit/42d1db16bfc0dbaee5781d230dc2bcbaa0849c6e
>> Control: fixed -1 0.42.1+ds1-1
>>
>> Dear Maintainer,
>>
>> golang-github-containers-common in stable does not include recent syscall 
>> used
>> by stable kernel/glibc breaking in my case simple container that do 
>> unattended-
>> upgrade on arm
>> particularly syscall=436 that is timer_settime64
>>
>> I believe this should be fixed in a point release.
>
>
> I agree. I realized that these syscall changes also affect amd64. I was able 
> to reproduce the issue
> by running a distribution that ships with glibc 2.34, such as ubuntu impish. 
> The testcase would be:
>
> $ podman run --rm -it ubuntu:impish sh -c 'apt update -qq && apt -y 
> full-upgrade && apt install -y libc6 jq'
>
> The symptom is described in more detail at 
> https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/1943049
>
> The problem here is that the issue is not simply dealt with updating the 
> secomp.json file, but also some code changes are required
> that allow setting the default return value for some syscalls. This means 
> that in order to fix this issue in stable, 3 uploads are needed:
>
> - golang-github-opencontainers-specs
> - golang-github-containers-common
> - libpod
>
> I'm cloning this bug appropriately so that these uploads can be tracked 
> separately.
> For now,I've backported and verified the changes. For your convenience, I've 
> uploaded the packages I got so far to
> https://people.debian.org/~siretart/bug.994451/
>
>>
>> BTW I strongly believe that  seccomp.json is a config file and should be
>> shipped in /etc and 988443  should also be shipped in stable.
>
>
> I could get convinced if the issue was fixable by just upading the 
> seccomp.json policy file.
> Sadly, that's not the case.
It seems that recent version of this package allow to change at exec
time the seccomp.json file.
But for this version, you take the point it need rebuilt.

Note that I have fixed this problem by manually using the unstable
version on my stable.

Bastien


> Stable Release team, I think this bug should be cloned with those 
> instructions:
>
>
> --
> regards,
> Reinhard

Bug#994974: [Pkg-javascript-devel] Bug#994974: node-define-property: Please deembed and fix vulnereability

[Bastien ROUCARIES]

Le ven. 24 sept. 2021 à 08:16, Jonas Smedegaard  a écrit :
>
> Hi Bastien,
>
> Quoting Bastien Roucariès (2021-09-24 09:49:37)
> > Package: node-define-property
> > Severity: serious
> > Tags: security upstream fixed-upstream
> > Justification: security bug
> > Forwarded: https://github.com/jonschlinkert/define-property/pull/6
> > X-Debbugs-Cc: Debian Security Team 
> >
> > Dear Maintainer,
> >
> > According to
> > https://www.npmjs.com/advisories/1490
> > node-define-property is vulnerable
> >
> >
> > Because it embed small modules that are vulnerable.
>
> Sorry, I don't see the advisory mentioning define-property anywhere, and
> don't see our actual code calling "constructor" anywhere, as seems to be
> what the security in the advisory is about.
>
> Your reference to a PR 6 seems to be tied to an older version of
> define-property than in Debian.
>
> Please elaborate how this vulnerability affects code in Debian.
>
>
> > Embdeding is bad and we have here another proof
>
> I was puzzled at first, but think I now understand your point:
>
> Embedding in general is not necessarily bad but is complex to do right -
> embedding without proper tracking is bad.

Yes it is lack of README.Sources, lack of lintian tag

>
> What confused me is that at first I thought you were ranting about
> Debian practice of embedding, but it seems you are ranting about lack of
> tracking of (either upstream or Debian-introduced) embedding.  Do I
> understand that correctly?

Yes it is

Fixed nevertheless
>
> Thanks for reporting, regardless,
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le mar. 21 sept. 2021 à 08:58, Ondrej Zary  a écrit :
>
> On Tuesday 21 September 2021, Bastien ROUCARIES wrote:
> > Le mar. 21 sept. 2021 à 07:55, Ondrej Zary  a écrit :
> > >
> > > On Monday 20 September 2021, Bastien Roucariès wrote:
> > > > Le lundi 20 septembre 2021, 19:32:52 UTC Bastien ROUCARIES a écrit :
> > > > Could you try one by one the following untested patch. Please compile 
> > > > and run
> > > > the testsuite.
> > >
> > > The first one fails to compile:
> > > In file included from ../src/util-inl.h:28,
> > >  from ../src/aliased_buffer.h:7,
> > >  from ../src/memory_tracker.h:12,
> > >  from ../src/memory_tracker-inl.h:6,
> > >  from ../src/base_object.h:27,
> > >  from ../src/async_wrap.h:27,
> > >  from ../src/async_wrap-inl.h:27,
> > >  from ../src/async_wrap.cc:22:
> > > ../src/util.h:210:11: error: ‘Persistent’ does not name a type; did you 
> > > mean ‘gethostent’?
> > >  const Persistent& persistent);
> >
> > Add on the top of the files using v8::Global;
> > and replace  const Persistent& persistent by const
> > Global& persistent
>
> You probably mean Global& persistent.
>
> Then ENVIRONMENT_STRONG_PERSISTENT_VALUES is undefined:
> In file included from ../src/env-inl.h:28,
>  from ../src/base_object-inl.h:28,
>  from ../src/async_wrap-inl.h:28,
>  from ../src/async_wrap.cc:22:
> ../src/env.h:1036:40: error: ‘V’ has not been declared
>ENVIRONMENT_STRONG_PERSISTENT_VALUES(V)
> ^
> ../src/env.h:1036:41: error: ISO C++ forbids declaration of 
> ‘ENVIRONMENT_STRONG_PERSISTENT_VALUES’ with no type [-fpermissive]
>ENVIRONMENT_STRONG_PERSISTENT_VALUES(V)
>  ^
> ../src/env.h:1036:41: error: expected ‘;’ at end of member declaration
>ENVIRONMENT_STRONG_PERSISTENT_VALUES(V)

:S

Jeremy backport will be hard. If we use std::shared_ptr we leak memory

Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le mar. 21 sept. 2021 à 07:55, Ondrej Zary  a écrit :
>
> On Monday 20 September 2021, Bastien Roucariès wrote:
> > Le lundi 20 septembre 2021, 19:32:52 UTC Bastien ROUCARIES a écrit :
> > Could you try one by one the following untested patch. Please compile and 
> > run
> > the testsuite.
>
> The first one fails to compile:
> In file included from ../src/util-inl.h:28,
>  from ../src/aliased_buffer.h:7,
>  from ../src/memory_tracker.h:12,
>  from ../src/memory_tracker-inl.h:6,
>  from ../src/base_object.h:27,
>  from ../src/async_wrap.h:27,
>  from ../src/async_wrap-inl.h:27,
>  from ../src/async_wrap.cc:22:
> ../src/util.h:210:11: error: ‘Persistent’ does not name a type; did you mean 
> ‘gethostent’?
>  const Persistent& persistent);

Add on the top of the files using v8::Global;
and replace  const Persistent& persistent by const
Global& persistent

>^~
>
>
> --
> Ondrej Zary

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Could you try first to apply https://github.com/nodejs/node/commit/c60780ff52

And see if the reject are bad ?

Bastien

Le lun. 20 sept. 2021 à 19:15, Ondrej Zary  a écrit :
>
>
>
> On Monday 20 September 2021 19:31:56 Bastien ROUCARIES wrote:
> > Le lun. 20 sept. 2021 à 17:28, Jérémy Lal  a écrit :
> > >
> > >
> > >
> > > Le lun. 20 sept. 2021 à 19:15, Ondrej Zary  a écrit :
> > > >
> > > > On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote:
> > > > > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary  a écrit :
> > > > > >
> > > > > > On Monday 20 September 2021, Bastien ROUCARIES wrote:
> > > > > > > Could you try to apply
> > > > > > >
> > > > > > > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4
> > > > > > >
> > > > > > > I think it describe that you see
> > > > > >
> > > > > > Does not apply, unfortunately. There's no node_dir.cc file and also 
> > > > > > no BaseObjectPtr definition.
> > > > >
> > > > > Ok as band aid could you replace in the patch BaseObjectPtr by
> > > > > std:shared_ptr
> > > >
> > > > Biggest problem is the missing node_dir.cc file. The patched code from 
> > > > that file is not present at all in nodejs 10.
> > >
> > > Wild guess, try only that part:
> > >
> > > - delete wrap_;
> > > + wrap_->Detach();
> > > + wrap_.reset();
> > Yes but reset is std:shared_ptr
> >
> > But I agree it is the main part of the patch
>
> Detach() is also not defined in src/base_object.h
>
>
> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 17:28, Jérémy Lal  a écrit :
>
>
>
> Le lun. 20 sept. 2021 à 19:15, Ondrej Zary  a écrit :
> >
> > On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote:
> > > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary  a écrit :
> > > >
> > > > On Monday 20 September 2021, Bastien ROUCARIES wrote:
> > > > > Could you try to apply
> > > > >
> > > > > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4
> > > > >
> > > > > I think it describe that you see
> > > >
> > > > Does not apply, unfortunately. There's no node_dir.cc file and also no 
> > > > BaseObjectPtr definition.
> > >
> > > Ok as band aid could you replace in the patch BaseObjectPtr by
> > > std:shared_ptr
> >
> > Biggest problem is the missing node_dir.cc file. The patched code from that 
> > file is not present at all in nodejs 10.
>
> Wild guess, try only that part:
>
> - delete wrap_;
> + wrap_->Detach();
> + wrap_.reset();
Yes but reset is std:shared_ptr

But I agree it is the main part of the patch
> Jérémy
>

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 17:15, Ondrej Zary  a écrit :
>
> On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote:
> > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary  a écrit :
> > >
> > > On Monday 20 September 2021, Bastien ROUCARIES wrote:
> > > > Could you try to apply
> > > >
> > > > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4
> > > >
> > > > I think it describe that you see
> > >
> > > Does not apply, unfortunately. There's no node_dir.cc file and also no 
> > > BaseObjectPtr definition.
> >
> > Ok as band aid could you replace in the patch BaseObjectPtr by
> > std:shared_ptr
>
> Biggest problem is the missing node_dir.cc file. The patched code from that 
> file is not present at all in nodejs 10.
According to 
https://github.com/nodejs/node/commit/b76a2e502c6f227f7df5f35ac3bbb0dcb2a8372d#diff-12768848757b514f1f042fddf06af34b9ba1d395113539ee98ff4bde165d1d4d

it is not needed in old nodejs because dir was not async...

Bastien
>
> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 15:00, Bastien ROUCARIES
 a écrit :
>
> Le lun. 20 sept. 2021 à 14:24, Ondrej Zary  a écrit :
> >
> > On Monday 20 September 2021, Bastien ROUCARIES wrote:
> > > Could you try to apply
> > >
> > > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4

[kapouer][jonas] Do you think it could be backported using std::share_ptr ?

Superficially it seems semantic equivalent, but I am unease

Bastien
> > >
> > > I think it describe that you see
> >
> > Does not apply, unfortunately. There's no node_dir.cc file and also no 
> > BaseObjectPtr definition.
>
> Ok as band aid could you replace in the patch BaseObjectPtr by
> std:shared_ptr
>
> Bastien
>
>
> > --
> > Ondrej Zary
> >
> > --
> > Pkg-javascript-devel mailing list
> > pkg-javascript-de...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#994767: [Pkg-javascript-devel] Bug#994767: rails ftbfs in experimental with The following packages have unmet dependencies: node-debbundle-acorn : Depends: nodejs:any (>= 10.12.0~dfsg~)

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 16:36, Pirate Praveen
 a écrit :
>
> Package: apt-cudf
> Version: 6.0.1-2
> Severity: important
> X-debbugs-cc: pkg-javascript-de...@lists.alioth.debian.org
> Control: affected -1 rails
>
> The following command fails to build rails from experimental (salsa
> master),
>
> DEB_BUILD_PROFILES=nocheck DEB_BUILD_OPTIONS=nocheck sbuild
> --extra-repository='deb http://deb.debian.org/debian experimental main'
> --extra-repository='deb http://incoming.debian.org/debian-buildd/
> buildd-unstable main' --extra-repository='deb
> http://incoming.debian.org/debian-buildd/ buildd-experimental main'
> --build-dep-resolver=aspcud -d experimental -s
>
> This was working till a few days ago and aptitude does not have this
> problem (replace aspcud with aptitude and build succeeds). There was a
> recent change in how nodejs dependencies are declared and I think this
> is related.

Bug is in aspcud. It should support multiarch depends with any
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 14:24, Ondrej Zary  a écrit :
>
> On Monday 20 September 2021, Bastien ROUCARIES wrote:
> > Could you try to apply
> >
> > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4
> >
> > I think it describe that you see
>
> Does not apply, unfortunately. There's no node_dir.cc file and also no 
> BaseObjectPtr definition.

Ok as band aid could you replace in the patch BaseObjectPtr by
std:shared_ptr

Bastien


> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Could you try to apply

https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4

I think it describe that you see

Bastien

Le lun. 20 sept. 2021 à 12:51, Ondrej Zary  a écrit :
>
> > Ok are you on IRC ? I am as rouca on #debian-js channel
>
> No, I'm not.
>
> > Install the debug symbols of nodejs and libuv (if available) and try
> > to run valgrind with --smc-check=all --read-var-info=yes
> > --track-origins=yes
>
> # runuser -u gitlab -- sh -c 'valgrind --smc-check=all --read-var-info=yes 
> --trace-children=yes --track-origins=yes yarnpkg install'
> ==3423== Memcheck, a memory error detector
> ==3423== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==3423== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==3423== Command: /usr/bin/yarnpkg install
> ==3423==
> ==3423== Memcheck, a memory error detector
> ==3423== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==3423== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==3423== Command: /usr/bin/node /usr/bin/yarnpkg install
> ==3423==
> yarn install v1.13.0
> [1/5] Validating package.json...
> [2/5] Resolving packages...
> [3/5] Fetching packages...
> [---]
>  0/520==3423== Invalid read of size 4
> ==3423==at 0x4556B5B: node::fs::FSReqWrap::~FSReqWrap() (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3423==by 0x4547A42: node::fs::FSReqAfterScope::~FSReqAfterScope() (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3423==by 0x45484FD: node::fs::AfterInteger(uv_fs_s*) (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3423==by 0x556170F: uv__work_done (threadpool.c:313)
> ==3423==by 0x55657FD: uv__async_io.part.0 (async.c:118)
> ==3423==by 0x5575527: uv__io_poll (linux-core.c:378)
> ==3423==by 0x55661C5: uv_run (core.c:370)
> ==3423==by 0x4515C75: node::Start(v8::Isolate*, node::IsolateData*, 
> std::vector, 
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&, 
> std::vector, 
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&) (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3423==by 0x4513C96: node::Start(int, char**) (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3423==by 0x8049157: main (in /usr/bin/node)
> ==3423==  Address 0x410 is not stack'd, malloc'd or (recently) free'd
> ==3423==
> ==3423==
> ==3423== Process terminating with default action of signal 11 (SIGSEGV)
> ==3423==  Access not within mapped region at address 0x410
> ==3423==at 0x4556B5B: node::fs::FSReqWrap::~FSReqWrap() (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3423==by 0x4547A42: node::fs::FSReqAfterScope::~FSReqAfterScope() (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3423==by 0x45484FD: node::fs::AfterInteger(uv_fs_s*) (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3423==by 0x556170F: uv__work_done (threadpool.c:313)
> ==3423==by 0x55657FD: uv__async_io.part.0 (async.c:118)
> ==3423==by 0x5575527: uv__io_poll (linux-core.c:378)
> ==3423==by 0x55661C5: uv_run (core.c:370)
> ==3423==by 0x4515C75: node::Start(v8::Isolate*, node::IsolateData*, 
> std::vector, 
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&, 
> std::vector, 
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&) (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3423==by 0x4513C96: node::Start(int, char**) (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3423==by 0x8049157: main (in /usr/bin/node)
> ==3423==  If you believe this happened as a result of a stack
> ==3423==  overflow in your program's main thread (unlikely but
> ==3423==  possible), you can try to increase the size of the
> ==3423==  main thread stack using the --main-stacksize= flag.
> ==3423==  The main thread stack size used in this run was 8388608.
> ==3423== Invalid read of size 1
> ==3423==at 0x786A6A4: check_free (dlerror.c:189)
> ==3423==by 0x786ABD8: free_key_mem (dlerror.c:221)
> ==3423==by 0x786ABD8: __dlerror_main_freeres (dlerror.c:239)
> ==3423==by 0x7CA4667: __libc_freeres (in 
> /usr/lib/i386-linux-gnu/libc-2.28.so)
> ==3423==by 0x402D1DE: _vgnU_freeres (in 
> /usr/lib/i386-linux-gnu/valgrind/vgpreload_core-x86-linux.so)
> ==3423==  Address 0x16b6b3 is not stack'd, malloc'd or (recently) free'd
> ==3423==
> ==3423==
> ==3423== Process terminating with default action of signal 11 (SIGSEGV)
> ==3423==  Access not within mapped region at address 0x16B6B3
> ==3423==at 0x786A6A4: check_free (dlerror.c:189)
> ==3423==by 0x786ABD8: free_key_mem (dlerror.c:221)
> ==3423==by 0x786ABD8: __dlerror_main_freeres (dlerror.c:239)
> ==3423==by 0x7CA4667: __libc_freeres (in 
> /usr/lib/i386-linux-gnu/libc-2.28.so)
> ==3423==by 0x402D1DE: _vgnU_freeres (in 
> 

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Ok are you on IRC ? I am as rouca on #debian-js channel

Install the debug symbols of nodejs and libuv (if available) and try
to run valgrind with --smc-check=all --read-var-info=yes
--track-origins=yes



Bastien

Le lun. 20 sept. 2021 à 11:57, Ondrej Zary  a écrit :
>
> > And try to rebuild the whole libuv and nodejs with -fstack-protector-all
>
> Does not print anything other than Segmentation fault.
>
> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 10:39, Ondrej Zary  a écrit :
>
> > Ok now try to run the whole thing against valgrind...
> Seems that valgrind does not work with asan:
>
> $ LD_PRELOAD=/usr/lib/i386-linux-gnu/libasan.so.5.0.0 valgrind yarnpkg install
> ==752== Memcheck, a memory error detector
> ==752== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==752== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==752== Command: /usr/bin/yarnpkg install
> ==752==
> ==752==ASan runtime does not come first in initial library list; you should 
> either link runtime to your application or manually preload it with 
> LD_PRELOAD.
> ==752==
> ==752== HEAP SUMMARY:
> ==752== in use at exit: 0 bytes in 0 blocks
> ==752==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==752==
> ==752== All heap blocks were freed -- no leaks are possible
> ==752==
> ==752== For counts of detected and suppressed errors, rerun with: -v
> ==752== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> valgrind with clean libuv1 (no asan):
> runuser -u gitlab -- sh -c 'valgrind --trace-children=yes yarnpkg install'
> ==3163== Memcheck, a memory error detector
> ==3163== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==3163== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==3163== Command: /usr/bin/yarnpkg install
> ==3163==
> ==3163== Memcheck, a memory error detector
> ==3163== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==3163== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==3163== Command: /usr/bin/node /usr/bin/yarnpkg install
> ==3163==
> yarn install v1.13.0
> [1/5] Validating package.json...
> [2/5] Resolving packages...
> [3/5] Fetching packages...
> [---]
>  0/520==3163== Invalid read of size 4
> ==3163==at 0x4556B5B: node::fs::FSReqWrap::~FSReqWrap() (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3163==by 0x4547A42: node::fs::FSReqAfterScope::~FSReqAfterScope() (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3163==by 0x45484FD: node::fs::AfterInteger(uv_fs_s*) (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3163==by 0x556170F: uv__work_done (in 
> /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
> ==3163==by 0x55657FD: ??? (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
> ==3163==by 0x5575527: uv__io_poll (in 
> /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
> ==3163==by 0x55661C5: uv_run (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
> ==3163==by 0x4515C75: node::Start(v8::Isolate*, node::IsolateData*, 
> std::vector, 
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&, 
> std::vector, 
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&) (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3163==by 0x4513C96: node::Start(int, char**) (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3163==by 0x8049157: main (in /usr/bin/node)
> ==3163==  Address 0x1085 is not stack'd, malloc'd or (recently) free'd
> ==3163==
> ==3163==
> ==3163== Process terminating with default action of signal 11 (SIGSEGV)
> ==3163==  Access not within mapped region at address 0x1085
> ==3163==at 0x4556B5B: node::fs::FSReqWrap::~FSReqWrap() (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3163==by 0x4547A42: node::fs::FSReqAfterScope::~FSReqAfterScope() (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3163==by 0x45484FD: node::fs::AfterInteger(uv_fs_s*) (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3163==by 0x556170F: uv__work_done (in 
> /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
> ==3163==by 0x55657FD: ??? (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
> ==3163==by 0x5575527: uv__io_poll (in 
> /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
> ==3163==by 0x55661C5: uv_run (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
> ==3163==by 0x4515C75: node::Start(v8::Isolate*, node::IsolateData*, 
> std::vector, 
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&, 
> std::vector, 
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&) (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3163==by 0x4513C96: node::Start(int, char**) (in 
> /usr/lib/i386-linux-gnu/libnode.so.64)
> ==3163==by 0x8049157: main (in /usr/bin/node)
> ==3163==  If you believe this happened as a result of a stack
> ==3163==  overflow in your program's main thread (unlikely but
> ==3163==  possible), you can try to increase the size of the
> ==3163==  main thread stack using the --main-stacksize= flag.
> ==3163==  The main thread stack size used in this run was 8388608.
> ==3163== Invalid read of size 1
> ==3163==at 0x786A6A4: check_free (dlerror.c:189)
> ==3163==by 0x786ABD8: free_key_mem (dlerror.c:221)
> ==3163==by 0x786ABD8: 

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 10:20, Bastien ROUCARIES
 a écrit :
>
> Le lun. 20 sept. 2021 à 10:15, Ondrej Zary  a écrit :
> >
> > libuv libuv1:i386 1.24.1-1+deb10u1 with -fsanitize=address,undefined:
> >
> > yarn install v1.13.0
> > [1/5] Validating package.json...
> > [2/5] Resolving packages...
> > [3/5] Fetching packages...
> > [---]
> >  0/520AddressSanitizer:DEADLYSIGNAL
> > =
> > ==26662==ERROR: AddressSanitizer: SEGV on unknown address 0x1085 (pc 
> > 0xf695db5b bp 0xffd3adb8 sp 0xffd3ada4 T0)
> > ==26662==The signal is caused by a READ memory access.
> > #0 0xf695db5a in node::fs::FSReqWrap::~FSReqWrap() 
> > (/lib/i386-linux-gnu/libnode.so.64+0x50bb5a)
> > #1 0xf694ea42 in node::fs::FSReqAfterScope::~FSReqAfterScope() 
> > (/lib/i386-linux-gnu/libnode.so.64+0x4fca42)
> > #2 0xf694f4fd in node::fs::AfterInteger(uv_fs_s*) 
> > (/lib/i386-linux-gnu/libnode.so.64+0x4fd4fd)
> > #3 0xf629e32d in uv__work_done (/lib/i386-linux-gnu/libuv.so.1+0x5f32d)
> > #4 0xf62ad125  (/lib/i386-linux-gnu/libuv.so.1+0x6e125)
> > #5 0xf631e0a8 in uv__io_poll (/lib/i386-linux-gnu/libuv.so.1+0xdf0a8)
> > #6 0xf62b198c in uv_run (/lib/i386-linux-gnu/libuv.so.1+0x7298c)
> > #7 0xf691cc75 in node::Start(v8::Isolate*, node::IsolateData*, 
> > std::vector, 
> > std::allocator >, std::allocator > std::char_traits, std::allocator > > > const&, 
> > std::vector, 
> > std::allocator >, std::allocator > std::char_traits, std::allocator > > > const&) 
> > (/lib/i386-linux-gnu/libnode.so.64+0x4cac75)
> > #8 0xf691ac96 in node::Start(int, char**) 
> > (/lib/i386-linux-gnu/libnode.so.64+0x4c8c96)
> > #9 0x8049157 in main (/usr/bin/node+0x8049157)
> > #10 0xf3ac5b40 in __libc_start_main 
> > (/lib/i386-linux-gnu/libc.so.6+0x1ab40)
> > #11 0x80491c1 in _start (/usr/bin/node+0x80491c1)
> >
> > AddressSanitizer can not provide additional info.
> > SUMMARY: AddressSanitizer: SEGV 
> > (/lib/i386-linux-gnu/libnode.so.64+0x50bb5a) in 
> > node::fs::FSReqWrap::~FSReqWrap()
> > ==26662==ABORTING
> Ok now try to run the whole thing against valgrind...

Could you try to build both libuv and node with -fsanitize=null it is
likely a null dereference so catch it

Bastien
>
> Bastien
>
> >
> >
> > --
> > Ondrej Zary
> >
> > --
> > Pkg-javascript-devel mailing list
> > pkg-javascript-de...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 10:15, Ondrej Zary  a écrit :
>
> libuv libuv1:i386 1.24.1-1+deb10u1 with -fsanitize=address,undefined:
>
> yarn install v1.13.0
> [1/5] Validating package.json...
> [2/5] Resolving packages...
> [3/5] Fetching packages...
> [---]
>  0/520AddressSanitizer:DEADLYSIGNAL
> =
> ==26662==ERROR: AddressSanitizer: SEGV on unknown address 0x1085 (pc 
> 0xf695db5b bp 0xffd3adb8 sp 0xffd3ada4 T0)
> ==26662==The signal is caused by a READ memory access.
> #0 0xf695db5a in node::fs::FSReqWrap::~FSReqWrap() 
> (/lib/i386-linux-gnu/libnode.so.64+0x50bb5a)
> #1 0xf694ea42 in node::fs::FSReqAfterScope::~FSReqAfterScope() 
> (/lib/i386-linux-gnu/libnode.so.64+0x4fca42)
> #2 0xf694f4fd in node::fs::AfterInteger(uv_fs_s*) 
> (/lib/i386-linux-gnu/libnode.so.64+0x4fd4fd)
> #3 0xf629e32d in uv__work_done (/lib/i386-linux-gnu/libuv.so.1+0x5f32d)
> #4 0xf62ad125  (/lib/i386-linux-gnu/libuv.so.1+0x6e125)
> #5 0xf631e0a8 in uv__io_poll (/lib/i386-linux-gnu/libuv.so.1+0xdf0a8)
> #6 0xf62b198c in uv_run (/lib/i386-linux-gnu/libuv.so.1+0x7298c)
> #7 0xf691cc75 in node::Start(v8::Isolate*, node::IsolateData*, 
> std::vector, 
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&, 
> std::vector, 
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&) 
> (/lib/i386-linux-gnu/libnode.so.64+0x4cac75)
> #8 0xf691ac96 in node::Start(int, char**) 
> (/lib/i386-linux-gnu/libnode.so.64+0x4c8c96)
> #9 0x8049157 in main (/usr/bin/node+0x8049157)
> #10 0xf3ac5b40 in __libc_start_main 
> (/lib/i386-linux-gnu/libc.so.6+0x1ab40)
> #11 0x80491c1 in _start (/usr/bin/node+0x80491c1)
>
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV (/lib/i386-linux-gnu/libnode.so.64+0x50bb5a) 
> in node::fs::FSReqWrap::~FSReqWrap()
> ==26662==ABORTING
Ok now try to run the whole thing against valgrind...

Bastien

>
>
> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 12:02, Ondrej Zary  a écrit :

> I'm unable to compile node with -fsanitize=address,undefined. Seems that
> compiler hits 32-bit memory space limit:
> cc1plus: out of memory allocating 65536 bytes after a total of 3356393472
> bytes
>
Libuv only will be Nice

Node is not crosscompile safe so this is a dead end

>
> --
> Ondrej Zary
>

Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 08:02, Ondrej Zary  a écrit :
>
> Rebuilt Debian libuv1 1.24.1 with -fno-stack-protector - still segfaults.
> Rebuilt Debian libuv1 1.42.0 (from unstable) in Buster - still segfaults.
Please rebuild both nodejs and libuv with asan (adresse sanitizer)

After, I think it is time to escalade.

Bastien
> --
> Ondrej Zary

Bug#994678: [Pkg-javascript-devel] Bug#994678: Bug#994678: pkg-js-tools: MA status

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 06:03, Yadd  a écrit :

> Le 19/09/2021 à 12:35, Bastien Roucariès a écrit :
> > Package: pkg-js-tools
> > Version: 0.9.66
> > Severity: important
> >
> > Dear Maintainer,
> >
> > According to a few cross build test (see for instance
> > https://salsa.debian.org/js-team/node-re2/-/jobs/1960208)
> >
> > This package is a blocker.
> >
> > May be MA: same if possible will help here
>
> pkg-js-tools is arch:all. So this issue seems a duplicate
>

Sorry i mean ma: foreign

>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 21:57, Bastien ROUCARIES
 a écrit :
>
> try to pass
>  -fstack-protector-strong to the local version as cflags
>
> If it fail upstream does not take in acount stack protector
>
> Le dim. 19 sept. 2021 à 21:45, Bastien ROUCARIES
>  a écrit :
> >
> > Le dim. 19 sept. 2021 à 21:39, Bastien ROUCARIES
> >  a écrit :
> > >
> > > Le dim. 19 sept. 2021 à 21:36, Ondrej Zary  a écrit :
> > > >
> > > > I've reinstalled nodejs and libnode64 back to original Buster 
> > > > 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to 
> > > > libuv1_1.34.2-1~bpo9+1_i386.deb from http://snapshot.debian.org
> > > >
> > > > It still segfaults!
> > > >
> > > > So it seems that the problem is not libuv version but its linking 
> > > > (included in node or external). Or cflags?
> > > Or ldflags
> > >
> > > Could you dump the cflags/ldfalgs of both version?
> > Or sanatizer that avoid a free after use...
> >
> > We harden a lot on debian side
> >
> > Bastien
> > >
> > >
> > > >
> > > > --
> > > > Ondrej Zary

If it does work try to build both nodejs and libuv with
-fsanitize=address or other sanitizer option

Bastien

> > > > --
> > > > Pkg-javascript-devel mailing list
> > > > pkg-javascript-de...@alioth-lists.debian.net
> > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
> >
> > --
> > Pkg-javascript-devel mailing list
> > pkg-javascript-de...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

try to pass
 -fstack-protector-strong to the local version as cflags

If it fail upstream does not take in acount stack protector

Le dim. 19 sept. 2021 à 21:45, Bastien ROUCARIES
 a écrit :
>
> Le dim. 19 sept. 2021 à 21:39, Bastien ROUCARIES
>  a écrit :
> >
> > Le dim. 19 sept. 2021 à 21:36, Ondrej Zary  a écrit :
> > >
> > > I've reinstalled nodejs and libnode64 back to original Buster 
> > > 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to 
> > > libuv1_1.34.2-1~bpo9+1_i386.deb from http://snapshot.debian.org
> > >
> > > It still segfaults!
> > >
> > > So it seems that the problem is not libuv version but its linking 
> > > (included in node or external). Or cflags?
> > Or ldflags
> >
> > Could you dump the cflags/ldfalgs of both version?
> Or sanatizer that avoid a free after use...
>
> We harden a lot on debian side
>
> Bastien
> >
> >
> > >
> > > --
> > > Ondrej Zary
> > >
> > > --
> > > Pkg-javascript-devel mailing list
> > > pkg-javascript-de...@alioth-lists.debian.net
> > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 21:39, Bastien ROUCARIES
 a écrit :
>
> Le dim. 19 sept. 2021 à 21:36, Ondrej Zary  a écrit :
> >
> > I've reinstalled nodejs and libnode64 back to original Buster 
> > 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to 
> > libuv1_1.34.2-1~bpo9+1_i386.deb from http://snapshot.debian.org
> >
> > It still segfaults!
> >
> > So it seems that the problem is not libuv version but its linking (included 
> > in node or external). Or cflags?
> Or ldflags
>
> Could you dump the cflags/ldfalgs of both version?
Or sanatizer that avoid a free after use...

We harden a lot on debian side

Bastien
>
>
> >
> > --
> > Ondrej Zary
> >
> > --
> > Pkg-javascript-devel mailing list
> > pkg-javascript-de...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 21:36, Ondrej Zary  a écrit :
>
> I've reinstalled nodejs and libnode64 back to original Buster 
> 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to libuv1_1.34.2-1~bpo9+1_i386.deb 
> from http://snapshot.debian.org
>
> It still segfaults!
>
> So it seems that the problem is not libuv version but its linking (included 
> in node or external). Or cflags?
Or ldflags

Could you dump the cflags/ldfalgs of both version?


>
> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 21:25, Bastien ROUCARIES
 a écrit :
>
> Le dim. 19 sept. 2021 à 21:15, Ondrej Zary  a écrit :
> >
> > Added back --shared-zlib: works.
> > Added back also --shared-cares: works.
> >
> > So you're right: --shared-libuv is the problem.
> > Upstream seems to include libuv 1.34.2.
> > Buster has 1.24.1-1.
>
> Do you have valgrind ?
>
> If so and if it work (test first on good version), it smell like a use
> after free or a RAII violation
>
> I means, that libuv free a pointer, nodejs fill the buffer with code,
> then libuv free it. BOOOM.
>From libuv changelog
- * unix,win: fix `uv_fs_poll_stop()` when active (Anna Henningsen)
- * unix: fix race condition in uv_async_send() (Ben Noordhuis)

But I suppose it will be quicker to bissect by build/try the different
version of libuv...

Bastien

>
> > --
> > Ondrej Zary
> >
> > --
> > Pkg-javascript-devel mailing list
> > pkg-javascript-de...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 21:15, Ondrej Zary  a écrit :
>
> Added back --shared-zlib: works.
> Added back also --shared-cares: works.
>
> So you're right: --shared-libuv is the problem.
> Upstream seems to include libuv 1.34.2.
> Buster has 1.24.1-1.

Do you have valgrind ?

If so and if it work (test first on good version), it smell like a use
after free or a RAII violation

I means, that libuv free a pointer, nodejs fill the buffer with code,
then libuv free it. BOOOM.



> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#994720: [Pkg-javascript-devel] Bug#994720: nodejs: Please depends of sse2-support

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 21:03, Jérémy Lal  a écrit :
>
>
>> Le dim. 19 sept. 2021 à 22:33, Bastien Roucariès 
>>  a écrit :
>>
>> Source: nodejs
>> Severity: serious
>> Tags: patch
>> Justification: base arch
>> Forwarded: 
>> https://chromium.googlesource.com/v8/v8.git/+/e825c4318eb2065ffdf9044aa6a5278635c36427
>>
>> Dear Maintainer,
>>
>> libv8 need sse2 on i386 since 2017...
>>
>> I asked upstream better communication with us, but we must depends on
>> sse2-support
>>
>> Patch because I will fix on git asap I have a bug number.
>>
>
> [i386] sse2-support is already a dependency... but that fact has not made it 
> to buster.
Yes and b-d should also depends
>
> Jérémy

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 20:21, Ondrej Zary  a écrit :
>
> On Sunday 19 September 2021 20:13:47 Bastien ROUCARIES wrote:
> > Hi,
> >
> > So you work on oldstable.
> >
> > Could you check for stable/testing/unstable/experimental ? And mark
> > the bug with found /not found.
>
> Unfortunately I can't. I'm trying to get gitlab 11.11.8+dfsg-1+fto10+2 to 
> work. Then I can upgrade gitlab further to 12 and 13 and only then I can 
> upgrade Debian to bullseye.
>
> I've rebuilt Debian nodejs without --shared-zlib, --shared-cares and 
> --shared-libuv (remove them from debian/rules). It works now!
begin whith shared-uv

Bastien
>
> Going to narrow it down.
>
> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#994703: [Pkg-javascript-devel] Bug#994703: Bug#994703: nodejs: please documents deps or avoid it

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 19:33, Jérémy Lal  a écrit :
>
>
>
> Le dim. 19 sept. 2021 à 18:54, Bastien Roucariès 
>  a écrit :
>>
>> Package: nodejs
>> Version: 12.22.5~dfsg-2
>> Severity: serious
>>
>> Dear Maintainer,
>>
>> README.source should document the deps directory.
>>
>> It will be better to remove some libs from deps. Why libz is needed for node 
>> ?
>> Could we push this plugin stuff to libz and so on.
>>
>> Acorn embdeded should be fixed by recent version.
>>
>> openssl one is worry some..
>
>
> Hi,
>
> What's in ./deps/ is mostly not used for building node.
> It's pretty much obvious if you look at ./debian/rules configure flags.

Yes but README.Source is in this case good
>
> I believe it is not common practice to remove unused files, as long as it's 
> okay with DFSG.
Yes also
> That's why
> zlib, openssl, nghttp2, http-parser, uv, c-ares, brotli
> are kept around in ./deps/ directory.
>
> This is actually useful, it makes debugging against "upstream-like" builds 
> easier.

Yes but in order to be less worried about something in this huge code
base use these files, I will really prefer to move the deps dir before
configure or removing the -r bit in order to avoid something strange

I was hit ten years ago by some leaking hardcoded path on a project I
compiled, and I really prefer to be paraonoiac on this side

Bastien

> Jérémy
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 19:37, Jérémy Lal  a écrit :
>
>
>
> Le dim. 19 sept. 2021 à 20:18, Bastien ROUCARIES 
>  a écrit :
>>
>> Hi,
>>
>> So you work on oldstable.
>>
>> Could you check for stable/testing/unstable/experimental ? And mark
>> the bug with found /not found.
>>
>
> Interestingly, the copy of zlib in nodejs source has several patches that are 
> not
> in the official zlib release available in debian.
> So if what was said is correct (that upstream binary builds do not crash) 
> this might be a clue.

I was more thinking about a cflags like hardening flags or something
like this...

Bastien

> Jérémy

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Hi,

So you work on oldstable.

Could you check for stable/testing/unstable/experimental ? And mark
the bug with found /not found.

Thanks

Bastien

Le dim. 19 sept. 2021 à 18:03, Ondrej Zary  a écrit :
>
> There's no such patch in 10.24.0~dfsg-1~deb10u1
>
> --
> Ondrej Zary

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 17:40, Ondrej Zary  a écrit :
>
> Upstream node rebuilt in Debian works. So it's not a compiler or libc problem.

Does removing the debian patch
large_pages_assembly_gnu_stack.patch

Changes something ?

Bastien


> The Debian (buster) i386 version 10.24.0~dfsg-1~deb10u1 already contains SSE2 
> instructions - it does not work on Pentium 3:
> $ node
> Illegal instruction
>
> So I doubt that changing -march would help.
>
> --
> Ondrej Zary

Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 16:33, Ondrej Zary  a écrit :
>
> upstream (strings in bin/node), seems to be statically linked:
> gcc 6.3.1
> libc 2.17 according to https://github.com/nodejs/unofficial-builds/
> build log found at 
> https://unofficial-builds.nodejs.org/logs/202102231620-v10.24.0/x86.log
>
> Debian binary seems to be split into libnode64.
> gcc (Debian 8.3.0-6) 8.3.0
> libc6 2.28-10
>
> I'll try to build the upstream version in Debian.
Could you try aurel32 tips:
  rouca: it's not obviously linked to libc
[16:34]  rouca: about gcc, we have a very low ISA baseline on
i386 compared to what is usually used. Might be worth trying to
rebuild it with -march=pentium4 or something like that


Bastien

>
> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 15:48, Ondrej Zary  a écrit :
>
> Seems that only Debian i386 build of nodejs is broken.
>
> Downloaded 
> https://unofficial-builds.nodejs.org/download/release/v10.24.0/node-v10.24.0-linux-x86.tar.xz
> unpacked somewhere and edited /usr/bin/yarnpkg to point to the new bin/node
> added symlinks (dirty hack) so node can find both /usr/lib/nodejs and 
> /usr/share/nodejs:
> /node_modules -> /usr/share/nodejs
> /var/lib/gitlab/.node_libraries -> /usr/lib/nodejs
>
> yarnpkg completed without segfault!
Could you investigate:
- the libc used both upstream and debian side ?
- the gcc or compiler used with flags both side ?

Bastien

> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#994577: lintian: node-* arch:all package should depends on nodejs:any and b-d on nodejs:native

[Bastien ROUCARIES]

Le sam. 18 sept. 2021 à 16:57, Mattia Rizzolo  a écrit :

> (this reply is not related to lintian directly)
>
> On Fri, Sep 17, 2021 at 09:34:43PM +, Bastien Roucariès wrote:
> > In order to improve cross build of nodejs ecosystem, node-* arch:all
> package
> > should depends on nodejs:any and b-d on nodejs:native
>
> IMHO, you should make your tooling produce this "nodejs:any" binary
> dependency, instead of having each package have it manually listed in
> d/control (see ${perl:Depends} as an example, since, it's actually the
> very same thing, producing perl:any dependencies).
>

Bug already opened. Thanks for thé idea

>
> > Maybe this test should be restricted to ma: foreign package
>
> It shouldn't be IMHO.
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> More about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>

Bug#994603: errormsg

[Bastien ROUCARIES]

 debian/upstream

To fix the situation please do the following:
  1) Examine debian/copyright_* and referenced files
  2) Update debian/copyright as needed
  3) Replace debian/copyright_hints with debian/copyright_newhints
touch debian/stamp-copyright-check
touch debian/stamp-upstream-cruft
node-gyp configure
gyp info it worked if it ends with ok
gyp info using node-gyp@7.1.2
gyp info using node@12.22.5 | linux | x64
gyp info find Python using Python version 3.9.7 found at "/usr/bin/python3"
gyp info spawn /usr/bin/python3
gyp info spawn args [
gyp info spawn args   '/usr/share/nodejs/node-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',
gyp info spawn args   '/tmp/node-stringprep/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/usr/share/nodejs/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/usr/include/nodejs/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/usr/include/nodejs',
gyp info spawn args   '-Dnode_gyp_dir=/usr/share/nodejs/node-gyp',
gyp info spawn args
'-Dnode_lib_file=/usr/include/nodejs/<(target_arch)/node.lib',
gyp info spawn args   '-Dmodule_root_dir=/tmp/node-stringprep',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
gyp info ok
touch debian/stamp-node-gyp-configure
V=1  CC="cc"  CXX="g++"  CFLAGS="-g -O2
-ffile-prefix-map=/tmp/node-stringprep=. -fstack-protector-strong
-Wformat -Werror=format-security"  CXXFLAGS="-g -O2
-ffile-prefix-map=/tmp/node-stringprep=. -fstack-protector-strong
-Wformat -Werror=format-security"  CPPFLAGS="-Wdate-time
-D_FORTIFY_SOURCE=2"  LDFLAGS="-Wl,-z,relro -Wl,-z,now" \
node-gyp build
gyp info it worked if it ends with ok
gyp info using node-gyp@7.1.2
gyp info using node@12.22.5 | linux | x64
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
make[1] : on entre dans le répertoire « /tmp/node-stringprep/build »
  g++ -o Release/obj.target/node_stringprep/node-stringprep.o
../node-stringprep.cc '-DNODE_GYP_MODULE_NAME=node_stringprep'
'-DUSING_UV_SHARED=1' '-DUSING_V8_SHARED=1'
'-DV8_DEPRECATION_WARNINGS=1' '-DV8_DEPRECATION_WARNINGS'
'-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_LARGEFILE_SOURCE'
'-D_FILE_OFFSET_BITS=64' '-D__STDC_FORMAT_MACROS'
'-DBUILDING_NODE_EXTENSION' -I/usr/include/nodejs/include/node
-I/usr/include/nodejs/src -I/usr/include/nodejs/deps/openssl/config
-I/usr/include/nodejs/deps/openssl/openssl/include
-I/usr/include/nodejs/deps/uv/include -I/usr/include/nodejs/deps/zlib
-I/usr/include/nodejs/deps/v8/include -I../../../usr/share/nodejs/nan
-fPIC -pthread -Wall -Wextra -Wno-unused-parameter -m64 -fPIC -O3
-fno-omit-frame-pointer -fno-rtti -std=gnu++1y `pkg-config icu-i18n
--cflags` -MMD -MF
./Release/.deps/Release/obj.target/node_stringprep/node-stringprep.o.d.raw
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-ffile-prefix-map=/tmp/node-stringprep=. -fstack-protector-strong
-Wformat -Werror=format-security -c
../node-stringprep.cc:20:26: error: ‘Handle’ has not been declared
   20 |   static void Initialize(Handle target)
  |  ^~
../node-stringprep.cc:20:32: error: expected ‘,’ or ‘...’ before ‘<’ token
   20 |   static void Initialize(Handle target)
  |^
../node-stringprep.cc:154:5: warning: dynamic exception specifications
are deprecated in C++11 [-Wdeprecated]
  154 | throw(UnknownProfileException)
  | ^
../node-stringprep.cc: In static member function ‘static void
StringPrep::Initialize(int)’:
../node-stringprep.cc:28:5: error: ‘target’ was not declared in this scope
   28 | target->Set(Nan::New("StringPrep").ToLocalChecked(),
t->GetFunction());
  | ^~
../node-stringprep.cc:28:81: error: no matching function for call to
‘v8::FunctionTemplate::GetFunction()’
   28 | target->Set(Nan::New("StringPrep").ToLocalChecked(),
t->GetFunction());
  |
 ^
In file included from /usr/include/nodejs/src/node.h:67,
 from ../../../usr/share/nodejs/nan/nan.h:56,
 from ../node-stringprep.cc:1:
/usr/include/nodejs/deps/v8/include/v8.h:6126:46: note: candidate:
‘v8::MaybeLocal
v8::FunctionTemplate::GetFunction(v8::Local)’
 6126 |   V8_WARN_UNUSED_RESULT MaybeLocal GetFunction(
  |  ^~~
/usr/include/nodejs/deps/v8/include/v8.h:6126:46: note:   candidate
expects 1 argument, 0 provided
../node-stringprep.cc: In static member function ‘static
Nan::NAN_METHOD_RETURN_TYPE
StringPrep::New(Nan::NAN_METHOD_ARGS_TYPE)’:
../node-stringprep.cc:48:48: error: no matching function for call to

Bug#994571: lintian: please warn javascript package including .node files "*/nodejs/.*\.node$' and ma:foreign

[Bastien ROUCARIES]

Le ven. 17 sept. 2021 à 21:20, Felix Lechner
 a écrit :
>
> Hi,
>
> On Fri, Sep 17, 2021 at 1:39 PM Bastien Roucariès
>  wrote:
> >
> > Package that include "/usr/(?:lib|share)/(?:[^/]+/)?/nodejs/.*\.node$' are
> > arch:any package (include node plugin) and thus should be arch:any
>
> Thank you for this suggestion!
>
> The files in question are shipped in installable packages that do not
> contain the Arch:any designation. (It appears in d/control in the
> sources.) The installable architecture in DEBIAN/control is either the
> actual port or 'all'. Furthermore, I believe the wildcarded directory
> level before 'nodejs' must be a known multi-arch triplet.

yes it is
> Is it okay
> if Lintian instead requires that the multi-arch component of the file
> paths found matches the target architecture of the installable package
> in which they were shipped?
Yes it is

> If that is acceptable, Lintian already has checks to constrain the
> installation paths for shared libraries, although they may need to be
> expanded. (And we have to watch out for -cross packages.) Do you have
> candidates for examination besides node-iconv (which I found locally)
> that should trigger the condition?

I am fixing node-expat-expat that ship under /usr/lib/


> > Moreover in this case ma:foreign is a error (they are plugins)
>
> That will be addressed at the same time, although I am not yet sure how.

Thanks

> Kind regards
> Felix Lechner

Bug#994544: [Pkg-javascript-devel] Bug#994544: Bug#994544: npm2deb: nodejs:any for arch:all package

[Bastien ROUCARIES]

Le ven. 17 sept. 2021 à 20:24, Yadd  a écrit :
>
>
>
> Le 17 septembre 2021 21:30:16 GMT+02:00, Bastien ROUCARIES 
>  a écrit :
> >Le ven. 17 sept. 2021 à 16:06, Yadd  a écrit :
> >>
> >> Le 17/09/2021 à 16:36, Bastien Roucariès a écrit :
> >> > Package: npm2deb
> >> > Version: 0.3.0-6
> >> > Severity: important
> >> >
> >> > Dear Maintainer,
> >> >
> >> >
> >> > In order to help cross build nodejs depends should be nodejs:any for 
> >> > purejs
> >> > module in depends field.
> >> >
> >> > In build-depends field we should use nodejs:native in order to help 
> >> > crossbuilt
> >> >
> >> > Bastien
> >>
> >> Hi Bastien,
> >>
> >> you should clone this and reassign to pkg-js-tools (build depends on
> >> nodejs).
> >> npm2deb should not set a run dependency to nodejs except if there is a
> >> /usr/bin file
> >Not sure perl set perl:any on every package.
> >
> >It is sensible to do so
> >
> >Bastien
>
> A Perl file is usable only with Perl, not a JS one. We decided to remove 
> nodejs dependency some months ago.
Ok thanks look sensible nevertheless, nodejs:any is also sensible if needed.

Will open a lintian bug also
>
> Cheers,
> Yadd
>
> --
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
> brièveté.

Bug#994544: [Pkg-javascript-devel] Bug#994544: Bug#994544: npm2deb: nodejs:any for arch:all package

[Bastien ROUCARIES]

control: clone -1 -2
control: reassign -2 pkg-js-tools

Le ven. 17 sept. 2021 à 16:06, Yadd  a écrit :
>
> Le 17/09/2021 à 16:36, Bastien Roucariès a écrit :
> > Package: npm2deb
> > Version: 0.3.0-6
> > Severity: important
> >
> > Dear Maintainer,
> >
> >
> > In order to help cross build nodejs depends should be nodejs:any for purejs
> > module in depends field.
> >
> > In build-depends field we should use nodejs:native in order to help 
> > crossbuilt
> >
> > Bastien
>
> Hi Bastien,
>
> you should clone this and reassign to pkg-js-tools (build depends on
> nodejs).
> npm2deb should not set a run dependency to nodejs except if there is a
> /usr/bin file
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#994544: [Pkg-javascript-devel] Bug#994544: Bug#994544: npm2deb: nodejs:any for arch:all package

[Bastien ROUCARIES]

Le ven. 17 sept. 2021 à 16:06, Yadd  a écrit :
>
> Le 17/09/2021 à 16:36, Bastien Roucariès a écrit :
> > Package: npm2deb
> > Version: 0.3.0-6
> > Severity: important
> >
> > Dear Maintainer,
> >
> >
> > In order to help cross build nodejs depends should be nodejs:any for purejs
> > module in depends field.
> >
> > In build-depends field we should use nodejs:native in order to help 
> > crossbuilt
> >
> > Bastien
>
> Hi Bastien,
>
> you should clone this and reassign to pkg-js-tools (build depends on
> nodejs).
> npm2deb should not set a run dependency to nodejs except if there is a
> /usr/bin file
Not sure perl set perl:any on every package.

It is sensible to do so

Bastien

>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#994118: RFP: ocrodjvu3 -- Python 3 port of ocrodjvu (removed from bullseye)

[Bastien ROUCARIES]

Le dim. 12 sept. 2021 à 10:53, Janusz S. Bień  a
écrit :

> On Sun, Sep 12 2021 at  8:42 GMT, Bastien ROUCARIES wrote:
> > I can sponsor if needed but I am not upstream so we need to push patches
> >
> > And I will prefer that you do the packaging. I can help
>
> I appreciate your offer to be a sponsor and to help with packaging.
>
> However ocrodjvu used to be maintaned by Python Applications Packaging
> Team and Daniel Stender (QA Page). Perhaps they will package also your
> port?
>

It is not a port but a patch... I am still wainting merge from upstream.
But we could package downstream (debian side)

Debian is a docratie. Si ask directly to Daniel with me in cc

Bastien

> Best regards
>
> Janusz
>
> --
>  ,
> Janusz S. Bien
> emeryt (emeritus)
> https://sites.google.com/view/jsbien
>

Bug#994118: RFP: ocrodjvu3 -- Python 3 port of ocrodjvu (removed from bullseye)

[Bastien ROUCARIES]

I can sponsor if needed but I am not upstream so we need to push patches

And I will prefer that you do the packaging. I can help

Bastien

Le dim. 12 sept. 2021 à 06:42, Janusz S. Bień  a écrit :
>
> Package: wnpp
> Severity: wishlist
>
> * Package name: ocrodjvu3
>   Version :
>   Upstream Author : Jakub Wilk and Bastien Roucari`es
> * URL or Web page : https://github.com/bastien-roucaries/ocrodjvu
> * License : GNU General Public License v2.0
>   Description : Python 3 port of ocrodjvu
>
> --
>  ,
> Janusz S. Bien
> emeryt (emeritus)
> https://sites.google.com/view/jsbien
>

Bug#743694: lintian: Downgrade most of privacy-breach* tags from severity: error to pedantic

[Bastien ROUCARIES]

Le ven. 10 sept. 2021 à 11:06, Felix Lechner
 a écrit :
>
> Hi,
>
> > The severity chosen for these tags/checks is not justified by any of our
> > policies, neither the Debian policy, not the best packaging practises nor
> > any legal reason!
> >
> > There is no technical nor social justification for this severity.
> >
> > making our package compliant to this new privacy-policy doesn't add
> > any value to our users.
>
> I believe Debian users have a reasonable expectation to read static
> files on their own storage media without being monitored. That
> objection is based on my own everyday experience in working to improve
> Debian, the Golden rule [2] and item #4 of Debian's social contract
> ("Our priorities are our users"). [2]
>
> The legal landscape is also changing. At least Europe and California
> have seen shifts toward greater privacy protections for consumers
> since the bug was filed.
>
> [1] https://en.wikipedia.org/wiki/Golden_Rule
> [2] https://www.debian.org/social_contract
>
> > I simply morally disagree with removing donation requests from authors
>
> It is not the solicitation but the unexpected loading of network
> resources that violates privacy expectations. Many micro-donation
> services offer resources like images or active HTML components to
> evoke feelings of familiarity or goodwill. That allows them to see who
> is using which software, and who chooses not to donate. While such
> gamesmanship may be common while browsing online (there are tools to
> fight it [3][4]) it is unexpected when browsing static files located
> on one's own storage media.
>
> Another, more generalized solution could be to modify all browsers
> shipped in Debian so they do not load online resources without
> confirmation. Unfortunately, that separates the solution from the
> problems. It is more reliable to address the privacy breaches where
> they occur, i.e. in the affected files.
>
> There is no issue with authors requesting donations (or even with
> Debian promoting such requests, for example in package metadata). The
> moral charge that Lintian's privacy expectations starve authors is not
> reasonable. The request just has to be made without unexpectedly
> loading online resources.
>
> [3] https://privacybadger.org/
> [4] https://noscript.net/
>
> > I find it unacceptable that the burden to make packages "privacy"-
> > compliant to some users is put on the shoulders of myself and fellow DDs.
>
> Lintian already reduces the workload by locating the issues for
> maintainers. (We hope that most of our tags do that.) As for the
> actual burden, the task of creating patches that drop lines from
> upstream files is well within the capabilities of any DD with upload
> privileges. The burden is not unreasonable.
>
> I will likely close this bug without action.
>
> Please reply to Bug#743694 if your response concerns Lintian's
> treatment of privacy breaches. Thanks!
>
> Kind regards
> Felix Lechner
Note that I am working on a dh_fixhtml helper to automate the cleaning
of privacy breach.

Bastien

Bug#993662: lintian: Please warn for source file that have This file was autogenerated or DO NOT EDIT BY HAND

[Bastien ROUCARIES]

control: tag -1 + patch

Le sam. 4 sept. 2021 à 15:27, Chris Lamb  a écrit :
>
> tags 993662 - patch
> thanks
>
> Hi Bastien,
>
> > Doing some code review on mozilla I found this interesting file
> > https://sources.debian.org/src/firefox-
> > esr/78.13.0esr-1/js/src/frontend/BinASTEnum.h/?hl=1#L1
> >
> > // This file was autogenerated by binjs_generate_spidermonkey,
> > // please DO NOT EDIT BY HAND.
>
> Interesting idea. But files with contents such as these aren't a
> problem in themselves. A problem only arises, at least from an
> ftpmaster point of view, when there isn't the corresponding, say,
> binjs_generate_spidermonkey script. (Imagine a long debate about
> "corresponding source code" here; better held elsewhere.)
>
> So, unless I'm missing something, I don't think this is something
> Lintian should warn about, at any severity level.
like other autogenerated a pedantic tag will help here
see for instance here
https://lintian.debian.org/tags/source-contains-prebuilt-javascript-object
or even like
https://lintian.debian.org/tags/very-long-line-length-in-source-file


I agree with your diagnostic, but in fact:
1. best packaging practice is to convince upstream to remove this file
and rebuild from source
2. good packaging pratice is to repack with a +ds suffix, in order to
be robust and rebuild all the time
3. a lintian tag will be a strong remainder to check manually this
file, repack or even add a lintian override thus a documentation why
it is not important for DFSG.

I really prefer to have a tag, ftpmaster is a bottlenet more than
maintainer time, so every little bit piece of documentation and help
is I think welcome here.

A pedantic time is just the right level for this kind of stuff...





>
> > Tags: patch
>
> (I assume this was a mistake, rather than you missing an attachment?
> Feel free to revert if necessary.)
Here
https://salsa.debian.org/lintian/lintian/-/merge_requests/366
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org  chris-lamb.co.uk
>`-

Bug#907336: still relevant? revert?

[Bastien ROUCARIES]

Le mer. 1 sept. 2021 à 08:21, Tomas Pospisek  a écrit :
>
> Dear ImageMagick Packaging Team,
>
> Short version: is it safe today to reenable PDF/PS conversion again these
> days?
>
> Long version:
>
> Today I was affected by the problem reported in [1], notably:
>
>  convert: attempt to perform an operation not allowed by the security
>  policy `PDF' @ error/constitute.c/IsCoderAuthorized/408.
>
> When I check /etc/ImageMagick-6/policy.xml I see that plenty of
> conversions to/from (?) PDF/(E)PS* are apparently disabled by default as
> delivered by Debian. Which actually covers part of the requests in this
> (#907336) bugreport.
>
> The mentioned stackoverflow Q however mentions that:
>
> > Make sure ghostscript is updated kb.cert.org/vuls/id/332928
>
> Which refers to a fix in Ghostscript 9.24 which is ages ago when compared
> to the Ghostscript version 9.53 currently in Debian stable.
>
> I have *zero* insight into the issues leading to PDF/PS conversion being
> disabled in Debian and if they still are relevant and still are of
> the same concern as they were at the times before Ghostscript 9.24.
>
> Or posed differently: does it make sense to reevaluate these issues and -
> if it turns out they are of no concern any more today - could the
> respective converters be re-enabled by default again?

No it will not renable by default.

The best will be to have a debconf question and let the user accept the risk.

Postscript is turing complete so it is easy to do a DOS. it should be documented

Patch welcome


Bastien

> Thanks a lot for maintaining ImageMagick! Greetings,
> *t
>
> [1] 
> https://stackoverflow.com/questions/52998331/imagemagick-security-policy-pdf-blocking-conversion
>

Bug#929825: Version 7 available upstream

[Bastien ROUCARIES]

Hi,

A lot:
- command line API is not fully compatible with v6
- I am trying to push latest v6, but it is blocked in NEWS and need a transition

I plan imagemagick7 to sit in experimental in parallel with
imagemagick6 at least before stabilazing

Could you help to triage bug, and fix security issue in v6 ? It will
help me and allow me to concentrate in v6->v7 transition

Bastien

Le mar. 31 août 2021 à 08:24, Johannes Schauer Marin Rodrigues
 a écrit :
>
> Hi,
>
> Quoting Bastien ROUCARIES (2021-08-28 11:44:08)
> > Le lun. 23 août 2021 à 22:48, Johannes Schauer Marin Rodrigues 
> >  a écrit :
> > > this bug affects my package img2pdf, so I wanted to send a friendly ping.
> > > What is the status of packaging the next version of imagemagick? Do you
> > > need help
> > Yes i nées help here. Ping me monday please
>
> what is your status? Where is work needed?
>
> Thanks!
>
> cheers, josch

Bug#990062: /usr/bin/mogrify-im6.q16: IO error writing tag data when processing tiff file

[Bastien ROUCARIES]

Le sam. 19 juin 2021 à 02:15, Brian May  a écrit :

> Package: imagemagick-6.q16
> Version: 8:6.9.11.60+dfsg-1.3
> Severity: important
> File: /usr/bin/mogrify-im6.q16
>
>
> $ mogrify -verbose -write /dev/null
> /home/brian/photos/images/orig/1990/04/01/flood001.tif
> /home/brian/photos/images/orig/1990/04/01/flood001.tif TIFF 6639x3984
> 6639x3984+0+0 8-bit TrueColor sRGB 75.6736MiB 0.080u 0:00.713
> /home/brian/photos/images/orig/1990/04/01/flood001.tif=>/dev/null TIFF
> 6639x3984 6639x3984+0+0 8-bit TrueColor sRGB 0.050u 0:00.046
> /home/brian/photos/images/orig/1990/04/01/flood001.tif=>/dev/null TIFF
> 6639x3984 6639x3984+0+0 8-bit TrueColor sRGB 0.040u 0:00.045
> mogrify-im6.q16: IO error writing tag data. `TIFFWriteDirectoryTagData' @
> error/tiff.c/TIFFErrors/606.
>
> Doing a Google search, I get this result from 2016. Not sure if it is
> the same issue or not.
>
> https://github.com/dlemstra/Magick.NET/issues/26



Whitout source image it is hard to say...

Please join source images

Bastien

>
>
> -- Package-specific info:
> ImageMagick program version
> ---
> animate:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25
> https://imagemagick.org
> compare:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25
> https://imagemagick.org
> convert:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25
> https://imagemagick.org
> composite:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25
> https://imagemagick.org
> conjure:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25
> https://imagemagick.org
> display:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25
> https://imagemagick.org
> identify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25
> https://imagemagick.org
> import:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25
> https://imagemagick.org
> mogrify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25
> https://imagemagick.org
> montage:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25
> https://imagemagick.org
> stream:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25
> https://imagemagick.org
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.0-7-amd64 (SMP w/20 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages imagemagick-6.q16 depends on:
> ii  hicolor-icon-theme 0.17-2
> ii  libc6  2.31-12
> ii  libmagickcore-6.q16-6  8:6.9.11.60+dfsg-1.3
> ii  libmagickwand-6.q16-6  8:6.9.11.60+dfsg-1.3
>
> Versions of packages imagemagick-6.q16 recommends:
> ii  ghostscript  9.53.3~dfsg-7
> ii  libmagickcore-6.q16-6-extra  8:6.9.11.60+dfsg-1.3
> ii  netpbm   2:10.0-15.4
>
> Versions of packages imagemagick-6.q16 suggests:
> pn  autotrace   
> pn  cups-bsd | lpr | lprng  
> ii  curl7.74.0-1.2
> pn  enscript
> ii  ffmpeg  7:4.3.2-0+deb11u2
> ii  gimp2.10.22-4
> pn  gnuplot 
> pn  grads   
> ii  graphviz2.42.2-5
> ii  groff-base  1.22.4-6
> pn  hp2xx   
> pn  html2ps 
> pn  imagemagick-doc 
> pn  libwmf-bin  
> ii  mplayer 2:1.4+ds1-1
> pn  povray  
> pn  radiance
> ii  sane-utils  1.0.31-4
> pn  texlive-base-bin
> pn  transfig
> pn  ufraw-batch 
> ii  xdg-utils   1.1.3-4.1
>
> -- debconf-show failed
>
>

Bug#929825: Version 7 available upstream

[Bastien ROUCARIES]

Le lun. 23 août 2021 à 22:48, Johannes Schauer Marin Rodrigues <
jo...@debian.org> a écrit :

> Hi,
>
> this bug affects my package img2pdf, so I wanted to send a friendly ping.
> What
> is the status of packaging the next version of imagemagick? Do you need
> help
>

Yes i nées help here. Ping me monday please

Bastien

>
> Thanks!
>
> cheers, josch

Bug#992150:

[Bastien ROUCARIES]

control: reassign -1 src:firefox-esr

Bug#992150: Please allow symlink in system extension

[Bastien ROUCARIES]

Followup-For: Bug #992150
Control: clone -1 -2
Control: assign -1 src:firefox-esr

Bug#992024: ITP: airsane -- SANE WebScan frontend that supports Apple's AirScan protocol

[Bastien ROUCARIES]

Le jeu. 12 août 2021 à 15:22, Didier 'OdyX' Raboud  a
écrit :

> Le lundi, 9 août 2021, 11.48:09 h CEST Bastien Roucariès a écrit :
> > Package: wnpp
> > Severity: wishlist
> > Owner: Bastien Roucariès 
> > X-Debbugs-Cc: debian-de...@lists.debian.org
> >
> > * Package name: airsane
> >   Version : 0.3.2
> >   Upstream Author : Simul Piscator
> > * URL : https://github.com/SimulPiscator/AirSane
> > * License : GPL3
> >   Programming Lang: C++
> >   Description :  SANE WebScan frontend that supports Apple's AirScan
> > protocol
> >
> >  SANE WebScan frontend that supports Apple's AirScan protocol. Scanners
> are
> > detected automatically, and published through mDNS. Acquired images may
> be
> > transferred in JPEG, PNG, and PDF/raster format.
> >
> > AirSane's intended purpose is to be used with AirScan/eSCL clients such
> as
> > Apple's Image Capture, but a simple web interface is provided as well.
>
> How does this compare with https://github.com/alexpevzner/sane-airscan/ /
> src:sane-airscan? Client vs Server?
>
Yes it is the server. I plan to package it in order to offer secure
scanning over network instead of insecure firmware

>
> Best,
>
> --
> OdyX

Bug#981171: [PATCH 06/13] Improve pager section by pointing to more

[Bastien ROUCARIES]

Le ven. 29 janv. 2021 à 12:28, Michael Kerrisk (man-pages)
 a écrit :
>
> On Fri, 29 Jan 2021 at 12:00, Bastien Roucariès
>  wrote:
> >
> > Le jeudi 28 janvier 2021, 09:31:00 UTC Michael Kerrisk (man-pages) a écrit :
> > > On 1/27/21 4:48 PM, roucaries.bast...@gmail.com wrote:
> > > > From: Bastien Roucariès 
> > > >
> > > > More is the default pager in a lot of system mention it
> > >
> > > Really "more" and not "less"?
> >
> > Yes, debian distribution have been patched to fallback to pager that is less
> > by default. But it is not the standard
>
> I use Fedora. The default is "less" on the applications I looked at.
> When you say "it is not the standard", can you say more precisely what
> you mean?

According to POSIX mailx manual:
PAGER
Determine a string representing an output filtering or pagination
command for writing the output to the terminal. Any string acceptable
as a command_string operand to the sh -c command shall be valid. When
standard output is a terminal device, the message output shall be
piped through the command if the mailx internal variable crt is set to
a value less the number of lines in the message; see Internal
Variables in mailx. If the PAGER variable is null or not set, the
paginator shall be either more or another paginator utility documented
in the system documentation. The effects of this variable are
unspecified if the User Portability Utilities option is not supported.

So it is up to the distribution to use less,
>
> Thanks,
>
> Michael
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/

Bug#981171: [PATCH 13/13] Document LINES and COLUMNS

[Bastien ROUCARIES]

Hi,

Le jeu. 28 janv. 2021 à 08:53, Michael Kerrisk (man-pages)
 a écrit :
>
> Hello Bastiern,
>
> On 1/27/21 4:48 PM, roucaries.bast...@gmail.com wrote:
> > From: Bastien Roucariès 
> >
> > Document the variable LINES and COLUMN
> >
> > Signed-off-by: Bastien Roucariès 
> > ---
> >  man7/environ.7 | 45 ++---
> >  1 file changed, 42 insertions(+), 3 deletions(-)
> >
> > diff --git a/man7/environ.7 b/man7/environ.7
> > index b461e93df..5665ac4d2 100644
> > --- a/man7/environ.7
> > +++ b/man7/environ.7
> > @@ -241,6 +241,48 @@ environment variables.
> >  The following variables are commonly used for personalizing
> >  applications used by the user.
> >  .TP
> > +.B COLUMNS
>
> The following text is copied almost word for word from the standard.
> For copyright reasons, we can't do that.
>
> > +This variable is a non-negative decimal integer used to indicate the 
> > user's preferred width
> > +in column positions for the terminal screen or window.
> > +If this variable is unset, set to zero, or empty, applications will
>
> How did you determine the bit about 'set to zero'? That's
> not mentioned in the standard?

Ok that was a research on sources.debian.org. I will mention on notes

Bastien

>
> Similar comments to the above, for LINES, below.
>
> Thanks,
>
> Michael
>
>
> > +determine the appropriate value themselves.
> > +When the
> > +.B COLUMNS
> > +environment variable
> > +is set, any terminal-width information implied by the
> > +.B TERM
> > +environment variable is overridden.
> > +.IP
> > +Users and applications should not set
> > +.B COLUMNS
> > +unless they wish to override the system selection.
> > +In this case, applications may produce output unrelated to the terminal 
> > characteristics.
> > +Users should not need to set this variable in the environment unless
> > +there is a specific reason to override the implementation's default 
> > behavior,
> > +such as to display data in an area arbitrarily smaller than the terminal 
> > or window.
> > +.TP
> > +.B LINES
> > +This variable is a non-negative decimal integer used to indicate the 
> > user's preferred
> > +number of lines for the terminal screen or window.
> > +If this variable is unset, set to zero, or empty, applications will
> > +determine the appropriate value themselves.
> > +When the
> > +.B LINES
> > +environment variable
> > +is set, any terminal-width information implied by the
> > +.B TERM
> > +environment variable is overridden.
> > +.IP
> > +As for the related variable
> > +.B COLUMNS,
> > +users and applications should not set
> > +.B LINES
> > +unless they wish to override the system selection.
> > +In this case, applications may produce output unrelated to the terminal 
> > characteristics.
> > +Users should not need to set this variable in the environment unless
> > +there is a specific reason to override the implementation's default 
> > behavior,
> > +such as to display data in an area arbitrarily smaller than the terminal 
> > or window.
> > +.TP
> >  .B PAGER
> >  The user's preferred utility to display text files.
> >  Any string acceptable as a command_string operand to the
> > @@ -307,9 +349,6 @@ See also
> >  gives information on how to address a given terminal
> >  (or gives the name of a file containing such information).
> >  .IP *
> > -.BR COLUMNS " and " LINES
> > -tell applications about the window size, possibly overriding the actual 
> > size.
> > -.IP *
> >  .BR PRINTER " or " LPDEST
> >  may specify the desired printer to use.
> >  See
> >
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/

Bug#981171: [PATCH 04/13] Document PATH resolution

[Bastien ROUCARIES]

Yes, you are right.

Le jeu. 28 janv. 2021 à 09:25, Michael Kerrisk (man-pages)
 a écrit :
>
> Hello Bastien,
>
> On 1/27/21 4:48 PM, roucaries.bast...@gmail.com wrote:
> > From: Bastien Roucariès 
> >
> > Document PATH resolution, particularly null sequence and empty PATH
> >
> > Signed-off-by: Bastien Roucariès 
> > ---
> >  man7/environ.7 | 42 ++
> >  1 file changed, 34 insertions(+), 8 deletions(-)
> >
> > diff --git a/man7/environ.7 b/man7/environ.7
> > index 8fc26bb92..11f30c332 100644
> > --- a/man7/environ.7
> > +++ b/man7/environ.7
> > @@ -68,7 +68,8 @@ The name of the logged-in user (used by some BSD-derived 
> > programs).
> >  Set at login time, see section NOTES below.
> >  .TP
> >  .B LOGNAME
> > -The name of the logged-in user (used by some System-V derived programs).
> > +The name of the logged-in user (used by some System-V derived programs
> > +and POSIX.1-2017).
>
> Please don't include unrelated changes in the same patch.
>
> >  Set at login time, see section NOTES below.
> >  .TP
> >  .B HOME
> > @@ -94,19 +95,27 @@ for further details of the
> >  environment variables).
> >  .TP
> >  .B PATH
> > -The sequence of directory prefixes that
> > -.BR sh (1)
> > -and many other
> > -programs apply in searching for a file known by an incomplete pathname.
> > -The prefixes are separated by \(aq\fB:\fP\(aq.
> > -(Similarly one has
> > +The list of places that shells and other programs look in to find
> > +a command when given an incomplete pathname. Elements on this
> > +colon-separated  (\(aq\fB:\fP\(aq) list may be absolute or relative 
> > directory
> > +names or the zero-length string (interpreted as meaning the
> > +current directory, see section BUGS below).
> > +.B PATH
> > +is checked element by element (left to right), applying that directory
> > +name as a prefix to the pathname (if it does not already
> > +end in a slash, the expansion will insert one between
> > +the prefix and the filename),
> > +until a file is found with the appropriate name and execution
> > +permissions.
> > +.IP
> > +Similarly one has
> >  .B CDPATH
> >  used by some shells to find the target
> >  of a change directory command,
> >  .B MANPATH
> >  used by
> >  .BR man (1)
> > -to find manual pages, and so on)
> > +to find manual pages, and so on.
> >  .TP
> >  .B PWD
> >  The current working directory.
> > @@ -254,6 +263,9 @@ and
> >  are specified by
> >  POSIX.1-1996
> >  and should be reasonably portable.
> > +.PP
> > +.B PATH
> > +behavior is specified by  POSIX.1-2017.
>
> When you write this, it implies that the behavior was not specified
> in earlier in earlier versions of POSIX. Is that true?
>
> >  .SH NOTES
> >  The
> >  .BR prctl (2)
> > @@ -292,6 +304,12 @@ preserves all the variables from the existing shell, 
> > and
> >  or
> >  .I su -l
> >  is the recommended way of getting a full root environment.
> > +.PP
> > +The default search path (used when the environment
> > +does not contain the variable \fBPATH\fR)
> > +shows some variation across systems. See
> > +.B execlp (3)
> > +for documentation of the exact behavior.
> >  .SH BUGS
> >  Clearly there is a security risk here.
> >  Many a system command has been
> > @@ -330,6 +348,13 @@ The authors of
> >  .I gzip
> >  should consider renaming their option to
> >  .BR GZIP_OPT .
> > +.PP
> > +A zero-length element in
> > +.B PATH,
> > +which appears as two adjacent colons \(aq\fB::\fP\(aq or as a leading
> > +or trailing colon on the list, is replaced by implicit \(aq\fB.\fP\(aq.
> > +In order to be portable and strictly conformant to POSIX.1-2017, a user
> > +should use instead an explicit \(aq\fB.\fP\(aq.
> >  .SH SEE ALSO
> >  .BR bash (1),
> >  .BR csh (1),
> > @@ -343,6 +368,7 @@ should consider renaming their option to
> >  .BR execve (2),
> >  .BR clearenv (3),
> >  .BR exec (3),
> > +.BR execlp (3),
>
> I think this line isn't needed. You mention execlp(3) already above.
>
> >  .BR getenv (3),
> >  .BR putenv (3),
> >  .BR setenv (3),
>
> I generally like the idea of this patch, but I can't apply it
> because of
> (a) My first comment above
> (b) It depends on earlier patches that I havne't applied.
>
> Thanks,
>
> Michael
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/

Bug#981171: [PATCH 03/13] Document that means at login time for HOME, LOGNAME, SHELL, USER

[Bastien ROUCARIES]

Le jeu. 28 janv. 2021 à 08:24, Michael Kerrisk (man-pages)
 a écrit :
>
> Hello Bastien,
>
> On 1/27/21 4:48 PM, roucaries.bast...@gmail.com wrote:
> > From: Bastien Roucariès 
> >
> > Clearly document that su by default does not change this variables.
>
> I'm dubious about this. The place that this should be (and is)
> properly documented is the manual page for su(1). Why repeat it
> here?

Ok for the su part. But the at login time should be documented. It is
not documented on debian documentation
where lie the responsability for setting this variables.

As a young debian developper I was burned by su a few time. But a
pointer to documentation of su should sufficient I agree.
Something like Note that behavior of su could lead to a mixed environment.

Thanks will redo

Bastien
>
> Thanks,
>
> Miuchael
>
> > Signed-off-by: Bastien Roucariès 
> > ---
> >  man7/environ.7 | 41 +
> >  1 file changed, 37 insertions(+), 4 deletions(-)
> >
> > diff --git a/man7/environ.7 b/man7/environ.7
> > index ec886d83d..8fc26bb92 100644
> > --- a/man7/environ.7
> > +++ b/man7/environ.7
> > @@ -65,15 +65,15 @@ Common examples are:
> >  .TP
> >  .B USER
> >  The name of the logged-in user (used by some BSD-derived programs).
> > +Set at login time, see section NOTES below.
> >  .TP
> >  .B LOGNAME
> >  The name of the logged-in user (used by some System-V derived programs).
> > +Set at login time, see section NOTES below.
> >  .TP
> >  .B HOME
> > -A user's login directory, set by
> > -.BR login (1)
> > -from the password file
> > -.BR passwd (5).
> > +A user's login directory.
> > +Set at login time, see section NOTES below.
> >  .TP
> >  .B LANG
> >  The name of a locale to use for locale categories when not overridden
> > @@ -114,6 +114,7 @@ Set by some shells.
> >  .TP
> >  .B SHELL
> >  The absolute pathname of the user's login shell.
> > +Set at login time, see section NOTES below.
> >  .TP
> >  .B TERM
> >  The terminal type for which output is to be prepared.
> > @@ -260,6 +261,37 @@ The
> >  and
> >  .B PR_SET_MM_ENV_END
> >  operations can be used to control the location of the process's 
> > environment.
> > +.PP
> > +The
> > +.B HOME,
> > +.B LOGNAME,
> > +.B SHELL
> > +and
> > +.B USER
> > +variables are set from a user database (such as the
> > +.B password (5)
> > +database) only when when a user is changed using the
> > +session management interface, for instance by the
> > +.B login(1)
> > +program.
> > +In particular, the
> > +.B setuid (2)
> > +family of functions does not set these variables.
> > +Note that as documented in
> > +.B su (1),
> > +getting a root shell with just the command
> > +.I su
> > +results in a mixed environment where
> > +.B LOGNAME
> > +and
> > +.B USER
> > +are retained from the old user. Using
> > +.I su -p
> > +preserves all the variables from the existing shell, and
> > +.I su -
> > +or
> > +.I su -l
> > +is the recommended way of getting a full root environment.
> >  .SH BUGS
> >  Clearly there is a security risk here.
> >  Many a system command has been
> > @@ -306,6 +338,7 @@ should consider renaming their option to
> >  .BR mktemp (1),
> >  .BR printenv (1),
> >  .BR sh (1),
> > +.BR su (1),
> >  .BR tcsh (1),
> >  .BR execve (2),
> >  .BR clearenv (3),
> >
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/

Bug#981171: [PATCH 01/13] Do not document mktemp (3)

[Bastien ROUCARIES]

Hi,
Le mer. 27 janv. 2021 à 22:28, Michael Kerrisk (man-pages)
 a écrit :
>
> Salut Bastien,
>
> On 1/27/21 4:48 PM, roucaries.bast...@gmail.com wrote:
> > From: Bastien Roucariès 
> >
> > Do not use for documentation purposes the unsecure mktemp function
>
> This message doesn't correspond to the change below (which removes
> a reference to "tempnam" and adds a reference to "mktemp".

ok
>
> But also, I don't think it makes systems more secure to
> remove the info that tempnam is influence by TMPDIR.

Yes but not documenting obsolete due to insecurity is better from a
user point of view experience.
I believe that manpage of insecure function should not be cited for
documentation purposes (I am a uni teacher and experiment every days
the
bad example uses in teaching)
> And, this patch is surely not correct. Yes, TMPDIR influences
> tmpfile(3). But how does TMPDIR influence mktemp(3), mkstemp(3),
> and mkdtemp(3), which base the temporary filename on a path
> supplied by the caller?
I am sorry
mkstemp does not need a file path, it need a template. Path is not
supplied by the caller.
The mkstemp manpage may be improved. Do you want a patch for it ?

File name are implementation dependend and path is $TMPDIR
>
> Finally, a request for patches: the format of the
> subject line should rather be:
>
> [PATCH ...] environ.7: Do not document...
Ok will do

Will redo this patch
>
> Thanks,
>
> Michael
>
> > Signed-off-by: Bastien Roucariès 
> > ---
> >  man7/environ.7 | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/man7/environ.7 b/man7/environ.7
> > index 182d823d2..d889310d6 100644
> > --- a/man7/environ.7
> > +++ b/man7/environ.7
> > @@ -191,7 +191,10 @@ and
> >  .IP *
> >  .B TMPDIR
> >  influences the path prefix of names created by
> > -.BR tempnam (3)
> > +.BR mktemp (1),
> > +.BR mkstemp (3),
> > +.BR mkdtemp (3),
> > +.BR tmpfile (3),
> >  and other routines, and the temporary directory used by
> >  .BR sort (1)
> >  and other programs.
> > @@ -289,6 +292,7 @@ should consider renaming their option to
> >  .BR csh (1),
> >  .BR env (1),
> >  .BR login (1),
> > +.BR mktemp (1),
> >  .BR printenv (1),
> >  .BR sh (1),
> >  .BR tcsh (1),
> >
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/

Bug#980876: More information

[Bastien ROUCARIES]

Hi,

BTW -c should be better documented as in bash mentioning the first non
option arguments:
 -cIf the -c option is present, then commands are read from
the first non-option argument command_string.  If there are arguments
after the command_string,

Bug#980202: FTBFS: gscan2pdf tests fail

[Bastien ROUCARIES]

Hi,

Just uploaded 6.9.11-58 as suggested by upstream.

No changes unfortunately

Bastien

Le ven. 22 janv. 2021 à 19:30, Cristy  a écrit :
>
> Subject "convert fails to create image with text" claims
>
> convert +matte -depth 1 -colorspace Gray -pointsize 12 -units PixelsPerInch 
> -density 300 label:"The quick brown fox" test.png
>
> returns unexpected results. We tried the command with ImageMagick 6.9.11-58 
> and get expected results under Fedora 33 and Debian 4.19.160-2 I686. Can you 
> try -58 on your system? Do you get expected results (test-old.png from bug 
> report)?
>
> Thanks,
>
> ImageMagick Development Team

Bug#979942: [Pkg-javascript-devel] Bug#979942: Bug#979942: Bug#979942: embedding dead code is no fix to bug for removing that same dead code

[Bastien ROUCARIES]

Le mar. 12 janv. 2021 à 21:02, Jonas Smedegaard  a écrit :
>
> Quoting Bastien ROUCARIES (2021-01-12 21:17:36)
> > Fixed it was a little bit hard to test options of compression one by
> > one but it work now.

Hi,

It was harder than I thought.

This time I document the requirement for this package under
https://salsa.debian.org/js-team/node-browser-pack/-/blob/master/debian/rules#L13

And I think I have suffisantly documented the bandaid method in case
of future problems

Could you confirm I am clear ?

Bastien
>
> Great!  Thanks!
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#979942: [Pkg-javascript-devel] Bug#979942: Bug#979942: embedding dead code is no fix to bug for removing that same dead code

[Bastien ROUCARIES]

Hi,

Fixed it was a little bit hard to test options of compression one by
one but it work now.


Le mar. 12 janv. 2021 à 17:48, Xavier  a écrit :
>
> Control: tags -1 reopen
> Control: severity -1 serious
>
> Le 12/01/2021 à 18:17, Jonas Smedegaard a écrit :
> > Quoting Debian FTP Masters (2021-01-12 18:06:40)
> >>  node-browser-pack (6.1.0+ds-7) unstable; urgency=medium
> >>  .
> >>* Team upload
> >>* Bump debhelper compatibility level to 13
> >>* Declare compliance with policy 4.5.1
> >>* Use dh-sequence-nodejs
> >>* Remove dependency to node-uglify but embed node-uglify in 
> >> build_modules
> >>  else build file is wrong (Closes: #979942)
> >
> > Do I read the above correctly that node-browser-pack "fixes" node-uglify
> > going away by embedding it, hidden?
> >
> > I disagree that that is a fix.
>
> OK, but I didn't succeed to fix that, let's reopen, upgrade severity and
> wait for someone else to fix it
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#971216: Bug#977205: imagemagick: CVE-2020-29599

[Bastien ROUCARIES]

hi,

I am ok with this but could you mention, the whole list of format
instead of ghostscript format in changelog aka (pdf, eps, ps)

Bastien

Le dim. 3 janv. 2021 à 14:21, Salvatore Bonaccorso  a écrit :
>
> Hi Bastien,
>
> Hope you are ok.
>
> On Tue, Dec 15, 2020 at 10:34:59AM +0100, Bastien ROUCARIES wrote:
> > Hi,
> >
> > As said on debian-provate go ahead please. I am late due to payjob issue.
>
> Alright attached is a proposed debdiff for covering the CVEs, but
> please double check them as well please (it includes as well disabling
> the ghostscript handled formats).
>
> There is though another RC bug, #971216 which needs handling for
> bullseye and unstable.
>
> Can you take it from here in case you got more free time?
>
> Regards,
> Salvatore

Bug#977205: imagemagick: CVE-2020-29599

[Bastien ROUCARIES]

Hi,

As said on debian-provate go ahead please. I am late due to payjob issue.

Bastien

On Sat, Dec 12, 2020 at 3:06 PM Salvatore Bonaccorso  wrote:
>
> Source: imagemagick
> Version: 8:6.9.11.24+dfsg-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
>
> Hi,
>
> The following vulnerability was published for imagemagick.
>
> A very extensive blogpost[1] explains the issue, and note that the
> provided POC though does only work so far in ImageMagick7 the issue is
> present as well in legacy ImageMagick 6, affected versions should be
> around 6.9.8-1 onwards.
>
> The required fixes for ImageMagick6 are referenced in the
> security-tracker.
>
> As a side node: For buster the issue is mitigated as the recent DSA
> included the 200-disable-ghostscript-formats.patch patch and disables
> ghostscript handled formats. As a hardening measure against those
> issue it might be ideal to ship the disabling as well in bullseye.
>
> CVE-2020-29599[0]:
> | ImageMagick before 6.9.11-40 and 7.x before 7.0.10-40 mishandles the
> | -authenticate option, which allows setting a password for password-
> | protected PDF files. The user-controlled password was not properly
> | escaped/sanitized and it was therefore possible to inject additional
> | shell commands via coders/pdf.c.
>
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2020-29599
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-29599
> [1] 
> https://insert-script.blogspot.com/2020/11/imagemagick-shell-injection-via-pdf.html
>
> Regards,
> Salvatore
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-rc6-amd64 (SMP w/8 CPU threads)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>

Bug#964090: Please upload backport

[Bastien ROUCARIES]

Hi,

I agree with salvatore, that in general disabling pdf is the safer solution.

I am slowly recovering from work debt due to covid  19 lockdown in
France (i was locked down three month, and I could only work by night
for payjob so debian work was not done), but I will accept patch.

The solution of this tradeoff problem is a debconf question. I will accept patch

Bastien



On Sun, Dec 13, 2020 at 9:21 PM Salvatore Bonaccorso  wrote:
>
> Hi,
>
> Cc'in the security-team alias.
>
> On Wed, Oct 07, 2020 at 01:15:23PM -0700, Felix Lechner wrote:
> > Control: tags -1 + patch
> >
> > Hi,
> >
> > > Is this because of a ghostscript vulnerability?
> >
> > The PDF policy restriction is also in effect on Debian stable even
> > though that release ships with Ghostscript 9.27, which online sources
> > suggest is safe. [1]
> >
> > Converting images to PDF is a very common functionality. Please
> > provide a backport with the attached patch, or similar. Thanks!
>
> It is actually unlikely for the moment that we will revert the
> 200-disable-ghostscript-formats.patch patch again, which was firstly
> included in the 8:6.9.10.23+dfsg-2.1+deb10u1 upload. It does mitigates
> in general problems with the ghostscript handled formats, e.g. the
> (new) CVE-2020-29599, cf.
> https://insert-script.blogspot.com/2020/11/imagemagick-shell-injection-via-pdf.html

Bug#840829: upstream bug

[Bastien ROUCARIES]

control: forwarded -1 https://github.com/moby/moby/issues/40360
control: tags -1 + upstream

According to https://medium.com/nttlabs/cgroup-v2-596d035be4d7 near ready

Bug#921594: Wontfix

[Bastien ROUCARIES]

control: tags -1 + wontfix

Hi,

This problem is due to an experimental version. I will not correct
this bug because It is a minor one and moreover this experimental
version was experimental.

Bastien

Bug#959477: ITP: ckeditor3 -- Javascript rich text editor for embedding into websites (v3)

[Bastien ROUCARIES]

On Sat, May 2, 2020 at 9:21 PM Mike Gabriel
 wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Mike Gabriel 
>
> * Package name: ckeditor3
>   Version : 3.6.6.1
>   Upstream Author : Frederico Knabben
> * URL : http://ckeditor.com/download
> * License : GPL-2+
>   Programming Lang: Javascript
>   Description : Javascript rich text editor for embedding into websites 
> (v3)
>
>  I plan to re-upload ckeditor3 to Debian as part of my initiative to
>  re-provide Horde in Debian.
>  .
>  Unfortunately, Horde upstream has still not moved on to ckeditor4, thus this
>  old version of ckeditor is required for the interim.
>  .
>  Before Debian 11 gets released I plan to provide a patch to Horde Upstream
>  that fixes this problem.

ckeditor in debian is 3 by memory

Bug#956922: ITP: fsverity -- Userspace utilities for fs-verity

[Bastien ROUCARIES]

On Thu, Apr 16, 2020 at 9:18 PM Romain Perier  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Romain Perier 
>
> * Package name: fsverity
>   Version : 1.0
>   Upstream Author : Eric Biggers 
> * URL : 
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/fsverity-utils.git
> * License : GPL
>   Programming Lang: C
>   Description : Userspace utilities for fs-verity
>
> This is fsverity, a userspace utility for fs-verity. fs-verity is a Linux 
> kernel
> feature that does transparent on-demand integrity/authenticity verification of
> the contents of read-only files, using a hidden Merkle tree (hash tree) 
> associated
> with the file. The mechanism is similar to dm-verity, but implemented at the 
> file
> level rather than at the block device level. The fsverity utility allows you 
> to
> set up fs-verity protected files.
>
> This package will be helpful for handling the fsverity feature on a file from
> userspace.
>
> I want to maintain this package. As DM, I need someone for the initial upload.
> Packaging is currently hosted here 
> https://salsa.debian.org/rperier-guest/fsverity,
> and will be developed at https://salsa.debian.org/debian/fsverity

I can. Do you plan also to support it under debian install (maybe also
dm-verify/dm-integrity)

Bastien

Bug#782654: Bug#838416: Bug#782654: Bug#838416: ITP: bazel -- Fast and correct automated build system by Google

[Bastien ROUCARIES]

Upstream seems to be friendly

Time to prod them:
https://github.com/bazelbuild/bazel/issues/9408

On Wed, Apr 8, 2020 at 10:57 PM Philipp Kern  wrote:
>
> On 2020-04-08 19:43, Olek Wojnar wrote:
> > Bazel has suddenly become more important because it is preventing us
> > from getting packages working that would help with the COVID-19
> > pandemic. Due to the significance, I am copying the Debian Med team as
> > well as key people from this bug's history in the hopes of getting
> > something moving quickly.
> >
> > On Tue, 22 May 2018 14:55:19 -0600 Kyle Moffett 
> > wrote:
> >> I spent a while working on it off and on, but there is a decent amount
> >> of tweaking and other packaging work needed to get policy-compliant
> >> bazel packages.  (E.G: There are quite a few binary JAR files shipped
> >> in the upstream tarball that don't necessarily match the versions in
> >> Debian).
> >>
> >> I just didn't have the spare time, especially now that I have a kid,
> >> to sink into one package.
> >
> > I can relate to the kid/time issues! ;) Have you had any time to work
> > on it recently? Did you ever upload any of your work?
> >
> > In the meantime, I see that Bazel has an unofficial Ubuntu build [1].
> > Do you know anything about that? It seems like a good place for us to
> > start if you aren't close to a product yourself.
>
> That's the build Google provides that is built with Bazel itself, using
> a ton of vendored libraries. (Because that's how Google operates
> internally.)
>
> Generally the pkg_deb output[1] is not really policy-compliant and more
> built from the ground up without any Debian tooling. So the /mere
> existence/ of that package (which was there from the beginning) does not
> help the quest of getting Bazel packaged for Debian, unfortunately.
>
> Kind regards
> Philipp Kern, obviously not speaking for Google
>
> [1]
> https://github.com/bazelbuild/bazel/blob/f828b4c77805ad0ea6afecef798aa69d68bec8d4/scripts/packages/debian/BUILD#L69

Bug#955816: Improve documentation of bridge option

[Bastien ROUCARIES]

control: forwarded -1 net...@vger.kernel.org

On Sun, Apr 5, 2020 at 1:05 PM Luca Boccassi  wrote:
>
> On Sun, 5 Apr 2020 at 10:30, Bastien Roucariès
>  wrote:
> >
> > Subject: iproute2: Improve bridge documentation
> > Package: iproute2
> > Version: 5.5.0-1
> > Severity: wishlist
> > Tags: patch
> > Forwarded: step...@networkplumber.org
> >
> > Dear Maintainer,
> >
> > I have improved the documentation of man pages for bridge.
> >
> > Moreover state is now case insensitive.
> >
> > Please apply
>
> Please send these upstream first. You can do so with git send-email:

Done

Thanks
>
> git send-email --subject-prefix='PATCH iproute2' --to
> net...@vger.kernel.org --annotate -6

Bug#952312: [Pkg-javascript-devel] Bug#952312: Bug#952312: Bug#952312: node-eslint-scope: FTBFS: tests failed

[Bastien ROUCARIES]

Le mar. 25 févr. 2020 à 19:48, Jonas Smedegaard  a écrit :

> control: reassign -1 node-espree
> control: affects -1 node-eslint-scope
>
> Quoting Xavier (2020-02-25 18:29:35)
> > Le 23/02/2020 à 14:50, Lucas Nussbaum a écrit :
> > > During a rebuild of all packages in sid, your package failed to
> > > build on amd64.
> >
> > Some test are incompatible with node-espree-6. The fix could be
> > simply:
>
> Certainly not a fix to disable tests.
>
> The package node-espree has exactly one reverse dependency which is
> node-eslint-scope, so this is a case of bad coordination.
>
> (yes, another fix would be to upgrade node-eslint-scope, but that is
> more complex and less urgent, so let's roll back first and work on going
> forward in experimental first



Node-espree was upgraded due to not compatible with acorn6...

So upgrade is safer

> )
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private--
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#951398: Rebuild pax

[Bastien ROUCARIES]

On Mon, Feb 17, 2020 at 10:12 PM Norbert Preining  wrote:
>
> Hi Bastien,
>
> On Mon, 17 Feb 2020, Bastien ROUCARIES wrote:
> > For rebuilding pax you need to apply this patch then from
>
> Ok, it is not that easy but done that now.
>
> > source/pax/latex/pax run ant
>
> ok.
>
> This script generates **three** files:
> texmf-dist/tex/latex/pax/pax.jargood
> texmf-dist/tex/latex/pax/lib/commons-logging.jar
> texmf-dist/tex/latex/pax/lib/pdfbox.jar
>
> Are the last two necessary there, i.e., should we replace them with
> links to the respective files in the installed packages?

They need to be replaced by link to their respective package (normally
it is symlink to /usr/share/commons-logging.jar)

Best

Bastien
>
> Best
>
> Norbert
>
> --
> PREINING Norbert  https://www.preining.info
> Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#951398: Rebuild pax

[Bastien ROUCARIES]

control: tags -1 + patch
control: severity -1 serious

Hi,

For rebuilding pax you need to apply this patch then from
source/pax/latex/pax run ant

It will create the whole stuff under script directory.

You will need to add depends to pdfbox and common-logging java package
but it work

When I will upload the TDS package you will need to remove the
latex/pax/ .jar files and remove the ant file.

Could you apply the patch, rebuild and test ?

Thanks

Bastien
diff --git a/scripts/pax/pax.jar b/scripts/pax/pax.jar
deleted file mode 100644
index 36371e2..000
Binary files a/scripts/pax/pax.jar and /dev/null differ
diff --git a/scripts/pax/pdfannotextractor.pl b/scripts/pax/pdfannotextractor.pl
index 085dc43..fd5dc30 100755
--- a/scripts/pax/pdfannotextractor.pl
+++ b/scripts/pax/pdfannotextractor.pl
@@ -39,18 +39,15 @@ ${title}Syntax:   $program [options] 
 Options:
   --help  print usage
   --version   print version number
-  --install   try installing PDFBox library
   --debug debug informations
 END_OF_USAGE
 
 my $help = 0;
 my $debug = 0;
-my $install = 0;
 my $opt_version = 0;
 use Getopt::Long;
 GetOptions(
   'debug!' => \$debug,
-  'install!' => \$install,
   'help!' => \$help,
   'version!' => \$opt_version,
 ) or die $usage;
@@ -59,24 +56,13 @@ if ($opt_version) {
   print "$name $date v$version\n";
   exit(0);
 }
-!$install and (@ARGV >= 1 or die $usage);
+(@ARGV >= 1 or die $usage);
 
 print $title;
 
 my $error = '!!! Error:';
-my $url_pdfbox = 'http://prdownloads.sourceforge.net/pdfbox/PDFBox-0.7.3.zip?download';
-my $size_pdfbox_zip = 22769102;
-my $size_pdfbox_jar = 3321771;
-my $name_pdfbox_jar = 'PDFBox-0.7.3.jar';
-my $entry_pdfbox= "PDFBox-0.7.3/lib/$name_pdfbox_jar";
 my $pdfbox = 'PDFBox';
-
 my $prg_kpsewhich = 'kpsewhich';
-my $prg_wget  = 'wget';
-my $prg_curl  = 'curl';
-my $prg_unzip = 'unzip';
-my $prg_texhash   = 'texhash';
-my $prg_mktexlsr  = 'mktexlsr';
 my $prg_java  = 'java';
 my %prg;
 
@@ -193,16 +179,11 @@ sub find_jar_pdfbox () {
 }
 }
 
+
 sub launch_pax () {
 check_prg $prg_java, 1;
 my @cmd = ($prg_java);
-my $sep = $is_win ? ';' : ':';
-my $cp = "$path_jar_pax";
-$cp .= "$sep$path_jar_pdfbox" if $path_jar_pdfbox;
-$cp .= "$sep$classpath" if $classpath;
-push @cmd, '-cp';
-push @cmd, $cp;
-push @cmd, $main_class;
+push @cmd, $path_jar_pax;
 push @cmd, @ARGV;
 debug 'System', "@cmd";
 system @cmd;
@@ -222,200 +203,6 @@ sub launch_pax () {
 return $exit_code;
 }
 
-# install part
-
-sub expand_var ($) {
-my $var = shift;
-check_prg $prg_kpsewhich, 1;
-my $cmd = $prg_kpsewhich
-  . " --progname $program"
-  . ' --expand-var';
-$cmd .= $is_win ? " \$$var" : " \\\$$var";
-debug 'Backticks', $cmd;
-my $path = `$cmd`;
-if ($? == 0) {
-chomp $path;
-debug 'Exit code', '0/success';
-debug "\$$var", $path;
-return $path;
-}
-if ($? == -1) {
-die "!!! Error: Cannot execute `$prg_kpsewhich' ($!)!\n";
-}
-if ($? & 127) {
-die "!!! Error: `$prg_kpsewhich' died with signal " . ($? & 127)
-. (($? & 128) ? ' with coredump' : '') . "!\n";
-}
-debug 'Exit code', ($? >> 8);
-return '';
-}
-
-sub ensure_dir ($) {
-my $dir = shift;
-return if -d $dir;
-mkdir $dir or die "$error Cannot create directory `$dir'!\n";
-debug 'mkdir', $dir;
-}
-
-sub file_size ($) {
-my $file = shift;
-return -1 unless -f $file;
-return (stat $file)[7];
-}
-
-if ($install) {
-# Can PDFBox already be found?
-find_jar_pdfbox;
-if ($path_jar_pdfbox) {
-print "* Nothing to do, because $pdfbox is already found:\n"
-  . "  $path_jar_pdfbox\n";
-exit(0);
-}
-
-# Find TEXMFVAR
-my $tds_root;
-foreach my $var ('TEXMFVAR', 'VARTEXMF') {
-$tds_root = expand_var $var;
-last if $tds_root;
-}
-$tds_root or die "$error Cannot find settings for `TEXMFVAR' or `VARTEXMF'!\n";
-
-# Create directories
-ensure_dir $tds_root;
-my $tds_pax = $tds_root;
-$tds_pax =~ s/(\/*)$/\/scripts/;
-ensure_dir $tds_pax;
-$tds_pax .= '/pax';
-ensure_dir $tds_pax;
-my $tds_pax_lib = "$tds_pax/lib";
-ensure_dir $tds_pax_lib;
-
-# Download
-my $dest_file = "$tds_pax/PDFBox-0.7.3.zip";
-if (file_size $dest_file == $size_pdfbox_zip) {
-debug "$pdfbox archive found", $dest_file;
-}
-else {
-my @cmd;
-my $prg_download;
-check_prg $prg_wget, 0;
-if ($prg{$prg_wget}) {
-$prg_download = $prg_wget;
-push @cmd, $prg_wget;
-push @cmd, '-O';
-}
-else {
-check_prg $prg_curl, 0;
-$prg{$prg_curl} or die "$error Cannot find programs `wget' or `curl'"
-   . " for downloading!\n";
-$prg_download = $prg_curl;
-

Bug#670040: Fixed

[Bastien ROUCARIES]

On Sun, Feb 16, 2020 at 12:46 AM Norbert Preining  wrote:
>
> Hi Bastien,
>
> >  https://github.com/bastien-roucaries/latex-pax
>
> Would you like to take over PAX as upstream? Heiko has left all behind
> and most packages are maintained by others now.

May be, how can I become upstream ?

BTW you will need to rebuild pax from source.And I have no idea how to
wrap java from macos and windosw

> Best
>
> Norbert
>
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#951398: FTBFS: pax.jar

[Bastien ROUCARIES]

Hi,

Could you reput severity to serious, because pax does not rebuilt from source.

I could help with this one if needed

Bastien
On Sun, Feb 16, 2020 at 12:53 AM Norbert Preining  wrote:
>
> severity 951398 normal
> thanks
>
> Hi Bastien,
>
> On Sun, 16 Feb 2020, Bastien Roucariès wrote:
> > I could not found the source of file texmf-dist/scripts/pax.jar
>
> Mind looking into the .orig.tar.xz?
>
> drwxr-xr-x norbert/norbert0 2020-02-10 10:40 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/
> -rw-r--r-- norbert/norbert 1376 2008-09-21 08:48 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/build.xml
> drwxr-xr-x norbert/norbert0 2020-02-10 10:40 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/license/
> drwxr-xr-x norbert/norbert0 2020-02-10 10:40 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/license/LaTeX/
> -rw-r--r-- norbert/norbert19110 2008-09-21 08:48 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/license/LaTeX/lppl.txt
> drwxr-xr-x norbert/norbert0 2020-02-10 10:40 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/license/PDFAnnotExtractor/
> -rw-r--r-- norbert/norbert17990 2008-09-21 08:48 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/license/PDFAnnotExtractor/gpl.txt
> drwxr-xr-x norbert/norbert0 2020-02-10 10:40 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/
> -rw-r--r-- norbert/norbert 4271 2012-04-20 01:53 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/Constants.java
> -rw-r--r-- norbert/norbert 4583 2012-04-20 01:53 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/Entry.java
> -rw-r--r-- norbert/norbert  963 2012-04-20 01:53 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/EntryWriteException.java
> -rw-r--r-- norbert/norbert   83 2008-10-03 08:11 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/MANIFEST.MF
> -rw-r--r-- norbert/norbert27677 2012-04-20 01:53 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/PDFAnnotExtractor.java
> -rw-r--r-- norbert/norbert 3674 2012-04-20 01:53 
> texlive-extra-2019.202000210/texmf-dist/source/latex/pax/src/StringVisitor.java
>
> > I will in the next week do an audit of all file not rebuilded from source 
> > and I think this package is unsuitable from main
>
> Wrong. But please enjoy the checking which has already been done by the
> RedHat lawyers.
>
> Enjoy.
>
> Norbert
>
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#951398: Patch

[Bastien ROUCARIES]

control: tags -1 + patch

Patch file

Bug#670040: Fixed

[Bastien ROUCARIES]

control: tags -1 + patch

Fixed here :
 https://github.com/bastien-roucaries/latex-pax

The javapath are not fixed but the pax could by using java -cp
/usr/share/texlive/texmf-dist/scripts/pax/pax.jar:/usr/share/java/pdfbox.jar:/usr/share/java/commons-logging.jar
pax.PDFAnnotExtractor file.pdf

Bug#930268: forwarded

[Bastien ROUCARIES]

control: forwarded -1 https://github.com/microsoft/TypeScript/issues/33661

Bug#940881: RFH: freedombox -- debian pure blend, user-friendly, privacy-oriented home server

[Bastien ROUCARIES]

Le sam. 21 sept. 2019 à 14:39, James Valleroy  a
écrit :

> Package: wnpp
> Severity: normal
>
> FreedomBox is looking for new contributors. Our recent success in
> launching a commercial FreedomBox product with Olimex has led to an
> influx in feedback about our software and, consequently, more
> development work to be done. Though we can currently handle urgent
> development matters, FreedomBox has many wish-list items which our
> small team can't always make time for. We need help from our friends
> in Debian!
>

OK for me.

> Although there are only a few bugs open in BTS, there are over 300
> listed in the Salsa issue tracker:
>
> https://salsa.debian.org/freedombox-team/plinth/issues
>
> It may be useful to look in one of the following labels:
> - beginner
> - Help Wanted
> - ready for implementation
>
> If you have any questions about an issue, feel free to comment on it,
> or discuss with us on #freedombox-dev. We also discuss development
> ideas on our forum in the "Development" category:
>
> https://discuss.freedombox.org/c/development
>
>

Bug#940648: Do not install bench dir

[Bastien ROUCARIES]

Package: pkg-js-tools
Version: 0.9.10
Severity: wishlist

Dear Maintainer,

Bench like test should not be installed

Bug#939772: forcemerge

[Bastien ROUCARIES]

forcemerge 939772 939771

Bug#939772: forcemerge

[Bastien ROUCARIES]

control: forcemerge 939772 939771

On Sun, Sep 8, 2019 at 7:28 PM Bastien ROUCARIES
 wrote:
>
>

Bug#782654: News of bazel refactoring for compliance with debian policy

[Bastien ROUCARIES]

Hi,

We recently drop tensorflow from debian due to the huge cost of
maintaining the build system byt converting from bazel to cmake.

Where is the roadmap to get bazel distrib friendly ?

Thanks

Bastien

Bug#938976: imagemagick: No .pc file installed when ImageMagick is installed using apt-get

[Bastien ROUCARIES]

On Fri, Aug 30, 2019 at 7:39 PM Tim Allman  wrote:
>
> Package: imagemagick
> Version: 8:6.9.7.4+dfsg-16ubuntu6.7
> Severity: important
>
> Dear Maintainer,

You should install one of the libdevel package

Thanks

>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
> I was trying to configure, prior to building, another package 
> (tango-icon-theme-0.8.90) which requires
> ImageMagick to create some image files. The configure script failed because 
> pkg-config reported that
> IM was not installed even though it was.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> I downloaded and built IM from source. This created ImageMagick.pc which I 
> copied to /usr/share/pkgconfig.
>
>* What was the outcome of this action?
> The configure script for tango-icon-theme-0.8.90 ran correctly.
>
>* What outcome did you expect instead?
> Failure of course.
>
> *** End of the template - remove these template lines ***
>
>
> -- Package-specific info:
> ImageMagick program version
> ---
> animate:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
> compare:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
> convert:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
> composite:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
> conjure:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
> display:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
> identify:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
> import:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
> mogrify:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
> montage:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
> stream:  ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic-updates
>   APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
> 'bionic'), (100, 'bionic-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-58-generic (SMP w/8 CPU cores)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_CA:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages imagemagick depends on:
> ii  imagemagick-6.q16  8:6.9.7.4+dfsg-16ubuntu6.7
>
> imagemagick recommends no packages.
>
> imagemagick suggests no packages.
>
> -- no debconf information
>

Bug#931179: [Pkg-javascript-devel] Bug#931179: acorn 6.1.1 please bundle additional plugins needed by nodejs source

[Bastien ROUCARIES]

On Thu, Jun 27, 2019 at 5:12 PM Jérémy Lal  wrote:
>
> Source: acorn
> Severity: wishlist
>
> https://github.com/nodejs/node/tree/master/deps/acorn-plugins
> shows which ones.
>
> Thanks for considering - i wonder if some of them would rather be
> packaged independently or not.

Will do but I need ftpmaster first
>
> Jérémy
>
> -- System Information:
> Debian Release: 10.0
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
> LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#916839: imagemagick: Silent ABI break in 6.9.10-11 on i386

[Bastien ROUCARIES]

Hi,

I have uploaded a newer version fixing the problem. Could you ask
release team a rebuild.

BTW could you get a glimpse at ruby-mini-magick ? It seems choked

Bastien

On Sat, Jan 5, 2019 at 4:08 PM Balint Reczey
 wrote:
>
> Hi Bastien,
>
> On Fri, Jan 4, 2019 at 8:41 PM Balint Reczey
>  wrote:
> >
> > Hi,
> >
> > On Thu, Dec 20, 2018 at 6:46 AM Bastien ROUCARIES
> >  wrote:
> > >
> > > On Wed, Dec 19, 2018 at 12:09 PM Balint Reczey
> > >  wrote:
> > > >
> > > > Package: imagemagick
> > > > Version: 8:6.9.10.14+dfsg-1
> > > > Severity: grave
> > > > Control: forwareded -1 
> > > > https://github.com/ImageMagick/ImageMagick6/issues/31
> > > > Control: tags -1 upstream fixed-upstream
> > > > Control: affects -1 ruby-rmagick
> > > >
> > > > Hi,
> > > >
> > > > The ABI broke in 6.9.10-11 due to changing MagickDoubleType to double
> > > > from long double.
> > > > This breaks ruby-rmagick and possibly other reverse dependencies, thus
> > > > after fixing imagemagick please check if some reverse dependencies
> > > > need to be rebuilt. The fix will be available in the .18 upstream
> > > > release.
> > >
> > > Exact, this will need a so bump I suppose...
> >
> > Since the ABI broke only in unstable and testing and only affected
> > i386 and possibly a few rare arches not in Ubuntu I'd say a few
> > rebuilds would suffice. Upstream did not do a major ABI bump either
> > and released the fix.
>
> I have uploaded an NMU to DELAYED/5 with the attached fix, which is
> already included in Ubuntu.
> This will enter the archive before the transition freeze thus Buster
> will be fixed even if no upload is made to imagemagick in the next
> week, but feel free to override it an upload a better fix like a full
> new upstream release.
>
> Cheers,
> Balint
>
> >
> > Cheers,
> > Balint
> >
> > >
> > > Bastien
> > >
> > >
> > >
> > > >
> > > > Cheers,
> > > > Balint
> > > >
> > > > --
> > > > Balint Reczey
> > > > Ubuntu & Debian Developer
> > > >
> >
> >
> >
> > --
> > Balint Reczey
> > Ubuntu & Debian Developer
>
>
>
> --
> Balint Reczey
> Ubuntu & Debian Developer

Bug#899266: [Pkg-javascript-devel] Bug#899266: Bug#899266: [node-backbone] FTBFS documentation

[Bastien ROUCARIES]

On Sun, Dec 30, 2018 at 3:33 PM Jonas Smedegaard  wrote:
>
> Control: tags -1 -ftbfs
> Control: retitle -1 backbone: documentation is pre-generated
> Control: severity -1 normal
>
> Quoting Bastien ROUCARIÈS (2018-05-21 23:37:19)
> > docs/*.html are build with docco not packaged for debian
>
> Correct: The documentation files below docs/ in upstream source was
> pre-generated using the tool docco which is not in Debian.
>
>
> > So FTBFS could you please rip it ?
>
> Please avoid using the term "FTBFS" for anything other than "the package
> fails to build from source".
>
> This Debian source package does not fail to build.
>
> That said, I will consider improve the reproducibility of source
> documentation.  I really appreciate your close examination, but do not
> consider this a serious issue.

Last time ftpmaster consider that I should have to rip the documentation
>
>
> > BTW I could not find copyright information about docs/js/*.js (it is
> > lazy load)
>
> I am unaware that anyone has claimed copyright over the documentation.

doc/js file are from other projects so seems safe to document;

>
> > And favicon.ico is generated from svg file.So you could remove and
> > regenerated from svg file (found it on wikipedia uploaded by original
> > author).
>
> Interesting.  Do you have a URL for the source SVG?

Yes https://commons.wikimedia.org/wiki/File:Backbone.js_logo.svg
>


>
> Thanks again for reporting this,
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#916839: imagemagick: Silent ABI break in 6.9.10-11 on i386

[Bastien ROUCARIES]

On Wed, Dec 19, 2018 at 12:09 PM Balint Reczey
 wrote:
>
> Package: imagemagick
> Version: 8:6.9.10.14+dfsg-1
> Severity: grave
> Control: forwareded -1 https://github.com/ImageMagick/ImageMagick6/issues/31
> Control: tags -1 upstream fixed-upstream
> Control: affects -1 ruby-rmagick
>
> Hi,
>
> The ABI broke in 6.9.10-11 due to changing MagickDoubleType to double
> from long double.
> This breaks ruby-rmagick and possibly other reverse dependencies, thus
> after fixing imagemagick please check if some reverse dependencies
> need to be rebuilt. The fix will be available in the .18 upstream
> release.

Exact, this will need a so bump I suppose...

Bastien



>
> Cheers,
> Balint
>
> --
> Balint Reczey
> Ubuntu & Debian Developer
>