Bug#311436: imo this bug should be downgraded.

[peter green]

it seems that this bug was actually in 2.0.0-1 and therefore only effected
updates from 2.0.0-1 to 2.0.0-2. imo since 2.0.0-1 was never in testing this
bug should not be allowed to keep the current version of freepascal out of
testing.




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

Bug#404611: the problem is

[Peter Green]

that iceweasel replaces that directory with a symlink but it can't do that
if another package already has files in it. What i think needs to happen
is that any plugins need to be modified to only put the files in the
iceweasel directory and then i belive the iceweasel package needs to be
made to conflict with the old versions of those packages but i'm not an
expert on this.


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

Bug#377032: i'm thinking

[peter green]

wouldn't it be more sensible to combine the protocol, hostname, port (if such a 
question exists) and directory questions into a single request for a mirror 
url? 

Bug#377032: i'm thinking

[peter green]

> For experienced users, yes. For newbies, definitely not (IMNSHO). For 
> them, the only really variable part they understand is the hostname, the 
> rest is goobleycook.
> Feel free to try to convince me otherwise.
imho there are only two classes of people who are likely to be using the manual 
entry option: those with enough knowlage of urls to understand a request for a 
mirror url with an example and those being told to do it explicitly by a local 
expert (e.g. thier network administrator) who should just be able to give them 
a url that they can type without understanding it just as they do for websites 
already.

for both of theese situations i'd think a single url would be less hassle than 
four seperate questions some of which are hidden in non-expert mode despite the 
need for them on some networks.

though maybe if going with the url option it would be nice to make it 
auto-prepend a default protocol (like web browsers do) and try adding /debian 
to the end if it fails to find a valid debian mirror at the url given (this 
would mean that someone could still enter just ftp.uk.debian.org and it would 
still work).

Bug#404972: Minor problems with Notebook HP nc 6000

[peter green]

> In particular, it kept waiting at the fd0 lines, so what I think 
> is that it
> had troubles with that.  This notebook does NOT have a floppy drive, so I
> guess that the long wait is related to fd0 timing out.
is this by any chance one of those laptops where the bios thinks there is a 
floppy drive even when there isn't (i've seen this before with notebooks with 
hotswap drives)

Bug#404990: sort out default page for first start after upgrading

[peter green]

package:iceweasel
version:2.0.0.1+dfsg-1
severity:minor

after upgrading iceweasel i got directed to a nonexistant whats new page, imo 
it would be sensible to either drop use of a special start page for the first 
run after upgrading or change this to point to an iceweasel specific page.

Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible

[peter green]

> However, when booting after the installation, the NPE driver seems to
> assume control of the interface name eth0, which causes something to
> rename the interface of the USB to ethernet adapter to eth1_rename.
it sounds to me like the built in nic is getting detected first before the USB 
to ethernet adaptor, udev should then swap the names back to those used at 
install time.

It looks like it is renaming the usb to ethernet to a temporary name (nessacery 
for a swap operation) but failing to rename the built in nic for some reason.

Bug#407602: inappropriate conffile prompts on upgrading from firefox on etch

[peter green]

package: iceweasel
severity: minor

I upgraded my etch system to have iceweasel wirh apt-get install iceweasel (btw 
it removed firefox but left mozilla-firefox, i don't think that is relavent to 
this issue though).

i got a couple of conffile prompts as below.

Configuration file `/etc/iceweasel/profile/bookmarks.html'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : background this process to examine the situation
 The default action is to keep your current version.
*** bookmarks.html (Y/I/N/O/D/Z) [default=N] ?

Configuration file `/etc/iceweasel/pref/iceweasel.js'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
  Z : background this process to examine the situation
 The default action is to keep your current version.
*** iceweasel.js (Y/I/N/O/D/Z) [default=N] ?
Please restart any running Iceweasels, or you will experience problems.

my understanding is that conffile prompts are only supposed to happen if files 
are either edited manually by the sysadmin or changed by a non-debian tool, i'm 
pretty sure neither was the case on this system.

Bug#407696: add a guided partitioning option for resizing an existing partition

[peter green]

package: debian-installer

currently to use guided partitioning on a system with no unpartitioned free 
space the user must go into manual partitioning, resize the existing partition 
and then go back out of manual partitioning and select guided using the largest 
free space, this is somewhat unintuitive.

since resizing an existing partition to make room for debian is likely to be 
one of the most common ways of installing it i think it deserves a seperate 
option at the same level as the guided-use entire disk and guided-use largest 
free space options.

Bug#407759: Set-up attempt failed.

[peter green]

> The install did not find the CDROM drives.  
As a workarround you might like to try installing using the boot, root, 
net-drivers 1 and net-drivers 2 floppies.

Bug#407689: tasksel: Please consider adding a Development task for Etch

[peter green]

> The problem with adding a development task has always been, and
> continues to be, that people do not use the same tools for development,
> and that there are no good defaults beyond basic C-style development
> tools. 
mind you a similar thing applies to say the file server task, there are at 
least 3 different types of server that someone could want that would fit the 
"file server" discription and its not at all clear which ones will be installed.

I personally belive that tasksel needs a major overhaul and is practically 
useless in its present form, what i think is really needed is a set of 
categories each with a number of entries so you'd say have a desktop category 
(with gnome desktop, kde desktop, xfce desktop etc), a webserver category (with 
basic websever, lamp webserver etc), a fileserver category (with samba,nfs and 
ftp options), a development category (with basic development, kernel 
development, debian package development, java development etc) and so on.


> This is why #266702 is still open. The fact that those default
> C development tools are no longer in standard still doesn't make
> "development" a sensible task. It's not the same class of thing as
> running a web server or using a desktop, both of which can be
> accomplished well, if not perfectly for everyone, with a predetermined
> list of software.
maybe development is the wrong name but even a task that just installed 
build-essential and the kernel headers would imo make things a lot easier for 
those stuck with unusual hardware or wanting to compile software that is not 
packaged off the bat (its not at all obvous to newbies that the package they 
need to make basic compilation work in one step is called build-essential and 
its pretty horrible getting compilation to work one package at a time).

Bug#257302: xfree86: general complaint about XFree86 on Dell LatitudeD400

[peter green]

> I'll try them as soon as Etch is out. As Stable. ;)
If you do that and the problem is still there then it will be too late for etch 
to get a fix.

Bug#401051: seems to be a dupe

[peter green]

this appears to be a dupe of 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402407

Bug#401266: Bug#393422: Contains non-free files

[Peter Green]

if you belive that the files used to build debians packages are free then
wouldn't the obvious thing to do be to remove everything else from the
source packages?


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

Bug#402482: tried to reproduce and failed.

[peter green]

i've tried to reproduce this bug but failed

btw in the process of trying this i discovered that busybox --install 
doesn't seem to work either i had to manually copy busybox and make a 
symlink for this test.


debian:~/busyboxinstall# cp /bin/busybox .
debian:~/busyboxinstall# ln -s gunzip busybox
ln: creating symbolic link `busybox' to `gunzip': File exists
debian:~/busyboxinstall# ln -s busybox gunzip
debian:~/busyboxinstall# ./gunzip
gunzip: compressed data not read from terminal.  Use -f to force it.
debian:~/busyboxinstall# echo foo | foo.txt
bash: foo.txt: command not found
debian:~/busyboxinstall# echo foo > foo.txt
debian:~/busyboxinstall# echo bar > foo.txt
debian:~/busyboxinstall# echo foo > foo.txt
debian:~/busyboxinstall# echo foo > bar.txt
debian:~/busyboxinstall# gzip foo.txt
debian:~/busyboxinstall# gzip bar.txt
debian:~/busyboxinstall# cat foo.txt.gz bar.txt.gz > baz.txt.gz
debian:~/busyboxinstall# gunzip baz.txt.gz
debian:~/busyboxinstall# cat baz.txt
foo
foo
debian:~/busyboxinstall# cat foo.txt.gz bar.txt.gz > baz.txt.gz
debian:~/busyboxinstall# ./gunzip baz.txt.gz
debian:~/busyboxinstall# cat baz.txt
foo
foo
debian:~/busyboxinstall# ls -l
total 428
-rw-r--r-- 1 root root 32 2006-12-17 02:30 bar.txt.gz
-rw-r--r-- 1 root root  8 2006-12-17 02:31 baz.txt
-rwxr-xr-x 1 root root 418112 2006-12-17 02:29 busybox
-rw-r--r-- 1 root root 32 2006-12-17 02:30 foo.txt.gz
lrwxrwxrwx 1 root root  7 2006-12-17 02:29 gunzip -> busybox
debian:~/busyboxinstall#

