Re: making dput a wrapper around git

[Daniel Pocock]

On 18/11/14 11:17, Ansgar Burchardt wrote:
> Hi,
>
> On 11/18/2014 09:45 AM, Daniel Pocock wrote:
>> How would people feel if dput was a wrapper around git?
> I think its not a good idea. It has too many problems, see below.
I agree it is not a trivial idea and is unlikely to appeal to everybody

>
>> This wouldn't imply that maintainers must use Git as their VCS
>>
>> For packages that do use git as the VCS, dput would do a "git tag" and
>> "git push", possibly using branches specifically intended for release.
> How would it know which branch to use? There are different conventions
> and integrating one in dput would force all to use the same convention.


Not quite - it would only use a unified VCS for dput purposes if the VCS
already used the layout that was expected

Otherwise it would just fall back to creating a second VCS or offering
to create branches it expects to use.

>> For packages that don't use git as the VCS, a Git repository would be
>> created dynamically without any direct effort by the maintainer.  dput
>> would make a git clone behind the scenes, commit the latest source
>> package into the repository and push it.
> That fails on the second upload. Or when maintainers use different
> layouts for their Git repository. Or when doing NMUs when you would
> suddenly get a second Git repository by the NMUer.
>
>> Various other parts of Debian could then use the Git repositories
>> - signed tags instead of signed source packages
> That's not great either. Nothing guarantees both are identical. (And
> they are not in some cases.)

That is not a Git-specific issue, it is a general issue with source-only
uploads.  If source-only uploads become the norm then signed tags should
be the same as source packages shouldn't they?


>> - the tool for browsing package source in the web browser could always
>> see the source in git
> The main reason why seeing the source in a VCS is useful (at least for
> me) is that you can see individual commits and commit messages. An
> automated system only importing release versions cannot provide that.
>
> (I assume dgit has the same problem.)
>
>> - the release team could rely on diffs from the designated git
>> repository instead of debdiff attachments
> No Git is required for that. There is already debdiff to diff packages
> if you really want to.
Yes, and I agree it works.  With something like Git it may be easier for
the release team to enforce though.  At the moment, there is nothing
which automatically ensures the consistency between the debdiff proposed
in an unblock request and the actual content of the upload.  With a
Git-based solution, the release team could make a signed tag on some
commit and it would be built and allowed through to testing.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546b495e.5090...@pocock.pro

making dput a wrapper around git

[Daniel Pocock]

This is probably tangential to the ongoing DEP-14 and source-only upload
discussions

How would people feel if dput was a wrapper around git?

This wouldn't imply that maintainers must use Git as their VCS

For packages that do use git as the VCS, dput would do a "git tag" and
"git push", possibly using branches specifically intended for release.

For packages that don't use git as the VCS, a Git repository would be
created dynamically without any direct effort by the maintainer.  dput
would make a git clone behind the scenes, commit the latest source
package into the repository and push it.

Various other parts of Debian could then use the Git repositories
- signed tags instead of signed source packages
- the tool for browsing package source in the web browser could always
see the source in git
- the release team could rely on diffs from the designated git
repository instead of debdiff attachments



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546b070f.7000...@pocock.pro

Re: veto?

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/11/14 11:52, Matthias Urlichs wrote:
> Hi,
> 
> Peter Samuelson:
>> 
>> Do you mean, perhaps, that the Further Discussion option in a GR
>> should be weighted much more heavily than other options, so that
>> it can beat another option if only a few people rank it higher?
>> I am not in favor of that.
>> 
> You can't give any one option more "weight" in a Condorcet election
> because each input vote is a ranking of options. You _could_
> require the Condorcet winner to have a 2:1 (or 1.5:1 or …)
> supermajority over FD.
> 
> IMHO, doing this would not be good for Debian, for reasons already
> stated.
> 
>> Or perhaps you mean there should be an official platform where
>> someone can say, effectively, "Before deciding to do X, you
>> should take into account that I, someone directly involved in its
>> implementation, will not help because I'm not convinced X is a
>> good idea.  Also, this may demotivate me from related work Y and
>> Z." But, well, anybody can already say that.
>> 
> Exactly. That platform already exists, it's called "debian-vote"
> (or -devel or -project … take your pick).
> 

As mentioned in another reply, how people vote doesn't give a good
insight into how they will or won't act

The things people write in debian-vote or debian-devel give more
insight but only for those people who take the time to write and even
then somebody has to read all of those opinions and potentially
summarize them.

E.g. if 10 people are going to stop or limit their maintenance of
essential packages because of some technical or policy change, that
would be very useful to know in advance of any GR.

>> Anyway... I don't really see people leaving because of a decision
>> they disagree with.
>> 
> I assume that some do, but they're doing it quietly.
> 
> If the systemd decision had gone the other way (i.e. pro Upstart),
> I would have done the same thing.
> 

It is not just about people formally resigning, people may simply
change the way they are working, may be less likely to volunteer for
things (like mentoring or helping the FTP masters with the NEW queue),
etc.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJUZznvAAoJEGxlgOd711bEHecP/A5q5D1HFsf6SZn19dJBB/pl
suSTFJjxqkvWdoRW20ZWqeV8G9p422/BG4hw1z1dSUWIq8gCm49i5+lN0d/u+lme
oTKlFIGm2DKMGu6zHgBYIPL3ee1HBDwMpWWiHLB8ICqHaXFMy2sgIW/iXFFXC0oq
jGpRa1Yp7UPl4aXjwo067Lhmt5eQv4CNakkvLn99sHASCeQYsbbbXNUPG6iIcSyM
dfSyy6MuKhjsi8dsd9CLNkl57DLKAnnJFuGGIj5oQ2I1GCG/gwp9B5mmd1kaKeM0
9a6nxEg/plN9pTZHTY9H5EF50+qa8iVa5dRFPJRKlhtWPG/bNZxs74dti1N87uao
+RoUNW5xtMg6ta7Qdzz2Vm6ouxmxeQ+mxCDm3Tkx6VXVxXmSqCmpxvEny9l+MMjh
KDaMkOVwB/7JM95Rv/3/zJ3rAKnMVZ0zwqZH+E5WHOuhhj8GrH5NJkUiTl4PxvoT
QzQe3ZXuhr70BHwGRUKu8UfincYgLRGnotsYK6qidh8Im5cQ1r9r+YTU7af1SAVv
AEA+K0BWjg1+rTLwAoTz1k0Lht+N+Q//GMYcLLXJus5b1gCCSyaf8ZggENuQULFx
OnzugBAjVBPoBvFTJ1VsG3yky0IcXND+p3ulsrIy+FQaDZE2Cd1NVcuhBEdBOdLb
R61ORPN6dVUnOrfh5kOz
=WcsA
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546739ef.6080...@pocock.pro

Re: veto the veto?

[Daniel Pocock]

On 13/11/14 15:25, Matthias Urlichs wrote:
> Hi,
>
> Daniel Pocock:
>> If veto is dead, what would the FTP masters do when somebody decides to
>> upload something before checking it is 100% free?
>>
> That's a different sort of veto. That's what they do, and they've got a
> mandate to do exactly that.
and they do a fine job of it too
>
> The veto we're talking about here is more along the lines of
> * DD A has an idea
> * DD B…Y think it's OK
> * DD Z think it's complete bulls**t and states "I veto this"
> * therefore the idea is not adopted
>
> Ostensibly, this would encourage consensus because, well, we take into
> account not only the stated reasons for Z's veto but also all the other
> semi-rational stuff that comes with Being Human, and talk about it until we
> all arrive at a conclusion we all can live with.
>
> In reality, this will not work. One major reason for this is that the
> evolution of Being Human proceeds in _slightly_ longer timeframes than
> the emergence of e-mail and IRC communication. For confirmation, look at
> any flame war where people write things they would (hopefully) never say to
> the recipient's face. :-/
>

That is a worst case scenario but there is no system of decision making
that doesn't have edge cases

However, I think people are missing the point.  It is not just about
people participating in the decision, it is about revealing the
percentage of people willing to actually execute the action that is
decided upon, do nothing, or execute some other action, such as resigning.

Veto is probably the crudest term to use when looking at such a problem,
even if it is not a perfect solution, it is relevant.

If DD "Z" in your example is a volunteer he/she doesn't have to do
anything if he doesn't like the decision anyway.  Maybe he will even
choose to resign or work on another part of Debian.  Fine, that is what
a voluntary organization is all about.

The current GR process doesn't show how many people will end up in such
situations.  In fact, they are hidden from view unless you go looking
through all the posts on debian-devel to see if they have shown their
hand.  If veto is a no go (if you'll excuse the pun), are there other
ways that we can quantitatively and concisely let people reveal how they
will or won't act in relation to a certain choice or decision?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5464cc5e.40...@pocock.pro

Re: veto?

[Daniel Pocock]

On 13/11/14 13:16, Holger Levsen wrote:
> Hi,
>
> On Donnerstag, 13. November 2014, Matthias Urlichs wrote:
>>> I veto this idea.
>> I agree.
> I don't. I veto the idea that this idea is dead, I think we should discuss it 
> some more.
>

If veto is dead, what would the FTP masters do when somebody decides to
upload something before checking it is 100% free?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5464ac26.5030...@pocock.pro

Re: veto?

[Daniel Pocock]

On 13/11/14 06:29, Gunnar Wolf wrote:
> Daniel Pocock dijo [Wed, Nov 12, 2014 at 12:08:23PM +0100]:
>> I didn't want to be too specific, to give other people a chance to make
>> suggestions
>>
>> However, one possibility is that anybody maintaining an essential
>> package and anybody who is a DPL delegate would be able to veto.  The
>> implication is that somebody can still win a GR against the veto, but
>> they do so knowing that they will have to find somebody else to maintain
>> some essential packages.
> As a DPL delegate, I'd strongly veto that idea. That clearly creates
> first- and second-class citizens.

Not quite: if people are choosing not to remain a citizen at all, then
they are neither first or second class.

If there was such a scheme in place, then I don't think people could use
it frivolously, at least not for too long.  E.g. maintainer of essential
package foo vetoes 5 GRs in a row.  At some point, other people will
start stepping forward to maintain that package or propose an alternative.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54646273.7070...@pocock.pro

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Daniel Pocock]

