[RFS] cmarrows
Hello, I have created a Debian package for `cmarrows'. "This is a METAPOST package for arrows and braces in the computer modern style. The arrows offer the same flexibility as the ordinary arrow macro in metapost. The braces can be made to follow an arbitrary path and you can control at which path time the middle piece is drawn." Motivation: the `plain' METAPOST format contains a single command (drawarrow) for drawing one kind of arrows. This package contains definitions of various common kinds of arrows which could be useful within METAPOST figures. I used this macro package for some time. I think that it is useful (for METAPOST fans). Here: http://altair.dcs.elf.stuba.sk/wiki/Kosik/DebianStuff is information how to get the current version of the package I created. The fact that the original software was put to public domain (no licensing restrictions were imposed on it by the original author AFAIK) permits me to attach FSF GPL to it. I did that. This was somewhat arbitrary. Hopefully (I am not lawer. I consulted DFSG-FAQ point 15) it is legal and in concord with Debian policy. If anyone wants to play with it and has any suggestions how to improve this package, I am open to discussion and correction of the problems that could emerge. It would be great if this package entered `main'. Regards -- Matej Kosik signature.asc Description: OpenPGP digital signature
Re: [RFS] cmarrows
Hello Justin, Thank you for the your answer. Justin Pryzby wrote: > On Wed, Jun 21, 2006 at 10:47:37AM +0200, Matej Kosik wrote: > >>Hello, >> >>I have created a Debian package for `cmarrows'. >> >>"This is a METAPOST package for arrows and braces in the computer modern >>style. The arrows offer the same flexibility as the ordinary arrow macro >>in metapost. The braces can be made to follow an arbitrary path and you >>can control at which path time the middle piece is drawn." >> >>Motivation: the `plain' METAPOST format contains a single command >>(drawarrow) for drawing one kind of arrows. This package contains >>definitions of various common kinds of arrows which could be useful >>within METAPOST figures. I used this macro package for some time. I >>think that it is useful (for METAPOST fans). >> >>Here: >>http://altair.dcs.elf.stuba.sk/wiki/Kosik/DebianStuff >>is information how to get the current version of the package I created. >> >>The fact that the original software was put to public domain (no > > Does something in the software package say so? Uff. I wrongly assumed that software available on the internet without any restrictions (no licensing information, no "public domain" statement ) could be considered to be "public domain". As you say, it is not true. Thus, the original software is "all rights reserved". That means that noone (other than the original author---the coopyright holder) can: - distribute it - modify it - ditribute modified versions. Am I right? If that is true, it (unless it would be relicensed or put to public domain by copyright holder) it would be illegal to include it to the Debian project (either in `main' or to `non-free' sections). Am I right? [snip] -- Matej Kosik signature.asc Description: OpenPGP digital signature
Re: [RFS] cmarrows
Adam Borowski wrote: > > However, the correct thing to do now is "mail upstream", not "drop the > package". I did that. And happily, Mr Ekola (the author) replied as follows: -- >>(me) >>Unfortunatelly, you do not specify any particular >>license which applies to that software and thus, >>by default, you hold "all rights reserved". >>In such situation noone but you can legally spread your work. (Mr Ekola) My intent is for cmarrows to be free software (or even public domain). The reason I haven't written an explicit licence is the following: cmarrows includes metafont code from the computer modern fonts written by Donald Knuth, which is not a problem since Knuth released his fonts in the public domain, but it also includes metafont code from the ams fonts (i.e. msam*.mf and msbm*.mf) and I have always been under the impression that these fonts are also in the public domain, but when I inspect, for example, msam10.mf is says %% copyright="Copyright (C) American Mathematical Society, %%all rights reserved. Copying of this file is %%authorized only if either: %%(1) you make absolutely no changes to your copy %%including name; OR %%(2) if you do make changes, you first rename it to some %%other name.", I am not a lawyer so I decided to remain blissfully ignorant of any licencing issues and simply not give an explicit license just in case I need to pull the code. If you, or anyone else, can assure me that the ams fonts are indeed in the publich domain (if that is what the copyright message above means) then I will gladly release cmarrows with a free licence (you might even suggest a suitable licence if you like). -- So he can be contacted and is willing to reconsider the licensing of `cmarrows'. He used some code from Donald E. Knuth's CM fonts (METAFONT code) as well as some code copyrighted (as noted above) by AMS (also METAFONT code). He embedded a borrowed METAFONT code to its METAPOST programs. All METAFONT programs have *.mf suffix. METAPOST programs have *.mp suffix. So clearly, borrowed pieces of programs are distributed in files with different names. It seems quite clear to me that there are no reasons why Mr Tommy Ekola couldn't attach any DFSG compliant license to the `cmarrows'. Am I right? AFAIK options are: public domain, MIT, BSD, GPL. -- Matej Kosik signature.asc Description: OpenPGP digital signature
Minix3 OS running inside qemu
Dear mentors, I have created a Debian package with which it is possible to conveniently install and run Minix running on QEMU. It might be useful for those, who want to look at it closer and play with it. Package name: minix Version: 3.1.2.3 Upstream author: various people, copyright holder is Vrije Universiteit, Amsterdam, The Netherlands License: http://www.minix3.org/license.html (it applies to the `minix.img.gz' file) The package is native. The harddisk image was produced from the Minix3 bootable CD version 3.1.2. Useful properties - (of course) straightforward installation of fully configured Minix3 system - networking over QEMU is enabled - Handy `/usr/bin/minix' script - `minix' script manual page - integration to the debian menu system (Apps/Programming/Minix) - the QEMU harddisk image could grow on demand (up to 1GB). Initially it occupies 59MB. - various people using the same computer might run Minix in the same way but each could have a different harddisk image. Possible problems: - the manual page might contain grammatical errors - since the networking over QEMU is enabled by default, the problems might arise when someone tried to install this package on a computer with no Internet connection. In that case the Minix configuration files related to networking must be altered manually. (The debian package itself has 11MB). Here is the *.deb file: http://altair.dcs.elf.stuba.sk/~kosik/debian/dists/etch/main/binary-i386/devel/minix_3.1.2.4_i386.deb The `minix' package can be obtained from the repository deb http://altair.dcs.elf.stuba.sk/~kosik/debian/ testing main deb-src http://altair.dcs.elf.stuba.sk/~kosik/debian/ testing main For `stable', there is a available distinct version (because of the changes of qemu command line parameters) deb http://altair.dcs.elf.stuba.sk/~kosik/debian/ stable main deb-src http://altair.dcs.elf.stuba.sk/~kosik/debian/ stable main Any suggestions are welcome. If it had sense to add it to the Debian project, I would gladly try to polish it to an acceptable state. Kind regards -- Matej Kosik signature.asc Description: OpenPGP digital signature
Re: Minix3 OS running inside qemu
Jaldhar H. Vyas wrote: > On Sun, 16 Jul 2006, Matej Kosik wrote: > >> Dear mentors, >> >> I have created a Debian package with which it is possible to >> conveniently install and run Minix running on QEMU. It might be useful >> for those, who want to look at it closer and play with it. >> > > This is interesting to me and I would consider sponsoring it. That would be great! Thank you. > However > from Debians point of view, there is one important factor to consider. > It must be possible to build the package from source. But it looks to > me that you just copy the disk image into the package.> Is this > correct? Is there anyway you can work creating the disk image into the > build process? > The `/usr/share/minix/minix.img.gz' is an image of a harddisk (in one of the QEMU formats). It has sense to distribute harddisk image because it is precooked, directly bootable (with QEMU), this debian package provides quick (automated) installation. Concerning the source code, there are two related facts: 1. the source code of the kernel, of various other parts of the operating system as well as of every single command in a fresh installation are part of that harddisk image. They can be found (if you boot Minix) in directory `/usr/src'. There would be no point of distributing Minix without source code since it is partially targeted to education. Hitherto, I haven't found any problem with modifying anything building it and installing it. If there would be such problem, that would be an error in a distribution. You can check if some source code is missing but I do not believe so. 2. There is a bootable CD http://www.minix3.org/download/ the procedure (not in a computer language) by which one can produce equivalent harddisk image is part of this Debian package. You can look at /usr/share/doc/minix/NOTES The procedure which properly populates the partition with Minix3 distribution is part of the installation program which is ran if you boot the bootable Minix3 live CD and execute `setup'. I suspect that from Linux one cannot mount the Minix3 partitions. Such a filesystem support could be implemented, though. But Minix3 does not need it install itself. I do not know how exactly is produced the Minix3 CD. If you boot Minix, in directory /usr/src/tools there is a script release.sh which, I guess, is somehow related. Very few people need to build the bootable CD from scratch. If it were important, I could try to do that. Regards -- Matej Kosik signature.asc Description: OpenPGP digital signature
A problem with dh_strip
Dear mentors, I am trying to create a Debian package for the Pict programming language. http://www.cis.upenn.edu/~bcpierce/papers/pict/Html/Pict.html The package itself is here http://altair.dcs.elf.stuba.sk/~kosik/debian/pool/main/p/pict/pict_4.1.0-1.dsc I have successfully built it within pbuilder environment. However, I have observed a weird behavior of the binary when I let dh_strip it. The binary is installed into /usr/lib/pict/pict (the /usr/bin/pict is only a script that calls the binary with pre-set environment variables required by the original software) The original and the dh_stripped versions of the binary differ - the original does recognize the `--help' option, the dh_stripped does not recognize it - when I run the original binary without any parameters, it complains "You must specify exactly one input file" whereas the dh_stripped bersion prints something else. - and other things Major part of the orignal binary is compiled from OCAML sources so maybe there is some specific error behavior of dh_strip related to these kind of binaries. I would welcome any helping hand with this problem. Thanks in advance -- Matej Kosik signature.asc Description: OpenPGP digital signature
RFS: pict
I am looking for a sponsor for my package "pict". * Package name: pict * Version: 4.1.0-1 * Upstream Authors: Benjamin C. Pierce David N. Turner * URL: http://altair.dcs.elf.stuba.sk/~kosik/debian/pool/main/p/pict/pict_4.1.0-1.dsc * Description: Compiler of the Pict programming language Pict is a programming language in the ML tradition, formed by adding high-level derived forms and powerful static type system to a tiny core language. The core, Milner's pi-calculus, is becoming popular as a theoretical foundation for a broad class of concurrent applications. The goal in Pict is to identify and support idioms that arise naturally when these primitives are used to build working programs---idioms such as basic data structures, protocols for returning results, higher-order programming, selective communication, and concurrent objects. The type system integrates a number of features found in recent work on theoretical foundations for typed object-oriented languages: higher-order polymorphism, simple recursive data-types, subtyping, and a useful partial type inference algorithm. The package is lintian clean. The package is not linda clean E: pict; Binary /usr/lib/pict/pict contains unneeded section comment. E: pict; Binary /usr/lib/pict/src2pi contains unneeded section comment. E: pict; Binary /usr/lib/pict/src2tex contains unneeded section comment. E: pict; Binary /usr/lib/pict/pict is not stripped. E: pict; Binary /usr/lib/pict/src2pi is not stripped. E: pict; Binary /usr/lib/pict/src2tex is not stripped. because #256900: ocaml: Ocaml compiled programs cannot be stripped, hence either don't work or violate policy http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900 It is possible to build the package in the pbuilder environment. Although the software exists already for some time, it was not yet packaged for Debian. Regards, -- Matej Kosik signature.asc Description: OpenPGP digital signature
Re: RFS: pict
Stefano Zacchiroli wrote: > On Wed, Feb 21, 2007 at 03:00:07PM +0100, Matej Kosik wrote: >> I am looking for a sponsor for my package "pict". > > Have you read the OCaml packaging policy available in > /usr/share/doc/ocaml/ocaml_packaging_policy.txt.gz (ocaml package)? > Being a program implemented in OCaml it should obey to it. Thank you for the pointer, I will look at it today and see what changes are necessary. I will think that my package conforms those criteria too. Thanks for the pointer. > > I'm Cc-ing the debian-ocaml-maint mailing list (the contact point for > all maintainers of OCaml-related programs). People there (are supposed > to :-)) have good knowledge of OCaml packaging issues and you can be > probably more lucky in finding there a sponsor. > > Thanks for packaging pict! (which I guess is the same thing as "nomadic > pict", am I wrong?) According to the authors of Nomadic Pict http://www.cl.cam.ac.uk/~pes20/nomadicpict.html Nomadic Pict is an extension of Pict with the notion of locations, agents, migration, distribution, and failures. It is also interesting. The Pict programming language is its predecessor: http://www.cis.upenn.edu/~bcpierce/papers/pict/Html/Pict.html I have created Debian GNU/Linux package for this one. > > Cheers. > > PS fully quoting your post for the benefits of debian-ocaml-maint > readers > >> * Package name: pict >> * Version: 4.1.0-1 >> * Upstream Authors: Benjamin C. Pierce >> David N. Turner >> * URL: >> http://altair.dcs.elf.stuba.sk/~kosik/debian/pool/main/p/pict/pict_4.1.0-1.dsc >> * Description: Compiler of the Pict programming language >> Pict is a programming language in the ML tradition, >> formed by adding high-level derived forms and powerful >> static type system to a tiny core language. The core, >> Milner's pi-calculus, is becoming popular as a theoretical >> foundation for a broad class of concurrent applications. >> The goal in Pict is to identify and support idioms that >> arise naturally when these primitives are used to build >> working programs---idioms such as basic data structures, >> protocols for returning results, higher-order programming, >> selective communication, and concurrent objects. The type >> system integrates a number of features found in recent work >> on theoretical foundations for typed object-oriented languages: >> higher-order polymorphism, simple recursive data-types, subtyping, >> and a useful partial type inference algorithm. >> >> >> The package is lintian clean. >> >> The package is not linda clean >> E: pict; Binary /usr/lib/pict/pict contains unneeded section comment. >> E: pict; Binary /usr/lib/pict/src2pi contains unneeded section comment. >> E: pict; Binary /usr/lib/pict/src2tex contains unneeded section comment. >> E: pict; Binary /usr/lib/pict/pict is not stripped. >> E: pict; Binary /usr/lib/pict/src2pi is not stripped. >> E: pict; Binary /usr/lib/pict/src2tex is not stripped. >> because >> #256900: ocaml: Ocaml compiled programs cannot be stripped, hence either >> don't work or violate policy >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900 >> >> It is possible to build the package in the pbuilder environment. >> >> Although the software exists already for some time, it was not yet >> packaged for Debian. Regards -- Matej Kosik signature.asc Description: OpenPGP digital signature
Re: RFS: pict
Stefano Zacchiroli wrote: > On Wed, Feb 21, 2007 at 03:00:07PM +0100, Matej Kosik wrote: >> I am looking for a sponsor for my package "pict". > > Have you read the OCaml packaging policy available in > /usr/share/doc/ocaml/ocaml_packaging_policy.txt.gz (ocaml package)? > Being a program implemented in OCaml it should obey to it. Report on comformance of Pict to http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/index.html 1.1. Bytecode and Native Code Although some (important) parts of this software are written in OCaml (namely the Pict compiler in the `Pict' directory of the provided source code) here are also other components that must be distributed and installed too and they were not written in OCaml * some (the Pict runtime) are written in C (see the `Runtime' directory) This is compiled into native code and linked with compiled Pict programs * some (the Pict libraries) are written in Pict, they are compiled with the Pict compiler into native code and linked with Pict programs Since not all parts that must be distributed and are essential can be provided as OCaml bytecode, I think that the architecture of this package cannot be changed from `any' to `all'. Then I think it is safe to privde also the Pict compiler compiled to native code. Was my conclusion correct? Another question: Is there a way how could I try to compile this package for all architectures and see if everything works? I must admit, I am working on i386-compatible and the binaries I have created are also for this architecture. I think it would be too bold to say `any' if I have actually only tried `i386'. How do others try their packages on "other architectures" that whose instances they physically own? > > I'm Cc-ing the debian-ocaml-maint mailing list (the contact point for > all maintainers of OCaml-related programs). People there (are supposed > to :-)) have good knowledge of OCaml packaging issues and you can be > probably more lucky in finding there a sponsor. > > Thanks for packaging pict! (which I guess is the same thing as "nomadic > pict", am I wrong?) > > Cheers. > > PS fully quoting your post for the benefits of debian-ocaml-maint > readers > >> * Package name: pict >> * Version: 4.1.0-1 >> * Upstream Authors: Benjamin C. Pierce >> David N. Turner >> * URL: >> http://altair.dcs.elf.stuba.sk/~kosik/debian/pool/main/p/pict/pict_4.1.0-1.dsc >> * Description: Compiler of the Pict programming language >> Pict is a programming language in the ML tradition, >> formed by adding high-level derived forms and powerful >> static type system to a tiny core language. The core, >> Milner's pi-calculus, is becoming popular as a theoretical >> foundation for a broad class of concurrent applications. >> The goal in Pict is to identify and support idioms that >> arise naturally when these primitives are used to build >> working programs---idioms such as basic data structures, >> protocols for returning results, higher-order programming, >> selective communication, and concurrent objects. The type >> system integrates a number of features found in recent work >> on theoretical foundations for typed object-oriented languages: >> higher-order polymorphism, simple recursive data-types, subtyping, >> and a useful partial type inference algorithm. >> >> >> The package is lintian clean. >> >> The package is not linda clean >> E: pict; Binary /usr/lib/pict/pict contains unneeded section comment. >> E: pict; Binary /usr/lib/pict/src2pi contains unneeded section comment. >> E: pict; Binary /usr/lib/pict/src2tex contains unneeded section comment. >> E: pict; Binary /usr/lib/pict/pict is not stripped. >> E: pict; Binary /usr/lib/pict/src2pi is not stripped. >> E: pict; Binary /usr/lib/pict/src2tex is not stripped. >> because >> #256900: ocaml: Ocaml compiled programs cannot be stripped, hence either >> don't work or violate policy >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900 >> >> It is possible to build the package in the pbuilder environment. >> >> Although the software exists already for some time, it was not yet >> packaged for Debian. > Regards -- Matej Kosik signature.asc Description: OpenPGP digital signature
Re: RFS: pict
Hi Ralf Ralf Treinen wrote: > Hi, > > On Wed, Feb 21, 2007 at 06:45:55PM +0100, Matej Kosik wrote: > >> Is there a way how could I try to compile this package for all >> architectures and see if everything works? I must admit, I am working on > > Sort of, if you are a debian developer. There are debian > machines for all supported architectures where dds can login, > but this would mean of course compiling and testing "by hand". Good to know. I just have asked to be sure I did not overlooked such possibility (if it existed). > > One could use the the autobuilder network, maybe at first for > the "experimental" architecture if one has serious doubts that > everythings works on every architecture. From the `INSTALL' file Pict has been compiled successfully on these platforms: - Sun Sparc (SunOS and Solaris) - 486/586 (Linux) - DEC Alpha (Ultrix) I myself has tried to compile it on Debian GNU/Linux (and fixed one problem and reported it to the original developers) Neither compiler nor binaries created by the Pict compiler use any hardware-specific feature. Actually, very little additional functionality is needed (like some libc functions such as memcpy, memset, malloc, free) and the binaries created by the Pict compiler do not need any operating at all and can run in kernel mode (this is what I tried). Pict is the simpliest capability-secure language I have seen (although my view might not be very broad). So in this respect it is interesting (even though many things could be improved on the original package, but I did as little changes as possible so that it can still be called Pict). Capability security is very interesting and Debian GNU/Linux does not contain any programming language that would support it. (I might be wrong, though). This is partially why I submitted this package. The advantage of Pict over other capability secure languages I know (such as E www.erights.org) is that it can be directly compiled with free software tool s which are directly part of Debian GNU/Linux. > >> i386-compatible and the binaries I have created are also for this >> architecture. I think it would be too bold to say `any' if I have >> actually only tried `i386'. How do others try their packages on "other >> architectures" that whose instances they physically own? > > It depends on the case. In many cases you can reasonably expect that if > your package compiles and runs on one architecture then it is the > same on the other architectures. In other cases you can expect right > from the beginning difficulties. You as a package maintainer should > have some idea about this, if necessary by looking at critical > portions of the code, or sometimes from the compiling instructions > given by upstream. > > I guess that many developers just upload and then wait for bug > reports, or look at the buildd logs. But it is of course much > better to think of it in avance. > > -Ralf. If there is no better way on what architectures Pict works without problems, I would risk and do the same as more other people before me. It is always possible to fix problems later if some arise. In the worst case Pict could be declared as software solely for `386' but I think it will work also elsewhere. -- Matej Kosik signature.asc Description: OpenPGP digital signature
