Re: Delegation for the Release Team

[Lucas Nussbaum]

On 26/12/13 at 13:20 +0100, Lucas Nussbaum wrote:
> Dear Developers,
> 
> It is my great pleasure and honor to officialize the existence and the
> powers of one of Debian's most important teams: the Release Team.

Hi,

I'd like to note that the discussion on this delegation was inconclusive
on a couple of points:

1) it does not include anything about defining rules for NMU delays.

The last time the NMU "policy" was changed was in 2011. The process used
back then was:
- the release team announced its intention to change the policy in 
  https://lists.debian.org/debian-devel-announce/2011/03/msg00016.html
- #625449 was filed against developers-reference
- there was some discussion
- the proposed change made it into developers-reference

I believe that this was a very reasonable way to make such a change, and
that there is no need to give explicit authority to the release team over
the definition of the recommended delays for NMUs in developers-reference[1].
[1] http://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#nmu

Of course, if recommended NMU delays are discussed again in the future,
I think that the release team's opinion should be heard with great
attention, given the role of NMUs in achieving quicker bug fixing and, in
fine, faster releases.


2) it does not include anything about Release Goals.

There's currently a thread on -devel@ about Release Goals, where the rough
consensus seems to be that we need a way to define "technical project-wide
goals", but that the release team is not necessarily the most suitable
team to oversee this (due to the additional workload, and to the fact
that most of such goals are not specific to a *release*).

Also, one could argue that this initial delegation should have documented
the current practice wrt release goals, and that's quite true. However,
(1) I found it very hard to describe the current practice wrt to release
goals, especially without making it overlap with the Technical Committee's
powers;
(2) I think that even if release goals are not explicitely mentioned as
such in the delegation, the powers required for the implementation of a
"release goals" process are being delegated, e.g., the release team can
decide that certain classes of bugfixes are higher-priority and and
suitable for post-freeze inclusion in testing.


Of course, if needed, I am open to updating the delegation in light of
future discussions on those topics.

- Lucas


signature.asc
Description: Digital signature

Re: Delegation for the Release Team

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/26/2013 07:23 AM, Lucas Nussbaum wrote:

> On 26/12/13 at 13:20 +0100, Lucas Nussbaum wrote:
> 
>> Dear Developers,
>> 
>> It is my great pleasure and honor to officialize the existence and
>> the powers of one of Debian's most important teams: the Release
>> Team.
> 
> Hi,
> 
> I'd like to note that the discussion on this delegation was
> inconclusive on a couple of points:

> 2) it does not include anything about Release Goals.
> 
> There's currently a thread on -devel@ about Release Goals, where the
> rough consensus seems to be that we need a way to define "technical
> project-wide goals", but that the release team is not necessarily the
> most suitable team to oversee this (due to the additional workload,
> and to the fact that most of such goals are not specific to a
> *release*).

Just as a note, since I don't recall having seen it mentioned in the
referenced thread:

It's seemed intuitively obvious to me that a "release goal" could
equally be defined as "a new criterion by which a package can be judged
to be RC-buggy". Since "deciding what issues are release-critical" is,
per the delegation announcement, part of the job of the Release Team,
that would naturally seem to fall under their purview. (Conflicting with
this is the fact that, IIRC, the criteria for "release-critical" status
are defined in policy.)

The advantage of classifying a "technical project-wide goal" as a
criterion for RC bugs - and, thus, for exclusion from a release - is
that it provides an impetus for package maintainers to implement the
changes necessary to meet that goal, by providing an enforcement
mechanism.

The major disadvantage, that I see, is that in practice it seems to
leave us with a choice between undesirable alternatives: making
exceptions to that criterion (and thus not progressing towards the
goal), omitting valuable packages from a release, or having an extended
freeze.

I'm not sure, however, that having a "technical project-wide goal"
*without* an enforcement mechanism would even work. While many people -
especially those who have proven themselves far enough to become DDs -
might well work to implement such a goal anyway, whether because they
like and agree with it or just out of a sense of responsibility and good
citizenship, not everyone is that responsible, that involved, or that
committed. Without an enforcement mechanism, I could easily see it
happening that many maintainers would simply let the goal slide, or
otherwise ignore it - and it might never get implemented for their packages.

It isn't certain that that would happen, of course, and even if it were
the threat of release exclusion may not be the only possible enforcement
mechanism. However, I don't think it's unlikely enough to be completely
ignored (except possibly for a "let's try it out and see what happens"
scenario), and I don't think I've seen any other possible mechanisms
proposed - nor have I been able to think of any plausible ones myself.

If an enforcement mechanism for project-wide goals is needed, and if the
only available one is tied to a release, then it seems natural and
appropriate for the release team to be the ones to oversee those goals.
If we don't want them doing that (for whatever reason), then we need to
either decide that no enforcement mechanism is needed, or come up with
one that is not tied to a release - or at least not to the authority of
the release team.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJSvDcLAAoJEASpNY00KDJrkmAP/1B7dBi02gDFQVYtgxo73QHk
dW6Z3hmfV3nFBBL154Mo3jeOQ0fyPTGJpzjAtRrHEt9caW2RPX2dY7C48NbkAAl2
va/SUJ2SL8l0+MpWtQ6BR8h5YXPEQzdfjKsOfkGHddg0YobTmi+j9NaT2G/+Q4Lw
cOLJDhyedopJW4VepH1XbYbhBdIV/LqkP9otvtU+aNbt1aonQM0ZC21kW+uaOoQt
y1NrDqlajaOZIHkAZysayDislYZNlCl47oPUJzwCbKkuSLWl5hPwrpWPbV2jWBGv
+NsE1zYJ0QXpj1U7k/NKuMss6wPRC77SHc3t9KMWJqGdALqgmB8ivO/Fbpp5bDaa
1ACmioZy2TMEuHgpqCn9IG4x1OXBDc3HI/+jmDalvQnKJAomcqP3DdZ32i8q2+LN
c6fkxMy7WXewHCR6uwhnjE483Lg7Mpeyc2xYgOUisaTzunIthTzYvbNtFm2ylxSe
6IRVRw/pvI407gyfU9q3u+pRyRqRMOby4NHMHm8OCm2HU+AU1WN7GH2SqGl4T11+
28q2Z13CqXYlLvDCq0dOxMzKvHk+gwac75AkG91kEv8X4w5Q4Xwvlb4nXXY60uKB
hhnf7Cohsk7pNBlFaf5oz95KiuRIp4E3N8+Z9QthVe5VL7SD+17N+iN+xkGZ0F7y
PEs+bAPZ4YOMewqoFv3C
=+YcY
-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/52bc370c.1090...@fastmail.fm

