Re: Release-critical Bugreport for May 14, 2004

* Cord Beermann: > I added a temporary(?) fix, and bounced the latest report to the list. Thanks, but it ended up in the archive (under the URL ), but not in the inboxes of subscribers.

Re: SourceForge.net PR-Web Upgrade Notice.

* Luke Kenneth Casson Leighton: > i'm forwarding this to debian devel for people's attention because > it would appear that debian has lost a quite large opportunity - [...] I'm surprised SourceForge didn't switch to AIX. Really. (They didn't upgrade to Mailman 2.1, by the way. *sigh*)

Re: Bug#282688: RFP: autoconf-doc -- Documentation for autoconf, automatic configure script builder

* Ben Pfaff: > Sorry, I don't maintain non-free packages. In this case, please file an ITO bug for gnu-standards.

Re: Bug#284285: ITP: fairuce -- Spam filter based on sender identity verification

* Hamish Moffatt: >> FairUCE is a spam filter that prevents spam from reaching the >> recipient's inbox by verifying the identity of the sender. It will stop > > By what mechanism? According to the AlphaWorks article, it's mostly a challenge-response system which suppresses the C&R mechanism if s

Re: ITP: lapispuzzle.app -- almost a clone of Street Puzzle Fighter

* Gürkan Sengün: > * Package name: lapispuzzle.app > Version : 0.9.1 > Upstream Author : Banlu Kemiyatorn <[EMAIL PROTECTED]> > * URL : http://home.gna.org/garma/lapispuzzle/index.html > * License : GNU GPL > Description : almost a clone of Street Puzzle F

Re: Linux Core Consortium

* Bruce Perens: > The Linux Core Consortium would like to have Debian's involvement. This > organization has revived what I originally proposed to do as the LSB - > to make a binary base for Linux distributions that could be among > several distributions who would share in the effort of maintai

Re: Linux Core Consortium

* Michael Banck: > 2. GNOME succeeded for the desktop. Are there any proprietary COTS applications for GNOME where vendor support isn't bound to specific GNU/Linux distributions? Maybe GNOME is a good example of cross-vendor cooperation (but so is GCC), but would be quite surprised if this autom

Re: Linux Core Consortium

* Brian Nelson: > Anyone, developer or non-developer, can help fix toolchain problems. > However, the only people who can work on the testing-security > autobuilders are ... the security team and the ftp-masters? It's about infrastructure, so the security team is out (they are just users of this

Re: Linux Core Consortium

* Steve Langasek: > Um, what's the concrete use case for a cross-distro standard network > configuration interface? VPN software, intrusion detection systems, software for CALEA support, centralized management software.

Re: Are BLOBs source code?

* Bruce Perens: > That's why I say the BLOB should be in a file rather than the driver. The problem is that this introduces unnecessary complexity. If the blob is required for booting, it has to be put into the initial ramdisk anyway, and a fail to see a significant advantage over the compiled-

Re: Are BLOBs source code?

* Goswin von Brederlow: >>> That's why I say the BLOB should be in a file rather than the driver. >> >> The problem is that this introduces unnecessary complexity. If the >> blob is required for booting, it has to be put into the initial >> ramdisk anyway, and a fail to see a significant advanta

Re: Linux Core Consortium

* Michael Meskes: >> Instead, proprietary software vendors should ship all libraries in the >> versions they need, or link their software statically. I wouldn't > >>From a technical standpoint this may make sense, but not from the > commercial standpoint ISVs have to take. Building your own envir

Re: New stable version after Sarge

* Christoph Berg: > Re: Paul van der Vlis in <[EMAIL PROTECTED]> >> You will understand that my most important point is security-support. > > ...which Debian provides for its stable distribution at any time, even > if the last stable release was ages ago. Where is the security support for woody's

Re: New stable version after Sarge

* Joey Hess: > I think we've taken this "security bugs arn't fixed in testing as well > as in stable" thing as gospel a little too long without verifying it > lately. I've been checking and if testing is lagging stable at all, it's > doing so by a much smaller amount than we've traditionally thoug

Re: partial patches - server application

* Andreas Barth: > This means: If the local file dists/sid/main/binary-i386/Packages has > the sha1-sum of f3a0c1972021af11782c661d1bd5214f1d443868, take the patch > named 2005-01-04-1633.27 (and this patch has the given size and > sha1-sum). Of course, this patch is a gz'ed file. The Patches are

Re: partial patches - server application

* Andreas Barth: >> Is this really a good idea? patch invokes ed(1) to process ed >> scripts, and this might lead to execution of arbitrary commands. > > It is agreed that the usage of patch and ed is _not_ the recommended > way for production code (but acceptable for prototype code). However, as

Re: partial patches - server application

* Thiemo Seufer: > They can be cumulated, see > http://lists.debian.org/debian-devel/2004/12/msg00462.html This trick should work for RCS deltas as well. >> The output from "diff -f" is, > > I haven't found an -f option in diff. It's documented in the Info manual, and it's required by POSIX. Ha

Re: Question about GFDL

* Bernhard R. Link: > Consider next that this info file does not contain the advertised > section nor contains the GFDL at all. I think that's why there is a @copying directive in recent Texinfo versions. You could change the Texinfo source to use it.

Re: MPEG in general Was: Is anyone packaging `lame' ?

> Is only MPEG Layer III patent encumbered ? > How about the other MPEG stuff ? > I find it hard to believe that it is all patent-free. It's all encumbered with patents. Encoders *and* decoders.

Re: MPEG in general Was: Is anyone packaging `lame' ?

* David BalaÂic: > Florian Weimer wrote: >>>Is only MPEG Layer III patent encumbered ? >>>How about the other MPEG stuff ? >>>I find it hard to believe that it is all patent-free. >> It's all encumbered with patents. Encoders *and* decoders. > > Y

Re: New stable version after Sarge

* Thomas Zimmerman: > Is that really true? I would love to run "apt-get dist-upgrade" every > half a year. Currently it doesn't get me much. :) Now, for production > systems, don't you do some testing *before* you upgrade the OS? Testing costs time and therefore money. Debian's secret corporat

Re: Manpages licensed under GFDL without the license text included

* Bernhard R. Link: > Looking into sarge I found a number of manpages, that do not look > redistributeable as they are licensed under the G"F"DL but do not > include the full licence text needed to be distributeable. I think it's enough to add an additional notice stating that the named section i

Re: Manpages licensed under GFDL without the license text included

* Francesco Poli: > On Sun, 09 Jan 2005 15:39:47 +0100 Florian Weimer wrote: > >> I think it's enough to add an additional notice stating that the named >> section is reproduced in the gfdl(7) manpage, incorporated by >> reference. > > I doubt that this woul

Re: Bug#293167: ITP: request-tracker3.4 -- Extensible trouble-ticket tracking system

* Lars Wirzenius: > ti, 2005-02-01 kello 15:25 +, Stephen Quinney kirjoitti: >> This is the 3.4 series of RT, it can be installed alongside the 3.0 >> and 3.2 series without any problems. This release is a big >> improvement over previous versions and features many new features, >> substan

Re: Bug#293167: ITP: request-tracker3.4 -- Extensible trouble-ticket tracking system

* Matthew Palmer: > On Tue, Feb 01, 2005 at 06:27:30PM +0100, Florian Weimer wrote: >> * Lars Wirzenius: >> >> > ti, 2005-02-01 kello 15:25 +, Stephen Quinney kirjoitti: >> >> This is the 3.4 series of RT, it can be installed alongside the 3.0 >&g

Re: Bug#293167: ITP: request-tracker3.4 -- Extensible trouble-ticket tracking system

* Matthew Palmer: >> As a user, I think this is very convenient. The ability to switch >> back to a known-to-work version by tweaking a few configuration files >> is reassuring, even if you've tested the new software version on an >> indepedent machine. > > So archive bloat is not a problem for y

Re: About valid and invalid user names

* Marc Haber: > On Sat, 05 Feb 2005 17:21:28 +0100, Bernd Eckenfels > <[EMAIL PROTECTED]> wrote: >>Why not make it an configurable RE? > > I am quite reluctant with a so big change in a base package, ranking > at #1 in popcon, so soon before sarge release. The check is on a very common code path.

Re: About valid and invalid user names

* Marc Haber: > By default, adduser will verify the user against a configurable > regexp, default being the most conservative ^[a-z][a-z0-9\-]*$. The > --force-badname option will change the regexp to a hardcoded > ^[-\._A-Za-z0-9]*\$?$, allowing users to happily hang themselves. This > gives the

Re: RFC: graph of Debian package cycle

* martin f. krafft: > Based on the work of Kevin Mark (URL not available, sorry), I have > made a graph of the life cycle of a Debian package for inclusion in > my forthcoming book (http://debianbook.info). You can find the > sources and generated files at > > http://people.debian.org/~madduck/g

Re: /etc under svk

* Torsten Landschoff: > Wanted to do that - but! Does svk handle symlinks? Thinking of > /etc/rc?.d and /etc/alternatives... Wrote my own scripts to handle svn > for /etc but they are still quite hackish... Subversion 1.1 and svk 0.18 both support symlinks natively. -- To UNSUBSCRIBE, email to

Re: Request for Help: apt 0.6

* Henrique de Moraes Holschuh: > You still need to deal with key revocation and a new key being needed, > anyway. Yearly changes will not make it more difficult, it will make sure > those codepaths are tested (and used at least once an year). Right now, it's not codepaths, but system administrat

Re: Request for Help: apt 0.6

* Martin Schulze: > Even though this will probably work well on a small scale, it won't on > a large scale. Just think about the installations of 500 or 1000 > Debian machines that also have security support. This is not > hypothetical. These installations do exist. You don't want to > install

Re: /etc under svk

* Marc Haber: > Also, the repository needs to be protected as /etc itself is, as it > contains passwords and other system confidential data. Well, typically you wont store such files in the repository because it makes automatically generated commit messages too sensitive to be sent by email. --

Re: /etc under svk

* Marc Haber: > Handling a directory with _some_ files under version control and > others not is a pain, even with subversion. I disagree. I do it all the time, especially for classical SCM tasks (software development). Most systems support this reasonably well, only old tla versions were a rea

Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

* Blunt Jackson: > Taking Exim as an *example* of this, when I installed Exim, and ran > into some problems configuring it the way I wanted, comparing the > application documentation on the Exim website with what apt-get > installed I found it utterly different. Just because the configuration fil

Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

* Marc Haber: > Is it really necessary to take our internal issues to upstream's > mailing lists? Can't we have internal flamage internally? Well, from time to time, many of us have an urgent desire to inflict harm on the project. Maybe this was just one of the usual excesses? I don't know. The

Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

* Steve Greenland: > And yes, it does belong there. It could easily add the something like: > >The single monolithic file is the normal upstream configuration, >while the other choice is a Debian innovation that works better with >large installations or ISPs needing to support many vir

APT 0.6 migration -- first status report

Hi, this message contains the first status report about the APT 0.6 migration. From time to time, I'll post such reports to debian-devel. * Status pages I maintain status pages at: Please have a look at this document, especially at the showstopp

Re: Statically linked binaries from fpc

* Roland Stigge: > Unfortunately, fpc in Debian produces statically linked binaries, due to > the Pascal unit style library files. We currently don't have other > packages in the archive that Build-Depend on fp-compiler (except fpc > itself which indeed carries statically linked binaries) as examp

Re: fftw3 non-pic k7 optimisations

* Paul Brossier: > Two questions: > - can anyone spot what in these codelets causes the non-pic ? Tables of constants are addressed directly, not in some IP-relative way. > - how much can it hurt to have this non-pic in fftw3 ? It shouldn't matter much if all PIC code is grouped together in t

Re: combining fakeroot and distcc/SSH

* martin f. krafft: > Has anyone else run into this problem? How could I work around it? "unset LD_PRELOAD" and a wrapper script works with current fakeroot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: fftw3 non-pic k7 optimisations

* Paul Brossier: >> Why do you insist to have that code be position-independant ? > > I could say because it is a 'must' in the debian policy, but... There is no such requirement in the Policy. 8-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact

Re: fftw3 non-pic k7 optimisations

* Henrique de Moraes Holschuh: > Just a small question: does the system KNOW an object compiled with > -fPIC but which contains non-PIC code must be treated as a non-PIC > object? On x86, the dynamic linker can perform the necessary relocations when a DSO is loaded which contains position-depende

Re: Bits (Nybbles?) from the Vancouver release team meeting

* Steve Langasek: > We project that applying these rules for etch will reduce the set of > candidate architectures from 11 to approximately 4 (i386, powerpc, ia64 > and amd64 -- which will be added after sarge's release when mirror space > is freed up by moving the other architectures to scc.debia

Re: Required firewall support

* Marc Haber: > I am routinely running systems without any packet filtering capability > on the network, and they are perfectly able to cope. They just only > accept network connections for needed services. This is a bit dangerous because any invocation of "apt-get install" or "apt-get upgrade" c

Re: Uploading amd64 packages

* Jérôme Marant: > Is it currently possible to upload amd64 packages to ftp-master? amd64 is not yet part of the archive. It depends on the so-called "mirror split".

Re: Uploading amd64 packages

* Jérôme Marant: > Quoting Florian Weimer <[EMAIL PROTECTED]>: > >> * Jérôme Marant: >> >> > Is it currently possible to upload amd64 packages to ftp-master? >> >> amd64 is not yet part of the archive. It depends on the so-called >> "mirr

Re: g++/stl -frepo problem?

* Steinar H. Gunderson: > -frepo is an optimization switch, designed to avoid multiple instantiations > of the same template (reducing its size). You should be able to compile just > fine without it, but your binaries will be bigger. Thanks to the .gnu.linkonce sections, the finaly binary should

Re: My IP address seems listed as a spammer address by bugs.debian.org

* Christian Perrier: > Is there something I can do for getting my address unlisted (apart > from again reducing the load I put on b.d.o...which I did again down > to the lowest acceptable refresh rate on my side)? There is a BTS mirror on merkel. Maybe you could mirror the bug reports you are in

Re: I am still on the keyring. With my old key.

* Andreas Schuldei: > i have not given up that hope yet and i invest a considerable > amount of time working on this issue as part of my work on the > DPL-Team. others there do so, too. Is this the "delegation to teams" item on ? A rather cryptic refe

Re: dpkg-sig support wanted?

* Marc Brockschmidt: > Today (or last night, whatever), the dak installation on ftp-master was > changed to not accept packages that include more than 3 parts, which are > usually the binary version and the compressed control and data > tarballs. This means that signed binary packages are rejected

Re: dpkg-sig support wanted?

* Anthony Towns: > Personally, I think it's cryptographic snake oil, at least in so far > as it relates to Debian. I remain interested in seeing any realistic > demonstration of how a Debian user could reasonably rely on them for > any practical assurance. The assurance doesn't come from the sign

Re: dpkg-sig support wanted?

* Anthony Towns: > (I'm amazed the security "crisis" we're having is about deb sigs > *again*, when we're still relying on md5sum which has a public exploit > available now...) These exploits are irrelevant as far as the Debian archive is concerned. (And that's not because hardly any sarge user

Re: dpkg-sig support wanted?

* Anthony Towns: > On Fri, Nov 25, 2005 at 07:59:40PM +0100, Florian Weimer wrote: >> * Anthony Towns: >> > (I'm amazed the security "crisis" we're having is about deb sigs >> > *again*, when we're still relying on md5sum which has a public

Re: dpkg-sig support wanted?

* Thiemo Seufer: >> A: Why do you lock your car up[1]? >> >> B: Because it looks like having it locked is better then not having it >> locked. >> >> A: Sorry, but that's a snake oil rationale. Anybody can pick the lock >> and break in. Anybody can smash a window and break in. etc. > > Wrong, it

Re: dpkg-sig support wanted?

* Henning Makholm: > Scripsit Peter Samuelson <[EMAIL PROTECTED]> > >> You may laugh if you wish, but I think it's annoying to have to move to >> a hash function whose hexadecimal representation takes 64 bytes, which >> doesn't leave much room on an 80-column line to describe what the hash >> is h

master mail problems -- help needed

>From time to time, master seems to bounce mail routed to mail.enyo.de with the following error message: [EMAIL PROTECTED] retry time not reached for any host after a long failure period Is anybody experiencing a similar problem? I tried to debug it myself, using the information I could ac

Re: dpkg-sig support wanted?

* Steinar H. Gunderson: > On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote: >> So? If SHA256 is so much better, why is that nobody can prove it, or >> at least can provide some evidence which supports that claim? "The >> numbers are bigger" is

Re: dpkg-sig support wanted?

* Henning Makholm: >> I wouldn't use real base64, though, because it would mean that you can >> use its hashed output as a file name. > > Good point. One might replace "/" with "_" and omit the final "=". > Having a "+" in the hash should be safe in most contexts. It should be replaced with "-".

Re: master mail problems -- help needed

* Stephen Gran: > Once you know the retry rules, try > /usr/sbin/exinext [EMAIL PROTECTED] > > That will tell you what's recorded in the retry database currently. exinext ist not SUID, and I haven't got sufficient permission on master to access the retry database: [pid 29063] open("/var/spool/e

Re: master mail problems -- help needed

* Jeroen van Wolffelaar: >> I tried to debug it myself, using the information I could access on >> master, but I couldn't gather enough evidence to present to the >> postmasters so far. > > But other DD's can also only do a limited amount of research, the only > way to really find out is asking a

Re: master mail problems -- help needed

* Stephen Gran: >> It probably makes sense to disable IPv6 support in Exim on master, >> independently of my current problem. I'm going to suggest this to >> postmaster@ once I figured out a good way to implement this. > > I doubt that's the problem. This is from my logs: > > 2005-08-10 13:33:46

Re: dpkg-sig support wanted?

* Adeodato Simó: > * Florian Weimer [Thu, 24 Nov 2005 18:28:04 +0100]: > > Hi, > >> AFAIK, binary NMus aren't announced on debian-devel-changes. > > Binary-only uploads are announced in the appropriate > debian-devel-$ARCH-changes list. According to <ht

Re: master mail problems -- help needed

* Stephen Gran: > No noticable time difference between the two, either. So, I don't > think this is the real problem. You could be right. The problem is still present, unfortunately. One more data point: A couple of seconds before the last bounce was generated, murphy (which is on the same ne

Re: dpkg-sig support wanted?

* Anthony Towns: > On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote: >> For the "exploits" we have seen so far to work, the malicious party >> needs upload access to the archive and has to plant a specially >> crafted package there, for which

Re: dpkg-sig support wanted?

* Jochen Voss: > On Tue, Nov 29, 2005 at 02:08:45PM +0100, Goswin von Brederlow wrote: >> According to slashdot articles you can generate human readable files >> (like the Packages file) with md5sum collision in ~45minutes on a >> modern cpu now. > I found the example at http://www.cits.rub.de/MD

Re: Best tool for patch update use case?

> What tool do you think is the easiest to perform this task? In the Debian context, most developers who maintain individual patches use dpatch. quilt is a similar tool. There's also Chris Mason's mq extension for Mercurial, and Stacked GIT, but these haven't been packaged for Debian yet. --

Re: dpkg-sig support wanted?

* Henning Makholm: > Scripsit Florian Weimer <[EMAIL PROTECTED]> >> * Jochen Voss: > >>> I found the example at http://www.cits.rub.de/MD5Collisions/ quite >>> impressive. They have two different valid PostScript files with >>> identical MD5 sums. I

Re: Best tool for patch update use case?

> I was really asking for a GUI tool that allows me to update the current > patches, one by one, to the current upstream sources, going through > each patch chunk and letting me update the chunk if it doesn't apply > correctly. Ah, something like an interactive three-way merge? ediff, kdiff3 and

Re: sarge uninstallable !?!

* A. Mennucc: > in both cases, the first part of the install was OK, but, after > reboot, when APT was called to upgrade the system, it stopped > claiming: > E: This installation run will require temporarily removing the essential > package e2fsprogs due to a Conflicts/Pre-Depends loop. This is

Re: master's mail backlog and upgrade time

> On Thu, Nov 24, 2005 at 06:45:58PM +, Ian Jackson wrote: >> So the best idea is indeed for >> downstream systems to have policies which are no more strict than >> upstream systems. > > Would it be possible for master to make call-outs to chiark ? > would that solve the problem ? I don't thin

Re: *** POKED TIMER ***

* Marc Haber: > May I ask why you pollute the general development mailing list for > that? The comment in the code is: /* * This is a temporary (probably) hack to fix a bug on tru64 5.1 * and 5.1a. Sometimes, pthread_cond_timedwait() doesn't actually * return

Re: master mail problems -- help needed

* Lionel Elie Mamane: > On Thu, Dec 08, 2005 at 09:30:52PM +0100, Wouter Verhelst wrote: > >> The fact that my primary MX is only available through IPv6, and that >> this is the case for other people who're having problems too might >> then be a better chance at being the problem. > > My primary M

Re: master mail problems -- help needed

* Lionel Elie Mamane: >> You also have one IPv4-only MX, > > No, I don't. But Exim 4 thinks so: [EMAIL PROTECTED] router = dnslookup, transport = remote_smtp host capsaicin.mamane.lu [2001:888:19f0::2] MX=9 host capsaicin.mamane.lu [2001:888:19f0:2::2] MX=

Re: FYI, current mirror sizes

* Goswin von Brederlow: > Mirror size per arch (in MiB): > > | sarge | etch | sid | all > -+---+--+---+--- > source | 9339 | 9419 | 11495 | 30252 This looks suspicious. I expected that the total number would be significantly less than the sum of the suites

Re: Size matters. Debian binary package stats

* Steinar H. Gunderson: > My comments are about the same as on IRC: > > - Disk space is cheap, bandwidth is cheap. Depends. Decent IP service costs a few EUR per gigabyte in most parts of the world. > Thus, anything sacrificing lots of human power and CPU power to save on disk > or bandwidth

Re: Size matters. Debian binary package stats

* Andreas Metzler: > Afaict from the webpage 7zip (LZMA) is quite a bit slower bzip2. - > Have you perhaps run some benchmarks? Memory use during decompression would be interesting, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROT

Re: Size matters. Debian binary package stats

* Michelle Konzack: > Am 2005-12-19 09:56:27, schrieb Olaf van der Spek: > >> Are you paying > 10 $/gb? >> Where is it that expensive? > > I pay 450.000 DHs (around 57.000 US$) in Morocco > for an E3 (34 MBit) with traffic included. With traffic included? How's that more than 10$ per gigabyte tr

Re: spohr.debian.org not sending email

* Anand Kumria: > Please take a look at see what is happening for the domains: > progsoc.uts.edu.au and progsoc.org Might yet another instance of master's mail problems. See the thread on -devel, and the one on exim-users ("Potential logic error in retry handling for IPv4+IPv6 hosts"). Short su

Re: Size matters. Debian binary package stats

* Michelle Konzack: > Am 2005-12-22 16:04:45, schrieb Florian Weimer: > >> With traffic included? How's that more than 10$ per gigabyte >> transferred and month? 8-) > > IF you can reach 34 Mbit! > > My old colo E3 at UUnet in Kehl/Germany wa

Re: Size matters. Debian binary package stats

* Michelle Konzack: > Because we do not get 34 MBit and we have not a netload > of 100% 24/7 the price per GByte is around 50 US$/GByte. This means you still have plenty capacity you've already paid for, supporting Steinar's claim that bandwidth is cheap. Just think about it. 8-) -- To UNSUBS

Re: spohr.debian.org not sending email

* Ryan Murray: > On Tue, Dec 27, 2005 at 03:45:26PM +1100, Anand Kumria wrote: >> There seems to be a problem, localised to spohr, with the sending of >> emails. I've uploaded some packages recently and have neither received > > The problem is on your end -- mail to these MXs is being 451'd, and >

Re: APT public key updates?

* Michael Vogt: > Sorry for the delay. I'm preparing a new upload that adds the 2006 > archive key to the default keyring. Please try to get a new self-signature without an expiration data first. If they key is compromised, it has to be (manually) revoked anyway. Rotating it once per year doesn

Re: APT public key updates?

* Bernd Eckenfels: >> IOW using the old key to sign the new key only requires that the old >> key be "good" at one point during the new year, whereas continuing to >> use the old key requires that it be "good" all year. > > Yes, but it breaks a long term usage like web of trust. The Debian archiv

Re: APT public key updates?

* Steve Langasek: > For a user with a compromised local network, the only safe solution is to > validate the new key via some web of trust. No, the web of trust doesn't solve the problem. I'm pretty sure most DDs don't even know who is authorized to issue a new archive key. A user has no way to

Re: APT public key updates?

* Steve Langasek: > I would encourage you to log into merkel and verify, directly and > securely, the key at /org/ftp.debian.org/web/ziyi_key_2006.asc; sign it; and > upload your signature to the public keyservers as well, if you are satisfied > that this is the key that is being used on ftp-maste

Re: APT public key updates?

* Bernd Eckenfels: > Paul TBBle Hampson <[EMAIL PROTECTED]> wrote: >> Maybe the one-true-stable-key idea is the way to go after all... > > One key by distribution? If this means one key per suite (sarge, etch, ...), and no yearly key rollover, I agree. 8-) -- To UNSUBSCRIBE, email to [EMAIL PR

Re: Need for launchpad

* Russ Allbery: > Debian isn't perfect at this. There are portions of the Debian > infrastructure where the exact version that Debian is running are not > necessarily available. However, these are generally considered within the > project to be anomolies and Debian *does* have a general committm

Re: How to debug - apachetop

* Alejandro Bonilla: > I want to learn how to debug and see what went wrong. How can I > learn to debug this kind of things or how can I enable some > debugging for this kind of things? valgrind is quite helpful for debugging such problems related to memory-management. You could also have a look

Re: Development standards for unstable

* Anthony Towns: > If you'd like to make suggestions about ideas that would be useful, What about: stop threatening your fellow developers? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: For those who care about their packages in Ubuntu

* Raphael Hertzog: > I believe Ubuntu fills an important gap in the Debian world and as such > I'm not satisfied when Ubuntu is diverging too much from Debian, and the > only way to avoid divergence is to merge back what's useful and to provide > better solution for derivatives when there's a need

Re: Development standards for unstable

* Thomas Viehmann: > I think that not shipping unmaintained and unsupported packages is a > benefit. Packages need a maintainer to enter, I think they should need > one to stay. A real problem is that willingness to maintain a package in unstable is not as good a predictor as you might think for

Re: Debian derivatives and the Maintainer: field (again)

* Matt Zimmerman: > It is important, in particular, to account for the fact that Ubuntu is not > the only Debian derivative, and that proposals like yours would amount to > Debian derivatives being obliged to fork *every source package in Debian* > for the sake of changing a few lines of text. Su

Re: Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer

* Josselin Mouette: > We are talking about a MP3 *decoding* plugin. Like the ones we > already have in so many packages we have stopped counting. Just to clarify since you put that emphasis on decoding: There is no difference between decoders and encoders. Both require patent licenses. There a

Re: when and why did python(-minimal) become essential?

* Matt Zimmerman: > One of the appealing things about the Python language is their "batteries > included" philosophy: users can assume that the standard library is > available, documentation and examples are written to the full API, etc. Would this really be a problem if the minimal Python implem

Re: The Debian community should influence the next Haskell language standard

* Isaac Jones: > I'd like to ask the Debian community to look at Haskell98 and some of > the "research" extensions[2] and give us some input as to what would > make Haskell more attractive to you. Uhm, most of the things on Debian's (as opposed to individual developer's) whishlist are quality-of-

Re: Provides: scheme-interpreter

* Chad Walstrom: > I'm trying to package up tex2page and noticed that there is no virtual > package for scheme-interpreter. I would like to specify in the > "Depends:" that some sort of scheme-interpreter is required instead of > having to list each of them individually. > > Any thoughts on this

Re: Provides: scheme-interpreter

* Joe Smith: > http://people.debian.org/~forcer/debian-scheme-policy/debian-scheme-policy.html/ > > Which may be an unofficial policy mandates certain symlinks managed > by alternatives to scheme interpreters based on what they > support. The virtual package names have been accepted by consensus >

Re: Bug#353381: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system

* Russ Allbery: > Your points about sync(8) and tzselect(8) seem reasonable on the surface, > but the rest of this seems to be disregarding the fact that manpages and > manpages-dev are not native packages. Those man pages are included in > that package because they're maintained together upstrea

Re: Bug#353381: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system

* David Weinehall: >> Upstream includes non-free manpages these days, so in reality, we have >> already forked. Further Debian-specific changes are needed to address >> bugs such as #295211 (upstream does not document our libc/kernel >> combination). > > What manpages in upstream are non-free? D

  1   2   3   4   5   6   7   8   >