Bug#892058: "Your Debian key is expiring" reminder emails

[Anthony Towns]

On Tue, Sep 22, 2020 at 09:42:57PM -0700, Felix Lechner wrote:
> This is a courtesy reminder that your Debian key is expiring on 2020-10-05.
> Please also keep in mind that the Debian folks in charge of the
> keyring update it only once a month. That usually happens on the 24th
> of each month. It is only two days away.

I was going to say it would be nice if there was a month or two advance
notice, but looking at the bug log, it seems this is only due to the first
run of this being just before my key was due to expire, and the idea is
there would normally be two or three months notice? If so, perfect!

> If you like this service, please leave a favorable comment here [2]. Thank 
> you!

It's very good, thank you very much!

FWIW, I would have expected MIA to be contacted for anyone who's key is
expired for more than a few months.

(Also, couldn't anyone write a script to synchronise the keyservers for
expiring keys? Step 1: get a list of Debian keys that will expire in
the next 6 months; Step 2: download them from any key servers; Step 3:
if any of them have an updated expiry date, export and send to Debian's
keyserver. No need to be keyring-maint or have the secret key for any
of those steps. Could sync for new sigs as well, but that might get
tedious)

Cheers,
aj

Bug#799626: RFP: beancount -- command line double-entry bookkeeping system

[Anthony Towns]

Nicolas Dandrimont wrote:
> * Martin Michlmayr  [2018-03-30 17:14:49 +0200]:
> > beancount 2.0 was released a few days ago so it's time to get this
> > into Debian.
> > Anyone interested in packaging it?  It's Python code.
> I've been meaning to look into this for a while, as I've been using
> beancount in an org I'm treasurer of.
> I'll put this in the python-team/applications group on
> salsa. Comaintainers welcome!

Any luck here? I didn't see anything on salsa yet, but maybe I missed it.
Don't suppose you've looked at packaging fava as well?

Cheers,
aj

Bug#718272: [Pkg-bitcoin-devel] Bug#718272: Bitcoin still not ready for stable release in Debian

[Anthony Towns]

Hey Luke, Jonas,

On Fri, Nov 03, 2017 at 08:31:33PM +, Luke Dashjr wrote:
> > >> I believe Bitcoin is now stable enough for stable release.
> > > Things have only gotten less stable upstream since 2013...
> > Please provide references supporting that.

0.15 is certainly "stable" in the sense that it's a well-maintained
piece of software, but it's not stable in the sense that it should
be reliably used without changes over a period of years. For instance
0.15.1 is currently being prepared to work around p2p problems that are
expected within a couple of weeks.

> > > What is the plan for getting security and protocol change updates
> > > backported to Debian stable?
> > Debian standard procedures for updating stable packages.
> In my experience, that has been "never update, even when fixes are available" 
> except for highly-visible security issues. :(

Not sure if there's something more up to date, but

https://lists.debian.org/debian-devel-announce/2016/11/msg9.html

says:

   * Fixes must be minimal and relevant and include a sufficiently
 detailed changelog entry

which seems like it generally precludes uploading new upstream releases
(0.14 to 0.15 at least, perhaps 0.15 to 0.15.1 would be fine). I don't
think upstream will generally be providing sufficiently "minimal and
relevant" backports to satisfy that rule...

AIUI, stable-updates is a subset of proposed-updates, so it's not easier
to get in there than regular updates to stable?

(If the release team are willing to accept new upstream releases into
stable or stable-updates, this seems like a good idea; it just doesn't
seem like they would be as far as I can see?)

Cheers,
aj

Bug#841951: bitcoin-qt segfaults on startup

[Anthony Towns]

On Wed, Oct 26, 2016 at 07:04:35PM +1100, Erik de Castro Lopo wrote:
> Anthony Towns wrote:
> > Maybe
> >  /usr/lib/x86_64-linux-gnu/qt5/examples/widgets/desktop/systray/systray
> > might reproduce the crash?
> Indeed it does! Gdb backtrace follows.

Okay, that makes it a Qt/GL bug afaics then. Might be worth trying the
attached. I get:

 $ g++ -o test test.cpp -lX11 -lGL -Wall -W
 $ ./test
 config 0 alphaSize 0
 config 1 alphaSize 0
 config 2 alphaSize 0
...
 config 36 alphaSize 0
 config 37 alphaSize 0
 config 38 alphaSize 8
 config 39 alphaSize 8

I'm guessing you'll get some visual==NULL!! warnings as well at which
point you might be able to work out what's going on?

Cheers,
aj

#include 
#include 
#include 
#include 
#include 
#include 

int main(void) {
Display *display = XOpenDisplay(NULL);
int screen = DefaultScreen( display );

// should be:
//   int drawableBit = 1;
//   QSurfaceFormat format = window()->requestedFormat();
//   QVector spec = qglx_buildSpec(format, drawableBit);
//   visual_attribs = spec.constData()
// but we'll try allowing anything... :-/
static int visual_attribs[] = { None };

int confcount = 0;
GLXFBConfig *configs;
configs = glXChooseFBConfig(display, screen, visual_attribs, );

if (configs == NULL) {
printf("configs was null, confcount is %d\n", confcount);
return 0;
}

for (int i = 0; i < confcount; i++) {
int alphaSize;
glXGetFBConfigAttrib(display,configs[i],GLX_ALPHA_SIZE,);
printf("config %d alphaSize %d\n", i, alphaSize);
XVisualInfo *visual = glXGetVisualFromFBConfig(display, configs[i]);
if (visual == NULL) {
printf("config %d visual==NULL!!\n", i);
}
}
return 0;
}

Bug#841951: bitcoin-qt segfaults on startup

[Anthony Towns]

On Tue, Oct 25, 2016 at 07:16:45PM +1100, Erik de Castro Lopo wrote:
> Thread 1 "bitcoin-qt" received signal SIGSEGV, Segmentation fault.
> qglx_findConfig (display=display@entry=0x56151080, screen=screen@entry=0, 
> format=..., 
> drawableBit=drawableBit@entry=1) at glxconvenience/qglxconvenience.cpp:157
> 157   glxconvenience/qglxconvenience.cpp: No such file or directory.
> (gdb) bt
> #0  qglx_findConfig (display=display@entry=0x56151080, 
> screen=screen@entry=0, format=..., 
> drawableBit=drawableBit@entry=1) at glxconvenience/qglxconvenience.cpp:157

That line is apparently:

   XRenderPictFormat *pictFormat = XRenderFindVisualFormat(display, 
visual->visual);

which presumably means "visual" is NULL. "visual" is:

   XVisualInfo *visual = glXGetVisualFromFBConfig(display, chosenConfig);

which "Returns NULL if config is not a valid GLXFBConfig." but
chosenConfig is "configs[i]" which is returned from glXChooseFBConfig,
so as far as I can see the only way it can plausibly be invalid is if
your OpenGL stuff is broken for some reason? Qt could actually check for
a NULL return and do "chosenConfig=NULL; continue;" though I guess.

> #13 0x76ef1477 in QSystemTrayIcon::setVisible (this=, 
> visible=)
> at util/qsystemtrayicon.cpp:271

Maybe

 /usr/lib/x86_64-linux-gnu/qt5/examples/widgets/desktop/systray/systray

might reproduce the crash?

Cheers,
aj

Bug#841951: bitcoin-qt segfaults on startup

[Anthony Towns]

> Just got a new machine, installed bitcoin-qt, ran it and got an
> immediate segfault. Re-running get the same result.
>
> Backtrace from GDB:
>
> (gdb) r
> Starting program: /home/erikd/Local/bin/bitcoin-qt

That's an odd location for the packaged binary?

> [Thread debugging using libthread_db enabled]
> Using host libthread_db library
> "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffe9967700 (LWP 21490)]
> [New Thread 0x7fffdcfa1700 (LWP 21491)]
> [New Thread 0x7fffd7fff700 (LWP 21492)]
> 
> Thread 1 "bitcoin-qt" received signal SIGSEGV, Segmentation fault.

bitcoin-qt's working fine for me with the same versions of the libraries
as you have, so I'll downgrade this report.

Some things you might like to try if you haven't already:

 - try running
/usr/lib/x86_64-linux-gnu/qt5/examples/gui/analogclock/analogclock
   from qtbase5-examples to see if simple qt programs fail?
 - running "bitcoin-qt -regtest" to eliminate downloading the blockchain
   and contacting peers while debugging
 - installing bitcoind, and trying it in headless mode to avoid qt and
   graphics related bugs
 - use "ssh -X" to get into your new desktop from somewhere else, and
   run bitcoin-qt from there, to perhaps eliminate any problems related
   to graphics drivers?

> There doesn't seem to be any debug symbols available for libqt5gui5 so
> I was not able to debug this futher.

Have you tried installing the qtbase5-dbg and related packages? That
seems to give me useful debug info.

Cheers,
aj

Bug#835809: bitcoind: Blockchain needs 87+ GB of space, not 20+

[Anthony Towns]

> The description of the bitcoin* packages mentions the following line:
> This requires 20+ GB of space, slowly growing.
>
> That info seems to be severely outdated and actually uses 87+ GB on
> my system, which is more then 4 times as much. I've put the severity
> at normal instead of minor/wishlist as it failed to work properly on a
> system where I had around 50GB space free when/where I installed it.

You might want to look into the "pruning" feature, that allows you to
run bitcoind with as little as a few gigabytes.

(The description still needs an update though)

Cheers,
aj

Bug#835963: bitcoin: non-standard gcc/g++ used for build (gcc-5)

[Anthony Towns]

Hey doko,

> Package: bitcoin
> Version: 0.12.1-0.1
>
> This package builds with a non standard compiler version; please check
> if this package can be built with the default version of gcc/g++, or
> with gcc-6/g++-6.
> The severity of this report is likely to be raised before the release,
> so that the gcc-5 package can be removed for the release.

See https://bugs.debian.org/812275 -- bitcoin 0.12 doesn't build correctly
with gcc-6; but version 0.13 looks like it does and is currently in
experimental. In any event, http://bugs.debian.org/718272 prevents
bitcoin from being included in a release anyway.

Can this bug be merged with 812275?

Cheers,
aj

Bug#822203: bitcoin-qt: New upstream release (0.12.1)

[Anthony Towns]

On Mon, Aug 01, 2016 at 02:25:25PM +1000, Anthony Towns wrote:
> I've had a go at packaging 0.12.1, and it seems to have worked. Changes
> versus the collab-maint repo are at:

I've taken the liberty of uploading NMUs of 0.12.1 and 0.13.0rc3 to
unstable and experimental via DELAYED/3. The git changes are at:

   https://github.com/ajtowns/bitcoin-deb/commits/master

In particular:

 
https://github.com/ajtowns/bitcoin-deb/commit/7b93639aa24744a7c1a87cd616bf0dbd7d713756

and

 
https://github.com/ajtowns/bitcoin-deb/commit/775a3f5490335204d42e9353696aa84bd422f092

If someone wants to do an official maintainer upload instead, that'd be
great of course :)

Cheers,
aj



signature.asc
Description: PGP signature

Bug#828248: bitcoin: FTBFS with openssl 1.1.0

[Anthony Towns]

On Sat, Aug 06, 2016 at 02:11:02PM +1000, Anthony Towns wrote:
> Building 0.12.1 fails due to the new gcc-6 default in unstable (see bug
> 812275), but 0.13.0rc2 builds okay and the tests pass.

My mistake, the build I tried was still against ssl from unstable. With
the correct libssl-dev installed there's a few failures, due to the
opaque data types. The attached patch seems to make things work for both
openssl 1.0 and 1.1.

Cheers,
aj

Description: openssl 1.1 compatability
Author: Anthony Towns <a...@erisian.com.au>
Bug-Debian: https://bugs.debian.org/828248



--- a/src/qt/paymentrequestplus.cpp
+++ b/src/qt/paymentrequestplus.cpp
@@ -19,6 +19,21 @@
 #include 
 #include 
 
+#if OPENSSL_VERSION_NUMBER < 0x1010L
+static EVP_MD_CTX *EVP_MD_CTX_new(void)
+{
+   EVP_MD_CTX *ctx = (EVP_MD_CTX *) OPENSSL_malloc(sizeof(*ctx));
+   if (ctx != NULL) {
+   EVP_MD_CTX_init(ctx);
+   }
+   return ctx;
+}
+static void EVP_MD_CTX_free(EVP_MD_CTX *ctx)
+{
+OPENSSL_free(ctx);
+}
+#endif
+
 class SSLVerifyError : public std::runtime_error
 {
 public:
@@ -131,6 +146,7 @@ bool PaymentRequestPlus::getMerchant(X50
 
 char *website = NULL;
 bool fResult = true;
+EVP_MD_CTX *ctx = NULL;
 try
 {
 if (!X509_STORE_CTX_init(store_ctx, certStore, signing_cert, chain))
@@ -159,12 +175,11 @@ bool PaymentRequestPlus::getMerchant(X50
 std::string data_to_verify; // Everything but the signature
 rcopy.SerializeToString(_to_verify);
 
-EVP_MD_CTX ctx;
 EVP_PKEY *pubkey = X509_get_pubkey(signing_cert);
-EVP_MD_CTX_init();
-if (!EVP_VerifyInit_ex(, digestAlgorithm, NULL) ||
-!EVP_VerifyUpdate(, data_to_verify.data(), data_to_verify.size()) ||
-!EVP_VerifyFinal(, (const unsigned char*)paymentRequest.signature().data(), (unsigned int)paymentRequest.signature().size(), pubkey)) {
+ctx = EVP_MD_CTX_new();
+if (!EVP_VerifyInit_ex(ctx, digestAlgorithm, NULL) ||
+!EVP_VerifyUpdate(ctx, data_to_verify.data(), data_to_verify.size()) ||
+!EVP_VerifyFinal(ctx, (const unsigned char*)paymentRequest.signature().data(), (unsigned int)paymentRequest.signature().size(), pubkey)) {
 throw SSLVerifyError("Bad signature, invalid payment request.");
 }
 
@@ -186,6 +201,8 @@ bool PaymentRequestPlus::getMerchant(X50
 
 if (website)
 delete[] website;
+if (ctx)
+EVP_MD_CTX_free(ctx);
 X509_STORE_CTX_free(store_ctx);
 for (unsigned int i = 0; i < certs.size(); i++)
 X509_free(certs[i]);
--- a/src/secp256k1/src/tests.c
+++ b/src/secp256k1/src/tests.c
@@ -22,6 +22,14 @@
 #include "openssl/ec.h"
 #include "openssl/ecdsa.h"
 #include "openssl/obj_mac.h"
+
+#if OPENSSL_VERSION_NUMBER < 0x1010L
+static void ECDSA_SIG_get0(ECDSA_SIG *sig, BIGNUM **r, BIGNUM **s)
+{
+*r = sig->r;
+*s = sig->s;
+}
+#endif
 #endif
 
 #include "contrib/lax_der_parsing.c"
@@ -3558,15 +3566,17 @@ int test_ecdsa_der_parse(const unsigned
 sigptr = sig;
 parsed_openssl = (d2i_ECDSA_SIG(_openssl, , siglen) != NULL);
 if (parsed_openssl) {
-valid_openssl = !BN_is_negative(sig_openssl->r) && !BN_is_negative(sig_openssl->s) && BN_num_bits(sig_openssl->r) > 0 && BN_num_bits(sig_openssl->r) <= 256 && BN_num_bits(sig_openssl->s) > 0 && BN_num_bits(sig_openssl->s) <= 256;
+const BIGNUM *r, *s;
+ECDSA_SIG_get0(sig_openssl, , );
+valid_openssl = !BN_is_negative(r) && !BN_is_negative(s) && BN_num_bits(r) > 0 && BN_num_bits(r) <= 256 && BN_num_bits(s) > 0 && BN_num_bits(s) <= 256;
 if (valid_openssl) {
 unsigned char tmp[32] = {0};
-BN_bn2bin(sig_openssl->r, tmp + 32 - BN_num_bytes(sig_openssl->r));
+BN_bn2bin(r, tmp + 32 - BN_num_bytes(r));
 valid_openssl = memcmp(tmp, max_scalar, 32) < 0;
 }
 if (valid_openssl) {
 unsigned char tmp[32] = {0};
-BN_bn2bin(sig_openssl->s, tmp + 32 - BN_num_bytes(sig_openssl->s));
+BN_bn2bin(s, tmp + 32 - BN_num_bytes(s));
 valid_openssl = memcmp(tmp, max_scalar, 32) < 0;
 }
 }
--- a/src/wallet/test/crypto_tests.cpp
+++ b/src/wallet/test/crypto_tests.cpp
@@ -42,15 +42,18 @@ bool OldEncrypt(const CKeyingMaterial& v
 int nCLen = nLen + AES_BLOCK_SIZE, nFLen = 0;
 vchCiphertext = std::vector (nCLen);
 
-EVP_CIPHER_CTX ctx;
+EVP_CIPHER_CTX *ctx;
 
 bool fOk = true;
 
-EVP_CIPHER_CTX_init();
-if (fOk) fOk = EVP_EncryptInit_ex(, EVP_aes_256_cbc(), NULL, chKey, chIV) != 0;
-if (fOk) fOk = EVP_EncryptUpdate(, [0], , [0], nLen) != 0;
-if (fOk) fOk = EVP_EncryptFinal_ex(, ([0]) + nCLen, ) != 0;
-EVP_CIPHER_CTX_c

Bug#828248: bitcoin: FTBFS with openssl 1.1.0

[Anthony Towns]

Source: bitcoin
Followup-For: Bug #828248

> OpenSSL 1.1.0 is about to released.  During a rebuild of all packages
> using OpenSSL this package fail to build.  A log of that build can be found
> at:
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/bitcoin_0.11.2-1_amd64-20160529-1408

>From that url:

> checking for RAND_egd in -lcrypto... no
> configure: error: Detected LibreSSL: This is NOT supported, and may
> break consensus compatibility!

This check has been removed upstream for some time now:

https://github.com/bitcoin/bitcoin/commit/59783884766d00866e190ba5ae761916e932df10

Building 0.12.1 fails due to the new gcc-6 default in unstable (see bug
812275), but 0.13.0rc2 builds okay and the tests pass.

Cheers,
aj

Bug#812275: bitcoin: FTBFS with GCC 6: test suite failures

[Anthony Towns]

Source: bitcoin
Followup-For: Bug #812275

> This package fails to build with GCC 6.

FWIW, this bug seems to be fixed upstream somewhere between 0.12.1 and
0.13.0rc2. I ran a git bisect, and the commit that fixes the issue seems
to be:

https://github.com/bitcoin/bitcoin/commit/89f71c68c0fecf63059f6055ebdd25f1eba4c982

Cheers,
aj

Bug#822203: [Pkg-bitcoin-devel] Bug#822203: bitcoin-qt: New upstream release (0.12.1)

[Anthony Towns]

On Wed, Aug 03, 2016 at 11:21:38AM +1000, Anthony Towns wrote:
> On Mon, Aug 01, 2016 at 09:35:42AM +0200, Jonas Smedegaard wrote:
> > Quoting Anthony Towns (2016-08-01 06:25:25)
> > > I've had a go at packaging 0.12.1, and it seems to have worked. 
> > > Changes versus the collab-maint repo are at:
> > >   https://github.com/ajtowns/bitcoin-deb/commits/master
> > Attached script (in active use with asterisk package), placed in debian 
> > dir and executed from the root dir (just like a rules file) should do 
> > the trick of tracking copyright and licensing changes separate from 
> > Debian packaging.
> I had to pull debian/rules.copyright-check out of the asterisk source
> from sid, but apart from that it worked!
> I've added a few more commits at the repo above (namely, adding
> copyright-check, updating the copyright file, and adding zmq as a dep).

Oops; I noticed that I messed up the "gbp import-orig" (it wasn't synced
with the upstream branch), so I've redone it and rebased the repo above.

FWIW, 0.13.0rc2 seems to build okay too.

Cheers,
aj

Bug#822203: [Pkg-bitcoin-devel] Bug#822203: bitcoin-qt: New upstream release (0.12.1)

[Anthony Towns]

On Mon, Aug 01, 2016 at 09:35:42AM +0200, Jonas Smedegaard wrote:
> Quoting Anthony Towns (2016-08-01 06:25:25)
> > I've had a go at packaging 0.12.1, and it seems to have worked. 
> > Changes versus the collab-maint repo are at:
> >   https://github.com/ajtowns/bitcoin-deb/commits/master
> Attached script (in active use with asterisk package), placed in debian 
> dir and executed from the root dir (just like a rules file) should do 
> the trick of tracking copyright and licensing changes separate from 
> Debian packaging.

I had to pull debian/rules.copyright-check out of the asterisk source
from sid, but apart from that it worked!

I've added a few more commits at the repo above (namely, adding
copyright-check, updating the copyright file, and adding zmq as a dep).

Cheers,
aj

Bug#822203: bitcoin-qt: New upstream release (0.12.1)

[Anthony Towns]

Package: bitcoin-qt
Followup-For: Bug #822203

Hi,

I've had a go at packaging 0.12.1, and it seems to have worked. Changes
versus the collab-maint repo are at:

  https://github.com/ajtowns/bitcoin-deb/commits/master

I had to disable cdbs to get it to build; I hit the same problem Petter
saw in Bug#808969. AFAICT cdbs is just used for the license checking
so that's not a huge problem; I couldn't figure out a reasonable way of
doing the license checking without cdbs though. :-/

I haven't updated the symbols file, so I get:

* dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
* dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
* dpkg-gensymbols: warning: debian/libbitcoinconsensus0/DEBIAN/symbols doesn't 
match completely debian/libbitcoinconsensus0.symbols

And it also looks like a dependency on zmq might be worth adding.

* configure: WARNING: libzmq version 4.x or greater not found, disabling

Not sure what that should be exactly; maybe "libzmq3-dev (>= 4) |
libzmq5-dev" ?

Cheers,
aj

Bug#829158: python-sympy should not conflict with python-gmpy2

[Anthony Towns]

Package: python-sympy
Version: 1.0-1
Severity: normal

Hi,

In sympy 0.7.5-2 a Conflicts: python-gmpy2 was added to the python-sympy
package to avoid an error in isympy reported in Bug#730975.

This error no longer seems to occur -- presumably due to mpmath having
better special casing:

] $ head -n306 /usr/lib/python2.7/dist-packages/mpmath/libmp/libintmath.py | 
tail -n7
] if BACKEND == 'gmpy':
] if gmpy.version() >= '2':
] isqrt_small = isqrt_fast = isqrt = gmpy.isqrt
] sqrtrem = gmpy.isqrt_rem
] else:
] isqrt_small = isqrt_fast = isqrt = gmpy.sqrt
] sqrtrem = gmpy.sqrtrem

So I think the Conflicts: line should just be removed at this point.

Thanks in advance.

Cheers,
aj

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-sympy depends on:
ii  isympy 1.0-1
ii  python-mpmath  0.19-3
pn  python:any 

