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

[Thomas Goirand]

On 07/19/2013 08:32 AM, John Paul Adrian Glaubitz wrote:
> On 07/18/2013 09:45 PM, Thomas Goirand wrote:
>> If OpenRC isn't what we need (I still believe it does address a bunch of
>> problems and that the fact it can work for non-Linux port is a key
>> factor), then I'd be for Upstart. I do maintain my packages so that they
>> work for both Ubuntu and Debian, having to write things for 2 init
>> systems would be useless added work.
> 
> Popcon however speaks a completely different language:

Even if that was truth (Russ showed it might not), I don't see how this
is a counter argument to what I wrote. Besides this, this is not a
voting system: if we were governed only by a majority of users, we would
all be running Windows.

Thomas


-- 
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/51e8f58f.7060...@debian.org

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

[Thijs Kinkhorst]

On Thu, July 18, 2013 09:15, Thomas Goirand wrote:
>> - Fast startup
>
> I thought everyone claimed (including systemd supporters) that this was
> a "teenager side effect" which we didn't care much about.

Definitely not. Debian should care about fast boot a lot. Rebooting a
system, planned or not, is downtime. If we can reduce the amount of
downtime that Debian systems experience, that is a big win.

Someone mentioned server POST that take minutes of boot time anyway. True.
However, this ignores that the world and their dog are moving to virtual
machines en masse for hosting their services. The boot times of vm's are
negligible and we now have many systems rebooting in < 1 min. This is a
very big advantage for professional and large scale installations, and the
more that time is reduced, the more advantageous it will be for these
users.


Cheers,
Thijs


-- 
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/9fc621eb254d5515cfac75075e4918c5.squir...@aphrodite.kinkhorst.nl

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

[Tollef Fog Heen]

]] Russ Allbery 

> The upstart package takes over process 1, so 100% of the systems with the
> upstart package installed are using it as process 1.  The same is true of
> systemd-sysv, of course.

This isn't necessarily true.  I used to run my laptop with systemd as
pid 1 and the upstart package installed, for historical reasons (it used
to run Ubuntu and was upgraded to Debian).  I agree that's not a
reasonable configuration, though.

> I don't think there's a way to do a straight apples to apples comparison
> on adoption based on the current popcon numbers.  The number of people
> running systemd is more than the install count of systemd-sysv, but less
> (and I suspect much less) than the install count of systemd.

Correct.  We are not talking about a huge number of systems in any
case (for either systemd or upstart).

-- 
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/m2ehau3orc@rahvafeir.err.no

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

[John Paul Adrian Glaubitz]

On 07/19/2013 10:15 AM, Thomas Goirand wrote:

Popcon however speaks a completely different language:


Even if that was truth (Russ showed it might not), I don't see how this
is a counter argument to what I wrote. Besides this, this is not a
voting system: if we were governed only by a majority of users, we would
all be running Windows.


Jeez, and I was honestly thinking all the time that Debian was a
community project which has a democratic organization and larger
decisions are primarily made with our users in mind.

I thought we were making software which is to be useful for our
users in the end, but it turns out that according to your
line of arguments, Debian is primarily made to fuel the egos
of its developers.

Guess, I am in the wrong project then.

Cheers,

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/51e905ef.5080...@physik.fu-berlin.de

Bug#717315: ITP: libdata-uuid-perl -- globally/universally unique identifiers (GUIDs/UUIDs)

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libdata-uuid-perl
  Version : 1.219
  Upstream Author : Alexander Golomshtok 
