Bug#284978: general: libgmp segfaults on generating 48402688-bit random number
Hi, * Thomas Womack [Thu, Dec 09, 2004 at 10:18:29PM +]: > The program [...] > segfaults in the mpz_urandomb() function > with a back-trace > #0 0x4003d051 in __gmpn_copyi () from /usr/lib/libgmp.so.3 > #1 0x40023012 in __gmp_randinit_lc_2exp () from /usr/lib/libgmp.so.3 > #2 0x4002310d in __gmp_rand () from /usr/lib/libgmp.so.3 > #3 0x400331f8 in __gmpz_urandomb () from /usr/lib/libgmp.so.3 > #4 0x0804861b in main (argc=1, argv=0xbca4) at use-gcds-BUG.c:14 Adding mpz_init for A, B and C helps. signature.asc Description: Digital signature
Re: ITP: g-wrap -- Scripting interface generator for C
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Andreas Rottmann <[EMAIL PROTECTED]> writes:
>
>> A note to Thomas: You can already try building GnuCash 1.8.9 (1.8.10
>> will have the patch applied, as it is already in CVS, both in HEAD and
>> the 1.8 branch) when you apply the attached patch.
>
> Just so you know, it's really my intention not to have *any* pre-Sarge
> changes.
>
Fine. I'll probably try building GnuCash 1.8.9 with G-Wrap 1.9.3
anyway, as maybe NetBSD pkgsrc switches to this setup and I want to
make sure it works. I'll file a wishlist bug ("build against G-Wrap
1.9.x") on GnuCash with the according patches once G-Wrap 1.9.x is in
Debian and I've made it work with GnuCash.
Cheers, Rotty
--
Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL
PROTECTED]
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Life is a sexually transmitted disease.
Re: Bug#284642: ITP: dpkg-reversion -- change the version of a DEB file
also sprach Adam Heath <[EMAIL PROTECTED]> [2004.12.09.2053 +0100]: > Probably yes on dpkg-repack. Definately not for dpkg-www. Which > is a sucky name, btw. Agreed. However, if dpkg-repack goes into dpkg, why not provide a means to edit a DEB file (without having to install it) too? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Linux Core Consortium
On Friday 10 December 2004 06.15, Gunnar Wolf wrote: > John Goerzen dijo [Thu, Dec 09, 2004 at 09:40:51PM -0600]: > > we could participate in this organization even if we didn't take > > their packages? That is, perhaps we could influence the direction to > > a more useful one? > Then we would be non-participants, we would be just bitchers No, I don't think so. I think what Bruce and Ian are aiming at is - Debian can get influence in LCC, so - some things LCC does might actually make sense, so Debian does these things in the way LCC does. - other things will be done in LCC-space, that will not make sense in Debian, so Debian can still do it in its own way. What is the benefit? The divergence between LCC and Debian will still be smaller than when Debian just stays outside. So - vendors may offer compatibility to LCC with manageable overhead (Ubuntu, perhaps?) - porting LCC applications to Debian is limited to those small areas where divergence between LCC and Debian diverge. I think about things like hardware detection and autoconfiguration, where there's a lot development right now, and there are a lot of different solutions. In many cases, the various solutions are more or less equivalent and things are done differently mainly because of personal taste of whoever does the implementation. Having a voice in how LCC does these things and doing it the same way in Debian, in these cases, would be a Very Good Idea(tm), I feel. -- vbi -- featured link: http://fortytwo.ch/gpg/intro pgpT84fNXbZ2P.pgp Description: PGP signature
Bug#285041: ITP: fprobe-ng -- Export captured traffic to remote NetFlow Collector
Package: wnpp Severity: wishlist * Package name: fprobe-ng Version : 1.0.6 Upstream Author : Slava Astashonok <[EMAIL PROTECTED]> * URL : fprobe.sourceforge.ne * License : GPL Description : Export captured traffic to remote NetFlow Collector A well-maintained alternative to fprobe. This program is a libpcap-based utility which collects network traffic and emits it as NetFlow towards a specified collector. . Homepage: fprobe.sourceforge.net This is the same as the sfprobe ITP only i changed the name on the suggestion of my sponsor. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
[EMAIL PROTECTED] (Debian Bug Tracking System) wrote: > Processing commands for [EMAIL PROTECTED]: > >> tag 284800 + fixed > Bug#284800: tetex-base: Can't be removed: rmdir: > `/usr/share/texmf/fonts/type1/pxr/': No such file or directory > There were no tags set. > Tags added: fixed Was this really necessary? You are NMU'ing a bug that is 2 days old, my last message to that bug was yesterday afternoon, saying: , | The cause is clear, the fix is easy. ` Since then, I was testing the packages with the fixes that we had prepared in the last days. You have not posted anything to this bug, neither a patch nor an intent to NMU. And you won't stop me from uploading these packages this morning. I find this extremely annoying. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: dselect survey
Bernd Eckenfels <[EMAIL PROTECTED]> wrote: >> Er, these are shortcuts. *shrug* > > Uh, so there is a non-shortcut method of operating? I awaited this comment, but didn't know which other word to use. No, I don't claim there is a non-shortcut method. I would say that dselects' control interface consists of only shortcuts (or whatever you want to call that) *by design*. I understand that this may be unpleasant to some people, but I think that for a very often-used program such as dselect (if this is your dpkg front-end of choice, of course), this is not a problem: you don't need 10 months to learn 10 shortcuts in a software that you use every week or so. And you are very efficient with these shortcuts. > And which is left with enter, just like you need to do to install (unless > you really want to ignore the conflict, which means you have to use "Q" to > install, then :) FWIW, was used to exit help in woody's dselect version. I cannot say I prefer the new behavior[1], but I don't see a major problem with the two uses of you are mentioning: in dselect has always[2] meant (in the context of an action) "do the work that has been marked so far" (usually: install according to the selections I have under the eyes). Consequently, whenever you hit , you are supposed to have convinced yourself that you want to do what has been marked so far, which is generally right under your eyes (list of packages to install or remove in a dependency/conflict dialog resolution, for instance). So, in the case of exiting help, you are just somehow led to pay a bit too much attention to a pretty harmless action, that is, exiting the on-line help. I admit this may not be perfect, but I don't see it as a big problem (how often do you need on-line help when you use dselect every week or so?). I think if we could exit help with , that would be perfect, but perhaps tty technicalities would require you to hit it twice as in mc (I don't know much about this problem), which would be a slightly ugly. [1] I still use both versions and happen to often hit instead of when I use sid's one, which doesn't have any bad consequences (simply scrolls help). And the problem will disappear automatically when I don't have to use woody's dselect anymore. [2] Well, since slink at least. -- Florent
Bug#285052: ITP: paje.app -- generic visualization tool (Gantt chart and more)
Package: wnpp Severity: wishlist * Package name: paje.app Version : 1.0.0cvs20041022 Upstream Author : Benhur Stein * URL (old) : http://www-id.imag.fr/Logiciels/paje/pajedist.html * URL (new) : http://forge.objectweb.org/projects/paje/ * License (old) : GPL * License (new) : LGPL Description : generic visualization tool (Gantt chart and more) Paje is a graphical tool that displays traces produced during the execution of multithreaded programs. Other programs can also generate traces for this tool. Key Features * Supports multi threaded programs o each thread of the analysed program can be individually displayed, or multiple threads can be combined, to reduce screen space usage. * Interactivity o each entity represented on the screen can be interrogated for more information, o related entities are highlighted as mouse cursor passes over some representation Rem: Paje has just been accepted in the ObjectWeb consortium. The project web page is created on their server, but not yet populated (hence the old url where current software is present and the new where new releases will be available) The adoption in the ObjectWeb consortium is also the reason why the author is currently switching from the GPL to the LGPL (the consortium prefers this licence and the author is ok). -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7-act Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Re: dselect survey
Miles Bader <[EMAIL PROTECTED]> wrote: > Completely and utterly wrong in my case. I'm exactly the sort of person > that you apparently think should like dselect, but I think aptitude is > _far_ superior, for both experts and newbies. The competition isn't even > close. Did I mention aptitude in my post? No. I'm just trying to understand people who bash dselect on the first occasion. If you don't like dselect and don't fall in one of the cases I have mentioned, then we have a problem. Simply preferring aptitude is *not* a valid reason to say dselect is ugly, difficult to use, . PS: maybe I forgot: (f) bash dselect 'cause someone else said it was crap (rest assured, this one is not intended to fit your particular case; I'm just trying to build as complete a list as possible) -- Florent
Removal of freeswan from sarge
Hi all, [Please CC me in replies, I am currently not subscribed to -devel. This is also cross-posted to debian-user because it might affect users that are not subscribed to -devel.] I have thought for quite some time about this issue and have now come to a decision. Sorry that it's rather late in the release process, but I really think it'll be better this way. If nobody wants to argue in favor of it, I hereby request freeswan to be removed from the archive (unstable and testing). (Please read further before actually doing it or starting to flame. Thanks.) Reasoning: freeswan is dead. It's upstream development has been discontinued, it has a lot of open bugs in the Debian BTS that I sometimes can't and for others won't fix. Besides all of that, the freeswan package has always been a bloody mess, with sometimes >10 (usually conflicting) patches needing to be applied to get all the features necessary for today's IPSec demands. Yes, package updates to new upstream version have not (only) taken that long because I am lazy. But don't despair, a new contender is here for rescue: openswan. It is a fork of the freeswan codebase, but already integrates most of the third-party patches I have been applying to the Debian package over the last years. It is therefore more feature-complete than native freeswan ever was. Since quite some time, I am also packaging openswan, and for nearly that long it is also in the Debian archive (unstable and testing). I am a lot more happy with my contacts to openswan upstream than I have been to my contacts to freeswan upstream (although some of them simply moved from freeswan to openswan). I can't give some facts here, but the openswan team is extremely responsive to any requests, which I like very much. In fact, most of the time the upstream package will include the latest Debian packaging, so the .diff.gz is generally _very_ small. One of the best points for openswan, from a user point of view, is that it is config-file compatible. I.e. if you remove (not purge) freeswan, install openswan, and - if you use the KLIPS kernel part instead of the native Linux IPSec kernel stack - recompile the kernel (or the modules) with openswan instead of freeswan, no other changes should be necessary. The same ipsec.conf, ipsec.secrets and X.509 certificates can be used. To make a long story short: If you have any compelling reason to continue using freeswan, i.e. if for some reason you can not use openswan, then please let me know now. And no, not wanting to compile a new kernel because of the switch is not a compelling reason. If you can't recompile your kernel, you either a) shouldn't have compiled it in the first place or b) should not be running unstable or testing. Remember that nothing will change for stable. I am probably being presumptuous with regard to current freeswan users here, but I am looking for the best solution for users of the to-be-stable release, and freeswan is not good for that. Better a clear cut now. If there are no objections within 2 weeks from now, I will ask the ftp maintainers and release managers to remove freeswan from unstable and testing. I am still thinking about doing an "upgrade" package of freeswan though, which depends on openswan and simply moves the configuration of the old freeswan configuration to openswan. Any preferences towards such a package? with best regards, Rene pgpZkmyRXYDgx.pgp Description: PGP signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thursday 09 December 2004 14:06, Ron Johnson <[EMAIL PROTECTED]> wrote: > You're coming very late to the "conversation". A District > Attorney angling for higher office or someone in the Morality > Police (think Saudi Arabia) or a petty member of the CCP might not > care about "there will be conflicts like this". Let's forget about Saudi law. Saudi law is something for people who live there to worry about not for those of us who live in the free world. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: LCC and blobs
Don Armstrong <[EMAIL PROTECTED]> writes:
> On Fri, 10 Dec 2004, Goswin von Brederlow wrote:
>> As for distributing the blobs itself they can be relicensed under
>> BSD license or similar (if their aren't already) that doesn't have
>> such a problem with a char data[] = { 0x17, ... } source file,
>> something without the prefered source form clause. Even putting some
>> in non-free works fine.
>
> They'd pretty much have to go into non-free, as I'd imagine most of
> them wouldn't be able to satisfy DFSG 2 if they were unable to satisfy
> the GPL's source code requirement.
>
>
> Don Armstrong
GPL's source code requirement says something about prefered form of
modification. The char data[] = { ... } is not the prefered form for
most people or not even source for others.
The DFSG is less strict there.
MfG
Goswin
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
Frank Küster <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Debian Bug Tracking System) wrote: > >> Processing commands for [EMAIL PROTECTED]: >> >>> tag 284800 + fixed >> Bug#284800: tetex-base: Can't be removed: rmdir: >> `/usr/share/texmf/fonts/type1/pxr/': No such file or directory >> There were no tags set. >> Tags added: fixed > > Was this really necessary? You are NMU'ing a bug that is 2 days old, my > last message to that bug was yesterday afternoon, saying: > > , > | The cause is clear, the fix is easy. > ` > > Since then, I was testing the packages with the fixes that we had > prepared in the last days. You have not posted anything to this bug, > neither a patch nor an intent to NMU. And you won't stop me from > uploading these packages this morning. > > I find this extremely annoying. > > Regards, Frank > -- > Frank Küster > Inst. f. Biochemie der Univ. Zürich > Debian Developer I find >200 failed package builds on the buildd extremly annoying. I'm sorry the NMU annoyed you but I welcome it. There is nothing worse than a package that kills buildds, esspecially such a common one. MfG Goswin
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote:
> Let me first say unequivocally that the LCC is very interested in
> getting Debian involved. The question has always been: How do we do
> that?
I think there is one obvious answer to this question: 'Learn from
history'.
1. Unix and UnitedLinux failed. LSB party succeeded but has no practical
importance.
2. GNOME succeeded for the desktop.
The reason why the above failed have already been outlined in this
thread and one quote from Bruce sums it up pretty well: 'The members
considered that they had proprietary value at the level at which they
were collaborating'.
The reason why GNOME succeeded is because it builds a solid, predictable
and free base for vendors and distributions to build on. Every major
distribution which is interested (mostly RedHat, Novell and Sun) has
people working on GNOME and collaborating with each other.
The other reason why GNOME succeeded is because it spectaculary managed
to reinvent itself to make it feasable for others to build upon it.
Before those mentioned above used GNOME as their base, it was pretty
much similar to what Debian is today: No proper release schedules,
delays and not much of a broad and far-reaching vision.
So I think the obvious conclusion to the above answer ('learn from
history') is:
*** The interested parties of the LCC should pick Debian as a base and
Debian should make this possible. ***
Rather than everybody just throwing all their stuff in together and
mixing it up.
Of course, this would also mean for Debian to change. Debian is free
and solid today, but not predictable. Thus:
* We should commit to strict release cylces of a base system others
(and Debian itself) can build value upon.
* We should proabably also commit to a set of core architectures which
*need* to be bug-free on release, while the rest *should* be, but
would not delay the release.
* We should look into having a reality-check with respect to licensing
and the way we treat each other.
On the other hand, this would also mean: The other partners should get
involved into Debian development, both by getting their toolchain/base
developers into the Debian project and possibly accepting Debian
developers into their ranks.
All this could not be done easily, but it is the only viable solution
for a solid, free and predictable base system. There is no alternative
to it.
thanks,
Michael
Re: Removal of freeswan from sarge
Rene Mayrhofer <[EMAIL PROTECTED]> wrote: > I am still thinking about doing an "upgrade" package of freeswan though, > which > depends on openswan and simply moves the configuration of the old freeswan > configuration to openswan. Any preferences towards such a package? I don't see any reasons for _not_ providing a smooth upgrade path. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Linux Core Consortium
On Thu, 2004-12-09 at 21:40 -0600, John Goerzen wrote: > On Thu, Dec 09, 2004 at 07:08:48PM -0800, Russ Allbery wrote: > > Bruce Perens <[EMAIL PROTECTED]> writes: > > > > I think that tying core Debian packages to the Red Hat boat anchor is a > > horrible, horrible idea. > > I tend to agree with sentiments like this, but didn't Bruce mention > that we could participate in this organization even if we didn't take > their packages? That is, perhaps we could influence the direction to > a more useful one? > > If that is the case, it seems zero risk to me. Yes, this is the bottom line: it does not negatively impact Debian for (for example) the DPL to go talk/email/IRC with the LCC representatives. If Debian's concerns can't be satisfactorily resolved, then Debian says "thanks, but no thanks", and continues down it's current path. It's *that* simple. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. Vegetarian - an old Indian word meaning 'lousy hunter'. signature.asc Description: This is a digitally signed message part
Re: LCC and blobs
On Dec 09, Bruce Perens <[EMAIL PROTECTED]> wrote: > The whole system has to be DFSG-free. Debian won't compromise on that. Which DFSG? The original one or the "clarified" one? > I have been thinking about the blob problem for a while. I propose to > remove blobs from the driver, and store them as files in initramfs (the > kernel-internal filesystem created by the stuff in /usr/src/linux*/usr) > or initrd.img. At boot time, the drivers would look for the blobs and You may want to take a look at debian-legal, because some people there think that even free drivers for hardware devices which need an externally loaded firmware are not acceptable for main. > load them if they are present, and fail gracefully or fall back if they > are not. This gets around some GPL issues, because rather than be There are no GPL issues for other distributions, nor for almost every kernel developers and I understand neither for the FSF. So you'd first have to persuade everybody else that the kernel is violating the GPL. > An alternative is to make blobs their own loadable modules, but then we > are treating them as code rather than as just a file that the kernel > sends to some device, and we get GPL issues. Encapsulating some data in an ELF object does not magically make it code. -- ciao, | Marco | [9686 esDusDIxsUiYM] signature.asc Description: Digital signature
Re: Linux Core Consortium
On Dec 09, Ian Murdock <[EMAIL PROTECTED]> wrote: > > > Let me first say unequivocally that the LCC is very interested in > > > getting Debian involved. The question has always been: How do we do > > > that? > > As usual: by sending patches. > So, the flow can only be unidirectional? No, interested developers can subscribe to the mailing list or whatever they need to do to partecipate. It's not that I don't like the idea of cooperation in defining things like sonames or some programs having an upstream maintainer instead of being independently patched to death by each distribution (especially for mature or orphaned packages like ppp, tcp-wrappers, netkit, etc...), but I'm can't see any benefit in blindly commiting to some standard, as it may mean lowering the quality of Debian. > > And which I doubt we will get with LCC, since the kernel is the most > > important piece which needs to be certificated. > The common core will include a common kernel. See the FAQ at Christoph Hellwig already explained the obvious problem with this. -- ciao, | Marco | [9687 apucCy4LNj8KQ] signature.asc Description: Digital signature
Re: Linux Core Consortium
On Thu, 2004-12-09 at 23:15 -0600, Gunnar Wolf wrote: > John Goerzen dijo [Thu, Dec 09, 2004 at 09:40:51PM -0600]: > > > I think that tying core Debian packages to the Red Hat boat anchor is a > > > horrible, horrible idea. > > > > I tend to agree with sentiments like this, but didn't Bruce mention > > that we could participate in this organization even if we didn't take > > their packages? That is, perhaps we could influence the direction to > > a more useful one? > > > > If that is the case, it seems zero risk to me. > > Then we would be non-participants, we would be just bitchers, telling > everybody how fucked-up their process and QA are. We would gain > nothing, and we would lose as everybody would say that Debian refuses > to play together with the guys after giving an initial 'yes'. And no, > no ISV would certify Debian just because Debian sits and bitches. There are diplomatic ways to say, "your processes and QA are all fucked up". We'll just have to send someone who knows how to do that. :) -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "If you don't know how to do something, you don't know how to do it with a computer." Anonymous signature.asc Description: This is a digitally signed message part
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Fri, 2004-12-10 at 22:48 +1100, Russell Coker wrote: > On Thursday 09 December 2004 14:06, Ron Johnson <[EMAIL PROTECTED]> wrote: > > You're coming very late to the "conversation". A District > > Attorney angling for higher office or someone in the Morality > > Police (think Saudi Arabia) or a petty member of the CCP might not > > care about "there will be conflicts like this". > > Let's forget about Saudi law. Saudi law is something for people who live > there to worry about not for those of us who live in the free world. It is. if we want people in Arabia to be able to possess Debian disks. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "Pacifism can act more effectively against democracy than for it." George Orwell, 1941 signature.asc Description: This is a digitally signed message part
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
On Fri, Dec 10, 2004 at 11:43:22AM +0100, Frank Küster wrote: > Since then, I was testing the packages with the fixes that we had > prepared in the last days. You have not posted anything to this bug, > neither a patch nor an intent to NMU. And you won't stop me from > uploading these packages this morning. Which certainly wasn't his intention. > I find this extremely annoying. Please calm down. Sure, it isn't usual to upload such a quick NMU, but (as Goswin already pointed out) such a bug that makes a package uninstallable that is a common build-depends can really hurt the autobuilders. You're free to discuss with lamont how to handle such cases in the future (and communicating him your anger) but please don't overreact. Positive thinking ;) Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Frank Küster <[EMAIL PROTECTED]> writes: > >> You have not posted anything to this bug, >> neither a patch nor an intent to NMU. And you won't stop me from >> uploading these packages this morning. >> >> I find this extremely annoying. >> [...] > I find >200 failed package builds on the buildd extremly annoying. I must admit that I didn't know that failed *removals* of build-dependencies would cause the buildd to fail. Nobody cared to indicate that to us. > I'm sorry the NMU annoyed you but I welcome it. There is nothing worse > than a package that kills buildds, esspecially such a common one. I agree. But still LaMont should have expressed his intent to do so, and send the patch to the BTS. I don't have a problem with being NMUed, but with NMUs prepared improperly. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
Hi Frank, > Please calm down. Sure, it isn't usual to upload such a quick NMU, but > (as Goswin already pointed out) such a bug that makes a package > uninstallable that is a common build-depends can really hurt the > autobuilders. You're free to discuss with lamont how to handle such > cases in the future (and communicating him your anger) but please > don't overreact. > Whats about uploading such packages to experimental more often. As i am being told on IRC, experimental is autobuilded on most architectures now. Greetings Martin -- Bachelor: A man who chases women and never Mrs. one.
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
Op vr, 10-12-2004 te 13:49 +0100, schreef Frank KÃster: > I must admit that I didn't know that failed *removals* of > build-dependencies would cause the buildd to fail. Nobody cared to > indicate that to us. It can happen. It doesn't happen always, but sometimes it does. In extreme cases, a buildd host can become so FUBARed that no package will build anymore (because *every* dpkg run will fail). -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
Frank Küster <[EMAIL PROTECTED]> writes: > Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > >> Frank Küster <[EMAIL PROTECTED]> writes: >> >>> You have not posted anything to this bug, >>> neither a patch nor an intent to NMU. And you won't stop me from >>> uploading these packages this morning. >>> >>> I find this extremely annoying. >>> > [...] >> I find >200 failed package builds on the buildd extremly annoying. > > I must admit that I didn't know that failed *removals* of > build-dependencies would cause the buildd to fail. Nobody cared to > indicate that to us. The failure did corrupt the apt/dpkg status resulting in apt-get always suggesting "run apt-get -f install" to corret the problem. Due to that no new Build-Depends can be installed and every build just fails. Sometimes a failure to remove something can be ignored, sometimes it breaks apt. This one was of the later kind. MfG Goswin
Re: Linux Core Consortium
On Thu, 2004-12-09 at 21:35 -0800, Philip Miller wrote: > Greg Folkert wrote: > > Many reasons people come to Debian... Distributed Binaries is not one of > > them. > > If you think this isn't a reason to use Debian, I, as a long-time user, will > tell you that > you're dead wrong. I use Debian because there exist packages for most every > popular piece > of free software out there, and I will never have to use an untrusted binary > package to > install it conveniently. Even when it comes to installing software that's not > in the > Archive, I can safely install it from source, with the assurance that none of > its files > will be mixed in with any files installed by the package management system > (not the case > with most 3rd-party RPMS). Should umm, clarify, Distributed Binaries == Binaries Built and shoved into Debian by an External Entity or 3rd Party. I rarely, RARELY compile a package with dpkg-buildpackage. When I do, it is for a local modification to workaround a hardware, security or performance issue before it is patched or fixed in Debian. Typically the only 3rd Party Binaries I use are Games or Business Critical (non-free/commercial) applications as deemed by the PHBs that be. > I am doing some sysadmin work involving RedHat Enterprise Linux 3 systems, > and I will tell > you that they do a terrible job of maintaining a binary distribution. > Standing by > themself, let alone compared to Debian, they do no integration testing of the > packages > they release and distribute. For example, this past summer, after a new > server > installation, we had to build and install a local copy of Perl, because the > version they > distributed was completely incompatible with both mailscanner and amavisd-new > due to > module bugs. This sort of brown-paper-bag error in a release is unthinkable > in Debian, > precisely because of the QA that our exact distributed binaries go through > (and this > particular issue was actually caught in testing, as it should have been). I have done and continue to manage RedHat AS/ES installations. I do these primarily via ssh, one is on another continent, most are in the US, though states away though). I can tell you first hand the terrible fixes I have had to force onto some of those systems that just wouldn't work with Oracle or Tuxedo or Websphere or mainly becuase of this lack of QA from RedHat. Regression testing, or integration testing as you call it, is by far the best reason to come to Debian. When I think of Debian and Binary... those are Binaries Built by Buildd-s in the Debian Submission and Acceptance process. Not on lumpy.redhat.com or some other external host that I have zero real knowledge of. And for your Perl Issue, you could have just CPAN updated those Perl Modules. I have had to do that many times. There are certain things I like about RedHat... one is the rpmbuild setup. If one could employ policies in an RPM build that are applied to DEB builds... I'd think that 99.9% of the issues we speak about in RedHat would be solved. So, I guess you misread what I meant. Or I wasn't as clear as I should have been. Either way, you should now understand my position a bit better. -- greg, [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry Onerous congratulations on your conceptual development of obliteration concerning telephones, lobsters and fish! signature.asc Description: This is a digitally signed message part
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
On Fri, Dec 10, 2004 at 01:49:33PM +0100, Frank Küster wrote: > > I'm sorry the NMU annoyed you but I welcome it. There is nothing worse > > than a package that kills buildds, esspecially such a common one. > > I agree. But still LaMont should have expressed his intent to do so, and > send the patch to the BTS. I don't have a problem with being NMUed, but > with NMUs prepared improperly. At this point, any RC bug in an important (as in for the release, not priority-wise) package is an implicit express to be NMUd, at any time. Deal with it, we want to release. One could argue about sending the NMU-patch/interdiff to the BTS, but I personally do not see much point in it, since (hi Omnic!) you can just get it from the archive and sync it yourself. It still makes sense for packages where you suspect the maintainer to be inactive/not willing to deal with this or (as is the case here apparently) already working on a new revision. In any case, NMUs are never meant as personal attacks or gratuitous. Especially when they are done by buildd maintainers you can be certain there was some need for it. I envision a time where there are no more NMUs, just uploads by people who care. cheers, Michael
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
Martin Zobel-Helas <[EMAIL PROTECTED]> schrieb: > Hi Frank, > >> Please calm down. Sure, it isn't usual to upload such a quick NMU, but >> (as Goswin already pointed out) such a bug that makes a package >> uninstallable that is a common build-depends can really hurt the >> autobuilders. You're free to discuss with lamont how to handle such >> cases in the future (and communicating him your anger) but please >> don't overreact. >> > > Whats about uploading such packages to experimental more often. As i am > being told on IRC, experimental is autobuilded on most architectures > now. What do you mean? Do you think the buggy package should have been uploaded to experimental? Believe me, we didn't plan the bug. Uploading the NMU to experimental wouldn't have helped anybody, either: The buildd's would still have been broken, and the NMU would still have been unannounced and without a patch in the BTS (the patch was received by the first mailhost 6 hours after the date in the changelog...) Grüße, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Linux Core Consortium
On Fri, 2004-12-10 at 12:50 +0100, Michael Banck wrote:
> On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote:
> > Let me first say unequivocally that the LCC is very interested in
> > getting Debian involved. The question has always been: How do we do
> > that?
>
> I think there is one obvious answer to this question: 'Learn from
> history'.
>
> 1. Unix and UnitedLinux failed. LSB party succeeded but has no practical
> importance.
>
> 2. GNOME succeeded for the desktop.
>
> The reason why the above failed have already been outlined in this
> thread and one quote from Bruce sums it up pretty well: 'The members
> considered that they had proprietary value at the level at which they
> were collaborating.
>
> The reason why GNOME succeeded is because it builds a solid, predictable
> and free base for vendors and distributions to build on. Every major
> distribution which is interested (mostly RedHat, Novell and Sun) has
> people working on GNOME and collaborating with each other.
>
> The other reason why GNOME succeeded is because it spectacularly managed
> to reinvent itself to make it feasible for others to build upon it.
> Before those mentioned above used GNOME as their base, it was pretty
> much similar to what Debian is today: No proper release schedules,
> delays and not much of a broad and far-reaching vision.
>
> So I think the obvious conclusion to the above answer ('learn from history')
> is:
>
>
> *** The interested parties of the LCC should pick Debian as a base and
> Debian should make this possible. ***
W, that would be tough. But I like it. At least for Core.
> Rather than everybody just throwing all their stuff in together and
> mixing it up.
>
> Of course, this would also mean for Debian to change. Debian is free
> and solid today, but not predictable. Thus:
>
> * We should commit to strict release cycles of a base system others
>(and Debian itself) can build value upon.
So we would detach "Core" from everything else, perhaps we should also
then also define kernels with specific patches to accommodate certain
situations or applications. IOW have flavours of kernels be something
like:
kernel-image-
kernel-image-
kernel-image-
kernel-image-
kernel-image-
kernel-image-
kernel-image-
kernel-image
With those Distributions needing keeping the base-patchset up-to-date
and while the buildd machines compile for the architectures, While we as
Debian just continue on managing these patchsets to work on all arches.
This would require those other Distros to become more policy driven. How
would we split this out? Would we then have "Core Only DDs"? Would we
still have the ability to get security fixes out the door in time?
Should we do revision releases like say we do for Woody right now:
3.0r1/2/... would this work? Doing incremental security/major bug-fix
releases similar to the way Microsoft does it? (No not really, but the
idea is similar) Should we then have a "Core Only"
Stable/Testing/Sid/Experimental?
> * We should probably also commit to a set of core architectures which
>*need* to be bug-free on release, while the rest *should* be, but
>would not delay the release.
I disagree here, when WOULD they get worked on then? Release pending is
a good motivator. But as we see now, it is not *THE HOLY GRAIL* of
Motivators. Some of the *OLDER* not able to keep up as of now anyway
buildd machine arches might be candidates, but Dang what a way to slam
the door on them. (like 32bit Sparc, M68K, others)
> * We should look into having a reality-check with respect to licensing
>and the way we treat each other.
Now this... needs to happen anyway.
> On the other hand, this would also mean: The other partners should get
> involved into Debian development, both by getting their toolchain/base
> developers into the Debian project and possibly accepting Debian
> developers into their ranks.
Again, this should happen period.
> All this could not be done easily, but it is the only viable solution
> for a solid, free and predictable base system. There is no alternative
> to it.
Unfortunately, this I agree with you. It will make it the toughest thing
on the planet. A sub-structure of Buildd will need to make both DEB
packages as well as RPM, lest we not forget, TGZ/other packages mgmt
systems.
This is a big job, which I believe nobody will succeed on. Which is tooo
bad.
--
greg, [EMAIL PROTECTED]
The technology that is
Stronger, better, faster: Linux
signature.asc
Description: This is a digitally signed message part
Re: Linux Core Consortium
On Fri, 2004-12-10 at 06:31 -0600, Ron Johnson wrote: > On Thu, 2004-12-09 at 23:15 -0600, Gunnar Wolf wrote: > > John Goerzen dijo [Thu, Dec 09, 2004 at 09:40:51PM -0600]: > > > > I think that tying core Debian packages to the Red Hat boat anchor is a > > > > horrible, horrible idea. > > > > > > I tend to agree with sentiments like this, but didn't Bruce mention > > > that we could participate in this organization even if we didn't take > > > their packages? That is, perhaps we could influence the direction to > > > a more useful one? > > > > > > If that is the case, it seems zero risk to me. > > > > Then we would be non-participants, we would be just bitchers, telling > > everybody how fucked-up their process and QA are. We would gain > > nothing, and we would lose as everybody would say that Debian refuses > > to play together with the guys after giving an initial 'yes'. And no, > > no ISV would certify Debian just because Debian sits and bitches. > > There are diplomatic ways to say, "your processes and QA are all > fucked up". > > We'll just have to send someone who knows how to do that. :) And just who the he(double-toothpick) would you suggest? Scott James Remnant? >:^) -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: Linux Core Consortium
Op vr, 10-12-2004 te 12:50 +0100, schreef Michael Banck: > *** The interested parties of the LCC should pick Debian as a base and > Debian should make this possible. *** > > Rather than everybody just throwing all their stuff in together and > mixing it up. > > Of course, this would also mean for Debian to change. Debian is free > and solid today, but not predictable. Thus: > > * We should commit to strict release cylces of a base system others >(and Debian itself) can build value upon. IOW, split off the release of the base system, and make it some entity that stands by itself. Hmm, isn't that what LCC suggests we do? > * We should proabably also commit to a set of core architectures which >*need* to be bug-free on release, while the rest *should* be, but >would not delay the release. This isn't necessary, unless you can show me one release which was delayed because a certain architecture wasn't in shape. > * We should look into having a reality-check with respect to licensing >and the way we treat each other. You'll have to explain this one to me. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
Michael Banck <[EMAIL PROTECTED]> wrote: > One could argue about sending the NMU-patch/interdiff to the BTS, but I > personally do not see much point in it, since (hi Omnic!) you can just > get it from the archive and sync it yourself. It still makes sense for > packages where you suspect the maintainer to be inactive/not willing to > deal with this or (as is the case here apparently) already working on a > new revision. > > In any case, NMUs are never meant as personal attacks or gratuitous. > Especially when they are done by buildd maintainers you can be certain > there was some need for it. As stated before, I see now that the NMU was okay. However, I was really annoyed this morning to find in my mailbox the mail indicating the bug was Fixed, but found no notice of this in the bug, or anywhere but the changelog. If anybody had cared to inform me about the problems the bug had caused, I would probably have delayed the testing of the other changes in our CVS, and prepared an upload myself. The fixed package could have hit unstable _earlier_ than the NMU did. Or I could simply have stayed at the university an hour longer yesterday evening, and make the upload of 2.0.2c-3 nearly at the same time as LaMonts NMU. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Linux Core Consortium
On Fri, Dec 10, 2004 at 12:50:13PM +0100, Michael Banck wrote: > *** The interested parties of the LCC should pick Debian as a base and > Debian should make this possible. *** > Rather than everybody just throwing all their stuff in together and > mixing it up. > Of course, this would also mean for Debian to change. Debian is free > and solid today, but not predictable. Thus: > * We should commit to strict release cylces of a base system others >(and Debian itself) can build value upon. This seems to be the same definition of "commit" as in "Novell is committed both to providing customers with standardized Linux technology and to simplifying ISVs' and IHVs' Linux certification efforts."[1] that is, to quote Hamlet, "words, words... words." While it might make a good April Fool's joke to ask Novell and Red Hat to standardize on Debian, we don't exactly have a strong history of being able to pull off timely releases, and it would be a true fool who today would bank on future Debian release schedules before we've demonstrated that time-based releases are organizationally possible for us. > * We should proabably also commit to a set of core architectures which >*need* to be bug-free on release, while the rest *should* be, but >would not delay the release. Er, what would be the point of making a stable release for an architecture if we know that it's broken? But perhaps you meant that the architectures would be dropped from the release. > * We should look into having a reality-check with respect to licensing >and the way we treat each other. This wording seems to imply a particular outcome of any licensing "reality check". Perhaps you meant to post it to one of the many easy-to-find DFSG flamewars in Debian's recent history, instead of to a thread discussing LCC's significance to Debian. -- Steve Langasek postmodern programmer [1] http://linux.about.com/b/a/129063.htm signature.asc Description: Digital signature
Re: Linux Core Consortium
Hello Debian developers, It seems to me than one of the main value of Debian is in the quality of its core distribution. One of the reason of the quality is that it is not developed for itself but as a platform for the 10^4+ packages and the 10+ architectures in Debian. For example the compiler must be able to build all the packages we ship on all the architectures we support, and we have some reasonable warranty it is the case when we release. Given that, an attempt to develop the core distribution as a separate entity is going to be impractical and to reduce its quality. On the other hand, nothing bars the LCC to build a distribution on top of Debian. There is a lot of precedent for doing so (Xandros,libranet, lycoris, linspire, mepis, etc.). I have to say the gcc-2.96 nightmare had made me distrust a lot of commercial distributions. Red Hat was well aware it was a development snapshot with a different C++ ABI and not well tested. Mandrake and SuSE were well aware of the consequences of following Red Hat on that path. Yet they did it and I still suffer from the consequences today. As a practical matter, what if the Debian gcc team decide to release etch with gcc 3.3 because 3.4 break ABI on some platforms and gcc-4.x is not stable enough on all the platforms ? Will LCC follow ? If not, how are we going to share binary package if we do not use the same compiler? Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
On Fri, Dec 10, 2004 at 02:45:17PM +0100, Michael Banck wrote: > On Fri, Dec 10, 2004 at 01:49:33PM +0100, Frank Küster wrote: > > > I'm sorry the NMU annoyed you but I welcome it. There is nothing worse > > > than a package that kills buildds, esspecially such a common one. > > I agree. But still LaMont should have expressed his intent to do so, and > > send the patch to the BTS. I don't have a problem with being NMUed, but > > with NMUs prepared improperly. > At this point, any RC bug in an important (as in for the release, not > priority-wise) package is an implicit express to be NMUd, at any time. > Deal with it, we want to release. > One could argue about sending the NMU-patch/interdiff to the BTS, but I > personally do not see much point in it, since (hi Omnic!) you can just > get it from the archive and sync it yourself. It still makes sense for > packages where you suspect the maintainer to be inactive/not willing to > deal with this or (as is the case here apparently) already working on a > new revision. I don't see how this should be a point of contention at all; the requirement that diffs from NMUs be posted to the BTS has been explicit for a very long time. It is the responsibility of the NMUer to ensure that the diffs are delivered to the maintainer for inspection via the BTS. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
Ron Johnson <[EMAIL PROTECTED]> writes: > It is. if we want people in Arabia to be able to possess Debian > disks. The solution to censorious regimes is not to say, "well, ok, we'll censor ourselves so you don't even have to bother".
Re: ITP: g-wrap -- Scripting interface generator for C
Andreas Rottmann <[EMAIL PROTECTED]> writes:
> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
>
> > Andreas Rottmann <[EMAIL PROTECTED]> writes:
> >
> >> A note to Thomas: You can already try building GnuCash 1.8.9 (1.8.10
> >> will have the patch applied, as it is already in CVS, both in HEAD and
> >> the 1.8 branch) when you apply the attached patch.
> >
> > Just so you know, it's really my intention not to have *any* pre-Sarge
> > changes.
> >
> Fine. I'll probably try building GnuCash 1.8.9 with G-Wrap 1.9.3
> anyway, as maybe NetBSD pkgsrc switches to this setup and I want to
> make sure it works. I'll file a wishlist bug ("build against G-Wrap
> 1.9.x") on GnuCash with the according patches once G-Wrap 1.9.x is in
> Debian and I've made it work with GnuCash.
Excellent; that sounds like a good plan to me.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Friday 10 Dec 2004 15:13, Thomas Bushnell BSG wrote: > Ron Johnson <[EMAIL PROTECTED]> writes: > > It is. if we want people in Arabia to be able to possess Debian > > disks. > > The solution to censorious regimes is not to say, "well, ok, we'll > censor ourselves so you don't even have to bother". Which is a fine point of view if you are making a political point. But as far as I am aware we are trying to make an operating system.
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
Frank Lichtenheld wrote: On Fri, Dec 10, 2004 at 11:43:22AM +0100, Frank Küster wrote: I find this extremely annoying. Please calm down. Why? There's _no_ excuse not to mail the BTS before NMUing. You're free to discuss with lamont how to handle such cases in the future (and communicating him your anger) but please don't overreact. How to NMU is documented in the developers-reference -- you mail a patch to the BTS, indicate that you're going to NMU via the BTS, then NMU. Normally you have more than five seconds between those actions, but even if ten seconds is too long to wait, you should still do all those things. Heck, you should mail *especially* if ten seconds is too long to wait -- just to explain why the problem is so serious so there's some hope the maintainer can avoid it in future. The whole point of the "mail the BTS" policy is to avoid maintainers not knowing what's going on, or why it's going on. (Apparently Lamont's connectivity was screwed up, which caused the lack of email in this case, rather than lack of knowledge or effort) Cheers, aj
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
Op vr, 10-12-2004 te 15:22 +, schreef Will Newton: > On Friday 10 Dec 2004 15:13, Thomas Bushnell BSG wrote: > > Ron Johnson <[EMAIL PROTECTED]> writes: > > > It is. if we want people in Arabia to be able to possess Debian > > > disks. > > > > The solution to censorious regimes is not to say, "well, ok, we'll > > censor ourselves so you don't even have to bother". > > Which is a fine point of view if you are making a political point. But as far > as I am aware we are trying to make an operating system. Sure. So we should not censor ourselves. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Friday 10 Dec 2004 15:24, Wouter Verhelst wrote: > > Which is a fine point of view if you are making a political point. But as > > far as I am aware we are trying to make an operating system. > > Sure. So we should not censor ourselves. I don't see how that follows from what I said. Here's a couple of examples: We don't agree with censorship, so anything packageable goes in the distribution. This means we have a number of worthless and crufty packages that no-one uses and our time to release is getting ever longer. We also end up with packages that offend many people and may even cause legal problems for our distributors. We "clarify" the DFSG just prior to an intended release and nearly derail the whole release in the process. We are soon to refuse to ship binary firmware blobs when the writing is quite clearly on the wall that this is going to be something more and more people will have to deal with in the years to come. Do you see why it seems like Debian is more of a political talking shop that a team trying to develop an operating system? I don't want to start a flame war and I will probably not reply to this thread any longer, but the latest discussions on debian-devel have pushed me to the edge of resigning from this project.
Re: Linux Core Consortium
On Friday 10 December 2004 15.35, Steve Langasek wrote: > we don't exactly have a strong history of being able to pull off > timely releases Did Debian even try? I didn't follow the woody release too closely, being a Debian newbie at the time, so I don't know. But - this was my impression - from the start, sarge was prepared with the 'we release when we're ready' idea, which makes everybody feel that they have more than enough time. cheers -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg pgporALSTEBxi.pgp Description: PGP signature
Re: Linux Core Consortium
Hi, > > * We should commit to strict release cylces of a base system others >(and Debian itself) can build value upon. > > * We should proabably also commit to a set of core architectures which >*need* to be bug-free on release, while the rest *should* be, but >would not delay the release. > I don't think that buys us anything. I don't think there is a single architecture which has blocked the release up to now. All bugs that appeared by testing on different architectures, were real bugs in the code. They just didn't show up by only testing on a few architectures. In short, releases are not faster and would probably contain more bugs. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: Removal of freeswan from sarge
On Friday 10 December 2004 13.20, Frank KÃster wrote: > Rene Mayrhofer <[EMAIL PROTECTED]> wrote: > > I am still thinking about doing an "upgrade" package of freeswan > > though, which depends on openswan and simply moves the configuration of > > the old freeswan configuration to openswan. Any preferences towards > > such a package? > > I don't see any reasons for _not_ providing a smooth upgrade > path. As far I understand it, a kernel recompilation is necessary in most cases, so the upgrade won't be smooth anyway. Not providing an upgrade package would leave current freeswan users with their setup, while providing an upgrade package would make them pull in openswan on upgrade, when they really wanted to keep that kernel and their current freeswan set up. I don't use any IPsec currently, so I'm not a user, just adding my â.02 -- vbi -- The law will never make men free; it is men who have got to make the law free. -- Henry David Thoreau pgpLRSC9IuCFP.pgp Description: PGP signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
Op vr, 10-12-2004 te 15:38 +, schreef Will Newton: > On Friday 10 Dec 2004 15:24, Wouter Verhelst wrote: > > > Which is a fine point of view if you are making a political point. But as > > > far as I am aware we are trying to make an operating system. > > > > Sure. So we should not censor ourselves. > > I don't see how that follows from what I said. Censoring is done by people who try to make a political point. Creating an operating system involves throwing a pile of software together, integrate it, remove any and all bugs you find, and release that. It does not involve censoring. In Debian's case, we censor only based on the question whether a package is DFSG-free, nothing else. It would be wrong to act otherwise. > Here's a couple of examples: > > We don't agree with censorship, so anything packageable goes in the > distribution. That is currently not the case. There are four requirements for a package to be in main, and these are clearly spelled out in policy: they need to be DFSG-free, they must not depend on software out of main, they need to be not so buggy that we refuse to support them, and they need to be policy-compliant. > This means we have a number of worthless and crufty packages > that no-one uses and our time to release is getting ever longer. Packages that are worthless, crufty, unused, and unmaintained are routinely being removed from the archive. > We also end > up with packages that offend many people and may even cause legal problems > for our distributors. Have you taken a look at what hot-babe actually looks like? I suspect you haven't. I don't think it will "offend" anyone. [...] > Do you see why it seems like Debian is more of a political talking shop that > a > team trying to develop an operating system? Debian has always been a political organization; if we weren't, we wouldn't be anything called 'DFSG'. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
subscribe
yeah
Re: Linux Core Consortium
On Thu, 09 Dec 2004 13:59:10 -0500, Jim Gettys <[EMAIL PROTECTED]> wrote: > That being said, certainly UNIX's disunity was a major aid to Microsoft. > Repeating that history would not be good. I must agree with Jim. From the stand-point that Debian is losing developers to other Linux platforms and architecture specialists are giving their favorite hardware OpSys preferences I personally feel this is a "fork in the road" for Debian overall. Observational participation for Debian within LCC is perferred as non-participation may be construed as "bad mannered" whereas complete, wide ranging, participation will likely result in Debian being viewed as "just another Distro with in a sea of Linux". Debian, IMHO, has always set itselt apart. Sure, their may be internal issues, but any Distro in-motion, especially one such as Debian, will have growth related problems. -- WC -Sx- Jones http://insecurity.org/
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Friday 10 Dec 2004 16:07, Wouter Verhelst wrote: > Have you taken a look at what hot-babe actually looks like? I suspect > you haven't. I don't think it will "offend" anyone. I have looked at it. And I don't think it is an acceptable thing to ship as part of an operating system. I am an atheist and a liberal but the majority of people in the world are not.
Re: Linux Core Consortium
On Fri, Dec 10, 2004 at 04:04:22PM +0100, Bill Allombert wrote: > As a practical matter, what if the Debian gcc team decide to release > etch with gcc 3.3 because 3.4 break ABI on some platforms and gcc-4.x is > not stable enough on all the platforms ? Will LCC follow ? If not, how > are we going to share binary package if we do not use the same compiler? Another question that bothered me, is whether "special" binaries which cannot be bit-equal be rebuilt by the build-process (i.e. everything containing timestamps, random offsets (consider prelink -R) or machine dependant strings (like the hostname)) are really free. Obviously there are rights attached to the binary which cannot be reproduced solely from the delivered source. A similar argument was brought up in the DRM/Palladium discussion with signed binaries. But that was worse, because this kind of binaries was unusable without the signature while non-LCC binaries would just be that: non-LCC binaries. Regards, David -- * Customer: "My palmtop won't turn on." * Tech Support: "Did the battery run out, maybe?" * Customer: "No, it doesn't use batteries. It's Windows powered." -- http://www.rinkworks.com/stupid/cs_power.shtml
Re: dselect survey
On Fri, Dec 10, 2004 at 12:03:03PM +0100, Florent Rougon wrote: > [1] I still use both versions and happen to often hit instead of > when I use sid's one, which doesn't have any bad > consequences (simply scrolls help). And the problem will disappear > automatically when I don't have to use woody's dselect anymore. echo expert >> /etc/dpkg/dselect.cfg Regards, David -- * Customer: "My palmtop won't turn on." * Tech Support: "Did the battery run out, maybe?" * Customer: "No, it doesn't use batteries. It's Windows powered." -- http://www.rinkworks.com/stupid/cs_power.shtml
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Dec 10, 2004 at 16:30, Will Newton praised the llamas by saying: > I have looked at it. And I don't think it is an acceptable thing to ship as > part of an operating system. I am an atheist and a liberal but the majority > of people in the world are not. I don't think it is an acceptable thing to ship as it has no use. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione.
Re: dselect survey
On Fri, 10 Dec 2004 12:13:29 +0100, Florent Rougon <[EMAIL PROTECTED]> wrote: > I'm just trying to understand > people who bash dselect on the first occasion. If you don't like dselect > and don't fall in one of the cases I have mentioned, then we have a > problem. Simply preferring aptitude is *not* a valid reason to say > dselect is ugly, difficult to use, here>. Question: does awkward, non-intuitive user interface for a text-based utility constitute a "problem"? I don't care for dselect primarily because, for whatever reason, the user interface constantly rubs me the wrong way. Although I have read the documentation, I almost always remember it wrongly, hit the wrong keys, etc. etc. After working with it for half an hour or so, I regain my proficiency... but after 6 months of not using it all that minutia is lost to my active memory, and -- once again -- my intuition about how a text-based application SHOULD work fails me. Do I consider this a problem? Not particularly. It is my problem, as much as anyone's. This is a sophisticated sysadmin tool, and I am only an occasional sysadmin, by no means sophisticated. > > (f) bash dselect 'cause someone else said it was crap > However, if you believe that user interface is important, it might behoove you to listen to your users: people don't usually grow to "hate" a system administration utility simply because it's the hip thing to do. Of course there may be some unreasonable, or even plain-stupid users: but if you believe that user interface is important, you even have to think about how to make *them* happy. An owner, interested in user interface, might take it upon him- or herself to start a thread asking for interface suggestions, in a place where users congregate. Ask questions like: "What text-based applications do you consider to be examples of good design?" Focus on the distinction between navigation and data-altering events. Consider on-screen cheatsheets that advanced users can disable. Ensure that there are sufficient and obvious undo paths with multiple roll-back points. I am a software developer too -- I know the temptation to mock users who just don't get it when "it" is perfectly obvious. (I recently rolled out some web software in which a table interface had graphical links: up and down arrows at the top of each column, right below the column label. The number one complaint was: "This is useless. There's no way to sort!" Are my users dumb as dirt? Apparently they are. Is it their problem? No, it's mine.) Anyway, something to think about. -bluejack -- -:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
Re: Linux Core Consortium
Adrian von Bidder dijo [Fri, Dec 10, 2004 at 04:38:10PM +0100]: > > we don't exactly have a strong history of being able to pull off > > timely releases > > Did Debian even try? > > I didn't follow the woody release too closely, being a Debian newbie at the > time, so I don't know. But - this was my impression - from the start, > sarge was prepared with the 'we release when we're ready' idea, which makes > everybody feel that they have more than enough time. Yes, it did. Debian has long tried to shorten the release cycles, without any success. That's the reason why Testing was introduced (after Slink, IIRC). I got involved in Debian close to the Woody release. We were quite optimist that Sarge would release in ~1 year - We failed. The failure has some justifications, and they all fall down to the fact that Sarge has not been ready, and we will not release before it is ready... Which is getting closer every day :) There are many proposals to make Etch and future releases come out sooner, please check them at http://wiki.debian.net/index.cgi?ReleaseProposals Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Linux Core Consortium
On Fri, Dec 10, 2004 at 04:38:10PM +0100, Adrian von Bidder wrote: > On Friday 10 December 2004 15.35, Steve Langasek wrote: > > we don't exactly have a strong history of being able to pull off > > timely releases > > Did Debian even try? No, not since I've been around. > I didn't follow the woody release too closely, being a Debian newbie at the > time, so I don't know. But - this was my impression - from the start, > sarge was prepared with the 'we release when we're ready' idea, which makes > everybody feel that they have more than enough time. Yup. There's never been a sense of urgency. The RM's throw out release dates and goals every once in a while, but no one seems to take those seriously. And probably for good reason. For the second straight release, when we've gotten to a point that it seemed we were nearly ready for a release, we then discover we have no security autobuilders. The release then gets pushed back a few more months, while the plebeian developers sit around twiddling their thumbs unable to help wondering why the hell no one thought to set up the autobuilders in the 2+ years we've been preparing a release. -- For every sprinkle I find, I shall kill you!
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
David Pashley <[EMAIL PROTECTED]> writes: > On Dec 10, 2004 at 16:30, Will Newton praised the llamas by saying: >> I have looked at it. And I don't think it is an acceptable thing to ship as >> part of an operating system. I am an atheist and a liberal but the majority >> of people in the world are not. > > I don't think it is an acceptable thing to ship as it has no use. > Well, I tried hot-babe and it was a bit amusing for a minute or two, but I personally don't find it useful/amusing enough seeing any need for it. If, on the other hand, someone finds it useful aneough to package and maintain it, and there are a few other users interested in running it, well I can't really say anything against it. Usefulness is a subjective thing. Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Any technology not indistinguishable from magic is insufficiently advanced. -- Terry Pratchett
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
Will Newton <[EMAIL PROTECTED]> writes: > On Friday 10 Dec 2004 15:24, Wouter Verhelst wrote: > > > > Which is a fine point of view if you are making a political point. But as > > > far as I am aware we are trying to make an operating system. > > > > Sure. So we should not censor ourselves. > > I don't see how that follows from what I said. This way: we will not submit to the decision of the Saudi Arabian or Chinese governments about what is and is not important to an operating system.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
David Pashley <[EMAIL PROTECTED]> writes: > On Dec 10, 2004 at 16:30, Will Newton praised the llamas by saying: > > I have looked at it. And I don't think it is an acceptable thing > > to ship as part of an operating system. I am an atheist and a > > liberal but the majority of people in the world are not. > > I don't think it is an acceptable thing to ship as it has no use. That's a bad reason; if you applied it consistently you'd have to get rid of frozen-bubble.
Re: dselect survey
David Schmitt <[EMAIL PROTECTED]> wrote: > On Fri, Dec 10, 2004 at 12:03:03PM +0100, Florent Rougon wrote: >> [1] I still use both versions and happen to often hit instead of >> when I use sid's one, which doesn't have any bad >> consequences (simply scrolls help). And the problem will disappear >> automatically when I don't have to use woody's dselect anymore. > > echo expert >> /etc/dpkg/dselect.cfg Sure. It is configured this way on all the systems for which I am the only administrator. The minor problem I was talking about only happens on machines which are also administered by people less comfortable with dselect. Thanks for the suggestion, anyway. -- Florent
Re: dselect survey
Blunt Jackson <[EMAIL PROTECTED]> wrote: > Do I consider this a problem? Not particularly. It is my problem, as > much as anyone's. This is a sophisticated sysadmin tool, and I am only > an occasional sysadmin, by no means sophisticated. So, I guess some people simply don't like the *type* of control interface dselect offers, cause they want to see menus and widgets all around instead of having to learn that $keystroke will perform $action. Their main grief towards dselect is therefore formulated as "awkward, non-intuitive user interface" as you wrote above. Well, I don't think that is so important because I use dselect relatively often and this type of interface allows very efficient operation. Of course, things are a bit different for you since you said that you can spend six months without using it. The situation is IMHO a bit similar to the vi case: I find vi's interface awkward, non-intuitive, just as you qualified dselect's one. But I can understand that some people happen to get used to it, find it efficient and even like it. It's their right, after all. And claiming that vi is a POS just because I don't like its interface is probably not right. > important, you even have to think about how to make *them* happy. An > owner, interested in user interface, might take it upon him- or > herself to start a thread asking for interface suggestions, in a place > where users congregate. Ask questions like: "What text-based > applications do you consider to be examples of good design?" Focus on I haven't witnessed any discussion of this type, but I suppose that users would have conflicting views on the subject. Some would want a very easy to understand interface where you just have to follow menus without having to learn any keystroke, while others would prefer an interface where a limited number of keystrokes is enough to get the job done. And, er, I like dselect as it is[1], and am not particularly interested in such a discussion. :-p [1] That doesn't mean I think it's perfect (for instance, I dream of the day where debtags will be fully operational and integrated in dselect). Simply, I wouldn't welcome radical changes in the control interface that would make it less efficient. -- Florent
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > David Pashley <[EMAIL PROTECTED]> writes: > >> On Dec 10, 2004 at 16:30, Will Newton praised the llamas by saying: >> > I have looked at it. And I don't think it is an acceptable thing >> > to ship as part of an operating system. I am an atheist and a >> > liberal but the majority of people in the world are not. >> >> I don't think it is an acceptable thing to ship as it has no use. > > That's a bad reason; if you applied it consistently you'd have to get > rid of frozen-bubble. Though you could try the following set of criteria: 1. Are there already similar packages in Debian? NO - okay, add. 2. Does it offer significant *technical* advantages over those packages? YES - okay, add. 3. Are any of those other similar packages poorly maintained? YES - don't add another until the others are cleaned up or removed - so don't add 4. Hairsplitting time - is there likelihood that adding it will cause grave distress to some proportion of the target market? NO - don't add. Default: then add it. Since there are a *lot* of CPU monitors, and a finite number of developers, and I'm sure at least one CPU monitor needs more maintenance, and wmbubblemon does the same job better, why add another? cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml
Re: dselect survey
On Fri, Dec 10, 2004 at 10:03:01PM +0100, Florent Rougon wrote: > So, I guess some people simply don't like the *type* of control > interface dselect offers, cause they want to see menus and widgets all > around instead of having to learn that $keystroke will perform $action. > > Their main grief towards dselect is therefore formulated as "awkward, > non-intuitive user interface" as you wrote above. No, it is because the shortcuts are completely non-intuitive. I use aptitude for the good intuitive keymapping, not for its menu. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+497211606754 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: dselect survey
On Fri, Dec 10, 2004 at 12:03:03PM +0100, Florent Rougon wrote: > I understand that this may be unpleasant to some people It is not a problem for me that dseclt has no menu, it is a problem that the keys are totally unintuitive, and some screens are really bothering. aptitude has a nice usage "enter" means drill down, this is intuitive. 'q' means quit/leave level backward - this is intuitive +-_ for selecting, this is intuitive... g for go, this is intuitive Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+497211606754 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: dselect survey
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 +. This is a style of browsing which is intuitive to me. Gruss Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+497211606754 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
Rich Walker <[EMAIL PROTECTED]> writes: > Though you could try the following set of criteria: We could have all kinds of criteria. The ones you propose are not, in fact, our criteria. Our criteria are something like: 1. Does the license meet the DFSG? 2. Is there a Debian maintainer willing to maintain or sponsor the package? Now, you might want a different set of criteria, in which case, please suggest them in the proper forum, which is not here. My concern is that Saudi Arabia and China don't get to tell us what our criteria are, and I would oppose any criterion that amounts to "give China a veto". Your proposal allows China a veto in some cases, and this makes it unreasonable to me. It is outrageous to think that China's or Saudia Arabia's censorship regimes should somehow influence our decision making in the slightest. Thomas
add Date: field to Packages files
Say, perhaps a "Date:" field could be added to Packages files. I mean even dog food has the date stamped on it these days. Even my crumby message has a Date: field. Sure, as your eyes scan the MD5sum: field, the package's DNA is registered in your brain. But us old fashioned types would still like a Date: field. > Well Jacobson, the date can be clearly seen at http://.../pool/n/norbowitz But Mom said no more searching the web for dates, so now I'm offline.
Re: dselect survey
* Bernd Eckenfels <[EMAIL PROTECTED]> [041210 22:18]: > > Their main grief towards dselect is therefore formulated as "awkward, > > non-intuitive user interface" as you wrote above. > > No, it is because the shortcuts are completely non-intuitive. I use > aptitude for the good intuitive keymapping, not for its menu. And I tried aptitude some time, but still use dselect when I want a high-level interface. Dselect always tell me what to do next, aptitude is some wild guessing what the keys might be, never showing those I do need[1], doing strange (=counterintuitive) things and so on... Hochachtungsvoll, Bernhard R. Link [1] for example the key to make it finaly do something -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Você ainda não conseguiu o que queria ? Anuncie GRATIS em Usados e Baratos
Quer vender ou comprar produtos de informática ? Venha participar do mais novo site de anúncios de classificados de produtos de informática e telefonia celular da internet! Você pode colocar vários anúncios sem limitação, colocar fotos do seus produtos, receber perguntas e respondê-las pelo próprio site, além de categorias organizadas. Dinamismo e segurança nas suas vendas e compras on-line! E isso tudo inteiramente GRÁTIS!! Seja um dos primeiros membros e ganhe beneficios especiais como participante Premium! Aproveite! Usados e Baratos, o seu site de classificados de informática! Acesse Já http://www.usadosebaratos.com.br __ Effective communication is easy, flexible and personal http://www.x-mailer.com
Re: add Date: field to Packages files
On Sat, 11 Dec 2004, Dan Jacobson wrote: > Say, perhaps a "Date:" field could be added to Packages files. > I mean even dog food has the date stamped on it these days. > Even my crumby message has a Date: field. > Sure, as your eyes scan the MD5sum: field, the package's DNA is > registered in your brain. But us old fashioned types would still like > a Date: field. > > Well Jacobson, the date can be clearly seen at http://.../pool/n/norbowitz > But Mom said no more searching the web for dates, so now I'm offline. Even offline, files have time stamps in most modern filesystems out there. Just remember to keep it when you download the Packages files, as it's usually as available as the file itself.
Re: LCC and blobs
On Fri, Dec 10, 2004 at 01:20:32PM +0100, Marco d'Itri wrote: > On Dec 09, Bruce Perens <[EMAIL PROTECTED]> wrote: > > The whole system has to be DFSG-free. Debian won't compromise on that. > Which DFSG? The original one or the "clarified" one? Give it up, Marco. Your little tantrums aren't cute. > > I have been thinking about the blob problem for a while. I propose to > > remove blobs from the driver, and store them as files in initramfs (the > > kernel-internal filesystem created by the stuff in /usr/src/linux*/usr) > > or initrd.img. At boot time, the drivers would look for the blobs and > > You may want to take a look at debian-legal, because some people there > think that even free drivers for hardware devices which need an > externally loaded firmware are not acceptable for main. I presume you're referring to drivers which are useless without a non-free firmware blob. We should treat them exactly the same way as any other Free software which is useless without some non-free component, and stick it in contrib. - Matt signature.asc Description: Digital signature
Re: dselect survey
Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > No, it is because the shortcuts are completely non-intuitive. I use > aptitude for the good intuitive keymapping, not for its menu. I see. You find them utterly unintuitive, and are not alone. I don't claim they are really "intuitive" (for what it means...), but *I* don't find them to be a problem at all; and I'm not alone, either. Different people, different tastes... The good thing is, you can have your favorite program and I can have mine, cause noone in Debian will object to a program being packaged for a simple matter of taste, right? ;-) -- Florent
Re: LCC and blobs
Matthew Palmer <[EMAIL PROTECTED]> writes: > On Fri, Dec 10, 2004 at 01:20:32PM +0100, Marco d'Itri wrote: >> On Dec 09, Bruce Perens <[EMAIL PROTECTED]> wrote: >> > I have been thinking about the blob problem for a while. I propose to >> > remove blobs from the driver, and store them as files in initramfs (the >> > kernel-internal filesystem created by the stuff in /usr/src/linux*/usr) >> > or initrd.img. At boot time, the drivers would look for the blobs and >> >> You may want to take a look at debian-legal, because some people there >> think that even free drivers for hardware devices which need an >> externally loaded firmware are not acceptable for main. > > I presume you're referring to drivers which are useless without a non-free > firmware blob. We should treat them exactly the same way as any other Free > software which is useless without some non-free component, and stick it in > contrib. Then we might as well remove the whole kernel from main, since most devices depend on a non-free firmware blob to operate. Why does it matter if that blob is stored on the device itself in EPROM or loaded by the kernel? The end result is absolutely identical to the user. If we choose not to distribute non-free firmware blobs, then fine. I still don't see why it has any effect on the device driver though. -- For every sprinkle I find, I shall kill you!
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: LCC and blobs
On Fri, 2004-12-10 at 15:21 -0800, Brian Nelson wrote: > Matthew Palmer <[EMAIL PROTECTED]> writes: > > > On Fri, Dec 10, 2004 at 01:20:32PM +0100, Marco d'Itri wrote: > >> On Dec 09, Bruce Perens <[EMAIL PROTECTED]> wrote: [snip] > > Then we might as well remove the whole kernel from main, since most > devices depend on a non-free firmware blob to operate. Why does it Most ? Or are you stretching beyond reason, to include stuff like the BIOS, which isn't in the kernel? -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "Give a man a fish, you feed him for a day, teach him to fish, he gets mad at you for making him have to work so hard." signature.asc Description: This is a digitally signed message part
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Rich Walker <[EMAIL PROTECTED]> writes: > >> Though you could try the following set of criteria: [I added these back in for the sake of clarity] >>1. Are there already similar packages in Debian? NO - okay, add. >> >>2. Does it offer significant *technical* advantages over those packages? >> YES - okay, add. >> >>3. Are any of those other similar packages poorly maintained? YES - >> don't add another until the others are cleaned up or removed - so >> don't add >> >>4. Hairsplitting time - is there likelihood that adding it will cause >> grave distress to some proportion of the target market? NO - don't >> add. >> >>Default: then add it. >> > > We could have all kinds of criteria. The ones you propose are not, in > fact, our criteria. Our criteria are something like: > > 1. Does the license meet the DFSG? > 2. Is there a Debian maintainer willing to maintain or sponsor the >package? > These are givens. I know this. It can't move from valid-ITP to package without this. > Now, you might want a different set of criteria, in which case, please > suggest them in the proper forum, which is not here. Actually, I don't want a different set of criteria. As a user, I am concerned that Debian is in danger of having a thousand "CPU monitors"[1] all with RC bugs. A process for restricting addition of semi-duplicate packages might reduce workloads all round, and improve quality of installed packages. > My concern is that Saudi Arabia and China don't get to tell us what > our criteria are, and I would oppose any criterion that amounts to > "give China a veto". Your proposal allows China a veto in some cases, > and this makes it unreasonable to me. Not quite. I simply suggest that *in the absence of any technical reason why*, and *in the presence of a social reason why not*, it would be polite to adopt "why not". That social reason might be "I can get tortured for possessing this" and it might be "pornview is tacky as a package name - come[2] up with a better one" or just "I believe this license isn't DFSG-free". Of course, the fact that the package under discussion can make possession of a Debian CD illegal in certain countries[3] trumps either of our arguments. > It is outrageous to think that China's or Saudia Arabia's censorship > regimes should somehow influence our decision making in the slightest. I believe the correct flame-inducing argument at this point is "tell that to the first person tortured or executed for possessing a Debian CD with hot-babe on it *who was not aware it was there*". Testimony elsewhere in this thread suggests that *possession* in those countries is a capital crime, with or without knowledge. This would seem to make adding this package a breach of the Social Contract, clause 4. Getting your users executed un-necessarily is, it's true, a very idealist thing to do, but I can't see everyone signing up to it. cheers, Rich. Footnotes: [1] Or any other common package type. Editors. MP3 players. Playlist managers. RSS feed agglomeraters. Xbiff clones. [2] For my English readers - I did that on purpose [3] Non-US exists because export of strong crypto from the US is an illegal act in the US. Hence, Debian has already accepted that local laws trump idealism. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
Rich Walker <[EMAIL PROTECTED]> writes: > Actually, I don't want a different set of criteria. As a user, I am > concerned that Debian is in danger of having a thousand "CPU > monitors"[1] all with RC bugs. A process for restricting addition of > semi-duplicate packages might reduce workloads all round, and improve > quality of installed packages. That's not a problem for our procedures. Optional packages with RC bugs do not hold up the release; they simply get dropped. > > My concern is that Saudi Arabia and China don't get to tell us what > > our criteria are, and I would oppose any criterion that amounts to > > "give China a veto". Your proposal allows China a veto in some cases, > > and this makes it unreasonable to me. > > Not quite. I simply suggest that *in the absence of any technical reason > why*, and *in the presence of a social reason why not*, it would be > polite to adopt "why not". Your proposal gives China a veto *in some cases*. I think it should get a veto *in no cases*. Regardless, the discussion belongs on debian-project. Thomas
Re: LCC and blobs
Ron Johnson <[EMAIL PROTECTED]> writes: > On Fri, 2004-12-10 at 15:21 -0800, Brian Nelson wrote: >> Matthew Palmer <[EMAIL PROTECTED]> writes: >> >> > On Fri, Dec 10, 2004 at 01:20:32PM +0100, Marco d'Itri wrote: >> >> On Dec 09, Bruce Perens <[EMAIL PROTECTED]> wrote: > [snip] >> >> Then we might as well remove the whole kernel from main, since most >> devices depend on a non-free firmware blob to operate. Why does it > > Most ? I'm no hardware expert, but I assume all ethernet cards, wireless chipsets, and SCSI cards do. At least that's true for all of the hardware I have... > Or are you stretching beyond reason, to include stuff like the > BIOS, which isn't in the kernel? If it made any sense at all for a mainboard's BIOS to loaded by the Linux kernel at boot time with a non-free firmware blob, the current consensus (on debian-legal anyway) seems to be that Debian would not support it. Period. The drivers for it would have to go in contrib. As far as I'm concerned, distribution of the firmware is the manufacturer's realm. Whether the manufacturer distributes it on an EPROM on the device itself, or on a CD shipped with the device, or just provides it for download from a website, I don't care. That's their decision. Debian should not care one bit how the firmware is loaded on the device, and the method used should not dictate whether a driver is DFSG-compliant. As for whether Debian would actually distribute the firmware blobs in main, I would prefer that we do. It can be a real pain installing Debian on a system in which I have to retrieve the firmware from an external source. It's only hurting the end-user by making them jump through more hoops to install Debian, with no obvious benefit. However, there seems to be a strong movement to make Debian 100% free down to the last bit. Reversing this movement is another much more controversial issue. -- For every sprinkle I find, I shall kill you!
Re: Intel EM64T porting machine for Debian
On Sat, 11 Dec 2004 00:27:38 +, Martin Michlmayr - Debian Project Leader <[EMAIL PROTECTED]> wrote: > agreed to set up the machine, host it for a while and give interested > developers access. This box is not a general .debian.org Is this by invitation only? -- WC -Sx- Jones http://insecurity.org/
Re: Bug#284642: ITP: dpkg-reversion -- change the version of a DEB file
On Thu, 9 Dec 2004, martin f krafft wrote: > also sprach Adam Heath <[EMAIL PROTECTED]> [2004.12.09.2053 +0100]: > > Probably yes on dpkg-repack. Definately not for dpkg-www. Which > > is a sucky name, btw. > > Agreed. However, if dpkg-repack goes into dpkg, why not provide > a means to edit a DEB file (without having to install it) too? Well, the plan is to make the dpkg-deb interface more formalized. What I mean, is being able to use it in a filter, with plugging input and output. Ie, multiple input methods: .deb, .rpm, filesystem filter mode: standard tar output output mode: filesystem, .deb, .rpm Repacking and editting then become easy to do.
Re: add Date: field to Packages files
On Fri, 10 Dec 2004, Santiago Vila wrote: > On Sat, 11 Dec 2004, Dan Jacobson wrote: > > > Say, perhaps a "Date:" field could be added to Packages files. > > I mean even dog food has the date stamped on it these days. > > Even my crumby message has a Date: field. > > Sure, as your eyes scan the MD5sum: field, the package's DNA is > > registered in your brain. But us old fashioned types would still like > > a Date: field. > > > Well Jacobson, the date can be clearly seen at http://.../pool/n/norbowitz > > But Mom said no more searching the web for dates, so now I'm offline. > > Even offline, files have time stamps in most modern filesystems out there. > Just remember to keep it when you download the Packages files, as it's > usually as available as the file itself. Timestamp of the .ar members.
Intel EM64T porting machine for Debian
Over the last few weeks, I have been in discussion with Intel about getting an EM64T system for Debian. They agreed to give a system on loan to us for 6 months (or possibly longer if we make good use of it) and after some legal issues were clarified (thanks to Greg Pomerantz of SPI), the machine is now being shipped to Stephen Frost. Stephen agreed to set up the machine, host it for a while and give interested developers access. This box is not a general .debian.org infrastructure box, but it is strictly to be used for EM64T/AMD64 porting, especially to make sure the existing experimental AMD64 port of Debian works on EM64T without any problems. I assume Stephen will post details about how to get accounts once he has received and installed the machine. -- Martin Michlmayr [EMAIL PROTECTED]
