/etc/modprobe.d/blacklist.conf contains this comment, but why?
# watchdog drivers should be loaded only if a watchdog daemon is installed
I maintain the package providing it, but I fear it is the result of
cargo cult sysadmining.
A driver will not engage the watchdog anyway until /dev/watchdog
On Do, 04 Feb 2010, Joerg Jaspert wrote:
> > /maildir-utils_0.6-1_amd64.changes is already present on target host:
> > maildir-utils_0.6-1_amd64.deb
> > Either you already uploaded it, or someone else came first.
> > Job maildir-utils_0.6-1_amd64.changes removed.
>
> > So *how* am I supposed to cl
Package: wnpp
Severity: wishlist
Owner: Carl Chenet
* Package name: mercurial-keyring
Version : 0.4.1
Upstream Author : Marcin Kasperski
* URL : http://pypi.python.org/pypi/mercurial_keyring
* License : GPL
Programming Lang: Python
Description : Mercu
John Goerzen wrote:
> On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
>> I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
>> package.
>
> I am doing the same, for the very simple reason that every other
> approach I've seen violates the KISS (Keep It Simple,
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 544 (new: 1)
Total number of packages offered up for adoption: 128 (new: 2)
Total number of packages request
Am Dienstag 02 Februar 2010 21:43:21 schrieb Tollef Fog Heen:
> ]] Hendrik Sattler
>
> | Am Dienstag 02 Februar 2010 16:14:27 schrieb Simon McVittie:
> | > However, this would also require that pkg-config itself was multiarch
> | > or otherwise supported cross-compilation
> | > (/usr/bin/i486-linu
On 12015 March 1977, Norbert Preining wrote:
> /maildir-utils_0.6-1_amd64.changes is already present on target host:
> maildir-utils_0.6-1_amd64.deb
> Either you already uploaded it, or someone else came first.
> Job maildir-utils_0.6-1_amd64.changes removed.
> So *how* am I supposed to clean up
Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho
* Package name: hlbrw
Version : 0.2.1
Upstream Author : Joao Eriberto Mota Filho
* URL : http://hlbr.sf.net
* License : GPL
Programming Lang: Bash
Description : assistant to help make new
I've recently installed debootstrap and schroot on a squeeze setup so
that I can build packages in sid.
I've got it more or less working except for being able to get /home/
to automatically bind-mount my real /home.
When I run schroot, I get:
kosuke$ schroot --debug=critical
W: Failed to change
]] Goswin von Brederlow
| But how would -dev packages signal that they need support for this? They
| do not depend on pkg-config as they are usable without. Should they
| Breaks: pkg-config (<< ver)? Seems too strong.
Breaks sounds fine to me.
--
Tollef Fog Heen
UNIX is user friendly, it's jus
On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
> I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
> package.
I am doing the same, for the very simple reason that every other
approach I've seen violates the KISS (Keep It Simple, Stupid)
principle.
My Debian
* Matt Zagrabelny [100203 23:26]:
> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the u
Peter Samuelson writes:
> [Goswin von Brederlow]
>> But how would -dev packages signal that they need support for this?
>> They do not depend on pkg-config as they are usable without. Should
>> they Breaks: pkg-config (<< ver)? Seems too strong.
>
> Alternatively, create a symlink into /usr/lib/p
Package: wnpp
Severity: wishlist
Owner: Matthijs Kooijman
* Package name: catcodec
Version : 1.0.0
Upstream Author : Remko Bijker
* URL : http://www.openttd.org/download-catcodec
* License : GPL
Programming Lang: C++
Description : tool to decode/encode
On 03/02/2010 07:14, Mike Hommey wrote:
> I'd go for the -browserplugin suffix.
>
> Speaking of plugins, I see there are several plugin packages that put
> plugins in various places. Here is a breaking news: the canonical place
> for plugins is /usr/lib/mozilla/plugins. Nowhere else.
>
> Why ? Be
--
Does your company need any of our Services ?
___
Our Best Services Offered..
Web designing / Web development / SEO-Internet Marketing/
Domain Registration and Hosting
Logo Designing/Brochure Designing/E-Brochure
In Addition to this we do..
On Thu, Feb 04, 2010 at 03:48:13PM +0100, Benjamin Drung wrote:
> Am Donnerstag, den 04.02.2010, 10:13 +0100 schrieb Fabian Greffrath:
> > Am 03.02.2010 07:14, schrieb Mike Hommey:
> > > I'd go for the -browserplugin suffix.
> >
> > Fine, but what now? Can we already call this a consensus? Shall I
Am Donnerstag, den 04.02.2010, 10:13 +0100 schrieb Fabian Greffrath:
> Am 03.02.2010 07:14, schrieb Mike Hommey:
> > I'd go for the -browserplugin suffix.
>
> Fine, but what now? Can we already call this a consensus? Shall I file
> wishlist bugs against the affected packages? What's the opinion o
Hi,
Am Mittwoch, den 03.02.2010, 16:25 -0600 schrieb Matt Zagrabelny:
> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/p
[debburn-devel cc'd since readers there probably want to know. Hence
whole mail left; please trim]
On Sat, Jan 30, 2010 at 03:26:43PM +0200, George Danchev wrote:
> Hereby I would like to propose usage of common mailing list
> (debburn-devel) for all the packages involved in low-level burning and
Hi,
On Thu, Feb 04, 2010 at 10:13:40AM +0100, Fabian Greffrath wrote:
> Am 03.02.2010 07:14, schrieb Mike Hommey:
>> I'd go for the -browserplugin suffix.
>
> Fine, but what now? Can we already call this a consensus? Shall I file
> wishlist bugs against the affected packages? What's the opinion
Am 03.02.2010 07:14, schrieb Mike Hommey:
I'd go for the -browserplugin suffix.
Fine, but what now? Can we already call this a consensus? Shall I file
wishlist bugs against the affected packages? What's the opinion of the
affected packages' maintainers?
- Fabian
--
To UNSUBSCRIBE, email
hi!
On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.
i use git+gbp+q
On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches
24 matches
Mail list logo
