gmane.linux.debian.devel.announce

Call for Talks for the Debian Developers' room at FOSDEM

Wouter Verhelst — 2008-12-01T01:11:12

Hello World, It's that time of the year again: FOSDEM is almost upon us. For those living under a rock and unaware of what FOSDEM is: the Free and Open Source Developers European Meeting is a yearly community meeting that takes place at the université libre de Bruxelles in Brussels, Belgium. It is highly non-commercial in nature, and a unique venue that allows FOSS people from all kinds of different backgrounds to meet and learn about the new things in the FOSS world. It is organized during a weekend in the month of February; this time, that will be the weekend of the 7th and 8th. As has become a habit now over the years, I've again requested a developers' room for the Debian project, and have just received an acceptance of that request[1]. This means we'll be able to hold talks at FOSDEM for one and a half day: during the afternoon on saturday, and the whole day on sunday. So, if you're interested in holding a talk at FOSDEM, now is the time. As usual, talks will be accepted on a first-come, first-serve basis; that is, of course, as long as they are suitable for a Debian venue. The information you should be sending me about your talk includes the following: - Your name - The title of your talk - How long you would like the talk to take (no more than one hour, please) - A short bio - A short abstract The latter two don't need to be loads of data; their goal is for them to be put on the official FOSDEM website, and for those of us who will be doing the talk introductions to have a bit of information to go by. Note also that due to the rather short amount of time we have this year[2], I will have to request that people interested in holding a talk do not procrastinate too much; otherwise, they'll likely miss the deadline. That's it, I guess. See you at FOSDEM! [1] Though nothing more so far; I know we'll have a room, but not which one, or what its capacity will be. Hopefully not a smaller one than last year. [2] Usually I receive a confirmation around halfway october to early november, and need to send in the schedule somewhere early february. This time around, we've received the schedule about a month later, and FOSDEM will /be/ around early february...

Dependency based boot sequencing release goal completed

Petter Reinholdtsen — 2008-11-30T10:06:00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is a new status update following the last report in http://lists.debian.org/debian-devel-announce/2008/03/msg00011.html The release goal to prepare all init.d scripts for a dependency based init.d script system can now be considered complete. 99.8% of all packages in unstable now have the dependency information (2 packages missing it), and a similar amount in Lenny contain the dependency header. I am not sure how to calculate the fraction in Lenny. The initial testing of these dependencies have discovered some bugs in the headers, leading to incorrect boot or shutdown sequence, refusal to activate dependency based boot sequencing or rejecting a package installation. Most of these bugs are fixed, but some remain open in BTS. More testers are needed to discover problems with currently untested combination of packages. Please tag all such BTS issues appropriately to get them to show up on http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=initscripts-ng-devel< at >lists.alioth.debian.org At the moment, 1% of the debian population got insserv installed. More testing is needed, to detect the remaining dependency errors. The insserv package in unstable and testing is doing well, and a large test suite has been written to verify that it is working correctly before upload. This have made us confident that it is working very well. Happy hacking, - -- Petter Reinholdtsen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJMmT220zMSyow1ykRAiEHAKCiTZh9gVYjiAemv+8z3N3yQ9oe/ACgiTbj HPsV4tmYhub7VlsxCeGM26k= =8E3J -----END PGP SIGNATURE-----

Bits from the buildd.debian.org world

Adeodato Simó — 2008-11-24T18:26:06

Hi there, Recent work from Steve McIntyre (current DPL) in coordination with Ryan Murray (wanna-build maintainer and buildd admin for several architectures) has led to the injection of new blood in the buildd.debian.org world. We thank them both for this opportunity, plus DSA for their help throughout the process. Autobuilders ============ Let's start with the autobuilders: Ryan will take care of alpha now, and i386, mipsen, and powerpc get new people on board. The list of buildd admins for all architectures ends up like this: * alpha: Ryan Murray (backup Steve Langasek) * amd64: Kurt Roeckx, Frederik Schüler * arm: Aurelien Jarno * armel: Riku Voipio * hppa: LaMont Jones * i386: Philipp Kern, Luk Claes [*] * ia64: LaMont Jones * mips, mipsel: Thiemo Seufer, Martin Zobel-Helas [*] * powerpc: Philipp Kern, Wouter Verhelst * s390: Bastian Blank * sparc: Martin Zobel-Helas These are the people who are, or will be, behind the < at >buildd.d.o mail aliases. Arches marked with [*] are those where the hand-over has not happened yet (but will happen soon). Also, there is ongoing work to ensure all architectures with a single admin get a backup admin. wanna-build infrastructure ========================== A new team has been created (gid: wbadm) to maintain the wanna-build infrastructure (that is, the software that tells the autobuilders what to build, plus the pages you see in ). The team is initially formed by: * Andreas Barth * Marc Brockschmidt * Luk Claes * Philipp Kern * Ryan Murray * Adeodato Simó In the past few days, Philipp Kern has taken care of migrating the existing setup to the new role account (uid: wbadm), and the hand-over is now finished. Contact addresses ================= Here's a crash course on who to ask what, and where: * the role address for the wanna-build team is wb-team< at >buildd.debian.org. However, a buildd.debian.org pseudo-package has been requested in the BTS, so please only use the role address for stuff that is not BTS material. * architecture-specific give-back and dep-wait requests, chroot problems, etc., should always be directed at < at >buildd.debian.org first; if you get no action, you can send them to wb-team< at >buildd.d.o. * binary NMUs requests should still be sent to debian-release< at >lists.d.o; the rationale is that many binNMU requests are related to some transition, or hide bugs, which the release team should stay on top of. Source code =========== All the source code that is around in raff (buildd.debian.org) and the buildds will be published, most likely under http://buildd.debian.org/git/ (plus a mirror in git.debian.org). We'll get to that next, thanks in advance for your patience. On behalf of wbadm,

SmellyWerewolf.com perfume & make-up discount

Josselin Mouette — 2008-11-23T16:59:13

Hi SmellyWerewolf.com are kindly offering every Debian Developer a discount on their whole perfumes and make-up catalog[1]. If you apply under the procedure outlined below, you will pay according to "Rate Eeencredible", which at the time of this writing means 20% more chicks loving you! Steps to follow: - If you do not already own perfume bottle, buy one at your nearest convenience store. - If you are goth, transsexual, female or simply metrosexual, you also need to buy make-up at the same place. - Send your private Debian GPG Key to more-chicks< at >debian.org. Include the brand of your perfume and the color of the make-up. - Wait for an OK reply and your new “good friends” will be delivered directly at home. If you don’t want the chicks, you should still buy the perfume and the make-up, cause you know, that can’t hurt, and in this time of economic crisis, the Lust industry needs your help. [1] http://malsain.org/SmellyWerewolf About SmellyWerewolf.com: Created in 1415 after the battle of Agincourt and purchased in 1802 by an experienced vampire who wanted to hide his horrible corpse smell, the Romanian company Smelly Werewolf delivers about 750,000 bottles of perfume for geeks in 198 countries around the works, which places the company around the leading make-up providers in Angola, and third in the World of Darkness. Today, Smelly Werewolf is considered as a strong point of reference among vampires and zombies. The company’s goal is to create an alternative and independent line of products destined to the undead. Smelly Werewolf is devoted to giving everyone enough blood for their needs, whether it is by allowing you to hide your corpse smell in birthday parties or by leading chicks directly to your home. In short, we enable people to claim new sex slaves for a very personal experience of professional quality. Our clients range from vampire individuals, packs of werewolves and small Elysiums to worldwide zombie attacks, and it’s something that you should be deeply afraid of.

