device nodes with udev?

[Miles Bader]

I usually compile my own kernels (using make-kpkg), but recently I
decided to try a standard debian package of 2.6.14, since it was up
before I got around to it.  [This is from unstable]

It seems to work OK, but the weird thing is that I got a bunch of random
useless device nodes in /dev as a result, and I'm not entirely sure
where they're coming from.

The main offender is ptys -- I use udev for my devices, and normally
/dev/pts gets used for ptys, but with the new kernel there were suddenly
about 10 zillion old-style pty-related device nodes -- /dev/[pt]ty[a-z][0-9]
-- there are also a bunch of other random devices I don't want like
/dev/ram[0-9].

Despite the presence of these old-style pty nodes, the system still seems to
be using the new /dev/pts driver for actually making ptys (e.g., if I type
"tty" in an emacs shell, it says "/dev/pts/1"), so they seem to be just some
left over cruft.

Where exactly are these created?  Given that I'm using udev, I'm surprised
that which kernel I have installed even makes a difference -- shouldn't
device creation just be left up to udev?  Is there a setting I should be
setting but am not?

   i linux-image-2.6.14-1-6862.6.14-2  
   i udev0.072-2   

Thanks,

-Miles
-- 
"Suppose He doesn't give a shit?  Suppose there is a God but He
just doesn't give a shit?"  [George Carlin]


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

Bug#337929: ITP: zope-plonetestcase -- unit testing framework and test case for Plone

[Fabio Tranchitella]

Package: wnpp
Severity: wishlist
Owner: Fabio Tranchitella <[EMAIL PROTECTED]>

* Package name: zope-plonetestcase
  Version : 0.7
  Upstream Author : Stefan H. Holek, [EMAIL PROTECTED]
* URL : http://zope.org/Members/shh/PloneTestCase
* License : ZPL
  Description : unit testing framework and test case for Plone

PloneTestCase is a thin layer on top of the ZopeTestCase package.
It has been developed to simplify testing of Plone-based applications
and products.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'experimental'), (500, 'testing'), (500, 
'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686-smp
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: 
LC_ALL set to [EMAIL PROTECTED])


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

Bug#337931: ITP: zope-cmfmember -- advanced members management for Plone sites

[Fabio Tranchitella]

Package: wnpp
Severity: wishlist
Owner: Fabio Tranchitella <[EMAIL PROTECTED]>

* Package name: zope-cmfmember
  Version : 1.1b5
  Upstream Author : Ben Saller (bcsaller), Jonah (MrEnoch), Geoff Davis (geoffd 
/ plonista)
* URL : http://plone.org/products/cmfmember
* License : ZPL
  Description : advanced members management for Plone sites

CMFMember is a replacement for portal_memberdata that provides TTP
(Through-The-Plone) member management. Members are ordinary Archetypes
(AT) objects that are controlled by workflow. Member data can be
expanded and configured via an AT schema (or via subclassing).

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'experimental'), (500, 'testing'), (500, 
'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686-smp
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: 
LC_ALL set to [EMAIL PROTECTED])


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

Bug#337932: ITP: zope-atseng -- framework to provide flexible schema editing for AT content-types

[Fabio Tranchitella]

Package: wnpp
Severity: wishlist
Owner: Fabio Tranchitella <[EMAIL PROTECTED]>

* Package name: zope-atseng
  Version : 0.3.2
  Upstream Author : Andreas Jung, Rob Miller (rafrombrc)
* URL : http://plone.org/products/atseng/
* License : LGPL
  Description : framework to provide flexible schema editing for AT 
content-types

ATSchemaEditorNG provides a means of allowing through the web (TTW) management 
of 
Archetypes schemas. Features include:
 * containment- or tool-based schema management
 * different schemas for the same content type in different locations
 * hooks for add TTW support for custom fields, widgets, or storages
 * hooks for extending the editor UI to supply custom attributes to fields
 * schema caching for performance

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'experimental'), (500, 'testing'), (500, 
'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686-smp
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: 
LC_ALL set to [EMAIL PROTECTED])


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

Re: device nodes with udev?