_
Visit MSN Holiday Challenge for your chance to win up to $50,000 in Holiday 
cash from MSN today!  
http://www.msnholidaychallenge.com/index.aspx?ocid=tagline&locale=en-us




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

Bug#403890: installation successfull with some manual work

[peter green]

Package: installation-reports

Boot method: CD boot with nothing extra typed at boot prompt
Image version: Etch RC1 full CD 1
Date: 

Machine: maxdata PC
Processor: celeron D (at least according to the label on the front)
Memory: 256MB
Partitions: 

Output of lspci -nn and lspci -vnn:

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]
Detect hard drives: [O]
Partition hard drives:  [E]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

The installer told me that my existing NTFS partition could not be resized due 
to an unknown error and to look at VC4 for more details (btw in errors like 
that you might wan't to give a brief description of how to switch virtual 
consoles). VC4 told me there were inconsistancies and to run "chkdsk -f" and 
then reboot windows twice. I followed its reccomendations and loaded the 
installer again. 

Resizing still failed but this time i was just dumped back in the manual 
partitioning window with no error. Checking vc4 told me the journal was not 
clean and to boot windows and shutdown cleanly to clean it. I did this and then 
back into the installer which promptly failed to resize again in exactly the 
same way.

I decided to try ntfsfix but I could not seem to find any way to manually 
install/extract debs/udebs within the installer environment. Eventually i 
resorted to installing ntfsprogs on another debian system and transfering 
ntfsfix and libntfs into the installer environment using http. ntfsfix ran with 
no errors and resizing succeeded afterwards.

once the resize was done i wen't into "guided partitioning" and told it to use 
the "largest free space" and put "everything in one big position". This created 
two partitions a root partition and a swap partition (since this option is 
aimed at people who don't wan't to tie themselves to particular allocations 
wouldn't it be more sensible and more consistant with the options name to 
create a swapfile instead?). 