Gandi.net Hosting discount

Joerg Jaspert — 2008-11-23T11:23:23

Hi Gandi.net are kindly offering every Debian Developer a discount on their hosting solution[1]. If you apply under the procedure outlined below, you will pay according to "Rate E", which at the time of this writing is a discount of 20%! Steps to follow: - If you do not already have a Gandi.net handle, create one at http://www.gandi.net/login/new - Send a mail signed with your Debian GPG Key to gandi-discount< at >debian.org. Include your Gandi.net handle and the currency in which you want to pay. - Wait for an OK reply before you order your server share(s) (Or the first month will be normal rates). If you already own a server share with Gandi.net and want to have the rate, follow the procedure above and starting with the next month you should be fine. [1] http://www.gandi.net/hosting/ About Gandi.net: Created in 1999 and purchased in 2005 by an experienced managerial team, the French company Gandi manages more than 750,000 domain names for clients in 198 countries around the world, which places the company among the leading domain names registrars in France and sixth at the European level. Today, Gandi is considered as a strong point of reference in the fields of domain name registrars. The company's goal is to create an alternative and independent line of Internet services based around domain names. Gandi is devoted to giving everyone tools for whatever their purpose is, whether it is to discuss their interests, present products or services, or to simply express themselves. In short, we enable people to lay claim to a personal online presence of professional quality. Our clients range from individuals, associations and small companies, to public institutions (EU for example) and large multinational corporations. All have put confidence in us, and it's something we are deeply proud of.

screenshots.debian.net

Christoph Haas — 2008-11-13T21:18:26

Hi everybody, a picture is worth a thousand words. And thanks to screenshots.debian.net[0] this finally comes true for Debian packages. Several people have proposed a service to provide screenshots for them. So after getting other developers' opinions and suggestions I sat down and crafted a web application that allows to upload and provide screenshots. Unless you are busy helping to fix RC bugs for the Lenny release please consider contributing screenshots of your favorite applications. Currently there are already over 260 screenshots available but there is still some way to go. Everybody can upload screenshots - you don't have to be a Debian developer or Debian maintainer to help. Your uploads will just be checked by the admin team and then published. I would love to see the screenshots integrated into packages.debian.org and perhaps they even get used in graphical package managers like synaptic, kpackage, adept or gnome-apt. It is easy to refer to screenshots from your own application or web site. Just use these URLs: Thumbnail (<= 160x120 pixels): http://screenshots.debian.net/thumbnail/PACKAGENAME (this URL returns a dummy thumbnail if no screenshot was found) Package's page with all available screenshots: http://screenshots.debian.net/package/PACKAGENAME There is still a couple of items on my to do list. But if you have further ideas on features, need a certain API or find bugs please tell me or let's discuss matters on debian-devel. Have fun, Christoph [0] http://screenshots.debian.net

Debian Installer lenny release candidate 1

Otavio Salvador — 2008-11-13T00:05:24

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Debian Installer lenny release candidate 1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Debian Installer team[1] is proud to announce the first release candidate of the installer for Debian GNU/Linux Lenny. Improvements in this release of the installer * Improved support for Live-CD installation media (much faster and more reliable than earlier releases); * Support for some NAS devices based on Marvell's ARM-compatible Orion chip: o QNAP TS-109/TS-209 and TS-409; o HP Media Vault mv2120; o Buffalo Kurobox Pro; * Installer images for Netwinder have been added again; * Installer images for i386 Xen guests[2] * Support for hardware speech synthesis (speakup) has been added; * Upgrade of packages early in pkgsel, for example to get available security updates for base system packages; * Support for loading firmware from (removable) media during the installation; * i386/amd64: support for installing to and loading firmware from MMC/SD cards; * New translations: Welsh, Irish, Northern Sami, Serbian (Amharic and Marathi were added in beta releases). Known issues in this release * i386: for this release, installation from floppy disk is not supported; * PowerPC: the graphical installer should work on almost all systems with ATI graphics cards, but probably not others; * touchpads should work with the graphical installer, but support may be suboptimal - if you experience problems, you should use an external mouse instead. See the errata[3] for details and a full list of known issues. We do need your help to find bugs and further improve the installer, so please try it. Installation CDs and DVDs, other media, errata, and everything else you'll need are available from the Debian Installer web site[4]. The Debian Installer team thanks everybody who has contributed to this release. References ~~~~~~~~~~ 1. http://wiki.debian.org/DebianInstaller/Team 2. http://wiki.debian.org/Xen#InstallLenny 3. http://www.debian.org/devel/debian-installer/errata 4. http://www.debian.org/devel/debian-installer/ - -- Otavio Salvador Debian Installer Release Manager -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ iEYEARECAAYFAkkbZJoACgkQLqiZQEml+FV5IwCfdJ+xagxFhZv7L4IFAQXPOjFA 8w4AoIj5Kl6FXdj0EPzU1SwO9xOWh1RO =La9o -----END PGP SIGNATURE-----

Announcement: Debian Pure Blends news

Andreas Tille — 2008-11-10T09:26:46

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, for those who might wander what the term Debian Pure Blends means: the Custom Debian Distributions now are called Debian Pure Blends - see below for further information. Here comes an update what was done since the beginning of this year which might be interesting for several projects. Web-Tools - --------- I'm proud to announce a new QA tool for all CDD^W Blends: Overview about all bugs about Dependencies of our metapackages. For the impatient here is a list of these pages: Debian Edu: http://cdd.alioth.debian.org/edu/bugs Debian GIS: http://cdd.alioth.debian.org/gis/bugs Debian Jr: http://cdd.alioth.debian.org/junior/bugs Debian Med: http://debian-med.alioth.debian.org/bugs Debian Science: http://cdd.alioth.debian.org/science/bugs You can read more about the estimation of tasks status of the bugs at the Blends/BugPages wiki page[1]. Not that new are the so called tasks pages which are listing the packages in focus of a Blend as well as those projects which are not yet packaged but might be intersting - so called "prospective packages". Here are links to the relevant tasks pages: Debian Edu: http://cdd.alioth.debian.org/edu/tasks Debian GIS: http://cdd.alioth.debian.org/gis/tasks Debian Jr: http://cdd.alioth.debian.org/junior/tasks Debian Med: http://debian-med.alioth.debian.org/tasks Debian Science: http://cdd.alioth.debian.org/science/tasks Both overviews are updated twice a day in a cron job. The tasks pages are interesting for users and developers and thus we tried to translate as much as possible by using the work of the DDTP project (we also provide links where translations might be needed). You can expect more tools which deal with sets of packages for a certain working field in the not so far future. Renaming Custom Debian Distributions to Debian Pure Blend - --------------------------------------------------------- We realised that the old name Custom Debian Distributions just sended the wrong message to outsiders: The conclusion that CDDs are something else than Debian was to "obvious" if people did not read the relevant documentation. So we finally found a raw consensus for a new name: Debian Pure Blends In the code inside Debian we use 'blend' for factorised code that concerns a single Blend (given as an option or something like that and 'blends' if it is working for all Blends in one context. The Debian and Pure is evidend inside Debian internal code like packages blends-dev (formerly cdd-dev) or blends-common (formerly cdd-common) etc. Configuration for blends will go into /etc/blends (formerly /etc/cdd. You can find more information on the according Wiki page[2] or the detailed paper about Debian Pure Blends[3]. Slides of a talk (in German) I have hold about Debian Pure Blends at Linux-Info-Tag (Dresden) is available as well[4]. Kind regards Andreas. [1] http://wiki.debian.org/Blends/BugsPages [2] http://wiki.debian.org/DebianPureBlends [3] http://cdd.alioth.debian.org/blends [4] http://people.debian.org/~tille/talks/200811_dresden_blends/ - -- http://fam-tille.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJF/5YYDBbMcCf01oRArgBAJ9cIeJ34AwbkWiEqQoiiWscj7LBVgCcCUa2 qYBv51AcJTVxdU5T6jvaORg= =OOt8 -----END PGP SIGNATURE-----