Re: Delegation for the Release Team

[Adam D. Barratt]

On Thu, 2013-12-26 at 09:02 -0500, The Wanderer wrote:
> It's seemed intuitively obvious to me that a "release goal" could
> equally be defined as "a new criterion by which a package can be judged
> to be RC-buggy".

One of the defining points of release goals (at least as they've
historically existed) is that the issues they cover are _not_
release-critical.

> Since "deciding what issues are release-critical" is,
> per the delegation announcement, part of the job of the Release Team,
> that would naturally seem to fall under their purview. (Conflicting with
> this is the fact that, IIRC, the criteria for "release-critical" status
> are defined in policy.)

Policy indicates that violations of "must" or "required" guidelines
"will generally not be considered acceptable for the Debian
distribution" and are therefore "roughly equivalent to [...] serious". 

It does not touch at all on the other RC severities and its definition
of serious is not all-encompassing, since "maintainer believes package
to be unsuitable for release" is sufficient for a severity:serious bug
and owner@bugs - although iirc he was also RM at the time - passed
responsibility for deciding exactly what constitutes a "serious enough"
policy violation to the release managers some years ago. (At least one
current member of owner@ has expressed a desire to bring the two sets of
issues back in line, but there's at least one current difference between
policy must/should issues and the RC policy for jessie.)

Regards,

Adam


-- 
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/1388068530.7018.25.ca...@jacala.jungle.funky-badger.org

Re: Delegation for the Release Team

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/26/2013 09:35 AM, Adam D. Barratt wrote:

> On Thu, 2013-12-26 at 09:02 -0500, The Wanderer wrote:
> 
>> It's seemed intuitively obvious to me that a "release goal" could
>> equally be defined as "a new criterion by which a package can be
>> judged to be RC-buggy".
> 
> One of the defining points of release goals (at least as they've
> historically existed) is that the issues they cover are _not_
> release-critical.

Hmm.

I've understood it to be the case that a package failing to meet a
release goal had been treated as sufficient to either remove it from
testing, or delay the release. (I'm not sure offhand what that
understanding came from, but I thought I'd seen actual bugs to that
effect.)

If that isn't the case, then I may well be on completely the wrong track.

If it is, however, then that certainly sounds like a close enough match
to the idea (if not the definition) of "release-critical" to me...

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJSvEo7AAoJEASpNY00KDJrNbIP/1psaItFrbMXWTdhhIkxyExk
IIqjPJSLWP5uRDyTZR55wOQnXWteIOSlONWbZ5qllMfh7rB40DNVOnOB6FP78Wky
GE2Y7WeNo3yzRefoP0go2/+91k7NfFdUY/vWbOt4VBBFfpzCXFBZJirqhM8ao6sD
UfYIjvOJ5wYqfZSOVl/S7S0N1HrL5ALE7JKDl3sQjnuOFRR3Uqv2zevInSjYau9d
eWWapQNmnRgS/vjGEsXxLwipzwHxntvv2jNSLbPTGps5FfR1Sildx1nsQCCzcCsK
BvP7fra0dryd9f8QbyQw7BTOAweuowQwR7YpH3l6qLNOXcSv2MYzy1dPd2lu6367
Sp8DAXMEktn1bs6xeOi48do/IqOX1utVfZO+qoR0t5S9sfFqjQW+4N6sVRwWFo6b
Yu6txrKv/Us5Jq3GiEqx34aRVtCOW77JUluBvR4nyJDI10hxl52PZU19UBdm3aQR
v9S39k2GC2QWYylR7FKuEwtbLYY3dQ2viAJtvuWzKIGKClNLn+Wig/WNhBjHmOES
FjOPTEH5vhX+SRRlkZIg+HaG+PlhD26rpS61LHj3uuWeKZ2PMTPgcflKs4CTieWu
m+fG0DGFUK65eaPjb2mticsccoyCNcNaUGzwRtHAK5WGY+8HqM8kSICjJV6MPErT
RQgaum/AsvpCzpxyuOQb
=ZokP
-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/52bc4a3b.9050...@fastmail.fm

Re: GnuTLS in Debian

[Alessandro Ghedini]

On mer, dic 25, 2013 at 01:36:13 -0800, Jonathan Nieder wrote:
> Russ Allbery wrote:
> 
> > Has anyone asked the Git maintainers whether they object to their software
> > being linked with a libcurl that uses OpenSSL?
> 
> I am not the author of the most of Git.  As a minority author:
> 
>  - libcurl provides a quite similar API with OpenSSL as with GnuTLS.
>I wish it provided a compatible ABI.

Different SONAMEs/symbols for different TLS providers is done so that things
that shouldn't, don't get linked against the wrong libcurl flavour (this has
been the case way before I became the curl maintainer).

