NEW changes in stable-new

2018-05-04 Thread Debian FTP Masters
Processing changes file: tzdata_2018e-0+deb9u1_all.changes
  ACCEPT



Forbidding Firefox addons from testing & stable (was: Firefox 60esr on Stretch ?)

2018-05-04 Thread Sean Whitton
Hello,

On Fri, May 04 2018, Moritz Mühlenhoff wrote:

> Same as all previous extension breakages incurred by ESR transitions;
> not at all. Apart from enigmail those are all not updated along in
> stable, this doesn't scale at all. If you want your extensions to be
> kept compatible, get them from the Mozilla addons page like every
> other Firefox/Thunderbird user.
>
> We should make it easy for administrators of bigger desktop
> deployments to easily create debs for local deployments, but keeping
> all those extensions in a stable release is just broken and we should
> block them from testing migration.

Is there a precedent for declaring a whole class of packages RC-buggy,
yet continuing to offer them in the unstable and experimental suites
(that it what we would need in order to make it easy for administrators
to create those debs: we'd need to be actively using the tooling
ourselves)?

In this case, I take it the point is that the special exception for
updating src:firefox-esr in stable justifies excluding packages that
effectively depend on specific versions of firefox-esr.

The only case I know of a package that will never migrate to testing,
but isn't RMed, is a single package, src:firefox.

It would also be good to know what the Release Team think of Moritz's
proposal, since they have authority over what goes into testing.

-- 
Sean Whitton


signature.asc
Description: PGP signature


NEW changes in stable-new

2018-05-04 Thread Debian FTP Masters
Processing changes file: tzdata_2018e-0+deb9u1_source.changes
  ACCEPT



NEW changes in stable-new

2018-05-04 Thread Debian FTP Masters
Processing changes file: libdatetime-timezone-perl_2.09-1+2018e_amd64.changes
  ACCEPT
Processing changes file: openjdk-8_8u171-b11-1~deb9u1_amd64.changes
  ACCEPT
Processing changes file: openjdk-8_8u171-b11-1~deb9u1_arm64.changes
  ACCEPT
Processing changes file: openjdk-8_8u171-b11-1~deb9u1_armel.changes
  ACCEPT
Processing changes file: openjdk-8_8u171-b11-1~deb9u1_armhf.changes
  ACCEPT
Processing changes file: openjdk-8_8u171-b11-1~deb9u1_i386.changes
  ACCEPT
Processing changes file: openjdk-8_8u171-b11-1~deb9u1_mips.changes
  ACCEPT
Processing changes file: openjdk-8_8u171-b11-1~deb9u1_mips64el.changes
  ACCEPT
Processing changes file: openjdk-8_8u171-b11-1~deb9u1_mipsel.changes
  ACCEPT
Processing changes file: openjdk-8_8u171-b11-1~deb9u1_ppc64el.changes
  ACCEPT
Processing changes file: openjdk-8_8u171-b11-1~deb9u1_s390x.changes
  ACCEPT



NEW changes in oldstable-new

2018-05-04 Thread Debian FTP Masters
Processing changes file: libdatetime-timezone-perl_1.75-2+2018e_amd64.changes
  ACCEPT
Processing changes file: tzdata_2018e-0+deb8u1_amd64.changes
  ACCEPT



Bug#897911: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2018e

2018-05-04 Thread Adam D. Barratt
Control: tags -1 + pending

On Fri, 2018-05-04 at 19:06 +0200, gregor herrmann wrote:
> I've uploaded libdatetime-timezone-perl/1:1.75-2+2018e for
> jessie(-updates). It contains a new patch which updates the data
> files to the Olson db release 2018e, which contains changes for North
> Korea effective tomorrow.
> 

Thanks; flagged for acceptance.

Regards,

Adam



Processed: Re: Bug#897912: stretch-pu: package libdatetime-timezone-perl/1:2.09-1+2018e

2018-05-04 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 + pending
Bug #897912 [release.debian.org] stretch-pu: package 
libdatetime-timezone-perl/1:2.09-1+2018e
Added tag(s) pending.