* URL : http://search.cpan.org/dist/Data-UUID/
* License : NTP~uuid
  Programming Lang: Perl, C
  Description : globally/universally unique identifiers (GUIDs/UUIDs)

 Data::UUID provides a framework for generating v3 UUIDs (Universally
 Unique Identifiers, also known as GUIDs (Globally Unique Identifiers).
 A UUID is 128 bits long, and is guaranteed to be different from all
 other UUIDs/GUIDs generated until 3400 CE.
 .
 UUIDs were originally used in the Network Computing System (NCS) and
 later in the Open Software Foundation's (OSF) Distributed Computing
 Environment.  Currently many different technologies rely on UUIDs to
 provide unique identity for various software components. Microsoft
 COM/DCOM for instance, uses GUIDs very extensively to uniquely identify
 classes, applications and components across network-connected systems.
 .
 The algorithm for UUID generation, used by this extension, is described
 in the Internet Draft "UUIDs and GUIDs" by Paul J. Leach and Rich Salz.
 (See RFC 4122.)  It provides reasonably efficient and reliable
 framework for generating UUIDs and supports fairly high allocation
 rates -- 10 million per second per machine -- and therefore is suitable
 for identifying both extremely short-lived and very persistent objects
 on a given system as well as across the network.


-- 
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/20130719093817.28460.44672.report...@auryn.jones.dk

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

[Chow Loong Jin]

On Fri, Jul 19, 2013 at 10:50:36AM +0200, Thijs Kinkhorst wrote:
> On Thu, July 18, 2013 09:15, Thomas Goirand wrote:
> >> - Fast startup
> >
> > I thought everyone claimed (including systemd supporters) that this was
> > a "teenager side effect" which we didn't care much about.
> 
> Definitely not. Debian should care about fast boot a lot. Rebooting a
> system, planned or not, is downtime. If we can reduce the amount of
> downtime that Debian systems experience, that is a big win.
> 
> Someone mentioned server POST that take minutes of boot time anyway. True.
> However, this ignores that the world and their dog are moving to virtual
> machines en masse for hosting their services. The boot times of vm's are
> negligible and we now have many systems rebooting in < 1 min. This is a
> very big advantage for professional and large scale installations, and the
> more that time is reduced, the more advantageous it will be for these
> users.

It's also worth noting that kexec-based reboots (if they work properly) can
eliminate POST time, but still has to go through the whole init run.

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature

Re: PulseAudio

[Helmut Grohne]

On Thu, Jul 18, 2013 at 07:05:16AM +0200, John Paul Adrian Glaubitz wrote:
> Yeah, I see that. But my original point was that the many griefs and
> complaints people about PulseAudio have originate from the fact that
> many people already used it when it simply wasn't ready yet, so it's
> not fair to use this as an argument against PA.

You suggest that PulseAudio is still not yet mature. The arguments Steve
Langasek made and my clueless user experience indeed confirm that
sentiment. What I do not understand here is why gnome is pulling it in
as a dependency in a stable release then.

In your reply to Wouter Verhelst you repeatedly argue how PulseAudio
saves time on your end. As has been pointed out this matches neither
Wouter's nor my experience. Clearly your claims are not universal. It
appears that your use case is significantly different from Wouter's or
mine. For instance installing PA breaks an existing mpd (and PA devs
acknowledge that, fixing this is harder though due to the architecture).

One of the main causes for grief with PA is that you cannot opt-in to it
like you can with Jack. Like PA, Jack can implement the default alsa
device, but it doesn't do that unless you ask it. Also you are in charge
to decide when to start Jack. That removes a fair amount of debugging,
because you can easily determine whether an issue is to be attributed to
Jack or not.

Just to be clear: Jack is not the solution here. It solves a different
problem: low latency.

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.

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.

It also appears that much of the troubleshooting documentation
concerning PA, that appears in Google, is seriously broken. Half of it
advises modifying files in /usr, so it breaks when you upgrade the
package. This applies especially to Ubuntu related docs. While PA is not
responsible for this broken documentation, the creation was likely
caused by absence of useful troubleshooting documentation on the side of
PA.

So PA is not removing complexity, but adding to it. Surely a bit of
complexity is needed to solve sophisticated tasks, but it could indeed
do better. For instance pacmd list-* could get some verbosity switches
and hide some details in the default view. Scanning a pacmd list-sinks
output for the relevant info just takes too long (in addition to needing
to scroll the terminal).

The sheer number of issues I find when investigating a supposedly mature
project is stunning. Clearly PA does not "just work" for me and some
others. On the bright side I can recommend upstreams irc channel and
reported issues appear to get fixed quickly.

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/20130719095652.ga19...@alf.mars

Re: [Piuparts-devel] adequate now reports incompatible-licenses - need help to verify and file bugs

[Holger Levsen]

Hi,

On Mittwoch, 10. Juli 2013, Andreas Beckmann wrote:
> I just noticed in my local piuparts instance that adequate now issues
> incompatible-licenses tags, too. Nice feature, Jakub! :-)

adequate 0.7 is now installed on pejacevic.d.o and piu-slave, so from now on, 
these results will be shown on piuparts.debian.org as well.
 
> For sid I've seen so far:
> @Holger: this requires adequate 0.7 - is that running on the slave?
> If yes, please reschedule above logs - and maybe create a report for it.

done in pejacevic:/srv/piuparts.debian.org/master

find . -name "ice34-services_*.log" -o -name "libcitygml0_*.log" -o -name 
"ccbuild_*.log" -o -name "coop-computing-tools_*.log" -o -name 
"osgearth_*.log" -o -name "tellico_*.log" | xargs echo rm -v

The next piuparts-report will be done in 3h and should have new results for 
these packages.


cheers,
Holger


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

Bug#717319: ITP: libproc-terminator-perl -- module to conveniently terminate processes

[Oleg Gashev]

Package: wnpp
Severity: wishlist
Owner: Oleg Gashev 

* Package name: libproc-terminator-perl
  Version : 0.05
  Upstream Author : M. Nunberg 
* URL : https://metacpan.org/release/Proc-Terminator
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to conveniently terminate processes

 Proc::Terminator provides a convenient way to kill a process, often useful in
 utility and startup functions which need to ensure the death of an external
 process.
 .
 Proc::Terminator provides a simple, blocking, and procedural interface to
 kill a process or multiple processes (not tested), and not return until they
 are all dead.
 .
 Proc::Terminator can know if you do not have permissions to kill a process,
 if the process is dead, and other interesting tidbits.
 .
 It also provides for flexible options in the type of death a process will
 experience. Whether it be slow or immediate.


-- 
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/20130719104428.28136.77513.reportbug@localhost

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

[heroxbd]

Hi William,

William Giokas <1007...@gmail.com> writes:

> * 'Graphical UI: yes': Nope.

side note: it is from 

 http://0pointer.de/blog/projects/why.html

Cheers,
Benda


pgpLYHGdS_e5Z.pgp
Description: PGP signature

Re: Berkeley DB 6.0 license change to AGPLv3

[Ondřej Surý]

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.

O.


On Tue, Jul 2, 2013 at 9:44 AM, Ondřej Surý  wrote:

