http://www.nnseek.com/e/linux.debian.announce.devel/ Posts for linux.debian.announce.devel Sat, 19 Jul 2008 06:40:08 PDT http://www.nnseek.com/ http://www.nnseek.com/img/64.png 64 64 NNSeek http://www.nnseek.com/e/linux.debian.announce.devel/release_update_freeze_architecture_requalification_85819584t.html http://www.nnseek.com/e/linux.debian.announce.devel/release_update_freeze_architecture_requalification_85819584t.html Hash: SHA1

Hi *,

Normally, you'd have a pithy comment about how we're writing to you with
lots of info and things. However, due to the timeline, please accept the
small picture below:
______________________
< We freeze next week! >
----------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||

Freeze status
~~~~~~~~~~~~~
Since the last update, the following steps in the timeline have been
taken:
Freeze of the non-essential toolchain
The "non-essential toolchain" means things like debhelper, cdbs
and a big chunk of other things usually needed to produce binary
packages.
Freeze of all library packages
This will affect all packages that produce library packages used
by other packaged software. Packages without r-deps won't be
frozen at this point.

I'll point out once again, that maintainers should look at the timeline
and realise that next week we *FREEZE*.


Architecture status
~~~~~~~~~~~~~~~~~~~
The architecture qualification pages on wiki.debian.org are still
missing a LOT of information.
Of the current 12 architectures, 8 are still at risk of being dropped
unless their issues can be solved. Check the [ARCH:QUAL] pages for more
information as to the current issues. In some cases, these arches are
not being considered because we may not have enough information in the
wiki pages to make an informed judgement.


Release goals
~~~~~~~~~~~~~
* Switch /bin/sh to dash

There are still quite a few bugs open about bashisms, but most of those
have a patch included. Please NMU. This goal doesn't mean we'd switch to
dash as a global default, but if people do so on their system, there
shouldn't be any issue after the last bugs have been finished off.

* piuparts-clean archive

Over 50 bugs remaining, many with little activity. Since these are
problems that affect all users and are usually fixed by little changes
to the maintainer scripts, more attention to this goal would be very
welcome.

* double compilation support

Most of the double compilation problems have been fixed since the last
release update and there are only about three dozen bugs left. Please
note that many of the packages still affected are in bad general shape,
so each NMUer should consider if the package in question shouldn't be
removed instead.

* Prepare init.d-Scripts for dependency-based init systems

Wider testing of dependency-based init systems has lead to some new bugs
for this goal, but the current state looks quite well. We are confident
that we will have full support for dep-based init system in lenny.


BSP Marathon
~~~~~~~~~~~~
At time of writing, we have 360 open RC bugs affecting lenny, which is
360 too many. A coordinated effort is needed to reduce this number, so
we've decided to resurrect last year's very successful BSP marathons. As
a reminder, we still have a 0-day NMU policy in effect.

Please note that in a BSP, you shouldn't just NMU every RC bug you see.
While you are working on a package, check for other low-hanging fruits
(like translation updates, typos that can easily be fixed, ...) and fix
them in your NMU. On the other hand, if you notice that a package looks
unmaintained, refrain from fixing the bugs for now and try to find out
if the package should be removed or adopted by another maintainer
instead.

In case you want to organise a BSP, don't hesitate to contact the
Release Team to coordinate efforts.


Release schedule
~~~~~~~~~~~~~~~~
If you've managed to miss my (ok, cowsay's) wonderful artwork, please
see the following:

Next week
Full freeze
Please don't wait with uploads for the last day before the freeze,
thanks.

September 2008
Release lenny!


Tricks from the Release Team
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Curious as to why your package isn't getting into testing? Have a look
at the [MIG] Migration Tracker page. Although if it's a library, or
you're reading this mail after next week, it's because we've frozen. Did I
mention that already?

- --
http://release.debian.org
Debian Release Team

References:
[ARCH:QUAL] http://release.debian.org/lenny/arch_qualify.html
[RG:D]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-release@lists.debian.org&tag=goal-dash
[RG:P]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-release@lists.debian.org&tag=piuparts-stable-upgrade&dist=testing
[MIG] http://release.debian.org/migration/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiB7aMACgkQ5UTeB5t8Mo2i3gCfaO6k3FYZFXAcu2NX60Fing9O
m3UAn1pKmp4PrLe9Nxk0lAcSmlbH3JZ3
=61g5
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-announce-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Posted In: linux.debian.announce.devel

no comments

Reply

]]> Sat, 19 Jul 2008 06:40:08 PDT http://www.nnseek.com/e/linux.debian.announce.devel/bits_from_the_dpl_85320384t.html http://www.nnseek.com/e/linux.debian.announce.devel/bits_from_the_dpl_85320384t.html Hi!

It's been a while since my last bits post, rather longer than it
should have been. Sorry. :-( I blame the idiot who suggested a big
survey of the teams in Debian. Oh, wait...

So, what's been happening?

The teams survey
----------------
I won't bore people with all the details again - I've already
announced them once [1]. Most of our teams seem to be working OK, but
many could do with more help and some have real problems. I'm going to
be working through my list of actions in the coming weeks and
months. Chief amongst them will be to help identify the places where
new people can help; many people have been asking already.

There was a followup to the survey - a brief piece in the Register[2]
unfortunately focussed a great deal on just one part of my write-up,
but I suppose that's probably to be expected sometimes.

I'm waiting on a few more press interviews (about the survey and other
topics) to happen in the upcoming weeks; I'll pass on pointers to them
as they happen.

