Re: Request: Source for parts of GNU/Solaris

[Bill Gatliff]

Anthony:

Loved your "for those of you following at home" post.


As is "pressing" people. You can justify hostility, certainly; but it's
at least worth trying "honest and cooperative" as an approach first.
 



It didn't start out that way, not as I read it anyway.


When you see some code that's not available under the GPL's terms,
what's your reaction:
 



My reaction is that the author is entitled to make his work products 
available under any license he chooses.


That isn't what's going on here, though.  As far as I can tell, Erast is 
completely disregarding the legitimate rights of the copyright holders 
of the software he's shipping with his system.  That isn't "some code 
that's not available under the GPL", that's "theft".



And, I mean, seriously: using the threat of legal action to make people
remove free software from the Internet? Whose side are we on here?
 



No.  The threat of legal action to stop the theft of Free software.  Big 
difference.


Erast hasn't done *anything* to address or even acknowledge the CDDL/GPL 
compatibility issue.  His system as currently implemented clearly 
depends on linking CDDL works with GPL works.  The authors of the 
software he's distributing with his system haven't given him permission 
to do that.  Quite simple, actually.


To be fair, I must admit that I'm not a DD and I don't hold copyright to 
any of Erast's software.  But I believe strongly in the way Debian does 
things, and I use a *lot* of Debian software in my work.  So I justify 
my participation in this thread based on my interest in protecting 
Debian's interests.




b.g.

--
Bill Gatliff
[EMAIL PROTECTED]


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

Bug#338272: ITP: libpoe-filter-ircd-perl -- a POE-based parser for the IRC protocol

[Steve Kowalik]

Package: wnpp
Severity: wishlist

* Package name: libpoe-filter-ircd-perl
  Version : 1.2-1
  Upstream Author : Jonathan Steinert, now Chris Williams <[EMAIL PROTECTED]>
* URL or Web page : http://search.cpan.org/~bingos/POE-Filter-IRCD-1.2/
* License : GPL/Artistic

  Description : a POE-based parser for the IRC protocol
 POE::Filter::IRCD provides a convient way of parsing and creating IRC
 protocol lines using the Perl Object Environment (POE) framework.

This package is firstly needed for the new upstream of
POE::Component::IRC and will be uploaded tonight (my time), unless I
hear any serious objections.

Cheers,
-- 
Steve
"E-mail is for geeks and paedophiles."
 - Sebastian, Cruel Intentions


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

Re: Request: Source for parts of GNU/Solaris

[Anthony Towns]

On Tue, Nov 08, 2005 at 08:55:41PM -0600, Kenneth Pronovici wrote:
> You'll note that even in the initial part of the thread when Debian
> folks were (generally) being polite, 

From the very first response:

] > and openness.
] You keep using that word.  I do not think it means, what you think it
] means.
..
] Not to poop on your parade, but please, next time you go to announce
] something to a technical list like d-devel -- drop the marketing guff,
] just stick to the useful info.

 -- http://lists.debian.org/debian-devel/2005/11/msg00052.html

Further on in that subthread, after Erast extolls the virtues of
OpenSolaris, there's Hamish's take:

] Why would this be of interest to Debian developers?
..
] I read all of your points as criticisms of Linux. That is
] disappointing.

 -- http://lists.debian.org/debian-devel/2005/11/msg00073.html

Second top level response was Florian's:

] How do you solve the problem that you cannot legally distribute
] software which is licensed under the GNU General Public License and is
] linked against a libc which is covered by the CDDL?  Have you ported
] GNU libc?
..
] This web site requires authentication.
..
] You should drop all references to the "Solaris" trademark because
] Sun's terms of use are anything but open (worse than Debian's).  And
] of course, compliance with the GPL in all aspects is very desirable,
] too.

 -- http://lists.debian.org/debian-devel/2005/11/msg00065.html

Does the above sound more like something fun you'd like to hack on with
a coworker, or a complaint from a manager who just doesn't "get it"?

Third top level response was Michael Banck's, which was mostly positive,
then, but the rest of that subthread covered licensing problems,
devolving into the exchange "The question is, are you going to pursue
a legal action against Sun Microsystems?" "To which my answer was "yes".".

> many of Erast's responses were at best antagonistic, 
> and at worst showed a complete disregard for what Debian is all about.  

Speaking of antagonistic...

> This strikes me as a rather poor way to start a
> relationship with someone, especially when you've just based most of
> your userspace on that someone's source code.

That's a very proprietary attitude about source code, don't you think?

Cheers,
aj


signature.asc
Description: Digital signature

Re: Request: Source for parts of GNU/Solaris

[Thomas Bushnell BSG]

Anthony Towns  writes:

> When you see some code that's not available under the GPL's terms,
> what's your reaction:
>
> (a) gosh, what can I do to convince the author to give it to me
> under the GPL?
>
> (b) you aren't/shouldn't be allowed to do that. stop now.
>
> (c) *shrug*

My reaction is a combination of (a) and (b).  However, the problem is
that we were speaking to people who cannot relicense the software in
question.  So (a) isn't an option.

Thomas


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

Re: Request: Source for parts of GNU/Solaris

[Anthony Towns]

On Wed, Nov 09, 2005 at 02:23:30AM +, Matthew Garrett wrote:
> Anthony Towns  wrote:
> > I'm amazed at the level of intolerence that's greeting a pretty major
> > contribution to the free software community. There are, what, five major
> > OS/kernels for PCs/workstatsions these days -- Windows, OS X, Solaris,
> > BSD and Linux. How does it make any sense at all to be hostile to the
> > fact that now four out of those five are free at their core?
> I would love a viable Debian-based Solaris system, and I think it's
> absolutely wonderful that we have so much software available under free
> licenses. But the CDDL/GPL issue is a big one,

For those playing along at home, the CDDL isn't GPL compatible, and
OpenSolaris's libc is CDDL'ed -- so anything GPLed can't link to libc
since that would violate 3(a) [0]. The reason GPL'ed software is okay
for regular Solaris is the "major components" exception, but that only
applies if those components don't "accompan[y] the executable".

