micah: > Chris Knadle <chris.kna...@coredump.us> writes: > >> Not yet, no. Looking at the build logs for mumble, I want to wait for the >> non-release architectures to have a build attempt, and some of them are >> still in Dep-Wait. >> >> What happened is that after the gcc5 transition was thought to be completed, >> zeroc-ice was still unpatched, so the build was still broken. [And in >> between the gcc-5 transition happened for Stretch.] zeroc-ice has been >> fixed now (by the release team), so mumble finally builds again... but not >> all the architectures have gotten it yet. > > Ok, thanks for the update, sounds reasonable to me!
The build logs for mumble 1.2.8-2+b1 on 6 of the non-release architectures haven't changed in a few days; mumble 1.2.8-2+b1 should be migrating to Stretch in a day or so, and at that point it's unclear how long I should wait further for the non-release architecture builds. >> I'm currently updating my 1.2.10-1 prepared upload for Debian with a patch >> for #787384, which I just did for the package in my repo only for Sid, >> because the new zeroc-ice hasn't transitioned to Stretch yet AFAIK. > > The reason I'm really interested in this is because of the PFS cipher > support. Unfortunately, it seems like this isn't particularly useful > unless things are built from the git head at the moment, and maybe that > support isn't even finished. It would be great if this could be brought > into the debian packages (even if it might need to be done before 1.3 is > released), see https://github.com/mumble-voip/mumble/issues/1811 I'm really interested in mumble in terms of encryption/privacy/integrity too, so I'd love to get PFS support but in reading the bug it looks like that's not possible for now. Upstream has specifically requested I only release the stable 1.2 builds (the non-snapshot+cherry-pick-patches release for wheezy that Ron Lee made has been particularly painful for upstream) and avoid uploading any of the 1.3 "snapshot" builds until they release a stable version, and #1811 above states that the mumble 1.2 releases are bound to Qt 4... and sounds like Qt 4 can't do PFS. Mumble upstream also have some Qt 4 patches to add TLS 1.1 and 1.2 support, but the way they work is to redefine QSsl::TlsV1 to mean "TLS 1.0 or later" and they don't recommend upstream distributions try to use these patches. This is explained in: http://blog.mumble.info/mumble-1-2-9/ The only good news is that with the 1.2.10-1 release I'm about to upload, the sslCiphers can be specified in the mumble-server.ini file. [That's probably important enough that I should add a note about this to the NEWS file.] BTW: in the "Advanced" settings under "Network" in the mumble client you can use "Force TCP mode" so that mumble could be used over Tor and then starting mumble in a terminal with 'torify mumble'. [That works! :-)] Re: integrity: a while ago I changed the the debian/watch file to have uscan check OpenPGP signatures of the upstream releases. And with 1.2.10-1 I'm switching debian/rules to 'dh' in an effort to get reproducible builds. >>> I'd really like this available as a jessie backport, so I'd love to see >>> it transition soon! >> >> I'm not pleased with the way backports currently work; bugs for packages >> from a backport aren't supposed to get reported to the normal BTS but >> instead a [debian-backports] mailing list. That's commonly confusing for >> both users and maintainers, and the result is that users report the bug to >> the BTS and maintainers have to close those reports and tell those users to >> report the bug to a mailing list. :-( This also recently came up >> concerning the PPA/bikesheds plan because it sounds like that's likely to >> have the same issue with BTS integration. > > This is a problem with the bug reporting path for backports, I > agree. However, I dont think that this particular bug means that > backports aren't useful, in fact they are incredibly indispensable for > us, just that the bug reporting path is a bit annoying. I dont think > that this should preclude backports from existing. I agree that having backports available is very important, I'm just not sure what advantage there is for a maintainer in having them at backports.debian.org. Right now backports.d.o is treated as an external repository as far as the BTS is concerned, and AFAIK that's what's going to happen with the PPA/bikesheds too, as well as all other external repos. In talking with several DDs at DC15 it's quite clear that external repos are the only way that an actual "PPA" implementation is ever going to happen. What I see some external repos do is add a "Bugs: <email_address>" line to the debian/control file for the source package (but not the binary packages), but AFAICT the bug reporting tools don't use this, and there is no Bugs: field listed for the control file in the Debian Policy Manual. I guess it's time to try to discuss this on -devel, -qa, -policy, -project, etc because we need a better way of dealing with this. >> However... in the meantime if you want a mumble 1.2.10 package for Jessie I >> have one available on my own repository here, which you're free to use: >> >> http://debian-packages.coredump.us > > thanks, I used these to test things out, the packages seemed to work > well for me on jessie. Cool. I'll be keeping those up-to-date. -- Chris -- Chris Knadle chris.kna...@coredump.us