user/password setup worked but i could find no way to bypass creation of a 
normal user account (i'm sure this was possible in the sarge installer).

Installing tasks wen't ok, i selected "standard system" and desktop, it did 
seem to be downloading some stuff from the net as well as using the CD though 
(i belive this is a known issue with the standard tasks now being too big to 
fit on CD1)


everything else went fine and.

Bug#403890: oops forgot to finish off the report

[peter green]

it should have said and windows still booted fine afterwards.

Bug#403890: installation successfull with some manual work

[peter green]

> 
> This was possible in export installs and this is still possible in
> expert installs. The behaviour has not changed with regard to that matter.
> 
i'm pretty sure i've never intentionally booted d-i in expert mode, and when i 
did a sarge install i'm pretty sure i managed to skip creating a normal user 
account (i think it prompted me for one and i selected some kind of cancel 
option), unfortuntely i don't have any spare systems to test this on now.

also is there any way to switch to expert mode mid install and if not why?

Bug#403890: installation successfull with some manual work

[peter green]

> Not sure what was wrong here, but it does not seem like something we can 
> fix in the installer. 
well ntfsfix cleared up the journal and made it work so it would presumablly be 
possible to do that, i dunno how safe ntfsfix is though.

btw why do you ask for installation reports even on sucessfull installations?

Bug#196729: old bug, whats the status?

[peter green]

you reported this bug over 3 years ago and gaim has changed a lot in 
that time. If you are still experiancing the crashes with the current 
version of gaim please provide more recent backtraces, otherwise please 
close the bug



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

Bug#264688: looks like an endian screwup, is it still happening?

[peter green]

this looks like a UCS2/UTF-16 endian screwup (a-z all map to cjk 
ideographs when byteswapped and - and . both map to characters from 
strange languages that you probablly won't have fonts for)


is this issue still happening with 2.0.0beta4?







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

Bug#397593: looks like another instance of sending non utf-8 text to dbus

[peter green]

tags 39753 patch
thanks

note: this reply is to the first message in this bug, the second message looks 
like it could be a seperate (but most likely similar) issue.

from the most recent changelog:
   * 06_irc-signal-crash.patch:
 - Add patch to work around crash on receiving non-ASCII characters
   in IRC by not emitting the new "irc-receiving-text" signal; the text
   from the server needs to be normalized into proper UTF-8 before sending
   it to dbus.

from looking at the backtrace and the source it seems there is an 
"irc-sending-text" signal that also needs to be disabled, i've attatched a 
modified version of the irc signal crash patch and put a set of debs at 
http://plugwash.bircd.org/gaimirccrashfix/ for testing, can the reporters of 
this bug please test if my change fixes their problem.



06_irc-signal-crash.patch
Description: Binary data

Bug#405639: just to let you know

[peter green]

i think i've caught wind of a real-life case of this breaking the installtion 
of a gui from the installer (the guy didn't give very many details but from the 
symptoms he reports it sure sounds like it) 

his post can be found at http://forums.debian.net/viewtopic.php?t=11221.

Bug#405639:

[peter green]

What is wrong with both having the -all packages in reccomends on thier own (so 
that reccomends using package managers always pull them in on sarge-etch 
upgrades) AND also having them as an alternative in depends so that they get 
pulled in by new installs made using package management tools that don't 
understand reccomends.

that is i understand why the reccomends were changed to fix the other bug but 
not why the depends were changed at the same time.

Bug#400621: you might like to note

[peter green]

that the bug that is marked as blocking this one has now been resolved.

Bug#406554: woody contents files missing from archive.debian.org

[peter green]

package:ftp.debian.org

the contents files for woody seem to be missing from archive.debian.org 

Bug#405549: installation-reports: Also ATI Rage

[peter green]

> My ATI Rage was also not configured after install -- gdm fails and X 
> reports no devices.  Missing input and video drivers.  ATI device is 
> configured as "agp".  The desktop package doesn't seems to install the 
> correct driver or detect it I guess.  Easy fix -- I added the video and 
> input tasks and ran dpkg-reconfigure xserver-xorg.  xorg.conf was 
> correctly configured at this point though I had to specifically choose 
> the "ati" driver.
its a known issue with the xserver-xorg package. It has already been fixed in 
unstable and the fix should hit testing in a couple of days.

Bug#406399: installation-report: Dell Inspiron 6400: X server configuration problems

[peter green]

> The initial debootstrap doesn't have download speed reported, but then,
> it's only a few dozen megabytes download.
thats a pretty long wait for a dialup, isdn bri or very low end "broadband" 
user.

Bug#399670:

[Peter Green]

any chance of an english translation of those error messages?


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

Bug#399670: ok found the issue, fixed preinst script is attatched.

[peter green]

tags 399670 patch
thanks

ok i've done some more investigation

the problem appears to be caused by there being something in 
/etc/firefox/profile that wasn't put there by dpkg and so doesn't
get removed by dpkg. The result of this is that dpkg purges the 
files it installed but leaves the directories in place.

it then seems that the firefox->iceweasel migration code spots 
the directories and tries to migrate your configuration. However it
then fails to rename files that don't exist in the copied config

based on that investigation work i started looking for the source 
of the problem, i found the migration code in the preinst script
and have modified it to check files actually exist before renaming
them, this should solve the problem (i have not tested the fix because
iceweasel fails to build on my box, probablly due to a lack of memory).


steps to reproduce (some steps may not actually be needed but this sequence 
seems to work)

1: make sure apt-utils is installed (i only mention this because i installed it 
while trying to reproduce, no idea if its actually needed or not)
2: remove and purge any existing firefox or iceweasel packages
3: apt-get install libgconf2-4 libgnome2-0 libgnomeui-0 libgnomevfs2-0
4: rm -rf /usr/lib/firefox /usr/lib/iceweasel /etc/firefox /etc/iceweasel

5: dpkg -i firefox_1.5.dfsg+1.5.0.7-2_i386.deb 
firefox-gnome-support_1.5.dfsg+1.5.0.7-2_i386.deb
6: touch /etc/firefox/profile/dummy
7: apt-get install iceweasel iceweasel-gnome-support firefox-gnome-support- 
firefox- --purge

below is a log in english :)

debian:/# dpkg -i firefox_1.5.dfsg+1.5.0.7-2_i386.deb 
firefox-gnome-support_1.5.dfsg+1.5.0.7-2_i386.deb
Selecting previously deselected package firefox.
(Reading database ... 21057 files and directories currently installed.)
Unpacking firefox (from firefox_1.5.dfsg+1.5.0.7-2_i386.deb) ...
Selecting previously deselected package firefox-gnome-support.
Unpacking firefox-gnome-support (from 
firefox-gnome-support_1.5.dfsg+1.5.0.7-2_i386.deb) ...
Setting up firefox (1.5.dfsg+1.5.0.7-2) ...
Please restart any running Firefoxes, or you will experience problems.

Setting up firefox-gnome-support (1.5.dfsg+1.5.0.7-2) ...

debian:/# touch /etc/firefox/profile/dummy
debian:/# apt-get install iceweasel iceweasel-gnome-support 
firefox-gnome-support- firefox- --purge
Reading package lists... Done
Building dependency tree... Done
Suggested packages:
  latex-xft-fonts xprint mozplugger
The following packages will be REMOVED
  firefox* firefox-gnome-support*
The following NEW packages will be installed
  iceweasel iceweasel-gnome-support
0 upgraded, 2 newly installed, 2 to remove and 0 not upgraded.
Need to get 0B/9010kB of archives.
After unpacking 2892kB of additional disk space will be used.
Do you want to continue [Y/n]?
(Reading database ... 22351 files and directories currently installed.)
Removing firefox-gnome-support ...
Removing firefox ...
Purging configuration files for firefox ...
dpkg - warning: while removing firefox, directory `/etc/firefox/profile' not 
empty so not removed.
dpkg - warning: while removing firefox, directory `/etc/firefox' not empty so 
not removed.
Selecting previously deselected package iceweasel.
(Reading database ... 21057 files and directories currently installed.)
Unpacking iceweasel (from .../iceweasel_2.0+dfsg-1_i386.deb) ...
mv: cannot stat `/etc/iceweasel/firefoxrc': No such file or directory
dpkg: error processing /var/cache/apt/archives/iceweasel_2.0+dfsg-1_i386.deb 
(--unpack):
 subprocess pre-installation script returned error exit status 1
Selecting previously deselected package iceweasel-gnome-support.
Unpacking iceweasel-gnome-support (from 
.../iceweasel-gnome-support_2.0+dfsg-1_i386.deb) ...
Errors were encountered while processing:
 /var/cache/apt/archives/iceweasel_2.0+dfsg-1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
debian:/#


iceweasel.preinst
Description: Binary data

Bug#400052: another dupelicate

[peter green]

severity 400052 grave
reassign 400052 gaim-autoprofile
merge 400052 394773

thanks


Debian Bug report logs source autoprofile.URL
Description: Binary data

Bug#397788: for the benifit of the testing scripts

[peter green]

found 397788 1:2.0.0+beta5-1
Thanks

the testing scripts seem to think this is not in beta5-1, hopefully this 
message will fix that problem.




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

Bug#395911: error mounting/creating filesystems windowswindow~1.log is 92k, but it has 41 clusters (164k)

[peter green]

> windowswindow~1.log is 92k, but it has 41 clusters (164k)
>
> ERROR !!!
>
> Ignore
> Cancel
>
> dmesg -c on second console didnt showed anything relevant, only
> information that swap was mounted/added.
>
> Perhaps the fat system there was damaged before and debian tried to
> mount it? But if so then this windows-fault, not-our-business error
> probably should be displayed in more "OMG, we failed, The Drama!" way
> not to scare newbies?
>
> After ignoring it there was another error,
>
> FIle system is reporting the freee space as 409170 clusters, not 409199
> clusters.
it sounds to me like the installer was running a filesystem check on the
parition and found a couple of minor issues, thats nothing unusual with fat.



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

Bug#394773: this sounds like an ideal candidate for a nmu

[peter green]

retitle 394773 minor change needed for compatibility with gaim2.0.0beta4
thanks

this sounds like an ideal candidate for a nmu, i've changed that title as it 
misleadingly implied that a binnmu would have fixed this.

Bug#396612: please loosen up dependency on gaim-data

[peter green]

package:gaim
severity:normal

right now gaim and gaim-dev use a == dependency on gaim-data. 

because gaim and gaim-dev are arch any while gaim-data is arch all when a new 
version of gaim is uploaded gaim becomes temporally uninstallable on most 
architectures. This causes a LOT of buildd failures for packages that depend on 
gaim.

is there any particular reason this needs to be an == dependency rather than 
just a >= ? all gaim-data seems to contain is a load of translations are theese 
highly version sensitive? 

Bug#394773: beta5 now in unstable

[peter green]

retitle 394773 support for the gaim 2.0.0beta5 required.
thanks

just to let you know that what is now needed is beta5 support, since 
beta5 has replaced beta4 in sid.



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

Bug#260420: libsilc has now been repackaged

[peter green]

and it seems the guy who did it this time understands that libraries have 
versions.

Bug#399791: about box still uses the term firefox

[peter green]

package: iceweasel
severity: important

the about box still prominantly shows the firefox name under the globe

also does the stuff about the firefox trademarks still need to be there now 
firefox has been rebranded?

Bug#399795: first run takes me to a mozilla page with bad instructions

[peter green]

Package: iceweasel
Severity: minor

when i first ran iceweasel in a sid chroot that had never run firefox before i 
got taken to http://en-us.www.mozilla.org/en-US/firefox/2.0/firstrun.

this page told me to close the tab to get my homepage but no tab bar was 
visible.

also the page prominently mentions the firefox name and even has the official 
logo with the fox, hardly consistant with the rebranding.

Bug#410224: give the user the ability to answer conffile prompts during installation

[peter green]

package:debian-installer
severity:wishlist

conffile prompts should not happen during installation (unless of course the 
admin uses a vt to edit files manually), but sometimes they do due to bugs in 
packages or other issues. 

just freezing with the conffile prompt on another vt and worse no way to answer 
it is not good behaviour when they do.

Bug#410218: etch RC1 release installation

[peter green]

> -Original Message-
> From: Wojciech Zareba [mailto:[EMAIL PROTECTED]
> Sent: 08 February 2007 16:28
> To: [EMAIL PROTECTED]
> Subject: Bug#410218: etch RC1 release installation
> 
> 
> Package: installation-reports
> 
> Boot method: CD netinst default install
> Image version: 
> http://cdimage.debian.org/cdimage/etch_di_rc1/i386/iso-cd/debian-t
esting-i386-netinst.iso
> Date: 2007-02-08 16:30 CET
> 
> Machine: PC based on Gigabyte GA-8PE800 Pro matherboard (chipset 845PE)
> Processor: Pentium 4 (2.2 GHz)
> Memory: 512 MB
> Partitions: default partitioning (all on one) with LVM - disk 120 GB
> 
> Output of lspci -nn and lspci -vnn: I can't do it due to fatal errors 
> during installation
> 
> 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]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Install tasks:  [E]
> Install boot loader:[ ]
> Overall install:[ ]
> 
> Comments/Problems:
> Main error:
> System has hung during installing additional packages. I couldn't 
> install grub becouse of it.
did you configure the network manually?

if so you are probablly hitting a known bug, the easiest workaround for this 
known bug is to skip installing packages and install the software you want 
manually after installation. 

Bug#410218: etch RC1 release installation

[peter green]

> -Original Message-
> From: Frans Pop [mailto:[EMAIL PROTECTED]
> Sent: 08 February 2007 18:00
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Bug#410218: etch RC1 release installation
> 
> 
> On Thursday 08 February 2007 18:21, peter green wrote:
> > if so you are probablly hitting a known bug,
> 
> No, that is not possible. That issue has been fixed.
sorry i must have missed its migration to testing, 
> 
> > the easiest workaround for 
> > this known bug is to skip installing packages and install the software
> > you want manually after installation.
> 
> Working around the issue won't fix it for others. What we actually need 
> here is to know what package is causing the problem in this case.
> 
> Could you try to reproduce the problem and send us the syslog (gzipped!) 
> for the installation.
> If you have another computer connected to the system the easiest 
> way is to 
> use the "Save debug logs" option in the main menu of the installer after 
> configuring the network, but before the package installation is started.
might also be an idea to look if there is anything of interest on the log vt 
(alt-f3) at the time of the hang

Bug#410419: confile prompts should use debconf

[peter green]

package:dpkg

in situations where a user cannot interact directly with dpkg (debian-installer 
is one example of this though conffile prompts shouldn't normally happen there) 
conffile prompts currently result in a hung installation process, this is not a 
good thing.

since debconf seems to be the preffered method of communicating with the user 
and already has mechanisms in place to allow for situations like D-I and for 
completely non-interactive installs it would seem more sensible to use it.

Bug#410721: migration from xfree 4.3.0.dfsg.1-14sarge2 to xorg 1:7.1.0-11 failed to correctly configure swiss german keyboard

[peter green]

i think i may have a similar issue on a box that has been tracking etch for a 
while with a british keyboard and developed the "can't switch out of x with the 
"CTRL-ALT-Fx" keys sometime while tracking etch (i don't recall exactly when).

i mention this because it means the issue of keyboard layout configuration 
changing with the result of broken vt switching out of X does not just affect 
swiss german keyboards but some others as well.

the section for the keyboard

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "CoreKeyboard"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc105"
Option  "XkbLayout" "uk"
EndSection

a recent etch install with a british keyboard which does not suffer this 
problem has gb instead of uk (i can't test if changing it on the first install 
fixes it right now due to lack of physical access)

Bug#412916: [EMAIL PROTECTED]

[peter green]

> I want to install the distribution debian for ia64 and when i 
> restart de the PC with the "bootable" installation CD inside it 
> does not work, the pc read from CD but the installation doesn't 
> start. What can i do?. With the distribution for i386 it works perfectly. 
The core 2 duo is not an ia64 processor. It is em64-t which is intels clone of 
amd64, therefore you should be using the amd64 version of debian.

Bug#412982: installation-reports: Enabling 'sudo' in installer skips setting root password and breaks desktop root tasks

[peter green]

reopen 412982
reassign 412982 gnome
thanks

> The Gnome date/time applet asks for the root password. The user
> password doesn't work.
this sounds like a gnome bug then, it really should be able to handle the case 
with the root account disabled but sudo availible.

Bug#413248: installation-reports: (etch) strangeness with non-ASCII-character filenames on vfat partition

[peter green]

> It could also be that there really is an issue with the display of VFAT 
> filenames if UTF-8 is used, but that would not be my first guess.
> Anyway, I doubt this would be an installer issue as there is no real way 
> for the installer to determine the correct settings.
VFAT stores filenames in UTF-16, the driver has to convert this to something 
byte-orientated for processes/users to see.

i suspect the problem is that the driver is still defaulting to converting to a 
legacy encoding while the user interface is now UTF-8

can you try adding iocharset=UTF-8 to the mount options for the partitions and 
telling us if that makes stuff behave as you expect?

if so then imo this option should be set by the installer when generating fstab 
as afaict newly installed debian systems are completely utf-8 based nowadays.

Bug#413281: x11-common: sarge to etch upgrade fails

[peter green]

> Thanks, I'll add a conflict on hamsoft.
> Do you have any idea where hanterm comes from?
after doing some initial research and some quick tests in a sarge chroot it 
seems to be a symlink into /etc/alternatives that is created when either 
hanterm-classic or hanterm-xf is installed and removed when both of them are 
removed.

Bug#413248: success with 'utf8' vfat mount option

[peter green]

> AFAICT this option is relevant not only for vfat, but also for ntfs and 
> iso9660, but _not_ for fat16.
afaict it is not relavent for partitions mounted as dos (no long filenames) but 
it *is* relavent for fat12 and fat16 partitions mounted as vfat and using long 
filenames.

Bug#413574: jigdo really needs to be completed

[peter green]

package:jigdo
severity:important

currently there is no decent method for downloading cd images other than 
http/ftp. jigdo-lite is virtually unusable (no indication of progress or if its 
resuming or restarting etc). Bittorrent is only usable on some networks (often 
throttled or banned) and only for the most common images.

Bug#389881: RC-ness of this bug

[peter green]

> > > I urge you to reconsider severity of this problem.  There's 
> another situation
> > > that makes it much worse:
> > The correct solution is to make d-i use labels in fstab and to find the
> > root file system. udev has not much to do with this.
> 
> Which will enable a whole lot of other broken setups. Even uuids would be
> better to use, though I'm not sure all filesystem types expose one (ditto
> for labels, actually).
isn't udev supposed to provide persistant device naming avoiding this problem?

Bug#389881: RC-ness of this bug

[peter green]

> -Original Message-
> From: Marco d'Itri [mailto:[EMAIL PROTECTED]
> Sent: 07 March 2007 11:05
> To: Robert Millan [ackstorm]
> Cc: Mike Hommey; [EMAIL PROTECTED]; debian-release@lists.debian.org
> Subject: Bug#389881: RC-ness of this bug
> 
> 
> On Mar 07, "Robert Millan [ackstorm]" <[EMAIL PROTECTED]> wrote:
> 
> > Labels are not well tested and a source of problems indeed.
> The /dev/disk/by-*/ devices are well tested and I do not know about
> problems posed by them.
but if we are going to use those which set should we use?

by-path seems like a reasonable choice though it will break if users move 
anything (but then so would the old system in many cases)

by-id seems to use the make/model of the drive and maybe some unique id of the 
drive, 

by-uuid contains my two ext3 partitions but not my swap partition, it also 
seems like it may be vulnerable to becoming confused.

maybe an answer would be to use by-path if drives are presenent on multiple 
controllers during installation and use conventional names otherwise (possiblly 
with a way to override this behaviour for experts).

Bug#389881: RC-ness of this bug

[peter green]

> > by-uuid contains my two ext3 partitions but not my swap 
> partition, it also seems like it may be vulnerable to becoming confused.
> 
> Only if the admin is a moron and keeps around multiple file systems
> cloned with dd.
are you calling it moronic to make a backup of a partition by dding to to a 
spare one? since this was a perfectly workable system of backup under the 
conventional way of doing things i'd call that pretty unexpected breakage.

the fact it doesn't seem to work for all partition types would seem to rule it 
out anyway.

Bug#389881: RC-ness of this bug

[peter green]

> I don't know how invasive those changes might be. AFAIK Ubuntu already
> does it (Colin?) and wouldn't be too hard to pick the changes from
> them but we would also need RM and Frans approval :(
ubuntu already does what? there are four possible soloutions proposed aren't 
there (labels in fstab and the 3 different /dev/by-* trees)

Bug#413574: jigdo really needs to be completed

[peter green]

i'm not going to fight over the severity since but 
http://www.debian.org/Bugs/Developer#severities says

important 
a bug which has a major effect on the usability of a package, without rendering 
it completely unusable to everyone.

i'd say this bug fits that definition, the main binary is incapable of 
performing its main function and the jigdo-file/jigdo-lite workaround while ok 
for those with very fast stable connections (or a local mirror) who have no 
need to keep tabs on progress etc is basically unusable for the rest of us. 

unfortunately c++ is not a language i'm familiar with or i'd offer to help.

maybe you should tag this bug help so that those looking for packages that need 
working on find it.

Bug#389881: RC-ness of this bug

[peter green]

> I don't believe this should be changed for etch at this point in 
> the release
> process, and that's speaking as someone who's run into this problem myself
> with SCSI device renumbering -- it's awkward and annoying to have to
> manually fiddle your boot config because a USB device is no longer
> registering as /dev/sda, and it's not in line with the quality of 
> experience
> that our users have come to expect when installing Debian >:), but I don't
> think that makes anything unreleasable.  Changing the fstab 
> handling at this
> point could break many other scenarios that we haven't thought of 
> and tested
> for, whereas the USB issue can be documented in the errata.
what about writing out a /etc/fstab.by-id file with the header below 
followed by a copy of thier normal fstab changed to use the 
/dev/disk/by-id/ syntax? that way we could instruct newbies who run 
into this problem to just boot in rescue mode and run 
"cp /etc/fstab.by-id /etc/fstab". that seems to be much simpler to
explain to people than a manual fixup whilst not risking breakage 
for anyone who doesn't run into the device rearangement problem.

header for /etc/fstab.by-id

# /etc/fstab.by-id
#
# This file was generated by the debian installer. It represents the same 
# partition structure as the /etc/fstab that the installer generated but 
# references disks by thier "id" rather than by thier traditional unix names
# which are prone to change on first boot after installation or on changing 
# hardware. 
#
# This structure is not used by default for etch installations (but probablly 
# will be for lenny) because of the possibility of regressions from such a 
# major change late in the release process. If you wish to use it and have not
# modified /etc/fstab after installation you may copy this file to "/etc/fstab"
#

Bug#389881: RC-ness of this bug

[peter green]

> UUIDs certainly have their disadvantages (verbosity being the main one),
> but they're a hell of a lot better than labels for automatic use like
> this. UUIDs are suitable for automatic generation while labels should
> only be set by the sysadmin. The fiasco with Red Hat's installer setting
> labels which can then end up conflicting with itself if you do multiple
> parallel installs should demonstrate this (and some of the people
> involved in Anaconda development said to me in person that in hindsight
> this was probably a mistake). We've already backed away from automatic
> use of labels once (http://bugs.debian.org/310754) so let's not have to
> do so again!
i'd still be happier with hardware IDs or paths than partition UUIDs, UUIDs 
seem very prone to things breaking on filesystem or disk cloning which is not 
something a *nix admin would expect to break stuff (unlike changing hardware)

Bug#415646: sarge > etch dist-upgrade fails, x11-common fails overwrite /usr/X11R6/bin

[peter green]

> -Original Message-
> From: Scott Raun [mailto:[EMAIL PROTECTED]
> Sent: 21 March 2007 21:11
> To: [EMAIL PROTECTED]
> Subject: Bug#415646: sarge > etch dist-upgrade fails, x11-common fails
> overwrite /usr/X11R6/bin
> 
> 
> On Wed, Mar 21, 2007 at 03:54:21PM -0400, Aaron M. Ucko wrote:
> > Scott Raun <[EMAIL PROTECTED]> writes:
> > 
> > > dpkg: error processing 
> > > /var/cache/apt/archives/xcursor-themes_1.0.1-5_all.deb (--unpack):
> > >  trying to overwrite `/etc/X11/cursors/core.theme', which is also in 
> > > package xlibs-data
> > 
> > Running
> > 
> > dpkg -i --force-overwrite 
> /var/cache/apt/archives/xcursor-themes_1.0.1-5_all.deb
> > 
> > should let
> > 
> > apt-get -f install
> > 
> > continue (though xcursor-themes already declares appropriate versioned
> > Conflicts: and Replaces:, so that theoretically shouldn't have been
> > necessary).
> 
> It did.  Ran for a while, then gave an error about capplets-data, which 
> I decide meant it was damaged - I deleted it, restarted the apt-get -f 
> install, and it ran for quite a while longer.
> 
> Now I'm at:
> 
> updmap-sys failed. Output has been stored in:
>   /tmp/tetex.updmap.tTOp7688
> Please include this file if you report a bug.
> dpkg: error processing tetex-bin (--configure):
>  subprocess post-installation script returned error exit status 1
> emacs-install emacs21
> install/dictionaries-common: Byte-compiling for emacsen flavour emacs21
> emacs21: error while loading shared libraries: libXaw3d.so.6: cannot 
> open shared object file: No such file or directory
> install/emacs-goodies-el: Handling emacs21, logged in 
> /tmp/elc_YSzzao.log
> emacs-install: /usr/lib/emacsen-common/packages/install/emacs-goodies-el 
> emacs21 failed at /usr/lib/emacsen-common/emacs-install line 28,  
> line 4.
> dpkg: error processing emacs21 (--configure):
>  subprocess post-installation script returned error exit status 127
> dpkg: dependency problems prevent configuration of tetex-extra:
>  tetex-extra depends on tetex-bin (>= 2.99); however:
>   Package tetex-bin is not configured yet.
> dpkg: error processing tetex-extra (--configure):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  emacs21
>  tetex-bin
>  tetex-extra

you could try purging the problem packages and anything that depends on them 
then reinstalling those packages.

Bug#390369: -o is not one option

[peter green]

it is a series of options

from ssmtps "sendmail" manpage

   Most sendmail options are irrelevent to sSMTP. Those marked ``ignored''
   or ``default'' have no effect on mail transfer.  Those marked  ``unsup-
   ported''  are fatal errors.  Those marked ``simulated'' are not errors,
   but the result is for the program to exit with an informative  message.
   A sort of fatal non-error.
.
   -oAfile
  (ignored) Use alternate alias file.

   -oc(ignored) Delay ``expensive'' connections.

   -od(ignored)  Set  the  delivery  mode  to interactive/synchronous,
  background or queue (Always interactive).

   -oD(ignored) Run newaliases if required.

   -oe(ignored) Set error processing to mail, write,  print  or  quit.
  (Always print).

   -oFmode
  (ignored) The mode to use when creating temporary files.

   -of(ignored)  Save UNIX-system-style ``From'' lines at the front of
  messages.

   -ogN   (ignored) Set group ID to use when calling mailers.

   -oHfile
  (ignored) Set SMTP help file.

   -oi(default) Do not take dots on a line by themselves as a  message
  terminator.

   -oLn   (ignored) The log level.

   -om(default) Send to ``me'' (the sender) also if in an alias.

   -oo(unsupported) If set, this message may have old style headers.

   -oQqueuedir
  (ignored) Select the directory in which to queue messages.

   -ortimeout
  (ignored) The timeout on reads.

   -oSfile
  (ignored) Save statistics in the named file.

   -os(ignored) Always instantiate the queue.

   -oTtime
  (ignored) Set timeout on messages.

   -otstz,dtz
  (ignored) Set the name of the time zone.

someone familiar with getopt will be required to provide a patch for nbsmtp 
that provides similar functionality.
-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.17/730 - Release Date: 22/03/2007 
07:44

Bug#416115: pitfal: no mention of /etc/modules

[peter green]

> There is no mention of updating /etc/modules.  Without a network driver,
> or something else equally critical, you may find your remote dedicated
> box happily running while noone can ssh into it.
afaict nowadays /etc/modules isn't really nessacery anymore and can even cause 
upgrade problems. If udev detected a device during installation and loaded the 
module it should also detect it in the running system.
-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.17/731 - Release Date: 23/03/2007 
15:27

Bug#415989: Debootstrap Warning : [...]/packages.gz was corrupt

[peter green]

> > PS: Is there a way to fix memory hardware issues ?

if you can get the system working well enough to install and compile stuff (say 
by pulling out some of the memory) you can build a custom kernel with the 
badram patches. Then put the bad memory back in, run a memory test and use the 
addresses to confiure badram.


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.17/732 - Release Date: 24/03/2007 
16:36

Bug#415379: fixed in testing but what about unstable

[peter green]

this bug has been fixed in testing through a TPU upload but there doesn't seem 
to be any information on if it is still present in unstable.
-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.18/733 - Release Date: 25/03/2007 
11:07

Bug#414944:

[peter green]

notfound 414944 0.2.3-4
found 414944 0.1.20

sorry seems i messed up on the version in this bug
-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.20/733 - Release Date: 27/03/2007 
00:00

Bug#416788: add a sneakernet source type

[peter green]

package: apt
severity: wishlist

Installing packages on machines with no internet connection currently is a 
pain. CDs are a partial soloution but only for official free packages and only 
for users of stable/testing not of unstable.

my proposal is to add a sneakernet source type. With this source type apt will 
give the user a list of files to retrive as a file, this list can then be 
transferred to a machine that does have net access (using removable media) and 
retrived by a simple program. The files can then be transferred back to the 
debian box (once again using removable media) where apt can then use them as if 
it had retrived them directly over the net.


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.22/739 - Release Date: 29/03/2007 
13:36

Bug#416944: dist-upgrade stuck

[peter green]

> -Original Message-
> From: Lou Poppler [mailto:[EMAIL PROTECTED]
> Sent: 31 March 2007 17:58
> To: [EMAIL PROTECTED]
> Subject: Bug#416944: dist-upgrade stuck
> 
> 
> Package: installation-reports
> 
> Trying to upgrade from sarge to etch, not doing well.
> I net-installed sarge a couple weeks ago, and got it working mostly well,
> with gdm X desktop and kernel 2.6.8.  I was having some minor ethernet
> driver problems which googling suggested might be fixed by a newer kernel.
> 
> I was encouraged by the reports of successful dist-upgrades to etch,
> so I went through the "Method C" process.  I am now running etch on
> this machine, with kernel 2.6.18-4-686, but many things seem to no
> longer be installed -- notably the X desktop (and I just noticed also
> no ssh).  I found that X wasn't starting because gdm was not installed,
> so I [re-]installed gdm from aptitude.  This got me into X, but after
> I login to gdm I get only a little shell window, probably an xterm.
> 
> I stopped gdm, and last night started: tasksel install desktop
> It started downloading, and I went to bed with it showing 1hr30min
> more download time.  When I came back to the machine after my nap,
> I find it stuck in tasksel.  The screen shows "Package configuration"
> on the very top line, and a text box in the middle saying:
> "Installing packages \  Installed libdiscover1  "
> and a status bar stuck at 75%.
if the seperate tasksel is anything like that in d-i i bet its getting stuck on 
a conffile prompt or something.

i'd suggest you install a desktop with apt-get install gnome-core and then just 
install what you want from there.


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.23/740 - Release Date: 30/03/2007 
13:15

Bug#380552: a possible medium term soloution

[peter green]

would it be possible to reduce the test to only cause a warning until it is 
worked out what about the build environment is causing the false positive?

Bug#48152: installer packages

[peter green]

reopen 48152
thanks

there seems to be a general issue with "installer packages" like 
flashplugin-nonfree and msttcorefonts, such packages don't contain any non-free 
software in the package itself (and hence are placed in contrib) but installing 
them causes non-free software to be installed on to the system from a source 
other than debian.

imho vrms should probablly flag up contrib packages as well, they represent a 
dependency of some form on non-free software even though they don't actually 
contain it.

better still would be for vrms to add detection methods other than searching 
the debian package database (since that is after all not the only way to 
install stuff on a debian system, especially stuff like mozilla plugins)

Bug#411552: please set a timeout in syslinux screen

[peter green]

> That is obviously a problem, but so is d-i booting unexpectedly.
D-I doesn't touch anything until told to does it?

i don't really see how unexpectedly ending up at the first screen of the 
installer is any worse than unexpectedly ending up at the syslinux boot prompt, 
either way you just remove the CD and reboot.

Bug#411552: please set a timeout in syslinux screen

[peter green]

> -Original Message-
> From: Joey Hess [mailto:[EMAIL PROTECTED]
> Sent: 20 February 2007 08:36
> To: Robert Millan; [EMAIL PROTECTED]
> Subject: Bug#411552: please set a timeout in syslinux screen
> 
> 
> Here are some scenarios to consider:
> 
> * Suppose that I'm blind. I put in the CD, reboot, and wait the 5
>   minutes I generally wait to get it past post[1]. Then I carefully start
>   typing the necessary kernel options for my braille reader into the
>   syslinux prompt I expect to be there...
> 
>   Even once I learn about the timeout, installing Debian is going to
>   suck a lot more than before for me.
As long as the timeout is much longer than normal POST times and the countdown 
stops as soon as a key is pressed (so slow typing is fine as long as the first 
key is pressed quickly i don't see this being a huge issue.

> 
> * Suppose that the machine is being booted by a rack monkey at the data
>   center. If it's set up like my data center, this means they put the CD
>   in the front of the rack, power on the machine, then run 200 feet
>   around to the back of the rack -- only to find that the crash cart
>   with the display isn't hooked up to the right machine. So they switch
>   it to the right one. Meanwhile, I want them to boot with "auto=true" to
>   avoid walking them through the whole install over the phone, and am
>   subsequently quite confused when I tell them to type that, and they
>   say that it replies with "Elektu landon, teritorion au aeron" and some
>   other strange words.
> 
>   Can you figure out what happened based on the above description? :-)
>   Could you figure it out over the phone? While being charged $x/minute
>   for a call from Europe to the US?
this is a legit one but its a pretty special use case imo

> 
> * My grandnephew Kai Runyon[2] is here visiting. He's 2, and he likes to
>   pound on keyboards and flip switches. He finds my power switch. Then he
>   finds my keyboard. I come out of a programming haze to find my media
>   server formatting its home directory thanks to the d-i CD I just had
>   it burn.
> 
>   Ok, granted, the timeout only saved him one well-placed enter, but
>   it's not unheard of for my home network to have preseed setups enabled
>   that let this whole scenario happen with only a few keystrokes.
otoh you could stretch that case to say that using the installer should require 
sufficiant arcane commands that a child can't cause trouble with it, i don't 
think that is a road we should go down. 

> 
> * My kiosk machine only has a user-accessible touchscreen, the keyboard
>   is locked away to avoid all those easily implantable keylogger chips,
>   and other problems. I leave an installation CD in it so that it can be
>   quickly reinstalled if something goes wrong, or weekly (just in case).
>   One day I decide to switch it to this new version of the lenny CD,
>   which happens to be the one where g-i becomes the default installer.
>   This also happens to be the one that a tricky user of the kiosk uses to
>   intercept a lot of credit card numbers, after running through the whole
>   g-i install using only the keypad, to get root.
but if you are leaving the CD in and you want the machine to be usable then you 
are going to have had to disable CD booting anyway.

Bug#412249: please install resolvconf by default

[peter green]

> Unfortunately, adding good DNS via network-admin doesn't archieve the same
> effect, because dhclient will overwrite /etc/resolv.conf whenever 
> it's run
the most obvious question would be why doesn't network-admin know this and do 
something about it?

>,
> which is going to be quite often if you happen to run 
> network-manager (also
> enabled by default).  This means Joe had to reload his DNS every 
> 10 minutes
> untill his friend Robert could debug the problem and figure out 
> that resolvconf
> was needed.
what exactly does resolvconf do? does installing it alter the behaviour of the 
dhcp client or will they just fight over resolv.conf?

Bug#412249: please install resolvconf by default

[peter green]

> As to what network-admin can do, it could easily alter the order (run
> dhclient first, then modify resolv.conf), but that would only archieve
> temporary unfuckage (i.e., same situation as if resolvconf was installed).
can't it just reconfigure dhclient not to touch dns (i presume dhclient has an 
option for this, if not then it should do) when the user specifies that they 
want to set it manually?

Bug#412249: please install resolvconf by default

[peter green]

> -Original Message-
> From: Robert Millan [mailto:[EMAIL PROTECTED]
> Sent: 25 February 2007 00:57
> To: peter green
> Cc: [EMAIL PROTECTED]
> Subject: Re: Bug#412249: please install resolvconf by default
> 
> 
> On Sun, Feb 25, 2007 at 12:30:36AM -, peter green wrote:
> > 
> > > As to what network-admin can do, it could easily alter the order (run
> > > dhclient first, then modify resolv.conf), but that would only archieve
> > > temporary unfuckage (i.e., same situation as if resolvconf 
> was installed).
> > can't it just reconfigure dhclient not to touch dns (i presume 
> dhclient has an option for this, if not then it should do) when 
> the user specifies that they want to set it manually?
> 
> No.  Check it out in /etc/dhclient-script.  We can change that, of course,
> but using the enter/exit hooks sounds easier.
if i get this right you are proposing letting dhclient write the file then 
immediately writing over it, that sounds like a dirty and confusing hack to me. 
Furthermore it will break any apps that happen to read resolv.conf (and 
possiblly cache it) between dhclient putting the wrong stuff in and your script 
replacing it with the right stuff.

Bug#412387: patch doesn't fix the real issue

[peter green]

the real issue is that there is no longer a /etc/init.d/inetd in debian, netkit 
has been removed and its two replacements use their own init script names, 
applying the patch would remove the errors but would just mean that inetd would 
not be restarted.

based on initial testing (i'd like a comment on this from someone who better 
understands bash though, if running them isn't safe then some more elaborate 
detection may be needed) it seems that when an inetd is removed but not purged 
it is safe to run its init script so the following code would be better.

if [ -x /etc/init.d/openbsd-inetd ]; then
invoke-rc.d openbsd-inetd restart
fi
if [ -x /etc/init.d/inetutils-inetd ]; then
invoke-rc.d inetutils-inetd restart
fi

Bug#336054: retitle per remaining part of the request

[peter green]

retitle 336054 add auto rejoin on kick support
thanks

since the confusing text has apparently been removed in 2.0 the only remaining 
part of this bug is a request to add an auto-rejoin on kick feature, retitling 
appropriately

Bug#413788: Daily Etch build fails to install on iMac G5 - Ethernet not detected

[peter green]

> -Original Message-
> From: Mike Hore [mailto:[EMAIL PROTECTED]
> Sent: 09 March 2007 01:40
> To: Frans Pop
> Cc: [EMAIL PROTECTED]
> Subject: Bug#413788: Daily Etch build fails to install on iMac G5 -
> Ethernet not detected
> 
> 
> Hi again Frans,
> 
> > On Thursday 08 March 2007 02:30, Mike Hore wrote:
> >> 0001:03:0f.0 Ethernet controller: Apple Computer Inc. Shasta (Sun GEM)
> >> [106b:0051]
> > According to this information, your NIC needs the sungem driver, which 
> > _is_ included in the installer and should be loaded automatically.
> > 
> > After the installer has failed to detect your NIC, please try the 
> > following:
> > - switch to VT2
> > - check if the sungem module is loaded ('lsmod | grep sungem')
> 
> No output.
> 
> > - if it is, check dmesg for any messages about the NIC
> 
> I didn't see any, but there were about 2 screenfuls of info and I didn't 
> know how to stop it scrolling off.
> 
> > - if it is not, try to load it manually ('modprobe sungem')
> 
> FATAL: module sungem not found
> 
> 
> So it really looks to me like it isn't there, sorry!
have you checked the md5sum against the one for the day your image is dated? 
(you can find older dailies by cutting back the image url to remove the current 
and everything before it and browsing manually from there)

i'm thinking this may be another case of a half and half download (half one 
days image half the next)

Bug#414172: xserver-xorg: on sarge-etch upgrade, fails produce usable xorg.conf

[peter green]

> -- System Information:
> Debian Release: 4.0
>   APT prefers testing
>   APT policy: (500, 'testing'), (200, 'unstable')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.18-4-686
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> 
> Versions of packages xserver-xorg depends on:
> ii  debconf [debconf-2.0]1.5.11  Debian configuration 
> management sy
> ii  x11-common   1:7.1.0-15  X Window System 
> (X.Org) infrastruc
> ii  xbase-clients1:7.1.ds1-2 miscellaneous X clients
> ii  xkb-data 0.9-4   X Keyboard Extension 
> (XKB) configu
> ii  xserver-xorg-core2:1.1.1-19  X.Org X server -- core server
> ii  xserver-xorg-input-all   1:7.1.0-15  the X.Org X server 
> -- input driver
> ii  xserver-xorg-input-evdev [xs 1:1.1.2-6   X.Org X server -- 
> evdev input driv
> ii  xserver-xorg-input-kbd [xser 1:1.1.0-4   X.Org X server -- 
> keyboard input d
> ii  xserver-xorg-input-mouse [xs 1:1.1.1-3   X.Org X server -- 
> mouse input driv
> ii  xserver-xorg-video-chips [xs 1:1.1.1-4   X.Org X server -- 
> Chips display dr
> ii  xserver-xorg-video-dummy [xs 1:0.2.0-3   X.Org X server -- 
> dummy display dr
> ii  xserver-xorg-video-fbdev [xs 1:0.3.1-1   X.Org X server -- 
> fbdev display dr
> ii  xserver-xorg-video-i810 [xse 2:1.7.2-4   X.Org X server -- 
> Intel i8xx, i9xx
> ii  xserver-xorg-video-v4l [xser 0.1.1-3 X.Org X server -- 
> Video 4 Linux di
> ii  xserver-xorg-video-vesa [xse 1:1.3.0-1   X.Org X server -- 
> VESA display dri
> ii  xserver-xorg-video-vga [xser 1:4.1.0-3   X.Org X server -- 
> VGA display driv
> 
> Versions of packages xserver-xorg recommends:
> ii  discover1 1.7.19 hardware 
> identification system
> ii  laptop-detect 0.12.1 attempt to detect a laptop
> pn  mdetect(no description available)
> pn  xresprobe  (no description available)
> ii  xserver-xorg-input-all1:7.1.0-15 the X.Org X server 
> -- input driver
> pn  xserver-xorg-video-all (no description available)
does this information relate to the boxes on which you had the problem and if 
so did you add or remove any packages after the upgrade? (i see no mention of 
mga in this list)

assuming you did some other stuff after the upgrade did the upgrade actually 
install the correct driver and how did you perform the upgrade?

Bug#407689: tasksel: Please consider adding a Development task for Etch

[peter green]

> I've added module-assistant to "forcd1". build-essential was already 
> included.
are the kernel headers for the standard debian kernels on CD1 as well? module 
assistant isn't going to be much use without those.

Bug#410047: marking as fixed in unstable per info from upstream bugtracker

[peter green]

close 410047 0.11-1

according to upstream 
(http://www.workplaceproxy.com/cgiproxy/nph-proxy.pl/010110A/http/trac.gajim.org/query?status=closed&milestone=0.11
 note, there are two bug reports mentioned in this thread but one appears to be 
a typo, 2038 seems to be the correct one) was fixed in version 0.11 and the 
original submitter essentially implied this was already fixed by a new upstream 
version and was just in need of a backport so mark it as closed by the new 
upstream version. 

Bug#286213: reopen 286213

[peter green]

> > Is the X process consuming lots of CPU when the freeze occur?
> 
> I don't know. I have no access to the system when X freezes.
can you setup sshd so you can login from another machine when the interface 
freezes?

Bug#404148: i'm not convinced release notes are enough

[Peter Green]

despite the best intentions of debian i am convinced that most users will
not read the release notes and over the lifetime of the etch release
having large ammounts (just how much is needed to trigger this bug btw) of
memory will become more and more common.

what does the sarge kernel do when placed on a machine like this? does it
use the hardware iommu? does it use the software one? does it not use one
at all (and hence lose some memory). In other words is the current
situation a regression from sarge?

what is the performance impact of using the safe option on all hardware
even that not affected by this bug? would using that option by default
result in a noticable performance degrdation?



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

Bug#414683: d-i RC2 installation report

[peter green]

> I am still not sure my failure was not due to a misconfigured 
> network/router but the D-Link DI-524 used usually works fine for me.
can you check if the default gateway is set and if there is something sane in 
resolv.conf within the installer environment?

failing that try starting the installer with the network cable unplugged, then 
select configure network manually when it prompts you, plug the cable in and 
set the network up.

Bug#389881: RC-ness of this bug

[peter green]

 
> Personally I also feel that all possible solutions effectively make
> /etc/fstab unreadable and unmaintainable. Maybe Debian should 
> lead the way 
> to make /etc/fstab a generated file (like e.g. modules.conf used to be).
what is so bad about /dev/disk/by-path/pci-:00:07.1-ide-0:0-part1 ?

it says exactly where the controller is on the PCI bus, which device it is on 
the controller and which partition it is. Someone seeing that pattern should 
easilly be able to add entries for other drives and partitions on the same 
controller and with a bit more work (e.g. reading lspci and/or looking through 
/dev/disk/by-path) for drives on other controllers.

sure its a little on the long side and you might want to change the spacing in 
fstab to reflect that but we have editors with copy and paste. A bit of extra 
verbosity in device names seems a small price to pay to get device names that 
are stable and reliable. The hd? system was very nice when most people just had 
a single ide controller with all their (sd? was alwats nasty afaict but few 
enough people had scsi that it didn't hit too many newbies) but times have 
moved on and it simply isn't possible to reliablly indentify drives with an 
identifier that short anymore. 

i don't see what generating fstab would gain. you are still going to have to 
have a configuration file that contains all the information about what to mount 
where including a method for identifying drives even accross addition of new 
hardware.

Bug#414944: libapt-pkg-perl and hence apt-file are uninstallable on a system that preffers experimental

[peter green]

Package: libapt-pkg-perl
Version: 0.2.3-4
Severity: important
Tags: experimental

debian:/# apt-get install apt-file
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  apt-file: Depends: libapt-pkg-perl but it is not going to be installed
E: Broken packages
debian:/#

debian:/# apt-get install apt-file libapt-pkg-perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  libapt-pkg-perl: Depends: libapt-pkg-libc6.3-6-3.11
E: Broken packages
debian:/#

debian:/# apt-get install apt-file libapt-pkg-perl libapt-pkg-libc6.3-6-3.11
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting apt instead of libapt-pkg-libc6.3-6-3.11
apt is already the newest version.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  libapt-pkg-perl: Depends: libapt-pkg-libc6.3-6-3.11
  E: Broken packages
  debian:/#

debian:/# apt-get install libapt-pkg-perl libapt-pkg-libc6.3-6-3.11
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting apt instead of libapt-pkg-libc6.3-6-3.11
apt is already the newest version.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  libapt-pkg-perl: Depends: libapt-pkg-libc6.3-6-3.11
  E: Broken packages
  debian:/#


-- System Information:
Debian Release: 4.0
  APT prefers experimental
  APT policy: (990, 'experimental'), (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-skas3-v9-pre9
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=locale: Cannot set LC_CTYPE to 
default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)

Bug#389881: RC-ness of this bug

[peter green]

> That it's not a persistent means of identifying a filesystem.  
for most users fstab has always identified by rough position (e.g. hda=ide 
primary master), changing to a system based on partition IDs would mean a lot 
of relearning for admins (e.g. its no longer ok to backup a partition by dding 
it to another one)

>It 
> changes if
> you move the PCI device
true, not that i imagine people do that much.

>, it changes if you change the SCSI/IDE bus address
> of the drive
the same applied in the old hd? and sd? days, drives names changing when you 
change thier IDE/SCSI ids is something admins expect and are used to.

, it changes if the kernel changes the name of the storage
> subsystem used to access the device (on kernel upgrades)
true, i wish they'd stop behaving like that.

>, it breaks down
> miserably if you use fiberchannel.
never used fiberchanel so can't comment on this.


to clarify my position on the overall issue

i agree that this is too late for etch (sadly) 
by-path and by-id each have some pros and cons over each other but both are far 
better than the old scheme now that multiple controllers and usb devices in sd? 
are becoming the norm.
by-uuid and uuid's in fstab (which seem to achive the same) is a very bad idea, 
it means that using dd to back up a partition to another one could result in 
the wrong one being mounted with potentially disasterous consequences. It could 
also be a severe security issue with the help of a carefully crafted usb stick 
(especially in an environment where deployment is done by imaging).
labels suffer from the problems given above for uuids
users installing on expert and possiblly medium should be given the choice 
between traditional names and the various new options.

Bug#408641: asks user to select disk to partition, even if there's only one disk

[peter green]

> Partman (guided partitioning) will still ask the user to select 
> which disk to
> partition, even if there's only one disk.
personally i think its better that it asks

consider the situation where a user has two drives but the one they want to use 
for debian is not detected.

then they select the use entire disk option.

Bug#380552: failed again on the same test

[peter green]

reopen 380552
thanks

looks like this is still an issue.
http://buildd.debian.org/fetch.cgi?pkg=coreutils;ver=5.97-5.3;arch=s390;stamp=1170189620
FAIL: pwd-long

Bug#409685: rebreak seems to have found its way from tpu to unstable

[peter green]

reopen 409685
thanks

seems that this was fixed in 1.0.9 but broken again by 1.0.10 which was 
intended for testing but somehow made it into unstable as well.





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

Bug#415030: now affects lenny too

[peter green]

tags 415030 -sid 
thanks

i get the same errors when building on lenny as were reported for 
building on sid



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

Bug#415034: now affects lenny too

[peter green]

tags 415034 -sid
thanks

debian:/# apt-get source -b chiark-utils
Reading package lists... Done
Building dependency tree... Done
Need to get 111kB of source archives.
Get:1 http://192.168.1.3 lenny/main chiark-utils 4.1.10 (dsc) [787B]
Get:2 http://192.168.1.3 lenny/main chiark-utils 4.1.10 (tar) [110kB]
Fetched 111kB in 5s (21.4kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = "en_GB:en_US:en_GB:en",
   LC_ALL = (unset),
   LANG = "en_GB"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
gpg: Signature made Mon Oct  2 21:26:30 2006 UTC using RSA key ID 23F5ADDB
gpg: Can't check signature: public key not found
dpkg-source: extracting chiark-utils in chiark-utils-4.1.10
dpkg-source: unpacking chiark-utils_4.1.10.tar.gz
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = "en_GB:en_US:en_GB:en",
   LC_ALL = (unset),
   LANG = "en_GB"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = "en_GB:en_US:en_GB:en",
   LC_ALL = (unset),
   LANG = "en_GB"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
dpkg-buildpackage: source package is chiark-utils
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = "en_GB:en_US:en_GB:en",
   LC_ALL = (unset),
   LANG = "en_GB"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = "en_GB:en_US:en_GB:en",
   LC_ALL = (unset),
   LANG = "en_GB"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
dpkg-buildpackage: source version is 4.1.10
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = "en_GB:en_US:en_GB:en",
   LC_ALL = (unset),
   LANG = "en_GB"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = "en_GB:en_US:en_GB:en",
   LC_ALL = (unset),
   LANG = "en_GB"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
dpkg-buildpackage: source changed by Ian Jackson 
<[EMAIL PROTECTED]>

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = "en_GB:en_US:en_GB:en",
   LC_ALL = (unset),
   LANG = "en_GB"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = "en_GB:en_US:en_GB:en",
   LC_ALL = (unset),
   LANG = "en_GB"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
dpkg-buildpackage: host architecture i386
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = "en_GB:en_US:en_GB:en",
   LC_ALL = (unset),
   LANG = "en_GB"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
dpkg-buildpackage: source version without epoch 4.1.10
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = "en_GB:en_US:en_GB:en",
   LC_ALL = (unset),
   LANG = "en_GB"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = "en_GB:en_US:en_GB:en",
   LC_ALL = (unset),
   LANG = "en_GB"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
   LANGUAGE = "en_GB:en_US:en_GB:en",
   LC_ALL = (unset),
   LANG = "en_GB"
   are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
debian/rules clean
test -f cprogs/writebuffer.c
rm -f build
set -e; for s in cprogs; do \
   /usr/bin/make -C $s -i distclean || \
   /usr/bin/make -C $s -f Makefile.in distclean; \
   done
make[1]: Entering directory `/chiark-utils-4.1.10/cprogs'
rm -f *~ ./#*# *.o
rm -f readbuffer writebuffer with-lock-ex xacpi-simple summer really 
trivsoundd

make[1]: Leaving directory `/chiark-utils-4.1.10/cprogs'

Bug#406816: also affects lenny

[peter green]

retitle 406816 libghc6-missingpy-dev: not 
installable (wants missingh-0.16, but missingh-0.18 is in lenny and sid)

tags 406816 -sid 
thanks

i have just confirmed this bug also happens with lenny


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

Bug#414715: now affects lenny

[peter green]

tags 414715 -sid
thanks

i just tried to build this in lenny and it fails with the same error


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

Bug#409488: now affects lenny too

[peter green]

tags 409488 -sid
thanks

i've just tested this in lenny and got the same error


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

Bug#419189: i'd suggest a check

[Peter Green]

it seems like it would be a good idea to check for non dpkg owned versions
of problem libraries sitting in that directory in the preinst and either
aborting the upgrade before the system is left in a badly broken state or
moving the files out of the way.


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

Bug#419211: d-i fails in fetching "Release.gpg" in netboot install of etch r0

[peter green]

> Of course, while this is the correct default behavior, it seems reasonable
> to me that we should allow users to override it with preseeding 
> or the like,
> so that's IMHO a valid wishlist request.
a related issue is if you have a cd not loaded through the CD mechanism for 
whatever reason and you have internet sources then even if you tell apt to 
allow unauthenticated it will always preffer the authenticated source, this is 
annoying if you have CD contents availible through a fast mechanism but a full 
mirror only accessible over a slowish internet link

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 269.4.0/762 - Release Date: 15/04/2007 16:22

Bug#390352: missing dependency on netbase

[peter green]

Package: ftp
Version: 0.17-12
Severity: important

netbase contains /etc/services which ftp needs to run but ftp doesn't depend
on it



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

Bug#391410: guifrications ftbfs on powerpc buildd because of problem installing gij

[peter green]

package: gij-4.1
severity: grave

the buildd log in question is at
http://buildd.debian.org/fetch.php?&pkg=guifications&ver=2.13%7Ebeta3-0.1&ar
ch=powerpc&stamp=1159970889&file=log&as=raw, the following is an extract
from that log

Setting up gij-4.1 (4.1.1-15) ...
gcj-dbtool-4.1: error while loading shared libraries: libgcj.so.70: cannot
open shared object file: No such file or directory
dpkg: error processing gij-4.1 (--configure):
 subprocess post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of ecj-bootstrap:
 ecj-bootstrap depends on gij-4.1 (>= 4.1.1-13); however:
  Package gij-4.1 is not configured yet.
dpkg: error processing ecj-bootstrap (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of ecj-bootstrap-gcj:
 ecj-bootstrap-gcj depends on ecj-bootstrap (>= 3.2.1-1); however:
  Package ecj-bootstrap is not configured yet.
dpkg: error processing ecj-bootstrap-gcj (--configure):
 dependency problems - leaving unconfigured
the line that appears to be the root of the problem is

gcj-dbtool-4.1: error while loading shared libraries: libgcj.so.70: cannot
open shared object file: No such file or directory
dpkg: error processing gij-4.1 (--configure):

this seems to indicate that gij-4.1's configure script is depending on
libgcj.so.70 but it hasn't been installed at that point for some reason.

i belive the soloution is to make gij-4.1 pre-depend on libgcj7-0



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

Bug#391410: guifrications ftbfs on powerpc buildd because of problem installing gij

[peter green]

> This one time, at band camp, peter green said:
> > i belive the soloution is to make gij-4.1 pre-depend on libgcj7-0
> Surely a simple Depends should do the trick?
according to http://packages.debian.org/unstable/devel/gij-4.1 a depends is
already there.

i thought pre-depends was needed to gaurantee that something would be
present for your configure run.




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

Bug#391244: this package is finished with

[peter green]

sametime support is now a built in feature of the main gaim package so this
package should be reduced to a dummy for ease of upgrading.





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

Bug#391242: patch for building on gaim

[peter green]

tags 391242 +patch
thanks.

making this build against 2.0.0beta3.1 in my sid chroot was pretty easy, i
just nicked some headers that are no longer in the official public interface
of gaim from the gaim source package (yes eliminating the dependance on non
public interfaces is a good move long term but i'm not enough of an expert
to do that), renamed them made some minor tweaks to use them and it built.

actually making the patch work with the build system was easier said than
done but now its done just add it to the debian/patches dir to use it.

i installed the package and gaim recognised it and gave me a rvp option in
the accounts dialog. I can't test beyond that because i don't have a
suitable server to use it with.


buildwithgaim2.0.patch
Description: Binary data

Bug#391244: removal from unstable

[peter green]

since my previous message i have been advised that because this package
already depended on gaim it should be removed from unstable rather than
converted into a dummy.

i've been told that such removal requests are made by submitting a bug on
the ftp.debian.org psudo package, if noone objects within a few days i will
do this for this package.



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