Bug#284030: ITP: asymptote -- script-based vector graphics language inspired by MetaPost
Package: wnpp Severity: wishlist * Package name: asymptote Version : 0.53 Upstream Author : Andy Hammerlindl, John Bowman, Tom Prince * URL or Web page : http://asymptote.sourceforge.net/ * License : GPL Description : script-based vector graphics language inspired by MetaPost Asymptote is a powerful script-based vector graphics language for technical drawings, inspired by MetaPost but with an improved C++-like syntax. Asymptote provides for figures the same high-quality level of typesetting that LaTeX does for scientific text. Preliminary packages available at: http://www.uhoreg.ca/programming/debian/
Re: Print Alternative
>>>>> "Gustavo" == Gustavo Noronha Silva <[EMAIL PROTECTED]> writes: [...] Gustavo> Having seen the code for the beast, I don't know if it does the Gustavo> Right Thing. It uses the 'print' alternative to find out what Gustavo> spooling system is being used. So if /usr/bin/print points to Gustavo> /usr/bin/lpr, the currently used daemon is lprng, if it points Gustavo> to /usr/bin/lp, it is using cups (I'm not very familiar with Gustavo> printing systems, though, so I may be wrong with the names and Gustavo> all that). Which is sort of stupid, because if you have cupsys-bsd installed, you get /usr/bin/lpr too. And someone could make /etc/alternatives/print point to that. There must be some better way of detecting which system is being used. e.g. checking the presence of /etc/cups Is it just me, or is this the wrong way to use alternatives? lpr and lp have very different command line syntaxes. Especially for important things like selecting which printer to print to. Something like that shouldn't be handled by alternatives. Gustavo> It would not be a problem if we could only have one spooling Gustavo> daemon at a time, but that does not seem to be the case for Gustavo> Debian. I see cupsys conflicts with newer versions of lprng, Gustavo> but it will allow lpr to be installed. Eh. If you have more than one spooling daemon installed, then it's not clear what the tool should do. Better to make a config file that says which system to configure. Or just configure all of them. Besides, everyone should be using CUPS anyways, right? ;-) -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Bug#342134: ITP: popplerkit.framework -- GNUstep framework for accessing PDF content
Package: wnpp Severity: wishlist * Package name: popplerkit.framework Version : svn snapshot Upstream Author : Stefan Kleine Stegemann * URL or Web page : http://download.gna.org/gsimageapps/PopplerKit * License : GPL Description : GNUstep framework for accessing PDF content PopplerKit is a GNUstep framework for accessing and rendering PDF content. It is based on the poppler library. . Its features are: - Render PDF content. - Extract text from a PDF document. - Access a PDF document's outline. - Search in PDF documents. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Sat, 11 Feb 2006 10:23:10 +0100, Henning Glawe <[EMAIL PROTECTED]> said: > just one thought: we have programs in main, where derived works are > only allowed as original source+patches (TeX comes to my mind...) > couldn't it be basically the same thing with GFDL documents? if there > is an invariant section with an 'ode to my cat', why can't we add a > section to the document telling the 'ode to my cat' is bloody > stupid. this would be in some sense equivalent to a patch, only the > interpreter is not the computer but the human brain (which is the > target architecture for documentation anyways). (sorry, couldn't > resist ;) ) Another difference is that a patch modifies the file before it is shipped to the interpreter/compiler, whereas an addendum to an invariant section is meant to be sent to the interpreter/compiler along with the original unmodified source. Unless you have a separate process in your brain that scans the document, applies the addenda, and then ships the result to the rest of your brain... (P.S. How did this discussion end up in -devel? It isn't "Discussion about technical development topics.") -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
>>>>> "Adrian" == Adrian Bunk <[EMAIL PROTECTED]> writes: Adrian> On Fri, Apr 15, 2005 at 02:22:11PM +0100, Matthew Garrett wrote: [...] >> The fact that we can remove the documentation and still distribute >> the software demonstrates that it isn't an unavoidable requirement. s/still distribute/still legally distribute/ License text is legally required. Documentation is not. Adrian> The question remains whether a gcc or MySQL without Adrian> documentation is of any practical value. I don't know about MySQL, since I've never used it. But gcc is still useful for compiling packages from source, and you don't need to look at the documentation for that; just run dpkg-buildpackage. In fact, I've never looked at the gcc documentation other than to look up machine-specific options and optimization flags. It's easy to use gcc without the documentation. Even in the case of MySQL, I'm sure that some packages that use it or depend on it will tell you exactly what you need to do to set it up so that it's usable to that package. Or they may even do the setup for you. [...] Adrian> Until recently, non-free contained only some obscure things most Adrian> people didn't require. ... Such as a graphical web browser, back in the time before mozilla existed or was usable. Or acroread (before the security vulnerability, when it was decided to just drop it from the archive altogether), or the Flash plugin (well, it's in contrib, but only because it downloads the actual plugin from the web) or msttcorefonts (also in contrib, for the same reason as the Flash plugin). Or giflib. Those are all obscure things. In fact, the GR last year [1] showed that most DDs think that non-free still contains useful software; not just obscure stuff. [1] http://www.debian.org/vote/2004/vote_002 -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
>>>>> "Adrian" == Adrian Bunk <[EMAIL PROTECTED]> writes: Adrian> On Fri, Apr 15, 2005 at 11:58:52AM -0400, Hubert Chan wrote: >> ... In fact, I've never looked at the gcc documentation other than >> to look up machine-specific options and optimization flags. It's >> easy to use gcc without the documentation. Adrian> Simple usage might work, but as soon as you reach any question Adrian> like e.g. Adrian> How do I pass in a additional path to the include path of gcc? Adrian> Which optimization levels does gcc support? These are widely known, and can be found in many makefiles, or by asking around. Optimization levels is also not something that is required knowledge; you an write a perfectly usable program without tweaking the optimization. Adrian> Which optimization option is best for my CPU? You wouldn't be able to find this in the documentation anyways. The "best" optimization depends on the CPU on the program characteristics. If you want to find this out, you could run your program through something like acovea. Adrian> you are pretty lost without the documentation. To make things clear, I'm _not_ saying that the documentation is useless. There are some things that you probably can't find out without reading the documentation (or the source code), such as more obscure stuff like architecture-specific flags. *But* documentation is in a much different class than license text. For license text, it is *legally required* to include it with the software. But software is still usable without documentation, and hence documentation is not a dependency. In fact, there's still quite a bit of software that doesn't even have documentation (of free documentation). If gcc (or MySQL, etc.) didn't come packaged with documentation and the only documentation available was non-free, we wouldn't be having this discussion. We'd all just be complaining that gcc doesn't have any good free documentation. But people would still be able to use gcc -- just not as well as they would if they had access to good documentation. Just like many completely undocumented programs today are still usable, but not as well as they would be if they had some form of documentation. This doesn't mean that these undocumented programs are unsuitable for distribution. This just means that someone should write some (free) documentation. Likewise, gcc doesn't need to go into non-free just because its documentation is DFSG non-free. It just means that someone should write DFSG free documentation. (Or that we should modify the DFSG so that the GFDL can be considered DFSG free, but I can't think of any sane [1] definition of free that would allow that; obviously the FSF thinks differently from me.) [1] "sane" meaning it has to still have some semblance to free-ness. If you define "free" as "everything is free", then certainly the GFDL is free, but most people would agree that such a definition is non-sane. Yes, I agree with you that good documentation is very useful and helps you use the software better than if you didn't have access to good documentation. But it is _not_ a *requirement* or *dependency*, since it is still usable without the documentation. I recently started looking at the GNUstep libraries, and tried my hand at writing a program using them. Documentation does exist, but it is highly inadequate -- it's easier to just read through the header files. So I ended up buying a couple of non-free books. Does this mean that GNUstep is non-free because I needed to buy some non-free documentation? No, it just means that we need to improve the quality of the free documentation. [...] Adrian> My point is: Adrian> Non-free was going to contain mostly obscure things now that Adrian> there are free replacements for Netscape and Acroread. Adrian> Debian's steps of moving more and more things into non-free Adrian> forces many users to use non-free who wouldn't do otherwise. Adrian> Is this effect really wanted? No. Ideally, we would have documentation that was DFSG free. But what are the alternatives to moving GFDL documentation to non-free? It seems you are suggesting that we could move gcc et al. into non-free as well, and I think we both agree that that would be an even worse solution. We could also just keep GFDL documentation in main, but that would violate our Social Contract as it stands today (or, rather, after Sarge is released). We could modify our social contract again (but after GR 2004-003 [2], I doubt there would be much support for that, although anyone is free to try). We could keep postponing the Social Contract changes [3] indefinitely, but I don't think that would get much support either. Or we could modify the DFSG so that the GFDL would be considered free. Again, I ca
Re: Why does Ubuntu have all the ideas?
On Sat, 29 Jul 2006 00:31:53 +0200, Stefano Zacchiroli <[EMAIL PROTECTED]> said: [...] > But the issues of disagreement on the topic of a given NMU was not my > point. It was rather to ease as much as possible the flow of code from > DDs workstations to debian packages. [... some good stuff snipped ...] > We should strive to simplify that model and it happens that we do have > a working alternative (packages collaboratively maintained on alioth), > we should just use it extensively. I more or less agree with what you said. There are a few ways, currently, that people can contribute to Debian packages, such as submitting bugs to the BTS, doing NMUs, or trying to organize collaborative maintenance (through alioth, or other mechanisms). And I think that each has its place. There are packages that I'd like to see improved, but I don't have time to dedicate to maintaining them, so I may send a patch. Or, if the maintainer seems unresponsive, and the bug is important enough, I may do an NMU (which of course does place extra burden on me, since now I have to follow the package to make sure I didn't introduce bugs). And conversely, for packages that I maintain, I welcome patches, and if I seem to be unresponsive, an NMU may be in order. And, of course, packages that I care more about, if I have time and it seems like the current maintainer needs help, I may offer to co-maintain the package (and conversely, for packages that I maintain, I may welcome co-maintainers as well, depending on the package -- for some packages, the overhead of co-maintenance is greater than any benefit that we might get). -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On Sat, 29 Jul 2006 20:00:21 +, "Gustavo Franco" <[EMAIL PROTECTED]> said: [...] > The packages that aren't under group maintenance and will never be, > needs more not so strict NMU rules. Why? -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On Mon, 31 Jul 2006 11:40:54 -0300, "Gustavo Franco" <[EMAIL PROTECTED]> said: > On 7/31/06, Hubert Chan <[EMAIL PROTECTED]> wrote: >> On Sat, 29 Jul 2006 20:00:21 +, "Gustavo Franco" >> <[EMAIL PROTECTED]> said: >> >> [...] >> >> > The packages that aren't under group maintenance and will never be, >> > needs more not so strict NMU rules. >> >> Why? >> > Due to the "my stuff, don't touch that!" current approach, but (again) > this is just IMHO. I disagree with that. (IMHO) I think that the "my stuff" approach has more to do with maintainer attitude than with NMU rules. I don't think that loosening the NMU rules will decrease the maintainers' possessiveness. The current rules already authorized all DDs to make NMUs, if you follow the procedures. And if you follow the current NMU rules, then the entire process will take, what, a couple of weeks? My own opinion is that if you loosen the NMU rules, we'll get more bad NMUs, which will result in more annoyed maintainers, which will increase possessiveness. (NMUs will be seen as sources of breakages, rather than as sources of fixes.) I also don't see why we would need to relax the NMU rules for all packages that are not under group maintenance. One of the packages that I maintain is extremely tiny (relatively speaking), and at the moment has a very slow upstream release cycle. If a normal-severity bug doesn't get fixed for two weeks, it's not the end of the world. And there is absolutely no reason why that package should be group-maintained -- adding a group would add more overhead, and produce no benefit. So I don't see why that package should have looser NMU rules than other packages, such as the GNUstep core library packages, which are maintained by a group (even though I'm basically the only one who maintains them), but has the potential of breaking other packages if it is broken. If we are going to loosen the NMU rules (or decrease the time for an NMU), I think it should be applied to all packages, and not just packages that are not group-maintained. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On Mon, 31 Jul 2006 19:30:34 +0300, George Danchev <[EMAIL PROTECTED]> said: > IMHO the maintainer(s) could mention their wishes wrt to NMU and any > particular package in debian/copyright, right after This package was > debianized by ... When needed NMU is appreciated/forbidden/whatever I agree that it could be helpful to document a maintainer's preference somewhere, but I'm not sure that debian/copyright is the right place. Maybe in the PTS, or getting it to show up in some extended view of the BTS, or in db.debian.org (although that won't help non-DDs). I like the LowThresholdNMU idea, but I won't be signing on for that because my own preferences are a bit stricter than what's on that page. It would be nice to document somewhere that I don't mind (well-made) NMUs, but please contact me first -- give me about a week to respond, and if I don't respond by then (and I haven't announced that I'm on vacation), then you can assume that I'm MIA, and NMU to your heart's content. Another question is: right now, LowThresholdNMU is opt-in: add your name to the list if you don't mind NMUs. I wonder how people would feel about changing it so that the default is low-threshold -- for those who don't say anything, we assume by default that NMUs are OK, and if you don't want people to touch your packages, or have other preferences, then you publish that in some generally-known area, wherever we choose to publish that information. (Of course, I think that you should always be allowed to NMU by following the procedures that we already have.) > That will help to avoid some confusion, when people are in doubt wrt > "to NMU or not to NMU". -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg doing wrong math (0.09 = 0.9) ?- [was: dak now supports ~ in version numbers]
On Fri, 11 Aug 2006 01:12:59 +0200, Michael Biebl <[EMAIL PROTECTED]> said: [...] > If it's not a bug in dpkg, could someone please elaborate on the > reasoning of this behaviour. I'd be grateful for any comments and > replies. It's documented in Policy 5.6.12 [1]. Substrings composed of digits are compared numerically, and so 09 == 9. (This is done to ensure that 10 > 9, for example.) [1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version So I guess your only real option is to use an epoch. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Jorg Schilling wrote: [...] > Sorry, but I do not believe people that put things into a GPL FAQ that > are obviously wrong. Let me give a single example to avoid wasting too > much time: > The FSF GPL FAQ e.g. incorrectly claims: > Linking ABC statically or dynamically with other modules is > making a combined work based on ABC. Thus, the terms and > conditions of the GNU General Public License cover the whole > combination. > The GPL does not contain the term "combined work", so this is an > invalid claim. The GPL does, however, contain the term "work based on [the Program]". Calling it a "combined work based on [the Program]" does not change the fact that it is a "work based on [the Program]". The "combined" is merely a clarification on the term. > The GPL rather talks about a "derived work" and simply linking two > modules together does definitely not make module B a "derived work" of > module A if module A calls code from module B but module B does not > call code from module A. No, but the combined work (A+B) (i.e. a binary produced by linking module A with module B) is a "work based on" A, and hence (A+B) must be distributable under the terms of the GPL. Distributing the sources of A with the sources of B may be fine, but Debian would not be legally allowed to distribute a binary produced by linking A with B, since this would not be "mere aggregation". You brought up the question of Cygwin in a previous message, but that is covered by the exception given in the second-last paragraph of section 3. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Fri, 11 Aug 2006 23:25:52 +0200, Joerg Schilling <[EMAIL PROTECTED]> said:
> Hubert Chan <[EMAIL PROTECTED]> wrote:
>> No, but the combined work (A+B) (i.e. a binary produced by linking
>> module A with module B) is a "work based on" A, and hence (A+B) must
>> be distributable under the terms of the GPL.
>>
>> Distributing the sources of A with the sources of B may be fine, but
>> Debian would not be legally allowed to distribute a binary produced
>> by linking A with B, since this would not be "mere aggregation".
> If you try to again post claims that have already proven to be wrong,
> I see no reason to continue this "discussion", it only wastes time...
> The GPL is a source license. The fact that you are thinking about the
> "license for a binary" verifies that you did not understand the GPL.
The GPL (section 3) does restrict distributions of binaries ("object
code or executable form", to use the words of the GPL, to be more
accurate, since the GPL only uses the term "binary" once, and only to
refer to a completely different issue) and states that such binaries
must be distributed under the terms of sections 1 and 2 (which seem to
be the important parts of the GPL as far as Debian is concerned).
Section 2b also then states that anything "... derived from the Program
..." must be licensed under the terms of the GPL, and I can't see how a
binary is not "derived from the Program".
The only place in the GPL that restricts its terms to applying to
sources is section 1, which refers to "verbatim copies of the Program's
source code as you receive it".
The GPL is a source license in the sense that it does not make sense to
apply it only to a binary, due to section 3. But that does not mean
that its terms do not apply to binaries as well.
[...]
> I did never claim that any possible combination of CDDL & GPL code is
> permitted. ...
Understood. I think that we all agree that, say, taking code licensed
under the CDDL and linking it to a GPLed library is not allowed. (And
we all agree that that is not the situation that we're talking about.)
--
Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net)
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Schilling wrote: > Nice to see that this video clip verifies my statements in case you > carefully listen to Simon Phipps: > - Sun did not make the CDDL incompatible by intention to the GPL Are you talking about what he's saying at approx. minute 36? That's the closest thing I could find to what you're claiming he said, but he's talking there about why they didn't release OpenSolaris under the GPL. He's not saying anything about whether or not the CDDL is incompatible with the GPL. > - The only thing that prevents Linux to use the DTrace code in > Linux is the different threading model Actually, what he's saying is that the different threading model prevents you from cut-and-pasting code. He's saying that in order to port DTrace to Linux, due to the different architecture, you would have to basically rewrite it, and so the CDDL would not cause any problems in that case, since you are rewriting, and would not be creating a derivative work. What he's saying is that the technical problems are bigger than the legal problems, and that the most sane way to get around the technical problems are to do so in such a way that the legal problems no longer apply. He is not saying that there are no legal issues. > - Eben Moglen tells you that what I do in cdrtools is OK: > "They" the FSF and Moglen have only be in fear that people > could interpret the GPL in a wrong way and for this reason > added the OS exception, but the GPL does allow to link a > GPLd project against libraries under other licenses. He's specifically talking about the so-called "operating system exception" in the GPL v2, and what the GPL v3 refers to as "System Libraries". He's not talking about any random library. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
On Sat, 26 Aug 2006 15:26:12 + (UTC), "Sam Morris" <[EMAIL PROTECTED]> said: > On Sat, 26 Aug 2006 16:02:04 +0200, Hendrik Sattler wrote: >> Am Samstag 26 August 2006 15:15 schrieb Theodore Tso: >>> No support for: (The * are critical) >>> >>> * SATA Hard Drives (*) >>> * Intel AD1981 HD Audio (*) >> >> This stuff did not even exist when Sarge was released. Half of >> userland would not fit this hardware, so who cares. > How do other long-lived distributions handle this problem? How does > one install RHEL 4 on such a machine? By downloading pre-compiled kernel modules (usually from the hardware vendor, or from another vendor that ships the same hardware). -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
On Sat, 26 Aug 2006 21:29:37 -0500, John Goerzen <[EMAIL PROTECTED]> said: > On Sat, Aug 26, 2006 at 01:19:47PM -0600, Hubert Chan wrote: >> On Sat, 26 Aug 2006 15:26:12 + (UTC), "Sam Morris" >> <[EMAIL PROTECTED]> said: [...] >> > How do other long-lived distributions handle this problem? How does >> > one install RHEL 4 on such a machine? >> >> By downloading pre-compiled kernel modules (usually from the hardware >> vendor, or from another vendor that ships the same hardware). > How do you get that on the install CD-ROM? You don't. (Sorry, I probably should have included this in my original message.) The RHEL 4 (and similar distributions) installer at some point asks you if you want to load an external module. You stick in a specially formatted floppy, tell the installer to load the module from the floppy, and then it loads the module and detects your hardware. (The exact details are sketchy -- the only time I did it was several months ago, in the middle of installing a whole bunch of new machines, so I don't remember all the details. But that's the basic idea.) (Note: I'm not the administrator for those machines. Otherwise, they'd be running some flavour of Debian.) FWIW, the Windows installer does a similar thing, as well. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: adun.app -- a Molecular Simulator
On Wed, 30 Aug 2006 22:12:04 -0400, Daniel Dickinson <[EMAIL PROTECTED]> said: > On Thu, Aug 31, 2006 at 09:24:21PM +1000, Steffen Joeris wrote: >> Hi >> >> > * Package name : adun.app >> Maybe I miss some essential parts, but I always wonder why some >> people add a .app to the software name? Can you please give me a >> short explanation or point me to a previous thread? > IIRC .app is usually used by apps with gnustep support (e.g. WindowMaker > dockapps). It doesn't normally mean they only work on gnustep though, > just that they use some features from gnustep, when available. To clarify, ".app" is generally used by GNUstep programs, and for some dockapps. Dockapps that are not written specifically for GNUstep don't use GNUstep features at all, and those that use GNUstep features rely on GNUstep. I am not aware of any that don't rely on GNUstep, but that use GNUstep features when present. There seems to be only a handful of dockapps that use ".app", though, so if you see a package that says ".app", chances are that it's a GNUstep program. And nearly all GNUstep programs say ".app". The ".app" comes from the NeXT nomenclature of programs. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[vac] Sept 1 to Sept 17
Since I'm not a DD yet, I can't tell db.debian.org that I'm on vacation, so this will have to do. I'll be on vacation from September 1 to September 17. I will have occasional email access, but it is unlikely that I'll be able to upload much, or do much development, until Sept. 17. NMUs for my packages are welcome for RC bugs, but please try to coordinate with me first (I will still have some email access), since I have a few packages that have already been sent to sponsors for uploading. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA pgpqAkkCdJbyR.pgp Description: PGP signature
Re: delay of the full etch freeze
On Thu, 12 Oct 2006 09:38:21 +0900, [EMAIL PROTECTED] said: > Le Wed, Oct 11, 2006 at 06:58:55PM +0200, Andreas Barth a écrit : >> >> For these reasons, we are delaying the full archive freeze for a few >> days. We haven't chosen a date yet, but you can still expect it to >> happen in October or early November. > Dear Andreas, > May I suggest to delay the freeze as long as it is necessary for the > packages which were uploaded to NEW before the 8th to enter in Etch if > they have no bugs? [...] It is probably better, in general, to let the RMs decide on a freeze date, and make special exceptions for packages that are stuck in NEW, if they choose, rather than to keep pushing back the freeze. Of course, depending on when the actual freeze occurs, and how quickly NEW is processed (which seems to be going more quickly now), this point may be completely moot anyways. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Re: Bug mass filling
On Sat, 21 Oct 2006 15:40:28 -0500, Manoj Srivastava <[EMAIL PROTECTED]> said: > Gee. Don't we already have something very like this? > These classifications are roughly equivalent to the bug > severities _serious_ (for _must_ or _required_ directive violations), > _minor_, _normal_ or _important_ (for _should_ or _recommended_ > directive violations) and _wishlist_ (for _optional_ items). [2] Well, it says "... _roughly_ equivalent". So it seems to me that both places (http://www.debian.org/Bugs/Developer and policy section 1.1) that attempt to correlate policy violations and bug severity do so with some hedging, and do not try to define a direct mapping. Given the amount of confusion on the issue (the single word "roughly" is easily missed), I think that it would be a good idea to either update policy so that "must"/"required" violations correspond exactly to the release team's definition of release-critical, or to change the wording to make it more explicit that a "must"/"required" violation is not necessarily release-critical. For the second option, (a very rough draft of) possible changed wording for www.debian.org/Bugs/Developer is: serious is a severe violation of Debian policy (roughly, it violates a "must" or "required" directive, although the severity of a policy violation is determined by the release managers), or, in the ... and for policy: These classifications are roughly equivalent to the bug severities serious (for must or required directive violations), minor, normal or important (for should or recommended directive violations) and wishlist (for optional items). [2] However, this is not a direct mapping, and the release managers determine which violations are considered release-critical. -- Hubert Chan <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava <[EMAIL PROTECTED]> said: [...] >> and for policy: >> These classifications are roughly equivalent to the bug severities >> serious (for must or required directive violations), minor, normal or >> important (for should or recommended directive violations) and >> wishlist (for optional items). [2] However, this is not a direct >> mapping, and the release managers determine which violations are >> considered release-critical. > where does release criticality jump in here from? Policy has > no mention of RC in this context, I see no reason to suddenly inject > one. Well, I did say that it was a very rough draft. ;) Second try: "... However, this is not a direct mapping, and the release managers determine the severity of each violation." > The problem is there are two mappings, one from policy > violations over to bug severities, and another from severities to > RC. The former is , according to policy, pretty static; the latter is, > by the release team directive, a fluid mapping based on the contents > of a web page, which is updated by the RM's as needed. > I don't see any reason to fuzzy up the first mapping; and I > see the etch-ignore tag as a perfectly legitimate and adequate > representation of the fluidity of the second mapping. >From my reading, the language for the first mapping is already a bit fuzzy, since both places that define the mapping use the word "roughly". So I think that we should either make it explicitly fuzzy by changing the wording, or make it explicitly not fuzzy by removing the word "roughly" (and possibly changing policy to reflect reality). I also would prefer if the first mapping wasn't fuzzy. But it sounds to me like the release team is reading it as being a fuzzy mapping (AFAICT), in which case I would suggest making it more clear that the mapping is fuzzy. -- Hubert Chan <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On Tue, 24 Oct 2006 17:00:45 -0500, Manoj Srivastava <[EMAIL PROTECTED]> said:
> On Tue, 24 Oct 2006 13:49:01 -0400, Hubert Chan <[EMAIL PROTECTED]>
> said:
>> On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava
>> <[EMAIL PROTECTED]> said: [...]
>>>> and for policy:
>>>> These classifications are roughly equivalent to the bug severities
>>>> serious (for must or required directive violations), minor, normal
>>>> or important (for should or recommended directive violations) and
>>>> wishlist (for optional items). [2] However, this is not a direct
>>>> mapping, and the release managers determine which violations are
>>>> considered release-critical.
>>> where does release criticality jump in here from? Policy has no
>>> mention of RC in this context, I see no reason to suddenly inject
>>> one.
>> Well, I did say that it was a very rough draft. ;)
>> Second try: "... However, this is not a direct mapping, and the
>> release managers determine the severity of each violation."
> Direct mapping of *WHAT*? are you falling into the assumption
> that serious == RC? Why?
No, the previous sentence (which is what we currently have in policy)
defines a mapping of serious bug <=> "must"/"required" directive
violation, and minor/normal/important bug <=> "should"/"recommended"
directive violation, and wishlist bug <=> "optional". That's the
mapping that it is referring to.
My understanding is that the release team treats that as an approximate
mapping, and the current wording of policy allows this due to the use of
the word "roughly".
("Mapping" may not be the best word to use in policy. But like I said,
it's a rough draft.)
--
Hubert Chan <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED]
PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On 23 Nov 2006 22:40:01 +0200, Jari Aalto <[EMAIL PROTECTED]> said: > My point. If there is explicit "Depends: bash", then someone can post > a patch to provide alternative solution to a person who may not know > alternative constructs (having learned only bashism). Sorry, but I don't understand what you're trying to do here. Can you please explain what dependencies have to do with wishlist bugreports? -- Hubert Chan <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy, version two
On 25 Nov 2006 10:02:14 +0200, Jari Aalto <[EMAIL PROTECTED]> said: > Hubert Chan <[EMAIL PROTECTED]> writes: >> On 23 Nov 2006 22:40:01 +0200, Jari Aalto <[EMAIL PROTECTED]> >> said: >> >> > My point. If there is explicit "Depends: bash", then someone can >> > post a patch to provide alternative solution to a person who may >> > not know alternative constructs (having learned only bashism). >> >> Sorry, but I don't understand what you're trying to do here. Can you >> please explain what dependencies have to do with wishlist bugreports? > "Depends:" make dependency visible, whereas filing a wishlist is > usually result of someone by accident finding the script to include > bashism. He may offer a patch to convert those constructs to standard > sh-way-of-doing-things. > It's easier to eyeball packages that explicitly announce "bash". > Those could be put to a stress test through: IMHO, this is trying to use dependencies for something that it was not meant for. Sure, it may make it easier to find scripts with possible bashisms, but I would not consider this to be a reason for telling people to depend on bash, just to make someone else's job easier. Those who care can 'grep "#\! */bin/bash" /usr/bin/* /etc/init.d/*' etc, or run through the archive. If a maintainer knows about a bashism and is interested in getting rid of it but doesn't know how, they can file a wishlist bug against their own package, and tag it 'help'. Making "Depends: bash" a requirement would affect too many packages, and making it a suggestion is IMHO no better than asking maintainers to file wishlist bug reports. -- Hubert Chan <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Proposal for official screenshot repo
Roberto C. Sanchez wrote: > On Thu, Jan 04, 2007 at 05:41:35PM +0100, Javier Fernández-Sanguino Peña > wrote: >> - Provide an HTML interface to the pool >> If the packages names are the same I don't see the need to add yet another >> line to the debian/control file, packages.debian.org would just need to point >> to http://screenshots.debian.org/ and that's it. > Good idea. I'd not though about it that way. We would then only need a > default place holder for packages without screenshots. Another thing you may want to consider is to allow for redirects. e.g. if someone is looking for screenshots for, say, mozilla, then you can tell them to go to the iceape page instead. -- Hubert Chan <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Re: Australian timezone (australasia) update for this weekend
Hi Aníbal, On Thu, 23 Mar 2006 10:22:37 +1100, Aníbal Monsalve Salazar <[EMAIL PROTECTED]> said: > Hello, The Australian timezone change is a couple of days away. If you > are running servers depending on acurrate time, you will need to check > or update them. > If you are running sid (unstable) or etch (testing), to update your > Australian timezone, just run 'apt-get update; apt-get install libc6'. Could you let us know which version the change is in, so that those who already have versions with the change included don't have to worry about upgrading if they don't need to? Testing has libc6 2.3.6-3. Is it safe to assume that any 2.3.6 version will have the correct time zone information? Thanks -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Re: /etc/apt/preferences (was: Bug#354674: What on earth?)
On Tue, 18 Apr 2006 09:29:14 +0200, Marc Haber <[EMAIL PROTECTED]> said: > On Sun, 16 Apr 2006 19:19:40 +0200, Pierre HABOUZIT > <[EMAIL PROTECTED]> wrote: >> it's already quite penible to use experimental (to avoid to pull >> every single experimental package, you have to edit your >> /etc/apt/preferences, > Furthermore, /etc/apt/preferences doesn't allow wildcarded package > names - it's either "the complete distribution" or "a single package > per stanza", which is a major annoyance. I use: Package: * Pin: release a=experimental Pin-Priority: 101 which results in packages that I installed from experimental automatically tracking experimental, while all the other packages track sid. I don't quite understand exactly why it works... -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 4
On Tue, 9 May 2006 22:49:36 +0200, Bill Allombert <[EMAIL PROTECTED]> said: > Debian GNUstep maintainers ... >gnustep-ppd Ah, I didn't notice gnustep-ppd was involved in a circular dependency as well. This one should be easy to fix. (And I'm working on the other GNUstep packages this week.) > Hubert Chan <[EMAIL PROTECTED]> >alsaplayer-alsa >alsaplayer-common >alsaplayer-gtk Hmm... alsaplayer-common Depends: on "alsaplayer-alsa | alsaplayer-output" and "alsaplayer-gtk | alsaplayer-interface". Is this really a problem? -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 4
On Wed, 10 May 2006 09:04:14 -0400, James Vega <[EMAIL PROTECTED]> said: > On Wed, May 10, 2006 at 12:32:53AM -0400, Hubert Chan wrote: >> Hmm... alsaplayer-common Depends: on "alsaplayer-alsa | >> alsaplayer-output" and "alsaplayer-gtk | alsaplayer-interface". Is >> this really a problem? My question, which I guess wasn't clear, was whether the circular dependency is still a problem if one of the dependencies in the cycle is an or'ed dependency. [...] > There's no real reason that alsaplayer-common needs to Depend on an > alsaplayer-output variant or an alsaplayer-interface variant. As a > user, if I just want to look at the common files for some reason, I > sholudn't need to install alsaplayer-(output|gtk). Those would be > fine as Recommends. alsaplayer-common contains the main alsaplayer binary (/usr/bin/alsaplayer), which does not function without an alsaplayer-output and alsaplayer-input plugin. So yes, it really does depend on these. (I would have named alsaplayer-common something different -- maybe alsaplayer-bin, or just alsaplayer, but that was what it was called when I inherited it.) A Recommends: might work, since aptitude will try to install recommended packages, but I think that Depends: describes the package relationship much better, and so I don't want to change it unless absolutely necessary. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 4
On Wed, 10 May 2006 14:24:58 -0400, James Vega <[EMAIL PROTECTED]> said: > On Wed, May 10, 2006 at 01:41:56PM -0400, Hubert Chan wrote: >> alsaplayer-common contains the main alsaplayer binary >> (/usr/bin/alsaplayer), which does not function without an >> alsaplayer-output and alsaplayer-input plugin. So yes, it really >> does depend on these. (I would have named alsaplayer-common >> something different -- maybe alsaplayer-bin, or just alsaplayer, but >> that was what it was called when I inherited it.) > Ah, yes, I didn't take a look at the packages as well as I should > have. Taking a look at the package contents, it seems like changing > the alsaplayer-(output|input) variants to Recommending > alsaplayer-common would work fine. Ah, looking at the changlogs, those dependencies were added because of Bug #185814 -- alsaplayer-common only works with alsaplayer plugins from the same version. Ugh. Yeah, I'll try to figure out how to fix this properly. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Real Life hits: need to give up packages for adoption
On Mon, 29 May 2006 21:29:34 +0200, [EMAIL PROTECTED] (Unknown) said: > * ufraw (need to package new Upstream; easy) I can take this if nobody else wants it. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
On Mon, 3 Jul 2006 15:04:14 +0200, Adam Borowski <[EMAIL PROTECTED]> said: > On Sun, Jul 02, 2006 at 11:57:50AM +0200, Wouter Verhelst wrote: >> Additionally, it puzzles me how you think a maintainer will be able >> to accurately predict how much RAM a certain build is going to >> use. There are so many variables, that I think anything but 'this is >> the fastest way to build it on my machine' is going to be unfeasible. > Let's say: program X consist of a number of C files; it seems like > compiling every file takes around 24MB, with the final link taking > much more[1]. I guess this can be called typical, in C you need to > store just the current file and the headers you use. But the amount of RAM taken depends on many factors, such as (just off the top of my head) architecture, compiler, the libraries used. (e.g. I have a package that builds fine in my sid pbuilder on my 128MB box, but it eats memory like crazy in my sarge pbuilder on the same box, AFAIK mostly due to the older compiler.) -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
On Fri, 21 Jul 2006 17:58:51 +0200, Bill Allombert <[EMAIL PROTECTED]> said: > Debian GNUstep maintainers <[EMAIL PROTECTED]> > gnustep-back0.10 > gnustep-base-common > gnustep-gpbs > gnustep-gui-common > libgnustep-base1.11 > libgnustep-gui0.10 Fixed in my own local repository. Waiting for the next upstream release before uploading (to avoid having to rebuild all GNUstep packages twice). -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Self-conflicts and self-depends
On Thu, 27 Jul 2006 00:22:54 +1000, Hamish Moffatt <[EMAIL PROTECTED]> said: > On Wed, Jul 26, 2006 at 01:17:30PM +0200, Fabio Tranchitella wrote: >> A: nothing; >> B: provides A; conflicts A >> >> ... which produces the same result, because you can't install both A >> and B because B conflicts with (the real package) A. >> >> For me, self-conflicts make no sense in every situation. > Now extend for more than two packages. Should each package list every > other, require every package to be updated when another is added? A: nothing; B: provides A; conflicts A C: provides A; conflicts A D: provides A; conflicts A E: provides A; conflicts A F: provides A; conflicts A . . . > Instead they can all provide and conflict a common virtual package. Or, yes, they can do that. (In fact, the above is basically the same thing, except that package A happens to be named the same as the virtual package.) But this doesn't give any reason for why package A needs to conflict with itself. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#323722: maintainer seems MIA, we should orphan this package.
On Thu, 18 Aug 2005 12:57:18 +0200, Sven Luther <[EMAIL PROTECTED]> said: >> Well, in fact, there was a quite harsh discussion re: progsreiserfs, >> including upstream Hans Reiser himself. > Mmm, i was under the impression that there are two different things, > progreiserfs and reiserfsprog, one being from hans-reiser upstream, > and the other from some other guy. I believe that the one you package > and the one parted uses is not the one where hans reiser is involved > in. Yes, which is why Hans doesn't like progsreiserfs -- because it's buggy and he occasionally gets complaints about it, when it's not his (or Namesys') code. -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: Debian based GNU/Solaris: pilot program]
On Thu, 03 Nov 2005 12:57:17 -0800, Erast Benson <[EMAIL PROTECTED]> said: > I'm not talking about DFSG to embrace CDDL entirely. CDDL is good ... Please look up the meaning of acronyms if you intend on using them. I do not think it means what you think it means. DFSG = Debian Free Software Guidelines see http://www.debian.org/social_contract#guidelines All software in Debian _must_ be licensed under a DFSG-compatible license. The question was whether or not Nexenta wants to be an official Debian port. If, as David suggests, CDDL is not DFSG-compatible, this already precludes GNU/Solaris from becoming an official Debian port. This does not mean that Nexenta cannot work with Debian, or with Debian developers. (In fact, Debian generally wants Debian-derivatives to work with them.) But this means that GNU/Solaris cannot be an official Debian port. -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
On Thu, 03 Nov 2005 12:48:53 -0800, Erast Benson <[EMAIL PROTECTED]> said: > On Thu, 2005-11-03 at 12:18 -0800, Thomas Bushnell BSG wrote: >> The GPL does not force developers to "contribute their changes back". >> That's exactly the *point*. > Explain please. > Lets assume you have GPL-ed project dpkg. Any change to foo.c must be > contributed back to the community. ... Only if you distribute a binary based on the changed foo.c. And only if someone asks you for the sources. If you keep the binary to yourself, you don't have to release anything. > Also GPL-ed dpkg could be easily distributed as a binary if it is not > part of the system. The way KDE and other GPL-ed software distributed > in projects like www.blastwave.org, cygwin, etc. > CDDL works similar way, except on per-file basis. And as Matthew has repeatedly pointed out, this will not help with getting dpkg dual-licensed, since several dpkg copyright holders probably do not want that. -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
On Thu, 3 Nov 2005 23:16:43 -0500, Noah Meyerhans <[EMAIL PROTECTED]> said: [...] > session optional pam_tmpdir.so > I have little operational experience with this PAM module, though. > Does it cause problems for certain apps? If so, could these problems > be solved with a less simplistic PAM configuration? I've been using it for quite a while, and pretty much all applications work fine (although, as you mentioned, some applications hardcode /tmp). The only problems, I think, that I have come across are when two programs try to communicate over a named pipe, or shared file, and one of them hardcodes /tmp, and the other uses $TMP. I don't remember which programs did that, but I remember it happened at least once. Another potential problem is if a run a suid (non-root) program that attempts to create a file in $TMP. But it's suid, so it doesn't run under my uid, and doesn't have permissions to write to $TMP. But I've never run across that -- suid programs are pretty uncommon. -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: per-user temp directories by default?
On Fri, 4 Nov 2005 01:42:08 -0500, Joey Hess <[EMAIL PROTECTED]> said: > One problem I have experienced is that if I manually start cups via > its init script, as root, the cups daemon ends up running as a less > privliged user that cannot write to /root/tmp, and the failure mode is > quite horrible (silent failure to print anything). This could possibly be fixed by having programs fall back on a hardcoded /tmp if $TMP is not writable. And/or by having init scripts clean up their environment. And of course I would consider silent failure to be a bug in CUPS. -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request: Source for parts of GNU/Solaris
On Fri, 11 Nov 2005 12:10:06 -0600, Bill Gatliff <[EMAIL PROTECTED]> said: [...] > No, the owner hasn't been deprived. But the rights said owner > conveyed via the GPL (which amount to some level of ownership, at > least philosophically) have been deprived from the GNU/Solaris end > users. It's the GNU/Solaris end users who have been stolen from. > I'll give up now. Is that dead horse I smell? :) I don't know, but maybe we should keep beating it until the smell goes away. :) -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reiser on /, fsck and ro: bug?
Why is this in d-devel?
>>>>> "A" == A Mennucc <[EMAIL PROTECTED]> writes:
A> hello I have set up a box that uses reiserfs as the root filesystem
A> I have noticed 3 facts that seem to be bugs (but I could not tell for
A> sure)
A> 1- I use a stock kernel by Herbert XU, which uses initrd; when
A> initrd's /sbin/init is run, eventually it mounts the root from the
A> hard disk, and it always mounts it read-only, without checking if the
A> kernel option 'ro' was given: is this a bug? what package's bug?
I believe it's supposed to mount it as ro, and later remount as rw.
A> 2- Then /sbin/init is executed from the hard disk, and this calls all
A> /etc/rcS.d/* that do an fsck on /
A> When this happens, though, fsck.reiserfs says: "filesystem is mounted
A> read-only: skipping journal replay": so it seems that the journal
A> will never be replyed, even if the filesystem is dirty (I am not sure
A> that this is the case, but I am not willing of doing extensive
A> testing on this issue). This is the opposite of what fsck.ext3 would
A> do: AFAIK it does a journal replay and a fsck ONLY IF the root is
A> mounted read-only.
AFAIK, the journal gets replayed automatically when the fs gets mounted.
A> 3- Then, fsck.reiserfs does a fsck of the disk. Regardless of it
A> being dirty or not (that is, ignoring the absence of the '-f'
A> flag). This is another difference with fsck.ext{2,3}. This is a minor
A> bug, but annoying (it wastes time).
fsck shouldn't be automatically run for ReiserFS partitions. In
/etc/fstab, make sure that the lines for your reiserfs partitions have
'0' as the last number, rather than a '1'.
--
Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
pgpSiuKropUTH.pgp
Description: PGP signature
Re: reiser on /, fsck and ro: bug?
>>>>> "Martin" == Martin Pitt <[EMAIL PROTECTED]> writes: [...] Martin> I also thought about that because it also annoys be. But then Martin> again, I _do_ want the partitions checked every now and then Martin> (e. g. every 25 mounts). Wouldn't this disable fsck completely? Martin> Or is the ckeck triggered on a different place? I believe that would require a modified reiserfsck (or fsck.reiserfs). Hmm. I just looked at the reiserfsck man page. It seems that it now supports the "-a" and "-p" options, and just "[prints] some information about the specified file system, [checks] if error flags in the superblock are set and [does] some light-weight checks." So it may be "safe" now to have it set to run fsck on bootup. This is from reiserfsprogs with Debian version 1:3.6.11-1 (from unstable). I'll try it out the next time I reboot (which won't be for a while). -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgpmkXhN6eW15.pgp Description: PGP signature