Upcoming events and talks
-------------------------
I've been invited to a couple of conferences to talk about
Debian. First, the region of Valencia in Spain are holding their 3rd
Open Source Software Congress [3] in the first week of November. I'm
hoping to meet up with lots of enthusiasts there who are pushing hard
to promote the use of Free Software in education and government. Then,
later in November I'll be visiting HP Dutchworld [4]. Hewlett Packard
have long been supporters of Debian, and this should be a good
opportunity to speak with some of their people and some of their
customers and tell them all about Debian.

Between now and then, I'm going to be helping to man the Debian stand
at two events closer to home in the UK. This coming weekend, we'll be
at LugRadio Live UK [5] in Wolverhampton and then in October we're
going to be exhibiting as part of the .ORG village at LinuxLive[6] in
London.

Team updates and delegations
----------------------------
As Christoph Berg moved on from the NM Front Desk to join DAM, he left
a gap behind him. Wouter Verhelst and Michael Koch have volunteered to
fill that gap, so hopefully the FD team should be able to cope without
him now. [7] As always, we'd still like more people to work as AMs -
please contact the FD folks if you want to help out [8].

As the constitution requires [9], I've spoken to Manoj and
re-delegated him as Project Secretary for this year. He and I have
also had further discussions about the secretary job and we agreed
that it would be useful to appoint an assistant to help in times where
he might be busy or unavailable. We have asked Neil McGovern to be the
assistant, and he has accepted the post.

Collaborating with Debian derivatives
-------------------------------------
I've spoken with Mark Shuttleworth a couple of times recently about
how we can improve collaboration between Debian and Ubuntu. I've also
started similar conversations with folks at Xandros and Linspire,
although I'll admit that I've not progressed those very far at all yet
due to lack of time on my part. Recent events may have changed the
landscape here a little [10], but I'm still convinced that there's a
lot to be gained if we can work together more closely with the
developers who use Debian as a base for their own distributions. I
want to talk about this more at Debconf, and I'd love to hear your
ideas on this front.

Debconf!
--------
Talking of which... We're less than 4 weeks from the start of this
year's Debconf in Mar del Plata, Argentina [11]. The organising team
have been working incredibly hard to get things done in time, and I
can't wait to head south and meet up with friends old and new. I've
also got the dubious honour of the opening talk when we're there, but
I'm more interested in hearing what others have to say. Oh, and maybe
the dancing and beer! I'll be wearing my Debian kilt with pride, and I
hope to see others too. Does anybody know if we can find sauna in
Argentina? :-)

Lenny
-----
Coming Real Soon Now. The freeze is in progress as I write this, and
we should be making the last push to get the RC bugs list [12] reduced
and prepare for the release. There's still a lot of work to be done,
and I'm told there's another release update coming from the Release
Team very shortly. Let's come together and help make Lenny our best
release yet!

[1] http://lists.debian.org/debian-devel-announce/2008/06/msg00009.html
[2] http://www.theregister.co.uk/2008/07/03/debian_death_threats/
[3] http://www.edu.gva.es/congreso
[4] http://www.hp.nl/dutchworld/
[5] http://lugradio.org/live/UK2008/
[6] http://www.linuxexpo.org.uk/
[7] http://lists.debian.org/debian-devel-announce/2008/06/msg00007.html
[8] http://lists.debian.org/debian-devel-announce/2008/06/msg00005.html
[9] http://www.debian.org/devel/constitution#7
[10] http://www.xandros.com/news/press_releases/xandros_acquires_linspire.html
[11] http://debconf8.debconf.org/

Cheers,

--
Steve McIntyre, Debian Project Leader debian.org>


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIfTlLfDt5cIjHwfcRAryjAJ9NLpcLwHUoK/GzTt+ZF8HljdGTLwCcC0ej
bWkiGsdceEHWn3ZkC9duz70=
=Hxmf
-----END PGP SIGNATURE-----

Posted In: linux.debian.announce.devel

no comments

Reply

]]> Tue, 15 Jul 2008 17:00:07 PDT http://www.nnseek.com/e/linux.debian.announce.devel/status_of_emdebian_arm_85312960t.html http://www.nnseek.com/e/linux.debian.announce.devel/status_of_emdebian_arm_85312960t.html Emdebian has been developing nicely over the last few months and the
time has come to produce a general status report because we are close to
having a reproducible set of working root filesystems for embedded ARM
devices to run Emdebian using prebuilt packages. Kernels and kernel
modules need to be arranged separately and the installation method will
need to be customised to the particular device at this stage. (I am
hoping to build the root filesystem tarball into the Debian Installer at
some stage.) Only ARM is supported at this time (ARM as in the current
Debian ARM port, not armel).

During DebCamp and DebConf8, I will be working on the issues set out
here as well as the ongoing development of TDebs with Christian Perrier
and the Debian i18n team.
http://www.emdebian.org/emdebian/langupdate.html

Emdebian now provides a cross-building autobuilder (in the
emdebian-tools package) which uses patches from Emdebian SVN to reduce
package size, reduce dependencies and support TDebs. These changes will
progress into more bugs in the relevant Debian packages in due course
under the banner of the "mass bug filing for cross-build support"
already in use.
http://www.emdebian.org/bugs.php

We also have an autobuilder for the toolchains themselves.

Emdebian also provides a wrapper for debootstrap (called emsandbox) to
build a root filesystem from the Emdebian ARM repository - separating
the build process from the generation of the root filesystem. All
packages can be customised for specific devices and the modified
packages folded into emsandbox via the use of a local repository and
local autobuilder.

Root Filesystems:
1. Basic busybox and glibc: 9.0Mb compressed, 24Mb installed.
2. as 1 with X server : 11Mb compressed, ~60Mb installed.
3. as 2 with full GPE GUI : 25Mb compressed, ~80Mb installed.

(My Debian pbuilder debootstrap is 146Mb compressed.)

