Re: Mass bug filing: use and misuse of dbus-launch (dbus-x11)

[Simon McVittie]

On Sun, 04 Sep 2016 at 19:24:09 +0100, Jonathan de Boyne Pollard wrote:
> You think that a good "replacement directory" is /run/user/$EUID .  Alright.
> Then when your program is told address=unix:runtime=yes and there's no
> XDG_RUNTIME_DIR, please make it fall back to using the directory that you
> think is the advisable directory to use.

No, I think that /run/user/$EUID is a good choice for the OS infrastructure
(systemd-logind or equivalent) to make. D-Bus implementations are merely
one specific user of XDG_RUNTIME_DIR; it is not their place to
set a specific interpretation of how to fall back when this variable
is unset, and it is not their place to define semantics for /run/user,
a directory that you will notice does not mention dbus or D-Bus anywhere
in its name.

D-Bus implementations should use the XDG per-uid runtime directory as a
rendezvous point *if* that directory is going to have all the required
properties (specified lifetime guarantee, cleaned up automatically
on logout, etc.). OS infrastructure can signal that it provides those
properties for a directory, and indicate what the right directory is,
by arranging for that environment variable to be in user processes'
environments. If you want to use interoperable protocols that rely on
XDG_RUNTIME_DIR, set an XDG_RUNTIME_DIR, otherwise your protocol is not
going to be interoperable.

You are writing to the mailing list for the development of Debian, in a
thread about the src:dbus source package and how the rest of Debian should
interact with it. The dbus binary package deliberately does not *require*
the user-bus model, for the reasons I outlined in the mass bug filing;
the dbus-user-session source package does require the user-bus model,
but it also depends on packages that ensure that $XDG_RUNTIME_DIR is set.
Everything else is not relevant to Debian, until/unless it is in Debian.

S