Debconf 8 internationalization sessions report

Christian Perrier — 2008-11-08T14:46:48

During Debconf 8, we handled four work sessions around internationalization as well as more informal work around i18n infrastructure. This long-overdue report summarizes the discussions during these meetings as well as other i18n-related work that happened during Debcamp and Debconf. Please accept our apologies for us being very late sending this. =============================================================== During Debconf 8, a lot of work happened around i18n, either during Debcamp, informal sessions during Debconf and four formal 1-hour sessions. i18n work session 1: infrastructure ----------------------------------- During that work session, several contributors of Debian i18n presented the recent progress about i18n infrastructure in Debian, mostly the dedicated server named "churro", aka i18n.debian.net. churro is hosted in Merida, Extremadura, Spain, since September 2006, the first i18n session held in Extremadura. Since then, several services were developed on churro (see http://i18n.debian.net/wiki): Nicolas François summarized the work around l10n material collection. Several scripts on churro gather the translation material and process it to provide: - access for translators to this material - various statistics pages ** Christian Perrier gave a summary about Pootle, the web interface that allows access to l10n material as well as (potentially). Pootle is now directly hooked to VCS repositories of Debian Installer as well as related projects. Some teams began working with it to access the material. It still needs very close monitoring, still, to manually handle possible conflicts. Some experimental scripts are also currently running to gather all po-debconf l10n material, commit it to debian-l10n SVN repository, with Pootle hooked on it. Translators do not have access to this, though, because we need to figure out how maintainers could easily get that material (for instance by having debhelper scripts that could gather it at build time, or similar solutions). We now need to more closely define the administrators for Pootle, if it becomes a production service (as it is partly, already, for D-I). ** Michael Bramer gave the status of the DDTP (packages descriptions translation project). Everything is now installed on churro since December 2007, including the web interface (DDTSS) developed by Martijn van Oosterhout. Future projects include the sync of translated descriptions with the archive (see the detailed section about this later in this report) as well as import/export of PO files, possibly hooked on Pootle (however, that leads to severe performance issues). ** Nicolas François showed the status of "tracking robots" that allow the most organised l10n teams to track down their work with special-formatted mails sent to their respective mailing lists. Recent weeks have seen Nicolas merging together several scripts that were running by a few teams in a general-purpose tracking robot that runs on churro (http://i18n.debian.net/debian-l10n/) ** Christian Perrier showed recent evolutions on compendia creation. Compendia are a collection of already translated strings, assembled in big PO files, that can be used by translation teams to make the translation of new material easier. The initial work by Eddy Petrisor is now running as a general service on churro (http://i18n.debian.net/debian-l10n/compendia/) ** Felipe Augusto van de Wiel summarized the status of the server administration and hosting. The server is hosted in the facilities of the Region of Extremadura. It is administered by Felipe, Christian Perrier, César Gomez Martin (as local contact) and Nicolas François. The server adminstration communication channel is the debian-l10n-devel< at >lists.alioth.debian.org mailing list and #debian-i18n on irc.debian.org. Nicolas and Felipe will setup IRC meetings between them every 2 weeks. A lot of work was done during Debcamp by Felipe and Nicolas to organize the various scripts and robots in a cleaner way, to allow redundancy in server and scripts monitoring. The general goal is to have a "DSA-quality" server and progressively runs all service in the most professional way. Philosophically speaking, we target to transform i18n.debian.net into i18n.debian.org, ie an official service of the project. i18n work session 2: tdebs -------------------------- (notes taken by Marc Hymers) "tdebs" or "translation debs" are an attempt to achieve two goals, by splitting localization material out of packahes: - reduce space usage on systems with low resources (goal pushed from EmDebian) - allow desynchronized updates of translations without requiring a full upload or package recompile (therefore potentially allowing l10n updates to stable, for instance) Various constraints and desirable characteristics were discussed: - Out-of-band translation updates - Only installing useful translations on systems - Reducing bandwidth usage - Avoiding archive bloat Discussion noted that "Reducing bandwidth usage" by providing small, individual tdebs per package per architecture and "Avoiding archive bloat" were contradictory. Instead it was suggested that one .tdeb per source package would be provided, including all translations, and that dpkg class support (http://www.dpkg.org/dpkg/Classes) should be added to allow filtering at install time. Using the class support, .tdebs would be easily splittable into smaller, per language tdebs. This may be considered at stable releases. Translators would be able to use +t[0-9]+ syntax to indicate translation updates (similar to bin-nmu style versioning) Translation-Version: would be used in Packages files to indicate the most up-to-date tdeb instead of having full Package: entries. For new translations, we'll need some form of source; to be decided. This work is aimed at lenny+2 due to the changes needed in the deb toolchain (those being for lenny+1). There needs to be discussion with the dpkg, apt, debian-installer and debhelper people. ftpmaster is happy with the one tdeb per source package and +t[0-9]+ syntax The plan is to meet in Extremedura (post-lenny) to continue the discussion and start the work. The meeting should gather i18n representatives, Neil Williams who did the first implementation of tdebs for EmDebian purposes, ftpmasters and hopefully at least one dpkg maintainer (Raphaël Hertzog who could be there for the QA meeting anyway?). i18n work sessions 3: coordination, i18n team --------------------------------------------- The concept of an i18n "team" was discussed during that session. Language coordinators --------------------- First of all, we might want to establish the concept of team "coordinators" (or "leaders"). The main point would then be to officially establish a list of "official" leaders for each language supported in Debian ("supported" meaning there exists a localization effort for that language in one of the l10n areas that are specific to Debian).. Such "formal" list already exists for D-I translation work. It could be used a a first draft list, even though some of the bigger teams might want to change this. Most participants in the meeting agreed that it would help getting in touch with people who have a good knowledge in each language l10n activities, as well as a good knowledge of that language itself. The list of coordinators would then become public on a wiki page and the nominated persons would then have the duty, if they accept, to follow the activities of Debian i18n efforts (reading the debian-i18n mailing list might be enough for this). Some roles have been mentioned for language coordinators: * defining work methods for the team (for instance, that must be done for the DDTP before any DDTP work starts) * act as a proxy between the translators and the core team * act as a point of contact for Debian project contributors who need to have input about a specific language * participate to i18n IRC meetings Core team --------- The concept of a "core team" for i18n has also been decided. This is indeed formalizing something that already exists with the de facto lead taken by Christian Perrier on i18n and l10n activities in the project, as well as the work done by a few "key" people. That core team would, for the beginning, include Christian Perrier debian.org>, Felipe Augusto van de Wiel debian.org>, Nicolas François centraliens.net>, Michael Bramer debian.org>. As of now, this is not a closed list but more formalizing what's already happening. Core team duties: * be responsible for the infrastructure and coordinate developments * organizing IRC meetings (reference: http://fedoraproject.org/wiki/L10N/Meetings) * schedule regular public meetings of the core team * maintain the list of language coordinators (add new ones, ping existing ones, resolve disputes in case there is a conflict in an l10n team) We need to find the right balance between a too formal process (which might scare people from "one-person" teams) and a too loosy one where nobody knows who's doing what. i18n work sessions 4: DDTP -------------------------- The DDTP/DDTSS infrastructure is now running solid on churro. Michael re-summarized the various possibilities that translators have to adjust their work process to the interface. The major improvement is that translated descriptions *now flow into the archive* since August 14th. Nicolas and Felipe worked hard on scripts for this, along with ftpmasters. So, from now, package management tools that support translated descriptions (apt, aptitude, etc.) will display up-to-date versions and not old stuff from 2006. The discussion about the "openess" of the system is still strong. In our i18n community, we clearly have two visions: - "open to everybody with low constraints": this is the original design of the DDTP: everybody can show up and start translating. This allows for a quick growth of the amount of translations to the expense of their quality ; - "control the quality": this is wished by the most structured teams and a concern bringed by many maintainers. Felipe explained how he tries to balance this for the Brazilian Portuguese team by basically controlling that nobody is translating outside the team and following the work process for the team as well as assigning tasks in the team. The general agreement is that each team should be able to choose its own process in the DDTP: some might want to restrict users by using the built-in "authentication" system, while some other teams might want to leave things more opened. Another agreement is to converge towards the possible use of PO as a method to translate in the DDTP (whether or not this is hooked to Pootle is not necessarily relevant: we coould have a transient situation where DDTP translation with PO files could be possible without hooking Pootle to this). Michael will work on PO import (PO export is alredy implemented and just needs to be automated). Using PO would of course be optional. i18n work sessions 4: Extremadura --------------------------------- An Extremadura meeting will happen in November (post Debconf: that should be Nov 26th to Nov 30th). This meeting will focus on tdeb work as well as DDTP/infrastructure improvement. For that reason, attendees should be the "core i18n infrastructure team", namely Felipe Augusto van de Wiel, Nicolas François, Christian Perrier, Michael Bramer, Martijn van Oosterhout. FTPmasters will be there as well, which will allow polishing the import of packages description translations in the archive. The presence of Neil Williams and at least one dpkg developer (for tdeb work) is wished. The meeting would be shared with the QA meeting. We might have some constraints in terms of number of participants, so we will need to reduce it to the strict minimum. Steve McIntyre mentioned that he cuold consider using Debian funds to sponsor some participation in case that could be needed. (post Debconf note: the meeting organization has started and is coordinated on event-extremadura-meetings< at >teams.debian.net, which anyone can subscribe to on http://teams.debian.net. The size constraints are quite strong) Achievements of Debcamp/Debconf ------------------------------- * Thanks to the support of the ftpmasters, we could find a agreement on how to provide the translations of the package description in the archive. This was awaited for more than 6 years. This is still a temporary solution for Lenny, and should be changed to a solution were the translation are attached to packages to allow the transition of translation with the packages. * Several improvements were discussed before debconf for the coordination pages (http://i18n.debian.net/debian-l10n/) and the statistics pages on http://www.debian.org/international/l10n/po-debconf/. The full support for history could be finished in Debcamp and put in production for the coordination pages. A patch has been sent for review for the statistics pages. These improvements should help teams to focus on the translations where an effort is needed. More improvements are expected on the robots to match with the workflow of more teams in debian. * Cleanup of churro - some services were still using an old version of the tools based on the CVS version. They have been updated to the version publicly available on SVN. * Services on Churro are now provided with SSL support. The (self-signed) certificate used currently will be changed when we will have a certificate signed by DSA. * Improvements on DDTP (http://ddtp.debian.net) * Debcamp and Debconf permitted to exchange ideas and introduce the code base of Pootle and the dl10n robots. The TODO list (http://wiki.debian.org/I18n/ToDoChurro) increased and will keep us active for next year. Meetings video recordings: http://meetings-archive.debian.net/pub/debian-meetings/2008/debconf8/low/541_I18n_mini-session_14.ogg http://meetings-archive.debian.net/pub/debian-meetings/2008/debconf8/low/586_i18n_mini-sessions_24.ogg http://meetings-archive.debian.net/pub/debian-meetings/2008/debconf8/low/642_i18n_mini-sessions_34.ogg http://meetings-archive.debian.net/pub/debian-meetings/2008/debconf8/low/814_i18n_mini-sessions_44.ogg (to get high resolution versions, please s/low/high in URLs)

For those who care about bts-link: call for adoption

Pierre Habouzit — 2008-10-30T16:41:01

Hi, As some of you may know, I've been the original creator of bts-link[0]. Though, I have currently neither the motivation, nor the time to maintain it, or run it on a regular basis[1]. I believe bts-link has become an important piece of our infrastructure, especially for packagers with huge user base, but not only. This is why it's more than time that I give bts-link to people that have the time to care about the beast. Anyways, the information is: I don't intend to maintain or run bts-link anymore[2], it is up for adoption. If the BTS people wish to inherit the beast they come first, but any motivated group of people are welcomed. I believe that the most important things right now would be: * make it an official Debian service (running from a Debian.org host) so that one can lift some specific bans that bug trackers maintainers over the world impose to crawlers ; * make the code base better so that one can have a comprehensive list of bugs that bts-link cannot get a status for, which it doesn't right now. In particular it means that if an upstream bugzilla moves or something, it gets completely unnoticed right now ; * maintain the code base, add support for new bugtrackers, ... Cheers, [0] http://bts-link.alioth.debian.org/ [1] Yes, you understood right, it's still run manually. [2] I will continue to run it on an irregular basis until it is properly adopted though.

Developer Status

Joerg Jaspert — 2008-10-22T21:33:28

Developer Status ================ Summary of this post -------------------- Discussions in the past have made it clear that the current definition of "Debian Developer" (AKA someone who is a member of the Debian project) should be modified and made more flexible. There have been attempts in the past to do something similar, notably Debian Maintainers (DM) [GR-DM], and to some extent debian-community.org [D-C], but these have only addressed parts of the whole issue. We plan to integrate DM more closely into the NM process/system while keeping the spirit of easing entry into Debian for newcomers. At the same time we add a separate track for less-technical contributors. If you are an existing Debian Developer or Debian Maintainer, don't be afraid, we are not going to take anything away from you. Currently becoming a Debian Developer means passing through all of the New Maintainer process. People that passed this get the < at >debian.org mail-forwarding, an account on all (developer-accessible) Debian machines, voting and upload rights. It is a process that requires work from prospective Developers, and depending on their available time and the effort put into it, it can take a bit of time. Some time ago a few Developers thus went and pushed forward the "Debian Maintainer" status. DM allows newcomers to upload their packages relatively early, without having to go through the "full" NM process. So far it has worked quite well for the people involved, but the way it was instantiated outside of most existing structures has always made other groups in Debian uncomfortable. The ftp-masters have to deal with the technical implementation that does not fit well with the rest of the archive, and the account and keyring managers would like to remain the authoritative source for "who is in Debian". Debian is about developing a free operating system, but there's more in an operating system than just software and packages. If we want translators, documentation writers, artists, free software advocates, et al. to get endorsed by the project and feel proud for it, we need some way to acknowledge that. This is where our proposal comes in. Now let us describe the way the account status is meant to be handled in future. A new user can start out in two ways depending on their personal preference. The first is the non-technical way: Debian Contributor ------------------ A DC is someone that has a strong relation with Debian through the work they are doing for/around Debian. Possible examples are translators and documentation writers. DC have to pass the ID check, agree to the Social Contract/DFSG and have successfully answered a set of questions[DCDMQ] similar to the ones used in the current first P&P step.[TEMPL] The second way is the technical one: Debian Maintainer ----------------- A DM has the same strong relation with Debian a DC has, but additionally wants to maintain a limited set of packages without the help of a sponsor. A DM has to pass the same checks a DC has and very few questions from the T&S part[DCDMQ]. A (very) small T&S basically, the most important T&S questions for them. They are allowed to upload their own (source) package. The allowed list of (source) packages to upload can be edited by any member of the NM committee[NMC], who will do a package check before they add new packages to the DM's list. In contrast to current DM this is based on source packages and allows uploads of new binary components, which have to pass NEW, too. While, strictly speaking, this increases the barrier to get DM compared to the current implementation of DM, we do not think it is an unreasonable or too high level. Anyone who is able to get a package put together in a lintian clean way will be able to get DM without much effort or time used. Those two "classes" are the initial set in which every NM will end up. After six months as DC or DM one might chose to become a Debian Member or Debian Developer. This - ensures that the interest in Debian isn't short-term. - enables them to learn more about the workings in Debian and generally helps them for the next step. - leaves everyone the option to stay DC or DM, if they do not want/need more rights. After the 6 months time in Debian Contributor/Maintainer are passed, applicants can apply to get Debian Developer status. There are now 2 different "classes" of DD status available, one with and one without upload rights. To not add confusion we selected to name them "Debian member" (no upload rights) and "Debian Developer" (upload rights). Both are project members, i.e. with voting and all other constitutional rights, the term "classes" does not indicate any kind of "first" or "second" level membership. Debian Member ------------- A DME is someone that previously had DC or DM for at least 6 months but additionally want to have voting rights or needs a login on a debian.org machine for their work. A DME can nominate themself as DPL, can be delegated rights from the DPL and can start any GR, basically do everything our foundation documents allow project members to do. DME are not able to freely upload any package, but DME can have the same upload rights a DM can have, ie. own packages, if they follow(ed) the DM rules for this. Following our Constitution §8.1.2, DAM declares that Debian Members are to be treated as "Developers who do not maintain packages" wherever the term "Developer" is used in one of our documents. Debian Developer ---------------- A DD is exactly the same as a DME, with the one and only notable exception that a DD can freely upload any package to the archive. To become a DD one has to pass all the checks a DM has to pass and additionally answer all the rest of the questions from the T&S steps in NM. [Or do whatever T&S checks are used by the AM. Focusing on the questions is just for this procedure, as we are used to them.] contributor.debian.org mail --------------------------- We are considering to implement an < at >contributor.debian.org mail forwarding setup which would be open for DC/DM too. Such addresses would continue to be valid even after a person becomes a DD/DME. If sufficient support for the idea is found then this will probably be implemented once the new debian.org mail setup is in place. Changes to existing Debian Developers ------------------------------------- No changes are done to existing Debian Developers, until they ask for it. If you want to drop down to DME, no matter if you want to keep a few packages maintained like a DM does, drop the NM-Committee a mail. Changes to existing Debian Maintainers and NMs ---------------------------------------------- No changes will be done to existing Debian Maintainers, and the 6 months waiting time will not be applied to NMs who have already applied to become DD, unless they ask to be handled using the new way. There is one exception - the handling of the packages allowed to upload will change. In future this will be a list maintained by the NM-committee. At the time of migrating from the old to the new way, Ftpmaster will convert the existing DM-Upload-Allowed fields into that list, so there should be no interruption in your ability to upload. The converted list will be made public before this happens, so to be sure - please check it at that time. (Follow debian-devel-announce and you will notice it). Applications and Advocations ---------------------------- NM applicants, no matter if it is for Debian Contributor or Maintainer status, have to sign up using the interface provided at nm.debian.org[NMDO]. This application, as well as the advocation mail From one or more existing Debian Member or Developer will be copied to the debian-newmaint mailinglist for public review. Changes to the DM Keyring ------------------------- Keyring management will be moved to the control of keyring-maint. The NM committee will decide who will be added or removed, similiar to the way keyring-maint and DAM currently work together. Footnotes ========= [DCDMQ]The intention is that the NM-Committee will select the actual set of questions used, not this mail. It can easily be adjusted to fit whatever the current situation may want to have. For DM we imagine it would be a very limited T&S set, like making sure someone can deal with the BTS and knows the basic tools (lintian, dput/dupload, debsign). It is not meant as a full (first part) of NM and lots of boring tasks before one get DM, but as a basic check for a minimum knowledge. [TEMPL] http://svn.debian.org/viewsvn/nm/trunk/nm-templates/ [GR-DM] http://vote.debian.org/something [D-C] http://debian-community.org/ [NMDO] This interface helps multiple things, like making sure no applicants chose an already existing account name, giving a central place to look at the current NM status, clearly showing what is going on/missing for an applicant. [NMC] The NM-committee is currently defined as (see http://lists.debian.org/debian-newmaint/2003/10/msg00001.html): An AM is a member of the NM committee if a) they are not marked as inactive (i.e. if they haven't retired as an AM) and b) if they've approved an applicant in the last six months. Every Debian Developer (and in future Member too) can join the NMcommittee by simply becoming an AM and successfully processing at least one applicant.

Bug Sprint - Oct 25 to Oct 30 - Register and eat cookies

Josselin Mouette — 2008-10-21T11:43:01

Dear developers, we are currently very close to release lenny which is most likely going to be absolutely awesome. However, there are currently around 100 RC bugs remaining that stand between us and this release. In the permanent BSP state that has lasted for quite some time, people seem to lose focus on this urgent need for the release and the most motivated people are losing motivation after this marathon. Hence the idea of the bug sprint. 100 developers × 5 days = 100 RC bugs closed 100 developers will be working during 5 days and each of them will commit to close a RC bug that will be assigned to him. Fixing a RC bug means either of: * Uploading a NMU that fixes the bug to unstable. * Convincing, with a mail that details the rationale, a release manager to tag the bug lenny-ignore. * Convincing, in a similar way, a release manager to remove the package from lenny. The one who Fixes a RC bug that is more than 3 months old by writing a patch shall become a WINNER. WINNERs and release managers will be eligible to receive home-made cookies from volunteers and from those who are not able to fix their RC bug in 5 days. Rules and inscription: http://wiki.debian.org/BugSprint Add your name now, and win cookies !

Bits from the Debian CD team

Steve McIntyre — 2008-10-14T23:23:34

Hi folks, It's probably time for a quick update on what we've been up to lately in terms of producing Debian CD and DVD and (!) BD images. That will give the game away for the biggest change that has happened lately - we're now producing some Blu-ray images alongside the existing CD and DVD images with each weekly Lenny build. As a standard Blu-ray disc will hold up to 25GB of data, that means that, for the first time in several years, users should be able to fit all of the packages for one architecture on a single disc. Woo! The downside of adding yet another image type is that potentially we could use up huge amounts more disk space and bandwidth on our central servers and our mirrors to accommodate them. What I've done, therefore, is start imposing limits on which images we will produce each week and with Lenny when it ships. What we now have is (in increasing order of size): * Business card and netinst CDs for all architectures (except s390), available for download as ISO, torrent and jigdo. As for Etch, we'll also have 2 multi-arch netinst CDs (i386/amd64/powerpc and alpha/hppa/ia64). * Full CD sets for all architectures: + i386, amd64 and source will all be available for download as ISO, torrent and jigdo + for powerpc we will create ISOs/torrents for the first 8 CDs only (with the rest as jigdo) + for other architectures we'll have ISOs/torrents for the first 3 CDs only (rest as jigdo) * Full DVD sets for all architectures: + i386, amd64 and source will all be available for download as ISO, torrent and jigdo + for other architectures we'll have ISOs/torrents for the first 1 DVD only (rest as jigdo) + again, the show giveaway DVD: multi-arch i386/amd64/powerpc/source containing as much as will fit on a single DVD * BD for 3 architectures: + Single images available for i386, amd64 and source, *jigdo only* There's scope for more options here; we could do a multi-arch i386/amd64 BD image if desired, and that would fit on a dual-layer disc. Other architectures are possible on BD, *except* powerpc is problematic: the genisoimage code to produce the hybrid ISO9660/HFS filesystem needed for powerpc fails utterly on such a large image. Some stats might help here, too. Currently we're looking at a *lot* of potential images for each full set, and this explains why we're starting to cut down now! CD DVD BD alpha 31 5 1 amd64 34 5 1 arm 30 4 1 armel 31 5 1 hppa 30 5 1 i386 33 5 1 ia64 35 5 1 mips 32 5 1 mipsel 32 5 1 multi-arch 0 1 1 powerpc 34 5 1 s390 32 5 1 source 28 4 1 sparc 32 5 1 ----------------------------------------- TOTAL 414 64 13 Daniel Baumann nd the rest of the debian-live team are also working on official live images that we'll release with Lenny for the first time. I've got some ideas of what he's planning in terms of options, but I'll let him tell you in more detail (nudge, nudge *grin*). If you have any questions about what I've mentioned here, or any suggestions on other things we could/should be doing (such as the numbers of ISOs we're making for your pet architecture), please bring them up on the debian-cd list. We're also going to be looking for testers very soon to help us verify the d-i RC1 and Lenny releases. If you'd like to help, please let us know. Cheers,