So there're three fairly simple ways around that issue:

  (a) go the www.sunfreeware.com route, and have a separate repository
  for GPLed stuff. This has arguably worked for Debian in the past,
  with Qt distributed on the main site, and KDE distributed
  externally. It's not very good though.

  (b) get the OpenSolaris libc relicensed to something GPL compatible;
  this might be plausible depending on whether the rationale for the
  CDDL ("initially we will not be able to release the source
  for all of Solaris") applies to the libc code or not; it's
  possible that it doesn't. Debian's obviously had success with
  this in the past.

  (c) get glibc working on OpenSolaris, and make it fairly easy to
  choose whether to build with OpenSolaris's libc or GNU's libc,
  eg by having "sol-gcc" build with the former and "gcc" with the
  latter. Debian already supports multiple libc's (cf, dietlibc),
  so this oughtn't to be very challenging, at least after any work
  to get glibc working on OpenSolaris.

Heck, as far as (a) goes, if Nexenta wanted to setup a minimal
distribution of just the kernel and libs, without all the l33t GNU stuff
that'd probably allow Debian to distribute the rest of it. The caveat to
doing that for regular Solaris or Windows is the "We will never make the
system require the use of a non-free component", which wouldn't apply
in this case.

The issue's not really that difficult -- its like has been solved before
repeatedly -- and making it into a bigger issue than it is doesn't
really help anyone. For comparison, the GNOME Project launched in August
'97, noting problems with the KDE/Qt mix [1], it then took Debian 'til
September '98 to get serious about pulling it [2], which then happened
a month later [3].

Cheers,
aj

[0] Presuming the FSF's claims about dynamic linking hold up in this
case, anyway.
[1] http://lwn.net/2001/0816/a/gnome.php3
[2] http://lists.debian.org/debian-devel/1998/09/msg00285.html
[3] http://www.debian.org/News/1998/19981008


signature.asc
Description: Digital signature

Re: Request: Source for parts of GNU/Solaris

[Anthony Towns]

On Tue, Nov 08, 2005 at 08:29:31PM -0600, Bill Gatliff wrote:
> I think that in this instant case, the "hostility" is the allegation 
> that a Debian-based "GNU/Solaris" system as described by Erast isn't 
> possible.  

Of course it's possible. Trivially: you do it by buying a majority of
shares in all the companies that own rights to OpenSolaris, and rerelease
it under the GPL. There are far easier ways than that available, too.

Telling someone that what they're trying to achieve is "impossible"
is generally hostile in any case, in the sense of "marked by features
that oppose constructive treatment or development". How do you go from
"sorry, can't be done." to constructive development?

> Even when pressed, Erast hasn't addressed the CDDL/GPL 
> incompatibility issue.  

As is "pressing" people. You can justify hostility, certainly; but it's
at least worth trying "honest and cooperative" as an approach first.

> I don't see it as hostility, I see it as an attempt to enforce the GPL.

When you see some code that's not available under the GPL's terms,
what's your reaction:

(a) gosh, what can I do to convince the author to give it to me
under the GPL?

(b) you aren't/shouldn't be allowed to do that. stop now.

(c) *shrug*

I'd expect a free software supporter to choose some variation on one of
those; and a free software advocate to choose one of the first two. Of
those two, I think the first is much more effective.

And, I mean, seriously: using the threat of legal action to make people
remove free software from the Internet? Whose side are we on here?

Cheers,
aj



signature.asc
Description: Digital signature

Re: Request: Source for parts of GNU/Solaris

[Kenneth Pronovici]

On Wed, Nov 09, 2005 at 11:39:20AM +1000, Anthony Towns wrote:
> I'm amazed at the level of intolerence that's greeting a pretty major
> contribution to the free software community. There are, what, five major
> OS/kernels for PCs/workstatsions these days -- Windows, OS X, Solaris,
> BSD and Linux. How does it make any sense at all to be hostile to the
> fact that now four out of those five are free at their core?

I don't mean to excuse the near-hostility that's evident now, and I
agree that we should give OpenSolaris some time to get everything
straightened out (that's only fair).  However, I suspect that if the
original announcement and subsequent conversation had been handled a
little better on the OpenSolaris side, Debian people would have been
more willing to cut them some slack.  

You'll note that even in the initial part of the thread when Debian
folks were (generally) being polite, many of Erast's responses were at
best antagonistic, and at worst showed a complete disregard for what
Debian is all about.  This strikes me as a rather poor way to start a
relationship with someone, especially when you've just based most of
your userspace on that someone's source code.

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Request: Source for parts of GNU/Solaris

[Adam Heath]

On Tue, 8 Nov 2005, Erast Benson wrote:

> > The source and binaries *must* match, period.  You can't have tarballs
> > being
> > constantly upgraded, and the binaries not, or vice versa.  The
> > source+binary
> > must be done as a whole unit.
> >
> > Also, with this email, I am making a formal request: I am the original
> > author
> > of DBS, the most widely used patch system available in debian.  This
> > system
> > tends to want to be embedded inside each and every package that makes use
> > of
> > it(altho, this is not always the case nowadays, with dbs.deb and cdbs).  I
> > therefor make an official request that you remove all distributition of
> > all
> > such dbs-derived packages until such time as this mismatch is fixed.
>
> all latest source code corresponds to latest binaries. so, there is no
> "mismatch".

It is if they are updated with different frequencies.


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

Re: bug closing etiquette

[Bill Gatliff]

Eric:

Miles Bader wrote:


Eric Cooper <[EMAIL PROTECTED]> writes:
 


Suppose someone has reported a bug that the maintainer can't
reproduce, but the reporter can.  Is it reasonable for the maintainer
to email the reporter and ask whether a new version fixes the problem,
or is that considered obnoxious?
   



It doesn't seem obnoxious to me.

Indeed, as a user, I actually rather appreciate it when maintainer asks
me to confirm that a bug I reported is fixed -- it gives the impression
that they care about the issue.
 



Ditto.

In fact, I wouldn't even mind getting an automated message saying "you 
filed a report against x.y; x.y+1 has just been released, could you 
please try it and see if it addresses your issue?"



b.g.

--
Bill Gatliff
[EMAIL PROTECTED]


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

Re: Request: Source for parts of GNU/Solaris

[Bill Gatliff]

Anthony:


I'm amazed at the level of intolerence that's greeting a pretty major
contribution to the free software community. There are, what, five major
OS/kernels for PCs/workstatsions these days -- Windows, OS X, Solaris,
BSD and Linux. How does it make any sense at all to be hostile to the
fact that now four out of those five are free at their core?
 



I think that in this instant case, the "hostility" is the allegation 
that a Debian-based "GNU/Solaris" system as described by Erast isn't 
possible.  Even when pressed, Erast hasn't addressed the CDDL/GPL 
incompatibility issue.  And that's obviously a topic that plenty of 
people in the Debian crowd have an opinion on.  :)


I don't see it as hostility, I see it as an attempt to enforce the GPL.


b.g.

--
Bill Gatliff
[EMAIL PROTECTED]


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

Re: bug closing etiquette

[Miles Bader]

Eric Cooper <[EMAIL PROTECTED]> writes:
> Suppose someone has reported a bug that the maintainer can't
> reproduce, but the reporter can.  Is it reasonable for the maintainer
> to email the reporter and ask whether a new version fixes the problem,
> or is that considered obnoxious?

It doesn't seem obnoxious to me.

Indeed, as a user, I actually rather appreciate it when maintainer asks
me to confirm that a bug I reported is fixed -- it gives the impression
that they care about the issue.

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'


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

Re: Request: Source for parts of GNU/Solaris

[Matthew Garrett]

Anthony Towns  wrote:

> I'm amazed at the level of intolerence that's greeting a pretty major
> contribution to the free software community. There are, what, five major
> OS/kernels for PCs/workstatsions these days -- Windows, OS X, Solaris,
> BSD and Linux. How does it make any sense at all to be hostile to the
> fact that now four out of those five are free at their core?

I would love a viable Debian-based Solaris system, and I think it's
absolutely wonderful that we have so much software available under free
licenses. But the CDDL/GPL issue is a big one, and it needs to be
resolved in a way that doesn't leave people feeling like their code is
being misappropriated. Pushing out CD images despite these concerns
being raised isn't a good way of inspiring trust and cooperation, and
the fact that these concerns still haven't been answered in an even
vaguely coherent way doesn't reassure me at all.
-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: Request: Source for parts of GNU/Solaris

[Anthony Towns]

On Tue, Nov 08, 2005 at 03:39:23PM +0100, Florian Weimer wrote:
> They began distributing binaries to a large audience *after* they were
> notified of the problems.  This gives the impression that they don't
> care about GPL compliance, and want to gain publicity *now*,
> exploiting the "GNU" and "Solaris" trademarks.

So this would be much the same as the DCC Alliance? Shouldn't we then
take the view that as fellow free software travellers we should discuss
the concerns in confidence?

Or is it more akin to Debian's pre-2001 efforts on GPL compliance, where
we'd frequently find ourselves accidently distributing binaries without
corresponding source, due to a lack of infrastructure to track which
source was necessary? In which case, shouldn't we encourage people to
make their best efforts, but acknowledge the shortcomings and trust that
things will be improved in time, and perhaps further note that that will
be faster with our help?

Or perhaps it's more akin to Debian's current handling of installer
images, which aren't guaranteed to have their sources available? Should
we drop everything to ensure that env-pressed 1.09's source is available
for the 20051018 unstable images, instead of just 1.10's? In which case
shouldn't we be being circumspect about mentioning the problem, and
quietly working to fix it, and thus both retaining our credibility and
strengthening our commitment to free software?

I'm amazed at the level of intolerence that's greeting a pretty major
contribution to the free software community. There are, what, five major
OS/kernels for PCs/workstatsions these days -- Windows, OS X, Solaris,
BSD and Linux. How does it make any sense at all to be hostile to the
fact that now four out of those five are free at their core?

Cheers,
aj


signature.asc
Description: Digital signature

Re: Dependencies of -dev packages

[Gabor Gombas]

On Thu, Nov 03, 2005 at 09:07:12AM -0800, Russ Allbery wrote:

> Like I said, this defeats the entire point of the FHS.

What is the "entire point" of the FHS? If it is to disallow alternative
implementations of the same interface to co-exist then the FHS is
broken. Fortunately, this is not my reading the of FHS.

There are already many examples: libglib-1.2-dev and libglib-2.0-dev
provide overlapping interfaces, yet they can be installed together
quite nicely. libgnutlsXX-dev provides part of the interface as
libssl-dev and they can be installed together. If you claim that this is
against the FHS then you are taking away freedom from the users to
choose their preferred implementation of a given interface.

> I'm not saying that using krb5-config is a bad idea.  Over time, it's
> gotten better and better.  But most Kerberos-using software does not use
> that script for a variety of reasons and patching all Debian packages for
> all of that software to use it is not necessary or particularly desirable
> in my opinion.

But this does not need to happen in an instant. Quick roadmap (might
have some glitches):

- move the conflicting files (headers, libs) to non-conflicting
  locations
- provide backward-compatibility symlinks using alternatives
- tell maintainers that when they for the next time upload a package
  that Build-Depends: on  to add a
  Build-Conflicts: with . This should happen
  only at the next upload, so noone needs to hurry.
- start converting applications (it might be just as easy as setting
  CPPFLAGS/LDFLAGS in debian/rules, depending on the application)
- when enough applications have converted, make the change mandatory
- at some time in the future (etch+1, etch+2...) remove the
  compatibility links

Will step 4 take some (a long) time? Sure. But it is not worse nor
more complicated than many other transitions (and Debian is quite
familiar with big and long-running transitions :-)

> It defeats the purpose of the FHS, which is to have files in a predictable
> and consistent location that doesn't require configuring all software that
> relies on those files with special flags.

Face it: many complex software already require such configuration and
this will only become more common, not less. Also, the purpose of the
FHS should never be to take away freedom from me, an ordinary Debian
user, to select _my_ preferred implementation of an interface
_regardless_ of what other -dev packages happen to depend on. Doing so
would be a violation of the Social Contract, which I beleive is stronger
than the FHS.

The FHS only says that include files should go under /usr/include,
libraries under /usr/lib etc. It does not say that they cannot go into
subdirectories (in fact, it even recommends that for complex packages in
case of /usr/lib). Also, it nowhere mentions that conflicting versions
of some software should not live simultaneously under different
subdirectories of /usr/include, /usr/lib etc.

> Sorry, my mistake.  I had thought that luckily all of the Heimdal library
> names were different than all of the MIT library names, which I believe is
> almost true *except* for (of course) libkrb5.

Well, if you'd be using krb5-config then you could just rename one of
them without anyone noticing (the old shared library should remain
until all dependent applications are rebuilt, but that's all).

> Anyway, given the vehemence of your response, I doubt you're willing to be
> convinced.

Yes, I'm quite pissed off when I want to install some -dev package (that
I do not even need the Kerberos support of) just for trying it and it
wants to remove heimdal-dev in favor of libkrb5-dev while a compilation
using heimdal-dev is still running in an other window...

Of course, if you have some other solution that unconditionally keeps
heimdal-dev installed (and which does not require rebuilding all
MIT-dependant -dev packages against Heimdal), I'd be interested.

> Given that, I'll just say that, as the co-maintainer of the
> MIT Kerberos package, I will not do what you suggest, and leave it at that
> (at least in the absence of other arguments that strike me as more
> persuasive).  If you want the package to change, you can try to convince
> Sam, but I expect he'll have the same objections.

Well, the other option for me is to bug every Kerberos-using package to
also have a version built against Heimdal, but I'm not quite
enthusiastic as except this stupid Conflicts: between the -dev packages
I see no technical reason to do so.


Although this is not a _technical_ reason, it would still be
useful to have both a MIT and a Heimdal-dependent version of
every KRB5-using application. So if the USA goes insane again
about crypto stuff, we will not be left without a working &
tested KRB5 implementation.


Gabor

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

Re: New version of kernel-package to create image packages using debconf

[Manoj Srivastava]

On Tue, 8 Nov 2005 07:43:14 +0100, Christian Perrier <[EMAIL PROTECTED]> said: 

> Quoting Manoj Srivastava ([EMAIL PROTECTED]):
>> Hi,
>> 
>> A new version of kernel-package is imminent, it is undergoing boot
>> camp out in experimental. For the impatient, this release brings
>> the log awaited debconf usage for kernel image packages -- and the
>> raison d'etre of this mail. Below are the new features of the
>> upcoming kernel-package -- but first, since the kernel image
>> package asks questions in the preinst, and uses debconf now, is it
>> OK for kernel image packages to pre-depend on debconf? Or should I
>> resurrect the old preinst code and laternately ask questions
>> manually?

> As I understand, I should now yell out "Hurray", learning that we
> probably will soon be able to be prompted in something else than the
> English language...AND be able to not be interrupted by the famous
> linux-image/kernel-image packages question.

> Do you plan to first post a call for translations in -i18n so that
> when you release the new kernel-package packages, they already have
> some translations handy?


Umm, no -- I figure that translations shall come soon enough,
 and Etch is not going to be released for an year or more now, so we
 have time to polish things up.  I don't think kernel-package is
 anywhere close to a final release.

> Of course, I'm here assuming that the package is properly i18n'ed as
> I'm sure it is..:-)

Well, we use po-debconf and all.

> I'll probably add kernel-package to the current quite short list of
> "level 5" translations proposed to D-I translators, which mostly
> lists packages which are considered very important to translate
> (completely empirically).

Thanks

manoj
-- 
"They're unfriendly, which is fortunate, really.  They'd be difficult
to like." Avon
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]

