libphobos-dev build-dep

[Samuel Thibault]

Hello,

The following packages have been in BD-Uninstallable buildd state for a
very long time. This is because they build-depend on the libphobos-dev
virtual package instead of an actual package such as libphobos-4.4-dev
or libphobos-4.8-dev. These packages want to rather build-depend on

libphobos-4.8-dev | libphobos-dev

or

libphobos-4.4-dev | libphobos-dev

As a reminder, buildds do not automatically pick up virtual package
build-dependencies, so as to get deterministic builds: it remains up to
the maintainers of these packages to decide whether it should be built
against libphobos 4.4 or 4.8.

Thanks for fixing your packages.
Samuel

Barry deFreese 
   mu-cade (U)
   titanion (U)
   tumiki-fighters (U)

Debian Games Team 
   a7xpg
   gunroar
   ii-esu
   mu-cade
   parsec47
   projectl
   tatan
   titanion
   torus-trooper
   tumiki-fighters
   val-and-rick

Miriam Ruiz 
   a7xpg (U)
   gunroar (U)
   ii-esu (U)
   mu-cade (U)
   parsec47 (U)
   projectl (U)
   tatan (U)
   titanion (U)
   torus-trooper (U)
   tumiki-fighters (U)
   val-and-rick (U)

Peter De Wachter 
   a7xpg (U)
   gunroar (U)
   ii-esu (U)
   mu-cade (U)
   parsec47 (U)
   projectl (U)
   tatan (U)
   titanion (U)
   torus-trooper (U)
   tumiki-fighters (U)
   val-and-rick (U)

Vincent Fourmond 
   a7xpg (U)
   mu-cade (U)


-- 
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/20140322121110.ga5...@type.youpi.perso.aquilenet.fr

Re: Bug#741930: reportbug: add current init system information

[Thijs Kinkhorst]

>> On Fri, Mar 21, 2014 at 10:00:12PM +0100, Sandro Tosi wrote:
>>> I thought about it a bit, and i'm not sure it's an information every
>>> bug report should have. I suspect there are few packages which are
>>> directly impacted by the possible different init system Debian has,

I think it should be in every report. reportbug currently adds the kernel
version and what /bin/sh points to, and for both of those it can just as
well be argued that they are not relevant to the majority of bug reports.
For those bugs where it will matter, it will save wasted developer time in
extra back and forths, which is the most precious resource we have.


Thijs


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

Re: libphobos-dev build-dep

[Peter De Wachter]

On 22-03-14 13:11, Samuel Thibault wrote:
> Hello,
>
> The following packages have been in BD-Uninstallable buildd state for a
> very long time. This is because they build-depend on the libphobos-dev
> virtual package instead of an actual package such as libphobos-4.4-dev
> or libphobos-4.8-dev.

I think a bit of background information is needed here. These packages
are implemented in the D language. They use the GDC compiler and Phobos
is the D standard library. GDC and Phobos are tightly coupled: each
version of the compiler requires a specific version of the library. As
an extra complication, GDC is build on all architectures but Phobos
currently only works on x86. (I believe ARM support is coming soon.)

All these packages have:
Depends: gdc, libphobos-dev

This works as follows:
- "gdc" is a gcc-defaults meta-package that depends on the current
default GDC compiler.
- The compiler in turn depends on a suitable Phobos implementation, if
one exists.
- The Phobos implementation provides libphobos-dev.
- And this satisfies the original dependency.

If there's no usable Phobos implementation, there will be nothing
providing libphobos-dev and the buildds will not attempt to build the
package. Which is correct, as the packages won't build without Phobos.

I know this scheme is unusual, but I don't see any alternatives. I can't
specify a Phobos version without also specifying a GDC version, and if I
do that I would have to upload new packages with every compiler release.


-- 
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/532d92c4.9040...@gmail.com

Re: libphobos-dev build-dep

[Samuel Thibault]

Peter De Wachter, le Sat 22 Mar 2014 14:40:20 +0100, a écrit :
> GDC is build on all architectures but Phobos
> currently only works on x86. (I believe ARM support is coming soon.)

Would it also work on x86 kfreebsd & hurd?

