Wookey | 1 Feb 01:52 2011

Re: tcl8.5 breaks dpkg-cross assumptions and multiarch

+++ Steve Langasek [2011-01-31 12:18 -0800]:
> > So, the questions is - which of these is the correct fix:
> > 1) make dpkg-cross copy over symlinks even when they point into
> > /usr/share
> > 2) make tcl8.5 put tclConfig.sh in /usr/lib/tcl8.5 instead of
> > /usr/share/tcltk/tcl8.5
> > 3) make sqlite (and similar packages) look in /usr/share/tcltk/tcl8.5
> > instead of /usr/lib/tcl8.5 when building
> 
> 1+2: dpkg-cross should also copy over symlinks that point to /usr/share.
> When such symlinks exist, it's almost invariably because *something is
> looking for the information in that location*.  So as a general policy, they
> should also be made available in a crossed package.

But if something is looking for arch-independent stuff in /lib then in
general that's wrong, and I'm not aware of any examples of
correctly-packaged packages that need this. Any arch-independent files
will be supplied by an arch all package that the build should depend
on if needed.

dpkg-cross has gone for 10 years without needing symlinks pointing into
/usr/share, so I'm reluctant to add them without some evidence that
it's actually correct. Its policy of only crossing arch-dependent
files is the right one, I believe.  (It does allow symlinks within
/usr/src which presumably has/had a good reason.)

Wookey
--

-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
(Continue reading)

brian m. carlson | 1 Feb 02:43 2011
Picon

Bug#611698: nodejs: conflicts with package node needlessly

Package: nodejs
Version: 0.2.6-1
Severity: serious
Tags: experimental