Versions of packages python-sympy recommends:
ii  dvipng  1.14-2+b2
ii  ipython 2.4.1-1
ii  python [python-ctypes]  2.7.11-2
ii  python-gmpy 1.17-1
ii  python-imaging  3.2.0-2
ii  python-numpy1:1.11.1~rc1-1
ii  python-pyglet   1.1.4.dfsg-3
ii  python-sympy-doc1.0-1
ii  texlive-fonts-extra 2016.20160520-1

python-sympy suggests no packages.

Bug#801950: protobuf-c: New upstream version 1.1.1 available

[Anthony Towns]

Source: protobuf-c
Version: 1.0.2-1
Severity: wishlist

Hi,

Any chance the Debian package could be updated to latest upstream? oneof
support would be helpful...

protobuf-c (1.1.0)
  * Implement oneof support (Issue #174). Protobuf 2.6.0 or newer is now
  required to build protobuf-c.

Cheers,
aj

Bug#709460: [Britney] binNMUs plus source take-over issue

[Anthony Towns]

Hi,

Attached is a possible patch for bug#709460. Works against both normal and
live-data test cases by the looks.

N: Using Time::HiRes to calculate run times
Running live-2011-12-13... ok (258.376s)
Running live-2011-12-20... ok (251.626s)
Running live-2012-01-04... ok (193.008s)
Running live-2012-05-09... done (159.661s)

The most notable change is that I pulled the _compute_groups function out
as the first thing that doop_source does, and then reuse its output later
rather than working out which binary packages are valid independently.
(I've left in some commented print statements that add some output as to
what binaries doop_source is actually looking at which seemed helpful)

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au
diff --git a/britney.py b/britney.py
index 55dd7c3..b254ea7 100755
--- a/britney.py
+++ b/britney.py
@@ -1859,11 +1859,6 @@ class Britney(object):
 InstallabilityTester.
 
 
-Pre-Conditions: The source package must be in testing and this
-should only be used when considering to do an upgrade
-migration from the input suite.  (e.g. do not use this for
-removals).
-
 Unlike doop_source, this will not modify any data structure.
 
 # local copies for better performances
@@ -1964,7 +1959,7 @@ class Britney(object):
  suite != 'unstable' and \
  binaries_t[parch][0][binary][ARCHITECTURE] == 'all':
 continue
-else:
+else:
 rms.add((binary, version, parch))
 
 # single binary removal; used for clearing up after smooth
@@ -1981,11 +1976,24 @@ class Britney(object):
 if migration_architecture not in ['source', parch]:
 continue
 version = self.binaries[suite][parch][0][binary][VERSION]
+
+if (not include_hijacked
+and self.binaries[suite][parch][0][binary][SOURCE] != 
source_name):
+# This binary package has been hijacked by some other 
source.
+# So don't add it as part of this update.
+#
+# Also, if this isn't a source update, don't remove
+# the package that's been hijacked if it's present.
+if migration_architecture != 'source':
+for rm_b, rm_v, rm_p in list(rms):
+if (rm_b, rm_p) == (binary, parch):
+rms.remove((rm_b, rm_v, rm_p))
+continue
+
 adds.add((binary, version, parch))
 
 return (adds, rms, set(smoothbins.itervalues()))
 
-
 def doop_source(self, item, hint_undo=None, removals=frozenset()):
 Apply a change to the testing distribution as requested by `pkg`
 
@@ -2016,16 +2024,19 @@ class Britney(object):
 inst_tester = self._inst_tester
 eqv_set = set()
 
+updates, rms, _ = self._compute_groups(item.package,
+   item.suite,
+   item.architecture,
+   item.is_removal,
+   removals=removals)
+#print(+++ %s % (sorted(updates)))
+#print(--- %s % (sorted(rms)))
+
 # remove all binary packages (if the source already exists)
 if item.architecture == 'source' or not item.is_removal:
 if item.package in sources['testing']:
 source = sources['testing'][item.package]
 
-updates, rms, _ = self._compute_groups(item.package,
-   item.suite,
-   item.architecture,
-   item.is_removal,
-   removals=removals)
 
 eqv_table = {}
 
@@ -2091,9 +2102,9 @@ class Britney(object):
 if not item.is_removal:
 source = sources[item.suite][item.package]
 packages_s = self.binaries[item.suite]
-for p in source[BINARIES]:
-binary, parch = p.split(/)
-if item.architecture not in ['source', parch]: continue
+
+for binary, version, parch in updates:
+p = %s/%s % (binary, parch)
 key = (binary, parch)
 binaries_t_a, provides_t_a = packages_t[parch]
 equivalent_replacement = key in eqv_set

Bug#780840: ITP: python-beanbag -- Helper module for accessing REST APIs

[Anthony Towns]

Package: wnpp
Severity: wishlist
Owner: Anthony Towns a...@erisian.com.au

* Package name: python-beanbag
  Version : 1.9.1
  Upstream Author : Anthony Towns a...@erisian.com.au
* URL : https://pypi.python.org/pypi/beanbag/
* License : MIT
  Programming Lang: Python
  Description : Helper module for accessing REST APIs

BeanBag is a simple module that lets you access REST APIs in an easy
way. See `http://beanbag.readthedocs.org/` for more information.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#769972: Draft new member ballot

[Anthony Towns]

On 3 March 2015 at 10:02, Don Armstrong d...@debian.org wrote:

 ===BEGIN

 The Technical Committee recommends that PERSON be appointment by the


appointed​...


 Debian Project Leader to the Technical Committee.

 A: Recommend to Appoint PERSON
 B: Further Discussion


​The way it was done last time was:

   Intro, common to all non-FD options:

   1. The Technical Committee thanks all the candidates who put
  themselves forward for the vacant TC seat.

   2. We appreciate the opportunity to select from a strong field of
  candidates.

   Option Packard:

   3. We propose to the DPL that Keith Packard should be appointed
  to the TC.  (Constitution 6.2(2))

   Option Kern:

   4. We propose to the DPL that Philipp Kern should be appointed
  to the TC.  (Constitution 6.2(2))

That seems like a sensible structure to continue to me?
​
Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au

Bug#555979: debian-policy: Symlinks pointing beyond the root of the file system

[Anthony Towns]

On Sun, Nov 23, 2014 at 01:25:50PM +0100, Bill Allombert wrote:
 On Sun, Nov 23, 2014 at 01:58:41AM +, Anthony Towns wrote:
  On Sat, Nov 22, 2014 at 12:39:44PM +0500, Andrey Rahmatullin wrote:
   On Thu, Nov 12, 2009 at 04:31:52PM -0800, Russ Allbery wrote:
Lintian has a tag:
Tag: symlink-has-too-many-up-segments
Severity: serious
  
   + Symbolic links must not traverse above the root directory.
  
  This isn't listed in https://release.debian.org/jessie/rc_policy.txt 
  
  I don't see any reason why it should be RC; so s/must/should/ IMO.
 
 Is it your position that an issue that cause the FTP masters to reject the
 package at upload time is not necessarily RC ?

Yes; or more particularly, that FTP masters should reject packages with
any bug that's easy to fix and easy to detect with no (or very minimal)
false positives, whether it's RC or not.

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767891: apt: Provide ability to manually mark packages as essential

[Anthony Towns]

Package: apt
Version: 1.0.9.3
Severity: wishlist
Tags: patch

Hi,

It would be useful to be able to locally mark certain packages as
Essential:yes so that they are never uninstalled. Trivial example: mark
sysvinit-core as essential on systems you don't want to have upgraded
to systemd as init.

I'm including a patch that allows you to do this by:

$ sudo apt-get -o pkgCacheGen::ForceEssential=systemd-sysv,apt update
...
$ sudo apt-get install sysvinit-core
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  systemd-sysv
The following NEW packages will be installed:
  sysvinit-core
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  systemd-sysv
0 upgraded, 1 newly installed, 1 to remove and 304 not upgraded.
Need to get 0 B/130 kB of archives.
After this operation, 179 kB of additional disk space will be used.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] no
Abort.

versus:

$ sudo apt-get -o pkgCacheGen::ForceEssential=apt update
...
$ sudo apt-get install sysvinit-core
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  systemd-sysv
The following NEW packages will be installed:
  sysvinit-core
0 upgraded, 1 newly installed, 1 to remove and 304 not upgraded.
Need to get 0 B/130 kB of archives.
After this operation, 179 kB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.


Patch is (git diff -b, ignoring whitespace-only changes):

--- a/apt-pkg/deb/deblistparser.cc
+++ b/apt-pkg/deb/deblistparser.cc
@@ -277,13 +277,20 @@ bool debListParser::UsePackage(pkgCache::PkgIterator Pkg,
if (Section.FindFlag(Important,Pkg-Flags,pkgCache::Flag::Important) == 
false)
   return false;
 
-   if (strcmp(Pkg.Name(),apt) == 0)
+   std::vectorstd::string force_essential = 
_config-FindVector(pkgCacheGen::ForceEssential,apt);
+   for (std::vectorstd::string::const_iterator p = force_essential.begin(); 
p != force_essential.end(); ++p)
+   {
+  if (strcmp(p-c_str(), Pkg.Name()) == 0)
   {
  if ((essential == native  Pkg-Arch != 0  myArch == Pkg.Arch()) 
||
  essential == all)
 Pkg-Flags |= pkgCache::Flag::Essential | 
pkgCache::Flag::Important;
  else
 Pkg-Flags |= pkgCache::Flag::Important;
+
+ _error-Notice(Marking package as essential: %s,p-c_str());
+
+  }
}
 
if (ParseStatus(Pkg,Ver) == false)

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767891: apt: Provide ability to manually mark packages as essential

[Anthony Towns]

On 3 November 2014 20:22, Julian Andres Klode j...@debian.org wrote:
 A simple way to achieve what you want is to create a local dummy
 package that depends on the packages you want and is
 Essential: yes or Important: yes. Important being preferred, since
 it has less restrictions on installation ordering.

Yeah, I've done that before (and the equivs package is helpful there).
But it's two somewhat complicated steps (build a package, install a
local package), for something that seems more like it should be a
simple configuration step (these packages are important to me: ...).

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767891: apt: Provide ability to manually mark packages as essential

[Anthony Towns]

On 3 November 2014 20:30, Anthony Towns a...@erisian.com.au wrote:
 On 3 November 2014 20:22, Julian Andres Klode j...@debian.org wrote:
 A simple way to achieve what you want is to create a local dummy
 package that depends on the packages you want and is
 Essential: yes or Important: yes. Important being preferred, since
 it has less restrictions on installation ordering.

 Yeah, I've done that before (and the equivs package is helpful there).
 But it's two somewhat complicated steps (build a package, install a
 local package), for something that seems more like it should be a
 simple configuration step (these packages are important to me: ...).

