Bug#835537: jessie-pu: package open-iscsi/2.0.873+git0.3b4b4500-8+deb8u1

[Cyril Brulebois]

Hi,

Christian Seiler  (2016-08-26):
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: jessie
> Severity: normal
> X-Debbugs-Cc: pkg-iscsi-maintain...@lists.alioth.debian.org, k...@debian.org
> 
> Dear release team,
> (Cc'ing KiBi because this affects d-i/udebs.)

No objections at first glance, thanks.


KiBi.


signature.asc
Description: Digital signature

Processed: Re: Bug#835397: transition: superlu soname 4 -> 5

[Debian Bug Tracking System]

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

> block 835397 by 835556 835557
Bug #835397 [release.debian.org] transition: superlu
835397 was not blocked by any bugs.
835397 was not blocking any bugs.
Added blocking bug(s) of 835397: 835557 and 835556
> thanks
Stopping processing here.

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

Bug#835397: transition: superlu soname 4 -> 5

[Drew Parsons]

binNMU requests filed to complete the petsc/slepc transtion:
#835556: nmu: aster_11.5.0+dfsg2-4
#835557: nmu: dolfin_2016.1.0-2

Bug#835557: nmu: dolfin_2016.1.0-2

[Drew Parsons]

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

nmu dolfin_2016.1.0-2 . ANY . unstable . -m "binNMU for petsc 3.7 transition"

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

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

Bug#835556: nmu: aster_11.5.0+dfsg2-4

[Drew Parsons]

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

nmu aster_11.5.0+dfsg2-4 . ANY . unstable . -m "binNMU for petsc 3.7 transition"

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

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

Bug#815036: transition: msgpack-c

[James McCoy]

On Sat, Aug 13, 2016 at 10:10:29AM -0400, James McCoy wrote:
> On Tue, Jun 14, 2016 at 06:17:31PM -0400, James McCoy wrote:
> > + libdata-messagepack-perl has a fix upstream but no "stable" release
> >   including it

There is now an actual upstream release with the msgpack-c changes.

> > + libdata-messagepack-stream-perl could be NMUed once
> >   libdata-messagepack-perl is available.
> 
> No activity on either of these.
> 
> They're only used by libcatmandu-store-lucy-perl and
> libtext-xslate-perl, which have no rdeps.  Should I bump the severity of
> these bugs or suggest removing them?

I've pinged these bugs and got responses that the Perl folks would be ok
with those two packages being removed from testing (not unstable since
packaging was done in response to an RFP) to help the transition and
possibly bring visibility to the needed maintenance.

Given that there's been some activity upstream around these packages,
I'm a little more confident about performing NMUs than I had been.

Thoughts on how to proceed?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Processed: Re: Bug#835397: transition: superlu soname 4 -> 5

[Debian Bug Tracking System]

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

> retitle 835397 transition: superlu
Bug #835397 [release.debian.org] transition: superlu soname 4 -> 5
Changed Bug title to 'transition: superlu' from 'transition: superlu soname 4 
-> 5'.
> thanks
Stopping processing here.

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

Processed: boinc: FTBFS with openssl 1.1.0

[Debian Bug Tracking System]

Processing control commands:

> block 827061 by -1
Bug #827061 [release.debian.org] transition: openssl
827061 was blocked by: 828502 828514 828430 828466 828475 828584 828442 828542 
828370 828335 828437 828281 828488 828287 828322 828282 828600 828586 828571 
828389 828406 828547 828388 828575 828515 828482 828385 828510 828522 828433 
828424 828386 828491 828306 828572 828396 828567 828460 828486 828568 828283 
828457 828497 828462 828604 828372 828345 828337 828519 828344 828479 828310 
828496 828580 828573 828553 828311 828521 828467 828326 828603 828592 828583 
828239 828589 828427 828508 828455 828238 828240 828620 828300 828266 828374 
828577 828499 828252 828244 828399 828503 828526 828591 828082 828528 828419 
828315 828292 828551 828576 828545 828449 828418 828516 828606 828540 828274 
828539 828295 828308 828320 828235 828533 828373 828303 828468 828304 828276 
828511 828273 828356 828610 828556 828590 828251 828544 828562 828228 828250 
828478 828395 828512 828505 828259 828359 828474 828327 828435 828365 828231 
828570 828253 828501 828284 828561 828420 828619 828615 828535 828330 828321 
828448 828369 828230 828340 828504 828279 828346 828565 828536 828416 828434 
828524 828262 828247 828309 828425 828380 828601 828376 828557 828492 828438 
828487 828360 828246 828331 828317 828307 828371 828412 828232 828611 828382 
828444 828127 828364 828296 828256 828597 828461 828548 828248 828293 828452 
828617 828316 828498 828368 828513 828421 828493 828453 828243 828520 828543 
828594 828260 828390 828351 828408 828261 828480 828602 828599 828229 828500 
828509 828410 828558 828495 828383 828585 828342 828272 828379 828439 828506 
828378 828582 828574 828268 828531 828277 828298 828347 828254 828494 828484 
828343 828546 828366 828560 828549 828485 828236 828598 828404 828605 828338 
828288 828333 828336 828361 828302 828257 828255 829465 828377 828552 828414 
828358 828426 828233 828405 828608 828265 828329 828451 828411 828525 828392 
828477 828391 828618 828352 828289 828263 828324 828529 828301 828415 828578 
828314 828507 828297 828472 828269 828362 828286 828518 828555 828367 828241 
828354 828450 828564 828527 828393 828614 828350 822380 828538 828579 828402 
828523 828537 828299 828397 828532 828375 828290 828476 828242 828280 828612 
828394 828422 828446 828264 828387 828341 828381 828403 828278 828328 828334 
828454 828569 828400 828581 828313 828459 828431 828275 828443 828237 828436 
814600 828469 828456 828355 828490 828312 828596 828349 828319 828566 828530 
828481 828432 828609 828258 828323 828318 828353 828357 828083 828550 828429 
828407 828413 828285 827076 828587 828470 828305 828267 828325 828234 828440 
828554 828464 828363 828458 828139 828613 828463 828249 828445 828616 828607 
828417 809271 828489 828270 828294 828291 828534 828541 828465 828595 828473 
829452 828447 828398 828559 827068 828471 828588 828428 828423 828271 828563 
828483 828441 828593 808669 828517 828384 828401 828142 828339 828332 828409
827061 was not blocking any bugs.
Added blocking bug(s) of 827061: 835549

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

Re: [Pkg-rust-maintainers] Plan for updating (hypothetical future) firefox-esr versions in stable with changed build-deps?

[Ximin Luo]

Ralph Giles:
> On 26/08/16 03:53 AM, Ximin Luo wrote:
> 
>> (cargo is harder, but it's also much smaller and quicker to build, so
>> I think it's less of a problem to bundle that. Also right now
>> Firefox-with-rust would be using cargo nightly; I don't know yet if
>> they have plans to change this.)
> 
> Firefox actually builds with the cargo included with rustc 1.11.0
> stable. Mozilla's release builds use a nightly cargo which implements
> `cargo build --frozen` to make sure we don't have any out-of-tree
> dependencies, but that's optional. That switch should be generally
> available in cargo as of the 1.12 stable release.
> 
> We're trying to require only stable rust to build Firefox, and that
> applies to cargo too.
> 

Thanks for the clarification! Yes, this will make things much easier for us too.

> Is rustc building cleanly against the packaged llvm?
> 

Yes, I don't even remember when we last had a problem with that. Recently we 
also switched to dynamically linking against libLLVM.so and this has been 
working fine too.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Re: [Pkg-rust-maintainers] Plan for updating (hypothetical future) firefox-esr versions in stable with changed build-deps?

[Ralph Giles]

On 26/08/16 03:53 AM, Ximin Luo wrote:

> (cargo is harder, but it's also much smaller and quicker to build, so
> I think it's less of a problem to bundle that. Also right now
> Firefox-with-rust would be using cargo nightly; I don't know yet if
> they have plans to change this.)

Firefox actually builds with the cargo included with rustc 1.11.0
stable. Mozilla's release builds use a nightly cargo which implements
`cargo build --frozen` to make sure we don't have any out-of-tree
dependencies, but that's optional. That switch should be generally
available in cargo as of the 1.12 stable release.

We're trying to require only stable rust to build Firefox, and that
applies to cargo too.

Is rustc building cleanly against the packaged llvm?

 -r



signature.asc
Description: OpenPGP digital signature

Processed: block 835170 with 835514

[Debian Bug Tracking System]

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

> block 835170 with 835514
Bug #835170 [release.debian.org] transition: protobuf
835170 was blocked by: 835425 835433 835427 835266 835430 822380 835290 835429 
835435 835302 809290 811917
835170 was not blocking any bugs.
Added blocking bug(s) of 835170: 835514
> thanks
Stopping processing here.

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

Bug#835537: jessie-pu: package open-iscsi/2.0.873+git0.3b4b4500-8+deb8u1

[Christian Seiler]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: jessie
Severity: normal
X-Debbugs-Cc: pkg-iscsi-maintain...@lists.alioth.debian.org, k...@debian.org

Dear release team,
(Cc'ing KiBi because this affects d-i/udebs.)

I'd like to propose an update of open-iscsi for the next point release.
It fixes the following two bugs:

 - https://bugs.debian.org/834830 (Severity: serious)

   This was reported on debian-user recently: after an installation on
   an iSCSI device, open-iscsi-udeb contains a hook to copy /etc/iscsi
   from the d-i environment over to the system. But it doesn't
   regenerate the initramfs afterwards - and because the daemon was
   never started in the installed system, the initiatorname.iscsi file
   would not contain a valid initiator name.

   Basically, this rendered a freshly installed system on iSCSI
   unbootable.

   sid hasn't been affected for a while, since we moved the generation
   logic from daemon startup to postinst. However, that change is not
   trivial, and the simpler fix is to simply regenerate the initramfs
   after copying the configuration to the system. In order to not have
   code in Jessie that's not also in sid, I've added the initramfs
   regeneration to the package in sid anyway. [1] (Even though it's not
   necessary there.)

   I've tested the udeb by starting an 8.5 installer, and installing
   the updated udeb via wget + udpkg and can confirm that it now works
   as expected.

 - https://bugs.debian.org/833917 (Severity: important)

   This was also reported on debian-user recently. There's a race
   condition at startup: while the current init script of open-iscsi
   does wait for the iSCSI disks themselves to appear via udevadm
   settle, the kernel scans disks for partitions asynchronously,
   which can lead to LVs on partitions not being activated.

   The proper fix for that will be to switch to an event-based startup;
   in order to support that in combination with LVM one needs lvmetad
   though - which doesn't work in Jessie. (See #774082.)

   The simplest workaround is to just wait a second after iSCSI session
   login. This is not ideal, but the least-invasive fix to improve the
   experience for Jessie users. I've also applied this workaround to
   the package in sid [2], because the event-based logic isn't complete
   there yet.

   In sid we already had a similar workaround when multipath was
   installed, waiting 3s. (multipath is even more racy.) I've taken the
   liberty in backporting that fix to Jessie as well.

   I've tested the resulting package on a Jessie system.

Source debdiff against the current version in Jessie is attached.

Thanks for considering,
Christian

[1] 
http://sources.debian.net/src/open-iscsi/2.0.873%2Bgit1.4c1f2d90-2/debian/open-iscsi-udeb.finish-install/#L15
[2] 
http://sources.debian.net/src/open-iscsi/2.0.873%2Bgit1.4c1f2d90-2/debian/extra/activate-storage.sh/#L58

diff -Nru open-iscsi-2.0.873+git0.3b4b4500/debian/changelog open-iscsi-2.0.873+git0.3b4b4500/debian/changelog
--- open-iscsi-2.0.873+git0.3b4b4500/debian/changelog	2015-05-24 10:48:15.0 +0200
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/changelog	2016-08-20 11:14:44.0 +0200
@@ -1,3 +1,14 @@
+open-iscsi (2.0.873+git0.3b4b4500-8+deb8u2) jessie; urgency=medium
+
+  * [6d8d26d] init script: wait a bit after iSCSI devices have appeared.
+This works around a race condition in which dependent devices can
+appear only after the initial udev settle has returned.
+(Closes: #833917)
+  * [8a8a870] open-iscsi-udeb: update initramfs after copying
+configuration to target system. (Closes: #834830)
+
+ -- Christian Seiler   Sat, 20 Aug 2016 11:14:44 +0200
+
 open-iscsi (2.0.873+git0.3b4b4500-8+deb8u1) stable; urgency=medium
 
   * [725c5c6] Populate udebs in every architecture they are built
diff -Nru open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.init open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.init
--- open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.init	2015-02-10 14:34:58.0 +0100
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.init	2016-08-20 11:14:44.0 +0200
@@ -109,6 +109,20 @@
 
 	udevadm settle || true;
 
+	# Work around race conditions: while after the above settle
+	# the disks themselves are guaranteed to be there, the
+	# kernel will scan partitions asynchronously; and multipathd
+	# will activate multipath devices only after a short delay
+	# (while it itself races for a lock with udev).
+	# See Debian Bug #833917 for details.
+	if [ -x /sbin/multipath ] ; then
+		sleep 3
+	else
+		sleep 1
+	fi
+	# Settle again to make sure that dependent devices are now
+	# available.
+	udevadm settle || true;
 
 	# Handle iSCSI LVM devices
 	if [ ! -x "/sbin/vgchange" -a -n "$LVMGROUPS" ]; then
diff -Nru open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi-udeb.finish-install 

Bug#834261: jessie-pu: package intel-microcode/3.20160714.1~deb8u1

[Henrique de Moraes Holschuh]

Due to new information, I have now high confidence that this proposed
update fixes a regression currently present in jessie (stable): Debian
bug #815990.

-- 
  Henrique Holschuh

RE: Porter roll call for Debian Stretch

[Daniel Knezevic]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretch release (est. end
of 2020):

For mips, mipsel and mips64el, I
 - can test all packages on this architecture on different hardware
   (I have access to different MIPS boards)
 - detect toolchain issues and bring it to the attention of toolchain
   maintainers whom we already have contact to,
 - triage arch-specific bugs
 - fix arch-related bugs

I am not a DD/DM.

Daniel Knezevic

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJXwEEeAAoJEJg7dWwzb8w/h3AH/Ar0NCDJL0tmMKOFDsZT/xsG
NaDRr63/zxz4wYNWw0zRcJIYZhfhsL6h03qmoTvSqWe9TCy5+SBjpepIbmzwiu+k
UAdX8ob1pYd0WJIataARy8wvhY/52LMjufcEVUp8dguNGmTCnkVgL7bN+PaYG+il
gziGeMdmDRHyszGlpIOd7byf090gMWtnuxkSofqwxlLdOG9szmUQ88YFy19F9mNW
/b3BQcxqNj6svluEjNMeozmfhcmB2EdRJR60zonL67TDf/Yj8FO7SiiVpaL2JOQV
VtWP2SngZrDnJpzbluF+Cu/23S/ScYnD7arKhWJdeJKHOkr1nXPOYAs4EE7/OoY=
=SvJh
-END PGP SIGNATURE-

Re: Porter roll call for Debian Stretch

[James Cowgill]

Hi,

On 17/08/16 21:05, ni...@thykier.net wrote:
> Like last release, we are doing a roll call for porters of all release
> architectures.  If you are an active porter behind one of the [release
> architectures] for the entire lifetime of Debian Stretch (est. end of
> 2020), please respond with a signed email containing the following
> before Friday, the 9th of September:
> 
>  * Which architectures are you committing to be an active porter for?

I'm an active porter for mips, mipsel and mips64el.

>  * Please describe recent relevant porter contributions.

Numerous mips64el related bugs and some assistance bootstrapping parts
of it. Lately I've been looking at some toolchain issues and bugs in
various other packages.

>  * Are you running/using Debian testing or sid on said port(s)?

Yes we have a number of mips machines running testing. They are mostly
used for development (some quite heavily used). I test common packages
on them (I'd be surprised if anyone can claim they test *all* packages
on their arch).

>  * Are you testing/patching d-i for the port(s)?

I don't use d-i a huge amount with the port unfortunately. Having said
that I am about to setup another machine so I'll try it out on that :)

>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>also apply to this port? [0]

I'm not aware of any issues with enabling -fPIC on mips arches so I
think you can go ahead with it. PIE is already enabled in a number of
packages and there doesn't seem to be any issues with them mips.

I'm a DD

James



signature.asc
Description: OpenPGP digital signature

Re: Porter roll call for Debian Stretch

[Frederic Bonnard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretchj release (est. end
of 2020):

For ppc64el, I
- - test most packages on this architecture
- - run a Debian testing or unstable system on port that I use regularly
- - fix arch-related bugs
- - triage d-i bugs
- - test d-i regularly
- - fix d-i bugs/issues

I am a DM.

About -fPIE/-pie, I'd say my packages should be ready to have it enabled by
default, even if, for skiboot package, on Ubuntu (with gcc having pie by
default since 16.04) I had to disable (or it crashed) it with -no-pie because
of assembly code being used for some part and that will not be changed soon by
upstream I guess.
In another package, I had another issue where a static test binary was compiled
with -pie because of hardening and -static, which produced a dynamically linked
executable.. which failed at runtime. I'm not an expert but gcc does not seem
to be ready for static+pie and it didn't complain either about both flags being 
used
( https://gcc.gnu.org/ml/gcc/2015-06/msg8.html )

I always add DEB_BUILD_MAINT_OPTIONS = hardening=+all to my packages (else
lintian reports about "hardening-no-pie"), but in default hardening there is no 
pie,
and I'm not sure all packages do so.
Checking https://lintian.debian.org/tags/hardening-no-pie.html, 
59088 packages have "hardening-no-pie" lintian... so pie doesn't not seem really
tested to me.
As I had 3 issues out of ~10 packages I maintain, I'm unsure of the result on 
the
whole archive, but it's worth trying.

Frédéric Bonnard
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXwDvrAAoJEGt0mPy5s1isGhEP/AwlaXn0BhLsFeW7E3L0H75X
B1gqGAbqGYNx4d8KX1uWX56khwwUh2Wt91ENNttYeUqQL5qm4juts03sRINnrUFD
x1kNJ7nrjTF4Ecc2sICLL/viA7wM95r+KDH4vuSwcr4eiQeTqOWp1zFuIOKlez71
l0cJCKZA+Y7Znz1/Q+53OnREk50rtrT/zf41qqMm7/ZIqXxec4fm+40i4BLAMxVT
RtQUp/xRY4sIwqTP/JlDN1PuIq1HqW992j09C1tBb3Kle/WNo/efG4q3Z9uCi9wn
oFbmrnQO9z757G04nyMsy+u9AetHUeu9JFEYxErXXvZvH/j5JSY7Gd+tqIrQqrHY
bNilGAhFFUsL/1cOB6InohAaj+aIwfzoxiDx9KHV7qiP/TKJONZgs83UCo9AUH+M
kSBuLRt/+xP9yKTIBuQb8G52EoXkH1xnJEE6KUfpEwCeee9lifoNvyabEg+/Hs0j
DKSuS0YXA+tikeEP09m4EbTA8g213TrbvPfojG37ODsOVsZ7IxmFrMvPuDUfZICz
1zJ+olgTr1Ym/WpbSBDbklrtEHXc/Z//lyUTl98Mksn1QT+/Sq1QbiSY7wKqE7ky
PgDLtkjnmF6xO+zQ6/oQJjf8994q6SNQ9yFkkPq1Z15AeqWH83FlIV5zkXJizWzN
42VSValqXtOHkpuLr9Zb
=uobB
-END PGP SIGNATURE-

RE: Porter roll call for Debian Stretch

[Dejan Latinovic]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretch release (est. end
of 2020):

For mips, mipsel and mips64el, I
 - can test all packages on this architecture on different hardware
   (I have access to different MIPS boards)
 - detect toolchain issues and bring it to the attention of toolchain
   maintainers whom we already have contact to,
 - triage arch-specific bugs
 - fix arch-related bugs

I am not a DD/DM.

Dejan Latinovic 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJXwCyhAAoJEDMjygTNXW5pdSkH/01mG18xVhNxmAoRSwv45ZsQ
V3GnUpKoUNBiANO0JHG/5T2AIKE/bDQP5atkNdbH6OaawYnTjK807er0oNaBQNtV
r0eSzJGCnF2+LQGxg8FJABRhSu+e8+TdoXgVTYodq3w/joGRPh0KqA37NtvKrlKl
7rqgJpbvDmfHrlCyZANlntVO+90FKZSbU543K0JHR0lMtL3uv7jmGN68rRTgQ+7r
nkLQO1BuMeZcXT1bc8XavatRS5P/HrUlBC83PRka+OziornHrYH/FzLrCGDjYKAq
KpyvOFkVgtCmdeh3EVYE6vADSecshD2uVkw19TQepYURk699hNPEGySABbm+KHg=
=XAXS
-END PGP SIGNATURE-

Re: [Pkg-rust-maintainers] Plan for updating (hypothetical future) firefox-esr versions in stable with changed build-deps?

[Ximin Luo]

+pkg-mozilla-maintainers

Julien Cristau:
> On Fri, Aug 26, 2016 at 06:59:20 +, Angus Lees wrote:
> 
>> Dear SRMs,
>>
>> My understanding is that Debian's new-ish plan is to update firefox-esr
>> versions in stable when there is a security update and the firefox-esr
>> upstream support window for the previous version has expired.
>> What is the plan for handling any new build-deps this new firefox-esr
>> release might require, and how will they also be merged into the existing
>> stable release?
>>
> I would expect firefox to bundle rustc, if needed, rather than relying
> on an external not-in-stable package.  But I'm just a bystander, and the
> actual plan is in the hands of the firefox maintainer(s) and security
> team, not the release team.
> 

(shall I drop debian-release@ off this thread?)

If Firefox bundles rustc, it would also have to bundle llvm. This is quite a 
lot of code to be bundling, almost doubling the source size. It would also 
increase its build time 4.5x, from ~1 hour to 4.5 hours (on a fast buildd 
machine [1][2][3][4]; my own machine is about 2x as slow).

rustc and llvm-3.8 will be in the next Debian stable, which is quite soon. And 
if I understood correctly, the future Firefox-with-rust build will use stable 
releases of rustc. These are released every 6 weeks, roughly on the same 
schedule as firefox-esr updates. The LLVM requirements stay the same across 
multiple releases.

I think it would be not much effort to keep backporting rustc to Debian stable 
to keep up with firefox-esr. rustc does not have other strictly-versioned 
dependencies apart from LLVM, so the backporting work would be minimal.

(cargo is harder, but it's also much smaller and quicker to build, so I think 
it's less of a problem to bundle that. Also right now Firefox-with-rust would 
be using cargo nightly; I don't know yet if they have plans to change this.)

X

[1] 
https://buildd.debian.org/status/fetch.php?pkg=firefox=arm64=48.0-1=1470231782
[2] 
https://buildd.debian.org/status/fetch.php?pkg=rustc=arm64=1.10.0%2Bdfsg1-3=1469947147
[3] 
https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-3.8=arm64=1%3A3.8.1-9=1471437328

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Re: Plan for updating (hypothetical future) firefox-esr versions in stable with changed build-deps?

[Mike Hommey]

On Fri, Aug 26, 2016 at 11:39:20AM +0200, Julien Cristau wrote:
> On Fri, Aug 26, 2016 at 06:59:20 +, Angus Lees wrote:
> 
> > Dear SRMs,
> > 
> > My understanding is that Debian's new-ish plan is to update firefox-esr
> > versions in stable when there is a security update and the firefox-esr
> > upstream support window for the previous version has expired.
> > What is the plan for handling any new build-deps this new firefox-esr
> > release might require, and how will they also be merged into the existing
> > stable release?
> > 
> I would expect firefox to bundle rustc

I hope you're joking.

Mike

Re: Plan for updating (hypothetical future) firefox-esr versions in stable with changed build-deps?

[Julien Cristau]

On Fri, Aug 26, 2016 at 06:59:20 +, Angus Lees wrote:

> Dear SRMs,
> 
> My understanding is that Debian's new-ish plan is to update firefox-esr
> versions in stable when there is a security update and the firefox-esr
> upstream support window for the previous version has expired.
> What is the plan for handling any new build-deps this new firefox-esr
> release might require, and how will they also be merged into the existing
> stable release?
> 
I would expect firefox to bundle rustc, if needed, rather than relying
on an external not-in-stable package.  But I'm just a bystander, and the
actual plan is in the hands of the firefox maintainer(s) and security
team, not the release team.

Cheers,
Julien

stretch-ignore? [was: Re: scilab is marked for autoremoval from testing]

[Sylvestre Ledru]

Hello

Can we consider a stretch-ignore for this issue?
We released squeeze, wheezy and jessie with this issue. And it is not
100% clear that it is non free code.

merci
Sylvestre


Le 20/08/2016 à 06:39, Debian testing autoremoval watch a écrit :
> scilab 5.5.2-2 is marked for autoremoval from testing on 2016-09-18
>
> It is affected by these RC bugs:
> 749833: scilab: Scilab include non-free codes
>
>

Plan for updating (hypothetical future) firefox-esr versions in stable with changed build-deps?

[Angus Lees]

Dear SRMs,

My understanding is that Debian's new-ish plan is to update firefox-esr
versions in stable when there is a security update and the firefox-esr
upstream support window for the previous version has expired.
What is the plan for handling any new build-deps this new firefox-esr
release might require, and how will they also be merged into the existing
stable release?

Firefox upstream is discussing how things will work once a (part) of
Firefox build-depends on the Rust compiler (rustc.deb).  Rust has strong
backwards guarantees, but is otherwise rapidly evolving.  It is highly
likely that a newer upstream codebase will require a newer rustc, and I'm
wondering what the implications for our rustc packaging might be if we have
to plan for a newer rustc to be merged into an existing stable release.

I feel like I read the answer to this once before, but haven't been able to
find it described anywhere.  A pointer to an existing doc would be most
welcome.

 - Gus