Re: Bits from keyring-maint

[Luca Capello]

Hi there!

On Wed, 15 Sep 2010 22:15:25 +0200, Tollef Fog Heen wrote:
> ]] Henrique de Moraes Holschuh 
>
> | I just wondering where I am supposed to find a good smartcard that can
> | take 2048R (or larger) keys, works well with gnupg, and for how much :)
>
> http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=42
> does 3072 bit keys and are quite reasonably priced.

This is a very unfortunate change, since the OpenPGP smartcard v2.0
webpage still reports 2048-bit RSA keys and not having changed the
version number if there has been an improvement to 3072-bit keys is a
*very bad* decision:

  http://www.g10code.com/p-card.html

> AFAIK, the onboard software isn't free, though.

True, as it was the case for the v1.0.

Thx, bye,
Gismo / Luca


pgpIs1NXozX3e.pgp
Description: PGP signature

Re: [RFC] Binary packages containing the source

[Josselin Mouette]

Le jeudi 16 septembre 2010 à 03:08 +0200, Jakub Wilk a écrit :
> * Hector Oron , 2010-09-15, 21:26:
> >  c) allow build depends on source packages, which it is probably a worst 
> > idea.
> 
> On the contrary, I think that allowing source packages to be installable 
> in the same way as binary packages is an excellent idea. Imagine you can 
> do:
> 
> apt-get install src:linux-2.6
> 
> which will install Linux sources into a standard location, or upgrade it 
> if it's already installed.

I agree this is a cleaner solution, but how do you ensure there are
sources (deb-src) referenced in the sources.list ?

Plus, these packages would (in the current state of affairs) lack a
description.

-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
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/1284621777.10697.21.ca...@meh

Re: [RFC] Binary packages containing the source

[Stefano Zacchiroli]

On Thu, Sep 16, 2010 at 09:22:57AM +0200, Josselin Mouette wrote:
> Plus, these packages would (in the current state of affairs) lack a
> description.

On this topic, we have our friend #555743. 

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Bits from keyring-maint

[Luca Capello]

Hi there!

On Thu, 16 Sep 2010 00:38:25 +0200, Manoj Srivastava wrote:
> On Wed, Sep 15 2010, Henrique de Moraes Holschuh wrote:
>> As for the large keysize, it is seen as too large.  It was recommended
>> that Debian should try to do something that would help reduce the
>> overall threat to the Debian PKI instead of promoting very large key
>> sizes *in order to acommodate for very large key lifetimes*.
>>
>> The recommendation for that one was: smartcards, use main key as a KSK
>> only, and don't let it leave the smartcard.  subkeys have several
>> advantages, they can be smaller than the main key, and they can be
>> replaced without web of trust issues (so you could replace them often,
>> and give them a validity of only 1-2 years).
>
> I did not like that, since the card presumably travels with the
>  person, and thus has the potential of getting lost. I prefer to
>  generate my main key and than store it on read-only media, away from
>  any network or computer. The subkeys are what live on the card.

Another reason for not storing the main key on the OpenPGP smartcard is
that smartcards can break and I personally broke some v1.0 OpenPGP
smartcards, both by "chance" (keeping the FSFE Fellowship card in my
pants' backpocket) or while trying to cut them to SIM size.

And please note that all the official documentation, as well as the
unofficial one, advises to store on the smartcard only subkeys and to
make an offline backup of (at least) the encryption subkey (you do not
care about the signature one and the authorization [1] one can be
replaced).

FWIW, in Debian we should use the already available wiki page:

  http://wiki.debian.org/Smartcards/OpenPGP

>> One would use the smartcard only to generate new subkeys and UIDs, and
>> to sign other keys (otherwise, you'd need to re-sign already-signed UIDs
>> when the subkey is about to expire. I didn't check if gnupg lets you use
>> subkeys to sign UIDs on other keys).
>
> I use my card for everyday uses, and to sign emails. Signing
>  keys is more involved, though that has ony happened 15 times for me so
>  far.

I did this with my (second-)old key (0x9DDB992B), but not yet with the
new one (0xE397832F).  OTOH, with the new one it is mostly the same as
using the OpenPGP smartcard, at least in principle, given that I
generated a signing/encryption/authorization subkey for everyday usage,
while keeping my primary key offline.  As Manoj wrote, the only reason
for primary key usage (obviously, except generating new subkeys) is
signing keys.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] by default, GnuPG offers to generate an authorization subkey only in
expert mode!


pgpjhYU0texAL.pgp
Description: PGP signature

Bug#597053: ITP: sparkleshare -- git-backed file sharing and collaboration tool

[Iain Lane]