-- 
897912: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897912
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#897912: stretch-pu: package libdatetime-timezone-perl/1:2.09-1+2018e

2018-05-04 Thread Adam D. Barratt
Control: tags -1 + pending

On Fri, 2018-05-04 at 19:06 +0200, gregor herrmann wrote:
> I've uploaded libdatetime-timezone-perl/1:2.09-1+2018e for
> strech(-updates). It contains a new patch which updates the data
> files to the Olson db release 2018e, which contains changes for North
> Korea effective tomorrow.
> 

Thanks. Flagged for acceptance.

Regards,

Adam



Processed: Re: Bug#897911: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2018e

2018-05-04 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 + pending
Bug #897911 [release.debian.org] jessie-pu: package 
libdatetime-timezone-perl/1:1.75-2+2018e
Added tag(s) pending.

-- 
897911: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897911
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#897923: stretch-pu: package tclreadline/2.1.0-15+deb9u1 pre-approval

2018-05-04 Thread Breno Leitao
On Fri, 04 May 2018 23:22:15 +0300 Sergei Golovan  wrote:

> I would like to upload the tclreadline package to stretch. The package
> currently in stable misses a shared library for the ppc64el architecture,
> as indicated in [1]. I'm attaching the package diff for review. It's
> tested using he ppc64el QEMU installation, and it builds fine now.

I also tested on a real ppc64el machine and this debdiff fixes the problem.

Thanks Sergei!



Bug#897923: stretch-pu: package tclreadline/2.1.0-15+deb9u1 pre-approval

2018-05-04 Thread Sergei Golovan
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi!

I would like to upload the tclreadline package to stretch. The package
currently in stable misses a shared library for the ppc64el architecture,
as indicated in [1]. I'm attaching the package diff for review. It's
tested using he ppc64el QEMU installation, and it builds fine now.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897429

-- System Information:
Debian Release: 9.4
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'proposed-updates'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru tclreadline-2.1.0/debian/changelog tclreadline-2.1.0/debian/changelog
--- tclreadline-2.1.0/debian/changelog  2016-10-08 12:04:28.0 +0300
+++ tclreadline-2.1.0/debian/changelog  2016-10-08 12:04:28.0 +0300
@@ -1,3 +1,10 @@
+tclreadline (2.1.0-15+deb9u1) stretch; urgency=medium
+
+  * Add a patch by Breno Leitao which fixes building the shared library for
+   the ppc64el architecture (closes: #897429).
+
+ -- Sergei Golovan   Sat, 08 Oct 2016 12:04:28 +0300
+
 tclreadline (2.1.0-15) unstable; urgency=low
 
   * Fixed implicit function declararion warning (replaced the deprecated
diff -Nru tclreadline-2.1.0/debian/patches/ppc64el.patch 
tclreadline-2.1.0/debian/patches/ppc64el.patch
--- tclreadline-2.1.0/debian/patches/ppc64el.patch  1970-01-01 
03:00:00.0 +0300
+++ tclreadline-2.1.0/debian/patches/ppc64el.patch  2016-10-08 
12:04:28.0 +0300
@@ -0,0 +1,15 @@
+Author: Breno Leitao
+Description: Patch fixes building the shared library for ppc64el.
+Last-Modified: Wed, 02 May 2018 21:11:16 +0300
+Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897429
+
+--- a/aux/ltconfig
 b/aux/ltconfig
+@@ -2000,7 +2000,6 @@
+   else
+ # Only the GNU ld.so supports shared libraries on MkLinux.
+ case "$host_cpu" in
+-powerpc*) dynamic_linker=no ;;
+ *) dynamic_linker='Linux ld.so' ;;
+ esac
+   fi
diff -Nru tclreadline-2.1.0/debian/patches/series 
tclreadline-2.1.0/debian/patches/series
--- tclreadline-2.1.0/debian/patches/series 2016-10-08 12:04:28.0 
+0300
+++ tclreadline-2.1.0/debian/patches/series 2016-10-08 12:04:28.0 
+0300
@@ -12,3 +12,4 @@
 functions.patch
 ding.patch
 stubs.patch
