Re: RFC, problem with g++4

* Antti-Juhani Kaijanaho: > The anon enumeration trick has been an established C++ idom for years > (ISTR, but cannot check now, even Stroustrup himself advocating it). This was once desirable because you couldn't declare real constants in classes. Today, template struct Foo { static

Re: Work-needing packages report for Jul 29, 2005

* > The following packages have been given up for adoption: > >compiler (#319801), offered 4 days ago > >eli (#319463), offered 6 days ago > Description: compiler construction kit > Reverse Depends: eli-xtools eli > >lincvs (#319461), offered 6 days ago (non-free) > Descr

Re: Documentation of alioth?

* Raphael Hertzog: > Now haydn is running sarge so it's relatively easy to duplicate alioth > on a local (virtual) machine (before the mixture of woody/sarge was > suboptimal). You have the sources and the packages running on alioth... > you can provide patches that apply to Alioth's version of gf

Re: Problemes with the debian archives or apt?

* Klaus Ethgen: > I notive that for about a week there is NO package upgrade in sid. This > is realy unusual. A server at the heart of the archive update process has been relocated. It is expected that this work has been completed (see debian-devel-announce), so regular development should contin

Re: Xorg packages

* Mark Sutton: > It seems most of the 6.8.2.dfsg.1-4 packages, > while listed in Packages are not in the pool. > Well not on mirrors.kernel.org anyway. > > Is there a better/more up to date mirror? This is probably yet another result of the ftp-master outage. There are reports the machine was sh

Re: Testing requirements stalled

* Lars Wirzenius: > The fact that ftp-master.d.o is moving has been announced on the list > that all developers are required to read: debian-devel-announce. The message announces machine outages, not service outages. If you are not intimately familiar with Debian's infrastructure, it's just a gu

Re: http://torrents.debian.org -- idea

* Mick Weiss: > What do you guys think? The concern that is usually voiced by traditional mirror operators is that trackers and seeders are hard to maintain because BitTorrent is not really amenable to scripting. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Tr

Re: ftp-master.d.o, db.d.o down due to relocation

* James Troup: > As previously mentioned[1], newraff and newsamosa have lost their > existing hosting and are being relocated. Is newsamosa the primary NS for debian.org, as the SOA record suggests? In this case, the debian.org zone could vanish from the secondaries (and thus from the entire net

Re: libcrypto++

l not finish after reasonable time as a result. This means that I'm probably not able to test my patch, which is included below. Sun Jul 24 12:05:11 CEST 2005 Florian Weimer <[EMAIL PROTECTED]> * Make template instantiation compatible with GCC 4.0 This patch is a kludge, but

Re: libcrypto++

* Florian Weimer: > * Nathanael Nerode: > >> I'd be interested in working on tracking down the linking problems, but I >> don't want to duplicate your work. Are your patches-so-far available >> somewhere? > > I think I've found the linking bug.

Re: libcrypto++

* Nathanael Nerode: > I'd be interested in working on tracking down the linking problems, but I > don't want to duplicate your work. Are your patches-so-far available > somewhere? I think I've found the linking bug. Details later. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subjec

Re: The BTS and bug subscriptions

* Petter Reinholdtsen: > [Florian Weimer] >> Developers must be careful to Cc: the submitters, otherwise they >> probably never receive the message. > > What about the [EMAIL PROTECTED] address? It's an alias for the email address of the submitter. AFAICS, messages to

Re: The BTS and bug subscriptions

* Don Armstrong: > No, it wouldn't. The messages are only sent to people after they have > made it through the spam filters, and for sumitter, it's even more > difficult, because the message must be formatted properly to actually > generate a new bug instead of an error. > > The idea was for the s

Re: The BTS and bug subscriptions

* Jochen Voss: > Hi Goswin, > > On Sat, Jul 23, 2005 at 01:55:19AM +0200, Goswin von Brederlow wrote: >> subscribing [the initial submitter] is already the current way. > Really? Since when is this the case? Just to stress Jochen's point: only closing a bug report automatically triggers mail to

Re: The BTS and bug subscriptions

* Goswin von Brederlow: >> What has actually been discussed is automatically subscribing >> submitters to the bug report unless some special header/pseudo-header >> is added to prevent that. [It's possible that this subscription would >> happen without even needing to confirm the subscription... b

Re: congratulations to the X team!!

* David Nusinow: > I'm mainly depressed that people aren't reading Planet Debian, or are just > ignoring it. Is there a better place to post this sort of thing so that > users don't keep repeating the same non-bug? The BTS obviously isn't > working for us here either, nor is posting to debian-x.

Re: congratulations to the X team!!

* Steve Langasek: > Why do people think that xorg broke library dependencies for our > entertainment, and that patching over the dependencies is an ok > solution? Because there was no recent announcement on debian-devel-announce which provided some guidance for this transition? The packaging its

Re: no time for all debian tasks was: interacting with the press

* Olaf van der Spek: >> First of all, in my opinion your mail never should have gone to -devel, >> but only to Martin Schulze and maybe to Branden Robinson. > > Why can't this be discussed in public? There are probably more people > concerned about this then only him. It's considered bad style to

Re: congratulations to the X team!!

* Francesco P. Lovergine: > Me too, at least on this machine I had to explicitly install > xserver-xorg to complete the move. BTW, I see the rendering of some ttf > fonts looks not so good. For instance I used happily this resource: > > XTerm*Font: -monotype-andale mono-medium-r-normal--15-0-0-0-c

Re: Lintian test case author needed (zlib linking)

As requested by Marc Brockschmidt, this is now Bug#318104. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Lintian test case author needed (zlib linking)

I'd like to encourage someone who has experience writing test cases for Lintian to create a new one. It should scan .deb files for ELF object files which match one of the following Perl regexps: /inflate ([0-9][ 0-9a-zA-Z.\-]{1,100}[0-9a-zA-Z.\-])/ /deflate ([0-9][ 0-9a-zA-Z.\-]{1,100}[0-9a-z

Re: interacting with the press

* Anand Kumria: > [1]: http://smh.com.au/news/breaking/debian-debates-support-for-ports/2005/07/12/1120934228145.html> Apparently, this is subscription only. 8-( Has this article been republished by another newspaper with less tight access controls? -- To UNSUBSCRIBE, email to [EMAIL PROTECT

Re: Documentation of alioth?

* Marc Haber: >>I never said we were perfect. But alioth is not "unmaintained". > > A project which leaves bug reports completely uncommented (and > unfixed) for three months is unmaintained. Not necessarily. It's very poor communication, and a huge problem. But without inside knowledge, you can

Re: GCC 4.0 as the default GCC / C++ ABI change

* Olaf van der Spek: >> I don't know if it's related, but roughly since the GCC 4.0 upload, I >> get strange assembler warnings for perfectly valid C++ programs: > > I got them too but it seems they're now 'fixed' in unstable. Seems to be the case, thanks. -- To UNSUBSCRIBE, email to [EMAIL PR

Re: GCC 4.0 as the default GCC / C++ ABI change

* Matthias Klose: > With today's dinstall run, new gcc/g++ packages are entering the > archives and GCC 4.0 is the default gcc/g++. Starting from now, please > DON'T upload any C++ code, which build-depends on a library written in > C++ that is not yet converted to the new C++ ABI. Details for th

Re: Greylisting for @debian.org email, please

* Elie Rosenblum: > On Fri, Jun 17, 2005 at 07:41:04AM +0200, Florian Weimer wrote: >> * Wouter Verhelst: >> >> > What's painful about it? >> >> I wouldn't be surprised if it already increases load on >> lists.debian.org significantly. >

Re: HashKnownHosts

* Wouter Verhelst: >> > -- and relying on other people's security to increase your own isn't >> > pretty clever, actually. >> >> Currently, it's the foundation of Internet security, I'm afraid. > > Well, then the 'foundation of Internet security' is very weak, I'm > afraid. It is. > It's plain

Re: [Debian-uk] Sun have (probably) patented apt-get

* Turbo Fredriksson: > YEARS (!) ago I wrote the script that did the pre-upgrades to 'bo' (I _think_ > it was to 'bo' any way :). It basically only ftp'd (or was it wget?) > required packages from the Debian GNU/Linux FTP site(s), installed them > and then allowed the user/admin to continue with t

Re: spohr on spamcop

> spohr is listed on spamcop. > > http://www.senderbase.org/?searchBy=ipaddress&sb=1&searchString=140.211.166.43&showRBL=1 > > Is there a better way to do this ? This is completely expected because of the way the Spamcop blacklist is operated: It is maintained by the same stupid users that reguarl

Re: HashKnownHosts

* Colin Watson: > That's true. You can add them by hand without hashing the host name (and > use 'ssh-keygen -H' afterwards if you like); known_hosts may contain a > mix of hashed and unhashed host names. > > Is this a feature you would use often? It might be practical for those of us who copy SS

Re: HashKnownHosts

* Colin Watson: > On Sat, Jul 02, 2005 at 09:04:18PM +0200, Florian Weimer wrote: >> * Wouter Verhelst: >> > Some of us actually do care what is listed in that file, and edit it >> > from time to time. Hashing those names makes that much harder >> >> T

Re: HashKnownHosts

* Wouter Verhelst: > Some of us actually do care what is listed in that file, and edit it > from time to time. Hashing those names makes that much harder There should be tools supporting this, I agree. > -- and relying on other people's security to increase your own isn't > pretty clever, actual

Re: HashKnownHosts

* Marco d'Itri: > On Jul 02, Florian Weimer <[EMAIL PROTECTED]> wrote: > >> > What is the rationale for changing the default setting? >> Reducing wormability. I think it's a pretty clever change. > This is not what I asked, I know what this option is for.

Re: HashKnownHosts

* Marco d'Itri: > What is the rationale for changing the default setting? Reducing wormability. I think it's a pretty clever change. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TODO for etch ?

* Olaf van der Spek: >> You should set the clock using NTP *before* starting any daemons. >> Most daemons don't use monotonic clocks (I'm not even sure if Linux >> supports them at the required level), and some of them fail in strange >> ways if the system clock warps. > > Doesn't Linux or NTP sup

Re: TODO for etch ?

* Marc Haber: > On Sun, 19 Jun 2005 08:20:49 -0500, Adam Majer > <[EMAIL PROTECTED]> wrote: >>That could "save" a grand total of about a second. > > It will save time in case of error when the bootup process stalls for > timeouts like DNS and NTP. You should set the clock using NTP *before* start

Re: Debian concordance

* Daniel Stone: > Breezy (like current sid) is built against 2.3.5. Current sid on which platform? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Greylisting for @debian.org email, please

* Santiago Vila: > The CBL, in particular, is completely automated, it tries very hard > to not list "real" mail servers, and you can remove yourself trivially. > > In fact, most of the effectiveness of SBL-XBL really comes from the CBL, > as shown by the widely known statistics: Hmm, so "greylis

Re: Greylisting for @debian.org email, please

* Andreas Barth: > First of all, E-Mail is no real time medium. It was never intended so. My users complain if it's not (soft) real-time, and rightly so For most users, it's more real-time than a fax transmission because both parties need not walk to the fax machine. Today, even an MX hop which

Re: Greylisting for @debian.org email, please

* Wouter Verhelst: > What's painful about it? I wouldn't be surprised if it already increases load on lists.debian.org significantly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: C++ ABI change -- freezing unstable for new C++ library packages

* Josselin Mouette: > I maintain a package (hdf5) which contains a pure C library and a C++ > interface. However, I'm pretty sure the C++ library isn't used by > packages depending on it. In this case, is it necessary for the library > to be renamed? Is it reasonable to expect that users compile

Re: Ongoing Firefox (and Thunderbird) Trademark problems

* Eric Dorland: > 1. Completely ignore their Trademark Policy document and let MoFo come > to us if they're not happy with our use of the marks. This is the policy we have adopted with PHP, Apache and similarly-licensed software. It's basically the only choice when we want to continue to distrib

Re: Why target Debian developers with Windows worms?

* Kevin Rosenberg: > Florian Weimer wrote: >> The string "Debian" was simply copied from your email address (and >> capitalized). The worm doesn't target Debian specifically. > > That's far more sensical than expecting Debian developers to be > us

Re: Why target Debian developers with Windows worms?

* Kevin Rosenberg: > I receieved a windows worm in a zip file with a message about my > Debian account being suspended[1]. It seems odd that someone would > bother targetting Debian developers with a Windows worm. The string "Debian" was simply copied from your email address (and capitalized). T

Re: Canonical and Debian

* Steve Langasek: >> how powerfull would a machine need to be to be of any help here? would >> an ultra 10 or a netra x1 be sufficient? > > The current buildd is an UltraSPARC II 300MHz with 512MB of RAM, and is not > sufficient. A Netra X1 typically feature a 400 MHz or 500 MHz UltraSPARC IIe CP

Re: hijacking libhtml-mason-perl

* Charles Fry: > I discussed the matter with Joshua Kwan, who recommended that I send > this email, asking whether or not it would be acceptable for me to > hijack the abandoned libhtml-mason-perl package. Don't forget to coordinate uploads with the request-tracker folks, for whom libhtml-mason-p

Re: PostgreSQL transition ahead

* Martin Pitt: > (2) PostgreSQL 8.0 brought a new SONAME for libpq (libpq4), which > removed a few symbols which were only intended for internal use, > but were used nevertheless by some client apps (like "psql"). > libpq4 can talk to all PostgreSQL servers back to 7.3 (same like >

Re: List of interface names (eth*, dummy*, ath*, tap*)

* Loïc Minier: > On Mon, Jun 06, 2005, Florian Weimer wrote: >> See nameif(8). Interface names can be chosen by the user. > > Hmm, no much point in preparing an interface name list indeed. If some > drivers name where bound to this interface names, it would be quite >

Re: List of interface names (eth*, dummy*, ath*, tap*)

* Loïc Minier: > I'm searching for a list of interface names supported under Debian for > the netspeed GNOME applet, preferably sorted by "user-relevance". The > goal is to try to select the most relevant interface one would display > network traffic for. See nameif(8). Interface names can

Re: New Nokia device is Debian-based?

* Jesus Climent: > That is the key: OSS cannot be killed, not while EU and USA's > governments, local and nationwide, are promoting, using and even > developing OSS themselves. Most countries use OSS only when it's supported by large companies that can be sued for billions. Smaller companies usu

Re: New Nokia device is Debian-based?

* Stephen Birch: > Wow Nokia just became my new favourite company. To put things into perspective, Nokia is one of the companies lobbying for unlimited software patents in Europe. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECT

Re: Keysigning without physically meeting ... thoughts?

* Wouter Verhelst: > Well, in Belgium it's not /that/ bad (a notary is required by law to > give you free advice), but the moment he uses his stamp, it indeed is a > three digit bill (around ¤900 last time I required the use of a notary's > services) The fee depends in part on the value of the tr

Re: [Fwd: RFS: eaccelerator - PHP script cacher]

* Roberto C. Sanchez: > I forwarding this to d-d since after a couple of days I > still have no response from anyone on d-m willing to sponsor > this package. Please have a look at the following discussions:

APT 0.6 migration -- second status report

A test suite for package validation is now available: Please refer to the README file in this directory for instructions how to use the test suite. The archives in the test suite are automatically generated by a collection of Python scripts. These scripts are

Re: Bug#304266: ITP: sdate -- never ending september date

* Josselin Mouette: > Is there any real-life use for this program? No, especially since September ended a couple of months ago: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "uns

Re: dpatch and patching debian/rules

* Lars Wirzenius: > /etc/issue is meant for the sysadmin to edit. It is free form > text. /etc/lsb-release is not. Why is it in /etc and marked as a conffile? 8-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to detect which user is connected to $DISPLAY

* Michelle Konzack: > curently I am coding a tool which run from cron (as root) periodicly > and if a $USER is loged into X it shows Messages. > > My Problem is, HOW to find the $USER who is connected to a $DISPLAY. $USER should start a program that connects to some daemon, from which it receives

Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt

* Elimar Riesebieter: > Differences between mutt and mutt-ng: You should make clear that this list of features compares the mutt and mutt-ng packages (I hope it does). Debian's mutt package contains some of the mutt-ng patches. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of

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: 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: 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: 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: 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: > 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: 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

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: "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

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

* 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: /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: /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: 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: 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: /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: 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: 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: 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: 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: 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

* 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: german debian mirror with 700mb paris.avi file...

* Rechberger Markus: > if someone's bored and looking for a 700mb paris.avi file ... > > ftp://ftp2.de.debian.org/pub/ > > forward it to the maintainer of that ftp if you know who it belongs > to... if possible It's probably not a good idea to post such stuff to debian-devel. 8-/ Would debian-ad

Re: NPTL support in 2.4 kernel series?

* Kurt Roeckx: > What is the problem with linuxthread? Are there some problems > linuxthreads cause that go away when using NPTL? LinuxThreads is pretty far away from POSIX compliance, and its mutexes cannot be shared across address spaces (which is a major problem for Berkeley DB, which therefo

Re: Reboot in postinst

* Marc Haber: > This prompts a question I have been wanting to ask for ages: When a > security update for, say, libc6, libssl or libz is installed, do I > need to restart services or not? That's one of the question you ask > three people and get five different answers. It depends. If the bug is

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

* Frederik Dannemare: > I'll dare to take the other route and ask: what is now holding back > software such as mplayer/mencoder, transcode and mjpegtools from > entering Debian? Same as ever, sufficiently influential people oppose it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subj

Re: rudeness in changelogs

* Steve Langasek: [DJB's vulnerability research course] > Considering the assignment AIUI was "find security holes", I think the assignment was "find potential security holes and prove that they are security holes, by writing exploits". The first part is easy, just compile any sufficiently obsc

Re: rudeness in changelogs

* Joey Hess: > Andrew Suffield wrote: >>* New upstream release (closes: #270944, #277543). It's less than two >> weeks since this was released; may you contract an interesting >> venereal disease. > > Is this really called for in changelogs? Note that the bug reports were > perfectly

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: 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: 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: 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: 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: 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: 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: 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

* 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: 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: 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: 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: 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: 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-

<    2   3   4   5   6   7   8   >