Re: RFS: kmenc15 - An advanced Qt/KDE MEncoder frontend.
On Tuesday 26 October 2004 04:52 pm, Oded Shimon wrote: > On Tuesday 26 October 2004 22:37, Shaun Jackman wrote: > > For your package to go in contrib, your dependency -- mplayer -- must > > exist in non-free. > > Really? I didn't know this. That's not surprising. Policy says (section 2.2.2, "The contrib section"): Examples of packages which would be included in contrib or non-US/contrib are: * free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution, and * wrapper packages or other sorts of free accessories for non-free programs. (disregarding any other reasons your package might not be suitable for the archive) Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Imagine if every Thursday your shoes exploded if you | | tied them the usual way. This happens to us all the | | time with computers, and nobody thinks of complaining. | \ Debian GNU/Linux http://www.debian.org -- Because. ---/ pgp2YpM0IhVbn.pgp Description: PGP signature
Re: How to handle libssl support?
On Thursday 11 November 2004 04:11 am, Juergen Salk wrote: > It seems in Sarge at least some of the crypto crippled versions > have just vanished into thin air. ...which is going to silently leave users running old versions of some software. links-ssl seems to have been replaced with a dummy upgrade package, but other *-ssl packages (eg, fetchmail-ssl) were just dropped. It seems to me that any crypto-enhanced package that was moved to main and renamed should have a dummy upgrade package in sarge. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Gil-Galad was an Elven king; | | of him the harpers sadly sing. | \-- (if (not (understand-this)) (go-to http://www.schemers.org)) ---/ pgpG1MglP2WR3.pgp Description: PGP signature
Re: How to handle libssl support?
On Thursday 11 November 2004 10:45 am, Mike Hommey wrote: > It is not necessary. Look at fetchmail, for instance: > Replaces: popclient, fetchmail-ssl, fetchmail-common > Provides: popclient, fetchmail-ssl, fetchmail-common > Conflicts: popclient, fetchmail-ssl, fetchmail-common, logcheck (<< > 1.1.1-9) > > I don't know and didn't check for the others *-ssl packages, though. Yes, but if you have fetchmail-ssl installed and not fetchmail, an upgrade will not install fetchmail. It might result in fetchmail-ssl being removed (since the new fetchmail-common doesn't provide the version it needs), but unless some other part of the system depends on fetchmail, you won't end up with fetchmail installed. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Almost Winter, Winter, Still Winter, and Construction. | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgpqFN6Bk79cH.pgp Description: PGP signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Wednesday 01 December 2004 06:55 pm, Manoj Srivastava wrote: > > But by this logic, Debian should include every bit of software it > > can -- if those countries with pesky copyright laws won't let us > > distribute it there, then we hope that portion of the world gets > > better in time. Debian will continue to practice freedom. > > I think this is mostly correct. So, do you think DeCSS should be included in main? Why or why not? Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "Next, consider a circle passing through infinity; that | | is, a straight line.." | \- A duck! -- http://www.python.org / pgpd8Y1YuUcYm.pgp Description: PGP signature
Re: ldap - a completely new method for fetching lists of packages?
On Thursday 02 December 2004 11:47 am, sean finney wrote: > exponentially faster How, exactly, is this "exponentially faster"? Is it guaranteed to run in logarithmic time relative to a normal download? Sorry to bug you, but I see this phrase being used a lot to mean "a whole lot faster" and it's one of my pet peeves. :) Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Wisdom is one of the few things | | that looks bigger the farther away it is. | | -- Terry Pratchett | \ Evil Overlord, Inc: http://www.eviloverlord.com --/ pgpoQkSIAoXsm.pgp Description: PGP signature
Depending on Virtual Packages (Public Service Announcement)
Just a reminder to everyone about how to depend on virtual packages. I thought this knowledge was widespread, but I recently ran up against this problem in one of our core packages. When your package Depends upon or Recommends a pure-virtual package P, you should always OR the dependency with a dependency on something that provides P, as a hint to the package manager (particularly apt). For instance, if you want to depend on an MTA, you should not write this: Depends: mail-transport-agent Instead, you should write something like this: Depends: exim4 | mail-transport-agent The reason is that when apt is trying to resolve dependencies, the first form will cause it to arbitrarily pick a package that provides "mail-transport-agent" for installation. This is really all it *can* do, since it has no way to choose between them. As a result, it might install exim4, ssmtp, nullmailer, or even courier-mta. In the last case, installing your package will pull in an entire Web server, which is probably not what you want! The second form avoids this problem by giving apt a specific package to try first. If the dependency is not satisfied, apt will try to select exim4 for installation, rather than grabbing a random provider of m-t-a. The same goes for Recommends, as those are also supposed to be installed automatically (although most frontends seem to ignore them). Daniel -- /------- Daniel Burrows <[EMAIL PROTECTED]> --\ | "Truly, you have a dizzying intellect." | |-- "The Princess Bride"| \- A duck! -- http://www.python.org / pgpNIjolcnQqT.pgp Description: PGP signature
Re: Depending on Virtual Packages (Public Service Announcement)
On Thursday 02 December 2004 09:07 pm, Chasecreek Systemhouse wrote: > So, you are saying that all we need to do is cross reference all the > co-dependencies for package or dselect scenario X? I don't understand your question. If you have a dependency on a pure virtual package, it should be preceded (and ORed with) a dependency on a real package so that apt behaves predictably. > Um, wouldn't that defeat the purpose of the package selection > automation process? I don't understand what this has to do with the previous question. > What would the formula be get dselect Desktop to actually install > Gnome on an Ultrasparc when there is a chain of co/required > dependencies failures? I don't understand what this has to do with Gnome or anything I said. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | The thing that really depresses me about my cynicism| | is that it's not as cynical as real life. | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgpjdAQRiOpxO.pgp Description: PGP signature
Re: charsets in debian/control
On Sunday 05 December 2004 03:32 pm, Jose Carlos Garcia Sogo wrote: > > Would Peter permit me a mild dissent? I prefer Latin-1. Reason: I can > > recognize and distinguish Latin-1 characters, even when I do not always > > understand the words they spell. Recognizing and distinguishing the > > characters is important to me. And not just to me. Imagine the dismay > > of a Korean user trying to read Arabic script in a control file. > > But the only field in UTF8 should be Maintainer, and that field should > have (IMHO) also a roman transliterate for the name, if you don't use a > latin charset (Greek, Arabic, Japanese, Chinese...) Well, when aptitude gets UTF8 support, it'll decode all the control fields that are mainly meant for human consumption: that means at least Description in addition to the Maintainer field, and maybe also Section. I don't see any reason to limit ourselves in the long term by sticking to Latin1 (or ASCII) just because none of us can read all of the languages that are available in the extended UTF8 namespace. If we want people to stick to certain subsets of UTF8, that should be determined in Policy, not the packaging software. If you want a practical concern (aside from, say, a general suspicion of building policy into software tools), consider these cases: -> Someone wants to translate the Description fields of all packages in Debian into Chinese or Arabic. What will they do if the package tools only support Latin-1? -> Someone wants to use the Debian packaging tools to create a new distribution for use in China. Again, what will they do if the package tools only support Latin-1? Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ |"We've got nothing to fear but the stuff that we're| | afraid of!" -- Fluble | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgpPb1jhTqyTk.pgp Description: PGP signature
Re: charsets in debian/control
On Tuesday 07 December 2004 12:44 am, Peter Samuelson wrote: > > Defining the character set as utf-8 means that any non-unicode > > capable application is going to have issues, yes. > > Postulate an app that is ignorant of character sets - we'll call it > "aptitude". Fixing it to make it accept utf-8 and spit out the correct > encoding for its LC_CTYPE is no harder than fixing it to make it accept > iso-8859-1 and spit out the correct encoding for its LC_CTYPE. > > And if the app already deals with charset conversions but assumes > iso-8859-1 input, then it's trivial to fix it to assume utf-8 input. This is not true. iso-8859-1 is an 8-bit charset, while Unicode is a 32-bit [0] charset. Storing and manipulating iso-8859-1 strings requires no changes to internal datatypes (only conversions for input and output); storing and manipulating Unicode means you have to switch to a completely different set of string-handling functions for all internal operations. In C++ you might be able to partly finesse this by creating a replacement string class, but if our program (call it "aptitude") is already using a complex replacement string class for some tasks, and this class assumes that characters are 8 bits wide, this might be a slightly non-trivial task, especially compared to handling iso-8859-1. Hypothetically speaking. :-) On the other hand, once the program is using Unicode internally, taking iso-8859-1 as input and producing it as output should be no problem. Daniel [0] According to the libc manual, only 16 bits have been assigned, but GNU systems use 32-bit encoding internally if the libc transcoding functions are used. -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | swapon /dev/ram | \--- News without the $$ -- National Public Radio -- http://www.npr.org ---/ pgpuGzR6Woq1o.pgp Description: PGP signature
Re: charsets in debian/control
On Tuesday 07 December 2004 10:17 am, Daniel Burrows wrote: > complex replacement string class Admittedly, "complex" might (hypothetically) be a bit of an exaggeration. :P Daniel -- /------- Daniel Burrows <[EMAIL PROTECTED]> --\ | You are in a maze of twisty little signatures, all alike. | \ Evil Overlord, Inc: http://www.eviloverlord.com --/ pgpdSwtA0vgWt.pgp Description: PGP signature
Re: charsets in debian/control
On Tuesday 07 December 2004 10:40 am, Richard Atterer wrote: > No, you do not have to do this. You can keep working with "char", the > changes when switching to UTF-8 will mostly have to deal with the fact that > one Unicode character is represented by more than one char. This means that > you need to use a different strlen function, take care only to chop strings > of char at character boundaries, ensure that input strings are actually > valid UTF-8, etc. This might work for programs that relatively blindly manipulate character strings and can pass them off to the terminal for processing. In fact, aptitude does a *lot* of processing and formatting of strings internally. That means, for instance: splitting strings into words and paragraphs, truncating strings, finding out how wide strings are. More importantly, it also makes significant (and increasing) use of strings annotated with the terminal attributes of each character (think colors, bold/reverse video, etc). Needless to day, it performs all of the above operations on those strings as well. All of these are impacted by extended charsets: for instance, you need to use a different function to find whitespace, and combining characters with their attributes requires the use of a structure where an integer previously sufficed. That's not to mention finding the length of a string, which is necessary to perform most types of layout. The changes that are necessary are at least: At a minimum, the class used for formatted strings will have to be re-targeted to support either formatted wide strings or formatted utf8 strings. If wide characters or are not used internally, it is also necessary to audit every occurrence of s.size() and check whether the length-in-memory or the length-in-characters of the string is being queried. If neither wide characters nor a utf8-specialized basic_string are used, it is necessary to audit every string constructor (which might cut a substring) and make sure that it doesn't play havoc with utf8 codings. Every use of isspace() and friends will have to be replaced with Unicode-aware equivalents. And that's just the problems I can think of off the top of my head. It's also necessary to use a completely different set of terminal i/o routines, but this is pretty much expected. None of these problems are insurmountable, of course, and I know pretty much how to solve must of them. However, it's also true that none of them exist *at all* when using iso-8859-1, which is why I object to the comment that it's no harder to handle utf8 than iso-8859-1. (in fact, if your terminal speaks iso-8859-1, aptitude will handle it just fine without any changes) Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Hi, I'm a .signature virus! | | Copy me into your .signature to help me spread! | \ The Turtle Moves! -- http://www.lspace.org ---/ pgpJ6zHEp3AWv.pgp Description: PGP signature
Re: dselect survey
On Thursday 09 December 2004 06:35 pm, Bernd Eckenfels wrote: > On Thu, Dec 09, 2004 at 10:27:50PM +, Roger Lynn wrote: > > The last time I used aptitude (about six months ago, from Testing), I > > found it difficult to specify how I wanted dependencies > > You just use "g" and resolve the dependencies? (Kind of same as in > dselect) If you want to find alternatives for a virtual package, you can use 'd' and 'r' to navigate the dependency lists. It's not as convenient as dselect, but it works. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "Do you know why the prisoner in the| |tower watches the flight of birds?"| | -- Terry Pratchett, _Reaper_Man_ | \-- (if (not (understand-this)) (go-to http://www.schemers.org)) ---/ pgptaUbdTIxuT.pgp Description: PGP signature
Re: dselect survey
On Friday 10 December 2004 04:23 pm, Bernd Eckenfels wrote: > On Thu, Dec 09, 2004 at 10:22:08PM -0500, Daniel Burrows wrote: > > If you want to find alternatives for a virtual package, you can use 'd' > > and 'r' to navigate the dependency lists. It's not as convenient as > > dselect, but it works. > > Well actually you can enter the package you dont want to have and see the > package which requires it. You can enter the package (all with enter) and > see the possible providers for a requirement and select one of it with +. That's true, but then you have to scroll past a lot of useless information; d/r (for Depends/Reverse Depends) will get you there quicker. Of course, bearing in mind that recent versions of aptitude (should) show the list of alternatives when you select the unwanted package, what would be really nice would be if you could Tab/mouse into the list and pick the alternative you want directly, the way you can in dselect... Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ |"We've got nothing to fear but the stuff that we're| | afraid of!" -- Fluble | \ Evil Overlord, Inc: http://www.eviloverlord.com --/ pgpEZhRKFSuHO.pgp Description: PGP signature
Re: Bug#285768: dselect survey
On Wednesday 15 December 2004 09:01 am, Simon Richter wrote: > aptitude could be taught to have "auto-installed" being Yes,No or > Unknown. Whenever a package that is in "Unknown" state could be removed > if it were only installed as a dependency, aptitude should list them in > the "actions to be performed" view as being still installed and unknown > whether they can be removed. Until I make a decision (which I am not > forced to do at this moment) the package would reappear in this list > everytime it could be deinstalled (i.e. until another package depending > on it is installed or a decision is made). It seems like "Unknown" would just be a synonym for "No", right? Presumably with a way to search for unknown packages (I think ~U isn't taken yet). Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "Inconceivable!" | | -- "The Princess Bride" | \ Evil Overlord, Inc: http://www.eviloverlord.com --/ pgpiEiMbkGLus.pgp Description: PGP signature
Re: Bug#285768: dselect survey
On Wednesday 15 December 2004 03:37 pm, Wouter Verhelst wrote: > > It seems like "Unknown" would just be a synonym for "No", right? > > Uh, yes. I think. > > You may want to explain that a bit more. Well, from the bug report, it looks like the proposal is to maintain the current behavior, but to set a different flag on packages that were conservatively assumed to be manually installed, so they can be switched later to automatic handling if desired. Sounds useful. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Thank you for reading me, but the real .signature is in another email. | \- Does your computer have Super Cow Powers? --- http://www.debian.org -/ pgpzIku2aqCBx.pgp Description: PGP signature
Re: Bug#285768: dselect survey
On Wednesday 15 December 2004 07:51 pm, Wouter Verhelst wrote: > You may also want to set a flag on packages that are assumed to be > automatically installed, but of which you have no information. aptitude never should assume that a package is automatically installed, unless it performs the automatic installation itself. I don't think any other option is really safe. (I *think* you're not talking about current behavior, but I thought I saw someone bring this up in the -devel thread that spawned this bug, and you just reminded me of it) > Consider libgnome2-perl: people may want to install that, even if there > is no dependency, to allow for debconf to provide a gnome frontend; > however, I can imagine there are also packages that have a dependency on > libgnome2-perl. > > Now consider a user who recently switched to aptitude after having used > a different frontend for a long while; this user had installed > libgnome2-perl manually (for the debconf frontend), but later on > installed just one package depending on libgnome2-perl to see what it > does. At that time, the switch to aptitude was made; but then the user > decided that the package using libgnome2-perl isn't useful enough, and > removes it again. > > What debfoster will do in that case, is present the user with > libgnome2-perl (and all packages whom only libgnome2-perl depends on and > for which no preference is yet known), and ask whether they should be > removed. It sounds to me like what you're proposing is something like: - If I see a new package installed by someone else, * if nothing depends on it, mark it "Unknown; probably manually installed" * otherwise, mark it "Unknown; probably automatically installed" Then you'd have two more classes of packages, in addition to manual and automatic: "Unknown; probably manually installed": I don't see doing anything especially fancy here, but there should be a way to show all of them on demand. "Unknown; probably automatically installed": If one of these packages is only [transitively] depended upon by some other packages in the same class, tell the user that they all are possibly unused. (for instance, in the preview screen) One problem is that the set of packages that are possibly unused isn't disjoint to the other sets of packages that aptitude displays, which could perhaps lead to some awkward situations. (what if a package is both upgradable and possibly unused? Which category is it listed in, or is it listed in both?) Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "Hah, I can just see a real playsmith puttin' a..a DONKEY in a play!" | | -- Terry Pratchett, _Lords and Ladies_| \-- (if (not (understand-this)) (go-to http://www.schemers.org)) ---/ pgpzJ1fg1NoVu.pgp Description: PGP signature
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?)
On Wednesday 05 January 2005 02:05 am, Ingo Juergensmann wrote: > When Joerg Jaspert is already doing the dirty daily work, why does James > still needs in place then? (Except he just stays in that position for a > transitional period until Joerg is taking over that task and job > completely. I would recommend that transitional period for other positions > as well.) Why does he need to be replaced at all? I think Debian is better off with small teams working key positions than single people. Daniel -- /------- Daniel Burrows <[EMAIL PROTECTED]> --\ | No-one remembers the singer.| | The song remains. | \ Debian GNU/Linux http://www.debian.org -- Because. ---/ pgpL2HJrbsAFz.pgp Description: PGP signature
Clanlib 0.7
Hi all, This is just a note for anyone who's looking for a project. I was just trying to compile some software, and it bombed out because I didn't have the right ClanLib version installed. I looked into the matter a little, and found a nearly two-year-old bug (#188449) asking for the library to be updated to the latest version. For people not familiar with it, ClanLib is a moderately popular high-level game programming library used by a number of different games. It has had a tendency to break API compatibility in the past, and it appears that the latest release is binary and source incompatible, so a lot of recent software is not compilable on Debian at all. Because the incompatibility is two-way, anyone who packages this will have to make allowances for installing both versions at once. Unofficial packages are available (see the bug), but will have to be reviewed for policy compliance and so on. And no, of course I don't have time to take care of this myself, or I'd have done it instead of posting a message here. It would be great if someone could get this into sarge, though, or people will be getting frustrating compile errors on Debian systems (barring a sudden change in how we release) for years and years to come. Daniel -- /------- Daniel Burrows <[EMAIL PROTECTED]> --\ | "Next, consider a circle passing through infinity; that | | is, a straight line.." | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgpXnQdJa8IjX.pgp Description: PGP signature
Re: Bug#287839: ITP: mxml -- small XML parsing library
On Friday 31 December 2021 08:38 am, Eduardo Marcel Macan wrote: I call dibs on his time machine ;-) Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Microsoft, n: | | A company that makes pretty good mice. | \- A duck! -- http://www.python.org / pgphFDVekdxD3.pgp Description: PGP signature
Re: dh_movefiles, tar vs. mv
On Friday 25 February 2005 12:36 pm, Frank Küster wrote: > Well, fine. But the question remains: dh_install uses cp, not mv. What > is the problem with using mv? And would it be safe to use mv if I only > move complete directories? I'd imagine that it doesn't use mv for the same reason "install" doesn't; ie, its purpose is to COPY files, not MOVE them. Anyway, I thought you were joking in your first message, but it looks like you're serious, so I'll answer this time. If you're copying between files on the same device, mv will use the rename(2) system call, which is an atomic operation: ie, it doesn't "copy" the source files at all, it just links them into the target directory. If you're copying between devices, mv will presumably copy the whole file before deleting it -- to actually remove a file "block-by-block" would mean a whole lot of totally pointless extra work in order to make the program less robust (there's no direct way to delete the first block of a file, so you'd have to either copy from the back or shift the whole file back a block at a time and then truncate it). Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ |"Is it too late to extricate myself| | from this plot line?" | |"Yes." -- Fluble | \-- (if (not (understand-this)) (go-to http://www.schemers.org)) ---/ pgpX29TkvNl7W.pgp Description: PGP signature
Re: dh_movefiles, tar vs. mv
On Saturday 26 February 2005 01:37 pm, Adeodato Simó wrote: > * Frank Küster [Sat, 26 Feb 2005 19:34:45 +0100]: > > I didn't look closely, but I think it might need quite some changes to > > the code. It seems dh_install uses cp -a for directories, and you cannot > > use hard links with directories (at least not generally, here on my ext3 > > $HOME it does not work. And I suspect it could end in great mess). > > I remember that I once modified my dh_install to use cp -al. That will > make each file be a hardlink, even if you copy a dir. It's fast. > > I wouldn't mind that dh_install accepted an option to behave like that. See bug #296917. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ |All generalizations are dangerous. | \ Evil Overlord, Inc: http://www.eviloverlord.com --/ pgpmqh7SGPS8n.pgp Description: PGP signature
Re: Popularity-contest http POST: call for testers
On Saturday 05 March 2005 06:48 pm, Bill Allombert wrote: > For that purpose, I have made an experimental popularity-contest package > that use both smtp and http. Please find it here: Have you considered uploading it to experimental? Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Afternoon, n.:| | That part of the day we spend worrying | | about how we wasted the morning.| \- A duck! -- http://www.python.org / pgpi6wedyCB1d.pgp Description: PGP signature
Re: Popularity-contest http POST: call for testers
On Sunday 06 March 2005 05:55 am, Bill Allombert wrote: > Not yet, because it does not report to the normal popcon account so I am > afraid that look a bit sneaky to just drop it in experimental without > warning users. Well, the idea would be to post here AND upload it to experimental, so people who want it can just fetch it from there. Daniel -- /------- Daniel Burrows <[EMAIL PROTECTED]> --\ | "Progress just means bad things happen faster." | |-- Terry Pratchett, _Witches Abroad_ | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgpIG6ZFVlHD1.pgp Description: PGP signature
Re: debian/NEWS.Debian / apt-listchanges woes
On Saturday 12 March 2005 12:38 pm, Dirk Eddelbuettel wrote: > | only has use if it's a transition package depending on the renamed > | package. Since this isn't what r-gnome will be as far as I understand > | you, you should simply stop building r-gnome from r-base. People > | upgrading will notice r-gnome will be uninstalled (if dependencies force > | that) > > Is that what will happen? I tend to force tight Depends on the same > version. So we'd upgrade from > > 2.0.1-4 for r-base-core and r-gnome > > to, say, at release time of R 2.1.0 > > 2.1.0-1 for r-base-core with no r-gnome. > > Wouldn't that block r-base because no suitable r-gnome is found for it? As far as I can tell, r-base doesn't have any dependency or recommendation on r-gnome. Maybe you mean that r-base will be prevented from upgrading because r-gnome requires the previous version -- you can deal with that situation by adding a Conflicts: r-gnome to r-base. This gives you the same situation as before, but without a bogus empty package and with an up-front warning to the user that r-gnome is going away. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "But what the eagle does not realize is that it is | |participating in a crude form of natural selection.| |One day, a tortoise will learn to fly."| | -- Terry Pratchett, _Small Gods_ | \- Does your computer have Super Cow Powers? --- http://www.debian.org -/ pgplqpkvjFUqC.pgp Description: PGP signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Monday 14 March 2005 07:49 am, Hamish Moffatt wrote: > Sure. Who's doing that on anything but i386/amd64/powerpc? Yes, I'm sure all those s390 users are running it on a machine in their basements... ;-) Daniel -- /------- Daniel Burrows <[EMAIL PROTECTED]> --\ | "But what *does* kill me bloody well leaves me dead!" | | -- Terry Pratchett, _Carpe Jugulum_ | \ Evil Overlord, Inc: http://www.eviloverlord.com --/ pgpweQ3xRkQbl.pgp Description: PGP signature
Re: [Help] How to fix a buggy prerm script in sarge? (was: Bug#338638: tetex-base: dies when /usr/local/ read-only)
On Sun, Nov 13, 2005 at 12:25:01PM +0100, Frank Küster <[EMAIL PROTECTED]> was heard to say: > we just received a bug report that is caused by a buggy prerm script > in the package in sarge (it fails because it doesn't handle read-only > /usr/local properly). Is there any way to fix this, except documenting > it in the release notes? If your old prerm fails, the new prerm should be called with "failed-upgrade" as its first argument (see Policy 6.4 and 6.5), so you can do any necessary workarounds there. Errors in postrm are handled similarly. Daniel signature.asc Description: Digital signature
Re: Spliting packages between pkg and pkg-data
On Mon, Nov 21, 2005 at 04:26:34PM +0100, Goswin von Brederlow <[EMAIL PROTECTED]> was heard to say: > Nicolas Boullis <[EMAIL PROTECTED]> writes: > > > On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote: > >> Hello Debian developers, > >> > >> When doing research about circular-deps, I looked at a lot of packages > >> that are split between a binary package and a data package. This is a > >> good thing since this reduce the total siez of the archive, however > >> there are simple rules that should be followed: > >> > >> 3) Keep the files that 'signal' executables in the same package than the > >>executable (e.g. menu file, program manpage). > > > > Why? I agree that it menu files and manpages are generally not that > > large, but what would it break to have them in pkg-data? > > (I would consider it strange to have such files out of the main pkg > > package, but it looks policy-compliant as far as I can see...) > > > > > > Nicolas > > foo depends on foo-data. But foo-data does NOT depend on foo. > > So an "apt-get install foo-data", while being useless, is consistent > for dpkg. After that you would end up with a menu entry for foo but no > foo binary. Shouldn't menu refuse to create menu entries for "foo" if the foo package is not installed? At least, I thought that's what ?package(foo): ... meant. Daniel signature.asc Description: Digital signature
Re: [RFC] xulrunner, shlibs, and dependencies.
On Sat, Dec 03, 2005 at 12:28:36AM -0800, Steve Langasek <[EMAIL PROTECTED]> was heard to say: > On Sat, Dec 03, 2005 at 08:58:45AM +0100, Mike Hommey wrote: > > Will all the tools resolving the dependencies be fine with a dependency > > on a virtual package without one an a real package ? (like for > > zlib1g-dev | libz-dev) > > Yes. See apt's Provides for an example of this. Just in case there's any confusion: the problem with depending only on a virtual package is that some tools tend to pick an arbitrary Provider of the package, which can in turn lead to unpredictable behavior. If only one provider at a time is installable, this shouldn't be a problem, though. Daniel signature.asc Description: Digital signature
Re: Debian and the desktop
On Mon, Dec 12, 2005 at 08:25:49PM +0100, Simon Richter <[EMAIL PROTECTED]> was
heard to say:
> >-default sound setup
>
> Sound is symptomatic of a much larger class of problems, namely that
> there is no system service that forwards resources other than display
> and keyboard to the user currently logged in... [snip]
> What would be required is some resource
> forwarding framework in which a priviledged process will pass out
> handles to sound/usb/floppy/... [snip]
>
> >-default wireless setup
>
> This is also related to the clash of the two approaches ("multiuser
> system with capable admin" versus "single-user personal system where all
> users need admin priviledge to associate to new APs as they roam with
> their laptop"). What we need is a solution that handles the in-between
> cases as well, and it's not Debian specific either.
Essentially what you are saying is that since we can't provide a 100%
generic solution that works perfectly in every concievable situation by
default, we shouldn't bother making the default install work better in
any situation (even, say, one that accounts for the overwhelming majority
of current and potential users). This is certainly in keeping with Debian
tradition, and it's also the reason I now hand out Ubuntu CDs instead of
Debian ones to new users.
Daniel
signature.asc
Description: Digital signature
Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
The attached text is a first draft of a proposed extension to the Description field to explicitly handle bulleted lists. The extended syntax allows list items to be treated specially by frontends (for instance, bullet characters can be replaced with graphics, and the body of the list item can be word-wrapped); current Descriptions should either parse correctly or be no worse off than they currently are. Current versions of aptitude implement this proposal. Daniel Abstract: This document describes a proposed extension to the Description formatting policy (policy section 5.6.13) to support better formatting of bullet lists in package descriptions. The proposed policy is primarily a formalization of existing best practice regarding bullets; most current package descriptions will parse as expected with no changes, and packages that do not can easily be converted to the new format without degrading presentation in legacy package management tools. The Description extensions described in this document are presently implemented in aptitude (>= 0.4.0). Background and Motivation: Policy 5.6.23 provides for "preformatted" lines in descriptions. These are lines beginning with at least two spaces, and will be displayed verbatim; they are either unwrapped or hard-wrapped. The current best-practice approach to including bullet lists in package descriptions is to write each line of the list as a preformatted line; for instance, = snip here = QEMU is a FAST! processor emulator: currently the package supports arm, powerpc, sparc and x86 emulation. By using dynamic translation it achieves reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: . * User mode emulation: QEMU can launch Linux processes compiled for one CPU on another CPU. * Full system emulation: QEMU emulates a full system, including a processor and various peripherials. It enables easier testing and debugging of system code. It can also be used to provide virtual hosting of several virtual PC on a single server. . As QEMU requires no host kernel patches to run, it is very safe and easy to use. = snip here = This convention has several serious limitations, however. Perhaps most importantly, it does not gracefully accomadate smaller terminals; while other paragraphs are word-wrapped by conforming user interfaces, word-wrapping of these preformatted paragraphs is (rightly) forbidden. This leads to poor readability when the terminal size is decreased; for instance, formatting to 60 columns produces: = snip here = QEMU is a FAST! processor emulator: currently the package supports arm, powerpc, sparc and x86 emulation. By using dynamic translation it achieves reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: * User mode emulation: QEMU can launch Linux processes compi led for one CPU on another CPU. * Full system emulation: QEMU emulates a full system, includ ing a processor and various peripherials. It enables easier test ing and debugging of system code. It can also be used to provide virtual hosting of several virtual PC on a single server. . As QEMU requires no host kernel patches to run, it is very safe and easy to use. = snip here = In contrast, the proposed mechanism allows this description to be formatted in 60 columns as follows: = snip here = QEMU is a FAST! processor emulator: currently the package supports arm, powerpc, sparc and x86 emulation. By using dynamic translation it achieves reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: * User mode emulation: QEMU can launch Linux processes compiled for one CPU on another CPU. * Full system emulation: QEMU emulates a full system, including a processor and various peripherials. It enables easier testing and debugging of system code. It can also be used to provide virtual hosting of several virtual PC on a single server. As QEMU requires no host kernel patches to run, it is very safe and easy to use. = snip here = Extensions to the syntax of Description blocks: As mentioned above, all lines beginning with two or more spaces are treated identically under current Policy. This proposal introduces the concept of a /bulleted block/. A bulleted block consists of a series of lines such that: (1) The first line begins with N > 2 spaces, (2) The first non-space character of the first line is a bullet character, and (3) Each subsequent line begins with at least N + 1 + M spaces, where M is the number of spaces immediately following the first non-space character of the first line. For the purposes of this definition, the bullet characters are [*-+]. The following are examples of bulleted blocks: = snip here = * If Peter Piper picked a peck of pickled pepp
Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
On Mon, Dec 12, 2005 at 06:38:59PM -0500, sean finney <[EMAIL PROTECTED]> was heard to say: > On Mon, Dec 12, 2005 at 03:09:52PM -0800, Daniel Burrows wrote: > > The attached text is a first draft of a proposed extension to the > > Description field to explicitly handle bulleted lists. The extended > > wow! that's quite a document. i'm glad to see that people are > focusing on the Really Big problems facing debian today. > > okay, that was a bit punchy... sorry i couldn't help it :) > > seriously though, i think the proposal is quite well written. the only > critique i have is that i think it's maybe going a little too far out > there to talk about nested lists, as i can't imagine them being at all > practical in what's supposed to be a short, informative description of > a package. That's a fair point, but I felt that there wasn't any reason to artificially restrict the sorts of lists that could be handled when nested lists can be dealt with in such a natural fashion. There are at least a few cases where I can imagine two-level lists being useful, and they seem to exist in the wild (see samhain and xml-core, for instance). One interesting question that I can see is whether to treat a *word-wrapped* line that starts with a bullet character as a bulleted item. Doing so would make several more natural ways of expressing lists work, especially nested lists -- the example in my document is actually wrong! On the other hand, doing this at the top-level would mean that conforming descriptions wouldn't degrade cleanly, while doing it only for sub-lists is inelegant. Daniel signature.asc Description: Digital signature
Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
On Mon, Dec 12, 2005 at 05:49:02PM -0600, Peter Samuelson <[EMAIL PROTECTED]> was heard to say: > > [Daniel Burrows] > > (1) The first line begins with N > 2 spaces, > > Don't you mean N >= 2? > > > (2) The first non-space character of the first line is a bullet > > character, and > > > > (3) Each subsequent line begins with at least N + 1 + M spaces, > > where M is the number of spaces immediately following the first > > non-space character of the first line. > > I think that's overgeneral. I do not see the point in allowing M != 1. > I say keep the spec simple; forcing frontends to include parsing > complexity that doesn't even add anything useful is a Bad Thing. > > (If aptitude wants to handle M != 1 in order to make certain legacy > descriptions look better, fine, but I don't think it should be > explicitly condoned.) Good point. I've adjusted this in my copy (updated version attached). Daniel Abstract: This document describes a proposed extension to the Description formatting policy (policy section 5.6.13) to support better formatting of bullet lists in package descriptions. The proposed policy is primarily a formalization of existing best practice regarding bullets; most current package descriptions will parse as expected with no changes, and packages that do not can easily be converted to the new format without degrading presentation in legacy package management tools. The Description extensions described in this document are presently implemented in aptitude (>= 0.4.0). Background and Motivation: Policy 5.6.23 provides for "preformatted" lines in descriptions. These are lines beginning with at least two spaces, and will be displayed verbatim; they are either unwrapped or hard-wrapped. The current best-practice approach to including bullet lists in package descriptions is to write each line of the list as a preformatted line; for instance, = snip here = QEMU is a FAST! processor emulator: currently the package supports arm, powerpc, sparc and x86 emulation. By using dynamic translation it achieves reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: . * User mode emulation: QEMU can launch Linux processes compiled for one CPU on another CPU. * Full system emulation: QEMU emulates a full system, including a processor and various peripherials. It enables easier testing and debugging of system code. It can also be used to provide virtual hosting of several virtual PC on a single server. . As QEMU requires no host kernel patches to run, it is very safe and easy to use. = snip here = This convention has several serious limitations, however. Perhaps most importantly, it does not gracefully accomadate smaller terminals; while other paragraphs are word-wrapped by conforming user interfaces, word-wrapping of these preformatted paragraphs is (rightly) forbidden. This leads to poor readability when the terminal size is decreased; for instance, formatting to 60 columns produces: = snip here = QEMU is a FAST! processor emulator: currently the package supports arm, powerpc, sparc and x86 emulation. By using dynamic translation it achieves reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: * User mode emulation: QEMU can launch Linux processes compi led for one CPU on another CPU. * Full system emulation: QEMU emulates a full system, includ ing a processor and various peripherials. It enables easier test ing and debugging of system code. It can also be used to provide virtual hosting of several virtual PC on a single server. . As QEMU requires no host kernel patches to run, it is very safe and easy to use. = snip here = In contrast, the proposed mechanism allows this description to be formatted in 60 columns as follows: = snip here = QEMU is a FAST! processor emulator: currently the package supports arm, powerpc, sparc and x86 emulation. By using dynamic translation it achieves reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: * User mode emulation: QEMU can launch Linux processes compiled for one CPU on another CPU. * Full system emulation: QEMU emulates a full system, including a processor and various peripherials. It enables easier testing and debugging of system code. It can also be used to provide virtual hosting of several virtual PC on a single server. As QEMU requires no host kernel patches to run, it is very safe and easy to use. = snip here = Extensions to the syntax of Description blocks: As mentioned above, all lines beginning with two or more spaces are treated identically under current Policy. This proposal introduce
Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
On Tue, Dec 13, 2005 at 12:01:52AM +, Roger Leigh <[EMAIL PROTECTED]> was heard to say: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Daniel Burrows <[EMAIL PROTECTED]> writes: > > > The attached text is a first draft of a proposed extension to the > > Description field to explicitly handle bulleted lists. > > That's quite a complex document for something I believe should be > quite simple. > > When I use Emacs, it can reflow text (M-q) by looking at the > indentation level of the following lines. It can even cope with > bullets, outdents, indents, etc. If a frontend display routine could > handle that, that would solve the problem generically, and would > handle any level of indentation required. The heart of the document describes how to do this in a simple and precise way. The first section explains some reasons that it's useful to recognize bulleted lists, while the last couple sections have implementation notes and analysis of the impact on current frontends and Descriptions. > Specifically regarding bullets: We now have UTF-8 encoded control > files, so why not simply use the UCS bullet character (U+2022)? It might make sense to recognize the Unicode bullet character, but forcing people to use it is not a good idea for several reasons, with backwards-compatibility being a major one. Daniel signature.asc Description: Digital signature
Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
On Tue, Dec 13, 2005 at 01:21:41AM +0100, Jeroen van Wolffelaar <[EMAIL PROTECTED]> was heard to say: > On Mon, Dec 12, 2005 at 03:09:52PM -0800, Daniel Burrows wrote: > > Extensions to the syntax of Description blocks: > > > > As mentioned above, all lines beginning with two or more spaces are > > treated identically under current Policy. This proposal introduces > > the concept of a /bulleted block/. A bulleted block consists of a > > series of lines such that: > > s/lines/series of items/, otherwise, you'd have a a series of lines that > each consist of a number of lines: ambigious (or at least confusing) > wording. Each bulleted block is one bullet item -- the syntax doesn't care about sequences of items, just individual ones (although the frontend is free to treat sequences differently from lone items). This can probably be made clearer. How about this wording? = snip here = As mentioned above, all lines beginning with two or more spaces are treated identically under current Policy. This proposal introduces the concept of a /bulleted block/. A bulleted block represents the contents of a single list item; it consists of a series of lines such that: = snip here = > > (2) The first non-space character of the first line is a bullet > > character, and > > > > (3) Each subsequent line begins with at least N + 1 + M spaces, > > where M is the number of spaces immediately following the first > > non-space character of the first line. > > I'd note that M might be as small as zero. This is implied by the lack > of prohibition in (2), but it can't hurt to be clear. As was noted in another reply, it probably makes sense to require M == 1 in the spec; only a few packages that I've seen use anything else and it looks best in legacy frontends. > > For the purposes of this definition, the bullet characters are [*-+]. > > Better write [*+-], to prevent needless ambiguity with regex syntax, > where [*-+] actually means '*' or '+', excluding '-'. Or just list the > three characters. Good point. I'm afraid that I'm guilty of being a bit lazy here. > In concreto, I'd suggest using the following definition instead, also > covering the nested bulleting that's only defined-by-example below: It actually is defined, but you have to read between the lines. (it's the bit about parsing as if N+M spaces were stripped) Unfortunately, my example was wrong! (see attachment) > For in policy 5.6.12: [snip] As you noted, this is a bit hard to read; I'll probably tackle the problem of writing this up for Policy at some point in the future, once there's some agreement on what the format should be. > > The following are examples of bulleted blocks: > > > > = snip here = > > * If Peter Piper picked a peck of pickled peppers, how many pickled > > peppers did Peter Piper pick? > > > > *Fourscore and > > seven years ago, > > our forefathers brought forth upon this continent > > a new nation. > > . > >-- Abraham Lincoln, 16th President of the United States of America > > According to your and my definition, this would be a bullet item too, > like (in HTML) - Abraham Lincoln (...) America ? Or how do I > misread your definition then, if this is *not* an instance of a bulleted > list? Yes, that's a good point. My example includes something that parses incorrectly :-). Note, however, that in the wild there are exactly two packages that break this way in aptitude out of the whole archive (checked with a regexp search), and that even these would not break if we required a space after the bullet character. > Alternative: > > A totally different way might be to exploit policy's opportunity to > extending the description syntax. Policy 5.6.12 explicitely states that > lines starting with a dot should not be used and are left open for > future expansions. So why not use *that*? Like, definition by example: I don't like this approach as much for a couple reasons -- it's not as natural (the format I proposed looks fine without any interpretation at all), you'd have to edit a lot of packages (most bulleted lists are in the right format already, in my observation), and it might not display properly in legacy frontends (frontends might display them literally, but Policy is silent on how these lines should be handled; aptitude IGNORES everything past the dot!) Daniel signature.asc Description: Digital signature
Re: Aptitude question
On Sat, Jan 07, 2006 at 12:51:55AM +0100, Jiří Paleček <[EMAIL PROTECTED]> was heard to say: > On Wed, 04 Jan 2006 19:50:14 +0100, Linas Zvirblis <[EMAIL PROTECTED]> > wrote: > > >Jiri Palecek wrote: > >>How does aptitude decide which one to choose? Shouldn't it > >>prefer to do something that won't break other packages? Or should > >>it ask the user for help? > > >As for your problem, you must provide way more information than just "it > >does not work" in order to get help. There are at least five different > >versions of aptitude you could be using on whatever version of Debian > >you use. Most of us cannot read minds, especially over the Internet. > > If you had read (at least the written protion of) my mind more carefully, > you would realize that I have never said "it does not work". I thought it > more as a feature request (or idea) than bug report. I was asking about > how is aptitude supposed to solve such situations, beacuse it isn't clear > if it really should try to guess the correct packages to install. The problem is that of the five versions Linas referred to, there are at least two separate ways of resolving such situations, which are likely to behave differently in your case. > Then, try to install "A". This will, in my version of aptitude > (0.2.15.9-7), > breaks package "D". However, the constraints are satisfiable by downgrading > package "B". The version in unstable (0.4.*) can calculate every (interesting) solution to a given dependency problem [0] and will show as many as you ask for. > As you had already noted, it greatly depends on the particular system (you > don't wanna read my /var/lib/dpkg/available and status, do you?). I thought > it more as an illustrative example. Actually, I often end up loading other people's system state files in the course of bug-hunting. Daniel [0] alert readers will note that the caveat "if the user waits for a sufficient amount of time" has to be added here; however, this is typically much less than one second per solution on my hardware. signature.asc Description: Digital signature
Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)
On Fri, Jan 13, 2006 at 02:34:32PM +0900, Charles Plessy <[EMAIL PROTECTED]> was heard to say: > As stated by the Debian Policy Manual : > > "The Depends field should be used if the depended-on package is required > for the depending package to provide a significant amount of > functionality." > > and > > "The Recommends field should list packages that would be found together > with this one in all but unusual installations." Something that may have been lost earlier in this thread is that apt-file *does* Recommend curl. The apt-file maintainer believes that it is useful enough to install apt-file without curl to justify weaking that to a Recommendation. Unless you are going to discuss that point specifically, the proper place to send your complaints is bug #42266. Daniel signature.asc Description: Digital signature
Re: Aptitude question
On Tue, Jan 10, 2006 at 11:41:25AM +0900, Miles Bader <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows <[EMAIL PROTECTED]> writes: > > [0] alert readers will note that the caveat "if the user waits for a > > sufficient amount of time" has to be added here; however, this is typically > > much less than one second per solution on my hardware. > > Er, what _is_ your hardware anyway? Though I love the aptitude interface > and functionality, I've noticed that on my home machine (not so fast, but > not too bad with average software), normal aptitude operation has been > getting more and more slothlike in recent times, to the point where I often > just hit ^C to exit after upgrading, instead of waiting ages for all the > "updating random stuff #11, very slowly... 2%" stuff to finish before I can > type "q" At the moment I'm using a laptop with a Pentium 4 chip. When you say that normal operation is getting slower, do you mean just the load time or its overall performance? The time required to load in all the state files is a bit long, but once they're loaded the program seems to run reasonably quickly to me. The main thing that changed recently that would impact the program's speed under normal use is the switch to using Unicode internally, which means that many string manipulations take 4x as long, and input strings (e.g., from package descriptions) have to be decoded before they're used. Daniel signature.asc Description: Digital signature
Re: Aptitude question
On Mon, Jan 16, 2006 at 10:57:22AM +0900, Miles Bader <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows <[EMAIL PROTECTED]> writes: > > When you say that normal operation is getting slower, do you mean just > > the load time or its overall performance? The time required to load > > in all the state files is a bit long, but once they're loaded the > > program seems to run reasonably quickly to me. > > The really problematic thing is indeed the state-file loading time; it > seems to take 30 - 40 seconds on my machine (with no disk I/O as the > files are already cached by the kernel). It would be interesting to see profile data for this. The new aptitude has a "nop" command that does nothing but load the cache and then stop, the better to get profiling information (but it's too fast on my computer to yield useful results). A lot of what aptitude is doing there is parsing RFC822-alike files using core apt code, and it's possible that the apt end of things could be optimized. There's even a patch in the BTS that eliminates various unnecessary copies (#$319377), although it might be better in some cases to prevent aptitude from calling those routines so many times (e.g., it should really be caching configuration values rather than doing lookups in the middle of a long loop). > Normal operation is generally OK, though some searches (e.g. "~dfoo") > are so slow as to be almost useless -- especially given that it's > "i-search", so a super-slow search gets repeated for every key as you > type the search string! I suspect that the problem with searches is due to locality: aptitude has to access several structures/files to perform a search, and (IIRC) it only attempts to order accesses along one "axis". i.e., it accesses packages in the order that they occur in the main cache, but this isn't necessarily the same order that they occur in, e.g., the Description files. If you look at the apt-cache code, in contrast, you'll see that it does a two-pass search, first iterating through the package cache to match package names, then sorting packages according to their order in the description file to match descriptions. This is easy for apt-cache, since it only has one type of match; aptitude's much more complex matching language and search architecture would require some more effort to optimize this way. I had some notes at one point on modifying aptitude's search to be multi-pass in order to increase locality, but I didn't get around to carrying through on the project. > > The main thing that changed recently that would impact the program's speed > > under normal use is the switch to using Unicode internally, which means that > > many string manipulations take 4x as long, and input strings (e.g., from > > package descriptions) have to be decoded before they're used. > > Do you know if the package/state files so large that it's really running > against fundamental memory bandwidth problems? I've noticed (in my own > programs) that some standard C++ library code, e.g. reading from > io-streams, seems suspiciously slow (though I've not confirmed this with > measurements)... I doubt that the code is hitting any fundamental limits, since you mentioned that the program is slow even when everything is cached. The standard library generally seems reasonably quick to me, although I avoid iostream input like the plague. Daniel signature.asc Description: Digital signature
Re: Obsolete packages in Experimental
On Wed, Jan 25, 2006 at 04:25:52PM +0100, Jérôme Warnier <[EMAIL PROTECTED]> was heard to say: > Le vendredi 20 janvier 2006 à 14:17 +, Paul Brossier a écrit : > > On Fri, Jan 20, 2006 at 04:09:28AM -0600, Peter Samuelson wrote: > > > > > > [Jérôme Warnier] > > > > Or even better: a list of all packages already installed on my system > > > > which have an experimental version? > > > > > > There might be a better way, but assuming you have experimental in your > > > sources.list... > > > > > > > aptitude search ~Aexperimental | grep ^i > Right, and if the second character on the line is a B, that means this > packages is already from experimental. > So you could filter the ones you could still upgrade with: > aptitude search ~Aexperimental | grep ^i|grep -v ^iB Err, the B means that the package is currently in a broken state. That might be strongly correlated with being experimental, but there's no guarantee in either direction ;-). To get a list of currently installed experimental packages, install aptitude >= 0.4.0 and do: aptitude search '~S~i~Aexperimental'. Daniel signature.asc Description: Digital signature
Re: For those who care about stable updates
On Sun, Mar 12, 2006 at 12:20:25PM +0100, Frank Küster <[EMAIL PROTECTED]> was heard to say: > Andreas Barth <[EMAIL PROTECTED]> wrote: > > > Actually, in case stockholm gets elected, > > Sorry, where's the Wiki page describing codenames for DPL candidates? Wait, you mean we aren't putting European cities forward for DPL-ship? ;-) Daniel signature.asc Description: Digital signature
Fwd: Re: Server Hardware
I just saw the attached email message on a LUG mailing list. It's the first time I've heard of this, and it looks a bit worrying, especially since a lot of newer machines are shipping SATA-only these days. What I'm wondering is: (a) Does the default sarge kernel run afoul of the problems alluded to in this email? I suppose the issue would be that you don't get the usual benefits of journalling. (b) If it does, is there a big fat warning somewhere in the installer when the user tries to partition a SATA disk with a journalling filesystem? Daniel -- /----- Daniel Burrows <[EMAIL PROTECTED]> -\ | If we do not change our direction | | we are likely to end up where we are headed.| \-- Listener-supported public radio -- NPR -- http://www.npr.org ---/ --- Begin Message --- On Wed, 23 Mar 2005 21:23:14 -0500, Jeff Wolfe <[EMAIL PROTECTED]> wrote: > James Gingerich wrote: > > Hello All, > > > > I'm getting ready to make a purchasing decision with limited funds and > > would like some advice. > > > > My department is looking to purchase a new tower server, running Linux > > of course. Its main purpose is a web server (Apache front end, Tomcat > > application server), but also uses its own RDBMS, and a little mail and > > file sharing (samba). It backs up regularly, with little changes. > > > > I'm trying to determine what the best comprimise of hardware for my cost > > is. I believe the key items are processor, memory, and hard drive(s). > > I just don't know which is more important for the server to squeeze the > > best performance, i.e.; weighing 2 processors vs. more memory vs. SCSI > > drives? > > > > Here is what I come up with thus far: > > > > 1 Xeon processor @ 3.0 GHz, 2 MB Cache, 800 MHz FSB > > 2 GB memory DDR2 @ 400 MHz > > CERC SATA RAID controller (RAID 0) > > 2 160 GB SATA hard drives > > > > Any suggestions would be greatly appreciated. > > I would encourage you to mirror the drives instead of striping. > > Also, if you're thinking of a distribution other than Redhat. There sometimes > can be issues with drivers and non-redhat distros.. Dell only certifies their > systems with RedHat. > Depending on how much you care about data integrity, things get more complicated. SATA disks use write-back cache in order to provide performance that is competitive with SCSI disks in write-through mode. Unfortunately, the sata protocol state machine assumes write-back is acceptable, and thus does not implement the scsi tcq asynchronous callback model. The net effect is that transactional systems, such as journalling filesystems and databases, will not operate correctly on sata disks, unless those transactional layers have special sata extensions. Recent 2.6 kernels support journalling on sata through their write barriers interface, which is just a cache flush command on the backend. So, if you care about integrity, your options are to turn off disk write caches (which makes performance abysmal due to sata's poorly designed state machine), use a very recent 2.6 kernel, or use a distro that has write barriers back-ported into their custom kernel. Furthermore, you need to be sure that you get the midrange sata disks, and not the desktop-oriented disks, because the MTBFs are very different. -- Tom Keiser [EMAIL PROTECTED] -- To unsubscribe, send mailto:[EMAIL PROTECTED] No subject or message text is required. For human assistance, mailto:[EMAIL PROTECTED] --- End Message --- pgpNrIptMG5AX.pgp Description: PGP signature
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Friday 25 March 2005 02:51 pm, Adam McKenna wrote: > No matter how you feel about the term "editorial changes", it seems to me > that if these changes were really so bad, and the majority of the project > is now against them, they should be easy enough to roll back. > > All we need is another GR. Stop bitching and propose one. http://www.debian.org/vote/2004/vote_004 Of course, the "roll back the changes" was defeated by a 2:1 ratio in that vote by the winning option... Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | The only thing that history teaches us | | is that we do not learn from history.| \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgpRAf6DlwPg7.pgp Description: PGP signature
Re: ITP: mazeofgalious -- The Maze of Galious
On Saturday 26 March 2005 03:04 pm, Henrique de Moraes Holschuh wrote: > As for the other games you mentioned: I don't know about PacMan, that one > might be on the public domain for all I know. Same for bomberman. Pingus > only copies the concept, so it would be in about as much trouble as Manesis > was, except for the fact that Lemmings is *not* from Konami, and nobody > ever heard anything from Psygnosis requesting Pingus to be withdrawn. I > have no idea about Supertux. And for an example in the other direction, see freecraft and bnetd. Daniel -- /------- Daniel Burrows <[EMAIL PROTECTED]> --\ | He had a terrible memory. He remembered everything.| \ The Turtle Moves! -- http://www.lspace.org ---/ pgpWhSk4dBVbk.pgp Description: PGP signature
aptitude 0.2.15.9 & apt 0.6
=== We interrupt your regularly scheduled flamewar to bring you this hemi-important announcement. === I just uploaded aptitude 0.2.15.9 to Incoming. Most of the changes in this version are translation updates, but I also included a backport of the apt-secure enhancements that were previously only available in experimental (including, as a special-freebie-never-before-seen-bonus, trust checking at the command-line). Since unstable's apt doesn't support these features, they are not compiled into the package by default, but they will be enabled if you recompile the source package on a system with a newer libapt-pkg-dev installed. As a convenience, I have uploaded packages for i386, compiled against the current experimental apt, to http://people.debian.org/~dburrows. I'm doing this for two reasons: (a) There is an ongoing effort to get apt 0.6 into sarge. While it seems to be a long shot, I can now say with some confidence that simply recompiling aptitude will be enough to manage that transition. (aptitude could be "just recompiled" in the past, but it didn't support the security features of 0.6, making the whole exercise kinda pointless) (a) Assuming, as seems likely, that apt 0.6 doesn't make it into sarge, I want it to be easy for security-conscious users to get a reasonably stable aptitude that supports apt-secure stuff (I doubt they want to be running experimental branches and so forth). If you find problems with the apt-secure stuff -- there are open questions regarding corner cases in the trust handling, for instance -- please report them via the BTS so they don't get lost when I get eaten by my thesis again. Thanks. === Transmission ends. Go back to making the world a better place by tearing each other to pieces. Or something. === Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | The thing that really depresses me about my cynicism| | is that it's not as cynical as real life. | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgpHETNxApy9y.pgp Description: PGP signature
Re: aptitude 0.2.15.9 & apt 0.6
On Sunday 27 March 2005 04:00 am, Norbert Tretkowski wrote: > * Daniel Burrows wrote: > > I just uploaded aptitude 0.2.15.9 to Incoming. Most of the changes > > in this version are translation updates, but I also included a > > backport of the apt-secure enhancements that were previously only > > available in experimental (including, as a > > special-freebie-never-before-seen-bonus, trust checking at the > > command-line). > > Thanks a lot! > > But it seems you forgot to mention this in the changelog. aptitude has three "changelogs". - The Debian changelog tracks changes to the Debian packaging and closes Debian-related bugs. - The NEWS file is the canonical list of major changes between versions (also what you get when you pick "Changelog" from the Help menu, unless you're using the experimental version in which case the program crashes) - The Changelog file is a list of every little modification to every source file in the package. So, it all makes sense. Somewhere. :) Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "You see, I've already stolen the spork of wisdom| | and the spork of courage.. together with the spork | | of power, they form the mighty...TRI-SPORK!" -- Fluble | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgp68aN1iBRRV.pgp Description: PGP signature
Re: Bug#302138: incorrect Description line wrapping with bullet lists
On Wednesday 30 March 2005 05:19 am, Jeroen van Wolffelaar wrote: > Ideally, all packaging tools would support some kind of very simple > markup language to support enumerations in a sane way, but that's a > long-term project. There's room in the description standard for future extensions: quoting Policy, Those containing a space, a full stop and some more characters. These are for future expansion. Do not use them. We can also extend the description format in backwards-compatible ways. So, while a proper markup language would be nice, that doesn't preclude fixing the bullet problem, albeit in a slightly hacky way, NOW. What about this: == A line beginning with two or more spaces, followed by a bullet character and a space, is considered to be an element of a bulleted list. Every succeeding line that begins with N+1 or more spaces, where N is the number of spaces preceding the bullet, is considered to be part of the same bulleted list, and is processed as if N+1 spaces had been stripped from its left margin, with the exception that if the N+2nd character is not a space, the line is formatted as if a leading space were present. (see below) Bullet characters are (maybe) "-", "+", "*", and "o"; the frontend may render them literally or modify their appearence as it deems appropriate. NOTE: it might be a good idea to exclude "o"; I doubt many packages use "o" as a word by itself at the beginning of a literally-formatted line, but it might be a word in some foreign language, which would cause problems once we have translated descriptions. Unfortunately, this would make the format less backwards-compatible. == This means that the current "best practice" for bulleted lists; eg, Description: something with a bulleted list This is a package. It has some features: * A feature. * Another feature. * A feature I felt like continuing onto the next line for some reason * For backwards compatibility, some variation in indentation is OK. will be displayed as expected in all current frontends, while future frontends will treat each of the last two items as a paragraph and word-wrap it accordingly. Lists-within-lists would work like this: Description: something with two bulleted lists This is a package. It has lots of features: * A feature. * Another feature. * A really complicated feature with subfeatures: + Subfeature 1 + Subfeature 2 + Subfeatures can also continue to the next line. . We can also have paragraph separators. * Another feature. The only non-sensibly-rendering thing in legacy frontends would be the literal full-stop, which could be avoided by discouraging the use of multiple-paragraph list items (and really, descriptions shouldn't be that complicated anyway...IMO). Things to note: - Older frontends will render descriptions in this format without any difficulty. - Newer frontends will either automagically detect bulleted lists in older descriptions (all the proper lists that I found in a very small sample would work exactly as expected) or display them literally (the current situation). The worst case would be where the start of a list is literal and its continuation is word-wrapped, but this would come out no worse than the current situation: * A feature * Some other feature but I want you to word-wrap the continuation. All-in-all, I think that this is a nice low-cost way of getting proper bullet support into the frontends. Comments? Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "You keep on using that word. I do not think | |it means what you think it means." | | -- "The Princess Bride" | \ The Turtle Moves! -- http://www.lspace.org ---/ pgp0DWWR190yA.pgp Description: PGP signature
Re: Bug#302138: incorrect Description line wrapping with bullet lists
On Wednesday 30 March 2005 09:56 am, Daniel Burrows wrote: > A line beginning with two or more spaces, followed by a bullet character > and a space, is considered to be an element of a bulleted list. Every > succeeding line that begins with N+1 or more spaces, where N is the number > of spaces preceding the bullet, is considered to be part of the same > bulleted list, and is processed as if N+1 spaces had been stripped from its > left margin, with the exception that if the N+2nd character is not a space, > the line is formatted as if a leading space were present. (see below) I didn't mention this here, but of course the frontend is expected to pay attention to the quantity of indentation, preserve leading indentation of the bullet, and use this information to figure out sub-list relationships. Daniel -- /------- Daniel Burrows <[EMAIL PROTECTED]> --\ | Hi, I'm a .signature virus! | | Copy me into your .signature to help me spread! | \-- Listener-supported public radio -- NPR -- http://www.npr.org ---/ pgpiTS7knHy0r.pgp Description: PGP signature
Re: Bug#302138: incorrect Description line wrapping with bullet lists
On Wednesday 30 March 2005 11:44 am, Andrew Suffield wrote: > I know of at least two such languages. Don't include 'o'. Ok, will do. Or, um, not do. Daniel -- /----------- Daniel Burrows <[EMAIL PROTECTED]> --\ |Human beings were created by water to transport it uphill. | \- A duck! -- http://www.python.org / pgp2ST4C7IpIO.pgp Description: PGP signature
Re: NEW handling: About rejects, and kernels
On Saturday 02 April 2005 08:31 am, Marco d'Itri wrote: > > It would be a better course of action to solve those problems than to > > deliberately mislabel non-free firmware as free. > > So you would have no objections to distributing firmwares packaged in > non-us [non-free?] on the debian install media? This would be a possible > solution to the problem. Personally, I always just assumed this is what would happen if/when non-free firmwares were ejected from main. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Thank you for reading me, but the real .signature is in another email. | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgp2rhj6uV7d9.pgp Description: PGP signature
Re: NEW handling: About rejects, and kernels
On Sunday 03 April 2005 05:51 am, Wouter Verhelst wrote: > Putting items from the non-free archive in the installer images does > just that. It is debatable whether the intention is the same, but by our > rulebook, this is not allowed. Wait...so you're saying it's OK to put non-free stuff in the installer image if we close our eyes and put our fingers in our ears and pretend that it's free and put it in "main" -- but if we call it "non-free", then it's forbidden? In that case, I think I'll go adjust the odometer in my car so I get better gas milage... Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Exhilaration is that feeling you get just | | after a great idea hits you, and just before| | you realize what is wrong with it. | \ Got APT? -- Debian GNU/Linux http://www.debian.org ---/ pgpWuMOtZii8b.pgp Description: PGP signature
Re: lintian & linda
On Monday 11 April 2005 03:14 am, Ron Johnson wrote: > Then why was aptitude written? Why not send patches against apt-get > and dselect? The correct question is why not send patches against console-apt, which you youngsters might not remember ;-). In fact, I did exactly that -- I sent about two patches to fix problems with it before deciding that the design was fundamentally flawed and there was a better way to do things. (hey, hubris is one virtue of a programmer, right? :) ) Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Will the last person to leave the Universe please | | turn off the lights and close the door? | \- A duck! -- http://www.python.org / pgp2drf7N9U0n.pgp Description: PGP signature
Re: lintian & linda
On Monday 11 April 2005 06:39 am, Steve Kowalik wrote: > 1) Proper English descriptions, rather than tags. > [EMAIL PROTECTED]:~% linda /var/cache/apt/archives/abiword_2.2.7-1_i386.deb > > E: abiword; No manual page for binary AbiWord-2.2. -i. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | He had a terrible memory. He remembered everything.| \-- Listener-supported public radio -- NPR -- http://www.npr.org ---/ pgpV37gxmNS99.pgp Description: PGP signature
Re: What do you win by moving things to non-free?
On Saturday 16 April 2005 09:28 am, Adrian Bunk wrote: > The invariant section issues are things you can discuss inside Debian or > with me or with the FSF. But for nearly everyone else the result if you > explain the GFDL problem will be that he thinks that the differences > between free and non-free software are pretty small. A lot of people can't understand why we would consider software that comes with source code, is freely distributable, and may be modified in any way to be non-free simply because its license states that you may not use it if you are a business/work at a nuclear plant/are a member of a neo-Nazi group. So, should we put software like that into main so that they don't "think the differences between free and non-free software are pretty small"? If not, I'm not sure I see what you're trying to say either. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "Next, consider a circle passing through infinity; that | | is, a straight line.." | \-- (if (not (understand-this)) (go-to http://www.schemers.org)) ---/ pgpb3P83iKPYZ.pgp Description: PGP signature
Re: All GPL'ed programs have to go to non-free
On Wednesday 20 April 2005 12:24 am, Adrian Bunk wrote: > In GR2004-004, Proposal D to revert GR2004-003 did get a 2.3:1 majority > by the developers over the proposal to keep the changes of GR2004-003. > That's a pretty clear statement. Adrian, I believe that you are misrepresenting the outcome of -004. The proposal to postpone the changes till after the release, then reinstate them, defeated option D (rescind -003) by a 2:1 majority. The only options I can see that D defeated by a 2.3:1 majority are option F (do nothing at all) and Further Discussion, which all the voters had been told would result in a further delay of the Sarge release. Daniel -- /------- Daniel Burrows <[EMAIL PROTECTED]> --\ | "The problem with LaTeX is that your answers | | look so good, you think they *must* be right!" | |-- Thomas Banchoff | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgp5DwLX4Rmvq.pgp Description: PGP signature
Re: All GPL'ed programs have to go to non-free
Wow, a civil discussion. I'll see if I can keep it up. On Wednesday 20 April 2005 10:10 am, Adrian Bunk wrote: > Could anyone give a definitive answer to the following questions: > - Did -003 contain real changes [1] or didn't it change anything? That basically depends on who you ask and on the more philosophical question of what a "real change" is. I think I'll skip this. > - How is it possible to happen that only a small amount of the Debian > developers (less than one out of four) participates in a GR vote, > the consequences of this GR do not become widely known until after > the GR, and one month later, corrections to this GR are widely > accepted? Anecdotally, it seems that at least some of the people who voted for -003 felt we were already in violation of the SC, and hence there was no need to rush to change things (since it hadn't been a priority before the GR). Others thought that a substantive change was taking place, but weren't expecting the Release Manager to immediately incorporate the changes as a release goal -- they had simply assumed that a timetable would be laid out that took sarge into consideration. I believe you can find people expressing sentiments along these lines in last spring's list archives. I think there also were a few people who claimed to have been mislead about what the SC changes did, although I've seen many, many more individuals claiming that other (unspecified) people were mislead. > - If -003 changed anything, were there Debian developers who mistakenly > agreed to -003 because of it's obfuscated "Editorial amendments" > title? > > If the intention of GRs was to express the opinion of the Debian > developers, the whole -003 and -004 mess seems to be a way how to not do > it. I don't think that anyone would do things exactly the same way with the benefit of hindsight. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | You are standing west of a white house. There is a mailbox here. | \- A duck! -- http://www.python.org / pgp79L0JLvVKw.pgp Description: PGP signature
Re: Bug#302138: incorrect Description line wrapping with bullet lists
On Wednesday 30 March 2005 09:56 am, Daniel Burrows wrote: > We can also extend the description format in backwards-compatible ways. > So, while a proper markup language would be nice, that doesn't preclude > fixing the bullet problem, albeit in a slightly hacky way, NOW. What about > this: This proposal is now mostly implemented in aptitude's experimental SVN branch, except that I decided to require exactly N+2 spaces of indentation for the contents of each entry in the list. It seems to work pretty well for most packages, although I haven't tested any packages that use sub-lists yet. (are there any?) A few packages that it can't figure out how to parse are displayed slightly worse -- usually a matter of indentation not quite lining up, so instead of * label: labelled lists are unfortunately not properly supported you get something like * label: labelled lists are unfortunately not properly supported In a quick scan of a few dozen packages, I only saw one (libcroco3) whose description was seriously damaged by the new formatting. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | A conclusion is the place | | where you got tired of thinking. | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgp8mQs6MNTZA.pgp Description: PGP signature
Re: apt in experimental (Re: APT 0.6 migration -- second status report)
On Wednesday 04 May 2005 03:05 pm, Matt Zimmerman wrote: > That is, I would upload apt to experimental, along with > python-apt+aptitude+synaptic+libapt-pkg-perl+etc. (versioned as NMUs). > Then, new versions of these packages would be uploaded to unstable, which > would supersede the versions I uploaded and cause them to be removed from > experimental. aptitude forked between unstable and experimental in December. Daniel -- /------- Daniel Burrows <[EMAIL PROTECTED]> --\ | Whoever created the human body left in a fairly basic | | design flaw. It has a tendency to bend at the knees. | | -- Terry Pratchett, _Men at Arms_ | \-- Listener-supported public radio -- NPR -- http://www.npr.org ---/ pgptOVBvcdsWz.pgp Description: PGP signature
Re: debian sarge is 3.2 or 4 ?
On Thursday 05 May 2005 10:38 am, Lars Wirzenius wrote: > Release numbers, like release code names, are up to the release managers > to decide. Since neither is particularly important, there's really not > much point in discussing them at length: if the release managers want > 3.1, then 3.1 is what we get. At least not in the common case. I imagine there would be some consternation if the release team announced we were entering the freeze for Debian 2.9 codename "sarge". ;-) Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "Of course you can't see the guards. They DON'T EXIST!" | | "Oh my god, we're surrounded!" "Run away, run away!" | | -- Fluble| \-- Listener-supported public radio -- NPR -- http://www.npr.org ---/ pgpGQcEt7kdEb.pgp Description: PGP signature
Re: Questions about apt-get upgrade/install semantic
On Friday 06 May 2005 06:04 am, Martin Braure de Calignon wrote: > Yes, ok for that. But when I want to upgrade a package, it is not really > logical to use "install", because the package is already installed, no ? Yes. Daniel -- /------- Daniel Burrows <[EMAIL PROTECTED]> --\ | "But what *does* kill me bloody well leaves me dead!" | | -- Terry Pratchett, _Carpe Jugulum_ | \--- News without the $$ -- National Public Radio -- http://www.npr.org ---/ pgpqTYDlXxvr4.pgp Description: PGP signature
Re: RFC: A new video-related section
On Friday 27 May 2005 04:09 am, Pierre Habouzit wrote: > though, that would mean that 'sound' won't have that many package. so > maybe we should rename sound into multimedia and populate it with video > players too ? It might make sense -- but on the other hand, given that our sections will be basically useless for anyone trying to actually find software even if we do this, does it really make sense to invest a lot of effort in rebalancing them? Daniel -- /------- Daniel Burrows <[EMAIL PROTECTED]> --\ | After the game, the king and| | the pawn go in the same box.| | -- Italian proverb| \- A duck! -- http://www.python.org / pgp4Gw3T0k42F.pgp Description: PGP signature
Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation
On Sunday 05 June 2005 03:37 am, Bill Allombert wrote: > Sound like a potential security nightmare to me. LaTeX is a full > programming language. Well, in principle it would be possible to just parse a subset of LaTeX [0] and get reasonable results. If they're calling LaTeX directly, though, that could definitely spell trouble. Daniel -- /------- Daniel Burrows <[EMAIL PROTECTED]> --\ |"We've got nothing to fear but the stuff that we're| | afraid of!" -- Fluble | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgp0fGy6ioE9f.pgp Description: PGP signature
Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation
On Monday 06 June 2005 01:11 pm, H. S. Teoh wrote:
> > Make a version which generates the image on the sending side?
>
> [...]
>
> That would be a *very* nice plugin. The bad thing about the current
> plugin isn't only the security concern: it requires that the recipient
> have the plugin installed. If the image is generated on the sending
> side, it solves the security problem, and also makes it possible to
> send (La)TeX fragments to arbitrary recipients with no additional
> hassle. I think this is worth considering.
But then you can only use the plugin if you can send images, which is almost
never the case for me (image-sending never seems to work even if I'm using
AIM, maybe because I'm behind a firewall).
One possible middle-ground (after all, parsing and generating nice-looking
forumale without TeX is annoying) would be to validate expressions before
handing them to LaTeX. Define a very strict grammar which excludes most
function calls and enforce it; poorly formed expressions would just be
displayed literally.
I'm thinking of something like
EXPR ::= EXPR EXPR | "{" EXPR "}" | "\frac{"EXPR"}{" EXPR "}"
| EXPR "_" EXPR | EXPR "^" EXPR | "+" | "-"
| | \sum | \prod | ...
i.e., just allow the most common expression-forming stuff plus the various
mathematical symbols (which are all safe). Teach your favorite parser
generator about this, validate all incoming text, and you should be fairly
safe. It's not as complete as the unrestricted form, but IMO it covers most
of what you'd want to use in IMs.
Daniel
--
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
| It is hard to think of anything |
| less sentient than a pumpkin.|
|-- Terry Pratchett, _Witches Abroad_ |
\- Does your computer have Super Cow Powers? --- http://www.debian.org -/
pgparbyIs4Ng4.pgp
Description: PGP signature
Re: If *-module depends on *-utils, should *-source recommend it?
On Wednesday 12 January 2005 11:52 am, Scott James Remnant wrote: > It's breaking elegance to fix something I'm not convinced is a problem. Just to be clear: you mean the elegance of the dpkg code, not its external behavior, right? Because I don't see anything elegant about erroring out and leaving an operation half-completed. Daniel -- /----------- Daniel Burrows <[EMAIL PROTECTED]> --\ | Apostrophes are not a warning that a| | word is about to end in an "s". | \ The Turtle Moves! -- http://www.lspace.org ---/ pgposwdkkzCWS.pgp Description: PGP signature
Re: If *-module depends on *-utils, should *-source recommend it?
On Wednesday 12 January 2005 12:37 pm, Scott James Remnant wrote: > On Wed, 2005-01-12 at 12:26 -0800, Daniel Burrows wrote: > > On Wednesday 12 January 2005 11:52 am, Scott James Remnant wrote: > > > It's breaking elegance to fix something I'm not convinced is a problem. > > > > Just to be clear: you mean the elegance of the dpkg code, not its > > external behavior, right? Because I don't see anything elegant about > > erroring out and leaving an operation half-completed. > > Why not? It means that you just need to go fetch and install the > dependency, you don't need to try and install the depending package > again. Well, you're also leaving the package in a broken and unconfigured state. Doing this in order to save the user a little typing later (adding the original package to the second --install line) seems to me like a hack to make some use cases slightly more convenient, not elegance. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "For a successful technology, reality must take precedence over | | public relations, for nature cannot be fooled." | |-- Richard Feynmann| \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgp5GnMO1s1W2.pgp Description: PGP signature
Re: copyright vs. license
On Thursday 13 January 2005 11:18 am, Thomas Bushnell BSG wrote: > Ben Pfaff <[EMAIL PROTECTED]> writes: > > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > > > [updating copyright years] > > > > > I have a handy-dandy emacs lisp frob that will do this automagically > > > for you if you like. > > > > I would like this. Slight modification that works more conveniently for me (this is the only significant chunk of elisp I've tried to write, so may be buggy; it worked in tests, though): === cut here === (defconst current-year (substring (current-time-string) -4) "String representing the current year.") (defconst last-year (int-to-string (- (string-to-int current-year) 1)) "String representing the current year (presuming that the current year is not 1 AD, which hopefully will continue to be the case indefinitely).") (defvar current-gpl-version "2" "String representing the current version of the GPL.") (defvar copyright-regex "[Cc]opyright\\s *\\(([Cc])\\)?\\(\\s *[0-9]+\\s *\\(-\\s *[0-9]+\\s *\\)?,\\s *\\)*\\s *\\(\\([0-9]+\\)\\s *-\\)?\\s *\\([0-9]+\\)" "Regular expression to match common copyright declarations, extracting the final year(s).") ;; Note: paren expr. #5 is the first year of the last dashed pair, if ;; any; paren expr. #6 is the last year. (defun update-copyright-with-queries () "My version of update-copyright." (save-excursion (save-restriction (widen) (goto-char (point-min)) (and (re-search-forward "[i]s free software" nil t) (not (eq major-mode 'rmail-mode)) (let ((limit (point))) (goto-char (point-min)) (re-search-forward copyright-regex limit t)) (let ((final-year (match-string 6)) (final-range-start (match-string 5))) (when (and (not (string= final-year current-year)) (progn (goto-char (point-min)) (sit-for 0) (y-or-n-p (format "Update copyright (last %s)? " final-year (if (string= final-year last-year) (if final-range-start (progn (goto-char (match-end 6)) (delete-region (match-beginning 6) (match-end 6)) (insert current-year)) (progn (goto-char (match-end 6)) (insert "-") (insert current-year))) (progn (goto-char (match-end 6)) (insert ", ") (insert current-year))) t)) (message "Copyright updated to include %s." current-year) (if (re-search-forward "; either version \\(.+\\), or (at your option)" nil t) (progn (goto-char (match-beginning 1)) (delete-region (point) (match-end 1)) (insert current-gpl-version))) (setq write-file-hooks (cons 'update-copyright-with-queries write-file-hooks)) == cut here Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Whom the gods would destroy, they first teach BASIC.| \--- News without the $$ -- National Public Radio -- http://www.npr.org ---/ pgpzYAZtDHGeP.pgp Description: PGP signature
Re: BTS "feature" comments
On Thu, Sep 23, 1999 at 08:35:06AM -0700, Darren Benham was heard to say: > What do you think? > - Forwarded message from Samuel Tardieu <[EMAIL PROTECTED]> - > > > On 21/09, Darren Benham wrote: > > | And do what... there are going to be keys that aren't in the debian > keyring.. > > Non-developpers should not be allowed to *manipulate* bugs IMO. > > > > - End forwarded message - As a non-developer who has manipulated bugs.. I think that non-developers should be allowed to manipulate bugs that they are the submittors of. Several times now I've submitted bugs that either became outdated by a new release or turned out to be my own fault (eg, I reported a bug against lftp that was caused because a local install in /usr/local/bin which I had forgotten about was overriding my packaged installation in /usr/bin) but nevertheless was not closed -- in such cases, I generally send a message to (bug-num)@bugs.debian.org saying that the bug is not a bug anymore and should be closed. However, in a few cases I never got a response from the maintainer and decided to just close a bug myself. I think that I may once have reopened a bug that I reported when it was prematurely closed (that is, the maintainer closed it but I could still reproduce the problem in the supposedly fixed version), in preference to submitting a new bug report. I'm not sure about that, though. I may have just considered it. Are these shooting offenses? If so, I guess I should start keeping an eye out for the Debian Hit Squad.. :-/ Daniel -- Man is timid; he no longer says 'I think' or 'I am' but quotes some prophet or sage. -- Ralph Waldo Emerson, "Self-Reliance"
Re: problems with the perl5 packages
On Thu, Sep 23, 1999 at 05:24:32PM +, Dale Scheetz was heard to say: > Well, in recovering my system, it became necessary to install dpkg-dev, > who's current version requires perl5. I chose to upgrade to perl-5.005, > but while installing perl-5.005-base I was forced to use > --auto-deconfigure on several packages that depended upon perl. When the > smoke cleared, after installing the complete perl-5.005 package, I could > not re-configure either libnet-perl, or mirror, both of which depend upon > perl. Maybe you're using old versions of those packages? bluegreen:~> dlocate -s libnet-perl Package: libnet-perl Status: install ok installed Priority: standard Section: base Installed-Size: 231 Maintainer: Michael Alan Dorman <[EMAIL PROTECTED]> Version: 1.0606-3 Replaces: libnet Provides: libnet Depends: perl5, perl-5.005 | data-dumper
Re: strange behavior of dh_dhelp
Sorry to interrupt the flamew^H^H^H^H^H^H^Hdiscussion here, but I have a quick question. On Wed, Sep 29, 1999 at 12:01:22PM +, Roland Rosenfeld was heard to say: > > One again: they are *not* accessible via these symlinks! > > They are. Well, maybe. (see below) > > This may work sometimes but not always -> hack. > > ctte decided, that this has always to work. If it doesn't, this is a > bug in the package. I assume that I can't start filing bugs against the ~116 packages on my system (eg, libc6) that moved to /usr/share/doc without leaving a symlink behind until this becomes part of policy. Any idea how long that'll be? I've attached an estimated list of missing symlinks, generated by the following command: for i in /usr/share/doc/*; do if [ -d $i ] && ! [ -L /usr/doc/`basename $i` ]; then echo /usr/doc/`basename $i`; fi; done (some stuff, like /usr/doc/HTML, is probably not a bug, and some of the packages are listed for 'other' reasons -- eg, another package provides the /usr/doc directory, or (in the case of python) the directory is left as cruft after an upgrade to FHS..but this is just a first approximation. While I'd like to use a shell script to automatically submit a bug for each package, I think this needs to be checked on a case-by-case basis..) Daniel -- Afternoon, n.: That part of the day we spend worrying about how we wasted the morning. /usr/doc/FAQ /usr/doc/HOWTO /usr/doc/HTML /usr/doc/aalib-bin /usr/doc/abiword /usr/doc/acct /usr/doc/apache-common /usr/doc/base-files /usr/doc/bash /usr/doc/binutils /usr/doc/bison /usr/doc/blackbox /usr/doc/cdparanoia /usr/doc/cdtool /usr/doc/clanbomber /usr/doc/console-tools-libs /usr/doc/crossfire-doc /usr/doc/debmake /usr/doc/dhelp /usr/doc/doc /usr/doc/doc++ /usr/doc/doc++-doc /usr/doc/doc-linux-html /usr/doc/dpkg-awk /usr/doc/e2fsprogs /usr/doc/ethereal /usr/doc/flip /usr/doc/fsviewer /usr/doc/gconv-modules /usr/doc/gdk-imlib-dev /usr/doc/gdk-imlib1 /usr/doc/giram-gnome /usr/doc/glibc-doc /usr/doc/gnome-print /usr/doc/gnu-standards /usr/doc/gpg-idea /usr/doc/gpgp /usr/doc/grip /usr/doc/gxset /usr/doc/gzip /usr/doc/hello /usr/doc/icewm-gnome /usr/doc/imlib-base /usr/doc/imlib-dev /usr/doc/imlib-progs /usr/doc/imlib1 /usr/doc/indent /usr/doc/info2www /usr/doc/irssi /usr/doc/jed /usr/doc/jed-common /usr/doc/koth /usr/doc/lesstif-bin /usr/doc/lesstifg-dev /usr/doc/libaspell3 /usr/doc/libc6 /usr/doc/libc6-dev /usr/doc/libcdparanoia0 /usr/doc/libcomerr2 /usr/doc/libgc4 /usr/doc/libgc5 /usr/doc/libgc5-dev /usr/doc/libglib1.2-dev /usr/doc/libgtk1.2-doc /usr/doc/libpam-doc /usr/doc/libpanel-applet0 /usr/doc/libpm3 /usr/doc/libreadlineg2 /usr/doc/libreadlineg2-dev /usr/doc/libss2 /usr/doc/libwine /usr/doc/libwine-dev /usr/doc/libwraster1 /usr/doc/libwww-perl /usr/doc/linpopup /usr/doc/locales /usr/doc/man-db /usr/doc/mtools /usr/doc/navigator-base-461 /usr/doc/navigator-smotif-461 /usr/doc/ncurses-base /usr/doc/ncurses-term /usr/doc/netpbm /usr/doc/netpbm1 /usr/doc/netscape-base-461 /usr/doc/netscape-java-461 /usr/doc/penguineyes-gnome /usr/doc/php3-gd /usr/doc/powertweak /usr/doc/procmail /usr/doc/python /usr/doc/setserial /usr/doc/shellutils /usr/doc/tar /usr/doc/texinfo /usr/doc/vim /usr/doc/wdm /usr/doc/wine /usr/doc/wine-doc /usr/doc/wmaker /usr/doc/wmaker-gnome /usr/doc/wmspaceweather /usr/doc/xfonts-100dpi /usr/doc/xfonts-75dpi /usr/doc/xfonts-base /usr/doc/xfonts-cjk /usr/doc/xfonts-scalable /usr/doc/xjed /usr/doc/xmorph /usr/doc/xscreensaver /usr/doc/xscreensaver-gl /usr/doc/xteddy /usr/doc/zed /usr/doc/zlib-bin /usr/doc/zlib1g /usr/doc/zlib1g-dev
Re: A simple question about unstable
On Wed, Sep 29, 1999 at 04:11:08PM -0400, Bill White was heard to say: > Is it possible to upgrade from slink to potato using a 56k modem connection? > If it takes 650Mb to upgrade everything it is not possible. If it is, > my problems are solved, of course. > > Thanks. If you pay for bandwidth/time it might not be. I believe that several computers I upgraded recently downloaded about 100MB of packages. (actually, I downloaded it to one and then copied them around on a local network) That was on a 28k connection, but we weren't being charged per minute or per megabyte so I just let it run overnight. That might not work for you. Daniel -- "...vicious Actions are not hurtful because they are forbidden, but forbidden because they are Hurtful, the Nature of Man alone consider'd" -- from the autobiography of Benjamin Franklin
Re: Is XEmacs nonfree?
On Thu, Sep 30, 1999 at 12:54:32AM +, David Coe was heard to say: [quoting RMS] > But in another sense it is not GNU software, because we can't use > XEmacs in the GNU system: using it would mean paying a price in > terms of our ability to enforce the GPL. Some of the people who have > worked on XEmacs have not provided, and have not asked other > contributors to provide, the legal papers to help us enforce the > GPL. I have managed to get legal papers for some parts myself, but > most of the XEmacs developers have not helped me get them. > > ... > > But this is worse than competition--it is unfair competition. The > XEmacs developers can and do copy code they like from Emacs. If I > could copy the code I like from XEmacs in the same way, at least the > rivalry would be fair. But I can't do that't, because substantial > parts of XEmacs don't have legal papers, or don't have known > authors. > > ... > > Is that still an accurate description of the legal status (from > FSF's perspective) of XEmacs, and if so, shouldn't we move it to > non-free? It looks to me like he's not concerned with the free-ness of the XEmacs code, but rather with the fact that it hasn't had its copyright assigned to the FSF. He doesn't want to include non-FSF-copyrighted code in the main Emacs branch, as I understand. I guess that would keep the FSF from defending the copyright it in court. (?) Anyway, he seems to think so. :-/ Daniel -- "I've struggled with reality for thirty-five years, but I'm glad to say that I finally won." -- _Harvey_
Re: Packages should not Conflict on the basis of duplicate functionality
On Thu, Sep 30, 1999 at 02:16:31PM +1000, Craig Sanders was heard to say: > > And if the package has a dependency? > > There are many situations dealing with the package system that can > > lead to daemons installing without your knowledge. mtools for potato > > includes floppyd, if someone upgrades a slink machine to potato, > > should floppyd be automatically started? > > if mtools needs floppyd to run and the user has chosen to install mtools > then yes. the user want mtools to work, they don't want mtools to work > ONLY if they do some weird and obscure thing (even if it IS documented > in the debian changelog, it is still weird and obscure unless they > happen to be aware of the fact that this major change has occurred) > which they never needed to do in the past... > > in other words, mtools used to just work, it should continue to just > work after an upgrade. I think it really looks like this question will not be solved until debconf is integrated into the distribution. floppyd is *not* required for mtools to work, it's just an optional and obscure 'feature' (not to mention either an evil or a clever hack :P) that most people aren't going to need (I wasn't even aware it existed until someone brought it up here) It also sounds like a potentially gaping security hole to me. In this case I think the only sane solution is to shut it off by default. I believe there are other packages that have similar situations (none spring to mind though) On the other hand, many things (like exim, ftp daemons, and inetd) should start running as soon as they're installed in most setups. (OTOH, a less promiscuous default inetd setup -- say, no ftp or telnet -- might be good) I don't really see any way to cleanly balance the needs of the four groups (two groups of packages, and two groups of users) without debconf. With debconf, it's laughably easy. Apologies if I have the idea of the system wrong :), but I think we just need to make a single template for all daemon entries, then specify the daemon name and the default setting (on or off) in each daemon. To keep people who aren't interested in this from having to see it, two things could be done. First, all the daemon-starting questions should have a higher priority than normal questions (I don't remember all the priorities now, but say maybe 2 above the 'total newbie' level). Second, an additional option could be collected by the base packages (at the same priority level) asking whether further daemon questions should be shown. (this might be a little trickier) Daniel -- Going on about Dungeons and Dragons being tools of the devil is like guarding the door while *it* is coming up through the floorboards... The Demon Lord of Hla'Siloth may want to cut your soul up into a thousand pieces, but at least he won't try to convince you that you haven't got one. -- [ approximately ] Terry Pratchett, _Johnny and the Dead_
Re: corel linux demo
On Thu, Sep 30, 1999 at 05:29:29AM -0700, Kenneth Scharf was heard to say: > They said that the beta of their linux distro will be > available for public download by the end of October. Hm. Do you have any information about the following issues: -> How big is it? The only spare partition I could try this out on is an old swap partition (currently used for Hurd, but I don't have time to fiddle with that at the moment..). If corel is going to shovel tons of stuff (eg, X and KDE) onto my disk, I doubt I can even try it. -> How 'nice' is it? If it's a <6 minute install, I doubt it really gives you options about what to do. I don't need it clobbering my Windows installation -- or, worse, my current Linux installation! More annoying would be if it decided that it was going to install LILO for me (I use GRUB to boot) I'd like to at least take a look at this and see what they fixed (I seem to remember hearing that they eliminated the horrible flat organization we use for packages and put in some sort of logical hierarchy) but I can't conjure up disk space or risk my current installations.. > Oh BTW they were also giving away copies of > Wordperfect for linux, personal edition (CD only). > Wordperfect is the only app they have ported as a > Native linux binary, and after version 8, they > probably won't be doing a linux native binary version. > So WP version 9 will be a win32 binary under Wine. Are you sure? Wine is not only a binary-compatibility system; it also aims for source-compatibility. They might just be using the Windows version as the canonical source. Daniel -- You have the right to remain silent. Anything you say will be misquoted, then used against you.
Re: First beta version of the Debian SGML/XML HOWTO
On Fri, Oct 01, 1999 at 08:54:14PM +0200, Wichert Akkerman was heard to say: > Previously Stephane Bortzmeyer wrote: > > ishtar:~> dpkg --search /usr/bin/nsgmls > > sp: /usr/bin/nsgmls ^^ > That only means you have it installed. Now try this: > > [lightning:~]-10> dpkg --print-avail nsgmls > Package `nsgmls' is not available. bluegreen:~> dpkg --print-avail sp Package: sp Priority: optional Section: text Installed-Size: 410 Maintainer: Adam Di Carlo <[EMAIL PROTECTED]> Architecture: i386 Source: jade (1.2.1-11) Version: 1.3.3-1.2.1-11 Depends: libc6 (>= 2.1), libstdc++2.10, libsp1 (>= 1.3.2-1.2-1), sgml-base Suggests: doc-base, sgml-data Filename: dists/unstable/main/binary-i386/text/sp_1.3.3-1.2.1-11.deb Size: 145676 MD5sum: 80d3b29d45a42c97ba9e833400535c22 Description: James Clark's SGML parsing tools This package is a collection of SGML/XML tools called SP. . These tools are used to parse, validate, and normalize SGML and XML files. The central programs included in this package are 'nsgmls', which replaces sgmls, 'spam', 'spent', 'sgmlnorm', and 'sgml2xml'. . Author: James Clark <[EMAIL PROTECTED]> Homepage: http://www.jclark.com/sp/ Daniel -- Knowledge, n: Things you believe.
Suggestion: binfmt_misc handling
Hello,
I was just poking around on my system and found a script I wrote back when
kernel 2.2 was released. It was an experiment to see if I could easily handle
registration and deregistration of binary formats (with binfmt_misc) -- it
just occured to me that Debian might be interested in it, so here it is.
Basically what you can do is create a directory called /etc/binfmt_misc and
put a bunch of files in it; each file should be a series of lines where each
line is a directive for the binfmt_misc registration file in /proc. So the
incantation for Java is:
:Java:M::\xca\xfe\xba\xbe::/usr/bin/javawrapper:
(assuming that /usr/bin/javawrapper does something sensible), and for JPEG
(yes, this is a really dumb usage of binfmt_misc, but it's the only other
magic number I could come up with offhand):
:JPEG:M::0xffd8::/usr/X11R6/bin/display:
:JPEG-JFIF:M::JFIF::/usr/X11R6/bin/display:
:JPEG-HSI:M::hsi1::/usr/X11R6/bin/display:
Comments are also supported (by beginning a line with '#')
Packages such as Wine, Kaffe, dosemu, and perhaps Frotz would drop a file
into this directory announcing their support of a binary format. The files
wouldn't actually be interpreted unless this init.d script is installed; I
assume that someone is going to claim this is a security hazard, so I thought
I'd point that out :P
[ as I understand it, a security 'breach' could only occur with this system if a
user had execute permissions but *not* read permissions on a file that wasn't
of a normal executable format; in other words:
rwx--x--x /usr/bin/haha-you-cant-run-me.exe
or if the user normally didn't have permissions to run the interpreter but had
enough permissions to execute files of that type. Both of these seem to me to
be unusual cases, but who knows? :) ]
The config file format could probably be made more sensible, but on the other
hand not many packages really need this and this format isn't *too* obscure..
The init file is attached; it would be cool if a Real Developer[tm] could
stick it in a package. I think this is a fairly useful bit of infrastructure.
Daniel
--
"Cogito, ergo sum."
-- Descartes
#!/bin/sh
# Register various binary types
test -e /proc/sys/fs/binfmt_misc || exit 0
register_format() {
while read -r FORMAT
do
echo "$FORMAT" > /proc/sys/fs/binfmt_misc/register
done
}
case "$1" in
start) echo -n "Registering binary formats: "
for i in `find /etc/binfmt_misc/ -mindepth 1 -maxdepth 1 -not -name \*~`
do
echo -n `basename $i`
sed '/#.*/d' $i | register_format
echo -n ". "
done
echo ""
;;
stop) echo -n "Disabling binary format recognition: "
echo -1 > /proc/sys/fs/binfmt_misc/status
echo "."
;;
restart) $0 stop
$0 start
;;
*) echo "Usage: /etc/init.d/binfmt_misc start|stop|restart"; exit 1
;;
esac
exit 0
Re: bash package removing /bin/sh on upgrade
On Sun, Oct 03, 1999 at 09:44:25AM -0400, Raul Miller was heard to say: > A wonderfuly horrible hack has occurred to me, by the way: A cron job > which runs every minute: /bin/sh -c exit || /sbin/rebuild-bin-sh Hmm. There's a bit of a problem here: aren't cronjobs executed with /bin/sh? :) (although a general way to regenerate a broken shell is nice..) Daniel -- "I've struggled with reality for thirty-five years, but I'm glad to say that I finally won." -- _Harvey_
Re: Suggestion: binfmt_misc handling
Oops. On Sun, Oct 03, 1999 at 10:06:02AM -0400, Daniel Burrows was heard to say: > test -e /proc/sys/fs/binfmt_misc || exit 0 That maybe should be test -d ... (although the above works even on ash) Daniel -- Genius may have its limitations, but stupidity is not thus handicapped. -- Elbart Hubbard
Re: Suggestion: binfmt_misc handling
On Sun, Oct 03, 1999 at 11:30:04AM -0400, Raul Miller was heard to say: > On Sun, Oct 03, 1999 at 10:06:02AM -0400, Daniel Burrows wrote: > > [ as I understand it, a security 'breach' could only occur with this > > system if a user had execute permissions but *not* read permissions > > on a file that wasn't of a normal executable format; in other words: > > rwx--x--x /usr/bin/haha-you-cant-run-me.exe or if the user normally > > didn't have permissions to run the interpreter but had enough > > permissions to execute files of that type. Both of these seem to me to > > be unusual cases, but who knows? :) ] > > Or if the interpreter was setuid or setgid. Unless I'm entirely confused, this is only an issue if the user can't run the interpreter without going through binfmt_misc (ie, they have no execute priviliges on it) -- otherwise they could just type '/usr/bin/setuid_interpreter evil-nasty-program' Daniel -- Whoever fights monsters should see to it that in the process he does not become a monster. And when you look into an abyss, the abyss also looks into you. -- Friedrich Nietzsche
Re: doom source GPL'd
On Sun, Oct 03, 1999 at 12:41:51PM -0700, Joey Hess was heard to say: > It looks like the doom source is now under the GPL. > (http://www.doomworld.com/). This clears up the previous licencing problems > that were keeping it out of debian. It will still be fit only for contrib > for now, since it needs non-free WAD files. > > Who's going to mackage it? Cool. Does this mean Heretic can go in as well? I've actually got a Debianization diff against one of the beta versions of the Linux port that I never did anything much with because of the licensing; if someone's interested in packaging it, I can send them it (and even the orig.tar.gz I used). I also have a package of the shareware WAD files..I don't remember if I can distribute it offhand, though. It's certainly not free. :) Daniel -- I haven't lost my mind, I know exactly where I left it.
Re: Suggestion: binfmt_misc handling
On Mon, Oct 04, 1999 at 09:37:02AM +1000, Brian May was heard to say:
> > Packages such as Wine, Kaffe, dosemu, and perhaps Frotz would drop a file
> >into this directory announcing their support of a binary format. The files
> >wouldn't actually be interpreted unless this init.d script is installed; I
> >assume that someone is going to claim this is a security hazard, so I thought
> >I'd point that out :P
>
> I have two comments:
>
> 1. Where would you install the files into this directory?
>
> Ideally, IMHO, it would be possible to directly embed the config file
> into the deb file, with the full pathname under /etc/bin_fmt.
>
> However, in this case, what would happen with duplicates? eg what will
> happen when many packages that provide Java, all provide their own
> (possibly different) entry under /etc/bin_fmt?
A problem. Clearly I haven't thought deeply about this..I just turned up
the script on my system, said "wow, that was a good idea!" and sent it here for
comments. I like your comments, though:
> 2. Suggestion: Would it be possible to somehow integrate this with
> /etc/mailcap, which already has good support in packages? There are
> different ways you could do this, eg have in the config file lines that
> look like:
>
> :Java:M::\xca\xfe\xba\xbe::application/x-java:
> :JPEG:M::0xffd8::image/jpeg:
> :JPEG-JFIF:M::JFIF::image/jpeg:
> :JPEG-HSI:M::hsi1::image/jpeg:
>
> Where the last field is replaced with the appropriate command line from
> the /etc/mailcap file. Not that there currently is a mailcap entry (at
> least on my slink system) for java...
>
> This file could potentially be used for more applications then just the
> kernel - any program that wants to map the file to a MIME type. (Apache
> already does this - is this any better? I suspect Apache's is hardcoded,
> but not sure).
>
> I think that this could be done with similar structure as originally
> proposed.
This is much better than what I had. I've had another suggestion to use
mailcap as well, and I think this is a good idea -- but I'm not quite sure how
to make it work in Linux (Marcus suggested something like this in the Hurd). I
think, though, that what's put in the binfmt_misc database should be
restricted:only things that vaguely resemble a program should go into it. One
possibility
is a meta-config file:
type "Java programs"
{
name "Java"
recognize-by "magic"
magic-number 0xCAFEBABE
mime-type application/x-java
executable true
load
}
or, more interestingly:
application/x-java; kaffe %s; magic-number="0xCAFEBABE"; \
executable=true; priority=5
(this is the format used by update-mime)
Assume that update-mime was changed to handle this. For every MIME type for
which a MIME handler declared "executable=true", update-mime would dump an
entry to /etc/binfmt_misc with instructions to use the handler which was the
highest priority of those which declared themselves to be willing to execute
files of that type.
update-mime could also check the architecture it's running on and do something
different on the Hurd, once it's decided exactly how that system will handle
stuff like this.
Does this sound reasonable?
Daniel
--
Genius may have its limitations, but stupidity is not thus handicapped.
-- Elbart Hubbard
Re: linking binfmt_misc with mime-types
On Mon, Oct 04, 1999 at 12:26:18PM +0100, Edward Betts was heard to say: > Could I clarify some stuff please? > > Are we proposing that all mime-types have binfmt_misc setup? Does that mean, > the kernel will be able to `run' any file in mailcap? Is that what we really > want? I'm not; I just happened to use the JPEG example in my first mail because I had the magic numbers lying around. On the other hand, you could certainly use them for this. Personally, I don't like the idea: you'll never be able to keep track of every possible file type, and unless you do it'll be way too inconsistent -- eg, file A.jpg works, but A.tiff doesn't (kinda like Windows' associations). Executable stuff should be stuff that's executable.. (although I can see the reasons why being able to do this would be nice) > Another question is are their mime-types for all the programs we might want to > run in this way? The programs I can think of off-hand, are Java, DOS EXE, and > Windows EXE, are there any others? If we go with the ability to run documents > like images and so on, do we have all the mime-types? Are we going to have to > invent new mime-types? Is that a bad thing to do? The other things I was thinking of that we might want to enter were Zcode (Zork and so on) and possibly files for some of the various video game emulators (nestra, snes9x). I think there are mime-types for some of these (isn't Java application/x-java-program? I think DOS EXE may be application/x-msdos-executable or something..). Probably zcode and video game RAMs don't have mime-types (do they even have magic numbers? Hm.) > Some more questions. Is it possible to recognise an html file by a couple of > magic numbers at the beginning? Most html starts or , but it is > not certian that it will look like this. Another thought is the possiblilty of > running perl scripts without the bang path, but then how would the shell tell > it is a perl script. 'file' does a pretty good job of that, but it's probably tough to get it right. However, it's worth noting that binfmt_misc can also recognize files based on extension (can you say 'horrible hack'? :) ) > If we put loads of entries into binfmt_misc are we likely to fill some kernel > data table? What happens if it overloads? Do we significantly affect the > performance of the system? If the kernel is checking each file against a list > of magic numbers will it take a long time to run a file? (Probably not the > kernel is fast, and most files we will run will be ELF, which is probably > checked first.) I don't know. I'd imagine it's been tested up to at least 20 or 30 entries.. at any rate, I would've done that if I had written it :) > This is not user independant is it? The system can not be set so that one user > has support for running Java/JPEGs from the command line, and another does > not? Nope. It could be on the Hurd, I think. I'm still trying to get up to speed on the structure there, though.. Daniel -- Exhilaration is that feeling you get just after a great idea hits you, and just before you realize what is wrong with it.
Re: Unstable release
On Mon, Oct 04, 1999 at 08:44:48PM +0200, Staffan Hämälä was heard to say: > Hi, > > I'm just curious about how other people succeed in installing the > potato release. *raises hand* I've actually done two things -- the machine I'm typing on has been running unstable since before Slink was frozen, so it's been continuously upgraded for a while. However, I've also upgraded existing Slink systems and installed new systems (sort of, see below) > Myself, I have always had _lots_ of trouble when > trying that. First, I installed it at home, and dselect freaked > out and started complaining over files that didn't exist. This > was due to the fact that ftp downloads the softlinks that point > to slink packages instead of the actual files. That time I had > downloaded the whole lot with ncftp. I downloaded another time > using wget with the option to get real files. That worked better, > and dselect found all files. Still, the big problem was dselect > because it complained about so many things it flipped out and > refused to install any more packages (I barely got a working > system). I usually use apt to fetch via ftp, but pointing it at a source archive should do the same thing. Are you using it as a dselect backend, or are you doing something else entirely? > Last week I tried the same thing at work, installing over ftp, > and I thik the installer also downloaded just the links, but > not the actual files, so this time I wasn't even able to boot > the system after running dselect. After this I installed slink > instead, and it worked like a charm. ^^^ Wait, you mean you're trying to actually *install* potato? I didn't realize that boot-floppies even worked again! I think it's usually the case that a from-scratch install doesn't work until the last minute. I know a Slink installs I tried last January was totally screwed up (dbootstrap (?) didn't properly create fstab and I had to put it together by hand -- and that was the simplest problem. I got a working system though! :) ) > Of course, I know that it's an unstable release, but is it really > this hard to install, or is it me doing something wrong? Yes and yes :) I'll describe my methods below.. > How are you installing potato? Is there some magic way > to make ftp install work when there are soft links on > the server? Is there a way to make dselect go on installing > other packages even though it finds ten faulty packages > first in the list? (This way I could add those ten manually > afterwards). I'll say first that we may have slightly different takes on 'install'; I wouldn't say that installing potato has to be done with the standard boot-floppies as long as you end up with a potato system at the end :) I do it with a fairly simple approach. I install the base Slink system, but on the reboot (after setting a root password :) ) I edit /etc/apt/sources.list and change all references to "stable" to "unstable". I then proceed as before. It may be that the archive is in a weird state at the moment; I haven't done this for a few months. I recommend just installing a small set of packages and then adding stuff by hand in dselect (but I recommend this when setting a new stable system up as well -- the metapackage/task system is too broken) I've never run into problems with this (aside from the usual unstable weirdness); if you're doing this and encountering trouble, could you be more precise about what's going on? apt follows symlinks, as (I believe) does dpkg-ftp. Daniel -- "In the Course of my Observation, these disputing, contradicting & confuting People are generally unfortunate in their Affairs. They get Victory sometimes, but they never get Good Will, which would be of more use to them." -- from the autobiography of Benjamin Franklin
Re: in.telnetd and virtual hosting
On Mon, Oct 04, 1999 at 10:18:51PM +0200, Marek Habersack was heard to say: > I'm trying to virtualize in.telnetd to access a chrooted virtual server > (using tcp_wrappers' twist option and Wietse's chrootuid utility). > Everything works just fine until the in.telnetd from chrooted location is > execed. It tries to allocate a pty (via openpty() call), but receives an > ENOENT error meaning that there are no more free pty pairs available, which > is not true, of course. If I use the 'spawn' option in hotst.allow I'm > presented with a login of the normal, non-virtual, server instead of the > new, chrooted, one. Does anyone know what might be the cause of such > behavior and perhaps knows a way to virtualize telnetd? I don't know a whole lot about telnetd and the intricacies of setting up chrooted environments -- but that said, what's in /dev in the chroot jail? I suspect you need to mount a devpts filesystem on /dev/pts for this to work, although I have no idea how Linux would react to having to having multiple devpts filesystems mounted at once. Probably best to try and see :) Daniel -- "People would panic?" "Very briefly, I'm afraid." -- The dangers of colliding with a star examined; Terry Pratchett, _The Light Fantasic_
Weird errors from update-alternatives
My system upgrade today (from yesterday's potato to today's potato) produced the following odd output: Setting up tk8.2 (8.2.0-3) ... Checking available versions of wish, updating links in /etc/alternatives ... (You may modify the symlinks there yourself if desired - see `man ln'.) Leaving wish (/usr/bin/wish) pointing to /usr/bin/wish8.2. Updating wish.1 (/usr/share/man/man1/wish.1.gz) to point to /usr/share/man/man1/wish8.2.1.gz. Removing wish8.0.1 (/usr/man/man1/wish8.0.1.gz), not appropriate with /usr/bin/wish8.2. warning: /usr/bin/wish8.0 is supposed to be a slave symlink to /etc/alternatives/wish8.0, or nonexistent; however, readlink failed: Invalid argument Removing wish8.0 (/usr/bin/wish8.0), not appropriate with /usr/bin/wish8.2. In particular, note the last three lines. /usr/bin/wish8.0 is in the package tk8.0, and I got set to file a Grave bug against something for clobbering a package's files arbitrarily (I wasn't sure whether dpkg or tk8.0 was at fault). However, I decided first to examine /usr/bin/wish8.0 and see what was there now. To my surprise, it was a binary which appears to belong to the tk8.0 package! So there are two things going on here: -> The readlink failure. I suspect that this is occuring because the file is not a symlink. -> The removal message. First, shouldn't update-alternatives do something more graceful than unconditionally clobbering whatever existed there before? Second, why didn't it delete the file? Anyone know why this is, and why I haven't seen this behavior before? (I noticed that dpkg was upgraded over two version numbers, but the only change to update-alternatives doesn't sound like it would be likely to be affected by this..) Daniel -- The Disc, being flat, has no real horizon. Any adventurous sailors who get funny ideas from staring at eggs and oranges too long and set out for the antipodes soon discovert that the reason that distant ships sometimes look like they're disappearing over the edge of the world is that they *are* disappearing over the edge of the world. -- Terry Pratchett, _The Light Fantastic_
Re: Unstable release
On Wed, Oct 06, 1999 at 02:12:08PM +0200, Staffan Hämälä was heard to say: > > NO, NO, NO, this is not redhat.com! Do this on a Debian only if you really > > know what you are doing or you may destroy your system. > > As far as I can see there is often not another way to do it. > Ie., program complains over a lib that is too old. If you try > to install the lib it complains over that there is already an > old version there. That's one of the problems I've encountered > quite a lot of times with Debian, and one of the times I've had > to use the force options. Could you give an example? I'm vague here on what your problem is. > As for the problem with conflicting library versions or whatever > you risk getting into when using --force*, I find that to be > a smaller problem than the problems I get when dpkg complains > about old versions that risk being overwritten. > > Btw, is it possible to tell dpkg to install all dependencies > automagically? > > /Staffan apt is for dependency resolution. Use it. (if there's a reason you can't use it, file bug reports until you can :) ) Daniel -- DROP THE SCYTHE AND TURN AROUND SLOWLY. -- Terry Pratchett, "Reaper Man"
Re: Weird errors from update-alternatives
On Tue, Oct 05, 1999 at 03:30:29PM +0200, Wichert Akkerman was heard to say: > Previously Daniel Burrows wrote: > > My system upgrade today (from yesterday's potato to today's potato) > > produced > > the following odd output: > > What version of dpkg do you have? > > Wichert. Currently 1.4.1.13 . However, I think dpkg may have upgraded itself from 1.4.1.11 during that upgrade run. Daniel -- "I've struggled with reality for thirty-five years, but I'm glad to say that I finally won." -- _Harvey_
Re: Weird errors from update-alternatives
On Tue, Oct 05, 1999 at 05:21:31PM -0400, Andrew Pimlott was heard to say: > See bug 37252--I believe it is responsible for what you are seeking. > > tkstep8.0 registers slave alternatives (under wish) for > /usr/man/man1/wish8.0.1.gz and /usr/bin/wish8.0 . This is bad because 1) > tk8.0 does not register these as slave alternatives, and 2) these are > actually files in tk8.0! > > However, I do not know why it would give this message about > /usr/bin/wish8.0 and not about /usr/man/man1/wish8.0.1.gz . If you want > help pursuing this further, let me know. > > You can also see bug 37254 I reported against dpkg for its role in the > fiasco. > > Andrew Ai! Those are *old* bugs! (although given that dpkg is involved, I shouldn't be too surprised..) It doesn't seem to have trashed my system, and unfortunately I don't have a log of the messages -- I may have had something similar for the manpage that I didn't catch -- so I think I'll just let it go and wait for the slowly-turning gears of Debian to fix it. Daniel -- "Inconceivable!" -- "The Princess Bride"
Re: aptitude
On Wed, Mar 08, 2000 at 08:26:00AM -0500, Daniel Burrows was heard to say: > > What gets me is that aptitude, apt-get, deselect, and gnome-apt all > > seem to give slightly different info on which packages > > are broken, will be deleted, or are on hold. Are the > > dependancy rules interperted differently between these > > programs? > > dselect probably uses a totally different algorithm from the others > > As for the apt-based programs: there are a number of ...argh..I need to get more sleep. Anyway, if you're talking about what happens when you modify a package state, there are a couple of variables that control what happens and a couple of different notions of "broken". For example, you can test separately whether a package is broken now or will be broken after all installs and so on are run. After fiddling with the options a little, I decided to display packages as 'broken' in either case. Selecting packages can also just select that package or select all its dependencies and remove conflicts. I don't remember what gnome-apt or console-apt do in this regard; to turn this behavior on in aptitude (which I don't like as it has hard-to-see side effects), set Aptitude::Auto-Install to "true" in /etc/apt/apt.conf. Also, aptitude tries by default to fix any broken packages, but doesn't use one of the canned routines (I tried and they didn't work well for my purposes..any suggestions on how to go back to them are accepted :) ) -- instead it directly accesses the problem-resolution code. Unfortunately that was a while ago and I don't remember precisely what the problem with pkgFixBroken and friends.. Daniel -- It is hard to think of anything less sentient than a pumpkin. -- Terry Pratchett, _Witches Abroad_
Re: Mozilla
On Thu, Mar 09, 2000 at 08:03:15PM -0500, Will Barton was heard to say: > I dont believe that this is a problem with Mozilla itself, because the binary > tarball of M14 works fine with M13 prefrences. Its only after you install the > deb that this go crazy. > > Has anyone else used both the deb and the binary version of M14 and had > similar results? Yes. I just chalked it up to alpha software and moved on.. Daniel -- It is hard to think of anything less sentient than a pumpkin. -- Terry Pratchett, _Witches Abroad_
Re: Release-critical Bugreport for March 10, 2000
On Fri, Mar 10, 2000 at 03:15:04AM -0600, BugScan reporter was heard to say: > Package: gnomeicu (debian/main) > Maintainer: Edward C. Lang <[EMAIL PROTECTED]> > 58919 gnomeicu causes XServer to grab all the memory. I think there was a discussion on -devel that concluded that there's some evidence that this bug is caused by Imlib.. Also, from the reporter: "I think the bug is Important because it causes the system to became [sic] unusable. But i stil use gnomeicu so, it may not be so RC." Bug severity inflation, perhaps? > Package: mozilla (debian/main) > Maintainer: Debian Mozilla maintainers <[EMAIL PROTECTED]> > 59990 mozilla: Segmentation fault on first start > 60012 M14 segfaults immediately I haven't looked at these (the BTS doesn't even seem to list them), but they're probably just the result of an old ~/.mozilla hanging around.. > Package: rep-gtk (debian/main) > Maintainer: Mikolaj J. Habryn <[EMAIL PROTECTED]> > 58684 rep-gtk_0.8-2(unstable): build error (prototype mismatch) > > Package: sawmill (debian/main) > Maintainer: Mikolaj J. Habryn <[EMAIL PROTECTED]> > [REMOVE] This package can be removed if it is not fixed. > 59760 sawmill: Sawmill fails to load -- missing file > /usr/lib/rep/0.11/i686-pc-linux-gnu/timers.so It would be really unfortunate if we lost these -- but the version of Sawmill this bug is reported against isn't the one in potato!! This is 0.25-1, the latest bleeding-edge release of sawmill, which AFAIK is only in unstable. John appears to have sent a patch for 58684 as well; I don't know if that's fixed or not. > Package: ssh (non-US/main) > Maintainer: Philip Hands <[EMAIL PROTECTED]> > [HELP] Please NMU, with extreme care. Contact Tommi Virtanen for info. > 59464 X11 forwarding appears to be /completely/ broken in 1.2.2-14 This is my bug, and it's fixed now. (although X forwarding is still broken, I can get it to work with some trouble) > 59862 ssh: X forwarding problems even after xauth upgrade Not sure what's wrong there.. Daniel -- "Do you know why the prisoner in the tower watches the flight of birds?" -- Terry Pratchett, _Reaper_Man_
Re: nasty slink -> potato upgrade problem
On Sat, Mar 11, 2000 at 04:37:11PM +0100, Raphael Hertzog was heard to say: > Le Sat, Mar 11, 2000 at 07:06:24PM +1100, Hamish Moffatt écrivait: > > Trouble ahead? > > Please run "apt-get install apt" before doing the dist-upgrade. Old apt > don't manage well the perl transition. This will be documented in the > Release Notes. This is just a thought: would it be a good idea for apt to always upgrade itself before attempting to upgrade anything else? Or would this be better done (if at all) in the frontends? Daniel -- There are many of us in this old world of ours who hold that things break about even for all of us. I have observed, for example, that we all get about the same amount of ice. The rich get it in the summer and the poor get it in the winter. -- Bat Masterson
Re: nasty slink -> potato upgrade problem
On Sat, Mar 11, 2000 at 08:32:07PM -0400, Nicolás Lichtmaier was heard to say: > > > Trouble ahead? > > Please run "apt-get install apt" before doing the dist-upgrade. Old apt > > don't manage well the perl transition. This will be documented in the > > Release Notes. > > Why don't we make the new perls conflict the old apt? I know I suggested something similar earlier, but would this really work? You'd have to restart the apt frontend in order to get the needed effect, even if it correctly upgraded itself. Or am I missing something? (eg..would it just hold back the perl upgrade and require two runs instead of doing something really nasty like it does now? :) ) Daniel
Re: Less interactive upgrades.
It seems to me that a better way to do this (in the abstract case :) ) would be to librarify dpkg -- that is, to make a libdpkg which approximately parallels libapt. This would also have the effect of solving some annoying quirks in the apt/dpkg interaction which are caused (if I remember correctly) by the fact that apt marshalls a whole lot of package installations for a single dpkg call, but can't easily tell which ones were successfully performed and which failed if something goes wrong. Of course, having never even tried to look at dpkg's code, I have no idea how easy this is given the program's design. I suspect that if it were possible someone would have done it already :) Daniel -- The only thing worse than infinite recursion is infinite recursion.
Re: Bug#60753: mutt: /etc/Muttrc should not use colors
On Wed, Mar 22, 2000 at 09:40:56AM +0100, Radovan Garabik was heard to say: > An elegant solution wouldbe to use escape only as a character "escaping" the > next > char, i.e. prefix for control chars, and what we know as an escape character > would be represented as Esc Esc. > > But this would probably break up almost all applications It might not -- most programs (most!) use curses, and very few try to actually catch Escape (due to the historical problems with it). So (a) if curses (and slang?) were modified to handle this, most programs would inherit the changes, and (b) even among the programs that do their own termcap handling, most wouldn't be affected. So -- proof by handwaving that it would work fine.. Daniel -- I used to be indecisive, but now I'm not sure.
Re: 5 days till Bug Horizon
On Wed, Mar 22, 2000 at 10:50:03AM +0100, Richard Braakman was heard to say: [snip] > 59909 cvs: cvs segfaults when commiting a dir FWIW, I've never seen this bug. > Package: rep-gtk (debian/main). > Maintainer: Mikolaj J. Habryn <[EMAIL PROTECTED]> > 58684 rep-gtk_0.8-2(unstable): build error (prototype mismatch) This appears to be an upstream problem specific to that version, which isn't in frozen (and may not even exist in unstable anymore..) Daniel -- Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jeff Raskin
Re: Bug#60753: mutt: /etc/Muttrc should not use colors
On Wed, Mar 22, 2000 at 12:15:42PM -0800, Joey Hess was heard to say: > Daniel Burrows wrote: > > It might not -- most programs (most!) use curses, and very few try to > > actually > > catch Escape (due to the historical problems with it). So (a) if curses > > (and > > slang?) were modified to handle this, most programs would inherit the > > changes, > > and (b) even among the programs that do their own termcap handling, most > > wouldn't be affected. > > Hm, I've written slang programs that catch escape, not to mention jed > catches escape, and there are certianly a large number of curses programs > that do - all falvors of vi (of course!), dialog, and probably a slew more. Oops, you're right. It still seems, though, that Curses should be able to buffer the programs from the fact that the hypothetical "xterm-sane" escapes escape this way.. Daniel -- "Truly, you have a dizzying intellect." -- "The Princess Bride"
Re: APT problem
On Wed, Aug 30, 2000 at 05:32:26PM +0200, Bernd Eckenfels <[EMAIL PROTECTED]> was heard to say: > On Wed, Aug 30, 2000 at 03:49:27PM -0700, Michael Meskes wrote: > > Could anyone please explain this to me? Did Corel do anything to their files > > that makes apt think it has to upgrade although its up-to-date? Or is this > > a bug in apt? > > I see this quite often, so it is a bug in the curret apt lib. aptitude is > even more vulnerable to this... at least the cache does work so u d/l it > only once. Any idea what makes aptitude in particular more vulnerable? I can toss it into the TODO queue. [1] Daniel [1] not that anything is being dequeued at the moment..*sigh*.. -- /- Daniel Burrows <[EMAIL PROTECTED]> -\ | f u cn rd ths,| "The spork is strong with him..." -- Fluble | | u cn gt a jb s| | |a cmptr prgrmr.| | \- The Turtle Moves! -- http://www.lspace.org /
Re: APT problem
On Wed, Aug 30, 2000 at 05:36:12PM -0400, Daniel Burrows <[EMAIL PROTECTED]> was heard to say: > On Wed, Aug 30, 2000 at 05:32:26PM +0200, Bernd Eckenfels <[EMAIL PROTECTED]> > was heard to say: > > On Wed, Aug 30, 2000 at 03:49:27PM -0700, Michael Meskes wrote: > > > Could anyone please explain this to me? Did Corel do anything to their > > > files > > > that makes apt think it has to upgrade although its up-to-date? Or is this > > > a bug in apt? > > > > I see this quite often, so it is a bug in the curret apt lib. aptitude is > > even more vulnerable to this... at least the cache does work so u d/l it > > only once. > > Any idea what makes aptitude in particular more vulnerable? I can toss > it into the TODO queue. [1] (especially since this looks like just the well-established behavior of downloading changed packages..) Daniel -- /- Daniel Burrows <[EMAIL PROTECTED]> -\ | If you're reading | "I've struggled with reality for thirty-five years, but | | this, you have too | I'm glad to say that I finally won." | | much free time. | -- _Harvey_ | \ News without the $$ -- National Public Radio -- http://www.npr.org /
Re: APT problem
On Thu, Aug 31, 2000 at 06:36:34AM +0200, Bernd Eckenfels <[EMAIL PROTECTED]> was heard to say: > On Wed, Aug 30, 2000 at 05:37:52PM -0400, Daniel Burrows wrote: > > (especially since this looks like just the well-established behavior of > >downloading changed packages..) > > I dont have a example right now, but on my system aptitude will download the > same package again and again. So in case it sees a difference must be > related two different sources provide the same package entry. then it > downloads the pakcage from one source and compares it with the entry of > another source. Hmm.. i will watch the problems and report them. Ok, between this and another message sent to me, I think that the problem is that aptitude doesn't clear sticky "reinstall" flags, and must be autoflagging stuff for reinstall when this occur. This doesn't have a really great solution, since you can't (easily) tell whether a reinstall was successful after the fact, but I could just unconditionally clear the reinstall flag for now; I doubt many people use it manually. In the future, I suppose a fancy system for detecting reinstallations is possible, but it might be more trouble than it's worth. Daniel -- /- Daniel Burrows <[EMAIL PROTECTED]> -\ | f u cn rd ths, | Apostrophes are not a warning that a | | u cn gt a jb s | word is about to end in an "s".| | a cmptr prgrmr. | | \-Evil Overlord, Inc: planning your future today. http://www.eviloverlord.com-/
Re: Security of Debian SuX0r?
On Thu, Aug 31, 2000 at 10:03:04AM -0400, Decklin Foster <[EMAIL PROTECTED]> was heard to say: > Peter Makholm writes: > > > I've just helped a friend instaling Debian. He had two comment > > about the above question. Is it the red or blue button there is > > active? It is badly marked which button you are about the press. > > You know, that *has* been bugging me... However you can use the cursor > to figure it out (unless your terminal is weird, I suppose). > > Is this hardcoded into dialog, or could the appearance be configured > by debconf at runtime? I know that joeyh has been working on a much nicer-looking slang frontend which doesn't suffer from this problem; maybe we can just ditch dialog eventually and use that? Daniel -- /- Daniel Burrows <[EMAIL PROTECTED]> -\ | This space |Hi, I'm a .signature virus!| |intentionally|Copy me into your .signature to help me spread!| | left blank. | | \ Real Programmers don't have braces. -- http://www.python.org ---/
Re: ITP lame
On Mon, Sep 04, 2000 at 08:37:20AM -0700, [EMAIL PROTECTED] was heard to say: > Lame could be compiled with vorbis support enabled and mp3 disabled, > perhaps, and go into unstable/main. But would we have to excise the > mp3-specific parts in the source package in order to do so? This is something I've been curious about since noticing that Lame supports Vorbis: why would you use Lame to encode a Vorbis file when Vorbis comes with its own encoder? Am I missing something? Daniel -- /----- Daniel Burrows <[EMAIL PROTECTED]> -\ | This space| "We've got nothing to fear but the stuff that we're | | intentionally |afraid of!" -- Fluble| |left blank.| | \--- (if (not (understand-this)) (go-to http://www.schemers.org)) / -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
