Re: apache 1.3 will soon be removed from testing/unstable
On Mon, Apr 30, 2007 at 12:56:17PM -0500, Peter Samuelson wrote: > Same for apache 1.3 (including apache, apache-ssl, apache-perl); it too > will soon disappear from sid and lenny. There are currently only a > handful of apache 1.3 module packages in sid, against which bugs will > be filed, but there are quite a few packages which depend on things > like "apache | httpd", which should be updated, though not urgently. > > Reply-To set to to the debian-apache list. Should apache2 Replace/Provide: apache in Lenny in order to facilitate upgrades from Etch? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
G++ 3.2 transition: How're we doing?
badly. http://people.debian.org/~willy/gcc-transition/ i think technically these are all worthy of an RC bug, but i don't want to file them and you don't want to see them. if your name's on the list: http://people.debian.org/~willy/gcc-transition/maint-packages-2.95 then figure out which of your packages needs to be fixed http://people.debian.org/~willy/gcc-transition/src-packages-2.95 and just try recompiling them with gcc 3.3. if they haven't been uploaded in that long, you could probably take the opportunity to update to the latest Standards-Version while you're at it. yeah, this should probably go to d-d-a, but let's see what kind of response this gets. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk
Conflicting manpage for queue.3
[ As suggested by Policy 10.1 [1], I am forwarding this issue to debian-devel. Please maintain the cc list in followups. ] Recent versions of manpages-dev include a new manpage queue.3. dqs has been providing a manpage by this name for some time. Therefore there is a file conflict when attempting to install both. manpages-dev is effectively a required package on any system where people do development. Its contents are part of every major Linux distribution. For us to rename the queue.3 manpage in manpages-dev would be a negative user experience for people switching to Debian or using a mixture of Debian and other non-Debian Linux systems. Additionally, dqs is non-free and therefore "not part of Debian". It seems doubly foolish for manpages-dev to rename its manpage. I therefore submit that bugs #208294 and #211620 be reassigned to dqs and merged with bug #213526. In addition, I think dqs should probably be added to the RFA: or O: list as it has had a release critical bug open for 211 days as well as several easily-fixable bugs open for much longer and no uploads since woody. [1] 10.1 Binaries Two different packages must not install programs with different functionality but with the same filenames. (The case of two programs having the same functionality but different implementations is handled via "alternatives" or the "Conflicts" mechanism. See Maintainer Scripts, Section 3.10 and Conflicting binary packages - Conflicts, Section 7.3 respectively.) If this case happens, one of the programs must be renamed. The maintainers should report this to the debian-devel mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, both programs must be renamed. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain
GCC 3.2 transition
I got sick of listening to people discuss the gcc 3.2 transition in an uninformed manner. So I've whipped up a transition plan which will hopefully get us from A to B without causing too much pain. Haha. I'm entirely fallible and I don't pretend to understand all the issues involved with doing the transition. But by writing down a plan at least it can be updated and fixed before we have to start _doing_ the transition. Comments and corrections welcomed. The most up to date version of this document is at http://people.debian.org/~willy/c++transition.html The following is the output from lynx -dump. - The Debian GCC 3.2 Transition Plan This is a proposal. You will be notified when this is a real plan Note! m68k and arm have not yet uploaded gcc-3.2. Until they do, we cannot start this transition! Note! We need to check glibc and binutils work properly with gcc-3.2 on all architectures! Until this is done, we cannot start this transition! Why do we need one? Because GCC 3.2 changed the C++ ABI. You can't mix a C++ library compiled with GCC 3.2 and a C++ application compiled with an earlier version, or vice versa. Transitions are painful. This will be no exception. The rules here are designed to make it as smooth as possible, but it's still going to be unpleasant. We have to do it, we can't stay with g++ 2.95 for ever. This is a proposal. You will be notified when this is a real plan So what're we going to do? * If your package contains no C++, do nothing. One fine day, gcc-defaults will be changed to gcc-3.2 and you'll start using GCC 3.2 with no work by yourself. * If you maintain a library written in C++, add a `c' to the end of the name of your .deb, eg libdb4.0++.deb -> libdb4.0++c.deb. This is similar in spirit to the glibc transition adding `g' to the end of libraries. * You should not add a `c' to your -dev package. * The exact placement of the `c' can be tricky. It's not terribly important; the important thing is that the new package conflicts with the old and has a different name. Stylistically, we prefer to keep the `c' adjacent to the soname number, eg libqt3c-mt-odbc, but if your package ends in a ++, put the `c' after that. * Add a Conflict with the non-`c' version of the package. * Ensure that you're using g++-3.2 to build your library (setting CXX in the environment will normally do the trick). * Add a build-dependency on g++-3.2 in your control file (this can be removed after gcc-defaults is changed). * Wait until all your dependencies have been uploaded in `c' versions. * Upload and rejoice! At some point in the future, we will change gcc-defaults to make gcc-3.2 the default on all architectures. At that time, you should remove the setting of CXX and the explicit dependency on g++-3.2. You should not rename your package to remove the `c' suffix until upstream change their soname. This is a proposal. You will be notified when this is a real plan Why don't we just change the sonames? Because upstream chooses the soname to match their API. If we change the soname then we render ourselves binary-incompatible with other distros and vendor-supplied binaries. This is important because the LSB intend to standardise the GCC 3.2 ABI; for Debian to become binary-incompatible at this point would be the height of perversity. Of course, when your upstream does bump the soname, you can drop the `c' from the package name, just like very few libs still have a `g' on the end. How about versioned symbols? Versioned symbols don't even pretend to solve ABI transition problems. Not to mention there's the other-distro compatibility issue -- binaries compiled on Debian would not run on other distros. Why don't we put the libs in a different directory? Basically, it's too complex. For the glibc transition, we could do this because they used different dynamic linkers. What about other architectures? The rules I've outlined above should make the autobuilders build your packages with GCC 3.2. Help! My package doesn't build with GCC 3.2 Typically this is because your package isn't actually written in C++ but some "extended subset" of it. You may want to talk to upstream about getting it converted. Fortunately, due to hppa using GCC 3.0 for woody, you've probably had a bug filed against your package for at least six months, so this is no surprise to you. If you really can't get your package fixed, you should change to build-depend on g++-2.95. If you depend on a library other than libstdc++ (or libg++), you're not likely to release with sarge. We recommend you statically link to any C++ libraries (other than libg++) which you use. This is a proposal. You will be notified when this is a real p
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 09:59:28AM -0700, Sean 'Shaleh' Perry wrote: > > * Add a Conflict with the non-`c' version of the package. > > why can't we have both installed, just like the libfoo6 and libfoo6g > situation?? i explained this elsewhere... Why don't we put the libs in a different directory? Basically, it's too complex. For the glibc transition, we could do this because they used different dynamic linkers. Or can you think of a good way of having them both install without having conflicting files? -- Revolutions do not require corporate support.
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 08:38:53PM +0200, Martin v. Loewis wrote: > In Jeff's plan: All C++ packages will be uploaded via NMUs. The > package maintainer can upload their packages afterwards if they have > to make other corrections. All of them? I sw someone do a count and there were around 1000 packages currently in the archive. 10%. Per architecture. Is Jeff really going to bNMU all of these packages on the same day for all architectures? What will that do to auric's disc space and our network traffic? This doesn't sound like a plan, it sounds like the absence of a plan. -- Revolutions do not require corporate support.
Re: Bug#388805: RFP: please package mod_auth_xradius
reassign 388805 libapache-mod-auth-radius retitle 388805 Please build apache 2 version kthxbye On Fri, Sep 22, 2006 at 07:10:04PM +0200, Ond??ej Sur?? wrote: > retitle 388805 RFP: please package mod_auth_xradius > reassign 388805 wnpp > severity 388805 wishlist > thank you > > You have filled bug at wrong package. Apache 2.X doesn't contain module > for radius auth. However I was able to find mod_auth_xradius, so I am > changing your bug to RFP (Request For Package) and reassigning it to our > WNPP database. Yeah, but that's wrong. libapache-mod-auth-radius contains the source for an apache 2.0 module, it jsut isn't built right now. > > mod_auth_xradius provides high performance authentication against > RFC 2865 RADIUS Servers. > > Features > *Supports popular RADIUS Servers including > OpenRADIUS, FreeRADIUS and commercial servers. > *Distributed Authentication Cache using apr_memcache. > *Local Authentication Cache using DBM. > *Uses standard HTTP Basic Authentication, unlike > mod_auth_radius which uses cookies for sessions. > > Kind regards, > -- > Ond??ej Sur?? <[EMAIL PROTECTED]> > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lack of a GR proposal explicitly condemning dunc-tank
On Thu, Oct 12, 2006 at 05:34:01PM +0100, Ian Jackson wrote: > I wrote: > > Normally I wouldn't publish private email but I think in this case the > > abusive nature warrants it. It really doesn't. Wanker. > It has been suggested that it would be better to include the context, > to avoid any potential or perceived unfairness, given that the context > was a debian-private posting by me. So here is the whole of Matthew's > message, including the text of my message which he is objecting to: > > On Wed, Oct 11, 2006 at 02:17:50PM +0100, Ian Jackson wrote: > > So I'd like to encourage dunc-tank opponents to consider whether they > > ought to have seconded my resolution too. There's still time to do so > > I think. > > I'm so thoroughly disgusted by you and the actions of people like you > that I've stopped working on Debian. nice job, wanker. > > Apparently taking the other side in this controversy is, in Matthew's > view, a justification for vitriol. Hey, Ian, you're trebly a wanker. Thanks for confirming my decision. I'm not going to explain my position as you'd only use it as an excuse to debate me. I am sick and fucking tired of the wankery coming from the parts of the debian disorganisation who don't want anything to change. It makes me so fucking angry that I've decided to just stop doing anything Debian related. I'm tempted to propose expulsion for a whole bunch of people, except that would involve dealing with Manoj, who I loathe. So, in summary: ___ / _|_ _ ___| | __ _ _ ___ _ _ | |_| | | |/ __| |/ / | | | |/ _ \| | | | | _| |_| | (__| < | |_| | (_) | |_| | |_| \__,_|\___|_|\_\ \__, |\___/ \__,_| |___/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Any CAML people want to take over efuns?
Brent Fulgham put efuns up for adoption over a year ago. It's got 3 release critical bugs open against it. I considered adopting it, but as I don't know CAML and don't like emacs, it would be a bad choice. Please, could someone who knows CAML adopt this package and look it over? Otherwise, let's purge it from the archive. It doesn't even build any more on x86: /usr/bin/ocamlc -I ../ocamlsrc/version/include -c options.ml File "options.ml", line 113, characters 4-6: Syntax error make[2]: *** [options.cmo] Error 2 -- Revolutions do not require corporate support. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Mon, Mar 21, 2005 at 03:20:29PM +0100, Sven Luther wrote: > > Anyway, regarding kernels: I can imagine sometimes, especially with the > > backlog we have currently, a swift processing of some kernel package > > might be warranted and help Sarge. If there is such a case, it would > > help if someone other than yourself from the kernel team contact the > > right email address[3] about it, I had a hard time distilling from your > > Why not me ? I would very much like a reason for that, am i in some way Because you are impossible to deal with. I think this mail from you shows all the characteristics which make you such a pain in the fucking arse. See a psychologist. Really. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *** SPAM *** Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Mon, Mar 21, 2005 at 04:08:19PM +0100, Sven Luther wrote: > Thanks. Maybe i should resign from my debian duties then since i am not > wanted. Do you volunteer to take over my packages ? Please handle parted for > which i am searching a co-maintainer since > 6 month, and take over the > powerpc kernels as well as do my job in the debian kernel team, as well as the > support of powerpc issues in d-i and the maintainance of a big part of the > ocaml subset. I think Debian would be better finding someone else to do those tasks, yes. I'm not going to volunteer for them as I intend to leave Debian shortly after sarge releases. I can't believe Debian is so short on skills that it needs you. > Not friendly anymore and expecting excuses from you Matthew and the whole > ftp-master team for their discrimination of me. Your emails have never had a friendly tone, despite the way you put "friendly" at the bottom of every one of them. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *** SPAM *** Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Mon, Mar 21, 2005 at 05:10:12PM +0100, Andreas Barth wrote: > * Matthew Wilcox ([EMAIL PROTECTED]) [050321 17:05]: > > I'm not going to volunteer for them as I intend to leave Debian > > shortly after sarge releases. > > Why do you intend to leave Debian? The Vancouver meeting summary upset me, not because of the proposals to drop architectures, but because it contained a reminder of the Social Contract changes. The project is moving to what I believe to be a ridiculously extremist position. I can't support the new Social Contract, and wouldn't sign up for it if I were going through NM right now. So the only honourable thing for me to do is resign at the point when it come into effect. It saddens me greatly that we've come to this situation. I've been proud to be a Debian Developer for the past 6 years. I'd like to say, as others have when resigning, that I will continue to run Debian on my machines, but I can't. Moving documentation to non-free makes Debian a less suitable distribution for me. I shall have to look around and see what other distributions suit my needs. I'd like to thank my friends in Debian who've made it worth working on. Those who've been involved in the PA-RISC port (which I first joined Debian to work on). The Apache team have done a fantastic job, and I'm proud of how that worked out. I didn't realise how emotionally attached I was until I came to write this mail. I really wish things could have worked out better. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Tue, Mar 22, 2005 at 09:06:19AM -0300, Humberto Massa wrote: > And I believe that the Vancouver proposal, if implemented as intended up > to now, will not only affect what Debian really *is*, but in some ways > will *destroy* what Debian is. Debian has already decided to destroy what it is by giving in to the crackpots who insist that everything is software. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Immutable files
>From a security point of view, it might be considered worthwhile to install system executables (particularly the suid ones) and then mark them immutable. This does stop some common attacks from succeeding, and it might prevent some stupid things accidentally done as root. My Debian 1.2.10 system (okay, it was an oldish CD-ROM..) has no files marked as immutable. Has this been considered for the hamm release? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
I resigned in 2004
I quit Debian development back in 2004. This was a moral decision, based on the malfeasance of the project secretary over the "Editorial changes" GR. For some reason, Debian as a project failed to notice that I had quit, even though my wi...@debian.org email address was deliberately forwarded to a non-functional email address (in part because of the complete catastrophe that was the Debian spam filtering system at the time). Over the last couple of months, the MIA team has been trying to get me to participate in some inane bureaucracy. I have been ignoring their emails. Today, they took it to a new level by encouraging everybody who knows me to pester me to answer my emails from them. This is not acceptable. Leave me alone. Your project left me long ago. Do not contact me with regard to Debian bullshit.
Re: I resigned in 2004
On Fri, Nov 09, 2018 at 09:29:30PM +0100, Mattia Rizzolo wrote: I would like to start by highlighting one very important line from my last email to you: > > Do not contact me with regard to Debian bullshit. And yet, you did. Fuck you. Do not contact me again. I shall consider any further contact (from you or anyone else in regards to this matter) as harassment, and I shall seek legal counsel. Your email is full of self-justifications and I have not the slightest interest in refuting any of them. You are a computer programmer pretending to be an HR department. You are no good at it. You have to appreciate that I owe you nothing. You don't pay me. It is not incumbent on me to do anything for you. Get a professional to review your procedures, because your procedures are completely inadequate. Causing people who I consider my friends to harass me to do something I find incredibly difficult and painful to do is not OK. You've made them complicit in hurting me. You've dragged up some awful memories from *fourteen* years ago, when I was betrayed by people who I thought were my friends. I don't care that you didn't do it on purpose. You've hurt me. And you made my friends hurt me. Again.