Bits from the Debian Eee PC team, autumn 2008

Ben Armstrong — 2008-10-13T17:35:16

Also posted as http://syn.theti.ca/2008/10/13/ Some brief highlights of the last three months of Debian Eee PC development. Thermal and ACPI breakage resolved in 2.6.26-7 We're pleased to see that in the upload to Sid of linux-image-2.6.26-1-686 version 2.6.26-7, the pair of [1]2.6.26 bugs we've been tracking that have made it difficult for Eee users to upgrade their systems have been resolved. Since then 2.6.26-8 has been uploaded and is expected to enter Lenny this week due to a freeze exception. Once the new kernel has migrated we will move quickly to build and release a new installer that includes it. Ath5k wifi works on Eee PC in Linux 2.6.27 Jean-Christophe reports that [2]ath5k works in Linux 2.6.27 on the Eee PC 701, and just needs a [3]small patch to work with our eeepc-acpi-scripts package. This is good news for those of us with models 701, 900, 900A and 1000HD who have been wanting to get off of the non-free Madwifi drivers and onto DFSG free drivers. New Eee PC model 701SD wifi support in the works Users of the new Eee PC Model [4]701SD have just started showing up looking for support in mainstream Linux distros. Martin Filtenborg confirmed using our [5]Eee PC Live image with the GPL'd rtl8187se driver from Realtek to demonstrate that we can at least use it to connect to an unencrypted AP, get an IP address and ping other hosts. Of course, it is one thing to have a working vendor-supplied driver and quite another to have mainstream support. We'll make do with what we have now, but will be seeking a mainstream solution as soon as possible. We're seeking more testers and developers to work on this. To date, an ITP has not been filed, as it is not yet clear who is going to carry this work forward. Chasing the 5 second boot An interesting discussion on [6]Arjan van de Ven and Auke Kok's work to get an Eee 901 to boot in 5 seconds took place this month. While the Debian Eee PC team is not making work on this a priority, we'll keep an eye on it to see if Debian can incorporate some or all of the techniques they used so that our users can benefit without making radical changes to their systems. Working towards mainstream support for rt2860 Our filing of an [7]ITP for rt2860 (the wifi driver for models 901, 1000 and 1000H) was followed by discussion about how to separate out the GPL'd driver from the embedded non-free firmware so that it can at least go into contrib. Glenn Saberton has been working on rewriting the build system around kbuild and separating out the firmware. Numerous improvements to ACPI scripts Since my last progress report, there have been numerous improvements to the eeepc-acpi-scripts package to deal with all of the various [8]models we now support and make the scripts more robust and flexible. Check out the [9]changelog for details. References 1. http://wiki.debian.org/DebianEeePC/Bugs/2.6.26 2. http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2008-October/001301.html 3. http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2008-October/001338.html 4. http://wiki.debian.org/DebianEeePC/Model/701SD 5. http://wiki.debian.org/DebianEeePC/Live 6. http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2008-October/001324.html 7. http://bugs.debian.org/497200 8. http://wiki.debian.org/DebianEeePC/Models 9. http://git.debian.org/?p=debian-eeepc/eeepc-acpi-scripts.git;a=blob;f=debian/changelog;h=da8639cc3ca8431724061008c79d70d5379b18f6;hb=e7224bd56207ffb7746a5abe49a1ec7fccd9f17e Ben -- ,-. nSLUG http://www.nslug.ns.ca synrg< at >sanctuary.nslug.ns.ca \`' Debian http://www.debian.org synrg< at >debian.org ` [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]

