Bug#1065926: Moving python-docker 5.0.3-1 to Python 3.12 will result in breaking changes
Hello! I came across this bug as I was writing up Ubuntu bug 2061929. Unfortunately, python-docker 5.0.3-1 will break if Python3 moves to 3.12. There are at least two different issues: • python-docker 5.0.3 relies on code from distutils, at runtime. The workaround for this is to rewrite the code, or to instead rely on python3-setuptools. • python-docker uses the requests & urllib3 modules in ways that break in newer versions. The breakage is in how the docker module talks to local Docker daemons through a UNIX socket. The only way to resolve this is a code change. There may be other breakages with python-docker 5.x and Python 3.12; I cannot say for certain. I came across this with Ubuntu 24.04, because they moved python3 to 3.12. More details, along with possible patches, can be found in https://bugs.launchpad.net/ubuntu/+source/python-docker/+bug/2061929 -- ~ Karl Kornel
Bug#907536: Update fstab template & docs to mention systemctl daemon-reload
Package: mount Version: 2.25.2-6 Severity: wishlist Tags: d-i Hello! I have a kindof-weird request, related to systemd and the documentation around /etc/fstab. I'd like to request that the stock /etc/fstab file include a note to run `systemctl daemon-reload` if you make changes to the file, but do not reboot afterwards. As has been mentioned in https://github.com/systemd/systemd/issues/7291 (among other places), when systemd is started during system boot—and when the daemon is reloaded with `systemctl daemon-reload`—generators (including, but not limited to, systemd-fstab-generator(8)) read /etc/fstab and generate unit files appropriately. If the sysadmin modifies /etc/fstab, but does not reboot, things may not work as expected. systemd-fstab-generator(8) makes an reference to systemd.swap(5), but our group has also experienced weirdnesses with NFS mounts, particularly when we're using NFSv4 and the krb5 security types, which require various rpc services be started before the mount can take place. Since people (including, most of the time, me!) forget about the link between system and /etc/fstab, I would like to request that a short note be placed in various places related to the fstab file, saying that, if the system isn't going to be rebooted, asking that at least `systemctl daemon-reload` after making any changes. I can think of three places in Debian where it would be worth mentioning this: • The /etc/fstab file generated during installation (that's why I added the `d-i` tag). • The fstab(5) man page. • The examples in the /usr/share/doc/mount/examples directory. I did some searching around outside of Debian, and I found that RHEL made a similar change, except they modified their administrator guides. The change was made earlier this year, in https://bugzilla.redhat.com/show_bug.cgi?id=1566088 If you have any questions about my request, please don't hesitate to reach out! -- ~ A. Karl Kornel Stanford Research Computing Center University IT, Stanford University
Bug#886806: intel-microcode: New version 20180108 published
Package: intel-microcode Version: 3.20171215.1 Severity: grave Tags: security Hello! In the ancient past (last week…), Mr. Holschuh mentioned, “I expect an official release from Intel soon, hopefully with updates for everything.”. Well, it looks like there has been a release! The data file version is 20180108. The microcode download page is https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File -- A. Karl Kornel | System Administrator Research Computing | Stanford University
Bug#851103: slurm account's UID conflicts with a user -- Allow setting a different ID at install time
Source: slurm-llnl Version: 16.05.8-1 Severity: wishlist Tags: patch Hello! We are in the process of setting up a new cluster, which will be available to many Stanford people. As part of setting it up, I discovered that UID 64030 (which is normally used for SLURM) is already in use by a previous student! The student has graduated, so the UID is no longer active, but if the student ever comes back, then he will get that UID again, which will cause problems. (By the way, I say that because the cluster uses central LDAP for account information, so giving him a new UID would be difficult.) The easiest thing to do would be to make a local modification to the existing preinst script, replacing “64030” with a different UID (I already have one allocated). But, I think the better way to do it is to make the preinst script prompt the user for an ID, and then use that! This also means that I can offer the script for you to take upstream, which is what I’m doing now! Here’s how things work: 1) If an account called “slurm” already exists, and a group called “slurm” already exists, then the package install takes place. This is actually a break from previous behavior. 2) Ask the user to provide an ID. If no ID is provided (because the user cleared the field, because a noninteractive install is happening, etc.), then default to ID 64030. 3) Check for non-numeric characters in the response. If any are found, notify the user and mark an error. 4) Check if the ID is already in use, either for a user or a group. If the ID is in use, notify the user and mark an error. 5) If no errors were found, go to the next step. If there have been three failed attempts, then error out the install/upgrade. Otherwise, increase the priority of the query, and go back to Step 2. 6) Add the user/group, as a system account, and without a home directory. As I mentioned, the biggest change between the original script, and my proposal, is that two previous checks have been removed: * There was a check to see if the slurm account had a home directory; if it did, then (under certain conditions) the home directory is changed to “/nonexistent”. * There was a check to see if the existing slurm account had UID and GID 64030. Both of those checks were removed under the idea that, if an account already exists, it should not be messed with. I would really appreciate it if people could try out this change. I have tried this many times on the new cluster (which runs Ubuntu Xenial), but this patch adds a lot of complexity, so I think other people should try it before it gets applied (assuming you are willing to take the patch). NOTE: This patch requires that you have already applied the patches from bug 850891. I definitely think bug 850891 should be resolved before this one, because that bug moves the same code from three preinst scripts into one. Finally, it is possible for the text to be translated! If anyone is interested in making translations, information is available here: http://www.fifi.org/doc/debconf-doc/tutorial.html#AEN34 (see the section called “Localizing the templates file”). I look forward to any comments that you have. Thank you very much! -- A. Karl Kornel | System Administrator Research Computing | Stanford University +1 (650) 736-9327 0001-Allow-custom-ID-for-slurm-user.patch Description: 0001-Allow-custom-ID-for-slurm-user.patch
Bug#850891: Additional patch, to cover slurmdbd's duplicate code
Hi Rémi, (I hope the é comes through the email properly!) If I would play devil’s advocate, then I would say this: “An action like this seems inappropriate to place into a package that does not clearly indicate why it is needed. Instead, you should create a slurm-common package, and have the user creation happen there.” I would be OK with that: I am fine putting together a patch to create a “slurm-common” package that does the user creation. Some common documentation could also be moved to that package. But, I did not know if that was appropriate, so I submitted the simpler change first! ~ Karl On 1/11/17, 1:21 AM, "Rémi Palancher"wrote: FWIW, we took the same approach in our EDF-specific packages: https://github.com/edf-hpc/slurm-llnl It works fine for us so far! I just don't remember why we didn't propose the patch back into Debian official packages though :( Best, Rémi
Bug#850891: Additional patch, to cover slurmdbd's duplicate code
Hello! I have a second patch, to make another similar change to my first patch. I noticed that slurmdbd’s preinst script is doing the same user-creation. Although slurmdbd does not directly relate to slurm-client, both slurm-client and slurmdbd depend directly on the slurm-wlm-basic-plugins package. So, my second patch does two things: 1) Move the preinst script from the slurm-client package to the slurm-wlm-basic-plugins package. 2) Remove the duplicate user-creation code from slurmdbd. Again, please let me know if I am missing anything! -- A. Karl Kornel | System Administrator Research Computing | Stanford University +1 (650) 736-9327 0002-Remove-duplicate-slurmdbd-user-creation-preinst.patch Description: 0002-Remove-duplicate-slurmdbd-user-creation-preinst.patch
Bug#850891: slurmctld depends on slurm-client; both have the same preinst user-creation code
Source: slurm-llnl Version: 16.05.8-1 Severity: wishlist Tags: patch Hello! I was looking around in the preinst scripts for SLURM, and I noticed that the slurm user-creation code exists in the slurmctld.preinst script, and also the slurm-client.preinst script. Since the slurmctld package depends on the slurm-client package, I am wondering if one is a duplicate of the other? I have attached a patch, which removes the user-creation code from slurmctld’s preinst script. Would you mind having a look at it, and let me know if I am missing something? Thank you very much for the consideration! -- A. Karl Kornel | System Administrator Research Computing | Stanford University +1 (650) 736-9327 0001-Remove-duplicate-slurmctld-user-creation-preinst.patch Description: 0001-Remove-duplicate-slurmctld-user-creation-preinst.patch
Bug#828549: SLURM OpenSSL 1.1 issue - Patch to disable OpenSSL support until upstream fixes
Hi Mehdi, That’s awesome! Changing the code is definitely preferable, as long as the code works with older versions of MySQL. To check this, I tried building SLURM in a Jessie COWbuilder installation. In order to test, one dependency had to be changed in the control file: Change “default-libmysqlclient-dev” to “libmysqlclient-dev”. The test took place with OpenSSL 1.0.1 (specifically, OpenSSL source package version 1.0.1t-1+deb8u3). I also tried building for Ubuntu Xenial (again using COWbuilder), which has OpenSSL package version 1.0.2g-1ubuntu4.5. This also required changing the control file, as with Jessie. I did not test in Wheezy, because there are other dependency issues (like a minimum debhelper version) that would need to be changed. I also did not test on Ubuntu Trusty. Both builds were able to complete. You can download the results here: Debian Jessie (16.05.6-2~sbp81+1, for jessie-backports): https://stanford.box.com/s/tehux7vh57w75k9sfjjpt0s0sjiugor1 Ubuntu Xenial (16.05.6-2~sbp16.04+1, for xenial-backports: https://stanford.box.com/s/opnjc8ab5dqzrwwp3qi2rutvfa1mu51l (I’ll keep each links working until the bug is fixed upstream) “sbp” stands for “Stanford Backport”, since this isn’t an official backport. Each .tar.gz has all of the stuff you would need to upload to a repository of your own, so you can either install the .deb files manually, or you could use the .changes file to upload to a repository of your own. The versions are numbered so that when Gennaro releases 16.05.6-2 (or something later), that will take precedence over the ones I built. Unfortunately, I don’t think your patch would be able to work directly, because the quilt build process requires that the original code be untouched; all of the changes to source have to be Quilt patches. So, I’ve taken your patch and converted it into a quilt patch! I’m attaching to this email a Git commit patch that creates the quilt patch, and updates the patch series list. So, here are the next steps that I would suggest: * Mehdi, you should go to https://bugs.schedmd.com, create an account, open bug 3226, and attach your patch (the original one you sent me). I’m asking you to do it because you are the author, so you should get the credit for it. * Anyone who wants to test on Jessie or Xenial can use one of the builds that I made. * In the meantime, if Gennaro decides to go forward with your code, he could use the quilt patch I’ve attached here. Thanks much for the patch! ~ Karl 0001-Add-support-for-OpenSSL-1.1.patch Description: 0001-Add-support-for-OpenSSL-1.1.patch
Bug#828549: SLURM OpenSSL 1.1 issue - Patch to disable OpenSSL support until upstream fixes
forwarded 828549 https://bugs.schedmd.com/show_bug.cgi?id=3226 tags 828549 + patch thanks Hello! It looks like even the latest SLURM Debian package, 16.05.6-1, still has this issue. I tested with OpenSSL package version 1.1.0b-2, building on a sid COWbuilder. The issue is being tracked upstream at this URL: https://bugs.schedmd.com/show_bug.cgi?id=3226 The bug was filed on Oct. 31, and acknowledged on Nov. 1. SLURM only uses OpenSSL in one place: To create “job step credentials”. However, this is not the default: the default is to have MUNGE create those credentials. Since OpenSSL is only used in one place, and that’s not even as the default, I have created a Quilt patch which removes OpenSSL from the build entirely. Unfortunately, it’s not enough to change how we run ./configure; if the configure script sees an OpenSSL installation, it will use it, so I have to completely remove the test for OpenSSL, as well as the Makefile.am file that would trigger the compilation of OpenSSL-using code. The same Quilt patch also updates the configuration builder HTML, to remove the OpenSSL option. Finally, I update the the control file, README files, and the init scripts (removing the OpenSSL-related checks). All of these changes are in a series of two Git patch files, which are attached. -- A. Karl Kornel | System Administrator Research Computing | Stanford University +1 (650) 736-9327 0002-Update-Debian-files-for-OpenSSL-removal.patch Description: 0002-Update-Debian-files-for-OpenSSL-removal.patch 0001-Add-quilt-patch-to-disable-OpenSSL.patch Description: 0001-Add-quilt-patch-to-disable-OpenSSL.patch
Bug#783779: Moving bug to ifupdown
reassign 783779 ifupdown retitle 783779 Fresh system interface gets allow-hotplug; doesn't wait for full ifup reopen 783779 found 783779 0.7.53.1 tags 783779 jessie d-i noowner 783779 thankyou Since this apparently isn't an issue with systemd, I'm moving this to ifupdown. I hope that's the right place for it! Tagging as jessie because I didn't see this problem in wheezy, and also tagging as d-i because the problem occurred on a freshly-installed system. I thought this was related to bug 766943, but that's already been closed in an earlier version. Maybe this is related to bug 752919 or 550014? Unfortunately, I don't know enough to say either way. ~ Karl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784568: Maybe in the nouveau package?
reassign 784568 xserver-xorg-video-nouveau thankyou Hello! I'm updating this bug to confirm that the issue is still happening, but once I switched to the binary nVidia drivers (via the nvidia-driver package), the problem stopped. So, this definitely seems like something related to nouveau. As a result, I'm moving the bug. I checked out bug #698296, and this might be related, but that bug's log doesn't show any nouveau_exa_upload_to_screen:380 or nouveau_exa_download_from_screen:295 messages. -- ~ A. Karl Kornel, (650) 736-9327 Authentication Collaboration Solutions University IT, Stanford University -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783779: systemd: system-ifup.slice start completes before interface is up
On 4/29/2015 5:43 PM, Michael Biebl wrote: snip Once /etc/init.d/networking has completed, the network is considered up. Ah, OK. Sorry about that! I thought systemd had taken over that functionality. snip Can you attach the output of systemctl status networking.service systemctl status ifup@eth0.service Attached as networking.service-status.txt and i...@eth0.service-status.txt. (you need to run that as root). Does it help, if you switch allow-hotplug eth0 to auto eth0 in /etc/network/interfaces? Yes it does! If I switch to auto eth0, then everything will correctly wait for the network connection to come up before continuing to boot. I have attached post-interface-change-networking.service-status.txt to show the output of `systemctl status networking.service` after I changed from allow-hotplug eth0 to auto eth0. ~ Karl â—� ifup@eth0.service - ifup for eth0 Loaded: loaded (/lib/systemd/system/ifup@.service; static) Active: active (exited) since Thu 2015-04-30 10:52:04 PDT; 2min 28s ago Process: 710 ExecStart=/sbin/ifup --allow=hotplug %I (code=exited, status=0/SUCCESS) Main PID: 710 (code=exited, status=0/SUCCESS) Apr 30 10:52:04 blargh.stanford.edu systemd[1]: Started ifup for eth0. Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: Internet Systems Consortium DHCP Client 4.3.1 Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: Copyright 2004-2014 Internet Systems Consortium. Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: All rights reserved. Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: For info, please visit https://www.isc.org/software/dhcp/ Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: Apr 30 10:52:04 blargh.stanford.edu ifup[710]: Internet Systems Consortium DHCP Client 4.3.1 Apr 30 10:52:04 blargh.stanford.edu ifup[710]: Copyright 2004-2014 Internet Systems Consortium. Apr 30 10:52:04 blargh.stanford.edu ifup[710]: All rights reserved. Apr 30 10:52:04 blargh.stanford.edu ifup[710]: For info, please visit https://www.isc.org/software/dhcp/ Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: Listening on LPF/eth0/14:cc:20:00:20:36 Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: Sending on LPF/eth0/14:cc:20:00:20:36 Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: Sending on Socket/fallback Apr 30 10:52:04 blargh.stanford.edu dhclient[721]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 Apr 30 10:52:04 blargh.stanford.edu ifup[710]: Listening on LPF/eth0/14:cc:20:00:20:36 Apr 30 10:52:04 blargh.stanford.edu ifup[710]: Sending on LPF/eth0/14:cc:20:00:20:36 Apr 30 10:52:04 blargh.stanford.edu ifup[710]: Sending on Socket/fallback Apr 30 10:52:04 blargh.stanford.edu ifup[710]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 Apr 30 10:52:09 blargh.stanford.edu dhclient[721]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 Apr 30 10:52:09 blargh.stanford.edu ifup[710]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9 Apr 30 10:52:09 blargh.stanford.edu dhclient[721]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Apr 30 10:52:09 blargh.stanford.edu dhclient[721]: DHCPOFFER from 171.64.18.1 Apr 30 10:52:09 blargh.stanford.edu ifup[710]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Apr 30 10:52:09 blargh.stanford.edu ifup[710]: DHCPOFFER from 171.64.18.1 Apr 30 10:52:09 blargh.stanford.edu dhclient[721]: DHCPACK from 171.64.18.1 Apr 30 10:52:09 blargh.stanford.edu ifup[710]: DHCPACK from 171.64.18.1 Apr 30 10:52:09 blargh.stanford.edu dhclient[721]: bound to 171.64.19.50 -- renewal in 81898 seconds. Apr 30 10:52:09 blargh.stanford.edu ifup[710]: bound to 171.64.19.50 -- renewal in 81898 seconds. â—� networking.service - LSB: Raise network interfaces. Loaded: loaded (/etc/init.d/networking) Drop-In: /run/systemd/generator/networking.service.d └─50-insserv.conf-$network.conf /lib/systemd/system/networking.service.d └─network-pre.conf Active: active (exited) since Thu 2015-04-30 10:52:04 PDT; 38s ago Process: 627 ExecStart=/etc/init.d/networking start (code=exited, status=0/SUCCESS) Apr 30 10:52:03 blargh.stanford.edu ntpdate[690]: Can't find host time-a.stanford.edu: Name or service not known (-2) Apr 30 10:52:04 blargh.stanford.edu networking[627]: Configuring network interfaces...done. Apr 30 10:52:04 blargh.stanford.edu systemd[1]: Started LSB: Raise network interfaces.. ● networking.service - LSB: Raise network interfaces. Loaded: loaded (/etc/init.d/networking) Drop-In: /run/systemd/generator/networking.service.d └─50-insserv.conf-$network.conf /lib/systemd/system/networking.service.d └─network-pre.conf Active: active (running) since Thu 2015-04-30 10:56:38 PDT; 1min 4s ago Process: 1261 ExecStop=/etc/init.d/networking stop (code=exited, status=0/SUCCESS) Process: 1355 ExecStart=/etc/init.d/networking start (code=exited, status=0/SUCCESS) CGroup: /system.slice/networking.service
Bug#783837: nvidia-driver: Driver incompatible with UEFI? Can we conflict with grub-efi-amd64?
Package: nvidia-driver Version: 340.65-2 Severity: important Tags: upstream Hello! I have a newly-build (built from scratch) amd64 jessie system, built on UEFI, but it looks like the nVidia driver is not currently compatible with UFEI systems. In my case, the issue manifested as not being able to switch to any virtual consoles after X started. Before X starts, I am able to see boot messages etc.. Once X starts, it works fine, but if I try to switch to any virtual consoles, I hear a beep and the display goes to sleep. Some searching around lead me to the following forum post: https://devtalk.nvidia.com/default/topic/827139/linux/uefi-nvidia-vga-console-complaints-/ I get the same error (Your system is not currently configured to drive a VGA console) that is described in the forum, so I am thinking that reinstalling onto a BIOS system will fix the problem for me. Would it be possible to make the nvidia-driver package conflict with the grub-efi-amd64 and grub-efi-ia32 packages, until the nVidia releases a UEFI-compatible driver? Please let me know if I can provide any additional information. Thanks very much! -- Package-specific info: uname -a: Linux blargh.stanford.edu 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux /proc/version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.65 Tue Dec 2 09:50:34 PST 2014 GCC version: gcc version 4.8.4 (Debian 4.8.4-1) lspci 'VGA compatible controller [0300]': 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3 Processor Integrated Graphics Controller [8086:041a] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Dell Device [1028:05a6] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 47 Region 0: Memory at f740 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at d000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at f000 [size=64] Capabilities: access denied Kernel driver in use: i915 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119 [NVS 310] [10de:107d] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation Device [10de:094e] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 51 Region 0: Memory at f600 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at e000 (64-bit, prefetchable) [size=128M] Region 3: Memory at e800 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at e000 [size=128] [virtual] Expansion ROM at f700 [disabled] [size=512K] Capabilities: access denied Kernel driver in use: nvidia dmesg: [0.00] AGP: No AGP bridge found [0.00] AGP: Checking aperture... [0.00] AGP: No AGP bridge found [0.307659] vgaarb: device added: PCI::00:02.0,decodes=io+mem,owns=mem,locks=none [0.307662] vgaarb: setting as boot device: PCI::01:00.0 [0.307663] vgaarb: device added: PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none [0.307664] vgaarb: loaded [0.307665] vgaarb: bridge control possible :01:00.0 [0.307665] vgaarb: no bridge control possible :00:02.0 [0.584556] Linux agpgart interface v0.103 [ 42.412702] [drm] Replacing VGA console driver [ 42.436212] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=none:owns=none [ 42.988317] snd_hda_intel :01:00.1: Handle VGA-switcheroo audio client [ 43.579231] nvidia: module license 'NVIDIA' taints kernel. [ 43.583945] vgaarb: device changed decodes: PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=none [ 43.584140] [drm] Initialized nvidia-drm 0.0.0 20130102 for :01:00.0 on minor 1 [ 43.584144] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 340.65 Tue Dec 2 09:50:34 PST 2014 [ 43.700298] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card2/input15 [ 43.700370] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card2/input16 [ 56.333741] nvidia :01:00.0: irq 51 for MSI/MSI-X [ 56.871733] NVRM: Your system is not currently configured to drive a VGA console [ 56.871735] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver [ 56.871736] NVRM: requires the use of a text-mode VGA console. Use of other console [
Bug#779368: Bug exists in upstream (bug #655074) -- Workaround is to enable SSL
Hello! I did some searching upstream, and it looks like this is upstream bug #655074. I found that this issue still exists in the latest version of upstream (version 38.0a2), and I also found that turning on SSL solves the problem. At least, I think it solves the problem, because debug messages show Icedove moving on to executing a search. The search doesn't work, but I think that's because of something else. So, the workaround for this issue (including in Icedove) is to use SSL for the LDAP connection at the same time that you are using GSSAPI. Of course, this probably won't work for everyone. Anyway, all my notes have been added to the upstream bug! ~ Karl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779364: pan: Crash when opening article with layered attachments
On Mar 1, 2015, at 12:37 AM, Dominique Dumont d...@debian.org wrote: snip Could you please follow up on this bug to answer any question upstream may have ? Hi Dominique, Certainly! I have CCed myself on the bug, and will watch for any questions. ~ Karl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779368: icedove: LDAP and GSSAPI silently failing with protocol violation
Package: icedove Version: 31.4.0-1~deb7u1 Severity: normal Hello! I am having an issue with icedove and LDAP/GSSAPI. I am trying to connect Icedove to our organization's LDAP server. In order to get access to non-public information (like phone numbers and email addresses), I need to use GSSAPI for authentication (simple binding is not supported). I am able to do GSSAPI authentication with the `ldapsearch` command, so I know that my Kerberos credentials are OK. I am attaching a packet capture, showing the attempted bind, and the failure. Wireshark reports that the bind is failing with the following error: generic failure: protocol violation: client requested invalid layer Please let me know if you need any more info! -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages icedove depends on: ii debianutils 4.3.2 ii fontconfig2.9.0-7.1 ii libasound21.0.25-4 ii libatk1.0-0 2.4.0-2 ii libc6 2.13-38+deb7u8 ii libcairo2 1.12.2-3 ii libdbus-1-3 1.6.8-1+deb7u6 ii libdbus-glib-1-2 0.100.2-1 ii libevent-2.0-52.0.19-stable-3+deb7u1 ii libffi5 3.0.10-3 ii libfontconfig12.9.0-7.1 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.7.2-5 ii libgdk-pixbuf2.0-02.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgtk2.0-0 2.24.10-2 ii libhunspell-1.3-0 1.3.2-4 ii libpango1.0-0 1.30.0-1 ii libpixman-1-0 0.26.0-4+deb7u1 ii libsqlite3-0 3.7.13-1+deb7u1 ii libstartup-notification0 0.12-1 ii libstdc++64.7.2-5 ii libx11-6 2:1.5.0-1+deb7u1 ii libxext6 2:1.3.1-2+deb7u1 ii libxrender1 1:0.9.7-1+deb7u1 ii libxt61:1.1.3-1+deb7u1 ii psmisc22.19-1+deb7u1 ii zlib1g1:1.2.7.dfsg-13 Versions of packages icedove recommends: ii myspell-en-us [myspell-dictionary] 1:3.3.0-4 Versions of packages icedove suggests: ii fonts-lyx 2.0.3-3 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u3 -- no debconf information icedove_packets.pcap Description: application/vnd.tcpdump.pcap
Bug#777549: Issue also appears in 6.7p1-3 on sid
found 777549 openssh/1:6.7p1-3 thank you Hello! It looks to me like this issue also exists in the latest version, on sid. I checked this by grabbing openssh_6.7p1.orig.tar.gz and openssh_6.7p1-3.debian.tar.xz off of packages.debian.org, and then applying gssapi.patch to the source. I see that the GSSAPI key-exchange algorithms are added to the head of the proposal in sshconnect2.c lines 170-188. Then, on lines 222-223, the client checks to see if any key-exchange algorithms were specified as options; if they were, the existing contents of the proposal get blown away. I was wondering if the block of code from lines 170-188 could be merged into the #ifdef GSSAPI block that exists at lines 227-236. Those lines appear after the key-exchange algorithms proposal gets potentially blown away, so I think it would be safe to change at that point. I'm sorry that I'm unable to build and test right now, but I don't have any hardware (physical or virtual) that I can test on. If that changes, I'll let you know! ~ Karl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777549: openssh-client: Setting KexAlgorithms disables GSSAPIKeyExchange
Package: openssh-client Version: 1:6.0p1-4+deb7u2 Severity: normal Good morning! I am reporting an issue that I have discovered in Debian's OpenSSH package: It appears that setting GSSAPIKeyExchange overrides the KexAlgorithms setting. The group I am in (Authentication Collaboration Solutions, part of Stanford IT) relies heavily on Kerberos: It is our policy to not allow our group members to enter passwords in remote sites, with few exceptions. As a new employee in our group, I have been updating our internal documentation that documents how we use SSH. Part of that includes making a standard OpenSSH client configuration for other new employees to use. One of the items in this configuration is to enable GSSAPI key exchange, and also to disable certain key-exchange algorithms. The problem I found is, if I explicitly set KexAlgorithms, that essentially turns off GSSAPIKeyExchange. Looking at debug logs, OpenSSH does not even try to use GSSAPI key exchange, which makes me think that setting KexAlgorithms somehow overrides whatever changes GSSAPIKeyExchange is trying to make. I'm going to try reproducing this problem in openssh 6.7p1-3, just to make sure the problem still exists there; I'll report back when I'm able to reproduce. -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages openssh-client depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 ii dpkg 1.16.15 ii libc6 2.13-38+deb7u7 ii libedit2 2.11-20080614-5 ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u2 ii libselinux12.1.9-5 ii libssl1.0.01.0.1e-2+deb7u14 ii passwd 1:4.1.5.1-1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages openssh-client recommends: ii openssh-blacklist0.4.1+nmu1 ii openssh-blacklist-extra 0.4.1+nmu1 ii xauth1:1.0.7-1 Versions of packages openssh-client suggests: pn keychain none pn libpam-sshnone pn monkeysphere none pn ssh-askpass none -- Configuration Files: /etc/ssh/ssh_config changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777549: openssh-client: Setting KexAlgorithms disables GSSAPIKeyExchange
Hello! Since three replies came in at once (from my perspective), I'm doing one email. On 2/9/2015 6:53 PM, Russ Allbery wrote: Alfred Karl Kornel akkor...@stanford.edu writes: I am reporting an issue that I have discovered in Debian's OpenSSH package: It appears that setting GSSAPIKeyExchange overrides the KexAlgorithms setting. Yeah, I would expect this, since GSS-API key exchange *is* a key exchange mechanism. If you do GSS-API key exchange, that completely replaces the normal ssh public key negotiation, since it instead uses Kerberos to negotiate the encrypted channel with the server. That's what I thought, but as I understood the patch, it seems that turning on GSSAPIKeyExchange is just working out what GSSAPI key-exchange methods are supported, and then prepending those to the default list of key-exchange algorithms (and then adding null at the end). That way, if the server doesn't support GSSAPI key exchange, the client is able to fall back to one of the more traditional methods. Is the problem that you want to be able to control the key exchange algorithms that the server falls back on if GSS-API key exchange fails (if, for example, the client doesn't support it)? Yup, that's correct! If you're happy to require all clients to do GSS-API key exchange, you can just delete all public keys for the server. They're not used at all with GSS-API, and that will prevent the server from negotiating any public key exchange mechanism as a fallback. The problem with that is, if I do that I'm putting all of my faith that GSSAPI will be working on both ends. I don't want to trust in GSSAPI not working if something goes wrong on my client. For example, if Kerberos is messed up on my workstation, I could still securely log in to the server, I'd just have a coworker log in and get the host key fingerprint for me. On 2/9/2015 7:09 PM, Christoph Anton Mitterer wrote: On Mon, 2015-02-09 at 18:53 -0800, Russ Allbery wrote: snip Guess the main problem here is, that GSSAPI Kex should have become configurable via KexAlgorithms and not via a separate option. OTOH, The GSSAPI Kex is really quite special (IIRC the client authentication phase also happens during the kex then). Well, I'm find with just having GSSAPIKeyExchange prepend all of the GSSAPI methods to the start of my chosen KexAlgorithms list. You could easily get very complicated here, such as by having SSH recognize things like gssapi-group1 or gssapi-group-exchange, and then replace with the appropriate expansions (after working out the OIDs). snip Anyway,... best chances are if Alfred would report this to upstream (which is here not OpenSSH, but the maintainers of the patchset). I was wondering if this would need to go upstream, but from what I understood, bug reporters are supposed to report bugs directly to Debian. Could you please tell me where upstream is in this case? I did some quick searching, but the one place I found hadn't been updated in a few years. Once I know where to send the bug report, I'm happy to file it upstream! On 2/9/2015 7:18 PM, Russ Allbery wrote: snip That's also true, particularly since it sounded from the second message like he has a proposed fix. However, it's worth noting that any fix for this wouldn't make it into jessie at this point, so you'll want to be thinking about workarounds or planning on backporting a later version. Yeah, it's really depressing, but I guess that's what's gonna happen. Could it possibly make it into jessie-backports, or is that also too much to hope for? Either way, thanks very much for the quick reply to my bug report! ~ Karl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#339841: Additional Information for Bug#339841
Hello. I have some additional information to add to this bug. First, I tried to check out a new working copy into a different directory (the repository and working copy are still on the same system here). Making the changes to the newly-checked-out copy can not be committed (the crash still takes place, and a cleanup/recover still needs to be done). In addition to the local working copy, I also have access to two working copies on remote systems. Both remote working copies use svn +ssh to connect to the repository. One remote system has version 1.2.1 (r15230), and another has version 1.1.4 (r13838). For each remote working copy, I updated it to the latest revision (with no problems), made a change, and tried to commit. Each one failed in the same place with the following: svn: Commit failed (details follow): svn: Malformed network data Each one required a cleanup/recover. In the end I dumped the entire repository, created a repository on a different machine, restored the repository onto the different machine, switched the URLs of all checked out working copies, and the problem was gone. The different machine is running Darwin 8.3.0 running Subversion 1.1.4 (r13838). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339841: svn commit crashes when commiting approx. 300 files to a local BDB repository
Package: svn Version: subversion Severity: important I am using Subversion 1.1.4 (r13838) that was already on the system. I did not install it, and I assume it came as part of the Debian installation. I have a repository containing many files (at least 1000) and several branches (directories), about 7 of which are in use and 6 of which are no longer in use (deleted), this in addition to the main trunk. I have about 300 files spread out in the 6 branches + trunk which I needed to commit. I first ran `svn update`, which showed no updates, and then ran `svn commit`. I entered one line of text in the commit log. All files were sent without problems. During the Transmitting file data part, subversion aborted. After this, I did a `svn update` and was told that the directory was locked. I ran `svn cleanup` and did not receive any output. I then ran `svn update` again and was told the repository needed to be recovered. I did so (nothing was lost), and tried the update/commit again. This time, the abort still took place but I was able to get a core dump. I then redid the cleanup/recover, and tried to commit smaller batches of files (one commit per branch + head). This does not work either. It seems that I can no longer commit anything from my working copy without an abort. Here is information that I was able to obtain from the core dump. * First, the information generated by gdb when loading: This GDB was configured as i686-pc-linux-gnu...(no debugging symbols found) Using host libthread_db library /lib/libthread_db.so.1. Core was generated by `svn commit'. Program terminated with signal 6, Aborted. Reading symbols from /usr/lib/libsvn_client-1.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libsvn_client-1.so.0 Reading symbols from /usr/lib/libsvn_wc-1.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libsvn_wc-1.so.0 Reading symbols from /usr/lib/libsvn_ra-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libsvn_ra-1.so.0 Reading symbols from /usr/lib/libsvn_delta-1.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libsvn_delta-1.so.0 Reading symbols from /usr/lib/libsvn_subr-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libsvn_subr-1.so.0 Reading symbols from /usr/lib/libaprutil-0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libaprutil-0.so.0 Reading symbols from /usr/lib/libldap.so.2... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libldap.so.2 Reading symbols from /usr/lib/liblber.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/liblber.so.2 Reading symbols from /usr/lib/libdb-4.2.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libdb-4.2.so Reading symbols from /usr/lib/libexpat.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /usr/lib/libapr-0.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libapr-0.so.0 Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libnsl.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/lib/libneon.so.24...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libneon.so.24 Reading symbols from /usr/lib/i686/cmov/libssl.so.0.9.7... (no debugging symbols found)...done. Loaded symbols for /usr/lib/i686/cmov/libssl.so.0.9.7 Reading symbols from /usr/lib/i686/cmov/libcrypto.so.0.9.7...(no debugging symbols found)...done. Loaded symbols for /usr/lib/i686/cmov/libcrypto.so.0.9.7 Reading symbols from /lib/libdl.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /usr/lib/libz.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libm.so.6... (no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libsvn_diff-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libsvn_diff-1.so.0 Reading symbols from /usr/lib/libsvn_ra_local-1.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libsvn_ra_local-1.so.0 Reading symbols from /usr/lib/libsvn_repos-1.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libsvn_repos-1.so.0 Reading symbols from /usr/lib/libsvn_fs-1.so.0...(no debugging symbols found)...done. Loaded symbols for