Bug#717390: general: Issue with sudo apt-get -f install to fix broken package

2013-07-20 Thread Robin Haeusler 
Package: general
Severity: important

Dear Maintainer,
I have compiled and installed Restroshare. Now when I want to add new packages 
via Synaptic or sudo apt-get, because of percieved unmet dependencies on 
superceeded packags libupnp3 and libssl, the system wants to remove my 
Retroshare. I have tried running sudo apt-get -f install as well as Synaptic 
fix broken packages, but they both want to remove the Retroshare installation. 

At present I am at a loss as to what to do, as I need to install clamav and I 
have not been able to find a solution.


-- System Information:
Debian Release: jessie/sid
Architecture: i386 (i686)

Kernel: Linux 3.9-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130720071557.10024.97870.reportbug@tardis13

Bug#717390: marked as done (general: Issue with sudo apt-get -f install to fix broken package)

2013-07-20 Thread Debian Bug Tracking System 
Your message dated Sat, 20 Jul 2013 15:37:42 +0800
with message-id 

and subject line Re: Bug#717390: general: Issue with sudo apt-get -f install to 
fix broken package
has caused the Debian Bug report #717390,
regarding general: Issue with sudo apt-get -f install to fix broken package
to be marked as done.

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

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


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

Dear Maintainer,
I have compiled and installed Restroshare. Now when I want to add new packages 
via Synaptic or sudo apt-get, because of percieved unmet dependencies on 
superceeded packags libupnp3 and libssl, the system wants to remove my 
Retroshare. I have tried running sudo apt-get -f install as well as Synaptic 
fix broken packages, but they both want to remove the Retroshare installation. 

At present I am at a loss as to what to do, as I need to install clamav and I 
have not been able to find a solution.


-- System Information:
Debian Release: jessie/sid
Architecture: i386 (i686)

Kernel: Linux 3.9-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
On 20 July 2013 15:15, Robin Haeusler  wrote:
> Package: general
> Severity: important
>
> Dear Maintainer,
> I have compiled and installed Restroshare. Now when I want to
> add new packages via Synaptic or sudo apt-get, because of
> percieved unmet dependencies on superceeded packags libupnp3
> and libssl, the system wants to remove my Retroshare. I have
> tried running sudo apt-get -f install as well as Synaptic fix
> broken packages, but they both want to remove the Retroshare
> installation.

Debian does not supply such a package, so we can not really fix
it.

It seems that upstream does supply packages for squeeze and
wheezy, but these are not built to support the dependencies
available in jessie/sid.  The package will have to be rebuilt.
You can try this yourself from the sources supplied upstream
or otherwise contact the upstream developers to provide a
more up to date version.



Regards

> At present I am at a loss as to what to do, as I need to install
> clamav and I have not been able to find a solution.
>
>
> -- System Information:
> Debian Release: jessie/sid
> Architecture: i386 (i686)--- End Message ---

Re: PulseAudio

2013-07-20 Thread Helmut Grohne 
On Fri, Jul 19, 2013 at 10:36:06PM +0200, Philipp Kern wrote:
> On 2013-07-19 11:56, Helmut Grohne wrote:

> Neither are yours. PA works fine for me with Bluetooth headsets and
> regular sound cards on GNOME. Leaving regular gnome-bluetooth
> crashes aside (that crash the shell, yay).

I am aware that my use case is not universal. That is why I only pointed
my finger at particular issues.

> PA should retract itself from the sound device when it's not in use.
> ALSA architecture also does not allow different users to access a
> sound device. (dmix is per user.)

I have no clue why/how, but with plain alsa I could play audio from two
different users simultaneously. It just worked and it stopped working
the moment pulseaudio was running.

> >As an aside note PA error messages smell badly. When running into a
> >crash with gdb attached to PA, I am told that my alsa device is
> >behaving
> >strangely and that this surely is a bug in the alsa driver. The
> >possibility that PA would be stopped for traceback investigation was
> >simply not considered.
>
> I don't think ptrace allows for that sort of self-tracing awareness,
> does it?

That's not the issue here. I was complaining about the software drawing
wrong conclusions from the behaviour it observed instead of just
presenting the unexpected situation. When people report bugs, we often
ask them not to quickly draw conclusions, because they might be wrong.
Some of the messages even feel insulting, because they try to tell me
what I want to do ("it's your own fault").

> >How much time does it take to write a utility, that listens to sink
> >state updates? It took me about three hours and a quite a bit of help
> >from #pulseaudio. It does not work like you connect to the bus and
> >listen for the signal. Instead you connect the session bus, to discover
> >the bus address to connect to. Then you tell the core object that you
> >want to receive signals for your sink and then you can actually listen
> >for the signal. Solving the very same task with mpd for instance is
> >radically easier. There are reasons for why so many steps are needed
> >with PA, but those are not spelled out in the documentation.
> 
> Obviously mpd solves a different problem.

True. That still makes them comparable, because they both implement a
common aspect. Both control a sound device that sometimes plays back
audio and other times doesn't. Both emit signals for state transitions.
This is why I find the comparison legitimate here. My comparison to Jack
also makes sense even though Jack solves a different problem. I just
compared a common aspect.

