Re: mplayer, the time has come

[giskard]

On Thu, 24 Feb 2005 19:40:35 -0500
Glenn Maynard <[EMAIL PROTECTED]> wrote:

> > 
> > *   Why the "--disable-aa" ?
> > Ok caca is better than aa but it's not enabled either.
> 
> libaa, the ASCII art library?  I'd hope that'd be disabled in the
> normal build.  It's a useless novelty; I certainly wouldn't want to
> have to install it to get a video player.  (Of course, if it can bind
> dynamically at runtime, that's not an issue; I don't know if it does
> that.)

many people who I know, especially artists who use free software, often
use the reproduction in ascii art (new kind of art).
i think that remove it would be a huge limitation.
-- 
ciao giskard

spero nel ritorno del grande bastardo.



pgp7WgOpJrtPm.pgp
Description: PGP signature

Re: mplayer, the time has come

[Marco d'Itri]

On Feb 25, giskard <[EMAIL PROTECTED]> wrote:

> many people who I know, especially artists who use free software, often
> use the reproduction in ascii art (new kind of art).
The artists you know are not many people and they are not representative
of the user base in any way.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: mplayer, the time has come

[Petri Latvala]

On Fri, Feb 25, 2005 at 10:36:21AM +0100, Marco d'Itri wrote:
> On Feb 25, giskard <[EMAIL PROTECTED]> wrote:
> 
> > many people who I know, especially artists who use free software, often
> > use the reproduction in ascii art (new kind of art).
> The artists you know are not many people and they are not representative
> of the user base in any way.


Those who want to use the aa backend can use -vo sdl:aa if
libsdl1.2debian-all is installed (and the mplayer package is compiled
with sdl support).


-- 
Petri Latvala


signature.asc
Description: Digital signature

Re: mplayer, the time has come

[Ron Johnson]

On Fri, 2005-02-25 at 10:36 +0100, Marco d'Itri wrote:
> On Feb 25, giskard <[EMAIL PROTECTED]> wrote:
> 
> > many people who I know, especially artists who use free software, often
> > use the reproduction in ascii art (new kind of art).
> The artists you know are not many people and they are not representative
> of the user base in any way.

"I just don't understand how Reagan got elected.  No one I know
voted for him!"

In other words, just because *you* don't know anyone who uses AA,
that doesn't mean that a decent number of people *do* use AA.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"Clearly the allies may not like it, and I think that's our great
concern - where's the backbone of Russia, where's the backbone of
France, where are they in expressing their condemnation of such
clearly illegal activity: they're now climbing into a box and
they will have enormous difficulty not following up on this if
there is not compliance."
John Kerry - CNN Crossfire / November 12, 1997
http://www.scoop.co.nz/mason/stories/HL0403/S00076.htm


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mplayer, the time has come

[Petter Reinholdtsen]

[Ron Johnson]
> "I just don't understand how Reagan got elected.  No one I know
> voted for him!"
> 
> In other words, just because *you* don't know anyone who uses AA,
> that doesn't mean that a decent number of people *do* use AA.

You are absolutely right. :)

But there is always a chance of someone rigging the election.
http://www.blackboxvoting.org/> and
http://www.verifiedvoting.org/> give some background on that. :)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mplayer, the time has come

[giskard]

