Nabble - debian-devel-announce

New source package formats now available

2009-11-21T07:54:36Z

Hello,

since a few weeks the Debian archive accepts source package using the new
formats "3.0 (quilt)" and "3.0 (native)". The last step for us (dpkg
maintainers) in this project is to change dpkg-source to use those new
formats by default. However, before we do this we want to ensure that
no packages (in sid) will be broken due to this switch and there are
quite a few packages left to fix:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=hertzog@...;tag=3.0-quilt-by-default
You're more than welcome to help us achieve this release goal [2].

The initial uptake is quite good, more than 120 source packages
have been converted already:
Graph: http://upsilon.cc/~zack/stuff/dpkg-v3/
Raw numbers: http://udd.debian.org/cgi-bin/dpkgformat.cgi

We have collected some question/answers from early adopters in
the dedicated wiki page, the most important information is pasted
below. We hope you will find it helpful to convert your own packages.
http://wiki.debian.org/Projects/DebSrc3.0#FAQ

=== Why should I convert my package to 3.0 (quilt) format? ===

Pick the reasons that matter to you:
* by keeping patches separate and properly documented (with DEP-3[1]):
* the Debian changes are more likely to be reviewed (for example thanks to
http://patch-tracker.debian.org)
* any upstream contributor is more likely to find and merge the patches (if
you haven't forwarded it properly)
* other distributions can reuse our patches
* even if you don't have any upstream patch right now, next time that
someone must NMU your package, they can cleanly add a patch (with a
proper DEP-3 header) without having to modify the build system
* same applies for derivative distributions that have to modify your
packages... you're more likely to be able to find something valuable to
merge if their changes are kept as separate patches instead of merged
within the .diff.gz
* debian/rules can be simplified by getting rid of the
patching/unpatching code (or the uuencoding/uudecoding code if you ship
a supplementary binary file like an icon)
* the upstream tarball is bzip2-compressed and you don't want to have to
convert it
* the upstream tarball contains a debian directory and you don't want to
repackage it just to remove that directory
* the upstream author releases the software in multiple tarballs
* you don't have to add -i -I every time that you manually build the
package from the VCS repository (the VCS-specific files are ignored by
default)
* in the long run it's best to standardize on a single patch system (new
contributors need to learn a single system, more people can help you,
etc.) and quilt appears to be that patch system.

=== How to convert a source package? ===

You need to put "3.0 (quilt)" or "3.0 (native)" in debian/source/format to
indicate the desired format to dpkg-source (see the dpkg-source(1) manual
page for more information).

Native packages should not need any other change.

When you switch to "3.0 (quilt)", there are other changes that you might
want to do:
* If your .diff.gz modifies upstream files, you should really put those
changes in separate quilt patches first, otherwise all those changes
will be merged in a single quilt patch named
debian/patches/debian-changes-<version>. Consider documenting those
patches by following DEP-3[1].
* If you use another patch system (like dpatch or dbs), consider
switching to quilt (you can then simplify your debian/rules, see next
point).
* You can remove everything related to quilt in debian/rules
(patch/unpatch logic, cleanup of quilt stamp file and its .pc
directory).

=== Does a 3.0 (quilt) source package need to build-depend on quilt? ===

If you drop the quilt usage in debian/rules (patch/unpatch logic), then no.

=== Is the README.source file needed with 3.0 (quilt) source packages? ===

No. Since dpkg-source -x applies the patch, you don't have to explain how
the patch system works. If lintian gives you the
patch-system-but-no-source-readme warning, upgrade to the latest version
in sid.

=== Other questions ? ===

Read the full FAQ in the wiki and the dpkg-source(1) manual page. If you
still have questions, please ask on debian-devel@....

Thank you for your attention.

[1] http://dep.debian.net/deps/dep3/
[2] http://wiki.debian.org/ReleaseGoals/NewDebFormats
http://release.debian.org/squeeze/goals.txt
--
Raphaël Hertzog

signature.asc (537 bytes) Download Attachment

some mail handling updates

2009-11-16T14:23:02Z

Hello everyone,

Over the past year or two, lots of changes have been made to the mail
handling for user mail accounts, and there are plenty of other changes
planned for the future. All the changes below do not affect liszt or
alioth.

Some notable changes:
- A single mail configuration template for all d.o machines
- The busier machines use clamav with 3rd party signatures for scanning
mail
- packages.d.o uses spamassassin on all mail at smtp time
- The BTS uses greylisting
- Most machines now route through a set of gateway MXes for inbound and
outbound delivery, letting those machines spend more time doing what
they're meant to and less time fighting spam.

- Users can set the envelope for their mail
- Users can decide whether a mail should be rejected, marked up, or
blackholed if it gets a 'hit' during content inspection

- Teams can have group writable mboxes or not
- Teams can use the same anti-spam techniques (RBLs, callouts,
greylisting, etc) as regular user accounts.
- Teams can have some aliases be only addressable from within the d.o
estate

Things planned for the future:
- Breaking up the conflation between @debian.org and @$machine.debian.org
mail handling (more on this in a seperate mail)
- BATV checking (there is support in ud-ldap, just not yet in the exim
configuration)
- Users can decide to opt out of the default anti-spam setup in place.

One of the happy side effects of this is a substantial reduction in spam
across the estate. We've stopped accepting roughly half a million mails
a day that were obviously spam, although of course we can do better.
One way you can help yourself is to log in to db.debian.org and select
the anti-spam options you feel would be helpful for your account.
For DNSBLs and RHSBLs, you'll need to use the mail gateway, as there is
not yet support in the web interface.

More notes on what the various fields mean and how they will be used can
seen in the very meager documentation [0] and more accurately here [1].

Cheers,
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@... |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
[0] http://db.debian.org/doc-mail-handling.html
[1] http://git.debian.org/?p=mirror/dsa-puppet.git;a=tree;f=modules/exim;h=HEAD

signature.asc (196 bytes) Download Attachment

Bits from the FTPMaster meeting

2009-11-15T07:15:35Z

Hello Debian world.

Meeting
-------
Your beloved FTP Team had a meeting in the Essener LinuxHotel[1] during
the last week of October. A lot has been achieved during this meeting
and we would like to take this opportunity to thank our hosts from the
LinuxHotel for the nice environment as well as every Debian Developer,
Maintainer and interested for their patience during the time of reduced
archive service.

During this meeting more than half of our codebase got changed and
multiple outstanding and intrusive patches got merged. We also discussed
various outstanding topics, a few of which we can report about already,
a few others where we still have to gather more information. This
process, either asking our lawyers or various other people, has already
been started.

dpkg v3 source format, compression
----------------------------------
As many already noticed, our archive now additionally supports 3.0
(quilt) and 3.0 (native) source package formats. You can use either
gzip as usual or bzip2 for the compression within the binary packages -
and now also for the source files. We do not support lzma as a
compressor, as the format is already dead again. After squeeze we will
probably add support for its successor, xz.

Currently there are no plans to support the 3.0 git or bzr formats.

incoming.debian.org
-------------------
The public view of incoming.debian.org has changed. Due to internal
changes in dak, queue/accepted no longer exists so we generate a
public view in the same way as the hidden buildd queues were always
generated. This change means that packages will stay visible on
incoming.debian.org for a short time after they enter the pool
and are pushed to the mirrors (which removes the old problem whereby
during dinstall packages would vanish from incoming but not yet
be visible in the pool). As a couple of people have commented, the
changes files are no longer part of this view. It's possible that
in the future we will add them back, but the same information is
available on debian-devel-changes@... and we would
need to make some small architectural changes to add the .changes
files back.

Another side-effect of this work is that it will now be possible
to autobuild suites other than unstable from 'accepted'. This will
require work and discussion with the buildd team as to how they
want to handle it.

IRC
---
The channel #debian-ftp is now open to the public as a way of
contacting members of the ftp-team, but not for random discussions.
Please, help us keep the channel well focused and on-topic.

source-only uploads
-------------------
After some discussion about this, there are two opinions within the
ftp-team about this matter. Given that other distros experience has
shown that allowing source only uploads results in a huge loss of
quality checks and an increased load on the buildds from packages
FTBFSing everywhere, some members of the team believe that source+binary
uploads should happen as currently, but that the maintainer built
binaries should be rebuilt by the buildds (i.e. be thrown away at accept
time). Other members of the team think that we should allow source-only
uploads and that if some people keep uploading packages which FTBFS
everywhere (showing a lack of basic testing), this should be dealt with
by the project in other ways which are out of the scope of the ftp-team.

The current "winning" opinion is to go with the source+throw away
binaries route. We are close to being able to achieve this, it is
simply that it has not yet been enabled. Before any version of this
can be enabled, buildd autosigning needs to be implemented in order
that dak can differentiate buildd uploads vs maintainer uploads.

Provisions have been made in dak for things such as bootstrapping a
new architecture where binary uploads from porters may be necessary
in order to get going.

lintian autorejects
-------------------
Now turned on. lintian tags available in yaml format from
http://ftp-master.debian.org/static/lintian.tags

"Inline" signed Release files
-----------------------------
We now have a second Release file on our mirrors, called InRelease. The
only difference to Release is that the signature is not detached, but
within the file. This is a first step towards getting rid of race
conditions when updating Packages/Sources files and mirror updates
running. After squeeze we will change to have more than one generation
of Packages/Sources files on the mirror (likely the last 3) and have
them all included. This will require discussion with the apt
(and other relevant) maintainers about how this should be implemented.

--rsyncable
-----------
We enabled all gzip content to be generated using --rsyncable
(Packages, Sources, Contents, indices/). This gives a slight increase
in size but a huge decrease in neccessary bandwidth used by the mirror
sync.

The extra source case
---------------------
This issue is the one traditionally known as the linux-modules-extra
problem but also exists for some compiler packages and in the past
existed for things such as apache2-mpm-itk and so is a more general
problem. It exists where a package needs to use source from another
package in order to build. This is normally done by creating a -source
binary package and Build-Depending on it (this is of course ugly in its
own right, but let's fix one thing at a time). The problem is that dak
then has no idea that we need to keep the extra source(s) around on the
mirror whilst that binary package is still available. We intend to fix
this by introducing a way of packages declaring that they were
Built-Using a certain source package,version and then tracking that to
ensure that the sources are kept around properly. The changes in dak
which are needed are now relatively small and a proposal will be posted
to debian-devel soon which will outline how we hope that this will work.

Tracking arch all packages
--------------------------
#246992 asked us to not delete arch all packages before the
corresponding (if any) arch any packages are available for all
architectures. Example: whenever a new source package for emacs23
gets uploaded the installation of the metapackage emacs_*_all.deb
breaks on most architectures until the needed Architecture: any
packages like emacs23 get built by the buildds. That happens because
dak removes all arch: all packages but the newest one.

While this behaviour is easily documented and one can easily devise a
fix ("just keep the arch all until the any is there, stupid"), the
actual implementation of it contains several nasty corner cases
which is why it took so long to fix.

Thankfully Torsten Werner took on this task during the meeting [2] and
we are now in a position where we can merge his work. We'll email
before turning on this feature so that people can watch out of any
strange cases which could cause problems.

NEW/Byhand
----------
Due to the massive changes in the archive, NEW (and also Byhand) had to
be disabled. Certain assumptions made by the processing tools no longer
applied. The last week was used to work on this issue and we think this
will be fixed today, so NEW processing will return to its normal speed
soon.

[1] http://www.linuxhotel.de
[2] http://ftp-master.debian.org/wiki/projects/arch-all-tracking/

--
bye, Joerg, for the FTP Team.
<madduck> and yes, the ftpmasters are not the most clueful people

attachment0 (265 bytes) Download Attachment

Bits from the ftp-team

2009-11-03T06:14:16Z

Hi,

Just a quick update on goings on in ftpmaster after the meeting last week.
We'll be sending out a full report as soon as we've finished writing it, but we
wanted to make people aware of a few things.

First of all, the following parts of the archive are temporarily
non-functional:

* NEW processing (sometime this week)
* {o-,}p-u-new to {o-,}p-u migration (sometime this week)

These two just need some converting to handle the new way of processing
packages. Members of the ftpteam are already working on patches to the code
and it should be done sometime this week.

* queue cleaning
* suite cleaning

Likewise, this is simply an update to take into account internal changes in the
way dak handles the buildd queue (and incoming.debian.org, the public view of
what has recently been accepted). These changes will however allow us to make
suites other than unstable available for building as seperate queues in the
same way as unstable is handled (where appropriate and wanted). We're hoping
to have these fixed either today or tomorrow morning to avoid the queues
growing out of control.

* new fingerprint importing

This is a relatively trivial to fix and is just a path / database mismatch, but
we want to check that nowhere else in the code will be affected. Should be
done by the end of the week.

One final announcement for now is that #debian-ftp is now an open channel. In
future, requests which used to involve pinging random members of the ftp-team
and hoping they were available should be directed to this channel. The channel
should be considered analagous to #debian-release or #debian-admin in that it's
not a general discussion and chat channel, but people are welcome to idle there
as long as this is remembered. The rationale for this is that too much traffic
on the channel will defeat its purpose which is for the ftp-team to jump to it
should they see any activity on it.

Thanks for your patience with all of these changes.

Cheers,

Mark
(on behalf of the ftp-team)

signature.asc (196 bytes) Download Attachment

DebConf10 to take place in New York City, USA in August 2010

2009-10-30T12:04:43Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

~~~ October 30, 2009 : PRESS RELEASE ~~~

FOR IMMEDIATE RELEASE

DebConf10 to take place in New York City, USA in August 2010
============================================================

* Annual Debian conference to take place August 1-7, 2010
* Hosted in New York City; first time ever in the United States
* General public invited to day of talks about Debian and Free Software
* Call for papers, registration to open in January 2010

New York City, USA, October 30, 2009 - The Debian Project,
the team behind the free Debian GNU/Linux operating system,
confirmed the dates and venue for its next annual conference,
DebConf10.

The conference will take place from August 1 to 7, 2010, at Columbia
University, in New York City, USA, in cooperation with the Columbia
Computer Science department. In DebConf's eleven-year
history, this will be the first time it has been held in the
United States of America.

Every year, DebConf allows new and existing Debian project participants
from around the world to assemble, share knowledge, make collaborative
contributions to Debian, and build tighter community bonds. Conference
costs are largely funded by corporate sponsors who find significant
value in enabling Debian's success.

"The Debian community in New York City is excited to welcome our
colleagues from around the world to join us for this rewarding and
productive conference," says Jimmy Kaplowitz, leader of the local team
for DebConf10. "We look forward to energizing North American Debian
contributors and introducing interested users to ways they can give back
to Debian, making it an even better operating system and an even better
community."

DebConf will include a day when it opens its doors to the general
public. There will be talks and demonstrations about the benefits
of Debian and Free and Open Source software in general to corporate,
governmental, academic, and individual users.

The call for papers and registration will open in January 2010.

DebConf10 will be preceded by DebCamp, the yearly developer work
sessions, starting on July 25.

Information about DebConf10 is updated at
http://debconf10.debconf.org as it becomes available.

ABOUT DEBIAN

Debian GNU/Linux is a free computer operating system. Over three
thousand volunteers from all over the world work together to create
and maintain Debian software. Translated into 27 languages, and
supporting a huge range of computer types, Debian calls itself the
"universal operating system". In the United States, Debian is backed
by Software in the Public Interest, Inc., a not-for-profit public
charity as described in section 501(c)(3) of the Internal Revenue
Code.

ABOUT DEBCONF

DebConf is the annual Debian conference, which has taken place since
2000 in places as varied as Canada, Finland, and Argentina. Several
hundred developers, contributors, and users gather each year at
a new location to further ideas, cooperate, and socialize. More
information about DebConf is available from http://debconf.org.

FOR FURTHER INFORMATION PLEASE CONTACT

DebConf press team
press@...
http://debconf10.debconf.org/

Americas: Europe / Middle East / Africa / Asia / Pacific:
Jimmy Kaplowitz Martin Krafft
jimmy@... madduck@...
Tel: +1 347 277 1465 Tel: +41 32 5119511

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

iQIcBAEBCgAGBQJK6iXkAAoJEGT+wHBUdj6bnS8P/i5Dhqfd1W1Hc4CfGuc5jX21
XlVbEeFvEiKfzTnmcKZQ83ff3/x/ggdjmNJvqgODJBcOOZShIp5Fo5ALBHSYa5Xe
uOUp+Xlkv2UpepW7dpvdGRLga7Zzr92VPHrpAgwQmmfGSKgizd+Bzr8a8bq3PJQg
ntDMnkSYc5fvyrIUt+pNIhnXCswKa5FFlPEGcfQ4ckJxkJ0YkAijwZmGzuovOilp
IrrLEGXSQgLFm/UYJH68CTyEahn2OinS9yjiUNfFg7fT7sj/119rmiT6bx3EjnlA
t1eJS9BTnK18v18M+RSdW1Jv8ORH+FzLpkKQVeO0gofif7vA/3FOWoxDBQGeHQKz
EahQyYKLIfk1EcvrSG29hMmmusmUQlE6rGcrAe+DgD9w6ofwSE6w1GQ3Cft27dMM
H2sT7SIDLHZ5z9QrnfgRLhJkw1MMtYSZCnughh63rF+VfBTTTbmCwykBG2TFx9iJ
LzyTj9fjRgm+GE9OF/MVJ/SmQogUYLXhLx9E555v9P3aWIuIquqMJWXov8LwXEE9
3mdOKE1bzf5TbWbonlTEnNXskXC4hrW+ZBxV8vFN3rinOgwXfMXBc1j0WBhsuC/w
2IzH7it4jxGDvYFTX0Cr6OaxN2grqDwUaum5NjXr3K4suSDnA9pMaFKTK3XA8l0P
apCjt26v6ucVcDfY8x0h
=uXBa
-----END PGP SIGNATURE-----

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

Lintian based autorejects

2009-10-27T07:06:07Z

Heyho,

we are turning on lintian based autorejects within the next few days.
This means that packages failing a defined set of lintian tags will no
longer be accepted into the archive, but get rejected immediately.
This should help to get rid of the worst policy violations before
wasting time and resources of other people.

Those automated rejects will only be done on sourceful uploads to
unstable and experimental.

As there are certain lintian tags that should only appear in very rare
cases we have created two categories. The first is named "warning", tags
listed here *can* be overriden by the maintainer using the normal
lintian override mechanism. Of course this should only be done if you
have a technically sound reason why your package needs to break in such a
way.

The second category is named "error" and the tags listed can not be
overridden. Those are tags corresponding to packaging errors serious
enough to mark a package unfit for the archive and should never happen.
In fact, most of the tags listed do not appear in our archive
currently, the few packages listed below should be easily fixable with
their next upload.

We will provide a static url for the list of tags soon, for now you can
look at them using [1].

There are multiple files in [2] showing you the packages affected,
together with the tags they hit.

[1] http://ftp-master.debian.org/~joerg/lintian/lintian.tags
[2] http://ftp-master.debian.org/~joerg/lintian/

For future handling: If we are adding tags to the list that will hit
more than a few packages we will send a notice to the d-d-a list.

If you think we should add tags or categorize them differently, feel
free to mail us at ftpmaster@....

--
bye, Joerg
> But i don't think that we talk a lot, as far as i can see, you live in
> the USA.
Australia. Only minor details like timezone and hemisphere but pretty
much the same. TZ is UTC+10

attachment0 (202 bytes) Download Attachment

Bits from the kernel team

2009-10-19T14:54:47Z

The Debian Kernel team recently had a series of face to face meetings
during the Linux Plumbers Conference [1].

The DPL managed to arrange for the whole team to be present in Oregon
at the same time, a representative of the release team was also present.

The LPC conference venue allowed the kernel team to interact with the
upstream developers and other distributions kernel teams in an
positive and productive way.

The Debian kernel team meetings ran over four days and covered a large
number of topics, the abridged minutes are presented here, the full
meeting minutes are also available [2].

Co-operation and version synchronisation with other distributions
-----------------------------------------------------------------

This discussion involved timing of the Debian freeze and what
implications this might have on the kernel version selected for
squeeze. The version selected by other distributions was also
discussed.

In conclusion the 2.6.32 release will probably be the initial kernel
version shipped with squeeze.

Separate firmware, what is left to do?
--------------------------------------

A constructive discussion was held about the outstanding firmware
issues, how the team addresses them and how we might work with upstream
to address our DSFG issues with kernel sources.

Kernel Mode Setting transition
------------------------------

It was resolved that KMS will be enabled at build time but disabled at
run time by default. The X packages will be able to use modprobe
config files to enable KMS at run time as required.

Feature patches
---------------

These are patches the Debian kernels have for major features which are
not upstream.

openvz
++++++

Debian will continue to support this system with assistance from the
openvz developers.

rt patchset
+++++++++++

This is apparently not ready for production use and will not be
present in Debian kernels.

vserver
+++++++

This feature will be present in squeeze but will be marked as
deprecated and a migration path to Linux containers investigated.

xen dom 0
+++++++++

This feature will be included in the squeeze kernel release subject to
ongoing stabilisation work. The feature will be marked as deprecated
and will not appear in future releases.

IDE to libata decision
----------------------

Debian will perform this transition using the udev packages in a
similar way to Ubuntu. The Ubuntu developers have offered their
assistance with this transition.

preemption
----------

This feature will be enabled for the squeeze release.

OSS
---

This has been a deprecated kernel interface for some time and will be
disabled for squeeze with mechanisms put in place to deal with legacy
users.

bug triage and tagging
----------------------

The kernel team has a large number of bugs, many of which contain
inadequate information. The team decided that a policy for bugs and
patches will be produced and enforced. We will also be improving the
bug reporting by improving the reportbug usage.

Moving the Debian Kernel packaging to Git
-----------------------------------------

A robust discussion happened with several views and ideas
expressed. The final outcome was that the team as a whole favoured the
move to git and that further investigation and implementation would
occur.

Coordination with release team and D-I
--------------------------------------

Several issues were covered the main item from this session was an
investigation as to if udeb generation should be merged with the main
kernel source package.

Out of tree modules
-------------------

After some discussion it was resolved to remove linux-modules-extra
and -nonfree as they are an impossible to support properly.

A few modules the project really must have will be placed
directly into the linux-2.6 source

The kernel team will endorse the use of dkms as a way for out-of-tree
module maintainers to get their modules auto-built.

Leveraging upstream .deb building
---------------------------------

This became a discussion about the general kernel packaging and how we
might use the upstream provided facilities better. There was some
discussion we have way too many ways to build a kernel.

We will be rationalising this to two methods, an upstream merged "make
deb-pkg" target and the linux-2.6 Debian source.

We will also be rationalising the kernel postinst and co-ordinating
our efforts with the Ubuntu developers.

New lists to co-ordinate
------------------------

There is a mailing list which we might resurrect for general
distribution co-ordination

kernel-packagers@...

And a list the Debian kernel team might want to join to co-ordinate with Ubuntu

kernel-team@...

Debug Packages
--------------

This refers to debugging information from current packages, not a
separate configuration, useful for crash tools. This will be
investigated further.

Automated build and test
------------------------

This might be a useful tool in the future and work is ongoing.

Experimental
------------

Some upload experimental uploads of the 2.6.31 version will be made.

[1] http://linuxplumbersconf.org/2009/
[2] http://lists.debian.org/debian-kernel/2009/10/msg00613.html

signature.asc (196 bytes) Download Attachment

Bits from the release team: Planning, request for help

2009-10-18T09:16:10Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

Release planning
================
Proposing a new freeze date is not easy. Taking into account all of
the feedback we have received, both online (by e-mail, IRC) as well as
in person, and some challenging release goals we have set for ourselves,
we propose freezing in March 2010.

Request for help
================
As in our previous update, we want to stress that the state
of unstable and testing is not very good. We still have a large number
of Release Critical bugs and problems ensuring the smooth
transition of packages to testing.

To get the number of RC bugs down, we will be more aggressively
removing fringe packages from testing and request your help in
fixing bugs, following the build status of your packages and
organising bug squashing parties (BSPs [0][1][2]).

In order to help ensure the smooth migration to testing of packages
involved in library transitions, we ask you to try to avoid uploading
packages when doing so would disturb an existing transition. Executing
``grep-excuses <pkg>'' (from the devscripts package) before uploading
can help a lot.

If you are interested in helping or joining the Release Team, please
contact us (in private or public) and we'll see how to make it work.

Please don't hesitate to contact us if you have any questions.

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

[0] http://wiki.debian.org/BSP
[1] http://wiki.debian.org/BSP2009/CambridgeNovember
[2] http://wiki.debian.org/BSP2010/Moenchengladbach

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

iEYEARECAAYFAkrbP0kACgkQ5UTeB5t8Mo20JACfSGv5AzY+KWhrqE4Byr87baAt
SzYAn06ud/VpVFCyfcxztKbndRzoYmsF
=n2BV
-----END PGP SIGNATURE-----

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

Misc developer news (#18)

2009-10-09T03:35:51Z

The news are collected on http://wiki.debian.org/DeveloperNews
Please contribute short news about your work/plans/subproject.

In this issue:
+ 3-way merge of debian/changelog files
+ Pending security issues now shown in PTS pages
+ DEP-3 updated for compatibility with git format-patch
+ debian-devel and ITPs
+ wiki.debian.org bugstatus

3-way merge of debian/changelog files
-------------------------------------

A new script doing smart 3-way merges of Debian changelog files has been
announced[1]. Git can be configured to use it automatically, and will
thus avoid the usual conflicts generated by the standard line-based
merge.

-- Raphaël Hertzog

[1] http://www.ouaza.com/wp/2009/10/08/3-way-merge-of-debian-changelog-files/

Pending security issues now shown in PTS pages
----------------------------------------------

Thanks to a patch by Raphael Geissert, the PTS
(http://packages.qa.debian.org) is now properly integrated with the
security tracker (http://security-tracker.debian.net): packages pages
will show the number of pending security issues (if any) that should be
addressed for a given source package.

-- Stefano Zacchiroli

DEP-3 updated for compatibility with git format-patch
-----------------------------------------------------

The recently announced Patch Tagging Guidelines[2] have been updated for
better compatibility with git format-patch and other VCS exchanging
changesets as mails. Please consider using this format and feel free to
share your comments on its usage.

-- Raphaël Hertzog

[2] http://dep.debian.net/deps/dep3/

debian-devel and ITPs
---------------------

At DebConf9 there was a discussion about making the debian-devel list
more useful. Towards that end, here is a quick reminder of the
recommendations in the developers reference section 5.1[3]. Please do not
sent ITPs for multiple packages to debian-devel, instead, please file the
ITPs and send a summary to debian-devel afterwards. This is especially
true for multiple packages that are related in some way.

-- Paul Wise

[3] http://www.debian.org/doc/developers-reference/pkgs.html#newpackage

wiki.debian.org bugstatus
-------------------------

The Debian wiki now uses some JavaScript to update wiki pages containing
DebianBug:123456 links such that closed bugs are differentiated from
open bugs by a strike through. In addition, the mouseover title is set to
the bug status + fixed versions + bug number + bug subject. This feature
was initiated and coded by Max Vozeler (mvz) of the debian-installer
team, who wanted to use it on their squeeze goals[4] wiki page.
Implementation details can be found in the git repository of the Debian
wiki team[5]. The wiki team are also looking for someone to design dead
bug and live bug icons[6] that can be used to replace the normal
interwiki icons. If you would like to help convert existing bugs on the
wiki to DebianBug:123456 links, please see the list of wiki page
candidates for DebianBugification[7].

-- Paul Wise

[4] http://wiki.debian.org/DebianInstaller/SqueezeGoals
[5] http://wiki.debian.org/Teams/DebianWiki
[6] http://art.debian.net/?ccm=/media/thread/24
[7] http://lists.debian.org/debian-www/2009/08/msg00154.html

--
Raphaël Hertzog

signature.asc (537 bytes) Download Attachment

Release architectures

2009-10-07T08:21:32Z

Hi,

since our recent release update, things have been moving a bit. We'd
like to give you the basic status of all our architectures for
Squeeze, for details please see the individual mails (and "basic
status" doesn't cover all details of course).

kfreebsd
~~~~~~~~

It looks like we could really release Squeeze with both a Linux port
and a non-Linux port (i.e. kfreebsd-{amd64,i386}. However, we still
have about 250 packages in Squeeze which are not installable due to
missing dependencies, and 4000 packages not at all in Squeeze for
kfreebsd. On the other hand, most of the issues are just "part of a
larger transition" and will clear up by itself over time. Also there
are good news on the debian-installer for kfreebsd. In all, the port
looks very promising, but of course there are still many topics to
tackle.

For this reason, our testing migration scripts will soon start to
treat out-of-date on kfreebsd as a blocking issue for testing
migration. Also normal bug severities apply now for kfreebsd-specific
bugs (meaning: there could be RC-bugs that are specific for kfreebsd).

We will however still allow testing migrations to happen which
increase the count of uninstallable packages on kfreebsd only, as the
uninstallability-count needs to be a bit lower to turn that off -
nothing too dramatic should happen there though.

alpha
~~~~~

After we sent mails to debian-alpha last month we came together with
the porters to the conclusion that we cannot keep up this port for
Squeeze. We will start purging the packages from testing in about a
fortnight. Bugs specific to alpha are no longer release critical.

amd64
~~~~~

Everything ok.

armel
~~~~~

The buildd speed isn't always as wanted, but work is underway to
replace machines with newer hardware. Also there are discussions on
getting the buildds within DSA-control after that; we would appreciate
that. Anyways, nothing really worries us.

hppa
~~~~

Porters have pushed this architecture much forward. The architecture
looks overall quite better than it did 6 weeks ago. We hope that this
continues this way. Contrary to what we discussed, we will not push
hppa to "out-of-date-packages are ok" for testing migration at this
time. There is no final decision yet from our side, but we want to
avoid the additional effort that putting hppa to "out-of-date-packages
are ok" requires from the porters. However to be included within
Squeeze, more issues like e.g. the current stability problems need to
be resolved.

i386
~~~~

Everything ok.

mips*
~~~~~

Mipsel is also suffering from low buildd speed sometimes, but new
boards are currently being shipped to hosting, so this should resolve
soon. We don't expect really issues for Squeeze.

powerpc
~~~~~~~

Nothing to worry right now.

s390
~~~~

Porters spoke to us that there are issues to worry about, especially
lack of access to newer hardware. We received generous offers from
users of that port, so we currently assume that the issues will be
resolved in time for Squeeze. We would like to get buildds DSAed on
this architecture as well.

sparc
~~~~~

Nothing that needs to worry us for Squeeze but only long-term is how
to transition sparc to sparc64. Upstream slowly starts to consider
sparc(32) outdated and deprecated, and we need to get to an decision
how to deal with that. Might be that multiarch is part of the answer,
but deciding what the best answer is needs to be done by porters, and
the answer should be given pre-Squeeze (doesn't necessarily need to be
fully implemented).

Cheers,
Andi
Debian Release Team

signature.asc (204 bytes) Download Attachment

(Overdue) bits from keyring-maint

2009-09-28T14:27:34Z

Hi.

It's been a few months, various things have happened and so it's
probably time for another keyring-maint update.

New keyring-maint member
========================

First up I'd like to welcome Gunnar Wolf to keyring-maint. I've been
aware for some time (and if I hadn't been there were plenty of people
reminding me ;) that with just one person working on it keyring was at
risk of becoming a bottleneck, so I took the opportunity at DebConf to
have a few discussions about people who could possibly help out. Gunnar
has foolishly^Wgraciously stepped up to the plate and has been putting
up with various brain dump emails from me about how things work. The
plan is we'll get these tidied up and made public for reference, but at
present we're working on getting him fully up to speed as a priority.

(If you weren't at DebConf you can see how it happened at [0].)

PGPv3 removal continues
=======================

I mentioned back in May[1] that I'd started chasing DDs with both v3 and
v4 keys in our keyrings about removing the v3 keys. Many people
responded and confirmed it was ok to remove the v3 key immediately. A
few stragglers wanted to hold off and check things out. And
unfortunately a few failed to reply to repeated mails and I submitted
them to the MIA team for investigation. I've now extended my reach to
all remaining v3 keys, asking people if they have a suitable v4 key and
pointing them at instructions for creating a new one if not. We're down
to 58 v3 keys; if you're one of them and haven't reply to my mail please
do so. It would be great if we could get rid of them all by Christmas.

SHA2 capable key replacements
=============================

Various key updates have been trickling in (moreso post DebConf)
updating keys to be SHA2 capable. I've been pushing back a bit on those
keys that aren't particularly well signed and so far I think the WoT is
keeping reasonably strong[2]. Please do make an effort to try and get you
key as well signed as possible before requesting replacement.

DM keyring added to keyring.debian.org
======================================

Another positive thing to come from discussions at DebConf was moving
the Debian Maintainers keyring to be part of keyring.debian.org. This
means it is distributed around the debian.org infrastructure in the same
way as the DD keyring. The FTP masters have already taken advantage of
this by enabling DM uploads on various extra upload queues[3]. Decisions
about DMs are still made by the DM admin team; keyring-maint is merely
responsible for acting on their requests to add new keys.

J.

[0] http://gwolf.org/blog/keyringmaint-addme
[1] http://lists.debian.org/debian-devel-announce/2009/05/msg00005.html
[2] http://keyring.debian.org/stats/
[3] http://lists.debian.org/debian-devel-announce/2009/08/msg00010.html

--
I am afraid of the dark.
This .sig brought to you by the letter L and the number 10
Product of the Republic of HuggieTag

signature.asc (852 bytes) Download Attachment

cupt, the APT competitor

2009-09-22T02:52:14Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- ---------------
The short story
- ---------------

This mail is to inform that Debian APT suite now has a competitor named Cupt [1].

[1] http://wiki.debian.org/Cupt

- --------------
The long story
- --------------

Some time ago (winter 2008), after working some time on APT suite, I started
to develop Cupt to substitute APT for myself in areas where APT fails due to
design or implementation problems.

I just uploaded cupt 1.0.0~beta1 to unstable claiming that most of obvious
(and not so obvious) bugs has been ironed out (thanks to people who helped me
to do that). I will, of course, appreciate excessive testing.

Indeed, I am aware and understand that considering a big number of apt reverse
dependencies and some missing features Cupt cannot serve as a drop-in APT
replacement, far from it. Nevertheless, I hope it can be useful even at the
current stage. The list of prominent features and limitations is present on [1].

- --
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer

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

iEYEARECAAYFAkq4nk4ACgkQchorMMFUmYxazACgzF6PGLKRwofAOzdS2vqJP3D1
MNsAoKEiaWwnPUmJtIAdeVHoEj3bikaB
=7dpX
-----END PGP SIGNATURE-----

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

Changes in the maintenance of the Developers Reference

2009-09-21T00:56:37Z

Hi,

Following a discussion on debian-devel@...[1], the way the Developers
Reference[2] is maintained has been changed, with the aim to make it
more public and easier for people to contribute.

Changes to developers-reference are now discussed on debian-policy@...
(also used for debian-policy). Don't hesitate to jump in and contribute
to the discussions.

Also, patches for developers-reference are very welcomed. In particular,
it would be great if new (or not so new) packaging practices were more
documented, like packaging processes with the various VCSes, cdbs and
dh, patch systems, etc. Some teams have already written some
documentation about that, and it could probably be gathered in
developers-reference.

Finally, we could use the help from one or two other editors. Their role
is to direct the discussions around the patches, and integrate them into
developers-reference. If you want to help, contact the current
maintainers and participate in the discussions on debian-policy@.

Lucas, for the developers-reference maintainers

[1] http://lists.debian.org/debian-devel/2009/09/msg00293.html
[2] http://www.debian.org/doc/developers-reference/

signature.asc (196 bytes) Download Attachment

debmirror - new features

2009-09-12T01:31:34Z

As debmirror is a native package that may interest developers I thought a
quick announcement here is appropriate.

I uploaded version 2.2 earlier this morning. In comparison with the lenny
version, this introduces the following new features:

* Automatic creation and update of suite->codename symlinks (1.0)
* Option to cache the mirror state between runs (2.0)
* Significant speed increase for parsing Packages/Sources files (2.0)
* Mirroring of "current" Debian Installer images (2.0)
* Mirroring additional files from specific directories (2.1)
* Mirroring translation files (2.2)

For additional details, see my blog:
http://alioth.debian.org/~fjp/log/posts/debmirror_II_-_Overview_of_new_features.html

Note that debmirror is intended to be used for creating (partial) local
mirrors, not for official mirrors of the archive.

Cheers,
FJP

signature.asc (204 bytes) Download Attachment

Distro Summit 2010: Call for Papers

2009-09-09T08:18:29Z

===============
CALL FOR PAPERS
===============

Distro Summit 2010 is a one-day technical conference with a strong focus on
collaboration between Free Software distributions. The event is hosted at
the linux.conf.au, which will be held in Wellington (New Zealand) on the
18-23 of January, 2010.

We are looking for proposals from any Free Software distribution, from the
typical full distributions (both linux and non-linux) to the niche market
derivatives.

In spite of the strong focus on collaboration between Free Software
distributions, topics may include packaging, maintenance, relationship with
upstream developers, release management and QA.

For more informtion, please visit: http://distrosummit.org.

Important dates
===============

* Call for papers ends: Wednesday 30 September 2009
* Announcing the schedule: Friday 2 October 2009
* Distro Summit 2010: 18/19 January 2010

Presentation types
==================

We will accept proposals for:

* 25 minute standard-length presentations;
* 50 minute long presentations.

Session lengths include time for audience questions.

We intend for standard-length presentation to make up the vast majority of our
presentations. If you plan on submitting a proposal for a long presentation, a
willingness to present a standard-length presentation will impact positively on
your proposal.

Submit a proposal
=================

To submit your proposal, we'll need the following information:

* Your name, contact details and a short biography;
* Your proposal title;
* Intended audience;
* An abstract;
* Presentation outline;
* Presentation type (standard-length or long).

To submit a proposal, or get more information, please write to
cfp@....

About the Distro Summit
=======================

The Distro Summit 2010 is a one-day developer conference with a strong focus on
collaboration between free software distributions hosted at the linux.conf.au
2010 (http://www.lca2010.org.nz). In addition to a schedule of technical,
social and policy talks, the Distro Summit provides an opportunity for
developers, contributors and other interested people to meet in person and work
together more closely.

Previous similar events have featured speakers from around the world. They have
also been extremely beneficial for developing key free software software
components and for improving collaboration and sharing between the different
distributions.

Target Audience
===============

The Distro Summit is (mainly) a technical event, but this does not mean that
the only target audience are developers and maintainers of free software
distributions: the event will feature talks that range from the development to
real-world use cases, going through marketing and the social aspects of the
maintenance of free software distributions.

--
Fabio Tranchitella
on the behalf of the Distro Summit organizers

signature.asc (204 bytes) Download Attachment

Patch Tagging Guidelines (aka DEP3)

2009-09-07T14:03:37Z

Hello,

after several rounds of discussion on -devel, we now have a
new standard defining meta-information to integrate on patches that we
distribute/apply in our packages:
http://dep.debian.net/deps/dep3/

I just changed the status of this Debian Enhancement Proposal to
CANDIDATE, that means that you are all encouraged to make use of it and
try it out for real. Hopefully, http://patch-tracker.debian.org will gain
support of this format and will allow smarter browsing based on those
information.

You are welcome to share your feedback about this format on -devel, if we
identify shortcomings or possible enhancements, we can still update
the proposal (but only after we had time to get some real feedback
based on actual usage of this format).

Feel free to update (Debian specific) tools that generate patches to
auto-generate a DEP3 header ready to be filled by the maintainer. Using
the format is a clear step forward towards more transparency on our local
changes, but it should not be difficul to use, thus some integration in
our tools is welcome.

Cheers,
--
Raphaël Hertzog

signature.asc (537 bytes) Download Attachment

Release Team, BTS, and debian-release@ policy.

2009-09-06T09:48:07Z

To help with the tracking of the numerous issues the Release Team has to deal
with, we decided to make use of the release.debian.org pseudo-package on the
BTS[1]. It will help us to avoid missing requests, which sadly happens a bit
too often for our taste.

BTS Usertags
============

To help triaging bugs, the Release Team will use the following usertags:

binnmu: for ... wait for it ... binnmu requests.

transition: transition tracking stuff.

unblock, freeze-exception:
to use for unblock or freeze-exception requests.

opu, pu: for oldstable and stable proposed updates upload requests.

rm: for oldstable, stable or testing removal requests.

Also some more obscure ones:

britney: for britney (aka the script responsible for testing
migrations) bugs, wishlists or feature requests.

tools: for bugs related to various Release Team tools.

To help you with this, the latest reportbug (4.7) has been patched to
deal with release.debian.org and provide proper questioning templates
for all those usertags.

Also, to help people be able to follow who in the Release Team is
responsible for tackling a specific issue, the BTS "owner" feature will
be used with the address of the Release Team member following the task.
This will be particularly useful for long lived bugs, like transition
tracking bugs.

BTS policy
==========

Most of the bugs you will report will have a very short history. Though,
some will need more exchanges (controversial unblock requests, long
transitions, ...). So that the history isn't cluttered with discussion,
we will ask you to only log status changes or facts relevant to the
request. Any discussion about the request should happen on list[2].

List policy
===========

The Release Team list policy has long been “this is not a discussion
list, please go elsewhere”. The reason has been that with too much
discussion, it's easy to lose track of the release related requests.
With the BTS, we hope this will not happen anymore. That's why we're
considering relaxing the list policy to enclose matters like Release
Goals discussions, arch qualifications, and similar matters.

Thanks
======

We'd like to thank Don Armstrong and Sandro Tosi for their help
preparing the BTS and reportbug for this.

On behalf of the Release Team,
Pierre

[1] http://bugs.debian.org/release.debian.org
[2] debian-release@... of course

signature.asc (204 bytes) Download Attachment

DebConf10 visa information available

2009-09-06T08:49:31Z

Hello,

The DebConf10 local team would like to announce availability of visa
information at
http://debconf10.debconf.org/visas.xhtml

Full information is contained at that page, provided by our lawyer; however
some important points are indicated below.

- The United States depends on its tens of millions of visitors annually for
its economy to function. Getting approved for a visa is not a rare
exception, and it is even easier given our generous free help from an
immigration lawyer.

- If you are from a Visa Waiver Program country (see visa page), fill out the
ESTA web form to apply for your travel authorization now. You don't need any
information about the conference itself or your means of travel.

- If you will need to apply for a visa, check the visa information page for
information on what to do. Carefully check the wait times for your country's
embassy. For most countries there is no *immediate* urgency, but plan to get
an appointment well in advance of May 2010.

- Make sure you will have a passport that will expire in February 2011 or later
(6 months after the latest possible DebConf date). If not, apply for a new
passport.

***Special note to Venezuelans: Since the wait time for a visa appointment in
Caracas is so long, we have been paying special attention to its visa
application process. We have reports that the dates for visa appointments are
moving quickly, getting later and later. If you are are applying for a visa in
Caracas, you need to make an appointment *immediately*. You just need to make
an appointment now, supporting materials can be assembled later.***

The local team hopes that everyone interested can meet us in New York City and
have a great DebConf10 experience!

- The DebConf10 Local Team

signature.asc (204 bytes) Download Attachment

The future of the boot system in Debian

2009-09-05T04:21:00Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The future of the boot system in Debian
=======================================

Over the last few years, the boot system in Debian has progressively
deteriorated due to changes in the Linux kernel which make the kernel
more and more event based. For example, the kernel and its drivers no
longer block all processing while detecting disks, network interfaces
and other hardware, making the once trusty old boot system in Debian
increasingly fragile. During the current boot sequence device files in
/dev/ are often missing when fsck or mount are looking for them, or
the network is not available when the boot system tries to mount NFS
entries because network interfaces were slow to initialise, or audio
devices are missing when audio settings should be set. The problem is
fundamental to the way we boot Debian today - sequentially, and a
solution needs to address this fundamental problem. We believe the
solution is to migrate to an event based boot system.

In addition to this, there are long lasting problems with the boot
sequence of the existing init.d scripts, for some combination of
packages. The boot sequence is wrong in these cases, and to solve it
one needs to change the sequence numbers of all the immediate forward
and reverse dependencies of the init.d script in question - and their
forward and reverse dependencies and so forth until the boot sequence
is correct. In some cases the change needs to happen to several
scripts in different packages at the same time, which is impossible
with the old way of ordering init.d scripts. Previously the ordering
was done by asking the package maintainers to guess on and update
sequence numbers, a process that tended to introduce new problems and
took a long time to be solved properly. The solution to this problem
is to change how we order boot scripts. Change it from static sequence
numbers to calculate the boot sequence using dependency information
provided in the init.d scripts themselves. Since 2009-07-27 this is
the default in Debian unstable, and it will be the way init.d scripts
are ordered in Squeeze. Switching to a dependency based boot
sequencing allows us to ensure its correctness, detect and fix
dependency loops, and in general fix a set of bugs in the distribution
that have been very hard to fix before. Other solved problems with
the new system are incorrect stop sequences (the default should have
been S20/K80, not S20/K20), and the misleading runlevels 0 and 6,
where start symlinks are called with 'stop' as the argument to the
scripts. All of these problems are solved when Debian now moves to
dependency based boot sequencing.

It will take longer to solve the fundamental problem. It requires a
rewrite of how we handle the boot, and can not be done by just
modifying the boot sequence framework.

Before explaining the current plan, some background information. The
current boot system can be seen as consisting of three different parts:

1. The implementation of /sbin/init, reading /etc/inittab and
starting the script implementing part 2 (/etc/init.d/rc). This is
normally done using the sysvinit package, but other replacements
are available, like initng and upstart.

2. The implementation of /etc/init.d/rc, which is responsible for
calling the init.d scripts in the correct sequence. This is
normally done using the sysv-rc package. An alternative is the
file-rc package, which uses a file /etc/runlevel.conf instead of
symlinks in /etc/rc?.d/ to decide what to execute and in which
order.

3. The individual init.d scripts, taking care of the tasks that need
to be done during boot. The basic framework is provided by the
initscripts package, and the rest is handled by individual
packages like udev, netbase, ifupdown, apache, etc. :) There are
approximately 850 packages with init.d scripts in Debian unstable.

Part 2 (sysv-rc) and 3 have been changed to use dependency based boot
sequencing. This was a release goal for Lenny and the continued work
is a release goal for Squeeze. The init.d scripts have seen review
with regard to dependency based ordering for more than 3 years. New
installs will use dependency based boot sequencing. For upgrades, a
critical debconf question will give the default option to migrate if
testing find no issues with the existing scripts or for now keep the
legacy boot ordering.

To solve the fundamental problem, the plan is to replace /sbin/init
with an implementation that is able to handle kernel events. It will
allow us to modify the boot system for the early boot to become event
based, while keeping the existing boot stuff working. We could rewrite
sysvinit to become event based, or have a look at the existing boot
systems that handle kernel events. After checking the options and the
systems used in other distributions, upstart seems like the most
promising candidate. It is used by Ubuntu and Fedora at the moment,
and solves the problem in a backwards compatible way. The plan is to
change upstart to actually use /etc/inittab, to ease the switch
between sysvinit and upstart. We will also change the init.d script
handling to treat upstart jobs as init.d scripts, to provide an
alternative for architectures lacking upstart support. These changes
should make it transparent for the users which package provides
/sbin/init, and thus make it easier to migrate from sysvinit to
upstart.

When /sbin/init is changed to an event based framework, the next step
is to rewrite the early boot system to use these events when
available, and behave the traditional way when there are no
events. When this step is finished the fundamental problem will be
solved, and the boot will be robust and should work correctly even in
edge cases with slow device buses.

The planned time frame for this is to replace /sbin/init with upstart
for Squeeze, and see if we manage to change the very early boot to
become event based in time for Squeeze too, fixing the most pressing
of the current boot problems (failing fsck and mount with USB
disks). For Squeeze+1, more of the early boot system will be
converted, to handle more of the existing problems.

According to the Linux Software Base specification, all LSB compliant
distributions must handle packages with init.d scripts. As Debian
plans to continue to follow the LSB, this mean the boot system needs
to continue to handle init.d scripts. Because of this, we need a boot
system in debian that is both event based for the early boot, and
which also calls init.d scripts at the appropriate time.

References:
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot

Petter Reinholdtsen, Kel Modderman, Armin Berres

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

iD8DBQFKoklo20zMSyow1ykRAkvfAJ4+kofKHP+sYOQndZlBhe/mC7nTvQCdE8af
YZEQ67miKPOCeMbC0Ephx1w=
=bA+k
-----END PGP SIGNATURE-----

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

Bits from the GRUB maintainers

2009-09-04T12:21:05Z

Hi,

As you may have noticed, upgrades of the GRUB Legacy package (`grub')
in unstable have begun using GRUB 2 (`grub-pc' package) as upgrade
path. This means that tentatively, GRUB 2 is to be considered the
option for Lenny to Squeeze upgrades. It should also become the option
for new Squeeze installs.

This decision is not final yet! We're looking for feedback on this
transition. First and foremost, we need people to test GRUB 2 on their
machines and report any issues that they may find.

GRUB 2 features a cleaner design, and is much more robust than its
predecessor. Also, unlike GRUB Legacy it's under active development.

Nervertheless, we're aware that for a minority of users, upgrading is
not currently an option, because they rely on specific features of
GRUB Legacy that GRUB 2 doesn't provide. For those users, GRUB Legacy
will continue being supported, at least up untill the Squeeze release.

Your friendly GRUB maintainers,

Robert Millan
Felix Zielcke

signature.asc (204 bytes) Download Attachment

testing is called testing for a reason ...

2009-09-04T09:12:10Z

Hi,

a few more bits from the large migration: By using real force, we
managed to push about 100 source packages and 1500 binNMUs to testing
at the same time that needed to go together. This should be pushed out
by dinstall in about 6-8 hours.

Howver, we needed to break a few packages on this. Nothing too bad we
hope, but we hadn't a real choice as this transition was becoming
larger and larger, and we had to stop that. Please don't upload new
disturbing transitions for yet another week so that we have the
chances to pick up any remaining pieces (and as always, please contact
the release team before starting transitions that affect many
packages). If you notice breakages that don't only wait for buildds to
complete, please don't hesitate to contact us (or even better: fix
them).

Cheers,
Andi

signature.asc (204 bytes) Download Attachment

do not upload stuff re mysql / octave / ...-transition

2009-09-01T12:13:41Z

Hi,

currently there is the large mysql / octave / hdf* / nattle /
...-transition going on which includes about 170 source package
changes and about 120 binary changes (recompilations) for every arch.

The transition is now mostly ready, but we have quite a few packages
being uploaded only recently, like e.g. today. We would like to give
all packages adequate testing before pushing them to testing, so we
need to have all packages at least aged for 4 days.

Please help us in getting the transition done, and do not upload any
package that links to any of the mentioned packages for the next few
days (especially bad are dependencies on libmysqlclient*), i.e. if you
have any link to mysql, octave or debian-gis, please do not upload.
The only exception to this are uploads that are necessary to get this
transition done, and are acked by me.

(The only other way would be to push packages to testing which are
untested, or remove packages from testing only for the reason they
have been recently uploaded to unstable - and we like neither of that)

I'll send a followup mail as soon as either this is done, or some
not-yet-detected blocker comes up (which so big transitions one never
knowns).

Thanks for your support.

Cheers,
Andi

signature.asc (204 bytes) Download Attachment

New NM Front-desk Member

2009-08-30T13:49:29Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

the New-Maintainer Front-desk is happy to announce that Enrico Zini
<enrico@...> followed our invitation to join the team. Welcome on board
and many thanks for volunteering!

Also it is probably worth to mention that the FD and DAM members plan to meet
this year. One of the big points on our to-do list is to work on a rewrite of
the website of nm.debian.org. If you have any suggestions for the rewrite, don't
hesitate to add them to [1].

[1] http://wiki.debian.org/FrontDesk/NewWebsite

Best regards,

Bernd
- --
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F

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

iEYEARECAAYFAkqa5c0ACgkQBnqtBMk7/3lhhACdFE3IzZd4mFG5D7DnCX12TD9h
/5wAoJkzMN6uBNjWjep+FyAlU2VwQHou
=AC97
-----END PGP SIGNATURE-----

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

Changes to Debian Maintainers handling

2009-08-30T03:07:01Z

Hi,

during DebConf9 the Debian Keyring Maintainers, the "Debian Maintainer
Keyring Team" and FTPMaster discussed the maintenance of the extra
debian-maintainers keyring. The conclusion was that the maintenance of
the keyring is handed over to the Debian Keyring maintainers, while the
policy (add/remove/change) is kept with the DM Keyring team.[1]

Thanks to this change we FTPMasters can now allow Debian Maintainers to
also use our various upload queues[2] for their uploads. You are no
longer bound to ftp-master only.

Note that DAK learns about changes in the keyring during dinstall, so
there can be a delay of up to 6 hours before a newly added key is fully
working. As DAK sends a mail with a summary of changes it learned, it is
safest to wait until you saw this mail appear on debian-projects@....

[1] It is now a similar handling as for the other keyrings. There DAM
tells keyring-maint who to add/remove.
[2] With the exception of security. DMs continue to be unable to do
security uploads, as that archive has no knowledge of DMUA status of
packages.

--
bye, Joerg
<holger> Ganneff: Im confident in your ability to create flamewars.

attachment0 (265 bytes) Download Attachment

Mini-DebConf Taiwan 2009

2009-08-30T02:57:35Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

The "Software Liberty Association of Taiwan"(SLAT) is featuring a
mini-DebConf during ICOS 2009 – International Conference on Open Source
in Taipei in September, 2009.

It's the 1st mini-DebConf in Taiwan, and would possibly become the 2nd
Asia mini-DebConf(if DDs from China/Japan/Korea/Hong Kong can be join as
well) since the 1st was on 2005 in Beijing. Please join us in Taipei on
Saturday 26th and Sunday 27th of September, 2009.

Participants may get accommodation and food sponsorship. Remember to add
your name to this wiki page below if you are joining us. Please also
send a separate email with your information to apply for sponsorship to
Local contact.

Details: http://wiki.debian.org/DebianTaiwan/MiniDebConf2009

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

iEYEARECAAYFAkqaTQ0ACgkQnQYz4bYlCYV4hgCfSlpW8rh0dsaRaAM3LWRezRQN
QgQAn36gUjIC/jrPwBq/1G0989OuK+s+
=g4E6
-----END PGP SIGNATURE-----

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

Bits from the release team: Release goals, schedule, state of the union

2009-08-25T13:51:38Z

Heya,

This mail should be the first in a row of roughly monthly mails
informing the project about the state of the release. Please don't
hesitate to contact us on debian-release@... whenever
you have questions.

Release Goals
=============
We have now reviewed the list of release goals [RT-Goals] and have
ACKed most of the proposed things. A short overview:

- multiarch
We hope to allow our users to install binaries for several
architectures on a single machine in Squeeze.
- kFreeBSD:
Debian 6.0 Squeeze should be the first Debian release shipping with
a non-Linux kernel.
- Boot performance:
Using a minimal shell such as dash, together with the possibility to
use an advanced init script management system, should make booting
Debian even faster.
- Package quality:
We want to encourage the use of tools such as piuparts and lintian
to improve our packages's quality.
- Removal of obsolete libs:
It's time to get rid of Gnome 1.x cruft and similar old, now
unneeded libraries.
- IPv6/LFS:
Further support for IPv6 and large files is still a release goal.
- New source package format:
Make it possible to build all packages using dpkg source format
3.0 (quilt).
- Removal of .la files:
To avoid future problems, we want to remove the error-prone libtool
.la files wherever they are not used.

There are some other goals in the queue for which we would like to
have a bit more information; individual mails requesting that have been
sent out. If you know of something you want to see as release goal for
Squeeze, mail us on debian-release@.

Release planning
================
As you may have noticed, we have asked for your development plans
for the Squeeze release cycle [RT-Survey]. We haven't received replies
From everyone yet (if you want to reply, do so soon) and still haven't
decided on a final schedule but, at this moment, a freeze in December
seems to be unlikely. We will send another mail when we have decided
on a schedule.

Release state
=============
The current state of unstable and testing isn't very good and we would
like to change this with your help. The problems are two-fold: We have
a very high number of release critical bugs and had problems ensuring
the smooth transition of packages to testing.

We have intensified our work on supporting transitions in the past
weeks, allowing quite a few packages to move to testing. We will
continue to do so in the coming weeks and would be grateful if you could
announce every non-trivial transition to debian-release@, so that we
can plan for it.

There were also some buildd problems in the last few days, but we hope
we are past them. We are currently working on the list of architectures
that will be released with Squeeze [RT-Archs] and hope to finalize it
soon.

The number of release critical bugs is something that requires help
From all of you. Please check your packages using our QA pages [DDPO]
and packages on your system using ``rc-alert'' (from the devscripts
package) and fix any outstanding bugs. If you notice bugs in
unmaintained packages, consider informing the MIA team (at
mia@...) or requesting the removal of the package.

Release preparations
====================
To encourage help from new developers, we would like to organize some
QA weekends (in the style of Gnome Love Days [GnomeLove]), preferably
with a real-life event at the same time.

For this, we will name a specific area which requires attention (for
example, bugs concerning a release goal) and provide documentation on how
to work on these issues. We hope to attract enough DDs to make it
possible to give advice to new helpers and to get all fixes sponsored in
a timely fashion.

If you would like to help with this and are willing to organize a real
life event, mail us on debian-release@, so that we have some specific
dates to work with.

Cheers,
Marc

Footnotes:
[RT-Goals] http://release.debian.org/squeeze/goals.txt
[RT-Survey] http://lists.debian.org/debian-devel/2009/08/msg00602.html
[RT-Archs] http://release.debian.org/squeeze/arch_qualify.html
[DDPO] http://qa.debian.org/developer.php
[GnomeLove] http://live.gnome.org/GnomeLove
--
http://release.debian.org
Debian Release Team

attachment0 (202 bytes) Download Attachment

Mail forwarding for @debian.org

2009-08-22T15:09:14Z

Hello all,

Since roughly forever, there has been an accidental conflation between
@debian.org mail routing and @master.debian.org mail routing. The two
are handled the same, although they should not be.

DSA is looking at ways to disentangle the two mail domains, and as a first
step, we are going to update LDAP so that everyone who doesn't currently
have a mail forward set will have it set to $uid@....
This should not change current behavior, but will make the forward
explicit and allow us to start disentangling the two mail domains without
breaking the implicit assumption that many of you seem to be relying on.

If this is not the behavior you want, please set your mail forward
attribute explicitly. To find out if your mail attribute is set, log
into any debian.org machine you have access to and run:

ldapsearch -x "(uid=$USER)" emailForward

If you get an emailForward attribute in the output and it is the correct
address for your mail, we thank you.

We will leave things as they are for a week or so, and then we'll do the
bulk update ourselves if you all haven't.

Cheers,
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@... |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------

signature.asc (196 bytes) Download Attachment

Bits from Debian Pure Blends

2009-08-19T01:15:12Z

Hi,

here are some bits from Debian Pure Blends [0]:

1. Rename finished

At DebConf 8 it was decided to rename the effort which was formerly
known as Custom Debian Distributions. The rename to Debian Pure
Blends now can be considered as finished in the docs, code and
infrastructure (mailing list, alioth project, etc.. There are
compatibility packages cdd-dev and cdd-common for one release cycle
to enable smooth upgrades.

2. New Blends

The BrDesktop project is actually not really a new Blend because it is
released with Lenny but it started using the technical framework since
last month. Also the DebiChem project is using the framework now. You
might like to have a look at the list of all Blends [1] which are using
the Framework to create tasks and bugs pages.

3. New features

The tasks and bugs pages are now created using Ultimate Debian
Database (UDD) [2] which enabled a lot of new features which
came quite cheap. These are
- Outright information about versions and architectures even
including information about newer upstream
- Information about packages in experimental and new queue
- Displaying DebTags (or asking user to provide DebTags if they
are missing)
- Popcon stats
- Providing correct links to Vcs
- Provide screenshots from screenshots.debian.net

Please provide screenshots to screenshots.debian.net to make
the tasks pages even more informative!

4. Blends needing more support

The Blends Debian Junior and Debian Lex currently are not actively
maintained. Some fresh blood might be needed.

5. Ways to help Blends and Debian users in General

- Translate package descriptions (see yellow buttons on the tasks
pages)
- Provide proper DebTags (see yellow buttons as well)
- Provide screenshots at screenshots.debian.net
- Usability comments about tasks and bugs pages
- Join a Blend featuring your own interests or create a new one.

Kind regards

Andreas.

[0] http://blends.alioth.debian.org/blends/
[1] http://blends.alioth.debian.org/
[2] http://wiki.debian.org/UltimateDebianDatabase

--
http://fam-tille.de

signature.asc (196 bytes) Download Attachment

Bits from Debian Pure Blends

2009-08-17T22:45:23Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

here are some bits from Debian Pure Blends [0]:

1. Rename finished

At DebConf 8 it was decided to rename the effort which was formerly
known as Custom Debian Distributions. The rename to Debian Pure
Blends now can be considered as finished in the docs, code and
infrastructure (mailing list, alioth project, etc.. There are
compatibility packages cdd-dev and cdd-common for one release cycle
to enable smooth upgrades.

2. New Blends

The BrDesktop project is actually not really a new Blend because it is
released with Lenny but it started using the technical framework since
last month. Also the DebiChem project is using the framework now. You
might like to have a look at the list of all Blends [1] which are using
the Framework to create tasks and bugs pages.

3. New features

The tasks and bugs pages are now created using Ultimate Debian
Database (UDD) [2] which enabled a lot of new features which
came quite cheap. These are
- Outright information about versions and architectures even
including information about newer upstream
- Information about packages in experimental and new queue
- Displaying DebTags (or asking user to provide DebTags if they
are missing)
- Popcon stats
- Providing correct links to Vcs
- Provide screenshots from screenshots.debian.net

Please provide screenshots to screenshots.debian.net to make
the tasks pages even more informative!

4. Blends needing more support

The Blends Debian Junior and Debian Lex currently are not actively
maintained. Some fresh blood might be needed.

5. Ways to help Blends and Debian users in General

- Translate package descriptions (see yellow buttons on the tasks
pages)
- Provide proper DebTags (see yellow buttons as well)
- Provide screenshots at screenshots.debian.net
- Usability comments about tasks and bugs pages
- Join a Blend featuring your own interests or create a new one.

Kind regards

Andreas.

[0] http://blends.alioth.debian.org/blends/
[1] http://blends.alioth.debian.org/
[2] http://wiki.debian.org/UltimateDebianDatabase

- --
http://fam-tille.de
Klarmachen zum Ändern!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFKij/2YDBbMcCf01oRAr8QAJ9sjZ2AnxpVBUrMoxIv81ZLbhJGNwCeNt6R
UUprfZ9zXwOUW8rEKqmYyDg=
=VadX
-----END PGP SIGNATURE-----

Bits from Debian Pure Blends

2009-08-16T07:44:39Z

Debian Policy 3.8.3.0 released

2009-08-15T17:32:11Z

I've just uploaded Debian Policy 3.8.3. The next time you upload a
package, please check it against the new version of Policy and update
Standards-Version in debian/control accordingly. A new release of Lintian
calibrated for this release of Policy will be uploaded shortly.

There is no need to make a new upload only to bump the standards version.
Lintian is also now smart enough to not warn if your package complied with
the current version of Policy at the time of the last upload and the
Policy version it complies with is not too old. For packages that need
little development, some packagers take the approach of doing one upload
per Debian release cycle whether the package needs it or not to do
standards version updates, switch to a new version of debhelper, resolve
minor Lintian tags, and do other housekeeping.

Summary of normative (possibly requiring changes to packages) Policy
changes since 3.8.2:

* Add DEB_*_ARCH_CPU and DEB_*_ARCH_OS variables and recommend them
over GNU-style variables for that information. [4.9]
* Source package Architecture fields may contain "all" in combination
with other architectures. Clarify when "all" and "any" may be used
in different versions of the field. [5.6.8]
* The Debian archive software does not support uploading to multiple
distributions with one *.changes file. [5.6.14]
* The Binary field may span multiple lines. [5.6.19]
* Remove the permission for shared library packages to install
libraries in a non-standard location and modify ld.so.conf.
Packages should either be installed in a standard library directory
or packages using them should be built with RPATH. [10.2]
* Clarify installation directories for X programs and remove the
requirement to pre-depend on x11-common before installing into
/usr/include/X11 and /usr/lib/X11. [11.8.7]
* Remove the requirement that all characters in a manual page be
representable in the legacy encoding for that language. [12.1]
* Localized man pages should either be kept up-to-date with the
original version or warn that they're not up-to-date, either with
warning text or by showing missing or changed portions in the
original language. [12.1]
* install-info is now handled via triggers so packages no longer need
to invoke it in maintainer scripts. Info documents should now have
directory sections and entries in the document. Packages
containing info documents should add a dependency to support
partial upgrades. [12.2]
* The requirement for Perl modules to have a versioned Depend and
Build-Depend on perl >= 5.6.0-16 has been removed. [perl]

/usr/share/doc/debian-policy/upgrading-checklist.txt.gz also contains this
list. Please review the listed section of Policy if the change appears
relevant to your package.

--
Russ Allbery (rra@...) <http://www.eyrie.org/~eagle/>

attachment0 (202 bytes) Download Attachment

FTP Team changes

2009-08-15T06:47:22Z

Hi,

everybody please welcome

Alexander 'Tolimar' Reichle-Schmehl
Chris 'lamby' Lamb
Torsten 'twerner' Werner
Barry 'bdefreese' deFreese

as new members of the FTP Team.

--
bye, Joerg
In dem allseits bekannten Land, wo die Intelligenz von einer
staatlichen Central-Agentur verwaltet und anscheinend so stark
rationiert wird, dass selbst der Präsident kaum was ab bekommen hat, [..]

attachment0 (265 bytes) Download Attachment

Bits o' Bugs from the BTS

2009-08-14T08:24:11Z

It's been a really long time since owner@... has written, so these
should most likely be called bytes, but here goes:

=== NEW FEATURES ===

[in control@bdo]

1) summary -- you can now select a message which summarizes a bug; the
first non-control, non-pseudoheader, non-quoted[1] paragraph is
selected as the summary for a bug:

# select message 15 as the summary
summary 12345 15
# select this message as the summary
summary 12345 0

this is also exported via get_status and soap, so other things can use it

2) affects -- you can now mark a bug as affecting another package, and
it'll show up in the other package's bug list by default. Use this
when liba breaks user-visible package b to try to stem the flow of
grave OMG THE WORLD BLEW UP bugs. [Or just to clue people in.] In the
near future, there will be a wrongpackage nnn foopkg; command which
reassigns to foopkg and marks the bug as affecting the package it was
originally assigned to.

3) limit -- you can now limit control operations[1.5] to arbitrary
constraints, such as:

# bugs with package foo and bar
limit package foo bar
# bugs which have severity serious
limit severity serious
# bugs which are submitted by you
limit submitter you@...

same keys are or'd, different keys anded. Full documentation of this
feature will be forthcomming in the server-control webpage when I get
around to it. [package foo is now implemented as a special case of
limit, in case you were wondering why the control transcript suddenly
changed.]

4) tag -- now accepts multiple commands in a single line:

# tag a bug bar, untag it foo, and set it to bleh
tag 12345 + bar - foo = bleh

5) unarchive,archive -- you can now archive and unarchive bugs. Bugs
which satisfy the criterion for archiving (ignoring time) and have
been previously archived can be manually archived using the archive
command. Any archived bug can be unarchived using the unarchive
command.

unarchive 12345
# since 12345 (presumably) still satisfies the archiving criterion
archive 12345

6) forcemerge -- takes the first bug as the prototype, and makes the
second bug just like it so that it can be merged.

[web frontend]

1) cgi options -- see the bottom of the webpages if you haven't
already; pretty self explanatory.

2) full text search -- http://bugs.debian.org/cgi-bin/search.cgi

3) little symbols -- to make the pages easier to see lots of bugs, the
following symbols have been added:

Merged =
Blocked ♙ # pawn
Blocks ♔ # king
Forwarded ↝
Affects ☣ # biohazard
patch +
Fixed Versions ☺ # smiley
wontfix ☹ # frownie
Archived ♲ # recycle
moreinfo M
security S
unreproducible R
pending P
help H
upstream u
fixed-upstream U
fixed F

Severities also have symbols, but these are fairly obvious; hover on
the symbols to see what they mean if you forget.

[local debbugs]

1) There is now a local debbugs package, which enables you to run a
local copy of debbugs which by default contains all of the RC bugs,
bugs in your packages, and bugs you've commented on that are
unarchived. [You can configure this if you wish.]