Helmut


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130720072257.ga13...@alf.mars

Re: PulseAudio

2013-07-20 Thread Helmut Grohne 
On Fri, Jul 19, 2013 at 10:49:07PM +0200, Vincent Bernat wrote:
> Did you see the examples of asoundrc I posted? PulseAudio removes all
> this non-sense by providing mixing in almost all situations (while Alsa
> is doing it out of the box only for analog output), correct setup of
> output (no need to remap channels), provide a sane naming of output (no
> meaningless numbered outputs), universal support for multiple input and
> output devices with per-application selection, per application volume,
> per application output, out of the box Bluetooth support with no need to
> put a MAC address in your asoundrc, network transparency with
> autodiscovery.

I am not declining that PA adds useful features. Having audio output
reroutable at runtime definitely is a win. Play back sound on your USB
card, unplug the USB card and have your sound automatically switch to
the other card is basically impossible with Alsa.

Still PA adds quite a bit of complexity on its own. The additional layer
has its own new toggles and whistles. Nothing in Alsa was ever talking
about latency. With Alsa there was no need to talk to ConsoleKit or
logind, because Alsa completely ignores the idea that a device should
only be accessible to a user for the duration of a session. There also
is no notion of a suspended sink in Alsa. All these examples are part of
the solution PA is. Still they do add complexity.

Your claim about removing meaningless numbering is just wrong. Like Alsa
numbers cards PA numbers sinks. The dbus object path of a sink does not
contain its name, but uses the sink number instead. This equally applies
to sources, cards, profiles, samples, streams, and modules. Everything
is identified by a number.

> Nobody cares about pacmd list-* being too verbose. Is it a serious
> argument about maturity?

I think that a program whose UI sucks, can be seriously annoying. I hope
that giving an example does not start another flamewar. From my point of
view the subversion UI sucked until the introduction of svn log --diff,
because showing recent changes was too hard. This has caused me to use a
different UI instead of svn in a few cases. I do care.

People started to use pacmd as a programmable interface. Upstream fears
that changes to it could break user scripts. By now it is a hybrid of a
supposedly human-readable and a somewhat machine-readable interface.
Other tools have avoid this trap as they matured. An example being nmap
-o$letter.

Worse, different UIs to PA use different terminology. What is called
sink in pacmd is called "output device" in pavucontrol. The concept of a
"default-sink" on side of pacmd is named "fallback device" in
pavucontrol.

To me these cursory observations indicate that there still are a few
things to work out in the way of talking to users. An aspect that makes
me consider it more like beta than mature/stable.

Nevertheless it turns out to be a quite useful beta once you understand
enough parts of it by reading the documentation^Wsource.

Helmut


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130720081058.gb13...@alf.mars

Re: PulseAudio

2013-07-20 Thread Josselin Mouette 
Le samedi 20 juillet 2013 à 09:48 +0300, Andrei POPESCU a écrit : 
> Have you been reading debian-user lately? One of the first 
> recommendations is still "uninstall pulseaudio and see if it works".

Having debian-user run by people trying to map their ideology of what a
Debian system should be to users coming for help is probably part of
what our reputation of poor end-user support is built on.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1374312670.4511.4.camel@tomoyo

