On Mon, 21 Jan 2008, Sebastian Pipping wrote:
hm, if we have ITA/ITPs with more than 300 days of no activity than
we need a fix here i guess :-)
i added a "dust" column showing the number of days without activity.
also the cron job updates existing entries finally.
this query shows some very o
Luk Claes wrote:
There is already a process that does that, though it takes into account
any follow-up on the bug report to reset the timer which you clearly
don't...
hm, if we have ITA/ITPs with more than 300 days of no activity than
we need a fix here i guess :-)
i added a "dust" column show
Rafael Laboissiere wrote:
This web page is great. It would be good to also show the submitter of the
bug in a column.
added.
sebastian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Sun, Jan 20, 2008 at 12:54:42PM -0500, Joey Hess wrote:
> Why are we copying shell functions off of wikis and embedding them into
> our maintainer scripts instead of adding the code to Debian once in a
> utility?
>
> (I've considered putting this code in debhelper, but the way it's used
> is no
[Michael Biebl]
> Why do you think, debhelper is not the correct place to handle this?
> Imho it would be fairly easy to write a debhelper command for this.
> Another way would be, to make dpkg smarter about such cases. As you
> want to write a special utility for this, how would you hook this up
Josselin Mouette <[EMAIL PROTECTED]> writes:
> Le mercredi 09 janvier 2008 à 11:19 +0100, Stefano Zacchiroli a écrit :
>> Regarding the list above I would guess that what you want is something
>> like the following:
>> * glib -> GLib
> * Glib -> GLib
glib is a regular English word, so I'll lea
Luk Claes wrote:
> It would probably better to focus on one of the alternatives of xmms
> like audacious, xmm2 or bmpx...
whereas audacious is imho the only worth one.
> snapshot.debian.net might help if you really want to stick with xmms...
or http://daniel.debian.net/packages/xmms/ as much as
Joey Hess wrote:
Why are we copying shell functions off of wikis and embedding them into
our maintainer scripts instead of adding the code to Debian once in a
utility?
I'm all for this! The sad truth is, that currently a lot of maintainers
simply forget to handle conffiles removals/moves. So h
On Jan 17, 2008 9:35 PM, Niko Tyni <[EMAIL PROTECTED]> wrote:
> Sandro Tosi <[EMAIL PROTECTED]>
>mathomatic-primes
Fixed, sent to sponsor to upload.
Thanks!
Sandro
--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
--
To UNSUBSCRIBE, email to
On Sun, Jan 20, 2008 at 04:44:34PM +0100, Adeodato Simó wrote:
> In summary, `run-parts` is safe wrt .dpkg-bak, `run-parts --lsbsysinit`
> is not.
Easy enough to fix if need be.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Petter Reinholdtsen wrote:
> I just noticed that when I rewrote the conffile removal code in
> initscripts recently, I copied code from
> http://wiki.debian.org/DpkgConffileHandling and accidently replaced
> the code that created *.dpkg-old files with code that would create
> *.dpkg-bak. I will ch
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Package name: ttf-ume
Version: 382-1
Upstream Author: Wataru Horai
URL: http://sourceforge.jp/projects/ume-font/wiki/FrontPage
License: Wada Laboratory (BSD-like licence. It is same as koch
* Roger Leigh [Sun, 20 Jan 2008 15:30:43 +]:
> On Sun, Jan 20, 2008 at 03:10:38PM +0100, Michael Biebl wrote:
> > Regarding run-parts: There is no problem afaik. I quickly tried this:
> > # mkdir test
> > # touch test/foo
> > # touch test/foo.dpkg-old
> > # touch test/foo.dpkg-bak
> > # run-p
On Sun, Jan 20, 2008 at 03:10:38PM +0100, Michael Biebl wrote:
> Roger Leigh wrote:
>> Hi folks,
>>
>> I noticed earlier today that many packages are creating copies of
>> conffiles in their maintainer scripts with the extension ".dpkg-bak",
>> which is not an extension used or removed by dpkg:
>
>
Sebastian Pipping wrote:
> Luk Claes wrote:
>> xmms removal was decided some time ago.
>
> i am working on a project partly depending
> on parts of xmms. in case it is removed
> i will need at least backups of all
> related package sources so i can still
> have the packages at my place.
It would
Luk Claes wrote:
xmms removal was decided some time ago.
i am working on a project partly depending
on parts of xmms. in case it is removed
i will need at least backups of all
related package sources so i can still
have the packages at my place.
where can i find more information about this?
Package: wnpp
Severity: wishlist
Owner: Bram Senders <[EMAIL PROTECTED]>
* Package name: contextfree
Version : 2.1
Upstream Author : Chris Coyne, John Horigan and Mark Lentczner
* URL : http://contextfreeart.org/
* License : GPL
Programming Lang: C++
Descri
Roger Leigh wrote:
Hi folks,
I noticed earlier today that many packages are creating copies of
conffiles in their maintainer scripts with the extension ".dpkg-bak",
which is not an extension used or removed by dpkg:
Say you name the file /etc/foo.dpkg-old instead of /etc/foo.dpkg-bak.
dpkg won
Hi,
> > Logging into the chroot reveals /dev/null is 644, not 666 as I would expect.
> >
> > How can I fix the permissions of /dev/null under the chroot?
> >
> > Are my problems likely to be cause by the fact that my machine is
> > running as a vserver?
>
> Actually /dev/null is not even a charact
Marcin Owsiany wrote:
> An xmms rev-dep I maintain (xmms-xf86audio) is useless without xmms, and
> not really portable to any of its replacements. Therefore I agree it
> should be removed if xmms is removed. However:
>
> - the reporter said to ask for removal after xmms is removed
> - the ftpmas
An xmms rev-dep I maintain (xmms-xf86audio) is useless without xmms, and
not really portable to any of its replacements. Therefore I agree it
should be removed if xmms is removed. However:
- the reporter said to ask for removal after xmms is removed
- the ftpmaster removal wiki page says reverse
Package: wnpp
Owner: Varun Hiremath <[EMAIL PROTECTED]>
Severity: wishlist
* Package name: enthought-chaco2
Version : 2.0.1b1
Upstream Author : Enthought, Inc.
* URL or Web page : http://code.enthought.com/chaco/
* License : BSD-style
Description : interactive plottin
[Roger Leigh]
> A lot of scripts are copying the rm_conffile script from
> http://wiki.debian.org/DpkgConffileHandling which adds a .dpkg-bak
> suffix to old conffiles.
>
> Are such names allowed? Why can't .dpkg-old be used instead?
I just noticed that when I rewrote the conffile removal code i
23 matches
Mail list logo
