Re: Why does Ubuntu have all the ideas?

[Matthias Julius]

Jon Dowland <[EMAIL PROTECTED]> writes:

> Without further specifics, this is not a useful argument to
> have.  Assuming by "Ubuntu" you mean Ubuntu Breezy (i.e.
> stable as of 6 months ago), but what do you mean by
> "Debian"?  Sarge?  Sid today? Sid yesterday? Etch last week?
> If you've only looked at Sarge, say, then perhaps Debian
> *does* support the hardware you are talking about.

I am running a testing/unstable system myself, but I would not
recommend a beginner user to use anything but stable.  Things do go
wrong in testing and I would not expect a beginner to deal with things
like the x.org transition.

So when comparing distributions I would always compare stable
releases.  I don't think it makes sense to compare development
versions since they are not intended for end users.

Matthias


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

Re: Code of Conduct on the Debian mailinglists

[Matthias Julius]

John Goerzen <[EMAIL PROTECTED]> writes:

> I am on dozens of mailing lists.  There are thousands of participants on
> this list alone.  I subscribe to, and leave, mailing lists all the time.
> Why should a person with a personal preference expect me to shoulder the
> burden of maintaining a mental list of that, when it's within his power
> to express his preference in a way that mail readers understand
> automatically?

On Debian lists the desire for no Ccs is not a personal preference but
it is the default.  Only if you want a Cc you should say so.  This is
what the CoC says.  If you don't agree with that - change it.  But
don't just ignore it.

Decent MUAs can be configured to send followups to the list only and
just Do The Right Thing.

>
> The same goes for the Debian CoC.  I agree with Wouter on this.  The CoC
> is at odds with the desires expressed in the mail headers.

In my view a missing mail header doesn't express any desire.

>
> Reply-To has been around since at least RFC822 (1982), and the person
> that wants to avoid personal CCs could use it.  It is standard and it is
> widely supported.

There are people who distinguish between followups and replies.  There
Reply-To is not a perfect solution either.

>
> There are, of course, problems with it.  Mail-Followup-To is also a
> defacto standard (note that RFC is not the only way for a standard to
> occur; HTML, for instance, was a standard long before it got an RFC).
> Many mail clients do the right thing when they see it, and that is
> especially true here.
>
> If the person with the complaint had used this, he would have been
> fine.

My MUA sets MFT but I still get a number of Ccs.  Fact is that MFT is
not implemented in every MUA or is disabled by default.

Matthias


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

Re: Code of Conduct on the Debian mailinglists

[Matthias Julius]

Miles Bader <[EMAIL PROTECTED]> writes:

> "Joe Smith" <[EMAIL PROTECTED]> writes:
>> So I really wonder why mailing lists are so common.
>
> It sort of depends on what you're looking for.
>
> Some advantages of mailing lists:
>
>   * E-mail generally has a "wider reach" -- it gets past corporate
> firewalls, (my company has never allowed external nntp connections),
> works even on strange systems, etc.
>
>   * With email, you can use the same MUA you always use, with the
> features you're used to.  People are _used_ to email, know how to
> configure it.
>
>   * With a mailing list you get a private copy of every message, without
> having to figure out how to setup a nntp server.
>

  * A mailing list is easier to distribute with a slow
server/connection.  If a mail takes 3 minutes to show up in your
mailbox it doesn't matter.  If each news post takes 15 seconds to
load it gets annoying.

Matthias


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

Re: Code of Conduct on the Debian mailinglists

[Matthias Julius]

Norbert Tretkowski <[EMAIL PROTECTED]> writes:

> * Matthias Julius wrote:
> [Mail vs. News]
>> * A mailing list is easier to distribute with a slow
>>   server/connection. If a mail takes 3 minutes to show up in your
>>   mailbox it doesn't matter. If each news post takes 15 seconds to
>>   load it gets annoying.
>
> Programs like slrnpull and leafnode which supports offline reading
> exist since years.

Yes, but this doesn't mean everybody is using them.  And they require
extra setup for each user.  Not everybody wants to be bothered with
that.

Does anybody have an idea how much difference there would be in server
load for a NNTP server compared to the current Debian mailing list
setup?

Matthias


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

Re: Not able to build a package with pbuilder

[Matthias Julius]

Michael Rasmussen <[EMAIL PROTECTED]> writes:

> On 2006-08-17 01:53:59, Junichi Uekawa wrote:
>> 
>> It's the way diff/patch works.  They don't preserve execute
>> permissions.
>> 
> I have realised that and I am opting for Don Armstrong solution which  
> solves the matter. Thanks.

You could run autoconf from within rules and have configure be created
during build.

Matthias


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

Re: Running x86-64 debian inside i386 pbuilder on AMD64

[Matthias Julius]

Sander Marechal <[EMAIL PROTECTED]> writes:

> I am looking to create .deb's for x86-64. I have an AMD64 but run an
> i386 OS due to the lack of some 64-bit packages (like flash and
> what-not). I have pbuilder all set up to build packages for i386, but I
> wonder if it's possible to use it to create x86-64 packages as well.
> After all, I do have an AMD64 so I can run x86-64 packages.
>
> So, is it possible to bootstrap an x86-64 OS with pbuilder on an i386
> system running on an AMD64?

Yes, this should be possible (if you are running an amd64 kernel).  I
would try (not tested):

 pbuilder create --debootstrapopts --arch=amd64

Matthias


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

Re: Running x86-64 debian inside i386 pbuilder on AMD64

[Matthias Julius]

Sander Marechal <[EMAIL PROTECTED]> writes:

> Thanks. The kernel works but I loose the nvidia driver and with it XGL,
> so X crashes on startup (I have the XGL server replace the standard X
> server, not run on top of it).

Maybe you just need to rebuild the nVidia kernel modules?

Matthias


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

Re: anticipating the upstart migration

[Matthias Julius]

Eric Dorland <[EMAIL PROTECTED]> writes:

>> - If you set up the alternatives in preinst, then there is a time when
>>   the symlink exists but the pointed binary hasn't been unpacked yet ->
>>   unbootable system.
>> - If you set up the alternatives in postinst, there is a time when there
>>   is no /sbin/init at all -> unbootable system.
>
> The second case is only true if the init providing packages conflict
> with each other, which I don't think would necessarily be the case. 

It would also be true if the admin chooses to deinstall tho old
package and install the new package at the same time.

Matthias


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

Re: anticipating the upstart migration

[Matthias Julius]

Eric Dorland <[EMAIL PROTECTED]> writes:

> * Matthias Julius ([EMAIL PROTECTED]) wrote:
>> Eric Dorland <[EMAIL PROTECTED]> writes:
>> 
>> >> - If you set up the alternatives in preinst, then there is a time when
>> >>   the symlink exists but the pointed binary hasn't been unpacked yet ->
>> >>   unbootable system.
>> >> - If you set up the alternatives in postinst, there is a time when there
>> >>   is no /sbin/init at all -> unbootable system.
>> >
>> > The second case is only true if the init providing packages conflict
>> > with each other, which I don't think would necessarily be the case. 
>> 
>> It would also be true if the admin chooses to deinstall tho old
>> package and install the new package at the same time.
>
> Sure, but then they are explicitly taking that risk. 

Yes, but probably without being aware of it.

How do you tell them about it before the old init package is removed?

Matthias


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

Re: Will IceWeasel be based on a fork or on vanilla FireFox?

[Matthias Julius]

"Sam Morris" <[EMAIL PROTECTED]> writes:

> On Mon, 16 Oct 2006 11:43:51 +1000, Ben Finney wrote:
>
>> I think there will be a serious attempt at collaborating with the
>> Gnuzilla folks to try to resolve this confusion. Meanwhile, we're
>> trying to get the existing Firefox into Debian as free software.
>
> Surely such an attempt can only end in one of two outcomes: they rename,
> or we rename. Since they used the name first, I think it is only polite
> that we choose to rename; therefore why not pick a new name at the start
> without having to drag Firefox users through *another* pointless name
> transition?

The third possibility is merge.  Are this actually different projects?

Matthias


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

Bug#394042: ITP: dnshistory -- Translating and storing of IP addresses from log files

[Matthias Julius]

Package: wnpp
Severity: wishlist
Owner: Matthias Julius <[EMAIL PROTECTED]>