not really vaporware but almost (Re: Survey answers part 3: systemd is not portable and what this means for our ports

2013-07-20 Thread Holger Levsen 
Hi,

On Samstag, 20. Juli 2013, Thomas Goirand wrote:
> The problem isn't that OpenRC isn't fit. The problem is that *NONE* of
> the projects are fitting *ALL* of our requirements. All of the 3
> solutions have problems. 

so, there is systemd and there is upstart. what is the 3rd solution?

After having read http://wiki.debian.org/OpenRC  and looking at  the 
packaging, I would like you to stop speaking about openrc for Debian as if 
existed. 
(In case you curious, read the paragraph labeled "Compile Out OpenRC" on that 
wiki page and clone git://anonscm.debian.org/collab-maint/openrc.git and read 
debian/openrc.postinst.)

So pleease, stop hyping something which is not even remotely ready, until 
it at least is installable with "git clone && debuild" or better yet, until it 
passed NEW. 

Oh, and there should also be a sane way to remove openrc after trying it. 
Restoring from backup is not such a way.


cheers,
Holger, who thinks the 3rd solution must by SysV-init


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

Re: Survey answers part 3: systemd is not portable and what this means for our ports

2013-07-20 Thread Josselin Mouette 
Le samedi 20 juillet 2013 à 13:40 +0800, Thomas Goirand a écrit : 
> The problem isn't that OpenRC isn't fit. The problem is that *NONE* of
> the projects are fitting *ALL* of our requirements.

What requirements are you talking about? Which requirements are not met
by systemd?

If this is about kFreeBSD, it would be nice and all to share the init
system with these ports, but it should certainly not have an influence
on the choice of init system for the Linux ports.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1374312478.4511.2.camel@tomoyo

Re: PulseAudio

2013-07-20 Thread Vincent Bernat 
 ❦ 20 juillet 2013 10:10 CEST, Helmut Grohne  :

> Your claim about removing meaningless numbering is just wrong. Like Alsa
> numbers cards PA numbers sinks. The dbus object path of a sink does not
> contain its name, but uses the sink number instead. This equally applies
> to sources, cards, profiles, samples, streams, and modules. Everything
> is identified by a number.

Most users won't use the DBus interface. They will use a more friendly
program like pavucontrol. In this program, I get profiles for each
soundcard (Analog Stereo Duplex or Digital Stereo Output or Analog 7.1
output) with the possibility to select the appropriate port without
fiddling with all those mixer controls (to use front headphones for
example). This more likely to help the user than having 20 sliders in
ALSA mixer.

>> Nobody cares about pacmd list-* being too verbose. Is it a serious
>> argument about maturity?
>
> I think that a program whose UI sucks, can be seriously annoying. I hope
> that giving an example does not start another flamewar. From my point of
> view the subversion UI sucked until the introduction of svn log --diff,
> because showing recent changes was too hard. This has caused me to use a
> different UI instead of svn in a few cases. I do care.
>
> People started to use pacmd as a programmable interface. Upstream fears
> that changes to it could break user scripts. By now it is a hybrid of a
> supposedly human-readable and a somewhat machine-readable interface.
> Other tools have avoid this trap as they matured. An example being nmap
> -o$letter.
>
> Worse, different UIs to PA use different terminology. What is called
> sink in pacmd is called "output device" in pavucontrol. The concept of a
> "default-sink" on side of pacmd is named "fallback device" in
> pavucontrol.

Well, for most users, pacmd is not the interface to use PulseAudio. This
is either the mixer of your desktop environment or pavucontrol. It seems
a good idea that the laters are using an easier terminology than
"sinks".
-- 
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)


pgp0X0gdltisK.pgp
Description: PGP signature

Re: PulseAudio

2013-07-20 Thread Vincent Bernat 
 ❦ 20 juillet 2013 08:48 CEST, Andrei POPESCU  :

>> For years, Linux had the reputation of having a terribly difficult audio
>> setup and thanks to PulseAudio and its now wide support in applications,
>> this is now behind us.
>
> Have you been reading debian-user lately? One of the first 
> recommendations is still "uninstall pulseaudio and see if it works".

No, I was not aware. I am sorry for that. PulseAudio being autostarted,
it may be difficult to diagnose if the problem comes from Alsa or
PulseAudio without uninstalling it. Was PulseAudio the culprit?
-- 
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plauger)


pgpqRXJmefvZ0.pgp
Description: PGP signature

Re: PulseAudio

2013-07-20 Thread Marc Haber 
On Sat, 20 Jul 2013 11:31:10 +0200, Josselin Mouette 
wrote:
>people trying to map their ideology of what a
>Debian system should be to users

Hear! Hear!

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1v0w6q-0004y2...@swivel.zugschlus.de

Re: Survey answers part 3: systemd is not portable and what this means for our ports

2013-07-20 Thread Marc Haber 
On Sat, 20 Jul 2013 11:27:58 +0200, Josselin Mouette 
wrote:
>If this is about kFreeBSD, it would be nice and all to share the init
>system with these ports, but it should certainly not have an influence
>on the choice of init system for the Linux ports.

Why?

Grüße
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1v0w5w-0004xv...@swivel.zugschlus.de

Re: Survey answers part 3: systemd is not portable and what this means for our ports

2013-07-20 Thread Holger Levsen 
On Samstag, 20. Juli 2013, Marc Haber wrote:
> Why?

http://lists.debian.org/debian-devel/2013/05/msg00725.html


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

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-20 Thread Ondřej Surý 
On Sat, Jul 20, 2013 at 1:37 AM, brian m. carlson <
sand...@crustytoothpaste.net> wrote:

> On Fri, Jul 19, 2013 at 04:29:21PM +0200, Ondřej Surý wrote:
> > Hi,
> >
> > would FOSS Exception similar to
> > http://www.mysql.com/about/legal/licensing/foss-exception/ fix the
> > relicensing problem?
> >
> > If so, I will propose Oracle developers to add the FOSS Exception to
> > Berkeley DB licensing.
> >
> > The MySQL FOSS Exception doesn't include 4-clause BSD, so it still might
> > bar some software to create derivative works with Berkeley DB, but the
> list
> > would be considerably shorter. Or they will need to add the 4-clause BSD
> > license to the exception list.
>
> Notably, it's also missing the GPL version 2.  This isn't a problem for
> MySQL, since it's already GPLv2, but there's probably quite a bit of
> software that is GPLv2 that uses Berkeley DB.  Also, there is a wide
> variety of BSD licenses that are incompatible, as you've pointed out.
>
> Personally, I think the easiest and best solution is simply to stick
> with Berkeley DB 5.3.  It avoids all the pain of relicensing and the
> inevitable licensing bugs that *will* show up.  Not to mention that some
> upstreams will be unamused at Oracle's shenanigans and won't want to
> support BDB 6.
>