Alternatively, it might make sense (from a user/admin's POV) to do it
via 'apt-mark', ie:

  apt-mark important xmonad
  apt-mark essential sysvinit-core

(I'm not really familiar with apt-mark though, particular if it's
something people should feel comfortable relying on)

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736189: [gitit] Sourceless file

[Anthony Towns]

On 26 September 2014 00:36, Anthony Towns a...@erisian.com.au wrote:
 This bug is reportedly fixed in the new upstream version 0.10.5 about a
 month ago:

Turns out the 0.10.5.1 tarball doesn't actually include the sources
for the minified jquery -- it's just included in git.

gitit 0.10.5.1 also adds a few dependencies, one of which isn't
packaged for Debian (hoauth2).

I've prepared a patch that:
 - updates to the current upstream
 - adds the new deps (except hoauth2) to debian/control
 - removes github oauth2 support, and hence the need for the hoauth2 dep
 - includes the jquery sources
 - updates debian/rules to replace the new names of jquery with the
packed jquery bits

It's available (unsigned) at
http://azure.erisian.com.au/~aj/tmp/gitit-bug736189/ for now.

I think that would be okay for the archive, but maybe it would be
better to just do a patch to 0.10.4 that includes the corresponding
jquery sources and try to get that into jessie?

I've submitted a pull request upstream to get the sources included in
the upstream tarball directly, see
https://github.com/jgm/gitit/pull/454

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736189: [gitit] Sourceless file

[Anthony Towns]

tag 736189 + fixed-upstream
thanks

This bug is reportedly fixed in the new upstream version 0.10.5 about a
month ago:

 I've released gitit 0.10.5.
 
 CHANGES:
 
...
   * Add full versions of minified JavaScript (#400) (Peter Gallagher).

 -- https://groups.google.com/forum/#!topic/gitit-discuss/7t_ew6pw7Ac

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752600: [colobot] pieces of text of in-game help missing

[Anthony Towns]

 the categories page seems to have missing text.

 there is big blank areas in the session Buildings and in the session
 Robots. if I select one of this areas with mouse, click in copy button
 and go to an editor and paste (I used emacs), I can see the missing
 text.

I was seeing the same thing in the previous version of colobot (no
text, but the links were still clickable). It seems fixed for me now,
as of 0.1.3-1.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#636783: TC process GRs

[Anthony Towns]

On 26 June 2014 10:11, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
  * Change the committee size to an odd number to minimise use of the
casting vote in highly contested situations.  Status: under
discussion; text should be simple.  Current proposal is to increase
to 9.

This seems a lot like fighting the last war to me, and consequently
not of much value, but does there also need to be some requirement to
actually fill the ctte then? having nine slots, but only eight members
doesn't help

  * Explicitly permit the TC to hold private conversations.  These
would not include actual votes etc., and are still discouraged.
Draft text is ready.

I personally think it'd be better to do something more along the
opposite lines -- if the tech ctte members have discussions in private
on issues that have been put to the ctte (eg at conferences, over
beers, irc query sessions), require they post summaries of the
conversation to the public ctte list after the fact.

As far as mediation goes; it would be appropriate for the ctte to
recommend the disputants undertake private mediation attempts, which
might result in a recommendation the ctte adopts, but it seems like
having that be separate from the ctte's duties in general would be a
better plan than allowing discussions to go secret whenever someone
thinks it would be counterproductive.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#636783: TC minimum discussion period

[Anthony Towns]

On 28 June 2014 10:50, Steve Langasek vor...@debian.org wrote:
 In the IRC meeting on May 22, we discussed several different approaches for
 handling the call for votes.  The one I favor is to introduce a formal
 cloture vote into the process.

I thought this made sense too.

 A cloture vote is a procedural up/down vote on whether to close debate on a
 question and move to a vote on the ballot.  ...

Here's an alternative strawman:

 - Any member of the TC may call for votes on a ballot at any time.
 - When calling for votes, the TC member may propose any combination
of resolutions they believe is appropriate to be considered on the
ballot, provided they fall under the ctte's constitutional powers.
 - When voting on the ballot, TC members may rank the proposed options
from 1 to n in the normal manner for Debian ballots.
 - An additional Cloture option will be automatically added to the ballot.
 - The Cloture option may only be marked Y to approve cloture, or
N to deny cloture.
 - The Cloture option is the default option for the SRP. A Y vote
for cloture is treated as ranking the default option below all others
(including unranked options). A N vote is treated as ranking the
default option above all others.
 - In the event that cloture fails (ie, the default option wins the
SRP), the TC members should discuss the reasons for the failure and
produce a new ballot that is able to pass cloture.

(SRP=Standard Resolution Procedure)

  - Ballot options proposed during the cloture vote shall be included on the
ballot.

I don't think that's likely to be compatible with the or when the
outcome is beyond doubt provision. ie:

  Let's vote on upstart vs systemd!
  next ten minutes: yes yes yes yes yes
  okay, here's the ballot!

  three hours later: what? no! i want option upstart and must
support multiple systemds on the ballot
  too bad, suckah

To make that provision work, I think you'd have to have a minimum
voting period, in which case I don't think there's any value beyond
just having a minimum discussion period.

But ultimately, if a majority of the ctte want to vote on a particular
question that's within the ctte's remit, I don't see why any minority
should get to block them from having exactly that vote. I do think it
makes sense to formally establish that a majority do want to undertake
that vote though.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741573: Two menu systems

[Anthony Towns]

, then everything additional that
the trad menu does is by definition useless (for users who want to do
menu things, anyway)... And if it's changed so it doesn't do anything
additional, what's the point?

So based on that I would say:

 - requirement that they should *not* be present
 - consequence of having them should be a minor bug

But I don't even know if I'm using desktop menus or trad menus, so...

 * How Policy should formally represent the distinction between different
   levels of requirements.

FWIW, I think policy should be distinguishing whether its
recommendations are requirements for distribution (legal issues,
dependency errors), proper practice (ie, it's a bug if you don't do
this), or just a good idea to consider (a suggestion from experienced
developers/packagers), but beyond that should just be documenting how
to make optimal packages assuming infinite time and motivation. I
don't know how you could do that more effectively; must/should/may
still seems reasonable to me, but it doesn't seem that effective.
Splitting them as three separate documents (distro/release
requirements, policy, suggested practices) might be an option. Maybe
it would be more effective to approach the problem from the other end
-- provide a document/site of what the project thinks are the most
important things to work on, so that people who want to force
maintainers into doing things go there rather than debating which verb
is used in policy.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

On Sat, Feb 08, 2014 at 12:56:56PM -0700, Bdale Garbee wrote:
 Bdale Garbee bd...@gag.com writes:
  - - - start ballot - - -
  We exercise our power to decide in cases of overlapping jurisdiction
  (6.1.2) by asserting that the default init system for Linux
  architectures in jessie should be
Dsystemd 
Uupstart
Oopenrc
Vsysvinit (no change)
Frequires further discussion
  Should the project pass a General Resolution before the release of
  jessie asserting a position statement about issues of the day on
  init systems, that position replaces the outcome of this vote and is
  adopted by the Technical Committee as its own decision.
  - - - end ballot - - -
 I vote D U O V F.

On Sat, Feb 08, 2014 at 12:16:51PM -0800, Russ Allbery wrote:
 I vote:
 D U O V F

On Sat, Feb 08, 2014 at 02:18:39PM -0800, Steve Langasek wrote:
 I vote F U D O V

On Sat, Feb 08, 2014 at 02:51:13PM -0800, Don Armstrong wrote:
 I vote D  U  O  V  F.

On Sat, Feb 08, 2014 at 02:57:52PM -0800, Keith Packard wrote:
 I vote:
 1.  D
 2.  U
 3.  O
 4.  V
 5.  F

On Sun, Feb 09, 2014 at 01:04:31PM +, Colin Watson wrote:
 I vote UDOFV.

On Sun, Feb 09, 2014 at 07:15:58PM +, Ian Jackson wrote:
 I vote F, V, O, U, D.

On Tue, Feb 11, 2014 at 09:07:11AM +0100, Andreas Barth wrote:
 Thus voting U, F, D, O, V.

So that's all the votes in, by my count. Summary is:

  4x D U O V F (bdale, russ, keith, don)
 F U D O V (steve)
 U D O F V (colin)
 F V O U D (ian)
 U F D O V (andi)

Pairwise defeats are:

  D = U  (4:4)

  U and D  O and V  
 (7:1) (ian against)
  O  V  (7:1) (ian against)

  U  F  (6:2) (steve, ian against)
  D  F  (5:3) (steve, ian, andi against)
  O  F  (5:3) (steve, ian, andi against)
  V = F  (4:4)

A.6.2: Quorum is 2 (6.3.1), all options meet quorum.
A.6.3: Option V does not strictly defeat default option F, so is eliminated
A.6.5: Transitive defeats are:

  D : O, F (directly)
  U : O, F (directly)
  O : F (directly)
  F :

A.6.6: Schwartz set is {D,U}
A.6.8: There are no defeats in the Schwartz set, so the elector with
   the casting vote chooses which of these options wins.

Per 6.3.2, the casting vote is held by the Chairman, who is currently
Bdale.

Per 6.3.1, the voting period expires either Feb 15th, or when the outcome
is no longer in doubt. Not clear to me if that's now, or only after Bdale
specifies a casting vote. Per 7.3, if there's any dispute about that, the
secretary adjudicates that dispute.

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

On 10 February 2014 06:41, Serge Kosyrev skosy...@ptsecurity.ru wrote:
 False.  Three messages on this list brought this conflict of interest
 into light:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2810 by Anthony Towns
 [...]
 There was no answer.

So, fwiw, I thought the above was kind of mean on my behalf. Not
/wrong/ per se, just mean.

I haven't been able to think of a *good* answer for this concern,
even in an arbitrary ideal world where the constraints are different.

For instance, Steve could recuse himself from the discussion entirely
-- that's what you'd expect in many cases where there are commercial
conflicts of interest, eg. But that would be ridiculous here, because
both his technical knowledge as upstart maintainer is nigh-on
essential to the discussion, and his input as to how things have
worked in Canonical is pretty useful too.

He could recuse himself from voting, or perhaps the committee chair or
committee as a whole could ask him to do so -- but at least at this
point, that would be effectively equivalent to Steve directly voting
systemd above upstart, and that would be a fairly unreasonable forced
reversal of preferences for Steve to make, or it would involve a
conflict of interest on behalf of the chair (who's indicated a
preference for systemd), or the rest of the committee (which has
indicated a 4:3 preference for systemd). Maybe one of these things
would have been good to do earlier, before positions had coalesced,
but I don't think they're reasonable things to do or expect now. (They
might have been when I sent the mail, but if so, they only remained
plausible for a pretty short window in my opinion; further, Steve
mentions that the committee discussed this earlier and came to the
conclusion that no action was needed)

If the committee had the flexibility to do so, maybe a reasonable
thing would have been to replace Steve for this vote with a less
interested party early in the discussions; eg by letting Phil Kern
step in to provide the 8th vote for this issue, so that Steve could
simply act as an advocate and technical advisor to the committee on
this issue. Alternatively, perhaps a reasonable thing might have been
to give the primary systemd, sysvinit and upstart maintainers the
ability to vote on this issue too. Neither were options open to the
committee though.

As it stands, though, Steve has to: consider the implications for
Debian, consider the implications for upstart (as maintainer),
consider the implications for Canonical and Ubuntu (as a Canonical
employee and Ubuntu dev), mostly dismiss the implications for
Canonical/Ubuntu (in order to prioritise the implications for Debian
as a ctte member making a ctte decision), and deal with accusations of
having a conflict of interest, despite not being able to do anything
concrete to address them. Oh, and I gather Steve's trying to run a
debconf in six months time or so too, which I understand could add
some degree of stress on its own...

So yeah, I stand by my description of that as fairly challenging,
and I'm really glad it's not me in that position.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

On 9 February 2014 09:52, Russ Allbery r...@debian.org wrote:
 If you're looking for Policy Editors who enjoy running things through a
 process that won't be successful just so that we can say they've been run
 through a process, you're going to need someone other than me.

In that case, wouldn't it make sense to have a quick chat with the
other policy editors about officially delegating the task of deciding
on policy for depending on init systems to the tech ctte?

Could even open a new bug for it!

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: Call for votes on init system resolution

[Anthony Towns]

On 7 February 2014 06:20, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
 Don Armstrong writes (Bug#727708: Call for votes on init system resolution):
 Given the already stated preferences of the CTTE, and the previous votes
 we've already had, openrc and sysvinit are clearly not going to defeat
 any option, so their position in your vote is largely irrelevant.
 If we held the votes separately in the other order, T-vs-L first, and
 T won, I would put GR ahead of systemd-T.  So if we vote on U-D-O-V
 first, l don't know whether to rank systemd above GR.

Based on your initial vote on your own ballot and the above, your
votes would be:

  1.  LFT
  2a. (L wins): UDF
  2b. (T wins): FUD (*cough*)

or:

  1. UD  (where do I put F?)
  2. LFT

Presuming everyone votes, where you put F only has an impact in either
case only if at least three other ctte members will also vote FD above
T or DT (given UT is irrelevant); which based on the already expressed
preferences and votes, isn't actually going to happen.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: Call for votes on init system resolution

[Anthony Towns]

On 7 February 2014 08:44, Adrian Bunk b...@stusta.de wrote:
 If Colin joins Ian, Andreas and Steve in voting DT and UT below FD,
 then T is dead.

It's really pretty terrible to actively use FD to try to block options
that aren't your favourite. Honestly, I would have expected the tech
ctte to be able to come to a consensus on a set of proposals
considered reasonable by all the members, and accept whatever a
majority decided. I'd certainly hope that tech ctte members won't
tactically change their vote to try to hack the process.

(The obvious counter is for the four members who prefer T to L to vote
all the L options below FD in the same way as Andi, Ian and Steve have
voted all the T options below FD)

(Longer term, it seems to me the vote system would be improved by only
allowing voters to cast a vote that ranks the proposed options between
themselves, or to vote for Further Discussion (with no ability to
express preferences amongst the proposals). Quorum would then be
satisfied by having Q votes ranking the options, and a vote would only
be blocked if there was 50% or more of voters voting for FD. A similar
idea to supermajority requirements could be achieved by allowing
proposals to be blocked by 1/N voters voting for FD where N  2)

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

Hey Colin,

On 29 January 2014 21:13, Colin Watson cjwat...@debian.org wrote:
 On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
Q2: Is it OK for packages to depend on a specific init system as
pid 1 ?
   Q2a: Is it OK for packages providing init systems to provide other
 APIs beyond just the minimum needed for starting/stopping services?
 We might disagree on the extent, perhaps, but I doubt anyone on the
 committee would vote against this in its general form;

So looking at the votes today, I would have said that both Ian and
Andi's original votes are against this (ranking the options which
allow specifying a dependency on a specific init below further
discussion), and probably Steve's does too, although I assume that's
more an objection against the wording.

At least, the impact seems like it is:

 - init systems can provide whatever extra APIs they like
 - other packages can only use extra APIs if they have a dependency on
the providing package
 - packages may not depend on specific init systems

 * therefore packages cannot use the extra APIs

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: Call for votes on init system resolution

[Anthony Towns]

On 6 February 2014 11:20, Russ Allbery r...@debian.org wrote:
 I therefore intend to change my vote to list FD first iff Steve does the
 same, since I think it's up to him to decide whether he wants to stop,
 rework, and start again, or just continue on since the vote has started
 anyway.

The votes so far are:

 ian: UL DL OL VL GR *FD* UT OT VT DT
 andi: UL DL OL VL *FD* GR UT DT OT VT

 steve: UL DL *FD* OL VL UT DT OT=VT GR
 russ: DT GR DL UT *FD* OT VT UL OL VL
 colin: UL DL OL UT DT GR *FD* OT VL VT
 don: DT DL UT UL OT OL VT VL GR *FD*

 ian2: FD UL DL OL VL GR UT OT VT DT
 andi2: FD UL DL OL VL GR UT DT OT VT

With the initial vote, the following options are eliminated:

 OT, VT  (ian, andi, steve, russ vote these below FD)

With Ian and Andi's changed votes, the following options are eliminated:

 OL, VL (ian2, andi2, steve, russ vote these below FD)

That leaves UL, UT, DL, DT and GR still in the race against FD.

If Steve changes his vote to FD  *, and Russ does likewise as he's
stated, the vote will be decided as FD again.

If no one changes their vote, then, at present, the comparisons are:

  UL = FD 3:3 (steve, colin, don in favour; russ, ian2, andi2 against)
  UT = FD 3:3 (russ, colin, don in favour; steve, ian/ian2, andi/andi2 against)
  DT = FD 3:3 (russ, colin, don in favour; steve, ian/ian2, andi/andi2 against)
  GR = FD 3:3 (russ, colin, don in favour; steve, ian2, andi/andi2 against)

So those options will be eliminated if Bdale and Keith don't vote, or
if either Bdale or Keith vote them below FD.

  DL  FD 4:2 (ian2, andi2 against)

That can only be eliminated at this point if both Bdale and Keith vote
it below FD. It's the only option that had all six original votes
ranking it above FD.

(As it stands, DL would thus win the vote since all other options are
eliminated)

As it stands, that also means that Bdale and Keith could collude to
determine the outcome of the vote amonst {D,U}{L,T} by only voting the
option they prefer above FD.

GR comparisons are:

  UL  GR 5:1 (russ against)
  UT = GR 3:3 (steve, colin, don in favour; ian, andi, russ against)
  DL  GR 6:0
  DT  GR 4:2 (ian, andi against)

Rankings between remaning actual outcomes is:

  4x  UL  DL  UT  DT  (steve, colin, ian, andi)
  2x  DT  DL  UT  UL  (russ, don)

So that's

   UL  DL  DT  4:2
   UL  UT  DT  4:2
   DL  UT  6:0

It seems to me that if this ballot fails to FD, any future ballots
should skip options:

  OT, VT  (insufficient support over FD)
  OL, VL  (at least 6 of 8 committee members prefer UL and DL over
these options)

It seems unlikely that there's any actual support for UT, either.


Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: Call for votes on init system resolution

[Anthony Towns]

On 6 February 2014 16:27, Anthony Towns a...@erisian.com.au wrote:
 Rankings between remaning actual outcomes is:
   4x  UL  DL  UT  DT  (steve, colin, ian, andi)
   2x  DT  DL  UT  UL  (russ, don)

Ah! I thought there was something to add here

The above votes divide neatly into upstart v systemd camps. Given
Bdale and Keith have expressed a preference for systemd previously,
presumably they fall onto the systemd side; so will vote presumably
vote either DT or DL above the other options, and will vote DL  UL,
and DT  UT.

In that case,

  DL  UT6:2, 7:1 or 8:0

  DL = DT  6:2, 5:3 or 4:4
  UL = UT  6:2, 5:3 or 4:4
  UL = DT  6:2, 5:3 or 4:4

  DT = UT  4:4
  DL = UL  4:4

UT would thus have no chance of being in the Schwartz set (it doesn't
beat anything, and is beaten by DL).

Possible outcomes are then:

  DL = DT  6:2, 5:3 or 4:4
  UL = DT  6:2, 5:3 or 4:4
  DL = UL4:4

ie:
 - if either Bdale or Keith vote DT below UL or DL, DT loses, and the
result is determined by Bdale's casting vote between UL and DL
 - otherwise, the result is determined by Bdale's casting vote amongst
UL, DL and DT

Also, Russ correctly points out:
DL  GR 6:0
 For whatever it's worth, I think this line is wrong.  I voted GR above DL.

Hopefully there wasn't much else wrong with the analysis. (Having 10
options on a vote that's supposed to have its results tallied by hand
seems nuts to me...)

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: TC resolution revised draft

[Anthony Towns]

On 2 February 2014 04:05, Uoti Urpala uoti.urp...@pp1.inet.fi wrote:
 On Sat, 2014-02-01 at 17:10 +, Ian Jackson wrote:
 Sébastien Villemot writes (Bug#727708: TC resolution revised draft):
  P1: DT  UT  DL  UL

 So his example was one where the D/U and L/T choices were independent
 for every voter,

Formally, there isn't a way to vote for an arbitrary partial order by
ranking options. ie, you can't vote for:

  DT  UT
  DL  UL
  UT  UL
  DT  DL

without inadvertently and insincerely expressing further preferences.

Err, yes you can:

  DT  UT = DL  UL

works fine. In which case the votes would be:

  P1: DT  UT = DL  UL
  P2: DL  UL = DT  UT
  P3: UT  DT = UL  DL
  P4: UT  DT = UL  DL

and the pairwise defeats are:

  DT  DL : 3 vs 1
  UT  UL : 3 vs 1
  DT  UL : 1 vs 0
  UT  DL : 2 vs 1

  UT = DT : 2 vs 2
  UL = DL : 2 vs 2

Transitive defeats are then just:

  DT t. defeats DL, UL
  UT t. defeats DL, UL

Schwartz set: { DT, UT }

There aren't any defeats in the schwartz set, so P1 uses a casting
vote to choose which of DT, UT is the winner, presumably DT.

Compare that to the corrected example's potential results:

  combined: UT wins
  D/U first: draw, tie break = D, T wins, so DT
  L/T first: T wins, draw, tie break = D, so DT

So I think you can put the difference down to either people expressing
insincere preferences, or that the additional, sincerely held,
preferences expressable via the combined vote having an effect on the
outcome, which shouldn't be surprising.

Cheers,
aj


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: call for votes on default Linux init system for jessie

[Anthony Towns]

On 28 January 2014 21:39, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
 I don't want to pass a resolution specifying the default without also
 answering the other two, related, contentious questions:
   Q1: Do we intend to support multiple systems long-term, or do we
   intend to settle on a single system, probably in jessie+1 ?

FWIW, that seems overly prescriptive to me -- if we settle on systemd
now, and as a result upstart stops getting maintained and systemfree
gets written that uses the same config files but only works on FreeBSD
and Hurd, maybe no one will want to maintain multiple init systems
later. Conversely, maybe people get excited about some init system we
don't pick as default for jessie and it becomes really awesome by the
time jessie is out; why would we want to prevent it being available in
Debian even if it's not ready to be default, or doesn't work with
Gnome yet, or whatever?

   Q2: Is it OK for packages to depend on a specific init system as
   pid 1 ?

I don't think that's the right question for the issue(s) at play here.

From what I can tell, the important question isn't whether systemd or
upstart happens to be pid 1, but rather whether certain interfaces
(dbus, logind, potentially others) that are only (currently) provided
by systemd are available on the system.

That would make the question break down into something like:

  Q2a: Is it OK for packages providing init systems to provide other
APIs beyond just the minimum needed for starting/stopping services?

  Q2b: If so, is it OK for packages requiring those APIs (such as
logind) to just depend on the particular init system known to provide
them (eg Depends: systemd)?

There's a third related question that I don't think is particularly
crucial, regarding the different ways of telling different init
systems about your service:

  Q2c: Is it OK for packages to provide a service start/stop
description that is understandable by some but not all available init
systems in Debian?

After Steve's and Russ's comments in [0] and [1], and thinking about
it some more, I'm inclined to think all those questions could
reasonably be dealt with through the policy process, though I still
think some non-binding advice from the tech ctte wouldn't be out of
place.

[0] https://lists.debian.org/debian-ctte/2014/01/msg00382.html
[1] https://lists.debian.org/debian-ctte/2014/01/msg00383.html

  Q2: Requiring specific init is forbidden

Note that this answer would preclude providing a package designed to,
say, duplicate aj's environment exactly, because it's awesome and all
his friends want to just be able to apt-get install it and be just as
cool as aj is. I don't think that's a win.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: On diversity

[Anthony Towns]

On 20 January 2014 14:29, Russ Allbery r...@debian.org wrote:
 Steve Langasek vor...@debian.org writes:
 On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
 For my part I think this is generally a good idea, but I have the
 impression that at least Russ would be strongly opposed to this because
 it's too prescriptive.  Probably not much sense in fleshing out such a
 resolution if there's not a consensus for it.
 I think this is all great work to do.  I'm just dubious about enforcing it
 with a technical committee decision.  This is the sort of thing that I was
 expecting to need to do on the Policy front once we have a decision.  I
 think that's the right forum for drilling into the details.

So I wondered what it might look like to say the same thing in a
minimally prescriptive way. Not even going to try guessing if this is
anywhere sufficient as far as Russ is concerned -- I'm not claiming to
know where Russ might draw the line on that topic. I've also added
some minimal tech ctte-esque boiler plate; I'm sure Ian could do
better.

---
The tech ctte determines as follows:

  [non-essential-init] In order to allow Debian users and developers
to easily design, test and deploy alternative init systems both now
and in the future, no init system in Debian should be provided via an
Essential:yes package.

  [default-init] Having examined the features and bugs of the various
init systems packaged for Debian, the default init system for jessie
for Linux architectures shall be {OpenRC | systemd | upstart |
determined by a GR}.

The tech ctte further offers the following advice to maintainers:

  [logind] The systemd/logind API provided by systemd and documented
on the freedesktop API will be important for a number of packages, and
that API should be made available within Debian for users of init
systems other than systemd. The various non-systemd init system
maintainers are encouraged to work with the systemd maintainers and
upstream to limit the code duplication that may result from this, and
to ensure enhancements and bug fixes are as widely available as
practical (both within Debian for different inits/architectures and
upstream). The maintainers involved should work through the policy
process to establish a virtual package for this API if needed.

  [required-init] In order to avoid users mistakenly removing all init
systems from their machine, we recommend the init maintainers
establish a virtual package (eg, init-system) that all init systems
in Debian both provide and conflict with, and that an Essential:yes
package depend on that virtual package. This should be undertaken
using the normal policy process.

  [init-minimal-compatability] In order to make it simple for packages
to work with different available init systems, a simple means of
providing a startup script/configuration that is understood by all
Debian init systems should be documented in policy as a requirement
for for packages providing the init system virtual package. This may
be providing a sysvinit style script and adding it via update-rc.d for
instance. This method may be assumed to always be available if the
[required-init] advice is followed, and thus packages can avoid a
dependency on the virtual package.

  [init-crossgrades] In order to provide a good user experience when
switching init systems, maintainers of init systems other than the
default should test converting both to and from their init system, and
that the system is able to correctly shutdown and restart after
transitions to different init systems.

  [init-related-patches] Maintainers should accept non-intrusive
patches to provide enhanced support for init systems (both for the
default init and other inits included in Debian). Patches may be
considered intrusive by the maintainer if they introduce additional
dependencies or significant patches to code that are not accepted
upstream. Patches that merely add files to the package or provide
extra code to maintainer scripts should generally not be considered
intrusive. Where a reasonable amount of time has been given to the
maintainer to review proposed patches via the BTS, and no objection
has been raised, a NMU to incorporate the patch is appropriate.

  [cgroups] Maintainers should be aware cgroups is a Linux-only
feature; if their package requires the use of cgroups to be usable it
should be configured to not build for non-Linux architectures. Where
cgroups support is a compile-time feature, it should generally be
supported on Linux architectures, and disabled on non-Linux
architectures, for the same reason.

  [systemd-portability] Maintainers should be aware systemd relies
heavily on cgroups and potentially other Linux-only features, and thus
should be aware that unless/until this changes, requiring use of a
systemd unit file for startup will likewise require their package to
be configured to not build for non-Linux architectures.
---

I think the [non-essential-init] and any of the four options for
[default

Bug#727708: On diversity

[Anthony Towns]

On 17 January 2014 03:52, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
 What is Debian ?  In one respect, Debian is an operating system.  And
 of course in another respect Debian is a community.
 * Debian is a forum for cooperation and technical development.
 * Debian, as a piece of software, tries to be all things to all
   people (within reason).

So the original message referring this to the tech ctte was about
deciding on the default init system. Honestly, that seems like the
least interesting part of this discussion to me; and I wonder if the
ctte shouldn't consider answering some different, but related question
that more directly addresses issues like packages depending on cgroups
or logind. Something like:

 a) maintainers should be aware cgroups is a Linux-only feature; if
their package requires the use of cgroups to be usable it should be
configured to not build for non-Linux architectures.

 b) maintainers should be aware systemd relies heavily on cgroups, and
thus should be aware that requiring use of a systemd unit file for
startup will likewise require their package to be configured to not
build for non-Linux architectures.

 c) logind or an equivalent service implementing the freedesktop.org
systemd/logind api should be available under all supported init
systems and architectures in Debian. It should be provided via a
virtual package fdo-logind and packages (such as desktop managers)
expecting logind to be available should Depend on fdo-logind

 d) [are packages likely to start depending on
localed/hostnamed/timedated/machined/??? in the same way as logind
such that it would need to be available outside systemd for upstart to
be a useful init?]

 e) no init system in Debian should be marked as Essential:yes, or
depended upon by any Essential:yes or Priority:required package except
through the virtual package init-system. All init packages should
Provide: and Conflict: init-system. base-files should Depend:
init-system.

 f) all init systems Providing the init-system virtual package must
support packages providing sysv style init scripts via update-rc.d.

 g) packages that do not work with sysv must declare a Depends: on the
init systems they do support, eg upstart | systemd

 h) having examined the various current available init systems, the
tech ctte considers [OpenRC] to be the best available init
implementation at present, and so determines that the relevant
maintainers, including the installer team and ftpmasters se it as the
default init-system for new Debian installs. This decision becomes
vacant should a general resolution specifying an alternative init
system as the default pass with a simple majority prior to jessie's
release.

 i) all these decisions revert to advisory opinions after the release
of jessie, and may then be changed by the usual methods of consensus
driven policy development, and maintainer decisions, or by referring
the issue to the tech ctte again.

I think (a) and (b) are pretty non-controversial. (c) and (d) are
required if we want to deal with new GNOME stuff and anything other
than systemd probably, and don't seem very hard to either do or
document. (e), (f) and (g) seem like a fairly straightforward of
allowing for multiple init systems in Debian. I think something like
(i) might be a good way of sunsetting tech ctte decisions so if
there's an actual consensus in future, there's no need to get a
pro-forma vote from the ctte to make changes in future. YMMV of
course.

In my ideal world, the tech ctte would work out good answers to all
the bits above except (h) and get those added to policy, then propose
various options for (h) as a GR themselves, with well argued
rationales for each of the options along the lines of what's already
been posted to the list. How much that conflicts with the No detailed
design work portion of the ctte's mission statement is up for debate
though. Why you'd have a *technical* committee and forbid them making
sure the details are right doesn't make a lot of sense to me though.
Fortunately I'm not on the tech ctte list, so I can look into details
all I like ;)

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: On diversity

[Anthony Towns]

On 20 January 2014 14:29, Russ Allbery r...@debian.org wrote:
 Steve Langasek vor...@debian.org writes:
 On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
 I think (a) and (b) are pretty non-controversial. (c) and (d) are
 required if we want to deal with new GNOME stuff and anything other
 than systemd probably, and don't seem very hard to either do or
 document. (e), (f) and (g) seem like a fairly straightforward of
 allowing for multiple init systems in Debian. I think something like
 (i) might be a good way of sunsetting tech ctte decisions so if there's
 an actual consensus in future, there's no need to get a pro-forma vote
 from the ctte to make changes in future. YMMV of course.
 For my part I think this is generally a good idea, but I have the
 impression that at least Russ would be strongly opposed to this because
 it's too prescriptive.  Probably not much sense in fleshing out such a
 resolution if there's not a consensus for it.
 I think this is all great work to do.  I'm just dubious about enforcing it
 with a technical committee decision.  This is the sort of thing that I was
 expecting to need to do on the Policy front once we have a decision.  I
 think that's the right forum for drilling into the details.

Personally, I'm still not really clear on where the ctte is leaning
wrt supporting multiple init systems; if the idea is that [OpenRC]
becomes the new default, and declares itself as Essential:yes, and the
Debian maintainers of [systemd and upstart] say okay, I give up, I'm
going to work on [OpenRC] now, it doesn't seem like there'd be much
need for policy work. Obviously, switch the init systems around as
appropriate. I believe I've seen comments along those lines from both
systemd and upstart maintainers should upstart or systemd be chosen as
the default, but maybe I'm mistaken. I'm pretty sure I've seen
numerous comments that Debian should only support one init system (per
kernel, at any rate), which would make the Essential:yes part make
sense. To me that seems like it would be a bad outcome (even if we
adopted upstart everywhere and abandoned sysvrc, systemd and openrc
entirely; it would still make it unduly difficult to experiment with
the next next-generation init systems in a Debian environment). I'd
expect the tech ctte's decision to be prescriptive enough that it's
clear what non-default-init-system maintainers and users should do,
post-apocalypse, I guess.

On a practical note, having a quick look at the policy list, it seems
like that's not actually crazy active/responsive at present either
(long overdue updates to menu policy and triggers documentation are
the only topics this month?), so relying on -policy for detail work
doesn't seem like it would actually work out in a timely fashion?

Honestly, I was a bit surprised that Steve thinks the above's a good
idea, given I wrote it from the (my) perspective of wanting to support
multiple init systems within Debian; and my understanding is his
opinion is that that's kind-of nuts. I think that's pretty great
through, especially in that it affirms my naive faith that drilling
down into technical details is a good way of achieving consensus
amongst people with very different goals and political/philosophical
stances... ;)

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system thoughts

[Anthony Towns]

On 31 December 2013 12:55, Colin Watson cjwat...@debian.org wrote:
 The criticisms of Upstart's event model in the systemd position
 statement simply do not make sense to me.  Events model how things
 actually happen in reality; dependencies are artificial constructions on
 top of them, and making them work requires the plethora of different
 directives in systemd (e.g. Wants, which is sort of a non-depending
 dependency) to avoid blocking the boot process on a single failing
 service.

Riffing off this more than replying to it.

I tend to think dependencies and events are both useful ways of
describing when to start up parts of the system. In particular, it
seems like:

 - when a network is connected, start web server
 - when a usb disk is connected, mount it
 - when a VPN is started, sync various things

are best described by an event model, while:

 - in order to run GNOME, logind must be started
 - in order to run logind, dbus must be available
 - as part of making the system ready for a user, network-manager
should be running

make the most sense when described by dependencies. In particular,
in many of those cases, the reverse might not be true: For debugging,
I might want to start the web server manually without connecting the
network; or I might want logind running without GNOME, or
network-manager running without the other parts of my desktop
environment.

Events and dependencies aren't that different; an event essentially
lets a service X say that:

  whenever Y happens, X happens
  whenever Y happens, X stops happening