Bug#338236: ITP: natstat -- A traffic monitoring program

[Florent Bayle]

Package: wnpp
Severity: wishlist
Owner: Florent Bayle <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: natstat
  Version : 0.0.10
  Upstream Author : Tommy Wallberg <[EMAIL PROTECTED]>
* URL : http://svearike.sytes.net/natstat/
* License : GPL
  Description : A traffic monitoring program

NatStat is a network monitoring tool designed to help paranoid users and
network administrators that want to monitor their iptables settings
live. It gathers information from iptables, calculates speeds on the
selected (or all available) rules, and shows it in a GUI (ncurses/Qt).
The helper application natdump can dump out the speeds on various or all
rules and give it to you in plain text.

- -- 
Florent

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDcSg/M+Ix3/RCm3gRAkFFAJ9chEKWd6ImkUZpZ7fSNkG98QVi1gCg1L97
WctkLZ6UVc4abevlTU67YOY=
=6oeM
-END PGP SIGNATURE-


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

Re: Licenses for DebConf6

[Henning Makholm]

Scripsit Francesco Poli <[EMAIL PROTECTED]>

> Don't you agree that seeing non-free or even undistributable (no license
> means "All Rights Reserved", with current laws!) papers at a DebConf is
> really a shame?

I don't.

Remember that non-free != evil, and that some of the arguments why
free software is a good thing do not apply to expositions of scholary
work or other conference contributions.

People who think that intellectual property is in and of itself an
evil concept are free to license their contributions liberally.  But
on the other hand, people who like free software for pragmatic reasons
related to its being, well, software should not be forced to give away
more rights than practically necessary for making the conference work.

For example, it is common not to want to allow derived works for
conference papers. That does not conflict with the SC, because the
papers are not going to be part of our operating system.

-- 
Henning Makholm  "Det er jo svært at vide noget når man ikke ved det, ikke?"


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

Re: Request: Source for parts of GNU/Solaris

[Erast Benson]

> On Tue, 8 Nov 2005, Erast Benson wrote:
>
>> OK, for your convenient, http://www.gnusolaris.org/sources shold has
>> everything latest/not-committed tarballs of source code with our
>> modifications for every package we are using.
>>
>> We are preparing cron job, so, will update them every night until we
>> fix some internal problems. Eventually all these tarballs should migrate
>> under http://www.gnusolaris.org/apt repository.
>>
>> Please notice, that some tarballs are in the middle of development, so
>> it is really really latest stuff.
>>
>> I hope we didn't miss anything, let us know if you find some.
>
> The source and binaries *must* match, period.  You can't have tarballs
> being
> constantly upgraded, and the binaries not, or vice versa.  The
> source+binary
> must be done as a whole unit.
>
> Also, with this email, I am making a formal request: I am the original
> author
> of DBS, the most widely used patch system available in debian.  This
> system
> tends to want to be embedded inside each and every package that makes use
> of
> it(altho, this is not always the case nowadays, with dbs.deb and cdbs).  I
> therefor make an official request that you remove all distributition of
> all
> such dbs-derived packages until such time as this mismatch is fixed.

all latest source code corresponds to latest binaries. so, there is no
"mismatch".

Erast


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

Re: Bug#338203: 73 pkgs contain debhelper maintscript remnant (cruft?)

[Justin Pryzby]

On Tue, Nov 08, 2005 at 12:57:40PM -0800, Russ Allbery wrote:
> Justin Pryzby <[EMAIL PROTECTED]> writes:
> "This" refers to the #DEBHELPER# token.
OH.  Maybe I understand.  The maintscripts of the packages in my list
were probably initially dh_make templates, and the maintainers didn't
remove that comment.  The packages not in my list either have
maintscripts created from scratch by debhelper, or their maintainer
removed that comment.

Is that a consistent interpretation?

-- 
Clear skies,
Justin


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

Re: bug closing etiquette

[Russ Allbery]

Ben Pfaff <[EMAIL PROTECTED]> writes:

> Anyone have a suggestion about what to do when the maintainer
> can't reproduce it and the reporter can only reproduce it on one
> of his machines?  I'm kind of stymied on #329333 for Autoconf.
> No idea what the problem is here.