Each root filesystem can be customised for specific machines and
variants of machines, e.g. balloon3.
http://buildd.emdebian.org/svn/browser/current/emdebian/trunk/machine/trunk/balloon3...
http://balloonboard.org/gallery/300/boxdisplay.jpg
http://balloonboard.org/

These sizes are already a significant improvement on standard Debian but
optimisations in glibc, tzdata and xfonts-base are expected to reduce
the installed size by at least another 12Mb. Work is ongoing to fold
uClibc into Emdebian to reduce installation sizes further.

BUGS
====

Bugs in Emdebian itself include #484700 which makes installation tricky
- chpasswd fails so the first task is to chroot into the installed
filesystem via the bootloader and set a non-random root password. I
suspect an error in how the passwd files are generated.

Two bugs already in the Debian BTS are critical for future Emdebian
development:
#448615 - support for DEB_BUILD_OPTIONS="nodocs" in debhelper
#450483 - support for setting DEB_CONFIGURE_SCRIPT_ENV to empty in CDBS
when cross-building to ensure the correct cross-compiler
options are available.

BTS crossbuilt tag and buildd.emdebian.org pseudo-package support has
been requested. (#480408 and #480511).

Autobuilder Summary:
===================
http://www.emdebian.org/buildd/index.php

235 packages built successfully.

17 packages failed to cross build.

93%% built OK
6%% failed.

28 packages are tagged for a manual upload. Some are old builds that had
already been uploaded before the autobuilder was written (and have not
changed in Debian since), others are due to dependency issues. Rather
than break the archive, packages are never uploaded until relevant
dependencies have been checked by edos-debcheck, fixed and uploaded.
This results in Emdebian unstable always being installable - a
significant bonus in cross-building as it means the root filesystems
should always build. Migration into testing is a manual process. (Note
that -dev, .udeb and -doc packages are ignored for installability
checks.)

Notes:
A) All the autobuilt packages did cross-build previously and those that
fail to cross-build, fail at the latest versions in Debian Sid. Many
could be upstream errors. All exist in Emdebian at previous versions
(only 1 failure is known to contain bugs in the current versions in
Emdebian and this only affects GUI installations. 2 other GUI packages
contains bugs but build OK.).
B) Some of the packages in the repository (including some of the
failures) are not used in *any* of the default emsandbox configurations.
Two need to be removed from the repository completely.
C) Some fixes are waiting for updates in Debian, either new uploads
migrating to mirrors or pending fixes currently in incoming.
D) The history of each package is now available via the Emdebian
Autobuilder Report: http://www.emdebian.org/buildd/index.php
The package name links to the history of previous build attempts for
this package. The version string links to the repository data for the
current version in Emdebian. The result of the build links to the build
log.
E) A comparison with Debian unstable is constantly updated:
http://www.emdebian.org/buildd/status.php
F) The repository contains a fair number of packages that we don't
currently use. This is a reflection of the problems of determining the
"path" through the dependencies when starting at the bottom (glibc|
uClibc etc.). Bear this in mind when considering new architectures and
new package sets. The process involves a lot of trial and error,
particularly as cross-building offers the change to alter the dependency
path at each iteration.
G) AFAICT OE has not built these packages at these versions but I
haven't checked each one individually. (It would be useful to know if
someone has the time - even better, write a script that can do the
comparison.)

Problems:

1. gtk+2.0 fails to cross-build because the patches now try to build the
udeb which comes up against a bug in dpkg-cross. I've uploaded the
new version (including a couple of other bug fixes) today. (A late
problem in apt-cross has delayed things slightly.) The Gtk package also
needs some work to run /usr/lib/libgtk2.0-0/update-gdkpixbuf-loaders so
that the icons can be read in the GUI.

2. pango1.0 also needs a fix to update the pango modules. This is
usually done at build time but it means running a cross-built binary. It
is a minor task and not CPU intensive so I plan to do this in postinst.
Without this fix, no text is rendered in the GUI, only empty glyphs.

4. xfonts-base is way too large still. More work is needed here to
optimise just what is meant by the 'fixed' font for X, precisely which
font files can be removed, which might be needed outside C or English
locales etc.

5. Other packages not currently cross-building include:
(NOTE: Some of these build logs are VERY large.)

adduser - needs to be removed from the repository, it is perl
and we implement it via busybox.
cups|cupsys - /usr/include/pthread.h:653:
warning: '__regparm__' attribute directive ignored
http://www.emdebian.org/buildd/index.php?log=cupsys-arm-1215672259.log&pkg=cupsy...

gcc-4.2 - needs to be removed from the repository, it no longer builds
libgcc1 which was the main reason for cross-building it.
glib2.0 - more generated content:
/bin/sh: line 2: /usr/bin/glib-genmarshal: No such file or
directory
http://www.emdebian.org/buildd/index.php?log=glib2.0-arm-1215674126.log&pkg=glib2...

gnomevfs - hasn't built for ages and isn't usable anyway due to
dependency issues. Currently preventing the use of
gpe-filemanager. Due to be replaced by GIO in Debian.

libusb - build failure, so far resistant to usual fixes.
http://www.emdebian.org/buildd/index.php?log=libusb-arm-1215676434.log&pkg=libus...

ncurses - build failure - uses gcc in wide char support build:
http://www.emdebian.org/buildd/index.php?log=ncurses-arm-1215676704.log&pkg=ncur...

ntp - build failure - assembly error.
authkeys.c:445: error: invalid 'asm': invalid operand for code 'w'
http://www.emdebian.org/buildd/index.php?log=ntp-arm-1215676930.log&pkg=ntp

pcre3 - build failure - apparently simply unresolved symbols resistant
to usual fixes.
http://www.emdebian.org/buildd/index.php?log=pcre3-arm-1215684456.log&pkg=pcre3