while a (systemd'ish) dependency says either:

  when X happens, Y happens as well[X Requires: Y]
  before X happens, Y happens as well   [X Requires: Y, After: Y]
  after X happens, Y happens as well [X Requires: Y, Before: Y]

(with Wants and Requisite and Overridable variants as well; also
RequiredBy and WantedBy variants)

If you look at Y, there are a few phases it could go through:

no-Y
Y-starts-starting
Y-started
Y-begins-ending
no-Y

If you wanted to emulate upstart events with dependencies, you'd need
to do four things, I think:

* create a dummy Y-started-event unit [network-is-available,
usb-is-available]
* invoke systemctl start Y-started-event when Y is finished starting
* invoke systemctl stop Y-started-event when Y begins ending
* add RequiredBy: Y-started-event and PartOf: Y-started-event
to X's unit file

That seems reasonably straight forward to me? If the event is
something systemd already knows about, you might only need to do
something equivalent to the last step. I don't think invoking
systemctl start/stop is any better or worse than whatever would be
needed to notify upstart of the same events.

To emulate systemd dependencies in an event model (ie, X depends on
Y), you'd need to do either:

* change Y's job to say start on starting X
* add stop on stopping Y to X's job description

or

* add a pre-start script to X in order to start Y first
* add stop on stopping Y to X's job description

The latter looks like it's the documented way of doing things. Neither
of those seem particularly great -- I think that's due to upstart not
letting you reverse event descriptions in the same way that systemd
has Requires/RequiredBy statements. If you could say:

   * on starting start Y
   * stop on stopping Y

in X's job description, by contrast, I think that would be a fine way
of declaring a dependency from X to Y without leaving the event
model. Not having a simple way of specifying this sort of dependency
seems pretty weak on upstart's behalf.

It would probably also be nice to have a way of saying when a new
network comes up, reload/refresh service X -- so that it could bind
to new ports or whatever even if it was already running; that seems
like the sort of thing that would be easier to specify in an event
model (on new-network-interface-started reload or start), than in a
dependency model.

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system thoughts

[Anthony Towns]

On 18 January 2014 17:19, Russ Allbery r...@debian.org wrote:
 It's worth noting that even the second solution above does not allow
 simulation of systemd's Requisite=, only Requires=.  Now, normally
 Requires= (when starting X, start Y if not already started) is going to be
 fine, but I can certainly imagine cases where Requisite= (if Y is not
 started, just immediately fail startup of X) is the behavior one actually
 wants.  I'm not sure how you would pry that behavior out of upstart's
 event model short of bypassing the event structure entirely and just
 writing an explicit check in shell in pre-start to ask whether Y is
 running.

I think this would be most analogous to the complex conditions bit,
where you'd say

  start on Y and Q

so that it will only be started when event Q happens if Y has also
already happened. I don't see how you'd prevent it from being manually
started without a prescript checking for Y though, but I'm not
entirely sure if that bothers me -- if I'm manually telling it to
start a daemon, that's configured not to automatically start some
thing it needs, do I care that much if I get an error from upstart or
the daemon itself?

Of course, upstart's complex conditions are documented not to work
the way you'd expect, so that's not entirely a solution. I could
easily imagine the complex condition support being enhanced to work to
fix the behaviour described in [0] and to also block manual starts of
the service prior to events happening, but that's not something that
exists now afaics. And the CLA's essentially the opposite of saying
patches welcome...

(Personally, I think I'm convincing myself that in an ideal world I'd
prefer the event model. upstart doesn't seem to implement that
sufficiently though at this point. Sigh, now I'm imagining an event
based init system written in haskell...)

Cheers,
aj

[0] http://upstart.ubuntu.com/cookbook/#restarting-jobs-with-complex-conditions

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: Bits from linux.conf.au

[Anthony Towns]

On 15 January 2014 20:36, Martin Pitt mp...@debian.org wrote:
 It's not realistic for a maintainer to continuously test three init
 systems;

It's not realistic for a maintainer to continuously test against 13
architectures (including three different kernel trees) either. So we
don't do that and instead let maintainers make their best effort when
packaging, expect them to test locally, and then rely on porters and
users to report bugs when there are problems.

 it's not realistic for a porter to continously test startup
 scripts for thousands of packages.

It's reasonable to semi-continuously test installation scripts for
thousands of packages -- that's what piuparts does, and we have
sponsored cloud resources to support that. It seems like that would be
fairly straightforward to duplicate for testing packages with
alternative init systems.

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: init system discussion status

[Anthony Towns]

On Jan 5, 2014 2:39 AM, Russ Allbery r...@debian.org wrote:
 I'm doubtful that either of us are going to convince the other on this
 point.  I don't consider it comparable to the other examples you're
 citing, and I think it's inobvious that raise(SIGSTOP) is a good technical
 choice.  Simple, yes, but that's not the same thing.

How hard would it be to write an external wrapper that converts the systemd
style socket activation to the SIGSTOP  protocol (for upstart invoking a
systemd compatible daemon)? Or to add support to start-stop-daemon for both
protocols so a reliable sysv style script is trivial for more modern
daemons?

Cheers,
aj

Bug#727708: init system discussion status

[Anthony Towns]

On Jan 5, 2014 10:40 AM, Russ Allbery r...@debian.org wrote:
 Anthony Towns a...@erisian.com.au writes:
  How hard would it be to write an external wrapper that converts the
  systemd style socket activation to the SIGSTOP protocol (for upstart
  invoking a systemd compatible daemon)?

On second thoughts, I think I meant this the other way around - systemd
invoking an upstart compatible daemon, since it seems like upstart is more
likely to support the systemd socket activation protocol than systemd is to
support upstart's SIGSTOP  protocol.

 The wrapper could fork
 and then exec the daemon in the *parent*, and have the *child* listen for
 the notification message and then kill(SIGSTOP) its parent and immediately
 exit.  I wonder if that would actually work

Nice :)

Cheers,
aj

Bug#727708: init system other points, and conclusion

[Anthony Towns]

  xfce4  16800 0 0 0 16800
(Debian Xfce Maintainers)

Personally, I run xfce because it works best for me; I wouldn't give
even a moments thought to running Gnome because by doing so I might
find and fix some bugs that would help other folks. I'd apply the same
argument to systemd/upstart, personally. To me, that seems like the
best way to let the most beneficial technology win out.

It seems to me like what should the default init system be? is a
very different question depending on whether other init systems are
also well supported. I get the impression that you think there's not
much chance of other init systems working well, while what I've read
from Russ and Ian seems to indicate that it ought to at least be
feasible. I can certainly understand that multiple init systems isn't
a winning idea from the point of view Ubuntu (or Red Hat) would take
when putting together a distribution, but I would have thought it was
something Debian could/should/would manage.

Forced to make a choice, should Debian go for smoother/tighter
integration between apps, or more choice for users/sysadmins? I'd
expect Debian to choose the latter; though Ubuntu, Red Hat and
possibly Fedora might choose the former.

Cheers,
a por que no los dos? j

-- 
Anthony Towns a...@erisian.com.au
Not speaking for my employer...


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727708: loose ends for init system decision

[Anthony Towns]

Okay, let's see how replying to a mail on my phone while in flight mode
goes. Apologies in advance for formatting, quoting and vocabulary issues.

On Dec 31, 2013 4:48 AM, Russ Allbery r...@debian.org wrote:

 2. Impact of Multiple Init Systems
 Obviously, the ideal situation for project-wide integration and support,
 and for Debian's ability to make full use of the capabilities of new init
 systems, is for all of Debian's ports to be running the same init system.

So, reading this (and trimming loss of stuff that makes sense) I wonder if
it's worth stepping back and considering what happens when a package
doesn't support /any/ init system. The answer I think is that the sysadmin
sighs, adds their own configuration, and maybe thinks well at least I
didn't have to compile it, I guess.

That still sucks compared to the alternative of typing apt-get install
and having it just start working, of course.

 Attempting to support multiple init systems has several obvious drawbacks:

 * Packages will either be limited by the functionality of the least
   capable init system or will behave differently (and have to be
   configured differently) on different ports.

I think the Debian way of dealing with multiple init systems would be to
provide a compatibility layer for the most common packaging and admin
tasks, and allowing packages to provide fancier integration where
appropriate. I'm thinking of things like newaliases and sendmail, and
cgi-bin and apache modules, I guess. Probably that's already covered for
init systems via sysvinit compatibility and update-rc.d. Maybe there's a
missing tool that could be written to let you set init specific
configuration somehow, which would change /etc/default for sysv and other
files for upstart/systemd.

It seems like there's maybe three separate questions then: what init system
gets used by default, what work gets done to make that experience
different/better than everything just having upstart or systemd pretending
to be sysvinit, and what's the experience of maintaining packages to
support secondary init systems and using secondary init systems on a Debian
system?

(Personally, I think a gr would be better for choosing the default then
having the tech ctte decide that issue, but whatever)

Based on what I've read, it seems like the ideas floating around amount to:

- if systemd is default: there would be a release goal to include systemd
configs added to packages and to get daemons converted to support socket
activation. Maybe other stuff too? As far as maintaining sysvinit, openrc
or upstart systemd goes, you'd just have to get upstart configs written and
packaged, and accept that there's an unused systemd library on your system.
Multiple inits must be supported to some extent, since systemd isn't
available on ports and that isn't likely to change apparently.

- upstart is default, other inits are supported: pull in Ubuntu configs for
upstart for various packages. If systemd socket stuff is allowed, dummy
library will probably be on most systems, if not, systemd in Debian won't
be very interesting.

- upstart is default and only init supported by Debian. Same support work
for Jessie, except any ports that want to stick around need to get upstart
enabled.

I don't think the latter is really the Debian way - better to have the
choice left in the users' hand if feasible, but it's likely a lot easier to
get some impressive results that way. I think the ideal page for tradeoffs
like that is in derivatives like Ubuntu personally.

 I believe Debian should take this path forward:
 1. We should select a new init system for jessie, either systemd or
upstart.  Support for that init system should be release-critical, but
only in the sense that the daemon works properly under that init
system.  In other words, use of the sysvinit compatibility of either
init system is acceptable support for jessie.

So that would mean switching the init system, and decorating anything that
breaks as a result RC buggy. Seems sensible.

 2. All packages providing init scripts must continue to support sysvinit
scripts through the jessie release.  Such support will continue to be
release-critical.

I'm not sure this makes sense, though. If someone packages a new daemon
that works fine with systemd and upstart, I don't see why it shouldn't get
released just because it doesn't work with two secondary init systems.
Filling a wishlist bug with a patch and doing an NMU seem like they'd be
sufficient here.

As far as upgrades go, if the idea is that systemd is the way to go for
Jessie it seems to me that an update would by default switch you from
sysvinit to systemd (likewise for upstart) - I don't think it makes much
sense to do systemd/upstart for new installs but leave upgrades with sysv
until Jessie+1.

 7. After jessie, functionality between systems running the primary Linux
init system and other init systems (including non-Linux ports) should
be allowed to drift.  In other 

Bug#699808: tech-ctte: syslinux vs the wheezy release

[Anthony Towns]

On 5 February 2013 22:48, Julien Cristau jcris...@debian.org wrote:
 Package: tech-ctte

 - the debian-installer source package, which builds the installer images
   for debian's releases, build-depends on syslinux
 - the release freeze for wheezy started in June 2012, and is now in its
   final stages
 - one of the prerequisites for the release is a release candidate for
   the installer
 - the syslinux maintainer uploaded new upstream versions of his package
   to unstable, which were unsuitable for wheezy, in November 2012, and
   again at the end of January 2013
 - the latest of these uploads breaks the installer, [...]

Isn't this a rationale for d-i to use the stable builds of syslinux
present in testing (or potentially testing-proposed-updates) rather
than unstable?

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#636783: proposed constitution fix for super-majority within the tech ctte

[Anthony Towns]

 the default option to be
+   used, the quorum required, and any supermajority requirements.

 B. Use of language and typography

Cheers,
aj

--
Anthony Towns a...@erisian.com.au



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#606176: /usr/bin/openrocket wrapper does not pass arguments

[Anthony Towns]

Package: openrocket
Version: 1.1.3-1
Severity: wishlist 
Tags: patch

Running openrocket blah.ork doesn't work, but it does if you change
the wrapper script:

--- /usr/bin/openrocket.old 2010-12-07 14:43:16.0 +1000
+++ /usr/bin/openrocket 2010-12-07 14:43:27.0 +1000
@@ -1,2 +1,2 @@
 #!/bin/sh
-java -jar /usr/share/java/OpenRocket-1.1.3.jar
+exec java -jar /usr/share/java/OpenRocket-1.1.3.jar $@

Cheers,
aj

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.35-trunk-686 (SMP w/1 CPU core)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages openrocket depends on:
ii  libjcommon-java 1.0.16-1 General Purpose library for Java
ii  libjfreechart-java  1.0.13-3 Chart library for Java
ii  libmiglayout-java   3.7.2-1  The Java Layout Manager
ii  openjdk-6-jre   6b18-1.8.2-4 OpenJDK Java runtime, using Hotspo

openrocket recommends no packages.

openrocket suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#592170: [Debconf-team] Bug#592170: please add debconf delegates to intro/organisation

[Anthony Towns]

On Sat, Aug 7, 2010 at 20:58, Michael Schultheiss schul...@debconf.org wrote:
 Holger Levsen wrote:
 Marga remembered that she, Ganneff and me (and probably others (*))
 were delegates, but I couldnt find such a mail from aj to
 d-d-a now, which is no surprise to me, given that DebConf
 has just ended.
 I found AJ's delegation at:
 http://lists.debian.org/debian-project/2006/06/msg00265.html
 http://lists.debconf.org/lurker/message/20060622.150218.0fd6bc26.en.html

Technically that was restricted to a venue decision for 2007 and was
revoked later anyway [0] as part of making the decision using public
criteria and an open IRC discussion (which aiui has only improved
since). Personally, I'd suggest just getting Stefano to do a new
delegation of some active/key debconf people and ignore the old stuff.

[0] http://lists.debian.org/debian-project/2006/07/msg00041.html

Just my 2c, FWIW, HTH, etc.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#155676: md5sums files

[Anthony Towns]

On Sun, Mar 7, 2010 at 10:28, Goswin von Brederlow goswin-...@web.de wrote:
 Anthony Towns a...@erisian.com.au writes:
 Advantages of doing it when uploading:
  - provides some sort of double check of what's being uploaded
  - saves CPU time on users' machines
   - avoids having bad checksums due to the user having bad hardware
     (which is one big use case of the files)

Big? It only makes a difference if:
  a) the corruption happens as soon as it's written, not after some time
  b) the file is too big/the system is too loaded to keep the file in
the page cache
  c) the system memory is corrupted just enough to screw the file but
not everything else

Compared to random make install invocations changing files in the
system and similar, that doesn't strike me as a big use case.

In any event, it's fairly easy to generate the checksum in the same
pass as generating the file, see the attached patch. (It's not as easy
to generalise to other hashes as the previous one, unfortunately)

If you're still worried, perhaps about having read() return bogus data
from the .deb that happens to still be valid when passed through
ungzip and untar and after you've already verified the entire file by
md5/sha1/sha256 when downloading, you're getting to the point of
trying to safely install on an actively malicious system, and
nothing's going to make that work.

Cheers,
aj

-- 
Anthony Towns a...@erisian.com.au
diff -x configure -x '*.m4' -x Makefile.in -urbN dpkg-1.15.5.6/configure.ac dpkg-1.15.5.6-aj/configure.ac
--- dpkg-1.15.5.6/configure.ac	2010-01-08 18:00:34.0 +1000
+++ dpkg-1.15.5.6-aj/configure.ac	2010-03-07 04:38:32.547372468 +1000
@@ -51,6 +51,16 @@
 esac])
 AC_SUBST(admindir)
 
+# Allow alternative default hash function
+hashtype=md5
+AC_ARG_WITH(hashtype,
+	AS_HELP_STRING([--with-hashtype=HASH],
+	   [hash function to use for .hashes files]),
+[case $with_hashtype in
+  md5|none) hashtype=$with_hashtype ;;
+  *) AC_MSG_ERROR([invalid hashtype specified]) ;;
+esac])
+AC_SUBST(hashtype)
 
 # Checks for programs.
 AC_PROG_CC
diff -x configure -x '*.m4' -x Makefile.in -urbN dpkg-1.15.5.6/debian/changelog dpkg-1.15.5.6-aj/debian/changelog
--- dpkg-1.15.5.6/debian/changelog	2010-01-09 04:02:03.0 +1000
+++ dpkg-1.15.5.6-aj/debian/changelog	2010-03-07 04:13:03.171356041 +1000
@@ -1,3 +1,11 @@
+dpkg (1.15.5.6+aj) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Automatically create /var/lib/dpkg/info/pkg.hashes containing MD5 hashes
+for unpacked files.
+
+ -- Anthony Towns a...@lazuline  Sun, 07 Mar 2010 04:12:32 +1000
+
 dpkg (1.15.5.6) unstable; urgency=low
 
   * dpkg-source: with format 3.0 (quilt) ensure quilt's .pc directory is
diff -x configure -x '*.m4' -x Makefile.in -urbN dpkg-1.15.5.6/lib/dpkg/buffer.c dpkg-1.15.5.6-aj/lib/dpkg/buffer.c
--- dpkg-1.15.5.6/lib/dpkg/buffer.c	2010-01-09 03:23:06.0 +1000
+++ dpkg-1.15.5.6-aj/lib/dpkg/buffer.c	2010-03-07 15:50:33.379710844 +1000
@@ -60,6 +60,13 @@
 	case BUFFER_WRITE_MD5:
 		buffer_md5_init(write_data);
 		break;
+	case BUFFER_WRITE_DUP:
+		{
+		  struct buffer_data *bddup = write_data-arg.ptr;
+		  buffer_init(NULL, bddup[0]);
+		  buffer_init(NULL, bddup[1]);
+		}
+		break;
 	}
 	return 0;
 }
@@ -90,6 +97,13 @@
 	case BUFFER_WRITE_MD5:
 		buffer_md5_done(write_data);
 		break;
+	case BUFFER_WRITE_DUP:
+		{
+		  struct buffer_data *bddup = write_data-arg.ptr;
+		  buffer_done(NULL, bddup[0]);
+		  buffer_done(NULL, bddup[1]);
+		}
+		break;
 	}
 	return 0;
 }
@@ -126,6 +140,14 @@
 	case BUFFER_WRITE_MD5:
 		MD5Updatestruct buffer_write_md5ctx *)data-arg.ptr)-ctx), buf, length);
 		break;
+	case BUFFER_WRITE_DUP:
+		{
+		  struct buffer_data *bddup = data-arg.ptr;
+  ret = buffer_write(bddup[0], buf, length, desc);
+		  if (ret != length) return ret;
+  ret = buffer_write(bddup[1], buf, length, desc);
+		}
+		break;
 	default:
 		internerr(unknown data type '%i' in buffer_write,
 		  data-type);
diff -x configure -x '*.m4' -x Makefile.in -urbN dpkg-1.15.5.6/lib/dpkg/buffer.h dpkg-1.15.5.6-aj/lib/dpkg/buffer.h
--- dpkg-1.15.5.6/lib/dpkg/buffer.h	2010-01-08 18:00:34.0 +1000
+++ dpkg-1.15.5.6-aj/lib/dpkg/buffer.h	2010-03-07 15:53:23.319707965 +1000
@@ -36,6 +36,7 @@
 #define BUFFER_WRITE_NULL		3
 #define BUFFER_WRITE_STREAM		4
 #define BUFFER_WRITE_MD5		5
+#define BUFFER_WRITE_DUP		6
 
 #define BUFFER_READ_FD			0
 #define BUFFER_READ_STREAM		1
@@ -52,6 +53,14 @@
 	buffer_hash(buf, hash, BUFFER_WRITE_MD5, limit)
 
 #if HAVE_C99
+# define fd_fdmd5(fd1, fd2, hash, limit, ...) \
+	do { \
+	struct buffer_data fdhash[2]; \
+fdhash[0].arg.i = fd2; fdhash[0].type = BUFFER_WRITE_FD; \
+fdhash[1].arg.ptr = hash; fdhash[1].type = BUFFER_WRITE_MD5; \
+buffer_copy_IntPtr(fd1, BUFFER_READ_FD, fdhash, BUFFER_WRITE_DUP, \
+	   limit, __VA_ARGS__); \
+} while(0)
 # define fd_md5(fd, hash, limit

Bug#155676: md5sums files

[Anthony Towns]

