Re: Bug#677571: ITP: gwt -- Google Web Toolkit dev and runtime libraries
On Fri, Jun 15, 2012 at 11:57:02PM +0200, Damien Raude-Morvan wrote: > There is already a "gwt" package in unstable [1] Sorry I had already realised this and closed this bug report again. One of the other gwt dependencies had been removed completely, and gwt has been removed from testing but not unstable. > (and it seems to be maintained by members of eucalytus team). > Do you plan to replace this package or provide a new gwt2 package ? To update the existing gwt package in unstable. I will be changing the package maintainer to the pkg-eucalyptus team, with the permission of the current maintainer of the package, who will remain in the uploaders. Chris -- 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/20120615221615.ga31...@hp-cha.thehalls.de
Bug#677571: ITP: gwt -- Google Web Toolkit dev and runtime libraries
Package: wnpp Severity: wishlist Owner: Chris Halls Package name: gwt (binaries libgwt-dev-java and libgwt-user-java) Version : 2.4.0 Upstream Author : Google Inc URL : http://google-web-toolkit.googlecode.com License : Apache 2.0 Programming Lang: Java Description : Google Web Toolkit dev and runtime libraries Google Web Toolkit (GWT) allows developers to quickly build and maintain complex JavaScript front-end applications in the Java programming language. These packages are based on work by Alexandre Rossi, and Charles Plessy. They will contain the buildtime and runtime libraries from GWT. Many thanks for the sponsorship of this work by Eucalyptus. -- 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/20120614221341.ga28...@hp-cha.thehalls.de
Bug#677569: ITP: jsilver -- Clearsilver templates in pure Java
Package: wnpp Severity: wishlist Owner: Chris Halls Package name: jsilver Version : 1.0.0 Upstream Author : David Beaumont, Ben Dodso URL : http://code.google.com/p/jsilver License : Apache 2.0 Programming Lang: Java Description : Clearsilver templates in pure Java JSilver is a pure-Java implementation of Clearsilver. Key benefits of JSilver over Clearsilver include: Performance - Templates are only parsed when the file changes - not for each request. - Optionally, templates can be compiled directly to Java bytecode, making rendering super-fast. - Once-off template optimization step simplifies template making rendering even faster. - Internal optimizations to streamline string manipulation. Avoids the complexities of JNI - Avoids the risk of native code taking down the JVM. - Avoids JNI marshalling overhead. Simplifies IDE use (no more forgetting java.library.path). - Allows for easy extension in Java - API allows template functions to be defined in Java allowing logic to be pulled out of templates. - Custom escaping / text filters can be plugged in. - Makes plugging in translations much simpler (e.g. ). - API designed with testability in mind. - Custom mechanisms can be plugged in for loading templates and caching. - Low-level access to template AST for advanced transformations. I am packaging this as it is needed as a dependency for Google Web Toolkit. It is based on the existing package in Ubuntu by Alexandre Rossi. -- 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/20120614220311.ga27...@hp-cha.thehalls.de
Bug#677567: ITP: sablecc -- Object-oriented fully featured parser generator
Package: wnpp Severity: wishlist Owner: Chris Halls Package name: sablecc Version : 3.2 Upstream Author : Etienne M. Gagnon and others URL : http://www.sablecc.org/ License : LGPL Programming Lang: Java Description : Object-oriented fully featured parser generator SableCC is a parser generator which generates fully featured object-oriented frameworks for building compilers, interpreters and other text parsers. In particular, generated frameworks include intuitive strictly-typed abstract syntax trees and tree walkers. SableCC also keeps a clean separation between machine-generated code and user-written code. This package also contains AntTask, a task to invoke SableCC on grammar files. I am packaging this as it is needed as a dependency for Google Web Toolkit. It is based on the existing package in Ubuntu. -- 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/20120614212112.6636.17036.report...@hp-cha.rugby.credativ.co.uk
Re: ping for missing maintainers
On Tuesday 20 June 2006 11:38, Goswin von Brederlow wrote: > Wouldn't it be better to merge this with apt-cacher and combine your > skills and time? They do seem awfully similar in what they do if not > how they do it. Well, when apt-cacher started out, it needed an apache installation to work and I did not see that as a good replacement for apt-proxy, and it lacked many of apt-proxy's features. It looks like it has grown many of these features now so maybe it might be mature enough to retire apt-proxy. It isn't really possible to merge the existing code since the implementations are so different. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ping for missing maintainers
On Monday 19 June 2006 01:39, [EMAIL PROTECTED] wrote: > Howdy. Just wondering if anyone knows the whereabouts of two maintainers: > > Otavio Salvador (apt-proxy) Otavio has asked me to maintain apt-proxy again and I am in the process of preparing an upload. > I have not noticed many updates to these programs recently, and both seem > to have some ignored bugs in the bts such as > #336433 Already tagged pending in the BTS > #312969 Fixed locally but not yet tagged. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Wednesday 15 Jun 2005 10:09, Steve Langasek wrote: > On Wed, Jun 15, 2005 at 10:31:45AM +0200, Petter Reinholdtsen wrote: > > I didn't see anyone proposing prelinking so far. I've seen rumors > > that program start time for some programs decrease a lot if prelinking > > is enabled. It would be nice if we could speed up the login time, or > > for example the openoffice start time. Is prelinking the way to go? > > Should it be enabled by default? > > Using prelink invalidates the md5sums of files belonging to Debian > packages. Has anyone done any work to address this? Not that I know of, and that's why we do not enable it by default in OOo. Actually, on the subject of OOo load time, that should decrease significantly once we have it compiled with the new gcc that has symbol visibility support. 75% of OOo startup time is spent in the dynamic linker, so reducing the number of symbols that need to be resolved will make a big difference. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: an idea for next generation APT archive caching
On Sat, 2004-10-23 at 05:45, Brian May wrote: > No, max_versions is not correct. It will only work if all my computers > use the same distribution; if some computers use unstable while others > use stable for example, then the stable version will get deleted after > n revisions of the unstable version of the package. Early versions of v2 from Ranty had this behaviour, but I fixed it a while ago. apt-proxy (1.9.12) experimental; urgency=low [...] * Fix max_versions to work in the same way as version 1 did, taking distributions into account (part of #242197) -- Chris Halls <[EMAIL PROTECTED]> Sun, 30 May 2004 07:32:18 +0200
Re: an idea for next generation APT archive caching
On Thu, 2004-10-21 at 04:04, Brian May wrote: > * If the above point wasn't bad enough by itself, the apt-proxy binary has > hard coded: > > WGET_CMD="$WGET --timestamping --no-host-directories --tries=5 > --no-directories -P $DL_DESTDIR" Hmm, seems you are talking about version 1, which has been rewritten. The new version isn't bug free yet but it does fix several problems. It doesn't use wget. > * No thought put into the file deletion algorithm. IMHO, deleting > files based on age is wrong (consider how long stable files > last). Deleting files based on number of different copies is also > wrong (consider if you have some systems setup with stable and another > is unstable). IMHO, the only correct way is to scan the most recently > downloaded Packages and Source index files and delete files that > aren't mentioned anymore. This could be made more aggressive though if > disk space is low. There are several cleaning algorithms, controlled by different parameters. The 'only correct way' algorithm described above is controlled by the max_versions parameter (in version 1 & 2) Chris
Re: an idea for next generation APT archive caching
On Wed, 2004-10-20 at 11:11, martin f krafft wrote: > 1. apt-proxy: > While I love the concept of apt-proxy, it works very unreliably. > Frequently, the proxy fails to download the package or imposes > very long delays (#272217, and others). This seems to be the result of a patch that fixed one problem and caused another. You can work around it for now by using this in the config file: disable_pipelining=1 > If it does work, it's a performance hog. On my Opteron 3600+, my > mouse starts to go jaggy when more than one machine accesses the > cache at the same time. Yes, this needs looking into. If you actually have some time on your hands to do this sort of thing, I'd encourage you to look at apt-proxy seriously. It hasn't had the loving attention it needs since ranty died, although Otavio has been fixing some of the problems recently. There have been quite a lot of attempts to make a better apt-proxy, but almost always the authors discovered the problem is rather difficult to get right, especially when you start worrying about streaming while downloading, multiple clients downloading simultaneously and cache cleaning algorithms. Based on previous attempts, I'd advise you not to underestimate the task. Is apt-proxy really so broken that the only way to make something better is to rewrite the whole thing from scratch? Chris
Re: [custom] Debian Enterprise - packages
On Wed, 2003-12-03 at 20:18, John Goerzen wrote: > Debian Enterprise will have to support 64-bit platforms, which > OpenOffice doesn't. ..yet. That will be fixed by 2.0 at the latest. Help is appreciated. Chris
Re: [custom] Debian Enterprise - packages
On Wed, 2003-12-03 at 05:49, John Goerzen wrote: > > * Office Suite - OpenOffice (there's no other near as feature complete) > > And OpenOffice is the only one that runs on only two -- yes, two -- > architectures that Debian supports. You missed two. OOo is available on i386, powerpc, sparc and s390. Chris
Re: Language extensions in programs under /usr/bin
On Mon, Oct 06, 2003 at 07:50:07PM -0500, John Hasler wrote: > Besides, if dumb names were a problem we'd do something about > openoffice.org. $ ls /usr/bin/*openoffice* /usr/bin/openoffice What is dumb about that? The thread is about naming of files within /usr/bin. Chris pgpsBIj7fhkCn.pgp Description: PGP signature
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 07:12:52PM +0200, Peter Makholm wrote: > We didn't have OpenOffice at last release and it doesn't seem to be in > unstable yet. 'apt-cache search openoffice' only find myspell > dictionaries. It's in contrib, package openoffice.org. It is scheduled to move into main around version 1.0.1-2. Chris pgpz19JGQzfCQ.pgp Description: PGP signature
Re: logging out a ssh-user
On Tue, Jul 29, 2003 at 11:35:01AM +0200, Matthias Urlichs wrote: > > In my particular case (gforge), I'll have to hack around the > > no-binary-in-diff limitation of dpkg-source. I work in the same > > repository as upstream, and some images were changed. > > Ugly. The best idea I have about that is to affix a .0.1 to the upstream > version number and to upload a new .orig.tar.gz. With a very large upstream .orig.tar.gz I would not be very popular with everyone if I did this for openoffice every time :) I added support in the dbs for openoffice to uudecode a patch file with the extension .uu before applying it. I talked to Jeff Bailey at debconf about supporting this in cdbs too. (Bug #202389) Chris pgpDAvHf3vxCQ.pgp Description: PGP signature
Re: Proposal: removing libc5, altgcc and all their old-days dependencies
On Thu, Jun 19, 2003 at 10:29:01PM +1200, Philip Charles wrote: > We have a lawyer here who is a GNU/linux geek who still has to use MS Word > because openoffice.org cannot handle the complex formatting of his legacy > Word documents. Is that still true for OOo 1.1beta2? Are there open bug reports upstream for the problems? Chris
Re: Packages.bz2, Sources.bz2, Contents-*.bz2, oh my
On Sat, Aug 31, 2002 at 01:38:52PM +0200, Peter Palfrader wrote: > Still, the Packages files should only be removed after no software in > our stable distribution depends on it. If you remove the Packages file > from unstable now you will break apt-proxy (and perhaps other tools > too). Well, apt-proxy won't actually break - it will just be less efficient when configured to fetch control files using rsync because it will have to use the .gz file and fetch the whole thing. http and ftp backends will be unchanged because apt-proxy is already fetching Packages.gz. Chris (apt-proxy maintainer) pgpKnsy4V3TLo.pgp Description: PGP signature
Re: Convenient way to enable IDE DMA
On Mon, Aug 26, 2002 at 12:11:18PM -0700, Nate Eldredge wrote: > The other question is how it should be enabled. One way is "hdparm -d 1 > /dev/hd?" or moral equivalent in an init script. The hwtools package includes a script with a placeholder for such hdparm tuning in /etc/init.d/hwtools: # hdparm optimization # Switches on interrupts during transfers and does multi sector transfers if command -v hdparm >/dev/null 2>&1; then # hdparm -q [PUT ARGS HERE] true fi Chris pgpyrZxQJP5Xx.pgp Description: PGP signature
Re: (my) summary about translated description with dpkg (still RFC)
On Tue, Sep 04, 2001 at 11:46:17AM +0200, Michael Bramer wrote: > On Tue, Sep 04, 2001 at 10:39:00AM +0200, Chris Halls wrote: > > How will the translated Description be stored in the deb Package? Sorry, I wasn't addressing that :-) I was expecting to use the solution that would need to be worked out as a result of your statement: > > > The more controversial point of our proposal is that we where planing > > > to centralize the translation in a way that keeps the maintainer out > > > of the loop. But it's not the key point, it's an add-on which ease the > > > work of translators. Each package can still provide the translation > > > and be 'self contained'. My proposal simply lets all packages be 'self contained'. > > You now have translated descriptions integrated into the .debs, > > and it is possible to generate the Packages. files for use by the > > modified dpkg/dselect as was originally suggested, except that the > > translations are coming from the .debs instead of a single server. > > Packages. are a hack. > > What are Packages. file? Files with the English and the > translated Description? Only the translated Description? With a > Description or a Description- tag? With the other tags? Oh yes, I was referring to the older solution. s/Packages./Packages.po (i.e. use the Packages.po format you suggested - I'm just suggesting always generating them from .debs in the same way as Packages, instead of introducing a seperate centralised system) > some cons: > - apt-get don't know about the translation with this > - if you will use some languages, you must download some Packages >files with all the tags. > - We have _now_ on ftp.d.o 316 Packages files with 141 MByte of size >_without_ translation... > - you must patch apt in a whole I think your objections are because I didn't talk about Packages.po, aren't they? Do your objections still hold if you use Packages.po? > - maybe we get outdates translations (like debconf) Yes, the issue is not solved totally MIA maintainers, who never initiate a package rebuild. But at leat, any NMU rebuild by someone else (or qa?) would then automatically fold in your updated description translations to the package, compared to the sometimes hit-and-miss affair of a BTS request which the maintainer may or may not integrate into the package. Using this suggestion, the 'default case' of a maintainer doing nothing to the translations when rebuilding would pick up the translations (provided they at least did an apt-get update every now and then!). Compare this with the debconf template situation: If the maintainer does nothing, the translation rots in the BTS. Chris
Re: (my) summary about translated description with dpkg (still RFC)
On Thu, Aug 30, 2001 at 09:58:59AM +0200, Martin Quinson wrote: > The more controversial point of our proposal is that we where planing > to centralize the translation in a way that keeps the maintainer out > of the loop. But it's not the key point, it's an add-on which ease the > work of translators. Each package can still provide the translation > and be 'self contained'. For the MIA maintainers, or the ones not > willing to interfere with the translation stuff, the po file providing > the translation is in a translator-maintained package. There is no > dependency between the formal package and the translation one. The > second enhance the first when installed. When no translation is > installed, the system will be the same than it is now, and will > display the description in good old english. I've got a suggestion regarding integrating the translations into the packages themselves. Instead of having package translations which the user has to install and are not included in the actual .deb, what about generating and using package translation -dev packages in the same way that e.g. autotools-dev is used to automatically integrate files (config.guess,sub) that are maintained elsewhere into packages as they are built by the maintainer or buildds? The package translations would be used to generate -dev packages that would be installed into the archive along with all the other tools that a developer (not a user) needs. Maybe the package translations could be split by something like archive section to keep the size down. The developer would be able to keep these 'source' translations up to date using existing infrastructure (apt-get update etc.) At package build time, a dh_ helper script could be used to integrate the translations into the newly built .deb, which is uploaded to incoming as usual. You now have translated descriptions integrated into the .debs, and it is possible to generate the Packages. files for use by the modified dpkg/dselect as was originally suggested, except that the translations are coming from the .debs instead of a single server. Now this doesn't solve the possible bloat issue of a package containing multiple languages - but that's something that needs to be solved along with all the other types of translations that are put into a .deb (debconf templates, program messages etc.). But at least the package translation case is no longer such a special case, with a completely different way of handling it. And the user's machine no longer needs to do .po file merging from a central source, since the translations are distributed along with the .deb in every case, not just the case that the maintainer wishes to do the translation themseleves or it comes from another source. Putting the maintainer back in the loop does have a cost - the time taken for them to re-upload the package once the translation has been integrated, and the resulting bandwidth and cost to buildds etc. But maybe that's a problem that should be solved along with the other translation areas that have the same issues in the .debs? At least by automating the translation integration, you make the loop a lot smaller. And another advantage: A user building a package themselves from the source packages ends up with a .deb which includes the translated descriptions. Would would need to be done to implement this? - Translation server needs to generate packages with translations that are put into the archives - helper scripts modification to integrate translations into package build process - the scripts to generate Packages files from .debs need to also generate Packages. files - dpkg/delect patch to be applied Chris