slang2 - possibly needs a patch update, tries to build -pic archives
and then fails.
http://www.emdebian.org/buildd/index.php?log=slang2-arm-1214368558.log&pkg=slang...

xorg-server - build failure:
make[4]: *** No rule to make target `-L/usr/arm-linux-gnu/lib', needed
by `Xprt'. Stop.
http://www.emdebian.org/buildd/index.php?log=xorg-server-arm-1215677189.log&pkg=xorg...

Of the problems above, only problems 2, 3 and 4 (gtk, pango and
xfonts-base) are "critical" as these are the only ones where the current
packages are sufficiently broken that the new version is essential
before Emdebian can make a "release" of a series of three root
filesystems for ARM.

Any help on the above issues is appreciated.

Problem-solving:
http://www.emdebian.org/docs.html
http://wiki.debian.org/EmdebianQuickStart

If you have SVN access, use 'emdebuild --svn-only' to commit your
changes (even if your changes don't solve all the problems).

Without SVN access, post the result of 'svn diff ../emdebian*' to the
debian-embedded mailing list (or 'svn diff ../debian*' if you have added
a patch for the upstream code to debian/patches/).

Platforms:
All the above is based solely on Emdebian ARM for balloon3:
Linux balloon 2.6.25.2-pxa270 #1 Sun May 18 22:38:11 BST 2008 armv5tel
unknown
http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/124-At-LAST!.html
http://balloonboard.org/gallery/300/boxdisplay.jpg
http://balloonboard.org/gallery/300/balloon3-0v1-fpga.jpg

AFAICT no other ARM platforms have been tested. :-(

When using emdebian-tools for native builds, for uClibc support or for
any architectures which I do not currently build, *PLEASE* file normal
Debian bugs in the BTS for emdebian-tools so that I don't lose track of
the issues. If you ask me something on IRC or on the debian-embedded or
debian-devel mailing lists, I am likely to forget what I promised /
explained / fixed so a bug report will really *REALLY* help me.

Finally, Lenny will release with working cross-building support via dpkg
and emdebian-tools but it is not possible to implement the same for Etch
except within a Lenny or Sid chroot. emdebian-tools is also not usable
on Debian derivatives like Ubuntu due to the lack of suitably ported
packages to prepare as cross-dependencies during the builds - a Debian
chroot is again recommended.

Although Emdebian won't be providing complete tarballs for installation
due to the variety of devices and installation methods/media (and the
limited space that prevents automated querying of the device), we are
still planning a 'release' of Emdebian {ARM} alongside Lenny as a series
of root filesystem options.

Not sure whether this should be Emdebian 1.0 or 5.0 - it is our first
working release but contains only packages from Debian 5.0 (Lenny/main).

Enjoy.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkh9I3UACgkQiAEJSii8s+NzvQCgp3Wr77E9mcd5TI0v7+V/UhFy
kAYAnRIaZO3ESSqipEj0+dMzh5Gbl8rN
=8mYE
-----END PGP SIGNATURE-----

Posted In: linux.debian.announce.devel

no comments

Reply

]]> Tue, 15 Jul 2008 15:30:16 PDT http://www.nnseek.com/e/linux.debian.announce.devel/call_for_keys_for_keysigning_in_mar_del_plata_during_85275840t.html http://www.nnseek.com/e/linux.debian.announce.devel/call_for_keys_for_keysigning_in_mar_del_plata_during_85275840t.html Hello All,

As part of the 9th Debian Conference in Mar del Plata, Argentina, there
will be OpenPGP (pgp/gpg) keysignings. If you intend to participate in
the DebConf8 keysignings, please send your ascii armored public key as
explained at [0] not later than 23:59 UTC on Saturday 26th of July,
2008.

More (and up-to-date) information is available at [0], so keep watching
it.

[0] http://people.debian.org/~anibal/ksp-dc8/ksp-dc8.html


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkh8k3UACgkQgY5NIXPNpFVtvgCfROe+u2ol+UYH2+AXTM9j3YaE
2wQAnAogD1H1vbWn4tc9fe8JlEuYCDeP
=q2tN
-----END PGP SIGNATURE-----

Posted In: linux.debian.announce.devel

no comments

Reply

]]> Tue, 15 Jul 2008 05:40:08 PDT http://www.nnseek.com/e/linux.debian.announce.devel/new_ftp_assistant_84108224t.html http://www.nnseek.com/e/linux.debian.announce.devel/new_ftp_assistant_84108224t.html Hi

following our "Bits" mail[1], where we asked for volunteers, we just
added a new member to the team. Everyone, please welcome our new
FTP Assistant Mark Hymers!

[1] http://lists.debian.org/debian-devel-announce/2008/05/msg00012.html

=2D-=20
bye, Joerg

PS: JFTR - there are still two volunteers, so *possibly* two more
candidates.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Joerg Jaspert debian.org> -- Debian Developer

iEYEARECAAYFAkhyc7QACgkQcV7WoH57islIJgCeNYzrgAfR9bz+CI+um0wfFI+3
VpsAoI2VTkM3/pBF70DNxYhMhlcQS3Yg
=+2r4
-----END PGP SIGNATURE-----

Posted In: linux.debian.announce.devel

no comments

Reply

]]> Mon, 07 Jul 2008 13:00:16 PDT http://www.nnseek.com/e/linux.debian.announce.devel/misc_developer_news_9_83565760t.html http://www.nnseek.com/e/linux.debian.announce.devel/misc_developer_news_9_83565760t.html The news are collected on http://wiki.debian.org/DeveloperNews
Feel free to contribute.

Advice on quilt usage and compatibility with new source format
--------------------------------------------------------------