It can be disabled though, but 1) if all the libcurl versions provided the same
*.so.X.Y,Z files, it'd make it impossible to install different versions at the
same time (e.g. libcurl3 + libcurl3-gnutls) and 2) all libcurl reverse depends
would have to be rebuilt.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature

Re: privacy-breach-google-adsense: how to get rid of it ?

[Andrew Starr-Bochicchio]

On Wed, Dec 25, 2013 at 7:06 PM, Paul Tagliamonte  wrote:
> On Thu, Dec 26, 2013 at 07:26:37AM +0800, Paul Wise wrote:
>> On Thu, Dec 26, 2013 at 4:57 AM, Jerome BENOIT wrote:
>>
>> > is there a proper way to get rid of the recent
>> > privacy-breach-google-adsense Lintian violation/error report [1] ?
>>
>> Same as with every issue in upstream code, report it to upstream and
>> get them to fix it, sending a patch if you are able. That way Debian
>> helps the free software community as a whole, which we promised to do
>> in our social contract:
>>
>> http://www.debian.org/social_contract
>
> I tend to agree. However, what would be doubleplusgood would be to get
> the tools like sphinx, doxygen, and friends to not insert the code when
> we're building a .deb - perhaps we should look at killing this bug in
> generated code by forcing the generated code to suck less.

What exactly are you proposing? At least for Sphinx, and I imagine
other tools, things like adsense aren't automatically injected into
the html. The author must explicitly add this stuff into the template.
I agree that we don't want package documentation in Debian to be
calling home, but if someone using Sphinx as a static webpage
generator wants to add Google Analytics to their site I don't see why
Debian should have a position on that. I certainly don't see Sphinx
upstream adding any code to automatically strip out such things. In
fact, Sphinx Contrib contains a Google Analytics plugin that makes it
easier to add the snippet to the generated files. It also adds a
'google_analytics' option to  conf.py which can be set to False to
disable adding the snippet.

Maybe we should package this for Debian and encourage its use for
people wanting to use GA. That way we'd only need a one line patch to
conf.py rather than some script parsing all the html.

Thanks,

-- Andrew Starr-Bochicchio

   Ubuntu Developer 
   Debian Developer 
   PGP/GPG Key ID: D53FDCB1


-- 
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/CAL6k_AwvU=cttrw+o6q9eppx2r+4urnah+xv6jpdwji4v-i...@mail.gmail.com

Re: Bits from the release team (freeze time line)

[Russ Allbery]

Niels Thykier  writes:

> Britney changes
> ===

> We have deployed a change in Britney that causes her to pay more
> attention to essential packages.  In particular, all packages now have
> to be co-installable with the essential set.  Previously, a package
> could conflict with a essential package.  It would still be considered
> installable by Britney as long as the transitive dependency closure of
> the package did not (explicitly) require the essential package it
> conflicted with.

This has implications for upstart, doesn't it?  It still conflicts with
sysvinit, which is essential.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sitf7an3@windlord.stanford.edu

Re: Bits from the release team (freeze time line)

[Josh Triplett]

On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote:
> Britney changes
> ===
> 
> We have deployed a change in Britney that causes her to pay more
> attention to essential packages.  In particular, all packages now have
> to be co-installable with the essential set.  Previously, a package
> could conflict with a essential package.  It would still be considered
> installable by Britney as long as the transitive dependency closure of
> the package did not (explicitly) require the essential package it
> conflicted with.

Here's the complete list of packages in latest unstable that would
violate this new criterion:

~$ aptitude search '?conflicts(?essential)'
p   systemd-sysv- system and service manager - SysV links
p   upstart - event-based init daemon

This new criterion would seem to make life difficult for the maintainers
of these and other potential future alternatives to the current set of
essential packages.

In addition to the small mountain of discussion ongoing about init
system defaults, there has also been some discussion on the specific
topic of this conflict (specifially, whether the package named
"sysvinit" should drop the Essential flag, or whether it should become a
metapackage depending on multiple alternative providers of /sbin/init).
The latter discussion unfortunately seems to have been deferred in favor
of the former.

Perhaps, in light of the pending tech-ctte decision of doom, it might
make sense to defer enabling this new criterion until at least that
point, to ensure that the maintainers of these two packages can continue
to maintain them and provide upgraded versions?  (To the extent other
external factors have not already prevented proper maintenance of those
packages, such as the unmodified packaging of new upstream versions with
useful new features.)

Or, will there be a testing migration exception for packages which
already exist in testing, which both of these do?

- Josh Triplett


-- 
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/20131226182342.GA5655@leaf

Re: Bits from the release team (freeze time line)

[Steve Langasek]

On Thu, Dec 26, 2013 at 10:03:12AM -0800, Russ Allbery wrote:
> Niels Thykier  writes:

> > We have deployed a change in Britney that causes her to pay more
> > attention to essential packages.  In particular, all packages now have
> > to be co-installable with the essential set.  Previously, a package
> > could conflict with a essential package.  It would still be considered
> > installable by Britney as long as the transitive dependency closure of
> > the package did not (explicitly) require the essential package it
> > conflicted with.

> This has implications for upstart, doesn't it?  It still conflicts with
> sysvinit, which is essential.

On Thu, Dec 26, 2013 at 10:23:42AM -0800, Josh Triplett wrote:

> Here's the complete list of packages in latest unstable that would
> violate this new criterion:

> ~$ aptitude search '?conflicts(?essential)'
> p   systemd-sysv- system and service manager - SysV links
> p   upstart - event-based init daemon

> This new criterion would seem to make life difficult for the maintainers
> of these and other potential future alternatives to the current set of
> essential packages.

Well, the fix is known; I was waiting for feedback on
 before
uploading, but there hasn't been any except for ratholing about openrc. 
I'll go ahead and upload the fixed sysvinit to NEW today.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Bits from the release team (freeze time line)