(I'm not subscribed to this list, so go ahead and Cc me)

On Thu, Mar 4, 2010 at 02:05, Peter Samuelson pe...@p12n.org wrote:
 [Wouter Verhelst]
  I must say I was somewhat surprised by these numbers. Out of 2483
  packages installed on my laptop, 2340 install md5sums.
 The surprising part, perhaps, is that dpkg itself didn't just generate
 the other 143 md5sums files at installation time.

The easy (and usually correct) reason for things like that is dpkg's
source is scary.

 I suggested this a long time ago and of course was met with so where's
 your patch?  Of course I was not willing to do the work.

See? Anyway, my patch is attached. It makes dpkg create a foo.hashes
when unpacking foo, whose contents looks like:

MD5:32b5e22f8e336b2f34e0dd87652e6dfc  usr/share/doc/mawk/changelog.gz
MD5:87a34f1f55ac3f7fec2c7fc82565e8eb  usr/share/doc/mawk/changelog.Debian.gz
...

Verification is a matter of something like:

$ cat /var/lib/dpkg/info/*.hashes | sed -n 's/^MD5://p' | (cd /;
md5sum -c) | grep -v ': OK$'

There's an option (--hash) that you can set to none to avoid
spending time calculating md5s if you so choose. Adding support for
sha1/sha256/whatever should be straightforward; afaik dpkg only has
code for md5 already built in though (though just invoking
/usr/bin/sha1sum etc would be an option of course).

Of course another option is just to pull the md5sums directly from the deb:

$ ar p /var/cache/apt/archives/ifupdown_0.6.9_i386.deb data.tar.gz |
tar --to-command='printf %s%s\n $(md5sum - | sed s/-$//)
${TAR_FILENAME#./}'  -xzf - |
diff - /var/lib/dpkg/info/ifupdown.md5sums
1,3d0
 346208729633adf45e2fa3f2bd3b19c6  etc/init.d/ifupdown
 c6fffaae03271f1641920105ce68796b  etc/init.d/ifupdown-clean
 fab851ca87c5deb9d6f665e610184648  etc/default/ifupdown
4a2
 a0f11cf1809a468c49b72e0aa0a8e26b  sbin/ifup

(md5sums doesn't normally list conffiles, but does list hardlinks; the
above command does the opposite)

 But
 fundamentally, shipping a md5sums file is really just a tradeoff in
 download size vs. installation speed, not unlike gzip vs. bzip2.

Advantages of doing in when unpacking:
 - choice of checksum is the admin's decision
 - we can quickly roll out support for sha1/sha256/crc/... checksums
by just changing one package
 - admin has hashes of exactly what was unpacked, no matter the source
 - no concerns about bugs in dh_md5sums or similar resulting in bad checksums

Advantages of doing it when uploading:
 - provides some sort of double check of what's being uploaded
 - saves CPU time on users' machines

For me, I'd rather have dpkg generate the hashes.

Cheers,
aj

--
Anthony Towns a...@erisian.com.au
diff -urb dpkg-1.15.5.6/debian/changelog dpkg-1.15.5.6-aj/debian/changelog
--- dpkg-1.15.5.6/debian/changelog	2010-01-09 04:02:03.0 +1000
+++ dpkg-1.15.5.6-aj/debian/changelog	2010-03-07 04:13:03.171356041 +1000
@@ -1,3 +1,11 @@
+dpkg (1.15.5.6+aj) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Automatically create /var/lib/dpkg/info/pkg.hashes containing MD5 hashes
+for unpacked files.
+
+ -- Anthony Towns a...@lazuline  Sun, 07 Mar 2010 04:12:32 +1000
+
 dpkg (1.15.5.6) unstable; urgency=low
 
   * dpkg-source: with format 3.0 (quilt) ensure quilt's .pc directory is
diff -urb dpkg-1.15.5.6/configure.ac dpkg-1.15.5.6-aj/configure.ac
--- dpkg-1.15.5.6/configure.ac	2010-01-08 18:00:34.0 +1000
+++ dpkg-1.15.5.6-aj/configure.ac	2010-03-07 04:38:32.547372468 +1000
@@ -51,6 +51,16 @@
 esac])
 AC_SUBST(admindir)
 
+# Allow alternative default hash function
+hashtype=md5
+AC_ARG_WITH(hashtype,
+	AS_HELP_STRING([--with-hashtype=HASH],
+	   [hash function to use for .hashes files]),
+[case $with_hashtype in
+  md5|none) hashtype=$with_hashtype ;;
+  *) AC_MSG_ERROR([invalid hashtype specified]) ;;
+esac])
+AC_SUBST(hashtype)
 
 # Checks for programs.
 AC_PROG_CC
diff -urb dpkg-1.15.5.6/src/Makefile.am dpkg-1.15.5.6-aj/src/Makefile.am
--- dpkg-1.15.5.6/src/Makefile.am	2010-01-09 03:23:06.0 +1000
+++ dpkg-1.15.5.6-aj/src/Makefile.am	2010-03-07 04:28:18.771356095 +1000
@@ -6,6 +6,7 @@
 AM_CPPFLAGS = \
 	-DLOCALEDIR=\$(localedir)\ \
 	-DADMINDIR=\$(admindir)\ \
+	-DHASHTYPE=\$(hashtype)\ \
 	-idirafter $(top_srcdir)/lib/compat \
 	-I$(top_builddir) \
 	-I$(top_srcdir)/lib
diff -urb dpkg-1.15.5.6/src/main.c dpkg-1.15.5.6-aj/src/main.c
--- dpkg-1.15.5.6/src/main.c	2010-01-09 03:23:06.0 +1000
+++ dpkg-1.15.5.6-aj/src/main.c	2010-03-07 04:29:59.271360858 +1000
@@ -187,6 +187,7 @@
 const char *admindir= ADMINDIR;
 const char *instdir= ;
 struct pkg_list *ignoredependss = NULL;
+const char *hashtype= HASHTYPE;
 
 static const struct forceinfo {
   const char *name;
@@ -516,6 +517,7 @@
   { admindir,  0,   1, NULL,  admindir, NULL,  0 },
   { instdir,   0,   1, NULL,  instdir,  NULL,  0 },
   { ignore-depends,0,   1, NULL,  NULL,  ignoredepends, 0 },
+  { hash,  0,   1, NULL

Bug#539863: liblua5.1-wsapi1: /usr/bin/wsapi.cgi has ^M characters

[Anthony Towns]

Package: liblua5.1-wsapi1
Version: 1.1.0-4
Severity: important

wsapi.cgi has carriage return (^M, \r) characters at end-of-line, which makes
it non-executable because there's no lua5.1\r in $PATH:

$ /usr/bin/wsapi.cgi 
: No such file or directory

$ /usr/bin/wsapi.cgi 21 |hexdump -C
  2f 75 73 72 2f 62 69 6e  2f 65 6e 76 3a 20 6c 75  |/usr/bin/env: lu|
0010  61 35 2e 31 0d 3a 20 4e  6f 20 73 75 63 68 20 66  |a5.1.: No such f|
0020  69 6c 65 20 6f 72 20 64  69 72 65 63 74 6f 72 79  |ile or directory|
0030  0a|.|
0031

Cheers,
aj



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#539993: sputnik: missing depends on coxpcall?

[Anthony Towns]

Package: sputnik
Version: 9.03.13+1-1
Severity: serious
Justification: Policy 3.5

From /usr/share/lua/5.1/sputnik/actions/wiki.lua:

require(coxpcall)

But liblua5.1-coxpcall0 isn't listed amongst:

Depends: liblua5.1-wsapi1, liblua5.1-markdown0, liblua5.1-cosmo0, 
liblua5.1-filesystem0, liblua5.1-md5-0, liblua5.1-logging, 
liblua5.1-socket2, lua5.1

(xavante depends on it, though; but aiui you don't need xavante for
sputnik)

Cheers,
aj

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.28.2 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages sputnik depends on:
ii  liblua5.1-cosmo0  8.04.14-2  A template library for the lua lan
ii  liblua5.1-filesystem0 1.4.2-1luafilesystem library for the Lua 
ii  liblua5.1-logging 1.1.4-2lualogging library for the lua lan
ii  liblua5.1-markdown0   0.32-1 A pure lua5.1 implementation of th
ii  liblua5.1-md5-0   1.1.2-1MD5 library for the lua language v
ii  liblua5.1-socket2 2.0.2-3TCP/UDP socket library for Lua 5.1
ii  liblua5.1-wsapi1  1.1.0-5Web server API abstraction layer f
ii  lua5.15.1.4-3Simple, extensible, embeddable pro

Versions of packages sputnik recommends:
pn  sputnik-goodies   none (no description available)

sputnik suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#518186: support http://bugs.debian.org/#123456 addresses...

[Anthony Towns]

Package: bugs.debian.org
Severity: wishlist

For browsers that support javascript, it's possible to make pasting
#123456 bug numbers from emails and changelogs slightly easier. Adding
something like the following snippet to the bugs.d.o/ frontpage (ie,
the page on www.d.o that's the target of the redirect) should work fine:

   script
   !--
   var h = document.location.hash;
   if (/^#\d\d+$/.exec(h)) {
   var dest = http://bugs.debian.org/; + h.substring(1);
   alert(Automatically redirecting to  + dest);
   window.location = dest;
   }
   //--
   /script

Cheers,
aj



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#212732: Bug#427909: Bug#212732: support redirects and interactive authentication (Progeny)

[Anthony Towns]

On Fri, Jan 30, 2009 at 09:14:54PM +0100, Michael Vogt wrote:
 On Sun, Dec 21, 2008 at 10:45:13PM +1000, Anthony Towns wrote:
  Attached is a patch against apt 0.7.19 (current in lenny/sid)
  including just the Redirect support from Jeff Licquia's patch in
  Bug#212732. 
 Thanks a lot for this, I merged it into my bzr tree and it will be
 part of the next merge into debian (experimental initially). 

Great!

  As far as the issues described in Bug#66434 with bad redirection [...]
 One possible issue I can see is that consistency may become a
 issue. If the server that redirects does that to mirrors that are not
 in sync and the Release file comes from A but the Packages file from B
 users may run into hashsum failures. 

Yup; that'll be caught and give an error though. I presume the most
likely use will be either redirecting all requests -- in which case
synchronisation isn't an issue; or redirecting pool/ but not dists/ -- in
which case 404s are the only risk, I can see, and seems reasonably minor.

 I can not think of any security concerns about the patch, the
 signature and hashsum code should protect us here to the extend
 possible. 

Yup, that matches my understanding.

Cheers,
aj




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#427909: Bug#212732: support redirects and interactive authentication (Progeny)

[Anthony Towns]

Attached is a patch against apt 0.7.19 (current in lenny/sid)
including just the Redirect support from Jeff Licquia's patch in
Bug#212732. 

As far as the issues described in Bug#66434 with bad redirection and
mod_speling, that seems mostly unlikely to be a problem these days thanks
to the md5 validation and signature support. The only way you could get
unexpected data is if your original Release and Release.gpg files were
redirected to the wrong place, but were completely consistent and had
corresponding Packages files and debs.

In the event that is a concern, the patch lets the user set the 
Acquire::http::AllowRedirect config option to false to block that behaviour.
It'd be possible to have an option to verify the filename part of the URL
is unchanged as well without much difficulty.

I bumped the library version, mostly so I could be sure I was testing the
right thing, but I presume this requires a libapt-pkg ABI bump anyway
(there's an Acquire::Redirect() callback added), so I left it in the
patch.

Cheers,
aj

diff -urb apt-0.7.19/apt-pkg/acquire-method.cc apt-0.7.19aj1/apt-pkg/acquire-method.cc
--- apt-0.7.19/apt-pkg/acquire-method.cc	2008-06-10 07:10:08.0 +1000
+++ apt-0.7.19aj1/apt-pkg/acquire-method.cc	2008-12-21 21:50:41.0 +1000
@@ -447,6 +447,38 @@
 }
 	/*}}}*/
 
+// AcqMethod::Redirect - Send a redirect message   /*{{{*/
+// -
+/* This method sends the redirect message and also manipulates the queue
+   to keep the pipeline synchronized. */
+void pkgAcqMethod::Redirect(const string NewURI)
+{
+   string CurrentURI = UNKNOWN;
+   if (Queue != 0)
+  CurrentURI = Queue-Uri;
+ 
+   char S[1024];
+   snprintf(S, sizeof(S)-50, 103 Redirect\nURI: %s\nNew-URI: %s\n\n,
+ CurrentURI.c_str(), NewURI.c_str());
+
+   if (write(STDOUT_FILENO,S,strlen(S)) != (ssize_t)strlen(S))
+  exit(100);
+
+   // Change the URI for the request.
+   Queue-Uri = NewURI;
+
+   /* To keep the pipeline synchronized, move the current request to
+  the end of the queue, past the end of the current pipeline. */
+   FetchItem *I;
+   for (I = Queue; I-Next != 0; I = I-Next) ;
+   I-Next = Queue;
+   Queue = Queue-Next;
+   I-Next-Next = 0;
+   if (QueueBack == 0)
+  QueueBack = I-Next;
+}
+/*}}}*/
+
 // AcqMethod::FetchResult::FetchResult - Constructor			/*{{{*/
 // -
 /* */
diff -urb apt-0.7.19/apt-pkg/acquire-method.h apt-0.7.19aj1/apt-pkg/acquire-method.h
--- apt-0.7.19/apt-pkg/acquire-method.h	2008-06-10 07:10:08.0 +1000
+++ apt-0.7.19aj1/apt-pkg/acquire-method.h	2008-12-21 21:50:02.0 +1000
@@ -84,6 +84,8 @@
void Log(const char *Format,...);
void Status(const char *Format,...);

+   void Redirect(const string NewURI);
+ 
int Run(bool Single = false);
inline void SetFailExtraMsg(string Msg) {FailExtra = Msg;};

diff -urb apt-0.7.19/apt-pkg/acquire-worker.cc apt-0.7.19aj1/apt-pkg/acquire-worker.cc
--- apt-0.7.19/apt-pkg/acquire-worker.cc	2008-11-24 19:35:21.0 +1000
+++ apt-0.7.19aj1/apt-pkg/acquire-worker.cc	2008-12-21 21:42:06.0 +1000
@@ -220,6 +220,20 @@
 	 Status = LookupTag(Message,Message);
 	 break;
 	
+ // 103 Redirect
+ case 103:
+ {
+if (Itm == 0)
+{
+   _error-Error(Method gave invalid 103 Redirect message);
+   break;
+}
+ 
+string NewURI = LookupTag(Message,New-URI,URI.c_str());
+Itm-URI = NewURI;
+break;
+ }
+   
 	 // 200 URI Start
 	 case 200:
 	 {
diff -urb apt-0.7.19/apt-pkg/makefile apt-0.7.19aj1/apt-pkg/makefile
--- apt-0.7.19/apt-pkg/makefile	2008-06-10 07:10:08.0 +1000
+++ apt-0.7.19aj1/apt-pkg/makefile	2008-12-21 21:54:58.0 +1000
@@ -13,7 +13,7 @@
 # methods/makefile - FIXME
 LIBRARY=apt-pkg
 LIBEXT=$(GLIBC_VER)$(LIBSTDCPP_VER)
-MAJOR=4.6
+MAJOR=4.7
 MINOR=0
 SLIBS=$(PTHREADLIB) $(INTLLIBS) -lutil
 APT_DOMAIN:=libapt-pkg$(MAJOR)
diff -urb apt-0.7.19/methods/http.cc apt-0.7.19aj1/methods/http.cc
--- apt-0.7.19/methods/http.cc	2008-11-24 19:32:23.0 +1000
+++ apt-0.7.19aj1/methods/http.cc	2008-12-21 22:25:28.0 +1000
@@ -39,6 +39,7 @@
 #include errno.h
 #include string.h
 #include iostream
+#include map
 #include apti18n.h
 
 // Internet stuff
@@ -57,6 +58,7 @@
 time_t HttpMethod::FailTime = 0;
 unsigned long PipelineDepth = 10;
 unsigned long TimeOut = 120;
+bool AllowRedirect = false;
 bool Debug = false;
 URI Proxy;
 
@@ -628,6 +630,12 @@
   return true;
}
 
+   if (stringcasecmp(Tag,Location:) == 0)
+   {
+  Location = Val;
+  return true;
+   }
+
return true;
 }
 	/*}}}*/
@@ -900,7 +908,9 @@
  1 - IMS hit
  3 - Unrecoverable error 
  4 - Error with error content page
- 5 - 

Bug#509337: apt copyright includes obsolete qt linking permission

[Anthony Towns]

Package: apt
Version: 0.7.19, 0.7.20~exp3
Severity: normal

From /usr/share/doc/apt/copyright:

] In addition, prior to November 15th, 2000, apt may be distributed under
] terms identical to the above with the following addition:
] 
] Works using apt may link against the GUI library libqt, copyright by
] Troll Tech AS, Norway, provided that:
] ...
]
] On and after November 15th, 2000, the above additional terms lose all
] force, and apt will be licensed only under the terms of the GNU General
] Public License, version 2.0 or later.

Seems like all this could reasonably be dropped...

Cheers,
aj

-- System Information:
Debian Release: lenny
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#503814: foo2zjs

[Anthony Towns]

On Fri, Oct 31, 2008 at 03:52:31PM +0100, Andreas Barth wrote:
 1. Currently, the submitter claims that the bug is serious, the
 maintainer don't think so, and there is no decision by the release team
 yet. So the current state of the bug isn't serious, but important. 

ie, the views (on serious severity) are prioritised as:

- submitter's (default)
- maintainer's (can override submitter, and in this case does)
- release team's (can override maintainer and submitter)
- tech-ctte (can override all three of the above)
- general resolution (likewise)

 2.  As per constitution, we (the tech ctte) only makes decision as last
 resort. So currently, the next step would be for anyone who disagrees
 with this bug not being release critical to ask the release team to
 review the decision and maybe overrule it.

I'm not sure I'd want the release team to be able to stop the tech-ctte
from being involved simply by not making a decision, so I'm not sure I
agree with this precisely. But in the general case, yes, I'd rather see
the release team making the call on this.

 tech ctte members, any opinion from you on that?

Basically, +1.

On a technical level, it seems to me there's two aspects:

   (1) can a package in main include a script that gets stuff from some
   random website really be considered DFSG-free/policy-compliant?

   (2) should we make sure that the stuff on the random website is also
   available from somewhere in Debian, in case the random website gets
   shut down, etc?

(1) seems to be resolved as per Andi's comments, but I kind-of think
(2) is actually the more important issue, and that the stuff getting
downloaded should probably be packaged for non-free and possibly volatile,
in order to remove the external dependency. The package in main would
then get a Suggests: foo2zjs-nonfree-drivers, and if the script gets
moved to contrib, that could then become Suggests: foo2zjs-nf-d |
foo2zj-nf-d-getter-script. That assumes someones willing to do the
legwork of packaging the drivers, of course, which might require
negotiating permission to redistribute them from whoever owns them.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#428084: Announce of the upcoming NMU for the ifupdown package

[Anthony Towns]

On Mon, Apr 28, 2008 at 10:26:32AM +0200, Christian Perrier wrote:
 I announced the intent to build and possibly upload a non-maintainer upload
 for this package in order to fix this long-time pending localization
 bug as well as all other pending translations.

Ack, do it. AFAICS your patch leaves the upgrade-from-0.5.x.pl script
in place; please leave it that way.

Cheers,
aj




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#474651: Fwd: Re: Bug#474651: debootstrap: W: Failure trying to run: chroot /sid

[Anthony Towns]

reopen 474651
thanks

On Fri, Apr 18, 2008 at 02:06:48PM +0200, Peter Walser wrote:
 It is reproducable and it's just whith:
 $ fakeroot -s fakechroot.save \
 fakechroot /usr/sbin/debootstrap --variant=fakechroot \
 sid /sid http://ftp.ch.debian.org/debian/

Turns out it's reproducible with

] fakeroot /usr/sbin/debootstrap --foreign sid sid $MIRROR
] echo $?

or

] sudo /usr/sbin/debootstrap --foreign sid sid $MIRROR
] echo $?

or

] sudo /usr/sbin/debootstrap sid sid $MIRROR

too; the problem being that libc6 and binutils both reference /usr/lib64,
but libc6 thinks it should be a symlink and binutils thinks it should be
a directory containing a file. After tar unpacks a directory and file from
binutils; it complains when it tries unpacking the symlink from libc6.

Cheers,
aj




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#474553: jetring-gen support for updating keys

[Anthony Towns]

On Mon, Apr 07, 2008 at 05:19:15PM -0400, Joey Hess wrote:
  and introduces a Key-Info: section to make it easier to find a changeset
  just by grepping.
 Some overlap with d-m keycheck info, though I don't think I've ever
 grepped that.

Opaque files just bother me.

 If you have a use case that involves grepping them all, wouldn't it be
 better (though perhaps not easy to implement) for jetring-accept to add
 the field, so it's consistently added to all changesets?

Hrm. We'd get that behaviour if jetring-accept worked something like:

jetring-build -I $KEYRING $DIR
jetring-review $KEYRING $CHANGESET $CHANGESET
jetring-accept $DIR $CHANGESET

I think.

 OTOH, jetring-accept will already suffix a changeset with
 .$x if necessary to make it unique.

Oh, that sounds sufficient then.

  (I wonder a bit why we went with a signed index instead of having patches
  applied in filename order, and all prefixed by a date.)
 Mostly, I think, so that it can be signed.

Hrm, we could equally well have just signed the output of

  find $DIR -maxdepth 1 -mindepth 1 | 
sed 's,^.*/,,' | 
grep '^[a-zA-Z0-9-.]*$' |
sort

too, though the only thing that buys us is having the index implicit in
the directory.

Heh, maybe what we really should be doing is treating the changesets as a
linked list:

  add-foo:
-BEGIN PGP SIGNED MESSAGE-
Action: import
Data:
blah
-BEGIN PGP SIGNATURE-
...
-END PGP SIGNATURE-

  add-bar:
-BEGIN PGP SIGNED MESSAGE-
Previous-Changeset: add-foo
Action: import
Data:
blahblah
-BEGIN PGP SIGNATURE-
...
-END PGP SIGNATURE-

  LAST-CHANGESET
add-bar

then you have ordering implied by the changesets themselves, so you get
direct tracability for every changeset, and an authenticated ordering
just falls out.

Which means you don't have to sign two files when adding a changeset, and 
you never have to reconstruct anything from the VCS history -- so rather than
having to find the commit that included the add-evilcracker changeset,
and then see who signed index.gpg, you just have too look at who signed
that changeset in the current tree.

Which is to say you could implement jetring-blame without having to
integrate it with a VCS.

Inserting at the end is trivial (add a new signed changeset, and update
LAST-CHANGESET), removing from the middle is easy-ish (replace the old
changeset with a new, empty one), and changing stuff in the middle is
possible but annoying, which seems entirely reasonable.

You don't strictly need LAST-CHANGESET, you could just do a tsort on all
the changesets, and check for:

loops (x Prev-Changeset: y, y Prev-Changeset: x)
branches (x Prev-Changeset: z, y Prev-Changeset: z)
multiple heads (nothing has Prev-Changeset: x _or_ Prev-Changeset: y)

Actually, that's trivial -- you just need to check:

- the number of files referenced as prev-changesets is
  one less than the number of files you have
- no file is referenced twice
- all referenced files exist

FWIW, attached is something that'll take a directory of changesets
(.) and either die with an error if there's a problem, or print out
the order they should be applied in.

OTOH, for jetring-gen, you'd have to sign every changeset individually,
rather than just do one signature. Maybe in that case it'd make sense
to give it an option to dump a single changeset for all the updates
(though keeping additions/removals in distinct changesets, I guess).

Hrm, that might not be entirely as whacky as I first thought...

Cheers,
aj



signature.asc
Description: Digital signature

Bug#474553: jetring-gen support for updating keys

[Anthony Towns]

On Tue, Apr 08, 2008 at 01:45:30PM +1000, Anthony Towns wrote:
 FWIW, attached is something that'll take a directory of changesets
 (.) and either die with an error if there's a problem, or print out
 the order they should be applied in.

*sigh*

Cheers,
aj


#!/usr/bin/perl -w

use strict;

my $dir = .;

my $head = undef;
my %next = ();
my %prev = ();

opendir DIR, $dir or die can't opendir $dir;
while (my $chset = readdir DIR) {
next if ($chset eq . || $chset eq ..);

my $path = $dir/$chset;
next if (! -r $path);

open CHSET,  $path or die can't open $path;
while(CHSET) {
chomp;
next unless /^Prev-Changeset:\s*(\S.*)$/;

my $p = $1;
$prev{$chset} = $p;
if (defined $next{$p}) {
die branch: $p - $chset and $next{$p};
}
$next{$p} = $chset;
last;
}
if (not defined $prev{$chset}) {
if (defined $head) {
die multipled heads: $chset, $head\n;
}
$head = $chset;
}
close CHSET;
}

my @res = ($head);
for (my $c = $head; defined $next{$c}; $c = $next{$c}) {
push @res, $next{$c};
}
if (scalar(@res) lt scalar(keys %prev)) {
die some changesets in a loop;
}
print join(,, @res).\n;



signature.asc
Description: Digital signature

Bug#474553: jetring-gen support for updating keys

[Anthony Towns]

On Tue, Apr 08, 2008 at 01:45:30PM +1000, Anthony Towns wrote:
   add-bar:
   Previous-Changeset: add-foo
 
 Inserting at the end is trivial (add a new signed changeset, and update
 LAST-CHANGESET), removing from the middle is easy-ish (replace the old
 changeset with a new, empty one), and changing stuff in the middle is
 possible but annoying, which seems entirely reasonable.

OTOH, in order to merge two trees, you'd need to go from:

  d---e
 /
a---b---c

and

a---b---c
 \
  x---y
to

  d---e
 / \
a---b---c   \
 \
  x---y

(requiring resigning x) or

  d---e
 / \
a---b---c   M
 \ /
  x---y

