Bug#1064346: Source is missing errors on HTML source files

[roucaries bastien]

Le jeu. 22 févr. 2024 à 06:07, Shriram Ravindranathan  a écrit :
>
> Thank you Bastien,
> I tried doing this but it appears that the scripts to build these
> example files all depend on having the highlight binary itself installed
> on the machine. I am unsure whether it is okay to have the package
> depend on itself for building.

Yes and no.

Best use the built package to generate the file

Other way is staged build

Bastien
>
> On 21/02/24 11:20 pm, roucaries bastien wrote:
> > You should rebuilt from source also... See for instance how I do with 
> > node-long
>
> --
> Shriram Ravindranathan
> ters
>

Bug#1064346: Source is missing errors on HTML source files

[roucaries bastien]

Le mer. 21 févr. 2024 à 15:38, Soren Stoutner  a écrit :
>
> Shriram,
>
> On Wednesday, February 21, 2024 8:30:54 AM MST Shriram Ravindranathan wrote:
> > Upon inspecting the embedded font, It seems to be a bespoke icon-font
> > generated using a tool called "Fontello" from one of the icons of the
> > octicons iconset from Atom  (MIT
> > Licensed SVGs)
> >
> > The font has only 1 glyph, Would it suffice to add this source image to
> > d/missing-souces and add that copyright info to d/copyright?
>
> I would assume so.  If anyone on mentors knows differently please speak up.
>
> > On 21/02/24 9:56 am, Soren Stoutner wrote:
> >
> > >
> > >
> > > Shriram,
> > >
> > >
> > >
> > >
> > > 1. For anything that has the unminified source in the upstream
> > > tarball, I would just create a lintian override with a comment listing
> > > the full path to the source for each file.  You can see an example of
> > > how this can be done here:
> > >
> > >
> > >
> > >
> > > https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/
> sou
> > > rce/lintian-overrides?ref_type=heads
> >
> > >
> > >
> > >
> > > Typically you only copy the source to the debian/missing-sources
> > > directory when it is not included in the upstream tarball and you have
> > > had to acquire it from another place.

You should rebuilt from source also... See for instance how I do with node-long
> > >
> > >
> > >
> > >
> > > 2. The github link below includes an embedded font in woff format.
> > > Typically, fonts like this would be considered compiled, so a separate
> > > font source would be needed.  However, I’m not sure what the Debian
> > > guidance for dealing with an HTML embedded font like this.  If someone
> > > else on mentors doesn’t know, I would recommend you ask on debian-legal.
> > >
> > >
> > >
> > >
> > > As these are mostly README files, and if it becomes difficult for you
> > > to acquire the source for some of them, you might consider excluding
> > > those you can’t get the source for, at least temporarily, using
> > > Files-Excluded in debian/copyright (and then running uscan, which will
> > > produce a modified tarball that does not include the problematic
> > > files).  For example, see:
> > >
> > >
> > >
> > >
> > > https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/
> copyr
> > > ight?ref_type=heads
> >
> > >
> > >
> > >
> > > Whether this is a good option depends on how helpful those README
> > > files are for the users of your package.  If you go this route, you
> > > should add +dfsg to the version of your package to indicate that the
> > > upstream tarball has been repackaged to remove files that are not free
> > > (or for which the source is not available).
> > >
> > >
> > >
> > >
> > > Soren
> > >
> > >
> >
> > --
> > Shriram Ravindranathan
> > ters
> >
>
>
> --
> Soren Stoutner
> so...@debian.org

Bug#1042532: mediawiki: Vendoring a few javascript library without source

[roucaries bastien]

Le lun. 14 août 2023 à 08:57, Kunal Mehta  a écrit :

> severity 1042532 normal
> tags 1042532 wontfix
> thanks
>
> Hi,
>
> On 7/31/23 07:23, roucaries bastien wrote:
> > hi,
> > Le lun. 31 juil. 2023 à 08:27, Kunal Mehta  a écrit
> :
> >> These are in the preferred form for modification so I don't think
> >> there's any issue here, but please correct me if I'm wrong. MediaWiki
> >> often patches these libraries (e.g. jquery.ui) in this format hence IMO
> >> meeting the "preferred form of the work for making modifications to it"
> >> requirement of the GPL.
> >
> > No
> https://sources.debian.org/src/mediawiki/1%3A1.39.4-2/resources/lib/pako/
> > is webpacked in order to be transformed in es5 No source available
> > before webpack
>
> IANAL, but as I understand it, there are two licenses to consider here:
> pako's MIT license (aka Expat) and MediaWiki's GPL v2 or later license.
> The pako_deflate.es5.js file contains the MIT license
> information/attribution, so we're in compliance for that.
>


Ni hère this is a dfsg problem. You do not recompile from source

So serious bug

>
> MediaWiki's GPL v2 requires source code to be in "preferred form of the
> work for making modifications to it". In the context of MediaWiki, this
> is in the preferred form, since that's how we plan to (and do) modify
> it. If you want to patch MediaWiki, having the pre-transpiled sources is
> going to be way more work than the source we're providing right now. And
> the proof is that (AFAIK) MediaWiki devs will just patch these sources
> directly, they don't go to the upstream sources, adjust those, and then
> generate a patch. So I don't see a DFSG issue.
>
> > And do not stick to lastest jquery is a security problem. Are you sure
> > you have closed all the CVE ?
>
> The ones that affect MediaWiki, I believe so. Upstream MediaWiki has at
> least one or two jQuery team members as core developers who follow that
> not to mention the Wikimedia Foundation's security team.
>
> > with my javascript hat, I believe that working with upstream to
> > improve the testing (using if needed selenium) will improve the
> > security of mediawiki by using packaged and up to date js
>
> There is already upstream selenium-based testing, but using the latest
> version of everything isn't always a feature.
>
> > In all the case it decrease the burden from a security point of view
>
> No, it really doesn't, it just shifts it elsewhere. The more deviations
> Debian makes, the less we can rely on upstream's QA processes for
> ensuring we're shipping working software, which will more likely slow
> down security updates. Since bundling is permitted by policy, we plan to
> continue doing it.
>
> -- Kunal
>

Bug#1042532: mediawiki: Vendoring a few javascript library without source

[roucaries bastien]