[Niels Thykier]

On 2013-12-26 19:23, Josh Triplett wrote:
> On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote:
>> Britney changes
>> ===
>>
>> We have deployed a change in Britney that causes her to pay more
>> attention to essential packages.  In particular, all packages now have
>> to be co-installable with the essential set.  Previously, a package
>> could conflict with a essential package.  It would still be considered
>> installable by Britney as long as the transitive dependency closure of
>> the package did not (explicitly) require the essential package it
>> conflicted with.
> 
> Here's the complete list of packages in latest unstable that would
> violate this new criterion:
> 
> ~$ aptitude search '?conflicts(?essential)'
> p   systemd-sysv- system and service manager - SysV links
> p   upstart - event-based init daemon
> 

We knew that upstart was affected and systemd-sysv does not come as a
surprise to me.

> This new criterion would seem to make life difficult for the maintainers
> of these and other potential future alternatives to the current set of
> essential packages.
> 

I do not see how you conclude that it will make life (any more)
difficult.  Anyhow, I think you might be overly concerned about the
downsides of this change compared to the positive side.


> In addition to the small mountain of discussion ongoing about init
> system defaults, there has also been some discussion on the specific
> topic of this conflict (specifially, whether the package named
> "sysvinit" should drop the Essential flag, or whether it should become a
> metapackage depending on multiple alternative providers of /sbin/init).
> The latter discussion unfortunately seems to have been deferred in favor
> of the former.
> 

I am well aware of this discussion.  If sysvinit were to lose its
Essential bit (or we use the metapackage solution), systemd-sysv and
upstart would no longer be affected by this change.

> Perhaps, in light of the pending tech-ctte decision of doom, it might
> make sense to defer enabling this new criterion until at least that
> point, to ensure that the maintainers of these two packages can continue
> to maintain them and provide upgraded versions?  (To the extent other
> external factors have not already prevented proper maintenance of those
> packages, such as the unmodified packaging of new upstream versions with
> useful new features.)
> 

I am not convinced it makes sense to undo this change, in particular ...

> Or, will there be a testing migration exception for packages which
> already exist in testing, which both of these do?
> 
> - Josh Triplett
> 
> 

Yes, there are.  In general, a package can still migrate to testing as
long as it does not increase the total number of uninstallable packages.
 This is a privilege packages in testing have that sid ones generally do
not[1].  Only new reverse dependencies will require manual action (and
then, only once).
  Mind you, such packages are still "second-class" in Britney's eyes,
since she will *not* prevent them from becoming "less installable" (e.g.
she will happy remove a package they depend etc.).


Also note that the change makes Britney handle this situation a lot more
consistent and in line with what the end-user sees with APT or dpkg.
Packages that have a versioned breaks on an essential package can no
longer migrate to testing before the updated version of the essential
package.  While very rarely, such issues have occurred in the past.

~Niels

[1] Because a package in sid would generally add a new "uninstallable"
package rather than update an existing one.  Though, exceptions can
occur with "hijacks" of binary packages - but still.



-- 
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/52bc83f9.1020...@thykier.net

Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?

[Vincent Bernat]

 ❦ 26 décembre 2013 01:04 CET, Colin Watson  :

> It is true that compatibility is sometimes less than ideal, but brushing
> the problem under the carpet just means that somebody gets to discover
> this when they're in a hurry trying to fix some unrelated problem years
> later, when the change in the autotools has been largely forgotten
> about, rather than it being fixed in a timely fashion.

Urgent updates, like security issues, seldomly need to patch the build
system. For one hour spent by the maintainer to fix the build system to
be able to build with a more recent version of automake or a more
ancient version of automake, how much time is saved by a third-party
person? Most of the time, none.

We don't need to put more burden on maintainers. It is better to really
build from sources and it is good if you spend time on it, but IMO, we
can't afford to make this a rule.
-- 
# Okay, what on Earth is this one supposed to be used for?
2.4.0 linux/drivers/char/cp437.uni


signature.asc
Description: PGP signature

Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?

[Russ Allbery]

Vincent Bernat  writes:
>  ❦ 26 décembre 2013 01:04 CET, Colin Watson  :

>> It is true that compatibility is sometimes less than ideal, but
>> brushing the problem under the carpet just means that somebody gets to
>> discover this when they're in a hurry trying to fix some unrelated
>> problem years later, when the change in the autotools has been largely
>> forgotten about, rather than it being fixed in a timely fashion.

> Urgent updates, like security issues, seldomly need to patch the build
> system. For one hour spent by the maintainer to fix the build system to
> be able to build with a more recent version of automake or a more
> ancient version of automake, how much time is saved by a third-party
> person? Most of the time, none.

Well, the build system is going to need to get updated to the newer
version of automake eventually, yes?  Otherwise, you end up having to keep
separately-installed obsolete copies of Automake around to maintain the
source.  The Debian automake package maintainer isn't going to want to
keep every version in the archive forever.

There therefore isn't any *global* savings of time in the long run apart
from the time savings from batching upgrades (upgrading across several
versions of Automake at once).  Of course, it may change the balance of
the work between the Debian package maintainer and upstream.

> We don't need to put more burden on maintainers. It is better to really
> build from sources and it is good if you spend time on it, but IMO, we
> can't afford to make this a rule.

I'm similarly a bit dubious about making it a rule, mostly because we
already put substantial up-front burdens in the way of someone packaging a
new piece of software, and I think one of the best ways to get people
involved in Debian is to help them get something they're interested in
using into the archive.  That said, I think we're accumulating technical
debt every time we accept something that relies on an obsolete version of
Automake, so I would encourage people to try to port their packages.