Well, the problem is that for some reason when he builds the package when
automake1.8 is installed, it's trying to rebuild autoconf.in.  This is
done with the rule:

$(srcdir)/autoconf.in: $(srcdir)/autoconf.as # FIXME: $(m4sh_m4f_dependencies)
$(AUTOM4SH) $(srcdir)/autoconf.as -o $@

which as you can see from the FIXME comment is buggy.  Specifically, it's
missing a dependency on $(AUTOM4TE_CFG), so that command runs without
building the .cfg file first and then fails.

The mystery is that for some reason when automake1.8 is not installed,
make thinks (correctly) that autoconf.in is up to date and doesn't try to
rebuild it.  I'm not seeing anything in the logs that would obviously
explain that.  If it really happens only on his machine, I'd start
suspecting some sort of issue on that machine that caused file system
timestamps to be off.

The only connection that I can see to automake is that the build does
appear to try to run automake after running configure:

 cd . && /bin/sh /source-etch/autoconf-2.59a/config/missing --run automake-1.7a 
--gnu 
/source-etch/autoconf-2.59a/config/missing: line 52: automake-1.7a: command not 
found
WARNING: `automake-1.7a' is missing on your system.  You should only need it if
 you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
 You might want to install the `Automake' and `Perl' packages.
 Grab them from any GNU archive site.

but this fails in both build logs, so I don't see why one of them would
behave differently than the other.  missing does touch files, but it only
touches Makefile.in so far as I can tell:

find . -type f -name Makefile.am -print |
   sed 's/\.am$/.in/' |
   while read f; do touch "$f"; done

Unless for some reason an additional dependency is being added to Makefile
when it's generated on his system, I'm mystified as to the difference.

I'd probably end up closing the bug as unreproducible and probably due to
something weird on his local system if the buildds are fine and no one
else is having trouble, but maybe someone will come up with a perceptive
analysis.

It's kind of annoying that Autoconf's build system tries to run Automake,
though.  I wonder if that's fixable.  If someone *does* have automake-1.7a
installed, they may not get the same build that everyone else gets.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Bug#338203: 73 pkgs contain debhelper maintscript remnant (cruft?)

[Russ Allbery]

Justin Pryzby <[EMAIL PROTECTED]> writes:

> OH.  Maybe I understand.  The maintscripts of the packages in my list
> were probably initially dh_make templates, and the maintainers didn't
> remove that comment.  The packages not in my list either have
> maintscripts created from scratch by debhelper, or their maintainer
> removed that comment.

> Is that a consistent interpretation?

Yeah, that would be my guess.

I started from a dh_make template and just kept the comment.  More
recently, I've started removing it since I know what #DEBHELPER# is for
and expect everyone who would be doing an NMU does as well, but the
comment is informative to new packagers looking at the source package and
doesn't really hurt anything.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: apt-proxy

[Aaron M. Ucko]

Brian May <[EMAIL PROTECTED]> writes:

> However, I prefer the approach over apt-cacher, as the apt-sources
> entries remain independent of the server that will be used to retrieve
> the files.

I originally kept away from apt-cacher for exactly that reason, but it
now (as of version 1.0.6) supports a path_map directive that allows
for symbolic names.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.


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

Re: bug closing etiquette

[Ben Pfaff]

Eric Cooper <[EMAIL PROTECTED]> writes:

> Suppose someone has reported a bug that the maintainer can't
> reproduce, but the reporter can.  Is it reasonable for the maintainer
> to email the reporter and ask whether a new version fixes the problem,
> or is that considered obnoxious?

I think it's a reasonable thing to do.  It is what I do.

Anyone have a suggestion about what to do when the maintainer
can't reproduce it and the reporter can only reproduce it on one
of his machines?  I'm kind of stymied on #329333 for Autoconf.
No idea what the problem is here.
-- 
Ben Pfaff 
email: [EMAIL PROTECTED]
web: http://benpfaff.org


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

Re: Bug#338203: 73 pkgs contain debhelper maintscript remnant (cruft?)

[Russ Allbery]

Justin Pryzby <[EMAIL PROTECTED]> writes:

> Package: lintian
> Severity: wishlist

> I am including a list of 73 packages which happened to be installed on
> my laptop which contain a maintscript with the fragment:

>   # dh_installdeb will replace this with shell code automatically
>   # generated by other debhelper scripts.

> Maybe this is a debhelper bug?

What's wrong with that?  It's documentation in the version of the script
that's in the source package.  I have several packages with postinst
scripts that have sections like:

# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.

#DEBHELPER#

"This" refers to the #DEBHELPER# token.

> In any case, I would like to request that lintian includes a check to
> ensure that new packages do not contain that text.

Please don't.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Request: Source for parts of GNU/Solaris

[David Schmitt]

On Tuesday 08 November 2005 20:29, Erast Benson wrote:
> > For example, I have found
> > http://www.gnusolaris.org/apt/dists/elatte-unstable/main/binary-solaris-i
> >386/base/apt_0.6.40.1-1.1_solaris-i386.deb which seems to be installed on
> > the ISO image, but no corresponding source package under sources/ or
> > http://www.gnusolaris.org/apt/dists/elatte-unstable/main/source/Sources
>
> It is there now... thanks for noticing that!

Thanks,


Further I'm also still searching for the Sources for the sunw* packages needed 
to build the rest of dpkgs build environment.


Regards, David

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

Bug#338203: 73 pkgs contain debhelper maintscript remnant (cruft?)

[Justin Pryzby]

Package: lintian
Severity: wishlist

I am including a list of 73 packages which happened to be installed on
my laptop which contain a maintscript with the fragment:

  # dh_installdeb will replace this with shell code automatically
  # generated by other debhelper scripts.

Maybe this is a debhelper bug?

Both of my packages contain postinst and postrm, only, and generated
entirely by debhelper.  They have sections like:

# Automatically added by dh_installmenu
...
# End automatically added section

Which I think is well done.  But IMHO the section about "debhelper
will replace ... " is indicitive of a bug.

Either that text should be removed, or something should be put in its
place.  Maybe these packages are buggy and need to do some certain
thing, such that debhelper can do that replacement, but they don't do
it?

In any case, I would like to request that lintian includes a check to
ensure that new packages do not contain that text.

Package list follows; 73 out of 1269 (5.8%) installed packages are
affected.

Please Cc: me.

-- 
Clear skies,
Justin

apt
apt-listchanges
apt-show-versions
aptitude
avifile-player
bittornado
ca-certificates
chaksem
checksecurity
clara
dangen
ddclient
debtags
defoma
dhcp3-client
dict-bouvier
dict-gazetteer2k-counties
dict-gazetteer2k-places
dict-gazetteer2k-zips
dpkg-cross
eep24c
electricsheep
elinks
gs-common
gs-gpl
gsfonts
hevea
icebreaker
imagemagick
info2www
jadetex
le
less
libcupsys2
libdevmapper1
libgtk1
libgtk2
libmoe1
libmysqlclient12
libmysqlclient14
libpam-runtime
libpango1
libroken16-kerberos4kth
libruby1
libsensors3
libsndfile0
login
lp-solve
lprng
mailliststat
menu-xdg
moon-buggy-esd
mpg321
ncurses-hexedit
nvram-wakeup
openssh-client
openssh-server
passwd
procps
psfontmgr
sbuild
tetex-base
tetex-bin
timidity
tkinfo
tpconfig
upgrade-system
usbutils
vche
vtgrab
w3c-dtd-xhtml
xfig
xtux-server


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

Re: Oldenburg DevJam meeting (2005-09-23)

[-.JavaManiac.-]

