Re: Tips wanted for debugging and testing Debian

[Michael Tautschnig]

Hi!
[...]
If you want to take this one step further, actually trying to crash an
application in a reproducible way, or trying to narrow down a bug to a
specific set of actions can be really helpful as well; for instance, if
there's a bug that says something like 'If I run this application, it
sometimes segfaults when I close it', and you can narrow it down to 'if
you run it, and use this and this and that option and /then/ close it,
it will segfault', that's very nice.
You can browse our bug database at . A good way
to start is to search for any bugs in software you regularly use, and to
see if you can help out.
But what could one do, if the maintainer doesn't react (for some time) - 
such that even bugreport with fixes provided are never acted upon?

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

Re: Tips wanted for debugging and testing Debian

[Michael Tautschnig]

 If a bug is serious, and not a trivial thing, and if a patch has
been filed then a NMU could be applied.
But only a Debian developer can do so, right?
When saying "trivial" - did you mean easy to fix or the priority of a 
bug (i.e., wishlist)?

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

Re: Tips wanted for debugging and testing Debian

[Michael Tautschnig]

 Usually, but I've sponsored NMU uploads by non-DDs before.
Sounds interesting - how does that work?

When saying "trivial" - did you mean easy to fix or the priority of a
bug (i.e., wishlist)?
 I mean it should be a serious bug which is affecting real people
but has gone unadressed.  Not something like adding a new feature
which was filed as a wishlist.
 It's a judgement which people may make differently.
That seems sensible to me too.
I might get flamed, but I'd like to mention just one example - the 
a2ps-package. Some of the bugs might be really easy to fixed (patches are 
attached) - but have not even been acknowledged by the developer.

So - is there anything I could do to help?
Thanks,
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: combining fakeroot and distcc/SSH

[Michael Tautschnig]

also sprach Goswin von Brederlow <[EMAIL PROTECTED]> [2005.03.05.1840 +0100]:
ssh -i usualy helps.
not if you cannot influence how SSH is called.
Actually I don't really know, but maybe the environment-variable 
DISTCC_SSH could be helpful.

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

Recurring problems since upgrade of openldap2 (2.1 -> 2.2)

[Michael Tautschnig]

Hi list!

I don't know which package I should file this bug against, but since the upgrade
of the openldap2-packages I'm seeing these errors quite frequently:

chown:
/home/roland/debian/openldap/build/2.1.30/openldap2-2.1.30/libraries/libldap/cyrus.c:468:
ldap_int_sasl_open: Assertion `lc->lconn_sasl_ctx == ((void *)0)' failed.

This happens not only with chown, but just as well with ls, tar, etc. The
relevant installed packages are:

ii  libldap-2.2-7  2.2.23-1   OpenLDAP libraries
ii  libldap2   2.1.30-3   OpenLDAP libraries
ii  libldap2-dev   2.1.30-3   OpenLDAP development libraries

Furthermore, processes such as postfix or autofs exit with signal 6 (SIGABRT) -
which is very very bad...

Thanks in advance,
Michael


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

Re: Recurring problems since upgrade of openldap2 (2.1 -> 2.2)

[Michael Tautschnig]

[...]
> 
> Not to mention that you probably don't need SASL. Could not reproduce
> this yet and it seems that it normally occurs with ldaps or failover
> configurations.
> 

In fact, I'm using ldaps and failover:


BASEdc=xxx
URI ldaps://x.y/ ldaps://z.y/

TLS_CACERT /etc/ssl/certs/cacert.pem

The only thing I'm pretty sure of, is that it happens since the upgrade of
slapd, I don't think that it's the client libraries that cause these problems.

HTH,
Michael


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

Re: Recurring problems since upgrade of openldap2 (2.1 -> 2.2)

[Michael Tautschnig]

Hi Torsten,

> Hi Michael, 
> 
> On Wed, Apr 20, 2005 at 12:09:15AM +0200, Michael Tautschnig wrote:
> > I don't know which package I should file this bug against, but since the 
> > upgrade
> > of the openldap2-packages I'm seeing these errors quite frequently:
> > 
> > chown:
> > /home/roland/debian/openldap/build/2.1.30/openldap2-2.1.30/libraries/libldap/cyrus.c:468:
> > ldap_int_sasl_open: Assertion `lc->lconn_sasl_ctx == ((void *)0)' failed.
> 
> This looks quite likely like the problem is in libldap2. In fact a bug
> report about this issue is already filed. I am still not sure what the
> bug is all about. Seems like libldap tries to open a sasl connection
> twice for some reason and want's to make sure that this is only done
> once. 
> 
> Not to mention that you probably don't need SASL. Could not reproduce
> this yet and it seems that it normally occurs with ldaps or failover
> configurations.
> 

I'm still seeing these problems every now and then - could you please send me
the bug-number, such that I can at least track any news about regarding the
problem. 

Seeing the problem enter stable is not to my liking...

Regards,
Michael


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

Re: gcc-h8300-hms_4.1.1-3_arm.changes REJECTED

[Michael Tautschnig]

[...]
> 
> > - I've requested rescheduling the package on ARM as it should now build
> >   successfully, but I haven't seen any reply on this one.
> > 
> 
> If you have written to [EMAIL PROTECTED], this is the right place. I
> wish you good luck, as it is roughly an alias to /dev/null.
>
[...]

Hmm, what did you point at by "this" - [EMAIL PROTECTED] or anything else
like the CC list?

Anyway, let's hope that your thread on debian-devel has some positive impact on
the packages you confirmed that they build fine...

Thanks,
Michael




pgpWDq9Sw06fo.pgp
Description: PGP signature

Re: s390 buildd?

[Michael Tautschnig]

> On Tue, Feb 05, 2008 at 08:17:04PM +0100, Hakan Ardo wrote:
> > Hi,
> > 15/12 I released gcc-avr version 1:4.2.2-1, but acording to:
> > 
> >http://buildd.debian.org/build.php?pkg=gcc-avr
> > 
> > the s390 buildd has not yet tried to build it. What might be the problem?
> 
> http://buildd.debian.org/pkg.cgi?pkg=gcc-avr says "Not for us" so the
> s390 buildd admins decided to not build the package. You should contact
> [EMAIL PROTECTED] for this.
>

Good luck.

Michael, who has tried that for ages.



pgpn382W3F0zV.pgp
Description: PGP signature

Re: Bug#465813: ITP: cyclone -- Safe dialect of C

[Michael Tautschnig]

> Quoting François-Denis Gonthier ([EMAIL PROTECTED]):
> > Package: wnpp
> > Owner: François-Denis Gonthier <[EMAIL PROTECTED]>
> > Severity: wishlist
> > 
> > * Package name: cyclone
> >   Version : 1.0/CVS
> >   Upstream Author : Dan Grossman, Trevor Jim, Greg Morrisett et al.
> > * URL or Web page : http://cyclone.thelanguage.org
> > * License : GPL (+ BSD alike for some files)
> >   Description : Safe dialect of C
> 
> I suggest "C-like compiler with improved security checks"
> 
> "dialect" is faily trivial language for me, which is IMHO not suitable
> for a package description.
> 

I disagree - dialect is the proper technical term here.

Best,
Michael



pgpdUcZWdzlMt.pgp
Description: PGP signature

Re: Bug#466078: RFP: sourcenav NG -- source code analysis tool

[Michael Tautschnig]

> This is an improved version, thank you for the review.
> 
> Package name: sourcenav-ng
> Version: NG3
> Upstream Author: Sourcenav Development Group <[EMAIL PROTECTED]>
> URL: http://sourcenav.berlios.de/
> License: GPL v2 
> Description: Source code analysis, editor, browser and build tool
>  source navigator NG is a source code analysis tool, that works
>  extracting information from programs written in C/C++, Java, Tcl and
>  others languages. With it, you can edit your source code, display
>  relationships between classes and functions and members, and display
>  call trees. It is based upon the old source navigator and strives to
>  improve usability and performance.
>

Well, I think "other languages" is still far to unspecific. Further, I think
claiming "Source code analysis" is of little value as well: Considering the two
main features (call trees and class relationships) in this context, eclipse
could call itself a "source code analysis" tool as well, which I guess they
would never claim. Instead, this is just what makes up for a nice IDE today.

If this is something else than a nice IDE, state it. Otherwise say that this is
an IDE for .

Best,
Michael





pgpKnuX8W7wzE.pgp
Description: PGP signature

Re: the new style "mass tirage" of bugs

[Michael Tautschnig]

> Paul Wise wrote:
> > On Fri, Feb 22, 2008 at 2:07 AM, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> > 
> >>  OTOH, maybe you're just too incompetent for that.
> > 
> > Insulting contributors really isn't helpful Josselin.
> > 
> 
> But the same it true the other way around. Imho it's also not ok to
> insult DDs publically in the way jidanni did. We are all volunteers
> after all and ranting on a public mailing list doesn't help to improve
> the motivation (and doesn't magically fix the bugs).
> 

But jidanni did not actually insult anyone, but just made a statement on the
current situation (possibly also expression his personal frustration). Our
social contract says that we must not hide problems - and indeed there is kind
of a problem, even though it's hard to blame anyone for it.

Nevertheless we should not use stop with the excuse that we are all volunteers.
Of course we are, but maybe there is something that can be done. What about the
following (happy flaming...): Let's just pick openoffice.org. Rene needs help.
It has 340 open bugs. We're somewhere around 1000 DDs. Makes 3 developers per
bug. Let's just randomly form teams of 3 from all DDs and assign a single bug to
each team. One week to submit a patch to the BTS.

There could be several positive outcomes: Many bugs get fixed or at least
somewhat acted upon. Randomly forming teams might result in new
teams/corporations for whatever else is to come. Hopefully at least one of each
team will have the necessary environment to reproduce the bug. Anotherone might
have the required knowledge of $LANG.

Well, just an idea.
Michael




pgpGdY9Llrshx.pgp
Description: PGP signature

Re: the new style "mass tirage" of bugs

[Michael Tautschnig]

[...]
>   Some people really like mentoring and training others and find that
>   immediately rewarding.  Those people are wonderful and deserve all the
>   praise we can give them.  For the rest of us, I think it's often a lot
>   to expect of people.  That sort of training is in many respects
>   significantly harder than all the rest of what one does as a DD.  It can
>   be a lot of fun with just the right person and a great match of
>   personalities, but on a comprehensive, project-wide basis, you can't
>   rely on that match happening.  In a workplace, you simply have to make
>   training happen even if it isn't loads of fun for both people.  It's
>   much harder to do that as part of a volunteer project.
>
[...]

Do you think that there is a chance we find a group of people who really like
mentoring/training others? If so, we could maybe set up kind of a bug-frontdesk
taking over _all_ new bug reports for a moment and checking them for a the bit
of information that seems crucial to fix/reproduce the bug.

Well, just another idea.
Michael



pgpjReEeT1VWA.pgp
Description: PGP signature

Re: the new style "mass tirage" of bugs

[Michael Tautschnig]

[...]
> 
> What might work quite well, however, is to have "bug janitors" (a la
> kernel janitors) who look at new bugs that have received no attention
> for, say, two weeks. If a bug gets reported against a package, and the
> package maintainer doesn't react to it, then the janitors can look at
> it. They could look at old bugs in general, of course.

Oh yes, this sounds a lot better. I'd be willing to work in such a team of bug
janitors, and judging from Cyril's post, there might be others willing to do so
as well.

The only thing that is need is some kind of automatism, forwarding bugs that
have not been acted upon from some time to a mailing list or the like. No idea
what the proper way of implementing this would be, but I guess the technical
part is the easiest to solve.

Best,
Michael



pgpQWWaN5xfGM.pgp
Description: PGP signature

Re: Automatic debiian installation

[Michael Tautschnig]

[sorry for cross-posting, I guess this thread should move away from
debian-devel, but I'm not subscribed to any of the others]

> Hello,
>
> I would like to use a system to install automatically all my debian pc.
> But
> i don't know wich could be the best between FAI and  PRESSEED.
>
> Somebody could explain the difference 
>
> the avantage and disavantage of the two methodes...!
>

It depends a lot on your specific needs. If you're fine with setting whatever is
debconf-configurable (be it at install time, using d-i's preseeding options, or
rather at the level of the installed packages), preseeding may be an appropriate
way to go. 

FAI, on the other hand, is a very flexible framework for installing systems.
Debconf preseeding is supported, but just one option out of many. You might want
to run several scripts for fine-tuning your system, copy over config files, etc.
Flexibility comes at the cost of probably slightly higher complexity, but people
tend to get to know it quite easily.

HTH,
Michael



pgpRGVX9yoBaG.pgp
Description: PGP signature

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Michael Tautschnig]

> On Sat, Jun 21, 2008 at 07:34:59PM +0200, Holger Levsen wrote:
> > Hi,
> > 
> > On Saturday 21 June 2008 15:52, Alexander Wirt wrote:
> > > I'm still not that sure if its a good idea to add a non-offical debian 
> > > repo
> > > keyring into the archive... 
> > 
> > Nobody is forced to install it?!
> > 
> > And AFAICS we regulary recommend backports.org to users, who need newer 
> > software. So I think it should be in.
> > 
> But backports.org is still unofficial.  If it were permitted, then what
> would happen when other unofficial repository maintainers want to
> package their repository keyrings?  Will those be allowed or disallowed?
>

What's wrong with packaging a keyring? Does a keyring package differ in any way
from a "normal" (whatever that is...) package? It installs some files and in
some sense modifies your system. It does not download any software itself, so
what?

Best,
Michael



pgpqpEyl9Lk2t.pgp
Description: PGP signature

Re: Please focus on one generic spell checker in Debian (Was: Bug#487732: O: ispell -- International Ispell (an interactive spelling corrector))

[Michael Tautschnig]

> Am Mittwoch, 25. Juni 2008 21:53:24 schrieb Agustin Martin:
> > Each spellchecker has currently some special features. Fortunately, the
> > only thing where ispell is stronger than the other spellcheckers (support
> > for pseudocharsets like 'a, "a, \'a, ... ) is already included in aspell
> > development version, so at that time we can drop ispell without any loss
> > of features. Not sure about hunspell here.
> 
> What tools are using such pseudo characters, probably because they do not 
> support 8bit character sets? Can't they be fixed to do so?
> AFAIK, even latex knows the existence of the 8th bit, nowadays.
> 

Yes, LaTeX does fully support this, but portability of plain files across
systems remains an issue and many people thus still prefer to encode umlauts
this way. For example, we often share files between Linux, Windows, OS X client.
In such situations, 8bit is still horribly unreliable. In theory, of course all
of them support 8bit.

Best,
Michael



pgpYq8ewsxbpY.pgp
Description: PGP signature

Re: Please focus on one generic spell checker in Debian (Was: Bug#487732: O: ispell -- International Ispell (an interactive spelling corrector))

[Michael Tautschnig]

> Am Dienstag, 1. Juli 2008 12:33:18 schrieb Lars Wirzenius:
> > ti, 2008-07-01 kello 12:10 +0200, Thibaut Paumard kirjoitti:
> > > Come on, UTF-8 is good.
> >
> > UTF-8 also 16 years old. That's enough for people to get driver's
> > licenses in the US, to have legal sex in many parts of the world, and to
> > vote in local elections in some parts of the world. Surely it's enough
> > age for a character set encoding to be accepted into general use?

Well, it may be old and systems should have been adapted to it. And in fact, it
works quite well in all my Linux boxes and editors running there. It doesn't
work as well on other operating systems, even though people pay for those. But
at work we do exchange files with users of those operating systems. So with
stick with something that works for everyone. It's pointless to discuss this
problem on this list, because the problem is elsewhere. But nevertheless we need
to do our best to solve/avoid it.

> 
> No, you have to get rid of the stubborn users, first ;)
> 
> @Bernhard: How about configuring you keyboard to whatever fits you better 
> than 
> the multikey sequence? Or buy a keyboard with a german layout...
> If you really want to, it is not that hard to do.
> 

Debian's Social Contract says that "Our priorities are our users and free
software". It does _not_ say that "Debian should tell users what is good".
Right?

And further, if our users request that some spellchecker support the LaTeX-style
umlauts, then we should better support them.

Best,
Michael



pgpnWy1Vx4qRV.pgp
Description: PGP signature

Re: Please focus on one generic spell checker in Debian (Was: Bug#487732: O: ispell -- International Ispell (an interactive spelling corrector))

[Michael Tautschnig]

> Michael Tautschnig wrote:
> > Debian's Social Contract says that "Our priorities are our users and free
> > software". It does _not_ say that "Debian should tell users what is good".
> > Right?
> >   
> Taken to the extreme, this would mean Debian would still require  obsolete kernel version here> because some users still need it for
> obscure reasons.
> 
> There comes a point when we can no longer support out-dated stuff any
> more, regardless of what the SC says. At best it takes time and effort
> on maintaining compatibility that could be better spent elsewhere.
> 
First of all I should say that the context of my citation has been errornously
dropped here. I wrote the above in response to the "get yourself a proper
keyboard" thing. But ...

> Should the priorities be for the users who want the old stuff or the
> users who want the new stuff?
>
... of course Debian must move on and cannot support old cruft forever. In this
very specific case, however, there seems to be a viable alternative approaching
(aspell includes support in its development version, just seems to be a matter
of packaging this one). IMHO it is thus a matter of providing a smooth
transition, like keeping ispell in lenny, and dropping it afterwards. Meanwhile
hopefully aspell gets released.

Best,
Michael



pgpTJfODUoOSe.pgp
Description: PGP signature

Re: CDPATH and shell scripts

[Michael Tautschnig]

[...]
> So what is the right course of action here?
> 
> 1) unset CDPATH in every single shell script there is?
> 2) never use relartive paths for cd in scripts?
> 3) shoot the user for doing something dumb?
> 4) disable CDPATH in /bin/sh (or is that POSIX?) or non-interactive
>scripts (would break automake I think)
> 

