Re: unknown-field-in-control homepage

[Frans Pop]

On Thursday 07 February 2008, Guillem Jover wrote:
> > I raised this issue on #debian-boot (irc), and was told that the
> > concerns by "(a d-i maintainer | someone who was willing to express an
> > opinion" were correct. Frans Pop from the debian-installer team
> > verified that the Homepage field should not be included in the udeb:
>
> Yes, makes sense. I've just fixed it in dpkg's git [0].

Thanks Guillem.


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

Re: [RFC] Changing priority of selinux back to optional

[Andreas Tille]

On Thu, 7 Feb 2008, Christian Perrier wrote:


Possible alternative: create a tasksel's task to include it, which
would make testing of installs with SELinux by default easier.


I would be in great favour of this.


Being
something not really end user-oriented, that would have to be a
"hidden" task (not shown as a choice by tasksel) that one could choose
with the appropriate D-I boot option.


Hmmm, why hidden?  In how far are other tasks more or less user-oriented?

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: [RFC] Changing priority of selinux back to optional

[Christian Perrier]

Quoting maximilian attems ([EMAIL PROTECTED]):

> 
> but currently willing to work on i'd nack fjp requests.
> of course if no progress has been made in a month,
> his request is more then reasonable.


I slightly disagree. Not that I have doubts about your commitment, but
this entire discussion showed that SELinux is, right now, not ready
for being included in default installs. As D-I is preparing a beta
release, it could be better to downgrade selinux stuff to optional
before that release.

It can still be reactivated later in case the progress you bring
proves to be enough for this.

Possible alternative: create a tasksel's task to include it, which
would make testing of installs with SELinux by default easier. Being
something not really end user-oriented, that would have to be a
"hidden" task (not shown as a choice by tasksel) that one could choose
with the appropriate D-I boot option.




signature.asc
Description: Digital signature

Re: Copyright question (BSD with advertisement clause)

[Charles Plessy]

Le Wed, Feb 06, 2008 at 10:27:55PM -0800, Russ Allbery a écrit :
> 
> Am I missing something?

This ?

http://web.archive.org/web/19990210065944/http://www.debian.org/misc/bsd.license
http://web.archive.org/web/20001205083200/http://www.debian.org/misc/bsd.license

-- 
Charles


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

Re: ITP: opencascade -- CAE platform library and scripting engine

[Christian Perrier]

Quoting Adam C Powell IV ([EMAIL PROTECTED]):
> Package: wnpp
> Severity: wishlist
> 
> Package name: opencascade
> Version: 6.2.0
> Author: Open Cascade SAS (OCC), a French software services company
> URL: http://www.opencascade.org/
> License: Open CASCADE Technology Public License, includes triangle with 
> non-free source
> Description: CAE platform library and scripting engine

s/CAE/computer-aided engineering would be more explicit, maybe.

> 
> Greetings,
> 
> I am packaging OpenCASCADE, a powerful computer-aided engineering (CAE)


That's great news. From what I know, OpenCASCADE is a pretty rare story
of a completely proprietary solution being opened by its owner to
become "Open Source"so getting it into Debian, if legal questions
allow this, would be a major step.




signature.asc
Description: Digital signature

Re: Bug#464392: ITP: libdebian-package-make-perl -- Perl extension for autobuilding Debian packages

[Christian Perrier]

Quoting Hilko Bengen ([EMAIL PROTECTED]):
> Package: wnpp
> Owner: Hilko Bengen <[EMAIL PROTECTED]>
> Severity: wishlist
> 
> * Package name: libdebian-package-make-perl
>   Version : 0.01
>   Upstream Author : myself
> * URL or Web page : not published yet
> * License : GPL2+
>   Description : Perl extension for autobuilding Debian packages

I suggest "s/Debian/.deb"

That would prevent derivative distributions to embark something that
is less meaningful for them.


> 
> Debian::Package::Make is a module that aims to simplify the necessary
> steps for completely automated builds of Debian packages and to

Same proposed change here.

> provide a sound base for make-*-package scripts.
> 
> This is useful for source distributions where contents change rapidly
> or where peculiar licenses prohibit redistribution via public package
> repositories.



signature.asc
Description: Digital signature

Re: Copyright question (BSD with advertisement clause)

[Russ Allbery]

Ben Finney <[EMAIL PROTECTED]> writes:

> The 4-clause BSD license is not one that we list as an acceptable
> license.
>
> DFSG http://www.debian.org/social_contract> §10:
>
>  10. Example Licenses
>
>  The GPL, BSD, and Artistic licenses are examples of licenses that
>  we consider free.
>
> That text isn't specific about *which* "BSD license" is an example of
> a free license.
>
> However, in that text, the term 'BSD' is an anchor to
> http://www.debian.org/misc/bsd.license>, which is a copy of the
> 3-clause BSD license, without advertising clause. That seems explicit
> that it's the version given as an example of a free license.

Hm, I could have sworn that the DFSG predated the Constitution and hence
predated the existence of the three-clause BSD license.  UCB dropped the
advertising clause in July of 1999 and the DFSG were adopted in July of
1997 according to Wikipedia.  Hence, I assumed the BSD license as referred
to in the DFSG must, regardless of what the web site currently links to,
actually refer to the 4-clause license since that's the only thing that
existed at the time.

Am I missing something?

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: [RFC] Changing priority of selinux back to optional

[Manoj Srivastava]

On Wed, 06 Feb 2008 00:49:01 +0100, Erich Schubert <[EMAIL PROTECTED]> said: 

> Hello Frans, Hello fellow DDs, Yes, the SELinux stuff doesn't seem to
> have any currently active developers. I haven't heard anything from
> Manoj in months.  

I haven't been around a whole lot, no.

> Anyway, back to the original topic:
> 1. I agree that SELinux currently is not in shape for a release. The

I don't think Lenny is in shape for a release either.  It took
 me about a day to get most SELinux packages back up to date --  which
 means we could have them updated anytmime in the last few months, if
 any one had the time or motivsation.

I ought to be back, now that we have survived the end of the
 year dog and pony show at work.

> packages are seriously outdated, there have been some major changes in
> upstream. In particular, the 'targeted' and 'strict' policies have
> been merged and only differ by having a 'targeted' module
> installed. AFAIK.

That is the case in the policy we have currently in Sid as well.



> 2. At least libselinux is linked by many of the core packages, and the
> package REALLY should be updated nevertheless. However that might
> require also updating most of the other packages; I'm not sure about
> API compability.

You update most libraries in sync, and most of the utility
 packages.  Done today.

> 3. In my experience, none of the SELinux librarys or applications were
> particularly hard to package/maintain. All the hard work is in
> fine-tuning the policy to support all the Debian-specific stuff.
> Especially when you need the cooperation of other maintainers, such as
>   initscripts: http://bugs.debian.org/390067 cron:
>   http://bugs.debian.org/333837 liblzo1:
>   http://bugs.debian.org/336138All of which have been open in the
>   range of 1.5-2.5 years.