On Fri, 25 Feb 2005 10:36:21 +0100
[EMAIL PROTECTED] (Marco d'Itri) wrote:

> On Feb 25, giskard <[EMAIL PROTECTED]> wrote:
> 
> > many people who I know, especially artists who use free software,
> > often use the reproduction in ascii art (new kind of art).

> The artists you know are not many people and they are not
> representative of the user base in any way.

ok.

just for this we cannot decide if a compile-option is useful for all
people or not. (excluding security options).

probably it could be intended as a new kind of discrimination? 

btw she saw the light:

 l'ascii art è l'arte degli "hacker"
 ascii art is the art of "hacker"

-- 
ciao giskard

spero nel ritorno del grande bastardo.



pgpGsnAx7OADs.pgp
Description: PGP signature

Bug#296873: ITP: jackbeat -- a drummachine-like audio sequencer with JACK support

[Guillaume Pellerin]

Package: wnpp
Severity: wishlist
Owner: Guillaume Pellerin <[EMAIL PROTECTED]>

* Package name: jackbeat
  Version : 0.3.3
  Upstream Author : Olivier Guilyardi 
* URL : http://www.xung.org/jackbeat/
* License : GPL
  Description : a drummachine-like audio sequencer with JACK support

  Jackbeat is an audio sequencer with the following features :

  * drummachine-like interface for fast and easy edition
  * realtime operation : while playing, the pattern can be edited 
and resized, the bpm rate modified, and new samples loaded
  * virtually unlimited number of tracks and beats
  * easy to use and yet powerful : just JACK it into jack-rack and 
you can apply LADSPA effect plugins on a per track basis, 
perform mastering with jackeq, jamin, etc...
  * loads and saves .jab files, Jackbeat's file format, based on XML 
and packed with tar.


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.5piem
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: the ongoing xfree86 buildd saga

[Goswin von Brederlow]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> Steve Langasek <[EMAIL PROTECTED]> writes:
>
>> I don't think it would hurt if maintainers whose packages are in this state
>> would email the relevant @buildd.debian.org addresses and cc:
>> debian-release on the message -- now, rather than waiting for the buildds to
>> be fixed.  Hopefully, this would save the buildd maintainers the trouble of
>> having to look through all the build logs to find the ones related to this
>> breakage, and they can requeue them as a batch.
>
> So I've done this, but I am skeptical about how much it will help.
>
> For example, if even *one* buildd maintainer doesn't requeue with some
> kind of promptness, then the only way to deal with it will be to make
> a new upload, which will force a recompile everywhere.

You can also find someone with that arch and get a manual build
uploaded.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mplayer, the time has come

[giskard]

On Fri, 25 Feb 2005 12:38:39 +0200
Petri Latvala <[EMAIL PROTECTED]> wrote:

> On Fri, Feb 25, 2005 at 10:36:21AM +0100, Marco d'Itri wrote:
> > On Feb 25, giskard <[EMAIL PROTECTED]> wrote:
> > 
> > > many people who I know, especially artists who use free software,
> > > often use the reproduction in ascii art (new kind of art).
> > The artists you know are not many people and they are not
> > representative of the user base in any way.
> 
> 
> Those who want to use the aa backend can use -vo sdl:aa if
> libsdl1.2debian-all is installed (and the mplayer package is compiled
> with sdl support).

[13:11:3Size: [EMAIL PROTECTED]:~]$ apt-cache show
libsdl1.2debian-all
Depends: aalib1
Size: 184960

[13:11:[EMAIL PROTECTED]:~]$ apt-cache show aalib1
Size: 53524

and:

[13:18:[EMAIL PROTECTED]:~]$ apt-cache rdepends libsdl1.2debian-all
libsdl1.2debian-all
Reverse Depends:
  libsdl1.2debian-oss
  libsdl1.2debian-oss
  libsdl1.2debian-nas
  libsdl1.2debian-nas
  libsdl1.2debian-esd
  libsdl1.2debian-esd
  libsdl1.2debian-arts
  libsdl1.2debian-arts
  libsdl1.2debian-alsa
  libsdl1.2debian-alsa
 |libsdl1.2debian

.

-- 
ciao giskard

spero nel ritorno del grande bastardo.



pgpiMBWVGH6gG.pgp
Description: PGP signature

Re: mplayer, the time has come

[Eduard Bloch]

#include 
* giskard [Fri, Feb 25 2005, 01:22:18PM]:

> > Those who want to use the aa backend can use -vo sdl:aa if
> > libsdl1.2debian-all is installed (and the mplayer package is compiled
> > with sdl support).
> 
> [13:11:3Size: [EMAIL PROTECTED]:~]$ apt-cache show
> libsdl1.2debian-all
> Depends: aalib1
> Size: 184960
> 
> [13:11:[EMAIL PROTECTED]:~]$ apt-cache show aalib1
> Size: 53524

And you point is...? 
I think 0.1% (guessed) of users that may need AA support can live with
extra 185kb in favor of 99.9% users saving that space.

Eduard.
-- 
OpenBSD fails miserably in this respect, and makes for an example of how NOT
to work with the community on security issues.  Their approach is, roughly,
"we fixed this a while ago but didn't tell anyone, so you're vulnerable and
we're not, ha-ha-ha".


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Tips wanted for debugging and testing Debian

[Steve Kemp]

On Thu, Feb 24, 2005 at 09:39:51PM +0100, Michael Tautschnig wrote:
> >You can browse our bug database at . A good way
> >to start is to search for any bugs in software you regularly use, and to
> >see if you can help out.
> >
> 
> But what could one do, if the maintainer doesn't react (for some time) - 
> such that even bugreport with fixes provided are never acted upon?

  If a bug is serious, and not a trivial thing, and if a patch has
 been filed then a NMU could be applied.

  Isn't that what we do when serious bugs are present and the maintainer
 doesn't fix them?

  (And if it's wishlist bug you'll expect to be flamed .. :)

Steve
--


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Tips wanted for debugging and testing Debian

[Michael Tautschnig]

 If a bug is serious, and not a trivial thing, and if a patch has
been filed then a NMU could be applied.
But only a Debian developer can do so, right?
When saying "trivial" - did you mean easy to fix or the priority of a 
bug (i.e., wishlist)?

[...]
Thanks,
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Tips wanted for debugging and testing Debian

[Steinar H. Gunderson]

On Fri, Feb 25, 2005 at 02:41:48PM +0100, Michael Tautschnig wrote:
>> If a bug is serious, and not a trivial thing, and if a patch has
>> been filed then a NMU could be applied.
> But only a Debian developer can do so, right?

You can have a sponsored NMU -- I did such a thing once.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Tips wanted for debugging and testing Debian

[Steve Kemp]

On Fri, Feb 25, 2005 at 02:41:48PM +0100, Michael Tautschnig wrote:

> > If a bug is serious, and not a trivial thing, and if a patch has
> >been filed then a NMU could be applied.
> But only a Debian developer can do so, right?

  Usually, but I've sponsored NMU uploads by non-DDs before.

> When saying "trivial" - did you mean easy to fix or the priority of a 
> bug (i.e., wishlist)?

  I mean it should be a serious bug which is affecting real people
 but has gone unadressed.  Not something like adding a new feature
 which was filed as a wishlist.

  It's a judgement which people may make differently.

Steve
--


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: svn.debian.org: Automatically putting log message into debian/changelog?

[Torsten Landschoff]

Hi Joey, 

On Thu, Feb 24, 2005 at 04:42:49PM -0500, Joey Hess wrote:
> I've done this for years using the attached script (which will work with
> both svn and cvs (less well), and can also tag releases).

Thanks, that was exactly what I looking for. I already had scheduled
some hacking for this. :)

Now I have to update it for svk ;)

Greetings

Torsten


signature.asc
Description: Digital signature

Re: Tips wanted for debugging and testing Debian

[Michael Tautschnig]

 Usually, but I've sponsored NMU uploads by non-DDs before.
Sounds interesting - how does that work?

When saying "trivial" - did you mean easy to fix or the priority of a
bug (i.e., wishlist)?
 I mean it should be a serious bug which is affecting real people
but has gone unadressed.  Not something like adding a new feature
which was filed as a wishlist.
 It's a judgement which people may make differently.