On 11/8/05, Arnaud Vandyck <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>   Hi,
>
>   This is the (long awaited) report from the DevJam (Debian Java
> Meeting)  from Oldenburg  (September  23 2005)[0].  You  can find  other
> reports  at the SkoleLinux  Wiki[1] or  an article  by Mark  Wielaard at
> LWN[2].
>
>   At DevJam  several Java people  from different distributions  meet for
> the first time. This way there was the possibility to talk about how the
> different  distributions  currently  handle java  packages.  Furthermore
> there are several discussions how  the distributions can join efforts in
> their task of maintaining java packages.
>
>   Wediscussed   theavailabletoolchain   (compiler,   runtime
> environments,  tools) for free  java available.  Both  from  an upstream
> point  of  view  and what  is  the   best  approach to  integrate  them.
> Discussion  happened  if  we  should  have  the  default  compiler   and
> runtimes and   how we can   make it easier  for users to  switch between
> different java environments.
>
>   Mark  Wielaard provided  an overview  about the  current state  of GNU
> classpath and which parts are currently missing and where to go with the
> new 1.5 features (generics-branch)
>
>   Andrew Haley (upstream of gcj) gave an overview about the state of aot
> (ahead of  time) compilation of java  code with gcj and  which tools are
> available for  packagers. Gary Benson gave  a talk about  the caveats of
> aot compiling  of java code during  packaging and how he  solves some of
> the problems in fedora packaging.
>
>   All over the days there happended discussions between people of debian
> java and other distributions about various topics of interest ...
>
>   Dalibor Topic  explained his experience with JCP  and the difficulties
> we have to understand, their  (SUNs) fear and the difficulties they have
> to understand our motivations for free software.
>
>   One of the needs of  distributions for schools like skolelinux is that
> free java just has to work. This is currently not the state as there are
> missing tools  (like keytool) in the  free toolchain as  well as missing
> implementations  in  GNU  classpath.  This  way  it  is  still  hard  to
> completely  use free  java  for education  without  the possiblity  that
> something breaks.
>
>   There were discussions how this  situation could be improved. First of
> all  the integration  of free  java  in the  distribution and  selective
> runtime  usage  for  programs   should  be  implemented  by  tools  like
> java-config or  find_jvm. This way  packagers can ensure that  a program
> really   works   with   his   configured  free   runtime   without   any
> problems.  Another point  is to  improve the  upstream toolchain  so its
> easier  for GNU classpath  developers to  get an  overview over  what is
> missing in  the code or  only implemented as  a stub. As there  is stuff
> missing  in GNU  classpath, priority  of implementing  functionality was
> also discussed.
>
>   I'm very sorry for the long delay of the report. Thanks for reading.
>
> People:
> o Wolfgang Baer (Debian)
> o Gary Benson (RedHat)
> o Daniel Bornkessel (SuSE)
> o Rene Engelhard (Debian)
> o Kurt Gramlich (DebianEdu, Skolelinux)
> o Andrew Haley (RedHat)
> o Matthias Klose (Ubuntu)
> o Michael Koch (GNU Classpath, Debian)
> o Pablo Pita
> o Petteri Rty (Gentoo)
> o Christian Thalinger (CacaoVM)
> o Dalibor Topic (Kaffe)
> o Arnaud Vandyck (Debian)
> o Jeroen VanWolffelaar (Debian)
> o Rene Wagner (OpenEmbedded)
> o Mark Wielaard (GNU Classpath)
> Sorry if I forgot someone...
>
> [0] http://java.debian.net/index.php/DevJam
> [1] http://skolelinux.de/wiki/FreeJava/Meeting050923
> [2] http://lwn.net/Articles/152664/
>
> - --
>   .''`.
>  : :' :rnaud
>  `. `'
>`-
> Java Trap: http://www.gnu.org/philosophy/java-trap.html
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFDcN0i4vzFZu62tMIRAl0NAJ4mea9w/9S9jrA892UzZ1doD2u+RQCgjKJb
> TZf0OB28V4ltd3BE+/ETE08=
> =7R1D
> -END PGP SIGNATURE-
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
>
>


--
Gerardo Curiel
Linux User # 374459
Geek By NaTure,LiNuX By ChOiCe,DebiAn of CoUrsE
<___-!!Java RuLeS!!-___>

Re: Request: Source for parts of GNU/Solaris

[Adam Heath]

On Tue, 8 Nov 2005, Erast Benson wrote:

> OK, for your convenient, http://www.gnusolaris.org/sources shold has
> everything latest/not-committed tarballs of source code with our
> modifications for every package we are using.
>
> We are preparing cron job, so, will update them every night until we
> fix some internal problems. Eventually all these tarballs should migrate
> under http://www.gnusolaris.org/apt repository.
>
> Please notice, that some tarballs are in the middle of development, so
> it is really really latest stuff.
>
> I hope we didn't miss anything, let us know if you find some.

The source and binaries *must* match, period.  You can't have tarballs being
constantly upgraded, and the binaries not, or vice versa.  The source+binary
must be done as a whole unit.

Also, with this email, I am making a formal request: I am the original author
of DBS, the most widely used patch system available in debian.  This system
tends to want to be embedded inside each and every package that makes use of
it(altho, this is not always the case nowadays, with dbs.deb and cdbs).  I
therefor make an official request that you remove all distributition of all
such dbs-derived packages until such time as this mismatch is fixed.


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

Re: Request: Source for parts of GNU/Solaris

[Olaf van der Spek]

On 11/8/05, Alex Ross <[EMAIL PROTECTED]> wrote:
> Note that we have limited resources.

How is that relevant?

Re: Request: Source for parts of GNU/Solaris

[Alex Ross]

Thomas Bushnell BSG wrote:

Andy Teijelo Pérez <[EMAIL PROTECTED]> writes:


El Martes, 8 de Noviembre de 2005 1:11, Thomas Bushnell BSG escribió:

"Erast Benson" <[EMAIL PROTECTED]> writes:

I understand your concern. We will release ISO image with CDDL/GPL
sources very soon. Majority of them already available at /apt. The rest
is comming.

Once again, delete the binaries *now*.

Please! Could you give the man a break?



I agree with you that they're not fullfilling every little drop of
ink in the GPL and that's not acceptable, but, man, please, let them
work. It's ok to point them their mistake, but let them fix it. Give
them some time. They cannot go from violating to not-violating in
zero time. 


That is not correct.  Deleting the binaries takes less than no time.
Do we need to file a formal copyright violation request?  The law
provides a way to force websites to immediately remove infringing
materials. 


They are clearly willing to correct their mistakes, it's
not like they'll just leave thing as they are. Give them some time!


I don't believe this for a minute.  There are insurmountable licensing
restrictions, and the "time" is an excuse.





Overnight we actually did remove the downloads. Today we posted this on the 
debian-devel:


http://www.gnusolaris.org/sources

Note that we have limited resources.

Thanks!


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

Re: Request: Source for parts of GNU/Solaris

[Erast Benson]

> On Tuesday 08 November 2005 17:17, Erast Benson wrote:
>> OK, for your convenient, http://www.gnusolaris.org/sources shold has
>> everything latest/not-committed tarballs of source code with our
>> modifications for every package we are using.
>>
>> We are preparing cron job, so, will update them every night until we
>> fix some internal problems. Eventually all these tarballs should migrate
>> under http://www.gnusolaris.org/apt repository.
>>
>> Please notice, that some tarballs are in the middle of development, so
>> it is really really latest stuff.
>>
>> I hope we didn't miss anything, let us know if you find some.
>
> This is a great start, but I'm getting tired of doing your homework:
>
> For example, I have found
> http://www.gnusolaris.org/apt/dists/elatte-unstable/main/binary-solaris-i386/base/apt_0.6.40.1-1.1_solaris-i386.deb
> which seems to be installed on the ISO image, but no corresponding source
> package under sources/ or
> http://www.gnusolaris.org/apt/dists/elatte-unstable/main/source/Sources

It is there now... thanks for noticing that!

Erast


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

Re: bug closing etiquette

[Thomas Bushnell BSG]

Eric Cooper <[EMAIL PROTECTED]> writes:

> Suppose someone has reported a bug that the maintainer can't
> reproduce, but the reporter can.  Is it reasonable for the maintainer
> to email the reporter and ask whether a new version fixes the problem,
> or is that considered obnoxious?

It's certainly my standard procedure.


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

Re: Request: Source for parts of GNU/Solaris

[Thomas Bushnell BSG]

Andy Teijelo Pérez <[EMAIL PROTECTED]> writes:

> El Martes, 8 de Noviembre de 2005 1:11, Thomas Bushnell BSG escribió:
>> "Erast Benson" <[EMAIL PROTECTED]> writes:
>> > I understand your concern. We will release ISO image with CDDL/GPL
>> > sources very soon. Majority of them already available at /apt. The rest
>> > is comming.
>>
>> Once again, delete the binaries *now*.
>
> Please! Could you give the man a break?

> I agree with you that they're not fullfilling every little drop of
> ink in the GPL and that's not acceptable, but, man, please, let them
> work. It's ok to point them their mistake, but let them fix it. Give
> them some time. They cannot go from violating to not-violating in
> zero time. 

That is not correct.  Deleting the binaries takes less than no time.
Do we need to file a formal copyright violation request?  The law
provides a way to force websites to immediately remove infringing
materials. 

> They are clearly willing to correct their mistakes, it's
> not like they'll just leave thing as they are. Give them some time!

I don't believe this for a minute.  There are insurmountable licensing
restrictions, and the "time" is an excuse.

Re: Debconf problem

[Joey Hess]

