Bug#974678: ITP: openh264 -- H.264 encoding and decoding

2021-06-02 Thread Walter Landry
Bastian Germann writes:
> Am 02.06.21 um 17:33 schrieb Tobias Frost:
>> Is this RFS package now a downloader or the library itself?
>
> It's both. The -dev package is created from the source files and
> resides in main. The library package contains the downloader as a
> postinst script, which checks the known SHA256 hashes.
> There are some example userspace tools available in the package which
> could potentially be packaged in an additional package. I left this
> for a later version.
>
> There is also a chance that reproducible build might be implemented:
> https://github.com/cisco/openh264/issues/893
> When that works, the package could build the lib, verify the resulting
> hashes, and throw away the built binary. That way we could be sure not
> to have any additions to the downloaded library that are not available
> as source.
>
> I think, as Cisco provides the patent license, having the downloader
> in contrib (for some architectures) is better than having the built
> library in main (for all compiling architectures). We could also
> provide both. Any thoughts?

As I understand Debian Policy, downloading anything during postinst is
discouraged, if not banned.  So it would be best to avoid it.

In terms of the patent license, I do not think that x264 has any special
dispensation.  So just directly building and packaging openh264 should
not open Debian to any significant additional liability.  But as always,
the FTP masters will be the final arbiter of that.

Cheers,
Walter



Bug#884592: [Pkg-fonts-devel] Bug#884592 fonts-fantasque-sans: variants use the same name, making them unusable in most programs

2020-08-29 Thread Walter Landry
Hello,

I just ran into this bug.  When set up by default, I get the
LargeLineHeight variant, which is definitely not what I want.  When
using Font Manager or Gnome Tweaks, it is really not clear to me how I
can even select other variants.  So, for what it is worth, my vote is to
have separate named variants.  Right now, running fc-list, I get the
font names

Fantasque Sans Mono:style=Bold
Fantasque Sans Mono:style=Bold Italic
Fantasque Sans Mono:style=Italic
Fantasque Sans Mono:style=Regular

To incorporate the NoLoopK and LargeLineHeight variants, I would propose
the names:

Fantasque Sans Mono:style=Regular
Fantasque Sans NoLoopK Mono:style=Regular
Fantasque Sans LargeLineHeight Mono:style=Regular
Fantasque Sans LargeLineHeight NoLoopK Mono:style=Regular

Fantasque Sans Mono:style=Bold Italic
Fantasque Sans NoLoopK Mono:style=Bold Italic
Fantasque Sans LargeLineHeight Mono:style=Bold Italic
Fantasque Sans LargeLineHeight NoLoopK Mono:style=Bold Italic

Fantasque Sans Mono:style=Italic
Fantasque Sans NoLoopK Mono:style=Italic
Fantasque Sans LargeLineHeight Mono:style=Italic
Fantasque Sans LargeLineHeight NoLoopK Mono:style=Italic

Fantasque Sans Mono:style=Regular
Fantasque Sans NoLoopK Mono:style=Regular
Fantasque Sans LargeLineHeight Mono:style=Regular
Fantasque Sans LargeLineHeight NoLoopK Mono:style=Regular

If it would be helpful, I could put together a patch.

Thanks,
Walter Landry



Bug#700227: GIMP hangs

2018-08-09 Thread Walter Landry
FYI, if for whatever reason you do not want to uninstall
libopenblas-base, a workaround for this bug is to set

  OPENBLAS_NUM_THREADS=1

before running gimp.  Setting it to anything larger than 1 makes gimp
hang for me.

Cheers,
Walter Landry



Bug#902981: Font-Awesome 5 no build system DFSG compatibility

2018-07-19 Thread Walter Landry
Simon McVittie  writes:
>> Considering DFSG #2:
>> > The program must include source code, and must allow distribution in
>> > source code as well as compiled form.
>
> The "program" (package, module) includes source code: [x]
>
> The license allows distribution of that source code: [x]

You may or may not consider this dispositive, but the definition of
source code from GPL v3 is 

  The "Corresponding Source" for a work in object code form means all
  the source code needed to generate, install, and (for an executable
  work) run the object code and to modify the work, including scripts to
  control those activities.

So a makefile or equivalent is required.

On a more practical level, Debian has to be able to rebuild all of the
binaries from source.  If you can not do that, then that would be an RC
bug.

Cheers,
Walter Landry



Bug#891981: installation-report: Buster Alpha 2 on Thinkpad X1 Yoga Gen 3 (2018)

2018-03-03 Thread Walter Landry
Package: installation-reports
Version: 2.68
Severity: normal
Tags: d-i

Dear Maintainer,

-- Package-specific info:

Boot method: USB
Image version: Buster Alpha 2
Date: Feb 2018

Machine: Lenovo Thinkpad X1 Yoga Gen 3 (2018)
Partitions:
Filesystem Type 1K-blocks  Used Available Use% Mounted on
udev   devtmpfs   8070244 0   8070244   0% /dev
tmpfs  tmpfs  1616984 30360   1586624   2% /run
/dev/nvme0n1p2 ext4  57411424  21625372  32840004  40% /
tmpfs  tmpfs  8084912 0   8084912   0% /dev/shm
tmpfs  tmpfs 5120 4  5116   1% /run/lock
tmpfs  tmpfs  8084912 0   8084912   0% /sys/fs/cgroup
/dev/nvme0n1p4 ext4 909885976 288896076 574700492  34% /home
/dev/nvme0n1p1 vfat523248   132523116   1% /boot/efi
tmpfs  tmpfs  161698016   1616964   1% /run/user/116
tmpfs  tmpfs  1616980  5216   1611764   1% /run/user/1000



Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[E]
Configure network:  [E]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

The directions on how to create a bootable USB drive (Section
4.3.1) are slightly confusing.  When I plug in a USB drive, it
automounts under Gnome.  If I unmount it in Gnome, then I can not
'cp' the iso.  I have to run

umount /dev/sdb1

as root.  As a suggestion, you could add the text

  Important
  If Gnome has automounted the USB drive, you will have to
  manually unmount it first.  Do that manually as root (e.g. umount
  /dev/sdb1).  Do not unmount it within Gnome.

When initially booting, the screen went black.  I had to enable
CSM under UEFI to get it to work.  At that point, the text was
tiny, but workable.  After install, I was able to disable CSM and
everything still works.

I also tried setting the BIOS to Legacy, and that seemed to work
well.  The fonts were a reasonable size.

I had to disable Secure Boot, but I think that is expected.

In the course of all this, I tried changing the boot parameters.
The instructions say to press uppercase 'E', but only lowercase
'e' works.  Also, after typing 'e', I was unable to read the
instructions.  The background is very light in the center, and
the text is light.  So either the background or the font color
needs to be changed.

This machine has Intel wireless, which the installer detected.
It prompted me to install a USB stick.  I inserted an installer
image for Stretch which included firmware.  Oddly enough, after I
inserted the USB stick and pressed 'Enter' to continue, it always
asked again for firmware.  Pressing 'Enter' a second time made it
work.  This is different from my Thinkpad X230T, where the
firmware was detected the first time.

I tried using the wireless at work.  The authentication for the
network required WPA enterprise, which does not seem to be
supported by the installer.

During the install, the trackpoint worked, but the trackpad did
not.

I am still having problems getting my tablet functionality working 100%.
It works in MyPaint and Gnome Terminal, but not in Gimp.  I think it
is related to this bug

https://bugzilla.redhat.com/show_bug.cgi?id=1519961


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20171204"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux mechane 4.13.0-1-amd64 #1 SMP Debian 4.13.13-1 (2017-11-16) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5914] 
(rev 08)
lspci -knn: Subsystem: Lenovo Device [17aa:2259]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device 
[8086:5917] (rev 07)
lspci -knn: Subsystem: Lenovo Device [17aa:2259]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation 
Skylake Processor Thermal Subsystem [8086:1903] (rev 08)
lspci -knn: Subsystem: Lenovo Device [17aa:2259]
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Skylake 
Gaussian Mixture Model [8086:1911]
lspci -knn: Subsystem: Lenovo Device [17aa:2259]
lspci -knn: 00:13.0 Non-VGA unclassified device 

Bug#891973: installation-report: Buster Alpha 2 on Thinkpad X230T

2018-03-03 Thread Walter Landry
Package: installation-reports
Version: 2.68
Severity: normal
Tags: d-i

-- Package-specific info:

Boot method: USB
Image version: Buster Alpha 2
Date: Feb, 2018

Machine: Lenovo Thinkpad X230T
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Easiest Debian install I have ever done.

The installer autodetected the Intel wireless adapter and prompted me
to insert a USB drive for firmware.  I inserted a USB drive with the
Stretch installer which included firmware, and it was able to find the
firmware.

There is still a problem with Wayland and the tablet functionality
which I think is the same as this bug

https://bugzilla.redhat.com/show_bug.cgi?id=1519961

but that is not a problem with the installer.

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20171204"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux daikaiju 4.13.0-1-amd64 #1 SMP Debian 4.13.13-1 (2017-11-16) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core 
processor DRAM Controller [8086:0154] (rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:2203]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen 
Core processor Graphics Controller [8086:0166] (rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:2203]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 
Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:2203]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 7 
Series/C216 Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:2203]
lspci -knn: 00:16.3 Serial controller [0700]: Intel Corporation 7 Series/C210 
Series Chipset Family KT Controller [8086:1e3d] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:2203]
lspci -knn: Kernel driver in use: serial
lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM 
Gigabit Network Connection [8086:1502] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21f3]
lspci -knn: Kernel driver in use: e1000e
lspci -knn: Kernel modules: e1000e
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C216 
Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:2203]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C216 
Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:2203]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C216 Chipset 
Family PCI Express Root Port 1 [8086:1e10] (rev c4)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series 
Chipset Family PCI Express Root Port 2 [8086:1e12] (rev c4)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series 
Chipset Family PCI Express Root Port 3 [8086:1e14] (rev c4)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C216 
Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:2203]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation QM77 Express Chipset 
LPC Controller [8086:1e55] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:2203]
lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 7 Series Chipset 
Family 6-port SATA Controller [AHCI mode] [8086:1e03] (rev 04)
lspci -knn: 

Bug#853568: No idea how to fix abs arguments in nanopolish

2017-08-31 Thread Walter Landry
Andreas Tille <andr...@an3as.eu> wrote:
> Hi,
> 
> to fix bug #853568 I tried a patch (gcc-7.patch) to fix abs() arguments
> in nanopolish[1] but I have no idea how to deal with this:
> 
> ...
> g++ -o src/hmm/nanopolish_pore_model_set.o -c -g -O2 
> -fdebug-prefix-map=/build/nanopolish-0.5.0=. -fstack-protector-strong 
> -Wformat -Werror=format-security -g -O3 -std=c++11 -fopenmp -Wdate-t
> src/common/nanopolish_variant.cpp: In function 'std::vector 
> extract_variants(const string&, const string&)':
> src/common/nanopolish_variant.cpp:32:69: error: call of overloaded 
> 'abs(std::__cxx11::basic_string::size_type)' is ambiguous
>  size_t difference = std::abs(reference.size() - haplotype.size());

The result of subtracting two size_t's is still a size_t, which is
unsigned.  So you need to cast it to a signed type.  The correct type
is ptrdiff_t.

  http://en.cppreference.com/w/cpp/types/ptrdiff_t

The line then becomes

  size_t difference = std::abs(static_cast(reference.size() - 
haplotype.size()));

Or you could do it in two lines

  ptrdiff_t diff_signed (reference.size() - haplotype.size());
  size_t difference = std::abs(diff_signed);

Cheers,
Walter Landry



Bug#843717: ITP: tablator -- Universal table translator for astronomy

2016-11-08 Thread Walter Landry
Package: wnpp
Severity: wishlist
Owner: Walter Landry <wlan...@caltech.edu>

* Package name: tablator
  Version : 1.0.0
  Upstream Author : Walter Landry <wlan...@caltech.edu>