That seems sensible to me too.
I might get flamed, but I'd like to mention just one example - the 
a2ps-package. Some of the bugs might be really easy to fixed (patches are 
attached) - but have not even been acknowledged by the developer.

So - is there anything I could do to help?
Thanks,
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

list of packages on private website

[Bartosz Fenski aka fEnIo]

Hello.

That's rather OT, but I wanted to target my question at developers, cause
I suppose that's the only group which would be able to help me.

I would like to put on my homepage list of packages that I maintain. 
I suppose that the easiest way would be to fetch this information from 
ldap database. I don't want to reinvent the wheel, and I'm sure some of 
you have already similar lists on your websites.

I'm also quite sure you want to share your code with others, don't you? ;)

So if someone could announce that he/she has some code, and in turn makes 
my life easier, then it's time to do that.

The perfect solution would be some script which would download these
information once a week and build static pages from it. This way
I wouldn't overload database.

So... who wants to share his code? ;)

regards
fEnIo


-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

Re: list of packages on private website

[Roberto C. Sanchez]

Bartosz Fenski aka fEnIo wrote:
Hello.
That's rather OT, but I wanted to target my question at developers, cause
I suppose that's the only group which would be able to help me.
I would like to put on my homepage list of packages that I maintain.
I suppose that the easiest way would be to fetch this information from
ldap database. I don't want to reinvent the wheel, and I'm sure some of
you have already similar lists on your websites.
I'm also quite sure you want to share your code with others, don't you? ;)
So if someone could announce that he/she has some code, and in turn makes
my life easier, then it's time to do that.
The perfect solution would be some script which would download these
information once a week and build static pages from it. This way
I wouldn't overload database.
I use a proprietary super-secret file format called Packages.gz.  I
require my users to license (for $699) a special browsing tool.  I
give then a choice between synaptic (desktop users), aptitude (server
users), and dselect (masochists). :-)
Naturally, all of this is in jest.  Just curious, why not just let them
view your packages through one of the above tools?
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr


signature.asc
Description: OpenPGP digital signature

Re: list of packages on private website

[Christoph Berg]

Re: Bartosz Fenski aka fEnIo in <[EMAIL PROTECTED]>
> 
> I would like to put on my homepage list of packages that I maintain. 
> I suppose that the easiest way would be to fetch this information from 
> ldap database. I don't want to reinvent the wheel, and I'm sure some of 
> you have already similar lists on your websites.

I tried this myself, but gave up eventually ;-) Just put a link there
to your QA page.

Otherwise, try something like
$ grep-available -FMaintainer fenio -sPackage

