Want to help write KC Debian? See the KC Authorship page the KC Debian homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.
A couple of weeks after an set up an apt-able archive with _all_ the packages someone
might need when upgrading the kernel to 2.4.x
, with the following
upgraded packages: modutils, util-linux, e2fsprogs, ppp, pcmcia-cs, and the
following new packages: kernel sources and perhaps images, devfsd, iptables,
reiserfsprogs, usbview and usbutils, perhaps linux-ntfs.
He eventually provided the apt lines:
deb http://people.debian.org/~bunk/debian potato main
deb-src http://people.debian.org/~bunk/debian potato main
but added the following warnings:
- These are packages taken from unstable recompiled on potato. You can't expect that they are as stable as the packages in potato and although I'll try my best I can't garuantee anything.
- When you upgrade modutils you can no longer run a modular 2.0.x kernel.
Anthony Towns posted a long list of packages that would be removed from
testing, including some crucial ones that caught Ben Collin's attention:
base-config and lilo. Ben commented, Without these,
it pretty much makes testing uninstallable using current boot-floppies. Is
that really the intention of testing? Does removing these really help anything
other than your numbers?
Daniel Kobras replied, disks-<arch> is empty in testing, so the 'official' way of getting
testing will be via upgrading. Unfortunately, the lilo in testing will wreck
your configuration and very probably leave you with a system that doesn't
boot unless you manually repair the damage. So, yes, removing lilo indeed
helps.
Anthony added, The real fault
here is that the testing scripts seem to have ignored the RC bug list at
some point and let (at least) a buggy updated lilo in and a buggy smail in,
neither of which should have happened.
Anthony mentioned among other problems: all the packages using the latest debconf which depended on a broken perl 5.6.
David Starner also noticed, That seems like
one of the catchs of testing: the slower build demons (i386, m68k and maybe
arm, from a glance through update_excuses) are frequently delaying the
entrance of programs into testing, because they don't build packages within
10 days.
Elsewhere, Aaron Lehmann mentioned:
The abiword packages have been replaced with abiword-xml and abiword-expat, which unfortunately do not Provide abiword.
It's unfortunate that the maintainer (gecko) is not active, since there is a much newer version of abiword out again. I would love to maintain the package but he hasn't conceded to giving me the package.
Joe Drew replied, Has he said 'no' or have you had
no response? In the latter case, please just take it over (and be willing to
give it back to gecko if he asks for it). I would take over abiword myself if
you don't - I use it and want it to be a much better package.
Aaron
explained that He said no a few months ago, but
has fallen into inactivity again. I'm not greedy for the packages, I'm just
an AbiWord developer who is embarassed by the current state of the Debian
packages and would be satisfied if someone keeps them up to date.
He added that the Abiword developers maintained .deb packages as part of
normal development, so there was really no excuse not to keep it uptodate in
Debian. Joe suggested, post to debian-devel and gecko's
email address saying your plans, wait a little bit, NMU a few times, and if
he still doesn't show up, make the packages better for everyone. Gecko's had
long enough to show up again.
Josip Rodin had a similar suggestion,
and the subthread ended.
Lazarus Long, while pleased with security handling in stable/potato,
and the immediate updates in unstable/sid, worried about lags in security
updates to testing/woody, due to the two week waiting period before packages
trickle in from unstable into testing. Andrea Glorioso replied, I was under the impression that woody was safer than
sid from a "apt-get upgrade won't crash my system" point of view rather
than from a security perspective. If you want security, stick with potato.
Bleeding-edge software (or near bleeding-edge software) rarely can give you
the kind of security assurance that you need if you put a security.debian.org
line in your /etc/apt/sources.list.
Anthony Towns clarified about testing: It does
include security fixes, it merely doesn't include them in as timely a manner
as security.d.o provides for stable. This is fine for release purposes, but
possibly not so fine for people actually running testing.
He contrasted
the timeliness of security updates of the various distributions:
If you're using stable, you can just point apt at security.d.o and not have to worry about anything much. You also get a single list to monitor for security issues. In principle.
If you're using testing, you can watch out for security updates, and only have to worry about occassional problems and inconsistencies: you don't end up with perl broken, eg (at least so far :). You have to get some of these updates from unstable, or build them yourself, which is difficult (at least while apt 0.4 is unreleased).
If you're using unstable, you don't get any assurances at all, but fixes generally come out fairly quickly.
Brian Russo found an amusing typo in the Debian Constitution, in
"Section A.1. Discussion and Amendment, 6." He added, Kind of ironic considering this bit is dealing with how to handle
typographical errors.
He quoted from the Constitution:
6.The proposer of a resolution may make changes to correct minor errors (for example, typographical errors or inconsistencies) or changes which do not alter the meaning, providing noone objects within 24 hours. In this case the mininum discussion period is not restarted."
The misspelled word was "mininum". Roland Mas felt it was a joke on the part of the original author, and Malcolm Parsons pointed out that in the same paragraph, "noone" should have been "no one". By KC Debian press time, "mininum" has been fixed; "noone" has not.