> Hi,
>
> Florian Weimer has correctly pointed out that Oracle has decided to change
> the BDB 6.0 license to AGPLv3 (
> https://oss.oracle.com/pipermail/bdb/2013-June/56.html). This hasn't
> been reflected in release tarball (probably by mistake), but since the
> AGPLv3 is not very friendly to downstream projects, we (as the Debian
> project) need to take a decision.
>
> My opinion is that this Oracle move just sent the Berkeley DB to oblivion,
> and Berkeley DB will be less and less used (or replaced by something else).
>
> What we can do right now (more can apply):
> [ ] Keep db5.3 for jessie
> [ ] Keep db5.3 for jessie+
> [ ] Keep db5.3 forever
> [ ] Suck it and relicense the downstream software as appropriate
> [ ] Block db6.0 and higher from entering Debian
> [ ] Remove Berkeley DB support from jessie+
> [ ] Remove Berkeley DB support from jessie++
> [ ] Replace Berkeley DB with free alternative [*]
> [ ] Somebody writes a BDB-compatible wrapper around the free alternative(s)
>
> As far as I am aware the most prominent users[1][2][3] of Berkeley DB are
> moving away from the library anyway, so this might not be a big deal after
> all.
>
> 1. openldap has mdb
> 2. cyrus-imapd has skiplist
> 3. subversion has moved to fsfs long time ago
>
> I am attaching list of affected software generated by:
>
> dak rm -Rn -s unstable db-defaults db5.1 db5.3 > db-depends
> < db-depends grep : | grep -Ev "^($| |#|Dependency problem found.|Will
> remove the following packages from unstable:|Maintainer:)" | sed -e
> "s/\\[.*\\]//" | cut -f 1 -d: | sort -u > package.list
> # chroot to unstable system
>  affected.list
>
> * - f.e. kyotocabinet is GPL with FOSS and Linking exception (
> http://ftp-master.metadata.debian.org/changelogs/main/k/kyotocabinet/unstable_copyright
> )
>
> kyotocabinet is a sister of tokyocabinet:
> http://tokyocabinet.sourceforge.net/benchmark.pdf
> or
> http://www.dmo.ca/blog/benchmarking-hash-databases-on-large-data/
>
> Ondrej
> --
> Ondřej Surý 
>



-- 
Ondřej Surý 

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

[Mathieu Parent]

2013/7/19 Russ Allbery :
> John Paul Adrian Glaubitz  writes:
>> On 07/19/2013 02:55 AM, Russ Allbery wrote:
>
>>> I believe the equivalent systemd package to the upstart package is the
>>> systemd-sysv package, so 174 rather than 1604 is perhaps the better
>>> number to use.
>
>> I'm not sure whether I can follow. I am using systemd on both my desktop
>> and my laptop and neither of them has the systemd-sysv package installed
>> which, AFAIK, is required for compatibility reasons only.
>
> I see no sign that installing systemd replaces init or takes over process
> 1.  All of the symlinks to do so are in the systemd-sysv package, and
> that's the only package that conflicts with sysvinit and thereby removes
> the other init system.  Am I missing something?Ah, here we go:
>
> | systemd can be installed alongside sysvinit and will not change the
> | behaviour of the system out of the box.  This is intentional.  To test
> | systemd, add:
> |
> | init=/bin/systemd
> |
> | to the kernel command line and then rebooting, or install the
> | systemd-sysv package.
>
> I didn't know about the init= method and was assuming the systemd-sysv
> method.  Anyway, my point is that I suspect the vast majority of the
> systems with the systemd package installed are not actually using it as
> process 1.
>
> The upstart package takes over process 1, so 100% of the systems with the
> upstart package installed are using it as process 1.  The same is true of
> systemd-sysv, of course.
>
> I don't think there's a way to do a straight apples to apples comparison
> on adoption based on the current popcon numbers.  The number of people
> running systemd is more than the install count of systemd-sysv, but less
> (and I suspect much less) than the install count of systemd.

As the recommended way to install systemd is using init= and not
installing systemd-sysv, maybe the popcon "vote" count is the correct
metric?

NB: "vote is the number of people who use this package regularly"


According 
http://qa.debian.org/popcon-graph.php?packages=upstart%2Csystemd&from_date=2013-06-06:

systemd is "used regulardly" on about 1200 popcon submiters, upstart
on about 600 (this is even less than 100 from 2013-07-04, but what
happened!).

Regards
--
Mathieu Parent


-- 
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/CAFX5sbyeJzuOVkEXhQZYVgxYtrab-QUxmJP==b=uj0cfaqe...@mail.gmail.com

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

[John Paul Adrian Glaubitz]

On 07/19/2013 06:57 PM, Scott Kitterman wrote:

sysvinit148865  99.83%


The reason might be that systemd does not conflict with sysvinit :).

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/51e9751c.9030...@physik.fu-berlin.de

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

[Bernd Schubert]

On 07/19/2013 06:43 PM, John Paul Adrian Glaubitz wrote:

On 07/19/2013 05:43 PM, Thomas Goirand wrote:

We try to have technical reasoning, which is (one of) the reason this
list exists. This has nothing to do with voting.


If we actually did, the choice would have already been made for systemd
long time ago. Don't make yourself any illusions. It has been explained
to you by many people before that OpenRC isn't fit for the purpose at
all and I really don't think upstart will meet the criteria either.


I thought we were making software which is to be useful for our
users in the end,...


That is the case, but not using popcon as a metric to our technical
decisions.


Well, technical reasons are obviously not counted in.


...but it turns out that according to your
line of arguments, Debian is primarily made to fuel the egos
of its developers.


Now you are crossing the line.


No, I am not. How often do I have to read people claiming that systemd
is a bad project because they don't like their upstream authors?



Honestly, I do not care about upstream at all, but I'm still concerned 
about systemd (as well as about upstart).
I had sufficient issues with upstart before - stopping to boot and not 
telling about its current state is from my point of view a show-stopper. 
And from my point of view it is irrelevant if there are underlying bugs. 
Important is that it helps the admin to figure out what went wrong and 
how this can be solved or worked-around. So upstart leaves a mostly 
blank screen without a console. What is systemd going to do if something 
fails? How does it help me if it crashes? How am I'm going to bring up a 
basic system then.


Thanks,
Bernd


--
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/51e97c73.8070...@aakef.fastmail.fm

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

[Scott Kitterman]