Looking at some autoconf-generated configure script I've found the following:


# The HP-UX ksh and POSIX shell print the target directory to stdout
# if CDPATH is set.
(unset CDPATH) >/dev/null 2>&1 && unset CDPATH


I had once stumbled over this problem and ever since I keep using

cd bla > /dev/null

whenever the output could possibly trouble me. But well, actually, unsetting
CDPATH would be more appropriate.

Best,
Michael



pgpbQZmW16g4o.pgp
Description: PGP signature

Re: Better tracebacks for C/C++ (and probably Ada & Fortran, too)

[Michael Tautschnig]

[...] (cool stuff)

> >
> > I'm now wondering whether something like this already exists (I
> > couldn't find anything, though).  I'm also not sure where to put this.
> 
> gnatbind could be instructed (-E) to store non-symbolic traceback in 
> exception 
> occurrences, which would be printed out as a list of addresses of calls, 
> which 
> could then be translated into source lines by addr2line tool from binutils. 
> There is also Call_Chain() procedure for Ada which records the a complete 
> stack traceback and is part of the GNAT.Traceback package, which I suspect 
> probably operates in a way similar to your library operation, though I have 
> never used that before.
> 
> > Due to the peculiar combination of libraries, it's somewhat
> > Debian-specific.
> 
> Perhaps the authors of `diagnostics' source package (available in Debian) 
> would be interested to include your library.
> 

[...]

Now that reply is somewhat late, but real life keeps me busy these days... It
would indeed be interesting to include your work in diagnostics, or at least be
able to use it from within diagnostics (meaning you do you roll your own library
or the like with a nice API).

Florian, I couldn't find anything on your web-page. Are you still interested in
that project?

Thanks,
Michael



pgp7UPXEbrF9R.pgp
Description: PGP signature

Bug#551992: general: stopping squeeze chroot shuts system

[Michael Tautschnig]

> Package: general
> Severity: important
> 
> 
> On this system I installed a squeeze chroot using the following command:
> 
> debootstrap squeeze /chroot/squeeze-x64-lighttpd-chroot 
> http://ftp.debian.org/debian/
> 
> This works as expected but when I stop the chroot, the system shuts as well.
> This is highly unexpected and somewhat unpleasant behaviour.
> 

Could you please elaborate on "stop the chroot"? One can enter and leave a
chroot, but a chroot is not a daemon or virtual host that could be
started/stopped!?

Thanks,
Michael



pgpS90X8uw2uR.pgp
Description: PGP signature

Re: Switch on compiler hardening defaults

[Michael Tautschnig]

> On Monday 26 October 2009 09:22:26 Marco d'Itri wrote:
> > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > > uses[2].
> > 
> > Seconded.
> 
> Thirded.
>

+1.

Thanks for bringing this up,
Michael



pgpDxjsmOMyTR.pgp
Description: PGP signature

Re: debian/rules "make -f" restriction

[Michael Tautschnig]

> Le Wed, Oct 28, 2009 at 04:02:32PM +0100, Tobi a écrit :
> >
> > Debian Policy 4.9 says about debian/rules:
> >
> > "It must start with the line #!/usr/bin/make -f, so that it can be  
> > invoked by saying its name rather than invoking make explicitly."
> 
> Dear all,
> 
> I also do not understand that rule. There are a larger number of packages that
> are simply removing all the content from the make file, for instance like:
> 

[...]

I don't think there's a point in disussing whether or not the shebang-line must
be there (and that it must read as stated in policy). The fundamental point is
that debian/rules must be a Makefile (and not just looks like a Makefile).
Debian Policy 4.9 guarantees that the behavior of debian/rules will be the same
if called as either make -f debian/rules or simply debian/rules.

> 
> I think that the key part of the Policy is the interface: debian/rules can be
> called with arguments such as ‘build’, ‘clean’, etc. When unique features of
> GNU Make are not needed, I do not see much advantage in requiring that the
> parts that actually do the work are wrapped into a makefile. Can’t we just
> trust the maintainers instead of putting restrictions that in the end are only
> increasing complexity for no benefit? 
> 

[...]

Yes, it's the interface. And the first sentence of 4.9 reads as:

"This file must be an executable makefile, and contains the package-specific
recipes for compiling the package and building binary package(s) from the
source."

This implies that the interface is to a larger extent documented in the make
documentation. Policy also specifies that a set of targets must be supported by
this makefile, but it doesn't say that these are the (only) supported arguments.
What about -j, for example? Not part of 4.9, but supported and documented by
make.

Adhering to a standard actually decreases complexity. What may seem "elegant" at
first makes it a lot harder for other people to step in. For example, the
VDR-solution IMHO doesn't decrease complexity, it merely hides it.

Best,
Michael



pgp7d7EB6nuxy.pgp
Description: PGP signature

Re: debian/rules "make -f" restriction

[Michael Tautschnig]

> Michael Tautschnig wrote:
> 
> > Adhering to a standard actually decreases complexity. What may seem 
> > "elegant" at
> > first makes it a lot harder for other people to step in. For example, the
> > VDR-solution IMHO doesn't decrease complexity, it merely hides it.
> 
> Yes, it indeed hides some complexity. But it only hides the stuff that is
> beyond the scope of the actual standard build process. It has no impact on
> the maintainability of the packages.
> 

In an earlier post you mentioned a pbuilder build process: If that is what you
are using, why not go for pbuilder hooks? A hook named A should be
fine, as far as I understood. It should get executed after unpacking the source,
but before starting the build. You could fiddle around with debian/rules in any
way you like and you would (a) not need the special shebang line, (b) not
contaminate the package _at all_ and (c) be happy :-)

HTH,
Michael



pgpps4KcO5Q3h.pgp
Description: PGP signature

Re: debian/rules "make -f" restriction

[Michael Tautschnig]

[...]

> 
> Build a development version of the vdr-plugin-* package from the same
> source, but using the API of the development version of VDR and with a
> different binary package name:
> 
> SPECIAL_VDR_SUFFIX=devel dpkg-buildpackage -tc -uc -us -rfakeroot
> 
> This way it works out-of-the-box with all the various build tools.
> 

Why don't you provide a script like debian/make-special-rules such that

debian/make-special-rules
dpkg-buildpackage -tc -uc -us -rfakeroot

does the job? I'm sure you already considered this idea, so would you mind
explaining why this does not work? Obviously you can tell your users/developers
that calling this script is required just as you documented the
SPECIAL_VDR_SUFFIX thingy.

> >From our point of view this is so easy to do and so easy to maintain (it's
> working quite well for over 2 years now), that this very specific
> requirement of the policy just seems to be a useless piece of bureaucratic
> over-specificiation.
> 
> We are still thinking about different solutions, not requiring to change
> the shebang line. But as said before - it's not that easy and it will most
> likely increase the complexity of debian/rules. A lot of pain, without a
> gain :-)
> 

[...]

I think Manoj already explained quite well why policy is that specific about a
single line. And apparently thousands of packages adhere to policy in this case,
so it's somewhat dubious that only VDR-related packages cannot cope with it. I
understand that any solution must remain easy to use and of course also easy to
maintain. But a hackish shebang line cannot be the only way to achieve this.

Best,
Michael



pgpXE7xLSaUKN.pgp
Description: PGP signature

Re: debian/rules "make -f" restriction

[Michael Tautschnig]

> Le Fri, Oct 30, 2009 at 09:35:58AM -0500, Manoj Srivastava a écrit :
> > 
> > The interface definition behind this is:
> 
> That ‘make -f debian/rules’ is not present anywhere in the Policy demonstrates
> it is not the interface.
> 

[...]

For the sake of completeness: Policy states that debian/rules is a makefile.
There is no need to document the above because all the make manuals already do
so.

Best,
Michael



pgpuyS4YjbprL.pgp
Description: PGP signature

Re: automake and intermediate files generated by yacc, lex, valac

[Michael Tautschnig]

> Hi,
> 
> there are several tools that generate C source code that is later
> complied in object code, e.g. yacc, lex or valac.  automake defaults to
> distribute these built intermediate files, so they are usually not
> regenerated during a build.
> 

[...]

Why do you restrict this question to generated C code? configure, Makefile.in
and some others are generated as well. Wouldn't it be consistent to talk about
all these files?

Best,
Michael



pgpS9Nk9lHOAO.pgp
Description: PGP signature

Strange FTBFS of gcc-h8300-hms 1:3.4.6-2

[Michael Tautschnig]

Hi!

I'm maintaining the gcc-h8300-hms package and had another upload of the package
through my sponsor (I'm not a DD yet). However, unlike 1:3.4.6-1, it FTBFS
(http://buildd.debian.org/fetch.cgi?pkg=gcc-h8300-hms;ver=1%3A3.4.6-2;arch=hppa;stamp=1169399342),
which is strange for 3 reasons:
- the differences to 1:3.4.6-1 should not affect the build process at the point
  where it fails
- it fails due to an error in the system headers:
/usr/include/sys/types.h:100: error: two or more data types in declaration 
specifiers
- while running configure in the subdirectories, the results vary, like:
[...]
Configuring in intl
[...]
checking for iconv... yes
[...]
Configuring in gcc
[...]
checking for iconv... no, consider installing GNU libiconv

Is there any way to either get access to some hppa host or obtain the config.log
files?

Thanks a lot,
Michael

PS: I've sent this mail to hppa_at_buildd.debian.org and
debian-hppa_at_lists.debian.org before, but didn't get any reply.



pgpM5rSUwt6FT.pgp
Description: PGP signature

Re-enabling architectures/removing packages from not-for-us

[Michael Tautschnig]

Hi!

As far as I understood it, _at_buildd.debian.org is the right place for
getting some package removed from not-for-us, however, I'm seeing no reply from
the s390 admins as far as the gcc-h8300-hms package is concerned. Is there maybe
someone on this list who could help out?

Best,
Michael



pgpeikSRjpvA3.pgp
Description: PGP signature

Re: Bug#482528: heimdal-clients,krb5-user

[Michael Tautschnig]

> Hello,
>
> Can I please have some input into this bug report?
>
> The report itself seems valid, ideally these packages shouldn't conflict.
>
> Solving this in such a way as not to break lots of stuff could be  
> awkward though.
>
> Ideas?
>

Are you guys really sure that alternatives are so misplaced here?
- Both perform a similar function.
- A user installing any of the alternatives providing kadmin will probably know
  what they are doing (at least so I guess); and (to be checked) using the wrong
  one will do no harm to the Kerberos database, it will just not work.
- update-alternatives --list editor 
/bin/ed
/bin/nano
/usr/bin/vim.tiny
/usr/bin/emacs21
/usr/bin/vim.basic

  Same command line interface? Definitely not. Same functionality? They all
  modify a piece of text, but that's about it. No need to flame, though, one
  could probably give a lot more examples other than editor.

Best,
Michael



pgpt4NeoD2yNb.pgp
Description: PGP signature

Re: Bug#482528: heimdal-clients,krb5-user

[Michael Tautschnig]

> Yeah, I'm reasonably sure that alternatives are wrong for kadmin.
> Editor is intended to be used by a user.  Kadmin is often used by
> users but is also quite often used by scripts.
> 
[...]

Well, if alternatives is the wrong approach, let's try an analytical approach:

- heimdal-clients and krb5-user must not both be installed: Clearly, conflicts:
  is indicated. Then both may provide kadmin. It will break no system (they
  can't both get installed right now).
- Conversely, the packages do not conflict. Then they must not both provide
  kadmin. I guess that there is consensus that even neither of them must ship
  kadmin. 
  - If no kind of aliasing is provided, surely all scripts are going to break.
It will force users to clean up their scripts. A migration path may be
provided, but this will just delay breakage.
  - If an alias is provided (be it alternatives or whatever), it will not cause
scripts to break whenever the link points to the proper kadmin. Determined
by luck or proper system administration. It will break fewer systems.
Alternatives at least provide a clean interface to such a shared alias. They
may be inappropriate, though, as pointed out.

Any options that I'd be missing?

Best,
Michael



pgpI4FjfLk1Hy.pgp
Description: PGP signature

Symbol files and C++ name mangling

[Michael Tautschnig]

Hi all,

I just added a symbols control file to the latest upload of the diagnostics
library. I started out with a single libdiagnostics0.symbols file, which caused
an FTBFS on all archs [0]. So we all know that C++ name mangling has its
downsides, but in this case it becomes a real PITA. Though, it is questionable
whether C++ name mangling is the issue, or symbol files are just broken by
design. Obviously I will now create arch-specific symbol files, but what if we
ever add a new symbol to diagnostics? Quite likely, things will FTBFS once
again.

Of course, I could add some wildcard, but this renders symbol files more or less
useless.

Michael.

[0] http://buildd.debian.org/build.php?pkg=diagnostics



pgpJApuG8n5pX.pgp
Description: PGP signature

Re: package deviates from standard mail-transport-agent dependency.

[Michael Tautschnig]

> On Thu, Aug 21, 2008 at 12:37:38AM -0700, Steve Langasek wrote:
> > > Where did you discuss this mass filing of (useless) bugs before you
> > > submitted them?
> 
> The previous discussions has lead nowhere. No use in discussing it yet
> again, instead it's time to act!
> 
But mass-bug-filing without prior notice is no proper way to act.

> > 
> > In particular, these bugs are *contrary* to the developing consensus in the
> > thread at http://lists.debian.org/debian-devel/2008/05/msg00381.html ff.
> 
> There where no consensus, since you where all just discussing overengineered
> solutions for solving the problem and all pointing out bugs in eachothers
> suggestions. Using exim4 | mail-transport-agent is the most
> straight-forward solution and will require minimal changes.
[...]

Solution to which problem? I completely fail to see a _problem_ here. Ok, not
all people get installed the same MTA -- so, what? If people care about the MTA
(like I do), they have their preferred MTA installed anyway.

> 
> If people put as much effort into actually working on packages
> as they did on debating in useless threads that leads nowhere the
> distribution would be in a hell of alot better shape.
> 
> Over and out.
>

Why don't you build your own CDD? So you don't need to discuss anything. Of
course, some discussions fail to reach consesus. This simply means that none of
the proposals has been good enough. Make a better _proposal_ and then according
to that. In this particular case, however, I'd even say that there has been some
consesus, just nobody stepped up to implement it. 

Best,
Michael



pgpe74pe5Ar4I.pgp
Description: PGP signature

Re: NEW processing

[Michael Tautschnig]

[...]
> > So, it is much better these to be detected and probably rejected 
> > before doing any more harm on their way. Low quality packages won't help 
> > users either, nor these users get the finally fixed and brought into 
> > relatively sane shape package faster.
> 
> I'm quite sure that most of our users would value "getting all new
> versions of important software a week earlier" higher than "get packages
> later, but with less packaging bugs". As already pointed out in this
> thread, lots of people use Ubuntu despite the (perceived) lower quality
> of universe packages :P

I don't think that we should discuss the quality of Ubuntu in a Debian mailing
list. They have different standards and different goals, that's it. Whether
their quality is lower or higher is surely not as easy to judge and first and
foremost not what we need to deal with a DDs.

Lucas, you've done lots of work for improving the quality of Debian packages in
the past, so I kind of wondered about the above statement. But anyway, I don't
think that it is easy to substantiate your claim about "what our users would
value". Personally, I really prefer high quality to "release quick and dirty",
but that is definitely biased by my use of Debian on a larger number of
production servers and client systems. I'd agree that quick and dirty is better
than not being able to run at all on some fancy latest&greatest XYZbook.

Still, I don't think we need to bring in that unknown $user, I think this thread
is more about some impatient DDs sitting and waiting for their package to enter
the archive. I doubt that many users turn to $Distro just because of NEW
processing being a lot of work and thus taking too long. Which again, I cannot
substantiate by any numbers.

Instead of what has happened in most of this thread we should really start to
listen to what ftp-masters and -assistants said (as part of this thread). They
do have a profound understanding of what takes most of their time. If all of us
would take just a bit more time to prepare that latest and greatest release
(counting in myself) ftp-masters would just get to review nicely built packages
and could focus on legal stuff, name clashes and the like. Instead, currently,
they get distracted by many easy-to-spot errors (including lintian
warnings/errors, which really doesn't require one to be an ftp-master to
see...). We're currently asking the guys to review the contents of something
full of spelling mistakes. Would you, yourself, be able to focus on the contents
if you can hardly read it because of syntactical errors jumping at you? And,
after all, the REJECT mail also requires a write-up of all those errors. Again,
fewer errors means faster processing.

Yes, packages sit in NEW for some time, maybe for too long. But as seen in both
this thread and the qmail thread lately, packagers could take lot more care and
thus take a lot of burden off of the FTP-team. If the team could rely on
packages ending up in the NEW queue to be of appropriate quality, they would
really only need to spend their time on legal gate-keeping. We can try to
increase the number of people processing NEW, but we could really also balance
part of the work across all DDs.

Best,
Michael




pgpaNDc5Xb2z6.pgp
Description: PGP signature

Re: Let's restart from scratch the gr_lenny vote (in a better form this time)?

[Michael Tautschnig]

> On Thu, Dec 18, 2008 at 01:22:40PM +0100, Sandro Tosi wrote:
> 
> > So, how many are in favor of redo *completely* the vote (in more
> > ballot, the first being the one for lenny ONLY)? how many should we be
> > to let it happen? how many should be in contrary to stop this re-vote?
> > how can we express the need for a better vote to let our beloved lenny
> > be released?
> 
> I'm against stopping the current vote. Let's wait for the outcome, and after
> that hold new votes for options that are still relevant then.
> 

Do we have any well-defined procedure to stop/cancel a GR (in progress)? If not,
is it the DPL to decide, based on what is voiced on this list? Shouldn't people
just say "Further discussion" in their votes to express such concerns (in terms
of a vote)?

Best,
Michael



pgpK2MVBfTI3R.pgp
Description: PGP signature

Re: I hereby resign as secretary

[Michael Tautschnig]

[...] (Sorry for only focusing on the below point, it was a really nice, but at
the same time also scary read!)

> 
> One bright spot is that I think there are fewer poisonous people in
> positions of authority in Debian now than in many points in its
> history.  We have a great leadership team, including ftpmasters,
> listmasters, release managers, secretary, SPI board, translators,
> system admins, DPLs, etc. and I am amazed at the amount of crap they
> put up with in order to do thankless tasks.  Even though I don't agree
> with everything you do, I've got to say: great job.  You guys do a job
> I would never want, day in and day out, and take lots of crap in the
> process.  Thanks for making this project possible.
> 
> Now if only we could say positive things about people BEFORE they
> resign, wouldn't this be a better place?
> 

Yes. Yes. Absolutely. I've written about that to Manoj in PM such as not to feed
the trolls any further, and my choice of words has probably not been as
profound, but I nevertheless tried it: We don't take those 5 minutes to say
"thank you" to all of those doing the grunt work in here (well, actually we
don't say it to a single one of them); instead, we use up all of our time to
flame over and over again. There is one slight hope, though: I might be
overly generalizing and saying "our time" when actually it is only a small, but
loud, group of people.

The hope lies in the community being even stronger than those few crying out
louder and making others think that their point is what Debian is about.  Free
speech is great, but sometimes silence is indeed gold.

  "It is better to sit alone than in company with the bad; and it is better
  still to sit with the good than alone. It better to speak to a seeker of
  knowledge than to remain silent; but silence is better than idle words."
  [Imam Bukhari]

Quietly,
Michael



pgp6pGCvdtw8F.pgp
Description: PGP signature

Re: Bits from the Debian Installer team

[Michael Tautschnig]

[...]
> - New features: 
[...]
>   support for realtime mount options
I think this^  was meant to be "relatime", and it is a single mount option.

[...]

Thanks for the great work,
Michael



pgpC6Pq9hQSOv.pgp
Description: PGP signature

Re: Override changes standard -> optional

[Michael Tautschnig]

[...]
> 
> The policy definition of 'standard' is:
> 
>   These packages provide a reasonably small but not too limited
>   character-mode system.  This is what will be installed by default
>   if the user doesn't select anything else.  It doesn't include
>   many large applications.
> 
> It's difficult to see how any of these packages fail the *definition* of
> standard.
> 

Indeed this is hard to tell, but "not too limited character-mode system" is so
vague that it won't be very helpful to take a look at this definition anyway.
Rather, it will require a case-by-case decision building on consensus.

> > strace
> > mtr-tiny
> 
> I think these are useful troubleshooting tools that we ought to install by
> default.  mtr-tiny is the only traceroute tool included in standard
> currently.
> 
> For comparison, both of these packages are part of the Ubuntu standard
> system.
> 
> I think we ought to even consider adding gdb in addition to strace, size
> allowing, since these two tools are rather complementary in their use; but
> certainly, I'd prefer having strace over not having either.
> 

Is "standard" in some sense also targeted at those who do lots of stuff other
than hacking with their computer systems? If so, I doubt that the the output of
strace will be very useful to those, and neither will those have any idea about
computer networks and the output of traceroute. As such, even though I do love
to have those tools at hand myself, I fully agree with the ftpmasters' proposal
of demoting those packages.

[...] (the other stuff I agree with)

> 
> > For the time right after the release we also intend to move ispell,
> > iamerican, ibritish, wamerian and dictionaries-common down.
> 
> Why?  I don't think that's justified at all.
> 

Hmm, do you disagree with the proposed move, or with postponing that?

Best,
Michael



pgpfFz799WXjA.pgp
Description: PGP signature

Re: Override changes standard -> optional

[Michael Tautschnig]

[...]
> 
> Actually, I misspoke in saying that mtr-tiny is the only traceroute we have
> by default.  iputils-traceroute is also installed at Priority: important; but
> iputils-traceroute is far less useful on modern networks than mtr-tiny is.
> 
> If traceroute belongs in important, then mtr belongs in standard.
> 

I'd rather say that the priority of iputils-traceroute should be downgraded as
well.

> > If so, I doubt that the the output of strace will be very useful to those,
> 
> The same argument easily applies to the output of 'dig', which is included
> in dnsutils at Priority: standard.  Nevertheless, having it available by
> default is useful for troubleshooting purposes when a problem has been
> escalated to the corresponding "support" personnel (via a Debian bug report,
> by handing your computer to your local expert, or whatever).
>

I do see one important fact here: Both, some traceroute tool and dig, are useful
in troubleshooting network problems, and its output will be useful for support
personnel. While the latter is also true for strace and friends, network
problems may prevent one from fetching the corresponding packages from Debian
mirrors.

Summarizingly I think that network troubleshooting tools should have a higher
chance to stay with Priority: standard than other debugging tools. Still, there
must be some consistency: If dig goes in, then some traceroute implementation
should do so as well, or (my preferred position) all of them should be demoted.

Best,
Michael



pgpllqN0hAZFV.pgp
Description: PGP signature

Re: Override changes standard -> optional

[Michael Tautschnig]

[...]
> 
> > I could buy that for mtr-tiny, but which average user can do anything
> > meaningful with strace so that it needs to be in standard? If you need
> > it you have bug, and the average user will report that $upstream
> > (debian, developer, wherever). And can then install it if asked to
> > strace something.
> 
> Having the tool available by default means one less step that users need to
> follow in order to debug.
> 

[...]

My main concern is that user <-> debug relation, which I doubt. "standard" is
meant for all users, not only for the developer/sysadmin subset. I do agree that
installing the debugging tool, when directed to do so, is one additional step,
but it's probably the easiest one.

Best,
Michael



pgpoLyhrv62U0.pgp
Description: PGP signature

Re: mass bug filing for undefined sn?printf use

[Michael Tautschnig]

[...]
> Michael Tautschnig 
>binutils-h8300-hms
> 
[...]

Fixed in unstable.

Best,
Michael



pgpiPwdmopCV1.pgp
Description: PGP signature

Re: Installation of Recommends by default on October 1st

[Michael Tautschnig]

[...]
> I use aptitude for my everyday work. On my desktop, I really appreciate
> pulling in Recommends. On cluster compute nodes, I don't. But I can turn
> it of easily without being "forced" to use apt-get just because I'm on a
> different type of machine. Compute nodes are what I'd call an "unusual
> installation", as the Policy states it for Recommends. So are Embedded
> Devices. (Of course, the definition of "usual" is always vague.)
[...]

Please consider two things:
- More than 90% of all processors are installed in embedded systems (of course,
  only on pretty few of them Debian is installed)
- (Debian) Linux is still more widely spread on server systems than on Desktops
  ([1,2] sorry, both are German)

However, especially Desktop users must be handled with extra care, so probably
staying with the current state really isn't an option. What I'd propose is not a
debconf question by apt, but rather the debian-installer. I'd follow this
approach for three reasons:
- debconf is used by the d-i anyway already, so no need for the APT-people to
  add debconf-stuff
- the d-i may be pre-seeded, so auto-installs using the d-i may avoid 
displaying 
  this question
- In case someone doesn't use d-i to setup systems there will be ways to modify
  the apt configuration anyway (be it copying or editing of config files or
  whatever)

What remains to be discussed is then, whether already installed systems should
get recommended packages or not. To go a little further, what would be a proper
way of asking users whether they want their settings changed or not (apart from
apt asking debconf questions).

Best,
Michael

[1] http://www.linux-professionell.net/praxis/article20061110018.aspx
[2] http://derstandard.at/?url=/?id=2974144



pgpdRVF4VRL9Q.pgp
Description: PGP signature

Re: Parallel build results

[Michael Tautschnig]

> I finally got through the test builds of all the source packages in sid for 
> i386 using dpkg-buildpackage -j3 on a dual core machine.  The results as 
> before are at http://people.debian.org/~schepler/build-logs/bymaint.html .  
> Some statistics:
>
[...]

BTW, Daniel, it would be nice if you provided a detailed description of the
exact build environment you use, i.e., kernel version, libc version, gcc, ...

Thanks,
Michael



pgpkghRLTogCM.pgp
Description: PGP signature

Re: Parallel build results

[Michael Tautschnig]

> I finally got through the test builds of all the source packages in sid for 
> i386 using dpkg-buildpackage -j3 on a dual core machine.  The results as 
> before are at http://people.debian.org/~schepler/build-logs/bymaint.html .  
> Some statistics:
>
[...]

Wouldn't it have been wise to use lenny (or even etch) instead of sid?
Apparently your statistics include all the failures due to "normal" bugs
entirely unrelated to the parallel build process.

Best,
Michael



pgpnf9JaJMYby.pgp
Description: PGP signature

Re: New field in binary stanza

[Michael Tautschnig]

[...]

> > I understand your need, but in this case (as opposed to the others you
> > mention) I believe a new field is not the right solution. The reason is
> > that in the general case too many information would need to be encoded
> > in such a field; that's why a machine interpretable copyright format has
> > been proposed [1].
> 
> Well, my proposal was for an optional field: who wants it, uses it.
>

What about debtags? Wouldn't this be most appropriate?
- It's optional.
- It's available from the apt-cache.
- No need to change dpkg, policy, etc.

Best,
Michael



pgpSOPbnRzCiP.pgp
Description: PGP signature

Re: Parallel build results

[Michael Tautschnig]

> On Sun, Dec 02, 2007 at 11:13:53PM +, Ben Hutchings wrote:
> >It appears that ExtUtils::MakeMaker, a standard Perl module commonly
> >used to generate Makefiles for Perl modules, emits the rule:
> >
> >install :: all pure_install doc_install
> >
> >This appears to account for the failure of some of my Perl packages, and
> >probably many others.  This should be fixed in MakeMaker, not in the
> >packages that use it.
> 
> About the only option I can see is to use something like:
> 
>   install :: all
>   $(MAKE) pure_install doc_install
> 
> which I'm not terribly keen on.  I'm open to better suggestions.
>

I don't actually remember the part of this discussion where the real cause of
the problem with the above rule was discussed, but in case it is about some
dependencies between the rules (which is the most likely IMHO), then it should
really be fixed as follows

doc_install:
  ...

pure_instal: doc_install
  ...

all: pure_install
  ...

install:: all
  ...

This is not a hack but instead the only way of properly fixing the problem (and
in fact the parallel builds then only made the bug visible...).

Best,
Michael




pgpg2mhGpEKwi.pgp
Description: PGP signature

Re: Debian-AI

[Michael Tautschnig]

[...]
> 
> I am requesting comment on this approach, review of my project, and
> looking for guidance.  Though I have tried for 7 years, I have not
> been able to make the breakthrough into the community (most likely
> owing to a lack of social skills).  I tried to discuss this project on
> the Debian channels, where they suggested I post to the Debian-devel
> mailing list.
> 
> Would there be any interest in a Debian-AI sub-project?
>

Hmmm, I kind of fail to see the exact point: Are you really proposing a
sub-project related to AI software (like Debian-Med is for medical tools), or
are you rather proposing an AI approach to selecting and packaging any software?
Judging from the beginning of your post I was tempted to think of the latter,
but suggesting an AI sub-project seems something pretty different from that.
Further, your repository mainly contains AI-related tools, but also some
unrelated software.

Could you/somebody else clarify this a little?

Best,
Michael



pgpt0Y0h3ZzLt.pgp
Description: PGP signature

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Michael Tautschnig]

> Robert Collins <[EMAIL PROTECTED]> writes:
> > On Wed, 2008-01-02 at 00:29 +, Colin Watson wrote:
> 
> >> Some packages actually do need to shut down cleanly; in the case of a
> >> database, for example, such a change could cause data loss.
> 
> > Surely no more than a hard power failure(*), which databases (even such
> > lightweight ones as sqlite) are designed to handle.
> 
> You can still lose data transactions that weren't complete, and you may
> have to go through an extended consistency check when the system comes
> back up.
>

Definitely. And databases are likely to store some critical data, just consider
LDAP as yet another database (which, for performance reasons, won't write
changes to disk all the time).

Once we are at it: If we don't do clean shutdowns of the services anymore, why
don't you just turn off power instead of taking the pain to kill the processes?
I guess I missed the point.

Best,
Michael



pgpXIhMdRYBBM.pgp
Description: PGP signature

Re: Correct spelling/capitalisation of project names

[Michael Tautschnig]

> * Russ Allbery <[EMAIL PROTECTED]> [2008-01-12 09:11]:
> 
> > Rafael Laboissiere <[EMAIL PROTECTED]> writes:
> > > The name of the S-Lang library is sometimes wrongly spelled as "slang". It
> > > would be good to have this fixed but if you add a rule slang -> S-Lang in
> > > Lintian you will hit some false positives (like in packages ascii and
> > > jargon) because "slang" is an English word.
> > 
> > Yeah, unfortunately I don't think lintian will be able to catch that one.
> 
> Can't you add exceptions for some packages in the Lintian check?  The only
> packages in sid that use "slang" as an English word are ascii, jargon, and
> jargon-text.  Other packages that use "slang" or "SLang" mean actually the
> "S-Lang" library.
>

I gues SLang could safely be added, but adding some packages as exceptions would
mean changes to lintian every time a new packages (correctly) uses slang, which
would even mean that this should be done before some new package foo gets added
to the archive, otherwise people can't even upload lintian-clean packages...

If an slang check is introduced in lintian I'd rather opt for people overriding
this in their packages (following your reasoning that this concerns only very
few packages).

Best,
Michael



pgpzy5VtnHP5C.pgp
Description: PGP signature

dpkg-gensymbols and C++ (once again)

[Michael Tautschnig]

Hi all,

With the recent upload of diagnostics I've again been bitten by dpkg-gensymbols
[1]. As you might notice, the symbol is/was there, just the mangling scheme
seems to have changed. For one, the next upload will be the third upload just to
fix changed symbol names on alpha. One could argue that I should have built the
package on an alpha system beforehand to avoid such brokenness. Well, I did.
Most probably the g++ versions used on albeniz.d.o and goetz just don't match.
Similarly, archive-rebuilds will show more or less spurious FTBFS (e.g.,
#562397 -- I'm building binary packages on amd64 myself).

I understand that symbol files could help to improve quality of our archives
and, as diagnostics is about software quality as well, I'd tend to support this
as well as possible. At the current stage, however, this seems hardly feasible
with C++ libraries, unless I'm doing something wrong.

Couldn't the following be implemented, maybe as some C++ mode of 
dpkg-gensymbols? 
- Instead of mangled symbol names, source packages should ship demangled symbol
  files. This way, package maintainers could truly inspect those lists of
  symbols and maintain them in a sane way (like manually adding symbols as the
  API evolves). The symbol names would remain independent of the architecture
  and sorted in some logical way (i.e., by C++ namespace and class names),
  unintended symbols as part of those lists would become obvious, etc. 
- Pending realizability using g++ or the like, these lists are converted to
  their architecture-specific variants consisting of mangled names by
  dpkg-gensymbols.
- Subsequently, the mangled list and the contents of the library should be
  compared and (as done currently) deviances reported. It would be nice, of
  course, to demangle missing and/or additional symbol names.
- The mangled list (generated from the list of the source package) should then
  be shipped in the binary package.

I guess the facilities to mangle/demangle are there, I just don't know whether
they are accessible from the command line.

Best,
Michael

[1] https://buildd.debian.org/~luk/status/package.php?p=diagnostics



pgpDFz904Y6fU.pgp
Description: PGP signature

Re: Xen, Squeeze, and Beyond

[Michael Tautschnig]

First of all, I'd like to say a big THANKS to all the people maintaining Xen
within (in of course also outside) Debian; you really saved us lots of money and
energy (which is both, electrical and that personal one). 

[...]

> 
> > 4) What will be our preferred server virtualization option for non-Linux
> > guests after squeeze?  Still KVM?
> Yes, virtualized Windows works much better in (modern) KVM than Xen.
> 
> > 5) Do we recommend that new installations of lenny or of squeeze avoid
> > Xen for ease of upgrading to squeeze+1?  If so, what should they use?
> It depends. KVM in lenny is buggy and lacks important features. While it
> works fine for development and casual use I do not recommend using it in
> production for critical tasks.
> This is where Red Hat really beats us: RHEL shipped Xen years ago but
> recently they released an update which provides a backported and
> stabilized KVM.
> 
> > 6) Are we communicating this to Debian users in some way?  What can I do
> > to help with this point?
> Remind people that Xen is dying and KVM is the present and the future.
> 

As I understand the later mails of Bastian and Ian, this is probably not an
issue anyway, but still I'd like to note it: Even though KVM may have a
promising future (on hardware with virtualization support, at least), there is a
serious need for a nice migration path. It seems impossible to dist-upgrade to
squeeze and switch from Xen to KVM at the same time.

Thanks everyone,
Michael



pgph22ptMIHTL.pgp
Description: PGP signature

Re: Armel build admins?

[Michael Tautschnig]

> 
> I would like to request a rebuild of one of my package on armel. It built
> fine for last-5 to last-2 but both last-1 and last failed due to timeouts --
> I think ot simply tried to build on a smaller machine.
> 
> As I can never remember what the porter / admin group emails are -- where do
> I want to send this? debian-arm is the catch-all list and that is not what I
> want, methinks.
> 

[...]

See the last lines of

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

Best,
Michael



pgpItb4cse5T5.pgp
Description: PGP signature

Re: [RESENT] Re: Xen for Squeeze, 3.4 or 4.0

[Michael Tautschnig]

[3.4 vs. 4.0 ...]

> 
> Based on my experience with Xen I think that we should have both.  Then if 
> one 
> doesn't work we can try the other.
> 
> My impression of Xen stability is that trying two different versions and 
> hoping that one will work is a good strategy for any given server.
> 
> Bastian, thanks a lot for all your great work on this, it's very important to 
> me and to lots of other people!
> 

[...]

I have no idea how much work that is, but I do agree that having both versions
would be the optimal solution. Still, I completely understand that this likely
is infeasible given limited man power - but thank you very much for nicely
maintaining the Xen packages, I do truly enjoy using the packages in stable on
our servers without a single glitch!

Thanks a lot,
Michael



pgpgg3twMOIyS.pgp
Description: PGP signature

Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files

[Michael Tautschnig]

> On Tuesday 07 September 2010 12:02:38 Jean-Christophe Dubacq wrote:
> > What about using nc ?
> > nc -l  < /etc/passwd
> > 
> > http://localhost:/ => bingo.
> > 
> > We will probably not convince you, but there are way too many
> > alternatives to make the packaging effort worth the time.
> you convinced me, and i was well aware of that.
> But how can i convince someone with an apple that he has to download gcc and 
> compile nc or even worst convince someone with windows?

mich...@apple[12:50]:~$ uname -o
Darwin
mich...@apple[12:50]:~$ which nc
/usr/bin/nc

And, well, even a Windows version exists, see
http://en.wikipedia.org/wiki/Netcat#Variants

Best,
Michael



pgppAc17iV6IZ.pgp
Description: PGP signature

ClamAV supportability in stable release (was: Unidentified subject!)

[Michael Tautschnig]

Hi all,

(Dared to fix CC/Subject which seemed to be somewhat broken in initial email.)

> The release team have been asked to remove ClamAV from testing (and
> hence the next stable release. See bug #587058.
> 
> The issue seems to be that it's not supportable in stable due to the
> upstream maintainers deciding to upgrade their data files in a way that
> isn't binary compatable with previous versions.
> 
> A couple of options have been mentioned for what to do with this,
> including volatile. I'm opening this mail thread for discussion, and if
> no one comments then I'll go ahead and action the bug report in two
> weeks. For avoidance of doubt, this will also affect reverse
> depends, see dd-list below.
> 

[...]

Has there been feedback other than Christian's idea of adding a
kind-of-transitional package? Speaking as clamav maintainer, we'll happily
continue to upload to unstable, and if migration to testing (and stable) is
permitted - so be it, but the volatile-path seems to be a lot more promising and
future-proof. That said, the clamav ABI/API is surely stabilizing and hence
users of clamav packages from stable might be better off than before. But
there's no guarantee that they really get all the latest&greatest detection
capabilities. 

One clear volatile-only advantage is added cleanliness: No need to mess around
with different versions that actually are the same packages, and it just feels a
lot better if we can have a package in volatile only, and not in unstable as
well.

Best,
Michael



pgpA9ZtKYzQTd.pgp
Description: PGP signature

Re: ClamAV supportability in stable release (was: Unidentified subject!)

[Michael Tautschnig]

Sorry, debian-rele...@bugs.d.o really doesn't exist...

> Hi all,
> 
> (Dared to fix CC/Subject which seemed to be somewhat broken in initial email.)
> 
> > The release team have been asked to remove ClamAV from testing (and
> > hence the next stable release. See bug #587058.
> > 
> > The issue seems to be that it's not supportable in stable due to the
> > upstream maintainers deciding to upgrade their data files in a way that
> > isn't binary compatable with previous versions.
> > 
> > A couple of options have been mentioned for what to do with this,
> > including volatile. I'm opening this mail thread for discussion, and if
> > no one comments then I'll go ahead and action the bug report in two
> > weeks. For avoidance of doubt, this will also affect reverse
> > depends, see dd-list below.
> > 
> 
> [...]
> 
> Has there been feedback other than Christian's idea of adding a
> kind-of-transitional package? Speaking as clamav maintainer, we'll happily
> continue to upload to unstable, and if migration to testing (and stable) is
> permitted - so be it, but the volatile-path seems to be a lot more promising 
> and
> future-proof. That said, the clamav ABI/API is surely stabilizing and hence
> users of clamav packages from stable might be better off than before. But
> there's no guarantee that they really get all the latest&greatest detection
> capabilities. 
> 
> One clear volatile-only advantage is added cleanliness: No need to mess around
> with different versions that actually are the same packages, and it just 
> feels a
> lot better if we can have a package in volatile only, and not in unstable as
> well.
> 
> Best,
> Michael
> 




pgpOOv2RN3f3z.pgp
Description: PGP signature

Re: Is a bug RC relevant if it has an influence on the health of a person

[Michael Tautschnig]

[...]

> 
>   Here comes the bug: GNUmed will, given appropriate
>   circumstances, OVERWRITE the first allergy against Sugar.
> 
> Three years later, Debian 10 has been released and you
> return because of FatigueFromPackaging.
> 
> I prescribe Sugar, which usually helps against
> FatigueFromPackaging. Your EMR does NOT contain the allergy
> entry for Sugar anymore because it was overwritten by the
> allergy to Water.
> 
> You die in hospital because of a second anaphylactic
> reaction to Sugar.
> 
> Of course, medico-legally I am responsible.
> 
> However, didn't you wish we had discussed and solved this
> issue in Debian *today* ?   ;-)
> 

[...]

Although I do see the point of "harms people" missing in the description of
severities, *all* RC-level severities already seem to apply, given the above
description (quoting [1]):

- critical: "... or causes serious data loss, ..." (although internal to GNUmed,
  it does cause loss of a patient's data)
- grave: "makes the package in question unusable or mostly so, ..." (given the
  above description, it shall better not be used by any medic)
- serious: "... or, in the package maintainer's or release manager's opinion, 
makes
  the package unsuitable for release." (the easiest one: paste Karsten's
  description into a bug report and you're done)

Hope this helps,
Michael

[1] http://www.debian.org/Bugs/Developer#severities



pgp6cvgVWCgGp.pgp
Description: PGP signature

Re: strange failures on lxdebian and asdfasdf.debian.net for cmor

[Michael Tautschnig]

Hi Alastair,

I'm by no means a bsd expert and you actually might want to redirect your
question to debian-...@l.d.o instead.

> I've a strange issue: I've a perfectly ordinary package, cmor, which fails to 
> build on s390 and kfreebsd-amd64. In both cases it fails while trying to 
> build a test executable, ipcc_test_code, in the test target, but with 
> different errors in ld, segfault and abort.
> 
> Now, outside the buildds (lxdebian and asdfasdf) the package builds fine on 
> s390 and kfreebsd-amd64 (it fails on kfreebsd-i386, also in building 
> ./ipcc_test_code, but that appears to be different. While I don't understand 
> the failure yet, it is at least reproducible).
> 

[...]

Could you maybe, as first measure, try to make the build (or the build of tests
at least) way more verbose? Surely it's not ln -sf that aborts, but that is
about all that can be found in the build logs. I guess it would be nice to see
the full command line that is being executed such that precisely this step can
be investigated in more detail. As the tests (once they run) seem to be very
verbose, this should (a) help to nail down the error and (b) could possibly be
some problem with the terminal!? (The latter is a wild guess as I have no idea
what cmor really does.)

Hope this helps,
Michael



pgpdaVi4TSt5G.pgp
Description: PGP signature

Re: Bug#606543: clamav-freshclam: affected by privilege escalation vulnerability in logrotate

[Michael Tautschnig]

(CC'ed debian-devel as this was a not-so-well coordinated MBF without
announcement to debian-devel, dd-list, usertags; so maybe at least further
discussion can happen there)

Hi Florian,

[...]
> 
> These lines from this package's maintainer scripts suggest that it likely
> is affected by the vulnerability:
> 
> ---
> chmod 640 $FRESHCLAMLOGFILE
> chown "$dbowner":adm $FRESHCLAMLOGFILE
> ---
> 

What is wrong about these two lines? And even from ...

[...]

> For some further details please see my announcement of this mass
> filing on debian-qa:
> 
> http://lists.debian.org/debian-qa/2010/11/msg00024.html
> 
[...]

... I don't quite understand why this would be problem specific to one of the
packages you did the MBF for. If I get the idea of your exploit right, you
replace the log file by a symlink to a root-owned file, and in some mysterious
way you then seem to be able to overwrite the root-owned file. Well, it will
suffice for the evil person to be in adm group, you don't need to be $package
user for doing that.

But ok, you don't even claim there's a specific bug in our package, it's all
logrotate's fault. Assuming clamav uses logrotate in a sane way (I wouldn't no
of anyone claiming it does not), what should we do? Drop log rotation? Cool,
thanks, then the security-tagged bug report against clamav is actually justified
because it'll soon fill up your disk, possibly resulting in a DoS. Come up with
it's own cron-job for log rotation? No, thank you.

At present, the only thing I'd plan to do is to either reassign this bug to
logrotate or simply close it.

Best regards,
Michael



pgpx3y5WyWN24.pgp
Description: PGP signature

Re: Forthcoming changes in kernel-package

[Michael Tautschnig]

[...]
>c. his means there will be no need for /etc/kernel-img.conf file any
>   more.

[...]

Isn't this file also read in the postinst of the "official" kernels? In FAI we
had several issues when kernel-img.conf was missing or hadn't had the proper
values in there.

Best,
Michael



pgpuCuaKQ5MHq.pgp
Description: PGP signature

Re: deprecated server packages in lenny?

[Michael Tautschnig]

> 
> [Daniel Baumann]
> > although probably almost everyone already does, it's finally time to
> > drop nfs-user-server (nfs-kernel-server has got support for nohide).
> 
> When are host netgroups expanded by nfs-kernel-server?  I had the
> impression that only the user space server would expand the host
> netgroups used to control NFS exports when a mount request arrive,
> while the kernel NFS server would expand them when the exportfs call
> was done.  The latter do not work well for netgroups with changes done
> after the exportfs call.
> 
> I use the user space NFS server to make sure netgroups are expanded
> when the mounting happen, and not during boot of the server.
> 

My experience says that it is expanded at the time of the mount request (I keep
my netgroup entries in LDAP and I never had to do an extra exportfs call after
changing entries).

Best,
Michael



pgpmURjEzNrAo.pgp
Description: PGP signature

Re: Upcoming Section changes in the archive

[Michael Tautschnig]

> Bastian Blank wrote:
> > On Thu, Feb 26, 2009 at 09:07:35PM +0100, Joerg Jaspert wrote:
> > According to my knowledge of dak, the sections are global. Which means
> > that we don't have to worry about a possible kernel update for
> > lenny+1/2. Am I correct with that?
> 
> The sections are defined in the override files [1], which are per 
> codename. Special case is current testing (i.e. squueze), for which the 
> overrides are always kept the same as sid.
> 
> I assume the proposed changes would only affect sid + squeeze, not sarge 
> and lenny.
> 
> So you probably do have to worry about lennynhalf as that will introduce 
> new packages which should go in the current sections. So either they will 
> need to have the correct "old" sections in the control file, or the FTP 
> masters will have to correct them in the overrides file for lenny during 
> NEW processing.
> 

[...]

Seeing that the change of sections could pose some technical problems (not only
challenges implementing them) as well, let me ask one (possibly stupid)
question: Why do we need sections at all?

All that policy states is that it simplifies some handling of packages. If it's
about partitioning the archive into manageable components (some algorithm
traversing each component linearly or whatever), why not just group them by
source package names, as already done in other situations?

Thanks a lot,
Michael



pgpA8snxadbgM.pgp
Description: PGP signature

Re: net-tools future

[Michael Tautschnig]

> Holger Levsen wrote:
> > Hi Luk,
> > 
> > On Freitag, 20. März 2009, Luk Claes wrote:
> >> Below a list of packages/maintainers that use ifconfig/route/netstat:
> > 
> > How did you create that list? You seem to be missing a few..
> 
> By looking at dependency relations with the net-tools package. I guess
> some packages use net-tools if available and otherwise fallback to
> something else?
> 

In that case, Holger actually listed packages that lack proper Depends: ... :-)

Best,
Michael



pgpcH5Dh7YK49.pgp
Description: PGP signature

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Michael Tautschnig]

[...]
> 
> I'm unsure why we need *any* 32-bit libraries or binaries on an
> amd64 system.  If one needs to run 32-bit software, it is possible to
> debootstrap an i386 system and use it as a chroot.  Using a tool such
> as schroot handles all of the kernel personality and chroot details,
> and even allows normal users to use it with access to all their files,
> etc.  With a few one line scripts/shell aliases, it's completely
> transparent.  It also has the advantage of being a complete i386
> system rather than just a collection of libraries; you can keep it up
> to date using the usual tools, and even boot it if you desire.  i.e.
> you get all the normal security support and updates.
> 
> With multiarch, it's a different story, but we aren't quite there yet.
> 

My main use of 32-bit libraries is commercial software that is available for
32bit systems only. Yes, that's bad, but I can't do anything about that ATM. I'd
really hate to run (and maintain!) an additional chroot on each of those servers
just to run a single application. I do have i386 schroots on other systems, but
I prefer not to maintain that on each and every server. It might actually be a
bit of problem, because one of those commercial products is our backup
software...

Best,
Michael



pgpuxu7YoZpem.pgp
Description: PGP signature

Re: AVR32 port - config.{sub,guess} bug filing

[Michael Tautschnig]

> Hi,
> 
> As some of you may be aware, myself and a few others are working towards
> an AVR32 port of Debian, which is now making good progress. One problem
> we've come across is since AVR32 is such a new architecture, a fair few
> packages have config.{sub,guess} files that are missing the architecture
> and hence fail to build. Since things are coming along nicely now, I feel
> it might be appropriate to start filing wishlist bugs for these, but since
> there are quite a large number of packages with this problem, it could
> easily be regarded as mass filing. So I thought I'd ask here first for
> people's thoughts comments on this matter. Thanks.
> 

I guess the proper solution is copying config.{sub,guess} from /usr/share/misc/
and removing them in clean. If that is the case, wouldn't the list of possibly 
buggy
packages be [1]?

Best,
Michael

[1] http://lintian.debian.org/tags/outdated-autotools-helper-file.html




pgpq1GG7qv7ds.pgp
Description: PGP signature

Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff? (was: Re: phyml_20081203-1_powerpc.changes REJECTED)

[Michael Tautschnig]

> Hi,
> 
> On Montag, 27. April 2009, Philipp Kern wrote:
> > Interestingly you did it again, ignoring the list Code of Conduct.
> 
> As it sadly happens many times every day. And as long as there are no means 
> to 
> enforce it (either pure social or aided by technology), it will continue to 
> happen.
> 
> 
> regards,
>   Holger, who tries to mentally ignore being annoyed by cc:s but fails on 
> this
>   way to often...

If you're annoyed by cc:s (well, Holger, I know you are, you told me about that
more than once :-) ), configure your mailclient to set Mail-Followup-To and hope
for the next poster's mailclient to support that header. Which actually means
that, to a certain degree, those annoyed by cc:s could themselves do something
about it.

Best,
Michael



pgpZGOIZ69YuQ.pgp
Description: PGP signature

Re: UDD querying jobs on jenkins.d.n (was Re: inconsistent versions of M-A: same packages

[Michael Tautschnig]

Hi Holger,

On Sat, Nov 08, 2014 at 15:12:42 +, Holger Levsen wrote:
> Hi,
> 
> On Samstag, 8. November 2014, Holger Levsen wrote:
> > It would be trivial to turn this into a jenkins jobs, shall I?
> > 
> > It seems to me, there could be several other UDD querying jobs as well, so
> > my first suggestion for a name (+namespace) would be
> > "udd_multiarch_inconsistencies"... suggestions for other useful UDD queries
> > welcome! (Useful as in: having them run by jenkins every day/week and the
> > results displayed in some job...)
> 
> I've done this now, currently there are three jobs:
> 
> https://jenkins.debian.net/view/qa.debian.org/job/udd_sid_multiarch_versionskew
> https://jenkins.debian.net/view/qa.debian.org/job/udd_jessie_multiarch_versionskew
> https://jenkins.debian.net/view/qa.debian.org/job/udd_wheezy_multiarch_versionskew
> 
[...]
> If you have any ideas for further UDD querying jobs I'd be glad to hear them!
> 

Have you considered running a groovy script instead of an external shell script?
This may make things easier/avoid the external script dependency. Here's what
I'm doing:

manager.hudson.class.classLoader.addURL(new 
URL("file:///usr/share/java/postgresql-jdbc4.jar"))

import groovy.sql.Sql;

def sql = 
Sql.newInstance("jdbc:postgresql://public-udd-mirror.xvm.mit.edu:5432/udd", 
"public-udd-mirror", "public-udd-mirror", "org.postgresql.Driver")

def check_res = \
sql.firstRow("SELECT count(*) \
  FROM bugs INNER JOIN bugs_usertags USING (id) \
  WHERE bugs_usertags.email = 'm...@debian.org' AND 
bugs_usertags.tag = 'goto-cc'")
assert check_res.count != null && check_res.count > 0, 'Could not select any 
bug reports'

(and then some more SQL queries)

Best,
Michael




pgpfSmU1XaBud.pgp
Description: PGP signature

Re: "Blacklists" in BTS (stopping the trolls and bug machines)

[Michael Tautschnig]

> Hi,
> 
> I would like to ask what would be general opinion to add functionality to
> BTS to be able to blacklist[*] certain people from filling the bugs
> directly.
> 
[...]
> * - It doesn't have to be blacklist per se, it could be a queue which would
> be viewed by some fresher minds, who still doesn't have
> debian-burnout-syndrome. (Or maybe they should solve some complex problem
> before they can submit the bug :).
> 

How exactly should that be implemented? Our BTS (fortunately!!!) doesn't require
any login, so all you could use is the sender's email address. And people might
have plenty of these, valid ones even.

If you can identify candidates that you'd like to see blacklisted, why don't you
write a quick script so that you can just do

auto-reply-and-close 123456

(Yes, this has the advantage that a human must make the active decision to
ignore a bug or person.)

Best,
Michael



pgpgCS8ebGAB_.pgp
Description: PGP signature

Re: [clang] Report bugs on packages failing to build with clang

[Michael Tautschnig]

> Hello,
> 
> With the recent setup of the parallel build infrastructure using clang
> instead of gcc [1], I would like to start to report
> bugs on packages failing to build with clang (with patches if possible).
> The severity would be minor.
> Of course, I would do that only when the issue is upstream [2].
> 
> Any comments ?
> 
[...]

I think this will likely improve code quality, hence I'm much in favour of this,
in particular when it comes to outright bugs. But a non-negligible fraction of
the build failures, I believe, are due to the use of nested functions. This
could well be considered design decisions when used intentionally (unlike, e.g.,
[684508], where I have already filed a bug). I'm not sure whether upstream will
be very keen on such bug reports?

Best,
Michael

[684508] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684508



pgpM3qGEM9EXP.pgp
Description: PGP signature

Re: [clang] Report bugs on packages failing to build with clang

[Michael Tautschnig]

Hi Sylvestre,

[...]
> I started to report them (with patches for now) with minor as severity:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=clang-ftbfs;users=pkg-llvm-t...@lists.alioth.debian.org
> 

You might want to take a look at

http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=m...@debian.org&tag=goto-cc

as quite a few more could deserve a usertag of yours, much like you already did
for aconnectgui. At least I can see the bugs filed against

coriander
cdecl
tpb
ax25-tools
pcp
r-cran-xml

are causing build failures with clang as well.

Best,
Michael



pgph3YKnJU7CH.pgp
Description: PGP signature

Re: Re: Candidates for removal from testing (2013-06-04)

[Michael Tautschnig]

> Hi,
> 
> > On Wed, Jun 05, 2013 at 09:37:54AM +0900, Charles Plessy wrote:
> > > Le Tue, Jun 04, 2013 at 02:06:26PM +0200, Niels Thykier a écrit :
> > > >
> > > > Our automated tools for finding RC buggy leaf packages in testing have
> > > > found 79 potential candidates (see attached files).
> > > >
> > > > The packages have been selected based on the following criteria:
> > > >  * The package had at least one RC bug without activity for the past
> > > >14 days.
> > > >  * If a bug is assigned to multiple packages, both packages will be
> > > >affected.
> > > >  * The RC bug affects both unstable and testing.
> > > >  * The affected package does not have any reverse dependencies in
> > > >testing.
> > >
> > > Thanks a lot.
> >
> > +1
> 
> I also like it, somewhat, but am also aware of this approach rendering
> unstable more stable than testing. I would prefer another kind of punishment
> for neglect / some difficulty than the mere removal.
> 
[...]

In what way exactly would this effort even affect unstable? Note that this is
about removal from *testing*, thus should rather remove the number of bugs in
testing, not necessarily in unstable!?

Best,
Michael



pgpOdFpVaowil.pgp
Description: PGP signature

Re: [clang] Report bugs on packages failing to build with clang

[Michael Tautschnig]

[...]
> > clang.debian.net lists 39 instances of these, though I think the buildd
> > is a bit behind so there are probably a few more.
> 
> At least one more of the 432 "Not categorized" is also due to this
> missing feature in clang (reprepro). As clang seems to gives quite
> misleading error messages in this case, I'd not be surprised if there
> are some more.
> 

Here is my list of those (manual filtering of the results documented at
https://github.com/tautschnig/cprover-debian/blob/master/result-notes/notes);
note that at least two cases are nested functions in the configure check, which
generally is harder to see when looking at the build logs only.

- busybox: nested functions
- cadabra: nested functions
- clutter-gesture: nested functions
- gpm: nested functions
- grub: nested functions
- gwc: nested functions
- idjc: nested functions
- lxc: nested functions
- qxw: nested functions
- reprepro: nested functions
- systemtap: nested functions
- tdb: nested functions in configure check
- tevent: nested functions in configure check
- win32-loader: nested functions
- zvbi: nested functions

Best,
Michael



pgpUrIYCIMy9h.pgp
Description: PGP signature

Re: jessie release goal: verbose build logs

[Michael Tautschnig]

> On 14/06/2013 13:49, Wookey wrote:
> > +++ Matthias Klose [2013-06-14 13:35 +0200]:
> >> Much more often than I do like it, I see bug reports for the toolchain just
> >> pointing to a build log.  Then looking at the build log, you often just see
> >>
> >>  CC ...
> >>  CCLD ... (sometimes even colorized)
> >>
> [...]
> > I'll second this. Like Doko, I've spent way too much time recently(ish)
> > staring at build-logs. The short-form build logs are often useless for
> > working out why something isn't working, or comparing successful
> > native builds with failed cross builds, for example.
> Same as Wookey. This would save me some time working on the analysis of
> rebuilds with clang.
> 

Late, but still: I am also very much in favour of this, as the lack of full
command lines has already caused quite a bit of overhead in my experiments with
our goto-cc compiler infrastructure.

Best,
Michael



pgp8GGKBTjSqy.pgp
Description: PGP signature

Re: Reporting 1.2K crashes

[Michael Tautschnig]

Hi Alexandre,

Many thanks for this effort, this sounds really interesting.

[...]
> You can download the list of affected packages, with their maintainers
> [3], generated with dd-list, as well as a sample bug report for
> gcov-4.6 [4]. The bug report contains:
>   1) the bug report that will be mailed to mainto...@bugs.debian.org
> (report.txt)
>   2) a testcase reproducing the crash in ./crash/
>   3) information about the crash in ./crash_info/: a core dump (core),
> the output of the crash (crash_output.txt), the dmesg of the crash
> (dmesg.txt), as well as the exit status (exit_status.txt).
> 
> This is a lot of bugs, and we want to make sure we're doing bug
> reports right, so that we don't make anyone angry by spamming the BTS
> with bad reports. Please let us know if the reports are good enough to
> proceed with the filing, or if any additional information should be
> included in the report.
> 
[...]

Can one also access, even before you go and file bugs, information for other
packages? I cannot actually find any reports for the package listed in the
dd-list under my name in your Packages, Runs, nor Programs pages. (And the fact
that the reported package is a transitional package does make this a little
suspicious.)

Thanks a lot,
Michael



pgpX26_Kkm0Tn.pgp
Description: PGP signature

Re: Reporting 1.2K crashes

[Michael Tautschnig]

Hi Alexandre,

(Just replying regarding the point I had raised.)

[...]
> > Can one also access, even before you go and file bugs, information for other
> > packages? I cannot actually find any reports for the package listed in the
> > dd-list under my name in your Packages, Runs, nor Programs pages. (And the 
> > fact
> > that the reported package is a transitional package does make this a little
> > suspicious.)
> 
> The reports are not public yet. Since you are a developer included in
> dd-list, we will send you an email containing the crash information
> for the programs you are developing. You will receive the email 1 week
> before the crash is submitted to the BTS. Does that sound reasonable?
> 
[...]

Sounds great, yes!

Looking forward to receiving detailed information,
Michael



pgpk83WzPlWWU.pgp
Description: PGP signature

Re: Reporting 1.2K crashes

[Michael Tautschnig]

> BTW,  the mails you have been sending with links to the crashes have
> been going to publicly archived lists, not sure if you meant for that
> to happen though?
> 

I don't think the Mayhem team is at all to blame for that: we seemingly simply
don't have the necessary information in place.

For mass bug filings with potential security implications, we'd need some
Maintainer-private field in our control files. I think it is simply impractical
to go and ask for those people doing the MBF to take a look at each package to
figure out *manually* which address to use for private contact.

In a similar vein, also machine-readable information about upstream contact
points would be useful for MBFs that relate to upstream issues (such as this
one).

Best,
Michael



pgpQ9gqk7tKJj.pgp
Description: PGP signature

Re: Innovation in Debian

[Michael Tautschnig]

> On Mon, Jul 22, 2013 at 04:39:54PM +0100, Michael Tautschnig wrote:
> > [...]
> > 
> > I feel the subject of this thread is not very well aligned with your 
> > reasoning -
> > I don't think innovation==breaking things!? At least for myself the init 
> > system
> 
> I very much disagree.
> 
>"Without deviation from the norm, progress is not possible"
> 
> Alas, most of the time, with software, deviation means
> incompatibilities. Not everything can be transitioned gracefully.
> Absolutely so in the early days of work, which is when we need this
> most of all.
>

I do see that some innovative ideas cause breakage. And sometimes breaking
things may result in progress. All I was saying is that innovation and breaking
things are not the same. In an ideal world, people would come up with innovative
ideas, think them through, and then come up with a plan that breaks as little as
possible. (No, we don't live in an ideal world.)

> As a result, people refuse to embrace progress for fear of "breaking
> things", or not being able to back the change out. Re-read some of the
> recent threads.
> 

I get your point.

> > is a particularly bad example: I have quite a while ago stopped following 
> > that
> > thread as the noise/information ratio was way too high for a sub-system I 
> > don't
> > necessarily care about (I just need *some* working init).
> > 
> > To re-iterate: are you worrying about innovation or about a lack of 
> > interest in
> > breaking things?
> 
> I don't think there's a lack of interest in innovating. I just don't
> think we have a way to do it without putting thumb-screws on excited
> people, and weighing them down.
> 

I tend to disagree, but I don't have any hard facts to back up my claim.
Therefore I'll go with your example:

> Personally, with desktop-base, I want to split the package to allow for
> more correct dependencies. I want to try this split out, and see how it
> works on a real system.
> 
> Here's the process:
> 
>   - Get a server
>   - Set up dak (ok, really reprepro would be fine, but I'm making a
> point)
>   - Set up wanna-build
>   - Get some build boxen
>   - Upload new desktop-base with changes
>   - "NMU" packages in the archive to work with the new packages in the overlay
>   - Fiddle with it
>   - Push work back to Debian main
> 
> This is stupid. I don't want to screw with servers to try out some
> ideas.
> 
> I want the process to be something like:
> 
>   - New PPAMAIN
>   - Upload new package
>   - "NMU" packages to work with the new stuff (this needs to be
> something that the project is OK with) inside the PPA
>   - Fiddle
>   - Push it back up
> 
> Screwing with setting up servers is absurd. I just want to hack. I don't
> want to maintain the archive. I don't want to maintain the servers. I
> don't want to support build boxen.
> 

May I dare to say you are lacking innovation here? Look at what Mika did in his
kantan project (http://grml.org/kantan/). No, he did not stick his head in the
sand when working towards testing grml. But actually all you need is a virtual
machine. Or maybe not even that: just use

http://collab-maint.alioth.debian.org/debtree/

which won't even require a single package build. Just look at (or automatically
analyze) the output.

> We need to find a way to get the "boring" stuff out of the way for
> people excited about change, and not try to box them into non-breaking
> changes only while they work out the kinks.
>
[...]

I fully agree with this point, but at the same time I'd hope that people go the
might-break-things route only once they thought about it. Breaking things out of
plain laziness is not acceptable.

> Yes, this is about breaking things. We can't restrict innovation to
> non-breaking changes. By letting DDs break things in a little corner,
> there's a good chance that this helps come up with a *real* transition
> plan that prevents breakage on real machines.
> 
> Either way, semantics, IMHO,
>Paul
> 

When (potentially) breaking things is the only way to achieve progress in a
particular sub-project then this shall be ok. (Obviously a comment I should be
making in other threads and likely there will be people who disagree.) But
*please* don't push for a routine of breaking things as a general means towards
progress. As I tried to show for your example above: there may be other
solutions to a problem, and these may even be more efficient. This isn't
anyone's personal sand-pit, so please be considerate of both users of fellow
DDs by putting in a reasonable amount of effort to think about safer solutions.

Best,
Michael



pgpdL18Apujnz.pgp
Description: PGP signature

Re: Innovation in Debian

[Michael Tautschnig]

Hi Paul, hi all,

> Ahoy, fellow developers,
> 
> 
> Having followed the recent threads, I've been growing concerned - not of
> sticking with an old init system, or switching to a new one, or even the
> god-aweful tone of every damn post on that thread (srsly guise).
> 
> I'm mostly concerned that we, as a project, have a *hard* time trying
> out big, breakey things -- I know, we're Debian, we're stable, I get
> that.
> 
[...]

I feel the subject of this thread is not very well aligned with your reasoning -
I don't think innovation==breaking things!? At least for myself the init system
is a particularly bad example: I have quite a while ago stopped following that
thread as the noise/information ratio was way too high for a sub-system I don't
necessarily care about (I just need *some* working init).

To re-iterate: are you worrying about innovation or about a lack of interest in
breaking things?

Best,
Michael



pgpboi9qipK1j.pgp
Description: PGP signature

jenkins vs. debile [was: Re: Bits from the Release]

[Michael Tautschnig]

Hi Zack, hi all,

> On Sun, Aug 25, 2013 at 05:09:22PM +0200, Niels Thykier wrote:
> > How you can help (NEW-TEST-HELP)
> > 
> > 
> > Add tests to your packages.  The full specification for these tests
> > are available from [AUTOPKG].  If you need inspiration, consider looking
> > at some of the existing autopkgtests[FIND-AUTOPKG].
> > 
> > We need to have the autopkgtest tests run.  Holger Levsen suggested
> > that jenkins.debian.net has the necessary hardware to support these
> > tests.
> > 
> > Asheesh Laroia has kindly spent some time during DebConf13 researching
> > and experimenting with setting up such jobs.
> 
> So, in the context of work to periodically run various sorts of static
> analysis tests on Debian packages [1], we (myself, Sylvestre Ledru, Léo
> Cavaillé, and Matthieu Caneill) have considered using Jenkins.  Based on
> feedback from Matthias Klumpp and his experience in using Jenkins for
> Tanglu, we have concluded that it didn't really scale to the point that
> we needed (number of Debian packages * number of checkers). We ended up
> using Paul Tagliamonte's debile infrastructure [2].
> 

Would you/Matthias be willing to share the feedback on jenkins more widely? I do
presently run a system with ~60,000 jobs, and, yes, this is probably somewhat
beyond what jenkins was meant to scale to. Yet jenkins does have the practical
advantage of being widely used, with lots of plug-ins, and being well
documented. Not all of this seems to be the case for debile at present...

> I don't doubt that jenkins.d.n can be leveraged for the time being,
> giving the low amount of autopkgtests currently available. But you might
> want to check with Matthias or similar experiences before committing to
> using Jenkins for this.
> 
[...]

I'd be happy to contribute mine as well, and one of the key points seems to be
the level of interaction/user control people are looking for.

Best,
Michael



pgpEf4uH71ZyW.pgp
Description: PGP signature

Comments+blank line in debian/control: Clarification in policy or MBF?

[Michael Tautschnig]

Hi,

While rebuilding our archive using pbuilder I noticed that all packages
build-depending on gnome-pkg-tools failed to build. That led me to filing
#684503, which I'll quote here for convenience:

| The file control.header ends with an empty blank line. As the contents of that
| file is prepended to debian/control for packages making using of
| gnome-pkg-tools, this results in
| 
| 
| 
| 
| 
| By policy, blank lines separate paragraphs, comments are discarded, so we end 
up
| with an empty first paragraph. Policy, however, requires that the *first*
| paragraph contains essential package information (Policy 5.2).
| 
| The current setup breaks at least pbuilder's build-dependency parsing, which
| relies on this fact.
| 
| If you believe that an empty first paragraph should not be considered a
| paragraph, please reassign to policy, asking for clarification that it's the
| *first non-empty* paragraph.

Ubuntu have fixed this bug in their version of gnome-pkg-tools already, but:

- the problem affects all packages *build-depending* on gnome-pkg-tools, thus
  I'd actually have to do an MBF (it's more than 160 packages)
- some other packages also contain comments and a blank line before the actual
  contents in debian/control (so at the very least I should be filing bugs
  against these as well)
- it seems only pbuilder is really strict in its interpretation of policy here,
  but effectively that means that all our other build infrastructure doing
  parsing of debian/control is *not* policy-compliant

Taking a pragmatic position, it would be best to have policy acknowledge the
fact that empty paragraphs don't count, and get the parser in pbuilder fixed.

Opinions would be much appreciated.

Best,
Michael



pgpmV8s6JWNA3.pgp
Description: PGP signature

Re: Comments+blank line in debian/control: Clarification in policy or MBF?

[Michael Tautschnig]

> Le lundi 01 octobre 2012 à 14:43 +0100, Ian Jackson a écrit : 
> > This wouldn't help people doing backports or whatever.  I think this
> > should be fixed in the packages involved.
> 
> Changing gnome-pkg-tools to replace the blank line with an empty comment
> is trivial. In unstable.
> 
> How does that help with backports?
> 

If gnome-pkg-tools were backported, any further backport build-depending on
gnome-pkg-tools would get fixed.

I think it is fair to say that this is a policy violation, but it clearly isn't
a *serious* policy violation, given its limited practical effect. I would ask
GNOME maintainers to get this fixed and uploaded, ideally also into t-p-u.

I'm going to file bugs against those packages not build-depending on
gnome-pkg-tools, but still containing comment+blank line at the start of
debian/control.

For all those packages build-depending on gnome-pkg-tools, I could then liaise
with the GNOME team to determine the best way forward.

Best,
Michael



pgpeJZMmzoRBc.pgp
Description: PGP signature

Re: Comments+blank line in debian/control: Clarification in policy or MBF?

[Michael Tautschnig]

> Le Mon, Oct 01, 2012 at 11:00:54PM +0200, Jakub Wilk a écrit :
> > * Michael Tautschnig , 2012-10-01, 14:25:
> > >>By policy, blank lines separate paragraphs, comments are
> > >>discarded, so we end up with an empty first paragraph. Policy,
> > >>however, requires that the *first* paragraph contains essential
> > >>package information (Policy 5.2).
> > 
> > I'm not convinced by this interpretation the Policy. Common sense
> > tells me that there's no such thing as "empty paragraph". So the
> > question is: are empty liens allowed at the beginning of a control
> > file?  I don't see an answer to that question in the Policy,
> > unfortunately.
> 
> Indeed, the Policy does not consider that case.
> 
> This said, the format of the control data files is inspired from the RFC822,
> which contains the following in its section 4.1:
> 
>  message =  fields *( CRLF *text )   ; Everything after
>  ;  first null line
>  ;  is message body
> 

If there is consent that we stay close to RFC822, then I read this as "there
must not be a blank line (CRLF) before the essential package information.

> Another important factor for the Policy is the "current practice".  Before
> proposing that empty lines are allowed or disallowed in control data files, I
> think that we would need to survey what is done in Debian.  For instnace, is
> gnome-pkg-tools an outlier, are there tools tolerating initial empty lines on
> purpose, what is the situation for other control data files, etc.
> 
[...]

I do not yet have data covering the entire archive, only arch:any packages for
letters a-p have been rebuilt so far. For that fraction (12915 out of 17369
packages), we have 184 packages broken by gnome-pkg-tools (including
gnome-pkg-tools itself) and only 3 other packages that have comments and a blank
line in there.

But then either all build infrastructure (and also lintian) don't use
debian/control, or all these tools tolerate that blank line (with the exception
of pbuilder).

Best,
Michael



pgpJ8RPP1GSRs.pgp
Description: PGP signature

Re: Comments+blank line in debian/control: Clarification in policy or MBF?

[Michael Tautschnig]

> On 2012-10-03 11:01, Michael Tautschnig wrote:
> > [...]
> > 
> > But then either all build infrastructure (and also lintian) don't use
> > debian/control, or all these tools tolerate that blank line (with the 
> > exception
> > of pbuilder).
> > 
> > Best,
> > Michael
> > 
> 
> Lintian's parser ignores empty lines before/between paragraphs.
> 

I suppose that piece of code is quite dated. Is there a way to figure out why
lintian does this, i.e., who decided to interpret policy in this way?

Best,
Michael



pgpl1qb3gDWFc.pgp
Description: PGP signature

Re: dput-ng/1.1 in unstable

[Michael Tautschnig]

Hi,

> As we recently announced [1], we have been working on a complete
> re-implementation of dput [2]. As of today, the package is available in
> Debian Unstable [3] ready for early adoptors.
> 
[...]

What are the chances of dput-ng becoming available in backports (well, once we
release, backported to wheezy at least)?

Thanks a lot,
Michael



pgpQK5vIhEnBe.pgp
Description: PGP signature

Re: Bootstrapping: list of 81 self-cycles in Debian Sid

[Michael Tautschnig]

Hi,

[...]
> CPU:
> 
> The whole script producing the output above took 7 hours to run on a 2.5GHz
> Core i5 for all suites and all architectures (38 combinations). This is 
> because
> generating strong strong dependencies for all packages in the archive takes
> 8-10 minutes with current archive sizes.  I dont think this value can
> considerably be lowered. On the other hand, the cron job doesnt have to be run
> every day but maybe once a week or once a month?
> 
[...]

What about parallelizing parts of the job? It might be possible compute strongly
connected components of the graph first, and then do the job for each component?

Obviously this doesn't reduce CPU time, but wall clock time might be more
interesting indeed.

Best,
Michael



pgpwcfd8UddXn.pgp
Description: PGP signature

Re: Open Source Survey - http://goo.gl/5bwR9t

[Michael Tautschnig]

> Thorsten Glaser  writes:
> 
> > Jonas Smedegaard  jones.dk> writes:
> >
> >> Quoting Michael Kaserer (2014-01-08 11:00:50)
> >> > We are two students currently working on a research project regarding 
> >> > motivation for contributing to Open Source projects. You can help us 
> >> > by filling out the following web-survey, it only takes max. 2 minutes!
> >
> > The survey asks which of the reasons is the most important one,
> > but one cannot choose the free-form “other” reason there, and
> > this is a mandatory field.
> 
> Funny that -- I specified an "other" option too, and would have selected
> that as my main reason if given the chance.
> 

Same here.

> The available options seem to say more about the assumptions of the
> researcher, than being likely to provide interesting data.
> 

I kept waiting for a free-form field to appear in order to help the researchers
with some (entirely subjective) notes about their assumptions. But unfortunately
there wasn't any such field (and neither any contact-the-authors link).

Have fun,
Michael



pgpdpFm75qbSq.pgp
Description: PGP signature

Re: Debian source packages file types and SLOC

[Michael Tautschnig]

Hi Jan,

>it's a too big a job to do by myself, and maybe the answer already exists:
> 
>When I would download all Debian source packages, extract them, determine
> of each the programming language it is written in and the SLOC, what would be
> the percentages of each programming language used?
> 
[...]

While zack already provided you with much more detailed instructions to
obtaining up-to-date information, you might find

http://blog.james.rcpt.to/2012/02/13/debian-wheezy-us19-billion-your-price-free/

useful to get an overview without extra effort.

Best,
Michael



pgphTGgBrq60J.pgp
Description: PGP signature

Re: Proposing amd64-hardened architecture for Debian

[Michael Tautschnig]

On Sat, Apr 19, 2014 at 14:26:59 +0300, Riku Voipio wrote:
[...]
> Riding the Heartbleed publicity wave seems unwise, unless you can
> propose a hardening flag that would have protected users from
> Heartbleed. Else, Heartbleed merely serves on a example
> how wallpapering problems over with "hardened" binaries often
> doesn't help you at all..
> 

+100 on this one. Hardening may be nice, but wouldn't have helped at all w.r.t.
Heartbleed (or any of the other recent SSL/TLS issues).

> Considering that most issues protected by compiler hardening are
> also detectable by static/dynamic code analysis, a more effective security
> measure would be to spend time with clang static analyzer, valgrind, trinity
> and other tools... or actualy reviewing patches that security critical
> projects recieve.
> 

Or maybe even just enable -Wall when compiling and take compiler warnings
seriously (plus explicitly silence the ones you are entirely sure they are
spurious). I wish people did that, it would so much help even starting static
analysis efforts as it helps rule out all the code that static analysis cannot
formally reason about due to its inconsistencies in typing. See [1] for some of
those - if only I had more time, I'd be reporting lots more that are still on my
stack for review. And I haven't even started reporting missing include files
(and thus missing declarations). I will propose an MBF for that as soon as time
permits.

Best,
Michael

[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=m...@debian.org&tag=goto-cc



pgpfve1WAfSgn.pgp
Description: PGP signature

Re: Gcc and undefined behavior

[Michael Tautschnig]

On Mon, Apr 28, 2014 at 16:45:56 +, Thorsten Glaser wrote:
> Shachar Shemesh  debian.org> writes:
> 
> > the changes there is a runtime check for undefined behavior. Just
> > compile with -fsanitize=undefined, and your program will crash with
> > log if it performs an operation that C/C++ considers to be
> > undefined.
> 
> This does not help. At all.
> 
> Consider:
> 
> • all possible codepaths
> 
>   ×
> 
> • all possible combinations of input/state data
> 
> Even “just” checking mksh would not work, for example.
> Let alone OpenSSL.
> 
> Plus, crashing in a screensaver is bad :D
[...]

So are we really at a point where we need all the en-vogue techniques applied to
each and every package in our distribution? Shouldn't we maybe first sort out
some basic problems that the compiler tells us about at no run-time cost? I was
slightly in shock when I realised the length of the list at

http://qa.debian.org/bls/bytag/W-implicit-declaration.html

knowing that bugs such as #702889 would have been caught by the compiler. (And
anyway missing function declarations imply a chance of undefined behaviour as
per 6.5.2.2, paragraph 10 of ISO C11.)

I'm not saying that there aren't any packages benefiting from
hardening/sanitisation flags, but type checking and data-flow analyses built
into current compilers could do a very decent job already *if only people paid
attention to warnings*. And doing static analysis (which, by the way, is a key
approach to combat the combinatorial explosion outlined by mirabilos) beyond
what compilers do as part of their job will require that the most basic
inconsistencies be ironed out first.

Best,
Michael



pgpIHz4zify2L.pgp
Description: PGP signature

Re: Bits from the Release Team - Kicking off Wheezy

[Michael Tautschnig]

Hi all,

[...]

> # package quality
>   Advocate: Holger Levsen and Luk Claes
>   State: confirmed
>   Wiki: http://wiki.debian.org/ReleaseGoals/PackagesQuality
> 
> This is a never ending goal of sustaining our packages quality by
> improving our tests and following up closely... so needless to say that
> I would still advocate this one.
> 
[...]

I would advocate the idea behind this goal as well, yet I think as-is this isn't
a very useful goal: how would we ever measure its achievement? To this end, I
think, we need to give a much more precise definition of how we intend to
measure "quality". For instance, we could fix lintian version x.y.z and state
that we want to have 0 errors at the time of release. Similarly for piuparts. Or
a bugs per package ratio. All of these are measurable and can be checked for,
although of course they only give a very limited notion of "quality". 

Best regards,
Michael



pgpxqPAt78sbC.pgp
Description: PGP signature

Re: Bits from the Release Team - Kicking off Wheezy

[Michael Tautschnig]

[...]
> • Read-only root
> 
>   Depends on /run.  Having /run will allow remaining writable files
>   under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters).
>   Identifying and fixing/removing packages writing to /etc during
>   their normal operation would be a worthy release goal.
> 
>   This will make Debian more secure to run, easier to deploy in a
>   cluster or netboot environment (no writable image overlay required),
>   keeping dpkg-managed filesystems completely read-only during normal
>   operation (other than /var).
> 
[...]

Here's an obviously incomplete list of such files, from a fairly comprehensive
desktop installation. I've taken these from my integrit configuration for a
lenny (!) system - I'd love not to be in need for such a list of exceptions.

/etc/aumixrc
/etc/mtab
/etc/motd
/etc/adjtime
/etc/resolv.conf
/etc/qt3/qt_plugins_3.3rc
/etc/network/run/ifstate
/etc/hotplug/.run/net.enable
/etc/cups/ppd/
/usr/share/ppd/custom/
/etc/cups/classes.conf
/etc/cups/printers.conf
/etc/cups/printers.conf.O
/etc/cups/cupsd.conf
/etc/printcap
/etc/lvm/cache/.cache
/etc/openvpn/openvpn-status.log
/etc/blkid.tab
/etc/blkid.tab.old
/etc/samba/dhcp.conf
/etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)

Hope this helps,
Michael



pgpnWeuDOjbXO.pgp
Description: PGP signature

Re: combined dependencies?

[Michael Tautschnig]

Hi Harri,

> would it be possible to support combined dependencies,
> e.g. if package A and B are installed, then package C(A)
> has to be installed, too?
> 
> That might be helpful for dkms packages, for example.
> A would be the kernel, B the dkms package, and C(A)
> would be the headers for A.
> 

What event would induce installation of C(A)?! Let's assume neither A nor B are
installed.

apt-get install A
  (no point installing C(A))
apt-get install B
  (B does not depend on C(A), otherwise this discussion is pointless)

  ... time passes ...

magic install C(A)
  ???


Isn't all you want a hard dependency of dkms on both the Linux kernel and its
header package? It seems that right now this is just a Recommends. Could you
maybe elaborate why a proper Depends: is not appropriate in your opinion?

Best,
Michael



pgpP8iIHfD9Qf.pgp
Description: PGP signature

Re: combined dependencies?

[Michael Tautschnig]

Hi all,

[...]
> 
> No, you can't install B without C(A) if A is installed, that's the whole
> point of conditional dependencies.  Thus at the second command apt would
> pull in C(A) or throw an error if it's uninstallable.
> 
> If A is installed, B gains Depends:C(A).
> If B is installed, A effectively gains Depends:C(A).
> If you try to install A and B in one go, C(A) will go in as well.
> If you try to uninstall C(A), either A or B has to be uninstalled.
> 
> The semantics are pretty obvious to me, it's the number of corner cases and
> complexity that this brings what stops dpkg/apt/aptitude/100-other-tools
> maintainers from implementing that.
> 

Propositional logic doesn't have too many corner cases. The problem is simply
that people don't even get current Depends right, introducing additional
expressiveness will worsen the situation.

> 
> (Let's rename "C(A)" to "C" for now, the former name makes no sense except
> when talking about dkms.)
> 
> Logically, what you want is: !(A & B & !C)
> 
> This is: C | !A | !B
> 

Correct NNF rewrite, but the first expression is wrong already. Sort of confirms
my above statement. All you say with this is expression is one case you don't
want to occur (it's the "If you try to install A and B in one go, C(A) will go
in as well." case). It would, however, be satisfied by installing C only, or B
and C for that matter.

> Technically, you could already get this effect by introducing a dummy
> package no-B that "Breaks: B" and having A "Depend: C | no-B".
> 
> In the case of dkms, there's one dkms and many kernels so B=dkms, A=kernels.
> Too bad, linux-image-$FOO depending on linux-headers-$FOO|no-dkms would be
> too ugly to live.  Just think of confusing messages from apt...
> 
> This could be done by no-B being a new kind of a virtual package, but I for
> one don't volunteer to code that.
> 

I'm still wondering why people are so hesitant to write proper Depends: lines.
I'll reply to Harri's email to reiterate that.

Best,
Michael



pgpxcK2fKUGXN.pgp
Description: PGP signature

Re: combined dependencies?

[Michael Tautschnig]

Hi again,

[...]
> 
> B _does_ depend on C(A), if A is installed.
> 

So B depends on

 ( A & C(A) ) | something-else

> > ... time passes ...
> > 
> > magic install C(A) ???
> > 
> > 
> > Isn't all you want a hard dependency of dkms on both the Linux kernel and 
> > its header package? It seems that right now this is just a Recommends. 
> > Could you maybe elaborate why a proper Depends: is not appropriate in your 
> > opinion?
> > 
> 
> Its not any header package: dkms needs the _appropriate_ header
> package matching the installed kernel package. If
> linux-image-2.6.39-1-amd64 is installed, then dkms needs
> linux-headers-2.6.39-1-amd64.  If linux-image-3.0-1-amd64 is
> installed in parallel, then dkms needs linux-headers-3.0-1-amd64,
> too.
> 
> Its just an example, anyway.
> 

Isn't all you want (with l-i-1 = linux-image-2.6.39-1-amd64, l-h-2 =
linux-headers-3.0-1-amd64, etc.)

Depends: (l-i-1, l-h-1) | (l-i-2, l-h-2) | ...

And yes, that's not allowed. You need to convert that to CNF. Doable, but
results in a blow-up of the expression size. Hence what you want is

Depends: dkms-l-1 | dkms-l-2

with additional (almost empty) packages dkms-l-1 for 2.6.39 and dkms-l-2 for
3.0.1, where

Package: dkms-l-1
Depends: l-i-1, l-h-1

Package: dkms-l-2
Depends: l-i-2, l-h-2

Best,
Michael



pgp3HfrEUq7iQ.pgp
Description: PGP signature

Re: Status of circulars dependencies in unstable

[Michael Tautschnig]

[...]
> 
> The problem is that perl and perl-modules really are one package that was
> split apart solely to get the (large) architecture-independent parts into
> an arch: all package.
> 

Wouldn't this problem be solved by moving the contents of perl to, e.g.,
perl-bin, making perl a dummy package, and the following relations:

Package: perl
Depends: perl-bin, perl-modules

Package: perl-bin

Package: perl-modules
Depends: perl-bin (= ${Source-Version})


But this solution seems so simple that I must be missing something.

Best,
Michael



pgpfIHsu1bOyC.pgp
Description: PGP signature

Re: ArchitectureSpecificsMemo

[Michael Tautschnig]

On Thu, Nov 27, 2014 at 10:50:26 +, Edmund Grimley Evans wrote:
> http://wiki.debian.org/ArchitectureSpecificsMemo
> 
> Some suggestions for improving this table:
> 
> 1. About half of the table is taken up with sizeof information, some
> of which could be expressed more concisely. (Are all Debian
> architectures ILP32 or LP64? Any rare exceptions could be described in
> a footnote.)
> 
> 2. Perhaps it would be better to reverse the axes, particularly if the
> sizeof information is simplified and as more and more architectures
> are added.
> 
> 3. A link to a list of system calls might be useful for some people.
> 
> 4. I'd like to see some information about va_list added as this
> sometimes causes portability problems. For example:
> 
> On amd64, va_list is a (struct { ... } [1]) with size 24 and alignment
> 8. (It's an array, so it turns into a pointer in some circumstances.
> You can test whether a va_list is equal to zero, for example.)
> 
> On arm64, va_list is a (struct { ... }) with size 32 and alignment 8.
> (It's not an array. You can't test whether it's zero.)
> 
> On armhf, va_list is a (struct { ...}) with size 4 and alignment 4.
> (Have I got that right?)
> 
> On i386, va_list is a (char *).
> 
> Any thoughts? Vehement objections?
> 

As this is one of the wiki pages that I visit most often: I'd completely agree,
and addition it would be very useful if the macros defined by compilers we use
(GCC, and maybe Clang) to test for a particular architecture were listed as
well. (Yes, we're in do-ocracy, so I should just go and add these...)

Best,
Michael



pgpLAeL93Fj4X.pgp
Description: PGP signature

Re: mkdocs locale error building djangorestframework

[Michael Tautschnig]

On Tue, Jan 26, 2016 at  1:23:19 +, Ben Hutchings wrote:
> On Tue, 2016-01-26 at 12:16 +1100, Brian May wrote:
> > Ben Hutchings  writes:
> > 
> > > That's not the problem at all.  Read the error message again.  Read the
> > > source line it points to.  Now look at where rv comes from:
> > 
> > Yes, that is how it would appear.
> > 
> > However, all this code does is try to work out the appropriate fatal
> > error message that should get displayed.
> > 
> > i.e. we should never have executed this code in the first place.
> > 
> > (I did file a bug on the python3 issue however)
> 
> Oh, well that's probably because you only set LANG and it's being
> overridden by LC_ALL.  Use a bigger hammer: set LC_ALL yourself.
> 

For the wider record: yes, pbuilder sets LC_ALL to C, which has been/is being
discussed in #376404 and #725788. It's just a problem surfacing with python3 and
will affect a number of packages I'm afraid.

Best,
Michael



signature.asc
Description: PGP signature

Re: Computing resources for DHG work

[Michael Tautschnig]

Hi Sean,

On Sun, May 29, 2016 at 20:32:43 +0900, Sean Whitton wrote:
> Dear all,
> 
> The Debian Haskell Group has picked a target set of package versions to
> freeze on for stretch.  I'm working to upgrade packages in the DHG
> source package git repository to the target versions.  This requires
> quite a lot of computation, and the only machine I have access to until
> late July is rather old and slow.  The test builds I want to run take
> days[1] to complete.
> 
> Joachim Breitner suggested I ask on this list if anyone has a powerful
> machine they could give me access to so I can run the builds.  Without
> root access, the Haskell devscripts require a particular schroot config,
> and the installation of a few deps.
> 

Is this a single-core endeavour, or would would you benefit from multiple cores?
What are the disk space and memory requirements? I may be able to provide
resources, but it would be useful to get some more details on the requirements.

Best,
Michael



signature.asc
Description: PGP signature