* URL : https://github.com/Caltech-IPAC/tablator
* License : GPL
  Programming Lang: C++
  Description : Universal table translator for astronomy

Tablator is a utility for converting tables in astronomy into
different formats.  Tablator can read and write tables in fits, ipac
table, hdf5, votable, json, json5, csv, and tsv, and can write html.
The emphasis is on speed, so all conversions are done in memory.



Bug#843570: ITP: json5-parser -- C++ library to parse JSON5

2016-11-07 Thread Walter Landry
Package: wnpp
Severity: wishlist
Owner: Walter Landry <wlan...@caltech.edu>

* Package name: json5-parser
  Version : 1.0.0
  Upstream Author : Walter Landry <wlan...@caltech.edu>
* URL : https://github.com/Caltech-IPAC/json5_parser
* License : MIT and BSD
  Programming Lang: C++
  Description : C++ library to parse JSON5

JSON5_Parser is a C++ library that reads and writes JSON5 and JSON
files or streams.  It is written using the Boost Spirit parser
generator.  If you are already using Boost, you can use JSON Spirit
without any additional dependencies.

JSON5_Parser is a fork of the JSON Spirit library, with enhancements
for reading JSON5.



Bug#841104: ITP: cspice -- C implementation of The SPICE Toolkit

2016-11-06 Thread Walter Landry
Rock Storm <rockst...@gmx.com> wrote:
> On Fri, 2016-11-04 at 17:23 -0700, Walter Landry wrote:
>> I replaced the build system with waf.  I have a waf package already.
>> Waf is a bit controversial in Debian, so I need to make an ITP and see
>> what the Debian consensus is.
> 
> I completely ignore waf and how it works, but I'll take a look at it,
> it seems promising.

FYI, I filed my waf ITP.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843325

For reasons I do not understand, it has yet to show up on
debian-devel.

> Even though it is a pain and feels outdated I was sticking to
> upstream's build system, I'd rather modify the source as little as
> possible.

In case it helps, I am attaching a Makefile that builds using the
upstream build system.  It is for a specialized setup we have here,
but should work with minor tweaks.  It does not build shared
libraries.

> As soon as the licensing issue is cleared up I'll upload my progress in
> case you'd like to review it and/or collaborate.

Are you in contact with upstream?

Cheers,
Walter Landry
INSTALL = install
INSTALL_PROGRAM = $(INSTALL) -m 755 -p
INSTALL_DATA = $(INSTALL) -m 644 -p
INSTALL_DIR = $(INSTALL) -m 755 -d

prefix=$(shell cd ../..; pwd)
exec_prefix=$(prefix)
bindir=$(exec_prefix)/bin
libdir=$(exec_prefix)/lib
includedir=$(prefix)/include/cspice
datadir=$(prefix)/data

all:  installdirs
if [ ! -d cspice/ ] ; then \
tar -xf dist/cspice.tar.Z ; \
else true ; \
fi
cd cspice; ./makeall.csh
$(INSTALL_PROGRAM) cspice/exe/* $(bindir)
rm -rf $(datadir)/*
$(INSTALL_DATA) cspice/data/* $(datadir)
rm -rf $(includedir)/*
$(INSTALL_DATA) cspice/include/* $(includedir)
$(INSTALL_DATA) cspice/lib/* $(libdir)
# symlink cspice.a to libcspice.a, the usual name for a library
ln -f -s cspice.a $(libdir)/libcspice.a 

installdirs :
$(INSTALL_DIR) $(bindir) $(libdir) $(includedir) $(datadir)

install:
true

clean:
rm -rf cspice/



Bug#843325: ITP: waf -- Tool for configuring, building, and installing projects

2016-11-05 Thread Walter Landry
Package: wnpp
Severity: wishlist
Owner: Walter Landry <wlan...@caltech.edu>

* Package name: waf
  Version : 1.9.5
  Upstream Author : Thomas Nagy
* URL : http://waf.io/
* License : BSD
  Programming Lang: Python
  Description : Tool for configuring, building, and installing projects

Waf provides functionality similar to autotools (autoconf, automake,
make).  Waf build scripts are also valid python, so build scripts can
easily use functionality from other python libraries to perform
complex actions.

---

I am trying to package waf because it is a build dependency for a few
other packages I would like to package.  I have a potential sponsor
lined up for these, but I have to figure out the waf package first.

There is a special note to packagers because waf tends to be included
in compiled form with software sources.

  https://wiki.debian.org/UpstreamGuide#waf

Doing a quick search

  curl -s https://codesearch.debian.net/results/22044ee2fe5c4350/packages.json 
| jq -r '.Packages[]' | wc -l

shows 39 packages might also benefit from a central installation of
waf.

---

I currently have a setup that creates two packages: waf and
python3-waflib.  That means that the build scripts must be valid
python 3.  If needed, I could also make a python2-waflib.  In that
case, we might want to have different executables for python2 and
python3.

---

Waf has had a somewhat contentious history in Debian.  It was packaged
and then removed upon request by upstream.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580712

I have had a conversation with upstream (Thomas Nagy).  Nagy still
opposes a generic 'waf' package, but is fine with giving it a specific
version number (e.g. waf-1.9.5).

  https://groups.google.com/d/msg/waf-users/T8f_-HW9_Tw/tuRk0IpIAQAJ

I will defer to the consensus here on what to name the package and any
executables.



Bug#841104: ITP: cspice -- C implementation of The SPICE Toolkit

2016-11-04 Thread Walter Landry
Rock Storm <rockst...@gmx.com> wrote:
> On Mon, 2016-10-31 at 14:02 -0700, Walter Landry wrote:
>> FYI, I created a package for this for my own use.
> 
> That's awesome! Is it uploaded somewhere? Could you share it with me? I
> would love to take a look at it.

Here is a tarball.

  https://caltech.box.com/s/f64t26xgauc9re6k3sryv5spagipslnu

As promised, the package is not optimal.  It is versioned with git,
but the modifications to debian/ and the main package are mixed.  If
DEBFULLNAME and DEBEMAIL are set, then running

  fakeroot debian/rules binary

should give you three rpms

  cspice_0065-1_amd64.deb
  libcspice-dev_0065-1_amd64.deb
  libcspice_0065-1_amd64.deb

I replaced the build system with waf.  I have a waf package already.
Waf is a bit controversial in Debian, so I need to make an ITP and see
what the Debian consensus is.

Cheers,
Walter Landry



Bug#841104: ITP: cspice -- C implementation of The SPICE Toolkit

2016-11-01 Thread Walter Landry
Rock Storm <rockst...@gmx.com> wrote:
> On Mon, 2016-10-31 at 14:02 -0700, Walter Landry wrote:
>> FYI, I created a package for this for my own use.
> 
> That's awesome! Is it uploaded somewhere? Could you share it with me? I
> would love to take a look at it.

I can share it.  Give me a day or so.  The build is ... complicated.

>> It is pretty terrible, but if I find the time, I may be able to make
>> a proper package.  If you already have a proper package, yours is
>> probably better.
> 
> I've been busier than I expected so I haven't done much yet, probably
> merging our efforts is the best option.

Ok.

> Nevertheless, I still have to discuss with legal whether distributing
> this package complies with the DFSG.

For what it is worth, I am a regular on debian-legal.  In this link

  
http://naif.jpl.nasa.gov/pub/naif/toolkit//C/PC_Linux_GCC_64bit/packages/README

I see a disclaimer, but no right to modify.  This link

  https://naif.jpl.nasa.gov/naif/rules.html

allows modification, but not simple redistribution?  To make things
even more muddy, this presentation

  
https://indico.esa.int/indico/event/111/session/27/contribution/130/material/slides/0.pdf

says that it is "free of licensing".

So it is pretty clear that we have to get a clarification on what,
exactly, the license is.  It looks like the person to talk to is the
NAIF manager at JPL.  His contact info is in the 'rules' link.
Clarifying this could, potentially, take a while.

Cheers,
Walter Landry


Bug#841104: ITP: cspice -- C implementation of The SPICE Toolkit

2016-10-31 Thread Walter Landry
FYI, I created a package for this for my own use.  It is pretty
terrible, but if I find the time, I may be able to make a proper
package.  If you already have a proper package, yours is probably
better.

Cheers,
Walter Landry
wlan...@caltech.edu



Bug#804645: slurm-drmaa-dev: Missing symlink for libdrmaa.so.1

2015-11-09 Thread Walter Landry
Subject: slurm-drmaa-dev: Missing symlink for libdrmaa.so.1
Package: slurm-drmaa-dev
Version: 1.0.7-1+b1
Severity: normal

Dear Maintainer,

Consider this simple "Hello DRMAA" program

  #include "drmaa.h"
  int main()
  {
char diagnosis[DRMAA_ERROR_STRING_BUFFER];
drmaa_init(NULL, diagnosis, sizeof(diagnosis)-1);
  }

I can compile it with the command

  gcc drmaa_init.c -o drmaa_init -ldrmaa

Running it gives me the error

  drmaa_init: error while loading shared libraries: libdrmaa.so.1: cannot open 
shared object file: No such file or directory

The real libraries are in

  /usr/lib/slurm-drmaa/lib

with symlinks set up using the alternatives section.  There is a link for

  libdrmaa.so

but not for

  libdrmaa.so.1

I can work around it using RPATH or LD_LIBRARY_PATH, but my impression
is that it should not be required.

Thank you,
Walter Landry


-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages slurm-drmaa-dev depends on:
ii  slurm-drmaa1  1.0.7-1+b1

slurm-drmaa-dev recommends no packages.

slurm-drmaa-dev suggests no packages.

-- no debconf information



Bug#788508: python-dap: New version available

2015-06-11 Thread Walter Landry
Package: python-dap
Version: 2.2.6.7-2
Severity: wishlist

Dear Maintainer,

There is a new version of pydap available at pydap.org.  The current
version is about 7 years out of date.

Thank you,
Walter Landry

-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-dap depends on:
ii  python   2.7.9-1
ii  python-httplib2  0.9+dfsg-2

Versions of packages python-dap recommends:
ii  python-cheetah  2.4.4-3
ii  python-paste1.7.5.1-6
ii  python-pastedeploy  1.5.2-1
ii  python-pastescript  1.7.5-3

python-dap suggests no packages.

-- no debconf information


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



Bug#717942: libwcstools-dev: Missing wcscat.h

2013-07-26 Thread Walter Landry
Package: libwcstools-dev
Version: 3.8.5-1
Severity: normal

Dear Maintainer,

The header file wcscat.h is not included.  This includes declarations of
functions like ctgread, which , according to

  http://tdc-www.harvard.edu/software/wcstools/subroutines/libwcs.cat.html

seem to be publicly available api's.  The libraries

  /usr/lib/libwcstools.a
  /usr/lib/libwcstools.so.0.0.0

already seem to have the necessary exported symbols.  It is just the header
wcscat.h  that is missing.



-- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libwcstools-dev depends on:
ii  libwcstools0  3.8.5-1

libwcstools-dev recommends no packages.

libwcstools-dev suggests no packages.

-- no debconf information


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



Bug#692613: [php-maint] Bug#692613: php5: non-free files in upstream tarball (The Software shall be used for Good, not Evil)

2013-05-13 Thread Walter Landry
Thijs Kinkhorst th...@debian.org wrote:
 On Mon, May 13, 2013 13:01, Ondrej Sury wrote:
 OK, it's very much annoying (since the tarball is huge and the updated
 module won't hit PHP 5.5), but I will comply.
 
 This seems like a paper exercise which I doubt is worth our efforts.
 
 I seems extremely unlikely that the author of the software could have a
 legally valid case where a judge would positively decide that a use case
 is objectively Evil and in violation of this license. I don't see a
 practical risk to anyones freedom being in jeopardy here.
 
 Surely it's an annoying license, so when removing it is opportune we
 should do it, but in this case the potential gains (if any?) do not seem
 to outweigh the cost.

The problem is not whether Debian can distribute the software.  The
problem is that the tarball that Debian distributes to users must not
contain non-free bits.  This is hardly the first time that this has
come up [1].  Yes, it is annoying for the packager.  But it is useful for
the user to know that, whatever is in the tarball, they will not have
to do any forensic analysis before using the tarball.

Cheers,
Walter Landry
wlan...@caltech.edu

[1] For example,
http://lists.debian.org/debian-legal/2008/11/msg00083.html
http://lists.debian.org/debian-legal/2007/11/msg00280.html
http://lists.debian.org/debian-legal/2006/07/msg00043.html


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



Bug#695262: bsdgames-nonfree: Coredump after loading save file

2012-12-06 Thread Walter Landry
Package: bsdgames-nonfree
Version: 2.17-4
Severity: normal
Tags: upstream patch

Dear Maintainer,

When running the game, saving and then reloading, I sometimes get a segfault.
I managed to track down the problem.  Rogue's objects use a const char* to
represent damage (e.g. 1d3).  The pointer to this string gets saved in the
savefile, but not the string itself.  When the program is run again, the
pointer is no longer valid, leading to segfaults.

A solution to this is to use a fixed size array of char's (I used char[7]
so that the size remains the same).  Then the whole object will be a simple
POD and serialize correctly.  I have attached a patch (patch -p6  
bsdgames.patch).

Note that this will break save files.  But you could argue that they were
already broken ;)

Cheers,
Walter Landry
wlan...@caltech.edu

diff -ru /home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17 
/home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17_patched/
diff -ru /home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17/rogue/init.c 
/home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17_patched/rogue/init.c
--- /home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17/rogue/init.c 
2003-12-16 18:47:37.0 -0800
+++ /home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17_patched/rogue/init.c 
2012-12-06 01:28:28.160049621 -0800
@@ -159,7 +159,7 @@
obj = alloc_object();   /* initial weapons */
obj-what_is = WEAPON;
obj-which_kind = MACE;
-   obj-damage = 2d3;
+   strncpy(obj-damage,2d3,7);
obj-hit_enchant = obj-d_enchant = 1;
obj-identified = 1;
(void) add_to_pack(obj, rogue.pack, 1);
@@ -168,7 +168,7 @@
obj = alloc_object();
obj-what_is = WEAPON;
obj-which_kind = BOW;
-   obj-damage = 1d2;
+   strncpy(obj-damage,1d2,7);
obj-hit_enchant = 1;
obj-d_enchant = 0;
obj-identified = 1;
@@ -178,7 +178,7 @@
obj-what_is = WEAPON;
obj-which_kind = ARROW;
obj-quantity = get_rand(25, 35);
-   obj-damage = 1d2;
+   strncpy(obj-damage,1d2,7);
obj-hit_enchant = 0;
obj-d_enchant = 0;
obj-identified = 1;
diff -ru /home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17/rogue/object.c 
/home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17_patched/rogue/object.c
--- /home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17/rogue/object.c   
2003-12-16 18:47:37.0 -0800
+++ 
/home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17_patched/rogue/object.c   
2012-12-05 23:33:49.596264092 -0800
@@ -536,25 +536,25 @@
switch(obj-which_kind) {
case BOW:
case DART:
-   obj-damage = 1d1;
+  strncpy(obj-damage,1d1,7);
break;
case ARROW:
-   obj-damage = 1d2;
+  strncpy(obj-damage,1d2,7);
break;
case DAGGER:
-   obj-damage = 1d3;
+  strncpy(obj-damage,1d3,7);
break;
case SHURIKEN:
-   obj-damage = 1d4;
+  strncpy(obj-damage,1d4,7);
break;
case MACE:
-   obj-damage = 2d3;
+  strncpy(obj-damage,2d3,7);
break;
case LONG_SWORD:
-   obj-damage = 3d4;
+  strncpy(obj-damage,3d4,7);
break;
case TWO_HANDED_SWORD:
-   obj-damage = 4d5;
+  strncpy(obj-damage,4d5,7);
break;
}
 }