On Friday, July 19, 2013 06:35:48 PM John Paul Adrian Glaubitz wrote:
> On 07/19/2013 06:12 PM, Mathieu Parent wrote:
> > As the recommended way to install systemd is using init= and not
> > installing systemd-sysv, maybe the popcon "vote" count is the correct
> > metric?
> 
> Plus, systemd isn't pulled in by anything else which means when it's
> there it's there because it was actively installed. I don't think it
> magically lands onto a user's hard disk or someone installs it just
> in order to not use it actually.
> 
> > systemd is "used regulardly" on about 1200 popcon submiters, upstart
> > on about 600 (this is even less than 100 from 2013-07-04, but what
> > happened!).
> 
> Like several people pointed out before, the popcon entries for the
> Ubuntu upstart package pointed to Debian which at a particular time
> which resulted in wrong data being sent to popcon.
> 
> The data that we have now is the actual data and it shows upstart
> isn't very popular.

sysvinit148865  99.83%

Neither is systemd.  The numbers for either are small enough to be 
meaningless.

Scott K


-- 
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/1559462.SK62LhKSUs@scott-latitude-e6320

Re: SONAME migration: should the symbols file be continued?

[Russ Allbery]

Osamu Aoki  writes:

> As I understand, when a library generated from a foo source packge moves
> to a new SONAME, we change its library package name:
>   library file:libfoo.so.1 -> libfoo.so.2
>   library package: libfoo1 -> libfoo2

> But what should we do with the symbols file as the BEST PRACTICE?

> Should we start with:
>  $ mv debian/libfoo1.symbols debian/libfoo2.symbols  --- case #1

> or, should we start fresh with:
>  $ : >debian/libfoo2.symbols --- case #2

The short version is that it doesn't matter.  In your example, since there
were no versions of libfoo2 prior to 2.1, a dependency on libfoo2 (>= 2.1)
and a dependency on libfoo2 (>= 1.2) or (>= 1.1) are equivalent.

Generally I reset all the versions to be the earliest version of libfoo2,
but I can't think of any likely scenario in which it would ever make any
practical difference.

-- 
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/87wqomh1h2@windlord.stanford.edu

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

[Uoti Urpala]

Scott Kitterman wrote:
> On Friday, July 19, 2013 06:35:48 PM John Paul Adrian Glaubitz wrote:
> > On 07/19/2013 06:12 PM, Mathieu Parent wrote:
> > > systemd is "used regulardly" on about 1200 popcon submiters, upstart
> > > on about 600 (this is even less than 100 from 2013-07-04, but what
> > > happened!).
> > 
> > Like several people pointed out before, the popcon entries for the
> > Ubuntu upstart package pointed to Debian which at a particular time
> > which resulted in wrong data being sent to popcon.
> > 
> > The data that we have now is the actual data and it shows upstart
> > isn't very popular.
> 
> sysvinit  148865  99.83%
> 
> Neither is systemd.  The numbers for either are small enough to be 
> meaningless.

The 99.83% percentage is meaningless as sysvinit is typically installed
even on those machines that use systemd. When considering the absolute
numbers, you need to take into account that a large portion of popcon
reporters have old installations or aren't in any sense developers or
system administrators; those are not even potentially target audience
for manually installing a new init system.

For a different perspective, systemd has currently 1602 installs, and
gcc-4.8 (has been default GCC version for over a month) has 3809. gdb
has 27116 (a large portion of those likely old systems that are not
being actively updated); systemd is over 5% of that.

I think a better comparison would be to pick some packages that are
typically manually installed by developers or sysadmins, choose only the
systems which contain recently updated versions of those packages, and
then see what portion of those systems have systemd installed. But AFAIK
the public popcon data does not contain such information about package
relationships.



-- 
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/1374258109.21442.34.camel@glyph.nonexistent.invalid

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

[Scott Kitterman]

John Paul Adrian Glaubitz  wrote:
>On 07/19/2013 06:57 PM, Scott Kitterman wrote:
>> sysvinit 148865  99.83%
>
>The reason might be that systemd does not conflict with sysvinit :).

So are we playing word games now or trying to solve a problem? According to the 
popcon data, neither systemd nor upstart have enough deployment to be 
considered anything other than essentially zero.   

It really shouldn't be a factor at all (I don't have an opinion on the right 
answer, just that this is irrelevant).

Scott K


-- 
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/5498f324-b641-4a2c-9aee-7b2441766...@email.android.com

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

[John Paul Adrian Glaubitz]

On 07/19/2013 05:43 PM, Thomas Goirand wrote:

We try to have technical reasoning, which is (one of) the reason this
list exists. This has nothing to do with voting.


If we actually did, the choice would have already been made for systemd
long time ago. Don't make yourself any illusions. It has been explained
to you by many people before that OpenRC isn't fit for the purpose at
all and I really don't think upstart will meet the criteria either.


I thought we were making software which is to be useful for our
users in the end,...


That is the case, but not using popcon as a metric to our technical
decisions.


Well, technical reasons are obviously not counted in.


...but it turns out that according to your
line of arguments, Debian is primarily made to fuel the egos
of its developers.


Now you are crossing the line.


No, I am not. How often do I have to read people claiming that systemd
is a bad project because they don't like their upstream authors?

What else is it other than a hurt ego if some people can't cope with
the fact that both PulseAudio and systemd are actually useful software?

What's the point in delaying the decision over and over again?


1/ Don't put words in my mouth which I never used.
2/ Try to write more useful things. Doing personal attacks doesn't help.


Says the guy who posted this to back up his chain of arguments:

> http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/51e96caf.50...@physik.fu-berlin.de

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

[John Paul Adrian Glaubitz]

On 07/19/2013 07:47 PM, Scott Kitterman wrote:



John Paul Adrian Glaubitz  wrote:

On 07/19/2013 06:57 PM, Scott Kitterman wrote:

sysvinit148865  99.83%


The reason might be that systemd does not conflict with sysvinit :).


So are we playing word games now or trying to solve a problem? According to the 
popcon data, neither systemd nor upstart have enough deployment to be 
considered anything other than essentially zero.


I don't understand why anyone would assume that the popcon data in this
context is not accurate.

