On Wed, 4 Jun 2008, Joey Hess wrote:
I definitely doubt that because there is no other explanation for #484167.
Conffiles are not moved into place until package configuration time,
so #484167 is entirely consistent with the latter call I describe
above.
Ah OK, this explains the problem. So
Package: wnpp
Severity: wishlist
Owner: markus schnalke <[EMAIL PROTECTED]>
* Package name: genwebgallery
Version : 0.5
Upstream Author : markus schnalke <[EMAIL PROTECTED]>
* URL : http://prog.marmaro.de/genwebgallery
* License : MIT/X
Programming Lang: sh
For the next version of Lintian, I'd like to drop or change a few checks
that have been around for a while, and I wanted to run that past everyone
here in case anyone objects or sees a reason to retain them.
I: non-standard-architecture
I: non-standard-arch-in-source-relation
These tags are issue
Steve McIntyre wrote:
> We've made it abundantly clear over the years why our version of
> testing exists and how it's going to be managed. End of story.
I hope "this is why it is the way it is" is not the end of story forever!
http://kitenet.net/~joey/code/debian/cut
--
see shy jo
signature.
Andreas Tille wrote:
> On Wed, 4 Jun 2008, Joey Hess wrote:
>
>> The current triggers code does not call the triggered script each time a
>> file is touched. The triggered script is called once at the end of the
>> dpkg run, and once after the set of changed packages are unpacked. (I'm
>> not sure
Mike Bird <[EMAIL PROTECTED]> writes:
> An alternative approach would be for packages to be retained in
> Testing for the benefit of the hundreds of thousands of desktop and
> laptop users who need to use Testing, and for the few members of the
> release team to use a filtered package list. The fi
On Wed June 4 2008 13:53:58 Steve McIntyre wrote:
> If you're so keen on using your own version of testing as your own
> special distribution, then all the packages and tools are available to
> allow you to maintain it for yourself.
Steve,
We use simple cross-distro scripts, in some ways similar
On Wed, 4 Jun 2008, James Vega wrote:
The number of times update-menus is called should be at most as many as
before triggers were introduced.
No. It might be that packages ship more than one file in /usr/lib/menu
and /usr/share/menu and each file there seems to trigger an update-menus
run (e
On Wed, 4 Jun 2008, Joey Hess wrote:
The current triggers code does not call the triggered script each time a
file is touched. The triggered script is called once at the end of the
dpkg run, and once after the set of changed packages are unpacked. (I'm
not sure why the latter call happens.)
I
Mike Bird wrote:
>
>An alternative approach would be for packages to be retained
>in Testing for the benefit of the hundreds of thousands of
>desktop and laptop users who need to use Testing, and for
>the few members of the release team to use a filtered package
>list. The filtered package list wo
On Wed, Jun 04, 2008 at 10:06:22PM +0200, Andreas Tille wrote:
> On Wed, 4 Jun 2008, Joey Hess wrote:
>
>> That would prevent update-menus from being run if a package was
>> installed not using apt.
>
> Yes, this is correct. But what is actually the advantage of calling
> update-menus using trigge
Andreas Tille wrote:
> Yes, this is correct. But what is actually the advantage of calling
> update-menus using triggers instead of doing it in the postinst.
> I always assumed that triggers would care for calling a programm
> at the right time (in the case of update-menus I would regard the
> rig
On Wed, 4 Jun 2008, Joey Hess wrote:
That would prevent update-menus from being run if a package was
installed not using apt.
Yes, this is correct. But what is actually the advantage of calling
update-menus using triggers instead of doing it in the postinst.
I always assumed that triggers wou
Andreas Tille wrote:
> in menu 2.1.39 the trigger feature was implemented. I wonder whether
> this implementation is really clever because update-menus which might
> take some time is called for every package that touches /usr/lib/menu
> or /usr/share/menu. While there is a migration path describ
Hi,
in menu 2.1.39 the trigger feature was implemented. I wonder whether
this implementation is really clever because update-menus which might
take some time is called for every package that touches /usr/lib/menu
or /usr/share/menu. While there is a migration path described in
#473467 which bri
Frank Lichtenheld <[EMAIL PROTECTED]> writes:
> On Wed, Jun 04, 2008 at 02:20:08PM +0200, Goswin von Brederlow wrote:
>> Lars Wirzenius <[EMAIL PROTECTED]> writes:
>>
>> > ke, 2008-06-04 kello 13:38 +0200, Jeremiah C. Foster kirjoitti:
>> >> Log files should be out of bounds, even for --purge.
>>
On 03-Jun-08, 15:24 (CDT), Pierre Habouzit <[EMAIL PROTECTED]> wrote:
> [lighttpd fails install if something else is already running on port 80]
>
> Well I reckon it's not really well documented, I'm not not sure where
> to put that. dpkg is maybe not the place to put that. I'll followup that
>
Le mercredi 04 juin 2008 à 17:13 +0200, Johannes Wiedersich a écrit :
> All agreed for packages that are so unmaintained that it is better to
> drop them for good. The situation is different (and maybe more difficult
> [1]) if the package is *wanted* in lenny, but just removed by the
> release mana
Package: wnpp
Severity: wishlist
Owner: Miguel Gea Milvaques <[EMAIL PROTECTED]>
* Package name: festcat
Version : 20071213
Upstream Author : Anotonio Bonafonte
* URL : http://www.talp.upc.edu/festcat
* License : LGPL
Programming Lang: lisp?
Description
retitle 484381 ITP: libyaml -- YAML 1.1 parser and emitter written in C
On Wed, 2008-06-04 at 09:20 +0200, Stefano Zacchiroli wrote:
> Then please call it libyaml
Okay. New package here:
http://web.mit.edu/andersk/Public/deb/libyaml_0.1.1-1.dsc
http://web.mit.edu/andersk/Public/deb/libyaml_0.1
On Wed June 4 2008 09:36:07 Pierre Habouzit wrote:
> Package: *
> Pin: release a=testing
> Pin-Priority: 990
>
> Package: *
> Pin: release a=unstable
> Pin-Priority: 500
Downsides include:
(1) Not something a newbie should be worrying about.
(2) Bug reports from Testing+Un
On Wed, Jun 04, 2008 at 02:11:51PM +, Johannes Wiedersich wrote:
> Arguments like
>
> On 2008-06-04 15:34, Pierre Habouzit wrote:
> >> (2) To a user who wishes to use a working feature of an imperfect
> >> package, Debian is better with the imperfect package than
> >> without: MISSING
On Tue, Jun 03, 2008 at 08:58:54PM +0200, Jeffrey Ratcliffe wrote:
> Fine. Although it always annoyed me that my $HOME filled up with
> spurious dotfiles whose origin I'm not necessarily sure of, and that a
> good installer could know to remove them if the package were purged.
If you run a shared
Andrea Bolognani skrev:
When you have a lot of software installed on your system, it might get
difficult to trace exactly which configuration files you need and which
ones you don't need.
Now imagine the following situation: a package's maintainer can declare the
per-user configuration/cache fil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2008-06-04 16:31, Charles Plessy wrote:
> Our packages are free software, so imperfect ones removed from the
> archive can be redistributed in third-party apt repository if there is a
> niche for this. This way, the decisions of removal can be prove
Le Wed, Jun 04, 2008 at 02:31:22AM -0700, Mike Bird a écrit :
>
> (2) To a user who wishes to use a working feature of an imperfect
> package, Debian is better with the imperfect package than
> without: MISSING PACKAGE < IMPERFECT PACKAGE < PERFECT PACKAGE.
> This is true even if the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2008-06-04 16:11, Johannes Wiedersich wrote:
> [1] search +testing +lenny on
The searches were performed without the '+' to have 'testing or lenny' etc.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIRqPFC1NzPRl9qEURAs70AJ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2008-06-03 19:59, Pierre Habouzit wrote:
> It depends of your definition of usable. I don't think it's usable on
> a daily basis because:
FWIW, let the users decide what they use or want to use. I took a curde
estimate by counting what the reader
On Wed, Jun 04, 2008 at 08:42:36AM +0200, Andreas Tille wrote:
> On Tue, 3 Jun 2008, Jeffrey Austen wrote:
> Ahh, I think here is the problem. I just purged my cdd-common and
> can now reproduce this. I'm afraid that the new trigger feature of
> dpkg is causing this problem. If I understood thin
On Wed, Jun 04, 2008 at 09:31:22AM +, Mike Bird wrote:
> On Wed June 4 2008 00:59:15 Pierre Habouzit wrote:
> > a broken software, or an inadequate one is more a problem to
> > me than not having it in Debian. Debian is about quality, not
> > quantity.
>
> (1) Pierre thus asserts IMPERFECT PA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2008-06-04 14:09, Riku Voipio wrote:
> ...for a certain subclass of _powerusers_ who are willing to
> walk through a minefield[1] using buggy software. For more typical
> endusers, buggy and unreliable software is a just big source of
> frustration.
Did you consider the case with $HOME being mounted on NFS with
rootsquash (which is set by default)? Should the postinst then 'su' to
each user to do the modifcations in that case then? How about if some
extra security policy is active like apparmor or selinux?
Sorry, the only sane option which i
On Wed, Jun 04, 2008 at 02:20:08PM +0200, Goswin von Brederlow wrote:
> Lars Wirzenius <[EMAIL PROTECTED]> writes:
>
> > ke, 2008-06-04 kello 13:38 +0200, Jeremiah C. Foster kirjoitti:
> >> Log files should be out of bounds, even for --purge.
> >
> > Doing that would mean log files never get clean
On Wed, Jun 04, 2008 at 01:38:30PM +0200, Jeremiah C. Foster wrote:
> > Richard Kettlewell writes ("What should postrm purge actually do?"):
> > > Things I'm uncertain about, that someone might actually miss:
> > > - log files
> >
> > Yes, these should be removed.
>
> I think removing log fil
Lars Wirzenius <[EMAIL PROTECTED]> writes:
> ke, 2008-06-04 kello 13:38 +0200, Jeremiah C. Foster kirjoitti:
>> Log files should be out of bounds, even for --purge.
>
> Doing that would mean log files never get cleaned up, unless the
> sysadmin realizes that they need to it manually. That's not a
On Wed, Jun 04, 2008 at 02:31:22AM -0700, Mike Bird wrote:
> (2) To a user who wishes to use a working feature of an imperfect
> package, Debian is better with the imperfect package than
> without: MISSING PACKAGE < IMPERFECT PACKAGE < PERFECT PACKAGE.
> This is true even if the imperfe
> On Mon June 2 2008 11:44:46 Lucas Nussbaum wrote:
> > See it the other way around: it shows testing the way stable could be if
> > nothing is done. I'm all for removing buggy packages early in the
> > release cycle: it makes it less likely that we release without a package
> > that many users nee
ke, 2008-06-04 kello 13:38 +0200, Jeremiah C. Foster kirjoitti:
> I think removing log files is a bad practice. A user may need to keep
> those log files (by law for example) and unbeknownst to them, debian
> has removed them when they removed web server X to replace it with
> web server Y.
In th
> Richard Kettlewell writes ("What should postrm purge actually do?"):
> > Is it written down anywhere what postrm purge is supposed to do?
> > Presumably remove some set of files, but what criteria should be used to
> > choose which?
> > Things I'm uncertain about, that someone might actually
* Marco d'Itri <[EMAIL PROTECTED]>, 2008-06-04 01:43:
On Jun 03, Piotr Lewandowski <[EMAIL PROTECTED]> wrote:
Debian Policy Manual states that 'Depends' declares an absolute dependency.
This is not the case with ifupdown as it works fine without it. Thus, I propose
to loosen it to 'Recommends'.
On Wed, 04 Jun 2008 12:16:40 +0200
Reinhard Tartler <[EMAIL PROTECTED]> wrote:
> > When you have a lot of software installed on your system, it might get
> > difficult to trace exactly which configuration files you need and which
> > ones you don't need.
>
> Which is a good reason to use software
Andrea Bolognani <[EMAIL PROTECTED]> writes:
>> Its the job of the user to cleanup his home. He knows best what he still
>> needs. Or at least should know.
>
> When you have a lot of software installed on your system, it might get
> difficult to trace exactly which configuration files you need and
Package: wnpp
Severity: wishlist
Owner: Julien Danjou <[EMAIL PROTECTED]>
* Package name: duma
Version : 2.5.14
Upstream Author : Hayati Ayguen <[EMAIL PROTECTED]>
Michael Eddington <[EMAIL PROTECTED]>
* URL : http://duma.sf.net
* License : G
On Wed June 4 2008 00:59:15 Pierre Habouzit wrote:
> a broken software, or an inadequate one is more a problem to
> me than not having it in Debian. Debian is about quality, not
> quantity.
(1) Pierre thus asserts IMPERFECT PACKAGE < MISSING PACKAGE.
(2) To a user who wishes to use a working fea
On Tue, 3 Jun 2008 21:05:30 +0200
Michael Koch <[EMAIL PROTECTED]> wrote:
> So a good installer knows when you mount your $HOME on multiple machines
> and use some config files only on some machines?
>
> Its the job of the user to cleanup his home. He knows best what he still
> needs. Or at leas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Am Di den 3. Jun 2008 um 20:19 schrieb Thomas Viehmann:
>> Same me, so please ignore the mail. I did miss the link at the end of
>> the page that there are 3 pages of entries and that one can go to the
>> next page. Confusing.
> So you want them
On Tue, Jun 03, 2008 at 06:56:56PM -0400, Anders Kaseorg wrote:
> * Package name: yaml
> * URL : http://pyyaml.org/wiki/LibYAML
Then please call it libyaml, as "yaml" is the format name and gives no
way to understand which particular implementation of the format is that
you are pac
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2008-06-03 22:26, Josselin Mouette wrote:
> Le mardi 03 juin 2008 à 21:06 +0200, Johannes Wiedersich a écrit :
>> As I've understood it so far, testing is for 'people trying to help the
>> developers by testing the software prior to release'. If too
48 matches
Mail list logo
