Re: cdrtools
On Jul 13, 2006 at 16:06, Erast Benson praised the llamas by saying: > > I don't want to insist on (1) too. But I must agree with Joerg that it > is unclear if Makefiles could be called as "scripts for compilation". > > Makefiles are programs written in non-scripting language. To understand > what non-scripting language is, I googled this: > > """I'd define a scripting language as one which requires you to put $ > or whatever in front of variable names, and makes quoting strings an > optional construct, and does string variable substitution inside string > constants unless you force it not to with odd escape characters. > A non-scripting language is one which has simple, clear-cut lexical > conventions and parsing syntax.""" > You run an interpreter[0] which loads the source script files[1] and executes it. The language is a mixture of declarative and iterative programming. It clearly falls in the remit of scripts for compilation. Your paragraph appears to make python a non-scripting language. [0] make(1) [1] Makefile -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
On Jul 12, 2006 at 21:52, Art Edwards praised the llamas by saying: > I posted the same initial message on the three sites I thought were > appropriate. My plea for honesty was a measure of frustration with > what should be well-established packages. It turns out that in the newer > distros, the structure of /usr/X11R6 has changed dramatically enough > that it broke a .cshrc file that had worked for five years. > Your fustration clearly hasn't reached a point where you felt it necessary to file a bug report about the issues you've faced. We can not fix problems if we don't know about them. I can not find a single bug report about the issues you've raised and I can only find one bug submitted by yourself. Occasionally we need to make incompatible changes to improve the distribution. The NEWS.Debian for Xorg should detail these changes. I would imagine that this change is significant to warrant a debconf notice during upgrade. I would also hope it is detailed in the Etch release notes, although I'd understand if these haven't been completely written yet. Arguably there should be symlinks in place so that the upgrade doesn't break your .cshrc file. I would suggest filing a bug against the package that contais the file that has moved, explaining that there is a regression. Please file bugs in our BTS as it is the only way maintainers can reliably discover problems in the distribution. A large number of developers do not read any of the lists you've posted to. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
On Jul 12, 2006 at 20:39, Art Edwards praised the llamas by saying: > The point is that they do not work exactly fine. For ddd, the console at the > bottom is dead. > The keyboard fails. For grace(xmgrace) the same symptom is present in all > text boxes. This appears to be a pretty general problem because the same is > true for > Fedora Core 5, but not for Fedora Core 4. I have compiled xmgrace from > sources and > I have the same problem. I have done some looking and this problem surfaced > several years ago on a cygwin list. > Just for the record, when I invoke xmgrace from the command line, I receive > many errors like this: > > Warning: String to TranslationTable conversion encountered errors > Warning: translation table syntax error: Unknown keysym name: osfHelp > > I get exactly the same set from ddd. Again, this is true for AMD64 for both > Debian and for Fedora Core 5. > > Can you file bugs about both these issues using the reportbug tool so the maintainers are made aware of the problems. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Jun 08, 2006 at 12:19, MJ Ray praised the llamas by saying: > Wouter Verhelst <[EMAIL PROTECTED]> > > On Wed, Jun 07, 2006 at 05:42:27PM +0100, MJ Ray wrote: > > > Exactly! It's not our fault, so why should we indemnify Sun against it? > > > > If it's not our fault, it's not under our control, and we *don't* need > > to indemnify. That's what the FAQ says; and whether or not it has legal > > value, it *does* explain the interpretation Sun gives to its license. > > Changes to debian are made under debian's control (in theory). > > The reason I raised the indemnity in particular is that the FAQ > does not contradict this concern, so all the "should we ignore > the FAQ" debate didn't affect it. > > Quoth the FAQ: > | Simply put, Sun requires indemnification to limit its exposure for > | issues that are not Sun's fault. If your conduct or your OS causes >^ > | a problem that results in a third-party claim, then Sun expects you > ^^^ > | to take responsibility for it. Note that you are not indemnifying > ^ > | Sun against claims that are a result of something in Sun's code. You > | also are not indemnifying Sun against claims due to changes that a > | downstream distributor has made to your OS. > > You *are* indemnifying Sun against claims due to changes to your > OS whose inclusion you control. It's only downstream changes > that are excluded, not upstream. (AIUI, Gentoo can avoid this > neatly, with its users' install commands rebuilding the OS.) Out of interest, if[0] that is saying that "we agree that anything isn't Sun's fault isn't Sun's fault" (which is fair enough) then that doesn't mention anything about any warranty that we might offer. For the large majority of the software we ship, we disclaim any warranty what so ever. Can we not just disclaim all warranty on Sun's java like we do with the rest of our software, or is there something in the license that forces us to give a warranty? [0] I'm going by MJ's comments. I haven't had chance to check the actual license, so take this as a curious question from someone interested to know the answer. > > Do you agree, or what have I missed? > > Regards, -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353777: ITP: multixterm -- drive multiple xterms separately or together
On Feb 20, 2006 at 20:43, gregor herrmann praised the llamas by saying: > Package: wnpp > Severity: wishlist > Owner: gregor herrmann <[EMAIL PROTECTED]> > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > * Package name: multixterm > Version : 1.8 > Upstream Author : Don Libes <[EMAIL PROTECTED]> > * URL : http://expect.nist.gov/example/ > * License : Public domain > Description : drive multiple xterms separately or together > > Multixterm creates multiple xterms that can be driven together or > separately. > > In its simplest form, multixterm is run with no arguments and commands are > interactively entered in the first entry field. Press return (or click the > "new xterm" button) to create a new xterm running that command. > > Keystrokes in the "stdin window" are redirected to all xterms started by > multixterm. xterms may be driven separately simply by focusing on them. > > The stdin window must have the focus for keystrokes to be sent to the > xterms. When it has the focus, the color changes to aquamarine. As > characters are entered, the color changes to green for a second. This > provides feedback since characters are not echoed in the stdin window. > > Typing in the stdin window while holding down the alt or meta keys sends an > escape character before the typed characters. This provides support for > programs such as emacs. > Why would I want to use this? I now know how to use it, but I am still none the wiser as to what I could do with it. You might want to rewrite the description to include some use cases for multixterm. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging swftools for Debian
On Dec 17, 2005 at 18:48, Simo Kauppi praised the llamas by saying: > On Sat, Dec 17, 2005 at 03:21:41PM +0100, Lionel Elie Mamane wrote: > > No, you have to _remove_ the offending code. Not only "disable it at > > build-time", but not ship it at all, also not in the > > source. Distributing infringing source code, not only infringing > > binaries, is an infringement to the patent. (The right mailing list > > for discussing this particular point is debian-legal@lists.debian.org) > > Sorry for being a little vague. What I meant was that it uses liblame > library by default and that dependency can be disabled at build time. > > My understanding is that there is no offending code in the swftools > itself (at least I haven't noticed any, but I have to double check :) > > So, by disabling lame, it compiles and runs without users needing to > install any non-free software (the liblame library). The only drawback > is, that two of its binaries, avi2swf and wav2swf, cannot be used. Since > it has many other useful tools, I would like to see a Debian package > from it anyway. > The obvious solution would be something that ldopened liblame, so a user could install liblame if they wanted and get the functionality that they would have done if it was compiled in now. I believe that would be allowed in Debian, as we wouldn't be distributing anything patent-encumbered. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Dec 14, 2005 at 00:25, Anand Kumria praised the llamas by saying: > I'd like to congratulate our ftp-master team on their ability to timely > process packages progressing through the NEW queue. > > <http://ftp-master.debian.org/new.html> [1] > > I think you are an excellent example of people who are too busy for Debian. > > I must say that I am particularly impressed that you've managed to > frustrate our users for over 1 year with the package 'xvidcap'. > > Truly the works of Gods among both Debian users _and_ Debian developers. > > If only more of the infrastructure teams displayed your attitude and > dedication to volunteering for the benefit of all Debian users and > developers. > 2875 + Dec 13 18:17 Debian Installer ( 0) irssi_0.8.10-1_multi.changes is NEW 2876 + Dec 13 23:48 Debian Installer ( 0) irssi_0.8.10-1_multi.changes ACCEPTED 5.5 hours for a package to make it through NEW. I think you owe some people an apology. (Oh and to who ever processed irssi, thank you. Was a nice surprise to wake up to. :) ) -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: REMOVE ME FROM C4LL W4VE
On Sep 05, 2005 at 18:33, John Hasler praised the llamas by saying: > David Pashley writes: > > No, because that doesn't help the next person that searches on Google. > > If these people read the messages they find with their searches they > wouldn't post here. They don't. They just grab the address and spam us. > I'd hope that people actually clicked on the page in question rather than just seeing the email address in the summary on the google search. But yes, I agree that some users are occasionally stupid or lazy or both. Even still, it's worth trying to get http://lists.debian.org/debian-devel/2005/01/msg01444.html bumped up to the top of the google search all the same. > And helping people get off C4LL W4VE is not our job. > Surely we should do our best to help all computer users, not just Debian users. :) > > I believe I did reply to them. > > But I did not cc them. That was my point (I replied privately with an > entirely different message). My apologies, I was not refering to your email, but to the other person that replied and CCed the list. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: REMOVE ME FROM C4LL W4VE
On Sep 05, 2005 at 18:14, Bob Proulx praised the llamas by saying: > David Pashley wrote: > > > Don't follow up. Reply to them privately. > > > > No, because that doesn't help the next person that searches on Google. > > That is exactly the point. We DO NOT WANT people to find the Debian > mailing lists in any relation to that search. Every time someone > references it in a Debian mailing list it increases the page range on > Google. That is the problem. > > By referencing it here and keeping the Google page rank pointing here > you are actually hurting the users searching Google in the future. > > What would help the user would be to increase the page range of > (avoding the name here) in Google so that when they search for it that > Google actually points them to the right place. Which is exactly why my reply included the link to http://lists.debian.org/debian-devel/2005/01/msg01444.html so that page ranks higher than the individual posts from people asking to be removed. If every time some asks to be removed, we link to that email in the archive, it will be considered more important than the current emails that come out top. > > Bob -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: REMOVE ME FROM C4LL W4VE
On Sep 05, 2005 at 17:13, John Hasler praised the llamas by saying: > David Pashley writes: > > I believe it is far more useful to follow up to these emails providing > > useful information how to remove themselves and in particular link to the > > rather informative email from Josh Metzler[0] so that they might find out > > how to do it themselves rather than emailing the list. > > Don't follow up. Reply to them privately. No, because that doesn't help the next person that searches on Google. > > > On a side note, I believe that if you are going to follow up, you should > > at least be polite. > > Unless you cc them they are not going to see the follow up. They are not > subscribed. I believe I did reply to them. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: REMOVE ME FROM C4LL W4VE
On Sep 05, 2005 at 16:31, John Hasler praised the llamas by saying: > Please do not follow up to these messages. These idiots apparently Google > the phrase and then spam all the addresses they find. Posting about the > subject here just creates more hits. I believe it is far more useful to follow up to these emails providing useful information how to remove themselves and in particular link to the rather informative email from Josh Metzler[0] so that they might find out how to do it themselves rather than emailing the list. On a side note, I believe that if you are going to follow up, you should at least be polite. Whilst we may get annoyed with the number of people asking to be removed, they may not know the extent of the problem and they will not understand why they get an abusive response. I don't belive it does the image of Debian any good by sending such replies. [0] http://lists.debian.org/debian-devel/2005/01/msg01444.html -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: REMOVE ME FROM CALL WAVE
On Sep 05, 2005 at 15:34, [EMAIL PROTECTED] praised the llamas by saying: >I notified you, electronically a month or more ago to cancel my >subscription to CALL WAVE. >This billing has continued on my VISA bill for two or more months. > >Will you acknowledge receipt of this current message? I would like a >credit memo for the last month or two, but I know this action will not be >done on your part. Kill my account if you do nothing else. > >Harold C. Fisher >Phone No. 662-755-8726 >E Mail: [EMAIL PROTECTED] > >512 Kings Row >Yazoo City, MS 39194 > This list is for developers of Debian GNU/Linux (http://www.debian.org) and are not related to Callwave in any way. Please view http://lists.debian.org/debian-devel/2005/01/msg01444.html for information on how to remove yourself from Callwave. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#324296: ITP: ldapscripts -- Add and remove user and groups stored (using ldap)
On Aug 21, 2005 at 14:30, Pierre Habouzit praised the llamas by saying: > Package: wnpp > Severity: wishlist > Owner: Pierre Habouzit <[EMAIL PROTECTED]> > > > * Package name: ldapscripts > Version : 1.2 > Upstream Author : Ganaël LAPLANCHE <[EMAIL PROTECTED]> > * URL : http://contribs.martymac.com/ > * License : GPL > Description : Add and remove user and groups stored (using ldap) > > Ldapscripts are shell scripts that allow to manage POSIX accounts > (users, groups, machines) on an LDAP directory. They are similar to > smbldap-tools but are written in shellscript, not in PERL. > That should be Perl. Thinking about it, why would the user care what language it is written in. > They only require OpenLDAP client commands (ldapadd, ldapdelete, > ldapsearch, ldapmodify, slappasswd) and make administrator's work a lot > easier avoiding him to configure PERL and each library dependencies > (e.g. Net::LDAP). > Again Perl, but then should this paragraph really matter to a user? > These scripts are very simple to configure by not requiring any > Samba-related information (SID, profiles, homes, ...) : management of > Samba attributes is entirely done by standard commands (net, smbpasswd > et pdbedit) used together with the scripts. Moreover, most of the > configuration is guessed from the one of libpam-ldap, and everything > should work out from the box for most users. > > The scripts may be used independently - within command lines - or > automatically by Samba (like smbldap-tools), to handle POSIX information > within accounts before adding Samba information. > -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Procedure reminders on updating a lib package for a C++ ABI change
On Jul 16, 2005 at 14:27, Stephen Gran praised the llamas by saying: > This one time, at band camp, Ralf Treinen said: > > I have a (probably very stupid) question: > > > > On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote: > > > > > If one of your packages needs to be transitioned, DO NOT upload it before > > > the C++ libraries it depends on have successfully made the transition. > > > > Is there an easy way to find out which of the libraries a package > > depends are C++ libraries, and which are not? > > grep'ing for Depends: libstdc++ would probably do it (although I have > recently found that some, like libgmp3, only Recommend: libstdc++ as it > is a c library with c++ bindings). Shouldn't the C++ bindings be split out and depend on libgmp3 and libstdc++? -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#317430: ITP: apt-history -- logs the changes when installing
On Jul 10, 2005 at 12:26, Goswin von Brederlow praised the llamas by saying: > David Pashley <[EMAIL PROTECTED]> writes: > > > The backend does have it. It logs the information. Higher level tools just > > need to read the file in and display it. Why add grep functionality to > > dpkg when we already have a tool that does it rather well? > > Not to dpkg but to the dpkg package, or to the apt package. > > > If people really want a friendlier front end to package installation > > history, why not add history browsing/querying in the friendlier package > > installation tools > > Because then I would have to start using aptitude just to see what I > did last night in dpkg. > No, you can just use grep on /var/log/dpkg.log. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#317430: ITP: apt-history -- logs the changes when installing
On Jul 10, 2005 at 07:01, Goswin von Brederlow praised the llamas by saying: > David Pashley <[EMAIL PROTECTED]> writes: > > > I'm wondering if this wouldn't be better added as a feature to > > aptitude/synaptic, as people who would use apt-get or dpkg would > > probably know grep. The people he was targetting are more likely to use > > one of the package selection tools. > > Why not have it in dpkg and have aptitude or synaptic use it in turn? > Why limit it to higher level frontends when the backend can do it for > everything? > The backend does have it. It logs the information. Higher level tools just need to read the file in and display it. Why add grep functionality to dpkg when we already have a tool that does it rather well? If people really want a friendlier front end to package installation history, why not add history browsing/querying in the friendlier package installation tools -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#317430: ITP: apt-history -- logs the changes when installing
On Jul 09, 2005 at 19:36, Goswin von Brederlow praised the llamas by saying: > Nico Golde <[EMAIL PROTECTED]> writes: > > > Ok it seems that I am the only one interrested in this > > package. I will close the bug. > > Thanks for your help! > > Regards Nico > > Please don't. Rather do what people suggested: > > 1.) adapt the script to use the dpkg.log > > The dpkg log is overly detailed and probably confusing to normal > users. Your output seems to be much pretier. Read in the logfile and > extract the relevant information. Can't be much harder than parsing > the status file. > > This has also the advantage that usage of dpkg directly will show up > in your output. > > 2.) contact the apt or dpkg maintainers > > Talk to them about inclusion of apt-history (or dpkg-history in dpkg) > in their package. People are against creating yet another package when > the functionality clearly belongs inside an existing one. > I'm wondering if this wouldn't be better added as a feature to aptitude/synaptic, as people who would use apt-get or dpkg would probably know grep. The people he was targetting are more likely to use one of the package selection tools. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#317430: ITP: apt-history -- logs the changes when installing
On Jul 09, 2005 at 12:22, Nico Golde praised the llamas by saying:
> Hallo David,
>
> * David Pashley <[EMAIL PROTECTED]> [2005-07-09 13:20]:
> > On Jul 09, 2005 at 12:12, Nico Golde praised the llamas by saying:
> > > > Coreutils is required. Why is the ability to do something without it an
> > > > advantage?
> > >
> > > You can do almost every thing with with tools like, grep,
> > > sed, awk etc. but in my opinion this should be so easy as
> > > possible to everyone. Not everybody is familiar with grep
> > > etc. but apt-history show should be no problem.
> > >
> > > Regards Nico
> >
> > function apt-history () {
> >grep " $1 " /var/log/dpkg.log
> > }
>
> That depends of the knowledge of shell functions.
> Please download the package and test it before you judge.
> If you then think that the package is overload I close the
> bug.
> Thanks Nico
The script hooks into DPkg::Post-Invoke and parses the status database
and records the same information that the dpkg.log stores. Basically you
end up with the information twice. You would be better off parsing
dpkg.log. I think you should file a wishlist bug against dpkg to include
it in that package. It isn't worth creating a package just for a 178
line python script.
--
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#317430: ITP: apt-history -- logs the changes when installing
On Jul 09, 2005 at 12:12, Nico Golde praised the llamas by saying:
> Hallo Matthew,
> >
> > Coreutils is required. Why is the ability to do something without it an
> > advantage?
>
> You can do almost every thing with with tools like, grep,
> sed, awk etc. but in my opinion this should be so easy as
> possible to everyone. Not everybody is familiar with grep
> etc. but apt-history show should be no problem.
>
> Regards Nico
function apt-history () {
grep " $1 " /var/log/dpkg.log
}
--
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#317430: ITP: apt-history -- logs the changes when installing
On Jul 09, 2005 at 01:14, Nico Golde praised the llamas by saying: > Ok, now I had a look on the log file. > I think apt-history is different. If you want you can see > the same info but the log is a typical logfile. You have to > use grep and other coreutils to get for example the new > version of a package and the displayed version of the > package before because the infos aren't listed in context in > the logfile. It is easier than building the information apt-history > gives out of the logfile. > Example: > > sudo apt-history show upgrade > 2005-07-09 00:12:03: upgrade gstreamer0.8-alsa=0.8.8-3 > 0.8.10-1 > 2005-07-09 00:12:03: upgrade libbonobo2-common=2.8.1-2 > 2.10.0-1 > 2005-07-09 00:12:03: upgrade gnome-desktop-data=2.10.1-2 > 2.10.2-1 > 2005-07-09 00:12:03: upgrade libgimp2.0=2.2.7-1 2.2.8-2 > 2005-07-09 00:12:03: upgrade findutils=4.2.22-1 > 4.2.22-2 > 2005-07-09 00:12:03: upgrade e2fslibs=1.37+1.38-WIP-0620-11.38-1 > 2005-07-09 00:12:03: upgrade dselect=1.13.9 1.13.10 > 2005-07-09 00:12:03: upgrade libgnome-keyring0=0.4.2-10.4.3-1 > 2005-07-09 00:12:03: upgrade login=1:4.0.3-35 > 1:4.0.3-36 > 2005-07-09 00:12:03: upgrade zlib1g-dev=1:1.2.2-4 > 1:1.2.2-7 > 2005-07-09 00:12:03: upgrade libgcrypt11-dev=1.2.0-11.1 1.2.1-1 > 2005-07-09 00:12:03: upgrade telnet=0.17-29 0.17-30 > 2005-07-09 00:12:03: upgrade libqdbm-dev=1.8.30-1 > 1.8.30-2 > > I think it is a nice little tool to furbish the information so I think > it would be good to have this in the tool chain. > And please correct me if I missed something > Regards Nico > beebo root% grep upgrade /var/log/dpkg.log | tail 2005-07-09 01:17:02 upgrade eog 2.10.0-0.2 2.10.2-0.1 2005-07-09 01:17:09 upgrade gaim 1:1.3.1-2 1:1.4.0-1 2005-07-09 01:17:10 upgrade gaim-data 1:1.3.1-2 1:1.4.0-1 2005-07-09 01:17:14 upgrade gcj 4:4.0.0-1 4:4.0.0-2 2005-07-09 01:17:15 upgrade gij 4:4.0.0-1 4:4.0.0-2 2005-07-09 01:17:19 upgrade libasound2 1.0.9-2 1.0.9-3 2005-07-09 01:17:19 upgrade libsensors3 1:2.9.1-3 1:2.9.1-4 2005-07-09 01:17:20 upgrade ucf 1.18 2.000 2005-07-09 01:17:23 upgrade libavc1394-0 0.5.0-2 0.5.1-1 2005-07-09 01:17:24 upgrade ssh 1:4.1p1-5 1:4.1p1-6 What else am I missing? Does apt-history hook into /etc/apt/apt.conf or just a wrapper around dpkg.log? -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#315903: ITP: evilfinder -- proves that any given subject is evil
On Jun 27, 2005 at 00:46, W. Borgert praised the llamas by saying: > Package: wnpp > Severity: wishlist > Owner: "W. Borgert" <[EMAIL PROTECTED]> > > Package name: evilfinder > Version : 666(?) > Upstream Author : Michal Zalewski <[EMAIL PROTECTED]> > URL : http://lcamtuf.coredump.cx/evilfinder/ef.shtml > License : under clarification, hopefully GPL > Description : proves that any given subject is evil > > Example output for input "Debian": > Do we really need this in the archive? Can we not add this to another package under games? It is rather small and doesn't serve a significant amount of functionality. david% wc -l *.c 746 ef.c 71 shuffle.c 817 total -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Jun 09, 2005 at 09:09, Tollef Fog Heen praised the llamas by saying: > * Christian Perrier > > | > Again, do not mess with cultures you do not understand. > | > | Do you have real examples? > > IRC. An example is the current irssi in Debian which doesn't do > recoding between different locales. (And that is needed, since IRC > doesn't have a charset concept and there are still loads and loads of > users out there with clients which interpret everything as Latin1.) > One of the new features of irssi 0.8.10 (when it gets released) is recoding support built in. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Jun 08, 2005 at 08:07, Ian Campbell praised the llamas by saying: > On Wed, 2005-06-08 at 07:54 +0200, Benjamin Mesing wrote: > > Debian already has a nice way to fix this -- if X doesn't start it tries > a couple of times and then disables itself and offers to show you the > log or drop you to a login prompt. > > I don't know if this functionality is from the X packages or from gdm > etc. but it is a much better solution than the band aid offered by > run-levels... > Plus you can always boot at runlevel 1 if you really don't want to attempt starting X. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#304266: ITP: sdate -- never ending september date
On Apr 12, 2005 at 18:01, Ron Johnson praised the llamas by saying: > On Tue, 2005-04-12 at 16:52 +0100, Ross Burton wrote: > > On Tue, 2005-04-12 at 17:10 +0200, Christoph Berg wrote: > > > Re: sean finney in <[EMAIL PROTECTED]> > > > > > > Is there any real-life use for this program? > > > > > > > > > > No. > > > > > > > > then please don't put it in debian. > > > > > > Which of the other games in Debian do serve a purpose? > > > > Games serve a purpose: they entertain the user. What is the purpose of > > sdate? > > Entertain the user, of course, in a things-were-better-back-in- > the-good-old-days kind of way. > > Sort of like Edith and Archie singing "Those Were The Days". > I suspect most games entertain the user for more than three seconds. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#303667: ITP: cycle -- calendar program for women
On Apr 08, 2005 at 01:20, Miriam Ruiz praised the llamas by saying: > Package: wnpp > Severity: wishlist > Owner: Miriam Ruiz <[EMAIL PROTECTED]> > > > * Package name: cycle > Version : 0.3.0 > Upstream Author : Oleg S. Gints <[EMAIL PROTECTED]> > * URL : http://cycle.sf.net/ > * License : GPL > Description : calendar program for women > Does cycle have any features over mencal[0] or periodic-calendar[1]? [0] apt-cache show mencal [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=283655 -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#301892: ITP: cuetools -- tools for manipulating CUE/TOC files
On Mar 30, 2005 at 12:38, Frank Küster praised the llamas by saying: > Alban Browaeys <[EMAIL PROTECTED]> wrote: > > > Le Tue, 29 Mar 2005 10:10:06 +0100, David Pashley a écrit : > > > >> What are CUE and TOC files? What are they used for? It would be useful > >> if you say a little bit more about them. > > > > Well i do not know if one can define CUE file shortly . This is like "ar" > > file but for cdroms "images" (not in the iso meaning, the raw image). > > This enables to store on disk what we want on the cdrom when we mix > > different type of data type on the medium. > > > > It could be a mix of iso9660, audio, video ... > > > > Kudos to the one who manage to explain it in a sentence :) > > You don't need to explain it so that everybody understands the format. > It should be sufficient to say as much as will allow to decide whether > the package is useful for me, or not. What about: > > , > | cuetools is a set of programs that are useful for manipulating CD/DVD > | image files in CUE format and Table of Contents (toc) files. The CUE > | format is used for mixing different data types on one medium (iso9660, > | audio, video,...). The package includes these utilities: > | > |- cueconvert: convert between CUE and TOC formats > |- cuebreakpoints: print the breakpoints from a CUE or TOC file > |- cueprint: print disc and track information for a CUE or TOC file > | > | It can also be used to split a large audio file into many > | small files according to a CUE or TOC. > ` > > Regards, Frank That looks much better. Mentioning CD/DVD makes quite a bit of difference if you ask me. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#301892: ITP: cuetools -- tools for manipulating CUE/TOC files
On Mar 29, 2005 at 01:07, Joshua Kwan praised the llamas by saying: > Package: wnpp > Severity: wishlist > Owner: Joshua Kwan <[EMAIL PROTECTED]> > > * Package name: cuetools > Version : 1.3 > Upstream Author : Svend Sorenson <[EMAIL PROTECTED]> > * URL : http://developer.berlios.de/projects/cuetools/ > * License : GPL > Description : tools for manipulating CUE/TOC files > > cuetools is a set of programs that are useful for manipulating CUE sheet > (cue) files and Table of Contents (toc) files. The package includes these > utilities: > >- cueconvert: convert between CUE and TOC formats >- cuebreakpoints: print the breakpoints from a CUE or TOC file >- cueprint: print disc and track information for a CUE or TOC file > > Probably the most popular use is to split a large audio file into many > small files according to a CUE or TOC, for example: > > cuebreakpoints disc.cue | shntool split disc.wav > > I've prepared packages at http://people.debian.org/~joshk/cuetools/. > What are CUE and TOC files? What are they used for? It would be useful if you say a little bit more about them. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Mar 08, 2005 at 14:58, Ben Hill praised the llamas by saying: > On Tue, 2005-03-08 at 00:46 +0100, David Härdeman wrote: > > first of all, this might be slightly off-topic for the debian-devel > > list, but I've got the impression that it's already been solved by some > > DD's and might prove interesting to others (including non-DD's such as > > me). > > I use a very small USB key for my gnupg and ssh keys. I had created > the .gnupg and .ssh directories in my home a long time ago, so I > formatted the USB device as ext2, and copied the two directories to the > USB device as ssh and gnupg. > Ideally I want to keep the disk formatted as vfat so it is usable on other operating systems and use an ext2 loopback filesystem. Getting the system to mount that is the hard part. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: UK Meetings
On Mar 08, 2005 at 14:40, Ben Hill praised the llamas by saying: > On Mon, 2005-03-07 at 23:52 +, Will Newton wrote: > > Try the debian-uk list: > > > > http://www.chiark.greenend.org.uk/mailman/listinfo/debian-uk > > Perfect, thanks! > You may also want to join #debian-uk on OFTC too, which is where most of us hang out. > -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#294209: ITP: reminiscence -- REminiscence is a rewrite of the engine used in the game Flashback from Delphine Software
On Feb 08, 2005 at 14:08, Niv Altivanik praised the llamas by saying: > Package: wnpp > Severity: wishlist > Owner: Niv Altivanik <[EMAIL PROTECTED]> > > > * Package name: reminiscence > Version : 0.1.2 > Upstream Author : Gregory Montoir <[EMAIL PROTECTED]> > * URL : http://membres.lycos.fr/cyxdown/reminiscence/ > * License : GPL > Description : REminiscence is a rewrite of the engine used in the game > Flashback from Delphine Software > > Description: free implementation of Delphine Software's FlashBack engine > REminiscence is an engine capable of runing any game based on the > FlashBackengine. > . > To actually make use of ScummVM, you currently need to get the orginal > FlashBack game data-files > Did you mean ScummVM there? -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#293561: ITP: player -- music player and organizer for GNOME
On Feb 04, 2005 at 13:39, Steve McIntyre praised the llamas by saying: > Dan Korostelev wrote: > >Package: wnpp > >Severity: wishlist > >Owner: Dan Korostelev <[EMAIL PROTECTED]> > > > >* Package name: player > > Version : 0.1pr1 > > Upstream Author : Milosz Derezynski <[EMAIL PROTECTED]> > >* URL : http://linux-media.net/player/ > >* License : GPL > > Description : music player and organizer for GNOME > > > > Player is a graphical music player and organizer for GNOME 2 > > desktop environment. > > > > It uses GTK+ for its user interface, GStreamer for playback and > > SQLite for working with music database. > > > >(expect packages soon on http://mentors.debian.net/, we still need > >libvisual to be packaged and uploaded.) > > Please use a less generic name. "player" alone means very little and > is likely to cause confusion. > Also, what advantages does player have over muine or rhythmbox? The UI looks identical to rhythmbox, but without some useful features, like being able to output to more than just alsasink. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292831: udev: udev prevents X from beeing started
On Jan 31, 2005 at 15:44, Wouter Verhelst praised the llamas by saying: > Op ma, 31-01-2005 te 09:40 -0600, schreef Ron Johnson: > > On Mon, 2005-01-31 at 15:58 +0100, Christoph Hellwig wrote: > > > On Mon, Jan 31, 2005 at 12:45:42PM -0200, Henrique de Moraes Holschuh > > > wrote: > > > > On Mon, 31 Jan 2005, Ron Johnson wrote: > > > > > Unfortunately, GNOME depends on hal, and hal depends on udev. > > > > > > > > If it does indeed depend on udev, how does it work under kernel 2.4 at > > > > all? > > > > > > Because that statement is utter bullshit. There's a single and optional > > > gnome component that wants to use hal. > > > > A single and optional gnome component that is very, very useful. > > apt-cache show magicdev > > No, that does not just work on Linux 2.4. > Except, I believe magicdev polls the kernel, rather than responding to kernel event. Plus HAL provides more features than just noticing if a CD has been inserted into a drive. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292831: udev: udev prevents X from beeing started
On Jan 31, 2005 at 04:46, Hamish Moffatt praised the llamas by saying: > On Mon, Jan 31, 2005 at 05:31:03AM +0100, Joey Hess wrote: > > Marco d'Itri wrote: > > > My package works as designed, but let me know if you can design > > > something better. > > > > Oh, so it's udev that's responsible for what IIRC is a race that can > > cause X to not see the ps/2 mouse if the module is loaded as part of X's > > setup? Nice design. :-P > > > > FWIW, we have worked around this bug in d-i unstable for at least i386 > > and amd64 by always putting psmouse in /etc/modules. > > I did an amd64 install last week from the (then) current install image > and didn't end up with psmouse in /etc/modules; I added it by hand when > I found that udev was preventing X from starting. :-( > > I am yet to submit a report; my bad. > Surely the solution is for hotplug/discover to load it during bootup. Could hotplug use mdetect? -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Jan 26, 2005 at 09:59, Henrique de Moraes Holschuh praised the llamas by saying: > On Wed, 26 Jan 2005, David Pashley wrote: > > > Since there are at least two packages containing their own version of > > > invoke-rc.d, having a search path policy for policy-rc.d can be > > > messy and is prone to be unstructured and uncoordinated. > > No, it is not. invoke-rc.d *HAS* to be coordinated, and implemented by every > initscript system. The maintainers of these packages are well aware of > that fact. > > The better fix IS to add an extra line to both incarnations of invoke-rc.d > (sysv-rc's and file-rc's) to look under /usr/local/sbin first. > > > It seems a bit excessive having a package for just one script. Is there > > not another package this could go in instead? > > No. Either it has to go on a package of its own, or it has to have the > functionality folded into file-rc and sysv-rc. > Then I suggest a patch is submitted to both file-rc and sysv-rc. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Jan 26, 2005 at 08:26, Marc Haber praised the llamas by saying: > Package: wnpp > Severity: wishlist > Owner: Marc Haber <[EMAIL PROTECTED]> > > * Package name: policyrcd > Version : 0.1 > Upstream Author : Marc Haber <[EMAIL PROTECTED]> > * URL : http://wiki.debian.net/index.cgi?ZugSchlus > * License : GPL > Description : policy-compliant interface from invoke-rc.d to local > config files > > contains a script which is linked via the alternatives subsystem to > /usr/sbin/update-rc.d. This script looks for a local policy-rc.d > script in /usr/local an /etc, providing a policy- and FHS-compliant > way to interface invoke-rc.d with a local script. > > Without this package, a local admin wanting to cleanly interface with > invoke-rc.d is forced to drop a local binary to /usr/sbin and/or > manually interface with the alternatives system. Both ways of doing > this are clumsy and error-prone, so this package offers a clean way of > interfacing with sysvrc and file-rc. > > Since there are at least two packages containing their own version of > invoke-rc.d, having a search path policy for policy-rc.d can be > messy and is prone to be unstructured and uncoordinated. > > Hence, having a dedicated package is the clean way of doing things. > It seems a bit excessive having a package for just one script. Is there not another package this could go in instead? -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292183: ITP: gtkpizza -- Pizza takeaway managment program written in gtk
On Jan 25, 2005 at 16:08, Guglielmo Dapavo praised the llamas by saying: > Package: wnpp > Severity: wishlist > Owner: Guglielmo Dapavo <[EMAIL PROTECTED]> > > * Package name: gtkpizza > > Version : 0.1.0 > Upstream Author : Guglielmo Dapavo <[EMAIL PROTECTED]> > * URL : http://www.dapavo.it/ > * License : (GPL) > Description : Pizza takeaway managment program written in gtk > > You can manage orders, external/internal customers, pizza types. It also > has reports. > Is it really neccessary to say it uses gtk? Could it be used to manage items other than pizzas? If so you might want to mention that it could be adapted for all types of fast food. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: scripts to download porn in Debian?
On Jan 25, 2005 at 11:03, Frank Küster praised the llamas by saying: > Ron Johnson <[EMAIL PROTECTED]> schrieb: > > > > http://slipgate.za.net/dosage/downloads/changelog > > I stand corrected. But in this case, the short description "dosage -- > powerful webcomic downloader / archiver" isn't really appropriate. > It appears that this is what the program does, so why is it an inaccurate description? -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292026: ITP: libapache2-mod-hash2 -- apache2 module which provides a good way to hash servername
On Jan 24, 2005 at 16:51, Julien Delange praised the llamas by saying: > Package: wnpp > Severity: wishlist > Owner: Julien Delange <[EMAIL PROTECTED]> > > > * Package name: libapache2-mod-hash2 > Version : 1.0 > Upstream Author : Yann Droneaud <[EMAIL PROTECTED]> > * URL : http://eloise.ouvaton.net/%7earch/archzoom.cgi/[EMAIL > PROTECTED]/mod-hash2--main--1.0 > * License : GPL > Description : apache2 module which provides a good way to hash > servername > > mod_hash2 build a digest from the servername to create a united > directory scheme. As digest could collide, mod_hash2 add the > real servername to distinguish between hash value (and allow human > to do inverse lookup on directory path). > > mod_hash2 use libmhash2 to create the digest, so it support all the > hash algo libmhash2 supports. > > Real document root is built with the default document root, > append the hash servername path, the servername, > optionnaly a name of a subdirectory and the URI requested. > I have absolutely no idea what this package does. May I suggest rewriting the description slightly. Perhaps adding a use-case might be worthwhile. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#291964: ITP: ocurl -- OCaml bindings for libcurl
On Jan 24, 2005 at 09:58, Enrico Tassi praised the llamas by saying: > Package: wnpp > Severity: wishlist > Owner: Enrico Tassi <[EMAIL PROTECTED]> > > > * Package name: ocurl > Version : 0.2.0 > Upstream Author : Lars Nilsson <[EMAIL PROTECTED]> > * URL : http://sourceforge.net/projects/ocurl > * License : MIT/X > Description : OCaml bindings for libcurl > > The Ocaml Curl Library (Ocurl) is an interface library for the > programming language Ocaml to the networking library libcurl. > Would it not be better to name the package ocaml-curl? Maybe we need a general policy on language bindings names. It is a shame we have libfoo-bar-perl and python-foobar. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debianized ndiswrapper-source is better on SourceForge
On Jan 10, 2005 at 16:24, William Ballard praised the llamas by saying: > On Mon, Jan 10, 2005 at 10:15:06AM -0600, Ron Johnson wrote: > > "shove ... down everybody's throat" > > "You've F'd it up beyond all recognition" > > I filed a bug nice and the guy closed it about 14 minutes later > immediately saying "there is no problem." The maintainer is dead-set on > following his chosen course. module-assistant is the way forward. It is easier for users than using make-kpkg. I believe he is doing the right thing. Do you hvae the bug number? > > The upstream Debian package is better, and this broken would should be > replaced with it. > > It is broken possibly because it is a rc version and upstream is using a released version. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious problem with the tty terminal - HELP!
On Jan 10, 2005 at 15:08, Simon Raven / Eric S. Côté praised the llamas by saying: > Le lun 2005-01-10 a 09:19:17 -0500, Bjorn Johansson <[EMAIL PROTECTED]> a dit: > > > > Hello. > > > > I have a problem with the text (tty) terminals. The problem is that if I > > move > > from the x-server to an tty text terminal I can't go back and I can't > > switch > > to another tty terminal either. The only way to get back to X is to kill > > the > > x-server. > > > > This problem has arised since I deleted all files i /lib. Then I reinstalled > > the gnome and kde system with the apt tool. And I have also reinstalled > > the base system, but it seems I've missed something, because this is not > > the > > default behaviour after a fresh install. And when I mean a fresh install, I > > mean installing from scratch with an empty harddisk. > > > > PLEASE, can someone help? You might find installing debsums and running "debsums -a -s" useful. This might tell you packages which have files missing in /lib. You can then do "apt-get --reinstall install foo-package" to replace that file. This all assumes that all your packages have md5sum files. I'm sure you could write a bash script that took dpkg --get-selections, and Contents.gz and checked it against the existence of files in /lib. Failing that, reinstall > > reinstall. > > > System: Debian Sarge "testing" > > > > Björn Johansson > > > > eric c./ > -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debianized ndiswrapper-source is better on SourceForge
On Jan 10, 2005 at 14:31, William Ballard praised the llamas by saying: > On Mon, Jan 10, 2005 at 03:45:56AM -0500, Andres Salomon wrote: > > Gee, the latest ndiswrapper has a bug. Downgrade to the one in > > testing, or upgrade to the one I uploaded today. It's not the > > end of the world. Perhaps you could even be helpful and let me > > know whether rc2 hangs in the same way that rc1 does. > > You don't get it: The SAME version that you packaged does not > hang the system the way he packaged - rc1. > > Listen, I'm checking out of this one. The guy upstream has > produced a perfectly working Debian package. You've F'd it > up beyond all recognition in some misguided effort to make > it symmetric with everything else. > > Everything the other guy has made works: the version you > made is horribly broken. > > Unless I've got this very wrong, but the ndiswrapper source supplied in the SF deb is different to the source provided in the Debian package in the archive. This suggests it isn't down to the packaging. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OSPF and distance vector routing source code
On Dec 17, 2004 at 09:44, j.s.dhilip praised the llamas by saying: >hello, > Would you please told me how can I get source code for OSPF? > Makes a nice change from dualling banjos. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Dec 10, 2004 at 16:30, Will Newton praised the llamas by saying: > I have looked at it. And I don't think it is an acceptable thing to ship as > part of an operating system. I am an atheist and a liberal but the majority > of people in the world are not. I don't think it is an acceptable thing to ship as it has no use. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione.
Re: Status of this ITP?
On Dec 08, 2004 at 17:15, Luis R. Rodriguez praised the llamas by saying: > > > Its been more than a year now. What's the status of this ITP? This is > ridiculous. If you can't package it, then say so so others can come in > and do the job. We deserve a freedesktop.org package by now in debian. > > Get off your ass. > This is an ITP for KDrive, the experimental xserver. It is not the X.org xserver. I'm not sure this is what you think it is. I appriciate that english may not be your first language, but the tone of the email was not exactly friendly. People work on Debian because they want to. Having people shout at them isn't the best incentive to get them to do voluntary work. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione.
Re: Bug#213897: ITP: libclass-dbi-abstractsearch-perl -- Abstract Class::DBI's SQL with SQL::Abstract
On Oct 03, 2003 at 12:03, Stephen Quinney praised the llamas by saying: > Package: wnpp > Version: unavailable; reported 2003-10-03 > Severity: wishlist > > * Package name: libclass-dbi-abstractsearch-perl > Version : 0.03 > Upstream Author : Tatsuhiko Miyagawa <[EMAIL PROTECTED]> > * URL : http://search.cpan.org/CPAN/authors/id/M/MI/MIYAGAWA/ > * License : GPL or Perl artistic > Description : Abstract Class::DBI's SQL with SQL::Abstract > > Class::DBI::AbstractSearch is a Class::DBI plugin to glue > the SQL::Abstract module into Class::DBI. I have absolutely no idea what this does. Can we have a slightly better description. What can I do with this package? > > -- System Information: > Debian Release: testing/unstable > Architecture: i386 > Kernel: Linux mizar 2.4.22 #1 Thu Aug 28 16:46:35 BST 2003 i686 > Locale: LANG=C, LC_CTYPE=C > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. pgpuRPTS5y8Vc.pgp Description: PGP signature
Re: unicode
On Jul 25, 2003 at 09:38, Adrian 'Dagurashibanipal' von Bidder praised the llamas by saying: Content-Description: signed data > On Wednesday 30 October 2002 14:11, Sergey V. Spiridonov wrote: > > > Is Debian aims to be unicode compatible system? > > IANADD - but I guess the answer definitely is yes. But it's not a very urgent > task. > > > If yes, then should I mail a bug report against packages which are not > > able to handle unicode? > > If you manage to test for the right things next time, yes :-) > You might also ask on the i18n lists if you suspect a problem. > > I think in most cases this would be a minor (or at most normal) bug. > Submitting a patch will in most cases help more in getting it fixed quickly > than a raised severity does. > > cheers > -- vbi > Probably the biggest unicode problem I have noticed is with man and/or less where it can't display dashes correctly. At least it doesn't seem to work out of the box. -- David Pashley [EMAIL PROTECTED] pgpEdYXqG1nKo.pgp Description: PGP signature
Re: Why do system users have shells?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 25 November 2002 9:34 pm, H. S. Teoh wrote: > On Mon, Nov 25, 2002 at 09:53:22PM +0100, Russell Coker wrote: > > On Mon, 25 Nov 2002 20:39, H. S. Teoh wrote: > > > On Mon, Nov 25, 2002 at 12:10:44PM -0700, James Hamilton wrote: > > > > I'm curious why system users such as bin, sys, and nobody have > > > > /bin/sh as a shell instead of a noshell program or /bin/false. > > > > > > [snip] > > > > > > Possibly because otherwise, you cannot run any shell scripts as that > > > user. (This may also apply to more than shell scripts, but I'm not sure > > > about that.) > > > > sudo, start-stop-daemon, su -s > > > > Why can't people read man pages before replying? > > [snip] > > But there are programs that don't use su -s. E.g., custom logins > (non-anonymous) from wu-ftpd will fail if the login shell is set to > /bin/false. This, of course, is probably a bug, but I suspect a lot of > things will break if (some) system users have no shell. > I remember trying to set all(most/some) system accounts to /bin/false and the only thing I noticed breaking was fetchmail. Of course there may have been others, but fetchmail persuaded me to revert to /bin/sh. Would it be worth filing a bug about this? - -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE94z2YYsCKa6wDNXYRAgesAJ4wSUV6Nc6SESWZC1ObDRvK27i18wCfXlAz llLPDoAOcFxhhLA/4GI0f0k= =bNH+ -END PGP SIGNATURE-
Re: Are we losing users to Gentoo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 20 November 2002 9:50 am, Andrew Lau wrote: [snip] > Whenever someone rants about Gentoo's processor optimisations > and states some overinflated performance boost such as 10%-20%, all I > can do is make a a feeble rebuttal stating that it's more like (insert > low figure without much solid evidence - e.g.. 5%) with exceptions > such as glibc, X, multimedia applications, mozilla and OpenOffice. So > then they counter that it's still an increase. Ok, so what strengths > does Debian have to make a comeback with? Unlike Gentoo, Debian has > quality assurance and security teams. We have a strict policy and bug > resolution procedures. But they won't listen and still say Gentoo. > [snip] > I know that there's plenty of logistical/mirroring reasons as > to why we shouldn't duplicate a lot of the i386 tree by creating a > i686 tree, but could we seriously not consider a partial i686 > optimised tree as a compromise to attract some of the Gentoo users > back with our strengths in policy and testing? If not, then we need to > find something else to offer to attract the cutting-edge > enthusiast. The worst thing we could do is dismiss this > completely. Remember the days when Slackware and Yggdrasil were the > 'elitist's choice'? I certainly don't ever want to see Debian even > come close to sinking. [snip] Sorry if this has already been mentioned, but my answer to this would be pentium-builder and apt-src or apt-build. Debian already has the infrastructure to be a source-based distribution, just that no-one uses it. - -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE94fSsYsCKa6wDNXYRAhn0AJ9zjbh74AO1vPiWhRGcreMgZQGrYQCcDby6 XdcbwAbIEmlXz1/1TvZRBmg= =83uO -END PGP SIGNATURE-
exim vs. exim-tiny (was: RFC: OpenLDAP and TLS/SSL)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 21 August 2002 2:57 pm, Stephen Frost wrote: > * Torsten Landschoff ([EMAIL PROTECTED]) wrote: > > Today I was convinced by Stephen Frost that I can just enable SSL support > > in the OpenLDAP packages I maintain. No problem so far, but: > > > > - libldap2 is Priority: important > > - this change will make it depend on libssl0.9.6 > > - libssl0.9.6 is Priority: standard > > [...] > > > Any suggestions welcome > > Hey all, > > I already explained my feelings about this to Torsten but since we're > moving it to -devel I'll lay out my thoughts here too. > > First off, crypto is important to us and I think we tend to feel that > it is important for our users as well. Thus, I see libssl0.9.6 being > made Priority: Important as a good option. > > If there are too many other issues with making libssl0.9.6 important > (though it only Depends: on libc and isn't very big?) then I would > think that we are very concerned about the size and would therefore > recommend that ldap support be removed from exim or exim be split into > exim-tiny for Important and exim-big with everything enabled. Of > course, exim support being modified to be modular would be an > excellent option but would require a decent amount of work I think. > > Not having any exim with support for mysql in Debian has been a > problem in the past for Debian users that I know. > As the main person in #exim on OPN, I've seen several people ask about exim with mysql or postgres support. There is a bug about having mysql support in exim in debian. (Wouldn't it be nice to have voting in debbugs?). I realise that exim does not have the sanest of build systems, but is there any chance of getting two exim packages built? Maybe the ability to choose a different patch to enable mysql et al support via a envvar. That way I can instruct people to rebuild exim. - -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9ZDvSYsCKa6wDNXYRAoU3AJ9WNEf5881o6GOp3aJxBrYj1cGbrwCfYEV5 KaZa7qbKprMMjdNqsf4l1q4= =Ck+m -END PGP SIGNATURE-
Re: Bug#156617: general: Kde K menu is confusing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 14 August 2002 10:35 am, Thomas Schoepf wrote: > reassign 156617 kdebase > thanks > > > There is a 'K/Preferences/System' menu and there is also a > > 'K/system' menu. This is redundant and thus confusing. > > One is for system programs, the other for system settings. What's > redundant about that? > I'll prod calc later about seeing if it is possible to change K/System to "K/System Tools". This has been changed in kde3.1. as you now have a settings menu, but it does not replicate the kcontrol hierarchy. - -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9WkL1YsCKa6wDNXYRAm7zAJ0d0gFQVcR9hqbmuKyOFIfK2QV/8QCfQBtb 5cWC69G3Pir32IWswSQEhaE= =33aS -END PGP SIGNATURE-