Again, sysvinit is essential, systemd is not and it doesn't have any
reverse dependencies. Thus, every counted systemd installation was
actually actively performed.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/51e98a07.5070...@physik.fu-berlin.de

Bug#717366: ITP: connman-ui -- A full-featured GTK based trayicon UI for ConnMan.

[Shawn Landden]

Package: wnpp
Severity: wishlist
Owner: Shawn Landden 

* Package name: connman-ui
  Version : 0
  Upstream Author : tomasz.burszt...@linux.intel.com
* URL : https://github.com/tbursztyka/connman-ui
* License : GPL-2+
  Programming Lang: C w/ glib/gtk-3
  Description : A full-featured GTK based trayicon UI for ConnMan.

Description: A full-featured GTK-based tray icon UI for ConnMan
 It targets all WM/DM users but Gnome3 ones*. It works on any Linux WM/DM 
 which provides a freedesktop compliant system tray. (kde, awesome, ...)
 .
 It exposes almost all features provided by ConnMan API (small features are 
 missing, see TODO for more informations). You can enable/disable a technology 
 (wired, wifi, cellular, bt, ...), connect/disconnect a service, configure a 
 service (IPv4, IPv6, DNS, Timeservers, etc...), share your current connection 
 (tethering) and so on. Everything is accessible through the mouse via the 
 trayicon, all with left and right click.


already packaged, just getting bug #


-- 
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/20130719193311.11487.14045.report...@chrome.churchofgit.com

Re: PulseAudio

[Philipp Kern]

On 2013-07-19 11:56, Helmut Grohne wrote:

In your reply to Wouter Verhelst you repeatedly argue how PulseAudio
saves time on your end. As has been pointed out this matches neither
Wouter's nor my experience. Clearly your claims are not universal.


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).


It appears that your use case is significantly different from Wouter's 
or

mine. For instance installing PA breaks an existing mpd (and PA devs
acknowledge that, fixing this is harder though due to the 
architecture).


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.)



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?



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.

Kind regards
Philipp Kern


--
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/753f2bdf0b4e419217cab0f6e3745...@hub.kern.lc

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

[Russ Allbery]

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!

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

[David Kalnischkies]

On Fri, Jul 19, 2013 at 8:48 PM, John Paul Adrian Glaubitz
 wrote:
> On 07/19/2013 07:47 PM, Scott Kitterman wrote:
>> John Paul Adrian Glaubitz  wrote:
>>>
>>> On 07/19/2013 06:57 PM, Scott Kitterman wrote:

 sysvinit148865  99.83%
>>>
>>>
>>> The reason might be that systemd does not conflict with sysvinit :).
>>
>>
>> So are we playing word games now or trying to solve a problem? According
>> to the popcon data, neither systemd nor upstart have enough deployment to be
>> considered anything other than essentially zero.
>
>
> I don't understand why anyone would assume that the popcon data in this
> context is not accurate.
>
> Again, sysvinit is essential, systemd is not and it doesn't have any
> reverse dependencies. Thus, every counted systemd installation was
> actually actively performed.

Oh, really? Because its the second time you claim that?

apt-cache rdepends systemd --important --no-conflicts --no-breaks -o
APT::Cache::ShowDependencyType=1


Granted, the rdependencies in stable/testing/unstable are all alternatives
in the second position which can be easily solved otherwise.
But we have also gnome-settings-daemon in experimental which depends without
an alternative on it. Now, if you look really close on the popcon data for
systemd you see that in March 2013 there is a plateau reached for systemd,
which "suddenly" at the end of the month is followed by the constant up –
which neatly alines with the upload of the previously mentioned
gnome-settings-daemon to experimental with a systemd dependency.
So, what do you think: More people wanting to testdrive GNOME 3.8 or systemd?


Oh, and while you have the graph open: Do you see the bump in the graph at
the end of May? Lets guess when the systemd survey was… so we can assume
that "a lot" people installed systemd to test it for the survey and it
worked so "great" that they not only not continued to use it, but have also
actively deinstalled it again – even though you don't have to, like for
upstart which doesn't seem to have obvious bumps (beside the ubuntu
 misreporting) so everyone installing it sticked with it…
I will leave the obvious conclusion as an exercise for the reader.


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


Best regards

David Kalnischkies

P.S.: Everyone who is now trying to disprove my "facts" has missed the point.


--
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/caaz6_fbmbdhcruh+m4k-6m3wvkg3pezm1ursg0jvbexd-jo...@mail.gmail.com

Re: PulseAudio

[Adam Borowski]

On Fri, Jul 19, 2013 at 10:49:07PM +0200, Vincent Bernat wrote:
>  ❦ 19 juillet 2013 11:56 CEST, Helmut Grohne  :
> 
> > So PA is not removing complexity, but adding to it. Surely a bit of
> > complexity is needed to solve sophisticated tasks, but it could indeed
> > do better. For instance pacmd list-* could get some verbosity switches
> > and hide some details in the default view. Scanning a pacmd list-sinks
> > output for the relevant info just takes too long (in addition to needing
> > to scroll the terminal).
> 
> 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),

I'm not aware of PulseAudio being capable of doing this, at least not in the
version in wheezy.  That "non-sense" of asoundrc you're speaking of is
required to have an usable multi-channel setup for N > 2.  PA will set all
weights to 1, which in a real-world room produces a worse result than a
two-speaker setup.  Unless your room is specifically built for a media
center, you can't reasonably place speakers in arbitrary places.

Not sure about current state, but at the very least a brief search doesn't
reveal any such functionality accessible to the user.  Which might mean
either that it doesn't exist or that the docs are worse than terrible.

A channel weight matrix is basic functionality for multi-channel.  ALSA
provides it from the start -- it's right in the rc you need to copy to
get any fancier setup.

And for non-fancier setups, ie, regular stereo, ALSA just works, and
PulseAudio, relying on ALSA, is nothing but an additional moving part
that can break.

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