I disagree here. Berkeley DB is not a flawless software and we need an
upstream support for bugs which creep up sometimes. Having the latest
supported version would help here.

Also if we have an upstream that is willing to relicense Berkeley DB
according to our needs, then we should work with them, not against them.

So the question remains - if I am to haggle with upstream, then what should
I propose?

O.
-- 
Ondřej Surý

Re: PulseAudio

2013-07-20 Thread Adam Borowski 
On Sat, Jul 20, 2013 at 08:24:26AM +0200, Vincent Bernat wrote:
> That's not a channel weight matrix, that's a remap of the channels. It's
> not something fancy to have the rear left channel go to the rear left
> speaker.
> 
> As for the channel weight matrix, it's usually the job of the AV
> amplifier to do that. And of course PulseAudio has also something like
> that: run pavucontrol and move the sliders for each channels. I don't
> see exactly the point to go to the documentation for that. PulseAudio is
> easy.

Excuse me but I can't seem to find that in pavucontrol.  All I see is a
single slider for each channel.

Ie, instead of:
1 0 0 0 0
0 1 0 0 0
0 0 1 0 0
0 0 0 1 0
0 0 0 0 1
you can have:
1   0   0 0 0
0 0.5   0 0 0
0   0 0.8 0 0
0   0   0 1 0
0   0   0 0 1
but not:
1   0   0 0 0
0 0.5 0.2 0 0
0 0.1 0.7 0 0 [these particular values don't make much sense]
0   0   0 1 0
0   0   0 0 1

That not really documented ability to remap channels allows at most
permuting them.  I also wonder what would be the purpose, unless your
setup is hard-wired at every single step, without the ability to pull
a plug and put it in correctly.

The purpose of the matrix is twofold:
* to handle placement of speakers that are not at correct angles
* properly down/up scaling signal that has more/less channels than
  you have speakers

Both of those are impossible using only capabilities PulseAudio has
(or at least exposes), while easy using ALSA.


A wish:
editing these matrices (multiple: you need one for at least 2->5.1,
5.1->5.1, 7.1->5.1) is not anything I'd expose an average user to, either.
The best GUI would be what I've once seen on some manufacturer-specific
Windows driver: you add/remove speaker icons and move them on a 2D display.
The matrices are then generated based on relative angles and distances.
Preferably together with a clone of ALSA's speaker-test.


-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130720133739.ga5...@angband.pl

Re: Survey answers part 3: systemd is not portable and what this means for our ports

2013-07-20 Thread Ondřej Surý 
On Fri, Jul 19, 2013 at 11:14 PM, Russ Allbery  wrote:

> I would *hope* a lot of Debian developers would do things like that, for
> any of the options!  There's no substitute for actually trying the
> software and seeing how easy it is to use, how well it works, and how
> difficult it is to support.  There are a bunch of good reasons to install
> packages, even if one isn't going to use them regularly.  Among other
> things, it's often the easiest way to read the documentation so that one
> knows what people are even talking about!
>

JFTR I did that (I already know upstart quite well from Ubuntu, so I just
did install systemd on my work machine) and now I am replacing sysvinit
with systemd on every machine I maintain. I have missed a supervised
services from init(1) for too long (I can only +1 to Russ's mail about
experiences with administration) and I have already used that to supervise
crashing gitlab-sidekiq service.

I also did add support for systemd and upstart to php5-fpm (and kept
sysvinit script) and I am quite confident I can support all three of them
without any trouble. It has a learning curve, but I am willing to learn
that (sysvinit scripts also have a learning curve - the idea that those are
just simple shell scripts are just wrong.)

And if I could use upstart job to extort Ubuntu PHP maintainers to
contribute back more, even better! :)

Anyway - this is the question for all proponents of systemd and upstart.
It's quite obvious that we cannot reach full consensus (and we never will
be able to reach one), but we have a body to make technical decisions -
tech-ctte. Why we just don't shove it to tech-ctte and let the independent
body decide? (Or GR, but I think that GR is an overkill.) This could stop
this endless debate and force the participants to write the technical
summary.

O.
-- 
Ondřej Surý

Re: Berkeley DB 6.0 license change to AGPLv3

2013-07-20 Thread Francesco Poli 
On Sat, 20 Jul 2013 15:33:41 +0200 Ondřej Surý wrote:

[...]
> So the question remains - if I am to haggle with upstream, then what should
> I propose?

In my own personal opinion?
I would recommend persuading upstream to switch back to the previous
BDB license (the one used up to Berkeley DB 5.3), or, at least, to
switch to the GNU LGPL v2.1, in order to enhance compatibility with
BDB-using software.

I don't know whether this can succeed, though...


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpxkHq5T56Rs.pgp
Description: PGP signature

Re: Survey answers part 3: systemd is not portable and what this means for our ports