@@ -645,7 +645,7 @@
obj-picked_up = obj-is_cursed = 0;
obj-in_use_flags = NOT_USED;
obj-identified = UNIDENTIFIED;
-   obj-damage = 1d1;
+   strncpy(obj-damage,1d1,7);
return(obj);
 }
 
diff -ru /home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17/rogue/rogue.h 
/home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17_patched/rogue/rogue.h
--- /home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17/rogue/rogue.h
2005-02-15 22:24:50.0 -0800
+++ 
/home/boo/random_stuff/roguelike/bsdgames-nonfree-2.17_patched/rogue/rogue.h
2012-12-05 23:31:08.344256787 -0800
@@ -219,7 +219,7 @@
 
 struct obj {   /* comment is monster meaning */
unsigned long m_flags;  /* monster flags */
-   const char *damage; /* damage it does */
+   char damage[7]; /* damage it does */
short quantity; /* hit points to kill */
short ichar;/* 'A' is for aquatar */
short kill_exp; /* exp for killing it */



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.5-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bsdgames-nonfree depends on:
ii  libc62.13-37
ii  libncurses5  5.9-10
ii  libtinfo5

Bug#685117: Installation Report: Thinkpad X230T

2012-08-16 Thread Walter Landry
:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

I have the Intel Centrino Ultimate-N 6300 wireless card, which
requires firmware to work.  I copied firmware.tar.gz to a USB stick,
but the installer could not find it.  Looking at the instructions
again, it seems that I have to unpack firmware.tar.gz for the
detection to work.  It would be nice if the installer knew to try to
unpack firmware.tar.gz to find the needed hardware.

In any case, with the firmware, the hardware works well.

The tablet functionality seem to work fine, though I do not know a
good way to change the orientation.  In Gnome, using System
Settings/Displays, if you rotate the orientation, the pen coordinates
do not get mapped correctly (up is left, down is right, etc.).
Annoyingly, I had to manually set up the eraser in Gimp and Xournal.

If I boot with monitors connected to the VGA and DisplayPort ports,
then the monitor and laptop screens flash with some error messages but
can never decide where to display anything.  If I pull out the VGA and
DisplayPort connectors, then it settles down and displays on the
laptop.  Once that is done, I can reconnect the displays and set them
up with System Settings/Displays in Gnome.

The equivalent setup works fine with my Thinkpad X220T with Intel HD
3000, so I am guessing that the HD 4000 is not fully supported yet.

I was getting random freezes of the whole system.  It seemed to happen
when doing more graphical activity.  My guess is that it is something
like bug #677444.  I upgraded to the kernel 3.4-trunk-amd64 from
experimental, and I have not had any more freezes.  I still have the
problem with multiple monitors.

Cheers,
Walter Landry
wlan...@caltech.edu


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



Bug#613822: installation-reports: Squeeze (amd64 and i386) cannot load NIC firmware from USB during installation for Poweredge 2950

2012-01-10 Thread Walter Landry
Package: installation-reports
Followup-For: Bug #613822

Hi,

I just wanted to add that I had the same problem (the installer could not find
the firmware for my wireless) on my new Thinkpad X220 Tablet.  As a workaround,
I ran a shell, mounted the usb stick manually, and then copied the iwlwifi*
firmware to /lib/firmware.



-- Package-specific info:

Boot method: usb
Image version: wheezy
Date: Date and time of the install

Machine: Thinkpad X220 Tablet
Partitions: df -Tl will do; the raw partition table is preferred


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

Description of the install, in prose, and any thoughts, comments
  and ideas you had during the initial install.


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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



Bug#655436: installation-reports: Graphical install does not detect mouse or keyboard

2012-01-10 Thread Walter Landry
Package: installation-reports
Severity: normal
Tags: d-i

Dear Maintainer,

When I tried the graphical installer, it would give me the first screen
(selecting the language or keyboard, I forget), but both the mouse and keyboard
do not work.  The text installer works fine.



-- Package-specific info:

Boot method: usb
Image version: 
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
Date: Date and time of the install

Machine: Thinkpad X220 Tablet
Partitions: df -Tl will do; the raw partition table is preferred


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

Description of the install, in prose, and any thoughts, comments
  and ideas you had during the initial install.


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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



Bug#655437: installation-reports: kernel image selection is confusing

2012-01-10 Thread Walter Landry
Package: installation-reports
Severity: minor
Tags: d-i

Dear Maintainer,
When installing on my X220 Tablet, at one point it asks me to choose which
kernel I want to use.  The choices were something like linux-image-amd64 and
linux-image-3.1.0-amd64.  There is no information for why you would want to
choose one or the other.  In fact, they both end up installing the same kernel,
so it seems it would be best if this question could be avoided entirely.

Thanks,
Walter Landry



-- Package-specific info:

Boot method: usb
Image version: 
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
Date: Date and time of the install

Machine: Thinkpad X220 Tablet
Partitions: df -Tl will do; the raw partition table is preferred


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

Description of the install, in prose, and any thoughts, comments
  and ideas you had during the initial install.


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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



Bug#655438: installation-reports: nilfs2 support

2012-01-10 Thread Walter Landry
Package: installation-reports
Severity: wishlist
Tags: d-i

Dear Maintainer,

It would be nice to support nilfs2 as a option during installation.  It seems
that there are only two things that need to be done: Add nilfs2 to the list of
kernel modules, and get partman to support nilfs2.  I presume the first thing
is easy, but I do not know how hard the second is.

I worked around it by using a Debian Squeeze Live CD.  That allowed me to run
gparted to create the partitions, and then mkfs.nilfs2 to make the filesystems.
Otherwise, I just followed the instructions in Appendix D.3 Installing Debian
GNU/Linux from a Unix/Linux System.  The only thing I had to special was to
add

  nilfs2

to the file

  /etc/initramfs-tools/modules

and then run update-initramfs -u in the chroot.

Thanks,
Walter Landry



-- Package-specific info:

Boot method: usb
Image version: http://d-i.debian.org/daily-images/amd64/daily/hd-
media/boot.img.gz
Date: Date and time of the install

Machine: Thinkpad X220 Tablet
Partitions: df -Tl will do; the raw partition table is preferred


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

Description of the install, in prose, and any thoughts, comments
  and ideas you had during the initial install.



-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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



Bug#570621: Parsing output = derivative work?

2011-03-08 Thread Walter Landry
Miriam Ruiz mir...@debian.org wrote:
 In general, I wouldn't consider parsing the output of another
 program to de a derivative work.

In general, I do agree with Miriam that parsing the output of another
program does not make a derivative work.  But just to give an example
of where it does happen, git is largely comprised of many small
utilities that communicate over pipes and command-line arguments.

Cheers,
Walter Landry
wlan...@caltech.edu



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



Bug#537414: Please default to 1.8 interface for hdf5-1.8.x

2011-01-09 Thread Walter Landry
Greetings,

I was recently bitten by this bug again.  HDF5 has had the new API for
almost 3 years.  This is getting a bit ridiculous.  It is time for
Debian to use the new API.  From

  http://www.hdfgroup.org/HDF5/doc/RM/APICompatMacros.html

  For new code development, The HDF Group recommends use of the
  compatibility macro mapped to the latest version of the function.

Debian is making it impossible to use this compatibility macro.  If
you download HDF5 from the net and build software against it using the
recommended API, it will not then build against the Debian version.

In addition, it seems that there is an easy workaround for people who
want to use the old API, but there is no easy workaround for people
using the new API.

So pretty please, with sugar on top, change the default API.

Thanks,
Walter Landry
wlan...@caltech.edu



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



Bug#564276: Ubuntu trademark non-free?

2010-08-10 Thread Walter Landry
Jordan Metzmeier titan8...@gmail.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 I had been looking at this bug for a few days now
 as well the the Ubuntu Trademark Policy [1]. I am
 not a legal person, so I would like to bring it to
 the attention of people who are, to see if this policy
 makes the application non-free in its current state.
 
 The statements that stands out to me are:
 
 We reserve the right to review all usage within the open
 source community, and to object to any usage that appears
 to overstep the bounds of discussion and good-faith
 non-commercial development.
 
 and
 
 Restricted use that requires a trademark licence
 
 Permission from us is necessary to use any of the Trademarks
 under any circumstances other than those specifically permitted
 above. These include:
 
 - - Any commercial use.

This makes it clearly non-free.  It is best to just replace anything
trademarked by Ubuntu.

Cheers,
Walter Landry
wlan...@caltech.edu



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



Bug#585909: xserver-xorg-video-radeon: Garbage on screen during initial boot if KMS enabled

2010-06-15 Thread Walter Landry
Michel Dänzer daen...@debian.org wrote:
 On Mon, 2010-06-14 at 13:08 -0700, Walter Landry wrote: 
 Package: xserver-xorg-video-radeon
 Version: 1:6.13.0-2
 Severity: important
 
 I upgraded this driver, and now when X starts during bootup I just get random
 garbage all over the screen.  If I switch to a virtual terminal, it is fine. 
  I
 can then restart gdm, and the screen comes up mostly fine.  The one problem 
 is
 that my monitor connected via displayport does not work.  It is detected, but
 for some reason it does not get any commands.  It is just black, and goes to
 sleep.
 
 If I disable kernel mode setting in /etc/modprobe.d/radeon-kms.conf, then X
 completely works again.
 
 [...]
 
 Current Operating System: Linux dante 2.6.32-trunk-amd64 #1 SMP Sun Jan 10 
 22:40:40 UTC 2010 x86_64
 
 Try a 2.6.32-4-amd64 or newer kernel.

Using 2.6.32-5 fixes all of the problems.  I actually had it
installed, but grub was not showing it.

Thanks,
Walter Landry
wal...@geodynamics.org



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



Bug#574134: term: COLUMNS not set correctly when running in X

2010-04-17 Thread Walter Landry
Rob Browning r...@defaultvalue.org wrote:
 Walter Landry wlan...@caltech.edu writes:
 
 When running emacs in X, if I run M-x term, then the COLUMNS
 environment variable is not set correctly.  I think that this is
 because there is a half-width space on the left and right sides of the
 window.  There may also be a scrollbar.  So COLUMNS will be too big by
 one or two.

 When I run emacs in a terminal, COLUMNS is set correctly, since it
 does not have to worry about the half-width spaces or scrollbar.

 This causes problems if you want to run applications like aptitude,
 because aptitude writes characters all the way to the right side of
 the screen.  It also causes problems if I ssh into a remote machine
 and run emacs there.
 
 Can you describe a way to reproduce this?  I tried running M-x term in
 an X emacs with a scrollbar, and COLUMNS was set to 80, and there were
 in fact 80 columns.

This is odd.  I can not reproduce it either.  I am running testing,
and I do not think that emacs was updated since I submitted the bug
report.  It was definitely misbehaving before, and it is definitely
behaving now.  So I guess you can close this bug.

Thanks for your time,
Walter Landry
wlan...@caltech.edu



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



Bug#574134: term: COLUMNS not set correctly when running in X

2010-03-16 Thread Walter Landry
Package: emacs23
Version: 23.1+1-5
Severity: normal

When running emacs in X, if I run M-x term, then the COLUMNS environment 
variable is not set correctly.  I think that this is because there is a 
half-width space on the left and right sides of the window.  There may also be 
a scrollbar.  So COLUMNS will be too big by one or two.

When I run emacs in a terminal, COLUMNS is set correctly, since it does not 
have to worry about the half-width spaces or scrollbar.

This causes problems if you want to run applications like aptitude, because 
aptitude writes characters all the way to the right side of the screen.  It 
also causes problems if I ssh into a remote machine and run emacs there.



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages emacs23 depends on:
ii  emacs23-bin-common  23.1+1-5 The GNU Emacs editor's shared, arc
ii  install-info4.13a.dfsg.1-5   Manage installed documentation in 
ii  libasound2  1.0.22-2 shared library for ALSA applicatio
ii  libatk1.0-0 1.28.0-1 The ATK accessibility toolkit
ii  libc6   2.10.2-6 Embedded GNU C Library: Shared lib
ii  libcairo2   1.8.8-2  The Cairo 2D vector graphics libra
ii  libdbus-1-3 1.2.20-2 simple interprocess messaging syst
ii  libfontconfig1  2.8.0-2  generic font configuration library
ii  libfreetype62.3.11-1 FreeType 2 font engine, shared lib
ii  libgif4 4.1.6-9  library for GIF images (library)
ii  libglib2.0-02.22.4-1 The GLib library of C routines
ii  libgpm2 1.20.4-3.3   General Purpose Mouse - shared lib
ii  libgtk2.0-0 2.18.6-1 The GTK+ graphical user interface 
ii  libice6 2:1.0.6-1X11 Inter-Client Exchange library
ii  libjpeg62   6b-16.1  The Independent JPEG Group's JPEG 
ii  libm17n-0   1.5.5-1  a multilingual text processing lib
ii  libncurses5 5.7+20090803-2   shared libraries for terminal hand
ii  libotf0 0.9.10-1 A Library for handling OpenType Fo
ii  libpango1.0-0   1.26.2-1 Layout and rendering of internatio
ii  libpng12-0  1.2.43-1 PNG library - runtime
ii  librsvg2-2  2.26.0-1 SAX-based renderer library for SVG
ii  libsm6  2:1.1.1-1X11 Session Management library
ii  libtiff43.9.2-3+b1   Tag Image File Format (TIFF) libra
ii  libx11-62:1.3.3-1X11 client-side library
ii  libxft2 2.1.14-1 FreeType-based font drawing librar
ii  libxpm4 1:3.5.8-1X11 pixmap library
ii  libxrender1 1:0.9.5-1X Rendering Extension client libra
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

emacs23 recommends no packages.

Versions of packages emacs23 suggests:
ii  emacs23-common-non-dfsg   23.1+1-1   GNU Emacs shared, architecture ind



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



Bug#572982: EPL + LGPL compatiblity?

2010-03-09 Thread Walter Landry
Pablo Duboue pablo.dub...@gmail.com wrote:
 Hi,
 
 We seek some advice regarding #572982 [1] (azureus, a well-known torrent 
 client, combines source licensed under incompatible  licenses).
 
 From Niels quoted sources, there is no doubt about the incompatibility of GPL 
 and EPL. But LGPL and EPL might be a different matter and Google has proved 
 quite unfriendly on this regard.