> All these packages have:
> Depends: gdc, libphobos-dev
> 
> This works as follows:
> - "gdc" is a gcc-defaults meta-package that depends on the current
> default GDC compiler.
> - The compiler in turn depends on a suitable Phobos implementation, if
> one exists.
> - The Phobos implementation provides libphobos-dev.
> - And this satisfies the original dependency.

OK, I see.

Samuel


-- 
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/20140322140946.ga5...@type.youpi.perso.aquilenet.fr

Re: libphobos-dev build-dep

[Julien Cristau]

On Sat, Mar 22, 2014 at 14:40:20 +0100, Peter De Wachter wrote:

> On 22-03-14 13:11, Samuel Thibault wrote:
> > Hello,
> >
> > The following packages have been in BD-Uninstallable buildd state for a
> > very long time. This is because they build-depend on the libphobos-dev
> > virtual package instead of an actual package such as libphobos-4.4-dev
> > or libphobos-4.8-dev.
> 
> I think a bit of background information is needed here. These packages
> are implemented in the D language. They use the GDC compiler and Phobos
> is the D standard library. GDC and Phobos are tightly coupled: each
> version of the compiler requires a specific version of the library. As
> an extra complication, GDC is build on all architectures but Phobos
> currently only works on x86. (I believe ARM support is coming soon.)
> 
> All these packages have:
> Depends: gdc, libphobos-dev
> 
> This works as follows:
> - "gdc" is a gcc-defaults meta-package that depends on the current
> default GDC compiler.
> - The compiler in turn depends on a suitable Phobos implementation, if
> one exists.
> - The Phobos implementation provides libphobos-dev.
> - And this satisfies the original dependency.
> 
Sounds to me like libphobos-dev should be a real package built from
gcc-defaults just like gdc.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: libphobos-dev build-dep

[Steve Langasek]

On Sat, Mar 22, 2014 at 01:11:10PM +0100, Samuel Thibault wrote:
> The following packages have been in BD-Uninstallable buildd state for a
> very long time. This is because they build-depend on the libphobos-dev
> virtual package instead of an actual package such as libphobos-4.4-dev
> or libphobos-4.8-dev. These packages want to rather build-depend on

> libphobos-4.8-dev | libphobos-dev

> or

> libphobos-4.4-dev | libphobos-dev
> 
> As a reminder, buildds do not automatically pick up virtual package
> build-dependencies, so as to get deterministic builds: it remains up to
> the maintainers of these packages to decide whether it should be built
> against libphobos 4.4 or 4.8.

Um, no, build-depending on virtual packages is absolutely allowed.  The
package is in dep-wait because libphobos-4.8-dev is only available on amd64
and i386.  There is *no* reason here for maintainers to change their
build-dependencies.

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

Bug#742370: ITP: golang-testify-dev -- A sacred extension to the standard go testing package

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: golang-testify-dev
  Version : 1.0
  Upstream Author : Mat Ryer and Tyler Bunnel
* URL : http://github.com/stretchr/testify
* License : MIT
  Programming Lang: Go
  Description : A sacred extension to the standard go testing package

Go code (golang) set of packages that provide many tools for testifying
that code behaves as intended.

Features include:
 * Easy assertions
 * Mocking
 * HTTP response trapping
 * Testing suite interfaces and functions