with c having two descendents, and M having two parents; and possibly
being able to have M as a no-op otherwise, so you can do merges without
having to have an additional changeset. You'd also have to pull out a
distinct ordering from that (presumably based on the order of the children
in M -- an ordered, depth-first descent would probably be all it'd take).

That assumes merging is actually something we care about, which it might
not be.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#474553: jetring-gen support for updating keys

[Anthony Towns]

Package: jetring
Version: 0.12
Severity: wishlist
Tags: patch

The following changes Action: import to Action: import
--import-options=merge-only for patches that just modify a key, and
introduces a Key-Info: section to make it easier to find a changeset
just by grepping.

For checking keyservers for updated keyrings, this means we then say:

  # save current keyring
  cp $KEYRING ${KEYRING}.old

  # get updated keys safely
  gpg --no-default-keyring --keyring $KEYRING --list-keys --with-colons | 
grep ^pub: | cut -d: -f5 | sort | 
xargs -n 15 gpg --no-default-keyring --keyring $KEYRING \
--keyserver-options honor-keyserver-url=no \
--import-options=merge-only --recv-keys

  # split out the changes
  jetring-gen ${KEYRING}.old $KEYRING

  # commit them
  for x in modify-*; do
[ -e $x ] || continue; # maybe there weren't any changes
y=$(date +%Y%m%d)-$x
mv $x $y
jetring-accept $JETDIR $y
  done

modify-0123456789ABCDEF will get repeated everytime new signatures
get added, so prefixing by date seems a reasonable way of avoiding it.

(I wonder a bit why we went with a signed index instead of having patches
applied in filename order, and all prefixed by a date.)

I wonder if there should be a jetring command that just does the above?
jetring-update-from-net or whatever.

--- jetring-gen 2007-12-10 03:04:01.0 +1000
+++ jetring-gen 2008-04-06 23:31:57.0 +1000
@@ -29,17 +29,20 @@
if (/-pub:/) {
genchangeset(delete-$fields[4],
delete-key $fields[4],
-   y);
+   y,
+   getlistkey($fields[4], $old));
}
elsif (/\+pub:/) {
genchangeset(add-$fields[4],
import,
-   getkey($fields[4]));
+   getkey($fields[4]),
+   getlistkey($fields[4]));
}
elsif (/ pub/) {
genchangeset(modify-$fields[4],
-   import,
-   getkey($fields[4]));
+   import --import-options=merge-only,
+   getkey($fields[4]),
+   getlistkey($fields[4]));
}
 }
 close DIFF;
@@ -48,6 +51,12 @@
my $fn=shift;
my $action=shift;
my $data=shift;
+   my $desc=shift;
+
+   chomp($desc);
+   $desc=~s/^$/./mg;
+   $desc=~s/^/  /mg;
+   chomp($desc);
 
if ($data=~/\n/) {
$data=~s/^/  /mg;
@@ -59,6 +68,8 @@
 Comment: $comment
 Date: $date
 Action: $action
+Key-Info:
+$desc
 Data: $data
 EOF
close OUT;
@@ -66,6 +77,13 @@
print $fn\n;
 }
 
+sub getlistkey {
+   my $id=shift;
+   my $kr=shift || $new;
+   my $listkey=`gpg --no-auto-check-trustdb --option /dev/null 
--no-default-keyring --keyring $kr --list-keys $id`;
+   return $listkey;
+}
+
 sub getkey {
my $id=shift;
my $key=`gpg --no-auto-check-trustdb --options /dev/null 
--no-default-keyring --keyring $new -a --export $id`;



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#474552: jetring: debian/copyright incomplete?

[Anthony Towns]

Package: jetring
Version: 0.12
Severity: normal

Hey Joey,

There's no pointer to the jetring source repo in jetring's
debian/copyright. Also,

] $ head -n3 /usr/share/doc/jetring/copyright 
] jetring was written by Joey Hess [EMAIL PROTECTED].
] 
] Copyright 2007 Joey Hess

] $ head -n4 /usr/bin/jetring-diff 
] #!/usr/bin/perl -w
] 
] # Copyright (c) 2007 Anthony Towns
] # GNU GPL; v2 or later

Cheers,
aj



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#472377: scribble: uses obsolete version specification in conflicts

[Anthony Towns]

Package: scribble
Version: 1.10-2

scribble specifies:

] Replaces: scrabble ( 1.10)
] Conflicts: scrabble ( 1.10)

These should be =, as per policy 7.1:

] The relations allowed are `', `=', `=', `=' and `' for strictly
] earlier, earlier or equal, exactly equal, later or equal and strictly
] later, respectively.  The deprecated forms `' and `' were used to
] mean earlier/later or equal, rather than strictly earlier/later, so they
] should not appear in new packages (though `dpkg' still supports them).

Cheers,
aj




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#469148: On fixed, found, reopen, notfixed, notfound and unversioned -done

[Anthony Towns]

On Thu, Mar 06, 2008 at 02:56:39PM -0800, Don Armstrong wrote:
  It's good to have a *command* for I'm the maintainer of this
  package (or the submitter of this bug), and this bug is DONE., but
  using the done field for that just doesn't work right anymore.
 I think that it can, and should, actually. In the cases where there's
 a found version that is greater than the fixed version, the bug is no
 longer done, and should be shown as such.

Right, that's exactly what I'm saying: from the BTS's point-of-view done
status should be determined based on the versions, not whether an email
address is in some field.

 I already do ignore versions entirely in pseudopackages. 

Well, in that case, maybe we should just make them disjoint:
pseudopackages don't do versions ever; versioned packages do versions
always. The done field is canonical for pseudopackages, and purely
advisory for normal packages.

For pseudopackages the only states are is currently a bug and is not
currently a bug (open and done, respectively); for versioned packages,
the states are was found in version X or earlier, was fixed in version
X or earlier and was not relevant for version X.

For pseudopackages we ignore dist=, and for versioned packages we default
dist=unstable if dist=/version= is unspecified.

  The logic's still pretty complicated then.
  With the matrix of done values being:

   pseudopkg, no done-field   OPEN
   pseudopkg, done-field  DONE

   cmp_ver=found | cmp_ver=fixed | cmp_ver=other
   versionedpkg, done-field   OPEN   |   DONE|  NOT-PRESENT
   versionedpkg, no done-fieldOPEN   |?  |  NOT-PRESENT

with the only questionable behaviour being a bug with some fixed-versions
but no done-field set (which we should disallow afaics); and you mark
notabugs by removing all the found-versions so it's NOT-PRESENT anywhere,
and setting done.

In that case, the behaviour would be:

-done: set fixed version, done field
found: set found version
notfound: remove found version
fixed: set fixed version, if done not set, set based on From:
notfixed: remove fixed version (don't unset done)

expire: if done is set, and bug is not OPEN in relevant dists, expire

 !found, fix | found, !fix | both| neither
no query-ver, no done-field  DONE| OPEN|  ?  | OPEN
no query-ver, done-field DONE| OPEN ?  | DONE| DONE
^  
query-ver, no done-field cmp_ver | cmp_ver | cmp_ver | OPEN
query-ver, done-fieldcmp_ver | cmp_ver | cmp_ver | DONE
^^^
 These are the ones I suggest we change; currently we mark these as
 done; I suggest that we mark them as done or absent/found.

For the latter one you have to do the version comparison, because you might
have a version earlier than found.

The differences between the two tables above are:

   !found, fix | found, !fix | both| neither
  no query-ver, no done-field  OPEN| | OPEN| 
  no query-ver, done-field | DONE| | 
  query-ver, no done-field | | | cmp_ver 
  query-ver, done-field| | | cmp_ver

(because query-ver becomes equivalent to whether it's a pseudopackage
or not)

This also gives you support for falling back to non-vt'ed BTSes that
behave the same way debbugs used to: it just means everything's a
pseudopackage.

  and had a bug with found-in: 1.0-1; then adding fixed-in: 1.0-1etch1
  would close the bug in the no-query-ver view, even though it's still
  open in unstable. That's probably confusing, and probably undesirable.
 If setting fixed sets the -done field, yes.

You could alternatively set it up so the fixed control@ gives an error
if the done-field isn't already set (by a mail to -done, eg).

  Having everything be version-tracked including dist-less queries and
  pseudopackages changes that to just always using cmp_ver, and
  removes the done-field from the logic entirely.
 We'd still have the done field in the logic because of the cases where
 there's no versions at all. 

We only *need* that for pseudopackages though. For versioned packages, we
can require a version to be included.

 What I think we should get rid of are the
 dist-less queries, and perhaps default to dist=unstable;arch=source or
 some equivalent for dist-less queries.

Yup.

  The constraints seem to be:
 - submitter must get a mail when a bug is deemed closed, even
   if that's only by manipulation of fixed-in etc; it mustn't be
   possible to go from the bug being open to being archived
   without mailing the submitter
 Right now, we require done to be set before we archive, so they'll get
 a mail on 

Bug#469148: On fixed, found, reopen, notfixed, notfound and unversioned -done

[Anthony Towns]

On Tue, Mar 04, 2008 at 12:28:51AM -0800, Don Armstrong wrote:
 On Tue, 04 Mar 2008, Anthony Towns wrote:
  Well, ultimately, the problem's that done doesn't really mean all that
  much anymore -- we've got:
 -done basically means I'm the maintainer of this package, and I've
 done what I needed to do to this bug.

Except it doesn't mean that anymore as soon as debbugs receives a
command like:

found $BUG $UNSTABLE_VER

or

notfixed $BUG $UNSTABLE_VER

It's good to have a *command* for I'm the maintainer of this package
(or the submitter of this bug), and this bug is DONE., but using the
done field for that just doesn't work right anymore.

 A much simpler method would be to disallow unversioned -done
 if there are found versions, 

How about disallowing (or ignoring) versions entirely in pseudopackages?

 and mark bugs that have found versions
 but no fixed versions as open even if they have been -done'd.

The logic's still pretty complicated then.

We've got a few states:

- do we have a version from the query, or not?
- is the done-field set?
- is found-in set?
- is fixed-in set?

With the matrix of done values being:

   !found, fix | found, !fix | both| neither
  no query-ver, no done-field  DONE| OPEN|  ?  | OPEN
  no query-ver, done-field DONE| OPEN ?  | DONE| DONE
  query-ver, no done-field cmp_ver | cmp_ver | cmp_ver | OPEN
  query-ver, done-fieldcmp_ver | cmp_ver | cmp_ver | DONE

AFAICS, it's the special cases that bite; whether on implementation or usage.
For example, by the above, if you had:

stable: 1.0-1 - 1.0-1etch1
unstable: 1.0-1 - 1.0-2

and had a bug with found-in: 1.0-1; then adding fixed-in: 1.0-1etch1
would close the bug in the no-query-ver view, even though it's still
open in unstable. That's probably confusing, and probably undesirable.

Having everything be version-tracked including dist-less queries and
pseudopackages changes that to just always using cmp_ver, and removes
the done-field from the logic entirely.

 This way notfixed would do the right thing in making the bug appear 
 to be open, but would remain commutative.  

Commutativity's pretty easy -- it just means that if you make notfixed
or found make a previously-closed bug open again; then fixed or
notfound have to make a previously-open bug closed.

That doesn't have to involve changing the done field at all -- ie,
the commands can still just manipulate the fixed/found fields in the
.summary; but if so, the CGIs (and archiving) have to take a different
tack working out what closed means, at least in some cases.

 We could then additionally deprecate reopen in favor of 
 found+submitter and finish retiring close as well.  

That sounds good.

The constraints seem to be:

   - submitter must get a mail when a bug is deemed closed, even if that's
 only by manipulation of fixed-in etc; it mustn't be possible to go from
 the bug being open to being archived without mailing the submitter

   - it must be easy to close bugs on pseudopackages (ie, mail to
 -done; no futzing around with control@)

   - there should be an easy way to deal with notabugs so they can
 be closed without ending up treated as open against any version of
 the package

   - the simpler the better

I would love to see the non-version-tracking view disappear at this point;
but afaics that needs us to come up with a pseudoversioning scheme for
pseudopackages.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#469148: closed by Don Armstrong [EMAIL PROTECTED] (Re: Bug#469148: bugs.debian.org: bug marked as resolved when it is not in any version)

[Anthony Towns]

On Mon, Mar 03, 2008 at 02:51:10PM -0800, Don Armstrong wrote:
 On Mon, 03 Mar 2008, Colin Watson wrote:
  Yes, I know - I meant conceptually rather than in detail. notfixed
  should not leave the bug in a fixed/done-type state.
 The problem is that giving it side effects (reopening the bug) means
 that it's no longer associative.

(commutative is the word you're looking for -- associative is (a+b)+c
= a+(b+c))

 That seems to violate (at least for me) the principle of least
 surprise. 

Having reopen NNN, found NNN VER and notfixed NNN VER be different
probably already violates the principle of least surprise.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#469148: closed by Don Armstrong [EMAIL PROTECTED] (Re: Bug#469148: bugs.debian.org: bug marked as resolved when it is not in any version)

[Anthony Towns]

On Mon, Mar 03, 2008 at 01:55:29PM -0800, Don Armstrong wrote:
 On Mon, 03 Mar 2008, Colin Watson wrote:
  On Mon, Mar 03, 2008 at 10:01:00PM +0100, Steinar H. Gunderson wrote:
   On Mon, Mar 03, 2008 at 08:57:25PM +, Colin Watson wrote:
Blink. Is that a typo? notfixed should be, if anything, the opposite of
-done. If what you say is the case then I think we (or indeed probably
I) buggered up the semantics rather badly.
   I guess what he was trying to say, was that a versioned close + notfixed 
   is
   the same as an unversioned close. (notfixed removes the version, but does 
   not
   change the status of the bug.)
  Ah. For the record I am inclined to think that is at best unintuitive
  and probably a bug.
 We need a command that does what notfixed does. 

Well, ultimately, the problem's that done doesn't really mean all that
much anymore -- we've got:

real bugs that applied in version between X and Y
real bugs that applied in versions = X
real bugs that can't be associated with a version because they
apply to pseudopackages, or to packages not in the archive
things that should never have been reported as bugs

We could introduce a pseudoversion for pseudopackages, eg make it the day
in UTC formatted as .MM.DD -- then we can require a Version to always
be present, and deal with things as:

filed/closed bug against a real package, versions should be
as expected

filed against a pseudopackage -- version should be the date the
bug first appeared

closed bug against a pseudopackage -- version should be the date
the bug was fixed

version of a pseudopackage in stable/testing/unstable == today's
date; pseudochangelog for pseudopackages that gives it a daily
history

closing a bug that should never have existed: just mark it
notfound in any version and not fixed in any version (or mark
it fixedin every version that it's foundin)

The done field could then either be dropped entirely, or left as a comment
that's only displayed for bugs that're determined to be resolved purely
by looking at versions.

For a version-free view (ie without dist=unstable, etc), you might be
able to determine open/resolved based on based on whether max(found-in)
 max(fixed-in). You'd need to have something, to avoid relying on the
done field.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#458939: allow search engines to index http://bugs.debian.org

[Anthony Towns]

On Thu, Jan 03, 2008 at 01:07:15PM -0800, Don Armstrong wrote:
 There are already mirrors which allow indexing, and you can use the
 BTS's own search engine which is far superior to gooogle [...]

Uh, you're kidding right? The BTS's own search engine won't turn up hits
outside the BTS, as a trivial example...

On Fri, Jan 04, 2008 at 08:49:08AM +0100, Raphael Hertzog wrote:
 Most of the content is generated dynamically nowadays and this file has
 been put in place because web crawlers have been known to severly hit the
 machine hosting the BTS...

AFAIK it was put in place when we first went dynamic, when bugs.d.o was
on master and horribly overloaded (so much so that updating the static
pages was taking over half a day).

It hasn't been removed ultimately because the CGIs provide too many
similar urls that shouldn't all be indexed; it's definitely a bug that
we don't provide some URLs that can be indexed.

Hacking around that in robots.txt seems tricky, as you can only reliably
specify Disallow: prefixes in robots.txt. Google supports * matches and
$ to match against end of string and Allow: fields, and at least *
seems somewhat common, so something like this could work:

Disallow: /*/   # exclude everything but the shortcuts
Allow: /cgi-bin/bugreport.cgi?bug=
Allow: /cgi-bin/pkgreport.cgi?pkg=*;dist=unstable$

That doesn't prevent bug=1234;reverse=yes and such, but I can't see a good
way of doing that.

I've set that up on rietz for Googlebot, we'll see if it works ok. I
don't think it's possible to make Disallow: /*/ be the default for
all User-Agents since * is an extension, but extending it to MSN and
Yahoo should be fine.

Getting smarturl.cgi properly done is still probably the real solution.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#458939: allow search engines to index http://bugs.debian.org

[Anthony Towns]

On Wed, Jan 09, 2008 at 05:58:34PM +1000, Anthony Towns wrote:
 Getting smarturl.cgi properly done is still probably the real solution.

Okay, so I've made smaturl.cgi work again; it was broken by:

   - Debbugs::CGI not accepting params from ARGV (smarturl.cgi changed
 to set QUERY_STRING)

   - Debbugs::CGI, pkgreport.cgi and version.cgi assuming the CGI's are in
 the current HTTP path (added /cgi-bin/)

I've made those changes on rietz directly; what's the procedure
for committing them? sudo -u debbugs -H bzr commit ? There was a
pre-existing change in pkgreport.cgi (adding a^ to the Go away
regexp) that also wasn't committed fwiw.

I think the best solution is to deal with URL naming in the long term
as follows:

   bugs.debian.org/123456  (bug report)
   bugs.debian.org/123456/mbox (full bug mbox format)
   bugs.debian.org/123456/10   (individual message)
   bugs.debian.org/123456/10/mbox  (individual message mbox format)
   bugs.debian.org/123456/10/att/3 (attachment to a message)

   bugs.debian.org/source/dpkg (bugs against dpkg in unstable)
   bugs.debian.org/package/dpkg

   bugs.debian.org/source/dpkg/1.14.14   (bugs against dpkg 1.14.14)
   bugs.debian.org/package/dpkg/1.14.14

   bugs.debian.org/usertag/[EMAIL PROTECTED]
   bugs.debian.org/usertag/[EMAIL PROTECTED]/rc-arm

   bugs.debian.org/maint/[EMAIL PROTECTED]
   bugs.debian.org/submitter/[EMAIL PROTECTED]
   bugs.debian.org/severity/serious
   bugs.debian.org/tag/lenny-ignore

These should all accept settings like boring=yes, reverse=yes,
repeatmerged=no from cookies, but _shouldn't_ accept any parameters on
the URL. That is, these should be the default views everyone gets and
per-user configuration should be done with cookies.

Only when you want to look at a customised version of a particular
page (like show me this bugreport reversed) or more complicated
queries (show me bugs with these three tags set) should you hit
/cgi-bin/pkgreport.cgi URLs.

As such, internal links from bug pages back to package pages and so on
should simply use the smarturl urls above, and not worry about all the
parameter parsing.

At that point, we should make smarturl.cgi active, and only prevent bots
from indexing /cgi-bin afaics.

Does that sound reasonable?

Cheers,
aj



signature.asc
Description: Digital signature

Bug#458939: allow search engines to index http://bugs.debian.org

[Anthony Towns]

On Wed, Jan 09, 2008 at 12:54:32PM -0800, Don Armstrong wrote:
 On Wed, 09 Jan 2008, Anthony Towns wrote:
  Uh, you're kidding right? The BTS's own search engine won't turn up hits
  outside the BTS, as a trivial example...
 It's far superior to google for searching for results *in* the BTS.
 That's obviously the subtext of my statement.

Well, that's certainly true while google's directed to not index results
in the BTS; if that weren't the case Google would do a respectable
job. But the more common case (IME) is when you don't have a site:
restriction and you're happy to have external pages appear if they're
relevant (eg, related launchpad bugs, or discussion on lists that didn't
get Cc'ed to the bug, etc). Likewise, the BTS search engine can't take
into account external hints about which bugs are more likely to be
relevant, while Google and other web search engines can.

(In practice, with google barely indexing anything in the BTS yet; lookup
for bug#459818 by googling for `medium dhclient-script' works fine;
using hyperstraier on merkel takes ages and doesn't return any hits)

  Getting smarturl.cgi properly done is still probably the real solution.
 It's not clear that that's actually the right way forward, but it may
 be a solution.

It's certainly /a/ solution. What else is an option?

I think any solution should at least provide simple to access
pages for bug#, package and source with at most one subdirectory
(bugs.d.o/bug/123413, eg), and they should be dynamically generated,
which means you've got to have a CGI script determining what to display
based on pathnames. I'd call anything doing that smarturl, pretty much.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#458939: allow search engines to index http://bugs.debian.org

[Anthony Towns]

On Wed, Jan 09, 2008 at 05:58:34PM +1000, Anthony Towns wrote:
   Disallow: /*/   # exclude everything but the shortcuts
   Allow: /cgi-bin/bugreport.cgi?bug=
   Allow: /cgi-bin/pkgreport.cgi?pkg=*;dist=unstable$
 I've set that up on rietz for Googlebot, we'll see if it works ok. I
 don't think it's possible to make Disallow: /*/ be the default for
 all User-Agents since * is an extension, but extending it to MSN and
 Yahoo should be fine.

User-Agent: *
Disallow: /cgi-bin
Allow: /cgi-bin/bugreport.cgi?bug=
Allow: /cgi-bin/pkgreport.cgi?pkg=*;dist=unstable$

would probably work okay, actually.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#456918: one more patch for experimental ifupdown - restore hwaddress.

[Anthony Towns]

On Wed, Dec 19, 2007 at 08:51:08PM +0100, Andreas Henriksson wrote:
 Here's an additional patch on top of the previous in the series. It
 restores backwards compatability for the hwaddress option (and drops
 the new lladdress option that was invented for the new syntax).

Ah, I don't think I can accept that one; the philosophy is to keep the
ifupdown proper ignorant of what commands are actually used, and have
all the specific knowledge in the OS-specific appendix.

However, I don't see why the same thing can't be done with a hook; so
that you add a function to archlinux.c, like:

void cleanup_hwaddress_for_iproute(char **pparam) {
char *rest = *pparam; /* we're shrinking the text,
   * so no realloc needed */
 + char *space = strchr(rest, ' ');
 + 
 + if (space != NULL) {
 + *space = '\0';
 + if (strcasecmp(rest, ether) == 0 ||
 + strcasecmp(rest, ax25) == 0 ||
 + strcasecmp(rest, ARCnet) == 0 ||
 + strcasecmp(rest, netrom) == 0)
 + {
 + /* found deprecated class attribute */
 + memmove(rest, space+1, strlen(space+1)+1);
 + }
 + else
 + {
 + *space = ' ';
 + }
 + }
}

Add a note to inet methords something like:

method static
  description
This method may be used to define ethernet interfaces with statically
allocated IPv4 addresses.
  
  options
...

  conversion
hwaddress cleanup_hwaddress_for_iproute

  up
...
  down
...

Add a conversion field to struct method that points to an array of
{char *, void (*)(char **)} entries, terminated by {NULL,NULL}.

(Alternatively, and more flexibly, the function could be
void(*)(interface_defn *), which would allow a conversion function to
create a full dotted-quad netmask given an address like 192.168.1.2/24,
and also remove the /24 from the address itself)

Do the necessary magic in defn2c.pl to get the above translated into C code
that creates the appropriate array of conversions, and links it all.

At that point we're back to:

  convert [[post-up]] and [[pre-down]] aliases to [[up]] and [[down]]
  check for duplicate options
  add option

And basically want to add a convert option after adding the option
that does something like:

convert option=
{
/* assumes:
 * struct conversion { char *option; void(*fn)(char**); };
 * typedef struct conversion conversion;
 * and interfaces_defn has a conversion *conversion; field
 */
conversion *c;
variable *o = currif-option[n_options-1];
for (c = currif-method-conversions; c-option  c-fn; c++) {
if (strcmp(c-option, o-name) == 0) {
c-fn(o-value);
break;
}
}
}
@

Alternatively it might be better (and maybe simpler) to have one
conversion function per method and only call it when the interface_defn
has been completely read, which would mean just looping over all the
interfaces at the end of read_interfaces():

typedef void(*conversionfn)(variable **option, int *n_opt, int *max_opt);

update interface definitions where necessary=
for (currif = defn-ifaces; currif; currif = currif-next) {
if (currif-method-conversion) {
currif-method-conversion(
currif-option,
currif-n_options,
currif-max_options
);
}
}
@

That lets you generate fake parameters however you see fit, like
converting netmask 255.255.255.0 to a new option cidr 24, so that
you can then tell iproute %address%/%cidr%, which seems like the right
way to go to get non-Linux stuff working right too to me.

What do you think?

Cheers,
aj



signature.asc
Description: Digital signature

Bug#431891: status of DDTP and ftp mirror synchronization?

[Anthony Towns]

On Sat, Dec 15, 2007 at 10:23:50AM -0200, Felipe Augusto van de Wiel wrote:
   I finished working on the scripts that will generate the
 files, we add some tests during the package build to reduce the
 checks on the archive side. The package, .dsc and byhand-ddtp
 are here: http://people.debian.org/~faw/ddtp/

That should be a .changes file, not a .dsc file. You could use the
tag-overrides changes on merkel as an example; look in:

 /srv/ftp.debian.org/queue/done/tag-overrides_200712071325_all.changes

The byhand script only allows translations for main, not contrib/non-free.
That seems odd?

If the filename looks like Translations-xx_YY-blah it will pass through
without complaint. FNL=$(echo ${FN} | cut -d'-' f2-) would fix that.
Using ${FN%%-*} and ${FN#*-} rather than the echo/cut subshells would
work too.

Only extracting files that you've guaranteed are okay might be safer, ie:
(untested)

is_name_okay () {
  local f
  f=$1
  f=${f#./}# trime leading ./ if present
  c=${f%%/*}   # component should appear first
  if [ x$c != xmain -a x$c != xcontrib -a x$c != xnon-free ]
  then
return 1
  fi
  f=${f#*/}

  if [ x$f = x ]; then return 2; fi # directory name, ignore it

  # i18n/ should appear next
  if [ ${f#i18n/} = $f ]; then
return 1
  fi
  f=${f#*/}

  if [ x$f = x ]; then return 2; fi # directory name, ignore it

  case $f in
Translation-[a-z][a-z][a-z]_[A-Z][A-Z]) return 0 ;;
Translation-[a-z][a-z]_[A-Z][A-Z]) return 0 ;;
Translation-[a-z][a-z][a-z]) return 0 ;;
Translation-[a-z][a-z]) return 0 ;;
  esac

  return 1
}

tar tzf ${TBALL} | while read f; do
  if ! is_name_okay $f  [ $? -ne 2 ]; then
true
  else
echo Bad name in tarball: $f
exit 1
  fi
done

tar tzf ${TBALL} | while read f; do
  if is_name_okay $f;
tar -C ${TEMPDIR} -xzf ${TBALL} $f
  fi
done

There's no code to move from the TEMPDIR into the dists/ directory? Or
are you meaning for TEMPDIR to be replaced by the real dest?

Cheers,
aj



signature.asc
Description: Digital signature

Bug#456918: Please apply patchseries for ifupdown in experimental

[Anthony Towns]

On Tue, Dec 18, 2007 at 02:53:25PM +0100, Andreas Henriksson wrote:
 Here's a bunch of patches to improve ifupdown 0.7~alpha2 (the current version
 in experimental).

 +Depends: net-tools, iproute (= 20071016-1), [...]

iproute (20071016-1) unstable; urgency=low

  ...
  [ Alexander Wirt ]
  * Add Andreas Henriksson to uploaders
  * Support dotted-quad netmasks in iproute (Closes: #357172) (Cherry picked
from upstream)

That is so cheating!! :)