To prepare a future switch to the "3.0 (quilt)" source package format, I
tried to convert the whole archive and to rebuild the packages
afterwards. This resulted in lots of improvements on dpkg-source as I
adapted the code to make it support many of the existing build setups but
not all problems could be fixed on the dpkg-source side. I filed a bunch
of bugs[1] for packages that need additional changes. To ensure
compatibility with the new source format, please try to follow the
guidelines below.

For packages already using quilt:
* Make sure that all patches apply with -p1 (and not -p0). This is the
default in quilt but some manually imported patches are only applicable
with -p0 (and this option is forced in the series file). This can be done
with quilt refresh (more on this below (*)).
* Make sure that the quilt patches don't modify/create/delete files
within the debian directory.
* Make sure that the .diff.gz doesn't contain cruft related to
auto-generated/updated files (like config.guess/sub, see #482716[2] to
avoid this). The upstream changes in the .diff.gz are like a new patch at
the end of the quilt series. It must be possible to unapply it during
"debian/rules clean" and to reapply it just before "debian/rules build".
* Don't hand-edit patches. If you do it nevertheless, please "quilt
refresh" them to ensure that the various offsets in the patches are
right.
* Store the patches in debian/patches/ and the series file as
debian/patches/series.
* Don't override the location of the ".pc" directory.
* Don't reinvent rules to apply/unapply patches, but rely on
/usr/share/quilt/quilt.make that you can include from debian/rules.
* If you use CDBS, use /usr/share/cdbs/1/rules/patchsys-quilt.mk but
don't change the top level source directory with DEB_SRCDIR (or change it
but apply patches from the top-level directory anyway by setting
DEB_QUILT_TOPDIR to ".").

For other packages:
* Don't keep the quilt series file if you stopped using quilt in your
source package.
* Avoid tarball in tarball, dpkg-source can't apply patches if the
source files are not available directly after extraction of the .orig
tarball.

(*) Use this small recipe to refresh all the patches. This will ensure
they are fully correct and will be applicable with "patch -p1".

quilt pop -a; while quilt push; do quilt refresh -p1; done

Note that you can also use quilt refresh -pab if you prefer fake
top-level directory names (those have the advantage not to change when
the directory name changes. Directories for source package typically have
the upstream version embedded).

-- Raphaël Hertzog

[1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=0;tag=3.0-quilt-by-default;repeatmerged...@debian.org
[2] http://bugs.debian.org/482716

update-grub starts using UUIDs by default
-----------------------------------------

Latest versions of update-grub (0.97-40 in GRUB Legacy and
1.96+20080601-2 in GRUB 2) start using filesystem UUIDs by default.
Although only GRUB 2 uses them internally for fetching its own files,
both of them detect the UUID of your root filesystem and pass that to
Linux in the "root" parameter.

In GRUB Legacy, this change affects only generation of "kopt" parameter
when no previous menu.lst existed. If you have an existing menu.lst and
are only updating it, your kopt will remain unmodified. Since this means
only new installs will be affected, it would be preferable if existing
installs explicitly tested this functionality by renaming menu.lst and
re-running update-grub, so that serious problems (if any exists) can be
detected in time before the freeze.

-- Robert Millan

wxwidgets2.8 upload to unstable
-------------------------------

Adeodato Simó recently uploaded wxwidgets2.8[3] to unstable. This is a
long requested update, but package maintainers are encouraged to be
conservative about using it: Only packages that don't work with
wxwidgets2.6[4] should use the new version, stability and new bug issues
are expected to happen when switching too fast. This is also the reason
behind the decision to keep wxwindows2.6 as default for Lenny[5]. Testing
with the new widgetset for such applications that still would work with
wxwindows2.6 should happen in private or experimental before decisions
are done.

-- Gerfried Fuchs

[3] http://packages.debian.org/source/sid/wxwidgets2.8
[4] http://packages.debian.org/source/sid/wxwidgets2.6
[5] http://www.debian.org/releases/lenny

Volunteers needed to handle update of release notes
---------------------------------------------------

Frans Pop has acted as the lead editor for the Sarge and Etch release
notes but recently resigned from this task[6]. For the Lenny release
notes a new team of editors is needed, but so far no one has stepped up
to work on that. This is a good opportunity for non-developers to help
while working in close coordination with the release team. Feel free to
join and start acting on the open bugs[7].

-- Raphael Hertzog

[6] http://lists.debian.org/debian-doc/2008/05/msg00008.html
[7] http://bugs.debian.org/release-notes


--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Signed by Raphael Hertzog

iEYEARECAAYFAkhtNXYACgkQvPbGD26BadJ74gCgjjNUp7VgYVRhjaRKgLJxCXLt
8BYAmgOZkRGVI37wnngS9CP6CpU6axjr
=E5rV
-----END PGP SIGNATURE-----

Posted In: linux.debian.announce.devel

no comments

Reply

]]> Thu, 03 Jul 2008 13:30:22 PDT http://www.nnseek.com/e/linux.debian.announce.devel/dpl_teams_survey_summary_summary_83151296t.html http://www.nnseek.com/e/linux.debian.announce.devel/dpl_teams_survey_summary_summary_83151296t.html Hey folks,

As you may remember, back before I started the DPL job I promised to
run a survey. Then I pestered a huge number of people to answer a set
of questions and get back to me. I've taken longer than I hoped to
read through all those responses and summarise them, but finally I'm
done. As I said at the time, I'm *not* going to go into great gory
detail about individuals or specific teams here and now. Many of the
surveys include personal information and I promised to protect
that. Instead, this is just a summary of the results. I'll be
following up in more detail with various of the teams in the coming
weeks. If you have any questions in the meantime, please feel free to
contact me.

So, enough of the disclaimers... :-)

The raw numbers
===============