2013-07-20 Thread Jeremy Bicha 
On 20 July 2013 08:17, Marc Haber  wrote:
> On Sat, 20 Jul 2013 11:27:58 +0200, Josselin Mouette 
> wrote:
>>If this is about kFreeBSD, it would be nice and all to share the init
>>system with these ports, but it should certainly not have an influence
>>on the choice of init system for the Linux ports.
>
> Why?

Because http://lists.debian.org/debian-devel/2013/07/msg00379.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAAajCMYX_wABY-TsZd0=Ga+rBK7BCq-t6KC8chXASDXnFgN=r...@mail.gmail.com

Re: PulseAudio

2013-07-20 Thread Vincent Bernat 
 ❦ 20 juillet 2013 15:37 CEST, Adam Borowski  :

>> That's not a channel weight matrix, that's a remap of the channels. It's
>> not something fancy to have the rear left channel go to the rear left
>> speaker.
>> 
>> As for the channel weight matrix, it's usually the job of the AV
>> amplifier to do that. And of course PulseAudio has also something like
>> that: run pavucontrol and move the sliders for each channels. I don't
>> see exactly the point to go to the documentation for that. PulseAudio is
>> easy.
>
> Excuse me but I can't seem to find that in pavucontrol.  All I see is a
> single slider for each channel.
>
> Ie, instead of:
> 1 0 0 0 0
> 0 1 0 0 0
> 0 0 1 0 0
> 0 0 0 1 0
> 0 0 0 0 1
> you can have:
> 1   0   0 0 0
> 0 0.5   0 0 0
> 0   0 0.8 0 0
> 0   0   0 1 0
> 0   0   0 0 1
> but not:
> 1   0   0 0 0
> 0 0.5 0.2 0 0
> 0 0.1 0.7 0 0 [these particular values don't make much sense]
> 0   0   0 1 0
> 0   0   0 0 1

OK. I don't know if it's possible with PulseAudio.

> That not really documented ability to remap channels allows at most
> permuting them.  I also wonder what would be the purpose, unless your
> setup is hard-wired at every single step, without the ability to pull
> a plug and put it in correctly.

With nVidia HDMI output, it is quite common to have rear left and rear
right inverted. You cannot just modify the physical placement of your
speakers because other sources will have the "right" order (and when you
play AC3, you will also get the "right" order).
-- 
Use debugging compilers.
- The Elements of Programming Style (Kernighan & Plauger)


pgp_KISFnYL1d.pgp
Description: PGP signature

Re: On accepting pre-generated doc from upstream

2013-07-20 Thread Joachim Breitner 
Hi,

Am Donnerstag, den 18.07.2013, 14:45 +0200 schrieb Goswin von Brederlow:
> On Thu, Jun 06, 2013 at 11:35:46PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote: 
> > - Using the full source tarball. Saddly this means having to compile most 
> > of 
> > it in order to get the tools for building the doc, or hacking far too much 
> > the 
> > build system to do something else.
> > 
> > - Build each submodule's doc.
> > 
> - Option 3:
> 
> For packages 1 and 2 build without docs but also build a
> package{1,2}-src package.

Option 4:

Have two source packages, package1 and package1-for-docs. They’d have
exactly the same upstream tarball, but of course different debian/-dirs:
  * The first builds the binaries and no docs.
  * The second source package builds only the docs.
The gain is that the second source package can build-depend on package2
without introducing build dependency cycles. I’d say it justifies the
slight unprettiness of having the same tarball twice in the archive.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata




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

Re: Survey answers part 3: systemd is not portable and what this means for our ports

2013-07-20 Thread Paul Tagliamonte 
(On my phone, I hate this ui, sorry for the CC Russ)

On Jul 19, 2013 5:30 PM, "Russ Allbery"  wrote:
>
> David Kalnischkies  writes:
>
> > Of course, both analysis are obviously flawed as this popcon data can't
> > really be interpreted that way as its an apple to banana comparison and
> > way too few datapoints, but everyone likes misinterpret statistics as
> > "proven" by this thread – and statistics say that I am a pro-faker!
>
> > "I only believe in statistics that I doctored myself."
> >  -- Winston Churchill
>
> [...]
>
> > P.S.: Everyone who is now trying to disprove my "facts" has missed the
> > point.
>
> Yes, exactly.
>
> The point is that none of this really means very much at this point, for a
> whole bunch of reasons.  Ways to use non-sysvinit init systems are not
> widely publicized, neither upstart nor systemd are (yet) that widely
> supported, and both are quite firmly "experimental" configurations at this
> point.  There's nothing *wrong* with that; it just means that if you're
> trying to use popcon as a democratic vote on which one people like better,
> there's simply no data there.
>
> We're still very much in the "installing things to try them out" stage.
>
> For example, as soon as I get my new laptop back from servicing, the
> systemd numbers will go up by one, because I want to try running it for a
> while so that my opinions are based on facts and so that I can start
> adding systemd unit files to some of my packages.  I don't have the same
> level of need to do so for upstart because I can see upstart on Ubuntu
> boxes, although I'm looking around for a good system to run with upstart
> for a while as well for similar reasons.  None of those really constitute
> user choices or votes or whatnot for that particular init system.
>
> I would *hope* a lot of Debian developers would do things like that, for
> any of the options!  There's no substitute for actually trying the
> software and seeing how easy it is to use, how well it works, and how
> difficult it is to support.  There are a bunch of good reasons to install
> packages, even if one isn't going to use them regularly.  Among other
> things, it's often the easiest way to read the documentation so that one
> knows what people are even talking about!

Yes. This. I was a pretty avid syatemd "hater", but having used it for a
solid 6 months, I can't imagine using anything else. I find myself
installing systemd as one of the first things I do when I get a new install.

If you're laying down systemd criticism - *try* systemd for a month.

My 2c,
  T

P.s. sorry if this comes out HTML.

>
> Maybe at some point in the future when whatever options we've converged on
> have been widely publicized and everyone knows how to switch and test and
> whatnot we might be able to gauge something about levels of interest from
> popcon.  But it's going to be a while before we're at that point.
>
> --
> Russ Allbery (r...@debian.org)   
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
> Archive: http://lists.debian.org/87ip06fe1e@windlord.stanford.edu
>

Re: Survey answers part 3: systemd is not portable and what this means for our ports

2013-07-20 Thread Matthias Klumpp 
2013/7/20 Paul Tagliamonte :
> Yes. This. I was a pretty avid syatemd "hater", but having used it for a
> solid 6 months, I can't imagine using anything else. I find myself
> installing systemd as one of the first things I do when I get a new install.
>
> If you're laying down systemd criticism - *try* systemd for a month.
Me too - I was never a "hater", I always loved the idea and concept of
logind and systemd, but I was sceptical about the benefits of e.g. the
journal and the dbus integration (and I also feared that too much
functionality would be moved into PID 1).
This has changed immediately after I started to use the features it
provides :P I now run rsyslog and the journal in parallel, while I
previously disabled it. I also just *love* the multiseat capacities
systemd provides, and the separation of user-written units and
distributor-provided systemd-units (you can still easily display
differences by using a systemd-tool).
And for developers of DEs, logind is just great ;-) (admittedly, I
always hated ConsoleKIt ^^)
Also, I don't find upstream very hostile - even the most stupid
questions were answered with patience, and Lennart even resembled some
of the concepts for me on IRC, when I asked some really silly
questions about cgroups and the systemd design decisions about a year
ago. The documentation is very good too (and now, since Google doesn
not consider "systemd" a typo anymore, you can also easily find it
online, if you don't want to install the manual pages)
I would recommend trying systemd in a VM to see what changes it brings
:-) (make sure sd is recent enough (>= 204))
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKNHny-ZCZWyF2bju4seK+Ft8Qh8L2p7c-YvpZ=2egoii4v...@mail.gmail.com