hi,
Le lun. 31 juil. 2023 à 08:27, Kunal Mehta  a écrit :
>
> Hi,
>
> On 7/29/23 16:44, Bastien Roucariès wrote:
> > Dear Maintainer,
> >
> > resources/lib/
> > (https://sources.debian.org/src/mediawiki/1:1.39.4-2/resources/lib/)
> >
> > include a few library already packaged for debian.
> >
> > Moreover some source are missing (I have only checked pako).
>
> These are in the preferred form for modification so I don't think
> there's any issue here, but please correct me if I'm wrong. MediaWiki
> often patches these libraries (e.g. jquery.ui) in this format hence IMO
> meeting the "preferred form of the work for making modifications to it"
> requirement of the GPL.

No https://sources.debian.org/src/mediawiki/1%3A1.39.4-2/resources/lib/pako/
is webpacked in order to be transformed in es5 No source available
before webpack

>
> > You could use the packaged library under debian
>
> Older versions of the package did that, but the version mismatches were
> not worth it. Plus MediaWiki has a ton of user-written code that's
> stored and loaded on-wiki, so deviations from the official version are
> incredibly hard to test and just cause breakage everywhere.

Pako is stable, I understand for jquery but sinon,,promise stuff and
so on could be packaged.

Moreover in all the case you should document the embed code in security tracker.

And do not stick to lastest jquery is a security problem. Are you sure
you have closed all the CVE ?

with my javascript hat, I believe that working with upstream to
improve the testing (using if needed selenium) will improve the
security of mediawiki by using packaged and up to date js

This bug should be solved package by package:
- first by doing an analysis of stable/not stable api => stable api use packaged
- for non stable and patched version => guarantee that source is here
- for non stable and patched version try to create test case with
upstream using selenium checking integration
- move to packaged

In all the case it decrease the burden from a security point of view

bastien

>
> -- Kunal

Bug#1041471: src:isa-support: fails to migrate to testing for too long: new autopkgtest fails on armel

[roucaries bastien]

Hi Paul,

It is a regression on qemu. I will disable the test but I will prefer
qemu fixed.

I could not reproduce on porter box, I get another qemu bug...

Who is the specialist of qemu ?

Bastien

Le mer. 19 juil. 2023 à 10:45, Paul Gevers  a écrit :
>
> Source: isa-support
> Version: 15.1
> Severity: serious
> Control: close -1 19
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
>
> Dear maintainer(s),
>
> The Release Team considers packages that are out-of-sync between testing
> and unstable for more than 30 days as having a Release Critical bug in
> testing [1]. Your package src:isa-support has been trying to migrate for
> 31 days [2]. Hence, I am filing this bug. The version in unstable added
> an autopkgtest that segfaults on armel. (Just for your info in case it's
> relevant, the ci.debian.net armel VM's run on arm64 hardware.)
>
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on
> other packages, which makes preparing for the release more difficult.
> Finally, it often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that
> hamper the migration of their package in a timely manner.
>
> This bug will trigger auto-removal when appropriate. As with all new
> bugs, there will be at least 30 days before the package is auto-removed.
>
> I have immediately closed this bug with the version in unstable, so if
> that version or a later version migrates, this bug will no longer affect
> testing. I have also tagged this bug to only affect sid and trixie, so
> it doesn't affect (old-)stable.
>
> If you believe your package is unable to migrate to testing due to
> issues beyond your control, don't hesitate to contact the Release Team.
>
> Paul
>
> [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
> [2] https://qa.debian.org/excuses.php?package=isa-support

Bug#1039119: darktable: use packaged lua

[roucaries bastien]

Le lun. 26 juin 2023 à 14:16, David Bremner  a écrit :
>
> roucaries bastien  writes:
> >
> > Yes in your case i cheched by grepping thé build log. Lua ils compiléd what
> > why i set rc severity.
>
> I suspect that you saw a different package with Lua in the name, namely
> LuaAutoC. The embedding of that library is a bug, but I'm not sure
> there's any practical benefit to filing it since it is not packaged
> seperately in Debian, and darktable is afaik the only package using it.

Yes I see it now, sorry for the noise..

> Personally there are higher priority issues with darktable, in
> particular the embedding of LibRaw (which is already tracked by it's own
> bug iirc).

Yes I agree

Bug#1039119: darktable: use packaged lua

[roucaries bastien]

Le lun. 26 juin 2023 à 06:45, David Bremner  a écrit :

> Bastien Roucariès  writes:
>
> > Source: darktable
> > Version: Use packaged lua
> > Severity: serious
> > Justification: embded code copy
> >
> > Dear Maintainer,
> >
> > It appear that your package embded and compile lua
> >
> > Could you:
> > - use the packaged lua lib
> > - repack in order to avoid accidental reintroduction of compiling lua
> >
> > rouca
>
> Since upstream already checks for the system lua (unless that changed)
> repackaging seems unecessary. Do you have some evidence (build logs ?)
> that the build is not using the system lua
>


Yes in your case i cheched by grepping thé build log. Lua ils compiléd what
why i set rc severity.


Bastien

> d
>

Bug#984748: gettext is wrongly marked Multi-Arch: foreign

[roucaries bastien]

Hi,

Time to get to unstable post release

Bastien

Le dim. 26 févr. 2023 à 14:44, Bastien Roucariès
 a écrit :
>
> Source: gettext
> Followup-For: Bug #984748
> Control: tags -1 + patch
>
> Dear Maintainer,
>
> I havve done a few patches for improving the situation. Patch 2 may be 
> reported
> upstream.

Bug#1017446: debian-policy: stress that preinst script that install by using base64 decode on self an elf binary is not a good stuff

[roucaries bastien]

Le mar. 16 août 2022 à 13:22, Sam Hartman  a écrit :
>
> > "Bastien" == Bastien Roucariès  writes:
> Bastien> I will like to stress that this kind of stuff is bad:
> Bastien> 
> https://salsa.debian.org/debian/isa-support/-/blob/master/debian/altivec-
> Bastien> support.preinst.in#L10
>
> How would you do better in that instance?
> I think everyone knows it's bad, but I'm guessing that the maintainer
> didn't have a better approach for detecting whether the referenced
> instructions worked on the installed system.
>
> I'm assuming that if feature tests in /proc/cpuinfo were sufficient they
> would have been used.

No the problem is not probing the cpu/cpuinfo...

The problem is the base64 encoded binary.

I ma solving this by pre-depends on a binary package and run the
binary from the preinstalled package.


>
> --Sam

Bug#998476: autoconf-archive: AX_PYTHON_DEVEL version checks fail with Python 3.10

[roucaries bastien]

Hi,

Can I have the debdiff ? I can do the upload

Bastien (ro...@debian.org)


Le jeu. 11 nov. 2021 à 11:48, Matthias Klose  a écrit :
>
> uploaded to the delayed queue to prepare for Python 3.10.

Bug#981171: [PATCH 6/6] Use subsection for environment

[roucaries . bastien]

From: Bastien Roucariès 

In order to improve readability create four subsections:
-  POSIX defined core environment variables, for variables defined by POSIX that
modify the general behavior of a program
- Internationalization environment variables for variables related to 
internationalization
- User customization environment variables for personnalizing application to 
user taste.
- Other common environment variables for other common variables

Move USER to other because this variable is not defined by POSIX

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 123 ++---
 1 file changed, 66 insertions(+), 57 deletions(-)

diff --git a/man7/environ.7 b/man7/environ.7
index 9fd3f727f..45204438f 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -138,38 +138,20 @@ to not conflict with the variables specified in the next 
sections.
 Environment variables specific to a particular program or library function
 are documented in the ENVIRONMENT section of the appropriate manual page.
 .SH ENVIRONMENT
-Common examples of environment variables 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.
+.SS POSIX defined core environment variables
+Common examples of environment variables defined by POSIX that may modify the 
general
+behavior of a program, are defined in the following section.
+Conforming applications shall not set these environment variables to have
+meanings other than as described.
 .TP
 .B LOGNAME
-The name of the logged-in user (used by some System-V derived programs).
+The name of the logged-in user.
 Set at login time, see section NOTES below.
 .TP
 .B HOME
 A user's login directory, set a login time.
 Set at login time, see section NOTES below.
 .TP
-.B LANG
-The name of a locale to use for locale categories when not overridden
-by
-.B LC_ALL
-or more specific environment variables such as
-.BR LC_COLLATE ,
-.BR LC_CTYPE ,
-.BR LC_MESSAGES ,
-.BR LC_MONETARY ,
-.BR LC_NUMERIC ,
-and
-.BR LC_TIME
-(see
-.BR locale (7)
-for further details of the
-.BR LC_*
-environment variables).
-.TP
 .B PATH
 The sequence of directory prefixes that
 .BR sh (1)
@@ -207,6 +189,62 @@ Set at login time, see section NOTES below.
 .TP
 .B TERM
 The terminal type for which output is to be prepared.
+.SS Internationalization environment variables
+.TP
+.B LANG
+The name of a locale to use for locale categories when not overridden
+by
+.B LC_ALL
+or more specific environment variables such as
+.B LC_COLLATE ,
+.B LC_CTYPE ,
+.B LC_MESSAGES ,
+.B LC_MONETARY ,
+.B LC_NUMERIC ,
+and
+.BR LC_TIME.
+See
+.BR catopen (3),
+.BR gettext (3),
+.BR locale (7)
+for further details of the
+.B LANG
+and
+.B LC_*
+environment variables.
+.TP
+.BR TZ/TZDIR
+.B TZ
+variable (in association with
+.B TZDIR)
+gives timezone information used by
+.BR tzset (3)
+and through that by functions like
+.BR ctime (3),
+.BR localtime (3),
+.BR mktime (3),
+.BR strftime (3).
+See also
+.BR tzselect (8).
+.SS User customization environment variables
+The following variables are commonly used for personalizing
+applications used by the user:
+.\" .TP
+.\" .B BROWSER
+.\" The user's preferred utility to browse URLs. Sequence of colon-separated
+.\" browser commands. See http://www.catb.org/\(tiesr/BROWSER/ .
+.TP
+.B COLUMNS/LINES
+The
+.B COLUMNS " and " LINES
+variables
+tell applications about the window size, possibly overriding the actual size.
+.TP
+.BR EDITOR / VISUAL
+The user's preferred utility to edit text files.
+Any string acceptable as a command_string operand to the
+.I sh\ \-c
+command shall be valid.
 .TP
 .B PAGER
 The user's preferred utility to display text files.
@@ -218,30 +256,11 @@ variable is null or not set,
 command could fallback
 .B more (1)
 or any suitable paging utility default defined system-wise.
-.TP
-.BR EDITOR / VISUAL
-The user's preferred utility to edit text files.
-Any string acceptable as a command_string operand to the
-.I sh\ \-c
-command shall be valid.
-.\" .TP
-.\" .B BROWSER
-.\" The user's preferred utility to browse URLs. Sequence of colon-separated
-.\" browser commands. See http://www.catb.org/\(tiesr/BROWSER/ .
-.PP
+.SS Other common environment variables
 Note that the behavior of many programs and library routines is
 influenced by the presence or value of certain environment variables.
 Examples include the following:
 .IP * 3
-The variables
-.BR LANG ", " LANGUAGE ", " NLSPATH ", " LOCPATH ,
-.BR LC_ALL ", " LC_MESSAGES ,
-and so on influence locale handling; see
-.BR catopen (3),
-.BR gettext (3),
-and
-.BR locale (7).
-.IP *
 .B TMPDIR
 influences the path prefix of names created by
 .BR tempnam (3)
@@ -272,23 +291,13 @@ gives the name of a file containing aliases
 to be used with
 .BR gethostbyname (3).
 .IP *
-.BR TZ " and " TZDIR
-give timezone information used by
-.BR tzset (3)
-and through that by functions like
-.BR ctime (3),
-.BR localtime (3),
-.BR mktime 

Bug#981171: [PATCH 5/6] Create a section ENVIRONMENT

[roucaries . bastien]

From: Bastien Roucariès 

According to man-page (7):
 ENVIRONMENT
  A list of all environment variables that affect the program or 
function and how they affect it.

Therefore push the list of variables to an ENVIRONMENT section.

Reorder also how to set environment variables to DESCRIPTION instead of after 
the ENVIRONMENT section
in order to improve readability.

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 95 +++---
 1 file changed, 52 insertions(+), 43 deletions(-)

diff --git a/man7/environ.7 b/man7/environ.7
index d1e86ee8d..9fd3f727f 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -87,7 +87,58 @@ The value can be anything that can be represented as a 
string.
 The name and the value may not contain an embedded null byte (\(aq\e0\(aq),
 since this is assumed to terminate the string.
 .PP
-Common examples are:
+Environment variables may be placed in the shell's environment by the
+.I export
+command in
+.BR sh (1),
+or by the
+.I setenv
+command if you use
+.BR csh (1).
+.PP
+The initial environment of the shell is populated in various ways,
+such as definitions from
+.IR /etc/environment
+that are processed by
+.BR pam_env (8)
+for all users at login time (on systems that employ
+.BR pam (8)).
+In addition, various shell initialization scripts, such as the system-wide
+.IR /etc/profile
+script and per-user initializations script may include commands
+that add variables to the shell's environment;
+see the manual page of your preferred shell for details.
+.PP
+Bourne-style shells support the syntax
+.PP
+NAME=value command
+.PP
+to create an environment variable definition only in the scope
+of the process that executes
+.IR command .
+Multiple variable definitions, separated by white space, may precede
+.IR command .
+.PP
+Arguments may also be placed in the
+environment at the point of an
+.BR exec (3).
+A C program can manipulate its environment using the functions
+.BR getenv (3),
+.BR putenv (3),
+.BR setenv (3),
+and
+.BR unsetenv (3).
+.PP
+What follows is a list of environment variables typically seen on a
+system.
+This list is incomplete and includes only common variables seen
+by average users in their day-to-day routine.
+Care should be taken
+to not conflict with the variables specified in the next sections.
+Environment variables specific to a particular program or library function
+are documented in the ENVIRONMENT section of the appropriate manual page.
+.SH ENVIRONMENT
+Common examples of environment variables are:
 .TP
 .B USER
 The name of the logged-in user (used by some BSD-derived programs).
@@ -178,48 +229,6 @@ command shall be valid.
 .\" The user's preferred utility to browse URLs. Sequence of colon-separated
 .\" browser commands. See http://www.catb.org/\(tiesr/BROWSER/ .
 .PP
-Names may be placed in the shell's environment by the
-.I export
-command in
-.BR sh (1),
-or by the
-.I setenv
-command if you use
-.BR csh (1).
-.PP
-The initial environment of the shell is populated in various ways,
-such as definitions from
-.IR /etc/environment
-that are processed by
-.BR pam_env (8)
-for all users at login time (on systems that employ
-.BR pam (8)).
-In addition, various shell initialization scripts, such as the system-wide
-.IR /etc/profile
-script and per-user initializations script may include commands
-that add variables to the shell's environment;
-see the manual page of your preferred shell for details.
-.PP
-Bourne-style shells support the syntax
-.PP
-NAME=value command
-.PP
-to create an environment variable definition only in the scope
-of the process that executes
-.IR command .
-Multiple variable definitions, separated by white space, may precede
-.IR command .
-.PP
-Arguments may also be placed in the
-environment at the point of an
-.BR exec (3).
-A C program can manipulate its environment using the functions
-.BR getenv (3),
-.BR putenv (3),
-.BR setenv (3),
-and
-.BR unsetenv (3).
-.PP
 Note that the behavior of many programs and library routines is
 influenced by the presence or value of certain environment variables.
 Examples include the following:
-- 
2.29.2

Bug#981171: [PATCH 4/6] Better documentation of the environment mechanism

[roucaries . bastien]

From: Bastien Roucariès 

Document the purpose of the envirment mechanism, compared to the
command line argument of a program. Document particularly that
the environment is shared by many programs and is inherited.

Define also the so called process environment and "the environment"
concept that are used in other manpages.

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/man7/environ.7 b/man7/environ.7
index 3c2769bfb..d1e86ee8d 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -43,6 +43,32 @@ The variable
 .I environ
 points to an array of pointers to strings called the "environment".
 The last pointer in this array has the value NULL.
+.PP
+At time of execution, a program receive context information by two mechanisms.
+The first way is the program arguments, represented by the arguments of
+.I main
+function,
+.I argc
+and
+.I argv
+variables. The second way, is the
+.I environ
+variable as discuted in this manual.
+.PP
+The program arguments are typically used to pass so-called command-line 
argument specific to
+a particular use of the program being invoked, thus changing the program 
behavior to an use case.
+The environment, on the other hand, keeps track of information that is shared 
by many programs and
+rarely changes.
+For example, a running process can query the value of the
+.B TMPDIR
+environment variable to discover a suitable location to store temporary files.
+.PP
+Standard environment variables are used for information about the user’s home 
directory,
+current language,...
+An user can define additional variables for other purposes.
+The set of all environment variables that have values is collectively known as
+the process environment or simply the environment.
+.PP
 This array of strings is made available to the process by the
 .BR execve (2)
 call when a new program is started.
-- 
2.29.2

Bug#981171: [PATCH 2/6] Document PATH resolution

[roucaries . bastien]

From: Bastien Roucariès 

Document PATH resolution, particularly null sequence and empty PATH

Document also that since POSIX.1-2001 null sequence for . are deprecated.

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/man7/environ.7 b/man7/environ.7
index e33dcc754..9ac86f357 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -97,16 +97,28 @@ environment variables).
 The sequence of directory prefixes that
 .BR sh (1)
 and many other
-programs apply in searching for a file known by an incomplete pathname.
+programs using
+.BR execlp (3)
+apply in searching for a file known by an incomplete pathname.
 The prefixes are separated by \(aq\fB:\fP\(aq.
-(Similarly one has
+When a non-zero-length prefix is applied to this pathname, a \(aq\fB/\fP\(aq
+(slash) shall be inserted between the prefix and the filename if the prefix
+did not end in
+\(aq\fB\(sl\fP\(aq (slash).
+A zero length prefix is a legacy sequence that indicate the current directory 
or
+\(aq\fB.\fP\(aq (see section BUGS below).
+The list of prefixes shall be searched from beginning to end, applying the
+pathname to each prefix, until an executable file with the specified name
+and appropriate execution permissions is found.
+.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.
@@ -323,6 +335,14 @@ The authors of
 .I gzip
 should consider renaming their option to
 .BR GZIP_OPT .
+.PP
+.B PATH
+zero lengh sequence,
+that appears as two adjacent colons \(aq\fB::\fP\(aq, as a initial colon
+\(aq\fB:\fP\(aq preceding the rest of the list,
+or as a trailing colon \(aq\fB:\fP\(aq following the rest of the list,
+shall be replaced by implicit \(aq\fB.\fP\(aq, in order to be portable
+and strictly conformant to POSIX.1-2001.
 .SH SEE ALSO
 .BR bash (1),
 .BR csh (1),
-- 
2.29.2

Bug#981171: [PATCH 3/6] Improve pager section by pointing to more

[roucaries . bastien]

From: Bastien Roucariès 

More is the default pager according to mailx manual page of POSIX.1-2001 to
POSIX.1-2017. Mention it.
---
 man7/environ.7 | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/man7/environ.7 b/man7/environ.7
index 9ac86f357..3c2769bfb 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -135,7 +135,12 @@ The terminal type for which output is to be prepared.
 The user's preferred utility to display text files.
 Any string acceptable as a command_string operand to the
 .I sh\ \-c
-command shall be valid.
+command shall be valid. If the
+.B PAGER
+variable is null or not set,
+command could fallback
+.B more (1)
+or any suitable paging utility default defined system-wise.
 .TP
 .BR EDITOR / VISUAL
 The user's preferred utility to edit text files.
@@ -348,6 +353,7 @@ and strictly conformant to POSIX.1-2001.
 .BR csh (1),
 .BR env (1),
 .BR login (1),
+.BR more (1),
 .BR printenv (1),
 .BR sh (1),
 .BR su (1),
-- 
2.29.2

Bug#981171: [PATCH 0/6][V2] environement (7)

[roucaries . bastien]

Please review and apply

[PATCH 1/6] Document that means at login time for HOME, LOGNAME,
[PATCH 2/6] Document PATH resolution
[PATCH 3/6] Improve pager section by pointing to more
[PATCH 4/6] Better documentation of the environment mechanism
[PATCH 5/6] Create a section ENVIRONMENT
[PATCH 6/6] Use subsection for environment

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

[roucaries . bastien]

From: Bastien Roucariès 

Clearly document that HOME, LOGNAME, SHELL and USER are set at login time
by program like login (1).

Document also that using su could result in a mixed environment, and point to
su manual.

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 34 ++
 1 file changed, 30 insertions(+), 4 deletions(-)

diff --git a/man7/environ.7 b/man7/environ.7
index 8f89ba86b..e33dcc754 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 a login time.
+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,30 @@ 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 only set when an user is changing using
+session management interface, typically by program
+.B login(1)
+from user database (for instance, but not limited, by using
+.B password (5)
+database).
+Particularly,
+.BR setuid (2)
+family of function
+does not set theses variables. Notes that as documented,
+going to root by
+.BR su (8)
+may result in a mixed environment where
+.B LOGNAME
+and
+.B USER
+are retained from old user.
 .SH BUGS
 Clearly there is a security risk here.
 Many a system command has been
@@ -305,6 +330,7 @@ should consider renaming their option to
 .BR login (1),
 .BR printenv (1),
 .BR sh (1),
+.BR su (1),
 .BR tcsh (1),
 .BR execve (2),
 .BR clearenv (3),
-- 
2.29.2

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

[roucaries . bastien]

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
+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
+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
-- 
2.29.2

Bug#981171: [PATCH 12/13] Introduce the user custumization section

[roucaries . bastien]

From: Bastien Roucariès 

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 74 ++
 1 file changed, 39 insertions(+), 35 deletions(-)

diff --git a/man7/environ.7 b/man7/environ.7
index 236025035..b461e93df 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -82,7 +82,7 @@ command-line arguments specific to a particular use of the 
program
 being invoked, thus changing the program's behavior for this use case.
 The environment, on the other hand, keeps track of information that is shared 
by many programs and
 rarely changes. For example, a running process can query the value of the
-.B TMDIR
+.B TMPDIR
 environment variable to discover a suitable location to store temporary files.
 .PP
 Standard environment variables are used for information about the user' home 
directory,
@@ -161,15 +161,15 @@ Common examples of environment variables defined by 
POSIX.1-2017 are defined in
 section. Conforming applications shall not set these environment variables to 
have
 meanings other than as described.
 .TP
+.B HOME
+A user's login directory.
+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
 and POSIX.1-2017).
 Set at login time, see section NOTES below.
 .TP
-.B HOME
-A user's login directory.
-Set at login time, see section NOTES below.
-.TP
 .B PATH
 The list of places that shells and other programs look in to find
 a command when given an incomplete pathname. Elements on this
@@ -204,26 +204,16 @@ Set at login time, see section NOTES below.
 .B TERM
 The terminal type for which output is to be prepared.
 .TP
-.B PAGER
-The user's preferred utility to display text files.
-Any string acceptable as a command_string operand to the
-.I sh\ \-c
-command shall be valid. If the
-.B PAGER
-variable is null or not set,
-command could fall back
-.B more (1)
-or any suitable paging utility as the system default.
-.TP
-.BR EDITOR / VISUAL
-The user's preferred utility to edit text files.
-Any string acceptable as a command_string operand to the
-.I sh\ \-c
-command shall be valid.
-.\" .TP
-.\" .B BROWSER
-.\" The user's preferred utility to browse URLs. Sequence of colon-separated
-.\" browser commands. See http://www.catb.org/\(tiesr/BROWSER/ .
+.B TMPDIR
+The current temporary directory.
+Influences the path prefix of names created by
+.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.
 .SH INTERNATIONALIZATION ENVIRONMENT VARIABLES
 .TP
 .B LANG
@@ -247,21 +237,35 @@ for further details of the
 and
 .B LC_*
 environment variables.
+.SH USER CUSTOMIZATION ENVIRONMENT VARIABLES
+The following variables are commonly used for personalizing
+applications used by the user.
+.TP
+.B PAGER
+The user's preferred utility to display text files.
+Any string acceptable as a command_string operand to the
+.I sh\ \-c
+command shall be valid. If the
+.B PAGER
+variable is null or not set,
+command could fall back
+.B more (1)
+or any suitable paging utility as the system default.
+.TP
+.BR EDITOR / VISUAL
+The user's preferred utility to edit text files.
+Any string acceptable as a command_string operand to the
+.I sh\ \-c
+command shall be valid. Defined by POSIX.1-2017.
+.\" .TP
+.\" .B BROWSER
+.\" The user's preferred utility to browse URLs. Sequence of colon-separated
+.\" browser commands. See http://www.catb.org/\(tiesr/BROWSER/ .
 .SH COMMON ENVIRONMENT VARIABLES
 Note that the behavior of many programs and library routines is
 influenced by the presence or value of certain environment variables.
 Examples include the following:
 .IP * 3
-.B TMPDIR
-influences the path prefix of names created by
-.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.
-.IP *
 .BR LD_LIBRARY_PATH ", " LD_PRELOAD ,
 and other
 .BR LD_*
-- 
2.29.2

Bug#981171: [PATCH 10/13] Introduce ENVIRONMENT section

[roucaries . bastien]

From: Bastien Roucariès 

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 92 +++---
 1 file changed, 49 insertions(+), 43 deletions(-)

diff --git a/man7/environ.7 b/man7/environ.7
index f2786fa09..96d47be9f 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -108,7 +108,55 @@ it inherits a
 .I copy
 of its parent's environment.
 .PP
-Common examples are:
+Environment variables may be placed in the shell's environment by the
+.I export
+command in
+.BR sh (1),
+or by the
+.I setenv
+command if you use
+.BR csh (1).
+.PP
+The initial environment of the shell is populated in various ways,
+such as definitions from
+.IR /etc/environment
+that are processed by
+.BR pam_env (8)
+for all users at login time (on systems that employ
+.BR pam (8)).
+In addition, various shell initialization scripts, such as the system-wide
+.IR /etc/profile
+script and per-user initialization scripts may include commands
+that add variables to the shell's environment;
+see the manual page of your preferred shell for details.
+.PP
+Bourne-style shells support the syntax
+.PP
+NAME=value command
+.PP
+to create an environment variable definition only in the scope
+of the process that executes
+.IR command .
+Multiple variable definitions, separated by white space, may precede
+.IR command .
+.PP
+Arguments may also be placed in the
+environment at the point of an
+.BR exec (3).
+A C program can manipulate its environment using the functions
+.BR getenv (3),
+.BR putenv (3),
+.BR setenv (3),
+and
+.BR unsetenv (3).
+.PP
+What follows is a list of environment variables typically seen on a
+system. This list is incomplete and includes only common variables seen
+by average users in their day-to-day routine.
+Environment variables specific to a particular program or library function
+are documented in the ENVIRONMENT section of the appropriate manual page.
+.SH ENVIRONMENT
+Common examples of environment variables are:
 .TP
 .B USER
 The name of the logged-in user (used by some BSD-derived programs).
@@ -196,48 +244,6 @@ command shall be valid.
 .\" The user's preferred utility to browse URLs. Sequence of colon-separated
 .\" browser commands. See http://www.catb.org/\(tiesr/BROWSER/ .
 .PP
-Names may be placed in the shell's environment by the
-.I export
-command in
-.BR sh (1),
-or by the
-.I setenv
-command if you use
-.BR csh (1).
-.PP
-The initial environment of the shell is populated in various ways,
-such as definitions from
-.IR /etc/environment
-that are processed by
-.BR pam_env (8)
-for all users at login time (on systems that employ
-.BR pam (8)).
-In addition, various shell initialization scripts, such as the system-wide
-.IR /etc/profile
-script and per-user initializations script may include commands
-that add variables to the shell's environment;
-see the manual page of your preferred shell for details.
-.PP
-Bourne-style shells support the syntax
-.PP
-NAME=value command
-.PP
-to create an environment variable definition only in the scope
-of the process that executes
-.IR command .
-Multiple variable definitions, separated by white space, may precede
-.IR command .
-.PP
-Arguments may also be placed in the
-environment at the point of an
-.BR exec (3).
-A C program can manipulate its environment using the functions
-.BR getenv (3),
-.BR putenv (3),
-.BR setenv (3),
-and
-.BR unsetenv (3).
-.PP
 Note that the behavior of many programs and library routines is
 influenced by the presence or value of certain environment variables.
 Examples include the following:
-- 
2.29.2

Bug#981171: [PATCH 11/13] Reorganize the different environment section

[roucaries . bastien]

From: Bastien Roucariès 

Introduce a Posix defined environment, other and internalization

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 69 +-
 1 file changed, 34 insertions(+), 35 deletions(-)

diff --git a/man7/environ.7 b/man7/environ.7
index 96d47be9f..236025035 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -152,15 +152,14 @@ and
 .PP
 What follows is a list of environment variables typically seen on a
 system. This list is incomplete and includes only common variables seen
-by average users in their day-to-day routine.
+by average users in their day-to-day routine. Care should be taken
+to not conflict with the variables specified in the next sections.
 Environment variables specific to a particular program or library function
 are documented in the ENVIRONMENT section of the appropriate manual page.
-.SH ENVIRONMENT
-Common examples of environment variables 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.
+.SH POSIX STANDARD ENVIRONMENT
+Common examples of environment variables defined by POSIX.1-2017 are defined 
in the following
+section. Conforming applications shall not set these environment variables to 
have
+meanings other than as described.
 .TP
 .B LOGNAME
 The name of the logged-in user (used by some System-V derived programs
@@ -171,24 +170,6 @@ Set at login time, see section NOTES below.
 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
-by
-.B LC_ALL
-or more specific environment variables such as
-.BR LC_COLLATE ,
-.BR LC_CTYPE ,
-.BR LC_MESSAGES ,
-.BR LC_MONETARY ,
-.BR LC_NUMERIC ,
-and
-.BR LC_TIME
-(see
-.BR locale (7)
-for further details of the
-.BR LC_*
-environment variables).
-.TP
 .B PATH
 The list of places that shells and other programs look in to find
 a command when given an incomplete pathname. Elements on this
@@ -243,20 +224,34 @@ command shall be valid.
 .\" .B BROWSER
 .\" The user's preferred utility to browse URLs. Sequence of colon-separated
 .\" browser commands. See http://www.catb.org/\(tiesr/BROWSER/ .
-.PP
+.SH INTERNATIONALIZATION ENVIRONMENT VARIABLES
+.TP
+.B LANG
+The name of a locale to use for locale categories when not overridden
+by
+.B LC_ALL
+or more specific environment variables such as
+.B LC_COLLATE ,
+.B LC_CTYPE ,
+.B LC_MESSAGES ,
+.B LC_MONETARY ,
+.B LC_NUMERIC ,
+and
+.BR LC_TIME.
+See
+.BR catopen (3),
+.BR gettext (3),
+.BR locale (7)
+for further details of the
+.B LANG
+and
+.B LC_*
+environment variables.
+.SH COMMON ENVIRONMENT VARIABLES
 Note that the behavior of many programs and library routines is
 influenced by the presence or value of certain environment variables.
 Examples include the following:
 .IP * 3
-The variables
-.BR LANG ", " LANGUAGE ", " NLSPATH ", " LOCPATH ,
-.BR LC_ALL ", " LC_MESSAGES ,
-and so on influence locale handling; see
-.BR catopen (3),
-.BR gettext (3),
-and
-.BR locale (7).
-.IP *
 .B TMPDIR
 influences the path prefix of names created by
 .BR mktemp (1),
@@ -289,6 +284,10 @@ gives the name of a file containing aliases
 to be used with
 .BR gethostbyname (3).
 .IP *
+.B USER
+The name of the logged-in user (used by some BSD-derived programs).
+Set at login time, see section NOTES below.
+.IP *
 .BR TZ " and " TZDIR
 give timezone information used by
 .BR tzset (3)
-- 
2.29.2

Bug#981171: [PATCH 09/13] Document convention of string in environ

[roucaries . bastien]

From: Bastien Roucariès 

Document the name=value system and that nul byte is forbidden

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/man7/environ.7 b/man7/environ.7
index f9e49a572..f2786fa09 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -90,6 +90,15 @@ current language, etc., and a user can define additional 
variables for other pur
 The set of all environment variables that have values is collectively known as
 the process environment or simply the environment.
 .PP
+By convention, the strings in
+.I environ
+have the form "\fIname\fP\fB=\fP\fIvalue\fP".
+Names of environment variables are case-sensitive and must not contain
+the character "\fB=\fP". The values of environment variables can be anything
+that can be represented as a string. A value and a name must not contain an
+embedded null byte (\(aq\e0\(aq),
+since this is assumed to terminate the string.
+.PP
 This array of strings is made available to the process by the
 .BR exec (3)
 call that started the process.
@@ -99,9 +108,6 @@ it inherits a
 .I copy
 of its parent's environment.
 .PP
-By convention the strings in
-.I environ
-have the form "\fIname\fP\fB=\fP\fIvalue\fP".
 Common examples are:
 .TP
 .B USER
-- 
2.29.2

Bug#981171: [PATCH 08/13] Better documentation of the environment mechanism

[roucaries . bastien]

From: Bastien Roucariès 

Compare with argc/argv and describe the purpose of environment
---
 man7/environ.7 | 24 
 1 file changed, 24 insertions(+)

diff --git a/man7/environ.7 b/man7/environ.7
index 7eeb1fe0e..f9e49a572 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -66,6 +66,30 @@ if the
 feature test macro is defined (see
 .BR feature_test_macros(7)).
 .PP
+At time of execution, a program receives context information by two mechanisms.
+The first way is the program arguments, represented by the
+.I argc
+and
+.I argv
+arguments of the
+.I main
+function. The second is the
+.I environ
+variable as discussed in this manual.
+.PP
+The program arguments are typically used to pass so-called
+command-line arguments specific to a particular use of the program
+being invoked, thus changing the program's behavior for this use case.
+The environment, on the other hand, keeps track of information that is shared 
by many programs and
+rarely changes. For example, a running process can query the value of the
+.B TMDIR
+environment variable to discover a suitable location to store temporary files.
+.PP
+Standard environment variables are used for information about the user' home 
directory,
+current language, etc., and a user can define additional variables for other 
purposes.
+The set of all environment variables that have values is collectively known as
+the process environment or simply the environment.
+.PP
 This array of strings is made available to the process by the
 .BR exec (3)
 call that started the process.
-- 
2.29.2

Bug#981171: [PATCH 07/13] Better documentation of _GNU_SOURCE for environment

[roucaries . bastien]

From: Bastien Roucariès 

Use feature_test_macros and document that historically
you should manually declare it.
---
 man7/environ.7 | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/man7/environ.7 b/man7/environ.7
index 981038ea1..7eeb1fe0e 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -36,19 +36,36 @@
 environ \- user environment
 .SH SYNOPSIS
 .nf
+.B #include 
+.PP
 .BI "extern char **" environ ;
 .fi
+.PP
+.RS -4
+Feature Test Macro Requirements for glibc (see
+.BR feature_test_macros (7)):
+.RE
+.PP
+.I environ:
+.nf
+_GNU_SOURCE
+.fi
 .SH DESCRIPTION
 The variable
 .I environ
 points to an array of pointers to strings called the "environment".
 The last pointer in this array has the value NULL.
-(This variable must be declared in the user program,
-but is declared in the header file
+.PP
+Historically and by standard, this variable must be declared in the user 
program,
+but for programmer convenience
+.I environ
+is also declared in the header file
 .I 
 if the
 .B _GNU_SOURCE
-feature test macro is defined.)
+feature test macro is defined (see
+.BR feature_test_macros(7)).
+.PP
 This array of strings is made available to the process by the
 .BR exec (3)
 call that started the process.
@@ -380,6 +397,7 @@ should use instead an explicit \(aq\fB.\fP\(aq.
 .BR putenv (3),
 .BR setenv (3),
 .BR unsetenv (3),
+.NR feature_test_macros(7),
 .BR locale (7),
 .BR ld.so (8),
 .BR pam_env (8)
-- 
2.29.2

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

[roucaries . bastien]

From: Bastien Roucariès 

More is the default pager in a lot of system mention it
---
 man7/environ.7 | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/man7/environ.7 b/man7/environ.7
index 81932d894..981038ea1 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -132,7 +132,12 @@ The terminal type for which output is to be prepared.
 The user's preferred utility to display text files.
 Any string acceptable as a command_string operand to the
 .I sh\ \-c
-command shall be valid.
+command shall be valid. If the
+.B PAGER
+variable is null or not set,
+command could fall back
+.B more (1)
+or any suitable paging utility as the system default.
 .TP
 .BR EDITOR / VISUAL
 The user's preferred utility to edit text files.
@@ -362,6 +367,7 @@ should use instead an explicit \(aq\fB.\fP\(aq.
 .BR env (1),
 .BR login (1),
 .BR mktemp (1),
+.BR more (1),
 .BR printenv (1),
 .BR sh (1),
 .BR su (1),
-- 
2.29.2

Bug#981171: [PATCH 05/13] Add see also ld.so (8) for LD_ variables

[roucaries . bastien]

From: Bastien Roucariès 

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/man7/environ.7 b/man7/environ.7
index 11f30c332..81932d894 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -212,7 +212,8 @@ and other programs.
 .BR LD_LIBRARY_PATH ", " LD_PRELOAD ,
 and other
 .BR LD_*
-variables influence the behavior of the dynamic loader/linker.
+variables influence the behavior of the dynamic loader/linker. See also
+.B ld.so (8)
 .IP *
 .B POSIXLY_CORRECT
 makes certain programs and library routines follow
-- 
2.29.2

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

[roucaries . bastien]

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).
 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.
 .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),
 .BR getenv (3),
 .BR putenv (3),
 .BR setenv (3),
-- 
2.29.2

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

[roucaries . bastien]

From: Bastien Roucariès 

Clearly document that su by default does not change this variables.

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),
-- 
2.29.2

Bug#981171: [PATCH 02/13] Add a note about portability of environment variable

[roucaries . bastien]

From: Bastien Roucariès 

Some variables are portable at least under UNIX

Signed-off-by: Bastien Roucariès 
---
 man7/environ.7 | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/man7/environ.7 b/man7/environ.7
index d889310d6..ec886d83d 100644
--- a/man7/environ.7
+++ b/man7/environ.7
@@ -242,6 +242,17 @@ tell applications about the window size, possibly 
overriding the actual size.
 may specify the desired printer to use.
 See
 .BR lpr (1).
+.SH CONFORMING TO
+The variables
+.B HOME
+.B LOGNAME,
+.B PATH,
+.B PWD,
+and
+.B SHELL
+are specified by
+POSIX.1-1996
+and should be reasonably portable.
 .SH NOTES
 The
 .BR prctl (2)
-- 
2.29.2

Bug#981171: Environment 7 improvments

[roucaries . bastien]

Hi,

Could you find a serie for better documenting environment


[PATCH 01/13] Do not document mktemp (3)
[PATCH 02/13] Add a note about portability of environment variable
[PATCH 03/13] Document that means at login time for HOME, LOGNAME,
[PATCH 04/13] Document PATH resolution
[PATCH 05/13] Add see also ld.so (8) for LD_ variables
[PATCH 06/13] Improve pager section by pointing to more
[PATCH 07/13] Better documentation of _GNU_SOURCE for environment
[PATCH 08/13] Better documentation of the environment mechanism
[PATCH 09/13] Document convention of string in environ
[PATCH 10/13] Introduce ENVIRONMENT section
[PATCH 11/13] Reorganize the different environment section
[PATCH 12/13] Introduce the user custumization section
[PATCH 13/13] Document LINES and COLUMNS

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

[roucaries . bastien]

From: Bastien Roucariès 

Do not use for documentation purposes the unsecure mktemp function

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),
-- 
2.29.2

Bug#964198: hylafax: diff for NMU version 3:6.0.7-3.1

[roucaries . bastien]

Control: tags 964198 + patch
Control: tags 964198 + pending
Control: tags 978220 + patch
Control: tags 978220 + pending


Dear maintainer,

I've prepared an NMU for hylafax (versioned as 3:6.0.7-3.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru hylafax-6.0.7/debian/changelog hylafax-6.0.7/debian/changelog
--- hylafax-6.0.7/debian/changelog  2020-03-28 09:26:49.0 +
+++ hylafax-6.0.7/debian/changelog  2021-01-13 13:00:13.0 +
@@ -1,3 +1,23 @@
+hylafax (3:6.0.7-3.1) unstable; urgency=medium
+
+  * NMU
+  * Bug fix: "FTBFS: Incompatible TIFF Library.", thanks to Lucas Nussbaum
+(Closes: #978220).
+  * Bug fix: "CVE-2020-15397 CVE-2020-15396", thanks to Moritz Muehlenhoff
+(Closes: #964198):
+- The faxsetup utility 
+  calls chown on files in user-owned directories.
+  By winning a race, a local attacker could use
+  this to escalate his privileges to root.
+- Scripts that execute binaries from directories 
+  writable by unprivileged users (e.g., locations under
+  /var/spool/hylafax that are 
+  writable by the uucp account). This allows these users to
+  execute code in the context of the user calling these binaries
+  (often root).
+
+ -- Bastien Roucariès   Wed, 13 Jan 2021 13:00:13 +
+
 hylafax (3:6.0.7-3) unstable; urgency=medium
 
   * Added logrotate configuration for /var/spool/hylafax/log/xferfaxlog
diff -Nru hylafax-6.0.7/debian/patches/832_fix_FTBFS_with_newer_libtiff.patch 
hylafax-6.0.7/debian/patches/832_fix_FTBFS_with_newer_libtiff.patch
--- hylafax-6.0.7/debian/patches/832_fix_FTBFS_with_newer_libtiff.patch 
1970-01-01 00:00:00.0 +
+++ hylafax-6.0.7/debian/patches/832_fix_FTBFS_with_newer_libtiff.patch 
2021-01-13 12:34:16.0 +
@@ -0,0 +1,20 @@
+Subject: Fix FTBFS with newer libtiff
+author: Bastien Roucariès 
+
+Allow newer libtiff in configure
+
+bug-debian: https://bugs.debian.org/978220
+
+Index: hylafax-6.0.7/configure
+===
+--- hylafax-6.0.7.orig/configure
 hylafax-6.0.7/configure
+@@ -2572,7 +2572,7 @@ EOF
+   tiff_offset_t="uint32"
+   tiff_bytecount_t="uint32"
+   ;;
+-  4.[01]) tiff_runlen_t="uint32"
++  4.[0-9])tiff_runlen_t="uint32"
+   tiff_offset_t="uint64"
+   tiff_bytecount_t="uint64"
+   echo '#define TIFFHeader
TIFFHeaderClassic'
diff -Nru hylafax-6.0.7/debian/patches/833_fix_insecure_directory.patch 
hylafax-6.0.7/debian/patches/833_fix_insecure_directory.patch
--- hylafax-6.0.7/debian/patches/833_fix_insecure_directory.patch   
1970-01-01 00:00:00.0 +
+++ hylafax-6.0.7/debian/patches/833_fix_insecure_directory.patch   
2021-01-13 12:55:29.0 +
@@ -0,0 +1,100 @@
+Subject: Fix insecure directory creation
+author: Johannes Segitz
+
+Secure temporary directory creation for faxsetup, faxaddmodem, and
+probemodem (13 Jun 2020)
+secure the HylaFAX spool directory bin and etc subdirs 
+
+In HylaFAX+ through 7.0.2 and HylaFAX Enterprise, the faxsetup utility 
+calls chown on files in user-owned directories. By winning a race, a local 
attacker could use this to escalate his privileges to root.
+
+HylaFAX+ through 7.0.2 and HylaFAX Enterprise have scripts that execute 
binaries from directories 
+writable by unprivileged users (e.g., locations under /var/spool/hylafax that 
are 
+writable by the uucp account). This allows these users to execute code in the 
context of the user calling these binaries (often root).
+
+This fix CVE-2020-15396 and CVE-2020-15397
+bug-debian: https://bugs.debian.org/964198
+origin: https://sourceforge.net/p/hylafax/HylaFAX+/2534/
+
+Index: hylafax-6.0.7/Makefile.in
+===
+--- hylafax-6.0.7.orig/Makefile.in
 hylafax-6.0.7/Makefile.in
+@@ -231,7 +231,10 @@ makeServerDirs::
+   -idb hylafax.sw.server -dir ${SPOOL}
+   -${INSTALL} -u ${FAXUSER} -g ${FAXGROUP} -m ${DIRMODE} \
+   -idb hylafax.sw.server -dir \
+-  -F ${SPOOL} bin client config dev etc info log recvq status
++  -F ${SPOOL} client config dev info log recvq status
++  -${INSTALL} -u root -g root -m ${DIRMODE} \
++  -idb hylafax.sw.server -dir \
++  -root ${INSTALLROOT} -F ${SPOOL} bin etc
+   -${INSTALL} -u ${FAXUSER} -g ${FAXGROUP} -m 700 \
+   -idb hylafax.sw.server -dir \
+   -F ${SPOOL} sendq doneq docq tmp pollq archive
+Index: hylafax-6.0.7/etc/faxaddmodem.sh.in
+===
+--- hylafax-6.0.7.orig/etc/faxaddmodem.sh.in
 hylafax-6.0.7/etc/faxaddmodem.sh.in
+@@ -108,12 +108,14 @@ if [ "$euid" != "root" ]; then
+ fi

Bug#905769: node-toidentifier: Unnecessary $(DEB_BUILD_PROFILES) check?

[roucaries bastien]

On Thu, Aug 9, 2018 at 11:36 AM Chris Lamb  wrote:
>
> Source: node-toidentifier
> Version: 1.0.0-1
> Severity: wishlist
> X-Debbugs-CC: Bastien Roucaris ,
> ftpmas...@debian.org
>
> Hi,
>
> I just ACCEPTed node-toidentifier from NEW but was wondering if:
>
>ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES)))
>
> .. should really be checking (only) DEB_BUILD_OPTIONS?

It is a feature that dpkg-buildpackage -P nocheck does not set
DEB_BUILD_OPTIONS.

My solution above is policy compliant and allow to test nocheck with
dpkg-buildpackage

Bastien

>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#904852: lintian: package-contains-documentation-outside-usr-share-doc far too overzealous

[roucaries bastien]

On Tue, Aug 7, 2018 at 3:54 PM Chris Lamb  wrote:
>
> Chris Lamb wrote:
>
> > > the phrase "Please move this files to /usr/share/doc/ or remove it."
> > > sounds very final, but completely ignores that there are quite a lot of
> > > files (often named README or so) documenting the purpose or contents of
> > > the directory they're in.
> >
> > I agree. Bastian, you added this in #901274 — can you chime in here? I
> > am not the greatest fan of this tag, and have already skipped it in some
> > of my own packages which is not the best sign from a Lintian maintainer...
>
> Gentle ping on this, Bastian? :)

Done will check only this directory in README.*
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#905746: node-code: Please clarify/tidy original origin of module

[roucaries bastien]

Ok will clarifiy.

It is inpired by node chai but it is a full rewrite
On Wed, Aug 8, 2018 at 10:57 PM Chris Lamb  wrote:
>
> Source: node-code
> Version: 5.2.0-1
> Severity: wishlist
> X-Debbugs-CC: Bastien Roucaris ,
> ftpmas...@debian.org
>
> Hi,
>
> I just ACCEPTed node-code from NEW but was wondering if you could
> clarify in debian/copyright that it is based on original work by
> someone called "Chai".
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#901931: the soundsystem still breaks after todays timidity and timidity-daemon upgrade to 2.14.0-8

[roucaries bastien]

please do an apt-get remove timidity-daemon if you do not need it

Bastien

On Sat, Jun 30, 2018 at 10:04 AM, Markus Steinko  wrote:
> Dear Maintainer,
>
> sadly the bug still appears after todays system upgrade, which also upgraded
> timidity and timidity-daemon to version 2.14.0-8.
>
> What kind of system information do you need to reproduce the situation?
>
> Kind regards,

Bug#902448: timidity: Breaks: timidity-daemon (>= 2.14.0-1~) but 2.14.0-5 is to be installed

[roucaries bastien]

Fixed uploaded.

BTW this package is a security trap.

I plan to open a few CVEs.

Did you have wrd karaoke file ? I plan to drop this feature if i could not test

bastien

On Wed, Jun 27, 2018 at 12:59 PM, Reiner Herrmann  wrote:
> On Wed, Jun 27, 2018 at 12:53:05PM +0200, Guillem Jover wrote:
>> > Most likely you meant to break timidity-daemon (<= 2.14.0-1~) rather
>> > than (>= 2.14.0-1~).
>>
>> I'm not sure that'd be correct either. From the bug that this was
>> supposed to fix (because the changelog description is not clear on
>> what was broken and what was the fix), this seems to be a new behavior
>> from timidity-daemon starting in that version, which does not play nice
>> when pulseaudio is also in the system, and both fight for exclusive
>> access to the sound devices.
>>
>> But this seems to be both a (perhaps temporary) workaround (why not
>> instead try to diagnose why timidity-daemon now requires exclusive
>> access to the sound devices?), and in the wrong place (if the problem
>> is with pulseaudio, then either of the packages need to possibly Break
>> the other, but not between timidity and timidity-daemon, I for one do
>> not have pulseaudio on this particular system for example).
>
> I also don't think that a Break is required here at all.
> If it needs to start after pulseaudio because otherwise the sound device
> is blocked, maybe the Required-Start field in the init script needs to
> be changed (to $all).
> (Maybe that was a regression from the last upgrade that the init script
> is started earlier.)
>
> Regards,
>   Reiner

Bug#898273: [lintian] Detect conflict between package.json version and debian control version

[roucaries bastien]

On Thu, May 10, 2018 at 10:56 PM, Chris Lamb  wrote:
> Hi Bastien,
>
>> - for every depends in package.json check debian control depends
>   ^^^
> Do you mean in the "devDependencies" key?

no the Dependencies key, the devDependencies should be checked against
source package depends

>Clarification on exactly
> what "check" means here would be needed here too; whilst your bug
> title says "detect conflict", that doesn't strictly include the
> case of missing dependencies, just as one example..

missing dependencies could be detected but worst is conflicts. It is
regression prone.
>
>> - for every optionnal depends on package.json check debian control
>> suggest or recommand
>
> Did you mean "*in* package.json" (not "on package.json")? If so, I was
> not aware package.json have optional dependencies.

Yes, in package.json, they are optional (seldom used) depends
>
> (Isn't this stuff autogenerated from the package.json by somen? Then
> there could not be a conflict...)
No it is manually done... I know crap over crap. Lintian is good for
cleaning, so use lintian

>
> Anyway, I'm sorry can't seem to prase what you are saying and there is
> quite a bit of ambiguity.

No problem.

I am on irc in case of problem

Bastien

>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#898273: [lintian] Detect conflict between package.json version and debian control version

[roucaries bastien]

On Wed, May 9, 2018 at 8:34 PM, Chris Lamb  wrote:
> Hi Bastien,
>
>> If package is section javascript search all file named package.json, parse it
>> and control against control depends (including optional that go to recommand
>   
>> or suggest).
>   ^^

Ok test will be run:
- unless section javascript bail out
- for every depends in package.json check debian control depends
- for every optionnal depends on package.json check debian control
suggest or recommand

bastien


>
> I can't parse this, sorry. Could you rephrase? :)
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#873102: [release.debian.org] transition: imagemagick

[roucaries bastien]

On Fri, Feb 16, 2018 at 3:02 PM, Emilio Pozuelo Monfort
<po...@debian.org> wrote:
> Control: tags -1 confirmed

Done waiting from your side
>
> On 16/02/18 14:30, roucaries bastien wrote:
>> On Wed, Oct 25, 2017 at 2:02 PM, roucaries bastien
>> <roucaries.bastien+deb...@gmail.com> wrote:
>>> On Sat, Oct 21, 2017 at 6:26 PM, Emilio Pozuelo Monfort
>>> <po...@debian.org> wrote:
>>>> Control: retitle -1 transition: imagemagick
>>>> Control: severity -1 normal
>>>>
>>>> On 24/08/17 17:21, Bastien ROUCARIÈS wrote:
>>>>> Package: release.debian.org
>>>>> Severity: important
>>>>>
>>>>> Hi,
>>>>>
>>>>> I have just landed an imagemagick version in experimental, that break the 
>>>>> ABI.
>>>>> Previous ABI used double_t that is not ABI stable...
>>>>>
>>>>> Could we get a transition of libmagickcore, libmagickwand and libmagick++
>>>>>
>>>>> I have rebuilded reverse deps a few week ago (waiting for ftpmaster) and 
>>>>> it
>>>>> was fine.
>>>>>
>>>>> I will fix ASAP the problems.
>>>>
>>>> What problems?
>>>>
>>>> FWIW this can't start until imagemagick builds on all release 
>>>> architectures:
>>>>
>>>> https://buildd.debian.org/status/package.php?p=imagemagick=experimental
>>>
>>> Smell like a compiler bug :S
>>
>> Fixed, could you please go for transition. Due to huge backlog of
>> security problem the sooener the better
>
> Go ahead.
>
> Emilio

Bug#873102: [release.debian.org] transition: imagemagick

[roucaries bastien]

On Wed, Oct 25, 2017 at 2:02 PM, roucaries bastien
<roucaries.bastien+deb...@gmail.com> wrote:
> On Sat, Oct 21, 2017 at 6:26 PM, Emilio Pozuelo Monfort
> <po...@debian.org> wrote:
>> Control: retitle -1 transition: imagemagick
>> Control: severity -1 normal
>>
>> On 24/08/17 17:21, Bastien ROUCARIÈS wrote:
>>> Package: release.debian.org
>>> Severity: important
>>>
>>> Hi,
>>>
>>> I have just landed an imagemagick version in experimental, that break the 
>>> ABI.
>>> Previous ABI used double_t that is not ABI stable...
>>>
>>> Could we get a transition of libmagickcore, libmagickwand and libmagick++
>>>
>>> I have rebuilded reverse deps a few week ago (waiting for ftpmaster) and it
>>> was fine.
>>>
>>> I will fix ASAP the problems.
>>
>> What problems?
>>
>> FWIW this can't start until imagemagick builds on all release architectures:
>>
>> https://buildd.debian.org/status/package.php?p=imagemagick=experimental
>
> Smell like a compiler bug :S

Fixed, could you please go for transition. Due to huge backlog of
security problem the sooener the better

Bug#873102: [release.debian.org] transition: imagemagick

[roucaries bastien]

On Sat, Oct 21, 2017 at 6:26 PM, Emilio Pozuelo Monfort
 wrote:
> Control: retitle -1 transition: imagemagick
> Control: severity -1 normal
>
> On 24/08/17 17:21, Bastien ROUCARIÈS wrote:
>> Package: release.debian.org
>> Severity: important
>>
>> Hi,
>>
>> I have just landed an imagemagick version in experimental, that break the 
>> ABI.
>> Previous ABI used double_t that is not ABI stable...
>>
>> Could we get a transition of libmagickcore, libmagickwand and libmagick++
>>
>> I have rebuilded reverse deps a few week ago (waiting for ftpmaster) and it
>> was fine.
>>
>> I will fix ASAP the problems.
>
> What problems?
>
> FWIW this can't start until imagemagick builds on all release architectures:
>
> https://buildd.debian.org/status/package.php?p=imagemagick=experimental

Smell like a compiler bug :S



>
>> I have set the severity to important because I will prefer to get quickly a
>> newer imagemagick version due to the number of security bug to backport
>
> Don't do that, and please use reportbug to get the necessary usertags.
>
> Cheers,
> Emilio

Bug#873744: RFS: liboauth/1.0.3-1 [QA-upload]

[roucaries bastien]

On Sat, Sep 2, 2017 at 3:29 PM, Mattia Rizzolo <mat...@debian.org> wrote:
> On Sat, Sep 02, 2017 at 03:23:46PM +0200, roucaries bastien wrote:
>> I can sponsor but I will need to be the maintainer of this package not 
>> debian-qa
>
> ?
> *you* will need to be the maintainer?  That doesn't make sense for QA
> upload.
>
> BTW, QA uploads do keep Debian QA as maintainer, see
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-qa-upload

Sorry send for a phone with french correction. I means that I will
prefer that carlos maddela will become the maint of this package.

It is a huge changelog for a qa upload.

Bastien
> --
> 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#873744: RFS: liboauth/1.0.3-1 [QA-upload]

[roucaries bastien]

I can sponsor but I will need to be the maintainer of this package not debian-qa

On Wed, Aug 30, 2017 at 6:01 PM, Carlos Maddela  wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
>   I am looking for a sponsor for my package "liboauth"
>
>  * Package name: liboauth
>Version : 1.0.3-1
>Upstream Author : Robin Gareus 
>  * URL : http://liboauth.sourceforge.net/
>  * License : Expat
>Section : libs
>
>   It builds these binary packages:
>
> liboauth-dev - C library implementing OAuth Core 1.0a API (development 
> files)
> liboauth0  - C library implementing OAuth Core 1.0a API (runtime)
>
>   To access further information about this package, please visit the 
> following URL:
>
>   https://mentors.debian.net/package/liboauth
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x 
> https://mentors.debian.net/debian/pool/main/libo/liboauth/liboauth_1.0.3-1.dsc
>
>   More information about my changes can be obtained from this git repo:
>   https://github.com/e7appew/pkg-liboauth.git.
>
>   Changes since the last upload:
>
>   * QA upload.
>   * New upstream release [1.0.3].
>   * Bump Standards-Version to 4.1.0 and debhelper compat level to 10.
>   * debian/control:
> - Update maintainer to Debian QA Group.
> - Update VCS URLs to use secure protocols.
> - Mark liboauth-dev package as Multi-Arch: same.
> - Rewrite package descriptions. Thanks to Martin Eberhard Schauer
>   and Justin B Rye. (Closes: #654334)
> - Perform wrap-and-sort.
> - Add build dependency on curl.
>   * debian/rules:
> - Simplify clean-up rule.
> - Build with all hardening flags set.
> - Suppress warnings about use of deprecated functions.
> - Enable LFS support on 32-bit architectures.
>   * Update library's symbols file to include the functions available
> when built with command-line curl feature.
>   * Suppress debian-watch-may-check-gpg-signature Lintian warning.
>   * debian/copyright:
> - Update details.
> - Remove redundancy.
> - Use Expat as license identifier, in preference to MIT, since
>   it matches this specifically.
>   * debian/patches/*:
> - Regenerate with git-buildpackage.
> - Drop 01_fix_manpage_spelling_errors.patch already applied upstream.
> - Fix newly detected typos in man page.
> - Update configure.ac for Autoconf 2.69.
> - Update Makefile.am files for Automake 1.15.
>
>   Regards,
>Carlos Maddela
>

Bug#862930: RFS: node-big-integer/1.6.22-1 [ITP]

[roucaries bastien]

Do not know depends if it is easy to patch depends

On Sat, Aug 26, 2017 at 5:52 PM, Pierre Rudloff <pie...@rudloff.pro> wrote:
> Hello,
>
> Sorry, I was on vacation.
>
> node-bn is indeed a very similar library. Should we abandon the
> node-big-integer package then?
>
> Regards,
>
>
>
> Le 26/08/2017 à 16:38, roucaries bastien a écrit :
>>
>> Does node-bn does the same ?
>>
>> Thanks
>>
>> On Sat, Aug 26, 2017 at 1:10 PM, Gianfranco Costamagna
>> <locutusofb...@debian.org> wrote:
>>>
>>> On Fri, 7 Jul 2017 10:04:49 + (UTC) Gianfranco Costamagna
>>> <locutusofb...@debian.org> wrote:
>>>>
>>>>
>>>>> I'm not sure what you mean.
>>>>> These are dev dependencies, they are used by big-integer developers to
>>>>> perform various development tasks, but they are not required to simply
>>>>> use the library so there is no point in packaging them in Debian.
>>>>> And they are *not* embedded in the package, they only appear in
>>>>> package.json.
>>>>
>>>>
>>>> this makes sense, thanks.
>>>> So the review goes to the next step.
>>>> 1) licenses are missing (even if not used in the binary package, the
>>>> copyright
>>>> should list all the licenses in the source code).
>>>> 2) please use the same copyright as upstream for Debian packaging, this
>>>> will make
>>>> patch upstreaming possible without having to explicitly relicense them
>>>
>>> ping
>>>
>>> G.
>>>>
>>>> G.
>>>>
>>>>
>

Bug#862930: RFS: node-big-integer/1.6.22-1 [ITP]

[roucaries bastien]

Does node-bn does the same ?

Thanks

On Sat, Aug 26, 2017 at 1:10 PM, Gianfranco Costamagna
 wrote:
> On Fri, 7 Jul 2017 10:04:49 + (UTC) Gianfranco Costamagna 
>  wrote:
>>
>>
>> >I'm not sure what you mean.
>> >These are dev dependencies, they are used by big-integer developers to
>> >perform various development tasks, but they are not required to simply
>> >use the library so there is no point in packaging them in Debian.
>> >And they are *not* embedded in the package, they only appear in
>> >package.json.
>>
>>
>> this makes sense, thanks.
>> So the review goes to the next step.
>> 1) licenses are missing (even if not used in the binary package, the 
>> copyright
>> should list all the licenses in the source code).
>> 2) please use the same copyright as upstream for Debian packaging, this will 
>> make
>> patch upstreaming possible without having to explicitly relicense them
>
> ping
>
> G.
>>
>> G.
>>
>>
>

Bug#873001: [debian-policy] get-orig-source documentation should include a pointer to devref and a minimal example

[roucaries bastien]

On Wed, Aug 23, 2017 at 6:29 PM, Russ Allbery  wrote:
> Bastien ROUCARIÈS  writes:
>
>> get-orig-source should include an example.
>
>> If you use uscan this is safe and policy compliant (maybe opening a bug
>> against dpkg-dev to get this rule by default)
>
>> cd "$(subst ",\",$(dir $(lastword $(MAKEFILE_LIST/.." && uscan --destdir 
>> $(subst ",\",$(CURDIR)) #"
>
>> We have a bug report for lintian asking for checking unsafe uscan, so I
>> was creating a compliant version
>
>> A footnote is suffisant
>
> I'm reasonably fluent in shell and make, and I still have absolutely no
> idea what that does.

you call the rules with something (using shebang or directly) make -f
somepath/package/debian/rules, uscan need to be excuted on
somepath/package/.

So you need to get the f parameter. Make get it in last entry of
$MAKEFILE_LIST, so, $(lastword $(MAKEFILE_LIST)) that return
somepath/package/debian/rules,

now we get the dir using $(dir ) and get one level up by ..
$(dir $(lastword $(MAKEFILE_LIST)))/..

Unfortunatly we need to escape, some char so use ' to quote and escape
it using $(subst  ',\', $(dir $(lastword $(MAKEFILE_LIST)))/..)

now i can cd:
$(subst  ',\', $(dir $(lastword $(MAKEFILE_LIST)))/..)

and do a uscan with DESTDIR (here the local dir) escaped:

Finnally:
cd $(subst  ',\', $(dir $(lastword $(MAKEFILE_LIST)))/..) && uscan
--destdir $(subst ",\",$(CURDIR)) #'

the #' at end if for emacs syntax highlight

Bastien


>
> Is there any way that we could help people out and have the correct thing
> to do be much, much simpler?  Just a single command invocation?
>
> --
> Russ Allbery (r...@debian.org)   

* do not expect something with name that include space

Bug#872996: RFS: node-unicode-tr51/9.0.0-1 ITP

[roucaries bastien]

control: tags -1 + moreinfo

On Wed, Aug 23, 2017 at 9:55 PM, roucaries bastien
<roucaries.bastien+deb...@gmail.com> wrote:
> control: owner -1 ro...@debian.org
>
> I take it
>
> On Wed, Aug 23, 2017 at 2:43 PM, Julien Puydt <julien.pu...@laposte.net> 
> wrote:
>> Package: sponsorship-requests
>> Severity: wishlist
>>
>>   Dear mentors,
>>
>>   I am looking for a sponsor for my package "node-unicode-tr51"
>>
>>  * Package name: node-unicode-tr51
>>Version : 9.0.0-1
>>Upstream Author : Mathias Bynens
>>  * URL : https://mths.be/unicode-tr51
>>  * License : Expat
>>Section : web
>>
>>   It builds those binary packages:
>>
>> node-unicode-tr51 - Emoji data for Node.js
>>
>>   To access further information about this package, please visit the
>> following URL:
>>
>>   https://mentors.debian.net/package/node-unicode-tr51
>>
>>
>>   Alternatively, one can download the package with dget using this command:
>>
>> dget -x
>> https://mentors.debian.net/debian/pool/main/n/node-unicode-tr51/node-unicode-tr51_9.0.0-1.dsc
>>
>>   It is packaged within the Debian Javascript Maintainers team:
>> Vcs-Git:
>> https://anonscm.debian.org/git/pkg-javascript/node-unicode-tr51.git
>> Vcs-Browser:
>> https://anonscm.debian.org/cgit/pkg-javascript/node-unicode-tr51.git
>>
>> Snark on #debian-js
>>
* debian/control:
   + section is javascript
   + you should use package.json version in source depends
   + Description is too short. Define emoji for instance. What contain
emoji data ?
 * copyright:
 please mention in general comment what I have just opened #873028
for adding emoji to unicode-data 
 * rules
  They are no guarantee that .js file are overwritten by script
and even in this case your package does not build cleanly. Better is
to create a debian/build directory (rm -rf during clean) that will get
a symlink of script and data. Than run script on it.
 * debian/test/mocha: please you a copy on my runtestsuite script. It
will use installed version instead of source
* debian/watch is 4

Bastien

Bug#872996: RFS: node-unicode-tr51/9.0.0-1 ITP

[roucaries bastien]

control: owner -1 ro...@debian.org

I take it

On Wed, Aug 23, 2017 at 2:43 PM, Julien Puydt  wrote:
> Package: sponsorship-requests
> Severity: wishlist
>
>   Dear mentors,
>
>   I am looking for a sponsor for my package "node-unicode-tr51"
>
>  * Package name: node-unicode-tr51
>Version : 9.0.0-1
>Upstream Author : Mathias Bynens
>  * URL : https://mths.be/unicode-tr51
>  * License : Expat
>Section : web
>
>   It builds those binary packages:
>
> node-unicode-tr51 - Emoji data for Node.js
>
>   To access further information about this package, please visit the
> following URL:
>
>   https://mentors.debian.net/package/node-unicode-tr51
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x
> https://mentors.debian.net/debian/pool/main/n/node-unicode-tr51/node-unicode-tr51_9.0.0-1.dsc
>
>   It is packaged within the Debian Javascript Maintainers team:
> Vcs-Git:
> https://anonscm.debian.org/git/pkg-javascript/node-unicode-tr51.git
> Vcs-Browser:
> https://anonscm.debian.org/cgit/pkg-javascript/node-unicode-tr51.git
>
> Snark on #debian-js
>

Bug#872753: RFS: node-regjsparser/0.2.1-1 ITP

[roucaries bastien]

On Mon, Aug 21, 2017 at 11:38 PM, Julien Puydt <julien.pu...@laposte.net> wrote:
> Hi,
>
> Le 21/08/2017 à 22:44, roucaries bastien a écrit :
>> On Mon, Aug 21, 2017 at 10:33 PM, roucaries bastien
>> <roucaries.bastien+deb...@gmail.com> wrote:
>>> control: owner -1 ro...@debian.org
>>>
>>> Will sponsor this one. Will review
>>>
>>> On Sun, Aug 20, 2017 at 9:59 PM, Andrey Rahmatullin <w...@debian.org> wrote:
>>>> Control: retitle -1 RFS: node-regjsparser/0.2.1-1 [ITP]
>>
>> * uscan is now 4
>
> Done.
>
>> *demo should be supplied as example
>
> I don't know how that demo is to be run, so I find it annoying to ship
> it as an example :-/
>
> Notice that the manpage I wrote has examples.
>
>> * test/*.json should be remove FTBFS (if you could regenerate you are
>> welcome to do)
>
> Same question as for nodejsgen : if it isn't used, do we still consider
> it FTBFS?
Yes repack is safer and bonus point package is smaller

>
>> * parser.js FTBFS search generated in source
>
> Darn. I had checked that we had the tool to generate it in node-esprima,
> but now I see it requires node-unicode-8.0.0, which we don't have :-(
>
>> * a smoketest will be welcome (readme.md seems to include something)
>
> I added one.
>
> The problem with parser.js is definitively a show stopper : that means
> I'll have to tackle the node-unicode-* packages issue sooner than I
> expected :-/
>
> Snark on #debian-js

Bug#872753: RFS: node-regjsparser/0.2.1-1 ITP

[roucaries bastien]

On Mon, Aug 21, 2017 at 10:33 PM, roucaries bastien
<roucaries.bastien+deb...@gmail.com> wrote:
> control: owner -1 ro...@debian.org
>
> Will sponsor this one. Will review
>
> On Sun, Aug 20, 2017 at 9:59 PM, Andrey Rahmatullin <w...@debian.org> wrote:
>> Control: retitle -1 RFS: node-regjsparser/0.2.1-1 [ITP]

* uscan is now 4
*demo should be supplied as example
* test/*.json should be remove FTBFS (if you could regenerate you are
welcome to do)
* parser.js FTBFS search generated in source
* a smoketest will be welcome (readme.md seems to include something)

Bastien

Bug#872753: RFS: node-regjsparser/0.2.1-1 ITP

[roucaries bastien]

control: owner -1 ro...@debian.org

Will sponsor this one. Will review

On Sun, Aug 20, 2017 at 9:59 PM, Andrey Rahmatullin  wrote:
> Control: retitle -1 RFS: node-regjsparser/0.2.1-1 [ITP]
>
> --
> WBR, wRAR

Bug#872808: [debian-policy] nocheck DEB_BUILD_OPTIONS DEB_BUILD_PROFILES

[roucaries bastien]

On Mon, Aug 21, 2017 at 9:14 PM, Jonathan Nieder  wrote:
> Hi Bastien,
>
> Bastien ROUCARIÈS wrote:
>
>> I think the following patch is needed even if profiles are not fully 
>> specified.
>> Maybe an example about nodoc and help2man will also help. The nocheck should
>> check both BUILD_OPTIONS and BUILD_PROFILES. It will help when implementing 
>> as
>> policy profiles
>>
>> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
>> index f706a13..d3d868c 100644
>> --- a/policy/ch-source.rst
>> +++ b/policy/ch-source.rst
>> @@ -465,7 +465,8 @@ The meaning of the following tags has been standardized:
>>
>>  ``nocheck``
>>  This tag says to not run any build-time test suite provided by the
>> -package.
>> +package. This tag could be also specified using
>> +   ``DEB_BUILD_PROFILES`` variable with nocheck flag
>>
>>  ``nodoc``
>>  This tag says to skip any build steps that only generate package
>> @@ -531,7 +532,7 @@ order to make it work for your package.
>>
>>  build:
>>  # ...
>> -ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
>> +ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS $DEB_BUILD_PROFILES)))
>>  # Code to run the package test suite.
>>  endif
>
> I am all for starting small in documenting build profiles (perhaps by
> documenting DEB_BUILD_PROFILES before the Build-Depends syntax) but it
> is possible to go too small.  This patch doesn't give context for what
> DEB_BUILD_PROFILES means and it makes policy harder to understand.
>
> In other words, if a patch
> - described what a build profile is
> - explained the DEB_BUILD_PROFILES environment variable
> - listed which values in that variable are required to be supported
>
> then that would already be enough for me to second it.  This patch
> doesn't do that.
>
> Do you mind if I merge this with bug#757760?

Feel free to do
>
> Thanks,
> Jonathan

Bug#849853: [debian-policy] Document source-is-missing lintian kind of problems

[roucaries bastien]

On Sun, Jul 2, 2017 at 11:54 AM, Sean Whitton  wrote:
> Hello Bastien,
>
> On Sun, Jan 01, 2017 at 01:45:34PM +0100, Bastien ROUCARIÈS wrote:
>> I get some problems when reporting bug detected by source-is-missing
>> tag in lintian.
>>
>> The main problems are:
>> * minified javascript is source
>> * I remove it using rules
>> * It is not a problems because not included in the binary forms
>>
>> [...]
>>
>> I believe we should offer on policy pointer to ftp master reject faq
>> and some description of common problems.
>
> Policy currently defers to the DFSG for a definition of what counts as
> free software for Debian's purposes.  Thanks to the DPL's delegation of
> the ftp-masters, Policy defers to the DFSG plus the ftp-masters jointly.
>
> If we included text in Policy about common ways in which a package could
> fail to satisfy DFSG, Policy would effectively cease to defer to the
> ftp-masters.  I don't think that Policy has the authority to do that,
> and I don't think it would be desirable.
>
> A footnote with a link to the REJECT-FAQ sounds useful.  Here's a patch.

Yes it will work thanks

>> Maybe it belong to devref.
>
> Perhaps that should be a separate bug, if we're going to use this one to
> discuss adding a footnote with a link to the REJECT-FAQ.
>
> --
> Sean Whitton

Bug#849851: [debian-policy] Document that rules clean target is not sufficient for removing dfsg problems

[roucaries bastien]

On Sun, Jul 2, 2017 at 11:22 AM, Sean Whitton  wrote:
> control: user debian-pol...@packages.debian.org
> control: usertag -1 +discussion
>
> Hello Bastien,
>
> On Sun, Jan 01, 2017 at 01:37:25PM +0100, Bastien ROUCARIÈS wrote:
>> Following #849830 and generally source-is-missing lintian problems
>> could you document in 4.9 Main building script: debian/rules that
>> clean target must no be used for removing dfsg problem but the right
>> tools is repack
>
> I don't think that it should be a point of Policy that the rules clean
> target is not to be used for this purpose, because it is entailed by
> the ftp-master's interpretation of DFSG plus this sentence that we
> already have in Policy:
>
> Every [source or binary] package in main must comply with the DFSG
> (Debian Free Software Guidelines).
>
> However, as you say, we should document this to prevent others from
> tripping over it.  As you suggest, such a note would need to refer to
> repacking the tarball.  The Developer's Reference already contains a
> discussion of repacking upstream tarballs, so perhaps this should go
> there?
>
> Or we could use a footnote to Policy.  I attach a patch doing that.

Really nice worded. Thank you

> --
> Sean Whitton

Bug#868184: [Pkg-gmagick-im-team] Bug#868184: CVE-2017-11141 CVE-2017-11166 CVE-2017-11170 CVE-2017-11188

[roucaries bastien]

I suppose I have already fille bug and are under TEMP under tracker

Bastien

On Wed, Jul 12, 2017 at 11:55 PM, Moritz Muehlenhoff  wrote:
> Source: imagemagick
> Severity: important
> Tags: security
>
> Please see:
>
> CVE-2017-11188:
> https://github.com/ImageMagick/ImageMagick/issues/509
>
> CVE-2017-11170:
> https://github.com/ImageMagick/ImageMagick/issues/472
>
> CVE-2017-11166:
> https://github.com/ImageMagick/ImageMagick/issues/471
>
> CVE-2017-11141:
> https://github.com/ImageMagick/ImageMagick/issues/469
> https://github.com/ImageMagick/ImageMagick/commit/353b942bd83da7e1356ba99c942848bd1871ee9f
>
> Cheers,
> Moritz
>
> ___
> Pkg-gmagick-im-team mailing list
> pkg-gmagick-im-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team

Bug#864151: [Pkg-gmagick-im-team] Bug#864151: imagemagick: Typo in debian/changelog for CVE identifier

[roucaries bastien]

On Sun, Jun 4, 2017 at 3:06 PM, Salvatore Bonaccorso  wrote:
> Source: imagemagick
> Version: 8:6.9.7.4+dfsg-11
> Severity: minor
>
> Hi
>
> There is a small typo in one of the CVE identifiers for the
> 8:6.9.7.4+dfsg-11:
>
>* Fix minor security bugs:
>  + CVE-2017-9409: Memory leak in the icon file coder.
>(Closes: #864087)
>
> which should be CVE-2017-9405.
>
> To avoid confusions for readers of debian/changelog, can you fix that
> in any furture upload retrospecitively?

They are also:

On Sat, May 27, 2017 at 04:06:53PM +, Bastien Roucaričs wrote:
>  + A crafted file revealed an assertion failure in profile.c.
>(Closes: #863124). Fix CVE-2017-9142.

Think that one was a typo right? Should be CVE-2017-9141. But I have
correctly tracked the fix in the security-tracker, so frime from that
POV.

Regards and thanks a lot for your amazing work,
Salvatore

Will do thanks for the bug

>
> Regards,
> Salvatore
>
> ___
> Pkg-gmagick-im-team mailing list
> pkg-gmagick-im-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team

Bug#863481: [Pkg-javascript-devel] Bug#863481: [node-concat-stream] Uninitialized Memory Exposure

[roucaries bastien]

I can do it but I do not know that is the best:
- let 1.6 go to unstable
- patch old version

Could you ask release team.

The debdiff between the two version is so small that I have doubt

On Sat, May 27, 2017 at 6:53 PM, Ross Gammon  wrote:
> Hi Bastien,
>
> If you would like me to prepare an upload to unstable for this (& unblock
> request), let me know. I have some time today & tomorrow - but travelling
> with work next week. I have DM upload rights for it.
>
> Only asking in case you are already working on it.
>
> Cheers,
>
> Ross
>
>
> On 05/27/2017 04:51 PM, Bastien ROUCARIÈS wrote:
>
> Package: node-concat-stream
> Version: 1.5.1-1
> Severity: grave
> Tags: patch security fixed-upstream fixed-in-experimental
> X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
> forwarded: https://snyk.io/vuln/npm:concat-stream:20160901
>
> Overview
>
> concat-stream is writable stream that concatenates strings or binary data
> and
> calls a callback with the result. Affected versions of the package are
> vulnerable to Uninitialized Memory Exposure.
>
> A possible memory disclosure vulnerability exists when a value of type
> number
> is provided to the stringConcat() method and results in concatination of
> uninitialized memory to the stream collection.
>
> This is a result of unobstructed use of the Buffer constructor, whose
> insecure
> default constructor increases the odds of memory leakage.
>
>
>
>

Bug#860939: node-diffie-hellman: Please clarify security concerns

[roucaries bastien]

control: forwarded -1
https://github.com/crypto-browserify/diffie-hellman/issues/22


On Sat, Apr 22, 2017 at 10:32 AM, Chris Lamb  wrote:
> Source: node-diffie-hellman
> Version: 5.0.2-1
> Severity: serious
> X-Debbugs-CC: Bastien Roucariès 
>
> Hi,
>
> I just ACCEPTed node-diffie-hellman from NEW but thought I would
> file this bug to ensure that the concerns on debian-devel were
> addressed etc.
>
> eg. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860771#10


Thanks
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#860238: [dpkg] Improve debugging experience for piupart

[roucaries bastien]

On Thu, Apr 20, 2017 at 10:00 AM, Guillem Jover  wrote:
> Control: forcemerge 813454 -1
>
> Hi!
>
> On Thu, 2017-04-13 at 12:02:07 +0200, Bastien ROUCARIÈS wrote:
>> Package: dpkg
>> Version: 1.18.23
>> Severity: important
>> affects: piuparts.debian.org
>> affects: src:imagemagick
>> control: tags -1 + patch
>
>> I know it is late on release but it will really help to add this patch.
>>
>> Could you consider for release ?
>
> When you first filed this, I took a quick look, but producing a proper
> fix seemed involved, given the contstrains I set for myself:
>
> Thanks for the patch, although I think this is not enough.
>
>> diff --git a/scripts/dpkg-maintscript-helper.sh 
>> b/scripts/dpkg-maintscript-helper.sh
>> index b4b3ac1b3..0b867d805 100755
>> --- a/scripts/dpkg-maintscript-helper.sh
>> +++ b/scripts/dpkg-maintscript-helper.sh
>> @@ -412,14 +412,8 @@ prepare_dir_to_symlink()
>>
>>   # If there are locally created files or files owned by another package
>>   # we should not perform the switch.
>> - find "$PATHNAME" -print0 | xargs -0 -n1 sh -c '
>> - package="$1"
>> - file="$2"
>> - if ! dpkg-query -L "$package" | grep -F -q -x "$file"; then
>> - exit 1
>> - fi
>> - exit 0
>> - ' check-files-ownership "$PACKAGE" || \
>> + find "$PATHNAME" -print0 | xargs -0 -n1 \
>> + dpkg-maintscript-helper package_owns_file_or_error $PACKAGE || 
>> \
>
> The problem with this is that it aborts on first error, so any other
> remaining problematic files are missed, which might make debugging
> difficult, miss files, or require several iterations.

Thanks for this remark but it I think you are wrong: xargs will
execute next command if error code is < 125 (and it is POSIX and
portable).
Try for instance
echo '/ /tmp' | xargs -n1 chmod +x
So this implementation will print the name of all not owned files.

>
> I also considered using a command like this, but it seemed wrong, as
> that is exposing a private implementation detail as part of the
> interface, so I'd rather not do this.
>
>>   error "directory '$PATHNAME' contains files not owned by" \
>> "package $PACKAGE, cannot switch to symlink"
>>
>> @@ -515,6 +509,18 @@ ensure_package_owns_file() {
>>   return 0
>>  }

Does adding a private suffix and passing a magic number as arg1 will
solve this ?

I means:

MAGICK_PRIVATE="This is private interface do not use"
package_owns_file_or_error() {
local MAGICK="$1"
local PACKAGE="$2"
local FILE="$3"
if test x$MAGICKL != x$MAGICK_PRIVATE; then
error "$MAGICK_PRIVATE";
fi
if ! ensure_package_owns_file $PACKAGE $FILE ; then
error "File '$FILE' not owned by package " \
 "'$PACKAGE'"
return 1


> error() already «exits 1». :)

Ok
>> +   fi
>> +   return 0

}
>> +
>> +package_owns_file_or_error() {
>> +   local PACKAGE="$1"
>> +   local FILE="$2"
>> +   if ! ensure_package_owns_file $PACKAGE $FILE ; then
>> +error "File '$FILE' not owned by package " \
>> +  "'$PACKAGE'"
>> +return 1
>
> error() already «exits 1». :)

Yes but for clarification it is better.

>> +   fi
>> +   return 0
>> +}

Thanks for the review

Bastien

> Thanks,
> Guillem

Bug#860237: [Piuparts-devel] Bug#860237: [piuparts.debian.org] Improve debugging experience in case of dpkg failure

[roucaries bastien]

On Thu, Apr 13, 2017 at 12:12 PM, Andreas Beckmann <a...@debian.org> wrote:
> On 2017-04-13 12:03, roucaries bastien wrote:
>> On Thu, Apr 13, 2017 at 12:02 PM, Andreas Beckmann <a...@debian.org> wrote:
>>> On 2017-04-13 11:44, Bastien ROUCARIÈS wrote:
>>>> Actually dpkg try to recover from error state in order to get something 
>>>> safe.
>>>>
>>>> it is not really needed for piupart and moreover it detroy bug evidence.
>>>>
>>>> Safer will be to add  abort-after=1 to dpkg config thus keeping evidence.
>>>
>>> Do you have a concrete example of a failure you want to debug?
>>
>> Yes here 
>> https://piuparts.debian.org/wheezy222testing/bugged/imagemagick-doc_8:6.9.7.4+dfsg-3.log
>
> rerunning it with --shell-on-error (and without timeout prefix) would
> give you a shell in the chroot - would this help?


Yes but without dpkg option it is too late. dpkg tried to recover...
>
>
> Andreas
>

Bug#860237: [Piuparts-devel] Bug#860237: [piuparts.debian.org] Improve debugging experience in case of dpkg failure

[roucaries bastien]

On Thu, Apr 13, 2017 at 12:02 PM, Andreas Beckmann  wrote:
> On 2017-04-13 11:44, Bastien ROUCARIÈS wrote:
>> Actually dpkg try to recover from error state in order to get something safe.
>>
>> it is not really needed for piupart and moreover it detroy bug evidence.
>>
>> Safer will be to add  abort-after=1 to dpkg config thus keeping evidence.
>
> Do you have a concrete example of a failure you want to debug?

Yes here 
https://piuparts.debian.org/wheezy222testing/bugged/imagemagick-doc_8:6.9.7.4+dfsg-3.log

>
> Andreas

Bug#849831: Evil licence

[roucaries bastien]

On Fri, Jan 27, 2017 at 6:35 PM, Emilio Pozuelo Monfort
 wrote:
> Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1334543
> Control: forwarded 849832 https://bugzilla.mozilla.org/show_bug.cgi?id=1334543
>
> On Thu, 28 Jan 2016 22:52:08 +0100 Bastien ROUCARIES
>  wrote:
>> severity: serious
>> user: debian...@lists.debian.org
>> usertags: json-evil-license
>> package: iceweasel
>> version: 44.0-1
>>
>> Hi,
>>
>> mozilla/dom/system/gonk/tests/marionette/ril_jshint/jshint.js
>>
>> is licenced under evil licence...
>>
>> Please repack and notify archive.debian.org in order to remove old package.
>
> Not sure that is necessary, given the file is distributable and I don't think
> it's used in the resulting binaries.

Last time I checked json are considered not distributable by ftpmaster
>
> Cheers,
> Emilio

Bug#849830: [src:digikam] Some sources are not included in your package

[roucaries bastien]

On Sun, Jan 1, 2017 at 7:59 AM, Steve Robbins  wrote:
> On Saturday, December 31, 2016 10:06:37 PM CST you wrote:
>
>> your package includes some files that seem to lack sources
>> in preferred forms of modification (even if removed during clean target).
>
> No part of the resulting binary package comes from files that are not in their
> intended form of modification.  I acknowledge there are extra non-source files
> in the source tarball *that are not used* to create the binary.

Yes but it fail dfsg
>
>> According to Debian Free Software Guidelines [1] (DFSG) #2:
>>  "The program must include source code, and must allow distribution
>>   in source code as well as compiled form."
>
> Digikam meets this test.

No minified javascript are not source
>
>> In some cases this could also constitute a license violation for some
>> copyleft licenses such as the GNU GPL. (While sometimes the licence
>> allows not to ship the source, the DFSG always mandates source code.)
>
> It requires all sources required to create the binary.  Digikam meets this
> test.

Please ask debian-qa or ftpmaster but you should repack

> -Steve

Bug#848894: Cannot reproduce on sbuild; thoughts on architecture=amd64

[roucaries bastien]

On Wed, Dec 21, 2016 at 11:54 PM, Hilko Bengen  wrote:
> control: tag -1 unreproducible
>
> Good evening.
>
> In my linux/amd64 sbuild setup, dx builds just fine.
>
> What had me puzzled, though, is how the message "checking architecture
> type... amd64" came to be. If uname works correctly, the string "amd64"
> could not have been generated inside the DX_ARCHITECTURE function
> (acinclude.m4). Could it be that ARCH=amd64 was part of the environment
> that got passed to pbuilder ... and to the configure script?
>
> Indeed, when I call the configure script with the ARCH environment
> variable set, I can reproduce the effect:

Yes I think so. Please close
> ,
> | $ ARCH=amd64 ./configure
> | [...]
> | checking whether large file support needs explicit enabling... yes
> | checking architecture type... amd64
> | checking architecture specific stuff... done
> | checking for a BSD-compatible install... /usr/bin/install -c
> `
>
> Cheers,
> -Hilko

Bug#846385: imagemagick: Potential ABI break upstream (without SONAME change)

[roucaries bastien]

BTW feel free to NMU imagemagick during a short break I take in the
next two days.

Bastien

Bug#846385: imagemagick: Potential ABI break upstream (without SONAME change)

[roucaries bastien]

On Tue, Dec 20, 2016 at 4:22 PM, roucaries bastien
<roucaries.bastien+deb...@gmail.com> wrote:
> On Wed, Dec 14, 2016 at 1:29 PM, roucaries bastien
> <roucaries.bastien+deb...@gmail.com> wrote:
>> On Wed, Dec 14, 2016 at 1:28 PM, roucaries bastien
>> <roucaries.bastien+deb...@gmail.com> wrote:
>>> On Tue, Dec 13, 2016 at 12:21 AM, Emilio Pozuelo Monfort
>>> <po...@debian.org> wrote:
>>>> On 09/12/16 22:37, roucaries bastien wrote:
>>>>> control: forwarded -1 
>>>>> https://github.com/ImageMagick/ImageMagick/issues/320
>>>>>
>>>>> Dear realease team,
>>>>>
>>>>> What is the next step?
>>>>
>>>> In which version was the ABI break introduced?
>>>
>>> It was introduced more than 2 years ago ( 6.9.2-10). One version after
>>> jessie what lie in unstable before jessie release.
>>>>
>>>> In general I would prefer the change to be reverted, but depending on how 
>>>> long
>>>> this has been in the archive, and in order to stay up to date for security
>>>> fixes, it may be best to do the soname bump.
>>>
>>> From a security point of view, I prefer recent version. I do not want
>>> to keep jessie version with huge patch queue for
>>>>
>>>> Can you check if your rdeps build fine against a new imagemagick?
>
> libmagick++ rdeps build fine except traficserver due to a sphinx error
> (unreleated to imagemagick)
> libmagickwand rdeps build fine except rss-glx due to unreleated build
> conflict (#838800)
> libmagickcore rdeps build fine except dx due to missing .mak file
> (unlikely imagemagick)

trafficserver is - #848800
dx #848894

>
> Will rebuild traficserver and dx under sid chroot and report FTBFS.
>
> Seems it is ok
>
> Bastien
>>>
>>> What i will do i will set on unstable the newer version with so dump
>>> and will begin to rebuilt on pbuilder. Normally it will be fine.
>>
>> s/unstable/experimental/g
>>>
>>> I wish to have abi checker on the debian side
>>>
>>> Bastien
>>>>
>>>> Emilio

Bug#846385: imagemagick: Potential ABI break upstream (without SONAME change)

[roucaries bastien]

On Wed, Dec 14, 2016 at 1:29 PM, roucaries bastien
<roucaries.bastien+deb...@gmail.com> wrote:
> On Wed, Dec 14, 2016 at 1:28 PM, roucaries bastien
> <roucaries.bastien+deb...@gmail.com> wrote:
>> On Tue, Dec 13, 2016 at 12:21 AM, Emilio Pozuelo Monfort
>> <po...@debian.org> wrote:
>>> On 09/12/16 22:37, roucaries bastien wrote:
>>>> control: forwarded -1 https://github.com/ImageMagick/ImageMagick/issues/320
>>>>
>>>> Dear realease team,
>>>>
>>>> What is the next step?
>>>
>>> In which version was the ABI break introduced?
>>
>> It was introduced more than 2 years ago ( 6.9.2-10). One version after
>> jessie what lie in unstable before jessie release.
>>>
>>> In general I would prefer the change to be reverted, but depending on how 
>>> long
>>> this has been in the archive, and in order to stay up to date for security
>>> fixes, it may be best to do the soname bump.
>>
>> From a security point of view, I prefer recent version. I do not want
>> to keep jessie version with huge patch queue for
>>>
>>> Can you check if your rdeps build fine against a new imagemagick?

libmagick++ rdeps build fine except traficserver due to a sphinx error
(unreleated to imagemagick)
libmagickwand rdeps build fine except rss-glx due to unreleated build
conflict (#838800)
libmagickcore rdeps build fine except dx due to missing .mak file
(unlikely imagemagick)

Will rebuild traficserver and dx under sid chroot and report FTBFS.

Seems it is ok

Bastien
>>
>> What i will do i will set on unstable the newer version with so dump
>> and will begin to rebuilt on pbuilder. Normally it will be fine.
>
> s/unstable/experimental/g
>>
>> I wish to have abi checker on the debian side
>>
>> Bastien
>>>
>>> Emilio

Bug#846385: imagemagick: Potential ABI break upstream (without SONAME change)

[roucaries bastien]

On Tue, Dec 13, 2016 at 12:21 AM, Emilio Pozuelo Monfort
<po...@debian.org> wrote:
> On 09/12/16 22:37, roucaries bastien wrote:
>> control: forwarded -1 https://github.com/ImageMagick/ImageMagick/issues/320
>>
>> Dear realease team,
>>
>> What is the next step?
>
> In which version was the ABI break introduced?

It was introduced more than 2 years ago ( 6.9.2-10). One version after
jessie what lie in unstable before jessie release.
>
> In general I would prefer the change to be reverted, but depending on how long
> this has been in the archive, and in order to stay up to date for security
> fixes, it may be best to do the soname bump.

>From a security point of view, I prefer recent version. I do not want
to keep jessie version with huge patch queue for
>
> Can you check if your rdeps build fine against a new imagemagick?

What i will do i will set on unstable the newer version with so dump
and will begin to rebuilt on pbuilder. Normally it will be fine.

I wish to have abi checker on the debian side

Bastien
>
> Emilio

Bug#846385: imagemagick: Potential ABI break upstream (without SONAME change)

[roucaries bastien]

On Wed, Dec 14, 2016 at 1:28 PM, roucaries bastien
<roucaries.bastien+deb...@gmail.com> wrote:
> On Tue, Dec 13, 2016 at 12:21 AM, Emilio Pozuelo Monfort
> <po...@debian.org> wrote:
>> On 09/12/16 22:37, roucaries bastien wrote:
>>> control: forwarded -1 https://github.com/ImageMagick/ImageMagick/issues/320
>>>
>>> Dear realease team,
>>>
>>> What is the next step?
>>
>> In which version was the ABI break introduced?
>
> It was introduced more than 2 years ago ( 6.9.2-10). One version after
> jessie what lie in unstable before jessie release.
>>
>> In general I would prefer the change to be reverted, but depending on how 
>> long
>> this has been in the archive, and in order to stay up to date for security
>> fixes, it may be best to do the soname bump.
>
> From a security point of view, I prefer recent version. I do not want
> to keep jessie version with huge patch queue for
>>
>> Can you check if your rdeps build fine against a new imagemagick?
>
> What i will do i will set on unstable the newer version with so dump
> and will begin to rebuilt on pbuilder. Normally it will be fine.

s/unstable/experimental/g
>
> I wish to have abi checker on the debian side
>
> Bastien
>>
>> Emilio

Bug#846385: imagemagick: Potential ABI break upstream (without SONAME change)

[roucaries bastien]

control: forwarded -1 https://github.com/ImageMagick/ImageMagick/issues/320

Dear realease team,

What is the next step?

Thank you

On Tue, Dec 6, 2016 at 8:23 PM, Simon McVittie <s...@debian.org> wrote:
> Control: reopen 846385
> Control: severity 846385 serious
>
> tl;dr: yes, this is clearly an ABI break.
>
> On Thu, 01 Dec 2016 at 15:55:02 +0100, roucaries bastien wrote:
>> * struct _DrawInfo (1) is not a problem from a C point of view because
>> it should be set and destry by API function. It is a opaque object. So
>> no need to so bump for this
>> *  _ElementReference (1) is part of _Drawinfo so not a problem
>> * _GradientInfo (3) is the same
>> * For _image is an opaque type so it is the same
>
> Unfortunately this is not true: none of these types are opaque. I think
> you have misunderstood what it means to say a struct type is opaque.
> For example, DrawInfo (aka struct _DrawInfo) has its layout visible to
> library users in the installed header  (in
> libmagickcore-6-headers), so any change to its size is an ABI break, and
> so is any semantic change to its contents.
>
> You are right to think that if library users were expected to allocate
> a DrawInfo on the stack, it would certainly be an ABI break to change
> its size. However, even if a structure is only ever allocated by
> library code, reading its fields directly is part of the library ABI too.
>
> For DrawInfo to be an opaque object, its layout would have to be
> in a .c or .h file used only internally by ImageMagick (and not installed
> in libmagickcore-6-headers), and library users would have to access its
> fields via accessor functions like DrawInfoGetGravity() and
> DrawInfoSetGravity(). For example, GRegex in GLib's glib/gregex.[ch]
> is a good example of an opaque object:
> https://sources.debian.net/src/glib2.0/2.50.2-2/glib/gregex.h/
> https://sources.debian.net/src/glib2.0/2.50.2-2/glib/gregex.c/
>
> The definition of an ABI break is that previously-correct code, compiled
> against version A, no longer works correctly when linked at runtime with
> version B. Consider what would happen if some program that uses ImageMagick
> is compiled against ImageMagick 6.9.1-10, and it wants to set the stroke
> opacity (which happens to be the last field in the struct):
>
> DrawInfo *draw_info = AcquireDrawInfo();
>
> draw_info->stroke_opacity = 0.5;
>
> In ImageMagick 6.9.1-10 on x86_64, according to the ABI Compliance Checker,
> the DrawInfo is a 720 byte struct. A double is 8 bytes, and stroke_opacity
> is the last thing in the struct, so that assignment results in an 8-byte
> write 712 bytes after the draw_info pointer, overwriting the bytes from
> 712 to 719 bytes after the pointer. In other words, on x86_64, it's the
> same machine code that you would get by compiling this:
>
> DrawInfo *draw_info = AcquireDrawInfo();
>
> *((double *) (((char *) draw_info) + 712)) = 0.5;
>
> Now suppose we install that program on a machine that has ImageMagick
> 6.9.2-10, in which DrawInfo has grown by 32 bytes. The program still
> writes at an offset of 712 bytes into the struct (remember that
> machine code doesn't know anything about structs or names, only
> pointers and offsets), but now the larger GradientInfo and
> ElementReference have pushed all the later struct fields further
> away from offset 0. If my arithmetic is correct, the field 712 bytes
> into the data structure is now draw_info->interword_spacing, which is
> not what was intended.
>
> Conversely, if you compile against 6.9.2-10 but use 6.9.1-10 at runtime,
> it's worse: the program writes at an offset of 724 bytes (overwriting
> bytes 724 to 731 inclusive); but since ImageMagick 6.9.1-10 only allocated
> a 720 byte struct, that write is outside the struct, and could be anything
> (in particular, it could be corrupting glibc malloc data structures).
>
> Regards,
> S

Bug#846385: Fwd: [Pkg-gmagick-im-team] Bug#846385: imagemagick: Potential ABI break upstream (without SONAME change)

[roucaries bastien]

Dear release team,

Could you get a glimpse at this bug?

I had supposed that this change was safe because these structure could
be only allocated using API call (no malloc) and size of structure was
expanded.

Do you think we need for safety a so bump ?

Sorry for this late mail

Bastien


-- Forwarded message --
From: Antonio Terceiro <terce...@debian.org>
Date: Sun, Dec 4, 2016 at 1:08 AM
Subject: Re: [Pkg-gmagick-im-team] Bug#846385: imagemagick: Potential
ABI break upstream (without SONAME change)
To: roucaries bastien <roucaries.bastien+deb...@gmail.com>
Cc: Nishanth Aravamudan <nish.aravamu...@canonical.com>, 846...@bugs.debian.org


On Thu, Dec 01, 2016 at 03:55:02PM +0100, roucaries bastien wrote:
> On Wed, Nov 30, 2016 at 9:34 PM, Nishanth Aravamudan
> <nish.aravamu...@canonical.com> wrote:
> > Package: imagemagick
> > Version: 6.9.9.6+dfsg-1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > We recently merged imagemagick 6.9.9.6+dfsg-1 in Ubuntu 17.04; however
> > we see autopkgtest failures in ruby-rmagick and php-imagick with this
> > version (note that Debian is seeing similar failures).
> >
> > At least for ruby-rmagick, it seems like (possibly) upstream made an ABI
> > change without bumping the SONAME for libmagickcore, and ruby-rmagick
> > ends up pulling in the wrong dependency
> > (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/r/ruby-rmagick/20161130_032804_d2177@/log.gz).
> >
> > More specifically, we are building against imagemagick
> > 8:6.9.6.6+dfsg-1ubuntu2:
> > https://launchpadlibrarian.net/295470626/buildlog_ubuntu-zesty-arm64.ruby-rmagick_2.15.4+dfsg-2build1_BUILDING.txt.gz.
> >
> > During the build, the tests pass succesfully (using the above version of
> > imagemagick), but you can see that the the resulting binary package has
> > dependencies that are more relaxed than that specific version:
> >
> >  Depends: ruby (>= 1:2.3~0), libc6 (>= 2.17), libmagickcore-6.q16-2 (>= 
> > 8:6.8.8.9), libruby2.3 (>= 2.3.0~preview2)
> >
> > Therefore, when the autopkgtest runs:
> > https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/r/ruby-rmagick/20161130_032804_d2177@/log.gz,
> > imagemagick 8:6.8.9.9-7ubuntu9 is used, and a segmentation fault occurs.
> >
> > Thanks to Marc Deslauriers' research, it seems like there might have
> > been at least one ABI breakage upsream in libmagickcore:
> > https://abi-laboratory.pro/tracker/compat_report/imagemagick/6.9.1-10/6.9.2-10/67f2f/abi_compat_report.html,
> > which might be related.
> >
> > What is your opinion on this as the Debian maintainer? Should the SONAME
> > be bumped and symbols files be updated?
>
> Some detail:
> *  GetDefaultOpenCLEnv is not a problem because opencl is disable on debian
> * struct _DrawInfo (1) is not a problem from a C point of view because
> it should be set and destry by API function. It is a opaque object. So
> no need to so bump for this

I don't think that is the case.

After initializing a _Drawinfo struct, ruby-rmagick needs to operate on
it, by assigning values to its fields. So unless I am missing some API
in imagemagick to set fields of _Drawinfo, it is *not* opaque for API
users. If the structure size changes without a proper SONAME bump, this
*will* cause segfaults.

Please reconsider this, and do SONAME bumps when there are ABI
changes.

> *  _ElementReference (1) is part of _Drawinfo so not a problem
> * _GradientInfo (3) is the same
> * For _image is an opaque type so it is the same
>
> Now for interpreted language you may need the size of this kind of
> structure and thus need stricter dependencies or use at
> innitialisation a runtime check of imagesize returned by
> AcquireImage() function.

See above.


signature.asc
Description: PGP signature

Bug#846385: [Pkg-gmagick-im-team] Bug#846385: imagemagick: Potential ABI break upstream (without SONAME change)

[roucaries bastien]

On Wed, Nov 30, 2016 at 9:34 PM, Nishanth Aravamudan
 wrote:
> Package: imagemagick
> Version: 6.9.9.6+dfsg-1
> Severity: normal
>
> Dear Maintainer,
>
> We recently merged imagemagick 6.9.9.6+dfsg-1 in Ubuntu 17.04; however
> we see autopkgtest failures in ruby-rmagick and php-imagick with this
> version (note that Debian is seeing similar failures).
>
> At least for ruby-rmagick, it seems like (possibly) upstream made an ABI
> change without bumping the SONAME for libmagickcore, and ruby-rmagick
> ends up pulling in the wrong dependency
> (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/r/ruby-rmagick/20161130_032804_d2177@/log.gz).
>
> More specifically, we are building against imagemagick
> 8:6.9.6.6+dfsg-1ubuntu2:
> https://launchpadlibrarian.net/295470626/buildlog_ubuntu-zesty-arm64.ruby-rmagick_2.15.4+dfsg-2build1_BUILDING.txt.gz.
>
> During the build, the tests pass succesfully (using the above version of
> imagemagick), but you can see that the the resulting binary package has
> dependencies that are more relaxed than that specific version:
>
>  Depends: ruby (>= 1:2.3~0), libc6 (>= 2.17), libmagickcore-6.q16-2 (>= 
> 8:6.8.8.9), libruby2.3 (>= 2.3.0~preview2)
>
> Therefore, when the autopkgtest runs:
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/r/ruby-rmagick/20161130_032804_d2177@/log.gz,
> imagemagick 8:6.8.9.9-7ubuntu9 is used, and a segmentation fault occurs.
>
> Thanks to Marc Deslauriers' research, it seems like there might have
> been at least one ABI breakage upsream in libmagickcore:
> https://abi-laboratory.pro/tracker/compat_report/imagemagick/6.9.1-10/6.9.2-10/67f2f/abi_compat_report.html,
> which might be related.
>
> What is your opinion on this as the Debian maintainer? Should the SONAME
> be bumped and symbols files be updated?

Some detail:
*  GetDefaultOpenCLEnv is not a problem because opencl is disable on debian
* struct _DrawInfo (1) is not a problem from a C point of view because
it should be set and destry by API function. It is a opaque object. So
no need to so bump for this
*  _ElementReference (1) is part of _Drawinfo so not a problem
* _GradientInfo (3) is the same
* For _image is an opaque type so it is the same

Now for interpreted language you may need the size of this kind of
structure and thus need stricter dependencies or use at
innitialisation a runtime check of imagesize returned by

AcquireImage() function.

Bastien





> Thanks for your time!
>
> -Nish
>
> --
> Nishanth Aravamudan
> Ubuntu Server
> Canonical Ltd
>
> ___
> Pkg-gmagick-im-team mailing list
> pkg-gmagick-im-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team

Bug#843362: RFS: wand/0.4.4-1

[roucaries bastien]

On Sun, Nov 6, 2016 at 10:30 AM, Changwoo Ryu  wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
>
> I am looking for a sponsor for my package "wand":
>
> * Package name: wand
>   Version : 0.4.4-1
>   Section : python
>
> It builds those binary packages:
>
>  pypy-wand  - Python interface for ImageMagick library (PyPy build)
>  python-wand - Python interface for ImageMagick library (Python 2 build)
>  python3-wand - Python interface for ImageMagick library (Python 3 build)
>  wand-doc   - Python interface for ImageMagick library - documentation
>
> Download the package with dget using this command:
>
> dget -x https://people.debian.org/~cwryu/debian/wand_0.4.4-1.dsc
>
> Or you can use the alioth git:
>
> https://anonscm.debian.org/git/users/cwryu/wand.git
>
>
> Changes since the last upload:
>
>   * New upstream release
>   * debian/control: Correct the Vcs-*: URI
>   * Use pybuild
> - The testsuite is disabled for now; it fails on the ImageMagick 6.8.* or
>   later

With my imagemagick hat, why it fail ?

Bastien

> My new gpg key is not in the keyring yet since the weak key
> removal so I can't upload this update myself.
>

Bug#842597: RFS: [RC] pythonmagick/0.9.14-1

[roucaries bastien]

On Sun, Oct 30, 2016 at 6:36 PM, Mattia Rizzolo  wrote:
> control: tag -1 moreinfo
> control: owner -1 !
>
> On Sun, Oct 30, 2016 at 06:11:01PM +0100, Bastien ROUCARIÈS wrote:
>>   I am looking for a sponsor for my package "pythonmagick"
>
> o/
>
>>   Alternatively, one can download the package with dget using this command:
>>
>> dget -x https://mentors.debian.net/debian/pool/main/p/pythonmagick/
>> pythonmagick_0.9.14-1.dsc
>
> given this package is in dpmt I'll stick to git instead.
>
>>   * Switch watch to .xz and add signature check
>
> please instead make use of uscan's @ARCHIVE_EXT@ substitution variable.
Ok
>
>>   * Add myself as uploader.
>>   * Switch to git-dpm.
>>   * Bump Standards-Version no changes.
>>   * New upstream release:
>> - Bug fix: "FTBFS with newer experimental version of imagemagick",
>>   thanks to Bastien ROUCARIES (Closes: #840428).
>
> I find weird thanking yourself here :)
ok
> Also, the upstream bug that you linked in the debian bug is still open
> with no comments, how come?
Due to transient bug in toolchain fixed now. New upstream is needed

> moreover:
>
> * please bump debhelper compat level to 10
ok
> * switch to pybuild for building


Do you have an example with autoconf ?

> * README.source is now completely useless
ok
> * I wouldn't mind seeing the build-deps sorted
ok
> * merge the UNRELEASED changelog entry into yours
ok

>
> Then, does this package build with python3?  If so please add a python3-
> package.
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Bug#838242: transition: imagemagick

[roucaries bastien]

On Fri, Oct 21, 2016 at 10:46 AM, Emilio Pozuelo Monfort
<po...@debian.org> wrote:
> On 13/10/16 09:45, Emilio Pozuelo Monfort wrote:
>> On 12/10/16 17:13, roucaries bastien wrote:
>>> Uploaded new version waiting for green light
>>
>> Go ahead.
>
> Can you look at pythonmagick? That is the last blocker.

I think we should drop pythonmagick:
1. it is an upstream bug
https://github.com/ImageMagick/PythonMagick/issues/5. I will fix ASAP
when a new upstream is ready
2. They are three new security bugs with CVE in imagemagick.

Bastien


> Cheers,
> Emilio

Bug#838242: transition: imagemagick

[roucaries bastien]

Hi,

On Tue, Oct 11, 2016 at 6:14 PM, roucaries bastien
<roucaries.bastien+deb...@gmail.com> wrote:
> Hi,
>
>
> On Sat, Oct 8, 2016 at 12:49 PM, Emilio Pozuelo Monfort
> <po...@debian.org> wrote:
>> Control: tags -1 confirmed
>>
>> On 07/10/16 17:15, roucaries bastien wrote:
>>> I have tried and it seems so.
>>>
>>> Due to perl transition I get some transient problem but it seems ok,
>>> except package only available under unstable
>>
>> Alright. This is small enough that should be fine in any case.
>>
>> You can go ahead.
>
> I need to upgrade a newer version to experimental fixing two CVE... I
> will prefer to use the newest version and I am rebuilding for
> experimental.
>
> they are now two problems
>
> k3b FTBS for unstable #838516
> pythonmagick need to be upgraded to newer version
>
> It is a good idea to upgrade pythonmagick due to security concern.
>
>
>>
>> I wonder why you called the new package libmagick++-6.q16-6v6 rather than 
>> just
>> libmagick++-6.q16-6. That seems like a mistake, though I guess just leave it
>> like that now, no need to go through NEW and add conflicts/replaces etc just 
>> for
>> a cosmetic change.
>
> Because some experimental version get a  libmagick++-6.q16-6 then they
> are an ABI problem due to newer g++
>
> So double bump.
>
> Bastien
>
>>
>> Cheers,
>> Emilio
Uploaded new version waiting for green light

Bug#838242: transition: imagemagick

[roucaries bastien]

Hi,


On Sat, Oct 8, 2016 at 12:49 PM, Emilio Pozuelo Monfort
<po...@debian.org> wrote:
> Control: tags -1 confirmed
>
> On 07/10/16 17:15, roucaries bastien wrote:
>> I have tried and it seems so.
>>
>> Due to perl transition I get some transient problem but it seems ok,
>> except package only available under unstable
>
> Alright. This is small enough that should be fine in any case.
>
> You can go ahead.

I need to upgrade a newer version to experimental fixing two CVE... I
will prefer to use the newest version and I am rebuilding for
experimental.

they are now two problems

k3b FTBS for unstable #838516
pythonmagick need to be upgraded to newer version

It is a good idea to upgrade pythonmagick due to security concern.


>
> I wonder why you called the new package libmagick++-6.q16-6v6 rather than just
> libmagick++-6.q16-6. That seems like a mistake, though I guess just leave it
> like that now, no need to go through NEW and add conflicts/replaces etc just 
> for
> a cosmetic change.

Because some experimental version get a  libmagick++-6.q16-6 then they
are an ABI problem due to newer g++

So double bump.

Bastien

>
> Cheers,
> Emilio

Bug#838242: transition: imagemagick

[roucaries bastien]

I have tried and it seems so.

Due to perl transition I get some transient problem but it seems ok,
except package only available under unstable

On Wed, Sep 21, 2016 at 10:43 PM, Emilio Pozuelo Monfort
 wrote:
> user release.debian@packages.debian.org
> usertags 838242 transition
> thanks
>
> On 18/09/16 23:08, Bastien ROUCARIÈS wrote:
>> Package: release.debian.org
>> Severity: normal
>
> Please use reportbug next time, you missed the appropriate usertags.
>
>>
>> Hi,
>>
>> imagemagick waiting in NEWs (8:6.9.5.9+dfsg-1) will need a transition to
>> experimental to unstable;
>>
>> Next stable version need to be based on this version from a security point of
>> view. It fix more than 50 securities bugs..;
>>
>> Moreover this version use autopkg test improving the quality of testing.
>
> Did you try to rebuild all the rdeps?
>
> Cheers,
> Emilio

Bug#829292: autoconf-archive: new upstream version 2016.03.20

[roucaries bastien]

Uploaded to mentors.

I you want you could sponsor

Bastien

On Fri, Sep 2, 2016 at 5:17 AM, Jeremy Bicha  wrote:
>> Will do please reprod in end of august if not done
>
> Hi, it's September now. The new autoconf-archive is being used by
> several GNOME 3.22 modules. Since Stretch will include GNOME 3.22, it
> would be great if you could make time to package the update soon.
>
> Thanks,
> Jeremy Bicha

Bug#835488: [Pkg-gmagick-im-team] Bug#835488: imagemagick: Regression after security update to 8:6.8.9.9-5+deb8u4, unable to convert PDF files in PHP

[roucaries bastien]

Yes with next security update

On Fri, Sep 2, 2016 at 3:23 PM, Tommie Van Mechgelen <m...@tommie.it> wrote:
> Hi,
>
> will there be an update available?
>
> Thanks
>
>
> On Wednesday, August 31, 2016 09:14 CEST, roucaries bastien
> <roucaries.bastien+deb...@gmail.com> wrote:
>
>
> Bad pach is :
> commit 26d910675e0cd1b62e988139dba8eb11931260ac
> Author: Cristy <urban-warr...@imagemagick.org>
> Date: Sat Jan 30 09:37:10 2016 -0500
>
> Fix out of bound in quantum handling
>
> Bug: https://github.com/ImageMagick/ImageMagick/issues/105
> bug-ubuntu:
> https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1539053
> origin: upstream,
> https://github.com/ImageMagick/ImageMagick/commit/c4e63ad30bc42da691f2b5f82a24516dd6b4dc70
> bug-debian: https://bugs.debian.org/832506
>
> On Fri, Aug 26, 2016 at 11:17 AM, Tommie Van Mechgelen <m...@tommie.it> wrote:
>> Package: imagemagick
>> Version: 8:6.8.9.9-5+deb8u4
>> Severity: important
>>
>> Dear Maintainer,
>>
>> After the upgrade to this version, converting PDF-files in PHP stopped
>> working.
>>
>> A small PHP test application throws an exception.
>>
>> ---
>> unable to read image data `/tmp/magick-28249kJukMY5BQuJr1' @
>> error/pnm.c/ReadPNMImage/617
>> The PDF contains 0 pages
>> ---
>>
>> The expected result is no exception and it should display the number of
>> pages. This worked with version 8:6.8.9.9-5+deb8u3.
>>
>> Thanks for investigating this.
>>
>> PHP code:
>> -
>> >
>> $imagick = new Imagick();
>> try {
>> $imagick->pingImage('bug.pdf');
>> }
>> catch(ImagickException $e) {
>> print $e->getMessage() . "\n";
>> }
>>
>> $pages = $imagick->getNumberImages();
>> print "The PDF contains $pages pages\n";
>>
>>
>> -- Package-specific info:
>> ImageMagick program version
>> ---
>> animate: ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25
>> http://www.imagemagick.org
>> compare: ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25
>> http://www.imagemagick.org
>> convert: ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25
>> http://www.imagemagick.org
>> composite: ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25
>> http://www.imagemagick.org
>> conjure: ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25
>> http://www.imagemagick.org
>> display: ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25
>> http://www.imagemagick.org
>> identify: ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25
>> http://www.imagemagick.org
>> import: ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25
>> http://www.imagemagick.org
>> mogrify: ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25
>> http://www.imagemagick.org
>> montage: ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25
>> http://www.imagemagick.org
>> stream: ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25
>> http://www.imagemagick.org
>>
>> -- System Information:
>> Debian Release: 8.5
>> APT prefers stable
>> APT policy: (500, 'stable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages imagemagick depends on:
>> ii imagemagick-6.q16 8:6.8.9.9-5+deb8u4
>>
>> imagemagick recommends no packages.
>>
>> imagemagick suggests no packages.
>>
>> -- no debconf information
>>
>> ___
>> Pkg-gmagick-im-team mailing list
>> pkg-gmagick-im-t...@lists.alioth.debian.org
>>
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team
>
>
>

Bug#835488: [Pkg-gmagick-im-team] Bug#835488: imagemagick: Regression after security update to 8:6.8.9.9-5+deb8u4, unable to convert PDF files in PHP

[roucaries bastien]

control: tags -1 + fixed-upstream
control: tags -1 + patch

On Wed, Aug 31, 2016 at 9:19 AM, roucaries bastien
<roucaries.bastien+deb...@gmail.com> wrote:
> Fixed upstream by
> https://github.com/ImageMagick/ImageMagick/commit/f6242e725c819a69bee2a444f8e4a3c7718b2b3f
>
> On Wed, Aug 31, 2016 at 9:14 AM, roucaries bastien
> <roucaries.bastien+deb...@gmail.com> wrote:
>> Bad pach is :
>> commit 26d910675e0cd1b62e988139dba8eb11931260ac
>> Author: Cristy <urban-warr...@imagemagick.org>
>> Date:   Sat Jan 30 09:37:10 2016 -0500
>>
>> Fix out of bound in quantum handling
>>
>> Bug: https://github.com/ImageMagick/ImageMagick/issues/105
>> bug-ubuntu:
>> https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1539053
>> origin: upstream,
>> https://github.com/ImageMagick/ImageMagick/commit/c4e63ad30bc42da691f2b5f82a24516dd6b4dc70
>> bug-debian: https://bugs.debian.org/832506
>>
>> On Fri, Aug 26, 2016 at 11:17 AM, Tommie Van Mechgelen <m...@tommie.it> 
>> wrote:
>>> Package: imagemagick
>>> Version: 8:6.8.9.9-5+deb8u4
>>> Severity: important
>>>
>>> Dear Maintainer,
>>>
>>> After the upgrade to this version, converting PDF-files in PHP stopped 
>>> working.
>>>
>>> A small PHP test application throws an exception.
>>>
>>> ---
>>> unable to read image data `/tmp/magick-28249kJukMY5BQuJr1' @ 
>>> error/pnm.c/ReadPNMImage/617
>>> The PDF contains 0 pages
>>> ---
>>>
>>> The expected result is no exception and it should display the number of 
>>> pages.  This worked with version 8:6.8.9.9-5+deb8u3.
>>>
>>> Thanks for investigating this.
>>>
>>> PHP code:
>>> -
>>> >>
>>> $imagick = new Imagick();
>>> try {
>>> $imagick->pingImage('bug.pdf');
>>> }
>>> catch(ImagickException $e) {
>>> print $e->getMessage() . "\n";
>>> }
>>>
>>> $pages = $imagick->getNumberImages();
>>> print "The PDF contains $pages pages\n";
>>>
>>>
>>> -- Package-specific info:
>>> ImageMagick program version
>>> ---
>>> animate:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>>> http://www.imagemagick.org
>>> compare:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>>> http://www.imagemagick.org
>>> convert:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>>> http://www.imagemagick.org
>>> composite:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>>> http://www.imagemagick.org
>>> conjure:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>>> http://www.imagemagick.org
>>> display:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>>> http://www.imagemagick.org
>>> identify:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>>> http://www.imagemagick.org
>>> import:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>>> http://www.imagemagick.org
>>> mogrify:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>>> http://www.imagemagick.org
>>> montage:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>>> http://www.imagemagick.org
>>> stream:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>>> http://www.imagemagick.org
>>>
>>> -- System Information:
>>> Debian Release: 8.5
>>>   APT prefers stable
>>>   APT policy: (500, 'stable')
>>> Architecture: amd64 (x86_64)
>>>
>>> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
>>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>>> Shell: /bin/sh linked to /bin/dash
>>> Init: systemd (via /run/systemd/system)
>>>
>>> Versions of packages imagemagick depends on:
>>> ii  imagemagick-6.q16  8:6.8.9.9-5+deb8u4
>>>
>>> imagemagick recommends no packages.
>>>
>>> imagemagick suggests no packages.
>>>
>>> -- no debconf information
>>>
>>> ___
>>> Pkg-gmagick-im-team mailing list
>>> pkg-gmagick-im-t...@lists.alioth.debian.org
>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team

Bug#835488: [Pkg-gmagick-im-team] Bug#835488: imagemagick: Regression after security update to 8:6.8.9.9-5+deb8u4, unable to convert PDF files in PHP

[roucaries bastien]

Fixed upstream by
https://github.com/ImageMagick/ImageMagick/commit/f6242e725c819a69bee2a444f8e4a3c7718b2b3f

On Wed, Aug 31, 2016 at 9:14 AM, roucaries bastien
<roucaries.bastien+deb...@gmail.com> wrote:
> Bad pach is :
> commit 26d910675e0cd1b62e988139dba8eb11931260ac
> Author: Cristy <urban-warr...@imagemagick.org>
> Date:   Sat Jan 30 09:37:10 2016 -0500
>
> Fix out of bound in quantum handling
>
> Bug: https://github.com/ImageMagick/ImageMagick/issues/105
> bug-ubuntu:
> https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1539053
> origin: upstream,
> https://github.com/ImageMagick/ImageMagick/commit/c4e63ad30bc42da691f2b5f82a24516dd6b4dc70
> bug-debian: https://bugs.debian.org/832506
>
> On Fri, Aug 26, 2016 at 11:17 AM, Tommie Van Mechgelen <m...@tommie.it> wrote:
>> Package: imagemagick
>> Version: 8:6.8.9.9-5+deb8u4
>> Severity: important
>>
>> Dear Maintainer,
>>
>> After the upgrade to this version, converting PDF-files in PHP stopped 
>> working.
>>
>> A small PHP test application throws an exception.
>>
>> ---
>> unable to read image data `/tmp/magick-28249kJukMY5BQuJr1' @ 
>> error/pnm.c/ReadPNMImage/617
>> The PDF contains 0 pages
>> ---
>>
>> The expected result is no exception and it should display the number of 
>> pages.  This worked with version 8:6.8.9.9-5+deb8u3.
>>
>> Thanks for investigating this.
>>
>> PHP code:
>> -
>> >
>> $imagick = new Imagick();
>> try {
>> $imagick->pingImage('bug.pdf');
>> }
>> catch(ImagickException $e) {
>> print $e->getMessage() . "\n";
>> }
>>
>> $pages = $imagick->getNumberImages();
>> print "The PDF contains $pages pages\n";
>>
>>
>> -- Package-specific info:
>> ImageMagick program version
>> ---
>> animate:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>> http://www.imagemagick.org
>> compare:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>> http://www.imagemagick.org
>> convert:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>> http://www.imagemagick.org
>> composite:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>> http://www.imagemagick.org
>> conjure:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>> http://www.imagemagick.org
>> display:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>> http://www.imagemagick.org
>> identify:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>> http://www.imagemagick.org
>> import:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
>> mogrify:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>> http://www.imagemagick.org
>> montage:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
>> http://www.imagemagick.org
>> stream:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
>>
>> -- System Information:
>> Debian Release: 8.5
>>   APT prefers stable
>>   APT policy: (500, 'stable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages imagemagick depends on:
>> ii  imagemagick-6.q16  8:6.8.9.9-5+deb8u4
>>
>> imagemagick recommends no packages.
>>
>> imagemagick suggests no packages.
>>
>> -- no debconf information
>>
>> ___
>> Pkg-gmagick-im-team mailing list
>> pkg-gmagick-im-t...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team

Bug#835488: [Pkg-gmagick-im-team] Bug#835488: imagemagick: Regression after security update to 8:6.8.9.9-5+deb8u4, unable to convert PDF files in PHP

[roucaries bastien]

Bad pach is :
commit 26d910675e0cd1b62e988139dba8eb11931260ac
Author: Cristy 
Date:   Sat Jan 30 09:37:10 2016 -0500

Fix out of bound in quantum handling

Bug: https://github.com/ImageMagick/ImageMagick/issues/105
bug-ubuntu:
https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1539053
origin: upstream,
https://github.com/ImageMagick/ImageMagick/commit/c4e63ad30bc42da691f2b5f82a24516dd6b4dc70
bug-debian: https://bugs.debian.org/832506

On Fri, Aug 26, 2016 at 11:17 AM, Tommie Van Mechgelen  wrote:
> Package: imagemagick
> Version: 8:6.8.9.9-5+deb8u4
> Severity: important
>
> Dear Maintainer,
>
> After the upgrade to this version, converting PDF-files in PHP stopped 
> working.
>
> A small PHP test application throws an exception.
>
> ---
> unable to read image data `/tmp/magick-28249kJukMY5BQuJr1' @ 
> error/pnm.c/ReadPNMImage/617
> The PDF contains 0 pages
> ---
>
> The expected result is no exception and it should display the number of 
> pages.  This worked with version 8:6.8.9.9-5+deb8u3.
>
> Thanks for investigating this.
>
> PHP code:
> -
> 
> $imagick = new Imagick();
> try {
> $imagick->pingImage('bug.pdf');
> }
> catch(ImagickException $e) {
> print $e->getMessage() . "\n";
> }
>
> $pages = $imagick->getNumberImages();
> print "The PDF contains $pages pages\n";
>
>
> -- Package-specific info:
> ImageMagick program version
> ---
> animate:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> compare:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> convert:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> composite:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
> http://www.imagemagick.org
> conjure:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> display:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> identify:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
> http://www.imagemagick.org
> import:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> mogrify:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> montage:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> stream:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
>
> -- System Information:
> Debian Release: 8.5
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages imagemagick depends on:
> ii  imagemagick-6.q16  8:6.8.9.9-5+deb8u4
>
> imagemagick recommends no packages.
>
> imagemagick suggests no packages.
>
> -- no debconf information
>
> ___
> Pkg-gmagick-im-team mailing list
> pkg-gmagick-im-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team

Bug#835488: [Pkg-gmagick-im-team] Bug#835488: Bug#835488: imagemagick: Regression after security update to 8:6.8.9.9-5+deb8u4, unable to convert PDF files in PHP

[roucaries bastien]

I tried convert rose: pdf:rose.pdf
identify rose.pdf
work as expected. Seems to crash on multiple page pdf

On Mon, Aug 29, 2016 at 6:08 PM, roucaries bastien
<roucaries.bastien+deb...@gmail.com> wrote:
> On Mon, Aug 29, 2016 at 11:35 AM, Udo Pütz <udo.pu...@muon.de> wrote:
>> On Mon, 29 Aug 2016 10:31:22 +0200 =?UTF-8?B?VWRvIFDDvHR6?=
>> <udo.pu...@muon.de> wrote:
>>> On Sat, 27 Aug 2016 21:41:26 +0200 "Tommie Van Mechgelen" <m...@tommie.it>
>>> wrote:
>>> >
>>> > Hi,
>>>
>>> Hi,
>>>
>>> > The issue exists with all PDF-files that I have tried.
>>> >
>>> > I tried both commands, and the result is the same for both.  So working 
>>> > previous the security update.
>>> > identify bug.pdf
>>> > Identify -ping bug.pdf
>>> >
>>> > Â 8:6.8.9.9-5+deb8u4:
>>> > identify: unable to read image data `/tmp/magick-4028M_5kB2MxtwSv1' @ 
>>> > error/pnm.c/ReadPNMImage/617.
>>>
>>> I strace'd the php call and saw that the file in question is there (in
>>> the example above /tmp/magick-4028M_5kB2MxtwSv1), being opened and read
>>> and then unlinked. But it also tries to unlink
>>> /tmp/magick-4028M_5kB2MxtwSv1.cache (name + ".cache") - which doesn't
>>> exist. I think the bug comes from that.
>>
>> From the strace. The /tmp/magick-8360Zq2saDcjr5Vf1 was mentioned in the
>> error message but, as can be seen, was there and unlinked
>
> No it is perfectly normal (removing before reading is unix way to
> create tmp file)
>
> Could you try ltrace ?
>
>
>
>>
>> 8360  unlink("/tmp/magick-8360Zq2saDcjr5Vf1.cache") = -1 ENOENT (No such
>> file or directory)
>> 8360  unlink("/tmp/magick-8360Zq2saDcjr5Vf1") = 0
>> 8360  munmap(0x7f42fa1fb000, 790528)= 0
>> 8360  brk(0x1b2c000)= 0x1b2c000
>> 8360  open("/var/www/files/htdocs/system/logs/error.log",
>> O_WRONLY|O_CREAT|O_APPEND, 0644) = 6
>> 8360  write(6, "[29-Aug-2016 10:07:38 Europe/Ber"..., 737) = 737
>> 8360  close(6)  = 0
>> 8360  write(1, "Fatal error"..., 682) = 682
>>
>> ___
>> Pkg-gmagick-im-team mailing list
>> pkg-gmagick-im-t...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team
>

Bug#835488: [Pkg-gmagick-im-team] Bug#835488: Bug#835488: imagemagick: Regression after security update to 8:6.8.9.9-5+deb8u4, unable to convert PDF files in PHP

[roucaries bastien]

On Mon, Aug 29, 2016 at 11:35 AM, Udo Pütz  wrote:
> On Mon, 29 Aug 2016 10:31:22 +0200 =?UTF-8?B?VWRvIFDDvHR6?=
>  wrote:
>> On Sat, 27 Aug 2016 21:41:26 +0200 "Tommie Van Mechgelen" 
>> wrote:
>> >
>> > Hi,
>>
>> Hi,
>>
>> > The issue exists with all PDF-files that I have tried.
>> >
>> > I tried both commands, and the result is the same for both.  So working 
>> > previous the security update.
>> > identify bug.pdf
>> > Identify -ping bug.pdf
>> >
>> > Â 8:6.8.9.9-5+deb8u4:
>> > identify: unable to read image data `/tmp/magick-4028M_5kB2MxtwSv1' @ 
>> > error/pnm.c/ReadPNMImage/617.
>>
>> I strace'd the php call and saw that the file in question is there (in
>> the example above /tmp/magick-4028M_5kB2MxtwSv1), being opened and read
>> and then unlinked. But it also tries to unlink
>> /tmp/magick-4028M_5kB2MxtwSv1.cache (name + ".cache") - which doesn't
>> exist. I think the bug comes from that.
>
> From the strace. The /tmp/magick-8360Zq2saDcjr5Vf1 was mentioned in the
> error message but, as can be seen, was there and unlinked

No it is perfectly normal (removing before reading is unix way to
create tmp file)

Could you try ltrace ?



>
> 8360  unlink("/tmp/magick-8360Zq2saDcjr5Vf1.cache") = -1 ENOENT (No such
> file or directory)
> 8360  unlink("/tmp/magick-8360Zq2saDcjr5Vf1") = 0
> 8360  munmap(0x7f42fa1fb000, 790528)= 0
> 8360  brk(0x1b2c000)= 0x1b2c000
> 8360  open("/var/www/files/htdocs/system/logs/error.log",
> O_WRONLY|O_CREAT|O_APPEND, 0644) = 6
> 8360  write(6, "[29-Aug-2016 10:07:38 Europe/Ber"..., 737) = 737
> 8360  close(6)  = 0
> 8360  write(1, "Fatal error"..., 682) = 682
>
> ___
> Pkg-gmagick-im-team mailing list
> pkg-gmagick-im-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team

Bug#835488: [Pkg-gmagick-im-team] Bug#835488: imagemagick: Regression after security update to 8:6.8.9.9-5+deb8u4, unable to convert PDF files in PHP

[roucaries bastien]

On Fri, Aug 26, 2016 at 11:17 AM, Tommie Van Mechgelen  wrote:
> Package: imagemagick
> Version: 8:6.8.9.9-5+deb8u4
> Severity: important
>
> Dear Maintainer,
>
> After the upgrade to this version, converting PDF-files in PHP stopped 
> working.
>
> A small PHP test application throws an exception.

Does it work using command line ?

Bastien
>
> ---
> unable to read image data `/tmp/magick-28249kJukMY5BQuJr1' @ 
> error/pnm.c/ReadPNMImage/617
> The PDF contains 0 pages
> ---
>
> The expected result is no exception and it should display the number of 
> pages.  This worked with version 8:6.8.9.9-5+deb8u3.
>
> Thanks for investigating this.
>
> PHP code:
> -
> 
> $imagick = new Imagick();
> try {
> $imagick->pingImage('bug.pdf');
> }
> catch(ImagickException $e) {
> print $e->getMessage() . "\n";
> }
>
> $pages = $imagick->getNumberImages();
> print "The PDF contains $pages pages\n";
>
>
> -- Package-specific info:
> ImageMagick program version
> ---
> animate:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> compare:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> convert:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> composite:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
> http://www.imagemagick.org
> conjure:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> display:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> identify:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 
> http://www.imagemagick.org
> import:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> mogrify:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> montage:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
> stream:  ImageMagick 6.8.9-9 Q16 x86_64 2016-08-25 http://www.imagemagick.org
>
> -- System Information:
> Debian Release: 8.5
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages imagemagick depends on:
> ii  imagemagick-6.q16  8:6.8.9.9-5+deb8u4
>
> imagemagick recommends no packages.
>
> imagemagick suggests no packages.
>
> -- no debconf information
>
> ___
> Pkg-gmagick-im-team mailing list
> pkg-gmagick-im-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team

Bug#827643: [Pkg-gmagick-im-team] Bug#827643: other bug reports

[roucaries bastien]

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

On Sun, Jun 19, 2016 at 8:22 PM, David Lechner  wrote:
> Here are some related bug reports:
>
> https://bugs.launchpad.net/debian/+source/imagemagick/+bug/1594060
> https://github.com/ImageMagick/ImageMagick/pull/223
>
> ___
> Pkg-gmagick-im-team mailing list
> pkg-gmagick-im-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team

Bug#823750: [imagemagick] Multiple security problems

[roucaries bastien]

On Sun, May 29, 2016 at 11:20 AM, Salvatore Bonaccorso
 wrote:
> Hi Bastien,
>
> I'm unsure this makes sense to have a big bugreport collecting
> various issues. Can this be split in the various isolated issues?
> Otherwise it is untrackable.
>
> I for now have removed the entry from the security-tracker.

I have split the bug.

Sorry for the delay my new born baby need time

Bastien

> Regards,
> Salvatore

Bug#829292: autoconf-archive: new upstream version 2016.03.20

[roucaries bastien]

Will do please reprod in end of august if not done

On Sat, Jul 2, 2016 at 7:40 AM, Paul Wise  wrote:
> Package: autoconf-archive
> Version: 20150925-1
> Severity: wishlist
>
> The latest upstream version 2016.03.20 has some changes to AX_CHECK_GL
> that would appear to fix macOS support. The MacPorts/chromium-bsu
> maintainer encountered bugs in the version in Debian unstable:
>
> https://sourceforge.net/p/chromium-bsu/bugs/26/
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
> 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
> 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages autoconf-archive depends on:
> ii  dpkg  1.18.7
>
> Versions of packages autoconf-archive recommends:
> ii  autoconf  2.69-10
>
> autoconf-archive suggests no packages.
>
> -- no debconf information
>
> --
>
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

Bug#817842: [Pkg-gmagick-im-team] Bug#817842: imagemagick & imagemagick-6.q16 packages have the same binary

[roucaries bastien]

On Thu, Mar 10, 2016 at 11:25 PM, Vincent Fourmond  wrote:
>  Hello,
>
> On Thu, Mar 10, 2016 at 10:58 PM, Ross Gammon  wrote:
>>Whilst debugging the two desktop menu items in imagemagick (separate bug), it
>> was noticed that the two packages (imagemagick & imagemagick-6.q16) seem to
>> provide the same binary, despite the q16 package being advertised as having a
>> different quantum depth (16 v 8).
>
>   Hmmm. Is it still written somewhere that the default depth is 8 ? If
> yes, then clearly we should modify that.
>
>> Also, if offering a default quantum depth package, and one with more quantum
>> depth, would it be better to offer Q16 as the default, and Q32 as the option?
>
>   That is something we'd like to do, and it's the reason why we set up
> different packages with proper alternatives, but that's unfortunately
> not going to happen very soon.


i am returning from paternity leave and try to upload a fixed
experimental package.

After I will do a HDRI imagemagick version

Bastien
>
>   Best,
>
>   Vincent
>
> ___
> Pkg-gmagick-im-team mailing list
> pkg-gmagick-im-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gmagick-im-team

Bug#808775: CKeditor: outstanding issues and maintenance; build system

[roucaries bastien]

On Wed, Feb 3, 2016 at 4:02 PM, Dmitry Smirnov  wrote:
> Guys, we have a problem with CKeditor.
> As I've recently realised, in its current source form CKeditor can't be
> loaded dynamically which breaks one of my packages after update. Therefore
> CKeditor badly needs maintenance.
>
> I took some time to learn how to build CKeditor from source. Current way is
> not safe and not compatible with official release. The best way to build
> CKeditor is to use CKbuilder that I've just packaged (#813577). As soon as it
> will be accepted I'd like to update CKeditor ASAP so I'm offering myself as
> (co-)maintainer.


Thanks help welcome.

How do you achieve to clean ckbuilder from source is missing and
license problem ?

Last time I give up...
> Knowing that package is in poor shape and not updated for a while I took
> liberty to introduce some improvements into "master" branch that I created in
> the package repository:
>
> https://anonscm.debian.org/cgit/collab-maint/ckeditor.git
Done pushed
>
> I did that because I found repository in bad shape -- one tag incorrectly
> applied (mismatch with uploaded package), two tags missing which comes down
> to three last uploads not committed. :(
>
> In master branch I was working only within "debian" directory and I did not
> touch upstream files as I'm not too sure about repository layout and I wanted
> to avoid introducing too many layout-related changes.

Layout is gitpkg. I have added debian directory above all. I use
debian/version branch for upstream+patches+debian directory
upstream/version for upstream and debian-patches/version for upstream+patch

> Bastien, would you be interested to help or would you rather leave CKeditor
> maintenance with me (at least for some time)?

I cannot work on it now. I need to care about my new born baby.

> Frank, are you still interested in maintaining CKeditor?
>
> Thanks.
>
> --
> Best wishes,
>  Dmitry Smirnov.
>
> ---
>
> There is not enough love and goodness in the world to permit giving any of
> it away to imaginary beings.
> -- Friedrich Nietzsche

Bug#813426: [Pkg-gmagick-im-team] Bug#813426: warning: /etc/alternatives/compare is dangling; it will be updated with best choice

[roucaries bastien]

On Wed, Feb 3, 2016 at 8:47 AM, Vincent Fourmond  wrote:
> control: severity -1 serious
>
>   Hello,
>
> On Wed, Feb 3, 2016 at 12:52 AM, 積丹尼 Dan Jacobson  wrote:
>>
>> What  a   mess.
>
>   I can only agree...
>
>> Preparing to unpack .../libmagickwand-6.q16-2_8%3a6.9.2.10+dfsg-2_i386.deb 
>> ...
>> Unpacking libmagickwand-6.q16-2:i386 (8:6.9.2.10+dfsg-2) over 
>> (8:6.9.2.10+dfsg-1) ...
>> Preparing to unpack .../imagemagick-6-doc_8%3a6.9.2.10+dfsg-2_all.deb ...
>> Unpacking imagemagick-6-doc (8:6.9.2.10+dfsg-2) over (8:6.9.2.10+dfsg-1) ...
>> Preparing to unpack .../imagemagick-doc_8%3a6.9.2.10+dfsg-2_all.deb ...
>> Unpacking imagemagick-doc (8:6.9.2.10+dfsg-2) over (8:6.9.2.10+dfsg-1) ...
>> Preparing to unpack .../libmagickcore-6.q16-2_8%3a6.9.2.10+dfsg-2_i386.deb 
>> ...
>> Unpacking libmagickcore-6.q16-2:i386 (8:6.9.2.10+dfsg-2) over 
>> (8:6.9.2.10+dfsg-1) ...
>> Preparing to unpack .../imagemagick-6-common_8%3a6.9.2.10+dfsg-2_all.deb ...
>> Unpacking imagemagick-6-common (8:6.9.2.10+dfsg-2) over (8:6.9.2.10+dfsg-1) 
>> ...
>> dpkg: warning: unable to delete old directory '/etc/etc/ImageMagick-6': 
>> Directory not empty
>> dpkg: warning: unable to delete old directory '/etc/etc': Directory not empty
>> Preparing to unpack .../libfftw3-single3_3.3.4-2+b1_i386.deb ...
>> Unpacking libfftw3-single3:i386 (3.3.4-2+b1) over (3.3.4-2) ...
>> Preparing to unpack .../libdebconfclient0_0.204_i386.deb ...
>> Unpacking libdebconfclient0:i386 (0.204) over (0.203) ...
>> Processing triggers for man-db (2.7.5-1) ...
>> Processing triggers for systemd (228-4+b1) ...
>> Processing triggers for libc-bin (2.22-0experimental1) ...
>> Processing triggers for doc-base (0.10.7) ...
>> Processing 1 changed doc-base file...
>> Registering documents with scrollkeeper...
>> Setting up libdebconfclient0:i386 (0.204) ...
>> Processing triggers for libc-bin (2.22-0experimental1) ...
>> Preparing to unpack .../isc-dhcp-client_4.3.3-7_i386.deb ...
>> Unpacking isc-dhcp-client (4.3.3-7) over (4.3.3-6) ...
>> Preparing to unpack .../isc-dhcp-common_4.3.3-7_i386.deb ...
>> Unpacking isc-dhcp-common (4.3.3-7) over (4.3.3-6) ...
>> Preparing to unpack .../libboost-iostreams1.58.0_1.58.0+dfsg-4.1+b1_i386.deb 
>> ...
>> Unpacking libboost-iostreams1.58.0:i386 (1.58.0+dfsg-4.1+b1) over 
>> (1.58.0+dfsg-4.1) ...
>> Preparing to unpack .../libgnutls30_3.4.8-3_i386.deb ...
>> Unpacking libgnutls30:i386 (3.4.8-3) over (3.4.8-2) ...
>> Preparing to unpack .../libasound2-data_1.1.0-1_all.deb ...
>> Unpacking libasound2-data (1.1.0-1) over (1.0.29-1) ...
>> Preparing to unpack .../libasound2_1.1.0-1_i386.deb ...
>> Unpacking libasound2:i386 (1.1.0-1) over (1.0.29-1) ...
>> Preparing to unpack .../alsa-utils_1.1.0-1_i386.deb ...
>> Unpacking alsa-utils (1.1.0-1) over (1.0.29-1+b1) ...
>> Preparing to unpack .../archives/bdf2psf_1.136_all.deb ...
>> Unpacking bdf2psf (1.136) over (1.135) ...
>> Preparing to unpack .../debian-policy_3.9.7.0_all.deb ...
>> Unpacking debian-policy (3.9.7.0) over (3.9.6.1) ...
>> Preparing to unpack .../dosfstools_3.99.0~git20160127-2_i386.deb ...
>> Unpacking dosfstools (3.99.0~git20160127-2) over (3.0.28-2) ...
>> Preparing to unpack .../imagemagick_8%3a6.9.2.10+dfsg-2_all.deb ...
>> dpkg-query: no packages found matching imagemagick:all
>> dpkg-query: package 'imagemagick' is not installed
>> Use dpkg --info (= dpkg-deb --info) to examine archive files,
>> and dpkg --contents (= dpkg-deb --contents) to list their contents.
>> dpkg-query: package 'imagemagick' is not installed
>> Use dpkg --info (= dpkg-deb --info) to examine archive files,
>> and dpkg --contents (= dpkg-deb --contents) to list their contents.
>> dpkg-query: package 'imagemagick' is not installed
>> Use dpkg --info (= dpkg-deb --info) to examine archive files,
>> [...]
>> Use dpkg --info (= dpkg-deb --info) to examine archive files,
>> and dpkg --contents (= dpkg-deb --contents) to list their contents.
>
>   This looks like a dpkg bug -- dpkg doesn't like so much switching
> from arch:any to arch:all, as far as I can tell.
>
>   BTW, you show a very long list of warning messages, did they stop by
> themselves ? If yes, I'm very curious why.
>
>> dpkg-maintscript-helper: error: directory '/usr/share/doc/imagemagick' 
>> contains files not owned by package imagemagick:all, cannot switch to symlink
>> dpkg: error processing archive 
>> /var/cache/apt/archives/imagemagick_8%3a6.9.2.10+dfsg-2_all.deb (--unpack):
>>  subprocess new pre-installation script returned error exit status 1
>> Preparing to unpack .../imagemagick-6.q16_8%3a6.9.2.10+dfsg-2_i386.deb ...
>> Unpacking imagemagick-6.q16 (8:6.9.2.10+dfsg-2) over (8:6.9.2.10+dfsg-1) ...
>> Preparing to unpack .../iso-codes_3.65-1_all.deb ...


This one is #813455

Bastien

>   Thanks !
>
>   Vincent
>
> ___
> Pkg-gmagick-im-team mailing list
> pkg-gmagick-im-t...@lists.alioth.debian.org
> 

Bug#813426: [Pkg-gmagick-im-team] Bug#813426: warning: /etc/alternatives/compare is dangling; it will be updated with best choice

[roucaries bastien]

On Wed, Feb 3, 2016 at 8:47 AM, Vincent Fourmond  wrote:
> control: severity -1 serious
>
>   Hello,
>
> On Wed, Feb 3, 2016 at 12:52 AM, 積丹尼 Dan Jacobson  wrote:
>>
>> What  a   mess.
>
>   I can only agree...

It is experimental
>
>> Preparing to unpack .../libmagickwand-6.q16-2_8%3a6.9.2.10+dfsg-2_i386.deb 
>> ...
>> Unpacking libmagickwand-6.q16-2:i386 (8:6.9.2.10+dfsg-2) over 
>> (8:6.9.2.10+dfsg-1) ...
>> Preparing to unpack .../imagemagick-6-doc_8%3a6.9.2.10+dfsg-2_all.deb ...
>> Unpacking imagemagick-6-doc (8:6.9.2.10+dfsg-2) over (8:6.9.2.10+dfsg-1) ...
>> Preparing to unpack .../imagemagick-doc_8%3a6.9.2.10+dfsg-2_all.deb ...
>> Unpacking imagemagick-doc (8:6.9.2.10+dfsg-2) over (8:6.9.2.10+dfsg-1) ...
>> Preparing to unpack .../libmagickcore-6.q16-2_8%3a6.9.2.10+dfsg-2_i386.deb 
>> ...
>> Unpacking libmagickcore-6.q16-2:i386 (8:6.9.2.10+dfsg-2) over 
>> (8:6.9.2.10+dfsg-1) ...
>> Preparing to unpack .../imagemagick-6-common_8%3a6.9.2.10+dfsg-2_all.deb ...
>> Unpacking imagemagick-6-common (8:6.9.2.10+dfsg-2) over (8:6.9.2.10+dfsg-1) 
>> ...
>> dpkg: warning: unable to delete old directory '/etc/etc/ImageMagick-6': 
>> Directory not empty
>> dpkg: warning: unable to delete old directory '/etc/etc': Directory not empty
>> Preparing to unpack .../libfftw3-single3_3.3.4-2+b1_i386.deb ...
>> Unpacking libfftw3-single3:i386 (3.3.4-2+b1) over (3.3.4-2) ...
>> Preparing to unpack .../libdebconfclient0_0.204_i386.deb ...
>> Unpacking libdebconfclient0:i386 (0.204) over (0.203) ...
>> Processing triggers for man-db (2.7.5-1) ...
>> Processing triggers for systemd (228-4+b1) ...
>> Processing triggers for libc-bin (2.22-0experimental1) ...
>> Processing triggers for doc-base (0.10.7) ...
>> Processing 1 changed doc-base file...
>> Registering documents with scrollkeeper...
>> Setting up libdebconfclient0:i386 (0.204) ...
>> Processing triggers for libc-bin (2.22-0experimental1) ...
>> Preparing to unpack .../isc-dhcp-client_4.3.3-7_i386.deb ...
>> Unpacking isc-dhcp-client (4.3.3-7) over (4.3.3-6) ...
>> Preparing to unpack .../isc-dhcp-common_4.3.3-7_i386.deb ...
>> Unpacking isc-dhcp-common (4.3.3-7) over (4.3.3-6) ...
>> Preparing to unpack .../libboost-iostreams1.58.0_1.58.0+dfsg-4.1+b1_i386.deb 
>> ...
>> Unpacking libboost-iostreams1.58.0:i386 (1.58.0+dfsg-4.1+b1) over 
>> (1.58.0+dfsg-4.1) ...
>> Preparing to unpack .../libgnutls30_3.4.8-3_i386.deb ...
>> Unpacking libgnutls30:i386 (3.4.8-3) over (3.4.8-2) ...
>> Preparing to unpack .../libasound2-data_1.1.0-1_all.deb ...
>> Unpacking libasound2-data (1.1.0-1) over (1.0.29-1) ...
>> Preparing to unpack .../libasound2_1.1.0-1_i386.deb ...
>> Unpacking libasound2:i386 (1.1.0-1) over (1.0.29-1) ...
>> Preparing to unpack .../alsa-utils_1.1.0-1_i386.deb ...
>> Unpacking alsa-utils (1.1.0-1) over (1.0.29-1+b1) ...
>> Preparing to unpack .../archives/bdf2psf_1.136_all.deb ...
>> Unpacking bdf2psf (1.136) over (1.135) ...
>> Preparing to unpack .../debian-policy_3.9.7.0_all.deb ...
>> Unpacking debian-policy (3.9.7.0) over (3.9.6.1) ...
>> Preparing to unpack .../dosfstools_3.99.0~git20160127-2_i386.deb ...
>> Unpacking dosfstools (3.99.0~git20160127-2) over (3.0.28-2) ...
>> Preparing to unpack .../imagemagick_8%3a6.9.2.10+dfsg-2_all.deb ...
>> dpkg-query: no packages found matching imagemagick:all
>> dpkg-query: package 'imagemagick' is not installed
>> Use dpkg --info (= dpkg-deb --info) to examine archive files,
>> and dpkg --contents (= dpkg-deb --contents) to list their contents.
>> dpkg-query: package 'imagemagick' is not installed
>> Use dpkg --info (= dpkg-deb --info) to examine archive files,
>> and dpkg --contents (= dpkg-deb --contents) to list their contents.
>> dpkg-query: package 'imagemagick' is not installed
>> Use dpkg --info (= dpkg-deb --info) to examine archive files,
>> [...]
>> Use dpkg --info (= dpkg-deb --info) to examine archive files,
>> and dpkg --contents (= dpkg-deb --contents) to list their contents.
>
>   This looks like a dpkg bug -- dpkg doesn't like so much switching
> from arch:any to arch:all, as far as I can tell.
>
>   BTW, you show a very long list of warning messages, did they stop by
> themselves ? If yes, I'm very curious why.
>
>> dpkg-maintscript-helper: error: directory '/usr/share/doc/imagemagick' 
>> contains files not owned by package imagemagick:all, cannot switch to symlink
>> dpkg: error processing archive 
>> /var/cache/apt/archives/imagemagick_8%3a6.9.2.10+dfsg-2_all.deb (--unpack):
>>  subprocess new pre-installation script returned error exit status 1
>> Preparing to unpack .../imagemagick-6.q16_8%3a6.9.2.10+dfsg-2_i386.deb ...
>> Unpacking imagemagick-6.q16 (8:6.9.2.10+dfsg-2) over (8:6.9.2.10+dfsg-1) ...
>> Preparing to unpack .../iso-codes_3.65-1_all.deb ...
>
>   Thanks !
>
>   Vincent
>
> ___
> Pkg-gmagick-im-team mailing list
> pkg-gmagick-im-t...@lists.alioth.debian.org
> 

Bug#809768: RFS: kbibtex/0.6+git7fdc0cd97c093f-1

[roucaries bastien]

On Mon, Jan 4, 2016 at 2:56 PM, Mattia Rizzolo  wrote:
> control: tag -1 moreinfo
> control: owner -1 !
>
> On Sun, Jan 03, 2016 at 09:26:26PM +0100, Bastien ROUCARIÈS wrote:
>> I am looking for a sponsor for my package "kbibtex"
>
> sure.
>
>>   More information about hello can be obtained from http://www.example.com.
>
> would be handy if people would at least read the template (also on the
> other RFS, btw..) :)
>
>
> stuff I don't like:
>
> * you overwrote the last upload changelog entry.  don't do that.
> * I think I'd prefer a more verbose changelog, instead of "upgrade
>   debian package" (at least the latter 3?)
>   + add of 001-add-keywords-to-desktop.patch
>   + remove README.source
>   + rewrite of d/watch
>   + remove of the menu file
> * in d/control you mix tab and spaces in a depends line, another
>   wrap-and-sort run should fix it
> * you use compat level 9, the following is just unneded:
>   +DPKG_EXPORT_BUILDFLAGS = 1
>   +include /usr/share/dpkg/buildflags.mk
> * is there a reason to put private libs in a public location (instead
>   of just overriding lintian naggings).
>   If those a private stuff I'd expect them to be under a /directory/.

Fixed with your comments. Could you get a glimpse

Bastien

> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  http://mapreri.org  : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Bug#788729: closed by Michael Biebl <bi...@debian.org> (Re: [src:libgda5] Some sources are not included in your package)

[roucaries bastien]

control: reopen -1

On Sat, Jan 16, 2016 at 11:36 PM, Debian Bug Tracking System
 wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:libgda5 package:
>
> #788729: [src:libgda5] Some sources are not included in your package
>
> It has been closed by Michael Biebl .
>
> 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 Michael Biebl 
>  by
> replying to this email.
>
>
> --
> 788729: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788729
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Michael Biebl 
> To: 788729-d...@bugs.debian.org
> Cc:
> Date: Sat, 16 Jan 2016 23:34:19 +0100
> Subject: Re: [src:libgda5] Some sources are not included in your package
> Version: 4.0.2-1
> On Sun, 14 Jun 2015 16:50:52 + bastien =?ISO-8859-1?Q?ROUCARI=C8S?=
>  wrote:
>> Package: src:libgda5
>> Version:  5.2.2-2
>> user: lintian-ma...@debian.org
>> usertags: source-is-missing
>> severity: serious
>> X-Debbugs-CC: ftpmas...@debian.org
>>
>> Hi,
>>
>> Your package includes some files that seem to lack sources
>> in prefered forms of modification:
>>
>> tools/jquery.js
>>
>> According to Debian Free Software Guidelines [1] (DFSG) #2:
>>  "The program must include source code, and must allow distribution
>>   in source code as well as compiled form."
>>
>> In some cases this could also constitute a license violation for some
>> copyleft licenses such as the GNU GPL. (While sometimes the licence
>> allows not to ship the source, the DFSG always mandates source code.)
>>
>> In order to solve this problem, you could:
>> 1.  add the source files to "debian/missing-sources" directory.
>> 2. repack the origin tarball and add the missing source files to it.
>>
>> Both way satisfy the requirement to ship all source code. The second option
>> might be preferable due to the following reasons [2]:
>>  - Upstream can do it too and you could even supply a patch to them, thus
>>full filling our social contract [3], see particularly §2.
>>  - If source and non-source are in different locations, ftpmasters may
>>miss the source and (needlessly) reject the package.
>>  - The source isn't duplicated in every .diff.gz/.debian.tar.* (though
>>this only really matters for larger sources).
>>
>> You could also ask debian...@lists.debian.org or #debian-qa for more
>> guidance.
>>
>> [1] https://www.debian.org/social_contract.en.html#guidelines
>> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736873#8
>> [3] https://www.debian.org/social_contract
>
> Closing, false positive:
>
> libgda4 (4.0.2-1) unstable; urgency=low
>
>
> - Don't ship our own copy of jquery.js, link to the one in libjs-jquery
>   instead. Thus depend on libjs-jquery.
>

No see http://sources.debian.net/src/libgda4/4.0.12-1/tools/jquery.js/

Corrected at build time see debian/rules, but you need a repack

Thanks


> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>
>
> -- Forwarded message --
> From: "bastien ROUCARIÈS" 
> To: sub...@bugs.debian.org
> Cc:
> Date: Sun, 14 Jun 2015 16:50:52 +
> Subject: [src:libgda5] Some sources are not included in your package
> Package: src:libgda5
> Version:  5.2.2-2
> user: lintian-ma...@debian.org
> usertags: source-is-missing
> severity: serious
> X-Debbugs-CC: ftpmas...@debian.org
>
> Hi,
>
> Your package includes some files that seem to lack sources
> in prefered forms of modification:
>
> tools/jquery.js
>
> According to Debian Free Software Guidelines [1] (DFSG) #2:
>  "The program must include source code, and must allow distribution
>   in source code as well as compiled form."
>
> In some cases this could also constitute a license violation for some
> copyleft licenses such as the GNU GPL. (While sometimes the licence
> allows not to ship the source, the DFSG always mandates source code.)
>
> In order to solve this problem, you could:
> 1.  add the source files to "debian/missing-sources" directory.
> 2. repack the origin tarball and add the missing source files to it.
>
> Both way satisfy the requirement to ship all source code. The second option
> might be preferable due to the following reasons [2]:
>  - Upstream can do it too and you could even supply a patch to them, thus
>full filling our social contract [3], see particularly §2.
>  - If source and non-source are in different locations, ftpmasters may
>miss the source and (needlessly) reject the package.
>  - The source isn't duplicated in every .diff.gz/.debian.tar.* (though
>this only really matters for larger sources).
>
> You 

Bug#788729: closed by Michael Biebl <bi...@debian.org> (Re: [src:libgda5] Some sources are not included in your package)

[roucaries bastien]

control: found -1 4.0.2-1.

On Sun, Jan 17, 2016 at 2:52 PM, roucaries bastien
<roucaries.bastien+deb...@gmail.com> wrote:
> control: reopen -1
>
> On Sat, Jan 16, 2016 at 11:36 PM, Debian Bug Tracking System
> <ow...@bugs.debian.org> wrote:
>> This is an automatic notification regarding your Bug report
>> which was filed against the src:libgda5 package:
>>
>> #788729: [src:libgda5] Some sources are not included in your package
>>
>> It has been closed by Michael Biebl <bi...@debian.org>.
>>
>> 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 Michael Biebl 
>> <bi...@debian.org> by
>> replying to this email.
>>
>>
>> --
>> 788729: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788729
>> Debian Bug Tracking System
>> Contact ow...@bugs.debian.org with problems
>>
>>
>> -- Forwarded message --
>> From: Michael Biebl <bi...@debian.org>
>> To: 788729-d...@bugs.debian.org
>> Cc:
>> Date: Sat, 16 Jan 2016 23:34:19 +0100
>> Subject: Re: [src:libgda5] Some sources are not included in your package
>> Version: 4.0.2-1
>> On Sun, 14 Jun 2015 16:50:52 + bastien =?ISO-8859-1?Q?ROUCARI=C8S?=
>> <roucaries.bastien+deb...@gmail.com> wrote:
>>> Package: src:libgda5
>>> Version:  5.2.2-2
>>> user: lintian-ma...@debian.org
>>> usertags: source-is-missing
>>> severity: serious
>>> X-Debbugs-CC: ftpmas...@debian.org
>>>
>>> Hi,
>>>
>>> Your package includes some files that seem to lack sources
>>> in prefered forms of modification:
>>>
>>> tools/jquery.js
>>>
>>> According to Debian Free Software Guidelines [1] (DFSG) #2:
>>>  "The program must include source code, and must allow distribution
>>>   in source code as well as compiled form."
>>>
>>> In some cases this could also constitute a license violation for some
>>> copyleft licenses such as the GNU GPL. (While sometimes the licence
>>> allows not to ship the source, the DFSG always mandates source code.)
>>>
>>> In order to solve this problem, you could:
>>> 1.  add the source files to "debian/missing-sources" directory.
>>> 2. repack the origin tarball and add the missing source files to it.
>>>
>>> Both way satisfy the requirement to ship all source code. The second option
>>> might be preferable due to the following reasons [2]:
>>>  - Upstream can do it too and you could even supply a patch to them, thus
>>>full filling our social contract [3], see particularly §2.
>>>  - If source and non-source are in different locations, ftpmasters may
>>>miss the source and (needlessly) reject the package.
>>>  - The source isn't duplicated in every .diff.gz/.debian.tar.* (though
>>>this only really matters for larger sources).
>>>
>>> You could also ask debian...@lists.debian.org or #debian-qa for more
>>> guidance.
>>>
>>> [1] https://www.debian.org/social_contract.en.html#guidelines
>>> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736873#8
>>> [3] https://www.debian.org/social_contract
>>
>> Closing, false positive:
>>
>> libgda4 (4.0.2-1) unstable; urgency=low
>>
>>
>> - Don't ship our own copy of jquery.js, link to the one in libjs-jquery
>>   instead. Thus depend on libjs-jquery.
>>
>
> No see http://sources.debian.net/src/libgda4/4.0.12-1/tools/jquery.js/
>
> Corrected at build time see debian/rules, but you need a repack
>
> Thanks
>
>
>> --
>> Why is it that all of the instruments seeking intelligent life in the
>> universe are pointed away from Earth?
>>
>>
>>
>> -- Forwarded message --
>> From: "bastien ROUCARIÈS" <roucaries.bastien+deb...@gmail.com>
>> To: sub...@bugs.debian.org
>> Cc:
>> Date: Sun, 14 Jun 2015 16:50:52 +
>> Subject: [src:libgda5] Some sources are not included in your package
>> Package: src:libgda5
>> Version:  5.2.2-2
>> user: lintian-ma...@debian.org
>> usertags: source-is-missing
>> severity: serious
>> X-Debbugs-CC: ftpmas...@debian.org
>>
>> Hi,
>>
>> Your package includes some files that seem to lack sources
>> in prefered forms of modification:
>>
>> tools/jquery.js
>>
>>

Bug#809691: Would you volunteer to take over the maintenance under my sponsorship

[roucaries bastien]

On Tue, Jan 12, 2016 at 9:27 AM, Andreas Tille  wrote:
> Hi Oliver,
>
> it seems Bastien has lost interest in this package.  It just popped up
> in my sentinel of packages that are in the focus of Debian Med but not
> uploaded for a long time.  If you have no idea how to maintain a package
> I'd consider a "Mentoring of the Month"[1] for Debian Science.
>
> Kind regards
>
>   Andreas.


Did you see my last update under mentors ?

I have just uploaded a new version, and I am going to upload this
evening a modified version.

So no thanks.

BTW new version is based on git tree in order to be kde5 compatible

Bastien
>
> [1] https://wiki.debian.org/DebianMed/MoM
>
> --
> http://fam-tille.de

Bug#798215: RFS: node-typedarray/0.0.6-1 [ITP]

[roucaries bastien]

On Mon, Sep 7, 2015 at 3:05 PM, Gianfranco Costamagna
 wrote:
> Control: owner -1 !
> Control: tags -1 moreinfo
>
> Hi Ross,
> 1) control: "priority: extra"
>
> as said before on debian-mentors the priority should be optional, unless you 
> have good reason to
> have extra
> https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities
>
> 2) "In order to run the tests provided with node-typedarray, it will be
>
> necessary to package tape for Debian."
>
> well, isn't it better to start from tape then?
>

No tape need grunt and a lot of non packaged package that reverse dep
on this package

> cheers,
>
>
> G.
>

Bug#770009: convert(1) very slow on mips with no FPU

[roucaries bastien]

On Sun, Aug 16, 2015 at 1:36 AM, James Cowgill james...@cowgill.org.uk wrote:
 On Sat, 2015-08-15 at 23:18 +0200, roucaries bastien wrote:
 On Sat, Aug 15, 2015 at 10:30 PM, roucaries bastien
 roucaries.bastien+deb...@gmail.com wrote:
  On Sat, Aug 15, 2015 at 10:16 PM, roucaries bastien
  roucaries.bastien+deb...@gmail.com wrote:
   On Sat, Aug 15, 2015 at 9:43 PM, James Cowgill james...@cowgill.org.uk 
   wrote:
Yes the ABI is different - you need a recompiled glibc (at least) to
use -msoft-float.
  
   Could this handled like libc-i686 ? It will be really helpful to have
   a soft-float version and use ld.so to switch between.
 
  They are a thread here about multilib
  https://lists.linaro.org/pipermail/cross-distro/2012-April/000167.html

 It could work, but I don't think mixed soft/hard float systems are
 supported very well (probably not many people are crazy enough to want
 this). You would need to use an alternate (and non standard) dynamic
 linker path, and some patches will be needed so ld/ld.so chooses the
 right library.

 BTW information about mips box are outdated here
 https://wiki.debian.org/MIPSPort

 Thanks. I can add some of the newer buildds, but I don't know exactly
 which ones have been retired.


Could you also add where they are FPU ?

Thanks
 It worked under ball but it seems ball was retired...

 I think ball did have an FPU.
 Thanks,
 James