Bug#923999: unblock: lammps/0~20181211.gitad1b1897d+dfsg1-2

[Andreas Tille]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package lammps


diff -Nru lammps-0~20181211.gitad1b1897d+dfsg1/debian/changelog 
lammps-0~20181211.gitad1b1897d+dfsg1/debian/changelog
--- lammps-0~20181211.gitad1b1897d+dfsg1/debian/changelog   2018-12-20 
21:27:37.0 +0100
+++ lammps-0~20181211.gitad1b1897d+dfsg1/debian/changelog   2019-03-08 
07:18:57.0 +0100
@@ -1,3 +1,11 @@
+lammps (0~20181211.gitad1b1897d+dfsg1-2) unstable; urgency=medium
+
+  * Team upload.
+  * Build-Depends: gfortran
+Closes: #923466
+
+ -- Andreas Tille   Fri, 08 Mar 2019 07:18:57 +0100
+
 lammps (0~20181211.gitad1b1897d+dfsg1-1) unstable; urgency=medium

   * [63546ae] Fix typo in d/copyright
diff -Nru lammps-0~20181211.gitad1b1897d+dfsg1/debian/control 
lammps-0~20181211.gitad1b1897d+dfsg1/debian/control
--- lammps-0~20181211.gitad1b1897d+dfsg1/debian/control 2018-12-20 
19:30:47.0 +0100
+++ lammps-0~20181211.gitad1b1897d+dfsg1/debian/control 2019-03-08 
07:18:57.0 +0100
@@ -6,7 +6,7 @@
 Build-Depends: debhelper (>= 11~),
libeigen3-dev,
cmake,
-   fortran-compiler,
+   gfortran | fortran-compiler,
libfftw3-dev,
libjpeg-dev,
mpi-default-bin,



unblock lammps/0~20181211.gitad1b1897d+dfsg1-2

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Processed: tagging 923548

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 923548 - moreinfo
Bug #923548 [release.debian.org] unblock: postfix/3.4.0-2
Removed tag(s) moreinfo.
> thanks
Stopping processing here.

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

Bug#923548: unblock: postfix/3.4.1-1

[Scott Kitterman]

On Wednesday, March 06, 2019 07:39:07 PM Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
> 
> On Fri, Mar 01, 2019 at 02:46:41PM -0500, Scott Kitterman wrote:
> > Given the outstanding track record this upstream has for delivering
> > mature,
> > well tested code I believe this change is appropriate for this stage of
> > the
> > release cycle given the benefits it will provide, but it is definitely not
> > minor, so I'd like release team feedback before uploading to unstable.
> 
> I agree. Please go ahead and remove moreinfo when it is ready to be
> unblocked.
> 
> Thanks.

Built on all release archs, so I think it's ready to be unblocked.  moreinfo 
tag removed.  Please:

unblock postfix/3.4.1-1

Scott K

