Bug#1064624: Hard to short-stroke an encrypted drive
On Mon, Feb 26, 2024 at 12:34:50AM +0100, Pascal Hambourg wrote: > Not if you do not write anything to them, or if you TRIM them. You can stop explaining to me how TRIM works. commit 0c659b82d11e Author: Matthew Wilcox Date: Thu Apr 2 10:37:25 2009 -0400 ata: Add TRIM infrastructure > You may either > - tell the installer not to erase (=write) the encrypted partition (if > guided partitioning prompts it, not sure) > or > - enable "discard" in /etc/crypttab (should be the default) > - create a logical volume in the free VG space > - blkdiscard the logical volume Last time I checked, dm-crypt did not pass DISCARD requests through to the underlying device because it's a security hazard.
Bug#1064624: Hard to short-stroke an encrypted drive
On Sun, Feb 25, 2024 at 11:42:37PM +0100, Pascal Hambourg wrote: > On 25/02/2024 at 05:40, Matthew Wilcox wrote: > > > > The partitioner "guided partitioning" offers me: > > > > - use the largest continuous free space > > - use entire disk > > - use entire disk and set up LVM > > - use entire disk and set up encrypted LVM > > > > I want "use largest contiguous space and set up encrypted LVM". > > That would let me reserve 200GB of my SSD as unencrypted free space, > > which will improve the write endurance of my SSD. > > Alternatively, the installer allows to reserve free space in the encrypted > volume group. That does not accomplish my goal of extending the life of my SSD. The SSD will see those blocks as "in use" because they have encrypted data written to them (it cannot tell that they are encrypted blocks of zeroes because, well, they're encrypted). The unused area has to be part of the unencrypted disk. And then I have to call TRIM on it. > > Also once I start partitioning, eg, "and set up LVM", I can't delete the > > partitions again. > > The installer allows to delete logical volumes, volume groups and > unencrypted partitions formerly used as physical volumes, but not encrypted > volumes nor their underlying partitions. Yes. This is a poor experience.
Bug#1064791: No ethernet card in a laptop
Package: debian-installer On my new laptop, d-i prints "No Ethernet card was detected. If you know the name of the driver (etc)". This confused me, as I thought it _also_ couldn't find the wifi driver (since it's a new laptop, it's possible the d-i kernel doesn't know about the wifi device). I suggest that if d-i can find a wifi device, it skips the step where it gives me a long inscrutable list of module names and asks me to choose one to make the network work.
Bug#1064624: Hard to short-stroke an encrypted drive
Package: debian-installer The partitioner "guided partitioning" offers me: - use the largest continuous free space - use entire disk - use entire disk and set up LVM - use entire disk and set up encrypted LVM I want "use largest contiguous space and set up encrypted LVM". That would let me reserve 200GB of my SSD as unencrypted free space, which will improve the write endurance of my SSD. Also once I start partitioning, eg, "and set up LVM", I can't delete the partitions again. Well, I can, but I have to switch to a terminal, run dmsetup remove_all. Which sometimes confuses the partitioner and it gets stuck printing "??? ???" If that happens, I can neither "go back", nor "continue".
Bug#1064617: Passwords should not be changed frequently
Package: debian-installer I just did an installation with the 2024-02-24 debian-testing-amd64-netinst.iso image. I forget the exact wording used, but when setting up a user, d-i printed advice that user passwords should be changed frequently. This is no longer current good advice (since 2017): "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator." https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf I happen to like their suggestion of providing a password-strength meter, but that would be a separate bug. This bug is simply a request to remove this outdated suggestion text from d-i.
Bug#976616: Abysmally slow writes to crypted partition
Package: partman-crypto This isn't really a bug in partman-crypto, but I'm reporting it here for tracking purposes as requested by Steve McIntyre. The symptom I first experienced was when doing an install on a Tiger Lake laptop with a 1TB SSD. The step where we run blockdev-wipe was going to take over 20 hours. I am currently investigating *why* it's taking so long. The SSD is capable of writing at 1.2GB/s and the CPU is capable of encrypting at >4GB/s, so the measured 13.7MB/s is ridiculous. What I've discovered so far is that writing through the page cache is (part of) the problem: # dd if=/dev/zero bs=64k count=1000 of=/dev/mapper/nvme0n1p4_crypt 4.79s, 13.7MB/s # dd if=/dev/zero bs=64k count=10 of=/dev/mapper/nvme0n1p4_crypt oflag=direct 13.6s, 481MB/s If you need to get a release out that doesn't crater performance before I find & fix this bug in the kernel, you could change blockdev-wipe.c to use O_DIRECT. That would be a matter of changing the calloc() call on line 86 to posix_memalign() (and an optional memset()) and specifying O_DIRECT on line 161. You need to align to at least 512 bytes, and for safety, I'd align to sysconf(_SC_PAGESIZE). I have not tested this workaround.
Bug#976112: Overwriting with random data message truncated
Package: debian-installer Version: 2020-11-23 When installing on an NVMe device, the message "The installer is now overwriting /dev/nvme0n1p3 with random data to prevent meta-information leaks from " is truncated in the graphical installer. I'd suggest just s/The installer is now o/O/ Also, it takes a very long time to write a terabyte of random data. I suspect you can't do much about that though (... use RDRAND directly?).
Bug#862884: Please upload
As a result of this patch not being applied, I couldn't connect my laptop to my employer's VPN (because I run testing, and this package isn't available in testing). Applying the patch and building it locally worked fine.
Bug#899308: date -d does not recognise git date format
Package: coreutils Version: 8.28-1 I am lazy and can't remember timezones. So I want to use 'date -d' to convert from the date in a git commit to local time. Date: Thu May 17 17:04:43 2018 +1000 $ date -d 'Thu May 17 17:04:43 2018 +1000' date: invalid date ‘Thu May 17 17:04:43 2018 +1000’ $ date -d 'Thu May 17 17:04:43+1000' Thu May 17 03:04:43 EDT 2018 I don't know why git chose this format over any other of the myriad date formatting standards we have, but it doesn't seem like it would be too hard to recognise this format in addition to all the others.
Bug#897426: Unix pathnames being misinterpreted as commands
Package: hexchat
Version: 2.14.1-2
Tags: patch
If I try to paste output into hexchat, it will attempt to interpret any
unix pathnames as IRC commands. For example:
[CC]t_truncate_self
/bin/bash ../libtool --quiet --tag=CC --mode=link gcc t_truncate_self.c -o
t_truncate_self -g -O2 -g -O2 -DDEBUG -I../include -DVERSION=\"1.1.1\"
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall
-DHAVE_FALLOCATE -lattr /usr/lib/libhandle.la -lacl -lpthread
../lib/libtest.la
libtool: error: cannot find the library '/usr/lib/libhandle.la' or unhandled
argument '/usr/lib/libhandle.la'
will not paste the second line as text to the person I'm having a
conversation with; rather it will attempt to interpret the second line
as a command, and the conversation gets derailed with missing lines.
Hexchat used to have code to detect unix pathnames, but it's currently
commented out. I've written and lightly tested a better heuristic --
IRC commands do not contain a /, so if we see a / before we see a space,
we can infer this is not an IRC command.
This is a superset of the current test for "//" at the beginning of
a string, so delete that check as well.
Description: Don't interpret unix pathnames as commands
Replace the list of common unix pathnames with a simpler heuristic;
if there are two '/' characters before there is a ' ', this cannot be an
IRC command, so just send it to the server as text instead of a command.
Author: Matthew Wilcox <wi...@infradead.org>
--- hexchat-2.14.1.orig/src/common/outbound.c
+++ hexchat-2.14.1/src/common/outbound.c
@@ -4852,6 +4852,9 @@
static int
handle_user_input (session *sess, char *text, int history, int nocommand)
{
+ char cmd_char = prefs.hex_input_command_char[0];
+ unsigned int i;
+
if (*text == '\0')
return 1;
@@ -4859,50 +4862,27 @@
history_add (>history, text);
/* is it NOT a command, just text? */
- if (nocommand || text[0] != prefs.hex_input_command_char[0])
+ if (nocommand || text[0] != cmd_char)
{
handle_say (sess, text, TRUE);
return 1;
}
- /* check for // */
- if (text[0] == prefs.hex_input_command_char[0] && text[1] ==
prefs.hex_input_command_char[0])
- {
- handle_say (sess, text + 1, TRUE);
- return 1;
- }
-
-#if 0 /* Who would remember all this? */
- if (prefs.hex_input_command_char[0] == '/')
+ /*
+* There are no commands with an embedded /, so if we see one before
+* we see a space, assume somebody's pasting a unix pathname or
+* similar. It can't be a command.
+*/
+ for (i = 1; text[i]; i++)
{
- int i;
- const char *unix_dirs [] = {
- "/bin/",
- "/boot/",
- "/dev/",
- "/etc/",
- "/home/",
- "/lib/",
- "/lost+found/",
- "/mnt/",
- "/opt/",
- "/proc/",
- "/root/",
- "/sbin/",
- "/tmp/",
- "/usr/",
- "/var/",
- "/gnome/",
- NULL
- };
- for (i = 0; unix_dirs[i] != NULL; i++)
- if (strncmp (text, unix_dirs[i], strlen
(unix_dirs[i]))==0)
- {
- handle_say (sess, text, TRUE);
- return 1;
- }
+ if (text[i] == cmd_char)
+ {
+ handle_say (sess, text, TRUE);
+ return 1;
+ }
+ if (text[i] == ' ')
+ break;
}
-#endif
return handle_command (sess, text + 1, TRUE);
}
Bug#897387: xfslibs-dev needs to include .la files
Package: xfslibs-dev Version: 4.15.1-1 trying to build the latest from git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git [CC]t_truncate_self /bin/bash ../libtool --quiet --tag=CC --mode=link gcc t_truncate_self.c -o t_truncate_self -g -O2 -g -O2 -DDEBUG -I../include -DVERSION=\"1.1.1\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -DHAVE_FALLOCATE -lattr /usr/lib/libhandle.la -lacl -lpthread ../lib/libtest.la libtool: error: cannot find the library '/usr/lib/libhandle.la' or unhandled argument '/usr/lib/libhandle.la' I downloaded the debian package of xfslibs-dev, built it, then manually copied libhandle/libhandle.la into /lib and then I could build xfstests-dev.
Bug#887472: Please update to newer version
Package: x86info Version: 1.31~pre0.8052aabdd159bc9050e7dc264f33782c5acce05f-1+b1 This version doesn't recognise the Kaby Lake in my laptop. The version I just downloaded from git does.
Bug#854778: liburcu 32 bit and 64 bit versions cannot install simultaneously
I think you may need to rebuild them differently from this in order to have it work. I just installed zlib1g-dev:i386 and :amd64 to have an example to look at. Each of these packages contains the same files under /usr/share and /usr/include, and dpkg happily installed them both without special flags on my part. Try “apt-get source liburcu-dev”, and edit the debian/control file’s Multi-Arch line for liburcu-dev. Then rebuild it and see if it behaves differently when you try to install them both at the same time. 2. I fetched .deb files for both, extracted them using, dpkg-deb -R liburcu-dev_0.9.1-3_amd64.deb rcupackage_amd64 dpkg-deb -R liburcu-dev_0.9.1-3_i386.deb rcupackage_i386 3. Added 'Multi-Arch: same' to DEBIAN/control file for both packages. 4. Re-packaged them using, dpkg-deb -b rcupackage_amd64 rcupackage_amd64.deb dpkg-deb -b rcupackage_i386 rcupackage_i386.deb 5. Installed both using, sudo dpkg -i rcupackage_amd64.deb; sudo apt install -f sudo dpkg -i --force-overwrite rcupackage_i386.deb; sudo apt install -f The overwrite was done for files in /usr/share/doc/liburcu-dev/examples/ and file /usr/include/urcu/config.h. In this way, I was able to install both and use them for what I wanted. But how to avoid the clash of files? I understand that we have these different names usr/lib/i386-linux-gnu and usr/lib/x86_64-linux-gnu. Thanks, Rehas
Bug#642496: quadrapassel doesn't move the top line down when removing lines
Package: gnome-games
Version: 2.30.2-2
Tags: patch
If you fill the entire playing field with blocks, then remove some lines
by completing a row, the top line stays stationary. It turns out to be
a simple fencepost error as the below patch (which fixes the problem)
demonstrates.
The easiest way to reproduce the problem is fill the entire left or
right column with blocks, right up to the top, then clear the bottom row.
What happens is this:
|x
|
|x
|x
|x
when it should look like this:
|
|x
|x
|x
|x
diff -urp gnome-games-2.30.2/quadrapassel/blockops.cpp
gnome-games-qpfix/quadrapassel/blockops.cpp
--- gnome-games-2.30.2/quadrapassel/blockops.cpp2010-04-10
01:01:17.0 -0400
+++ gnome-games-qpfix/quadrapassel/blockops.cpp 2011-09-22 15:17:47.0
-0400
@@ -363,7 +363,7 @@ BlockOps::checkFullLines()
clutter_behaviour_remove_all (explode_fade_behaviour);
clutter_behaviour_remove_all (explode_scale_behaviour);
- for (int y = MIN (posy + 4, LINES); y 0; --y)
+ for (int y = MIN (posy + 4, LINES); y = 0; --y)
{
if (checkFullLine (y))
{
--
Matthew Wilcox Intel Open Source Technology Centre
Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625224: xhci-hcd has the wrong module name
Package: initramfs-tools Version: 0.98.8 In /usr/share/initramfs-tools/hook-functions, xhci-hcd is spelled simply xhci. It was renamed to xhci-hcd in 2.6.34-rc2. Please update this script. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567555: [kerneloops] basename : command not found
On Tue, Feb 02, 2010 at 08:24:09AM -0500, Brent S. Elmer Ph.D. wrote: I did that but it doesn't get much farther. Here is as far back as I can see at the top of the screen: Starting kerneloops:/sbin/start-stop-daemon: stat /usr/sbin/kerneloops: No such file or directory Seems like you don't have /usr mounted ... so you don't have kerneloops. I have narrowed the problem down to 1 kernel config paramater(CONFIG_LBDAF). If I build my kernel with CONFIG_LBDAF=y, the kernel will work. If I don't, it won't boot. I have submitted a bug report for linux-source-2.6.32 for this. My computer is a Lenovo thinkpad w500 with only a 150G hard drive so there is no need for CONFIG_LBDAF. I got a response from a Debian person saying to submit the kernel bug upstream and to give the kerneloops information. I don't know how to get any kerneloops information given what I see above. I think they mean to submit the kernel oops information printed to the screen, not to use the kerneloops package (which is a means for transmitting kernel oops information upstream automatically). Your system crashes too early for the kerneloops daemon to be able to help you. -- Matthew Wilcox Intel Open Source Technology Centre Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567555: [kerneloops] basename : command not found
On Fri, Jan 29, 2010 at 01:23:13PM -0500, Brent S. Elmer Ph.D. wrote: I have built a new 2.6.32 kernel that is failing to boot. I don't know what the failure is. The previous kernel I built that works is 2.6.30. I used the config from the 2.6.30 and make oldconfig to configure for the 2.6.32 build. The failure is early on and has scrolled off the screen. What I do see on the screen is: /etc/rc2.d/S23kerneloops: line 29: basename: command not found OK, change line 29 of /etc/init.d/kerneloops from: prog=$(basename $exec) to: prog=kerneloops Sorry about that, I'll fix it in the next upload. -- Matthew Wilcox Intel Open Source Technology Centre Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#421386: can't install gnome-themes
reopen 421386 thanks On Sat, Sep 26, 2009 at 01:55:52PM +0200, Andrea Veri wrote: rmadison gnome-themes-common returns me nothing, so I guess we can close this bug now. Also there is no more activity since May 2007, therefore this bug shouldnt be a problem anymore. Feel free to re-open if it will happena again. I guess you didn't understand the bug. If you had installed gnome-themes-common a long time ago, and now tried to upgrade to stable, it fails to work. There is a simple solution, which for some reason hasn't yet been implemented. -- Matthew Wilcox Intel Open Source Technology Centre Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#421386: can't install gnome-themes
On Sun, Sep 27, 2009 at 12:05:29AM +0200, Emilio Pozuelo Monfort wrote: Matthew Wilcox wrote: I guess you didn't understand the bug. If you had installed gnome-themes-common a long time ago, and now tried to upgrade to stable, it fails to work. There is a simple solution, which for some reason hasn't yet been implemented. If you upgrade to stable, it's from oldstable (etch), but it doesn't have gnome-themes-common, so I wonder what the bug is. You should remove packages that don't exist in the archive anymore before dist-upgrading, so at best this would be a wishlist, and wontfix since we won't push an update to stable for such a thing IMHO. I think gnome-themes-common predates etch. I'm not sure how old a distro has to be to include 2.14, nor whether we support upgrading from such a release directly to lenny or even etch. I find it very sad that a bug like this gets closed by virtue of being ignored for so long. Don't you? -- Matthew Wilcox Intel Open Source Technology Centre Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476328: Here's a patch to split the package
On Fri, Aug 07, 2009 at 01:48:34PM -0400, Tim Abbott wrote:
tag 476328 +patch
thanks
I've attached a patch to split the package into a kerneloops package and a
kerneloops-applet package. The new kerneloops package has just the
daemon, and works as though allow-submit = ask were set to no. There
may be some migration cost of people who upgrade and lose the GUI, but I
think that this is a substantially better design than having two packages
that both contain indentical copies of the kerneloops daemon, init script,
etc.
Later, we can try to implement an allow-submit = ask system for when one
doesn't have a GUI using one of the schemes from this bug report.
How about we do this the opposite way round, where we have
a kerneloops-daemon package, and the kerneloops package depends
on it? That way, people who upgrade from current kerneloops lose no
functionality, and new installs who want to get rid of the applet can
just install kerneloops-daemon?
(I also submitted this patch to this Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/kerneloops/+bug/337757)
-Tim Abbott
From 439668b7c0b40ac60455b2cf1989ca29051de8e5 Mon Sep 17 00:00:00 2001
From: Tim Abbott tabb...@ksplice.com
Date: Thu, 23 Jul 2009 11:10:05 -0400
Subject: [PATCH] Split the kerneloops package into kerneloops and
kerneloops-applet.
Signed-off-by: Tim Abbott tabb...@ksplice.com
---
debian/control |8
debian/kerneloops-applet.install |3 +++
debian/kerneloops.install|2 ++
debian/rules |6 --
4 files changed, 17 insertions(+), 2 deletions(-)
create mode 100644 debian/kerneloops-applet.install
create mode 100644 debian/kerneloops.install
mode change 100644 = 100755 debian/rules
diff --git a/debian/control b/debian/control
index 0e93c6a..3de12ca 100644
--- a/debian/control
+++ b/debian/control
@@ -14,3 +14,11 @@ Description: kernel oops tracker
kerneloops is a daemon that collects kernel crash information and then
submits the extracted signature to the kerneloops.org website for
statistical analysis and presentation to the Linux kernel developers.
+
+Package: kerneloops-applet
+Architecture: any
+Depends: ${shlibs:Depends}, kerneloops
+Description: applet for the kernel oops tracker
+ The kerneloops applet allows the kerneloops crash reporting utility
+ to ask a desktop user for permission before submitting an oops report
+ to the kerneloops.org website.
diff --git a/debian/kerneloops-applet.install
b/debian/kerneloops-applet.install
new file mode 100644
index 000..3850712
--- /dev/null
+++ b/debian/kerneloops-applet.install
@@ -0,0 +1,3 @@
+debian/tmp/usr/bin/kerneloops-applet /usr/bin
+debian/tmp/usr/share/kerneloops /usr/share
+debian/tmp/usr/share/locale /usr/share
diff --git a/debian/kerneloops.install b/debian/kerneloops.install
new file mode 100644
index 000..cb7f717
--- /dev/null
+++ b/debian/kerneloops.install
@@ -0,0 +1,2 @@
+debian/tmp/usr/sbin/kerneloops /usr/sbin/
+debian/tmp/usr/share/man/man8/* /usr/share/man/man8/
diff --git a/debian/rules b/debian/rules
old mode 100644
new mode 100755
index dfe7ee3..ebf8678
--- a/debian/rules
+++ b/debian/rules
@@ -27,8 +27,10 @@ install: build
dh_installdirs
# Add here commands to install the package into debian/packagename
- $(MAKE) DESTDIR=`pwd`/debian/`dh_listpackages` install
+ $(MAKE) DESTDIR=`pwd`/debian/tmp install
install -D -m 0755 kerneloops.init
`pwd`/debian/kerneloops/etc/init.d/kerneloops
+ dh_install -pkerneloops
+ dh_install -pkerneloops-applet
# Build architecture-independent files here.
binary-indep: build install
@@ -41,7 +43,7 @@ binary-arch: build install
dh_installchangelogs
dh_installdocs
dh_installexamples
- dh_installinit -o
+ dh_installinit -pkerneloops -o
#dh_installdebconf
#dh_installman kerneloops.8
dh_link
--
1.6.3.3
--
Matthew Wilcox Intel Open Source Technology Centre
Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476328: Here's a patch to split the package
On Fri, Aug 07, 2009 at 04:03:32PM -0400, Tim Abbott wrote: On Fri, 7 Aug 2009, Matthew Wilcox wrote: On Fri, Aug 07, 2009 at 01:48:34PM -0400, Tim Abbott wrote: I've attached a patch to split the package into a kerneloops package and a kerneloops-applet package. The new kerneloops package has just the daemon, and works as though allow-submit = ask were set to no. There may be some migration cost of people who upgrade and lose the GUI, but I think that this is a substantially better design than having two packages that both contain indentical copies of the kerneloops daemon, init script, How about we do this the opposite way round, where we have a kerneloops-daemon package, and the kerneloops package depends on it? That way, people who upgrade from current kerneloops lose no functionality, and new installs who want to get rid of the applet can just install kerneloops-daemon? Hmm. I think long-term it would be best to have the names be kerneloops/kerneloops-applet. kerneloops-daemon/kerneloops is certainly much better than kerneloops-nogui/kerneloops, but I think is still a bit confusing. It may very well be justified by saving the current userbase from having things change out from under them. We can set that as our goal and transition to it. So we should split the package into kerneloops-applet and kerneloops-daemon. Then create a new kerneloops dummy package which depends on kerneloops-applet. In a couple of years, we can rename kerneloops-daemon to kerneloops, and everybody should be happy. Computer Science Motto: All problems can be solved with an extra layer of abstraction ;-) -- Matthew Wilcox Intel Open Source Technology Centre Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495562: Disc format changes
Actually, btrfs disc format changed in 0.16. It's really not appropriate to ship this in Lenny. It's not ready and will create pain for our users and for the upstream btrfs developers. It definitely is worth having this packaged -- but only shipping in lenny+1. -- Matthew Wilcox Intel Open Source Technology Centre Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486478: Where's the build log?
I went to buildd.debian.net and I don't see the build log for this package. And the [0] reference doesn't seem to have been filled in in the original mail. How very strange. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486478: Where's the build log?
On Mon, Jun 23, 2008 at 09:33:14PM +0200, Daniel Baumann wrote: ...and sorry for having missed in the first mail. That's OK, I was just a bit perturbed at not being able to find the build logs in the system. It's a bit odd the way it's built. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486478: Where's the build log?
On Mon, Jun 23, 2008 at 09:28:53PM +0200, Daniel Baumann wrote: mips: http://buildd.debian.org/fetch.cgi?pkg=linux-modules-extra-2.6ver=2.6.25-2arch=mipsstamp=1213610531file=log Thanks! Here's the failing line: CC [M] /build/buildd/linux-modules-extra-2.6-2.6.25/debian/build/build_mips_none_r4k-ip22_et131x/et131x_initpci.o et131x_initpci.c: In function 'et131x_pci_setup': et131x_initpci.c:1375: error: implicit declaration of function 'pci_set_consistent_dma_mask' But look at this: $ grep pci_set_consistent_dma_mask include/linux/* include/linux/pci.h:int pci_set_consistent_dma_mask(struct pci_dev *dev, u64 mask); $ grep pci.h et131x_initpci.c #include linux/pci.h The only way I can see this happening is if CONFIG_PCI isn't set. But as far as I can tell, this driver is PCI only, so it should be disabled for non-PCI builds. s390: http://buildd.debian.org/fetch.cgi?pkg=linux-modules-extra-2.6ver=2.6.25-2arch=s390stamp=1213582615file=log We know s390 doesn't have PCI ;-) Hell, it doesn't have MMIO, IO ports ... anyway, it should be disabled for s390. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484493: kerneloops: Why not started at (the default) runlevel 2?
On Wed, Jun 04, 2008 at 01:31:20PM +0200, Frans Pop wrote: I have been wondering why I've never seen anything from kerneloops as I often run upstream RC kernels and have seen at least WARNON messages. I now find that the init script has: # Default-Start: 3 4 5 # Default-Stop: 0 1 2 6 Which means that the daemon is just not started at Debian's default runlevel 2. I could not find any reason for that in either the man page or in /usr/share/doc. I guess you're using a different init system from me: /etc/rc0.d/K20kerneloops - ../init.d/kerneloops /etc/rc1.d/K20kerneloops - ../init.d/kerneloops /etc/rc2.d/S20kerneloops - ../init.d/kerneloops /etc/rc3.d/S20kerneloops - ../init.d/kerneloops /etc/rc4.d/S20kerneloops - ../init.d/kerneloops /etc/rc5.d/S20kerneloops - ../init.d/kerneloops /etc/rc6.d/K20kerneloops - ../init.d/kerneloops I'll guess the reason that this is done is because the original init was done for Red Hat systems which use runlevel 2 to mean no X, and I didn't pick up on this gratuitous and annoying difference between Debian and Red Hat. I'll fix it in the next upload, thanks for bringing it to my attention. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482902: please provide libc6-hppa64 and libc6-hppa64-dev packages
On Sun, May 25, 2008 at 11:21:28PM +0200, Matthias Klose wrote: that's fine. in this case we should drop support for hppa for lenny. Probably a good idea. I don't think anyone's doing much work with hppa and Debian any more. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482902: please provide libc6-hppa64 and libc6-hppa64-dev packages
On Mon, May 26, 2008 at 01:17:06AM +0200, Thibaut VARENE wrote: On Mon, May 26, 2008 at 12:14 AM, Matthew Wilcox [EMAIL PROTECTED] wrote: On Sun, May 25, 2008 at 11:21:28PM +0200, Matthias Klose wrote: that's fine. in this case we should drop support for hppa for lenny. Probably a good idea. I don't think anyone's doing much work with hppa and Debian any more. I kind of resent that affirmation. Sometimes the truth hurts, I guess. Not even questioning its grounds, I'm sure we don't decide to evict an architecture simply based on doubt, and uncertainty? hppa doesn't have any major flaw we're aware of, it has porters dedicated to maintaining it and it keeps up with the archive (99.9% of lenny is built on hppa[0]). Does it really have porters dedicated to maintaining it? http://wiki.debian.org/hppaLennyReleaseRecertification The Debian port is maintained by the following developers, who actively work on architecture specific issues: 1. KyleMcMartin 2. ThibautVarene 3. ... 4. ... 5. ... I have a fairly good idea what Kyle's been doing recently. What have you done for the hppa port recently? Does anybody else intend to step up to be porter 3, 4 and 5? The developer machines have been unavailable for months, so Debian developers who don't have their own hppa machine are unable to work on their own packages or fix bugs. I'll just assume this was the expression of your personal opinion, and I'll state mine which is pretty much opposed to what you suggest. In the end I'm sure any decision will be taken based on facts, which is fine with me. What is needed here is not some Descartian dialect designed to separate truth from falsehood, but people putting in some work. The port has been coasting for several years now and things are gradually rotting. Do we put a stake in the corpse now, or make an effort to fix some bugs? -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476328: split package: desktop and server
On Tue, Apr 15, 2008 at 06:31:15PM -0400, Joey Hess wrote: I'd like to be able to install kerneloops on a server without needing to install desktop dependencies that will never be used. ie all the gnome stuff? Fair enough, I suppose. It would also be convenient if installation of kerneloops on a server didn't need editing of /etc/kerneloops.conf to enable it sending oopes. I'm very leery about this. I think we need to recognise the privacy/security implications here. The user needs to take some kind of affirmitive action to permit the transmission of data from their machine. I'd like kerneloops installed by default ... so having the 'ask' is the right way to proceed. Arguably typing 'apt-get install kerneloops-foo' is affirmitive action, but I'd prefer something a little more explicit. I wonder if we could send an email to root. Something like: Hi. This is your friendly kerneloops daemon. I've noticed a few oopses in your logfiles that don't appear to have been submitted to the central server at kerneloops.org. If you want to enable these to be sent automatically, please edit /etc/kerneloops.conf and change allow-submit=ask to allow-submit=yes. If you don't want to be bothered with these mails any more, either change allow-submit to no or deinstall the kerneloops package. With this said, the current configuration is right for desktops, and dekstop users shouldn't need to edit the file either. I think that two packages are called for. The easiest split would be the keep the current package unchanged and add a kerneloops-server package that conflicts with it. The name is wrong. The kerneloops-server is something that runs on kerneloops.org (and afaik the source isn't released). I guess kerneloops-nogui would have to have priority extra if it's going to conflict with something with priority optional. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365148: Taking over keyanalyze
On Mon, Apr 21, 2008 at 10:06:51PM +0200, Christoph Berg wrote: I would like to take over your keyanalyze package, and put it under the signing-party umbrella that already hosts a number of similar tools. The outstanding bugs all sound fixable, or already have a patch. Makes sense. Go ahead. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475398: tasksel: add kerneloops to standard task
On Fri, Apr 11, 2008 at 01:38:30PM +0200, Frans Pop wrote: I installed it without problems on my KDE desktop. It's dependencies look sane (did not pull in any new packages in my case) and the default configuration is to ask to be allowed to submit. Only remaining question is how it works on systems that do not have a graphical environment installed, especially with the default of ask. If you're not running a graphical interface, with the default of 'ask', nothing's going to listen for kerneloops dbus messages, so the daemon will never be signalled to send oopses. You can, of course, change the default in /etc/kerneloops.conf from 'ask' to 'always'. Do you think we need a debconf question to set this up? Or a note to let people know they can activate it? My opinion is that this will still be useful even if people with headless servers don't activate it. I think many more people encounter kernel bugs on desktop Debian machines than they do on servers. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462412: kerneloops: Refuses to run, lacks documentation
On Thu, Jan 24, 2008 at 07:27:03PM +0100, Johan Walles wrote: Package: kerneloops Version: 0.7-1 Severity: grave Justification: renders package unusable Grave? Are you serious? Anyway, I have 0.10 prepared with an init script. I just need to upload it, which won't happen until I'm physically reunited with my gpg secret key, which will be in approximately 2 weeks. In the meantime you can download some untrustable packages from http://people.debian.org/~willy/kerneloops/ (feel free to verify the orig.tar.gz matches upstream and the contents of the diff.gz, then rebuild it yourself). -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460106: ia64 guile woes
X-Debbugs-CC: [EMAIL PROTECTED]
Package: guile-1.8
Version: 1.8.3+1-1
It's a one-liner to fix the compile failure in gc.c:
--- guile-1.8-1.8.3+1.orig/libguile/gc.c
+++ guile-1.8-1.8.3+1/libguile/gc.c
@@ -1058,7 +1058,7 @@
void *
scm_ia64_ar_bsp (const void *opaque)
{
- ucontext_t *ctx = opaque;
+ const ucontext_t *ctx = opaque;
return (void *) ctx-uc_mcontext.sc_ar_bsp;
}
# endif/* linux */
However, the test-suite then fails:
PASS: test-list
/bin/sh: line 4: 12524 Illegal instruction../../pre-inst-guile-env
${dir}$tst
FAIL: test-unwind
I don't have time to dig into this further, but perhaps the above patch
could be integrated so the next person who wonders why they can't
install a bunch of guile stuff will find it's a harder problem.
--
Intel are signing my paycheques ... these opinions are still mine
Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453899: ether_line returns far too much
On Sun, Dec 02, 2007 at 10:15:16AM -0500, Clint Adams wrote: On Sat, Dec 01, 2007 at 09:49:23PM -0700, Matthew Wilcox wrote: const char *ethers = mmap(NULL, 10, PROT_READ, MAP_SHARED, fd, 0); ether_line(ethers, addr, hostname); Is there a reason to pass more than one actual line to ether_line()? Um, I think I just showed an example -- where you want to mmap /etc/ethers rather than fgets() each line in turn. Is that a usage that we don't want to support? If so, I think the manpage should be amended to state that. It's somewhat ambiguous, of course: The ether_line() function parses a line in /etc/ethers format (ethernet address followed by whitespace followed by hostname; '#' introduces a comment) and returns an address and hostname pair, or non-zero if it cannot be parsed. The buffer pointed to by hostname must be suffi- ciently long, for example, have the same length as line. It doesn't say the line has to be NUL-terminated; my understanding would be that a \n terminates a line. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453899: ether_line returns far too much
Package: libc6
Version: 2.6.1-1+b1
I'm convinced this is an upstream bug, but the glibc upstream bug
reporting page is about as snarly as any I've ever seen, and insist I
report it to you instead.
Here's a test program:
#include netinet/ether.h
#include stdio.h
#include sys/mman.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
int main(void)
{
struct ether_addr addr;
char hostname[1024];
int fd = open(ethers, O_RDONLY);
const char *ethers = mmap(NULL, 10, PROT_READ, MAP_SHARED, fd, 0);
ether_line(ethers, addr, hostname);
printf(%s\n, hostname);
return 0;
}
And here's the data file (ie ethers) I run it against:
00:16:35:4b:ca:eb charming
00:30:6e:1b:6f:2c fozzie
00:30:6e:38:2a:29 rowlf
00:30:6e:1e:6e:65 animal
# honeydew wireless (HP 11b card)
00:02:2d:1d:d7:f2 honeydew-wb
# honeydew wireless (3com 11g card)
00:12:a9:d1:8b:1f honeydew-wg
# honeydew tethered
08:00:46:77:c2:53 honeydew
Here's what MacOS X prints:
charming
Here's what glibc prints:
charming
00:30:6e:1b:6f:2c fozzie
00:30:6e:38:2a:29 rowlf
00:30:6e:1e:6e:65 animal
Clearly it stops at the first #, not at the end of line.
This is a severe bug as it can lead to overrunning the 'hostname' buffer.
--
Intel are signing my paycheques ... these opinions are still mine
Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439572: lwm: Package description should be neutral about the software
tag 439572 wontfix thanks On Sat, Aug 25, 2007 at 08:16:23AM +0200, Christian Perrier wrote: This package's description should be more neutral with regards of what the software can do and cannot do. There is no need to mention if you want this, use another software or talk about whatever Holy War to reconquest the computer's memory. This makes the package's description sound slightly childish, IMHO. It's how the author describes it on his website ... http://www.jfc.org.uk/software/lwm.html -- Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433956: Allow customising goto label indentation
Package: indent
Version: 2.2.9-9
Severity: wishlist
I like my source code to have a one space indent before the goto label,
like this:
int foo(void)
{
bar();
quux:
}
The current code hardcodes an indentation of two columns less than the
current indentation. This patch allows you to configure a negative
displacement from the current indent level, or a positive absolute
displacement. So I can now invoke indent as:
$ indent -kr -i8 -li1
and get the style I prefer.
Notice that -li0 will give you a label in the first column. -li-2 will
give the current, and default behaviour.
Here's the patch to implement that. I even added documentation!
diff -u indent-2.2.9/src/indent.h indent-2.2.9/src/indent.h
--- indent-2.2.9/src/indent.h
+++ indent-2.2.9/src/indent.h
@@ -80,6 +80,8 @@
#define DEFAULT_RIGHT_COMMENT_MARGIN 78
+#define DEFAULT_LABEL_INDENT -2
+
/* Name of input file. */
extern char *in_name;
@@ -201,6 +203,7 @@
int leave_preproc_space; /* if true, leave the spaces between '#' and
preprocessor commands. */
int force_preproc_width; /* if this is 0, this becomes the preproc
indent-level */
int lineup_to_parens;/* if true, continued code within parens will be
lined up to the open paren */
+int label_indent; /* if 0 an absolute indent, if 0 relative to
curret indent level */
int honour_newlines; /* True when positions at which we read a newline
in the input file, should get
* a high priority to break long lines at. */
int format_comments; /* If any comments are to be reformatted */
--- indent-2.2.9.orig/doc/indent.texinfo
+++ indent-2.2.9/doc/indent.texinfo
@@ -1188,6 +1188,16 @@
columns wide, but (as of version 1.2) may be changed by the @option{-ts}
option. Tabs are treated as the equivalent number of spaces.
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
+The indentation of goto labels is controlled by the @option{-li} parameter. If
+it is set to zero or a positive number, this indicates how far from the left
+margin to indent a label. If it is set to a negative number, this indicates
+how far back from the current indent level to place the label. The default
+setting is -2 which matches the behaviour of earlier versions of indent.
+Note that this parameter does not affect the placing of case labels; see the
[EMAIL PROTECTED] parameter for that.
+
@kindex [EMAIL PROTECTED]
@kindex [EMAIL PROTECTED]
@kindex -nip
@@ -1656,6 +1666,11 @@
Set maximum line length for comment formatting to @[EMAIL PROTECTED]
@xref{Comments}.
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
+Set indentation for labels to @[EMAIL PROTECTED]
[EMAIL PROTECTED]
+
@item -lp
@itemx --continue-at-parentheses
Line up continued lines at [EMAIL PROTECTED]
--- indent-2.2.9.orig/src/io.c
+++ indent-2.2.9/src/io.c
@@ -54,9 +54,6 @@
RCSTAG_CC ($Id: io.c,v 1.50 2002/08/04 17:08:41 david Exp $);
-/* number of levels a label is placed to left of code */
-#define LABEL_OFFSET 2
-
/**/
/* Stuff that needs to be shared with the rest of indent. Documented in
* indent.h.
@@ -312,9 +309,14 @@
/* FIXME: does this belong here at all? */
return 1;
}
+
+if (settings.label_indent 0)
+{
+return parser_state_tos-ind_level + settings.label_indent + 1;
+}
else
{
-return parser_state_tos-ind_level - LABEL_OFFSET + 1;
+return settings.label_indent + 1;
}
}
--- indent-2.2.9.orig/src/args.c
+++ indent-2.2.9/src/args.c
@@ -125,6 +125,7 @@
static int exp_kr = 0;
static int exp_l= 0;
static int exp_lc = 0;
+static int exp_li = 0;
static int exp_lp = 0;
static int exp_lps = 0;
static int exp_nip = 0;
@@ -252,6 +253,7 @@
{nbacc, PRO_BOOL, false, OFF,
settings.blanklines_around_conditional_compilation, exp_bacc},
{lps, PRO_BOOL, false, ON,
settings.leave_preproc_space, exp_lps},
{lp, PRO_BOOL,true, ON,
settings.lineup_to_parens, exp_lp},
+{li, PRO_INT, DEFAULT_LABEL_INDENT, ONOFF_NA,
settings.label_indent, exp_li},
{lc, PRO_INT, DEFAULT_RIGHT_COMMENT_MARGIN, ONOFF_NA,
settings.comment_max_col, exp_lc},
{l, PRO_INT, DEFAULT_RIGHT_MARGIN, ONOFF_NA,
settings.max_col, exp_l},
{kr, PRO_SETTINGS, 0, ONOFF_NA,
KR_SETTINGS_STRING, exp_kr},
@@ -365,6 +367,7 @@
{nbacc, PRO_BOOL, false, OFF,
settings.blanklines_around_conditional_compilation, exp_bacc},
{lps, PRO_BOOL, false, ON,
settings.leave_preproc_space,
Bug#423631: segfaulting gdb on ia64
On Tue, Jun 05, 2007 at 04:46:56PM +0200, Martin Michlmayr wrote: * Daniel Jacobowitz [EMAIL PROTECTED] [2007-05-22 10:21]: /home/willy/debian/gdb/gdb-6.6.dfsg/gdb/libunwind-frame.c:272: internal-error: libunwind_frame_prev_register: Assertion `regnum = 0' failed. IIRC there's a configure option you have to specify to use libunwind; maybe that's what's broken. Has there been any progress on this bug? I'd need to use gdb on ia64. :/ I have to confess that once I built gdb from CVS, I got distracted with other things. The fate of the debugger, I guess ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422722: gs has been broken since 2004
severity 422722 serious thanks I haven't been running unstable on my ia64 system, so I didn't notice gs being broken. Unfortunately, it's now broken imagemagick too. I can upload an NMU if you don't have time to handle this issue. I independently came up with the same patch as dannf: diff -u gs-gpl-8.56.dfsg.1/debian/patches/06_libpaper_support.dpatch gs-gpl-8.56.dfsg.1/debian/patches/06_libpaper_support.dpatch --- gs-gpl-8.56.dfsg.1/debian/patches/06_libpaper_support.dpatch +++ gs-gpl-8.56.dfsg.1/debian/patches/06_libpaper_support.dpatch @@ -39,6 +39,14 @@ diff -urN gs-gpl-8.56.dfsg.1.orig/src/imainarg.c gs-gpl-8.56.dfsg.1/src/imainarg.c --- gs-gpl-8.56.dfsg.1.orig/src/imainarg.c 2007-01-18 06:10:47.0 +0900 +++ gs-gpl-8.56.dfsg.1/src/imainarg.c 2007-05-05 08:35:34.0 +0900 +@@ -16,6 +16,7 @@ + #include ctype_.h + #include memory_.h + #include string_.h ++#include paper.h + #include stdlib.h /* for qsort */ + + #include ghost.h @@ -198,6 +198,29 @@ return e_Fatal; } diff -u gs-gpl-8.56.dfsg.1/debian/changelog gs-gpl-8.56.dfsg.1/debian/changelog --- gs-gpl-8.56.dfsg.1/debian/changelog +++ gs-gpl-8.56.dfsg.1/debian/changelog @@ -1,3 +1,10 @@ +gs-gpl (8.56.dfsg.1-1.1) unstable; urgency=low + + * Fix libpaper support on ia64 (and probably some other 64-bit architectures +too) + + -- Matthew Wilcox [EMAIL PROTECTED] Fri, 25 May 2007 17:23:01 -0400 + gs-gpl (8.56.dfsg.1-1) unstable; urgency=low * New upstream release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423631: segfaulting gdb on ia64
I hit the same problem as the buildd and Kurt. Since I need something more recent than gdb 6.5 in order to handle current ia64 executables, I tried to run it anyway. It's not pretty: $ ./objdir/gdb/gdb gs GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as ia64-linux-gnu... (no debugging symbols found) Using host libthread_db library /lib/libthread_db.so.1. (gdb) set args /home/willy/gnupg/keyanalyze-200204-willy/bsdcan2007/output/graph.ps (gdb) run Starting program: /usr/bin/gs /home/willy/gnupg/keyanalyze-200204-willy/bsdcan2007/output/graph.ps (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. 0x20580e61 in strncat () from /lib/libc.so.6.1 (gdb) bt #0 0x20580e61 in strncat () from /lib/libc.so.6.1 #1 0x4010a8a0 in ?? () /home/willy/debian/gdb/gdb-6.6.dfsg/gdb/libunwind-frame.c:272: internal-error: libunwind_frame_prev_register: Assertion `regnum = 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y /home/willy/debian/gdb/gdb-6.6.dfsg/gdb/libunwind-frame.c:272: internal-error: libunwind_frame_prev_register: Assertion `regnum = 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) y Aborted I really don't know how to go about debugging the debugger when the previous version of the debugger no longer works. $ gdb ./objdir/gdb/gdb GNU gdb 6.5-debian This GDB was configured as ia64-linux-gnu...BFD: /home/willy/debian/gdb/gdb-6.6.dfsg/objdir/gdb/gdb: don't know how to handle OS specific section `.gnu.hash' [0x6ff6] /home/willy/debian/gdb/gdb-6.6.dfsg/objdir/gdb/gdb: not in executable format: File format not recognized -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423631: segfaulting gdb on ia64
On Tue, May 22, 2007 at 08:23:34AM -0400, Daniel Jacobowitz wrote: On Tue, May 22, 2007 at 06:00:20AM -0600, Matthew Wilcox wrote: I hit the same problem as the buildd and Kurt. Since I need something more recent than gdb 6.5 in order to handle current ia64 executables, I tried to run it anyway. It's not pretty: If you have some time to look at this, could you try building a CVS checkout of GDB on ia64? Maybe that will work better. Much better: === gdb Summary === # of expected passes11320 # of unexpected failures69 # of unexpected successes 2 # of expected failures 41 # of known failures 45 # of unresolved testcases 1 # of untested testcases 5 # of unsupported tests 13 (ulimit -c was set to 0, so some of those fails are my fault). Running it against gs, my previous testcase, I now get: Program received signal SIGSEGV, Segmentation fault. 0x20580e61 in strncat () from /lib/libc.so.6.1 (gdb) bt #0 0x20580e61 in strncat () from /lib/libc.so.6.1 #1 0x4010a8a0 in ?? () #2 0x40005970 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) which is a damn sight better than the assertion failure. /home/willy/debian/gdb/gdb-6.6.dfsg/gdb/libunwind-frame.c:272: internal-error: libunwind_frame_prev_register: Assertion `regnum = 0' failed. That's very strange... -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419410: Also a problem for ps - jpeg
I'm also seeing this on i386: $ convert bsdcan2007/output/graph.ps bsdcan2007/output/graph.jpg convert: missing an image filename `bsdcan2007/output/graph.jpg'. $ convert -geometry 320x240 bsdcan2007/output/graph.ps bsdcan2007/output/graph-small.jpg convert: missing an image filename `bsdcan2007/output/graph-small.jpg'. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421386: Happened to me too
reopen 421386 thanks I have the same problem on an ia64/unstable machine. Clearly at some point the gnome-themes-common package got installed and was never uninstalled. Why not fix this simply by Conflicts/Replaces: gnome-themes-common? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422713: [Pkg-pciutils-discuss] Bug#422713: lspci does not list anything (etch and dailies)
On Tue, May 08, 2007 at 12:43:26AM +0300, Eddy Petri??or wrote: On 08/05/07, Geert Stappers [EMAIL PROTECTED] wrote: reassign 422713 pciutils tags 422713 d-i Probably I would have assigned this to the kernel than to pciutils. (OTOH, taking into account that (probably) due to this bug networking is not set up, I'd say this is an issue that should be di's concern.) It could be the fault of any of the three components. Let's try to debug this. Can you run lspci -G and see if it says something like: Trying method 1..using /sys/bus/pci...OK Decided to use Linux-sysfs My guess is that sysfs isn't mounted, but that's tentative. Note that I don't care what the actual PCI devices are that you have ... just the information about what methods it's trying. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421149: Causes FTBFS with GCC 4.3: the meaning of inline changed in C99
On Thu, Apr 26, 2007 at 08:50:42PM +0200, Martin Michlmayr wrote: Package: apache-dev Version: 1.3.34-4.1 Usertags: ftbfs-gcc-4.3 Your package causes other packages to fail to build with GCC 4.3. Since Apache 1.3 is not intended to release with Lenny, I don't think it's worth fixing this problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411314: compressed pci.ids issues
On Fri, Feb 23, 2007 at 04:17:46AM -0800, Matt Taggart wrote: Hi Martin, I am looking at Debian pciutils bug #411314, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411314 and it appears that there are a couple problems causing compressed pci.ids files to not work as expected. The problem is that I was trying to transition the Debian package to support compressed pci.ids without breaking the packages linked against libpci. You need to delete these two lines from debian/rules: gunzip debian/pciutils/usr/share/misc/pci.ids.gz perl -pi -e 's/PCI_COMPRESSED_IDS=.*$$/PCI_COMPRESSED_IDS=/' \ debian/pciutils/usr/bin/update-pciids 2.) The file at http://pciids.sourceforge.net/v2.2/pci.ids.gz; is not gzipped. It is. Really. $ wget http://pciids.sourceforge.net/v2.2/pci.ids.gz --07:29:02-- http://pciids.sourceforge.net/v2.2/pci.ids.gz = `pci.ids.gz' Resolving pciids.sourceforge.net... 66.35.250.209 Connecting to pciids.sourceforge.net|66.35.250.209|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 129,175 (126K) [text/plain] 100%[] 129,175 163.72K/s 07:29:03 (163.26 KB/s) - `pci.ids.gz' saved [129175/129175] $ file pci.ids.gz pci.ids.gz: gzip compressed data, from Unix, last modified: Sun Feb 11 21:05:02 2007 So Martin, there's nothing to worry about here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395941: Not pciutils' fault
This is clearly a corrupt filesystem, and pciutils is just an innocent bystander. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403104: Doesn't remove renamed files
Package: git-core Version: 1:1.4.4.1-1 I just merged 2.6.20-rc1 into the 2.6.19 parisc tree as follows: git-pull origin refs/tags/v$VERS (some conflicts were created, so I edited the files to remove the conflicts) git-commit -a Now git-status shows me a lot of untracked files, eg: # include/asm-arm/arch-at91rm9200/at91rm9200_twi.h According to commit a5c474580b8b7cc8b7b2cca9a2bd27ff5c065e70 these are renamed to omit the rm9200 part of the name. I believe the git-commit should have deleted these files; it did correctly notice it was in the middle of a merge. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389415: [HELP] Bug#389415: wordnet_1:2.1-2(ia64/unstable): FTBFS: cast from pointer to int of diff size. (fwd)
On Tue, Sep 26, 2006 at 11:22:38AM +0200, Andreas Tille wrote: Probably it did not hit the mirrors, but now it should be there. (Debian verison number -2 is missleading because -1 was in experimental and than was overriden by another upload of a previous upstream version with colon versioning). Hope this helps tracking down the problem. OK, it's there now. Here's line 17 of stubs.c: static Id = $Id: stubs.c,v 1.7 2005/04/29 19:01:57 wn Exp $; which is just garbage. static const char Id[] = ... would make sense. How does that build on any architecture? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389415: [HELP] Bug#389415: wordnet_1:2.1-2(ia64/unstable): FTBFS: cast from pointer to int of diff size. (fwd)
On Tue, Sep 26, 2006 at 02:51:14PM +0200, Andreas Tille wrote: On Tue, 26 Sep 2006, Matthew Wilcox wrote: which is just garbage. static const char Id[] = ... would make sense. Well, this sounds very reasonable in dead. How does that build on any architecture? As expected fine on i386 and probably better than before on any other. So if you commit that it compiles on ia64 chances seems to be good for any other, IMHO. The thing is, it doesn't even build on i386. So I don't understand how you uploaded it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389415: [HELP] Bug#389415: wordnet_1:2.1-2(ia64/unstable): FTBFS: cast from pointer to int of diff size. (fwd)
On Mon, Sep 25, 2006 at 07:36:11PM +0200, Andreas Tille wrote: is any kind soul out there that is able to send me a patch for this problem. I have no real idea what to do. Get:1 http://http.us.debian.org unstable/main wordnet 1:2.0g-14 (tar) [5464kB] Where's the source? cc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/include/tcl8.4 -I/usr/include -I../include -I/usr/include/tcl8.4 -I/usr/include-g -Wall -O2 -c -o wishwn-stubs.o `test -f 'stubs.c' || echo './'`stubs.c stubs.c:17: warning: type defaults to 'int' in declaration of 'Id' stubs.c:17: warning: initialization makes integer from pointer without a cast stubs.c:17: error: initializer element is not computable at load time TBH, this looks like you have a misdeclaration in stubs.c. The initialization makes integer from pointer message is not the source of the problem. Need to see at least line 17 from stubs.c to be any use at all in diagnosing this problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388805: RFP: please package mod_auth_xradius
reassign 388805 libapache-mod-auth-radius retitle 388805 Please build apache 2 version kthxbye On Fri, Sep 22, 2006 at 07:10:04PM +0200, Ond??ej Sur?? wrote: retitle 388805 RFP: please package mod_auth_xradius reassign 388805 wnpp severity 388805 wishlist thank you You have filled bug at wrong package. Apache 2.X doesn't contain module for radius auth. However I was able to find mod_auth_xradius, so I am changing your bug to RFP (Request For Package) and reassigning it to our WNPP database. Yeah, but that's wrong. libapache-mod-auth-radius contains the source for an apache 2.0 module, it jsut isn't built right now. mod_auth_xradius provides high performance authentication against RFC 2865 RADIUS Servers. Features *Supports popular RADIUS Servers including OpenRADIUS, FreeRADIUS and commercial servers. *Distributed Authentication Cache using apr_memcache. *Local Authentication Cache using DBM. *Uses standard HTTP Basic Authentication, unlike mod_auth_radius which uses cookies for sessions. Kind regards, -- Ond??ej Sur?? [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387563: Typo: lspci -X should be lspci -n
On Fri, Sep 15, 2006 at 03:07:01PM +0200, Michel D?nzer wrote:
On Fri, 2006-09-15 at 08:27 +0300, Tapio Lehtonen wrote:
My lspci command does not have option -X. I think it should be -n.
The text shown to user is here:
msgid
You may wish to use the \lspci -X\ command to determine the bus location
of your PCI, AGP, or PCI-Express video card.
It should be:
msgid
You may wish to use the \lspci -n\ command to determine the bus location
of your PCI, AGP, or PCI-Express video card.
Then it should prbably also mention that lspci -n prints hex numbers,
but X takes decimal... from the pciutils changelog:
Looks like it was used after all.
The X people assured me it wasn't being used. I'm not reintroducing the
flag. I don't understand why you'd want -n.
Users of PowerPC machines, and users of any computer with multiple video
devices, should specify the BusID of the video card in an accepted
bus-specific format.
.
Examples:
.
ISA:1
PCI:0:16:0
SBUS:/[EMAIL PROTECTED],1000/[EMAIL PROTECTED],10001000/SUNW,[EMAIL
PROTECTED],80
.
For users of multi-head setups, this option will configure only one of the
heads. Further configuration will have to be done manually in the X server
configuration file, /etc/X11/xorg.conf.
.
The lspci command shows the bus location of your PCI, AGP, or PCI-Express
video card in hexadecimal, please note that it must be specified in decimal
in the configuration file.
.
When possible, this question has been pre-answered for you and you should
accept the default unless you know it doesn't work.
Or alternatively, you could include a little program that shows you all
your VGA cards. Something like this:
#!/usr/bin/perl
require shellwords.pl;
while () {
@line = shellwords($_);
next unless $line[1] =~ /VGA/;
($bus,$dev,$fn) = ($line[0] =~ /^(\S+):(\S+).(\d)/);
$bus = hex($bus);
$dev = hex($dev);
print PCI:$bus:$dev:$fn ($line[2] $line[3])\n;
}
Normally, you'd invoke it like this:
$ lspci -m | ./Xlspci
PCI:1:0:0 (nVidia Corporation NV17 [GeForce4 420 Go 32M])
But for the sake of testing ...
$ echo -e '01:1f.7 VGA compatible controller nVidia Corporation NV17
[GeForce4 420 Go 32M] -ra3 Hewlett-Packard Company tc1100 tablet\nff:10.5
VGA compatible controller nVidiot Corporation NV17 [GeForce4 420 Go 32M]
-ra3 Hewlett-Packard Company tc1100 tablet' | ./Xlspci
PCI:1:31:7 (nVidia Corporation NV17 [GeForce4 420 Go 32M])
PCI:255:16:5 (nVidiot Corporation NV17 [GeForce4 420 Go 32M])
(If you prefer not to pipe data at it, this also works:
#!/usr/bin/perl
require shellwords.pl;
open F, lspci -m| || die Could not execute lspci;
while (F) {
@line = shellwords($_);
next unless $line[1] =~ /VGA/;
($bus,$dev,$fn) = ($line[0] =~ /^(\S+):(\S+)\.(\d)/);
$bus = hex($bus);
$dev = hex($dev);
print PCI:$bus:$dev:$fn ($line[2] $line[3])\n;
}
But I prefer to be able to test it).
The advanced hacker might want to extend this to support PCI domains
(hint, use lspci -mD to see domain numbers), but I don't know what the
X syntax is for specifying domains. And we could do with a bit more
error checking ... but I think you see the idea.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386729: /etc/vim/vimrc is no longer used
reopen 386729 retitle 386729 setting foldmethod in vimrc has no effect thanks On Sun, Sep 10, 2006 at 10:18:43AM +0200, Stefano Zacchiroli wrote: It's rather disconcerting to be editing vimrc to turn off THE FUCKING ANNOYING AUTOMATIC FOLDING APPLIED TO DEBIAN CHANGELOG FILES You know, is really a pleasure to process bug report like this one, where the reporter is polite, willing to help, and informed about what's going on. You're quite welcome. It's such a pleasure to use programs which suddenly change their behaviour on upgrades and go unfixed for weeks. JFYI the FUCKING ANNOYING AUTOMATIC FOLDING has been changed in the vim version we are going to upload so that the first entry is unfolded per default. If you still think your /etc/vim/vimrc is not used please reopen the bug report. So why doesn't setting the foldmethod work? Typing :set foldmethod=marker in the file works. Why doesn't it work when I set it in /etc/vim/vimrc? It also doesn't work when I set it in ~/.vimrc. Is it being overridden by something else later? If so, I can't find it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386729: /etc/vim/vimrc is no longer used
Package: vim Version: 1:7.0-035+1 $ strace -e trace=file -o foo vi debian/changelog $ grep /etc.*vim foo stat64(/etc/vim/vimrc.local, 0xbfa9fe80) = -1 ENOENT (No such file or directory) open(/etc/vim/vimrc.local, O_RDONLY) = -1 ENOENT (No such file or directory) It's rather disconcerting to be editing vimrc to turn off THE FUCKING ANNOYING AUTOMATIC FOLDING APPLIED TO DEBIAN CHANGELOG FILES and find that it doesn't work. Not that it works if you put set foldmethod=marker in .vimrc either. But it works great if you type :set foldmethod=marker once you've been exposed to all the crappy foldedness in the file. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386750: missing dependency on curl
Package: git-core Version: 1:1.4.1.1-1 git-clone with the http method will try to use curl. So we need a dependency on curl added, please. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386495: git-apply fails to apply some patches
Package: git-core Version: 1:1.4.1.1-1 Trying to apply a patch that was created with interdiff fails ... Here's the first patch (which works) --- pciutils-2.1.11.orig/debian/dirs +++ pciutils-2.1.11/debian/dirs @@ -0,0 +1,6 @@ +usr/share/misc +usr/share/man +usr/bin +usr/lib +usr/share/lintian/overrides +bin On top of that, I try to apply this interdiff generated patch: diff -u pciutils-2.1.11/debian/dirs pciutils-2.1.11/debian/dirs --- pciutils-2.1.11/debian/dirs +++ pciutils-2.1.11/debian/dirs @@ -6,0 +7 @@ +var/lib/pciutils and git-apply says: error: debian/dirs: already exists in working directory I suspect it's confused by the '-x,0' thinking that means file does not exist rather than we have 0 context for this diff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385754: rwlocks can deadlock
Package: linux-image-2.6.17-2-parisc Version: 2.6.17-6 I found about 4 different ways to deadlock the current implementation of rwlocks on parisc. I've committed a patch to our git tree which should improve the situation, although it's obviously not had a lot of testing yet, and is subject to being improved further. You can get the commit from http://git.parisc-linux.org/?p=linux-2.6.git;a=commitdiff;h=513b38677e9bb51d32f4cb401105bf828dfcd685 I do think it's worth putting this in the Debian Etch kernel since it's a definite improvement over what's currently in there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385083: apache: Large files support in default installation doesn't work
severity 385083 wishlist merge 156972 385083 thanks Seems like you didn't read bug 156972. You can try the version of apache2 in experimental to get this problem fixed. On Tue, Aug 29, 2006 at 12:47:08AM +0200, Mr. Zdeeck wrote: Maybe I'm just misinformed, but large files support (2GB) doesn't work. For example if large file is present in the directory and the directory is listed using apache (ie mod_autoindex), the presented filesize is the real filesize modulo 2GB. I think in these days, when filesizes 2GB are getting more common (see DVD images, etc.) it's critical bug that default installation of apache in such distribution as Debian doesn't support them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383219: index.aux generation
Alioth needs to generate an index.aux file. It'd be helpful if we had an example script for doing this. Here's the script used for git.infradead.org (MIT licence, says its author): --- cut --- #!/bin/sh cd /home for a in * ; do [ -r $a/public_git ] [ ! -d /home/git/users/$a ] ln -s /home/$a/public_git /home/git/users/$a ; done cd /home/git ls */HEAD users/*/*/HEAD | grep ^[-./=+a-zA-Z0-9]*\$ | sed s:/HEAD\$:: | while read DIR ; do TREEUID=`stat -c %U $DIR` TREEUSERNAME=`grep ^$TREEUID: /etc/passwd | cut -f5 -d: | sed s/\ /+/` if [ $TREEUSERNAME = ]; then TREEUSERNAME=$TREEUID fi echo $DIR $TREEUSERNAME | sed s:/:%2F:g done /home/git/.index.aux.$$ mv /home/git/.index.aux.$$ /home/git/.index.aux --- cut --- I suspect Alioth wants something like (untested ...) cd /srv/git.debian.org/git ls */*/HEAD | grep ^[-./=+a-zA-Z0-9]*\$ | sed s:/HEAD\$:: | while read DIR ; do TREEUID=`stat -c %U $DIR` TREEUSERNAME=`XXX` if [ $TREEUSERNAME = ]; then TREEUSERNAME=$TREEUID fi echo $DIR $TREEUSERNAME | sed s:/:%2F:g done /srv/git.debian.org/.index.aux.$$ mv /srv/git.debian.org/.index.aux.$$ /srv/git.debian.org/.index.aux where XXX would be how to turn a username into the name of a user. I dunno how Alioth works; ldap or postgres db seem plausible answers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383219: Setup could be easier
Package: gitweb
Version: 1.4.1.1-1
I just finished setting up git.parisc-linux.org and installation could
have been easier. I offer you some suggestions:
First, an init script is good to have to start the git daemon running
automatically. Here's the one I'm using; I'm sure it can be improved.
diff -urpN git-core-1.4.1.1/debian/init.d git-core-willy/debian/init.d
--- git-core-1.4.1.1/debian/init.d 1969-12-31 19:00:00.0 -0500
+++ git-core-willy/debian/init.d2006-08-15 13:28:05.0 -0400
@@ -0,0 +1,32 @@
+#! /bin/sh
+set -e
+
+GITD=/usr/bin/git-daemon
+GITD_OPTS='--syslog --base-path=/var/cache'
+GITD_DIR=/var/cache/git
+
+test -x $GITD || exit 0
+
+case $1 in
+ start)
+ echo -n Starting git daemon: git-daemon
+ start-stop-daemon --start --quiet --background \
+ --pidfile /var/run/gitd.pid --make-pidfile \
+ --exec $GITD -- $GITD_OPTS $GITD_DIR
+ echo .
+ ;;
+
+ stop)
+ echo -n Stopping git daemon: git-daemon
+ start-stop-daemon --stop --quiet --oknodo \
+ --pidfile /var/run/gitd.pid
+ rm -f /var/run/gitd.pid
+ echo .
+ ;;
+
+ *)
+ echo Usage: /etc/init.d/gitd {start|stop}
+ exit 1
+esac
+
+exit 0
Then there's some more things which could go in README.Debian:
When setting up a git.example.org server, there are several things to
configure to make everything work nicely together.
1. Run a git-daemon. This allows people to use a git:// URL to access
your repos.
2. Install rsync. This allows people to use rsync:// URLs to access your
repositories. You then need to add a stanza to /etc/rsyncd.conf that looks
like this:
[git]
path = /var/cache/git
readonly = yes
Now git-clone rsync://git.example.org/git/repo will work.
3. Configure an apache virtual server (XXX: other webservers with virtual
hosting abilities?). Add a stanza to your apache configuration that
looks like this:
VirtualHost *:80
ServerName git.example.org
ServerAdmin [EMAIL PROTECTED]
HeaderName HEADER
# bogus but safe DocumentRoot
DocumentRoot /var/cache/git
ErrorLog /var/log/apache-ssl/git.example.org-error.log
CustomLog /var/log/apache-ssl/git.example.org-access.log combined
Alias /robots.txt /var/www/cvs.robots.txt
Alias /gitweb.css /usr/share/doc/gitweb/gitweb.css
Alias /git /var/git
ScriptAlias / /usr/lib/cgi-bin/gitweb.cgi
RedirectMatch permanent ^/~(.*)$ http://example.org/~$1;
/VirtualHost
Now git.example.org will display a list of repositories, and people can
git-clone http://git.example.org/git/repo.
I think that was about all of the things I had a problem with. Hope this
is helpful.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280174: still occurring
We just had another data corruption with 1.12.13-3, prompting us to switch to git from CVS. We had been running with some pre-sarge version of cvs pinned, but decided to try the current etch version of CVS. Bad idea. Oh well. Sucks to be us. Probably worth leaving this bug report open though, since I think it would actually be better to ship etch without CVS than to ship it with a version that has known data corruption problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380032: [Pkg-pciutils-discuss] Bug#380032: FTBFS on hurd-i386: Unconditional use of MAXPATHLEN
On Thu, Jul 27, 2006 at 12:11:52PM +0200, Thomas Schwinge wrote: On Thu, Jul 27, 2006 at 11:56:59AM +0200, Martin Mares wrote: As briefly explained on the hurd-devel-debian page[1], unconditional use of PATH_MAX is a POSIX incompatibility. Err, is there any sense in trying to compile pcimodules on the Hurd? It's a program specific to Linux (and it isn't a part of the official pciutils at all, anyway). If that's the case, then yes, please disable it for ```uname -s` = GNU'' or the Debian architecture `hurd-i386' (or even better enable it only for the supported ones?). I'm hoping to get rid of it entirely before etch releases. AFAIK we don't actually use it anywhere. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379982: Misuse of alternatives
Package: git Version: 4.3.20-8 Severity: serious Justification: Policy 10.1 10.1 Binaries Two different packages must not install programs with different functionality but with the same filenames. (The case of two programs having the same functionality but different implementations is handled via alternatives or the Conflicts mechanism. See Maintainer Scripts, Section 3.9 and Conflicting binary packages - Conflicts, Section 7.3 respectively.) If this case happens, one of the programs must be renamed. The maintainers should report this to the debian-devel mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, both programs must be renamed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379407: I/O access on GNU/Hurd
On Sun, Jul 23, 2006 at 01:36:46PM +0200, Thomas Schwinge wrote: Hello! Hi! Thanks for the patch. diff -ru pciutils-2.2.1.orig/lib/Makefile pciutils-2.2.1/lib/Makefile --- pciutils-2.2.1.orig/lib/Makefile 2004-08-13 22:29:06.0 +0200 +++ pciutils-2.2.1/lib/Makefile 2006-01-20 01:53:05.0 +0100 @@ -45,6 +45,10 @@ PCILIB=libpciutils.a endif +ifdef PCI_OS_GNU +CFLAGS += -D_GNU_SOURCE +endif Do you need to touch the Makefile? Would it be enough to instead do ... +++ pciutils-2.2.1/lib/i386-io-hurd.h 2006-01-20 02:08:58.0 +0100 #include sys/io.h +#define _GNU_SOURCE instead? I'm also a little concerned that you guys are still using the ioport routines. This config space access method doesn't support PCI domains and doesn't support extended config space. I hope someone's working on some mechanism for Hurd to access MMCONFIG (for example) regions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325650: debug output
On Tue, Jul 11, 2006 at 09:31:04AM +0200, Marco d'Itri wrote: On Jul 11, Matthew Wilcox [EMAIL PROTECTED] wrote: I don't know why Marco changed the location of MAKEDEV; it was right before: Because if makedev is not installed but udev is, /sbin/MAKEDEV will not exist. Most other packages use /dev/MAKEDEV, but probably ppp is the only one which pbuilder tries to install. But ... makedev is Priority: required, even in sid. And Policy says that removing a package marked as required may cause your system to become totally broken and you may not even be able to use dpkg to put things back, so only do so if you know what you are doing. udev is still merely optional. Usually I think this would be solved with a pre-depend, but obviously we do not want to use one here. I think that just text -x MAKEDEV is an acceptable solution. Any other comments? I think it can always rely on /sbin/MAKEDEV being there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325650: debug output
On Tue, Jul 11, 2006 at 01:40:01PM +0200, Marco d'Itri wrote: On Jul 11, Matthew Wilcox [EMAIL PROTECTED] wrote: But ... makedev is Priority: required, even in sid. And Policy says that removing a package marked as required may cause your system to become totally broken and you may not even be able to use dpkg to put things back, so only do so if you know what you are doing. udev is still merely optional. It's time to start making the changes needed in a world where makedev is optional and udev is required. That seems premature. Right now, ppp is broken and won't install on sid because of this change. It would have worked fine with /sbin/MAKEDEV because makedev (being required) is configured and installed before ppp. So could you revert this change and use /sbin/MAKEDEV instead for the moment, then work with whoever needs to care to make udev a required package? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325650: debug output
# This is actually a bad bug to be reopening, there's two bugs mixed in # together; the second reporter confused the symptoms. # However, Matt and Bob are already looking at this bug, so there's some # benefit. reopen 325650 reassign 325650 ppp thanks Looks like a bug in ppp's postinst to me: O: Setting up ppp (2.4.4rel-1) ... P: Configuring package ppp D: Updating ppp to status 3 O: /var/lib/dpkg/info/ppp.postinst: line 41: ./MAKEDEV: No such file or directory O: dpkg: error processing ppp (--configure): O: subprocess post-installation script returned error exit status 1 O: dpkg: dependency problems prevent configuration of pppconfig: O: pppconfig depends on ppp (= 2.3.7); however: O: Package ppp is not configured yet. O: dpkg: error processing pppconfig (--configure): O: dependency problems - leaving unconfigured O: dpkg: dependency problems prevent configuration of pppoeconf: O: pppoeconf depends on ppp (= 2.4.2+20040428-2) | pppoe (= 3.0); however: O: Package ppp is not configured yet. O: Package pppoe is not installed. O: pppoeconf depends on ppp (= 2.4.1.uus2-4); however: O: Package ppp is not configured yet. O: dpkg: error processing pppoeconf (--configure): O: dependency problems - leaving unconfigured O: Errors were encountered while processing: O: ppp O: pppconfig O: pppoeconf O: E: Sub-process /usr/bin/dpkg returned an error code (1) D: Return code: 25600 - Aborting with an error - cleaning the build env - removing directory /var/cache/pbuilder/build//18172 and its subdirectories ppp's postinst script seems to have changed between 2.4.4b1-1.diff.gz and ppp_2.4.4rel-1.diff.gz from: # create /dev/ppp if we are not using devfs if [ ! -c /dev/ppp ]; then cd /dev /sbin/MAKEDEV ppp fi to: # create /dev/ppp if we are not using udev if [ ! -c /dev/ppp ]; then cd /dev ./MAKEDEV ppp fi I don't know why Marco changed the location of MAKEDEV; it was right before: $ dpkg -S MAKEDEV makedev: /sbin/MAKEDEV -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335665: kudzu patch to not use PCI_FILL_CLASS
On Tue, Jun 27, 2006 at 03:24:23PM +0200, Martin Mares wrote:
Hello!
Martin, now that we have a reason, what do you think to this patch?
Applied :)
Thanks!
(Available in the GIT repository and also as a -pre2.)
About that -pre2 tarball ...
- It adds lspci.c.orig and lib/pci.h.orig which I suspect are just
remnants from patch(1).
- You don't seem to have included the patch I sent a few weeks ago to
exclude git directories; here it is again:
Index: maint/release.pm
===
RCS file: /cvsroot/pkg-pciutils/pciutils/maint/release.pm,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 release.pm
--- maint/release.pm13 Mar 2006 05:00:54 - 1.1.1.1
+++ maint/release.pm6 Jun 2006 12:10:39 -
@@ -15,7 +15,7 @@ sub new($$) {
PACKAGE = $basename,
rules = [
# p=preprocess, s=subst, -=discard
- '(^|/)(CVS|\.arch-ids|{arch}|tmp)/' = '-',
+ '(^|/)(CVS|\.arch-ids|{arch}|tmp|\.git)/' = '-',
'\.(lsm|spec)$' = 'ps',
'(^|/)README$' = 's'
],
Although I now wonder if you also want to exclude .orig files too:
+ '(^|/)(CVS|\.arch-ids|{arch}|tmp|.git|.*\.orig)$' =
'-',
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328318: [Pkg-pciutils-discuss] Re: Bug#328318: pciutils: why not centralize pci.ids?
On Thu, Jun 15, 2006 at 10:05:07AM +0200, Cristian Ionescu-Idbohrn wrote: On Wed, 14 Jun 2006, Matt Taggart wrote: Have you tried /usr/bin/update-pciids from the pciutils packages? :) No, I did't :( Another one I missed. Thanks for pointing that out. The drivers in the Linux kernel all have their own lists of PCI ids that they support. I don't know what kudzu/etc do, but I didn't think their ability to support hardware was based on how up to date their pci.ids was. I suppose (didn't look into the details) discover, hotplug, udev, etc. have their own way too. They don't rely on pci.ids for naming, no. Anyway we'll try to keep it as up to date as possible. After a stable release happens I suppose we could update via a stable update if needed, but we'd need to have a good reason. Have a look at the 'hinfo' package. When installing, it offers to setup a cron-job. I don't think this is a good idea. It's going to put a lot of load on the sf.net webservers to have a few million Debian machines all trying to update at the same time. It also messes up debsums (and no, I looked at faking out debsums ... that's not a good idea either). If we're going to update pci.ids, I think we should use volatile for doing so. Maybe we should split out pci.ids from pciutils for that, since it would then be binary-all. But I'm not too keen to proliferate packages unnecessarily. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335665: kudzu patch to not use PCI_FILL_CLASS
PCI_FILL_CLASS is a RH specific patch to pciutils that upstream isn't
interested in. This patch removes uses of that feature from kudzu which
allows current CVS to compile on a system without RH patches to pciutils.
By the way, the main kudzu page at http://rhlinux.redhat.com/kudzu/
has two broken links on it; the rawhide link and the cvsweb link.
Index: pci.c
===
RCS file: /usr/local/CVS/kudzu/pci.c,v
retrieving revision 1.140
diff -u -p -r1.140 pci.c
--- pci.c 28 Feb 2006 19:49:56 - 1.140
+++ pci.c 13 Jun 2006 16:25:57 -
@@ -286,7 +286,7 @@ static int isDisabled(struct pci_dev *p,
#endif
unsigned int devtype, command;
- devtype = p-device_class;
+ devtype = pci_read_word(p, PCI_CLASS_DEVICE);
if (p-irq || pciToKudzu(devtype) != CLASS_VIDEO) {
return 0;
}
@@ -416,7 +416,7 @@ struct device * pciProbe(enum deviceClas
subvend = config[PCI_SUBSYSTEM_VENDOR_ID+1] 8 |
config[PCI_SUBSYSTEM_VENDOR_ID];
subdev = config[PCI_SUBSYSTEM_ID+1] 8 |
config[PCI_SUBSYSTEM_ID];
}
- pci_fill_info(p, PCI_FILL_IDENT | PCI_FILL_CLASS | PCI_FILL_IRQ
| PCI_FILL_BASES | PCI_FILL_ROM_BASE | PCI_FILL_SIZES);
+ pci_fill_info(p, PCI_FILL_IDENT | PCI_FILL_IRQ | PCI_FILL_BASES
| PCI_FILL_ROM_BASE | PCI_FILL_SIZES);
bustype = PCI_NORMAL;
for (bridgenum=0; cardbus_bridges[bridgenum]; bridgenum++) {
if (p-bus == cardbus_bridges[bridgenum])
@@ -428,14 +428,14 @@ struct device * pciProbe(enum deviceClas
dev-subVendorId = subvend;
dev-subDeviceId = subdev;
dev-pciType = bustype;
+ devtype = pci_read_word(p, PCI_CLASS_DEVICE);
asprintf(t,v%08Xd%08Xsv%08Xsd%08Xbc%02Xsc%02Xi%02x,p-vendor_id,p-device_id,
-subvend, subdev,(u_int8_t)(p-device_class
8),(u_int8_t)(p-device_class),config[PCI_CLASS_PROG]);
+subvend, subdev, devtype 8, devtype 0xff,
config[PCI_CLASS_PROG]);
drv = aliasSearch(aliases, pci, t);
x_drv = aliasSearch(aliases, pcivideo, t);
free(t);
if (drv)
dev-driver = strdup(drv);
- devtype = p-device_class;
if (x_drv) {
dev-classprivate = strdup(x_drv);
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335665: kudzu patch to not use PCI_FILL_CLASS
On Tue, Jun 13, 2006 at 10:36:33AM -0600, Matthew Wilcox wrote: PCI_FILL_CLASS is a RH specific patch to pciutils that upstream isn't interested in. This patch removes uses of that feature from kudzu which allows current CVS to compile on a system without RH patches to pciutils. My apologies to everyone else involved; I had no idea that redhat-devel-list was a closed list. I recommend that you drop that list from the cc in order to avoid those annoying we think you're a spammer emails. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335665: kudzu patch to not use PCI_FILL_CLASS
On Tue, Jun 13, 2006 at 07:03:18PM +0200, No?l K?the wrote: Am Dienstag, den 13.06.2006, 12:54 -0400 schrieb Bill Nottingham: Aside from that... what are you using kudzu for? You shouldn't. (it basically is sticking around in RH/Fedora until the installer can be ported away from it.) We packaged kudzu for Debian because Knoppix Live CD uses kudzu for hardware detection. Looks like knoppix 5 is still using it ... ii kudzu-knoppix-dev1.1.3-4 Hardware detecting library ii kudzu-knoppix-vesa 1.1.3-4 Hardware detecting library perhaps they need to be warned to stop using it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335665: kudzu patch to not use PCI_FILL_CLASS
On Tue, Jun 13, 2006 at 12:54:37PM -0400, Bill Nottingham wrote:
The reason we do this is because the class, vendor, and device ID fields in
sysfs are correct with respect to applied PCI quirks. The config data (at
least at the point we added the patch) is not. (Hooray for PPC.)
Aha. That makes sense; I suspect most PCI devices don't allow the OS to
write that field ;-) I didn't like the 'read it byte-by-byte' part of
the patch, so I changed it to pci_get_word().
Martin, now that we have a reason, what do you think to this patch?
--- pciutils-2.2.1/lib/sysfs.c.devicetype 2005-09-21 07:51:00.0
-0400
+++ pciutils-2.2.1/lib/sysfs.c 2005-12-13 17:02:12.0 -0500
@@ -164,7 +164,6 @@
sysfs_get_resources(d);
d-irq = sysfs_get_value(d, irq);
d-known_fields = PCI_FILL_IRQ | PCI_FILL_BASES | PCI_FILL_ROM_BASE |
PCI_FILL_SIZES;
-#if 0
/*
* We prefer reading these from the config registers, it's faster.
* However, it would be possible and maybe even useful to hack the
kernel
@@ -173,8 +172,8 @@
*/
d-vendor_id = sysfs_get_value(d, vendor);
d-device_id = sysfs_get_value(d, device);
- d-known_fields |= PCI_FILL_IDENT;
-#endif
+ d-device_class = sysfs_get_value(d, class) 8;
+ d-known_fields |= PCI_FILL_IDENT | PCI_FILL_CLASS;
}
pci_link_dev(a, d);
}
--- pciutils-2.2.1/lib/pci.h.devicetype 2005-09-10 08:10:54.0 -0400
+++ pciutils-2.2.1/lib/pci.h2005-12-13 17:02:12.0 -0500
@@ -84,6 +84,7 @@
/* These fields are set by pci_fill_info() */
int known_fields;/* Set of info fields already known */
u16 vendor_id, device_id;/* Identity of the device */
+ u16 device_class;/* PCI device class */
int irq; /* IRQ number */
pciaddr_t base_addr[6]; /* Base addresses */
pciaddr_t size[6]; /* Region sizes */
@@ -118,6 +119,7 @@
#define PCI_FILL_BASES 4
#define PCI_FILL_ROM_BASE 8
#define PCI_FILL_SIZES 16
+#define PCI_FILL_CLASS 32
#define PCI_FILL_RESCAN0x1
void pci_setup_cache(struct pci_dev *, u8 *cache, int len);
--- pciutils-2.2.1/lib/generic.c.devicetype 2004-08-13 16:15:23.0
-0400
+++ pciutils-2.2.1/lib/generic.c2005-12-13 17:02:12.0 -0500
@@ -46,7 +46,8 @@
d-func = t-func;
d-vendor_id = vd 0x;
d-device_id = vd 16U;
- d-known_fields = PCI_FILL_IDENT;
+ d-device_class = pci_read_word(t, PCI_CLASS_DEVICE);
+ d-known_fields = PCI_FILL_IDENT | PCI_FILL_CLASS;
d-hdrtype = ht;
pci_link_dev(a, d);
switch (ht)
@@ -86,6 +87,8 @@
d-vendor_id = pci_read_word(d, PCI_VENDOR_ID);
d-device_id = pci_read_word(d, PCI_DEVICE_ID);
}
+ if (flags PCI_FILL_CLASS)
+ d-device_class = pci_read_word(d, PCI_CLASS_DEVICE);
if (flags PCI_FILL_IRQ)
d-irq = pci_read_byte(d, PCI_INTERRUPT_LINE);
if (flags PCI_FILL_BASES)
--- pciutils-2.2.1/lib/example.c.devicetype 2000-03-09 03:38:33.0
-0500
+++ pciutils-2.2.1/lib/example.c2005-12-13 17:02:12.0 -0500
@@ -21,7 +21,7 @@
pci_scan_bus(pacc); /* We want to get the list of devices */
for(dev=pacc-devices; dev; dev=dev-next) /* Iterate over all devices */
{
- pci_fill_info(dev, PCI_FILL_IDENT | PCI_FILL_BASES); /* Fill in
header info we need */
+ pci_fill_info(dev, PCI_FILL_IDENT | PCI_FILL_BASES | PCI_FILL_CLASS);
/* Fill in header info we need */
c = pci_read_word(dev, PCI_CLASS_DEVICE);/* Read config register
directly */
printf(%02x:%02x.%d vendor=%04x device=%04x class=%04x irq=%d
base0=%lx\n,
dev-bus, dev-dev, dev-func, dev-vendor_id, dev-device_id,
--- pciutils-2.2.1/lspci.c.devicetype 2005-11-26 06:48:29.0 -0500
+++ pciutils-2.2.1/lspci.c 2005-12-13 17:04:39.0 -0500
@@ -123,7 +123,7 @@
d-config_cached += 64;
}
pci_setup_cache(p, d-config, d-config_cached);
- pci_fill_info(p, PCI_FILL_IDENT | PCI_FILL_IRQ | PCI_FILL_BASES |
PCI_FILL_ROM_BASE | PCI_FILL_SIZES);
+ pci_fill_info(p, PCI_FILL_IDENT | PCI_FILL_CLASS | PCI_FILL_IRQ |
PCI_FILL_BASES | PCI_FILL_ROM_BASE | PCI_FILL_SIZES);
return d;
}
@@ -255,7 +255,7 @@
printf( %s: %s,
pci_lookup_name(pacc, classbuf, sizeof(classbuf),
PCI_LOOKUP_CLASS,
-get_conf_word(d, PCI_CLASS_DEVICE)),
+p-device_class),
pci_lookup_name(pacc, devbuf, sizeof(devbuf),
PCI_LOOKUP_VENDOR | PCI_LOOKUP_DEVICE,
p-vendor_id, p-device_id));
@@ -267,7 +267,7 @@
c = get_conf_byte(d, PCI_CLASS_PROG);
x = pci_lookup_name(pacc, devbuf, sizeof(devbuf),
Bug#268031: Upstream
tags 268031 + fixed-upstream thanks On Fri, Jun 02, 2006 at 11:40:32PM +0200, David N. Welton wrote: Looks good to me. Thankyou! Martin liked the idea, but not the implementation, so he redid it. It's upstream as version 2.2.4-pre1. I'm waiting on my co-maintainers to bless the current 2.2.1-1 package, then we'll upload it to unstable, wait for it to get into testing, then upload 2.2.4-pre1 (or whatever makes sense at that time). So I would expect to see this in unstable in a couple of weeks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369956: Radeon RC410 / Xpress 200 broken
Package: xserver-xorg Version: 6.9.0.dfsg.1-6 I just bought myself a new motherboard (lspci output below) and tried installing the 20060528 d-i snapshot on it. Unfortunately, X doesn't start correctly. The screen has thin horizontal lines on it and the mouse pointer is a block of gibberish a centimetre or two in width. I'm attaching the Xorg.0.log and the xorg.conf (very boring, as created by debian-installer). Let me know if there's any more info that would be useful. I could take a picture of the display corruption if that'd be helpful. Also, when I switch back to text mode after starting X, it has turned the text display into character-sized blocks of coloured, sometimes flashing gibberish. 00:00.0 Host bridge: ATI Technologies Inc: Unknown device 5a33 (rev 01) 00:01.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge 00:19.0 PCI bridge: ALi Corporation M5249 HTT to PCI Bridge 00:1b.0 Ethernet controller: ALi Corporation M5263 Ethernet Controller (rev 50) 00:1c.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) 00:1c.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) 00:1c.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) 00:1c.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01) 00:1e.0 ISA bridge: ALi Corporation PCI to LPC Controller (rev 31) 00:1e.1 Bridge: ALi Corporation M7101 Power Management Controller [PMU] 00:1f.0 IDE interface: ALi Corporation M5229 IDE (rev c7) 01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200] 02:13.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46) 02:14.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 11) 03:08.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01) 03:09.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder (rev 01) # xorg.conf (Xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/xorg.conf /etc/X11/xorg.conf.custom # md5sum /etc/X11/xorg.conf /var/lib/xfree86/xorg.conf.md5sum # dpkg-reconfigure xserver-xorg Section Files FontPathunix/:7100# local font server # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi/:unscaled FontPath/usr/lib/X11/fonts/75dpi/:unscaled FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/CID FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module Loadbitmap Loaddbe Loadddc Loaddri Loadevdev Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadtype1 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section Device Identifier ATI Technologies, Inc. Radeon Xpress 200 (RC410) Driver ati BusID PCI:1:5:0 EndSection Section Monitor Identifier Generic Monitor Option DPMS HorizSync 30-75 VertRefresh 50-85 EndSection Section Screen Identifier Default Screen Device ATI Technologies, Inc. Radeon Xpress 200 (RC410) Monitor Generic Monitor DefaultDepth24 SubSection Display Depth 1 Modes 1600x1200 1280x1024 640x480 EndSubSection SubSection Display Depth 4 Modes 1600x1200 1280x1024 640x480 EndSubSection SubSection Display
Bug#369751: waiting for NEW processing
Anton, as soon as libpci2 gets out of NEW, we'll be uploading 2.2.1-1 which is actually pretty close to 2.2.3. I've been testing on a machine with domains, and I know it's working ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#268031: How about this?
How does this output look (from my laptop):
$ ./lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation 82855PM Processor to I/O
Controller [8086:3340] (rev 03)
00:01.0 PCI bridge [0604]: Intel Corporation 82855PM Processor to AGP
Controller [8086:3341] (rev 03)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 01)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 01)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 01)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2
EHCI Controller [8086:24cd] (rev 01)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge
[8086:2448] (rev 81)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801DBM (ICH4-M) LPC Interface
Bridge [8086:24cc] (rev 01)
00:1f.1 IDE interface [0101]: Intel Corporation 82801DBM (ICH4-M) IDE
Controller [8086:24ca] (rev 01)
00:1f.3 SMBus [0c05]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
SMBus Controller [8086:24c3] (rev 01)
00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] (rev 01)
00:1f.6 Modem [0703]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
AC'97 Modem Controller [8086:24c6] (rev 01)
01:00.0 VGA compatible controller [0300]: nVidia Corporation NV17 [GeForce4 420
Go 32M] [10de:0176] (rev a3)
02:05.0 Network controller [0280]: Intel Corporation PRO/Wireless LAN 2100 3B
Mini PCI Adapter [8086:1043] (rev 04)
02:06.0 CardBus bridge [0607]: Texas Instruments PCI1620 PC Card Controller
[104c:ac54] (rev 01)
02:06.1 CardBus bridge [0607]: Texas Instruments PCI1620 PC Card Controller
[104c:ac54] (rev 01)
02:06.2 System peripheral [0880]: Texas Instruments PCI1620 Firmware Loading
Function [104c:8201] (rev 01)
02:07.0 Ethernet controller [0200]: Broadcom Corporation BCM4401 100Base-T
[14e4:4401] (rev 01)
$ ./lspci -nnvvvs 02:07.0
02:07.0 Ethernet controller [0200]: Broadcom Corporation BCM4401 100Base-T
[14e4:4401] (rev 01)
Subsystem: Hewlett-Packard Company [103c] Unknown device 08b0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort+ TAbort-
MAbort- SERR- PERR-
Latency: 64
Interrupt: pin A routed to IRQ 12
Region 0: Memory at e000 (32-bit, non-prefetchable) [size=8K]
[virtual] Expansion ROM at 5400 [disabled] [size=16K]
Capabilities: access denied
Here's the patch that does this; if it matches your needs, I'll talk to
Martin Mares about including it.
Index: lspci.c
===
RCS file: /cvsroot/pkg-pciutils/pciutils/lspci.c,v
retrieving revision 1.8
diff -u -p -r1.8 lspci.c
--- lspci.c 5 May 2006 19:39:37 - 1.8
+++ lspci.c 2 Jun 2006 18:19:06 -
@@ -2293,7 +2293,7 @@ main(int argc, char **argv)
switch (i)
{
case 'n':
- pacc-numeric_ids = 1;
+ pacc-numeric_ids++;
break;
case 'v':
verbose++;
Index: lib/names.c
===
RCS file: /cvsroot/pkg-pciutils/pciutils/lib/names.c,v
retrieving revision 1.5
diff -u -p -r1.5 names.c
--- lib/names.c 21 Mar 2006 19:44:22 - 1.5
+++ lib/names.c 2 Jun 2006 18:19:06 -
@@ -326,8 +326,8 @@ pci_lookup_name(struct pci_access *a, ch
va_start(args, flags);
- num = 0;
- if ((flags PCI_LOOKUP_NUMERIC) || a-numeric_ids)
+ num = a-numeric_ids;
+ if ((flags PCI_LOOKUP_NUMERIC) || a-numeric_ids == 1)
{
flags = ~PCI_LOOKUP_NUMERIC;
num = 1;
@@ -352,20 +352,30 @@ pci_lookup_name(struct pci_access *a, ch
{
case PCI_LOOKUP_VENDOR:
iv = va_arg(args, int);
- if (num)
+ if (num == 1)
res = snprintf(buf, size, %04x, iv);
else if (v = id_lookup(a, ID_VENDOR, iv, 0, 0, 0))
- return v-name;
+{
+ if (num)
+ res = snprintf(buf, size, %s [%04x], v-name, iv);
+ else
+ return v-name;
+}
else
res = snprintf(buf, size, Unknown vendor %04x, iv);
break;
case PCI_LOOKUP_DEVICE:
iv = va_arg(args, int);
id = va_arg(args, int);
- if (num)
+ if (num == 1)
res = snprintf(buf, size, %04x, id);
else if (d = id_lookup(a, ID_DEVICE, iv, id, 0, 0))
- return d-name;
+{
+ if (num)
+ res = snprintf(buf, size, %s [%04x], d-name, id);
+ else
+ return d-name;
+ }
else if (synth)
res = snprintf(buf, size, Unknown device %04x, id);
else
@@ -374,28 +384,46 @@ pci_lookup_name(struct pci_access *a, ch
case PCI_LOOKUP_VENDOR |
Bug#278479: reverted
Hi. I've reverted this change as I believe it's based on a flawed interpretation of the FHS. Please see http://sourceforge.net/mailarchive/forum.php?thread_id=10004256forum_id=3128 The comment about debsums indicating that the file has changed is entirely correct. That's called working as designed: debsums is intended primarily as a way of determining what installed files have been locally modified by the administrator or damaged by media errors and is of limited use as a security tool. Running update-pciids counts as 'locally modified by the administrator' to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363441: It's too easy to quit
Package: sgt-puzzles Version: 6526-1 Not psychologically, perhaps, but physically. If you're, say, playing Solo and in attempting to press '1', miss and press 'q' instead, the game you were in the middle of evaporates with no chance to confirm or save. This can be quite traumatising. I see several possible solutions. 1. If the game is in progress, a dialog box could be opened to confirm quit. 2. An autosave feature could be added, like vim. This would also protect against power cuts. 3. The key to quit the game could be changed from q to, say, control-q. This would also match other games, such as Gnome Tetravex. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241223: apache2.2 is available...
On Tue, Apr 11, 2006 at 09:10:35PM -0700, [EMAIL PROTECTED] wrote: Apache 2.2 has been released since November 2005... O RLY? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344072 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347877: Reversion of lspci -m changes
I have to say I really, really wish remco hadn't accepted this patch. Changing the *machine readable* option of lspci makes Debian incompatible with every other distro. This one is definitely being reverted before we get to 2.2.1-1. Sorry, no discussion on this one. It actually makes it *IMPOSSIBLE* to machine-parse, unless you use -n as well. Look: $ lspci -m 00:00.0 Host bridge Intel Corporation 82855PM Processor to I/O Controller 03 00 Hewlett-Packard Company Unknown device 08b0 I mean, wtf? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355146: Help no longer works
Package: sgt-puzzles Version: 6526-1 The help menu options no longer work. Running loopy under strace shows: stat64(/usr/share/sgt-puzzles/gnome/help/Loopy/Loopy, 0xbfde686c) = -1 ENOENT (No such file or directory) stat64(/usr/share/gnome/help/Loopy, 0xbfde686c) = -1 ENOENT (No such file or directory) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353942: SATA CD-ROM drives unnecessarily hard to get working
On Wed, Feb 22, 2006 at 04:45:37PM +0100, Frans Pop wrote: On Wednesday 22 February 2006 04:54, Matthew Wilcox wrote: If this doesn't get fixed, the workaround needs to be documented. I expect Fujitsu won't be the only people shipping SATA CD-ROMs during the lifecycle of Etch. We expect Etch to ship with 2.6.16 or even later and have been told this SATA ATAPI support should be enabled by default in 2.6.16. So this is a temporary problem only. willy jgarzik: apparently you promised to turn on sata atapi by default in 2.6.16 jgarzik willy: hmmm, I guess its 2.6.17 now Possibly the kernel team need to make this change themselves. As you say, Joey's decided to treat this as an example of another kind of bug now, but I want you to be aware that 2.6.16 won't have this on by default. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353983: eth* network interfaces change after install
Package: debian-installer Version: 21-Feb-2006 Hardware: Fujitsu P7120 Lifebook This model has an ieee1394 connector, so we autoload the eth1394 module during the first boot, and this is loaded before the 8139too module that drives the built-in ethernet connector. So eth1394 gets eth0 and 8139too gets eth1. After rebooting, the modules are loaded in the opposite order, so 8139too gets eth0 and eth1394 gets eth1. This means the configured networking doesn't work automatically. You have to edit /etc/network/interfaces to make it work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353942: sigh, udev..
On Wed, Feb 22, 2006 at 01:55:16PM -0500, Joey Hess wrote: Another way to do this might be to tag parameters on the command line with the module they apply to. Matthew Wilcox suggests in this bug report that libata.atapi_enabled=1 will send that parameter to the libata driver if it's compiled in; I wasn't aware of this syntax before. Is it documented somewhere (kernel source file is fine ;-) and does it work for other module parameters? Seems we could just parse that if so. It was introduced as part of the module_param work that Rusty did. If you look at Documentation/kernel-parameters.txt from a 2.6 kernel, you'll see it documented there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353480: [parisc-linux] Re: Bug#353480: yaird: [hppa] /dev/sd* device nodes not created and eth0 not enabled
On Tue, Feb 21, 2006 at 06:00:43PM +0100, Joel Soete wrote: Just a small update to confirm that works fine: INIT: version 2.86 booting Starting the hotplug events dispatcher: udevd. Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated... done (timeout). How is timing out works fine? Works better, sure, but why is it timing out? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353942: SATA CD-ROM drives unnecessarily hard to get working
Package: debian-installer Version: 21-Feb-2006 My wife just got a shiny new Fujitsu Lifebook P7120 (thanks to Joey Hess raving about it on Planet the other day). I downloaded the latest nightly build for Etch and tried to install it. This far too much fun, thanks to the SATA CD-ROM drive. You see, to enable support for SATA CD-ROM drives, you have to set the libata module parameter 'atapi_enabled=1'. If libata were built in, that would be the simple matter of passing 'libata.atapi_enabled=1'. But it's a module, and even in expert mode, libata is loaded before you get to a shell. Busybox doesn't seem to have an rmmod command, so you can't unload it and then load it with the option specified. So you have to boot with BOOT_DEBUG=3 to get a shell prompt where you 'modprobe libata atapi_enabled=1'. If this doesn't get fixed, the workaround needs to be documented. I expect Fujitsu won't be the only people shipping SATA CD-ROMs during the lifecycle of Etch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344550: Irregular periods broken
Package: mencal
Version: 2.3-5
Seems the patch I supplied before was rather buggy, so I've rewritten
it. The patch below works much better.
I'm a little confused why you created a new program rather than simply
patch mencal? If someone's only using one 'start' (or even no start
command), it works the same way it always did.
--- 2.3-5/mencal-2.3/debian/mencalnreg 2005-12-23 09:45:46.937783465 -0500
+++ ./mencalnreg2005-12-23 11:20:40.742638212 -0500
@@ -194,46 +194,57 @@
}
}
+ sub getnext {
+my $self = shift;
+my $first = shift;
+my $starts = $self-{'start'};
+my $length = $self-{'length'} * 24 * 3600;
+my $n_s = scalar @{$starts};
+my $best;
+
+if (($n_s 0) (date2sec($starts-[0]) = $first)
+($first = date2sec($starts-[($n_s - 1)]))) {
+ foreach (@{$starts}) {
+$best = date2sec($_);
+last if $best = $first;
+ }
+ return $best;
+}
+
+if ($n_s == 0) {
+ $best = strftime %Y%m%d, localtime;
+} elsif ($first date2sec($starts-[0])) {
+ $best = date2sec($starts-[0]);
+} else {
+ $best = date2sec($starts-[$n_s - 1]);
+}
+
+while ($best ($first + $length)) {
+ $best -= $length;
+}
+
+while ($best $first) {
+ $best += $length;
+}
+
+return $best;
+ }
+
sub getdays {
my $self = shift;
my ($year, $month) = (shift, shift);
-my $starts = $self-{'start'};
my $duration = $self-{'duration'} * 24 * 3600;
-my $length = $self-{'length'} * 24 * 3600;
$self-{'days'} = '#';
my $month_first = mktime(0, 0, 0, 1, ($month-1), ($year-1900));
my $month_next = mktime(0, 0, 0, 1, $month, ($year-1900));
my $first_interesting = $month_first - $duration;
-if (scalar @{$starts} == 0) {
- push @{$starts},strftime %Y%m%d, localtime;
-}
-my $j = 0;
-while (($first_interesting date2sec($starts-[$j]))
-(($j + 1) scalar @{$starts})) {
- $j++;
-}
-
-my $actday = date2sec($starts-[$j]);
-
-# extrapolate, if necessary.
-while ($actday = $month_first) {
- $actday -= $length;
-}
-while (($actday + $length) $month_first) {
- $actday += $length;
-}
+my $actday = $self-getnext($first_interesting);
while ($actday $month_next) {
markdays($self, $month_first, $month_next, $actday, $duration);
- if ((($j + 1) scalar @{$starts})
- ($actday = date2sec($starts-[0]))) {
-$j++;
- $actday = date2sec($starts-[$j]);
- } else {
-$actday += $length;
- }
+ $actday = $self-getnext($actday + $duration + 1);
}
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330282: [Pkg-db-devel] Bug#330282: libdb3++c102: Needs C++ transition
On Tue, Sep 27, 2005 at 10:36:30AM +0200, Daniel Schepler wrote: Package: libdb3++c102 Severity: important Version: 3.2.9-22 As the subject says, the C++ interface library to libdb3 still needs to be transitioned to the new C++ ABI. I think we should probably just stop building it. Nothing uses it. (apt-cache showpkg libdb3++c102 to convince yourself) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329888: reassign
reassign 329888 linux-2.6 tags 329888 +patch thanks For the next release, please apply this patch: http://cvs.parisc-linux.org/linux-2.6/arch/parisc/kernel/pacache.S?r1=1.19r2=1.20makepatch=1diff_format=u It fixes a latent kernel bug that is now flagged by recent binutils changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329888: [parisc-linux] binutils breaks hppa kernel build,
On Sat, Sep 24, 2005 at 09:27:22PM -0400, John David Anglin wrote: The last fic opcode entry is wrong. It's using the wrong instruction format, the mask is wrong, pa10 is wrong, etc. I don't think we realised this until now. I suspect we've been silently emitting bad code up until this point, and given that it's in flush_kernel_icache_page, maybe it explains some of our occasional crashes. The code was previously: fic,m %r23(%r26) We're trying to flush kernel space at this point, so we can use any of sr4-sr7. I suspect before we were putting sr0 in, which could have been flushing any random space instead of the one we wanted. I'll commit this change to the kernel source now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329888: [parisc-linux] binutils breaks hppa kernel build,
On Sat, Sep 24, 2005 at 11:24:31PM -0400, John David Anglin wrote: On Sat, Sep 24, 2005 at 09:27:22PM -0400, John David Anglin wrote: The last fic opcode entry is wrong. It's using the wrong instruction format, the mask is wrong, pa10 is wrong, etc. I don't think we realised this until now. I suspect we've been silently emitting bad code up until this point, and given that it's in flush_kernel_icache_page, maybe it explains some of our occasional crashes. The code was previously: fic,m %r23(%r26) I've committed a fix to binutils head. The above should now be accepted when generating PA 2.0 code. However, I'd probably avoid using this feature for awhile. It looks like the bug has been present since ~ 1996. This is in a file that's used on pa1.1 processors too, so I've gone with specifying sr4 explicitly. Thanks for fixing this bug and exposing our bug ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329370: New upstream version 2.2.0 available
Package: pciutils Version: 2.1.11 Severity: wishlist Hi, just reporting this so you know about 2.2.0. I'd like to see this ASAP so I don't have to compile my own version of lspci any more ;-) - Forwarded message from Martin Mares [EMAIL PROTECTED] - From: Martin Mares [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: pciutils-2.2.0 released List-Help: mailto:[EMAIL PROTECTED] List-Owner: mailto:[EMAIL PROTECTED] List-Post: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] X-Spam-Score: 0.0 (/) Hello! I have released pciutils-2.2.0. They are available at the usual places: ftp://atrey.karlin.mff.cuni.cz/pub/linux/pci/ ftp://ftp.kernel.org/pub/software/utils/pciutils/ The most important changes since 2.1.11 are (see ChangeLog for details): o New ports: GNU Hurd, Solaris/i386, Win32 o On Linux, support (and prefer) reading from /sys over /proc/bus. o Dumping of most of PCI 3.0, PCI-X, PCI Express and HyperTransport capabilities. o Dumping of extended 4096-byte config space on PCI-X and PCI Express (Linux with sysfs only). o Device addresses were extended to (domain,bus,device,function). o 64-bit resources are now supported on all Linux systems. o Extended the format of the pci.ids file to include subsystems not tied to specific devices, but the pci.ids file shipped does not use this feature yet. o As usually, lots of new entries in the PCI ID database. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Next lecture on time travel will be held on previous Monday. - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308271: still a problem with gnupg 1.4
Package: sig2dot
Version: 0.34-3
sig2dot is still connfused when it finds keys with trust signatures on
them (quite rare), eg:
Using: sig X1 44CE7F46 1999-07-01 [User ID not found]
The solution is to match up to one more character:
--- /usr/bin/sig2dot2005-03-06 14:53:06.0 -0500
+++ ./sig2dot 2005-05-08 23:40:56.0 -0400
@@ -107,7 +107,7 @@
#sig 39456ADE2 2004-02-07 Michael Schiansky michael#schiansky.de
# type id date name
- if ($line =~ m#([\w]+)[ !\?][ \dLNPRX]{0,7} +([^ ]+) +([^ ]+)(?:
+?([^]*))?#)
+ if ($line =~ m#([\w]+)[ !\?][ \dLNPRX]{0,8} +([^ ]+) +([^ ]+)(?:
+?([^]*))?#)
# differences:
# - [ !\?] (to use 'gpg --check-sigs|sig2dot.mio|springgraph|display')
# [ \d] - [ \dLRXP] (signature attributes)
ie replace {0,7} with {0,8}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302584: Problems with the hppa installer-manual
Package: debian-installer-manual I just took a little time to review the sarge installation manual at http://www.debian.org/releases/testing/hppa/ . It's a big improvement over the woody one! I do have some nits I'd like fixed before release: 2.1.3 currently reads: The newer AGP video slots are actually a modification on the PCI specification, and most AGP video cards work under XFree86. Just delete that line, it's pretty much a non-sequiter. Or maybe change it to: Most AGP, PCI and PCIe video cards work under XFree86. 2.4.2 should read something like: 2.4.2. RAM for PA-RISC machines HP has sold a wide variety of RAM for PA-RISC workstations and servers. It is generally not compatible with RAM used in other architectures and you should only use RAM that is specifically designed for PA-RISC machines. (to be honest, 2.4.2 is probably bad even on i386 -- who uses SIMMs these days?) 3.2 doesn't make much sense for PA-RISC. You can't share the hard drive between HPUX and Debian, so you need to find a second drive if you want to dual-boot. 3.6 also seems pretty incongruous 4.3 says In the examples in this section, we shall provide commands for SunOS 4.x, SunOS 5.x (a.k.a. Solaris), and GNU/Linux. I see no Solaris examples 5.2.1 isn't an issue as we have no floppy support Thanks -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301266: Always advertises 'Debian GNU/Linux'
On Sat, Mar 26, 2005 at 06:04:11PM +0100, Robert Millan wrote: - Someone proposed that it's easier to scrap it (ignoring the fact that I already provided a patch). Not just easier. More standards-compliant. I hereby propose to replace the constant string Debian GNU/Linux with a dynamic string that detects the kernel and becomes Debian GNU/$kernel. And I counter-propose replacing the constant string Debian GNU/Linux with just Debian. The argument that netcraft might want to report on which kernel variant we're using is absurd; they can already tell this from their other probing techniques. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301266: Always advertises Debian GNU/Linux
On Fri, Mar 25, 2005 at 05:51:50PM +0100, Robert Millan wrote: My apologise, but this patch produces FTBFS due to broken command-line options in gcc. I'm working on a fix and will send it RSN. I'm not sure it's worth it. I remember a bug against Apache 1.3 saying that we shouldn't include the Debian GNU/Linux string as that said we had component GNU with version Linux. See sections 3.8 and 14.38 of HTTP/1.1. Why don't we just put (Debian) in instead? -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241497: RFC and status report: Kernel upgrades for woody-sarge upgrades
On Thu, Mar 24, 2005 at 02:31:55PM +0100, Frank Lichtenheld wrote: As many of you may know on some machines users will need to install a current kernel before they will be able to upgrade woody to sarge (or better: glibc of woody to glibc of sarge). I've tried to use the available information to provide the needed files for these kernel upgrades. To my knowledge the affected machines/architecures are currently hppa64, sparc sun4m (only some of them) and 80386. It's all hppa machines, not just hppa64. I've prepared the necessary backports and some rudimentary documentation and put it online at http://higgs.djpig.de/upgrade/upgrade-kernel/ I'll give it a try now. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#275836: lwm: Button 3 on root window does NOT bring up a menu
retitle 275836 Manual page is unclear about button 3 usage thanks On Sun, Oct 10, 2004 at 06:56:18PM +0300, Tapio Lehtonen wrote: It is not possible to exit lwm as it does not bring up a menu by pressing mouse button 3 on root window. Manua page claims Pressing button 3 on the root window brings up a menu. This does not work. I tried on two different machines. Ah. I see the confusion. The menu that is brought up by lwm is a menu of all the hidden windows. It doesn't have options like start a new window manager or run random program. The lwm philosophy is to have that functionality in a different program. Having said that, if you're using lwm without a session manager, I think it needs to have the exec another window manager functionality, as killing lwm will cause your X session to end. I'll raise this point with upstream. In the meantime, I'll fix the manpage so it doesn't confuse others: .PP A button 3 click on a window frame hides that window. Pressing -button 3 on the root window brings up a menu. The various items unhide -the named hidden window. +button 3 on the root window brings up a menu of all the hidden windows. +Releasing the button while over an item will unhide the named window. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
