Re: gnome-swallow_1.2-2_source.changes REJECTED
On Fri, Nov 11, 2005 at 12:18:00AM +0100, Joerg Jaspert wrote: On 10469 March 1977, Josselin Mouette wrote: I can't see the rationale for rejecting source uploads, and they used to be accepted in the past. Because people then fuck up their packages even more. No, they havent been accepted in the past. Ubuntu does that, Debian not. They were accepted by katie in the past, but strongly discouraged by the i386 buildd admin. Been there, done that. Nowadays, I think that pbuilder and friends have mostly alleviated the need for source-only uploads, but Josselin seems to disagree. Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debconf problem
Joey Hess [EMAIL PROTECTED] wrote: Frank Küster wrote: Because it isn't true that the previous version didn't use debconf. It just asked the questions totally differently and took an approach that I now would call flawed. But still it gave the users the impression that their ls-R files' permissions are managed by debconf, and probably many thought they were properly managed and didn't do any manual changes. Well, assuming that your debconf questions are different from the ones it asked before, this is the same as not having had questions before. Consider what I've said before to operate on a per-question basis. (In other words, I'm suggesting that you rename your questions and ask the new ones on upgrade from the broken versions of the package.) In the previous mail, I understood you suggested to not at all ask questions on upgrade: , | Your package is being converted from a previous version, which did not | use debconf and did have the files, to a version which does use debconf. | So why ask the question on upgrade from this previous version at all? ` So I'm confused. The parameters passed to the config script can be used to detect the upgrade and not ask any questions or populate the debconf database at all, while leaving debconf asking the question on fresh installs and when reconfigured. Oh, but that seems very hard to do right: The only way to differentiate between an upgrade and reconfigure seems to be the version number of the last installed version. No, in an upgrade, $2 is configure, for a reconfigure $2 is reconfigure. Stupid me, I can't read. But since one could install the package noninteractively, but switch to an interactive frontend before an upgrade, I would have to avoid asking questions for *any* last-installed version number older than the current one (if I decide not to ask and act at all upon upgrade). Only if the noninteractive install ran with DEBCONF_NONINTERACTIVE_SEEN not set to true. Not setting that to true by default is agruably a bug in debconf since it does lead to this edge condition, but it's not an edge case I would worry about dealing with in your package. Okay, thanks - is this variable documented anywhere? Things getting clearer, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Licenses for DebConf6
It's not all that unusual for conferences to require that the material submitted for the conference be licensed in a specific manner; if you plan on presenting, some DFSG free license of the material you present should be expected so portions of the work can be utilized in main or otherwise distributed by Debian if desired. [If this poses a problem,[1] you always have the option of not presenting, or presenting your work in an informal session.] On Fri, 11 Nov 2005, Anthony Towns wrote: Of course, DFSG-free isn't all the dc6 organisers are insisting on, but the right to MIT/X11 recordings of presentations too -- not even giving presenters the option to copyleft the recording of their presentation for some reason. This is primarily pragmatic, since there's no clear consensus on what the prefered form for modification for a video is, or even what it means to copyleft a video. [If you have a clear idea of what it means, you could communicate it to the organizers...] Don Armstrong 1: I'd be rather surprised if it did; but then again, I've been suprised before. -- Any excuse will serve a tyrant. -- Aesop http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Resignation and orphan list
[Chip Salzenberg] I see no point in trying to force my way (back) into a project that shows no interest in allowing me to keep participating. Therefore, I hereby resign from the Debian Project. Please, do not do this. The project is to large and fuzzy to have any interest, but there are several developers and members of the project who have interest in fixing the flaws and problems within the Debian project and I am one of these. Packing up and leaving just because a few vital bottlenecks haven't been dealt with in Debian is not a solution. If the keyring maintainer is too busy to do updates in a timely manner, we need to reinforce that part of the project by putting more people on the task. I hope the DPL team is able to put some focus on this, to solve it quickly, unless James Troup find assistants with more time himself. Your report is not the first one regarding slow keyring updates, so I know you are not alone here. We need to work together to solve the problems in Debian. Leaving in anger do not help much. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#338503: ITP: cvssuck -- inefficient cvs repository grabber using cvs command
also sprach Piotr Roszatycki [EMAIL PROTECTED] [2005.11.10.1908 +0100]: CVSsuck is a mirroring tool for CVS repositories. Unlike other tools such as CVSup or rsync, it uses cvs command to access the repository. So, it works well with remote repositories without a special server or shell account. However it is inefficient and not perfect because CVS client/server protocol is not designed for mirroring. If a server provides special way to grab a repository, you shouldn't use CVSsuck. Sounds like this is best kept out of the archive then... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! it has been said that there are only two businesses that refer to customers as users: illegal drug trade and the computer industry. signature.asc Description: Digital signature (GPG/PGP)
Re: Shall Debian's su conform to other implementations
On Sun, Nov 06, 2005 at 11:14:39PM +0100, Nicolas Fran?ois wrote: Hi, In #276419, the bug submitter complained that when a command and some arguments were passed to su, all these arguments were concatenated, and provided to the shell -c option. This behavior differs from su on other systems [0]. This also forbid to pass arguments to the shell [1]. As these behaviors where not documented in the man page, in the code or in the changelog, we uploded 4.0.3-36 to fix this bug. Unfortunately, this broke pbuilder (see #317264), and other Debian packages (e.g. dchroot). So this patch was (at least temporarily) removed, and the current behavior documented. Whatever you choose to do, you need to take care of partial upgrade. Given than login is an essential package, the only sane way is to change all package in Debian to use a syntax that work with both old and new su, wait for the release, and then upload new su. e.g. you cannot fix Sarge pbuilder anyway, so etch su must work with sarge pbuilder. That why it would have been better to announce the change before Sarge release. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages file missing from unstable archive
On Fri, 11 Nov 2005 14:51:30 +1000 Anthony Towns aj@azure.humbug.org.au wrote: Anyway, if it's recompressing like I think, there's no way to get the same compressed md5sum -- even if the information could be transferred, there's no guarantee the local gzip _can_ produce the same output as the remote gzip -- imagine if it had used gzip -9 and your local gzip only supports -1 through -5, eg. We could just mandate in policy that what the gzip level is supposed to be. If we're going to do that, it's probably easier to just use --rsyncable and teach zsync to do look-in-ar instead of look-in-gz. Also we wouldn't have the md5sum problem on the data.tar.gz then. Note that I haven't tested the efficiency of --rsyncable... grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome-swallow_1.2-2_source.changes REJECTED
Le vendredi 11 novembre 2005 à 00:55 +0100, Bernd Eckenfels a écrit : In article [EMAIL PROTECTED] you wrote: Why is this the case ? I'm running with experimental GNOME packages; if I upload a binary package depending on them, it will be uninstallable on unstable systems. How can you test your packages if you dont build them? I can test the version I have built against experimental GNOME libraries. They don't differ much from unstable ones, but the shlibs were bumped. For me, it's exactly similar to the fact I can't test packages on architectures other than mine. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: gnome-swallow_1.2-2_source.changes REJECTED
On 11/10/05, Peter Samuelson [EMAIL PROTECTED] wrote: [Josselin Mouette] I can't see the rationale for rejecting source uploads, and they used to be accepted in the past. It's the first line of defense against people uploading things that don't build, wasting various infrastructure resources. Shouldn't that be dealt with by having the infrastructure first deal with packages that have already been build on other architectures? Perhaps what you need is for someone to set up an autobuilder queue that doesn't upload packages but just returns them to you somehow, with logs, so you can sign and upload yourself. Of course this autobuilder queue should be under control of Debian developers, lest we have another round of flames about uploading untrusted binaries. I think it has been suggested before to simply route the uploaded binaries to /dev/null and rebuild anyway.
Re: Resignation and uploads
On Thu, Nov 10, 2005 at 04:22:39PM -0800, Chip Salzenberg wrote: Bill Allombert [EMAIL PROTECTED] writes: There are around 1000 developers out there. At the very least I am sure you would find several of them willing to sponsor your upload. That's not a fix, it's a bad workaround. I was a DD. I should have been sponsoring uploads for other people, not trolling for sponsors. This is not a fix but it make it unfair to say that we are a project that shows no interest in allowing me to keep participating. Anyway, I hope you will be back in the project soon! Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Shall Debian's su conform to other implementations
On Fri, 11 Nov 2005, Bill Allombert wrote: Whatever you choose to do, you need to take care of partial upgrade. Not across released stable versions! Since when do we support stable/stable+1 mixed systems? Besides, depends/pre-depends and conflicts should be more than enough if done right. New shadow would conflict with ALL packages that do not support the new syntax (yes, it is a pain to list them. Maybe conflicting with *ALL* packages that use su is a better idea). And all updated packages (that use su) MUST depend/predepend on the new package providing su. Yes, that would be a su transition. Urgh. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome-swallow_1.2-2_source.changes REJECTED
[Brian Nelson] Oh, so Ubuntu packages are fucked up more by their maintainers more than Debian packages are? Yes, or so it's been alleged. Not being a user of ubuntu unstable, I can't confirm or deny. signature.asc Description: Digital signature
Re: Packages file missing from unstable archive
On Tue, Nov 01, 2005 at 09:54:09AM -0500, Michael Vogt wrote: A problem is that zsync needs to teached to deal with deb files (that is, that it needs to unpack the data.tar and use that for the syncs). [Anthony Towns] That seems kinda awkward -- you'd need to start by downloading the ar header, working out where in the file the data.tar.gz starts, then redownloading from there. I guess you could include that info in the .zsync file though. Right, the latter. Having downloaded the .zsync file, you calculate your local checksums against the ones in that file and you know exactly what's left to be downloaded and what to do with it. The .zsync file includes a sort of map of the structure of the target, not unlike a jigdo file. OTOH, there should be savings in the control.tar.gz too, surely -- it'd change less than data.tar.gz most of the time, no? He was only comparing data.tar.gz because that made for a simpler mock-up. zsync doesn't currently dig into a .deb at all, so this was just a simulation, as it were. Hrm, thinking about it, I guess zsync probably works by storing the state of the gzip table at certain points in the file and doing a rolling hash of the contents and recompressing each chunk of the file I haven't actually looked at the implementation of zsync, but I've always assumed that zsync assumes a homogeneous (i.e., predictable) gzip algorithm everywhere, works out the known variables by trial and error, and stores the appropriate amount of state to reproduce the gzip file exactly, given the assumptions about the gzip implementation. For that to be correct assumes a certain homogeneity of the zlib used by zsync implementations; for it to be efficient assumes the same about whatever is used to compress files in gzip format. I've always harbored my doubts about the deployment scalability of this approach. Anyway, just because you get a different file, that doesn't mean it'll act differently; so we could just use an authentication mechanism that reflects that. That might involve providing sizes and sha1s of the uncompressed contents of the ar in the packages file, instead of the md5sum of the ar. Authenticating uncompressed content is a good design choice anyway. Makes it easier, for instance, to add gpg signatures inside the ar file, without invalidating existing checksum authentication. Conceptually, authenticating content based on a container which is essentially nondeterministic is a bit like refusing to authenticate a person because he or she is wearing different clothes from the ones noted in the auth database. signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Fri, Nov 11, 2005 at 03:26:58PM +1000, Anthony Towns wrote: Why fight at all? If having a free license is so obviously correct, why force people to do it? If some people are uncomfortable with it, why fight that? Even within Debian, it's become clear to me that, if we want DFSG-free things, it has to be mandatory and enforced, since there are people in Debian who care about the create a good operating system part, but less about the create a free operating system detail[1]. My point was that this isn't a big fight: these are papers, typically written by one person, who is probably in all cases immediately, easily contactable; not software with dozens of copyright holders, or written by companies feeling their commercial interests threatened. Compared to the battles underlying a lot of attempts to get free licenses, this is easy. I don't mean that it's obviously correct in the sense that people will do it anyway or agree without a debate. Both the documentation should be free threads and the firmware threads, among others, have shown me that no matter how obvious it may seem to me that something should be free, people will disagree. :) BTW, a question: if you say you must make your stuff DFSG-free, aren't you inspiring debate from people who don't want to, or who aren't comfortable with that, on why the DFSG isn't appropriate? If you made it optional or encouraged instead of compulsory, wouldn't that encourage debate on why the DFSG is good in the specific instances where people choose not to use free licenses? Wouldn't that be better? All it's doing is shifting who has to start the debate: in the optional case, the people who think all of the papers should be free will debate the cases that weren't; and in the compulsory case, the people who think papers shouldn't have to be free will debate theirs. Both of these are after the fact. What should happen is what is happening: debate the issue in advance, and make a decision based on that. [1] To be clear, I'm not thinking of anyone in this conversation. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-shadow-devel] Bug#276419: [Pbuilder-maint] Shall Debian's su conform to other implementations
Hi, We would now like to get rid of this bug. What do you recommend: * keep a Debian specific implementation and tag this bug wontfix * reapply the patch to fix this bug, and report bugs on the packages that uses this feature Could you document and wait until etch release? Etch release? We already delayed this for sarge release.then tried to fix it (badly as you know). I don't want bug reports rotting in the BTS. I have no idea of the shadow devel team healt in more than 1 year and I prefer we fixed as many bugs as possible while we can. Are these changes *that* invasive for pbuilder? The ideal way to approach this is to announce a change, document that change, provide some environmental variable support for that change (like POSIXLY_CORRECT) Then change. We've got quite a bit of tools in sarge that doesn't work with this change, right? regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#276419: [Pkg-shadow-devel] Bug#276419: [Pbuilder-maint] Shall Debian's su conform to other implementations
The ideal way to approach this is to announce a change, Which is what we are doing now. We neglected to do so the first time (mostly because we didn't anticipate this would break pbuilder so much) and this is why we reverted the change very quickly. document that change, provide some environmental variable It will be documented. We have a ready document, written by the original bug reporter, which documents the changes and gives recommendations for fixing affected usage of su. We didn't want to send it now because it's a long and deeply technical document and we first wanted to get input from people, like you, who are already aware of the issue. support for that change (like POSIXLY_CORRECT) Then change. We've got quite a bit of tools in sarge that doesn't work with this change, right? From what Nicolas investigated, not that much. He only found dchroot and pbuilder up to now. Nicolas does not pretend to have a complete investigation but I trust him when he mentions he tried as widely as possible. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: altzone
I never got an answer, and when upstream was presented with the problem
OpenSCEP more or less died. Go figure. I lost interest in the packageing
due to this.
Lars, If you ever got an answer to your question below could you
share it with me. I'm trying to compile a mixed fortran C code that
can't find altzone.
Lars Bahner
PS. Your email wound up as junk here. Therefor the late answer.
An ITP has been filed against wnpp that I wish to package OpenSCEP (Bug
#118532). This is a server to help you build scaleable VPNs using Ciscos
Certificate Enrollment Protocol.
This question might be better of at a gcc mailing list, but I will try
here first and apologize for the possible inconvenience.
I have compiled a crippled version (I will explain why) and ran parts og
the enrollment process with success. So the whole suite seems to work fine
and configuration seems correct. The program is crippled as I had to
cripple a function ``asn1_time_to_time'' in order to make the program
compile.
I have tried to compile with both gcc3 and gcc2.95. I have tried different
version of OpenSSL and OpenLDAP (upon which the program relies) with no
result.
The real issue here is that I don't program C, but I will try to explain.
Running make yields the error:
sceplist.o: In function `asn1_time_to_time':
/home/lars/src/openscep-0.3.6/scepd/sceplist.c:127: undefined reference to
`altzone'
Now I gather that ``altzone'' should be declared in /usr/include/time.h
from what I can gather from Google. Furthermore ctime(3) states that
altzone should be present if the system is to be Posix compliant. (Correct
me if I am wrong.).
There is no mention of ``altzone'' in either /usr/lib or /usr/include as
far as I can make out. But the twin variable ``timezone'' is however
declared (in /usr/include/time.h)
So, why twin variable? Well the code in sceplist.c looks like this (with
line 127 marked by me):
--
/* convert ASN1 time string to a struct tm */
static time_t asn1_time_to_time(ASN1_TIME *tm) {
struct tm rtm;
charwork[3];
time_t rt;
extern time_t timezone, altzone;
/* prepare work and result buffers for the conversions */
memset(work, '\0', sizeof(work));
memset(rtm, 0, sizeof(struct tm));
/* convert ASN1 time string to struct tm structure elements*/
memcpy(work, tm-data + 10, 2);
rtm.tm_sec = atoi(work);
memcpy(work, tm-data + 8, 2);
rtm.tm_min = atoi(work);
memcpy(work, tm-data + 6, 2);
rtm.tm_hour = atoi(work);
memcpy(work, tm-data + 4, 2);
rtm.tm_mday = atoi(work);
memcpy(work, tm-data + 2, 2);
rtm.tm_mon = atoi(work);
memcpy(work, tm-data, 2);
rtm.tm_year = atoi(work);
if (rtm.tm_year 70)
rtm.tm_year += 100;
/* set the time zone to GMT, as mktime uses the local time zone*/
[LARS: THIS IS LINE 127] timezone = 0; altzone = 0;
/* use mktime to normalize the structure and t convert to a */
/* time_t value */
rt = mktime(rtm);
/* reset the time zone to local settings*/
tzset();
return rt;
}
--
As you can see for yourself, ``altzone '' is used twice. The first mention
seems to me to be a declaration and the second an assignment.
And well, ... I just don't get it.
The documentation mentions that some compilers might need to be executed as :
``CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure''
But there is no posix library as far as I can make out in Debian, so that
won't do.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Resignation and uploads
Op do, 10-11-2005 te 16:22 -0800, schreef Chip Salzenberg: Bill Allombert [EMAIL PROTECTED] writes: There are around 1000 developers out there. At the very least I am sure you would find several of them willing to sponsor your upload. That's not a fix, it's a bad workaround. Yes, but one that works. [...] Since I sent my resignation mail, I have been told that the keyring was updated twice after my initial request for key change. Why was my key not added? Good question. Here's a thought: You're not the only person requesting key updates, and there's a queue. Probably because there've been issues of higher importance (such as upgrading project machines from Woody to Sarge, or making sure the SPARC and ARM buildd hosts get their logs signed, etc). Since your initial update, James found time to work his way partway through that queue, but hasn't reached the end (or, for that matter, your position in the queue) yet. Oh, and here's something else to ponder: Maybe, just maybe, James has more time to go to Ubuntu below zero than he has to handle keyring updates because he prioritizes by what gets the bills paid. As most of us do, I suppose. Stop whining, please. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: due1ing b4nj0s sheet music
[EMAIL PROTECTED] wrote: I am looking for the sheet music to the song due1ing b4nj0s from the movie deliverance. It's for guitar. Can you tell me where I can find it? Please see (for instance) http://www.cowboylyrics.com/tabs/flatt-and-scruggs/due%6cing-b%61nj%6fs-6185.html http://www.sheetmusicplus.com/pages.html?cart=334068939915374680target=smp_detail.html%26sku%3DMO.MMOCD4401s=pages-wwws.sheetmusicplus.com/e=/sheetmusic/detail/MO.MMOCD4401.htmlt=k=r=wwws-err5 and please read this page for the reason why the first result in Google is not always the one you want: http://www.mirabilis.ca/archives/001399.html regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
Hi, I tried to download and run Live CD but without success. I think that collaboration of enterprise forces of Solaris-security,stable,expandableand usability of Debian platform is great idea. I'm a sys admin in Institute of Computer and Comm. Systems - Bulg. Academy of Science. Ourefforts /may group/ are in computer communications with Win and Unix/Linux platforms from one side. Another mainstreamis collaboration of Unix/Linux/OpenBSD platforms and Cisco equipment and softs - build gateways, firewalls and so on.I want to support Nexenta OS and if you agree with my possibilities, I'm readyto connect with development and test. Regards alexander kemalov
Re: Bug#276419: [Pkg-shadow-devel] Bug#276419: [Pbuilder-maint] Shall Debian's su conform to other implementations
Hi, support for that change (like POSIXLY_CORRECT) Then change. We've got quite a bit of tools in sarge that doesn't work with this change, right? From what Nicolas investigated, not that much. He only found dchroot and pbuilder up to now. Nicolas does not pretend to have a complete investigation but I trust him when he mentions he tried as widely as possible. FWIW, pbuilder in sid is fixed since 0.129 (17 August 2005), and I am hoping that will probagate into some stable backports, so that practically, pbuilder side is ready for the new su. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
getting unstable lintian linda into stable
Hi, It seems that not every new maintainer is building a package on an unstable system which is recommended (or at least a version with the current policy version). So there are errors in packages which come to debian-mentors which are checked with an old version of the debian policy. So what about a special exception which provides updated lintian linda packages for the stable distribution? Is it technical possible? I mean becaused it should be fixed. If not it would be great to add some kind of Warning to the source code which checks the Debian versions and warns the user that it is normally recommended to built on a newer version. Maybe this idea is crap but I think somehow it would be great to wanr users building on stable (not an error because of backports etc.) Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org Forget about that mouse with 3/4/5 buttons - gimme a keyboard with 103/104/105 keys! pgpb2V6iDDmRu.pgp Description: PGP signature
Re: getting unstable lintian linda into stable
Re: Nico Golde in [EMAIL PROTECTED] So what about a special exception which provides updated lintian linda packages for the stable distribution? Is it technical possible? I mean becaused it should be fixed. This doesn't make sense. You need unstable to build on unstable, and only updating lintian and linda doesn't change that. If not it would be great to add some kind of Warning to the source code which checks the Debian versions and warns the user that it is normally recommended to built on a newer version. Maybe lintian could detect if if was running on stable when it should be on unstable, and warn the user. I'm not sure how to do this, since there are legitimate uses on stable where you wouldn't want to get the warning. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Bug#338503: ITP: cvssuck -- inefficient cvs repository grabber using cvs command
Hi, CVSsuck is a mirroring tool for CVS repositories. Unlike other tools such as CVSup or rsync, it uses cvs command to access the repository. So, it works well with remote repositories without a special server or shell account. However it is inefficient and not perfect because CVS client/server protocol is not designed for mirroring. If a server provides special way to grab a repository, you shouldn't use CVSsuck. Sounds like this is best kept out of the archive then... To me it sounded like a pretty good idea, if the server only provides anonymous pserver CVS access. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#276419: [Pkg-shadow-devel] Bug#276419: [Pbuilder-maint] Shall Debian's su conform to other implementations
FWIW, pbuilder in sid is fixed since 0.129 (17 August 2005), and I am hoping that will probagate into some stable backports, so that practically, pbuilder side is ready for the new su. Well, this is actually great news as pbuilder was by far the main blocker for this change. Sorry for having bugged you, then. (removing Junichi and the pbuilder list from CC) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Closing bugs bevore the upload is available
Hi, Today I did a update of the system (yes, sid and yes I know it can be unstable but...) and the update includes grep where no open critical bug was seen. After Boot the system was completely broken as of the libpcre dependency. So please do not close bugs bevore it is available on servers. This break of the system musn't be. Didn't apt-listbugs help you at all ? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request: Source for parts of GNU/Solaris
Anthony: Anthony Towns wrote: On Tue, Nov 08, 2005 at 11:56:32PM -0600, Bill Gatliff wrote: And, I mean, seriously: using the threat of legal action to make people remove free software from the Internet? Whose side are we on here? No. The threat of legal action to stop the theft of Free software. Big difference. First, theft isn't an appropriate term to use about copyright violations -- you're not depriving anyone of their use. Don't buy into the FUD. With all due respect, and a certain unwillingness to get distracted from the main thread of discussion or to further inflame an already pretty volatile situation, I think that theft may in fact be the appropriate term to use here. The copyright holders of GPL works have made clear the terms under which others may use, incorporate or derive from those works. Erast appears to have built and distributed a system that deviates from those terms. He has constructed and subsequently distributed something that's apparently of value to him (otherwise he wouldn't have done it), at the expense of using software that he's not entitled to use for that purpose (as defined by the terms of the GPL, which is the authority granted to him by the copyright holders). Taking something you're not entitled to ~= theft. Honestly, I wouldn't have replied to this at all except that you accused me of buying into the FUD. Just wanted to set the record straight. :) Whether Erast did so with malicious intent, that's another question entirely. And frankly, not one that I care to have answered. I mean, I'm sure Erast is a nice guy and all. But regardless, he's doing what he's doing; why he's doing it, or whether he even knows that what he's doing is wrong, is relatively unimportant. There, I'm all done now. :) b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request: Source for parts of GNU/Solaris
On Friday 11 November 2005 06:48, Anthony Towns wrote: On Thu, Nov 10, 2005 at 06:07:33PM +0100, David Schmitt wrote: [0] Presuming the FSF's claims about dynamic linking hold up in this case, anyway. I consider a Debian-derived distribution a derived work of the contained Debian tools in more ways than mere dynamic linking. That doesn't much matter -- Debian doesn't claim any copyright on its efforts in collecting work, so deriving from Debian doesn't involve any copyrights but that of the aggregate parts you use. The relevant parts are the licenses of individual packages that get linked against OpenSolaris' libc, and whether libc counts as a module [the program] contains and is thus covered as part of the complete source code as part of paragraph 3(a) of the GPL. To be more specific: I don't believe that the fact that software A is being packaged with Debians tools is a derived work of said tools, That's not actually the question -- the only derivative issue is that Nexenta's dpkg (eg) is a derivative of Debian's dpkg (or gcc is a derivative of upstream gcc) and thus covered by the GPL. For those playing along at home, this little exchange contains much of my misunderstanding of GPL-matters. After talking this over with Anthony on IRC, I now understand the whole thing better and will try to explain this in more detail: To decide how far the GPL requirements reach, first I have to disassemble the volume of a storage or distribution medium, since this has no relevance to our question (c.f. mere aggregation). I now have a pool of components (typically files). Those compiled from or consisting of GPL'ed source can obviously be tagged as GPL-requiring. If everyone follows the recommendation of embedding the standard GPL disclaimer in the binary, this is trivial by examining the resultant files. For every component now I have to decide whether it can be reasonably considered independent and separate work in itself. Obvious examples where this is the case include shell scripts being independent from /bin/sh or documentation being independent from everything else. Source archives by far and large[ex] are independent and separate of each other too. In the case of a source-only distribution, my analysis stops here because all components are now identified as independent and separate works which are merely aggregated and the GPL specifically does not apply to this situation. In the case of a binary distribution though, there are components left in the pool which are still to be considered. The interesting case is obviously, when one of those components is tagged as GPL-requiring. Let's consider this dpkg binary from the GNU/Solaris LiveCD, which I have loop mounted: [EMAIL PROTECTED]:/gnusolaris/livecd-mnt/usr/bin$ ./dpkg bash: ./dpkg: No such file or directory [EMAIL PROTECTED]:/gnusolaris/livecd-mnt/usr/bin$ Since the GNU libc I'm running locally is not binary compatible to the Sun libc against which the dpkg binary is linked. This is now the point: the binary is not independent any more and therefore the same sections [are distributed] as part of a whole [(i.e. /usr/bin/dpkg + /lib/libc.so)] which is a work based on the Program, the distribution of the whole must be on the terms of this License. This means that I need a GPL-compatible component in my pool to satisfy (transitively) all NEEDED[od] linkages to satisfy the GPL-requiring components library to the point of distributability. I'd like to add (d) distributing as source only. Compiling the whole thing on the users system Note that compiling Nexenta involves using gcc, so you'd need to cross-compile from a glibc system, or you'd have the same problem in that you'd be distributing libc and gcc (which is GPLed and links to libc) together. If gcc can bootstrap itself on OpenSolaris from their native compiler, this is only a matter of computing power and/or endurance. On other news, private communication by the gnusolaris.org people lead me to the conviction that they are internally working on resolving their problems with the legalese and we should give them a break. I will keep you informed about their progress. Ugh; giving people a break's a good thing, but doing things in private and behind closed doors isn't. Participating in Debian in public can be (unreasonably) rough, but closing yourself up from the community and having communication bottle necks isn't a win either. It was only a small notice, that they are soliciting legal help. I just wanted to demonstrate that they _are_ working on it in - what I believe - good faith and that therefore they should be given more time (you know lawyers) to resolve these problems. On the other hand I also do not want to forget this issue and will followup on it, if I receive no further messages. Everyone else is free to act as dictated by his or her conscience. I hear copyright holders have better leverage then
Re: Shall Debian's su conform to other implementations
e.g. you cannot fix Sarge pbuilder anyway, so etch su must work with sarge pbuilder. That why it would have been better to announce the change before Sarge release. Maybe, but unfortunately, this bug was properly analysed a few weeks *after* sarge release. Remember, there were over 150 opened bugs on shadow when I took it over in March..and I indeed didn't really work on it before May, when the team was set up and ready to work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request: Source for parts of GNU/Solaris
Bill Gatliff writes: With all due respect, and a certain unwillingness to get distracted from the main thread of discussion or to further inflame an already pretty volatile situation, I think that theft may in fact be the appropriate term to use here. Theft, n.: 1. (Law) The act of stealing; specifically, the felonious taking and removing of personal property, with an intent to deprive the rightful owner of the same; larceny. [1913 Webster] 2. The thing stolen. [R.] [1913 Webster] Infringing copyright is not theft, since nothing is removed from its rightful place. Similarly, the purported violation of the GPL in the main thread of discussion does not involve removal of any property. The authors of the GPL made clear what their intent was: to propagate certain freedoms to the users (in practice, recipients) of software, not to preserve anyone's physical property rights. Infringing those copyrights or hoarding those freedoms may be moral or legal wrongs of a degree similar to theft but they are _not_ theft. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getting unstable lintian linda into stable
On Fri, Nov 11, 2005 at 03:28:31PM +0100, Nico Golde wrote: So what about a special exception which provides updated lintian linda packages for the stable distribution? Is it technical possible? I mean becaused it should be fixed. It might not be necessary as an exception: perhaps the rule sets could be provided, in a seperate package, via volatile.debian.net ? If not it would be great to add some kind of Warning to the source code which checks the Debian versions and warns the user that it is normally recommended to built on a newer version. I expect that could be implemented as a rule, and I think on it's own it is a good idea, as I often forget to make sure I'm in an unstable system when building packages. -- Jon Dowland http://jon.dowland.name/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: better init.d/* : who carres ?
On Sat, Aug 27, 2005 at 02:16:39PM -0700, Thomas Bushnell BSG wrote: David Weinehall [EMAIL PROTECTED] writes: And while dash is also optional, all *correctly* written /bin/sh scripts should work with dash too. That's incorrect. A correctly written /bin/sh script is allowed to use Debian programs (including, say, test) and expect to get the Debian versions. Please read the thread on the policy list from quite a while ago. (Sorry for an extremely late reply, found this sorted into the wrong mailbox): test is in /usr/bin/ (together with [), thus at the very least init-scripts cannot rely on behaviour provided by /usr/bin/test, but make do with what /bin/sh provides, which limits you to what POSIX-test (e.g. dash) provides. Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Resignation and uploads
Oh, and here's something else to ponder: Maybe, just maybe, James has more time to go to Ubuntu below zero than he has to handle keyring updates because he prioritizes by what gets the bills paid. As most of us do, I suppose. Yep, this is something I was about to add. Most of us have moments in our Debian lives where our paid work, or other duties in real life, keep our attention derived from our Debian duties. This seems quite similar for James, except that his paid work happens to be working on Ubuntu (at least this is what I'm assuming). So, I actually don't see a difference: James couldn't handle this part of his Debian duty because his paid work grabbed all his attention for a while. From what I know of him, he will take care of these Debian tasks as soon as he'll be able to do sojust like any of us would after coming back from a conference we were at as part of our paid work. This is why I consider a resignation as a bit of overrreaction here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request: Source for parts of GNU/Solaris
Bill Gatliff writes: Taking something you're not entitled to ~= theft. Nothing is being taken. A copyright may be being infringed, but the owner is not being deprived of any property. Whether Erast did so with malicious intent, that's another question entirely. It is not. Theft requires intent as well as deprivation of property. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338635: ITP: kde-style-polymer -- Polymer widget style and kwin decoration for KDE3
Package: wnpp Severity: wishlist Owner: Michael Biebl [EMAIL PROTECTED] * Package name: kde-style-polymer Version : 0.5.5 Upstream Author : Marco Martin [EMAIL PROTECTED] * URL : http://www.kde-look.org/content/show.php?content=27968 * License : GPL Description : Polymer widget style and kwin decoration for KDE3 Widget style and kwin decoration both aim to maintain a good balance between eyecandy and simplicity. Widget style is based on Plastik, window decoration is based on Smoothblend. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.1 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getting unstable lintian linda into stable
Hi! * Nico Golde [EMAIL PROTECTED] [05 15:28]: So what about a special exception which provides updated lintian linda packages for the stable distribution? Is it technical possible? I mean becaused it should be fixed. Curently it's quite easy to run unstables lintian, debootstrap and pbuilder on system running stable for the other packages. So I don't see a big problem creating and testing packages on a stable system. Yours sincerely, Alexander -- http://learn.to/quote/ http://www.catb.org/~esr/faqs/smart-questions.html signature.asc Description: Digital signature
Re: Request: Source for parts of GNU/Solaris
On Fri, Nov 11, 2005 at 10:11:24AM -0600, John Hasler wrote: Bill Gatliff writes: Taking something you're not entitled to ~= theft. Nothing is being taken. A copyright may be being infringed, but the owner is not being deprived of any property. There's something darkly amusing about arguments coming from Free Software people that sound very close to intellectual property. I wonder if people will start suggesting copy protection with DMCA enforcement. :) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338634: ITP: libcommandline-ruby -- Ruby library to building a command
Package: wnpp Severity: wishlist Owner: Esteban Manchado Velázquez [EMAIL PROTECTED] * Package name: libcommandline-ruby Version : 0.7.10 Upstream Author : Jim Freeze * URL : http://rubyforge.org/projects/optionparser/ * License : BSD-style Description : Ruby library for building command-line applications This library greatly simplifies the repetitive process of building a command line user interface for your applications. It's 'ruby-like' usage style streamlines application development so that even applications with numerous configuration options can be quickly put together. CommandLine automatically builds friendly usage and help screens that are nicely formatted for the user. -- 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.12 Locale: [EMAIL PROTECTED], LC_CTYPE=ISO_8859_1 (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED])
Re: getting unstable lintian linda into stable
Op vr, 11-11-2005 te 15:28 +0100, schreef Nico Golde: So what about a special exception which provides updated lintian linda packages for the stable distribution? Doesn't sound like a particularly good idea to me. You need no just unstable's linda/lintian; you also need unstable's libraries to be able to make sure your package will work and build on unstable. There's no way around that; there's way too many libraries that might have their SONAME bumped, way too many packages that might have been split (or merged) so that the packages you need to build-dep on in stable don't exist anymore in unstable (or vice versa), etc. Just including linda/lintian in stable doesn't fix that. If not it would be great to add some kind of Warning to the source code which checks the Debian versions and warns the user that it is normally recommended to built on a newer version. That could work. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request: Source for parts of GNU/Solaris
Glenn: Glenn Maynard wrote: On Fri, Nov 11, 2005 at 10:11:24AM -0600, John Hasler wrote: Bill Gatliff writes: Taking something you're not entitled to ~= theft. Nothing is being taken. A copyright may be being infringed, but the owner is not being deprived of any property. No, the owner hasn't been deprived. But the rights said owner conveyed via the GPL (which amount to some level of ownership, at least philosophically) have been deprived from the GNU/Solaris end users. It's the GNU/Solaris end users who have been stolen from. I'll give up now. Is that dead horse I smell? :) There's something darkly amusing about arguments coming from Free Software people that sound very close to intellectual property. I wonder if people will start suggesting copy protection with DMCA enforcement. :) Yea, what we need here are some software dongles. Free Software dongles. :P (kidding!!) b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Resignation and uploads
On Fri, Nov 11, 2005 at 03:09:22PM +0100, Wouter Verhelst wrote: Op do, 10-11-2005 te 16:22 -0800, schreef Chip Salzenberg: Bill Allombert [EMAIL PROTECTED] writes: There are around 1000 developers out there. At the very least I am sure you would find several of them willing to sponsor your upload. That's not a fix, it's a bad workaround. Yes, but one that works. No. A workaround that works would be a *good* one. This is a *bad* one. It doesn't scale, for one thing. Else, why even have DDs? Just have random people send source packages to one guy with The Debian Key. And for me to update my contact info or change my ssh key, there is no substitute for a key on the keyring. Stop whining, please. *grin* Stop trying to suppress negative commentary, please. -- Chip Salzenberg [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Closing bugs bevore the upload is available
Klaus Ethgen [EMAIL PROTECTED] wrote: Today I did a update of the system (yes, sid and yes I know it can be unstable but...) and the update includes grep where no open critical bug was seen. After Boot the system was completely broken as of the libpcre dependency. So please do not close bugs bevore it is available on servers. This break of the system musn't be. [...] Hello, This is (currently) standard practice and usually[1] there is no manual maintainer action involved. 1. Package uploaded 2. archive software processes the package, including 2a. closing bugs 2b. making it available on incoming.d.o. 3. Only after the next mirror-pulse (which happens up to ~24 hours later) the fixed package will be found by apt-get. As a maintainer I prefer this approach, because I get rather quick feedback after an upload. cu andreas [1] Yes, the grep bug was closed manually, but also only after the fixed package was availale in incoming. -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Resignation and uploads
[Wouter Verhelst] Oh, and here's something else to ponder: Maybe, just maybe, James has more time to go to Ubuntu below zero than he has to handle keyring updates because he prioritizes by what gets the bills paid. As most of us do, I suppose. Yes, most of us have changing priorities, and am not able to follow up all our Debian commitments all the time. I am convinced this is the case with the keyring maintainer James as well, and that he will process the backlog as quickly as he can. But as we know that the priorities changes over time, and that some times real life or other commitments demand our focus from time to time, it is vital to plan and prepare for this, and make sure no privileged position in Debian depends on one persons priorities. And as keyring maintenance is a privileged position (I can not take over immediately it if James is not doing it), we need to make sure the processing of key changes do not stop when James am unable to handle the incoming queue of requests. Do we know how many requests are in the queue? Is the queue growing or shrinking? Is the current processing speed enough to actually empty the queue some time in the future? It would be interesting to know these things, and one way to make it possible for others to monitor the status of the keyring maintenance would be to make sure the processing is transparent. Is it? I do not know, but hope it is. If it isn't, it is very hard for others to take over if James suddenly is unable to process the requests at all. I believe it is important for Debian as a project to make sure the privileged positions have good redundancy. (I call this the bus factor - aka how many will have to be run over by a bus before the project/process/work stops. A bus factor = 1 is very bad. :). At the moment, several of the privileged positions in debian seem to have a very low bus factor, and we should address this as a project to make sure the task being done by the people in these positions do not grind to a complete halt when their real world commitments take too much of their time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request: Source for parts of GNU/Solaris
On Fri, 11 Nov 2005 12:10:06 -0600, Bill Gatliff [EMAIL PROTECTED] said: [...] No, the owner hasn't been deprived. But the rights said owner conveyed via the GPL (which amount to some level of ownership, at least philosophically) have been deprived from the GNU/Solaris end users. It's the GNU/Solaris end users who have been stolen from. I'll give up now. Is that dead horse I smell? :) I don't know, but maybe we should keep beating it until the smell goes away. :) -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFC: drop kerberos4-support?
Hi, while my regular clean up RC-bugs-work I noticed that the package krb4 is RC-buggy in more than one way. On further investigation, I also noticed that kerberos 4 is dying right now, and also that the bugs are not as easy to fix. Also, upstream doesn't look too active according to http://www.pdc.kth.se/kth-krb/. For this reason, I started to consider to push dropping of the krb4-package from unstable. This has some influence on the heimdal-package, and also on the release notes for migration issue. However, I personally tend to go that way. Please see bug #315059 for some discussion; especially, heimdal in experimental stopped to depend on kerberos 4. Well, my question is simple: should I push packages to go away from kerberos-4-support? Unless there is a good reason to do not, I would start to push into that direction. And of course, feel free to send me things that need to be changed. As usual, the maintainers have a special say in everything (that's why I Cced them). :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Resignation and orphan list
On Thu, 2005-11-10 at 15:23 -0800, Chip Salzenberg wrote: Over the past five weeks And guess how long will take to get your account removed. -- David Moreno Garza [EMAIL PROTECTED] | http://www.damog.net/ [EMAIL PROTECTED] | GPG: C671257D Este no es un capricho, es un corazón sincero: Nada más.
Re: better init.d/* : who carres ?
On Fri, 11 Nov 2005, David Weinehall wrote: On Sat, Aug 27, 2005 at 02:16:39PM -0700, Thomas Bushnell BSG wrote: David Weinehall [EMAIL PROTECTED] writes: And while dash is also optional, all *correctly* written /bin/sh scripts should work with dash too. That's incorrect. A correctly written /bin/sh script is allowed to use Debian programs (including, say, test) and expect to get the Debian versions. Please read the thread on the policy list from quite a while ago. (Sorry for an extremely late reply, found this sorted into the wrong mailbox): test is in /usr/bin/ (together with [), thus at the very least init-scripts cannot rely on behaviour provided by /usr/bin/test, but make do with what /bin/sh provides, which limits you to what POSIX-test (e.g. dash) provides. Er, only some such scripts; those that are run before /usr is available(which is a small set). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
testing migration: wtf?
What is happening with testing migration of my package, sork-passwd? The various testing migration pages seem to be all confused: - http://qa.debian.org/developer.php?package=sork-passwd doesn't give me the excuses link anymore - http://bjorn.haxx.se/debian/testing.pl?package=sork-passwd thinks sork-passwd is not in testing, while it is (in an older version), as shown by http://packages.debian.org/sork-passwd . Can somebody explain me what is happening? Thanks. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
On Tuesday 08 November 2005 00:53, Matthew Garrett wrote: On Mon, Nov 07, 2005 at 02:50:01PM -0800, Alex Ross wrote: Here's the 2nd part of the answer: [EMAIL PROTECTED] wrote: The question is, are you going to pursue a legal action against Sun Microsystems? To which my answer was yes. I'm not sure how that's supposed to excuse you in any way. Could you please elaborate why your answer was yes ? Having done that with Companion CD [1] (which is full of mostly GPL software linked against Sun's libc) for Solaris 8/9/10 Sun Microsystems, Inc is perfectly ok (except they calling it wrongly freeware [2]) because of GPL permits that [3][4]. That is not the problem (that's GPL being smart here), the problem is that I doubt CDDL 1.0 can satisfy Debian free software principles and rules, thus I doubt gnusolaris can be part of the Debian project, except if the copyright holders re-think the license of its the codebase and relicensed it as well. [1] http://www.sun.com/software/solaris/freeware/ [2] http://www.gnu.org/philosophy/categories.html#freeware [3] http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs [4] http://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs [5] http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible P.S. I'd like to apologize being too impatient and replying to previous messages on that thread which have been already replied but missed by myself. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
Andreas Barth [EMAIL PROTECTED] writes: Well, my question is simple: should I push packages to go away from kerberos-4-support? Unless there is a good reason to do not, I would start to push into that direction. And of course, feel free to send me things that need to be changed. As usual, the maintainers have a special say in everything (that's why I Cced them). :) I think it's time to encourage maintainers to start thinking about this, as the next major release of MIT Kerberos is also going to drop Kerberos v4 support as of May of 2006. Kerberos 4 support will still be there in the MIT package until at least that time, and there are some sites who are still in the process of transitioning away, so I wouldn't want to see too many things disappear too quickly, but it's certainly time to think about how to drop it over time. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
Andreas == Andreas Barth [EMAIL PROTECTED] writes: Andreas Hi, while my regular clean up RC-bugs-work I noticed Andreas that the package krb4 is RC-buggy in more than one Andreas way. On further investigation, I also noticed that Andreas kerberos 4 is dying right now, and also that the bugs are Andreas not as easy to fix. Also, upstream doesn't look too Andreas active according to http://www.pdc.kth.se/kth-krb/. For Andreas this reason, I started to consider to push dropping of Andreas the krb4-package from unstable. This has some influence Andreas on the heimdal-package, and also on the release notes for Andreas migration issue. However, I personally tend to go that Andreas way. Please see bug #315059 for some discussion; Andreas especially, heimdal in experimental stopped to depend on Andreas kerberos 4. Not only that, but it conflicts with key krb4 libraries (libroken and libsl) IIRC. Andreas Well, my question is simple: should I push packages to go Andreas away from kerberos-4-support? Unless there is a good Andreas reason to do not, I would start to push into that Andreas direction. And of course, feel free to send me things Andreas that need to be changed. As usual, the maintainers have a Andreas special say in everything (that's why I Cced them). :) Ideally I thin the krb4 maintainer should have same say. However I haven't heard from him. I think there several things I want to do before uploading Heimdal to unstable as it is in experimental: * Find out what packages will break. * Find out what packages will still be broken even after recompiling. * Find out what is required to keep AFS support working (assuming I don't already have it). -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338657: ITP: Buoh -- Buoh is a reader for online strips comics, designed to work well under the GNOME Desktop
Package: wnpp Severity: wishlist Owner: borg [EMAIL PROTECTED] * Package name: Buoh Version : 0.8 Upstream Author : * URL : http://buoh.steve-o.org/ * License : GPL Description : Buoh is a reader for online strips comics, designed to work well under the GNOME Desktop (Include the long description here.) -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Determining a .deb's intended Debian Version
Suppose you have a repository stuffed full of binary packages, in this case Debian Packages. If you were unlucky enough to have them in a rather un-organized fashion, I was just wondering if the package file itself would provide said information to allow me to write a program to sort them out. -- christopher Marc 'HE' Brockschmidt wrote: Christopher Crammond [EMAIL PROTECTED] writes: I was wondering if someone could provide me with some additional information related to Debian packaging. Specifically, I would like to know if there is a way to determine which version of Debian that a package belongs to? No. Almost all packages in stable have been uploaded to unstable, were migrated to testing and then were released as stable. We would have to do new uploads for each of these transitions to keep such a field updated. Why do you need it, anyway? Marc !DSPAM:4373032e716371204020884! -- Christopher Crammond, Software Engineer Open Country, Inc. [EMAIL PROTECTED] 650.591.8080 ext 246
Re: Determining a .deb's intended Debian Version
Hi, Christopher Crammond Christopher Crammond [EMAIL PROTECTED]: Suppose you have a repository stuffed full of binary packages, in this case Debian Packages. If you were unlucky enough to have them in a rather un-organized fashion, I was just wondering if the package file itself would provide said information to allow me to write a program to sort them out. You are looking for apt-move. Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * COMTEC in Dresden, 09. - 11. November 2005 * Info: http://www.messe-comtec.de/ * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getting unstable lintian linda into stable
On Fri, Nov 11, 2005 at 03:28:31PM +0100, Nico Golde wrote: [...] So what about a special exception which provides updated lintian linda packages for the stable distribution? Is it technical possible? I mean becaused it should be fixed. That's imho wrong idea because of at least one very important reason. Let's say that policy of unstable has changed and now it is required to put some kind of binaries in /foo/bar/, and lintian warns if you're going to put them in other place. It's possible that stable distribution even doesn't contain /foo/bar/ directory or some other needed tool which are now required in unstable. regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: Request: Source for parts of GNU/Solaris
On Fri, Nov 11, 2005 at 05:18:09PM +1000, Anthony Towns wrote: On Wed, Nov 09, 2005 at 01:40:27PM -0600, Kenneth Pronovici wrote: On Wed, Nov 09, 2005 at 02:53:01PM +1000, Anthony Towns wrote: On Tue, Nov 08, 2005 at 08:55:41PM -0600, Kenneth Pronovici wrote: many of Erast's responses were at best antagonistic, and at worst showed a complete disregard for what Debian is all about. Speaking of antagonistic... Huh? Kenneth's responses have ranged from being dismissive to hostile. That would be antagonistic in that: * it makes the problem overly personal -- I'd be making you, personally, out to be the problem rather than saying your arguments or claims are wrong and should be abandoned; * it's overly critical -- portions of your responses might have been dismissive or the OpenSolaris guys' work, and it might've been possible to interpret your responses in a hostile manner, but that doesn't mean such an interpretation is correct or the most important aspect of your mails; * it's also blatantly dishonest -- not all of your mails have been dismissive to hostile. The latter's the case for Erast too -- take [0] eg, which doesn't seem remotely antagonistic, let alone showing a complete disregard for what Debian is all about. Well, yes, but my statement wasn't that broadly worded - note I said many of Erast's responses not just Erast's responses. Perhaps the word many is an overly broad characterization, but there were quite a few, especially in the part of the thread I originally replied to (which is why I replied to him in the first place). Anyway, I don't feel we need to go into this any deeper. I understand the point you're trying to make. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: RFC: drop kerberos4-support?
Brian May [EMAIL PROTECTED] writes: * Find out what is required to keep AFS support working (assuming I don't already have it). Well, what sort of AFS environment? The answer is different if you mean AFS using kaserver than if you mean AFS using krb524 or native K5. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
* Russ Allbery ([EMAIL PROTECTED]) [05 21:47]: Andreas Barth [EMAIL PROTECTED] writes: Well, my question is simple: should I push packages to go away from kerberos-4-support? Unless there is a good reason to do not, I would start to push into that direction. And of course, feel free to send me things that need to be changed. As usual, the maintainers have a special say in everything (that's why I Cced them). :) I think it's time to encourage maintainers to start thinking about this, as the next major release of MIT Kerberos is also going to drop Kerberos v4 support as of May of 2006. Kerberos 4 support will still be there in the MIT package until at least that time, and there are some sites who are still in the process of transitioning away, so I wouldn't want to see too many things disappear too quickly, but it's certainly time to think about how to drop it over time. You think that December 2006 (the expected release time of etch) is too early to drop Kerberos 4? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome-swallow_1.2-2_source.changes REJECTED
El jue, 10-11-2005 a las 23:43 +0100, Josselin Mouette escribió: Le jeudi 10 novembre 2005 à 23:00 +0100, Adeodato Simó a écrit : * Josselin Mouette [Thu, 10 Nov 2005 22:45:20 +0100]: (And don't tell me to use pbuilder, I don't have the disk space nor the bandwidth for it.) Why bandwidth? Several systems exist to cache debs so they don't have to be fetched from the net each time they're used (apt-cacher, apt-proxy, or even a shared /var/cache/apt/archives). And here comes the lack of disk space... Sorry, Joss, but I can't believe disk space can be a problem nowadays. Of course you can be short of disk space, but a 160GB HDD is quite affordable, and you can cache Debian lot of times there. Cheers, -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: RFC: drop kerberos4-support?
Andreas Barth [EMAIL PROTECTED] writes: You think that December 2006 (the expected release time of etch) is too early to drop Kerberos 4? I'm not sure. I think it's going to be tight for some people, but on the other hand not shipping etch with MIT Kerberos 1.5 is not exactly appealing. I expect, though, that Stanford will be in a situation where that will be fine with us by December, and we're historically one of the slower sites to migrate, so maybe it will be okay. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
* Russ Allbery ([EMAIL PROTECTED]) [05 23:26]: Andreas Barth [EMAIL PROTECTED] writes: You think that December 2006 (the expected release time of etch) is too early to drop Kerberos 4? I'm not sure. I think it's going to be tight for some people, but on the other hand not shipping etch with MIT Kerberos 1.5 is not exactly appealing. I expect, though, that Stanford will be in a situation where that will be fine with us by December, and we're historically one of the slower sites to migrate, so maybe it will be okay. On the other hand, sarge will be supported till December 2007, so this should give enough time for migration, provided we warn of this scenario properly. But perhaps it's better to reconsider it again, as we have enough time to decide. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getting unstable lintian linda into stable
Hi, * Wouter Verhelst [EMAIL PROTECTED] [2005-11-11 23:41]: Op vr, 11-11-2005 te 15:28 +0100, schreef Nico Golde: So what about a special exception which provides updated lintian linda packages for the stable distribution? Doesn't sound like a particularly good idea to me. You need no just unstable's linda/lintian; you also need unstable's libraries to be able to make sure your package will work and build on unstable. There's no way around that; there's way too many libraries that might have their SONAME bumped, way too many packages that might have been split (or merged) so that the packages you need to build-dep on in stable don't exist anymore in unstable (or vice versa), etc. Just including linda/lintian in stable doesn't fix that. [...] Yes you are right. Should I file a wishlist bug against linda and lintian to answer for the described warning procedure? Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org Forget about that mouse with 3/4/5 buttons - gimme a keyboard with 103/104/105 keys! pgpttGsaEbsmG.pgp Description: PGP signature
Re: Debian based GNU/Solaris: pilot program
On Friday 11 November 2005 21:19, George Danchev wrote: On Tuesday 08 November 2005 00:53, Matthew Garrett wrote: On Mon, Nov 07, 2005 at 02:50:01PM -0800, Alex Ross wrote: Here's the 2nd part of the answer: [EMAIL PROTECTED] wrote: The question is, are you going to pursue a legal action against Sun Microsystems? To which my answer was yes. I'm not sure how that's supposed to excuse you in any way. Could you please elaborate why your answer was yes ? Having done that with Companion CD [1] (which is full of mostly GPL software linked against Sun's libc) for Solaris 8/9/10 Sun Microsystems, Inc is perfectly ok P.S. I'd like to apologize being too impatient and replying to previous messages on that thread which have been already replied but missed by myself. Take a look at Anthonys mail and my reply, which explore this issue: http://lists.debian.org/debian-devel/2005/11/msg00753.html Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Resignation and orphan list
David Moreno Garza [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Thu, 2005-11-10 at 15:23 -0800, Chip Salzenberg wrote: Over the past five weeks And guess how long will take to get your account removed. Hmm... Doesn't a resignation require a message signed with a key on the keyring? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request: Source for parts of GNU/Solaris
On Friday 11 November 2005 19:36, Erast Benson wrote: On Friday 11 November 2005 06:48, Anthony Towns wrote: Let's consider this dpkg binary from the GNU/Solaris LiveCD, which I have loop mounted: [EMAIL PROTECTED]:/gnusolaris/livecd-mnt/usr/bin$ ./dpkg bash: ./dpkg: No such file or directory [EMAIL PROTECTED]:/gnusolaris/livecd-mnt/usr/bin$ Since the GNU libc I'm running locally is not binary compatible to the Sun libc against which the dpkg binary is linked. This is now the point: the binary is not independent any more and therefore the same sections [are distributed] as part of a whole [(i.e. /usr/bin/dpkg + /lib/libc.so)] which is a work based on the Program, the distribution of the whole must be on the terms of this License. David, [Running this dpkg binary on Solaris 8 through 11 would work, it is therefore independent] Erast [First please be advised that I will copy further private communications from you verbatim to public mailinglists as I feel necessary to facilitate the public discussion about this.] We can agree that dpkg is as independent as other linked binaries, which can be run on Solaris and OpenSolaris and your distribution. What I don't think, is that this is independent enough. Being able to run the dpkg binary on a older version of the same library doesn't change the requirements when they are distributed together. For me, this sounds similar to saying that trains are independent of tracks because they can drive on german and austrian tracks. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: device nodes with udev?
Peter == Peter Samuelson [EMAIL PROTECTED] writes: Peter [Miles Bader] I'd say so. Or fix the bug. Peter Kind of quick and dirty, and not particularly tested, since Peter I don't actually know how to use ttysnoop. Peter But it's a proof of concept of how easy it is to add unix98 Peter pty support to an app Damn! Can't I just complain and wine about one broken package in Debian without it immediately being fixed grin. Maybe if I mention bug #13180 that will get fixed too ;-). I don't think it should be too hard, I suspect the package needs to be changed to use the wtmp API in libc6 (assuming my memory is correct and such an API exists). -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Closing bugs bevore the upload is available
Junichi == Junichi Uekawa [EMAIL PROTECTED] writes: Junichi Hi, Today I did a update of the system (yes, sid and yes I know it can be unstable but...) and the update includes grep where no open critical bug was seen. After Boot the system was completely broken as of the libpcre dependency. So please do not close bugs bevore it is available on servers. This break of the system musn't be. Junichi Didn't apt-listbugs help you at all ? AFAIK apt-listbugs only displays open bugs, if the bug is closed then it won't get displayed. Ideally apt-listbugs needs to be updated to support the new versioning system in the BTS. This could also solve the issue that the mirror you use might be out-of-date and still have a buggy package that is fixed on the master server. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: drop kerberos4-support?
On Fri, Nov 11, 2005 at 11:19:07PM +0100, Andreas Barth wrote: * Russ Allbery ([EMAIL PROTECTED]) [05 21:47]: Andreas Barth [EMAIL PROTECTED] writes: Well, my question is simple: should I push packages to go away from kerberos-4-support? Unless there is a good reason to do not, I would start to push into that direction. And of course, feel free to send me things that need to be changed. As usual, the maintainers have a special say in everything (that's why I Cced them). :) I think it's time to encourage maintainers to start thinking about this, as the next major release of MIT Kerberos is also going to drop Kerberos v4 support as of May of 2006. Kerberos 4 support will still be there in the MIT package until at least that time, and there are some sites who are still in the process of transitioning away, so I wouldn't want to see too many things disappear too quickly, but it's certainly time to think about how to drop it over time. You think that December 2006 (the expected release time of etch) is too early to drop Kerberos 4? Note that dropping the krb4 source package does not require dropping Kerberos 4 support from the MIT Kerberos packages, either; and as the MIT Kerberos version doesn't seem to have any RC bugs at present regarding the status of its Kerberos 4 support, there doesn't seem to be any reason to cut it before upstream does. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Fri, 11 Nov 2005 15:26:58 +1000 Anthony Towns wrote: On Thu, Nov 10, 2005 at 07:49:36PM -0500, Glenn Maynard wrote: FYI, a possible response might be: we care about freeness, but we pick our battle, and our battle is Debian main. I care about starving children, but I don't donate the majority of every check to feed them: there are lots of good causes, and the fact that everybody has to pick and choose their causes doesn't mean people don't care enough. (That said, I don't agree with that response: it should be no big deal for people to freely license their papers, so they can be packaged later in Debian. This isn't a big, difficult fight.) Why fight at all? If having a free license is so obviously correct, why force people to do it? If some people are uncomfortable with it, why fight that? I wish it were obvious to everyone, but apparently it's not. Otherwise there would not be so much non-free documentation around and we would not have to deal with its (wrong) presence in Debian main... Try to think what it would mean to Debian, if your above-quoted don't fight philosophy were applied to the Debian distribution. There would be no separate sections of the archive (main, contrib, and non-free would be all merged in one melting pot of works): there are already many GNU/Linux distros that do so... Fortunately Debian is different. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp8gxPUNgnZ7.pgp Description: PGP signature
Re: testing migration: wtf?
On Fri, Nov 11, 2005 at 08:58:35PM +0100, Lionel Elie Mamane wrote: What is happening with testing migration of my package, sork-passwd? The various testing migration pages seem to be all confused: - http://qa.debian.org/developer.php?package=sork-passwd doesn't give me the excuses link anymore That's because it's not longer in need of an update, because the latest version is in testing. - http://bjorn.haxx.se/debian/testing.pl?package=sork-passwd thinks sork-passwd is not in testing, while it is (in an older version), as shown by http://packages.debian.org/sork-passwd . Looks like confusion on the part of those scripts. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#338678: ITP: italc -- teaching tool
Package: wnpp Severity: wishlist Owner: Steffen Joeris [EMAIL PROTECTED] * Package name: italc Version : 0.9.6.2 Upstream Author : Tobias Doerffel [EMAIL PROTECTED] * URL : http://italc.sourceforge.net/download.php * License : GPL Description : teaching tool ITALC makes it possible, to access and influence the pupils activities just from the computer of the teacher. With the help of iTALC, for example the teacher is able to see the content of the pupils screens on his screen. If a pupil needs help, the teacher can access the pupils desktop and give support from his computer. The pupil can watch all activities, the teacher is doing on his desktop. So the pupil can learn new processes. For teaching something to all pupils, you can switch into demo-mode where all screens of the pupils show the teacher-screen. Furthermore things like locking pupil's screens, killing games, power on/off clients and much more can be done with iTALC. . Web site: http://italc.sourceforge.net/home.php -- 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.14-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338676: ITP: python-turbogears -- front-to-back rapid web development
Package: wnpp Severity: wishlist Owner: Bob Tanner [EMAIL PROTECTED] * Package name: python-turbogears Version : 0.8a3 Upstream Author : Kevin Dangoor [EMAIL PROTECTED] * URL : http://www.turbogears.org/ * License : http://www.opensource.org/licenses/mit-license.php Description : front-to-back rapid web development TurboGears brings together four major pieces to create an easy to install, easy to use web megaframework. It covers everything from front end (MochiKit JavaScript for the browser, Kid for templates in Python) to the controllers (CherryPy) to the back end (SQLObject). The TurboGears project is focused on providing documentation and integration with these tools without losing touch with the communities that already exist around those tools. TurboGears is easy to use for a wide range of web applications. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[RFH] Test of new grub package
Hello folks, I prepared a new package of grub for upload in next days. It still needs some work but looks like a good improvement. Would be good if you could do a brief test of it and provide feedback directly to me. If it solve any previous bug that you had before, would be good if you could send me a hint so I can close it when I have the upload ready. I can't promise that it'll work for you but it, at least, worked for me ;-) The updated package is available, with the source, at: deb http://projetos.ossystems.com.br/~otavio/test/grub ./ Thanks in advance, -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. pgpdc3LYGqUxO.pgp Description: PGP signature
Re: Request: Source for parts of GNU/Solaris
On Fri, Nov 11, 2005 at 11:43:23AM -0500, Glenn Maynard wrote: On Fri, Nov 11, 2005 at 10:11:24AM -0600, John Hasler wrote: Bill Gatliff writes: Taking something you're not entitled to ~= theft. Nothing is being taken. A copyright may be being infringed, but the owner is not being deprived of any property. There's something darkly amusing about arguments coming from Free Software people that sound very close to intellectual property. I wonder if people will start suggesting copy protection with DMCA enforcement. :) I guess you missed [0] then? [0] http://lists.debian.org/debian-devel/2005/11/msg00609.html Cheers, aj signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Fri, Nov 11, 2005 at 12:49:21AM -0800, Don Armstrong wrote: It's not all that unusual for conferences to require that the material submitted for the conference be licensed in a specific manner; OTOH, conferences usually ask for the minimal permission they actually need to do their job. if you plan on presenting, some DFSG free license of the material you present should be expected so portions of the work can be utilized in main or otherwise distributed by Debian if desired. Debian distributes lots of things that aren't DFSG-free -- not only stuff in non-free, but also stuff on lists.debian.org (like this thread), stuff on bugs.debian.org, and stuff on planet.debian.org. [If this poses a problem,[1] you always have the option of not presenting, or presenting your work in an informal session.] *sigh* Does this really have to devolve to if you don't like it, go away already? How about showing your potential speakers enough courtesy to at least consider their concerns, and enough respect to believe that they're scrupulous enough that they'll do the right thing even without being forced? Or, for that matter, having the flexibility to accept that sometimes the right thing changes depending on the situation? On Fri, 11 Nov 2005, Anthony Towns wrote: Of course, DFSG-free isn't all the dc6 organisers are insisting on, but the right to MIT/X11 recordings of presentations too -- not even giving presenters the option to copyleft the recording of their presentation for some reason. This is primarily pragmatic, since there's no clear consensus on what the prefered form for modification for a video is, or even what it means to copyleft a video. Huh? Copyleft == you can't restrict other people from redistributing and making further modifications. As an example: someone downloads the debconf presentations, culls various tidbits from them and puts them together in a dos and don'ts of technical presentations, then sells the new video for $5 a pop online, and refuses to allow people who purchase it to modify or redistribute it. Example copyleft licenses for videos include the CC ShareAlike licenses, the GFDL, the OPL, and the GPL. TTBOMK, of those, only the GPL talks about preferred form for modification. Cheers, aj signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Fri, Nov 11, 2005 at 08:00:55AM -0500, Glenn Maynard wrote: On Fri, Nov 11, 2005 at 03:26:58PM +1000, Anthony Towns wrote: Why fight at all? If having a free license is so obviously correct, why force people to do it? If some people are uncomfortable with it, why fight that? Even within Debian, it's become clear to me that, if we want DFSG-free things, it has to be mandatory and enforced, Of course, within Debian DFSG-freeness isn't mandatory or enforced: you can upload to non-free instead of main just by tweaking your control file. And that lack of compulsion, coupled with a fairly strong endorsement of DFSG-free content has resulted in DFSG-free software making up 98% of unstable. My point was that this isn't a big fight: these are papers, typically written by one person, who is probably in all cases immediately, easily contactable; not software with dozens of copyright holders, or written by companies feeling their commercial interests threatened. Compared to the battles underlying a lot of attempts to get free licenses, this is easy. The hard part isn't finding the people, it's convincing them that a DFSG-free license is best. That's why pine and qmail remain in non-free even though we know exactly who their authors are. Or, for that matter, most of RMS's writings are still licensed in a non-DFSG-free manner. BTW, a question: if you say you must make your stuff DFSG-free, aren't you inspiring debate from people who don't want to, or who aren't comfortable with that, on why the DFSG isn't appropriate? If you made it optional or encouraged instead of compulsory, wouldn't that encourage debate on why the DFSG is good in the specific instances where people choose not to use free licenses? Wouldn't that be better? All it's doing is shifting who has to start the debate: No, it's not. In this case, I'd much rather be in a position where I can argue for making things DFSG-free when I can see enough specifics to think of good reasons why that woul dbe okay, and remain silent in the cases where I don't think that's a win. I don't think remaining silent when people are being pressured to do things that don't seem right is a good option though, so instead I find myself arguing against the DFSG. in the optional case, the people who think all of the papers should be free will debate the cases that weren't; I don't believe I've seen anyone debate my use of the (aiui) non-DFSG-free CC ShareAlike/Attrib clause on my debbugs paper this year. There's no actual requirement for debate there either, the people who want to license their paper in non-DFSG-free way can happily leave the last word to the DFSG advocates because they don't have to debate to get their way; and the advocacy and arguments about the DFSG are more likely to have a long term effect than the license on any paper presented at a conference. and in the compulsory case, the people who think papers shouldn't have to be free will debate theirs. Which, to my mind, means it's a real, substantive win to not give people any reason to make this argument. At the very least, I'm getting really tired of having to have my desire for tolerance of other people's choices and individual freedoms trump my desire to argue for the DFSG freedoms everywhere. Cheers, aj signature.asc Description: Digital signature
Re: Closing bugs bevore the upload is available
Hi, Today I did a update of the system (yes, sid and yes I know it can be unstable but...) and the update includes grep where no open critical bug was seen. After Boot the system was completely broken as of the libpcre dependency. So please do not close bugs bevore it is available on servers. This break of the system musn't be. Junichi Didn't apt-listbugs help you at all ? AFAIK apt-listbugs only displays open bugs, if the bug is closed then it won't get displayed. It will be displayed even when it's closed. It does have some heuristics to avoid showing irrelevant bugs. Ideally apt-listbugs needs to be updated to support the new versioning system in the BTS. Taru; we've discussed face-to-face about handling the new BTS versioning features last month[1]; how about implementing it? This could also solve the issue that the mirror you use might be out-of-date and still have a buggy package that is fixed on the master server. apt-listbugs already parses which version of the package is going to be installed, so using the BTS versioning info instead of guessing from the existing text is the last required step. regards, junichi [1] http://www.netfort.gr.jp/~dancer/column/2005-debianmeeting.html.en -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: testing migration: wtf?
On Fri, Nov 11, 2005 at 08:58:35PM +0100, Lionel Elie Mamane wrote: What is happening with testing migration of my package, sork-passwd? sork-passwd |2.2.2-2 | testing | source, all sork-passwd |2.2.2-2 | unstable | source, all It migrated already... Cheers, aj signature.asc Description: Digital signature
Re: gnome-swallow_1.2-2_source.changes REJECTED
Scribit Josselin Mouette dies 10/11/2005 hora 22:45: Le jeudi 10 novembre 2005 à 13:32 -0800, Debian Installer a écrit : Rejected: source only uploads are not supported. I can't see the rationale for rejecting source uploads, and they used to be accepted in the past. And I see a rationale for allowing them: what prevents a DD to upload binaries that include exploits or some trojan code, along with a clean source? Isn't a buildd compilation more secure WRT this issue? (I don't try to say it's perfectly secure, I think admins of the buildd could do the trick also...) I suspect that is has already been discussed, so could someone give me URIs of messages/web pages on the subject if it is the case? BTW, is there any infrastructure to check against that? Would it be possible, or consume way much of resources (and first CPU of the buildd)? Doubtfully, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Sat, 12 Nov 2005, Anthony Towns wrote: On Fri, Nov 11, 2005 at 12:49:21AM -0800, Don Armstrong wrote: It's not all that unusual for conferences to require that the material submitted for the conference be licensed in a specific manner; OTOH, conferences usually ask for the minimal permission they actually need to do their job. Often; but they're not mutually exclusive. [At least in the academic world, it's not all that unusual for publishers to require a non-exclusive, unlimited copyright license to the work; I think a requirement that material be DFSG free is substantially more reasonable than that, and better aligned with the goals of debconf.] if you plan on presenting, some DFSG free license of the material you present should be expected so portions of the work can be utilized in main or otherwise distributed by Debian if desired. Debian distributes lots of things that aren't DFSG-free -- not only stuff in non-free, but also stuff on lists.debian.org (like this thread), stuff on bugs.debian.org, and stuff on planet.debian.org. Those examples are primarily a case of not being able to do better and still function; here I believe we can do better, and therefore should. [If this poses a problem,[1] you always have the option of not presenting, or presenting your work in an informal session.] Does this really have to devolve to if you don't like it, go away already? It was merely a statement that no one is forcing anyone to license their works in a particular manner, merely that the organizers (which to avoid confusion, doesn't include me) of the conference determine what the minimal set of permisions they need to do their jobs is. [Not that you should take your ball and go home.[1] ;-)] How about showing your potential speakers enough courtesy to at least consider their concerns, I assume that's what is being done here... correct me if I'm wrong. and enough respect to believe that they're scrupulous enough that they'll do the right thing even without being forced? I assume that the right thing is having the works licensed under a DFSG free license; granted, we've disagreed on numerous occasions whether that truly is the right thing or not... Huh? Copyleft == you can't restrict other people from redistributing and making further modifications. I tend lump both legal and technical means of restriction together, so I automatically assume that copyleft implies the distribution of the prefered form for modification; in any case, dealing with the licenses below will make the distribution of the DVDs containing the talks a bit more difficult... as the people actually making the recording and digitizing it are doing the majority of the work for it, presumably they are in the best position to determine the licences for the recording. Don Armstrong 1: At least, not until I kick it over the fence for you. ;-) -- Clint why the hell does kernel-source-2.6.3 depend on xfree86-common? infinity It... Doesn't? Clint good point http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: RFC: drop kerberos4-support?
On Sat, Nov 12, 2005 at 07:36:46AM +1100, Brian May wrote: Andreas == Andreas Barth [EMAIL PROTECTED] writes: Andreas Hi, while my regular clean up RC-bugs-work I noticed Andreas that the package krb4 is RC-buggy in more than one Andreas way. On further investigation, I also noticed that Andreas kerberos 4 is dying right now, and also that the bugs are Andreas not as easy to fix. Also, upstream doesn't look too Andreas active according to http://www.pdc.kth.se/kth-krb/. For Andreas this reason, I started to consider to push dropping of Andreas the krb4-package from unstable. This has some influence Andreas on the heimdal-package, and also on the release notes for Andreas migration issue. However, I personally tend to go that Andreas way. Please see bug #315059 for some discussion; Andreas especially, heimdal in experimental stopped to depend on Andreas kerberos 4. Not only that, but it conflicts with key krb4 libraries (libroken and libsl) IIRC. More likely: Conflicts/Replaces/Provides. I expect that if the Heimdal versions of libroken and libsl conflict with the existing krb4 versions, it's because they are in fact a compatible replacement. Hmm; looking at the symbol tables of each library, we have the following symbols that were present in the krb4 version of libroken and have been dropped in the heimdal version: get_progname roken_glob roken_globfree set_progname At least get_progname and set_progname were exported as part of the published API, so libroken16-heimdal can't claim to provide libroken16-kerberos4kth. It would be nice if upstream changed the soname, though, to distinguish it from other, known-incompatible versions out there. For libsl, the only symbol dropped is get_progname, and that doesn't seem to be part of the exported interface for libsl0 as of 1.2.2-11.3. So it may be valid for libsl0-heimdal to maintain package compatibility with libsl0-kerberos4kth, but this probably needs to be confirmed upstream. For libotp0, no symbols were dropped. So libotp0-heimdal should either Conflicts:/Replaces:/Provides: libotp0-kerberos4kth, or simply keep the same libotp0-kerberos4kth name. The latter is actually more useful, given that existing packages that depend on libotp0-kerberos4kth have a *versioned* dependency that can't be satisfied by the use of Provides. If all this is done correctly (libroken soname change, keep the historical package names of the other two libs), users who still need krb4 support locally should be able to keep around the krb4 packages from sarge as long as they need to while still being able to install heimdal from etch. Ideally I thin the krb4 maintainer should have same say. However I haven't heard from him. Well, normally package maintainers have a say in the removal of their own packages by responding to the RC bugs in them... I think there several things I want to do before uploading Heimdal to unstable as it is in experimental: * Find out what packages will break. By the update of heimdal, it should only be packages depending on libgssapi1-heimdal, I guess? By the removal of krb4: (old) heimdal, and libsasl2-modules-kerberos-heimdal (from cyrus-sasl2). The only other packages in the archive with a dependency on krb4 today are lsh-server, libsasl2-modules-gssapi-heimdal, and sasl2-bin, which pull in the dependency via heimdal; and a build of samba which seems to have picked up a gratuitous krb4 dependency when built on my system... * Find out what packages will still be broken even after recompiling. If anything has to be recompiled which *doesn't* depend on libgssapi1-heimdal, then that's a bug that needs to be fixed in heimdal first... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Sat, Nov 12, 2005 at 10:46:24AM +1000, Anthony Towns wrote: Of course, within Debian DFSG-freeness isn't mandatory or enforced: you can upload to non-free instead of main just by tweaking your control file. The response is predictable, but here it is anyway: non-free isn't within Debian; Debian mandates DFSG-freeness. The practical impact of that is lessened due to the ease at which people can add non-free to their sources; but if it's not fundamentally true, then SC#1 needs serious reinforcement. The hard part isn't finding the people, it's convincing them that a DFSG-free license is best. That's why pine and qmail remain in non-free even though we know exactly who their authors are. Or, for that matter, most of RMS's writings are still licensed in a non-DFSG-free manner. UW, DJB and RMS may be fairly extreme examples of people who are difficult to convince. :) No, it's not. In this case, I'd much rather be in a position where I can argue for making things DFSG-free when I can see enough specifics to think of good reasons why that woul dbe okay, and remain silent in the cases where I don't think that's a win. It's usually so easy to find reasons why DFSG-freeness is a good thing, I tend to assume they exist by default. So, I see it the other way around: things should be DFSG-free unless I can see enough specifics to think of good reasons why they shouldn't be. I don't think remaining silent when people are being pressured to do things that don't seem right is a good option though, so instead I find myself arguing against the DFSG. I don't understand how licensing papers DFSG-freely way doesn't seem right. Incidentally, I care less about papers than many other things, so I'm not going to spend much effort to try to convince people to DFSG-free them; however, I'm a bit interested to understand the rationale behind not wanting to, from people who are beyond I don't want people putting words in my mouth responses. (But I understand not wanting to spend time arguing *against* DFSG-freeness.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request: Source for parts of GNU/Solaris
Scribit Anthony Towns dies 11/11/2005 hora 16:43: The problem is a technicality, not a moral or practical difference from the GPL's expectations: you still have the source to OpenSolaris libc, and you still have permission to modify it, redistribute it, sell it, etc. Didn't someone ask for the source of some other packages (sunw*) that are not, at the moment, available (and won't in the future, IIUC)? I had understood that the problem is that some of the source needed to compile core packages of Nexenta are not even open source... Curiously, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Request: Source for parts of GNU/Solaris
On Fri, 11 Nov 2005 15:48:20 +1000, Anthony Towns aj@azure.humbug.org.au said: On Thu, Nov 10, 2005 at 06:07:33PM +0100, David Schmitt wrote: [0] Presuming the FSF's claims about dynamic linking hold up in this case, anyway. I consider a Debian-derived distribution a derived work of the contained Debian tools in more ways than mere dynamic linking. That doesn't much matter -- Debian doesn't claim any copyright on its efforts in collecting work, so deriving from Debian doesn't involve any copyrights but that of the aggregate parts you use. Every single one of my packages has software that is under copyright by me, and distributed under various free licenses. So, if you derive from Debian, if you happen to use any packages I maintain (make? flex?) does indeed involve copyrights apart from the copyright of aggregated works. To be more specific: I don't believe that the fact that software A is being packaged with Debians tools is a derived work of said tools, Hmm. What about software bits of the package (maintainer scripts, added utilities, prompting infrastructure ) under copyright by Debian developers -- do they count? manoj -- He who has a shady past knows that nice guys finish last. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licenses for DebConf6
On Sat, 12 Nov 2005 10:26:52 +1000, Anthony Towns aj@azure.humbug.org.au said: On Fri, Nov 11, 2005 at 12:49:21AM -0800, Don Armstrong wrote: [If this poses a problem,[1] you always have the option of not presenting, or presenting your work in an informal session.] *sigh* Does this really have to devolve to if you don't like it, go away already? How about showing your potential speakers enough courtesy to at least consider their concerns, and enough respect to believe that they're scrupulous enough that they'll do the right thing even without being forced? Or, for that matter, having the flexibility to accept that sometimes the right thing changes depending on the situation? Err, if this compilation is a project Debian product, or is associated with us, then it seems like we are doing to presentation software bits what we ask of producers of other kinds of software bits: If you want it to be part of debian, you must ship all them software bits under a license we deem free. Why are presentation 0's and 1-s any different from executable 0's and 1's, or documentation 0's and 1's ? Again, if debconf is not related to debian, than none of this applies, and in that case, can we take this off a mailing list for Debian development? manoj -- We're living in a golden age. All you need is gold. D.W. Robertson. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licenses for DebConf6
On Fri, 11 Nov 2005 15:26:58 +1000, Anthony Towns aj@azure.humbug.org.au said: On Thu, Nov 10, 2005 at 07:49:36PM -0500, Glenn Maynard wrote: FYI, a possible response might be: we care about freeness, but we pick our battle, and our battle is Debian main. I care about starving children, but I don't donate the majority of every check to feed them: there are lots of good causes, and the fact that everybody has to pick and choose their causes doesn't mean people don't care enough. (That said, I don't agree with that response: it should be no big deal for people to freely license their papers, so they can be packaged later in Debian. This isn't a big, difficult fight.) Why fight at all? If having a free license is so obviously correct, why force people to do it? If some people are uncomfortable with it, why fight that? Because sometimes one feels the need to fight for what is right? Even if people feel far more comfortable with just sweeping stuff under the carpet, and not brought out in the open? While I am undecided how much I am willing to fight for DFSG freeness, and not sending people the message that Debian only fights for DFSG freeness when it is other peoepls free documentation, and blithely accepts whatever goes when it comes to their own convenience, I must voice my objection to this line of argument (why make waves? the misguided folks will come to see the crrect argument and do the right thing after all [Hello, Kansas Board of Education]). My blog's licensed under the CC No-derivs/non-commerical license for much the same reasons as most of RMS's writings aren't DFSG-free; but that's fine -- I'm not trying to get them to become the basis of a developer community or similar, and that's why I'm not bothered by not having comments on my blog, either. And, thankfully, they do not come with the imprimatur of the Debian project, as Debconf seems to. I'd prefer something like this: During and after the conference various materials will be made available to attendees and the general public; submission of a paper thus indicates permission to: * distribute verbatim copies and translations of the paper, slides and other materials provided by the presenter * distribute audio and video recordings of the presentation Presenters are encouraged to provide a specific license (preferably DFSG-free) under which the materials and presentation can be redistributed. If Debian lends it names to a compilation of papers distributed by it, such as it may be construed as the compilation product of the Debian project, or in any way part of Debian, we are constrained to have that compilation be free. If, of course, Debconf is a independent entity, not related to Debian, then I have no opinion, apart from isn't this off-topic here on this mailing list? manoj -- The truth about a man lies first and foremost in what he hides. Andre Malraux Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome-swallow_1.2-2_source.changes REJECTED
On Sat, 12 Nov 2005 02:29:56 +0100, Pierre THIERRY [EMAIL PROTECTED] said: Scribit Josselin Mouette dies 10/11/2005 hora 22:45: Le jeudi 10 novembre 2005 à 13:32 -0800, Debian Installer a écrit : Rejected: source only uploads are not supported. I can't see the rationale for rejecting source uploads, and they used to be accepted in the past. And I see a rationale for allowing them: what prevents a DD to upload binaries that include exploits or some trojan code, along with a clean source? Isn't a buildd compilation more secure WRT this issue? (I don't try to say it's perfectly secure, I think admins of the buildd could do the trick also...) Of Robert Pike C compiler trojan trick ... You gotta start trusting somewhere. Our web of trust starts with the Developers in the keyring, we trust these people not to muck with the binaries. manoj -- The more the change, the more it is the same thing. -- Alphonse Karr Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Licenses for DebConf6
On Sat, 12 Nov 2005 10:46:24 +1000, Anthony Towns aj@azure.humbug.org.au said: On Fri, Nov 11, 2005 at 08:00:55AM -0500, Glenn Maynard wrote: On Fri, Nov 11, 2005 at 03:26:58PM +1000, Anthony Towns wrote: Why fight at all? If having a free license is so obviously correct, why force people to do it? If some people are uncomfortable with it, why fight that? Even within Debian, it's become clear to me that, if we want DFSG-free things, it has to be mandatory and enforced, Of course, within Debian DFSG-freeness isn't mandatory or enforced: you can upload to non-free instead of main just by tweaking your control file. I am sure you are aware that is not part of Debian. Perhaps it was wring not to throw non-free archives off Debian machines, if such confusion is rampant. And that lack of compulsion, coupled with a fairly strong endorsement of DFSG-free content has resulted in DFSG-free software making up 98% of unstable. And 100% of Debian. I don't believe I've seen anyone debate my use of the (aiui) non-DFSG-free CC ShareAlike/Attrib clause on my debbugs paper this year. I was not aware that you were soliciting opinions. If you are, I find it deplorable. I saw no benefit in sharing my opinion after the fact, but am perfectly willing to do so if you think my rectitude was implicit approval. There's no actual requirement for debate there either, the people who want to license their paper in non-DFSG-free way can happily leave the last word to the DFSG advocates because they don't have to debate to get their way; Only if they want their papers in a collection which is actually part of Debian, they do too. and the advocacy and arguments about the DFSG are more likely to have a long term effect than the license on any paper presented at a conference. Any advocacy of the DFSG by an organization that happily accepts non-free licenses when it is convenient, smacks so much of hypocrisy to be unpersuasive. But that is just my opinion. manoj -- You have the power to influence all with whom you come in contact. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338692: ITP: python-pyprotocols -- Open Protocols and Component Adaptation for Python
Package: wnpp Severity: wishlist Owner: Bob Tanner [EMAIL PROTECTED] * Package name: python-pyprotocols Version : 0.9.3 Upstream Author : Phillip J. Eby [EMAIL PROTECTED] com * URL : http://peak.telecommunity.com/PyProtocols.html * License : http://www.zope.org/Resources/ZPL or http://www.python.org/2.3.2/license.html Description : Open Protocols and Component Adaptation for Python Do you hate having to write lots of if-then logic to test what type something is? Wouldn't it be nice if you could just declare I want this object to have this behavior and magically convert whatever value you have, to the type you need? PyProtocols lets you do just that, cleanly, quickly, and robustly -- even with built-in types or other people's classes. . PyProtocols extends the PEP 246 adapt() function with a new declaration API that lets you easily define your own protocols and adapters, and declare what adapters should be used to adapt what types, objects, or protocols. In addition to its own Interface type, PyProtocols can also use Twisted and Zope's Interface types too. (Of course, since Twisted and Zope interfaces aren't as flexible, only a subset of the PyProtocols API works with them. Specific limitations arelisted in the documentation.) . Home Page: http://peak.telecommunity.com/PyProtocols.html Package: python2.3-pyprotocols Architecture: any Depends: python, python2.3 Description: Open Protocols and Component Adaptation for Python Do you hate having to write lots of if-then logic to test what type something is? Wouldn't it be nice if you could just declare I want this object to have this behavior and magically convert whatever value you have, to the type you need? PyProtocols lets you do just that, cleanly, quickly, and robustly -- even with built-in types or other people's classes. . PyProtocols extends the PEP 246 adapt() function with a new declaration API that lets you easily define your own protocols and adapters, and declare what adapters should be used to adapt what types, objects, or protocols. In addition to its own Interface type, PyProtocols can also use Twisted and Zope's Interface types too. (Of course, since Twisted and Zope interfaces aren't as flexible, only a subset of the PyProtocols API works with them. Specific limitations arelisted in the documentation.) . Home Page: http://peak.telecommunity.com/PyProtocols.html Package: python2.4-pyprotocols Architecture: any Depends: python2.4 Description: Open Protocols and Component Adaptation for Python Do you hate having to write lots of if-then logic to test what type something is? Wouldn't it be nice if you could just declare I want this object to have this behavior and magically convert whatever value you have, to the type you need? PyProtocols lets you do just that, cleanly, quickly, and robustly -- even with built-in types or other people's classes. . PyProtocols extends the PEP 246 adapt() function with a new declaration API that lets you easily define your own protocols and adapters, and declare what adapters should be used to adapt what types, objects, or protocols. In addition to its own Interface type, PyProtocols can also use Twisted and Zope's Interface types too. (Of course, since Twisted and Zope interfaces aren't as flexible, only a subset of the PyProtocols API works with them. Specific limitations arelisted in the documentation.) . Home Page: http://peak.telecommunity.com/PyProtocols.html -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338698: ITP: python-ruledispatch -- Rule-based Dispatching and Generic Functions
Package: wnpp Severity: wishlist Owner: Bob Tanner [EMAIL PROTECTED] * Package name: python-ruledispatch Version : 0.5a0dev Upstream Author : Phillip J. Eby [EMAIL PROTECTED] * URL : http://www.turbogears.org/download/eggs/RuleDispatch-0.5a0dev_r2097.zip * License : http://www.zope.org/Resources/ZPL or http://www.python.org/2.3.2/license.html Description : Rule-based Dispatching and Generic Functions Home Page: http://www.turbogears.org/download/index.html -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
inquiry
Dear Sir We are Exporter of all kind of Textile Waste from Pakistan and would like to extend our Business Relationship with your esteem Company, we can provide you following item Gin mote Card Fly Cotton Yarn Waste P/C Yarn Waste Comber Noël Hosiery Cutting 100% Cotton Hosiery Cotton / synthetic, cutting Polyester Waste all type Beside this we can export PET Waste / PTA Powder Off Grade and other Plastic, PV resin If you are interested, we can send you the Sample Best regards, Mr. Maqsood Ali Email: [EMAIL PROTECTED]
Bug#338701: ITP: python-testgears -- TestGears extensions to unittest
Package: wnpp Severity: wishlist Owner: Bob Tanner [EMAIL PROTECTED] * Package name: python-testgears Version : 0.2 Upstream Author : Kevin Dangoor dangoor+testgears at gmail com * URL : http://www.turbogears.org/testgears/ * License : http://www.opensource.org/licenses/mit-license.php Description : TestGears extensions to unittest TestGears provides automatic discovery of unittest.TestCases and the ability to run tests that are written as simple functions. It generates a standard unittest.TestSuite for use with any of the standard frontends, and provides a distutils command to run tests with zero configuration. . Home Page: http://www.turbogears.org/testgears/ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted drift 2.1.2-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 28 Sep 2005 14:37:51 +0200 Source: drift Binary: drift Architecture: source i386 Version: 2.1.2-1 Distribution: unstable Urgency: low Maintainer: Arjan Oosting [EMAIL PROTECTED] Changed-By: [EMAIL PROTECTED] Description: drift - type sensitive preprocessor for Haskell Changes: drift (2.1.2-1) unstable; urgency=low . * New upstream release. * added debian/patches/01_update-autotools.patch: update files generated by autotools. Files: d2bae21bf5b181c1eadb0e5a4f3013bc 749 devel optional drift_2.1.2-1.dsc 71500b9ce9536a354a9359437eb42fe2 248652 devel optional drift_2.1.2.orig.tar.gz 2088d511191658ed26fe736575f68bb8 6753 devel optional drift_2.1.2-1.diff.gz 250b6422d11c13687a493cebec0dd0a1 389338 devel optional drift_2.1.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDdE0RBLPTZ7K4MaIRAvlrAKCjnuWkXUfVOG3Pon7i6SoQG3EzEACfQ8Bu +hc5chlouwG6GmzYajeVpqs= =AFV6 -END PGP SIGNATURE- Accepted: drift_2.1.2-1.diff.gz to pool/main/d/drift/drift_2.1.2-1.diff.gz drift_2.1.2-1.dsc to pool/main/d/drift/drift_2.1.2-1.dsc drift_2.1.2-1_i386.deb to pool/main/d/drift/drift_2.1.2-1_i386.deb drift_2.1.2.orig.tar.gz to pool/main/d/drift/drift_2.1.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ksubtile 1.2-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 11 Nov 2005 09:32:15 +0100 Source: ksubtile Binary: ksubtile Architecture: source i386 Version: 1.2-2 Distribution: unstable Urgency: low Maintainer: Ana Beatriz Guerrero Lopez [EMAIL PROTECTED] Changed-By: Isaac Clerencia [EMAIL PROTECTED] Description: ksubtile - subtitle editor for KDE Changes: ksubtile (1.2-2) unstable; urgency=low . * Fix FTBFS in arm, m68k and hppa by building with gcc-3.4 there Files: 99b49b5441ad35f60d63405c396252c0 734 kde optional ksubtile_1.2-2.dsc 12ae6b491716f05d3c808954d309c4c6 13929 kde optional ksubtile_1.2-2.diff.gz d6c165393d74d197b011d01cdcadf546 242246 kde optional ksubtile_1.2-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Signed by Isaac Clerencia [EMAIL PROTECTED] iD8DBQFDdFhgQET2GFTmct4RAq5vAKCInSbwVqugDbR4+QItbwqnLkzKSwCglFxC daR0Oa+GBiN1Zk1bu3LPki0= =j5vH -END PGP SIGNATURE- Accepted: ksubtile_1.2-2.diff.gz to pool/main/k/ksubtile/ksubtile_1.2-2.diff.gz ksubtile_1.2-2.dsc to pool/main/k/ksubtile/ksubtile_1.2-2.dsc ksubtile_1.2-2_i386.deb to pool/main/k/ksubtile/ksubtile_1.2-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnome-python 2.10.0-4 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 11 Nov 2005 11:02:16 +0100 Source: gnome-python Binary: python-gnome2-dev python2.4-gnome2 python2.3-gnome2 python-gnome2 Architecture: source i386 all Version: 2.10.0-4 Distribution: unstable Urgency: high Maintainer: Sebastien Bacher [EMAIL PROTECTED] Changed-By: Loic Minier [EMAIL PROTECTED] Description: python-gnome2 - Python bindings for the GNOME desktop environment python-gnome2-dev - Python bindings for the GNOME desktop environment python2.3-gnome2 - Python bindings for the GNOME desktop environment python2.4-gnome2 - Python bindings for the GNOME desktop environment Closes: 337203 Changes: gnome-python (2.10.0-4) unstable; urgency=high . * Change the python2.3-pyorbit build-dep in python-pyorbit-dev. (Closes: #337203) [debian/control, debian/control.in] Files: c9366d642d69442f5aa369f2b83b0117 2057 python optional gnome-python_2.10.0-4.dsc c0959f0a6f4c02a3f8181dd4b9b839a1 6443 python optional gnome-python_2.10.0-4.diff.gz 1e69bb06fd3a47d528a3a602d33e9631 184024 python optional python2.3-gnome2_2.10.0-4_i386.deb 3065993ab6348e09011f937e184dac03 183960 python optional python2.4-gnome2_2.10.0-4_i386.deb f98f1e4ffd0b4bc3b4d25c110ca7666c 32998 python optional python-gnome2_2.10.0-4_all.deb 2bc66b26480ff4fa79e217d2fe5a7605 53998 python optional python-gnome2-dev_2.10.0-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDdG/h4VUX8isJIMARAqp9AKCLjqqRcXlGYZ/Z8/oVxwPIbhz2twCgunnQ bnRGGJQjgIp4PLLpj68B/os= =ZOjj -END PGP SIGNATURE- Accepted: gnome-python_2.10.0-4.diff.gz to pool/main/g/gnome-python/gnome-python_2.10.0-4.diff.gz gnome-python_2.10.0-4.dsc to pool/main/g/gnome-python/gnome-python_2.10.0-4.dsc python-gnome2-dev_2.10.0-4_all.deb to pool/main/g/gnome-python/python-gnome2-dev_2.10.0-4_all.deb python-gnome2_2.10.0-4_all.deb to pool/main/g/gnome-python/python-gnome2_2.10.0-4_all.deb python2.3-gnome2_2.10.0-4_i386.deb to pool/main/g/gnome-python/python2.3-gnome2_2.10.0-4_i386.deb python2.4-gnome2_2.10.0-4_i386.deb to pool/main/g/gnome-python/python2.4-gnome2_2.10.0-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnome-swallow 1.2-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 10 Nov 2005 21:12:20 +0100 Source: gnome-swallow Binary: gnome-swallow-applet Architecture: source i386 Version: 1.2-2 Distribution: unstable Urgency: low Maintainer: Josselin Mouette [EMAIL PROTECTED] Changed-By: Josselin Mouette [EMAIL PROTECTED] Description: gnome-swallow-applet - meta-applet to embed any application in the GNOME panel Closes: 306150 333606 Changes: gnome-swallow (1.2-2) unstable; urgency=low . * Acknowledge NMU (closes: #306150). * Switch to cdbs. * gettimeofday.patch: fix amd64 crasher (closes: #333606). * Standards-version is 3.6.2. * Fix FSF address. Files: 3f263b55ecac63acaa8145bf37e8e467 542 gnome optional gnome-swallow_1.2-2.dsc 6fbbad64a675816c96c1fa5f3096606e 90330 gnome optional gnome-swallow_1.2-2.tar.gz c8c7be64a0bffc92c35b9ba6dcd03572 12880 gnome optional gnome-swallow-applet_1.2-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDdIBRt1anjIgqbEsRAnqgAKDANjttlAEbp7c5CaNrWdS1f0KHaACg9NAi yZdNSM+PENseJOcGZ/hp0Xc= =SYmA -END PGP SIGNATURE- Accepted: gnome-swallow-applet_1.2-2_i386.deb to pool/main/g/gnome-swallow/gnome-swallow-applet_1.2-2_i386.deb gnome-swallow_1.2-2.dsc to pool/main/g/gnome-swallow/gnome-swallow_1.2-2.dsc gnome-swallow_1.2-2.tar.gz to pool/main/g/gnome-swallow/gnome-swallow_1.2-2.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted spca5xx 20051105-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 11 Nov 2005 20:25:52 +1000 Source: spca5xx Binary: spca5xx-source Architecture: source all Version: 20051105-1 Distribution: unstable Urgency: low Maintainer: Debian spca5xx Maintainers [EMAIL PROTECTED] Changed-By: Kel Modderman [EMAIL PROTECTED] Description: spca5xx-source - source for the spca5xx driver Changes: spca5xx (20051105-1) unstable; urgency=low . [Kel Modderman] * New upstream release. - fixes compilation with 2.4.x kernels * Ensure postinst exits with status of 0. * Add debhelper token to postinst.modules.in. Files: 44cf56b3afe4a73d625da23ca0fbf12b 810 misc optional spca5xx_20051105-1.dsc 7d2e84c3d3880728fefd5644713ba0ca 179996 misc optional spca5xx_20051105.orig.tar.gz 89efb7bd19f9144ff54893098daf8b6c 3781 misc optional spca5xx_20051105-1.diff.gz 17a59b8e77b75133b63b7ea0810e4d62 184134 misc optional spca5xx-source_20051105-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDdHvcLqiZQEml+FURAs85AKCSxf4/4diCDgnOJP4deL+ijMeDTgCfeAeh 9KEpE2h4YFaGHmrBN3qXdLQ= =cpm9 -END PGP SIGNATURE- Accepted: spca5xx-source_20051105-1_all.deb to pool/main/s/spca5xx/spca5xx-source_20051105-1_all.deb spca5xx_20051105-1.diff.gz to pool/main/s/spca5xx/spca5xx_20051105-1.diff.gz spca5xx_20051105-1.dsc to pool/main/s/spca5xx/spca5xx_20051105-1.dsc spca5xx_20051105.orig.tar.gz to pool/main/s/spca5xx/spca5xx_20051105.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted abuse-lib 2.00-17 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 11 Nov 2005 11:27:27 +0100 Source: abuse-lib Binary: abuse-lib Architecture: source all Version: 2.00-17 Distribution: unstable Urgency: low Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED] Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED] Description: abuse-lib - original levels for Abuse Changes: abuse-lib (2.00-17) unstable; urgency=low . * debian/control: + Set policy to 3.6.2.1. + Build-depend on debhelper (= 4.0). * debian/postinst: + Fix directory permissions. + Fix deprecated chown usage. * debian/copyright: + Add link to the GPL license. Files: 61955d5d1d119ac718e36aa499663e8c 589 games extra abuse-lib_2.00-17.dsc f4419f4d3f555aacfa61d6d6fa202039 3766 games extra abuse-lib_2.00-17.diff.gz b3c3e261645d90bb776acd5ad836a605 834668 games extra abuse-lib_2.00-17_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDdIHvfPP1rylJn2ERAuleAJ9AFz9VtC18nnXBpSUleixoDj8+BQCfV1o4 NlOqB0xc8GJBL8q6qedhm8E= =Gm2Q -END PGP SIGNATURE- Accepted: abuse-lib_2.00-17.diff.gz to pool/main/a/abuse-lib/abuse-lib_2.00-17.diff.gz abuse-lib_2.00-17.dsc to pool/main/a/abuse-lib/abuse-lib_2.00-17.dsc abuse-lib_2.00-17_all.deb to pool/main/a/abuse-lib/abuse-lib_2.00-17_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted geneweb 4.10-16 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 11 Nov 2005 12:04:29 +0100 Source: geneweb Binary: geneweb gwtp Architecture: source i386 Version: 4.10-16 Distribution: unstable Urgency: low Maintainer: Christian Perrier [EMAIL PROTECTED] Changed-By: Christian Perrier [EMAIL PROTECTED] Description: geneweb- genealogy software with web interface gwtp - web interface interacting with Geneweb databases Closes: 336360 338514 338521 Changes: geneweb (4.10-16) unstable; urgency=low . * debian/geneweb.init,debian/geneweb.postinst: - Correct reference to /usr/share/doc/geneweb instead of /usr/share/doc/geneweb/doc. Closes: #338514,#336360 * Debconf translations: - Swedish added. Closes: #338521 Files: 710802c3a558861509b4d22e5f3bb4b5 678 misc optional geneweb_4.10-16.dsc 28a28f8ee81e64d8c593c0c8d7045862 84595 misc optional geneweb_4.10-16.diff.gz 4ad44a2ab51d197831b39626d81c7ecb 2056732 misc optional geneweb_4.10-16_i386.deb 2120b289f0303b3838cd29b145e9c1ea 188112 misc optional gwtp_4.10-16_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDdIC71OXtrMAUPS0RAqprAKCB5v3QIPDEQhoMQMsqQLfPQe8PcgCgsRMm vA+S4B4tM1BejjbmlU1P43s= =K2oL -END PGP SIGNATURE- Accepted: geneweb_4.10-16.diff.gz to pool/main/g/geneweb/geneweb_4.10-16.diff.gz geneweb_4.10-16.dsc to pool/main/g/geneweb/geneweb_4.10-16.dsc geneweb_4.10-16_i386.deb to pool/main/g/geneweb/geneweb_4.10-16_i386.deb gwtp_4.10-16_i386.deb to pool/main/g/geneweb/gwtp_4.10-16_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mozilla-firefox 1.4.99+1.5rc2.dfsg-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 11 Nov 2005 08:07:05 +0100 Source: mozilla-firefox Binary: mozilla-firefox mozilla-firefox-gnome-support mozilla-firefox-dom-inspector Architecture: source i386 Version: 1.4.99+1.5rc2.dfsg-1 Distribution: experimental Urgency: low Maintainer: Mike Hommey [EMAIL PROTECTED] Changed-By: Mike Hommey [EMAIL PROTECTED] Description: mozilla-firefox - lightweight web browser based on Mozilla mozilla-firefox-dom-inspector - tool for inspecting the DOM of pages in Mozilla Firefox mozilla-firefox-gnome-support - Support for Gnome in Mozilla Firefox Closes: 211010 256384 323639 Changes: mozilla-firefox (1.4.99+1.5rc2.dfsg-1) experimental; urgency=low . * xpcom/typelib/xpidl/xpidl.c: Fix crash when no file is given on the command line (Closes: #323639). Also fix the error message about extra arguments given showing before the crash. * configure.in, configure: Work around dash's bug #337294 so that we can build fine when sh is dash (Closes: #211010, #256384). * debian/mozilla-firefox-runner: - Removed the code to detect the JVM and set LD_ASSUME_KERNEL=2.2.5 for b0rked 1.3 JVMs: it's been a long time they've not been ABI compatible. - Removed setting of MOZILLA_FIVE_HOME. We already have a default one built-in. - Removed /usr/lib/mozilla/plugins from EXTENT_LD_LIB_PATH, since we never get the plugins from there. - Removed cleanup of the profile. It is correctly done by firefox, now. Files: ff57f20e9fa33ed64a89f9a3dd3d8751 1029 web optional mozilla-firefox_1.4.99+1.5rc2.dfsg-1.dsc 3df05506ad9d847203a205f3b861ff0e 42515528 web optional mozilla-firefox_1.4.99+1.5rc2.dfsg.orig.tar.gz 892835322e2727cd6f41ca299c440a3f 72216 web optional mozilla-firefox_1.4.99+1.5rc2.dfsg-1.diff.gz 7364fd7346cfde566b52ae6d4905a694 7769806 web optional mozilla-firefox_1.4.99+1.5rc2.dfsg-1_i386.deb fa27aae9e65ac21aa6d38d25e6c806ab 203782 web optional mozilla-firefox-dom-inspector_1.4.99+1.5rc2.dfsg-1_i386.deb b58a632fc4ed3824b87f4c19a19b3e97 64688 web optional mozilla-firefox-gnome-support_1.4.99+1.5rc2.dfsg-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDdHHi3kvaLFT9KlgRArQ1AJoDzUlpTPfM7l7+rnMjYv+JzTSuZQCdEKJg XsZYqDVXO1k4t4O6hMiaUt4= =Ws1Y -END PGP SIGNATURE- Accepted: mozilla-firefox-dom-inspector_1.4.99+1.5rc2.dfsg-1_i386.deb to pool/main/m/mozilla-firefox/mozilla-firefox-dom-inspector_1.4.99+1.5rc2.dfsg-1_i386.deb mozilla-firefox-gnome-support_1.4.99+1.5rc2.dfsg-1_i386.deb to pool/main/m/mozilla-firefox/mozilla-firefox-gnome-support_1.4.99+1.5rc2.dfsg-1_i386.deb mozilla-firefox_1.4.99+1.5rc2.dfsg-1.diff.gz to pool/main/m/mozilla-firefox/mozilla-firefox_1.4.99+1.5rc2.dfsg-1.diff.gz mozilla-firefox_1.4.99+1.5rc2.dfsg-1.dsc to pool/main/m/mozilla-firefox/mozilla-firefox_1.4.99+1.5rc2.dfsg-1.dsc mozilla-firefox_1.4.99+1.5rc2.dfsg-1_i386.deb to pool/main/m/mozilla-firefox/mozilla-firefox_1.4.99+1.5rc2.dfsg-1_i386.deb mozilla-firefox_1.4.99+1.5rc2.dfsg.orig.tar.gz to pool/main/m/mozilla-firefox/mozilla-firefox_1.4.99+1.5rc2.dfsg.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