-- 
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/20130719211222.ga4...@angband.pl

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

[heroxbd]

Dear Russ,

Russ Allbery  writes:

> 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!
>
> 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.

Your objective thinking is much appreciated!

Actually I was thinking of setting up test environments of systemd
upstart, OpenRC (and other candidates?) on Debian development boxes (or
some third party boxes which is open to DD), when Steve (excuse me for
not digging out your original words) mentioned in this thread that we
need a _modern_ init system which can handle race conditions in a
sophiscated setup (NFS, aufs, as / /usr etc.) reliably and expected
OpenRC would fail in this realm. Then we can prove our points in public
and open to peer review that "something is not suited for such and
such".

Is it realistic?

Yours,
Benda


-- 
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/8761w6dwrk@proton.in.awa.tohoku.ac.jp

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

[Thomas Goirand]

On 07/19/2013 05:25 PM, John Paul Adrian Glaubitz wrote:
> On 07/19/2013 10:15 AM, Thomas Goirand wrote:
>>> Popcon however speaks a completely different language:
>>
>> Even if that was truth (Russ showed it might not), I don't see how this
>> is a counter argument to what I wrote. Besides this, this is not a
>> voting system: if we were governed only by a majority of users, we would
>> all be running Windows.
> 
> Jeez, and I was honestly thinking all the time that Debian was a
> community project which has a democratic organization and larger
> decisions are primarily made with our users in mind.

We try to have technical reasoning, which is (one of) the reason this
list exists. This has nothing to do with voting.

> I thought we were making software which is to be useful for our
> users in the end,...

That is the case, but not using popcon as a metric to our technical
decisions.

> ...but it turns out that according to your
> line of arguments, Debian is primarily made to fuel the egos
> of its developers.

Now you are crossing the line.

1/ Don't put words in my mouth which I never used.
2/ Try to write more useful things. Doing personal attacks doesn't help.

> Guess, I am in the wrong project then.

Definitively, if you continue to express yourself this way, you are.

Thomas


-- 
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/51e95e95.2030...@debian.org

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

[John Paul Adrian Glaubitz]

On 07/19/2013 06:12 PM, Mathieu Parent wrote:

As the recommended way to install systemd is using init= and not
installing systemd-sysv, maybe the popcon "vote" count is the correct
metric?


Plus, systemd isn't pulled in by anything else which means when it's
there it's there because it was actively installed. I don't think it
magically lands onto a user's hard disk or someone installs it just
in order to not use it actually.


systemd is "used regulardly" on about 1200 popcon submiters, upstart
on about 600 (this is even less than 100 from 2013-07-04, but what
happened!).


Like several people pointed out before, the popcon entries for the
Ubuntu upstart package pointed to Debian which at a particular time
which resulted in wrong data being sent to popcon.

The data that we have now is the actual data and it shows upstart
isn't very popular.

Cheers,

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/51e96ae4.5050...@physik.fu-berlin.de

modern features and OpenRC (was: Re: Survey answers part 3: systemd is not portable and what this means for our ports)

[heroxbd]

Dear all,

John Paul Adrian Glaubitz  writes:

> Says the guy who posted this to back up his chain of arguments:
>
>> http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems

Excuse me for hijacking this reply.

On the wiki page.

I revised it into present form last year, after a *shadow* survey (using
each to see its interface and features, by performing service
add/remove/start/stop) of various init systems, including sysvinit +
sysv-rc, Upstart, systemd, OpenRC, SMF and launchd. It is biased, not
mature and started from the biased
http://0pointer.de/blog/projects/why.html to counter-argue Lennart's
points.

For the '??' in Device-based Activation, sorry, at that time I didn't
know what it was so just copy-n-pasted.

Because of the bias, It was soon moved into "Talk" for archieving
purpose. For a objective version have a look at the main page,
http://wiki.gentoo.org/wiki/Comparison_of_init_systems.


For the features that people care most in OpenRC (openrc herd, correct
me if I am wrong):

a. process supervising:

   no.

   But OpenRC can be integrated with runit (unofficial yet), my personal
   effort is targeting to use s6[1] together with OpenRC.

b. event-driven, mostly hotplug events

   OpenRC provides a HOTPLUG virtual runlevel. to keep features minimal,
   it relies on udev to trigger it. An example of iPhone hotplugging[2].

   I forgot if inotify could fit into this. If you need more info I can
   dig it out.

c. socket activation

   no.

   At present no solution yet.

Cheers,
Benda

1. http://www.skarnet.org/software/s6/why.html
2. http://wiki.gentoo.org/wiki/Iphone_USB_Tethering#udev_trigger


-- 
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/87ob9ycgml.fsf...@proton.in.awa.tohoku.ac.jp

SONAME migration: should the symbols file be continued?

[Osamu Aoki]

Hi,

As I understand, when a library generated from a foo source packge moves
to a new SONAME, we change its library package name:
  library file:libfoo.so.1 -> libfoo.so.2
  library package: libfoo1 -> libfoo2

But what should we do with the symbols file as the BEST PRACTICE?

Should we start with:
 $ mv debian/libfoo1.symbols debian/libfoo2.symbols  --- case #1

or, should we start fresh with:
 $ : >debian/libfoo2.symbols --- case #2

After doing the basics (like removing Debian revision -1), we may end up
like:

For case #1:
libfoo.so.2 libfoo2 #MINVER#
  foo_get_name@Base 1.1
  foo_get_longname@Base 1.2
  foo_get_type@Base 1.1
  foo_get_longtype@Base 2.1
  foo_get_symbol@Base 1.1
  foo_get_rank@Base 1.1
  foo_new@Base 1.1
  ...

For case #2:
libfoo.so.2 libfoo2 #MINVER#
  foo_get_name@Base 2.1
  foo_get_longname@Base 2.1
  foo_get_type@Base 2.1
  foo_get_longtype@Base 2.1
  foo_get_symbol@Base 2.1
  foo_get_rank@Base 2.1
  foo_new@Base 2.1
  ...