[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=d...@packages.debian.org;tag=dbus-launch-unless-dsba

Re: Mass bug filing: use and misuse of dbus-launch (dbus-x11)

[Simon McVittie]

On Sun, 04 Sep 2016 at 17:30:43 +0100, Jonathan de Boyne Pollard wrote:
> Simon McVittie:
> > To the best of my knowledge, the listenable address "unix:runtime=yes"
> > (as in "dbus-daemon --address=unix:runtime=yes") does work on generic
> > Unix, and should interoperate fine with the XDG_RUNTIME_DIR/bus fallback
> > used by clients with no DBUS_SESSION_BUS_ADDRESS. It is compiled and
> > tested whenever DBUS_UNIX is defined (i.e. everything except Windows),
> > and I haven't seen bug reports about that test failing.
> > 
> There you go, then.  New knowledge.  (-:  It doesn't work with your program
> as ported to FreeBSD/TrueOS/OpenBSD.

The D-Bus bug tracking system is over here:

Please follow the traditional bug-reporting template (steps to reproduce,
expected result, actual result). Tested patches are also welcome.

(As the commit message[1] says, unix:runtime=yes is intended to fail
if XDG_RUNTIME_DIR is unset; that's not considered to be a bug.)

If you want patches applied to dbus (the reference implementation of
D-Bus), please submit those patches for review in its bug tracking
system, in a bug report that describes the bug or missing feature that
those patches address. Links to your personal website, written in a form
that ensures that typical web browsers will reject the SSL certificate,
in a thread on the Debian mailing list for the development of Debian,
are not a recommended form of upstream patch submission - doubly so
for issues that specifically involve OSs that are not Debian and so
are off-topic for this mailing list.

Linking to other people's implementations of sd_listen_fds() is also
not a useful form of upstream patch submission. I am well aware that
it is possible to implement an API equivalent to sd_listen_fds() on
non-Linux OSs. I do not run those other OSs, and I am not going to test
dbus on those other OSs, so a link that effectively says "you could
do it something like this" is not particularly helpful: the proposed
change needs to be sufficiently specific that someone who *does* run
the relevant OS can easily test it. Until that testing is done, the
change won't be merged.

If you are more interested in those other OSs than I am, and want to
contribute tested improvements for them, please do so. If you want to
encourage others to contribute those improvements, or pay someone to do
so, that's also fine. However, debian-devel is not an appropriate
venue for any of those activities.

[1] 
https://cgit.freedesktop.org/dbus/dbus/commit/?h=dbus-1.10&id=e3f117e7610b0e0a91dfe5bff7bf2e217c129a86

> That's not the right way to look at it.  You yourself have just said several
> times that this is stuff that is supposed to be on "supported Unix
> platforms".  This isn't giving new things to anyone.  This is making
> existing things, that you yourself think are existing, work.

As far as I'm aware, "the old way" - involving dbus-launch - works the
same on BSD as it does on Linux, and works the same on BSD in dbus 1.10
as it did in dbus 1.0.

The unix:runtime=yes listenable address is a new feature in 1.10.0
(actually 1.9.x, but that was an unstable development branch that led
to 1.10.x). As far as I'm aware, it works as intended on all Unix
platforms. Regardless of whether that is true or not, it does not
affect whether the previously-supported listenable addresses work on
those platforms.

unix:runtime=yes is not intended to work in the absence of an
XDG_RUNTIME_DIR; if your platform doesn't routinely set that variable
for user processes, and you have not taken any special steps to set it
in the dbus-daemon's environment, then attempting to listen on
unix:runtime=yes will fail. This is equally true on Linux and non-Linux.

> You're pushing your new way of per-user Desktop Bus brokers at the world.

This is the debian-devel mailing list, for the development of Debian.
I am one of Debian's dbus maintainers, and I would like Debian to default
to the user-bus model, at least for new installations on the Linux kernel.
Whether other operating systems do the same is up to the people with the
equivalent role in those other operating systems.

I don't find Debian's non-Linux ports particularly interesting, and
they are certainly not a majority configuration or one that I would
recommend to inexperienced users, so I don't consider changing the
default on those ports to be equally important. Some people consider
those ports to be important, and those people are invited to provide
tested patches. That bug tracker link again:


Non-Debian operating systems are not relevant to this mailing list, and
I regret getting drawn in to your discussion of them. Other operating
systems' dbus maintainers should make their own decision whether
their particular OS has a login-session bus or a user bus, and
contribute any patches that might be needed to make their chosen
int

Re: Introducing default-mysql-* metapackages

[Otto Kekäläinen]

Hello!

2016-09-05 9:57 GMT+03:00 Ondřej Surý :
> could you elaborate a bit more why you are forcing all Build-RDeps to
> change B-D to default-libmysqlclient-dev instead of just changing the
> semantics of libmysqlclient-dev?
>
> I understand the default-mysql-client and default-mysql-server, but I
> don't understand the change from libmysqlclient-dev to
> default-libmysqlclient-dev.
>
> We have a couple of similar cases that doesn't require that much work
> (f.e. libjpeg-dev) and renaming the original libmysqlclient-dev to
> libmysqlclient-oracle-dev and adding Provides: libmysqlclient-dev to
> libmariadbclient-dev would achieve the same thing and require a
> substantially less work on the other people side.

Thanks for the suggestion. This method was not discussed earlier when
the pkg-mysql-maint team designed the new mysql-defaults metapackages.
I would be fine by doing what you suggest. What does Robie and others
who are more vested in maintaining Oracle packages think about this?

- Otto

Bug#836765: ITP: chartkick.js -- create beautiful JavaScript charts with minimal code

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: "ChangZhuo Chen (陳昌倬)" 

* Package name: chartkick.js
  Version : 2.0.1
  Upstream Author : Copyright (c) 2013 Andrew Kane
* URL : https://github.com/ankane/chartkick.js
* License : Expat
  Programming Lang: JavaScript
  Description : create beautiful JavaScript charts with minimal code

 Create beautiful JavaScript charts with minimal code. Supports
 Chart.js, Google Charts, and Highcharts. Also available for React,
 Ruby, Python, and Elixir.

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D
  BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Re: Mass bug filing: use and misuse of dbus-launch (dbus-x11)

[Steve Litt]

On Sun, 4 Sep 2016 17:30:43 +0100
Jonathan de Boyne Pollard 
wrote:

> Simon McVittie:
> 
> > This can already work. If you put XDG_RUNTIME_DIR in user programs' 
> > environment, and arrange for your favourite service manager to make
> > a dbus-daemon (or something else that speaks the same protocol)
> > listen on $XDG_RUNTIME_DIR/bus before any user process would try to
> > connect to it, then modern versions of at least libdbus, GDBus and
> > sd-bus will connect to it by default with no additional effort on
> > your part. This client-side code path does not depend on systemd,
> > does not depend on libsystemd (except obviously sd-bus which is
> > part of libsystemd), and is compiled in for all supported Unix
> > platforms. 
> That's the problem.  No the whole unix:runtime=yes mechanism is not.
> As I said, this is something that you and Joe Marcus Clarke and
> whomever else have to sort out with each other.  I'm unfortunately
> stuck in the middle, here.  Please do whatever it is that you need to
> do with each other to make your program understand address=systemd:
> and address=unix:runtime=yes on FreeBSD/TrueOS/OpenBSD.  It does not
> do so.
> 
> Simon McVittie:
> 
> > Meanwhile, if you want the relevant integration files (your
> > favourite service manager's equivalent of systemd units) to be part
> > of dbus (the reference implementation of D-Bus), please propose
> > tested patches; if they follow the "user session" model[1], they
> > could eventually go in dbus-user-session.deb, with its dependencies
> > changed from the current systemd-sysv to "systemd-sysv |
> > your-service-manager". 
> Kudos for being the first project to offer integration, ever. (-:

Danger Will Robinson.

"Integration" in cases of systemd and its venus fly trap, dbus, is more
Embrace, Extend, Extinguish than integration. The Rube Goldbergesque
system described in the preceding quoted context exquisitely highlights
that fact.

Do not cooperate with systemd. The systemd proponents don't cooperate
with anyone else.


> Yes, down the road it would be marvellous if people included service
> bundles in their own projects.  

What would be marvellous is if people would simply ignore systemd,
opting for a real init system (not a conglomeration of welded krap
trying to supercede what we've had for years).

> Yes, I'd like to see the day when the
> number of service bundles in the nosh-bundles package actually starts
> going down, because people are taking on shipping their own service
> bundles for their own services, instead of going up.  So yes,
> eventually you'll be taken up on that offer I hope. But one step at a
> time.

Ooo, "service bundles." My runit run scripts average about 6 lines
long. Any fool can make them. Behold the power of a real init: An init
that knows it's an init, and does only what inits are designed to do. I
highlight runit out of familiarity, but my use of s6 and Epoch indicate
that both are equally as simple, when defining service startup, runit.

> 
> Simon McVittie:
> 
> >> As for what I would like, I'd like you (where that's plural, 
> >> including Joe Marcus Clarke or whomever else) to please make
> >> either address=systemd: or address=unix:runtime=yes work in your
> >> program on FreeBSD/PC-BSD/OpenBSD.
> >>  
> > To the best of my knowledge, the listenable address
> > "unix:runtime=yes" (as in "dbus-daemon --address=unix:runtime=yes")
> > does work on generic Unix, and should interoperate fine with the
> > XDG_RUNTIME_DIR/bus fallback used by clients with no
> > DBUS_SESSION_BUS_ADDRESS. It is compiled and tested whenever
> > DBUS_UNIX is defined (i.e. everything except Windows), and I
> > haven't seen bug reports about that test failing. 


> There you go, then.  New knowledge.  (-:  It doesn't work with your 
> program as ported to FreeBSD/TrueOS/OpenBSD.  Joe Marcus Clarke is
> the porter for FreeBSD, according to the port information, and
> Antoine Jacoutot the porter for OpenBSD.  

To the *BSD communities: Please do not let the systemd camel get his
nose in your tent. Systemd is a repudiation of everything Unix, created
by a guy who makes no bones of his hate for Posix.


> This is why I am saying
> that it's something that you (plural, remember) need to sort out
> amongst yourselves.  We users stuck in the middle cannot use
> address=systemd: and address=unix:runtime=yes with your program on
> these systems.  As I said, it's something that I had to fix in
> November 2015, to stop trying to use address=systemd: on
> FreeBSD/TrueOS because it turned out that it didn't actually work.  I
> thought that address=unix:runtime=yes might, but that did not either.
> 
[snip]
> 
> Simon McVittie:
> 
> > To be brutally honest, there is a fairly low limit to how much
> > benefit I can create by giving new things to PC-BSD users, [...]
> >  
> That's not the right way to look at it.  

This is precisely the right way to look at it, when it pertains to
systemd.

> You yourself have just said 
> several tim

Re: Mass bug filing: use and misuse of dbus-launch (dbus-x11)

[Andrey Rahmatullin]

At first, I thought it's a random set of words. Then I noticed that they
follow language rules and thought that it's a nicely crafted Markov chain
text designed to look like random babbling of a typical systemd-hater. It
looks like I was wrong after all.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: [debian-mysql] Introducing default-mysql-* metapackages

[Robie Basak]

Hi Ondřej,

On Mon, Sep 05, 2016 at 08:57:57AM +0200, Ondřej Surý wrote:
> could you elaborate a bit more why you are forcing all Build-RDeps to
> change B-D to default-libmysqlclient-dev instead of just changing the
> semantics of libmysqlclient-dev?

MySQL ships the soname libmysqlclient.so.20 (in experimental currently,
18 in unstable and testing) and continues to be maintained in Debian. So
the expected package names to get libmysqlclient.so.20 are
libmysqlclient20 and libmysqlclient-dev, according to Debian policy
sections 8.1 and 8.4. libmysqlclient-dev should result in a link against
MySQL's libmysqlclient.so.

MariaDB upstream do also ship libmysqlclient.so.18 (forked from an older
MySQL), but clearly it would be insane to ship this in Debian in the
same way because of the soname conflict. I understand why MariaDB
upstream have done it this way, but their expected use case is that a
user would pick MariaDB and drop everything MySQL. Since we're not doing
that in Debian, this cannot work. So instaed, it makes sense for us to
ship separate sonames, so we are patching MariaDB to build
libmariadbclient.so.18 instead.

Having a package build depend on libmysqlclient-dev, link with
"-lmysqlclient" and then up with with a binary dependency on
libmariadbclient.so.18 would be wrong, IMHO.

That's why I want to leave libmysqlclient-dev alone, and why we're
moving this necessary insanity to libmariadbclient-dev-compat instead.
Then it's clear.

We then have the need for a "default" package, libmysqlclient-dev is
already taken, and default-libmysqlclient-dev follows the same pattern
as the others. It is perhaps a little confusing because as long as the
default is MariaDB, packages using it will end up with a binary
dependency on libmariadbclient.so.18 from libmariadbclient-dev instead,
but I think that all the other options we've considered are worse.

At least this way the insanity is limited to the -compat package, and by
extension the default- package, but everything else will appear as
normal.

Robie

Re: GPL debate on kernel mailing list

[Theodore Ts'o]

On Tue, Aug 30, 2016 at 12:09:35PM +0200, Zlatan Todorić wrote:
> For years and years companies are using community hard work and creating
> their "great" products without turning back
>
> People all over the world created Free software for decades and just
> small number of those people got employed to work on Free software for
> living...

This is one of these myths that gets repeated over and over again, but
it's a bit of a distortion of reality.  If you look at the actual data
of who actually contributes to the Linux kernel[1], engineers employed by
companies contribute over 80% of the changes.  Consultants are 2.6%,
and hobbyists are somewhere between 7.7% and 14.5% (6.8% of the
commits are authored by people where it's not clear whether their work
is supported by a company or not).

[1] Linux Kernel Development: How Fast It is Going, Who is Doing It,
What They are Doing, and Who is Sponsoring It, 2016.   http://goo.gl/QKbJ5Q

I suspect if you take a look at how many of the commits that go into
gcc or LLVM, you would see a similar dynamic.


So the debate is really about whether or not the companies versus "the
community" is really an accurate, or for that matter, healthy, way of
looking at things.

It's far more accurate to say that the companies are *part* of the
community, and we need to encourage all members of the community,
whether they are individuals or corporations, to live up to the
community norms.  (And some cases, that means teaching a student at a
two-year college in Toronto that taking credit for other people's work
and sending patches that haven't been tested, and in some cases, don't
even compile, to users who are asking for help on a bug tracker isn't
cool.  And in other cases, it might be convincing companies and
individuals who ship VM images that they need to include source.)

> I don't know is it a time for GPLv4 which will explain to all
> corporations that THIS LICENSE mean you must participate with
> community...  ...and not engage that only way to achieve is by lies,
> manipulation, abuse, FUD, secrets.

In my opinion, this kind of Manichean attitude is not an accurate
description of reality, and it's really not helpful.

- Ted

Bug#836800: ITP: espeak-ng -- Multi-lingual software speech synthesizer

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 

* Package name: espeak-ng
  Version : git snapshot
  Upstream Author : Reece H. Dunn 
* URL : https://github.com/espeak-ng/espeak-ng
* License : GPL
  Programming Lang: C++
  Description : Multi-lingual software speech synthesizer

eSpeak NG is a fork of espeak, which is currently unmaintained.  It
is API and ABI compatible with espeak, thus making it a drop-in
replacement, while providing fixes in source code and voices.

Re: [debian-mysql] Introducing default-mysql-* metapackages

[Clint Byrum]

Excerpts from Robie Basak's message of 2016-09-05 18:59:39 +0100:
> Hi Ondřej,
> 
> On Mon, Sep 05, 2016 at 08:57:57AM +0200, Ondřej Surý wrote:
> > could you elaborate a bit more why you are forcing all Build-RDeps to
> > change B-D to default-libmysqlclient-dev instead of just changing the
> > semantics of libmysqlclient-dev?
> 
> MySQL ships the soname libmysqlclient.so.20 (in experimental currently,
> 18 in unstable and testing) and continues to be maintained in Debian. So
> the expected package names to get libmysqlclient.so.20 are
> libmysqlclient20 and libmysqlclient-dev, according to Debian policy
> sections 8.1 and 8.4. libmysqlclient-dev should result in a link against
> MySQL's libmysqlclient.so.
> 
> MariaDB upstream do also ship libmysqlclient.so.18 (forked from an older
> MySQL), but clearly it would be insane to ship this in Debian in the
> same way because of the soname conflict. I understand why MariaDB
> upstream have done it this way, but their expected use case is that a
> user would pick MariaDB and drop everything MySQL. Since we're not doing
> that in Debian, this cannot work. So instaed, it makes sense for us to
> ship separate sonames, so we are patching MariaDB to build
> libmariadbclient.so.18 instead.
> 

I don't think we should gloss over this activity by MariaDB.  They're
completely aware of the fact that they're breaking with all norms by
shipping a _forked_ API with the same soname as an established one.

There's simply no reason for this to be entertained as anything other
than aggressive anti-mysql activity. They could easily ship the original
libmysqlclient API in a wrapper, and then build any new functionality
into a mariadbclient so that users who link to the new one know they
are dependent on MariaDB's new functionality.

IMO, until they stop doing this, I don't think Debian should help them
subvert MySQL by shipping this API under mysqlclient's soname.

Re: GPL debate on kernel mailing list

[Zlatan Todorić]

On 09/05/2016 11:10 PM, Theodore Ts'o wrote:
> On Tue, Aug 30, 2016 at 12:09:35PM +0200, Zlatan Todorić wrote:
>> For years and years companies are using community hard work and creating
>> their "great" products without turning back
>>
>> People all over the world created Free software for decades and just
>> small number of those people got employed to work on Free software for
>> living...
> 
> This is one of these myths that gets repeated over and over again, but
> it's a bit of a distortion of reality.  If you look at the actual data
> of who actually contributes to the Linux kernel[1], engineers employed by
> companies contribute over 80% of the changes.  Consultants are 2.6%,
> and hobbyists are somewhere between 7.7% and 14.5% (6.8% of the
> commits are authored by people where it's not clear whether their work
> is supported by a company or not).

You're just fueling myths you stand behind for some reason. You take
data from one year (did you even verify it on your own?) and you don't
look at historical development of situation. While I can pull out data
that will easily throw out of door your point I will just go a bit
through development. Companies didn't care for Linux and only wanted
profit from it. GNU and Linux where spearheaded by volunteers, by fun
and most of companies didn't look at it. They started looking when
volunteers made it very competitive, they started employing some of them
to continue such work but mostly not. Most company contributions happen
because someone who came from Free software background pushed this
inside company and yet to date we don't have a major Free software
company (RedHat could be called a major open source company).

Microsoft had attitude of calling Linux "cancer and communism". Do you
think they nowdays contribute because to open source because they really
like it. No, they were loosing edge, and most contributions from
companies to open source happen because they are loosing edge. And even
today they show a lot of hostile approach when they can - by suddenly
not releasing documentation, by introducing non-free firmware. Creating
enterprise editions with nonfree code etc.

There must be awareness that even if they today contribute most of code
(it would be interesting to pull out entire data or data for few first
years where probably volunteers made 80%-90% and then just throw such
statistic at you and talk about distortion of reality) it is not because
they are good community citizens that understand the philosophy. And I
am fairly sure that most of their dormant projects where only good
because community gave a lot of love and care after it was killed
mainstream. So even if they produce most of the code today, they are
still hostile to GPL and entire philosophy.

> 
> [1] Linux Kernel Development: How Fast It is Going, Who is Doing It,
> What They are Doing, and Who is Sponsoring It, 2016.   http://goo.gl/QKbJ5Q
> 
> I suspect if you take a look at how many of the commits that go into
> gcc or LLVM, you would see a similar dynamic.
> 
> 
> So the debate is really about whether or not the companies versus "the
> community" is really an accurate, or for that matter, healthy, way of
> looking at things.
> 

The discussion started because of thoughts about companies abusing GPL
and community is the one that suffers from it as result. Users loose
their Freedom and that is the major point why we do work here in Debian.
Or am I at wrong place?

> It's far more accurate to say that the companies are *part* of the
> community, and we need to encourage all members of the community,
> whether they are individuals or corporations, to live up to the
> community norms.  (And some cases, that means teaching a student at a
> two-year college in Toronto that taking credit for other people's work
> and sending patches that haven't been tested, and in some cases, don't
> even compile, to users who are asking for help on a bug tracker isn't
> cool.  And in other cases, it might be convincing companies and
> individuals who ship VM images that they need to include source.)

It is not at all accurate to state such thing. Companies invade
communities with their money, marketing and so on, they rarely engage
with community in a healthy matter if at all. I agree that we need to
encourage companies to live up to the community norms, but that will not
happen while they violate GPL (basically breaking the foundation of that
norm). We don't need to convince them, that is why there is GPL. They
are free to choose other license such as BSD/MIT and not violate it with
their (nonfree) work.

> 
>> I don't know is it a time for GPLv4 which will explain to all
>> corporations that THIS LICENSE mean you must participate with
>> community...  ...and not engage that only way to achieve is by lies,
>> manipulation, abuse, FUD, secrets.
> 
> In my opinion, this kind of Manichean attitude is not an accurate
> description of reality, and it's really not helpful.

While I understand and su

Bug#836808: ITP: golang-github-googleapis-gax-go -- Google API Extensions for Go

[Potter, Tim (HPE Linux Support)]

Package: wnpp
Severity: wishlist
Owner: Tim Potter 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

* Package name: golang-github-googleapis-gax-go
  Version : 0.0~git20160714.0.8b0741b-1
  Upstream Author : Google APIs
* URL : https://github.com/googleapis/gax-go
* License : BSD-3-clause
  Programming Lang: Go
  Description : Google API Extensions for Go

 Google API Extensions for Go (gax-go) is a set of modules which aids
 the development of APIs for clients and servers based on gRPC and Google
 API conventions.


signature.asc
Description: Message signed with OpenPGP using GPGMail