Debian bugs #600000 and #1000000 contest

Christian Perrier — 2008-10-12T14:10:27

As the bug #500000 mark was turned on September 24th 2008, Debian developers and contributors need a new challenge. So, again, a small contest has been set up. The principle is very simple: please place a bet (one per person) about the day bugs #600000 and #1000000 will be reported. The winner(s) will be the person(s) placing her|his|their bet as close as possible to the real moment bug #600000 and #1000000 are reported. There is nothing to win but the pride of being the person who predicted our bug report rate for the next months|years, just what René Mayorga won by winning the bug #500000 prediction game (http://people.debian.org/~bubulle/500000.html). The bet page is a wiki page: http://wiki.debian.org/600000thBugContest It will be closed on November 30th 2008. Bets will be kept statically until bug #600000 is reported. Then the page will be reopened with a new list of bets for bug #1000000. Thus, we will have four sets of bets for bug #1000000 with even more suspense and fun!. Enjoy...

What you can do for "Lenny"

Alexander Reichle-Schmehl — 2008-10-06T16:44:49

Hi! You probably noticed by now, that Debian GNU/Linux 5.0 aka "Lenny" hasn't been released in September. Well, that's a shame, but very easy to explain: Too many release critical bugs[1]. 1: http://bts.turmzimmer.net/graph-large.png Well, our release team coordinated several transitions, took care of release goals, but it's pretty hard to estimate, how fast RC bugs will be fixed, and apparently they were a bit to optimistic :( The big question is: What can you do, to help release "Lenny" at least in this quarter? That's pretty easy: Fix rc-bugs, take care, that the fixed packages are migrated to "Lenny", do upgrade tests, document problems in the release-notes. Pretty simple, isn't it? For users (or better: For everyone) ========= Even as a "simple user" (aren't we all just users?) you may help getting "Lenny" released. Some things you can do: * If you are running stable (aka "Etch"), you could consider upgrading to "Lenny" and see, if everything works fine. Currently there are no detailed release notes documenting the procedure, so you best way to test upgrades are to: 1. Make backups 2. Change your /etc/apt/sources.list 3. Run aptitude update to get information about new packages 4. Run aptitude install dpkg aptitude apt to install the newest package management 5. Run aptitude full-upgrade If something goes wrong / something unexpected happens, please report it. If you already know a specific package, report a bug against that package. If you don't know, please report a bug describing the problem you experienced to the upgrade-reports package. If your problem is something, which can't be fixed properly, but should be documented (e.g. hardware support regressions, packages no longer available) please report a bug against the release-notes package (Bonus points if you not only report the bug, but also supply a paragraph to be added to the release notes). * Speaking of the release notes[2]: You can take a look at the bugs reported against the release notes and see if you can help there, e.g. by writing a paragraph describing a problem. 2: http://bugs.debian.org/release-notes * Install the package devscripts[3] (you'll need the version provided by backports.org[4], and run the script rc-alert --include-dists TU. You'll get a list of release critical bugs open for one of the packages you have installed. Guessing that you have them installed, because you are using them and are interested in them, you should have a very high interest to get this bugs fixed :) 3: http://packages.debian.org/devscripts 4: http://www.backports.org/ You can try to help, by trying to reproduce them and reporting that to the bug report. There are even some easy bugs, where the maintainer hasn't found the time, yet to fix it. Bug 497290[5] for example didn't need deep technical skills. It just needed someone with some time to collect the needed data for the copyright file. 5: http://bugs.debian.org/497290 * If you speak a language other than English, you might consider joining the translation efforts. While it is to late to translate the debian-installer or the installation guide to a new language for "Lenny" (perhaps for the next release then?), you could start translating the release notes to a not yet supported language. If you are willing to do so (which can be quite time consuming, especially in the final phase), please contact either your localization team[6] or the debian doc mailing list[7] if there's no local mailing list. 6: http://lists.debian.org/i18n.html 7: http://lists.debian.org/debian-doc/ See? Even as a "simple user" without deeper technical knowledge you can help us getting "Lenny" in shape to be released. If you have technical knowledge: Very good! You might want to read the next section, too, and see what applies to you, there :) For maintainers (Or: For everyone with some more experience) =============== It basically boils down to two things: If your packages have RC bugs open in "Lenny" fix them and take care, that the fix will propagate to "Lenny". If your packages don't have RC bugs open, fix someone else's RC bug. Surely you don't think, the release team will fix the remaining rc bugs, do you? And surely you understand, that your shiny rc bug free packages are kind of useless, if they aren't released? To search for bugs to be fixed, take a look at the unofficial rc bugs thingy[8]. The URL lists RC bugs open in both "Sid" and "Lenny". Obviously they should be fixed ASAP. If no one takes care about these packages, they might be removed from "Lenny" (if possible). 8: http://bts.turmzimmer.net/details.php?bydist=both&sortby=packages&fullcomment=on Again: Try to reproduce the bug, try fix it, upload an NMU (or send your patch to the bug report and search for an sponsor). You'll notice, that some of these bugs already have a patch. In that case, your job would be to test the patch, report that to the bug report and offer to sponsor an NMU. Another interesting list is the list of rc bugs open only in "Lenny"[9]. These bugs have been fixed, but the fix hasn't propagated to "Lenny", yet. Normally, the release team will grant freeze exceptions for these packages if possible. However, if the changes to the fixed version are quite grave or the package in "Sid" depends on a newer package than in "Lenny" that's not possible. In these cases look out for packages marked as "need tpu upload" or similar. 9: http://bts.turmzimmer.net/details.php?bydist=lenny-only&sortby=packages&fullcomment=on Oh, and if you could refrain from upload new upstream versions of packages to "Sid", you would make all our lives easier. Some reasons: * New packages won't reach "Lenny" anyway. * Upload new packages to "Sid" makes it harder to get a fix into "Lenny" should a new bug be found. * Uploading a new package makes it harder for other packages depending on your package to be migrated to "Lenny". * You are wasting the buildd's time. And of course you should spend your time fixing rc bugs anyway ;) Best regards, Alexander "To send out release announcements I do everything" Reichle-Schmehl