It appears that nodejs in experimental has acquired a Conflicts with
node.  According to the changes file for that release:

   * Use upstream binary names for node and node-waf,
     conflicts with node package. (Closes: #597571)

I still don't believe that is allowed by Debian Policy.  Section 10.1
states:

     Two different packages must not install programs with different
     functionality but with the same filenames.  (The case of two programs
     having the same functionality but different implementations is handled
     via "alternatives" or the "Conflicts" mechanism.  See Section 3.9,
     `Maintainer Scripts' and Section 7.4, `Conflicting binary packages -
     `Conflicts'' respectively.) If this case happens, one of the programs
     must be renamed.  The maintainers should report this to the
     `debian-devel' mailing list and try to find a consensus about which
     program will have to be renamed.  If a consensus cannot be reached,
     _both_ programs must be renamed.

#597571 had been marked wontfix, but then was mysteriously closed in
experimental.  If this isn't in contravention of Debian Policy (which is
possible, I suppose), then what's been done to resolve it so it isn't
should be put in README.Debian or NEWS.Debian.

(Continue reading)

Thijs Kinkhorst | 1 Feb 10:06 2011
Picon

Re: A request for those attending key signing parties

On Mon, January 31, 2011 21:18, Martin Zobel-Helas wrote:
> a more theoretical question quite related to this:
>
> If one plans to have the key replaced in the keyring, and we have a
> fellow DD in the keyring who's only trust path to other Debian
> Developers goes via that key (this might become a real scenario when we
> do a bigger round of key replacements) will that key replacement really
> happen? Thus CCing keyring maintainers.

(I'm not a keyring maintainer.)

Currently connectedness has only been used to decide on entry into the
keyring. In a similar scenario, if you are signed by just one DD and that
DD retires from Debian, you are not removed from the keyring, even though
you're no longer connected to other DD's by trust paths. And that is not a
problem, because the process is used to establish identity. Your identity
has been established upon entry, and this fact is not lost when
connectedness of your key is reduced. Thus it's not essential to keep the
keys internally connected.

Cheers,
Thijs

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Archive: http://lists.debian.org/906938246402b2893e33b381b2fe3747.squirrel <at> wm.kinkhorst.nl

Thijs Kinkhorst | 1 Feb 10:12 2011
Picon

Re: Upstream "stable" branches and Debian freeze

On Mon, January 31, 2011 18:09, Christian PERRIER wrote:
> However, upstream's policy in their "stable" branches is alway to only
> fix "important" bugs (they don't call them this way...but the
> definition is fairly close to Debian's). So, *in the case of samba*, I
> can guarantee that the user's (indeed sysadmin's) experience is much
> improved if (s)he can follow the upstream minor releases.

In the past such things have not been allowed with the argumentation that
even though stable may contain bugs, users rely on the behaviour that
stable has. They may know about a bug but may have worked around it (and
the update may break the workaround) or they do not know about a bug but a
fix for it may break a previously functional system. And of course as we
all know: bugfixes are not zero-risk and do have chances on new bugs being
introduced.

Being completely bug-free would be nice, but is probably unachievable. I
think there's something to say for the predictability of a release: it may
not be perfect, but once installed and tested it will keep working.

Cheers,
Thijs

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Archive: http://lists.debian.org/4edb1dc090de6330490ab7f897785b9f.squirrel <at> wm.kinkhorst.nl

Petter Reinholdtsen | 1 Feb 10:58 2011

Re: CPE lists was Re: Equivalent packages between Linux distributions


[Silvio Cesare]
> I created an automatically generated CPE list for Fedora13
> packages. It only has 300 or so packages in it, but this will
> improve as say Debian increase the list of packages they track (they
> only track 1100 or so currently).
>
> https://github.com/silviocesare/Equivalent-Packages/blob/master/CPE/Fedora13.CPE.generated

Very interesting.  I created the CPE entries for Debian manually, by
comparing the set of affected packages reported in the CVE database
for Debian and NVD.  Perhaps something similar could be done for
Fedora, assuming the project track CVEs in a structured way?

Note that there are several duplicate CPE entries used by NVD.  A list
of the ones I have identified so far is in data/CPE/aliases.

Note that there is a bug in your list.  xen is claimed to be
grub-legacy.  Perhaps check your code?

Happy hacking,
--

-- 
Petter Reinholdtsen

Picon

Re: Upstream "stable" branches and Debian freeze

On Tue, 01 Feb 2011, Thijs Kinkhorst wrote:
> On Mon, January 31, 2011 18:09, Christian PERRIER wrote:
> > However, upstream's policy in their "stable" branches is alway to only
> > fix "important" bugs (they don't call them this way...but the
> > definition is fairly close to Debian's). So, *in the case of samba*, I
> > can guarantee that the user's (indeed sysadmin's) experience is much
> > improved if (s)he can follow the upstream minor releases.
> 
> In the past such things have not been allowed with the argumentation that
> even though stable may contain bugs, users rely on the behaviour that
> stable has. They may know about a bug but may have worked around it (and
> the update may break the workaround) or they do not know about a bug but a
> fix for it may break a previously functional system. And of course as we
> all know: bugfixes are not zero-risk and do have chances on new bugs being
> introduced.

It is a good thing that we are actually able to learn, and move forward
then, isn't it?

Some upstreams do so much regression testing and are so strict, that
you'd actually be doing a disservice to your users if you don't track
their stable branch during Debian stable lifetime.

> Being completely bug-free would be nice, but is probably unachievable. I
> think there's something to say for the predictability of a release: it may

You can just unplug it from the net and never update, if you want that
(and if you're going to do that, be smart and use read-only media for
the invariant parts of the system already): We've had several
regressions due to security fixes.  While those are not frequent,
(Continue reading)

Loïc Minier | 1 Feb 12:50 2011

Re: tcl8.5 breaks dpkg-cross assumptions and multiarch

On Tue, Feb 01, 2011, Wookey wrote:
> But if something is looking for arch-independent stuff in /lib then in
> general that's wrong, and I'm not aware of any examples of
> correctly-packaged packages that need this. Any arch-independent files
> will be supplied by an arch all package that the build should depend
> on if needed.

 I might be getting your point wrong, but I certainly see a lot of files
 in /lib itself which are arch-independent data used for early boot
 (before /usr is available); PNG files and text files which would be
 identical on all architectures.

--

-- 
Loïc Minier
Ian Jackson | 1 Feb 14:11 2011
Picon

Re: Upstream "stable" branches and Debian freeze

Thijs Kinkhorst writes ("Re: Upstream "stable" branches and Debian freeze"):
> In the past such things have not been allowed with the argumentation that
> even though stable may contain bugs, users rely on the behaviour that
> stable has. They may know about a bug but may have worked around it (and
> the update may break the workaround) or they do not know about a bug but a
> fix for it may break a previously functional system. And of course as we
> all know: bugfixes are not zero-risk and do have chances on new bugs being
> introduced.

Basically this argument is "the update may break things".

That's true, but the right questions are: how likely is that; how bad
are the bugs that would be fixed by the update; and so on.

> Being completely bug-free would be nice, but is probably unachievable. I
> think there's something to say for the predictability of a release: it may
> not be perfect, but once installed and tested it will keep working.

This argument seems very absolutist and would seem to suggest we
should never do any stable release updates at all.  But a user who
wants that level of stability can simply not take the stable release
updates, and only apply the security updates.

I think there is room for us relaxing our policy for stable updates.
Where upstream have a good track record of not breaking their own
stable branch, I think providing those updates to our users is
probably sensible.

Ian.

(Continue reading)

Philipp Kern | 1 Feb 16:32 2011
Picon

Re: Upstream "stable" branches and Debian freeze

On 2011-02-01, Ian Jackson <ijackson <at> chiark.greenend.org.uk> wrote:
> This argument seems very absolutist and would seem to suggest we
> should never do any stable release updates at all.  But a user who
> wants that level of stability can simply not take the stable release
> updates, and only apply the security updates.

That's not easily possible as stable as found on the mirrors is overriden
by point releases.[1]  So you'd need to mirror stable r0.

> I think there is room for us relaxing our policy for stable updates.
> Where upstream have a good track record of not breaking their own
> stable branch, I think providing those updates to our users is
> probably sensible.

First off they have to establish that track record with us, though.

(See also [2].  There will be a few updates to leaf packages in stable.
However updates to stable server software will be considered carefully,
and it depends on how we're convinced of the QA of maintainers and the
quality of upstream releases.  PostgreSQL did that[3].  For others we'll
act on a case-by-case basis.)

Kind regards
Philipp Kern

[1] Ubuntu does it a tad differently.  On normal releases their release suite
    isn't updated.  Instead updates are just pushed through the -updates suite.
    So here you're free to ignore those.  LTS do point releases like we do,
    though.
[2] http://lists.debian.org/debian-volatile-announce/2011/msg00000.html
(Continue reading)

Timur Birsh | 1 Feb 16:34 2011

Any Debian Developers traveling to Almaty? (GPG key sign needed)

Hello,

Are there any Debian Developers traveling to Almaty for the Asian Winter 
Games? I need a GPG key sign.

Thanks,
--

-- 
Timur


Gmane