[Marco d'Itri]

On Nov 07, Miles Bader <[EMAIL PROTECTED]> wrote:

> It seems to work OK, but the weird thing is that I got a bunch of random
> useless device nodes in /dev as a result, and I'm not entirely sure
> where they're coming from.
The kernel.

> The main offender is ptys -- I use udev for my devices, and normally
> /dev/pts gets used for ptys, but with the new kernel there were suddenly
> about 10 zillion old-style pty-related device nodes -- /dev/[pt]ty[a-z][0-9]
So tell the kernel team to stop enabling CONFIG_LEGACY_PTYS.

> -- there are also a bunch of other random devices I don't want like
> /dev/ram[0-9].
Rebuild a kernel without a ramdrive then.

Or if you really can't live with these devices and can't be bothered
building a new kernel, use something like:

cat < /etc/udev/rules.d/000_my.rules
KERNEL=="pty[a-z]*", NAME= ""
KERNEL=="ram[0-9]*", NAME= ""
END

> Where exactly are these created?  Given that I'm using udev, I'm surprised
> that which kernel I have installed even makes a difference -- shouldn't
> device creation just be left up to udev?  Is there a setting I should be
> setting but am not?
README.Debian may be a good way to start learning how udev actually
works.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

initramfs-tools backport?

[Joerg Platte]

Hi!

Recent vanilla kernels do not include devfs any longer. Are there any 
"official" plans to provide a backport of initramfs-tools for sarge? 

Regards,
Jörg


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

Problem with package build-depends against libpcap-dev - is this a bug?

[Roy Hills]

I'm having problems building nmap and xprobe from source because of
build-depends on libpcap-dev.  I need to build these two packages
from source because I have local patches that I want to apply to the
source code before it's compiled.



I'm running sarge on i386 and have libpcap0.8-dev installed, which
allows both nmap and xprobe to build without error if I use
"dpkg-buildpackage -d" to override the dependency check.


If I try to install libpcap-dev, it removes libpcap0.8-dev and installs
libpcap0.7-dev - effectively downgrading the libpcap development
libraries.  It does this because libpcap-dev depends on
libpcap0.7-dev, which conflicts with libpcap0.8-dev.  However, I
don't want to do this, because the packages I'm interested in compile
and run
fine with 0.8, so I see no reason to downgrade to 0.7.


Is this a bug?  If so, which package is in error - nmap for
specifying libpcap-dev, or libpcap-dev for not allowing libpcap0.8-dev
to meet the dependency?



I also note that the notes for libpcap-dev say that it is a "Empty
package to facilitate upgrades, can be safely removed", so I guess this
means that other packages shouldn't have depends against it.

Here are the details of the libpcap packages that I have installed:

# dpkg -l | grep libpcap
ii  libpcap0.7
0.7.2-7    System interface for
user-level packet captu
ii  libpcap0.8
0.8.3-5    System interface for
user-level packet captu
ii  libpcap0.8-dev 0.8.3-5    Development library and header files for lib

Any pointers would be gratefully received.

Roy

Re: device nodes with udev?

[Miles Bader]

[EMAIL PROTECTED] (Marco d'Itri) writes:
>> The main offender is ptys -- I use udev for my devices, and normally
>> /dev/pts gets used for ptys, but with the new kernel there were suddenly
>> about 10 zillion old-style pty-related device nodes -- /dev/[pt]ty[a-z][0-9]
>
> So tell the kernel team to stop enabling CONFIG_LEGACY_PTYS.

I presume that default kernels need legacy ptys to support older systems
that don't use udev, right?

What about disabling them by default in udev (as you illustrate below),
but leave the driver in the default kernel for those with an existing
static /dev that need them?

> cat < /etc/udev/rules.d/000_my.rules
> KERNEL=="pty[a-z]*", NAME= ""
> KERNEL=="ram[0-9]*", NAME= ""
> END

I'll do that, thanks.

-miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research


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

Re: Bits from the release team: the plans for etch

[Gabor Gombas]

On Fri, Nov 04, 2005 at 11:01:20AM -0800, Philippe Troin wrote:

> Although I agree with the above on principle, how do you manage
> membership to the floppy, audio, video, etc groups?

pam_group for example. If you want to let some users access the devices
even if they are not logged in at the console, then it is better to use
sudo & some helper scripts (so syslog will contain who did what).

Gabor

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


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

Re: device nodes with udev?

[Marco d'Itri]

On Nov 07, Miles Bader <[EMAIL PROTECTED]> wrote:

> > So tell the kernel team to stop enabling CONFIG_LEGACY_PTYS.
> I presume that default kernels need legacy ptys to support older systems
> that don't use udev, right?
Wrong. Nothing needs BSD ptys but some *very* old applications (I would
not even know where to find one).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: device nodes with udev?

[Ian Campbell]

On Mon, 2005-11-07 at 21:03 +0900, Miles Bader wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
> >> The main offender is ptys -- I use udev for my devices, and normally
> >> /dev/pts gets used for ptys, but with the new kernel there were suddenly
> >> about 10 zillion old-style pty-related device nodes -- 
> >> /dev/[pt]ty[a-z][0-9]
> >
> > So tell the kernel team to stop enabling CONFIG_LEGACY_PTYS.
> 
> I presume that default kernels need legacy ptys to support older systems
> that don't use udev, right?

It's to support older applications which don't know about the /dev/pyts/
interface. Whether the legacy device nodes come from a static /dev or
from udev doesn't really enter in to it.

Ian.

-- 
Ian Campbell
Current Noise: Amon Amarth - Without Fear

If everything seems to be going well, you have obviously overlooked something.


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

Re: device nodes with udev?

[Gabor Gombas]

On Mon, Nov 07, 2005 at 01:30:56PM +0100, Marco d'Itri 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
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.

Gabor

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


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

Re: device nodes with udev?

[Marco d'Itri]

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.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: device nodes with udev?

[Miles Bader]

[EMAIL PROTECTED] (Marco d'Itri) writes:
>> I presume that default kernels need legacy ptys to support older systems
>> that don't use udev, right?
>
> Wrong. Nothing needs BSD ptys but some *very* old applications (I would
> not even know where to find one).

I was thinking about the case where someone has a (very old) static /dev
and simply never bothered to add /dev/pts (though I don't know if such a
configuration would even work in a modern debian).

In any case, does anyone else know if there are really such old
applications still around?

-Miles
-- 
自らを空にして、心を開く時、道は開かれる


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

Re: apt-proxy

[Otavio Salvador]

Brian May <[EMAIL PROTECTED]> writes:

> Hello,
>
> Simple question: is apt-proxy still being maintained?

Yes, it's. Chris Halls is doing a big refactoring of it.

Current sid version has a lot fixes and more's comming.

Unfortunatelly I hadn't time to work on it anymore and major of last
work was did by Chris. Could you help with its development?

> Based on the growing list of bugs, I suspect not.

apt-proxy has some critical problem in its base and that's why a
refactoring is in process.

> A quick glance of some of the reports shows no sign of response from
> the maintainer.

In past I was active in its development but lack time to work on it
since I started to work in others projects and to help to maintain
some like  grub, parted, discover and etc...

> Some users in fact have completely given up.
>
> A recent bug I have discovered makes it unusable.

I already saw your bug report and I'll see if Chris can handle it or
I'll try to do it ASAP.

Sorry!

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


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

Re: device nodes with udev?

[LUK ShunTim]

Miles Bader wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
> 
>>>I presume that default kernels need legacy ptys to support older systems
>>>that don't use udev, right?
>>
>>Wrong. Nothing needs BSD ptys but some *very* old applications (I would
>>not even know where to find one).
> 
> 
> I was thinking about the case where someone has a (very old) static /dev
> and simply never bothered to add /dev/pts (though I don't know if such a
> configuration would even work in a modern debian).
> 
> In any case, does anyone else know if there are really such old
> applications still around?
> 
> -Miles

FWIW, I just remove udev and revert to static /dev because I did not get udev to
create /dev/fd0 for me. It happen to both kernel version 2.6.12 and 2.6.14. I
think older version of udev (before 0.70?) have no such problem.

Regards,
ST
-- 


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

Re: initramfs-tools backport?

[Andre Luis Lopes]

On Mon, Nov 07, 2005 at 12:56:52PM +0100, Joerg Platte wrote:
> Hi!

Hello,

> Recent vanilla kernels do not include devfs any longer. Are there any 
> "official" plans to provide a backport of initramfs-tools for sarge? 

It's not official, but there're current (2.6.14) kernel images backported
to Sarge available at http://www.backports.org/pending/ .

Also, you will find there yaird (but not initramfs-tools) and udev
backports, which should allow you to run a recent kernel in a Sarge
system.

I didn't tested any of it yet. I'm just answering your question and trying
to help.

Regards,

-- 
++--++
||  André Luís Lopes [EMAIL PROTECTED]||
||   http://people.debian.org/~andrelop ||
||  Debian-BR Projecthttp://www.debian-br.org   ||
||  Public GPG KeyID 9D1B82F6   ||


signature.asc
Description: Digital signature

Re: real-i386

[Simon Richter]

Hi,

Bastian Venthur wrote:


What I'd really like to know rightnow is whether i386 *is* the wrong therm
for the x86 (or IA32) arch or not. If not then Debian could stick to this
name, but if so I think Debian just delays the problem for a few years.


In fact, there are efforts underway to allow architecture switches on 
existing systems, to allow for e.g. an i386 installation to be migrated 
to amd64.


I propose that everyone offended by the "i386" architecture name shall 
help those efforts or shut up. Talking about problems that are only 
technical in nature will not make them go away.


   Simon


signature.asc
Description: OpenPGP digital signature

Re: apt-proxy

[Eric Cooper]

On Mon, Nov 07, 2005 at 11:51:55AM +1100, Brian May wrote:
> Simple question: is apt-proxy still being maintained?
> 
> Based on the growing list of bugs, I suspect not.
> 
> A quick glance of some of the reports shows no sign of response from
> the maintainer.
> 
> Some users in fact have completely given up.
> 
> A recent bug I have discovered makes it unusable.
> 
> 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.
> 
> Is there a good alternative?

I wrote approx for exactly this purpose. It's now in testing.

-- 
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: apt-proxy

[Ian Campbell]

On Mon, 2005-11-07 at 11:51 +1100, Brian May wrote: 
> 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.
> 
> Is there a good alternative?

I use apt-cacher and have mod_rewrite rewrite /debian/
to /apt-cacher/ftp.uk.debian.org, similarly for /debian-amd64/
and /debian-security/ etc.

I could have sworn I got the idea from an article on
www.debian-administration.org but the nearest I can find now is
http://www.debian-administration.org/articles/136

Ian.
-- 
Ian Campbell
Current Noise: Tool - Parabola

I feel better about world problems now!


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

Re: initramfs-tools backport?

[Christophe Chisogne]

Andre Luis Lopes a écrit :
> It's not official, but there're current (2.6.14) kernel images backported
> to Sarge available at http://www.backports.org/pending/ .
> 
> Also, you will find there yaird (but not initramfs-tools) and udev
> backports, which should allow you to run a recent kernel in a Sarge
> system.

It seems impossible to build and install a 2.6.14 kernel
(from kernel.org) with initrd on Testing (Etch)
(make-kpkg --initrd kernel_image ..  ; dpkg -i ../kernel-image...)
without dpkg complaining about some "initrd support" error.

I installed yaird and dpkg happily installed the kernel image.

Hope this can help others too.

Ch.


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

Re: Problem with package build-depends against libpcap-dev - is this a bug?

[Frank Küster]

Roy Hills <[EMAIL PROTECTED]> wrote:

> I'm having problems building nmap and xprobe from source because of
> build-depends on libpcap-dev.  I need to build these two packages from
> source because I have local patches that I want to apply to the source
> code before it's compiled.

You'd make me happier if you'd wrap your lines at a sensible length,
like 75, instead of letting me do it...


> I'm running sarge on i386 and have libpcap0.8-dev installed, which
> allows both nmap and xprobe to build without error if I use
> "dpkg-buildpackage -d" to override the dependency check.

Do the programs also run without problems?

[only libcap0.7-dev provides libcap-dev]

> Is this a bug?  If so, which package is in error - nmap for specifying
> libpcap-dev, or libpcap-dev for not allowing libpcap0.8-dev to meet
> the dependency?

It depends...  Usually all development packages of stable versions of a
library Provide the generic name package, so the first guess is that
libcap0.8 should provide libcap-dev.  But it might not be so easy -
maybe libcap0.8 isn't as stable as 0.7.  If it was in testing, there
could be other causes - e.g. currently there's libkpathsea3-dev and
libkpathsea4-dev in sid, but only libkpathsea3-dev in testing, and only
provides libkpathsea-dev.  The purpose is that all packages that
build-depend on libkpathsea-dev will be linked against the SOVERSION 3
and can migrate to testing without problems, while the 4 version is only
used by one source package - the one that provides it.

> I also note that the notes for libpcap-dev say that it is a "Empty
> package to facilitate upgrades, can be safely removed", so I guess
> this means that other packages shouldn't have depends against it.

This might indicate that it was for an older upgrade (0.6-0.7), and
there is no smooth upgrade path from 0.7 to 0.8 - maybe on purpose.  In
this case, it's either a bug in nmap and xprobe that they don't allow
building against 0.8 - or the maintainer has found that there's an
incompatibility. 

> Any pointers would be gratefully received.

Did you have a look at the BTS pages for the involved packages?

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

Re: [SECURITY] [DSA 881-1] New OpenSSL 0.9.6 packages fix cryptographic weakness

[Martin Schulze]

Turbo Fredriksson wrote:
> > The following matrix explains which version in which distribution has
> > this problem corrected.
> >
> > oldstable (woody)  stable (sarge) unstable (sid)
> > openssl  0.9.6c-2.woody.8   0.9.7e-3sarge1  0.9.8-3
> > openssl 094  0.9.4-6.woody.4 n/a  n/a
> > openssl 095  0.9.5a-6.woody.6n/a  n/a
> > openssl 096   n/a   0.9.6m-1sarge1n/a
> > openssl 097   n/an/a0.9.7g-5
> >
> > We recommend that you upgrade your libssl packages.
> 
> With an upgrade like this, doesn't all the packages that links with OpenSSL
> needs to be re-packaged?

Restarted, not repackaged.

Regards,

Joey

-- 
This is GNU/Linux Country.  On a quiet night, you can hear Windows reboot.

Please always Cc to me when replying to me on the lists.


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

Bug#337960: ITP: python-logilab-astng -- Python Abstract Syntax Tree New Generation

[Alexandre Fayolle]

Package: wnpp
Severity: wishlist
Owner: Alexandre Fayolle <[EMAIL PROTECTED]>

* Package name: python-logilab-astng
  Version : 0.13.1
  Upstream Author : Sylvain Thénault <[EMAIL PROTECTED]>
* URL : http://www.logilab.org/projects/astng
* License : GPL
  Description : Python Abstract Syntax Tree New Generation

 The aim of this module is to provide a common base representation of
 python source code for projects such as pychecker, pyreverse,
 pylint... Well, actually the development of this library is essentialy
 governed by pylint's needs.
 .
 It extends class defined in the compiler.ast [1] module with some
 additional methods and attributes. Instance attributes are added by a
 builder object, which can either generate extended ast (let's call
 them astng ;) by visiting an existant ast tree or by inspecting living
 object. Methods are added by monkey patching ast classes.

This package contains code that was in python-logilab-common, and which
upstream split in a new library. The newest pylint package uses the new
code. 

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-amd64-k8-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to fr_FR)

Re: Problem with package build-depends against libpcap-dev - is this a bug?

[Adeodato Simó]

* Frank Küster [Mon, 07 Nov 2005 16:23:53 +0100]:

> Roy Hills <[EMAIL PROTECTED]> wrote:

> > I'm having problems building nmap and xprobe from source because of
> > build-depends on libpcap-dev.  I need to build these two packages from
> > source because I have local patches that I want to apply to the source
> > code before it's compiled.

> You'd make me happier if you'd wrap your lines at a sensible length,
> like 75, instead of letting me do it...

  (FWIW, Roy's mail came in multipart/alternative text/plain and
  text/html. The text/plain version had proper line wrapping. You MUA
  should be configurable to prefer text/plain over text/html.

  HTH,)

-- 
Adeodato Simó
EM: dato (at) the-barrel.org | PK: DA6AE621
 
As an adolescent I aspired to lasting fame, I craved factual certainty,
and I thirsted for a meaningful vision of human life -- so I became a
scientist. This is like becoming an archbishop so you can meet girls.
-- Matt Cartmill


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

Re: Problem with package build-depends against libpcap-dev - isthis a bug?

[Roy Hills]

Roy Hills <[EMAIL PROTECTED]> wrote:>> I'm running sarge on i386 and have libpcap0.8-dev installed, which>> allows both nmap and xprobe to build without error if I use
>> "dpkg-buildpackage -d" to override the dependency check.> Do the programs also run without problems?Yes, there are no problems running the programs after they havebeen compiled against libpcap08-dev.
>> I also note that the notes for libpcap-dev say that it is a "Empty>> package to facilitate upgrades, can be safely removed", so I guess>> this means that other packages shouldn't have depends against it.
> This might indicate that it was for an older upgrade (0.6-0.7), and> there is no smooth upgrade path from 0.7 to 0.8 - maybe on purpose.  In> this case, it's either a bug in nmap and xprobe that they don't allow
> building against 0.8 - or the maintainer has found that there's an> incompatibility.It looks like the libpcap-dev package is to ease the transition fromwoody to sarge.  Woody has just libpcap0 and libpcap-dev (no zero in
the -dev package name), both of which have version 0.6.2-2, whereassarge includes the first two version digits in both runtime and devpackages and supplies two versions: 0.7 and 0.8.I presume that there must be a reason why both 
0.7 and 0.8 aresupported in sarge, but I can't find anything.>> Any pointers would be gratefully received.> Did you have a look at the BTS pages for the involved packages?Yes, I couldn't find anything except a wishlist bug against
libpcap-dev which asked if it should be removed.I'll submit a bug against libpcap-dev first for not allowinglibpcap0.8-dev to satisfy the dependency, and see where thatleads.  I guess that the libpcap-dev developer should know
what is supposed to happen.Roy

Re: initramfs-tools backport?

[Norbert Tretkowski]

* Andre Luis Lopes wrote:
> On Mon, Nov 07, 2005 at 12:56:52PM +0100, Joerg Platte wrote:
> > Recent vanilla kernels do not include devfs any longer. Are there
> > any "official" plans to provide a backport of initramfs-tools for
> > sarge? 
> 
> It's not official, but there're current (2.6.14) kernel images
> backported to Sarge available at http://www.backports.org/pending/ .
> 
> Also, you will find there yaird (but not initramfs-tools) and udev
> backports, which should allow you to run a recent kernel in a Sarge
> system.

I'll add initramfs-tools soon, the reason why there's only yaird is
that it's easier to backport than initramfs-tools.

Norbert


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

Re: initramfs-tools backport?

[Joerg Platte]

Am Montag, 7. November 2005 17:48 schrieb Norbert Tretkowski:
Hi!

> I'll add initramfs-tools soon, the reason why there's only yaird is
> that it's easier to backport than initramfs-tools.

Great news :-) I'm using initramfs-tools for sid for some time now with some 
enhancements to support an rsync-based update mechanism. With a backported 
version it's possible to port these scripts to our sarge based cluster and 
computer pool. IMHO, initramfs-tools is much easier to understand and enhance 
than the old initrd system. 

regards,
Jörg


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

Re: Problem with package build-depends against libpcap-dev - isthis a bug?

[Martijn van Oosterhout]

2005/11/7, Roy Hills <[EMAIL PROTECTED]>:
> I'll submit a bug against libpcap-dev first for not allowing
> libpcap0.8-dev to satisfy the dependency, and see where that
> leads. I guess that the libpcap-dev developer should know
> what is supposed to happen.

I wonder if this shouldn't be like libreadline-dev. This virtual
package is provided by both libreadline4-dev and libreadline5-dev.
Packages generally compile against both. People depending on readline
would use something like:

Build-Depends: libreadline5-dev | libreadline-dev

meaning it compiles against whatever you have installed, only
installing libreadline5-dev if you don't have either...

Re: real-i386

[Michelle Konzack]

Am 2005-11-03 11:35:22, schrieb Ron Johnson:

> If so, they've hidden it on their web site.  The Elan is called
> a Am5x86 CPU, and I get the impression that the Geode isn't i386
> either.

And what about the 386EX ?
...which I have bought recently from Intel ?
 
> Companies *do* make them, though.  They are *tiny*, low-power &
> *cheap*.  The 386SX is perfect for the embedded market.

:-)

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


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

Re: per-user temp directories by default?

[Greg Norris]

On Thu, Nov 03, 2005 at 11:16:43PM -0500, Noah Meyerhans wrote:
> I have little operational experience with this PAM module, though.  Does
> it cause problems for certain apps?  If so, could these problems be
> solved with a less simplistic PAM configuration?

The only one I've encountered so far is gdm[1], although I haven't been 
using libpam-tmpdir for all that long.

   [1] http://bugs.debian.org/332466


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

Re: per-user temp directories by default?

[Greg Norris]

On Fri, Nov 04, 2005 at 02:08:41PM +0200, Lars Wirzenius wrote:
> I don't think the suggestion was to make TMP=~/tmp, but TMP=/tmp/$USER,
> where /tmp/$USER is owned by the user in question and is inaccessible to
> others. Or perhaps I read too much into the proposal?

That's pretty close... currently, libpam-tmpdir uses "/tmp/user/$UID".


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

Re: Debian based GNU/Solaris: pilot program

[Michael Banck]

On Fri, Nov 04, 2005 at 01:47:22AM -0500, Joey Hess wrote:
> Michael Banck wrote:
> > Do you plan to use debian-installer for installation?
> 
> And do you realize that the debian installer is largely GPL licensed and
> would present the same license incompatability issues as eg, dpkg?

Yes.

At the time of writing, I assumed "GNU/Solaris" implied they'd use the
GNU libc (so I didn't even ask them about it).


cheers,

Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Re: device nodes with udev?

[Marco d'Itri]

On Nov 07, Christopher Martin <[EMAIL PROTECTED]> wrote:

> This fixes both rtc and floppy. I'm assuming that the root of the problem 
> here is the kernel? No surprise if that's the case. But thanks for coming 
> up with a workaround. Hopefully there aren't too many more of these issues 
> lurking.
Yes, I forgot to add the workaround to the udev package when I killed
the old hotplug package. I will fix this in the next upload.
Most people have not noticed this because they have not purged hotplug
yet, so its conffile was not removed.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Request: Source for parts of GNU/Solaris

[David Schmitt]

Dear GNU/Solaris Team!

I have downloaded the elatte_live_prealpha1_x86.iso.gz[1] from your website 
and found a dpkg binary on it. 

Much to my dismay I was not able to locate the source for this binary, despite
it being obviously under the GPL[2]. Therefore I request you kindly to make
the sources available to me. This includes "all the source code for all 
modules it contains, plus any associated interface definition files, plus the 
scripts used to control compilation and installation of the executable."[3]

Since dpkg is distributed with a complete operating system, I have to assume
that other components on the CD are Free Software too. Therefore I again
request you kindly to make the sources to the used libraries[4] available to
me.



Regards, David Schmitt



[1] http://www.gnusolaris.org/elatte_live_prealpha1_x86.iso.gz, 
md5sum:17b70141a1c4a3d877af5271b1caf920

[2] See /usr/share/doc/dpkg/copyright on said ISO Image

[3] http://www.gnu.org/licenses/gpl.html

[4] Library Packages
libintl.so.3gettext/sunwclsr
libiconv.so.2   libiconv
libc.so.1   sunwcls{,r}
libz.so zlibg1
libbz2.so.1.0   libbz2-1.0
libgcc_s.so.1   libgcc1


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

Re: Bits from the release team: the plans for etch

[Philippe Troin]

Gabor Gombas <[EMAIL PROTECTED]> writes:

> On Fri, Nov 04, 2005 at 11:01:20AM -0800, Philippe Troin wrote:
> 
> > Although I agree with the above on principle, how do you manage
> > membership to the floppy, audio, video, etc groups?
> 
> pam_group for example. 

pam_group would work for floppy, audio and video.  But it's insecure.
And it does not solve the problem for group membership like
Debian-exim.

> If you want to let some users access the devices
> even if they are not logged in at the console, then it is better to use
> sudo & some helper scripts (so syslog will contain who did what).

Yes, it can be done.  But it's also impractical.

Phil.


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

Re: Request: Source for parts of GNU/Solaris

[John Hasler]

David Schmitt writes:
> I have downloaded the elatte_live_prealpha1_x86.iso.gz[1] from your website 
> and found a dpkg binary on it. 

> Much to my dismay I was not able to locate the source for this binary,
> despite it being obviously under the GPL[2].

Was the requisite written offer included?  Would you be willing to check
the CD for other GPL software and notify the authors if you find any?
-- 
John Hasler


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

Re: Request: Source for parts of GNU/Solaris

[Alex Ross]

John Hasler wrote:

David Schmitt writes:
I have downloaded the elatte_live_prealpha1_x86.iso.gz[1] from your website 
and found a dpkg binary on it. 



Much to my dismay I was not able to locate the source for this binary,
despite it being obviously under the GPL[2].


Was the requisite written offer included?  Would you be willing to check
the CD for other GPL software and notify the authors if you find any?


It's a bug, bad link on a generated page.

Here's the correct link:

http://www.gnusolaris.org/apt/dists/unstable/main/source/base/

We'll look more into this. Thanks for the notice!


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

Re: apt-proxy

[Adrian von Bidder]

On Monday 07 November 2005 15.53, Ian Campbell wrote:
> On Mon, 2005-11-07 at 11:51 +1100, Brian May wrote:
> > 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.
> >
> > Is there a good alternative?
>
> I use apt-cacher and have mod_rewrite rewrite /debian/
> to /apt-cacher/ftp.uk.debian.org, similarly for /debian-amd64/
> and /debian-security/ etc.

For those not fluent with mod_rewrite, would you mind posting the 
configuration snippet?

cheers
-- vbi

-- 
Available for key signing in Zürich and Basel, Switzerland
(what's this? Look at http://fortytwo.ch/gpg/intro)


pgpdXzKMt1Bdk.pgp
Description: PGP signature

Re: device nodes with udev?

[Peter Samuelson]

[Ian Campbell]
> It's to support older applications which don't know about the
> /dev/pyts/ interface. Whether the legacy device nodes come from a
> static /dev or from udev doesn't really enter in to it.

/dev/{pts/,ptmx} are so trivial to support (in applications) that I
think it's worthwhile to disable legacy BSD pty support in Debian
kernels, and fix whatever still breaks.  That is, unless we think there
are still a significant number of third-party non-free apps out there
still using them.

Likewise, I'd also support having udev ship a rule which by default
ignores /dev/{tty,pty}[p-za-e]*.


signature.asc
Description: Digital signature

Re: apt-proxy

[Ian Campbell]

On Mon, 2005-11-07 at 22:07 +0100, Adrian von Bidder wrote:
> On Monday 07 November 2005 15.53, Ian Campbell wrote:
> > On Mon, 2005-11-07 at 11:51 +1100, Brian May wrote:
> > > 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.
> > >
> > > Is there a good alternative?
> >
> > I use apt-cacher and have mod_rewrite rewrite /debian/
> > to /apt-cacher/ftp.uk.debian.org, similarly for /debian-amd64/
> > and /debian-security/ etc.
> 
> For those not fluent with mod_rewrite, would you mind posting the 
> configuration snippet?

Sure.

Include /etc/apt-cacher/apache.conf

RewriteEngine on
RewriteRule ^/debian-security/(.*) /apt-cacher/security.debian.org/$1 [PT]
RewriteRule ^/debian-amd64/(.*) 
/apt-cacher/ftp.nl.debian.org/debian-amd64/debian/$1 [PT]
RewriteRule ^/debian/(.*) /apt-cacher/ftp.uk.debian.org/debian/$1 [PT]

Ian.

-- 
Ian Campbell

Health nuts are going to feel stupid someday, lying in hospitals dying
of nothing.
-- Redd Foxx


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

Re: Debian based GNU/Solaris: pilot program

[cascardo]

On Fri, Nov 04, 2005 at 07:40:34AM -0500, Michael Poole wrote:
> Frank Küster writes:
> 
> > Michael Poole <[EMAIL PROTECTED]> wrote:
> >
> >> Andrew Suffield writes:
> >>
> >>> On Thu, Nov 03, 2005 at 12:48:53PM -0800, Erast Benson wrote:
>  CDDL works similar way, except on per-file basis.
> >>>
> >>> This is incomprehensible gibberish.
> >>
> >> This is unsupportable hyperbole.  Erast's statement may be inapt,
> >> wrong, misleading, or have any number of other flaws, but it is
> >> neither incomprehensible nor gibberish.
> >
> > I do not comprehend what he means with "CDDL works on a per-file basis,
> > GPL does not".  One can of course create a project made up of GPL'ed
> > source files and other source files with different, GPL-compatible
> > licenses.
> 
> The CDDL (based as it is on the MPL) allows you to mix CDDL-licensed
> files in a project with files under CDDL-incompatible licenses and
> distribute the resulting executable.  The GPL applies to the work as a
> whole.  The relevant sections of the GPL are below; this trait is why
> people say that, even though CDDL is a copyleft license, it allows
> developers to create proprietary applications on top of the CDDL base.

Sorry, but the relevant sections below do not belong to the GPL, but
to the CDDL.

> 
>   1.3. "Covered Software" means (a) the Original Software, or (b)
> Modifications, or (c) the combination of files containing Original
> Software with files containing Modifications, in each case
> including portions thereof.
> 
>   1.9. "Modifications means the Source Code and Executable form of any
> of the following:
> A. Any file that results from an addition to, deletion from or
> modification of the contents of a file containing Original
> Software or previous Modifications;
> B. Any new file that contains any part of the Original Software or
> previous Modification; or
> C. Any new file that is contributed or otherwise made available
> under the terms of this License.
> 
>   1.12. "Source Code" means (a) the common form of computer software
> code in which modifications are made and (b) associated
> documentation included in or with such code.
> 
>   3.1. Availability of Source Code.
> Any Covered Software that You distribute or otherwise make
> available in Executable form must also be made available in Source
> Code form and that Source Code form must be distributed only under
> the terms of this License. You must include a copy of this License
> with every copy of the Source Code form of the Covered Software
> You distribute or otherwise make available. You must inform
> recipients of any such Covered Software in Executable form as to
> how they can obtain such Covered Software in Source Code form in a
> reasonable manner on or through a medium customarily used for
> software exchange.
> 
> Does this help?
> 
> Michael Poole
> 

Thadeu Cascardo
--


signature.asc
Description: Digital signature

Re: Debian based GNU/Solaris: pilot program

[Matthew Garrett]

Michael Banck <[EMAIL PROTECTED]> wrote:

> At the time of writing, I assumed "GNU/Solaris" implied they'd use the
> GNU libc (so I didn't even ask them about it).

Having downloaded their preview ISO:

The system is using Solaris's C library, but contains a great deal of
GPLed material. When I queried this, I was told

"Our reading of the GPL (http://www.gnu.org/copyleft/gpl.html) tells us
that we are fully compliant. Sun libc is exempt simply because it is
(quote from GPL, Section 3) 'normally distributed (in either source or
binary form) with the major components (compiler, kernel...'."

I've pointed out that the rest of that sentence rules out that line of
argument, but haven't received a response yet.
-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Bug#338026: ITP: gnormalize -- gnormalize is a front-end to normalize, an audio converter, encoder, ripper, meta data (tag) editor and audio cd player

[Michael Stilkerich]

Package: wnpp
Severity: wishlist
Owner: Michael Stilkerich <[EMAIL PROTECTED]>


* Package name: gnormalize
  Version : 0.46
  Upstream Author : Claudio Fernandes de Souza Rodrigues <[EMAIL PROTECTED]>
* URL : http://gnormalize.sourceforge.net/
* License : GPL
  Description : gnormalize is a front-end to normalize, an audio converter, 
encoder, ripper, meta data (tag) editor and audio cd player

gnormalize decodes the MP3/MP4/MPC/OGG/APE/FLAC file to WAV, then
normalizes the WAV to a targeted volume level and re-encodes it.
Moreover, gnormalize can extract Audio CD track and output as various
popular audio formats (MP3, MP4, MPC, OGG, APE, FLAC, WAV) with fast
speed and high quality. gnormalize can also convert audio format between
MP3, MP4, MPC, OGG, APE and FLAC with high fidelity, which meets your
need to play and collect audio files. It can change the encoding and
Metadata (tag) properties of final normalized files.
gnormalize can be used to adjust the volume of audio files to a standard
volume level, where different recording levels on different albums can
cause the volume to vary greatly from song to song.
gnormalize is an alternative for replaygain, because "there is no
consistent standard by which to define the appropriate replay gain which
mp3 encoders and players agree on, and no automatic way to set the
volume adjustment for each track". 

-- 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.14
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


-- 
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 Monday 07 November 2005 21:29, John Hasler wrote:
> David Schmitt writes:
> > I have downloaded the elatte_live_prealpha1_x86.iso.gz[1] from your
> > website and found a dpkg binary on it.
> >
> > Much to my dismay I was not able to locate the source for this binary,
> > despite it being obviously under the GPL[2].
>
> Was the requisite written offer included?

On http://www.edv-bus.at/david/gnusolaris/download_page.ps you can see the 
Page where I downloaded it. As far as I can see, there is neither a link to 
the source nor a written offer.

> Would you be willing to check 
> the CD for other GPL software and notify the authors if you find any?

On http://www.edv-bus.at/david/gnusolaris/copyrights/ you can find 
the /usr/share/doc/*/copyright files as I found them on the ISO image. 
A simple check[1] in this directory indicates 265 packages claiming GPL 
inheritance. Amongst them apt, base-files, base-passwd, debianutils, defoma, 
dselect, python-apt and synaptic, which seem to be of particular interest to 
the Debian community. 

Additionally I have uploaded the /var/lib/dpkg/status from the ISO image to 
document the declared relationships between the packages. This can also be 
found in the http://www.edv-bus.at/david/gnusolaris/ directory.

Regards, David Schmitt

[1] rgrep -l GPL * | wc -l

-- 
- 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: per-user temp directories by default?

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Fr den  4. Nov 2005 um 13:36 schrieb Jon Dowland:
> ...alongside the private keys in ~/.gnupg?

Well, you can configure gnupg to write secret keys to a secure medium.

Am Fr den  4. Nov 2005 um 15:46 schrieb Noah Meyerhans:
> First of all, libpam_tmpdir doesn't put $TMP in $HOME.  Second, we're

Ah, ok. In some mails I understand to put it in $HOME. One more
directory level under /tmp shouldn't be a problem.

> talking about the *default* configuration.  If you're doing something

Me too. Also pam configuration can be overwritten from dpkg. (If you
didn't touch it this will be done without asking a question.

Also if it seems to be a good idea to use per user tmp just ask the
sysadmins by a debconf question.

> with encrypted swap or $HOME on NFS, you've already diverged quite a bit
> from the default configuration, so your security would not be broken
> even if $TMP was in $HOME.  You'd simply have one single line to delete
> from the default pam configuration.

Well, not pam configuration for this changes. (For other like LDAP or
such you need to) So the config files will be silentely overwritten.

Gruß
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ2/Pw5+OKpjRpO3lAQIzQwf/V/GTrGJX4BTn8+a4lBsqlCzssgUSk7aT
Oo2s2GQ3KfJXMNwp/BLxGc/yAhYaNLmysfNEJDrzLaeIUYsohRbzIGiSFCEGmSJf
cOd3yWVuv6vmX5+4pvi3cHk26fteWm22YVcQNwb0sX9JPDWrA5pA6BZUGA9sSkQb
9cFa8VWgJoVA13rbrLKU/Z/gFLZfXF4KQCh0986tR3W4uknRHMBPPyynEVjlfEqb
97AHS3pSyhcawgcmEtRpsKn1K3xtfyv3fqMCIfJ9DNYdKZq9fZT6fUdI2mL8e74E
GH18UKyHstHa2h5D18r4S63A+unDbaF9lbZLI9k0olkIi+UVKyBDhA==
=q86y
-END PGP SIGNATURE-


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

Bug#338033: general: wmifs and wmii try to overwrite each other

[Manolo Díaz]

Package: general
Severity: grave
Justification: renders package unusable



-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)




Both packages, wmifs (version 1.3b1-15) and wmii (version 2-1) from unstable 
provide
/usr/bin/wmifs
and try to overwrite each other.


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

Re: Debian based GNU/Solaris: pilot program

[Alex Ross]

Matthew Garrett wrote:

Michael Banck <[EMAIL PROTECTED]> wrote:


At the time of writing, I assumed "GNU/Solaris" implied they'd use the
GNU libc (so I didn't even ask them about it).


Having downloaded their preview ISO:

The system is using Solaris's C library, but contains a great deal of
GPLed material. When I queried this, I was told

"Our reading of the GPL (http://www.gnu.org/copyleft/gpl.html) tells us
that we are fully compliant. Sun libc is exempt simply because it is
(quote from GPL, Section 3) 'normally distributed (in either source or
binary form) with the major components (compiler, kernel...'."

I've pointed out that the rest of that sentence rules out that line of
argument, but haven't received a response yet.


Here's the 2nd part of the answer:

[EMAIL PROTECTED] wrote:
> Hi Matthew,
>
> 
>
> Then again, there's the Solaris distribution from Sun Microsystems.
> Sun's JDS
> has gnome-about. Here's the linkage from Solaris Express (that comes by
> the way
> on a single DVD):
>
> # cat /etc/release
>Solaris 11 nv_16 X86
>Copyright 2005 Sun Microsystems, Inc.  All Rights Reserved.
> Use is subject to license terms.
>  Assembled 01 June 2005
>
> # which gnome-about
> /usr/bin/gnome-about
> # ldd `which gnome-about` | grep libc
> libc.so.1 => /lib/libc.so.1
> libcrypto.so.0.9.7 =>/usr/sfw/lib/libcrypto.so.0.9.7
> libcrypto_extra.so.0.9.7 =>
> /usr/sfw/lib/libcrypto_extra.so.0.9.7
>
> # /usr/ccs/bin/mcs -p `which gnome-about`
> /usr/bin/gnome-about:
>
> 2.6.0:JDS3:SUNWgnome-panel:i386:2005-05-16:supported
>
>
> The question is, are you going to pursue a legal action against Sun
> Microsystems?
>
> Best regards!
>
> Nexenta Systems, Inc.


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

Re: Debian based GNU/Solaris: pilot program

[Matthew Garrett]

On Mon, Nov 07, 2005 at 02:50:01PM -0800, Alex Ross wrote:

> Here's the 2nd part of the answer:
> 
> [EMAIL PROTECTED] wrote:

> > The question is, are you going to pursue a legal action against Sun
> > Microsystems?

To which my answer was "yes". I'm not sure how that's supposed to excuse 
you in any way.
-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: Debian based GNU/Solaris: pilot program

[Matthew Garrett]

(Oh, and please don't see this as any sort of bias against non-Linux 
kernels or non-glibc systems - I spent quite some time working on a port 
of Debian to the NetBSD kernel, using the native C library)

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Processed: Re: Bug#338033: general: wmifs and wmii try to overwrite each other

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 338033 wmii
Bug#338033: general: wmifs and wmii try to overwrite each other
Bug reassigned from package `general' to `wmii'.

> severity 338033 serious
Bug#338033: general: wmifs and wmii try to overwrite each other
Severity set to `serious'.

> severity 335446 serious
Bug#335446: wmii fails to install because it conflicts with wmifs.
Severity set to `serious'.

> merge 338033 33546
Bug number 33546 not found.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
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]

> David Schmitt writes:
>> I have downloaded the elatte_live_prealpha1_x86.iso.gz[1] from your
>> website
>> and found a dpkg binary on it.
>
>> Much to my dismay I was not able to locate the source for this binary,
>> despite it being obviously under the GPL[2].
>
> Was the requisite written offer included?  Would you be willing to check
> the CD for other GPL software and notify the authors if you find any?

you can check, than re-check again and again, Nexenta OS GNU/OpenSolaris
is a complete open source project and going to be developed by the
community. Any source code changes will be released back to the community
as per GPL/CDDL.

Erast


-- 
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]

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

>> Was the requisite written offer included?  Would you be willing to check
>> the CD for other GPL software and notify the authors if you find any?
>
> you can check, than re-check again and again, Nexenta OS GNU/OpenSolaris
> is a complete open source project and going to be developed by the
> community. Any source code changes will be released back to the community
> as per GPL/CDDL.

What is this "will be"?  You are distributing binaries now; you must
therefore distribute the complete source now, under terms compatible
with the GPL.


-- 
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]

> "Erast Benson" <[EMAIL PROTECTED]> writes:
>
>>> Was the requisite written offer included?  Would you be willing to
>>> check
>>> the CD for other GPL software and notify the authors if you find any?
>>
>> you can check, than re-check again and again, Nexenta OS GNU/OpenSolaris
>> is a complete open source project and going to be developed by the
>> community. Any source code changes will be released back to the
>> community
>> as per GPL/CDDL.
>
> What is this "will be"?  You are distributing binaries now; you must
> therefore distribute the complete source now, under terms compatible
> with the GPL.

You are welcome to obtain account at the web portal and check out the
source directly from SVN.

Erast


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

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

[Francesco Poli]

[Added Cc: debian-legal, because the topic may be of interest there,
I would say.]
[No need to Cc: me, as long as you keep Cc:ing debian-legal (just to
make things clear: I am subscribed to debian-legal, but not to
debian-devel)]



On Mon, 7 Nov 2005 10:01:48 +0100 Andreas Schuldei wrote:

> Fine Print Publication Rights
> 
> Debconf requires non-exclusive publication rights to papers,
> presentations, and any additional handouts or audio/visual materials
> used in conjunction with the presentation. The authors have the
> freedom to pick a DFSG-free license for the papers themselves and
> retain all copyrights.

"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?


> The presentations will be recorded, and may be broadcast over the
> Internet. Any copies of the presentation will be made available under
> a license like the MIT/X11 license.

This refers to audio/video recordings, IIUC.
It seems that the same rules adopted for DebConf5 still hold for
DebConf6.
Good.

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpHsvUcbzJHS.pgp
Description: PGP signature

Re: Request: Source for parts of GNU/Solaris

[Thomas Bushnell BSG]

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

>> What is this "will be"?  You are distributing binaries now; you must
>> therefore distribute the complete source now, under terms compatible
>> with the GPL.
>
> You are welcome to obtain account at the web portal and check out the
> source directly from SVN.

Is it necessary to obtain an account to get the binaries?  

The source for the complete binary must be available.  Please see the
original request, which you have not honored.


-- 
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]

> "Erast Benson" <[EMAIL PROTECTED]> writes:
>
>>> What is this "will be"?  You are distributing binaries now; you must
>>> therefore distribute the complete source now, under terms compatible
>>> with the GPL.
>>
>> You are welcome to obtain account at the web portal and check out the
>> source directly from SVN.
>
> Is it necessary to obtain an account to get the binaries?
>
> The source for the complete binary must be available.  Please see the
> original request, which you have not honored.

actually, I just checked. anonymous access is granted. Just browse it at
http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1

I hope I "honored" your orignal request now. :-)


-- 
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]

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

> actually, I just checked. anonymous access is granted. Just browse it at
> http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1
>
> I hope I "honored" your orignal request now. :-)

It was not my request.  Where is the C library, and is it being
distributed under terms compatible with the GPL?


-- 
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]

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

> actually, I just checked. anonymous access is granted. Just browse it at
> http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1

Specifically requested were the source for libintl.so.3,
libiconv.so.2, libc.so.1, libz.so, libbz2.so.1.0, and libgcc_s.so.1,
which must be provided under terms no more restrictive than GPL
sections one and two.

Thomas


-- 
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]

> "Erast Benson" <[EMAIL PROTECTED]> writes:
>
>> actually, I just checked. anonymous access is granted. Just browse it at
>> http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1
>
> Specifically requested were the source for libintl.so.3,
> libiconv.so.2, libc.so.1, libz.so, libbz2.so.1.0, and libgcc_s.so.1,
> which must be provided under terms no more restrictive than GPL
> sections one and two.

http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1/gnu

its in progress process, we are moving gnusolaris1/gnu code to ..
you have to look at both directories at this point. Sorry for inconvenience.
Also some stuff not committed yet, becase we are testing them.

In 2-3 months we are hoping to sort out all these "starting" issues with code
browsing, scripts availability, etc.

Erast



-- 
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]

Dear Alex!

On Monday 07 November 2005 21:58, Alex Ross wrote:
> John Hasler wrote:
> > David Schmitt writes:
> >> I have downloaded the elatte_live_prealpha1_x86.iso.gz[1] from your
> >> website and found a dpkg binary on it.
> >>
> >> Much to my dismay I was not able to locate the source for this binary,
> >> despite it being obviously under the GPL[2].
> >
> > Was the requisite written offer included?  Would you be willing to check
> > the CD for other GPL software and notify the authors if you find any?
>
> It's a bug, bad link on a generated page.
>
> Here's the correct link:
>
> http://www.gnusolaris.org/apt/dists/unstable/main/source/base/
>
> We'll look more into this. Thanks for the notice!

Thank you for your fast response!

I took a look at the URL you provided and still have the following problems:

* I found the files dpkg_1.13.10-0gnusol2.dsc and dpkg_1.13.10-0gnusol2.tar.gz 
which declare a Build-Dependency on libncurses5-dev | libncurses-dev. Neither 
of which can be satisfied using your Sources file from 
http://www.gnusolaris.org/apt/dists/unstable/main/source/Sources

* Since this is based on Debian, I expected to find a build-essential package 
detailling further build requirements. I was not able to find such. Please 
consider adding such a package as a service to your users as well as 
documentation for your further obligations under the GPL Section 2.

* Further I downloaded some of the sunw* source packages which all seem to be 
empty except for some boilerplate code under the respective debian/ 
directories.

Thus I kindly request you to supply the sources for the full development 
environment (including headers, scripts, kernel, compiler and libraries) 
since most of these seem to accompany dpkg on the distributed ISO.

* While browsing through your I couldn't find source for your version 
(0.6.40.1-1.1) of apt nor your version of debhelper (4.9.3elatte), since both 
are GPL and the latter is even a build-dependency for some of the sunw* 
packages I kindly request that you fullfill your obligation under the GPL 
that you provide the sources for these packages too.


Regards, David Schmitt
-- 
- 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: Request: Source for parts of GNU/Solaris

[Erast Benson]

David,

this is the place were source code lives:

http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1/gnu

or

http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1

If you do not see something specific, or newer versions, like(you can find
debarchiver-0.3 but we have debarchiver-0.4 packaged), that means it is
not committed yet and we are testing it right now and will be committed
shortly.

Erast

> Dear Alex!
>
> On Monday 07 November 2005 21:58, Alex Ross wrote:
>> John Hasler wrote:
>> > David Schmitt writes:
>> >> I have downloaded the elatte_live_prealpha1_x86.iso.gz[1] from your
>> >> website and found a dpkg binary on it.
>> >>
>> >> Much to my dismay I was not able to locate the source for this
>> binary,
>> >> despite it being obviously under the GPL[2].
>> >
>> > Was the requisite written offer included?  Would you be willing to
>> check
>> > the CD for other GPL software and notify the authors if you find any?
>>
>> It's a bug, bad link on a generated page.
>>
>> Here's the correct link:
>>
>> http://www.gnusolaris.org/apt/dists/unstable/main/source/base/
>>
>> We'll look more into this. Thanks for the notice!
>
> Thank you for your fast response!
>
> I took a look at the URL you provided and still have the following
> problems:
>
> * I found the files dpkg_1.13.10-0gnusol2.dsc and
> dpkg_1.13.10-0gnusol2.tar.gz
> which declare a Build-Dependency on libncurses5-dev | libncurses-dev.
> Neither
> of which can be satisfied using your Sources file from
> http://www.gnusolaris.org/apt/dists/unstable/main/source/Sources
>
> * Since this is based on Debian, I expected to find a build-essential
> package
> detailling further build requirements. I was not able to find such. Please
> consider adding such a package as a service to your users as well as
> documentation for your further obligations under the GPL Section 2.
>
> * Further I downloaded some of the sunw* source packages which all seem to
> be
> empty except for some boilerplate code under the respective debian/
> directories.
>
> Thus I kindly request you to supply the sources for the full development
> environment (including headers, scripts, kernel, compiler and libraries)
> since most of these seem to accompany dpkg on the distributed ISO.
>
> * While browsing through your I couldn't find source for your version
> (0.6.40.1-1.1) of apt nor your version of debhelper (4.9.3elatte), since
> both
> are GPL and the latter is even a build-dependency for some of the sunw*
> packages I kindly request that you fullfill your obligation under the GPL
> that you provide the sources for these packages too.
>
>
> Regards, David Schmitt
> --
> - 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
>
>



-- 
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]

Erast Benson <[EMAIL PROTECTED]> wrote:

> If you do not see something specific, or newer versions, like(you can find
> debarchiver-0.3 but we have debarchiver-0.4 packaged), that means it is
> not committed yet and we are testing it right now and will be committed
> shortly.

Erast,

Unless you provide a written offer, good for three years, to supply the
source on request, you *must* provide the source code for a binary
alongside the binary. That means that the source code for a specific
version of the binary must be downloadable before you can provide that
binary. Providing binaries without the appropriate source code (as
required under 3(a) of the GPL) or a written offer for the same (GPL
3(b)) is a violation of the license, and thus infringes the copyright of
the authors. 

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: [Fwd: Re: Debian based GNU/Solaris: pilot program]

[Gustavo Noronha Silva]

Em Qui, 2005-11-03 às 12:45 -0800, Erast Benson escreveu:
> Apparently you misunderstood me.
> All I'm saying is that Debian community might want to embrace
> GNU/Solaris non-glibc port or reject it. To embrace, some core
> components, like dpkg, should be dual-licensed CDDL/GPL.

I say let's reject it.

Let Sun do the rethinking.

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:    *  



signature.asc
Description: Esta é uma parte de mensagem	assinada digitalmente

Bug#338058: ITP: markdown -- text-to-HTML conversion tool for web writers

[Pierre THIERRY]

Package: wnpp
Severity: wishlist
Owner: Pierre THIERRY <[EMAIL PROTECTED]>

* Package name: markdown
  Version : 1.0.1
  Upstream Author : John Gruber <[EMAIL PROTECTED]>
* URL : http://daringfireball.net/projects/markdown/
* License : BSD-style
  Description : text-to-HTML conversion tool for web writers

Markdown is a text-to-HTML conversion tool for web writers. Markdown
allows you to write using an easy-to-read, easy-to-write plain text
format, then convert it to structurally valid XHTML (or HTML).

Thus, "Markdown" is two things: a plain text markup syntax, and a
software tool, written in Perl, that converts the plain text markup 
to HTML.

Markdown works both as a Movable Type plug-in and as a standalone Perl
script -- which means it can also be used as a text filter in BBEdit
(or any other application that supporst filters written in Perl).

Quickly,
Nowhere man
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature

Re: Request: Source for parts of GNU/Solaris

[Erast Benson]

> Erast Benson <[EMAIL PROTECTED]> wrote:
>
>> If you do not see something specific, or newer versions, like(you can
>> find
>> debarchiver-0.3 but we have debarchiver-0.4 packaged), that means it is
>> not committed yet and we are testing it right now and will be committed
>> shortly.
>
> Erast,
>
> Unless you provide a written offer, good for three years, to supply the
> source on request, you *must* provide the source code for a binary
> alongside the binary. That means that the source code for a specific
> version of the binary must be downloadable before you can provide that
> binary. Providing binaries without the appropriate source code (as
> required under 3(a) of the GPL) or a written offer for the same (GPL
> 3(b)) is a violation of the license, and thus infringes the copyright of
> the authors.

OK. point taken. This will be "fixed" soon. Hopefully in Alpha 1, which
bits is planned to be release by the end of this week.

Erast


-- 
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]

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

>> "Erast Benson" <[EMAIL PROTECTED]> writes:
>>
>>> actually, I just checked. anonymous access is granted. Just browse it at
>>> http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1
>>
>> Specifically requested were the source for libintl.so.3,
>> libiconv.so.2, libc.so.1, libz.so, libbz2.so.1.0, and libgcc_s.so.1,
>> which must be provided under terms no more restrictive than GPL
>> sections one and two.
>
> http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1/gnu
>
> its in progress process, we are moving gnusolaris1/gnu code to ..
> you have to look at both directories at this point. Sorry for inconvenience.
> Also some stuff not committed yet, becase we are testing them.

That is not acceptible.  You must immediately take down the binaries
if you cannot NOW provide the source.

> In 2-3 months we are hoping to sort out all these "starting" issues with code
> browsing, scripts availability, etc.

That is not acceptible.  If you are not providing the source now, then
you must immediately remove the binaries.


-- 
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]

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

> OK. point taken. This will be "fixed" soon. Hopefully in Alpha 1, which
> bits is planned to be release by the end of this week.

That is not acceptible.  You must fix it now, not soon.  You can fix
it by, for example, removing the binaries you are distributing.


-- 
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]

Dear Erast!

On Tuesday 08 November 2005 01:01, Erast Benson wrote:
> > Specifically requested were the source for libintl.so.3,
> > libiconv.so.2, libc.so.1, libz.so, libbz2.so.1.0, and libgcc_s.so.1,
> > which must be provided under terms no more restrictive than GPL
> > sections one and two.
>
> http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1/gnu
>
> its in progress process, we are moving gnusolaris1/gnu code to ..
> you have to look at both directories at this point. Sorry for
> inconvenience. Also some stuff not committed yet, becase we are testing
> them.
>
> In 2-3 months we are hoping to sort out all these "starting" issues with
> code browsing, scripts availability, etc.

The GPL specifically requests that offers for download are made "offering 
equivalent access to copy the source code from the same place". While I 
appreciate the fine source control browser, I really cannot download the 
whole sources over this interface. Notwithstanding the technical 
difficulties, 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.

Further I also couldn't find the Sources for the sunw* packages needed to 
build the rest of the build requirements.

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: Request: Source for parts of GNU/Solaris

[Erast Benson]

> Dear Erast!
>
> On Tuesday 08 November 2005 01:01, Erast Benson wrote:
>> > Specifically requested were the source for libintl.so.3,
>> > libiconv.so.2, libc.so.1, libz.so, libbz2.so.1.0, and libgcc_s.so.1,
>> > which must be provided under terms no more restrictive than GPL
>> > sections one and two.
>>
>> http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1/gnu
>>
>> its in progress process, we are moving gnusolaris1/gnu code to ..
>> you have to look at both directories at this point. Sorry for
>> inconvenience. Also some stuff not committed yet, becase we are testing
>> them.
>>
>> In 2-3 months we are hoping to sort out all these "starting" issues with
>> code browsing, scripts availability, etc.
>
> The GPL specifically requests that offers for download are made "offering
> equivalent access to copy the source code from the same place". While I
> appreciate the fine source control browser, I really cannot download the
> whole sources over this interface. Notwithstanding the technical
> difficulties

www.gnusolaris.org is *the same place*.

 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?

Erast


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

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

[Brian M. Carlson]

On Monday 07 November 2005 11:28 pm, Francesco Poli wrote:
> [Added Cc: debian-legal, because the topic may be of interest there,
> I would say.]
> [No need to Cc: me, as long as you keep Cc:ing debian-legal (just to
> make things clear: I am subscribed to debian-legal, but not to
> debian-devel)]
> > used in conjunction with the presentation. The authors have the
> > freedom to pick a DFSG-free license for the papers themselves and
> > retain all copyrights.
>
> "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?

The way I read it was that "the authors may pick any license, so long as it's 
DFSG-free".  Do you see how it could be read that way?

Now, because they are the copyright holders, they could additionally license 
it in some other way, too.  But they must at least offer a DFSG-free license.

-- 
Brian M. Carlson <[EMAIL PROTECTED]>
Running on GNU/kFreeBSD; i686-pc-kfreebsd-gnu
Support alternative kernels in Debian!


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

Re: per-user temp directories by default?

[Brian M. Carlson]

On Saturday 05 November 2005 11:27 pm, Brian May wrote:
> Can't we just pick one standard name for the environment variable and
> stick to it?

If we do that, I'd request that it be $TMPDIR, as that's what SUSv3 has 
standardized.

-- 
Brian M. Carlson <[EMAIL PROTECTED]>
Running on GNU/kFreeBSD; i686-pc-kfreebsd-gnu
Support alternative kernels in Debian!


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

Re: device nodes with udev?

[Miles Bader]

Peter Samuelson <[EMAIL PROTECTED]> writes:
> /dev/{pts/,ptmx} are so trivial to support (in applications) that I
> think it's worthwhile to disable legacy BSD pty support in Debian
> kernels, and fix whatever still breaks.  That is, unless we think there
> are still a significant number of third-party non-free apps out there
> still using them.

There's a pretty easy way to find out...
[and now seems to be the time in the release cycle to do it.]

> Likewise, I'd also support having udev ship a rule which by default
> ignores /dev/{tty,pty}[p-za-e]*.

Yeah, me too.

-miles
-- 
I'd rather be consing.


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

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

[Adam Heath]

On Tue, 8 Nov 2005, Brian M. Carlson wrote:

> The way I read it was that "the authors may pick any license, so long as it's
> DFSG-free".  Do you see how it could be read that way?

You sound just like Henry Ford.


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

Bug#338077: ITP: sword-text-kvj -- King James Version with Strongs Numbers and Morphology

[Roberto C. Sanchez]

Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: sword-text-kvj
  Version : 2.2
  Upstream Author : CrossWire Bible Society <[EMAIL PROTECTED]>
* URL : 
http://www.crosswire.org/sword/modules/ModInfo.jsp?modName=KJV
* 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. The Strong's numbers in the
OT were obtained from The Bible Foundation: http://www.bf.org. The NT
Strong's data was obtained from The KJV2003 Project at CrossWire:
http://www.crosswire.org. These mechanisms provide a useful means for
looking up the exact original language word in a lexicon that is keyed
to Strong's numbers.

- -- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-miami-16
Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1)

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

iD8DBQFDcASejqO5DLK5e7ERAoVYAKCkTgTNT/WgT8xhS2ZuDR2MeE3WkQCdHYgU
s2koEbDtlPwuFFQ+j73TyHg=
=jDR0
-END PGP SIGNATURE-


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

Bug#338079: ITP: sword-text-rv -- Spanish Reina-Valera (1909) Bible for SWORD

[Roberto C. Sanchez]

Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: sword-text-rv
  Version : 1.0
  Upstream Author : Crosswire Bible Society <[EMAIL PROTECTED]>
* URL : 
http://www.crosswire.org/sword/modules/ModInfo.jsp?modName=SpaRV
* License : Public Domain
  Description : Spanish Reina-Valera Bible (1909) for SWORD

The Reina-Valera Bible (1909) is a Spanish Bible translation based on
the Textus Receptus.

- -- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-miami-16
Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1)

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

iD8DBQFDcAZnjqO5DLK5e7ERAu8fAJ9Ln6lmiwR+6898LONG8T1vI7GycgCfYUuU
CeSxnjWXugjpR0EAWiLQLkg=
=ye3V
-END PGP SIGNATURE-


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

Bug#338080: ITP: sword-strongs-greek -- Strong's Greek Bible Dictionary for SWORD

[Roberto C. Sanchez]

Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: sword-strongs-greek
  Version : 1.2
  Upstream Author : Crosswire Bible Society <[EMAIL PROTECTED]>
* URL : 
http://www.crosswire.org/sword/modules/ModInfo.jsp?modName=StrongsGreek
* License : Public Domain
  Description : Strong's Greek Bible Dictionary for SWORD

 Dictionary of Greek Words taken from Strong's Exhaustive Concordance by
 James Strong, S.T.D., LL.D. 1890.

- -- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-miami-16
Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1)

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

iD8DBQFDcAcIjqO5DLK5e7ERApSfAKDTS5b0dJpm+zmDiZfC5Ks6e9ORdgCbBo3b
pu0VcE+3p89XLuc83e1gIFo=
=gi8A
-END PGP SIGNATURE-


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

Bug#338083: ITP: sword-strongs-hebrew -- Strong's Hebrew Bible Dictionary

[Roberto C. Sanchez]

Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: sword-strongs-hebrew
  Version : 1.2
  Upstream Author : Crosswire Bible Society <[EMAIL PROTECTED]>
* URL : 
http://www.crosswire.org/sword/modules/ModInfo.jsp?modName=StrongsHebrew
* License : Public Domain
  Description : Strong's Hebrew Bible Dictionary

 Dictionaries of Hebrew Words taken from Strong's Exhaustive Concordance by
 James Strong, S.T.D., LL.D. 1890

- -- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-miami-16
Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1)

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

iD8DBQFDcAd/jqO5DLK5e7ERAlClAJ9x8RogvhnWrsog+vGd1UL6c85hWACePpQs
LOjaVg3+7L9MAqL9fuDEKQU=
=d/uO
-END PGP SIGNATURE-


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

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

[Brian M. Carlson]

On Tuesday 08 November 2005 01:58 am, Adam Heath wrote:
> On Tue, 8 Nov 2005, Brian M. Carlson wrote:
> > The way I read it was that "the authors may pick any license, so long as
> > it's DFSG-free".  Do you see how it could be read that way?
>
> You sound just like Henry Ford.

My goal was to do exactly that.  I was hoping someone would catch it. :-)

-- 
Brian M. Carlson <[EMAIL PROTECTED]>
Running on GNU/kFreeBSD; i686-pc-kfreebsd-gnu
Support alternative kernels in Debian!


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

Re: Request: Source for parts of GNU/Solaris

[Alexander Schmehl]

Hi!

* Erast Benson <[EMAIL PROTECTED]> [051108 01:48]:

> > (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?

Uhm... I don't understand...  if it is only available for developer, why
are they on a disc image, publicaly available for everyone?

And how I should I decide if I want to be a developer and help you, if
can't take a look at it, and see if I can be of helpt?

Just curious...

Yours sincerely,
  Alexander

-- 
http://learn.to/quote/
http://www.catb.org/~esr/faqs/smart-questions.html


signature.asc
Description: Digital signature

Re: Request: Source for parts of GNU/Solaris

[cascardo]

On Mon, Nov 07, 2005 at 04:48:52PM -0800, Erast Benson wrote:
> > Dear Erast!
> >
> > On Tuesday 08 November 2005 01:01, Erast Benson wrote:
> >> > Specifically requested were the source for libintl.so.3,
> >> > libiconv.so.2, libc.so.1, libz.so, libbz2.so.1.0, and libgcc_s.so.1,
> >> > which must be provided under terms no more restrictive than GPL
> >> > sections one and two.
> >>
> >> http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1/gnu
> >>
> >> its in progress process, we are moving gnusolaris1/gnu code to ..
> >> you have to look at both directories at this point. Sorry for
> >> inconvenience. Also some stuff not committed yet, becase we are testing
> >> them.
> >>
> >> In 2-3 months we are hoping to sort out all these "starting" issues with
> >> code browsing, scripts availability, etc.
> >
> > The GPL specifically requests that offers for download are made "offering
> > equivalent access to copy the source code from the same place". While I
> > appreciate the fine source control browser, I really cannot download the
> > whole sources over this interface. Notwithstanding the technical
> > difficulties
> 
> www.gnusolaris.org is *the same place*.
> 

[...] *equivalent* access [...]

If binaries are distributed in an ISO image, you should distribute the
sources in an ISO image too.

> 
> Erast
> 
> 

Thadeu Cascardo.
--


signature.asc
Description: Digital signature

Re: Request: Source for parts of GNU/Solaris

[Erast Benson]

> On Mon, Nov 07, 2005 at 04:48:52PM -0800, Erast Benson wrote:
>> > Dear Erast!
>> >
>> > On Tuesday 08 November 2005 01:01, Erast Benson wrote:
>> >> > Specifically requested were the source for libintl.so.3,
>> >> > libiconv.so.2, libc.so.1, libz.so, libbz2.so.1.0, and
>> libgcc_s.so.1,
>> >> > which must be provided under terms no more restrictive than GPL
>> >> > sections one and two.
>> >>
>> >> http://www.gnusolaris.org/cgi-bin/trac.cgi/browser/gnusolaris1/gnu
>> >>
>> >> its in progress process, we are moving gnusolaris1/gnu code to ..
>> >> you have to look at both directories at this point. Sorry for
>> >> inconvenience. Also some stuff not committed yet, becase we are
>> testing
>> >> them.
>> >>
>> >> In 2-3 months we are hoping to sort out all these "starting" issues
>> with
>> >> code browsing, scripts availability, etc.
>> >
>> > The GPL specifically requests that offers for download are made
>> "offering
>> > equivalent access to copy the source code from the same place". While
>> I
>> > appreciate the fine source control browser, I really cannot download
>> the
>> > whole sources over this interface. Notwithstanding the technical
>> > difficulties
>>
>> www.gnusolaris.org is *the same place*.
>>
>
> [...] *equivalent* access [...]
>
> If binaries are distributed in an ISO image, you should distribute the
> sources in an ISO image too.

OK. Thanks. Working on it right now.

Erast


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

Re: Request: Source for parts of GNU/Solaris

[Steve Langasek]

On Mon, Nov 07, 2005 at 04:48:52PM -0800, Erast Benson wrote:

>  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.

Sorry, but that doesn't mean it's your choice to not distribute the source
which matches the binaries.  If you haven't tested it enough to be willing
to release the GPL source, then you shouldn't be releasing binaries either.

-- 
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

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

[Manoj Srivastava]

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?

Back to the regularly schedules press release.

This version of kernel-package has been largely
 reorganized. The crusty old mechanism has beenremoved, the targets
 are now streamlined. One of the factors that made the build mechanism
 so complex was that the rules file had a dual purpose: Initially,
 when ./debian was not present or not populated, it was responsible
 for populating that, and then it was responsible for building the
 kernel packages, incorporating any user customizations.

Also, this version implements the new ramdisk generation tool
 finding plan. The ramdisk variable in /etc/kernel-pkg.conf or
 /etc/kernel-img.conf can now be a space separated list of init ram
 disk creation commands, which need to also support the
 --supported-host-version and --supported-target-version options, just
 like mkinitrd does. The list in /etc/kernel-pkg.conf is used to set
 defaults (by setting INITRD_CMD). However, the defaults are set to a
 subset of "mkinitrd mkinitrd.yaird mkinitramfs", the subset being
 decided based on the version of the kernel being built, so one should
 refrain from setting this manually -- unless one knows what one is
 doing.  The list in /etc/kernel-img.conf is the list tried at
 installation time.

The stem used for the kernel-related packages is now set to
 $DEB_HOST_OS -- so we create kfreebsd-image-foo or linux-image-foo
 packages, for instance.

The kernel image maintainer scripts now use  debconf; and a
 number of questions have been moved to the config file while others
 are asked conditionally in the postinst. The postinst has also become
 far less verbose.

The postinst gets rid of the code that generated boot floppies
 and created lilo.conf (that latter was probably illegal under current
 policy anyway). The do_boot_enable and do_boot_floppy configuration
 variables in /etc/kernel-img.conf are now invalid.


Also, the source tree is not automatically cleaned; the
 do_clean configuration variable, and the environment variable
 CLEAN_SOURCE, now control if the source tree is optionally cleaned
 after the kernel image package is built.

We now take special care of the case in which the
 kernel-headers are installed after the kernel-image has been; and the
 build symlink is not setr. In this case, the header postinst now
 correctly installs the build symlink.

Another fallout from the kernel-package generated packages
 being made lintian clean is that it was noticed that the default
 versioning was such that the packages appeared to be Debian native,
 obviously not the case. It now generates a proper $version-$debian
 version, unless over ridden.

manoj
  
-- 
A hammer sometimes misses its mark - a bouquet never.
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#338092: ITP: kompile -- KDE automatic installer for source packages

[Felipe Sateler]

Package: wnpp
Severity: wishlist
Owner: Felipe Sateler <[EMAIL PROTECTED]>


* Package name: kompile
  Version : 0.2
  Upstream Author : Tommaso Frazzetto <[EMAIL PROTECTED]>
* URL : http://www.kde-apps.org/content/show.php?content=30223
* License : GPL
  Description : KDE automatic installer for source packages

Kompile is a KDE interface for automatic execution of
configuration, compilation and installation of source tarballs.
It adds a KDE service menu so as to right click a source tarball
and automatically install or remove a package.   

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-k7
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]

Re: Request: Source for parts of GNU/Solaris

[Erast Benson]

> On Mon, Nov 07, 2005 at 04:48:52PM -0800, Erast Benson wrote:
>
>>  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.
>
> Sorry, but that doesn't mean it's your choice to not distribute the source
> which matches the binaries.  If you haven't tested it enough to be willing
> to release the GPL source, then you shouldn't be releasing binaries
> either.

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.

Erast


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

Bug#338094: ITP: sword-comm-scofield -- Scofield Reference Notes, 1917 Edition for SWORD

[Roberto C. Sanchez]

Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: sword-comm-scofield
  Version : 1.0
  Upstream Author : Crosswire Bible Society <[EMAIL PROTECTED]>
* URL : 
http://www.crosswire.org/sword/modules/ModInfo.jsp?modName=Scofield
* License : Public Domain
  Description : Scofield Reference Notes, 1917 Edition for SWORD

Scofield Reference Notes, 1917 Edition Based on the version at
http://bible.crosswalk.com/ with formatting changes and corrections.

- -- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-miami-16
Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1)

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

iD8DBQFDcB4gjqO5DLK5e7ERAhVyAJ44td0J2BIt31oKTttTx8VDDFkBIACdG/a4
dD8Ab5nyaYD9A5aUy31Qnls=
=Kn5o
-END PGP SIGNATURE-


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

Bug#338095: ITP: sword-comm-tdavid -- C. H. Spurgeon's Treasury of David for SWORD

[Roberto C. Sanchez]

Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: sword-comm-tdavid
  Version : 1.1
  Upstream Author : Crosswire Bible Society <[EMAIL PROTECTED]>
* URL : 
http://www.crosswire.org/sword/modules/ModInfo.jsp?modName=TDavid
* License : Public Domain
  Description : C. H. Spurgeon's Treasury of David for SWORD

This seven volume "magnum opus", by Charles H. Spurgeon, was first
published in weekly installments over a twenty-year span in the London
Metropolitan Tabernacle's periodical, The Sword and the Trowel. As each
section was completed it was published as a volume until the seventh and
final volume was released in 1885.

- -- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-miami-16
Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1)

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

iD8DBQFDcB5vjqO5DLK5e7ERAlm4AKCjSB0YOM4z7ueEZxyCrc7iT6ENPwCePja0
/Nrr4e7SSOC0x/n8zxlIQkk=
=5/R/
-END PGP SIGNATURE-


-- 
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]

"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*.  


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

Re: Request: Source for parts of GNU/Solaris

[Matthew Palmer]

On Mon, Nov 07, 2005 at 07:35:11PM -0800, Steve Langasek wrote:
> On Mon, Nov 07, 2005 at 04:48:52PM -0800, Erast Benson wrote:
> 
> >  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.
> 
> Sorry, but that doesn't mean it's your choice to not distribute the source
> which matches the binaries.  If you haven't tested it enough to be willing
> to release the GPL source, then you shouldn't be releasing binaries either.

WhatSteveSaid++.

Also, it's even *more* important to release source whenever you're producing
binaries for "developer testing".  How are developers supposed to help test
and debug the program if they can't use the source to identify the problems
and fix them?

- Matt


signature.asc
Description: Digital signature

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

[Christian Perrier]

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?

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

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).


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