Re: The correct use of debian-devel
On Sun, Jun 04, 2006 at 05:51:17PM +0200, Cesare Leonardi wrote: > In particular, the primary question is: Who can write on > debian-devel? Anyone: - interested - that has constructive things to say, on-topic, that is the technical development of Debian. - that does so in a socially acceptable way (not too much insults, ad hominem attacks, ...) The "interested" part would tend to restrict it to Debian contributors, upstream authors (for specific threads), ... I say "contributors", not "developers". > Steve Langasek wrote: >>On Sun, Jun 04, 2006 at 12:18:16PM +0200, Olaf van der Spek wrote: >>>On 6/4/06, Anthony Towns wrote: On Sun, Jun 04, 2006 at 12:18:39AM -0700, Mike Bird wrote: > It is past time that the covert actions of the "small cabal" > were openly reviewed. The license (for convenience), any > relevant written promises from Sun (if any), and any relevant > written legal opinions from counsel (if any) should forthwith be > posted to debian-legal. For those playing along at home, Mike isn't a Debian developer, doesn't maintain any packages, and isn't a new-maintainer applicant. He doesn't even seem to be a regular participant on the debian-legal list. >>> None of those things seem to be relevant. >> For those still playing, Olaf also isn't a Debian developer, >> doesn't maintain any packages, and isn't a new-maintainer >> applicant. He's made something like 5 posts to debian-legal, >> though, which I guess given Andrew Donnellan's assertion that >> someone with one post ever on -legal is a "regular participant", >> means Olaf is a senior analyst or something. >> As beautiful as this irony is of a non-developer asserting on a >> developer list that being involved in development is irrelevant, >> you might want to give some thought to the question of why a >> non-developer making demands of anyone might be seen as >> doubly-inappropriate. > Because for someone that is not a "primary collaborator", a DD, but > use Sid to follow the Debian development, report and comments on > bug, reply to suggest improvement, collaborate with developer to > solve problems (DD: Please can you try this? What if you run... Your > hardware in uncommon, what do you see...) This self-description qualifies you as contributor. > and express sane, constructive and polite opinion on subjects that > he judges important and, in general, acts hoping to help the Debian > project going on, even on non-regular basis, And this as "socially acceptable" and "constructive things to say, on-topic". > They seems to say: "If you don't write code, you cannot permit to > speak in debian-devel". For in so far as I can agree with what was said, it meant "if you are not a member of Debian (a status that is confusingly called 'Debian developer'), you don't get to speak in the name of Debian (unless by specific, subject-restricted proxy of Debian)". Even DDs should be very cautious about _not_ speaking in the name of Debian on subjects that are not consensual within Debian. Just a note to the public that this comment was not done in the name of Debian. This was particularly "needed" in the context of licenses, because non-DDs have not been checked as adhering to the social contract / DFSG and as understanding the Debian "caselaw" interpretation of these documents. And also: if you are not a DD (that is member of Debian), you don't get a direct "vote" about how the internal Debian decision-making process works, but you can convince a DD to take up the idea and you can contribute in the discussion. But try to avoid hot buttons like the word "cabal", people will listen better to you if you don't. (I think I've slipped well into personal opinion, and out of "what I can support in the statements made" there.) > Or, that is worse: "If you don't write code you are not > partecipating in the Debian development". That is wrong. People do get DD status for doing translation, there is a special NM track for that. We are not quite setup to handle a flood of NMs that come for _other_ competences than packaging or translation, but nobody let that keep hir from applying; we'll treat them as special cases (if not too many) or setup an NM track for it (if numerous). -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Wed, Jul 12, 2006 at 02:18:27AM -0400, Eric Dorland <[EMAIL PROTECTED]> wrote: > * Mike Hommey ([EMAIL PROTECTED]) wrote: > > On Wed, Jul 12, 2006 at 12:47:32AM -0400, Eric Dorland <[EMAIL PROTECTED]> > > wrote: > > > * Matthew Garrett ([EMAIL PROTECTED]) wrote: > > > > Eric Dorland <[EMAIL PROTECTED]> wrote: > > > > > > > > > Just to point out that as of Firefox/Thunderbird 2 the entire codebase > > > > > is triple licensed under the MPL, GPL and LGPL and any objection to > > > > > the MPL as far as Mozilla is concerned is fairly academic at this > > > > > point. > > > > > > > > Seriously? That's absolutely great. Is there any sort of announcement > > > > of > > > > this anywhere? > > > > > > Seriously: > > > http://weblogs.mozillazine.org/gerv/archives/2006/03/relicensing_complete.html. > > > > Actually, only the trunk has the relicensing complete, and the trunk is > > Firefox 3. Firefox 2 will still be in the same state as previous > > releases, but we know most of its code is available in upstream cvs in a > > really triple licensed form. > > Really? Gerv's post is incorrect? Last time I checked (and it was after Gerv's post), the relicensing changes were still not applied to the MOZILLA_1_8_BRANCH. Things seem to have changed, but that needs some checking. I took some random files to check and found out files that are not tri-licensed in the trunk, so... *sigh* Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
announcing bluetooth maintainers group
Hello fellow developers, I would like to announce the creation of bluetooth maintainers team (pkg-bluetooth on alioth). There's a wiki page ( http://wiki.debian.org/Bluetooth ) where you can find more informations. The team aims to provide better integration between bluetooth applications (bluez and friends) and desktops and the whole debian system in general. I would like to have more packages and more people involved (we are using svn-buildpackage, svn repo at http://svn.debian.org/wsvn/pkg-bluetooth/ note that not all packages in svn are under current maintaineance). Comments are welcome as usual :) thanks in advance, filippo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#377956: ITP: python-psycopgda2 -- PostgreSQL adapter for Python
Package: wnpp
Severity: wishlist
Owner: Toni Mueller <[EMAIL PROTECTED]>
Hello,
I intend to package this module which would be a successor of
python-psycopgda
* Package name: python-psycopgda2
Version : 2.0.2
Upstream Author : Federico Di Gregorio <[EMAIL PROTECTED]>
* URL : http://initd.org/pub/software/psycopg/
* License : GPL with OpenSSL and Pg exeption, ZPL and BSD for parts of
the package
Programming Lang: C, Python
Description : PostgreSQL adapter for Python
psycopg - Python-PostgreSQL Database Adapter
psycopg is a PostgreSQL database adapter for the Python programming
language. This is version 2, a complete rewrite of the original code to
provide new-style classes for connection and cursor objects and other
sweet candies. Like the original, psycopg 2 was written with the aim of
being very small and fast, and stable as a rock.
psycopg is different from the other database adapter because it was
designed for heavily multi-threaded applications that create and destroy
lots of cursors and make a conspicuous number of concurrent INSERTs or
UPDATEs. psycopg 2 also provide full asycronous operations for the
really brave programmer.
psycopg is free software ("free as in freedom" but I like beer too.)
Licensing information is available in the LICENSE file.
Note: If there is already a package (which I failed to detect), please
notify me. In that case, I'd like to avoid duplicating the effort.
Best,
--Toni++
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Done in NMU
Processing commands for [EMAIL PROTECTED]: > tags 322762 fixed Bug#322762: /usr/doc still exists (transition tracking bug) There were no tags set. Tags added: fixed > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322762: Done in NMU
tags 322762 fixed thanks -- .''`. Fuck your fascist beauty standards : :' : `. `' Proudly running unstable Debian GNU/Linux `- www.amayita.com www.malapecora.com www.chicasduras.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
the planet is gone...
Hi DDs, this may again be the wrong place - but from here (Germany), I cannot access planet.debian.org anymore. The problems seem to be with qwest.net, who themselves cannot route to HP, where the planet actually is according to a 'whois': (from qwest.net's Atlanta router): traceroute to 192.25.206.10 (192.25.206.10), 30 hops max, 40 byte packets 1 atl-svcs-01 (205.171.21.214) 0.929 ms 0.525 ms 0.493 ms 2 atl-core-02 (205.171.21.17) 0.616 ms 0.621 ms 0.589 ms 3 atl-edge-17 (205.171.21.186) 0.585 ms 0.625 ms 0.583 ms 4 65.112.33.30 (65.112.33.30) 1.484 ms 1.205 ms 1.075 ms 5 * * * 6 * * * 7 * * * and so on - you can check yourself on http://stat.qwest.net/looking_glass.html Sigh... at least klecker is back - we get that over xs4all now. -- cheers, +---+ | wjl aka Wolfgang Lonien | GPG key: 728D9BD0 | |-| Fingerprint: | | Mail: | a923 2294 b7ed eb3e 2f18 | | wolfgang - at - lonien.de | ae56 aab8 d36a 728d 9bd0 | +---+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Not blocking
Processing commands for [EMAIL PROTECTED]: > unblock 322762 by 359360 Bug#322762: /usr/doc still exists (transition tracking bug) Was blocked by: 189856 190020 203278 254800 254913 254924 255590 302504 319726 320084 320103 321926 322749 322769 322772 322776 322778 322779 322781 322782 322783 322784 322785 322786 322787 322788 322789 322790 322791 322792 322793 322794 322795 322797 322798 322799 322800 322801 322803 322804 322805 322806 322807 322808 322809 322810 322811 322812 322813 322814 322815 322816 322817 322818 322819 322820 322828 322829 322830 322831 322832 322833 322834 322835 322837 322838 322839 352893 352894 353569 355341 359358 359359 359360 359361 359362 359363 359364 359365 359366 359367 359368 359369 359370 359371 359372 359374 359375 359376 359377 359378 359379 359380 359381 359382 359383 359384 359385 359386 359387 359388 359389 359390 359391 359392 359393 359394 359395 359396 359397 359398 359399 359400 359401 359402 359403 359404 359405 359406 359407 359408 359409 359410 359411 359412 359413 359414 359415 359416 359417 359418 359419 359420 359421 359422 359423 359424 359425 359426 359427 359428 359429 359430 359431 359432 359433 359434 359435 359436 359437 359439 359440 359441 359442 359443 359444 359445 359446 359447 359448 359449 359450 359451 359452 359453 359454 359455 359456 359457 359458 359459 359460 359461 359462 359463 359464 359465 359466 359467 359468 359469 359470 359471 359472 359473 359474 359475 359476 359477 359478 359479 359480 359481 359482 359483 359484 359485 359486 359487 359488 359489 359490 359491 359492 359493 359494 359495 359496 359497 359498 359499 359500 359501 359502 359503 359504 359505 359506 359507 359508 359509 359510 359511 359512 359513 359514 359515 359516 359517 359518 359519 359520 359521 359522 359523 359524 359526 359527 359528 359529 359530 359531 359532 359533 359534 359535 359536 359537 359538 359539 359540 359541 359542 359543 359544 359545 359546 359547 359548 359549 359550 359551 359552 359553 359554 359555 359556 359557 359558 359559 359560 359561 359562 359563 359564 359565 359566 359567 359568 359569 359570 359571 359572 359573 359574 359575 359576 359577 359578 359579 359580 359581 359582 359583 359584 359585 359586 359587 359588 359589 359590 359591 359592 359593 359594 359595 359596 359597 359598 359599 359600 359601 359602 359603 359604 359605 359606 359607 359608 359609 359610 359611 359612 Blocking bugs of 322762 removed: 359360 > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the planet is gone...
Hi, On Wed, Jul 12, 2006 at 12:42:06PM +0200, Wolfgang Lonien wrote: > this may again be the wrong place - but from here (Germany), I cannot > access planet.debian.org anymore. gluck, the box which hosts planet.debian.org and www.debian.org is down. Sorry for the inconvenience, Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
0O7
hands of the International Institute." disappointed. There was a limit to how much the new body could do, and never set eyes on them! that? What does it feel like? How far can you go?" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the planet is gone...
Michael Banck wrote: > Hi, Hi Michael, > On Wed, Jul 12, 2006 at 12:42:06PM +0200, Wolfgang Lonien wrote: >> this may again be the wrong place - but from here (Germany), I cannot >> access planet.debian.org anymore. > gluck, the box which hosts planet.debian.org and www.debian.org is down. ic... that can happen of course... > Sorry for the inconvenience, np - is there a status page somewhere for the Debian boxes, so next time ppl could look it up themselves? I would volunteer to make one, but I'm no DD... -- cheers, wjl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: I'm stoopid
Processing commands for [EMAIL PROTECTED]: > tags 322762 -fixed Bug#322762: /usr/doc still exists (transition tracking bug) Tags were: fixed Tags removed: fixed > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Wed, Jul 12, 2006 at 10:10:29AM +0200, Mike Hommey <[EMAIL PROTECTED]> wrote: > Last time I checked (and it was after Gerv's post), the relicensing changes > were still not applied to the MOZILLA_1_8_BRANCH. Things seem to have > changed, but that needs some checking. I took some random files to check > and found out files that are not tri-licensed in the trunk, so... *sigh* After a slightly closer look, it seems most of the code is actually tri-licensed, even in the Firefox 2 branch. Strangely enough, while the vast majority of the code is under MPL/GPL/LGPL, some of it is under NPL/GPL/LGPL. That doesn't change much for us, but it's still strange. Still a lot of files don't have a license text at all, including examples and test source code. Some examples and test files are licensed under Mozilla-sample-code. The most problematic files are in xpcom/reflect/xptcall/src/md/unix. This directory contains assembler code for xpcom on several platforms. While a lot of these files are not of any use for us (irix, vms...) some are indeed used: xptcinvoke_asm_ppc_linux.s, xptcstubs_asm_ppc_linux.s and xptcinvoke_asm_sparc_linux.s are NPL only ; xptcinvoke_asm_mips.s is MPL. I'm going to contact Gerv about that. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: the planet is gone...
I have always liked Demons (UK ISP) status which is linked to the motd on their gateway. If you type "finger [EMAIL PROTECTED]" you get the current status of their systems. Simple perl cgi which also does a web page. If there is interest (and nothing already exists) I will code something along the these lines. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Wed, 2006-07-12 at 01:02 +0100, Matthew Garrett wrote: > Erast Benson <[EMAIL PROTECTED]> wrote: > > > Don't forget that Joerg were main developer of cdrtools for quite some > > time and we should respect his point of view on how result of his work > > for the last (what 10 years?) should be licensed. Debian is built on top > > of contributions made by people like Joerg. Besides, Joerg made a good > > point on why he thinks that his mix of CDDL and GPL code is OK. Please > > provide real fact arguments aligned with general license interpretation > > rules, if none provided, I suggest to close those bugs. > > 1) The GPL requires that all scripts used to control compilation and > installation of the executable be released under terms compatible with > the GPL. Joerg clearly stands that: 1) Makefiles != scripts or at least it is unclear whether Makefiles may be called "scripts": """ GPL §3 requires the "scripts for compilation" to be provided but as a first note, it is unclear whether Makefiles may be called "scripts". Makefiles are programs written in a non-scripting language: I call this language "make". It is a non-algorithmic language but a rule based language (like e.g. CDL2).""" but this is not the main point of his argument. > 2) The Schily makefile system is licensed under the CDDL. which is totally fine (read below) > 3) The Schily makefile system is used to control compilation and > installation of the executable Makefile(s) are not exactly scripts... (read above) > 4) The CDDL is not compatible with the GPL But not in his case. He explains: """Next point is that GPL §2 requires that the whole code of a project (if you carefully read GPL §2, this does only include things that do end up in the binary) that is made from including other peoples GPL code is to be made available under the GPL. This means in other words: If I take other people's GPL code and create a "derived work" from that code, I need to make the whole work available under GPL. I do not need to make non-GPL code available at all, if GPL code is derived on that code. I do not need to make the build system available under GPL (GPL §3 requires me to make it available but does not mention a license) and the build system is not code that is "derived" from the GPLd project.""" later he explains: """This means in other words: If I take other people's GPL code and create a "derived work" from that code, I need to make the whole work available under GPL. I do not need to make non-GPL code available at all, if GPL code is derived on that code. I do not need to make the build system available under GPL (GPL §3 requires me to make it available but does not mention a license) and the build system is not code that is "derived" from the GPLd project.""" The key point is: GPL is pure source license. It does not explicitly require you to use a specific license for the binary in case you make the source available. Erast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
* Mike Hommey ([EMAIL PROTECTED]) wrote: > On Wed, Jul 12, 2006 at 10:10:29AM +0200, Mike Hommey <[EMAIL PROTECTED]> > wrote: > > Last time I checked (and it was after Gerv's post), the relicensing changes > > were still not applied to the MOZILLA_1_8_BRANCH. Things seem to have > > changed, but that needs some checking. I took some random files to check > > and found out files that are not tri-licensed in the trunk, so... *sigh* > > After a slightly closer look, it seems most of the code is actually > tri-licensed, even in the Firefox 2 branch. Strangely enough, while the > vast majority of the code is under MPL/GPL/LGPL, some of it is under > NPL/GPL/LGPL. That doesn't change much for us, but it's still strange. > Still a lot of files don't have a license text at all, including > examples and test source code. Well I'm glad it's mostly resolved. It's odd that there are still things licensed under the NPL. http://www.mozilla.org/MPL/ says it's not even used in any mozilla code anymore. > Some examples and test files are licensed under Mozilla-sample-code. Uh, is that actually a license? > The most problematic files are in xpcom/reflect/xptcall/src/md/unix. > This directory contains assembler code for xpcom on several platforms. > While a lot of these files are not of any use for us (irix, vms...) some > are indeed used: > xptcinvoke_asm_ppc_linux.s, xptcstubs_asm_ppc_linux.s and > xptcinvoke_asm_sparc_linux.s are NPL only ; > xptcinvoke_asm_mips.s is MPL. Even if we don't use the irix, vms, etc files, if they're problematic license-wise, we'd need to strip them out or get the license fixed. > I'm going to contact Gerv about that. Fantastic. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Broken applications: Could we be honest?
Thanks for your response. We have the pgi compiler on the head node of a very old, 32-bit beowulf. I do my production calculations on a very nice large, 64-bit cluster at a national laboratory, but my desktop machine had, until about 6 weeks ago, been a 1.4 GHz 32-bit machine. The graphics had become hopelessly bogged down. So, ironically, our main internal compute engine is 32-bit and my desktop is 64. Go figure. I'm using my laptop for most code development and for making xmgrace figures for publication. Art Edwards On Sat, Jul 08, 2006 at 05:40:37PM +0100, Jimmy Tang wrote: > On 7/8/06, Art Edwards <[EMAIL PROTECTED]> wrote: > > > >I have been writing to the list about two applications that > >are so broken on the AMD64 distribution that they render the > >box pretty useless. I'm sure one could say that two measly > >applications are no big deal. However, if you do scientific computation > >for a living, and two of the primary tools are broken, you now have > >a rather clumsy paperweight where a computer should be. You could > >argue that we should simply learn new tools, and we could, but we > >should really be doing science instead. > > > >This brought up the question, who uses 64 bit Linux anyway? > >Surely gamers do not drive the 64-bit linux community. It can't be the > >desktop > >community, seeing that the standard office tool doesn't really > >work for 64-bit. I would think that scientific and engineering > >users would drive this community. Besides the instruction set, which > >can probably give some speed, but wouldn't justify the cost, the address > >space in 64-bit OS's mean that we can solve much larger problems. Unles > >you're > >not doing some heavy-duty, memory-intensive computation, 64-bits seems > >to be simply a status symbol. > > > >For compute servers the amd64 distribution is fine. All you really need > >are > >languages (compilers), libraries and decent MPICH. We run our small, 32 > >bit > >Beowulf on debian with abandon, and from my experience, I look forward to > >converting it to amd64 ... with a 32-bit node where things actually work. > > > >Unless such core pieces as the debugging tool (ddd) and the data display > >tool > >(xmgrace) are working, it is dishonest to pretend that the 64-bit version > >is ready for testing. It would be very nice if you, and other distro's, > >were > >to put appropriate caveats on the websites, saying that 64-bit is really > >not > >ready for the prime-time desktop. That way, we could make better > >purchasing > >decisions. > > > > > > > At the risk of imposing what we do at our work place onto your work flow, i > find that users generally should have access to better debuggers/profilers > than what ships with standard gnu distros. presumably if you are doing > scientific computations, you probably have access to a commercial compiler? > i know that the portland group compilers ship with a fairly good gui > debugger if you are not satisfied with gdb (in parallel attached to each > running process) > > also shouldnt users be using programs like xmgrace on their local > workstations? again with out trying to impose my workflow to yours, i find > sometimes users do silly things on the head node on clusters, and I tend to > try and get my users to do post analysis etc... stuff that can run serially > on their own desktops whenever possible. > > Jim > > > > -- > Jimmy Tang > Trinity Centre for High Performance Computing, > Lloyd Building, Trinity College Dublin. > http://www.tchpc.tcd.ie/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
Excuse me for chiming in, but I think many places simply look for the best performance and productivity/dollar(euro). We do use the PGI compiler, mostly because gnu had not had a f90-f95 compiler, and partly because of, maybe, a 10% improvement in speed. What I find interesting is that both Fedora and Debian have similar problems for different reasons. Debian has now stable release for AMD64 because Sarge was released before AMD64 was really ready. This means that we are all stuck in the beta test-site pool. It would be really nice if Debian actually packaged up a "stable-like" version of AMD64 at the same level as Sarge. Fedora has been moving so quickly, that they have incorporated the same problems into a nominally stable release. On Sat, Jul 08, 2006 at 07:28:21PM +0200, Oliver Rother wrote: > Jimmy Tang wrote: > > >At the risk of imposing what we do at our work place onto your work > >flow, i find that users generally should have access to better > >debuggers/profilers than what ships with standard gnu distros. > > Well, if you intend to start a flame war on the lists... but enough on that. > > >presumably if you are doing scientific computations, you probably have > >access to a commercial compiler? > > Oh, we do. Consider an project with a timeline of many years or even > decades of years. would you choose a non onepn source (commercial) > compiler/debugger for that project? I'm pretty sure, you won't. > > >also shouldnt users be using programs like xmgrace > > Talking about commerical applications from your point of view - why use > free software for data analysis when powerful commercial packages like > IDL are available? > > Olli > > -- > Oliver Rother, Department of Space Physics, > University of Kiel, Leibnizstr. 11/505a, D-24118 Kiel > phone: +49 (0)431 880 4802, fax: +49 (0)431 880 3968 > [EMAIL PROTECTED] www.ieap.uni-kiel.de/et -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
The point is that they do not work exactly fine. For ddd, the console at the bottom is dead. The keyboard fails. For grace(xmgrace) the same symptom is present in all text boxes. This appears to be a pretty general problem because the same is true for Fedora Core 5, but not for Fedora Core 4. I have compiled xmgrace from sources and I have the same problem. I have done some looking and this problem surfaced several years ago on a cygwin list. Just for the record, when I invoke xmgrace from the command line, I receive many errors like this: Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfHelp I get exactly the same set from ddd. Again, this is true for AMD64 for both Debian and for Fedora Core 5. Art Edwards On Sat, Jul 08, 2006 at 07:02:24PM +0200, Oliver Rother wrote: > Art Edwards wrote: > > >Unless such core pieces as the debugging tool (ddd) and the data display > >tool > >(xmgrace) are working, it is dishonest to pretend that the 64-bit version > >is ready for testing. > > ddd and grace are in Debian testing (etch) amd64 and work fine. So where > exactly is the issue? > > We use an mixture of testing and unstable here with the following > priority setting /etc/apt/preferences: > > Package: * > Pin: release a=testing > Pin-Priority: -1 > Package: * > Pin: release a=unstable > Pin-Priority: -2 > > So, if a package is still brocken in testing (as parts of gnome at least > at box installation time), we take it from unstable with > > apt-get install PACKAGE -t unstable, > > including its dependencies. > > So far, we observerd no major issues. > > -- > Oliver Rother, Department of Space Physics, > University of Kiel, Leibnizstr. 11/505a, D-24118 Kiel > phone: +49 (0)431 880 4802, fax: +49 (0)431 880 3968 > [EMAIL PROTECTED] www.ieap.uni-kiel.de/et -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
On 7/12/06, Art Edwards <[EMAIL PROTECTED]> wrote: The point is that they do not work exactly fine. For ddd, the console at the bottom is dead. The keyboard fails. For grace(xmgrace) the same symptom is present in all text boxes. This appears to be a pretty general problem because the same is true for Fedora Core 5, but not for Fedora Core 4. I have compiled xmgrace from sources and I have the same problem. I have done some looking and this problem surfaced several years ago on a cygwin list. Just for the record, when I invoke xmgrace from the command line, I receive many errors like this: Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfHelp I get exactly the same set from ddd. Again, this is true for AMD64 for both Debian and for Fedora Core 5. Art Edwards I did a google search for "Warning: String to TranslationTable conversion encountered errors" and found this link: http://www.ubuntuforums.org/showthread.php?t=82087 With the following suggestion: The answer is: export XKEYSYMDB=/usr/share/X11/XKeysymDB This is also needed to get the grace package to work right on Breezy, BTW. Hope this helps -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
On Jul 12, 2006 at 20:39, Art Edwards praised the llamas by saying: > The point is that they do not work exactly fine. For ddd, the console at the > bottom is dead. > The keyboard fails. For grace(xmgrace) the same symptom is present in all > text boxes. This appears to be a pretty general problem because the same is > true for > Fedora Core 5, but not for Fedora Core 4. I have compiled xmgrace from > sources and > I have the same problem. I have done some looking and this problem surfaced > several years ago on a cygwin list. > Just for the record, when I invoke xmgrace from the command line, I receive > many errors like this: > > Warning: String to TranslationTable conversion encountered errors > Warning: translation table syntax error: Unknown keysym name: osfHelp > > I get exactly the same set from ddd. Again, this is true for AMD64 for both > Debian and for Fedora Core 5. > > Can you file bugs about both these issues using the reportbug tool so the maintainers are made aware of the problems. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
* Art Edwards <[EMAIL PROTECTED]> [2006-07-12 21:48]: > Excuse me for chiming in, but I think many places simply look > for the best performance and productivity/dollar(euro). We do use the PGI > compiler, > mostly because gnu had not had a f90-f95 compiler, and partly because > of, maybe, a 10% improvement in speed. > > What I find interesting is that both Fedora and Debian have similar > problems for different reasons. Debian has now stable release for > AMD64 because Sarge was released before AMD64 was really ready. This means > that we are all stuck in the beta test-site pool. It would be really nice > if Debian actually packaged up a "stable-like" version of AMD64 at the > same level as Sarge. Fedora has been moving so quickly, that they have > incorporated the same problems into a nominally stable release. http://amd64.debian.net/ http://lists.debian.org/debian-devel-announce/2005/06/msg5.html yours Martin -- <[EMAIL PROTECTED]> Debian GNU/Linux - The Universal Operating System $macht-- * HE .oO(Macht einer weniger?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
Ozzy Lash wrote: On 7/12/06, Art Edwards <[EMAIL PROTECTED]> wrote: The point is that they do not work exactly fine. For ddd, the console at the bottom is dead. The keyboard fails. For grace(xmgrace) the same symptom is present in all text boxes. This appears to be a pretty general problem because the same is true for Fedora Core 5, but not for Fedora Core 4. I have compiled xmgrace from sources and I have the same problem. I have done some looking and this problem surfaced several years ago on a cygwin list. Just for the record, when I invoke xmgrace from the command line, I receive many errors like this: Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: osfHelp I get exactly the same set from ddd. Again, this is true for AMD64 for both Debian and for Fedora Core 5. Art Edwards I did a google search for "Warning: String to TranslationTable conversion encountered errors" and found this link: http://www.ubuntuforums.org/showthread.php?t=82087 With the following suggestion: The answer is: export XKEYSYMDB=/usr/share/X11/XKeysymDB This is also needed to get the grace package to work right on Breezy, BTW. Hope this helps What is that honesty things invading all news group from Debian? Please answer only to the list the mail is originating. On top, I am wondering why we have so many ' tell the truth mail lately. Thierry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
Thanks very much. See below. On Wed, Jul 12, 2006 at 02:54:14PM -0500, Ozzy Lash wrote: > On 7/12/06, Art Edwards <[EMAIL PROTECTED]> wrote: > >The point is that they do not work exactly fine. For ddd, the console at > >the bottom is dead. > >The keyboard fails. For grace(xmgrace) the same symptom is present in all > >text boxes. This appears to be a pretty general problem because the same > >is true for > >Fedora Core 5, but not for Fedora Core 4. I have compiled xmgrace from > >sources and > >I have the same problem. I have done some looking and this problem surfaced > >several years ago on a cygwin list. > >Just for the record, when I invoke xmgrace from the command line, I > >receive many errors like this: > > > >Warning: String to TranslationTable conversion encountered errors > >Warning: translation table syntax error: Unknown keysym name: osfHelp > > > >I get exactly the same set from ddd. Again, this is true for AMD64 for > >both Debian and for Fedora Core 5. > > > > > >Art Edwards > > I did a google search for "Warning: String to TranslationTable > conversion encountered errors" and found this link: > > http://www.ubuntuforums.org/showthread.php?t=82087 > > With the following suggestion: > The answer is: > > export XKEYSYMDB=/usr/share/X11/XKeysymDB This was, indeed, the problem. It arose because my .cshrc file pointed to an older place (/usr/X11R6/lib/X11/XKeysymDB). Again, thanks. Art Edwards > > > This is also needed to get the grace package to work right on Breezy, BTW. > > > Hope this helps > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
Hi, On Wed, Jul 12, 2006 at 01:29:37PM -0600, Art Edwards wrote: > Excuse me for chiming in, but I think many places simply look > for the best performance and productivity/dollar(euro). We do use the PGI > compiler, > mostly because gnu had not had a f90-f95 compiler, and partly because > of, maybe, a 10% improvement in speed. heh, I think that whole choice f90/f95 codes and compilers issue a chicken and egg problem. its probably not a idea to get into any religous discussions on why one should use a certain toolchain to build things. > > What I find interesting is that both Fedora and Debian have similar > problems for different reasons. Debian has now stable release for > AMD64 because Sarge was released before AMD64 was really ready. This means > that we are all stuck in the beta test-site pool. It would be really nice > if Debian actually packaged up a "stable-like" version of AMD64 at the > same level as Sarge. Fedora has been moving so quickly, that they have > incorporated the same problems into a nominally stable release. > To be honest, I find that debian amd64 (sarge) is quite stable, we choose to use it simply because we like debian and what apt-get has to offer. In terms of building a compute cluster using debian amd64 (sarge) it's certainly a risk since its a release candidate rather than what debian stable is typically like. I guess if you find packages to be broken or dont work as expected, do as other have suggested on these lists, report the bugs, or fix them yourself and submit the fix to someone so that it gets to become stable quicker :) Jimm -- Jimmy Tang Trinity Centre for High Performance Computing, Lloyd Building, Trinity College Dublin, Dublin 2, Ireland. http://www.tchpc.tcd.ie/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
I posted the same initial message on the three sites I thought were appropriate. My plea for honesty was a measure of frustration with what should be well-established packages. It turns out that in the newer distros, the structure of /usr/X11R6 has changed dramatically enough that it broke a .cshrc file that had worked for five years. Art Edwards On Wed, Jul 12, 2006 at 10:18:40PM +0200, Thierry Chatelet wrote: > Ozzy Lash wrote: > >On 7/12/06, Art Edwards <[EMAIL PROTECTED]> wrote: > >>The point is that they do not work exactly fine. For ddd, the console > >>at the bottom is dead. > >>The keyboard fails. For grace(xmgrace) the same symptom is present in > >>all > >>text boxes. This appears to be a pretty general problem because the > >>same is true for > >>Fedora Core 5, but not for Fedora Core 4. I have compiled xmgrace > >>from sources and > >>I have the same problem. I have done some looking and this problem > >>surfaced > >>several years ago on a cygwin list. > >>Just for the record, when I invoke xmgrace from the command line, I > >>receive many errors like this: > >> > >>Warning: String to TranslationTable conversion encountered errors > >>Warning: translation table syntax error: Unknown keysym name: osfHelp > >> > >>I get exactly the same set from ddd. Again, this is true for AMD64 > >>for both Debian and for Fedora Core 5. > >> > >> > >>Art Edwards > > > >I did a google search for "Warning: String to TranslationTable > >conversion encountered errors" and found this link: > > > >http://www.ubuntuforums.org/showthread.php?t=82087 > > > >With the following suggestion: > >The answer is: > > > >export XKEYSYMDB=/usr/share/X11/XKeysymDB > > > > > >This is also needed to get the grace package to work right on Breezy, > >BTW. > > > > > >Hope this helps > > > > > What is that honesty things invading all news group from Debian? > Please answer only to the list the mail is originating. On top, I am > wondering why we have so many ' tell the truth mail lately. > Thierry > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Erast Benson <[EMAIL PROTECTED]> wrote: > On Wed, 2006-07-12 at 01:02 +0100, Matthew Garrett wrote: >> 1) The GPL requires that all scripts used to control compilation and >> installation of the executable be released under terms compatible with >> the GPL. > > Joerg clearly stands that: > > 1) Makefiles != scripts or at least it is unclear whether Makefiles may > be called "scripts": At that point we start getting into semantic arguments that are basically uninteresting to anyone other than a judge (and possibly not even then). As copyright holder, if this is Joerg's opinion, he can add an exception to the license that avoids the problem entirely. > This means in other words: If I take other people's GPL code and create > a "derived work" from that code, I need to make the whole work available > under GPL. I do not need to make non-GPL code available at all, if GPL > code is derived on that code. I do not need to make the build system > available under GPL (GPL §3 requires me to make it available but does > not mention a license) and the build system is not code that is > "derived" from the GPLd project.""" It's an interesting arugment But, again, this is semantic bickering and entirely unnecessary - if Joerg is copyright holder, he can ensure that the license reflects his opinion. > The key point is: GPL is pure source license. It does not explicitly > require you to use a specific license for the binary in case you make > the source available. Can I suggest you read section 2(b)? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378046: ITP: libmail-dkim-perl -- Create and verify DKIM (DomainKeys Identified Mail) signatures
Package: wnpp Severity: wishlist Owner: Magnus Holmgren <[EMAIL PROTECTED]> * Package name: libmail-dkim-perl Version : 0.18 Upstream Author : Jason Long <[EMAIL PROTECTED]> * URL : http://jason.long.name/ * License : "Same as Perl" Programming Lang: Perl Description : Create and verify DKIM (DomainKeys Identified Mail) signatures DomainKeys Identified Mail (DKIM) provides a method for validating an identity that is associated with a message, during the time it is transferred over the Internet. That identity then can be held accountable for the message. See http://www.dkim.org/ This is a Perl implementation created by Jason Long of Messiah College. It performs signing as well as signature verification. The library is largely based on Mail::DomainKeys. For those who don't know, DKIM is a merge of Yahoo!'s [1]DomainKeys and Cisco's [2]Internet Identified Mail. An IETF [3]working group has been chartered with the goal of creating standards-track specifications. Because of Yahoo!'s DomainKeys patents, they have made the following IPR disclosure: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=716 where they repeat the statement from [1] that they license the Necessary Patent Claims under either of the DomainKeys Patent License Agreement (v1.2) and the GPL v2.0. We need to determine exactly what it means to license patents under the GPL. [1] http://antispam.yahoo.com/domainkeys [2] http://www.identifiedmail.com/ [3] http://ietf.org/html.charters/dkim-charter.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