(Don't forget "dselect update" before.)

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: dh_movefiles, tar vs. mv

[Frank Küster]

Eric Dorland <[EMAIL PROTECTED]> schrieb:

> * Frank Küster ([EMAIL PROTECTED]) wrote:
>> Hi,
>> 
>> dh_movefiles internally uses tar to move file contents. I'm not sure why
>> it doesn't use mv, is it because mv moves the file block-by-block and
>> thus starts removing parts of the file before it is completely written,
>> and hence is less save?
>> 
>> Anyway: If I am only going to move complete subdirectories from the temp
>> tree to the package trees, is it in this case safe to use mv? It's much
>> faster, and it would safe space (because dh_movefiles only removes the
>> originals after the complete tarball has been extracted).
>
> Uhh, who cares? dh_movefiles has been superseded by dh_install. 

Well, fine. But the question remains: dh_install uses cp, not mv.  What
is the problem with using mv?  And would it be safe to use mv if I only
move complete directories?

TIA, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Automatic building of (parts of) the archive

[Frank Küster]

Hi,

in order to test whether packages that build-depend on tetex can still
be built with the upcoming version 3.0, I would like to automatically
build as many of these packages.  I know where I can read about setting
up a buildd, but two questions remain:

- are there any scripts that hand over the next package in a list after
  one build has finished (without setting up a copy of wanna-build...)?

- Does anybody have some ready-to-use code to find not only packages
  that build-depend on my package, but also those that build-depend on
  packages that depend on mine, or build-depend on packages that depend
  on packages that depend on mine, or...?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: dh_movefiles, tar vs. mv

[Daniel Burrows]

On Friday 25 February 2005 12:36 pm, Frank Küster wrote:
> Well, fine. But the question remains: dh_install uses cp, not mv.  What
> is the problem with using mv?  And would it be safe to use mv if I only
> move complete directories?

  I'd imagine that it doesn't use mv for the same reason "install" doesn't; 
ie, its purpose is to COPY files, not MOVE them.

  Anyway, I thought you were joking in your first message, but it looks like 
you're serious, so I'll answer this time.  If you're copying between files on 
the same device, mv will use the rename(2) system call, which is an atomic 
operation: ie, it doesn't "copy" the source files at all, it just links them 
into the target directory.  If you're copying between devices, mv will 
presumably copy the whole file before deleting it -- to actually remove a 
file "block-by-block" would mean a whole lot of totally pointless extra work 
in order to make the program less robust (there's no direct way to delete the 
first block of a file, so you'd have to either copy from the back or shift 
the whole file back a block at a time and then truncate it).

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|"Is it too late to extricate myself|
| from this plot line?" |
|"Yes." -- Fluble   |
\-- (if (not (understand-this)) (go-to http://www.schemers.org)) ---/


pgpX29TkvNl7W.pgp
Description: PGP signature

Re: dh_movefiles, tar vs. mv

[Christoph Berg]

Re: Daniel Burrows in <[EMAIL PROTECTED]>
>   I'd imagine that it doesn't use mv for the same reason "install" doesn't; 
> ie, its purpose is to COPY files, not MOVE them.

As I understood it, the question was about moving stuff from
debian/tmp to debian/package. The stuff in debian/tmp should get
removed by the clean target anyway, so it doesn't hurt to move instead
of copying it.

>   Anyway, I thought you were joking in your first message, but it looks like 
> you're serious, so I'll answer this time.  If you're copying between files on 
> the same device, mv will use the rename(2) system call, which is an atomic 
> operation: ie, it doesn't "copy" the source files at all, it just links them 
> into the target directory.  If you're copying between devices, mv will 
> presumably copy the whole file before deleting it -- to actually remove a 
> file "block-by-block" would mean a whole lot of totally pointless extra work 
> in order to make the program less robust (there's no direct way to delete the 
> first block of a file, so you'd have to either copy from the back or shift 
> the whole file back a block at a time and then truncate it).

I doubt that any subdirs of a package build directory will ever be on
a different mount point than the directory itself ;-)

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: dh_movefiles, tar vs. mv

[Eric Dorland]

* Frank Küster ([EMAIL PROTECTED]) wrote:
> Eric Dorland <[EMAIL PROTECTED]> schrieb:
> 
> > * Frank Küster ([EMAIL PROTECTED]) wrote:
> >> Hi,
> >> 
> >> dh_movefiles internally uses tar to move file contents. I'm not sure why
> >> it doesn't use mv, is it because mv moves the file block-by-block and
> >> thus starts removing parts of the file before it is completely written,
> >> and hence is less save?
> >> 
> >> Anyway: If I am only going to move complete subdirectories from the temp
> >> tree to the package trees, is it in this case safe to use mv? It's much
> >> faster, and it would safe space (because dh_movefiles only removes the
> >> originals after the complete tarball has been extracted).
> >
> > Uhh, who cares? dh_movefiles has been superseded by dh_install. 
> 
> Well, fine. But the question remains: dh_install uses cp, not mv.  What
> is the problem with using mv?  And would it be safe to use mv if I only
> move complete directories?

Well one reason is sometimes (in multipackage builds) you want to have
the same file in 2 different packages. Also, the less side-effects
during build time the better for debugging. Eg since dh_install is
idempotent I can run my install target multiple times it will
work. That won't work with dh_movefiles.

OTOH if you have a massively big package, dh_install would be painful,
especially on some of the buildds. 

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: dh_movefiles, tar vs. mv

[Frank Küster]

Christoph Berg <[EMAIL PROTECTED]> schrieb:

> Re: Daniel Burrows in <[EMAIL PROTECTED]>
>>   I'd imagine that it doesn't use mv for the same reason "install" doesn't; 
>> ie, its purpose is to COPY files, not MOVE them.
>
> As I understood it, the question was about moving stuff from
> debian/tmp to debian/package. The stuff in debian/tmp should get
> removed by the clean target anyway, so it doesn't hurt to move instead
> of copying it.

Indeed. Especially when people tell me that dh_install is the successor
of dh_movefiles, which even has move in its name...

>>   Anyway, I thought you were joking in your first message, but it looks like 
>> you're serious, so I'll answer this time.  If you're copying between files 
>> on 
>> the same device, mv will use the rename(2) system call, which is an atomic 
>> operation: ie, it doesn't "copy" the source files at all, it just links them 
>> into the target directory.

That's why I want to use it. It would speed things up tremendously for
packages with lots of files that need to be separated into different
binary packages.

>> If you're copying between devices, mv will 
>> presumably copy the whole file before deleting it -- to actually remove a 
>> file "block-by-block" would mean a whole lot of totally pointless extra work 
>> in order to make the program less robust (there's no direct way to delete 
>> the 
>> first block of a file, so you'd have to either copy from the back or shift 
>> the whole file back a block at a time and then truncate it).
>
> I doubt that any subdirs of a package build directory will ever be on
> a different mount point than the directory itself ;-)

Correct. So, why not use mv?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: dh_movefiles, tar vs. mv

[Frank Küster]

Eric Dorland <[EMAIL PROTECTED]> wrote:

> * Frank Küster ([EMAIL PROTECTED]) wrote:
>> 
>> Well, fine. But the question remains: dh_install uses cp, not mv.  What
>> is the problem with using mv?  And would it be safe to use mv if I only
>> move complete directories?
>
> Well one reason is sometimes (in multipackage builds) you want to have
> the same file in 2 different packages. 

Well, then I don't use mv. Note that I didn't request that dh_install
use mv from now on (although an option to do this might be a nice
idea). What I asked is whether there are any real reasons why I
shouldn't do it. If dh_install doesn't do it this way, I can still do it
manually. 

> Also, the less side-effects
> during build time the better for debugging. Eg since dh_install is
> idempotent I can run my install target multiple times it will
> work. That won't work with dh_movefiles.

Well, that's of course a nice thing to have. However, I think in my case
its value is limited, since there is lot of other code during install
time, like moving things in the installed trees, moving and symlinking,
and especially removing some files completely. I tried to make it
idempotent, but that seemed to be a very hard task, and I gave up.

> OTOH if you have a massively big package, dh_install would be painful,
> especially on some of the buildds. 

Yes, that's why I'm asking. Well, it's mainly about an architecture: all
package, but its painful for *my* machine...

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Tips wanted for debugging and testing Debian

[Nico Golde]

Hello Sascha,

* Sascha Berkenkamp <[EMAIL PROTECTED]> [2005-02-25 13:45]:
> I want to help the debian team and I also read  debian.org/devel ! So I
> think I would like to help testing and debugging the debian system in
> order to help to fix some bugs in some programs or debian sepcific
> stuff. I'm not sure if I'm able to do this with mit taks but I'll try
> and learn. 

[...] 
The best thing you can to to test is (as we told you on the
mutt-ng mailinglist yesterday) to use a system. If you want
to test bug reports look after software you use and try to
reproduce them.
If you are able write a patch.
Regards Nico

-- 
Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF
http://www.ngolde.de | mutt-ng.berlios.de | grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpzYNmEYQWz5.pgp
Description: PGP signature

Re: dh_movefiles, tar vs. mv

[GOMBAS Gabor]

On Fri, Feb 25, 2005 at 01:14:00PM -0500, Daniel Burrows wrote:

>   Anyway, I thought you were joking in your first message, but it looks like 
> you're serious, so I'll answer this time.  If you're copying between files on 
> the same device, mv will use the rename(2) system call, which is an atomic 
> operation:

Well, if we are nitpicking, then rename(2) is atomic only in the sense
that after it returns, you can either access the old name (if rename
failed) or the new name (if it succeeded) (modulo of course journaling,
disk write cache, yadda yadda if you want to extend the atomicity over a
crash).

_But_ it is not neccessarily atomic wrt. other operations, especially
getdents(2). So it is equally possible that a readdir(3) during the
rename(2) returns the old name, the new name, both or neither, depending
on file system implementation and how the parent directory(/ies) is(/are)
actually allocated on the disk. Not very important for dh_install, though
:-)

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dh_movefiles, tar vs. mv