* Package name: dnshistory
  Version : 1.2
  Upstream Author : Stephen McInerney <[EMAIL PROTECTED]>
* URL : http://www.stedee.id.au/dnshistory/
* License : GPL
  Programming Lang: C
  Description : Translating and storing of IP addresses from log files

 Provide a means for storing a history of DNS/Name changes for the IP Addresses
 extracted from web log files. The major target being that multiple analyses of
 older log files do not require re-lookups of IP Address to FQDNs, and 
additionally
 maintain the accuracy of the lookup as it was then and not as it is now.

Matthias


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

Re: ethstatus: no upstream, RFA or removal?

[Matthias Julius]

Christoph Haas <[EMAIL PROTECTED]> writes:

> I'm unhappy with the missing upstream situation. I could also wait for a 
> volunteer to maintain both the software and the maintainer.
      ^^

What kind of maintenance do *you* need?

Matthias


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

Re: Question regarding maintainer email

[Matthias Julius]

Rafael Laboissiere <[EMAIL PROTECTED]> writes:

> As regards bouncing, we recognize that receiving an automated message is not
> the suitable behavior.  On the other hand, not receiving anything and not
> seeing the message in the list archives is even worse.  We decided then to
> suppress bouncing and also to be very reactive as regards the moderation.
> We have two moderators for each list and we try to insure that one of them,
> at least, will always be available for prompt moderation. As a courtesy to
> bug reporters, when we accept messages we systematically add the sender to
> the list of people allowed to post.

Since all bug reports come via bugs.debian.org can't you just let in
all messages that come through b.d.o?

Matthias


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

Re: Bug mass filling

[Matthias Julius]

Gabor Gombas <[EMAIL PROTECTED]> writes:

> How about instead of speaking about POSIX, policy should just list the
> shells that are officially supported as /bin/sh? There is no need
> listing every shell, just a representative subset: bash (obviously),
> dash (it's popular) and an other "minimalistic" shell (posh?) to prevent
> allowing everything & the kitchen sink if dash starts to rapidly acquire
> new features.

You could say the script _should_ be POSIX compliant and _must_ work
with bash, dash, ash...

Matthias


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

Re: On including 64-bit libs in 32-bit packages (see #344104)

[Matthias Julius]

Matthew Garrett <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>> "Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes:
>>> Is it possible to make 64bit kernels available?
>> 
>> Sarge does have them and the BTS has a patch for linux-2.6 to enable
>> them again. Now go and hit the kernel team till they apply the
>> patch. :)
>
> Bear in mind that the 64-bit kernel doesn't offer all the functionality 
> that the 32-bit one does. vm86 is the most obvious thing missing.

Don't install it if you don't need it.

Matthias


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

Re: Getting package build dependencies

[Matthias Julius]

Ross Boylan <[EMAIL PROTECTED]> writes:

> I am interested in getting build-dependencies for a source package on
> a system using aptitude.  In the past I've used apt-get build-dep, but
> that was on systems managed with apt-get.  I think aptitude won't know
> about apt-get's selections, and may toss the packages at the first
> chance (or perhaps get confused in some other way).
>
> Is this analysis correct?

Not completely.  When you install a package with apt-get (or dselect
or dpkg -i) the package will not be marked automatic in aptitude.
Thus aptitude will never automatically remove it.

So the real problem is to find and get rid of the build-depends when
you don't need them anymore.

I think it would be great if aptitude would learn about source
packages.  One could introduce a new flag ("S" maybe) that would cause
all build-depends to be installed automatically.  But of course this
would slow down aptitude update even more since it would have to
process the Sources files.

Matthias


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

Re: First call for vote on immediate vote under section 4.2.2

[Matthias Julius]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> I think that is an artifact of any mail sent to d-d-a, as a 
> Mail-Followup-To: debian-devel@lists.debian.org
>  header is automatically added for every mail sent there.

Even for mail that already has a M-F-T header?

Matthias


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

Re: Downgrading the priority of nfs-utils

[Matthias Julius]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> And I'm not sure that you are right with your majority claim. A lot of
> larger installations use nfs and they quickly add up to a lot of
> systems rivaling the rest of the user base in numbers.

But, I am not sure whether you can count them all as individual
installations as many of those probably get installed on one system
and then copied to another. And they are managed by only a few admins.

I would guess that most people who install a linux system don't need
NFS.

And actually, NFS us not required to run Debian.  Do I don't think it
needs to be in the default installation even if 70% of the users will
use it. IMHO

Matthias


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

Re: Downgrading the priority of nfs-utils

[Matthias Julius]

Anthony DeRobertis <[EMAIL PROTECTED]> writes:

> I think you've misunderstood the purpose of the default installation.

That might be.

> It's not the bare minimum to make the system work (that's Essential:
> yes). It's the standard stuff that everyone expects to be on a UNIX
> system, including things like a working c & c++ compiler, etc. 70% of
> users using something is, IMO, a very strong argument for it to be
> installed by default.

I don't have a UNIX background.  So I don't know what everyone expects
to be on a UNIX system.

