Bug#1074772: ITP: gecode-snapshot -- low-level modelling language for constraint problems
Package: wnpp Severity: wishlist Owner: Kari Pahula X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gecode-snapshot Version : 6.2.0+gitMMDD Upstream Contact: Guido Tack , Mikael Zayenz Lagerkvist * URL : https://www.gecode.org/ * License : MIT/X (and others) Programming Lang: C++ Description : low-level modelling language for constraint problems FlatZinc is a low-level modelling language for constraint problems. It is designed to be easily interfaceable to constraint solvers (like Gecode). For more information on FlatZinc, please refer to the MiniZinc pages of the G12 project <https://www.minizinc.org/>. Source package name would be gecode-snapshot and it'll likely have a single binary package, gecode-flatzinc. Gecode is already in Debian, this is get an updated version of FlatZinc available for MiniZinc. Gecode hasn't had a release since 2019 and I need to use it as a library as well. Fuller description of the situation can be found at https://lists.debian.org/debian-devel/2024/06/msg00312.html Hopefully gecode-snapshot can be removed in the future when Gecode's had a release again.
Packaging Gecode twice to have newer snapshot for Minizinc
I have an unhappy situation with Gecode and Minizinc. Gecode offers two things: A shared C++ library, and a flatzinc programming language implementation. Minizinc is a programming language as well, whose implementation works by turning minizinc programs to flatzinc and uses an implementation to execute it. Much like the numerous languages outputting C or JS. Minizinc also requires Gecode library to compile itself, but that's an independent use from invoking a flatzinc executable. Indeed, flatzinc has multiple implementations and minizinc has support for picking one among them. Gecode's is just the default one and the one minizinc is bundled with in their upstream binaries. Debian has two others packaged, chuffed and ortools. Unfortunately chuffed is only a partial implementation and ortools is currently uninstallable and updating it is pending on absl library upgrade (which is no mean feat). Gecode has last had a release in 2019 and the flatzinc implementation offered by it is not sufficient to run current minizinc programs. A new Gecode release would be ideal but unfortunately prodding upstream is unlikely to have any quick results as the person who used to do them has passed away since. Minizinc is actively developed and has frequent releases. The current release of Gecode is still sufficient for Minizinc's use of it as a library and I expect it's going to remain that way. Just packaging a Gecode snapshot would solve the issues, but it would imply taking over the SONAME and I'm not willing to do that. ABI changes are upstream's call. I'm considering packaging Gecode again as gecode-snapshot and also keep the original gecode package. I'd remove the flatzinc executable from the original and only offer flatzinc from gecode-snapshot. Alternatively I could pick another flatzinc as a default. None of the currently packaged options are up to the task and I'd have to pick yet another one to package. There are options, some of which are free software. Another option would be to update to the snapshot and still offer a library but move it to some private directories and tell minizinc to use it from there and users to not touch it. There are no current rdepends on it other than minizinc. It wouldn't serve well any users who would be using the library and it'd feel making an even more of a special case of this compared to just going with gecode-snapshot. If nobody objects I'll proceed with an ITP on gecode-snapshot. If and when upstream makes a release I'll retire the package. This all relates to #1073819. I looked at it but there's a limit to what I can do to enable minizinc's features without touching the ABI.
Bug#1063388: ITP: chuffed -- lazy clause generation CP solver
Package: wnpp Severity: wishlist Owner: Kari Pahula X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org * Package name: chuffed Version : 0.13.1 * URL : https://github.com/chuffed/chuffed * License : MIT/X Programming Lang: C++ Description : lazy clause generation CP solver Chuffed is a state of the art lazy clause solver designed from the ground up with lazy clause generation in mind. Lazy clause generation is a hybrid approach to constraint solving that combines features of finite domain propagation and Boolean satisfiability. It combines some of the advantages of finite domain constraint programming (high level model and programmable search) with some of the advantages of SAT solvers (reduced search by nogood creation, and effective autonomous search using variable activities). Chuffed only supports 3 different propagator priorities. Chuffed implements a number of global propagators (alldiff, inverse, minimum, table, regular, mdd, cumulative, disjunctive, circuit, difference). It also only supports two kinds of integer variables. Small integer variables for which the domain is represented by a byte string. And large integer variables for which the domain is represented only by its upper and lower bound (no holes allowed). All boolean variables and boolean constraints are handled by the builtin SAT solver. The solver, when run with lazy clause generation disabled, is somewhat comparable in speed with older versions of Gecode. The overhead from lazy clause generation ranges from negligible to perhaps around 100%. The search reduction, however, can reach orders of magnitude on appropriate problems. Thus lazy clause generation is an extremely important and useful technology. The easiest way to use Chuffed is as a backend to the MiniZinc constraint modelling language. Chuffed can also be used as a C++ library. The description is edited from upstream's description, it went into more detail than this about the implementation. For certain types of CP problems it works better than the alternatives. Chuffed is both a library and it provides a binary (fzn-chuffed). The library can be used as a dependency for both minizinc and minizinc-ide (which I maintain) and it provides an alternative flatzinc implementation for minizinc. I plan to maintain this under the Debian Science team. As of now upstream is building chuffed as a static library only but I'll try to convince them to provide a shared library before packaging it.
Bug#928903: ITP: piperka-client -- Mobile oriented web comics reader client
Package: wnpp Severity: wishlist Owner: Kari Pahula * Package name: piperka-client Version : 0.2.1 Upstream Author : Kari Pahula * URL : https://gitlab.com/piperka/client * License : GPLv2 or later Programming Lang: C++ Description : Mobile oriented web comics reader client Piperka is a web comic tracking and bookmarking service with over 6000 comics listed on it. It doesn't host any web comics by itself but maintains a list of them and an index of their archive pages. . Piperka Client uses Piperka's database to provide browsing and navigation for web comics' archives in a unified manner with an embedded browser. It stores user's bookmarks and periodically contacs the server to check for any updates to the comics that a user reads. . This program is geared towards mobile use. I originally wrote this app for Sailfish and then implemented a generic Qt mobile oriented version of it, mainly to get it to Android. Packaging it for Debian is a low hanging fruit so why not. I haven't actually tagged a 0.2.1 yet but will do so soon.
Re: Bug#832174: ITP: js-build-tools -- collection of tools to help building Jane Street Packages
On Sat, Jul 23, 2016 at 11:58:49AM +0200, Stéphane Glondu wrote: > * Package name: js-build-tools That's an unfortunate choice for a name. This package has nothing to do with javascript.
Bug#803636: ITP: hsakmt -- thunk library for AMD's HSA Linux kernel driver (amdkfd)
Package: wnpp Severity: wishlist Owner: Kari Pahula * Package name: hsakmt Version : 1.0.0 Upstream Author : Advanced Micro Devices, Inc. * URL : http://cgit.freedesktop.org/amd/hsakmt/ * License : MIT/X Programming Lang: C Description : thunk library for AMD's HSA Linux kernel driver (amdkfd) hsakmt is a thunk library that provides a userspace interface to amdkfd (AMD's HSA Linux kernel driver). It is the HSA equivalent of libdrm. . Heterogeneous System Architecture (HSA) is a computer processor architecture that integrates central processing units and graphics processors on the same bus, with shared memory and tasks. The HSA is being developed by the HSA Foundation, which includes (among many others) AMD and ARM. The platform's stated aim is to reduce communication latency between CPUs, GPUs and other compute devices, and make these various devices more compatible from a programmer's perspective, relieving the programmer of the task of planning the moving of data between devices' disjoint memories (as must currently be done with OpenCL or CUDA). This library is needed (along with hsa-runtime, ITP for that will follow later) to enable HSA features in AMD's Kaveri and Carrizo APUs. The amdkfd driver is already included in the mainline kernel.
Bug#793733: ITP: minizinc-ide -- MiniZinc constraint modelling language IDE
Package: wnpp Severity: wishlist Owner: Kari Pahula * Package name: minizinc-ide Version : 0.9.8 Upstream Author : Guido Tack * URL : http://www.minizinc.org/ide/ * License : MPL-2.0 Programming Lang: C++ Description : MiniZinc constraint modelling language IDE The MiniZinc IDE is a simple Integrated Development Environment for writing and running MiniZinc models. It provides a tabbed editor with MiniZinc syntax highlighting, configuration dialogs for solver options and model parameters, and an integrated environment for compiling models and running solvers. This is to go along with minizinc package (#791608). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150726193733.9301.94529.report...@sammakko3.piperka.net
Bug#791608: ITP: minizinc -- Constraint modelling language and tool chain
Package: wnpp Severity: wishlist Owner: Kari Pahula * Package name: minizinc Version : 2.0.4 Upstream Author : Guido Tack * URL : http://www.minizinc.org/ * License : MPL-2.0, MS-PL Programming Lang: C++ Description : constraint modelling language and tool chain MiniZinc is a medium-level constraint modelling language. It is high-level enough to express most constraint problems easily, but low-level enough that it can be mapped onto existing solvers easily and consistently. It is a subset of the higher-level language Zinc. . MiniZinc is designed to interface easily to different backend solvers. It does this by transforming an input MiniZinc model and data file into a FlatZinc model. FlatZinc models consist of variable declaration and constraint definitions as well as a definition of the objective function if the problem is an optimization problem. The translation from MiniZinc to FlatZinc is specializable to individual backend solvers, so they can control what form constraints end up in. In particular, MiniZinc allows the specification of global constraints by decomposition. I already maintain Gecode, which includes a FlatZinc interpreter. I intend to package minizinc and minizinc-ide to provide more use for Gecode. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150706194031.11890.33240.report...@sammakko3.piperka.net
Bug#759668: ITP: libnet-oauth2-perl -- implementation of the OAuth 2.0 protocol
Package: wnpp Severity: wishlist Owner: Kari Pahula * Package name: libnet-oauth2-perl Version : 0.61 Upstream Author : Mark Overmeer * URL : https://metacpan.org/release/Net-OAuth2 * License : Artistic or GPL-1+ Programming Lang: Perl Description : implementation of the OAuth 2.0 protocol Net::OAuth2 implements OAuth 2.0 authorization protocol client. OAuth 2.0 is imcompatible with OAuth 1.0. . The library can be used to authenticate users against OAuth 2.0 service providers such as Google and Facebook. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140829094325.4910.4539.report...@sammakko3.piperka.net
Re: make 4.0: archive rebuild resulted in 73 packages broken (help wanted)
On Mon, Apr 28, 2014 at 11:01:58PM -0700, Manoj Srivastava wrote: > Kari Pahula >gecode That one failed due to missing Build-Depends-Indep and the build attempted to call debian/rules build-indep. I don't think that make 4.0 had anything to do with that failure. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140429160944.gb15...@sammakko3.piperka.net
Speeding up dpkg triggers with a list of changes
I had a fun little weekend project.
I tried out using inotify to speed up dpkg file triggers, with man-db
as a test case, not that this approach is limited to that.
My code consists of two programs, one that parses a .triggers file and
collects the events in the background and another one that asks for
those changes. I didn't need to recompile any programs for this, but
just add a few lines to man-db's postinst file.
Some benchmarks, to motivate this thing. I chose "the" as a benchmark
since it's a simple package with a singular man page in section 1,
where man1 would be a directory with a few thousand entries.
# time { for a in {1..10}; do dpkg --remove the; dpkg -i
/var/cache/apt/archives/the_3.3~rc1-2_amd64.deb ; done }
Plain old man-db trigger:
real0m39.733s
user0m11.949s
sys 0m7.768s
With inotify and using mandb -f:
real0m26.910s
user0m11.081s
sys 0m4.428s
That's a lot of stat calls left uncalled.
The reason why I've made my test code to handle just singular man
pages is that mandb accepts only one -f parameter. I didn't try
changing that for this test. mandb still has a nontrivial startup
time and I wouldn't call it in a loop, as it is.
I'd say that doing this is a worthwhile thing, but I'd like to discuss
the specifics. How closely should this be associated with dpkg
itself? Starting the collection process takes about 200ms so I'm not
quite sure how well launching it at the same time as dpkg itself would
work. With apt-get or aptitude that'd pose no problem. On the other
hand, man is an example where we could eliminate that delay if we
applied some domain specific knowledge. Stop readdir early if there
are any non-directories in a directory, since we know that, for man,
none of those will have subdirectories. We're only adding inotify
watches on directories.
Who should decide what packages have inotify data collection enabled?
I don't expect this level of detail to be useful for all packages.
How configurable should this be? I doubt any trigger would benefit
from getting a list of a hundred files or so and would be better off
just doing a full run of whatever they're doing.
I'd keep having this information available optional, with having
triggers fall back to do what they currently do. There's a chance
(however small) that inotify fills up its event buffer and any data
collection routine will have no choice but to bail out, and we have
non-Linux systems to consider too.
I'm not entirely sure this thing couldn't have false negatives, with
having changes go unnoticed. But triggers are supposed to cope with
that already.
I haven't tried looking at dpkg's source to see what it does to decide
to call a file trigger and why it won't make a file list available, or
what would need to be done to expose that. I know that it doesn't use
inotify.
Strictly speaking, none of what I did really necessiates dpkg's, apt's
or anyone's cooperation, if I made it an independent daemon and just
let a package's postinst trigger optionally use it if it was active.
I've attached my test code. I don't know what all earlier attempts
there are at doing this sort of a thing. Most of the file alteration
monitor software (e.g. fam, gamin, incron) are more geared towards
having actions happen when files change, not recording the changes.
inotify-interest.tar.gz
Description: Binary data
Bug#658573: ITP: lincity -- build & maintain a city/country
Package: wnpp Severity: wishlist Owner: Kari Pahula * Package name: lincity Version : 1.13.1 Upstream Author : I J Peters, Greg Sharp, Corey Keasling * URL : http://lincity.sourceforge.net/ * License : GPLv2 Programming Lang: C Description : build & maintain a city/country You are required to build and maintain a city. You must feed, house, provide jobs and goods for your residents. You can build a sustainable economy with the help of renewable energy and recycling, or you can go for broke and build rockets to escape from a pollution ridden and resource starved planet, it's up to you. Due to the finite resources available in any one place, this is not a game that you can leave for long periods of time. This game is similar to the commercial simulation game with a similar name. lincity has been in Debian for over a decade and was abandoned and finally removed a year ago. I prefer the classic lincity over lincity-ng, so I'm bringing it back. Upstream seems pretty much dead and I don't expect to do any new development myself, but just fix bugs, keep it up to standards and in a buildable state. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120204085017.10714.68828.report...@sammakko3.piperka.net
Bug#584464: ITP: tpl -- efficient C serialization library
Package: wnpp Severity: wishlist Owner: Kari Pahula * Package name: tpl Version : 1.5 Upstream Author : Troy Hanson * URL : http://tpl.sourceforge.net/ * License : One clause BSD Programming Lang: C Description : efficient C serialization library Tpl is a library for serializing C data. The data is stored in its natural binary form. The API is small and tries to stay "out of the way". Tpl can serialize many C data types, including structures. . Tpl makes a convenient file format. For example, suppose a program needs to store a list of user names and ids. This can be expressed using the format string "A(si)". If the program needs two such lists (say, one for regular users and one for administrators) this could be expressed as "A(si)A(si)". It is easy to read and write this kind of structured data using tpl. . Tpl can also be used as an IPC message format. It handles byte order issues and deframing individual messages off of a stream automatically. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100603174221.9598.578.report...@sammakko
Bug#539238: ITP: gearhead2 -- roguelike mecha role playing game in space
Package: wnpp Severity: wishlist Owner: Kari Pahula * Package name: gearhead2 Version : 0.603 Upstream Author : Joseph Hewitt * URL : http://www.gearheadrpg.com/ * License : LGPL v2.1 or later Programming Lang: Pascal Description : roguelike mecha role playing game in space Set a century and a half after nuclear war, you can explore a world where various factions compete to determine the future of the human race. Major features include random plot generation, a detailed character system, and over two hundred customizable mecha designs. . GearHead 2 is set five years after the events of GearHead 1. It is currently under development and is initially set in the L5 Orbital Pattern. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: binNMUs for arch:all packages too
On Mon, Jul 06, 2009 at 10:33:56AM -0700, Steve Langasek wrote:
> Because:
>
> - there are no autobuilders configured to build arch: all packages in debian
Because there was no need for them before.
> - allowing arch: all packages to be binNMUed breaks the invariant that
> packages may use ${binary:Version} for package relationships on other
> arch: any packages from the same source package, and ${source:Version} for
> package relationships on arch: all packages from the source package
I'd like to see how fixed that invariant is. AFAIK it's only one on
convention level. If a coordinating set of packages relies on
arch:all packages getting binNMUed, I don't see what the problem is.
I'm not proposing to have this enabled by default, but this is just a
situation where it would be useful.
> > What's needed to get this working?
>
> I don't think it should be made to work.
So you think that sourceful uploads for Haskell libraries is the
expected thing to do? We're talking about tens of packages.
signature.asc
Description: Digital signature
binNMUs for arch:all packages too
Currently, asking for nmu foo_1.0-1 . ALL . -m 'rebuild against bar 2.3' only builds foo_1.0-1+b1 for arch:any packages. No +b1 is built for any possible -doc packages. Often, this is what's expected, but not always. The specific scenario I have in mind is Haskell libraries. They change ABIs often, at least once every time ghc6 gets a new upstream version. That's a lot of packages, needing rebuilding and dep-wait states, with no source changes. Haskell library -doc packages include .haddock files, which are derived from the ABI at build time. They describe the library's API and are used at build time for things like generating correct links in depending libraries' documentation and for generating an index on a user's system. They are itself architecture independent, but still need to be rebuilt along with the libraries themselves. Building and uploading the -doc package corresponding to the binNMU by hand is possible even now (as described in http://lists.debian.org/debian-haskell/2009/05/msg00029.html) but not really any more convenient than doing a sourceful upload, as it stands. It's a hack, too. Plus, it'd be preferable if this was all part of the usual buildd network. I don't know offhand if this has been discussed before. Any reasons why this shouldn't be supported? What's needed to get this working? I guess it'd be more proper if there was some other token that'd trigger building arch:all packages, instead of including it in ALL. signature.asc Description: Digital signature
Bug#534883: ITP: haskell-lazysmallcheck -- A library for demand-driven testing of Haskell programs
Package: wnpp Severity: wishlist Owner: Kari Pahula * Package name: haskell-lazysmallcheck Version : 0.3 Upstream Author : Matthew Naylor * URL : http://www.cs.york.ac.uk/fp/smallcheck/ * License : BSD Programming Lang: Haskell Description : A library for demand-driven testing of Haskell programs Lazy SmallCheck is a library for exhaustive, demand-driven testing of Haskell programs. It is based on the idea that if a property holds for a partially-defined input then it must also hold for all fully-defined refinements of the that input. Compared to `eager' input generation as in SmallCheck, Lazy SmallCheck may require significantly fewer test-cases to verify a property for all inputs up to a given depth. I'm packaging this since other Haskell packages depend on this one. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposed release goal: fix debian/rules build-arch
On Mon, Feb 16, 2009 at 11:21:42AM -0800, Russ Allbery wrote: > Such a requirement unfortunately still won't mean that Lintian can use > that option to do a check of debian/rules. As long as make is willing to > run such code, we can't just rely on a Policy statement saying that you're > not supposed to do that. It is, among other things, a security problem. That's a good point, but not running debian/rules means that you'd be making it a requirement to write debian/rules files in a stylised way, to make it greppable. Conventions are one thing, that'd be another. That'd have a human cost too. But this is somewhat coincidental to this. Coming up with a test, even an imperfect one, could help push changes forwards. > I have to admit that I'm tempted by this approach, mostly because it's not > clear to me that the build-arch vs. build-indep separation actually gains > us anything that useful. The point, so far as I can tell, is to save > buildd time by not building the architecture-independent packages. How > much time would we actually be saving? Is it worth putting a lot of human Ask buildd admins. They could start downloading and installing B-D-I along with B-D today. Deprecating B-D-I and -arch and -indep would be a small step after that. > effort into making that situation possible? Generally CPU cycles are far, > far cheaper than human cycles. Another thing that B-D-I is good for: breaking dependency cycles. An example from the upcoming version of ghc6: ghc6 uses haddock to build API docs. Haddock needs to be built with the same version of ghc6 it generates docs for. Putting haddock in ghc6's B-D-I avoids that cycle. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Proposed release goal: fix debian/rules build-arch
Currently, Debian Policy doesn't match with the current practice in section 7.7. > The Build-Depends-Indep and Build-Conflicts-Indep fields must be > satisfied when any of the following targets is invoked: build, > build-indep, binary and binary-indep. I know that people like to say that Policy should reflect reality, not have wishful thinking (like in #178809). It's been tried before but I'd like to try again to get a transition done to make reality into what 7.7 says it is. As it stands, buildds call "debian/rules build" without having B-D-I installed, contrary to 7.7. Buildds do call "debian/rules binary-arch". As such, B-D-I does what it's supposed to do on buildds only in conjunction with binary-arch and clean targets. Obviously, we'd get half of the archive FTBFS if we made buildds call build-arch instead of build now, since it's an optional feature. Having a call to "debian/rules build-arch" fail tells us less than we'd like, too. Nobody's yet written a reliable check to see if the build-arch target is present in a debian/rules file. I'm hoping that we're only dealing with debian/rules files that are makefiles. It'd be desirable to know if build-arch is supported from the .dsc file alone, without unpacking the source package. This has been discussed before and I'll list some options from the top of my head. I'm hoping to start a discussion, again. Now, option 1 (cold turkey): Make build-arch to be a mandatory target in debian/rules files in the next policy version (3.9.0, already?). Any existing "build" targets work, by necessity, correctly without having B-D-I installed, and a debian/rules file could be fixed by adding one line: build-arch: build Buildds would still call "debian/rules build" on anything that had a smaller Standards-Version than 3.9.0, and "debian/rules build-arch" on the rest. It'd be the maintainer's responsibility to check that it works before bumping the version. Option 2 (features field): Add a field called "Build-Features:" to debian/control and have it contain a space separated list of tokens. Define "build-arch" as a recognized value. Put that in .dsc. As with things like this, we'd potentially get stuck with it forever, but it'd be the least invasive thing to do and still get buildds to use build-arch. There'd be no transition, other than getting sbuild patched. We could also change build-arch into a "should" feature and warn anyone who didn't support build-arch and switch over to having it as a "must" once everyone did it. It'd be easy to check for that, with this. Option 3 (lintian hackery first): I know some people would like to see a lintian check, first. The thing is, debian/rules is a program, so trying to figure out any properties about it, like "does it support feature X?" or "does it halt?" gets quite close to the halting problem. GNU make does have some options to query a makefile, like --dry-run and --question. Even those would require evaluating a makefile, at least to some degree. If someone put $(shell rm *) in there, it'd do that. I'd like to see something like "Running debian/rules --dry-run or --question must not have harmful side effects or affect any subsequent calls to debian/rules." in the policy before relying on those. I'm hoping that there's nothing controversial about this addition. IMHO it's a rather pathological makefile that does things like that. I'd like to see some explicit option added to make that would just answer the question "Is there a rule that would match target X?". Same considerations about evaluation would apply as to -n and -q. As it stands, I'd need to do something like this: debian/rules -q build-arch 2>&1 >/dev/null | tail -n 1 | \ egrep -e '^make: \*\*\* No rule to make target `build-arch.\. Stop\.$' As an aside, guaranteeing that --dry-run wouldn't do anything evil would help lintian in other matters, too. For example, this is what the current version does to check whether a package uses CDBS: if (m,^include\s+/usr/share/cdbs/1/rules/debhelper.mk,) I'd rather run "debian/rules -nds" to check if it includes something from under /usr/share/cdbs/. Option 4 (give up): Remove the mention of "build" from 7.7. Policy would match the current usage, right then. This is not what I'd like to see, since I think that a reliable build-arch would be a really nice thing to have. Option 5 (further discussion): Do nothing. Have this discussion again sometime after Squeeze. Can we please not do this? I see less of a need for a build-indep target. Should we touch that? signature.asc Description: Digital signature
Bug#473563: ITP: haskell-hspread -- Haskell client library for the Spread toolkit
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: haskell-hspread Version : 0.3 Upstream Author : Andrea Vezzosi <[EMAIL PROTECTED]> * URL : http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hspread-0.3 * License : 3 clause BSD Programming Lang: Haskell Description : Haskell client library for the Spread toolkit A haskell library that supports the most recent version of the Spread protocol. Its aim is to make easier to implement correct distribuited applications by taking advantage of the guarantees granted by Spread: such as reliable and total ordered messages. It's intended to be used with a serialization library like binary, and a separate installation of the spread deamon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457373: ITP: pxsl -- Parsimonious XML Shorthand Language
Package: wnpp
Severity: wishlist
Owner: Kari Pahula <[EMAIL PROTECTED]>
* Package name: pxsl
Version : 1.0
Upstream Authors: Tom Moertel <[EMAIL PROTECTED]> and Bill Hubauer <[EMAIL
PROTECTED]>
* URL : http://community.moertel.com/ss/space/PXSL
* License : GPLv2 or later
Programming Lang: Haskell
Description : Parsimonious XML Shorthand Language
PXSL ("pixel") provides XML authors and programmers with a simple,
concise syntax that they can use to create XML documents.
.
For more advanced users, PXSL offers customizable shortcuts and
sophisticated refactoring tools like functional macros that can
markedly reduce the size and complexity of markup-dense XML
documents.
.
The short version is this: PXSL is XML turned inside-out. Instead of
tagging the structure, you tag the non-structure, which is the better
approach when most of your information is structure.
.
Also, PXSL lets users intermix PXSL and XML syntax in one
document. Users are free to use whichever syntax works best for each
portion of their documents.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#432795: ITP: haskell-generic-xml -- Haskell library for marshalling values to/from XML
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: haskell-generic-xml Version : 0.1 Upstream Author : HAppS LLC * URL : http://hackage.haskell.org/cgi-bin/hackage-scripts/package/generic-xml-0.1 * License : BSD Programming Lang: Haskell Description : Haskell library for marshalling values to/from XML Library for marshalling Haskell values to/from XML. The upcoming HAppS version depends on this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#432794: ITP: haskell-syb-with-class -- Haskell library for generic programming
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: haskell-syb-with-class Version : 0.1 Upstream Author : Simon Peyton Jones, Ralf Laemmel * URL : http://hackage.haskell.org/cgi-bin/hackage-scripts/package/syb-with-class-0.3 * License : BSD Programming Lang: Haskell Description : Haskell library for generic programming Classes, and Template Haskell code to generate instances, for the Scrap Your Boilerplate With Class system. This is a dependency for generic-xml, which in turn is a dependency for the upcoming HAppS version. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Filing FTBFS bugs and packages in NEW
I'd like to file a wishlist bug on people who file FTBFS bugs. It would be nice if you checked first whether there's a package pending in NEW or incoming and see if that might resolve the issue already. I'm looking at you, #426867. Thank you. signature.asc Description: Digital signature
Bug#413835: ITP: haskell-zlib -- Haskell library for using gzip and zlib formats
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: haskell-zlib Version : 0.3 Upstream Author : Duncan Coutts <[EMAIL PROTECTED]> * URL : http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib-0.3 * License : revised BSD Programming Lang: Haskell Description : Haskell library for using gzip and zlib formats This library provides support for compression and decompression in the gzip and zlib formats, using ByteStrings. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-1-k7 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413833: ITP: haskell-binary -- Haskell library for binary serialisation using lazy ByteStrings
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: haskell-binary Version : 0.2 Upstream Author : Lennart Kolmodin <[EMAIL PROTECTED]> * URL : http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.2 * License : revised BSD Programming Lang: Haskell Description : Haskell library for binary serialisation using lazy ByteStrings The 'binary' package provides Data.Binary, containing the Binary class, and associated methods, for serialising values to and from lazy ByteStrings. . A key feature of 'binary' is that the interface is both pure, and efficient. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-1-k7 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413826: ITP: haskell-hlist -- Haskell library for strongly typed heterogeneous collections
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: haskell-hlist Version : 2.0+darcs20070207 Upstream Author : Oleg Kiselyov, Ralf Lämmel, and Keean Schupke * URL : http://homepages.cwi.nl/~ralf/HList/ * License : MIT/X Programming Lang: Haskell Description : Haskell library for strongly typed heterogeneous collections A heterogeneous collection is a datatype that is capable of storing data of different types, while providing operations for look-up, update, iteration, and others. There are various kinds of heterogeneous collections, differing in representation, invariants, and access operations. . HList is a Haskell library providing strongly typed heterogeneous collections including extensible records. Mainly packaging this because HAppS 0.8.8 depends on this. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-1-k7 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Bug#400117: ITP: gecodej -- Java interface for the Gecode constraint programming library
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: gecodej Version : 1.0.1 Upstream Author : Mikael Lagerkvist, Guido Tack * URL : http://www.gecode.org/gecodej/index.html * License : MIT/X Programming Lang: C++, Java Description : Java interface for the Gecode constraint programming library Gecode/J is a Java interface for the Gecode C++ constraint programming library. It allows you to . - Model and solve constraint problems in Java. - Explore the search tree with Gist, the Graphical Interactive Search Tool. Either using the built-in depth-first search strategy, or manually and interactively. Solutions and choice nodes can be inspected by clicking on them, and visualized using custom actions. - Implement propagators in Java. Whether for prototyping, for teaching, or just for fun. The propagators are integrated fully, so in your model you can mix them freely with the built-in propagators provided by Gecode. - Implement branchings for custom heuristics. Just like propagators, custom branchings fully integrate into Gecode/J. - Implement search engines using copying and recomputation. As search is fully programmable, you can write your own search engine, e.g. for LDS or A* search. In fact, Gist is implemented entirely in Java using the Gecode/J interface. Depends on Sun's Java, so this'll have to go to contrib until the license is changed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400042: ITP: happs -- Haskell library for building Internet applications
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: happs Version : 0.8.4 Upstream Author : Alex Jacobson * URL : http://happs.org/ * License : BSD with advertising clause Programming Lang: Haskell Description : Haskell library for building Internet applications HAppS is a Haskell library for building industrial strength Internet applications safely, quickly, and easily. With HAppS you focus entirely on application functionality implemented in your favorite language and you don't have to worry about making sure all sorts of server subsystems are functioning properly. . - HTTP Application Server Performs better than Apache/PHP in our informal benchmarks (thanks to FastPackedString), handles serving both large (video) files and lazy (javascript) streaming, supports HTTP-Auth, and more. - Mail delivery agent with integrated DNS resolver Stop worrying about making sure a separate local mail server or DNS is up and running to delivery your mail. HAppS takes care of making sure your mail is delivered as long as your application itself is running and makes sure no outbound mail is lost even with unplanned restarts. - XML and XSLT Separate application logic from presentation using XML/XSLT. With HAppS, you can have your application output XML (via HTTP or SMTP) and handle style/presentation via separate XSLT files at runtime. HAppS takes care of doing server side XSLT for outbound mail and HTTP user-agents that don't support it client side. - SMTP Server Handle incoming email in your application without worrying about .procmail or other user level inbound mail configuration hackery. Just have the HAppS.SMTP listen on port 25 or have the system mail server SMTP forward mail for your app to some internal port. - Monadic ACID transaction service Write apps as a set of simple state transformers. MACID write-ahead logging and checkpointing make it easy for you to guarantee application integrity in the face of unplanned outages. MACID even guarantees that your side effects will be executed at-least-once if they can complete within a timelimit you define. - Session Service Define bits of per-user application state that automatically expire after time limits you define. No more manual housekeeping of session data! - (Experimental) Table and Index Do relational operations safely on in memory Haskell Data.Set(s) rather than dealing with an external SQL relational database. Define custom indices for your Haskell datatypes (e.g. geographic/geometric types). Use in combination with MACID for a robust relational DBMS customized for your application. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396049: ITP: alice -- Alice programming language
On Sun, Oct 29, 2006 at 09:35:58AM -0600, Ron Johnson wrote: > > Description : Alice programming language > > > > A functional programming language based on Standard ML, extended with > > support for concurrent, distributed, and constraint programming. The > > Alice ML language extends Standard ML with several new features: > > I might be nice to mention MUMPS somewhere in the long description. This one? http://www.enseeiht.fr/irit/apo/MUMPS/ I'm afraid I don't see what the connection with that and Alice is. Could you please elaborate? I'm assuming that you're not talking about the programming language MUMPS (http://en.wikipedia.org/wiki/MUMPS), at least. Most of the search results for MUMPS are about the disease. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396049: ITP: alice -- Alice programming language
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: alice Version : 1.3.0 Upstream Author : Programming Systems Lab, Saarland University * URL : http://ps.uni-sb.de/alice/ * License : GPL, BSD-like Programming Lang: C++, SML, Alice Description : Alice programming language A functional programming language based on Standard ML, extended with support for concurrent, distributed, and constraint programming. The Alice ML language extends Standard ML with several new features: . - Futures: laziness and light-weight concurrency with data-flow synchronisation - Higher-order modules: higher-order functors and abstract signatures - Packages: integrating static with dynamic typing and first class modules - Pickling: higher-order type-safe, generic & platform-independent persistence - Components: platform-independence and type-safe dynamic loading of modules - Distribution: type-safe cross-platform remote functions and network mobility - Constraints: solving combinatorical problems using constraint propagation and programmable search I've been wanting to package this one for a long time already, and started looking into it this weekend. There's still a few issues that I'll have to resolve. The release tarballs at http://ps.uni-sb.de/alice/download/sources/ have the alice runtime system in compiled bytecode format only. Not having the source would fail DFSG, but fortunately it's available in the CVS. For security fixes' sake I'll retool the build system to compile the bytecode on debian/rules build and not just include the sources along with upstream's binary blobs. Also, Alice doesn't seem to be quite FHS compliant. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: want to contribute
On Fri, Oct 13, 2006 at 10:39:18AM -0500, Arvind kumar wrote: > I am using debian linux for quite some time and quite impress by it. I want > to contribute to its development . It would help if you could narrow down your interest somewhat. Some possible projects are listed at http://www.us.debian.org/devel/todo/ > Please give me some pointers . I looked at website , it not quite clear how > to start http://www.debian.org/devel/ has a good overview the various areas of development. http://www.debian.org/devel/join/ is probably what you should start with. The new maintainers' guide at http://www.debian.org/doc/maint-guide/ should get you started with packaging work, if that interests you. Other than the above, you could check the wiki too, at http://wiki.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#374132: ITP: tntdb -- C++ class library for easy database access
On Sat, Jun 17, 2006 at 03:46:11PM +0300, Kari Pahula wrote: > * License : GPLv2 or later > Currently has support for MySQL, PostgreSQL and SQLite. And PostgreSQL links to openssl, which is GPL incompatible. Sigh... I'll investigate what could be done about this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374132: ITP: tntdb -- C++ class library for easy database access
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: tntdb Version : 0.6.2 Upstream Author : Tommi Mäkitalo <[EMAIL PROTECTED]> * URL : http://www.tntnet.org/tntdb.hms * License : GPLv2 or later Programming Lang: C++ Description : C++ class library for easy database access This library provides a thin, database independent layer over an SQL database. It lacks complex features like schema queries or wrapper classes like active result sets or data bound controls. Instead you get to access the database directly with SQL queries. The library is suited for application programming, not for writing generic database handling tools. . Currently has support for MySQL, PostgreSQL and SQLite. I'm not that happy with my description (as usual). Any suggestions for improving it are welcome. Tntdb will depend on cxxtools (ITP #366834). -- 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.16.18 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Re: Sun Java available from non-free
On Mon, May 22, 2006 at 06:58:08PM -0500, Anthony Towns wrote: > On Sun, May 21, 2006 at 06:14:51PM +0200, Michael Meskes wrote: > > On Sat, May 20, 2006 at 04:18:44PM -0500, Anthony Towns wrote: > > > Anyway, the background is that James Troup, Jeroen van Wolffelaar and > > > myself examined the license before accepting it into non-free (which is > > > three times the usual examination, and was done given the inability to > > > examine the license in public), and both James and Jeroen had extensive > > > contact with Sun to ensure that the tricky clauses were actually okay. > > You won't expect Sun to say they are not, would you? :-) > > The questions asked weren't "Is this okay for non-free?" it's "Did you > mean or when you wrote ?". The answers to those latter > questions are, ttbomk, all included in the FAQ, which is why ignoring > it just wastes everyone's time. Several people have already pointed out this bit on top of the said FAQ: Note: This FAQ is provided to help explain the Operating System Distributor License for Java; nothing in this FAQ is intended to amend the license, so please consult the license itself for the precise terms and conditions that actually apply. To my eyes that reads as "please disregard this FAQ." It's simply not authoritative. The FAQ offers no As. Why do you think that we should not ignore it? signature.asc Description: Digital signature
Bug#366984: ITP: klone -- web application development framework
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: klone Version : 1.1.0 Upstream Author : KoanLogic Srl <[EMAIL PROTECTED]> * URL : http://www.koanlogic.com/kl/cont/gb/html/klone.html * License : GPLv2 or later Programming Lang: C Description : web application development framework KLone is a fully-featured, multiplatform, web application development framework, targeted especially for embedded systems and appliances. . It is a self-contained solution which includes a web server and an SDK for creating WWW sites with both static and dynamic content. When using KLone, there's absolutely no need for any additional component: neither the HTTP/S server (e.g. Apache, Netscape, Roxen), nor the typical active pages engine (PHP, Perl, ASP, Python). . KLone does everything, and does it fast and small. . KLone blends the HTTP/S server application together with its content and configuration into a single executable file. The site developer writes his/her dynamic pages in C/C++ (in usual scripting style: <% /* code */ %>) and uses KLone to transform them into embeddable, compressed native code with the native C/C++ compiler. The result is then linked to the HTTP/S server skeleton to obtain one single, ROM-able, binary file. This means that he/she can get: - easy, complete and unfiltered interaction with the host operating system - dynamic pages in native compiled code, which in turn implies - fast execution and - small overall application footprint - all of this without giving up the common functionality of web application frameworks such as sessions, parsing of form variables, cookies, etc -- 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.15.6 Locale: LANG=C, LC_CTYPE=fi_FI (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: cxxtools Version : 1.4.1pre2 Upstream Author : Tommi Mäkitalo <[EMAIL PROTECTED]> * URL : http://www.tntnet.org/ * License : GPL v2 or later Programming Lang: C++ Description : library of unrelated but useful C++ classes cxxtools contains an argument-parser, a base-64 encoder/decoder, a C++ interface to iconv, md5-stream for easy MD5 calculation, threading classes, socket classes, a dynamic exception-safe buffer, a wrapper for dlopen/dlsym, a pool template (e.g., for a connection pool in a multi-threaded application), query_params, and a class for easy parsing of CGI parameters (GET and POST) in a CGI program. -- 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.15.6 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Bug#365240: ITP: seam -- virtual machine architecture and library
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: seam Version : 1.3.0 Upstream Authors : Thorsten Brunklaus <[EMAIL PROTECTED]> Leif Kornstaedt <[EMAIL PROTECTED]> Andreas Rossberg <[EMAIL PROTECTED]> Guido Tack <[EMAIL PROTECTED]> * URL : http://www.ps.uni-sb.de/seam/ * License : MIT/X Programming Lang: C++ Description : virtual machine architecture and library SEAM (Simple Extensible Abstract Machine) is designed to be language- and platform-independent, to be simple and based on few principled services. - Uniform data representation and memory management. All datastructures used to represent computations, including code and threads, reside in an abstract store, which represents an abstract graph of data nodes. Language specific datastructures are modelled on top of the language-independent store structures. The store manages the allocation of nodes and their efficient layout in memory. - Platform-independent external representation. Store values are converted to a portable representation during export (pickling), and converted back during import (unpickling). A language-independent transfer language is defined to describe values independent from platform. Unpickling operates with respect to runtime-pluggable language-dependent transformation. For example, language specific code can be instantiated either to byte code or to native code. - Abstract execution model. Computations are defined by a generic evaluator interface. SEAM supports arbitrarily many codes and evaluators to be used at the same time and interact freely. In particular, common virtual machine services like foreign function interfaces are easily expressible. . SEAM is used successfully to implement the new virtual machine underlying the Alice Programming System. -- 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.15.6 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eiffel.
On Tue, Apr 11, 2006 at 06:29:44PM +0800, Katipo wrote: > Hello, > > What's the general consensus on this? If Eiffel Studio is under GPL, then it can be included in Debian. There isn't really much else to it, as far as Debian is concerned. There is already an ITP on it: http://bugs.debian.org/361001 Daniel Baumann also wrote about this in his blog: http://blog.daniel-baumann.ch/2006/04/05 I can assume that Eiffel Software is arguing that anything compiled with Eiffel Studio is a derived product and needs to be under GPL too. Not that I've investigated this myself at all. signature.asc Description: Digital signature
Bug#358657: ITP: libsl -- memory-efficient generic linked list library
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: libsl Version : 0.3.3 Upstream Author : Stig Brautaset <[EMAIL PROTECTED]> * URL : http://brautaset.org/software/sl/ * License : GPLv2 or later Description : memory-efficient generic linked list library sl is a memory-efficient generic linked list library. It doesn't use container nodes. Instead it requires a pointer to the next item directly in the datastructure you want to create lists (or stacks) of. This can give you significant memory savings when creating long lists of small structures. It also allows for fast push and pop operations since there is no need to allocate or free memory for the container nodes. It also means that a push can't fail because memory couldn't be allocated for the container node. -- 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.15.6 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358659: ITP: libggtl -- generic game-tree search library
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: libggtl Version : 2.1.2 Upstream Author : Stig Brautaset <[EMAIL PROTECTED]> * URL : http://brautaset.org/software/ggtl/ * License : GPLv2 or later Description : generic game-tree search library GGTL is a library designed to make it easier to program games in C. It provides an AI that is able to play most 2 player strategic games. Nim, Tic-Tac-Toe, Reversi (aka Othello), Connect-4 and Chess are all examples of games that can all be implemented using GGTL. The provided Reversi and Nim extensions implement all the game-specific callback functions GGTL's AI needs. Using one of these extensions means you can have a game with a capable AI up and running in next to no time. Doing so incurs no penalty in flexibility, however--you can override any provided callback function with your own. -- 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.15.6 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#353293: ITP: littlewizard -- development environment for children
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: littlewizard Version : 1.1.1 Upstream Author : Marcin Kwadrans <[EMAIL PROTECTED]> * URL : http://littlewizard.sourceforge.net/ * License : GPL Description : development environment for children Little Wizard is created especially for primary school children. It allows to learn using main elements of present computer languages, including: variables, expressions, loops, conditions, logical blocks. Every element of language is represented by an intuitive icon. It allows program Little Wizard without using keyboard, only mouse. -- 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 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On Wed, Dec 21, 2005 at 12:23:32PM +0100, Thomas Hood wrote: > I don't think that it is ridiculous to require that every package have a > team behind it---i.e., at least two maintainers. First, if someone can't Sorry, but I'm having an issue with the word "require" here. Call me idealistic, but I think a more basic requirement here is to expect maintainers to act responsibly. Let them recognize the best ways to maintain a package for themselves. Telling them they must work in a certain manner is disparaging. If there are cases where team maintainership would clearly solve a problem yet the maintainer will refuse to turn over the package to TM, then it is valid to question whether that maintainer is acting responsibly. But otherwise, team maintainership is a solution looking for a problem. I'm not against advocating for TM, but please do so in a case by case basis. Other than that, enable, don't force. If you think that TM is great try to convince people, set an example and show people how it can be done but don't set rules. The goal of Debian remains to create a free operating system and it doesn't matter how we get there. signature.asc Description: Digital signature
Bug#343940: ITP: gecode -- generic constraint development environment
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: gecode Version : 1.0.0 Upstream Author : Christian Schulte <[EMAIL PROTECTED]> and others * URL : http://www.gecode.org/ * License : BSD Description : generic constraint development environment Gecode is an attempt to construct an open, free, portable, accessible, and efficient environment for developing constraint-based systems and applications. Gecode is radically open for programming: it can be easily interfaced to other systems. It supports the programming of new propagators (as implementation of constraints), branching strategies, and search engines. New variable domains can be programmed at the same level of efficiency as finite domain and integer set variables that come predefined with Gecode. -- 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 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340805: ITP: gearhead -- roguelike mecha role playing game
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: gearhead Version : 1.000 Upstream Author : Joseph Hewitt <[EMAIL PROTECTED]> * URL : http://www.geocities.com/pyrrho12/programming/gearhead/ * License : LGPL Description : roguelike mecha role playing game A century and a half ago the Earth was nearly destroyed by nuclear war. Now, a federation of free city-states has begun to restore civilization. However, there are forces operating in the darkness which will unleash the horrors of the past age in a bid to determine the future of the human race. Features of the game include random storyline generation, richly detailed character generation, complex NPC interaction, and of course over 150 different mechanical designs ranging from jet fighters to giant robots to city-smashing tanks. -- 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: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Orphaning Crossfire
On Wed, May 04, 2005 at 01:51:28AM +0300, Jaakko Niemi wrote: > Hello, > > crossfire-* is available for grabs. Upstream is active and helpful. > No big issues, just needs some basic work. Any takers? I can take this. I'm not a DD (yet), so I'll need a sponsor too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306852: ITP: droidbattles -- A programming game
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: droidbattles Version : 1.0.6 Upstream Author : Andreas Agorander <[EMAIL PROTECTED]> * URL : http://www.bluefire.nu/droidbattles/ * License : GPL Description : A programming game DroidBattles is a programming game. You design and program bots (in an asm-like language) in order to make it better then anyone elses bot. You then run the bots in a battle simulation, where they try to kill each other. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306737: ITP: q-lang -- Q equational programming language
Package: wnpp Severity: wishlist Owner: Kari Pahula <[EMAIL PROTECTED]> * Package name: q-lang Version : 6.0 Upstream Author : Albert Graef <[EMAIL PROTECTED]> * URL : http://q-lang.sourceforge.net/ * License : GPL Description : Q equational programming language Q stands for "equational", so Q, in a nutshell, is a programming language which lets you "program by equations". You specify a system of equations which the interpreter uses as "rewrite rules" to reduce expressions to "normal form". The Q language supports a rich variety of built-in types, like arbitrary precision integers, floating point numbers (double precision 64 bit), truth values, strings, lists and files. It also provides primitives for exception handling and multithreaded execution. Q also allows you to interface to "external" modules written in the C programming language, which provides a means to access functions in C libraries and employ C's higher processing speed for time-critical tasks. Conversely, Q scripts can also be executed from C, which allows Q to be used as an embedded language or term rewriting engine in C/C++ applications. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
