Re: an idea for next generation APT archive caching
>>>>> "Chris" == Chris Halls <[EMAIL PROTECTED]> writes: Chris> Hmm, seems you are talking about version 1, which has been Chris> rewritten. The new version isn't bug free yet but it does Chris> fix several problems. It doesn't use wget. It would appear apt-proxy v2 isn't in Debian (or that I can't find it). Chris> There are several cleaning algorithms, controlled by Chris> different parameters. The 'only correct way' algorithm Chris> described above is controlled by the max_versions parameter Chris> (in version 1 & 2) No, max_versions is not correct. It will only work if all my computers use the same distribution; if some computers use unstable while others use stable for example, then the stable version will get deleted after n revisions of the unstable version of the package. -- Brian May <[EMAIL PROTECTED]>
Re: an idea for next generation APT archive caching
>>>>> "Wouter" == Wouter Verhelst <[EMAIL PROTECTED]> writes: Wouter> It's not actually version 2 yet, but the current apt-proxy Wouter> in unstable is supposed to be apt-proxy v2. This version isn't in testing, hence part of my confusion. The other part comes from the fact apt-proxy 1.9.18 in unstable is probably v2. (As for why it is not in testing, see bug #267880 + others). -- Brian May <[EMAIL PROTECTED]>
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
>>>>> "Joe" == Joe Wreschnig <[EMAIL PROTECTED]> writes: Joe> So what are we going to do with it? Ignoring it, as many here Joe> seems to advocate, is pretty dumb. Bashing the USA for stupid Joe> laws doesn't solve the problem. An "Adult" debtag category Joe> might, but then do we demand (formal or informal) age Joe> verification to download the "full" Debian CD? And if not, Joe> what's the point of that tag? We'd just be distributing Joe> *admitted* adult content to minors, then. -- Joe Wreschnig Joe> <[EMAIL PROTECTED]> If we did this, we would allow people to create CDs, if they desired, without the offending software. This would solve complaints along the lines of "I want to distribute Debian without accidently upsetting parents by distributing Adult software that is useless anyway...". -- Brian May <[EMAIL PROTECTED]>
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
>>>>> "Kalle" == Kalle Kivimaa <[EMAIL PROTECTED]> writes: Kalle> The problem is that Debian is about freedom of speech. If Kalle> we start dropping packages just because they are offensive Kalle> to somebody, we are compromising that ideal. Should we drop Kalle> the Bible packages because they are offensive to quite a Kalle> few Islamists? Should we refuse to add a Koran package as Kalle> it is offensive to some Christians? Remove the fortunes-off Kalle> because it offends probably quite a large group of people? Everyone has different standards on what is offensive and what is not offensive. However, I get the impression that giving children access to nude pictures is generally considered wrong in a number of different cultures and countries. This is different from the Bible - if you find the bible offensive you don't have to install it. If you don't want your kids to install nude pictures, they might find it on a source you hadn't anticipated (a Debian CD of all things) and install it without your permission. Just as we value "freedom" in creating Debian, there should also be freedom in being able to distribute it. If Debian were to become known as a CD containing Adult images, especially for the sake of software that has no real purpose, then this could be very damaging, and it could be difficult to repair the damage to our reputation (even if we subsequently removed the software). In much the same way I have seen people get upset when they discover commercially available Windows software comes with free erotic photos (sorry, I can't remember what software now), I think the same applies here. (Admittedly it is worse, IMHO, when it gets installed without your consent). -- Brian May <[EMAIL PROTECTED]>
Re: Bug#283751: ITP: fakepop -- fake pop3 server to warn users that only pop3-ssl is available
>>>>> "Petter" == Petter Reinholdtsen <[EMAIL PROTECTED]> writes: Petter> "connection refused" generate a support request from the Petter> user, and increases the load on the support organisation. Petter> The users will ask what the error message mean, and will Petter> have to get the explanations individually. A message Petter> poping up every time the user connect to the wrong service Petter> will normally change the users behaviour without any extra Petter> work for the support organisation. This assumes that the client program will display the error message. IIRC, Some programs will just display "invalid password" regardless of what the server returns. This makes debugging any problems difficult. IIRC Outlook falls into this category. Even if the client returns the error message to the user, users frequently (read: close-to-always) are unable to *read* error messages (in my experience) and will interpret the error as "invalid password" regardless of what was actually displayed in the message box. These people won't be able to tell technical support any more then the very misleading "Mail doesn't work as it doesn't like my password!". -- Brian May <[EMAIL PROTECTED]>
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
>>>>> "David" == David Weinehall <[EMAIL PROTECTED]> writes: David> Worried parents should realise, that if their kids are old Worried parents, like it or not, have already caused laws to be created in some countries that limit the distribution of certain materials to minors. ...including USA, where master is currently located. These laws were created for a reason, this reason was judged to be a good reason (although people may disagree) and I don't think we should blindly going about breaking them just because we can or just because we disagree. (However, the material in question on this thread may or may not be illegal). The other issue that is implied on this list: What if a package is legal to distribute in USA but not other countries? *If* this is a problem, could we have a list of packages (or something similar) that can be distributed in each country? So if you wanted to create a Debian CD and freely distribute it in country XYZ (which makes distribution of vi to adults a capital offense) you could do so by using a list that removes all illegal programs (in this case all versions of vi) when creating the CD. Note: this wouldn't stop you from downloading illegal content, it would make it possible to distribute Debian legally in the given countries. Just a thought. -- Brian May <[EMAIL PROTECTED]>
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
>>>>> "Michelle" == Michelle Konzack <[EMAIL PROTECTED]> writes: Michelle> And if she does not like violence and naked people ? Michelle> And publicity using half naked people is offensive !!! I would like to think somebody who doesn't like this, even at age 13, wouldn't download and install such a package. Am I being naive? This leaves the issue of if the 13 year old does like it and installs it without permission from parents. Yes, it might be possible for the minor to download it from Internet anyway, but this assumes the minor has unrestricted access to the Internet. I know Australian schools, in general, are very paranoid about censoring the Internet, and there have been news articles along the lines of "school XYZ in disgrace after student downloaded porn". I can't remember if it really was porn or if it was intentional or not, however a number of students got to see it. According to the media, it was very distressing to concerned parents. If we want everybody to use Debian, including schools, then this is an important issue we cannot ignore. -- Brian May <[EMAIL PROTECTED]>
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
>>>>> "Andrew" == Andrew Suffield <[EMAIL PROTECTED]> writes: Andrew> Anybody who can't obtain porn using only the tools Andrew> provided on a Debian CD is a total moron. You might as Andrew> well complain that the internet is bad, just because it's Andrew> primarily used as a vehicle for delivering porn. Not my point. My point was for somebody thinking along the lines: "I want to distribute Debian to this target audience but I don't want to risk upsetting anybody or risk getting arrested and I don't want to have to do it in secret". -- Brian May <[EMAIL PROTECTED]>
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes: Manoj> Well, remember to exclude the Linux kernel, then. It Manoj> is certainly not minor friendly. How many children look at the Linux kernel source code? How many children even know that it exists? I might be naive, but am somewhat skeptical... Also, to the best my knowledge the kernel doesn't contain any pictures of naked people either. I might be mistaken. -- Brian May <[EMAIL PROTECTED]>
Re: Bug#283578: ITP: hot-babe -- (abusive?) erotic images in Debian
>>>>> "Tollef" == Tollef Fog Heen <[EMAIL PROTECTED]> writes: Tollef> | Finally, I would like to commend Michelle Konzack for Tollef> standing up on | this issue. Debian should never promote | Tollef> degradation/abuse/exploitation, in any form, of females Tollef> (or males or | blacks or whites or whatever). Tollef> Please take a look at the images and I'd be surprised if Tollef> you feel them degrade, abuse or exploit females. I think Tollef> they are silly and nothing to be upset about. Not porn, Tollef> not erotic, just silly. If the intention is to be silly, why not replace the images with something else that isn't so controversial? I personally liked the idea I heard about the sheep. Just change the name at the same time. I don't think there is nothing stopping the program from being configurable. If you really want the image of the naked woman, then you can download the image (from non-Debian website) and install it in the appropriate directory, and it could automatically be used instead. I think such a solution would kill off all the complaints I have seen so far... -- Brian May <[EMAIL PROTECTED]>
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
>>>>> "Russell" == Russell Coker <[EMAIL PROTECTED]> writes: Russell> As an example see some of the books of advice for Russell> pregnant women. They have LOTS of photos of nudity Russell> including nipples and public hair. Women seem to buy Russell> such books in quantity. >From time to time they even have naked photos on broadcasted shows too. Sorry, I can't remember all the ratings now. I suspect one show was G (General), or similar (science show aimed at teenagers). What is scary is that I have all these nude photos on my website of some friends. Included is one bitch (hmmm... should include the other bitch sometime). No, I am not swearing (see dictionary reference for "bitch" if you are uncertain; in particular, see the K9 version). Should my website get censored? The subjects in question don't mind or understand... I think the issue, for the general case (some cultures may be different), isn't so much "seeing the naked body is bad", rather, seeing pictures that present the body as a sex item is seen as bad. There is a fine line between the two, people will have different opinions. -- Brian May <[EMAIL PROTECTED]>
Re: Hot-Babe non-controversial images
>>>>> "Frederik" == Frederik Schueler <[EMAIL PROTECTED]> writes: >> An earlier suggestion to show a lamb in various states of >> shear, and then roasted at 100% was also good. Frederik> As a vegeterian I have to strongly object on this. ;-) An extra good reason not to overwork your poor overloaded CPU ;-). -- Brian May <[EMAIL PROTECTED]>
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
>>>>> "Ron" == Ron Johnson <[EMAIL PROTECTED]> writes: Ron> Umm, all animals (except humans) are naked. Not true; have a look at some of the photos here: http://www.tech-sol.net/humor/funphoto121.htm> (note: web page produces stupid warnings; ignore them and it seems to work). There probably are better photos if you looked. While some photos are rather erotic (unfortunately), there are some very decent photos, too. -- Brian May <[EMAIL PROTECTED]>
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
>>>>> "Ron" == Ron Johnson <[EMAIL PROTECTED]> writes: Ron> If you are presenting pictures that "appeal to the prurient Ron> interest and lacks serious literary, artistic, political or Ron> scientific value", then you very well might be violating your Ron> ISP's AUP. So are you saying I should take my web pages of my naked dogs down? -- Brian May <[EMAIL PROTECTED]>
Re: package rejection
>>>>> "Russell" == Russell Coker <[EMAIL PROTECTED]> writes:
Russell> Bad idea. Some countries have stupid laws and we should
Russell> not pander to them. There are laws against encryption
Russell> and against reverse engineering (which could get strace,
Russell> ltrace, and gdb).
I think it would be better to create a distribution of Debian, where
applicable, that meets the legal requirements of the given country.
That way if you do really want to distribute Debian where there are
laws against XYZ, you can distribute a subset of Debian that doesn't
{do,use,require,consume,kill,display,say,etc} XYZ.
No - I am not volunteering.
This also raises lots of issues, like how to do it with minimum fuss
and who is legally responsible (if anybody) if mistakes occur.
No - I am not volunteering here either.
--
Brian May <[EMAIL PROTECTED]>
Re: handling bugs of udev
>>>>> "Nico" == Nico Golde <[EMAIL PROTECTED]> writes: Nico> i think this should be created be default, but thats the Nico> decision of the maintainer. Looking at the script, I was under the impression it is created by default. -- Brian May <[EMAIL PROTECTED]>
Re: Bug#292666: ITP: autoreply -- A safe, rate-limited auto-responder
>>>>> "Christopher" == Christopher Sacca <[EMAIL PROTECTED]> writes:
Christopher> * Package name: autoreply
Christopher> Version : 1.2
Christopher> Upstream Author : Giles Lean
Christopher> * URL : http://www.nemeton.com.au/sw/autoreply/
Christopher> * License : BSD
Christopher> Description : A safe, rate-limited auto-responder
Christopher> A safe, rate-limited autoresponder
Christopher> autoreply is a simple autoresponder useful for replying to
Christopher> email upon receipt.
>>>>> "Chris" == Chris Sacca <[EMAIL PROTECTED]> writes:
Chris> Package: wnpp
Chris> Severity: wishlist
Chris> * Package name: autoreply
Chris> Version : 1.2
Chris> Upstream Author : Giles Lean
Chris> * URL : http://www.nemeton.com.au/sw/autoreply/
Chris> * License : BSD
Chris> Description : A safe, rate-limited autoresponder
Chris> Autoreply is a simple autoresponder useful for replying to
Chris> email upon receipt.
May I suggest that one package would be sufficient?
(I think you filed two ITPs).
--
Brian May <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292572: ITP: praat -- program for speech analysis and synthesis
>>>>> "Rafael" == Rafael Laboissiere <[EMAIL PROTECTED]> writes: Rafael> * This is partly free software; you can redistribute BUT NOT MODIFY Rafael> * it under the terms of the GNU General Public License as published by Rafael> * the Free Software Foundation; either version 2 of the License, or (at Rafael> * your option) any later version. That IMHO is a pretty confusing paragraph/license. I will rephrase it, the way I read it: "You may not modify this under the terms of the GPL version 2 or later (if you desire) as published by the FSF". The implication might be that you can modify it under the terms of the GPL 1. Alternatively, maybe you could modify it under the terms of the BSD license. However, the above line does not grant any privileges, it only removes privileges, so I think it is meaningless. The only part that means anything is "you can redistribute". No rights to modify, implies non-DFSG. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: scripts to download porn in Debian?
>>>>> "Don" == Don Armstrong <[EMAIL PROTECTED]> writes: Don> 2. Should Debian publish content I disagree with which is Don> DFSG free? I am going to write a DFSG script that will download photos I have taken from my website, and display them at random on the users screen. There are no pornographic images and no nude images of humans. If nude photos of dogs, cars, cats, birds or aircraft are a problem for anyone, I can have them removed. There should no need for any controversy. Even better, I will just license the photos (currently 346Meg, but I could make that several gigabytes) under a DFSG compatible license, and include the whole set as a single Debian package in the next stable release of Debian (or sarge+1). Seriously, what has any of this got to do with Debian? I consider Debian an operating system, not a method of transferring art, whether digital images, digital video, writing, etc. I really think we need to draw the line somewhere. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing problemes with deluser
>>>>> "Marc" == Marc Haber <[EMAIL PROTECTED]> writes: Marc> I will leave that explanation to people knowing the project Marc> better. The issue that killed your system would not have Marc> happened if you had used the default configuration or if you Marc> had refrained from trying to remove a default account. Don't forgot the case where package maintainer scripts call "deluser" automatically... It is my opinion that postrm maintainer scripts should not use the delete home directory option, because of the possibility that the administrator may have changed this to point to a directory he/she doesn't want deleted. Instead, it should use (as appropriate) rm -rf to delete the directory that was created in the postinst script. Perhaps these scripts should really be using "userdel" instead (without the -r), as I think this program does not use config files, and no likely to misbehave because the administrator didn't like the default config, however I regularly get these commands confused, and suspect that there might be other package maintainers who have done the same thing. If (for some insane reason, or bug, or something) you change the home directory of a user to /, set REMOVE_HOME on, and purge the relevant package, do don't really expect the contents of your hard disk to be erased while you wait... I am not convinced this is the fault of deluser, but its good to see it will check the home directory for obvious directories that it shouldn't delete. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#294491: RFA: povray -- Persistence of vision raytracer
>>>>> "Miles" == Miles Bader <[EMAIL PROTECTED]> writes: Miles> Pascal Hakim <[EMAIL PROTECTED]> writes: >>> That would be cool. At least one of the povray maintainers >>> has a giant stick up his butt about Debian, something along >>> the lines of "The version of povray in Debian stable is old, >>> so DEBIAN SUX0RS IN EVERY IMAGINABLE WAY!@&* YARGH#(*!!! LOL!" >> Would this be the same povray that's not in Debian? Miles> It's in non-free: I asked about this a while ago on debian-devel and was told (IIRC) that a major rewrite was happening in order to make Povray DFSG compliant. Is this still the case? -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is /.udev for ?
>>>>> "John" == John Hasler <[EMAIL PROTECTED]> writes: John> Norbert Tretkowski writes: >> There's no label saying "if you don't like these wires, remove >> them". John> And cars never grow unwanted wires. You obviously need to run "apt-get update && apt-get dist-upgrade" on your car more often. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#294491: RFA: povray -- Persistence of vision raytracer
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes: One question: Brian> I asked about this a while ago on debian-devel and was told Brian> (IIRC) that a major rewrite was happening in order to make Brian> Povray DFSG compliant. Brian> Is this still the case? Two answers: >>>>> "Jeroen" == Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: Jeroen> No, not really, upstream seems to really want to keep Jeroen> development closed and the license too, in fear of rough Jeroen> versions/ripoffs of POV-Ray to be used without proper Jeroen> acknowledgements, and to prevent any commercial use of the Jeroen> software the authors wrote. Jeroen> See the POV-Ray newsgroups for more information. >>>>> "Miles" == Miles Bader <[EMAIL PROTECTED]> writes: [...] Miles> 2) Acording to their FAQ, they'd actually rather _like_ Miles> to be free-software, but large quantities of their Miles> source-base were developed before they had any such Miles> concept, and contributor is so muddled that they couldn't Miles> easily just relicense everything. Miles> 3) There's a suggestion that they may try to change their Miles> license to something free after the next big rewrite, Miles> planned for the vague medium-term future. Curious; maybe the FAQ is wrong? -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is /.udev for ?
>>>>> "Ron" == Ron Johnson <[EMAIL PROTECTED]> writes: Ron> Rules to live by: Ron> Look before you leap. Isn't the modern version: "Leap before you look..." (and then contact your lawyer[1]...) Ron> Measure twice, cut once. Cut twice, measure once. Ron> Google it! Loose it! Notes: [1] I was debating putting a smiley face here, but then remembered some recent court cases... -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror scripts
>>>>> "Goswin" == Goswin von Brederlow <[EMAIL PROTECTED]> writes: Goswin> zsync has the option of looking into gziped files and Goswin> rsync them as if they would be ungziped (while still just Goswin> downloading chunks of the gziped file). Its a bit more Goswin> complex algorithm but works even better than rsyncable Goswin> files and rsync. zsync looks suspiciously like it might have similar patent issues which killed the rproxy project. Then again I am no expert; Please tell me I am wrong... -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror scripts
>>>>> "Goswin" == Goswin von Brederlow <[EMAIL PROTECTED]> writes: Goswin> zsync uses the algorithm described in the rsync technical paper Goswin> afaik. Does rsync have a patent issue? Do we realy care about some Goswin> stupid countries patents? My understanding is that rsync doesn't have problems, but rproxy (which is also based on rsync) does have problems because it does the calculations at the client side instead of the server side. Rusty Russell had a webpage up describing the history of the problems encountered with rproxy, but all I can find right now is an empty page: http://ozlabs.org/~rusty/index.cgi/rproxy.html> (linked from: http://ozlabs.org/~rusty/index.cgi/IP/2004-10-14.html>). IIRC the patent owner wasn't interested in this application of the patent but was threatening to enforce it regardless. However, based on Robert's response it would appear that patent issues have been considered for zsync and considered OK. I would speculate this is because information is pre-calculated at the server and stored in *.zsync files. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org
>>>>> "John" == John Hasler <[EMAIL PROTECTED]> writes: John> Henning Makholm writes: >> I maintain one package whose upstream author apparently thought that >> $PATH would be a good place to look for a system-wide configuration >> file. I changed that to look in /etc instead, which makes the >> configuration mechanism in Debian substantially different from >> upstream's. John> I have made similar changes, but I also patched the documentation. Many John> DDs do not do so, confusing users. I consider that a bug. If something like this is different, then not only should Debian supplied documentation reflect the change, but a list of differences should appear in README.Debian. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_movefiles, tar vs. mv
>>>>> "Christoph" == Christoph Berg <[EMAIL PROTECTED]> writes: Christoph> As I understood it, the question was about moving stuff Christoph> from debian/tmp to debian/package. The stuff in Christoph> debian/tmp should get removed by the clean target Christoph> anyway, so it doesn't hurt to move instead of copying Christoph> it. A benefit of moving files, rather then copying, is that you get to see at a glance what files your package left behind and missed in debian/tmp (e.g. if upstream adds new files to the packages but doesn't document these additions). -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: procmail and Large File Support
>>>>> "Colin" == Colin Watson <[EMAIL PROTECTED]> writes: Colin> Not everyone likes maildir; I gave up on it after Colin> experimenting with it and realising that making it harder Colin> for myself to use standard Unix text-processing tools on my Colin> mailboxes was just too annoying. This is true of spam-bin Colin> folders more than other folders, if anything. Not every situation warrants using maildir, it uses a large number of inodes, is slow to scan (yes, mbox isn't very good either), inefficient at storing large number of very small files (due to block size limitations of file system), and more complicated to transfer/move/share. Of course, all of these factors depend on the file system used. I am confident somebody could point out a file-system that eliminates many of these disadvantages. The major benefits of Maildir, IIRC, seem to be: * No locking required for mail delivery. Not all folders require this. * More robust separation of messages (only an issue because mbox. standards are so pathetic and everybody has there own ideas what constitutes a reliable method to detect the end of a message). So what appears to be to separate messages contained in mbox format in mutt can be interpreted as only one message by formail (see bug #295604 for example). -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] maildir
>>>>> "Michelle" == Michelle Konzack <[EMAIL PROTECTED]> writes: >> > inefficient at storing large number of very small files (due >> to block > size limitations of file system), and more >> complicated to > transfer/move/share. Michelle> What is complicate ? You need only the right Michelle> programs... Perhaps I should elaborate on this point. If I want to allow people to download a mbox folder (consider mailing list archive), all I do is put in under a HTTP accessible directory. People only need to download one file, and IIRC, there is a standard (or defacto standard) MIME type for mbox files. I believe a browser will automatically start mutt. In fact, I believe this will work even if the file is gzipped. Now take Maildirs... Sure, I could tar.gz the entire directory, but this means the recipient must manually untar it before accessing it. I don't believe there is a standard MIME type to distinguish these files either. As far as your browser is concerned, it isn't "Maildir" format, it is "gzipped tar format". Also, all mailing list software I have seen so far exclusively uses mbox files. Sure, these are implementation issues that could be solved, but currently mbox wins. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy
>>>>> "O.S." == Otavio Salvador <[EMAIL PROTECTED]> writes: O.S.> Unfortunatelly I hadn't time to work on it anymore and major O.S.> of last work was did by Chris. Could you help with its O.S.> development? Thanks for the response. Unfortunately, as I seem to be running behind with my own packages, I don't think I can spare time to help with other packages at this point in time. I am glad to hear though that it is still being worked on. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy
>>>>> "Eric" == Eric Cooper <[EMAIL PROTECTED]> writes: Eric> I wrote approx for exactly this purpose. It's now in Eric> testing. Is a back port available for sarge? If not, how feasible would it be to create on? Does it depend on anything not in sarge? Thanks -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
>>>>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes: Russ> Brian May <[EMAIL PROTECTED]> writes: >> * Find out what is required to keep AFS support working >> (assuming I don't already have it). Russ> Well, what sort of AFS environment? The answer is different Russ> if you mean "AFS using kaserver" than if you mean "AFS using Russ> krb524 or native K5." Ideally that would be "AFS environment that our users require". However, I would be happy is that was "AFS environment that will work without recompilation of Debian packages". My preference would be native K5. However, I get the impression that isn't yet possible with openafs in Debian (unless I am badly confused). So if using krb524 works, then hopefully that would be OK. (when I last tested it I couldn't get it to work with anything except krb4 support in the KDC, but I may have been doing something wrong...) -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
>>>>> "Steve" == Steve Langasek <[EMAIL PROTECTED]> writes: >> Not only that, but it conflicts with key krb4 libraries >> (libroken and libsl) IIRC. Steve> More likely: Conflicts/Replaces/Provides. I expect that if Steve> the Heimdal versions of libroken and libsl conflict with Steve> the existing krb4 versions, it's because they are in fact a Steve> compatible replacement. In theory at least... Steve> Hmm; looking at the symbol tables of each library, we have Steve> the following symbols that were present in the krb4 version Steve> of libroken and have been dropped in the heimdal version: Steve> get_progname roken_glob roken_globfree set_progname The latest Heimdal version might have renamed these to glob() and globfree(), hence clashing with the libc6 version of these functions. Yuck. There should be configure tests to prevent these, but I am not convinced they are working, as the header files were clashing (I don't know what is going on here). I can't remember now why our workaround was to rename the functions instead of removing them. It is possible the roken version has required features not in libc6. Double yuck. libroken is probably the most important library. I suspect no package other then Heimdal uses the functions in question, but I can't guarantee it. Steve> At least get_progname and set_progname were exported as Steve> part of the published API, so libroken16-heimdal can't Steve> claim to provide libroken16-kerberos4kth. It would be nice Steve> if upstream changed the soname, though, to distinguish it Steve> from other, known-incompatible versions out there. At least some of these changes look like they are Debian specific, not sure. So upstream changing the soname may not be appropriate. Anyway, here is a quick scan of dependencies, at least in sarge: (note: I filtered out Heimdal and kerberos4kth from these lists) snoopy:~# apt-cache rdepends libroken16-kerberos4kth libroken16-kerberos4kth Reverse Depends: sasl2-bin lsh-server libsasl2-modules-gssapi-heimdal evolution-exchange arla snoopy:~# apt-cache rdepends libsl0-kerberos4kth libsl0-kerberos4kth Reverse Depends: arla snoopy:~# apt-cache rdepends libss0-kerberos4kth libss0-kerberos4kth Reverse Depends: [ none ] snoopy:~# apt-cache rdepends libotp0-kerberos4kth libotp0-kerberos4kth Reverse Depends: [ none ] snoopy:~# apt-cache rdepends libkrb-1-kerberos4kth libkrb-1-kerberos4kth Reverse Depends: sasl2-bin libsasl2-modules-kerberos-heimdal evolution-exchange arla Build-depends kerberos4kth-dev: Package: arla Package: cyrus-sasl2 (note: just because a dependency is listed doesn't mean the library is *used* by application. I suspect many applications blindly link using "-lkrb5 -lsl -lroken", etc, because antique versions of libtool couldn't handle interdependencies between shared libraries properly, and there seems to be a lot of code that assumes libtool is still broken - in actual fact "-lkrb5" is all that is required). My proposed plan of action seems to be: * Work out this glob() and globfree() business, and make sure I am not creating duplicate symbols or using a version that is incompatible. * Upload Heimdal. * Rebuild above packages. * If packages don't rebuild then it may be because it requires krb4 support => drop krb4 support (cyrus-sasl?), or entire package (arla?). * Drop kerberos4kth. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
>>>>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes: Russ> You're correct, although it's very close. It will be Russ> possible with the 1.4.1 release (and is almost possible Russ> right now but openafs-krb5 is too old; I'm waiting for the Russ> 1.4.1 release to retire the openafs-krb5 package and package Russ> aklog and asetkey with openafs). So it will be possible for Russ> etch. The aklog in openafs will also support krb524d. I can't seem to find it in my version ;-( However, I now got krb524 working with Heimdal. I had to insert enable-524 = true in /var/lib/heimdal-kdc/kdc.conf (the man page for kdc lead me to believe this was the default). and add: [login] enable-524 = true in /etc/krb5.conf -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: master's mail backlog and upgrade time
>>>>> "Stephen" == Stephen Frost <[EMAIL PROTECTED]> writes: >> So if I have my system say `250' to a piece of mail, I'm guaranteeing >> that either I'll bounce it (and get a `250' on the bounce), or that >> some human (me or someone else I know) will read it. Stephen> Sure, so say '250' and then bounce it if you want to Stephen> later. That's basically the *point* here. master's Stephen> forwarding the mail for you, you should accept it and Stephen> then you can decide to either read it yourself or bounce Stephen> it. You do *not* need master to bounce it for you! Are you saying you should bounce SPAM mail??? Where do you bounce it to? The forged senders email address? Alternatively, you could redirect the mail to >/dev/null, but then the poster of a genuine email doesn't know his mail didn't get through. Yes, in this case the mail would bounce anyway, but I think the solution is to improve the SPAM checking on master, and not accept the mail in the first place. Yes, you could probably make mail from master.debian.org bypass SMTP level SPAM controls, but taken to the extreme, you would have to also do this to every server that forwards you email (perhaps even every mailing list server?). -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
>>>>> "Matthew" == Matthew Palmer <[EMAIL PROTECTED]> writes: Matthew> I'm keenly interested in per-package signatures for Matthew> Debian packages -- I think they're a great idea and it's Matthew> a pity that they haven't received more interest. Same here. I would really like to see all packages signed, not just the source code and not just the archive (if any) they came from. I see advantages: * ability to check downloaded binary package even if it no longer exists in latest archive. * ability to trace the source of a binary package in a secure way, whether it was built by a maintainer, automatically built by an autobuilder (which one?), or built by some 3rd party. yes - I realize some people consider automatic signing by an autobuilder to be "insecure" - however I think it is more secure then not having any signature - when deciding on how much you trust it you need to take into account the source. Besides, I believe the archive is already signed automatically anyway. * this can occur without trying to look up the *.changes file (assuming it still exists - for packages never uploaded to Debian, maybe not). * others I am too lazy to think of. Matthew> I've never seen dpkg-sig mentioned before, only debsigs, Matthew> so I'm not familiar with the tool itself, but the concept Matthew> is one that needs a lot more exposure. I would speculate debsigs got a name change to dpkg-sig. Can somebody confirm or deny? -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
>>>>> "Marc" == Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> writes: Marc> Brian May <[EMAIL PROTECTED]> writes: >>> I've never seen dpkg-sig mentioned before, only debsigs, >>> so I'm not familiar with the tool itself, but the concept >>> is one that needs a lot more exposure. >> I would speculate debsigs got a name change to dpkg-sig. Can somebody >> confirm or deny? Marc> No. dpkg-sig is a completly independent application (though Marc> some ideas were taken from debsigs) So, can I conclude we should use dpkg-sig and not debsigs? The reason I haven't uploaded my packages using something like this is: * last time I tried, it got rejected, I didn't know the situation has changed. * confusion over which system to use. * Not integrated with dpkg-buildpackage, debsign, autobuilders, or dak yet. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
>>>>> "Thiemo" == Thiemo Seufer <[EMAIL PROTECTED]> writes: >> Well, even if I know naught about it, it looks to me that having >> something signed is better than having the same something not signed. Thiemo> Sorry, but that's a snake oil rationale. A: Why do you lock your car up[1]? B: Because it looks like having it locked is better then not having it locked. A: Sorry, but that's a snake oil rationale. Anybody can pick the lock and break in. Anybody can smash a window and break in. etc. However, we still lock our cars regardless. We still lock our houses. We still use signatures and ID cards (all of which can be forged) as protection to keep our money safe. The reason why? Because we have just made it more difficult (or so we hope!) for somebody to break in. We still consider this a worth while compared with the added inconvenience of having to maintain the additional security (e.g. keep the key safe and not lost). Despite the fact we all know it is not absolute security. It is also feasible. Yes, you could hire a security guard to watch your car 24 hours a day, but that is likely to cost more then the car is worth. Most people don't consider their cars to be this important. I think the same thing applies here - sure somebody could interfere with the system and either steal the private key or get a package signed that shouldn't be signed, but if you really want to argue along these lines, I think we remove all signatures everywhere, because the possibility exists any one of these could be "forged" (especially as Debian cannot guarantee that every maintainer keeps their private key secure, and that their build systems are secure, etc). So just saying "its snake oil" isn't really saying anything IMHO, because taken to an extreme all security we have in this world *is* snake oil. Sometimes it works. Sometimes it doesn't work. That doesn't mean we shouldn't try to improve it as much as possible. The only exception I would make is when "improvements" mean extra "security" for political/red tape reasons which do nothing to stop the weaknesses they are meant to stop, but instead serve to make our politicians looks good as well as giving them more income. However, I think the ability to trace a Debian binary package to its source, even if the original .changes file is no longer available, is a definite advantage, and is not any less reliable or secure then using the original .changes file for the same purpose. In fact, you could argue it is more secure then the "Received" headers everyone relies on to trace SPAM (which have no cryptographic signature). I also believe that the threat of somebody being tricked into installing a Trojan package is a very real possibility, and we should do everything we can do to aid our users prevent this from happening. Notes: [1] Assuming you have a car, if not replace the words "car" and "lock" with something more appropriate. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Heimdal autotools dramas
My biggest concern with the Heimdal in experimental, is glob() in libroken. To the best of my knowledge, it isn't required because libc6 glob() does everything required. I am concerned, because of the potential of the symbols conflicting with the function in libc6. The Heimdal configure script correctly detects that glob() is present in libc6, but appears to build glob.c anyway, and it also installs glob.h. A similar situation appears to exist with fnmatch, but I haven't investigated in detail. Unfortunately, solving this is pushing my automake knowledge to its limits. lib/roken/Makefile.am has: if have_glob_h glob_h = else glob_h = glob.h endif Some how that is being set in lib/roken/Makefile, despite the fact have_glob_h is also set (this is confusing me!!!) I simply cannot see where lib/roken/Makefile.am references glob.c. However, lib/roken/Makefile references glob$U.lo and glob$U.o. I asked upstream Heimdal and got no response. Any help would be much appreciated. Thanks. PS. Source code is Heimdal in Debian experimental. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Heimdal autotools dramas
>>>>> "Gabor" == Gabor Gombas <[EMAIL PROTECTED]> writes: Gabor> It tests for the GLOB_QUOTE flag but that is not present in Gabor> glibc, so it decides that glibc's glob() function is not Gabor> good enough. See cf/broken-glob.m4. Arhh... This brings back memories. Now I just need to remember if GLOB_QUOTE is actually required or not. Gabor> Also, libroken.so contains only the symbol rk_glob(), not Gabor> glob(). I haven't checked the actual Debian package, but Gabor> unless it overwrites /usr/include/glob.h (which I highly Gabor> doubt) Heimdal's version of glob() will not be used outside Gabor> of Heimdal. I suspect you are probably looking at an older version of the Debian package, which renamed the function in order to eliminate this type of problem. (I thought the new name was roken_glob() though). Unfortunately, this patch didn't apply cleanly to Heimdal 0.7.1 (I haven't investigated in detail why), and I was hoping it wouldn't be required. I might be mistaken. Gabor> I've just tried a Heimdal-0.7.1 build here and libroken Gabor> does not have fnmatch. Just the header file then, which I delete in debian/rules. Gabor> Heimdal is using the AC_LIBOBJ machinery. Not familiar with this. Maybe thats why I was confused. >> I asked upstream Heimdal and got no response. Gabor> I did not see your mail on the heimdal-discuss list... I sent the message to heimdal-bugs. Maybe heimdal-discuss would be more appropriate? Unfortunately, my laptop computer is throwing one of its "I will not power on unless you remove my power source and batteries for several days" tantrum, so I can't double check right now. Hmmm. Really need to fix this. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: something strange with rsh/ssh + bash/tcsh is happening. Please advise
>>>>> "Yaroslav" == Yaroslav Halchenko <[EMAIL PROTECTED]> writes: Yaroslav> rsh node19 '/bin/echo ; /bin/echo 123' Yaroslav> rsh node19 /bin/sh -c '/bin/echo ; /bin/echo 123' I think the problem has already been explained. The solutions appear to be: * rsh node19 '/bin/echo ; /bin/echo 123' (as running the shell inside the shell seems to be a dumb thing anyway) * rsh node19 /bin/sh -c '"/bin/echo ; /bin/echo 123"' (also works, but gets increasingly complex) Also if you are curious try: * rsh node19 '/bin/echo *; /bin/echo 123' (the * will be expanded by the implicit shell at the remote end) * rsh node19 '/bin/echo 111 > /tmp/out; /bin/echo 123' (the > will be take effect in the implicit shell at the remote end) Is there anyway you can disable this implicit shell, either with ssh or rsh? I really don't like it. I would rather each parameter be passed straight to the remote executable via exec without being parsed by sh first. Then, if I want to use the shell, I can say so. I don't like this business of the command line being parsed by two shells as the default. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: something strange with rsh/ssh + bash/tcsh is happening. Please advise
On Sun, Jan 01, 2006 at 05:58:21AM -0600, Peter Samuelson wrote:
> So you want rsh/ssh to do the job of word splitting? The question is
No! The easiest way to do word spliting is not to join the words again
after the shell has already split them. No, I am not sure if the
protocol support this. I think it should. So, for example:
myssh remotehost echo a 'b c' *
executes myssh with:
ARGV[0] = "myssh"
ARGV[1] = "remotehost"
ARGV[2] = "echo"
ARGV[3] = "a"
ARGV[4] = "b c"
ARGV[5] = "file1.txt"
(obviously I am assuming one file exists in the current directory on
the local machine)
Which will pass the parameters, still split, to the remote end end
run:
exec*("echo","a","b c","file1.txt",NULL);
(note: I don't have the man page available to double check the
various exec variants)
> how elaborate its shell-emulation parser should be. Handle \ and " and
> ' quoting? Expand environment variables? Expand globs? Execute $()
> nested commands? Handle | or || or && or >> or ! or <& or ; or & or ~?
> Implement builtins such as chdir and while?
If you really want this sort of expansion at the remote end (most of the
time I don't), that is easy:
myssh remotehost sh -c 'echo a "b c" *'
which will become three parameters:
sh
-c
echo a "b c" *
This also makes it more obvious (IMHO) why you need two levels of
quoting.
WHat I propose is much the same as recommended elsewhere, e.g. I have
seen the recommendation you shouldn't use:
system('echo a "b c"');
In perl, as this requires invoking the shell - if instead you pass the
parameter as an array, the shell isn't required, no splitting of the
parameters is required, and this makes the script more secure.
Unfortunately, it seems the same methods have yet to come to
rsh/ssh, etc. Hmmm. I think sudo supports it though:
[EMAIL PROTECTED]:~$ sudo 'id; echo hi'
sudo: id; echo hi: command not found
[EMAIL PROTECTED]:~$ sudo sh -c 'id; echo hi'
uid=0(root) gid=0(root) groups=0(root)
hi
--
Brian May <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
>>>>> "Eduard" == Eduard Bloch <[EMAIL PROTECTED]> writes: Eduard> And I have never understood why the apt-setup questions Eduard> for contrib and non-free have been put into the same Eduard> dialog. The only possible reason is that the users that Eduard> have deliberately decided to not use non-free software Eduard> (because of "political" reasons) should never come in Eduard> touch with it and therefore all possible ways that may Eduard> lead to the "dark side" should be hidden. OTOH the last Eduard> action is already a kind of limiting the freedom of Eduard> choice. And if not (eg. is explained as something else, Eduard> political correctness or whatever) then it still means Eduard> making life or users harder and is a violation of Eduard> DSFG. Pushing users for ideological reasons sucks. I believe installer packages for non-free software still go in contrib, because they are considered GPL compliant. So if you want to be sure you won't accidently get confused with non-free software (I have done so from time to time), this can be achieved by eliminating all non-free software from the search results produced by "apt-cache search". This requires eliminating contrib as well as nonfree. Example, in sarge: flashplugin-nonfree and quake2-data is in contrib. There are also other suspicious packages in sarge maintained by the GA group, eg. acl-installer, and int-fiction-installer. I think these should belong in a separate category then ndiswrapper, because, unlike ndiswrapper, they are not even "complete" packages without non-free software, and this will never change for the lifetime of the installer package. On the other hand, the possibility exists that somebody is using ndiswrapper, either now or in the future with entirely DFSG software. Even if nobody does this, it is still possible to integrate ndiswrapper with free software (such as debian-installer)[1]. The same thing cannot be said (IMHO) for an installer package. Whether this means ndiswrapper should go in main, flashplugin-nonfree should go in non-free, or some other solution, I am undecided. Note: [1] One way, I think, of looking at ndiswrapper is that it is a set of DFSG hooks to allow integration with add-on nonfree software. I believe there are similar hooks in the Linux kernel. Some of these hooks can only be used by non-free software (e.g. uploading of nonfree firmware). This doesn't make the kernel contrib. Why should it be any different if you split the hooks out into a separate user space and separate kernel space package? Would kernel code for uploading firmware suddenly become contrib if you split it out from the kernel source and made it a compilable module? Why so/not? Would the situation be any different if there was a package in main that depended on ndiswrapper-utils, but made use of such non-free drivers optional? If ndiswrapper moved to contrib would this package have to move to? I am not providing an opinion here, but I didn't notice these issues being discussed earlier. back to your regular program... -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Processed: block 322762 with 355341
On Sun, 2006-03-05 at 19:04 -0800, Debian Bug Tracking System wrote: > Processing commands for [EMAIL PROTECTED]: > > > # Automatically generated email from bts, devscripts version 2.9.15 > > block 322762 with 355341 > Bug#322762: /usr/doc still exists (transition tracking bug) > Was blocked by: 189856 190020 203278 254800 254913 254924 254930 255590 > 256250 302504 319726 320084 320103 321926 322749 322769 322772 322775 322776 > 322778 322779 322781 322782 322783 322784 322785 322786 322787 322788 322789 > 322790 322791 322792 322793 322794 322795 322797 322798 322799 322800 322801 > 322803 322804 322805 322806 322807 322808 322809 322810 322811 322812 322813 > 322814 322815 322816 322817 322818 322819 322820 322828 322829 322830 322831 > 322832 322833 322834 322835 322837 322838 322839 352893 352894 353569 > Blocking bugs added: 355341 What does the "block" command do? I have never seen it documented anywhere, including at http://bugs.debian.org/>. Did I miss something? -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Processed: block 322762 with 355341
>>>>> "Don" == Don Armstrong <[EMAIL PROTECTED]> writes: >> > > # Automatically generated email from bts, devscripts >> version 2.9.15 > > block 322762 with 355341 > Bug#322762: >> /usr/doc still exists (transition tracking bug) > Was blocked >> by: 189856 190020 203278 254800 254913 254924 254930 255590 >> 256250 302504 319726 320084 320103 321926 322749 322769 322772 >> 322775 322776 322778 322779 322781 322782 322783 322784 322785 >> 322786 322787 322788 322789 322790 322791 322792 322793 322794 >> 322795 322797 322798 322799 322800 322801 322803 322804 322805 >> 322806 322807 322808 322809 322810 322811 322812 322813 322814 >> 322815 322816 322817 322818 322819 322820 322828 322829 322830 >> 322831 322832 322833 322834 322835 322837 322838 322839 352893 >> 352894 353569 > Blocking bugs added: 355341 Don> Indicates that a bug cannot be closed/fixed/addressed until Don> the bugs that it is blocked by are closed. Two more questions. 1. according to the above, bug 355341 was added to the block list of 322762. If I go to http://bugs.debian.org/322762>, there is a list of blocking bugs at the top: --- cut --- ix blocked by #189856: /usr/doc/libruby still exists after upgrade to unstable; ...etc... --- cut --- but I don't see bug 355341 listed. Why not? However, at the bottom it is listed: --- cut --- Blocking bugs added: 355341 Request was from Joey Hess <[EMAIL PROTECTED]> to [EMAIL PROTECTED] Full text and rfc822 format available. --- cut --- 2. is it possible to list all bugs that are not blocked? 3. does blocking imply any action will automatically be taken once all blocked bugs are closed? What happens if you try to close a bug that is blocked? Oh wait, thats three, not two. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue backing up again -- ftpmasters, any explanation or comment?
On Mon, 2006-03-13 at 11:00 +0100, Petter Reinholdtsen wrote: > Ouch. If that is true, I hope ftpmasters will announce it to the > developers, as a blocked NEW hinders development of Debian and should > not we a surprise. An announcement would at least give us some idea > on when the NEW holding will end, and let us plan ahead. > > It blocks my development at least, as I normally want to make sure one > level of dependencies are in the archive and doing well before I move > on and upload the next level of dependencies. Blocked NEW stops all > progress in this case, and I spend time on other things while I wait. It appears that dar is being blocked because the soname of libdar3c2a has changed to libdar4. Normally processing such packages is very quick, so the delay, even though it has only been several days (I uploaded Sunday; it is now Tuesday) it would appear that NEW is blocked for some reason. However, no changes in my upload are critical (at least none that I am aware of), and there are no known security bugs, so I am not complaining. Just curious. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Delayed ldconfig execution in postinst step
>>>>> "Goswin" == Goswin von Brederlow <[EMAIL PROTECTED]> writes: >> - there are no dangerous transitions (libc5->libc6) that would >> require having updated ld.so.cache immediately - all >> applications should follow the ld.so.conf paths if something is >> not in the cache. No problem here. I am not convinced this is correct. Once I installed a corrupt libc6 package (without realizing it was corrupt), and my system was stuffed. Not because libc6 itself was corrupt. The problem was because ldconfig wasn't run, and this meant I couldn't run any executables that required libc6. Eventually I was able to run ldconfig from a preexisting chroot, and my system was fine. Maybe it has changed now, but it didn't look like the applications were falling back to ld.so.conf when this happened. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: moleinvasion -- Jump'n run game with Tux
>>>>> "Henning" == Henning Makholm <[EMAIL PROTECTED]> writes:
Henning> Which, however, will not stop the code from dying
Henning> horribly if $LANG does not contain an underscore (see
Henning> /usr/share/locale/locale.alias), or if it contains an
Henning> underscore that comes so late that there is no room for
Henning> the LONG_TEXT_FILE string.
Henning> (It does prevent executing arbitrary code taken from the
Henning> environment variable _instead_ of dying horribly).
Not tested, other solutions also possible, but my point is developing
solutions shouldn't be hard:
--- cut ---
FILE * fd=NULL;
if(getenv("LANG"))
{
memset(lang,'\0',sizeof(lang));
strncpy(getenv("LANG"),lang,sizeof(lang)-1);
ptr=strchr(lang,"_");
if (ptr) *ptr='\0';
memset(buffer,'\0',sizeof(buffer));
snprintf(buffer,sizeof(buffer)-1,"txt/%s_%s",getenv("LANG"),LONG_TXT_FILE);
--- cut ---
--
Brian May <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue backing up again -- ftpmasters, any explanation or comment?
>>>>> "Simon" == Simon Richter <[EMAIL PROTECTED]> writes: Simon> The main reason for the NEW queue is the US export Simon> legislation. If it were legal to make packages immediately Simon> downloadable, it would be done. In which case why do new packages with known source code end up in the NEW queue? The source code has already been examined for the US export legislation. e.g. if soname changes on shared library, it requires the package be renamed which appears as a new package. Could be an issue if such an upload contained security fixes. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request of expulsion of Zeke the Cat from the Debian Project
>>>>> "Wouter" == Wouter Verhelst <[EMAIL PROTECTED]> writes: Wouter> This is an official request to throw Zeke the Cat out of Wouter> the Debian Project. I do *not* want a cat as my DPL, Wouter> therefore, I'm requesting that she be removed from the Wouter> project. This is an official request not to expel Zeke the Cat, because Zeke has contributed enormously to the Debian project, and besides I like cats. I am very disappointed that Zeke's nomination for DPL appears to have been censored and think Zeke should be treated equally to the other candidates, despite her superior, bossy, know-it-all cat attitude. Wouter> Besides, I don't like cats anyway. You should be expelled instead! ;-) Wouter> ... then again, maybe this isn't. Huh ? ;-) Wouter> Get over yourself. Please. No! The more expulsions the better! (except for Cats.) -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
>>>>> "Daniel" == Daniel Stone <[EMAIL PROTECTED]> writes: Daniel> However I don't think you'd be right to hold a grudge Daniel> against anyone who refused to apply it. If Matthew raised Daniel> some issues with your patch, why did you not fix them? Daniel> Surely removing a debugging printk and moving the #include Daniel> to the head of the file would've been pretty obvious. Is holding a grudge against somebody grounds for expelling the developer? I think not. Daniel> It's not an isolated event, either. My refusal to apply a Daniel> patch which was unprecedented in the xorg packaging, for Daniel> an issue that I feel (with not insignificant Daniel> justification) is a purely hardware issue was presented as Daniel> me hating on Pegasos. Similarly, your refusal to fix the Daniel> patch you provided was also presented as the kernel team Daniel> despising you and the Pegasos. (Money being paid or no. Daniel> Principles are principles, mmm?) Based on this quote: I would suggest that there might be better techniques one can use to influence somebody to apply a patch. Burning bridges not included. I can't help but get the impression Daniel may have prematurely discounted the patch - admittedly I may not understand the issues though. Most likely all parties involved from room for improvement. Making a developer a scapegoat on a public mailing list isn't going to make anybody improve their behaviour, more likely the person is going to get defensive and refuse to admit they did anything wrong (as this thread demonstrates, or at least what I have read so far - all parties seems to be saying: I am right - you are wrong). I get the impression Sven has contributed a lot to get Linux working on Pegasos. Do we really want to force him to leave? I think not. Would it achieve anything beneficial? I think not. So everyone calm down. Then consider what *you* could have done differently to avoid this conflict from arising. Do so in such a way you are not blaming anyone else, no matter how much you might dislike the other people involved. If you are game, provide a list here. Otherwise, consider sending a private letter of apology to the other party for anything you could have done differently. Then once you have done this, realize there is only one thing left to do. Find the guilty party. There is only one guilty party. IT WAS ALL TUX' FAULT! TUX IS EVIL! EXPEL TUX NOW! BURN TUX! -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
>>>>> "Daniel" == Daniel Stone <[EMAIL PROTECTED]> writes:
Daniel> The following is technically a well-formed diff:
Daniel> --- init/main.c.orig2006-03-15 23:11:48.0 +0200
Daniel> +++ init/main.c 2006-03-15 23:12:23.0 +0200
Daniel> @@ -653,6 +653,9 @@
Daniel> static int init(void * unused)
Daniel> {
Daniel> +char *foo = NULL, *bar = NULL;
Daniel> +strdup(bar, foo);
Daniel> +
Daniel> lock_kernel();
Daniel> /*
Daniel> * init can run on any cpu.
What the heck? Are you implying that would be a suitable well-formed
patch suitable for inclusion? Or did I miss some sarcasm?
Apart from the NULL pointers, strdup only takes one parameter...
--
Brian May <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
>>>>> "Andres" == Andres Salomon <[EMAIL PROTECTED]> writes: Andres> If I didn't care about etch, I could just as easily sit Andres> back and let Sven do his thing (as I have been doing for Andres> the past few months); however, I would like to see the Andres> release happen. Given the time and resources that Sven's Andres> arguments consume, I am convinced that expelling him will Andres> make things run a lot smoother. Even if Sven is as bad as you make out (assume that is the case), would expelling Sven "make him go away"? Would it make him lose interest? Or would the arguments continue either with Sven (from outside the project) or somebody else to take his place? Would the next step be to ban Sven from participating in our public mailing lists? Has the world gone completely crazy? -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
>>>>> "Eduard" == Eduard Bloch <[EMAIL PROTECTED]> writes: Eduard> Sven, you have a problem with not having the last word in Eduard> a dispute. If someone hurts you (or even it may _look_ Eduard> for you this way while it has not been meant to be Eduard> offensive), you cannot stop and reconsider your Eduard> actions. You have to kick your opponent again and again, Eduard> and you insist on leaving the battle as a winner. At some Eduard> point either you or your opponents (driven by your Eduard> aggresive kind) began with stupid polemics, and on this Eduard> point the constructive discussion is over. Eye for an eye Eduard> is not a good way to find acceptable solutions. If somebody attacks you, especially in public, it is a natural reaction to defend yourself. Even if that person is right. Very likely you may not even consider the possibility that the other person is right. So I think you could replace Sven in the above paragraph with any number of other people, including Debian developers. IMHO This is not sufficient grounds for expelling him. PS: I noticed you had the header set: Mail-Followup-To: Sven Luther <[EMAIL PROTECTED]>, debian-devel@lists.debian.org was this intentional? I think Sven is subscribed to this list... -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
>>>>> "Samuel" == Samuel Mimram <[EMAIL PROTECTED]> writes: Samuel> Sorry for not doing this but this mail made me discover Samuel> you expulsion thing and I wanted to give my public support Samuel> to Sven at least once. Me too. I have found him to be very friendly and open to discussion whenever I have talked to him, with issues surrounding my Pegasos computer. Sven donated me this computer, and I have been very happy with it (I using it to type this email in fact). Considering Apple seem to have dropped PowerPC, I am glad some people are still making machines that use a non-Intel based CPU, as it makes me nervous that Intel and AMD have such a huge monopoly. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue backing up again -- ftpmasters, any explanation or comment?
>>>>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes: Russ> I'm dubious that's really the main reason for the NEW queue. Russ> Looking at <http://ftp-master.debian.org/REJECT-FAQ.html>, Russ> the ftpmasters check a lot more than that. In addition, Russ> they also verify licensing issues. I consider that check to Russ> be an integral part of the Debian QA process and wouldn't Russ> want to do without it. It which case, why do packages that a new but with known source appear in NEW? Surely the fact the source code is in Debian would imply that the ftpmasters have already checked the licensing, legal issues, and other things? In contrast it is possible to upload packages containing new upstream source code (but no new packages) that has no manual checking. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
rebooting, non-root raid, udev
Hello, How is the boot process of RAID (using a Debian supplied kernel that doesn't have RAID autodetect compiled in) meant to work with udev? What seems to happen (at least with recent testing/sarge based system): 1. initrd script starts RAID for swap and /. No problems here. The initrd script does the right thing (after I renamed devfs names to non-devfs names in /etc/raidtab that is). 2. kernel boots and transfers control to userland. 3. udev, I believe (not checked) starts early in the boot process. It creates /dev/md entries for the activated RAID partitions (swap and /), but nothing else (since the RAID hasn't been initialised for these devices yet). 4. /etc/init.d/raid2 attempts to initialise the other RAID partitions but fails to do so because the /dev/md* entries do not exist. As I hacked solution, I have added to the very start of my /etc/init.d/raid2 (not tested yet in automatic boot, but worked when I run it manually): for i in 12 14 20 30 32 do mknod /dev/md/$i b 9 $i ln -s md/$i /dev/md$i done I think this will solve the problem. Now I know what happens in practise, what is meant to happen in theory? I haven't observed anything like this behaviour with devfs, so I suspect this is udev specific. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292813: ITP: construo -- 2D construction toy using wireframe objects and physical forces
>>>>> "Miriam" == Miriam Ruiz <[EMAIL PROTECTED]> writes: Miriam> * License : (GPL, LGPL, BSD, MIT/X, etc.) It is licenced under all of these licenses? Seems a very flexibly approach... Presumably the user picks which ever one the like the most. This removes all these potential nasty flame wars about the pros/cons of various licenses. I wanted to verify the license, but the upstream web page of http://www.example.org/> didn't work for me. I suspect contacting the upstream author at "Name <[EMAIL PROTECTED]>" wouldn't work either (I didn't test it though). -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
>>>>> "Jorge" == Jorge L deLyra <[EMAIL PROTECTED]> writes: Jorge> /etc/init.d/ start Jorge> in its postinstall script to start that daemon. I was not Jorge> talking about booting a system, but about using a chroot Jorge> shell to install packages in the filesystem structure of a Jorge> remotely-booted machine. If a package directly uses /etc/init.d/ in its scripts, file a bug report. It should use invoke-rc.d instead. man invoke-rc.d It should work for chroots, and does work for pbuilder. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gluck available again / filesystem shaked
>>>>> "Joerg" == Joerg Jaspert <[EMAIL PROTECTED]> writes: Joerg> You know, our userdir-ldap manages ssh keys. You dont need Joerg> to put them manually in .ssh dirs. How do you set the ssh key in LDAP? I can't see any settings in db.debian.org. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#304570: ITP: codeblocks -- Code::Blocks is a free C/C++ IDE built
>>>>> "Kevin" == Kevin B McCarty <[EMAIL PROTECTED]> writes: Kevin> Francois-Denis Gonthier wrote: >> * Package name : codeblocks Version : x.y.z Kevin> ^ >> Upstream Author : Name <[EMAIL PROTECTED]> Kevin> ^^^ >> * URL : http://www.example.org/ Kevin> ^^^ >> * License : (GPL, LGPL, BSD, MIT/X, etc.) Kevin> ^ Kevin> I think you forgot some stuff. Don't be silly. I think example.com is the new sourceforge... I think they have a requirement that you license your software under multiple DFSG compliant licenses. "somebody" seems very busy writing all this software. There seems to be a lot of free software based there. Just look at the ITPs here. Unfortunately the website doesn't seem to be working right now. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More about GFDL
>>>>> "Maciej" == Maciej Dems <[EMAIL PROTECTED]> writes: Maciej> I have a simple question concerning the GFDL discussion. Maciej> Does the GFDL documentation which currently does not Maciej> contain any invariant section have to go to non-free as Maciej> well? It might be better to ask this question on debian-legal. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
>>>>> "Thomas" == Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: Thomas> You've missed the point. Split / and /boot, that makes Thomas> sense if it's necessary. Splitting / and /usr does not Thomas> make sense. Bad example. A better example might be if you want to mount /usr via NFS or some other network file-system. I have heard people use AFS for this purpose. I am sure there are other file-systems that could be used. Yes, there are ways you can mount / via a network file-system: * NFS Boot code in kernel that auto-configures the network. * initramfs (anybody written code to do this?) However, if all you want to do is share /usr between systems, currently the simplest approach (and the only way I know this is possible) is if /usr is a separate from /. For starters, it only requires an extra entry in /etc/fstab. No changes to the boot structure. A relevant factor is that some directories (i.e. /etc and /var) cannot always be shared, but must be available early on in the boot process (i.e. /etc). So it might make sense to have a local private copy of /, but have /usr shared. Yes, this gets a bit messy in places (e.g. keeping /etc, /lib, and /var synchronized with /usr), but my point is to prove that there still are benefits in keeping /usr and / split. The arguments presented hold true of any filesystem that is complicated enough to require user-level tools to initialize, and for some reason you don't want to use an initramfs to initialize it. Or if you want /usr to be shared between computers but don't want to share all of /. -- Brian May <[EMAIL PROTECTED]> -- 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
>>>>> "Marc" == Marc Haber <[EMAIL PROTECTED]> writes: Marc> If that option is switched off, an account created with Marc> adduser --disabled-login is impossible to ssh into (log Marc> entry "sshd[14704]: User testuser not allowed because Marc> account is locked") while an account created with adduser Marc> --disabled-password can ssh in fine via authorized_keys. I would speculate that the pam_unix module doesn't support checking the account is locked or not, it only checks to see if it can match the password. However, as no password is used... Is there any reason why pam_unix doesn't check if the account is locked? Along similar lines, I have noticed general weirdness with pam_ldap. According to tests I just conducted (OK means login allowed, Fail means login failed): | password | RSA | courier-imap | openssh | openssh +--+-+ expired password| OK | Fail[1] | Fail[2] account deactive[3] | Fail | Fail| OK -- I find this inconsistency is very confusing. What happened (in my case) is most users on my system log in via courier-imap and never realize that their password has expired, because it continued working. Then they came to a trivial problem that took ages to fix because first I had to debug why ssh wouldn't let them log in using a password. I also find it incredible that an expired LDAP password will prevent RSA based log ins (WHY?), but a deactive account won't (WHY not?). I also think it would be really "cool"(TM) if the system could display a message "password expired" or "account is locked" if the user successfully authenticates to the system but is unable to authorize the user to use the system. This saves the user wondering "did I use the correct password?", "Did I enter it in correctly?", etc. Notes: [1] Nothing displayed to user, but following logged: May 15 10:46:24 snoopy sshd[15018]: error: PAM: User account has expired for jan from localhost [2] Automatically reverts to password based authentication which fails, but in this case it never displays the expired message. May 15 10:50:53 snoopy sshd[15846]: error: PAM: Authentication failure for jan from localhost [3] "Account deactivated" option in "LDAP Account Manager". I haven't worked out how this is stored in LDAP yet. No messages displayed to the user. -- Brian May <[EMAIL PROTECTED]> -- 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
>>>>> "Steve" == Steve Langasek <[EMAIL PROTECTED]> writes: Steve> It does, if you use the authorization checks in PAM. If Steve> you only use the authentication checks, then PAM is only Steve> going to authenticate the user -- not check whether they're Steve> allowed access. When you say "authorization checks" vs "authentication checks" what do you mean? PAM has the following sections "auth", "account", "password", "session". All of these are configured by default on Debian. The implication I got when reading Marc's post (or did I read too much into it?) is if ssh is configured to use PAM and if you use RSA based authentication, it won't detect if the account is locked. I fail to see where terms like "authorization" and "authentication" fit into its configuration scheme. If I did misread Marc's post, and pam_unix does the right thing, this doesn't excuse pam_ldap for not doing the right thing either (as shown in my test results I already posted). Steve> This leaks information to attackers about the state of the Steve> account. Only if the attackers are able to successfully authenticate as you. If they can authenticate as you, then security is potentially lost anyway, right? ...unless the solution to the error is to update the password, but in that case leaking the information doesn't have any downside. Perhaps the only exception I can think of is if the account is locked due to "too many login attempts" as opposed to "password expired" or "account has expired" or some other predictable reason. Then, yes, that would be a problem. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Against which package should this go?
>>>>> "Bernd" == Bernd Eckenfels <[EMAIL PROTECTED]> writes: Bernd> I think it is a good idea. Even if we dont move to a web Bernd> based system there is no harm to support us web browser Bernd> users a bit :) Bernd> And consider especially the end-user. Also consider forwarding bugs to upstream, etc. They may not understand our BTS system, or how to access the full details of the bug. I often mention the URL by entering it manually, but this is potentially error prone (one day I suspect I will end up accidently cutting & pasting either the wrong bug id, or http://bugs.debian.org.au/123456> or http://bugs.debian.org/#123456>; all of these are wrong). The downside though is that this would require the BTS software to edit the email message, deal correctly with MIME attachments, etc. I think mailing list software does this correctly though(?), so it should be possible. Another option would be to add-yet-another-cool-macro to Gnus/the-kitchen-sink... errr.. I mean Gnus/emacs... that somehow does the task automatically if I-can-remember-the-stupid-sequence-of-keys-I-invent-to-activate-it, but I don't have the time or patience to learn that awful-programming-language-that-requires-lots-of-nested-brackets... errr... I mean LISP... right now. ;-) However, this won't work anyway for people stuck using lesser MUAs (e.g. mutt), fake MUAs (e.g. evolution), or worse (e.g. anything written by or for Microsoft). -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RES: /usr/lib vs /usr/libexec
>>>>> "Thomas" == Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: Thomas> We've been told that /usr is necessary to allow network Thomas> sharing. Of course, you can network share any directory, Thomas> not just /usr. If you want executables to be shared, then Thomas> share /bin. It's not a problem. I've done it. If you want to share /bin, how do you run /bin/mount in order to mount /bin? Presumably you would also want to do share /sbin and /lib, too. That makes the issue more complex. /sbin/init is the first process that boots (under most setups), and most programs use shared libraries from /lib. Yes, you could do this from initrd/initramfs, but this also becomes harder to setup and debug. I am not familiar with a tool that will generate such images (that doesn't mean they don't exist). AFAIK module dependency information is *still* stored under /lib/modules/$version/, and updated on each boot. If you make a shared version of this writable by each client, you risk (I assume) race conditions on booting multiple clients at the same time. If you make it read-only, you have to be sure it is kept accurate via some other means. You could argue based on this, /lib isn't designed to be shared, so you still need to split it into /usr/lib and /lib. Alternatively you could argue only /lib/modules isn't sharable, I guess. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RES: /usr/lib vs /usr/libexec
>>>>> "Peter" == Peter Samuelson <[EMAIL PROTECTED]> writes: Peter> [Thomas Bushnell BSG] >> Um: >> >> /bin/mount foo:whatever /bin I was considering commenting on this, I think if you want to start going down this track it would be simpler to write/adapt a script that automatically creates an initramfs. This initramfs would not only initialise the network, but mount the appropriate file, including /etc (non-shareable), /lib (shareable except perhaps /lib/modules), /sbin, /bin, /proc, /dev. Some people consider this approach cleaner as it doesn't require the kernel to do the initialisation stuff that can be done is user land. It fact, it wouldn't surprise me if the kernel NFS-root stuff is either obsolete or planned to become obsolete, for this reason. Also you automatically get updated files when you update the kernel, and you don't have to mess around with the package system. Peter> That's a huge administrative hassle. Not only do you have Peter> to figure out what programs and libraries /bin/mount Peter> depends on so you can make sure they're on your real root Peter> partition, but the packaging system doesn't - and shouldn't Peter> - do anything to help you keep the two copies of /bin in Peter> sync. Not to mention the extra mess (at least IMHO) of mounting two copies of /bin. Sure, it is possible though. I am not sure what the point would be. Peter> You would put up with all *that* for a 6-megabyte savings Peter> on your root filesystem? It would be more then 6 megabyte savings on the root file-system if /usr was moved to /. That was the original point I responded to. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RES: /usr/lib vs /usr/libexec
>>>>> "Thomas" == Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: Thomas> sbin is for things that should be in root's path. The Thomas> executables in question are ones that shouldn't be in Thomas> anyone's path. (The standard example is programs started Thomas> only by inetd.) Why not put them under /usr/lib/$packagename/*? I have only seen one argument against this proposal, and that was of (unverified) performance issues. If a given file system does have performance problems with /usr/lib, isn't the correct solution to fix the file system? Disclaimer: I don't care too much either way. It is perhaps worth noting that a package I maintain does use /usr/lib/$packagename/* for inetd servers, and this reduces file conflicts with other packages. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
kernel security bug #307900
Hello, Whats the deal with bug #307900? As far as I can tell from reading the bug report, the bug has not been fixed in sarge, will not be fixed for the release, but the bug has been closed. Have we come to the point where making a release is more important then fixing known security bugs? Does this mean people who want secure pre-compiled kernels have to resort to unstable until the issue is fixed? -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel security bug #307900
>>>>> "Steve" == Steve Langasek <[EMAIL PROTECTED]> writes: Steve> kernel-image packages built against 2.6.8-16 are available Steve> in sarge for the past week or so for i386, alpha, and ia64. [...] Steve> In light of the announcement at the beginning of May that Steve> sarge is security-supported, I think it would be a good Steve> idea for any DSAs issued over these holes to include Steve> mention of the relevant kernel versions for i386 etc., so Steve> that users who have upgraded earlier know that they need to Steve> upgrade and reboot. I think it would also be a good idea if the change log in the kernel-image package could mention any DSAs fixed... The changelog I have says: --- cut --- kernel-image-2.6.8-i386 (2.6.8-16) unstable; urgency=low * Fix up AMD descriptions to include CPU name. Thanks to J. Grant. (Simon Horman) * Removed "for those who want the latest ..." from header package descriptons as this is what packages from kernel-latest-2.6-i386 do. (Simon Horman) * Build against kernel-tree-2.6.8-16. (Simon Horman) * Add myself as an uploader. (Simon Horman) -- Simon Horman <[EMAIL PROTECTED]> Thu, 19 May 2005 16:52:19 +0900 kernel-image-2.6.8-i386 (2.6.8-15) unstable; urgency=high * Build against 2.6.8-15. -- Andres Salomon <[EMAIL PROTECTED]> Tue, 22 Mar 2005 12:39:59 -0500 --- cut --- This still leaves me confused if it fixed the problem or not. I guess I am expected to cross reference this with the changelog of the kernel-source package. What is the "kernel-tree-2.6.8-16" package? Or is this an abbreviation for "kernel-tree-2.6.8" version "2.6.8-16"? Does this imply "kernel-source version 2.6.8-16"? Again, I think it would be much quicker, easier, and less prone to errors if the DSAs where mentioned in the relevant kernel-image-change too. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
>>>>> "Matthew" == Matthew Palmer <[EMAIL PROTECTED]> writes: >> Add to the list of daemon related features the "not start >> daemons by default" and wait for the admin to define which ones >> to start from /etc/defaults or whatever. Matthew> Jesus, meet policy-rc.d. Not all packages use/support this. Most recent example I have personally identified is udev (when creating a Debian system using a script in a chroot, the script couldn't unmount the partition when it was finished, because udev was running and had mounted additional filesystems - the only solution I could come up with was to stop the daemon in the chroot before unmounting the file-system). -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
>>>>> "Grzegorz" == Grzegorz B Prokopski <[EMAIL PROTECTED]> writes: Grzegorz> On Tue, 2005-07-06 at 01:03 +0200, Javier Grzegorz> Fernández-Sanguino Peña wrote: >> [ Installation improvements ] - Firewall configuration during >> installation (ala Fedora Core or SuSE): module for >> d-i. Currently, the system is exposed just during installation >> on some systems (empty root password?) Grzegorz> Right. Especially for workstation installation Grzegorz> something like below would allow to connect from Grzegorz> workstation to anywhere else, but not to any servers ran Grzegorz> on workstation. I would suggest shorewall with a very simple default configuration. IMHO, shorewall seems to be easy to use and configure, and can be used in very simple single computer setups to very complicated networks. The difficulty with supporting firewalls is that people will expect "if I install package X, then it should automatically adjust the firewall to allow it to work". I really do *not* want to go down this path. The firewall is up to the administrator to decide on, not the package maintainers. -- Brian May <[EMAIL PROTECTED]>
Upgrading to Debian sarge
Hello, I am attempting to upgrade a powerpc based system to sarge. It was previously on testing, but hasn't been updated for months. I left the download going overnight (over 600Meg downloads according to aptitude), but it doesn't seem to like anything it downloads. No errors, no warnings, but no packages upgraded either. What is wrong? [EMAIL PROTECTED]:~# aptitude install libc6 Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done The following packages have been kept back: [...] The following packages will be upgraded: libc6 libc6-dev locales 3 packages upgraded, 0 newly installed, 0 to remove and 591 not upgraded. Need to get 7296kB/11.3MB of archives. After unpacking 12.3kB will be used. Do you want to continue? [Y/n/?] Writing extended state information... Done Get:1 http://mirror.pacific.net.au testing/main libc6-dev 2.3.2.ds1-22 [3064kB] Get:2 http://mirror.pacific.net.au testing/main libc6 2.3.2.ds1-22 [4232kB] Fetched 7296kB in 2m14s (54.3kB/s) Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done [EMAIL PROTECTED]:~# echo $? 0 If I run the same command again, I would get the same response. Some sort of message and non-zero exit status would be really nice here... I have seen this behavior before for individual files, when one file is corrupt, but surely the entire archive isn't corrupt? Then again, maybe the entire archive *is* corrupt! [EMAIL PROTECTED]:~# apt-get install libc6 Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: libc6-dev locales The following packages will be upgraded: libc6 libc6-dev locales 3 upgraded, 0 newly installed, 0 to remove and 591 not upgraded. Need to get 7296kB/11.3MB of archives. After unpacking 12.3kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://mirror.pacific.net.au testing/main libc6-dev 2.3.2.ds1-22 [3064kB] Get:2 http://mirror.pacific.net.au testing/main libc6 2.3.2.ds1-22 [4232kB] Fetched 7296kB in 2m14s (54.3kB/s) Failed to fetch http://mirror.pacific.net.au/debian/pool/main/g/glibc/libc6-dev_2.3.2.ds1-22_powerpc.deb MD5Sum mismatch Failed to fetch http://mirror.pacific.net.au/debian/pool/main/g/glibc/libc6_2.3.2.ds1-22_powerpc.deb MD5Sum mismatch E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? [EMAIL PROTECTED]:~# apt-cache show libc6 | grep MD5sum MD5sum: ab0895ee6d8d2cf3b6906eb5228e5c25 [EMAIL PROTECTED]:~# md5sum /var/cache/apt/archives/libc6_2.3.2.ds1-20_powerpc.deb 69301110f8865edd7f2f93d79ad6a715 /var/cache/apt/archives/libc6_2.3.2.ds1-20_powerpc.deb Then again, this package looks old, so maybe the entire mirror is old, and no longer usable. My point though that aptitude should tell you what went wrong. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
>>>>> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes: Joey> Since d-i currently puts the initrd that reads the second Joey> floppy (or other USB media) on the boot floppy with the Joey> kernel, we either have to shoehorn that initrd, which is Joey> currently 644k, onto the same floppy, reducing its size by Joey> 414k somehow. I suggest having a look at yaird. http://www.xs4all.nl/~ekonijn/yaird/yaird.html> Downloads at http://www.xs4all.nl/~ekonijn/yaird/> Yaird appears to be newer and better then mkinitrd, and may help lower the size of the image. Also, it uses initramfs/cpio, supports both Debian and Fedora, looks like it would be easy to customize, etc. I am not sure it is appropriate to use yaird for d-i, I haven't investigated this in depth. Even if it is not suitable out of the box, I suspect it should be possible to customize it so that it is suitable. On my system (using standard libc6), there is a huge difference in size: [521] [snoopy:bam] ~ >ls -l /tmp/test.img /boot/initrd.img-2.6.8-2-k7 -rw-r--r-- 1 root root 4648960 Jun 5 12:49 /boot/initrd.img-2.6.8-2-k7 -rw--- 1 root root 1107666 Jun 12 09:00 /tmp/test.img By default, only essential files (+jbd!!!) are copied (my system is IDE RAID using ext3): [520] [snoopy:bam] ~ >sudo zcat /tmp/test.img | cpio --list . bin bin/cat bin/dash bin/mkdir bin/mknod bin/mount bin/sleep bin/umount dev dev/console dev/null etc home home/bam home/bam/local home/bam/local/lib home/bam/local/lib/yaird home/bam/local/lib/yaird/exec home/bam/local/lib/yaird/exec/run_init lib lib/modules lib/modules/2.6.8-2-k7 lib/modules/2.6.8-2-k7/kernel lib/modules/2.6.8-2-k7/kernel/drivers lib/modules/2.6.8-2-k7/kernel/drivers/ide lib/modules/2.6.8-2-k7/kernel/drivers/ide/pci lib/modules/2.6.8-2-k7/kernel/drivers/ide/pci/via82cxxx.ko lib/modules/2.6.8-2-k7/kernel/drivers/ide/ide-core.ko lib/modules/2.6.8-2-k7/kernel/drivers/ide/ide-disk.ko lib/modules/2.6.8-2-k7/kernel/drivers/ide/ide-generic.ko lib/modules/2.6.8-2-k7/kernel/drivers/md lib/modules/2.6.8-2-k7/kernel/drivers/md/md.ko lib/modules/2.6.8-2-k7/kernel/drivers/md/raid1.ko lib/modules/2.6.8-2-k7/kernel/fs lib/modules/2.6.8-2-k7/kernel/fs/ext3 lib/modules/2.6.8-2-k7/kernel/fs/ext3/ext3.ko lib/modules/2.6.8-2-k7/kernel/fs/jbd lib/modules/2.6.8-2-k7/kernel/fs/jbd/jbd.ko lib/modules/2.6.8-2-k7/kernel/fs/mbcache.ko lib/tls lib/tls/libc-2.3.2.so lib/tls/libm-2.3.2.so lib/tls/libpthread-0.60.so lib/tls/librt-2.3.2.so lib/tls/libc.so.6 lib/tls/libm.so.6 lib/tls/libpthread.so.0 lib/tls/librt.so.1 lib/ld-2.3.2.so lib/libblkid.so.1.0 lib/libuuid.so.1.2 lib/ld-linux.so.2 lib/libblkid.so.1 lib/libuuid.so.1 mnt proc sbin sbin/insmod sbin/mdadm sys var init 4926 blocks No doubt this would be even more with klibc. The only downside I see is that it is still being developed, and considered "incomplete" at the moment. Also, it is not in Debian. I have not yet tested i for booting. Joey> uclibc is one possibility, but 409-some kilobytes of that Joey> 644k are used for kernel modules and other stuff that uclibc Joey> wouldn't effect (much); only 235k is used for libc Joey> currently, and I fear those numbers don't add up to uclibc Joey> making it small enough, unless uclibc occupys only 5k of the Joey> compressed disk. Maybe other changes, like using initramfs Joey> for that image, a little kernel hacking to remove a few Joey> modules that are barely used (like ide-core which is on Joey> there for only 1 symbol on 2.4; didn't check 2.6), and so on Joey> might just make it work. klibc? Not yet in Debian, is there any reason for this? -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keysigning without physically meeting ... thoughts?
>>>>> "Wesley" == Wesley J Landaker <[EMAIL PROTECTED]> writes: Wesley> I wrote this up to someone. I thought I'd share it, and Wesley> get your thoughts. (e.g. anybody see any weaknesses in Wesley> #1-#3 that *aren't* present in the typical meet, check ID, Wesley> get GPG fingerprint, assuming #4 is always used Wesley> afterwards?) Can I please ask the blindingly obvious question that is so obvious nobody has asked? What is the point of keysigning? What are we setting out to achieve? Ok, so I get my key signed, using what I believe to be the standard process[1][2][3][4][...]: 1. I claim to be "Brian May". I have a passport that proves that I am in fact "Brian May". I have a drivers license that proves that I am "Brian May". The photos are identical to what I look like. Assume none of these are forged. I suspect many people would not be able to tell a forgery, even if it technically is illegal. Often the photo looks nothing like the person (due to shave, glasses, hair style, etc). In this case though, I am very convincing that I am Brian May. People who know me and see me can also confirm this. 2. I claim key-id 00530C24 with fingerprint 9918 7E12 ABAF 54EA 9C9E 27A5 B828 A71C 0053 0C24 is mine. In fact, numerous people have already signed this key for me. 3. You obtain a copy of my key with the following UIDs, and sign all of them: Brian May <[EMAIL PROTECTED]> Brian May <[EMAIL PROTECTED]> Brian May <[EMAIL PROTECTED]> Brian May <[EMAIL PROTECTED]> Brian May <[EMAIL PROTECTED]> (note: assume for this keysigning I deleted my old UIDs and added several new ones that I should have added several years ago). 4. Either: a) You send a copy of my key, to me, to the first address[1]. b) You send a copy of my key, encrypted using my key, to the first address. Do this if I you know I want to keep my public key private[2]. Or do this if the key signing session was a "smaller group"[3]. c) You upload to a key server. Do this only if you know I want the public key to become public[2], or if keysigning wasn't a "smaller group"[3]. Or just do this anyway[4]. I have heard various reasons why each alternative is better then the other alternatives. Read the references. Is this process "correct"? Or did something go seriously wrong here? If it was correct, why was it correct? If it was wrong, why was it wrong? Assume this key isn't already in the Debian keyring (it is), but I am an existing Debian Developer. If you were the Debian administrators, would you have any problems adding this key to the Debian keyring? What if I only supplied my Debian UID, and my public key was otherwise private? So after having my key signed, I get my name legally changed to "John Doe". As such, I get my passport, etc, reissued under "John Doe". Does this suddenly mean my key is invalid? If so why? What if my email address of [EMAIL PROTECTED] was still valid? Would it be OK to sign a UID for "John Doe" if the UID was "Brian May <[EMAIL PROTECTED]>" or "John Doe <[EMAIL PROTECTED]>", but I didn't have any proof of ever being "Brian May"? Why/Why not? What if my past email address was something cryptic, like [EMAIL PROTECTED], how would you know if this was suppose to belong to "Brian May" or "John Doe"? What if I got my name legally changed to "Branden Robinson"? Shouldn't I be able to get my key signed? Just because my name happens to be the same as some other person on this planet... Or would it be better if I invented an alias? Then my key ID wouldn't match my legal ID. What if everyone knows me by an alias, but I haven't/don't want to change my legal name? "Rusty Russell" is one well known example. If my key uses my real name, people may not realize it is me. I can't help but wonder if we have become to obsessed with signing a key to a particular name, that we have lost track of what we are trying to achieve. Just because the name matches (or is almost identical) does not mean it is the same person. Even if this key has hundreds of trusted signatures and the name is identical, it still doesn't mean it must be the same person. You could improve security if you do the tedious task of sending an email to every address, using a password decided on at the meeting[3]. This is step is considered "optional". However [3] doesn't give the full details for this to be secure, either. You would need: * ensure nobody else sees the shared password. The password for every person should be different. Writing it down could be unsafe, but not writing it down could lead to memory loss. * to test eve
Re: Upgrading to Debian sarge
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes: Brian> [EMAIL PROTECTED]:~# apt-cache show libc6 | grep MD5sum MD5sum: Brian> ab0895ee6d8d2cf3b6906eb5228e5c25 Brian> [EMAIL PROTECTED]:~# md5sum Brian> /var/cache/apt/archives/libc6_2.3.2.ds1-20_powerpc.deb Brian> 69301110f8865edd7f2f93d79ad6a715 Brian> /var/cache/apt/archives/libc6_2.3.2.ds1-20_powerpc.deb Brian> Then again, this package looks old, so maybe the entire Brian> mirror is old, and no longer usable. Hang on, please disregard this part of my post, the mirror is up-to-date, but I was comparing with the old version of the deb file I last successfully downloaded. Stupid! The fact remains that (presumable all 600Meg) files downloaded directly from this mirror were corrupt, according to apt-get. Hmmm. My /var/cache/apt/archives has only 124Meg failed uploads, I wonder where the rest went. Anyway, the correct results for my test are: [EMAIL PROTECTED]:~# md5sum /var/cache/apt/archives/partial/libc6_2.3.2.ds1-22_powerpc.deb.FAILED 17a6aff5f72df60d303fbce0258d2962 /var/cache/apt/archives/partial/libc6_2.3.2.ds1-22_powerpc.deb.FAILED [EMAIL PROTECTED]:~# apt-cache show libc6 | grep '^Size' Size: 4231786 [EMAIL PROTECTED]:~# apt-cache show libc6 | grep MD5sum MD5sum: ab0895ee6d8d2cf3b6906eb5228e5c25 -rw-r--r-- 1 root root 4231786 May 12 12:47 /var/cache/apt/archives/partial/libc6_2.3.2.ds1-22_powerpc.deb.FAILED Which md5sum is right? The file size is correct. Hmmm, The archive looks broken: [EMAIL PROTECTED]:~# dpkg -c /var/cache/apt/archives/partial/libc6_2.3.2.ds1-22_powerpc.deb.FAILED drwxr-xr-x root/root 0 2005-05-11 08:53:05 ./ drwxr-xr-x root/root 0 2005-05-11 08:52:49 ./sys/ drwxr-xr-x root/root 0 2005-05-11 08:53:31 ./lib/ -rwxr-xr-x root/root 94420 2005-05-11 08:53:11 ./lib/ld-2.3.2.so -rw-r--r-- root/root 11384 2005-05-11 08:53:11 ./lib/libanl-2.3.2.so [...] -rw-r--r-- root/root 84720 2005-05-11 08:53:16 ./usr/lib/gconv/BIG5.so -rw-r--r-- root/root222144 2005-05-11 08:53:16 ./usr/lib/gconv/BIG5HKSCS.so tar: Read 2308 bytes from - tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now dpkg-deb: subprocess tar returned error exit status 2 So the file sizes all look correct, but the files are corrupt. Looks like time to switch mirrors. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
shared libraries, bug 313094
Hello, Very recently somebody filled a bug against on of my packages, #313094. In brief, the library soname changed without me realizing it, and the package made in into the sarge release before anyone noticed. This means that a) (old) packages that linked with the old library won't work with the new library. b) recent packages that linked with the new library won't work with the old library. I added to the bug report saying I did not consider it worth fixing, because the only breakage occurs if you upload from a version that **no longer exists**[1] and was **never distributed in any stable release of Debian**. However somebody else has upgraded the severity of the bug to serious, making it a release critical. The person offered no explanation as to why they felt it was serious, or why they disagreed with my assessment. I am guessing that this means that the Debian administrators will have to go back in time, and prevent my package from getting released with sarge, but I didn't think Debian had the funds for a time machine . So what do people think? * Is this a bug? * Does it need fixing? * Is serious really appropriate? * What is the best way to fix this? - Should I change the name libdar2 to libdar3? Or should I wait until libdar4? - Should I add the (yucky) version dependency as suggested by the bug reporter? My personal opinion is that it isn't really a bug, because it only is only an issue for people who used the now obsolete version from a previous testing/unstable. My understanding is that while Debian supports upgrades from stable-->stable, we don't necessarily guarantee upgrades from testing will work flawlessly. Comments anyone? Notes: [1] Not counting hurd-i386, this platform would appear to be months behind. I don't think the bug reporter used hurd though. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#313094: shared libraries, bug 313094
>>>>> "Steve" == Steve Langasek <[EMAIL PROTECTED]> writes: Steve> I've attached a couple of files that are a snapshot of a Steve> more intelligent solution for library soname/shlibs Steve> handling that I'm working on, which I would like to see Steve> widely adopted by library maintainers as early as possible Steve> in the etch cycle. There are still some unresolved issues, Steve> though, and I haven't gotten a chance to talk to the Steve> debhelper maintainer about this at all yet, so take it with Steve> a grain of salt for now. :) Sounds like a much needed feature, IMHO. Good like for getting your changes integrated into debhelper. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keysigning without physically meeting ... thoughts?
>>>>> "Steve" == Steve Langasek <[EMAIL PROTECTED]> writes: >> Is this process "correct"? Or did something go seriously wrong >> here? If it was correct, why was it correct? If it was wrong, >> why was it wrong? For anyone who didn't pick it up; I lied: <[EMAIL PROTECTED]> isn't my email address. Steve> Many people consider all of options a), b), and c) to be Steve> inappropriate, and will instead encrypt each of the uid Steve> signatures individually and mail them to the corresponding Steve> email address, to verify that you control each address. I didn't see any key signing HOWTO or FAQ that mentioned this, not even the Debian guide. Do you have a reference? However, if I was able to intercept email to <[EMAIL PROTECTED]> (maybe I have exploited a security hole in master.debian.org that hasn't been discovered/fixed yet), this wouldn't help. Even if you looked up Debian web pages for [EMAIL PROTECTED], you still wouldn't verify that this isn't really my address, as real name is only out by one character. Typo? (Good think Brian Mays doesn't seem to be watching this thread...) My point though is that I could have taken my dodgy key into a keysigning session, and people adhering to many standard keysigning would not notice anything wrong, even if I couldn't intercept the mail. This would mean: * If I was a new Debian maintainer, I could submit my key to the official Debian keyring, with only the Brian May <[EMAIL PROTECTED]> key ring, and use this to upload packages. If I deliberately made an upload, say of the PCMCIA packages, which was a Trojan horse, Brian Mays would get the blame, not me. * If I was able to intercept Brian Mays email, I might be able trick people into sending encrypted email using my signed and verified key, instead my Brian Mays signed and verified key. That way I can read "his" encrypted email. * Alternatively (assume Brian Mays wasn't an existing developer), I could intercept his email when he supplies his key to Debian for the first time, and replace it with my own. This key would then be installed in the Debian keyring. To make sure this happens, I could intercept previous emails and changed "Brian Mays" to "Brian May" and his phone number to my phone number (in case somebody ring up and verify the keyid). (disclaimer: I haven't read the current maintainer procedures; this might be harder then stated). Note: People from time to time do get confused and send me bug reports that should have been sent to Brian Mays, such confusion could work to the benefit of a would be attacker. >> I can't help but wonder if we have become to obsessed with >> signing a key to a particular name, that we have lost track of >> what we are trying to achieve. Just because the name matches >> (or is almost identical) does not mean it is the same >> person. Even if this key has hundreds of trusted signatures and >> the name is identical, it still doesn't mean it must be the >> same person. Steve> Certainly, it doesn't mean that they're the same person. Steve> Who has asserted that this is the case? Just because there Steve> may be more than one person with the same real name using Steve> PGP doesn't invalidate the practice of ensuring that the Steve> name on a key is the same as the person's real name. I was under the impression that signing was implemented so you could trust that keyid 00530C24 with the fingerprint "9918 7E12 ABAF 54EA 9C9E 27A5 B828 A71C 0053 0C24" really was the person everyone knows as "Brian May". That way, if you want to send my a secure email, but never have met me in person, but you know a trusted friend (Fred) how has met me in person, and has signed my key, you can still communicate to me securely. After all, I thought this was the whole point of key signing. However, it seems that key signing only verifies * the name on my UID matches my "legal" name. * (optional) that I can read email to the email address in the UID. For the first part, so what if my legal name is "Brian May"? Does this have any significance to the open source community? Maybe the name "Brian May" matches the name I use on emails, then again, maybe it doesn't. Or maybe somebody else is using that name on emails. There is no way to verify that keyid 00530C24 is the same person who made all of these interesting contributions, and not the person who writes Trojan horses 24 hours a day and also happens to have the same name, unless said contributions are signed by the same key. When Fred signs my key, he might think I am the first person, when in fact I might be the later. Nowhere does it state on
Re: TODO for etch ?
>>>>> "Florian" == Florian Weimer <[EMAIL PROTECTED]> writes: Florian> You should set the clock using NTP *before* starting any Florian> daemons. ...which of course is a problem if the daemons are required to setup the network connection to the NTP server... e.g. network tunnels and DNS servers both might need to be started first before the NTP server can be contacted. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: raidtools2 -> mdadm change: woes and problems
>>>>> "Martin" == Martin Michlmayr <[EMAIL PROTECTED]> writes: Martin> * Clemens Schwaighofer <[EMAIL PROTECTED]> [2005-06-21 Martin> 14:44]: >> Are there any kind of documents describing how to move from >> raidtools safely to mdadm without loosing a raid? Martin> http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#s-mdadm Hello, On 2 of the systems I have upgraded, I had serious problems with mdadm. The documentation said that there was no need for a config file, and I never used a 2.2 kernel, so the paragraphs starting with "If your RAID array was created on a 2.2 Linux kernel patched with RAID" seem irrelevant. However, after rebooting, the raid devices would renumber themselves starting from /dev/md0 and up. This meant the entries in /etc/fstab were now wrong. I tried starting /dev/md4 manually, but I got /dev/md0 instead. Eventually, I got /dev/md4 up and running, manually, and the computer resumed booting. After rebooting the computer, and the same problem reoccurred... Repeat previous paragraph numerous times with different variations. I tried assembling the RAID with the --update=super-minor option (as well as all the other options), but it didn't seem to help. In the end, I gave up and changed /etc/fstab to the new system. I no longer have access this machine, the other machine doesn't seem to have the problem anymore. How is this meant to work? -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#315298: ITP: yaird -- Yet Another mkInitRD
>>>>> "Jonas" == Jonas Smedegaard <[EMAIL PROTECTED]> writes: Jonas> YAIRD is a sysfs-based initrd builder. It determines Jonas> which modules to load based on the same algorithms as Jonas> hotplug. Unlike Debian's stock initrd-tools, the kernel Jonas> being booted need not support the now-deprecated devfs. . Jonas> This version builds the newer cpio format initrds, even Jonas> though the stock Debian configuration uses the older Jonas> format. Thus, having cramfs compiled into the kernel is Jonas> not necessary. YAIRD supports only kernel 2.6. Jonas> I am in good dialogue already with upstream about the Jonas> Debian packaging. I was wondering when an ITP would show up for this package... Maybe I am thinking too much in the future, but I would really like to see yaird in Debian be able to use klibc in Debian for all the user tools (I believe there is already an ITP for klibc). -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC version change / C++ ABI change
>>>>> "Matthias" == Matthias Klose <[EMAIL PROTECTED]> writes: Matthias> - Rebuild C++ applications, which do not depend on any Matthias> other C++ library besides libstdc++. Matthias> - Rename and rebuild C++ libraries, which do not depend Matthias> on any other C++ library besides libstdc++. Presumably applications which are built using the same source as a library that meets the 2nd criteria should also be built. Otherwise we wouldn't get anywhere... I am specifically thinking of dar here, it contains a library and an application that uses this library in the one source, by the above criteria I could rebuild the library but not the application, which seems pointless. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-uk] Sun have (probably) patented apt-get
trademark infringement. Eric Goldhagen, a member of the free technology training group InterActivist Network, said: "The fact that somebody, just by claiming to own a word, can intimidate large companies and powerful law firms shows the damage, to an extent, is already done." In the movie realm, Stoller says that he wrote to Sony in March, objecting to Columbia Pictures' plan to call its navy film Stealth. The next month Columbia asked the Federal Court in Chicago to rule that using the word as a movie title did not violate copyright law. Stoller, who has filed a counterclaim, says he will not back down. "I will police and protect the stealth mark against all," he said. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-uk] Sun have (probably) patented apt-get
>>>>> "Turbo" == Turbo Fredriksson <[EMAIL PROTECTED]> writes: Turbo> YEARS (!) ago I wrote the script that did the pre-upgrades Turbo> to 'bo' (I _think_ it was to 'bo' any way :). It basically Turbo> only ftp'd (or was it wget?) required packages from the Turbo> Debian GNU/Linux FTP site(s), installed them and then Turbo> allowed the user/admin to continue with the upgrade... Turbo> Now, that seems like 'prior art' to me (even to apt-get :). Did you publish it? I think it only counts as prior-art if you published it in some public forum (not sure of the exact criteria). If it was a private thing, then it doesn't count. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about kill(1)
>>>>> "Adeodato" == Adeodato Simó <[EMAIL PROTECTED]> writes: Adeodato> I also have heard (but I'm not sure how often does this Adeodato> happen, if at all) that it is usefult to have it as a Adeodato> built-in when your system is in a state when it can't Adeodato> create more processes. In practise whenever that happens, and if I am lucky enough to have a terminal open, and if I am not dumb enough to accidently close the window, I don't know what the PID is of that CPU hungry/memory hungry process is in order to kill it. This happened to me approx a week ago. I wanted to write a wrapper around subversion that set umask before calling subversion, but instead the wrapper recursively called itself. I thought subversion was just being slow. It never considered the possibility it was the reason my computer subsequently went very slowly until it was unusable. It took me two reboots of the computer before I finally realized the DOS attack was from *my* own script! It took me another reboot to fix the problem properly. Sometimes it pays to use the full pathname to the executable... -- Brian May <[EMAIL PROTECTED]>
Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)
>>>>> "Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes: Santiago> Well, I consider the idea that old bugs deserve more Santiago> attention than new bugs (or non-old bugs) completely Santiago> flawed. I wonder how many old bugs are either fixed (but not marked as fixed) or irrelevant (if another solution was used). I suspect that there would be a high percentage of such bugs. Santiago> Bugs do not increase their severity by age. A wishlist Santiago> bug which is ten years old is still a wishlist bug. A Santiago> normal bug which is ten years old is still a normal Santiago> bug. An important bug which is ten years old is still an Santiago> important bug (well, modulo the fact that the important Santiago> severity might not exist ten years ago :-). True. However, I think it is easy to forget about old bugs and concentrate only on the new. After all who wants to spend considerable time gong over old bugs, attempting to work out if they are still relevant, for situations that you are never likely to encounter yourself, when you could be fixing "real" problems (as in problems that effect you)? Maybe the process of reviewing old bugs could be improved. I find the current process very clumsy: 1. Review bugs in web browser. 2. Identify questionably bug that you haven't already looked at before today. 3. Inspect bug report, in new window, install package, install source, inspect as required. Open up new browser windows to find information as required. 4. Make changes as required to source code. 5. Enter one/more emails to either forward bug upstream, change tags, or close the bug. 6. Go back to step 3. 7. Fix up the all the silly typos made in every BTS email sent so far and retransmit. (note: this is after the BTS has decided to respond). 8. upload the changes to source code. 9. realize that I forgot to sign the upload due to a bug in by pbuilder wrapper script, create a *.commands file to send to the upload queue to delete the old upload and reupload again. It would be good if this process could be simplified and/or made more error resistant. For example: 1. Client program that lists all bugs and has the ability to mark bugs. Ability to sort bugs in order of when you last looked it one. This information should be stored on maintainers computer, not the BTS. Even better, if you could attach a short summary/note to each one for your use, e.g. "need to talk to XYZ about this", "this user is an idiot", "I think this has been solved but I need to check X first", or "as of 1/1/2005 this bug is still waiting on X" that you don't want to appear in the BTS. This should be immediately visibly without having to select the bug and scrolling to the bottom. This way you can get a clear picture of which bugs require immediate attention, and which bugs you consider "too-hard" or "too-time consuming" right now, or are waiting on other outside events. 2. Client program with provision for sending updates to the BTS, but caching the updates until they finally appear in the BTS. Either that or fast response time from the BTS. 3. Environment/scripts to enable better testing, updating, and recompiling packages even if it is based on a non-preferred distribution, e.g. if you use stable, but the bug report is against unstable or vice versa. pbuilder is good and building packages against other distributions, it is not so good (at the moment anyway) for testing arbitrary packages in arbitrary distributions (except via pre-written scripts), because it was designed for building not interactive testing. There is the "pbuilder login" operation, but it doesn't give you access to your newly created package. 4. Make dupload obsolete, and replace with dput. Make dput the default in debrelease. I think dput would have prevented me uploading my unsigned package. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about kill(1)
>>>>> "Goswin" == Goswin von Brederlow <[EMAIL PROTECTED]> writes: Goswin> Try ctrl/atl/shift + print/scroll/pause combinations on Goswin> the console. Or alt+sysrq+h if thats enabled in your Goswin> kernel. You get a process listing with one of the first Goswin> and the second can do a lot more. Thanks for reminding me, I need to remember these keystrokes. How does it work? On my system, I push shift+ctrl+alt with my 1st hand, any two of print/scroll/pause with my 2nd hand. At this stage, I get a user friendly manual with "showTasks" as one my options. With my third hand I push the T button, and get what looks like a complete stack trace that overflows the dmesg buffer, let alone the screen. Oh wait, I can't do that, I just remembered I only have two hands... Maybe this has changed in the 2.6 kernels. I don't think it will work from X-Windows when the system is too bogged down to switch to a text console though... -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)
>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED] (va, manoj)> writes: Manoj> ! [1] ??? Manoj> ! [2] ??? Manoj> Are we sure we want someone who is routinely this Manoj> incompetent to help with bug triage? Seems to me we would Manoj> be bette off without such substandard help; anyone this Manoj> incompetent is probably creating more problems than they Manoj> are solving. Are you implying that if I cannot write and maintain a pbuilder wrapper script that produces perfect results every time, regardless of regular interruptions, that I am incompetent? You must be perfect! Which means the fact I could not have any definitions of [1] or [2] in your message must be my fault. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: compromise of gluck.debian.org, lock down of other debian.org machines
Hello, What is the situation with gluck? I am cut off from debian-devel, while my mail is accumulating on gluck, as I can't log in with my DSA key. I was under the impression from the security announcement that DSA logins should still be working. Unfortunately, the ssh connections hang immediately after authentication succeeds. I tried contacting James Troup previously, but got no response. In the meantime I am concerned that my BSMTP mail spool on gluck must be getting huge. (I also have some important issues I want to discuss on debian-devel concerning etch). Thanks. (PS: Please send responses directly to me for obvious reasons) [EMAIL PROTECTED]:~$ ssh -v gluck.debian.org OpenSSH_3.8.1p1 Debian-krb5 3.8.1p1-7, OpenSSL 0.9.7e 25 Oct 2004 debug1: Reading configuration data /home/bam/.ssh/config debug1: /home/bam/.ssh/config line 2: Deprecated option "FallBackToRsh" debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to gluck.debian.org [192.25.206.10] port 22. debug1: Connection established. debug1: identity file /home/bam/.ssh/identity type -1 debug1: identity file /home/bam/.ssh/id_rsa type -1 debug1: identity file /home/bam/.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version 3.9p1 debug1: no match: 3.9p1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-krb5 3.8.1p1-7 debug1: Miscellaneous failure No credentials cache found debug1: Miscellaneous failure No credentials cache found debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 zlib debug1: kex: client->server aes128-cbc hmac-md5 zlib debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'gluck.debian.org' is known and matches the RSA host key. debug1: Found key in /home/bam/.ssh/known_hosts:219 debug1: ssh_rsa_verify: signature correct debug1: Enabling compression at level 6. debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/bam/.ssh/identity debug1: Trying private key: /home/bam/.ssh/id_rsa debug1: Offering public key: /home/bam/.ssh/id_dsa debug1: Remote: Pty allocation disabled. debug1: Remote: X11 forwarding disabled. debug1: Remote: Agent forwarding disabled. debug1: Remote: Port forwarding disabled. debug1: Server accepts key: pkalg ssh-dss blen 433 debug1: read PEM private key done: type DSA debug1: Remote: Pty allocation disabled. debug1: Remote: X11 forwarding disabled. debug1: Remote: Agent forwarding disabled. debug1: Remote: Port forwarding disabled. debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new host key?: Re: compromise of gluck.debian.org, lock down of other debian.org machines
>>>>> "Osamu" == Osamu Aoki <[EMAIL PROTECTED]> writes: Osamu> Hi, Are you sure it is Debian gluck issue? It was working fine all the time up and until the compromise of gluck.debian.org. I haven't made any changes to the software on this computer, except to install the odd security fix. (I don't think any security fixes recently were for ssh either). So, from my point of view, it would appear to be a gluck problem. Hmmm. but it works fine from my Etch system. So maybe something has changed on gluck to break connections from ssh in sarge? (note: I am using ssh-krb5 - not that should matter - it authenticated OK). This is weird. Maybe I will need to experiment more. Osamu> It looks like gluck's new SSH uses new host identification. Osamu> I got following message when I connected with ssh -v ... Osamu> @@@ Osamu> @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ Osamu> @@@ Osamu> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Osamu> After removing old entries from ~/.ssh/known_hosts, I can Osamu> update host key and login. Yes, I got that. Osamu> PS: It would have been nicer if old hosk identification was Osamu> backuped and used in new system. They may have been concerned that the old host identification had been compromised, if so, changing it is the only thing they could do. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new host key?: Re: compromise of gluck.debian.org, lock down of other debian.org machines
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes: Brian> (note: I am using ssh-krb5 - not that should matter - it Brian> authenticated OK). Brian> This is weird. Maybe I will need to experiment more. I just tried the standard ssh in sarge, and get the same results. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
renaming network interfaces in udev
Hello,
For some reason I thought it was considered bad to rename eth* to eth* using
udev (race conditions and such).
However, after upgrading my systems to etch, I notice they do just this,
by default:
--- cut ---
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# UNKNOWN device (/class/net/eth0)
SUBSYSTEM=="net", DRIVER=="?*", SYSFS{address}=="00:0b:2f:4e:31:65", NAME="eth0"
# UNKNOWN device (/class/net/eth1)
SUBSYSTEM=="net", DRIVER=="?*", SYSFS{address}=="00:0b:2f:6d:19:2b", NAME="eth1"
# UNKNOWN device (/class/net/eth2)
SUBSYSTEM=="net", DRIVER=="?*", SYSFS{address}=="00:11:06:00:00:00:4b:2f",
NAME="eth2"
--- cut ---
Where eth0 is the only real network card on this system.
Unfortunately the above rules broke, and I ended up with eth0 being
not accessible. I only had eth0, and it wasn't the correct device.
I ended up renaming eth* in the above to net* and it works.
So I am really puzzled that the above is the default, because I
thought it was previously mentioned in this mailing list that you
cannot do the above due to race conditions or something.
Comments???
Although my system is working fine, I still get the following message on
startup (at least last time I looked):
udevd_event: rename_net_if: error changing net interface name eth1_temp to
eth0: timeout
which seems really confusing, IMHO.
Thanks for any advice.
Brian May
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new host key?: Re: compromise of gluck.debian.org, lock down of other debian.org machines
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes: Brian> (note: I am using ssh-krb5 - not that should matter - it Brian> authenticated OK). Brian> This is weird. Maybe I will need to experiment more. Brian> I just tried the standard ssh in sarge, and get the same Brian> results. My bad. I suddenly remembered I put access restrictions on this ssh key in my authorized_keys file at the remote host, so if someone somehow stole my key used to download email they would be restricted in what they can do. Including no-pty. A nice friendly message would have been nice though, as opposed to a hanging connection :-(. Thanks everyone who tried to help me. Now getting my email again (in fact it was working all the time, but I disabled the cron job when I saw interactive sessions weren't working :-( ). -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots hides bugs?
>>>>> "Martijn" == Martijn van Oosterhout <[EMAIL PROTECTED]> writes: Martijn> The only example I can think of is programs that use Martijn> configure to include support for anything they can find Martijn> installed. So you get different results depending on Martijn> what's installed in the buildd. It's a bug in the Martijn> packaging though, the maintainer should be doing Martijn> --enable-* or --disable-* for every option. The point Martijn> being that if you only build in a clean chroot you'll Martijn> never notice the problem. In my experience these bugs generally occur when a user installs a library that I have never used/heard of before - as such I generally miss them regardless of the build environment. Even if I did happen to have that library accidently installed for the build - I probably wouldn't notice that there is a minor (perhaps obsolete) feature enabled with no corresponding build-depends. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
>>>>> "Adeodato" == Adeodato <"=?utf-8?B?U2ltw7M=?=" <[EMAIL PROTECTED]>> >>>>> writes: Adeodato> But if you have a set of equal developers, bzr can be Adeodato> also used in a very similar way to Subversion, where all Adeodato> commits go to a central repository, and nobody has to Adeodato> collect them. It's just a matter of setting up a Adeodato> directory somewhere with the appropriate write Adeodato> permissions, and say "This is our canonical archive, the Adeodato> uploader will include what it's in there, nothing more, Adeodato> nothing less". For documentation on checkouts and bound branches, see http://bazaar-vcs.org/CheckoutTutorial http://bazaar-vcs.org/BzrUsingBoundBranches However, I am not convinced the following paragraph in the first page is correct: "Getting a checkout is generally faster than making a copy of a branch. The catch though is that whenever the checkout needs to look at the RCS data it will do so by accessing the branch. This holds true even if the branch is on some distant network that you accessed over the internet." To me, this sounds like it might be talking about a "lightweight checkout", as I believe a checkout is a complete copy of the branch, and network access is only required for commits or updates. "Bound branches in bzr take the place of remote 'checkouts' in systems like CVS or SVN and we refer to them as 'checkouts'. (bzr also supports "lightweight checkouts", which are like local checkouts, and aren't branches at all.)" Can anyone confirm/deny? My central dislike of bzr is bugs like: http://bugs.debian.org/380412 https://launchpad.net/products/bzr/+bug/54253 ...which unfortunately makes it unusable for some of my applications. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
>>>>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: Robert> Are you doing conversions from SVN? Current bzr uses 20MB Robert> of ram to do a native branch operation in similar Robert> circumstances. (bug report gets fixed, new at 11 :)). No, this was a conversion from baz. Might be the same bug though, hopefully. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
udev vs ldap at startup
Hello, I found my debian/testing computer was hanging on startup. udev was trying to contact LDAP (via NSS), but LDAP wasn't configured yet. After much trial and error I came up with: [EMAIL PROTECTED]:~# tethereal -r /root/tethereal -V | grep Filter: Filter: (&(objectClass=posixGroup)(cn=nvram)) Filter: (&(objectClass=posixAccount)(uid=tss)) Filter: (&(objectClass=posixGroup)(cn=tss)) Filter: (&(objectClass=posixGroup)(cn=fuse)) Filter: (&(objectClass=posixGroup)(cn=rdma)) Filter: (&(objectClass=posixGroup)(cn=rdma)) All of these users and groups mentioned in /etc/udev/permissions.rules, but none of these users or groups exist in /etc/passwd or /etc/group. So NSS naturally tried resolving them using LDAP (the second preference listed in /etc/nsswitch.conf). Is this a bug in Debian, or a sign of something weird (and perhaps ancient history) on my computer? What should be creating the above users/groups? Could udevd be changed to make debugging these issues easier, e.g. maybe some sort of verbose mode? Should I file any bug reports, if so what packages? Thanks. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
