Re: LCC and blobs
Brian Thomas Sniffen wrote: No; the hardware is damaged. No driver can drive that. The driver you have is a driver for Foomatic Quxer cards. You don't have a Foomatix Quxer; you have a broken pile of junk. So here you argue that because the firmware is gone the hardware is broken, correct? ... It's clearly software, and the driver clearly has a dependency on it. And now you consider it software just because the method of storage is different? How can the nature of the bytes change because they are stored on a disk? If the driver need to load the firmware or just needs to enable it is the same thing. Just think of the enable sequence as highly compressed firmware :-). So the driver has a dependency on the firmware, even if it is in the device itself. So we have to move all drivers that use devices with build-in firmware to contrib. That or we see that the firmware is actually part of the hardware and that uploading is just a natural thing a driver should do. The fact that most firmware cannot be redistributed or does not come as source just selects what we can ship or have to ask the user to provide. Since in the case of firmware on disk we can't reliably get the firmware to users *anyway*, utility's not atainable and we should keep our principles of freedom. I see no limitation of my freedom in using firmware. Please tell me how I am limited in my freedom. If I wanted a open source firmware I could buy a device with open firmware, Groetjes, Peter
Re: LCC and blobs
Brian Thomas Sniffen wrote: Peter Van Eynde <[EMAIL PROTECTED]> writes: And now you consider it software just because the method of storage is different? How can the nature of the bytes change because they are stored on a disk? The nature of the bytes do not change. But my name, distributed in a Debian package, is software. My name, written in letters of granite You name is software! Now I'm a Common Lisp hacker, you know the data is code people, but even _we_ do not consider a string software unless it drives some software. Is your name input for a state-machine? Architectural plans for a house, shipped in a Debian package, are software. I'm stunned. So anything in a Debian package is software. With alien I can convert a tar.gz into a debian package, so all tar files are software. With tar I can create a tar.gz from any file, so all electronic data is software? And you restrictions that any package that depends on non-DFSG "software" to work cannot be in main means that after releasing sarge we have to remove from main: - all bootloaders. Grub cannot start my XP without the XP bootsector. - tftpd. I want to netboot my Solaris machines. The tftpd needs the solaris code to "work". - all font renderers. I want to see a document with the font I bought, and without it the document is broken, so the renderer needs the font, right? - all interpreters. I want to run HACMP. It is in perl, so the perl is useless to me without HACMP. - the kernel. I want to ship a stripped down debian with my non-DFSG code in an embedded system. The kernel is useless without my code, so the kernel cannot be in main. Should I go on? Groetjes, Peter
Re: LCC and blobs
Brian Thomas Sniffen wrote: Some firmware is part of the hardware. Some isn't. It's easy to tell -- either it's in the hardware or it isn't. Of course, the name "firmware" should make it clear that this is an often ambiguous line. But this does seem to be a good practical place: can anybody with the device and the driver use it? Or are there some people who even with a functioning, complete device and a driver who can't get it to work? This is not only a feature of a device with firmware. Some hardware you cannot buy, you only get a license to use it. If I remember correctly you never "buy" an EMC, you only get permission to use it and have to pay every year to continue to use it. So you want to rip out all fiber-channel drivers because they might be used to connect to an EMC? I see no limitation of my freedom in using firmware. Please tell me how I am limited in my freedom. If I wanted a open source firmware I could buy a device with open firmware, Then Windows isn't proprietary either. Sigh. It is, but does the fact that I can boot it with grub limit my freedom? Groetjes, Peter
Re: Bug#285518: misdn-utils includes a firmware loader
Glenn Maynard wrote: Hmm. A few places to draw the "dependency from driver to firmware" line seem to be: 1: a dependency exists if the driver needs access to a copy of the firmware (for devices that need the firmware uploaded on every boot); 2: a dependency exists if the hardware needs firmware at all; There is no way to determine if a device that needs a initialisation sequence is in the first or in the second part. The sequence might just be a safeguard against accidental activation, or it might patch the firmware. For instance if you start an wifi device it has to know your country. Is this just used to configure the device or is it used to patch the firmware so it does not have to do lookups all the time? We cannot know. Groetjes, Peter
Re: LCC and blobs
Raul Miller wrote: Fundamentally, the DFSG is aimed at making sure that we can provide the software that we can support. Restrictions that leave us writing an opaque blob of bits which drives an unknown API very much put us into a context where we can't know that we're doing the right thing. The API is known, otherwise there would be no Linux driver. The fact that we uploaded the firmware does not excuse the device from respecting its API. Nor is it our task to write the firmware, Debian is a distribution for general-purpose computers, if you want to have a distribution for firmware you are free to do so. Debian should consider hardware as things that you have to talk to with a certain protocol. [hardware with build in flash that lost the flash] However, unlike non-flash devices that need the firmware uploaded every time, the driver is still useful without it. Yes. It is useful to re-upload the flash. Nothing else. So what is the difference between this use and the driver that has to load it every time? Groetjes, Peter
Re: LCC and blobs
Matthew Palmer wrote: Should I go on? No, I think you've adequately demonstrated that you don't have the foggiest idea what you're talking about. Ok. I'm game. Why? Where is the error my in applying your rules? Groetjes, Peter
Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues
John Goerzen wrote: On Thu, Dec 16, 2004 at 10:43:37PM +0100, Wouter Verhelst wrote: Thus, the answer to the failure of the LSB is not "the Free Software people should be more helpful to the non-free people"; the correct answer is "the non-free people should be more helpful to the Free Software people". Very well written, Wouter. Thanks. I agree. One other possibility -- and I don't know if it's true or not -- is that the organization working on LSB is itself the problem. As a person who has seen an ISV in action I think the main problem is that they know the software works with product X, version Y. What they do not know is which properties of the product they are using, so if a new version comes out they have no way of knowing if it will work. The fact the glibc is known for incompatible changes in its ABI is not helping... Sun solves this by having a tool call appcert. http://developers.sun.com/solaris/articles/appcert.html it checks if the application only uses the "official" Sun API. Groetjes, Peter
Re: LCC and blobs
Brian Thomas Sniffen wrote: Peter Van Eynde <[EMAIL PROTECTED]> writes: Is your name input for a state-machine? You should see what it does to TECO. My name is a killing word. :-) >>[data == software ?] Bingo. Debian had this debate last year. There was a giant vote over it. Then another debate and another vote. Hmm. I remember we had an "editorial change" that then turned into something completely different, followed by 6 damage limitation options and 1 hard line option. A damage limitation option won, but I if I read the matrix correctly the hard line option was defeated by _every_ damage limitation clause, so I would not be so certain that "we had this debate". Post-sarge we will have the debate and I hope that this time ftp-master will state the consequences of the options in advance, so there are no surprises any more. Also having less then 7 options would also be nice. >[clarifications] I think I'm starting to understand your point of view. So _any_ use of the software without using non-DFSG data makes it free, right? But what if loading the firmware is not required? That if the device was "warm-booted" in another OS? (I know there are technical limitations here) Would the driver-firmware relation still be a "depends"? Oh, I have another use for the ipw2100 driver without firmware: it can recognise the card from the pci-id information. :-) Please at least read Policy on what "Depends" means first. If you I see no mention of this in version 3.6.1.1. There is: |5.6.9. Package interrelationship fields -> see chapter 7 |7.2. Binary Dependencies -> is for debian packages. And has: |... |The `Depends' field should be used if the depended-on package is required |for the depending package to provide a significant amount of |functionality. |... |7.6. Relationships between source and binary packages ->N/A There is no mention of dependency of packages on external data that fall outside the packaging system. So what meaning do you mean? If you extend the rules for packages to firmware then the question becomes what "significant amount of functionality" is. In the past it was used for "can run", optional libraries were "Suggest"ed in. [EMAIL PROTECTED]:~ :) $ cd /usr/lib/hotplug/firmware/ [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ ls ipw2100-1.0.fwipw2100-1.1-p.fw ipw2100-1.2-p.fw ipw2100-1.3-p.fw ipw2100-1.1.fwipw2100-1.2.fwipw2100-1.3.fwisl3890 ipw2100-1.1-i.fw ipw2100-1.2-i.fw ipw2100-1.3-i.fw LICENSE [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mkdir t [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mv * t/ mv: cannot move `t' to a subdirectory of itself, `t/t' [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :( $ l t/ [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo modprobe -v ipw2100 insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211_crypt.ko insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211.ko insmod /lib/modules/2.6.8-1-686/kernel/drivers/base/firmware_class.ko insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ipw2100.ko The module loaded without firmware, not? It detected my card, but failed to load the firmware. ipw2100: Detected Intel PRO/Wireless 2100 Network Connection ipw2100: eth1: Firmware 'ipw2100-1.3.fw' not available or load failed. ipw2100: eth1: ipw2100_get_firmware failed: -2 ipw2100: eth1: Failed to power on the adapter. ipw2100: eth1: Failed to start the firmware. ipw2100Error calling regiser_netdev. ipw2100: probe of :02:02.0 failed with error -5 I would say this is a functional driver. It provides me with useful information about my system. The fact that I cannot connect to a wifi lan is the same situation as with grub not being able to load XP without the XP bootsector, if there were a free firmware with the same API I would be able to load and use it. also read the archives, you'll have a chance at understanding the position of other debaters here, and of generating original arguments. So far, this is all a repeat. It wasn't convincing any of the last couple times, so it won't be this time. Well. The last couple of times I thought rationality would return and I grew tired of the gedanken-experiments going on, and actually I did not care for the documentation idiocy. I should have paied more attention to my history classes and how extremists will take over democratic regimes because the majority cannot be bothered resisting simplistic arguments until it is too late. Making Debian uninstallable because of mistaken beliefs is too much and I care enough to resists this. I survived Erik Naggum, so this should be a walk in the park. Groetjes, Peter
Re: LCC and blobs
Raul Miller wrote: On Fri, Dec 17, 2004 at 10:39:26AM +0100, Peter Van Eynde wrote: The API is known, otherwise there would be no Linux driver. The API that is programmed by the firmware -- which you shouldn't confuse with the API used by the driver that downloads the firmware -- is not known to us. I don't understand you. An API is not "programmed". Something can provide or support an API or use an API. In this case the firmware+hardware provides and API to the linux driver. It is known, we can support it. If the device has bugs in executing the API it makes no difference if there is a firmware or not to the driver, nor does it to our support because we don't provide the firmware, we only use it. The mere fact of uploading the firmware does not give us an obligation to support it. If your printer misprints a page you don't expect debian to patch it do you? ... It is useful to re-upload the flash. Nothing else. So what is the difference between this use and the driver that has to load it every time? The "has to" bit. If the "has to" is to do a specific task, eg connecting to a wifi network, then the "has to" is no different from grub loading the XP bootsector. In the other case the ipw2100 driver already loads and does some (very limited) work. Groetjes, Peter
status of vore?
Hello, I would need to have access to a sid chroot on sparc to build sbcl by hand, but vore seems to be unreachable by me. The machine page [1] shows no indication of problems, it is outdated? Groetjes, Peter 1: http://db.debian.org/machines.cgi?host=vore -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson| pgpcW2wChqwnG.pgp Description: PGP signature
Re: status of vore?
On Monday 21 November 2005 12:07, Ingo Juergensmann wrote: > I could give you an account on a sparc machine with unstable chroot, but > that's a non-debian.org machine, so it's mostly usuable for debugging and > not for a build of an binary upload. Thanks, but as the main goal is creating a new debian package I fear I will just have to wait for another 'official' sparc machine. Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345657: ITP: cl-s-base64 -- A Common Lisp implementation of Base64 Encoding/Decoding
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-s-base64 Version : 20051102 Upstream Author : Sven Van Caekenberghe * URL : http://homepage.mac.com/svc/s-base64/ * License : LLGPL Description : A Common Lisp implementation of Base64 Encoding/Decoding A Common Lisp implementation of Base64 Encoding/Decoding S-BASE64 is an open source Common Lisp implementation of Base64 Encoding and Decoding. Base64 encoding is a technique to encode binary data in a portable, safe printable, 7-bit ASCII format. For a general introduction, please consult the Wikipedia article on Base64. This simple package is used as a building block in a number of other open source projects, as can be seen from this description of some other Open Source Common Lisp packages. . Homepage: http://homepage.mac.com/svc/s-base64/ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.2mine2 Locale: [EMAIL PROTECTED], LC_CTYPE=it_IT (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345658: ITP: cl-s-sysdeps -- An Abstraction Layer Over Platform Dependent Functionality
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-s-sysdeps Version : 20051122 Upstream Author : Sven Van Caekenberghe * URL : http://homepage.mac.com/svc/s-sysdeps/ * License : LLGPL Description : An Abstraction Layer Over Platform Dependent Functionality S-SYSDEPS is an abstraction layer over platform dependent functionality. This simple package is used as a building block in a number of other open source projects. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.2mine2 Locale: [EMAIL PROTECTED], LC_CTYPE=it_IT (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345661: ITP: cl-s-utils -- A collection of Common Lisp utilities
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-s-utils Version : 20051212 Upstream Author : Sven Van Caekenberghe * URL : http://homepage.mac.com/svc/s-utils/ * License : LLGPL Description : A collection of Common Lisp utilities S-UTILS is collection of Common Lisp utilities. This simple package is used as a building block in a number of other open source projects. . S-UTILS helps in: manipulating directory pathnames,copying streams, doing some elementary parsing (tokenizing), flexibly formatting dates, times and durations and parsing integers more safely. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.2mine2 Locale: [EMAIL PROTECTED], LC_CTYPE=it_IT (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345663: ITP: cl-s-http-server -- A Minimal Standalone Common Lisp HTTP Server
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-s-http-server Version : 20051218 Upstream Author : Sven Van Caekenberghe * URL : http://homepage.mac.com/svc/s-http-server/ * License : LLGPL Description : A Minimal Standalone Common Lisp HTTP Server S-HTTP-SERVER is a minimal standalone HTTP Server. This simple package is used as a building block in a number of other open source projects. . S-HTTP-SERVER can: handle HTTP requests and generate HTTP responses, be configured with plugins or handlers, has a builtin status handler, comes with a static resource handler and allows you to write and install your own handlers -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.2mine2 Locale: [EMAIL PROTECTED], LC_CTYPE=it_IT (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345665: ITP: cl-kpax -- A Common Lisp Application Framework
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-kpax Version : 20051222 Upstream Author : Sven Van Caekenberghe * URL : http://homepage.mac.com/svc/kpax/ * License : LLGPL Description : A Common Lisp Application Framework KPAX is a Common Lisp Web Application Framework. Altough KPAX is quite mature and has been in production use for years, the documentation is currently not good enough to support use by the general public. . KPAX allows you to build web applications and to run standalone and behind apache+mod_lisp or portableaserver -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.2mine2 Locale: [EMAIL PROTECTED], LC_CTYPE=it_IT (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310665: ITP: cl-rfc2388 -- an implementation of RFC 2388 in Common Lisp
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-rfc2388 Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : an implementation of RFC 2388 in Common Lisp rfc2388 is an implementation of RFC 2388, which is used to process form data posted with HTTP POST method using enctype "multipart/form-data". . The main functions of interest are PARSE-MIME and PARSE-HEADER. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.10-my7 Locale: [EMAIL PROTECTED], LC_CTYPE=it_IT (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
Hello, Daniel Holbach wrote: > I set up http://www.ubuntulinux.org/wiki/UniverseNewPackages some time ... > Ideally, both, the Debian maintainer and the Ubuntu maintainer should > work together and make it an absolutely rocking package with no flaws > and a perfectly crafted packaging system. A message like this makes you the perfect victim :-) for my question: what should a debian maintainer do to have his or her packages in universe in a good shape? I'm even willing to build the packages myself, but I fail to see how the pieces fit together. Where do universe bugs go? Who decides which version goes into universe? What do to with my packages that cannot be 'source only' like cmucl? The fact that the MOTS seem to place a high importance on IRC, which I cannot use at work, and the wiki seems a little off-putting. Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
binary uploads sometimes are required Was: Is Ubuntu a debian derivative or is it a fork?
Hello, While this is getting a little off topic, I just wanted to correct a common misconception. Wouter Verhelst wrote: >>I'm not sure what you mean by this; do you mean packages with circular >>dependencies which must be bootstrapped manually? If so, this is generally >>handled by our buildd admins. > > > Actually, it's handled by those that start the port. Once one version of > said package has been compiled and is available, the previous version > can always be used to build the next version. > With normal packages I agree, but what about packages like the perversion that is cmucl where the developers only guarantee that a certain release will build that release and no future one[1]? The build-procedure to get from an older to a newer release can be contrived and involve manually patching the image as it is constructed. In general one would need access to the architecture involved and then construct the new package from the binary release upstream issues. The related sbcl project can build a new release with an older version. Notice that there are more architectures supported for sbcl then for cmucl in Debian. On the upside, gcc/libc version changes cause me little or no problems :-). 1: see for example http://article.gmane.org/gmane.lisp.cmucl.devel/7925 Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312293: ITP: cl-utilities -- a Common Lisp library of common functions
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-utilities Version : 1.1 Upstream Author : Peter Scott * URL : http://common-lisp.net/project/cl-utilities/ * License : public domain Description : a Common Lisp library of common functions This package provides a library of semi-standard functions that are otherwise re-implemented in many projects. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.10-my7 Locale: [EMAIL PROTECTED], LC_CTYPE=it_IT (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
Alle Thursday 03 August 2006 13:42, Otavio Salvador ha scritto: > Alexander Sack <[EMAIL PROTECTED]> writes: > > > Anyway, as a side note on this thread: *darcs is just far t > > slow* for decent maintenance of large pieces of software. I tried once > > to create a mozilla repository, do some work with it and it was completely > > unusable. I am not talking about minutes, but almost hours to finish > > tasks that should take seconds. > > It has improved a lot in last releases. You might redo your try. As a recent post of mine to darcs-devel [1] shows it seems to be going well for a while and then after a few upstream releases it just breaks down. Hints for solving this mess would be appreciated, I'm investigating bzr at the moment, but tailor doesn't seem to like it all that much either seeing all the errors I get. Groetjes, Peter 1: http://article.gmane.org/gmane.comp.version-control.darcs.user/10145 never mind my idiotic duplicate. -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FIRST CALL FOR VOTES FOR "DFSG #2 applies to all programmatic works"
> > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > 22fc4edd-1f6c-454f-b204-6aa0bad0ce1d > [ ] Choice 1: DFSG #2 applies to all programmatic works > [ 1 ] Choice 2: Further discussion > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- pgpJGXAIXbUre.pgp Description: PGP signature
Re: FIRST CALL FOR VOTES FOR "DFSG #2 applies to all programmatic works"
On Sunday 01 October 2006 01:05, Debian Project Secretary wrote: > > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > 22fc4edd-1f6c-454f-b204-6aa0bad0ce1d > [ ] Choice 1: DFSG #2 applies to all programmatic works > [ 1 ] Choice 2: Further discussion > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- pgpdsg0eky9NL.pgp Description: PGP signature
Re: Call for votes for "GR: : Handling source-less firmware in the Linux kernel"
On Sunday 08 October 2006 01:52, Debian Project Secretary wrote: > > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > c2d43675-9efa-4809-a4aa-af042b62786e > [ 2 ] Choice 1: Release Etch even with kernel firmware issues > [ 1 ] Choice 2: Special exception to DFSG2 for firmware as long as required > [3:1] > [ 3 ] Choice 3: Further discussion > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394171: ITP: cl-trivial-https -- a fork of trivial-http with https support
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-trivial-https Version : 20051125 Upstream Author : Brian Mastenbrook / David Lichteblau * URL : http://common-lisp.net/project/cl-plus-ssl/ * License : BSD Programming Lang: Common Lisp Description : a fork of trivial-http with https support https support is added using cl-plus-ssl. trivial-http is a trivial networking library for doing HTTP POST and GET (web client operations) over a socket interface. . Homepage: http://common-lisp.net/project/cl-plus-ssl/ -- 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.18-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394163: ITP: cl-hunchentoot -- The Common Lisp web server formerly known as TBNL
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-hunchentoot Version : 0.4.4 Upstream Author : Dr. Edmund Weitz * URL : http://weitz.de/hunchentoot/ * License : BSD Programming Lang: Common Lisp Description : The Common Lisp web server formerly known as TBNL Hunchentoot is a web server written in Common Lisp and at the same time a toolkit for building dynamic websites. As a stand-alone web server, Hunchentoot is capable of HTTP/1.1 chunking (both directions), persistent connections (keep-alive), and SSL, but it can also sit behind the popular Apache using Marc Battyani's mod_lisp. . Hunchentoot provides facilities like automatic session handling (with and without cookies), logging (to Apache's log files or to a file in the file system), customizable error handling, and easy access to GET and POST parameters sent by the client. It does not include functionality to programmatically generate HTML output. For this task you can use any library you like, e.g. (shameless self-plug) CL-WHO or HTML-TEMPLATE. . Homepage: http://weitz.de/hunchentoot/ -- 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.18-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394161: ITP: cl-plus-ssl -- A simple Common Lisp interface to OpenSSL
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-plus-ssl Version : 20060904 Upstream Author : various * URL : http://common-lisp.net/project/cl-plus-ssl/ * License : Lisp LGPL Programming Lang: Common Lisp Description : A simple Common Lisp interface to OpenSSL This library is a fork of SSL-CMUCL. The main differences are that this library uses protable code based on cffi and gray streams. With this it defined a libssl BIO portable lisp streams based IO. . Homepage: http://common-lisp.net/project/cl-plus-ssl/ -- 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.18-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394223: ITP: cl-cffi -- The Common Foreign Function Interface for Common Lisp
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-cffi Version : 20061013 Upstream Author : James Bielman * URL : http://common-lisp.net/project/cffi/ * License : BSD Programming Lang: Common Lisp Description : The Common Foreign Function Interface for Common Lisp CFFI, the Common Foreign Function Interface, purports to be a portable foreign function interface for Common Lisp. The CFFI library is composed of a Lisp-implementation-specific backend in the CFFI-SYS package, and a portable frontend in the CFFI package. . The CFFI-SYS backend package defines a low-level interface to the native FFI support in the Lisp implementation. It offers operators for allocating and dereferencing foreign memory, calling foreign functions, and loading shared libraries. The CFFI frontend provides a declarative interface for defining foreign functions, structures, typedefs, enumerated types. It is implemented in portable ANSI CL making use of the low-level operators exported by CFFI-SYS. . A UFFI compatibility layer is also being developed. . Homepage: http://common-lisp.net/project/cffi/ -- 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.18-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394603: ITP: cl-chunga -- Portable chunked streams for Common Lisp
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-chunga Version : 0.2.0 Upstream Author : Dr. Edmund Weitz * URL : http://weitz.de/chunga/ * License : BSD Programming Lang: Common Lisp Description : Portable chunked streams for Common Lisp Chunga implements streams capable of chunked encoding on demand as defined in RFC 2616. For an example of how these streams can be used see Drakma. . Chunga is currently not optimized towards performance - it is rather intended to be easy to use and (if possible) to behave correctly. . Homepage: http://weitz.de/chunga/ -- 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.18-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#321253: ITP: cl-closer-mop -- Cross implementation AMOP library
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-closer-mop Version : 0.2 Upstream Author : Pascal Costanza * URL : http://common-lisp.net/project/closer/ * License : MIT-style Description : Cross implementation AMOP library This library enhances the different MOP implementations so that they support better the AMOP specifications. . The CLOS spec contained two parts, only the basic level went into the Common Lisp standard. The lower level functions of the AMOP were not included so different implementations differ (mostly slightly) in how to implement the AMOP. . With the help of cl-closer-mop you can use the full power of AMOP on all supported implementations, relying on the library to translate your code. . Supported implementations: Allegro Common Lisp, Clisp, cmucl, LispWorks, OpenMCL and SBCL (version restrictions might apply) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-my Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#321252: ITP: cl-lw-compat -- LispWorks Compatibility Library
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-lw-compat Version : 0.2 Upstream Author : Pascal Costanza * URL : http://common-lisp.net/project/closer/ * License : MIT-style Description : LispWorks Compatibility Library This library a portable implementation of a set of utility functions provided by lwl. It is required by cl-closer-mop. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-my Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [cl-debian] modifying home directories by maintainer scripts (was: Re: Bug#329347: common-lisp-controller: checking of permissions of the output directory)
On Wednesday 21 September 2005 15:49, René van Bevern wrote: > > A lot of packages install stuff in the user directory. > > I doubt that any package does this. 1/[EMAIL PROTECTED]:~ :( $ grep '^/home/' /var/lib/dpkg/info/*.list 1/[EMAIL PROTECTED]:~ :( $ None on my system. > Not by packages or their scripts and not without user > interaction. It's dangerous. After thinking it over I do agree with this. I will resist any change to move the cache directory over to a location beneath /home unless there is a change in debian policy on this. I am willing to provide hooks to permit a user to move the fasls to a location of choice. I fear I did not have time yet to investigate cl-launch but I'll try to make some time for it. Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson| pgpSZS30mOjT4.pgp Description: PGP signature
How to get rid of a poised version
Hello,
Mea culpa. I did a stupid thing with sbcl: in version 1:0.9.6.0-1 I used the
following construction:
Package: sbcl
Depends: sbcl-common (= ${Source-Version}), ${shlibs:Depends}
...
Package: sbcl-common
Now it turns out that the buildd network cannot build new packages[1]:
|The following packages have unmet dependencies:
| sbcl: Depends: sbcl-common (= 1:0.9.6.0-1) but 1:0.9.6.0-6 is to be
| installed
Now, after thinking a bit I dropped the Depends, but I cannot force the
buildd's to build a new version. I tried:
- to force to use a known good version: (1:0.9.6.0-4)
Build-Depends: debhelper (>> 4.1.16), sbcl (= 1:0.9.5.50-1) ...
This also failed [2]:
|The following packages have unmet dependencies:
| sbcl: Depends: sbcl-common (= 1:0.9.6.0-1) but it is not going to be
|| installed
-include sbcl-common into the build-depends (1:0.9.6.0-6)
Build-Depends: debhelper (>> 4.1.16), sbcl-common, sbcl (>= 1:0.8.16-1)
Also [3]:
|The following packages have unmet dependencies:
| sbcl: Depends: sbcl-common (= 1:0.9.6.0-1) but 1:0.9.6.0-6 is to be
| installed
So is there anything else I can do?
Groetjes, Peter
1:
http://buildd.debian.org/fetch.php?&pkg=sbcl&ver=1%3A0.9.6.0-6&arch=alpha&stamp=1130914277&file=log&as=raw
2:
http://buildd.debian.org/fetch.php?&pkg=sbcl&ver=1%3A0.9.6.0-4&arch=alpha&stamp=1130888045&file=log&as=raw
3:
http://buildd.debian.org/fetch.php?&pkg=sbcl&ver=1%3A0.9.6.0-6&arch=alpha&stamp=1130914277&file=log&as=raw
--
signature -at- pvaneynd.mailworks.org
http://www.livejournal.com/users/pvaneynd/
"God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#170774: ITP: cl-pg -- Common Lisp library that provides a socket level postgresql interface.
Package: wnpp Version: N/A; reported 2002-11-08 Severity: wishlist * Package name: cl-pg Version : 0.14 Upstream Author : Eric Marsden <[EMAIL PROTECTED]> * URL : http://www.chez.com/emarsden/downloads/ * License : LGPL Description : Common Lisp library that provides a socket level postgresql interface. Pg is a socket-level interface to the PostgreSQL object-relational Database. The Library implements the client part of the frontend/backend protocol, so does not require interfacing with the libpq library. SQL types are converted to the equivalent Common Lisp types where possible. Supports large objects (BLOBs). Groetjes, Peter -- It's logic Jim, but not as we know it. | [EMAIL PROTECTED] "God, root, what is difference?" - Pitr| http://people.debian.org/~pvaneynd/ "God is more forgiving." - Dave Aronson| http://users.belgacom.net/pvaneynd/ pgpU3JPyrfiYF.pgp Description: PGP signature
Re: Bug#33262: xlib6g now depends on xfree86-common (?)
On Thu, Feb 11, 1999 at 08:49:06PM -0500, Branden Robinson wrote: > Package: cmucl-clx > Version: 2.4.9 > > On Fri, Feb 12, 1999 at 12:04:19AM +0100, Pierre Mai wrote: > > This has in fact already happened some time ago, as can be witnessed > > by CLX, which is an implementation of the X protocol for and in Common > > Lisp, and has been the de-facto standard for Common Lisp X programs > > for quite some time (see X11 contrib tapes). And indeed it has > > already been packaged for Debian, as part of Peter Van Eynde's CMU CL > > packages (cmucl-clx). > > Huh, I'll be damned. I knew a Common LISP equivalent of Xlib existed, but > I thought it was long dead and not packaged for Debian. I shouldn't > underestimate my own distribution like that. :) > > Can I ask that cmucl-clx *please* depend on xfree86-common for frozen and > unstable? Done in 2.4.13. Groetjes, Peter -- It's logic Jim, but not as we know it. | [EMAIL PROTECTED] for pleasure, "God, root, what is difference?",Pitr | [EMAIL PROTECTED] for more pleasure!
Re: 64-bit time_t transition for 32-bit archs: a proposal
Hi, On Wed, Jun 7, 2023, at 09:19, Sune Vuorela wrote: > lisp runtie. unsure why restricted >> cmucl deb lisp optional arch=i386 >> cmucl-clm deb lisp optional arch=i386 cmucl contains a compiler and is self hosting (the compiler is used to create the new version of the environment). x86 is the last active architecture for this system, but as a whole it is slowly drying. Most people moved on to using sbcl, which supports amd64 and has a more active development. I planned to ask for removal of cmucl after the next release. End of an era... Best regards, Peter