I think that the LGPL v3 is compatible with the EPL.  The LGPL allows
you to convey combined works as long as you can recompile the LGPL
parts.  Since we have the source for everything, this is not a
problem.

Cheers,
Walter Landry
wlan...@caltech.edu



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



Bug#494126: paraview sometimes kills xserver

2010-03-02 Thread Walter Landry
I used to have this problem, but it always turned out to be a graphics
card issue.  With certain operations, I could reliably kill my xserver
on my machine running with an ATI card.  But my machine with Intel
graphics never had a problem.

Cheers,
Walter Landry
wlan...@caltech.edu



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



Bug#550295: ktouch: Letters are cut off

2009-10-08 Thread Walter Landry
Package: ktouch
Version: 4:4.3.1-1
Severity: normal

When displaying the letters that you type, the bottom 30% of the characters are 
not displayed.  This is true whether or not the keyboard is being shown.

The version in Lenny seems to work fine.


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ktouch depends on:
ii  kdebase-runtime   4:4.3.1-1  runtime components from the offici
ii  kdelibs5  4:4.3.1-1  core libraries for all KDE 4 appli
ii  libc6 2.9-25 GNU C Library: Shared libraries
ii  libqt4-xml4:4.5.2-2  Qt 4 XML module
ii  libqtcore44:4.5.2-2  Qt 4 core module
ii  libqtgui4 4:4.5.2-2  Qt 4 GUI module
ii  libstdc++64.4.1-4The GNU Standard C++ Library v3

ktouch recommends no packages.

Versions of packages ktouch suggests:
ii  khelpcenter4  4:4.3.1-1  Help Center for KDE 4

-- no debconf information
attachment: cutoff.png

Bug#550297: ktouch: Colemak letters not marked correctly

2009-10-08 Thread Walter Landry
Package: ktouch
Version: 4:4.3.1-1
Severity: normal

When running a lesson with the Colemak keyboard layout, the keyboard is 
displayed correctly, but which key to type is marked wrong.  For example, if 
the next letter is r, ktouch highlights the p key.  The p key on Colemak 
is where the r key is on QWERTY.  So it is as if ktouch has changed the 
display of the keys, but not its internal mapping.

The DVORAK layout works fine.



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ktouch depends on:
ii  kdebase-runtime   4:4.3.1-1  runtime components from the offici
ii  kdelibs5  4:4.3.1-1  core libraries for all KDE 4 appli
ii  libc6 2.9-25 GNU C Library: Shared libraries
ii  libqt4-xml4:4.5.2-2  Qt 4 XML module
ii  libqtcore44:4.5.2-2  Qt 4 core module
ii  libqtgui4 4:4.5.2-2  Qt 4 GUI module
ii  libstdc++64.4.1-4The GNU Standard C++ Library v3

ktouch recommends no packages.

Versions of packages ktouch suggests:
ii  khelpcenter4  4:4.3.1-1  Help Center for KDE 4

-- no debconf information



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



Bug#546385: installation-report: Minor issues with install

2009-09-12 Thread Walter Landry
Package: installation-reports
Version: 2.38
Severity: normal


-- Package-specific info:

Boot method: CD
Image version: Business card daily image, Sept 4
Date: Date and time of the install

Machine: Lenovo Thinkpad W500
Partitions:
Partition Table for /dev/sda

 ---Starting  Ending-Start Number of
 # Flags Head Sect  Cyl   ID  Head Sect  Cyl SectorSectors
-- -   -    - --- ---
 1  0x8011 0 0x83  254   63   121  63 1959867
 2  0x0001   122 0x83  254   63  3768 195993058589055
 3  0x0001  3769 0x83  254   63  437660548985 9767520
 4  0x0001  4377 0x05  254   63 2432070316505   320400360
 5  0x0011  4377 0x83  254   63 23834  63   312592707
 6  0x0011 23835 0x82  254   63 24320  63 7807527

FilesystemType   1K-blocks  Used Available Use% Mounted on
/dev/sda1  xfs  848860142648706212  17% /
tmpfstmpfs 1996612 8   1996604   1% /lib/init/rw
udev tmpfs   10240   180 10060   2% /dev
tmpfstmpfs 199661288   1996524   1% /dev/shm
/dev/sda5  xfs   156165280  94399904  61765376  61% /home
/dev/sda2  xfs29163452   4983896  24179556  18% /usr
/dev/sda3  xfs 4752688   2737540   2015148  58% /var


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O ]
Detect network card:[O ]
Configure network:  [O ]
Detect CD:  [O ]
Load installer modules: [E ]
Detect hard drives: [O ]
Partition hard drives:  [O ]
Install base system:[O ]
Clock/timezone setup:   [O ]
User/password setup:[O ]
Install tasks:  [O ]
Install boot loader:[E ]
Overall install:[O ]

Comments/Problems:

I tried the graphical installs for LXDE, XFCE, and the default. The
pointing stick did not work, but the trackpad worked fine.

The machine has switchable graphics (Intel integrated and ATI).  The
VESA driver was automatically selected, which thought my screen
(1920x1200) is even wider than that.  If I set the graphics to one or
the other in the BIOS, then it used the correct driver and the screen
resolution was fine.

I used XFS as the filesystem on all of my partitions.  It would be
nice to be able to pass options to mkfs.  I ended up using rescue mode
to make the filesystems exactly the way I wanted.  However, the
regular rescue mode did not work.  The graphical rescue mode worked
fine.

When manually partitioning, the meanings of the labels B, F, and
K are not immediately apparent.  This is not such a big deal, since
it is really for experts only.

It used Grub by default, but that did not install.  I ended up using
Lilo.  This is probably just bug #545226.

It is nice that I can specify a number of different options when
mounting filesystem.  However, I can not specify the logbufs option,
which can be useful for tuning XFS performance.