[GOMBAS Gabor]

On Fri, Feb 25, 2005 at 07:54:27PM +0100, Frank Küster wrote:

> Correct. So, why not use mv?

Add a new "--move" flag to dh_installfiles, come up with some exact
numbers showing the build time/disk usage savings for your favorite Big
Package (hard numbers usually very helpful for promoting new features),
and send the numbers together with the patch to the debhelper maintainer. 

Someone already mentioned that a complex package might want to install
the same file to multiple different locations, so making this the
default is probably not feasible.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dh_movefiles, tar vs. mv

[Colin Watson]

On Fri, Feb 25, 2005 at 07:54:27PM +0100, Frank Küster wrote:
> Christoph Berg <[EMAIL PROTECTED]> schrieb:
> > Re: Daniel Burrows in <[EMAIL PROTECTED]>
> >>   I'd imagine that it doesn't use mv for the same reason "install" 
> >> doesn't; 
> >> ie, its purpose is to COPY files, not MOVE them.
> >
> > As I understood it, the question was about moving stuff from
> > debian/tmp to debian/package. The stuff in debian/tmp should get
> > removed by the clean target anyway, so it doesn't hurt to move instead
> > of copying it.
> 
> Indeed. Especially when people tell me that dh_install is the successor
> of dh_movefiles, which even has move in its name...

debhelper (4.0.0) unstable; urgency=low

  * dh_movefiles has long been a sore point in debhelper. Inherited
from debstd, its interface and implementation suck, and I have maintained
it while never really deigning to use it. Now there is a remplacment:
dh_install, which ...
- copies files, doesn't move them. Closes: #75360, #82649

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dh_movefiles, tar vs. mv

[Oliver Kurth]

On Fri, 2005-02-25 at 20:25 +0100, GOMBAS Gabor wrote:
> On Fri, Feb 25, 2005 at 07:54:27PM +0100, Frank Küster wrote:
> 
> > Correct. So, why not use mv?
> 
> Add a new "--move" flag to dh_installfiles, come up with some exact
> numbers showing the build time/disk usage savings for your favorite Big
> Package (hard numbers usually very helpful for promoting new features),
> and send the numbers together with the patch to the debhelper maintainer. 
> 
> Someone already mentioned that a complex package might want to install
> the same file to multiple different locations, so making this the
> default is probably not feasible.

How about hard linking with ln instead? You would have the best of both
approaches: it is fast, and still possible to have the same file in
multiple packages.

Greetings,
Oliver



signature.asc
Description: This is a digitally signed message part

Re: dh_movefiles, tar vs. mv

[Frank Küster]

Colin Watson <[EMAIL PROTECTED]> schrieb:

> On Fri, Feb 25, 2005 at 07:54:27PM +0100, Frank Küster wrote:
>> Christoph Berg <[EMAIL PROTECTED]> schrieb:
>> > Re: Daniel Burrows in <[EMAIL PROTECTED]>
>> >>   I'd imagine that it doesn't use mv for the same reason "install" 
>> >> doesn't; 
>> >> ie, its purpose is to COPY files, not MOVE them.
>> >
>> > As I understood it, the question was about moving stuff from
>> > debian/tmp to debian/package. The stuff in debian/tmp should get
>> > removed by the clean target anyway, so it doesn't hurt to move instead
>> > of copying it.
>> 
>> Indeed. Especially when people tell me that dh_install is the successor
>> of dh_movefiles, which even has move in its name...
>
> debhelper (4.0.0) unstable; urgency=low
>
>   * dh_movefiles has long been a sore point in debhelper. Inherited
> from debstd, its interface and implementation suck, and I have maintained
> it while never really deigning to use it. Now there is a remplacment:
> dh_install, which ...
> - copies files, doesn't move them. Closes: #75360, #82649

What do you want to say with this?  Do you want to tell me that using mv
is bad?  If yes, why?  It's not in the bug reports.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: dh_movefiles, tar vs. mv

[Joey Hess]

