Re: Compiling in SELinux in the default kernels
On Friday 05 November 2004 11:12, Henrique de Moraes Holschuh wrote: > On Fri, 05 Nov 2004, Manoj Srivastava wrote: > > I would once again like to bring up the possibility of > > compiling in support for SELinux in 2.6.9+ kernels, but leaving > > them disabled by default at boot time. This can be accomplished by > > I second this request. Same here. Please include it, but at the same time I think it would be reasonable to wait till sarge is out, so kernel effort can be put into working on kernels released with sarge. Just a thought. -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk
Re: RFS tag?
On Wednesday 05 January 2005 09:50, Nico Golde wrote: > Hi, > what about an RFS tag for ITPs or and RFS bug report for > wnpp. So debian developers who like to sponsor a package > don't have to read debian-mentors. > I think it would be a good idea. As a person looking for sponsors from time to time, I second this. B/R, -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk
Re: list what's in the NEW queue?
On Thursday 03 February 2005 03:03, Marcelo E. Magallon wrote: > On Wed, Feb 02, 2005 at 06:28:58PM +0100, Jeroen van Wolffelaar wrote: > > As a DD, you can ls /org/ftp.debian.org/queue/new on merkel, daily > > synced. Beware, there are 2826 files in there atm, so ls via grep > > or something. > > And while we are on the subject, what's with NEW not being > processed? Or are we again in the usual "I'll process any package > that I feel like processing" situation? Is it not just that there's too few hands to do the processing? Recently our DPL assigned extra man-power to the "New Maintainers Front Desk" and to the "Debian Account Managers" and with very good results, for what I know. It would be great if he would assign more people to process the NEW queue as well (in context hereto - do all current members of ftp-masters process the NEW queue?). Best regards, -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Thursday 03 February 2005 14:45, Steve Langasek wrote: > On Thu, Feb 03, 2005 at 02:28:39PM +0100, Frederik Dannemare wrote: > > On Thursday 03 February 2005 03:03, Marcelo E. Magallon wrote: > > > On Wed, Feb 02, 2005 at 06:28:58PM +0100, Jeroen van Wolffelaar wrote: > > > > As a DD, you can ls /org/ftp.debian.org/queue/new on merkel, > > > > daily synced. Beware, there are 2826 files in there atm, so ls > > > > via grep or something. > > > > > > And while we are on the subject, what's with NEW not being > > > processed? Or are we again in the usual "I'll process any package > > > that I feel like processing" situation? > > > > Is it not just that there's too few hands to do the processing? > > > > Recently our DPL assigned extra man-power to the "New Maintainers > > Front Desk" and to the "Debian Account Managers" and with very good > > results, for what I know. It would be great if he would assign more > > people to process the NEW queue as well (in context hereto - do all > > current members of ftp-masters process the NEW queue?). > > Increasing the rate at which new packages flow into unstable is NOT > something that should be a priority when we're trying to get the RC > bug count down in preparation of a release. Show me that there are > enough people working on release-critical issues for sarge, You're probably right there's not. > which > requires no imprimatur from the DPL, before you start throwing > packages that have never even been tested by their maintainer at us > faster than we already get them. I see your point if it is really the case that uploads are being done without proper testing from the maintainer himself/herself. I am not to say if this is practice, but I certainly don't do it myself, and it is a pity for those of us who actually ensure proper testing before uploading. For instance, I have clamcour waiting in the queue and before the upload I tested it for weeks on a server of mine, had an ongoing dialogue with upstream and a rather important bug was identified and solved. Now, should an an rc bug accidentially slip into sid despite this, I would, of course, be sure to file an rc bug against my own package to prevent it from propagating to sarge. Would it be an idea (post-Sarge?) to not let packages automatically propagate from sid to testing after X days. Instead, the responsible maintainer would have to explicitly tag a package as 'ready for testing' as opposed to the current situation where a bug must be filed to prevent a buggy package from propagating? Best regards, -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Thursday 03 February 2005 16:05, Wouter Verhelst wrote: > Op do, 03-02-2005 te 15:44 +0100, schreef Frederik Dannemare: > > On Thursday 03 February 2005 14:45, Steve Langasek wrote: > > > Increasing the rate at which new packages flow into unstable is > > > NOT something that should be a priority when we're trying to get > > > the RC bug count down in preparation of a release. Show me that > > > there are enough people working on release-critical issues for > > > sarge, > > > > You're probably right there's not. > > Parse error. :-) I meant to indicate that: no, I cannot show that enough people are working on rc bugs. > > > which > > > requires no imprimatur from the DPL, before you start throwing > > > packages that have never even been tested by their maintainer at > > > us faster than we already get them. > > > > I see your point if it is really the case that uploads are being > > done without proper testing from the maintainer himself/herself. > > His point is still valid even if all maintainers do proper testing. > You can't be expected as a maintainer to be able to test /every/ > possible or impossible situation in which a package could be used. > And then I'm not even talking about packages that should conflict > with eachother but don't, because the maintainer of the new package > didn't know that a file in his package happens to have the same name > as a different file in a completely unrelated package... True, but why would it necessarily affect sarge? The maintainer (and others) would soon discover the problem of conflicting files and a rc bug would be filed, thereby preventing the issue from entering sarge, right? Speaking of this, I actually had a package last week involved in this very situation, and it never came to be a sarge rc issue. But, yes, I do understand there may be many other concerns as well. I just wish /somehow/ there was different handling of new packages depending on their "expected" impact. I realise this would require a lot of extra work if done manually. Maybe it could be (semi-)automated somehow by checking against different aspects of a package. E.g. if an incoming package has Priority: optional - Section: Games - Impact: low (new fantasy field) and only a single binary + man page, then this package slips into the LOWIMPACT NEW queue which requires no further (nor manual) invervention. Other more 'dangerous' (potentially) packages would be dispatched to a HIGHIMPACT NEW queue for further examination by the ftp-masters. Yeah, wishful thinking, I know. But that the same time it is not optimal, IMHO, that extremely trivial or 'very low impact' packages get stuck in a huge queue. Take something akin to a mozilla-firefox-locale package or my mcdp package, for instance. Best regards, -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Friday 04 February 2005 02:30, Steve Langasek wrote: > On Thu, Feb 03, 2005 at 04:05:19PM +0100, Wouter Verhelst wrote: > > Op do, 03-02-2005 te 15:44 +0100, schreef Frederik Dannemare: > > > > which > > > > requires no imprimatur from the DPL, before you start throwing > > > > packages that have never even been tested by their maintainer > > > > at us faster than we already get them. > > > > > > I see your point if it is really the case that uploads are being > > > done without proper testing from the maintainer himself/herself. > > > > His point is still valid even if all maintainers do proper testing. > > You can't be expected as a maintainer to be able to test /every/ > > possible or impossible situation in which a package could be used. > > And then I'm not even talking about packages that should conflict > > with eachother but don't, because the maintainer of the new package > > didn't know that a file in his package happens to have the same > > name as a different file in a completely unrelated package... > > What I know is that every time an ftpmaster processes a batch of NEW > packages, a percentage of them wind up in testing with serious bugs > for failing to declare build-dependencies, and then the release team > has to track these bugs. > > Since the testing scripts have no way to distinguish an > architecture-specific package from a broken binary that only builds > on the maintainer's system, the only strategies I can think of > off-hand that would be effective at reducing this problem are to > disallow all binary uploads from maintainers, [ snip ] Yes, much better to have everything built by the buildd in a clean env, IMO. This would be on my wishlist for post-sarge. This topic was also discussed (for other reasons, though; security concerns, I think it was) last summer. Best regards, -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Friday 04 February 2005 14:14, Brian M. Carlson wrote: > On Fri, 2005-02-04 at 13:26 +0100, Frederik Dannemare wrote: > > On Friday 04 February 2005 02:30, Steve Langasek wrote: > > > On Thu, Feb 03, 2005 at 04:05:19PM +0100, Wouter Verhelst wrote: > > > > Op do, 03-02-2005 te 15:44 +0100, schreef Frederik Dannemare: > > > > > > which > > > > > > requires no imprimatur from the DPL, before you start > > > > > > throwing packages that have never even been tested by their > > > > > > maintainer at us faster than we already get them. > > > > > > > > > > I see your point if it is really the case that uploads are > > > > > being done without proper testing from the maintainer > > > > > himself/herself. > > > > > > > > His point is still valid even if all maintainers do proper > > > > testing. You can't be expected as a maintainer to be able to > > > > test /every/ possible or impossible situation in which a > > > > package could be used. And then I'm not even talking about > > > > packages that should conflict with eachother but don't, because > > > > the maintainer of the new package didn't know that a file in > > > > his package happens to have the same name as a different file > > > > in a completely unrelated package... > > > > > > What I know is that every time an ftpmaster processes a batch of > > > NEW packages, a percentage of them wind up in testing with > > > serious bugs for failing to declare build-dependencies, and then > > > the release team has to track these bugs. > > > > > > Since the testing scripts have no way to distinguish an > > > architecture-specific package from a broken binary that only > > > builds on the maintainer's system, the only strategies I can > > > think of off-hand that would be effective at reducing this > > > problem are to disallow all binary uploads from maintainers, > > > > [ snip ] > > > > Yes, much better to have everything built by the buildd in a clean > > env, IMO. This would be on my wishlist for post-sarge. This topic > > was also discussed (for other reasons, though; security concerns, I > > think it was) last summer. > > I think this is an awful idea. This means that developers will no > longer test their packages before uploading, [ snip ] I surely hope they would still do so. Another option could simply be to proceed with the current way of uploading - but then let the buildd rebuild the uploaded binary. Or is that somehow not feasible? As of right now it is troublesome to build e.g. gl stuff as a maintainer if you are using the nvidia drivers on your system. I'm sure there are many, many other scenarios to choose from. Best regards, -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Friday 04 February 2005 15:02, Henrique de Moraes Holschuh wrote: > On Fri, 04 Feb 2005, Frederik Dannemare wrote: > > As of right now it is troublesome to build e.g. gl stuff as a > > maintainer if you are using the nvidia drivers on your system. I'm > > sure there are many, many other scenarios to choose from. > > Well, you CAN setup a clean sid pbuilder/chroot, you know... In > fact, chances are you should. I actually do. But do all developers? -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Friday 04 February 2005 15:02, Thiemo Seufer wrote: > Frederik Dannemare wrote: > [snip] > > > I surely hope they would still do so. Another option could simply > > be to proceed with the current way of uploading - but then let the > > buildd rebuild the uploaded binary. Or is that somehow not > > feasible? > > Actually, requiring a binary upload _plus_ rebuilding it would be > better, yes, that would be the way to do it, IMO. > it allows to compare the packages and warn if the results > are too different. (It's a warning, not an error, because version > skew of build-deps and build-essential packages can introduce some > changes.) > > > As of right now it is troublesome to build e.g. gl stuff as a > > maintainer if you are using the nvidia drivers on your system. I'm > > sure there are many, many other scenarios to choose from. > > Always build packages for uploads in a clean environment (a fresh > chroot if nothing else is available). I absolutely agree. But it still doesn't have to be 100% problem-free (letting buildd build all packages on all archs for distribution would still be preferred, IMO). For instance, the issue with nvidia and building gl apps I mentioned: I have a sid chroot (debootstrap) on my sarge desktop machine which uses the nvidia driver. Trying to start X in the chroot with the normal nv driver failed due to nvidia already being loaded on that machine (I forget what the exact errors were - it's a while ago now). Thus, in order to have a useable X in my chroot (I need it for various reasons), I had to install and use the nvidia driver there as well, which in turn can case the aforementioned problems when building gl packages for distribution. I'm not saying I cannot find work-arounds - just that having buildd (re)building everything would still be preferred (less worries for maintainers). -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Friday 04 February 2005 15:47, Henrique de Moraes Holschuh wrote: > On Fri, 04 Feb 2005, Frederik Dannemare wrote: > > On Friday 04 February 2005 15:02, Henrique de Moraes Holschuh wrote: > > > On Fri, 04 Feb 2005, Frederik Dannemare wrote: > > > > As of right now it is troublesome to build e.g. gl stuff as a > > > > maintainer if you are using the nvidia drivers on your system. > > > > I'm sure there are many, many other scenarios to choose from. > > > > > > Well, you CAN setup a clean sid pbuilder/chroot, you know... In > > > fact, chances are you should. > > > > I actually do. But do all developers? > > Not all. But some of those who don't, watch like hawks the > buildd-reports, so the arch-dep packages are fixed ASAP. > > If people don't do even THAT much, you want them to have the > possibility of uploading source-only? [ snip ] No. That was not my intend. Read http://lists.debian.org/debian-devel/2005/02/msg00199.html -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Friday 04 February 2005 15:59, Thiemo Seufer wrote: > Frederik Dannemare wrote: > [snip] > > > > Always build packages for uploads in a clean environment (a fresh > > > chroot if nothing else is available). > > > > I absolutely agree. But it still doesn't have to be 100% > > problem-free (letting buildd build all packages on all archs for > > distribution would still be preferred, IMO). > > > > For instance, the issue with nvidia and building gl apps I > > mentioned: I have a sid chroot (debootstrap) on my sarge desktop > > machine which uses the nvidia driver. Trying to start X in the > > chroot with the normal nv driver failed due to nvidia already being > > loaded on that machine (I forget what the exact errors were - it's > > a while ago now). > > Then use another chroot, only for package builds. This will also > catch missing build-deps better. True. Like I said, I'm not saying there's no work-arounds for what I experienced. My point is merely that I think in the end it is better to let the buildd do all build for all archs. I.e. we continue current way of uploading, but buildd will rebuild the uploaded bin (most often x86 I guess) to ensure a proper build in a clean env - just like you suggested in your previous respons. -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian sarge is 3.2 or 4 ?
On Thursday 05 May 2005 01:17, Andrea Mennucc wrote: [ ... ] > Considering that woody was released 19 Jul 2002, it took us > ~3 years to release; in the meantime, all most important > components changed completely; and we did a lot of work > in Sarge, that I do not want to see numerically > represented as > sarge = woody + 0.1 > > So I would much prefer if sarge would be called "Debian 4" > > Do you agree? Well, it doesn't really matter to me personally, but am I correct that the changes from Woody to Sarge have been at least as big as they were from Potato to Woody (where the version number was bumped from 2.2 -> 3.0)? If yes, and with that in mind, it could probably be justified that Sarge ships as 4.0, I guess. -- Frederik Dannemare | http://sentinel.dk | http://linuxworlddomination.dk http://qa.debian.org/developer.php?login=Frederik+Dannemare http://www.ubuntulinux.org/wiki/FrederikDannemare Key fingerprint = 30CF 7AD3 17D9 1A63 A730 ECA6 0D4C 2C97 9D9A 238E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adduser: what is the difference between --disabled-password and--disabled-login
On Thursday 12 May 2005 20:18, Marc Haber wrote: [ ... ] > "UsePam yes" is generally a _big_ surprise for the local admin since > it allows passwords to be used even if "UsePasswordAuthentification > no" is set in sshd_config. [ ... ] I have exactly those set on a few hosts: foohost:/var/log# egrep "PasswordAuth|UsePAM" /etc/ssh/sshd_config PasswordAuthentication no UsePAM yes But from client hosts with no proper pubkey, I get : $ ssh foohost Permission denied (publickey). From what you mention above, I should actually be prompted for a password, right? I only remember setting "PasswordAuthentication no" in sshd_config and I haven't touched any PAM stuff (ie. default Sarge settings). Best regards, -- Frederik Dannemare | http://sentinel.dk | http://linuxworlddomination.dk http://qa.debian.org/developer.php?login=Frederik+Dannemare http://www.ubuntulinux.org/wiki/FrederikDannemare Key fingerprint = 30CF 7AD3 17D9 1A63 A730 ECA6 0D4C 2C97 9D9A 238E
Re: adduser: what is the difference between --disabled-password and--disabled-login
On Monday 16 May 2005 11:12, Frederik Dannemare wrote: > On Thursday 12 May 2005 20:18, Marc Haber wrote: > [ ... ] > > > "UsePam yes" is generally a _big_ surprise for the local admin > > since it allows passwords to be used even if > > "UsePasswordAuthentification no" is set in sshd_config. > > [ ... ] > > I have exactly those set on a few hosts: > foohost:/var/log# egrep "PasswordAuth|UsePAM" /etc/ssh/sshd_config > PasswordAuthentication no > UsePAM yes > > But from client hosts with no proper pubkey, I get : > $ ssh foohost > Permission denied (publickey). > > From what you mention above, I should actually be prompted for a > password, right? I only remember setting "PasswordAuthentication no" > in sshd_config and I haven't touched any PAM stuff (ie. default Sarge > settings). Btw, I have "ChallengeResponseAuthentication no" as well. I suspect this is why "UsePAM yes" is not a problem here (with respect to allowing passwords to be used). -- Frederik Dannemare | http://sentinel.dk | http://linuxworlddomination.dk http://qa.debian.org/developer.php?login=Frederik+Dannemare http://www.ubuntulinux.org/wiki/FrederikDannemare Key fingerprint = 30CF 7AD3 17D9 1A63 A730 ECA6 0D4C 2C97 9D9A 238E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Proper way to remove a package from both sarge and sid
Hi, how should I properly approach the removal of a package which I maintain? Package in question is mozilla-firefox-locale-da which is to be replaced by mozilla-firefox-locale-da-dk (not maintained by me) from source package mozilla-firefox-locale-all. Unfortunetaly, mozilla-firefox-locale-da and mozilla-firefox-locale-da-dk don't conflict, so users trying to install both will face trouble. mozilla-firefox-locale-da-dk just entered sid today and will most likely enter sarge within the normal 10 days. I was thinking this: 1) mail to [EMAIL PROTECTED] today: Package: ftp.debian.org Severity: important Tags: sid < explain reason for removal... > 2) 1 day before mozilla-firefox-locale-da-dk goes in sarge: Ask on debian-release: hint/tag my package for removal BTW, what does RoM and RoQA mean? Thanks in advance, -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MPEG in general Was: Is anyone packaging `lame' ?
On Tuesday 11 January 2005 03:57, Chris Cheney wrote: > On Mon, Jan 10, 2005 at 11:55:30PM +0100, Tollef Fog Heen wrote: > > * Chris Cheney > > > > | Its all encumbered, there is a separate organization MPEG-LA that > > | strictly deals with the licensing. It is quite surprising to me > > | that ffmpeg was allowed into main. > > > > According to rumors I heard, it was allowed in since other > > applications (xine at least, I think) already included it. So it > > didn't really make a difference -- if we're infringing on patents > > with ffmpeg, we are with xine as well. > > > > (Apologies if xine is not the package I'm thinking about.) > > Wouldn't that be an argument to have xine removed from Debian not the > addition of ffmpeg? 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? I hope I'm not pushing the envelope here, and I'm not trying to ignite a lengthy discussion about the legal matters (since IMO we are already past that one with the inclusion of ffmpeg). I merely think we should consider the possibility of releasing Sarge with these other extremely popular tools. Best regards, -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proper way to remove a package from both sarge and sid
Hi Martin On Tuesday 11 January 2005 21:40, Martin Zobel-Helas wrote: > Hi Frederik, > > On Tuesday, 11 Jan 2005, you wrote: > > BTW, what does RoM and RoQA mean? > > RoM: Request of Maintainer > RoQA: Request of QA Group Thanks, bug report sent away with subject of "RM: mozilla-firefox-locale-da -- RoM; replacement available, replacement collides with this one" P.S.: Please include the list on replies. Best regards, -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proper way to remove a package from both sarge and sid
On Tuesday 11 January 2005 20:29, Frederik Dannemare wrote: > Hi, > > how should I properly approach the removal of a package which I > maintain? > > Package in question is mozilla-firefox-locale-da which is to be > replaced by mozilla-firefox-locale-da-dk (not maintained by me) from > source package mozilla-firefox-locale-all. > > Unfortunetaly, mozilla-firefox-locale-da and > mozilla-firefox-locale-da-dk don't conflict, so users trying to > install both will face trouble. [ snip ] What I meant to say here was, of course, that the packages do indeed conflict/collide - it's just that they don't have a Conflicts i their control file. Just wanted to make that clear... :) Anyhow, <http://bugs.debian.org/290008> has been filed. -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proper way to remove a package from both sarge and sid
On Wednesday 12 January 2005 19:39, Frank Küster wrote: > Frederik Dannemare <[EMAIL PROTECTED]> wrote: > > On Tuesday 11 January 2005 20:29, Frederik Dannemare wrote: > >> Package in question is mozilla-firefox-locale-da which is to be > >> replaced by mozilla-firefox-locale-da-dk (not maintained by me) > >> from source package mozilla-firefox-locale-all. > >> > >> Unfortunetaly, mozilla-firefox-locale-da and > >> mozilla-firefox-locale-da-dk don't conflict, so users trying to > >> install both will face trouble. > > > > [ snip ] > > > > What I meant to say here was, of course, that the packages do > > indeed conflict/collide - it's just that they don't have a > > Conflicts i their control file. Just wanted to make that clear... > > :) > > Then this is a release critical bug in the newer package, ..da-dk. > You should file this bug and prevent the buggy version from entering > sarge. It is not sufficient to remove your old package from the > archive, because user will still have installed it and get in > trouble. Instead, a new revision of the ..da-dk package must be > uploaded that has proper Conflicts. > > Will you file the bug? Yep, I'll file it today (with severity serious). Actually I spoke with maint. of ..da-dk earlier today and mentioned the problem for him, and he could tell me that he already did a new revision of ..da-dk - only it hadn't been uploaded by his sponsor just yet. Best regards, -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk
Re: Proper way to remove a package from both sarge and sid
On Friday 14 January 2005 17:08, Tollef Fog Heen wrote: > * Frederik Dannemare > > | Package in question is mozilla-firefox-locale-da which is to be > | replaced by mozilla-firefox-locale-da-dk (not maintained by me) > | from source package mozilla-firefox-locale-all. > > AFAIK, Danish is not spoken anywhere but in Denmark. Why do you want > a m-f-l-da-dk rather than just a m-f-l-da ? [ ... ] Well, I don't know. You'd have to ask the maintainer of ..-da-dk. I only did the ..-dk package before mozilla-firefox-locale-all arrived. -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libGL.so.1: cannot handle TLS data (nvidia-glx deb issue?)
Hi everybody, the last week or so I have been seeing complains about libGL not being able to handle TLS data (whatever that means in this context). For instance, launching xmms gives me: ~$ xmms libGL.so.1: cannot handle TLS data but the app does starts up, however. Today, on the other hand, I tried to start Quake 3 Arena, and I got the following: - Client Initialization Complete - - R_Init - ...loading libGL.so: QGL_Init: Can't load libGL.so from /etc/ld.so.conf or current dir: /home/margith/games/quake3/libGL.so: cannot open shared object file: No such file or directory failed ...loading libMesaVoodooGL.so: QGL_Init: Can't load libMesaVoodooGL.so from /etc/ld.so.conf or current dir: /home/margith/games/quake3/libMesaVoodooGL.so: cannot open shared object file: No such file or directory failed - CL_Shutdown - RE_Shutdown( 1 ) --- - CL_Shutdown - --- Sys_Error: GLimp_Init() - could not load OpenGL subsystem After a lot of trial'n'error this eventually worked out for me as a solution: cd /usr/lib/ ls -ld libGL.so lrwxrwxrwx 1 root root 17 Nov 4 13:00 libGL.so -> libGL.so.1.0.4496 mv libGL.so libGL.so.nontls ln -s /usr/lib/tls/libGL.so.1.0.4496 libGL.so Seems to be a problem with the latest nvidia-glx package, I guess? Anybody else seen it? B/R, Frederik Dannemare
Re: libGL.so.1: cannot handle TLS data (nvidia-glx deb issue?)
Frederik Dannemare wrote: Hi everybody, the last week or so I have been seeing complains about libGL not being able to handle TLS data (whatever that means in this context). forgot to say I'm running Sid, of course... After a lot of trial'n'error this eventually worked out for me as a solution: cd /usr/lib/ ls -ld libGL.so lrwxrwxrwx 1 root root 17 Nov 4 13:00 libGL.so -> libGL.so.1.0.4496 mv libGL.so libGL.so.nontls ln -s /usr/lib/tls/libGL.so.1.0.4496 libGL.so also forgot to say that while this solves the issue with Q3A, other apps such as xmms still complains about "libGL.so.1: cannot handle TLS data". groups.google.com/google.com doesn't have anything useful. I'll submit a bug report in a couple of days, if nothing comes up that indicates I have done anything wrong. B/R, Frederik Dannemare
Re: libGL.so.1: cannot handle TLS data (nvidia-glx deb issue?)
Juergen Kreileder wrote: Frederik Dannemare <[EMAIL PROTECTED]> writes: Frederik Dannemare wrote: [cut] Read the (recently closed) bug reports for nvidia-glx [cut] and install the current version of that package. ,[ /usr/share/doc/nvidia-glx/changelog.Debian.gz ] | nvidia-graphics-drivers (1.0.4496-8) unstable; urgency=low -8 is in fact the version I have installed, and it seems that I'm not the only one having problems with this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=219646 | | * Correctly install tls libglx. | I'm not sure it really does. Not here at least. B/R, Frederik Dannemare
Backport of the integer overflow in the brk system call
Hi everybody, just curious: any particular reason why we didn't see a backport any sooner of the integer overflow in the brk system call (see recent announcement by Wichert Akkerman: http://lists.debian.org/debian-security-announce/debian-security-announce-2003/msg00212.html) like we did with the ptrace issue some time back? Wasn't it (the brk vuln) considered to be threatening enough to justify a quick fix, or was it because the fix by Andrew Morton didn't say (kerne changelog) enough about the potential seriousness of the vuln, or? -- B/R, Frederik Dannemare
Re: Backport of the integer overflow in the brk system call
Frederik Dannemare wrote: Hi everybody, just curious: any particular reason why we didn't see a backport any sooner of the integer overflow in the brk system call (see recent announcement by Wichert Akkerman: http://lists.debian.org/debian-security-announce/debian-security-announce-2003/msg00212.html) like we did with the ptrace issue some time back? Wasn't it (the brk vuln) considered to be threatening enough to justify a quick fix, or was it because the fix by Andrew Morton didn't say (kerne changelog) enough about the potential seriousness of the vuln, or? forgot to say: hat's off to the forensics guys. great work! I really appreciate that we now know what helped the attacker gain root. -- B/R, Frederik Dannemare
Re: Backport of the integer overflow in the brk system call
Henning Makholm wrote: Scripsit Tom <[EMAIL PROTECTED]> On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote: rather far from changing anything in the kernel memory. Andreas is definitely right that the hole doesn't look like that it is that dangerous. If it wasn't a big deal we wouldn't be talking about it. It shut down servers. It's dangerous enough. Whw Isaac said was that he understands why the kernel developer who originally fixed the bug did not realize that it was security critical. OK, this is sort of what I was after. I suspected this was the case, since nothing else would make much sense. I'm just glad the exploit was discovered, and I think the way the whole situation was handled from day one was very professional. -- B/R, Frederik Dannemare
Re: PRINT EPSON STYLUS C82
On Tuesday 05 October 2004 18:49, SAVERIO FERRARO wrote: > I HAVE SOME PROBLEMS WITH THE CONFIGURATION OF THIS PRINT. > HOW HAVE I TO DO? > THANKS You should really start out by reading http://www.catb.org/~esr/faqs/smart-questions.html (especially http://www.catb.org/~esr/faqs/smart-questions.html#beprecise). Then ask again (but on debian-user instead). Best regards, -- Frederik Dannemare | mailto:[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=Frederik+Dannemare http://frederik.dannemare.net | http://www.linuxworlddomination.dk