Bits from the DPL

Steve McIntyre — 2008-09-29T23:05:16

Hey folks, At the risk of sounding like a broken record here, apologies for taking so long to write this. It's been a few too many weeks since I wrote my last summary. In the last couple of months, I was ill for 3 weeks (as you may have seen from my blog post[1]) and otherwise very busy. I've been struggling to catch up with everything, but I think I'm just about there. So, what's up? Debconf! -------- Debconf 8 [2] has been and gone. We had an excellent time in Mar del Plata, with the usual mix of great technical talks and lots of socialising. The local orga team put in a huge amount of work to make the conference happen, and they did astoundingly well. I'm sure there are places where they'd disagree (*grin*), but as far as I and other attendees could see everything ran smoothly. Woo! Due to the typically long travel distance to Argentina (and, therefore, the high cost of travel), unfortunately many of our developers could not make the trip this year. However, the video team did an amazing job this year [3] - a combination of live streams of all the talks plus volunteers forwarding questions from IRC meant that people could stay involved despite the distance. For those of us that did make it down to Argentina, it was great to be able to meet up with friends old and new, and to have some very useful technical discussions. As ever, people came away re-invigorated and inspired with more ideas about what to work on next. We also got to enjoy some excellent local food, and to paddle or even swim(!) in the South Atlantic. I'm looking forwards to Extremadura next year already... :-) Press ----- A few more interviews to report on: * I met up with Sam Varghese from ITWire when he was in the UK, and we had a good chat [4]. * Bruce Byfield spoke to me and some of our past DPLs about how Debian was looking on our 15th birthday [5]. * Vincenzo Ciaglia from Linux Magazine Italy[6] asked me a wide range of questions. I don't see a copy of the article online anywhere, so I don't know if it has made into print yet. * At Debconf, I sat down with Barton George from Sun for an audio interview [7] about how Debian is going. * Another general update with Phil Manchester at The Register. [8] There are a couple more in progress that I'll mention next time once they're published. More team updates ----------------- Quite a few changes in our core teams to mention since last time. Some of these have already been announced elsewhere, but I'll summarise nonetheless. The ftpmaster team has grown, adding Mark Hymers. [9] After many years of hard work, James Troup has resigned his position in the DAM team [10]. Martin Zobel-Helas has been invited to help out as part of the DSA team [11], and to make more time for this new job, he has passed on his Stable Release Manager position to Phillip Kern [12]. Please join me in wishing good luck to all of those people with their new responsibilities. Thanks to all of them. Google Summer of Code 2008 -------------------------- We've had excellent results again this year in the Summer of Code programme. We were allocated thirteen spaces this year, but some early problems meant that a couple of our chosen students dropped out even before they started their projects. Of the remaining eleven who started the summer with us, all were successful. More details shortly once we've collected together a final report. Three of the Debian mentors (me, Daniel Burrows and Dirk Eddelbuettel) will be travelling to Google HQ for the regular post-SoC summit to join in discussions about how things went this year and how to improve for next year. What else am I up to? --------------------- Although things may have seemingly gone quiet on that front, I've continued to work through issues with several of our teams over the last couple of months. There's still more to do yet, and I'll provide public updates as and when possible. I'm trying to help as much as I can, while not wishing to cause major disruption at this point before the next release. I've been asked to look into various trademark issues that have been brought to my attention. It seems that there's quite a bit of work to be done there, so it may take a while. What else are *we* up to? ------------------------- One obvious thing: LENNY! We're due a release candidate from the d-i team very shortly [13], and elsewhere we're in a deep freeze state [14] as we make the final push. There's still work to be done, of course: we have more release critical bugs that should be fixed, and the more installation and upgrade testing we can do now, the better. Also, there's always more help needed on finishing off and translating the Release Notes; please dive in if you can. Let's make Lenny our best release yet! [1] http://blog.einval.com/2008/09/11#still_ill [2] http://debconf8.debconf.org/ [3] http://wiki.debconf.org/wiki/DebConf8/Videoteam/Thanks [4] http://www.itwire.com/content/view/19917/1090/ [5] http://itmanagement.earthweb.com/features/article.php/12297_3765826_1 [6] http://www.linux-magazine.it/ [7] http://blogs.sun.com/barton808/entry/an_inside_look_at_debian [8] http://www.theregister.co.uk/2008/09/25/debian_state_of_nation/ [9] http://lists.debian.org/debian-devel-announce/2008/07/msg00001.html [10] http://lists.debian.org/debian-project/2008/08/msg00167.html [11] http://lists.debian.org/debian-project/2008/08/msg00195.html [12] http://lists.debian.org/debian-project/2008/08/msg00196.html [13] http://lists.debian.org/debian-devel-announce/2008/09/msg00005.html [14] http://lists.debian.org/debian-devel-announce/2008/09/msg00000.html Cheers,