Well.  Currently, I think the new setools, polgen, and slat
 packages _are_ hard. The refpolicy is not easy either, and not because
 of packaging, but because of the testing that needs to be done with any
 change.

> So maybe it would be better to actually get some people involved in
> SELinux again.

That would indeed be nice.


manoj
-- 
"Intelligence without character is a dangerous thing." Steinem
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: [RFC] Changing priority of selinux back to optional

[Manoj Srivastava]

On Wed, 6 Feb 2008 12:27:45 +0100, maximilian attems <[EMAIL PROTECTED]> said: 

> so asking if the SELinux team is ok with adding me as co-maintainer?
> thanks Erich for your concise posting on where the work needs to be
> picked up!

The place we need most  work is
 1) slat
 2) polgen-dfsg (I need to redo python packaging in there)
 3) setools (I am packaging 3.3.2, and that seems to need a whole slew
of new packages, new libs -- libqpol, libpoldiff, etc, and new
python and java binding packages)
 4) policy.  Wait until the new policy upload tomorrow, and then  see
how to deal with any errors that arise on your machine.  This is
where the most help is needed.

If people send in patches, I'll try to maintain a less than
 seven day turn around time on them  starting this weekend.

manoj
-- 
Is there another word for synonym? George Carlin
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: [RFC] Changing priority of selinux back to optional

[Manoj Srivastava]

On Tue, 5 Feb 2008 23:19:14 +0100, Frans Pop <[EMAIL PROTECTED]> said: 

> The priority of selinux packages was changed from optional to
> standard, fairly shortly before the release of Etch.

> I propose to revert that change before Lenny. The basic reason is that
> the selinux packages have basically been unmaintained since the
> release of Etch. Because of that current SeLinux just cannot be
> expected to work.

While this is mostly true (I have been swamped in real life
 work), I do expect tha to change this spring (indeed, most of the
 SELinux packages are now sitting in incoming -- happy happenstance)

> An additional reason is that the installation of selinux packages adds
> significantly to the size of the base system and accounts for a
> significant part of the time it takes to install the "standard" task,
> especially on slower architectures. This would be OK if there were
> real benefits in having SeLinux, but ATM that benefit is just not
> there.

I am not sure I agree. SELinux is working for me in production
 on  Lenny/Sid machines; 

> Packages (both tools and policy packages) currently available in
> unstable and testing are seriously outdated when compared with their
> upstream versions. This also means that, with the soft freeze for
> Lenny starting fairly soon, that there is little time left to
> substantially improve the SeLinux support in Debian, which was one of
> the arguments for making it standard in the first place.

Err, I think you are making far too much of the amount of effort
 required.  While we are a few minor version behind; updating it was a
 days effort -- apart from policy, which I'll get to tomorrow.

So I am not sure we are in dire straits, but y'all will have to
 make that decision.

> Some facts.

> Package etch lenny/sid upstream policycoreutils 1.32-3 2.0.16-1 2.0.42
> (?)  setools 2.4-3 2.4-3 3.3.2 refpolicy 0.0.20070507-5 0.0.20070507-5
> 20071214 libsepol 1.14-2 2.0.3-1 2.0.20 (?)  libselinux 1.32-3
> 2.0.15-2 2.0.50 (?)

> None of the packages in Debian has been updated since June/July 2006.

That is indeed true.  It is also nmo longer the case, but I
 can't excuse the fact that I have been very busy.

> There are also some longstanding bugs, including fairly simple
> packaging errors in Etch, none of which have been addressed. Examples:
> - #440474: chcat: syntax errors
> - #405975: semodule_deps and semodule have alignment issues
> - #427906: postinst: policy package name to deb name, lacks glob
>   #support
> - #438604: selinux-basics: Invalid test for dynamic motd updating
> - #438706: selinux-doc: Error in doc-base definition
> - #438887: refpolicy: Spurious "+" causes warnings when building
>   #modules

> None of these bugs has seen any reaction from the package maintainers.

Mostly fixed.

manoj
-- 
Excess of grief for the deceased is madness; for it is an injury to the
living, and the dead know it not.  -- Xenophon
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Copyright question (BSD with advertisement clause)

[Ben Finney]

Russ Allbery <[EMAIL PROTECTED]> writes:

> I don't think it's horribly credible that including software covered
> by the 4-clause BSD license in Debian violates the principle of
> least surprise when we specifically list it as one of our acceptable
> licenses in the DFSG.

The 4-clause BSD license is not one that we list as an acceptable
license.

DFSG http://www.debian.org/social_contract> §10:

 10. Example Licenses

 The GPL, BSD, and Artistic licenses are examples of licenses that
 we consider free.

That text isn't specific about *which* "BSD license" is an example of
a free license.

However, in that text, the term 'BSD' is an anchor to
http://www.debian.org/misc/bsd.license>, which is a copy of the
3-clause BSD license, without advertising clause. That seems explicit
that it's the version given as an example of a free license.

It would perhaps be better for the DFSG to disambiguate "BSD license"
in the text of the DFSG, but the hyperlink to the 3-clause BSD license
without advertising clause serves the purpose in this instance.