My wireless card (Intel 5300) is supported by the kernel.  However, I
was never prompted to load the necessary firmware from USB.  I could
get it to work by starting a shell and manually loading the firmware.
I usually used the wired connection (Intel 82567LM Gigabit), which
worked fine.

I felt the XFCE install was too bare-bones.  It was missing a lot of
things useful for laptop owners.  It was actually better to install
the default Gnome desktop and then add the XFCE task.

Keyboard information was asked for twice: once at the beginning and
once for console-setup.

I got asked questions about a samba server.  This was a little
annoying, since I did not ask for samba and do not know anything about
it.  I am not sure of the best way to solve this.

In general, things went quickly and/or I had a good sense of progress,
so it was a fairly pleasant experience.

As a comparison, I also tried installing Ubuntu 9.04.  It had no problem
detecting the pointing stick and used the Intel video driver.  It
really did not like XFS, though.

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION=Debian GNU/Linux installer
DISTRIB_RELEASE=6.0 (squeeze) - installer build 20090903-00:00
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux dante 2.6.30-1-amd64 #1 SMP Sat Jul 18 12:55:06 UTC 2009 x86_64 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series 
Chipset Memory Controller Hub [8086:2a40] (rev 07)
lspci -knn: 

Bug#492696: Combining Artistic|GPL-1+ with GPL-2 and LGPL-3+

2009-01-17 Thread Walter Landry
MJ Ray m...@phonecoop.coop wrote:
 Damyan Ivanov d...@debian.org wrote:
  [Please Cc me on replies. Thanks]
  Most of the code is licensed under the same terms as Perl itself,
 [...]
  In addition to that, some icons are licensed under LGPL-3+, and some 
  more icons are licensed under GPL-2.
 
  From how I understand it, if we choose GPL-2 for the main code, that 
  still leaves the combination of GPL-2 (code and some .png icons) and 
  LGPL-3+ (.png icons). Is such aggregation OK?
 
 If it's mere aggregation, I believe each stays under their own licence.

Just to be clear, if it is not mere aggregation, then it is not ok.
If the LGPL-3+ icons are required for the program to operate
correctly, that is a hint that licenses need to be compatible with
GPL-2.

Cheers,
Walter Landry
wlan...@caltech.edu



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



Bug#448359: window list applet hangs

2008-12-24 Thread Walter Landry
Package: gnome-panel
Version: 2.20.3-5
Followup-For: Bug #448359


Greetings,

Since I did not see any followup to the original bug, this is a 
confirmation that it does exist.  I recently installed Lenny on my
machine and all that I have to do is open about nine windows and the 
whole panel freezes.  As mentioned earlier, a workaround is to 
change the window list preferences to allow grouping of windows.  At 
this point, the best course of action might be to change the default 
preference so that users do not run into this simply by opening up a 
bunch of windows.