Debian-Edu Skolelinux Developer Gathering in Oslo, Norway, 10th-12th of October 2008

Holger Levsen — 2008-09-26T09:18:55

---------- Forwarded Message ---------- From: Anders Kringstad skolelinux.org> Hello everyone! Once again the board of Free software in schools Norway are happy to invite everyone who wish to contribute to the Skolelinux-project to our developer gathering in Oslo on the 10th-12th of October. The gathering will be held at the dep. of informatics at the University of Oslo, Norway. To register for this developer gathering, please send an email to debian-edu< at >lists.debian.org containing the following information: Subject: Yes, I will participate in the developer gathering 10th-12th of october in Oslo. Body: - Your name - Your travel expenses (if you are or plan to be an active developer, translator or contributor to Skolelinux). - Which part of the gathering you are joining (conference, technical/testing, translation, system user/documentation, facilitators) - If you are joining us for dinner on Thursday, Friday and/or Saturday - If you are a developer, we would like to know which Bug(s) you are going to work on as well. Our bugs can be found at http://bugs.skolelinux.org/ More information about the developer gathering and the conference the day after can be found here: Gathering: http://www.friprogramvareiskolen.no/Gathering/2008-10-Oslo Conference: http://www.friprogramvareiskolen.no/Gathering/2008-10-UC-Oslo If you have questions regarding attending either the developer gathering or the conference, please do send these to styret< at >friprogramvareiskolen.no or debian-edu< at >lists.debian.org. The board sincerely welcomes all old and new friends!! -- (o_ / with regards | / Anders Kringstad - skolelinux.org> //\-X Leader elect, Free software in schools Norway: www.skolelinux.org V_/_ Fri programvare i skolen: www.friprogramvareiskolen.no -------------------------------------------------------