I'm upstream for a whole ton of stuff that uses Automake, and I've almost
never had any problems with newer versions that took more than a few
minutes to fix.  My sense from following the Automake development list is
that the people who run into a lot of upgrade issues are *mostly*
(although not always) using rather obscure corners of Automake and doing
things in fancy or non-standard ways, which makes them more vulnerable to
problems during upgrades.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sitf5q66@windlord.stanford.edu

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

[Zbigniew Jędrzejewski-Szmek]

On Sun, Dec 22, 2013 at 03:56:04PM -0800, Russ Allbery wrote:
> Zbigniew Jędrzejewski-Szmek  writes:
> 
> > But this should be safe for instance units, so I'd like to see
> > 'systemctl stop/status/... server@*.service' implemented.
> 
> That would be very useful for distribution packagers.  If, for example,
> you support a multiple-instance Tomcat configuration (which is quite nice
> to do, since it isolates Java applications that may require different
> override JARs), you want to restart all of them when you upgrade the
> packaged Tomcat.

This bug can be considered fixed upstream:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=e3e0314b56012f7

I doubt that anyone would want to port it to systemd <= 208, because
in the porting to libsystemd-bus has been completely rewritten from
earlier versions. But it'll be part of systemd 209.

Zbyszek


-- 
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/20131226210534.go2...@in.waw.pl

Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?

[Tollef Fog Heen]

]] Vincent Bernat 

> We don't need to put more burden on maintainers. It is better to really
> build from sources and it is good if you spend time on it, but IMO, we
> can't afford to make this a rule.

Given that the configure is automatically generated from configure.ac,
it's pretty clear that configure.ac is the source and configure isn't,
really.  It's some kind of intermediate format.

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


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

Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?

[Vincent Bernat]

 ❦ 26 décembre 2013 21:10 CET, Russ Allbery  :

>> Urgent updates, like security issues, seldom need to patch the build
>> system. For one hour spent by the maintainer to fix the build system to
>> be able to build with a more recent version of automake or a more
>> ancient version of automake, how much time is saved by a third-party
>> person? Most of the time, none.
>
> Well, the build system is going to need to get updated to the newer
> version of automake eventually, yes?  Otherwise, you end up having to keep
> separately-installed obsolete copies of Automake around to maintain the
> source.  The Debian automake package maintainer isn't going to want to
> keep every version in the archive forever.

Yes, eventually, the build system will get updated. But I don't need a
FTBFS bug and a special upload for this. This takes unecessary time to
fix it only for Debian while it will eventually be fixed upstream. I am
not speaking of outdated build system, I am only speaking of automake
being a project changing rules in a backward and forward incompatible
way (subdir-objects, AM_INIT_AUTOMAKE, ...).

See for example libevent which is a well-maintained software. It won't
compile with automake 1.13 and later (because automake thinks that using
$(top_srcdir) in TESTS is broken while it worked perfectly). This will
be fixed when libevent 2.0.22 will be released. In the meantime, nobody
complained about this problem. Should we take time to fix a problem that
nobody sees?
-- 
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?

[Colin Watson]

On Thu, Dec 26, 2013 at 09:01:29PM +0100, Vincent Bernat wrote:
>  ❦ 26 décembre 2013 01:04 CET, Colin Watson  :
> > It is true that compatibility is sometimes less than ideal, but brushing
> > the problem under the carpet just means that somebody gets to discover
> > this when they're in a hurry trying to fix some unrelated problem years
> > later, when the change in the autotools has been largely forgotten
> > about, rather than it being fixed in a timely fashion.
> 
> Urgent updates, like security issues, seldomly need to patch the build
> system. For one hour spent by the maintainer to fix the build system to
> be able to build with a more recent version of automake or a more
> ancient version of automake, how much time is saved by a third-party
> person? Most of the time, none.

I agree with Russ' reply to this, to the effect that the global time
spent doesn't really change much; it just moves it around.  I would add
that it's better for the package maintainer to deal with this kind of
thing, since they're familiar with the package, than for drive-by
bug-fixers to have to figure it out.

My perspective on this is rather different from yours, as I *have* been
in the position of having to patch build systems for some pretty urgent
fixes, quite frequently even.  In a few cases I have even had to resort
to holding my nose and patching *only* the generated files because it
was just too hideously painful to make them behave properly when the
true source files were touched at all.  Nowadays my position is: no
more.  I understand the autotools well enough that I'll take the time to
fix it properly, damn it, so that the next person doesn't have the same
problem.

> We don't need to put more burden on maintainers. It is better to really
> build from sources and it is good if you spend time on it, but IMO, we
> can't afford to make this a rule.

Note that I wasn't suggesting it should be made a rule, mainly because
it would be a completely unrealistic rule today.  I would like to
eventually get there, but for the meantime I'd settle for it being a
strong guideline and sending a ton of patches to move that along as best
I can.

Of course, autoreconfing has been a strong guideline in
/usr/share/doc/autotools-dev/README.Debian.gz for at least 4.5 years
now, which is referenced from devref 6.7.1 ... the trick is to get
enough people to notice it.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131226222350.ga19...@riva.ucam.org

Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?

[Colin Watson]

On Thu, Dec 26, 2013 at 11:09:38PM +0100, Vincent Bernat wrote:
> See for example libevent which is a well-maintained software. It won't
> compile with automake 1.13 and later (because automake thinks that using
> $(top_srcdir) in TESTS is broken while it worked perfectly). This will
> be fixed when libevent 2.0.22 will be released. In the meantime, nobody
> complained about this problem. Should we take time to fix a problem that
> nobody sees?

You say "nobody", but in fact we did have to patch libevent in Ubuntu to
make it build on ppc64el; yet another point where what could have been a
largely automated process had to stop and wait for human intervention.
Matthias should forward the patch for that (*poke*), but it's:

  
https://launchpadlibrarian.net/158354967/libevent_2.0.21-stable-1_2.0.21-stable-1ubuntu1.diff.gz