I understand that either case should work fine for the next upstream
release 2.2.  But which is better and why is it?

Case #1 keeps the history (but that part of history is not really used).

Case #2 is cleaner.  But missing data.

I am doing case #1 now but wondering why by myself...

Osamu


-- 
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/20130719174329.GA2009@goofy.localdomain

Re: PulseAudio

[http]

Having read both sets of docs (and not merely the two pages named), I have to 
assert that the question is not a troll.

The end user docs explain to end users how to use PA when everything's going 
according to plan, and cover some common glitches.

I have gained no additional understanding of the concepts behind PA, though I suppose that if I went through those pages again I 
might be able to pick out some specific terminology to search elsewhere for.


PeteR


On 17/07/13 01:24 AM, John Paul Adrian Glaubitz wrote:

On 07/17/2013 09:26 AM, Marc Haber wrote:

 Where are the end-user docs that explain the concept?


Was that a troll question? Just use your favorite
search engine.

  >  http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/
  >  http://freedesktop.org/software/pulseaudio/doxygen/

PA also has excellent support on their IRC channels. I have been
able to solve any problem I had with it so far and in all
cases it turned out to be a user error.

Adrian




--
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/51e952da.4080...@shaw.ca

Re: Berkeley DB 6.0 license change to AGPLv3

[brian m. carlson]

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.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: PulseAudio

[Vincent Bernat]

 ❦ 19 juillet 2013 11:56 CEST, Helmut Grohne  :

> So PA is not removing complexity, but adding to it. Surely a bit of
> complexity is needed to solve sophisticated tasks, but it could indeed
> do better. For instance pacmd list-* could get some verbosity switches
> and hide some details in the default view. Scanning a pacmd list-sinks
> output for the relevant info just takes too long (in addition to needing
> to scroll the terminal).

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.

Nobody cares about pacmd list-* being too verbose. Is it a serious
argument about maturity?
-- 
panic("Detected a card I can't drive - whoops\n");
2.2.16 /usr/src/linux/drivers/net/daynaport.c


pgpNVaW4xg1N1.pgp
Description: PGP signature

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

[Arto Jantunen]

Scott Kitterman  writes:

> On Friday, July 19, 2013 06:35:48 PM John Paul Adrian Glaubitz wrote:
>> The data that we have now is the actual data and it shows upstart
>> isn't very popular.
>
> sysvinit  148865  99.83%
>
> Neither is systemd.  The numbers for either are small enough to be 
> meaningless.

However no popcon number is quite as meaningless as the number for a
package that is Essential: yes. I'd guess most systems that run either
upstart or systemd still have sysvinit installed (mine do, for another
useless example).

-- 
Arto Jantunen


-- 
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/87y592mpix@iki.fi

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

[Adam Borowski]

On Fri, Jul 19, 2013 at 10:43:33PM +0200, David Kalnischkies wrote:
> But we have also gnome-settings-daemon in experimental which depends without
> an alternative on it. Now, if you look really close on the popcon data for
> systemd you see that in March 2013 there is a plateau reached for systemd,
> which "suddenly" at the end of the month is followed by the constant up –
> which neatly alines with the upload of the previously mentioned
> gnome-settings-daemon to experimental with a systemd dependency.
> So, what do you think: More people wanting to testdrive GNOME 3.8 or systemd?

Ha ha...
So why do we even discuss popcon data here, with it being messed with so
badly?  Instead, there should be a repeat of the network-manager brouchacha.

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


-- 
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/20130719233953.ga7...@angband.pl

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

[Vincent Cheng]

On Fri, Jul 19, 2013 at 9:35 AM, John Paul Adrian Glaubitz
 wrote:
> On 07/19/2013 06:12 PM, Mathieu Parent wrote:
>>
>> As the recommended way to install systemd is using init= and not
>> installing systemd-sysv, maybe the popcon "vote" count is the correct
>> metric?
>
>
> Plus, systemd isn't pulled in by anything else which means when it's
> there it's there because it was actively installed. I don't think it
> magically lands onto a user's hard disk or someone installs it just
> in order to not use it actually.

On the contrary, in experimental, gnome-shell depends on
gnome-settings-daemon, which in turn depends on systemd. I wouldn't be
surprised if this is one of the reasons sid still has version 3.4 of
the shell, rather than the latest upstream version (3.8).

If/when gnome-shell 3.8 hits unstable and systemd gets forced on end
users as well...I dare say that the general outcry here on
debian-devel would make the past network-manager related threads look
tame in comparison. I offer my deepest condolences to the gnome
maintainers in advance (I doubt that they're looking forward to
dealing with all this).

Regards,
Vincent


-- 
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/CACZd_tC4acLy=Ant-0KsHCz-g0UsW5vO8Qx2O6=tpmj6nfk...@mail.gmail.com

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

[Charles Plessy]

Le Fri, Jul 19, 2013 at 07:14:31PM -0700, Vincent Cheng a écrit :
> 
> If/when gnome-shell 3.8 hits unstable and systemd gets forced on end
> users as well...I dare say that the general outcry here on
> debian-devel would make the past network-manager related threads look
> tame in comparison. I offer my deepest condolences to the gnome
> maintainers in advance (I doubt that they're looking forward to
> dealing with all this).

What do you offer in case you are wrong and the people who are upgrading to
GNOME 3.8 do not mind having systemd installed on their computer ?  Bets are
funnier if there is a concrete consequence with both outcomes.  How about
triaging 100 bugs of your choice for instance ?

The problem is that, if it is too cheap to predict bad things on that list and
be wrong, then the proportion of relevant messages on this list will
decrease...

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20130720034322.gd23...@falafel.plessy.net

