headers
Abhishek Dasgupta | 1 Jul 2010 01:24
Picon
Gravatar

Bug#587701: ITP: flashbake -- automated version control with git

Package: wnpp
Severity: wishlist
Owner: Abhishek Dasgupta <abhidg <at> gmail.com>

* Package name    : flashbake
  Version         : 0.26.2
  Upstream Author : Thomas Gideon <cmdln--thecommandline--net>
* URL             : http://bitbucketlabs.net/flashbake/
* License         : GPL-3
  Programming Lang: Python
  Description     : automated version control with git

Flashbake is a tool which watches files and automatically checks
them in to a git repository. The commit lines can be customised
using plugins and are autogenerated. Thus it simplifies life for
the user by taking off the burden of manually committing changes
and allowing one to focus on the work.
Permalink | Reply | 0 comments |
headers
Daniel Pittman | 1 Jul 2010 05:39
Gravatar

Re: Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues

Goswin von Brederlow <goswin-v-b <at> web.de> writes:
> Daniel Pittman <daniel <at> rimspace.net> writes:
>> Petter Reinholdtsen <pere <at> hungry.com> writes:
>>> [Goswin von Brederlow]

[... waiting for enough devices to show up ...]

>>> The only known solution today is to add a long delay during boot to try to
>>> increase the chance of having all devices available when they are
>>> needed. :(
>>>
>>>> The big question is how long do you wait?
>>
>> Please, for the love of everything sane, ask a low priority debconf question
>> with a default of five minutes[1] — and display a note in the initramfs about
>> what you are waiting for, and how long.
>
> For most people that is about 4 minutes and 30 seconds too long.  And don't
> forget that this needs to be multiple times. Usualy once in the initramfs
> and once in the real system. But if devices are really multilayered you can
> end up having to do this for every layer.
>
> The multipath waits for both its paths. Then the raid waits for all its
> devices. Then the drbd waits for both its other hosts to boot. That is 15
> minutes already in case of a bad error.

*nod*

>> (Actually, the countdown from the DRBD init script, including the prompt to
>>  override the configured wait time, would be absolutely wonderful to have
(Continue reading)

Permalink | Reply | 2 comments |
headers
Goswin von Brederlow | 1 Jul 2010 09:31
Picon

Re: Advanced Startup/Shutdown with Multilayered Block Devices and Related Issues

Daniel Pittman <daniel <at> rimspace.net> writes:

> Goswin von Brederlow <goswin-v-b <at> web.de> writes:
>> Daniel Pittman <daniel <at> rimspace.net> writes:
>>> Petter Reinholdtsen <pere <at> hungry.com> writes:
>>>> [Goswin von Brederlow]
>
> [... waiting for enough devices to show up ...]
>
>>>> The only known solution today is to add a long delay during boot to try to
>>>> increase the chance of having all devices available when they are
>>>> needed. :(
>>>>
>>>>> The big question is how long do you wait?
>>>
>>> Please, for the love of everything sane, ask a low priority debconf question
>>> with a default of five minutes[1] — and display a note in the initramfs about
>>> what you are waiting for, and how long.
>>
>> For most people that is about 4 minutes and 30 seconds too long.  And don't
>> forget that this needs to be multiple times. Usualy once in the initramfs
>> and once in the real system. But if devices are really multilayered you can
>> end up having to do this for every layer.
>>
>> The multipath waits for both its paths. Then the raid waits for all its
>> devices. Then the drbd waits for both its other hosts to boot. That is 15
>> minutes already in case of a bad error.
>
> *nod*
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexandre Fournier | 1 Jul 2010 10:45
Picon
Favicon

Fw: Bug#587620: (wishlist) debian packages: add an optional "Why" field to "suggest" entries (in the dependency field)


Hello everyone,

Goswin von Brederlow (I think he is an apt maintainer)
suggested to forward this wishlist bug report to debian-devel.

Best regards,

Alexandre Fournier

 ----- Message Transféré -----

Date: Wed, 30 Jun 2010 16:44:23 +0200
De: Goswin von Brederlow <goswin-v-b <at> web.de>
À: Alexandre Fournier <brutus <at> free.fr>
Cc: 587620 <at> bugs.debian.org
Sujet: Re: Bug#587620: apt: add an optionnal "Why" field to "suggest"
entries (in the dependency field)

Alexandre Fournier <brutus <at> free.fr> writes:

> Package: apt
> Version: 0.7.25.3
> Severity: wishlist
>
> Hello,
>
> Sometimes, from a user point of view, understanding  why a package A
> recommends or suggests package B1 or B2 is not straightforward.
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Neil Williams | 1 Jul 2010 12:53
Picon
Favicon
Gravatar

Re: Fw: Bug#587620: (wishlist) debian packages: add an optional "Why" field to "suggest" entries (in the dependency field)

On Thu, 1 Jul 2010 10:45:20 +0200
Alexandre Fournier <brutus <at> free.fr> wrote:

> > Sometimes, from a user point of view, understanding  why a package A
> > recommends or suggests package B1 or B2 is not straightforward.
> >
> > It would be nice to add  an optionnal  "why" field to explain what
> > features are enabled in package A when installing package B1.
> >
> > Ideally, this could be displayed when the user calls : apt-cache show
> > or looks at the package data in another front-end for apt. This way,
> > they would know from the start if they want to install package B1 all
> > along, when installing A.

A single field in debian/control is probably too short to explain the
reasons in a lot of cases and adds yet more bloat to the Packages files
- make it long enough to be particularly useful and the bloat gets even
worse.

If there is a v.short reason, it probably should be part of the
Description anyway (so that it can be translated and easily removed
to reduce the size of the Packages files). If it needs more than a few
words of explanation, the reasoning should go in the manpage or
whatever other form of documentation the package can provide, like Help
files. (Depending on whether the extra functionality is related to
upstream additions or Debian-specific changes.) Yes, you only get to see
those after installation of the main package but that's not an issue -
in this scenario, the user wants the main package anyway, just isn't
sure about the others.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Fathi Boudra | 1 Jul 2010 13:13
Picon
Favicon

Bug#587747: ITP: qmf -- Qt Messaging Framework (QMF)

Package: wnpp
Severity: wishlist
Owner: Fathi Boudra <fabo <at> debian.org>

* Package name    : qmf
  Version         : 1.0~2010w23
  Upstream Author : Nokia Corporation
* URL             : http://qt.gitorious.org/qt-labs/messagingframework
* License         : LGPL with exception or GPL3
  Programming Lang: C++
  Description     : Qt Messaging Framework (QMF)

 The Qt Messaging Framework, QMF, consists of a C++ library and daemon server
 process that can be used to build email clients, and more generally software
 that interacts with email and mail servers.
Permalink | Reply | 0 comments |
headers
Fabian Greffrath | 1 Jul 2010 13:01
Favicon

Re: Fw: Bug#587620: (wishlist) debian packages: add an optional "Why" field to "suggest" entries (in the dependency field)

>> It would be nice to add  an optionnal  "why" field to explain what
>> features are enabled in package A when installing package B1.

IMHO if the suggests isn't obvious, this should be part of the package 
description. Something like "this package can also handle postscript 
files if ghostscript is installed."

  - Fabian
Permalink | Reply | 0 comments |
headers
Hideki Yamane | 1 Jul 2010 13:40
Picon
Favicon
Gravatar

Re: python-twitter package should be removed from testing (Re: all twitter client should support OAuth before they will drop Basic Auth in August

On Wed, 30 Jun 2010 18:08:02 +0200
Josselin Mouette <joss <at> debian.org> wrote:
> >  Okay, I propose once python-twitter package should be removed from testing.
> >  If we're lucky :), it'll be in squeeze, again.
> 
> You should probably file a RC bug so that it doesn’t migrate again
> without being fixed first.

 Thanks Joss, filed as Bug#587749

--

-- 
Regards,

 Hideki Yamane     henrich  <at>  debian.or.jp/org
 http://wiki.debian.org/HidekiYamane
Permalink | Reply | 1 comment |
headers
Fathi Boudra | 1 Jul 2010 14:51
Picon
Favicon

Bug#587759: ITP: qt-simulator -- simulator for Qt applications running on Nokia devices

Package: wnpp
Severity: wishlist
Owner: Fathi Boudra <fabo <at> debian.org>

* Package name    : qt-simulator
  Version         : 1.0.0
  Upstream Author : Nokia
* URL             : http://labs.trolltech.com/page/Projects/Tools/QtSimulator
* License         : LGPL2
  Programming Lang: C++
  Description     : simulator for Qt applications running on Nokia devices

  Qt Simulator is a fast and lightweight simulator for Qt applications
  intended to run on Nokia devices. As such, it should be your first
  target when developing a Qt application for Symbian or Maemo/Meego
  devices.
Permalink | Reply | 0 comments |
headers
Goswin von Brederlow | 1 Jul 2010 15:22
Picon

Re: Fw: Bug#587620: (wishlist) debian packages: add an optional "Why" field to "suggest" entries (in the dependency field)

Neil Williams <codehelp <at> debian.org> writes:

> On Thu, 1 Jul 2010 10:45:20 +0200
> Alexandre Fournier <brutus <at> free.fr> wrote:
>
>> > Sometimes, from a user point of view, understanding  why a package A
>> > recommends or suggests package B1 or B2 is not straightforward.
>> >
>> > It would be nice to add  an optionnal  "why" field to explain what
>> > features are enabled in package A when installing package B1.
>> >
>> > Ideally, this could be displayed when the user calls : apt-cache show
>> > or looks at the package data in another front-end for apt. This way,
>> > they would know from the start if they want to install package B1 all
>> > along, when installing A.
>
> A single field in debian/control is probably too short to explain the
> reasons in a lot of cases and adds yet more bloat to the Packages files
> - make it long enough to be particularly useful and the bloat gets even
> worse.
>
> If there is a v.short reason, it probably should be part of the
> Description anyway (so that it can be translated and easily removed
> to reduce the size of the Packages files). If it needs more than a few
> words of explanation, the reasoning should go in the manpage or
> whatever other form of documentation the package can provide, like Help
> files. (Depending on whether the extra functionality is related to
> upstream additions or Debian-specific changes.) Yes, you only get to see
> those after installation of the main package but that's not an issue -
> in this scenario, the user wants the main package anyway, just isn't
(Continue reading)

Permalink | Reply | 0 comments |

Gmane