Package: wnpp
Severity: wishlist
Owner: Debian CLI Applications Team 

* Package name: sparkleshare
  Version : 0.2~beta1
  Upstream Author : Hylke Bons 
* URL : http://sparkleshare.org/
* License : GPLv3
  Programming Lang: C#
  Description : git-backed file sharing and collaboration tool

SparkleShare is a syncing and collaboration tool that is designed to
get out of your way, to make sharing documents and collaboration
easier, and to make peers aware of what you are doing.
..
SparkleShare uses git as its storage backend (server) component. There
are default profiles present for the Gitorious, Github and GNOME
servers, but users can add their own as well.



-- 
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/20100916080332.31847.23481.report...@localhost6.localdomain6

Re: [RFC] Binary packages containing the source

[Stéphane Glondu]

Le 16/09/2010 09:22, Josselin Mouette a écrit :
> I agree this is a cleaner solution, but how do you ensure there are
> sources (deb-src) referenced in the sources.list ?

You don't need to. The package would be reported as uninstallable. Some
message suggesting to add deb-src lines to sources.list could be
displayed in such circumstances, though.

-- 
Stéphane


--
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/4c91cdb7.20...@debian.org

RFC: Rules for distro-friendly packages

[Enrico Weigelt]

Hi folks,


I've collected several rules that upstreams should follow to make
distro maintainer's life much easier:

http://www.metux.de/index.php/de/component/content/article/57.html

Free feel to comment on it :)


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: i...@metux.de   skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
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/4c91d7fe.5030...@metux.de

Re: RFC: Rules for distro-friendly packages

[Vincent Bernat]

On Thu, 16 Sep 2010 10:40:30 +0200, Enrico Weigelt 
wrote:

> I've collected several rules that upstreams should follow to make
> distro maintainer's life much easier:
> 
> http://www.metux.de/index.php/de/component/content/article/57.html
> 
> Free feel to comment on it :)

About autoconf stuff:
 - Why require autogen.sh? On a release, configure script should be
present. No need to rebuild it. Some users just don't have recent enough
autotools to rebuild the configure. Moreover, with modern autotools, I tend
to think that autoreconf -i is just as simple as autogen.sh.
 - Why require building in a separate tree? Why it helps, most of the
packages we have just build in the same source tree.
 - Not using AC_TRY_RUN is too strong. This macro has a parameter to be
used when cross-compiling. It is more useful to detect a problem when not
cross-compiling with AC_TRY_RUN than to not detect it at all.


-- 
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/0668dd331505dad9896cff083909a...@chopper.luffy.cx

Re: RFC: Rules for distro-friendly packages

[Enrico Weigelt]

* Vincent Bernat  schrieb:

Hi,

> About autoconf stuff:
>  - Why require autogen.sh? On a release, configure script should be
> present. No need to rebuild it. 

No, there often *is* a need to rebuild it (actually, much of my
QM work on dozens packages requires changing configure.in+friends).
And you don't seriously want to patch autogenerated files, do you ? ;-o

> Some users just don't have recent enough autotools to rebuild the
> configure. 

They should simply install it. Similar as they need recent toolchain,
make, pkg-config, etc, etc.

> Moreover, with modern autotools, I tend
> to think that autoreconf -i is just as simple as autogen.sh.

That might be true for most packages, but some also need other stuff.
Therefore calling autogen.sh script is the more generic interface.
And that's one of the point it's about: make the interface between
package and distro build system as simple as possible.
 
>  - Why require building in a separate tree? Why it helps, most of the
> packages we have just build in the same source tree.

That shows up a lot of possible errors with autogenerated files.

>  - Not using AC_TRY_RUN is too strong. 

No, it's mandatory. It simply cannot crosscompile, no chance.

> This macro has a parameter to be used when cross-compiling.

It's inherently unreliable, by design. The developer has to specify
some default behaviour in case of crosscompiling. And that's most
likely wrong. If you do use that macro, you've normally relying
on basicly assumptions. Such as the building system is equal 
(yes *equal*, not just similar) to the actual target system.

> It is more useful to detect a problem when not cross-compiling
> with AC_TRY_RUN than to not detect it at all.

If you really wanna have some runtime tests, then it should be
done separately (eg. separate script or in make test stage).


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
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/20100916102857.ga2...@nibiru.local

Re: RFC: Rules for distro-friendly packages

[Luca Bruno]

Enrico Weigelt scrisse:

> I've collected several rules that upstreams should follow to make
> distro maintainer's life much easier:

You may also be interested in http://wiki.debian.org/UpstreamGuide
 