Having to wait for new upstream releases when you're trying to get a
port done sucks.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131226222751.gb19...@riva.ucam.org

Re: privacy-breach-google-adsense: how to get rid of it ?

[Paul Tagliamonte]

On Thu, Dec 26, 2013 at 01:00:56PM -0500, Andrew Starr-Bochicchio wrote:
> What exactly are you proposing? At least for Sphinx, and I imagine
> other tools, things like adsense aren't automatically injected into
> the html.

Erm, my memory officially sucks. I was confusing Sphinx with
readthedocs, it's a config option there, and for some reason I thoguht
it was a config option for Sphinx.

Ignore that last mail.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: Bug#732878: Add MariaDB as an alternative dependency

[Otto Kekäläinen]

2013/12/25 Thomas Goirand :
> Don't you think it would be more reasonable if the mariadb-client
> contained a Provides: mysql-client, rather than changing each and every
> software dependency in Debian?

Currently the package contains "Provides: virtual-mysql-server" but I
guess this needs to be re-evaluated in the packaging team and the
rationale documented better, as I have already forgot why we ended up
with what we have now..

> P.S: Do you know if the MariaDB package in Sid has the capability to run
> in cluster, like for Galera?

No, but I might package MariaDB Galera Cluster later if I have time
and energy for additional packages. However before that I'll do
MariaDB 10.0 (Debian now only got 5.5).


-- 
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/CAHj_TLDtLiFvQzVOQ2p_VF1DKed4MAz076C2FCZV=rm1f8z...@mail.gmail.com

Bug#733201: RFP: automake -- autogen.sh looks for automake-1.13