-- 
 \   “It ain't so much the things we don't know that get us in |
  `\ trouble. It's the things we know that ain't so.” —Artemus |
_o__)  Ward (1834-67), U.S. journalist |
Ben Finney


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

Re: How to cope with patches sanely

[Manoj Srivastava]

On Tue, 05 Feb 2008 18:30:40 +0100, Sven Mueller <[EMAIL PROTECTED]> said: 

> On another note, I have a slight problem with the (other) proposal of
> using a (git/$DVCS) repository as the form of source package
> distribution. Mainly because I think this will usually add
> bloat. While developing/packaging, I often see intermediate commits
> which need to be heavily modified or even reverted to finally build
> the patch I wanted to get working. Though these commits are fine in
> the Repository, I wouldn't want to see all the intermediate steps in
> the source package.

I take it that you do not use sloppy branches to do
 development.  I can see why you generate cruft in the repo. I generally
 do my development in a sloppy branch, which is in a private repo.  When
 things work as I like, I then refactor patches from the sloppy branch
 into a feature branch  (I have a catch-all features branch for stuff
 that is small and unlikely to make it into upstream). Each commit into
 a feature branch can be clean -- and then merged forward into the
 integration branch immediately.

This way, all th cruft lies in the sloppy branch, which I then
 dump.

manoj
-- 
Real Programmers don't write in PL/I.  PL/I is for programmers who can't
decide whether to write in COBOL or FORTRAN.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: How to cope with patches sanely

[Manoj Srivastava]

On Tue, 5 Feb 2008 09:00:52 +, Matthew Johnson <[EMAIL PROTECTED]> said: 

> On Tue Feb 05 00:51, Manoj Srivastava wrote:
>> > If we can't figure out a good and clean way to keep a large stack
>> > of long-lived patches in the vcs then I firmly believe we should
>> > standardize on quilt.
>> 
>> I think I have indeed solved the issue of long standing feature sets
>> using feature branches, integration branches, and sloppy branches
>> while upgrading, and would not want to be forced to regress to a
>> patch system.
>> 
> I don't think anyone is talking about forcing DVCS users to regress to
> a patch system, merely to change the interchange format; which all
> DVCS-based maintenance methods can easily export to/import from. The
> only reason which you would have to interact with it would be a more
> standard interface for NMUs, which can only be a good thing.

Why should I bring my feature branches into a patch system, when
 there is no need to?  As far as the end user or NMUer is ocnerned, they
 do apt-get source foo, and they get the sources they may hack
 on. Adding to the chaos by converting my nice, clean source format to
 the blecherousness of a patch system does seem like regression to me.

manoj
-- 
IBM Advanced Systems Group -- a bunch of mindless jerks, who'll be first
against the wall when the revolution comes...  -- with regrets to
D. Adams
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Copyright question (BSD with advertisement clause)

[Russ Allbery]

Charles Plessy <[EMAIL PROTECTED]> writes:

> I think that it is a bit frivolous to distribute software with
> advertisment clause in main and not properly warning the redistributors,
> who are the most likely persons to infringe the clause. We should
> remeber that for other aspects of licencing and intellectual property
> management, Debian is much more rigorous, so the presence of 4-clauses
> BSD licences is contradicting the principle of least surprise, that is
> usually a good guidance.

I don't think it's horribly credible that including software covered by
the 4-clause BSD license in Debian violates the principle of least
surprise when we specifically list it as one of our acceptable licenses in
the DFSG.

But regardless, practically speaking, the inclusion of one more or fewer
package in main with an advertising clause will make no practical
difference for the requirements of any redistributor.  Any serious attempt
to eliminate this license from Debian would face other challenges first,
such as removing OpenSSL from main.  Unless someone has a plan to do that,
which strikes me as unlikely, I disagree with an implication that
including another package with this license would cause any additional
problems for Debian redistributors.

I have no problem with your other arguments against the 4-clause BSD
license.  I'm not arguing that it's a good license.  But since you were
giving advice to someone who is new to licensing issues, I wanted to
clarify that including one more package with this license would not cause
any noticable hardship for redistributors compared to what they already
would need to deal with.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#464169: ITP: vagalume -- A GTK+-based Last.fm client

[Christian Perrier]

Quoting Alberto Garcia ([EMAIL PROTECTED]):
> On Wed, Feb 06, 2008 at 05:57:21PM +0100, Christian Perrier wrote:
> 
> > > > "graphical GTK+-based client for Last.fm media service"
> > > Is it necessary to say it's graphical provided that it's based on
> > > GTK+?
> > "GTK+" is jargon..:-)
> 
> Then we'd need to change quite a few package descriptions :-)

Yes. Most package description aren't really great and forget that they
should be targeted for end users. The Developers Reference gives
numerous hints about the Right Way to write package descriptions (and
not only when it makes recommendations about syntax)

> 
> $ dpkg -l | grep -i gtk
> 
> Not to mention all other packages with similar technical words in
> their descriptions: ncurses, Qt, PHP, etc.
> 
> Also, if a user doesn't know what GTK+ is, he/she probably won't
> expect a radio player being non-graphical ...
> 
> There are very few non-graphical Last.fm clients around, Vagalume is
> not special for that :)


Let me clarify.

Saying that something is GTK-based is probably meaningful for the
average geek. It means nothing for the average user. This is what I
call jargon.

Our package descriptions should help all users to answer the simple
questions "what is this package good for?" and "Do I need this
package?"

Being GTK-based is not the most important mention for this ad we
shouldn't assume that everybody knows that it means "graphical" or
"GUI".

That doesn't necessarily mean to *remove* GTK (it has some meaning for
some of our usersand some even decide whether a package is good
for them, based on this)...but we shouldn't assume this is *enough*.

(not to mention debtags, by the way)



signature.asc
Description: Digital signature

Re: Copyright question (BSD with advertisement clause)

[Charles Plessy]

Le Wed, Feb 06, 2008 at 06:44:38PM -0800, Russ Allbery a écrit :
> Charles Plessy <[EMAIL PROTECTED]> writes:
> 
> > This example is maybe a bit artificial, but the point is that with such
> > licences in main, redistributors who use advertisement should in theory
> > read all the copyright files to check who to acknowledge. For this
> > reason, I wouldn't recommend to include this program in main.
> 
> There is already much software in Debian main with this license and other
> Debian Developers who do not agree with this and who will continue to
> include such software in Debian main.  (It is, after all specifically
> called out as a free license in the Debian Free Software Guidelines.)  So
> the practical impact for a Debian derivative of including or not including
> one more package with the four-clause BSD license is minimal.

Hi Russ,

I think that it is a bit frivolous to distribute software with
advertisment clause in main and not properly warning the redistributors,
who are the most likely persons to infringe the clause. We should
remeber that for other aspects of licencing and intellectual property
management, Debian is much more rigorous, so the presence of 4-clauses
BSD licences is contradicting the principle of least surprise, that is
usually a good guidance.

Importantly, the copyright holders of such programs are often not the
programmers themselves, but the universities, who nowardays face very
strong financial pressures and delegate more and more the management of
the intellecutal property to specialised services, who can be ran by
people who know nothing about the spirit of free software that blessed
the researchers when they wrote their programs.

This is why, as a personnal choice, I do not take the responsability of
introducing new packages with the BSD advertisement clause in Debian,
and I suggest others to refrain as well.

Anyway, I really think that there are good chances to obtain a
relicencing, that is by far the best way to find a solution that
pleases everybody.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


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

Re: Copyright question (BSD with advertisement clause)

[Russ Allbery]

Charles Plessy <[EMAIL PROTECTED]> writes:

> This example is maybe a bit artificial, but the point is that with such
> licences in main, redistributors who use advertisement should in theory
> read all the copyright files to check who to acknowledge. For this
> reason, I wouldn't recommend to include this program in main.

There is already much software in Debian main with this license and other
Debian Developers who do not agree with this and who will continue to
include such software in Debian main.  (It is, after all specifically
called out as a free license in the Debian Free Software Guidelines.)  So
the practical impact for a Debian derivative of including or not including
one more package with the four-clause BSD license is minimal.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: unknown-field-in-control homepage

[Guillem Jover]

Hi,

On Wed, 2008-02-06 at 20:23:37 +0100, Jonas Meurer wrote:
> On 06/02/2008 Russ Allbery wrote:
> > > I'm not sure whether this is an issue with dpkg or rather with lintian,
> > > but if I check the cryptsetup deb+udeb packages after building them,
> > > lintian reports that udebs don't allow the Homepage field in
> > > debian/control.
> > 
> > This is what I was told by (a d-i maintainer | someone who was willing to
> > express an opinion).  I'm happy to change lintian if having Homepage in
> > udeb is deemed acceptable.  Otherwise, dpkg should probably be modified to
> > not propagate Homepage fields into udebs.
> 
> I raised this issue on #debian-boot (irc), and was told that the
> concerns by "(a d-i maintainer | someone who was willing to express an
> opinion" were correct. Frans Pop from the debian-installer team verified
> that the Homepage field should not be included in the udeb:
> 
> 20:11 < mejo> fjp: did you see Russ's response to my question regarding
>   Homepage Field in udebs?
> 20:11 < mejo> fjp: i mean on [EMAIL PROTECTED]
> [...]
> 20:12 < fjp> mejo: Please file a bug against dpkg-dev.
> 20:14 < fjp> mejo: Russ is correct: we don't want the homepage field in
>  the control file of udebs
> 
> 
> If nobody has any objections, i'll follow Frans' advice and file a bug
> against dpkg-dev.

Yes, makes sense. I've just fixed it in dpkg's git [0].

regards,
guillem

[0] 


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

Re: Copyright question (BSD with advertisement clause)

[Charles Plessy]

Le Wed, Feb 06, 2008 at 04:30:01PM +0100, Jean Parpaillon a écrit :
>  
>  3. All  advertising  materials  mentioning  features  or  use of this
>  software must display the following acknowledgement:
>  This  product  includes  software  developed  at  the  University  of
>  Tennessee, Knoxville, Innovative Computing Laboratories.

Bonjour Jean,

This is the "advertisement clause" of the original BSD licence. Some
works in main are or were distributed under this clause, so it is
considered DFSG-Free.

However, distributors of Debian can easily infringe this clause: for
instance, if an hypothetical magazine, "Clusterised Linux" would sell an
issue with a DVD of Debian Lenny and advertise it with a slogan such as
"Debian Lenny: faster with upgraded kernel and HPL memory distribution",
the university of Tenessee could obviously claim that the licence has
not been respected because their name has not been cited.

This example is maybe a bit artificial, but the point is that with such
licences in main, redistributors who use advertisement should in theory
read all the copyright files to check who to acknowledge. For this
reason, I wouldn't recommend to include this program in main.

But there is a much better solution. The problem has been well explained
on FSF's website: http://www.gnu.org//philosophy/bsd.html and
importantly, the university of Berkeley from which this licence
originates has now abandonned the advertisement clause. This is a strong
argument, and with it I was able to obtain the relicencing of a
4-clause-BSD-licenced program by the Whitehead Institute. I think that
you have your chances with the university of Tenessee.

Have a nice day,

-- 
Charles Plessy
Debian-Med packaging team.
Wakō, Saitama, Japan


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

Re: [RFC] Changing priority of selinux back to optional

[Erich Schubert]

Hi everyone,
There is no real "SELinux team" anymore that could say yes or no to
anything I figure. The SELinux people at Debian were mostly Manoj, RJC
and myself. I havn't heard anything from Manoj in months, I'm not able
to do any actual SELinux work anymore and while RJC updated his SELinux
Demo machine (http://www.coker.com.au/selinux/play.html) at some point,
I havn't heard any plans from hin to 'revive' SELinux in Debian, but he
is actively advocating SELinux and actively blogging:
  http://etbe.coker.com.au/tag/selinux/
and he has some somewhat-updated packages in his repository:
  http://www.coker.com.au/dists/etch/selinux
Make sure to talk to him, but other than that I'd suggest you just
hijack/NMU the relevant packages.

There is an updated policy package I did early this year at
 http://selinux.alioth.debian.org/experimental/refpolicy/
which is after the strict/targeted merge. It's also using my own
packaging, it's not based on Manojs work. He reproduced some of the
things I did in Perl, while I'm still using my python+sh code, which in
my opinion is superior in some cases I believe (I never tried his
packages!). I don't know if his module auto installation still loads one
module after the other, or if it's done in one pass like I do. I also
introduced some module guessing and upgrading (!) code I don't know if
he has yet adopted, so make sure to investigate both packages.

Make sure to also investigate the new Ubuntu efforts that Reinhard
pointed out. It would be best to join efforts here. Caleb Case is using
a tresys email address, that is where refpolicy upstream lives.

best regards,
Erich Schubert
-- 
 erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C (o_
 A man doesn't know what he knows until he knows what he doesn't know. //\
  Es lohnt sich nicht, die Augen aufzumachen,  V_/_
 wenn der Kopf im Sand steckt.


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

Re: Bug#464169: ITP: vagalume -- A GTK+-based Last.fm client

[Alberto Garcia]

On Wed, Feb 06, 2008 at 05:57:21PM +0100, Christian Perrier wrote:

> > > "graphical GTK+-based client for Last.fm media service"
> > Is it necessary to say it's graphical provided that it's based on
> > GTK+?
> "GTK+" is jargon..:-)

Then we'd need to change quite a few package descriptions :-)

$ dpkg -l | grep -i gtk

Not to mention all other packages with similar technical words in
their descriptions: ncurses, Qt, PHP, etc.

Also, if a user doesn't know what GTK+ is, he/she probably won't
expect a radio player being non-graphical ...

There are very few non-graphical Last.fm clients around, Vagalume is
not special for that :)

-- 
Alberto García González
http://people.igalia.com/berto/


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

Re: Bug#464388: RFP: alfresco -- open source enterprise content management

[Christian Perrier]

Quoting Carlos Izquierdo ([EMAIL PROTECTED]):
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
> 
>Package name: alfresco
> Version: 2.1
> Upstream Author: Alfresco Software, Inc.
> URL: http://www.alfresco.com/
> License: GPL with FLOSS exception
> Description: Alfresco is an open source enterprise content management 
> repository and portlets (CMS) built by a team that includes the co-founder of 
> Documentum. Its modular architecture uses the latest open source Java 
> technologies: Spring, Hibernate, Lucene and JSF.


You can probably drop "open source" which is obvious in a Debian
context.

I'd say that "enterprise content management" is enough for the synopsis.



signature.asc
Description: Digital signature

Re: Bug#464169: ITP: vagalume -- A GTK+-based Last.fm client

[Christian Perrier]

Quoting Alberto Garcia ([EMAIL PROTECTED]):
> On Wed, Feb 06, 2008 at 06:56:05AM +0100, Christian Perrier wrote:
> 
> > >   Description : A GTK+-based Last.fm client
> > 
> > "Last.fm" isn't really clear for anybody. I suggest using a more
> > generic description and somehow say this is related to audio/media
> > playing.
> 
> Well, you're right, I should update the full description too.
> 
> > Also drop the leading article, of course
> > 
> > "graphical GTK+-based client for Last.fm media service"
> 
> Is it necessary to say it's graphical provided that it's based on
> GTK+?


"GTK+" is jargon..:-)



signature.asc
Description: Digital signature

Re: unknown-field-in-control homepage

[Jonas Meurer]

On 06/02/2008 Russ Allbery wrote:
> > I'm not sure whether this is an issue with dpkg or rather with lintian,
> > but if I check the cryptsetup deb+udeb packages after building them,
> > lintian reports that udebs don't allow the Homepage field in
> > debian/control.
> 
> This is what I was told by (a d-i maintainer | someone who was willing to
> express an opinion).  I'm happy to change lintian if having Homepage in
> udeb is deemed acceptable.  Otherwise, dpkg should probably be modified to
> not propagate Homepage fields into udebs.

Hey,

I raised this issue on #debian-boot (irc), and was told that the
concerns by "(a d-i maintainer | someone who was willing to express an
opinion" were correct. Frans Pop from the debian-installer team verified
that the Homepage field should not be included in the udeb:

20:11 < mejo> fjp: did you see Russ's response to my question regarding
  Homepage Field in udebs?
20:11 < mejo> fjp: i mean on [EMAIL PROTECTED]
[...]
20:12 < fjp> mejo: Please file a bug against dpkg-dev.
20:14 < fjp> mejo: Russ is correct: we don't want the homepage field in
 the control file of udebs


If nobody has any objections, i'll follow Frans' advice and file a bug
against dpkg-dev.

greetings,
 jonas


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

Re: unknown-field-in-control homepage

[Russ Allbery]

Jonas Meurer <[EMAIL PROTECTED]> writes:

> I'm not sure whether this is an issue with dpkg or rather with lintian,
> but if I check the cryptsetup deb+udeb packages after building them,
> lintian reports that udebs don't allow the Homepage field in
> debian/control.

This is what I was told by (a d-i maintainer | someone who was willing to
express an opinion).  I'm happy to change lintian if having Homepage in
udeb is deemed acceptable.  Otherwise, dpkg should probably be modified to
not propagate Homepage fields into udebs.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: unknown-field-in-control homepage

[Jonas Meurer]

On 06/02/2008 Leo costela Antunes wrote:
> Jonas Meurer wrote:
> > I: cryptsetup-udeb udeb: unknown-field-in-control homepage
> 
> Quick guess: could this be a case-sensitivity issue? Should be
> "Homepage:"...

Unfortunately not. It's already 'Homepage' in debian/control. lintian
inself seems to lowercase the field.

greetings,
 jonas


signature.asc
Description: Digital signature

Re: unknown-field-in-control homepage

[Jonas Meurer]

On 06/02/2008 Barry deFreese wrote:
>> I: cryptsetup-udeb udeb: unknown-field-in-control homepage
>
> What version of lintian do you have?  That should be fixed by now.

$ lintian -V
Lintian v1.23.43

greetings,
 jonas


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

Re: [RFC] Changing priority of selinux back to optional

[maximilian attems]

On Wed, 06 Feb 2008, Stefano Zacchiroli wrote:

> On Wed, Feb 06, 2008 at 12:27:45PM +0100, maximilian attems wrote:
> > I'd like to work on SELinux packages and bugs.
> 
> That's wonderful, thanks for your help offering!
> 
> Still, if I'm interpreting correctly Frans' and Erich's mails, the
> *current* status of SELinux in Debian is, erm, sub-optimal. So I think
> Frans' request of demoting selinux related stuff priority is entirely
> reasonable, isn't it?
> 
> So I presume you have nothing against actually changing the priority
> back to optional until you're working on the various fixes. Once the
> needed bug fixes and the pending package upgrades are in place, we can
> for sure promote again the priority. What do you think?

well i haven't heard yet back from Erich yet,
so I'm waiting his response.
cc'ing him diretly now ;)

but currently willing to work on i'd nack fjp requests.
of course if no progress has been made in a month,
his request is more then reasonable.
 
best regards

-- 
maks

ps keep me on response on cc, thanks.


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

Re: unknown-field-in-control homepage

[Leo "costela" Antunes]

Jonas Meurer wrote:
> I: cryptsetup-udeb udeb: unknown-field-in-control homepage

Quick guess: could this be a case-sensitivity issue? Should be
"Homepage:"...

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: unknown-field-in-control homepage

[Barry deFreese]

Jonas Meurer wrote:

Hello,

I'm not sure whether this is an issue with dpkg or rather with lintian,
but if I check the cryptsetup deb+udeb packages after building them,
lintian reports that udebs don't allow the Homepage field in
debian/control.

If I got it right, the Homepage field belongs to the Source section of
debian/control, so I see no way to keep it out of the udeb.

Here's the exact lintian message:

$ lintian -i -I cryptsetup_1.0.6~pre1+svn45-2_amd64.changes
I: cryptsetup-udeb udeb: unknown-field-in-control homepage
N:
N:   See the Policy Manual for a list of the possible fields in a binary
N:   package control file.
N:
N:   In udeb packages the fields pre-depends, conflicts, essential and
N:   suggests are disallowed, but they can contain the new fields
N:   subarchitecture and installer-menu-item.
N:
N:   Refer to Policy Manual, section 5.3 for details.
N:

what shall I do about that?

greetings,
 jonas

  

What version of lintian do you have?  That should be fixed by now.

Thanks,

Barry deFreese


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

unknown-field-in-control homepage

[Jonas Meurer]

Hello,

I'm not sure whether this is an issue with dpkg or rather with lintian,
but if I check the cryptsetup deb+udeb packages after building them,
lintian reports that udebs don't allow the Homepage field in
debian/control.

If I got it right, the Homepage field belongs to the Source section of
debian/control, so I see no way to keep it out of the udeb.

Here's the exact lintian message:

$ lintian -i -I cryptsetup_1.0.6~pre1+svn45-2_amd64.changes
I: cryptsetup-udeb udeb: unknown-field-in-control homepage
N:
N:   See the Policy Manual for a list of the possible fields in a binary
N:   package control file.
N:
N:   In udeb packages the fields pre-depends, conflicts, essential and
N:   suggests are disallowed, but they can contain the new fields
N:   subarchitecture and installer-menu-item.
N:
N:   Refer to Policy Manual, section 5.3 for details.
N:

what shall I do about that?

greetings,
 jonas


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

ITP: opencascade -- CAE platform library and scripting engine

[Adam C Powell IV]

Package: wnpp
Severity: wishlist

Package name: opencascade
Version: 6.2.0
Author: Open Cascade SAS (OCC), a French software services company
URL: http://www.opencascade.org/
License: Open CASCADE Technology Public License, includes triangle with 
non-free source
Description: CAE platform library and scripting engine

Greetings,

I am packaging OpenCASCADE, a powerful computer-aided engineering (CAE)
platform library and scripting engine.  It includes computer-aided
design (CAD) and visualization features, as well as some meshing for
analysis.  It also comes with its own scripting engine.

The license appears to be free, though upstream interprets it as
non-free, and the source includes the non-free "triangle" program.  See
http://lists.debian.org/debian-legal/2007/12/msg00066.html for details.

The current package is at http://lyre.mit.edu/~powell/opencascade/ .  I
plan to split the package using Jason Kraftcheck's scripts (see
http://lists.debian.org/debian-science/2008/01/msg00013.html and
http://lists.debian.org/debian-science/2008/01/msg00024.html for
details) before uploading.

This is a build-depend for Salomé which I ITP'd (bug 457075).

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


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

Re: Copyright question

[Cyril Brulebois]

On 06/02/2008, Sebastian Harl wrote:
> Just to make this clear […]

Yep, thank you (all) for clarifying that, sorry for the inconvenience.

Cheers,

-- 
Cyril Brulebois


pgpFkxYGMPJdq.pgp
Description: PGP signature

Re: [RFC] Changing priority of selinux back to optional

[Václav Ovsík]

Hi,
I'm not DD, but I'm very interested into SELinux on Debian (but must to
say - not a guru for SELinux yet :).

I'm experimenting with latest SELinux code on Etch, so if this staff can
be worth for anyone...

http://linux.i.cz/debian/dists/selinux-etch/

Packages are a bit hairy (changelogs). I rewrite packaging using CDBS
somewhere, which maybe is not acceptible for maintainer (Manoj).
Some packages are simply backports from Sid, some are upgraded (e.g. pam
is 0.99.9.0).
There is no package for policy yet, because this is (as Erich S. writes)
long run.
Everything is highly experimental :).

Cheers
-- 
Zito


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

Re: Bug#464169: ITP: vagalume -- A GTK+-based Last.fm client

[Alberto Garcia]

On Wed, Feb 06, 2008 at 09:59:30AM +0100, Alberto Garcia wrote:

> > Also drop the leading article, of course
> > "graphical GTK+-based client for Last.fm media service"
> 
> Is it necessary to say it's graphical provided that it's based on
> GTK+?
> 
> How about ...
> 
> "Graphical GTK+-based client for the Last.fm online radio"

Sorry, I forgot to remove the redundant 'Graphical':

"GTK+-based client for the Last.fm online radio"

or

"GTK+-based client for the Last.fm online radio and social network"

-- 
Alberto García González
http://people.igalia.com/berto/


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

Re: [update] Automatic mirror selection - feedback appreciated

[Leo "costela" Antunes]

[setting MFT to avoid OT discussion on -mirror]

Raphael Geissert wrote:
> PD. What do you think about adding a built-in list of addresses which 'work'
> for OpenDNS so they are excluded and some kind of http redirection is used
> instead?

It's a possibility, but I had envisioned something simpler. IMHO this
falls under the "user knows better than to use an automated system"
scenario, for people that would probably be picking their mirrors
manually anyway. I don't know of any ISP that uses off-shore DNS
resolvers, so people that do this are probably already changing it manually.
But of course, I'm open for discussion if people think this is a worthy
workaround (and you're also free get the script yourself and provide
some patches ;) ).

Cheers and thanks for the feedback!

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Bug#464392: ITP: libdebian-package-make-perl -- Perl extension for autobuilding Debian packages

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: libdebian-package-make-perl
  Version : 0.01
  Upstream Author : myself
* URL or Web page : not published yet
* License : GPL2+
  Description : Perl extension for autobuilding Debian packages

Debian::Package::Make is a module that aims to simplify the necessary
steps for completely automated builds of Debian packages and to
provide a sound base for make-*-package scripts.

This is useful for source distributions where contents change rapidly
or where peculiar licenses prohibit redistribution via public package
repositories.



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

Re: Copyright question

[Bas Zoetekouw]

Hi Jean!

You wrote:

> I intend to package HPL benchmarks. Copyright file contains the
> following statements:
> --
>  1. Redistributions  of  source  code  must retain the above copyright
>  notice, this list of conditions and the following disclaimer.   
>  
>  2. Redistributions in binary form must reproduce  the above copyright
>  notice, this list of conditions,  and the following disclaimer in the
>  documentation and/or other materials provided with the distribution.
>  
>  3. All  advertising  materials  mentioning  features  or  use of this
>  software must display the following acknowledgement:
>  This  product  includes  software  developed  at  the  University  of
>  Tennessee, Knoxville, Innovative Computing Laboratories.
>  
>  4. The name of the  University,  the name of the  Laboratory,  or the
>  names  of  its  contributors  may  not  be used to endorse or promote
>  products  derived   from   this  software  without  specific  written
>  permission.  
> 
> 
> I've read DFSG and I'm not sure if items 3 and 4 are problematic. Can
> someone help me ? If it's not ok, may it be in contrib ?

Why is that probematic?  It seems like a default 4-clause BSD license to
me.  Should be fine, unless you intend to link it against GPL code.

Kind regards,
Bas.

-- 
+--+
| Bas Zoetekouw  | Sweet day, so cool, so calm, so bright, |
|| The bridall of the earth and skie:  |
| [EMAIL PROTECTED]  | The dew shall weep thy fall tonight;|
+|For thou must die.   |
 +-+


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

Re: Copyright question

[Sebastian Harl]

Hi,

On Wed, Feb 06, 2008 at 04:46:23PM +0100, Cyril Brulebois wrote:
> On 06/02/2008, Jean Parpaillon wrote:
> >  3. All  advertising  materials  mentioning  features  or  use of this
> >  software must display the following acknowledgement:
> >  This  product  includes  software  developed  at  the  University  of
> >  Tennessee, Knoxville, Innovative Computing Laboratories.
> >
> >  4. The name of the  University,  the name of the  Laboratory,  or the
> >  names  of  its  contributors  may  not  be used to endorse or promote
> >  products  derived   from   this  software  without  specific  written
> >  permission.
> > 
> >
> > I've read DFSG and I'm not sure if items 3 and 4 are problematic. Can
> > someone help me ? If it's not ok, may it be in contrib ?
> 
> See http://wiki.debian.org/DFSGLicenses, BSD-3 (without point 3.)
> isn't a problem.
> 
> The advertising requirement (3.) is a problem, though.

Just to make this clear: the 4-clause BSD license is not a problem in
respect to DFSG-freeness - it's perfectly fine to include BSD 4-clause
licensed software in Debian. However, the license is incompatible to the
GPL, so you may not mix BSD 4-clause and GPL code.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#464388: RFP: alfresco -- open source enterprise content management

[Carlos Izquierdo]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: alfresco
Version: 2.1
Upstream Author: Alfresco Software, Inc.
URL: http://www.alfresco.com/
License: GPL with FLOSS exception
Description: Alfresco is an open source enterprise content management 
repository and portlets (CMS) built by a team that includes the co-founder of 
Documentum. Its modular architecture uses the latest open source Java 
technologies: Spring, Hibernate, Lucene and JSF.



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

Re: Copyright question

[Stephen Gran]

This one time, at band camp, Cyril Brulebois said:
> On 06/02/2008, Jean Parpaillon wrote:
> >  3. All  advertising  materials  mentioning  features  or  use of this
> >  software must display the following acknowledgement:
> >  This  product  includes  software  developed  at  the  University  of
> >  Tennessee, Knoxville, Innovative Computing Laboratories.
> >
> >  4. The name of the  University,  the name of the  Laboratory,  or the
> >  names  of  its  contributors  may  not  be used to endorse or promote
> >  products  derived   from   this  software  without  specific  written
> >  permission.
> > 
> >
> The advertising requirement (3.) is a problem, though.

No.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Copyright question

[brian m. carlson]

[Please follow up to -legal only.  Full quote for the benefit of -legal.]

On Wed, Feb 06, 2008 at 04:30:01PM +0100, Jean Parpaillon wrote:

Hi,
I intend to package HPL benchmarks. Copyright file contains the
following statements:
--
1. Redistributions  of  source  code  must retain the above copyright
notice, this list of conditions and the following disclaimer.   

2. Redistributions in binary form must reproduce  the above copyright

notice, this list of conditions,  and the following disclaimer in the
documentation and/or other materials provided with the distribution.

3. All  advertising  materials  mentioning  features  or  use of this
software must display the following acknowledgement:
This  product  includes  software  developed  at  the  University  of
Tennessee, Knoxville, Innovative Computing Laboratories.

4. The name of the  University,  the name of the  Laboratory,  or the

names  of  its  contributors  may  not  be used to endorse or promote
products  derived   from   this  software  without  specific  written
permission.  



I've read DFSG and I'm not sure if items 3 and 4 are problematic. Can
someone help me ? If it's not ok, may it be in contrib ?


This is a standard BSD-with-advertising-clause, so yes, this is 
DFSG-free.  Only DFSG-free material may go in main or contrib; material 
that does not meet the DFSG must go in non-free.  Also note that due to 
the advertising clause (clause 3), this license is not compatible with 
the GPL.


In future, please post questions about copyright and licenses to -legal, 
where the regulars are well versed.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Copyright question

[Cyril Brulebois]

On 06/02/2008, Jean Parpaillon wrote:
>  3. All  advertising  materials  mentioning  features  or  use of this
>  software must display the following acknowledgement:
>  This  product  includes  software  developed  at  the  University  of
>  Tennessee, Knoxville, Innovative Computing Laboratories.
>
>  4. The name of the  University,  the name of the  Laboratory,  or the
>  names  of  its  contributors  may  not  be used to endorse or promote
>  products  derived   from   this  software  without  specific  written
>  permission.
> 
>
> I've read DFSG and I'm not sure if items 3 and 4 are problematic. Can
> someone help me ? If it's not ok, may it be in contrib ?

See http://wiki.debian.org/DFSGLicenses, BSD-3 (without point 3.)
isn't a problem.

The advertising requirement (3.) is a problem, though.

Note that if a package isn't DFSG-free, it can't go to contrib either.
Contrib is for DFSG-free material depending on non-free (or contrib in
turn) stuff, see Policy 2.2.2.

Cheers,

-- 
Cyril Brulebois


pgpCQ2mURhche.pgp
Description: PGP signature

Copyright question

[Jean Parpaillon]

Hi,
I intend to package HPL benchmarks. Copyright file contains the
following statements:
--
 1. Redistributions  of  source  code  must retain the above copyright
 notice, this list of conditions and the following disclaimer.   
 
 2. Redistributions in binary form must reproduce  the above copyright
 notice, this list of conditions,  and the following disclaimer in the
 documentation and/or other materials provided with the distribution.
 
 3. All  advertising  materials  mentioning  features  or  use of this
 software must display the following acknowledgement:
 This  product  includes  software  developed  at  the  University  of
 Tennessee, Knoxville, Innovative Computing Laboratories.
 
 4. The name of the  University,  the name of the  Laboratory,  or the
 names  of  its  contributors  may  not  be used to endorse or promote
 products  derived   from   this  software  without  specific  written
 permission.  


I've read DFSG and I'm not sure if items 3 and 4 are problematic. Can
someone help me ? If it's not ok, may it be in contrib ?

Regards,
Jean

-- 
Nul ne sera condamné pour des actions ou omissions qui, au moment où elles ont 
été commises, ne constituaient pas un acte délictueux d'après le droit national 
ou international. De même, il ne sera infligé aucune peine plus forte que celle 
qui était applicable au moment où l'acte délictueux a été commis.
Article 11.2. Déclaration Universelle des Droits de l'Homme
-
No one shall be held guilty of any penal offence on account of any act or 
omission which did not constitute a penal offence, under national or 
international law, at the time when it was committed. Nor shall a heavier 
penalty be imposed than the one that was applicable at the time the penal 
offence was committed.
Article 11.2. Universal Declaration of Human Rights

begin:vcard
fn:Jean Parpaillon
n:Parpaillon;Jean
org:Kerlabs
adr:;;;Rennes;;;France
email;internet:[EMAIL PROTECTED]
tel;work:+33 2 99 84 25 99
tel;cell:+33 6 80 32 73 85
version:2.1
end:vcard



signature.asc
Description: OpenPGP digital signature

Re: Standardisation of the name of the patching targets included in debian/rules.

[Stefano Zacchiroli]

On Wed, Feb 06, 2008 at 02:34:58PM +, Gerrit Pape wrote:
> > So please go for patch/unpatch.
> 
> An unpatch target might be problematic.  There're packages with patches
> that touch the upstream Makefile, and calling 'make unpatch' before
> 'make clean' can break things; of course the clean target can depend on

Then just make unpatch depends on clean.

Anyhow, we were discussing naming here, that is the API for the package
maintainer to implement, while you seem to dig into details on how the
proposed target names should be internally implemented ...

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Bug#464169: ITP: vagalume -- A GTK+-based Last.fm client

[Alberto Garcia]

On Wed, Feb 06, 2008 at 06:56:05AM +0100, Christian Perrier wrote:

> >   Description : A GTK+-based Last.fm client
> 
> "Last.fm" isn't really clear for anybody. I suggest using a more
> generic description and somehow say this is related to audio/media
> playing.

Well, you're right, I should update the full description too.

> Also drop the leading article, of course
> 
> "graphical GTK+-based client for Last.fm media service"

Is it necessary to say it's graphical provided that it's based on
GTK+?

How about ...

"Graphical GTK+-based client for the Last.fm online radio"

Thanks for your suggestions

-- 
Alberto García González
http://people.igalia.com/berto/


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

Re: [RFC] Changing priority of selinux back to optional

[David Paleino]

Il giorno Wed, 6 Feb 2008 12:27:45 +0100
maximilian attems <[EMAIL PROTECTED]> ha scritto:

> 
> > The priority of selinux packages was changed from optional to standard, 
> > fairly shortly before the release of Etch.
> > 
> > I propose to revert that change before Lenny. The basic reason is that
> > the selinux packages have basically been unmaintained since the release
> > of Etch.
> 
> I'd like to work on SELinux packages and bugs.

Can't one just file NMUs and upload them to DELAYED/*?

David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Standardisation of the name of the patching targets included in debian/rules.

[Gerrit Pape]

On Sun, Feb 03, 2008 at 08:14:35PM +0100, Stefano Zacchiroli wrote:
> On Sun, Feb 03, 2008 at 11:10:41AM +0100, Martin Quinson wrote:
> > I find personnaly patch/unpatch more easy to understand, but YMMV...
> 
> I think (hope) that no one will be able to find a reason why the two
> target should *not* be called "patch" / "unpatch". They are IMO the only
> 2 that people will be able to guess out of the blue.
> 
> So please go for patch/unpatch.

An unpatch target might be problematic.  There're packages with patches
that touch the upstream Makefile, and calling 'make unpatch' before
'make clean' can break things; of course the clean target can depend on
patch, but this seems to complicate things.  Why not simply do the
unpatch in the clean target?

This is what I use in packages I maintain:

patch: deb-checkdir patch-stamp
patch-stamp:
for i in `ls -1 debian/diff/*.diff || :`; do \
  patch -p1 <$$i || exit 1; \
done
touch patch-stamp

clean: deb-checkdir deb-checkuid
$(MAKE) clean $(OPTS)
test ! -e patch-stamp || \
  for i in `ls -1r debian/diff/*.diff || :`; do patch -p1 -R <$$i; done
rm -f patch-stamp [...]

Regards, Gerrit.


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

Re: [update] Automatic mirror selection - feedback appreciated

[Leo "costela" Antunes]

Michal Čihař wrote:
> This server was the place where I tried the lookup and it is really in
> Czech. It has own DNS server which does not use any proxy and I flushed
> it's cache before each attempt. Just tested it again to be sure:

[snip]

> Okay let's try it also another way - ask directly your server without
> anything on the way. It seems that last reply is somehow cached even 
> for different source addresses. If I do query first here in Japan and 
> then over there in Czech, I get few results pointing to Japan mirror 
> before it updates to Czech one. The same happens when I then start 
> resolving in Japan - I get again the Czech server on first attempts.
> Log follows, the time difference 8 hours is time zone shift:

Are you sure there's no redirection of port 53 going on there? Or
perhaps a load-balancing between two separate outbound IPs (one of which
could be wrong in the GeoIP database)? I don't mean to say you don't
know how your servers work, it's just that this seems a bit odd, given
that nobody else reported similar problems and how simple the setup is.

I don't think it's a cache problem on PDNS, firstly because it doesn't
seem to be caching anything (based on log output) and secondly because
the answer is changing between requests inside a small time-frame. But I
could be wrong.

Can you hop on to IRC to coordinate some queries while I watch the log?


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: [RFC] Changing priority of selinux back to optional

[Stefano Zacchiroli]

On Wed, Feb 06, 2008 at 12:27:45PM +0100, maximilian attems wrote:
> I'd like to work on SELinux packages and bugs.

That's wonderful, thanks for your help offering!

Still, if I'm interpreting correctly Frans' and Erich's mails, the
*current* status of SELinux in Debian is, erm, sub-optimal. So I think
Frans' request of demoting selinux related stuff priority is entirely
reasonable, isn't it?

So I presume you have nothing against actually changing the priority
back to optional until you're working on the various fixes. Once the
needed bug fixes and the pending package upgrades are in place, we can
for sure promote again the priority. What do you think?

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: [RFC] Changing priority of selinux back to optional

[maximilian attems]

> The priority of selinux packages was changed from optional to standard, 
> fairly shortly before the release of Etch.
> 
> I propose to revert that change before Lenny. The basic reason is that
> the selinux packages have basically been unmaintained since the release
> of Etch.

I'd like to work on SELinux packages and bugs.
SELinux is doing great proactive security and I'd like
to help the Debian harden team. SELinux is currently the
most superior security policy and latest kernel see several
scalability fixes.

so asking if the SELinux team is ok with adding me as co-maintainer?
thanks Erich for your concise posting on where the work needs
to be picked up!

best regards

-- 
maks


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

Re: How to cope with patches sanely --> Debian New Maintainers'

[Matthew Johnson]

On Wed Feb 06 12:09, Patrick Schoenfeld wrote:
> Hi Pierre,
> 
> On Tue, Feb 05, 2008 at 09:17:12PM +0100, Pierre Habouzit wrote:
> >   Again, the discussion isn't (for me) about a tool, but an exchange
> > format. We are discussing having patches served in a quilt series, and
> 
> okay, this approach is similar but different. So you want a quilt
> series, but not quilt. This means every other utility must be able to
> generate this and must support every future quilt has, which itself may
> not have. So, effectively you don't actively force them to use sth. but
> passiveley you do. The difference is small however.

I'd have said that it would be more sensible to define a reasonable subset
of quilt features. A set of patches with comments at the top and a
series file can be manipulated by many tools, isn't really
quilt-specific. Allowing obscure quilt-only features wasn't what I'd
understood from the discussion.

Anyway, given that many VCSen seem to be gaining quilt-compatible
interfaces, it doesn't really seem like forcing people to use quilt.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Intend to hijack rrdtool

[Matthias Urlichs]

Hi,

Bernd Zeimetz:
> as rrdtool is a vital part of a lot of system monitoring solutions and
> should not go into Lenny in its current unmaintained state, I intend to
> hijack it.
> 
Do it.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
TAIL RECURSION n. See TAIL RECURSION.
-- From the AI Hackers' Dictionary


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

Re: How to cope with patches sanely --> Debian New Maintainers' Guide

[Patrick Schoenfeld]

Hi Pierre,

On Tue, Feb 05, 2008 at 09:17:12PM +0100, Pierre Habouzit wrote:
>   Again, the discussion isn't (for me) about a tool, but an exchange
> format. We are discussing having patches served in a quilt series, and

okay, this approach is similar but different. So you want a quilt
series, but not quilt. This means every other utility must be able to
generate this and must support every future quilt has, which itself may
not have. So, effectively you don't actively force them to use sth. but
passiveley you do. The difference is small however.

> let people adapt their tools to be able to export their work as a quilt
> series so that other can find it and import it in their own tool of
> choice if needed.

But I am nitpicking. Call it "defining a common interface", while I call
it "decide on quilt as a common patch system". That does not matter.
What matters is that we give up a little diversity for some more
efficience.

>   Enforcing maintenance tools is A Bad Idea™. The difference is huge:
> having common interfaces means that there is One True Tool that everyone
> can use if he doesn't know the Real Tools the Maintainer uses (apt-get
> source versus $SCM clone/checkout/whatever).

That are different solutions to different problems. apt-get source only
fetches finished (release, uploaded) source packages, while $SCM
clone/checkout/whatever fetches the history of the package including the
snapshot of it when doing the checkout. The common interface for $SCM
would more likely be debcheckout imo.

Regards,
Patrick


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

Re: Bug#464159: ITP: ktsuss -- gtk wrapper for su

[Christian Perrier]

Quoting Yves-Alexis ([EMAIL PROTECTED]):
> Package: wnpp
> Severity: wishlist
> Owner: [EMAIL PROTECTED]
> 
> 
> * Package name: ktsuss
>   Version : 1.2
>   Upstream Author : David B. Cortarello <[EMAIL PROTECTED]>
> * URL : http://developer.berlios.de/projects/ktsuss
> * License : BSD
>   Programming Lang: C
>   Description : gtk wrapper for su

s/gtk/GTK?

Possible alternative: "graphical wrapper for su" and keep reference to
GTK in the long description.




signature.asc
Description: Digital signature