I sent out 75 mails containing survey questions[1] at the end of
April. The initial (announced) deadline was the 25th of May, but I
always planned to accept late submissions (within reason). When I sent
out an update [2] earlier this month, predictably that prompted more
answers. The latest response landed in my inbox on the 20th of
June. In total, 116 people got back to me with information and all of
those (modulo a couple of bounces) should by now have received
individual thank you messages from me. I'll echo that again here anyway
- thanks very much to the people who spent their valuable time giving
me the data I asked for.

It's common for people to be in multiple teams; 15 people identified
themselves as belonging to 4 or more teams, and a couple said they
were in 10 or more teams. But still the majority of people responding
listed one team only.

In all from the responses, 77 teams were listed.

Highlights
==========

As I hoped to find, the vast majority of the respondents said they
were having fun working on Debian. That's not unexpected, but it's
nice to confirm this. A few people responded to say "I have fun doing
Debian work, but would have even more fun doing it if I had more
time." Quite a number said they're enjoying working with friends,
doing cool technical stuff but are less happy about our mailing lists
and IRC channels when they devolve into flamewars.

Most respondents believe that their teams are working
well. Apparently, just about *every* team could do with more people to
help with their tasks, but again that's not a great surprise. :-)

Some teams are working very well, by all accounts. As an example: I
received a huge number of responses from the Perl team, all of them
very positive. The group seem to be getting on astoundingly well,
supporting hundreds of packages between them. Communications are good,
and there are enough people to cover bug reports and new package
versions. Woo!

The i18n and l10n groups tend to be quite informally organised, but
(with a small number of exceptions) are mostly working well. There's a
small (and funny) contradiction in the responses here: Christian
Perrier told me that the team needs some stronger leadership and he
doesn't think he's good at organising things. Most of the other people
in this area said that they loved Christian and his efforts in
organisation. *grin*

More and more teams are springing up spontaneously over time, mainly
covering groups of packages. This is aiding developers to work
together on related work, plus it's a great way for new developers to
join in and learn more about Debian.

Lowlights
=========

I received no responses at all from a small number of the teams. These
include a couple of the role addresses listed on our organisation page
[3]. I'm going to try and fix those quickly, and I'll be checking up
on the rest of these teams ASAP.

Many of our longest-standing developers are overworked. Most of them
are still having fun, but not all. Almost all of them are struggling
to find the time to do the jobs they want to do, and it's clear that
in some cases they feel guilty because of this.

It won't come as a big surprise that the porter teams working on
several of our architectures are short of manpower. Some are thriving
and working well, but it seems that we have a real problem finding
skilled people with enthusiasm to work on some of the more exotic
types of machine. In stark contrast to that, I received a large number
of reports from the m68k porters; they may be working on old, slow
hardware but they're still passionate about making it work.

Communication between some of our teams is less than ideal, ranging
from bad to non-existent. There are many reasons for this: personality
conflicts, lack of time, conflicting goals and ideas and
more. Communications inside some of the teams can be just as bad -
I've heard of places where the only communications between team
members come via comments in VCS reverts.

Some of our teams struggle for leadership. It can be all too easy for
people to leave tasks for "somebody else" to do, but "somebody else"
never picks them up. Some teams may be working just fine on the
day-to-day tasks that come up, but either never consider the bigger
issues or get too bogged down in discussions and disagreements about
how to solve those issues such that they never get started.

Expected results
================

Almost all the respondents said that their teams could use more
people. Not a shock... :-) Some teams are *really* short of people for
important core jobs and could do with help to find more.

Several core teams have had problems with communications. That was
already expected up-front, and was one of the reasons why I initiated
this review. Personnel changes have happened in various of those teams
already, and it seems that they have made quite a difference in a
short time. More work is still needed here yet, as more teams are
still having problems.

Quite clearly, many of our developers are over-committed. That's not
uncommon at all in a volunteer project - it goes with the
territory. It's also clear that quite a few people have not (until
now) actually taken stock of all the jobs they have promised to
do. Maybe I've just caused some of them to be scared now. :-)

I now have a much more complete picture of how our teams are
working. I had my own ideas beforehand, but in a lot of cases all I
had to go on was second-hand stories and rumours. There's now a lot
more information for me to use when talking to some of the teams in
the upcoming weeks, and that will be very helpful.

In return for the promise of privacy / anonymity in the surveys, I
have had some refreshingly honest answers from many people. This does,
unfortunately, mean that I can't really publish much of the data I've
gained, but that's a price worth paying. By explicitly asking for
responses to be sent to leader@ rather than to me directly, at least
most of the data will be archived for future DPLs to see. If that's
not something you expected for your survey response and you'd like it
to be un-archived, please contact me privately.

Unexpected news
===============

I wasn't aware of just how badly some of our teams were
performing. Quite a few are barely functional at all. In more than one
case, I had responses like "team? what team?". Several are technically
made up of a group of people, but only one person is doing all the
work. Other teams are in worse positions of stagnation or even
out-and-out conflict. There are not many teams in these states, but
having any at all is bad.

Many of our developers are used to strong discussions and technical
arguments in the course of Debian and Free Software development, but I
was *shocked* to hear that one of our community has been the target of
death threats as a thank you for her work. I'm horrified to hear about
such a nasty thing happening; please let me know ASAP if any such
thing happens again in the future and I'll do my level best to help
track down and deal with the perpetrators.

Where to go from here
=====================

There are a few things I can do here, and a lot more that I'd like to
encourage others to do or to help with.

1. As I've mentioned above, there are several places where urgent work
is needed to try and rescue teams/tasks that are failing. I'll be
talking to those folks as soon as possible. I'm not naming names
here just yet, as I don't want to just add even more pressure to
already-stressful situations.