Cheers,
Walter Landry
wlan...@caltech.edu

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.27.8 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gnome-panel depends on:
ii  gnome-about2.22.3-2  The GNOME about box
ii  gnome-control-center   1:2.22.2.1-2  utilities to configure the GNOME d
ii  gnome-desktop-data 2.22.3-2  Common files for GNOME 2 desktop a
ii  gnome-menus2.22.2-4  an implementation of the freedeskt
ii  gnome-panel-data   2.20.3-5  common files for the GNOME Panel
ii  libatk1.0-01.22.0-1  The ATK accessibility toolkit
ii  libbonobo2-0   2.22.0-1  Bonobo CORBA interfaces library
ii  libbonoboui2-0 2.22.0-1  The Bonobo UI library
ii  libc6  2.7-16GNU C Library: Shared libraries
ii  libcairo2  1.6.4-7   The Cairo 2D vector graphics libra
ii  libdbus-glib-1-2   0.76-1simple interprocess messaging syst
ii  libecal1.2-7   2.22.3-1.1Client library for evolution calen
ii  libedataserver1.2-92.22.3-1.1Utility library for evolution data
ii  libedataserverui1.2-8  2.22.3-1.1GUI utility library for evolution 
ii  libgconf2-42.22.0-1  GNOME configuration database syste
ii  libglade2-01:2.6.2-1 library to load .glade files at ru
ii  libglib2.0-0   2.16.6-1  The GLib library of C routines
ii  libgnome-desktop-2 2.22.3-2  Utility library for loading .deskt
ii  libgnome-menu2 2.22.2-4  an implementation of the freedeskt
ii  libgnome2-02.20.1.1-1The GNOME 2 library - runtime file
ii  libgnomeui-0   2.20.1.1-2The GNOME 2 libraries (User Interf
ii  libgnomevfs2-0 1:2.22.0-5GNOME Virtual File System (runtime
ii  libgtk2.0-02.12.11-4 The GTK+ graphical user interface 
ii  liborbit2  1:2.14.13-0.1 libraries for ORBit2 - a CORBA ORB
ii  libpanel-applet2-0 2.20.3-5  library for GNOME Panel applets
ii  libpango1.0-0  1.20.5-3  Layout and rendering of internatio
ii  libwnck22  2.22.3-1  Window Navigator Construction Kit 
ii  libx11-6   2:1.1.5-2 X11 client-side library
ii  libxau61:1.0.3-3 X11 authorisation library
ii  menu-xdg   0.3   freedesktop.org menu compliant win

Versions of packages gnome-panel recommends:
ii  alacarte  0.11.5-1   easy GNOME menu editing tool
ii  evolution-data-server 2.22.3-1.1 evolution database backend server
ii  gnome-applets 2.22.3-3   Various applets for GNOME 2 panel 
ii  gnome-icon-theme  2.22.0-1   GNOME Desktop icon theme
ii  gnome-session 2.22.3-2   The GNOME 2 Session Manager

Versions of packages gnome-panel suggests:
ii  gnome-system-tools  2.22.0-3 Cross-platform configuration utili
ii  gnome-terminal [x-termi 2.22.3-3 The GNOME 2 terminal emulator appl
ii  gnome-user-guide [gnome 2.22.1-1 GNOME user's guide
ii  konsole [x-terminal-emu 4:3.5.9.dfsg.1-6 X terminal emulator for KDE
ii  nautilus2.20.0-7 file manager and graphical shell f
ii  xterm [x-terminal-emula 235-1X terminal emulator
ii  yelp2.22.1-8+b1  Help browser for GNOME 2

-- no debconf information



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



Bug#507579: Help needed for bug 507579 (AGPL issue).

2008-12-04 Thread Walter Landry
Charles Plessy [EMAIL PROTECTED] wrote:
 Dear debian-legal,
 
 yocto-reader is a package licenced under the AGPL, and due to the novelties of
 this license there is divergence of interpretation on wether this package is
 fit for the release or not.
 
 Can you have a look to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507579
 and help to resolve the issue?
 
 The bug is quite short so I hope there is no need to make a summary. The main
 issues are:
 
  - Wether the Debian package is a modification of upstream work that fails to
provide access to the diff and the build environment.

Upstream is also the Debian maintainer.  So the question of whether
Debian is modifying the code is sufficiently fuzzy that I do not feel
comfortable saying anything definite.  If someone else takes over
maintenance (e.g. QA), then they would have more work on their hands.

  - Wether it is acceptable to have html pages that include a link to a remote
non-free Google javascript.

If I understand correctly, the Google javascript is required in order
for the page to work properly.  In Debian parlance, this means that
yocto-reader depends on the Google javascript.  So at a minimum
yocto-reader would have to go into contrib.

Now, it also seems like the Google javascript implements an API that
yocto-reader uses.  This makes the javascript more like a library, and
the AGPL requires the source of all of the libraries that it uses.

In summary, I am unsure about the first point, but I agree with
Florian Weimer about the second point.  Unfortunately, this means that
the code can not be packaged unless it is relicensed.

Cheers,
Walter Landry
[EMAIL PROTECTED]



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



Bug#504007: linux-image-2.6.26-1-686: Thinkpad T43 also does not boot

2008-10-31 Thread Walter Landry
Package: linux-image-2.6.26-1-686
Version: 2.6.26-8
Followup-For: Bug #504007

My laptop, a Thinkpad T43, has the exact same behavior: lots of dots and 
then it hangs.  So it is not specific to the Acer.  I also use LILO, 
and all of my partitions use XFS.  The 2.6.25-2 kernel still works 
fine.

Cheers,
Walter Landry
[EMAIL PROTECTED]


-- Package-specific info:

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages linux-image-2.6.26-1-686 depends on:
ii  debconf [debconf-2.0] 1.5.22 Debian configuration management sy
ii  initramfs-tools [linux-initra 0.92j  tools for generating an initramfs
ii  module-init-tools 3.4-1  tools for managing Linux kernel mo

Versions of packages linux-image-2.6.26-1-686 recommends:
ii  libc6-i6862.7-15 GNU C Library: Shared libraries [i

Versions of packages linux-image-2.6.26-1-686 suggests:
ii  lilo  1:22.8-6   LInux LOader - The Classic OS load
pn  linux-doc-2.6.26  none (no description available)

-- debconf information:
  linux-image-2.6.26-1-686/preinst/abort-overwrite-2.6.26-1-686:
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.26-1-686/postinst/bootloader-error-2.6.26-1-686:
  linux-image-2.6.26-1-686/postinst/depmod-error-initrd-2.6.26-1-686: false
  linux-image-2.6.26-1-686/prerm/removing-running-kernel-2.6.26-1-686: true
  linux-image-2.6.26-1-686/postinst/old-system-map-link-2.6.26-1-686: true
  linux-image-2.6.26-1-686/preinst/abort-install-2.6.26-1-686:
  linux-image-2.6.26-1-686/preinst/lilo-has-ramdisk:
  linux-image-2.6.26-1-686/preinst/bootloader-initrd-2.6.26-1-686: true
  linux-image-2.6.26-1-686/prerm/would-invalidate-boot-loader-2.6.26-1-686: true
  linux-image-2.6.26-1-686/preinst/elilo-initrd-2.6.26-1-686: true
  linux-image-2.6.26-1-686/postinst/kimage-is-a-directory:
  linux-image-2.6.26-1-686/postinst/old-dir-initrd-link-2.6.26-1-686: true
  linux-image-2.6.26-1-686/postinst/create-kimage-link-2.6.26-1-686: true
  linux-image-2.6.26-1-686/preinst/lilo-initrd-2.6.26-1-686: true
  linux-image-2.6.26-1-686/postinst/old-initrd-link-2.6.26-1-686: true
  linux-image-2.6.26-1-686/preinst/overwriting-modules-2.6.26-1-686: true
  linux-image-2.6.26-1-686/postinst/depmod-error-2.6.26-1-686: false
  linux-image-2.6.26-1-686/postinst/bootloader-test-error-2.6.26-1-686:
  linux-image-2.6.26-1-686/preinst/failed-to-move-modules-2.6.26-1-686:
  linux-image-2.6.26-1-686/preinst/initrd-2.6.26-1-686:



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



Bug#370295: sun-java must not provide java2-runtime

2007-01-05 Thread Walter Landry
I was not CC'd, so I did not notice this action on this bug until now.

 severity 370295 important
 thanks

You are the release manager, and you can modify the normal processing
of bugs.  So I won't argue about the severity of this bug.

 The rationale given for reopening this bug was:
 
   The SWT example suggests that it is OK to reimplement large parts of the
   Java API and configure Sun's Java to run with it, but the plain language
   of the license prohibits it.
 
 Even though the license text appears to prohibit this, and even though the
 license text asserts that the FAQ is non-binding, we have:

You are confusing me.  The FAQ _is_ binding.

 - a statement from upstream (in the FAQ) that the DLJ does not prohibit
   distributing sun-java5 together with eclipse, which implies it does not
   prohibit distributing it together with SWT

That is why this is all so confusing.  Sun contradicts itself.  The
reasonable thing to do is to find out what Sun wants before charging
ahead with packaging.

 - an upstream liaison who understands Debian packaging and how these
   packages are put together and who, after reviewing this bug report, closed
   it with the statement that these issues have been addressed.

I don't know what upstream thinks.  I know what Tom Marble says, but
Tom Marble has never claimed that he speaks authoriatively for Sun
when deciding whether the packaging is ok.  I have asked him several
times, and he never replied to that question.

 It is also debatable whether Debian has combined, configured, or
 distributed the Software to run in conjunction with any additional
 software that implements the same or similar functionality or APIs
 as the Software.  We are distributing the software in such a way
 that a user can opt to combine them

The provides: java2-runtime line configures sun's java to run with
any program that needs it.  I do not understand how you can argue
otherwise.

 , but even though sun-java5 is
 listed as providing java2-runtime, on a default Debian system
 non-free is not even listed in the apt configuration.

It does not matter whether sun-java is available on a default Debian
system.  It only matters whether Debian is the one distributing the
incompatible packages.

 I'm not going to claim that there are no bugs in the way this
 package is currently licensed; lack of clarity is always a bug.  But
 I don't believe there is anything here that warrants holding the
 package out of the release -- and upstream apparently agrees.

In any case, the code will become GPL, so this problem will go away on
its own.  It is unfortunate that the package was rammed through
without competent review of the license.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#370295: DLJ prevents running jython with sun-java

2006-10-06 Thread Walter Landry
Thijs Kinkhorst [EMAIL PROTECTED] wrote:
 Hello Walter,
 
  reopen 370295
 
   Please do not reopen this bug again.
  
  This bug has not been resolved.  So I have reopened it.  Please do not
  close it until it has been resolved.  Getting an answer to the
  questions I posted will resolve this bug.
 
 I'm looking through the RC-buglist for etch and noticed this bug. I'm
 surprised by your recent reopening of this bug.
 
 I've read it and the following applies:
 * The package maintainer is of the opinion that this is not a bug;
 * The Debian FTP-master is of the opinion that this is not a bug;

I see the maintainer (Matthias) saying that he needs some
clarifications from Sun.  I see a comaintainer and FTP assistant
(Jeroen) at times saying it is not a bug, and at other times saying
that I should open a new bug.  So it is not clear to me what the
collective opinion of the maintainers is.  If the collective opinion
has coalesced, then I would love to hear it.

 * The upstream copyright holder is of the opinion that this is not a
   bug;

Upstream initially felt the same way about #370296.  Upstream was
eventually persuaded to clarify the license and the bug was closed.
That has not yet happened with this bug.  I honestly do not know what
upstream really wants here.

 You act like you're authorised to override these people's decisions.

From the developers reference [1]

  If the bug submitter disagrees with your decision to close the bug,
  they may reopen it until you find an agreement on how to handle
  it.

I have asked some questions to upstream, and we are now waiting for
them to respond.  Upstream has been fairly responsive, so I am hopeful
that this can be resolved soon.

Cheers,
Walter Landry
[EMAIL PROTECTED]

[1] 
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-housekeeping


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



Bug#370295: DLJ prevents running jython with sun-java

2006-09-30 Thread Walter Landry
reopen 370295
retitle 370295 sun-java must not provide java2-runtime
thanks

Jeroen van Wolffelaar [EMAIL PROTECTED] wrote:
 On Thu, Sep 28, 2006 at 03:54:26PM -0700, Walter Landry wrote:
  This bug is about whether the Debian package should provide
  java2-runtime.  This is the most appropriate place to discuss this
  issue.
 
  Subject: DLJ prevents running jython with sun-java
 
 No, it's not. Please open a new bug if you want to discuss that. 

I have retitled the bug.

 This buglog is so full of very widely distinct issues, it's
 unmanagable to respond to -- now it's verly closely resembling a
 meta-bug I don't think sun-java5 belongs in Debian's non-free
 section.

This bug has always been about how the Debian package is configured.
I have never claimed that the problems in this bug makes it impossible
to have in non-free.  Perhaps you have confused this bug with other
bugs you have commented on (e.g. 370245 and 370296)?

 Please do not reopen this bug again.

This bug has not been resolved.  So I have reopened it.  Please do not
close it until it has been resolved.  Getting an answer to the
questions I posted will resolve this bug.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#370295: DLJ prevents running jython with sun-java

2006-09-28 Thread Walter Landry
reopen 370295
thanks

Tom Marble [EMAIL PROTECTED] wrote:
 
 All:
 
 Distribution of Java SE with Linux or OpenSolaris is governed by the
 DLJ; however, these FAQ's are offered to explain and illustrate some
 of the language in the license.  Sun's goals are to make the
 software widely usable while maintaining compatibility.  I am doing
 my best to help resolve issues that are raised.
 
 It should be clear that the use of SWT is acceptable under the
 DLJ from FAQ #15 [1].

I agree.  However, the point still stands that

  Debian must not only check whether the package itself implements a
  similar API, but must also check all of the users of the package and
  their dependencies.

This only affects how Debian packages Sun's Java, not whether Debian
can package it at all.

 To make this class of concerns explicitly clear we have added
 DLJ FAQ #34 [2].

This new FAQ item seems to be a blanket retraction of the problematic
clause 2c, since Debian is now allowed to configure and distribute
Sun's Java to work with any other software.  This includes GNU
Classpath.  Unfortunately, this FAQ entry also contradicts DLJ FAQ
#14.

So now I really do not know what limits Sun is putting on configuring
technology to work together.  Can I

  1) Reimplement only one small part of the Java API
 (e.g. javax.servlet.jsp.el) and configure it to work with Sun's
 Java?

  2) What about a larger part (e.g. libcommons-*-java)?

  3) What about almost all of the core library (e.g. classpath)?

  4) For all of the above questions, what if they are in a different namespace?

The SWT example suggests that it is OK to reimplement large parts of
the Java API and configure Sun's Java to run with it, but the plain
language of the license prohibits it.

If you could provide clear answers to the above questions, I think
that we can resolve this issue.

 I am closing this bug as the issues covered here have been
 addressed.  Allow me to reiterate the appeal made previously
 by Jeroen when he closed this bug the first time that if anyone
 believes there is still a problem please specify a concrete working
 example of how to get a DLJ-incompatible situation with just using
 apt-get install.  

I mentioned it earlier

  apt-get install sun-java5-bin sun-java5-jre
  apt-get install libcommons-el-java

 Adding still more, new issues to this bug will not facilitate
 constructive discussion of the DLJ and Debian.
 
 Venues for voicing such concerns include the jdk-distros forum [3],
 the DLJfeedback [4] alias and the debian-java mailing list [5].

This bug is about whether the Debian package should provide
java2-runtime.  This is the most appropriate place to discuss this
issue.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#370295: SWT is java and implements similar functionality to Swing (II)

2006-08-28 Thread Walter Landry
Johan Walles [EMAIL PROTECTED] wrote:
 As mentioned by somebody on Debian-legal,
 http://packages.debian.org/unstable/devel/libswt3.1-gtk-java says:
 SWT (Standard Widget Toolkit) provides functionality similar to Swing.
 
 The DLJ at http://download.java.net/dlj/DLJ-v1.1.txt says: do not
 combine, configure or distribute the Software to run in conjunction
 with any additional software that implements the same or similar
 functionality or APIs as the Software.
 
 If I'm reading the DLJ correctly, this means Debian isn't allowed to
 distribute SUN's JDK if that makes it possible to run SWT apps with
 it.  Not being able to run Eclipse (which is an SWT app) would make
 Debian's JDK package useless for me.

So this is a different wrinkle of the problem.  Here, SWT is not
invoked directly by Sun's JDK, but a program does use both at the same
time.  If Sun's license had said

  run in conjunction with any additional java software

instead of

  run in conjunction with any additional software

then there would not be a problem.

The end result of this is that Debian must be even more careful when
declaring that a package can run with Sun's JDK.  Debian must not only
check whether the package itself implements a similar API, but must
also check all of the users of the package and their dependencies.

This could end up encompassing most of the java packages in Debian.
Sun's java would still be useful for developing applications, but not
so useful for running applications distributed by Debian.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#370295: DLJ prevents running jython with sun-java

2006-08-25 Thread Walter Landry
reopen 370295
thanks

Jeroen van Wolffelaar [EMAIL PROTECTED] wrote:
 On Mon, Jul 10, 2006 at 12:15:10AM -0700, Josh Triplett wrote:
  Jeroen van Wolffelaar wrote:
   On Sun, Jun 04, 2006 at 02:37:45PM -0700, Josh Triplett wrote
 I think the main reason this is not a issue is the following:
 Everybody realizes that because of the configurability of Linux and
 Debian in particular, if someone wants to run and mix-and-match
 technologies on one's own system, one can do so. There is no way this
 can be technically prevented.
 
 This particular license statements intends to forbid shipping
 mix-and-matching code and applications, as once mentioned as example, a
 Sun's JVM combined with classpath.
 
 As per FAQ#14, Sun has an issue if parts of the JDK/JRE were used
 together with other non-Sun parts to create a Java implementation.
 Debian does ship Sun's JDK/JRE in such a way that it is configured to
 run completely as a single suite. Existance of other packages, even
 those implementing similar features to the same API, do not result in a
 Java implementation configured as such by Debian that's consisting of
 bits of Sun with bits of other things.

Debian has configured libcommons-el-java (for example) to run with
either gij-4.1 or sun-java5-jre via the virtual package java2-runtime.
They should just work together.  That is the whole point of
dependencies.

 It is still possible for extra packages that implement part of the Java
 class library API to be configured by the user to create a configuration
 that is in violation of the DLJ. However, Debian doesn't do so, and the
 user must have read the license while installing sun-java5 from
 non-free, and then realizes that this is not what Sun wants. Note that
 merely apt-get install'ing does *not* get you into this situation, in
 order to get additional libraries to supersede/augment the available
 classes, you need to modify classpath directives (similar to
 LD_LIBRARY_PATH for C): see libcharva1-java, libgnu-regexp-java and
 libgetenv-java's README.Debian for example.

You do not have to override the existing implementation of those API's
to get into trouble.  The language in the DLJ is same or similar,
not just same.

 Once a newer Java policy makes it easier to just install and use such
 additional classes by managing the classpath better, we'll need to
 ensure that if Sun is used, this is not happening by default.

The best way to do this is to have Sun's java not provide generic
virtual packages like java2-runtime.

   As long as a package is not using the exact same namespace and
   interface, it's not a drop-in replacement, but rather a similar (but
   distinct) piece of software that you're perfectly fine of using with Sun
   Java.
  
  Neither the DLJ nor Sun's FAQ make any mention of namespaces, and
  neither one deals only with exact matches or drop-in replacements.
  Nothing in either document suggests that these packages can coexist with
  Sun Java.  Any Java package in Debian which follows the Debian Java
  policies qualifies as configured to run with Sun Java, and thus any
  such package which implements the same or similar interfaces will
  constitute a license violation.
 
 I disagree with 'qualifies as  configured to run with Sun Java', see
 above, and also, I don't share this reading of what qualifies software
 that implements the same or similar API's, from elaborate talks with
 Sun, I believe we must interpret this as narrowly as I suggested above.
 Anyway, the latter point is not very relevant because of the former.

The elaborate talks you had with Sun are not part of the license.  I
have asked Tom Marble more than once whether his comments are binding
on Sun.  He has declined to answer that question, so we can only go by
what is in the license.

snip
 On Sat, Jul 22, 2006 at 12:40:12AM -0700, Walter Landry wrote:
  In any case, it may well be that libgetenv-java is buggy.  Fixing it
  should not suddenly cause a license problem.  There are still all of
  the packages
  
libcharva1-java
libcommons-*-java
libregexp-java
  
  which have dependencies that are fulfilled by java2-runtime.
  liboro-java should probably depend on a java2-runtime as well.
 
 I believe the above also addresses your concerns.
 
 Therefore, I'm now closing this bug (again), if anyone still believes
 there is a problem, please specify a concrete working example of how to
 get a DLJ-incompatible situation with just using apt-get install.

apt-get install sun-java5-bin sun-java5-jre
apt-get install libcommons-el-java

libcommons-el-java is an implementation of the API in
javax.servlet.jsp.el.

This is really a simple bug to fix.  Just take out the Provides:
java2-runtime.  Then the second apt-get line would pull in a free
runtime.

Cheers,
Walter Landry
[EMAIL PROTECTED]



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



Bug#370295: DLJ prevents running jython with sun-java

2006-07-22 Thread Walter Landry
Tom Marble [EMAIL PROTECTED] wrote:
 Walter Landry wrote:
  [...]
  All of the examples given above are good, but libgetenv-java is about
  as clear as you can get.  It only depends on java2-runtime and libc,
  and it serves as a replacement for java.lang.System.getenv.  It
  creates a hybrid implementation.
  
  If you want to argue that it is the other packages fault, go ahead.
  That would make the java2-runtime virtual package much less useful, in
  which case there should be a java2-runtime-free virtual package.
 
 Obviously making sun-java5 not provide java2-runtime (or whatever
 provides Debian Java Policy settles upon) defeats the purpose
 of packaging Sun Java.

Not really.  Having sun-java5 provide java2-runtime only allows other
Debian packages to use sun-java5 without special casing.  Users can
still manually specify everything needed to compile and run programs.
That is a big improvement over the current situation.

In any case, a package can still use a Depends: line like

  Depends: java2-runtime | sun-java5-jre

if there is no conflict between what the package does and the DLJ.

 I appreciate your trying to address an entire class of problems, but
 in the case of libgetenv-java it appears that the jar is malformed.
 We're it formed correctly it would be in it's own namespace.

The problems persist even if it is in its own namespace.

In any case, it may well be that libgetenv-java is buggy.  Fixing it
should not suddenly cause a license problem.  There are still all of
the packages

  libcharva1-java
  libcommons-*-java
  libregexp-java

which have dependencies that are fulfilled by java2-runtime.
liboro-java should probably depend on a java2-runtime as well.

Finally, can Debian rely on your statements as official statements of
Sun, or must Debian only look to the DLJ and DLJ FAQ?

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#377560: More direct replacement examples

2006-07-14 Thread Walter Landry
Jeroen van Wolffelaar wrote:
 On Sun, Jun 04, 2006 at 02:37:45PM -0700, Josh Triplett wrote:
  jikes-sun implements a javac compiler, and uses the Sun JDK.
 
 This is indeed as far as I can see a violation of Sun's license to
 do, it's however a bug in jikes-sun: jikes-sun is the package
 combining technology in a way that's not allowed by the license of
 one of the used packages. This was already a problem before the DLJ,
 also the old Sun Java license didn't allow to do so.

This is not actually a bug, since javac does not use sun-java5, but
blackdown's distribution.  That makes any issues with jikes-sun wholly
separate from the sun-java5 packages.  The relevant part of the EULA
you get from blackdown is

 A.Software Internal Use and Development License Grant. Subject to the
 │ terms and conditions of this Agreement, including, but not limited to
 │ the Java Technology Restrictions of these Supplemental Terms, Sun grants
 │ you a non-exclusive, non-transferable, limited license without fees to
 │ reproduce internally and use internally the Software complete and
 │ unmodified for the purpose of designing, developing, and testing your
 │ Programs.

I see no conflict with the end-user using jikes-sun in conjunction
with the JDK to design, develop, and test programs.

So I see no reason why this bug can not be closed.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#370295: DLJ prevents running jython with sun-java

2006-07-14 Thread Walter Landry
reopen 370295
thanks

Jeroen van Wolffelaar [EMAIL PROTECTED] wrote:
 On Sun, Jun 04, 2006 at 08:16:24AM -0700, Walter Landry wrote:
  In the Distributor License for Java, there is the clause
  
  (c) you do not combine, configure or distribute the Software to
  run in conjunction with any additional software that implements
  the same or similar functionality or APIs as the Software;
  
  Debian distributes Jython, which can run with sun-java.  However,
  Jython, being a reimplementation of Python, implements a great deal of
  similar functionality as sun-java.
 
 In Sun's, ftp-master's, nor package maintainer's opinion, this is
 something that the license is seeking to prevent at all -- see also the
 FAQ questions now included in upstream's LICENSE file (and in Debian in
 'copyright').

The FAQ makes it clear that shipping Python and Perl are not problems.
It does not make it clear that Jython is ok, although Tom's reply
clearly states that.  Not as good as I would like, but I will take it.

snip
  Any libfoo-java package in Debian will run with the current installed
  JDK.  Thus, any libfoo-java package in Debian which implements the same
  or similar functionality as Sun Java causes Debian to violate the
  license on Sun Java.  Obvious examples include libswingwt-java (which
  implements much of the Swing API), libcharva1-java, libcommons-*-java
  (similar functionality), Java XML processing tools that implement the
  standard APIs, libgnu-regexp-java (since, if I recall correctly, Sun
  Java includes regular expression handling), liboro-java (same reason),
  libregexp-java (same reason), libgetenv-java (specifically notes itself
  as a replacement for java.lang.System.getenv), and probably others.
 
 I don't think any of these are a violation of the license, most clearly
 as per FAQ#14.

Sun clearly does not want to allow hybrid implementations, where parts
of Sun's JDK is replaced by another.  It seems they even object if the
new parts use a different namespace.  From the FAQ #14

  However, you can't use pieces of the JDK configured in conjunction
  with any alternative technologies to create hybrid implementations,
  or mingle the code from the JDK with non-JDK components of any kind
  so that they run together.

All of the examples given above are good, but libgetenv-java is about
as clear as you can get.  It only depends on java2-runtime and libc,
and it serves as a replacement for java.lang.System.getenv.  It
creates a hybrid implementation.

If you want to argue that it is the other packages fault, go ahead.
That would make the java2-runtime virtual package much less useful, in
which case there should be a java2-runtime-free virtual package.

 Since I believe that there are no doubt-points left legal-wise,
 especially and specifically not on sun-java5 itself, I'm now closing
 this bug.

I have reopened the bug.  As I noted earlier, a simple technical fix
is to make sun-java not provide java2-runtime etc.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#370296: DLJ only allows distributing the exact same file

2006-07-10 Thread Walter Landry
Jeroen van Wolffelaar [EMAIL PROTECTED] wrote:
 # submitter clarification needed
 tags 370296 moreinfo
 thanks
 
 On Tue, Jun 06, 2006 at 07:13:10AM -0700, Walter Landry wrote:
  Matthias Klose [EMAIL PROTECTED] wrote:
   severity 370296 normal
   thanks
   
   I think that is your interpretation. The paragraph cited never talks
   about the exact same file. It's an archive of some form, which is
   unpacked and repacked in the deb format.
   
   - no files in the archive is distributed modified.
   - all files in the archive are complete. completeness is guaranteed
 by package dependencies, except for the files declared as
 optional in the README.
  
  In the README, there is the statement
  
The limited set of files from the JDK listed below may be included
in vendor redistributions of the J2SE Runtime Environment. They
cannot be redistributed separately, and must accompany a JRE
distribution.
  
  This does not seem to allow a separate JDK package, since the JRE
  would not _always_ accompany the JDK.  Later, the README says
 
 In Debian, a JRE is always accompanying a JDK thru the dependencies, so
 this point is moot.   ^

That is the the point.  It is only through dependencies.  I can still run

  wget 
http://http.us.debian.org/debian/pool/non-free/s/sun-java5/sun-java5-jdk_1.5.0-07-1_i386.deb

and have the JDK without the JRE.  I can even install it, using the
appropriate options to dpkg.  I could easily imagine a confused user
doing exactly that.  That is why it is necessary to get a
clarification from Sun that enforcing completeness only through
package dependencies is ok.

snip
   We did check with Sun that the resulting packaging conforms to the
   distribution terms.
  
  If you have a binding statement from Sun that it is OK to enforce
  completeness only through package dependencies, then it would be great
  if you could put that in the copyright file.
 
 This has meanwhile happened.

Where?  The DLJ FAQ does not address this.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#335278: shc -- #335278 broken packaging -- non-DD NMU prepared

2006-06-30 Thread Walter Landry
George Danchev [EMAIL PROTECTED] wrote:
 On Thursday 29 June 2006 01:10, [EMAIL PROTECTED] wrote:
  On Wed, Jun 28, 2006 at 12:58:59AM +0200, Alexander Schmehl wrote:
   /**
* 'Alleged RC4' Source Code picked up from the news.
* From: [EMAIL PROTECTED] (John L. Allen)
* Newsgroups: comp.lang.c
* Subject: Shrink this C code for fame and fun
* Date: 21 May 1996 10:49:37 -0400
*/
 
  I think it should be easy to replace that code by a DFSG-free
  implementation of RC4. Openssl include one.
 
 I'm afraid that I can not use OpenSSL licensed code into GPL program (shc) 
 without a special OpenSSL exception given from the shc's upstream, which 
 unfortunately did not respond to any mail sent yet. Also I'm a litle bit 
 scared to reimplement that myself - I might introduce hell of bugs at 
 least ;-) ... deviating from upstream for the matter of that is not a good 
 idea also.

libgcrypt also has an RC4 implementation.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#370245: Export control problems in license

2006-06-07 Thread Walter Landry
Tom Marble wrote:
 Walter:
 
 I have just posted a notice to debian-legal about the
 availability of new DLJ FAQ [1] which further clarifies
 our intent.
 
 Please see the new FAQ#30 [2].

Unfortunately, the problem is not with the DLJ.  The DLJ was always
fine.  To be specific, when the package from Sun is installed, the
clause is in a file at the top level called COPYRIGHT.  If the
copyright notice in that file does not actually apply to anything in
the java package, then it should be removed.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#370296: DLJ only allows distributing the exact same file

2006-06-06 Thread Walter Landry
Matthias Klose [EMAIL PROTECTED] wrote:
 severity 370296 normal
 thanks
 
 I think that is your interpretation. The paragraph cited never talks
 about the exact same file. It's an archive of some form, which is
 unpacked and repacked in the deb format.
 
 - no files in the archive is distributed modified.
 - all files in the archive are complete. completeness is guaranteed
   by package dependencies, except for the files declared as
   optional in the README.

In the README, there is the statement

  The limited set of files from the JDK listed below may be included
  in vendor redistributions of the J2SE Runtime Environment. They
  cannot be redistributed separately, and must accompany a JRE
  distribution.

This does not seem to allow a separate JDK package, since the JRE
would not _always_ accompany the JDK.  Later, the README says

  If you wish to distribute the JRE rather than the JDK...

which implies that they do not consider the case of splitting the JDK
from the JRE.

 We did check with Sun that the resulting packaging conforms to the
 distribution terms.

If you have a binding statement from Sun that it is OK to enforce
completeness only through package dependencies, then it would be great
if you could put that in the copyright file.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#370245: Export control problems in license

2006-06-05 Thread Walter Landry
Steve Langasek [EMAIL PROTECTED] wrote:
 On Sun, Jun 04, 2006 at 02:56:07AM -0700, Walter Landry wrote:
  Package: sun-java5-jre
  Version: 1.5.0-06-1
  Severity: serious
 
  In the copyright file there is the phrase
 
Export or reexport to countries subject to U.S. embargo or to
entities identified on U.S. export exclusion lists, including, but
not limited to, the denied persons and specially designated
nationals lists is strictly prohibited.
 
  This is also repeated in French.  The mirrors in the US may or may not
  implement this kind of restriction, but I do not think that the Debian
  mirrors in Canada (for example) restrict downloads from Cuba.
 
 This notice does not claim to be part of the license of the work.  

This phrase is part of the copyright statement.  I do not understand
why you think it is not binding.  The DLJ does not claim to be the
sole license for the work.

 It states that distribution to these parties is strictly
 prohibited.  This is a true statement: it is strictly prohibited,
 by the United States government.  I don't see any reason why it's
 warranted to read more into it than that.

If that is all that were meant, then they would have been satisfied
with the phrase

  This product is covered and controlled by U.S.  Export Control laws
  and may be subject to the export or import laws in other countries.

which is also in the copyright statement.  They went further than
that, which would lead a reasonable person to believe that they
intended a greater effect.  They even put it in french, which strongly
implies that they meant it to apply to Canadians.  If Sun does not
intend that to be the case, then they can remove the phrase.  It is
easy for Sun to fix.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#370295: DLJ prevents running jython with sun-java

2006-06-05 Thread Walter Landry
Steve Langasek [EMAIL PROTECTED] wrote:
 On Sun, Jun 04, 2006 at 08:16:24AM -0700, Walter Landry wrote:
  This can be fixed by making Jython conflict with sun-java, although I
  suspect that there may be other packages that also cause problems.

Another fix for this particular problem is to make sun-java not
Provide:java-runtime etc. at all.

 There have been various clarifications that the intent of this clause is to
 prohibit distributing sun-java5 in a configuration that mixes and matches
 parts of Sun's implementation with other Java implementations.  
 Why are these clarifications not sufficient when we regularly accept
 clarifications of this nature from other copyright holders?

There are a few problems here:

1) Clarifications from other copyright holders do not come with a big
   disclaimer stating that the clarification has no legal weight.
   Debian relies on the clarification having legal weight.

