Bug#341915: ITP: mozilla-greasemonkey -- firefox extension which enables customization of webpages with user scripts
Package: wnpp Severity: wishlist Owner: Michael Spang <[EMAIL PROTECTED]> * Package name: mozilla-greasemonkey Version : 0.5.4 Upstream Author : Aaron Boodman * URL : http://greasemonkey.mozdev.org/ * License : No restrictions Description : firefox extension which enables customization of webpages with user scripts Greasemonkey allows Firefox and Seamonkey users to install "user scripts" which run when the user visits any site which the script is enabled for. These scripts can modify the content of the page. A large collection of existing scripts can be found at userscripts.org. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-rc4-git1 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#358080: ITP: pygaim -- python plugin support for gaim
Package: wnpp Severity: wishlist Owner: Michael Spang <[EMAIL PROTECTED]> * Package name: pygaim Version : 1.5.0 * URL : http://pygaim.sf.net * License : GPL Description : python bindings and plugin loader for gaim PyGaim allows the Gaim Instance Messaging client to be extended with the Python programming language. Python bindings for all of the functions in Gaim's plugin API are provided. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323148: ITP: mozilla-firefox-webdeveloper -- web developer extension for the Firefox web browser
Package: wnpp Severity: wishlist Owner: Michael Spang <[EMAIL PROTECTED]> * Package name: mozilla-firefox-webdeveloper Version : 0.9.3 Upstream Author : Chris Pederick * URL : http://chrispederick.com/work/ * License : GPL Description : web developer extension for the Firefox web browser The Web Developer Firefox extension adds a toolbar with several features aimed at web developers. It can disable various web features, outline page elements, quickly validate a web page by linking to a web-based validation service, add user CSS to any page, resize the browser to an arbitrary size (for screen size testing), and more. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323149: ITP: gjlv -- java log viewer for GNOME
Package: wnpp Severity: wishlist Owner: Michael Spang <[EMAIL PROTECTED]> * Package name: gjlv Version : 1.0.4 Upstream Author : Bodo Pfelzer <[EMAIL PROTECTED]> * URL : http://gjlv.sourceforge.net/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : java log viewer for GNOME The Java Log Viewer for GNOME is a graphical viewer for Java's XML logs. Logs can be read from files or can be read from a socket with appropriate configuration. When reading from a socket, the list is updated as records are received. Individual records are displayed in a GTK list, with further detail available through the detail window. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using buildds only
On Tue, 23 Aug 2005 01:42:18 +0200, Martin Pitt <[EMAIL PROTECTED]> wrote: Something like this is in fact considered. Probably Ubuntu won't use pbuilder itself since it is not the most efficient implementation around, but rebuilding the buildd chroots from scratch would help to eliminate many FTBFS bugs due to polluted chroots. Wouldn't those bugs just be indicative of an improperly packaged app or broken build system? I really don't see the point of using pbuilder to inefficiently work around a fixable problem. If they're not fixable (I don't see how this could be) perhaps we need a Build-Conflicts field. -- Michael Spang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making .deb packages
jdgamble wrote: I'm not sure if this is the right group to post to, but I am trying to learn how to make deb packages and I seem to go around in circles confusing myself. I am following this HowTo http://www.debian.org/doc/maint-guide/ and I keep getting errors from lintian and linda that I do not know how to fix. lintian -i may be of help if some of the errors and warning seem cryptic. HTH, Michael Spang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to maintain packaging files for multiple distributions in the same tree?
> versions on one axis, Lustre versions on the other and the stacked > patchs on the 3rd axis > > Lustre \ Linux 2.6.12 2.6.152.6.19 2.6.20 > 1.4.6 ++ ++ > 1.4.7 ++ ++ > 1.4.8 ++ ++ > 1.6.0 ++ ++ > > Patch 1: add intents > Lustre \ Linux 2.6.12 2.6.152.6.19 2.6.20 > 1.4.6 v1 v1v1-19v1-19 > 1.4.7 v1 v1v1-19v1-19 > 1.4.8 v2 v2-15 v2-19v2-20 > 1.6.0 v3 v3-15 v3-15v3-20 > > Patch 2: add no-intents fixes > Lustre \ Linux 2.6.12 2.6.152.6.19 2.6.20 > 1.4.6 v1 v1-15 v1-15v1-15 > 1.4.7 v1 v1-15 v1-15v1-15 > 1.4.8 v2 v2-15 v2-19v2-19 > 1.6.0 v3 v3-15 v3-19v3-20 > > ... some 20 such patches > > Side note: Lustre provides the 2.6.12 patches so they are > upstream. The rest is local changes and fixes. > > Each feature patch has (possible) different versions for each lustre > and linux version. Changes come from two directions and have to be > merged across that axis or across a whole plane. And the patch > versions can't be incremental. You can't have a base patch for 2.6.12 > and then just add ons for 2.6.15. The 2.6.12 patch often won't apply > to 2.6.15 unaltered anymore. But they will share large amounts of > common changes. > > Say I find a bug in the "add intents" patch that applies to all lustre > and linux versions. Real live example an off-by-one error in a > loop. Then I have to apply it to add-intents-v1 and replay it in v2, > v3, v1-15, v2-15, v3-15, v2-19, v3-19 and v3-20. > > Say I find a bug in 2.6.19 related to "add intents" that isn't present > in 2.6.20. Then I have to branch add-intents-v1-19 as > add-intents-v1-20 (for 2.6.20) and add-intents-v3-15 as > add-intents-v3-19 and commit the change to v1-19, v2-19 and v3-19. > > > The problems comes when you maintain patch sets for multiple versions > of something in parallel. It becomes worse if you have an upstream > source and an upstream patch set and have to maintain multiple > versions of both in parallel. Then you commonly have to apply one > change to many branches of a patch. > > MfG > Goswin Perhaps no RCS supports your particular workflow out of the box, but you should be able to fix that with a simple shell script. I've started using git recently, and it definitely has the primitives required to do what you want. You could have a "common" branch and then apply (with a rebase or merge) the changes to the other branches in a hook right after commit. That would make it seamless; you would be able to do a single logical commit and have the changes integrated into all of your parallel branches. If you use rebase, which rewrites history, your other branches will always look as if they forked right off off of the common branch *after* your last commit to it, which seems to be what you're looking for. If there are conflicts at any point in this process, you could either abort and roll back the entire operation, or drop to a shell to resolve them and pick up where you left off (the latter is what rebase does already, with the option to abort if you so desire) I really think that if you find doing things by hand tedious, as it often is, then it's just a matter of stringing together the necessary operations for your workflow in a script somewhere. Git is very scriptable so you may find it easier to do what you want with git than other systems. I don't doubt it would be manageable with any modern RCS, though. Cheers, Michael Spang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