Cheers, Luca

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.| lucab (AT) debian.org
`. `'`  | GPG Key ID: 3BFB9FB3
  `- http://www.debian.org  | Debian GNU/Linux Developer


pgpAoGnbGPUGK.pgp
Description: PGP signature

Re: Bits from keyring-maint

[Alexander Reichle-Schmehl]

Hi!

Am 15.09.2010 17:07, schrieb Marco d'Itri:

>> I suspect that those figures are because 2048 bits is the default size
>> for RSA keys and 4096 bits is the largest size that GnuPG supports.
> FWIW, the OpenPGP smartcard v2 supports keys up to 3072 bits.

At the recent FrOSCon I have been told, that 4096 bit keys should work,
but aren't officially supported. (Haven't tested it myself, yet.)


Best regards,
  Alexander


-- 
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/4c920759.4090...@schmehl.info

Re: Bits from keyring-maint

[Simon Richter]

Hi,

On Thu, Sep 16, 2010 at 02:02:33PM +0200, Alexander Reichle-Schmehl wrote:

> > FWIW, the OpenPGP smartcard v2 supports keys up to 3072 bits.

> At the recent FrOSCon I have been told, that 4096 bit keys should work,
> but aren't officially supported. (Haven't tested it myself, yet.)

Well, I've tried. Apparently, some of the first 2.0 cards have a
firmware bug that leads to a buffer overrun inside the card if a 3072
bit key is used for decryption (signing and authentication work fine).

The overrun cannot be exploited as it is immediately detected by the
card runtime and the request aborted with an error condition.

FWIW, I'm using a 4096 bit KSK, which is kept in a safe location, and
2048 bit subkeys on a smartcard for daily use. I don't think the large
size for the master key is excessive, as I expect to keep it for several
years, and as it has been generated with key usage explicitly set to "C"
only it cannot be abused directly (i.e. if someone were to get hold of
the key and wanted to upload something to Debian with it, they'd need to
add a subkey and push it to the Debian keyserver, which would make the
entire operation pretty noisy).

   Simon


-- 
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/20100916122327.ga28...@richter

Re: RFC: Rules for distro-friendly packages

[Enrico Weigelt]

* Luca Bruno  schrieb:
> Enrico Weigelt scrisse:
> 
> > I've collected several rules that upstreams should follow to make
> > distro maintainer's life much easier:
> 
> You may also be interested in http://wiki.debian.org/UpstreamGuide

Thanks.

It's seems my rules are a bit more rigid and contain the most of it.
One thing I yet missed was configurable install pathes.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
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/20100916123811.ga4...@nibiru.local

Bug#597094: ITP: ringojs -- server-side JavaScript runtime and web framework

[Hannes Wallnoefer]

Package: wnpp
Severity: wishlist
Owner: Hannes Wallnoefer 


* Package name: ringojs
  Version : 0.6
  Upstream Author : Hannes Wallnoefer 
* URL : http://ringojs.org/
* License : Apache 2.0
  Programming Lang: Java, JavaScript
  Description : server-side JavaScript runtime and web framework

RingoJS is a JavaScript runtime written in Java based on Mozilla Rhino.
It adds to Rhino a CommonJS module loader, a rich module library and
support for CommonJS packages, providing a suitable development platform
real-world web applications.



-- 
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/2010091614.7116.48522.report...@hns

Bug#597110: ITP: kpartsplugin -- Netscape-compatible plugin to embed KDE file-viewers into browser

[Michele Gastaldo]

Package: wnpp
Severity: wishlist
Owner: Michele Gastaldo 


* Package name: kpartsplugin
  Version : 20100723
  Upstream Author : Thomas Fischer 
* URL : http://www.unix-ag.uni-kl.de/~fischer/kpartsplugin/
* License : GPL3
  Programming Lang: C++
  Description : Netscape-compatible plugin to embed KDE file-viewers into
browser

This is a plugin that works with Firefox/Iceweasel, Opera, Chromium and Arora,
which makes it possible to use Kparts inside browsers to view and edit 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/20100916174406.16263.16984.report...@blackbeauty.homenet.telecomitalia.it

Re: /usr/share/info/dir.gz if install-info is installed

[Sebastian Andrzej Siewior]

* Ian Jackson | 2010-09-15 11:56:49 [+0100]:

>Julien Cristau  wrote:
>> I'd say they're serious bugs if packages in the archive suffer from
>> the misbuild, and normal ones if not.
>
>I agree.

Okay. In that case I open this weekend bugs against the packages I
identified [0] with severity serious for those in main archive and
normal for those in debian-ports.

[0] http://lists.debian.org/debian-devel/2010/09/msg00277.html

>Ian.

Sebastian


-- 
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/20100916202006.gb28...@chamillionaire.breakpoint.cc

Re: RFC: Rules for distro-friendly packages

[Russ Allbery]

Enrico Weigelt  writes:

> I've collected several rules that upstreams should follow to make
> distro maintainer's life much easier:

> http://www.metux.de/index.php/de/component/content/article/57.html

> Free feel to comment on it :)

You've prohibited upstream distributions that come in multiple tarballs.
Now that our source format can handle that, I think that prohibition is a
bit too strong, although it's still less convenient.

The test suites for my packages do network communication on localhost.
It's completely impossible to test a lot of network code if you don't
allow this.  But your build system point currently says that's not
allowed.  I think you should allow localhost network communication for the
test suite (although not the main package build).

The way that the point about build output not varying based on the runtime
properties of the building system is both confusingly stated (by "build
output" I would have assumed you meant the textual output from the
compiler to the screen, not the constructed binaries) and I think way too
restrictive.  You're basically saying that people aren't allowed to use
the typical Autoconf semantics of honoring --with and --without flags and
autodetecting an optional dependency if neither is given, but that's best
practice.  Instead, I think you should say that it must be possible to
pass flags into the build system such that the build will always either
produce the same binaries or will fail, not silently drop features that
have been explicitly requested (or silently add features that have been
explicitly disabled).

I disagree with requiring static libraries even with the exception that
you list.  In this day and age, I think static libraries are basically
useless unless one can not yet commit to a stable ABI, and there are
various situations (such as support for dynamic plugins) where supporting
them is a huge pain.

Libraries should NOT build shared libraries if they can't commit to a
stable ABI with proper SONAME changes when it changes.  Yes, that sucks,
and there should be a stable ABI, but if there isn't, static-only is
better than an unstable shared library ABI not reflected in SONAME
changes.

I think you should specifically call out DESTDIR as the mechanism that
should be supported for specifying the installation location even if
Autoconf is not used.  Everything else is more annoying to use, and
supporting DESTDIR with hand-written Makefiles is not that hard.

I strongly disagree with requiring pkg-config.  None of my libraries
support this, and I don't see any point in using pkg-config if the way
that one uses the shared library is to just add -l.  You
don't need pkg-config to figure that out.  It's a nice-to-have if upstream
wants to bother, but is absolutely not required.

I absolutely refuse to call my autogen script autogen.sh for the same
reason that I oppose putting language extensions on any executable.  Linux
is not Windows; we don't need to call things foo.bat and bar.exe.

My packages will not be using pkg-config when pkg-config doesn't do
anything useful or when I can reproduce its results in more supportable
ways.  The pkg-config Autoconf glue is ugly and does not properly
implement Autoconf semantics (for example, it incorrectly merges CPPFLAGS
and CFLAGS, and LIBS and LDFLAGS, and is not written using modern Autoconf
features and style), and is not something I'm willing to use or support
unless I absolutely have to.

-- 
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/878w31fg8a@windlord.stanford.edu

Work-needing packages report for Sep 17, 2010

[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: 492 (new: 2)
Total number of packages offered up for adoption: 129 (new: 1)
Total number of packages requested help for: 66 (new: 0)

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



The following packages have been orphaned:

   pdnsd (#596302), orphaned 6 days ago
 Installations reported by Popcon: 318

   pngwriter (#596413), orphaned 5 days ago
 Description: easy to use graphics library
 Reverse Depends: libpngwriter0-dev
 Installations reported by Popcon: 135

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

   scalable-cyrfonts (#596674), offered 3 days ago
 Description: free Cyrillic PostScript fonts for X and TeX
 Installations reported by Popcon: 1679

128 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-cross (#540341), requested 405 days ago
 Description: retrieve, build and install libraries for
   cross-compiling
 Reverse Depends: apt-cross emdebian-crush
   mlton-target-alpha-linux-gnu mlton-target-arm-linux-gnueabi
   mlton-target-hppa-linux-gnu mlton-target-i486-linux-gnu
   mlton-target-ia64-linux-gnu mlton-target-mips-linux-gnu
   mlton-target-mipsel-linux-gnu mlton-target-powerpc-linux-gnu (3 more
   omitted)
 Installations reported by Popcon: 320

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

   ara (#450876), requested 1040 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 100

   asymptote (#517342), requested 566 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 1294

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

   bastille (#592137), requested 40 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 426

   boinc (#511243), requested 616 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc boinc-app-milkyway boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1532

   chromium-browser (#583826), requested 109 days ago
 Description: Chromium browser
 Reverse Depends: chromium-browser chromium-browser-dbg
   chromium-browser-l10n gecko-mediaplayer sun-java6-plugin
 Installations reported by Popcon: 2102

   cobbler (#590044), requested 55 days ago
 Description: Install server

   cvs (#354176), requested 1666 days ago
 Description: Concurrent Versions System
 Reverse Depends: cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html
   cvschangelogbuilder cvsconnect cvsd cvsps cvsservice cvssuck (9 more
   omitted)
 Installations reported by Popcon: 21472

   dctrl-tools (#448284), requested 1055 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies debtree dlocate
   haskell-devscripts javahelper libsbuild-perl linux-patch-debianlogo
   simple-cdd ubuntu-dev-tools
 Installations reported by Popcon: 12649

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

   dietlibc (#544060), requested 384 days ago
 Description: diet libc - a libc optimized for small size
 Reverse Depends: libowfat-dev
 Installations reported by Popcon: 236

   doc-central (#566364), requested 236 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 271

   dpkg (#282283), requested 2125 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: a2ps acct ace-gperf acl2-doc
   ada-reference-manual-info adacontrol advi advi-examples alien
   alqalam (538 more omitted)
 Installations reported by Popcon: 90029

   elvis (#432298), requested 1165 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 

Re: RFC: Rules for distro-friendly packages

[Paul Wise]

On Thu, Sep 16, 2010 at 6:44 PM, Luca Bruno  wrote:

> You may also be interested in http://wiki.debian.org/UpstreamGuide

Just added a link to Enrico's page from that.

-- 
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/aanlktinwxm9vs6jcn5o+kl4bh11kdv2kywc4t99p6...@mail.gmail.com

Re: RFC: Rules for distro-friendly packages

[Vincent Bernat]

OoO Pendant  le temps de  midi du jeudi  16 septembre 2010,  vers 12:28,
Enrico Weigelt  disait :

>> About autoconf stuff:
>> - Why require autogen.sh? On a release, configure script should be
>> present. No need to rebuild it. 

> No, there often *is* a need to rebuild it (actually, much of my
> QM work on dozens packages requires changing configure.in+friends).
> And you don't seriously want to patch autogenerated files, do you ? ;-o

>> Some users just don't have recent enough autotools to rebuild the
>> configure. 

> They should simply install it. Similar as they need recent toolchain,
> make, pkg-config, etc, etc.

No, no, no. Users are not  limited to Debian developers using Sid. Users
may try to compile  on an old RHEL 2. They should  absolutely not try to
rebuild configure since it is likely  to not work and leave them with an
unconfigurable package. On most projects, there is not autogen/bootstrap
in the realeases  for this very reason: do not confuse  the user and let
him install  autotools which is not mandatory  at all. autogen/bootstrap
is shipped in the VCS repository because this is targeted at developer.

autotools are  aimed at the end  user, not the distro  packager. This is
stated in the  introduction to autotools.  This is nice  to be nice with
the distro packager but the primary  target is the lambda user (which is
usually less skilled than the distro packager).

Compiling software from source is  enough a pain to avoid any unecessary
dependency. No need for a recent toolchain and no need for autotools for
a software aimed at running on a lot of systems (which is what autotools
are for too).

>> - Not using AC_TRY_RUN is too strong. 

> No, it's mandatory. It simply cannot crosscompile, no chance.

>> This macro has a parameter to be used when cross-compiling.

> It's inherently unreliable, by design. The developer has to specify
> some default behaviour in case of crosscompiling. And that's most
> likely wrong. If you do use that macro, you've normally relying
> on basicly assumptions. Such as the building system is equal 
> (yes *equal*, not just similar) to the actual target system.

>> It is more useful to detect a problem when not cross-compiling
>> with AC_TRY_RUN than to not detect it at all.

> If you really wanna have some runtime tests, then it should be
> done separately (eg. separate script or in make test stage).

Oh sure, if there  is a problem that can only be  detected at runtime, I
will let  the user  deal with it  in some  "make test" that  nobody runs
instead  of  handling  the  problem   for  him  in  most  situations  in
configure. Again, configure is targetted  at the end user (which usually
does not cross-compile). It  should automatically configure the software
to  be in  a workable  state  after compilation.  No need  to read  some
README or run some additional scripts.

As upstream, I  care about Debian and cross-compiling  but I also should
care about  people wanting to  compile my software  on old RHEL 2  or on
Debian Etch (an  old enough platform to require some  runtime test in my
case). None of those platforms have a recent enough autotools to rebuild
configure, BTW.
-- 
Use the "telephone test" for readability.
- The Elements of Programming Style (Kernighan & Plauger)


pgpM0Fy62RtPn.pgp
Description: PGP signature