Frank Küster wrote:
> I found no way to cleanly solve the problem of 
> 
> - writing the current state into the debconf database, so that
>   noninteractive installs don't change anything
> 
> - actually reflect changed answers in the system.

The config script is passed parameters that you can use to tell if it is
an upgrade or a reconfigure and handle these cases appropriatly.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Request: Source for parts of GNU/Solaris

[David Schmitt]

On Tuesday 08 November 2005 17:17, Erast Benson wrote:
> OK, for your convenient, http://www.gnusolaris.org/sources shold has
> everything latest/not-committed tarballs of source code with our
> modifications for every package we are using.
>
> We are preparing cron job, so, will update them every night until we
> fix some internal problems. Eventually all these tarballs should migrate
> under http://www.gnusolaris.org/apt repository.
>
> Please notice, that some tarballs are in the middle of development, so
> it is really really latest stuff.
>
> I hope we didn't miss anything, let us know if you find some.

This is a great start, but I'm getting tired of doing your homework:

For example, I have found
http://www.gnusolaris.org/apt/dists/elatte-unstable/main/binary-solaris-i386/base/apt_0.6.40.1-1.1_solaris-i386.deb
which seems to be installed on the ISO image, but no corresponding source 
package under sources/ or 
http://www.gnusolaris.org/apt/dists/elatte-unstable/main/source/Sources

Further I'm also still searching for the Sources for the sunw* packages needed 
to build the rest of dpkgs build environment.


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

Re: Debconf problem

[Frank Küster]

Joey Hess <[EMAIL PROTECTED]> wrote:

> dpkg-reconfigure runs the config script exactly once, so the config file
> is read once, its values are used for defaults to the questions to allow
> reconfiguration, and are saved to the config file by the postinst.

Yes, I was wrong about this - it's only run twice upon apt-get install
and friends.

> In more complex cases, such as adding a debconf question based on a
> config file line that already exists in a previous version of the
> package, you have to add additional code.

Mine is probably a "more complex case", but it may be not so uncommon.
I only talked about config files because I didn't understand the details
even of the simple case, but that is clear now.

In the real case, the item that is configured are the permissions of
generated files (i.e. files not included in the deb, so
dpkg-statoverride cannot be used), the ls-R files of teTeX/tex-common.
There existed some debconf questions about this, but the approach we
took in sarge was flawed, and therefore we decided to not take over any
"seen" flags.

What we try to do is determine which of three ls-R files should be
group-writable.  Upon a fresh install, they don't exist when config is
run, but upon upgrade or dpkg-reconfigure they do exist.  Is there any
package that does a thing like that?  

I found no way to cleanly solve the problem of 

- writing the current state into the debconf database, so that
  noninteractive installs don't change anything

- actually reflect changed answers in the system.

The only idea I came up with is to tell the script whether the question
has been *just* seen (e.g. with a db_fset mypackage/question justseen
after db_go in config, and resetting this flag in the postinst script).
But this seems to be an ugly hack.  The current code, stripped down to
one file, is

if [ -r $lsr ] ; then
if ls -l $lsr | grep -q ^.w ; then
gwrite="true"
else
gwrite="false"
fi
db_set tex-common/managedlsr $gwrite || true
fi
db_input low tex-common/managedlsr || true
db_go

And the postinst does

db_get tex-common/managedlsr || true
if [ "$RET" = "true" ]; then
  test -e $lsr || echo "$ls_R_magic" > $lsr 
  chmod g+w $lsr
fi

TIA, Frank

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

KJV Bible - Crown Copyright in UK [was: Bug#338077: ITP: sword-text-kvj -- King James Version with Strongs Numbers and Morphology]

[Lionel Elie Mamane]

(
 Please mail followups to:
 [EMAIL PROTECTED], debian-legal@lists.debian.org, [EMAIL PROTECTED], [EMAIL 
PROTECTED]
)

On Tue, Nov 08, 2005 at 10:13:42AM -0500, Roberto C. Sanchez wrote:
> Quoting Lionel Elie Mamane <[EMAIL PROTECTED]>:
>> On Mon, Nov 07, 2005 at 08:51:26PM -0500, Roberto C. Sanchez wrote:

>>>* License : Public Domain
>>>  Description : King James Version with Strongs Numbers and Morphology

>>>This is the King James Version of the Holy Bible (also known as the
>>>Authorized Version) with embedded Strong's Numbers. The rights to
>>>the base text are held by the Crown of England.

>> What "rights" are you speaking about? The text certainly is far too
>> old for any copyright to hold and you yourself tag it as "public
>> domain". So what "right" is being spoken of here?

> Based on my understanding [0], the Crown of England maintains the
> perogative to authorize printings of the KJV text in Great Britain.
> It is in the public domain everywhere else.

Ain't law fun? 

This makes the KJV of the bible non-free in GB and probably even
illegal to distribute at all in GB, unless the Crown gives a blanket
license for electronic distribution. Does it?

According to the wikipedia article, we can escape this Crown Copyright
if what the package will contain is an "annotated Study Bible". The
question is whether that thing will be annotated enough to be
considered as such.

Please investigate this before uploading to Debian.

> [0]
> http://en.wikipedia.org/wiki/King_James_Version_of_the_Bible#Copyright_status

-- 
Lionel


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

Re: Request: Source for parts of GNU/Solaris

[Erast Benson]

> On Tuesday 08 November 2005 01:48, Erast Benson wrote:
>> www.gnusolaris.org is *the same place*.
>
> Oh, I expected some tar-ball to be linked from the same place as the ISOs
> (i.e. the Downloads page) not some point-and-click SVN-webinterface.
>
>> > this URL also does _neither_ offer access to the apt
>> > (0.6.40.1-1.1) nor your patched debhelper (4.9.3elatte) as requested
>> in
>> > my other mail.
>>
>> I'm personally working on it, and I will not commit those changes until
>> they will be tested. Rememer, these all binaries are under development,
>> and
>> available for developers only. Are you developer and wanna help us?
>
> I'm a user of your software, who insists on his license-granted rights to
> the
> source of the binaries he received. That's why it's called "Open Source".
> I
> would already be satisfied with a tar-ball of your development directory
> as
> long as I can build from there and it has appropriate (i.e. GPL
> compatible)
> licensing terms attached.

OK, for your convenient, http://www.gnusolaris.org/sources shold has
everything latest/not-committed tarballs of source code with our
modifications for every package we are using.

We are preparing cron job, so, will update them every night until we
fix some internal problems. Eventually all these tarballs should migrate
under http://www.gnusolaris.org/apt repository.

Please notice, that some tarballs are in the middle of development, so
it is really really latest stuff.

I hope we didn't miss anything, let us know if you find some.

Thanks!
Erast


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

Re: Debconf problem

[Joey Hess]

Frank Küster wrote:
> However, in case apt-utils is installed, this script will be run twice:
> Once by dpkg-preconfigure, i.e. in the preinst stage, and once by
> confmodule when the postinst script sources confmodule.  As far as I can
> see, this will have a confusing effect.  Assume the configfile currently
> contains
> 
> FOO=true
> 
> and the local admin wants to change this to 
> 
> FOO=false
> 
> using dpkg-reconfigure mypackage.  This is what is going to happen:

dpkg-reconfigure runs the config script exactly once, so the config file
is read once, its values are used for defaults to the questions to allow
reconfiguration, and are saved to the config file by the postinst.

In the case of a fresh installation of the package, or an upgrade from a
version before the config file exists, or before a given line is added
to the config file, the config script runs the first time, does not
override the question from the default in the debconf database because
the config file is not present, the user answers the question, the
config script runs again similarly but the question is not asked a second
time, and the postinst script writes the values into the config file.

In the case of an upgrade of the package, the config file exists, the
config script runs as you describe but the user is not asked any
questions since they have seen them before, and the postinst writes the
old values back into the config file.

In more complex cases, such as adding a debconf question based on a
config file line that already exists in a previous version of the
package, you have to add additional code.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#338174: ITP: systemtap -- instrumentation system for Linux

[Eugeniy Meshcheryakov]

Package: wnpp
Severity: wishlist
Owner: Eugeniy Meshcheryakov <[EMAIL PROTECTED]>

* Package name: systemtap
  Upstream Authors: Frank Ch. Eigler <[EMAIL PROTECTED]>,
Graydon Hoare <[EMAIL PROTECTED]>
Martin Hunt <[EMAIL PROTECTED]>
Tom  Zanussi <[EMAIL PROTECTED]>
* URL : http://sourceware.org/systemtap/
* License : GPL
  Description : instrumentation system for Linux 2.6

 The SystemTap project aims to produce a Linux tool that lets
 application developers and system administrators take a deeper look
 into a running kernel. It aims to exploit the capability of a fully
 open-source Linux target to go beyond performance measurements, and
 perhaps even serve as a programmable debugger.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8)


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