(packaging this because etcd uses 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/20140322213406.22063.88300.reportbug@localhost

Re: libphobos-dev build-dep

[Samuel Thibault]

Steve Langasek, le Sat 22 Mar 2014 12:43:56 -0700, a écrit :
> Um, no, build-depending on virtual packages is absolutely allowed.

Yes, but something has to make the buildd pick up one package which
provides it.  It won't decide by itself which one to choose.

Samuel


-- 
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/20140322235355.gn5...@type.youpi.perso.aquilenet.fr

Re: libphobos-dev build-dep

[Russ Allbery]

Samuel Thibault  writes:
> Steve Langasek, le Sat 22 Mar 2014 12:43:56 -0700, a écrit :

>> Um, no, build-depending on virtual packages is absolutely allowed.

> Yes, but something has to make the buildd pick up one package which
> provides it.  It won't decide by itself which one to choose.

Only if there is more than one package providing the same virtual package.
If there is only one, the buildds will pick that one.  And at the moment
there appears to be only one provider.

The problem, rather, is that the package is not available.

-- 
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: https://lists.debian.org/877g7lsrge@windlord.stanford.edu

package upload failed?

[Brian May]

Yesterday I uploaded the latest version of dar to Debian, using dput.

brian@falidae:~/tree/debian/dar/dar-2.4.12$ cat
../dar_2.4.5.debian.1-1_amd64.ftp-master.upload
Successfully uploaded dar_2.4.5.debian.1-1.dsc to ftp.upload.debian.org for
ftp-master.
Successfully uploaded dar_2.4.5.debian.1.orig.tar.gz to
ftp.upload.debian.org for ftp-master.
Successfully uploaded dar_2.4.5.debian.1-1.debian.tar.gz to
ftp.upload.debian.org for ftp-master.
Successfully uploaded dar-docs_2.4.5.debian.1-1_all.deb to
ftp.upload.debian.org for ftp-master.
Successfully uploaded libdar-dev_2.4.5.debian.1-1_amd64.deb to
ftp.upload.debian.org for ftp-master.
Successfully uploaded libdar64-5_2.4.5.debian.1-1_amd64.deb to
ftp.upload.debian.org for ftp-master.
Successfully uploaded dar_2.4.5.debian.1-1_amd64.deb to
ftp.upload.debian.org for ftp-master.
Successfully uploaded dar_2.4.5.debian.1-1_amd64.changes to
ftp.upload.debian.org for ftp-master.

However I haven't received any notifications or anything since.

If I go here:

ftp://ftp.upload.debian.org/pub/UploadQueue/

I can see some of the files:

* dar-docs_2.4.12-1_all.deb
* dar-static_2.4.12-1_amd64.deb
* dar_2.4.12-1.debian.tar.xz
* dar_2.4.12-1.dsc
* dar_2.4.12-1_amd64.deb
* dar_2.4.12.orig.tar.gz
* libdar-dev_2.4.12-1_amd64.deb
* libdar64-5000_2.4.12-1_amd64.deb

However no sign of the dar_2.4.5.debian.1-1_amd64.changes.

Did I get something wrong?

Thanks
-- 
Brian May 

Re: libphobos-dev build-dep

[Samuel Thibault]

Russ Allbery, le Sat 22 Mar 2014 17:12:49 -0700, a écrit :
> Samuel Thibault  writes:
> > Steve Langasek, le Sat 22 Mar 2014 12:43:56 -0700, a écrit :
> 
> >> Um, no, build-depending on virtual packages is absolutely allowed.
> 
> > Yes, but something has to make the buildd pick up one package which
> > provides it.  It won't decide by itself which one to choose.
> 
> Only if there is more than one package providing the same virtual package.
> If there is only one, the buildds will pick that one.

I don't think so.

If it was true, then we'd have non-deterministic builds depending one
what package happens to be available.

Samuel


-- 
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/20140323005015.gr5...@type.youpi.perso.aquilenet.fr

Re: libphobos-dev build-dep

[Russ Allbery]

Samuel Thibault  writes:
> Russ Allbery, le Sat 22 Mar 2014 17:12:49 -0700, a écrit :

>> Only if there is more than one package providing the same virtual
>> package.  If there is only one, the buildds will pick that one.

> I don't think so.

See how libjpeg-dev has been handled for some time.

> If it was true, then we'd have non-deterministic builds depending one
> what package happens to be available.

That's why only one package Provides the virtual package name when they're
used for this purpose.  It would indeed be a bug if multiple packages
provided the same virtual package name at the same time, but it works if
that is not the case.

This approach is a simpler way of implementing the same thing that
gcc-defaults and boost-defaults do with a separate source package.  It
lets multiple versions of a library exist in the archive at the same time
and for most packages to build-depend on the current "default," which can
then be changed by moving the Provides from one package to another and
then rebuilding everything with binNMUs.

-- 
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: https://lists.debian.org/87lhw1rayu@windlord.stanford.edu

Re: RSA vs ECDSA (Was: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!)

[Henrique de Moraes Holschuh]

On Wed, 05 Mar 2014, peter green wrote:
> Also ECDSA shares with DSA the serious disadvantage over RSA that
> making signatures on a system with a broken RNG can reveal the key.

I believe that we should avoid ECDSA gnupg keys and subkeys like the plague
for the time being.

You'd most likely get ECDSA keys using the NIST p-curves out of gnupg, and
these p-curves are suspected to be backdoored.  AFAIK, better curves are
available only on the latest development versions of gnupg 2.1, and the
difficulties do not end there: the keyservers are also going to be a problem
for such keys and subkeys for a while yet.

IMHO, we should stick with 4096-bit RSA for the main key for the time being,
and use short expire dates for the *subkeys* (2 years or less).

Refer to http://safecurves.cr.yp.to/  for more details on elliptic curves
for crypto.


PS: NIST p-curves are also a potential problem on OpenSSH and DNSSEC.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20140323025114.ga14...@khazad-dum.debian.net

Re: Registering a media type for Debian binary packages ?

[Charles Plessy]

Le Fri, Mar 21, 2014 at 04:07:33PM +0900, Charles Plessy a écrit :
> Hi Guillem and everybody,
> 
> I agree with your suggestions.
> 
> If there are no further comments I will submit the media type after
> correcting the points below.

For the record, here is the latest version.  

Have a nice day,

-- Charles

Type name:
application

Subtype name:
vnd.debian.binary-package

Required parameters:
None.

Optional parameters:
None.

Encoding considerations:
binary

Security considerations:

Debian binary packages can contain scripts executing arbitrary commands during
installation, which is done with administrator privileges.  It is therefore
essential to trust the origin of the package.  The recommended way is to
download packages from Debian format repositories that are authenticated with a
trusted cryptographic key (see the manual page of apt-secure for details).  As
a lesser alternative for cases where secure package manager frontends (such as
APT, cupt, etc.) are not available, the package should be downloaded with
secured protocols such as HTTPS.  There also exists a mechanism for signing
packages directly (called ‘debsigs’), but it is not deployed.

The Debian binary package consists of an ‘ar‘ archive (in old common format)
containing, amongst other things, compressed tar archives for the primary
package contents such as the files to be installed (see the ‘deb’ manual page
for details on the format); it is therefore possible to inspect them with
standard UNIX tools (although the recommended way is through the command
‘dpkg-deb’) without actually installing the package and therefore without
executing the package's scripts.  An estimate of the uncompressed size of the
package may be available in its ‘control’ file, but it can only be trusted if
the package itself is trusted (a malicious person can design a package
containing small compressed files that become extremely large after
decompression).

Since the Debian packages convey programs to be installed on a computer,
the monitoring of a user's downloads over non-secured transport protocols such
as HTTP or FTP may reveal information pertaining to the user's privacy, or
suggest information related to the system's security such as the precise
version numbers of programs in use.

Interoperability considerations:

Arbitrary Debian binary packages can be installed on any system where the
‘dpkg’ package manager is used, but it is recommended to only install packages
that have been built for a release matching the distribution installed on the
system.

Published specification:
http://manpages.debian.org/cgi-bin/man.cgi?query=deb&manpath=Debian+unstable+sid

http://manpages.debian.org/deb

Applications that use this media type:

The Debian binary packages are manipulated by system programs such as ‘dpkg’,
‘apt-get’, graphical front-ends such as ’Synaptic’ but also generic archive
decompressors such as ‘File Roller’.  After downloading a package with a web
browser or after clicking on its icon, front-ends or decompressors are usually
started.

Fragment identifier:
None.

Restrictions on usage:
None.

Additional information:

Deprecated alias names for this type:
application/x-debian-package
application/x-deb

Magic number(s):
Version 2.0 files start with the following string:
!\ndebian-binary

File extension(s):
deb, udeb

Macintosh file type code(s):
None.

Object Identifier(s) or OID(s):
None.

Person & email address to contact for further information:
The Debian Policy mailing list 

Intended usage:
Common

Author:
Charles Plessy 

Change controller:
The Debian 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/20140323025911.GC20063@aqwa.igloo

Re: libphobos-dev build-dep

[Steve Langasek]

On Sun, Mar 23, 2014 at 01:50:16AM +0100, Samuel Thibault wrote:
> Russ Allbery, le Sat 22 Mar 2014 17:12:49 -0700, a écrit :
> > Samuel Thibault  writes:
> > > Steve Langasek, le Sat 22 Mar 2014 12:43:56 -0700, a écrit :

> > >> Um, no, build-depending on virtual packages is absolutely allowed.

> > > Yes, but something has to make the buildd pick up one package which
> > > provides it.  It won't decide by itself which one to choose.

> > Only if there is more than one package providing the same virtual package.
> > If there is only one, the buildds will pick that one.

> I don't think so.

> If it was true, then we'd have non-deterministic builds depending one
> what package happens to be available.

It *is* possible to have non-deterministic builds if you build-depend on a
virtual package provided by more than one real package; this is why, if a
virtual package is provided by more than one real package at a time, you are
expected to indicate the preferred behavior by listing the real package
first before the virtual package in the build-deps.  But this is a matter of
policy, and is not enforced by the buildds.

For the case where there is only one real package providing the virtual
package at any one time (the common case for build-dependencies), this is
unnecessary - and actively counterproductive, since the reason for
build-depending on a virtual package is to avoid forcing a sourceful
transition.

But your case is neither the "more than one provider" case nor the "one
provider" case.  You have zero providers of libphobos-dev on these archs.

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

ca-certificates: no more cacert.org certificates?!?

[Dmitry Smirnov]

I've just noticed that cacert.org certificates was removed from
"ca-certificates" a month ago. From changelog [1]:

* No longer ship cacert.org certificates.  Closes: #718434, LP: #1258286

I'm disappointed by this decision and from #718434 I don't get
a clear picture what is wrong with cacert.org. For years we were
shipping their certificates and IMHO there should be a damn good
reason to stop doing so. I wish maintainer would state the reason for
removal in cahngelog.

Is situation with cacert.org certificates dramatically worsened lately?
Any security flaws were discovered?
What we're gaining from dropping their certificates?

Did we notify cacert.org about our intentions to drop their certificates?
What were their comments? Did they provide time frame to address our concerns?

Cacert.org web of trust model is very similar to ours. To me it is
essentially more trustworthy than what for-profit CAs offer.
Cacert.org (as the only non-profit community managed CA) needs our support.
How dropping cacert.org certificates is going to benefit our communities?

The following comment highlight some benefits of providing cacert.org
certificates:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434#209

I want cacert.org certificates to raise no warning in browsers. This way we
can encourage use of cacert.org certificates as alternative to self-signed
certificates and therefore promote the use of HTTPS.
Users are supposed to check certificate properties for encrypted connections
if/when they want to check certificate authenticity. I think dropping
cacert.org did more harm than good. Perhaps it's better to promote packages like
"xul-ext-certificatepatrol" rather than punish cacert?
After all I'm sure cacert.org team is doing their best just like we all do
in Debian.

[1]: 
http://metadata.ftp-master.debian.org/changelogs/main/c/ca-certificates/unstable_changelog

-- 
Cheers,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

The most fatal blow to progress is slavery of the intellect. The most
sacred right of humanity is the right to think, and next to the right to
think is the right to express that thought without fear.
-- Helen H. Gardner, "Men, Women and Gods"


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

Re: package upload failed?

[Ansgar Burchardt]

Hi,

Brian May  writes:
> Yesterday I uploaded the latest version of dar to Debian, using dput.

The log for queued says:
Mar 22 02:44:41 /dar_2.4.12-1_amd64.changes has bad PGP/GnuPG signature!

As we don't keep files with bad signatures, I cannot tell what was wrong
in this case, but the usual problems are:

 - Wrong key used for signing. Make sure you use the one in the
   Debian keyring.
 - Garbage before or after the PGP signed block.
 - Using --sign instead of --clearsign. Make sure the signature is
   ASCII armored.
 - Key in the keyring is expired.

Ansgar


-- 
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/87vbv5h1f5@eisei.43-1.org

Re: package upload failed?

[Brian May]

On 23 March 2014 17:30, Ansgar Burchardt  wrote:

>  - Wrong key used for signing. Make sure you use the one in the
>Debian keyring.
>

It looks good to me. Oh wait, thought I checked, but seems I somehow used
my old key.

Will retry. Thanks.
-- 
Brian May 

Re: ca-certificates: no more cacert.org certificates?!?

[Andreas Metzler]

Dmitry Smirnov  wrote:
> I've just noticed that cacert.org certificates was removed from
> "ca-certificates" a month ago. From changelog [1]:

>* No longer ship cacert.org certificates.  Closes: #718434, LP: #1258286
[...]

FWIW there is an article about it on 
http://lwn.net/Articles/590879/
cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/73d20b-b63@argenau.downhill.at.eu.org