Re: PulseAudio

2013-07-20 Thread Andrei POPESCU 
On Sb, 20 iul 13, 11:31:10, Josselin Mouette wrote:
> Le samedi 20 juillet 2013 à 09:48 +0300, Andrei POPESCU a écrit : 
> > Have you been reading debian-user lately? One of the first 
> > recommendations is still "uninstall pulseaudio and see if it works".
> 
> Having debian-user run by people trying to map their ideology of what a
> Debian system should be to users coming for help is probably part of
> what our reputation of poor end-user support is built on.

Not exactly sure what ideology has to do with basic troubleshooting.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: PulseAudio

2013-07-20 Thread Andrei POPESCU 
On Sb, 20 iul 13, 11:49:25, Vincent Bernat wrote:
>  ❦ 20 juillet 2013 08:48 CEST, Andrei POPESCU  :
> 
> >> For years, Linux had the reputation of having a terribly difficult audio
> >> setup and thanks to PulseAudio and its now wide support in applications,
> >> this is now behind us.
> >
> > Have you been reading debian-user lately? One of the first 
> > recommendations is still "uninstall pulseaudio and see if it works".
> 
> No, I was not aware. I am sorry for that. PulseAudio being autostarted,
> it may be difficult to diagnose if the problem comes from Alsa or
> PulseAudio without uninstalling it. Was PulseAudio the culprit?

Well, at least in some cases audio started working, but I couldn't tell 
you more as I stay out of those threads because I don't use pulseaudio 
myself.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: how can we help DSA save money (was: bits from the DPL - June 2013)

2013-07-20 Thread Steven Chamberlain 
Hello,

On 09/07/13 10:40, Lucas Nussbaum wrote:
> I approve the purchase of additional storage for backups (~2300 EUR) and
> for our new hosting location at Bytemark, where snapshot.d.o will be moved
> soon (~£7000).

May I ask some more details about this please;  what kind/amount of
storage can DSA get for this, and are these costs for the hardware and
warranty, or does it also include costs of setup, hosting, power or
other ancillary bits?

The reason I ask, is that a feature of Debian software and development
work, is being able to derive more benefit from lower-cost,
general-purpose hardware.  (And also because this stood out as being
quite a big purchase if it is just storage).

