Bug#301566: python-4suite-doc: Actually, the html docs are missing altogether!

[Jakob Bohm]

Package: python-4suite-doc
Version: 0.99cvs20041008-5
Followup-For: Bug #301566

A second look at the package reveals that there is no html documentation in
the package at all, only a few text files and a lot of regression tests.

I respectfully suggest adding the docs or simply removing the package...


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10jbj3.2.8
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)

-- no debconf information


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

Bug#302854: Acknowledgement (libcgicc-doc: Cannot install -doc: cannot create .dhelp file)

[Jakob Bohm]

tags 302854 patch
thanks

Note, I have not tested this patch!

--- debian/libcgicc-doc.doc-base.org2005-05-08 22:03:11.804375000 +0200
+++ debian/libcgicc-doc.doc-base2005-05-09 06:50:11.680330112 +0200
@@ -5,7 +5,7 @@
 Section: Apps/Programming
 
 Format: HTML
-Index: /usr/share/doc/libcgicc1-dev/html/index.html
-Files: /usr/share/doc/libcgicc1-dev/html/*.html
+Index: /usr/share/doc/libcgicc1-doc/html/index.html
+Files: /usr/share/doc/libcgicc1-doc/html/*.html
 
   


-- 
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.


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

Bug#309247: roxen4-doc fails to install on its own, extremely bad packaging

[Jakob Bohm]

Package: roxen4-doc
Version: 4.0.325-2
Severity: grave
Justification: renders package unusable (fails to install)

roxen4-doc failed to install, complaining that it did not know what database
to contact.  That sounded like obvious nonsense (I was installing the
*documentation*, not a database client, and besides it never asked me to
install or select any database whatsoever).  So I investigated further.

Here is the bunch of problems I found:

1. The packager has chosen to provide the documentation in the form of a
database file, which can only be read with special software.  This is
unacceptable in principle and in practice: Documentation must be readable
(and installable if in its own package) seperately from the act of running
the software being documented.  It must be possible to read the
documentation of various packages without having to run a different and
special program for each.  Debian contains and supports plenty of file
formats for this, a LOT of justification is needed to use a different format
in the binary .deb (except a redundant copy of the same text).

2. Launching or contacting daemons etc. from postinst in unexpected ways and
without warning (and without asking for positive user consent) is extremely
bad behaviour in terms of security and privacy.  This alone could justify a
grave bug on security grounds.

3. On top of all this, the package does not declare a dependency on the
packages it needs to even install, and displays an incorrect error message
when it sees that a different package (roxen4) is not configured.

I recommend that this package is completely redone or removed from the
archive.  *nothing* was apparently done right.


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.10jbj3.2.8
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)

-- no debconf information


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

Bug#317332: udev 0.060-1 NOT COMPATIBLE with ANY sarge or released kernels

[Jakob Bohm]

Package: udev
Version: 0.060-1
Severity: critical
Justification: breaks the whole system, will break upgrades from sarge

According to the NEWS entry provided in the udev 0.060-1 package itself,
this version of udev is NOT COMPATIBLE with any kernel version prior to
2.6.12.

Kernel 2.6.12 has NOT YET been packaged even in sid/unstable, making this
package upload completely useless with all current Debian kernels.  Even
worse, because of the critical function performed by udev, this means that
any attempt to upgrade to this package version can be expected to break the
whole system *according to the package's own documentation* .

Furthermore, because kernel 2.6.12 or later is not included in the sarge
release, inclusion of this package version or any other udev not compatible
with the kernel versions actually in sarge will cause massive breakage to
users upgrading from sarge to etch or etch+1.

Thus no udev implementation incompatible with the 2.6.x kernels actually in
sarge can be accepted into unstable, testing, frozen or stable until etch+1
has been released.  In the eventuality that etch releases as late after
sarge as sarge released after woody, this restriction could optionally be
relaxed from applying to etch+1 to etch+0.  This is nothing new, it is the
general release upgrade principles followed by Debian since the 1.1 release.

I thus STRONGLY SUGGEST that this package version be removed from the
archive and a prior package version reinstated in its place.  Furthermore I
would advise the ftpadmin to keep a very close eye on future uploads by this
maintainer to ensure that such deliberate breakage is not allowed to leave
the incoming queue again.

>From the chocked

Jakob

P.S.  When the NEWS item in question was displayed by apt-listchanges, I
obviously abandoned the upgrade, I thus have no access to the actual
contents of the package but a NEWS item declaring the package deliberately
broken should be proof enough (at least if the upload date is not April 1).

(Irrelevant config information omitted)

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11jbj3.2.10
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)

Versions of packages udev depends on:
ii  hotplug  0.0.20040329-22 Linux Hotplug Scripts
ii  initscripts  2.86.ds1-1  Standard scripts needed for bootin
ii  libc62.3.2.ds1-22GNU C Library: Shared libraries an
ii  makedev  2.3.1-78creates device files in /dev
ii  sed  4.1.4-2 The GNU sed stream editor

udev recommends no packages.


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

Bug#317332: udev 0.060-1 NOT COMPATIBLE with ANY sarge or released kernels

[Jakob Bohm]

On Thu, Jul 07, 2005 at 08:23:03PM +0200, Marco d'Itri wrote:
> retitle 317332 udev 0.060-1 should be used with a >= 2.6.12 kernel
> thanks
> 
> On Jul 07, Jakob Bohm <[EMAIL PROTECTED]> wrote:
> 
> > Justification: breaks the whole system, will break upgrades from sarge
> Not really.
> 
> > According to the NEWS entry provided in the udev 0.060-1 package itself,
> > this version of udev is NOT COMPATIBLE with any kernel version prior to
> > 2.6.12.
> NEWS.Debian ended out being a bit too much scary than it was intended.
> See http://blog.bofh.it/id_91 for details.

OK, so it was not as bad as stated for my 2.6.11 kernel (from unstable), but
the primary sarge kernel was 2.6.8, so 2.6.8 is the primary compatibility
requirement, while 2.6.11 is needed only for those tracking testing or
unstable!

What is worse however is the information about upstream in your blog.

Am I understanding you correctly when I read it as saying that kernel 2.6.12
(a point release in the "stable" branch) is making an incompatible change to
the udev interface, requires an upstream udev version which will not work on
relatively recent kernels (2.6.8 etc.) and (from info elsewhere)
simultaneously drops support for devfs (to which people just finished
migrating their locally written scripts ...)?

If this is correct, then this is the third such self-incompatible kernel
change in the last few months.  The two others were a security patch that
broke modules compiled from the same kernel source (due to careless touching
of header files), and an ALSA user space library that could not
simultaneously support kernel 2.6.8 and kernel 2.6.10.

It seams that if getting udev 0.6x quickly rewritten to support all
udev-based kernels in one version is too much work or too controversial, you
should do what modutils, cdrecord and other packages usually do for *major*
kernel upgrades (like 2.4.x to 2.6.x): package two versions of the source,
two sets of binaries (in one .deb) and some wrapper scripts or binaries to
exec the right one depending on the kernel version.

That is create a package with a structure like this

udev-0.060/
   debian/
  (rules etc.)
   debian/switch/
  (the wrapper scripts to select the right udev)
   v0.0??/
  (unpacked copy of some older udev tarball for older kernels)
   v0.058/
  (unpacked copy of the 0.058 tarball plus Debian patches)
   ./
  (upstream source not moved so pristine .orig.tar.gz still possible)

and from this create a package like this

/sbin/udev (result of
   perl -p -e 's|NAME|udev|g; s|DIR|sbin|g;' >/dev/console ||
echo "/DIR/NAME: ${ERR}" >&2 ||
:
[ -x /usr/bin/logger ] && /usr/bin/logger -i -t "NAME" -p 27 "${ERR}" || :
exit 1
# Hope no bashisms here...
# Note: This uses
#external program: /bin/uname
#optional external program: /usr/bin/logger
#shell builtins: set, case, esac, exec, echo, exit, :, [
#shell features: charset wildcards, $(), ${}, &&, ||, >>, >&2
# Note2: This script is optimized to minimize lines/commands before
#doing a successful exec
#also, no variables (not even PATH) are used or touched in the
#success case.

> 
> > Furthermore, because kernel 2.6.12 or later is not included in the sarge
> > release, inclusion of this package version or any other udev not compatible
> > with the kernel versions actually in sarge will cause massive breakage to
> > users upgrading from sarge to etch or etch+1.
> An upgrade plan is being designed, but it is not really relevant to
> the kernel version requirements of this package.
> 
> I will leave this bug open until 2.6.12 will be in etch.
> 

Side note: I think that it is prudent to always have a clear upgrade plan
from stable to current upload, during the woody->sarge upgrade I was hit by
several (mostly minor) issues caused by relatively old changes that never
got the upgrade plan right, including just about every sarge package with a
NEWS file (support for displaying NEWS files was a post-woody feature, so
none of those upgrade instructions were displayed during the upgrade that
they addressed!).



-- 
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.


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

Bug#317332: udev 0.060-1 NOT COMPATIBLE with ANY sarge or released kernels

[Jakob Bohm]

On Sun, Jul 10, 2005 at 01:02:11AM +0200, Marco d'Itri wrote:
> On Jul 10, Jakob Bohm <[EMAIL PROTECTED]> wrote:
> 
> > It seams that if getting udev 0.6x quickly rewritten to support all
> > udev-based kernels in one version is too much work or too controversial, you
> > should do what modutils, cdrecord and other packages usually do for *major*
> > kernel upgrades (like 2.4.x to 2.6.x): package two versions of the source,
> > two sets of binaries (in one .deb) and some wrapper scripts or binaries to
> > exec the right one depending on the kernel version.
> No, this would be hell to maintain. So far it looks like that upgrading
> the kernel before udev will work well enough to finish the upgrade.

Upgrading the kernel is a non-option for solving this.  It is technically
impossible [1] and even if it was possible, it would be a major removal of a
primary feature of the Debian distribution and packaging system as a whole
[2].

Like it or not, udev in etch MUST be a valid, functional, drop-in, no-reboot
upgrade from udev in sarge when running on top of any kernel image actually
included in sarge.  Ditto for the vast majority of correctly custom-compiled
kernels based on the kernel-source and kernel patch files actually included
in sarge.

Because sarge has already released, those kernel versions are now "cast in
stone", as is the udev version actually shipped in sarge.  Any point release
updates to sarge only add to the list, they do not remove the need to
correctly upgrade from Debian 3.1r0.

Thus technically there is no way around the need to ship (and thus maintain)
a 2.6.8 compatible udev package named udev in etch.  Nor is there any way
around ensuring that if whatever kernel ships in etch (like 2.6.16 at the
current schedule) is still using udev, that switching back and forth [3]
between those two kernel versions can be done without manually installing,
removing, upgrading, downgrading, reconfiguring or otherwise manipulating
the etch udev package or anything else on the non-volatile disks of the
system.


But just to clarify the situation:

Does kernel 2.6.12 work with any udev version that also supports 2.6.8?

If yes, that is the udev version that can go in etch (and thus sid).

If no, then either we cannot upgrade to kernel 2.6.12 or some workaround
needs to be coded.

The best workaround would be to patch udev to make a single udev version
work with both kernel versions (2.6.8 and the etch 2.6.x, currently 2.6.12).

If this is too difficult, then packaging two versions of udev (one for each
kernel version) with trivial wrapper scripts is a tried and true solution,
already used for the similar breakage of modutils between the 2.4.18 (from
woody) and 2.6.8 (from sarge).

And if you don't know how to package 2 udev versions in one package, then
look at my sample code posted in this report, or the code in
module-init-tools in sarge, or the code in cdrecord in sarge, or the similar
code found in various other packages with kernel-dependent functionality,
including glibc.

> 
> (If you tried to discuss your ideas with maintainers before starting to
> write down big designs you would probably save a lot of time.)
> 

This is not a new idea, it is a routine solution and a lot of cut/paste from
sarge. The only thing that took time was double checking various boring
facts, spell checking my mail etc.

-Jakob

Footnotes:

[1] Changing kernel versions can only happen at system reboot.  Upgrading
udev or any other package must happen before or after a reboot.  So there
will be a period of time during this process where only one of the two has
been upgraded, and many parts of the system must be 100% functional during
that period in order to successfully complete the upgrade.

This includes any device needed to actually run the packaging system and its
user interface, for any and all of the various media options available to
our users for both .deb files, local disks and user interfaces.  Including,
amongst others, a huge portion of the udev managed devices and modules.

And there is also the possibility that the second of the two upgrade steps
may fail or need to be redone, e.g. due to network, disk or power failures.

An even more demanding possibility is if the reboot attempt reveals a need
to recompile the etch kernel with different options to match the users
hardware etc.  Then gcc and other toolchain stuff also needs to run on the
half-upgraded system.


[2] Specifically, that a system upgrade from one stable release to the next,
or from stable to testing/frozen can be done as dselect/apt-get/aptitude
dist-upgrade with no or few special precautions, and the corresponding
reboot delayed until the user is ready etc.  This can be seen e.g. in the
release notes for at least hamm, potato, woody and sarge, and possibly bo as
well.


[3] Since very early Debian release (I seem to recall this being in bo), all
kernel image insta

Bug#317332: udev 0.060-1 NOT COMPATIBLE with ANY sarge or released kernels

[Jakob Bohm]

On Sun, Jul 10, 2005 at 11:49:22AM -0700, Greg KH wrote:
> On Sun, Jul 10, 2005 at 12:56:52AM +0200, Jakob Bohm wrote:
> > 
> > Am I understanding you correctly when I read it as saying that kernel 2.6.12
> > (a point release in the "stable" branch)
> 
> There is no more "stable" or "development" kernel branches anymore,
> haven't been for quite some time.  So this statement is false.

I was aware that a more aggressive change policy had been decreed for the
2.6.x series and that 2.7.x had not yet been started.  I was not aware that
the whole idea of starting a truly experimental branch (2.7.x or whatever)
later had been abandoned.  But thanks for the info, it only reinforces one
of my points.

> 
> > is making an incompatible change to the udev interface,
> 
> No, udev had a bug that caused it to not work as well as it should in
> 2.6.12, it was not a kernel problem.
> 
> > requires an upstream udev version which will not work on relatively
> > recent kernels (2.6.8 etc.)
> 
> Not true again, the current udev will work just fine on older kernels.

That was not the information published by Marco in his packaging changelog
and in his blog.  The bug is reported against the Debian package, I believed
Marco on his word that this was an upstream change in udev, that udev 0.060
would not fully work on kernel 2.6.8, while previous udev versions would not
work on kernel 2.6.12 .

> 
> > and (from info elsewhere) simultaneously drops support for devfs (to
> > which people just finished migrating their locally written scripts
> > ...)?
> 
> devfs has just been removed from the main kernel tree.  If you all are
> just starting to add support for it, you are all pointless behind the
> times.

Again confirming what I said.  The decision to drop devfs as of 2.6.12 did
not reach us users until about a year ago.  Converting thousands of tools,
scripts (upstream sources, distribution packages, local sysadmin scripts,
even files such as /etc/fstab) on each and every system had then (a year
ago) just been completed (not started).  At that time, 2.6.x was relatively
new, devfs was supported in both 2.4.x and 2.6.x and its naming scheme was
no longer being changed at irregular intervals.  Not so with udev.  A year
ago.  Then the word came down: devfs is going to be removed!  Move to udev! 
All your work is wasted!

Debian does a very thorough and careful QA and integration on packages and
has traditionally had a great focus on backward compatibility, however this
natural creates a delay before major upstream events reach the user end of
the pipeline.

Full support for running Debian on kernel 2.6.x at all was not declared
release ready until June 6th 2005, and just in case that release included
kernel 2.4.27 as a fallback option.  This was also the first release to not
include a fallback kernel from the 2.2.x series.  And the first release with
an officially supported udev package.  The Beta period for stuff like kernel
and udev was a whole year *after* deciding on upstream versions numbers and
making things apparently work.

Put another way:  kernel.org changes before mid 2001 became "Beta" in mid
2001 and was released in mid 2002.  The batch of changes from mid 2001 to
mid 2004 became "Beta" in mid 2004 and released in mid 2005.  The batch
changes from mid 2004 until some time in 2006 are now being prepared,
expecting a "Beta" mid 2006 and release early 2007 (My apologies to the
release team if this rough timeline is not accurate, I use words like Beta
loosely here). It is like interstellar (local) e-mail: Ping round trip time
measured in years, delay-bandwidth product (=TCP window) in Giga or Terra
bytes.

On systems not running Beta releases, this means that using udev rather than
devfs in the system configuration and scripts was not even an option until a
few weeks ago, less if people wait until they can get a DVD box via surface
mail.

Some people live on the bleeding edge, others wait for things to stabilize
and the kinks to be shaken out of systems first.  And for us, killing such a
pervasive API needs a longer notice than a year or two.


> 
> In the future, please get your facts straight before complaining.
> 

I was complaining to Marco based on information from Marco.

> > If this is correct,
> 
> It is not.
> 

Really?, that would be good news.

> > then this is the third such self-incompatible kernel change in the
> > last few months.  The two others were a security patch that broke
> > modules compiled from the same kernel source (due to careless touching
> > of header files), and an ALSA user space library that could not
> > simultaneously support kernel 2.6.8 and kernel 2.6.10.
> 
> These were "incompatible" changes that happened to kernel.org kernels?

According to very pu

Bug#317332: udev 0.060-1 NOT COMPATIBLE with ANY sarge or released kernels

[Jakob Bohm]

On Mon, Jul 11, 2005 at 09:57:46AM +0200, Marco d'Itri wrote:
> On Jul 11, Jakob Bohm <[EMAIL PROTECTED]> wrote:
> 
> > That was not the information published by Marco in his packaging changelog
> > and in his blog.  The bug is reported against the Debian package, I believed
> > Marco on his word that this was an upstream change in udev, that udev 0.060
> > would not fully work on kernel 2.6.8, while previous udev versions would not
> > work on kernel 2.6.12 .
> It's not my opinion, while the old udev works well enough with new
> kernels the new ones do not work with old kernels, as many users
> reported.

Ok, sorry for that little detail.  I misread one of your notes to mean that
you needed to upload 0.060 quickly because of 2.6.12.

-Jakob


-- 
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.


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

Bug#317332: udev 0.060-1 NOT COMPATIBLE with ANY sarge or released kernels

[Jakob Bohm]

On Mon, Jul 11, 2005 at 10:32:16AM -0700, Greg KH wrote:
> On Mon, Jul 11, 2005 at 06:15:35AM +0200, Jakob Bohm wrote:
> > On Sun, Jul 10, 2005 at 11:49:22AM -0700, Greg KH wrote:
> > > On Sun, Jul 10, 2005 at 12:56:52AM +0200, Jakob Bohm wrote:
> > > > 
...

> udev supports devfs naming schemes if you want to use that instead.  No
> breakage happens.  Becides the devfs naming scheme is not LSB compliant,
> why would you work to implement support for such a broken scheme?

Oh, it does?  Thats really good news to me and settles most of my worries
about devfs going away so quickly.  I retract those rants then.

> 
> Debian's development cycles have no relevance on this, sorry.

The bug is about the Debian development cycles and is filed against the
Debian packages (in)ability to handle it.  Not against upstream udev !

> 
> I am well aware of Debian's kernel support, and the mess that it
> currently is.  Along with the mess that the current long development
> cycles have caused.  That was not my point here at all, I was only
> stating that your comments about udev and the kernel were incorrect.
> 
> ...
> 
> As Debian seems wed to 2.6.8, devfs is still there, you can still use it.

Debian has not wed itself to 2.6.8 .  But Debians "slow" release cycle (and
no other aspect of Debian kernel support, messy or not) means that 2.6.8
was the latest version to make it into "sarge".

So now Debian (not upstream) needs to find a way to upgrade users from
2.6.8 to 2.6.12 (or a later kernel).  And that process involves finding
a way to upgrade both udev and kernel, with the complications caused by
the following (from the 2.6.11 kernel README):

 - Keep a backup kernel handy in case something goes wrong.  This is
   especially true for the development releases, since each new release
   contains new code which has not been debugged.  Make sure you keep a
   backup of the modules corresponding to that kernel, as well.  If you
   are installing a new kernel with the same version number as your
   working kernel, make a backup of your modules directory before you
   do a "make modules_install".

The above creates a need to have a single install of udev etc. work with
both the current and backup kernel.

So the primary criticism is internal to Debian, not against you at
upstream.

Take care

Jakob

-- 
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.


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

Bug#317332: Having udev disable itself on reboot is not acceptable

[Jakob Bohm]

On Mon, Jul 11, 2005 at 09:53:42AM +0200, Marco d'Itri wrote:
> On Jul 11, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> 
> > Having udev disable itself on reboot and leaving the system
> >  non-functional is not an acceptable solution. Most systems have
> I disagree, this is what udev has done since last year and so far
> nobody ever complained, so it's obviously not such a bad solution.

The current (sarge) udev only disables itself for 2.6.x kernel versions
that were never in a stable release of Debian.  2.6.8 IS in a stable
release of Debian which makes a huge difference.

(P.S. your disabling code apparently forgets to disable udev when running
on kernel 0.x or 1.x, but this is truly minor and not worth a bug number).

> 
> > The solution, of course, is blindingly simple: do what lvm has
> >  done for ages. Ship the old and the new versions of udev; and select
> >  the version to run based on the running kernel image.
> Cool! I will wait for your simple patch then.
> 

Just to clarify:  It appears that differences in configuration files and
inter-package APIs makes it impractical to have both 0.05x and 0.06x udev
on the same system thus ruling out my suggestion (which was just a
suggestion), that a dual-personality package could be easier to maintain
than other solutions.

And the need to permit the presence of 2 or more kernel versions in the
lilo/grub/whatever config makes it extremely hard to try to prevent
installing udev 0.06x on systems also containing kernel 2.6.8 tucked away
somewhere - At least if one wants a smooth and reliable upgrade process
from sarge to etch.

So this leaves the option of dealing with the bugs that prevent udev 0.060
from working on top of a 2.6.8 kernel.  Either upstream or as Debian
patches.  Which is obviously not going to be a simple patch and far beyond
my kernel knowledge.

-Jakob

Oh and I have been looking up Marco on the net, he seems a really cool guy.


-- 
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.


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

Bug#352172: libbsf-java_2.3.0+cvs20050308.orig.tar.gz missing in pool/main (is in contrib)

[Jakob Bohm]

Package: libbsf-java
Version: 2.3.0+cvs20050308-6
Severity: serious
Justification: no source, breaks debmirror etc.


Due to the issue described in Bug #341858 (an existing bug
against ftp.debian.org), when libbsf-java was moved from contrib
to main, the .orig.gz file was not included in pool/main (there
is a valid copy of the file in pool/contrib).

This has the following serious effects:

1. Running debmirror against sid source will always fail because
this orig.tar.gz is listed in main/source/Sources for sid and
testing but cannot be download from ftp.*.debian.org .  Thus it
makes ftp.debian.org internally inconsistent!

2. It obviously prevents downloading and building the source,
simply because apt-get source libbsf-java fails.

3. It clearly violates policy 2.1 (and the DFSG itself) "The
program must include source code, ..." .

I suggest that the missing file is added to ftp.debian.org
either by upload or by manual ftp-master intervention (the file
can simply be copied from the identical file in pool/contrib
where it is used by sarge).  Something like (line broken for
width in e-mail):

ftp-master$ cp -p \
debian/pool/contrib/libb/libbsf-java/libbsf-java_2.3.0+cvs20050308.orig.tar.gz \
debian/pool/main/libb/libbsf-java/


-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.14jbj3.4-11
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)


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

Bug#378183: apt: All SHA256 hashes generated/used by APT are wrong

[Jakob Bohm]

Package: apt
Version: 0.6.44.2
Severity: critical
Tags: security patch
Justification: breaks the whole system

The SHA256 checksums recently added to Packages files are wrong
due to a porting error when the sha256 implementation code was
imported from the Linux kernel sources to the apt source tree. 
Specifically, the broken sha256 code checksums only 19 out of
every 64 bytes of input and otherwise computes a result which is
neither sha256(input) nor sha256(mangled input).

According to the changelog, the broken code was added to
non-experimental apt in version 0.6.44 uploaded 8 May 2006 .

This has the following severe consequences:

- The broken hash values obviously do not provide anything
 resembling the security needed by secure apt, a problem
 compounded by the broken status of the other two hash
 algorithms used (MD5 and SHA1).  Thus the security tag.

- When the code is fixed to produce and check correct SHA256
 hashes, the fact that these values are different from the
 broken values means that a correct apt will reject all Packages
 files produced by a broken apt and a broken apt will reject all
 Packages files produced by a correct apt.  This means that
 when such a new apt implementation is placed in the debian
 archive, the whole system becomes impossible to install or
 upgrade:

 If the Packages file has bad SHA256 values, the broken apt
 versions already installed by testers/users will allow
 installation of the new apt, but once it has been installed,
 the new apt will reject all packages and stop all further
 installs.

 If the Packages file has good SHA256 values, the broken apt
 versions already deployed will refuse their contents, thus
 preventing users from upgrading to a good apt.

 This I believe justifies the "breaks whole system, critical"
 tag.

To work around the "breaks whole system" issue, the following
transition plan is proposed:

 1. Before uploading the fixed apt, temporarily reconfigure
  darcs etc. to NOT include SHA256 values in Packages files at
  all (apt-ftparchive has an option to do that).

 2. Upload the fixed apt as a minimal change from the apt
   version in testing, and coordinate with ftpadmin to push it
   quickly through to testing.  Yes, this means holding back
   other bug fixes until the change has propagated.

 3. Allow 1-3 weeks for users to upgrade to the fixed apt.  Use
   the various announce mailing lists to alert users to the
   urgency of getting rid of apt versions 0.6.44 to 0.6.44.?
   inclusive before the grace period ends!

 4. Turn SHA256 back on in darcs etc. this makes the SHA256
   security available for real.  But it also means that the
   archive can no longer be used by the broken 0.6.44 versions
   of apt.  So leave behind (on the ftp server, www server etc.)
   a message explaining how users can manually upgrade to a new
   apt version by downloading a .tar file and a detached .gpg
   signature from ftp.debian.org/debian/tools/something .  (This
   would be a hand-built tar file containing replacement .so
   files for each of the bad 0.6.44 apt versions and platforms).

For the security breakage, patching apt is the obvious fix.

Steps to reproduce:

$ apt-ftparchive packages somedirwithdebs
.
Filename: somedirwithdebs/something_xyz_all.deb
SHA256: 64 wrong hex digits here
.
$ gpg --pring-md sha256 somedirwithdebs/something_xyz_all.deb
somedirwithdebs/something_xyz_all.deb: 64 right hex digits
$ shasum -a 256 somedirwithdebs/something_xyz_all.deb
64 right hex digits  somedirwithdebs/something_xyz_all.deb
$ openssl dgst -sha256 -hex somedirwithdebs/something_xyz_all.deb
SHA256(somedirwithdebs/something_xyz_all.deb)= 64 right hex
digits
$

Thus at least 3 independent SHA256 implementations agree on the
correct value, as will apt once corrected.

[Patch begin, apply to apt-0.6.44.x with patch -Np1]
diff -Naur apt-0.6.44.2.old/apt-pkg/contrib/sha256.cc 
apt-0.6.44.2.new/apt-pkg/contrib/sha256.cc
--- apt-0.6.44.2.orig/apt-pkg/contrib/sha256.cc 2006-05-16 19:31:39.0 
+
+++ apt-0.6.44.2.new/apt-pkg/contrib/sha256.cc  2006-07-14 00:50:49.0 
+
@@ -61,10 +61,10 @@
 
 static inline void LOAD_OP(int I, u32 *W, const u8 *input)
 {
-   W[I] = (  ((u32) input[I + 0] << 24)
-   | ((u32) input[I + 1] << 16)
-   | ((u32) input[I + 2] << 8)
-   | ((u32) input[I + 3]));
+   W[I] = (  ((u32) input[I * 4 + 0] << 24)
+   | ((u32) input[I * 4 + 1] << 16)
+   | ((u32) input[I * 4 + 2] << 8)
+   | ((u32) input[I * 4 + 3]));
 }
 
 static inline void BLEND_OP(int I, u32 *W)
[Patch end]
(In the Linux kernel, the same calculation used a kernel only
type and macro to do the big-endian-unaligned-32bit to
native-endian-aligned-32bit conversion, the code lines above
were written specially for apt 0.6.44 (8 May 2006) and later).


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential::

Bug#378183: apt: All SHA256 hashes generated/used by APT are wrong

[Jakob Bohm]

On Fri, Jul 14, 2006 at 12:26:12PM +0200, Goswin von Brederlow wrote:
> Jakob Bohm <[EMAIL PROTECTED]> writes:
> 
> > To work around the "breaks whole system" issue, the following
> > transition plan is proposed:
> >
> >  1. Before uploading the fixed apt, temporarily reconfigure
> >   darcs etc. to NOT include SHA256 values in Packages files at
> >   all (apt-ftparchive has an option to do that).
> >
> >  2. Upload the fixed apt as a minimal change from the apt
> >version in testing, and coordinate with ftpadmin to push it
> >quickly through to testing.  Yes, this means holding back
> >other bug fixes until the change has propagated.
> >
> >  3. Allow 1-3 weeks for users to upgrade to the fixed apt.  Use
> >the various announce mailing lists to alert users to the
> >urgency of getting rid of apt versions 0.6.44 to 0.6.44.?
> >inclusive before the grace period ends!
> >
> >  4. Turn SHA256 back on in darcs etc. this makes the SHA256
> >security available for real.  But it also means that the
> >archive can no longer be used by the broken 0.6.44 versions
> >of apt.  So leave behind (on the ftp server, www server etc.)
> >a message explaining how users can manually upgrade to a new
> >apt version by downloading a .tar file and a detached .gpg
> >signature from ftp.debian.org/debian/tools/something .  (This
> >would be a hand-built tar file containing replacement .so
> >files for each of the bad 0.6.44 apt versions and platforms).
> >
> > For the security breakage, patching apt is the obvious fix.
> 
> One could rename the SHA256 field to SHA256v2 (or something) instead
> alowing for both new and old apt to work with both new and old
> Packages files.
> 
> Breaking the format even with a 4 week grace period will result in
> users having broken systems. We had such a transition for the
> debian-amd64 project (with libc6/base-files depends) and even 6 month
> after the transition period user still appeared on the ML unable to
> upgrade from before the transition to current. There will always be
> stragglers.

On second thought, renaming the field (even though the old field use
is not really useful) may be the better option.  The biggest unknown
factor (to me), is if the SHA256 field is already being used by one
or more Debian derived distributions, and if so, if those derived
distributins use the correct or broken value for the field.

But if no deployed software is currently using the field with its
correct contents, renaming it (and reserving the old name
indefinitely) would indeed be the smoothest overall solution.  As the
field name will appear repeatedly in Packages, Sources, Release and
other key archive index files, the new name should be chosen to match
the following criteria already satisfied by the old name:

  - Short, apt and dpkg store the uncompressed indices on the users
   disk.
  
  - Meaning obvious to the casual observer
  
  - Unlikely to clash with future updates to FIPS180, for instance if
   NIST/NSA release an updated 256 bit algorithm, such an updated
   algorithm is likely to be named SHA256v2 or SHA256v1, just as the
   second edition of 160 bit SHA (FIPS180) was named SHA-1
   (FIPS180-1).

  - A valid identifier in most programming languages, including
   shell, C++ etc.

Since SHA256 is one of the 4 new and similar hash formulas defined in
FIPS180-2, those 4 algorithms are often referred to collectively as
SHA2, with the 4 individual functions distinguished by their size in
bits.  Since none of the other SHA2 algorithms have yet to appear in
the Packages file format, and since the mental ambiguity with SHA224,
SHA384 and SHA512 is trivially dispelled by the size of the value
(256 bits == 64 hex chars), I propose simply calling the field "SHA2"
. If it is later decided to add one of the other bit lengths, that
bit length can use the SHA224/SHA384/SHA512 names that have not been
subjected to a failed implementation.

Cheers

Jakob

-- 
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.


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

Bug#433685: flashplugin-nonfree: Security issue fixed in unstable [CVE-2007-3456]

[Jakob Bohm]

Package: flashplugin-nonfree
Version: 9.0.31.0.1
Severity: grave
Tags: security, etch, upstream, fixed-upstream
Justification: user security hole (and won't install)

Upstream for this package (Adobe) has released version 9.0.48 as a
security update for version 9.0.31.

There is also an upstream security bulletin APSB07-12 at

it cross references [CVE-2007-3456].  It also cross references two
other CVE numbers which only affect versions not in stable (etch).

The upstream security update 9.0.48 has already been included in
unstable, but is not included in stable.

oldstable (sarge) contains version 7 of this plugin which might
not be affected by CVE-2007-3456 (the Adobe advisory is vague on
this).  oldstable is affected by CVE-2007-2002 though, see separate
bug report.

Additional note: as reported in bug #432755, the package currently
in stable (etch) does not install because Adobe has removed the
vulnerable version from its download servers.  Publishing 9.0.48
(or a backport of it) on security.debian.org should fix that too.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /basnxt32/bin/bash
Kernel: Linux 2.6.21jbj3.4-21
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)

Versions of packages flashplugin-nonfree depends on:
ii  debconf [debconf-2.0] 1.5.11 Debian configuration management sy
ii  fontconfig2.4.2-1.2  generic font configuration library
ii  libatk1.0-0   1.12.4-3   The ATK accessibility toolkit
ii  libc6 2.3.6.ds1-13   GNU C Library: Shared libraries
ii  libcairo2 1.2.4-4The Cairo 2D vector graphics libra
ii  libexpat1 1.95.8-3.4 XML parsing C library - runtime li
ii  libfontconfig12.4.2-1.2  generic font configuration library
ii  libfreetype6  2.2.1-5FreeType 2 font engine, shared lib
ii  libglib2.0-0  2.12.4-2   The GLib library of C routines
ii  libgtk2.0-0   2.8.20-7   The GTK+ graphical user interface 
ii  libice6   1:1.0.1-2  X11 Inter-Client Exchange library
ii  libpango1.0-0 1.14.8-5   Layout and rendering of internatio
ii  libpng12-01.2.15~beta5-1 PNG library - runtime
ii  libsm61:1.0.1-3  X11 Session Management library
ii  libx11-6  2:1.0.3-7  X11 client-side library
ii  libxau6   1:1.0.1-2  X11 authorisation library
ii  libxcursor1   1.1.7-4X cursor management library
ii  libxdmcp6 1:1.0.1-2  X11 Display Manager Control Protoc
ii  libxext6  1:1.0.1-2  X11 miscellaneous extension librar
ii  libxfixes31:4.0.1-5  X11 miscellaneous 'fixes' extensio
ii  libxi61:1.0.1-4  X11 Input extension library
ii  libxinerama1  1:1.0.1-4.1X11 Xinerama extension library
ii  libxrandr22:1.1.0.2-5X11 RandR extension library
ii  libxrender1   1:0.9.1-3  X Rendering Extension client libra
ii  libxt61:1.0.2-2  X11 toolkit intrinsics library
ii  wget  1.10.2-2   retrieves files from the web
ii  zlib1g1:1.2.3-13 compression library - runtime

Versions of packages flashplugin-nonfree recommends:
pn  xfs(no description available)

-- debconf information:
  flashplugin-nonfree/not_exist:
  flashplugin-nonfree/local:
  flashplugin-nonfree/httpget: false


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

Bug#433687: flashplugin-nonfree: Security issue fixed upstream [CVE-2007-2022]

[Jakob Bohm]

Package: flashplugin-nonfree
Version: 7.0.25-5
Severity: grave
Tags: security, sarge, upstream, fixed-upstream
Justification: user security hole (and won't install)

Upstream for this package (Adobe) has released versions 7.0.70 and
9.0.48 as security updates for version 7.0.25.  Like Debian, Adobe
appears to be creating backported security updates (versions 7.0.69
and 7.0.68 were also security updates released after a new major
version had been released).

There is also an upstream security bulletin APSB07-12 at

it cross references [CVE-2007-2022].  It also cross references two
other CVE numbers which maybe only affect versions not in
oldstable (sarge), the Adobe advisory is unfortunately vague on
that.

The upstream security update 9.0.48 has already been included in
unstable, but is not included in stable or oldstable.  The upstream
security update 7.0.70 has not yet been packaged for Debian,
but since this is just an installer package, changing it to refer to
the new upstream version should be trivial.

stable (etch) contains version 9 of this plugin which is not
affected by CVE-2007-2022.  stable is affected by CVE-2007-3456
though, see separate bug report.  CVE-2007-3457 is for upstream
major version 8, which is neither in oldstable nor in stable.

Additional note: as reported in bug #402822, the package currently
in oldstable (sarge) does not install because Adobe has removed the
vulnerable version from its download servers.  Publishing a version of
the oldstable package which downloads upstream version 9.0.48 or 7.0.70
on security.debian.org should fix that too.


-- System Information:
Debian Release: 3.1
  APT prefers oldstable
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.21jbj3.4-21
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)


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

Bug#382612: bzr: '~' in Version number violates policy 5.6.12

[Jakob Bohm]

Package: bzr
Version: 0.9~rc1-1
Severity: serious
Justification: Policy 5.6.12

Policy section 5.6.12 lists the permitted characters in package
version numbers, '~' is NOT on the list, and until less than 14
days ago all packages in the archive were compliant with that
rule.  I know for certain that one of my own mirroring scripts
will refuse to accept '~' in package file names, and others
might do the same.

As explained in policy section 5.6.12, if the upstream version
number does not match the format and semantics specified in
section 5.6.12, the maintainer should reformat the version
number in his upload.

Sincerely

Jakob

Footnote: The actual wording in policy 5.6.12 does not use the
standard phrases specified in policy 1.1, making it difficult to
infer if violation of the specified format should be classified
as serious, normal or wishlist.  Based on the nature of the
information, its citing in the first footnote of policy 1.1 and
the general structure of the English language, I interpret "may
only" as a must requirement not to do something else.  In other
words, it is entirely optional for a version number to contain
the character '+' ("may contain only ... '+'"), but it is
required not to use any characters not enumerated there.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (450, 'unstable'), (400, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /basnxt/bin/bash
Kernel: Linux 2.6.17jbj3.4-16
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)


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