2) Clarifications are typically for minor ambiguities.  One example is
   where someone put code into a project and forgot to change the
   license to the project's license, thus creating a conflict.

   For cases where there are real problems with the wording of the
   license, Debian makes the copyright holder rewrite the license.

3) There are only two clarifications I know of.  One is in the
   non-binding DLJ FAQ, and the other is from Tom Marble [1].  Neither
   of these clarifications limit the restrictions to Java
   implementations.  For example, in Tom's clarification he says [2]

 In a similar way please don't take bits from the Java platform
 and use them as part of or to complete alternate technologies
 (e.g. plugin.jar).

  So using Java's plugin mechanism to implement python plugins for
  Jython is not allowed.  And this makes sense.  Sun would definitely
  be unhappy if the JDK were used to implement J++ or C#, especially
  because they are not Java.

Cheers,
Walter Landry
[EMAIL PROTECTED]

[1] It is unclear to me how binding Tom Marble's clarifications are on
Sun.  I somehow doubt that he is clearing every email with Sun's
legal department, though I could be wrong.

[2] http://lists.debian.org/debian-legal/2006/05/msg00165.html


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



Bug#370245: Export control problems in license

2006-06-04 Thread Walter Landry
Package: sun-java5-jre
Version: 1.5.0-06-1
Severity: serious

