Re: eleventh-hour transition for mysql-using packages related to apache
Theodore Ts'o said: > > My system (currently running unstable, but it from the your description > it sounds like it may be happening on sarge as well) has an > apache2/mysql/php4 combination which blows up the moment you try to open > a connection to a mysql database. Are you sure you're note experiencing the bugs listed in #295998 and #296694, which are fixed in 4.3.10-8 in unstable?... If not, then I guess the transition has started with some packages and not others, and we need to resolve that ASAP. It was stalled for a bit pending some license issues, but Steve and I got that resolved upstream recently. Steve, should we be going ahead with the push to make this transition occur as soon as we can, now that the license mess is sorted? ... Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why do we still have this on the distribution?
Gunnar Wolf said: > > Adam: Is there a reason for keeping PHP3 in the archive? It has users. One of those users recently let me know that he continues to use it, because it "just works". For the curious, that user also happens to be a member of the security team. I won't reveal his name, in case he prefers not to deal with the embarassment of running something as unhip as an old version of PHP. > Is there a real reason to keep carrying this cruft? I understand the > packages are not (or don't appear to be) buggy... However, their bits are > rotting. They are not widely used anymore, and they might have all sorts > of problems that do not get detected. I don't know if patches for the php4 > modules are backported (if the problem exists, of course) for older php3 > modules. It will certainly suffer bitrot, as many (MANY) packages in Debian do. I do, however, still attend to bug reports about the packages, and backport security fixes for vulnerabilities found in php4 that are also present in php3. Heck, I even occasioanlly look at non-security bugs and toss those around a bit. This is probably more than one can so for maintainers of many packages with active upstreams. Someone in this thread mentioned that "upstream doesn't send us patches for php3, so how will we know how to fix stuff?!". Well, guess what? They often don't send us patches for php4 either (and wouldn't/won't for php5). The argument that "upstream doesn't deliver us neat and tidy security updates for our source packages" would probably invalidate 95% of our archive. Maybe not a bad idea. ;) At any rate. I will petition for php3's removal when I'm bored with it, when someone else backs me into a corner to do so, or when I'm convinced no one uses it or cares about it anymore. ... Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#81396: root shell fscked after upgrade to woody
Hate to state the obvious, but on a DEFAULT Debian install, if nothing is changed, root's default path with be dictated by /root/.profile ... Maybe the machine behaving fine still has this file, and the other has had it deleted, and then (and only then) is login/whatever providing you with a default user env... ... Adam Conrad -Original Message- From: Eray Ozkural (exa) [mailto:[EMAIL PROTECTED] Behalf Of Eray Ozkural (exa) Sent: Saturday, January 06, 2001 9:46 PM To: Aaron Lehmann Cc: Eray Ozkural (exa); [EMAIL PROTECTED]; debian-devel@lists.debian.org Subject: Bug#81396: root shell fscked after upgrade to woody On Sat, Jan 06, 2001 at 08:25:54PM -0800, Aaron Lehmann wrote: > Debian has always exhibited this behavior for me. There's a simple > workaround: don't log in as root. > > I don't know which is more distasteful: That you have telnet enabled, or > that you have enabled remote root logins via telnet. > I was surprised to find that I'd enabled remote root logins via telnet, too. he he. I'll close it after projects are over... About having telnet enabled: everybody on the campus knows how to use telnet but would be very surprised I didn't let them connect easily from windows clients. For me, using telnet is of course a bit insecure but when I'm not able to use an ssh client... it's easier. > Interesting, RedHat 5.1 (and up?) exhibits exactly the opposite > phenomenon. Log in as root and you get the right paths. su without '-' > and you don't. Hmmm. This is most probably directly related to login program. :/ Now, the interesting thing is this happens only on machines which have upgraded, and sometimes it won't happen even on upgraded ones. ? For instance, this machine is on woody latest, and it doesn't have the bug. I login as root from console, and I get all the sbin paths here. On borg, the bug occurs as you say, I login as root and I'm in like a normal user. I have to do a 'su' to get things right. What might be the reason for this? -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: What is the default gcc version ?
Neil Roeth wrote: > > I'd like to know this, too. I recently fixed some bugs on > m68k (a painful experience) and the most recent bug reports are basically > "the bug you closed is reoccurring". If the compiler I'm using to test my > fixes is different than the one used to build the package, that might be > the reason. The default should definitely be gcc-3.3 at this point. If we have any m68k buildds that are still using gcc-3.2, those machines' chroots are in desperate need of a dist-upgrade. ... Adam
RE: apt-get'able Release file format
Matt Zimmerman wrote: > > That sounds backwards. "Component" is the one recognized by apt, and > (naturally) the one used by official Release files in the > Debian archive. "Components: updates/main updates/contrib updates/non-free" [1] ... Adam [1] http://klecker.debian.org/debian-security/dists/woody/updates/Release
Re: mass bug filing on packages that are blocking use of cdebconf
Joey Hess wrote: > > This is your third and final reminder. I count 542 packages remaining, > down only 9 from last month. I assume most of the people below do not > read debian-devel, so I've taken the librerty of BCCing you all. :-P > > Debian Apache Maintainers >apache2 apache2 will be fixed when 2.0.55 is released upstream and I upload it to sid (which is due to happen any day now). I didn't see the point in an upload just to fix this issue. ... Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The status of libapache2-mod-perl2
On Wed, Aug 15, 2007 at 09:32:30PM -0500, Gunnar Wolf wrote: > > - Should we hijack/adopt the package, or will its current maintainers > stand up and get it back to life? > - Is there somebody who wants to lead this? > - Pkg-perl and/or Apache groups: Do you agree? :) > - In any other case: Other takers? The debian-apache group has both the necssary perl, apache, and C skills required to maintain this, what we're lacking at times (hey, check the apache changelogs for my name recently... *sigh*) is the time. I'd be happy to see it in the debian-apache SVN repo, though, with a blanket policy for open non-NMU uploads from the Perl folk as well, just to spread the blame as thinly as possibly. ... Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: klibc only initramfs
On Mon, Mar 01, 2010 at 02:00:31AM +0100, Wouter Verhelst wrote: > On Sun, Feb 28, 2010 at 10:26:48AM -0800, Steve Langasek wrote: > > > > You could obviously just fall back to using the full .so in the case of > > initramfs generation. If we can detect that the libc generated is unsuitable, then this fallback seems safe enough. > Also, changing back to a working initramfs may be rather hard, depending > on the bootloader in use. This argument holds for just about any change (epecially ones that we suspect might behave different on different architectures, with different bootloaders, or with different underlying storage techniques), and the answer is the same in all cases. Test, test, test. I know it's nowhere near as true as it was a decade ago, but "people running unstable should know how to fix something as simple as their system failing to boot due to a broken bootloader/kernel/initrd". Personally, I think the idea of cutting out the klibc duplication and stripping eglibc during initramfs generation is a pretty reasonable solution to this longstanding issue. The extra upshot of this is that some of the weirder corner cases you refer to that have bitten d-i in the past (A) have made the implementation more robust, but more interestingly (B) new and similar issues will be discovered and fixed more readily if this is being tested by more than just a handful of installer builders/testers. ... Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100307161356.gb1...@0c3.net
RE: Bug#216492: FTBFS (unstable/all) missing build-dep
Graham Wilson wrote: > > Why exactly is this? Is this really the correct behavior? Shouldn't > dpk-buildpackage be invoked using the -B option? It is. `dpkg-buildpackage -B' invokes debian/rules clean, build, binary-arch. ... Adam
RE: keyserver.debian.org.com
> -Original Message- > From: Philip Brown [mailto:[EMAIL PROTECTED] > > Has anyone noticed that someone has pseudo-hijacked > keyserver.debian.org.com Wildcard DNS. Try "foo.bar.org.com" or "this.hostname.cant.exist.org.com", it all goes to the same place. ... Adam
RE: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Björn Stenberg wrote: > Matthias Urlichs wrote: > >>>Depends: libc6 (>= 2.3.1-1), libgcc1 (>= 1:3.2.3-0pre6), ... > > Note that the version shown is simply the current libgcc.so version. > > Current as of when? When the upload was done? Current as of when libgcc1 froze the shlibs, which was recently. lucifer:~# dpkg -l libgcc1 |grep ^ii ii libgcc13.2.3-0pre8GCC support library lucifer:~# cat /var/lib/dpkg/info/libgcc1.shlibs libgcc_s 1 libgcc1 (>= 1:3.2.3-0pre6) lucifer:~# zgrep "Freeze" /usr/share/doc/libgcc1/changelog.Debian.gz * Freeze the shlibs dependencies to (>= 1:3.2.3-0pre6). ... Adam
RE: apache php4-imap Segmentation fault (help needed)
Jørgen Hermanrud Fjeld wrote: > > On one of my servers, apache segfaults when php4 loads the > imap.so module. > I have a few servers with similar versions, and only one of > the servers > experiences the segfault. Check incoming in an hour or two. Or your local mirror around this time tomorrow. ... Adam
RE: Updated package diff stats for testing/unstable
Daniel Jacobowitz wrote: > > PowerPC's fixed. m68k is a whole other problem. They were both fixed as of today's dinstall run, actually. ... Adam
RE: Autobuilder locale setup
Roger Leigh wrote: > > This works fine when the locales exist for each localisation, but if > they don't exist, it defaults to C locale/US-ASCII charset. Can the > autobuilders guarantee a full set of generated locales, or is only C > available? Autobuilders don't even have "locales" installed by default, as it's non-essential, so you certainly can't count on any specific locales being there, no. You can, however, generate the locales that you need and make them available to you during your package build, with some trickery. See debian/locale-gen in the gcc-3.2 source package, for instance. ... Adam
Re: Current and upcoming toolchain changes for jessie
On Tue, May 07, 2013 at 05:48:52PM +0200, Aurelien Jarno wrote: > > Even if I have to admit I currently don't have a lot of time, it would > have been nice to keep the other people in the team in the loop about > such an upload. You'd been fairly inactive of late, and I felt I'd take some initiative here instead of asking you about every upload. Apologies, no offense was meant. I'd been told that you're fairly busy with real life, so was trying to pull up some slack, that's all. > > The other unfortunate issue with the glibc bump to 2.17 is that it > > has left kfreebsd behind with some pthread mutex changes that need > > some love from BSD porters to untangle. We had hoped that leaving > > it FTBFS in experimental for several months and gently pinging would > > have been enough of a hint, but we can't wait forever either. For a > > porter who knows FreeBSD and pthreads inside out, the work to fix > > glibc 2.17 on kfreebsd should be trivial. Patches welcome. > > I haven't been able to find mails about that on the debian-bsd mailing > list. Could you please point me to them? It was discussed on IRC with both 2.16 and 2.17 with you, among other people. I gave a stab at fixing some of it, but my BSD/pthreads know- how wasn't up to the task. You're right that I didn't mail the list, however. > > For the Debian glibc maintainers, Adam Conrad > > Now I understand why I was not in the loop, I am not member of the team > anymore. Glad to learn that in such an email. You're clearly still a member of the team. That was just how doko signed the email from both of us, I imagine he also didn't ask all the GCC uploaders/committers for their permission on his uploads either. Again, no personal offense was meant here, and the beginning of a new release seemed like the optimal time to make major toolchain changes, rather than waiting several months. The bugs had been filed (and many fixed) long ago. Other than the kfreebsd situation, this isn't a particularly nasty transition, per se. ... Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130507160358.gd29...@0c3.net
Re: Current and upcoming toolchain changes for jessie
On Wed, May 08, 2013 at 01:59:38AM +0200, Aurelien Jarno wrote: > > They weren't coordinated within the team. Furthermore I don't consider > that eglibc was ready to go to unstable, as it was known that two > architectures were going to FTBFS, without a real try to get that fixed > (for example by contacting the porters). I'll absolutely take blame for not trying harder to contact more porters than just you on IRC. On the flip side, I don't think I'm entirely off my rocker in thinking that maybe porters with direct commit access to the packaging might have cared that eglibc has been FTBFS in experimental for four and a half months. This isn't new. And, as we've discovered today, most of the fixes required were really quite trivial (though we're not quite done yet). Anyhow. Arguments are cheap and, generally, pointless. Hopefully Petr has some clever ideas to get us past the last kfreebsd/glibc snag, and I'll have another stab at it tomorrow if this flu subsides and lets me think straight. As I said before, I'm sorry for not coordinating this better outside of Matthias and I. It'll happen differently next time. I can't go back in time and make this time different, so discussing it ad nauseum does no one any good. ... Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508003516.gg29...@0c3.net
Re: Bits from ARM porters
On Tue, Dec 03, 2013 at 12:30:16PM +0100, Hector Oron wrote: > 2013/12/3 Lisandro Damián Nicanor Pérez : > > > Would this be a Qt problem related to the emulator or the the toolkit > > itself? > > That was a comment done by Canonical folks, iirc Adam Conrad, talking > from their experience on emulated builds. Maybe, they are able to > expand on the comment. It's not a Qt issue, it's a fundamental issue with qemu-user-static and threading, which Qt uses a whole lot of. The issues aren't at all limited to Qt, it just happens that Qt gets run a lot in a lot of builds (a lot more than you'd think...). ... Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131203160122.gi7...@0c3.net