+ppc64el.patch


Re: How to deal with non-functional package in stretch? (Was: Bug#897605: profphd failure in stretch)

2018-05-04 Thread Andreas Tille
Hi Tanya,

thanks for your comments.

On Fri, May 04, 2018 at 07:11:22PM +0300, merlettaia wrote:
> This is fixed in version 1.0.42-2, and not present in version 1.0.42-1,
> which seems to be latest in stretch (both with tests).
> At patches dir:
> 
>   https://salsa.debian.org/med-team/profphd/blob/master/
> debian/patches/2_remove_perlbrew_usage.patch
> - this disables perlbrew usage (this was temporary, it would be wiser to
> replace this patch with the one which removes if-then-statement completely,
> because this "temporary" fix just confuses and intricates code logic in
> long-term perspective),
> 
>   https://salsa.debian.org/med-team/profphd/blob/master/
> debian/patches/3_fix_indexing.patch - and as far as I remember this fixes
> actual erratic behavior with latest versions of perl, which was the reason
> why that if-then-else statement appeared in profphd code (the main problem
> here is the "$["-magic in perl).
> 
> Other patches fix error or warning messages, which appeared in almost all
> rostlab packages and were not as tricky as this one.

If you ask me the most sensible approach would be to use exactly
1.0.42-2 since this is solidly tested.

> P.S. - I could work on fixing this bug late at the evening or tomorrow,
> because at this moment I have no Debian distribution or VM somewhere
> nearby, and I could check that everything works after I come home. In case
> if Liubov has time for solving this before that and she is not working on
> something else I've added her to CC.

Before you spent some time on removing sensible patches I'd first like
to hear the opinion of the release team whether my argument to use
something tested is better as the minimum diff to the current package
in Stretch.

Kind regards

 Andreas.

-- 
http://fam-tille.de



Bug#897912: stretch-pu: package libdatetime-timezone-perl/1:2.09-1+2018e

2018-05-04 Thread gregor herrmann
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.09-1+2018e for
strech(-updates). It contains a new patch which updates the data
files to the Olson db release 2018e, which contains changes for North
Korea effective tomorrow.

Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlrskylfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZMYQ/9FSCrT+YFEfONUgq4OrkRjiFAkRQgPkeX8H24O9OfrKJhDOACZgNe9Wsn
oMlCDbI+RqGambIV+KkBQyAX/5qxqkDHk+sXckP7FsJ5g63T1lgKJRMRKG/Sg8cG
TKypBIqMTMeA2AhahXwicY+Vcp1t12P8k8JEfOtKFkG7AAXKeNvOeyqMtMRlYYPV
Arm7L4/YeY9RYP3Rzcs8vfsrYW6oqS/2KMl97ZhnwqzBvwVO+X9t5l8wA0Shgmo8
Jz1/7Qb+H40qPlKZEnJxTZJ28nNyObgNbKcDQs4LSF93d5mEelhWimbBN6+lLAQn
xYhgywQ0dz90iiZK7ZfJoJjZeJoUAINqn8aB1QgNYGEZtVd6qKiryw608sByjXu9
Rh7sRKfCvdm2LKKP6qTy0cTP7d248XNtN70CHbbCJRsz51lK1CJmbpd+WbakyzFw
9HnvR7MX3JQkPciFDa72r+SQCZuvQlPyfBCUlpSfnJi7XzBDJMuO4iiz5m/xykVz
13+CQA+EkdENbALRcUTlp9jKmb01WAcNSxRaZJU7Cg9X410vwX7Qh17ZSfsNYZ+X
DKNTnBFH0pqBdJh5OJkHTtt971QkZtmlFG9mB3EblScP4LA9X28VNJi6K2Pjwq8X
UvwOlhj0mMfIjkvYiiNCuA6VR3ZlbInsNqFSQg9eCA7zOHOE30k=
=WVWY
-END PGP SIGNATURE-



Bug#897911: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2018e

2018-05-04 Thread gregor herrmann
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:1.75-2+2018e for
jessie(-updates). It contains a new patch which updates the data
files to the Olson db release 2018e, which contains changes for North
Korea effective tomorrow.

Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlrskyVfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYUNhAAkQ9r2Z1AXyhCeP3VwT3Lf37J8l46gRWrcjHDSmzNDBMJj25Xb2gnd+QW
9pMPs4JlLDPrj/9h282NlDnW2LfTb1fjRsiPoQYZXnMJSlmghzJ0BuYBEAiSp/Wi
eRd2GCHKw6yRWLtK7I8Nv91whnR7h+56TGPfqEE+hgvgwqIQ+9XlHntxyMlS6lRe
OyQm/EYIY0eOsoMQV9AV6CvNNTBRX9VjEukf11OPnHqFqZ3s9zHU9nzKEAcS1O1X
tMeWzamL9568lqNaFyx4nmcv3nZTD0w4vRuYe69uatTSCw0D9Pdxfn4pp2HdBMQr
NrHkDxnBDnHyKQ9gn2+zUhqPvbHC3/8Z7qHJ4AL/fx9bjWMRDFJe++shPUKcohcK
HLdm6YdiwvJxbU4TVJAL+FJ1uVl+dIpM+tJlV+yJNstvlsLaFDxvh4CyudxSeXEd
kdaoPZvJ7Z9uDZA4dsqtRgBozkH9EmhVqfkFH8Lr6DxPoxibDRBXpS26FiPJFJWi
wPpGvFh0BDsZUeTwvhW+bPNt0ZCMauFLBlHMp04o6Z4cpJAkLqll5w6dC9U65oDM
GAbQMvjte2ablQgBK2PxN2SJRztnzraNhS6JqDjEK85GsNkUwLSD49ViL7nkI3t9
nzB1cJiHwxOdPHPMlI0Db/UCaNpzmv97kbdUU9+sVgPImL4eBKE=
=FmHo
-END PGP SIGNATURE-



Re: How to deal with non-functional package in stretch? (Was: Bug#897605: profphd failure in stretch)

2018-05-04 Thread Emilio Pozuelo Monfort
Hi Andreas,

On 04/05/18 09:27, Andreas Tille wrote:
> Hi release team,
> 
> it turned out that profphd is non-functional in stretch (see bug
> #897605).  Since its not obviously a security issue we are wondering
> whether there is some way to integrate this admittedly low popcon
> package into Debian 9.5 (whenever this might be released).

If it is non functional, shouldn't the severity be adjusted?

Sorry, I don't have the time to go through all the bug log. But yes, there is a
procedure to update packages in stable, it's called a stable update. Please file
a stable-pu bug with `reportbug release.debian.org' and attach a debdiff built
and tested against stretch.

Thanks,
Emilio



Re: How to deal with non-functional package in stretch? (Was: Bug#897605: profphd failure in stretch)

2018-05-04 Thread merlettaia
Hi All,

This is fixed in version 1.0.42-2, and not present in version 1.0.42-1,
which seems to be latest in stretch (both with tests).
At patches dir:

  https://salsa.debian.org/med-team/profphd/blob/master/
debian/patches/2_remove_perlbrew_usage.patch
- this disables perlbrew usage (this was temporary, it would be wiser to
replace this patch with the one which removes if-then-statement completely,
because this "temporary" fix just confuses and intricates code logic in
long-term perspective),

  https://salsa.debian.org/med-team/profphd/blob/master/
debian/patches/3_fix_indexing.patch - and as far as I remember this fixes
actual erratic behavior with latest versions of perl, which was the reason
why that if-then-else statement appeared in profphd code (the main problem
here is the "$["-magic in perl).

Other patches fix error or warning messages, which appeared in almost all
rostlab packages and were not as tricky as this one.

P.S. - I could work on fixing this bug late at the evening or tomorrow,
because at this moment I have no Debian distribution or VM somewhere
nearby, and I could check that everything works after I come home. In case
if Liubov has time for solving this before that and she is not working on
something else I've added her to CC.

2018-05-04 10:27 GMT+03:00 Andreas Tille :

> Hi release team,
>
> it turned out that profphd is non-functional in stretch (see bug
> #897605).  Since its not obviously a security issue we are wondering
> whether there is some way to integrate this admittedly low popcon
> package into Debian 9.5 (whenever this might be released).
>
> While we can certainly do a backport not all users will realise / profit
> from this.
>
> On Fri, May 04, 2018 at 04:01:48AM +, olivier sallou wrote:
> > Le jeu. 3 mai 2018 21:55, Andreas Tille  a écrit :
> >
> > > On Thu, May 03, 2018 at 02:58:58PM +, olivier sallou wrote:
> > > >
> > > > newer version in sid (1.0.42-2) added a patch to allow new perl
> release.
> > > A
> > > > quick test on sid works (at least no error, just calling program
> with no
> > > > argument), so maybe backporting this release would do the job
> > >
> > > Ahhh, right - I remember that Tatiana had to do some heavy patching.
> > >
> > > > > We definitely need some CI test for this package obviously.
> > >
> > > That was also done by Tatiana.
> > >
> > > However, a backport does not really close a bug in stretch and the
> issue
> > > is also not really a security issue, right?
> > >
> >
> > This is indeed not a security issue, but package is unusable. Backport
> > would at least make software available.
> > I don't know know what is usual debian policy regarding this use case. I
> > suppose it occured multiple times.
> >
> > I can't be sure that sid version is really working, it just does not show
> > any error. Could tatiana do some 'real' testing?
>
> As far as I understood Tatiana she did some effort to make the program
> functional.  She has done some real life tests.
>
> Kind regards
>
> Andreas.
>
> --
> http://fam-tille.de
>



-- 
Best wishes,
Tanya.


Bug#897772: transition: miniupnpc

2018-05-04 Thread Emilio Pozuelo Monfort
Control: tags -1 confirmed

On 04/05/18 14:24, Thomas Goirand wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi there!
> 
> We've uploaded miniupnpc to Experimental, and my sponsoree said he attempted
> a rebuild against all the reverse dependencies listed here:
> https://release.debian.org/transitions/html/auto-miniupnpc.html
> 
> There was no FTBFS problem, so we would like to upload miniupnpc 
> 2.0.20180410-2
> to unstable ASAP. Please let me know when I can upload.

Go ahead.

I will schedule the binNMUs when miniupnpc is built everywhere.

Cheers,
Emilio



Processed: Re: Bug#897772: transition: miniupnpc

2018-05-04 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 confirmed
Bug #897772 [release.debian.org] transition: miniupnpc
Added tag(s) confirmed.

-- 
897772: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897772
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#897772: transition: miniupnpc

2018-05-04 Thread Thomas Goirand
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi there!

We've uploaded miniupnpc to Experimental, and my sponsoree said he attempted
a rebuild against all the reverse dependencies listed here:
https://release.debian.org/transitions/html/auto-miniupnpc.html

There was no FTBFS problem, so we would like to upload miniupnpc 2.0.20180410-2
to unstable ASAP. Please let me know when I can upload.

Ben file:

title = "miniupnpc";
is_affected = .depends ~ "libminiupnpc16" | .depends ~ "libminiupnpc17";
is_good = .depends ~ "libminiupnpc17";
is_bad = .depends ~ "libminiupnpc16";


-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Processed: tagging 897613

2018-05-04 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> # info provided
> tags 897613 - moreinfo
Bug #897613 [release.debian.org] RM: redmine/3.0~20140825-8~deb8u4
Removed tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
897613: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897613
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#897682: nmu: med-fichier_3.0.6-12+b1

2018-05-04 Thread Alastair McKinstry
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

There were problems in med-fichier with the usage of an internal version of 
pmix by openmpi3.
This has been resolved by making pmix work for all architectures
(as of pmix 2.1.1~rc1-4,  openmpi 3.0.1.real-3). So, med-fichier needs to be 
rebuilt using these.

nmu med-fichier_3.0.6-12+b1 . hppa armhf i386 kfreebsd-i386 kfreebsd-amd64 
powerpc riscv64 x32 . unstable . -m "Rebuild for openmpi3, pmix fix"

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-6-686-pae (SMP w/1 CPU core)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_IE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#897681: nmu: lammps_0~20161109.git9806da6-7+b1

2018-05-04 Thread Alastair McKinstry
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

There were problems in lammps with the usage of an internal version of pmix by 
openmpi3.
This has been resolved by making pmix work for all architectures
(as of pmix 2.1.1~rc1-4,  openmpi 3.0.1.real-3). So, lammps needs to be rebuilt 
using these.

nmu lammps_0~20161109.git9806da6-7+b1 . sh4 x32 riscv64 powerpcspe m68k 
hurd-i386 powerpc kfreebsd-i386 kfreebsd-amd64 . unstable . -m "Rebuild for 
openmpi3, pmix fix"

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-6-686-pae (SMP w/1 CPU core)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_IE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#897613: RM: redmine/3.0~20140825-8~deb8u4

2018-05-04 Thread Sébastien Delafond
On May/03, Adam D. Barratt wrote:
> There's a few r-deps. Walking the tree gives us:
> 
> - redmine-plugin-pretend
> - redmine-plugin-recaptcha
> - redmine-recaptcha
> 
> I assume the intent is that those also be removed.

That is correct, sorry for not mentioning the r-deps initially.

Cheers,

--Seb



Bug#897680: nmu: p4est_1.1-5+b1

2018-05-04 Thread Alastair McKinstry
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

There were problems in p4est with the usage of an internal version of pmix by 
openmpi3.
This has been resolved by making pmix work for all architectures
(as of pmix 2.1.1~rc1-4,  openmpi 3.0.1.real-3). So, p4est needs to be rebuilt 
using these.

nmu p4est_1.1-5+b1 . ANY . unstable . -m "rebuild for openmpi3, pmix"

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-6-686-pae (SMP w/1 CPU core)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_IE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



How to deal with non-functional package in stretch? (Was: Bug#897605: profphd failure in stretch)

2018-05-04 Thread Andreas Tille
Hi release team,

it turned out that profphd is non-functional in stretch (see bug
#897605).  Since its not obviously a security issue we are wondering
whether there is some way to integrate this admittedly low popcon
package into Debian 9.5 (whenever this might be released).

While we can certainly do a backport not all users will realise / profit
from this.

On Fri, May 04, 2018 at 04:01:48AM +, olivier sallou wrote:
> Le jeu. 3 mai 2018 21:55, Andreas Tille  a écrit :
> 
> > On Thu, May 03, 2018 at 02:58:58PM +, olivier sallou wrote:
> > >
> > > newer version in sid (1.0.42-2) added a patch to allow new perl release.
> > A
> > > quick test on sid works (at least no error, just calling program with no
> > > argument), so maybe backporting this release would do the job
> >
> > Ahhh, right - I remember that Tatiana had to do some heavy patching.
> >
> > > > We definitely need some CI test for this package obviously.
> >
> > That was also done by Tatiana.
> >
> > However, a backport does not really close a bug in stretch and the issue
> > is also not really a security issue, right?
> >
> 
> This is indeed not a security issue, but package is unusable. Backport
> would at least make software available.
> I don't know know what is usual debian policy regarding this use case. I
> suppose it occured multiple times.
> 
> I can't be sure that sid version is really working, it just does not show
> any error. Could tatiana do some 'real' testing?

As far as I understood Tatiana she did some effort to make the program
functional.  She has done some real life tests.

Kind regards

Andreas.

-- 
http://fam-tille.de