In the copyright file there is the phrase

  Export or reexport to countries subject to U.S. embargo or to
  entities identified on U.S. export exclusion lists, including, but
  not limited to, the denied persons and specially designated
  nationals lists is strictly prohibited.

This is also repeated in French.  The mirrors in the US may or may not
implement this kind of restriction, but I do not think that the Debian
mirrors in Canada (for example) restrict downloads from Cuba.

Note that this is different from the clause in the DLJ, which could
just be interpreted as a notice about US law.

This problem was brought up with Sun [1], but they did not respond.

Cheers,
Walter Landry
[EMAIL PROTECTED]

[1] http://lists.debian.org/debian-legal/2006/05/msg00176.html


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



Bug#370296: DLJ only allows distributing the exact same file

2006-06-04 Thread Walter Landry
Package: sun-java5-jre
Version: 1.5.0-06-1
Severity: serious

In the DLJ, there is the clause

Sun also grants you a non-exclusive, non-transferable,
royalty-free limited license to reproduce and distribute the
Software, directly or indirectly through your licensees,
distributors, resellers, or OEMs, electronically or in physical
form or pre-installed with your Operating System on a general
purpose desktop computer or server, provided that: (a) the
Software and any proprietary legends or notices are complete and
unmodified; ...

According to the copyright file, Debian gets the package from

  http://download.java.net/dlj/binaries/

That location only has a single binary package.  However, Debian
splits that into multiple packages (sun-java5-bin, sun-java5-jdk,
sun-java5-jre, etc.).  So Debian is not distributing the code complete
and unmodified.

This problem was brought up with Sun [1].  They explained why it is
nice to split up the package, but failed to explain why Debian is
allowed to do the split.  Jeroen also commented about it [2], and
makes the argument that the changes necessary for package management
are acceptable.  But this does not explain why Debian can split the
package, thus only distributing part of what Debian gets from Sun.

Cheers,
Walter Landry
[EMAIL PROTECTED]

[1] http://lists.debian.org/debian-legal/2006/05/msg00151.html
[2] http://lists.debian.org/debian-legal/2006/05/msg00141.html


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



Bug#370295: DLJ prevents running jython with sun-java

2006-06-04 Thread Walter Landry
Package: sun-java5-jre
Version: 1.5.0-06-1
Severity: serious

In the Distributor License for Java, there is the clause

(c) you do not combine, configure or distribute the Software to
run in conjunction with any additional software that implements
the same or similar functionality or APIs as the Software;

Debian distributes Jython, which can run with sun-java.  However,
Jython, being a reimplementation of Python, implements a great deal of
similar functionality as sun-java.

This can be fixed by making Jython conflict with sun-java, although I
suspect that there may be other packages that also cause problems.

Cheers,
Walter Landry
[EMAIL PROTECTED]




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



Bug#346354: AW: Bug#346354: Is distribution of the maxdb-doc package a GPL violation?

2006-04-27 Thread Walter Landry
[EMAIL PROTECTED] wrote:
 I have verfified that the actual sources for the generated HTML are
 Microsoft Word documents and that those will not be
 distributed. Does the mean that the maxdb-doc package will have to
 be pulled from the repository?

Yes, unless you get a license exemption from the copyright holder
allowing Debian and its mirrors to distribute the HTML as is.  They
will probably agree.  In that case, it goes into non-free.

Sorry for the extra work.

Cheers,
Walter Landry
[EMAIL PROTECTED]



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



Bug#346354: AW: Bug#346354: Is distribution of the maxdb-doc package a GPL violation?

2006-04-27 Thread Walter Landry
Steve Langasek [EMAIL PROTECTED] wrote:
 On Thu, Apr 27, 2006 at 05:35:51AM -0700, Walter Landry wrote:
  [EMAIL PROTECTED] wrote:
   I have verfified that the actual sources for the generated HTML are
   Microsoft Word documents and that those will not be
   distributed. Does the mean that the maxdb-doc package will have to
   be pulled from the repository?
 
  Yes, unless you get a license exemption from the copyright holder
  allowing Debian and its mirrors to distribute the HTML as is.  They
  will probably agree.  In that case, it goes into non-free.
 
 It's not obvious to me that either the license exemption or the non-free
 categorization are necessary here.  GPL requires the preferred form for
 modification, which for most people working on derivative works would
 probably *not* be the Word docs?

The people actually doing modifications use the Word format, not the
HTML format.  It seems clear to me that the Word format is
preferred.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#346354: Is distribution of the maxdb-doc package a GPL violation?

2006-04-26 Thread Walter Landry
Guido Trotter [EMAIL PROTECTED] wrote:
 
 Hi!
 
 I've been asked by the debian release team to look into this bug and see what
 can be done to have a successful resolution... The situation seems to be this
 one:
 
 1) maxdb-doc is a package which contains some GPL licensed html manual files
 2) the GPL asks for the source code (defined as: preferred form of
 the work for making modifications to it) to be available
 3) the html files are determined to be automatically generated by a
 tool called SAP Html Export, and the files which originate them
 are not available
 
 This seems to be a problem only because the GPL is used... Would the
 files be under a less restrictive licence we would be perfectly OK
 distributing them as is...

Sort of.  Debian requires source for everything that it distributes in
main.  If it were not GPL'd, it would still have to go into non-free.

 I'm addressing this mail to the debian-legal list too for a
 consultation about whether they think this package is distributable
 at all or not as is, and what would they recommend...

As is, it is not distributable.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#323099: no longer a bug.

2006-03-12 Thread Walter Landry
Mike O'Connor [EMAIL PROTECTED] wrote:
 from the documentation in question:
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.2 or
 any later version published by the Free Software Foundation; with the
 Invariant Sections being ``GNU General Public License'' and ``GNU Free
 Documentation License'', with no Front-Cover Texts, and with no
 Back-Cover Texts.  A copy of the license is included in the section
 entitled ``GNU Free Documentation License''.
 
 The only things the documentation license holds as invariant are the GPL
 and the GFDL themselves, and Debian already accepts those as being
 invariant, this documentation should no longer be considered non-free in
 light of GR-2006-01.  But becuase of this, I'm copying debian-legal.

Unfortunately, no.  The GFDL already requires that the license be
included in the document, so putting it in an invariant section does
not change anything.  However, that is not true for the text of the
GPL.  If someone wants to reuse the documentation for a BSD-licensed
work, the GPL would be completely off topic.

Cheers,
Walter Landry
[EMAIL PROTECTED]


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



Bug#349279: tailor: _process.py seems under non-GPL license

2006-01-21 Thread Walter Landry
Osamu Aoki [EMAIL PROTECTED] wrote:
 Although /usr/share/doc/tailor/copyright states GPL for tailor package,
 this is not GPL for sure. -- problem.

This is a problem, though not all that serious.  The copyright info
must be correct.

 This license only gives permission when fee is not charged.  That seems
 to be DSFG1 violation.  Also mixing code of GPL and this seems to be
 incompatible. 

This is a fairly standard license.  The usual way of interpreting it
is that you need not pay any fees in order to copy, modify, or
distribute.  Not that you may not sell copies.  So it is GPL
compatible.

 I looked further and found practically the same code is licensed under 
 # Licensed to PSF under a Contributor Agreement.
 # See http://www.python.org/2.4/license for licensing details.
 for python2.4.  (subprocess.py)  So no real issue should exist.  Thus
 marked this as important instead of serious.

If the version in Debian depends on python 2.4, then this is fine.
Upstream may balk at requiring 2.4 though.  I think it is best just to
update the copyright file.

Cheers,
Walter



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



Bug#302988: IBM Thinkpad T43 hardware detection incomplete

2005-04-05 Thread Walter Landry
Christian Perrier [EMAIL PROTECTED] wrote:
 Quoting Geert Stappers ([EMAIL PROTECTED]):
 
  Could you boot the debian-installer another time on your T43?
  
  And modprobe for the right sata module and share the information with us?
 
 If you don't know which SATA module is the right one, I think that
 trial and error may help.
 
 AFAICT, the available SATA modules for the 2.6.8 kernel are:
 
 ./scsi/sata_nv.ko
 ./scsi/sata_promise.ko
 ./scsi/sata_sil.ko
 ./scsi/sata_sis.ko
 ./scsi/sata_svw.ko
 ./scsi/sata_sx4.ko
 ./scsi/sata_via.ko
 ./scsi/sata_vsc.ko

Actually, I think that it is ata_piix.  I am attaching my working
2.6.11.5 kernel config and the output of lsmod.  I am not using an
initrd image.  However, if I modprobe ata_piix and sd_mod, the
installer still does not find the hard drive.  I don't find any
entries in /dev/scsi either.  It does not help to modprobe all of the
other sata_* modules either.

I mentioned earlier that I turned off Advanced Partition Support.  For
example, see

  http://kerneltrap.org/node/970

I seem to remember reading somewhere that this bug was fixed in
2.6.10.  I have not tried the 2.6.8 kernel without Advanced Partition
Support.

Cheers,
Walter Landry
[EMAIL PROTECTED]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11.5
# Sat Mar 26 10:43:38 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION=
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUMM=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
# CONFIG_SMP is not set
# CONFIG_PREEMPT is not set
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y

#
# Firmware Drivers
#
CONFIG_EDD=m
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
# CONFIG_REGPARM is not set

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SOFTWARE_SUSPEND is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_IBM=y
CONFIG_ACPI_TOSHIBA=m
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER is not set
# CONFIG_ACPI_CONTAINER is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_STAT_DETAILS is not set