Frank Küster wrote:
> Colin Watson <[EMAIL PROTECTED]> schrieb:
> 
> > On Fri, Feb 25, 2005 at 07:54:27PM +0100, Frank Küster wrote:
> >> Christoph Berg <[EMAIL PROTECTED]> schrieb:
> >> > Re: Daniel Burrows in <[EMAIL PROTECTED]>
> >> >>   I'd imagine that it doesn't use mv for the same reason "install" 
> >> >> doesn't; 
> >> >> ie, its purpose is to COPY files, not MOVE them.
> >> >
> >> > As I understood it, the question was about moving stuff from
> >> > debian/tmp to debian/package. The stuff in debian/tmp should get
> >> > removed by the clean target anyway, so it doesn't hurt to move instead
> >> > of copying it.
> >> 
> >> Indeed. Especially when people tell me that dh_install is the successor
> >> of dh_movefiles, which even has move in its name...
> >
> > debhelper (4.0.0) unstable; urgency=low
> >
> >   * dh_movefiles has long been a sore point in debhelper. Inherited
> > from debstd, its interface and implementation suck, and I have 
> > maintained
> > it while never really deigning to use it. Now there is a remplacment:
> > dh_install, which ...
> > - copies files, doesn't move them. Closes: #75360, #82649
> 
> What do you want to say with this?  Do you want to tell me that using mv
> is bad?  If yes, why?  It's not in the bug reports.

The changelog entry explains why dh_movefiles is implemented using tar.
The bug reports explain a significant problem with using mv: loss of
idempotency.

-- 
see shy jo


signature.asc
Description: Digital signature