PhD / Doktorandenstelle: OCR für Linux (Open Source)

[RalfGesellensetter]

(X-post to kde-devel. please reply to debian-devel@lists.debian.org)

Liebe Entwickler, dear developers,

as far as I can tell, current alternatives to commercial products (I 
dare name Abbyy Finereader and Omnipage Pro) such as gocr and ocrad, 
fail to reach the same standards. This is partly a matter of man power 
and money spent (I suppose), partly a question of technology (best 
results are achieved when operating on "3 dimensional" greyscale 
scans).

Researching on further informations, I found out, that the university of 
KL (Kaiserslautern?) offers a payed PhD project which deals exactly 
with this task:

"Develop a free open source software (FLOSS) that does optical character 
recognition (OCR) with optimal results."

Further information can be obtained from:
Christoph Lampert (username: "chl"; servername: "iupr.net")

I can't tell if the thesis has to be done in German, but of course, it 
can only be done by postgraduates. 

Finally, I quote Christoph's original posting from April, this year (he 
just told me, that there haven't been any serious applicants since!)

>> Hallo Liste,
>>
>>
>> eine Mitteilung, eine Frage:
>>
>> Wir haben voraussichtlich demnaechst am DFKI in KL einige gut
>> bezahlte Doktorandenstellen, die sich mit der Entwicklung einer Open
>> Source OCR-Loesung unter Linux beschaeftigen sollen. Wenn jemand von
>> Euch,  oder jemand, den Ihr kennt, Interesse hat, kann er sich direkt
>> an mich  wenden, dann schicke ich Euch Informationen.

Regards
Ralf

P.S.: Developers who are ready to support the usage of FLOSS at schools, 
are invited to meet their requirements by developing missing software 
as described at http://skolelinux.de/wiki/LernSoftware/Desiderata
- Please, take into consideration that the generation to come will use 
the type of software (and OS) they know from school...


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

Re: device nodes with udev?

[Jerome Warnier]

Le lundi 07 novembre 2005 à 14:06 +0100, Marco d'Itri a écrit :
> On Nov 07, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> 
> > > Wrong. Nothing needs BSD ptys but some *very* old applications (I would
> > > not even know where to find one).
> > At least /sbin/bootlogd does not work without BSD ptys and this is not
> Actually it does.
> 
> > documented anywhere. I needed some time to figure out why it complains
> > about some completely bogus tty name not being available even if I
> > specify the correct console at the kernel's command line.
> Because it's half broken.
Maybe you could tell us how to do it, then, hmmm? :-)

-- 
Jérôme Warnier
FLOSS Consultant
http://beeznest.net


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

Re: bug closing etiquette

[Nico Golde]

Hi,
* Ron Johnson <[EMAIL PROTECTED]> [2005-11-08 16:18]:
> On Tue, 2005-11-08 at 09:53 -0500, Eric Cooper wrote:
> > Suppose someone has reported a bug that the maintainer can't
> > reproduce, but the reporter can.  Is it reasonable for the maintainer
> > to email the reporter and ask whether a new version fixes the problem,
> > or is that considered obnoxious?
> 
> Doesn't reportbug already check to see whether there is a newer
> version in Debian (at least in the branches w/in your sources.list)?

Yes but sometimes upstream provides a newer version which is 
not yet packaged so if the bug is fixed in it it can be 
tagged fixed-upstream.
Regards Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org
Forget about that mouse with 3/4/5 buttons -
gimme a keyboard with 103/104/105 keys!


pgp6FywvAmwwL.pgp
Description: PGP signature

Re: Request: Source for parts of GNU/Solaris

[sean finney]

On Tue, Nov 08, 2005 at 03:43:36PM +0100, Andreas Barth wrote:
> You could send them e.g. a DMCA Takedown Notice. Especially as they
> didn't listen before. Of course only if you're the author of one of the
> relevant programms.

you could also send their isp(s) and/or hosting provider(s) said 
takedown notice.  it would be most unfortunate if things need to come
to that... but it is an option (and an effective one ime)


sean

-- 


signature.asc
Description: Digital signature

Re: bug closing etiquette