ssh.upload.debian.org

Joerg Jaspert — 2008-09-21T14:59:58

Hi as the possibility to upload via ssh is something people like we just setup an upload queue supporting this. If you want to upload using ssh please use the hostname ssh.upload.debian.org and place the files into /srv/upload.debian.org/UploadQueue to get them processed. If you use this upload queue you will receive one more mail about your upload, at the time our queue daemon moves your files over to the ftp.upload.debian.org host. ssh.upload.d.o does support .commands files to remove broken uploads. The DELAYED queue is *not* supported using ssh. If you want to upload something with a delay, you have to use ftp. Please always only use the symbolic names for the places to upload to (ie ftp.upload.debian.org and ssh.upload.debian.org), do not use any machine name directly. Queues may move at any time, without further notice and the symbolic names will be updated.

DELAYED queue and upload hostname

Joerg Jaspert — 2008-09-20T16:30:55

Hi, for the impatient people: :) - the DELAYED queue is back on ftp-master - there is ftp.upload.debian.org, please use that in future instead of ftp-master.debian.org DELAYED queue ------------- Thanks to work from Thomas Viehmann the DELAYED queue is back on the ftp-master host, integrated with the normal processing tools. The current service provided by Tollef[1] is probably going away sometime soon. To upload your files with a waiting delay before they enter Debian, upload them into a subdirectory of the new DELAYED/ you can find at the normal ftp upload place. Packages uploaded into the X-day (X between 0 and 15) subdirectories of that DELAYED/ will be moved into the DEFERRED queue and won't be placed into the archive before the waiting time is over. To avoid confusion, the terms used are: DELAYED - the public ftp upload directories, reachable via DELAYED/X-day DEFERRED - this is the place where the uploads are placed by the queue daemon after processing and where packages wait before they are moved into the incoming queue. You can modify the queues (besides uploading packages) with *.commands files, using the following syntax. Note that any processing in the DEFERRED queue works on whole uploads (i.e. a .changes file and all the files that came with it), whereas operations in the DELAYED queue (and the normal ftp root directory) work on individual files. - To move a package from one DEFERRED directory into another, say from 8-days to 2-days delay: reschedule foo_1.2-1.1_all.changes 2-day The move-target has to be without the trailing /. - To delete an upload (and all associated files) in the DEFERRED queue: cancel foo_1.2-1.1_all.changes - To delete a broken upload in the DELAYED queue: rm DELAYED/X-day/foobar.deb or rm --searchdirs foobar* - The old mv command is no longer supported. Wildcards in .commands files are only valid for the DELAYED queue and its rm command, the DEFERRED queue commands cancel and reschedule do not allow them. There will be an overview of the DEFERRED queue at http://ftp-master.debian.org/deferred.html [1] Thank you for doing that work. ftp.upload.debian.org --------------------- To untie the upload queue from the archive DSA setup an alias to be used for future uploads. Please change your configuration of dput, dupload or whatever you use to no longer use ftp-master.debian.org but ftp.upload.debian.org instead.

Call for testing of next Debian Installer release

Otavio Salvador — 2008-09-17T12:38:47

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Call for testing of Debian Installer - ------------------------------------ We are approaching the Debian 5.0 (Lenny) release and the Debian Installer team is working to fix the remaining issues for it. The Debian Installer Release Candidate 1 is being prepared and we are short in time to make fixes. The installer has a lot of new and impressive features against last Etch release and Lenny beta 2. For a better view of the changes made on the installer since last beta, take a look on our release announcement draft[1]. We are sure you are going to have a nice feeling about it. We count on you to help us! 1. http://wiki.debian.org/DebianInstaller/ReleaseAnnounce How could I help Debian Installer team? ======================================= That is easy! Go to our development webpage[2], download the weekly builds or daily snapshots and give it a try! This is very important and simple way to help us since it is impossible for the team to try all possible configurations in different hardware sets. 2. http://www.debian.org/devel/debian-installer/ After installing it, please do a proper installation report[3] to allow us to improve the installer and make it ready for Lenny release. 3. http://d-i.alioth.debian.org/manual/en.i386/ch05s03.html#submit-bug Thanks in advance, Otavio Salvador Debian Installer Release Team - -- O T A V I O S A L V A D O R - --------------------------------------------- E-mail: otavio< at >debian.org UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - --------------------------------------------- "Microsoft sells you Windows ... Linux gives you the whole house." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ iEYEARECAAYFAkjQ+gsACgkQLqiZQEml+FVEJQCguSs7esreTm+P4IQHjom66Jq1 dMgAni+5acyEC08/sHF7K4vuDv5IbvYE =jQUN -----END PGP SIGNATURE-----