Bug#688772: gnome Depends network-manager-gnome
On Friday, October 12, 2012 14:38:07, Ian Jackson wrote:
> Don Armstrong writes ("Bug#688772: gnome Depends network-manager-gnome"):
> > On Fri, 12 Oct 2012, Ian Jackson wrote:
> > > Why do you think the gnome metapackage depending on, rather than
> > > recommending, wicd, is a good idea?
> >
> > The primary case of NM breaking things is when it's installed with
> > wicd, AFAICT. The other cases of NM breaking things are RC bugs in NM.
>
> There are no other competitors to wicd and n-m then ?
'apt-cache search "network manager"' also comes up with nova-network which is
a network manager for OpenStack, which I think is Cloud related, but I'm not
familiar with it. Here's the relevant portion of the description:
This package equips a system to function as a network node. This
service is responsible for managing floating and fixed IP addresses,
DHCP, bridging, and VLANs, and in some cases acts as a gateway.
Different networking strategies can be accessed by setting the
network_manager flag to FlatManager, FlatDHCPManager, or VlanManager
(the default).
> > > For example, consider the position of someone who has deliberately
> > > removed n-m in squeeze, and is using ifupdown or running ifconfig by
> > > hand or whatever, and upgrades to wheezy. This still gives them n-m
> > > back. That's not respecting their previous choice to remove it.
> >
> > Right, but if they get NM back, and nothing breaks because of it,[0]
> > it's just the same as any other package being installed by a meta
> > package. They've wasted some disk space, and they've got another
> > program running, but everything continues to work.
>
> And you're saying nothing will break because in the case where they
> have wicd, n-m won't be installed because of the alternative. And in
> the case where they don't have wicd "there are no such bugs that
> aren't rc".
>
> Are we sure that all these rc bugs are going to be fixed and not
> downgraded at the last moment ? Are we sure that we will find them
> all, for that matter, before the release ?
>
> Given the very strong insistence by n-m's proponents that these bugs
> aren't even real, in many cases, it seems more likely that n-m will be
> released in wheezy with infelicities which will be argued by the gnome
> maintainers to be not bugs, or not rc, or someone else's fault.
>
> For example, if I want to use ifupdown then I probably don't want n-m
> to bring up even interfaces which exist but which I haven't mentioned
> in /etc/network/interfaces - but managing those interfaces is
> precisely the point of n-m. So I'm cast back into "install n-m but
> disable it", which is clearly inferior.
>
> The result is surely going to be more friction between users who find
> n-m doesn't work for them, and developers who insist on forcing n-m on
> them.
I keep thinking about this in the context of laptops, and forgetting the
context of "traditional desktop boxes" and servers. In the context of either,
it's common to want to install Gnome without any wireless manager installed
and use ifupdown "just like with any other server" -- and specifically not
install n-m due to previous bad experiences people have had with it, or to
have trouble figuring out how to configure n-m for a static IP if they aren't
able to remove it. [It can do it, but is apparently not intuitive.]
There are a couple of people at my local LUG that run Gnome on their server
(usually on Ubuntu). I've overheard a few discussions about the difficulties
of removing n-m in this context, and the advice given to the server owner
generally ranges between "remove n-m -- it's worth it" to "you might as well
configure n-m for a static IP, because the system will fight you on removing
it too much".
I thought running Gnome3 on a server was a crazy idea until I asked about it;
the basic premise is that the server then has a similar interface as the
traditional Desktop, and allows for running GUI administration programs.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: Bug#691098: unblock: mumble/1.2.3-349-g315b5f5-2.1 [pre-approval request]
On Monday, October 22, 2012 07:39:24, Julien Cristau wrote: > On Mon, Oct 22, 2012 at 13:35:09 +0200, gregor herrmann wrote: > > On Mon, 22 Oct 2012 12:30:34 +0200, Julien Cristau wrote: > > > > Package: release.debian.org > > > > Severity: normal > > > > User: release.debian@packages.debian.org > > > > Usertags: unblock > > > > > > > > I'd like to request a pre-approval for a future unblock of a > > > > not-yet-uploaded NMU of mumble. > > > > > > IMO the package needs to be in sid before we consider it. > > > > Thanks for your quick reply! > > > > I was under the impression that the release team prefers to assess > > the situation before an upload in more complicated situations, but > > I'm happy to upload the NMU to a DELAYED queue later today. > > I guess I don't consider this a complicated situation. Either the new > version is ok, or we release without mumble. Neither the current > version in sid nor the current version in wheezy are suitable anyway, > AIUI. That's correct. The "348"-1 currently in Wheezy will not build due to library changes in Wheezy, and the "349"-2 in Sid cannot communicate with the existing Mumble userbase. Thanks much. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#688772: gnome Depends network-manager-gnome
On Thursday, October 25, 2012 18:27:58, Michael Biebl wrote: > On 25.10.2012 22:47, Andreas Barth wrote: > > * Jeremy Bicha (jbi...@ubuntu.com) [121025 18:51]: > >> On 25 October 2012 12:17, Don Armstrong wrote: > >>> That said, if I'm wrong, and you believe that there is a compromise > >>> which would resolve the concerns raised beyond those already presented > >>> (status quo with/without release notes), now would be the time to > >>> present it. > >> > >> My proposal is to: > >> 1. Add a paragraph to the Release Notes with the one line command > >> people should use if they don't want NetworkManager running: > >> "update-rc.d disable network-manager" > >> 2. And cases where that doesn't work are RC. > > > > How would that prevent startup of n-m during upgrades from stable to > > next-stable? (Which could already present issues, especially if the > > system is remote managed) > > I've been discussing with jordi today about this issue. > > One idea that came up was to check wether wicd is in use (or for that > matter ifupdown), and then show a debconf prompt explaining the > situation, and letting the user chose if he wants to take over network > management by NetworkManager. > It would work similar to how we currently handle multiple installed > display managers, like gdm3 or kdm (btw, gdm3 is currently a hard > depends of gnome-core). > If the users choses no, we could disable the service via update-rc.d > disable, so the invoke-rc.d later on in postinst would not start NM. > > This would also help in situations where users install both wicd and > network-manager by accident, which usually doesn't really work well > since e.g. both spawn their own instance of wpa_supplicant. > > A more detailed reply will follow soon. This is a good suggestion, and one which I think would work around all of the breakage concerns I raised on this issue. Thank you for putting in the effort for coming up with this option. A tweak I'd suggest considering would be to reverse the logic of the test of when to show the debconf prompt -- because there are several possible tools for setting up networking like iwconfig, manually using wpa_supplicant, commands in rc.local, etc, such that trying to test for all of the specific situations of when to show the option might be frustrating to track down competely. What we /do/ know is that there are two known situations where the user does /not/ need to see the choice to disable N-M, which is A) when N-M is already installed and running, or B) when N-M is installed but disabled via update-rc.d I think this effectively reduces down to checking if N-M is already installed and prompting if it's not. Well, unless you also want to test if it's running to take into consideration the possibility that N-M could be locally installed outside of package management, in which also installing N-M as a package would be... weird. ;-) The last thing I'm wondering about are the concerns from the Gnome team about whether empathy or evolution would know if you're online -- which in this case means if they do if N-M is installed but not running. If they do then this solution would have that as an advantage. If it doesn't then (at least on the surface) this solution seems similar to N-M being a Recommends in the meta- gnome package such that it doesn't have to be installed. [I'm not bringing this up as an argument against choosing this solution because I think the solution would work, but rather I'm trying to objectively evaluate what the effect this solution would have and how it compares to other possibilities.] Thanks again. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#693348: mumble-server: pidfile should use /run directory instead of /var/run
Hi, Pitchum. On Thursday, November 15, 2012 12:16:48, pitchum wrote: > Package: mumble-server > Severity: normal > > The mumble-server.ini shipped contains a reference to /var/run: > pidfile=/var/run/mumble-server/mumble-server.pid > > I recently noticed that many packages were migrating their configuration > to avoid using /var/run directory and others. > I don't know the real reasons for that choice but I just wanted to make > sure you're aware of this. > > The page http://wiki.debian.org/ReleaseGoals/RunDirectory#Overview > states that the use of /run "is a release goal for Wheezy". > I would be sad if mumble-server could not reach Wheezy because of that. I got notification from the PTS on this bug and I've had some discussion with Gregor Herrmann about it. Further down the same page linked to above states "It is not currently planned to require transition from /var/run and /var/lock for Wheezy.", so AFAICT this won't cause mumble-server not to be shipped with Wheezy. http://wiki.debian.org/ReleaseGoals/RunDirectory#Packages_using_.2BAC8-var.2BAC8-run_and_.2BAC8-var.2BAC8-lock Note that making the transition from /var/run to /run requires adding a versioned initscripts dependency. For more on that, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676560 Also concerning Wheezy, mumble-server 1.2.3-349-g315b5f5-2.1 has already transitioned to it, so things should be okay there AFAIK. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: Interoperability with speex patch
t; Celt 0.7.1 gives poor results at bitrates where both opus and speex shine. > > > dondelelcaro: I think we know that if we reenable the embedded > celt it will work as intended with existing clients. > > We do gain an extra possible dimension of interoperability. Unfortunately > that's not enough on its own to ensure it will work with other existing > clients and servers - either at all, or with acceptable results. Of the 19 other distributions that ship Mumble, all of them are compatible with CELT 0.7.1 (or will be -- Magia 2 has a bug because of library name mangling, so even though they ship a CELT 0.7.1 bundled library Mumble can't find the file -- this is being worked on to fix it) and I tested that (all but Magia 2) are currently interoperable. […] > And the SECCOMP sandboxed version of celt has been pushed upstream now. > The guy who worked on that sounds like he's pretty happy with it, but I > looked at the code and do worry that it's probably too big a change to > push into a stable release without more live testing, and probably a > few other pairs of eyes auditing it. It seems to be a good answer that > I don't totally want to take off the table, but probably not something > that could seriously be considered for wheezy proper without more people > taking an intense interest in it very soon. I also saw that show up in the upstream repo a couple of days ago, and it looks interesting. I've been too busy with Mumble testing to look at it closely, though. [1] http://opus-codec.org/ -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#675971: Tables of Mumble client compatability
At the same time I tested the two proposed patches for the "348" version of Mumble in Wheezy, I also took the time to test the top 25 free software distributions [as per distrowatch.com] to check for interoperability and what support those distributions were including. These tests used the "348"-1.1 patched mumble-server, and a amd64 Debian Sid host running "348"-1.1 patched for using bundled celt 0.7.1. Distributions were loaded into a VirtualBox VM; "Interop" makred as "Y" indicates that audio output was heard from the VM through the host while Mumble in the host had the mic muted. One notable oddity: the highest version of the CELT codec is 0.11.1, but Mumble reports CELT version 2.0.0 in Fedora 17 and Mageia 2, seemingly due to library filename renaming done in these distributions. Extra Celt CeltServer Distro version (mumble version) 0.7.1 Vers.+ Opus Interop Loopback -|-|--||---|| *Mint Debian 201204 (1.2.3-3)| Y | || Y |Y | *Linux Mint 13 (1.2.3-2ubuntu4) | Y | || Y |Y | *Ubuntu 12.04 (1.2.3-2ubuntu4) | Y | || Y |Y | Mageia 2 (1.2.3-2.mga2) [3]| | 2.0.0|| | [1] | Fedora 17 (1.2.3-7.fc17.1) | Y | 2.0.0|| Y |Y | openSUSE 12.1 (1.2.3-10.3.1) | Y |0.11.0|| Y |Y | *Debian Sid (1.2.3-349-g315b5f5-2) | | | Y | | [4] | *Debian Wheezy (1.2.3-348-g317f5a0-1)| Y | || Y |Y | *Debian Squeeze (1.2.2-6+squeeze1) | Y | || Y |Y | Arch Linux 2012-08-04 (1.2.3-5) | Y |0.11.0|| Y | [1] | *Ultimate 3.4 (1.2.3-2ubuntu4) | Y | || Y | [2] | *Lubuntu 12.04 (1.2.3-2ubuntu4) | Y | || Y | [2] | *Pear Linux 5 (1.2.3-2ubuntu4) | Y | || Y |Y | Sabayon Linux 9 (1.2.3-r2~0) | Y |0.11.0|| Y | [1] | *Zorin OS 6 (1.2.3-2ubuntu4) | Y | || Y |Y | Chakra 2012.07 (1.2.3-3) | Y |0.11.0|| Y |Y | *Bodhi 2.0.1 (1.2.3-2ubuntu4)| Y | || Y | [1] | *Snowlinux 2 "Ice" (1.2.2-6+squeeze1)| Y | || Y |Y | *Snowlinux 2 "Cream" (1.2.3-2ubuntu4)| Y | || Y |Y | Gentoo 12.1 (1.2.3-r2) | Y |0.11.0|| [6] | [1] | Vector Linux 7.0 (1.2.3-i586-2vl70) [5]| Y |0.11.0|| Y |Y | *CrunchBang 10 (1.2.2-6+squeeze1)| Y | || Y |Y | *SolusOS Eveline 1.1 (1.2.3-3solus1) | Y | || Y |Y | *Knoppix 7.03 DVD (1.2.3-348-g317f5a0-1) | Y | || Y |Y | -|-|--||---|| *Debian Wheezy "348"-1.1 bundled-celt [7]| Y | || Y |Y | *Debian Wheezy "348"-1.1 celt-lib [7]| Y | || Y |Y | -|-|--||---|| CentOS 6.3 (not in distro) Slacko Puppy 5.3.3 (not in distro) *Lucid Puppy 5.2.8 (not in distro) *PCLinuxOS 2012.02 (not in distro) FreeBSD 9 (not in distro) Slackware 13 (not in distro) Fuduntu 2012.3 (not in distro) * Distro is Debian-based + Extra CELT codec version available as reported by Mumble [1] Audio output did not work, so could not test server loopback [2] Audio did function, but could not get audio output working in Mumble [3] The bundled libcelt 0.7.1 in Mageia 2 for Mumble has a known bug related to library filename mangling which is why it is not interoperable. The Mageia QA team are working to fix it. https://bugs.mageia.org/show_bug.cgi?id=6581 [4] Server loopback for "349"-2 only works if all connected clients support the OPUS codec [5] Mumble is only in the "testing" repository in Vector Linux [6] It took 3 full days to get a Gentoo base system and KDE4 installed using the standard instructions, after which X wouldn't start; Mumble was tested via ssh X forwarding without audio [7] "348"-1.1 = 1.2.3-348-g317f5a0 with proposed patches -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#682010: [mumble] Communication failures due to CELT codec library removal
Ron -- Can you please let me know the procedure for how to verify the orig tarball for the "349" version in Debian Sid? Up to and including the "348" version of Mumble in Wheezy that Patrick Matthäi had been packaging, the tarballs clearly came from the upstream snapshots located at [1], so those are simple to verify via 'diff' directly. But the "349" version in Debian Sid doesn't come from there; instead the tarball is somehow created from the upstream Git repo. 'pristine-tar list' doesn't come up with any tarballs, so in a local clone of the upstream Git repo I did a checkout on commit 315b5f587910983d764955f456fe64e696a786cc that the "349" orig tarball seems to be based on, a checkout of commit 43a04a7e813d3e420409c5465b71af148e779717 in your Git tree that the "349" orig tarball seems to be based on -- but when I try to compare the directories I see a bunch of files that are only in the upstream directory or vice-versa. So would you mind giving me a pointer for how to verify the tarball? Thanks. [1] http://mumble.info/snapshot/ -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Tuesday, August 14, 2012 11:36:33, Ian Jackson wrote: […] > 13. The mumble maintainers, with appropriate help from other > interested parties, should prepare an upload of mumble for wheezy > with >- embedded celt 0.7.1 enabled >- no other version of celt enabled >- whatever other release-critical bugfixes they consider > relevant (subject to any appropriate discussion with the > release team as necessary) >- closing #675971. Option 1: I've prepared another version of Mumble based on the mumble-1.2.3-412-g6c9694d release snapshot on August 3rd. This pacakge is built as described above, and also supports Opus via the Debian opus system library which uses Opus version 0.9.14. I've tested: - communication via Opus with the "349"-2 version in Sid - communication via Opus with another version of the "412" pacakge that uses the embedded 0.9.8 version of Opus that ships with the Mumble upstream source - communication via Celt 0.7.1 with several other clients Option 2: Using the mumble-348-fixes-embedded patch I sent on Aug 1st, and upload a new version of "348" that's in Wheezy. [Needs modification to add a Closes: #675971 in the changelog.] I haven't yet gotten any feedback on the patch. Related question: Can a DD upload a package to Sid with a lower version number than what is currently in the archive? Option 3: Manipulate the "349"-2 source in Sid, fix it, and upload a "349"-3. I was investigating this in order to minimize the diff necessary, but I'm not sure what all of the implications are of the modifications done to the "orig.tar.gz" tarball compared to the upstream repo it's based on. Some of the changes simply look like they might be innocuous autoconf stuff added, but there are also some scripts and build files removed. File containing the list of differences attached. This option would inolve reverting one Git commit in order to remove debian/patches/10-use-celt-guard. -- Chris -- Chris Knadle chris.kna...@coredump.us # Steps to repeat results above: # From local clone of upstream Mumble git repo, make tarball of the "315b5f5" commit from 2012-05-31 06:46:56 git archive --prefix=mumble-1.2.3-349-g315b5f5/ -o mumble-1.2.3-349-g315b5f5-upstream.tar 315b5f587910983d764955f456fe64e696a786cc # make a new directory somewhere, untar 'upstream' tarball and rename # directory with a "-upstream" added, untar "orig" mumble tarball and rename # with a "-sid" added, do a recursive diff on the two directories diff -u -r ./mumble-1.2.3-349-g315b5f5-upstream ./mumble-1.2.3-349-g315b5f5-sid $ colordiff -u -r ./mumble-1.2.3-349-g315b5f5-upstream ./mumble-1.2.3-349-g315b5f5-sid # Note: "Only in .. upstream" means the file is missing in the Sid version # and "Only in .. sid" means the file doesn't exist in the upstream version # Not in the Sid source tarball: Only in ./mumble-1.2.3-349-g315b5f5-upstream: 3rdPartyLicenses Only in ./mumble-1.2.3-349-g315b5f5-upstream/celt-0.11.0-build: win32 Only in ./mumble-1.2.3-349-g315b5f5-upstream/celt-0.7.0-build: win32 Only in ./mumble-1.2.3-349-g315b5f5-upstream: doc Only in ./mumble-1.2.3-349-g315b5f5-upstream: Doxyfile Only in ./mumble-1.2.3-349-g315b5f5-upstream: .gitignore Only in ./mumble-1.2.3-349-g315b5f5-upstream: .gitmodules Only in ./mumble-1.2.3-349-g315b5f5-upstream/icons/flags: readme.txt Only in ./mumble-1.2.3-349-g315b5f5-upstream/icons: g15helper.ico Only in ./mumble-1.2.3-349-g315b5f5-upstream/icons: mumble.osx.installer.png Only in ./mumble-1.2.3-349-g315b5f5-upstream/icons/publicdomain: readme.txt Only in ./mumble-1.2.3-349-g315b5f5-upstream/icons/tango: README Only in ./mumble-1.2.3-349-g315b5f5-upstream: installer Only in ./mumble-1.2.3-349-g315b5f5-upstream/macx/overlay: avail.h Only in ./mumble-1.2.3-349-g315b5f5-upstream/macx/overlay: avail.pl Only in ./mumble-1.2.3-349-g315b5f5-upstream/macx: scripts Only in ./mumble-1.2.3-349-g315b5f5-upstream/opus-build: Win32 Only in ./mumble-1.2.3-349-g315b5f5-upstream/plugins: mumble_plugin_win32.h Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: addban.php Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: binserver.pl Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: ermine.conf Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: git2cl.pl Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: glacier Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: idle.php Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: ListUsers.cs Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: mkflags.pl Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: mkini.sh Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: mklic.pl Only in ./mumble-1.2.3-349-g315b5f5-upstream/scripts: mkwr
Bug#675971: what should we be doing?
On Monday, June 18, 2012 22:59:40, micah anderson wrote: > Is the situation that all users that are at 1.2.3-348 and older can > speak to each other and all users that are at 1.2.3-349 and greater can > speak to each other, but >=349 cannot speak to <=348 users? I did some testing of Mumble Client/Server on versions in Debian to try to answer this. Notes: version "348" = 1.2.3-348-g317f5a0-1 "348" client includes libcelt0-0, mumble-server does not version "349" = 1.2.3-349-g315b5f5-1 "Yes" means "server loopback" worked correctly (ONE user on server) Server 348Server 349 Server 1.2.3-2+b2 Client 348Yes Yes Yes Client 349Yes YesNo > If so, is the intended plan for everyone to bump up to >=349? Based on this very minimal testing, I think that would work. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Wednesday, June 20, 2012 08:20:39 PM Chris Knadle wrote: > On Monday, June 18, 2012 22:59:40, micah anderson wrote: > > Is the situation that all users that are at 1.2.3-348 and older can > > speak to each other and all users that are at 1.2.3-349 and greater can > > speak to each other, but >=349 cannot speak to <=348 users? > > I did some testing of Mumble Client/Server on versions in Debian to try to > answer this. > > Notes: > version "348" = 1.2.3-348-g317f5a0-1 > "348" client includes libcelt0-0, mumble-server does not > version "349" = 1.2.3-349-g315b5f5-1 > "Yes" means "server loopback" worked correctly (ONE user on server) > > Server 348Server 349 Server 1.2.3-2+b2 > Client 348Yes Yes Yes > Client 349Yes YesNo > > > If so, is the intended plan for everyone to bump up to >=349? > > Based on this very minimal testing, I think that would work. ... however there's something else to consider -- version "349" is not available for all platforms. On the Mumble website (http://mumble.sourceforge.net) none of the platforms (including Linux) have that version advertised for it. From the appearance on the website, the latest "Stable" version advertised is 1.2.3a, and the "Developer snapshot" version is "361" (1.2.3-361-ga2a38360). -- -- Chris Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Thursday, June 21, 2012 00:57:23, Chris Knadle wrote: > On Wednesday, June 20, 2012 08:20:39 PM Chris Knadle wrote: > > On Monday, June 18, 2012 22:59:40, micah anderson wrote: > > > Is the situation that all users that are at 1.2.3-348 and older can > > > speak to each other and all users that are at 1.2.3-349 and greater can > > > speak to each other, but >=349 cannot speak to <=348 users? Additional testing. The newest client (349) in Debian without CELT support doesn't work with older versions of mumble-server in Debian -- but older versions of the client across several platforms seem to work with the newer versions of mumble-server in Debian. Notes: server "348" = 1.2.3-3480g317f5a0-1 in Debian "348" client includes libcelt0-0, mumble-server does not server "349" = 1.2.3-349-g315b5f5-1 in Debian client "361" = 1.2.3-361-ga2a3836 (Developer Snapshot for Windows) "Yes" means "server loopback" worked correctly (one user on server only) mumble Debian mumble-server versions client versions 1.2.2-6+squeeze1 1.2.3-2+b2 "348" "349" ---|--| Deb. Client "348" | Yes YesYes Yes | Deb. Client "349" |NoNoYes Yes | Win. Client 1.2.3a | Yes YesYes Yes | Win. Client "361" | Yes YesYes Yes | Mac Client 1.2.2 | Yes YesYes Yes | |--| I'm glad that newer versions of the server work with older versions of the client, and as such I no longer have a personal stake in the decision of whether Wheezy gets version "349" or not. The main issue I see is that the popular public mumble-server (murmur) servers seem to end up connecting using the CELT codec (which has issues) for which support for is removed in the "349" client in Debian Unstable (for good reasons). I don't personally use the public servers, but if "349" is shipped for Wheezy this will likely be frustraing for many, so at the least I suggest having a private repo around somewhere that contains version "348" to point people to if it becomes necessary. :-/ -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
I'm a bit dissappointed by the reply you got back to this suggestion, so I'm adding some thoughts concerning your idea. On Saturday, June 23, 2012 15:54:07, Michael Schmitt wrote: > Hi folks, > > I guess shipping both versions with wheezy is not a viable option? At > least I think that it would make sense. Disclaimer in the readme, > explanation of the situation, if a major security exploit does surface > (a mumble-client-crash is not a major security risk imho), remove that > second version (if there is no somewhat easy fix at that time). Call the > package mumble-client-buggy that conflicts with the "normal" client and > I guess all users can decide on their own if they want to be safe or > actually talk to other people. What you're proposing concerning adding a 'mumble-client-buggy' could technically be done /in theory/ and even occasionally has been in other packages; the packages 'gobby' and 'gobby-0.5' are an example. If you look these binary packages up, you'll see they have two different source packages too -- 'gobby' and 'gobby-infinote'. The reason these exist is that the two versions of the software are incompatable by design, and 'upstream' still offers both versions. Debian Wheezy is extremely close to being frozen in preparation for releasing the next version of Debian Stable -- a "buggy" package destined for the "stable" release would have to be justfied and would likely be rejected by the ftpmasters after upload if it couldn't be. Plus it sounds like there are several other issues to handle. These types of decisions are generally up to the maintainer of the package as to how to proceed. It's clear the maintainer for mumble is frustrated right now, because (IMHO) there isn't a clear path as to how to proceed here. Several options are possible, but nothing seems to exactly fit -- removing the CELT codec breaks communication with popular older mumble/murmur servers, leaving the codec in has security and support implications, making both packages available would require going through the NEW queue at the last minute and would additionally risk being rejected. Because of all these sticky problems, without a clear path to proceed if I were personally in the maintainer's shoes I'd probably take the "do nothing" option and release the current "348" version that has the libcelt0-0 codec that has issues but retains compatability with older popular mumble servers. I wouldn't /like/ this option though, because I'd have to support it for two years, and upstream isn't supporting the buggy CELT 0.7.1 codec at all. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Monday, June 25, 2012 04:27:20, Ron wrote: > On Sun, Jun 24, 2012 at 03:51:14PM -0400, Chris Knadle wrote: > > Because of all these sticky problems, without a clear path to proceed if > > I were personally in the maintainer's shoes I'd probably take the "do > > nothing" option and release the current "348" version that has the > > libcelt0-0 codec that has issues but retains compatability with older > > popular mumble servers. I see you've trimmed the last line from what I wrote, which fundamentally changes the meaning. > The so called "do nothing" option is far simpler than that. > The 348 version fails to build from source and so is undistributable. > Since you insisted on reopening this bug as RC, it, among others, ties my > hands and prevents updating that, and the actual logical conclusion is the > people who preferred "don't ship mumble in wheezy at all" look like getting > their wish now. What I /did/ was find a bug in the latest mumble client, found a bug report that matched the symtpoms but which was somehow closed without any explanation or fix, and reopened it. That was the correct action for me to take and if I hadn't done it someone else would have. > If people would rather write long rationalisations about how to pretend > the problem doesn't exist than Do Something to actually solve it and > create a viable future for maintaining this code, than logically, that's > probably even the correct outcome. I've already spent 12 hours testing several versions of both mumble-client and mumble-server on three platforms. This was intended to help both you and others. If this blame-laden email is your way of asking for further help, it's a piss poor way of doing it. I am willing to help further, but I'm most definitely not if you're going to continue giving me attitude. Learn to ask. Nicely. > To say I'm "a bit disappointed" by that would be an understatement, it > certainly makes a waste of the effort I've put in trying to find some > workable solution - but if nobody else cares enough than to say "just > close your eyes and ship it", then I don't see this being resolved in > any adequate way in the tiny amount of time remaining to do so. > > A month ago you might have been able to convince me of anything if I > saw people actually committed to Doing The Work needed to make that a > viable answer. But all I've seen is people saying "there is no problem > until patches magically appear to fix it", and outright refusing to be > the one who takes any responsibility for the now abandoned code. > > Now people are even saying they want other people to do double the work > and take on all the risk, so that they (and innocent others) can be > insecure without being interrupted from busily doing the nothing that > they themselves would rather be doing. I did not intend to suggest that packaging another version of mumble was correct for this case, but rather only that it has been done elsewhere and that it is up to the maintainer to choose the action to take. I felt this was necessary to explain to Michael because your reply to him was unhelpful to anyone, and I wanted to give him more helpful information. > If the obvious answer to that isn't obvious, then I don't know what > else to say. > > > People I've never heard of are going to need better evidence than some > dismissive handwaving to convince me to ignore the concerns of people > who I very much trust. When the person who has found more bugs in this > code than anyone else in the world expresses concern, it would be dumb > not to listen to them - when someone who has never even looked at the > code says "I don't see a problem", then ... well ... > I'm sure you can safely extrapolate from there. Right now the extrapolation I get is that trying to help you further is not a worthwhile use of my time. I'd appreciate it if that would change. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
It seems unusual to CC ftpmaster in a bug report, but keeping the CC as this is a reply to one that went there. On Sunday, June 24, 2012 21:36:28, Michael Schmitt wrote: > Am 24.06.2012 21:51, schrieb Chris Knadle: > > On Saturday, June 23, 2012 15:54:07, Michael Schmitt wrote: .. > > I'm a bit dissappointed by the reply you got back to this suggestion, so > > I'm adding some thoughts concerning your idea. > > *Many* thanks for taking my mail seriously, which the maintainer > obviously did not. You're welcome. ... > > Because of all these sticky problems, without a clear path to proceed if > > I were personally in the maintainer's shoes I'd probably take the "do > > nothing" option and release the current "348" version that has the > > libcelt0-0 codec that has issues but retains compatability with older > > popular mumble servers. I wouldn't /like/ this option though, because > > I'd have to support it for two years, and upstream isn't supporting the > > buggy CELT 0.7.1 codec at all. > > Afaik, wrong. Upstream does support (as described above) both celt > incarnations (built-in). And only the current debian package does not > include celt (and the external lib was removed). Just to recap: Ron described communicating with upstream in which they did not commit to supporting CELT 0.7.1, which Ron said is bitstream incompatable with other versions of CELT. i.e. what is reported is that only a specific version of CELT is allegedly not getting support upstream. A logical thing to try from here, if you want to give this a shot, would be to attempt to build the current upstream version from source and see if the current version of CELT that it includes will work with older versions of mumble-server, many of which are public. If you manage to get it to build and run, in the configuration select "Advanced" on the bottom left of the configure window, then in the "Audio Output" section under "Loopback Test", try the "server" setting and see if you can hear yourself through the server. This would specifically be helpful in verifying firsthand if the newer versions of CELT that ship with upstream Mumble will work with older versions of mumble-server. > I wonder how other distros will handle this... > > In general, I had a few words with some mumble devs on IRC a few days > back. Common thinking there was, removing celt is not a wise option, no > real security exploits known yet, mumble will support celt for the > foreseeable future (1 - 2 years). Do you know if CELT still the default codec? -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
Greetings Nicos. Thank you for your informative email. On Tuesday, June 26, 2012 09:08:45, Nicos Gollan wrote: > On Monday 25 June 2012 23:26:50 Chris Knadle wrote: > > On Sunday, June 24, 2012 21:36:28, Michael Schmitt wrote: ... > > If you manage to get it to build and run, in the configuration select > > "Advanced" on the bottom left of the configure window, then in the "Audio > > Output" section under "Loopback Test", try the "server" setting and see > > if you can hear yourself through the server. > > > > This would specifically be helpful in verifying firsthand if the newer > > versions of CELT that ship with upstream Mumble will work with older > > versions of mumble-server. > > The client tells the server which versions it supports. If it doesn't admit > to supporting 0.7.1, the server will effectively assume that it does > anyway, to retain a stable codec negotiation and to keep misbehaving > clients from ruining things for everyone. That mechanism is supported by > all 1.2 server versions (plus or minus a few details, but if you're on >= > 1.2.3, you should be golden; using 1.2.2 as a server, especially without a > few patches, may not give you the stable operation you'd hope for). > > In a further step, the server makes sure to negotiate a codec that's > supported by all clients "within listening range". > > To my knowledge, that mechanism will work with all server versions that are > not a stupid thing to use. The only thing new to the party is Opus, which > requires further protocol support on the server side. > > So effectively, as long as your client advertises only codecs it really > supports and has the baseline codec, server echo will work, as will > communication with other people. I'm assuming all of the above is true under normal circumstnaces when CELT 0.7.1 support is included. However with libcelt0-0 removed, mumble version 1.2.3-349-g315b5f5-1 is unable to communicate via server loopback to the majority of the public mumble servers (at least in the United States) all of which seem to have versions >= 1.2.3. None of the server loopback tests with public servers I tested with worked reliably. Tests shows that communication with this server works _sometimes_: 1.2.3-361-ga2a3836-ermine Server:"0 FREE OrangeRed Mumble West 0" (Codec Opus) later retests fail and show Codec: None Tests failed with these servers: 1.2.3-1~ppa1~lucid Server:"0- MumbleBoxes.com Demo Server - Atlanta #1" 1.2.3-273-g0f4314e-ermine Server:"0- FREE OrangeRed Mumble Central 0" 1.2.3 (Win) 1.2.3 Server:"Breakpoint Lobby" 1.2.3-1ubuntu6.1Server:"Luke's Server" The intermittency of server loopback communication with the OrangeRed server above is interesting, and likely has to do with the protocol negotiation to find a protocol that all connected clients support. :-( Unfortunately I've come to the conclusion that with CELT 0.7.1 support removed, the user experience with public servers is dismal. Since CELT 0.7.1 support is assumed rather than advertised [based on what you've described], communication without support for it will be unreliable, at best. > > > In general, I had a few words with some mumble devs on IRC a few days > > > back. Common thinking there was, removing celt is not a wise option, no > > > real security exploits known yet, mumble will support celt for the > > > foreseeable future (1 - 2 years). > > > > Do you know if CELT still the default codec? > > For the 1.2 series, it's supposed to be. Opus is going to be supported, it > will be used if all clients support it, and there are knobs in place to > make a server prefer it even at the disadvantage of older clients, but the > baseline codec will be assumed for a long time to come. > > Hope that clears things up a bit Yes, it does -- very much so. Thanks very much. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Wednesday, June 27, 2012 04:57:13, Ron wrote: > On Wed, Jun 27, 2012 at 08:59:57AM +0200, Nicos Gollan wrote: ... > > So for reliable support, the safer bet would be to wait for 1.2.4; until > > then, it's under development and may break in weird ways. > > Which is not to say this part might not be true. But only because of bugs > that purely exist in mumble alone, not any other cause. I personally don't > see how making it artificially hard for people to test it is going to make > it stop breaking "in weird ways" any sooner ... but ymmv. > > > Maybe people should look at the Mangler package and ventrilo if they really > just want something that actually works today and they aren't concerned > about the compromises they need to make to get that - which seems to be > the ongoing theme here. > > They managed to get that working with opus in just a couple of days, and > with none of the ED grade drama that we seem to be seeing here. That cuts both ways. Okay... What do you believe the correct action to take for Mumble? What could you use help with? I've had a look at the mumble source package in git. On Sid, after doing a checkout of v1.2.3-348-g317f5a0-1 the package is not buildable right now because a dependency on libcelt-dev which has been removed. On Wheezy, after doing a checkout of v1.2.3-348-g317f5a0-1 I'm unable to get the package to build because there's no source tarball and debuild reports that it can't build source format 3.0 (quilt) if the source tarball is missing. Do you have the source tarball for 1.2.3-348-g317f5a0 at a web accessible location somewhere? -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Wednesday, June 27, 2012 08:59:25, Chris Knadle wrote: ... > On Wheezy, after doing a checkout of v1.2.3-348-g317f5a0-1 I'm unable to > get the package to build because there's no source tarball and debuild > reports that it can't build source format 3.0 (quilt) if the source > tarball is missing. Do you have the source tarball for 1.2.3-348-g317f5a0 > at a web accessible location somewhere? nevermind, 'apt-get source mumble' gets the necessary tarball. I've re-read what you had written to at least try to understand what options there there might be. If possible, I'd like some clarification on what the "zero-ice snafu" in the following statement means: On Tuesday, June 19, 2012 04:58:38, Ron wrote: ... > Given the general state of things, including the zeroc-ice snafu of > breaking ABI to "fix the build with gcc 4.7", and the time we have > remaining before the freeze, I'm having a very hard time seeing how this > might possibly be a viable release candidate for Wheezy anyway at this > stage. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680884: [p0f] Please update to v3; v2 marked "do not use"
Package: p0f Version: 2.0.8-2 Severity: wishlist Please upgrade p0f to version 3 (if possible). Upstream has marked versions <= 2 as "do not use". http://lcamtuf.coredump.cx/p0f3/releases/ The particular use case I have for p0f v3 is for an addon for Exim4. I can't send the URL here, as the domain is currently in the URIBL blacklist. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: Bug #675971 closed, but is not fixed
Ron, thank you for your efforts and for uploading a new version of Mumble, 1.2.3-349-g315b5f5-2. I just tested this version of the client with mumble-server version 1.2.3-2+b2 -- and unfortunately server loopback communication does not work, even when nobody else is connected to the server -- information shows "Codec: None". Bug #675971 is about the disabling of a default CELT codec which breaks communication with any server that doesn't have the Opus Codec available, as well as with servers that do have Opus available but which has another Mumble client connect which doesn't. This still seems to be a problem with this new upload, so I feel that this grave bug is being closed incorrectly, unless there's an explanation. Neither the changelog.Debian.gz nor the NEWS.Debian.gz discusses the impact of the CELT library removal, which was another issue Nicos reported on June 5. I'm not going to bother re-opening the bug again [even though I feel it would be correct to do so], because I don't think that would help you. But simultaneously I strongly suggest updating the NEWS.Debian.gz to warn users of the impact of the CELT Codec removal [and thus making another upload], because the removal of the codec is a non-upstream decision which has a large impact on the usability of the package. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680884: [p0f] Please update to v3 [use case]
The particular use case I have for p0f v3 is for an addon for Exim4 at the following URL: http://dist.epipe.com/exim/ Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: Bug #675971 -- "wontfix"?
Marking this bug as "fixed" is incorrect for this case because the issue remains, and will mean that when someone else finds the bug they will reopen it -- which is the correct thing for them to do. If this the remaining parts of this bug are "not considered bugs", or if the intention is not to fix these bugs because they were created by a necessary design choice (of removing CELT), then I think the right thing to do is to give a reasonable explanation that a potential bug reporter can understand, and to mark the bug "wontfix". That way when others run into the problem and find the bug report, they'll learn that the package has this issue by design. If the bug is marked "fixed" rather than "wontfix" then I intend to reopen it, by the same reasoning. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: Bug #675971 Reopening, preparing tech-ctte bug
reopen 675971 found 675971 1.2.3-349-g315b5f5-2 thanks Ron, as it appears we have an intractible technical dispute, I'm preparing a summary of the dispute for referring it to the Debian Technical Committee. The committee first has the recommendation that parties in the dispute attempt to resolve the problem via constructive discussion to understand the other person's point of view. If this fails, then they recommend that a summary of the dispute is created, preferably which is agreed upon by all parties. Please let me know how you would like to update your point of view. Likewise for bug reporters: if you would like additions or changes to the list I've created below, let me know. It would be helpful to refer to the following page for instructions concerning the Debian Technical Committee before sending updates. http://www.debian.org/devel/tech-ctte Point of view of bug reporters: - In recent changes in the Mumble package, a CELT audio Codec has been removed which is a base assumption used by Mumble servers, causing audio connections to fail for many commonly found Mumble server versions outright - On newer Mumble server versions, the audio connection fails if another client connects that does not have another audio Codec available that all other connected clients can use. - The newest -2 upload contains this issue. - The bug is repeatedly being closed and marked as if it was fixed. Point of view of the maintainer (as understood by this bug reporter thusfar): - Someone said the CELT library contains code that could potentially crash - It was decided to remove the CELT library as to not burden the security team - Therefore this isn't a bug Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: Bug #675971 [mumble] Communication failures due to CELT codec library removal
7;t a bug, so it should be closed, and there is no need to warn users of the package I've subscribed to the tech-ctte mailing list, so I don't need to be CCed. We're prepared to accept any possible outcome the TC deems appropriate. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Bug#682010: [mumble] Communication failures due to CELT codec library removal
7;t a bug, so it should be closed, and there is no need to warn users of the package I've subscribed to the tech-ctte mailing list, so I don't need to be CCed. We're prepared to accept any possible outcome the TC deems appropriate. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Bug#675971: Don't put Bug # in subject line
Note to future bug reporters: Apparently putting the Bug # at the start of the subject line will cause submissions to the BTS to go to the bug report with the same # rather than the package listed at the top of the body of the email. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: #682010 re celt and mumble referred to the TC
On Thursday, July 19, 2012 05:38:47, Ron wrote: ... > > - This is a serious problem for mumble at least and is arguably RC. > > Yes, mumble has a serious problem, that is arguably RC. > In fact it has several of them aside from this corner that people > have painted themselves into with it ... […] >FWIW, even the original poster of the bug in question later agreed >in calmer discussion on IRC that the Right Thing for mumble to do >is to release 1.3 and accelerate the migration, and that is only >being delayed now by the first point above. I don't disagree, but I'm wondering how the migration could be (or could have been) accelerated. […] > If I'd known that Thorvald was not going to be here to manage this > transition for Wheezy, I'd have never agreed to shipping libcelt in > the Squeeze release either, and would have instead kept it in sid > only. If I'd known that his plan to have all other distros ship > the 0.7.1 release as a temporary interoperability snapshot would > fail as dismally as it did (no other distro shipped this version > except debian derivatives who took it from us), I'd have similarly > vetoed the idea of shipping this as a public library in the last > stable release too. This was definitely not clear; if it had been I wouldn't have considered re- enabling it as a potential solution. > Mumble already ships this as an embedded private library on every > system other than direct Debian derivatives. Just for clarification: does the Mumble client as shipped with Debian also contain the embedded private library? > > I assume it would be possible to reintroduce a celt package which was > > very similar to the one recently removed, so as to avoid risking > > unnecessary bugs. > > I see that this proposal has already resulted in Chris skating down > the slippery slope of "let's re-enable it for everything else too". > And we'll get people with no experience or prior involvement to > maintain it, and we'll enable multi-arch too, and ... In terms of re-enabling CELT, I was simply looking upon this as a matter of fairness to other maintainers. If it's decided only Mumble requires an exception to use CELT 0.7.1 (which right now doesn't sound like the right thing to do), I'm fine with that. […] > My general feeling is that mumble is currently in an awkward state > which really doesn't make it a good release candidate for Wheezy, > and we'd probably be best served by simply dropping it from testing, > fixing this in sid as the fixes come or are needed, and then pushing > snapshots to bpo as we have reasonable candidates for that. > > That was my original recommendation to the release team, but Phil > offered to cut us some slack with letting things in if I did try > to salvage it for Wheezy proper, so Svedrin and I put in the effort > to make that as possible as it might be. > > Maybe that really was a mistake. I don't mind taking full > responsibility for my mistakes - but being bullied into making > even bigger mistakes, by people who didn't understand the set > that created the problem in the first place, is not in my usual > definition of wisdom, and the crux of my disagreement with the > crusade that Chris has embarked on here. The disagreement was that I wanted a working Mumble, or a warning in NEWS.Debian concerning the compatability issues. That's not a crusade, so I object to this mischaracterization. > Since he didn't bother to wait for Josh and I to discuss that > further, now we're here ... There was no indication of any kind that the discussion was going to continue, otherwise I would have delayed the summary to the TC. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: re celt and mumble referred to the TC
On Thursday, July 19, 2012 08:00:11, Chris Knadle wrote: > On Thursday, July 19, 2012 05:38:47, Ron wrote: […] > > If I'd known that Thorvald was not going to be here to manage this > > transition for Wheezy, I'd have never agreed to shipping libcelt in > > the Squeeze release either, and would have instead kept it in sid > > only. If I'd known that his plan to have all other distros ship > > the 0.7.1 release as a temporary interoperability snapshot would > > fail as dismally as it did (no other distro shipped this version > > except debian derivatives who took it from us), I'd have similarly > > vetoed the idea of shipping this as a public library in the last > > stable release too. > > This was definitely not clear; if it had been I wouldn't have considered > re- enabling it as a potential solution. ... except that Nicos Gollan stated that mumble servers have a base assumption that clients have the CELT 0.7.1 codec available. :-/ Is that correct? […] > > I see that this proposal has already resulted in Chris skating down > > the slippery slope of "let's re-enable it for everything else too". > > And we'll get people with no experience or prior involvement to > > maintain it, and we'll enable multi-arch too, and ... > > In terms of re-enabling CELT, I was simply looking upon this as a matter of > fairness to other maintainers. If it's decided only Mumble requires an > exception to use CELT 0.7.1 (which right now doesn't sound like the right > thing to do), I'm fine with that. I mixed up the last sentence above; I was trying to say that I was fine with only Mumle using CELT 0.7.1 if it requires it, rather than any package that could theoretically use it. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: Call for votes on CELT in Mumble
On Friday, August 24, 2012 11:03:31, Ian Jackson wrote: […] > 14. Consequently, the mumble source package should be configured to > use an embedded copy of celt 0.7.1. (If necessary the embedded > copy of celt in the source package should be updated to the > actual 0.7.1.) We figured out a month ago that Celt 0.7.1 in the Debian system library and the version in the upstream Mumble source for embedding are the same. [1] I'll copy it again here for convenience: $ diff -r -u celt-0.7.1/libcelt mumble/celt-0.7.0-src/libcelt Only in celt-0.7.1/libcelt: Makefile.in [1] http://lists.debian.org/debian-ctte/2012/07/msg00333.html -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: Call for votes on CELT in Mumble
On Friday, August 24, 2012 12:16:01, Ian Jackson wrote:
> Chris Knadle writes ("Bug#682010: Call for votes on CELT in Mumble"):
> > On Friday, August 24, 2012 11:03:31, Ian Jackson wrote:
> > […]
> >
> > > 14. Consequently, the mumble source package should be configured to
> > >
> > > use an embedded copy of celt 0.7.1. (If necessary the embedded
> > > copy of celt in the source package should be updated to the
> > > actual 0.7.1.)
> >
> > We figured out a month ago that Celt 0.7.1 in the Debian system library
> > and the version in the upstream Mumble source for embedding are the
> > same. [1]
>
> > I'll copy it again here for convenience:
>
> Right.
>
> >$ diff -r -u celt-0.7.1/libcelt mumble/celt-0.7.0-src/libcelt
> >Only in celt-0.7.1/libcelt: Makefile.in
> >
> > [1] http://lists.debian.org/debian-ctte/2012/07/msg00333.html
>
> But you might want to rename it. I don't think we (the TC) need to
> have an opinion about that. I don't want to tie the mumble
> maintainers' hands on these kinds of details.
It would be nice to do eventually; i.e. renaming celt-0.7.0 to celt-0.7.1 to
make it clear what version Mumble actually had in it. There are several of
these little things I'd like to send upstream patches or Git pull requests
for, but I don't think it's necessary to deal with it now.
Likewise I found that the mumble upstream source currently builds in Opus
version 0.9.8, but the library comes out named as "libopus.so.0.0.0" which
again is non-intuitive as to what version it actually is. This doesn't really
matter for the version in Debian because it will use Debian's libopus0 library
instead (which contains Opus version 0.9.14, which I found to be compatible).
> But if you would be happier I can withdraw the version above and ask
> for a vote on a text without the parenthetical comment.
I thank you for the offer, but I don't think that's necessary. Fine as-is.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: alternatives to mumble
On Thursday, August 30, 2012 14:51:06, Daniel Pocock wrote: > This is not a comment in support of or against Mumble, rather, it is > looking beyond Mumble > > A few weeks ago I put up a wiki page about alternatives to mumble: > >http://wiki.debian.org/AlternativesToMumble > and I've put up an ITP (sponsor needed) for SylkServer (supports SIP, > Jabber and IRC conferencing) > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682698 I'd like to discuss this in the ITP above rather than in this bug report, but I'll mention that I caught your DebConf12 talk "Free (as in freedom) communications, VoIP and messaging": http://penta.debconf.org/dc12_schedule/events/933.en.html -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682698: alternatives to mumble
On Thursday, August 30, 2012 14:51:06, Daniel Pocock wrote (to #682010): > This is not a comment in support of or against Mumble, rather, it is > looking beyond Mumble > > A few weeks ago I put up a wiki page about alternatives to mumble: > >http://wiki.debian.org/AlternativesToMumble > > and I've put up an ITP (sponsor needed) for SylkServer (supports SIP, > Jabber and IRC conferencing) > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682698 > > Ultimately, the widespread deployment of standards-based solutions (such > as SylkServer and others mentioned in the wiki) should eliminate any > need for anyone to run Mumble and then celt can be put to rest. What originally drew me to Mumble was: a) it was built on Qt and has clients for Linux/Windows/Mac (i.e. is cross-platform) b) is free-as-in-freedom software c) is encrypted for both voice and text communication (simple and automatic in the user sense) d) it has a 3D overlay for popular videogames to allow seeing who is talking e) it was easy to set up f) has ACL rules for specifying user privileges I initially needed a VoIP solution for a group of gamers who were running multiple platforms. Mumble fits that need well in that there are different "channels" one can join, similar to chatrooms, which can be done quickly with just a couple of mouse clicks. Mumble has no provision for making phone calls, which has its pros and cons. To connnect to a Mumble server from the client, one generally only needs a single DNS name or an IP address (although it's possible to change the default port and/or to require a password for entry to the server). I caught your DebConf12 talk "Free (as in freedom) communications, VoIP and messaging": http://penta.debconf.org/dc12_schedule/events/933.en.html from this it seemed like making connections required knowing particular email addresses to make connections, and I didn't see any discussion concerning chatroom communications. It's thus not immediately clear to me what the user impact would be concerning switching from Mumble to one of the alternatives. If you could give a brief description of the (general) connection and chatroom choosing process of the alternatives, that would at least give me a 'gut feel' for whether they might be fitting. The alternatives are obviously more versitile, but that comes with some complication on both the client and server side, which raises the 'barrier-to-entry' a bit. Concerning this ITP concerning sponsorship, I suggest having a look at the Debian Mentors [1] page and the [debian-mentors] [2] mailing list; right now Wheezy is frozen and so new NEW packages are being sponsored for uploads right now AFAIK. In the meantime if you've got packages ready I wouldn't mind trying them [assuming I cand find time to do so] to see if they'd could theoretically be a drop-in replacement for Mumble and to get the packages ready for sending to [debian-mentors] after Wheezy is released. [1] http://mentors.debian.net/ [2] https://lists.debian.org/debian-mentors/ -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: #675971 -- are you willing to help?
Ron --- I know you'd like the celt 0.7.1 library to be removed from Wheezy. Are you willing to help put together an upload a new mumble package containing embedded celt 0.7.1 (as the tech-ctte has outlined) so that can happen? What version of mumble do you think is appropriate for this purpose? -- -- Chris Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: re celt and mumble referred to the TC
On Thursday, July 19, 2012 10:11:38, Nicos Gollan wrote: > Hi, > > On Thursday 19 July 2012 14:40:28 Chris Knadle wrote: > > ... except that Nicos Gollan stated that mumble servers have a base > > assumption that clients have the CELT 0.7.1 codec available. :-/ Is > > that correct? > > If a client does not report any CELT versions, the server assumes that > (only) 0.7.1 is available for that client. If a client reports a number of > supported versions, and 0.7.1 is not among them, the server will _not_ > make the assumption, but of course such clients also risk being unable to > communicate. > > For details, see the implementations of: > > * Server::msgAuthenticate() > * Server::recheckCodecVersions() > > Newer git versions of the server will send upon login a warning to clients > which are either missing CELT support on a "normal" server, or OPUS support > on an OPUS-only server. I'd just like to again give you my sincere thanks for providing this information. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: re celt and mumble referred to the TC
On Thursday, July 19, 2012 14:23:31, Ron wrote:
> On Thu, Jul 19, 2012 at 12:55:59PM +0100, Ian Jackson wrote:
> > Ron writes ("Re: #682010 re celt and mumble referred to the TC"):
[…]
> > > Mumble already ships this as an embedded private library on every
> > > system other than direct Debian derivatives.
> >
> > I'm not sure exactly what you mean. Do you mean they support some
> > other version of the celt codec ? Or are you just talking about how
> > they manage the packaging ?
>
> I mean mumble embeds something like seven mutually incompatible versions
> of celt, all of which it provides as private implementation libraries
> on every platform except Debian - because nobody else provides the version
> that we do. And we only provide that version because upstream tagged the
> current head on a random day when Thorvald and I said, "if we're going to
> do this, we need it today".
>
> The idea was, he was going to try to get everyone else to use it too.
> But that failed completely, so all we have now is this random Debian-
> specific snapshot, that nothing and nobody else uses or interoperates
> with, and which mumble has to embed anyway for every other user.
When I test the version in Wheezy that uses celt I'm able to interoperate with
any public server, whether it be a Debian platform, Gentoo, Fedora, Windows,
FreeBSD, but I often cannot with the version in Sid. :-/
> It really is time to just admit that was a mistake, and correct it.
However as I said I also don't disagree with this.
An alternative I've been thinking about would be an additional text file in
the Mumble package (FAQ.txt, PROBLEMS.txt -- whatever filename seems logical)
which could contain information concerning removal of the CELT codec and the
reasons why -- dead upstream, security concerns, etc. Enough information
(such as that you've already provided) that's easy enough to find so that
there's at least a chance for users to find it, or something to point them to
if they open a bug report ... and then we suffer for a bit until Opus support
gets more widespread.
What I'm really looking to try avoid are repeat events of someone installing
Mumble, finding or opening a bug report, and receiving back [this is not an
accusation] "this isn't a bug " because the users lack the
information, and it being too exasperating for any maintainer to give the long
explanation repeatedly.
This is why I've been asking whether an entry in NEWS.Debian makes sense. Or
perhaps both makes sense: a NEWS.Debian entry for "please read FAQ.txt in
/usr/share/docs/mumble relating to why some audio connections fail currently"
or something to that effect.
Not optimal of course, but no solution to bug ever will be.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
signature.asc
Description: This is a digitally signed message part.
Bug#682010: re celt and mumble referred to the TC
On Thursday, July 19, 2012 19:07:52, Ron wrote: > Ok, so I've just had a long overdue catch-up with Thorvald, and we think > we have a plan that really covers all the bases ... > > We can re-enable speex support in the client, which was only just recently > dropped (so only the client currently in unstable is affected by that), > and since all the clients well back in pre-history should support that > just fine, we can jigger things so that it will be the baseline interop > if celt is not present, and use the existing threshold setting on the > servers to let people select the point at which the number of users with > opus support triggers switching to that. > > Which means we basically get the best of all worlds, we have interop with > existing old clients, we get to drop celt support and so don't have to > worry about getting burned by it, and people will automatically switch to > the wonders of opus (and get lower bandwidth and better quality) as soon > as enough of the connected parties have support for it. This sounds great. > There's a few things that need testing, but we're reasonably confident > this can fly, and meet all the concerns of almost everyone. > > > There are only two small catches: > > - catch 1. He's about to fly out and will be afk for a week, so he >won't be able to look at this until he gets back. (which is why >I'm writing this now instead of letting him do it) > > - catch 2. The version of murmur currently in testing is completely >broken again due to the zeroc-ice screwup. That wouldn't have >happened if the -2 upload of mumble had transitioned as planned, >but well, you all know the story there ... Let's just call it the results from a communication breakdown. I appologize for my side of that. > So ... Chris, since you're currently the major objector, and opened > this bug with the TC, this question is mainly for you ... This sounds like a very good compromise to me, and I thank both you and Thorvald for the effort in coming up with it. .. And thanks for talking to me again. > What we'd like to do in the meantime, is let the mumble version from > unstable transition to testing now. That will: > > - Unbreak the server for everyone, which currently won't work at all. ... And I can verify that this is the case, as I just attempted to upgrade the version of mumble-server I was running on a server, which results in an error message on every attempted startup: /usr/sbin/murmurd: symbol lookup error: /usr/sbin/murmurd: undefined symbol: _ZN3Ice6upCastEPNS_10ConnectionE Whereby I upgraded to mumble-server from Sid, which works fine. (Thank you for dealing with the zero-ice difficulties, and I'm glad that work will be put to good use.) > - Break the client for people using ancient servers, and who are >talking to people without opus support. ie. not everyone, but a >fair number of people who haven't yet moved, or who can't convince >their friends to move yet. You know the deal there. Minorly sucks but I see no reasonable alternative. > - Most importantly though: minimise the diff that -release need to >review when Thorvald gets back and we have a new upload to make >once again. > > We tossed up which way to go with this (the alternative being to not > let it migrate and inflict the bigger diff on -release and broken > server on everyone) - but this seems to be the lesser evil, since it > will let people get some more testing miles on opus, and people who > would really be put out by that can just put it on hold for a short > time. > > Once Thorvald gets back and we re-add speex, this should all work again > for everyone, and we don't have to kick it out of testing, don't have > to embed a suspect lib, and shouldn't have to leave anyone feeling > hard done by ... > > > Does that sound ok for you? Yes it does. Best suggestion I've heard yet. > If it does, I'll bump the severity of your bug back down to something > not RC (but not close it yet, we'll let the speex enabling upload do > that), and request the release team unblock it. And if there is no > further complaint to discuss, then I guess you can tell -ctte you > have the pound of flesh you sought :) I appreciate your humor. ;-) No objection to the plan. > Otherwise ... well, then I don't know what ... you'll have to > suggest a plan B all your own, because this is the best we have ... > > All Thorvald asked is that people stay calm, so he can actually worry > about working on the code rather than being stressed by the drama :) > > > I'll make this happen if I get your ACK that it works for you too. ACK. T
Bug#682010: re celt and mumble referred to the TC
On Thursday, July 19, 2012 19:07:52, Ron wrote: ... > What we'd like to do in the meantime, is let the mumble version from > unstable transition to testing now. That will: > > - Unbreak the server for everyone, which currently won't work at all. > - Break the client for people using ancient servers, and who are >talking to people without opus support. ie. not everyone, but a >fair number of people who haven't yet moved, or who can't convince >their friends to move yet. You know the deal there. I'm still not opposed to the plan (because I still think it's the best option discussed), but I think it might hurt a bit more than perhaps we anticipated in the very-short-term before the version of the Mumble client with the Speex codec is available. Test: - installed -2 mumble-server from Sid on the server (this was likely a one-way operation, because the version I was previously running is gone from the repos) - upgraded to the -2 client from Sid on my laptop - connected to the server, Opus codec was chosen - friend connected from his laptop using Windows Mumble client 1.2.3a and was shown an error message stating lack of Opus support, so he couldn't talk nor hear. - I had the friend upgrade to the developer snapshot 1.2.3-361-ga2a3836 from the Mumble website and try again -- same message. So right now there is no version of the Mumble client available for Windows (at least on the front page of the Mumble website) that supports Opus, or if it does it's not compatable with the version of Opus in the -2 Mumble package in Sid. - I disconnected from the server (-2 client) and closed Mumble - I reinstalled Mumble from Wheezy (the "348" version of the client that is impossible to build today) - Connected to the server again and communication works via CELT codec From this test I draw the following conclusions: - the -2 version of mumble-server is safe to migrate to Wheezy, no problem there - in terms of the mumble client, we'll be relying on getting the version with Speex support tested and into Wheezy. We knew this already, but now it's more clear that this will be important even for /newer/ versions of the Mumble client. - Once -2 of the Mumble client is migrated to Testing we will be fully committed to the plan - There's some element of time risk involved because Thorvald is going to be afk for a week. I have faith that this will work out, and I also think it's important to report these findings so we can all try to understand the scope of the problem. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Bug#682010: re celt and mumble referred to the TC
On Friday, July 20, 2012 01:47:21, Chris Knadle wrote: […] > From this test I draw the following conclusions: […] >- Once -2 of the Mumble client is migrated to Testing we will be > fully committed to the plan Update: scratch the above, the "348" version of Mumble in Wheezy as it is now won't build anyway, so there's no harm in migrating -2 from Sid -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Bug#682010: re celt and mumble referred to the TC
On Friday, July 20, 2012 07:54:21, Ian Jackson wrote:
> Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the
TC"):
> > On Thursday, July 19, 2012 19:07:52, Ron wrote:
> > ...
> >
> > > What we'd like to do in the meantime, is let the mumble version from
> > >
> > > unstable transition to testing now. That will:
> > > - Unbreak the server for everyone, which currently won't work at all.
> > > - Break the client for people using ancient servers, and who are
> > >
> > >talking to people without opus support. ie. not everyone, but a
> > >fair number of people who haven't yet moved, or who can't convince
> > >their friends to move yet. You know the deal there.
> >
> > I'm still not opposed to the plan (because I still think it's the
> > best option discussed), but I think it might hurt a bit more than
> > perhaps we anticipated in the very-short-term before the version of
> > the Mumble client with the Speex codec is available.
>
> I'm not sure I follow this conversation but it seems to be a plan to
> switch to yet a different codec.
Yes, one that used to be supported in Mumble until recently in low-bandwidth
situations.
> How will this interact with mumble in other distros, who are
> presumably following mumble upstream's advice to use celt 0.7.1 as a
> baseline ?
According to Nicos in his last email, not well. The problem with the idea is
that Speex is not part of the codec selection mechanism in existing clients,
and will thus cause similar issues.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
signature.asc
Description: This is a digitally signed message part.
Bug#682010: re celt and mumble referred to the TC
On Friday, July 20, 2012 08:32:01, Ron wrote: > On Fri, Jul 20, 2012 at 08:14:48AM -0400, Chris Knadle wrote: > > On Friday, July 20, 2012 07:54:21, Ian Jackson wrote: […] > > > How will this interact with mumble in other distros, who are > > > presumably following mumble upstream's advice to use celt 0.7.1 as a > > > baseline ? > > > > According to Nicos in his last email, not well. The problem with the > > idea is that Speex is not part of the codec selection mechanism in > > existing clients, and will thus cause similar issues. > > Nicos hasn't talked to Thorvald yet. The solution to that problem is what > Thorvald will be implementing when he gets back, and he thinks he can do it > in a way that will be backward compatible for all clients. Okay. In his previous email, Nicos pointed me to two functions, * Server::msgAuthenticate() * Server::recheckCodecVersions() Which I'm studying to see if I can figure out what Thorvald might have in mind. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: re celt and mumble referred to the TC
On Friday, July 20, 2012 10:20:28, Ian Jackson wrote:
> Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the
TC"):
> > Test:
> Thanks.
>
> This:
> >- I had the friend upgrade to the developer snapshot
> >1.2.3-361-ga2a3836
> >
> > from the Mumble website and try again -- same message. So right now
> > there is no version of the Mumble client available for Windows (at
> > least on the front page of the Mumble website) that supports Opus,
> > or if it does it's not compatable with the version of Opus in the
> > -2 Mumble package in Sid.
> >
> >- I disconnected from the server (-2 client) and closed Mumble
> >- I reinstalled Mumble from Wheezy (the "348" version of the client
> >that
> >
> > is impossible to build today)
> >
> >- Connected to the server again and communication works via CELT codec
>
> Does not appear to be consistent with this:
> > From this test I draw the following conclusions:
> >- the -2 version of mumble-server is safe to migrate to Wheezy,
> >
> > no problem there
>
> Since if I read you correctly the -1 .deb works with your friend's
> Windows version and the -2 .deb doesn't.
Negative. Let me try to make this clear.
- the -2 mumble-server from Sid was in use in all cases of this test.
[And BTW it seems after doing so it is not possible to downgrade
mumble-server to the version in Squeeze.]
- the difference as to whether my friend could speak after he
installed the developer snapshot was whether *I* was using the
Mumble *client* from Wheezy on my laptop, or the -2 version from Sid.
The "348" client from Wheezy has CELT support, the -2 client in
Sid does not. The -2 "349" version of the client in Sid has Opus
support (only), the Windows developer snapshot my friend loaded
does not.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
signature.asc
Description: This is a digitally signed message part.
Bug#682010: re celt and mumble referred to the TC
On Friday, July 20, 2012 10:21:17, Ian Jackson wrote:
> Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the
TC"):
> > On Friday, July 20, 2012 01:47:21, Chris Knadle wrote:
> > […]
> >
> > > From this test I draw the following conclusions:
> > […]
> >
> > >- Once -2 of the Mumble client is migrated to Testing we will be
> > >
> > > fully committed to the plan
> >
> > Update: scratch the above, the "348" version of Mumble in Wheezy as
> > it is now won't build anyway, so there's no harm in migrating -2
> > from Sid
I'm going to reverse the order of your two questions below.
> It won't build in sid because sid is missing celt but it will build
> in wheezy.
Negative. It builds fine in Sid, without celt being required. But because it
does not use the celt library (regardless of whether it is installed) clients
cannot voice communicate with any server with connected clients that require
using anything other than Opus. Text communication always works.
> Why won't it build ?
The mumble source pacakge will not build in Wheezy on amd64 due to Wheezy
getting an upgrade to gcc 4.7 in relation with zero-ice.
Phillip Kern sent the following link to (Bug #675971, msg #131):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672066#54
On i386 the package does build, but due to ABI breakage in zero-ice, mumble-
server is unable to start and spits out an error on every invocation.
I'm working on getting you a build log from a Wheezy amd64 VM.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
signature.asc
Description: This is a digitally signed message part.
Bug#682010: re celt and mumble referred to the TC
On Friday, July 20, 2012 11:27:08, Ian Jackson wrote:
> Chris Knadle writes ("Re: Bug#682010: re celt and mumble referred to the
TC"):
> > On Friday, July 20, 2012 10:21:17, Ian Jackson wrote:
> > > Why won't it build ?
> >
> > The mumble source pacakge will not build in Wheezy on amd64 due to Wheezy
> > getting an upgrade to gcc 4.7 in relation with zero-ice.
>
> Oh, right. This is related to the other changes from -1 to -2.
I might be forgetting some facts, but that sounds right.
Build just finished and erred as expected. I'll give you the tail of the
file, just let me know if you'd like the entirety.
--
/usr/include/Ice/Handle.h: In instantiation of
‘IceInternal::Handle::Handle(T*) [with T = Ice::Communicator]’:
/usr/include/Ice/OutgoingAsync.h:49:16: required from here
/usr/include/Ice/Handle.h:66:13: error: ‘upCast’ was not declared in this
scope, and no declarations were found by argument-dependent lookup at the
point of instantiation [-fpermissive]
compilation terminated due to -Wfatal-errors.
make[3]: *** [release/MurmurIce.o] Error 1
make[3]: Leaving directory `/home/cknadle/src/mumble/mumble-1.2.3-348-
g317f5a0/src/murmur'
make[2]: *** [release] Error 2
make[2]: Leaving directory `/home/cknadle/src/mumble/mumble-1.2.3-348-
g317f5a0/src/murmur'
make[1]: *** [sub-src-murmur-sub_Release_ordered] Error 2
make[1]: Leaving directory `/home/cknadle/src/mumble/mumble-1.2.3-348-
g317f5a0'
make: *** [build-arch-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
> I assume that we could make, in principle, a -3 which was like -2 but
> with celt 0.7.1 reenabled.
I should probably examine the Git history, but in priciple I believe it should
be possible to either make a "348" -2 with backported zero-ice ABI fixes and
hardcoding use of gcc 4.6, or a "349" -3 with added libcelt support.
However if we decide to go in this direction while upstream plans to re-enable
Speex, we should probably also consider whether to try to re-enable Speex for
interoperability.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
signature.asc
Description: This is a digitally signed message part.
Bug#682010: [mumble] Communication failures due to CELT codec library removal
Diff for summary attached. Thanks to Don Armstrong -- Chris -- Chris Knadle chris.kna...@coredump.us diff --git a/682010_celt_and_mumble.org b/682010_celt_and_mumble.org index ae6112a..849c105 100644 --- a/682010_celt_and_mumble.org +++ b/682010_celt_and_mumble.org @@ -1,18 +1,25 @@ * Issue #682010 -** Mumble in unstable/testing currently cannot interact with other clients and servers - + Due to the removal of celt 0.7.1 (?) +** Mumble in unstable/testing currently cannot interact with other clients and servers due to: + + removal of celt 0.7.1 library and disabling of use in mumble + + mumble upstream dropping speex * Possible solutions ** Include celt 0.7.1 as a convenience copy - + Security Issues with embedded copies + + Security Issues with embedded copies (?) (Thorvald) + Unspecified possible security issues + + Deprecated upstream in favor of opus + + Proliferates ancient celt library downstream ** Upload a celt 0.7.1 package + No maintainer desires to deal with this (apparently?) + + Request from celt authors to stop distributing ancient version + Unspecified possible security issues ** Use speex instead - + Server (and clients?) do not select speex as an option unless bandwidth is low + + Clients do not use speex unless bandwidth is <= 32kb/s + + Clients cannot currently report speex version during codec selection process + + Requires code modification for selection process and re-enabling speex + + After mods should be backward compatible with existing clients ** Use only opus - + Not yet (?) released upstream - + May not communicate with non-opus clients + + Will not communicate with non-opus clients + + Will not communicate with non-opus servers * Open questions ** Can speex be made to be an option? ** Is a convenience copy acceptable, assuming mumble is the only thing with it?
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Friday, July 20, 2012 17:48:07, Don Armstrong wrote: > I've updated the summary with the suggested changes (at the end). Please note that the table I had previously published to the original bug is informative for when "server loopback" works when there is only a *single* client connected. It doesn't take into account situations when an opus-only client and an non-opus client are both connected, in which case [audio] communication always fails for one or more parties, depending on which codec the server decides all clients must use. [It would be helpful to make a note of this above or below the table in the summary. Thanks.] > On Sat, 21 Jul 2012, Ron wrote: > > I think that's roughly right. If there's anything more people need > > clarified or answered, just ask. > > [...] > > > And I'm still not quite clear what his objection was, because the > > response I got was: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#124 > > The objection is that the issue has been raised before the CTTE, so it > needs to be resolved first before action is taken. From what I > understand now, while we could fix up some of the RC issues with the > client/server in testing and unstable, we'd need yet another upload of > mumble to unstable with propagation to testing in order to actually > fix the client inter-operation bug. Additionally I think it's best to show respect and use patience. It's a difficult and complicated problem that we're all trying to help each other with. > From what I can tell now, the ideal solution is to wait until Thorvald > has a chance to enable speex for all bandwidths. If that is > impractical/impossible then we get to choose between a convenience > copy of celt, not releasing mumble, or releasing with opus. Is that > the understanding of everyone else? I believe this is correct. Thats 4 options, each of which have their own set of issues. Re: summary: Two lines are duplicated: […] 11 + Clients cannot currently report speex version during codec selection process […] 14 + Clients cannot currently report speex version during codec selection process Additional items: "348" package in Wheezy will not build on amd64; zero-ice + gcc 4.7 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672066#54 "348" mumble-server will not start due to zero-ice ABI breakage Otherwise it looks good to me. Thanks a lot, Don. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Friday, July 20, 2012 19:24:17, Don Armstrong wrote: > On Sat, 21 Jul 2012, Ron wrote: > > One very last thing then, before I hopefully stop bothering you for > > > > a while (: > > > ** Use speex instead > > > > > >+ Clients cannot currently report speex version during codec > > >selection process > > > > I don't understand where that issue came from? > > Speex has been API and bitstream compatible since, like 2006, or maybe > > before. > > > > Maybe I totally misunderstand what that's saying, but anything relying on > > a "speex version" is almost surely Doing It Wrong. > > Chris asked for this to be added IIRC; I believe[1] that this should > really be "currently report speex support" rather than "speex > version". Yes I think the above wording is better. I was reading code where several versions of CELT are reported and versions compared -- and since there isn't any code for reporting speex availability, I made an assumption as to how that would theoretically be handled. > Don Armstrong > > 1: Hopefully I'll be corrected if I'm wrong; it's likely that I > introduced the incorrect wording too. With a list of complications this long, something will end up being worded wrong. ;-) -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: [mumble] Communication failures due to CELT codec library removal
and the set of codecs supported by all clients > appears to be the empty set, unless we want to all agree to use an > obsolete experimental codec which suffers from serious non-theoretical > security issues. > > So I'm really not sure why it's useful for the TC to be debating which of > the bad options we consider least bad. There isn't much choice, as lack of interoperability was why the matter was brought to the TC, and the action chosen directly affects interoperability. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#114 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010#42 -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Sunday, July 22, 2012 04:35:00, Ron wrote: > On Sat, Jul 21, 2012 at 03:46:34PM -0400, Chris Knadle wrote: ... > > [Special thanks goes to Nicos for watching our backs here.] > > Just to be clear here, because at some point Ian described Nicos as being > "a mumble developer", and you have now declared him a "sage" ... You've misquoted me. I said "he's consistently given us sage technical advice". > $ git log master | wc -l > 30363 > > $ git log master | grep Nicos | wc -l > 12 > > And all of those commits afaics relate to GUI overlay stuff for games, > nothing at all to do with the protocol negotiation we are talking about > here ... Nicos is the only one that has hinted to how the protocol negotiation works; being judgmental about his commits isn't going to help. If you know more about how the selection algorithm works, that would be good, but I haven't yet heard you discuss the subject when it has come up. > So I think I'd still rather put my trust in the the opinion > of Thorvald about what can be made to work, than in someone who has said > repeatedly, "Debian should just remove this, nobody cares because nobody > uses Debian anyhow". Which is also clearly quite incorrect, or we wouldn't > be having this discussion at all. I'm quite willing to discuss Thorvald's plan when he comes back. > The current facts are: > > - The server is currently 100% broken in testing, and will remain so >for our users for as long as this is blocked here. The current -2 is also undistributable, so this doesn't really matter. You'll see why. I just found something out about the Opus-only client and the codec selection by the server. This test involves four Mumble clients: - "348" client from Wheezy (has Opus and CELT) - "1.2.2-6+squeeze1" client from Stable (lacks Opus) - "361" Windows developer snapshot (lacks Opus) - "349" client from Sid (has Opus only) And the server version is again -2 from Sid. Steps: 1. "361" Windows client connects (Codec CELT) 2. I connected the "1.2.2-6_squeeze1" client; doesn't show which codec is use, but it's CELT 3. I connect my "348" client, connection shows Codec CELT 4. Talk a while -- everything works 5. I connect the "349" client from Sid, shows Codec OPUS 6. All audio connections for everybody DO NOT WORK from here on. "348" client still shows Codec CELT. As long as the "349" client from Sid is connected, disconnecting and reconnecting any other client gets a message from the server "Warning: Your client doesn't support the Opus codec, you won't be able to talk or hear anyone. Please upgrade to a client with Opus support." 7. Disconnect the "349" client Audio connections still do not work. 8. In order to get the audio connection to work again between the clients that have CELT, one of them must disconnect and then reconnect in order to get the server to renegotiate which codec is used. This is 100% repeatable. This means that the Opus-only client ruins the audio connection for everybody else that's connected, at least in this case. From seeing this I really think releasing a client that only has the Opus codec available is a directly detrimental plan. It also implies that the current version of the server seems to choose using Opus over everything else, regardless of whether the other clients have it. […] >Then provided we have a clear public record of the people wanting >that putting *their* own heads on the block, and taking the full >responsibility for any fall out or required remedy -- then I have >clean hands, and someone to point at who is completely to blame for >an action I advised against in the event it goes Horribly wrong. Quit the social engineering. […] > The weekend here is nearly over, and I can't keep stealing time from > my Work customers to keep discussing this in circles next week (and > I'm sure many others here are in the same position). > > The longer we draw this out, the less testing any of it is going to > have, the less time is going to be available to fix any shortcomings > that we haven't so far seen, and the poorer the result that we are > ultimately going to end up with. Since you're low on time I'll cut to the chase. As far as I'm concerned I now think we're down to three distinct options. 1) Fix up "348" from Wheezy so it compiles and uses the CELT codec library [very undesirable] 2) Same as 1) but with embedded CELT (would need testing) 3) drop mumble from Wheezy -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Sunday, July 22, 2012 18:31:27, Chris Knadle wrote:
> On Sunday, July 22, 2012 04:35:00, Ron wrote:
> > On Sat, Jul 21, 2012 at 03:46:34PM -0400, Chris Knadle wrote:
[…]
> Steps:
> 1. "361" Windows client connects (Codec CELT)
> 2. I connected the "1.2.2-6_squeeze1" client; doesn't show which
> codec is use, but it's CELT
> 3. I connect my "348" client, connection shows Codec CELT
> 4. Talk a while -- everything works
> 5. I connect the "349" client from Sid, shows Codec OPUS
> 6. All audio connections for everybody DO NOT WORK from here on.
> "348" client still shows Codec CELT.
> As long as the "349" client from Sid is connected, disconnecting
> and reconnecting any other client gets a message from the server
> "Warning: Your client doesn't support the Opus codec, you won't
>be able to talk or hear anyone. Please upgrade to a client with
>Opus support."
I got curious as to which platforms supported Opus. It just so happens my
girlfriend is a Mac user, and also has an iPad. [Not my thing for obvious
reasons, but... to each their own.]
Opus support
Windows 1.2.3a *no*
Windows "361" dev snapshot *no*
iOS 1.1 *no*
Mac OSX 1.2.3a *no*
Mac OSX "409" dev snapshot *yes*
("409" is brand new within the last couple of days)
Debian specifically
---
1.2.2-6+squeeze1 *no*
"348" in Wheezy *no*
"349" in Sid *yes, only*
So who /exactly/ can the Debian -2 version of Mumble talk to?
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
signature.asc
Description: This is a digitally signed message part.
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> Philipp Kern writes ("Re: Bug#682010: [mumble] Communication failures due to
CELT codec library removal"):
> > On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote:
> > >1) Fix up "348" from Wheezy so it compiles and uses the CELT
> > >
> > > codec library [very undesirable]
> > >
> > >2) Same as 1) but with embedded CELT (would need testing)
> > >3) drop mumble from Wheezy
>
> Of these 2. would seem to be the best option.
I agree.
Pros:
- Solution should work for both Wheezy and Sid
(-2 in Sid currently has no celt support, and celt is the most widely
used codec in mumble on the 'net)
- Would use celt 0.7 as well as 0.11
- Celt library can be removed, which a lot of effort has gone into
Cons:
- Larger diff in mumble
- Would greatly irritate mumble maintainer
> Mumble is pretty widely used in some communities and I certainly think
> we should try to have software in wheezy which can (i) provide a
> server for mumble clients (ii) talk to mumble servers (iii) is
> generally compatible with the existing deployed base (both inside and
> outside Debian).
>
> Personally I don't think there is much to prefer between 1 and 2. Is
> all that's stopping us from fixing this is overcoming our resistance
> to an embedded library copy ? If so I think we should just go ahead.
Pros:
- Smaller diff in mumble
Cons:
- Only uses celt 0.7
- Proliferates library that upstream requested removal of
- No DD found to maintain celt 0.7 library (yet)
- Would somewhat irritate mumble maintainer
> The difference in security supportability of a single embedded library
> copy versus a separately library package with a rdep isn't very
> great. The difference mostly consists of the discoverability of the
> embedded copy - and after this conversation I think we can reasonably
> hope that everyone will know that mumble needs attention for security
> bugs in celt 0.7.1.
Right.
> We should confirm this with the security team but I don't imagine
> they'll have an objection.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
signature.asc
Description: This is a digitally signed message part.
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 13:09:05, Ian Jackson wrote:
> Chris Knadle writes ("Re: Bug#682010: [mumble] Communication failures due to
CELT codec library removal"):
> > On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> > > Philipp Kern writes ("Re: Bug#682010: [mumble] Communication failures
> > > due to
> >
> > CELT codec library removal"):
> > > > On Sun, Jul 22, 2012 at 06:31:27PM -0400, Chris Knadle wrote:
> > > > >1) Fix up "348" from Wheezy so it compiles and uses the CELT
> > > > >
> > > > > codec library [very undesirable]
> > > > >
> > > > >2) Same as 1) but with embedded CELT (would need testing)
> > > > >3) drop mumble from Wheezy
> > >
> > > Of these 2. would seem to be the best option.
> >
> > I agree.
> >
> > Pros:
> > - Solution should work for both Wheezy and Sid
> >
> > (-2 in Sid currently has no celt support, and celt is the most widely
> >
> > used codec in mumble on the 'net)
> >
> > - Would use celt 0.7 as well as 0.11
>
> I'm not sure I follow this. Are you saying that enabling the embedded
> celt would necessarily involve enabling /two/ versions of celt ?
Yes AFAIK.
> (And you mention `0.7' and `0.11' neither of which are the same as `0.7.1'
> so I'm confused about that too.)
The mumble source package seems to contain celt 0.11.0 and 0.7.0. The celt
library contains celt 0.7.1.
> Surely we want to avoid having multiple different versions if at all
> possible. Is it essential to support anything other than 0.7.1 ?
AFAIK, no.
> I thought upstream had declared 0.7.1 to be a baseline so that would
> be sufficient.
That was my understanding too, but upstream seem to be using 0.7.0 from what I
can tell. [As such I'm likewise asking the same questions you are.]
> And if 0.7.1 is sufficient, can it be done using an embedded copy
> right now with a build system change, or would we have to dump a
> special copy of celt 0.7.1 into the mumble source package ?
I'm working on the assumption that celt 0.7.0 in the source package can be
embedded using a build system change.
> > Cons:
> > - Larger diff in mumble
>
> Is it in fact a substantial diff ? I thought it was essentially a
> configure option.
Source-wise it's likewise my assumption also, but I was also considering the
"binary diff", if you will.
> > - Would greatly irritate mumble maintainer
>
> Rather than consider someone's emotional state, I'd rather focus on
> their views. That is, if this is a bad idea according to the mumble
> maintainers then I'd like to hear why they think so.
Likewise -- I'm just trying to take the maintainer's wishes into account.
> > > Personally I don't think there is much to prefer between 1 and 2. Is
> > > all that's stopping us from fixing this is overcoming our resistance
> > > to an embedded library copy ? If so I think we should just go ahead.
> >
> > Pros:
> > - Smaller diff in mumble
> >
> > Cons:
> > - Only uses celt 0.7
>
> See above.
Celt 0.7.1 in the celt library.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
signature.asc
Description: This is a digitally signed message part.
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 04:52:29, Nicos Gollan wrote: > Hi, > > On Monday 23 July 2012 00:31:27 Chris Knadle wrote: > > This means that the Opus-only client ruins the audio connection for > > everybody else that's connected, at least in this case. > > That happens because the maintainer patch "20-add-opus-threshold-option" > sets the threshold variable default to 1, which is a pretty nonsensical > value in most situations. It only really makes sense to set it to 0 or > 100, unless you want to fabricate some really weird behaviour in codec > negotiation… Yes I see that opusthreshold is commented out, and iOpusThreshold = 1. I've verified that this patch doesn't exist in the "348" version in Wheezy -- nor does it contain patches in relation to Opus. > In that case, any client with Opus support should trigger the issue, no > matter if it supports CELT. > > Just for completeness' sake, this is _not_ an upstream issue, the value is > initialised to 100 there. > > I guess manually setting "opusthreshold=100" in your murmur.ini would > restore sane behaviour on the server side, but I'm not inclined to dig > through the other maintainer patches to see what else is interfering at > this point. When it comes to the -2 version in Sid I hope it will only be necessary to get the build fixes required to build "348" -1 in Wheezy. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 13:16:55, Ron wrote: > On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote: […] > Maybe that is true for the gamers, but when I asked I didn't get > any confirmation that this was what the problem they saw was - so > I'm guessing a bit here, based mostly on the knowledge of what the > codecs themselves are capable of. > > I am actually likewise curious to understand this better if that's > not the reason. It's not surprising celt can sound better, but it > is quite surprising if speex actually sounds Bad. And for people > just talking, and who pay for their traffic by the MB, or who only > have a low bandwidth pipe, celt may not be the best choice for them > at all anyway. I seem to recall that the early versions of Mumble that I used defaulted to using Speex. I seem to remember it sounding sort of like "a so-so cellphone connection", sort of like the person(s) on the other side sounded like they might be slightly underwater. i.e. "works but not great", whereas CELT sounds very clear [as does Opus]. I can't be positive about this though because I might be mixing this memory up with my memories of other VoIP packages I've used over the years, so I'm likewise curious to hear what Speex sounds like again. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675971: Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 13:26:57, Don Armstrong wrote: > On Mon, 23 Jul 2012, Chris Knadle wrote: > > On Monday, July 23, 2012 10:34:28, Ian Jackson wrote: > > > Of these 2. would seem to be the best option. > > > > I agree. > > [...] > > I believe in order to actually evaluate any of these solutions, > someone is going to have to prepare binaries, and do an table showing > the tested (not theoretical) compatibility of with multiple different > clients (and servers?) to their solution's server and client. > > I propose that whoever wants to see a particular solution actually sit > down and do the work for their particular solution, with sources, > binaries, interdiffs, and compatibility table conveniently available in > some public location. That sounds reasonable. I might need occasional advice but otherwise I think I can handle this. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 15:25:17, Ron wrote:
> On Mon, Jul 23, 2012 at 06:09:05PM +0100, Ian Jackson wrote:
> > Chris Knadle writes ("Re: Bug#682010: [mumble] Communication failures due
to CELT codec library removal"):
> > > On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> > > > Philipp Kern writes ("Re: Bug#682010: [mumble] Communication failures
> > > > due to
[…]
> > > - Would use celt 0.7 as well as 0.11
> >
> > I'm not sure I follow this. Are you saying that enabling the embedded
> > celt would necessarily involve enabling /two/ versions of celt ? (And
> > you mention `0.7' and `0.11' neither of which are the same as `0.7.1'
> > so I'm confused about that too.)
>
> This is absolutely not _necessary_, and not at all what I had in mind
> in the previous discussions of this option.
>
> It is _possible_ for mumble to embed many versions of celt simultaneously,
> and perhaps Nicos and Chris had discussed this privately, but this is not
> what we should be doing here. If we take this option at all, then we
> should use precisely the same celt code we have been using before now,
> the 0.7.1 release.
I have no objection.
There has been no private discussion with any of the parties in the bug AFAIK.
The main reason I was considering the embedded version was because the celt
library is removed in Sid. The only possible benefit of using celt 0.11.0 is
only if it somehow improves interoperability with other distros, that from
what you mentioned used embedded celt -- but this is certainly /not/ a
requirement.
> > Surely we want to avoid having multiple different versions if at all
> > possible.
>
> Absolutely.
> Anything else only increases our exposure surface to unmaintained code.
I think I agree with that.
[…]
> > I thought upstream had declared 0.7.1 to be a baseline so that would
> > be sufficient.
>
> Correct. (well, ostensibly correct, that's what upstream declared, but
> apparently there are live servers in existence which don't respect this
> and want to force other arbitrary versions of celt too).
>
> For decoding speex actually appears to be the only baseline that we
> really can trust all clients will have and all servers will support.
It will be good if a solution with Speex will work out such that celt can go
away. On that I think we're all on the same page, but I have my doubts if it
will work with existing servers. Hopefully it does.
[…]
> > That is, if this is a bad idea according to the mumble
> > maintainers then I'd like to hear why they think so.
>
> My primary concern is with the fact we would be shipping very complicated
> code, that only about 3 people in the world really understand, and which
> has no committed ongoing maintainer from among them or anyone else.
>
> If there is a consensus among the members of the TC and the security
> team that the risk of doing that is justified by other factors, then
> I'll consider the peer decision making process to have worked as it
> should, and quite the opposite of being 'irritated', I'll be quite
> relieved that this decision and its possible consequences do not fall
> on my head alone.
>
> I was not comfortable unilaterally making the decision to continue
> shipping celt with the knowledge I have of its situation, and I wasn't
> going to be browbeaten by users who shared no part in the risk they
> wanted to expose others to.
The term "browbeaten" is objectionable, as from our point of view mumble
became completely unusable to talk to the rest of the world, there wasn't
sufficient information available to understand the issue, and ... so on.
Please just try to stick to the technical issues so I may do the same, because
those are things we're much more likely to agree on.
> That's very different to the TC putting
> its judgement on the line, and the security team committing to do the
> work should it come to that.
>
> If they all agree this is our best option, then I have no problem with
> deferring to that opinion. As I said previously, it won't take a formal
> vote to convince me if consensus is that this is the best thing to do.
Cool.
> I think I'd still like to see us explore the speex option. But the
> release clock is ticking, and I'd be lying if I said I wasn't anxious
> about squandering what time we have left by not having real users
> really out testing all this and reporting the bugs they find.
>
> The bottom line on the compatibility matrix is that the *only* way to
> ensure we really are compatible with all extant systems is to:
>
> - Ship with speex reenabled.
> - Ship with al
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 15:43:11, Ron wrote: > On Mon, Jul 23, 2012 at 02:38:19PM -0400, Chris Knadle wrote: > > On Monday, July 23, 2012 13:16:55, Ron wrote: > > > On Mon, Jul 23, 2012 at 03:38:44PM +0100, Ian Jackson wrote: > > […] > > > > > Maybe that is true for the gamers, but when I asked I didn't get > > > any confirmation that this was what the problem they saw was - so > > > I'm guessing a bit here, based mostly on the knowledge of what the > > > codecs themselves are capable of. > > > > > > I am actually likewise curious to understand this better if that's > > > not the reason. It's not surprising celt can sound better, but it > > > is quite surprising if speex actually sounds Bad. And for people > > > just talking, and who pay for their traffic by the MB, or who only > > > have a low bandwidth pipe, celt may not be the best choice for them > > > at all anyway. > > > > I seem to recall that the early versions of Mumble that I used defaulted > > to using Speex. I seem to remember it sounding sort of like "a so-so > > cellphone connection", sort of like the person(s) on the other side > > sounded like they might be slightly underwater. i.e. "works but not > > great", whereas CELT sounds very clear [as does Opus]. I can't be > > positive about this though because I might be mixing this memory up with > > my memories of other VoIP packages I've used over the years, so I'm > > likewise curious to hear what Speex sounds like again. > > That's the classic artifact introduced by an echo canceller hunting for > phase lock, which is exactly what causes it in cell phone connections > too. It's not an artifact of the codec itself. > > And unless you really are completely misremembering, really early versions > of mumble used speex 1.1, which is an inferior codec to what we have today, > but is still not responsible for introducing that effect. That all sounds reasonable. Back then I think I was using many of the default settings and as such could have been using echo cancelation. These days I've turned that off because it can sometimes cause echo rather than canceling it. Speex 1.1 sounds familiar. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Tuesday, July 24, 2012 15:37:51, Ron wrote: > On Tue, Jul 24, 2012 at 06:25:04PM +0100, Ian Jackson wrote: […] > My current understanding is that the code given as celt 0.7.0 in the > current mumble source *is* in fact 0.7.1, though I need to diff that > against the upstream 0.7.1 to be absolutely certain still. At least in terms of what's in the "349" -2 in Sid and the celt 0.7.1 library in Wheezy, it looks to me like the code is exactly the same. $ diff -r -u celt-0.7.1/libcelt mumble/celt-0.7.0-src/libcelt Only in celt-0.7.1/libcelt: Makefile.in -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Tuesday, July 24, 2012 04:59:29, Nicos Gollan wrote: […] On Monday, July 23, 2012 15:25:17, Ron wrote: > > Speex is our most certain baseline, because all clients support it, > > and no server support is required. > > Support for speex was a hack around disabilities of CELT at low bandwidths, > and it could easily be added because the decoder was already in the client, > so it was a non-breaking change to have clients just send speex encoded > audio and be universally understood. Still, there is no way for a client > to make other clients use speex. I will, however, happily declare being > wrong about that once the magic fix-all speex patch hits and actually > works. > > **Sidenote:** Discussion about the qualities of different codecs, what they > were made for, or what people want to use Mumble for, is certainly out of > scope for this issue. With the qualities of Opus, it would certainly make a > worthwhile topic on the Mumble forum. The way you've described this, /if/ the trick with Speex does work, and the Debian version of Mumble ships without CELT, it would mean that if any Debian user shows up on a public server then all users would switch to using Speex. If that's the case, then the audio quality of Speex vs Celt and the latency each has matters to an extent. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Wednesday, July 25, 2012 03:40:52, Nicos Gollan wrote: > Hi, > > On Wednesday 25 July 2012 03:50:23 Chris Knadle wrote: > > The way you've described this, /if/ the trick with Speex does work, and > > the Debian version of Mumble ships without CELT, it would mean that if > > any Debian user shows up on a public server then all users would switch > > to using Speex. If that's the case, then the audio quality of Speex vs > > Celt and the latency each has matters to an extent. > > If "the trick with speex" works and is actually deemed necessary, then > we're talking about a package providing the absolute minimum of > interoperability without any ambition to providing quality. And yes, for > it to work, it would need to switch all clients within hearing range to > using speex with all the penalties in quality and latency that brings. Yeah... I'm not liking the sound of that. For instance one of the things that are common on public Mumble/Murmur servers are one or more "music channels" among the many other channels for teams of gamers. Forcing all of that through a low-quality codec meant only for voice communication sounds very undesirable from the user perspective. > However, as suggested earlier, statistics also show that users on Linux > platforms make up not quite 2% of the overall userbase, and users affected > by the hack would be well below that (my guess would put them under one > per mil). With that in mind, it would be easy for users to just kick the > offending handful of clients worldwide off their servers if the need > arises, since it would be a very rare occurrence. That makes the impact on > the overall userbase absolutely negligible. [I'm sure you know the following, but I'm explaining this in more detail for those that may not be familiar with it.] Normally users cannot kick nor ban another user off the server. To kick an offending client off the server would require SuperUser priviliges in the Mumble/Murmur server, or for kick/ban priviliges to be delegated to specific users via Groups or ACL rules in the server. After that, this would involve right-clicking on the suspected offending client and getting Information on the client version, *somehow* figuring out that that version of Mumble was causing the problem (i.e. "the Debian version of Mumble is a problem" from a web search), and then finding someone with kick/ban priviliges to get the offending client off. Then presumably someone has to leave the server and return in order to get the server to renegotiate the codec used. I wouldn't characterize the above as "easy" -- although it is easy in the sense that it doesn't require reconfiguring the host machine to do it. It would be easier for users to text the offending client and ask that the user leave, but this would also involve understanding and explaining the situation. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 13:26:57, Don Armstrong wrote: > On Mon, 23 Jul 2012, Chris Knadle wrote: > > On Monday, July 23, 2012 10:34:28, Ian Jackson wrote: > > > Of these 2. would seem to be the best option. > > > > I agree. > > [...] > > I believe in order to actually evaluate any of these solutions, > someone is going to have to prepare binaries, and do an table showing > the tested (not theoretical) compatibility of with multiple different > clients (and servers?) to their solution's server and client. > > I propose that whoever wants to see a particular solution actually sit > down and do the work for their particular solution, with sources, > binaries, interdiffs, and compatibility table conveniently available in > some public location. Attached is a patch for fixing the build on the "348" version of Mumble in Wheezy. Two files, of which only one or the other is required: one is a standard diff which can be used to patch the "348" version as-is via "patch - p1 < " while in the source package directory. The other is an mbox file for importing via 'git am ' against the latest tagged version of "348", v1.2.3-348-g317f5a0-1. The patch consists of cherry-picked git commits from the "349" version, plus one commit after doing a 'dch -i' to add a changelog entry [automatically marked as a .1 NMU, which for the moment I haven't changed]. This version still requires libcelt. I'm currently testing this -1.1 on both client and server -- all seems well so far. [Tables of compatability to follow.] I think the "348" version includes the Speex codec, but I haven't been able to trigger its use yet experimentally. Quick summary of changes: - Remove broken mumble-server-web package - Change maintainer from Debian VoIP team to Ron Lee - Remove Patrick Matthäi from Uploaders - Hardcode use of and add dependency on g++-4.6 - Remove boot 1.46 dependency resolution - Remove libgl dependency resolution - Depend on ice34 and drop resolution via older versions I'm also still working on how to do the embedded celt version; by default embedding CELT will enable both embedded 0.7.1 and 0.11.0 so enabling only 0.7.1 will require a quilt patch to modify the original source build directives slightly. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 mumble-348-fixes.mbox Description: application/mbox diff --git a/debian/MurmurPHP.ini b/debian/MurmurPHP.ini deleted file mode 100644 index 4937106..000 --- a/debian/MurmurPHP.ini +++ /dev/null @@ -1 +0,0 @@ -ice.slice=/usr/share/slice/Murmur.ice diff --git a/debian/changelog b/debian/changelog index e0fa95f..d53fa2b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,16 @@ +mumble (1.2.3-348-g317f5a0-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Remove broken mumble-server-web package + * Change maintainer from Debian VoIP team to Ron Lee + * Remove uploader Patrick Matthäi + * Hardcode use of and add dependency on g++-4.6 + * Remove boot 1.46 dependency resolution + * Remove libgl dependency resolution + * Depend on ice34 and drop resolution via older versions + + -- Christopher Knadle Mon, 30 Jul 2012 02:00:32 -0400 + mumble (1.2.3-348-g317f5a0-1) unstable; urgency=low * New upstream snapshot from 20.05.2012. diff --git a/debian/control b/debian/control index 435588e..b360e0f 100644 --- a/debian/control +++ b/debian/control @@ -2,16 +2,15 @@ Source: mumble Section: sound Priority: optional Homepage: http://mumble.sourceforge.net/ -Maintainer: Debian VoIP Team -Uploaders: Patrick Matthäi , - Thorvald Natvig -Build-Depends: debhelper (>= 7.0.8), +Maintainer: Ron Lee +Uploaders: Thorvald Natvig +Build-Depends: debhelper (>= 7.0.8), g++-4.6, po-debconf, - libboost1.46-dev | libboost-dev (>= 1.38.0), - libboost-python1.46-dev | libboost-python-dev (>= 1.38.0), + libboost-dev (>= 1.42), + libboost-python-dev (>= 1.42), libqt4-dev (>= 4.5.0), hardening-wrapper, - libgl1-mesa-dev | libgl-dev, + libgl1-mesa-dev, libasound2-dev, libpulse-dev, libogg-dev, @@ -20,9 +19,9 @@ Build-Depends: debhelper (>= 7.0.8), libcelt-dev (>= 0.7.0), libsndfile1-dev, libssl-dev, - libzeroc-ice34-dev | libzeroc-ice33-dev | libzeroc-ice32-dev | libzeroc-ice-dev, - ice34-translators | ice33-translators | ice32-translators | ice-translators, - ice34-slice | ice33-slice | ice32-slice | ice-slice, + libzeroc-ice34-dev (>= 3.4.2-8.1), + ice34-translators (>= 3.4.2-8.1), + ice34-slice (>= 3.4.2-8.1), libg15daemon-client-dev, libspeechd-dev, protobuf-compiler, @@ -87,21 +86,3 @@ Description: Low latency VoIP client (debugging symbols) . This package contains the debugging symbols for the 'mumble' and 'mumble-server' packages.
Bug#675971: Bug#682010: [mumble] Communication failures due to CELT codec library removal
On Monday, July 23, 2012 13:26:57, Don Armstrong wrote:
> On Mon, 23 Jul 2012, Chris Knadle wrote:
> > On Monday, July 23, 2012 10:34:28, Ian Jackson wrote:
> > > Of these 2. would seem to be the best option.
> >
> > I agree.
>
> [...]
>
> I believe in order to actually evaluate any of these solutions,
> someone is going to have to prepare binaries, and do an table showing
> the tested (not theoretical) compatibility of with multiple different
> clients (and servers?) to their solution's server and client.
>
> I propose that whoever wants to see a particular solution actually sit
> down and do the work for their particular solution, with sources,
> binaries, interdiffs, and compatibility table conveniently available in
> some public location.
Attached is a patch for fixing the build for the "348" version of Mumble in
Wheezy, which includes embedding celt 0.7.1 into the mumble package and
removing the dependency on the celt library. There are two versions attached:
a diff that can be applied directly via 'patch -p1 < ', and an mbox file
that can be applied to the git repository via 'git am ' against tag
v1.2.3-348-g317f5a0-1.
Quick summary of changes:
- Remove broken mumble-server-web package
- Change maintainer from Debian VoIP team to Ron Lee
- Remove Patrick Matthäi from Uploaders
- Hardcode use of and add dependency on g++-4.6
- Remove boost 1.46 dependency resolution
- Remove libgl dependency resolution
- Depend on ice34 and drop resolution via older versions
- Build and embed celt 0.7.1 (and not celt 0.11.0)
One interesting difference when using the embedded version rather than the
celt library is that Mumble reports using "Celt 0.7.0" in the Server ->
Information screen, rather than "Celt 0.0.0" that is reported when using the
external celt library.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
diff --git a/debian/MurmurPHP.ini b/debian/MurmurPHP.ini
deleted file mode 100644
index 4937106..000
--- a/debian/MurmurPHP.ini
+++ /dev/null
@@ -1 +0,0 @@
-ice.slice=/usr/share/slice/Murmur.ice
diff --git a/debian/changelog b/debian/changelog
index e0fa95f..79bd682 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+mumble (1.2.3-348-g317f5a0-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Remove broken mumble-server-web package
+ * Change maintainer from Debian VoIP team to Ron Lee
+ * Remove uploader Patrick Matthäi
+ * Hardcode use of and add dependency on g++-4.6
+ * Remove boost 1.46 dependency resolution
+ * Remove libgl dependency resolution
+ * Depend on ice34 and drop resolution via older versions
+ * Use embedded celt 0.7.1
+
+ -- Christopher Knadle Wed, 01 Aug 2012 06:42:30 -0400
+
mumble (1.2.3-348-g317f5a0-1) unstable; urgency=low
* New upstream snapshot from 20.05.2012.
diff --git a/debian/control b/debian/control
index 435588e..066ad12 100644
--- a/debian/control
+++ b/debian/control
@@ -2,27 +2,25 @@ Source: mumble
Section: sound
Priority: optional
Homepage: http://mumble.sourceforge.net/
-Maintainer: Debian VoIP Team
-Uploaders: Patrick Matthäi ,
- Thorvald Natvig
-Build-Depends: debhelper (>= 7.0.8),
+Maintainer: Ron Lee
+Uploaders: Thorvald Natvig
+Build-Depends: debhelper (>= 7.0.8), g++-4.6,
po-debconf,
- libboost1.46-dev | libboost-dev (>= 1.38.0),
- libboost-python1.46-dev | libboost-python-dev (>= 1.38.0),
+ libboost-dev (>= 1.42),
+ libboost-python-dev (>= 1.42),
libqt4-dev (>= 4.5.0),
hardening-wrapper,
- libgl1-mesa-dev | libgl-dev,
+ libgl1-mesa-dev,
libasound2-dev,
libpulse-dev,
libogg-dev,
libspeex-dev,
libspeexdsp-dev,
- libcelt-dev (>= 0.7.0),
libsndfile1-dev,
libssl-dev,
- libzeroc-ice34-dev | libzeroc-ice33-dev | libzeroc-ice32-dev | libzeroc-ice-dev,
- ice34-translators | ice33-translators | ice32-translators | ice-translators,
- ice34-slice | ice33-slice | ice32-slice | ice-slice,
+ libzeroc-ice34-dev (>= 3.4.2-8.1),
+ ice34-translators (>= 3.4.2-8.1),
+ ice34-slice (>= 3.4.2-8.1),
libg15daemon-client-dev,
libspeechd-dev,
protobuf-compiler,
@@ -38,7 +36,6 @@ Package: mumble
Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends},
- libcelt0 (>= 0.7.0) | libcelt0-0 (>= 0.7.1~),
libqt4-sql-sqlite,
lsb-release
Recommends: speech-dispatcher
@@ -87,21 +84,3 @@ Description: Low latency VoIP client (debugging symbols)
.
This package contains the debugging symbols for the 'mumble' and
'mumble-server' packages.
-
-Package: mumble-server-web
-Architecture: all
-Depends: ${misc:Depends},
- ${perl:Depends},
- mumble-server (>= ${binary:Version}),
- apache2,
- exim4 | mail-transport-agent,
- libnet-dbus-perl,
- libcgi-session-perl,
- libhtml-template-perl,
- php-zeroc-ice,
- ice34-translators | ice33-translators | ice3
Bug#681834: Call for votes on network-manager, gnome
On Tuesday, September 11, 2012 13:52:47, Jeremy Bicha wrote: > I see two things missing from this resolution: > 1. GNOME has a stronger dependency on NM than they did when Squeeze > was released. GNOME Shell now has a hard dependency on NM. > > > The user has to take separate, explicit (and somewhat unusual for the > > average user) action to disable network-manager after it has been > > installed. > > 2. Yes, but it is also unusual for the average user to need to disable > NM. For the average user, the consequences of not having NM are quite > a bit worse than the benefits of being able to set up networking by > hand. It's definitely possible to disable NM and the procedure to do > this could easily be release-noted. Comments on your two cents: - There are other network managers than NM. - I experienced breakages on NM on upgrades on several occasions, whereby I switched to wicd. - My experience has been that NM conflicts with wicd when NM is running. - Furthermore my experience has been that disabling NM via modifying the init script (i.e. the "exit 0" suggestion which came up on [debian-devel], or making the init script non-executble) only works until NM is upgraded, whereby the init script is replaced and thus the NM daemon starts again -- which on Sid happens fairly regularly. - Wishlist bug #685742 [1] suggested a way to disable NM permanently via a /etc/default/ file (like wicd comes with) but was outright rejected, in favor of instead using "update-rc.d network-manager disable" -- the latter of which isn't mentioned anywhere in the documentation that comes with NM. - For these and several other reasons I'm personally in favor of Recommends rather than Depends for the NM package, as the tech-ctte has outlined. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685742 -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681834: Call for votes on network-manager, gnome
On Tuesday, September 11, 2012 21:59:49, Jeremy Bicha wrote: > On 11 September 2012 21:32, Chris Knadle wrote: > > - There are other network managers than NM. > > Of course, but only one is part of GNOME. Nothing else integrates into > GNOME Shell's top bar or System Settings (gnome-control-center). Hmm. That itself sounds like a bug. > GNOME 2 was different as wicd could integrate just as well as > NetworkManager did. > > > - My experience has been that NM conflicts with wicd when NM is running. > > You have two network managers running on your computer and you expect > networking to not have problems? On a Wheezy VM I've been running (to do testing on the mumble package), originally wicd was installed by default, but on an upgrade task-xfce-desktop pulled in network-manager (via a Recommends on network-manager-gnome I believe), leading to both running. Certainly not the desired behavior, but surprisingly it actually worked for standard "wired" networking via dhcp. […] > It looks like you're right that NetworkManager itself doesn't come > with documentation for disabling itself but maybe it should. 'man > update-rc.d' works too though. Yeah, as long as you know the command you need already; whether or not that's obvious is certainly debatable. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681834: Call for votes on network-manager, gnome
On Tuesday, September 11, 2012 22:04:08, Russ Allbery wrote: > Chris Knadle writes: > > - Furthermore my experience has been that disabling NM via modifying the > > init script (i.e. the "exit 0" suggestion which came up on > > [debian-devel], or making the init script non-executble) only works > > until NM is upgraded, whereby the init script is replaced and thus the > > NM daemon starts again -- which on Sid happens fairly regularly. > > The correct way to disable network-manager, or any other init script in > Debian, is: > > update-rc.d disable > > This will be preserved on upgrades. Yes, I caught that earlier in the thread (before replying). My point in bringing this up is that I think the first instinct someone has is to disable the init script -- and this suggestion came up both in this thread as well as on [debian-devel], which only works temporarily. > > - Wishlist bug #685742 [1] suggested a way to disable NM permanently via > > a /etc/default/ file (like wicd comes with) but was outright > > rejected, in favor of instead using "update-rc.d network-manager > > disable" -- the latter of which isn't mentioned anywhere in the > > documentation that comes with NM. > > That's understandable since it has nothing specific to do with > network-manager; rather, it's a standard interface in Debian for any init > script. > > Most of the /etc/default hacks to disable daemons predate the > standardization of the enable/disable interface in update-rc.d, or at > least its widespread publication. Okay. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672318: chirp 0.3.0-0.1 Debian package available
Greetings. I recently got a new rig, a small HT, and needed chirp to program it. Unfortunately the version of the packge in Debian now doesn't work for the rig, and I found the year-old wishlist bug #672318 requesting a new version. I've prepared a new 0.3.0-0.1 package (currently as an NMU) and made several other changes -- the debian/rules file now uses dh. If someone has time to take a peek and review this source package, I'd appreciate it. ;-) http://debian-packages.coredump.us/debian/pool/main/c/chirp/ Thanks. -- Chris, KB2IQN -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672318: chirp 0.3.0-0.1 Debian package available
On Friday, April 05, 2013 02:46:15, David A Aitcheson wrote: > Chris, > > Did you try the "Chirp-Daily" package? It is almost DAILY in its updates > and working FB for me on Ubuntu 12.04-LTS. I'm running Debian Sid/Unstable. > Please look at https://launchpad.net/ubuntu/+source/chirp before you > proceed much more. The above package shows version 0.1.12 -- it wouldn't have worked for me. And besides, I've actually /completed/ packaging 0.3.0 (AFAIK, except if there are further desired changes) -- and I'm actually using it, and it does the job I need it to do. ;-) > The PPA for chirp is at > https://launchpad.net/~dansmith/+archive/chirp-snapshots I've often had issues using Ubuntu PPAs on Debian. Sometimes they work... sometimes they don't, due to differences between the distributions, usually in dependencies. Now... having a look at it, the closest package that would fit in the PPA would be the one for Precise (because Debian Sid is by definition 6 months newer than Ubuntu releases), but the chirp-daily package for Precice in this PPA doesn't have a version available for amd64. I've downloaded the source package so I can have a look and compare it with the packge I just put together. > Dave - KB3EFS > > PS - A fork similar to this is what caused all the problems with "NODE". > Did we not learn anything from that drawn out over more than a decade mess? Debian packages are generally based on "stable" tested versions of upstream projects rather than daily builds, so (AFAIK) it would probably not be fitting to pull this Ubuntu PPA package into Debian. The main issue I know about with the "node" package was the naming conflict; I wasn't aware of the fork issue. This isn't a fork of of the chirp package, it's just a different package version of the same software with the same name. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672318: chirp 0.3.0-0.1 Debian package available
On Friday, April 05, 2013 09:15:15, Chris Knadle wrote: > On Friday, April 05, 2013 02:46:15, David A Aitcheson wrote: [...] > > The PPA for chirp is at > > https://launchpad.net/~dansmith/+archive/chirp-snapshots [...] > I've downloaded the source package so I can have a look and compare it > with the packge I just put together. Just did a quick review; putting aside the source code differences (because the PPA is a daily build rather than of the 0.3.0 version), the main differences in the packaging are mostly superficial: - package name (chirp vs chirp-daily) - debhelper compat (9 vs 7) - Standards-Version (3.9.4 vs 3.9.2) - dependencies (chirp-daily depends on python-suds) - copyright file (1.0 format vs and older format) - patch set (different sources so this is expected) - addition of the --with-python2 option to dh in the rules file, which was required to upgrade to compat 9 I don't see any changes I need to make based on the comparison. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704211: [release-notes] [wheezy] issues: NM conflicts with wicd-daemon, Gnome3 now depends on NM
tags 704211 + patch thanks Patches attached for a proposed update for the release-notes concerning conflicts between NetworkManager and wicd-daemon (and possibly others). These are based on release-notes svn revision 9694. issues-NM.dbk.diff-> explains NM <-> wicd conflict and a workaround whats-new-NM.dbk.diff -> mentions some NetworkManager features and points to conflict section if another networking manager is desired. These patches are separate so that the two sections can be updated independently of one-another. I'm willing to keep these patches updated if changes to the wording are desired. Thanks. [Joost: not sure why, but I only saw your message in BTS just now and did not receive it in email.] -- Chris -- Chris Knadle chris.kna...@coredump.us Description: update issues.dbk for conflicts between NetworkManager and other network management daemons, such as wicd-daemon Author: Christopher Knadle === --- en/issues.dbk(revision 9694) +++ en/issues.dbk(working copy) @@ -106,21 +106,62 @@ the current Chromium releases for stable. GNOME desktop changes and support - - By default, most accessibility tools are not enabled in the GNOME display - manager (gdm3). In order to enable screen reading, zooming, or a visual - keyboard, the simplest way is to enable the shell greeter. - + + Accessibility + +By default, most accessibility tools are not enabled in the GNOME display +manager (gdm3). In order to enable screen reading, zooming, or a visual +keyboard, the simplest way is to enable the shell greeter. + + +To do that, edit the /etc/gdm3/greeter.gsettings file, +and uncomment the following: + session-name='gdm-shell' +while commenting + session-name='gdm-fallback' +Note that it requires a compatible 3D graphics card — which is the reason +why it is not enabled by default. + + + + NetworkManager + +The package chain in GNOME now Depends on +network-manager. At present, +NetworkManager can detect if a network interface is +managed by ifupdown to avoid conflicts with it, but +does not detect other networking manager programs such as +wicd-daemon. Problems and unexpected behavior can +result if two network manager daemons are managing the same interface +when attempting to make a networking connection. + + +For instance, if wicd-daemon and +NetworkManager are both running, attempting to use a +wicd client to make a connection will fail with a +counterintuitive error message: +Connection Failed: bad password +Attempting to use a NetworkManager client may likewise +fail with the message: +NetworkManager is not running. Please start it. +The network-manager package +cannot easily be removed due to it now being a GNOME dependency, but if +continuing to use another networking manager is desired, the +NetworkManager daemon may remain installed but be +permanently disabled in a way which is persistant through upgrades with +the following command: +# update-rc.d network-manager disable +Also examine the contents of /etc/resolv.conf, which +is used to specify DNS servers for name resolution, as the contents of +this file are normally replaced by NetworkManager. + + +Further information is available in bugs +#681834 and +#688772. + + - - To do that, edit the /etc/gdm3/greeter.gsettings file, - and uncomment the following: -session-name='gdm-shell' - while commenting -session-name='gdm-fallback' - Note that it requires a compatible 3D graphics card — which is the reason - why it is not enabled by default. - Description: update whats-new.dbk to mention NetworkManager and wicd-daemon, link to possible conflicts Author: Christopher Knadle === --- en/whats-new.dbk(revision 9694) +++ en/whats-new.dbk(working copy) @@ -656,6 +656,19 @@ deb-src &url-debian-mirror-eg;/debian &releasename;-updates main contrib + +Network management + + GNOME now features online connectivity awareness with several + applications along with the GNOME shell using + NetworkManager, which features IPv6 compatibility and + network connection awareness for GNOME applications. If you are + planning on using another network management daemon (such as + wicd-daemon), please see Section + concerning possible + conflicts. + + signature.asc Description: This is a digitally signed message part.
Bug#704211: [release-notes] [wheezy] issues: NM conflicts with wicd-daemon, Gnome3 now depends on NM
(sorry for the dupe, forgot to include this to the BTS) On Saturday, April 06, 2013 01:47:15, Joost van Baal-Ilić wrote: > Hi Chris, > > Thanks for these nice patches. Some comments though: > In the TC-bug > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688772#532 > has some text on why using n-m with gnome is a good idea. Yes, as I mentioned I didn't get your (previous) BTS message as email, and only saw it after-the-fact as I was about to send the patches. [I did get /this/ one as email, thankfully.] I sent these patches anyway because I also want others to have a baseline to allow further suggested changes. ;) > You didn't quote that. I feel it's important: people who > previously choose not to run n-m might want to reconsider > that, since n-m got much improved. It's helpful to list > those improvements. Okay. I can use some of the hints from your prior email to the BTS; I don't use NM much myself, so I don't have first-hand knowledge of improvements it has recently gotten. > And in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688772#665 > Technical Commitee stated: > > 6. We request that a release note is created explaining that gnome > users who do not currently have NM installed consider installing > it. > > I didn't see that reflected. Care to get that in, too? Yes, I plan to do that this morning. Would you like this in the 2.2.5.4 section, or the 5.4.2 section? (Or both?) AFAICT it makes sense to put into the 5.4.2 section, e.g. something like: "It is suggested that installing NM be considered because it has features that other networking managers lack (such as IPv6 support), but if use of another network manager is desired, the NetworkManager daemon may remain installed but be permanently disabled [...]" > Thanks for your work! :) Thanks for yours. > (More remarks below.) […] > > [Joost: not sure why, but I only saw your message in BTS just now and did > > not receive it in email.] > > Hrm, strange. I'll check for a bounce on my side. Yeah I looked for a rejection in my mail logs and didn't see one, so not sure what happened. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704211: e: Bug#704211: [release-notes] [wheezy] issues: NM conflicts with wicd-daemon, Gnome3 now depends on NM
Okay... updated patches attached. These are still based on svn r9694. I was trying to update them for r9709 using Git, but I've apparently forgotten how to do a pull between local branches. If you have any other suggested changes, just let me know and I'll update these again. ;) Thanks much. -- Chris -- Chris Knadle chris.kna...@coredump.us Description: update issues.dbk for conflicts between NetworkManager and other network management daemons, such as wicd-daemon Author: Christopher Knadle === --- en/issues.dbk(revision 9694) +++ en/issues.dbk(working copy) @@ -106,21 +106,62 @@ the current Chromium releases for stable. GNOME desktop changes and support - - By default, most accessibility tools are not enabled in the GNOME display - manager (gdm3). In order to enable screen reading, zooming, or a visual - keyboard, the simplest way is to enable the shell greeter. - + + Accessibility + +By default, most accessibility tools are not enabled in the GNOME display +manager (gdm3). In order to enable screen reading, zooming, or a visual +keyboard, the simplest way is to enable the shell greeter. + + +To do that, edit the /etc/gdm3/greeter.gsettings file, +and uncomment the following: + session-name='gdm-shell' +while commenting + session-name='gdm-fallback' +Note that it requires a compatible 3D graphics card — which is the reason +why it is not enabled by default. + + + + NetworkManager + +At present, NetworkManager can detect if a network +interface is managed by ifupdown to avoid conflicts +with it, but does not detect other networking manager programs such as +wicd-daemon. Problems and unexpected behavior can +result if two network manager daemons are managing the same interface +when attempting to make a networking connection. + + +For instance, if wicd-daemon and +NetworkManager are both running, attempting to use a +wicd client to make a connection will fail with a +counterintuitive error message: +Connection Failed: bad password +Attempting to use a NetworkManager client may likewise +fail with the message: +NetworkManager is not running. Please start it. +The network-manager package +cannot easily be removed due to it now being a dependency in the GNOME +package chain. It is is recommended that users of GNOME consider +installing and trying NetworkManager, but if continuing +to use another networking manager is desired, the +NetworkManager daemon may remain installed but be +permanently disabled in a way which is persistant through upgrades with +the following command: +# update-rc.d network-manager disable +Also examine the contents of /etc/resolv.conf, which +is used to specify DNS servers for name resolution, as the contents of +this file are normally replaced by NetworkManager. + + +Further information is available in bugs +#681834 and +#688772. + + - - To do that, edit the /etc/gdm3/greeter.gsettings file, - and uncomment the following: -session-name='gdm-shell' - while commenting -session-name='gdm-fallback' - Note that it requires a compatible 3D graphics card — which is the reason - why it is not enabled by default. - Description: update whats-new.dbk to mention NetworkManager and wicd-daemon, link to possible conflicts Author: Christopher Knadle === --- en/whats-new.dbk(revision 9694) +++ en/whats-new.dbk(working copy) @@ -656,6 +656,24 @@ deb-src &url-debian-mirror-eg;/debian &releasename;-updates main contrib + +Network management + + GNOME now features online connectivity awareness with several + applications along with the GNOME shell using + NetworkManager, which features IPv6 compatibility + along with a wide range of networking technologies (VPN, wireless, 3G). + GNOME users are strongly advised to use + NetworkManager for network connectivity; the GNOME + components work best with NetworkManager. + + + If you are planning on using another network management daemon instead + (such as wicd-daemon), please see Section + concerning possible + conflicts. + + signature.asc Description: This is a digitally signed message part.
Bug#688772: Dependency of meta-gnome on network-manager
Patches to the release-notes document to discuss the symptoms and workaround for the conflict between NM and wicd-daemon are available in #704211. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704211: [release-notes] [wheezy] issues: NM conflicts with wicd-daemon, Gnome3 now depends on NM
On Sunday, April 07, 2013 02:22:17, Andrei POPESCU wrote: > On Vi, 29 mar 13, 09:45:11, Chris Knadle wrote: > > You will also need to recreate /etc/resolv.conf, as the contents of this > > file is replaced by NetworkManager. > > Isn't this done by wicd-daemon (maybe by restarting it)? It doesn't. Also keep in mind that wicd can be set for all kinds of configurations, such that it may not touch this file even making a connection. [I have what appear to be default settings, and this is the behavior I see on my home network, for instance.] /By default/ NM seems to replace /etc/resolv.conf on the first connection attempt. This entry in the release-notes is aimed for Gnome users that /didn't/ previously have network-manager installed, thus may be using wicd. The first thing these users are likely to do is try wicd and find it broken due to the conflict, then try NM and find it broken too -- and the connection attempt with NM replaces the /etc/resolv.conf file, where wicd may not. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#704211: [release-notes] [wheezy] issues: NM conflicts with wicd-daemon, Gnome3 now depends on NM
On Sunday, April 07, 2013 12:50:14, Andrei POPESCU wrote: > On Du, 07 apr 13, 12:10:28, Chris Knadle wrote: > > On Sunday, April 07, 2013 02:22:17, Andrei POPESCU wrote: > > > On Vi, 29 mar 13, 09:45:11, Chris Knadle wrote: > > > > You will also need to recreate /etc/resolv.conf, as the contents of > > > > this file is replaced by NetworkManager. > > > > > > Isn't this done by wicd-daemon (maybe by restarting it)? > > > > It doesn't. Also keep in mind that wicd can be set for all kinds of > > configurations, such that it may not touch this file even making a > > connection. [I have what appear to be default settings, and this is the > > behavior I see on my home network, for instance.] > > This doesn't sound right. Wicd has got to have some resolv.conf > handling, otherwise it wouldn't be very useful. Maybe the maintainer can > help out here? wicd can use a dhcp client (dhcpcd, pump, dhclient, udhcpc, "automatic"), but doesn't necessarily have to. (My settings are in "automatic" right now.) But there are always some cases where /etc/resolv.conf aren't normally overwritten (and that's not something confined to wicd). The warning about /etc/resolv.conf being replaced by NM is generic so that if a user has this case they can investigate and fix it. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#704870: opus: cve-2013-0899
tags 704870 + patch
thanks
Gregor -- thanks for finding the links.
The .diff just had different line numbers, so would likely apply with fuzz,
but I made a quick patch that doesn't agaist the git repo.
I would have made a quilt patch, but this looks like a package in 1.0 format.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
From d5aeb4fa4ff5e93deb7641359678d91b49fae4b0 Mon Sep 17 00:00:00 2001
From: Christopher Knadle
Date: Mon, 8 Apr 2013 17:59:28 -0400
Subject: [PATCH] fix for CVE-2013-0899
Fix possible overflow padding by feeding ~16 MB of 0xff bytes to the decoder
Thanks to Gregor Herrmann for finding these links with more detail:
https://code.google.com/p/chromium/issues/detail?id=160480
http://git.xiph.org/?p=opus.git;a=commitdiff;h=9345aaa5ca1c2fb7d62981b2a538e0ce20612c38
---
src/opus_decoder.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/opus_decoder.c b/src/opus_decoder.c
index 24869e7..7d2219d 100644
--- a/src/opus_decoder.c
+++ b/src/opus_decoder.c
@@ -596,16 +596,14 @@ static int opus_packet_parse_impl(const unsigned char *data, opus_int32 len,
/* Padding flag is bit 6 */
if (ch&0x40)
{
- int padding=0;
int p;
do {
if (len<=0)
return OPUS_INVALID_PACKET;
p = *data++;
len--;
-padding += p==255 ? 254: p;
+len -= p==255 ? 254: p;
} while (p==255);
- len -= padding;
}
if (len<0)
return OPUS_INVALID_PACKET;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part.
Bug#694388: lscpi data, BCD file information
Additional information for bug report; thanks, Ron, for retrieving and sending me the information. :-) I'm attaching the \Boot\BCD file that the Windows Boot Manager is complaining about; 'file' reports this to be: $ file BCD BCD: MS Windows registry file, NT/2000 or above :-( The Debian 'reglookup' package is able to parse this; it looks like it's got partition information in it for Windows 8 to be able to find bootable elements. Output of 'lscpi -knn' on the IdeaPad P500: --- 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09) Subsystem: Lenovo Device [17aa:3977] Kernel driver in use: agpgart-intel 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) Subsystem: Lenovo Device [17aa:3904] Kernel driver in use: i915 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) Subsystem: Lenovo Device [17aa:3977] Kernel driver in use: xhci_hcd 00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04) Subsystem: Lenovo Device [17aa:3977] 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) Subsystem: Lenovo Device [17aa:3977] Kernel driver in use: ehci_hcd 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04) Subsystem: Lenovo Device [17aa:3977] Kernel driver in use: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4) Kernel driver in use: pcieport 00:1c.1 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 [8086:1e12] (rev c4) Kernel driver in use: pcieport 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04) Subsystem: Lenovo Device [17aa:3977] Kernel driver in use: ehci_hcd 00:1f.0 ISA bridge [0601]: Intel Corporation HM76 Express Chipset LPC Controller [8086:1e59] (rev 04) Subsystem: Lenovo Device [17aa:3977] 00:1f.2 SATA controller [0106]: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e03] (rev 04) Subsystem: Lenovo Device [17aa:3977] Kernel driver in use: ahci 00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller [8086:1e22] (rev 04) Subsystem: Lenovo Device [17aa:3977] 01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller [10ec:8136] (rev 05) Subsystem: Lenovo Device [17aa:3977] Kernel driver in use: r8169 02:00.0 Network controller [0280]: Intel Corporation Centrino Wireless-N 2230 [8086:0888] (rev c4) Subsystem: Intel Corporation Centrino Wireless-N 2230 BGN [8086:4262] Kernel driver in use: iwlwifi -- Chris -- Chris Knadle chris.kna...@coredump.us BCD Description: Binary data signature.asc Description: This is a digitally signed message part.
Bug#693351: RM: kismet/2008-05-R1-4.3
On Wednesday, December 12, 2012 10:18:54, Nick Andrik wrote: > 2012/12/12 intrigeri : > > Hi, > > > > Nick Andrik wrote (12 Dec 2012 14:32:35 GMT) : > >> I don't have strong feelings in any case, I don't expect someone to be > >> using this version of the package nowadays. > >> On the other hand, I don't also see the clear benefits from removing it. > > > > OK. I think the key question then becomes: as the upcoming maintainer > > of kismet in Debian, do you want to commit to maintain 2008-05-R1-4.3 > > in stable once Wheezy is released? (as in: dealing with security > > issues, fixing RC bugs through stable updates, answering bug > > reports, etc.) > > If there are any bugs reported on functionality (which I doubt) then > it makes no sense trying to fix the 2008 version. Ubuntu has several SIGSEGV crashes reported on kismet 2008-05-R1-4.3: https://launchpad.net/ubuntu/+source/kismet/+bugs Upstream (Mike Kershaw, who I see at MHVLUG meetings) is frustrated by the fact that this old version of kismet is still being shipped in Ubuntu, because he regularly gets bugs reported to him directly from users that he isn't able to help with because the version is ancient. I'm adding Mike to the list of recipients so that he can have a chance to offer an opinion on whether 2008-06-R1-4.3 should be shipped in Wheezy (and thus shipped for another two years in Debian). It'll be good to get a newer Kismet package in Unstable, since Ubuntu is based on Unstable. > All other bugs are OK. > > BTW, I guess there is no chance to have the new package in wheezy once > it gets released, is this correct? To get a new version in it would have had to have been in Unstable before the freeze in June. Around that time I made a newer Kismet package using debhelper v9, but it wasn't ready before the freeze and the package I made still needs a couple of tweaks, which is why I hadn't tried to file an ITA. Nick -- let me know if you'd like to see what I did re: /debian/* files. The main thing that needs tweaking in the package I came up with had to do with the menu shortcut and how to handle access permissions correctly. > If we need to fix anything then I will have to keep different branches, > i.e. one for stable and one for testing, right? Maybe. There will be different package versions, but "branches" implies using a version control system which isn't a requirement AFAIK. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#693351: RM: kismet/2008-05-R1-4.3
able? IMHO, no. To install the package in Testing on a Stable box requires switching Debian trees temporarily and usually ends up requiring upgrading other packages due to version dependencies, and thus results in the box being in a "mixed tree" state; then the admin switches trees back to Stable, whereby the box doesn't get security updates for the packages that came from Testing. [I occasionally do this, and so far I've gotten away with it, but it wouldn't be something I'd advise someone else to do.] A better plan for this, IMHO, would be to use backports.debian.org for having an upgraded package for Stable available, which could thus stick with the packages in Stable as much as possible, and thus continue to get security updates. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#680884: [p0f] Please update to v3 [use case]
Hello Axel. On Tuesday, April 23, 2013 11:23:44, Axel Beckert wrote: ... > > I would be really happy if I would be able to use p0f in Debian to > > inform XP users that their OS will be EoL soon. :-) > > For that I needed a package of p0f v3 anyway, so I built one. :-) I've been doing the same elsewhere. ;-) > I've put a source package and an amd64 package online here: > > http://noone.org/debian/p0f_3.06b-1.dsc (signed) > http://noone.org/debian/p0f_3.06b-1_amd64.deb > http://noone.org/debian/p0f_3.06b-1_amd64.changes (signed and > contains hash sums of p0f_3.06b-1_amd64.deb) > > The .dsc and .changes are signed with my key in the Debian keyring. Just a quick note about the above: the source package conists of the .dsc, the .orig tarball, and the .debian diff tarball. I was able to get those from your website and extract them via 'dpkg-source -x'. You might consider making yourself your own private Debian repository with these packages BTW, which would help both you and others use them. I recently did this; the three main options I considered were reprepro, DAK, and mini- buildd, and I ended up using reprerpo -- it works well for several thousand packages, is packaged for Debian, and has a simple dependency list that doesn't require a web server. The main you'll need is to create a keyring package which drops a .gpg file containing the public signing key(s) into /etc/apt/trusted.gpg.d/. reprepro also needs a gpg key to sign the package list file, so my keyring ended up having two GPG keys becuase I didn't want the secret key for my private GPG key on my server. If the server's GPG key contains a password, you'll also need to run gpg-agent on the server, and configure gnupg for pinentry and install a pinentry package. If you're interested in discussing this more, please contact me. :-) > Cc'ing the original reporter in case the package helps him for his v3 > use case. Thanks much. Builds clean in cowbuilder. Very nice job with the debian/rules file. Likewise with the DEP-3 formatted patches. ;-) Just one hint I was given that I'll pass on: - The debian/copyright file could be upgraded to the 1.0 format. See: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Thanks for your work! :-) -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#702102: Acknowledgement (fails to upgrade (cowbuilder) chroot)
On Wednesday, March 20, 2013 15:25:26, Michael Biebl wrote: > from IRC: > > i ran into that one today, i think. had to set a variable in > pbuilderrc to tell it to not bother mounting shm > iirc it tries to check whether /run/shm exists on the host to > decide whether to use /dev/shm or /run/shm in the chroot > which makes no sense at all > > > That's the problem indeed. I don't have /run/shm (but /dev/shm), and > pbuilder trips over that. Symptoms match: I have /run/shm as well as /dev/shm, and both directories seem bound together. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702102: fails to upgrade (cowbuilder) chroot
On Tuesday, March 26, 2013 08:46:08, Michael Biebl wrote: > Am 26.03.2013 09:48, schrieb Junichi Uekawa: > > not enough information in the bug, 702811 seems to be a better bug. > > Say what? Have you read the full bug report, including the analysis that > it is because of /run/shm vs /dev/shm? Related to this, a patch was incorporated from the following email to handle another bug. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700591#5 Based on the idea that it's somehow this patch that's causing this new problem, I'm "pulling at straws" to try to help figure out why. You mentioned you have /run/shm but not /dev/shm. Based on that I'm looking at the following logic from the patch: +if [ "$DEB_BUILD_ARCH_OS" = "linux" ] && [ "$USEDEVSHM" = "yes" ]; then + SHM_PATH="run/shm" + [ ! -d "/$SHM_PATH" ] && SHM_PATH="dev/shm" This looks to me like it's checking if /run/shm exists (and is a directory), and if it doesn't then blindly uses /dev/shm instead. This seems reasonable but I'm wondering if there's some way for this test to fail. If /run/shm were a /device/ rather than a directory or a softlink to a directory, that would be one way for that to happen. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704211: [release-notes] [wheezy] issues: NM conflicts with wicd-daemon, Gnome3 now depends on NM
Package: release-notes Severity: important --- Please enter the report below this line. --- Greetings. I'm looking to add information to the Release Notes and the Wheezy Errata in order to handle bug #688772 concerning conflict between NetworkMmanager and wicd-daemon. There are about 1800 known [1] installations in which NM is not installed but the "gnome" metapackage is, and the upgrade to a Depends on NM has a likelihood of breaking these installations, and at present there is no documentation available for the symptoms or how to fix it. [I've been hit by this conflict myself, so I know how frustrating a problem this is.] Attached is a text file containing the basic information I'd like to add. I've cloned the release-notes SVN repo for making a patch, but I'd appreciate a hint as to what section to add it to or if there are wording changes desired. Thanks! [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688772#151 -- Chris -- Chris Knadle chris.kna...@coredump.us conflicts with other networking manager daemons ~~~ Gnome upstream chose to couple NetworkManager tightly with the Gnome Shell in order to provide connectivity awareness for both the Shell and Gnome3 applications. For this reason the Gnome3 maintainers in Debian decided to follow upstream and upgrade the Recommends on the network-manager stack to a Depends. It is known that a small number (about 5.7%) of Squeeze installations have Gnome installed but not NetworkManager, and this new Dependency will cause NetowrkManager to be installed upon a distribution upgrade to Wheezy. At present, NetworkManager can detect if an interface is managed by ifupdown to avoid conflicts with it, but does not detect other networking manager programs such as wicd-daemon. Problems and unexpected behavior can ensue if two network manager daemons are managing the same interface when attempting to make a networking connection. This issue was discussed by the Debian Technical Committee in #681834 and #688772. If wicd-daemon and NetworkManager are both running, a wicd client will fail to make a connection with the counterintuitive message: "Connection Failed: bad password" Trying a NetworkManager client may sometimes result in the message (even when NetworkManager is running): "NetworkManager is not running. Please start it." Or a NetworkManager client may work as expected. Or some other unexpected behavior may occur. If continuing to use another networking manager is desired, the NetworkManager daemon may remain installed but be permanently disabled (which is persistant through upgrades) with: 'update-rc.d network-manager disable' You will also need to recreate /etc/resolv.conf, as the contents of this file is replaced by NetworkManager.
Bug#700516: [virtualbox-dkms] building VBOX modules depends on IOMMU being enabled in the kernel config
Package: virtualbox-dkms Version: 4.1.18-dfsg-2.1 Severity: normal --- Please enter the report below this line. --- When building the VirtualBox modules using linux-source-3.7 from Debian Experimental, the build will fail without IOMMU support being configured-in: LD /var/lib/dkms/virtualbox/4.1.18/build/vboxpci/built-in.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxpci/linux/VBoxPci-linux.o CC [M] /var/lib/dkms/virtualbox/4.1.18/build/vboxpci/VBoxPci.o In file included from /var/lib/dkms/virtualbox/4.1.18/build/vboxpci/VBoxPciInternal.h:34:0, from /var/lib/dkms/virtualbox/4.1.18/build/vboxpci/VBoxPci.c:38: include/linux/iommu.h: In function ‘iommu_group_alloc’: include/linux/iommu.h:272:2: error: implicit declaration of function ‘ERR_PTR’ [-Werror=implicit-function-declaration] include/linux/iommu.h:272:2: warning: return makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors make[2]: *** [/var/lib/dkms/virtualbox/4.1.18/build/vboxpci/VBoxPci.o] Error 1 make[1]: *** [/var/lib/dkms/virtualbox/4.1.18/build/vboxpci] Error 2 make: *** [_module_/var/lib/dkms/virtualbox/4.1.18/build] Error 2 make: Leaving directory `/home/cknadle/src/LinuxDev/linux-source-3.7' An interesting aspect of this is that the VirtualBox modules build just fine against upstream Linux 3.5.7 /without/ IOMMU being configured-in, but does fail for upstream Linux 3.6 and 3.7. As all of the hardware I own does *not* support IOMMU, having to configure it in to be able to compile the VirtualBox modules is counterintuitive and thus seems like it's a bug, so I'm writing this mainly to let other users know about the problem. I'm not sure what severity this should have, so I'm just going to leave it as "normal". Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us --- System information. --- Architecture: amd64 Kernel: Linux 3.7.3-c2d-crk-2 Debian Release: 7.0 500 unstablewww.deb-multimedia.org 500 unstableftp.us.debian.org 500 unstabledownload.jitsi.org 500 testing security.debian.org 500 testing ftp.us.debian.org 500 stable dl.google.com 1 experimentalftp.us.debian.org --- Package information. --- Depends (Version) | Installed ===-+-= dkms (>= 2.1.0.0) | 2.2.0.3-1.2 virtualbox (>= 4.1.18-dfsg-2.1) | 4.1.18-dfsg-2.1 Package's Recommends field is empty. Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688772: [CTTE #688772] Dependency of meta-gnome on network-manager
On Tuesday, February 26, 2013 13:31:37, Don Armstrong wrote: > On Tue, 26 Feb 2013, Josselin Mouette wrote: > > Le lundi 25 février 2013 à 11:43 -0800, Don Armstrong a écrit : > > > 4. We overrule the decision of the meta-gnome maintainers to add a > > > > > >dependency from gnome to network-manager-gnome; this dependency > > >should be removed. If in the opinion of the NM maintainer (and > > >before the release of wheezy the Chair of the Technical Committee > > >or an individual delegated by the Chair in consultation with the > > >Release Team) the concerns raised in §4 of the CTTE decision > > >#681834 have been addressed through technical means (e.g. by > > >preventing the starting of NM as discussed in #688772), the > > >meta-gnome maintainers may freely adjust the dependencies as > > >usual. > > > > Can we consider that the changes in NetworkManager 0.9.4.0-9 are OK on > > this matter? > > I think those changes did most/all of the work to resolve the really > important issues from my perspective.[1] However, Bdale and the RMs > are the people who have to decide on this, so my opinion doesn't > really count for anything. > > If anyone else has any comments on why the current version of NM > doesn't address the concerns in §4 of the CTTE decision, please raise > them to the bug. Were the issues relating to wicd and network-manager intercting badly addressed somehow? I know there was a plan [1] to fix this, but I didn't see the intended followup. [There may have been unforseen difficulties with the proposed solution.] Last I checked this as part of #688772, attempting to use wicd caused a counterintuitive error message of "Connection Failed: bad password" if network-manager was running. I just tested this again on Sid, and this is still the case. [I don't currently have the ability to test Wheezy for this.] When this was brought up in the bug report, the response was "network-manager can be installed, then disabled", but how to do that wasn't documented anywhere in the network-manager package. Instead the next suggestion was documenting this issue in the Wheey errata [2], but I don't see network- manager or wicd mentioned there, nor mentioned in the Installation Guide [3] for Wheezy. Suggestions? [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688772#464 [2]: http://www.debian.org/devel/debian-installer/errata [3]: http://www.debian.org/releases/testing/amd64/install.txt.en -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#688772: [CTTE #688772] Dependency of meta-gnome on network-manager
On Wednesday, February 27, 2013 07:39:44, Michael Biebl wrote: > On 27.02.2013 00:50, Chris Knadle wrote: > > When this was brought up in the bug report, the response was > > "network-manager can be installed, then disabled", but how to do that > > wasn't documented anywhere in the network-manager package. Instead the > > next suggestion was documenting this issue in the Wheey errata [2], but > > I don't see network- manager or wicd mentioned there, nor mentioned in > > the Installation Guide [3] for Wheezy. > > > > Suggestions? > > I will try to add a section to README.Debian which should be re-usable > for the release notes / errata. Thanks much. > Neil, who should I contact getting those changes into the release notes? > If anyone is willing to review the text, even better. I'd certainly be willing to help with that. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#702102: [pbuilder] seems to work for alternate location
s currently installed.) Preparing to replace libpam-modules-bin 1.1.3-7.1 (using .../libpam-modules-bin_1.1.3-9_amd64.deb) ... Unpacking replacement libpam-modules-bin ... Replacing files in old package libpam-modules:amd64 ... Setting up libpam-modules-bin (1.1.3-9) ... (Reading database ... 6 files and directories currently installed.) Preparing to replace libpam-modules:amd64 1.1.3-7.1 (using .../libpam-modules_1.1.3-9_amd64.deb) ... Unpacking replacement libpam-modules:amd64 ... Setting up libpam-modules:amd64 (1.1.3-9) ... (Reading database ... 6 files and directories currently installed.) Preparing to replace libmpfr4:amd64 3.1.0-5 (using .../libmpfr4_3.1.1-1_amd64.deb) ... Unpacking replacement libmpfr4:amd64 ... Preparing to replace sysv-rc 2.88dsf-39 (using .../sysv-rc_2.88dsf-41_all.deb) ... Unpacking replacement sysv-rc ... Setting up sysv-rc (2.88dsf-41) ... (Reading database ... 6 files and directories currently installed.) Preparing to replace initscripts 2.88dsf-39 (using .../initscripts_2.88dsf-41_amd64.deb) ... Unpacking replacement initscripts ... Setting up initscripts (2.88dsf-41) ... (Reading database ... 6 files and directories currently installed.) Preparing to replace libpam-runtime 1.1.3-7.1 (using .../libpam-runtime_1.1.3-9_all.deb) ... Unpacking replacement libpam-runtime ... Setting up libpam-runtime (1.1.3-9) ... (Reading database ... 6 files and directories currently installed.) Preparing to replace libboost-iostreams1.49.0 1.49.0-3.1 (using .../libboost-iostreams1.49.0_1.49.0-3.2_amd64.deb) ... Unpacking replacement libboost-iostreams1.49.0 ... Preparing to replace binutils 2.22-7.1 (using .../binutils_2.22-8_amd64.deb) ... Unpacking replacement binutils ... Preparing to replace linux-libc-dev:amd64 3.2.35-2 (using .../linux-libc-dev_3.2.39-2_amd64.deb) ... Unpacking replacement linux-libc-dev:amd64 ... Setting up libmpfr4:amd64 (3.1.1-1) ... Setting up libboost-iostreams1.49.0 (1.49.0-3.2) ... Setting up binutils (2.22-8) ... Setting up linux-libc-dev:amd64 (3.2.39-2) ... Setting up perl-modules (5.14.2-18) ... Setting up perl (5.14.2-18) ... Reading package lists... Building dependency tree... Reading state information... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Reading package lists... Building dependency tree... Reading state information... Package 'ccache' is not installed, so not removed aptitude is already the newest version. build-essential is already the newest version. dpkg-dev is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. I: Copying back the cached apt archive contents I: new cache content diffutils_1%3a3.2-8_amd64.deb added I: new cache content perl_5.14.2-18_amd64.deb added I: new cache content perl-base_5.14.2-18_amd64.deb added I: new cache content sysvinit_2.88dsf-41_amd64.deb added I: new cache content sysvinit-utils_2.88dsf-41_amd64.deb added I: new cache content libpam0g_1.1.3-9_amd64.deb added I: new cache content libpam-modules-bin_1.1.3-9_amd64.deb added I: new cache content libpam-modules_1.1.3-9_amd64.deb added I: new cache content libmpfr4_3.1.1-1_amd64.deb added I: new cache content initscripts_2.88dsf-41_amd64.deb added I: new cache content libpam-runtime_1.1.3-9_all.deb added I: new cache content libboost-iostreams1.49.0_1.49.0-3.2_amd64.deb added I: new cache content binutils_2.22-8_amd64.deb added I: new cache content linux-libc-dev_3.2.39-2_amd64.deb added I: unmounting dev/pts filesystem I: unmounting run/shm filesystem I: unmounting proc filesystem -> removing cowbuilder working copy -> Moving work directory [/deb-chroots/cow-buildplace//cow.32420] to final location [/deb-chroots/amd64-sid-base.cow] and cleaning up old copy forking: rm -rf /deb-chroots/cow-buildplace//cow.32420-32420-tmp == Post the cowbuilder command line you're using if you think it might be significant. Maybe there's an option you're using that I'm not that is triggering the bug? -- Chris -- Chris Knadle chris.kna...@coredump.us --- System information. --- Architecture: amd64 Kernel: Linux 3.7.7-c2d-crk-1 Debian Release: 7.0 500 unstablewww.deb-multimedia.org 500 unstableftp.us.debian.org 500 unstabledownload.jitsi.org 500 testing security.debian.org 500 testing ftp.us.debian.org 500 stable dl.google.com 1 experimentalftp.us.debian.org --- Package information. --- Depends (Version) | Installed =-+-= coreutils(>= 4.5.8-1) | 8.20-3 debootstrap | 1.0.46 OR cdebootstrap | dpkg-dev | 1.16.9 debianutils (>= 1.13.1) | 4.3.4 wget | 1.14-1 debconf (>= 0.5) | 1.5.49 OR debconf-2.0
Bug#688772: [CTTE #688772] Dependency of meta-gnome on network-manager
On Wednesday, February 27, 2013 07:39:44, Michael Biebl wrote: > On 27.02.2013 00:50, Chris Knadle wrote: > > When this was brought up in the bug report, the response was > > "network-manager can be installed, then disabled", but how to do that > > wasn't documented anywhere in the network-manager package. Instead the > > next suggestion was documenting this issue in the Wheey errata [2], but > > I don't see network- manager or wicd mentioned there, nor mentioned in > > the Installation Guide [3] for Wheezy. > > > > Suggestions? > > I will try to add a section to README.Debian which should be re-usable > for the release notes / errata. It's been a couple of weeks, so I did some minimal testing and wrote up some initial text for this purpose based on the behavior I observed. -- Chris -- Chris Knadle chris.kna...@coredump.us conflicts with other networking manager daemons ~~~ Gnome upstream chose to couple NetworkManager tightly with the Gnome Shell in order to provide connectivity awareness for both the Shell and Gnome3 applications. For this reason the Gnome3 maintainers in Debian decided to follow upstream and upgrade the Recommends on the network-manager stack to a Depends. It is known that a small number of Squeeze installations have Gnome installed but not NetworkManager, and this Dependency will cause NetowrkManager to be installed upon a distribution upgrade to Wheezy. At present, NetworkManager can detect if an interface is managed by ifupdown to avoid conflicts with it, but does not detect other networking manager programs such as wicd-daemon. Problems and unexpected behavior can ensue if two network manager daemons are managing the same interface when attempting to make a networking connection. This issue was discussed by the Debian Technical Committee in #681834 and #688772. If wicd-daemon and NetworkManager are both running, a wicd client will fail to make a connection with the counterintuitive message: "Connection Failed: bad password" Trying a NetworkManager client may sometimes result in the message (even when NetworkManager is running): "NetworkManager is not running. Please start it." Or a NetworkManager client may work as expected. Or some other unexpected behavior may occur. If continuing to use another networking manager is desired, the NetworkManager daemon may remain installed but be permanently disabled (which is persistant through upgrades) with: 'update-rc.d network-manager disable' You will also need to recreate /etc/resolv.conf, as the contents of this file are replaced when the network-manager package is installed. signature.asc Description: This is a digitally signed message part.
Bug#629534: [libc6] Successful upgrade on i386
Package: libc6 Version: 2.13-5 --- Please enter the report below this line. --- I was able to complete an upgrade of libc6 on an old i386 box I run, which had its last reinstall in October 2007. During the installation Xorg lost video, so I had to complete the installation via an ssh connection. /lib/ld* after the installation looks like this: /lib$ ls -l ld* lrwxrwxrwx 1 root root 25 Jun 6 11:08 ld-linux.so.2 -> i386-linux-gnu/ld-2.13.so lrwxrwxrwx 1 root root 13 Mar 5 11:54 ld-lsb.so.1 -> ld-linux.so.2 lrwxrwxrwx 1 root root 13 Mar 5 11:54 ld-lsb.so.2 -> ld-linux.so.2 lrwxrwxrwx 1 root root 13 Mar 5 11:54 ld-lsb.so.3 -> ld-linux.so.2 I wanted to include what /lib/ld* looked like before the upgrade, but because I lost X I also lost the terminal I was working in where I had that information ready. However, what I recall seeing was that there was an ld-2.13.so file in /lib directly before the upgrade. Examination of libc6_2.13-4_i386.deb and libc6_2.13-5_i386.deb via 'debdiff' confirms this: $ debdiff libc6_2.13-4_i386.deb libc6_2.13-5_i386.deb ... Files in second .deb but not in first - ... -rwxr-xr-x root/root /lib/i386-linux-gnu/ld-2.13.so -rwxr-xr-x root/root /lib/i386-linux-gnu/libc-2.13.so -rwxr-xr-x root/root /lib/i386-linux-gnu/libpthread-2.13.so lrwxrwxrwx root/root /lib/i386-linux-gnu/ld-linux.so.2 -> ld-2.13.so ... Files in first .deb but not in second - ... -rwxr-xr-x root/root /lib/ld-2.13.so -rwxr-xr-x root/root /lib/libc-2.13.so -rwxr-xr-x root/root /lib/libpthread-2.13.so lrwxrwxrwx root/root /lib/ld-linux.so.2 -> ld-2.13.so So there is a change in ld file location in this upgrade. -- Chris -- Chris Knadle chris.kna...@coredump.us --- System information. --- Architecture: i386 Kernel: Linux 2.6.37.6-686-crk4 Debian Release: wheezy/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.us.debian.org 1 experimentalftp.us.debian.org --- Package information. --- Depends (Version) | Installed ===-+-=== libc-bin (= 2.13-5) | 2.13-5 libgcc1 | 1:4.6.0-11 Recommends (Version) | Installed =-+-=== libc6-i686| 2.13-5 Suggests (Version) | Installed ==-+-=== glibc-doc | debconf| 1.5.39 OR debconf-2.0| locales| 2.13-5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#637688: [mercurial] unable to reproduce bug
Package: mercurial Version: 1.9.1-2 --- Please enter the report below this line. --- As I don't use Mercurial much (I mostly use Git) I decided to test the upgrade due to this bug, and was unable to reproduce it. In my case no byte-compiled files were removed. The relevant output (from aptitude): Preparing to replace mercurial 1.9.1-1 (using .../mercurial_1.9.1-2_i386.deb) ... Unpacking replacement mercurial ... Preparing to replace mercurial-common 1.9.1-1 (using .../mercurial-common_1.9.1-2_all.deb) ... Unpacking replacement mercurial-common ... ... Setting up mercurial-common (1.9.1-2) ... Setting up mercurial (1.9.1-2) ... And 'hg' also seems to operate correctly as far as I can tell. Now the qustion is what cause byte-compiled files to be removed in the original instance the bug is based on. BTW in case this may help, I'm including the output of the following command: $ ls -ld /usr/lib/python2.6/site-packages ls: cannot access /usr/lib/python2.6/site-packages: No such file or directory -- Chris -- Chris Knadle chris.kna...@coredump.us --- System information. --- Architecture: i386 Kernel: Linux 2.6.37.6-686-crk4 Debian Release: wheezy/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.us.debian.org 1 experimentalftp.us.debian.org --- Package information. --- Depends(Version) | Installed -+- libc6 (>= 2.4) | 2.13-16 python2.6| 2.6.7-4 OR python2.7| 2.7.2-4 python (>= 2.6) | 2.6.7-3 python (<< 2.8) | 2.6.7-3 ucf (>= 2.0020) | 3.0025+nmu2 mercurial-common (= 1.9.1-2) | 1.9.1-2 Package's Recommends field is empty. Suggests (Version) | Installed ===-+-=== qct | wish| vim | OR emacs | kdiff3 | OR tkdiff | OR meld| OR xxdiff | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#638200: javascript-common: install/remove fail and causes shell control loss when using passworded SSL key with HTTP server
Package: javascript-common Version: 7 Severity: important --- Greetings. Unfortunately the way the install/remove scripts are currently written, both installation and removal fails and also causes loss of control of the shell when an SSL key with a password is used with the HTTP server, because they both cause a RESTART on the HTTP server rather than a RELOAD. The password prompt for the SSL key is not shown, and hitting CTRL-C does not break out of the problem, so the end result is whiptail using 100% CPU time, loosing control of the shell, and an install/remove script that never terminates. The line in both the postinst and postrm scrip that is the problem is: . /usr/share/wwwconfig-common/restart.sh [BTW this is likewise in the javascript-common pacakge in Unstable.] Presumably the SSL passowrd prompt is sent to wwwconfig-common, rather than to the terminal where it must go. This leaves the user clueless. :-/ To allow installation or removal, I had to modify /usr/share/wwwconfig-common/restart.sh to cause a reload rather than a restart. I need to refer to the Debian Maintainer's guide, but I get the feeling the severity of this should probably be "serious". -- Chris -- Chris Knadle chris.kna...@coredump.us --- -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages javascript-common depends on: ii wwwconfig-common 0.2.1 Debian web auto configuration javascript-common recommends no packages. Versions of packages javascript-common suggests: ii apache22.2.16-6+squeeze1 Apache HTTP Server metapackage ii apache2-mpm-prefork [h 2.2.16-6+squeeze1 Apache HTTP Server - traditional n -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#712156: [mumble] Alternate OpenGL overlay solution
Package: mumble Version: 1.2.3-349-g315b5f5-2.2 Severity: wishlist --- Please enter the report below this line. --- Ron -- Mumble upstream replied to a bug I submitted to them concerning the OpenGL bug that was dealt with in #691535 and after investigating they came up with a different solution. - libmumble.so as built fresh from Git is meant to work without being linked to libGL. It overrides glXSwapBuffers (via traditional LD_PRELOAD or by hooking into dlopen/dlsym), and will only ever call OpenGL functions in the glXSwapBuffers call -- so OpenGL functions will only be invoked if the process by some means has loaded libGL (or equivalent) anyway. This is the way it has worked for a long time. While looking into this, I also found out why it doesn't work that way for Debian anymore. The reason is that the rules file sets DEB_BUILD_HARDENING=1 which, among other things, causes all built binaries to be linked with "-z now". This causes all dynamic symbols to resolved when the program is loaded. In our normal build, we use "-z now" for all binaries and shared libraries, except libmumble.so -- because we want the behavior of a lightweight LD_PRELOADable library I described above. I have updated the debian/rules file in our Ubuntu PPA with a fix for this: https://github.com/mumble-voip/mumble-ubuntu- ppa/commit/8756933f3a18cec4f24ca885d5c33118cc10bddf I set DEB_BUILD_HARDENING_BINDNOW=0, and let the Mumble build link using "-z now" for the binaries it knows are OK with having load-time symbol resolving. Regarding the current Debian fix of linking directly with libGL, I don't see too much harm. The Linux overlay only supports GLX at present, so direct linking doesn't hurt in that regard. But were the overlay to support a non-GLX OpenGL implementation in the future, alongside the current GLX support, direct linking probably wouldn't work out favourably. Our preferred method however is still the lightweight LD_PRELOAD-able overlay library which only links against libc and friends. That way, we don't potentially bring in unwanted dependencies with us when we're LD_PRELOADED into foreign programs, and we let the environment of the foreign program guide our decisions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#717040: kmail: Can't send mail since upgrading to 4:4.10.5-1
Greetings.
After migrating to KMail2 at first I had this same issue (mail stuck in local
outbox and no attempt to send the email occurs), but logging out and in again
worked in my case when the akonadi backend is MySQL.
The behavior when using a akonadi backend of PosgreSQL (which requires some
manual setup to get working) seems different; email can be sent on the first
try, but I run into intolerable issues when trying to _read_ email because
the list of folders show up, but 90% of the emails that they contain do not.
Of the several thousand emails I have in IMAP, about 200 of them show up after
2 days of indexing, with lots of errors going to Postgresql log. :-(
The postgresql 9.1 log is 649 MiB and contains about 9 million lines of this:
2013-07-16 17:51:52 EDT ERROR: invalid input syntax for type bytea at
character 24
2013-07-16 17:51:52 EDT STATEMENT: EXECUTE qpsqlpstmt_7d ('\SEEN')
2013-07-16 17:51:52 EDT ERROR: invalid input syntax for type bytea at
character 24
2013-07-16 17:51:52 EDT STATEMENT: EXECUTE qpsqlpstmt_7d ('\SEEN')
...
I'll open a separate bug report about the above; the only reason I'm
mentioning it here is in relation to differences in behavior I see concerning
sending email.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#717117: [akonadi-backend-postgresql] continuous errors in postgresql 9.1 log
Package: akonadi-backend-postgresql
Version: 1.9.2-2
Severity: important
--- Please enter the report below this line. ---
Greetings.
Thanks for including akonadi-backend-postgresql in Sid... I'm hoping to use it
when I can get it working.
I'm having a lot of trouble when trying to use PostgreSQL 9.1 as the backend
for Akonadi; I can't tell for sure that this is the correct package to file
this bug against, but this seems the most logical place to start. [The next
logical alternative is the 'kmail' package.]
When migrating from KMail1 to KMail2, KMail2 shows a dialog box indicating
that all mail has been migrated, but email does not show up and PostgreSQL
continuously spits out errors to the log with:
2013-07-16 17:51:52 EDT ERROR: invalid input syntax for type bytea at
character 24
2013-07-16 17:51:52 EDT STATEMENT: EXECUTE qpsqlpstmt_7d ('\SEEN')
2013-07-16 17:51:52 EDT ERROR: invalid input syntax for type bytea at
character 24
2013-07-16 17:51:52 EDT STATEMENT: EXECUTE qpsqlpstmt_7d ('\SEEN')
...
After letting the system run for about 24 hours, the postgresql log grows to
about 650 MB containing about 9 million lines of the above, and about 200
emails (out of thousands) show up in KMail2 (in various folders, and none of
the messages in the "inbox" folder ever showed up) from my main IMAP account,
and new ones show up very slowly -- which I believe seems to be related to the
errors. This is repeatable.
Steps to replicate
--
1. Install akonadi-backend-postgresql, which pulls in dependencies:
postgresql:amd64
postgresql-9.1:amd64
postgresql-client-9.1:amd64
postgresql-client-common:amd64
postgresql-common:amd64
Modify /etc/postgresql/9.1/main/postgresql.conf to uncomment:
standard_conforming_strings = on
(this was suggested in akonadiconsole)
2. 'su' to root, then 'su - postgres' to become the postgres user
3. Create a role for a normal user with CreateDB ability
pgsql -d template1
-> CREATE ROLE cknadle WITH CREATEDB LOGIN;
\q
exit; exit; [to become regular user again]
4. Create new database as a regular user
psql -d template1
-> CREATE DATABASE "akonadi-chris";
\q
5. Delete previous files for akonadi:
rm -rf ~/.local/share/akonadi
rm -rf ~/.config/akonadi/agent*
rm -rf ~/.kde/share/akonadi_*
rm -rf ~/.kde/share/akonadi-*
Delete settings for kmail2 and kmail-migrator
rm -rf ~/.kde/share/config/kmail2*
rm -rf ~/.kde/share/config/kmail-migrator*
6. Open akonadiconsole as user, set to use the akonadi-chris database,
start Akonadi
7. Start KMail2 and choose "Migrate"
Setps 5 through 7 work just fine when using the the Akonadi MySQL backend, and
likewise KMail2 seems to work fine afterwards.
Please let me know if I can be of further assistance.
Thanks!
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
--- System information. ---
Architecture: amd64
Kernel: Linux 3.9-1-amd64
Debian Release: jessie/sid
500 unstablewww.deb-multimedia.org
500 unstableftp.us.debian.org
500 unstabledebian-packages.coredump.us
500 testing security.debian.org
500 testing ftp.us.debian.org
500 stable-updates ftp.us.debian.org
500 stable security.debian.org
500 stable ftp.us.debian.org
500 sid linux.dropbox.com
--- Package information. ---
Depends (Version) | Installed
==-+-===
libqt4-sql-psql| 4:4.8.5+dfsg-2
Recommends (Version) | Installed
=-+-===
akonadi-server| 1.9.2-2
postgresql| 9.3+142really9.1+145
Package's Suggests field is empty.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#717040: kmail: Can't send mail since upgrading to 4:4.10.5-1
On Wednesday, July 17, 2013 09:28:00 Pino Toscano wrote:
> Hi,
>
> Alle mercoledì 17 luglio 2013, Chris Knadle ha scritto:
> > After migrating to KMail2 at first I had this same issue (mail stuck
> > in local outbox and no attempt to send the email occurs), but
> > logging out and in again worked in my case when the akonadi backend
> > is MySQL.
> >
> > The behavior when using a akonadi backend of PosgreSQL (which
> > requires some manual setup to get working) seems different; email
> > can be sent on the first try, but I run into intolerable issues when
> > trying to _read_ email because the list of folders show up, but 90%
> > of the emails that they contain do not. Of the several thousand
> > emails I have in IMAP, about 200 of them show up after 2 days of
> > indexing, with lots of errors going to Postgresql log. :-( The
> > postgresql 9.1 log is 649 MiB and contains about 9 million lines of
> >
> > this:
> > 2013-07-16 17:51:52 EDT ERROR: invalid input syntax for type bytea
> >
> > at character 24 2013-07-16 17:51:52 EDT STATEMENT: EXECUTE
> > qpsqlpstmt_7d ('\SEEN') 2013-07-16 17:51:52 EDT ERROR: invalid
> > input syntax for type bytea at character 24 2013-07-16 17:51:52 EDT
> > STATEMENT: EXECUTE qpsqlpstmt_7d ('\SEEN') ...
>
> This is mostly caused by #716922.
I agree.
> > I'll open a separate bug report about the above; the only reason I'm
> > mentioning it here is in relation to differences in behavior I see
> > concerning sending email.
>
> Of course there is a difference in behaviour, considering the pgsql
> access if broken due to the regression in qt4-sql-pgsql, so I'm not sure
> what this bug would be about then, if you reported a new #717117 (which
> is a duplicate of #716922).
Sorry for the duplicate report. Thanks very much for letting me know about
#716922 ... I'm going to go run a test with standard_conforming_strings=off to
see if that's a possible workaround.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
signature.asc
Description: This is a digitally signed message part.
Bug#718182: Vicious cpufreq widget broken with Linux 3.10
> The vicious cpufreq widget uses > /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq, which seems to > be gone in 3.10, and the new cpuinfo_cur_freq is root:root 0400 :/ Concerning root:root 0400 ownership, the workaround I would suggest would be to install the 'sysfsutils' package and then to make entries in /etc/sysfs.conf to manually set file mode and ownership, such as: mode devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq = 0440 mode devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq = 0440 ... owner devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq = root:adm owner devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq = root:adm ... Another confusing thing is that I'm using Debian's 3.10 kernel, but for some reason scaling_cur_freq and cpuinfo_cur_freq both exist on my system. (Not sure why that is.) # uname -r 3.10-1-amd64 # ls -1 /sys/devices/system/cpu/cpu0/cpufreq/ affected_cpus bios_limit cpuinfo_cur_freq cpuinfo_max_freq cpuinfo_min_freq cpuinfo_transition_latency related_cpus scaling_available_frequencies scaling_available_governors scaling_cur_freq scaling_driver scaling_governor scaling_max_freq scaling_min_freq scaling_setspeed stats -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718182: Vicious cpufreq widget broken with Linux 3.10
On Monday, July 29, 2013 01:53:32 gregor herrmann wrote: > On Sun, 28 Jul 2013 19:02:20 -0400, Chris Knadle wrote: > > > and the new cpuinfo_cur_freq is root:root 0400 :/ > > > > Concerning root:root 0400 ownership, the workaround I would suggest would > > be to install the 'sysfsutils' package and then to make entries in > > > /etc/sysfs.conf to manually set file mode and ownership, such as: > Oh, nice, I didn't know that. I didn't either until I tried to use 'cpufreq-set' from the 'cpufrequtils' package as a normal user, and then found that I didn't have permission to manually change the CPU frequency due to the permission/ownership on these files. Normally I use sysfsutils for setting battery charge thresholds with the tp_smapi module, and /etc/sysfs.conf contains comments specific to changing /sys file mode+ownership, so that's how I found out it could do this. > > Another confusing thing is that I'm using Debian's 3.10 kernel, but for > > some reason scaling_cur_freq and cpuinfo_cur_freq both exist on my > > system. (Not sure why that is.) > > It depends on the scaling_driver; I'm using (not by my own decision, > but hey :)) intel_pstate. This makes sense after I read the 'help' in a 'make menuconfig' on the Linux kernel source. > I had a quick look into the kernel sources today, and depending on > the driver's "properties" cpuinfo_cur_freq and/or scaling_cur_freq > are created, at least that was my conclusion. Okay. The output of these two 'files' (pointers to kernel memory) output the same information: # cat cpuinfo_cur_freq scaling_cur_freq 80 80 I currently don't know if it's possible to make a [soft|hard]link within /sys, but if that were possible that would be a way around the lack of the scaling_cur_freq filename. If nothing else this should be possible via a custom Linux kernel module. I've experimented with doing this, which is explained in "Linux Device Drivers": https://lwn.net/Kernel/LDD3/ which is another book I'm hoping to get back to reading... P.S. I've subscribed to this bug (manually), so I don't need to be CCed. Cheers -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Bug#662898: [kde-config-touchpad] reliably crashes on startup with KDE 4.7.4
../kdeui/kernel/kapplication.cpp:311 #92 0x7f2def43c80c in QCoreApplication::notifyInternal (this=0x7fffb83f1590, receiver=0x203dae0, event=0x7fffb83f08c0) at kernel/qcoreapplication.cpp:876 #93 0x7f2df00dee92 in sendEvent (event=, receiver=) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231 #94 QApplicationPrivate::sendMouseEvent (receiver=0x203dae0, event=0x7fffb83f08c0, alienWidget=0x203dae0, nativeWidget=0x20a1780, buttonDown=0x203dae0, lastMouseReceiver=..., spontaneous=true) at kernel/qapplication.cpp:3166 #95 0x7f2df015b255 in QETWidget::translateMouseEvent (this=0x20a1780, event=) at kernel/qapplication_x11.cpp:4515 #96 0x7f2df015a11a in QApplication::x11ProcessEvent (this=0x7fffb83f1590, event=0x7fffb83f1180) at kernel/qapplication_x11.cpp:3641 #97 0x7f2df0182852 in x11EventSourceDispatch (s=0x1de74b0, callback=0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:146 #98 0x7f2dec5c06ba in g_main_context_dispatch () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 #99 0x7f2dec5c0a80 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #100 0x7f2dec5c0b44 in g_main_context_iteration () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 #101 0x7f2def46bd8f in QEventDispatcherGlib::processEvents (this=0x1db3450, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #102 0x7f2df01824de in QGuiEventDispatcherGlib::processEvents (this=, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #103 0x7f2def43b5f2 in QEventLoop::processEvents (this=, flags=...) at kernel/qeventloop.cpp:149 #104 0x7f2def43b847 in QEventLoop::exec (this=0x7fffb83f1520, flags=...) at kernel/qeventloop.cpp:204 #105 0x7f2def4408d7 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1148 #106 0x0040b225 in main (argc=1, argv=0x7fffb83f1858) at ../../../systemsettings/app/main.cpp:49 I'm available to run further tests if I can be of service. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us --- System information. --- Architecture: amd64 Kernel: Linux 3.2.8-c2d-crk5 Debian Release: wheezy/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.us.debian.org 1 experimentalftp.us.debian.org --- Package information. --- Depends (Version) | Installed ==-+-== python2.7 | 2.7.2-13 OR python2.6 | 2.6.7-4 python (>= 2.6.6-7~) | 2.7.2-10 python(<< 2.8) | 2.7.2-10 python-pyudev | 0.13-1 python (>= 2.7) | 2.7.2-10 OR python-argparse| 1.2.1-2 python-pkg-resources | 0.6.24-1 python-qt4(>= 4.8) | 4.9.1-2 python-kde4 (>= 4:4.5) | 4:4.7.4-1 libxi6 (>= 2:1.4) | 2:1.5.99.2-1 Recommends (Version) | Installed ==-+-=== libxtst6 | 2:1.2.0-4 python-dbus| 1.0.0-1 upower | 0.9.15-2 Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662898: [kde-config-touchpad] retitle, moreinfo
retitle 662898 segfaults with KDE 4.8.0 pacakges from Experimental thanks The title was a bit misleading: I had several packages from Experimental loaded from KDE 4.8.0 which seem to have caused the problem. Downgrading libqt4-dbus forced the following actions, which eliminates the segfault: [REMOVE, DEPENDENCIES] automoc [REMOVE, DEPENDENCIES] libqt4-declarative-particles [REMOVE, DEPENDENCIES] libqt4-dev [REMOVE, DEPENDENCIES] libqt4-opengl-dev [REMOVE, DEPENDENCIES] libqtwebkit-dev [DOWNGRADE] libgcc1 1:4.7.0~rc1-1 -> 1:4.6.3-1 [DOWNGRADE] libqscintilla2-8 2.6.1-3 -> 2.6.1-1 [DOWNGRADE] libqt4-dbg 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-dbus 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-declarative 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-declarative-gestures 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-designer 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-help 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-network 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-opengl 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-qt3support 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-script 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-scripttools 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-sql 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-sql-mysql 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-sql-sqlite 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-svg 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-test 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-xml 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqt4-xmlpatterns 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqtcore4 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqtgui4 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] libqtlocation1 1.2.0-2 -> 1.2.0-1 [DOWNGRADE] libqtwebkit4 2.2.1-1 -> 2.2.0-3 [DOWNGRADE] libstdc++6 4.7.0~rc1-1 -> 4.6.3-1 [DOWNGRADE] python-qt4 4.9.1-2 -> 4.9.1-1 [DOWNGRADE] python-qt4-dbus 4.9.1-2 -> 4.9.1-1 [DOWNGRADE] python-qt4-gl 4.9.1-2 -> 4.9.1-1 [DOWNGRADE] python-qt4-phonon 4.9.1-2 -> 4.9.1-1 [DOWNGRADE] python-qt4-sql 4.9.1-2 -> 4.9.1-1 [DOWNGRADE] qdbus 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] qt4-demos 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] qt4-designer 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] qt4-dev-tools 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] qt4-linguist-tools 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] qt4-qmlviewer 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] qt4-qtconfig 4:4.8.0-1 -> 4:4.7.4-2 [DOWNGRADE] qtcreator 2.4.0-1 -> 2.2.1-2 -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675418: [kmail] link plus text in parenthesis get munged together
Package: kmail Version: 4:4.4.11.1+l10n-2 Severity: normal --- Please enter the report below this line. --- Greetings Debian Qt/KDE Maintainers. I'm on a LUG mailing list and received the email at [1] which contains an http link along with some other text within parenthesis. KMail for some reason munges all of this together such that the other text becomes part of the link. http://www.spy-hill.net/~myers/xena/ (Note the trailing "/" which may be significant.) This link instead becomes: http://www.spy-hill.net/~myers/xena/whichisover10yearsold at least when viewing the email. This is a tad annoying because the link gets munged and thus points to a nonexistent page when clicking on it while viewing the email. When replying to the email (or when looking at the source), the link is correct. There's a chance this may be an HTML limitation and thus may not be fixable, but I'm filing this as a bug anyway since KMail seems to be misrendering the underlying text. [1] http://mhvlug.org/pipermail/mhvlug/2012-May/032244.html -- Chris -- Chris Knadle chris.kna...@coredump.us --- System information. --- Architecture: amd64 Kernel: Linux 3.4.0-c2d-crk-1 Debian Release: wheezy/sid 500 unstablewww.deb-multimedia.org 500 unstableftp.us.debian.org 1 experimentalftp.us.debian.org --- Package information. --- Depends (Version) | Installed ===-+- = kde-runtime | 4:4.7.4-2+b1 kdepim-runtime | 4:4.4.11.1-4 kdepimlibs-kio-plugins | 4:4.7.4-3 libakonadi-contact4 (>= 4:4.6) | 4:4.7.4-3 libakonadi-kde4 (>= 4:4.6) | 4:4.7.4-3 libc6 (>= 2.4) | 2.13-32 libgcc1(>= 1:4.1.1) | 1:4.7.0-11 libgpgme++2 (>= 4:4.6) | 4:4.7.4-3 libkabc4 (>= 4:4.6) | 4:4.7.4-3 libkcal4 (>= 4:4.6) | 4:4.7.4-3 libkcmutils4 (>= 4:4.6) | 4:4.7.4-6 libkde3support4 (>= 4:4.6) | 4:4.7.4-6 libkdecore5 (>= 4:4.6) | 4:4.7.4-6 libkdepim4(= 4:4.4.11.1+l10n-2) | 4:4.4.11.1+l10n-2 libkdeui5(>= 4:4.6) | 4:4.7.4-6 libkhtml5(>= 4:4.6) | 4:4.7.4-6 libkimap4(>= 4:4.6) | 4:4.7.4-3 libkio5 (>= 4:4.6) | 4:4.7.4-6 libkldap4(>= 4:4.6) | 4:4.7.4-3 libkleo4 (= 4:4.4.11.1+l10n-2) | 4:4.4.11.1+l10n-2 libkmime4(>= 4:4.6) | 4:4.7.4-3 libknotifyconfig4(>= 4:4.6) | 4:4.7.4-6 libkontactinterface4 (>= 4:4.6) | 4:4.7.4-3 libkparts4 (>= 4:4.6) | 4:4.7.4-6 libkpgp4 (= 4:4.4.11.1+l10n-2) | 4:4.4.11.1+l10n-2 libkpimidentities4 (>= 4:4.6) | 4:4.7.4-3 libkpimtextedit4 (>= 4:4.6) | 4:4.7.4-3 libkpimutils4(>= 4:4.6) | 4:4.7.4-3 libkresources4 (>= 4:4.6) | 4:4.7.4-3 libksieve4(= 4:4.4.11.1+l10n-2) | 4:4.4.11.1+l10n-2 libktnef4(>= 4:4.6) | 4:4.7.4-3 libmailtransport4(>= 4:4.6) | 4:4.7.4-3 libmessagecore4 (= 4:4.4.11.1+l10n-2) | 4:4.4.11.1+l10n-2 libmessagelist4 (= 4:4.4.11.1+l10n-2) | 4:4.4.11.1+l10n-2 libmimelib4 (= 4:4.4.11.1+l10n-2) | 4:4.4.11.1+l10n-2 libnepomuk4 (>= 4:4.6) | 4:4.7.4-6 libphonon4 (>= 4:4.6.0really4.3.80) | 4:4.6.0.0-2 libqt4-dbus(>= 4:4.5.3) | 4:4.8.1-1 libqt4-network (>= 4:4.5.3) | 4:4.8.1-1 libqt4-qt3support (>= 4:4.5.3) | 4:4.8.1-1 libqt4-xml (>= 4:4.5.3) | 4:4.8.1-1 libqtcore4 (>= 4:4.7.0~beta2) | 4:4.8.1-1 libqtgui4 (>= 4:4.8.0) | 4:4.8.1-1 libstdc++6 (>= 4.2.1) | 4.7.0-11 libthreadweaver4 (>= 4:4.6) | 4:4.7.4-6 phonon | 4:4.6.0.0-2 perl| 5.14.2-11 Recommends(Version) | Installed ===-+-=== gnupg2 | 2.0.19-1 gnupg-agent | 2.0.19-1 pinentry-qt4| 0.8.1-1 OR pinentry-x11| Suggests
Bug#672198: [developers-reference] NMU clarification for section 5.11.1
Package: developers-reference
Version: 3.4.7
Severity: wishlist
Tags: patch
In a long email thread on [debian-devel] concerning a package which has a
maintainer that is temporarily MIA due to being time overloaded, the
discussion came to an idea for using NMUs in order to bring the package up to
date to upload a new upstream version of the software. I was directed to read
section 5.11 of the Developer's Reference, but it doesn't seem to clearly
state that this is allowed. Stefano Zacchiroli responded with a post [1]
explaining NMUs from his point of view which I find is a bit more clear in
this area.
Attached is a minimal patch against commit:
r9201 | taffit | 2012-04-25 09:25:10 -0400 (Wed, 25 Apr 2012)
in the repository for the Developer's Reference. Diffstat:
pkgs.dbk | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
[1] http://lists.debian.org/debian-devel/2012/04/msg00486.html
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
diff --git a/pkgs.dbk b/pkgs.dbk
index af8bcf0..6959ac8 100644
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -1923,8 +1923,15 @@ Before doing an NMU, consider the following questions:
-Does your NMU really fix bugs? Fixing cosmetic issues or changing the
-packaging style in NMUs is discouraged.
+Will the NMU help the maintainer?
+
+
+
+
+Does your NMU really fix bugs? ("Bugs" includes wishlist bugs for packaging
+a new upstream version, but care should be taken to minimize the impact to
+the maintianer.) Fixing cosmetic issues or changing the packaging style
+(dh, cdbs, etc) in NMUs is discouraged.
Bug#672198: [developers-reference] NMU clarification for section 5.11.1
Sending again as I forgot to CC the BTS
On Thursday, May 10, 2012 10:26:44, Lucas Nussbaum wrote:
> On 08/05/12 at 20:11 -0400, Chris Knadle wrote:
> > Package: developers-reference
> > Version: 3.4.7
> > Severity: wishlist
> > Tags: patch
> >
> > In a long email thread on [debian-devel] concerning a package which has a
> > maintainer that is temporarily MIA due to being time overloaded, the
> > discussion came to an idea for using NMUs in order to bring the package
> > up to date to upload a new upstream version of the software. I was
> > directed to read section 5.11 of the Developer's Reference, but it
> > doesn't seem to clearly state that this is allowed. Stefano Zacchiroli
> > responded with a post [1] explaining NMUs from his point of view which I
> > find is a bit more clear in this area.
> >
> > Attached is a minimal patch against commit:
> >r9201 | taffit | 2012-04-25 09:25:10 -0400 (Wed, 25 Apr 2012)
> >
> > in the repository for the Developer's Reference. Diffstat:
> > pkgs.dbk | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > [1] http://lists.debian.org/debian-devel/2012/04/msg00486.html
> >
> > -- Chris
> >
> > --
> > Chris Knadle
> > chris.kna...@coredump.us
> >
> > diff --git a/pkgs.dbk b/pkgs.dbk
> > index af8bcf0..6959ac8 100644
> > --- a/pkgs.dbk
> > +++ b/pkgs.dbk
> >
> > @@ -1923,8 +1923,15 @@ Before doing an NMU, consider the following
questions:
> >
> >
> >
> >
> > -Does your NMU really fix bugs? Fixing cosmetic issues or changing the
> > -packaging style in NMUs is discouraged.
> > +Will the NMU help the maintainer?
>
> How do you determine that?
As Stefano mentioned, it's a question for the submitter to consider.
"Years ago, I've been applying the above commonsense principles while
performing several NMUs and I've never received harsh replies in
response. That experience has convinced me that properly done NMU are
just welcome and that to properly do NMU you just need to keep in mind
that the goal is helping the maintainer and use commonsense."
> > +
> > +
> > +
> > +
> > +Does your NMU really fix bugs? ("Bugs" includes wishlist bugs for
> > packaging +a new upstream version, but care should be taken to minimize
> > the impact to +the maintianer.)
>
> So other kind of wishlist bugs are not included?
I think at least ONE example of what "bugs" means would be helpful. Perhaps
adding the word "even" before "wishlist bugs" would clarify this.
> typo: maintianer.
Got it.
> > +Fixing cosmetic issues or changing the packaging style
> > +(dh, cdbs, etc) in NMUs is discouraged.
>
> rewrite to:
>changing the packaging style (e.g. switching from cdbs to dh) is
>discouraged.
agreed.
Would you like an amended patch?
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672198: [developers-reference] NMU clarification for section 5.11.1
On Friday, May 11, 2012 03:20:41, Lucas Nussbaum wrote:
> On 10/05/12 at 17:31 -0400, Chris Knadle wrote:
> > Sending again as I forgot to CC the BTS
> >
> > On Thursday, May 10, 2012 10:26:44, Lucas Nussbaum wrote:
> > > On 08/05/12 at 20:11 -0400, Chris Knadle wrote:
> > > > Package: developers-reference
> > > > Version: 3.4.7
> > > > Severity: wishlist
> > > > Tags: patch
> > > >
> > > > In a long email thread on [debian-devel] concerning a package which
> > > > has a maintainer that is temporarily MIA due to being time
> > > > overloaded, the discussion came to an idea for using NMUs in order
> > > > to bring the package up to date to upload a new upstream version of
> > > > the software. I was directed to read section 5.11 of the
> > > > Developer's Reference, but it doesn't seem to clearly state that
> > > > this is allowed. Stefano Zacchiroli responded with a post [1]
> > > > explaining NMUs from his point of view which I find is a bit more
> > > > clear in this area.
> > > >
> > > > Attached is a minimal patch against commit:
> > > >r9201 | taffit | 2012-04-25 09:25:10 -0400 (Wed, 25 Apr 2012)
> > > >
> > > > in the repository for the Developer's Reference. Diffstat:
> > > > pkgs.dbk | 11 +--
> > > > 1 file changed, 9 insertions(+), 2 deletions(-)
> > > >
> > > > [1] http://lists.debian.org/debian-devel/2012/04/msg00486.html
> > > >
> > > > -- Chris
> > > >
> > > > --
> > > > Chris Knadle
> > > > chris.kna...@coredump.us
> > > >
> > > > diff --git a/pkgs.dbk b/pkgs.dbk
> > > > index af8bcf0..6959ac8 100644
> > > > --- a/pkgs.dbk
> > > > +++ b/pkgs.dbk
> > > >
> > > > @@ -1923,8 +1923,15 @@ Before doing an NMU, consider the following
> >
> > questions:
> > > >
> > > >
> > > >
> > > >
> > > > -Does your NMU really fix bugs? Fixing cosmetic issues or changing
> > > > the -packaging style in NMUs is discouraged.
> > > > +Will the NMU help the maintainer?
> > >
> > > How do you determine that?
> >
> > As Stefano mentioned, it's a question for the submitter to consider.
> >
> >"Years ago, I've been applying the above commonsense principles while
> > performing several NMUs and I've never received harsh replies in
> > response. That experience has convinced me that properly done NMU are
> > just welcome and that to properly do NMU you just need to keep in
> > mind that the goal is helping the maintainer and use commonsense."
>
> Still, "helping the maintainer" sounds like a concept that is difficult
> to instanciate. That might require asking the maintainer, which goes
> against the idea of using the DELAYED queue for a "fire and forget"
> NMU.
Yes I agree that this is confusing to explain. Maybe this can be worded more
like "Have you geared the NMU towards helping the maintainer?"
I also agree that this is difficult to instantiate to give an example of what
this means in a particular context. Mainly I'm trying to plant the idea that
NMUs can actually help the maintainer, and that it's also a good idea to keep
helping the maintainer in mind when making an NMU.
BTW I originally worded this section as a longer paragraph and included
discussing the DELAYED queue, but removed it because it would repeat the
discussion about the DELAYED queue that is already in the document. I think
you're right that it's better to discuss it here, so I'm adding Stefano's
comments on that back into the patch. [Mainly because I don't know how to
word it any better than he has already.]
> > > > +
> > > > +
> > > > +
> > > > +
> > > > +Does your NMU really fix bugs? ("Bugs" includes wishlist bugs for
> > > > packaging +a new upstream version, but care should be taken to
> > > > minimize the impact to +the maintianer.)
> > >
> > > So other kind of wishlist bugs are not included?
> >
> > I think at least ONE example of what "bugs" means would be helpful.
> > Perhaps adding the word "even" before "wishlist bugs" would clarify
> > this.
>
> note that in your wording, "new upstream version" are the only kind of
> wishlist bugs where NMU