>
> (Remember: installed by default does not mean you have to install it. It
> just means if you don't manually select packages, it will be installed).

This in practice means almost the same.  If it is selected by default
only very few users will de-select it.  On the other hand, if someone
needs it it's easy to install.

Generally I am in favor of the default install beeing really minimal
(only essential packages) and let the user decide which packages he
wants.

Matthias


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

Re: Downgrading the priority of nfs-utils

[Matthias Julius]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Wed, Nov 08, 2006 at 11:50:09AM -0500, Matthias Julius wrote:
>
> Then perhaps you shouldn't be changing a winning team? ;-)

Who are you referring to?

>> This in practice means almost the same.  If it is selected by default
>> only very few users will de-select it.
>
> Wrong.

Well, I should have worded that differently.  The above is a bit too
absolute.  I guess, it all depends on the demographics of the Debian
users.

>
>> On the other hand, if someone needs it it's easy to install.
>
> If you don't need it, it's also easy to remove.

Of course.  If you know it is installed and that you don't need it.

> In other words, it doesn't have to be essential for the system to work
> in order to be installed by default. The ability to mount
> NFS-filesystems most certainly is part of the expectation of an
> experienced Unix person; thus, it should be part of the set of
> "important" packages and should be installed by default.
>
> I see no reason to change that; the definitions in policy are sound this
> way.

Well, Idon't want to argue with the policy.  It is certainly not
unreasonable as it is.

Matthias


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

Re: sarge->etch upgrade: plenty of locales errors.

[Matthias Julius]

martin f krafft <[EMAIL PROTECTED]> writes:

> LANGUAGE=en_CH:en_US:en_GB:en
   ^

There is a Swiss English?  I didn't know that.

Matthias


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

Re: Why not scan for unmaintained packages and orphan them?

[Matthias Julius]

Sune Vuorela <[EMAIL PROTECTED]> writes:

>  - but having 20 importaint bugs in one package and 1 wishlist in
>another package -- in my world the 20 importaint bugs gets higher
>priority - even if it takes a half year to get to the wishlist
>without much commenting.

I don't think much commenting was asked for.  Just an aknowledgement
and maybe a short explanation why it is very low on the priority list
might be enough.  A bug report that is sitting in the BTS for half a
year without any sign that the maintainer has even seen it is very
frustrating for the reporter, IMHO.

Matthias


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

Re: Why not scan for unmaintained packages and orphan them?

[Matthias Julius]

Russ Allbery <[EMAIL PROTECTED]> writes:

> There are a fair number of lintian wishlist bugs in that category.  I
> suppose I could send a form letter in response to each one of them, but
> I'm not sure how useful that really is.  I try to get to wishlist bugs for
> new checks when I have a chance, with the probability of inclusion raised
> significantly (but not to 100%) by having a patch attached to the bug.

I understand that replying to every bug requires some extra effort and
I don't necessarily want to make it a must.  But a response like "I
have seen your report.  Unfortunately I don't have the time right now
to take care of it.  If you send a patch I will consider it." is a
nice gesture to the reporter.

I have started doing some l10n work about a month ago.  Some of the
bugs I filed have not seen any reaction from the maintainer.  While
that is not yet surprising I came across a number of l10n bugs
providing translations that are half a year old or older.  This is
frustrating to the translator to see his work collecting dust in the
BTS for such a long time.

And those bugs are easy and straight forward to fix and don't require
much thinking.

Matthias


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

Re: [edos-wp2] KDE and Gnome panel applets showing percentage of broken packages

[Matthias Julius]

Berke Durak <[EMAIL PROTECTED]> writes:

> 
>   
> iframe { border-style: none; width: 140px; height: 500px }
> div.weather { float: right; width: 100px; height: 200px; margin-right: 
> 30px }
>   
>   http://brion.inria.fr/anla/weather_status";>
> Your rusty browser does not support IFRAMEs.
>   
> 

This code has some flaws. 

- the style element may only appear within the head element and not
  within body

- the style element has a required attribute "type"
  (e.g. type="text/css")

- the iframe element is not available in the "strict" variants of
  (X)HTML and probably won't be in future versions of SHTML

If using iframe one could write:


  http://brion.inria.fr/anla/weather_status";>
Your rusty browser does not support IFRAMEs.
  


For "strict" HTML one could use the object element.

What is the reason the iframe is specified larger than the enclosing div?

Matthias


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

Re: Why not scan for unmaintained packages and orphan them?

[Matthias Julius]

Mark Brown <[EMAIL PROTECTED]> writes:

> I don't see how forcing people to reply to bugs helps here.  What's
> really needed is to convince maintainers to respond promptly and
> constructively to bug reports.  That's a much harder problem, and much
> harder to automate.

That is exactly what I meant.

Matthias


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

Re: db.debian.org (and related infrastructure) updates

[Matthias Julius]

Santiago Vila <[EMAIL PROTECTED]> writes:

> Moreover, if you send a message using a real smtp server, and its IP
> is listed in a DNSBL I use, you will receive a message from
> mailer-daemon saying so. This may and will surely happen, hopefully
> not often, but IMHO it's better than the message arriving to a spam
> folder which is so big that it will never be read.

Are you saying, that your server is sending a notification mail to the
>From address of mails that have been classified as spam?

I think people whose email addresses have been abused by spammers
really appreciate those messages.

Nowadays a large percentage of SMTP traffic on the internet is spam.
I wonder how much of the rest are those notification mails, bounces
and so on caused by spam.

Matthias


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

Re: db.debian.org (and related infrastructure) updates

[Matthias Julius]

Santiago Vila <[EMAIL PROTECTED]> writes:

> If your SMTP server is listed in a DNSBL which I told db.debian.org
> to use for my debian.org email and you try to send me a message,
> then master will say "I don't accept this message" to your SMTP
> server, and your SMTP server, in turn, will send you the usual
> mailer-daemon message saying "Undelivered Mail Returned to Sender".

This sounds much better.  I was just thinking of occasional emails I
get saying: "Your email sent to 
was classified as spam. ..."

>
> I was comparing the previous scenario with the current one. The risk
> of missing an email because of it being lost inside a very big spam
> folder is now very low. This is one of the reasons rejecting a lot of
> email at SMTP time and filtering the rest (what we can do now) is
> usually better than not rejecting anything at all and trying to "filter"
> everything afterwards.

I agree.

Matthias


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

Re: etch's upgrades during life cycle

[Matthias Julius]

Luis Matos <[EMAIL PROTECTED]> writes:

> Qui, 2007-01-04 às 11:10 +, Dominic Hargreaves escreveu:
>> 
>> backports.org is, to my mind, a perfect solution to this problem; it
>> allows you to selectively upgrade your favourite/important packages that
>> you need, whilst retaining the stable base on which to run them.
>> 
>
> here i agree that backports.org is the way out and that should be
> official so maintainers could upload backports in a easier and have a
> better security support. (and gives users other view for it if
> backports.org is indeed in debian and recommended by debian.)

Maybe backports.org is too much and changing to frequently to provide
security support for and to be really stable.

There could be another archive called updates.debian.org where
selected packages go in in coordination with the security and stable
release teams.

Matthias

Re: etch's upgrades during life cycle

[Matthias Julius]

Luis Matos <[EMAIL PROTECTED]> writes:

>> 
>> There could be another archive called updates.debian.org where
>> selected packages go in in coordination with the security and stable
>> release teams.
> that would be nicier ... but that's a bit of volatile's purpose.
> Although it is not very used.

You are right.  It does sound a lot like volatile.  I didn't know much
abaut it up to now.  Maybe all that needs to be done is to make it
more official, have it supported by the security team and put a
commented out line for it into sources.list.

Matthias


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

Re: possible problem with ftp.us.debian.org

[Matthias Julius]

Marc Haber <[EMAIL PROTECTED]> writes:

> On Sun, 7 Jan 2007 08:40:17 -0700, "Wesley J. Landaker"
>>
>>Months; I've had to switch 10's of clients to use ftp.debian.org instead 
>>since I've been getting intermittant problems like this with 
>>ftp.us.debian.org since ~ October last year.
>
> That's why I have a local CNAME debian.debian.zugschlus.de which I try
> to have pointing to a working germany-based mirror most of the time.
> Saves me from updating all clients in case of a mirror failure.

If you have more than a few clients it might be a good idea to have
your own private mirror.  Then, if your upstream mirror has a
temporary problem your private one will be a little bit out of date,
but your clients won't notice.  And your clients will get a faster
response, too.

Regarding load on mirrors: How many clients do you need to put a
similar load on a mirror like a mirror sync?

Matthias


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

Re: Proposal for Lenny: Please avoid duplicated changelogs for binary packages sharing the same source package

[Matthias Julius]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> 2) multiarch has a problem with changelogs in library packages. It
> must be possible to insall libc6:i386 and libc6:amd64. If both contain
> /usr/share/doc/libc6/changelog then that gives a file conflict in
> dpkg. Having the changelog in libc6-common beautifully solves this
> problem and avoids having to special case this in dpkg.

There is one more catch to add here: The same library can be installed
in different versions for the different arches.  IMHO this makes it
impossible for them to really share the same file.

I think the possibly cleanest solution is to install the docs in
directories with an arch specific suffix, e.g. doc/libc6_i386 and
doc/libc6_amd64.  The debhelper scripts could do that for multiarch
packages.

But, what do you do with conflicting man pages?

How is multiarch coming along?

Matthias


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

Re: possible problem with ftp.us.debian.org

[Matthias Julius]

Marc Haber <[EMAIL PROTECTED]> writes:

> On Mon, 08 Jan 2007 08:37:28 -0500, Matthias Julius
> <[EMAIL PROTECTED]> wrote:
>>
>>If you have more than a few clients it might be a good idea to have
>>your own private mirror.  Then, if your upstream mirror has a
>>temporary problem your private one will be a little bit out of date,
>>but your clients won't notice.
>
> I don't think that is superior to my CNAME solution if the systems are
> distributed. Larger sites can have a squid with holding time for .deb
> files beefed up.

As long as your CNAME is pointing to a working mirror, yes.

>
>>And your clients will get a faster
>>response, too.
>
> Only if the mirror is in the local network, which means that all
> clients should be in the same LAN.

I agree, for distributed clients the benefit is very limited.

Matthias


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

Re: Proposal for Lenny: Please avoid duplicated changelogs for binary packages sharing the same source package

[Matthias Julius]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Matthias Julius <[EMAIL PROTECTED]> writes:
>
>> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>>
>>> 2) multiarch has a problem with changelogs in library packages. It
>>> must be possible to insall libc6:i386 and libc6:amd64. If both contain
>>> /usr/share/doc/libc6/changelog then that gives a file conflict in
>>> dpkg. Having the changelog in libc6-common beautifully solves this
>>> problem and avoids having to special case this in dpkg.
>>
>> There is one more catch to add here: The same library can be installed
>> in different versions for the different arches.  IMHO this makes it
>> impossible for them to really share the same file.
>
> Not neccessarily. I wouldn't really get upset if libc6 depends on
> libc-common (= source:version) and forces libc6:i386 and libc6:amd64
> to be the same version at all times.

There is nothing that guaranties that libc6 is on the same version on
all arches (at least in unstable).  If it is not your second choice
becomes uninstallable.  

Multiarch packages would need to be blocked from upgrading in the
archive until the new version is available on all arches that can run
on the same platform.