Cheers,
aj



signature.asc
Description: Digital signature

Bug#431891: status of DDTP and ftp mirror synchronization?

[Anthony Towns]

On Sat, Dec 15, 2007 at 10:23:50AM -0200, Felipe Augusto van de Wiel (faw) 
wrote:
 The package, .dsc and byhand-ddtp
 are here: http://people.debian.org/~faw/ddtp/

(I haven't looked at this yet)

   Some doubts appear in the process, while writing the byhand
 I realize that you (or other ftpmaster) probably would need to adjust
 the necessary bits like paths and make sure that 'rm -rf' do not
 erase the entire archive.

Yup.

 We tried to check the consistence of the
 tarball and also the names, we plan to add other checks, and I hope
 it would be not too hard to update it in the future. We decide to
 take care of the enconding on our side, before the upload.

Good.

  * When we upload a new file removing a translation, how would we
remove that from the archive? byhand-ddtp should take care of that?

Uploading a set of translations for unstable will replace /all/
the translations for unstable, IMO. So if you have some new Turkish
translations you have to re-upload all the old Spanish translations
even if they haven't changed -- if you don't, we'll assume Spanish is
no longer a useful language and will drop translations for them.

So, yes, byhand-ddtp should take care of that, afaics.

  * We were concern about the version format system, but I think the
package is not going to appear on the archive,

That's largely correct. You can use a different package name / version
format if you have a better one. You can also upload a source and binary
package if you think that's useful (it is for debian-maintainers, eg).

  * Can we close bugs using debian/changelog like on a normal package?
Because we could close #431891 when this upload happens. :)

Yes, afaik that works fine.

   I also tried to implement the check of allowed uploads, but
 it seems that it needs to be done on archive side, I don't have the
 necessary understanding of projectb to implement that, but we would
 like to restrict who can upload the new translations.

Why would you want to do that? Tag uploads aren't restricted, eg, nor
are glibc uploads. Why are translations more special than either of those?

Cheers,
aj



signature.asc
Description: Digital signature

Bug#438179: Processed: destruction of round-robin functionality is fucking up our mirrors and making Debian suck for many people, hence fixing this is a release-critical wish

[Anthony Towns]

On Sun, Dec 16, 2007 at 03:45:37AM +0100, Josip Rodin wrote:
 After around 11 hours, we've had:
 * villa 4.29 MB/s
 * lobos 3.91 MB/s
 * steffani 14.86 MB/s

The rule9 prediction was:

A: 000.000.000.000-127.255.255.255: steffani, villa, lobos
B: 128.000.000.000-191.255.255.255: steffani
C: 192.000.000.000-212.211.131.255: villa, lobos
D: 212.211.132.000-212.211.132.127: villa
E: 212.211.132.128-212.211.132.255: lobos
F: 212.211.133.000-255.255.255.255: villa, lobos

Class A is pure round-robin, so we can ignore rule9 and assign 1/3 of its
traffic to each host.

The difference between villa and lobos is aiui due not only to the difference
between the D and E IP ranges, but also because the round-robin ordering of
the hosts is [lobos, steffani, villa], which means that since rule9 happens
after round-robin, you get orderings:

lobos, steffani, villa - [lobos, villa], steffani
steffani, villa, lobos - [villa, lobos], steffani
villa, lobos, steffani - [villa, lobos], steffani

A/3 + B   = 14.86 MB/s (steffani)
A/3 + 2C/3 + 2F/3 + D = 4.29 MB/s  (villa)
A/3 + C/3 + F/3 + E   = 3.91 MB/s  (lobos)

If you assumethe 212.211.132.0/24 traffic is negligible, and thus D = E = 0,
then subtracting lobos from villa gives:

   C/3 + F/3 = 4.29 MB/s - 3.91 MB/s = 0.38 MB/s

And thus filling in for lobos, we get A/3 = 3.91 MB/s - 0.38 MB/s =
3.53 MB/s.

Going back to steffani, that gives B = 14.86 MB/s - 3.53 MB/s = 11.33 MB/s,
and we thus have:

A = 10.59 MB/s
B = 11.33 MB/s
C + F =  1.14 MB/s
D =  0MB/s (by assumption)
E =  0MB/s (by assumption)

Which gives us 23.06 MB/s which was the total of what we started with, yay.

Note that 192.168.*.* addresses are in class C, so can only possibly make
up just under 5% of our traffic, which seems pretty negligible. 10.*.*.*
addresses are in class A, and 172.16... class addresses are in class B. I
would've thought there wouldn't be significantly more of those than for
the 192.168.*.* private addresses though.

Anyway, hope that's of some use.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#431891: status of DDTP and ftp mirror synchronization?

[Anthony Towns]

On Tue, Dec 11, 2007 at 05:50:52PM -0200, Felipe Augusto van de Wiel wrote:
  I'm still not entirely comfortable with having something outside of
  ftpmaster determine which translations should be in which suites,
  but that's something that'll probably need changes in apt-ftparchive
  to improve, and can be left 'til later.
   Ok, we would like to help with that, so we can have it in
 Lenny. Not sure exactly what is required and all the details, but
 would be great if we could cooperate to find the best solution to
 fulfill ftpmaster requirements.

Having it be upload the translations; have some archiving tool pull
out the relevant ones for stable/testing/unstable/experimental when
generating the Packages files would make me happier. That way updated
translations would migrate automatically to testing, and translations
of old descriptions wouldn't stick around in the archive. But I don't
think that's your problem.

  Any suggestions/scripts for validating the uploaded file would be
  good too.
   Are there examples/references for what is done/tested/checked
 by debian-maintainer and debtags?

d-m checks who can upload it, debtags checks that there aren't any invalid
entries in the tags files.

The scripts to validate and accept those are at:

   http://ftp-master.debian.org/bzr/ftpmaster-dak/scripts/debian/byhand-tag
   http://ftp-master.debian.org/bzr/ftpmaster-dak/scripts/debian/byhand-dm

Cheers,
aj


signature.asc
Description: Digital signature

Bug#431891: status of DDTP and ftp mirror synchronization?

[Anthony Towns]

On Mon, Dec 10, 2007 at 12:39:34AM -0200, Felipe Augusto van de Wiel (faw) 
wrote:
   If I'm not wrong, Anthony did the first upload of the
 Translation files, I'm cc:ing him, he probably can add more
 info on that.
   I think we could use the BYHAND to upload Translation
 files having some kind of DDTP Team, similar to debtags, but
 I would still like to hear from Anthony if a package upload
 would be better/worst than a rsync from someplace.

Yup; the autobyhand stuff we have now (used by debtags and
debian-maintainers) makes that easy to work with too.

I'm still not entirely comfortable with having something outside of
ftpmaster determine which translations should be in which suites,
but that's something that'll probably need changes in apt-ftparchive
to improve, and can be left 'til later.

So I'd say:

 - prepare a byhand upload
 - targetted at unstable (ie Distribution: unstable)
 - with a byhand file called ddtp-translations_2007.12.12-1_all.tar.gz
   or similar (different package name or version, eg)
 - section should be raw-translations
 - that tarball should contains:
  main/i18n/Translation-xx_XX
  contrib/i18n/Translation-xx_XX
  non-free/i18n/Translation-xx_XX
ie, translations for all components and languages, uncompressed

Workable?

If you can upload all that somewhere I can have a look at it and make
sure it's workable, rather than directly to the archive, that'd seem
like a good next step.

Any suggestions/scripts for validating the uploaded file would be
good too.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#454461: [D-m-team] Bug#454461: Bug#454461: debian-maintainers: package name does not match GR

[Anthony Towns]

severity 454461 wishlist
thanks

On Wed, Dec 05, 2007 at 05:27:37PM -0500, Joey Hess wrote:
 Martin Wuertele wrote:
  Please change the name to debian-maintainers-keyring to match the
  keyring namespace as used by the following packages:
  debian-keyring
  debian-archive-keyring
  debian-edu-archive-keyring
  debian-backports-keyring
 This minor inconsistency does not seem to me to be worth the pain of
 renaming the package, getting it through NEW, and probably changing dak
 to use the new name.

Changing dak is pretty trivial -- it's two lines in dak.conf, and a few
changes in the byhand-dm script that does the BYHAND processing. Change
another line in dak.conf and make a couple more changes to byhand-dm to
change the keyring name to debian-maintainers-keyring.gpg too, if desired.

I think this could be worthwhile. If desired, we could have
debian-maintainers stick around as a BTS pseudopackage so bugreports
didn't have to be moved.

Cheers,
aj




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#432564: Allow debian/rules to not be a makefile

[Anthony Towns]

On Tue, Jul 10, 2007 at 01:42:03PM -0700, Don Armstrong wrote:
 On Tue, 10 Jul 2007, Russ Allbery wrote:
  I also could have sworn that we recently tightened this requirement,
  but I can find no mention of that in changelog with some quick
  searches. Am I just imagining things?
 It was tightened about 2 or 3 years ago, iirc.

See the previous policy bugs for this issue, 88111 and 148941:

  It'll have happened during Manoj's incorporation of the packaging-manual
  into policy. See 72949. You'll notice you seconded it... :)

-- http://lists.debian.org/debian-policy/2001/03/msg00020.html 

While they might seem old enough to have been lost in history, they were
only actually closed in April last year...

 Regardless, even requiring debian/rules to be a makefile doesn't
 actually do much, because someone could do something like: 
 .DEFAULT: 
 debian/irule $@
 or whatever.

 People should be using make, but if they have a valid reason for doing
 something else, policy shouldn't get in the way.

And policy doesn't get in their way, because they can just do the above...

Benefits of using a makefile include (as discussed in the previous
bug reports),

  Also the debian/rules VAR=VALUE ... syntax is used by dpkg-buildpackage.

  debian/rules [variable=value ...] target [variable=value ...]
  exit: 0 if OK, non-0 otherwise
  debian/rules -q target
  exit: 2 if target cannot be built (doesn't exist), non-2 otherwise

It looks like there was more in the thread than the bug log.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#432564: Allow debian/rules to not be a makefile

[Anthony Towns]

On Thu, Dec 06, 2007 at 06:31:50PM +0100, Lo?c Minier wrote:
 On Thu, Dec 06, 2007, Anthony Towns wrote:
   Regardless, even requiring debian/rules to be a makefile doesn't
   actually do much, because someone could do something like: 
   .DEFAULT: 
   debian/irule $@
   or whatever.
   People should be using make, but if they have a valid reason for doing
   something else, policy shouldn't get in the way.
  And policy doesn't get in their way, because they can just do the above...
  Except it completely breaks any hope to benefit of this new Policy
  requirement:

Uh, this isn't a new policy requirement. It's been a MUST in policy for
years before you even applied to be a DD, eg.

  - passing -j2 might not be honored (Policy doesn't require it anyway)
  - querying the list of targets (to check for build-arch for example)
with a make flag wont work either (Policy doesn't require it anyway)

That's true -- but at least by specifically hacking your way out of
make land by something like the above, it's clear that it's your job to
make those features work. It'll partially honour those things too, eg
make -j2 binary-indep binary-all will run both targets at once.

As opposed to writing debian/rules as a #!/bin/sh script and then
wondering why people are invoking it with weird flags, multiple targets,
or variables as parameters instead of in the environment.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#441200: libconfig name clash

[Anthony Towns]

On Tue, Nov 27, 2007 at 09:25:02PM +, Ian Jackson wrote:
   [Option D:]
 (1) The existing libconfig in Debian may retain its name.

The maintainer of that package writes:

] Here's my argument(s). I'll try to keep it short:
] 
]  a) First come, first serve. I'm both the upstream author and maintainer and
] the library is used by several of my programs (some Debian packages, some
] not). I would prefer not to spend all the effort to rename just to please
] another crowd that didn't do the research to check for name clashes to
] begin with.
] 
] I think it is definitely unfair to expect me to change the name, even if
] my version is less popular.
]
]  b) I agree that the name is perhaps a bit generic and a more specific name
] would have been a better choice.

  -- http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;bug=441200

As far as (a) goes, first-come-first-serve is reasonable to some extent,
which is why the git package doesn't contain the version control system.
Userbase is relevant too though, and afaics, libconfig doesn't have one. There
are no build-depends on libconfig0-dev in unstable, nor any dependencies on
libconfig0 or libconfig0-dev in unstable.

The libconfig author (Abraham vd Merwe, [EMAIL PROTECTED]) is also the 
maintainer
of libdebug (builds libdebug0 and libdebug0-dev) and libabz (builds
libabz0 and libabz0-dev). All the packages that use libabz are maintained
by Abraham, and all the packages that use libdebug also use libabz.

Both libconfig and libdebug have been unchanged since sarge's
release. libabz has been updated since sarge, but was not released with
etch due to bug 385881.

