Transition: new PAM config file handling in unstable
An NMU of the core PAM packages has just been uploaded to unstable with
the maintainer's permission, and is currently available at
http://incoming.debian.org. The upload addresses the longstanding issue
of central management of PAM authentication/password services in Debian.
This message is an appeal for further testing, and an attempt to
document what needs to be done in other PAM-using packages to take
advantage of these exciting new features.
From the changelog:
* Add three new config files (/etc/pam.d/common-{auth,account,session})
to libpam-runtime. Other packages which depend on libpam-runtime
can now @include these files from their own PAM configs.
* Convert /etc/pam.d/other from a conffile to a non-conffile config
file. Closes: #186011.
What this means:
- It will now be possible to choose md5 vs. crypt passwords at install
time without violating policy. (Currently, a number of conffiles are
being modified by maintainer scripts in order to enable md5
passwords.) Actually making this process policy-compliant will
require changes to a number of other packages prior to release.
- As packages switch to this new config file scheme, administrators will
have a central set of files (four) they can edit to set a system-wide
policy for authentication to services, including services from
not-yet-installed packages; while packagers can continue shipping
their per-package default settings as conffiles.
- At a later date, it will be possible to support tools for
debconf-based management of the authentication subsystem so that
administrators can seamlessly integrate workstations into (e.g.)
Kerberos, LDAP, or Windows NT authentication realms. No work has been
done yet to develop these tools, and they are unlikely to be ready in
time for sarge; but this is a realistic goal for sarge+1, or for
customized installers based on sarge.
I believe that, with your help, we can convert most PAM-enabled packages
in Debian in time for Sarge's release, following the guidelines below.
- Per-package /etc/pam.d/ configuration files should not include
explicit 'password' blocks. Instead, services should use the builtin
libpam fallback to /etc/pam.d/other for their password changing
policy.
- Configuration files should be modified to no longer reference
pam_unix directly. For auth, account, and session blocks, such
references should be replaced with these lines:
@include common-auth
@include common-account
@include common-session
These @include lines are handled as literal includes by libpam, so
packages that currently use other modules besides pam_unix (or offer
commented-out examples) need only leave those surrounding module lines
intact.
- A versioned dependency on libpam-runtime (= 0.76-13.1) must be added
to each PAM-using package. In addition, packages that don't already
depend on the libpam-modules package must do so. (Transitive circular
dependencies prevent libpam-modules from being pulled in
automatically for you.)
- Essential packages which currently pre-depend on libpam0g (read:
login) will also need a versioned Pre-Depends on libpam-runtime
before adopting this scheme, so that they are usable in an
unconfigured state. Please consider this an introduction to the
debian-devel discussion as mandated by Policy section 3.5.
This concludes the roadmap for sane PAM handling in sarge. Should be
straightforward, right? It's only 100 packages or so...
One final comment: I know how excited everyone will be about this
revolutionary breakthrough, but owing to the newness of this change, I
would ask that you *not* avail yourselves of the 0-day policy to start
NMUing packages as part of this transition. A partial transition for
sarge is much better than locking users out of their systems, so there's
no need to be impatient with maintainers before we've even put the
code through its paces in unstable.
Happy Hacking,
--
Steve Langasek
postmodern programmer
pgp2ZJtPRfxv8.pgp
Description: PGP signature
Release update
Hello world. There's a steadily increasing buzz about the status of the sarge release, now that the new installer is on the home stretch. The release team has been hard at work on finalizing a viable release schedule, but it will take a little more time yet before that's ready to be announced. In the meantime, we do need to announce the first stage of the sarge freeze. 31 July Hard-freeze of base+standard With the release of debian-installer's second test candidate at the beginning of August, we need to provide a fixed target for the d-i team. Freezing base at this point will help us ensure the debian-installer release can be used for shaking out its *own* bugs, instead of getting caught up in new bugs from the base system. Starting 31 July, no more non-RC changes are allowed into testing for base packages or for packages of priority standard and higher. RC fixes are allowed in through the testing-proposed-updates queue, and will be hand-approved by the release team. Base libraries in unstable must also NOT change their shlibs, because these changes will not be propagated to testing before the release! Please note that for these purposes (and for the purposes of the ongoing base dependency freeze), base packages are those packages which are installed by debootstrap by the sarge target. If you're not sure whether this includes you, please check http://release.debian.org/base-packages.txt for a list of binary packages. Also keep in mind that any RC bugs currently holding new versions of base packages out of testing will need to be fixed in advance of 31 July, if you want to get your other changes into sarge. Since long freezes become a problem, you can rest assured that once base is frozen we will be moving to release as quickly as we can. This means that, even though there was no official BSP this weekend, it's still open season on all RC bugs. If you have some extra time, please consider spending it on http://bugs.debian.org/release-critical/. Of particular importance now are the bugs listed at http://bugs.qa.debian.org/. There are still around 230 RC bugs affecting sarge, which means around 230 package removals if these don't get fixed. Look for a full timeline to become available around the first of August. The current thought is to release sarge by mid-September, but we're trying not to promise anything we can't deliver. We'll let you know soon when we think this baby is due. Cheers, -- Steve Langasek [EMAIL PROTECTED] Debian Release Assistant, on behalf of the release team signature.asc Description: Digital signature
Release update: lib transitions, toolchain fixes, buildd backlog
of to unstable. Please remember to build and test these packages against sarge, not sid! - The KDE partial upgrade problems are not known to affect qt-x11-free and arts (the top two blockers in unstable, now that GNOME is fixed). The Qt updates in particular are important for sarge, so you should not worry about t-p-u uploads for packages only blocked by Qt or arts. - Kernels 2.4.27 and 2.6.8.1 have been released, with a strong committment from the debian-kernel team to make these the default for sarge. Packages are already available in unstable for many architectures, which are in need of testing to help ensure that updating is the right decision. There's not much sense in releasing a second debian-installer release candidate until this decision has been finalized. As always, please address any concerns about the release to [EMAIL PROTECTED] Cheers, -- Steve Langasek [EMAIL PROTECTED] Debian Release Team [1] http://lists.debian.org/debian-devel-announce/2004/08/msg3.html signature.asc Description: Digital signature
Release update: Qt, arts, arm, yes; freeze date, no
plan to upload (diff -u preferred) and, with approval, upload to testing-proposed-updates. Changes should be limited to translation updates and fixes for important or RC bugs. - If your package depends on KDE and you have changes you need to make to fix important or RC bugs for sarge, you will need to upload to testing-proposed-updates as well, with the same requirements as for frozen packages. - All other package updates should be uploaded to unstable only. Please use urgency=high for uploads that fix RC bugs for sarge unless you believe there is a significant chance of breakage in the new package. Finally, let's recap the original timeline, with the fixed dates traded out for variables, to see where we're going once testing-security is on-line... N+0 days ~140 RC bugs testing-proposed-updates, testing-security working for all architectures Official security support for sarge begins The testing-proposed-updates queue is already in use for uploads of RC bugfixes, but up to now testing-security is not in use. Now that it's ready, the security team can begin providing security support for sarge. The sooner this can actually happen, the better. With security support in place, adventurous users can begin testing the upgrade path from woody to sarge. Their feedback will be used for further bugfixing of packages, and to start preparing release notes. N+5 days 120 RC bugs Last call for low-urgency uploads Although the original last call has come and gone, the doors are not closed for further low-priority fixes to make there way into sarge until after testing-security is up and running. This allows us a period of time after the start of upgrade testing for low-priority fixes to get uploaded if they're targetted for sarge. Of course, bugs that warrant uploads at a higher urgency can be fixed after this date; including t-p-u uploads for RC bugs. N+16 days 90 RC bugs d-i RC2 Freeze time! A release candidate of d-i will require about three weeks to prepare, so preparations will need to begin before testing-security is fully operational to meet this timeline. Because this process has not started yet, and because of the Oldenburg conference that will keep many of our installer team busy, this gives us a date for N of at least two weeks out from today. If all goes well, for both RC bug fixes and the d-i RC2 release, we'll be ready to freeze the rest of the archive at this point. Changes to base+standard are limited to RC fixes only; fixes for RC bugs and translation updates are allowed for the rest of the archive via testing-proposed-updates. N+30 days 0 RC bugs Any remaining release-critical bugs will be fixed through uploads to testing-proposed-updates or by removals from sarge. With a final cut of the installer in the bag, we will also be fixing any remaining CD generation problems, as well as final tweaks to the installation manual and release notes. Before this point, we will also need to have kernel upgrade paths sorted out for all architectures. Around this time, we will be able to set a date for the full release. Keep up the good work, folks. We're definitely on the road to release, even if at times it is two steps forward and one step back. The release team's page at http://release.debian.org/sarge.html will continue to document new release issues as we become aware of them, and we'll continue striving to get update emails out to you on a semi-regular basis. Cheers, -- Steve Langasek [EMAIL PROTECTED] Debian Release Team [1] http://bjorn.haxx.se/debian/stalls.html [2] http://lists.debian.org/debian-boot/2004/09/msg01085.html [3] http://bugs.debian.org/release-critical/ signature.asc Description: Digital signature
Bits (Nybbles?) from the Vancouver release team meeting
of candidate architectures from 11 to approximately 4 (i386, powerpc, ia64 and amd64 -- which will be added after sarge's release when mirror space is freed up by moving the other architectures to scc.debian.org). This will drastically reduce the architecture coordination required in testing, giving us a more limber release process and (it is hoped) a much shorter release cycle on the order of 12-18 months. Architectures that are no longer being considered for stable releases are not going to be left out in the cold. The SCC infrastructure is intended as a long-term option for these other architectures, and the ftpmasters also intend to provide porter teams with the option of releasing periodic (or not-so-periodic) per-architecture snapshots of unstable. Also, since the original purpose of the SCC proposal was to reduce the size of the archive that mirrors had to carry, the list of release candidate architectures will be further split, with only the most popular ones distributed via ftp.debian.org itself. The criterion for being distributed from ftp.debian.org (and its mirrors) is roughly: - there must be a sufficient user base to justify inclusion on all mirrors, defined as 10% of downloads over a sampled set of mirrors To be eligible for inclusion in the archive at all, even in the (unstable-only) SCC archive, ftpmasters have specified the following architecture requirements: - the architecture must be freely usable (i.e., without NDAs) - the architecture must be able to run a buildd 24/7 sustained (without crashing) - the architecture must have an actual, running, working buildd - the port must include basic unix functionality, e.g resolving DNS names and firewalling - binary packages must be built from the unmodified Debian source (required, among other reasons, for license compliance) - binaries for the proposed architecture must have been built and signed by official Debian developers - the architecture must have successfully compiled 50% of the archive's source (excluding architecture-specific packages) - 5 developers who will use or work on the port must send in signed requests for its addition - the port must demonstrate that they have at least 50 users These objective requirements would be applied both to the other eight architectures being released with sarge that are not currently regarded as candidates for release with etch, and also to any porter requests asking for new architectures to be added to the archive. This plan has been signed off on by: Steve Langasek (Release Manager) Colin Watson (Release Manager) Andreas Barth (Release Assistant) Joey Hess (Release Assistant) Frank Lichtenheld (Release Assistant) James Troup (ftpmaster) Ryan Murray (ftpmaster) Anthony Towns (ftpmaster) The following people in Debian leadership roles have also expressed their support: Andreas Schuldei (DPL candidate) Angus Lees (DPL candidate) Branden Robinson (DPL candidate) Jonathan Walther (DPL candidate) Again, if you've got any questions, comments or concerns, please raise them on -devel so we can take them into account before putting this plan into effect. Further plans for etch -- After the release of sarge, the release team will stop tracking the day-to-day status of RC bugs in testing for a while. NMUs for broken packages will be minimal; instead, our RC bug handling will mostly be limited to the usual aggressive removal of broken packages from testing. This will also be a key time for the QA team to focus on deeper quality issues and methods for a change, instead of on individual release-critical bugs. Meanwhile, much of the release team's energy will be focused on coordinating the many major changes that are sure to hit the archive shortly after sarge's release. We already know of a number of major package changes coming up: gcc 4.0, python 2.4, xorg-x11 6.8.2, apt 0.6. If you are planning any other transitions that will affect a lot of packages, please let us know in advance. We will need to complete the larger transitions as fast as possible, to get testing back into a nearly releasable state quickly again after the release. It's also not too early to begin staging complex transitions for etch in experimental, particularly those transitions that will take a while to debug. Post-sarge, we also know that with the new social contract, all documentation needs to adhere to the DFSG. The biggest impact of this change is that documentation that is licensed only under the current version of the GNU Free Documentation License (GFDL) needs to be made available under a license that meets the requirements of the DFSG, or else be moved to non-free. Some maintainers have already opted to move their GFDL documentation to non-free for sarge, but the vast remainder will need to be dealt with soon after sarge's release to keep us on track for etch. Otherwise, it's business as usual for the sarge release. Please bear in mind previous
Release update: editorial changes to the testing propagation scripts
, testing-security working for all architectures Official security support for sarge begins Freeze time! Joey Schulze of the security team has given the thumbs-up for official security support for sarge as of the time of the freeze. Which is now. With security support in place, adventurous users can begin testing the upgrade path from woody to sarge. Their feedback will be used for further bugfixing of packages, and to start preparing release notes. Currently, this is tempered by known bug #278495, which affects perl when upgrading on a sizable percentage of systems. We hope this bug will be addressed soon, so that we can start getting good upgrade reports in ASAP. 5-8 May 2005 ~70-60 RC bugs Bug Squashing Party Frank Lichtenheld has, with prescient and uncanny timing, announced a BSP for this coming weekend[1]. Now that we have a relatively fixed number of release-critical bugs in sarge, we hope to quickly eliminate the remaining RC bugs. We need your help to do that, though, so volunteers for squashing bugs and processing upgrade reports is appreciated. If you are interested in helping to process upgrade reports, please subscribe to debian-testing@lists.debian.org and contact debian-release. 18 May 2005 ~15 RC bugs d-i final if needed As before, being able to hold to this schedule depends heavily on a steadily dropping RC bug count, so if that isn't happening, the timeline will have to be tweaked accordingly. Security bugs will, however, not figure into this count for the most part because they can and will be fixed post-release. Experience shows that d-i releases take a bit longer to roll out than this timeline is really allowing for, so the plan is to release sarge with d-i RC3. However, there has been some discussion of less intrusive per-arch uploads of the installer, to take care of some specific kernel bugs; if this happens, it would be around this date. 27 May 2005 0 RC bugs Any remaining release-critical bugs will be fixed through uploads to testing-proposed-updates or by removals from sarge. With a final cut of the installer in the bag and the effective RC count down to zero, it's time to finalize the installation manual and release notes and to create official CD images. 30 May 2005 Release And if everything goes well, we'll be ready to release at the end of the month. We'll continue to post updates as the freeze goes on. For now, please concentrate on fixing the last few issues, and hey, let's see if we can stick to this schedule! Cheers, -- Steve Langasek and Colin Watson Debian Release Managers http://release.debian.org/ [1] http://lists.debian.org/debian-devel-announce/2005/05/msg0.html signature.asc Description: Digital signature
Call for upgrade testing
Hi folks, Well, with security support in place for sarge we hoped to be sending this message out a week or so ago, but it took longer than expected to sort out one particularly hairy bug that was known to affect upgrades. Now that it's fixed in testing and we can accept upgrade reports without trying to filter out the noise from that bug, the release team is happy to issue this official call for upgrade testers for sarge. As in releases past, we strongly recommend that you read the release notes before upgrading, and in particular Chapter 4, Upgrades from previous releases, since some aspects of the recommended upgrade path have changed. The preliminary release notes for sarge can be found at http://www.debian.org/releases/sarge/releasenotes. Andreas Barth has prepared an upgrade report template to help when reporting problems with your upgrades. If you do run into problems when testing the upgrade path from woody to sarge, please download the template at http://release.debian.org/upgrade-report.html, fill it out, and email it to [EMAIL PROTECTED] We also welcome reports of successful upgrades, short notes to let us know things are working for you, or tasteful fruit baskets. We mentioned in the freeze announcement[1] that we needed volunteers to help with processing upgrade reports -- taking them apart, identifying the bugs that appear, and assigning them to the packages responsible so that they can get fixed for sarge. Our call for volunteers got us a total of, uh... one person offering to help, so we could probably use more. :) If you are an experienced user who is good at figuring out who to blame when things break, and you have some time you'd be willing to spend helping make sarge the best Debian release ever, please contact [EMAIL PROTECTED] We'll be happy to put you to work. Cheers, -- Steve Langasek [EMAIL PROTECTED] Debian Release Team [1] http://lists.debian.org/debian-devel-announce/2005/05/msg1.html signature.asc Description: Digital signature
Release update: freeze progress, closing date for non-RC fixes
depends on an arch: all package and your upload makes it unusable as a build-dep until it's up-to-date on all archs. Uploading a new upstream version of a library that's a build-dependency of xfree86, while a release-critical update of xfree86 is in preparation, without talking to the xfree86 maintainers first. Don't do this. The *best*-case scenario is that I get to spend an hour or two sorting out whether this upload has broken the library ABI. The worst-case scenario is much, much worse. When I say you should talk to the maintainers of packages that depend on yours, I really, really mean it. * Trigger a rebuild, because the i386 package wasn't built properly. (Closes: Bug#309365) Yeah, don't do this one either. Whether we're in a freeze at the time or not, it is a waste of buildd cycles to do a *sourceful* upload to correct for a problem with the way *binaries* were built in your build environment. If you're not making changes to the source, you probably shouldn't be uploading a new source package. Indeed, all of the above are pretty good advice at all times, but during a freeze these are the kinds of things that can really hurt the release timeline. Timeline Oh yes, the timeline. Here's (sorta) what it looks like, from today forward: 18 May 2005 ~40 RC bugs d-i final needed? No. So the RC bug count is higher than we want it to be, but definitely moving in the right direction. Can we get it where we want it by the end of the month? Possibly, if more people pitch in over the next week or so... There has been no further action on preparing architecture-specific updates for d-i, so there will be no d-i final. This means that no outstanding kernel changes will be integrated into sarge until r1. Fixes for security bugs should be available from security.debian.org well before then, of course. 20-22 May 2005 ~30 RC bugs Bug Squashing Party The count of 30 RC bugs should be the count *before* the BSP; at the conclusion of the BSP, we want this number to look more like 10. Please join us in getting rid of those last few troublesome RC bugs on the way to the release. 25 May 2005 ~10 RC bugs 0 RC bugs not tagged sarge Since it takes a few days for autobuilders to catch up after a source package has been uploaded, we want to have fixes uploaded to unstable or testing-proposed-updates for all RC bugs by the 25th. The RC bug count should at this point therefore not include any bugs that aren't tagged sarge. 27 May 2005 0 RC bugs Final version of release notes available The rest of the RC bug fixes get into testing, or the packages get removed, or the schedule slips a week. Take your pick -- I certainly prefer the first option. At the same time, we want to have the release notes finished up, as well as the installation manual if any changes are still pending. This leaves very little time for the documentation team to incorporate feedback from upgrade testing, and even less time for localization teams to complete translations. Since there are currently only three translations of the release notes that are reasonably up-to-date, we should plan to allow translations to be updated after the release itself. They obviously won't get onto the CD images (which we'll start building at this time), but there were no release notes on the CDs for woody at all, so it's not a total loss to do things this way. 30 May 2005 Release And if everything goes well, we'll be ready to release at the end of the month. If everything *doesn't* go well, then we're hopefully looking at the first weekend in June instead. Right now, this schedule is looking more ambitious than when we cooked it up, but it's not completely out of the question -- we just need to pick up the pace a bit. Cheers, -- Steve Langasek [EMAIL PROTECTED] http://release.debian.org/ [1] http://lists.debian.org/debian-devel-announce/2005/05/msg1.html [2] http://lists.debian.org/debian-devel-announce/2005/05/msg00010.html signature.asc Description: Digital signature
Procedure reminders on updating a lib package for a C++ ABI change
As a result of some questions on IRC and some ill-timed uploads that I've seen, I think it would be a good idea to highlight a couple of important points from Matthias's transition plan for the benefit of library maintainers and would-be NMUers: The library package renames, libfoo1 - libfoo1c2, libfoo1c102 - libfoo1c2, or libfoo1c102 - libfoo1, are done because there is an ABI change *without an upstream soname change*. Since there is no soname change, the files installed by the renamed package will also not change -- which means, just like for any other packages with overlapping files, you *must* conflict with the previous library package name. You must *not* add a Provides: libfoo1 or Provides: libfoo1c102 to the new package; this transition is happening because of an ABI transition, which means the new package will NOT provide the same interface as the old one, and setting Provides will lead apt to give your users broken package combinations. If one of your packages needs to be transitioned, DO NOT upload it before the C++ libraries it depends on have successfully made the transition. Barring exceptional buildd delays, you should wait until your build-dependencies have been rebuilt for g++ 4.0 on *all* architectures before uploading your package. Otherwise, you'll cause unnecessary churn on the buildds, and it will take *longer* for your package to get built everywhere. Being impatient now will mean a longer wait later. A useful interface for tracking the status of a package across architectures can be found at http://people.debian.org/~igloo/status.php. If any of what I've said above surprises you, then you should go back and read the complete email about the transition plan[1] before uploading anything. If you have questions, /ask/. Five minutes asking/answering a question now can easily save us weeks of fighting to get a package back into releasable shape. Also, for those who aren't aware, the new xorg packages now in unstable are also implicated in the C++ transition, because libGLU is implemented in C++. Particularly if you have packages that are involved in other transitions that are happening right now, it may not necessarily be a good idea to rebuild against xorg just yet unless you're already part of the C++ transition. If you do, your package will also get tangled in the same C++ transition. This has unfortunately already happened with GNOME, because of a maintainer who was in a hurry to update his build dependencies for xorg; all of GNOME 2.10 is now held out of testing until xorg is also ready to go in, even though xorg has so far only been built successfully on 4/11 architectures. In effect, this means all of the large etch transitions are now hooked together, but if you have other packages that aren't yet part of the tangle, ask before you upload and maybe you'll save yourself some trouble. Cheers, -- Steve Langasek postmodern programmer [1] http://lists.debian.org/debian-devel-announce/2005/07/msg1.html signature.asc Description: Digital signature
[EMAIL PROTECTED]: port qualification declarations for etch
Hello world! As you readers of d-d-a know well by now, one of the goals of the release team for etch is to put into effect standards governing which ports will be included in the release. The two month period for requalifying existing ports, set out in [0], has already begun, and it would be great to begin getting input from porters to help us fill in the table at [1]. It also wouldn't hurt porters to get feedback about which criteria their ports are currently failing to meet, so that they can either figure out how to meet them by November 20 or work with the release team to refine the criteria. To that end, I would like to invite you to join Anthony Towns and myself on IRC this Sunday, October 9 from -0200 UTC in the #debian-tech channel on irc.oftc.net. The goal of this two-hour session is to come up with a qualification declaration for as many architectures as possible, and to further refine the architecture criteria as necessary. A wiki page for the event can be found at [2]. This is also something of an inaugural event for the #debian-tech channel. If you don't already know about #debian-tech because you don't follow Planet Debian religiously (you know, with scented candles and angst, like any True Blogger), you can learn more about this new Debian channel-with-a-twist at [3]. The channel ops welcome your participation in this experiment, both for this event and in general. We ask that you read the channel charter[4] before joining the channel, so you are aware of a few basic ground rules; however, we do want to emphasize that the goal of the channel is to provide a friendly, easy-going, and productive environment and hope you will find that to be the case in spite of (and in part, because of!) our uncharacteristic moderated approach. So whether you're blocking out two hours on your weekend calendar, or just stopping in, we look forward to seeing you on #debian-tech this weekend! Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ [0] http://lists.debian.org/debian-devel-announce/2005/09/msg00012.html [1] http://release.debian.org/etch_arch_qualify.html [2] http://wiki.debian.org/IRC/debian-tech/Event/20051009-releasequalification [3] http://wiki.debian.org/IRC/debian-tech/ [4] http://wiki.debian.org/IRC/debian-tech/Charter signature.asc Description: Digital signature
Bits from the release team: the plans for etch
* to announce. As Colin Watson has already announced[5], he has decided to step down as my co-Release Manager for etch. Colin, thanks for all you've done; it was great working with you for sarge, and just because your title will say Release Assistant instead of Release Manager now doesn't mean we plan to let you off the hook completely for etch. ;) On the other side, that leaves a vacant Release Manager seat which the team is agreed should be filled, and Andreas Barth has risen to this challenge. Please welcome Andreas as my new co-RM for etch -- anything you would pester me about, you should now feel free to pester him about instead. :) Issues for the release notes We would like to encourage people to submit content for the etch release notes throughout the development cycle, so that upgrade concerns can be documented when the changes are fresh in people's minds. To help with that, there is now a release-notes pseudopackage at bugs.debian.org. Please use it. NMU policy ~~ After lots of experimentation with NMU policies during the sarge release process, it's pretty clear that permissive NMU policies had a HUGE, positive impact on our ability as a project to cope with outstanding release-critical issues. We don't want that to stop now just because the sarge release is behind us; NMUs don't just speed up the release, they're also great for helping the quality of Debian! For this reason, we would like to continue the 0-day NMU policy from sarge throughout the etch release cycle. But first, we'd like to hear from you, the developers, about what *you* thought did and didn't work with NMUs for sarge. So after a brief respite following the sarge release, we're ready to move etch into full swing. Look forward to more of these emails from the release team periodically from here on out, chock-full of release-y goodness! -- Steve Langasek [EMAIL PROTECTED] Debian Release Team [0] http://www.advogato.org/person/vorlon/diary.html?start=10 [1] http://www.debian.org/intro/organization [2] http://www.debian.org/devel/people [3] http://bugs.debian.org/release-critical/ [4] http://lists.debian.org/debian-devel-announce/2005/09/msg7.html [5] http://lists.debian.org/debian-project/2005/09/msg00199.html signature.asc Description: Digital signature
Re: ethique Debian
On Wed, Dec 11, 2002 at 01:46:50PM +0100, Benjamin Drieu wrote: Pour la propagande raciste, il y a un point dans les DFSG (http://www.debian.org/doc/debian-policy/ch-archive.html) qui dit : pas de discrimination contre une personne ou un groupe de personnes Attention, il s'agit de discrimination d'utilisation. En clair, un soft qui restreint son utilisation à une ethnie, une nationalité ou une religion particulière n'est pas libre. En revanche, un logiciel raciste mais libre satisfait ce point (c'est il me semble le cas de certaines bases de fortunes). Exactement. Les DFSG exigent seulement que tout le monde *puisse* utiliser le logiciel, ne pas que le logiciel soit *attractif* a tous. À propos du nom «pornview», nous avons déjà «bitchx», la langue «brainfuck» (appelée «brainf***» ou «BF» dans les archives), et je ne sais quoi d'autre. Si on trouve que le nom d'un paquet est offensif, la solution est très simple: ne l'installez pas. Sans le nom, pornview est un lecteur d'image comme tout autre. -- Steve Langasek postmodern programmer pgprayA2vcC2L.pgp Description: PGP signature
Re: qui a réussi a compiler samba3 pour woody ???
On Wed, Aug 13, 2003 at 10:02:19AM +, Eric Belhomme wrote: J'ai voulu créer des paquets de samba3 pour mettre sur mon serveur de fichiers (une debian woody stock) Qu'est ce que je suis pas allé faire la !!! j'ai passé la journée complète d'hier à backporter une 20aine de paquets de la testing vers la stable pour satisfaire les dépendances de princesse samba3 (python2.2 tcl8.4, acl, attr, debconf, ...) et quand enfin dpkg-buildpackage accpeté de lancer la compillation de samba, ca a été pour m'informer 30 minutes plus tard d'un build error :(( Du coup, je me pose des questions : les dépendances de samba3 vont (tres) loin : glibc, openssl, python2.2 qui eux-meme entrainent d'autres dépendances, etc... au final, je me retouve avec un systeme dont la plupart des paquets critiques sont backportés, ce qui amha est pas terrible au niveau de la stabilité (et evenutuellement de la sécurité) du systeme... Du coup, a-t-on une chance de voir un jour des paquets samba3 pour woody stable ? j'ai l'impression que non ;-/ Simò Sorce (du Samba Team) a des paquets pour woody à ftp://it.samba.org/pub/samba/bin-pkgs/Debian experimental main. -- Steve Langasek postmodern programmer pgpQ75QklJkiP.pgp Description: PGP signature
Re: connexion ssh aux serveurs Debian
On Mon, Jan 05, 2004 at 08:00:46PM +0100, Nicolas Bertolissio wrote: Suite à la compromission, j'ai envoyé à l'adresse qui avait été indiquée ma clé ssh pour pouvoir me connecter avec cette méthode et je n'ai donc pas de mot de passe sur ces machines. Quand j'essaye de me connecter, sur gluck pas de problème il me demande bien ma phrase de passe pour ma clé rsa, mais j'ai essayé sur d'autres machines (auric et klecker) et là il me demande un mot de passe sur la machine, et forcément je n'en ai pas puisque je n'en ai pas demandé de nouveau. Auric et klecker ont été fermés après la compromission, par question de securité (ils sont ftp-master.debian.org et security.debian.org, bien sur). http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200312/msg1.html Where can I login? -- There's been a fair bit of talk post-compromise about restricting access to machines running (core) services. At the moment, the only thing I'm (personally) doing is not enabling non-services accounts on auric (ftp-master) and klecker (security, non-US, qa, nm, www-master) immediately. Obviously, it's useful for random developers to have access to e.g. the postgres database of the archive, so the current plan if the restricted nature of auric becomes permanent is to mirror the system daily to another box that would be unrestricted. [This would have the added bonus of giving us a hot spare for disasters/arson attacks etc.] Basically the whole issue of what, if anything, to restrict is still up in the air. I'm looking for input/opinions/discussion on this. If you need access to the machines running the archives, please tell me (or probably better yet, start a thread on debian-devel) why. On a similar note some of our boxes are currently overloaded and services are generally inelegantly distributed; there's certainly going to be some juggling of them coming up. It's not decided what/when/where/how yet though, more details before it happens. -- Steve Langasek postmodern programmer pgpkdAbdloqwj.pgp Description: PGP signature
Re: non respect de build-essential
On Fri, Jan 16, 2004 at 09:38:13PM +0100, Alexandre Pineau wrote: Je suis en train d'essayer de proposer un patch pour un bug critique touchant le paquet fireflier-client-gtk et j'ai observé un truc curieux dans la ligne build-depends. Le paquet déclare une dépendance sur g++-3.2, dépendance qui fait partie de build-essential, et qui plus est avec une version inférieure! Mais, g++-3.2 ne fait pas partie de build-essential; c'est g++ qui apparait dans la liste, et si on a besoin d'un autre compilateur(?), ça n'implique pas un bogue. S'il n'y avait aucun paquet g++-3.2 dans l'archive, ça serait vraiment un bogue. Cheers, -- Steve Langasek postmodern programmer pgpN9eoJCrzvR.pgp Description: PGP signature
Re: non respect de build-essential
On Fri, Jan 16, 2004 at 10:22:06PM +0100, Alexandre Pineau wrote: On Fri, 16 Jan 2004 14:34:42 -0600 Steve Langasek [EMAIL PROTECTED] wrote: Mais, g++-3.2 ne fait pas partie de build-essential; c'est g++ qui apparait dans la liste, et si on a besoin d'un autre compilateur(?), ça n'implique pas un bogue. Certes, mais il apparait un versionning strict (= 3:3.3), ce qui m'a enduit d'erreur. S'il n'y avait aucun paquet g++-3.2 dans l'archive, ça serait vraiment un bogue. Donc on pourrait utiliser build depend pour indiquer une version de gcc 2.95? Tous les paquets ayant des problèmes de compilations avec un gcc récent pourraient donc etre corrrigés en idiquant un build depend sur gcc 2.95? Il y a autres considérations: si le paquet dépend d'une bibliothèque C++, il faut utiliser le même compilateur que cette bibliothèque. Puisque la grande plupart des paquets C++ dans la distro dépendent de telles bibliothèques, c'est assez important. Si vous avez une programme simple sans dépendences de bibliothèques C++, il est bien possible d'utiliser n'import quel des compilateurs. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: RFA: le-dico-de-rene-cougnenc -- Le Dico par René Cougnenc
On Thu, Mar 11, 2004 at 11:35:16PM +0100, Christian Perrier wrote: Il faut mettre une description en anglais, donc j'ai besoin d'un peu d'aide. conjugaisons ? conjugations. :) Cela donne pour l'instant avec mon anglais de cuisine: More than 100.000 french elements including nouns, verbs, adjectives, CONJUGAISONS et complex plural forms as well as major postal codes. . This list has been carefully elaborated by a team of french BBS users and put in the public domain in accented ASCII format either using the IBM MS/DOS charset or the ISO-8859-1 charset for other systems. Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Clavier français et RC3 de l'installateur (noyau 2.6)
On Wed, Apr 06, 2005 at 07:40:44PM +0200, Cyril Olivier MARTIN wrote: From: Christian Perrier [EMAIL PROTECTED] Un correctif dans kbd-chooser implique de reconstruire tous les initrds, de les valider, puis de reconstruire toutes les images. Puis les phases de test correspondantes... Pour mémoire, cela a pris environ 4 semaines pour la RC3. Difficile de convaincre Joey de se lancer là dedans avec comme argument Broken 2.6 french install on i386. Plus d'un an à attendre la sarge... Troisième Release Candidate... Quatre semaines de test... Et ça marche pas ! Franchement, ça va faire du bruit, et l'image de Debian n'en ressortira pas grandi. Enfin, tout ceci n'est pas très grave si la prochaine sortie de Debian n'a pas lieu dans deux ans. Je suis un peu amère. Merci de votre aide en éprouvant la version RC3 de l'installateur avant son lancement. Votre contribution à la prochaine edition de Debian ne passera pas inaperçue. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Clavier français et RC3 de l'installateur (noyau 2.6)
Allô Laurent, On Thu, Apr 07, 2005 at 07:43:55PM +0200, Laurent COOPER wrote: Lisant la liste depuis un moment, mais ne participant pas, je peux néanmoins apporter une information. Le bug existe sans doute, puisqu'il se produit avec la release-candidate de kubuntu (basé comme le dit très bien C. Perrier sur l'installeur debian) J'ai installé trois machines en me servant de ce CD comme cd d'install, et j'ai eu le problème du clavier anglais au lieu de français. Par contre, il n'est pas apparu sur une quatrième, me laissant plus que perplexe... Y'a-t-il quelque différence entre les deux groupes de machines? P.e., est-ce que les trois premières machines ont des claviers USB, et la quatrième un clavier PS/2? Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Passage en UTF-8 par d éfaut
On Sun, Sep 04, 2005 at 07:38:35PM +0200, Josselin Mouette wrote: Le dimanche 04 septembre 2005 à 14:23 +0200, Christian Perrier a écrit : Cela n'a pas posé de problème grave (en fait, ça n'en pose apparamment aucun). Suffisamment pour que j'envisage désormais de basculer la locale par défaut des installations françaises sur une locale UTF-8. Le passage en UTF-8 est un des objectifs d'etch, pour mémoire. À vrai dire, je ne comprends pas pourquoi ça n'a pas été fait pour sarge. Parce que zsh manquait de support pour UTF-8 ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Encore une question sur les transitions de libs
On Sun, Jan 22, 2006 at 08:56:50PM +0100, Pierre THIERRY wrote: Avant de comprendre puis de me tenir au courant des transitions, je ne captais jamais pourquoi apparaissaient des paquets avec un c102 ou ce genre de suffixe. Étant donné que ce sera également le cas de 99,99% des utilisateurs qui tomberont sur un upgrade qui foire, je ne comprends pas pourquoi ces paquets de transition de mentionnent pas qu'ils le soient dans la description du paquet... Dans quelle sense sont-ils paquets de transition? Ils sont paquets de bibliothèques; qu'il y *ait* une transition n'implique pas que les paquets soient transitionels. Et il est déjà assez difficile de réaliser une telle transition sans faire des corrections aux descriptions de paquet au même temps. Tenez compte que pour ceux qui installent etch, la transition n'a rien à voir; ils sont simplement les versions courrants des bibliothèques... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Gestion des licences dans le format .deb
On Sat, Aug 16, 2008 at 02:43:53PM +0200, Romain Beauxis wrote: Le Friday 15 August 2008 09:38:21 Charles Plessy, vous avez écrit : Je suppose que ce que voulait dire le journaliste, c'est qu'il y a un champ « License » dans le fichier « spec » des paquets RPM, alors qu'il n'y en a pas dans le ficher « control » des paquets Debian. Ce que je pense surtout c'est que la décision relève très probablement de critères internes à Intel et qu'Intel, puis le journaliste essaient de se rattraper aux branches pour justifier cela. Il est vrai qu'ubuntu ne respecte pas forcément très clairement la séparation entre logiciel open source et logiciel non libre. Probablement aussi qu'ils sont moins regardant sur les licences. D'où vient ce FUD-ci? Ce n'est pas vrai qu'Ubuntu manque d'une séparation entre logiciel libre (main, universe) et logiciel non-libre (restricted, multiverse). La seule différence à Debian (en ignorant certaines très petites différences de la définition de logiciel libre de chacun), c'est que les CDs d'Ubuntu contiennent des pilotes non-libres pour qu'on puisse utiliser les périphériques correspondants sans media extra, lequel est un compromis pragmatique qui donne à l'utilisateur le choix d'utiliser ces pilotes ou non. De temps en temps Ubuntu prend des décisions différentes à Debian, mais ça ne veut pas dire que les licences propres ne soient pas importantes pour Ubuntu. Mais ce dont nous manquons, tant Debian comme Ubuntu, c'est une manière de voir automatiquement la compatibilité (ou pas) de licence entre deux paquets. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: petsc_2.3.0-1_i386.changes REJECTED
[redirecting this to -devel; discussions of ftp team NEW queue policies are off-topic for -release.] On Mon, Nov 14, 2005 at 05:13:47PM -0500, Adam C Powell IV wrote: And thats what I asked for, yes. Drop the version from -dev|-dbg|-doc, use the shlib system for the rest (which makes packages built against it depending on the right version) and have fun. I understand that, and the whole proposal. And it will break a lot of things for many of my users, who need to use old versions of the -dev packages at the same time -- which is why I do the versioned -dev packages and the alternatives system. *Why* do users need to use old versions of -dev packages at the same time? How can it be so important to maintain parallel installable versions of devel packages for a library package that has only *one* reverse-dependency in Debian? For that matter, why is it important that Debian provide support for coinstallability with older packages that are, evidently, not important enough themselves to be supported by Debian? Anyway, the empty petsc-dev package is completely pointless. It can't be used sanely as a dependency or build-dependency, because it does *not* guarantee a constant interface thanks to petsc's FHS-incompatible layout. I think it would be better if there *were* a single petsc-dev package containing the header files and library links in FHS locations, making libpetsc2.2.0-dev unnecessary; but if this is not to be the case for whatever reason, then petsc-dev ought to be dropped. In any case, I agree with Joerg that there ought to only be one -dev package here... So now the needs/requests of the users are less important to Debian than removing two empty packages? Users often make requests that would be bad for the system as a whole if we honored them unconditionally. Package indices that grow without bounds are one way that choices that may be good for a subset of users come with a cost for the rest of our users. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Sat, Nov 12, 2005 at 11:11:47PM -0600, Manoj Srivastava wrote: I do stand behind my words; here are, chastizing the GFDL for not being free, standing on the verge of the rowing GNU documentation out of Debian, and yet, we blithely, though the instrumentation of an annual Debian Developer conference, accept any non-free license there is, as long as it makes our conference a success. I leave it to the readers to determine if this is, or is not, hypocrisy . Whether or not anyone in Debian is taking a hypocritical position on this issue[0], I think it would be very inappropriate to *chastize* anyone for the fact that the GFDL does not meet the DFSG. The FSF have indeed never claimed that the GFDL was a Free Software license, and they don't claim that the same freedoms that are required for programs are required for documentation, either -- a position that you may recall is shared by a significant number of developers within Debian. We may have decided that extending the same freedoms to documentation and data as to programs is important enough for us to take a stand on, but by no means does that justify haughtiness towards our fellows in the Free Software community. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ [0] Wwhen an open organization such as Debian has individual members who hold *different* positions, one usually describes that as schizophrenic, not hypocritical signature.asc Description: Digital signature
Re: library renaming due to changed libstdc++ configuration
On Mon, Nov 14, 2005 at 07:34:58PM +0100, Aurelien Jarno wrote: Matthias Klose a écrit : * Once dependencies are fulfilled for all architectures, request binNMU's for all other packages depending on a library package with a changed package name. If a source upload is necessary for other fixes, wait as well until dependencies are fulfilled for all architectures. I don't know who will handle those binNMU, but would it be possible to have, during the period of the transition, a list of the packages that have been currently binNMUed? That would help the unofficial ports to follow the transition. This is true at least for kfreebsd-i386, but I think that is also the case for amd64, armeb, m32r, hurd-i386 (even if it is in the archive, the w-b database is not hosted by Debian). I propose a list on wiki.debian.org, but maybe there is a better solution. Given that anyone with wanna-build access for an arch can fire off a binNMU, I don't know if it's feasible to provide a comprehensive list; but I've already been asked about keeping the amd64 maintainers in the loop, so I can commit to putting the information I have somewhere public. Let's make it http://ftp-master.debian.org/~vorlon/transition-binnmus.txt rather than the wiki, a wiki would be overkill. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: master's mail backlog and upgrade time
On Tue, Nov 15, 2005 at 12:18:45PM +, Ian Jackson wrote: Ryan Murray writes (master's mail backlog and upgrade time): Also, I've investigated the mail backlog on master and found the main problem. The mail queue is currently full of email that will never be able to be delivered, all for one particular user. This mail is being removed from the queue, and the setup changed to not deliver to the problem address. Once this is finished (a few days), mail latency for mail moving through master should be greatly improved. I have now discovered that the `one user' referred to is at least two of the users of my colo system, chiark.greenend.org.uk. Based on specifics (well... more-specific vaguenesses) mentioned by Ryan elsewhere, I don't believe this is the case. Chiark appears to be on the wrong continent to be attached to the user in question, and reducing one to two seems like a rather incredible off-by-one error to make in this case. * I now discover by reading master's exim4.conf that all mail to the _mail domain_ chiark.greenend.org.uk has been arranged to bounce on master. This is contrary to what is stated in the announcement, which says that the setup was changed `to not deliver to the problem _address_' (emph. mine). Well, I certainly see a line in that file relating to chiark, but I have no exim-fu to understand the precise semantics -- and certainly no idea why it's there, sorry. Regarding the problem and how to solve it: * The mail backlog that `will never be able to be delivered' was (as far as I can tell) all spam that chiark has been properly rejecting. No: there is nothing proper about rejecting mail from a host that you have configured to forward mail for you. * It is unfortunate that (a) master has such a lax spam policy and that (b) Debian developers cannot choose to make their @debian.org address unuseable other than by the Debian system administrators. ... procmail? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Testing-watch emails
On Sat, Nov 05, 2005 at 12:17:29AM +0100, Henning Makholm wrote: Scripsit Steve Langasek [EMAIL PROTECTED] If you're interested in making this happen I'll be happy to give you any info I can; 2) Any advice on how to test patches to ftp-master code before submitting them? My own scripts I can dry-run by substituting a dummy command for sendmail and run them in the very place where they will eventually function. In contrast, construcing a test mock-up of the ftp-master environment to do test runs of a patched britney appears to be highly nontrivial. Does some automation for this purpose exist? Or what do ftpmaster/release gurus do when you change code? Heh, so I guess the only info I can offer you is to say that no, there's no particularly useful automation for this... creating a copy of the ftp-master env is non-trivial, yes, but it's also the only real option, AFAIK. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: petsc_2.3.0-1_i386.changes REJECTED
On Tue, Nov 15, 2005 at 05:15:28PM -0500, Adam C Powell IV wrote: On Mon, 2005-11-14 at 23:59 -0800, Steve Langasek wrote: I understand that, and the whole proposal. And it will break a lot of things for many of my users, who need to use old versions of the -dev packages at the same time -- which is why I do the versioned -dev packages and the alternatives system. *Why* do users need to use old versions of -dev packages at the same time? How can it be so important to maintain parallel installable versions of devel packages for a library package that has only *one* reverse-dependency in Debian? Users of PETSc are developers, almost always of some local code of their own, most of the time which links with third-party libs, such as libmesh (not yet in Debian), dolfin (from what I hear may soon be in Debian), etc. Because PETSc upstream changes its API with every point release, a user's local code -- and these various third-party libs -- often lag behind, such that upgrading a single libpetsc-dev package would break all of those builds. On the other hand, upgrading my petsc-dev package requires only a simple update-alternatives --config to reinstate the older version as the default, since the newer one doesn't conflict with or replace the older one. Ah, I didn't notice the alternatives there. That's definitely an interesting approach to dev packages; though given that only root can run update-alternatives, I don't know that this is really much of an advantage over just keeping two .debs around and switching between them. For that matter, why is it important that Debian provide support for coinstallability with older packages that are, evidently, not important enough themselves to be supported by Debian? In contrast, libxml-dev has 731 users and at least one major reverse dependency (gnucash), making it much more valuable. Not to mention just one large API change, vs. PETSc's, um, 10 or so since I first uploaded it. Right; it's the API changes that make the idea of an unversioned petsc-dev package of questionable utility... Why is coinstallability worth supporting? The package is worth much more to those few users with this feature than without it, as described above. I've had a number of users contact me about old versions, which are available at a URL in README.Debian, and which might be necessary for an old version of one of the packages mentioned above, or even some old code written by a former grad student in a research group. Ok, that's fair. Anyway, the empty petsc-dev package is completely pointless. It can't be used sanely as a dependency or build-dependency, because it does *not* guarantee a constant interface thanks to petsc's FHS-incompatible layout. I think it would be better if there *were* a single petsc-dev package containing the header files and library links in FHS locations, making libpetsc2.2.0-dev unnecessary; but if this is not to be the case for whatever reason, then petsc-dev ought to be dropped. In any case, I agree with Joerg that there ought to only be one -dev package here... So then, we don't need python-dev? python-dev provides an interface that packages can build-depend on which gives them both /usr/bin/python, and a set of development tools from the corresponding version of python. This is not analogous to petsc-dev, which only depends on the versioned -dev package. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: petsc_2.3.0-1_i386.changes REJECTED
On Wed, Nov 16, 2005 at 01:46:04AM -0600, Peter Samuelson wrote: [Steve Langasek] python-dev provides an interface that packages can build-depend on which gives them both /usr/bin/python, and a set of development tools from the corresponding version of python. This is not analogous to petsc-dev, which only depends on the versioned -dev package. The only point of python-dev seems to be to pull in the development package for Debian's default python version. That it also pulls in 'python' (another near-empty package) is pretty incidental to that. No, it is *not* incidental to that. Package: python-dev Depends: python (= 2.3), python ( 2.4), python2.3-dev (= 2.3.4-18) If the python dependency were incidental, there would be no reason for the versioned dependency. This is specifically there to ensure that you get a consistent devel environment for the version of python that's installed as /usr/bin/python. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Packages still shipping schemas in /etc
On Wed, Nov 16, 2005 at 11:02:40AM +0100, Josselin Mouette wrote:
Thanks to the introduction of dh_gconf, the list of packages shipping
their GConf schemas in /etc has dramatically reduced. I think it's time
to file bugs against the remaining packages. These packages should use
dh_gconf, build-depend on debhelper = 4.2.13 and depend on
${misc:Depends}. Packages using cdbs just have to use the gnome.mk
template to benefit of it.
Except that cdbs depends on debhelper (= 4.1.0); an additional
build-dependency on the correct version of debhelper is also still required
in the cdbs case.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: master's mail backlog and upgrade time
On Tue, Nov 15, 2005 at 04:01:10PM +, Ian Jackson wrote: If a domain was set up to be treated this way for an unrelated reasons without an announcement anywhere, surely that is even worse ! Well, it's no longer DSA is making misleading statements about the nature of the problem; the fact that you weren't notified when this was done is bad, but it could be that they tried to contact you and failed for whatever reason, so I certainly reserve any judgement until both sides have commented... On Tue, Nov 15, 2005 at 12:18:45PM +, Ian Jackson wrote: * The mail backlog that `will never be able to be delivered' was (as far as I can tell) all spam that chiark has been properly rejecting. No: there is nothing proper about rejecting mail from a host that you have configured to forward mail for you. Nearly all of this mail flow is invalid in one way or another. Of course it is. That doesn't make it proper to reject such mail when you've told some other host to forward it to you in the first place; I'm sure it's a pretty common misconfiguration in the context of Debian mail forwarding, but that doesn't make it right... What is happening is that master provides a mail forwarding facility with a lax input policy, but I forward my mail to chiark which does stricter checks and has a stricter policy. This has the effect of turning the rejected messages into bounced bounces on master. This would be an unfriendly thing to do if the sysadmins on master actually cared about reliable mail delivery and took a policy of reviewing bounced bounces and dealing with their causes (as I do on chiark). It's an unfriendly thing to do *anyway*. Performance of Debian mail service has sucked for a while, and based on my own experiences running such systems, I have no doubt that bounced forwards account for a lot of this sluggishness, not even counting the one particular user who was clogging the system with gigs of mail. Ryan now seems to be making quite a bit of progress on fixing these problems with the mail setup -- not just with eliminating antisocial mail forwarding configs, but also with making improvements on the input side so master doesn't *have* to store and forward so much garbage email. Like many others, my first reaction is Finally! Thank GOD!, but obviously DSA is comprised of volunteers like everything in Debian, and kudos are certainly due for his work on this - even if some of the changes may have been implemented in a suboptimal fashion. Anyway, the line in question is still in master's exim4 config; you may want to try sending a mail to debian-admin, let them know what you've done on your end, and ask if there's anything still preventing its removal... But, there is another important point: I don't really want a debian.org address. It's technically necessary for me to have one for (eg) cronmail from debian systems, and additionally I feel that there is an (unwritten) rule that I should have one. But it is simply untenable to suggest that I ought to accept all of this junkmail and actually read it ! So accept it and auto-discard it instead, if you prefer; but don't throw it back at master after telling master to send it to you. ... procmail? How would that help ? I could arrange for procmail to try to detect whether (eg) the mail had ever been through any non-debian.org host and if so construct a bounce. But this is no better and no worse than me having chiark rejecting the mails at SMTP time. It would still lead to master having to deal with lots of undeliverable bounces. Why would you need to bounce instead of discarding? If it's not a valid contact address for you, I don't see why you would be so concerned about sending notifications to people trying to use it. That was relevant 5-10 years ago; today it's a waste of resources. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: master's mail backlog and upgrade time
On Thu, Nov 17, 2005 at 01:41:31PM +0100, Frank Küster wrote: Steve Langasek [EMAIL PROTECTED] wrote: No: there is nothing proper about rejecting mail from a host that you have configured to forward mail for you. Nearly all of this mail flow is invalid in one way or another. Of course it is. That doesn't make it proper to reject such mail when you've told some other host to forward it to you in the first place; I'm sure it's a pretty common misconfiguration in the context of Debian mail forwarding, but that doesn't make it right... How can I avoid such a problem if I do not have the power to influence the mail server configuration of the machine that hosts the account I forward my Debian mail to? I currently forward Debian mail to [EMAIL PROTECTED], and although the domain is mine, the MX is not. I have no way to control the spam or any other policy of this server. Fortunately (or rather unfortunately except in this case) this server is really lax in accepting spam (they only offer to mark it in the subject). But if it was strict, what should I do? Not forward Debian mail and instead get it from master with POP3? Grabbing your mail off of master is one option. For that matter, continuing to forward it is an option, too... just, y'know, don't try to claim that sending SMTP rejects back to master is a *good* thing... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Automated testing - design and interfaces
[let's get this over to a technical list like it was supposed to be ;)] On Thu, Nov 17, 2005 at 10:43:34PM +0100, Stefano Zacchiroli wrote: On Thu, Nov 17, 2005 at 06:43:32PM +, Ian Jackson wrote: This means execute debian/tests/fred, debian/tests/bill, etc., each with no arguments, expecting exit status 0 and no stderr. The Having been involved in various unit testing packages I found the above expectations too much constraining. The first thing you will need after requiring all tests not to fail is to be able to distinguish: test that need to suceed vs test that need to fail. Only the misbehaviour of tests wrt their expected result should be reported as test failures. I thus propose to add Following your exit status based approach you could add to stanzas something like: Expected-Status: 0 I found the above requirement the very minimum for a test interface. What follows is optional (IMHO). FWIW, I don't see that there's a clear advantage to having the test harness *expect* non-zero exit values (or non-empty output as you also suggested). It may make it easier to write tests by putting more of the logic in the test harness, but in exchange it makes it harder to debug a test failure because the debugger has to figure out how correct and incorrect are defined for each test, instead of just getting into the meat of seeing why the test returned non-zero. Likewise, expecting successful tests to be silent means that you can rely on any output being error output that can be used for debugging a test failure. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 2
On Fri, Nov 18, 2005 at 06:08:52PM +0100, Bill Allombert wrote: Probably I should do a massive bug report ? Sounds like a good idea to me. Thanks for working on this! Though I think we have at least some false-positives to weed out first: * libxtst6 libxtrap6 libxrender1 libxrandr2 libxpm4 libxp6 libxt6 libxmu6 libxi6 libsm6 xlibs Given that I can remove xlibs from my system and not take any of these other libs along, this looks like a false positive (probably as a result of the many or'ed deps on xlibs). Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: petsc_2.3.0-1_i386.changes REJECTED
On Wed, Nov 16, 2005 at 10:53:57AM -0500, Adam C Powell IV wrote: For that matter, why is it important that Debian provide support for coinstallability with older packages that are, evidently, not important enough themselves to be supported by Debian? In contrast, libxml-dev has 731 users and at least one major reverse dependency (gnucash), making it much more valuable. Not to mention just one large API change, vs. PETSc's, um, 10 or so since I first uploaded it. Right; it's the API changes that make the idea of an unversioned petsc-dev package of questionable utility... Fair enough. It's a convenience, but one which forces a user/developer to upgrade his/her code -- or point to the old version (likely still there because there are no conflicts) until such time becomes available. Hmm. Perhaps the analogy to linux-image-2.6-SUBARCH is better. The kernel API changes enough to suggest or require some new utilities, and obsolete others. This *usually* doesn't require users to change things, as there's a big effort to be backward compatible (e.g. ALSA provides an OSS-compatible interface), but not always. Well, I think the factor there is that we usually want users to upgrade to the latest kernel automatically, whereas users of petsc usually can't auto-upgrade to the new API. But what about the empty linux-image upgrade convenience packages mentioned above? If the answer is Such packages are all bad and should go away, I'm fine with that. No, I certainly think that packages like linux-image-2.6-686 should be kept around. And you've also made a case for why it may be useful to keep petsc-dev around. In any case, it's ultimately the ftp team's decision to make; it sounds to me like all the arguments have been made at this point. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: How to deal with dependencies/conflics on third party packages
On Sun, Nov 20, 2005 at 10:23:58AM +, Joerg Sommer wrote: I've got a bug report (#336527) my package bootchart-view do not work with j2re1.3. But j2re1.3 is not in Debian. Can I set a conflict upon a packages that is not in Debian? But if it do not work with j2re1.3 it should more than ever not work with older version. But I would assume older version have different packages names. So I must add a list of packages names (j2re1.3 j2re1.2 j2re1.1), because I can not use the version clause (j2re1.3 ( 1.3)). So what should I do? Does not work with j2re1.3 means you should be depending on what it *does* work with, not trying to conflict with (unrelated) packages that don't satisfy the dependency. The problem here is that bootchart-view depends on '| java-virtual-machine', which does not satisfy its runtime needs. Depend on something more appropriate; possibly even j2re1.4. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Spliting packages between pkg and pkg-data
On Sun, Nov 20, 2005 at 12:03:33PM -0600, Steve Greenland wrote: On 20-Nov-05, 05:13 (CST), Bill Allombert [EMAIL PROTECTED] wrote: When doing research about circular-deps, I looked at a lot of packages that are split between a binary package and a data package. This is a good thing since this reduce the total siez of the archive, however there are simple rules that should be followed: [*snip* good rules} 5) Of course move /usr/share/pkg to pkg-data. Why? If I install foo, I really expect it's shared data to be in /usr/share/foo. I think he means the contents of /usr/share/pkg should be shipped in package pkg-data. (I misread this the first time, too. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Man page owner
On Sun, Nov 20, 2005 at 08:40:17PM +, Rich Walker wrote: This is probably a question with an obvious answer, but I couldn't find the answer. Why are man pages installed with owner and group root rather than owner and group man? Why would man need write access to the man pages? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: How to deal with dependencies/conflics on third party packages
On Sun, Nov 20, 2005 at 11:50:55PM +, Joerg Sommer wrote: Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Nov 20, 2005 at 10:23:58AM +, Joerg Sommer wrote: I've got a bug report (#336527) my package bootchart-view do not work with j2re1.3. But j2re1.3 is not in Debian. Can I set a conflict upon a packages that is not in Debian? But if it do not work with j2re1.3 it should more than ever not work with older version. But I would assume older version have different packages names. So I must add a list of packages names (j2re1.3 j2re1.2 j2re1.1), because I can not use the version clause (j2re1.3 ( 1.3)). So what should I do? Does not work with j2re1.3 means you should be depending on what it *does* work with, not trying to conflict with (unrelated) packages that don't satisfy the dependency. All packages in Debian they provide java-virtual-machine work with bootchart-view. That includes jamvm and gij-3.3? But all alternative JVMs do only work with svg output and only Sun's JVM support png. This is the reason, why I don't want restrict the dependencies upon the JVMs in Debian. I don't understand this explanation at all. The bug report is about a failure due to class version mismatches; what does this have to do with svg vs. png? The problem here is that bootchart-view depends on '| java-virtual-machine', which does not satisfy its runtime needs. Depend on something more appropriate; possibly even j2re1.4. I can not find this package The implication was that j2re1.4 would be a virtual package, provided by those packages which implement the 1.4 spec. But of course, there's also a *real* j2re1.4 package, not available in Debian but buildable using java-package. The main point is not that j2re1.4 is the correct name to include in this list (it may be, but I don't know that for sure); the point is that java-virtual-machine is *incorrect*, because j-v-m only ensures you a lowest common denominator feature set, and that's obviously not sufficient in this case. Can I depend on packages they are not in Debian? This would be new to me. In a list of alternatives, sure. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: petsc_2.3.0-1_i386.changes REJECTED
On Sun, Nov 20, 2005 at 06:57:36PM -0500, Adam C Powell IV wrote: Well, I think the factor there is that we usually want users to upgrade to the latest kernel automatically, whereas users of petsc usually can't auto-upgrade to the new API. Okay, then what about octave, another empty package which forced an incompatible auto-upgrade from octave2.0 to octave2.1, and now to 2.9? Probably depends on how incompatible the upgrades are. BTW, the other big reason for linux-image-2.6-$flavor metapackages is that they provide a hook for debian-installer, so the installer doesn't have to be futzed with in 5 places every time there's a kernel update. And come to think of it, the python-dev python version consistency argument doesn't really apply to anyone running a single distribution, because the python version in that distribution is automatically identical to the python-dev version. The only way this guarantee of the same pythonx.y-dev and python - pythonx.y actually does anything is if an admin somehow attempts to shoehorn the woody python with the sarge python-dev onto the same system, and how likely is that? So you're suggesting that people who package python tools should be ok with having to update their build-dependencies as part of every python transition, even when nothing else in their package needs to change? (This also has implications for backports and cross-ports, mind you...) Again, the point is that these are all over Debian, and it's inconsistent to accept all but one. I don't think anyone has been proposing an inconsistent guideline, here. I'll grant you that these guidelines probably haven't been *applied* consistently in the past, but that's not the same thing. Joerg, the ball is in your court: * There is broad consensus for versioned -dev packages (e.g. Thomas Viehmann's precedent, Junichi's libpkg-guide), No, actually, there are vocal *proponents* of versioned -dev packages. That's not the same thing as broad consensus. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: status of vore?
On Mon, Nov 21, 2005 at 10:10:38AM +0100, Peter Van Eynde wrote: I would need to have access to a sid chroot on sparc to build sbcl by hand, but vore seems to be unreachable by me. The machine page [1] shows no indication of problems, it is outdated? The db.d.o page doesn't get status updates all that frequently, I'm afraid. Yes, vore has been down for a while now -- about three weeks, actually. This leaves us without a porter machine for sparc at present; there's been talk of putting user chroots on auric, but this may be dependent on another sparc buildd being brought on-line (and one is in the works) so that auric isn't doing double-duty as a porter machine and buildd. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Uploading amd64 packages
On Tue, Nov 22, 2005 at 08:13:23AM -0600, Ken Bloom wrote: Why not accept the AMD64 binaries, then dump the AMD64 binaries because you don't know what to do with them, but accept the arch:all debs from that upload? Why would ftp-master want to work on special-casing amd64 for this instead of just working on getting amd64 into the archive? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Wed, Nov 23, 2005 at 10:52:52PM +0100, Marc Haber wrote: On Wed, 23 Nov 2005 12:09:34 -0600 (CST), Adam Heath [EMAIL PROTECTED] wrote: There's been no push. No default. No message saying that it's acceptable and wanted to sign debs. So Debian doesn't care about security. If we did, we would have an official message saying so. Why do we have the reputation of being so secure? It's an elaborate hoax we put together in order to see how you would react when you found out it wasn't true. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: ssl/crypto
On Wed, Nov 23, 2005 at 11:43:27PM -0800, Thomas Bushnell BSG wrote: libgnutls-dev is a suitable substitute for libssl-dev when one wants libssl. However, libssl-dev provides *two* libraries; the other is libcrypto. Is there a GPL-compatible replacement for the latter? libgcrypt -- separate source package. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: possible freetype transition; improved library handling needed for all C/C++ packages
On Thu, Nov 24, 2005 at 01:25:07AM +0100, Henning Makholm wrote: Scripsit Steve Langasek [EMAIL PROTECTED] * Don't use other *-config tools. While many libraries these days use pkg-config, there are also other libs which ship their own tools for querying library and header include paths, libs needed for linking, etc. The problem is that all of these tools I've seen are incapable of distinguishing between what's needed for static linking, and what's needed for dynamic linking. Would you recommend against *shipping* such a script when upstream provides it (in addition to a .pc file)? If upstream ships both a .pc file (either correct, or fixable as described) and a -config script that does the wrong thing, then yeah, I would recommend to not ship the -config script unless there is a compelling reason why you need to keep it... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: possible freetype transition; improved library handling needed for all C/C++ packages
On Thu, Nov 24, 2005 at 03:12:46PM +0100, Daniel Schepler wrote: Le Jeudi 24 Novembre 2005 14:43, Peter Eisentraut a écrit : Steve Langasek wrote: * Use Debian's libtool. I took one affected package (kmldonkey) from your list, relibtoolized it as described, and rebuilt it, which failed spectacularly. Then, I took another one (rekall), relibtoolized it, rebuilt it, and that failed with a strikingly similar pattern. kmldonkey links with the following libraries: -lkdeui -lkio. As shipped, libtool expands that to every library under the sun. The new libtool indeed reduces this to /usr/lib/libkdeui.so /usr/lib/libkio.so and a few system libraries/objects, which is then greeted by ld with hundreds of error messages of the kind: /usr/share/qt3/include/qstring.h:847: undefined reference to `QString::shared_null' /usr/share/qt3/include/qstring.h:848: undefined reference to `QStringData::deleteSelf()' Both libkdeui and libkio reference (as shown by ldd) libqt-mt (which I suppose is where these symbols should be). The error messages in the rekall build are of the sort .../rekall-2.2.3-2/db/mysql/kb_mysql.cpp:595: undefined reference to `i18n(char const*)' In this case -lqt-mt is actually on the libtool command line. So what is wrong here? Have other maintainers of Qt/KDE-related packages perhaps experienced this? Try debian/patches/common/07_disable_no_undefined.diff from any of the core KDE packages. Er... that doesn't sound like a good thing, why would you want to allow undefined references? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote: That's easy: you trust the Packages file to be correct when using apt, and it's not verified at all by per-package signatures. In what way trust and how does that change anything? At best you can prevent a newer version of a package to appear in the Packages file by compromising it. You can't subvert a package itself. But you can already ship yesterdays Release.gpg, Release and Packages file to a user and thereby prevent any updates. On the other hand, without package signatures ftp-master adds a vulnerability. You can hack into it, replace debs, recreate the Packages, Release and Release.gpg file and thereby infect users. With signed debs that could still be detected by every user in apt-get. Only if every user is in a position to verify signatures from each Debian developer individually, which is completely unrealistic. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
On Thu, Nov 24, 2005 at 10:36:41PM +0100, Thiemo Seufer wrote: I can see arguments against it, but none that make it an RC bug. Policy violations are RC by definition. Actually, no; policy violations are RC by *default*, but the definition of what's release-critical for a release is set by the release team with input from the developer community. I'm fairly certain that we're shipping packages in sarge that have maintainer fields pointing at people who have orphaned the packages in question; if it wasn't true at the time of the sarge release, it will certainly be true of sarge by the time etch releases. If we can survive this, I don't think that putting a mailing list address in a changelog (wrong though I think it is) would be grounds for delaying the release or removing the package from the release (the definition of RC). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 02:57:36PM +0100, Goswin von Brederlow wrote: Steve Langasek [EMAIL PROTECTED] writes: On Thu, Nov 24, 2005 at 07:17:06PM +0100, Goswin von Brederlow wrote: That's easy: you trust the Packages file to be correct when using apt, and it's not verified at all by per-package signatures. In what way trust and how does that change anything? At best you can prevent a newer version of a package to appear in the Packages file by compromising it. You can't subvert a package itself. But you can already ship yesterdays Release.gpg, Release and Packages file to a user and thereby prevent any updates. On the other hand, without package signatures ftp-master adds a vulnerability. You can hack into it, replace debs, recreate the Packages, Release and Release.gpg file and thereby infect users. With signed debs that could still be detected by every user in apt-get. Only if every user is in a position to verify signatures from each Debian developer individually, which is completely unrealistic. Up to a point you can trust the keyring. As much as you can trust any DD signature. You try to argue that signatures are not absolutely trustworthy but that is nothing new. I'm arguing that a 5-hop-long signature chain to establish the validity of a Debian package is as good as useless, and worse if the user doesn't understand this. And a 5-hop-long signature chain does *not* mean that anyone in that chain trusts the person holding the key on the end to upload packages to Debian. The only thing we have that establishes *that* is the presence of the user's key in the Debian keyring, so then you have the logistical problem of how arbitrary users are supposed to verify whether a given key is in the keyring. The debian-keyring package doesn't get updated every time there's a key added or removed, and the web interface to keyring.debian.org doesn't provide any cryptographic assurances. Oh, and BTW, check the IPs of ftp-master.debian.org and keyring.debian.org... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#340934: lintian check for unneeded/transitive shlibs dependencies
On Sun, Nov 27, 2005 at 06:05:52PM +0100, Henning Makholm wrote: I have written a Lintian check which attempts to flag instances of this problem. It looks for ELF objects that flag shared libraries in the default search path as NEEDED without actually importing symbols that the library exports. This produces a lot of noise in a case where a package has multiple binaries or libraries (sometimes in multiple packages), and a Makefile that links everything to a common set of libs which not everything needs. Your check flags this correctly, but it can be a real pain to fix, and doesn't usually cause practical problems - particularly the problem Steve writes about. Remember, the granularity of testing migrations and library transitions is not the file or even the binary package, but the source package. This appears to be a fair point. I think I'll revise my proposal so it works per .deb rather than per object file. I'd like to see some broader debate, however. I am not conviced that the entire _source_ package is the right level to check this at. Steve mentioned two problems - one is painfullness of library transitions, the other is segfaults in case of partial upgrades. While the first problem indeed works on the source package level, the second is often a matter between binary packages with the same source. I agree that we need better granularity than per-source. I actually think that having it per object file is ideal in the long run, though in the short term doing it per binary package means less confusing noise. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: package name changes in atlas-cpp (was Re: library renaming due to changed libstdc++ configuration)
On Mon, Nov 28, 2005 at 10:09:00AM -0600, Ming Hua wrote: On Tue, Nov 15, 2005 at 06:28:05AM +0100, Matthias Klose wrote: * Rename and rebuild the libraries listed below. The new suffix for these packages should be in any case c2a (instead of c2). No new suffix is needed when the soname changes in a new upstream upload. I noticed that atlas-cpp with renamed library packages has been uploaded, and it renames the binary packages as follows: libatlas-cpp-0.6-0 = libatlas-cpp-0.6-0c2 libatlas-cpp-0.6-0-dbg = libatlas-cpp-0.6-0c2-dbg I have two questions for this: 1. Should -dbg packages be renamed or not? I don't see any reason to rename the -dbg packages, generally. 2. Shouldn't the suffix be c2a in this case? Yes, it should. If the package was being renamed because of an soname change, then there'd be no need for the c2a; but since the package is being renamed *only* because of the C++ ABI change, being consistent is important because there way be other packages in the wild named libatlas-cpp-0.6-0c2 which *aren't* using the final mt allocator ABI. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: package name changes in atlas-cpp (was Re: library renaming due to changed libstdc++ configuration)
On Tue, Nov 29, 2005 at 11:38:32AM +0100, Stephan Hermann wrote: Hi Ming, Steve, others, On Tuesday 29 November 2005 11:03, Steve Langasek wrote: On Mon, Nov 28, 2005 at 10:09:00AM -0600, Ming Hua wrote: On Tue, Nov 15, 2005 at 06:28:05AM +0100, Matthias Klose wrote: * Rename and rebuild the libraries listed below. The new suffix for these packages should be in any case c2a (instead of c2). No new suffix is needed when the soname changes in a new upstream upload. I noticed that atlas-cpp with renamed library packages has been uploaded, and it renames the binary packages as follows: libatlas-cpp-0.6-0 = libatlas-cpp-0.6-0c2 libatlas-cpp-0.6-0-dbg = libatlas-cpp-0.6-0c2-dbg I have two questions for this: 1. Should -dbg packages be renamed or not? I don't see any reason to rename the -dbg packages, generally. For the first cxx transition during Breezy development, I renamed libatlas-cpp-0.5 to libatlas-cpp-0.5c2 because this was our plan. Every package without c102 (from old ABI changes) will get c2 and the other library packages with a c102 suffix, the c102 will be removed. For Debian there was another decision, and it's in the responsibilty of the Debian package maintainer, if he wants to rename or not. (If I recall the mail correctly). Absolutely not. Renaming of library packages on ABI change is mandatory in Debian, just as it was for Ubuntu. Anyway, the fact that there was never a c102 version of libatlas-cpp-0.6 in Debian or Ubuntu certainly cuts down on the chances of there being an incompatible libatlas-cpp-0.6-0c2 package in the wild. So it's not *crucial* that this package be named -0.6-0c2a, but it would be nice to not have gratuitous inter-distro incompatibilities when they can be avoided. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: package name changes in atlas-cpp (was Re: library renaming due to changed libstdc++ configuration)
On Wed, Nov 30, 2005 at 10:21:34PM +0100, Michael Koch wrote: On Wed, Nov 30, 2005 at 09:10:58PM +0100, Stephan Hermann wrote: Don't worry :) If new 0.6.0 upstream source will change the soname and the package is named to libatlas-cpp-0.7 then you can just conflicts/replaces to libatlas-cpp-0.6, libatlas-cpp-0.6c2, libatlas-cpp-0.6c2a, so ubuntu can sync it directly without any problems. we are then in sync again and avoid any serious troubles during updates. It will be named libatlas-cpp-0.6-1. Just its interface version is changed. Actually what you can also do is to follow Matthias Kloses post from 2005-11-14 about the libstdc++ new allocator transition. You actually need to rename libatlas-cpp-0.6c2 to c2a so we are in sync as well.. If you want I can send you an accurate debdiff. Any objections? I dont mind what the solution of this problem is finally choosen. My Problem is that I made the same fault with wfmath and cal3d. I would like a vote from a RM about this. Steve ? Well, if the soname will be changing again soon anyway then there's no reason to reupload just to add the a to the package name. If the lib soname is going to be around for a while, though, for my part I think it's worthwhile to get the package name consistent across distros where possible; and in that case, the c2a name should be preferred since that's the name specified in the published transition plan. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: texlive-basic_2005-1_i386.changes REJECTED
On Thu, Dec 01, 2005 at 09:51:34AM +0100, Frank Küster wrote: Peter Samuelson [EMAIL PROTECTED] wrote: [Frank Küster] Why do we need two packages containing the latex command, for example? Why do we need N packages that provide MTA functionality? That's not equivalent. An equivalent question would be more like why do we need N packages all containing the source code for exim and building a binary called /usr/sbin/exim? What I mean is, AFAICT, if you get past the packaging, tetex and texlive are the *same* source code and the *same* data - not just two different implementations of a similar interface. The source of teTeX is a *subset* of TeXLive's source, modulo versions. Then we definitely shouldn't need two copies of it! It will serve our users to be able to install, as a Debian package, the parts of TeXLive that are not included in teTeX. Then why can't TeXLive build binary packages: - tetex-bin, containing all the usual goodies it provides today - tetex-extras-double-plus-good, containing the new TeXLive stuff ? It would not do our users any good if we dropped teTeX right now and switched everything to TeXLive (especially Debian developers would be quite angry about the numerous FTBFS bugs, and nonresponsive maintainers who are overworked). They would be justifiably angry if you broke existing tetex build-dependencies; but if TeXLive is indeed a superset of teTeX, there is no reason at all why a switch to TeXLive should *require* breaking existing packages. I also think that teTeX is a long-term alternative (e.g. for people who want a reasonably sized, reasonably recent TeX system without thinking much about details, or for buildds). Sure sounds to me like this could be provided by careful division of the TeXLive contents between binary packages? Becaues of the internal dependencies of a TeX system, it is not trivial to take out the things from TeXLive that are already in teTeX, and only package the rest. Does this also apply to the suggestion of having a core tetex package built from TeXLive sources, plus a shell texlive package depending on it? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [RFC] xulrunner, shlibs, and dependencies.
On Sat, Dec 03, 2005 at 08:58:45AM +0100, Mike Hommey wrote: So my idea is the following : - First, I want to provide the libs with a correct soname. It won't be compatible with upstream until some people use clue sticks, but i'll do my best for them to improve on that point. Having a correct soname will enable us to actually use the shlibs mecanism. - Now, the problem is that we can't really use the sonames correctly, because if we succeed in the clue stick batting, we'll have different sonames, which, in the long term, would be painful. So, I'd like to provide a dummy gecko-x.y-serial or such package, which would correctly depend on the libxul package (with strict version if necessary), and the .shlibs in the libxul-dev package would say to depend on the gecko-x.y-serial package. If you don't want to make up sonames (and I think having debian-specific sonames is fine, personally), I think that having libxul provide a virtual package to use in dependencies is the best option (whether that's gecko-x.y-serial, or libxul1debianX, makes no real difference). Will all the tools resolving the dependencies be fine with a dependency on a virtual package without one an a real package ? (like for zlib1g-dev | libz-dev) Yes. See apt's Provides for an example of this. There are two advantages to managing sonames even when upstream does not: it lets you interface better with un-packaged software (but *only* if that software is built against the Debian version!), and it allows co-installability of different library versions. You need to decide whether these features are important enough for your application to warrant spinning your own sonames. (My guess is no.) My concern is more about what it becomes when we hopefully get upstream to use sonames. Someone suggested me to use specific sonames like libxul.so.d1. Does that really work ? Do shlibs work as well with that ? If this is the case, I think i have my solution... Yes, sonames can be more or less arbitrary strings. You can certainly use sonames with debian in them with a fairly high degree of confidence that upstream won't collide with them. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [RFC] xulrunner, shlibs, and dependencies.
On Sat, Dec 03, 2005 at 10:16:38AM +0100, Mike Hommey wrote: On Sat, Dec 03, 2005 at 12:28:36AM -0800, Steve Langasek [EMAIL PROTECTED] wrote: On Sat, Dec 03, 2005 at 08:58:45AM +0100, Mike Hommey wrote: So my idea is the following : - First, I want to provide the libs with a correct soname. It won't be compatible with upstream until some people use clue sticks, but i'll do my best for them to improve on that point. Having a correct soname will enable us to actually use the shlibs mecanism. - Now, the problem is that we can't really use the sonames correctly, because if we succeed in the clue stick batting, we'll have different sonames, which, in the long term, would be painful. So, I'd like to provide a dummy gecko-x.y-serial or such package, which would correctly depend on the libxul package (with strict version if necessary), and the .shlibs in the libxul-dev package would say to depend on the gecko-x.y-serial package. If you don't want to make up sonames (and I think having debian-specific sonames is fine, personally), I think that having libxul provide a virtual package to use in dependencies is the best option (whether that's gecko-x.y-serial, or libxul1debianX, makes no real difference). Will all the tools resolving the dependencies be fine with a dependency on a virtual package without one an a real package ? (like for zlib1g-dev | libz-dev) Yes. See apt's Provides for an example of this. So why do we keep providing transition packages, then ? What transition packages do you mean? If you mean, why don't we use Provides: instead of transition packages?, the answer is that apt will never automatically replace a real package with a virtual one on upgrades. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: SDL producing bogus dependencies or packages misusing SDL?
On Mon, Dec 05, 2005 at 10:32:00PM -0500, Nathanael Nerode wrote: I wanted to verify this. I've been looking at a number of packages which have picked up dependencies on libartsc0, libasound2, libaudio2, libaudiofile0, libsed0, libjpeg62, libpng12-0, and many others, without actually build-depending on any of the corresponding dev packages. The common factor is that they depend on libsdl-image1.2, libsdl-mixer1.2, and/or libsdl1.2debian. Clearly they're suffering from recursive library dependency disease. The question is this: is this due to some script in the SDL packages? They're complex enough that I couldn't actually tell. The alternative possibility is of course that each of these packages generated the bad recursive list on its own, which is just as likely. I'm wondering where to file the bugs. :-) Try building the package from source, then grep the resulting build tree for references to the libraries in question: both the -lartsc and the libartsc\.(so|la) forms. Then figure out where those references are coming from. If you have a libartsc.la, then the package needs to be relibtoolized (for starters); if you have -lartsc in an auto-generated file, it probably comes from SDL itself; if you have -lartsc hard-coded in the non-auto-generated Makefile (or Makefile.in, Makefile.am...), it's that package's problem. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: StrongARM tactics
On Tue, Dec 06, 2005 at 09:02:23AM +0100, Thomas Viehmann wrote: Kurt Roeckx wrote: twinkle: requeue (probably libccrtp was stuck in NEW) The problem is that libccrtp1-1.3-0 is still linked to libcommoncpp2-1.3c2 instead of libcommoncpp2-1.3c2a. Hm. Sorry. wvstreams: Dep-Wait (libxplc0.3.13-dev) - dep in new queue, see #340696 xchm: retry (needed libchm-dev) This can probably be requeued indeed. But it would help if the maintainer uploaded xchm after libchm was in installed state on all arches, so buildd admins don't have to look at this. Yeah. That would help. But so there's a lot of packages that need attention by buildd-admins. xmms-openspc: arch specific (says maintainer in control) zinc-compiler: arch specific dependency (ghc6) So those should get added to P-a-s instead. Well, but that'd be something for the buildd-admin to collect. (Or maintainers of the packages, but that doesn't seem to fashionable nowadays...) Um... no. This is *porter* work; one does not have to be a buildd admin to analyze a build failure to see whether the package belongs in P-a-s, and there's no reason that the buildd admins alone should bear the responsibility for figuring out whether a permanent build failure should be fixed or ignored. (Maintainers probably need to be involved in this process, but usually maintainers don't have the requisite knowledge about all our ports to make informed decisions on their own.) Saying that's the buildd admin's job about tasks that don't *need* to be done by the buildd admin is a pretty effective way of encouraging the problems that the Vancouver proposal sought to address, where two or three people end up carrying all the ports, and all their time is eaten up by maintaining the buildds and giving back failed packages with no time for following through on the permanent failures (which, even though they sometimes represent a minority of Maybe-Failed packages usually account for a majority of the actual work needing done). weechat: don't know, error on dh-strip on 5 archs, no bug filed That's 2 out of 7 which need actual debugging, both not arm-specific. And only 1/7 where some action of the buildd maintainer is needed at this time to get something build. The dep-wait is well inside the some action of the buildd maintainer is needed. The needed P-a-s entries could be handeled centrally if the problem description is pile of maybe-failed packages. Wonderful. Nice to see that you think P-a-s entries are somebody else's problem that should be handled centrally. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: StrongARM tactics
On Tue, Dec 06, 2005 at 11:03:40AM +0100, Thiemo Seufer wrote: Steve Langasek wrote: [snip] So those should get added to P-a-s instead. Well, but that'd be something for the buildd-admin to collect. (Or maintainers of the packages, but that doesn't seem to fashionable nowadays...) Um... no. This is *porter* work; one does not have to be a buildd admin to analyze a build failure to see whether the package belongs in P-a-s, and there's no reason that the buildd admins alone should bear the responsibility for figuring out whether a permanent build failure should be fixed or ignored. (Maintainers probably need to be involved in this process, but usually maintainers don't have the requisite knowledge about all our ports to make informed decisions on their own.) FWIW, I started to send mips patches for P-a-s, following the procedure outlined at the top of this file. There was neither a response nor any other discernable action. Saying that's the buildd admin's job about tasks that don't *need* to be done by the buildd admin is a pretty effective way of encouraging the problems that the Vancouver proposal sought to address, where two or three people end up carrying all the ports, and all their time is eaten up by maintaining the buildds and giving back failed packages with no time for following through on the permanent failures (which, even though they sometimes represent a minority of Maybe-Failed packages usually account for a majority of the actual work needing done). A while later, and rather by accident, Ryan Murray told me on IRC (paraphrased) Of course they were ignored, you aren't a buildd admin. Send them to me. So I did. Ryan acknowledged to have received them with (again paraphrased) Well, it's not so urgent. This was about 6 weeks ago. Well, a few comments: - Ryan is not himself one of the people listed as contacts for P-a-s; he may consider it best to send such changes through the buildd admins, but that doesn't mean that's the only way for them to be accepted. - I know for a fact that changes *have* been accepted from non-buildd folks (myself included). - Even without it being a policy, there's some truth to the idea that changes are going to be accepted more readily from folks that are trusted to get it right, because there's less need for review on the part of the P-a-s maintainers. And buildd folks are going to be at the top of the list wrt knowing what's going on with P-a-s; but feeding the changes to a very busy buildd admin instead of a very busy P-a-s maintainer isn't an obvious win. :) Much better that the porters show themselves to be competent wrt P-a-s, so that over time their changes *will* be trusted without lengthy delays while someone finds time to review them. - He's right, it's not urgent. :) So don't sweat the delays too much. - I just checked with Adam Conrad on IRC, who was recently added as a third P-a-s maintainer because three busy contacts are better than two. He asks that you please forward your changes to him. weechat: don't know, error on dh-strip on 5 archs, no bug filed That's 2 out of 7 which need actual debugging, both not arm-specific. And only 1/7 where some action of the buildd maintainer is needed at this time to get something build. The dep-wait is well inside the some action of the buildd maintainer is needed. The needed P-a-s entries could be handeled centrally if the problem description is pile of maybe-failed packages. Wonderful. Nice to see that you think P-a-s entries are somebody else's problem that should be handled centrally. It appears to be the idea of the people with write access to P-a-s. Oh, well... appearances *can* be deceiving. Never attribute to malice that which can be adequately explained by people wearing a whole buncha hats. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: StrongARM tactics
On Tue, Dec 06, 2005 at 11:51:00AM +0100, Thomas Viehmann wrote: Um... no. This is *porter* work; one does not have to be a buildd admin to analyze a build failure to see whether the package belongs in P-a-s, and there's no reason that the buildd admins alone should bear the responsibility for figuring out whether a permanent build failure should be fixed or ignored. (Maintainers probably need to be involved in this process, but usually maintainers don't have the requisite knowledge about all our ports to make informed decisions on their own.) Sorry, then I must have misunderstood the nature of the P-a-s file. But then, I always thought of it as a relict that probably should be gotten rid of once one believes that porters and maintainers can sort it out by themselves. It's the file that controls whether wanna-build feeds a given package to the buildds for that architecture, and it's also used in calculating the statistics on how an architecture is keeping up -- so figures directly into whether an arch is a release candidate. As for somebody else: Attached is a patch for the build stuff that I think I have figured out. Ok. Here's some feedback on some that I either disagree with, or don't see enough rationale for. (This is why, ideally, the process should involve the porters and the maintainers...) +dfsbuild: i386 alpha powerpc amd64 # [ANAIS] debian from scratch installer Seems like it should be portable without too much trouble to other architectures, if there was porter interest? -grub2: !hppa !ia64 m68k# bootloader +grub2: !hppa !ia64 !m68k !alpha !mips !mipsel !s390 !sparc # bootloader for i386/powerpc [?] The medium-term goal is for grub2 to be portable to a range of platforms, AIUI; I wouldn't close the door on this yet... +%helix-player: i386 powerpc sparc # [ANAIS] Seems like this is a candidate for porting. +ree: i386 amd64 ia64 kfreebsd-i386 hurd-i386 # reads ROM from /dev/mem, i386/amd64/ia64-specific The description says this package can also extract font data from video card ROMs. Are we certain this is specific to i386/amd64/ia64? +rootskel-gtk: alpha amd64 i386 powerpc sparc # [ANAIS] udeb for graphical debian-installer Just because it's only built for these archs now doesn't mean this has to be true long-term. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: StrongARM tactics
On Tue, Dec 06, 2005 at 05:21:46PM -0800, Blars Blarson wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Um... no. This is *porter* work; one does not have to be a buildd admin to analyze a build failure to see whether the package belongs in P-a-s, and there's no reason that the buildd admins alone should bear the responsibility for figuring out whether a permanent build failure should be fixed or ignored. (Maintainers probably need to be involved in this process, but usually maintainers don't have the requisite knowledge about all our ports to make informed decisions on their own.) I can do the analyzing, but what should I do with the results? [EMAIL PROTECTED] seems to be a black hole. You'll need to find someone willing to communicate with access to the buildd queues before the porters can do anything. I said that deciding which packages should belong in P-a-s is porter work; as is filing bugs on failed packages that shouldn't, providing patches, and doing porter NMUs if necessary. If the porters do this effectively, there's really not much need at all for telling the buildd maintainers about transient build failures, because they'll be pretty obvious (and account for the majority of failures, as it should be). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: StrongARM tactics
On Tue, Dec 06, 2005 at 02:33:34PM +0100, Thiemo Seufer wrote: Steve Langasek wrote: [snip] -grub2: !hppa !ia64 m68k# bootloader +grub2: !hppa !ia64 !m68k !alpha !mips !mipsel !s390 !sparc # bootloader for i386/powerpc [?] Is a P-a-s entry some sort of a final verdict? No, but it's a fairly long-term one; when people are concerned about response time of the folks managing P-a-s, increasing churn certainly isn't advisable, and having a package in P-a-s that shouldn't be has much more of an impact than not having one listed that should be. :) I don't think it makes sense to attempt builds of a package for some years when it is known to fail. (Years might not be true for grub2, an example which comes to mind is gwydion-dylan.) Agreed. I think grub2 is a bit different, because upstream is (AIUI) explicitly working on porting it to other architectures, so it bears checking with the porters first. [snip] +ree: i386 amd64 ia64 kfreebsd-i386 hurd-i386 # reads ROM from /dev/mem, i386/amd64/ia64-specific The description says this package can also extract font data from video card ROMs. Are we certain this is specific to i386/amd64/ia64? At least for mips/mipsel reading /dev/mem with a PC-like hardcoded offset won't yield anything useful. Sure; but the root of this thread is a post talking about arm boards with VGA BIOS emulation, so... :) Again, worth checking with porters on. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: StrongARM tactics
On Wed, Dec 07, 2005 at 04:48:24PM -0600, Bill Allombert wrote: On Tue, Dec 06, 2005 at 01:14:00AM -0800, Steve Langasek wrote: Saying that's the buildd admin's job about tasks that don't *need* to be done by the buildd admin is a pretty effective way of encouraging the problems that the Vancouver proposal sought to address, where two or three people end up carrying all the ports, and all their time is eaten up by maintaining the buildds and giving back failed packages with no time for following through on the permanent failures (which, even though they sometimes represent a minority of Maybe-Failed packages usually account for a majority of the actual work needing done). This go against the two basic rules for a volunteer organisation. 1) Volunteers doing the job should be people interested in doing it. 2) Responsibility should go to people that are going to do the job. Which translates here to: 1) Buildd admin should be people interested in supporting the port. 2) People that are going to support the port must get the responsibility. Which is great as a statement of principle, but it doesn't seem to offer much as a practical recommendation; you don't get to be a buildd maintainer by telling the current folks you aren't taking the right amount of pleasure in this -- better let me do it, you get there by working with the current folks and building a relationship with them and showing that you know what you're doing. Sorry, with a project that's a thousand strong, if they *do* care about the task, not too many people are going to turn it over to someone they don't know without first assuring themselves that they can handle it; and note that I never suggested the current buildd maintainers don't *care* about the ports they're helping with, they just don't have unlimited amounts of time to spend on single-handedly ensuring that ports keep up. BTW, I have no reason to believe that buildd maintenance in general is any more exciting or intrinsically rewarding than filing bugs on failed packages (and providing fixes for the same); so if people are going to balk at the latter task even though this is an area of porting that definitely (in some cases desperately) needs attention, what reason is there to think they're well-suited to being buildd maintainers either? Making buildd admin a purely administrative task while porters are not even trusted to do a binary upload is not going to work because you will never find volunteers accepting to work under theses terms. It seems like you're assuming that buildd admins and porters are two non-overlapping sets. On 6 of 11 architectures, at least one buildd admin is also a porter for that arch under the release requalification guidelines; on 7 of 11 architectures, at least one of the porters has wanna-build access for that arch. So it's certainly not the case that no porters are trusted to do binNMUs. If what you're arguing is that *all* porters should have wanna-build/buildd access (which is the best way to do binNMUs so that we get log files and consistent build envs), then I disagree. There's a heck of a lot of other work that porters would be better off spending their time on -- like, for instance, the unresolved build failures of perl on arm. I mean, it's possible you're right that porters are going to feel slighted if they don't have buildd access; but shouldn't porters' primary motivation be to make sure etch releases with a kick-ass Debian port for their architecture of choice? Should this really be about who holds the keys to the buildds? Isn't being a Debian porter already something to take pride in? If the Vancouver proposal is the constatation that the old model did not work the solution is to change the model, not to expect that people will suddenly accept it. Unless you are just looking at an excuse to remove ports, obviously. Fortunately there are no external organisations forcing the old model upon us, so there is no reason not to change it. All I really see here is that you've asserted that other (unspecified) porters should be given access to buildds that they don't necessarily want or need. Is this the new model you're referring to, or have I missed something? To be honest, it doesn't seem like much of a new model to me, just new people in the same roles. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: StrongARM tactics
On Thu, Dec 08, 2005 at 10:41:51AM +0100, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Aaron M. Ucko) writes: Thomas Viehmann [EMAIL PROTECTED] writes: +pcsx: i386 # i386 assembly AFAICT, this is only because its Linux/Makefile forces CPU to ix86 unconditionally. Write patch. At a minimum the package should be i386 amd64. In general anything with Arch: i386 should add amd64. And is that certain to give a working 64-bit binary on amd64, or are you suggesting that we ship extra copies of 32-bit binaries for both i386 and amd64? Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because: [EMAIL PROTECTED]:~% zcat /mnt/mirror/debian/dists/sid/contrib/source/Sources.gz| grep-dctrl pcsx Package: pcsx Binary: pcsx Version: 1.6df-1 Priority: optional Section: contrib/games Maintainer: Ryan Schultz [EMAIL PROTECTED] Build-Depends: debhelper (= 4.0.0), x11proto-core-dev | x-dev, libgtk2.0-dev, zlib1g-dev | libz-dev Architecture: i386 Standards-Version: 3.6.2 Format: 1.0 Directory: pool/contrib/p/pcsx Files: 972b029160bdc0a1c6316d27280fe7ec 619 pcsx_1.6df-1.dsc c688e5da5ee3aa6a1b2377545d97a4e1 317340 pcsx_1.6df.orig.tar.gz 006f2f71b0dcc24ec2c76821504f03ec 2540 pcsx_1.6df-1.diff.gz wanna-build already filters the Architecture field of sources. No, it does not. It goes to the buildds with every sourceful upload, and fails when sbuild checks the architecture list. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: buildd administration [was Re: StrongARM tactics]
On Thu, Dec 08, 2005 at 11:40:17AM +0100, Josselin Mouette wrote: As a result, no one can help with buildd maintenance as the current buildd admins won't let anyone help them, however overloaded they can be. They refuse to delegate any part of their powers because people aren't skilled enough, How do you know this is true? (Hint: I know it's not.) and people aren't skilled enough because they aren't allowed to help. Er, did you even *read* this thread? We got on the topic of buildds because *someone refused to help diagnose build failures because they consider it the buildd admin's job*. This is a concrete and specific task which needs attention, which doesn't require special access in order to work on, and by means of which developers can demonstrate their trustworthiness to buildd maintainers. Instead, people are telling me this is the buildd maintainer's job, and that no one is going to volunteer to do any porting work unless they are given the keys to the buildds in the process. The buildd maintainers are stopping people from helping? Like, WTF? I started my implication in the project four years ago. For four years, there have been problems with keyring maintenance and buildd administration. What problems are there today with buildd administration, please? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: StrongARM tactics
On Thu, Dec 08, 2005 at 01:52:51PM +0100, Goswin von Brederlow wrote: Steve Langasek [EMAIL PROTECTED] writes: On Thu, Dec 08, 2005 at 10:41:51AM +0100, Goswin von Brederlow wrote: [EMAIL PROTECTED] (Aaron M. Ucko) writes: Thomas Viehmann [EMAIL PROTECTED] writes: +pcsx: i386 # i386 assembly AFAICT, this is only because its Linux/Makefile forces CPU to ix86 unconditionally. Write patch. At a minimum the package should be i386 amd64. In general anything with Arch: i386 should add amd64. And is that certain to give a working 64-bit binary on amd64, or are you suggesting that we ship extra copies of 32-bit binaries for both i386 and amd64? The later if the former is not working. Since we have no multiarch yet and acceptance of patches leading up to it is going very slowly it looks like etch will remain without multiarch. So we need the extra copy to have something working. And for this you want to add hackish patches to console emulator packages? I think the amd64 port can live for a while without a Playstation emulator while we sort out how to cope with cross-installing of i386 packages. Also pcsx should not be in P-A-S (and isn't on cvs.d.o) because: ... wanna-build already filters the Architecture field of sources. Small correction, quinn-diff does the actual filtering (here). No, it does not. It goes to the buildds with every sourceful upload, and fails when sbuild checks the architecture list. Hmm, must be just me then. Here quinn-diff already filters it out so it doesn't reaches wanna-build itself. But that might just be one of the several small differences to the official buildd suite. [EMAIL PROTECTED]:~/t% quinn-diff 21 | grep pcsx [quinn-diff]: ignoring: pcsx has an architecture field of i386 which doesn't include amd64. Right; it is quinn-diff that does the filtering; and the quinn-diff on buildd.d.o does not filter on the package-provided Architecture: list. Makes no sense to include a source not for this arch. On the contrary, I think it's a bad idea for quinn-diff to look at package Architecture: fields directly, just like it would be a bad idea for dak to let maintainers change Section: values directly. You want porter oversight of the list of packages that are being excluded on an arch, and having these show up as build failures gives you that oversight. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Sparc build failure analysis (was Re: StrongARM tactics)
without worrying about the Failed state, yes? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Sparc build failure analysis (was Re: StrongARM tactics)
On Sun, Dec 11, 2005 at 02:38:35PM +0100, Jeroen van Wolffelaar wrote: On Sun, Dec 11, 2005 at 12:35:26AM -0800, Steve Langasek wrote: On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote: FAILED But FAILED is an advisory state anyway; it doesn't directly benefit the port, at all, to have the package listed as Failed, this is just a convenience for folks sifting through the build failures (like the rarely used confirmed BTS tag is for maintainers). In the long-term, one of two things needs to happen with each of these build failures: the package needs to be added to P-a-s so the arch no longer tries to build it, or the package needs to be fixed -- via porter NMU if necessary. So as you have the list of these packages, as a porter you can proceed with figuring out which of the two categories each falls into, and take the necessary action without worrying about the Failed state, yes? Indeed, for practical buildd maintainance purposes, the distinction is not that important -- though 'Failed' is known to not benefit of a requeue, while 'Building:Maybe-Failed' might or might not, it's unkown, most archs should have enough surplus buildd power that retrying everything once in a while doesn't hurt. The major benefit is though to make it apparant for porters what to look into, without all the 'noise' in between of maybe-transient failures. One could also make sure that the FTBFS bugs are tagged (user-tagged) with [EMAIL PROTECTED] (etc) for example (or [EMAIL PROTECTED] There doesn't exist a [EMAIL PROTECTED] for example...), so that one can get a nice overview of all the porting bugs. It'd make sense to synchronise this across all architectures, so that it is consistent. http://lists.debian.org/debian-alpha/2005/12/msg00028.html Our porters can beat up your porters. ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Packages-arch-specific (was: Sparc build failure analysis)
On Sun, Dec 11, 2005 at 08:52:04AM -0800, Russ Allbery wrote: Steve Langasek [EMAIL PROTECTED] writes: On Sat, Dec 10, 2005 at 06:53:47AM -0800, Blars Blarson wrote: Again: what can I do with such a list? See the list below. Changes to the P-a-s list should be sent to the contacts listed at the top of this file (http://buildd.debian.org/quinn-diff/Packages-arch-specific). So I followed the instructions at the top of that file and requested a P-a-s entry, after asking people here what to do. No response. Hm. I wasn't sure what to make of that -- maybe this request is too trivial to bother with, it's fine for the builds to fail, and I should just ignore it? Or maybe my e-mail wasn't received? Or maybe I misunderstood something and this was the wrong channel or the wrong thing to do? Right, well, as noted, it's generally a fairly low priority to get packages added to P-a-s -- even though it's an eventual goal, the waste just really isn't so much (in the usual case) to warrant a rush job. So from that standpoint, as long as there is quite such the backlog on P-a-s that there is (from what I can see), it seems like something maintainers should also give a pretty low priority to. Anyway, you could always try throwing this in Adam's direction as well now that he's listed as a co-maintainer of the file. I waited a while (my saved mail says two months) and asked my AM about it. He said that mailing them again was probably the right thing to do. So I went ahead and did that, providing the specific entry that I think should be used. No response (that was in August). However, I notice in the build report that m68k is now marking openafs as not for us (but the other arches aren't). Is this because of my mail? Because the buildd administrator noticed the error message? That would be noticing the error message... This is a really minor issue in the grand scheme of things. It's not RC, it doesn't break anything, it's really mostly cosmetic plus a minor resource waste. Now I'm feeling kind of guilty about bothering clearly busy people with a trivial request, and I probably really shouldn't send this message to debian-devel either, since certainly it's not any kind of serious problem that this hasn't been done. Eh, well, don't get all guilted up over it. :) Maybe the right thing to do would be to work out a way for package maintainers to provide input to their own P-a-s entries in some sort of automated fashion? It does seem like a package maintainer is generally going to know this sort of thing, and I hate to bother busy buildd maintainers with this kind of thing if I could do it myself. Well, except between the time you wrote this message and the time I'm drafting a reply to it, I've filed/upgraded at least three bugs about packages wrongly limiting themselves to Architecture: i386; and I'm sure there are plenty more out there in the packages I haven't looked at yet. Skills do vary among maintainers, and especially among novice maintainers there's certainly a tendency to mark packages as arch-specific when they shouldn't be. If P-a-s were being updated automatically based on whatever the maintainer thinks should be there, it would've been substantially harder to find these bugs. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: question towards freetype transition; improved library handling needed for all C/C++ packages
On Sun, Dec 11, 2005 at 11:17:51AM -0500, Benjamin Mesing wrote:
today I've tried to address the issue raised by Steve Langasek regarding
inherited dependencies [1].
As I am unexperienced with the whole linking and dependency process I
was not able to deduce the consequences of this announcement for my
packaging.
As far as I have understood the email, whatever is added to the linker
on the command line (using -l...) is also added to the package as a
dependency. Is this correct (the depends line of my package is:
Depends: apt, ${shlibs:Depends}, ${misc:Depends}
)?
I believe my package is affected by the issues stated by Steve,
depending on libraries which I do not directly use. Most of them are
probably pulled in through the QT library I am depending on. My package,
packagesearch, uses qmake as a build tool. The linking command line
contains loads of other libraries including freetype (collected by
qmake).
In this scenario how should I proceed? Steve's hints seem to apply
mostly to library packages, and due to using qmake are not applicable
for me anyways. Should I go with his last hint to use -Wl,--as-needed?
These recommendations are not specific to library packages; they apply
equally well to libraries and applications. You're right that packagesearch
is pulling in lots of dependencies that it doesn't need. I wasn't aware
there were any qmake-specific bugs in this area, but I'll take a look and
see what I can find out. In general, though, qmake seems to suffer from
heavy NIH, so I don't hold out much hope for an easy fix.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: question towards freetype transition; improved library handling needed for all C/C++ packages
On Sun, Dec 11, 2005 at 11:17:51AM -0500, Benjamin Mesing wrote:
today I've tried to address the issue raised by Steve Langasek regarding
inherited dependencies [1].
As I am unexperienced with the whole linking and dependency process I
was not able to deduce the consequences of this announcement for my
packaging.
As far as I have understood the email, whatever is added to the linker
on the command line (using -l...) is also added to the package as a
dependency. Is this correct (the depends line of my package is:
Depends: apt, ${shlibs:Depends}, ${misc:Depends}
)?
I believe my package is affected by the issues stated by Steve,
depending on libraries which I do not directly use. Most of them are
probably pulled in through the QT library I am depending on. My package,
packagesearch, uses qmake as a build tool. The linking command line
contains loads of other libraries including freetype (collected by
qmake).
This bug appears to be specific to the QT4 version of qmake; the QT3 version
doesn't add the extraneous libs to the $(LIBS) variable.
A bug report is probably in order.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: buildd administration
On Sun, Dec 11, 2005 at 03:46:12PM -0800, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: On Sat, Dec 10, 2005 at 03:51:36PM -0800, Thomas Bushnell BSG wrote: Anthony Towns aj@azure.humbug.org.au writes: (a) seeing if the FTBFS can be fixed immediately, and finding it can't (b) documenting (this is the transparent bit, so pay attention) that fact by not having s390 incorrectly listed as a supported arch in the source and ensuring it does not incorrectly indicate a known broken build is successful as it did in the past (c) informing ftpmaster that the build currently in the archive is broken by filing a bug requesting the broken build be removed (you know, communicating with people) (d) downgrading the bug so that it is not incorrectly listed as a RC issue that the RM and QA teams have to attend to (e) as maintainer, work with upstream and porters to fix the downgraded but still open bug we were just talking about I disagree with this. Then you're not maintaining your packages properly, and you're making life more difficult for the rest of the project out of spite. You are incorrect. I disagree with your approach to fixing this particular problem. I think it is better to keep the package out of testing until the problem is resolved one way or the other. You have failed to detail any particular difficulty that this causes, I'm pretty sure I saw him do this already, by noting that it increases the number of packages that the release and QA teams have to keep track of. It's great that you're concerned about the portability of the package, but there are 500+ open RC bugs known to be relevant to the next release, and 1300+ RC bugs all up that affect packages in unstable. Packages with bugs in the first category add to the release team's workload of downgrading bugs/NMUing/pestering maintainers/removing packages; packages with bugs in the second category add to the QA team's workload of figuring out if maintainers are MIA, whether packages should be removed from the archive, and so on. Bugs in both categories make it harder for would-be bugsquashers to sift through the bug lists to find packages that they can usefully NMU. Also, after a certain point 1300 RC bugs * n binary packages per source package * 12 architectures starts to look kinda wasteful on the mirrors. There are 9450 source packages in unstable/main today; assuming (optimistically?) that half of these RC bugs map uniquely to source packages that we should consider removing, that's still about 6% mirror overhead from packages we should be getting rid of, and as much as another 6% of packages that complicate the process of figuring out which 6% ought to go... nor have you given any reason why the package should be added to testing in advance of my judgment that it's ready, nor have you given any explanation of why you think it's ready now. If we suddenly decided to release etch next month, what would you do with this package -- keep the RC bug open because you think s390 support is more important, or ask for the removal of the old s390 binaries because the package is worth something to users of other architectures? How long is it reasonable to postpone taking this action, then, knowing that such bugs clutter the various tracking lists to the point of making them unusable for some purposes today? How long is it reasonable if 50 maintainers are sitting on bugs like this? If 100 maintainers are? You have not pointed at any documentation of maintainer policies that indicates that one must clear an RC bug as soon as possible, for unreleased packages, to push them into testing before the maintainer thinks they are ready. Rather, it seems much more likely that we would want to push such packages *out* of unstable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
On Sat, Dec 17, 2005 at 06:09:05PM -0600, Peter Samuelson wrote: [Thomas Hood] After installation you should have a tmpfs mounted on /run. This has been created for the use of that handful of packages that need a place to store run time state files independently of networking. Given the need, and now the reality, of /run, is there any need for a separate /var/run? I vote we migrate to /var/run - /run, at least in the default install. Whether packages should continue to refer to /var/run is a matter of FHS touchy feely, and perhaps compatibility with other FHS distributions is more important than the ability to eliminate the /var/run symlink in the long run. Given the reality of /lib, is there any need for a separate /usr/lib? The principle is the same: /lib is used only for the minimal system required for booting, and everything else should go in /usr/lib. /run should be used only for junk that needs to be stored early in the boot sequence, and everything else should go in /var/run. We should *not* be moving all of /var/run into /run; symlinking the former to the latter should be left as a touchy feely exercise for the local admin. (We also shouldn't need to specify a policy for mounting any particular filesystem on /run, but merely mount /run early iff it's present in /etc/fstab and leave the implementation details to the local admin.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
On Sun, Dec 18, 2005 at 03:57:35AM +, Matthew Garrett wrote: Steve Langasek [EMAIL PROTECTED] wrote: The principle is the same: /lib is used only for the minimal system required for booting, and everything else should go in /usr/lib. /run should be used only for junk that needs to be stored early in the boot sequence, and everything else should go in /var/run. Under Linux, can't all of this be done with mount --move anyway? I'm not convinced that we actually need a /run any more. So you would have these files stored in /var/run from the beginning, and use mount --move to shuffle them around if /var is a separate mount point? I'm pretty sure --move is a 2.6-only feature, too, and we haven't yet gotten rid of 2.4 for etch; and is there an equivalent solution for non-Linux ports? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
On Sun, Dec 18, 2005 at 04:50:33AM +, Matthew Garrett wrote: Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 03:57:35AM +, Matthew Garrett wrote: Under Linux, can't all of this be done with mount --move anyway? I'm not convinced that we actually need a /run any more. So you would have these files stored in /var/run from the beginning, and use mount --move to shuffle them around if /var is a separate mount point? I'm pretty sure --move is a 2.6-only feature, too, and we haven't yet gotten rid of 2.4 for etch; and is there an equivalent solution for non-Linux ports? Yeah, it's 2.6 only. Are we seriously expecting to ship etch with 2.4 kernels? Is anyone still doing active security support for it? I'm eager to be able to drop 2.4 for etch, but I don't think it's completely clear yet whether the hardware support in 2.6 will be broad enough to meet users' needs. I expect we'll need to work with porters over the next months to begin pruning architectures from the 2.4 tree, and evaluate what's left at the end. Yes, lack of active security support for 2.4 is a concern. Also, bear in mind that even if 2.4 isn't shipped with etch, we still have to provide an upgrade path for users of sarge, so some thought would need to go into what that would look like. The linux-onlyness of it is a bit more awkward, but non-Linux OSs tend to be lacking things like decent ram filesystems anyway, so the semantics are going to vary in any case. But I guess if it's difficult, sticking with /run might be easier. Has anyone talked to the FHS guys about this? (I haven't actually checked whether it's in there, so the answer may well be yes :) ) I'm not sure if anyone has talked to the FHS folks lately about this, no. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Debian Installer team monthly meeting minutes (20051214 meeting)
On Sun, Dec 18, 2005 at 04:14:19PM +0100, Frans Pop wrote: On Sunday 18 December 2005 15:34, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: I hope this will be solved soon! use nameif. This has been suggested before but AIUI nameif has problems/limitations renaming eth0. The correct solution seems to be to use udev rewriting rules to make sure interfaces keep their name. We will work on implementing this in Debian Installer before the next beta release. Both Ubuntu and Marco d'Itri have offered to help with that. For existing users we should make sure this issue will be documented in the Release Notes for Etch. I'm filing a bug against release-notes as a reminder. Is there some reason we should be unable to provide a smooth upgrade path for users of sarge? Having your network devices scramble themselves on reboot is a Big Deal, whether or not it's in the release notes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Debian Installer team monthly meeting minutes (20051214 meeting)
On Mon, Dec 19, 2005 at 09:13:01AM +0100, Marco d'Itri wrote: On Dec 19, Steve Langasek [EMAIL PROTECTED] wrote: Is there some reason we should be unable to provide a smooth upgrade path for users of sarge? Having your network devices scramble themselves on reboot is a Big Deal, whether or not it's in the release notes. This often happens anyway when switching between 2.4 and 2.6 kernels, so it's something users have always needed to be aware about. How wonderful then that udev now gives us the opportunity to make upgrades completely seamless for users of 2.4 *and* 2.6 kernels! Indeed, if that's the case, why should we settle for anything less? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
On Sun, Dec 18, 2005 at 01:26:45PM +0100, [EMAIL PROTECTED] wrote: Steve Langasek wrote: (We also shouldn't need to specify a policy for mounting any particular filesystem on /run, but merely mount /run early iff it's present in /etc/fstab and leave the implementation details to the local admin.) I think that packages Depending on initscripts = 2.86.ds1-7 should be entitled to assume that /run/* is a writable location available very early after boot. Yes, they should. Initscripts 2.86.ds1-7 includes /run and mountvirtfs mounts a tmpfs on it, thus causing this assumption to be true. If the local admin wants something else then he or she can edit the script in such a way that the aforementioned assumption remains true. No, having to edit init scripts sucks. So does having mounts that aren't controlled via /etc/fstab. Are there really any init scripts that need to write out data prior to checkroot.sh (the point at which /run would be writeable by default on the rootfs)? If not, why can't we mount /run using /etc/fstab as part of checkroot.sh, and leave the details to the admin? This optimizes for the common case, and leaves the way open for solutions to uncommon requirements. If there is demand for an alternative standard operation mode that satisfies the assumption then that can be implemented, of course, but offhand I can't think of why anyone would need anything but the default configuration. The two use cases that were raised when /run was first discussed were: - NFS-mounted /var filesystem - read-only / filesystem Having a /run directory for early-boot volatile data addresses the needs of both of these use cases (even simultaneously -- hurray!), but by constraining the actual *implementation* of /run (barring ugly hacking of the init scripts), you've made the system less suitable for a third use case: - memory is at a premium, disk is not I'm not going to claim that I know of any particular users that are affected by this change; files that are candidates for /run (or /lib/run) are typically small enough that it's fairly unlikely for this alone to impact what they can or can't do with Debian. But that's also not the point: the point is that design-wise, there's simply no reason to make the choice for the user of *what* is mounted on /run, only to specify that *something* must be (and that it must be writable); given that the existing default is perfectly suitable for the majority of users, I believe we're better off not touching it. If you really want to be clever though about supporting upgrades for users that may already have read-only root, I guess you could do something like this: if grep -q '[[:space:]]/run' /etc/fstab; then mount $options /run elif grep -q '[[:space:]]/[[:space:]].*\bro\b' /etc/fstab; then mount $options -t tmpfs tmpfs /run fi And then everyone can be happy. :) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
On Sat, Dec 17, 2005 at 10:13:35PM -0600, Peter Samuelson wrote: [Steve Langasek] Given the reality of /lib, is there any need for a separate /usr/lib? The principle is the same: /lib is used only for the minimal system required for booting, and everything else should go in /usr/lib. /run should be used only for junk that needs to be stored early in the boot sequence, and everything else should go in /var/run. /var/run is *tiny*. In fact on my system it's close to 4 orders of magnitude smaller than /usr/lib. I know why /usr isn't assumed to be on the root filesystem, and it's not at all related to why a /run ramfs that has to exist anyway might be inappropriate for /var/run. On the contrary; on some of my systems, I have at least /var/run/samba and /var/run/screen, which aren't guaranteed to stay small at all. On one particular samba fileserver I checked, /var/run is less than two orders of magnitude smaller than /usr/lib. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: /run vs /var/run (was: Please test new sysvinit)
On Mon, Dec 19, 2005 at 12:23:00PM +0100, Thomas Hood wrote: Steve Langasek wrote: Are there really any init scripts that need to write out data prior to checkroot.sh (the point at which /run would be writeable by default on the rootfs)? Well, it would be nice if fsck logs could be stored in /run until /var/log/ is available for writing. It would be nice if mtab could be kept in /run so that it could be written to as filesystems are being mounted. Currently these sorts of things are delayed using one trick or another. Ok, that's fair. by constraining the actual *implementation* of /run (barring ugly hacking of the init scripts), you've made the system less suitable for a third use case: - memory is at a premium, disk is not Tmpfs memory can be swapped out, so is this even a hypothetical problem? Maybe it isn't on Linux. I wasn't aware tmpfs could be swapped out. That still leaves the question of just which features we want to require from our non-Linux kernels for basic operation, I guess. [...] the point is that design-wise, there's simply no reason to make the choice for the user of *what* is mounted on /run, only to specify that *something* must be (and that it must be writable); One advantage to supporting only tmpfs on /run is that the assumption can then be made that the hierarchy is empty at boot; there are no stale files and no cleaning has to be done. Seems to me that we have a handle on the process of cleaning directories by now though, no? :) If there are reasons why some users would not want to put a tmpfs at /run (which there may well be, although I haven't heard them yet) then we can of course support this. Then either initscripts will have to clean the directory or programs using it will have to contend with stale files. Cleaning cannot occur until the filesystem underlying /run is mounted read-write and programs must not use /run before the cleaning has been completed; it would probably be easier to drop the cleanliness-at-boot guarantee and let programs clean out their own stale files. Sounds to me like this will play havoc with idempotence of init scripts; anyway, why would mount /run and clean it be anything less than an atomic operation from the viewpoint of other init scripts? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Thoughts on Debian quality, including automated testing
On Wed, Dec 21, 2005 at 02:07:30AM +0200, Lars Wirzenius wrote: Several ideas have been floating around for years on how to improve this situation, of which I'd like to mention three. While I've here used the number of bugs as the measure of a package's quality, the same ideas might help with other aspects, like getting new upstream versions packaged soon after they're released. * Team maintenance. If a package is maintained by a team, there are more people sharing the work. When a team works well, more people look at the package, and finding and fixing problems is more effective. There is less work per person, so things don't lag as much. A well-working team is a good thing. As an example, the Debian GNOME team seems to work really well. Transitions to the next upstream version happen quite smoothly these days. OTOH, sometimes team maintenance means no one takes responsibility for the package. I've dealt with release critical bugs on packages where the Maintainer field pointed to a team mailing list, there were several Uploaders listed for the package, and the bug sat unattended for well over a month for no apparent reason. I've also *been* part of maintainer teams where all the members of the team were busy people, and bugs tended to linger because they were somebody else's problem. Anyway, I agree that team maintenance can be a force for good. I also agree with the rest of your mail, including the call for a more proactive QA team. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: kernel-package hooks transition
On Sun, Dec 25, 2005 at 03:34:43PM +, Colin Watson wrote: On Sun, Dec 25, 2005 at 01:51:00AM +0100, Sven Luther wrote: On Sat, Dec 24, 2005 at 05:30:26PM +, Colin Watson wrote: On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote: Notice that the debconf helper scripts provide stdout on 3, so any scripts writing to stdout only need to redirect their output to 3, no My impression is that these days maintainer scripts are much better about not mixing up debconf interaction with normal use of stdout, and so it's still possible that the fd 3 hack will be removed some day. Ok, now i read it all, shouldn't really be replying to email after the christmas party ... :) Likewise, on Christmas Day I haven't really looked at this issue in any depth. :-) So, do you have any idea of what is going wrong here and how to fix it ? I mean having hosed powerpc kernels over christmas is really not the nicest thing to have happen, and i really don't understand the subtleties of what is going on here. k-p uses debconf (probably using the perl helpers you mentioned), and does a db_stop before calling the script hooks. The STOP command causes the debconf frontend to shut down; that would certainly break anything trying to talk to debconf after it. May be worth removing that and seeing if things start working. I haven't checked if kernel-package runs anything else that would require it to use STOP. It seems a little unlikely that it would be starting up any daemons, though. Note a common misconception: the STOP command does *not* put your file descriptors back the way they were before you started the debconf frontend. Indeed, not only does STOP not restore your file descriptors, it also leaves a sentinel value in the environment which prevents debconf-using children from successfully restarting the frontend. STOP should only be used when you need to force-kill the frontend because of other processes that will otherwise leave dangling file descriptors open to it after your scripts exit. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Your Confirmation Required
On Tue, Dec 27, 2005 at 05:35:33PM +0100, Simon Richter wrote: Wouter Verhelst wrote: What's the chance of someone owning a domain with the intended use of sending out Islamic preaches in eight different languages would be interested in subscribing to -devel with an email address in that domain? Yet the proper response may be to tell them that someone has been abusing their service and that it may be in their interest to implement something so that it can be detected who did it. I've actually already had one conversation with them about the fact that their site was allowing subscriptions without confirmation. Now the site requires confirmations, and someone's apparently still confirming the damn things. It's been suggested that this may be happening wholly automatically through link spiders, though, which I hadn't thought of initially; so yeah, it'd be good to either have abuse headers to track, or (probably easier) just blacklist the domain... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
bug tracking for non-RC architectures
Hi folks, For architectures that are not release candidates, we are going to need another way to track release critical bugs. The whole point of having architecture criteria is so the project can give higher priority to issues affecting release architectures (or all architectures) than to issues that are specific to an architecture that isn't meeting our standards for releasability; and we're not doing that very effectively if we leave such architecture-specific bugs at RC severity. OTOH, we don't want to lose sight of them by just downgrading the severities, as this would make it awkward to reintroduce the architecture as a release candidate without also silently reintroducing RC bugs. Usertags to the rescue! I've gone through the current list of release critical bugs at http://bugs.debian.org/release-critical/debian/all.html, identified the bugs that I believe are specific to one or more of arm, m68k, s390, and sparc, and have downgraded/usertagged them. The results for all archs can be seen here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag[EMAIL PROTECTED]tag=rc-arm,rc-m68k,rc-s390,rc-sparcnam0=Statuspri0=pending:pending,forwarded,pending-fixed,fixed,donettl0=Outstanding,Forwarded,Pending%20Upload,Fixed%20in%20NMU,Resolvednam1=Architecturepri1=tag:rc-arm,rc-m68k,rc-s390,rc-sparcttl1=arm,m68k,s390,sparcord1=0,1,2,3 Per-architecture views are also available: http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag[EMAIL PROTECTED]tag=rc-arm http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag[EMAIL PROTECTED]tag=rc-m68k http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag[EMAIL PROTECTED]tag=rc-s390 http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag[EMAIL PROTECTED]tag=rc-sparc This gives us convenient access to the bug lists relevant to each architecture, so that they can be upgraded again if/when the architecture meets the release criteria. I strongly encourage you to use this same usertag convention (rc-$arch usertag, under user debian-release@lists.debian.org) when filing new bugs about breakage specific to your architecture. Please refer to Anthony Towns' announcement[0] if you have questions about the use of usertags. Oh, and this also gives porters a handy list of bugs affecting their architecture that they can be working on in between getting things back in line with the release arch standards. As always, porter NMUs are encouraged -- you don't need an RC bug as an excuse to fix a package for your architecture! Wouldn't it be great to have zero bugs on that page two months from now? :) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ [0] http://lists.debian.org/debian-devel-announce/2005/09/msg2.html signature.asc Description: Digital signature
Re: stable aliases for CD drives
On Thu, Dec 29, 2005 at 01:00:40AM +0100, Marco d'Itri wrote: As you can see, %e will go away soon so /etc/udev/cd-aliases.rules will not be supported anymore. Some component of debian will have to install a rules file with static aliases, and so far I think that this should be a task for d-i. Comments and other ideas are welcome. What will provide this for systems upgraded from sarge? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: stable aliases for CD drives
On Fri, Dec 30, 2005 at 11:48:56AM +0100, Adrian von Bidder wrote: Network interfaces may be renamed after sarge to etch upgrades is acceptable. Network interfaces may completely lose any stable naming and may be randomly named after every reboot after sarge to etch upgrades unless you manually install some additional software is not. Given the sort of solution that needs to be implemented here to address the second, I don't see any reason why the first should be acceptable either. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Experiment: poll on switching to vim-tiny for standard vi?
On Mon, Jan 02, 2006 at 11:47:05AM -0600, Steve Greenland wrote: On 23-Dec-05, 11:54 (CST), Anthony Towns aj@azure.humbug.org.au wrote: The size of base matters a little, but it's not an every byte is sacred situation. Cheers, aj (base maintainer, for those playing along at home) So, it seems that so far as Stefano (vim maintainer) and I (nvi maintainer) are concerned, you and Joey get to make the call on this. Since Joey initiated this thread, I think we can assume he's in favor of the change. How say you? If you agree with the change, do Stefano and I need to do anything other than swap vi alternative priorities and swap important-optional priorities? Why swap the vi alternative priorities? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: How to Increase Contributions from Volunteers
On Mon, Jan 02, 2006 at 10:29:30PM +0800, Enrico Zini wrote: On Mon, Jan 02, 2006 at 02:53:52PM +0200, Linas Zvirblis wrote: A hypothetical example: I decide to found a debian-geology team and I am not a Debian Developer. So what now? Should I help debian-med to become a DD? But I am not interested in medicine, I am interested in geology. 1) Open a geology project on Alioth and do some work. 2) Ask for someone to sponsor package uploads. Hmm, I would actually hope that the Alioth admins would reject an application from a non-DD in step 1) for a project that hasn't already had step 2) happen. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Experiment: poll on switching to vim-tiny for standard vi?
On Tue, Jan 03, 2006 at 08:58:49AM -0600, Steve Greenland wrote: On 03-Jan-06, 00:46 (CST), Steve Langasek [EMAIL PROTECTED] wrote: On Mon, Jan 02, 2006 at 11:47:05AM -0600, Steve Greenland wrote: If you agree with the change, do Stefano and I need to do anything other than swap vi alternative priorities and swap important-optional priorities? Why swap the vi alternative priorities? Because if vim is the default, and someone deliberately installs nvi, the presumption is that they prefer nvi, and thus it should grab the vi link. I think that's a pretty bad presumption; to me, it indicates that *someone* on the system prefers nvi and has requested its installation, but this doesn't mean it's the preference of either the system administrator or of the majority of the users. Such behaviour is pretty much standard alternative handling: the default install is the lowest priority, and the optional variants have higher priorities. For a single user system, this makes sense. For a multi-user system, where the admin might want all of (vim, nvi, vile, whatever) as options for the user, it's easy to pick whichever one you want for the default. OTOH, the admin may not understand the alternatives system, or recognize its relevance at the time of installing the package (worst case, some other package pulls it in automatically), which makes for an inconsistent user experience. I think the single-user system is the last one that alternatives handling should optimize for, since the *one* person who's going to know to type nvi instead of vi, and the one person who can fix the alternatives if he doesn't like them, is the admin... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: bits from the release team
On Tue, Jan 03, 2006 at 11:27:25PM +0100, Sven Luther wrote: On Tue, Jan 03, 2006 at 11:01:03PM +0100, Frans Pop wrote: (forgot to CC d-kernel on this) On Tuesday 03 January 2006 22:02, Sven Luther wrote: We will have a kernel which is outdated by two versions at release time with this plan, since there are about 1 kernel upstream release every 2 month. 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just starting to get implemented). I remember we did consider using 2.6.10 instead of 2.6.8 and decided not to mainly because it was not really that much better than 2.6.8. As I remember it, this was a joint decision by the kernel team, release managers and the d-i developers. Not something that the kernel team were really pushing and was blocked by some assholes from the d-i team who did not want to cooperate. Well, i remember joeyh vetoing it because it would take at least a month to get the change done, and i believe we didn't really push for it because the infrastructure was a mess back then. This has changed. The one point that put me up, is that we should have gotten that security update in, but this was also vetoed for the same month-long delay in the kernel/d-i upgrade process. The kernel team has reduced that delay to less than 24hours now for the release arches, You have been harranguing the ftp team to approve new upstream kernels through the NEW queue before they've even been uploaded -- for an amazing false optimization that burns good will with your fellow developers. Even if udebs *were* being built from the same linux-2.6 source package, this doesn't address the real reason why it's important to freeze the kernel early: *the kernel is a core component of everyone's system and detecting regressions takes a long time*. Anything that requires a reboot cycle or an installation test in order for users to detect bugs is going to need a longer testing period than other packages; the only way to ensure this happens is by freezing it early, i.e., around the same time as the toolchain packages for which we have the same problem of figuring out whether a new version is better or worse. The underlying assumption in your plea for a shorter kernel freeze is newer is better. But people who accept this assumption unconditionally don't *run* Debian stable; so neither should we base our freeze timeline on an unconditional acceptance of it. Newer isn't necessarily better, but it is necessarily *different*, which is the enemy of stability. There is still room for targetted fixes to the kernel after the freeze date; backports of new drivers, or backports of specific bugfixes, are certainly fair game. Taking a new version of whatever upstream happens to have released would not be. My believe is that this kind of thing should be as much automated as possible, to let the few ressource we have be used where best it should, a little work at the start which will pay off forever after, this is what computers and programming is for, to make the task of the users and programmers easier, i think we all agree with that, or we would still be using boot-floppies :) I'm all in favor of streamlining the integration of new kernel versions into the installer, but I don't believe that the majority of the work involved falls into the automatable category. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) wrote: 1. http://lkml.org/lkml/2005/12/3/55 Perhaps the idea of maintain a kernel with other distros is not bad, if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, Xandros, DCC Alliance Fan Club and also other Debian Derivatives. I really don't know if it is possible to mix RH, Debian, SuSE, Slackware and other distros to maintain the same kernel, but certainly should be possible to get all Debian (and Debian based/derivative) playing together. :-) The biggest obstacle to this is that different distributions have different and contradictory requirements for what ships in the kernel. For Debian, the obvious requirement is that everything we ship in main meets the DFSG; this is a requirement that is not shared by Ubuntu, for instance, which means any collaboration on kernels between those two distros has to allow for different bits being stripped out at the time of source package generation. It would certainly be nice to see improvements in kernel collaboration, and I believe it is possible, we just have to be honest with ourselves about the difficulties involved. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?
On Wed, Jan 04, 2006 at 01:22:57PM -0500, Benjamin Mesing wrote: So please disregard my statement against testing (In this case, xterm could have had a conflict with your package to avoid screwing users over unnoticed; and we could (in future) have added a note to the testing scripts to not allow upgrades of xterm until a fixed version of packagesearch is also included) It turned out that what I thought to be a deliberate change of how arguments are handled in xterm was actually considered to be a bug, and reported to the BTS [1]. Though xterm made the migration to testing, because the bug was only of severity normal. So it is nothing wrong with the testing mechanism, but more likely a wrongly set severity of the bug. But here is what I started with: the features in packagesearch relying on xterm were broken in testing once the version entered it. I was able to work around this bug in unstable as soon as I realized it, but the migration of the fixed package to testing was delayed due to the QT library transition. This same Qt library transition would have prevented some number of users of unstable from installing a fixed version of packagesearch during that same period. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr
On Wed, Jan 04, 2006 at 10:43:57PM -0200, Henrique de Moraes Holschuh wrote: On Wed, 04 Jan 2006, Peter Samuelson wrote: [Peter Eisentraut] What do you think about this request? It seems reasonable, but I [...] This issue was mentioned in the /run discussion we just had on this list. I'm in favor of forcing all init scripts to mkdir -p initscripts co-maintainer hat on Do it. We are *heavly* considering support for ephemeral /var/run (which is orthogonal to /run or anything else in that topic), so you might as well do it now and make your user happy. A lot of other packages already support ephemeral /var/run. BUT, if you do, don't ship /var/run inside the deb. Why? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: APT public key updates?
On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote: [Michael Vogt] Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Sounds good. Will this automatically take care of the key update and make sure no manual intervention is needed to get packages upgraded? Isn't Ubuntu using the signed apt stuff? How are they handling the new archive keys? AIUI, Ubuntu isn't rotating their archive keys -- something else that their centralized model more readily affords them. I think they still have the same problem we do regarding how to cope with a key compromise revocation, though. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: APT public key updates?
On Thu, Jan 05, 2006 at 04:43:13PM -0800, Thomas Bushnell BSG wrote: Steve Langasek [EMAIL PROTECTED] writes: AIUI, Ubuntu isn't rotating their archive keys -- something else that their centralized model more readily affords them. I'm a little confused about why we do rotate the keys. I'm not experienced in thinking through the subtle issues concerned, so I'm trying to learn, because I know that Debian has plenty of people who *do* have this experience, and I want to learn/understand. With a non-expiring key, there is the risk that the key will be compromised. However, with the expiring key, there is the risk that a fake key will be generated at the expected roll-over time. In other words, I needed to fetch the new key this week, from the web site, and tell my system yeah, that's the right key. Of course, the new key is signed with the old key. It's also signed with some sigs that I haven't checked, which I assume are the Debian ftpmasters. However, nothing about the apt-key procedure actually seems to have *checked* any of these signatures. There are four main attack vectors that I can see: - compromise of the user's local network connection - compromise of the user's local mirror - compromise of the PGP key, together with one of the preceding - compromise of ftp-master itself In the fourth case, either the compromise is detected by the admins, or it isn't. If it isn't, all bets are off: we can only ever have cryptographic assurance that the packages came from ftp-master, not that the packages that came from ftp-master are *good*, so we focus instead on prevention and detection of compromises instead and eliminate this case from consideration. If the compromise *is* detected by the admins, the key is revoked, the server is re-secured, and a new key is issued. So we know that our system has to deal with key revocations: providing means of both broadcasting the key revocation as widely as possible to users, and delivering a replacement key to those same users as securely as possible. In the third case, again the compromise is either detected, or it isn't. If it's detected, we're revoking the key again; if it's *not* detected (and it seems to me that anyone able to compromise the pgp key without also having to compromise ftp-master is likely good enough to go undetected), then this is a case where scheduled key rotations help us. It also shouldn't *hurt* us, since we need to have a sound process in place for dealing with key replacements regardless due to the possibility of compromise. The first two cases provide us with a rationale for wanting cryptographic assurances in the first place, and insight into what that assurance ought to look like. For a user with a compromised local mirror, just having the new key available to grab from http://ftp-master.debian.org is sufficient. (If it isn't, the user falls into one of the other categories.) For a user with a compromised local network, the only safe solution is to validate the new key via some web of trust. This is the feature that's missing today, to give Joe User some reasonable method of checking keys against the web of trust before importing them. Perhaps then we need to improve apt-key to implement a more careful model? Yes, I think so. I'm not sure that apt-key itself is what should be doing the checking, or if we should be giving users some sort of recipe for pre-verifying keys using gpg? $ gpg --recv-keys 2D230C5F gpg --update-trustdb \ gpg --batch --edit-key 2D230C5F quit 21 | grep -q 'validity: full' \ gpg --armor --export 2D230C5F | sudo apt-key add - If the key is compromised, which is the only way the non-expiring key method can be broken, then the expiring key doesn't seem to be offering all that much additional security. Indeed it doesn't. Ideally, if the previous key has been compromised, users would be verifying the integrity of the new key using other signatures; but in the worst case, verifying using the signature from the previous key (if they're disconnected from the web of trust) is no worse than not being able to verify it at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr
On Thu, Jan 05, 2006 at 09:07:58AM -0200, Henrique de Moraes Holschuh wrote: On Wed, 04 Jan 2006, Steve Langasek wrote: On Wed, Jan 04, 2006 at 10:43:57PM -0200, Henrique de Moraes Holschuh wrote: initscripts co-maintainer hat on Do it. We are *heavly* considering support for ephemeral /var/run (which is orthogonal to /run or anything else in that topic), so you might as well do it now and make your user happy. A lot of other packages already support ephemeral /var/run. BUT, if you do, don't ship /var/run inside the deb. Why? Because: 1. It will go away on reboot and if your service isn't enabled, it won't be re-created. dpkg will still think it should be there, however. And what does that break? AFAIK, dpkg will ignore a missing directory on package removal without incident. 2. We may deploy some auto-create-stuff-in-/var/run solution, and it WILL clash with packages that ship /var/run and recreate it (not that I'd expect that clash to do anything other than mkdir -p be a waste of time -- but better safe than sorry). The /var/run directory itself *must* always exist; it has to be on the filesystem which holds /var. Also, it makes life easier for us to track down packages that need to be examined for lack of ephemeral /var/run support. I think you're going to need a more reliable test than this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: APT public key updates?
On Thu, Jan 05, 2006 at 11:15:08PM -0800, Thomas Bushnell BSG wrote: If the key is compromised, which is the only way the non-expiring key method can be broken, then the expiring key doesn't seem to be offering all that much additional security. Indeed it doesn't. Ideally, if the previous key has been compromised, users would be verifying the integrity of the new key using other signatures; but in the worst case, verifying using the signature from the previous key (if they're disconnected from the web of trust) is no worse than not being able to verify it at all. I think I now understand better, and I can better express the uncertainty I was groping at. A key is only as good as the keys that sign it. The reason for rotating the key is that there is some non-zero risk that it will be compromised, and this limits exposure. But in order to validate the new key, which is only as good as its signatures, I must rely on whatever signs the new key. I trust AJ. So I trust AJ to sign the new key correctly. Surely, it seems to me, the risk of AJ allowing his own key to be compromised is just about the same as the risk of his allowing the archive key to be compromised. What am I missing? The exposure of the archive key is higher, because it sits on an Internet-connected, ssh-accessible server. Also, you don't have to trust AJ's key; in contrast with Florian's assessment of the NM-suitability of the three ftpmasters, one ftp assistant, and one RM who have signed this key so far :), I would encourage you to log into merkel and verify, directly and securely, the key at /org/ftp.debian.org/web/ziyi_key_2006.asc; sign it; and upload your signature to the public keyservers as well, if you are satisfied that this is the key that is being used on ftp-master.debian.org to sign the archive. You should *only* do this if you're satisfied that the presence of this file in the mirror on merkel is adequate evidence that it's the same key in use on ftp-master. So trusting that the ssh host key of merkel is authentic, trusting that someone hasn't compromised both merkel and your network (pushing matching, invalid keys to you via merkel and a MITM of http://ftp-master.debian.org), and trusting that the propagation from ftp-master to merkel is secure. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr
On Fri, Jan 06, 2006 at 09:44:35AM -0200, Henrique de Moraes Holschuh wrote: On Thu, 05 Jan 2006, Steve Langasek wrote: BUT, if you do, don't ship /var/run inside the deb. Why? Because: 1. It will go away on reboot and if your service isn't enabled, it won't be re-created. dpkg will still think it should be there, however. And what does that break? AFAIK, dpkg will ignore a missing directory on package removal without incident. Well, it is not good form. If you want to ship it there, be my guest. But don't expect me to tell others to ship it _unless_ there is a real reason to do so, and so far there isn't (there might be one in the future). That's fine; I'm just saying that there's not much point in telling people to *not* ship /var/run (or subdirectories thereof) in their package. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: APT public key updates?
On Fri, Jan 06, 2006 at 02:04:49PM +0100, Florian Weimer wrote: * Steve Langasek: I would encourage you to log into merkel and verify, directly and securely, the key at /org/ftp.debian.org/web/ziyi_key_2006.asc; sign it; and upload your signature to the public keyservers as well, if you are satisfied that this is the key that is being used on ftp-master.debian.org to sign the archive. Or publish a statement, maybe signed with your OpenPGP key, that the key 1024D/2D230C5F, fingerprint 084750FC01A6D388A643D869010908312D230C5F is the 2006 Debian archive key. This conveys more information than a certifying signature, and avoids the problem how you got physical ID for Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED], or a verification that the keyholder actually reads the mailbox mentioned in the user ID. 8-) Yes, that's also reasonable, although the downside is a lack of good distribution channel for such a signed statement -- key signatures you can throw at any keyserver and they'll stick. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Advices, comments? Bug#345651: passwd package should be essential?
On Fri, Jan 06, 2006 at 06:38:47PM +0100, Christian Perrier wrote: I tend to agree with Kurt opinions below and thus, I'm tempted to make passwd Essential: yes. The opinions in the shadow package maintenance team slightly vary. However, given that this is an important decision, I think it is a good idea to get the advice of fellow developers. So, please comment It's not just a good idea, it's the Policy (3.8). For my part, I think this sounds like a bad idea. We should be very sparing in our use of the Essential: yes flag; I think we really should not be using it *except* for packages that we require to be functional when in an unconfigured state. The passwd package certainly doesn't qualify in this regard. Making the package Essential just to cover other packages' failure to depend on it while it was virtually-essential also seems dodgy; btw, it wasn't virtually-essential in woody, so packages really shouldn't have had a chance to get too buggily accustomed to having it around. So why do I think passwd needs to be essential? There are several things in the package that one might want to run from one of the maintainer scripts from debconf, like useradd, groupadd, userdel, ... First, I can't see any reason why you would want to call these commands from a *config* script; that smells of abuse to me. Second, assuming there is a reason to ever call one of these commands from the debconf script, standard procedure for any non-essential .config dependency is to check for the executable and defer configuration to the postinst if it's not yet unpacked. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