>
> You can't assume the i386 /usr/share/* files will work for the amd64
> package if you allow the versions to differ and even if versions are
> forced to match it would be complex to handle up/down-grades
> correctly. For /usr/share/doc we can hack around as that dir must be
> unimportant to the workings of a package. Not so for /usr/share/* in
> general.

Doesn't this problem already exist for packages that have a separated
-common or -data package?  What is worse in multiarch if the arches
are force to be on the same version?

>
>> How is multiarch coming along?
>
> In officialy Debian it is stuck with binutils missing a few lines
> patch from the BTS.

Is there hope that gets resolved after etch?

Matthias


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

Re: Your message to Pkg-ruby-extras-maintainers awaits moderator approval

[Matthias Julius]

Michelle Konzack <[EMAIL PROTECTED]> writes:

> Am 2007-01-08 10:26:50, schrieb Pierre Habouzit:
>>>   That becomes tiredsome. Once again, I really think that the list used
>> as a primary contact for packaging shall not be moderated. Alioth has
>> quite reasonable antispam measures, so that's really not needed.
>
> ACK
>
> I have tried to subscribe to several source packages
> on the BTS/PTS and have gotten the same messages...
>
> It very iritating if you want to watch a package and
> then you are subscribed to a Mailinglist on . 

You mix something up here.  Nobody is subscribed to any moderated list
when subscribing to a package or a bug.  In fact, the message Pierre
has quoted was a notice that his mail was held back because he is NOT
subscribed to that list.

You get those infamous notifications when you send a mail to
@packages.debian.org or to a bug of a package that has a
moderated list as maintainer.

Matthias


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

Re: How (not) to write copyright files - take two

[Matthias Julius]

Luca Capello <[EMAIL PROTECTED]> writes:

> [Debian Policy Manual]
>
>  12.5 Copyright information
>
>  Every package must be accompanied by a verbatim copy of its copyright
>  and distribution license in the file
>  /usr/share/doc/package/copyright. This file must neither be compressed
>  nor be a symbolic link.
>
>  [...]
>
>  Packages distributed under the UCB BSD license, the Artistic license,
>  the GNU GPL, and the GNU LGPL should refer to the files
>  /usr/share/common-licenses/BSD, /usr/share/common-licenses/Artistic,
>  /usr/share/common-licenses/GPL, and /usr/share/common-licenses/LGPL
>  respectively, rather than quoting them in the copyright file.

Now, Perl and a lot of Perl related packages are licensed under
GPLv1.  Shouldn't Debian provide the text for this one as well?

Matthias


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

Re: amd64 uploads

[Matthias Julius]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> I have a more detailed list sorted by popularity and annotated by the
> bug number or the dep-waits but that would have been much longer to
> post.

Can you put it online somewhere and post a link to it?

Matthias


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

Re: cleaning up lib*-dev packages?

[Matthias Julius]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Then I had the idea that I could just as well convert Sources files to
> create pseudo packages for sources that depend on all the
> Build-Depends. So I create a dummy deb without contents and converted
> the Sources file to have src-foobar as package name for foobar, the
> Build-Depends as Depends and the empty dummy deb as Filename
> entry. After that I could just do
>
> apt-get install src-foobar
>
> and it pulls in all the Build-Depends for foobar. The best thing is
> that, if the Build-Depends of a package change, the next apt-get
> update/dist-upgrade will pull in the new Build-Depends since the
> Sources file gets converted on each fresh donwload and the src-foobar
> package then gets updated.

I think a more elegant solution would be if aptitude had a command to
install build-depends.  It could attach a new flag to a package that
causes aptitude to treat build-depends just like depends of that
package.  This way aptitude would mark build-depends as automatically
installed and remove them if they are not needed anymore.

Matthias


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

Re: cleaning up lib*-dev packages?

[Matthias Julius]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Matthias Julius <[EMAIL PROTECTED]> writes:
>
>> I think a more elegant solution would be if aptitude had a command to
>> install build-depends.  It could attach a new flag to a package that
>> causes aptitude to treat build-depends just like depends of that
>> package.  This way aptitude would mark build-depends as automatically
>> installed and remove them if they are not needed anymore.
>>
>> Matthias
>
> That wouldn't work well with dpkg, apt-get, deborphan, debfoster.

True.  But, if it works with aptitude that's better than nothing.

>
> I would also think that aptitude uses /var/lib/dpkg/status for the
> list of installed packages and the build-depends would not show up
> there. Aptitude would need its own list of imaginaryinstalled sources
> to keep track of them.

I think aptitude uses /var/lib/apt/lists/*Packages to determine
dependencies.  How else would it know about them for packages that are
not installed.  It would need to consult *Sources to find out
build-depends.  This should not be too hard. 

>
> With pseudo packages you can run "dpkg --purge src-foobar" and the
> next time aptitude runs it would suggest cleaning up.
>
> I'm also thinking of actualy populating the source packages with the
> actual source. "apt-get install src-foo" would then install all the
> build-depends and put the source files into /usr/src. So if you want
> to work on a package you could do:
>
> apt-get install src-foobar
> dpkg-source -x /usr/src/foobar*.dsc
> cd foobar*/
> sensible-editor
> debuild
>
> But I'm not so sure how usefull that would actualy be.

I don't think you really want to duplicate all source packages.  You
could have a post-install script that actually gets the source.

Matthias


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

Re: cleaning up lib*-dev packages?