[Marco d'Itri]

On Nov 08, Eric Cooper <[EMAIL PROTECTED]> wrote:

> Suppose someone has reported a bug that the maintainer can't
> reproduce, but the reporter can.  Is it reasonable for the maintainer
> to email the reporter and ask whether a new version fixes the problem,
> or is that considered obnoxious?
It's the obvious next step.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: bug closing etiquette

[Ron Johnson]

On Tue, 2005-11-08 at 09:53 -0500, Eric Cooper wrote:
> Suppose someone has reported a bug that the maintainer can't
> reproduce, but the reporter can.  Is it reasonable for the maintainer
> to email the reporter and ask whether a new version fixes the problem,
> or is that considered obnoxious?

Doesn't reportbug already check to see whether there is a newer
version in Debian (at least in the branches w/in your sources.list)?

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

"Don't be so open minded that your brains fall out."
s. keeling


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

Re: bug closing etiquette

[Christoph Berg]

Re: Eric Cooper in <[EMAIL PROTECTED]>
> Suppose someone has reported a bug that the maintainer can't
> reproduce, but the reporter can.  Is it reasonable for the maintainer
> to email the reporter and ask whether a new version fixes the problem,
> or is that considered obnoxious?

You mean, rather than just closing the bug (as suggested by the
subject)? Asking the submitter to provide input is fine, why not?

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


signature.asc
Description: Digital signature

bug closing etiquette

[Eric Cooper]

Suppose someone has reported a bug that the maintainer can't
reproduce, but the reporter can.  Is it reasonable for the maintainer
to email the reporter and ask whether a new version fixes the problem,
or is that considered obnoxious?

-- 
Eric Cooper e c c @ c m u . e d u


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

Re: Request: Source for parts of GNU/Solaris

[Andreas Barth]

* Thomas Bushnell BSG ([EMAIL PROTECTED]) [051108 07:11]:
> "Erast Benson" <[EMAIL PROTECTED]> writes:

> > I understand your concern. We will release ISO image with CDDL/GPL sources
> > very soon. Majority of them already available at /apt. The rest is
> > comming.

> Once again, delete the binaries *now*.  

You could send them e.g. a DMCA Takedown Notice. Especially as they
didn't listen before. Of course only if you're the author of one of the
relevant programms.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Accepted console-tools 1:0.2.3dbs-58 (source all i386)

[Unknown]

Szia!

Levelet kaptam Tõled a [EMAIL PROTECTED] email címemre! Ezt a postafiókomat már 
nem használom!

Légyszives ide írj: [EMAIL PROTECTED]

Cég Vezetõ

Re: Request: Source for parts of GNU/Solaris

[Florian Weimer]

* Andy Teijelo Pérez:

> El Martes, 8 de Noviembre de 2005 1:11, Thomas Bushnell BSG escribió:
>> "Erast Benson" <[EMAIL PROTECTED]> writes:
>> > I understand your concern. We will release ISO image with CDDL/GPL
>> > sources very soon. Majority of them already available at /apt. The rest
>> > is comming.
>>
>> Once again, delete the binaries *now*.
>
> Please! Could you give the man a break?
> I agree with you that they're not fullfilling every little drop of ink in the 
> GPL and that's not acceptable, but, man, please, let them work. It's ok to 
> point them their mistake, but let them fix it.

They began distributing binaries to a large audience *after* they were
notified of the problems.  This gives the impression that they don't
care about GPL compliance, and want to gain publicity *now*,
exploiting the "GNU" and "Solaris" trademarks.

Re: Request: Source for parts of GNU/Solaris

[Andy Teijelo Pérez]

El Martes, 8 de Noviembre de 2005 1:11, Thomas Bushnell BSG escribió:
> "Erast Benson" <[EMAIL PROTECTED]> writes:
> > I understand your concern. We will release ISO image with CDDL/GPL
> > sources very soon. Majority of them already available at /apt. The rest
> > is comming.
>
> Once again, delete the binaries *now*.

Please! Could you give the man a break?
I agree with you that they're not fullfilling every little drop of ink in the 
GPL and that's not acceptable, but, man, please, let them work. It's ok to 
point them their mistake, but let them fix it. Give them some time. They 
cannot go from violating to not-violating in zero time. They are clearly 
willing to correct their mistakes, it's not like they'll just leave thing as 
they are. Give them some time!

Regards,
Andy.

Bug#338153: ITP: cdpr -- Cisco Discovery Protocol Reporter

[Matt Zagrabelny]

Package: wnpp
Severity: wishlist
Owner: Matt Zagrabelny <[EMAIL PROTECTED]>


* Package name: cdpr
  Version : 2.2.0
  Upstream Author : Lance O'Connor <[EMAIL PROTECTED]>
* URL : http://www.d.umn.edu/~mzagrabe/debian/cdpr/
* License : GPL
  Description : Cisco Discovery Protocol Reporter

(Include the long description here.)

cdpr listens on specified network interfaces for Cisco Discovery
Protocol packets. It thendecodes those packets and outputs the
information, optionally sending the information to a server for
processing.



-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.3.20050725.0
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

bts2ldap-gateway: new host bts2ldap.debian.net

[Andreas Barth]

Hi,

once again, the ldap-part of the bts2ldap-gateway changed its location.
It is now on bts2ldap.debian.net (but this host name has the advantage
that it can stay, even if the ldap-server moves once again :), port is
10101.

Thanks to Andrew Pollock for offering some space on one of his machines
for this.

The index-files are still available as files on merkel and master.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Bug#338128: ITP: miredo -- IPv6 Teredo tunnneling client, relay and server

[Matt Brown]

Package: wnpp
Severity: wishlist
Owner: Matt Brown <[EMAIL PROTECTED]>


* Package name: miredo
  Version : 0.5.3
  Upstream Author : Rémi Denis-Courmon <[EMAIL PROTECTED]>
* URL : http://www.simphalempin.com/dev/miredo/
* License : GPL v2
  Description : IPv6 Teredo tunnneling client, relay and server

Miredo is an open-source implementation of the Teredo: Tunneling IPv6
over UDP through NATs Internet draft specification. Miredo can act as
a Toredo Client, a stand-alone Toredo relay or a Toredo server.
.
The purpose of Teredo IPv6 tunnelling is to provide IPv6 connectivity
to users behind NAT devices. Most, if not all, currently deployed NATs
do not support IPv6, in particular 6to4, so another method is needed
to obtain public IPv6 connectivity. That can be achieved by running a
Teredo client, such as Miredo.
.
Further information is at: http://www.simphalempin.com/dev/miredo/

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.12.5-skas3-v8.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Debconf problem

[Frank Küster]

Hi,

I posted this question yesterday on -mentors, but since nobody answered,
it seems it isn't as trivial as I had hoped.

I have either some fundamental misunderstanding of how debconf or
maintainer scripts work, or there is an error in the descriptioin of how
debconf-using scripts should handle configuration files.  In
debconf-devel(7), the section "Config file handling" under "ADVANCED
PROGRAMING WITH DEBCONF" suggests the following config script:

 #!/bin/sh
CONFIGFILE=/etc/foo.conf
set -e
. /usr/share/debconf/confmodule

# Load config file, if it exists.
if [ -e $CONFIGFILE ]; then
. $CONFIGFILE || true

# Store values from config file into
# debconf db.
db_set mypackage/foo FOO
db_set mypackage/bar BAR
fi

# Ask questions.
db_input medium mypackage/foo || true
db_input medium mypackage/bar || true
db_go || true

However, in case apt-utils is installed, this script will be run twice:
Once by dpkg-preconfigure, i.e. in the preinst stage, and once by
confmodule when the postinst script sources confmodule.  As far as I can
see, this will have a confusing effect.  Assume the configfile currently
contains

FOO=true

and the local admin wants to change this to 

FOO=false

using dpkg-reconfigure mypackage.  This is what is going to happen:

- The config script is run and sources $CONFIGFILE, FOO is set to true,
  mypackage/foo is set to true in the debconf database, too, and the
  question is asked.  The local admin answers to disable foo, and now
  mypackage/foo is set to false in the database.

- The postinst script is run, sources confmodule, which executes config
  again.  config sources the (yet unchanged) $CONFIGFILE, FOO is set to
  true, and again mypackage/foo is set to true in the debconf database.
  This time, however, debconf does not ask the question again, so "true"
  stays in the database.

- The postinst script is reexecuted by debconf, this time it really
  runs, queries the debconf database, gets the answer "true" for
  mypackage/foo, and does *not* change $CONFIGFILE.

Pleaase, tell me, where is my mistake?

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

Re: Request: Source for parts of GNU/Solaris

[David Schmitt]

On Tuesday 08 November 2005 01:48, Erast Benson wrote:
> www.gnusolaris.org is *the same place*.

Oh, I expected some tar-ball to be linked from the same place as the ISOs 
(i.e. the Downloads page) not some point-and-click SVN-webinterface.

> > this URL also does _neither_ offer access to the apt
> > (0.6.40.1-1.1) nor your patched debhelper (4.9.3elatte) as requested in
> > my other mail.
>
> I'm personally working on it, and I will not commit those changes until
> they will be tested. Rememer, these all binaries are under development, and
> available for developers only. Are you developer and wanna help us?

I'm a user of your software, who insists on his license-granted rights to the 
source of the binaries he received. That's why it's called "Open Source". I 
would already be satisfied with a tar-ball of your development directory as 
long as I can build from there and it has appropriate (i.e. GPL compatible) 
licensing terms attached.


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

Re: Licenses for DebConf6 [was: Re: DebConf6: Call For Papers]

[Andreas Schuldei]

* Francesco Poli <[EMAIL PROTECTED]> [2005-11-08 00:28:07]:
> "The authors have the freedom to pick a DFSG-free license" means that
> they *may* do so, but are not required to. Am I correct?
> 
> IMHO, DebConf paper authors should be *required* to publish in a
> DFSG-free manner, as a condition for presenting at the conference.
> 
> Don't you agree that seeing non-free or even undistributable (no license
> means "All Rights Reserved", with current laws!) papers at a DebConf is
> really a shame?

given your knowledge level of how debconf intents to handle
things and the way you escalate this issue gives me the idea that
you mainly want to raise a stink and create unrest.

So please inform yourself properly first. that might include to
take up the issue in a friendly way with someone who is involved
or trying to submit a proposal, paper or even give a talk
yourself.

You might also think about the organizers options when a speaker
surprisingly NOT picks a DFSG free license, double-licenses his
talk in an awkward way or declares before the audience that his
talk must not be distributed.

Also consider the legal implications of an intention or promise
to release a DFSG free talk vs the actual act of releasing the
work and when that happens in a legally binding way. Then
consider the character of the CFP as a legaly binding document
for the licenses of the actual talks of the speakers.

But please do so alone, first.

/andreas


signature.asc
Description: Digital signature

Re: New version of kernel-package to create image packages using debconf

[Steve Langasek]

On Mon, Nov 07, 2005 at 09:35:38PM -0600, Manoj Srivastava wrote:

> A new version of kernel-package is imminent, it is undergoing
>  boot camp out in experimental. For the impatient, this release brings
>  the log awaited debconf usage for kernel image packages -- and the
>  raison d'etre of this mail. Below are the new features of the
>  upcoming kernel-package -- but first, since the kernel image package
>  asks questions in the preinst, and uses debconf now, is it OK for
>  kernel image packages to pre-depend on debconf? Or should I resurrect
>  the old preinst code and laternately ask questions manually?

Well, of course the concern with pre-depends is that careless
pre-dependencies can lead to unbreakable loops.  Although it's the custom
for userspace packages to not depend (or pre-depend) on kernel image
packages directly, in order to allow users to roll their own unpackaged
kernels, there are certainly occasions when userspace software has a de
facto pre-dependency on a particular kernel version.  So we'll have to be
careful not to let the kernel images (indirectly) pre-depend on anything
that would leave us without an upgrade path from sarge, but I don't think
pre-depends vs. depends even matter here given that you can't reboot to a
Debian kernel image before the package has been successfully configured.

Anyway, the dependency tree for debconf looks something like this in sarge
(Essential packages trimmed):

debconf
|_ debconf-i18n
   |_ liblocale-gettext-perl
   |  |_ perlapi-5.8.0
   |_ libtext-iconv-perl
   |  |_ perlapi-5.8.3
   |_ libtext-wrapi18n-perl
   |_ libtext-charwidth-perl

There are more packages involved if we consider the various debconf
frontends, but the above is sufficient, on the debconf side, to let a
kernel-image package install whether it depends or pre-depends on debconf.
So I would say that such a pre-dependency is safe, unless anyone else sees
a problem?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Request: Source for parts of GNU/Solaris

[Frank Küster]

"Erast Benson" <[EMAIL PROTECTED]> wrote:

> David,
>
> this is the place were source code lives:
>
> http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1/gnu

, Permission Denied
|  Insufficient permissions to access /gnusolaris1/gnu 
`

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