Once debbugs is uploaded to experimental (soon, I promise) and
progresses through NEW[2], you can play with this by installing the
debbugs-local package, and running:

local-debbugs --mirror
local-debbugs --daemon
local-debbugs --search severity:serious
local-debbugs --stop

(it's a bit rough around the edges still; bugs (preferably with
patches) accepted.)

== ARCHITECTURE CHANGES ==

1) Debbugs::Control abstraction -- almost all of the control@ routines
are in a new file, which means we can call them from submit@ time to
support control actions in an initial mail.

2) Bugs which are assigned to a source package instead of a binary
package now have src: prefixed in front of the name. This now
completely disambiguates the source: foo makes binary: bar, and
source: bar makes binary: foo case... (but it doesn't make it less
confusing for humans, so please don't do that.)

3) General code cleanup -- most everything is use warnings; use
strict; (but not everything).

== FUTURE ==

1) Indication of the status of bugs for all distributions (and
architectures) in a single query; soap-able too. [This will enable the
bts ldap to be deprecated and phased out.]

2) Finish abstracting out control; make it accessible at submit@ time

[...] see the huge list of bugs at http://bugs.debian.org/debbugs and
http://bugs.debian.org/bugs.debian.org

== CALL FOR VOLUNTEERS ==

We're always looking for more people to help out with debbugs; feel
free to ask questions and get started fixing bugs in the bug tracker.