[Matthias Julius]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Matthias Julius <[EMAIL PROTECTED]> writes:
>
>> I think aptitude uses /var/lib/apt/lists/*Packages to determine
>> dependencies.  How else would it know about them for packages that are
>> not installed.  It would need to consult *Sources to find out
>> build-depends.  This should not be too hard. 
>
> That is not what I ment. When you select "install build-depends for
> foobar" in aptitude it would have to somehwere record "build-depends
> for foobar: manual" so it can keep all build-depends on automatic and
> not remove them too early.
>

Aptitude would need to keep that information at the same place it
keeps the automatic flag, probably /var/lib/aptitude/pkgstates?

> Hehe. No I wouldn't want to duplicate the source packages. The idea I
> have in mind is to trick apt into accepting the actual source
> files as debs (via the apt-get wrapper) and have the dpkg-deb wrapper
> present them to dpkg in the format of debs. The DEBIAN dir would get
> created on the fly and the source file itself wrapped in a tar file.
>
> It is a dirty hack but where else do we get to have some fun?

Let me know when it works.

Matthias


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

Re: binNMUs for arch:all packages too

[Matthias Julius]

Frank Küster  writes:

> The ${source:Version} thing is a point. However, I also see a need for
> such binNMUs, or rather a case where it would be helpful. 
>
> That's the case when a package Build-Depends on some package because it
> needs to incorporate code (or configuration settings or data or
> whatever) into it's arch:all binary packages. For example tex-common
> provides dh_installtex which writes code into the Build-Depending
> packages's maintainer scripts.  
>
> I'm not aware of any other debhelper-like scripts, but there may be
> some. Fixing a bug in cdbs (e.g. failing to make the necessary dh_foo
> calls) might also mean that some packages need to be rebuilt.

In general, fixing a bug in any of the Build-Depends of any package
that has caused the package to be built wrongly makes a rebuild
necessary - Arch:all or not.

How often has that happened for Arch:all packages?

Matthias


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: update on binary upload restrictions

[Matthias Julius]

Charles Plessy <[EMAIL PROTECTED]> writes:

> Le Mon, Jan 29, 2007 at 10:42:25AM +0100, Goswin von Brederlow a écrit :
>> Santiago Vila <[EMAIL PROTECTED]> writes:
>> 
>> > On Sun, 28 Jan 2007, Benjamin Seidenberg wrote:
>> >
>> >> If we do go to source-only uploads, could this problem be avoided by
>> >> having arm and other slow arches wait until at least one other arch
>> >> successfully builds the package?
>> >
>> > I think that would be a good idea anyway, even if we do not go to
>> > source-only uploads. There is no point in wasting expensive CPU cycles
>> > to build a package if it FTBFS on every architecture.
>> 
>> I would rather do the opposite. Stop building a package when it fails
>> on other archs. Thing about the (unlikely) situation that arm is
>> idle. Nothing to build. Now someone uploads foobar. Should we wait or
>> just try? If it works we saved time. If it fails only idleing is lost.
>
> Or how about having the package rejected before being queued if it is
> not buildable on a (p|cow)builder installed on a fast machine, for
> instance?

You could make the i386 buildds special (or whichever arch is the most
complete) and have it build a newly uploaded package first.  Only if
that succeeds throw the package at the other arches.

This would need overrides for packages that don't exist on i386.

Matthias

Re: Where did Bacula 1.38.11-7+b1 come from?

[Matthias Julius]

John Goerzen <[EMAIL PROTECTED]> writes:

> On Fri, Feb 23, 2007 at 12:13:07AM +0100, Wouter Verhelst wrote:
>> > binNMUs though.  Aren't buildds simply there to build the existing
>> > sources on other platforms?  Surely some human was involved here?
>> 
>> wanna-build and buildd have been modified a while back to be able to do
>> binNMU's. The only human involvement is when a given package is marked
>> in the database as 'requires a binNMU', and when the buildd admin later
>> signs the package, as usual.
>
> Would it be possible to record the name of the human that marked the
> package in debian/changelog?  That would be a big help, I think (and
> hopefully avoid a discussion on debian-devel next time it happens)

Since this is about a binNMU where the source package is not touched
and the changelog lives inside the source package how is that supposed
to be possible?

Adding to the changelog requires a new upload.

Matthias


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

Re: On maintainers not responding to bugs

[Matthias Julius]

Ben Finney <[EMAIL PROTECTED]> writes:

> If I receive automatic notification from the BTS that the maintainer
> has attached a "confirmed" tag to the bug, that is plenty of
> acknowledgement.

or "pending", "upstream", "wontfix", "help" or change in severity.
Any of those actions indicates that someone is dealing with the bug.
And the submitter (or anyone) can look that up in the BTS.  But, a
notification email to the submitter might be a good idea.

Matthias


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

Re: On maintainers not responding to bugs

[Matthias Julius]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> On Mon, Mar 05, 2007 at 05:35:43PM +, Jon Dowland wrote:
>
>   wow, I'm really amazed. For the KDE and Gnome teams (and I'm sure
> others did it as well) there was mails requesting help to triage bugs
> and so on (from january 2006). Reading this thread could let people
> believe that those teams neved did that, and always denied they needed
> help. Well, sorry if I don't like the sound of that, but I really don't
> because it's at the antipodes of the reality.

Reading this thread makes me think that people are not aware that
those teams have requested help.

>   Like every packaging team in debian, mailing the [EMAIL PROTECTED] or
> [EMAIL PROTECTED] depending on how old the team is. Usually that list
> is in the Maintainer or Uploaders field of the control file.
> #debian-$team is also a good place to look. Those things are _obvious_.

Do you expect potential helpers to search various list archives or
mail maintainers to ask whether they need help?  I would guess only
people who have a specific issue with a package they want to get fixed
would do that.

>> One way is the existing wnpp system.
>>  lists
>> packages which have RFH filed. This list is very short and
>> doesn't seem to include the examples which have been put
>> forward in this thread at all.
>> 
>> For such packages, where triage would be needed, would it
>> not make sense to file an RFH bug to that effect?
>
>   The mails I alluded to earlier (to seek for help) have seen (at least
> for the KDE guys, I'll let the Gnome guys tell you how it worked for
> them) 0 answer. My experience is that RFH bugs works well when Norbert
> put it on vim to ask for co-maitenance or such very interesting software
> to package. But when the job is to deal with KDE bugs, there is really
> less people eager to do the job.

What does it hurt to file a RFH bug?  At least it is a centralized
platform where potential helpers can find out about who need help.
And it is a logical place for that.  And the list is posted weekly on
-devel.

What it probably needs is a link from
 to make it more obvious for people
not yet familiar with Debian.

>
>   Again, I do not appreciate the latent criticism of the big teams to
> hide their understaff problem. It's blatantly bogus hence iritating,
> almost insulting.

Don't you wonder why it is perceived like that?

Matthias


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

Re: edit patches in dpkg configuration file dialog

[Matthias Julius]

sean finney <[EMAIL PROTECTED]> writes:

> On Mon, 2007-03-05 at 19:23 +0100, Nico Golde wrote:
>> 
>> The implementation was not really difficult, the patch file 
>> itself is 200 lines alltogether.
>
> not bad :) i have to admit i haven't looked at the patch.
>
>> > would be to see the differences between the new maintainer conffile and
>> > the previous version of the maintainer conffile.
>> > 
>> > to implement this, one would simply need to keep a copy of
>> > dpkg-installed conffiles in some directory hierarchy under /var/lib/dpkg
>> > and provide a new option to diff this old version against the
>> > newly-unpacked-but-not-installed version of the conffile.

Although this clutters up /etc they could be saved as *.dpkg-last or
so.  New packages' conffiles can be saved as *.dpkg-new just like dpkg
currently does if one chooses not to install the new file.  Before a
new version is installed *.dpkg-new would be renamed to *.dpkg-last.

>> I am not sure if I get your idea 100% correctly but what 
>> about the user changes if you just look at the old and the 
>> new maintainer version of the config file?
>
> this wouldn't be for merging or anything, simply seing what the cause of
> the prompt was in the first place.

Of course you need this for merging.  You need to make a diff between
the old and new maintainer versions and then you can apply the
resulting patch to the user's version of the conffile.  Any conflicts
then need to be resolved.

Matthias


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

Re: The GIMP plugins for refocussing blurred images

[Matthias Julius]

This question is better placed on [EMAIL PROTECTED]

So, I am crossposting it there

Bernd Zeimetz <[EMAIL PROTECTED]> writes:

> Hello,
>
> since I'm not only a geek but also a photographer and GIMP user I've
> decided to have a look at wnpp bug #398765 [1] and package the plugin
> [2]. While packaging gimp-refocus I came across the refocus-it plugin,
> which uses a different algorithm and also supports to refocus motion
> blur, so I've decided to package it, too [3]. It seems to be much
> slower, though - but it provides a command-line version which works
> totally independent of The GIMP, it only depends on libc6.
> I've commented and described the issues of  both plugins at the given
> urls, testing and comments would be very appreciated.
>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398765
> [2] http://bzed.de/debian/packages/gimp-refocus
> [3] http://bzed.de/debian/packages/gimp-refocus-it
>
> Thanks a lot,
>
> Bernd Zeimetz


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

Re: edit patches in dpkg configuration file dialog

[Matthias Julius]

Jean-Christophe Dubacq <[EMAIL PROTECTED]> writes:

> On Tue, Mar 06, 2007 at 08:53:00PM +0100, Alexander Schmehl wrote:
>> > Although this clutters up /etc they could be saved as *.dpkg-last or
>> > so.  New packages' conffiles can be saved as *.dpkg-new just like dpkg
>> > currently does if one chooses not to install the new file.  Before a
>> > new version is installed *.dpkg-new would be renamed to *.dpkg-last.
>> 
>> ... and they will probably deleted my many admins thinking they are not
>> needed.  I don't think you can count on leaving them in /etc and finding
>> them again.

Everyone is free to break his own system. ;-)

The consequence would be minimal.  dpkg would just fall back to the
current behavior.

>
> And why shouldn't they. If anything, this should belong to
> /var/lib/dpkg/

You are right.  This is the logical place.

Matthias


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

Re: On maintainers not responding to bugs

[Matthias Julius]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> On Tue, Mar 06, 2007 at 12:49:56PM -0500, Matthias Julius wrote:
>> Pierre Habouzit <[EMAIL PROTECTED]> writes:
>>
>> Do you expect potential helpers to search various list archives or
>> mail maintainers to ask whether they need help?  I would guess only
>
>   no I expect them to contact the teams, and entry points are obvious.
> Hiding behind the fact that entry points are not waved under their nose
> and that because of that they can't help is, well, Ubuesque.

It's a matter of how someone arrives at the point where he wants to
help.  If he wakes up one morning and thinks "I want to help the KDE
team" he will probably contact the KDE maintainers.  If he thinks
"Since 3 years I am using Debian it's time for me to contribute." he
might look in more generic places to find out who requests help.

>> 
>> What does it hurt to file a RFH bug?  At least it is a centralized
>> platform where potential helpers can find out about who need help.
>> And it is a logical place for that.  And the list is posted weekly on
>> -devel.
>
>   because that's not one, but 1500, and that would not be very useful to
> flood RFH that are often specific needs for technicals matters. Here
> it's manpower missing, RFH seems inapropriate to me.

Does a RFH need to be that specific?  I think those 0-day NMU mails
from last week might be well suited for RFH.  I think it is beneficial
if the help request is permanently visible compared to being burried
in some list archive.

If you wanted to request help for a specific bug you would tag it
'help'.  Am I correct?

>
>> >   Again, I do not appreciate the latent criticism of the big teams to
>> > hide their understaff problem. It's blatantly bogus hence iritating,
>> > almost insulting.
>>
>> Don't you wonder why it is perceived like that?
>
>   Yes I do, especially given that in that thread those teams have
> claimed many times they need help, and that people continue to pretend
> like it never happened. So Yes I wonder if it's not that it's just
> easier to pretend it's our fault, than to question onself "wtf didn't I
> helped before already ?"

Well, of course, it is always easier to blame everybody else.  I just
think an argument like "We have a RFH out since one year and nobody
cared." will work better for you than "We sent a request to -kde a year
ago and nobody responded."


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

Re: On maintainers not responding to bugs

[Matthias Julius]

Roland Mas <[EMAIL PROTECTED]> writes:

> Matthias Julius, 2007-03-07 11:32:32 -0500 :
>
>> It's a matter of how someone arrives at the point where he wants to
>> help.  If he wakes up one morning and thinks "I want to help the KDE
>> team" he will probably contact the KDE maintainers.  If he thinks
>> "Since 3 years I am using Debian it's time for me to contribute." he
>> might look in more generic places to find out who requests help.
>
> In that case, I suppose http://www.debian.org/intro/help should be
> made a bit more helpful.  More visible, more readable, and so on.  I
> understand one of the DPL candidates intends to work (or get people to
> work) on the Debian website; I suggest this page could be considered
> during that endeavour.

I don't consider it to be too bad.  But it would be a good step
forward if it contained a reference to the RFH list.

Matthias


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

Re: On maintainers not responding to bugs

[Matthias Julius]

Kevin Mark <[EMAIL PROTECTED]> writes:

> message to its intended target is a hard thing. How about having 'text
> ads' on the pages of the Debian site that showcase a 'request for help'
> or similar?

I don't like ads.  Ads are annoying.  That doesn't mean they don't
work.  If I need some information I usually know where to look for it
(for information that is conveyed in an ad anyway).

An innocent potential helper will probably start at www.d.o and find
the "Help Debian" link.  Following that whould lead to all information
needed.  The next thing one might try is the "Developers Corner"

If help requests are not accessible through those channels chances are
slim that they will be noticed by the target audience. IMHO

Matthias


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

Re: On maintainers not responding to bugs

[Matthias Julius]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> ] ] > >   Again, I do not appreciate the latent criticism of the big teams
> ] ] > >   to
> ] ] > > hide their understaff problem. It's blatantly bogus hence iritating,
> ] ] > > almost insulting.
> ] ] >
> ] ] > Don't you wonder why it is perceived like that?
>
>   Which do seem like a quite not very hidden accusation, so yes, somebody
> is playing finger-pointing games here, and I'm tired of it.

Actually, I am trying to not to accuse anybody of anything and not to
point fingers.  I know that you are very active within Debian and I
appreciate the work you do.  The same is true for many contributors.

I just meant there must be a reason if many people say: "I didn't now
you needed help."  Appearently you and others were unsuccessful in
conveying the message that you do need help.

And I was trying to promote the idea to use a central and permanently
visible platform for such help requests (the RFH list).

And I don't mean at all to say: "Blame yourself for not getting help
because you didn't send in a RFH!"

Matthias


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

Re: On maintainers not responding to bugs

[Matthias Julius]

Kevin Mark <[EMAIL PROTECTED]> writes:

> I see no harm in addressing the issue in multiple ways. I have no
> problem with a FLOSS project 'asking' for help in an ad. I dont like ads
> for most other things. People take multiple paths to find stuff. Instead
> of assuming that 'if I found it, then everyone can!', I'd simply like to
> increase the avenues for people to find the help requests. More
> pageviews of help requests, the more possible help. I'd simply like for
> it to be given a trial rather than 'I know it will not work, therefore
> it must not be tried'.

Ads for non-commercial stuff are a little better than commercial ads.

There is nothing wrong with publicizing a help request through several
different channels.  One can send an RFH, write a wiki page, post it
on Alioth or on some mailing list.  What I wouldn't like too much is a
banner on www.d.o

A clearly labelled link to the relevant information should be
sufficient.  I think it is better to make information easily
accessible for someone who is interested in it than to push it out to
everyone.

Matthias

Re: Ethernet interface numbering in etch

[Matthias Julius]

Mike Hommey <[EMAIL PROTECTED]> writes:

> On Tue, Mar 27, 2007 at 12:06:09AM -0400, Nathanael Nerode <[EMAIL 
> PROTECTED]> wrote:
>> Specifically because:
>> * Most machines have only one interface (If Debian is running on more 
>> routers 
>> than workstations, obviously this would be wrong, but I doubt that's the 
>> case.)
>
> More and more server machines come with dual interfaces.

And even consumer mainboards.

Matthias


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

Re: Ethernet interface numbering in etch

[Matthias Julius]

Gabor Gombas <[EMAIL PROTECTED]> writes:

> On Mon, Mar 26, 2007 at 11:11:04AM -0500, John Goerzen wrote:
>
>>configuration, it will no longer bring up the network on boot because
>>the device name changed.  If the box is using NFS, NIS, or LDAP,
>>people may even have trouble logging in to it.
>
> If you replace a NIC you surely check that it is working before you
> leave the machine room, don't you?

In case of a rented dedicated server I would never enter the machine
room and the person changing hardware would have no login on it.

For other machines the only possible access is by SSH which is
difficult if the network is not coming up.  Setting them up with
keyboard/monitor (if they have a video output at all) or a serial
console (and RS232 is getting rare, too) is an inconvenience at least.

Matthias


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

Re: Ethernet interface numbering in etch

[Matthias Julius]

Ben Hutchings <[EMAIL PROTECTED]> writes:

> And almost every laptop comes with wired and wireless interfaces.

I almost wrote that myself, but they have different names and dont
compete for numbers.

Matthias


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

Re: Attempted summary and thoughts

[Matthias Julius]

"cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> writes:

>Automatically orphaning such packages has problems as Russel pointed out,
>but a "needs co-maintainers"/"needs hijacking" list of packages where
>DD's can be more aggressive in jumping/taking over in seems a good idea
>IMO.

You could allow and encourage NMUs for bugs of priority less than
important that are more than 6 months old.

Matthias


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

Re: Pushing multi-arch media (Re: blockers for 64-bit adoption)

[Matthias Julius]

Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes:

> On Mon, Apr 09, 2007 at 03:51:54PM +0200, Alexander Schmehl wrote:
>> The multiarch media still has a small problem:  for i386/amd64 they are
>> no "fire and forget" thing;  you still need to find out if you have an
>> amd64 compatible system and start the amd64 boot process by hand.
>> 
>> It would be really cool, if that could be autodetected... but I don't
>> know how that could be done.
>
> Check if the processor has support for long mode?  AIUI it only takes a
> bit of assembler to do it (on a Linux system you can look for "lm" in
> /proc/cpuinfo, but I suspect this has to be done before Linux is
> booted).

Does d-i need to run in 64bit mode to be able to install a amd64
system?

Matthias


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

Re: Pushing multi-arch media (Re: blockers for 64-bit adoption)

[Matthias Julius]

[EMAIL PROTECTED] (Lennart Sorensen) writes:

> On Mon, Apr 09, 2007 at 12:37:16PM -0400, Matthias Julius wrote:
>> Does d-i need to run in 64bit mode to be able to install a amd64
>> system?
>
> It needs a 64bit kernel to run 64bit binaries, and since many post
> installs run binaries, I would say yes it does.

Yes, post-installs are a problem.

>
> You could probably isntall 32bit using a 64bit kernel though, so if the
> boot laoder for the installer always loaded a 64bit kernel on any cpu
> capable of running it, then you could still let people pick which they
> want.

If you can detect whether the CPU supportst 64bit before booting the
kernel then the problem doesn't exist.

Can Grub be set up in a way that it falls back on booting a 32-bit
kernel if the 64-bit one doesn't boot?

Matthias


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

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Matthias Julius]

[EMAIL PROTECTED] (Lennart Sorensen) writes:

> Actually I wouldn't say win64 is broken, it just has a serious lack of
> drivers, which of course will continue as long as nobody is using it.
> If microsoft wanted to solve this they should mandate 64bit drivers
> along with 32bit drivers in order to certify a driver for vista.  Until
> they force drivers to exist, 64bit windows will be a niche market for
> high end servers only.

Workstations as well.  CAD is one example.  You can never have enough
memory there.  I could imagine the same is true for video processing
or rendering and similar applications.  I guess it won't become
mainstream until there are a siginficant number of 64bit games.

Matthias


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

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Matthias Julius]

Robert Millan <[EMAIL PROTECTED]> writes:

> You mean win64-only games?  Nobody dares to invest in developing that now;
> it would be suicidal.

I don't know about the practices of game developers, but, from what I
see on Linux it should be minimal effort to port a software to 64 bit
if it is written right.  So, I would expect developers to keep
64-safety in mind when writing new code.  Eventually this would lead to
programs that can be built for 64bit systems.  And since 64bit CPUs
are available for consumers since a while now I would have hoped this
process has started 5 years ago.

There seems to be a market for high-end gaming hardware.  I imagine
there are people willing to pay a premium for 64bit games that produce
a 10% higher frame rate, too.

> If a game really needs bigmem, PAE is much more feasible (it is a
> trap, but that's not a problem for the game vendor ;-)).

Isn't PAE a performance hog?  And it still limits the amount of memory
a process can get.

Matthias


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

Re: Pushing multi-arch media (Re: blockers for 64-bit adoption)

[Matthias Julius]

Robert Millan <[EMAIL PROTECTED]> writes:

> I suppose you haven't seen my previous mail.  Note that this problem
> (autodetecting 64-bit) is already solved in etch.

True.  I've read it after I wrot mine.

Does d-i use syslinux?

Matthias


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

Re: Pushing multi-arch media (Re: blockers for 64-bit adoption)

[Matthias Julius]

Joey Hess <[EMAIL PROTECTED]> writes:

> Just a thought, but how about booting d-i and familiarising yourself
> with it? (This goes for all DDs who have never run d-i.)

I hate to reboot just to try out d-i. :-)

Now that etch is released I will actually do that.  I have one machine
left that is not running Debian.

Matthias


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

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Matthias Julius]

Robert Millan <[EMAIL PROTECTED]> writes:

> On Mon, Apr 09, 2007 at 03:48:06PM -0400, Matthias Julius wrote:
>> 
>> I don't know about the practices of game developers, but, from what I
>> see on Linux it should be minimal effort to port a software to 64 bit
>> if it is written right.  So, I would expect developers to keep
>> 64-safety in mind when writing new code.
>
> Yes, providing a 64-bit version in addition to the 32-bit one is not too
> hard if you do things right (they're starting to do that already).  But
> if you release the win64 version only, you are screwed :-).  I suppose
> Microsoft is going to be the only game vendor who does that (they did it
> for Exchange already).

I don't know that game. :-)

>
>> There seems to be a market for high-end gaming hardware.  I imagine
>> there are people willing to pay a premium for 64bit games that produce
>> a 10% higher frame rate, too.
>
> Only if they have a working platform to run them on, which for win64 is
> not currently present.

There are some drivers.  And having popular applications would drive
demand.

But anyway, what do we care?  I have my working 64bit platform.

Matthias


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

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Matthias Julius]

[EMAIL PROTECTED] (Lennart Sorensen) writes:

> Well my farther is going to get a new system for cad soon, which the
> current plan is to have 64bit vista with solidworks 64bit running.  But
> it might be another month or two before he is ready for it, so hopefully
> by then any remaining driver issues are worked out. :)

Manufacturers of professional graphics hardware are certainly aware or
their CAD customers and provide win64 drivers.  Otherwise you need
network drivers and you are good to go on a CAD workstation.

>
> I think in general the 3d modeling and cad users will very much like
> 64bit windows.  Many of the 3d modeling people ran windows xp 64bit
> version in beta for a long time because they couldn't wait for it to be
> done.

Yes.  I see questions about win64 every week in the Autodesk Inventor
discussion group.  Unfortunately, the answer is always: No, but at
least it will get up to 4 GB of memory.  You will get a similar answer
if yo ask about multicores.  And the really sad thing is that this is
even true for the upcomming release.

If only software vendors would accept Linux as a platform...  Life
would already be much better.

Matthias


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

Re: Pushing multi-arch media (Re: blockers for 64-bit adoption)

[Matthias Julius]

Santiago Vila <[EMAIL PROTECTED]> writes:

> On Mon, 9 Apr 2007, Matthias Julius wrote:
>
>> I hate to reboot just to try out d-i. :-)
>
> Actually, you don't have to. Try qemu.

Ahh, true.  That's another chapter I havn't looked into, yet.

Matthias


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

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Matthias Julius]

"Tshepang Lekhonkhobe" <[EMAIL PROTECTED]> writes:

> I've got an idea that some software is targeted at such a narrow
> userbase (CAD for example) that volunteer development seemes
> unjustified. In such cases, it's nice when academy and business lend
> their hand.

There just isn't enough interest among people who would be able for a
project like a parametric 3D CAD modeller.  The only project I know of
is Varkon (http://www.tech.oru.se/cad/varkon/man.htm).  When I tried
it a while back I gave up.  It wasn't very intuitive and I didn't have
much time.  There is active development but it is not a solid
modeller.

Matthias


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

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Matthias Julius]

Luis Matos <[EMAIL PROTECTED]> writes:

> Free cad implementations are too simple for use in some industrial
> environments, when programs like CATIA or Solidorks, or inventor, Come
> in Mind.
> These programs are expensive and require power that can be better used
> in 64 bit platform.

64bit Linux has been available since years.  Pro/E is available for
32bit RHEL only.  UGS NX was to be ported to Linux as well, but I
couldn't find any information on their website.  It seems like you
have to log in first and you have to be a customer for that.

So why is nobody adopting 64bit Linux (or *BSD)?

Autodesk will not even have a win64 port of Inventor with the upcoming
release.  They do have one for AutoCAD.  I doubt Autodesk will ever
port their software to Linux.  They are tied up with MS all over.
Inventor requires MS Excell and it uses VBA.  Their data management
system requires MS IIS and MS SQL Server.  They are just switching
from OpenGL to DirectX...

AFAIK it doesn't look much better for SolidWorks.

Matthias


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

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Matthias Julius]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Er, by definition a patent is supposed to include a complete description of
> the invention that would permit a third-party to reimplement the invention,
> in exchange for granting the inventor exclusive rights to the invention for
> a limited time.  Would you argue that distributing copies of the patent
> application is infringement, too?

While you are probably free to distribute the description you are not
free to distribute an implementation of the technology claimed by the
patent.  You can implement it but you can not distribute the
implementation.

Matthias


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

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Matthias Julius]

Robert Millan <[EMAIL PROTECTED]> writes:

> If x86_64-linux-gnu is stablished as the new reference api, well, they'll
> be forced to.

Reference for what?  Is there any software vendor porting his
applications to 64bit Linux because of problems with win64?  I havn't
noticed any.  Proprietary software that is available for Linux is only
available for i386 in most cases.

I don't know what the critical mass of Linux users is that generates
interest for Linux among software vendors.  We seem to be far from
it.  

Matthias


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

Re: Not-so-mass bug filing for the patented IDEA algorithm

[Matthias Julius]

Ben Hutchings <[EMAIL PROTECTED]> writes:

> There is an argument that source code can only be a description whereas
> a binary is an implementation, so only distributing binaries that
> include the claimed invention could infringe.  I'm not sure whether this
> has been legally tested.

If this holds true that would mean Debian could distribute the source
as long it is disabled and not compiled into the binary.

Personally, I don't think that argument is valid.  What about
interpreted languages where only the source is shipped anyway?  This
would mean you don't need to care about patents as long as you
implement it in e.g. Python.  I don't think that will withstand a
legal trial.  But, I am no lawyer.

Matthias


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

Re: Pushing multi-arch media (Re: blockers for 64-bit adoption)

[Matthias Julius]

Robert Millan <[EMAIL PROTECTED]> writes:

> On Mon, Apr 09, 2007 at 09:54:20PM -0400, Matthias Julius wrote:
>> Santiago Vila <[EMAIL PROTECTED]> writes:
>> 
>> > On Mon, 9 Apr 2007, Matthias Julius wrote:
>> >
>> >> I hate to reboot just to try out d-i. :-)
>> >
>> > Actually, you don't have to. Try qemu.
>> 
>> Ahh, true.  That's another chapter I havn't looked into, yet.
>
>   sudo apt-get install qemu
>   qemu -cdrom debian.iso
>
> That's all :-)

Life can be so easy.

Thanks,

Matthias


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

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Matthias Julius]

Robert Millan <[EMAIL PROTECTED]> writes:

> On Tue, Apr 10, 2007 at 04:43:09PM -0400, Matthias Julius wrote:
>> Robert Millan <[EMAIL PROTECTED]> writes:
>> 
>> > If x86_64-linux-gnu is stablished as the new reference api, well, they'll
>> > be forced to.
>> 
>> Reference for what?  Is there any software vendor porting his
>> applications to 64bit Linux because of problems with win64?
>
> No, but there isn't any vendor providing win64 games either.  Everything
> I see are proof-of-concept versions that nobody is going to use because
> functionaly equivalent win32 counterparts are available.  I will truly
> believe it when I see win64-only games, and when I see gamers give up their
> old, driverless hardware to be able to run them on win64.

I don't think it needs win64-only games.  It just needs games that run
with a 10% higher frame rate on win64 to create demand. Or on
Linux-amd64.

My point is that not many people will switch to 64bit Linux because
they can not have a working win64 system.  People switch for other
reasons.  Or would if their favorite application would support it.
And for most people it doesn't matter whether they run in 32 or 64bit
mode on Windows and Linux.  I run amd64 because it is available and
almost as complete as i386 - not because I really need it.

>
>> I havn't
>> noticed any.  Proprietary software that is available for Linux is only
>> available for i386 in most cases.
>
> The same happens on Windows.
>
>> I don't know what the critical mass of Linux users is that generates
>> interest for Linux among software vendors.  We seem to be far from
>> it.  
>
> Yes, but Microsoft is much farther.  I wouldn't be surprised if our 64-bit
> userbase outnumbered win64's already.

And MS doesn't care.  As long as users don't switch to Linux because
they need a working 64bit system.  This might be the case for servers
but not for desktop systems.  People just stay with win32 if they can
not have win64 drivers for their hardware.

> When 64-bit computing as a whole starts to become significant,
> they'll start to be interested in either of these platforms.

It will be a while before that happens for desktop computers.  So far
it doesn't provide a real advantage for the average desktop computer.

Matthias


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

Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)

[Matthias Julius]

[EMAIL PROTECTED] (Lennart Sorensen) writes:

> Autodesk is fortunately slowly becoming less relevant as much better
> programs are eating away at their market share.  Moving to directx
> sounds crazy given the pro level graphics cards have certified opengl
> drivers, not directx drivers.  They really must have had too much of the
> Microsoft coolaid.

Inventor wouldn't be that bad of a program if it was more stable.

> Solidworks has 64bit support, and they are sticking with opengl.

That's something on the plus side.  But it still needs Excel and uses
VBA.

Matthias


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

Re: The number of etch installations is rocketing...

[Matthias Julius]

Petter Reinholdtsen <[EMAIL PROTECTED]> writes:

> [Sebastian Mach]
>> Is that only for stable? Me for example uses a february testing, and
>> I might not be alone
>
> These numbers are for everyone, including oldstable, stable, testing
> and unstable.

And what is most interesting about them is their rate of increase.
And I don't think anybody will now install a february testing.

Matthias


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

Re: Doc-base section hierarchy

[Matthias Julius]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:

> Programming/OCaml would be better than the status quo for me.
>
> But actually I'm not sure if my case would deserve an even finer
> sub-category such as Programming/$language/ApiReference or similar. What
> do you think?
>
> Would it be possible to let package maintainers to refine some leaf
> categories?

There are many packages that have more than one piece of
documentation. I think it would be generally a good idea if there is a
sub-category in those cases.

Matthias


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

Re: debian/copyright verbosity

[Matthias Julius]

Ben Finney  writes:

> This seems a useful summary:
>
> Neil Williams  writes:
>
>> AFAICT it is perfectly acceptable for debian/copyright to collapse
>> those to:
>> 
>> >  Files: *.c
>> >  Copyright: 2006, 2008 Mr. X
>> >  Copyright: 2005 Mr. Y
>> >  License: GPL2+
>> 
>> There is no collapsing of the years - each year is described
>> separately.
>> 
>> The copyright is retained and each file is listed in debian/copyright
>> under the correct licence.
>
> That's pedantically true, perhaps, but only in the sense that I can say
> the entire works of Shakespeare are retained in the keys on a keyboard.
> The relevant question, it seems to me, is whether the information is
> preserved usefully.

It is exactly what you would get if someone would merge the three
files into one.  Suddenly, the copyright statements cover the whole of
the contents of all three files and you couldn't knwow anymore what is
by whom.  Would the copyright statement be less true?

Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian/copyright verbosity

[Matthias Julius]

Noah Slater  writes:

> On Tue, Apr 14, 2009 at 07:27:33PM +1000, Ben Finney wrote:
>> > Does Files: *.c mean that everything below applies equally to all
>> > files that match the pattern or does it mean that the statement
>> > includes a summary of all files that match the pattern?
>>
>> Before this thread, I was under the unquestioning assumption that the
>> former interpretation was the only one. The question has never, to my
>> knowledge, been raised explicitly like this before. I'd like to know
>> what the consensus of the Debian project is on the question.
>
> Likewise, I had never thought of this use before, but now it has been 
> explained
> I don't think I have a problem with it. My expectation for the Copyright field
> has been widened significantly following recent discussion, to the point 
> where I
> no longer consider it necessary at all. Given this position, it is not hard 
> for
> me to appreciate that you might want to collapse any copyright statements down
> into one File stanza for convenience.

I would say that the former interpretation applies.  Files: *.c means
that all files that mach the pattern are covered in this section of
the copyright file.  And I believe everyone agrees that a following
License: GPL2+ then applies to all of those files.

The question is to me what a Copyright: stanza really means.  A
copyright statement in a source file does not imply that every person
mentioned has a copyright on every line of the file.  It means that
every person has a copyright on some portion of the file (that the
program authors have deemed siginficant enough to mention the person
at all).  And I think it is perfectly fine to expand that principle to
debian/copyright and say that each person mentioned in the Copyright:
stanzas has a copyright to some portion of the files specified in
Files: - and not necessarily every file.

Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian/copyright verbosity

[Matthias Julius]

Ben Finney  writes:

> Matthias Julius  writes:
>
>> It is exactly what you would get if someone would merge the three
>> files into one. Suddenly, the copyright statements cover the whole of
>> the contents of all three files and you couldn't knwow anymore what is
>> by whom. Would the copyright statement be less true?
>
> But, in the proposed scenario, that *hasn't happened*. How is it a
> useful preservation of information to falsely assume that an event has
> occurred when writing ‘debian/copyright’, or to ignore the distinction
> of whether it has or not?

I just meant to say that when it is OK to summarize the copyright
statements when merging the files then it should also be fine to make
the same summarized statement about a set of files.  One is as true as
the other.

Matthias


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ignoring the CoC in regards to cc:s (Re: Can we ship sources of a PDF file in the Debian diff?

[Matthias Julius]

Noah Slater  writes:

>   * I don't know much about mailing list software, so I'm not going to be as
> bold as to suggest I know what the solution is. However, on all the other
> lists, I never get duplicate copies of email when people reply to me with 
> an
> unnecessary CC. Perhaps they are intelligently filtering out recipients 
> from
> the mailing list software?

Don't know about the Debian list server, but mailman for example can
be set to not send a list posting to someone who is already in To: or
Cc:.  But, I don't like that because I have my mail sorted by List-Id
and mails sent directly to me obviously don't have that header.

Also, for example cyrus can filter out duplicate mail.  But, since the
direct mail is usually faster than the one going through the list
server, this results in the same problem as above.

That's why I like the way Debian lists are setup and the CoC.

>
>   * The Debian lists do not have a Reply-To header, meaning that by default my
> email client wants to send replies to individual posters. To get the 
> mailing
> list included in the reply means that I have to reply to all. It's a very
> easy mistake to make, not to remember to manually shuffle these addresses
> around each time I want to send a follow up. Don't make me think!

Doesn't mutt have a reply-to-list functionality?

Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org