Re: python-scipy: autopkgtest fails (Re: bug#919929)

[Drew Parsons]

On 2019-03-07 20:46, Paul Gevers wrote:


If you upload now, your package will not migrate to testing before the
full freeze becomes effective so it would need an unblock. If you want
to fix this issue with the three lines I saw in the bug report, you can
go ahead. However, it is probably worth waiting for a resolution of bug
915738 and combine it with that.



Alas, the deprecation patch (in python-scipy 1.1.0-3) doesn't actually 
prevent emission of the deprecation warnings, so they're still spamming 
the debci log.  On the bright side, s390x is now using gfortran-8 
successfully (#915738).


To remove the deprecation warnings we'd need to deal with them at the 
source. Upstream has patches

https://github.com/scipy/scipy/commit/614847c5fc8d5f8a618980df3c1b93540428ae46
https://github.com/scipy/scipy/commit/e0cfa29e2fbe86f994924c0c7514ff5bbfffd514
and for completeness
https://github.com/scipy/scipy/commit/87e48c3c54d7a85bc6628c88c1de98ac0469b6fa

The deprecation problem (matrix API) appears in many places, but the fix 
is straightfoward: replace np.matrix with matrix from from 
scipy.sparse.sputils


Can you authorise an unblock to apply these 3 upstream patches to 
python-scipy 1.1.0 ?
That won't necessarily fix the debci failure, but it will make it a lot 
easier to see what's actually failing.


Drew

Bug#855811: release.debian.org: release.d.o WWW should explicitly recommend against uploading to sid during the freeze

[Sean Whitton]

Hello Paul,

On Thu 07 Mar 2019 at 09:37PM +01, Paul Gevers wrote:

> On Tue, 21 Feb 2017 15:04:39 -0700 Sean Whitton
>  wrote:
>> I'd like to suggest that this recommendation be stated explicitly on the
>> release team's website, to reduce the number of blocking uploads to
>> unstable made during the freeze.
>
> Is the current text good enough for this purpose?
> """
> We strongly prefer changes that can be done via unstable instead of
> testing-proposed-updates. If there are unrelated changes in unstable,
> you should consider reverting these instead of making an upload to
> testing-proposed-updates.
> """

No, I don't think so.  You have to think moderately hard to infer, "oh,
stop uploading to sid" from that text.  I would suggest appending
"I.e. only upload to sid changes for which you plan to request an unblock."

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#923989: unblock: python-dmidecode/3.12.2-8

[Sandro Tosi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package python-dmidecode

This upload fix the poor handling of the dir-to-symlink transition for the doc
directories

unblock python-dmidecode/3.12.2-8

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-dmidecode-3.12.2/debian/changelog 
python-dmidecode-3.12.2/debian/changelog
--- python-dmidecode-3.12.2/debian/changelog2019-01-28 23:09:03.0 
-0500
+++ python-dmidecode-3.12.2/debian/changelog2019-03-07 17:51:40.0 
-0500
@@ -1,3 +1,12 @@
+python-dmidecode (3.12.2-8) unstable; urgency=medium
+
+  * debian/rules
+- remove doc/ directories, to actually use dir_to_symlink; Closes: #919442
+  * debian/*.maintscript
+- use prior-of tag at the end of the command-line
+
+ -- Sandro Tosi   Thu, 07 Mar 2019 17:51:40 -0500
+
 python-dmidecode (3.12.2-7) unstable; urgency=medium
 
   * debian/*.maintscript
diff -Nru python-dmidecode-3.12.2/debian/python3-dmidecode-dbg.maintscript 
python-dmidecode-3.12.2/debian/python3-dmidecode-dbg.maintscript
--- python-dmidecode-3.12.2/debian/python3-dmidecode-dbg.maintscript
2019-01-28 23:09:03.0 -0500
+++ python-dmidecode-3.12.2/debian/python3-dmidecode-dbg.maintscript
2019-03-07 17:51:40.0 -0500
@@ -1 +1 @@
-dir_to_symlink /usr/share/doc/python3-dmidecode-dbg python3-dmidecode
+dir_to_symlink /usr/share/doc/python3-dmidecode-dbg python3-dmidecode 3.12.2-8~
diff -Nru python-dmidecode-3.12.2/debian/python-dmidecode-dbg.maintscript 
python-dmidecode-3.12.2/debian/python-dmidecode-dbg.maintscript
--- python-dmidecode-3.12.2/debian/python-dmidecode-dbg.maintscript 
2019-01-28 23:09:03.0 -0500
+++ python-dmidecode-3.12.2/debian/python-dmidecode-dbg.maintscript 
2019-03-07 17:51:40.0 -0500
@@ -1 +1 @@
-dir_to_symlink /usr/share/doc/python-dmidecode-dbg python-dmidecode
+dir_to_symlink /usr/share/doc/python-dmidecode-dbg python-dmidecode 3.12.2-8~
diff -Nru python-dmidecode-3.12.2/debian/rules 
python-dmidecode-3.12.2/debian/rules
--- python-dmidecode-3.12.2/debian/rules2019-01-28 23:09:03.0 
-0500
+++ python-dmidecode-3.12.2/debian/rules2019-03-07 17:51:40.0 
-0500
@@ -38,9 +38,12 @@
 endif
 
 override_dh_installdocs:
-   dh_installdocs -A README doc/AUTHORS doc/changelog doc/README.types 
doc/AUTHORS.upstream doc/README.upstream
dh_installdocs -p$(P2)-dbg --link-doc=$(P2)
dh_installdocs -p$(P3)-dbg --link-doc=$(P3)
+   dh_installdocs -p$(P2) README doc/AUTHORS doc/changelog 
doc/README.types doc/AUTHORS.upstream doc/README.upstream
+   dh_installdocs -p$(P3) README doc/AUTHORS doc/changelog 
doc/README.types doc/AUTHORS.upstream doc/README.upstream
+   mkdir -p $(CURDIR)/debian/$(P2)-data/usr/share/doc/
+   cp -r $(CURDIR)/debian/$(P2)/usr/share/doc/$(P2) 
$(CURDIR)/debian/$(P2)-data/usr/share/doc/$(P2)-data
 
 override_dh_strip:
 ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))

Re: Fixing stretch debian-installer on armhf

[Cyril Brulebois]

Vagrant Cascadian  (2019-03-07):
> If that's indeed the case, then that does seem like the best approach.
> Happy to test images to confirm.

Rebuilding the stretch debian-installer source package within stretch
should give you everything you need to test. Beware if you go for a
manual build instead (make under build/, with a specific target), as
you'd need to pass some extra variable (see debian/rules).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Fixing stretch debian-installer on armhf

[Cyril Brulebois]

Ben Hutchings  (2019-03-07):
> On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
> [...]
> > > * Rebuild the debian-installer images, pulling in updates from
> > >   stretch-updates, leaving only armhf netboot targets broken. 
> > 
> > Expanding a bit: rebuilding src:debian-installer from the stretch
> > branch, which has s-p-u enabled, would fetch the fixed kernel and a
> > couple of its udebs, at build time; the resulting netboot images
> > wouldn't know about s-p-u though at run time, and would try to load
> > udebs from stretch.
> [...]
> 
> Why is that a problem?  The only change made in 4.9.144-3.1 is in the
> kernel image, and the module udebs don't have versioned dependencies.

I had planned to clarify in this mail thread the limitations I was
mentioning in my early replies on IRC. I don't think I've said this
specific combination of kernel and udebs can't work. I hope people
knowledgeable about kernel and arm* stuff can figure out both what
theory (source code/packaging) and reality (tests on actual HW) look
like.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Fixing stretch debian-installer on armhf

[Vagrant Cascadian]

On 2019-03-07, Ben Hutchings wrote:
> On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
> [...]
>> > * Rebuild the debian-installer images, pulling in updates from
>> >   stretch-updates, leaving only armhf netboot targets broken. 
>> 
>> Expanding a bit: rebuilding src:debian-installer from the stretch
>> branch, which has s-p-u enabled, would fetch the fixed kernel and a
>> couple of its udebs, at build time; the resulting netboot images
>> wouldn't know about s-p-u though at run time, and would try to load
>> udebs from stretch.
> [...]
>
> Why is that a problem?  The only change made in 4.9.144-3.1 is in the
> kernel image, and the module udebs don't have versioned dependencies.

If that's indeed the case, then that does seem like the best
approach. Happy to test images to confirm.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Fixing stretch debian-installer on armhf

[Ben Hutchings]

On Thu, 2019-03-07 at 14:39 +0100, Cyril Brulebois wrote:
[...]
> > * Rebuild the debian-installer images, pulling in updates from
> >   stretch-updates, leaving only armhf netboot targets broken. 
> 
> Expanding a bit: rebuilding src:debian-installer from the stretch
> branch, which has s-p-u enabled, would fetch the fixed kernel and a
> couple of its udebs, at build time; the resulting netboot images
> wouldn't know about s-p-u though at run time, and would try to load
> udebs from stretch.
[...]

Why is that a problem?  The only change made in 4.9.144-3.1 is in the
kernel image, and the module udebs don't have versioned dependencies.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.




signature.asc
Description: This is a digitally signed message part

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: ansible_2.2.1.0-2+deb9u1_amd64.changes
  ACCEPT
Processing changes file: ikiwiki_3.20170111.1_source.changes
  ACCEPT
Processing changes file: ikiwiki_3.20170111.1_all.changes
  ACCEPT
Processing changes file: ldb_1.1.27-1+deb9u1_amd64.changes
  ACCEPT
Processing changes file: ldb_1.1.27-1+deb9u1_arm64.changes
  ACCEPT
Processing changes file: ldb_1.1.27-1+deb9u1_armel.changes
  ACCEPT
Processing changes file: ldb_1.1.27-1+deb9u1_armhf.changes
  ACCEPT
Processing changes file: ldb_1.1.27-1+deb9u1_i386.changes
  ACCEPT
Processing changes file: ldb_1.1.27-1+deb9u1_mips.changes
  ACCEPT
Processing changes file: ldb_1.1.27-1+deb9u1_mips64el.changes
  ACCEPT
Processing changes file: ldb_1.1.27-1+deb9u1_mipsel.changes
  ACCEPT
Processing changes file: ldb_1.1.27-1+deb9u1_ppc64el.changes
  ACCEPT
Processing changes file: ldb_1.1.27-1+deb9u1_s390x.changes
  ACCEPT
Processing changes file: mumble_1.2.18-1+deb9u1_source.changes
  ACCEPT
Processing changes file: mumble_1.2.18-1+deb9u1_amd64.changes
  ACCEPT
Processing changes file: mumble_1.2.18-1+deb9u1_arm64.changes
  ACCEPT
Processing changes file: mumble_1.2.18-1+deb9u1_armel.changes
  ACCEPT
Processing changes file: mumble_1.2.18-1+deb9u1_armhf.changes
  ACCEPT
Processing changes file: mumble_1.2.18-1+deb9u1_i386.changes
  ACCEPT
Processing changes file: mumble_1.2.18-1+deb9u1_mips.changes
  ACCEPT
Processing changes file: mumble_1.2.18-1+deb9u1_mips64el.changes
  ACCEPT
Processing changes file: mumble_1.2.18-1+deb9u1_mipsel.changes
  ACCEPT
Processing changes file: mumble_1.2.18-1+deb9u1_ppc64el.changes
  ACCEPT
Processing changes file: mumble_1.2.18-1+deb9u1_s390x.changes
  ACCEPT
Processing changes file: openssh_7.4p1-10+deb9u6_sourceonly.changes
  ACCEPT
Processing changes file: openssh_7.4p1-10+deb9u6_all.changes
  ACCEPT
Processing changes file: openssh_7.4p1-10+deb9u6_amd64.changes
  ACCEPT
Processing changes file: openssh_7.4p1-10+deb9u6_arm64.changes
  ACCEPT
Processing changes file: openssh_7.4p1-10+deb9u6_armel.changes
  ACCEPT
Processing changes file: openssh_7.4p1-10+deb9u6_armhf.changes
  ACCEPT
Processing changes file: openssh_7.4p1-10+deb9u6_i386.changes
  ACCEPT
Processing changes file: openssh_7.4p1-10+deb9u6_mips.changes
  ACCEPT
Processing changes file: openssh_7.4p1-10+deb9u6_mips64el.changes
  ACCEPT
Processing changes file: openssh_7.4p1-10+deb9u6_mipsel.changes
  ACCEPT
Processing changes file: openssh_7.4p1-10+deb9u6_ppc64el.changes
  ACCEPT
Processing changes file: openssh_7.4p1-10+deb9u6_s390x.changes
  ACCEPT
Processing changes file: openssl1.0_1.0.2r-1~deb9u1_source.changes
  ACCEPT
Processing changes file: openssl1.0_1.0.2r-1~deb9u1_amd64.changes
  ACCEPT
Processing changes file: openssl1.0_1.0.2r-1~deb9u1_arm64.changes
  ACCEPT
Processing changes file: openssl1.0_1.0.2r-1~deb9u1_armel.changes
  ACCEPT
Processing changes file: openssl1.0_1.0.2r-1~deb9u1_armhf.changes
  ACCEPT
Processing changes file: openssl1.0_1.0.2r-1~deb9u1_i386.changes
  ACCEPT
Processing changes file: openssl1.0_1.0.2r-1~deb9u1_mips.changes
  ACCEPT
Processing changes file: openssl1.0_1.0.2r-1~deb9u1_mips64el.changes
  ACCEPT
Processing changes file: openssl1.0_1.0.2r-1~deb9u1_mipsel.changes
  ACCEPT
Processing changes file: openssl1.0_1.0.2r-1~deb9u1_ppc64el.changes
  ACCEPT
Processing changes file: openssl1.0_1.0.2r-1~deb9u1_s390x.changes
  ACCEPT
Processing changes file: php7.0_7.0.33-0+deb9u2_amd64.changes
  ACCEPT
Processing changes file: php7.0_7.0.33-0+deb9u2_arm64.changes
  ACCEPT
Processing changes file: php7.0_7.0.33-0+deb9u2_armel.changes
  ACCEPT
Processing changes file: php7.0_7.0.33-0+deb9u2_armhf.changes
  ACCEPT
Processing changes file: php7.0_7.0.33-0+deb9u2_i386.changes
  ACCEPT
Processing changes file: php7.0_7.0.33-0+deb9u2_mips.changes
  ACCEPT
Processing changes file: php7.0_7.0.33-0+deb9u2_mips64el.changes
  ACCEPT
Processing changes file: php7.0_7.0.33-0+deb9u2_mipsel.changes
  ACCEPT
Processing changes file: php7.0_7.0.33-0+deb9u2_ppc64el.changes
  ACCEPT
Processing changes file: php7.0_7.0.33-0+deb9u2_s390x.changes
  ACCEPT
Processing changes file: rdesktop_1.8.4-1~deb9u1_amd64.changes
  ACCEPT
Processing changes file: rdesktop_1.8.4-1~deb9u1_arm64.changes
  ACCEPT
Processing changes file: rdesktop_1.8.4-1~deb9u1_armel.changes
  ACCEPT
Processing changes file: rdesktop_1.8.4-1~deb9u1_armhf.changes
  ACCEPT
Processing changes file: rdesktop_1.8.4-1~deb9u1_i386.changes
  ACCEPT
Processing changes file: rdesktop_1.8.4-1~deb9u1_mips.changes
  ACCEPT
Processing changes file: rdesktop_1.8.4-1~deb9u1_mips64el.changes
  ACCEPT
Processing changes file: rdesktop_1.8.4-1~deb9u1_mipsel.changes
  ACCEPT
Processing changes file: rdesktop_1.8.4-1~deb9u1_ppc64el.changes
  ACCEPT
Processing changes file: rdesktop_1.8.4-1~deb9u1_s390x.changes
  ACCEPT
Processing changes file: rssh_2.3.4-5+deb9u4_amd64.changes
  ACCEPT
Processing changes file: rssh_2.3.4-5+deb9u4_arm64.changes
  ACCEPT
Processing changes file: 

Bug#923978: unblock: refcard/10.4

[Holger Wansing]

Package: release.debian.org
Usertags: unblock


I would like to request an unblock for version 10.4 of the Debian
reference card (source package 'refcard'). 
I have just uploaded the 10.4 version to unstable.

The changings include updates of the Finnish, Italian and Japanese translations
and a refresh of the publication date.

The debdiff is attached.


Thanks
Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076


refcard-10.4.debdiff
Description: Binary data

Bug#855811: release.debian.org: release.d.o WWW should explicitly recommend against uploading to sid during the freeze

[Paul Gevers]

Hi Sean,

Sorry it took so long to get a reply.

On Tue, 21 Feb 2017 15:04:39 -0700 Sean Whitton
 wrote:
> I'd like to suggest that this recommendation be stated explicitly on the
> release team's website, to reduce the number of blocking uploads to
> unstable made during the freeze.

Is the current text good enough for this purpose?
"""
We strongly prefer changes that can be done via unstable instead of
testing-proposed-updates. If there are unrelated changes in unstable,
you should consider reverting these instead of making an upload to
testing-proposed-updates.
"""

Paul



signature.asc
Description: OpenPGP digital signature

Bug#219978: marked as done ([britney] main being self-contained not ensured)

[Debian Bug Tracking System]

Your message dated Thu, 7 Mar 2019 21:26:58 +0100
with message-id <3d832409-b18d-0186-55dc-91e3e6b0b...@debian.org>
and subject line Re: ftp.debian.org: britney doesn't ensure main being 
self-contained
has caused the Debian Bug report #219978,
regarding [britney] main being self-contained not ensured
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
219978: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=219978
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: ftp.debian.org
Severity: important

Hi aj,

For example:

$ grep-excuses openoffice.org-help-de
openoffice.org-help-de (1.1+20030814-1 to 1.1+20030814-2)
Maintainer: Debian OpenOffice Team
Too young, only 9 of 10 days old
Not considered

$ grep-excuses openoffice.org
$ grep-excuses openoffice.org
openoffice.org (1.1.0-1 to 1.1.0-2)
Maintainer: Debian OpenOffice Team
Too young, only 9 of 10 days old
openoffice.org/alpha unsatisfiable Depends: openoffice.org-bin (>> 1.1.0)
openoffice.org/arm unsatisfiable Depends: openoffice.org-bin (>> 1.1.0)
openoffice.org/hppa unsatisfiable Depends: openoffice.org-bin (>> 1.1.0)
openoffice.org/ia64 unsatisfiable Depends: openoffice.org-bin (>> 1.1.0)
openoffice.org/m68k unsatisfiable Depends: openoffice.org-bin (>> 1.1.0)
openoffice.org/mips unsatisfiable Depends: openoffice.org-bin (>> 1.1.0)
openoffice.org/mipsel unsatisfiable Depends: openoffice.org-bin (>> 1.1.0)
openoffice.org (source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, 
powerpc, s390, sparc) is buggy! (1 > 0)
Not considered
Depends: openoffice.org glibc (not considered)

OK, so what AFAIS is going to happen is that -help-de goes into testing
tomorrow but openoffice.org not because of glibc (the RC bugs is
downgraded now). So we have openoffice.org-help-* packages and
openoffice.org-debian-files not being installable when you only look
at main since they depend on openoffice.org which then is still in
contrib unless the new version enters testing..

And those packages above _have_ a versioned dependency on
openoffice.org...

Not good...

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux frodo 2.4.21-rene #3 Mit Aug 6 17:21:44 CEST 2003 i686
Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73
  


signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
Hi Rene,

Sorry it took so long to respond to this bug. Apparently nobody from the
release team noticed that this bug was assigned to them and cared to reply.

On Mon, 10 Nov 2003 15:35:44 +0100 Rene Engelhard  wrote:
> OK, so what AFAIS is going to happen is that -help-de goes into testing
> tomorrow but openoffice.org not because of glibc (the RC bugs is
> downgraded now). So we have openoffice.org-help-* packages and
> openoffice.org-debian-files not being installable when you only look
> at main since they depend on openoffice.org which then is still in
> contrib unless the new version enters testing..
> 
> And those packages above _have_ a versioned dependency on
> openoffice.org...
> 
> Not good...

I really wonder if that ever happened. As you can read in the britney
documentation [1], the excuses are only reporting the results of phase
1. I believe that phase 2 would be blocking the migration. Do you agree
with me that I close this bug report?

Paul

[1] https://release.debian.org/doc/britney/short-intro-to-migrations.html



signature.asc
Description: OpenPGP digital signature
--- End Message ---

Bug#903308: marked as done (RM: nslu2-utils/20080403-4)

[Debian Bug Tracking System]

Your message dated Thu, 7 Mar 2019 21:04:58 +0100
with message-id 
and subject line Re: RM: nslu2-utils/20080403-4
has caused the Debian Bug report #903308,
regarding RM: nslu2-utils/20080403-4
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
903308: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903308
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

nslu2-utils was removed from unstable last year:
  https://bugs.debian.org/869430
but for some reason it is still present in buster.

anbe@coccia:~$ dak rm -Rn -s buster nslu2-utils
Will remove the following packages from buster:

nslu2-utils | 20080403-4 | source, armel

Maintainer: Joey Hess 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


Andreas
--- End Message ---
--- Begin Message ---
On Sun, 08 Jul 2018 19:15:13 +0200 Andreas Beckmann  wrote:
> nslu2-utils was removed from unstable last year:
>   https://bugs.debian.org/869430
> but for some reason it is still present in buster.

Not anymore, so closing this bug.

Paul



signature.asc
Description: OpenPGP digital signature
--- End Message ---

Processed: retitle 145257 [britney] build-depends not taken into consideration for arch:all packages

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 145257 [britney] build-depends not taken into consideration for 
> arch:all packages
Bug #145257 [release.debian.org] [britney] build-depends not taken into 
consideration
Bug #184812 [release.debian.org] [britney] dephelper version ignored
Bug #599848 [release.debian.org] testing is not checked for unsatisfied build 
dependencies
Bug #916884 [release.debian.org] [britney2] Does not consider B-D for migration 
to testing
Changed Bug title to '[britney] build-depends not taken into consideration for 
arch:all packages' from '[britney] build-depends not taken into consideration'.
Changed Bug title to '[britney] build-depends not taken into consideration for 
arch:all packages' from '[britney] dephelper version ignored'.
Changed Bug title to '[britney] build-depends not taken into consideration for 
arch:all packages' from 'testing is not checked for unsatisfied build 
dependencies'.
Changed Bug title to '[britney] build-depends not taken into consideration for 
arch:all packages' from '[britney2] Does not consider B-D for migration to 
testing'.
> thanks
Stopping processing here.

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

Bug#866878: marked as done (release.debian.org: should autopkgtest regressions be considered RC?)

[Debian Bug Tracking System]

Your message dated Thu, 7 Mar 2019 20:25:16 +0100
with message-id <001ed52f-41b7-4d58-b91a-4ff7e3cc1...@debian.org>
and subject line Re: Bug#866878: release.debian.org: should autopkgtest 
regressions be considered RC?
has caused the Debian Bug report #866878,
regarding release.debian.org: should autopkgtest regressions be considered RC?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
866878: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866878
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: wishlist

Dear Release Team

I recall some discussion from dc16 and I see a talk planned for dc17
[1] on using autopkgtest results for unstable to testing migration.
In other words, package uploads that cause autopkgtests to fail, where
those tests passed previously, should be prevented from migrating to
testing.  The regression can be in the uploaded package's own
autopkgtests, or in those of a reverse dependency.

Can a decision please be made, as to whether autopkgtest regressions
will be considered RC for buster, so that bugs of severity level
'serious' can be filed now?

Regards
Graham


[1] https://debconf17.debconf.org/talks/2/
--- End Message ---
--- Begin Message ---
On Mon, 15 Oct 2018 18:41:00 + Niels Thykier  wrote:

> An update on this:
>
> Per
> https://lists.debian.org/debian-devel-announce/2018/09/msg4.html,
> autopkgtest regressions will block migration to testing before (or no
> later than) the transition freeze.  Due to the slowly increasing
> delay, the regressions will effectively be RC several weeks before the
> transition freeze.

We are now blocking on regressions, so we are considering autopkgtest
regressions RC in principle (for the package of the version in unstable
that causes the regression). However, there are subtleties that need to
be taken into account:

1) regressions caused by too sensitive tests (e.g. failing on
deprecation warnings) or tests that just need to be updated to updated
behavior (e.g. tests that record stdout or stderr and check verbatim
against a reference) are not RC for the package causing the regression.
But in general we prefer those tests to be updated before the causing
package migrates.

2) when autopkgtest starts to regress due to a bug *fix*, i.e. where the
tested package relies on the former, buggy, behavior, it depends on the
situation what needs to be fixed. Normally the tested package should be
updated (and given reasonable time to do so), but of course there are
exceptions to that rule. Of course, if it's not the package, but only
the autopkgtest that relies on the buggy behavior, its the autopkgtest
that needs to be fixed.

3) the Debian setup to test for regressions naturally has limitations.
The setup may not be blocking the package that really causes the
regression. E.g. the test may be installing other packages (direct or
indirect (test) dependencies) from unstable that are really responsible
for the regression. The package will be blocked from migration, but the
RC issue is not against the package.

4) once a regression "migrates" to testing, there is no regression
anymore per definition. So even when a package causes another package's
autopkgtest to fail where it succeeded in the past, the mere fact that
the autopkgtest fails is not RC. Maybe (some time after the release of
buster) failing autopkgtest (in testing) will be an RC bug on its own,
but not yet.

5) ... [I don't pretend being complete in my listing of subtleties.]

Of course, in order to have the package migrate to testing that causes
or seems to cause the regression, manual action is required.

Paul



signature.asc
Description: OpenPGP digital signature
--- End Message ---

Processed: Re: Bug#923771: unblock: pandas/0.23.3+dfsg-3

[Debian Bug Tracking System]

Processing control commands:

> tags -1 - moreinfo
Bug #923771 [release.debian.org] unblock pre-approval: pandas/0.23.3+dfsg-3
Removed tag(s) moreinfo.

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

Bug#923771: unblock: pandas/0.23.3+dfsg-3

[Rebecca N. Palmer]

Control: tags -1 - moreinfo

Built on every release architecture, autopkgtest good.

As discussed, please also give back statsmodels, as the new pandas 
should allow it to build.

Bug#923966: unblock: libncl/2.1.21+git20180827.c71b264-2

[Andreas Tille]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libncl


 libncl (2.1.21+git20180827.c71b264-2) unstable; urgency=medium
 .
   * Rebuild for new version of gcc to fix symbols
 Closes: #923955
   * Standards-Version: 4.3.0



unblock libncl/2.1.21+git20180827.c71b264-2

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libncl-2.1.21+git20180827.c71b264/debian/changelog 
libncl-2.1.21+git20180827.c71b264/debian/changelog
--- libncl-2.1.21+git20180827.c71b264/debian/changelog  2018-12-04 
19:10:38.0 +0100
+++ libncl-2.1.21+git20180827.c71b264/debian/changelog  2019-03-07 
19:13:02.0 +0100
@@ -1,3 +1,11 @@
+libncl (2.1.21+git20180827.c71b264-2) unstable; urgency=medium
+
+  * Rebuild for new version of gcc to fix symbols
+Closes: #923955
+  * Standards-Version: 4.3.0
+
+ -- Andreas Tille   Thu, 07 Mar 2019 19:13:02 +0100
+
 libncl (2.1.21+git20180827.c71b264-1) unstable; urgency=medium
 
   * Update symbols
diff -Nru libncl-2.1.21+git20180827.c71b264/debian/control 
libncl-2.1.21+git20180827.c71b264/debian/control
--- libncl-2.1.21+git20180827.c71b264/debian/control2018-12-04 
19:10:38.0 +0100
+++ libncl-2.1.21+git20180827.c71b264/debian/control2019-03-07 
19:13:02.0 +0100
@@ -6,7 +6,7 @@
 Build-Depends: debhelper (>= 11~),
d-shlibs,
python
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/med-team/libncl
 Vcs-Git: https://salsa.debian.org/med-team/libncl.git
 Homepage: https://github.com/mtholder/ncl
diff -Nru libncl-2.1.21+git20180827.c71b264/debian/libncl2.symbols.amd64 
libncl-2.1.21+git20180827.c71b264/debian/libncl2.symbols.amd64
--- libncl-2.1.21+git20180827.c71b264/debian/libncl2.symbols.amd64  
2018-12-04 19:10:38.0 +0100
+++ libncl-2.1.21+git20180827.c71b264/debian/libncl2.symbols.amd64  
2019-03-07 19:13:02.0 +0100
@@ -852,7 +852,6 @@
  _ZNK24NxsTransformationManager7IsEmptyEv@Base 2.1.18
  
_ZNK24NxsTransformationManager9IsIntTypeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.1.18
  _ZNK25NxsDiscreteDatatypeMapper10DebugPrintERSo@Base 2.1.18
- (optional)_ZNK25NxsDiscreteDatatypeMapper13FirstIsSubsetEiib@Base 2.1.18
  _ZNK25NxsDiscreteDatatypeMapper13IsPolymorphicEi@Base 2.1.18
  _ZNK25NxsDiscreteDatatypeMapper17PositionInSymbolsEc@Base 2.1.18
  _ZNK25NxsDiscreteDatatypeMapper17ValidateStateCodeEi@Base 2.1.18
@@ -916,12 +915,11 @@
  _ZNK9NxsString9IsADoubleEv@Base 2.1.18
  _ZNKSt5ctypeIcE8do_widenEc@Base 2.1.18
  
_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE4findERKS5_@Base
 2.1.18
+ 
_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_16NxsIntStepMatrixESt10_Select1stIS9_ESt4lessIS5_ESaIS9_EE4findERS7_@Base
 2.1.21+git20180827.c71b264
  
(optional)_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_17NxsRealStepMatrixESt10_Select1stIS9_ESt4lessIS5_ESaIS9_EE4findERS7_@Base
 2.1.21+git20171002.4becff7
  
_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_NS0_4listIS6_IS5_St3setIjSt4lessIjESaIjEEESaISE_St10_Select1stISH_ESA_IS5_ESaISH_EE4findERS7_@Base
 2.1.18
  
_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_St6vectorIdSaIdEEESt10_Select1stISB_ESt4lessIS5_ESaISB_EE4findERS7_@Base
 2.1.18
  
(optional)_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_jESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE4findERS7_@Base
 2.1.21+git20171002.4becff7
- (optional)_ZNSt11_Deque_baseIjSaIjEED1Ev@Base 2.1.21+git20171002.4becff7
- (optional)_ZNSt11_Deque_baseIjSaIjEED2Ev@Base 2.1.21+git20171002.4becff7
  
_ZNSt11__copy_moveILb0ELb0ESt26random_access_iterator_tagE8__copy_mIPPKcSt20back_insert_iteratorISt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaISD_ET0_T_SI_SH_@Base
 2.1.18
  
_ZNSt12_Destroy_auxILb0EE9__destroyIPSt4pairI25NxsDiscreteDatatypeMapperSt3setIjSt4lessIjESaIjEvT_SB_@Base
 2.1.18
  _ZNSt13_Bvector_baseISaIbEE13_M_deallocateEv@Base 2.1.18
@@ -931,7 +929,6 @@
  
(optional)_ZNSt20__uninitialized_copyILb0EE13__uninit_copyIN9__gnu_cxx17__normal_iteratorIPKSt6vectorIiSaIiEES4_IS6_SaIS6_PS6_EET0_T_SE_SD_@Base
 2.1.18
  
_ZNSt20__uninitialized_copyILb0EE13__uninit_copyIPK9NxsStringPS2_EET0_T_S7_S6_@Base
 2.1.18
  
_ZNSt20__uninitialized_copyILb0EE13__uninit_copyIPKSt4pairI25NxsDiscreteDatatypeMapperSt3setIjSt4lessIjESaIjEEEPS9_EET0_T_SE_SD_@Base
 2.1.18
- 

Bug#923965: unblock: libbpp-seq/2.4.1-3

[Andreas Tille]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libbpp-seq


 libbpp-seq (2.4.1-3) unstable; urgency=medium
 .
   * Rebuild for new version of gcc to fix symbols
 Closes: #923954
   * Standards-Version: 4.3.0


unblock libbpp-seq/2.4.1-3

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libbpp-seq-2.4.1/debian/changelog libbpp-seq-2.4.1/debian/changelog
--- libbpp-seq-2.4.1/debian/changelog   2018-12-03 08:15:45.0 +0100
+++ libbpp-seq-2.4.1/debian/changelog   2019-03-07 18:56:16.0 +0100
@@ -1,3 +1,11 @@
+libbpp-seq (2.4.1-3) unstable; urgency=medium
+
+  * Rebuild for new version of gcc to fix symbols
+Closes: #923954
+  * Standards-Version: 4.3.0
+
+ -- Andreas Tille   Thu, 07 Mar 2019 18:56:16 +0100
+
 libbpp-seq (2.4.1-2) unstable; urgency=medium
 
   [ Jelmer Vernooij ]
diff -Nru libbpp-seq-2.4.1/debian/control libbpp-seq-2.4.1/debian/control
--- libbpp-seq-2.4.1/debian/control 2018-12-03 08:15:45.0 +0100
+++ libbpp-seq-2.4.1/debian/control 2019-03-07 18:56:16.0 +0100
@@ -8,7 +8,7 @@
cmake,
d-shlibs (>= 0.80),
libbpp-core-dev (>= 2.4.1)
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/med-team/libbpp-seq
 Vcs-Git: https://salsa.debian.org/med-team/libbpp-seq.git
 Homepage: http://biopp.univ-montp2.fr/wiki/index.php/Main_Page
diff -Nru libbpp-seq-2.4.1/debian/libbpp-seq12.symbols 
libbpp-seq-2.4.1/debian/libbpp-seq12.symbols
--- libbpp-seq-2.4.1/debian/libbpp-seq12.symbols2018-12-03 
08:15:45.0 +0100
+++ libbpp-seq-2.4.1/debian/libbpp-seq12.symbols2019-03-07 
18:56:16.0 +0100
@@ -328,7 +328,6 @@
  
_ZN3bpp16AbstractAlphabet8getStateERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 2.4.1
  _ZN3bpp16AbstractAlphabet8getStateEi@Base 2.4.1
  _ZN3bpp16AbstractAlphabet8setStateEmPNS_13AlphabetStateE@Base 2.4.1
- _ZN3bpp16AbstractAlphabetC2ERKS0_@Base 2.4.1
  _ZN3bpp16AbstractAlphabetD2Ev@Base 2.4.1
  _ZN3bpp16AbstractCoreSite11setPositionEi@Base 2.4.1
  
_ZN3bpp16ApplicationTools12getParameterIjEET_RKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt3mapIS8_S8_St4lessIS8_ESaISt4pairIS9_S8_EEES2_SA_bi@Base
 2.4.1
@@ -1710,13 +1709,13 @@
  _ZNKSt5ctypeIcE8do_widenEc@Base 2.4.1
  
_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE4findERS7_@Base
 2.4.1
  
_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_mESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE4findERS7_@Base
 2.4.1
+ 
_ZNSt11_Deque_baseINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED1Ev@Base
 2.4.1
+ 
_ZNSt11_Deque_baseINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED2Ev@Base
 2.4.1
  _ZNSt11_Deque_baseIiSaIiEE17_M_initialize_mapEm@Base 2.4.1
  _ZNSt11_Deque_baseIiSaIiEED1Ev@Base 2.4.1
  _ZNSt11_Deque_baseIiSaIiEED2Ev@Base 2.4.1
  _ZNSt13_Bvector_baseISaIbEE13_M_deallocateEv@Base 2.4.1
  
_ZNSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St4lessIS5_ESaISt4pairIKS5_S5_EEEixEOS5_@Base
 2.4.1
- 
_ZNSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St4lessIS5_ESaISt4pairIKS5_S5_EEEixERS9_@Base
 2.4.1
- 
_ZNSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt6vectorImSaImEESt4lessIS5_ESaISt4pairIKS5_S8_EEEixERSC_@Base
 2.4.1
  _ZNSt3mapIiiSt4lessIiESaISt4pairIKiiEEEixEOi@Base 2.4.1
  
_ZNSt5dequeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED1Ev@Base
 2.4.1
  
_ZNSt5dequeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED2Ev@Base
 2.4.1
@@ -1813,7 +1812,6 @@
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_PN3bpp8SequenceEESt10_Select1stISB_ESt4lessIS5_ESaISB_EE11equal_rangeERS7_@Base
 2.4.1
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_PN3bpp8SequenceEESt10_Select1stISB_ESt4lessIS5_ESaISB_EE12_M_erase_auxESt23_Rb_tree_const_iteratorISB_E@Base
 2.4.1
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_PN3bpp8SequenceEESt10_Select1stISB_ESt4lessIS5_ESaISB_EE14_M_insert_nodeEPSt18_Rb_tree_node_baseSJ_PSt13_Rb_tree_nodeISB_E@Base
 2.4.1
- 
(optional)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_PN3bpp8SequenceEESt10_Select1stISB_ESt4lessIS5_ESaISB_EE16_M_insert_uniqueIS6_IS5_SA_EEES6_ISt17_Rb_tree_iteratorISB_EbEOT_@Base
 2.4.1
  

Bug#923072: marked as done (RM: why -- ROM; Dependency why3 too new in unstable)

[Debian Bug Tracking System]

Your message dated Thu, 7 Mar 2019 19:08:01 +0100
with message-id <721db848-f126-23a4-7cae-8bf6925b5...@debian.org>
and subject line Re: Bug#923072: RM: why/2.40-3+b1 from testing
has caused the Debian Bug report #923072,
regarding RM: why -- ROM; Dependency why3 too new in unstable
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
923072: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923072
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Hi,

please remove src:why from testing.

why depends on why3. However, the version of why in testing, as well as
the newest version of why published by ustream, need a version of why3
<= 0/88.3 which is older than the version of why3 that we have in
testing or in unstable. This makes why unusable [1]. For this reason
I think that why should not be distributed with buster, please remove
it from testing.

The current why in testing delays the migration of coq and friends
(I hope we get one day all the blockers of coq out of the way!)

Thanks -Ralf.

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

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- End Message ---
--- Begin Message ---
On Sun, 24 Feb 2019 20:06:42 +0100 Paul Gevers  wrote:
> Ok. Will add the removal hint.

Which did its job.

Paul



signature.asc
Description: OpenPGP digital signature
--- End Message ---

Processed: Re: Bug#923953: Acknowledgement (unblock: giada/0.15.2+ds1-2)

[Debian Bug Tracking System]

Processing control commands:

> block -1 by 923952
Bug #923953 [release.debian.org] unblock: giada/0.15.2+ds1-2
923953 was not blocked by any bugs.
923953 was not blocking any bugs.
Added blocking bug(s) of 923953: 923952

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

Bug#923953: Acknowledgement (unblock: giada/0.15.2+ds1-2)

[Debian/GNU]

Control: block -1 by 923952
Thanks

Since giada currently has two causes for FTBFSing, unblocking this
package only makes sense if  juce/5.4.1+really5.4.1~repack-3 has been
unblocked before.

fgmasdr
IOhannes

Bug#923953: unblock: giada/0.15.2+ds1-2

[IOhannes m zmoelnig]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package giada

giada currently FTBFS due to an underlinking problem when building against
juce-modules-source/5.4.1+really5.4.1~repack-3 (currently in 'unstable' awaiting
an unblock as juce-modules-source/5.4.1+really5.4.1~repack-2 in 'testing' causes
another FTBFS of giada).

The patch is pretty simple (adding B-D on libcurl-dev and adding "-lcurl" to the
linker flags).

Thanks for considering

unblock giada/0.15.2+ds1-2

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru giada-0.15.2+ds1/debian/changelog giada-0.15.2+ds1/debian/changelog
--- giada-0.15.2+ds1/debian/changelog   2018-09-08 18:22:39.0 +0200
+++ giada-0.15.2+ds1/debian/changelog   2019-03-06 23:08:53.0 +0100
@@ -1,3 +1,9 @@
+giada (0.15.2+ds1-2) unstable; urgency=medium
+
+  * B-D and link against libcurl (Closes: #923898)
+
+ -- IOhannes m zmölnig (Debian/GNU)   Wed, 06 Mar 2019 
23:08:53 +0100
+
 giada (0.15.2+ds1-1) unstable; urgency=medium
 
   * New upstream version 0.15.2+ds1
diff -Nru giada-0.15.2+ds1/debian/control giada-0.15.2+ds1/debian/control
--- giada-0.15.2+ds1/debian/control 2018-09-08 18:22:39.0 +0200
+++ giada-0.15.2+ds1/debian/control 2019-03-06 23:08:53.0 +0100
@@ -11,6 +11,7 @@
  juce-modules-source,
  libasound2,
  libfltk1.3-dev,
+ libcurl4-gnutls-dev | libcurl-dev,
  libjack-dev,
  libjansson-dev,
  libpulse-dev,
diff -Nru giada-0.15.2+ds1/debian/rules giada-0.15.2+ds1/debian/rules
--- giada-0.15.2+ds1/debian/rules   2018-09-08 18:22:39.0 +0200
+++ giada-0.15.2+ds1/debian/rules   2019-03-06 23:08:53.0 +0100
@@ -14,7 +14,7 @@
 
 CPPFLAGS+=-DBUILD_DATE='"$(BUILD_DATE)"'
 CXXFLAGS+=-std=c++11 -Wno-error
-LIBS=$(shell pkg-config --libs libjpeg libpng)
+LIBS=$(shell pkg-config --libs libjpeg libpng libcurl)
 
 # JUCE (used by giada) uses some c++11 features requiring atomic_store_8 and
 # atomic_load_8, so we need to link with libatomic on

Bug#923952: unblock: juce/5.4.1+really5.4.1~repack-3

[IOhannes m zmoelnig]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package juce

The upload of JUCE-5.4.1 has introduced an FTBFS regression in the "giada"
package (0.13.2~dfsg1-1).
This upload fixes RC#923529, which will make "giada" build again
(well almost, there's an underlinking bug in giada's d/rules which causes
another FTBFS, for which i will do an unblock request as soon as giada has hit
the archives).

juce (or rather its binary package "juce-modules-source") is a development
package, which - unfortunately - has to be linked statically (and due to the
heavy use of templates there's no static library but instead build-rdependencies
compile the the required code into their binaries.
build-rdependencies use "Built-Using" to keep the required version of juce in
the archives. I would very much prefer if we only need to keep a single version
of juce for "buster".

There are currently only two reverse build-dependencies on juce (one being
"giada"), so the upload should have minimal impact on the rest of the archive.

Thanks for considering.
mfgards
IOhannes

unblock juce/5.4.1+really5.4.1~repack-3

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru juce-5.4.1+really5.4.1~repack/debian/changelog 
juce-5.4.1+really5.4.1~repack/debian/changelog
--- juce-5.4.1+really5.4.1~repack/debian/changelog  2019-01-13 
09:42:22.0 +0100
+++ juce-5.4.1+really5.4.1~repack/debian/changelog  2019-03-06 
19:22:02.0 +0100
@@ -1,3 +1,9 @@
+juce (5.4.1+really5.4.1~repack-3) unstable; urgency=medium
+
+  * Add more missing VST opcodes (Closes: #923529)
+
+ -- IOhannes m zmölnig (Debian/GNU)   Wed, 06 Mar 2019 
19:22:02 +0100
+
 juce (5.4.1+really5.4.1~repack-2) unstable; urgency=medium
 
   * Install VSTInterface.h for jor arch:all builds
diff -Nru 
juce-5.4.1+really5.4.1~repack/debian/extra/juce_audio_processors/format_types/juce_VSTInterface.h
 
juce-5.4.1+really5.4.1~repack/debian/extra/juce_audio_processors/format_types/juce_VSTInterface.h
--- 
juce-5.4.1+really5.4.1~repack/debian/extra/juce_audio_processors/format_types/juce_VSTInterface.h
   2019-01-13 09:42:22.0 +0100
+++ 
juce-5.4.1+really5.4.1~repack/debian/extra/juce_audio_processors/format_types/juce_VSTInterface.h
   2019-03-06 19:22:02.0 +0100
@@ -54,6 +54,8 @@
  #pragma pack(push, 8)
 #endif
 
+#define VSTCALLBACK VSTINTERFACECALL
+
 const int32 juceVstInterfaceVersion = 2400;
 #define kVstVersion 2400
 const int32 juceVstInterfaceIdentifier = 0x56737450;// The "magic" 
identifier in the SDK is 'VstP'.
@@ -246,6 +248,13 @@
 , effGetNumMidiInputChannels = pluginOpcodeGetNumMidiInputChannels
 , effGetNumMidiOutputChannels = pluginOpcodeGetNumMidiOutputChannels
 
+, effConnectInput = plugInOpcodeConnectInput
+, effConnectOutput = plugInOpcodeConnectOutput
+, effEditIdle = plugInOpcodeEditorIdle
+, effIdle = plugInOpcodeIdle
+, effShellGetNextPlugin = plugInOpcodeNextPlugInUniqueID
+, effStartProcess = plugInOpcodeStartProcess
+, effStopProcess = plugInOpcodeStopProcess
 };
 
 
@@ -309,6 +318,39 @@
 , audioMasterGetTime = hostOpcodeGetTimingInfo
 , audioMasterSizeWindow = hostOpcodeWindowSize
 , audioMasterVersion = hostOpcodeVstVersion
+
+, audioMasterCloseWindow = hostOpcodeCloseEditorWindow
+, audioMasterCurrentId = hostOpcodeCurrentId
+, audioMasterGetAutomationState = hostOpcodeGetAutomationState
+, audioMasterGetBlockSize = hostOpcodeGetBlockSize
+, audioMasterGetDirectory = hostOpcodeGetDirectory
+, audioMasterGetInputLatency = hostOpcodeGetInputLatency
+, audioMasterGetLanguage = hostOpcodeGetLanguage
+, audioMasterGetNextPlug = hostOpcodeGetNextPlugIn
+, audioMasterGetNumAutomatableParameters = 
hostOpcodeGetNumberOfAutomatableParameters
+, audioMasterGetOutputLatency = hostOpcodeGetOutputLatency
+, audioMasterGetOutputSpeakerArrangement = 
hostOpcodeGetOutputSpeakerConfiguration
+, audioMasterGetParameterQuantization = hostOpcodeGetParameterInterval
+, audioMasterGetPreviousPlug = hostOpcodeGetPreviousPlugIn
+, audioMasterGetProductString = hostOpcodeGetProductName
+, audioMasterGetSampleRate = hostOpcodeGetSampleRate
+, audioMasterGetVendorString = hostOpcodeGetManufacturerName
+, audioMasterGetVendorVersion = hostOpcodeGetManufacturerVersion
+, audioMasterIdle = hostOpcodeIdle
+, audioMasterNeedIdle = hostOpcodeNeedsIdle
+, 

Re: Advocating for unstable->testing flow

[Filippo Rusconi]

Greetings, Mattia and Release Managers,

On Thu, Mar 07, 2019 at 01:51:33PM +0100, Mattia Rizzolo wrote:

Hi,

On Thu, Mar 07, 2019 at 09:55:00AM +0100, Filippo Rusconi wrote:

Greetings, Fellow Debianites and Release Managers,

I would like to advocate for two pacakges to enter testing if no critical bugs
are found in them:


Please file a proper unblock bug for each of them, stating your case
there.
Mails in the mailing list are easily overlooked, and the regular process
asks for bugs anyway.


Understood, in fact I did that right after having sent the mail to the mailing
list. 


- isospec: a very small library for science;


This one is already in buster, and looking at the changelog I think it
should really be unblocked (using -march is a RC bug, you should
actually file one affecting the version in buster and fixed in
unstable…)


Done with a mail to cont...@bugs.debian.org.


- daps: an all-architecture package to build documentation;


Also for this package, have I made an unblock bug report.

Thank you for your attention and your work,

Sincerely,
Filippo

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
 http://www.debian.org

Bug#923944: unblock: double-conversion/3.1.0-3

[Mo Zhou]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

I've cherry-picked upstream commits to fix an upstream bug:
https://github.com/google/double-conversion/issues/89
That's all changes from 3.1.0-2 (testing) to 3.1.0-3.
The -3 revision will land on unstable shortly.
debdiff attached.

Detail:
* 8751aafe993c4ec429ba172916596403a336d502.diff
  fixes upstream issue #89
* 860b43156c1ba436aba9792407429bf46b9780a0.diff
  fixes typo in unit tests introduced by the above patch

unblock double-conversion/3.1.0-3

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru double-conversion-3.1.0/debian/changelog double-conversion-3.1.0/debian/changelog
--- double-conversion-3.1.0/debian/changelog	2018-09-20 05:41:28.0 +
+++ double-conversion-3.1.0/debian/changelog	2019-03-07 14:15:09.0 +
@@ -1,3 +1,9 @@
+double-conversion (3.1.0-3) unstable; urgency=medium
+
+  * Cherry-pick upstream commits to fix incorrect downcasting of separator_.
+
+ -- Mo Zhou   Thu, 07 Mar 2019 14:15:09 +
+
 double-conversion (3.1.0-2) unstable; urgency=medium
 
   * autopkgtest: Add one more test script unittest.sh .
diff -Nru double-conversion-3.1.0/debian/patches/860b43156c1ba436aba9792407429bf46b9780a0.diff double-conversion-3.1.0/debian/patches/860b43156c1ba436aba9792407429bf46b9780a0.diff
--- double-conversion-3.1.0/debian/patches/860b43156c1ba436aba9792407429bf46b9780a0.diff	1970-01-01 00:00:00.0 +
+++ double-conversion-3.1.0/debian/patches/860b43156c1ba436aba9792407429bf46b9780a0.diff	2019-03-07 14:06:42.0 +
@@ -0,0 +1,15 @@
+Modified from https://github.com/google/double-conversion/commit/860b43156c1ba436aba9792407429bf46b9780a0
+
+Index: double-conversion/test/cctest/test-conversions.cc
+===
+--- double-conversion.orig/test/cctest/test-conversions.cc
 double-conversion/test/cctest/test-conversions.cc
+@@ -3603,7 +3603,7 @@ TEST(StringToDoubleSeparator) {
+   CHECK(all_used);
+ 
+   CHECK_EQ(3.0,
+-   StrToD16("0x0@23.p0", flags, 0.0, , _used,
++   StrToD16("0x0@3.p0", flags, 0.0, , _used,
+ char_separator, separator));
+   CHECK(all_used);
+ }
diff -Nru double-conversion-3.1.0/debian/patches/8751aafe993c4ec429ba172916596403a336d502.diff double-conversion-3.1.0/debian/patches/8751aafe993c4ec429ba172916596403a336d502.diff
--- double-conversion-3.1.0/debian/patches/8751aafe993c4ec429ba172916596403a336d502.diff	1970-01-01 00:00:00.0 +
+++ double-conversion-3.1.0/debian/patches/8751aafe993c4ec429ba172916596403a336d502.diff	2019-03-07 14:06:42.0 +
@@ -0,0 +1,153 @@
+Fixes upstream bug: https://github.com/google/double-conversion/issues/89
+Cherry-picked from: https://github.com/google/double-conversion/commit/8751aafe993c4ec429ba172916596403a336d502
+
+Index: double-conversion/double-conversion/double-conversion.cc
+===
+--- double-conversion.orig/double-conversion/double-conversion.cc
 double-conversion/double-conversion/double-conversion.cc
+@@ -553,7 +553,7 @@ static bool IsCharacterDigitForRadix(int
+ 
+ // Returns true, when the iterator is equal to end.
+ template
+-static bool Advance (Iterator* it, char separator, int base, Iterator& end) {
++static bool Advance (Iterator* it, uc16 separator, int base, Iterator& end) {
+   if (separator == StringToDoubleConverter::kNoSeparator) {
+ ++(*it);
+ return *it == end;
+@@ -581,7 +581,7 @@ static bool Advance (Iterator* it, char
+ template
+ static bool IsHexFloatString(Iterator start,
+  Iterator end,
+- char separator,
++ uc16 separator,
+  bool allow_trailing_junk) {
+   ASSERT(start != end);
+ 
+@@ -622,7 +622,7 @@ template (0x123456789),
++   StrToD16("0x1@2@3@4@5@6@7@8@9", flags, Double::NaN(),
++, _used, char_separator, separator));
++  CHECK(all_used);
++
++  CHECK_EQ(18.0, StrToD16(" 0x1@2 ", flags, 0.0,
++  , _used, char_separator, separator));
++  CHECK(all_used);
++
++  CHECK_EQ(static_cast(0xabcdef),
++   StrToD16("0xa@b@c@d@e@f", flags, 0.0,
++, _used, char_separator, separator));
++  CHECK(all_used);
++
++  CHECK_EQ(Double::NaN(),
++   StrToD16("0x@1@2", flags, 0.0,
++, _used, 

Re: python-scipy: autopkgtest fails (Re: bug#919929)

[Drew Parsons]

On 2019-03-07 22:07, Paul Gevers wrote:

Hi Drew,

On 07-03-2019 14:56, Drew Parsons wrote:

On 2019-03-07 20:46, Paul Gevers wrote:

However, it is probably worth waiting for a resolution of bug
915738 and combine it with that.


There hasn't been recent movement on 915738. I'll apply Julian's patch
and see how we go.


Huh. There was a comment from doko that the underlying issue is fixed 
in

gcc-8, no? I think you only need to switch to the default gfortran. On
the other hand, I don't know how feasible it is at this moment to not
release buster with gcc-7. Maybe other release team members can comment
on that?


Perhaps it's ok now, as Matthias says.  Testing on zelenka now. I'll do 
the 919929 upload if s390x proves fine.


Drew

Re: python-scipy: autopkgtest fails (Re: bug#919929)

[Paul Gevers]

Hi Drew,

On 07-03-2019 14:56, Drew Parsons wrote:
> On 2019-03-07 20:46, Paul Gevers wrote:
>> However, it is probably worth waiting for a resolution of bug
>> 915738 and combine it with that.
> 
> There hasn't been recent movement on 915738. I'll apply Julian's patch
> and see how we go.

Huh. There was a comment from doko that the underlying issue is fixed in
gcc-8, no? I think you only need to switch to the default gfortran. On
the other hand, I don't know how feasible it is at this moment to not
release buster with gcc-7. Maybe other release team members can comment
on that?

Paul



signature.asc
Description: OpenPGP digital signature

Re: Advocating for unstable->testing flow

[Mattia Rizzolo]

Hi,

On Thu, Mar 07, 2019 at 09:55:00AM +0100, Filippo Rusconi wrote:
> Greetings, Fellow Debianites and Release Managers,
> 
> I would like to advocate for two pacakges to enter testing if no critical bugs
> are found in them:

Please file a proper unblock bug for each of them, stating your case
there.
Mails in the mailing list are easily overlooked, and the regular process
asks for bugs anyway.

> - isospec: a very small library for science;

This one is already in buster, and looking at the changelog I think it
should really be unblocked (using -march is a RC bug, you should
actually file one affecting the version in buster and fixed in
unstable…)

> - daps: an all-architecture package to build documentation;

-- 
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  `-


signature.asc
Description: PGP signature

Processed: Re: Bug#923797: unblock: pyres/1.5-2

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # forgot to tag with my question
> tags 923797 moreinfo
Bug #923797 [release.debian.org] unblock: pyres/1.5-2
Added tag(s) moreinfo.
> thanks
Stopping processing here.

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

Re: python-scipy: autopkgtest fails (Re: bug#919929)

[Drew Parsons]

On 2019-03-07 20:46, Paul Gevers wrote:

Hi Drew,

On 07-03-2019 13:19, Drew Parsons wrote:


python-scipy is currently failing all debci tests in both unstable and
testing.


autopkgtest only, so no FTBFS?


That's right, scipy builds fine.


Some of us want failing autopkgtest to be RC *after* the release of
buster. I am not aware of consensus about that yet. autopkgtest
*regression* in testing is effectively RC since the soft freeze of
12-2-2019. The autopkgtest of python-scipy is already failing in
testing, so it isn't a regression. Hence, it failing is not RC for 
buster.


Thanks, that clarifies the appropriate severity.

Certainly please do unblock if the full freeze is already in place. 
But

my intention was to first upload python-scipy 1.1 with a small patch,
not 1.2 just yet.


If you upload now, your package will not migrate to testing before the
full freeze becomes effective so it would need an unblock. If you want
to fix this issue with the three lines I saw in the bug report, you can
go ahead. However, it is probably worth waiting for a resolution of bug
915738 and combine it with that.


There hasn't been recent movement on 915738. I'll apply Julian's patch 
and see how we go.


Drew

Re: Fixing stretch debian-installer on armhf

[Cyril Brulebois]

Hi,

Vagrant Cascadian  (2019-03-06):
> Even rebuilding the debian-installer images, while pulling in a
> working kernel that would boot, debian-installer would load .udeb
> modules from stretch, not stretch-updates. This might be ok for
> hd-media targets or targets that do not load module .udeb files from
> the network, but netboot targets are not likely to work at all.

To clarify, from an earlier IRC conversations (#-boot yesterday,
#-kernel a couple of days ago): we're mostly considering rebuilding
src:debian-installer, not respinning ISO images (those don't seem to
be in widespread use in the arm* world).

> So some of the options at the moment appear to be:
> 
> * Wait for another point release, rebuild debian-installer, leaving
>   debian-installer on armhf broken until then. How long till the next
>   point release?

This wasn't confirmed yet but April 27 seems to be the front runner at
this stage.

> * Rebuild the debian-installer images, pulling in updates from
>   stretch-updates, leaving only armhf netboot targets broken. 

Expanding a bit: rebuilding src:debian-installer from the stretch
branch, which has s-p-u enabled, would fetch the fixed kernel and a
couple of its udebs, at build time; the resulting netboot images
wouldn't know about s-p-u though at run time, and would try to load
udebs from stretch. Even if we were to have some kind of support for
loading udebs from stretch and from s-p-u (backports support patches
could help), that would only be an option until a new linux is accepted
into s-p-u.

Finally, for completeness, there's no specific suppport regarding
stretch-updates; we pull stuff from a given suite and optionally from
$suite-p-u; of course, we could still switch from s-p-u to s-u for one
particular upload…

> * Another point release with the kernel update sooner than planned,
>   and rebuild debian-installer images.

This was brought up on #-kernel and it didn't spark joy (lots of teams
need to be around for a point release)…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: python-scipy: autopkgtest fails (Re: bug#919929)

[Paul Gevers]

Hi Drew,

On 07-03-2019 13:19, Drew Parsons wrote:
>> Can you elaborate why you think that bug should be RC (as that isn't
>> clear to me from the report itself) and why you haven't marked it as
>> such if you think it should be?
> 
> python-scipy is currently failing all debci tests in both unstable and
> testing.

autopkgtest only, so no FTBFS?

> I haven't marked it RC myself since I'm not 100% certain what the usual
> protocol is for marking the severity of debci test failures.  But as I
> understood it, debci test failures is considered RC under the final
> freeze which we're about to enter (but we're not quite in that deep
> freeze yet).

Some of us want failing autopkgtest to be RC *after* the release of
buster. I am not aware of consensus about that yet. autopkgtest
*regression* in testing is effectively RC since the soft freeze of
12-2-2019. The autopkgtest of python-scipy is already failing in
testing, so it isn't a regression. Hence, it failing is not RC for buster.

> Hi Andreas, I may not have been clear.  What I mean at this point is to
> upload a small patch for scipy 1.1 to ignore the deprecation warnings
> (scipy 1.2 already does that).
> 
> If that doesn't help pass the debci tests then we can consider uploading
> scipy 1.2 instead.  But python-fluids and dipy FTBFS against scipy 1.2
> (a new version of dipy is available which presumeably fixes that)

Please *don't* upload scipy 1.2 to fix only this issue (nor for any
other issue without discussion first), it's for sure not worth it.

>> Slightly depending on the answer above, I'll unblock an upload of
>> python-scipy with only that change.
> 
> Certainly please do unblock if the full freeze is already in place. But
> my intention was to first upload python-scipy 1.1 with a small patch,
> not 1.2 just yet.

If you upload now, your package will not migrate to testing before the
full freeze becomes effective so it would need an unblock. If you want
to fix this issue with the three lines I saw in the bug report, you can
go ahead. However, it is probably worth waiting for a resolution of bug
915738 and combine it with that.

Paul



signature.asc
Description: OpenPGP digital signature

Re: python-scipy: autopkgtest fails (Re: bug#919929)

[Drew Parsons]

On 2019-03-07 19:00, Paul Gevers wrote:

Hi Drew,

On 07-03-2019 09:03, Andreas Tille wrote:

On Tue, Mar 05, 2019 at 07:01:54PM +0800, Drew Parsons wrote:
python-scipy has recently started failing all debci tests in testing 
and

unstable, exacerbating the bug report in Bug#919929 [1].

The failing error is a MemoryError. But understanding the problem is
hampered by a flood of deprecation warnings, presumably triggered by 
numpy
1.16. scipy 1.2 added instructions to pytest.ini to ignore the 
warnings.


Bug#919929 has not yet been marked RC but I guess it's about to 
happen.


Can you elaborate why you think that bug should be RC (as that isn't
clear to me from the report itself) and why you haven't marked it as
such if you think it should be?


python-scipy is currently failing all debci tests in both unstable and 
testing.


I haven't marked it RC myself since I'm not 100% certain what the usual 
protocol is for marking the severity of debci test failures.  But as I 
understood it, debci test failures is considered RC under the final 
freeze which we're about to enter (but we're not quite in that deep 
freeze yet).




I
propose in the first instance to apply a patch of the pytest.ini diff
between scipy 1.1 and 1.2 and see if that clears things up. I'll 
commit the

patch now. Should I proceed with upload to unstable?


May be its sensible to coordinate with debian-release (list in CC) and
file a unblock request *before* uploading.  I confirm that I usually
upload simple fixes and ask for unblock afterwards but you intend to 
do

a version change which does not qualify as simple fix (despite I agree
with you that it is sensible).


Hi Andreas, I may not have been clear.  What I mean at this point is to 
upload a small patch for scipy 1.1 to ignore the deprecation warnings 
(scipy 1.2 already does that).


If that doesn't help pass the debci tests then we can consider uploading 
scipy 1.2 instead.  But python-fluids and dipy FTBFS against scipy 1.2 
(a new version of dipy is available which presumeably fixes that)



Slightly depending on the answer above, I'll unblock an upload of
python-scipy with only that change.


Certainly please do unblock if the full freeze is already in place. But 
my intention was to first upload python-scipy 1.1 with a small patch, 
not 1.2 just yet.


Drew

Processed: unblock: android-framework-23/6.0.1+r72-5, android-platform-dalvik/8.1.0+r23-2, android-sdk-meta/25.0.0+10

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 923901 unblock: android-framework-23/6.0.1+r72-5, 
> android-platform-dalvik/8.1.0+r23-2, android-sdk-meta/25.0.0+10
Bug #923901 [release.debian.org] unblock: android-framework-23/6.0.1+r72-5,
Changed Bug title to 'unblock: android-framework-23/6.0.1+r72-5, 
android-platform-dalvik/8.1.0+r23-2, android-sdk-meta/25.0.0+10' from 'unblock: 
android-framework-23/6.0.1+r72-5,'.
>
End of message, stopping processing here.

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

Processed (with 1 error): unblock: android-framework-23/6.0.1+r72-5, android-platform-dalvik/8.1.0+r23-2, android-sdk-meta/25.0.0+10

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 923901 unblock: android-framework-23/6.0.1+r72-5,
Bug #923901 [release.debian.org] unblock: android-framework-23/debian/25.0.0+9,
Changed Bug title to 'unblock: android-framework-23/6.0.1+r72-5,' from 
'unblock: android-framework-23/debian/25.0.0+9,'.
> android-platform-dalvik/8.1.0+r23-2, android-sdk-meta/25.0.0+10
Unknown command or malformed arguments to command.
>
End of message, stopping processing here.

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

Bug#923901: update debdiff and git log

[Hans-Christoph Steiner]

attached are updated debdiff and git log for changes from
debian/25.0.0+8 to debian/25.0.0+10
diff --git a/.gitignore b/.gitignore
index eeb0cfd..7f495f1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,5 +4,5 @@ debian/*.substvars
 debian/android-sdk*/
 debian/debhelper-build-stamp
 debian/files
-debian/source.properties
-debian/tmp/
\ No newline at end of file
+debian/tmp/
+source.properties
\ No newline at end of file
diff --git a/51-android.rules b/51-android.rules
index 47e2025..8961bcd 100644
--- a/51-android.rules
+++ b/51-android.rules
@@ -70,10 +70,10 @@ SUBSYSTEM=="usb", ATTR{idVendor}=="109b", 
ENV{adb_user}="yes"
 #HTC
 SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ENV{adb_user}="yes"
 #Huawei
-SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", ATTR{idProduct}=="", 
ENV{adb_user}="yes"
-SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", ATTR{idProduct}=="", 
ENV{adb_user}="yes"
-SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", ATTR{idProduct}=="", 
ENV{adb_user}="yes"
-SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", ATTR{idProduct}=="", 
ENV{adb_user}="yes"
+SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", ATTR{idProduct}=="1038", 
ENV{adb_user}="yes"
+SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", ATTR{idProduct}=="1021", 
ENV{adb_user}="yes"
+SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", ATTR{idProduct}=="1057", 
ENV{adb_user}="yes"
+SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", ATTR{idProduct}=="1050", 
ENV{adb_user}="yes"
 #Intel
 SUBSYSTEM=="usb", ATTR{idVendor}=="8087", ATTR{idProduct}=="09ef", 
ENV{adb_user}="yes"
 SUBSYSTEM=="usb", ATTR{idVendor}=="8087", ATTR{idProduct}=="0a16", 
ENV{adb_user}="yes"
diff --git a/build-tools/package.xml b/build-tools/package.xml
index 5cbbc4a..44dcff1 100644
--- a/build-tools/package.xml
+++ b/build-tools/package.xml
@@ -4,13 +4,13 @@
 
xmlns:ns5="http://schemas.android.com/repository/android/generic/01;
 
xmlns:ns6="http://schemas.android.com/sdk/android/repo/repository2/01;>
   Please refer to Apache v2.0 
license
-  
+  
 http://www.w3.org/2001/XMLSchema-instance;
   xsi:type="ns5:genericDetailsType"/>
 
-  24
+  27
   0
-  0
+  1
 
 Android SDK Build-Tools
 
diff --git a/build-tools/source.properties b/build-tools/source.properties
deleted file mode 100644
index e432fd7..000
--- a/build-tools/source.properties
+++ /dev/null
@@ -1,2 +0,0 @@
-Pkg.UserSrc=false
-Pkg.Revision=24.0.0
\ No newline at end of file
diff --git a/debian/.gitlab-ci.yml b/debian/.gitlab-ci.yml
new file mode 100644
index 000..44da822
--- /dev/null
+++ b/debian/.gitlab-ci.yml
@@ -0,0 +1,11 @@
+image: registry.salsa.debian.org/salsa-ci-team/ci-image-git-buildpackage:latest
+
+build:
+  except:
+- tags
+  artifacts:
+paths:
+- "*.deb"
+expire_in: 1 day
+  script:
+- gitlab-ci-git-buildpackage-all
diff --git a/debian/android-sdk-platform-tools.links 
b/debian/android-sdk-platform-tools.links
index 2b2284a..333767a 100644
--- a/debian/android-sdk-platform-tools.links
+++ b/debian/android-sdk-platform-tools.links
@@ -1 +1,5 @@
+etc/mke2fs.conf   usr/lib/android-sdk/platform-tools/mke2fs.conf
+sbin/mke2fs   usr/lib/android-sdk/platform-tools/mke2fs
+sbin/mkfs.f2fsusr/lib/android-sdk/platform-tools/make_f2fs
+sbin/sload.f2fs   usr/lib/android-sdk/platform-tools/sload_f2fs
 usr/bin/sqlite3   usr/lib/android-sdk/platform-tools/sqlite3
\ No newline at end of file
diff --git a/debian/changelog b/debian/changelog
index 02a8b91..52ac635 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,27 @@
+android-sdk-meta (25.0.0+10) unstable; urgency=medium
+
+  * drop packages with impossible arches from meta Depends
+
+ -- Hans-Christoph Steiner   Thu, 07 Mar 2019 10:35:06 +
+
+android-sdk-meta (25.0.0+9) unstable; urgency=medium
+
+  [ Jeremy Bicha ]
+  * android-sdk-platform-tools: Don't require adb or fastboot on mips*
+
+  [ 殷啟聰 | Kai-Chung Yan ]
+  * Update versions of SDK components to match upstream
+
+  [ Hans-Christoph Steiner ]
+  * fix missing idProduct values in udev rules
+  * add autopkgtest for udev rules
+  * add autopkgtest for `apt-get install android-tools-adb`
+  * add debian/.gitlab-ci.yml to run tests on GitLab CI
+  * update alternative Depends: for current Java versions (Closes: #922555)
+  * purge dependencies not in buster
+
+ -- Hans-Christoph Steiner   Wed, 06 Mar 2019 23:06:35 +
+
 android-sdk-meta (25.0.0+8) unstable; urgency=medium
 
   * include /usr/bin/screenshot2 as symlink
diff --git a/debian/clean b/debian/clean
new file mode 100644
index 000..6999eb3
--- /dev/null
+++ b/debian/clean
@@ -0,0 +1,2 @@
+build-tools/source.properties
+platform-tools/source.properties
\ No newline at end of file
diff --git a/debian/control b/debian/control
index 37e79fb..bab0575 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: android-sdk-meta
 Section: metapackages
 Priority: optional
 Maintainer: Android Tools Maintainers 

-Uploaders: Kai-Chung Yan ,
+Uploaders: 

Processed (with 1 error): unblock: android-framework-23/debian/25.0.0+9, android-platform-dalvik/8.1.0+r23-2, android-sdk-meta/25.0.0+9

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 923901 unblock: android-framework-23/debian/25.0.0+9,
Bug #923901 [release.debian.org] unblock: android-framework-23/debian/25.0.0+9,
Ignoring request to change the title of bug#923901 to the same title
> android-platform-dalvik/8.1.0+r23-2, android-sdk-meta/25.0.0+10
Unknown command or malformed arguments to command.
>
End of message, stopping processing here.

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

Bug#923901: unblock: android-framework-23/debian/25.0.0+9, android-platform-dalvik/8.1.0+r23-2, android-sdk-meta/25.0.0+9

[Hans-Christoph Steiner]

Control: retitle 923901 unblock: android-framework-23/debian/25.0.0+9,
android-platform-dalvik/8.1.0+r23-2, android-sdk-meta/25.0.0+10

I uploaded android-sdk-meta/25.0.0+10 to solve the depends issue in the
meta packages.  I chose to drop the Depends: on dexdump and/or
dmtracedump only for armel mips mipsel mips64el.  This keeps continuity
with what was in stretch, so people on those arches will get upgrades.



signature.asc
Description: OpenPGP digital signature

Processed: unblock: android-framework-23/debian/25.0.0+9, android-platform-dalvik/8.1.0+r23-2, android-sdk-meta/25.0.0+9

[Debian Bug Tracking System]

Processing control commands:

> retitle 923901 unblock: android-framework-23/debian/25.0.0+9,
Bug #923901 [release.debian.org] unblock: android-framework-23/debian/25.0.0+9, 
android-platform-dalvik/8.1.0+r23-2, android-sdk-meta/25.0.0+9
Changed Bug title to 'unblock: android-framework-23/debian/25.0.0+9,' from 
'unblock: android-framework-23/debian/25.0.0+9, 
android-platform-dalvik/8.1.0+r23-2, android-sdk-meta/25.0.0+9'.

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

Re: python-scipy: autopkgtest fails (Re: bug#919929)

[Paul Gevers]

Hi Drew,

On 07-03-2019 09:03, Andreas Tille wrote:
> On Tue, Mar 05, 2019 at 07:01:54PM +0800, Drew Parsons wrote:
>> python-scipy has recently started failing all debci tests in testing and
>> unstable, exacerbating the bug report in Bug#919929 [1].
>>
>> The failing error is a MemoryError. But understanding the problem is
>> hampered by a flood of deprecation warnings, presumably triggered by numpy
>> 1.16. scipy 1.2 added instructions to pytest.ini to ignore the warnings.
>>
>> Bug#919929 has not yet been marked RC but I guess it's about to happen.

Can you elaborate why you think that bug should be RC (as that isn't
clear to me from the report itself) and why you haven't marked it as
such if you think it should be?

>> I
>> propose in the first instance to apply a patch of the pytest.ini diff
>> between scipy 1.1 and 1.2 and see if that clears things up. I'll commit the
>> patch now. Should I proceed with upload to unstable?
> 
> May be its sensible to coordinate with debian-release (list in CC) and
> file a unblock request *before* uploading.  I confirm that I usually
> upload simple fixes and ask for unblock afterwards but you intend to do
> a version change which does not qualify as simple fix (despite I agree
> with you that it is sensible).

Slightly depending on the answer above, I'll unblock an upload of
python-scipy with only that change.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#923928: unblock: daps/3.0.0-3

[Filippo Rusconi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package daps

Greetings, Fellow Debianites and Release Managers,

I would like to advocate for daps to enter testing if no critical bugs
are found in it:

- daps is an all-arch package useful to create DocBook-based documentation;

I have packaged this software piece myself because my msxpertsuite software
needs them.

I really would like msxpertsuite to be part of stable, because it is a
replacement of massxpert that had a pretty good popularity contest rate. It is
not a recent development, and I currently have a paper in revision where I
pretend it will be in Debian :-).

daps does not have reverse-dependencies other than msxpertsuite.

In the hope that you will consider this request favorably,

Sincerely,
Filippo

unblock daps/3.0.0-3

-- System Information:
Debian Release: buster/sid
 APT prefers testing
 APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
 http://www.debian.org

Bug#923901: sorting out armel mips mipsel mips64el now

[Hans-Christoph Steiner]

android-sdk-meta is a collection of meta packages, so their Depends: are
to pull in packages as a group.  The udev rules are in
android-sdk-platform-tools-common, which is "Architecture: all".

It seems that valgrind was removed permanently from buster/armel. So
these issues can be solved in one of two simple ways:

* removing armel mips mipsel mips64el from the supported architectures

* dropping the Depends: on dexdump and/or dmtracedump only for armel
mips mipsel mips64el

Both are fine by me and easy to do.

Bug#923927: unblock: isospec/1.9.1-5

[Filippo Rusconi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package isospec

Greetings, Fellow Debianites and Release Managers,

I would like to advocate for isospec to enter testing if no critical bugs
are found in it:

- isospec is a very small library for science;

The difference between buster/sid version is only packaging, in particular
patching a Makefile to fix the build flags for various architectures on which
the software did not build (two last days work).

I have packaged this software piece myself because my msxpertsuite software
needs them.

I really would like msxpertsuite to be part of stable, because it is a
replacement of massxpert that had a pretty good popularity contest rate. It is
not a recent development, and I currently have a paper in revision where I
pretend it will be in Debian :-).

isospec does not have reverse-dependencies other than msxpertsuite.

In the hope that you will consider this request favorably,

Sincerely,
Filippo

unblock isospec/1.9.1-5

-- System Information:
Debian Release: buster/sid
 APT prefers testing
 APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
 http://www.debian.org

Bug#923901: sorting out armel mips mipsel mips64el now

[Hans-Christoph Steiner]

* android-sdk-build-tools/armel unsatisfiable Depends: dexdump (>=
8.1.0+r23~)
* android-sdk-platform-tools/armel unsatisfiable Depends: dmtracedump
(>= 8.1.0+r23~)

android-sdk-build-tools/armel depends on dexdump,
android-sdk-platform-tools/armel depends on dmtracedump.  Both of these
are from from src:android-platform-art which Build-Depends: on valgrind.
 valgrind/armel is missing in sid but present in buster, so this is a
sid-only issue:

https://buildd.debian.org/status/package.php?p=android-platform-art=buster
https://buildd.debian.org/status/package.php?p=android-platform-art=sid




* android-sdk-build-tools/mips unsatisfiable Depends: dexdump (>=
8.1.0+r23~)
* android-sdk-build-tools/mipsel unsatisfiable Depends: dexdump (>=
8.1.0+r23~)

buildd says android-platform-art built and installed on both mips and
mipsel:
https://buildd.debian.org/status/package.php?p=android-platform-art=buster

But they are somehow missing from the buster archive:
https://packages.debian.org/buster/dexdump



* missing build on mips64el: android-sdk, android-sdk-build-tools,
android-sdk-platform-tools (from 25.0.0+8)

buildd says it built and installed on mips64el but those packages aren't
in the archive yet:
https://packages.debian.org/sid/android-sdk
https://buildd.debian.org/status/package.php?p=android-sdk-meta=sid





signature.asc
Description: OpenPGP digital signature

Bug#923770: unblock: zfs-linux/0.7.13-1

[Aron Xu]

Hi,

Similar to what I have replied for Bug #923769, this is a new upstream
bug fix minor point release, and here are some details.

In packaging:
1. Rebase 2332-OpenZFS-8898-creating-fs-with-checksum-skein-on-the-.patch
A simple patch rebase.
2. Remove linux 4.20 and 5.0 compat fixes.
Included in upstream 0.7.13. See # in the following section.
3. Bump Standards-Version to 4.3.0 (no change).
4. Include new example scripts
Installs a new example file `etc/zfs/vdev_id.conf.scsi.example'
which is left out unintentionally in previous version.

Changes in upstream release are here:
https://github.com/zfsonlinux/zfs/commits/zfs-0.7-release

In more detail:

1. 
https://github.com/zfsonlinux/zfs/commit/2428fbbfcf7f1b2298e1e4ee054430ca155144cc
   Non-significant change to use automake to build initramfs scripts and hooks.

2. 
https://github.com/zfsonlinux/zfs/commit/edb504f9dbeb2921da2eb669ff052e11c8079e9d
   Minor fix to make initramfs/dracut able to find mount.zfs mount
helper when not
   installed to /sbin

3. 
https://github.com/zfsonlinux/zfs/commit/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a
   Avoid a deadlock by not creating/removing zfs_dbuf_evict_key tsd values, also
   improves performance a little bit

4. 
https://github.com/zfsonlinux/zfs/commit/14a5e48fb92210541ffd04081c313f4d6061a4d9
   Replace hard coded command cpp with $CPP, to fix cross-compiling.

5. 
https://github.com/zfsonlinux/zfs/commit/e3fb781c5fdaaba0ee788a1602490dc9e3a7c7d5
   Auto load zfs kernel module when needed. Previous behavior is that,
there must
   be an active zpool to make systemd services to load the kernel
module at system
   boot time, otherwise user must run modprobe themselves before using any
   zfs/zpool command lines. Auto loading would improve user experience but
   previously we are conservative.

6. 
https://github.com/zfsonlinux/zfs/commit/f325d76e962fa569503189797ffdd447114db88c
Fix a conflict of marco ZFS_MINOR which interferes with Lustre

7. 
https://github.com/zfsonlinux/zfs/commit/2b8c3cb0c83681d7425fa5bf567e726b7ba975e9

https://github.com/zfsonlinux/zfs/commit/41f7723e9cb260f313f99d667142e37617812fca

https://github.com/zfsonlinux/zfs/commit/89019a846b90f933db13082cdfe7c046dee0a210
Helper shell script, udev rule and man page changes, making `vdev_id'
command behave similar with SCSI disks to previously supported SAS
disks, also make it generates consistently named links in /dev/by-enclosure/
by adding a `enclosure_symlinks' option to this piece of shell script.

8. 
https://github.com/zfsonlinux/zfs/commit/7e5def8ae0586d1fb9a27411e529ad1a356795c3
Minor fix in man page examples.

9. 
https://github.com/zfsonlinux/zfs/commit/b0d579bc55a8536fe6313a7627d52206322d39b9
Only affects contributing commits to the project -- make commit
subject length limit bump from 50 to 72 characters.

10. 
https://github.com/zfsonlinux/zfs/commit/44f463824bc78df2d23dd049c3ef57ddaf464feb
 Add an option to dkms configuration to empower the user to
 forcibly enable debuginfo generation at dkms build time.

11. 
https://github.com/zfsonlinux/zfs/commit/98bb45e27ae80145a6ce028df90fccdb23f8901d
 Deadlock fix, which is useful together with this change in spl-linux:
 
https://github.com/zfsonlinux/spl/commit/cb4464f1549087794fdbe0f5ad2328618de2033e

12. 
https://github.com/zfsonlinux/zfs/commit/0a3a4d067a40bf3a84fcbe0a4f3869fb1bca8f18
  
https://github.com/zfsonlinux/zfs/commit/e22bfd814960295029ca41c8e116e8d516d3e730
  
https://github.com/zfsonlinux/zfs/commit/5c4ec382a76c7c0d6b218fcab5a1c2e035012158
  Already cherry-picked in zfs-linux/0.7.12-2 which is now released
  in upstream tarball.

13. 
https://github.com/zfsonlinux/zfs/commit/edc2675aed7d05f7ec230874e33c8a20d7402b02
  
https://github.com/zfsonlinux/zfs/commit/ba8024a2849d347886328a1148d1ed820869a4e2
  
https://github.com/zfsonlinux/zfs/commit/f45ad7bff6cacb4ca0717a1f6686873136a5aa22
  These 4 patches are changes for Linux 5.0 compatibility, and
  mostly they are conditional applied to higher versions of Linux
  when detected (most diffs are to m4 and Makefile files to
  implement such behavior). As spl/zfs are already declared to
  support up to Linux version 5.0 in debian/linux_compat, we
  would like to have these compatibility patches applied.

14. 
https://github.com/zfsonlinux/zfs/commit/2254b2bbbe17a1ad34b016d1605fea49c01461cf
  Compiler compatibility fix for GCC9.0. Also the command is
  only used when testing zpool/zfs itself.

15. 
https://github.com/zfsonlinux/zfs/commit/c32c2f17d06cea5dc298b404fad7696921e490e0
  test-runner python3 compatibility. The stuff is only used when
  running upstream tests.

Please unblock zfs-linux/0.7.13-1, thanks.

Regards,
Aron

Bug#923901: sorting out armel mips mipsel mips64el now

[Hans-Christoph Steiner]

FYI, I'm working right now on sorting out why android-sdk-meta/25.0.0+9
is having issues on out armel mips mipsel mips64el.

Also, FYI, android-sdk-meta/25.0.0+8 was in buster for a while, and was
removed because of android-framework-23.

Bug#907199: Need alternative

[Bardot Jérôme]

Hello,


Disclamer: i did not read all bug posts.


I just see you removed weboob from repositories. Well, do you will
provide an alternative ?

I don’t care about my software names' while it does the job.

If i remember well  the name is a word game. The weboob team had remove
insults in their code no ?

They do a great job with their piece of software why should not respect
their touch of humor ? (people who don’t like it, will not install it by
the way)


Back to my concern i use mostly the bank part for custom dashboards. If
you can provide an alternative it would be cool. I’m sure a lot of
Debian users use weboob and are like me.




Jérôme





0x053A41EF03878A98.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#923769: unblock: spl-linux/0.7.13-1

[Aron Xu]

Hi,

spl-linux/0.7.13-1 is a new upstream bug fix minor point release, here
are some details about the changes:

In packaging:
1. Removed 0001-Add-check-for-ktime_get_coarse_real_ts64-for-V5.0-ke.patch:
Included in upstream 0.7.13, see #2 in following section.
2. Bump Standards-Version to 4.3.0 (no change).

Changes in upstream release are here:
https://github.com/zfsonlinux/spl/commits/spl-0.7-release

In more detail:

1. 
https://github.com/zfsonlinux/spl/commit/b80cb0ac2f15ff9eeb776aab037eefc713f8458c
Replace hard coded command cpp with $CPP, to fix cross-compiling.

2. 
https://github.com/zfsonlinux/spl/commit/e2c6e12ef26c86d7a23568ffad5e55d00ab00eba
Already cherry-picked in spl-linux/0.7.12-2 which is now released
in upstream tarball

3. 
https://github.com/zfsonlinux/spl/commit/cb4464f1549087794fdbe0f5ad2328618de2033e
One liner, part of a deadlock fix, which is useful together with
this change in zfs-linux:

https://github.com/zfsonlinux/zfs/commit/98bb45e27ae80145a6ce028df90fccdb23f8901d

4. 
https://github.com/zfsonlinux/spl/commit/2e2babafd8e13ef0bbe46e28fa8fb35aa1e5ebc9

https://github.com/zfsonlinux/spl/commit/8a9030bd9fd6633fdfda3d9d14c80c56aa179a9e

https://github.com/zfsonlinux/spl/commit/b237f61564de1dca05d415501889e33e1f0dac20

https://github.com/zfsonlinux/spl/commit/39333e3323b19a76bcef1a210f5636550661f77a
These 4 patches are changes for Linux 4.20 and Linux 5.0
compatibility, and mostly they are
conditional applied to higher versions of Linux when detected
(most diffs are to m4 and
Makefile files to implement such behavior). As spl/zfs are already
declared to support up to Linux
version 5.0 in debian/linux_compat, we would like to have these
compatibility patches applied.

Please unblock spl-linux/0.7.13-1, thanks.

Regards,
Aron

Advocating for unstable->testing flow

[Filippo Rusconi]

Greetings, Fellow Debianites and Release Managers,

I would like to advocate for two pacakges to enter testing if no critical bugs
are found in them:

- isospec: a very small library for science;
- daps: an all-architecture package to build documentation;

I have packaged these software pieces myself because my msxpertsuite software
needs them.

I really would like msxpertsuite to be part of stable, because it is a
replacement of massxpert that had a pretty good popularity contest rate. It is
not a recent development, and I currently have a paper in revision where I
pretend it will be in Debian :-).

isospec and daps do not have reverse-dependencies other than msxpertsuite.

In the hope that you will consider this request favorably,

Sincerely,
Filippo

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
 http://www.debian.org

Bug#917805: marked as done (release.debian.org: autopkgtests wrongly assume that package work in testing)

[Debian Bug Tracking System]

Your message dated Thu, 7 Mar 2019 09:29:07 +0100
with message-id 
and subject line Re: release.debian.org: autopkgtests wrongly assume that 
package work in testing
has caused the Debian Bug report #917805,
regarding release.debian.org: autopkgtests wrongly assume that package work in 
testing
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
917805: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917805
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal

The upload of glibc 2.28-4 has trigger the pacemaker autopkgtest, which
failed due to bug#917801, caused by the migration of corosync 3.0.0-1 to
testing on 2018-12-26:

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pacemaker/1613604/log.gz

It is considered as a regression introduced by the glibc upload, as the
reference used is the following from 2018-12-24, which still uses
corosync 2.4.4-3.

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pacemaker/1581332/log.gz

I believe the autopkgtests should not assume that a package still works
in testing if it has worked at some point in the past. The best would be
to retry the tests purely in testing if the one from testing + tested
package fail.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- End Message ---
--- Begin Message ---
Hi Aurelien,

On Sun, 30 Dec 2018 15:10:27 +0100 Aurelien Jarno 
wrote:
> I believe the autopkgtests should not assume that a package still works
> in testing if it has worked at some point in the past. The best would be
> to retry the tests purely in testing if the one from testing + tested
> package fail.

The migration software has been improved to ignore results from versions
not in unstable or testing. So the case in this bug report shouldn't
happen anymore.

https://salsa.debian.org/release-team/britney2/commit/992b27a

Paul



signature.asc
Description: OpenPGP digital signature
--- End Message ---

Re: python-scipy: autopkgtest fails (Re: bug#919929)

[Andreas Tille]

On Tue, Mar 05, 2019 at 07:01:54PM +0800, Drew Parsons wrote:
> python-scipy has recently started failing all debci tests in testing and
> unstable, exacerbating the bug report in Bug#919929 [1].
> 
> The failing error is a MemoryError. But understanding the problem is
> hampered by a flood of deprecation warnings, presumably triggered by numpy
> 1.16. scipy 1.2 added instructions to pytest.ini to ignore the warnings.
> 
> Bug#919929 has not yet been marked RC but I guess it's about to happen.  I
> propose in the first instance to apply a patch of the pytest.ini diff
> between scipy 1.1 and 1.2 and see if that clears things up. I'll commit the
> patch now. Should I proceed with upload to unstable?

May be its sensible to coordinate with debian-release (list in CC) and
file a unblock request *before* uploading.  I confirm that I usually
upload simple fixes and ask for unblock afterwards but you intend to do
a version change which does not qualify as simple fix (despite I agree
with you that it is sensible).

Kind regards

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

-- 
http://fam-tille.de