Don Armstrong
(on behalf of the whole owner@... team)

1: For the most part, and assuming you quote with >; if you quote with
spaces or | or some other char(s), put the summary on top.

1.5: Well, almost all. merge, unmerge, forcemerge, and clone don't
respect this, though they do respect the package limit.

2: Or you can get it right now from:
bzr branch http://bugs.debian.org/source/mainline
--
Everyone has to die. And in a hundred years nobody's going to inquire
just how most people died. The best thing is to do it in the way that
strikes your fancy most.
-- Kenzaburō Ōe _Silent Cry_ p5

http://www.donarmstrong.com http://rzlab.ucr.edu

signature.asc (196 bytes) Download Attachment

Misc developer news (#17)

2009-08-13T05:44:23Z

The news are collected on http://wiki.debian.org/DeveloperNews
Please contribute short news about your work/plans/subproject.

In this issue:
+ PTS news: accessibility, piuparts, l10n
+ cvs.debian.org (and its webwml repo) moved to Alioth
+ Git user's survey 2009
+ New source formats
+ New mailing list debian-user-dutch

PTS news: accessibility, piuparts, l10n
---------------------------------------

A handful of changes have been flowing into the PTS
(http://packages.qa.debian.org) during DebConf9:

* the PTS page layout have been re-designed, mainly behind the scenes:
it no longer uses tables and should be more accessible. As a minor
drawback, alternative CSS stylesheets beyond the default one are
currently broken
* the PTS now shows errors about package installation stressing found by
piuparts (see http://piuparts.debian.org for more info)
* the PTS now shows information about the translation status of a
package and warns when Debian-specific strings (e.g. debconf
templates) need translations

-- Stefano Zacchiroli

cvs.debian.org (and its webwml repo) moved to Alioth
----------------------------------------------------

cvs.debian.org has been moved away from gluck.debian.org, its new home is
alioth.debian.org with all the other version control system. This
concerns mainly committers to the webwml repository (the website) since
the associated SSH host key has changed and the password to use is the
alioth's one (and not the one from Debian's official LDAP).

-- Raphaël Hertzog

Git user's survey 2009
----------------------

The Git User's Survey 2009[1] is up! If you care about improving Git so
that it better suits your needs for your Debian work, please take a few
minutes to answer it. The survey will last until 15th september 2009.

-- Raphaël Hertzog

[1] http://www.survs.com/survey?id=2PIMZGU0&channel=Q0EKJ3NF54

New source formats
------------------

A status update concerning the switch to new source formats has been sent
to dedian-devel[2]. Test source packages (and an associated APT
repository) are available. The main blocker is the merge of the branch
that adds support of new source formats to dak. Check out the message for
more details on what has been done and what's planned.

-- Raphaël Hertzog

[2] http://lists.debian.org/debian-devel/2009/07/msg00937.html

New mailing list debian-user-dutch
----------------------------------

A new mailing list has been created for Debian users who speak Dutch. You
can participate even if you run your desktop in English. You can
subscribe here: http://lists.debian.org/debian-user-dutch/

-- Paul van der Vlis

--
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/

signature.asc (536 bytes) Download Attachment

Override changes

2009-08-05T14:49:52Z

Hi,

if you need to request an override change for your package, please use
the BTS in future, no longer reply to the override disparity mail you
will receive from the archive.

The format for such bug reports against the ftp.debian.org
pseudopackage:

Subject: override: PACKAGE1:section/priority, [...], PACKAGEX:section/priority

Include the justification for the change in the body of the bug please.

(I hope reportbug will understand this soon, similar to it knowing about
removal bugs).

This new way will make it easier for us to keep track which are already
done and which not.

--
bye, Joerg
.SH AUTHOR
This manual page was not written by anyone. It sprang forth into
existence on its own.

attachment0 (265 bytes) Download Attachment