2. On the flip side of that, I'd also like to ask the members of the
teams that are acknowledged to perform well to help us with ideas
for good practices to follow. Obviously, some working methods may
not transfer well from team to team as they face different
problems. But it's also clear that some methods *will* work well in
a wider context, and it would be nice to see them tried.

3. Being busy is not itself a problem, but being *too* busy (such that
tasks are left undone and other people are blocked) does cause
trouble. To fix it, we need to spread the load and re-prioritise
work, admitting that we need help on some of our tasks. We all need
to look at our own work and time commitments and honestly evaluate
whether or not we can do all that we've promised. Over-work doesn't
work in the long run.

4. Several teams desperately need more help. Firstly I'd suggest that
they should try to find more help themselves. Blog posts on Planet,
or mails to debian-devel, or "bits from" mails to d-d-a are a good
way to pick up more interested people. If those really don't help,
then we can maybe find more ways.

5. Face-to-face meetings have been a great help for various teams over
the last few years, at FOSDEM, Debconf, Extremadura and
elsewhere. If you think that your team(s) would benefit from
getting together like this, then get organising!

6. I found that people from quite a number of teams responded to the
survey, despite not being on my initial target list. That's not a
surprise! However, a more comprehensive, canonical single list of
teams would be very nice to have. Currently there are multiple
incomplete team lists scattered all over the place; that's not very
useful.

7. Be more verbose about what we're doing. The more that people talk
about the good work that's going on all over the project, the more
we'll encourage existing and new developers to join in and help
us. Equally, if there's something particularly problematic that
you've found is blocking you, tell the rest of us about it.

8. Publicise more clearly the places where new people could help
out. I'm commonly asked by people how they could get involved in
Debian, or what tasks most urgently need help, and those are quite
difficult things to answer. A more focussed set of web pages and/or
wiki pages targeting these questions would be a great thing to
have.

There's a whole load more ideas people have suggested to me beyond
these, some quite obvious and easy to implement and some much less
so. I've also got quite a few people to come back to and talk to some
more about various other topics they raised in their survey
responses. It's been a busy few weeks, and there's no sign of that
changing much soon... *grin*

Thanks for bearing with me so far.

[1] http://people.debian.org/~93sam/teams_review.txt
[2] http://lists.debian.org/debian-project/2008/06/msg00045.html
[3] http://www.debian.org/intro/organization

--
Steve McIntyre, Debian Project Leader debian.org>



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIZ6ggfDt5cIjHwfcRAggHAJ9W+xDojecmQNlHFrkAZ/2EuiHeZQCfQxdA
IDNv56a2qFM+AyVzO8I6v+g=
=cuhU
-----END PGP SIGNATURE-----

Posted In: linux.debian.announce.devel

no comments

Reply

]]> Sun, 29 Jun 2008 08:30:16 PDT http://www.nnseek.com/e/linux.debian.announce.devel/security_incorrect_file_permissions_due_to_now_fixed_82993344t.html http://www.nnseek.com/e/linux.debian.announce.devel/security_incorrect_file_permissions_due_to_now_fixed_82993344t.html Likely affected: any unstable/testing system that has 'debsums' installed
Possibly affected: any unstable/testing system

Today a Debian Testing Security Announcement [1] was published describing
an issue where files may have gotten world readable/writable/executable
permissions due to a bug in perl 5.10. As not everybody reads DTSAs, it
seems proper to give this issue a bit wider publication.

The issue was first spotted by Joey Hess and myself for terminfo files
from the ncurses-base package [2] and traced to debsums being run by APT
during post-install. From there, Ben Hutchings traced it to a bug in the
function File::Path::rmtree in perl 5.10.

So far the issue has only been confirmed for the use of File::Path::rmtree
in debsums, but in theory any program using that function can result in
files with incorrect permissions.

Although the cause of the bug has now been fixed, many systems may still
have files with incorrect permissions around and thus be vulnerable to
attack. Checking if your systems are affected is strongly recommended.

Please see the DTSA [1] for further details.

Just to be clear: systems running stable (etch) are NOT affected.

[1]http://lists.debian.org/debian-testing-security-announce/2008/06/msg00016.html
[2]http://lists.debian.org/debian-devel/2008/06/msg00543.html
http://bugs.debian.org/487319


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkhkCVcACgkQgm/Kwh6ICoRB/ACdFb2+YiG1rSu/dNewyc9D+Zi3
CBMAoKSlOLUCOi9LkCzkT9tPjErq7N2v
=dRbm
-----END PGP SIGNATURE-----

Posted In: linux.debian.announce.devel

no comments

Reply

]]> Thu, 26 Jun 2008 14:30:22 PDT http://www.nnseek.com/e/linux.debian.announce.devel/new_nm_front_desk_members_82975424t.html http://www.nnseek.com/e/linux.debian.announce.devel/new_nm_front_desk_members_82975424t.html Hi,

the New-Maintainer Front-Desk is proud to announce the addition of two
new members to its ranks. Wouter Verhelst debian.org> and
Michael Koch debian.org> have accepted the invitation to join
the team.

Welcome on board!

Christoph,
on behalf of the current FD members
--
cb@df7cb.de | http://www.df7cb.de/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIY7OHxa93SlhRC1oRAtV6AKCv4qG8XhtMI0UXNc9uLrx8AnYFsQCgiJJq
SnSgMRX9lqs7V4n6pws2Ve4=
=YPTb
-----END PGP SIGNATURE-----

Posted In: linux.debian.announce.devel

no comments

Reply

]]> Thu, 26 Jun 2008 08:30:15 PDT http://www.nnseek.com/e/linux.debian.announce.devel/bits_from_testing_security_team_82826432t.html http://www.nnseek.com/e/linux.debian.announce.devel/bits_from_testing_security_team_82826432t.html Hi fellow developers,

It's been some time since our last email. Much has happened since then
with regards to the security support of Debian's testing distribution.