Bug#717382: ITP: python-lesscpy -- LessCss Compiler for Python 3

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-lesscpy
  Version : 0.9h
  Upstream Author : Johann T Mariusson
* URL : https://pypi.python.org/pypi/lesscpy
* License : MIT
  Programming Lang: Python
  Description : LessCss Compiler for Python 3

 Lesscpy is a compiler written in Python 3 for the lesscss language. It is very
 useful if node.js can't be installed in the environment. Not all features of
 lesscss are supported (yet). Some features wil probably never be supported
 (JavaScript evaluation).
 .
 This program uses PLY (Python Lex-Yacc) to tokenize/parse the input and is
 considerably slower than the nodejs compiler.


-- 
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/20130720040808.30288.88482.report...@buzig.gplhost.com

Bug#717384: ITP: python-affinity -- control process CPU affinity

[Apollon Oikonomopoulos]

Package: wnpp
Severity: wishlist
Owner: Apollon Oikonomopoulos 

* Package name: python-affinity
  Version : 0.1.0
  Upstream Author : Enfold Systems, LLC 
* URL : https://pypi.python.org/pypi/affinity
* License : MIT (see below)
  Programming Lang: C, Python
  Description : control process CPU affinity

affinity provides a simple Python module for setting the processor affinity,
i.e. which processors a process is allowed to run on, by wrapping the specific
underlying function calls of each platform. It works on Linux 2.6/3.x and
Windows. Under Linux it provides a Python extension that uses glibc's
sched_getaffinity(2) and sched_setaffinity(2) functions.

Note that while the current version of affinity at PyPi bears no license, I
contacted Enfold Systems and they kindly offered to relicense the code under
the MIT license if I moved it to github.


-- 
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/20130720053520.GA550@marvin

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

[Thomas Goirand]

On 07/20/2013 12:43 AM, John Paul Adrian Glaubitz wrote:
> On 07/19/2013 05:43 PM, Thomas Goirand wrote:
>> We try to have technical reasoning, which is (one of) the reason this
>> list exists. This has nothing to do with voting.
> 
> If we actually did, the choice would have already been made for systemd
> long time ago.

For many reasons, the choice isn't that easy.

> It has been explained
> to you by many people before that OpenRC isn't fit for the purpose at
> all and I really don't think upstart will meet the criteria either.

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. And this is probably what we should focus on:
make it so that at least one of the projects becomes a perfect fit.

The main issue there is with Systemd, is that it doesn't seem like we
may have a chance to make it evolve the way we need (for example, make
it compatible with non-Linux ports). I believe it is possible to enhance
OpenRC, which is why I worked on it. Maybe it can be possible to do that
with Upstart as well (though I never heard about anyone working on a
non-Linux port of Upstart yet).

>>> ...but it turns out that according to your
>>> line of arguments, Debian is primarily made to fuel the egos
>>> of its developers.
>>
>> Now you are crossing the line.
> 
> No, I am not.

When talking about egos, you are.

> How often do I have to read people claiming that systemd
> is a bad project because they don't like their upstream authors?

Again, this was *not* my point.

>> 1/ Don't put words in my mouth which I never used.
>> 2/ Try to write more useful things. Doing personal attacks doesn't help.
> 
> Says the guy who posted this to back up his chain of arguments:
> 
>> http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems

I posted this to show OpenRC does more than just enhancing the init.d
scripts, which Steeve claimed. You are the one who took on the "hostile
upstream" part of the page, when this wasn't part of my argumentation at
all. Also, you can't make me responsible for a page which I didn't
write, or for the fact that many people think this way about Systemd
upstream. So I stand by point point 1 and 2 above.

This goes nowhere again...

Thomas


-- 
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/51ea22d5.20...@debian.org

Re: PulseAudio

[Vincent Bernat]

 ❦ 19 juillet 2013 23:12 CEST, Adam Borowski  :

>> > So PA is not removing complexity, but adding to it. Surely a bit of
>> > complexity is needed to solve sophisticated tasks, but it could indeed
>> > do better. For instance pacmd list-* could get some verbosity switches
>> > and hide some details in the default view. Scanning a pacmd list-sinks
>> > output for the relevant info just takes too long (in addition to needing
>> > to scroll the terminal).
>> 
>> 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),
>
> I'm not aware of PulseAudio being capable of doing this, at least not in the
> version in wheezy.  That "non-sense" of asoundrc you're speaking of is
> required to have an usable multi-channel setup for N > 2.  PA will set all
> weights to 1, which in a real-world room produces a worse result than a
> two-speaker setup.  Unless your room is specifically built for a media
> center, you can't reasonably place speakers in arbitrary places.
>
> Not sure about current state, but at the very least a brief search doesn't
> reveal any such functionality accessible to the user.  Which might mean
> either that it doesn't exist or that the docs are worse than terrible.
>
> A channel weight matrix is basic functionality for multi-channel.  ALSA
> provides it from the start -- it's right in the rc you need to copy to
> get any fancier setup.

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.

> And for non-fancier setups, ie, regular stereo, ALSA just works, and
> PulseAudio, relying on ALSA, is nothing but an additional moving part
> that can break.

Maybe you missed some features like mixing in almost all situations
(while Alsa is doing it out of the box only for analog output), 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.

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.
-- 
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)


pgpWL2nrV0TuG.pgp
Description: PGP signature

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

[Thomas Goirand]

On 07/20/2013 07:39 AM, Adam Borowski wrote:
> So why do we even discuss popcon data here

Because John Paul Adrian Glaubitz started writing about it, and defended
strongly that it is be data we should consider...

He is currently alone defending that opinion.

Thomas


-- 
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/51ea2e06.8000...@debian.org

Re: PulseAudio

[Andrei POPESCU]

On Sb, 20 iul 13, 08:24:26, Vincent Bernat wrote:
> 
> 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".

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