This is somewhere that contributors could help instead of financially,
but by designing, developing, or simply documenting solutions that would
fulfill DSA needs.  I know this happens a bit already, DSA heavily makes
use of Debian software and there is even a list of relevant usertagged
bugs[0].  But what things are we not using Debian for yet, and where
could we save DSA some money?

[0]:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-ad...@lists.debian.org

Thanks!
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51eae099.5040...@pyro.eu.org

Bug#717428: ITP: libgisi -- communication library for isi modems

2013-07-20 Thread Sebastian Reichel 
Package: wnpp
Severity: wishlist
Owner: Sebastian Reichel 

* Package name: libgisi
  Version : 0.1.0
  Upstream Author : freesmartphone.org Team
* URL : http://www.freesmartphone.org/
* License : GPL
  Programming Lang: C, Vala
  Description : communication library for isi modems

This project contains the following parts:

 * libgisi (standalone), a low level library for communicating with
   ISI devices, such as the modem found in some Nokia devices.

 * vala bindings for libgisi.

 * protocol definitions and enumerations.

 * libgisicomm, a high level library for communicating with
   ISI modem devices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130720195037.6581.27659.reportbug@earth.universe

Re: how can we help DSA save money (was: bits from the DPL - June 2013)

2013-07-20 Thread Ben Hutchings 
On Sat, 2013-07-20 at 20:10 +0100, Steven Chamberlain wrote:
> Hello,
> 
> On 09/07/13 10:40, Lucas Nussbaum wrote:
> > I approve the purchase of additional storage for backups (~2300 EUR) and
> > for our new hosting location at Bytemark, where snapshot.d.o will be moved
> > soon (~£7000).
> 
> May I ask some more details about this please;  what kind/amount of
> storage can DSA get for this, and are these costs for the hardware and
> warranty, or does it also include costs of setup, hosting, power or
> other ancillary bits?

Should be answered by:
https://lists.debian.org/debian-devel-announce/2013/03/msg00010.html

> The reason I ask, is that a feature of Debian software and development
> work, is being able to derive more benefit from lower-cost,
> general-purpose hardware.

Debian attempts to support older hardware than many distributions, but
it doesn't make software consume less resources.

> (And also because this stood out as being
> quite a big purchase if it is just storage).

We're not talking about a home NAS...

> This is somewhere that contributors could help instead of financially,
> but by designing, developing, or simply documenting solutions that would
> fulfill DSA needs.  I know this happens a bit already, DSA heavily makes
> use of Debian software and there is even a list of relevant usertagged
> bugs[0].  But what things are we not using Debian for yet, and where
> could we save DSA some money?

I can't understand how you expect to save money on hardware by applying
'more Debian'.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.


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

Bug#717434: RFA: socat -- multipurpose relay for bidirectional data transfer

2013-07-20 Thread Chris Taylor 
Package: wnpp
Severity: normal
X-Debbugs-CC: debian-devel@lists.debian.org


I intend to orphan socat in the next few weeks and would like someone to
adopt the package as it is still useful to many. I no longer have the time
nor motivation/need to continue to maintain it, therefore I am formally
requesting its adoption.


Description-en: multipurpose relay for bidirectional data transfer
Socat (for SOcket CAT) establishes two bidirectional byte streams
and transfers data between them. Data channels may be files, pipes,
devices (terminal or modem, etc.), or sockets (Unix, IPv4, IPv6, raw,
UDP, TCP, SSL). It provides forking, logging and tracing, different
modes for interprocess communication and many more options.
.
It can be used, for example, as a TCP relay (one-shot or daemon),
as an external socksifier, as a shell interface to Unix sockets,
as an IPv6 relay, as a netcat and rinetd replacement, to redirect
TCP-oriented programs to a serial line, or to establish a relatively
secure environment (su and chroot) for running client or server shell
scripts inside network connections. Socat supports sctp as of 1.7.0.


Thanks,
Chris

Re: PulseAudio

2013-07-20 Thread Bernd Zeimetz 
On 07/17/2013 06:07 PM, John Paul Adrian Glaubitz wrote:
> On 07/17/2013 05:40 PM, Marc Haber wrote:
>> On Wed, 17 Jul 2013 10:58:49 +0200, John Paul Adrian Glaubitz
>>  wrote:
>>> Some sound cards expose two dozens or more
>>
>> ... usually underdocumented, if documented at all, ...
> 
> The Fedora people had a very nice screen shot of the ALSA mixer
> back then which said more than a 1000 words:
> 
>> http://people.redhat.com/alexl/files/why-alsa-sucks.png

That does not necessarily look like an alsa problem, just a problem of the GUI
being to stupid to show all the settings in a useful way. I'd guess the card has
several pcm channels, all wih their own chorus/reverb/ settings - so the gui
could group then properly and show nice buttons


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51eb0a3c.6090...@bzed.de

Re: Survey answers part 3: systemd is not portable and what this means for our ports

2013-07-20 Thread The Wanderer 

[I am almost certainly going to regret this.]

On 07/20/2013 12:52 PM, Paul Tagliamonte wrote:


(On my phone, I hate this ui, sorry for the CC Russ)

On Jul 19, 2013 5:30 PM, "Russ Allbery"  wrote:



I would *hope* a lot of Debian developers would do things like
that, for any of the options!  There's no substitute for actually
trying the software and seeing how easy it is to use, how well it
works, and how difficult it is to support.  There are a bunch of
good reasons to install packages, even if one isn't going to use
them regularly.  Among other things, it's often the easiest way to
read the documentation so that one knows what people are even
talking about!


Yes. This. I was a pretty avid syatemd "hater", but having used it
for a solid 6 months, I can't imagine using anything else. I find
myself installing systemd as one of the first things I do when I get
a new install.

If you're laying down systemd criticism - *try* systemd for a month.


For my part, despite having not personally used it I'm not (and haven't
recently, and I hope ever, been) opposed to systemd's functionality, or
even necessarily to its design - just to its apparent philosophy, and
where that philosophy might take it (and anyone who adopts and therefore
comes to rely on it) in the future.

Leaving aside fears about what upstream might decide to do at some point
(e.g. the "make udev require systemd" proposal), much of that objection
simply comes down to how difficult it looks like it would be to switch
*away* from systemd, once it becomes entrenched.

Making the switch away from the entrenched sysvinit is visibly very
difficult, at least as a social matter, even in the environment we have.
systemd et al., by virtue of the integration which is apparently one of
their selling points and the "proprietary"[0] interfaces they seem to
use, look like they would create an environment where a similar switch
to "whatever comes next" would be even harder - at least partly as a
technical matter, rather than a social one.

Similarly, in an environment where systemd is entrenched, setting up a
system which doesn't use it (for whatever reason that might be
desirable, e.g. a "toy" system of some sort or an experimental
environment or a system with extremely limited resources) without losing
other functionality looks like it might be considerably harder than
setting up something which doesn't use sysvinit without losing
functionality not provided by the init scripts currently is.

I could easily be wrong about both of those, and I hope I am, but so far
I don't think I've seen anything which even tries to convince me
otherwise.


[0] Meaning approximately "we create our own language and talk it to
ourselves, and anyone else who wants to talk to us has to learn our
language", not intending to imply "undocumented" or "legally restricted"
or anything of the sort. This isn't a very good term for what I mean,
but I couldn't find a better one.

--
   The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
  - LiveJournal user antonia_tiger


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51eb1b7d.8090...@fastmail.fm

Bug#717466: ITP: sphinxcontrib-httpdomain -- Sphinx domain for HTTP APIs

2013-07-20 Thread Thomas Goirand 
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: sphinxcontrib-httpdomain
  Version : 1.1.8
  Upstream Author : Hong Minhee
* URL : https://pypi.python.org/pypi/sphinxcontrib-httpdomain
* License : BSD-2-clauses
  Programming Lang: Python
  Description : Sphinx domain for HTTP APIs

 This contrib extension, sphinxcontrib.httpdomain provides a Sphinx domain for
 describing RESTful HTTP APIs. It generates RESTful HTTP API reference
 documentation from a Flask application’s routing table, similar to
 sphinx.ext.autodoc.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130721053220.28236.39112.report...@buzig.gplhost.com

Bug#717467: ITP: sphinxcontrib-pecanwsme -- documenting APIs built with Pecan and WSME

2013-07-20 Thread Thomas Goirand 
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: sphinxcontrib-pecanwsme
  Version : 0.2
  Upstream Author : Doug Hellmann
* URL : https://pypi.python.org/pypi/sphinxcontrib-pecanwsme
* License : Apache-2.0
  Programming Lang: Python
  Description : documenting APIs built with Pecan and WSME

 sphinxcontrib.pecanwsme is an extension to Sphinx for documenting APIs
 built with Pecan and WSME.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130721055019.30088.78026.report...@buzig.gplhost.com

Re: how can we help DSA save money

2013-07-20 Thread Tollef Fog Heen 
]] Steven Chamberlain 

> On 09/07/13 10:40, Lucas Nussbaum wrote:
> > I approve the purchase of additional storage for backups (~2300 EUR) and
> > for our new hosting location at Bytemark, where snapshot.d.o will be moved
> > soon (~£7000).
> 
> May I ask some more details about this please;  what kind/amount of
> storage can DSA get for this, and are these costs for the hardware and
> warranty, or does it also include costs of setup, hosting, power or
> other ancillary bits?

Backups is 8 x 4T Seagate Constellation drives.  Bytemark is 24 x 4T
Seagate Constellation drives.  We get setup, hosting, power, etc
donated, so that is not part of the cost there.

> The reason I ask, is that a feature of Debian software and development
> work, is being able to derive more benefit from lower-cost,
> general-purpose hardware.  (And also because this stood out as being
> quite a big purchase if it is just storage).

It's quite a bit of storage.  Snapshot is large.

> This is somewhere that contributors could help instead of financially,
> but by designing, developing, or simply documenting solutions that
> would fulfill DSA needs.

The only realistic alternative to spending the money here would be if
some company donated the equivalent in hardware.  It's not really
possible to code ourselves out of this one.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87siz8jvfr@xoog.err.no