The extent of changes to libconfig since its initial inclusion in the
archive in June 2002 have been (according to the changelog):
   * Ported to library to FreeBSD.
   * Changed copyright notices to reflect my new preferred email address.
   * Updated feature wishlist.
   * Added a more descriptive description in control file (Closes: #151535)
   * Changed libconfig0-dev section.
   * Updated package dependencies.
   * Changed sections.

The changes to libdebug have been somewhat more substantial though not
massively so. libdebug was also first uploaded in June 2002. libabz
was first uploaded in November 2002 (according to the ftpmaster logs,
libconfig and libdebug were both accepted from NEW by Randall Donald;
libabz by James Troup).

AFAICS neither libdebug nor libconfig have any reason to be packaged
separately from libabz. I don't think they should have been accepted
with such generic package names in the first place.

   [Options X and N:]
 (1) The existing libconfig in Debian must be renamed or removed.

I'd say the libdebug0/libconfig0 binary package names should be reserved
for the existing libconfig/libdebug packages to ensure there aren't
any dependency breakages, but their source packages should definitely
be removed.

   [Option N:]
 (2) The newer library may use the name libconfig.
   [Options X and D:]
 (2) The newer library may not use the name libconfig.

I'd be inclined towards a name more like libconfig-hyperrealm to
avoid being unnecessarily generic, while still making it easy for people
searching for `libconfig'.

The first page of google gives the following results:

#1 hyperrealm libconfig by Mark A. Lindner (the one under ITP)
#2 gnuwin32 port of R. Keene's libconfig
#3 freshmeat page for R. Keene's libconfig
#4 homepage for R. Keene's libconfig
#5 sourceforge page for Zhange Le (ejoy)'s libconfig, a C++ port 
   of KDE's KConfig
#6 WAND libconfig
#7  #8 packages.d.o pages for libconfig-ini-perl
#9 this thread (!)
#10 libconfig for the Amaya web browser

Five different projects just called libconfig in the top ten results
seems to me to indicate libconfig alone isn't a distinctive enough
package name for any of them.

I don't see any way in which a more descriptive package name would
cause a problem. Actually, I see the Debian packaging included in the
upstream source already calls it libconfigduo. Renaming the library
itself from libconfig.so.5 would be more of a problem since it'd mean
binary incompatabilities with other distros. But I don't think that's
actually an issue, as long as the libconfig packagers make sure they
don't have .so name conflicts.

   [All options:]
 (4) If after that no member of the TC objects to a name within 7
 days (counted from the maintainer's suggestion), then the
 package is entitled to the name.
 (5) Even if a TC member objects, if the TC does not pass
 a resolution vetoing the new name within 28 days, the
 package is likewise entitled to the new name.

If either maintainer *wants* to use a different package name, they should
just upload it to NEW, and the technical committee shouldn't even consider
being involved unless there's an actual dispute about that name. 

I don't support the technical committee being involved 

Bug#452011: Advocate DM: Asheesh Laroia

[Anthony Towns]

On Fri, Nov 23, 2007 at 06:56:03PM +0100, Benj. Mako Hill wrote:
 I advocate Asheesh Laroia as a DM. I've been reviewing and uploading
 Asheesh's packages for sometime now and he already done a great job for
 Debian already and will continue to do so a sa DM.

Could people advocating DMs (or potential DDs for that matter) go into
a bit more detail in their advocacy? 

From the above, or other advocacy messages like it, it's not clear what
a great job means -- is there something special he's done, or is
it that whatever he's working on is particularly important, or is he
remarkably consistent, or what? What's he actually done that's earnt
your trust? What makes him special compared to the other folks who're
helping Debian? What in particular about his work should people lurking
on this list be trying to emulate if they want to be a DM or a DD?

Cheers,
aj


signature.asc
Description: Digital signature

Bug#449542: equivs: Option to include file contents inline

[Anthony Towns]

Package: equivs
Followup-For: Bug #449542

Here's a follow-on patch that allows you to include extra files inline in
the control file, eg:

File: /etc/apt/sources.list.d/lovetts.list
 deb http://labradoodle/lovetts/ client/
 .
 deb http://labradoodle/debian etch main contrib non-free
 deb http://labradoodle/debian etch-proposed-updates main contrib non-free
 .
 deb http://security.debian.org/ etch/updates main contrib non-free

The leading space is trimmed, and lines just containing a dot are converted
to blank lines (and two dots - one dot, etc SMTP-style).

It also allows specifying a suite directly, and you can include maintainer
scripts ({pre,post}{inst,rm}) directly.

Patch follows.

Cheers,
aj

diff -Nurb equivs-2.0.7-0.0aj1/debian/changelog 
equivs-2.0.7-0.0aj3/debian/changelog
--- equivs-2.0.7-0.0aj1/debian/changelog2007-11-06 23:29:26.0 
+1000
+++ equivs-2.0.7-0.0aj3/debian/changelog2007-11-07 14:33:09.0 
+1000
@@ -1,3 +1,12 @@
+equivs (2.0.7-0.0aj3) unstable; urgency=low
+
+  * Add support for specifying suite.
+  * Add support for creating files from the control file, by specifying
+File: filename\n contents... fields. Includes support for in place
+specification of postinst and other maintainer scripts.
+
+ -- Anthony Towns [EMAIL PROTECTED]  Wed, 07 Nov 2007 14:32:33 +1000
+
 equivs (2.0.7-0.0aj1) unstable; urgency=low
 
   * An unuploaded NMU.
diff -Nurb equivs-2.0.7-0.0aj1/usr/bin/equivs-build 
equivs-2.0.7-0.0aj3/usr/bin/equivs-build
--- equivs-2.0.7-0.0aj1/usr/bin/equivs-build2007-11-06 23:38:55.0 
+1000
+++ equivs-2.0.7-0.0aj3/usr/bin/equivs-build2007-11-07 14:43:06.0 
+1000
@@ -61,28 +61,49 @@
 # Copy any additional files
 
 my @extra_files = split ,, $control{'Extra-Files'} || ;
-my %install_files= ();
+my %install_files = ();
 for (split \n, $control{'Files'} || ) {
-$install_files{$1} = $2 if m/^\s*(\S+)\s+(\S+)\s*$/;
+$install_files{$2} = $1 if m/^\s*(\S+)\s+(\S+)\s*$/;
+}
+my %create_files = ();
+for (@{$control{'File'} || []}) {
+  if (m/^\s*(\S+)\n(.*)$/s) {
+my ($f,$b) = ($1,$2);
+$b =~ s/^ //mg;
+$b =~ s/^[.]([.]*)$/$1/mg;
+$create_files{$f} = $b;
+  }
 }
 
 mkdir $builddir/install, 0755;
 open INSTALL, '', $builddir/debian/install or
   die Cannot open $builddir/debian/installfor writing: $!\n;
-foreach my $file (keys %install_files){
-  $file =~ s/ +//g;
-  my $target = $install_files{$file};
+foreach my $target (keys %install_files, keys %create_files) {
+  $target =~ s/ +//g;
   my $destination;
   my $cnt = 0;
+  if ($target =~ m/^(preinst|postinst|prerm|postrm)$/) {
+$destination = debian/$target;
+  } else {
   do {
   $destination = install/$cnt;
   mkdir $builddir/$destination unless -d $builddir/$destination;
   $destination .= / . basename($target);
   $cnt++;
   } while ( -e $builddir/$destination );
+print INSTALL $destination  . dirname($target) . \n;
+  }
+  if (defined $install_files{$target}) {
+my $file = $install_files{$target};
   copy $file, $builddir/$destination or
 die Cannot copy $file to $builddir/$destination: $!\n;
-  print INSTALL $destination  . dirname($target) . \n;
+  } else {
+open CREATE, , $builddir/$destination or
+  die Cannot create file $builddir/$destination: $!\n;
+print CREATE $create_files{$target};
+print CREATE \n;
+close CREATE;
+  } 
 }
 close INSTALL;
 
@@ -106,7 +127,6 @@
   die Cannot copy $script to $builddir/debian/$destination: $!\n;
 }
 
-
 write_control_file($builddir, \%control);
 
 if ($control{'Changelog'}) {
@@ -156,11 +176,12 @@
 
 sub read_control_file {
   my ($builddir, $control, $specific_arch, $file) = @_;
+  my @control = ();
   my $in;
 
   open($in, $builddir/debian/control.in) or
 die Cannot open control file: $!\n;
-  read_control_file_section($in, $control) or
+  read_control_file_section($in, [EMAIL PROTECTED]) or
 die error: empty control file\n;
   close $in;
 
@@ -174,6 +195,8 @@
 
   chomp($systemname = qx(hostname --fqdn));
 
+  %{$control} = @control;
+
   $control-{'Maintainer'} = $fullname [EMAIL PROTECTED];
 
   $control-{'Architecture'} = $specific_arch ? 'any' : 'all';
@@ -181,10 +204,24 @@
   open($in, $file) or
 die Cannot open control file $file: $!\n;
 
-  read_control_file_section($in, $control) or
+  @control = ();
+  read_control_file_section($in, [EMAIL PROTECTED]) or
 die error: empty control file\n;
   close $in;
 
+  for (my $i = 0; $i  $#control; $i += 2) {
+my $k = $control[$i];
+my $v = $control[$i+1];
+if ($k eq File) {
+  my $vv = [];
+  $vv = $control-{$k} if defined $control-{$k};
+  push @{$vv}, $v;
+  $control-{$k} = $vv;
+} else {
+  $control-{$k} = $v;
+}
+  }
+
   # Fix Source: entry
   $control-{'Source'} = $control-{'Package'};
 
@@ -201,17 +238,17 @@
   my ($cf,$v);
   while ($fh) {
 chomp;
-next if (m/^\s*$/ or m/^\s*#/);
+next if (m/^\s*$/ or m

Bug#449542: equivs: option to add additional files to a package

[Anthony Towns]

Package: equivs
Version: 2.0.7
Severity: wishlist

It'd be useful if equivs could add more files to the package than just
docs; my use case is adding some scripts into /usr/local/bin and an
/etc/cron.d file. Patch follows.

diff -urb equivs-2.0.7/debian/changelog equivs-2.0.7-0.0aj1/debian/changelog
--- equivs-2.0.7/debian/changelog   2006-02-28 18:01:18.0 +1000
+++ equivs-2.0.7-0.0aj1/debian/changelog2007-11-06 23:29:26.0 
+1000
@@ -1,3 +1,14 @@
+equivs (2.0.7-0.0aj1) unstable; urgency=low
+
+  * An unuploaded NMU.
+  * Added support for equivs packages to include actual files by
+specifying a Files: section that contains  src /path/to/dest
+lines.
+  * Update Standards-Version.
+  * Change debhelper to Build-Depends: for availability in clean target.
+
+ -- Anthony Towns [EMAIL PROTECTED]  Tue, 06 Nov 2007 22:41:29 +1000
+
 equivs (2.0.7) unstable; urgency=low
 
   * New maintainer.  (Closes: #350835)
diff -urb equivs-2.0.7/debian/control equivs-2.0.7-0.0aj1/debian/control
--- equivs-2.0.7/debian/control 2006-02-22 20:12:29.0 +1000
+++ equivs-2.0.7-0.0aj1/debian/control  2007-11-06 23:26:41.0 +1000
@@ -2,8 +2,8 @@
 Section: admin
 Priority: extra
 Maintainer: Peter Samuelson [EMAIL PROTECTED]
-Standards-Version: 3.6.2
-Build-Depends-Indep: debhelper (= 4)
+Standards-Version: 3.7.2
+Build-Depends: debhelper (= 4)
 
 Package: equivs
 Depends: perl, debhelper (= 4), dpkg-dev, devscripts, make, fakeroot
diff -urb equivs-2.0.7/usr/bin/equivs-build 
equivs-2.0.7-0.0aj1/usr/bin/equivs-build
--- equivs-2.0.7/usr/bin/equivs-build   2006-02-28 18:33:25.0 +1000
+++ equivs-2.0.7-0.0aj1/usr/bin/equivs-build2007-11-06 23:38:55.0 
+1000
@@ -61,6 +61,30 @@
 # Copy any additional files
 
 my @extra_files = split ,, $control{'Extra-Files'} || ;
+my %install_files= ();
+for (split \n, $control{'Files'} || ) {
+$install_files{$1} = $2 if m/^\s*(\S+)\s+(\S+)\s*$/;
+}
+
+mkdir $builddir/install, 0755;
+open INSTALL, '', $builddir/debian/install or
+  die Cannot open $builddir/debian/installfor writing: $!\n;
+foreach my $file (keys %install_files){
+  $file =~ s/ +//g;
+  my $target = $install_files{$file};
+  my $destination;
+  my $cnt = 0;
+  do {
+  $destination = install/$cnt;
+  mkdir $builddir/$destination unless -d $builddir/$destination;
+  $destination .= / . basename($target);
+  $cnt++;
+  } while ( -e $builddir/$destination );
+  copy $file, $builddir/$destination or
+die Cannot copy $file to $builddir/$destination: $!\n;
+  print INSTALL $destination  . dirname($target) . \n;
+}
+close INSTALL;
 
 mkdir $builddir/docs, 0755;
 open DOCS, '', $builddir/debian/docs or
diff -urb equivs-2.0.7/usr/share/equivs/template/debian/rules 
equivs-2.0.7-0.0aj1/usr/share/equivs/template/debian/rules
--- equivs-2.0.7/usr/share/equivs/template/debian/rules 2006-02-26 
21:46:51.0 +1000
+++ equivs-2.0.7-0.0aj1/usr/share/equivs/template/debian/rules  2007-11-06 
22:45:04.0 +1000
@@ -20,6 +20,7 @@
 binary-arch: install
dh_testdir
dh_testroot
+   dh_install
dh_installdocs
dh_installchangelogs
dh_compress



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#385623: Processed: reopening 385623

[Anthony Towns]

On Wed, Oct 17, 2007 at 06:28:23AM -0500, Steve Robbins wrote:
 I guess you're reopening of this bug is related to the UNACCEPT messages 
 that I got.
 I am still in the dark about that.
 Could you please let me know what is wrong and what I might need to do to 
 fix it?

There was some internal error in dak that ended up with your package
listed as accepted without an override; I've rejected it. Upload a
new version (or the same version) and let it get processed as NEW is
all you need to do.

Cheers,
aj


signature.asc
Description: Digital signature

Bug#360066: sudo fails to lookup hostname if it contains a hyphen (-)

[Anthony Towns]

tag 360066 unreproducible
thanks

I think this is actually due to a typo on the submitter's behalf:

 [EMAIL PROTECTED]:~$ sudo ps
 sudo: unable to lookup az-svr-01 via gethostbyname()
   PID TTY  TIME CMD
 12302 pts/000:00:00 ps

 If I change the hostname to azsrv01 sudo is silent about this:
 [EMAIL PROTECTED]:~$ sudo ps

Note that az-svr-01, azsrv01 and azsvr01 appear with variants of
svr and srv. If I try that myself, setting my hostname to az-svr-01
as indicated in the first prompt, and adding fqdn to the Defaults line
of my /etc/sudoers, I get the following results:

] # grep az- /etc/hosts
] 127.0.2.2   az-srv-01
] # sudo echo hi
] sudo: unable to lookup az-svr-01 via gethostbyname()
] hi

] # vi /etc/hosts
] # grep az- /etc/hosts
] 127.0.2.2   az-svr-01
] # sudo echo hi
] hi

Unless there's some other circumstances that make the submitter's machine
behave differently, I think this bug report can be closed.

HTH.

Cheers,
aj


signature.asc
Description: Digital signature

Bug#438179: getaddrinfo() behaviour

[Anthony Towns]

So here's my understanding of where we're at.

First, fact finding. Everything here should be able to be agreed by
everyone.

getaddrinfo() is a new interface that replaces gethostbyname(). It
hasn't different semantics that are intended to make it superior
to gethostbyname() and other functions, both in supporting IPv6 and
potentially other ways (such as resolving foo.bar.com:http differently
to foo.bar.com:https).

The most authoritative document for how getaddrinfo() will order
its results is RFC3484, which is a Proposed Standard on the Internet
Standards Track and seems to be being implemented by the major vendors
including glibc and Windows.

The sorting behaviour of getaddrinfo() cannot be relied on in today's
Internet, and it behaves differently in different implementations --
particularly due to RFC3484 having been proposed only after getaddrinfo()
had already been in wide use. Further, RFC3484 specifically indicates
that the sorting behaviour may be overridden if a better order can be
determined locally (see the last paragraph of section 6). Beyond that,
determining optimal address selection appears to be an open area of
research, and modifications to RFC3484 are still being discussed and
proposed both within and outside of the RFC context [0].

Note that RFC4294 (IPv6 Node Requirements) indicates RFC3484 MUST be
implemented, at least in the context of dealing with multiple addresses.

The sorting behaviour specified in RFC3484 has not been in common
use within the IPv4-based Internet. Instead, by far the most common
behaviour has been to use the ordering presented by the DNS, usually
simply selecting the first returned result. This behaviour has allowed
client address selection to be influenced by the DNS system and thus the
provider of the service being addressed, as described in RFC 1794. This
has most commonly been implemented by having the DNS servers provide a
cyclic, round-robin selection of addresses, such that each address is
returned as the first result equally often.

This is not the only method for load balancing, though it is one of the
simplest and most easily deployed on today's Internet. Others include
giving entirely different results to different people doing DNS queries
such as described in the supersparrow architecture [1], or doing dynamic
load balancing of http queries via the 302 redirect response.

The primary expectations for load balancing are generally one or more of:
- that load be evenly distributed across hosts
- that load be biassed to the closest/cheapest host for the client
- that load distribution be controllable by the service provider

The prefix-matching procedure described in RFC3484 does not meet those
expectations in a number of cases.

First, responsibility for destination selection is assumed entirely by the
client, so that the only choice the service provider has is to list or
not list a host. As such the service provider is faced with a choice of
providing only the best servers to the client, and not giving the client
the possibility to failover to other servers that might be available;
or having the client select a server entirely on its own judgement.

Second, when NAT is in use, a relatively small range of prefixes (10/8,
192.168/16, 172.16/12 and potentially 169.254/16) will have a high
number of users, thus leading to a bias towards servers matching those
prefixes. Further, those prefixes by design do not bear any relationship
to their actual position in the network, removing the possibility of
the bias being towards close/cheap servers.

Third, when round-robin DNS is in use, the ordering procedure described
by RFC3484 will not ensure that all servers with the best matching
prefix are given equal time as the first address returned, but instead
may be biassed towards one address depending on the exact ordering of
the addresses presented by the server [2].

Each of these objections apply to the mechanism described in RFC3484
whether applied to IPv4 or IPv6 addresses.

In addition, with particular regard to IPv4 addresses, in the present
day Internet:

- round-robin DNS is normal
- NAT is extremely common
- the average prefix length in BGP tables is 22 [3], and
  matches on shorter prefixes do not provide a strong correlation
  with locality

...

Is the above all reasonable and uncontroversial?

If so, conclusions that could potentially be drawn:

(a) Using prefix matching to select IPv4 addresses isn't useful
(b) Using prefix matching to select IPv4 addresses is harmful
(c) Using prefix matching to select IPv4 addresses is harmful enough to
be an RC issue for Debian
(d) Prefix matching IPv4 addresses provided the match is at least 22 bits
(or similar) might be reasonable
(e) Choosing the best address isn't a job for the client, and is better
left to the service provider and DNS system
(f) Given the existance of round-robin DNS, if prefix 

Bug#438179: glibc's getaddrinfo() sort order

[Anthony Towns]

On Sun, Sep 23, 2007 at 04:21:58AM -0700, Steve Langasek wrote:
 On Fri, Sep 21, 2007 at 01:07:49PM +1000, Anthony Towns wrote:
  On Thu, Sep 20, 2007 at 06:19:10PM -0700, Steve Langasek wrote:
   So do you have a use case where you think the behavior described in rule 9
   *is* desirable?
  Any application written assuming this behaviour, works correctly on
  Windows, Solaris, *BSD and glibc based systems in general, but not
  on Debian.
 So my argument here is that I don't believe there *are* any applications
 being written that assume this behavior; and that even if there were, such
 applications would either work just fine with the previous getaddrinfo()
 behavior, or be too pathological to live.

There's two aspects to RFC3484's behaviour: first that it creates a
much more stable ordering of its results than could have been expected
otherwise, and second it tries to make that ordering more optimal than
a random ordering would be wrt routing.

Stability is useful for any case where the servers hosting a particular
might be out of sync with each other; eg, if stability could be assumed
we'd have less errors where an invocation of apt-get update chooses one
mirror, and a subsequent apt-get upgrade chooses a different server
that hasn't finished syncing. Hopefully apt-get isn't considered
too pathological to live...

Better routing has less direct benefits to the client, probably limited
to slightly better ping times, with a small chance of somewhat cheaper
bandwidth costs. For the people providing the service, it lets you make
better assumptions as to load balancing -- you can expect the servers
based in a particular area to be serving a load proportional to the
number of users in that area, rather than having the load fairly evenly
distributed globally. Of course, there are other ways of doing this
that don't rely on how the client's resolver is implemented. Of course,
if the routing is worse, those turn into drawbacks instead of benefits.

 Instead, taken over the whole Internet rule 9 is statistically a
 pseudo-randomization relative to the *correct* sorting[1],

If that were the case it would be no worse than round-robin selection of
preferred address.

You can only take it over the whole Internet if you're assuming an equal
distribution across all IPs, which isn't valid for IPv4 (where there's
presumably a significant bias to private IPs), and presumably isn't valid
for any particular service, which will be heavily biassed to particular
IP ranges by correlation with location or language...

 One of the existing use cases that breaks is round-robin DNS.  

Round-robin DNS isn't broken; the expectation of (approximately) equal
load-distribution across all servers in a round-robin is broken.

 They might be reasons why RR DNS would be
 an acceptable sacrifice in favor of other beneficial features, but rule 9 as
 written offers *no* benefits in the general case!

Even without the possibility of applications like apt-get benefiting
from stability of results, I don't think we've done anywhere enough of
a review to be declaring that there aren't any benefits to rule 9.

 So I don't see that much weight should be given to whether other operating
 system vendors choose to comply with a rule which is, fundamentally,
 misguided and broken.

As far as I can see, for rule 9 to be fundamentally misguided and
broken, the concept of providing a stable answer, or a better than random
ordering, would need to be harmful. If they're beneficial, even in some
cases, then we've got a problem in the details of the specification,
not a fundamental issue.

(Note that prefix matching is the only reordering rule that has any
effect in almost all actual cases, so without that rule or a replacement,
both stability and any improvements in routing disappear)

Note that stability isn't definitively a good thing -- if the first
server you connect to happens to be the only one that's down/unreachable,
then with a stable resolver you need to have specific failover code
to use a different address; whereas if you can expect gethostbyname()
to return a different first result, you can just rerun the program.

 Furthermore, even if gethostbyname() has been deprecated in POSIX, it's
 relevant that there is still plenty of software in Debian that uses this
 interface[1].  Almost all of this software is going to be IPv4-only; if we
 want Debian to be fully IPv6-capable, these are programs that will need to
 be updated to use the getaddrinfo() interface, at which point they will
 cease to work correctly with round-robin DNS in the absence of additional
 code to re-randomize addresses(!).  

Uh, round-robin DNS isn't a guarantee that any individual client will
get different or randomised results -- and the argument that round-robin
won't break anything that relies on rule 9 goes the other way too.

Further, having getaddrinfo() behave differently for IPv4 and IPv6
isn't completely helpful in making Debian support IPv6 -- if we change
a program

Bug#438179: glibc's getaddrinfo() sort order

[Anthony Towns]

On Thu, Sep 20, 2007 at 06:19:10PM -0700, Steve Langasek wrote:
 So do you have a use case where you think the behavior described in rule 9
 *is* desirable?

Any application written assuming this behaviour, works correctly on
Windows, Solaris, *BSD and glibc based systems in general, but not
on Debian.

In the bug log, Pierre reported this behaviour is already supported on
most of those sytems:

] On that matter, according to Aurelien, Vista (maybe XP),
] {Open,Net,Free}BSD follow the RFC. Other OSes could be tested (MacOS X
] and solaris come to mind). So it's kind of a decision of Debian vs. the
] rest of the world. And if I don't really care about the issue of the
] decision technically, this aspect worries me.

Hrm, I see RFC5014 (from this month) provides some socket options for
changing the way RFC3484 source address selection works, and envisages
the possibility of doing the same for destination address selection. It
assumes prefix matching is undertaken in getaddrinfo in order to achieve
one of its aims.

 Even if you do have one, I still don't see any reason to think this is a
 reasonable default behavior on the real-world Internet.

As it happens I largely agree with that. I don't agree with making a
decision to go against an IETF standard and glibc upstream lightly,
though, no matter how many caps Ian expends repeating that it's at the
least mature level of Internet standard. If it's also the case that
the RFC-specified behaviour is a de facto standard amongst other OSes,
as the above seems to indicate, then that's even more reason to make
sure we have a clear decision backed up by good, clear reasoning.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#438179: glibc's getaddrinfo() sort order

[Anthony Towns]

On Tue, Sep 18, 2007 at 03:33:51PM +0100, Ian Jackson wrote:
 Anthony Towns writes (Re: glibc's getaddrinfo() sort order):
  I'm not familiar with how getaddrinfo() has been implemented in the
  past
 I think this is an important point.  If you're not familiar with the
 history then perhaps I can help explain.
 hostname-to-address lookups have up to recently generally been done
 with gethostbyname.

Right, gethostbyname I am familiar with (along with the corresponding
DNS round-robin behaviour), and changing its behaviour is certainly
unreasonable.

 [...]

 So far so good.  (For clarify, it is the above round-robin
 functionality that I am arguing ought to be preserved.)

 [...]

 However, additionally, it was realised that if getaddrinfo can return
 a mixture of IPv4 and v6 addresses it was necessary to specify in what
 order they ought to be returned.
 
 When RFC3484 was written its authors evidently felt that the best way
 to do this was to define a comparison function over all addresses,
 which would define which address was to be preferred.
 
 Heedless of the effect on the DNS round-robin functionality I describe
 above, the authors of RFC3484 specified (s6 rule 9) that all addresses
 should be sorted by proximity to the host making the choice - where
 proximity is defined as the length of the common initial address
 prefix.

So if getaddrinfo() has always behaved in this way, I don't see a great
deal of justification in changing it. The bug log indicated that there
were pre-rfc implementations of getaddrinfo() that behaved more like
gethostbyname() at least wrt round-robin DNS; but I've got no way of
verifying that.

 This may have been a disputed but arguable definition of real network
 proximity for IPv6 in at the time 3484 was written.  But it is clear
 now that it is not such a measure in the real IPv6 internet, and it
 has never been such a measure in the IPv4 internet.

I hadn't seen any indication it was disputed for IPv6 prior to your mail.
The patch in glibc only affected IPv4 addresses, for that matter.

 So RFC3484 s6 rule 9 is just wrong, because the reasons behind it do
 not apply any more if they ever did.

To give an analogy to the lines I'm thinking along: the definition of
tm_year in the tm struct in time.h is wrong, years since 1900 should be
years since 0 AD, but the spec says otherwise, so programs simply need
to deal with that historical craziness.

That's not quite the same here, in that the spec does (by my reading)
explicitly allow implementors to not behave in that way, but if you're
coding to the spec you certainly can't rely on DNS round-robin being passed
through an invocation of getaddrinfo().

 However, it's worse than that: rule 9 is trying to change the
 behaviour of existing systems.  If we agree with rule 9 it ought to
 apply just as well to applications using gethostbyname.

 All existing applications using gethostbyname are not in compliance
 with rule 9.  

The RFC specifies the behaviour of getaddrinfo(), not gethostbyname(),
so doesn't affect any apps that solely use gethostbyname(). So no, it
shouldn't be applied to other functions anymore than the definition of
tm_year should mean we count from 1900 in every year related function.

I think we can safely say that Rule 9 isn't useful for IPv4 addresses.
I'm not sure that's true or not for IPv6 addresses -- it certainly seems
an inappropriately hierarchial way of viewing a network that's connected
much more ... fluidly than that, at any rate. But even if Rule 9 is
completely useless and counterproductive, it's still the standard for
that function, which, afaics, we should be meeting.

 What about getaddrinfo ?  Well, there is no reason why a change in API
 (to add additional richness needed for new functionality) should so
 radically change the behaviour.

Agreed in principle, but this is a rule the RFC should've followed;
since they haven't, I'm not convinced we should.

 It is not reasonable for the RFC to attempt to specify that the
 addresses be returned in a predictable ordering when the established
 behaviour, relied on throughout the internet for decades, has been
 that the addresses are _not_ returned in a predictable order.

Again, I agree with that, but the RFC *has* done that.

  I'd say it's more important that getaddrinfo() on Debian behave the same
  as on other operating systems, than that it behave in the same way as
  other functions. I can only take the RFC's assertion as to getaddrinfo()'s
  proper behaviour though; I don't have a more direct idea how getaddrinfo()
  behaves in previous versions of Debian, other Linux distros, other libcs,
  Windows, etc.
 This argument is an argument for accepting any crap that comes out of
 glibc upstream.

No, it's an argument for accepting any crap that comes out of the Internet
standards process. :-/

 As I have demonstrated above, the RFC is wrong, inconsistent with
 existing practice, 

It's certainly inconsistent with gethostbyname()'s existing

Bug#438179: glibc's getaddrinfo() sort order

[Anthony Towns]

On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
 On Wed, Sep 19, 2007 at 03:03:51AM +1000, Anthony Towns wrote:
  So if getaddrinfo() has always behaved in this way, I don't see a great
  deal of justification in changing it. [...]
 glibc is the only implementation I know of that does this.

Windows implementations would seem like the other candidate, given the
Microsoft Research at the top of that RFC.

Cheers,
aj



signature.asc
Description: Digital signature