Re: Strange messages
The messages resulted from a toasted news gateway. Within minutes after the incident we have taken action and have blocked that system from further posting as well as informing its maintainer. Since our mail system is very fast several such mails went through, at least 1-5 per list. Regards, Joey Michael Bramer wrote: On Mon, Nov 23, 1998 at 03:59:04PM -0600, Steve Corder wrote: Very recently (i.e. today), I began receiving several unusual messages addressed to the debian-cd@lists.debian.org and the debian-devel-announce@lists.debian.org mailing lists. I say unusual because none of these messages were in English, and unless I'm badly mistaken (it's happened before) some (if not all) of them have to do with cars... Is this just happening to me, or is everyone on the lists getting these messages? I get this messages too. Are the mail rot13-mails? No, they were polish. Regards, Joey -- GNU does not eliminate all the world's problems, only some of them. -- The GNU Manifesto
Debian-List HOWTO
Debian-List HOWTO [EMAIL PROTECTED] November 8, 1999 Martin Schulze Debian-List HOWTO The scope of this document is to help people establish a mailing list at lists.debian.org. The intention of this document is to decrease the workload for the listmasters and to decrease annoying discussions and superflous requests for stuff that is still missing. New lists will only be created if a (wishlist) bug report against lists.debian.org exists and the required information is provided in the bug report. The following information is required if you want to establish a new list: 1. Name Which list do you want to be created? Please note that every list is prefixed by a unique string: Debiandebian- Software in the Public Interest spi- Berlinberlin- Linux Documentation Project ldp- Linux Standard Base lsb- The listmasters will add this string if required. Please keep the name descriptive, short and unique. Subnames are divided by a dash `-'. If the name is not proper the listmasters will reject the request. 2. Rationale Why do you want this list be created, why is it important or similar. Vanity lists (like debian-jokes etc.) will not be created. Do not waste your (and our) time. We will reserve the right to ask for consensus on debian-devel and / or debian-project first. To speed it up you should do this for questionable lists. 3. Long description For http://www.debian.org/MailingLists/subscribe This description is meant for people who are looking for the proper list to join. The description refers to the part of Debian that will be covered. It contains the purposes of the list. 4. Category This is needed to classify the list and to properly sort it on http://www.debian.org/MailingLists/subscribe . One of: . Users . Developers . Internationalization and Translations . Ports . LSB . Other 5. Subscription Policy open / closed If closed, who may get subscribed, who can act as listmaster? 6. Post Policy open / moderated If moderated, who are the moderators? 7. Web-Archive yes / no 8. Short description Only required if 6. is yes. For http://www.debian.org/Lists-Archives/ Hanno Wager Alexander Koch Martin Schulze
Preparing 2.2r3
Preparation of Debian GNU/Linux 2.2r3 = Up-to-date version on http://master.debian.org/~joey/2.2r3/ I'm currently preparing 2.2r3 and will send reports so people can actually comment on it. I'm sortof responsible for this release, however Anthony Towns has to give the final approval for each package. I, however, can and will try to make his work as easy as possible in the hope to get the next release out real soon now. My requirements for packages to go into stable: 1. The package fixes a security problem. Quite helpful would be an advisory issued by the Security Team already. 2. The package fixes a critical bug which can lead into data loss, data corruption or an overly broken system. 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts 4. The package gets all architectures in stable in sync. 5. All released architectures have to be in sync. Packages that I probably reject: . Package that fixes non-critical bugs . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' . Packages that are out of sync Accepted packages - These packages should make it into stable. acroreadupdates 4.05-3 i386 Anthony Fok says: Since multiple users have filed bugs against the NLS problem, it is safe to assume that this problem affects a significant minority of all users,. (PDF files often undisplayable or unprintable without the fix unless they manually set LANG=C or something like that...) So 4.05-3 does indeed: fix an important bug that inconvenience quite a few users; or for newbie users, they don't even know how to fix it with LANG=C... Changelog says: * Added a line in /usr/lib/mime/packages/acroread to force Netscape use the Acroread PDF plugin. Thanks to Thibaut Cousin for reporting the bug and and to fellow Debian developer Ryan Murray for providing the fix. Closes: Bug#79333 * Acroread has some NLS issues that broke viewing and printing for international users when the decimal separator is not a dot. A patch is applied to the acroread wrapper script to set LC_NUMERIC. Thanks to Mirek, Serge Gavrilov, Sebastien Cabot for their bug reports, and special thanks to Florian Siegesmund for providing a patch ported from the netscape wrapper script written by H. Peter Anvin et al. Closes: Bug#66586, #66593, #76840, #86473. * Moved /usr/X11R6/bin/acroread back to /usr/bin/acroread. :-) * Added menu hints=PDF. Thanks, Arthur Korn! Closes: Bug#82321. * Acroread 4.05 does support type-in fields for fill-in forms. Closes: Bug#36451. analog updates 1:4.01-1potato1 alpha, arm, i386, m68k, powerpc, sparc Security Update apache updates 1.3.9-13.2 alpha, arm, i386, m68k, powerpc, sparc Security Update apache-ssl stable1.3.9.13-2 alpha, i386, m68k, powerpc, sparc apache-ssl updates 1.3.9.13-2 arm Get architectures in sync. This is non-US. aview updates 1.2-8.1.1 m68k Fix unmet dependency in potato bind updates 1:8.2.3-0.potato.1 alpha, arm, i386, m68k, powerpc, sparc bind-dev updates 1:8.2.3-0.potato.1 alpha, arm, i386, m68k, powerpc, sparc bind-doc updates 1:8.2.3-0.potato.1 all dnsutils updates 1:8.2.3-0.potato.1 alpha, arm, i386, m68k, powerpc, sparc task-dns-server updates 1:8.2.3-0.potato.1 all Security Update console-apt stable0.7.7.2potato2 i386, m68k, powerpc, sparc console-apt updates 0.7.7.2potato2 alpha, arm Get stable packages in sync cronupdates 3.0pl1-57.2 alpha, arm, i386, m68k, powerpc, sparc Security Update cslatex updates 1.2.2 all Showstopper Fixed cslatex stops installation (closes: #67214, #69224) cupsys-bsd updates 1.0.4-9 i386, m68k, powerpc, sparc cupsys updates 1.0.4-9 i386, m68k, powerpc, sparc libcupsys1-dev updates 1.0.4-9 i386, m68k, powerpc, sparc libcupsys1 updates 1.0.4-9 i386, m68k, powerpc, sparc Security upload Packages compiled for alpha and arm uploaded. No advisory yet, due to audit in progress dedit stable0.5.11 alpha, i386, m68k, powerpc, sparc dedit stable0.5.9 arm dedit updates 0.5.11 arm Get stable in sync dialog updates 0.9a-2118-3bis alpha, arm, i386, m68k, powerpc, sparc Security Update distributed-net updates 2.8012-potato3 alpha, i386, powerpc, sparc aj: It's actually non-free, not contrib. The maintainer says that we ought to be doing this in order to be allowed to
Preparing 2.2r3 - hopefully final
Preparation of Debian GNU/Linux 2.2r3 = Up-to-date version on http://master.debian.org/~joey/2.2r3/ I'm still preparing 2.2r3 and will send reports so people can actually comment on it. I'm sortof responsible for this release, however Anthony Towns has to give the final approval. I, however, can and will try to make his work as easy as possible in the hope to get the next release out real soon now. This mail hopefully is the last status mail that I have to send out before 2.2r3 gets released. Please check the section Further investigation careful and issue a recompile for missing architectures. My requirements for packages to go into stable: 1. The package fixes a security problem. Quite helpful would be an advisory issued by the Security Team already. 2. The package fixes a critical bug which can lead into data loss, data corruption or an overly broken system. 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts 4. The package gets all architectures in stable in sync. 5. All released architectures have to be in sync. Packages that I probably reject: . Package that fixes non-critical bugs . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' . Packages that are out of sync Accepted packages - These packages should make it into stable. acroreadupdates 4.05-3 i386 Anthony Fok says: Since multiple users have filed bugs against the NLS problem, it is safe to assume that this problem affects a significant minority of all users,. (PDF files often undisplayable or unprintable without the fix unless they manually set LANG=C or something like that...) So 4.05-3 does indeed: fix an important bug that inconvenience quite a few users; or for newbie users, they don't even know how to fix it with LANG=C... Changelog says: * Added a line in /usr/lib/mime/packages/acroread to force Netscape use the Acroread PDF plugin. Thanks to Thibaut Cousin for reporting the bug and and to fellow Debian developer Ryan Murray for providing the fix. Closes: Bug#79333 * Acroread has some NLS issues that broke viewing and printing for international users when the decimal separator is not a dot. A patch is applied to the acroread wrapper script to set LC_NUMERIC. Thanks to Mirek, Serge Gavrilov, Sebastien Cabot for their bug reports, and special thanks to Florian Siegesmund for providing a patch ported from the netscape wrapper script written by H. Peter Anvin et al. Closes: Bug#66586, #66593, #76840, #86473. * Moved /usr/X11R6/bin/acroread back to /usr/bin/acroread. :-) * Added menu hints=PDF. Thanks, Arthur Korn! Closes: Bug#82321. * Acroread 4.05 does support type-in fields for fill-in forms. Closes: Bug#36451. analog updates 1:4.01-1potato1 alpha, arm, i386, m68k, powerpc, sparc Security Update apache updates 1.3.9-13.2 alpha, arm, i386, m68k, powerpc, sparc Security Update apache-ssl stable1.3.9.13-2 alpha, i386, m68k, powerpc, sparc apache-ssl updates 1.3.9.13-2 arm Get architectures in sync. This is non-US. aview updates 1.2-8.1.1 m68k Fix unmet dependency in potato bind updates 1:8.2.3-0.potato.1 alpha, arm, i386, m68k, powerpc, sparc bind-dev updates 1:8.2.3-0.potato.1 alpha, arm, i386, m68k, powerpc, sparc bind-doc updates 1:8.2.3-0.potato.1 all dnsutils updates 1:8.2.3-0.potato.1 alpha, arm, i386, m68k, powerpc, sparc task-dns-server updates 1:8.2.3-0.potato.1 all Security Update boot-floppies updates 2.2.22 all Install, uses an updated kernel and other improvements. Other architectures are not able to hold the release, since boot-floppies are normally out of sync. There are too few porters around working on it. m68k: Christian recently relocated to the US, and no one else is willing to do boot-floppies. sparc: Ben Collins plans to build it on April 13th. arm: Peter Naulls or Wookey plan to build them within the next two weeks. powerpc: 2.2.22 does not build. Dan Jacobowitz is going to build 2.2.23 for powerpc on April 13th (night). console-apt stable0.7.7.2potato2 i386, m68k, powerpc, sparc console-apt updates 0.7.7.2potato2 alpha, arm Get stable packages in sync cronupdates 3.0pl1-57.2 alpha, arm, i386, m68k, powerpc, sparc Security Update cslatex updates 1.2.2 all Showstopper Fixed cslatex stops installation (closes: #67214, #69224) cupsys-bsd updates 1.0.4-9 i386, m68k,
master.debian.org hit by disk failure
One of our main servers, namely master.debian.org, is down after it suffered from a disk failure. This was the main reason it was turned off but unfortunately didn't come up again. Adam Heath is currently inspecting the problem, and it seems that our data is still there while the root disk was suffering. This results in a lack of the following services: @debian.org @bugs.debian.org @packages.debian.org http://lists.debian.org/ http://cgi.debian.org/ Mail for master.debian.org and debian.org is queued on murphy and klecker and will be delivered when master is up again. Not affected are: http://packages.debian.org/ @lists.debian.org Sorry for the inconvenience Regards, Joey -- It's practically impossible to look at a penguin and feel angry. pgpeSjL4IoLbO.pgp Description: PGP signature
Proposed General Resolution: IRC as a Debian communication channel
[ Posted as requested by Courtesy Raphaël Hertzog [EMAIL PROTECTED] ] [ Please respect the reply-to [EMAIL PROTECTED] ] Hello, I have proposed the following general resolution a few days ago (my initial mail to debian-devel-announce didn't get through). The discussion takes place on debian-project@lists.debian.org I already have the five required seconds (but you can still second it if you want). Please read what has already been said there before eventually replying : http://lists.debian.org/debian-project/2001/debian-project-200110/threads.html In particular my clarification message : http://lists.debian.org/debian-project/2001/debian-project-200110/msg00103.html Thanks, buxy. PROPOSED GENERAL RESOLUTION IRC AS A DEBIAN COMMUNICATION CHANNEL 1. Context A #debian-devel operator regularly kicks (sometimes bans) people from the channel if they are not Debian developers. He does so even if they have been introduced by developers as valuable Debian contributors and behave correctly in the channel. The invoked reason is historic. #debian-devel used to be for developers only and from time to time issues discussed on [EMAIL PROTECTED] are discussed on #debian-devel. Even the channel founders argued about the policy that should be applied to #debian-devel. Other facts : - #debian-private exists and is key protected (the key should be known by debian developers only), although it is not really used - #debian-devel is useful for many people and is useful for Debian contributors (not yet developers) : * the topic regularly asks for testers of prerelease of some packages * the topic usually warns about the worst problems of unstable * future developers can learn many things by following the discussions - #debian-devel is used for day to day work related to Debian's development 2. Problems * The IRC channels #debian-* are not officially recognized as part of Debian's communication channels. * Debian can't treat valuable contributors like it's done actually on IRC. Kicking a person who naturally has its place within the developer's community (because of his interest and his work) is not reasonable. (Personal note: this kind of behavior gives Debian its bad image of a closed community preaching openness) * Debian's philosophy concerning the development has always been to open the communication channels. There's a mismatch here. 3. Proposed changes We should ackowledge the fact the IRC channels are used to communicate within Debian. They are only an alternate way to discuss things. They are not the main communication channels (the mailing lists are). This should be documented in Debian Developers Reference and wherever it's applicable. By acknowledging their existence, we also have to apply the usual Debian policies : - all #debian-* channels on OpenProjects should be open to everyone except #debian-private which is for registered debian developers only (the actual key protection may be replaced by a better identification mechanism at any time) - the netiquette (RFC 1855, section 4.1.2) applies, channels' subjects should be respected Nevertheless, some specific IRC rules apply : - the channels should not be publicly archived without notice - public quotations may not be accepted by everyone 4. Item proposed to vote (after the discussion period) [ ] I accept the ratification of IRC channels as a communication medium and as such they have to follow the usual Debian policies (adapted for IRC habits) -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguer sans se fatiguer à chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com pgpqRpiUThUDQ.pgp Description: PGP signature
Preparing Debian GNU/Linux 2.2r5
of
Martin Schulze. The 0.4b22 upstream version included
important fixes for data corruption that can occur with the
version that was released with potato.
MISSING alpha
MISSING arm
MISSING powerpc
MISSING sparc
man2htmlstable1.5-23 alpha, arm, i386, m68k, powerpc, sparc
man2htmlupdates 1.5-23.1arm, i386, m68k, powerpc, sparc
* Recompiled with correct CGIBASE to avoid bad links; closes: #104474.
Grave bug, warrants inclusion into stable.
MISSING alpa
nfs-common stable1:0.1.9.1-1 alpha, arm, i386, m68k,
powerpc, sparc
nfs-common updates 1:0.1.9.1-1.potato1 i386, m68k, sparc
nfs-kernel-server stable1:0.1.9.1-1 alpha, arm, i386, m68k,
powerpc, sparc
nfs-kernel-server updates 1:0.1.9.1-1.potato1 i386, m68k, sparc
nhfsstone stable1:0.1.9.1-1 alpha, arm, i386, m68k,
powerpc, sparc
nhfsstone updates 1:0.1.9.1-1.potato1 i386, m68k, sparc
Support statd callbacks from later 2.2 kernels. (closes:
#111990)
It seems that this upload fixes a disparity between late 2.2
kernels and the older nfs-utils package from stable in
connection with statd/lockd.
MISSING alpha
MISSING arm
MISSING powerpc
xcinstable2.3.04-1 arm
xcinstable2.5.1.3-1 powerpc
xcinstable2.5.1.99.pre6.1-1 alpha
xcinstable2.5.2-1i386, m68k, sparc
xcinupdates 2.5.2-1alpha
Get versions back in sync
Beware: change the distribution to stable only.
MISSING arm
MISSING powerpc
Rejected packages
-
These packages don't meet the requirements.
dvi2ps-fontdata-a2n stable1.0-5 all
dvi2ps-fontdata-a2n updates 1.0-6 all
dvi2ps-fontdata-bsr stable1.0-5 all
dvi2ps-fontdata-bsr updates 1.0-6 all
dvi2ps-fontdata-jastable1.0-5 all
dvi2ps-fontdata-jaupdates 1.0-6 all
dvi2ps-fontdata-n2a stable1.0-5 all
dvi2ps-fontdata-n2a updates 1.0-6 all
dvi2ps-fontdata-ptexfake stable1.0-5 all
dvi2ps-fontdata-ptexfake updates 1.0-6 all
dvi2ps-fontdata-rrs stable1.0-5 all
dvi2ps-fontdata-rrs updates 1.0-6 all
dvi2ps-fontdata-rsp stable1.0-5 all
dvi2ps-fontdata-rsp updates 1.0-6 all
dvi2ps-fontdata-tbank stable1.0-5 all
dvi2ps-fontdata-tbank updates 1.0-6 all
dvi2ps-fontdata-three stable1.0-5 all
dvi2ps-fontdata-three updates 1.0-6 all
Misplaced upload to 'stable unstable'
icecast-server stable1.0.0-1 alpha, arm, i386, m68k, powerpc, sparc
icecast-server updates 1.3.10-1alpha, arm, m68k, powerpc, sparc
icecast-server updates 1.3.10-1.1 i386
Alleged security update.
Changelog says:
* Several security exploits found to icecast. No simple way to patch
* old version, so upgrade to latest stable version from icecast.org
* If questions or assistance needed join #icecast on openprojects.net
IRC
Do you have a documentation about said security exploits?
That's still pending
Is it something different than this one?
icecast is a server used to distribute audio streams to
compatible clients such as winamp, mpg123, xmms and many
others. Matt Messier ([EMAIL PROTECTED]) and John Viega
([EMAIL PROTECTED]) have identified several buffer overflow and
format strings problems in Icecast that could be remotely
exploited.
Our latest update to this software changes the package to use
an unprivileged user (icecast) for the daemon, so the impact
of this vulnerability is not as high. Recent distributions (CL
= 5.1) have this package compiled with StackGuard to make it
more difficult to exploit buffer overflows.
It's said to be.
Clarification appreciated.
To make it worse, there is now Version: 1.3.10-1.1
* Binary-only recompile by security team
* Rebuild with potato libc6
roxen-doc stable1.3.122-13 all
roxen-doc updates 1.3.122-22 all
roxen-ssl stable1.3.122-13 all
roxen-ssl updates 1.3.122-22 all
roxen stable1.3.122-11 arm
roxen stable1.3.122-13 alpha, i386, m68k, sparc
roxen updates 1.3.122-22 i386
Misplaced upload:
Distribution: stable unstable
* Dropping the 'task-webserver-roxen2' package...
* Updating config.{sub|guess} Closes: #111546
samba-common stable2.0.7-3.4 alpha, arm, i386, m68k, powerpc, sparc
samba-common updates 2.0.7-4 alpha, arm, i386, m68k, powerpc, sparc
samba stable2.0.7-3.4
Preparing another stable revision (r6)
An up-to-date version is at http://master.debian.org/~joey/2.2r6/ In another quixotic attempt, I am preparing another revision of the stable Debian distribution (r6) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. The plan is to get this revision of Debian GNU/Linux 2.2 (codename `potato') out within the first week of March this year (2002). James Troup still has to give the final approval for each package since he is the ftpmaster involved with stable revisions. However, I will try to make his work as easy as possible in the hope to get the next revision out properly. Thanks for your attention. This may also be the last version of the 2.2 series, depending on how well the woody release is making progress. There is, however, still a possibility 2.2r7 (to be scheduled at the beginning of May) has to be released before 3.0. My requirements for packages to go into stable: 1. The package fixes a security problem. An advisory by our own Security Team would be quite helpful. I really should make this a requirement for security uploads. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. Packages, which I will most probably reject: . Package which fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable'. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. Accepted packages - These packages should be installed into stable and be part of the next revision. adjtimexstable1.10-1 alpha, i386 adjtimexstable1.5-1 sparc adjtimexstable1.5-3 powerpc adjtimexstable1.7-1 arm adjtimexstable1.8.1-1 m68k adjtimexupdates 1.10-1 arm, m68k, powerpc, sparc Get versions in sync, apart from that: * New upstream release - security fix: use popen() to recover output from ntpdate, instead of an unsafe temporary file (thanks to Colin Phipps [EMAIL PROTECTED]) (closes:bug#56752) at stable3.1.8-10alpha, arm, i386, m68k, powerpc, sparc at updates 3.1.8-10.2 alpha, arm, i386, m68k, powerpc, sparc Security Upload, DSA 102 dumpstable0.4b16-1 alpha, arm, i386, m68k, powerpc, sparc dumpupdates 0.4b25-0.potato.1 alpha, arm, i386, m68k, powerpc, sparc * back-port dump current version to potato at the request of Martin Schulze. The 0.4b22 upstream version included important fixes for data corruption that can occur with the version that was released with potato. fml stable3.0+beta.2106-1 all fml updates 3.0+beta.2106-5 all DSA 088, improper character escaping gcc stable1:2.95.2-13alpha, i386, powerpc, sparc gcc stable1:2.95.2-13.1 arm, m68k gcc updates 1:2.95.2-13.1 alpha, i386, powerpc, sparc Changelog says: * Non-maintainer upload * Add new patch for ARM (closes #75801) Clarification required. Doko queried. He approved, the patch is conditionalized so gets only applied on ARM. glibc-doc stable2.1.3-19all glibc-doc updates 2.1.3-20all i18ndata stable2.1.3-19all i18ndata updates 2.1.3-20all libc6-dbg stable2.1.3-19arm, i386, m68k, powerpc, sparc libc6-dbg updates 2.1.3-20arm, i386, m68k, powerpc, sparc libc6-dev stable2.1.3-19arm, i386, m68k, powerpc, sparc libc6-dev updates 2.1.3-20arm, i386, m68k, powerpc, sparc libc6-pic stable2.1.3-19arm, i386, m68k, powerpc, sparc libc6-pic updates 2.1.3-20arm, i386, m68k, powerpc, sparc libc6-profstable2.1.3-19arm, i386, m68k, powerpc, sparc libc6-profupdates 2.1.3-20arm, i386, m68k, powerpc, sparc libc6.1-dbg stable2.1.3-19alpha libc6.1-dbg updates 2.1.3-20alpha libc6.1-dev stable2.1.3-19alpha libc6.1-dev updates 2.1.3-20alpha libc6.1-pic stable2.1.3-19alpha libc6.1-pic updates 2.1.3-20alpha libc6.1-prof stable2.1.3-19alpha libc6.1-prof updates 2.1.3-20alpha libc6.1 stable2.1.3-19alpha libc6.1 updates 2.1.3-20alpha libc6 stable2.1.3-19arm, i386, m68k, powerpc, sparc libc6 updates 2.1.3-20arm, i386, m68k, powerpc, sparc locales stable2.1.3-19alpha, arm, i386, m68k
Preparing another stable revision (r6)
An up-to-date version is at http://master.debian.org/~joey/2.2r6/ In another quixotic attempt, I am preparing another revision of the stable Debian distribution (r6) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. The plan is to get this revision of Debian GNU/Linux 2.2 (codename `potato') out within the first week of March this year (2002). James Troup still has to give the final approval for each package since he is the ftpmaster involved with stable revisions. However, I will try to make his work as easy as possible in the hope to get the next revision out properly. Thanks for your attention. This may also be the last version of the 2.2 series, depending on how well the woody release is making progress. There is, however, still a possibility 2.2r7 (to be scheduled at the beginning of May) has to be released before 3.0. My requirements for packages to go into stable: 1. The package fixes a security problem. An advisory by our own Security Team would be quite helpful. I really should make this a requirement for security uploads. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. Packages, which I will most probably reject: . Package which fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable'. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. Accepted packages - These packages should be installed into stable and be part of the next revision. adjtimexstable1.10-1 alpha, i386 adjtimexstable1.5-1 sparc adjtimexstable1.5-3 powerpc adjtimexstable1.7-1 arm adjtimexstable1.8.1-1 m68k adjtimexupdates 1.10-1 arm, m68k, powerpc, sparc Get versions in sync, apart from that: * New upstream release - security fix: use popen() to recover output from ntpdate, instead of an unsafe temporary file (thanks to Colin Phipps [EMAIL PROTECTED]) (closes:bug#56752) at stable3.1.8-10alpha, arm, i386, m68k, powerpc, sparc at updates 3.1.8-10.2 alpha, arm, i386, m68k, powerpc, sparc Security Upload, DSA 102 cupsys-bsd stable1.0.4-9 alpha, arm, i386, m68k, powerpc, sparc cupsys-bsd updates 1.0.4-10alpha, arm, i386, m68k, powerpc, sparc cupsys stable1.0.4-9 alpha, arm, i386, m68k, powerpc, sparc cupsys updates 1.0.4-10alpha, arm, i386, m68k, powerpc, sparc libcupsys1-dev stable1.0.4-9 alpha, arm, i386, m68k, powerpc, sparc libcupsys1-dev updates 1.0.4-10alpha, arm, i386, m68k, powerpc, sparc libcupsys1 stable1.0.4-9 alpha, arm, i386, m68k, powerpc, sparc libcupsys1 updates 1.0.4-10alpha, arm, i386, m68k, powerpc, sparc Security upload: DSA 110, Buffer overflow dumpstable0.4b16-1 alpha, arm, i386, m68k, powerpc, sparc dumpupdates 0.4b25-0.potato.1 alpha, arm, i386, m68k, powerpc, sparc * back-port dump current version to potato at the request of Martin Schulze. The 0.4b22 upstream version included important fixes for data corruption that can occur with the version that was released with potato. faqomatic stable2.603-1.1 all faqomatic updates 2.603-1.2 all Security upload, DSA 109, cross-site scripting vulnerability fml stable3.0+beta.2106-1 all fml updates 3.0+beta.2106-5 all DSA 088, improper character escaping gcc stable1:2.95.2-13alpha, i386, powerpc, sparc gcc stable1:2.95.2-13.1 arm, m68k gcc updates 1:2.95.2-13.1 alpha, i386, powerpc, sparc Changelog says: * Non-maintainer upload * Add new patch for ARM (closes #75801) Clarification required. Doko queried. He approved, the patch is conditionalized so gets only applied on ARM. glibc-doc stable2.1.3-19all glibc-doc updates 2.1.3-20all i18ndata stable2.1.3-19all i18ndata updates 2.1.3-20all libc6-dbg stable2.1.3-19arm, i386, m68k, powerpc, sparc libc6-dbg updates 2.1.3-20arm, i386, m68k, powerpc, sparc libc6-dev stable2.1.3-19arm, i386, m68k, powerpc, sparc libc6-dev updates 2.1.3-20arm, i386, m68k, powerpc, sparc libc6-pic stable2.1.3-19arm, i386, m68k, powerpc, sparc libc6
Bits from the SRM
Not sure if people would like to read more bits, but if so, here are some. The first update of Debian woody is on its way. Preparation of Debian GNU/Linux 3.0r1 = An up-to-date version is at http://master.debian.org/~joey/3.0r1/. I am preparing the first revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. The plan is to release this revision at the beginning of October, 2002. James Troup still has to give the final approval for each package since he is the ftpmaster involved with stable revisions. However, I will try to make his work as easy as possible in the hope to get the next revision out properly. The regulations for stable are quite conservative. The requirements for packages to get into stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the security team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. It is (1 OR 2 OR 3) AND 4 Since this is the first revision of stable, I may be a little bit lax about enforcing reason 2. However, regular bugs and upgrade problems should instead be documented in the Release Notes which are maintained by Rob Bradford [EMAIL PROTECTED] and found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. cacti stable0.6.7-2 all, source cacti updates 0.6.7-2.1 all, source DSA-164 cacti - arbitrary code execution cron-aptstable0.0.6all, source cron-aptupdates 0.0.6woody1 all, source * Added default path so the upgrade will work fine. Thanks to Donovan Baarda [EMAIL PROTECTED] for pointing out the problem. Closes: #158869. Rationale: Without the path, this package doesn't run out of the box on woody anymore. debiandoc-sgml stable1.1.67all, source debiandoc-sgml updates 1.1.67woody1 all, source On a machine which was upgraded from potato to woody a couple of months before release, there is a wrong entry in transitional.cat, which causes debiandoc to be unusable. My opinion is, it is bad enough (and simple enough to fix) so that it must go into 3.0r1. * debian/postinst: added invocation of 'install-sgmlcatalog --remove debiandoc-sgml' to clean up cruft potentially left over from the SGML catalog transition in a potato - woody upgrade (closes: Bug#154737) dietlibc-dev stable0.12-2 alpha, arm, i386, mips, mipsel, powerpc, sparc dietlibc-dev updates 0.12-2.4alpha, arm, i386, mips, mipsel, powerpc, sparc dietlibc stable0.12-2 source dietlibc updates 0.12-2.4source DSA-146 dietlibc - integer overflow elkdoc stable3.0-8.1 all elk stable3.0-8.1 arm, hppa, i386, m68k, mips, mipsel, powerpc, s390, sparc, source elk updates 3.0-8.1 alpha Get architectures in sync (IA-64 is missing, though, but the package doesn't seem to compile on that arch) ethereal-common stable0.9.4-1woody1 alpha, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc ethereal-common updates 0.9.4-1woody2 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc ethereal-dev stable0.9.4-1woody1 alpha, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc ethereal-dev updates 0.9.4-1woody2 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc ethereal stable0.9.4-1woody1 alpha, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc, source ethereal updates 0.9.4-1woody2 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source tetherealstable0.9.4-1woody1 alpha, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc tetherealupdates 0.9.4-1woody2 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc DSA-162 ethereal - buffer overflow fam
Preparation of Debian GNU/Linux 3.0r1
Preparation of Debian GNU/Linux 3.0r1 = An up-to-date version is at http://master.debian.org/~joey/3.0r1/. I am preparing the first revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain to me why certain packages should be handled differently. There is still time to reconsider. It requires good arguments, though. Several security updates got lost partially or totally or were rejected by the katie archive system. I'm working on bits I can work on, others will have to be left to the ftp people. The plan is to release this revision in the middle of November, 2002. James Troup still has to give the final approval for each package since he is the ftpmaster involved with stable revisions. However, I will try to make his work as easy as possible in the hope to get the next revision out properly. The regulations for stable are quite conservative. The requirements for packages to get into stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the security team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. It is (1 OR 2 OR 3) AND 4 Since this is the first revision of stable, I may be a little bit lax about enforcing reason 2. However, regular bugs and upgrade problems should instead be documented in the Release Notes which are maintained by Rob Bradford [EMAIL PROTECTED] and found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. bugzillastable2.14.2-0woody1 all, source bugzillaupdates 2.14.2-0woody2 all, source DSA-173 bugzilla - privilege escalation cacti stable0.6.7-2 all, source cacti updates 0.6.7-3 all, source DSA-164 cacti - arbitrary code execution 0.6.7-3 contains a tempfile race condition cron-aptstable0.0.6all, source cron-aptupdates 0.0.6woody1 all, source * Added default path so the upgrade will work fine. Thanks to Donovan Baarda [EMAIL PROTECTED] for pointing out the problem. Closes: #158869. Rationale: Without the path, this package doesn't run out of the box on woody anymore. debiandoc-sgml stable1.1.67all, source debiandoc-sgml updates 1.1.67woody1 all, source On a machine which was upgraded from potato to woody a couple of months before release, there is a wrong entry in transitional.cat, which causes debiandoc to be unusable. My opinion is, it is bad enough (and simple enough to fix) so that it must go into 3.0r1. * debian/postinst: added invocation of 'install-sgmlcatalog --remove debiandoc-sgml' to clean up cruft potentially left over from the SGML catalog transition in a potato - woody upgrade (closes: Bug#154737) dietlibc-dev stable0.12-2 alpha, arm, i386, mips, mipsel, powerpc, sparc dietlibc-dev updates 0.12-2.4alpha, arm, i386, mips, mipsel, powerpc, sparc dietlibc stable0.12-2 source dietlibc updates 0.12-2.4source DSA-146 dietlibc - integer overflow docbook-xml-slides stable1.1-2 all, source docbook-xml-slides updates 1.1-2.1woody2 all, source Don't depend on obsolete library anymore. This bug is just an incorrect dependency in the control file, which makes docbook-xml-slides insist on pulling the obsolete docbook-xsl-stylesheets instead of recent docbook-xsl. This in turns causes other packages to be uninstallable, because they correctly depend on the new one. elkdoc stable3.0-8.1 all elk stable3.0-8.1 arm, hppa, i386, m68k, mips, mipsel, powerpc, s390, sparc, source elk updates 3.0-8.1 alpha Get architectures in sync (IA-64 is missing, though, but the package doesn't seem to compile on that
Preparation of Debian GNU/Linux 3.0r1
Preparation of Debian GNU/Linux 3.0r1 = An up-to-date version is at http://master.debian.org/~joey/3.0r1/. I am preparing the first revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision in the middle of November, 2002. James Troup still has to give the final approval for each package since he is the ftpmaster involved with stable revisions. However, I will try to make his work as easy as possible in the hope to get the next revision out properly. The regulations for stable are quite conservative. The requirements for packages to get into stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the security team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. It is (1 OR 2 OR 3) AND 4 Since this is the first revision of stable, I may be a little bit lax about enforcing reason 2. However, regular bugs and upgrade problems should instead be documented in the Release Notes which are maintained by Rob Bradford [EMAIL PROTECTED] and found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. afterstep stable1.8.11-5woody1 alpha, hppa, i386, ia64, mips, mipsel, s390, sparc, source afterstep updates 1.8.11-5woody1 arm, powerpc Try to sync architectures. There is an m68k package hooked up in testing-proposed-updates as well. The arm package was built on July 4th, but didn't make it into the archive, strangely. apache-common stable1.3.26-0woody1 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc apache-common updates 1.3.26-0woody3 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc apache-dev stable1.3.26-0woody1 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc apache-dev updates 1.3.26-0woody3 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc apache-doc stable1.3.26-0woody1 all apache-doc updates 1.3.26-0woody3 all apache stable1.3.26-0woody1 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source apache updates 1.3.26-0woody3 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source DSA-187 apache - several vulnerabilities apache-ssl stable1.3.26.1+1.48-0woody2 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source apache-ssl updates 1.3.26.1+1.48-0woody3 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source DSA-188 apache-ssl - several vulnerabilities bugzillastable2.14.2-0woody1 all, source bugzillaupdates 2.14.2-0woody2 all, source DSA-173 bugzilla - privilege escalation cacti stable0.6.7-2 all, source cacti updates 0.6.7-3 all, source DSA-164 cacti - arbitrary code execution 0.6.7-3 contains a tempfile race condition cron-aptstable0.0.6all, source cron-aptupdates 0.0.6woody1 all, source * Added default path so the upgrade will work fine. Thanks to Donovan Baarda [EMAIL PROTECTED] for pointing out the problem. Closes: #158869. Rationale: Without the path, this package doesn't run out of the box on woody anymore. debiandoc-sgml stable1.1.67all, source debiandoc-sgml updates 1.1.67woody1 all, source On a machine which was upgraded from potato to woody a couple of months before release, there is a wrong entry in transitional.cat, which causes debiandoc to be unusable. My opinion is, it is bad enough (and simple enough to fix) so that it must go into 3.0r1. * debian/postinst: added invocation of
Preparation of Debian GNU/Linux 3.0r1
Preparation of Debian GNU/Linux 3.0r1 = An up-to-date version is at http://master.debian.org/~joey/3.0r1/. I am preparing the first revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision at some time in the future. James Troup still has to give the final approval for each package since he is the ftpmaster involved with stable revisions. However, I will try to make his work as easy as possible in the hope to get the next revision out properly. The regulations for stable are quite conservative. The requirements for packages to get into stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the security team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. If it is a kernel package, I can detect a similar amount of packages to remove, preferably older versions of the new packages. It is ((1 OR 2 OR 3) AND 4) OR 5 Since this is the first revision of stable, I may be a little bit lax about enforcing reason 2. Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. afterstep stable1.8.11-5woody1 alpha, hppa, i386, ia64, mips, mipsel, s390, sparc, source afterstep updates 1.8.11-5woody1 arm, powerpc Try to sync architectures. There is an m68k package hooked up in testing-proposed-updates as well. The arm package was built on July 4th, but didn't make it into the archive, strangely. apache-common stable1.3.26-0woody1 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc apache-common updates 1.3.26-0woody3 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc apache-dev stable1.3.26-0woody1 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc apache-dev updates 1.3.26-0woody3 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc apache-doc stable1.3.26-0woody1 all apache-doc updates 1.3.26-0woody3 all apache stable1.3.26-0woody1 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source apache updates 1.3.26-0woody3 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source DSA-187 apache - several vulnerabilities apache-perl stable1.3.26-1-1.26-0woody1 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source apache-perl updates 1.3.26-1-1.26-0woody2 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source DSA-195 apache-perl - several vulnerabilities apache-ssl stable1.3.26.1+1.48-0woody2 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source apache-ssl updates 1.3.26.1+1.48-0woody3 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source DSA-188 apache-ssl - several vulnerabilities arcboot stable0.3.1mips, source arcboot updates 0.3.3.9.woody.0 mips, source tip22 updates 0.3.3.9.woody.0 mips Guido writes: - it don't lets failures to read from an ext2 fs completely crash the loader (like when you enter a non existent partition in the prom) - it introduces tip22 as a separate binary package[1], a piggyback style tftp loader that is used to pack kernel and initrd into one ecoff file which can be tftpbooted. This finally solves the whole initrd issues on mips. Without that mips will not be able to use kernels
Preparation of Debian GNU/Linux 3.0r1
Preparation of Debian GNU/Linux 3.0r1 = An up-to-date version is at http://master.debian.org/~joey/3.0r1/. I am preparing the first revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision at some time in the future. James Troup still has to give the final approval for each package since he is the ftpmaster involved with stable revisions. However, I will try to make his work as easy as possible in the hope to get the next revision out properly. The regulations for stable are quite conservative. The requirements for packages to get into stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the security team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. If it is a kernel package, I can detect a similar amount of packages to remove, preferably older versions of the new packages. It is ((1 OR 2 OR 3) AND 4) OR 5 Since this is the first revision of stable, I may be a little bit lax about enforcing reason 2. Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. afterstep stable1.8.11-5woody1 alpha, hppa, i386, ia64, mips, mipsel, s390, sparc, source afterstep updates 1.8.11-5woody1 arm, powerpc Try to sync architectures. There is an m68k package hooked up in testing-proposed-updates as well. The arm package was built on July 4th, but didn't make it into the archive, strangely. apache-common stable1.3.26-0woody1 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc apache-common updates 1.3.26-0woody3 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc apache-dev stable1.3.26-0woody1 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc apache-dev updates 1.3.26-0woody3 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc apache-doc stable1.3.26-0woody1 all apache-doc updates 1.3.26-0woody3 all apache stable1.3.26-0woody1 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source apache updates 1.3.26-0woody3 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source DSA-187 apache - several vulnerabilities apache-perl stable1.3.26-1-1.26-0woody1 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source apache-perl updates 1.3.26-1-1.26-0woody2 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source DSA-195 apache-perl - several vulnerabilities apache-ssl stable1.3.26.1+1.48-0woody2 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source apache-ssl updates 1.3.26.1+1.48-0woody3 alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc, source DSA-188 apache-ssl - several vulnerabilities arcboot stable0.3.1mips, source arcboot updates 0.3.3.9.woody.0 mips, source tip22 updates 0.3.3.9.woody.0 mips Guido writes: - it don't lets failures to read from an ext2 fs completely crash the loader (like when you enter a non existent partition in the prom) - it introduces tip22 as a separate binary package[1], a piggyback style tftp loader that is used to pack kernel and initrd into one ecoff file which can be tftpbooted. This finally solves the whole initrd issues on mips. Without that mips will not be able to use kernels
Results from the Security Survey last Year
Debian Security Survey [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze February 17th, 2003 http://www.debian.org/security/faq Results from the Security Survey last Year http://lists.debian.org/debian-devel-announce-0211/msg1.html Counted votes total: 153 Votes used for calculations: 130 Too many people (about 100) didn't supply proper dates but used free text for responses to the questions I initially asked. Hence, their answers need to be interpreted into a date or ignored. Assuming forever as December 31st, 2003 we get these results: Wait upgrading approximately until : March 15, 2003 Want support for potato approx. until: March 11, 2003 The results vary a little bit if the answer is weighted by the number of potato machines these people maintain: Wait upgrading approximately until : November 3, 2003 Want support for potato approx. until: October 23, 2003 However, one person answered the questions and revealed that he maintains some 4000 machines running potato that he cannot simply upgrade to woody. He will replace the machines with woody systems, though, in case of failures. So, removing this answer, the results (still weighted) become: Wait upgrading approximately until : June 11th, 2003 Want support for potato approx. until: May 2nd, 2003 If the interpretation of forever is changed into December 31st, 2004, the calculated results (still weighted) will move up again: Wait upgrading approximately until : September 18, 2003 Want support for potato approx. until: May 27, 2003 In general it seems that many Debian administrators would rather like to stay with the old stable release before upgrading, for about one year after a new stable version has been released. This places a heavy burdon on the security team which has to support the old stable distribution for one year. This means, supporting two distributions (including all architectures) for one year after a new stable distribution has been released. Conclusion I will probably continue to support potato with security updates at least until end of June 2003 and I hope that the other members of the Security Team will do the same. This means that we support potato for additional 12 months after the release of woody, which is much more than users can expect from a group of volunteers who only work on the system for the sake of it. However, since investigating, correcting and fixing packages for two entirely different code bases needs to be done, supporting woody and potato is very time consuming and you should not expect security updates for potato after the end of June 2003. You should have upgraded to woody anyway. Regards, Joey -- Life is too short to run proprietary software. -- Bdale Garbee pgpZcx3wgW0E5.pgp Description: PGP signature
Preparation of Debian GNU/Linux 3.0r2 (II)
Preparation of Debian GNU/Linux 3.0r2 = An up-to-date version is at http://master.debian.org/~joey/3.0r2/. I am preparing the second revision of the current stable Debian distribution (woody) which will probably be released soon. This report is to allow people to comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision at some time in the future. An ftpmaster still has to give the final approval for each package since they are responsible for the archive. However, I will try to make their work as easy as possible in the hope to get the next revision out properly. The regulations for stable are quite conservative. The requirements for packages to get into stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the security team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. If it is a kernel package, I can detect a similar amount of packages to remove, preferably older versions of the new packages. It is ((1 OR 2 OR 3) AND 4) OR 5 Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. acm stable5.0-3 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source acm updates 5.0-3.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 333 - integer overflow apcupsd stable3.8.5-1.1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source apcupsd updates 3.8.5-1.1.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 277 - buffer overflows, format string aspell-en stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc aspell stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc source libaspell-dev stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc libaspell10stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc The license incorrectly says that it's LGPL but it is in fact a unique license which is non-DFSG-free. atftpd stable0.6 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc atftpd updates 0.6.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc atftp stable0.6 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source atftp updates 0.6.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 314 - buffer overflow autorespond stable2.0.2-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source autorespond updates 2.0.2-2woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 373 - buffer overflow balsa stable1.2.4-2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source balsa updates 1.2.4-2.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 300 - buffer overflow bind-devstable1:8.3.3-0.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc bind-devupdates 1:8.3.3-2.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc bind-docstable1:8.3.3-0.woody.1 all bind-docupdates 1:8.3.3-2.0woody1 all bindstable1:8.3.3-0.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source bindupdates 1:8.3.3-2.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 196 - several vulnerabilities bugzilla-doc stable2.14.2-0woody2 all bugzilla-doc updates 2.14.2-0woody4 all
Preparation of Debian GNU/Linux 3.0r2 -- (III)
Preparation of Debian GNU/Linux 3.0r2 = An up-to-date version is at http://master.debian.org/~joey/3.0r2/. I am preparing the second revision of the current stable Debian distribution (woody). This is most probably the last report before the update can be made on Wednesday/Thursday. However, there's still time to comment on it and intervene if this is required. If you disagree with one bit or another, please reply to this mail personally and explain why these things should be handled differently. The regulations for stable are quite conservative. The requirements for packages to get into stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the security team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. If it is a kernel package, I can detect a similar amount of packages to remove, preferably older versions of the new packages. It is ((1 OR 2 OR 3) AND 4) OR 5 Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. Changelog - * Investigation conquest * Moved galeon from further to reject * Moved hylafax from reject to accept * Accepted intlfonts * Rejected libpam-pwdfile * Accepted minimalist * Moved mysql-dfsg from further to reject * Accepted omega-rpg * Moved openssh from reject to accept * Accepted postgresql * Accepted wemi * Moved xnc from further to accept Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. acm stable5.0-3 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source acm updates 5.0-3.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 333 - integer overflow apcupsd stable3.8.5-1.1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source apcupsd updates 3.8.5-1.1.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 277 - buffer overflows, format string aspell-en stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc aspell stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc source libaspell-dev stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc libaspell10stable0.33.7.1-8 alpha arm hppa i386 ia64 m68k powerpc s390 sparc The license incorrectly says that it's LGPL but it is in fact a unique license which is non-DFSG-free. atftpd stable0.6 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc atftpd updates 0.6.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc atftp stable0.6 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source atftp updates 0.6.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 314 - buffer overflow autorespond stable2.0.2-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source autorespond updates 2.0.2-2woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 373 - buffer overflow balsa stable1.2.4-2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source balsa updates 1.2.4-2.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 300 - buffer overflow bind-devstable1:8.3.3-0.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc bind-devupdates 1:8.3.3-2.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc bind-docstable1:8.3.3-0.woody.1 all bind-docupdates 1:8.3.3-2.0woody1 all bindstable1:8.3.3-0.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source bindupdates 1:8.3.3-2.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 196 -
Preparation of the next stable Debian GNU/Linux update [Oct 8th]
Preparation of the next stable Debian GNU/Linux update == An up-to-date version is at http://people.debian.org/~joey/3.0r3/. I am sorry for not being able to send out the entire document, but the preparation efforts list has grown so much that the large mail is rejected at the Debian listserver due to its sheer size. I am preparing the third revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision at some time in the future, hopefully before the release of sarge. It may be the last update if no updates to 3.0 are possible after sarge has been released. An ftpmaster still has to give the final approval for each package since ftpmaster are responsible for the archive. However, I will try to make their work as easy as possible in the hope to get the next revision out properly and without too much hassle. The regulations for updates to the stable Debian release are quite conservative. The requirements for packages to get updated in stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the Security Team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. The package gets all released architectures back in sync. It is (or (and (or 1 2 3) 4) 5) Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. . Packages that fix an unusable minor part of a package. If you would like to get a package updated in the stable release, you are advised to talk to the stable release manager first (see http://www.debian.org/intro/organization). This is probably the last update to the current stable Debian release since updates are impossible when a new suite is labelled stable. It's also possible that the current stable Debian release won't be updated at all. ChangeLog - 2004/10/08 12:28 MET * Accepted lesstif1-1 * Accepted libapache-mod-dav * Accepted net-acct * Accepted netkit-telnet * Accepted rp-pppoe Disclaimer -- This list intends to help the ftp-masters releasing 3.0r3. They have the final power to accept a package or not. If you want to comment on this list, please send a mail to Martin Schulze [EMAIL PROTECTED]. Last updated 2004/10/08 12:28 MET -- Unix is user friendly ... It's just picky about its friends. Please always Cc to me when replying to me on the lists. signature.asc Description: Digital signature
S/390 buildd reconfiguration -- problem fix
Moin, a recent upgrade of the Z/VM of the S/390 machine Millenux hosts and which runs the Debian S/390 buildd (debian01.zseries.org) caused the old kernel to run without the network interface. In order to get networking running again a new 64bit kernel was required. Unfortunately this changed the kernel architecture from s390 to s390x. This in turn has the potential to break older configure scripts. This is a quite unfortunate incident this close to a release and will slow down security support for woody and sarge. The security team has already stomped over the first package that fails to build anymore in a plain woody S/390 environment. The Cure If you notice something like the following in build logs of failed builds checking build system type... Invalid configuration `s390x-ibm-linux': machine `s390x-ibm' not recognized configure: error: /bin/sh ./config.sub s390x-ibm-linux failed. make: *** [build-stamp] Error 1 The following patch should help get the package to build again. --- config.sub~ 2004-10-11 18:30:48.0 +0200 +++ config.sub 2004-10-11 18:30:57.0 +0200 @@ -259,7 +259,7 @@ case $basic_machine in | mips64el-* | mips64orion-* | mips64orionel-* \ | mips64vr4100-* | mips64vr4100el-* | mips64vr4300-* | mips64vr4300el-* \ | mipstx39-* | mipstx39el-* | mcore-* \ - | f301-* | armv*-* | s390-* | sv1-* | t3e-* \ + | f301-* | armv*-* | s390-* | s390x-* | sv1-* | t3e-* \ | m88110-* | m680[01234]0-* | m683?2-* | m68360-* | z8k-* | d10v-* \ | thumb-* | v850-* | d30v-* | tic30-* | c30-* | fr30-* \ | bs2000-* | tic54x-* | c54x-*) A more recent configure suite should suffice as well, but this is not applicable for certain cases where the changes to the source should be kept as minimal as possible: . security updates . upload into *-proposed-updates . updates in unstable for frozen packages that should be pushed through into testing Please note that it is required for uploaded packages to be buildable by the buildds. However, for the release of sarge, we consider it as an important bug if a new upload won't be built any more. Of course, fixing important bugs is appreciated. -- GNU GPL: The source will be with you... always. Please always Cc to me when replying to me on the lists. signature.asc Description: Digital signature
Preparation of Debian GNU/Linux 3.0r3
An up-to-date version is at http://people.debian.org/~joey/3.0r3/. I am preparing the third revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision at some time in the future. An ftpmaster still has to give the final approval for each package since they are responsible for the archive. However, I will try to make their work as easy as possible in the hope to get the next revision out properly. The regulations for stable are quite conservative. The requirements for packages to get into stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the security team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. If it is a kernel package, I can detect a similar amount of packages to remove, preferably older versions of the new packages. It is (or (and (or 1 2 3) 4) 5) Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. Due to the number of recent kernel vulnerabilities this update will contain several updated kernel packages. This poses a threat to our users since the correction for do_brk() (CAN-2003-0961) changes the binary compatibility of the kernel, hence local or vendor-provided modules won't work anymore. As a result i386 kernels cannot be exchanged, but for most other architectures this is possible. Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. bindstable1:8.3.3-2.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source bindupdates 1:8.3.3-2.0woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 409 bind - denial of service bind9-docstable1:9.2.1-2.woody.1 all bind9-docupdates 1:9.2.1-2.woody.2 all bind9-host stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc bind9-host updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc bind9stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source bind9updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source dnsutils stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc dnsutils updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libbind-dev stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libbind-dev updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libdns5 stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libdns5 updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libisc4 stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libisc4 updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libisccc0stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libisccc0updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libisccfg0 stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libisccfg0 updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc liblwres1stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc liblwres1updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc lwresd
Preparation of the next stable update
Preparation of Debian GNU/Linux 3.0r3 = An up-to-date version is at http://people.debian.org/~joey/3.0r3/. I am preparing the third revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision at some time in the future. An ftpmaster still has to give the final approval for each package since they are responsible for the archive. However, I will try to make their work as easy as possible in the hope to get the next revision out properly. The regulations for stable are quite conservative. The requirements for packages to get into stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the security team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. If it is a kernel package, I can detect a similar amount of packages to remove, preferably older versions of the new packages. It is (or (and (or 1 2 3) 4) 5) Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. Due to the number of recent kernel vulnerabilities this update will contain several updated kernel packages. This poses a threat to our users since the correction for do_brk() (CAN-2003-0961) changes the binary compatibility of the kernel, hence local or vendor-provided modules won't work anymore. As a result i386 kernels cannot be exchanged, but for most other architectures this is possible. Changelog - * Investigation of aptitude * Moved atari800 from further to accept * Investigation of freeamp * Accepted hdate * Investigation of imagemagick * Moved initrd-tools from further to reject * Accepted junior-puzzle * Investigation of junior-writing * Moved kaffe from further to reject * Accepted kernel-patch-2.4.0-ia64 * Accepted kernel-patch-2.4.0-reiserfs * Accepted kernel-patch-2.4.1-ia64 * Moved libgtop from further to accept * Accepted lpr-ppd * Investigation of lvm10 * Moved mpg321 from further to accept * Moved nd from further to accept * Moved perl from accept to further * Moved phpmyadmin from further to reject * Moved rinetd from further to accept * Investigation of scsh * Accepted xroach Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. atari800stable1.2.2-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source atari800updates 1.2.2-1woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 359 - buffer overflows contrib bindstable1:8.3.3-2.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source bindupdates 1:8.3.3-2.0woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 409 bind - denial of service bind9-docstable1:9.2.1-2.woody.1 all bind9-docupdates 1:9.2.1-2.woody.2 all bind9-host stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc bind9-host updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc bind9stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source bind9updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source dnsutils stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc dnsutils updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libbind-dev stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libbind-dev updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64
Preparation of the next stable update
Preparation of the next stable Debian GNU/Linux update == An up-to-date version is at http://people.debian.org/~joey/3.0r3/. I am preparing the third revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision at some time in the future. An ftpmaster still has to give the final approval for each package since they are responsible for the archive. However, I will try to make their work as easy as possible in the hope to get the next revision out properly. The regulations for stable are quite conservative. The requirements for packages to get into stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the security team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. If it is a kernel package, I can detect a similar amount of packages to remove, preferably older versions of the new packages. It is (or (and (or 1 2 3) 4) 5) Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. Due to the number of recent kernel vulnerabilities this update will contain several updated kernel packages. This poses a threat to our users since the correction for do_brk() (CAN-2003-0961) changes the binary compatibility of the kernel, hence local or vendor-provided modules won't work anymore. As a result i386 kernels cannot be exchanged, but for most other architectures this is possible. Changelog - * Moved aptitude from further to accept * Moved imagemagick from further to accept * Accepted interchange * Accepted kdenetwork * Accepted kernel-image-2.4.17-hppa * Moved lvm10 from further to accept * Moved metamail from further to accept * Moved nbd from further to accept * Moved nethack from further to accept * Moved openssl from further to accept * Moved rsync from further to accept * Moved spamassassin from further to accept * Removed spellcast * Investigation of syslog-ng * Moved tcpdump from further to accept Accepted Packages - These packages will be installed into the stable Debian distribution and will be part of the next revision. aptitudestable0.2.11.1-2 alpha arm hppa i386 ia64 m68k powerpc s390 sparc source aptitudeupdates 0.2.11.1-4 alpha arm hppa i386 ia64 m68k powerpc s390 sparc source Support Pre-Depends, required for a smooth upgrade: Rebuild for stable-proposed-updates...should have done this a couple years ago, but better late than never. This upgrade is needed to cleanly upgrade from Woody to Sarge. See bug #151701 for details. atari800stable1.2.2-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source atari800updates 1.2.2-1woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 359 atari800 - buffer overflows contrib bindstable1:8.3.3-2.0woody1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source bindupdates 1:8.3.3-2.0woody2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source DSA 409 bind - denial of service bind9-docstable1:9.2.1-2.woody.1 all bind9-docupdates 1:9.2.1-2.woody.2 all bind9-host stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc bind9-host updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc bind9stable1:9.2.1-2.woody.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source bind9updates 1:9.2.1-2.woody.2 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source dnsutils stable1:9.2.1-2.woody.1 alpha
Most Debian Machines temporarily restricted
Due to the most recent Linux kernel vulnerability that was disclosed today, Debian admins had to restrict all hosts temporarily in order to install a corrected kernel. The vulnerability was disclosed by iSEC today and is described here: http://isec.pl/vulnerabilities/isec-0015-msfilter.txt Most core non-porting and non-buildd machines are already fixed and accessible again. This refers to the following machines: o newsamosa o newraff o spohr o saens o master o murphy Unfortunately gluck requires action from a local admin, so http://people.debian.org/ is currently not available. The local admins of the other machines are informed. The hosts will be unrestricted as soon as we can confirm that a corrected kernel is installed and running. We are sorry for the inconvenience this caused on you. We hope that the machines will be available for you soon again. Thanks a lot to James Troup who worked on new kernels as soon as the problem went public. Regards, Joey -- Still can't talk about what I can't talk about. Sorry. -- Bruce Schneier signature.asc Description: Digital signature
Preparation of the next stable Debian GNU/Linux update
Preparation of the next stable Debian GNU/Linux update == An up-to-date version is at http://people.debian.org/~joey/3.0r3/. I am sorry for not being able to send out the entire document, but the preparation efforts list has grown so much that the large mail is rejected at the Debian listserver due to its sheer size. I am preparing the third revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision at some time in the future, hopefully before the release of sarge. It may be the last update if no updates to 3.0 are possible after sarge has been released. An ftpmaster still has to give the final approval for each package since ftpmaster are responsible for the archive. However, I will try to make their work as easy as possible in the hope to get the next revision out properly and without too much hassle. The regulations for updates to the stable Debian release are quite conservative. The requirements for packages to get updated in stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the Security Team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. The package gets all released architectures back in sync. It is (or (and (or 1 2 3) 4) 5) Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. . Packages that fix an unusable minor part of a package. If you would like to get a package updated in the stable release, you are advised to talk to the stable release manager first (see http://www.debian.org/intro/organization). This is probably the last update to the current stable Debian release since updates are impossible when a new suite is labelled stable. It's also possible that the current stable Debian release won't be updated at all. ChangeLog - 2004/09/03 06:54 MET * Accepted qt-copy * Updated krb5 (accept) * Updated python2.2 (accept) Disclaimer -- This list intends to help the ftp-masters releasing 3.0r3. They have the final power to accept a package or not. If you want to comment on this list, please send a mail to Martin Schulze [EMAIL PROTECTED]. Last updated 2004/09/03 06:54 MET -- WARNING: Do not execute! This call violates patent DE10108564. http://www.elug.de/projekte/patent-party/patente/DE10108564 wget -O patinfo-`date +%Y%m%d`.html http://patinfo.ffii.org/ signature.asc Description: Digital signature
Preparation of the next stable Debian GNU/Linux update
Preparation of the next stable Debian GNU/Linux update == An up-to-date version is at http://people.debian.org/~joey/3.0r3/. I am sorry for not being able to send out the entire document, but the preparation efforts list has grown so much that the large mail is rejected at the Debian listserver due to its sheer size. I am preparing the third revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision at some time in the future, hopefully before the release of sarge. It may be the last update if no updates to 3.0 are possible after sarge has been released. An ftpmaster still has to give the final approval for each package since ftpmaster are responsible for the archive. However, I will try to make their work as easy as possible in the hope to get the next revision out properly and without too much hassle. The regulations for updates to the stable Debian release are quite conservative. The requirements for packages to get updated in stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the Security Team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. The package gets all released architectures back in sync. It is (or (and (or 1 2 3) 4) 5) Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. . Packages that fix an unusable minor part of a package. If you would like to get a package updated in the stable release, you are advised to talk to the stable release manager first (see http://www.debian.org/intro/organization). This is probably the last update to the current stable Debian release since updates are impossible when a new suite is labelled stable. It's also possible that the current stable Debian release won't be updated at all. ChangeLog - 2004/09/25 03:27 MET * Moved courier from further to accept * Accepted cupsys * Moved ethereal from further to accept * Accepted gnomesword * Accepted gtk+2.0 * Accepted imlib * Accepted imlib2 * Moved kdebase from further to accept * Moved libpng3 from further to accept * Accepted lukemftpd * Moved netkit-telnet-ssl from further to accept * Accepted wv Disclaimer -- This list intends to help the ftp-masters releasing 3.0r3. They have the final power to accept a package or not. If you want to comment on this list, please send a mail to Martin Schulze [EMAIL PROTECTED]. Last updated 2004/09/25 03:27 MET -- Unix is user friendly ... It's just picky about its friends. signature.asc Description: Digital signature
ToDo List for the Boot Floppies Package
ToDo List for the Boot Floppies Package I guess you all know that new slink boot floppies have been uploaded today bu the leader of the boot floppies team, Enrique Zanardi. Please test them and write appropriate bug reports if you discover problems with them. I've talked to Enrique about things that still need to be done with the boot-floppies package. This is the compiled list. I'm sure there are still tasks missing. If you want to add things to the list please drop me a line, I might post another list to debian-devel-announce again, depending on the progress made. . Try to trim the rescue floppy so that it fits on a 1.44 MB disk again. . Modify on boxes.c so that the dialog boxes resize themselves. As the messages have different lenghts for the different translations, this is a must-have for the translated floppies. Also take care of the current screen size (start linux with vga=ask and use 132x44 for example). . Implement an install on a loop filesystem option. The major work should be fulfilled by Jens 'grimaldi' Ritter. . Read more data from the boot prompt (keyboard language, source medium, network config, ... eventually everything may be provided from the boot prompt. That makes an unattended installation trivial, one just write the proper syslinux.cfg file and there it goes...) . Implement an install base system from a HTTP server option. . Go through the huge list of bugs, closing/reassigning the already fixed/not in boot-floppies but on syslinux or kernel bugs. . The user should only be queried once for the cd-rom path if the path that was provided at the first place matches the need at the second place, too. Is the /dev/cdrom link created now? . Provide a debug program for each and every dialog box - can also be used to provide screen shots of the installation. This includes some fiddling with internal settings. (long term todo) . Provide easy targets for boot floppies in non-english languages. Currently 'es' is ready, 'de' is on the way.[1] . Include dpkg-multicd in the base system. (theoretically solved) . Maybe make multi_cdrom the default access method for dselect. How does one achieve this? If you have some spare time I would appreciate if Enrique could be provided some appropriate patches when he is back on Nov 9th. [1] If you want to translate the system into another language you should get in touch with err... Hartmut Koptein (hee hee) or me. I would prefer Harmut while I'm sure that he would prefer to contact me... You chose. Regards, Joey -- The only stupid question is the unasked one. pgpSNVsXLCAmE.pgp Description: PGP signature
gluck available again / filesystem shaked
After gluck.debian.org started experiencing problems writing to its disks on Sunday we have tried our best to get the machine back in shape. As we have checked all files that we could and fixed all services that had broken files, best to our knowledge, we have decided to bring the machine back online. Please verify the files in your home directory. !!! Please check the files in your home directories! !!! After several runs of e2fsck the machine was running stable again. However, unfortunately, the filesystem that contains /home (and hence /org as /home/org) was totally screwed. Many inode numbers were exchanged by a near random permutation. As a result of this, former files were turned into directories which contained files that weren't supposed to be where we found them. Other files were named properly but had wrong content. Also several files contained blocks in the middle which weren't supposed to be there, hence, broken content. We have restored the services that were running on gluck.debian.org as good as we were able to. We have also removed spurious files in users home directories. We are unable to check the content of the remaining files in users home directories, though. This machine hosted the following service (some only as local copy) cdimage.debian.orgrecovered cvs.debian.orgchecked, see below ddtp.debian.org disabled before ftp.debian.orgonly a copy, recreated keyring.debian.orgonly a copy, recreated lintian.debian.orgbroken, needs to be rebuilt packages.debian.org moved to another machine admin.debian.org verified people.debian.org need to be checked planet.debian.org fixed popcon.debian.org verified release.debian.orgfixed www.debian.orgrestored woody chroot recreated The following CVS repositories are currently hosted on gluck: /cvs/webwml restored from backup /cvs/dak needs to be verified /cvs/debian-admin not affected /cvs/debian-doc restored from backup /cvs/debian-boot restored from backup /cvs/debian-openofficechecked, should be mostly fine /cvs/debian-planetfixed /cvs/debian-policylooks fine /cvs/debbugs looks fine /cvs/deitylooks fine /cvs/dpkg looks fine /cvs/qa looks fine /cvs/tetexfixed (one corrupt file to be replaced) There are still problems in developers home directories. These need to be verified from the developers on their own. In particular, the public files in the public_html directories need to be verified to be not broken. The .ssh directory has been disabled for all users. In the directory /home/__Corrupt-R-US/$LOGNAME you'll find the spurious files with wrong ownership that were found in the developer's home directory. Feel free to take a look at them. We will remove these on May 1st, so don't wait too long with checking whether anything useful is included. !!! Please check the files in your home directories! !!! If you have any questions, feel free to contact the Debian admin team at [EMAIL PROTECTED]. Regards, Joey PS: There are 23 accounts that had a current .ssh and a disabled one from the break in as well. If you instate a new .ssh directory, it's probably a good idea to remove the old one(s). -- It's time to close the windows. signature.asc Description: Digital signature
Preparation of the next stable Debian GNU/Linux update (III)
the end of time). ssmtp stable2.50.6.1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source ssmtp updates 2.50.6.2alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source Suspicius upload. Suspicious interdiff. Removed Packages These packages will be removed from the stable Debian distribution. This normally only a result of license problems when the license prohibits their distribution. Disclaimer -- This list intends to help the ftp-masters releasing 3.0r6. They have the final power to accept a package or not. If you want to comment on this list, please send a mail to Martin Schulze [EMAIL PROTECTED]. Last updated 2005/05/20 06:07 MET -- Computers are not intelligent. They only think they are. signature.asc Description: Digital signature
Preparation of the next stable Debian GNU/Linux update (IV)
available in the copyright file. MISSING alpha MISSING arm MISSING hppa MISSING ia64 MISSING m68k MISSING mips MISSING mipsel MISSING powerpc MISSING s390 MISSING sparc spellcast-doc stable1.0 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source spellcast-doc updates 1.0.1 i386 source * Moved to non-free due to licensing which was incorrectly considered free by the previous maintainer. See http://lists.debian.org/debian-legal/2003/debian-legal-200310/msg00136.html * Added a rant on why spellcast is not GPL describing the issue in the README.Debian file with more detail than the information available in the copyright file. MISSING alpha MISSING arm MISSING hppa MISSING ia64 MISSING m68k MISSING mips MISSING mipsel MISSING powerpc MISSING s390 MISSING sparc syslog-ng stable1.5.15-1alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source syslog-ng updates 1.5.15-1.2 hppa syslog-ng updates 1.5.15-1.3 mipsel source 1.5.15-1.2 would be DSA 175 syslog-ng - buffer overflow 1.5.15-1.3 has the security update again yaboot stable1.3.6-1 powerpc source yaboot updates 1.3.10-0woody1 powerpc source * Backport yaboot 1.3.10 to stable (See bug #190439). - This is necessary to boot/install on recent Apple hardware. - Ethan reports that the one line change between 1.3.9 and 1.3.10 is critical. Unly required for new boot-floppies Rejected Packages - These packages don't meet the requirements and will be rejected (if katie supports that, otherwise we'll just carry them with us until the end of time). bzip2 stable1.0.2-1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source bzip2 updates 1.0.2-1.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source libbz2-1.0 stable1.0.2-1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libbz2-1.0 updates 1.0.2-1.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libbz2-dev stable1.0.2-1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc libbz2-dev updates 1.0.2-1.1 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc Fixes RC bug - in a distribution where RC bugs aren't fixed anymore. (and prevented a security update *args*) Removed Packages These packages will be removed from the stable Debian distribution. This normally only a result of license problems when the license prohibits their distribution. Disclaimer -- This list intends to help the ftp-masters releasing 3.0r6. They have the final power to accept a package or not. If you want to comment on this list, please send a mail to Martin Schulze [EMAIL PROTECTED]. Last updated 2005/05/27 20:55 MET -- Computers are not intelligent. They only think they are. signature.asc Description: Digital signature
Debian Day @ LinuxTag 2005 / and additional talks
Debian Day @ LinuxTag 2005 / and additional talks - I'm happy to announce (even though I should have done this one week ago already) the schedule for the Debian Day, the mini-conference of the Debian project traditionally held during LinuxTag. It will take place on Thursday, 23rd of June during this year's LinuxTag in Karlsruhe, Germany. The talks will describe certain parts of the distribution or the project and will be held in English. Thursday, June 23rd, 2005, Room 2.05 Time | Speaker Title --+- 10:00 | Norbert Tretkowski: Backporting Practice 11:00 | Joey Schulze: Debian Security 12:00 | Luk Claes:Internationalisation localisation 13:00 | Goswin von Brederlow: Debian Archive Structure 14:00 | Martin Zobel-Helas: The volatile Archive 15:00 | Meike Reichle:The Debian Women Project 16:00 | Andreas Tille:CDD: Current and Future 17:00 | Jörg Jaspert: Bootable multi-arch CDs Due to the large number of talks submitted and interesting topics we have decided to extended the Debian day by another day. Hence, part two will take place on Friday, 24th of June. Friday, June 24th, 2005, Room 2.05 Time | Speaker Title --+- 12:00 | Yutaka Niibe: Porting to m32r Architecture 13:00 | Mike Wiesner: Kerberos V5 mit Debian 14:00 | Stefano Zacchiroli: OCaml @ Debian 15:00 | Andreas Tille:Knowledge, Power and free Beer 16:00 | Hauke Goos-Habermann: m23 Distribution System 17:00 | Michael Banck:The Ubuntu Development Model In addition to these talks, we'd like to add another list of talks that have a connection to the Debian distribution or the Debian project, in addition to the keysigning party. Some of these may also be of interest for visitors who are interested in ongoings of Debian. Only some of these talks will be held in English. Wednesday, June 22nd, 2005 10:00 Fabian Franz: Einführung in Knoppix (EG Weinbrenner) Thursday, June 23rd, 2005 13:30 Florian Schießl: Linux in München (UG2 Mombert) 17:00 Alexander Schmehl:Neues in Debian Sarge (EG Forum) Friday, June 24th, 2005 12:00 Fernanda Weiden: Free Software with a female touch (UG2 Mombert) 16:00 Mako Hill:Strategies in Financing (UG2 Mombert) 17:00 Fabian Franz: Einführung in Knoppix (Practical Linux Forum) Saturday, June 25th, 2005 14:00 Peter Palfrader: Key Signing Party (R 2.05) 15:00 Debian Developers*: Debian Projekt intern (UG3 Hebel) 16:00 Alexander Schmehl:Paybacktime (EG Forum) 17:00 Mako Hill:Debian and Ubuntu (UG3 Hebel) 17:00 Michael Kofler: Ubuntu - Das menschliche Linux (EG Weinbrenner) 17:00 Gregorio Robles: Quo vadis, libre software? (UG3 Hebel) * Jörg Jaspert, Frank Lichtenheld, Andreas Barth, Joey Schulze For more information, please check the Debian day page at http://www.infodrom.org/Debian/events/LinuxTag2005/day.html For locating the conference rooms, please see the building overview: http://www.infodrom.org/Debian/events/LinuxTag2005/conference.html In addition to this hopefully overwhelming conference program the Debian project will maintainer a booth in the exhibition area. The new sarge release will be demonstrated at the booth. -- Reading is a lost art nowadays. -- Michael Weber signature.asc Description: Digital signature
nm.debian.org and qa.debian.org moved to merkel
A while ago the services of nm.debian.org have been moved from klecker to merkel. Even longer ago the services of qa.debian.org have been moved from klecker to merkel. To finnish this the respective developer accounts have been disabled on klecker as well. The home directories have been moved to /org/klecker.debian.org_home on gluck and will be removed one month. The affected maintainers have been informed via mail and are asked to move their old home directory and zero out the tar file. Regards, Joey -- A mathematician is a machine for converting coffee into theorems. Paul Erdös Please always Cc to me when replying to me on the lists. signature.asc Description: Digital signature
Need help with file-rc
Hi! file-rc has one release critical bug. I can't reproduce this bug on my systems that use file-rc. At the moment I don't think that I'm able to track it down - mainly due time shortness. Could somebody please review it and investigate the problem. I'd appreciate a non-maintainer upload if needed or appropriate patches to fix it? Please contact me in either case. #23057: file-rc: rcS fails to complete startup Package: file-rc; Severity: critical; Reported by: Wakko Warner [EMAIL PROTECTED]; 14 days old. http://www.infodrom.north.de/Debian/Bugs/db/23/23057.html Thanks in advance, Joey -- / Martin Schulze http://home.pages.de/~joey/ / *** Fatal Error: Found [MS-Windows],[EMAIL PROTECTED] / / repartitioning Disk for Linux ... / pgpGjtqSXoR9b.pgp Description: PGP signature
[joey: Intent to package mswordview]
I apologize, but I used the wrong list... Regards, Joey - Forwarded message from Martin Schulze joey - --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi! I plan to package this. It's distributed under the GPL. MSWordView is a program that can understand the microsofts word 8 binary file format (office97), it currently converts word into html, which can then be read with a browser. MSWordView is being actively worked on, and will be pretty bleeding edge for the next few weeks. It works fine so far. http://www.csn.ul.ie/~caolan/docs/MSWordView.html Regards, Joey --=20 / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / The only stupid question is the unasked one / --azLHFNyN32YCQGCU Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- Version: 2.6.3ia iQCVAwUBNZKVvRRNm5Suj3z1AQF/9QP+L4MM3NDh4Y314ZtVm8jS1nrwLFtdYwtA TMh6pZZyuI/Lc75EwhF+gK7kbqJb/mDTJNYakuitB5U713zF0yDDPX5ZbRt/pxfq +Wph83gZBg62PIBuP32MMydovhvQv5U251AER3n/WSEKPNBQQvbGh9Ea1y7cWZ18 li0l55U3FCw= =TjtY -END PGP SIGNATURE- --azLHFNyN32YCQGCU-- - End forwarded message - -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / The only stupid question is the unasked one / -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Retract packaging mswordview
Ouch! I can't package this software. At least not for now: File: ConvertUTF.C Author: Mark E. Davis Copyright (C) 1994 Taligent, Inc. All rights reserved. This code is copyrighted. Under the copyright laws, this code may not be copied, in whole or part, without prior written consent of Taligent. Taligent grants the right to use or reprint this code as long as this ENTIRE copyright notice is reproduced in the code or reproduction. The code is provided AS-IS, AND TALIGENT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL TALIGENT BE LIABLE FOR ANY DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR OTHER PECUNIARY LOSS) ARISING OUT OF THE USE OR INABILITY TO USE THIS CODE, EVEN IF TALIGENT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE LIMITATION MAY NOT APPLY TO YOU. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(l)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19. This code may be protected by one or more U.S. and International Patents. TRADEMARKS: Taligent and the Taligent Design Mark are registered trademarks of Taligent, Inc. I have now contacted the author and hope he'll get a replacement. Regards, Joey PS: If s/o needs this package, contact me. -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / http://home.pages.de/~joey/ / The only stupid question is the unasked one / pgpYaw8m1mr2W.pgp Description: PGP signature
Intend to package gtkfind
gtkfind-0.7 is a graphical file-finding program using the gtk toolkit A screenshot can be found here: http://www.oz.net/~mattg/gtkfind.gif Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror.
Re: Suse supports linuxconf
Rainer Dorsch wrote: I remembered, that there was some time ago some discussion about linuxconf on the list. I just picked up, that Suse will support linuxconf (beside yast) in Suse 6.0 (release date: end of 1998). Please check our experimental such as ftp://ftp.infodrom.north.de/pub/debian/project/experimental/linuxconf_1.10r34-1_i386.deb If you think it's not fully integrated, please find some time and work on it. If you think that it should be included in the regular release, please discuss it with the maintainer, and/or here. Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror.
Re: Intent to Package GNU nana
Brent Fulgham wrote: I am working on a project that could benefit from the GNU nana package. It would be a cool idea if you would provide a description what nana is or does. Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror.
Re: Switch to perl-5.005_02 ?
Darren/Torin/Who Ever... wrote: Joey Hess, in an immanent manifestation of deity, wrote: Do you have any plans to offer it as something like /usr/bin/perl-t? (or would modules need to be rebuilt too?) It will be available as /usr/bin/perl5.00502-thread. I could manage the /usr/bin/perl-t as alternatives. No suidperl will be offered for this. Any debian packages and all architecture dependent packages will have to be recompiled. The 5.00502-thread will install itself under I guess after the new version of perl is installed in slink somebody should file bugreports against all architecture-dependent perl packages, i.e. CPAN modules with a severity of at least important so they will be either recompiled or removed with slink. Btw. do we have a name for the next release yet? Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror.
Re: what's after slink
This leaves the following possible names: Ben Gertzfield wrote: Here's what imdb.com says: Cast overview, first billed only: Don Rickles Mr. Potato Head John Morris (III) Andy Laurie Metcalf Mrs. Davis R. Lee Ermey Sergeant Sarah Freeman Hannah so we really don't have that many more choices.. 2.2 potatoe 2.3 andy 2.4 davis 3.0 sergeant 3.1 hannah The namespase lasts for five more releases. Or do I misunderstand something? Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror.
Re: What about a bookmarks-package ?
Christian Hammers wrote: Why not creating a Debian package that contains a huge html file with links and some bookmarks-file converters for Netscape/IE/lynx etc. P.S.: Yes, I would like to be maintainer - if all of you be contributers =;-) I'd say: Go ahead. First start for the search engines: http://www.infodrom.north.de/search.html Regards, Joey -- Whenever you meet yourself you're in a time loop or in front of a mirror.
Re: Craig Small here?
Christian Schwarz wrote: [Please CC: any replies to me, since I'm not subscribed to your list] Craig Small [EMAIL PROTECTED] sent me mail about the Debian CD web pages on www.debian.org. Unfortunately, this address bounces (host scooter not found) and also his @debian.org address bounces (same reason). Does someone have a working address? That should be his current address. Regards, Joey -- Unable to locate coffee, operator halted. -- Stefan Farsch
Re: pine in other distributions
Kikutani Makoto wrote: I'm sorry, Pine again (and again and...). Does anybody know if other distributions (RedHat, slack...) have Pine package ? They have. If they have it, I assume their license policy is not hard as Debian. Indeed. Debian is know for its maximum pickyness wrt copyrights and licenses. There is a pine-src package which will build a local pine.deb. Regards, Joey -- Unable to locate coffee, operator halted. -- Stefan Farsch
Re: what's after slink
Wichert Akkerman wrote: Previously Martin Schulze wrote: The namespase lasts for five more releases. Or do I misunderstand something? On a related note, do we want to continue using names from pixar movies now that Bruce is gone? I don't see a reason for not continuing this scheme. Even stronger I believe that changing it everytime the namespace founder leaves would be a very stupid idea. We should discuss a new naming scheme in five years when there are no names left (~12 names, 3 releases per year plus some names from successor movies -- 5 years). Regards, Joey -- Unable to locate coffee, operator halted. -- Stefan Farsch
Re: pine in other distributions
Kikutani Makoto wrote: On Sun, Oct 04, 1998 at 05:52:47PM +0200, Martin Schulze [EMAIL PROTECTED] wrote: Does anybody know if other distributions (RedHat, slack...) have Pine package ? They have. If they have it, I assume their license policy is not hard as Debian. Indeed. Debian is know for its maximum pickyness wrt copyrights and licenses. There is a pine-src package which will build a local pine.deb. I see. According to the past pine discussions, it seemed that Pine must be distributed with its source. Is this correct ? I haven't looked at the copyright yet since pine is out of interest for me. From what I saw on the lists the copyrights fails at permitting us to distribute (modified) binaries. Generally speaking all .deb files contain *modified* binaries. That's why there is only a source package. Regards, Joey -- Unable to locate coffee, operator halted. -- Stefan Farsch
[Milan Zamazal] Re: Intent to package sabre
Milan Zamazal wrote: I'd like to package sabre if nobody objects. sabre is an svgalib flight simulator. License: GPL 1. Milan Zamazal -- Having GNU Emacs is like having a dragon's cave of treasures. Robert J. Chassell -- VFS: no free i-nodes, contact Linus -- finlandia, Feb '94
Re: Live file system
Michael Meskes wrote: Do we have a complete filesystem on CD like SuSE does? It's a nice addition for those short in disk space. Please send an appropriate patch to the debian-cd maintainer. Regards, Joey -- Never trust an operating system you don't have source for!
Re: Live file system
Michael Meskes wrote: On Tue, Oct 06, 1998 at 07:37:10PM +0200, Martin Schulze wrote: Do we have a complete filesystem on CD like SuSE does? It's a nice addition for those short in disk space. Please send an appropriate patch to the debian-cd maintainer. That means there is none? I don't have a patch. Neither am I going to create one, but a collegue that I try to persuade to switch from SuSE might be interested. The live file system is the only thing that keeps him from switching and he might be willing to put some time into it. So if we don't have it I talk to him and tell you more. It is quite easy to install a set of packages on a different partition and write it to cd afterwards. So if you have a cd write around you should be able to produce a custom cd for him. Regards, Joey -- Never trust an operating system you don't have source for!
New list debian-snapshots
Hi, a new mailing list, debian-snapshots@lists.debian.org, has been created by request of Jim Pick. The purpose of this list is to discuss various topics about automatic building of binary packages out of upstream CVS repositories. A tool is planned that will handle this sort of package building. Currently many parts of Gnome and egcs are developed through publically available CVS repositories. Subscription / Unsubscription *NO* subscription or unsubscription messages should be sent to the lists address, but to a special control address which is slightly different from the lists address. To subscribe or unsubscribe to such a list, please send mail to [EMAIL PROTECTED] with the word `subscribe' or `unsubscribe' as subject. Please remember the -REQUEST inside of the name. If you need to contact a human listmaster, direct your mail to [EMAIL PROTECTED] or [EMAIL PROTECTED] . These are two different machines in case one is offline. Regards, Joey -- Never trust an operating system you don't have source for! pgp7aJVZAPsHd.pgp Description: PGP signature
Re: debian for non linux systems ...
[EMAIL PROTECTED] wrote: Hello, I remember some month ago there was a discution some time ago about debian for non entirely debian systems (i think it was a debian-solaris thing). What happened to it ? i was given a ultra sparc 1 with solaris 2.6 here at the university, and þerhaps i would like to work on such a thing. (not now, but i a month or so...) You should grab the dpkg development snapshot from the cvs directory or ~klee on master. Regards, Joey -- There are lies, statistics and benchmarks.
Re: Top source
Peter Iannarelli wrote: Hello all: What package hosts the top command? finlandia!joey(tty11):~ dpkg -S bin/top procps: /usr/bin/top netstd: /usr/bin/toport finlandia!joey(tty11):~ dpkg -l procps Desired=Unknown/Install/Remove/Purge | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersionDescription +++-===-==- ii procps 1.2.7-2The /proc file system utilities. Regards, Joey -- There are lies, statistics and benchmarks.
debian/rules and find
Hi, this afternoon I occurred a serious problem where some of our debian/rules file will fail. xargs will *always* execute the command, even with no input. This means that all constructs like find -name foo|xargs chmod g+w will fail as soon as find doesn't find any file. As Joey pointed out this is a documented feature. I understand that there are situations where this is a needed feature. However in the process of creating .deb files this is not needed, even worse it will stop the creation. Instead we should use xargs -r or --no-run-if-empty which won't execute the program on the command line if there is no input. So please check your debian/rules files for constructs like the following: chmod g+w `find debian/tmp -name foo` find debian/tmp -name foo|xargs chmod g+w the correct way to implement this would be find debian/tmp -name foo|xargs -r chmod g+w Regards, Joey -- There are lies, statistics and benchmarks.
Contacting authors
Hi,
tonight I was thinking about implementing @authors.debian.org which
would enable a way for us to get in touch with the upstream authors of
some piece of software without the need of looking into the copyright
file or digging in the source if the maintainer forgot to add the
authors email into that file.
What do you think about it?
Example: [EMAIL PROTECTED] would redirect the mail to
[EMAIL PROTECTED] who is the current developer of hypermail.
An easy way to implement this would be to simply add a line to the
source section of debian/control of each package like
Source: gtkfind
Section: x11
Priority: optional
Maintainer: Martin Schulze [EMAIL PROTECTED]
Author: Matt Grossman [EMAIL PROTECTED] this one
Standards-Version: 2.4.0.0
Package: gtkfind
Architecture: any
Depends: ${shlibs:Depends}
Description: Graphical File Finder
This package provides a graphical file finding program.
This would also need an adjustment for dpkg-source.
What do you think about this?
Regards,
Joey
--
There are lies, statistics and benchmarks.
pgpNU6K7p5bEo.pgp
Description: PGP signature
Flagging squid bug as important
Hi, I'd like to flag Bug#27444 severity important since it filled up my disk to 100% for the fourth time two days ago. This suxx and since there is a patch provided it won't hold the release (except nobody makes a new upload for it). http://www.infodrom.north.de/Debian/Bugs/db/27/27444.html Do I receive your objection or acceptance? Regards, Joey -- There are lies, statistics and benchmarks.
Re: Contacting authors
Shaleh wrote: On 07-Oct-98 Martin Schulze wrote: Hi, tonight I was thinking about implementing @authors.debian.org which would enable a way for us to get in touch with the upstream authors of some piece of software without the need of looking into the copyright file or digging in the source if the maintainer forgot to add the authors email into that file. What do you think about it? This sounds good in theory. However numerous pieces of software have no defined author. Enlightenment has two, which should be listed? Either note the leading maintainer, write down both addresses, take its development list or leave it out. However the development list might not be a good idea. I haven't made my mind up. How about making the field optional, and if it is not present the mail gets forwarded to the developer? An optional field would be ok. If there is no author available the mail [c/w]ould be redirected to the current maintainer. This mechanism is already available through packages.debian.org. I't like to tag it at the same priority as using @debian.org as the maintainer address. Read: Please do it but if not nobody would seriously complain. Regards, Joey -- There are lies, statistics and benchmarks.
Re: Contacting authors
Alexander Koch wrote: Hi Joey. What do you think about it? Will it produce more mail to the authors? Will *they* like it? Which author doesn't like to be contacted wrt his software? Besides, you can leave it out. Regards, Joey -- There are lies, statistics and benchmarks.
Re: Contacting authors
Darren Benham wrote: Before packaging something, I check with the upstream author. I know it's GPL but I like to be polite about it. In one case, I had the upstream author make some suggestions and one of them was to make sure any and all mail about the package got sent to me. I think he'd be an example of someone who doesn't want a lot of email about his software... Interesting, but since I'd like to have this field optional this is no problem referring to my proposal. Regards, Joey -- There are lies, statistics and benchmarks.
Re: Contacting authors
Martin Schulze wrote:
tonight I was thinking about implementing @authors.debian.org which
would enable a way for us to get in touch with the upstream authors of
some piece of software without the need of looking into the copyright
file or digging in the source if the maintainer forgot to add the
authors email into that file.
What do you think about it?
[..]
This would also need an adjustment for dpkg-source.
This is the change that's needed to pass the Author field through
the control file.
--- dpkg-source.origWed Oct 7 23:49:17 1998
+++ dpkg-source Wed Oct 7 23:57:25 1998
@@ -51,7 +51,7 @@
$i = 100;
grep ($fieldimps {$_} = $i--,
- qw (Source Version Binary Maintainer Architecture Standards-Version));
+ qw (Source Version Binary Maintainer Author Architecture
Standards-Version));
while (@ARGV $ARGV[0] =~ m/^-/) {
$_=shift(@ARGV);
@@ -111,7 +111,7 @@
if (s/^C //) {
#print STDERR G key $_ value $v\n;
if (m/^Source$/) { setsourcepackage; }
-elsif (m/^Standards-Version$|^Maintainer$/) { $f{$_}= $v; }
+elsif (m/^Standards-Version$|^Maintainer$|^Author$/) { $f{$_}= $v;
}
elsif (s/^X[BC]*S[BC]*-//i) { $f{$_}= $v; }
elsif (m/^(Section|Priority|Files)$/ || m/^X[BC]+-/i) { }
else { unknown('general section of control info file'); }
Regards,
Joey
--
There are lies, statistics and benchmarks.
Re: Contacting authors
Joey Hess wrote: Example: [EMAIL PROTECTED] would redirect the mail to [EMAIL PROTECTED] who is the current developer of hypermail. It seems like a good idea in general. The only 2 problems I can see are that we would have to keep track of authors changing their email addresses, and that some authors may not want this as an address that points to them (they may be concerned about spam going to it, for example). We already have to keep track of authors changing their email addresses since we have to put their name and address in the copyright file. Re spam: I'd like to make it optional so it does not have to be used but only should. Each pkg. maintainer could negotiate with the upstream author about this feature and not use it if the author doesn't like that. Regards, Joey -- There are lies, statistics and benchmarks.
1st unpacking, 2nd dependency checking
This might be an faq. But occasionally I notices that dpkg first unpacks and installs the files in a particular package and checks dependencies afterwards. This means that wrong dependencies are discovered when it is too late since the old version of the package is already overwritten. I'm sure there is a rationale for this, but what is it? At least I would have expected that dpkg tests the dependency of new packages and refuses to unpack them - unless one told it to ignore dependencies. Regards, Joey -- There are lies, statistics and benchmarks.
Re: perl version depends
Darren Stalder wrote: Is it possible for dpkg to have a depends line similar to: Depends: perl (=5.005) and have that include 5.005-\d+? Or will I need to put a = means equal. I guess it's logical that 5.005 != 5.005-1 Thus I believe it would need to use (= 5.005-0) Provides: perl5.005 in so that packages can depend on that? (Note that I did say that this would break *all* debian installed packages in the change release.) (I thought that debian-devel had reached a consensous that it's not a good idea to change the perl version less than 14 days before the code freeze.) Regards, Joey -- There are lies, statistics and benchmarks.
Re: korganizer debian package (OT: licence interpretation)
Russell Coker wrote: I have one question to that - in what way does distributing a binary suddenly resolve a licence conflict? According to the GPL, GPL'd code can not be linked to QT; _only_ the author of a given piece of code has the right to make an exception to that rule. Because the original in many cases was not written for QT, no such exception is present. I believe that what Moritz is saying is that the main KDE packages (kdesupport, kdelibs, kdebase, kdenetwork, and koffice) are all quite legal because the authors expressly wrote them for use with QT. The only issue is Is this written down in the license? If they're released with plain GPL and without this important notice - which Debian has requested several times - we can't distribute them. I've started making Debian packages of the development releases of the base KDE packages. Is there anyone who's got some space on a fast FTP server where I can store them? Please contact [EMAIL PROTECTED],kde}.org. He has shown interest in keeping maintenance of .deb files for KDE and putting them on ftp.kde.org. Regards, Joey -- There are lies, statistics and benchmarks.
Re: perl version depends
Raphael Hertzog wrote: Le Thu, Oct 08, 1998 at 01:59:40AM +0200, Martin Schulze écrivait: Thus I believe it would need to use (= 5.005-0) (= 5.005) should work too, no ? Check out what dpkg thinks about it: finlandia!joey(tty5):/tmp dpkg --compare-versions 5.005 lt 5.005-1; echo $? 0 So, yes, it's also ok. (I thought that debian-devel had reached a consensous that it's not a good idea to change the perl version less than 14 days before the code freeze.) I don't know what debian-devel reached, but in fact it seems to me that just a few people are interested by perl. :-) Yes, but more people are interested in a broken perl subsystem. John Lapeyre has made a good summary of solutions available. In fact Perl5.005 is in unstable and some packages (like eperl) have already been updated and uploaded for using perl5.005. Before this screwup I didn't realize that most but not all modules are placed in /usr/lib/perl5/$version/$arch-linux/$dir while plain /usr/lib/per5 would be sufficient, too. We should have made it policy that modules have to omit the versioned directory where it is possible. Regards, Joey -- The only stupid question is the unasked one.
Re: perl version depends
Darren/Torin/Who Ever... wrote: Thus I believe it would need to use (= 5.005-0) But it would also have to use ( 5.006-0). I don't think this is a problem. (I thought that debian-devel had reached a consensous that it's not a good idea to change the perl version less than 14 days before the code freeze.) I didn't realize this. I saw the comment from Manoj but I also saw several others that said they wanted to see it. We can back out the release if need be. This should be done soon though. I'll still upload a new version tonight. Since the freeze is in 7 days and I don't believe that we can fix all incompatibilities wrt the new version of perl as well as re-compiling all perl packages *after* the main perl package has stabilized, I would like to go back to the old version of perl. My proposal with this version of perl was 7 more days ago. Read: we lost 7 days of integrating perl. Another solution would be a) to postpone the freeze for some time or b) allow fixed perl uploads within the freeze. Regards, Joey -- There are lies, statistics and benchmarks.
Re: Contacting authors
Alexander Koch wrote: On Thu, 8 October 1998 00:07:26 +0200, Martin Schulze wrote: Re spam: I'd like to make it optional so it does not have to be used but only should. Each pkg. maintainer could negotiate with the upstream author about this feature and not use it if the author doesn't like that. That's what I meant yesterday evening. If we ask and the author gives an ack, this is ok, but some will think of just spam and the like and deny this. We would have an incomplete package-base at authors.debian.org, then... Maybe make it different. I'd like get a way to contact the upstream authors without having to dig into the copyright file or even worse (when the maintainer forgot to mention his name plus email there) to dig into the source. Mainly I have the problem that I lose track of all the upstream authors of my own packges. I guess Joey has the same problem just by factor three. I could implement a local registry and implement it on my local system(s) so I'll have [EMAIL PROTECTED] but I thought more globally so other Debian maintainers could benefit from it, too. I'm open to good ideas. Regards, Joey -- The only stupid question is the unasked one. pgpzHrASJRKdO.pgp Description: PGP signature
Re: perl version depends
Michael Stone wrote: Quoting Martin Schulze ([EMAIL PROTECTED]): Before this screwup I didn't realize that most but not all modules are placed in /usr/lib/perl5/$version/$arch-linux/$dir while plain /usr/lib/per5 would be sufficient, too. We should have made it policy that modules have to omit the versioned directory where it is possible. Except that this isn't what's happening; the new perl is ignoring /usr/lib/perl5. (E.g., I couldn't install netstd the other day because That's the main cause of this thread... it couldn't find DebianNet.pm--which is in /usr/lib/perl5--until I put a symlink in /usr/lib/perl5/5.005. Can someone give a concise explanation of the rationale behind that? I can't but s/o said that PERL5LIB=/usr/lib/perl5 would help. I haven't tried. I have copied the missing modules into /usr/lib/perl5/5.005 since I had to put the machine back online *quick*. Regards, Joey -- The only stupid question is the unasked one.
Re: perl version depends
Richard Braakman wrote: Raphael Hertzog wrote: Le Thu, Oct 08, 1998 at 04:14:18AM +0200, Martin Schulze écrivait: Another solution would be a) to postpone the freeze for some time or b) allow fixed perl uploads within the freeze. b) would be fine for me. Because perl uploads will not introduce any security holes and because packages will only be modified in the sense that they will use a different directory. That only is a large source of packaging bugs. In fact, the (IMO) most annoying upgrade problem in hamm was a pathname problem: two packages had moved to a different directory at the last minute, and the auto upgrade script hadn't been modified to match. Speaking of the upgrade script, is there *any* reason why /pub/debian/dists/hamm/main/upgrade-i386/cd_autoup.sh still doesn't run and the fixed version is in /pub/debian/Incoming/upgrade-i386/cd_autoup.sh since Sep 5th? I think we should fall back on perl 5.004, and only move to 5.005 when there's a real plan for upgrading cleanly. Many core utilities rely When slink is released it's time to break sid. No problem with this. That's the usual way to switch to newer versions of programs. Regards, Joey -- The only stupid question is the unasked one.
Re: Squid2, how to handle incompatible upgrade
Miquel van Smoorenburg wrote: I'm currently maintaining squid, and squid-2.0 has been released. We have been running the beta versions on our own machines for quite some time and it's much better/faster than the 1.2 versions. However the problem is dat squid-2.0 is totally incompatible with squid-1.2. The cache directory and file format has changed, and the config file format has changed .. in fact it's a new package. How do I handle this? Should I just make a new package squid2 that conflicts with squid-1.2? I would'n't like to introduce a new set of packages. You should however ensure that the old configuration file is saved. Wrt. spool file: I believe that it is acceptable to blow the old spool away if the new squid gains more speed. If I do that, I have the problem that the squid source package creates 4 binary packages. Should I do a new upload of the latest squid-1.2 with only the squid .deb, and upload the rest with squid2? Depends on the purpose of the other packages... Regards, Joey -- The only stupid question is the unasked one.
Support for multiple CD's
I guess that we all have realized that slink doesn't fit on one CD anymore. Slink's total size for binary-i386 e.g. is 749 MB. Thus slink has to be splitted over two official cd roms. Currently slink doesn't contain an access method that can handle multiple cd roms if not all cd-roms are available at the same time. How are we going to handle this? I know that Heiko Schlittermann has developed a multi-cd package that provides a new access method for dselect but needs a patch for dpkg-scanpackages. Regards, Joey -- The only stupid question is the unasked one.
Re: Support for multiple CD's
Kenneth Scharf wrote: I installed a second CD rom drive in my computer. Some people have CD 'changers' that can have 3 - 5 disks in the stack. (Some of these take up several drive letters in windows/dos...do they appear as separate lun's in scsi or separate partitions under linux) Diffenrent media in CD changers would show up as different LUNs just like big cd jukeboxes. There should be support for prompting the user to swap disk. If there is more than one CD rom drive, then dpkg/dselect/apt/? should just go to the right disk (previously mounted). That's what multi-cd is doing. Or distribute on DVD rom and don't worry (till Debian grows to 4.7gb) Please go ahead, buy a writer and provide DVD images. :-) Regards, Joey -- The only stupid question is the unasked one.
Re: GTK Dselect - ALPHA 1
Tom Lees wrote: Wow, it looks nice. However I wonder why you changed the ordering of the two main windows. Regards, Joey PS: I also wonder if one may express wishlists. -- The only stupid question is the unasked one.
Re: Reverting to Perl 5.004
Darren Stalder wrote: I suspect that it's in the best interest of the freeze to revert to Perl Thanks. 5.004. I'm currently uploading the 5.004.04-6 release to master's Incoming. I'll file a bug on ftp.debian.org that the 5.005 release should be deleted and the 5.004 release installed. Maybe that's not needed since, right after s/unstable/frozen/ there will be a new unstable which is perfectly the correct place for the new perl package. Regards, Joey -- The only stupid question is the unasked one.
Re: Contacting authors
Ian Jackson wrote: Martin Schulze writes (Contacting authors): tonight I was thinking about implementing @authors.debian.org which would enable a way for us to get in touch with the upstream authors of some piece of software without the need of looking into the copyright file or digging in the source if the maintainer forgot to add the authors email into that file. What do you think about it? Example: [EMAIL PROTECTED] would redirect the mail to [EMAIL PROTECTED] who is the current developer of hypermail. I'm sorry to say that I think this is a bad idea. I think most authors wouldn't want to be contacted in this way - I know that I in my capacity as upstream author wouldn't. Making it easy to contact the upstream author(s) in this way will encourage our users to contact them directly, and many (most) of these messages will be about Debian-specific things. One of the main reasons we have package maintainers is to filter bogus mail, so that upstream authors don't get bombarded with questions and bug reports about Debian. How many maintainer are false contacted via the packages.debian.org mechanism? This mechanism was implemented a long time ago and I guess that it's even documented on the web somewhere. Thanks, and sorry to be negative, No problem. That's why I've asked. For me the question is not to do or not to do anymore but do it locally or let other maintainers benefit from it. Thus, a stop that is ok, too. You wouldn't want to implement any such mechanism? Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book
Re: The freeze and IMMINENT 2.2.0p1!!
[EMAIL PROTECTED] wrote: In light of the perl issues (see my last message) and the message Linus just sent off to linux-kernel about 2.1.125 and 2.2.0p1 could the freeze be pushed back a week to see if we should QUICKLY re-target slink towards 2.2.0? No, this would hold the release for at least two more months. . We have several kernel module package that need to be re-packaged. . We have to rework on the sound modules, possibly, I dunno. . We have to rework on the boot-floppies to cope with different and/or more modules etc. . We have to ensure that the new kernel headers won't infect various compilation of programs. . We might need to re-compile/re-package the libc. . We need to include new programs / packages to interfere with new kernel interfaces. . We need to review our documentation wrt the kernel (maybe, I duno) All this can't be done in 6 days. Linux 2.2 is a good candidate for the next unstable to play with. I believe that it will be fun, but I also forsee that there will be problems. I hope our release manager won't jump on that train too quick. Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book pgpCyzcO0yeu8.pgp Description: PGP signature
Re: Debian 3.0 and release goals
Please check out http://www.debian.org/~joey/goals/index.html or http://www.infodrom.north.de/~joey/Linux/Debian/master/goals/index.html Regards, Joey -- No question is too silly to ask, but, of course, some are too silly to answer. -- Perl book
Bug#27663: project: installing linuxconf on my maschine running Debian slink
reassign 27663 linuxconf thanks Runo Førrisdahl wrote: Farris: ~/install# dpkg -i linuxconf_1.10r34-1_i386.deb (Reading database ... 62852 files and directories currently installed.) Unpacking linuxconf (from linuxconf_1.10r34-1_i386.deb) ... dpkg: error processing linuxconf_1.10r34-1_i386.deb (--install): trying to overwrite `/etc/init.d/rc', which is also in package sysvinit dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: linuxconf_1.10r34-1_i386.deb This is a bug in linuxconf. If it also provides an init.d/rc method it has to use dpkg-divert (or update-alternatives, currently not supported). To the maintainer: Please take a look at the file-rc package which handles this situation well. Regards, Joey -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: PROPOSAL: one debian list for all porting efforts
Marcus Brinkmann wrote: Purpose of the list would be problems with porting to new architectures, either package specific or general. Problems with bootstrapping a new architecture. Cross compilation of Debian packages. Maybe setting up some documents or entries in the FAQ-O-MATIC. Do you think this list would be useful or that the already existing lists can carry the load (namely debian-devel)? This list is not needed and I don't consider it useful at all. Porting problems are arch-specific and thus should be discussed in that specific list. General questions (e.g. using -mbla with dpkg-genchanges) should be discussed on -devel. Regarding ports to new architectures one should look into the other lists, especially if parts of the architecture are similar. It would not make sense for porters to not only post their mail to the arch specific list but also to the -porters list. Regards, Joey -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: libgtk-dev and libgtk1.1-dev
Ben Gertzfield wrote: Ole Is there an easy way to have both libgtk-dev and Ole libgtk1.1-dev available? I have trouble with yagirc and Ole libgtk1.1. It compiles but I get a sigsegv when I try to run Ole it. I was hoping that linking with libgtk (stable) would fix Ole it, but I need gtk-1.1 for balsa. You cannot have libgtk-dev and libgtk1.1-dev installed at the same time, but you don't need to. gnotepad+ does not work with gtk 1.1 while many application that come with Debian are linked against 1.1. Thus you can't compile gnotepad+ on that machine. Regards, Joey PS: I compiled gnotepad+ on a 2nd machine with only gtk 1.0 and all id did was to segfault. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: libgtk-dev and libgtk1.1-dev
Ben Gertzfield wrote: Martin == Martin Schulze [EMAIL PROTECTED] writes: Ben You cannot have libgtk-dev and libgtk1.1-dev installed at the Ben same time, but you don't need to. Martin gnotepad+ does not work with gtk 1.1 while many Martin application that come with Debian are linked against 1.1. Martin Thus you can't compile gnotepad+ on that machine. Sure, but you can always remove libgtk1.1-dev and install libgtk-dev. Won't it hurt if I leave libgtk1.1 installed? Regards, Joey -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: libgtk-dev and libgtk1.1-dev
Ben Gertzfield wrote: Martin == Martin Schulze [EMAIL PROTECTED] writes: Martin gnotepad+ does not work with gtk 1.1 while many Martin application that come with Debian are linked against 1.1. Martin Thus you can't compile gnotepad+ on that machine. Ben Sure, but you can always remove libgtk1.1-dev and install Ben libgtk-dev. Martin Won't it hurt if I leave libgtk1.1 installed? No; that's like leaving libc5 and libc6 installed. It's no big deal. Hmm, so I have 1.1 installed as well as 1.0-dev. Now if I compile, I compile against 1.0. So it's dynamically linked against 1.0. But 1.0 is not installed and even conflicts with 1.1. Something's wrong here... Regards, Joey -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: libgtk-dev and libgtk1.1-dev
Ben Gertzfield wrote: Martin == Martin Schulze [EMAIL PROTECTED] writes: Martin Hmm, so I have 1.1 installed as well as 1.0-dev. Now if I Martin compile, I compile against 1.0. So it's dynamically Martin linked against 1.0. But 1.0 is not installed and even Martin conflicts with 1.1. libgtk 1.0 does not conflict with 1.1. libgtk-dev 1.0 does. You must have 1.0 installed to have 1.0-dev installed, so the complaint is kind of moot :) Sorry, I was theoretically blubbering. Thanks for the clarfication. Like I sais, something was wrong, my brain. Regards, Joey -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: KDE gone, Lyx next ?
Craig Sanders wrote: imo, we should grant Lyx the same courtesy we did KDE. send them a request to change their license, and give them some time (say a few weeks rather than the months that KDE got) to change. if they ignore the request or choose not to change their license then we have to yank the software. I wonder if you know that LyX is founded by the same person who has founded KDE some years later. Not that this has to imply anyghing... Regards, Joey -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: PROPOSAL: one debian list for all porting efforts
James Troup wrote:
Martin Schulze [EMAIL PROTECTED] writes:
Marcus Brinkmann wrote:
Do you think this list would be useful or that the already
existing lists can carry the load (namely debian-devel)?
This list is not needed and I don't consider it useful at all.
(As a porter) I disagree; I've often wanted to contact more than just
m68k porters, and short of cross-posting (aka spamming)
debian-{alpha,powerpc,sparc,(whatever other lists there are for the
newer ports)}, which are also user lists, I can't do that.
So you want to force all porters to join another list? Why not contact
them in their native lists?
Regards,
Joey
--
Beware of bugs in the above code; I have only proved it correct,
not tried it. -- Donald E. Knuth
gtop and slink?
Hi, I wonder if there will be a new gtop in slink now that it has been moved out of gnome-core (or another core Gnome module). Regards, Joey -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: 1st unpacking, 2nd dependency checking
Santiago Vila wrote: But occasionally I notices that dpkg first unpacks and installs the files in a particular package and checks dependencies afterwards. This means that wrong dependencies are discovered when it is too late since the old version of the package is already overwritten. The rationale is that this would make package installing too much troublesome, if not impossible in some cases. In particular, if A depends on B and B depends on A, you would be unable to install A and B at all. With the current design, you can. This should be resolveable in one dpkg run itself since it should be able to know which packages it's going to install. If both, A and B, are to be installed at the same time the issue is resolved. However, dselect calls dpkg with -iGROEB which could make it difficult to resolve this. Regards, Joey -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
[conrad@srl.caltech.edu: ANNOUNCE: Fulcrum scientific plotting tool update]
I wonder if somebody plans to package this one. Regards, Joey - Forwarded message from Conrad Steenberg [EMAIL PROTECTED] - Date: Fri, 9 Oct 1998 12:08:03 -0400 (EDT) From: Conrad Steenberg [EMAIL PROTECTED] X-URL: http://archive.redhat.com/gtk-list/ Subject: ANNOUNCE: Fulcrum scientific plotting tool update Fulcrum Scientific Analysis/Plotting Tool for Unix/GTK -- 9 October 1998 The fulcrum development team is pleased to announce the avalibility of a new snapshot. The fulcrum project aims to develop a useful, fast and full- featured scientific plotting and data analysis package under the GPL. The purpose of the snapshot release is to create interest in the projects and to attract potential co-developers. The new snapshot fulcrum-09.10.1998.tar.gz availible on http://www.srl.caltech.edu/srl/personnel/conrad.html. See also the screenshot on the same page. Changes include: o Added icons to the tree view. o Massive progess on the coordinate system/box object, with support for many different tick/tick label styles as well as logarithmic axes. o Added the xy line/scatter plot object. o Introduced data sharing between the GUI and the yorick interpreter. o As always some bug fixes. The screenshot shows three plots in the plot window, two of them containing lines of the form y=x^2 and y=x^3. The data for these plots was automatically generated by the yorick interpreter from instructions in the xy line/scatter plot object. This means you have full access to the functionality of yorick functions/packages, including standard math functions, numerical integration/differentiation, fft's, data cuts, matrix inversion, pde sololutions, 1D and 2D interpolation, ASCII/binary file I/O, reading FITS files, etc... To do: -- o After the xy plot object is finished, work will start on the more visible GUI elements of fulcrum, finally bringing it up to a usable state. o There are many more plot objects to be added, including histograms, vector fields, keys to plot objects, text and other geometric primitives. o Fulcrum will be GNOMEified once the basic functionality has reached a more stable state. Installation and usage instructions: 1. Installation Unpack the tarball fulcrum.tar.gz Type in './configure', the 'make'. If all goes well a binary named 'fulcrum' will be built in the Yorick subdirectory. To install, type 'make install' as root if you compiled the package to be installed in the system directories (the default is /usr/local) Run the binary Yorick/fulcrum and enjoy... or whatever you do when you see unfinished programs. 2. Usage The main window in divided into three parts, from left to right, the object tree display, which should show a document containing one page. The graph/spreadheet display, with a fractal C-curve in blue displayed. There is also a tab for the spreadsheet window. On the right hand side an interperter window should display the yorick copuright message and prompt. You can execute commands in the interpreter window. Try typing in the following commands: x=span(0,10,100) y=x^2 y The values of the array 'y' will now be displayed. For help on yorick, type in 'help'. There is a command history, accessed using the cursor up and down keys. 3. Copyright This code is released under the GNU General Public Licence version 2. The Yorick interperter falls under a more liberal BSD-style copyright, see the file COPYING.yorick for details. Conrad Steenberg *-* | Conrad Steenberg| | e-mail: [EMAIL PROTECTED] | | Tel: (626) 395-2965 Fax: (626) 449-8676 | *-* -- To unsubscribe: mail -s unsubscribe [EMAIL PROTECTED] /dev/null - End forwarded message - -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
[ettrich@troll.no: Live and let live]
I don't want to hide this mail from you. Regards, Joey - Forwarded message from Matthias Ettrich [EMAIL PROTECTED] - From: Matthias Ettrich [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Live and let live Date: Sat, 10 Oct 1998 18:43:07 +0200 Old-Return-Path: [EMAIL PROTECTED] X-Loop: [EMAIL PROTECTED] Let me summarize Debian's licensing problem without any pseudo-juridical nit-picking textual interpretations: a) It's ok for Debian to distribute KDE as a source package with an post-installation script that compiles and installs the stuff for the users. b) it's not ok, if Debian compiles the stuff before distribution and ships both the binary and the source code to make the installation process on the user's side faster. Although I have a rather bad opinion of the Debian guys, I just cannot believe that they are that irrational to claim that there is a significant, even ethical difference between both approaches. But following the recent discussion on our mailing lists I almost get the impression that some of them really believe what they are saying. Naa, that can't be true. The fact that Debian also removed the KDE libraries (that cleary are not covered by their GPL interpretation since they are not distributed under the terms of the GPL), showed their real intention. In case some Debian developers read this mailing list: Guys, you don't like KDE since it encourages people to write software for it. Therefore you don't want to distribute it. That's fine with me. I would never dare to spam your mailing lists for that reason. So please stop spamming our mailing list. I still wish you could say this in public (Bruce Perens did it, for example) without publishing licensing problems statements that insult their readers intelligence. Come on, the LInux world is large enough for both KDE and Debian. We let you work on your social mission, so please let us fullfil our mission to make Unix more friendly and powerful for users and application developers. DISCLAIMER: this is a statement of my own, not of the KDE project. Matthias - End forwarded message - -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: KDE gone, Lyx next ?
Joseph Carter wrote: I wonder if you know that LyX is founded by the same person who has founded KDE some years later. Not that this has to imply anyghing... It's irrelevant. Lyx is free code using a license that does not allow us to I know. But it may end up in the same flame fest However I don't hope so and since there are others who are actively developing LyX there is a little chance. Let's see what happens. link it with non-free code. We can't distribute it if they won't modify their license. But like KDE, they deserve a chance to do something about it. Of course, they deserve a chance to correct the license. I would be the last who would try to keep them from doing that. Regards, Joey -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: KDE gone, Lyx next ?
Joseph Carter wrote: On Sat, Oct 10, 1998 at 01:08:28PM +0200, Martin Schulze wrote: Craig Sanders wrote: imo, we should grant Lyx the same courtesy we did KDE. send them a request to change their license, and give them some time (say a few weeks rather than the months that KDE got) to change. if they ignore the request or choose not to change their license then we have to yank the software. I wonder if you know that LyX is founded by the same person who has founded KDE some years later. Not that this has to imply anyghing... It's irrelevant. Lyx is free code using a license that does not allow us to link it with non-free code. We can't distribute it if they won't modify their license. But like KDE, they deserve a chance to do something about it. That's what I feared. Bye-bye LyX. Matthias Ettrich wrote: From: Matthias Ettrich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: LICENSES [was: Re: Have you seen this?] Message-Id: [EMAIL PROTECTED] LyX is in contrib. I don't have it installed, but if it is licensed under the GPL, then you're probably right, and you're free to file a bug report against it. If you don't want to do so, then I'll check it out and file the bug report myself if needed. LyX is buggy, it has licensing problems (unless you compile it yourself). Yeah, file the bug report, highest priority level due to the ethical implications. Remove almost 4 years hard work of more than 20 people who offer the (right now) only usable free document processor for unix. Clearly LyX has been written by scratch but we in the LyX team accepted GPL'ed patches without signed written permissions of the authors to distribute binaries linked to XForms. Shame on us, not LyX has licensing problems! I will remove it from my hard disk immediately. Damn, four years hacking for me and a aresult it's no longer usable for Debian What a great day! Luckily I have an invitation for dinner to celebrate it :-) It's getting harder and harder to take Debian serious. Matthias Regards, Joey -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: Fix buildd@powerpc.debian.org bounces!
Guy Maor wrote: Message-Id: [EMAIL PROTECTED] Date: Sat, 10 Oct 1998 20:54:40 +0200 (CEST) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: mail failed, returning to sender |- Failed addresses follow: -| [EMAIL PROTECTED] ... transport smtp: 550 relaying to [EMAIL PROTECTED] prohibited by administrator |- Message text follows: | Received: at Infodrom Oldenburg (/\##/\ Smail-3.2.0.101 1997-Dec-17 #2) from master.debian.org by finlandia.Infodrom.North.DE via smail with smtp id [EMAIL PROTECTED] for unknown; Sat, 10 Oct 1998 20:54:36 +0200 (CEST) Received: from ([209.176.56.5]) by teergrube (10 sec delayed, relaying denied) Received: (qmail 19938 invoked by uid 878); 10 Oct 1998 18:54:34 - Date: 10 Oct 1998 18:54:34 - Message-ID: [EMAIL PROTECTED] From: Debian Installer [EMAIL PROTECTED] To: Debian/powerpc Build Daemon [EMAIL PROTECTED] Subject: xpuzzles_5.4.4-2_powerpc.changes INSTALLED [body not included] Args. I was told that this was fixed yesterday, so I didn't pay attention anymore. Apparently it was not. I apologize for my lack for administrator duties. I'm sorry, but people keep installing exim but forget about contacting me about it. I have now re-installed Smail since it's the MTA that causes least trouble and I'm able to configure it. It provides: . Local user delivery . Support for ~/.forward files . Support for real-user to bypass a .forward file . Localhost is localhost, tervola, tervola.infodrom.north.de and powerpc.debian.org . Outgoing mail is sent to a smarthost . Incoming mail is only accepted from the 0 MX machine. . Execution via inetd, limited by tcpd Please don't change it without notifying me. The same setup should be installed on kullervo. If not, I might get over and remove exim there in order to install Smail, too. Regards, Joey -- The good thing about standards is that there are so many to choose from. -- Andrew S. Tanenbaum
Re: Debian 3.0 and release goals
Hi Eloy! I wrote: Please check out http://www.debian.org/~joey/goals/index.html or http://www.infodrom.north.de/~joey/Linux/Debian/master/goals/index.html Since release goals were abandoned due to the hamm desaster no goals for slink were accepted. All listed goals on my page reflect wishes from various maintainers that were not abandoned. There were three important changes made after the hamm release: a) The releases will be incremental b) We won't have release goals anymore that may hold the release. c) Changing the libc will be smother than the bo-hamm transition Regards, Joey -- The good thing about standards is that there are so many to choose from. -- Andrew S. Tanenbaum
Re: [larsbj@ifi.uio.no: Re: copyright problem]
Michael Meskes wrote: On Sun, Oct 11, 1998 at 04:07:31PM +, Raja R Harinath wrote: I agree that by using XForms in development, and XForms *is* needed to compile and run LyX, we have implicitly allowd all users to link Lyx with XForms. I don't see how it follows. we have implicitly allowed all users to link LyX with XForms does not imply we have implicitly allowed (re)distribution of the resulting LyX binaries, which I guess is the issue at hand. I'm sorry, but for me this sounds like like nitpicking. But I try to solve this. Boy, I wonder how many problemes with licenses we will find if we examine all packages to that detail. A lot. Regards, Joey -- Linux - the choice of a GNU generation
Re: GNotepad
Ole J. Tetlie wrote: Is anyone packing gnotepad? [ Sorry if anyone tried to a post of mine and bounced. I played with exim.conf and forgot to unplay the rewrite. ] wget + ./configure + vi src/main.c + make just finished. It looks nice, it seems to work. We should include it. However if I push the exit button I get a Gdk segfault message. Regards, Joey -- Linux - the choice of a GNU generation
Re: Packages that disappeared
Michael Meskes wrote: xadmin Request by maintainer=author, iirc. x11amp-static mp3.8hz You didn't watch the 100 messages thread on debian-private? Regards, Joey -- Linux - the choice of a GNU generation
Re: problem with new icewm
Michael Meskes wrote: I installed both packages. After starting X I found that the old name is no longer the one compiled for gnome which removed all my applets from the panel. I changed my setup to call icewm-gnome instead and re-created my panels but had to notice that the panel applet no longer works. Not only does it not appear, but no applet added after it will appear. I've set up my panel without the pager again and it works fine but I'd like to get the pager back. Also I would prefer an alternative setup for these two packages with icewm-gnome getting the higher one. Or even divided into three: icewm-common, icewm-gnome, icewm-nognome. ^ This should be kept as `icewm' imho. Regards, Joey -- Linux - the choice of a GNU generation
Re: GNotepad
Ole J. Tetlie wrote: Is anyone packing gnotepad? [ Sorry if anyone tried to a post of mine and bounced. I played with exim.conf and forgot to unplay the rewrite. ] Since nobody stepped forward, I take it for now. It in the process of being built right now. Regards, Joey -- Linux - the choice of a GNU generation
Re: GNotepad
Michael Meskes wrote: On Mon, Oct 12, 1998 at 06:18:47PM +0200, Martin Schulze wrote: wget + ./configure + vi src/main.c + make just finished. It looks nice, it seems to work. We should include it. However if I push the exit button I get a Gdk segfault message. Please upload it. I'd like to get a look at it. Already done. I apologize but after three days of mainly sysklogd work I'd like to finish that one first. :-) It looks nice and I was already told that it is quite useable. And the author is also running Debian. Need more reasons? Regards, Joey -- Experience is a useful thing. Unfortunately it is only acquired just after one could have used it.
Re: KDE gone, Linux next ?
Matthew Parry wrote: I think a much more important implication of the KDE debacle is what problems the GPL might make now that Linus is allowing proprietary drivers to be loaded into the kernel. Isn't this effectively the same as linking against a library? Err. a) The free kernel links against a free driver or b) A non-free driver links against the free Kernel. Compared with the KDE debacle, Linux would be the library and the driver would be the program. For me it looks like the situation is exactly the other way round. Linus didn't put the whole kernel under the GPL. I'm sure that there is no restriction to binary-only-commercial drivers. And even if it isn't, what are we going to do if proprietary drivers become common? We'll have a main dist that is useless on a lot of computers. Maybe we're not able to distribute them. So what? People should instead buy hardware for which the specs are available. I think Debian should take a stand against proprietary drivers and only distribute kernels with the proprietary driver code removed. I mean people were worried about the proprietary QT Define proprietary driver code. becoming a standard on Linux - I think a much more worying prospect for Linux (and the free software community as a whole) is having Linux boxes that won't function *at all* without proprietary drivers! This won't be the case for regular machines. It might be the case for boxes that use crappy hardware where the manufacturer holds back the specs and doesn't allow development of free drivers. Regards, Joey -- Experience is a useful thing. Unfortunately it is only acquired just after one could have used it.
Re: New Debian maintainer Jakob Borg
Please ensure that it's not illegal to distribute replay. 8hz.mp3 was removed due to patent/license problems. Regards, Joey -- Experience is a useful thing. Unfortunately it is only acquired just after one could have used it.
Re: gtop
Michael Meskes wrote: Where is the gtop binary nowadays? It has been moved outside of gnome and has its own cvs directory. Unfortunately the new maintainer has problems compiling it so it's not likely to meet the freeze date. Regards, Joey -- Experience is a useful thing. Unfortunately it is only acquired just after one could have used it.
Re: Packages that disappeared
Joseph Carter wrote: On Tue, Oct 13, 1998 at 07:58:58AM +0200, Michael Meskes wrote: x11amp-static mp3.8hz You didn't watch the 100 messages thread on debian-private? I never got it. In fact I was surprised I didn't get a single mail on private for at least two months. Could anyone please check whether I'm still listed there? Not with *meskes*. Send a request to [EMAIL PROTECTED] Regards, Joey -- Experience is a useful thing. Unfortunately it is only acquired just after one could have used it.
