Bug#523716: [pkg-nvidia-devel] Bug#523716: Another build failure...
On April 13, 2009 11:14:12 Lennart Sorensen wrote: That is no longer a complete set of headers and you can't build against it like that. The kernel team says that is no longer supported. This is what I've done for a long time (changing the kernel in question each time, obviously). Why not use module-assitant? I sure didn't test that old way of doing it when I rewrote the build scripts. I used module-assistant and a hacked up version of linux-modules-nonfree-2.6 and both worked. I did not test make-kpkg or doing it manually (which I stopped doing years ago when I discovered module-assistant). I guess I'll switch to module-assistant - not a problem. But as was pointed out elsewhere, it might be best to make the requirement explicit. Cheers, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#517297: hplip udev rules never match
Thanks for uploading 3.9.2. However, I noticed that the udev rules supplied by the package (z60_hplip.rules, or hplip.udev in the debian folder of the source) still don't ever match, meaning that my printer's node isn't in the lp group, meaning it won't work. Replacing the file with my new version allows my printer to work again. Any reason why the new file I supplied wasn't used? I'm happy to answer questions. Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#517297: [Pkg-hpijs-devel] Bug#517297: hplip udev rules never match
Hi, Just a few observations: 1) The rules in the hplip 3.9.2-1ubuntu1 package don't work for me; the printer node remains in the root group. 2) Using ATTR doesn't seem to work on my system, but ATTRS does. To be honest, I'm not sure exactly what the difference is, but changing back and forth and cycling the printer makes the difference clear. 2) The upstream (and my suggested) rules match on SUBSYSTEM=usb_device as well as SUBSYSTEM=usb; I can report that if I configure the rules to match only SUBSYSTEM=usb, then the rules don't match my printer. I can't find any documentation of when usb_device became relevant, but again, I'm going with what works. My suggested rules break from upstream's in that they don't match OWNER, and don't muck around with sane. As for the rules' order (40-* vs. 55-* vs. z60*) I have no opinion; it might be worth ensuring that the scanner package's rules have a chance to match after hplip's, so that the nodes of multifunction devices are owned by scanner, not lp (if my understanding of udev is correct). Hope that helps, Christopher Martin On March 11, 2009 05:01:41 Till Kamppeter wrote: Mark Purcell wrote: On Tuesday 10 March 2009 10:11:17 Christopher Martin wrote: I'm happy to answer questions. Chris, Till, Seems that the udev rules are again causing problems. Lots of Debian bugs reported :-( Till. You reinstated our own udev rules with 2.8.12-1ubuntu5 which fixed a number of issues for ubuntu. Do we need to rework again, or are upstream 3.9.2 udev rules good? If possible, I wouldn't like to merge from upstream and would rather pass fixes like the enclosed directly upstream: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517297 Aaron, What is the best way we can work with you together on this? Mark I returned to having Ubuntu's own UDEV rules file due to the following bug reports: https://bugs.launchpad.net/bugs/319660 Cannot edit configuration from udev rules https://bugs.launchpad.net/bugs/319661 Must not set OWNER in udev rules https://bugs.launchpad.net/bugs/319662 udev rules should be 40-*.rules unless there's a good reason https://bugs.launchpad.net/bugs/319665 Uses deprecated SYSFS instead of ATTR Till signature.asc Description: This is a digitally signed message part.
Bug#508934: gwenview: Pause to load images (or no images?)
I'm sorry, could you please restate the problem? I didn't quite get the nature of the problem from your description. Thanks! On December 16, 2008 14:10:22 psycheye wrote: Package: gwenview Version: 1.4.2-5+b1 Severity: normal In the file manager, when I click on a folder that contains lot of images there's a long pause, so I don't if gwenview loading images or there aren't any images. thanks psycheye -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505726: Not fixed - symlink still not in correct location
reopen 505726 severity 505726 important stop Since the plugin still does not work in Iceweasel without manual intervention, this bug should not be closed. Instead of placing the symlink in /usr/lib/xulrunner-addons/plugins, the package should place it in /usr/lib/mozilla/plugins (as was explained by others in this report). Then the plugin will work out-of-the-box. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517297: hplip udev rules - patch fixing never matches problem
tags 517297 patch
stop
Hello,
Borrowing from the hplip upstream udev rules (included in the hplip
source), and looking at the udev documentation, I've come up with the
following new hplip.rules file (also provided as a patch against the
current file, debian/hplip.udev) which updates them so that they now
work with recent kernels and udev versions (while leaving out some of
the more esoteric changes in the upstream rules).
Critically, the rules now handle both SUBSYSTEM=usb and
SUBSYSTEM=usb_device. They also use ATTRS, not ATTR. ATTR doesn't
seem to work at all for what we ask of it.
With this update, my printer's node is now correctly in the lp group,
allowing hplip to work; before, printing simply wasn't possible as a
regular user. I don't recall when exactly things broke, but it's been a
while...
Please include this fix in the next hplip upload.
Thanks,
Christopher Martin
--- hplip.udev.orig
+++ hplip.udev.new
@@ -1,118 +1,126 @@
# Udev rules file for HP printer products.
+ACTION!=add, GOTO=hpmud_rules_end
+SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, GOTO=pid_test
+SUBSYSTEM!=usb_device, GOTO=hpmud_rules_end
+
+LABEL=pid_test
+
# Check for AiO products (0x03f0xx11).
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==??11, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==??11, GROUP=lp
# Check for Photosmart products without wildcard since cameras and scanners also used (0x03f0xx02).
# The xx02 pid has been retired so this explicit list should not change.
# photosmart_d2300_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==c302, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==c302, GROUP=lp
# photosmart_100
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3802, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3802, GROUP=lp
# photosmart_1115
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3402, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3402, GROUP=lp
# photosmart_1215
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3202, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3202, GROUP=lp
# photosmart_1218
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3302, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3302, GROUP=lp
# photosmart_130
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3902, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3902, GROUP=lp
# photosmart_1315
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3602, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3602, GROUP=lp
# photosmart_140_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1002, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1002, GROUP=lp
# photosmart_230
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3502, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3502, GROUP=lp
# photosmart_240_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1102, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1102, GROUP=lp
# photosmart_320_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1202, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1202, GROUP=lp
# photosmart_330_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1602, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1602, GROUP=lp
# photosmart_370_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1302, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1302, GROUP=lp
# photosmart_380_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1702, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1702, GROUP=lp
# photosmart_420_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1502, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1502, GROUP=lp
# photosmart_470_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1802, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1802, GROUP=lp
# photosmart_7150
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3a02, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3a02, GROUP=lp
# photosmart_7200_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==b002, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==b002, GROUP=lp
# photosmart_7345
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==2002, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==2002, GROUP=lp
# photosmart_7350
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3c02, GROUP
Bug#517297: hplip udev rules - patch fixing never matches problem
Hello,
I've slightly updated the files to reflect a change in upstream's own
rules from 2.8.12 to 3.9.2 (they added a new device). Everything else
is the same.
Thanks,
Christopher Martin
# Udev rules file for HP printer products.
ACTION!=add, GOTO=hpmud_rules_end
SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, GOTO=pid_test
SUBSYSTEM!=usb_device, GOTO=hpmud_rules_end
LABEL=pid_test
# Check for AiO products (0x03f0xx11).
ATTRS{idVendor}==03f0, ATTRS{idProduct}==??11, GROUP=lp
# Check for Photosmart products without wildcard since cameras and scanners
also used (0x03f0xx02).
# The xx02 pid has been retired so this explicit list should not change.
# photosmart_d2300_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c302, GROUP=lp
# photosmart_100
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3802, GROUP=lp
# photosmart_1115
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3402, GROUP=lp
# photosmart_1215
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3202, GROUP=lp
# photosmart_1218
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3302, GROUP=lp
# photosmart_130
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3902, GROUP=lp
# photosmart_1315
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3602, GROUP=lp
# photosmart_140_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1002, GROUP=lp
# photosmart_230
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3502, GROUP=lp
# photosmart_240_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1102, GROUP=lp
# photosmart_320_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1202, GROUP=lp
# photosmart_330_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1602, GROUP=lp
# photosmart_370_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1302, GROUP=lp
# photosmart_380_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1702, GROUP=lp
# photosmart_420_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1502, GROUP=lp
# photosmart_470_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1802, GROUP=lp
# photosmart_7150
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3a02, GROUP=lp
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3b02, GROUP=lp
# photosmart_7200_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==b002, GROUP=lp
# photosmart_7345
ATTRS{idVendor}==03f0, ATTRS{idProduct}==2002, GROUP=lp
# photosmart_7350
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3c02, GROUP=lp
# photosmart_7400_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==b802, GROUP=lp
# photosmart_7550
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3e02, GROUP=lp
# photosmart_7600_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==b202, GROUP=lp
# photosmart_7700_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==b402, GROUP=lp
# photosmart_7800_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c002, GROUP=lp
# photosmart_7900_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==b602, GROUP=lp
# photosmart_8000_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c102, GROUP=lp
# photosmart_8100_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==ba02, GROUP=lp
# photosmart_8200_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c202, GROUP=lp
# photosmart_8400_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==bb02, GROUP=lp
# photosmart_8700_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==bc02, GROUP=lp
# photosmart_a310_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1d02, GROUP=lp
# photosmart_a320_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1e02, GROUP=lp
# photosmart_a430_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1902, GROUP=lp
# photosmart_a440_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1f02, GROUP=lp
# photosmart_a510_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1a02, GROUP=lp
# photosmart_a520_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==2602, GROUP=lp
# photosmart_a530_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==2b02, GROUP=lp
# photosmart_a610_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1b02, GROUP=lp
# photosmart_a620_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==2702, GROUP=lp
# photosmart_a630_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==2c02, GROUP=lp
# photosmart_a710_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1c02, GROUP=lp
# photosmart_a820_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==2902, GROUP=lp
# photosmart_d5060_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c802, GROUP=lp
# photosmart_d5100_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c402, GROUP=lp
# photosmart_d6100_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c502, GROUP=lp
# photosmart_d7100_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c602, GROUP=lp
# photosmart_d7300_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c702, GROUP=lp
# photosmart_pro_b8300_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==be02, GROUP=lp
# photosmart_b8800_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==d002, GROUP=lp
# photosmart_pro_b9100_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==bd02, GROUP=lp
# Photosmart_B8500_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==d102, GROUP=lp
# Check for Business Inkjet products (0x03f0xx12).
ATTRS{idVendor}==03f0, ATTRS{idProduct}==??12, GROUP=lp
# Check for Deskjet products
Bug#560413: RM: gwenview-i18n -- obsolete, part of kde-l10n as of KDE4
Package: ftp.debian.org Severity: normal Please remove the gwenview-i18n source and binary packages from unstable. Rationale: When gwenview built against KDE3 (now only in stable) it was an independent package and so had its own internationalization package. Now, however, gwenview is part of KDE4 (unstable/testing) and so gwenview's translations are provided by the kde-l10n-** packages. Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#527383: Status?
On December 10, 2009 04:50:12 Jan Jabbery wrote: What's the status on this bug? It seems pretty simple to close and the conflict it produces, prevents Debian liveCD's from being created with user-chosen locales if you use KDE4 and gwenview on them. My apologies; the original request slipped through the net on my end. I've filed the appropriate bug (#560413) for removal. Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#590840: libxine1-misc-plugins: assertion error in kaffeine 0.8.7
I suspect that the crash is related to this problem: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2010-January/014891.html Thus it may be a xine-lib bug after all, as I don't see any InitializeMagick() - or DestroyMagick() for that matter - calls in xine-lib's code. I would guess that libxinevdec/image.c would be the appropriate place to add them. Christopher Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623516: New upstream release of kaffeine
Package: kaffeine Version: 1.1-2 Severity: wishlist Just FYI, but version 1.2.2 of kaffeine has been released. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766979: O: imwheel -- program to support non-standard buttons on mice in Linux
Package: wnpp Version: 1.0.0pre12-12 Severity: normal IMWheel needs a new maintainer.
Bug#764733: ETA on Google API keys fix?
Hi, Do you have an ETA on fixing the (apparent) absence of Google API Keys in the sid package? I assume (correct me if I'm wrong) that it is fixable. I had to revert to chromium in testing to get my browser to start (segfault since I was logged in to chromium previously), and am unwilling to work around this by nuking my ~/.config/chromium and re-configuring. Thanks, Christopher Martin
Bug#764793: Possible fix for HTML5 video in Chromium?
-4 is a large rewrite, and something may by missing from the GYP_DEFINES now. Comparing the before and after rules files should help. Best wishes, Mike I suspect that you're correct. While Vimeo works here, I did notice that the Youtube HTML5 player had stopped working; it automatically reverted to using Flash. The attached one-liner patch to debian/rules seems to address that problem on my system. This line in debian/rules was present in older Chromium packaging. Cheers, Christopher Martin --- a/debian/rules +++ b/debian/rules @@ -64,6 +64,7 @@ # enable proprietary codecs defines+=proprietary_codecs=1 \ + ffmpeg_branding=Chrome \ # icu defines+=use_system_icu=0 \
Bug#748867: Fix/workaround for Google API key problem and crash
Hello, The attached patch to debian/rules restores the ability to sign-in to Chromium, by re-adding the Debian Google API keys that used to be included in older Chromium packaging debian/rules. The patch also resolves the crash that occurred on sign-in with Chromium built against the system protobuf (the solution being, simply enough, not to use the system protobuf - this issue was explained further in Debian bug #764911). With these fixes applied and Chromium re-built, I can upgrade from Chromium 37 to 38 without any need to delete ~/.config/chromium or any such hassle. Hope this helps. Cheers, Christopher Martin --- a/debian/rules +++ b/debian/rules @@ -42,6 +42,11 @@ linux_link_libspeechd=1 \ linux_link_gnome_keyring=1 \ +# Debian Google API Key +defines+=google_api_key=AIzaSyCkfPOPZXDKNn8hhgu3JrA62wIgC93d44k \ + google_default_client_id=811574891467.apps.googleusercontent.com \ + google_default_client_secret=kdloedMFGdGla2P1zacGjAQh \ + # system libraries to use defines+=use_system_re2=1 \ use_system_yasm=1 \ @@ -58,7 +63,7 @@ use_system_libsrtp=1 \ use_system_jsoncpp=1 \ use_system_libevent=1 \ - use_system_protobuf=1 \ + use_system_protobuf=0 \ use_system_harfbuzz=1 \ use_system_xdg_utils=1 \
Bug#826071: khotkeys built without XTest
Package: khotkeys Version: 4:5.6.4-1 Hello, Now that 5.6 supports gestures properly again, I turned them back on and found that I could no longer middle click: when not performing a gesture with the middle mouse button, khotkeys wasn't passing my middle clicks through to the underlying applications. A quick search uncovered this: https://www.reddit.com/r/kde/comments/4gffxp/mouse_gestures_break_middle_click Essentially, khotkeys needs to be built with XTest support. It will then pass clicks through to the underlying application once it has determined that no gesture is being made. Armed with this knowledge, I was able to solve the issue by rebuilding khotkeys myself after installing libxtst-dev . The solution thus appears to be simple - add that package to the khotkeys build-depends. Thanks for your work packaging KDE. Christopher Martin
Bug#855801: zfs-mount.service / zfs.target should be WantedBy=local-fs.target, not multi-user.target
Package: zfsutils-linux Version: 0.6.5.9-2 Currently, the zfs-mount.service is started through the zfs.target, which is itself in turn WantedBy=multi-user.target. This happens after local-fs.target is reached (which is when local file systems are expected to be mounted). As a result, there is no guarantee that a daemon or other service, many of which are also started through multi-user.target, will be able to see ZFS mounts when they launch. This can cause problems (e.g. a DLNA server that wants to serve files stored on a ZFS array). Instead, I would suggest that zfs-mount.service or the zfs.target (whichever makes most sense) be WantedBy=local-fs.target, thereby mounting ZFS along with all the other local filesystems. That way, daemons etc. started later, through multi-user.target, will reliably be able see the system's ZFS mounts when they launch. Thanks, Christopher Martin
Bug#911191: wide-dhcpv6-client: patch adding support for a random interface id
Package: wide-dhcpv6-client
Version: 20080615-21
Severity: wishlist
Tags: patch, ipv6
Please find attached a patch that adds a new feature to
wide-dhcpv6-client, namely an option ("ifid-random") in the
prefix-interface section of dhcp6c.conf to generate a random interface
id on startup. This is useful if you wish to have the final 64 bits of
your IPv6 address change from time to time - a sort of very rough
equivalent of IPv6 Privacy Extensions. If you do not add "ifid-random"
to the config file, then nothing about the client's current behaviour
changes.
Note that if your prefix-interface section has both the current "ifid
X" option (where X is whatever number you want to manually assign as
your interface id) and the new "ifid-random" option, then the
interface id is randomized and "ifid X" is ignored.
Thanks,
Christopher Martin
--- a/cfparse.y
+++ b/cfparse.y
@@ -104,7 +104,7 @@
%token INTERFACE IFNAME
%token PROFILE PROFILENAME
-%token PREFIX_INTERFACE SLA_ID SLA_LEN IFID DUID_ID
+%token PREFIX_INTERFACE SLA_ID SLA_LEN IFID IFID_RAND DUID_ID
%token ID_ASSOC IA_PD IAID IA_NA
%token ADDRESS
%token REQUEST SEND ALLOW PREFERENCE
@@ -1064,6 +1064,13 @@
l->num = (u_int64_t)$2;
$$ = l;
}
+ | IFID_RAND EOS
+ {
+ struct cf_list *l;
+
+ MAKE_CFLIST(l, IFPARAM_IFID_RAND, NULL, NULL);
+ $$ = l;
+ }
;
ianaconf_list:
--- a/cftoken.l
+++ b/cftoken.l
@@ -244,6 +244,7 @@
sla-id { DECHO; return (SLA_ID); }
sla-len { DECHO; return (SLA_LEN); }
ifid { DECHO; return (IFID); }
+ifid-random { DECHO; return (IFID_RAND); }
/* duration */
infinity { DECHO; return (INFINITY); }
--- a/config.c
+++ b/config.c
@@ -521,6 +521,15 @@
}
break;
case IFPARAM_IFID:
+ if (use_default_ifid) {
+for (i = sizeof(pif->ifid) - 1; i >= 0; i--)
+ pif->ifid[i] = (cfl->num >> 8*(sizeof(pif->ifid) - 1 - i)) & 0xff;
+use_default_ifid = 0;
+ }
+ break;
+ case IFPARAM_IFID_RAND:
+ for (i = 0; i < pif->ifid_len ; i++)
+cfl->num = cfl->num*2 + rand()%2;
for (i = sizeof(pif->ifid) -1; i >= 0; i--)
pif->ifid[i] = (cfl->num >> 8*(sizeof(pif->ifid) - 1 - i)) & 0xff;
use_default_ifid = 0;
--- a/config.h
+++ b/config.h
@@ -266,7 +266,7 @@
DECL_PREFIX, DECL_PREFERENCE, DECL_SCRIPT, DECL_DELAYEDKEY,
DECL_ADDRESS,
DECL_RANGE, DECL_ADDRESSPOOL,
- IFPARAM_SLA_ID, IFPARAM_SLA_LEN, IFPARAM_IFID,
+ IFPARAM_SLA_ID, IFPARAM_SLA_LEN, IFPARAM_IFID, IFPARAM_IFID_RAND,
DHCPOPT_RAPID_COMMIT, DHCPOPT_AUTHINFO,
DHCPOPT_DNS, DHCPOPT_DNSNAME,
DHCPOPT_IA_PD, DHCPOPT_IA_NA, DHCPOPT_NTP,
--- a/dhcp6c.conf.5
+++ b/dhcp6c.conf.5
@@ -453,6 +453,15 @@
prefix and the sla-id to form a complete interface address. The
default is to use the EUI-64 address of the
.Ar interface .
+.It Xo
+.Ic ifid-random ;
+.Xc
+This statement instructs the client to generate a completely random
+interface id. This will override the
+.Ic ifid
+statement, if present. The resulting random interface id will be combined
+with the delegated prefix and the sla-id to form a complete interface
+address.
.El
.El
.\"
Bug#913517: hplip: patch to support IPv6
Package: hplip
Version: 3.18.10+dfsg0-2
Severity: wishlist
Tags: patch ipv6
Please see https://bugs.launchpad.net/hplip/+bug/1724089 for the
original report, which includes a patch that adds IPv6 support to
libhpmud.
The patch ensures that libhpmud properly resolves IPv6 addresses and
hostnames. I've tested it against the latest hplip (3.18.10) and it
works well.
Please consider merging it into Debian's package.
Thanks,
Christopher Martin
From e7bc4bd41239d2e60f0406415ae0cc3d7a40cc2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Thomas=20B=C3=A4chler?=
Date: Wed, 30 Aug 2017 00:25:32 +0200
Subject: [PATCH] Add ipv6 support to libhpmud
---
io/hpmud/jd.c | 147 ++
1 file changed, 45 insertions(+), 102 deletions(-)
diff --git a/io/hpmud/jd.c b/io/hpmud/jd.c
index 06f5072ee..45d6d36cc 100644
--- a/io/hpmud/jd.c
+++ b/io/hpmud/jd.c
@@ -332,44 +332,49 @@ enum HPMUD_RESULT __attribute__ ((visibility ("hidden"))) jd_channel_close(mud_d
* JetDirect channel functions.
*/
+static int try_connect(const char* address, int port)
+{
+ int s = -1;
+ struct addrinfo *addrinfo = NULL;
+
+ struct addrinfo hints;
+ bzero(, sizeof(struct addrinfo));
+ hints.ai_family = AF_UNSPEC;
+ hints.ai_socktype = SOCK_STREAM;
+ hints.ai_protocol = IPPROTO_TCP;
+ hints.ai_flags = AI_ADDRCONFIG;
+ char service[6];
+ snprintf(service, sizeof(service) / sizeof(service[0]), "%d", port);
+ getaddrinfo(address, service, , );
+
+ const struct addrinfo *a;
+ for(a = addrinfo; a != NULL; a = a->ai_next)
+ {
+ if ((s = socket(a->ai_family, a->ai_socktype, a->ai_protocol)) == -1)
+ continue;
+ if (connect(s, a->ai_addr, a->ai_addrlen) == 0)
+ break;
+ close(s);
+ s = -1;
+ }
+ if (addrinfo != NULL)
+ freeaddrinfo(addrinfo);
+ return s;
+}
+
enum HPMUD_RESULT __attribute__ ((visibility ("hidden"))) jd_s_channel_open(mud_channel *pc)
{
mud_device *pd = >device[pc->dindex];
- struct sockaddr_in pin,tmp_pin;
- struct hostent *he;
char buf[HPMUD_LINE_SIZE];
int r, len, port;
enum HPMUD_RESULT stat = HPMUD_R_IO_ERROR;
- bzero(_pin, sizeof(tmp_pin));
- bzero(, sizeof(pin));
- pin.sin_family = AF_INET;
-
- if(inet_pton(AF_INET, pd->ip, &(tmp_pin.sin_addr))) //Returns 0 when IP is invalid.
-pin.sin_addr.s_addr = inet_addr(pd->ip);
- else
- {
-if((he=gethostbyname(pd->ip)) == NULL)
-{
-BUG("gethostbyname() returned NULL\n");
-goto bugout;
-}
-
-pin.sin_addr = *((struct in_addr *)he->h_addr);
- }
-
switch (pc->index)
{
case HPMUD_PRINT_CHANNEL:
port = PrintPort[pd->port];
- pin.sin_port = htons(port);
- if ((pc->socket = socket(AF_INET, SOCK_STREAM, 0)) == -1)
- {
-BUG("unable to open print port %d: %m %s\n", port, pd->uri);
-goto bugout;
- }
- if (connect(pc->socket, (struct sockaddr *), sizeof(pin)) == -1)
- {
+ if ((pc->socket = try_connect(pd->ip, port)) == -1)
+ {
BUG("unable to connect to print port %d: %m %s\n", port, pd->uri);
goto bugout;
}
@@ -379,14 +384,7 @@ enum HPMUD_RESULT __attribute__ ((visibility ("hidden"))) jd_s_channel_open(mud_
port = ScanPort1[pd->port];
else
port = ScanPort0[pd->port];
- pin.sin_port = htons(port);
-
- if ((pc->socket = socket(AF_INET, SOCK_STREAM, 0)) == -1)
- {
-BUG("unable to open scan port %d: %m %s\n", port, pd->uri);
-goto bugout;
- }
- if (connect(pc->socket, (struct sockaddr *), sizeof(pin)) == -1)
+ if ((pc->socket = try_connect(pd->ip, port)) == -1)
{
BUG("unable to connect to scan err=%d port %d: %m %s\n", errno, port, pd->uri);
goto bugout;
@@ -409,13 +407,7 @@ enum HPMUD_RESULT __attribute__ ((visibility ("hidden"))) jd_s_channel_open(mud_
port = GenericPort1[pd->port];
else
port = GenericPort[pd->port];
- pin.sin_port = htons(port);
- if ((pc->socket = socket(AF_INET, SOCK_STREAM, 0)) == -1)
- {
-BUG("unable to open port %d: %m %s\n", port, pd->uri);
-goto bugout;
- }
- if (connect(pc->socket, (struct sockaddr *), sizeof(pin)) == -1)
+ if ((pc->socket = try_connect(pd->ip, port)) == -1)
{
BUG("unable to connect to port %d: %m %s\n", port, pd->uri);
goto bugout;
@@ -450,13 +442,7 @@ enum HPMUD_RESULT __attribute__ ((visibility ("hidden"))) jd_s_channel
Bug#913517: hplip: patch to support IPv6
You're no doubt right that there's scope for improvement, and I don't want to go too far in defending a patch that I didn't write myself. But I would note that, as I understand matters, the patched hplip would only use IPv6 if either an IPv6 address was explicitly passed, or if the hostname resolved to an IPv6 address (say in /etc/hosts - which is what I tested). If that results in problems, then the system is arguably misconfigured elsewhere. These are (presumably most of the time) local network printers we're dealing with, so the state of their IPv6 support is known and controllable. One possibility might be to test matters via an upload to experimental after the next release and watch for reports of breakage. Cheers, Christopher Martin On Mon, Nov 12, 2018 at 6:40 AM Julian Andres Klode wrote: > > On Sun, Nov 11, 2018 at 02:47:12PM -0500, Christopher Martin wrote: > > Package: hplip > > Version: 3.18.10+dfsg0-2 > > Severity: wishlist > > Tags: patch ipv6 > > > > Please see https://bugs.launchpad.net/hplip/+bug/1724089 for the > > original report, which includes a patch that adds IPv6 support to > > libhpmud. > > > > The patch ensures that libhpmud properly resolves IPv6 addresses and > > hostnames. I've tested it against the latest hplip (3.18.10) and it > > works well. > > Having had the experience with dealing with IPv6 support in apt, I am not > convinced it's a good idea. The assumption that > > "The system's C library automatically selects the appropriate addresses (for > example, it omits ipv6 addresses if there is no ipv6 connectivity)." > > is wrong. We've heard a lot of reports from people without _working_ > IPv6 for which apt did not work, which forced me to implement a variant > of happy eyeballs. > > The patch in question does not try multiple address families in parallel, > nor does it seem to have any time out at all, meaning it will get stuck > indefinitely trying to connect to a broken ipv6 host. > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en
Bug#917464: New upstream release available
Package: rygel Version: 0.36.2-3 Severity: wishlist Version 0.37.1 has been released. Thanks, Christopher Martin
Bug#918658: [networkd] crash on resume in 240
Package: systemd Version: 240-2 Severity: normal Tags: patch After upgrading to systemd 240, networkd started crashing when resuming from a suspended state. About 30 seconds (give or take) after resume, systemd restarted networkd and thus brought the network back up, but the damage had been done. This is the error from the journal: systemd-networkd[458]: Assertion 'IN_SET(link->state, LINK_STATE_CONFIGURING, LINK_STATE_FAILED, LINK_STATE_LINGER)' failed at ../src/network/networkd-link.c:934, function address_handler(). Aborting. The same error was reported and fixed upstream as https://github.com/systemd/systemd/issues/11272, although the reported circumstances were different. Regardless, fixes have been committed upstream, and grabbing the latest version of the relevant file (systemd/src/network/networkd-link.c) and rebuilding systemd fixes the issue on my machine as well. I bring this to your attention only because the freeze is near and 241 may be a ways off... Thanks, Christopher Martin
Bug#917706: nfs-utils: New upstream release available
Source: nfs-utils Version: 1:1.3.4-2.3 Severity: wishlist Upstream has released 2.3.3 and is getting close to 2.3.4, while Debian remains on 1.3.4, which was released in mid-2016. An update in time for buster would be very much appreciated. Thanks, Christopher Martin
Bug#925465: gerbera: New upstream release available (1.3.0)
Package: gerbera Version: 1.1.0+dfsg-3 Severity: wishlist Upstream has released version 1.3.0. Even if it's too late for buster, having the new version available would be helpful. Thanks, Christopher Martin
Bug#923461: hostapd@.service can start too soon; should wait until device exists
Package: hostapd Version: 2.7+git20190128+0c1e29f-1 Severity: normal hostapd@.service: [Unit] Description=Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator (%I) -After=network.target +After=network.target sys-subsystem-net-devices-%i.device BindsTo=sys-subsystem-net-devices-%i.device The change above fixes a problem whereby the service will often run before USB wifi devices are detected and setup, resulting in failure. Telling the service to wait until after the device in question exists solves the problem. (The problem may not always be noticeable because the service will restart every two seconds, so it will eventually work, but that's hardly the best solution.) Thanks, Christopher Martin
Bug#995305: wine: New upstream release available (6.0.1)
Package: wine Version: 5.0.3-3 Severity: wishlist Hello, Wine upstream has released 6.0.1 (stable), while Debian remains on 5.0.3. An update would be great. Thanks, Christopher Martin
Bug#1020598: rtkit should depend on polkitd instead of policykit-1
Package: rtkit Version: 0.13-4 rtkit depends on policykit-1, which is now a transitional package that pulls in both polkitd and pkexec. Please update rtkit to depend directly on polkitd, thereby helping users remove pkexec. Thanks.