On 11/11/14 22:26, Raphael Hertzog wrote:
> Hello,
> 
> following the initial discussion we had in August
> (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
> written a first draft of the Debian Enhancement Proposal that I suggested.
> It's now online at http://dep.debian.net/deps/dep14 and also attached
> below so that you can easily reply and comment.
> 
> I have left one question where I have had conflicting feedback
> and I'm not sure what's best. Thus I will welcome a larger set of
> opinions on this specific question (search for "QUESTION" in the
> text).
> 
> Are there things that are missing?
> 
> Here's the draft:
> 
> 
> Title: Recommended layout for Git packaging repositories
> DEP: 14
> State: DRAFT
> Date: 2014-11-04
> Drivers: Raphael Hertzog 
> URL: http://dep.debian.net/deps/dep14
> Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn
> Abstract:
>  Recommended naming conventions in Git repositories used
>  to maintain Debian packages
> 
> 
> Introduction
> 
> 
> This is a proposal to harmonize the layout of Git repositories
> used to maintain Debian packages. The goals are multiple:
> 
>  * making it easier for Debian and its derivatives to build upon
>their respective Git repositories (with the possibility
>to share a common one in some cases)
> 
>  * make it easier to switch between various git packaging helper
>tools. Even if all the tools don't implement the same worflow, they
>could at least use the same naming conventions for the same things
>(Debian/upstream release tags, default packaging branch, etc.).
> 
> Scope
> =
> 
> This proposal defines naming conventions for various Git branches
> and Git tags that can be useful when doing Debian packaging work.
> The hope is that maintainers of git packaging helper tools will adopt
> those naming conventions (in the default configuration of their tools).
> 
> Generic principles
> ==
> 
> Vendor namespaces
> -
> 
> Each "vendor" uses its own namespace for its packaging related 
> Git branches and tags: `debian/*` for Debian, `ubuntu/*` for Ubuntu, and
> so on.
> 
> Helper tools should usually rely on the output of `dpkg-vendor --query vendor`
> to find out the name of the current vendor. The retrieved string must be
> converted to lower case. This allows users to override the current vendor
> by setting `DEB_VENDOR` in their environment (provided that the vendor
> information does exist in `/etc/dpkg/origins/`).
> 
> If `dpkg-vendor` is not available, then they should assume "debian" is the
> current vendor. Helper tools can also offer a command-line option to
> override the current vendor if they desire.
> 

What about an extra prefix, e.g. dist/debian/* ?

This would be useful for those cases where the upstream official
repository is willing to keep Debian and Ubuntu branches.


> Version mangling
> 
> 
> When a Git tag needs to refer to a specific version of a Debian package,
> the Debian version needs to be mangled to cope with Git's restrictions.
> The colon (`:`) needs to be replaced with a percent (`%`), and the tilde
> (`~`) needs to be replaced with an underscore (`_`).
> 
> Packaging branches and tags
> ===
> 
> Packaging branches should be named according to the codename of the
> target distribution. In the case of Debian, that means for example
> `debian/sid`, `debian/jessie`, `debian/experimental`,
> `debian/wheezy`, `debian/wheezy-backports`, etc. We specifically avoid
> "suite" names because those tend to evolve over time ("stable" becomes
> "oldstable" and so on).
> 
> The Git repository listed in debian/control's `Vcs-Git` field should
> usually have its HEAD point to the branch corresponding to the
> distribution where new upstream versions are usually sent. For Debian,
> it will usually be `debian/sid` (or sometimes `debian/experimental`).
> 
>   QUESTION: some people have argued to use debian/master as the latest
>   packaging targets sometimes sid and sometimes experimental. Should we
>   standardize on this? Or should we explicitly allow this as an alternative?
> 
> The helper tools that do create those repositories should use a command
> like `git symbolic-ref HEAD refs/heads/debian/sid` to update HEAD
> to point to the desired branch.
> 
> When releasing a Debian package, the packager should create and push
> a signed tag named `/`. For example, a Debian maintainer
> releasing a package with version 2:1.2~rc1-1 would create a tag named
> `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with
> version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should
> point to the exact commit that was used to build the corresponding upload.
> 
> Managing upstream sources
> =
> 
> Importing upstream release tarballs in Git
> --
> 
> If the Git workflow in u

Re: veto?

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 12/11/14 18:36, Philip Hands wrote:
> Daniel Pocock  writes:
> 
>> On 12/11/14 17:47, Thomas Goirand wrote:
>>> On 11/12/2014 07:08 PM, Daniel Pocock wrote:
>>>> On 12/11/14 11:43, Andrey Rahmatullin wrote:
>>>>> On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock
>>>>> wrote:
>>>>>> It is very sad to see that contributors sometimes feel
>>>>>> that the only option for them is to resign.
>>>>>> 
>>>>>> Would it be worthwhile giving people another option, for
>>>>>> example, allowing a percentage of DDs to formally veto
>>>>>> decisions?  Would this be better than people leaving
>>>>>> outright?
>>>>> Can you elaborate which decisions and how many DDs could
>>>>> veto them?
>>>>> 
>>>> 
>>>> I didn't want to be too specific, to give other people a
>>>> chance to make suggestions
>>>> 
>>>> However, one possibility is that anybody maintaining an
>>>> essential package and anybody who is a DPL delegate would be
>>>> able to veto.  The implication is that somebody can still win
>>>> a GR against the veto, but they do so knowing that they will
>>>> have to find somebody else to maintain some essential
>>>> packages.
>>> 
>>> I don't agree with filtering the people on what kind of package
>>> they maintain, or if they have a role delegated by the DPL.
>>> This makes absolutely no sense to me: in what way are they more
>>> competent, and why should they have more power than others?
>> 
>> It is not a suggestion that such people are more or less
>> competent than anybody else.
>> 
>> Rather, it is a recognition of the fact that if these people are
>> going to leave anyway (or are not going to lift a finger to
>> support a particular decision, as everybody is a volunteer after
>> all) then people proposing the decision need to actively
>> demonstrate that they can take on the extra workload that will
>> result from getting a decision in their favor.
> 
> Oh, I see.
> 
> You're expecting people proposing GRs to be receptive to rational
> argument.
> 
> I fear you've not been paying close attention recently.  Well
> done. I congratulate you on your wisdom.
> 

If rational argument is not necessary, then I'll propose a GR myself:
Debian will give every DD a present of 1 million BTC for Christmas.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJUY5ySAAoJEGxlgOd711bEoykP/2ibacRc+firPLXHsYv+BYzJ
ahN6RL7GqW0abHXEgqbvQkg6sUOHcU5R0hxRGm0kCYg43hybmPQaLvEkteh3r9Qd
580p5hsQdtuTBHu9mFTeHBHeWKxI7dfqi+Zt5TEfvi/1brFn2rCEkdZXXX6KJkv4
diA4lKJ5MPPBW5ZiEMKLZMM6uF1I0fdkW6jbd3yI6wsxXbzHiH3OBSKFl3mrX6fV
61ByJX+lcsDfCzTOguVGUanbXMQvuA6W4NVGOTqXOSjoXAYxLdgEmjqeCLJYcOx8
8ysEnMH1/SL1jsYOvBq7MX75I7PqCPrMka23I9MsD9AKfJcHqz8tud/YYL6V8E8/
C7ZcthPxJWRVxrW8cNAQVnjp/dYwKSyyKj+iv7KHm1smnv6qS9okJ5t0FO90kJj5
2oVlowNG9UaVDUIeu5MhKIjMb3YAF3S9dK++T9vkMGZfQgextFzrsSoHBbGxasic
iwlkK0A0ldo+x/RWoQ4vMcbQvwKuNPJhxrwPcE6JAn/i8fzloXxfeAP6OkBHqbOm
GsCjKZyuSWEZGBm0dvb3D+o+ril+Mvsw03jHxqkmfCMmUa/y2uxqj57/km29Osyw
nZj4xT5bDEEu9gFaNDBdTVc9IzznfXbIL7h9H3Z+U03wo/IaNIb/0/PMKUW+w7Ny
e7ux+oFkalhzB1uua4zt
=n+Cj
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54639c92.7010...@pocock.pro

Re: veto?

[Daniel Pocock]

On 12/11/14 17:47, Thomas Goirand wrote:
> On 11/12/2014 07:08 PM, Daniel Pocock wrote:
>> On 12/11/14 11:43, Andrey Rahmatullin wrote:
>>> On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock wrote:
>>>> It is very sad to see that contributors sometimes feel that the only
>>>> option for them is to resign.
>>>>
>>>> Would it be worthwhile giving people another option, for example,
>>>> allowing a percentage of DDs to formally veto decisions?  Would this be
>>>> better than people leaving outright?
>>> Can you elaborate which decisions and how many DDs could veto them?
>>>
>>
>> I didn't want to be too specific, to give other people a chance to make
>> suggestions
>>
>> However, one possibility is that anybody maintaining an essential
>> package and anybody who is a DPL delegate would be able to veto.  The
>> implication is that somebody can still win a GR against the veto, but
>> they do so knowing that they will have to find somebody else to maintain
>> some essential packages.
> 
> I don't agree with filtering the people on what kind of package they
> maintain, or if they have a role delegated by the DPL. This makes
> absolutely no sense to me: in what way are they more competent, and why
> should they have more power than others?

It is not a suggestion that such people are more or less competent than
anybody else.

Rather, it is a recognition of the fact that if these people are going
to leave anyway (or are not going to lift a finger to support a
particular decision, as everybody is a volunteer after all) then people
proposing the decision need to actively demonstrate that they can take
on the extra workload that will result from getting a decision in their
favor.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54639613.1010...@pocock.pro

Re: Should fast-evolving packages be backports-only?

[Daniel Pocock]

On 12/11/14 17:42, Scott Howard wrote:
> On Tue, Nov 11, 2014 at 2:35 PM, Rogério Brito  wrote:
>> On 2014-11-11 15:30, Henrique de Moraes Holschuh wrote:
>>> However, candidate packages due to reason (c) above really are a problem,
>>> IMHO they shouldn't be in stable in the first place.
>>
>> Does this mean that I should ask for the removal of youtube-dl from testing?
>>
>> It will certainly bitrot in a stable release, as it supports downloading
>> from many sites, the target sites are moving too fast (that's the nature
>> of the web) and there's no chance that I will be hunting minimal patches
>> to fix breakage of multiple sites, as upstream generally refactors the
>> whole thing constantly and as multiple sites may get broken, the pile of
>> patches would sometimes be larger than the code to extract data from
>> some simpler sites.
> 
> Maybe a decent release goal for Jessie+1: what to do with these
> packages that require changes that aren't fit for stable-updates to
> remain useful.
> 
> CUT [1,2] I believe, was the most recent stab that this idea, but as
> Daniel Pocock pointed out there are an increasing number of
> cloud/web/networking/communications packages that require larger
> changes than stable-updates would reasonably accept. Such packages, if
> released in stable, would be unusable, or at worst dangerous, to
> users. As such, some are blocked from testing for now. The problem is
> that those packages can't be in backports because they can't be in
> testing because they can't be in stable because they can't be updated
> by stable-updates and need to be updated in backports which they can't
> be in because then they would have to be in testing. There's a
> chicken-and-egg game that prevents supporting those packages in
> Debian, users can't even say "I'll just run testing" since those
> packages aren't allowed in testing. I don't think backports being
> enabled by default, on its own, is the right answer (stable systems
> should be stable) - but some other mechanism might be appropriate for
> users to choose which packages they want continuously updatable.
> Rebecca's suggestion might be a clever way of obtaining such a
> feature: (1) blocking migration to testing, (2) maintaining in
> backports, and (3) incorporating some easy way for users to choose to
> pin the backports version or install from backports if not available
> via stable.
> 
> [1] http://cut.debian.net/
> [2] http://lwn.net/Articles/406301/
> 

Looking at it from the user perspective: users expect Debian packages to
be stable

So if we have some packages that will never be stable, as long as we
have a way to signal that to users when they choose the package, I think
we should make it as easy as possible to make them available in a stable
release.

backports already does some of that.  Security team is using security
updates to do it with browsers.  The only question is whether to have
packages that are always essentially like a backport.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5463956b.5090...@pocock.pro

Re: veto?

[Daniel Pocock]

On 12/11/14 13:12, zlatan wrote:
> Please no.
>
> We need less and not more layers of governance/'political' complexity
> in project. Lets stop acting like government  and more like community.


If a veto facility is created effectively, then it will deter people
from complexity and force people back to looking for consensus

If it is too easy to veto something though then I agree that would slow
the project down


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5463557d.2030...@pocock.pro

Re: veto?

[Daniel Pocock]

On 12/11/14 11:43, Andrey Rahmatullin wrote:
> On Wed, Nov 12, 2014 at 11:04:05AM +0100, Daniel Pocock wrote:
>> It is very sad to see that contributors sometimes feel that the only
>> option for them is to resign.
>>
>> Would it be worthwhile giving people another option, for example,
>> allowing a percentage of DDs to formally veto decisions?  Would this be
>> better than people leaving outright?
> Can you elaborate which decisions and how many DDs could veto them?
>

I didn't want to be too specific, to give other people a chance to make
suggestions

However, one possibility is that anybody maintaining an essential
package and anybody who is a DPL delegate would be able to veto.  The
implication is that somebody can still win a GR against the veto, but
they do so knowing that they will have to find somebody else to maintain
some essential packages.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54633fa7.1050...@pocock.pro

veto?

[Daniel Pocock]

It is very sad to see that contributors sometimes feel that the only
option for them is to resign.

Would it be worthwhile giving people another option, for example,
allowing a percentage of DDs to formally veto decisions?  Would this be
better than people leaving outright?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54633095.9060...@pocock.pro

Re: Beersigning in Zürich/SH/Winti? Meeting other local Debianistas? Bugfixing?

[Daniel Pocock]

On 12/11/14 06:59, Paul Wise wrote:
> On Wed, Nov 12, 2014 at 10:16 AM, Tomas Pospisek wrote:
> 
>> would any of you come and sign my key when in Zürich/SH/Winti?
> 
> In case folks from these places aren't reading this list, some possibilities:
> 
> https://db.debian.org/search.cgi?country=ch&dosearch=Search
> https://wiki.debian.org/Keysigning/Offers#CH
> https://wiki.debian.org/LocalGroups#Switzerland
> http://debian.ch/
> 
> This info brought to you by DebianLocations:
> 
> https://wiki.debian.org/DebianLocations
> 


Even better - there is monthly beersigning near the main railway station
Zurich HB, look for the Debian Treff:

http://www.lugs.ch/lugs/termine/

I'm not far from Zurich myself, may be up there again Saturday, please
email on the debian.ch list or try #debian.ch


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54630469.9040...@pocock.pro

Bug#769173: RFA: libmusicbrainz5 -- Library to access the MusicBrainz.org database

[Daniel Pocock]

Package: wnpp
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-multimedia-maintain...@lists.alioth.debian.org, a...@gently.org.uk,
tjaal...@ubuntu.com

https://tracker.debian.org/pkg/libmusicbrainz5

libmusicbrainz5 is pulled into many GNOME desktops as a dependency,
hence the high popcon stats:
https://qa.debian.org/popcon.php?package=libmusicbrainz5

There is currently an RC bug, a couple of non-free files crept in at
some point, upstream has removed them but had to make API changes.
Somebody adopting the package may need to consider a transition.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749698

This package relies on a web service API from MusicBrainz and somebody
familiar with that may be able to support the package more easily.

I think this is a very worthwhile package, it is part of the eco-system
of open source alternatives to cloud-based music services.  I originally
helped with this package to support the packaging of flactag.  However,
I have a large portfolio of other packages where I have more in-depth
experience and ongoing development work hence I'm putting this one
up for adoption in the hope that somebody will focus on it.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5462804c.5090...@pocock.pro

Re: Should fast-evolving packages be backports-only?

[Daniel Pocock]

On 11/11/14 18:30, Henrique de Moraes Holschuh wrote:
> On Tue, 11 Nov 2014, Rebecca N. Palmer wrote:
>> Possible candidates:
>> a. Packages that work closely with hardware, where old versions
>> don't work with new hardware (example: beignet)
>> b. Packages that implement fast-evolving file formats or network
>> protocols, where you need the same version as the people you are
>> communicating with (possible example: jscommunicator [2])
>> c. Packages that are generally rapidly improving, and are typically
>> used where this improvement is more important than stability
> 
> We used to have the volatile archive for software that absolutely needs to
> be updated very often (like virus scanners).  We now have the
> "stable-updates" archive for this.
> 
> https://wiki.debian.org/StableUpdates
> 
> If packages are taking too long to go from stable-proposed-updates to
> stable-updates, that's something we could talk to the release managers
> about.
> 
> Although, I am *sure* lack of widespread use (and therefore testing) of
> stable-proposed-updates by users and developers (HINT HINT HINT HINT) is one
> of the reasons.
> 
> However, candidate packages due to reason (c) above really are a problem,
> IMHO they shouldn't be in stable in the first place.  backports seem like a
> better solution for this case.  However, we'd need to add further
> requirements:  packages not built from the same source package cannot depend
> on such "never-for-stable" packages, and we must tag them somehow so that
> they never get released to stable...
> 

That is not so easy though or it may have side effects

For example, if a library changes implementation details but the public
API and ABI does not change and no other dependent packages need to be
recompiled then it should be OK for those dependent packages to live in
stable.

Does that mean the maintainer has to put their libfoo-dev in stable
while keeping their volatile libfoo1 in backports?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54624ca0.80...@pocock.pro

Re: Should fast-evolving packages be backports-only?

[Daniel Pocock]

On 11/11/14 14:30, Rebecca N. Palmer wrote:
> It has been recently stated [0-1] that backports is enabled by default
> in Jessie.
>
> 1. Does that mean that if pkgX is in jessie-backports but not jessie,
> "apt-get install pkgX" will install it from -backports?
>
> 2. If so, when (if ever) is it appropriate to deliberately invoke that
> behaviour by removing pkgX from jessie?
>
> Possible candidates:
> a. Packages that work closely with hardware, where old versions don't
> work with new hardware (example: beignet)
> b. Packages that implement fast-evolving file formats or network
> protocols, where you need the same version as the people you are
> communicating with (possible example: jscommunicator [2])

> c. Packages that are generally rapidly improving, and are typically
> used where this improvement is more important than stability


Maybe also

d. packages that the security team decide to support by using
upstream releases (in other words, should the browsers be distributed
through backports only?)

One big question that arises then (and what I asked in a separate thread
about the browser-related packages but it is relevant to other classes
of package too) is compatibility
- if package foo is allowed to change, do all packages broken by the
change (e.g. browser plugins) get to be uploaded again too?
- if some package hides the complexity of the change and the maintainer
has kept the API stable so that dependent packages don't break should it
be looked on more favorably and allowed to be updated in stable too?

Personally, I feel that having backports enabled by default is only part
of the solution to the challenges with volatile packages but it may be a
step in the right direction.

I also feel that this is something that impacts each maintainer and each
user differently.  Some people are working in parts of the system where
the freeze concept really is the most important thing.  Other people are
working on applications where network compatibility is the most
important thing (as it is with communications) and people simply won't
use the package or won't be able to use it successfully if is not
updated.  Ultimately, with more and more packages being in this category
as the world becomes more networked/cloudified, this impacts Debian's
relevance for whole groups of users.


>
> The advantage of doing so (over having both the old version in jessie
> and the new one in jessie-backports) is that non-technical users (who
> may not know that backports exists) get the new version they probably
> want; the disadvantage is that users who explicitly want stability can
> no longer choose it (except by pinning or using snapshot.debian.org,
> which also block security updates of that package).
>
> In the long run it may be a better idea to have these packages suggest
> upgrading to -backports in their "this hardware/protocol
> version/option not supported" error message, or on startup if there is
> no easy way to identify attempts to use the newer features, but it is
> too late to do this for jessie.
>
> (Release team have already ruled that a. (#767961) and b. (#768933)
> are not valid reasons for freeze exceptions; I guess this would also
> forbid stable updates)
>
> [0] https://lists.debian.org/debian-devel/2014/11/msg00339.html
> [1] My own sources.list has
> # jessie-backports, previously on backports.debian.org
> # Line commented out by installer because it failed to verify:
> #deb http://ftp.uk.debian.org/debian/ jessie-backports main
> but https://lists.debian.org/debian-user/2014/09/msg01174.html reports
> getting one with that line uncommented
> [2] https://lists.debian.org/debian-release/2014/11/msg00866.html
>
>


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54621b37.4040...@pocock.pro

release browser-related packages to stable?

[Daniel Pocock]

Since 2013, Debian has allowed new browser versions to enter stable[1]
even though most other package versions are frozen

The security team announcement mentions that "some Xul extensions
currently packaged in the Debian archive are not compatible" and that a
solution to that is still being worked out.

There are similar consequences for some server-side content, e.g. jessie
will include various WebRTC JavaScript libraries.  The packages
asterisk, jssip, jscommunicator and sipml5 closely follow this emerging
standard.  There have already been some occasions where changing browser
technology (e.g. Chrome changing from SDES to DTLS-SRTP encryption) has
caused these other packages to become unusable for periods of time.

Has there already been any further discussion about the solution for Xul
extensions packaged in Debian?

With the freeze for jessie having just started, should the freeze
guidelines be amended to make it easier for packages closely related to
the browser to be updated to new versions at any time during the freeze
if the browser version itself changes?

Are there people who would object to such updates?


1. https://lists.debian.org/debian-security-announce/2013/msg00107.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5461d85b.4020...@pocock.pro

Re: versions / suffixes in experimental

[Daniel Pocock]

On 25/09/14 10:00, Neil Williams wrote:
> On Thu, 25 Sep 2014 09:42:42 +0200
> Jonas Smedegaard  wrote:
>
>> Quoting Daniel Pocock (2014-09-25 09:16:46)
>>> I have a package, version 2.2.5-5 in unstable and testing
>>>
>>> I uploaded 2.2.5-6 and 2.2.5-7 to experimental.  Should I have
>>> given them versions like 2.2.5-6~exp1 or something and then upload
>>> a proper 2.2.5-6 to unstable when I am happy with it?  Or should my
>>> next upload to unstable by 2.2.5-8?  Or do I just ignore the
>>> version numbers I uploaded to experimental and use 2.2.5-6 as the
>>> next version number for an unstable upload, even if it doesn't
>>> contain the same things as 2.2.5-6 in experimental?
>> Both approaches makes sense to me - depending on your reason for
>> using experimental in the first place - and on your mood.
> Any approach which tries to use the same version in multiple suites at
> the same time does not make sense to the archive. The mood of the
> maintainer is rightly ignored by dak.
>

Personally, I think the suffix would be useful for cases where the
upload to experimental and unstable are both otherwise identical

If I upload 2.2.5-8 to unstable, should it include the changelog entries
for experimental too or that doesn't matter either way?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5423dd42.6060...@pocock.pro

versions / suffixes in experimental

[Daniel Pocock]

Is there any convention for version numbers in experimental?

E.g. when uploading to backports, we add a suffix like "A.B.C~bpo70+1"
so that the system can cleanly upgrade to version A.B.C when upgrading
to the next stable release.

I have a package, version 2.2.5-5 in unstable and testing

I uploaded 2.2.5-6 and 2.2.5-7 to experimental.  Should I have given
them versions like 2.2.5-6~exp1 or something and then upload a proper
2.2.5-6 to unstable when I am happy with it?  Or should my next upload
to unstable by 2.2.5-8?  Or do I just ignore the version numbers I
uploaded to experimental and use 2.2.5-6 as the next version number for
an unstable upload, even if it doesn't contain the same things as
2.2.5-6 in experimental?





-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5423c15e.1090...@pocock.pro

Re: 2 months and no upload for pkg

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 05/09/14 20:46, Matthias Urlichs wrote:
> Hi,
> 
> Daniel Pocock:
>> 
>>>> c) offer a paid review service.  FTP masters and assistants
>>>> can sell their time through an auction process.  [...]
>>> 
>>> I hope this is a joke.
>> 
>> Not entirely I was not suggesting people would pay to have their
>> packages approved. Only that there would be payment for
>> consideration.
> 
> I recall that the last time we went through this sort of argument, 
> numerous people have stated quite unequivocally that as soon as
> there is any sort of direct monetary compensation for participating
> in some Debian tasks, they're outta here.
> 
> I don't think that has changed, and thus I believe that the net
> amount of work done for Debian is most likely to *de*crease if
> somebody does that kind of thing.
> 
> TL;DR: Do Not Go There.

Well, I did give the disclaimer that this was just a list of ideas to
start discussion - it would be really helpful to have other potential
ideas too.

There is already the appearance of commercial activity in derivatives
and it can also undermine motivation for people when they upload
something to Debian and they see it in a commercially funded
derivative distribution before it passes the NEW queue and appears in
Debian itself.  In the case of one of my own uploads, this appeared to
be pure co-incidence but I can imagine cases where the packager may
get a bad impression.

One way to deal with this may be to suggest that if something is
accepted by Ubuntu while waiting in NEW and if it passes an automated
scan for binary content and blacklisted license texts, it could be
automatically accepted in Debian.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJUCsCyAAoJEGxlgOd711bEosUQAJfL62+H0r0FsbHTuMZQ9Fbs
Lzg/umTgZ8qcS81g09EW0LqiuYiXAD+tvsF8OoktxvmBWspUEOd3xj2tA0ZstaG0
v7ZWgK6wfiXoQmWqs9viUy1nrHguM1FbNpSCsYRsM56w7jsLqwroxLJGTN/vPrjI
bRgeaw4HGGG3hY0Ln4sEAYI+ehJ3XOu2MDIqpEfsdvSOuoA6Y/FF0cH7Enk6zaQ+
5Dx2+PBLY5MP2pr0zV0zGnLsZuNSWoBFvqYHCu8qCS1mbFcfloaOLTftYTIYgAzg
ktXZL5HEM3H7HQsVup9j7JZIvU4z69v47/5UqkfK0GwmViz730G9TksJHURLDMmc
9SLOQty9Ga3m4JgK+G2vtJs4lmJ06ghUGktGIbeiTzCKYHzI6fIYOCIHYs6OGG6x
H4DrzolOPDBcibVIQSHnkSma1u2ORVP3+0kXHvdOIGmOBg+kkEXEvmIey/f8kG63
kCnISbtHa5VgPS4syA1fvAFnAruaKHL0G3QEtrMTdRp9s1vIVZSTbP0G0VlV1TKh
E8l9mr0Ol5N38uLNKjm4JXiLkte+b3QF0vUfClre7add96XeJeLOlBjJ8KBdOknF
xobrlmmhr8VkSe1cpOJJKMiHDoWVII1hKY/VPSPtMsIgz/7GkcM7J378UmNg70aI
S420ykwhPJ5TWK7BMAuR
=CPJk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/540ac0b2.5000...@pocock.pro

Re: 2 months and no upload for pkg

[Daniel Pocock]

On 05/09/14 18:45, Ian Jackson wrote:
> Daniel Pocock writes ("Re: 2 months and no upload for pkg"):
>> This is really the root of the problem and I agree that it would be nice
>> to find ways to help them.  A solution is good for the FTP masters and
>> good for the project.
> 
> I agree.
> 
>> Another way to look at your proposal may be to compare it to
>> alternatives (I'm not suggesting I personally agree with all of these,
>> but they are just some things that come to mind):
>>
>> a) let people self-certify packages when they wrote 100% of the code
>> themselves.  People abusing this privilege would lose it.
>>
>> b) offer some facility for upstreams to certify their packages as 100%
>> free software by completing a DEP-5-like template and signing it with
>> the same key they use to sign their tags and release announcements.
> 
> I think both of these are, mostly, ad-hoc ways of prioritising certain
> packages.  (Since the effort of setting up such systems and monitoring
> compliance etc. is probably not less than that of reviewing the
> packages in question and coming to a judgement.)
> 
> A more flexible approach along the same lines would be to allow
> packages to skip manual NEW review if countersigned by N DDs (who
> would presumably lose countersigning privileges it was later
> discovered that the package should have been rejected).
> 
>> c) offer a paid review service.  FTP masters and assistants can sell
>> their time through an auction process.  [...]
> 
> I hope this is a joke.

Not entirely

I was not suggesting people would pay to have their packages approved.
Only that there would be payment for consideration.  If the payment was
completely transparent, if it motivated more people to join the FTP team
and if it increased throughput without compromising quality then it may
be worthy of discussion.

If it meant packages of a non-commercial nature were never getting
looked at then I personally would feel that is a loss for Debian.


>> d) the upload with binary JARs inside it was accepted by the NEW queue
>> software.  Maybe the scripts could be stricter about rejecting such
>> packages before they reach FTP masters?  Do the FTP masters publish
>> statistics on rejections that could be used to identify the top things
>> to scan and reject automatically?
> 
> I'm sure the ftpmasters will welcome your patches to their decision
> support software.

I'd be happy to comment on that further if anybody could point me to
statistics about the types of things to look for.  Maybe this could also
be a good idea for an OPW project?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/540a035d.1010...@pocock.pro

Re: 2 months and no upload for pkg

[Daniel Pocock]

On 05/09/14 17:48, Ian Jackson wrote:

> It is true that long NEW processing queues is a big problem.  But it
> appears that a substantial amount of core team effort is being used to
> deal with poor submissions.  If we can fix that, we can fix the long
> queue.
> 

This is really the root of the problem and I agree that it would be nice
to find ways to help them.  A solution is good for the FTP masters and
good for the project.

Another way to look at your proposal may be to compare it to
alternatives (I'm not suggesting I personally agree with all of these,
but they are just some things that come to mind):

a) let people self-certify packages when they wrote 100% of the code
themselves.  People abusing this privilege would lose it.

b) offer some facility for upstreams to certify their packages as 100%
free software by completing a DEP-5-like template and signing it with
the same key they use to sign their tags and release announcements.

c) offer a paid review service.  FTP masters and assistants can sell
their time through an auction process.  Uploaders and interested third
parties can bid for packages to be reviewed.  If they reject a package,
it goes back to its original place in the queue unless somebody pays for
them to spend more time on it.  Some people may feel that this will
deter the FTP masters from reviewing packages unless all uploaders start
paying while other people may feel that this funding would give the FTP
masters more time.  Maybe the fee could include a surcharge of 33% to
cover regular queue processing, so for every 3 packages that pay, one
package is taken from the front of the queue as well?  The rate of the
surcharge could be variable to keep the backlog within a 2 week target
range.

d) the upload with binary JARs inside it was accepted by the NEW queue
software.  Maybe the scripts could be stricter about rejecting such
packages before they reach FTP masters?  Do the FTP masters publish
statistics on rejections that could be used to identify the top things
to scan and reject automatically?

Are there other alternatives that people can think of?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5409e308.3080...@pocock.pro

Re: 2 months and no upload for pkg

[Daniel Pocock]

On 03/09/14 17:47, Ian Jackson wrote:
> Daniel Pocock writes ("Re: 2 months and no upload for pkg"):
>> It may not simply be the person
>>
>> Somebody uploading packages where they are also the upstream may know
>> the copyright situation inside out and just cut and paste
>> debian/copyright from one package to the next and it is always correct.
>>
>> Somebody ambitious who works on packages they are less familiar with
>> or really monstrous packages may well miss things from time to time
>> and be deterred by such a system.  Then we have less people willing to
>> attack such monstrous packages.
> 
> There is a tradeoff here, between 1. the interests of users and
> developers of the `monstrous' package, and 2. the interests of
> ftpmaster and the users and developers of everything else.

That depends on the extent to which you consider all packages to be
independent of each other or if you believe that a collection of
packages, big and small, is worth more than the sum of the values of
each individual part.

> The costs of such a `monstrous' package should be borne by those who
> are working on it and want to see it in Debian.  It is true that that
> means that such packages are less likely to be in Debian than smaller
> or easier ones.  We should not try to fix that by redirecting core
> team effort to fix big and difficult packages.

I'm certainly not arguing that work on monstrous packages should be
offloaded onto the ftp masters.  I was only thinking about very small
errors, like missing the fact that some particular file has a slightly
different license that is otherwise fully compatible with the license of
the overall package.

There is one package I recently uploaded where I meant to use a
repackaged tarball to get rid of an embedded binary toolchain JAR.  This
is a more nasty mistake of course but thanks to the diligence of the FTP
masters it was spotted.

What is fascinating though is that other developers made exactly the
same mistake with exactly the same source package - uploading it
directly into Ubuntu, binary JARs included[1], before it had passed
through the Debian NEW queue.  In fact the Ubuntu changelog[2] mentions
at least three other developers who also didn't notice the same embedded
JAR in the source.

This also brings up one other concern about a procedure that
deliberately defers processing of some items in the NEW queue: it may
give an advantage to derivative distributions that are cherry-picking
the best things from NEW and appear to be getting them faster than Debian.



1.
https://launchpad.net/ubuntu/+archive/primary/+files/libphonenumber_6.0%2Br655.orig.tar.gz

2. https://launchpad.net/ubuntu/+source/libphonenumber/+changelog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54083f7f.9020...@pocock.pro

Re: Bug#759014: RFP: bitcointrader -- Bitcoin trading application

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256




On 23/08/14 21:42, Dmitry Smirnov wrote:
> Package: wnpp Severity: wishlist X-Debbugs-CC:
> debian-devel@lists.debian.org,pkg-bitcoin-de...@lists.alioth.debian.org
>
>  Package name: bitcointrader Version: 1.07.99 Upstream Author: July
> IGHOR  URL:
> https://github.com/JulyIGHOR/QtBitcoinTrader License: GPL-3+ with
> OpenSSL linking exception Description: Bitcoin trading application 
> QtBitcoinTrader is a front-end to cryptocurrency exchanges. It
> helps to open and cancel orders very fast and monitor data in real
> time. .

Could this link against the OpenMAMA packages to get real-time
currency rates?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJT+4j0AAoJEGxlgOd711bEcRYQAJrhgbXi4vY6BK0HDvReooC1
GXlPaNnRvLWeblyGqVKxsFX9Bnhq+YQM7ad3cPt07E0GCJe4TucETz8DpH1h0HaX
13+ustbPZ0zc2jIRQyU4pTCvj8n9hQgZhzTSo7Srd5VNkSrnh1reOCuzFYGbr4/c
R6VdxMFvJJV43UFN7JQKAFdl+M+VY+G87m7I+YX+E7GM4xgxGP3cpeENKniLs5Ae
nfHzy4EocA0ZGKd64uW/raV3e15XoxIWhW8FkElGmFBo9u4Y/VrwgRasfmjEXOiI
KrWZa09IscqeUJkEg3ZMP8ktqUgYdGliZiBINTFuWOrSPt6CrPFO2L3xiFyqSQ2j
AhKBtsjA7A/mAU9o58fSCDeXDAGWX7bmVUPugtw+uNbbFtkRBNAlGrfsiYLwm/0g
uRSQFY2UpGw/5XC9+4Jsv9+K+PCYlQj4A0QzRwZ+H4Ljavn7Xv6XnFJhC2pgFo64
B+kKHBB5uxpV513g67zDk0Jz+JPu3ipHqWnowVQs6kJWlohYdU/z1RrCFoFRPmHL
wCK0glAjxV/Ls17H+sGJGhrW8aN6gF99YaNQNv5hWMLSKj/RG3leDWUYfaeGcmzk
6poHlafO+Ac8jsfI4IjekxcSBIESxFcQ94hOAfVFM3Cu9LxIdKxemBzXWeRmFiAB
Te+ArxaxEG2zf2LDn99Y
=wfBh
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53fb88f5.2050...@pocock.pro

Re: 2 months and no upload for pkg

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 20/08/14 16:39, Marco d'Itri wrote:
> On Aug 20, Ian Jackson  wrote:
> 
>> I think we need a reputation system here.
>> 
>> Eg, you could sort the NEW queue by something like
>> 
>> number of REJECTs of uploader's packages in last 12 months 
>> --- 
>> number of ACCEPT or REJECTs from uploader in last 12 months + 1
>> 
>> If you did that, someone who submitted several bad packages to
>> NEW would have to get another DD or DM to sponsor their NEW
>> uploads.  That might well deal with the quality problem quite
>> quickly...
> This looks like a great idea.
> 


It may not simply be the person

Somebody uploading packages where they are also the upstream may know
the copyright situation inside out and just cut and paste
debian/copyright from one package to the next and it is always correct.

Somebody ambitious who works on packages they are less familiar with
or really monstrous packages may well miss things from time to time
and be deterred by such a system.  Then we have less people willing to
attack such monstrous packages.

Ultimately, the person who made the package may be using it anyway and
such delays may only inconvenience other users of a package, including
the rest of the community.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJT9N94AAoJEGxlgOd711bEMVcP/jUutpWoz82uDNLK1jzb/e4L
LfluobflwG0npCAA/jQawET0wi6PZEQfRgTo2kT5k3w99rmwmxbUOpS4+BM/HgEe
JYt/Ne2E5THdJBx061/TcAoBI4pISSOHKn8KXH/voAFaaepmW5XQ7kWOk7a3RBgQ
K6xKdlNAGGsHkOvW2ZMAB4kzw0+dk+tW39jn5cxQY1bi3r9Y7J77TeWJjjppBHTs
DxQtlG4SMFxiA8RLGV79H1USx5Dbd8Dm6VPbU/Qhv0KeZPkMyXfBhxQvATAw1voZ
7BwRYdjn5miQpqUKunSBOPBPLUkqAXVzaQnuW+8L0iLGqCNl9WB1tsAxyIFGy1Qf
yqslGhLcv7EjOUKUM90Uvd7lwB9qzzH0tmVNrkvdvzd7qpDpNO57LF/dpcfjO6OM
Uc+FmzjtfON+bzxT5v9b6M1QUnkMatU2B7/KFJlL9va6/5+TP/peDrPQaGYkqCUs
4c+ukB+RdaOevjpz45Ccp/Y+QypYZ0P1MjKexdtlIjl+rNzOFEFAE2jViloypdCC
dlcppCBqgWutk28Oq2fd//IkO8GwXh4Q4PJEesB8+6WGsY8ZkZku+LTM1kmXw70w
R+yHSKGlrsJcwuxkzZmrij7wwfzqn8l0J9ZaXCICspNQylG5eH2zFgHnsxK/HRz1
Ro+uevciP6z7/9fJ2e5Y
=Z9br
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f4df78.2040...@pocock.pro

Re: packages using non-standard ports

[Daniel Pocock]

On 02/08/14 19:17, Henrique de Moraes Holschuh wrote:
> On Sat, 02 Aug 2014, Josh Triplett wrote:
>> How easily could you teach syslog-nagios-bridge to listen on a UNIX
>> domain socket, instead of or in addition to a TCP socket?  You could
>> then have it listen on /run/syslog-nagios-bridge by default, and have
>> rsyslog automatically forward messages there.
> 
> Unless this socket is *never* going to need any sort of access control, rule
> zero for UNIX socket security applies: you must put it inside a directory.
> 
> I.e. unless this socket always has to be accessible by everyone, don't put
> it directly in /run.  Use something like /run/syslog-nagios-bridge/socket,
> and depend on the access permissions of /run/syslog-nagios-bridge/ to
> control access to the socket.
> 
> That may well mean you need the directory just for the socket.  If you have
> extra files that need different access restrictions, they'll have to go in a
> separate directory.
> 

Using a UNIX socket involves:

- patching python-netsyslog to create the socket instead of binding to a
TCP port (this is not hard)

- using rsyslog's omuxsock module

http://www.rsyslog.com/doc/omuxsock.html

Looking at that, it appears less flexible than TCP as the socket name is
defined globally, so if somebody else already writes to some socket,
maybe they can't have multiple output sockets?  Or maybe that is just a
shortcoming in the documentation/example though?

It would also be necessary to check how rsyslog behaves when the socket
is not there (e.g. if rsyslog starts before syslog-nagios-bridge or if
syslog-nagios-bridge is restarted).  Using TCP, rsyslog caches the
messages for peers that are temporarily offline.

However, I agree the UNIX socket is more flexible than hard-coding some
port number and it is also easier to align with current security
practices for log data (e.g. the socket would only be accessible to
root, just like /var/log/*)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ddd947.6020...@pocock.pro

Re: packages using non-standard ports

[Daniel Pocock]

On 02/08/14 15:24, Ben Hutchings wrote:
> On Sat, 2014-08-02 at 13:05 +0200, Daniel Pocock wrote:
>>
>>
>> syslog-nagios-bridge needs to listen on a TCP port for connections from
>> rsyslogd or whatever
>>
>>
>> To make it easy for users (fully automated installation), I can
>>
>> a) configure the package to listen on some port (I use 30514)
>>
>> b) deploy a file /etc/rsyslog.d/nagios-bridge.conf with the config for
>> the same port
>>
>> Doing this, the service starts working as soon as the package is installed.
>>
>> Do people feel it is a good idea for packages to grab non-standard ports
>> like this?
> 
> Not really, no.  Isn't there a standard port for this?  (Annoyingly
> 514/tcp is assigned to a completely different protocol.)
> 


The syslog daemon itself usually listens on 514

It then relays a copy of every message to syslog-nagios-bridge on
localhost:30514 or whatever using the same Syslog protocol.

syslog-nagios-bridge shouldn't run on 514.  Although it can receive
Syslog packets, it doesn't store them to file or database or any other
normal Syslog features.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53dce848.1080...@pocock.pro

packages using non-standard ports

[Daniel Pocock]

syslog-nagios-bridge needs to listen on a TCP port for connections from
rsyslogd or whatever


To make it easy for users (fully automated installation), I can

a) configure the package to listen on some port (I use 30514)

b) deploy a file /etc/rsyslog.d/nagios-bridge.conf with the config for
the same port

Doing this, the service starts working as soon as the package is installed.

Do people feel it is a good idea for packages to grab non-standard ports
like this?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53dcc5ed.6060...@pocock.pro

Re: Alioth tracker

[Daniel Pocock]

On 11/05/14 18:26, Tollef Fog Heen wrote:
> ]] Daniel Pocock 
> 
>> On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote:
>>
>>> What is the reason that the processing there is so slow? Is there a way
>>> to change that?
> 
> I think it's quite clear and has been for a while that we need more
> active admins for Alioth.
> 
>> Other people have had problems with alioth too:
>>
>> - write permissions on VCS directory for new projects
>>
>> - mailing list creation requests waiting for admin approval
> 
> Mailing lists are managed through gforge and there's no manual approval
> process that I know of.


When creating a list, it tells me the list will be approved within 6-24
hours

Previously when I created lists, I would receive an email from mailman
some hours later giving me the list password - this is the usual mailman
behavior when the mailman site admin approves a list.  Maybe that is
entirely within mailman and not gforge.

>> Any of these things could help reduce the admin burden, maybe there are
>> other approaches too?
> 
> Help fix bugs in fusionforge, hang out in #alioth try to help people and
> we'd be happy to get more people involved.

If people have not already stepped forward to fill these gaps then that
is the very reason why I was suggesting further automation or cutting
back on things like legacy VCS support.

Hopefully the burden of support and the capacity of volunteers will then
converge at a point where it is sustainable.

I'm not criticizing anybody for this situation, nor am I trying to prod
anybody into action - I just feel that if volunteers are limited, it is
better to constrain the scope of the service.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/536fd070.1090...@pocock.pro

Re: Alioth tracker

[Daniel Pocock]

On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote:
> Hi,
> 
> is someone processing the items on the Alioth tracker?
> 
> There are currently 184 reuqests open, some trivial requests already
> since two years (like [1]).
> 
> I filed a ticket there a month ago, and still did not get any
> response yet.
> 
> What is the reason that the processing there is so slow? Is there a way
> to change that?
> 
> Also, although alioth is an official Debian server (right? It has .org
> suffix), it does not use the Debian bug system, but its own ticket
> system. I asked that already some time ago, and got the recommendation
> to ask that on alioth directly. However, since the response time there
> is so long, I doubt that there will be a discussion about this.
> 


Other people have had problems with alioth too:

- write permissions on VCS directory for new projects

- mailing list creation requests waiting for admin approval

On non-Debian sites (e.g. Sourceforge, github) things like this are
fully automated (for better or worse).

For mailing lists:
- could list creation be fully automated if they are on a debian.net
subdomain?
- could all DDs be given rights to approve alioth.d.o mailing list
creation (with a dispute process for any controversial approvals)?

For repositories:
- would moving to a single tool (e.g. Git) make it easier to automate
and help to eliminate the bugs we currently see on alioth?
- could we have a debian.org solution (alioth or elsewhere) that
automatically mirrors all Git repositories that DDs maintain themselves
on github or other public locations?

Any of these things could help reduce the admin burden, maybe there are
other approaches too?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/536f821a.5030...@pocock.pro

Re: concurrent installation of different pkg versions

[Daniel Pocock]

On 28/04/14 21:16, Jonas Smedegaard wrote:
> Quoting Daniel Pocock (2014-04-28 20:10:09)
>> On 28/04/14 18:59, Gunnar Wolf wrote:
>>> Paul Wise dijo [Sat, Apr 26, 2014 at 11:41:17AM +0800]:
>>>>> a generalized approach is needed.
>>>> Multiple versions of a package seems undesirable to me, for the 
>>>> same reasons as static libraries and embedded code copies are 
>>>> undesirable.
>>> [...] It makes sense for a programmer [...]
>>> But supporting this as a whole is a mess.
>> I'm not suggesting that this is a practice that should be encouraged 
>> nor given the same level of security support in every case.
>>
>> However, there are cases (e.g. hundreds of packages containing jquery) 
>> where it becomes the lesser evil: instead of having hundreds of copies 
>> of non-standard JavaScript dependencies, we end up with maybe 3 or 4 
>> supported versions of each important library.
> What level of support _are_ you talking about - at all?
>
> I fail to understand: How are packages magically "supported" by it being 
> possible to co-install both the version maintained ordinarily and older 
> instances of same package no longer maintained but e.g. fetched from 
> snapshot.d.o?
>
> If you imply support from the security team for snapshot.d.o then I find 
> it quite important to state explicitly what you have in mind.
>
> If you imply support from the package maintainer, then I find it more 
> sensible to simply maintain as separate packages for each "branch" that 
> the maintainer deem sensible to support - as we are doing with a range 
> of packages.
>
> If you don't really mean "supported", just "possible" then there are 
> several ways a sysadmin can either maintain a separate virtualized full 
> Debian installations or a custom versions of code (possibly simplest 
> being to pile stuff up below /usr/local or withing the project needing 
> it).

Perhaps the support burden for legacy versions should be taken up by
those people packaging things that depend on the legacy versions.

They would then have to weigh up the benefits of getting upstream to
work with newer jquery or supporting a legacy jquery package.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535f6f74.6080...@pocock.pro

Re: concurrent installation of different pkg versions

[Daniel Pocock]

On 28/04/14 18:59, Gunnar Wolf wrote:
> Paul Wise dijo [Sat, Apr 26, 2014 at 11:41:17AM +0800]:
>>> a generalized approach is needed.
>>
>> Multiple versions of a package seems undesirable to me, for the same
>> reasons as static libraries and embedded code copies are undesirable.
>>
>> Systems that do this already exist though:
>>
>> https://nixos.org/
>> http://www.gobolinux.org/
> 
> I have long lamented that's the direction the Ruby community took with
> Gems¹.
> 
> Gems support different versions installed on a system, as well as
> depending on specific versions. It makes sense for a programmer
> keeping track of different systems with changing APIs — Not having
> coinstalability means they'd have to patch all of their systems every
> time an API changes. Which happens on a daily basis in Ruby-land.
> 
> But supporting this as a whole is a mess. We try to make sure our
> system is a coherent unit, and that security and reliabilty fixes are
> applied to all or our packages (yes, that's the reason why I spent
> most of my Debian time in the past two weeks dealing with a single
> issue in Drupal7: Waiting for the right times to upload the fixes for
> stable / unstable / testing / bpo70 / bpo60).
> 
> Were we to support coinstallable multiple versions, we would have a
> much harder time supporting security.
> 
> For some cases (i.e. Daniel's suggestion of JQuery), the installed
> base and the incompatibilities between versions mean it could very
> well make sense. Right now, we *do* ship different JQuery versions,
> because several of our packages are incompatible with the systemwide
> one... But that's a bug, not a feature.
> 

nvm for Node.js is a bit like that too

I'm not suggesting that this is a practice that should be encouraged nor
given the same level of security support in every case.

However, there are cases (e.g. hundreds of packages containing jquery)
where it becomes the lesser evil: instead of having hundreds of copies
of non-standard JavaScript dependencies, we end up with maybe 3 or 4
supported versions of each important library.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535e9981.8040...@pocock.pro

Re: concurrent installation of different pkg versions

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 26/04/14 07:11, Steve Langasek wrote:
> On Sat, Apr 26, 2014 at 02:07:22PM +0900, Charles Plessy wrote:
>> Le Sat, Apr 26, 2014 at 11:41:17AM +0800, Paul Wise a ￩crit :
>>> On Sat, Apr 26, 2014 at 1:39 AM, Daniel Pocock wrote:
> 
>>>> a generalized approach is needed.
> 
>>> Multiple versions of a package seems undesirable to me, for the
>>> same reasons as static libraries and embedded code copies are
>>> undesirable.
> 
>> Hi Paul and everybody,
> 
>> it would be a great advantage for Debian over the other
>> distributions to have the capacity to install multiple versions
>> concurrently.
> 
> No, no it wouldn't.
> 
> This is how rpm handles library packages.  It's a horror show.
> 

There is a difference between doing this for "core" packages (e.g. C
libraries, system daemons, things that are sensitive to something in
/etc) and these independent eco-systems that exist around Python,
Java, JavaScript, etc.

Letting people install arbitrary versions of Python and then expect
all the Python scripts in a stable system to just work feels unreasonable.

However, letting them install additional versions of the Python
interpreter or some Python libraries that can be used on-demand, while
not impacting the default that is used would be less demanding on
Debian to support.  The same can be said for Java and JavaScript and
other things.

With JavaScript, the problem is particularly acute because the APIs
are more volatile.  It is harder to force all web packages to use a
single version of jQuery (or something else) if each upstream uses a
different version.  Debian either ends up dropping a lot of these web
packages or demanding that DDs who want to upload such things jump
through more hoops to patch their packages.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTW2TGAAoJEOm1uwJp1aqDJVwQAIXaaMRQtgkXxBE+3ZfOOGly
HFWQjJ+6sX1f2xfzUCok5wyhnhQNmSCSXQ5tknEvtvJAOC5Vmb4d3fhV8knIt6HZ
QEprwYDzPeOmpxtbLQpCrGOnsIG0WcJX3Sr5DUG9g6ObJvArNTX/7sZKYLdcDZWG
FVQCLFgD6BqCXC4b0MMO6GGmb8WvnM9qz7GVgwv3JaQdlwWHzkZZ5RNRGBrN7BGS
uLqVTMWblUa8qmmhGbSNbefaOOk8rjvuKlPH0mwctcZ03K44/fr0lkoRG41bGnx/
HztaOGmGG2xOOgSbKE5oOpCCy/J/5RK2VzcFAS4NQlry+vXdHt7A/3/4UFJPTCuS
OFnEnNu7+d8bC+YtoJgVOWGncQ587eOhGhGAVnNT4Jf3VLy6F15XGoOSQmUUgCjj
Avtpmz+lFjdCmv3zCji8yw4LV/2ZANHyAWwWQAIJSQtz0+B6kQCXtaRYtBmrpHKG
bp6OIhMKtRzfsx/1Vl27ZGvbFhC2ZpRflubyNasFBD1VXbIAvsAmwGCRG3863cWS
bWY4F7Kfq0HzzDPpgan9S3Tl3XEa/HEFfRzQBtsUDNQuO1rtvQwQufhjxpXvEp5o
NnNzPxfdQHj1d3MtxuYB+VAS30kwuE9jOd/ES8jdLhyrBzq0VnGEO9+QU/CJHzPq
DgEkOPG+e3Qp9ejVOs7N
=gLWq
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535b64c6.3090...@pocock.pro

Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

[Daniel Pocock]

On 26/04/14 01:31, Manuel A. Fernandez Montecelo wrote:
> 2014-04-26 00:08 Vincent Bernat:
>> ❦ 25 avril 2014 17:40 CEST, Neil Williams  :
>>
>>> Compared to that amount of work, stripping a few files from a tarball
>>> using uscan is utterly trivial and I don't see why it is a problem.
>>> It's quite a bit harder to do the right thing and persuade upstream to
>>> not include them.
>>
>> How to handle this with gbp?
> 
> I guess that one of the best things that you can do is to filter the
> files, like
> other cruft in the tarball coming from upstream, example:
> 
> http://anonscm.debian.org/gitweb/?p=pkg-sdl/packages/libsdl2.git;a=blob;f=debian/gbp.conf;h=b3a5a0939feff4f6578c8d617059ac7e740b778b;hb=HEAD
> 


The problem with this (or any other approach) is that DDs need to spend
much more time checking every upstream tarball and adapting the filter
rules each time they update the package.  This is especially true for
upstreams that are web-based projects where dealing with minified js is
like playing whack a mole.

Once again, my feeling is that it needs to be done pro-actively (by
scripts that track the upstream repository/releases) to assist the DD.
Many cases of minified js are easily spotted by certain patterns (like
long lines)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535b5824.9000...@pocock.pro

Re: Bits from the 7th Debian Groupware Meeting

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256




On 25/04/14 21:27, Guido Gnther wrote:
> The seventh Debian Groupware Meeting[1] was held in the
> LinuxHotel, Essen, Germany[2]. We had one remote hacker from NYC
> which brings the number of attendants up to 9. This is a short
> summary of what happened during the weekend:
> 
> * We decided to abandon Iceowl (based on the standalone calendar 
> sunbird) since Mozilla started to actively remove the code [3]. 
> Unfortunately this leaves us without a proper GUI stand alone
> calendar client with GSSAPI support.
> 
> * The icedove package got a major cleanup including the switch from
> CDBS to dh and the removal of the rebranding logic. This will
> hopefully allow us to better keep in sync with upstream. Carsten's
> git repo [4] usually carries the most up to date version and a
> automated build of these version is in the works.
> 
> * The sogo connector extension for icedove got uploaded and tested 
> including a wiki page[5][6]
> 





Brief feedback:

- - I'm using DAViCal package as server (for Calendar + Contacts)
  - upstream said "no more time to maintain" in 2012 but list activity
looks busier than ever
http://sourceforge.net/p/davical/mailman/davical-general/?viewmonth=201210


- - I've been using

  Icedove + Iceowl-extension (Lightning) + Sogo connector

 as calendar client


- - due to the limitations of Icedove addressbook UI (max 2 email
addresses per contact, etc) I tend to use Evolution as the client for
the Contact records


- - I've also tried the various Android clients against DAViCal,
including the new DAVdroid (which is open source) and I've tried the
not-really-open CardDAV-sync app


Thanks for making the Sogo connector a proper package

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTWrsAAAoJEOm1uwJp1aqDWskP/1RG/+57vYoK6qbdIYozkT/2
Ohil87V4M4kNJprn/SyopGoN6jA9OtCOeokKHPzmKd+trdObgRuzC2nk6qwpnKDY
e1tqFEAr36UdmwG6RYWmT8WniB6t8JaDoKeXOAa1LJCAjmlC3yLMeLhHPDy2rSP7
5X5y6QOVzkL6HbBQMqLiaj21BBGq8ModulN7yYh8KhAzVFuf7z9xhXmN0vSfm4On
GMF3Yq/j3ODUErkiDCDAQUTAAJTNlV2zb+NUeqEnJ01y6Ua6kvv9tfw2JPz37Kn4
+p+Jp7WKkLtebiEi1sifNtT9klLH74rRcwnPGJkgYIpiSgEeglb5MorTiXqyiNWu
sceUQfjCdRP5uQAqnup9RJrvxgCcFBbdiWpQMasBMw5EoKFmhsa9cUJyy842M6fr
mc2s83sTzkn3evJU7Yx5ZistzA9wuuwO9cxBS+hg/j10dk2lhtifO3JkmPPgwqRz
8JJMJhMlTjOAX+H6UTzWFuOdHqdTQXgYHFb7L8X84gL6bTciOHBJu6MeHbAMBt6F
j5egpVaqOOoJuEB/H2DxJ5Ar8Tm8OHrgq07H7ug8hDchcY307qVL46SwHXmSiClb
2vxZVTIluKnjv8wah7UBa318W3GMS5m+LpoB8KCAzBjX6erlyrYQya1/NKeKGdg3
dC8Jk7TOXNPaz3ZOml+6
=DGzE
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535abb00.1090...@pocock.pro

concurrent installation of different pkg versions

[Daniel Pocock]

With all the talk about removing jquery from source packages, one thing
that does arise is the question of how to support different jquery versions.

This is not just a JavaScript issue though.  Maybe we can have

  libjs-jquery-1.7
  libjs-jquery-1.10

and friends all installed concurrently.  Maybe it will be needed more
widely though (e.g. for some Java stuff too).  On the other hand, some
maintainers and security team naturally don't want the hassle of
supporting so many versions concurrently.  With so many upstreams now
including stuff like this, particularly in web software and the
emergence of node.js as well, maybe a generalized approach is needed.

There was even a debate about this on the backports list recently in the
context of how to support different versions of OpenStack (not installed
concurrently though, but just making perhaps the most recent 2 releases
available to users on wheezy)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535a9def.6050...@pocock.pro

Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 25/04/14 17:40, Neil Williams wrote:
> On Fri, 25 Apr 2014 16:47:41 +0200 Jeroen Dekkers
>  wrote:
> 
>> At Fri, 25 Apr 2014 14:58:35 +0200, Daniel Pocock wrote:
>>> There is no doubt in my mind that if the rules are not strict
>>> then sooner or later somebody will sneak something bad into
>>> some minified Javascript - maybe it will happen upstream and
>>> the DD won't even be aware of it.
>> 
>> Yes, and that's why javascript shipped in binary packages should
>> be build from source and we should not copy minified javascript
>> files from upstream. I think there isn't much disagreement about
>> that part. But if the minified javascript files in the upstream
>> tarball aren't used when building the binary packages because the
>> javascript libraries are already packaged in Debian, then it
>> isn't possible that something bad sneaks in our packages. So why
>> repack the upstream tarball?
>> 
>> I don't really see any value in repacking every upstream tarball
>> that has a minified copy of jQuery.
> 

When FTP masters approve a package from NEW, they might well see that
the js is not really in use - but somebody (upstream or maintainer)
may change something after 6 months and the js does get used

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTWpyKAAoJEOm1uwJp1aqDBtAP+wTz77QSufMFsbV9NrMCYlnk
UmRqSWuZLOxh20njiASkqKRK7QMdSQqlvHgr9jsl7CwVEUuoBF0AEe/+Agg0ZPg3
0vR3MndrRHr7feb3NjgQW7KcJzh4HOonMe7BCWRoXjMRfwP5FdG1Oy+ARrKIa/f4
p3b19qu8WxbcU3560Xpr/8jiuOIvQzje+J+QPCaq7xe7bdjs4BeEDAl4T0c6yH3H
vH8tAIheUGYIKf7y49EupLYwyi7iPnDIcAmlT5RCiUnjgrEJEhUYcq9uagvh+9Xj
0aqIE9Bvyq/F8Xm2gk8k1CJIztf6WbmUlLyN31qOpenVHz+Uc0qNhpma5LFmlBVR
+1EByOiS5qufEp51dBj+O09ZWT0y0JaVFTvpmNfT4nELutU23I0dNj2OhWtq6ROA
ENo5zOO4Lu7OU8PXWpeWaDvdUX7uFt5Xn7emIxOC2pwqHhSeAQdmadT/25c6lUZU
XeLzu4drfGgFnr3I6iIqZbkVV1gATtMZnBmRgrZQWvo3eCbvDTeglLxTyHNKf4Or
V9Cw1jzESQsWQ1pLWVGBMl86qmhqH93aTUvVwEZJU73yK2YQ9rCre1MNFOdWu/Ay
QurrBBUcOAFRVl0WuE5vhiXoN7qWNFwO8AkTkcnJxGT24Dn2nk04FYNEnYtYDepf
oIf9kGD5p8gy7VBD/5Qc
=J2Dn
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535a9c8a.60...@pocock.com.au

Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

[Daniel Pocock]

On 25/04/14 02:16, Manuel A. Fernandez Montecelo wrote:
>
> I don't think that we should go and do the tedious work of repack
> thousands of
> packages because of this, with no real benefit in terms of freedom (or
> any
> other) for our users -- provided that we depend and link to the canonical
> versions in the binary packages.
>

That is exactly why there is a GSoC project this year that involves
pro-actively and automatically creating repackaged upstream tarballs -
the focus is on Java, but some of these solutions can be generalized

 
http://danielpocock.com/automatically-creating-repackaged-upstream-tarballs-for-debian

so that DDs can just grab a clean tarball to work with whenever they
need to, automatically see a summary of new or changed non-free files
between upstream tags, etc

There is no doubt in my mind that if the rules are not strict then
sooner or later somebody will sneak something bad into some minified
Javascript - maybe it will happen upstream and the DD won't even be
aware of it.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535a5bfb.7070...@pocock.pro

Bug#745640: ITP: hazelcast - distributed cache

[Daniel Pocock]

Package: wnpp
Severity: wishlist
Owner: Daniel Pocock 
X-Debbugs-CC: debian-j...@lists.debian.org,debian-devel@lists.debian.org

(Would appreciate feedback from other Java users)

Brief: Hazelcast claims to be quite simple and powerful at the same
time.  Well documented.  Not using millions of dependencies from Maven,
all but two are already packaged.

Upstream:

  http://www.hazelcast.org

Source:

  https://github.com/hazelcast/hazelcast

License:

  Apache 2 License

Hazelcast is a clustering and highly scalable data distribution platform
for Java.

With its various distributed data structures, distributed caching
capabilities, elastic nature, memcache support, integration with Spring
and Hibernate and more importantly with so many happy users, Hazelcast
is feature-rich, enterprise-ready and developer-friendly in-memory data
grid solution.
Features:

Distributed implementations of java.util.{Queue, Set, List, Map}
Distributed implementation of java.util.concurrency.locks.Lock
Distributed implementation of java.util.concurrent.ExecutorService
Distributed MultiMap for one-to-many relationships
Distributed Topic for publish/subscribe messaging
Synchronous (write-through) and asynchronous (write-behind) persistence
Transaction support
Socket level encryption support for secure clusters
Second level cache provider for Hibernate
Monitoring and management of the cluster via JMX
Dynamic HTTP session clustering
Support for cluster info and membership events
Dynamic discovery, scaling, partitioning with backups and fail-over


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5357f6bb.1000...@pocock.pro

Re: automatically maintaining/tracking repackaged upstream tarballs

[Daniel Pocock]

On 23/04/14 10:07, Adam D. Barratt wrote:
> On 2014-04-23 8:27, Daniel Pocock wrote:
>> - uscan is only for existing packages
>
> No, it's not.

>From the man page:


SYNOPSIS
   uscan [options] [path-to-debian-source-packages ...]



could be more verbose:

uscan [options] [path-to-debian-source-packages ...]

uscan [options] --watchfile 


>
>> - should it be generalized to also
>> read directly from watch files that are not in a source package?
>
> $ cat tempwatch
> version=3
> http://ftp.gnome.org/pub/GNOME/sources/anjal/([\d\.]+)/anjal-([\d\.]+)\.tar\.gz
>
>
> $ uscan --watchfile tempwatch --package anjal --upstream-version 0
> --download
> anjal: Newer version (0.3.2) available on remote site:
>   http://ftp.gnome.org/pub/GNOME/sources/anjal/0.3/anjal-0.3.2.tar.gz
>   (local version is 0)
> anjal: Successfully downloaded updated package anjal-0.3.2.tar.gz
> and symlinked anjal_0.3.2.orig.tar.gz to it
>
> Regards,
>
> Adam
>
>


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53577e5d.4070...@pocock.pro

Re: automatically maintaining/tracking repackaged upstream tarballs

[Daniel Pocock]

On 23/04/14 01:09, Paul Wise wrote:
> On Wed, Apr 23, 2014 at 4:40 AM, Daniel Pocock wrote:
>
>> Given all the recent issues with popular packages containing minified
>> JavaScript and other sourceless files, I'm hoping to get feedback from
>> people about how the solution can be generalized to help as many
>> developers as possible.
> You may have missed the fact that uscan now supports removing files
> specified by the Files-Excluded field in debian/copyright when it
> repacks archives.
>
>> In the Java world, some of these things stick out like a sore thumb
>> (e.g. copies of junit or other *.jar files in upstream tarball) - it is
>> not hard to extrapolate this to match other patterns though.
> If they are automatically detectable, please submit bugs or patches to
> lintian about support for detecting them.
>

Some of this is in "wishlist" territory though:

- could/should uscan be run centrally, e.g. creating a pool of +dfsg
tarballs on alioth?

- uscan is only for existing packages - should it be generalized to also
read directly from watch files that are not in a source package?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53576b60.7070...@pocock.pro

automatically maintaining/tracking repackaged upstream tarballs

[Daniel Pocock]

I've just added some comments on my blog about tracking upstream
tarballs that need to be repackaged and automating whatever we can:

http://danielpocock.com/automatically-creating-repackaged-upstream-tarballs-for-debian

Given all the recent issues with popular packages containing minified
JavaScript and other sourceless files, I'm hoping to get feedback from
people about how the solution can be generalized to help as many
developers as possible.

In the Java world, some of these things stick out like a sore thumb
(e.g. copies of junit or other *.jar files in upstream tarball) - it is
not hard to extrapolate this to match other patterns though.

Regards,

Daniel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5356d3c5.5090...@pocock.pro

Re: default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

On 06/04/14 17:38, Tzafrir Cohen wrote:
> On Wed, Apr 02, 2014 at 01:33:15PM +0200, Martín Ferrari wrote:
>> On 30/03/14 15:20, Jonas Smedegaard wrote:
>>
>>> Please use https://wiki.debian.org/UnifiedCommunications as starting 
>>> point.  There is already link to a (mini-)HOWTO on some server setup, 
>>> but if that does not adequately cover conference calls (I haven't tried 
>>> yet myself) then consider extending that wiki page instead of sharing 
>>> details here ;-)
>>
>> What I see missing from the Wiki page and this discussion are other SIP
>> clients, like linphone, Yate client, SFLphone, etc. Coincidentally,
>> linphone and Yate are the best I have found so far. Each one with its
>> own limitations and strenghts.
> 
> Go ahead and add them to the wiki. I occasionally use linphone though
> find its interface lacking. SFLphone is likewise rough. I have not
> managed to get anything useful done with yate-client.
> 
>>
>> At the same time, my experience with Jitsi was not great. I have just
>> installed it again to try it out, and it just fails to connect to any of
>> my accounts, I am guessing it is choking on IPv6. 
> 
> Are there any other clients with IPv6 issues?
> 

Jisti IPv6 problems?  They are supposed to be one of the leaders in
things like that, you may want to ask on their mailing list

http://www.internetsociety.org/deploy360/blog/2013/03/video-emil-ivov-about-jitsi-a-voip-softphone-supporting-ipv6-and-dnssec/

repro SIP proxy fully supports IPv6 on the server side and is a good
platform to test against.

Lumicall doesn't support IPv6 at all though


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534192eb.7010...@pocock.com.au

default contact/address book for jessie?

[Daniel Pocock]

As mentioned in Tincho's recent email on the RTC/VoIP/IM client thread,
none of the clients have great address book integration

But what is the address book strategy itself?

Is there a different solution per desktop?  E.g. Gnome seems to have
Evolution and Evolution Data Server.  I have found that in wheezy, they
are not working reliably with CardDAV - http://bugs.debian.org/740911 -
this limits their interaction with mobile devices, etc

Icedove remains popular no matter which desktop is in use.  Its address
book only supports two email addresses per contact and doesn't support
the same set of phone numbers that Evolution supports.  Accessing a
single address book in a CardDAV server using both Icedove and Evolution
is a pain, e.g. saving a record in Icedove can lose some of the email
addresses stored by Evolution.

I would love to try and help get the RTC clients working well with
address books, click to dial, etc.  We already have sipdialer in a
package and there is an Icedove plugin (not yet packaged) that can make
address book links clickable URIs that invoke sipdialer.  However, all
of these things are just pieces of the puzzle and they depend on having
a useable address book.

To make this more confusing, some protocols (e.g. XMPP) store server
side address books/buddy lists.  Commercial cloud services obviously
love to encourage their users to move all data to their hosted address
books but Debian, as an organization that thinks about what is best in
technical terms and for the user, may be able to look at a wider range
of options that don't involve using the cloud by default.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/533c0621.1040...@pocock.pro

Re: Adiscon LogAnalyzer? rsyslog + mongodb?

[Daniel Pocock]

On 05/03/14 11:07, Daniel Pocock wrote:
> On 05/03/14 09:09, Florian Ernst wrote:
>> Hello all,
>>
>> On Tue, Mar 04, 2014 at 03:49:25PM +0100, Daniel Pocock wrote:
>>> The rsyslog mongodb output module and the PHP mongodb modules are now in
>>> wheezy-backports.  This would appear to be sufficient to do something like:
>>>
>>> rsyslog => mongodb => loganalyzer
>>>
>>> Has anybody else tried that or does anybody have any comments on it (or
>>> recommended alternatives)?
>> That actually did work for a time, but something broke starting with
>> rsyslog 7.4.0-1. Since then the format of the data dumped into mongodb
>> doesn't match what tools like loganalyzer expect, cf. #721277 / #728827.
>> As I was merely experimenting with it I didn't follow up any further.
> 
> Some of this looks like documentation bugs and/or problems with the
> default config rather than mongodb integration itself
> 
> LogAnalyzer and rsyslog are from the same upstream too, so I would be
> surprised if they would not have them working together
> 
> I had a look at the Git history for the ommongodb, does anything stand
> out here?
> 
> https://github.com/rsyslog/rsyslog/commits/master/plugins/ommongodb
> 
> You state the problem started with 7.4.0-1 - could you comment on the
> previous set of versions that you had working (both rsyslog and
> LogAnalyzer versions)?
> 
> 


Brief follow up:

LogAnalyzer is now packaged

rsyslog 7.4.8 in testing and wheezy-backports solves the problem
described by Florian, so a complete rsyslog/MongoDB/LogAnalyzer is now
quite trivial to setup on wheezy or jessie.  Details in README.Debian


http://packages.qa.debian.org/l/loganalyzer.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5339bb17.8050...@pocock.pro

Re: default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

On 31/03/14 15:31, Jonas Smedegaard wrote:
> Quoting Daniel Pocock (2014-03-31 15:11:06)
>> On 31/03/14 14:48, Josselin Mouette wrote:
>>> Le lundi 31 mars 2014 à 14:15 +0200, Daniel Pocock a écrit : 
>>>> The Jitsi people have done that work.  They may also be willing to 
>>>> take steps towards achieving better desktop integration, maybe not 
>>>> perfectly, but maybe sufficient to give the best all-round user 
>>>> experience.  Right now, there is time to discuss that with them with 
>>>> a realistic possibility that it would meet our needs for Jessie
>>> Are they willing to put their work in the form of a Telepathy 
>>> backend?
>>>
>> Why not ask them directly?
>>
>> However, it would also be helpful to clarify whether Telepathy will 
>> even be a priority if XFCE remains the default desktop
> Please aim not only for defaults.
>
> It is relevant to care about the major desktops - i.e. those we offer 
> initial install CDs for.

At the moment, the default for a lot of users is a non-free solution
that cares little for GNOME or any other free desktop.

I, too, feel that having a nice Telepathy-based solution would be a
positive thing - but I haven't seen any evidence that anybody has
committed to develop it before the Jessie freeze.  If that was to change
I'd be more than happy to test it and evaluate it on its merits and
provide whatever feedback and encouragement I could.

That said, if Jitsi (or one of the other free softphones) does manage to
expand the free communication userbase significantly and keep us in
touch with the WebRTC world, this may provide more motivation for the
GNOME Project and others to rally around standards like TURN and then
people will have a nice Telepathy-based solution for Jessie+1



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/533978f7.3080...@pocock.pro

Re: default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

On 31/03/14 14:48, Josselin Mouette wrote:
> Le lundi 31 mars 2014 à 14:15 +0200, Daniel Pocock a écrit : 
>> The Jitsi people have done that work.  They may also be willing to take
>> steps towards achieving better desktop integration, maybe not perfectly,
>> but maybe sufficient to give the best all-round user experience.  Right
>> now, there is time to discuss that with them with a realistic
>> possibility that it would meet our needs for Jessie
> Are they willing to put their work in the form of a Telepathy backend?
>

Why not ask them directly?

However, it would also be helpful to clarify whether Telepathy will even
be a priority if XFCE remains the default desktop



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5339696a.8090...@pocock.pro

Re: default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

On 31/03/14 13:29, Josselin Mouette wrote:
> Le lundi 31 mars 2014 à 12:37 +0200, Daniel Pocock a écrit : 
>> Just to clarify, it is not mandatory to install any of Empathy at all
>> when installing a GNOME desktop and the whole of Empathy could be left
>> out if GNOME is the desktop and another client (like Jitsi or Pidgin)
>> was preferred by the Debian community?
> You can use any software you like with GNOME. But AFAIK only Empathy is
> based on Telepathy, which means only Empathy gets integration with
> GNOME. Only Telepathy accounts will be started up automatically and
> their conversations integrated in the shell.
>
> I agree that Empathy lacks things as a SIP client. But I strongly
> disagree with the idea of moving away from it as the default IM client
> for GNOME. If SIP support in Empathy is not ready for jessie, we can
> still remove the SIP parts and let the user install a SIP client of her
> choice.

The problems with Empathy are not specific to SIP

Most of the problems are the same for XMPP

e.g. a TURN server to relay media across unfriendly NAT routers can be
used to support any type of media stream for a SIP call, an XMPP webcam
session or a pure WebRTC browser session.  Empathy doesn't currently
support standard TURN for any protocol (except a special case for Google
Talk users) and as Simon explained in his email, there is work involved
to change that.

The Jitsi people have done that work.  They may also be willing to take
steps towards achieving better desktop integration, maybe not perfectly,
but maybe sufficient to give the best all-round user experience.  Right
now, there is time to discuss that with them with a realistic
possibility that it would meet our needs for Jessie

However, we need to be willing to say that if they are the first (or
only) ones who do the work and hit that threshold before November, we
will give them a fair go



>> If developers were keen to help and spend time in this area, would it be
>> better to spend that effort on getting Jitsi (or another softphone) to
>> work more smoothly within GNOME or to get Empathy to fill in the gaps
>> discussed in this email or something else?
> Improving the state of the SIP Telepathy stack is definitely the best
> way to go for our users. But back in squeeze, such a thing did not exist
> and we shipped a different client by default for SIP.

Simon has already explained that development on SIP has stopped and that
development of TURN support (for SIP or XMPP) doesn't have any immediate
resources.

How do you propose to resolve that?

Arguing that it is the "best way to go for our users" doesn't make new
development happen.


> I would definitely object to shipping one based on Java, though, unless
> it can work with GCJ.
>

That, too, is another example of making a statement about something
without giving any reasons for it.  Please be more specific and then
maybe people can address your concerns.

Given the time between now and the freeze, I think it would be quite
reasonable to send requests like this (please clarify GCJ support) to
the Jitsi users list




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53395c75.7000...@pocock.pro

Re: default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

On 31/03/14 12:12, Simon McVittie wrote:
> On 31/03/14 10:27, Josselin Mouette wrote:
>> Le dimanche 30 mars 2014 à 11:04 +0200, Daniel Pocock a écrit : 
>>> Currently, Empathy is installed by default
> I think you might be conflating "present in a default desktop
> installation" with "recommended by the project for all of its possible
> functionality". IIRC we install nano and nvi by default, but I think
> most DDs would recommend emacs, vim and/or a GUI editor over either of
> those for many purposes :-)
>
>> Empathy is the default for GNOME, and I do not see a convincing reason
>> to change that.
> 
>
> Empathy is a simple UI for text chat, presence, file transfer and basic
> VoIP with excellent GNOME integration. It is appropriate to include it
> in some GNOME metapackage; I have no opinion on whether it should be in
> a tasksel-driven installation of Debian-with-GNOME[1].

Just to clarify, it is not mandatory to install any of Empathy at all
when installing a GNOME desktop and the whole of Empathy could be left
out if GNOME is the desktop and another client (like Jitsi or Pidgin)
was preferred by the Debian community?

>
> It is not currently a replacement for a fully-featured telephony stack:
> if you pick a random high-quality SIP implementation, it probably does
> several things that Empathy/Telepathy don't. Users with "enterprise"
> VoIP requirements are likely to be better off with something else. I
> have not assessed whether Jitsi is the correct "something else", but
> it's one possibility.
>
> Would it address your concerns about Empathy if the gnome metapackage's
> dependency on telepathy-rakia was weakened to Suggests, resulting in
> Empathy lacking SIP support in a default Debian-with-GNOME installation?

Quite the opposite - if somebody does choose Empathy, I'm quite happy
for them to automatically benefit from telepathy-rakia if that is the
only option for SIP support within Empathy.  If there were two possible
SIP modules for Empathy, then it would be nice to have a way to choose
and not be locked in to one of them.

The bigger worry is choosing things like

a) which client handles the xmpp: and sip: URIs by default.
b) should the client run automatically on login (with an easy way for
users to disable it) and if so, which client

> 
>
> 
>
> Like Pidgin, Telepathy primarily comes from an "instant messaging"
> background/history: it mainly competes with Pidgin, Google Talk, Skype
> etc. The fact that some of its supported protocols can also be seen as
> competing with the PSTN is currently secondary.

The XMPP support is quite effective and compelling too, as long as TURN
is not required for an audio/video call.  I've used Empathy a lot for XMPP.

> We don't currently have enough developer time to be trying to compete
> with a fully-featured telephony stack (and in particular, the former
> primary maintainer of our SIP implementation, which was never
> particularly comprehensive anyway, is no longer active). Anyone who
> wants to close the gap is more than welcome to help us.
>
> In particular, we would love to see:
>
> * an upstream maintainer for our SIP implementation and the library
>   behind it (telepathy-rakia + sofia-sip), or a new SIP connection
>   manager replacing Rakia using a more actively-maintained library

Just some comments on that:
a) reSIProcate is an excellent choice for a SIP stack, but as it is C++,
I don't know if you would go with it
b) Asterisk recently moved to PJSIP, so that might also be a better
choice than Sofia SIP
c) the FreeSWITCH people have forked Sofia SIP, so if there is no other
option, then it may be desirable to get in sync with their fork then
there will be a higher chance of packaging FreeSWITCH and also a higher
chance of keeping up to date with security

> * a reasonable UI design, and the implementation to back it up, for
>   out-of-band configuration of TURN servers and TURN credentials
>
> * a XEP for automatic provisioning of TURN credentials from XMPP
>   servers (functionality equivalent to what telepathy-gabble supports
>   for Google Talk), so that users of XMPP services other than Google
>   Talk can use their service's TURN servers transparently
>
> * encrypted RTP via keys negotiated through the server
>   (trusting the server - more trust involved than full end-to-end
>   security, but also much much easier)

WebRTC expects DTLS-SRTP negotiation.  Many users also want ZRTP. 
Libraries are available for both, but there is work involved to get it
into Empathy.

> * full end-to-end security (fair warning: this is Hard, and unlikely
>   to be a good project for beginners - try something else first)
>
> but for any of those to happen, someone else i

Re: default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

On 31/03/14 11:27, Josselin Mouette wrote:
> Le dimanche 30 mars 2014 à 11:04 +0200, Daniel Pocock a écrit : 
>> Currently, Empathy is installed by default
> Empathy is the default for GNOME, and I do not see a convincing reason
> to change that.
>
> The default for Xfce (which is currently the default desktop) should be
> decided by the Xfce maintainers.

Why is that a decision for the XFCE or GNOME maintainers?

Why should the maintainers of the desktop drag down the VoIP/RTC
experience for everybody to push their own pet projects even if it is
only suitable for limited use cases or violates the privacy expectations
of our users (as is the case with Empathy)?

Why should the Debian community not be free to mix and match those
components that are best suited for the task?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53394029.1020...@pocock.pro

Re: default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 30/03/14 20:53, Jonas Smedegaard wrote:
> Quoting Tzafrir Cohen (2014-03-30 19:15:04)
>> On Sun, Mar 30, 2014 at 07:24:15PM +0200, Daniel Pocock wrote:
>>> On 30/03/14 16:54, Jonas Smedegaard wrote:
>>>> Quoting Daniel Pocock (2014-03-30 16:31:18)
>>>>> Jitsi does IM/chat too, I just didn't emphasize that so
>>>>> mcuh.
>>>> 
>>>> Please add "T" in the relevant "TAV" fields at 
>>>> https://wiki.debian.org/UnifiedCommunications/ClientSoftwareComparison
>>>>
>>>> 
- - and while at it please also add info about JSCommunicator :-)
>>>> 
>>> 
>>> That is a trick question - many of the features of
>>> JSCommunicator are provided by the media stack in the browser
>>> or by JsSIP
>>> 
>>> E.g. if a browser supports Opus, JSCommunicator will use it.
>>> If not, it doesn't actually know or care.
>> 
>> So this page needs some entries for browsers?
> 
> Please don't: Let's keep it a two-dimensional matrix.
> 
> Track browser features in a separate wiki page if you find that
> relevant (and, for comparison, one on how well desktop environments
> integrates a volume control as part of their GUI, and one on which
> integrated computers has graphics drivers with XVIDEO supported X11
> drivers, etc.).
> 

To maintain the correct focus here, it is probably more relevant to
track browser features from the WebRTC specs rather than all browser
features in general.

Some things are standard as per the spec and all browsers implement
them (e.g. the G.711 codec, AVPF, ICE)

There has been variation in the SRTP style and the video codecs but
that will hopefully converge.

All of this could be summarised by a line in the table for "WebRTC
spec" rather than one line per browser.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTOGl6AAoJEOm1uwJp1aqDWKsP/3K3FiS01/1ibU0DTSLeNxVk
/6HW/pFmnykQlWwg25Q3TBPaEBlhTqjiidpMTQ1zev50UzbNZt1nmWTlmwWb0Eg2
crOvjErfm4of+pdQeqq7r+bAVOk8lX80QYxUveTzPDOuyB7QJgmRw5PzI7JaoUxc
rLKDaqJLnhgj16UJJfdg7ECgLGxFVYxudb82oQIXHfDAoiWY0QpzABge/uvO9r10
8Y/IgPkrBEcTmZO6Gfdu1P0cE2P7+UZ01CnV10MTJyqv1txgPQeKpkLwxMwK8NVw
O03jLiVNLjfyKCr5HHbtPyXjZSYWlrBSUpwxEXefwjF+mCErGnolQjuIjaP7puJa
mSOjlS5DwUPSmNkinydwCY3/0Ho6HPf5BE0esG1iddcN1b4yDnsKm7s//NJUviad
sVCS9uDUiw+mx53LxSowWtwoIfcpEbWR7lMaBnnubdbBuFHdfr3oGKaC+uHuwbb7
4amXJUy+i7Ch18RoKR3zrO6SAuYwmjjIx1/Xzk7czZqAXVr3ZqyPUe2+1cxJl1My
7hfUuvXgJkG3A6BgDMwMkRRnIm1jCCi3R0VAH2jUQyd6aG6npO0ODOFvTGTl+zx1
KSgvcfIuaL4lQjXzrWutpPPwP2golnknuX2LkaCZG4TghZJ22epwq3z6qY9uC2Bv
G3Q13Ae9pG/UlYwvw0qP
=aG2+
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5338697a.2010...@pocock.pro

Re: default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 30/03/14 16:54, Jonas Smedegaard wrote:
> Quoting Daniel Pocock (2014-03-30 16:31:18)
>> Jitsi does IM/chat too, I just didn't emphasize that so mcuh.
> 
> Please add "T" in the relevant "TAV" fields at 
> https://wiki.debian.org/UnifiedCommunications/ClientSoftwareComparison
> - and while at it please also add info about JSCommunicator :-)
> 

That is a trick question - many of the features of JSCommunicator are
provided by the media stack in the browser or by JsSIP

E.g. if a browser supports Opus, JSCommunicator will use it.  If not,
it doesn't actually know or care.



> 
> Others: Please add what you know of relevant bits about your pet
> voip clients to above wiki page.
> 
> 
> - Jonas
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTOFM/AAoJEOm1uwJp1aqD+DQP/1r5cOO8l9etBKfs79kcHgqb
oGWgciDSTHyRRhdKdWzNsMQuxWioPABlwOl1jnuB5cOWO7C8dAUVyNw0oTnRAwXs
Sf3lze9Wzc/OwzLnsqAjrORh0av43xkqAnJBWNYa2elpSg5goMLS1DMmsN4OKFma
sW4Fj0jaJzX7B4fkQ48qPhvX8IIrakxtw6LGa2mA83EasQGZreLe2fcRfcAxSMrk
da9CpeNc/7YPWLLhbBPbOdCLZp6iw7NyIWlIOwM7z1fW3BeN9hTsMgVQm4N+pimC
3/2BeGoU9wome6hUH3ODg8qDRIBufO+QhxWW5XPuprim8amVRFwpamkaMnxbuSNl
IERW9ITygUyHJfs1ZM/x0p4YTOBleBLNUE1B2nO6OLUg2uOog6AGJmSwMlLzVbbE
DYCEJrk1q6ZmJjeDdfgZneMZ3xV3zrf+vio0l4UsRdiRHq02L19CLZWBlP83Cj5o
LAL05LBVRIxuXZdTgvYXodzCLqQQTswr8ZCJMTxHI8Hg991lmwO1hbnhhMqyrb3x
78Ukt/82RxXplcIuRn2Tk4MgoQXNZJ5QBeDnXbbyIAIw8fsI0e2OGb3V4mu83f8T
WX1rcfXdIoxDA4bIW0YfGm3Y1cDrug3naSlZCRdlKXqp3nuJhSE/cO6l52tySThr
lAy2E04AU5xJgqS/i4Xh
=7lGK
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5338533f.1070...@pocock.pro

Re: default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

On 30/03/14 16:09, Thomas Goirand wrote:
> On 03/30/2014 06:55 PM, Matthias Urlichs wrote:
>> Hi,
>>
>> Thomas Goirand:
>>> P.S: I don't really care which client is the default, because I find the
>>> concept of default app bad in itself, and I think users should be given
>>> the choice, and it isn't the role of a distribution to choose for its
>>> users. However, if we *have* to have a default, probably Jitsi is a good
>>> choice.
>>>
>> Most new users don't know enough to choose.
> 
> Excuse me to say it this way, but ... NO!
> 

Actually, many users will use what their friends are using, that's how
they end up using solutions like WhatsApp that uses their phone's IMEI
number as a password for XMPP.

We should make it easy for people to choose - and Debian does a great
job of that.  But we should have a good default too.

The default needs to work for the widest number of use cases.

> My point above was only that I don't think it's a good idea to install
> so many stuff by default. It bloats the installer and make it difficult
> to fit on the 700 MB of the CD1. I very much prefer a more minimalistic
> approach.

That is a different issue.  If it is too much for a single CD

a) lets have it on DVD1

b) lets have some way to get stuff like this automatically if the user
supplements CD1 with a network mirror

c) or maybe we can have different CD sets, e.g. a set of disks for
"deskop / end user" and a different set of disks for "developer / sysadmin"

> Empathy isn't only doing VoIP, it does lots of other (chat) protocol,
> and trying to compare it to Jitsi doesn't help IMO. I myself prefer

Jitsi does IM/chat too, I just didn't emphasize that so mcuh.

> pidgin + Ekiga than just Empathy (and I find Jitsi too heavy and slow),
> but that's just me. Ask 5 persons, and probably you will get 5 different
> answers (including Ekiga, Skype, Linphone, Mumble, you-name-it). So why
> even bothering installing anything by default? In the case of Empathy,
> my understanding was that the reason it was there, is because it's
> designed to integrate with Gnome. I don't think we can say the same
> thing with Jitsi (which integrates with nothing).

Quite simply, when talking about a communications tool, I feel the
default option needs to be able to communicate with the widest number of
people.

Jitsi currently does that - despite all the legitimate concerns about
disk space, GNOME UI, Java, whatever.  It maximizes the number of people
who can contact each other.

By enabling the widest number of people to inter-operate, we help create
the foundation for a world of free VoIP.  Solutions like Empathy can
grow into that at their own pace and the developers will have more
motivation to fill those gaps (like DTLS-SRTP support) when there is a
more active body of users to tap into.

In any case, please feel free to add the other options into the wiki:


  https://wiki.debian.org/UnifiedCommunications/ClientSoftwareComparison

> I also find it a pain to add the Jitsi dependencies in the default setup:
> 
> Depends: libjitsi-jni (>= 2.4.4997-1), default-jre | java6-runtime,
> libunixsocket-java, libhttpcore-java, liblog4j1.2-java, libjmdns-java,
> libdnsjava-java, libmac-widgets-java, libfelix-main-java,
> libfelix-framework-java, libhttpclient-java, libhttpmime-java,
> libcommons-logging-java, libcommons-codec-java, libcommons-lang3-java,
> liblaf-widget-java, libdbus-java, libxpp3-java, libjzlib-java,
> libbcprov-java, libjna-java, libjgoodies-forms-java,
> libjson-simple-java, libjcalendar-java
> 
> And yes, Java sux! :/ And it's going to take *a lot* of space on the
> CD1. This should therefore be discussed on the debian-cd list as well. I
> don't think that only the argument "it's better because of this or that
> feature" would be the only one (unfortunately).
> 

I don't work exclusively with Java myself and I'm well aware of the
benefits and disadvantages.

Quite simply, it gives us a DFSG-compliant solution now.  Thanks to
Java, it brings that solution to people who are not even ready to change
their whole OS and they can communicate with people who are 100%
Debian/free-software users.

Whatever you think about Java, it is free software and people are
welcome to develop alternatives.  Some of the building blocks are
already out there in C or C++, like the reSIProcate project (which
includes reTurn for TURN and reflow for RTP media now).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53382ab6.3030...@pocock.com.au

Re: default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

On 30/03/14 15:45, Michael Banck wrote:
> Hi,
> 
> On Sun, Mar 30, 2014 at 11:49:08AM +0200, Daniel Pocock wrote:
>>> If you want GNOME to switch from Empathy to jitsi I think that would
>>> be a conversation that should be had with upstream, not with Debian. I
>>> doubt they would be interested in it due to the Java requirement
>>> though.
>>
>> Whichever desktop is in use, why does Debian have to accept what
>> upstream recommends as an IM/VoIP client if we know something else is
>> going to give users far greater chance of success?
> 
> With respect to GNOME, you did not explain how well jitsi is blending
> into the GNOME3 desktop.
> 
> Is it using GTK3, does it have a GNOME3 branding?
> 

These are relevant considerations

However, in my view, these questions are much higher on the list of
priorities:

 - does it only talk to friends on the same LAN or anywhere?

 - is the communication secure (relative to alternatives)?

 - is it easy to set up?

 - does it empower other types of development (e.g. for
   people wanting to build WebRTC web applications) on
   a free platform?

To put it another way, the most widely used softphones are not GNOME
related either, millions of users are choosing them simply because they
appear to work regularly and they are very easy to set up.  Jitsi is
probably the most compelling competitor for those proprietary products
right now.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53382409.5010...@pocock.pro

Re: default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 30/03/14 12:57, Jonas Smedegaard wrote:
> Quoting Daniel Pocock (2014-03-30 11:04:31)
>> I'd like to propose that Jitsi be considered as the default
>> messaging, VoIP and webcam client for the next major Debian
>> release (jessie). This would mean it is installed by default in a
>> desktop install and it is the default handler for sip: and xmpp:
>> URIs.
>> 
>> Currently, Empathy is installed by default
>> 
>> There are several reasons I am suggesting this and it is possible
>> that Empathy could address some of them before the release freeze
>> in November but we should be completely prepared to go with Jitsi
>> if they continue to be the leaders in this area.
> 
> Thanks for all your tremendous work in this field, Daniel.
> 
> Is there some comparison available e.g. at our wiki?
> 
> I am thinking something like https://wiki.debian.org/Groupware - I
> know there is https://wiki.debian.org/UnifiedCommunications and a
> bunch of sub-pages but there I have located only install guides, no
> comparison, which I find essential for a discussion like you raise
> here.
> 

Done

  https://wiki.debian.org/UnifiedCommunications/ClientSoftwareComparison

> Putting it on wiki instead of summarizing in an email, you
> encourage contribution from others (I happen to use Pidgin, for
> example, and might attempt to fill in the bits for that in a
> comparison chart if it existed, but I don't feel knowledgeable
> enough to put up a chart myself - you seem quite knowledgeable and
> might even have the data already.

Please go ahead - I've just finished my own edits
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTOADVAAoJEOm1uwJp1aqDDkgP/3Gl14U0BgQAL2fyB2+5fmWe
JiIrlWebyrSBVL3RMAxEv1jCcKW16CmJ3NeQEfEqzsi4JlbQwPDooHrL/4r+hsm9
eSgxofEAeCnmRQT8vQVi2ZsaR39bb5kIEjH8wJkF911Z57hKGNLAcrUwm2inOjbR
wQbD/wsMyyDArM3K0oHi6I1awbNwLnLHivY+aXsy0p3Mvfcb6KXvi3DCQFjfJwlf
XZreLTxui+qH6jZ63L5dITi/qDiGpe5MN5uzIDvrGU2exeAgig60Du1Ph0OclQkS
N1T5sgt3MgK9uyQ7BIXdnphu1JdSB3D2+t6+6xczYd0XSWtez6WEDZ00L9pxPr4/
gNcUUIrmspWYQv7pVqq3Y2wMNb32/7wp6m4VK096QVA6EBleLTLsUCwiyG++Cx91
lLjQbkHuYbOVQBB5kYT2LMkFcBP0oBaJujnq62687r8eY5LJ+Ii3FMXkZR4cmfi6
2LofRow+/ru5OCZ4ML1OHwzfH85CC+xuBW6BQCK+Ab9H+/htMFym6Uvdim+c1M6l
HTkN+Yf8ecneDBj6ZmWM8LCP8nIFeLVbuQrR4FQgApyjp+/2Yc3xYZWsrC4Ts6hq
oJDZKHXd4gMYLOAjL+FMwTxwrrq7BIaltw3VxVVEKZo97MAjztXCJUpBlyDe4ysD
5gaFPDCBkX3aqTZ46uVy
=rd6W
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/533800d6.60...@pocock.pro

Re: default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

On 30/03/14 12:29, Thomas Goirand wrote:
> On 03/30/2014 05:04 PM, Daniel Pocock wrote:
>> ZRTP - peer to peer encryption, like PGP for VoIP.  Once again,
>> it has been in Jitsi for ages but is not in Empathy[7]
> 
> To me, this is the most important feature of them all, and is IMO
> mandatory nowadays. But do you know if Asterisk (or other VoIP servers)
> are configured to accept such important feature by default?
> 
> 
> On 03/30/2014 05:04 PM, Daniel Pocock wrote:
>>JitMeet multi-party video conferencing solution[8] for WebRTC
>>browsers
> 
> You should remove the "s" at browsers. It only supports Chrome(ium).

Most of my own WebRTC stuff started out only supporting Chromium but
Firefox support was not hard to add as well.  Chrome developers are also
moving to be more Firefox-like (e.g. using DTLS-SRTP and dropping SDES)
and that will force many projects to get in sync.

> By the way, do you know if it's easy to setup conference calls the way
> there is with JitMeet / Hangout, but without a web browser, eg directly
> on a VoIP software? Can Jitsi do that?
> 


http://packages.qa.debian.org/r/reconserver.html

is trivial to use and compiles cleanly on wheezy, proper backport coming
soon.

Asterisk has the MeetMe conferencing module

If you don't need packages, there are additional options like FreeSWITCH
conferencing.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5337fd7d.6040...@pocock.pro

Re: default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

On 30/03/14 11:22, Paul Wise wrote:
> On Sun, Mar 30, 2014 at 5:04 PM, Daniel Pocock wrote:
> 
>> Currently, Empathy is installed by default
> 
> The default desktop is now Xfce, which doesn't use Empathy.
> 
> http://metadata.ftp-master.debian.org/changelogs/main/t/tasksel/unstable_changelog

Their wiki doesn't emphasize any particular IM/VoIP client, although
Jitsi is mentioned there:

   https://wiki.xfce.org/recommendedapps

Even if no client is installed by the default window manager package's
declared dependencies, it is still quite reasonable to include an
IM/VoIP client (such as Jitsi) in task-desktop for example.

> 
> If you want GNOME to switch from Empathy to jitsi I think that would
> be a conversation that should be had with upstream, not with Debian. I
> doubt they would be interested in it due to the Java requirement
> though.

Whichever desktop is in use, why does Debian have to accept what
upstream recommends as an IM/VoIP client if we know something else is
going to give users far greater chance of success?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5337e894.1060...@pocock.pro

Re: FTPMaster position statement about package contents

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 28/03/14 22:14, Steve Langasek wrote:
> On Fri, Mar 28, 2014 at 09:49:44PM +0100, Bas Wijnen wrote:
>> On Thu, Mar 27, 2014 at 07:41:50PM -0700, Steve Langasek wrote:
>>> I can understand the ftp team's desire to sidestep any moral
>>> questions here, but in the process I think your guidelines have
>>> wound up vague and overbroad, as they suggest that as a project
>>> we will never take a stand for anything but only do what's
>>> safe.
> 
>> I think you are mistaken.  The statement says that before
>> uploading, we should ask the ftp team for advice.  Not that they
>> will always deny the upload.
> 
>> What it means, is that they don't want rigid rules where there
>> are problems when we get a new member from a new country, but
>> instead leave the decision to humans (the ftp team).  I think
>> that is very wise.
> 
> If your interpretation is correct, then the mail from Joerg in
> practice provides *no* new guidance, and the only reason the
> software in question is blocked from the archive is "because the
> ftp team says so".
> 
> That's an even worse policy than how I interpreted it.
> 


I find it relieving that when these things have to happen (as was
necessary after the proposal to package some controversial content)
Debian is able to discuss it and document the decision in public.

While not everybody will agree with the outcome, the process of
decision making and public documentation of the decision is much
better than the way secret lists of blocked websites are being
assembled in various countries that pretend to have free and
democratic values.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTN+ELAAoJEOm1uwJp1aqDzRUQAKKz/Vbcek5zdpsERN7M8BDF
culUU6a4zEDx85YCRgGngFITRf3OBLiZQAeeAqa4xpstMIDLdGv3FsNST4cvnl4D
YQoVEMgjtnAj1Svc4wrVBKOFPmEMpC3I2ADKB3tfEfEkewNOA9cjqh5Wzg4k/pRt
rNYD1KYI7+4K336Y1HQRnFCNN7GGoxigxF/qhkOJaJ/Xd12YDEj5V70EQF+7DC8A
bpSO7n0No/oIhSY962S0cL3q54emPcTWISJVQHcWcSqL6JS5M6ju8FiSVfnr1bAQ
kGVj/19RR/OvWBQ9yUzRnowGVtPEwrofxMW1tPTdxcPb56eo4F+is9sFOsTwXmdT
eVFe8CicWhCXHXU23LjOgRRHAUX3vxjKf0Wa2s4LqTQvG6zpB1c7A1NutOiX6zll
yJspegDhZrk/wR0H/XJ9G/HFZ90QRPbATalKqVTnGNs820dBTd4Ni9d95piXa0nz
bFfnEfgywWqXBvnUmy5kxuAEIC6PdjB+HmnDvDDZadjMwo/vzwEzrFgXTXHDDs7/
Jo8nXPGSAlHLBxhcPwGcl/X6aTvzK8/2x6drVp7fwLr26Fxq9TFCO1ze/nBsc2UO
VbI/jvg9w9P9Kw/vJHZC4mWY0rc4u7P2qgUxjrZaqf8vi+5IDOC9iLwA3CmKBn7D
MaWtx7hPPhnDGzH7wD0O
=XY1+
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5337e10b.2090...@pocock.pro

default messaging/VoIP client for Debian 8/Jessie

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



I'd like to propose that Jitsi be considered as the default messaging,
VoIP and webcam client for the next major Debian release (jessie).
This would mean it is installed by default in a desktop install and it
is the default handler for sip: and xmpp: URIs.

Currently, Empathy is installed by default

There are several reasons I am suggesting this and it is possible that
Empathy could address some of them before the release freeze in
November but we should be completely prepared to go with Jitsi if they
continue to be the leaders in this area.

 * Google dependency: Empathy is hard-coded[1] to use Google
   media relay (TURN) servers for NAT traversal.  It can't
   be configured to use a TURN server on a Debian server,
   even though we have three TURN servers packaged for our
   users.  This means that when Google shifts the goal posts
   (as they already did, ditching true XMPP to promote
   Google hangouts[2]) or when they have a service outage[3] then
   Debian's users are left high and dry.  There are also privacy
   concerns, Google themselves report a 120% increase in the amount
   of data they officially and knowingly give to their government[4].
   Jitsi supports any user-specified TURN server for XMPP and they
   plan to support TURN for SIP too.

 * Convenient NAPTR discovery.  Empathy does not autoconfigure
   itself with services (such as Debian.org's own SIP proxy) that
   have NAPTR records in DNS[5].  With Jitsi, this just works.

 * WebRTC integration (calling from browsers to Jitsi desktop).
   This depends on new media stream features (e.g. DTLS-SRTP and AVPF)
   that are not supported in Empathy yet[6].

 * ZRTP - peer to peer encryption, like PGP for VoIP.  Once again,
   it has been in Jitsi for ages but is not in Empathy[7]

 * Upstream.  Both Empathy and Jitsi upstreams are very
   good developers.  Jitsi seem to have an edge though.
   Just look at how quickly they turned out the
   JitMeet multi-party video conferencing solution[8] for WebRTC
   browsers - it is a phenomenal achievement and delivered
   in good time to help free software gain traction in the
   emerging WebRTC space before any vested interests try to
   monopolize the technology.

The whole real-time communications (RTC) space is very important for
free software in general.  If it fails to work conveniently and
reliably, the peer pressure of family and friends pull people back into
dangerous non-free solutions.  Some of these solutions are a threat to
the whole concept of free software on mainstream desktops.  With all
the recent attention on communications privacy, there has never been a
better time for Debian to try and fill this gap with a solution like
Jitsi on the front-end and the various free SIP/XMPP/TURN servers in
the back-end.

To put it simply, the Jitsi team are blazing a trail in this area and
a Debian initiative to install Jitsi on every desktop will give them
more momentum and ensure more people can talk to each other in line
with our agreed definition of freedom.

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704234
2.
https://www.eff.org/deeplinks/2013/05/google-abandons-open-standards-instant-messaging
3. http://www.cnet.com/news/outage-hits-google-talk-hangouts/
4. http://www.bbc.com/news/technology-26786593
5. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736149#10
6. http://lists.freedesktop.org/archives/telepathy/2012-June/006122.html
7. https://bugzilla.gnome.org/show_bug.cgi?id=589778
8. https://jitsi.org/Projects/JitMeet

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTN94bAAoJEOm1uwJp1aqDRkgP/0jKZ2GfrIIxTy70p8b5PFDo
e9KKTkDTEINpwAdeyP2BpX5BLTEtuzgRZh+AQi7HZHbPAfCq8Cf24FjJfQyY0AgC
jDpzuX05ahNExPbpWOW4OGwinJ4S3kaPG5/o/IQC66y9tUdH0Lrh8AIvmvEgIJ9j
K0Nb669heMCdrn77ihbk9MtJlGvCE1KVOnrg+SrQLSEE1HsXk8iTXlyoGfE2T/ho
24PxrKwhnjFoojIe0c2f/cMTMOL3prHyndYZB/Q86AiKExCow+6WtSwzb3po153i
USHFS/e+lA1+GquJXYiJq1FMUB+HiPaLer241yodqr7R5mqSD4igiF7/oQzywYId
OcxjqaLZVGxcqd5s+hmv2vCf3FXC21uDeBULZYP6TulELPGK1i6EJPpg0JqiWZbD
rE8Zs1a9W0zLOamc6jpMMx/rMC1Pml00Y69ek/c1uXW3YfxaEsiyV4cv+i99XU5B
hkkmQf5DbV+P3nQqblIkNPTydWlN/spsaLitWQsfr0cG3l4ZH+zCHKoNVl87g7Sy
CCv8FsnyhJy2wOdB//1OreDRmNK28UWwv+GM3Kf2/BI9oylbBmGbN8q3luy8KlQd
NHAledDQ0c2xEnCK0VF5NtOCQyY+cQriPcTUt1MSpq+m2mnqYj40VqBiDJITf/zz
xF+ESMftdl5n0cqmMNQJ
=UwwC
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5337de1f.9000...@pocock.pro

Re: trolls and Humans are *fundamentally incompatible* -> and you have proven it

[Daniel Pocock]

On 25/03/14 18:33, Milan P. Stanic wrote:
> On Tue, 2014-03-25 at 16:15, Jonathan Dowland wrote:
>> I was very proud of my fellow colleagues for not feeding the troll a
>> full 24 hours later. Thanks for breaking the record :(
> 
> I had a hope that the no one will answer OP. :(
> 
> 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53332d22.4010...@pocock.com.au

Re: debian-archive-keyring installing ubuntu keys?

[Daniel Pocock]

On 26/03/14 10:03, Adam D. Barratt wrote:
> On 2014-03-26 8:39, Daniel Pocock wrote:
>> I have a project that is building in the travis-ci.org environment
>> (based on Ubuntu)
> [...]
>> Unpacking debian-archive-keyring (from
>> .../debian-archive-keyring_2010.08.28_all.deb) ...
>> Setting up debian-archive-keyring (2010.08.28) ...
>
> That package is older than the version in squeeze (i.e. oldstable).
>
> However, even fetching the package from Ubuntu trivially shows that it
> does not contain any non-Debian keys:
>
> $ wget
> http://mirrors.kernel.org/ubuntu/pool/universe/d/debian-archive-keyring/debian-archive-keyring_2010.08.28_all.deb
> $ mkdir debtmp
> $ dpkg-deb -x debian-archive-keyring_2010.08.28_all.deb debtmp
> $ gpg --no-default-keyring --keyring
> debtmp/usr/share/keyrings/debian-archive-keyring.gpg --list-keys
>
> debtmp/usr/share/keyrings/debian-archive-keyring.gpg
> 
> pub   1024D/F42584E6 2008-04-06 [expired: 2012-05-15]
> uid  Lenny Stable Release Key
> 
>
> pub   4096R/55BE302B 2009-01-27 [expired: 2012-12-31]
> uid  Debian Archive Automatic Signing Key (5.0/lenny)
> 
>
> pub   2048R/6D849617 2009-01-24 [expired: 2013-01-23]
> uid  Debian-Volatile Archive Automatic Signing Key
> (5.0/lenny)
>
> pub   4096R/B98321F9 2010-08-07 [expires: 2017-08-05]
> uid  Squeeze Stable Release Key
> 
>
> pub   4096R/473041FA 2010-08-27 [expires: 2018-03-05]
> uid  Debian Archive Automatic Signing Key
> (6.0/squeeze) 
>
> $
>
>> " not changed
>> gpg: key FBB75451: "Ubuntu CD Image Automatic Signing Key
>> " not changed
>> gpg: Total number processed: 2
>> gpg:  unchanged: 2
>
> This suggests that you've got ubuntu-keyring installed in the
> environment.
>
> You'll notice that the messages all say "not changed". There are no
> new keys being added at this point. What's happening is this:
>
> if which apt-key > /dev/null; then
> apt-key update
> fi
>

Maybe that postinst script needs to
   echo "Summary of which keys are already on your system:"

so it is clear the output does not relate to the contents of the package.

> [from debian-archive-keyring's postinst]
>
> [...]
>> Is this simply because I'm trying to use packages from sid?  Or is this
>> "debian-archive-keyring" package at fault?
>
> As far as I can tell, neither of these is the case. If you don't want
> your environment to contain Ubuntu keys, don't install ubuntu-keyring
> in it.
>

In this case, I don't mind if the environment has Ubuntu keys, I just
wanted to make sure I could get the Debian keys as well

> I can't see how to easily tell from your setup exactly what's
> installed in the environment before your job started, or I'd supply a
> link.

I believe each travis-ci build environment starts out running the last
stable Ubuntu LTS (12.04)

I've just tweaked the build script some more, I tried:

a) dist-upgrade to saucy
b) install debian-archive-keyring from saucy
c) dist-upgrade to sid

but that fails too as it does not appear to be a valid upgrade path. 
I'll try the same thing but s/saucy/trusty

before_install:
 - sudo add-apt-repository -y "deb http://archive.ubuntu.com/ubuntu/
saucy main universe"
 - sudo apt-get update -qq
 - sudo apt-get dist-upgrade -qq
 - sudo add-apt-repository -y "deb http://http.debian.net/debian/ sid main"
 - sudo apt-get update -qq
 - sudo apt-get install -qq --force-yes debian-archive-keyring
 - sudo apt-get update -qq
 - sudo apt-get dist-upgrade -qq
 - sudo apt-get install -qq gperf libasio-dev libboost-dev libc-ares-dev
libdb++-dev libpopt-dev \
   libssl-dev perl libmysqlclient-dev libfreeradius-client-dev
libcppunit-dev autotools-dev \
   libpcre3-dev libxerces-c-dev curl libcajun-dev python-cxx-dev
libsipxtapi-dev libsrtp-dev


Latest build log

https://travis-ci.org/resiprocate/resiprocate/jobs/21574148


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53329a8e.9080...@pocock.com.au

debian-archive-keyring installing ubuntu keys?

[Daniel Pocock]

I have a project that is building in the travis-ci.org environment
(based on Ubuntu)

I added the following to .travis.yml to try and make it use packages
from sid:

 before_install:
  - sudo apt-get update -qq
  - sudo apt-get install -qq debian-archive-keyring
  - sudo add-apt-repository -y "deb http://http.debian.net/debian/ sid main"
  - sudo apt-get update -qq
  - sudo apt-get install -qq gperf libasio-dev libboost-dev
libc-ares-dev libdb++-dev 



The log shows the following output:

Unpacking debian-archive-keyring (from
.../debian-archive-keyring_2010.08.28_all.deb) ...
Setting up debian-archive-keyring (2010.08.28) ...
gpg: key 437D05B5: "Ubuntu Archive Automatic Signing Key
" not changed
gpg: key FBB75451: "Ubuntu CD Image Automatic Signing Key
" not changed
gpg: Total number processed: 2
gpg:  unchanged: 2

...

$ sudo apt-get update -qq
W: GPG error: http://http.debian.net sid InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 8B48AD6246925553
...
$ sudo apt-get install -qq gperf libasio-dev libboost-dev libc-ares-dev
libdb++-dev libpopt-dev libssl-dev ..
WARNING: The following packages cannot be authenticated!
  locales libnih-dbus1 libnih1 libc-dev-bin libc6-dev libc6 libdb5.3
perl .
  .
  .


Is this simply because I'm trying to use packages from sid?  Or is this
"debian-archive-keyring" package at fault?  My understanding is that
because the package has debian in the name, it will give me Debian
project keys.


Build log:
https://travis-ci.org/resiprocate/resiprocate/jobs/21572385


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53329253.4090...@pocock.com.au

Re: RTC project feedback/expectations (was: RTC login)

[Daniel Pocock]

On 13/03/14 17:08, chandrika parimoo wrote:
> Hello,
>
> I have been working with WebRTC for some time now and wanted to work
> on improving the current softphone feature of Debian WebRTC service,
> rtc.debian.org . In order to do so I need to
> familiarize myself with the existing features of the service and since
> it requires a developer login, I am unable to do so. I would like to
> know if there is some tester login so that I can proceed with the
> development.
> Also I would appreciate any suggestions from the Debian developers
> regarding the desirable features for the future version of the portal.
>

Chandrika is one of the applicants for GSoC[1]

I'll be providing a mock-up of https://rtc.debian.org for students to
test code against, either for WebRTC or traditional SIP.

It would be really useful for people to provide ideas about ways to
improve the service, either reply to this thread or create wishlist bugs
against libjs-jscommunicator (or in the upstream issue tracker)

There are already some wishlist items describe in the upstream bug tracker
  https://github.com/opentelecoms-org/jscommunicator/issues

1.
https://wiki.debian.org/SummerOfCode2014/Projects#SummerOfCode2014.2FProjects.2FWebRTC_portal_for_the_Debian_community.WebRTC_portal_for_the_Debian_community

Re: Adiscon LogAnalyzer? rsyslog + mongodb?

[Daniel Pocock]

On 05/03/14 09:09, Florian Ernst wrote:
> Hello all,
>
> On Tue, Mar 04, 2014 at 03:49:25PM +0100, Daniel Pocock wrote:
>> The rsyslog mongodb output module and the PHP mongodb modules are now in
>> wheezy-backports.  This would appear to be sufficient to do something like:
>>
>> rsyslog => mongodb => loganalyzer
>>
>> Has anybody else tried that or does anybody have any comments on it (or
>> recommended alternatives)?
> That actually did work for a time, but something broke starting with
> rsyslog 7.4.0-1. Since then the format of the data dumped into mongodb
> doesn't match what tools like loganalyzer expect, cf. #721277 / #728827.
> As I was merely experimenting with it I didn't follow up any further.

Some of this looks like documentation bugs and/or problems with the
default config rather than mongodb integration itself

LogAnalyzer and rsyslog are from the same upstream too, so I would be
surprised if they would not have them working together

I had a look at the Git history for the ommongodb, does anything stand
out here?

https://github.com/rsyslog/rsyslog/commits/master/plugins/ommongodb

You state the problem started with 7.4.0-1 - could you comment on the
previous set of versions that you had working (both rsyslog and
LogAnalyzer versions)?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5316f75c.3020...@pocock.pro

Re: Adiscon LogAnalyzer? rsyslog + mongodb?

[Daniel Pocock]

On 04/03/14 18:04, Nicolas Dandrimont wrote:
> * Daniel Pocock  [2014-03-04 15:49:25 +0100]:
>
>> I didn't see any existing package of LogAnalyzer from Adiscon, the
>> people who make rsyslog - is there any specific reason for not packaging
>> it or it is just not something anybody needed yet?  It is GPL:
>>
>> http://loganalyzer.adiscon.com/
>>
>> http://download.adiscon.com/loganalyzer/loganalyzer-3.6.5.tar.gz
>>
>> The rsyslog mongodb output module and the PHP mongodb modules are now in
>> wheezy-backports.  This would appear to be sufficient to do something like:
>>
>> rsyslog => mongodb => loganalyzer
>>
>> Has anybody else tried that or does anybody have any comments on it (or
>> recommended alternatives)?
>>
>> http://loganalyzer.adiscon.com/articles/using-mongodb-with-rsyslog-and-loganalyzer/
> Hi,
>
> At work, I have been investigating the ElasticSearch + Logstash[1] + Kibana[2]
> combo, which has been pretty solid in my tests so far (feeding it 10GB or so 
> of
> firewall logs a day, yes, that thing is noisy).
>
> There is no Debian packaging of that stack yet (the RFP of logstash is at 
> [3]),
> and I haven't investigated the upstream-provided repositories either (AIUI,
> they appeared after my tests, so I ran the stuff from the "flatjar" bundle, 
> ick).

This is obviously the more advanced and feature-rich solution (and I
notice they include syslog in their long list of connectivity options):

http://cookbook.logstash.net/recipes/rsyslog-agent/
  "The logstash agent, when run from java, can incur significant
overhead. The minimum memory footprint I have been able to achieve is
about 100mb. On tiny virtual machines, this may not be acceptable, so
you need an alternative."  (an alternative that every Debian system
contains already being a good choice)

I had a look at the distribution artifact (the flat JAR), it is a mix of
Java and Ruby, including various dependencies.  As everything is merged
into a single JAR it wasn't immediately obvious what the dependencies
are and which ones are essential but I'm guessing from the long list of
connector options that some are optional and packaging may involve
allowing people to mix and match.

For my own use cases, a Debian package isn't always a requirement and
the features this offers appear more compelling.

For some people (and some of my own use cases), LogAnalyzer is probably
enough as well and if a trivial integration with mongodb is going to be
possible in jessie, I felt it would be a nice thing for Debian.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5316f403.5080...@pocock.pro

Adiscon LogAnalyzer? rsyslog + mongodb?

[Daniel Pocock]

I didn't see any existing package of LogAnalyzer from Adiscon, the
people who make rsyslog - is there any specific reason for not packaging
it or it is just not something anybody needed yet?  It is GPL:

http://loganalyzer.adiscon.com/

http://download.adiscon.com/loganalyzer/loganalyzer-3.6.5.tar.gz

The rsyslog mongodb output module and the PHP mongodb modules are now in
wheezy-backports.  This would appear to be sufficient to do something like:

rsyslog => mongodb => loganalyzer

Has anybody else tried that or does anybody have any comments on it (or
recommended alternatives)?

http://loganalyzer.adiscon.com/articles/using-mongodb-with-rsyslog-and-loganalyzer/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5315e7f5.5050...@pocock.pro

Re: Honestly, fork systemd

[Daniel Pocock]

On 16/02/14 09:54, ChaosEsque Team wrote:
> Isn't it great that we have to have this discussion about forking debian
> because within an oligarchic 8 man planning committee, which
> was split 50/50 for and against systemd, the chairman happened to
> be a systemd fan and abused his position to gain a double
> vote for forcing systemd down out knecks?

Whatever it is you are trying to say, what difference will it make if
you keep sending these emails without doing any actual work to code an
alternative?

Do you think an alternative is going to just fall out of the sky?


-- 
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/5300908c.10...@pocock.com.au

Re: Honestly, fork systemd

[Daniel Pocock]

On 14/02/14 14:58, Aigars Mahinovs wrote:
> On 14 February 2014 13:42, ChaosEsque Team  wrote:
>> The systemd fans ban anyone who say fork-that to systemd.
> 
> Not respecting the communication culture of the project is a perfectly
> reasonable reason for a ban, regardless of the opinion expressed by
> the banned or held by the banners.
> 
>> What can we do?
>> Can we fork debian? (Why do we have to...)
> 
> During this whole debate what I came away feeling is that the
> strongest point of criticism against systemd was not technical or
> structural, but rather social - there is a significant and vocal
> discontent with the decision making process in systemd and with some
> specific decisions made with that process. Which leads to a fear of
> possible future problematic decisions.
> 
> If that is not a reason enough to reject systemd from consideration
> (and apparently it is not), then there is another solution with a long
> history of success in open source community - *fork systemd*.
> 
> Debian appears to have some important requirements and wishes that
> current upstream does not consider valid. If the current upstream
> continues to hold on to that position, then it might be beneficial to
> both Debian and the wider community if Debian leads a fork of systemd,
> implementing these requirements and wishes, seeking out other
> requirements and wishes that have been rejected or ignored and
> gathering a new development community around this fork in systemd.
> 

To answer the original poster's own question, what can he do?

He can stop writing these emails and start writing code (a fork of
systemd supporting kFreeBSD, to be specific)

As a second choice, if he believes in this cause so valiantly but
doesn't know how to code, he can sell his home and give the money to the
free software developer of his choosing and pay them to make an alternative.





-- 
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/52ffac54.6000...@pocock.com.au

Re: Ubuntu will switch to systemd

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 14/02/14 19:15, Matthias Urlichs wrote:
> I have to admit that I did *not* expect this. At all.
> 
> http://www.markshuttleworth.com/archives/1316
> 

Quite the opposite - some people felt it would be inevitable that
Debian choosing systemd would effectively be a death sentence for Upstart

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJS/mMUAAoJEOm1uwJp1aqDd4EP/0v9FArZvoNUCARLanyR5+9t
HkYW4FPuVf20gBfq67lLcmJRLfmWPjNIkT1c8l3Gz1j1vUuDqPYcVi24Ye8HCnOp
ydl/ABfpMctyM4IktdwcGdymgr8jhE7KZ22JgFv/Eo4QFaKaR0IjZ/MFncOBxu4i
1HpM7mgQT1lo4rfjiDURavizKqPZX/1Vns0DR6sPHglUgMP4kk6y4g3tb8lNsBb3
S02FqiD4saDembRmuyScEyIx06Pns9UYcjRYPCfFGMjHJdUy0zIud7Z0mM5rrVoY
tlCmzebWAQcVABAG9ysqsAhmWx/ZzK7JlpdLqXQRqmEz4XpPutB1OLjYjBvYhUqy
vKOhTuBM5iGav7a6wnVIB6tlNbUcuUqnlFqkt1sINiI/2tMWej+7o9E2vUUbwASR
bvkit3LoM/hOze2CDrORmKOqk+7reNyKrCU4RYErja4q9xs6B9aM6rlvEDMR0Gvr
RAbGqBORKMDO9xDdmkCk9P3FKXaBvASTZxYtu8pN8g7PZCjuR+4kcXQMjb7HgqqJ
MT1ZxHCsNinl+wVnyJYZQ5Aq2MdFnvfM2EPSuv4pV2uYzC+42b0ANEVBgEIpFG5n
yBWp4sC0vX1EAj/Q+kv1lqQiPylJfHNZfbCkO+fIBluKpirYo7SpIYSIDnKlqOgi
WLTeSBEKWuAg6wB6rBPG
=xiFA
-END PGP SIGNATURE-


-- 
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/52fe6314.6000...@pocock.com.au

Re: Can we please change the Subject: ?

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 11/02/14 21:23, Stig Sandbeck Mathisen wrote:
> Andrey Rahmatullin  writes:
> 
>> About The Thread.
> 
> The Thread That Shall Not Be Named.  (to be more precise :)
> 


Apply to the thread of your choice - unfortunately there are more than
one nonsensical enough to choose from

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJS+peoAAoJEOm1uwJp1aqDdpUQAL+S9k9XtNh40SvcvZhQcyyQ
H49ASRb0JwBPwU4P5gcLQLSTy2/5umh/hZOjLsFUI5ARZxiaDRYLCGSM1S/X045l
2gAaKTT/pT9w+HcrO24wlnvLRTthV/NhZbt7U6yEiEEZj+2sv+AbpJxHE4CxuHDF
H3M6hhFFOZG9XbshrgGTm5iIlovoxd0k4B7yiHt6livovRLux7HlIQfY2quom88k
ar59h/WsZ+kODHakFf/zBlY4Bk/xoXPMEy0dGVbo5DnZrGbrFr1/4RtxMKKN9Vop
n44T2Xf24WW3kXVrDV1oD1bt4tdZ0PovXVYA8md9+S1WFCx/Yt/LRM7HUfDDosxm
2xeQqEHB+id8XTkC+QQSleXMhhAQFujhdxceKqf8yWZpPAtkHpwj8lv8rxqvuHTF
QwHzBtUZ2mT7evlWqo+sH7tm6LwsNAvZLR3iJlREoolChG/vhPSwLIyeIyO8x5yi
R4VIQo1x0LC58QLIf0GwbLCFspHAGEijM8c49j12SiQpVQe0KqQPGlBs9URdK5lZ
kY8oXL22p6VdbqVy4Synhp2ZfQHdkyvHwm1HXmwCLOCLnAZv3iEOSoi3JFX15Hpf
tfeHIVtlhIFgU+WWV2Kon7/DI0xIgT+PZvB+lXaz6QFffQqawY9AyghFmI1EzEhT
iDZOLpv4+BYXdFO7B6Lo
=oXdp
-END PGP SIGNATURE-


-- 
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/52fa97a8.2020...@pocock.com.au

debconf managed configuration files

[Daniel Pocock]

debconf-devel(7)[1] gives a brief example of managing a key=value
configuration file with debconf

"There are a lot of ways to do this, and most of them are wrong, and
will often earn you annoyed bug reports. Here is one right way to do it.
It assumes that your config file is really just a series of shell
variables being set"

I've also come across notes on other pages suggesting additional tricks,
for example:
- check if the conf file is a symlink, if so, don't touch it
- checking for the presence/absence of some magic comment like
##DEBCONF-MANAGED## in the file

Has anybody written any further documentation about debconf with
configuration files, for example, for those that don't meet the
assumptions for the example in the debconf-devel manpage?

Are there any particular packages that are regarded as examples of best
practice?

I've also found some references to the UCF package but it is not
referenced in the debconf-devel manpage itself, is UCF the way to go or
is this a red herring?



1. http://manpages.debian.net/cgi-bin/man.cgi?query=debconf-devel&sektion=7



-- 
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/52f2077f.7040...@pocock.com.au

Re: Bug#727708: init multiple instances of a daemon

[Daniel Pocock]

On 23/12/13 08:41, Adrien Clerc wrote:
> Le 23/12/2013 00:37, Zbigniew Jędrzejewski-Szmek a écrit :
>>> It looks like both upstart and systemd don't provide direct
>>> mechanisms to
>>> manage all instances.
>> That's true (I'm only speaking about systemd). There have been
>> requests for
>> such functionality before, but nothing was implemented. But I think
>> we should
>> revisit this topic... I recently added globbing to a bunch of
>> systemctl verbs
>> for listing stuff (list-units, list-sockets, etc.), and it was actually
>> trivial. I felt that allowing globing for verbs that influence state
>> (start,
>> stop, enable, disable, ...) was too dangerous. But this should be
>> safe for
>> instance units, so I'd like to see 'systemctl stop/status/...
>> server@*.service'
>> implemented.
>>
>> Zbyszek
>>
> This could be controlled via a setting inside the unit file, like
> AllowGlobControl, default set to false in template unit files.
>


Going back to the SysVinit world for a moment... maybe we could add an
extra keyword in the LSB data in the init scripts, e.g.

X-Package: apache2

would indicate that an init script is based on the apache2 package and
should be executed whenever the primary init script from the package is
executed by the maintainer scripts

When people copy the apache2 init script or make any of their own custom
init scripts using binaries from the apache2 package, they would have to
make sure that line is included in their new script


-- 
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/52b7f04c.4070...@pocock.com.au

Re: Bug#727708: init multiple instances of a daemon

[Daniel Pocock]

On 22/12/13 21:03, Russ Allbery wrote:
> Daniel Pocock  writes:
> 
>> This email is not so much about the change of init system but just about
>> the multiple-instance problem, regardless of which init we use.  It is
>> not a huge hassle but it is something that could be handled more
>> smoothly.
> 
>> Some packages provide a way to start multiple instances in one shot from
>> their init script, e.g.
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433660
>> which does it in such a way that a single invocation of the init script
>> hits all instances (e.g. starting all when you may only want to start one).
> 
> This is something that I specifically looked at when evaluating the
> features of upstart and systemd (I haven't been able to find the necessary
> documentation for OpenRC), and I'm happy to report that they both have
> mechanisms for doing this.  upstart calls this "instances" and systemd
> calls this "unit templates".  Both allow you to write a single service
> configuration file that can then be started multiple times with differing
> parameters, creating independent services from the same configuration.

Just to clarify: does this mean systemd and upstart can refer to the
instances collectively or individually as required?  E.g. you can tell
it restart all instances of httpd (on dpkg upgrade) or just restart one
specific instance (after a config change)?

Will additional effort be needed so that dpkg or maintainer scripts can
request the collective restart of all instances, should this be
documented with a wishlist bug against dpkg perhaps?


-- 
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/52b7477d.10...@pocock.com.au

init multiple instances of a daemon

[Daniel Pocock]

This email is not so much about the change of init system but just about
the multiple-instance problem, regardless of which init we use.  It is
not a huge hassle but it is something that could be handled more smoothly.

Some packages provide a way to start multiple instances in one shot from
their init script, e.g.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433660
which does it in such a way that a single invocation of the init script
hits all instances (e.g. starting all when you may only want to start one).

This is a situation that may improve by the move to a new init system
but I believe it can also be improved even if we retain sysvinit for
some or all platforms.

My own solution usually involves duplicating the init script, e.g

# cp /etc/init.d/some-service /etc/init.d/some-service-instance2

and then hacking some-service-instance2 to use an alternate daemon
command line, point the daemon to alternate configuration file, PID
file, etc and finally I do

# update-rc.d some-service-instance2 defaults

This means the admin can restart the instances independently.  However,
there are still two problems:

a) the additional instances are not restarted automatically by dpkg upgrades

b) depending upon the package, the effort to hack the init script can
vary and potentially many users waste time duplicating these local hacks

Changing to a new init system probably resolves problem (b) because most
of the new solutions are based on a very concise manifest that can be
duplicated easily.  If we stick with sysvinit, however, maybe we need to
consider standardizing init scripts using a pattern that supports
multi-instance?  Peter's blog suggests one starting point, for example:
http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html

Problem (a) would still remain, however, with all the init solutions as
far as I can tell unless we decide on some mechanism for letting dpkg
know which copies of the init script (or declarative manifest in systemd
or upstart language) are associated with each package.  Is that a
specific topic that has already been discussed elsewhere?


-- 
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/52b73f9f.7070...@pocock.com.au

Re: Release sprint results - team changes, auto-rm and arch status

[Daniel Pocock]

On 29/11/13 18:23, Simon McVittie wrote:
> On 29/11/13 16:36, Ian Jackson wrote:
>> It seems likely to me that that bug is, at root, a race of some kind.
>> And it just so happens that the race is lost on kFreeBSD - sometimes.
>>
>> Detecting such a race is valuable to the project; it's certainly not a
>> disbenefit.  After all, a race that happens to us sometimes is likely
>> to happen to users sometimes.
> 
> Yes, to a point. On the other hand, each RC architecture where
> build-time tests are fatal inflates some subset of "ordinary bugs" to
> Severity:serious - if we'd seen this bug (or a similar "sometimes-fails"
> bug) "in real life", even if there's a way to reproduce it on (say) x86
> Linux, would it necessarily have RC severity?
> 
> Perhaps this particular bug would - I have no idea how often it happens,
> or what functionality it breaks - but Daniel's phrasing implied that
> this particular regression test suite is far more thorough than what
> we'd consider to be "a major effect on the usability of a package"
> (Severity:important).
> 

The test suite is executed on every upload and if it isn't 100%
successful the build fails and the package does not propagate on any
platform.

This race condition is 100% reproducible on the porter boxes too, I'm
yet to find the root cause though.  Of particular note, it only occurs
on some of the more recent builds, so it appears to have been introduced
by some upstream change in the last 6 months.


-- 
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/5298ec78.70...@pocock.com.au

Re: Release sprint results - team changes, auto-rm and arch status

[Daniel Pocock]

On 29/11/13 04:14, Steve Langasek wrote:
> Hi Niels,
>
> On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote:
>> kFreeBSD was a technology preview, and has not generated enough user
>> interest to bring in sufficient install base to continue in this
>> state.
> I wonder, how is the release team measuring this?  For the other ports that
> you mention, you've pointed to concrete technical problems that are in line
> with the previously-documented release qualification guidelines.  kfreebsd,
> OTOH, is only listed as having "insufficient install base".  But what is
> sufficient?  http://popcon.debian.org/ shows numbers for kfreebsd-* that are
> greater than a number of our ports.
>
> You rightly point out that keeping the architectures in testing has a cost,
> because the architectures will block testing migration.  But are the
> kfreebsd archs actually causing testing blockages, in practice?  If there
> are such blockages, can you give us more information about how this has been
> the case?

I have had unusual issues on kFreeBSD with reSIProcate although that is
partly because the unit tests are so exhaustive that they expose obscure
bugs, e.g.

  http://list.resiprocate.org/archive/resiprocate-devel/msg08488.html

It could be argued that the "cost" of these other architectures is not a
one-sided equation - their presence contributes in some way to the
overall quality of the software that people include in Debian.  So the
net cost may be lower than people really think, but of course that
doesn't take away the fact that it is a cost that has to be paid to keep
these ports there.




-- 
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/5298b686.8030...@pocock.com.au

Re: Release sprint results - team changes, auto-rm and arch status

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 28/11/13 21:04, Niels Thykier wrote:



> Architecture Status ===
> 
> ia64 causes us concern for the following reasons:
> 
> * binutils issues (#718047, #720404), resulting in build failures
> blocking transitions
> 
> * many packages link to libunwind on ia64, which causes issues if 
> used at boot time (as the library is in /usr) and means nearly
> 3000 packages need to be rebuilt when the SONAME changes. The
> ingrained nature also leads to libunwind8 currently depending on
> libunwind7 (which is no longer built)
> 
> * d-i in a virtualised environment on top of HP-UX is broken (see
> https://lists.debian.org/debian-boot/2013/11/msg00017.html)
> 
> 
> We have stopped considering ia64 as a blocker for testing 
> migration. This means that the out-of-date and uninstallability 
> criteria on ia64 will not hold up transitions from unstable to
> testing for packages. It is expected that unless drastic
> improvement occurs, ia64 will be removed from testing on Friday
> 24th January 2014.
> 
> The architectures sparc, mips and mipsel also cause concern:
> 
> * [sparc] cannot run stable kernels.  Kernels in sid have issues
> too with some machines. * [sparc] gcc randomly crashes, SMP not
> working * [sparc] only one porter * [mips, mipsel]
> buildds/porterboxes run on hardware which is very old or has known
> defects: - mips octeon is unstable - mipsel loongson have CPU bugs 
> - swarm is a decade old
> 
> kFreeBSD was a technology preview, and has not generated enough
> user interest to bring in sufficient install base to continue in
> this state.
> 
> We will review this situation after 28th January 2014. 
> Architectures still causing us concern at that point will join ia64
> in no longer being considered for britney migrations and may be
> dropped from testing after a further period.
> 
> s390 and Hurd will not be release architectures for Jessie. s390
> was replaced by s390x in Wheezy and this completes that transition.
> As for Hurd; we do not believe it is ready.  Particularly, we
> believe that it does not surpass kFreeBSD in user interest or
> install base.
> 
> Note that s390x and powerpc could also do with more porters, but
> at this time we are not giving an official warning for them.
> 

I've found the builds on the less used architectures have been useful
for flushing out unusual bugs, particularly when the code ships with
many test cases and it exposes problems for big endian machines, etc.

Also, kFreeBSD and HURD are both kind of special in that they are not
Linux, it would be good to keep one or the other around even if other
architectures are culled more aggressively.



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJSl6aKAAoJEOm1uwJp1aqDhsEP/jVlnrrriK9nF//yIpqZey/z
qF17Wa4O8R160LRwr0N8C4VZ9gYxDkMHlVLswwY0QTez7ZwQNjOlWHnEFscINPBN
l9fprEoG2cQ1pzY9voY+ba5jQ0NHXvD36cgTk0PIAXXaG+FEriWxFq/9X+2koHBp
QXluhSWMWY3TplLNQKNTU1uj01+L4lFVrPmzZP7guQjQLVcZuoJ5Kd8/JiaZ12Fl
FtdC0DDVTg3QKCw7+ljhMmryfQ39XHeV84QzgWkcYXx/boh0+mXi5AYOrlffnRq/
ypBC4Kcf+CxRLafYcsrtgA5sDr4rPzC6zh91ewXGd5F0pi+m+Ofx53lkq1TDjcJQ
sZzSAQjarVeTjZt6Sb0n9fllBMBNg4b6D6idYKrY+wcGNecNK/YoCWItY8jmr+5L
NJfD0ykFsEr+Y53aJyU/0Gv9ahkciXeN2Bvw3ujYbBmU2wVRO3WlgNrMlbzPesIj
n8pNWqEcCszN82g0463ldg+KnzCTxRw/3PGaACwx/reT3m1Iy+JonBISSEIs0Hjg
7rEdUgj2FE338aUEgokJOzPO8UrLaz/G+YshdRntGPqwY+WLzsa+8odltUhR3v+d
4R13WPIs4gxOKLcBbwsSXbjZ0FI1M1xumRfNQt+5J6TeaXs7t/XkbwDU2skhZLyR
YFastfqPuNmfjMpu7N6A
=hOWV
-END PGP SIGNATURE-


-- 
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/5297a68a.8020...@pocock.com.au

transition from radiusclient-ng -> freeradius-client, shared config file

[Daniel Pocock]

Can anybody suggest how to share the radius client config file between
these two packages?

radiusclient-ng is deprecated

freeradius-client is the same code, but supported with some fixes from
the FreeRADIUS community

Both packages use the same config file and currently they are declared
to conflict with each other.

However, header locations are different, SONAMEs are different, so it
would be possible for them to exist concurrently on a system

Hopefully radiusclient-ng will not be part of the jessie release, but
may remain on systems as people upgrade

How should I ensure that people can keep both packages on the system
without getting errors about the config file when adding the new
package, but also ensure that fresh installs don't need to install the
old package to create the config file?


-- 
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/524fd0da.40...@pocock.com.au

Re: update-menus silently failing with Gnome?

[Daniel Pocock]

On 30/09/13 01:34, Charles Plessy wrote:
> Le Sun, Sep 29, 2013 at 10:01:50PM +0200, Daniel Pocock a écrit :
>>
>> For those feeling lazy, I suppose we can just grab the .desktop file
>> generated under /var by update-menus and copy it into our packages?  Or
>> is there a more elegant way to manage the duplication with debhelper
>> support perhaps?  If somebody could add that under the bug it might help
>> those who face this issue in future.
> 
> Hello Daniel,
> 
> in case it helps, you can also have a look at the following page on our
> wiki, where the syntax of the Menu and Desktop entry files are compared
> side to side.
> 
> 
> https://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries#Parallel_between_Menu_and_Desktop_entries

Thanks for pointing this out

The menu page mentions that menu files have to be 7-bit ASCII to support
some window managers - is that still an requirement?

Some desktop files I looked at appear to be UTF-8

Is the wiki proposing to abolish the menu files, or simply to generate
menu files at build time or installation time from .desktop files?


-- 
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/52491d51.7030...@pocock.com.au

Re: update-menus silently failing with Gnome?

[Daniel Pocock]

On 29/09/13 20:09, Adam D. Barratt wrote:
> On Sun, 2013-09-29 at 19:55 +0200, Daniel Pocock wrote:
>> I can see that update-menus is run during the dpkg install and I tried
>> running it again manually.
>>
>> I can even find the .desktop file for Gnome after update-menus has run,
>> it looks OK
>>
>> However, the item just doesn't appear in the menu, even after logging
>> out and rebooting
> 
> GNOME uses .desktop files, and (in jessie and sid) does not use the
> Debian menu at all; see #694356.
> 

Thanks for the fast reply

The bug doesn't really give a lot of detail about the strategy for this
- Debian appears to have a perfectly good menu tool and it is not clear
why it has to be ditched.  If it is a permanent change, does somebody
need to raise a bug against the document that I was referring to?

Should lintian implement a new check for packages with
menu-file-but-no-dot-desktop ?

For those feeling lazy, I suppose we can just grab the .desktop file
generated under /var by update-menus and copy it into our packages?  Or
is there a more elegant way to manage the duplication with debhelper
support perhaps?  If somebody could add that under the bug it might help
those who face this issue in future.

For now, I've just added this to debian/install:

debian/postbooks.desktop usr/share/applications

and put a postbooks.debian file in debian/


-- 
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/5248872e.2000...@pocock.com.au

update-menus silently failing with Gnome?

[Daniel Pocock]

I've been trying to create menu items for postbooks and
postbooks-updater, for example:

http://anonscm.debian.org/gitweb/?p=collab-maint/postbooks-updater.git;a=blob;f=debian/menu;h=456d003f95312b27e3a1301057dd5b8dc3efca36;hb=86c8d75cc7297ba47b6398930c256d202011ab93


is a debian/menu file containing:

?package(postbooks-updater):needs="X11" \
   section="Applications/Office" \
   title="PostBooks Updater" \
   command="postbooks-updater" \
   icon="/usr/share/pixmaps/xTuple.xpm"

The file is installed to /usr/share/menu/postbooks-updater

The xpm file exists (it is installed by another package)

I can see that update-menus is run during the dpkg install and I tried
running it again manually.

I can even find the .desktop file for Gnome after update-menus has run,
it looks OK

However, the item just doesn't appear in the menu, even after logging
out and rebooting

I also tried looking in the menu editor to see if it was disabled, but
it is not there either

The update-menus -v output doesn't give any clues

Are there some extra steps required to make a working menu item?  Could
they be added to http://www.debian.org/doc/packaging-manuals/menu.html/
perhaps?


-- 
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/52486994.2060...@pocock.com.au

qmake and "make dist"

[Daniel Pocock]

upstream is using qmake for PostBooks

qmake doesn't appear to provide a "make dist" facility, at least not the
way the project is currently configured.

Consequently, upstream tarballs tend to be snapshots of the developer
workspace, in one case, even including things like submodules,
.gitmodules and other things that don't fit too nicely into the Debian VCS

Is there any convenient way that upstream can generate a clean tarball
with qmake?  In general, is it sufficient to work with a
github-generated tarball for the tag on a qmake project?


-- 
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/524332c1.1010...@pocock.com.au

Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing

[Daniel Pocock]

On 20/09/13 22:09, Bastian Blank wrote:

> I would call code that hits such clear definitions too buggy to be
> supported.
> 

and what if many more existing packages are found to have similar issues?

  http://debile.debian.net/sources/

One of my packages has some nice colours:

http://debile.debian.net/source/fred/resiprocate/1.8.12-4/1


-- 
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/523cbf1f.7040...@pocock.com.au

Re: packaging Postgres binary dump files

[Daniel Pocock]

On 20/09/13 17:07, Paul Tagliamonte wrote:
> On Fri, Sep 20, 2013 at 05:04:50PM +0200, Daniel Pocock wrote:
>> On 20/09/13 15:49, Paul Tagliamonte wrote:
>>> On Fri, Sep 20, 2013 at 02:47:39PM +0100, Jonathan Dowland wrote:
>>>> On Fri, Sep 20, 2013 at 12:20:38PM +0200, Paul Wise wrote:
>>>>> It is also impossible to patch the binary format unlike SQL.
>>>> Interesting. For the first time, I've realised there can be a clash between
>>>> "preferred form for modification" and "preferred form for use".
>>> I mean, not really, right?
>>>
>>> If I want to use a .so, I want the ELF, but I want to modify it in C
>>>
>>>
>>> This just means we ship the prefered form for use (this binary kruft)
>>> but ship the preferred form for modification in the source.
>> The rules file could apply changes if required, pg_restore | something |
>> pg_dump again.
>>
>> The current version of the postbooks-schema-* packages are now in
>> collab-maint git. They simply install these files to
>> /usr/share/postbooks-schema but make no attempt to load them into PostgreSQL
>>
>> In this case, it is a client-server solution.  There is no guarantee the
>> client code (package: postbooks) runs on the same host as the database
>> (packages postgresql and postbooks-schema-quickstart).  Maybe the user
>> even has some Windows clients too.  So we have no easy way to
>> synchronize changes to the client package and the database.
>>
>> If somebody wants to create any indexes in the database, details can go
>> in README.Debian.  The administrator can then choose how to use it.
>>
>> However, if the package is formally rejected by the FTP masters then I
>> will be happy to change it to ASCII SQL if required.
> Please include the source / preferred form for modification in the
> source, and create this postgres thing from that.

I've now re-created the git repos on alioth and created a new version of
the orig.tar.gz that includes both the file downloaded from upstream and
an ASCII SQL

Only the SQL is shipped in the binary package.

The file from upstream is not distributed in the binary package for now
and we do not try to regenerate it either.  The conversion between this
format and ASCII is one way with the pg_restore command.  We convert the
file from binary to SQL during the creation of the orig.tar.gz (it is a
repackaged upstream tarball in effect).

To go the other way (from an ASCII SQL into a binary dump file) during
the package build phase, it needs to be loaded into a running PostgreSQL
server and then extracted with pg_dump.  I don't think that is a great
build dependency, especially if we want to support things like chroot
builds.

There are two downsides to this approach:
- user doesn't get the benefit of the pg_restore features for selective
restore
- the usage instructions are very slightly different from what upstream
describes, in particular, the SQL is zipped and has to be piped through
zcat when using it


-- 
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/523c7558.6000...@pocock.com.au

Re: packaging Postgres binary dump files

[Daniel Pocock]

On 20/09/13 15:49, Paul Tagliamonte wrote:
> On Fri, Sep 20, 2013 at 02:47:39PM +0100, Jonathan Dowland wrote:
>> On Fri, Sep 20, 2013 at 12:20:38PM +0200, Paul Wise wrote:
>>> It is also impossible to patch the binary format unlike SQL.
>> Interesting. For the first time, I've realised there can be a clash between
>> "preferred form for modification" and "preferred form for use".
>
> I mean, not really, right?
>
> If I want to use a .so, I want the ELF, but I want to modify it in C
>
>
> This just means we ship the prefered form for use (this binary kruft)
> but ship the preferred form for modification in the source.

The rules file could apply changes if required, pg_restore | something |
pg_dump again.

The current version of the postbooks-schema-* packages are now in
collab-maint git. They simply install these files to
/usr/share/postbooks-schema but make no attempt to load them into PostgreSQL

In this case, it is a client-server solution.  There is no guarantee the
client code (package: postbooks) runs on the same host as the database
(packages postgresql and postbooks-schema-quickstart).  Maybe the user
even has some Windows clients too.  So we have no easy way to
synchronize changes to the client package and the database.

If somebody wants to create any indexes in the database, details can go
in README.Debian.  The administrator can then choose how to use it.

However, if the package is formally rejected by the FTP masters then I
will be happy to change it to ASCII SQL if required.



-- 
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/523c6412.4010...@pocock.com.au

Re: packaging Postgres binary dump files

[Daniel Pocock]

On 20/09/13 09:07, Paul Wise wrote:
> On Thu, Sep 19, 2013 at 2:42 PM, Daniel Pocock wrote:
>
>> PostBooks distributes their schema as a Postgres binary dump file for
>> use with pg_restore
> What is their reason for using the binary format? Could they be
> convinced to switch to or add something more normal like compressed
> SQL?
>


Maybe they are just trying to make it easy for people to download and
start using it quickly.

My own database was created using their "quickstart" database, I've also
tried their "demo" database, both are very easy to use for anybody with
basic PostgreSQL knowledge.

They also provide an installer as another way to get started.  Neither
Andrew nor I have tried that yet and it is not in the main upstream
tarball, it is released from another repository.  We may want to provide
just the SQL and a postinst script wrapped in a Debian package rather
than packaging their whole installer.



-- 
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/523c006c.7070...@pocock.com.au

PostBooks packaging update, new alioth group

[Daniel Pocock]

Andrew and I have been going over the PostBooks packages, first uploads
in the NEW queue

We have an alioth group now:

   https://alioth.debian.org/projects/pkg-xtuple/

and a mailing list:

https://lists.alioth.debian.org/mailman/listinfo/pkg-xtuple-maintainers

so please join us.  The packages are tracked in git:

Vcs-Git: git://git.debian.org/collab-maint/postbooks.git
Vcs-Browser: http://git.debian.org/?p=collab-maint/postbooks.git;a=summary

Vcs-Git: git://git.debian.org/collab-maint/csvimp.git
Vcs-Browser: http://git.debian.org/?p=collab-maint/csvimp.git;a=summary

Vcs-Git: git://git.debian.org/collab-maint/openrpt.git
Vcs-Browser: http://git.debian.org/?p=collab-maint/openrpt.git;a=summary


and the README.Debian shows how easy it is to try it:

http://anonscm.debian.org/gitweb/?p=collab-maint/postbooks.git;a=blob_plain;f=debian/README.Debian;hb=HEAD

My feeling is that this is the most advanced of all the accounting
solutions packaged on any Linux distribution, but it is also relatively
easy to get started.



-- 
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/523b649f.7000...@pocock.com.au

Re: Roll call for porters of architectures in sid and testing

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256




I'm particularly keen to see communication packages working on as many
architectures as possible because otherwise two-way communications
opportunities are missed if some users are excluded.

In short, I'm not formally volunteering, but if people have trouble
with any VoIP or communications packages on any of the ports, please
hassle me, I'll try to help.

I'm also very happy to accept feedback and patches from porters when
wearing my upstream developer hat, so if people have trouble with any
of my packages on ports, please contact me.

Regards,

Daniel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJSO2GLAAoJEOm1uwJp1aqDrDwQAJWC2L3hHQvlLInXeN9YxfEk
cqx9+qNnnT1Tl9Pj2x0kLYxYyxyI0guhpqPH/nxjD6KOyfSLiecmtyfgjqSW9y7x
KnrB4OicgXLla5hpSnk5iLOg5WVDRajR/LznsnR+abCUCP/7ltAqmu3CMY6ZrOYH
HHk9IgfkOoL1tJSabhBXEdSHS6EXB4raMYRKgRzp55iJtmr+704VnmP6KVMxYjPz
q4253QRgf/MhcAl2WMiH/iCOJIyEENmaMnlkMNcASVk11uVhUhYhSnUfWlRm//q3
V5vIca/DR7UVnlSiFblEK1Ir1kLBamhCKOVQD98hYt00Fho3yK35udJtKYukei+C
ILeEV9odlUT3LJUbdw0nP3K9zn58x8YHP26HscsaDltNyYQWLGf5EeJUWqyxHVwZ
mHEQlNppsT8jZMjvo6BoafNxQvVTvBrYqyDXNvloLBDRh38Ppcb6z5Qng2akyRC9
I9TLFwDE7lzP1lFs3IDKuGTSFLgHve7ZgKIEmlj3JioVjME8yyvl/Z7SSFGWooAQ
ykBnq7SYrmQBqWXbJw1BpCl6l8JoLYIVqq4wgsm7Gjd5XFs6FwwFoaDxumHorl90
PP2Yw+RZJDLwePsnFAmONo06/dbCNLgyyQAuENwYS50MJGp6uBl/YPxtB6dqvezL
RIwweOQnSBmZ8/k16xIX
=s7HC
-END PGP SIGNATURE-


-- 
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/523b618c.4020...@pocock.com.au

packaging Postgres binary dump files

[Daniel Pocock]

PostBooks distributes their schema as a Postgres binary dump file for
use with pg_restore

They are available for download here (not in the source tarball):

  
http://sourceforge.net/projects/postbooks/files/03%20PostBooks-databases/4.1.0/

The pg_dump documentation explains the binary format features:

   http://www.postgresql.org/docs/9.1/static/app-pgdump.html

Is this format suitable for making a source package or do we need to
load it into Postgres and then pg_dump it again as text / SQL?

I would prefer to simply distribute the original files so that people
can compare with upstream's checksums if they wish.



-- 
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/523af145.4090...@pocock.com.au

Re: using packages from sid on travis-ci.org

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/09/13 23:34, Roger Leigh wrote:
> On Tue, Sep 10, 2013 at 10:42:09PM +0200, Daniel Pocock wrote:
>> 
>> 
>> Some of the upstream projects I work on use travis-ci.org for
>> continuous integration
>> 
>> In some cases I'd like to configure builds that depend on
>> packages from Debian unstable, but I'm not sure of the Ubuntu or
>> travis way of doing that, has anybody dealt with this before?  Or
>> is there a Debian alternative?
> 
> You can configure travis to add additional apt sources and then
> install packages from them, e.g.
> 
> before_install: - sudo add-apt-repository -y "deb
> http://archive.ubuntu.com/ubuntu/ raring main universe" - sudo
> apt-get -qq update - if [[ $BUILD != 'sphinx' ]]; then sudo apt-get
> install -qq python-genshi; fi - if [[ $BUILD == 'cppwrap' ]]; then
> sudo apt-get install -qq build-essential cmake libboost-all-dev;
> fi - if [[ $BUILD == 'sphinx' ]]; then sudo apt-get install -qq
> python-sphinx; fi - if [[ $BUILD == 'sphinx' ]]; then sudo apt-get
> -y install texlive-latex-base texlive-latex-recommended
> texlive-xetex; fi - if [[ $BUILD == 'sphinx' ]]; then sudo apt-get
> -y install texlive-latex-extra texlive-fonts-recommended tex-gyre;
> fi - if [[ $BUILD == 'sphinx' ]]; then sudo fc-cache -rsfv; fi
> 
> In this case, we're updating to a newer version of Ubuntu and
> installing packages from it, but you can probably do exactly the
> same for unstable.
> 

Thanks for this feedback, I managed to get my dependency into saucy
and it is working with that approach

However, I suspect that sooner or later I will need to just get things
directly from sid (or testing) so that I am always using the versions
likely to be released.  I've never tried doing such a dist-upgrade
from Ubuntu but if it can all happen without any user input then I
will give it a go.



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJSOg8BAAoJEOm1uwJp1aqDZ4gP/iHuYUsEqZ7nz4b/Ddc9JP6z
NQghvjLIWX5X7imX+vMCyhB5gW3gif9j7JVb3CDVxDJcVHsNQfny2xGgHneUxHTn
uwaKsds2Wk8vev/IiugssycdoFhm0TP3hdLzXSRb4aP5Y1kMsRdwPlv+cWzVITKd
g/cSayTG737cnUC//0T1LiwkFcRH2vdY09QvL5Q4ctik9RFc6F9bbBUcTK+oUz/V
AOVpX4n6ZIMpsq1jmcKBlz1RkU4wDF436pgvS9DRwklhAPKovzsdO6KST96KgYKO
Exf4dT3uoSYD/LuBFvZZ+16OsQX2Lj+skDDKP1qI3Wgu7xnKHLo/xV0S/tmQv9Qo
0cSiaMlT5+Y4ZyvKwe2M4jbh2T+pS9wY4nHuHblX9thMxMDPM96HCoEzcBjKbHiE
NtoQ8lNgV3lQAqE98zTGesoXmex6b+u5Ok0pc0YbExbG0lANPW6lT5WIMF+ckRJv
xwJRvUn2jqChCsBANEFD8EKkDCsu8S1IuTcCXrCwBOocHGzEji7SfRkhpq0pk+W+
cb4T6DH9otbWDm1Egc7xTvpSyzkYSh6ADxycISM/K5GQjMUZI4TgQAK+8BCAga7V
DpC8Rt4U7kjeE6n3wDLjjXK6Fw/IlPU2fBuMtXqZAIDvVDBfXBu2+JiFReS3uasL
AtSsmwCzZHK3hmwDNt4G
=3QZi
-END PGP SIGNATURE-


-- 
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/523a0f01.2010...@pocock.com.au

using packages from sid on travis-ci.org

[Daniel Pocock]

Some of the upstream projects I work on use travis-ci.org for continuous
integration

In some cases I'd like to configure builds that depend on packages from
Debian unstable, but I'm not sure of the Ubuntu or travis way of doing
that, has anybody dealt with this before?  Or is there a Debian alternative?


-- 
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/522f8421.6060...@pocock.com.au

Re: buildd could run "make -i" twice on failure

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 08/09/13 01:20, Roger Leigh wrote:
> On Sat, Sep 07, 2013 at 11:28:31PM +0200, Daniel Pocock wrote:
>> After a build fails on the buildd, it would be really useful to
>> have the build run again twice with "make -i" and log the output
>> of the second retry
> 
> What's the main advantage of doing so?  To log further errors not 
> seen due to the first failure?  Why not just use "-k" to begin 
> with?

If -k will try all the same things as -i (which is true for most well
written Makefiles) then it is fine.

I agree that developers could just add -k in the build section of
debian/rules, but the output is quite verbose.  One reason I suggest a
re-run of the make with -i (or -k) is to get a more concise summary of
the errors, probably with -j1 as well, and make that available
separately from the normal buildd log output.


> There's no guarantee that "make" is being used for building, and 
> it's non-trivial to determine if it is or is not in use, nor how to
> invoke it appropriately.  If we want to do it centrally, it would
> be more reliable to add a new target which sbuild or other build
> tools could invoke on error, and which package maintainers could
> add to support their specific requirements.

That would be quite OK.  Maybe every target could have an optional "on
failure" target.

As well as a new target (or targets), there would also need to be some
way to have the output of the target redirected to a dedicated log

Later on, this could also lead to more advanced reporting, e.g. rather
than just counting the number of packages that fail on HURD or fail
after some transition, we would be able to count the number of actual
errors and calculate the ratio of errors/package, etc.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJSLDcaAAoJEOm1uwJp1aqD0FIP/jnDl1YKy32KPDKO0/0gfAc5
h+exPEM4FilwLowZmrHKQ6sYgl28okoyGI6aAIbIo3VWABQKWftf7SMHqEPN3W6T
GhqQQdajNusysm7OlEs0PFV0wtQkm6XdOWgi6/jHyF0JpXpj+N8Hn6/pKTSvccrh
NcnJDhRtcDdsBojaHT+6SK9G9V/P5n6HeijHU40SMRhVzvvrrgAx7F6oiFw+8mxf
wKoagtiAs4NY1vcd2qa0Pbdr3/AgFI1+yeEn+f/mNVn8wUH1k3Akwb1jJ5y3XP5P
ZLG4DlewyOlRKDgh5F3iE6RvFhMLCLxLcxzxV/oqgpUj9ybaeWdcKMxSmNSnbJdQ
1WDEFvEqszWr2xEMyWXKRDPCnw1UgdwStRrrSjR2qtdG3Hu39/PIwrh+BBR3bW7Q
hUx+GV/N/gprXQqALi+WciIkol1kgiVoPna7vm2takNh9iLy7cMLsfmbpZynALW1
XakQWeis2zvKklynAkOC33f96ZkFAi/EbZP7T1EcGISKmBDMSAFnK+cfGWIHbh+V
rUnOL82O2Nt6l2rwhJKAri0DAx6PqqYTjOq/bfx2mcMHsNg8mZWp58kZO3aOeRk5
KpgirDUS4PcL83P1ahSaZxEPBsd9p8+gh7KZQT+EsjaLa1YJoJGASO2dxarGjIrm
pkiZ4h2Buh7Hn2ndpS2o
=v0pO
-END PGP SIGNATURE-


-- 
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/522c371a.4030...@pocock.com.au

buildd could run "make -i" twice on failure

[Daniel Pocock]

After a build fails on the buildd, it would be really useful to have the
build run again twice with "make -i" and log the output of the second retry

Obviously I could hack something like this into debian/rules:


make || make -i ; make -i ; exit 1

but it would be nice to have a centrally managed approach


The output would then provide a more complete set of feedback about
whether a package just has 1 error or 500 errors, this would provide
greater visibility of potential effort required for porting

Some packages don't compile their test cases without running "make
check", so it would also be useful to force the test cases to be
compiled (with -i) to check for compile errors


-- 
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/522b9a7f@pocock.com.au

Re: Dreamhost dumps Debian

[Daniel Pocock]

On 21/08/13 19:08, Clint Byrum wrote:
> Excerpts from Kevin Chadwick's message of 2013-08-21 08:45:27 -0700:
>> My point of view is that Debian Stable should be aiming for whatever
>> they believe the sweet point between stable and so usable without having
>> problems is and maximising security. Aka maximising productivity and
>> safety with no other concerns or compromises.
>>
>> Large hosting companies not having made their scripts etc. good enough
>> to ride out upgrades well should have nothing to do with any decision.
>>
>> In fact they are best positioned man power wise to be able to set up a
>> test rig and then deploy compared to small hosting companies.
>>
>> Does anyone even know for sure what the decision to switch was actually
>> based upon?
>>
> IIRC, the blog post cites exactly that, too short releases.

There have been many comments about the 5 year security updates, but
some people (sadly) don't think about that anyway, there are plenty of
other decision making factors:

For many users, the server is under warranty for 3 years, they are
sometimes willing to risk or purchase another 1-2 years, total 5 years
useful life for the server.  They pick Ubuntu LTS or RHEL because it
appears to be aligned with that.

At the beginning, they chose the server and OS together.  Unless there
is a compelling reason, they don't want to risk upgrading the server
half way through its useful life, risking any changes to hardware driver
compatibility.  They only want to spend time on those issues once: when
they buy the server.

Many commercial products also support legacy users and upgrades from
(current-2) or (current-3) rather than just upgrading from the last
major release.  If Debian followed this model, then it would mean:
a) security updates for squeeze would continue until jessie + 1 year
b) a direct upgrade from squeeze to jessie (skipping wheezy) would be
desirable (though not essential)

Users who don't need or want bleeding edge stuff typically prefer to
progress at that pace


-- 
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/52161386.5040...@pocock.com.au

Re: buildd dependency problems?

[Daniel Pocock]

On 18/07/13 22:44, Adam D. Barratt wrote:
> On Thu, 2013-07-18 at 12:46 +0200, Daniel Pocock wrote:
>> I notice one of my package fails on hurd-i386, kfreebsd-* and sparc due
>> to various dependencies:
>> https://buildd.debian.org/status/package.php?p=resiprocate&suite=sid
>>
>> and it appears these dependencies have been unavailable for a long time.
>>
>> The bottom line is that urgent fixes in the package are not propagating
>> to testing at all because of these other packages on the least used
>> architectures
> 
> I was tempted to reply with simply "codswallop", but that seemed
> unhelpful so I'll expand on how you're mistaken.
> 
> It's a little more difficult than it might have been to check the
> situation now, as there have been three uploads of resiprocate since you
> sent the mail to which I'm replying.
> 
> However, one can still easily look at the grep-excuses output for the
> previous upload:
> 
> 24 days old (needed 10 days)
> out of date on armel: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, 
> libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, 
> libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer 
> (from 1.8.8-2)
> out of date on kfreebsd-amd64: libresiprocate-1.8, 
> libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, 
> libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer 
> (from 1.8.5-4)
> out of date on kfreebsd-i386: libresiprocate-1.8, libresiprocate-1.8-dev, 
> libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, 
> resiprocate-turn-server, sipdialer (from 1.8.5-4)
> out of date on mips: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, 
> libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, 
> libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer 
> (from 1.8.10-2)
> out of date on mipsel: librecon-1.8, librecon-1.8-dev, 
> libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, 
> libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer 
> (from 1.8.8-2)
> out of date on powerpc: librecon-1.8, librecon-1.8-dev, 
> libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, 
> libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer 
> (from 1.8.10-2)
> out of date on s390: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, 
> libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, 
> libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer 
> (from 1.8.10-2)
> out of date on s390x: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, 
> libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, 
> libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer 
> (from 1.8.10-2)
> resiprocate (source) has new bugs!
> Updating resiprocate introduces new bugs: #713634, #713865
> 
> Of the architectures you suggested were blocking "urgent fixes", neither
> hurd-i386 nor sparc appear in that list - both because the failures are
> not regressions and because hurd isn't a release architecture.

Ok, I had simply been looking at the buildd status page and trying to
get it into shape (things are looking better after today's third
upload).  Given the long list of failures I hadn't been comparing the
items on the different lists one by one.

Maybe the buildd status could differentiate the blocking failures?  Or
is there another way I can view all of that in one place?

> Indeed, the above output clearly indicates that the actual problems were
> the build failures on eight previously supported architectures. (and the
> two RC bugs which were still open despite apparently having been fixed.)

The quality of the code has actually improved, but so have the test
cases and they are catching bugs that were there before, especially on
big endian.

Various upstream issues have been found in big endian and other
non-Intel architectures - obviously all the upstream team are very
grateful to Debian for providing a platform where we could make these
improvements.

On the other hand, we've simultaneously fixed some unrelated issues on
the most popular architectures too


-- 
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/51e85719.5010...@pocock.com.au

buildd dependency problems?

[Daniel Pocock]

I notice one of my package fails on hurd-i386, kfreebsd-* and sparc due
to various dependencies:
https://buildd.debian.org/status/package.php?p=resiprocate&suite=sid

and it appears these dependencies have been unavailable for a long time.

The bottom line is that urgent fixes in the package are not propagating
to testing at all because of these other packages on the least used
architectures

To avoid causing delays for users who want the fixes in testing, I'm
tempted to just change "Architecture: any" and cut out those other
platforms.

I had a brief look here:

http://www.debian.org/devel/buildd/

and I notice it encourages people to make their package portable, which
is great for packages people maintain themselves but I couldn't find any
guidance about the situation I have now.

If I do cut support for those other architectures, is there any way I
can be automatically notified when the dependencies do become available?





-- 
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/51e7c784.2000...@pocock.com.au

Re: system-wide crypto policies

[Daniel Pocock]

On 28/06/13 09:34, Thijs Kinkhorst wrote:
> On Thu, June 27, 2013 22:16, Daniel Pocock wrote:
>> On 27/06/13 21:44, Florian Weimer wrote:
>>> * Daniel Pocock:
>>>
>>>> However, are such issues at the discretion of package maintainers and
>>>> upstream, or is it useful to have a uniform Debian approach to
>>>> cryptographic strength?
>>>
>>> Keep in mind that RFC 4880 (OpenPGP) hard-codes SHA-1 in several
>>> places, notably for key fingerprints.  If there's a uniform strength
>>> requirement, we need some weasel words that GnuPG remains compliant.
>>>
>>> It's also unclear if SHA-256 or SHA-512 is stronger, and if either
>>> really is that much better than SHA-1.
>>
>> Just to clarify, although my query was related to the use of this hash
>> in GnuPG, the reason for the email on debian-devel is for the
>> system-wide policy on hashes: which could mean any package (e.g. git
>> uses SHA-1 too, some of the X.509 root certs use an SHA-1 hash)
>>
>> The first question then - do we even need to care, as a project, about
>> being pro-active?  Or just leave it at the discretion of derivatives and
>> end-users to make their own policies?  That's quite OK as long as this
>> approach is documented.  The security page[1] says "Debian takes
>> security very seriously" and some users may ask how we apply that
>> philosophy to SHA-1 given that it is on various alerts[2].
>>
>> It may be that we say "Some packages include SHA-1 technology and if the
>> attack potential crosses some threshold X the security team will not
>> support them."  Then it is up to maintainers and upstreams to think
>> about and start making plans for the future of their packages.
> 
> I think such decisions are indeed best left to individual package
> maintainers as there's in my opinion no one sound advice that works for
> all cases. While moving away from SHA-1 right now might make sense in some
> cases, in others it's still problematic. You name X.509: CA roots are by
> and large not moving away from SHA-1; you name GnuPG: SHA-1 is indeed in
> the standard and signing stuff with non-SHA-1 hashes still leads to
> compatibility issues which make that there's a good case for keeping the
> current default.

Just out of interest, a CA can re-issue their root cert with the same
key pair but a stronger hash.  This type of thing has happened before.


> Although deprecation is good, there's also still doubt on where to migrate
> to. Per-package decisions are hence a much more suited approach than
> archive-wide policies.
> 

I agree it is not clear - if there was a clear bug and a clear solution
I would have just filed a bug report.

As it stands, I will probably start a wiki on crypto-strength issues to
start gathering information that is relevant.  Then users and
maintainers will have something to refer to when such issues come up in
future.


-- 
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/51cdfb24.7030...@pocock.com.au

Re: system-wide crypto policies

[Daniel Pocock]

On 27/06/13 21:44, Florian Weimer wrote:
> * Daniel Pocock:
> 
>> However, are such issues at the discretion of package maintainers and
>> upstream, or is it useful to have a uniform Debian approach to
>> cryptographic strength?
> 
> Keep in mind that RFC 4880 (OpenPGP) hard-codes SHA-1 in several
> places, notably for key fingerprints.  If there's a uniform strength
> requirement, we need some weasel words that GnuPG remains compliant.
> 
> It's also unclear if SHA-256 or SHA-512 is stronger, and if either
> really is that much better than SHA-1.
> 


Just to clarify, although my query was related to the use of this hash
in GnuPG, the reason for the email on debian-devel is for the
system-wide policy on hashes: which could mean any package (e.g. git
uses SHA-1 too, some of the X.509 root certs use an SHA-1 hash)

The first question then - do we even need to care, as a project, about
being pro-active?  Or just leave it at the discretion of derivatives and
end-users to make their own policies?  That's quite OK as long as this
approach is documented.  The security page[1] says "Debian takes
security very seriously" and some users may ask how we apply that
philosophy to SHA-1 given that it is on various alerts[2].

It may be that we say "Some packages include SHA-1 technology and if the
attack potential crosses some threshold X the security team will not
support them."  Then it is up to maintainers and upstreams to think
about and start making plans for the future of their packages.


1. http://www.debian.org/security/

2. http://www.dsd.gov.au/publications/csocprotect/sha-1_deprecated.htm


-- 
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/51cc9db9.8060...@pocock.com.au

system-wide crypto policies

[Daniel Pocock]

There have been various discussions about GnuPG's default use of SHA1, e.g.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612657

which impacts the archive pseudo-package but is also relevant for the
gnupg* packages

However, are such issues at the discretion of package maintainers and
upstream, or is it useful to have a uniform Debian approach to
cryptographic strength?



-- 
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/51cc3709.7000...@pocock.com.au