Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
On Sun, Mar 10, 2024 at 10:06:42AM +0800, Sean Whitton wrote: > Package: tech-ctte > X-debbugs-cc: csm...@debian.org, lea...@debian.org > > I call for votes on the following ballot to fill a vacant seat on the > Debian Technical Committee. The voting period starts immediately and > lasts for up to one week, or until the outcome is no longer in doubt. > > ===BEGIN > The Technical Committee recommends that Craig Small be > appointed by the Debian Project Leader to the Technical Committee. > > C: Recommend to Appoint Craig Small > F: Further Discussion > ===END I vote C > F signature.asc Description: PGP signature
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
On Mon, Mar 04, 2024 at 04:08:37PM +, Simon McVittie wrote: > Copying context from elsewhere in the thread, Sam Hartman wrote: > > Are there solutions in the space of having glib2.0-0 continue to exist > > as a package depended on by glib2.0-0t64 or depending on the new library > > allowing you to replace the postrm? > > to which I replied: > > If libglib2.0-0 continues to exist, then packages that expect the affected > entry points to have 32-bit time_t will still have their dependencies > satisfied, but then when they call the affected entry points, they will > crash, because their time_t is not the same size as GLib's. So as far > as I can see, this is functionally equivalent to reverting the rename: > to be correct, it would have to be accompanied by versioned Breaks on > every package that calls into the affected entry points. Sorry, yes, because we're transitioning the package name but not the soname. My mistake.
Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition
I agree with the conclusions drawn here, but feel that it's possibly worth making a stronger general statement that policy should never prevent the implementation of a well-considered simple solution. I would like some further analysis of Sam's proposal, though - I don't think there's any advantage in undoing the existing solution, but if it would work then it's maybe a more straightforward solution for any similar issues in future?
Bug#1050001: Unwinding directory aliasing
On Fri, Aug 25, 2023 at 06:50:54AM +0200, Ansgar wrote: > If someone wants to go this way, I suggest to just have a GR about it > instead of iterating this at tech-ctte yet again. It's not very > motivating to have some people endlessly argue against moving forward > and wanting to revisit/reverse/change some decisions endlessly. Ian is a sufficient subject matter expert that I think his concerns are worth analysing. I lean towards disagreeing with his conclusion (I agree that aspects of usrmerge may uncover or result in subtle bugs, but suspect that having Debian diverge from the approach that most other distributions have taken would probably result in a larger number), but I feel it's legitimate to bring this up with the committee. At the moment I think the general feeling seems to be that the concerns aren't sufficient to change the approach we're taking, but when presented with new information it makes sense to take that into account. Please don't interpret this as an attempt to prevent us from moving forward - please think of this as additional verification that we *are* moving forward.
Bug#1041552: HFS/HFS+ are insecure
On Fri, Jul 21, 2023 at 10:55:39AM +0200, Marco d'Itri wrote:
> Unless somebody has a better idea then then my plan is to ship in the
> next upload of kmod a file in /etc/modprobe.d/ which uses the blacklist
> directive to prevent automatically loading some file system modules.
I think this would break any existing fstab entries that reference hfs
and hfsplus, and the convenient way to integrate Linux boot with x86
Macs is certainly to have an hfsplus EFI partition so this may be a
legitimate use-case. It also means that anyone who has a need to use one
of these filesystems in a static manner is vulnerable to automount
attacks using them.
Completely untested, but I think something along the lines of:
SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
LABEL="udisks_insecure_fs_end"
in a udev fragment should work? Any static fstab or mount units should
still work, but it should disable udisks automounting regardless of the
desktop agent involved, even if the fs modules are already loaded.
Bug#1037563: tech-ctte: Call for votes on TC membership of Timo Röhling
On Wed, Jun 14, 2023 at 10:04:54AM +0100, Sean Whitton wrote: > Package: tech-ctte > X-debbugs-cc: roehl...@debian.org, lea...@debian.org > > I call for votes on the following ballot to fill a vacant seat on the > Debian Technical Committee. The voting period starts immediately and > lasts for up to one week, or until the outcome is no longer in doubt. > > ===BEGIN > The Technical Committee recommends that Timo Röhling be > appointed by the Debian Project Leader to the Technical Committee. > > R: Recommend to appoint Timo Röhling > F: Further discussion > ===END I vote R > F signature.asc Description: PGP signature
Bug#1037562: tech-ctte: Call for votes on TC membership of Stefano Rivera
On Wed, Jun 14, 2023 at 10:03:19AM +0100, Sean Whitton wrote: > Package: tech-ctte > X-debbugs-cc: stefa...@debian.org, lea...@debian.org > > I call for votes on the following ballot to fill a vacant seat on the > Debian Technical Committee. The voting period starts immediately and > lasts for up to one week, or until the outcome is no longer in doubt. > > ===BEGIN > The Technical Committee recommends that Stefano Rivera be > appointed by the Debian Project Leader to the Technical Committee. > > R: Recommend to appoint Stefano Rivera > F: Further discussion > ===END I vote: R > F signature.asc Description: PGP signature
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Tue, Jun 13, 2023 at 09:14:53PM +0200, Ansgar wrote: > On Tue, 2023-06-13 at 20:01 +0100, Matthew Garrett wrote: > > After discussing this at our monthly meeting, we concluded that the > > technical committee isn't going to take action on this at the moment. > > There's a legitimate technical consideration behind the warning, and > > it's necessary for derivatives to ensure that they handle the > > associated scenarios properly. > > Okay, I take that as "Debian doesn't care about derivatives". > Suggesting users to revert to split-/usr *will* break stuff for users > once more code Debian assumes merged-/usr. With my non-CTTE hat on, I think this is a demonstration that Debian *does* care about derivatives. It's important to ensure that derivatives are aware of the subtle interactions between dpkg and usrmerge, otherwise they may suffer from hard to diagnose issues on upgrades. The message from dpkg says nothing about reverting to split-/usr, and instead points at a wiki page. If our documentation on how to avoid these issues is incomplete (ie, if we're only describing how to avoid it by using split-/usr rather than describing the mitigations we've imposed within Debian to avoid triggering the issues), perhaps a better approach would be to improve that documentation? We don't benefit our users by pretending there isn't a problem here.
Bug#902972: libargon2-0 install a symlink pointin to libargon2.so.1
severity 902972 normal The SONAME of this library changed, but the ABI did not. There's no benefit in forcing users to rebuild, and I'm unclear on how this violates policy, so I'm downgrading the severity to unblock migration. -- Matthew Garrett | mj...@srcf.ucam.org
Bug#663433: udev: does not load acpiphp on ThinkPad T520 although it is needed for ExpressCard hotplugging
On Mon, Mar 12, 2012 at 03:30:24PM +, Ben Hutchings wrote: > This is terrible... there must be some way we can DTRT as it's just not > acceptable to require users to configure this. I was under the > impression that RH had built-in acpiphp and pciehp now... Matthew? Any hardware that's broken by acpiphp is also broken by Windows. I've seen no evidence that anything exists in the real world that would be broken merely by loading this driver. -- Matthew Garrett | mj...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#631664: [PATCH v2] x86: Add amilo-rfkill driver for some Fujitsu-Siemens Amilo laptops
On Sun, Nov 13, 2011 at 07:06:42PM +, Ben Hutchings wrote: > +#define A1655_STATE_PORT 0x64 > +#define A1655_COMMAND_PORT 0x64 > +#define A1655_DATA_PORT 0x60 You'll need to synchronise with the i8042 driver here, otherwise things could go horribly wrong. > +#define M7440_PORT1 0x118f > +#define M7440_PORT2 0x118e These ports are defined in the DSDT for one of these systems, but not referenced. I think a hardware-banging driver like this is probably the only interface. Should be fine as long as you make sure you're not racing with the keyboard controller. -- Matthew Garrett | mj...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587014: screen brightness can't be modified on some Panasonic laptops
Well, that's odd. There's certainly support for ACPI backlight control in your firmware, and it goes via opregion so it should work correctly. I think the thing to do here is to have the panasonic driver bail if there's ACPI backlight support, and then figure out why the ACPI video driver isn't working for you. -- Matthew Garrett | mj...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587014: screen brightness can't be modified on some Panasonic laptops
Is there a /sys/class/backlight/acpi_video0 directory as well as the Panasonic one? -- Matthew Garrett | mj...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587014: screen brightness can't be modified on some Panasonic laptops
On Tue, Jan 04, 2011 at 06:14:40AM +0800, Cristopher Camacho wrote: > No, there is no. Only the /sys/class/backlight/panasonic/ directory is > present. Can you attach the output of the acpidump command on your system? -- Matthew Garrett | mj...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587014: screen brightness can't be modified on Panasonic S9
On Sun, Jun 27, 2010 at 03:14:44AM +0100, Ben Hutchings wrote: > Harald, > > Nicolas Limare reported that the backlight control in panasonic-laptop > is non-functional on the S9; see <http://bugs.debian.org/587014>. > There's a kernel log attached to that bug report, but it doesn't show > very much. Can you suggest how to investigate this? Could be a number of things. The output of acpidump would help. -- Matthew Garrett | mj...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#403983: wireless-tools: Needs to up interface before setting options
On Thu, Nov 13, 2008 at 10:35:36PM -0800, Steve Langasek wrote: > Matthew, do you know if this is still needed for softmac? There's been at > least one bug report against wireless-tools in Ubuntu complaining that it > breaks other ifupdown functionality > (https://bugs.launchpad.net/bugs/219520), so if it's safe to drop this diff > now, I'd like for us to do that. I agree that conceptually, it's better to > set all of the wireless variables before bringing up the interface. softmac's dead, so if it's not required for mac80211 I suspect it can die. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501137: ITP: acerfand -- Control the fan of the Acer Aspire One
On Tue, Oct 07, 2008 at 05:30:12PM -0500, Gunnar Wolf wrote: > Matthew, and out of personal curiosity (as I will probably continue to > use this, at least until something better comes along): What does the > danger amount to? Say, a random lock-up? Or will it lead to hardware > malfunction (or shorter lifespan)? I am currently setting the > fan-on threshold at 70C, the fan-off at 60C (the default settings for > acerfand) It really depends on how the hardware is designed, but an example would be where the kernel ends up reading the incorrect register when checking the temperature and misinterprets it as requiring a critical thermal shutdown. Lockups are certainly possible, and it's just about conceivable that you could cause hardware damage - though that's a bit of a stretch. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501137: ITP: acerfand -- Control the fan of the Acer Aspire One
Gunnar Wolf <[EMAIL PROTECTED]> wrote: > Keeps the fan from spinning constantly in the noisy Acer Aspire > One. Provides also tools to query several machine-specific EC > registers Be careful with this - it can't perform the locking used by the kernel and firmware for EC access, so there's a risk of racing and trashing the contents of other registers. This should really be implemented as a kernel driver using either the hwmon or thermal interfaces and a generic fan control daemon implemented on top of that. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435970: Please do not generate the udeb any longer
On Mon, Aug 06, 2007 at 08:16:37PM +0200, Davide Viti wrote: > Today Aiet Kolkhi posted the following: > > http://lists.debian.org/debian-i18n/2007/08/msg00026.html Looks good. I'll try to get this fixed in the next couple of days. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435970: Please do not generate the udeb any longer
On Sat, Aug 04, 2007 at 02:40:50PM +0200, Davide Viti wrote: > Hi, I'm switching the graphical installer as to fetch Georgian glyphs out > of ttf-dejavu (>= 2.18), so there's no need to generate the udeb anylonger > (see [1]). > Here's also the trivial patch to achieve it: Did you ever get any feedback from the Georgian developers? It'd be nice to know if they're happy with the change. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#424887: vbetool: FTBFS on kfreebsd-amd64
On Thu, May 17, 2007 at 06:42:15PM +0200, Petr Salinger wrote: > --- vbetool-0.7/vbetool.c > +++ vbetool-0.7/vbetool.c > @@ -42,7 +42,9 @@ > exit(1); > } > > +#if !(defined(__FreeBSD_kernel__) && defined(__x86_64__)) > ioperm(0, 1024, 1); > +#endif Does the code work with this change? I'd be suspicious... -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355223: #355223: hotkey-setup: add Dell Inspiron multimedia keys
Could you clarify the comments? "Dell i key" doesn't sound like a media key. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#272085: InputDevice stanzas for both /dev/psaux and /dev/input/mice cause events to be received twice on 2.6 kernels
On Thu, Jan 11, 2007 at 07:24:17PM +0100, Brice Goglin wrote: > Hi Matthew, > > About 2 years ago, you reported a bug to the Debian BTS regarding mouse > events being received twice by the X server when running a 2.6 kernels. > Did you reproduce this problem recently? If not, I will close the bug in > the next weeks. I'm afraid I don't have any Debian installs at the moment - however, I believe that this was fixed before the release of woody. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
A couple of observations: * This bug will not cause hardware damage. The hard thermal cutoff temperature is well below the temperature at which actual damage will occur. * It's not clear that the vendor DSDT is broken. It's an unusual interpretation of the spec, but not necessarily an invalid one - sadly, the ACPI specification is not entirely clear on every point. The patch is /probably/ safe, and we've been shipping it in Ubuntu. On the other hand, previous versions did cause problems on certain other items of hardware. It's not clear what the best option is, but it's certainly not a regression over Sarge. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403983: wireless-tools: Needs to up interface before setting options
Package: wireless-tools Severity: normal As described in http://lkml.org/lkml/2006/12/20/371 , various wireless drivers require that the interface be brought up before wireless options are set. As far as I can tell, the pre-up script doesn't currently do this. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.33 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Versions of packages wireless-tools depends on: ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383481: Must source code be easy to understand to fall under DFSG?
On Tue, Oct 31, 2006 at 05:00:15PM +0100, Ola Lundqvist wrote:
(Anyone on debian-legal: please note and maintain the Cc:s)
> As you say you need the prefered form of _modification_, which means
> that if we change things, we are not allowed to obfuscate it. I can not
> see anything that enfoce the original author to actually do such
> obfuscation.
No, the preferred form *for* modification.
> The only requirement on the original author (as I can determine) is that
> you get source code for it, not that it is in preferred form for making
> modification.
That's perfectly acceptable. Upstream can do whatever they want.
However, if upstream do not provide the preferred form for modification
(ie, the unobfuscated version), Debian can not distribute it under the
terms of the GPL.
That's not an issue in this case, since X is not a GPLed application.
Debian can distribute the obfuscated code entirely legally, without
violating any licenses. The issue is whether "source" in the DFSG refers
to the GPL's definition ("the preferred form for modification") or not.
An alternative interpretation could be "a form amenable to modification
by people sufficiently familiar with the work".
If people define source as "the preferred form for modifications" in all
cases, then there's no place for deliberately obfuscated code in Debian.
There's also arguably no place for works that are only available
as JPEGs, any flattened image formats, mp3s, PDFs and so on. Right now
there doesn't seem to be a strong opinion in the project about that, but
I expect it's a discussion that needs to be had.
(For anyone doubting that the nvidia code is deliberately obfuscated -
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/vga256/drivers/nv/Attic/nv4driver.c.diff?r1=1.1.2.3&r2=1.1.2.4&hideattic=0&only_with_tag=xf-3_3_3
ought to make it pretty clear)
--
Matthew Garrett | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303640: kernel-image-2.6.8-10-amd64-k8: Xfree86 fails to find a VESA chipset
On Sun, Apr 10, 2005 at 08:03:55PM +0200, Kurt Roeckx wrote: > On Fri, Apr 08, 2005 at 10:17:47PM +0200, David Robin wrote: > > please note the message "XFree86: vm86 mode not supported on 64 bit > > kernel" at the end of the log. I have just noticed it. May this issue > > be related to XFree86? > > I'm assuming that this is using the amd64 kernel with a i386 > userland? ia32 builds of Xorg use vm86 for real-mode BIOS calls. 64-bit kernels don't support the vm86 syscall, even with 32-bit userland. The Vesa driver requires the ability to make real-mode BIOS calls. This can never work. I'd suggest just closing this. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383465: Contains obfuscated source code, DFSG violation?
Sorry? 12 of the files in the source tree contain explicit Nvidia copyright statements. The others tend to have no copyrights at all, but are generally written by Mark Vojkovich who is an nvidia employee. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384120: hal: Bad interaction with acpi-support
The scripts in acpi-support can potentially be triggered in more than one way. The classic example is to have /etc/acpi/events/sleepbtn call the sleep script. In an environment where you're running an application like gnome-power-manager, this isn't what you want to happen. Once the user can determine policy, the hardcoded events should do nothing. That's the reason for checking whether gnome-power-manager or similar are running, and refusing to run in that case. HAL should pass the force argument in order to cause the script to run anyway, since HAL will only be triggered by policy manager events in any case. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383465: Contains obfuscated source code, DFSG violation?
Package: xserver-xorg-video-nv
Version: 1:1.0.1.5-2
Severity: serious
The nv driver appears to be heavily obfuscated and is effectively
unmodifiable. Rather than symbolic constants, almost every reference to
hardware is performed using undocumented hex. The only registers that
appear to be documented are the legacy CRTC ones which are effectively
identical over all hardware. Take for example NVBacklightEnable:
if((pNv->Chipset == 0x10DE0179) ||
(pNv->Chipset == 0x10DE0189) ||
(pNv->Chipset == 0x10DE0329))
{
/* NV17,18,34 Apple iMac, iBook, PowerBook */
CARD32 tmp_pmc, tmp_pcrt;
tmp_pmc = pNv->PMC[0x10F0/4] & 0x7FFF;
tmp_pcrt = pNv->PCRTC0[0x081C/4] & 0xFFFC;
if(on) {
tmp_pmc |= (1 << 31);
tmp_pcrt |= 0x1;
}
pNv->PMC[0x10F0/4] = tmp_pmc;
pNv->PCRTC0[0x081C/4] = tmp_pcrt;
}
The idea that nvidia do not posess an electronic list of register names
and offsets is entirely implausible. The only rational explanation is
that register information is postprocessed out in order to reduce
information leakage. The shipped code is certainly not the preferred
form for modification, and according to prevailing attitudes on
debian-legal should be removed from Debian.
--
Matthew Garrett | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372895: acpid script
> Is it possible to add it in the package? No - dpms bios calls don't work on all hardware, and may be actively harmful in some cases. This is a Dell BIOS bug that can also be seen under safe mode in Windows - please feel free to complain to Dell. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351621: [Bug 28648] Slow movement regression of synaptics touchpad on v0.14.3+seriouslythistime
On Thu, Mar 23, 2006 at 12:30:20PM +0100, Mattia Dongili wrote: > Did any of you (at ubuntu) forwarded the patch upstream already? Not yet - I only wrote the patch last night. Feel free to do so. It's fairly ugly, but it might encourage upstream to do something similar (and cleaner) -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351621: [Bug 28648] Slow movement regression of synaptics touchpad on v0.14.3+seriouslythistime
Diff attached.
--
Matthew Garrett | [EMAIL PROTECTED]
--- xserver-xorg-input-synaptics-0.14.3+seriouslythistime.orig/linux_input.h
+++ xserver-xorg-input-synaptics-0.14.3+seriouslythistime/linux_input.h
@@ -27,7 +27,7 @@
#define EVIOCGID _IOR('E', 0x02, struct input_id)/* get
device ID */
#define EVIOCGRAB _IOW('E', 0x90, int)/*
Grab/Release device */
#define EVIOCGBIT(ev,len) _IOC(_IOC_READ, 'E', 0x20 + ev, len)/* get
event bits */
-
+#define EVIOCGNAME(len)_IOC(_IOC_READ, 'E', 0x06, len)
/* get device name */
#define EV_SYN 0x00
#define EV_KEY 0x01
--- xserver-xorg-input-synaptics-0.14.3+seriouslythistime.orig/eventcomm.c
+++ xserver-xorg-input-synaptics-0.14.3+seriouslythistime/eventcomm.c
@@ -31,6 +31,8 @@
#define LONG(x) ((x) / LONG_BITS)
#define TEST_BIT(bit, array) (array[LONG(bit)] & (1 << OFF(bit)))
+extern int is_alps;
+
/*
* Function Definitions
/
@@ -52,6 +54,17 @@
{
}
+static Bool
+event_query_is_alps(int fd)
+{
+char name[5]="";
+ioctl(fd, EVIOCGNAME(sizeof(name)),name);
+name[4]='\0';
+if (strcmp(name, "Alps") == 0)
+ return TRUE;
+return FALSE;
+}
+
static Bool
event_query_is_touchpad(int fd)
{
@@ -258,13 +271,17 @@
noent_cnt = 0;
have_evdev = TRUE;
is_touchpad = event_query_is_touchpad(fd);
- SYSCALL(close(fd));
if (is_touchpad) {
xf86Msg(X_PROBED, "%s auto-dev sets device to %s\n",
local->name, fname);
xf86ReplaceStrOption(local->options, "Device", fname);
+ if (event_query_is_alps(fd) == TRUE) {
+ is_alps = 1;
+ }
+ SYSCALL(close(fd));
return TRUE;
}
+ SYSCALL(close(fd));
}
ErrorF("%s no synaptics event device found (checked %d nodes)\n",
local->name, i + 1);
--- xserver-xorg-input-synaptics-0.14.3+seriouslythistime.orig/synaptics.c
+++ xserver-xorg-input-synaptics-0.14.3+seriouslythistime/synaptics.c
@@ -163,6 +163,7 @@
#endif /* XFree86LOADER */
+int is_alps=0;
/*
* Function Definitions
@@ -342,26 +343,49 @@
priv->shm_config = xf86SetBoolOption(local->options, "SHMConfig", FALSE);
/* read the parameters */
+
pars = &priv->synpara_default;
-pars->left_edge = xf86SetIntOption(local->options, "LeftEdge", 1900);
-pars->right_edge = xf86SetIntOption(local->options, "RightEdge", 5400);
-pars->top_edge = xf86SetIntOption(local->options, "TopEdge", 1900);
-pars->bottom_edge = xf86SetIntOption(local->options, "BottomEdge", 4000);
-pars->finger_low = xf86SetIntOption(local->options, "FingerLow", 25);
-pars->finger_high = xf86SetIntOption(local->options, "FingerHigh", 30);
-pars->tap_time = xf86SetIntOption(local->options, "MaxTapTime", 180);
-pars->tap_move = xf86SetIntOption(local->options, "MaxTapMove", 220);
-pars->tap_time_2 = xf86SetIntOption(local->options, "MaxDoubleTapTime",
180);
-pars->click_time = xf86SetIntOption(local->options, "ClickTime", 100);
-pars->fast_taps = xf86SetIntOption(local->options, "FastTaps", FALSE);
-pars->emulate_mid_button_time = xf86SetIntOption(local->options,
+if (is_alps) {
+ pars->left_edge = xf86SetIntOption(local->options, "LeftEdge", 120);
+ pars->right_edge = xf86SetIntOption(local->options, "RightEdge", 830);
+ pars->top_edge = xf86SetIntOption(local->options, "TopEdge", 120);
+ pars->bottom_edge = xf86SetIntOption(local->options, "BottomEdge", 630);
+ pars->finger_low = xf86SetIntOption(local->options, "FingerLow", 14);
+ pars->finger_high = xf86SetIntOption(local->options, "FingerHigh", 15);
+ pars->tap_time = xf86SetIntOption(local->options, "MaxTapTime", 180);
+ pars->tap_move = xf86SetIntOption(local->options, "MaxTapMove", 110);
+ pars->tap_time_2 = xf86SetIntOption(local->options, "MaxDoubleTapTime",
180);
+ pars->click_time = xf86SetIntOption(local->options, "ClickTime", 100);
+ pars->fast_taps = xf86SetIntOption(local->options, "FastTaps", FALSE);
+ pars->emulate_mid_button_time = xf86SetIntOption(local-&g
Bug#358149: acknowledged by developer (Re: Bug#358149: vbetool: Error in posting after standby (Fujitsu-Siemens A7645 + SiS M760))
On Tue, Mar 21, 2006 at 01:17:37PM +0100, Thomas Halva Labella wrote: > I tried this the vbestate option too, both before, after and without > post, but it did not work either. The problem was the same "garbage" on > the screen. :( And switching back to X doesn't work? If not, I'm afraid there's nothing I can do (you're not using a framebuffer, right? If you are, then it needs suspend/resume code to deal with this, and vbetool is probably just confusing it. But in any case, there doesn't appear to be a bug in vbetool here) -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355252: [Fwd: PATCH: Fix gnu-efi-3.0b-041222 for ia32]
On Fri, Mar 17, 2006 at 01:43:24PM -0700, Brett Johnson wrote: > FWIW, This patch looks interesting, and looks like it might solve the > problem with the newer binutils. I still haven't figured out an easy > way to get a ia32 EFI machine up and running to test on (for some > reason, qemu hangs about 30sec after booting the EFI floppy image). But > it might be worth patching gnu-efi and trying it for someone that has > easy access to a ia32/EFI machine. Yes, I've been in contact with binutils upstream about this. I still seem to require -march=i386, but otherwise things seem to work well now. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355252: [Fwd: Bug#355252: elilo: fails to work on ia32]
Right. I can build a working binary if I do two things: 1) Add -march=i386 to the gnu-efi and elilo builds 2) Use plain binutils-2.16.1, and not binutils-2.16.1cvs20060117 The first of these is easy, the second involves finding out what's broken in binutils. What fun. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355252: Binutils version dependent
As a datapoint - using binutils_2.16.1cvs20060117-1, I get an elilo that fails to run with "Ext status code: Invalid parameter". Using binutils-2.6.1-2, I get an elilo that hangs the machine. In both cases, gnu-efi was rebuilt with the same binutils. Disassembling the images produces almost identical outputs (some addresses are slightly different), but these sections: Hanging version (binutils-2.6.1) Idx Name Size VMA LMA File off Algn 0 .text 00011888 1000 1000 0400 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 000157f4 00013000 00013000 00011e00 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .dynamic 0080 00029000 00029000 00027600 2**2 CONTENTS, ALLOC, LOAD, DATA 3 .rel 0998 0002a000 0002a000 00027800 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .reloc000a 0002a998 0002a998 00028398 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .dynsym 14c0 0002b000 0002b000 00028600 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA Entirely non-working version (binutils 2.6.1.cvs20060117) Idx Name Size VMA LMA File off Algn 0 .text 00011888 1000 1000 0400 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00015814 00013000 00013000 00011e00 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .dynamic 0080 00029000 00029000 00027800 2**2 CONTENTS, ALLOC, LOAD, DATA 3 .rel 0998 0002a000 0002a000 00027a00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .dynsym 14a0 0002b000 0002b000 00028400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .reloc000a 0002f060 0002f060 00029a60 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA I'm afraid I don't really know toolchains well enough to go much further myself. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355252: [Fwd: Bug#355252: elilo: fails to work on ia32]
On Sat, Mar 04, 2006 at 09:59:39PM -0700, Brett Johnson wrote: > Yes, I believe that to be the case also. It's not clear from the bug > report which toolchain Matthew is using. In Sarge, if gcc4 is used to > compile elilo, I know it will fail on both ia32 and ia64 due to an older > version of gnu-efi (3.0a). Etch and sid both have gnu-efi 3.0b, which > should fix the problems with the gcc4 toolchain (and do, on ia64). I > don't have an ia32 EFI machine, so have never tested the ia32 side (but > it apparently works ok, since the gentoo build works, and some people > have been booting their intelmac machines with it ;) I suspect a > mismatch between gnu-efi versions and gcc versions... Sarge uses gnu-efi 3.0a and gcc-3.3 (I believe), with Sid using gnu-efi 3.0b and gcc-4.0. I've tried various combinations of Debian gcc and binutils, but haven't managed to produce a working binary yet. Scanning the Gentoo binutils and gcc patches doesn't show anything terribly obvious, so it sounds like tracking this down won't be terribly good fun. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355252: elilo: fails to work on ia32
Package: elilo Severity: grave Justification: renders package unusable On IA32 systems, attempting to run elilo.efi gives: 'elilo' not found Exit status code: Invalid Parameter The Sarge version gives Exit status code: Load Error I have a working elilo.efi that was built on a gentoo system using 3.6 source, so my suspicion is that there's a toolchain bug here somewhere. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686-smp Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281043: netapplet fails to start with "WARNING **: icon_name=stock_unknown"
On Tue, Dec 13, 2005 at 08:07:27PM +0100, Dominique Deleris wrote: > # apt-get install libiw27 > Reading package lists... Done > Building dependency tree... Done > Package libiw27 is not available, but is referred to by another package. > This may mean that the package is missing, has been obsoleted, or > is only available from another source > E: Package libiw27 has no installation candidate It was uploaded this morning - it may take a little while to hit the archive. Thanks, -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281043: netapplet fails to start with "WARNING **: icon_name=stock_unknown"
Can you reproduce this with the latest netapplet? I believe it to be fixed now. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341549: vbetool: ftbfs [sparc] sys/io.h: No such file or directory
On Thu, Dec 01, 2005 at 03:11:40AM -0800, Blars Blarson wrote: > vbetool.c:19:20: error: sys/io.h: No such file or directory > vbetool.c: In function 'main': > vbetool.c:46: warning: implicit declaration of function 'ioperm' > vbetool.c:47: warning: implicit declaration of function 'iopl' > vbetool.c: In function 'enable_vga': > vbetool.c:378: warning: implicit declaration of function 'outb' > vbetool.c:378: warning: implicit declaration of function 'inb' > make[2]: *** [vbetool.o] Error 1 > make[2]: Leaving directory `/build/buildd/vbetool-0.5' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/build/buildd/vbetool-0.5' > make: *** [build-stamp] Error 2 Hmm. Does sparc genuinely not have any concept of legacy port io? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328200: [debian-ntp] Bug#328200: Problems with ntp
Bdale Garbee <[EMAIL PROTECTED]> wrote: > The file util/ansi2knr.c is also GPL. I'm pretty sure it's unused, but > an easy reference in debian/copyright would cover it. This may be a problem if it is used, as: > There are several files that are BSD with advertising clause, including > libntp/memmove.c, libntp/mktime.c, libntp/random.c, libntp/strerror.c, > libntp/strstr.c, ntpd/refclock_jupiter.c, and ntpd/refclock_mx4200.c. > These should be referenced in debian/copyright. BSD with advertising isn't GPL compatible. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324404: irda-utils: Where possible, use PNP to autoconfigure IrDA
Package: irda-utils Severity: wishlist Tags: patch On x86 and amd64 laptops (and possibly some desktops), the presence of IrDA ports is indicated through the PNP BIOS. The attached patch attempts to use this information to automatically load the correct FIR driver and to configure the serial port appropriately. If successful, it will then start irattach. -- System Information: Debian Release: 3.1 Architecture: i386 (i586) Kernel: Linux 2.6.8-2-386 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) diff -urN irda-utils-0.9.16/debian/config irda-utils-0.9.16.mine/debian/config --- irda-utils-0.9.16/debian/config 2005-08-22 00:40:35 +0100 +++ irda-utils-0.9.16.mine/debian/config2005-08-22 00:43:33 +0100 @@ -15,19 +15,22 @@ # preinst has to retrieve the old values first. if [ ! -e "$CONFIG_OLD" ]; then STATE=1 -LASTSTATE=4 +LASTSTATE=5 while [ $STATE -gt 0 -a $STATE -le $LASTSTATE ]; do case $STATE in 1) db_input medium $PACKAGE/enable || true ;; -2) + 2) + db_input medium $PACKAGE/automatic || true + ;; +3) db_input medium $PACKAGE/discovery || true ;; -3) +4) db_input medium $PACKAGE/selectdevice || true ;; -4) +5) db_get $PACKAGE/selectdevice if [ "$RET" = "serial" ]; then db_input medium $PACKAGE/ttydev || true diff -urN irda-utils-0.9.16/debian/irda-utils.init irda-utils-0.9.16.mine/debian/irda-utils.init --- irda-utils-0.9.16/debian/irda-utils.init2005-08-22 00:40:35 +0100 +++ irda-utils-0.9.16.mine/debian/irda-utils.init 2005-08-22 00:17:29 +0100 @@ -20,6 +20,14 @@ if [ -f /etc/default/$PACKAGE ]; then . /etc/default/$PACKAGE fi + + +test "$AUTOMATIC" = "true" && if [ -f /var/run/irdadev ]; then +# We discovered a device on boot. Attempt to bind to it. +ENABLE="true" +read -d " " DEVICE $STATEFILE; + let "IRDA=$IRDA+1"; + FALLBACK=false; + else + # Try to recover + if [ "$UART" != "undefined" ]; then + setserial $PORT uart $UART; + fi + fi + fi + + if [ "$SIR" = "true" ]; then + if [ "$FIR" = "false" -o "$FALLBACK" = "true" ]; then + # Ok, let's try just driving the UART + # The IRQ is not always set correctly, so try to deal with that + IRQ=`grep irq $x/resources | sed -e 's/irq \(.*\)/\1/'` + setserial $PORT irq $IRQ; + echo "$PORT sir" >$STATEFILE; + fi + fi +done +;; +stop) +exit 0 +;; +esac diff -urN irda-utils-0.9.16/debian/po/de.po irda-utils-0.9.16.mine/debian/po/de.po --- irda-utils-0.9.16/debian/po/de.po 2005-08-22 00:40:35 +0100 +++ irda-utils-0.9.16.mine/debian/po/de.po 2005-08-22 00:36:36 +0100 @@ -15,7 +15,7 @@ msgstr "" "Project-Id-Version: irda-utils\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2004-07-24 10:17+0200\n" +"POT-Creation-Date: 2005-08-22 00:36+0100\n" "PO-Revision-Date: 2004-05-21 14:23+0200\n" "Last-Translator: Sebastian Henschel <[EMAIL PROTECTED]>\n" "Language-Team: de <[EMAIL PROTECTED]>\n" @@ -179,3 +179,18 @@ "Bestätigen Sie, wenn IrDA während des Bootvorgangs aktiviert werden soll. " "Dies ist für Geräte notwendig, die ein laufendes \"irattach\" benötigen. Die " "meisten Geräte brauchen es, mit Ausnahme einiger weniger FIR-Geräte." + +#. Type: boolean +#. Description +#: ../templates:65 +#, fuzzy +msgid "Attempt to probe for IrDA on system bootup?" +msgstr "Aktiviere IrDA bei Systemstart?" + +#. Type: boolean +#. Description +#: ../templates:65 +msgid "" +"Confirm if you want to attempt to autoconfigure IrDA on system startup. If " +"a device is found, irattach will automatically be started up." +msgstr "" diff -urN irda-utils-0.9.16/debian/po/fr.po irda-utils-0.9.16.mine/debian/po/fr.po --- irda-utils-0.9.16/debian/po/fr.po 2005-08-22 00:40:35 +0100 +++ irda-utils-0.9.16.mine/debian/po/fr.po 2005-08-22 00:36:37 +0100 @@ -17,7 +17,7 @@ msgstr "" "Project-Id-Version: irda-utils\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2004-07-24 10:17+0200\n" +"POT-Creation-Date: 2005-08-22 00:36+0100\n" "PO-Revision-Date: 2004-07-24 22:00+0200\n" "Last-Translator: Christian Perrier <[EMAIL PROTECTED]>\n" "Language-Team: French <[EMAIL PROTECTED]>\n" @@ -184,3 +184,18 @@ "lancement de votre système. Ce choix est indispensable pour les " "périphériques qui ont besoin de « irattach » pour fonctionner, ce qui est le " "cas de la plupart, à l'exception de rares périphériques FIR." + +#. Type: boolean +#. Description +#: ../templates:65 +#, fuzzy +msgid "Attempt to probe for IrDA on system bootup?" +msgstr "Faut-il activer la gestion de l'infrarouge au démarrage ?" + +#. Type: boolean +#. Description +#: ../templates:65 +msgid "" +"C
Bug#323397: grub: Does not fall back to source drive if BIOS fails to pass boot drive
Package: grub
Version: 0.95+cvs20040624-12
Severity: normal
Tags: patch
On boot, the BIOS is supposed to pass the boot drive to the bootloader
in register dx. Not all BIOSes do this. The included patch causes grub
to attempt to boot off the boot drive passed by the BIOS. If this fails,
it then reverts to the drive that grub was originally installed to. It
should only trigger in cases that currently fail.
diff -ur -x 'Makefile*' -x 'config.*' grub-0.95+cvs20040624/stage1/stage1.h
grubme/stage1/stage1.h
--- grub-0.95+cvs20040624/stage1/stage1.h 2004-03-27 17:02:53 +
+++ grubme/stage1/stage1.h 2005-08-16 13:54:01 +0100
@@ -54,6 +54,9 @@
/* The offset of BOOT_DRIVE_MASK. */
#define STAGE1_BOOT_DRIVE_MASK 0x4d
+/* The offset of STAGE1_SOURCE_DRIVE. */
+#define STAGE1_SOURCE_DRIVE 0x4e
+
/* The offset of a magic number used by Windows NT. */
#define STAGE1_WINDOWS_NT_MAGIC0x1b8
diff -ur -x 'Makefile*' -x 'config.*' grub-0.95+cvs20040624/stage1/stage1.S
grubme/stage1/stage1.S
--- grub-0.95+cvs20040624/stage1/stage1.S 2004-03-27 17:02:53 +
+++ grubme/stage1/stage1.S 2005-08-16 13:55:34 +0100
@@ -115,12 +115,16 @@
boot_drive_mask:
.byte 0x00
+
+source_drive:
+ .byte GRUB_INVALID_DRIVE
+
/*
* ljmp to the next instruction because some bogus BIOSes
* jump to 07C0: instead of :7C00.
*/
ljmp$0, $ABS(real_start)
-
+
real_start:
/* set up %ds and %ss as offset from 0 */
@@ -236,7 +240,18 @@
testb $STAGE1_BIOS_HD_FLAG, %dl
jz floppy_probe
- /* Nope, we definitely have a hard disk, and we're screwed. */
+ /* Nope, we definitely have a hard disk, and we're screwed.
+ Try as hard as we can to recover. */
+
+ MOV_MEM_TO_AL(ABS(source_drive))/* movb ABS(source_drive), %al
*/
+ cmpb$GRUB_INVALID_DRIVE, %al
+ je 1f
+ cmpb%al, %dl /* We've been here before */
+ je 1f
+ movb%al, %dl
+ jmp 1b
+
+1:
jmp hd_probe_error
final_init:
diff -ur -x 'Makefile*' -x 'config.*' grub-0.95+cvs20040624/stage2/builtins.c
grubme/stage2/builtins.c
--- grub-0.95+cvs20040624/stage2/builtins.c 2005-08-16 13:34:13 +0100
+++ grubme/stage2/builtins.c2005-08-16 13:57:44 +0100
@@ -2063,12 +2063,19 @@
src_part_start = part_start;
src_geom = buf_geom;
- if (! new_drive)
+ if (! new_drive) {
new_drive = src_drive;
- else if (src_drive != dest_drive)
-grub_printf ("Warning: the option `d' was not used, but the Stage 1 will"
-" be installed on a\ndifferent drive than the drive where"
-" the Stage 2 resides.\n");
+*((unsigned char *) (stage1_buffer + STAGE1_SOURCE_DRIVE)) =
+ GRUB_INVALID_DRIVE;
+ } else {
+ if (src_drive != dest_drive)
+ grub_printf ("Warning: the option `d' was not used, but the"
+ " Stage 1 will be installed on a\ndifferent"
+ " drive than the drive where the Stage 2"
+ " resides.\n");
+ *((unsigned char *) (stage1_buffer + STAGE1_SOURCE_DRIVE)) =
+ src_drive;
+ }
/* Set the boot drive. */
*((unsigned char *) (stage1_buffer + STAGE1_BOOT_DRIVE)) = new_drive;
-- System Information:
Debian Release: 3.1
Architecture: i386 (i586)
Kernel: Linux 2.6.8-2-386
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages grub depends on:
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libncurses5 5.4-4Shared libraries for terminal hand
-- debconf information:
* grub/install_boot_loader: true
grub/replace_other_boot_loader: false
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#321318: acknowledged by developer (Fixed in new package upload)
On Fri, Aug 05, 2005 at 03:14:48PM +0200, Marco van Zwetselaar wrote: > Just a minor point: since this bug is fixed by an upload, why do you > close it using email to its -done address? Because I failed to close it in the changelog. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#321318: hotkey-setup: package contains no binaries or (init) scripts
On Thu, Aug 04, 2005 at 10:31:17PM +0200, Marco van Zwetselaar wrote: > The package does not contain the init script that its README.Debian > refers to. As a consequence, it doesn't actually do anything. Gah. Sorry about that. I've uploaded a new version - I'll close once it's in the archive. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316487: debian-installer-manual: Missing copyright credit: Karsten M. Self for section C.4
Glenn Maynard <[EMAIL PROTECTED]> wrote: > On Fri, Jul 01, 2005 at 11:58:07PM +0100, Matthew Garrett wrote: >> Yes. And? > > So you think it's acceptable to have a work in main, whose license is > "if you're Debian, you're never allowed to remove this work, or I'll > sue you for an unrelated, already-fixed[1] past violation"? I don't > like throwing around overly loaded words, but I can't find any word > short of "extortion" that accurately represents what this seems to be. No. In that case I'd say "So sue us". Demanding that something never be removed is more unreasonable than rewriting something that we stole. Demanding acknowledgement isn't. Really. Listen to yourself. Are you honestly claiming that someone asking that we acknowledge his (involuntary) contribution to Debian is an unreasonable act? Are you honestly claiming that choosing to rewrite that text instead of giving due credit is not petty? >> Which bit of "We've been knowingly violating a license for over 2 years, >> and so we're the bad guys" is unclear here? > > Debian has offered to correct it, in a perfectly acceptable and legitimate > manner. The manner in which we've offered to correct it is plainly not perfectly acceptable to Karsten, otherwise it would have been accepted. > In my viewpoint, (a) is not wrong in any ethical or moral way > (legally, I don't know and would prefer not to guess); coercing Debian > maintainers to include a work in future releases against their will and > judgement is. You think it's ethical to rewrite a perfectly good section of text rather than give appropriate credit to the original author? I think you're mad. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316487: debian-installer-manual: Missing copyright credit: Karsten M. Self for section C.4
Glenn Maynard <[EMAIL PROTECTED]> wrote: > On Fri, Jul 01, 2005 at 11:08:24PM +0100, Matthew Garrett wrote: >> a) Remove the material concerned from the installation guide in woody >> and sarge and get new versions uploaded to the archive. Apologise >> profusely. Potentially still be sued. > d) Add attribution to the installation guide in woody and sarge, and > remove the material concerned from the archive for the next stable > release. Sure. That's fairly equivalent to (a). > This seems like "If you remove my work from your current version, I'll > sue you for your violation in the last version". I hope you can > understand why I don't believe that arrangement is acceptable--it's > no different than "if you don't give me $100, I'll sue you for your > violation in the last version". Yes. And? > I don't see (c) happening; if it is, then Karsten's complaint was > unclear (which shouldn't be surprising, given its length). Karsten > is asserting that a) is "doing the wrong thing", which is ridiculous. (c) /is/ happening. Karsten asked for attribution in 2003. And (a) /is/ doing the wrong thing - fixing the situation now doesn't excuse us from the guilt of having been violating his copyright for the past few years, especially when it was pointed out to us some time ago. We've been offered a reasonable way to settle the situation. Karsten's well within his rights to bring legal action, but instead he hasn't even threatened to put it on Slashdot. Which bit of "We've been knowingly violating a license for over 2 years, and so we're the bad guys" is unclear here? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316487: debian-installer-manual: Missing copyright credit: Karsten M. Self for section C.4
Glenn Maynard <[EMAIL PROTECTED]> wrote: > A past error does not prohibit the maintainer from excising any part > of the work, at his discretion. You don't get to say "you made a > mistake in the past, so you're not allowed to remove my work now". Regardless of what we do in future versions, we're currently distributing material in violation of a copyright holder's license. Our choices are pretty much: a) Remove the material concerned from the installation guide in woody and sarge and get new versions uploaded to the archive. Apologise profusely. Potentially still be sued. b) Add attribution to the current version of the guide. The copyright holder has indicated that he'd let the matter drop in that case. c) Ignore the issue. We are *breaking the law*. The correct response is "Oh, fuck, how can we fix this", not "Stop complaining, it's against our policy to attribute people so we'll remove your material instead". -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310833: [CAN-2005-1040] local root privilege escalation
I chatted to rml about this at LCA - it ought to only affect the Suse codepath, so I'm not too worried about it. I'll take another look to make sure that we're not affected. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306265: nstx_1.1-beta6-2(powerpc/unstable): FTBFS: assumes signedness of chars
On Thu, Apr 28, 2005 at 07:46:36PM +0300, Lars Wirzenius wrote: > The attached patch fixes the build problem. > > I may do an NMU tomorrow or next week, since we're close to a sarge > freeze (and in a 0-day NMU phase). Should be an innocent enough change. No problem - I'm the wrong side of a thin piece of string at the moment, so an NMU would be helpful. Thanks, -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304943: netapplet does not show signal strength
On Sat, Apr 16, 2005 at 06:38:50PM +0100, Johannes Jördens wrote: > names are for, however, they remain inactive (that is, neither a > percentage value nor its graphical bar representation is shown). > Other applets, such as "Wireless Link Monitor" or the gkrellm plugin > show the strength reliably, as does iwconfig. The issue is whether your driver returns the strength for networks that you aren't connected to. What does iwlist scan return? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#285112: Wish that netapplet grokked logical interfaces
On Wed, 2005-04-06 at 12:07 +0200, Thomas Hood wrote: > What is really needed is for netapplet to grok logical interfaces. > Currently when I click on the netapplet icon I get a list of physical > interfaces, labelled "Network Connections". If I click on one of these > names then netapplet seems to run (via netdaemon) "ifup " or > "ifdown " on these; then ifup uses its internal mapping > mechanism to assign a logical interface. SFAICT netapplet has no > awareness of logical interfaces or mapping. Below "Network Connections" > it displays a list of "Wireless Networks". If I click on these items > then netapplet sends out iwconfig commands. SFAICT this ignores the > information provided on "wireless" option lines in logical interface > definitions and reconfigures Wi-Fi cards directly. Yes. I'm unsure how to present logical interfaces in a reasonable way. ifupdown allows you to assign any logical interface to any physical interface, which allows a great deal of flexibility but is a bit of a UI nightmare. I'd prefer not to provide a second level of menus listing every logical interface if at all possible. > I don't know whether or not netapplet is aware that changing wireless > parameters can have consequences for whether or not "Network > Connections" should be up or not. E.g., if there are no access points > in range then wlan0 should be brought down, but netapplet does not bring > down wlan0 when I try the experiment. Indeed, I find that netapplet > does not succeed in switching wireless networks at all. But that is > another bug. Netapplet doesn't attempt to provide any sort of network control policy - networkmanager behaves more like this. This is a design decision rather than a bug. It leaves policy up to the underlying infrastructure (ifupdown and stuff like ifplugd) and allows the user to override some automatic decisions. I can't reproduce your issues with switching wireless networks. This may be a driver issue - ISTR that orinoco_cs doesn't like switching networks while the interface is up. Could you open a new bug for that issue? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303361: netapplet doesn't notice when interface activation fails
On Wed, 2005-04-06 at 12:28 +0200, Thomas Hood wrote: > I click on wlanp_0. The interface is not configured because the Wi-Fi > card is not associated to an access point. (Running "ifup wlanp_0" > from the command line yields "Ignoring unknown interface wlanp_0=none".) > Nevertheless, netapplet labels wlanp_0 as "active". ifup returns 0 in this case. It would probably make life easier if it didn't. In any case, I'll look at sanity checking that failure mode - thanks for the report. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302874: doesn't work with large packets
Package: nstx Version: 1.1-beta6-1 Severity: grave nstxd in sid is broken with any packets longer than 90 bytes. Fix it, you fool. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 Versions of packages nstx depends on: ii adduser 3.59 Add and remove users and groups ii libc6 2.3.2.ds1-16 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296369: ITP: spin -- Powerfull model checking and software verification tool
Eike Dehling <[EMAIL PROTECTED]> wrote: > " Spin is distributed in source form to encourage research in formal > verification, and to help a support friendly and open exchange of > algorithms, ideas, and tools. The software itself has a copyright from > Lucent Technologies and Bell Laboratories, and is distributed for > research and educational purposes only (i.e., no guarantee of any kind > is implied by the distribution of the code, and all rights are reserved > by the copyright holder). For this general use of Spin, no license is > required. No permission is granted for distribution, only use. You're permitted to download it - you're not permitted to pass it on any further. It may well be their intent that it be redistributable, but this notice doesn't say so. Your best bet would be to contact the copyright holders and ask for permission to distribute it. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281688: dasher: Eats my keymap
Just to check - are you quitting dasher correctly when doing this? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288782: dasher: missing Build-Depends ?
The package in the archive depends on at-spi on all architectures (judging by the buildd logs). I think this is probably down to at-spi changing somehow. Does libspi-dev still have the same shlibdeps? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289856: mdnsresponder: Wrong license
Steve Langasek <[EMAIL PROTECTED]> wrote:
> - The copyright license is terminated if you attempt to defend your patent
> rights against Apple.
It should be emphasised that this is the case if you defend /any/ patent
rights against Apple. It's not limited to software patents, and it's not
limited to patents that you claim are infringed by that given piece of
software. I think this goes too far (but lean towards believing that
termination of patent rights wouldn't be an unreasonable thing for Apple
to do)
> - The license requires you to publish any local modifications if you deploy
> public services based on the Covered Code, which discriminates against a
> field of endeavour.
This clause aims to deal with what is seen by many as a flaw in
traditional copyleft licenses. I don't think it's a terribly convincing
argument in itself - it's no more actively discriminatory than the GPL
("discriminates against people who want to provide closed-source
software"), so the discussion is really whether we want to encourage or
discourage that sort of license.
> - The license includes a choice of venue clause forcing all licensees to
> accept the jurisdiction of the Northern District of California, which is
> discriminatory against persons located outside this district by exposing
> them to unequal legal expense.
But most licenses discriminate against people who don't speak English,
or don't have legal training, or...
Again, in itself, it's not seeking to discriminate. It's clearly not
equivilent to a clause that says "This software may not be used by
employees of arms manufacturers", which is the sort of thing that DFSG 5
was supposed to deal with.
But I agree with your summary. It's not entirely clear that the APSL
contravenes the DFSG, but it's also not entirely clear that it should be
considered a free software license. I think a firm conclusion is going
to have to wait until we actually have a project-wide discussion of how
the DFSG should be interpreted nowadays, especially in the face of
issues that weren't considered when they were written.
--
Matthew Garrett | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291227: Patches nv.c, but no permission granted
Package: nvidia-kernel-source Severity: normal The source code in the nvidia provided kernel module has the following copyright text: /* _NVRM_COPYRIGHT_BEGIN_ * * Copyright 2001 by NVIDIA Corporation. All rights reserved. All * information contained herein is proprietary and confidential to NVIDIA * Corporation. Any use, reproduction, or disclosure without the written * permission of NVIDIA Corporation is prohibited. * * _NVRM_COPYRIGHT_END_ */ This provides no permission to modify the code, so distribution of modified code is likely to be a copyright violation. I can't find any grant of permission to modify in the other license files. Is there somewhere else that provides this permission? -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-2-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290366: bootloader doesn't set VESA mode on x86, so vesafb is never loaded
Package: debian-installer Severity: normal For vesafb to work, the kernel bootloader needs to set up a VESA mode. This is typically done by passing something like vga=0x301 (which will set a 256 colour 640x480 display). If this succeeds, vesafb should load and work correctly. Otherwise, the system will fall back to vga16fb when the vesafb modprobe fails. Currently, vga16fb is loaded unconditionally. I have a machine here that works correctly with vesafb but fails with vga16fb. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