[José Antonio S.A.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

- --- Please fill out the fields below. ---

   Package name: automake
Version: 1:1.14-3
Upstream Author: [NAME ]
URL: [http://example.com]
License: [GPL, LGPL, BSD, MIT/X, etc.]
Description:
I have tried to compile  rhythmbox  from git repository.


$./autogen.sh --help
Can't locate Automake/Config.pm in @INC (you may need to install the
Automake::Config module) (@INC contains: /usr/share/automake-1.13
/etc/perl /usr/local/lib/perl/5.18.1 /usr/local/share/perl/5.18.1
/usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18
/usr/local/lib/site_perl .) at /usr/bin/aclocal line 37.
BEGIN failed--compilation aborted at /usr/bin/aclocal line 37.
*** No yelp-tools found, please install it ***



I have linked aclocal to aclocal-1.4

/usr/bin/aclocal -> /usr/bin/aclocal-1.14


and automake to automake-1.14

/usr/bin/automake -> /usr/bin/automake-1.14


Not it seems to work fine.

Regards!
Jose Antonio Salgueiro

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

iF4EAREIAAYFAlK8x88ACgkQiIkUvo0orI806AD7B1Abt8fxNXRD+RU0L6GyxMi5
NkLNwHuqhf4m7mBcnHUA/0Ejvy6RT1woW2qgZYWcUbYzi2Fe/rH56xX6qs3aibAM
=8d3Y
-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/52bcc7d2.2060...@gmail.com

Re: privacy-breach-google-adsense: how to get rid of it ?

[Paul Wise]

On Thu, 2013-12-26 at 13:00 -0500, Andrew Starr-Bochicchio wrote:

> What exactly are you proposing? At least for Sphinx, and I imagine
> other tools, things like adsense aren't automatically injected into
> the html. The author must explicitly add this stuff into the template.
> I agree that we don't want package documentation in Debian to be
> calling home, but if someone using Sphinx as a static webpage
> generator wants to add Google Analytics to their site I don't see why
> Debian should have a position on that. I certainly don't see Sphinx
> upstream adding any code to automatically strip out such things. In
> fact, Sphinx Contrib contains a Google Analytics plugin that makes it
> easier to add the snippet to the generated files. It also adds a
> 'google_analytics' option to  conf.py which can be set to False to
> disable adding the snippet.

Thoughts:

Google Analytics is non-free JavaScript running in user's browsers and
non-free code running on Google servers. As promoters of software and
user freedom I think this provides a solid reason for us to encourage
upstreams to just drop GA or switch a libre alternative solution like
piwik if they need to analyse website visitor traffic.

Asking website visitors to report themselves to one of the larger
commercial surveillance and advertising networks in the world isn't a
particularly friendly thing to do. Most web browsers will blindly load
GA so in practice this is actually forcing most website visitors to
report to Google. Surveillance isn't good for user freedom so I think
this provides another reason to encourage upstreams to drop GA.

Personally whenever I see this tag or this issue on upstream websites I
will encourage them to either just drop GA or use piwik instead if they
actually need what GA provides. I encourage everyone else on this list
to do the same. I also encourage people to consider disabling JavaScript
in your browser by default. As the Tor/Firefox attacks (CVE-2013-1690)
showed, this is a good idea anyway.

> Maybe we should package this for Debian and encourage its use for
> people wanting to use GA. That way we'd only need a one line patch to
> conf.py rather than some script parsing all the html.

That sounds like a good idea.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Work-needing packages report for Dec 27, 2013

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 529 (new: 3)
Total number of packages offered up for adoption: 158 (new: 1)
Total number of packages requested help for: 55 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   mdetect (#733143), orphaned today
 Description: mouse device autodetection tool
 Reverse Depends: ltsp-client
 Installations reported by Popcon: 1789

   read-edid (#733145), orphaned today
 Description: hardware information-gathering tool for VESA PnP
   monitors
 Installations reported by Popcon: 3185

   zziplib (#733144), orphaned today
 Description: library providing read access on ZIP-archives -
   binaries
 Reverse Depends: libacexml-6.0.3 libconcord3 libogre-1.7.4
   libogre-1.8.0 libogre-1.9.0 libogre-dev libzzip-dev lua-zip
   ogre-1.9-tools zziplib-bin
 Installations reported by Popcon: 2660

526 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   apron (#733101), offered yesterday
 Description: abstract interpretation library
 Reverse Depends: libapron-ocaml libapron-ocaml-dev
 Installations reported by Popcon: 8

157 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 1424 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache fuss-launcher goplay packagesearch
 Installations reported by Popcon: 77781

   athcool (#278442), requested 3348 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 52

   balsa (#642906), requested 823 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 809

   cardstories (#624100), requested 976 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 11

   chromium-browser (#583826), requested 1306 days ago
 Description: Chromium browser
 Reverse Depends: chromium chromium-dbg chromium-l10n mozplugger
 Installations reported by Popcon: 23271

   cups (#532097), requested 1664 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups chromium cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client cups-daemon cups-dbg cups-filters
   (58 more omitted)
 Installations reported by Popcon: 132234

   debtags (#567954), requested 1424 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2432

   fbcat (#565156), requested 1443 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 146

   freeipmi (#628062), requested 945 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect
   freeipmi-tools libfreeipmi-dev libfreeipmi12 libipmiconsole-dev
   libipmiconsole2 libipmidetect-dev libipmidetect0 (3 more omitted)
 Installations reported by Popcon: 4250

   gnat-4.4 (#539562), requested 2086 days ago
 Description: help needed to execute test cases
 Reverse Depends: dh-ada-library ghdl gnat-4.4 libgnat-4.4
   libgnat-4.4-dbg libgnatprj-dev libgnatprj4.4 libgnatprj4.4-dbg
   libgnatprj4.4-dev libgnatvsn-dev (3 more omitted)
 Installations reported by Popcon: 1006

   gnat-gps (#496905), requested 1946 days ago
 Description: co-maintainer needed
 Reverse Depends: gnat-gps gnat-gps-dbg
 Installations reported by Popcon: 530

   gnokii (#677750), requested 558 days ago
 Description: Datasuite for mobile phone management
 Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql
   gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6
   xgnokii
 Installations reported by Popcon: 1866

   gnupg (#660685), requested 675 days ago
 Description: GNU privacy guard - a free PGP replacement
 Reverse Depends: apt bootstrap-base cdebootstrap cdebootstrap-static
   cdebootstrap-udeb clamav-unofficial-sigs cloud-utils
   debian-archive-keyring debian-edu-archive-keyring
   debian-ports-archive-keyring (52 more omitted)
 Installations reported by Popcon: 161230

  

Re: Bug#733045: debhelper: Can debhelper make autotools-dev updating default behaviour?

[Paul Wise]

On Thu, Dec 26, 2013 at 7:34 AM, Paul Wise wrote:

> Building as much as possible from source at package build time should
> be the norm not the exception, otherwise the build process for that
> source will bitrot and we will never detect that.

Having said that, I expect there will be exceptions to this (examples
I can think of below). We currently don't have any standard way to
check that these exceptions are still buildable from source.

For example:

Packages that contain raytraced images that take a month or more to
render. We probably don't want to rebuild those every time. Various
games are probably an example of this.

Packages that need to download data from the Internet and munge it
into a cached form. lintian is an example of this, usually this is
done at release time. fonttools is another example, it has a
seldom-run (and now broken) script to extract table names from the
OpenType spec and put them in a python module.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6e8hmnh4pzkab55zv0kwkm-zpejjzouokt6sk6dapa...@mail.gmail.com

Re: Bug#732878: Add MariaDB as an alternative dependency

[Clint Byrum]

Excerpts from Ben Hutchings's message of 2013-12-25 04:32:01 -0800:
> On Wed, 2013-12-25 at 03:41 -0800, Clint Byrum wrote:
> > Excerpts from Vincent Bernat's message of 2013-12-25 03:36:30 -0800:
> > >  ❦ 25 décembre 2013 08:27 CET, Thomas Goirand  :
> > > 
> > > > Don't you think it would be more reasonable if the mariadb-client
> > > > contained a Provides: mysql-client, rather than changing each and every
> > > > software dependency in Debian?
> > > 
> > > Maybe MariaDB wants to be the "default" MySQL implementation?
> > 
> > MariaDB is not MySQL, so this is not really what you mean. Also I'd ask
> > that you suggest why you think there should be a default, and why you
> > think that "MySQL" should not be the default "MySQL".
> 
> Similarly,
> 
> wodim is not cdrecord
> LibreOffice is not OpenOffice.org
> Iceweasel is not Firefox
> etc.
> 
> so clearly we should never have implemented an automatic transition from
> one to the other...
> 

As far as I know, we are not planning any such automatic transition from
MySQL to MariaDB. They will both remain in Debian as long as there are
parties available to maintain them. Percona Server will also be arriving
soon, and now I see talk of Galera enabled MySQL variants as well.

This is quite a bit different from those three desktop programs you
mentioned.


-- 
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/1388108468-sup-5003@clint-HP

Re: Bug#732878: Add MariaDB as an alternative dependency

[Clint Byrum]

Excerpts from Vincent Bernat's message of 2013-12-25 09:52:40 -0800:
>  ❦ 25 décembre 2013 12:41 CET, Clint Byrum  :
> 
> >> > Don't you think it would be more reasonable if the mariadb-client
> >> > contained a Provides: mysql-client, rather than changing each and every
> >> > software dependency in Debian?
> >> 
> >> Maybe MariaDB wants to be the "default" MySQL implementation?
> >
> > MariaDB is not MySQL, so this is not really what you mean. Also I'd ask
> > that you suggest why you think there should be a default, and why you
> > think that "MySQL" should not be the default "MySQL".
> 
> I am saying this because the bug reports about adding support for
> MariaDB were asking for mariadb-client | mysql-client and not
> mysql-client | mariadb-client. My question is genuine, I really don't
> know. Do we plan to transition away from MySQL to MariaDB?

No such plan is under way. I am one of the few people maintaining MySQL,
but others have recently stepped up to get us onto git, to get MySQL
5.6 ready, and to do general work, so MySQL seems like it may remain in
Debian. As long as it does, there is no "automatic transition". They are
forked, and more so than ever with MariaDB 10, so we should just treat
them as such.


-- 
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/1388108595-sup-7918@clint-HP

Re: privacy-breach-google-adsense: how to get rid of it ?

[Russ Allbery]

Paul Wise  writes:

> Personally whenever I see this tag or this issue on upstream websites I
> will encourage them to either just drop GA or use piwik instead if they
> actually need what GA provides. I encourage everyone else on this list
> to do the same.

If we could manage to get piwik packaged for Debian, it would make this
easier to do (not to mention help out at my day job).

See:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448532

for some of the history.  I believe there are remaining non-free source
file issues (which may be fixable through simply repackaging upstream).

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87eh4z3rrb@windlord.stanford.edu

Bug#733205: ITP: python-args -- Command Arguments for Humans

[TANIGUCHI Takaki]

Package: wnpp
Owner: tak...@debian.org
Severity: wishlist

* Package name: python-args
  Version : 0.1.0
  Upstream Author : Kenneth Reitz
* URL or Web page : https://github.com/kennethreitz/args
* License : BSD
  Description : Command Arguments for Humans
 This simple python module gives you an elegant interface for your
 command line argumemnts.


-- 
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/87sitf0znk.wl%tak...@debian.org

Bug#733211: ITP: awscli -- Universal Command Line Environment for AWS

[TANIGUCHI Takaki]

Package: wnpp
Owner: tak...@debian.org
Severity: wishlist

* Package name: awscli
  Version : 1.2.9
  Upstream Author : Amazon.com, Iinc.
* URL or Web page : http://aws.amazon.com/cli/
* License : Apache
  Description : Universal Command Line Environment for AWS
 This package provides a unified command line interface to many
 Amazon Web Services.
 .
 The currently supported services include:
 .
  * AWS CloudFormation
  * AWS Data Pipeline
  * AWS Direct Connect
  * AWS Elastic Beanstalk
  * AWS Identity and Access Management
  * AWS Import/Export
  * AWS OpsWorks
  * AWS Security Token Service
  * AWS Storage Gateway
  * Amazon CloudWatch
  * Amazon ElastiCache
  * Amazon Elastic Compute Cloud
  * Amazon Elastic MapReduce
  * Amazon Elastic Transcoder
  * Amazon Redshift
  * Amazon Relational Database Service (Beta)
  * Amazon Simple Email Service
  * Amazon Simple Notification Service
  * Amazon Simple Queue Service
  * Amazon Simple Storage Service
  * Amazon Simple Workflow Service
  * Auto Scaling
  * Elastic Load Balancing


-- 
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/87r48y24e5.wl%tak...@debian.org

On building everything from source.

[Charles Plessy]

Le Fri, Dec 27, 2013 at 09:36:33AM +0800, Paul Wise a écrit :
> On Thu, Dec 26, 2013 at 7:34 AM, Paul Wise wrote:
> 
> > Building as much as possible from source at package build time should
> > be the norm not the exception, otherwise the build process for that
> > source will bitrot and we will never detect that.
> 
> Having said that, I expect there will be exceptions to this (examples
> I can think of below). We currently don't have any standard way to
> check that these exceptions are still buildable from source.

Thanks for the clarification, Paul.

On my side, I feel an increased social and sometime formal pressure to build
things from source with no clear limit, and this is chilling effects that make
me abandon more and more packages and focus on the most trivial works to
package.  More becomes less, for instance when Upstream adds pictures to their
documentation, etc.

I would welcome clearer rules to decide what is strictly required to be built
from source.  In particular, I would welcome something like "The maintainer
decides, and can be overruled by the Technical Comittee if needed".  What
follows is not intended as a gratuitous rant but is my experience of a
packager: the long delays at the NEW queue, the variability of the decisions
(which depend on who reviews the package), the unpredictability of when a
source package goes to NEW (that is, when the list of binary packages changes),
and the impossibility of using our archive as a guide of what is acceptable
(since it contains things that would not be accepted anymore) are making it
too difficult to support packages over years.

Needless to say, since we have a nice upstream guide, reminding Upstream about
the importance of being as rebuildable as possible is something that is easy to
be done.  But not if the emails finish by things like "in the meantime, we have
deleted your documentation from our packages".

Have a nice day,

-- 
Charles Plessy
Illkirch-Graffenstaden, France


-- 
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/20131227071931.ga2...@falafel.plessy.net

Bug#733212: ITP: librunning-commentary-perl -- Perl module to call system() with tracking messages

[Salvatore Bonaccorso]

Package: wnpp
Owner: Salvatore Bonaccorso 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: librunning-commentary-perl
  Version : 0.05
  Upstream Author : Damian Conway 
* URL : https://metacpan.org/release/Running-Commentary
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to call system() with tracking messages

Running::Commentary provides a single subroutine: run() which is
designed to be a more informative and less error-prone replacement for
the built-in system(). run() acts like system(), except that it returns
true on success and false on failure, and it announces what it's doing.

It also provides a compile-time keyword: run_with with which you can set
lexically scoped default options for run().


-- 
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/1388128845.160994.11953@lorien