General security support for testing
------------------------------------

The Debian Testing Security team is very near to providing full
security support for the testing distribution. At the time of the last
email, two blockers for full security support were present. However,
we now are able to process embargoed issues (more on that below), so
we are happy to announce that only one blocker remains. The only
remaining blocker for full security support at this point is the
kernel. We are talking to the kernel security team about providing
testing-security support, but at the moment this task lacks
manpower. If you are willing to work on this, please feel free to
contact us. Otherwise, in terms of security at this point we recommend
using the stable kernel or if that is not an option, the unstable
kernel. Also, we would like to state that packages that are not
security supported for stable are likewise unsupported for
testing. This list includes all packages in contrib and non-free, as
well as the ones that are marked unsupported (for example,
kfreebsd). The maintainers are solely responsible for security and
there won't be any DTSAs for such packages.


Security status of the current testing distribution (lenny)
-----------------------------------------------------------

With some pride we can say that testing has never been in such good
shape security wise. The tracker reflects very accurately the current
known security issues in the testing distribution[0]. Our new
announcement emails[1] provide a notification for users whenever a new
security fix reaches testing, whether through migration from unstable
or DTSA for testing-security. Also fewer packages are getting removed
from testing because of security issues.

In order to reach a wider audience with security updates for testing
and due to the beta1 release of the lenny installer including the
testing-security repository in the apt-sources, this new mailing list
was created. We highly recommend that every user who runs Debian
testing and is concerned about security subscribes[1] to this list

Note: this list is a replacement of the old secure-testing-announce
list hosted on alioth which has been removed.


Security status of the next testing distribution (lenny+1)
----------------------------------------------------------

After the release of lenny, there will probably be no security support
for the new testing distribution for some time. It is not clear yet
how long this state will last. Users of testing who need security
support are advised to change their sources.list entries from
"testing" to "lenny" now and only switch to lenny+1 after the begin of
its security support is announced. There will be another announcement
with more details well before the release of lenny.


Embargoed issues and access to wider security information
---------------------------------------------------------

Parts of the Testing Security Team have been added to the
team@security.debian.org alias and are thus also subscribed to the
vendor-sec mailing list where embargoed security issues are
coordinated and discussed between Linux vendors before being released
to the public. The embargoed security queue on security-master will be
used to prepare DTSAs for such issues. This is a major change as the
Testing Security Team was not able to prepare updates for security
issues under embargo before. If a DTSA was prepared for an embargoed
issue in your package, you will either be contacted by us before the
release or you will be notified through the BTS. Either way, you will
most likely get an RC bug against your package including the patch
used for the DTSA. This way you can prepare updates for unstable and
the current unfixed unstable package does not migrate to testing,
where it would overwrite the DTSA.


Freeze of lenny coming up
-------------------------

With the lenny release approaching, the Debian release team will at
some stage freeze the testing archive. This means it is even more
important to stay in close contact with the Debian Testing Security
team to coordinate security updates for the testing distribution. If
one of your packages is affected by an unembargoed security issue,
please contact us through the public list of the team[2] and fix the
issue in unstable with high urgency. Please send as much information
as possible, including patches, ways to reproduce the issue and
further descriptions. If we ask you to prepare a DTSA, please follow
the instructions on the testing-security webpage[3] and go ahead with
the upload. If your package is affected by an embargoed issue, email
the private list[4] and if we should ask you to upload a DTSA, use the
embargoed upload queue (which is the same than for stable/oldstable).


Handling of security in the unstable distribution
-------------------------------------------------

First of all, unstable does not have official security support. The
illusion that the Debian Testing Security team also officially
supports unstable is not true. Security issues in unstable, especially
when the package is not in testing, are not regarded as high urgency
and are only dealt with when there is enough spare time.

However, it is true that most of our security updates migrate through
unstable to prevent doubled workload. For this purpose, we urge every
maintainer to upload their security fixes with high urgency and
mention the CVE ids (if given) in their changelogs. Because we let
fixes migrate, it often happens that we NMU packages. An up to date
list of NMUs done by the security team can be found in our
repository[5]. These NMUs are done as the need arises and do not
always follow the given NMU rules, because security updates are
treated with higher urgency.


Call for new members:
---------------------

The team is still looking for new members. If you are interested in
joining the Debian Testing Security team, please speak up and either
write to the public mailing list[2] or approach us on the internal
mailing list[6]. Note that you do not have to be a DD for all tasks.
Check out our call for help[7] for more information about the tasks
and the requirements if you want to join the team. We also look for
people with experienced knowledge regarding the kernel. We would like
to start security support for the kernel packages in testing and
prepare DTSAs for the unembargoed kernel issues. For this task, it
would be good to have one or two designated people in the Debian
Testing Security team to only concentrate on this task. If you are
interested, please speak up.


Yours,
Testing Security

[0]: http://security-tracker.debian.net/tracker/status/release/testing
[1]: http://lists.debian.org/debian-testing-security-announce
[2]: secure-testing-team@lists.alioth.debian.org
[3]: http://testing-security.debian.net/uploading.html
[4]: team@security.debian.org
[5]: http://svn.debian.org/wsvn/secure-testing/data/NMU/list?op=file&rev=0&sc=0
[6]: team@testing-security.debian.net
[7]: http://lists.debian.org/debian-devel-announce/2008/03/msg00007.html


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkhiCyIACgkQHYflSXNkfP9kPgCfQIdz+hnUcjIajghaMGfrr3AU
0T8An2PDfxNsUBzHragbAFjiDhakUix4
=/iS3
-----END PGP SIGNATURE-----

Posted In: linux.debian.announce.devel

no comments

Reply

]]> Wed, 25 Jun 2008 02:20:12 PDT