dpkg: config file `foo' is a circular link

[Frank Küster]

Hi,

the third thread I start or continue today. Should go home instead.

On a not-yet uploaded package, when upgrading from the version in sid, I
get these error messages:

Setting up tetex-base (3.0-0.4) ...
dpkg: tetex-base: warning - config file `/etc/texmf/platex/language.dat' is a 
circular link
 (= `/etc/texmf/platex/language.dat')
dpkg: tetex-base: warning - config file `/etc/texmf/platex/hyphen.cfg' is a 
circular link
 (= `/etc/texmf/platex/hyphen.cfg')
dpkg: tetex-base: warning - config file `/etc/texmf/cyrplain/cyrtex.cfg' is a 
circular link
 (= `/etc/texmf/cyrplain/cyrtex.cfg')
Installing new version of config file /etc/texmf/latex/texsys.cfg ...

I have no idea how this could come, and google isn't helpful, either.
When I install from purged state, everything is as it should, it happens
only upon upgrade.  The old version of the package has only ordinary
files there:

$ ll /etc/texmf/platex/
total 16
-rw-r--r--  1 root root 4447 2003-01-30 12:10 hyphen.cfg
-rw-r--r--  1 root root 2113 2003-01-30 12:10 language.dat
-rw-r--r--  1 root root   81 2001-06-05 20:18 platex.ini

The same ist still true at the end of preinst, where I put a

ls -l /etc/texmf/platex >&2 || true

And the deb of the new version also contains only ordinary files:

# ar x /var/cache/apt/archives/tetex-base_3.0-0.4_all.deb 
# tar -xzf data.tar.gz 
# ls -l etc/texmf/platex/
total 12
-rw-r--r--  1 root root 4447 Dec 21 01:52 hyphen.cfg
-rw-r--r--  1 root root 2113 Dec 21 01:52 language.dat
# 

When I try to debug this by using dpkg --debug=22, I get lots of useless
(?)  information, plus a segfault when it tries to run maintainer
scripts (once in the old package's postrm, once in the new packages
preinst, I don't see a pattern yet).

The debugging output contains:

D20: process_archive conffile `/etc/texmf/platex/language.dat' 
package=tetex-base same hash=8e3525fe40ae72bb08f673b3
0eca1236
D20: process_archive conffile `/etc/texmf/platex/hyphen.cfg' 
package=tetex-base same hash=1199fd3dbe752e8eedaca7a5a6
df9258
D20: process_archive conffile `/etc/texmf/cyrplain/cyrtex.cfg' 
package=tetex-base same hash=843bd70324caf63d72269dd3
afdd8eb1
[...]
D20: conffderef in=`etc/texmf/platex/language.dat' 
result=`/etc/texmf/platex/language.dat'
D20: tarobject fnnf_new_conff deref=`etc/texmf/platex/language.dat'
D20: conffderef in=`etc/texmf/platex/hyphen.cfg' 
result=`/etc/texmf/platex/hyphen.cfg'
D20: tarobject fnnf_new_conff deref=`etc/texmf/platex/hyphen.cfg'
D20: conffderef in=`etc/texmf/cyrplain/cyrtex.cfg' 
result=`/etc/texmf/cyrplain/cyrtex.cfg'
D20: tarobject fnnf_new_conff deref=`etc/texmf/cyrplain/cyrtex.cfg'

This does not look different from the preceding or following files, but
note that the three files are processed one after the other, nothing in
between. 

The segfault then is:

D02: fork/exec /var/lib/dpkg/info/tetex-base.postrm (dpkg: error processing 
/var/cache/apt/archives/tetex-base_3.0-0
.4_all.deb (--unpack):
 dpkg: warning - old post-removal script killed by signal (Segmentation fault)

D02: fork/exec /var/lib/dpkg/info/tetex-base.preinst (dpkg: error while 
cleaning up:
 subprocess pre-installation script killed by signal (Segmentation fault)

But I don't believe that this is the real problem. /bin/sh generally
runs fine here, and those scripts contain a "set -x" as their first
command.


It's not the first time I get a segfault when trying to use dpkg's debug
options (and there are bug reports about that). But that doesn't help me
in finding out what is wrong in my package

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Any reason why I'm not CCed by bugs of my packages?

[Andreas Tille]

Hi,
I have an open bug against dict-wn
   ~> apt-cache show dict-wn | grep Maint
   Maintainer: Andreas Tille <[EMAIL PROTECTED]>
but got no mail notification about #296197 - just have seen it via
web interface.  Any idea what went wrong here.  (If I'm not absolutely
wrong this is not the first case for this package.)
Kind regards
  Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dh_movefiles, tar vs. mv

[Colin Watson]

On Fri, Feb 25, 2005 at 08:59:00PM +0100, Frank Küster wrote:
> Colin Watson <[EMAIL PROTECTED]> schrieb:
> > On Fri, Feb 25, 2005 at 07:54:27PM +0100, Frank Küster wrote:
> >> Christoph Berg <[EMAIL PROTECTED]> schrieb:
> >> > Re: Daniel Burrows in <[EMAIL PROTECTED]>
> >> >>   I'd imagine that it doesn't use mv for the same reason "install" 
> >> >> doesn't; 
> >> >> ie, its purpose is to COPY files, not MOVE them.
> >> >
> >> > As I understood it, the question was about moving stuff from
> >> > debian/tmp to debian/package. The stuff in debian/tmp should get
> >> > removed by the clean target anyway, so it doesn't hurt to move instead
> >> > of copying it.
> >> 
> >> Indeed. Especially when people tell me that dh_install is the successor
> >> of dh_movefiles, which even has move in its name...
> >
> > debhelper (4.0.0) unstable; urgency=low
> >
> >   * dh_movefiles has long been a sore point in debhelper. Inherited
> > from debstd, its interface and implementation suck, and I have 
> > maintained
> > it while never really deigning to use it. Now there is a remplacment:
> > dh_install, which ...
> > - copies files, doesn't move them. Closes: #75360, #82649
> 
> What do you want to say with this?  Do you want to tell me that using mv
> is bad?  If yes, why?  It's not in the bug reports.

My point is that half the reason why dh_install was introduced instead
of dh_movefiles is to copy files, not move them, and it seems odd that
now there's a thread asking how to get dh_install to move files. If you
want to move files, don't use dh_install.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Any reason why I'm not CCed by bugs of my packages?

[Steve Langasek]

On Fri, Feb 25, 2005 at 09:31:00PM +0100, Andreas Tille wrote:
> I have an open bug against dict-wn

>~> apt-cache show dict-wn | grep Maint
>Maintainer: Andreas Tille <[EMAIL PROTECTED]>

> but got no mail notification about #296197 - just have seen it via
> web interface.  Any idea what went wrong here.  (If I'm not absolutely
> wrong this is not the first case for this package.)

Perhaps there was some spam filter in your pipeline that tried to do natural
language parsing of the text, and exploded the same way my brain did upon
reading that message?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: list of packages on private website

[Goswin von Brederlow]

Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes:

> Hello.
>
> That's rather OT, but I wanted to target my question at developers, cause
> I suppose that's the only group which would be able to help me.
>
> I would like to put on my homepage list of packages that I maintain. 
> I suppose that the easiest way would be to fetch this information from 
> ldap database. I don't want to reinvent the wheel, and I'm sure some of 
> you have already similar lists on your websites.
>
> I'm also quite sure you want to share your code with others, don't you? ;)
>
> So if someone could announce that he/she has some code, and in turn makes 
> my life easier, then it's time to do that.
>
> The perfect solution would be some script which would download these
> information once a week and build static pages from it. This way
> I wouldn't overload database.
>
> So... who wants to share his code? ;)

How about:

http://people.debian.org/~igloo/status.php?email=brederlo%40informatik.uni-tuebingen.de&packages=&arches=

> regards
> fEnIo

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Automatic building of (parts of) the archive

[Goswin von Brederlow]

Frank Küster <[EMAIL PROTECTED]> writes:

> Hi,
>
> in order to test whether packages that build-depend on tetex can still
> be built with the upcoming version 3.0, I would like to automatically
> build as many of these packages.  I know where I can read about setting
> up a buildd, but two questions remain:
>
> - are there any scripts that hand over the next package in a list after
>   one build has finished (without setting up a copy of wanna-build...)?

You can preseed the local queue with packages just fine. No need for
wanna-build.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Automatic building of (parts of) the archive

[David Schmitt]

On Friday 25 February 2005 18:43, Frank Küster wrote:
> in order to test whether packages that build-depend on tetex can still
> be built with the upcoming version 3.0, I would like to automatically
> build as many of these packages.

Take a look at pbuilder. There are people recompiling the whole of debian 
regularily with pbuilder.

Regards, David

-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Any reason why I'm not CCed by bugs of my packages?

[Andreas Tille]

On Fri, 25 Feb 2005, Steve Langasek wrote:
   ~> apt-cache show dict-wn | grep Maint
   Maintainer: Andreas Tille <[EMAIL PROTECTED]>

but got no mail notification about #296197 - just have seen it via
web interface.  Any idea what went wrong here.  (If I'm not absolutely
wrong this is not the first case for this package.)
Perhaps there was some spam filter in your pipeline that tried to do natural
language parsing of the text, and exploded the same way my brain did upon
reading that message?
Interesting idea but I doubt that.  I also did not got my response
and if I remember right in the past this also happened for another
bug of the same package.  I do not regard this as a hard issue but
I wanted to make sure that this would not happen for others with more
important packages.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Any reason why I'm not CCed by bugs of my packages?

[John Hasler]

Andreas Tille writes:
> but got no mail notification about #296197 - just have seen it via web
> interface.  Any idea what went wrong here.  (If I'm not absolutely wrong
> this is not the first case for this package.)

I have no idea what causes it but the same thing happens to me a couple of
times a year.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Updating config files: permissions!?

[Torsten Landschoff]

Hi *, 

During upgrades the slapd package (for example) has to do some
adjustments on config files (it asks the user for permission of course). 

Problem: How do I make sure the new config files have the same
permissions!? Currently I do

chmod --reference=OLD NEW
chown --reference=OLD NEW
mv NEW OLD

but this will break with ACLs. And what happens with SELinux!? Can't
find anything in debian-policy about it, shouldn't we define that
handling?

Greetings

Torsten


signature.asc
Description: Digital signature

procmail and Large File Support

[Santiago Vila]

Hello.

I have several reports saying procmail does not support mbox folders
larger than 2GB. Questions:

* Am I right to think that adding -D_FILE_OFFSET_BITS=64 to CFLAGS
should be enough to fix this, as explained by this URL?:

http://www.suse.de/~aj/linux_lfs.html

The version in experimental has -D_FILE_OFFSET_BITS=64, and it works
on files larger than 2GB, but I have only tested it on the i386
architecture.

* Would the release managers approve this change for sarge?

Thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Any reason why I'm not CCed by bugs of my packages?

[Steve Greenland]

On 25-Feb-05, 16:43 (CST), John Hasler <[EMAIL PROTECTED]> wrote: 
> Andreas Tille writes:
> > but got no mail notification about #296197 - just have seen it via web
> > interface.  Any idea what went wrong here.  (If I'm not absolutely wrong
> > this is not the first case for this package.)
> 
> I have no idea what causes it but the same thing happens to me a couple of
> times a year.

Ditto.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Package xxx has broken dep on yyy: normal?

[Dan Jacobson]

M> Dan Jacobson [12]wondered about the broken dependencies he notices
M> every now and then. Colin Watson [13]answered that this is the
M> problem that the testing distribution is intended to solve. Goswin
M> Brederlow [14]explained that this is caused by strictly versioned
M> dependencies to binary-all packages.

Well I like sid, but am not used to
 Package gpe-contacts has broken dep on libgpevtype0
  Try to Re-Instate gpe-contacts
lasting for days into weeks.
Goswin's post implied that such problems should only last a day or two.
How is it that such problems are allowed to persist for days into weeks?
Isn't there a feedback mechanism to prevent developers making the
archive "unstable" permanently unknowingly? A couple of days isn't so
bad, but apparently users often have to remind developers what mess apt-get
shows they have turned their dependencies into otherwise they are oblivious?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: procmail and Large File Support

[Steve Langasek]

Hi Santiago,

On Sat, Feb 26, 2005 at 12:53:40AM +0100, Santiago Vila wrote:
> I have several reports saying procmail does not support mbox folders
> larger than 2GB. Questions:

> * Am I right to think that adding -D_FILE_OFFSET_BITS=64 to CFLAGS
> should be enough to fix this, as explained by this URL?:

> http://www.suse.de/~aj/linux_lfs.html

> The version in experimental has -D_FILE_OFFSET_BITS=64, and it works
> on files larger than 2GB, but I have only tested it on the i386
> architecture.

Please use the value of $(getconf LFS_CFLAGS) instead; it appears (based on
past exim4 bug reports) that using -D_FILE_OFFSET_BITS=64 on natively 64-bit
systems such as alpha causes surprising breakage of some glibc APIs.

> * Would the release managers approve this change for sarge?

If this is the only change, yes.

Cheers,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Any reason why I'm not CCed by bugs of my packages?

[Marco d'Itri]

On Feb 25, John Hasler <[EMAIL PROTECTED]> wrote:

> I have no idea what causes it but the same thing happens to me a couple of
> times a year.
Me too. I think that it happens more often, but I probably get way more
bugs than you do.
And no, my spam filters do not silently discard mail, ever.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Package xxx has broken dep on yyy: normal?

[Steve Langasek]

On Sat, Feb 26, 2005 at 07:39:17AM +0800, Dan Jacobson wrote:
> M> Dan Jacobson [12]wondered about the broken dependencies he notices
> M> every now and then. Colin Watson [13]answered that this is the
> M> problem that the testing distribution is intended to solve. Goswin
> M> Brederlow [14]explained that this is caused by strictly versioned
> M> dependencies to binary-all packages.

> Well I like sid, but am not used to
>  Package gpe-contacts has broken dep on libgpevtype0
>   Try to Re-Instate gpe-contacts
> lasting for days into weeks.

Get used to it, it happens.  This is unstable, not testing; there are no
safeguards to ensure that *any* given package in unstable is installable at
all, and at any given moment there are lots of packages that are not
installable.  If you aren't willing to cope with this, then you do not "like
sid", you just refuse to understand that the issues you have a problem with
are fundamental to unstable and are fundamentally *avoided* by using
testing instead.

That said, any package that is uninstallable in testing for such a long
period of time almost certainly has an RC bug that should be filed.  In the
case of gpe-contacts, this is definitely so; the package currently in
unstable cannot be built using sources in the archive (it depends on a
library that currently awaits ftp-master NEW processing), so should not have
been uploaded to main.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: procmail and Large File Support

[Ron Johnson]

On Sat, 2005-02-26 at 00:53 +0100, Santiago Vila wrote:
> Hello.
> 
> I have several reports saying procmail does not support mbox folders
> larger than 2GB. Questions:

OT here, but WTF are people smoking, to have 2GB mbox files?

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

LUKE: Is Perl better than Python?
YODA: No... no... no. Quicker, easier, more seductive.
LUKE: But how will I know why Python is better than Perl?
YODA: You will know. When your code you try to read six months
from now.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

splitting a source package into 2 source packages

[sean finney]

hi,

i'm maintaining a source package that produces two binary packages.  however,
one of the packages is built from a seperately distributed (same author,
same website, but different tarball and versioning scheme) tarball.

so i'm thinking these two packages should be generated from their own
respective tarballs (and i'm not sure why they weren't in the first
place).  however, one thing that's not clear to me is whether or not the
new second source package will have to make it through the NEW queue.
if it does, this is a problem given that NEW seems to be stalled and the
previous version of the package will be totally broken when the other
is updated.

comments would be appreciated... thanks.

sean

-- 


signature.asc
Description: Digital signature