Bug#777010: reportbug crashes when trying to submit bug report
Package: reportbug Version: 6.6.3 Severity: grave Justification: renders package unusable I was trying to report a bug to the kernel, but after the report was shown for confirmation before sending the mail, it crashes: Submit this report on linux-image-3.18.0-trunk-amd64 (e to edit) [Y|n|a|c|e|i|l|m|p|q|d|t|s|?]? Y Traceback (most recent call last): File "/usr/bin/reportbug", line 2211, in main() File "/usr/bin/reportbug", line 1081, in main return iface.user_interface() File "/usr/bin/reportbug", line 2203, in user_interface self.options.envelopefrom) File "/usr/lib/python2.7/dist-packages/reportbug/submit.py", line 305, in send_report os.popen(pager, 'w').write(message) IOError: [Errno 32] Broken pipe -- Package-specific info: ** Environment settings: EDITOR="/home/oxan/shell/bin/edit -f" DEBEMAIL="o...@oxanvanleeuwen.nl" EMAIL="o...@oxanvanleeuwen.nl" DEBFULLNAME="Oxan van Leeuwen" NAME="Oxan van Leeuwen" INTERFACE="text" ** /home/oxan/.reportbugrc: mode advanced ui text paranoid editor "nano -r 80" no-cc realname "Oxan van Leeuwen" email "o...@oxanvanleeuwen.nl" -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (920, 'testing'), (910, 'stable'), (900, 'testing-proposed-updates'), (525, 'unstable'), (515, 'experimental'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages reportbug depends on: ii apt 1.0.9.6 ii python2.7.8-2 ii python-reportbug 6.6.3 pn python:any reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils pn debsums pn dlocate pn emacs23-bin-common | emacs24-bin-common ii file 1:5.20-2 ii gnupg1.4.18-6 ii msmtp-mta [mail-transport-agent] 1.4.32-2 pn python-gtk2 pn python-gtkspell pn python-urwid pn python-vte ii xdg-utils1.1.0~rc1+git20111210-7.3 Versions of packages python-reportbug depends on: ii apt 1.0.9.6 ii python-debian 0.1.25 ii python-debianbts 1.12 pn python:any python-reportbug suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777016: linux-image-3.18.0-trunk-amd64: kernel panic in __intel_set_mode
Package: src:linux Version: 3.18.5-1~exp1 Severity: serious My system hangs when booting using kernel 3.18 sometime after unlocking the encrypted root disk. Kernel 3.17 works fine. * Using the default kernel command line, the problem occurs everytime. * Using the nomodeset parameter, the kernel works fine but I can't use X. * When using netconsole, the system sometimes hangs and sometimes works fine, though outputting a warning in the kernel (see first log below). When the kernel hangs, unfortunately only the first few lines of the BUG show up in the netconsole (see second log at the bottom). Let me know if I can be of any more assistance. -- Package-specific info: ** Version: Linux version 3.18.0-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 3.18.5-1~exp1 (2015-01-31) ** Command line: BOOT_IMAGE=/vmlinuz-3.18.0-trunk-amd64 root=UUID=452d1dc1-2c61-4bba-b64a-8137c122bf0b ro net.ifnames=1 netconsole=@130.89.172.53/eth0,@130.89.171.131/60:a4:4c:d6:77:4d ** Tainted: W (512) * Taint on warning. ** Kernel log (when system was booted with netconsole and didn't panic): [9.236016] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [9.236361] acpi device:60: registered as cooling_device10 [9.236420] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input9 [9.236629] [drm] Initialized i915 1.6.0 20140905 for :00:02.0 on minor 0 [9.236710] ACPI Warning: SystemIO range 0xf040-0xf05f conflicts with OpRegion 0xf040-0xf04f (\_SB_.PCI0.SBUS.SMBI) (20140926/utaddress-258) [9.236728] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [9.236820] snd_hda_intel :00:03.0: enabling device ( -> 0002) [9.236883] snd_hda_intel :00:1b.0: enabling device ( -> 0002) [9.237298] snd_hda_intel :00:03.0: irq 31 for MSI/MSI-X [9.237400] snd_hda_intel :00:1b.0: irq 32 for MSI/MSI-X [9.247250] sound hdaudioC1D0: autoconfig: line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line [9.247255] sound hdaudioC1D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [9.247257] sound hdaudioC1D0:hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [9.247259] sound hdaudioC1D0:mono: mono_out=0x0 [9.247261] sound hdaudioC1D0:dig-out=0x1e/0x0 [9.247262] sound hdaudioC1D0:inputs: [9.247264] sound hdaudioC1D0: Front Mic=0x19 [9.247266] sound hdaudioC1D0: Rear Mic=0x18 [9.247268] sound hdaudioC1D0: Line=0x1a [9.260930] input: HDA Intel HDMI HDMI/DP,pcm=3 as /devices/pci:00/:00:03.0/sound/card0/input18 [9.261589] input: HDA Intel HDMI HDMI/DP,pcm=7 as /devices/pci:00/:00:03.0/sound/card0/input19 [9.261619] input: HDA Intel PCH Front Mic as /devices/pci:00/:00:1b.0/sound/card1/input10 [9.261928] input: HDA Intel HDMI HDMI/DP,pcm=8 as /devices/pci:00/:00:03.0/sound/card0/input20 [9.262246] input: HDA Intel PCH Rear Mic as /devices/pci:00/:00:1b.0/sound/card1/input11 [9.262699] input: HDA Intel PCH Line as /devices/pci:00/:00:1b.0/sound/card1/input12 [9.262997] input: HDA Intel PCH Line Out Front as /devices/pci:00/:00:1b.0/sound/card1/input13 [9.263271] input: HDA Intel PCH Line Out Surround as /devices/pci:00/:00:1b.0/sound/card1/input14 [9.263535] input: HDA Intel PCH Line Out CLFE as /devices/pci:00/:00:1b.0/sound/card1/input15 [9.263815] input: HDA Intel PCH Line Out Side as /devices/pci:00/:00:1b.0/sound/card1/input16 [9.264073] input: HDA Intel PCH Front Headphone as /devices/pci:00/:00:1b.0/sound/card1/input17 [9.279344] [ cut here ] [9.279372] WARNING: CPU: 0 PID: 411 at /build/linux-xmCjRp/linux-3.18.5/drivers/gpu/drm/i915/intel_display.c:11417 intel_crtc_set_config+0xbe8/0xe60 [i915]() [9.279374] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic nls_utf8 nls_cp437 vfat fat iTCO_wdt mxm_wmi ppdev iTCO_vendor_support joydev x86_pkg_temp_thermal evdev intel_powerclamp intel_rapl coretemp efi_pstore kvm_intel psmouse kvm snd_hda_intel snd_hda_controller serio_raw snd_hda_codec efivars snd_hwdep pcspkr i2c_i801 snd_pcm snd_timer snd i915 soundcore drm_kms_helper intel_smartconnect tpm_infineon 8250_fintek video drm parport_pc tpm_tis battery parport tpm i2c_algo_bit wmi i2c_core shpchp mei_me lpc_ich mei mfd_core button processor fuse autofs4 ext4 crc16 mbcache jbd2 algif_skcipher af_alg dm_crypt dm_mod hid_generic usbhid hid netconsole configfs sg sr_mod cdrom sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel xhci_pci [9.279628] ahci libahci aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd xhci_hcd libata ehci_pci ehci_hcd scsi_mod r8169 mii usbcore usb_common thermal fa
Bug#620469: status
On 08-08-11 23:06, Clint Byrum wrote: Excerpts from Oxan van Leeuwen's message of Mon Aug 08 07:27:01 -0500 2011: Hi Clint, What's the current status of the updated python-gearman.libgearman package? Hi Oxan. This package has been waiting for sponsorship for some time now, and fixes the bug: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=gearman-interface Hi Clint, Did you have any luck getting the updated package in Debian yet? I'd like to have this bug resolved sometime before the upcoming Wheezy freeze, so that python-gearman is included in the Wheezy release. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620469: status
Hi Clint, What's the current status of the updated python-gearman.libgearman package? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620469: Bug#620496
# wheezy not affected as this bug blocks python-gearman from migrating tag 620469 + sid thanks I see three solutions for this problem: (A) Add Conflicts against each other. This prevents users from installing the packages together, which normally isn't needed as they provide the same functionality. It isn't optimal however, as in the future it might be possible that there are programs that depend on one of these libraries and that need to be co-installable. (B) Rename the python module in one of the packages. This would be the best solution, but it is a backwards-incompatible break and every reverse-dependency needs to be patched to use the renamed API. (C) Drop the __init__.py from one of the packages. The two modules are actually co-installable and usable, as they don't use the same namespace: python-gearman.libgearman uses gearman.libgearman, while python-gearman uses just gearman. The __init__.py from python-gearman can't be dropped as it imports the primary API into the gearman namespace. python-gearman.libgearman seems to be functional without the __init__.py, but I'm not 100% sure. Also having two packages providing the same Python package is confusing. I think the best we can do at this point is A, given the side-effects of the other options. I'll implement that in python-gearman (which should be enough) if nobody objects. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620469:
On 04/03/2011 06:53 PM, Clint Byrum wrote: > > Oxan, thanks for the quick response. Thanks for your response! > I opened this issue upstream: > > https://github.com/Yelp/python-gearman/issues/#issue/11 > > I think the way to go is to drop __init__.py from > python-gearman.libgearman, and make it depend on python-gearman, since > it is a sub-module of the gearman namespace. That does make sense. > > I haven't been able to make gearman.libgearman work properly without > the __path__ changes, though I'm not entirely sure why as I'm sort of a > python extension novice. If anyone *can* make that work, then we don't > even need the change suggested above. I did some more testing and got it working without __init__.py. The __init__.py is only needed during compilation/installation and not during execution. This does make sense, as it adds a directory to the path that is already searched in. Not installing it in debian/rules should be enough, can you confirm that? I also think that we can demote the dependency to a Recommends, as they do work without each other. > >> I think the best we can do at this point is A, given the side-effects of the >> other options. I'll implement that in python-gearman (which should be enough) >> if nobody objects. > > Yeah I was thinking of doing the same in the python-gearman.libgearman, > but I think since its temporary we can just leave it in python-gearman > until the necessary changes can be made for python-gearman.libgearman > to depend on python-gearman. > > With the Conflicts on one side, I think we can close this bug, and open > a new wishlist bug to implement the dependency relationship. Given your response and the results above I'm hoping that we can fix this directly in one upload, without having to upload a temporary fix first :) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620469: Bug#620496
Hi Clint,
On 03-04-11 18:53, Clint Byrum wrote:
> I think the way to go is to drop __init__.py from
> python-gearman.libgearman, and make it depend on python-gearman, since
> it is a sub-module of the gearman namespace.
>
> I haven't been able to make gearman.libgearman work properly without
> the __path__ changes, though I'm not entirely sure why as I'm sort of a
> python extension novice. If anyone *can* make that work, then we don't
> even need the change suggested above.
I did some more testing and gearman.libgearman actually works without the
__path__ changes, when it's installed in one of the standard Debian locations.
During compilation it's not, so it needs the __path__ changes then.
The problem with implementating that is python-gearman uses dh_python2 while
gearman.libgearman uses python-support, which results in the bytecode files
(.pyc) being installed into different directories. When I converted
gearman.libgearman to dh_python2 both packages work fine. Do you agree with this
solution?
I've attached the patch that I used for testing gearman.libgearman using
dh_python. You'll probably need to make some more changes, but maybe you can use
this.
diff -Nru gearman-interface-0.13.2/debian/changelog gearman-interface-0.13.2/debian/changelog
--- gearman-interface-0.13.2/debian/changelog 2010-09-29 04:41:31.0 +0200
+++ gearman-interface-0.13.2/debian/changelog 2011-04-18 20:21:59.0 +0200
@@ -1,3 +1,9 @@
+gearman-interface (0.13.2-3.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+
+ -- Oxan van Leeuwen Mon, 18 Apr 2011 20:21:56 +0200
+
gearman-interface (0.13.2-3) unstable; urgency=low
* Fixing Vcs-Bzr to point at debian packaging (Closes: #596794)
diff -Nru gearman-interface-0.13.2/debian/control gearman-interface-0.13.2/debian/control
--- gearman-interface-0.13.2/debian/control 2010-09-29 04:40:46.0 +0200
+++ gearman-interface-0.13.2/debian/control 2011-04-18 20:32:19.0 +0200
@@ -1,7 +1,7 @@
Source: gearman-interface
Priority: extra
Maintainer: Clint Byrum
-Build-Depends: python-setuptools (>= 0.6b3), python, python3 (>= 3.1.2-6~), python3-all-dev (>= 3.1.2-10), python-all-dev, debhelper (>= 7.0.50~), python-support (>= 0.8.4), libgearman-dev (>= 0.13), swig, uuid-dev
+Build-Depends: python-setuptools (>= 0.6b3), python3-all-dev (>= 3.1.2-10), python-all-dev (>= 2.6.6-3~), debhelper (>= 7.0.50~), libgearman-dev (>= 0.13), swig, uuid-dev
Standards-Version: 3.9.1
Section: python
Homepage: https://launchpad.net/gearman-interface
@@ -9,7 +9,7 @@
Package: python-gearman.libgearman
Architecture: any
-Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
+Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}, python-gearman
Provides: ${python:Provides}
Description: Python wrapper of libgearman
This package contains a Python wrapper of libgearman.
diff -Nru gearman-interface-0.13.2/debian/rules gearman-interface-0.13.2/debian/rules
--- gearman-interface-0.13.2/debian/rules 2010-09-29 04:40:46.0 +0200
+++ gearman-interface-0.13.2/debian/rules 2011-04-18 20:31:33.0 +0200
@@ -14,7 +14,7 @@
PY3VERS=$(shell py3versions -vs)
%:
- dh $@
+ dh --with python2,python3 $@
override_dh_build:: build-python-all build-python3-all
@@ -38,7 +38,8 @@
override_dh_install:: build $(PYVERS:%=install-python2%) $(PY3VERS:%=install-python3%)
install-python2%:
- cd python && python$* setup.py install --root $(CURDIR)/debian/python-gearman.libgearman
+ cd python && python$* setup.py install --install-layout=deb --root $(CURDIR)/debian/python-gearman.libgearman
+ find $(CURDIR)/debian/python-gearman.libgearman -name '__init__.py' -delete
install-python3%:
cd python3 && python$* setup.py install --install-layout=deb --root $(CURDIR)/debian/python3-gearman.libgearman
@@ -52,10 +53,6 @@
rm -f python/libgearman.c
rm -f python3/libgearman.c
-override_dh_pysupport::
- dh_pysupport
- dh_python3
-
override_dh_clean::
dh_clean
rm -f build-python*
@@ -66,5 +63,7 @@
rm -rf python/build/
rm -rf python/python_libgearman.egg-info/
rm -rf python3/build/
+ rm -rf python3/gearman/_libgearman*so
+ rm -rf python3/gearman/__pycache__
[ ! -f python/libgearman.c.orig ] || mv -f python/libgearman.c.orig python/libgearman.c
[ ! -f python3/libgearman.c.orig ] || mv -f python3/libgearman.c.orig python3/libgearman.c
Bug#620469: Bug#620496
On 19-04-11 05:14, Clint Byrum wrote: > > Thats great news, and yes I agree with the solution completely. I > had actually already begun porting the package to dh_python2 in the > bzr branch: > > https://code.launchpad.net/~clint-fewbar/gearman-interface/debian-packaging Great! > I've added some of your tweaks to the branch. However, its not clear to > me the reason for these two additions to debian/rules: > > rm -rf python3/build/ > + rm -rf python3/gearman/_libgearman*so > + rm -rf python3/gearman/__pycache__ > [ ! -f python/libgearman.c.orig ] || mv -f python/libgearman.c.orig > python/libgearman.c > > I was hoping you could explain those. Once I can explain what that is > in debian/changelog, I'll get it uploaded. I needed that change to be able to build the package twice in the same directory. Ultimately the clean target should return to the state after unpacking the tarball, so all created files should be deleted. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718309: python-irclib: duplicate of python-irc
Package: python-irclib Version: 0.4.8-1.1 Severity: serious This package is an old version of the python-irc package. - The description is the same - The Homepage field points to an old version of the homepage from the python-irc package. - They use the exact same class and method names Given that the other package is actively maintained and this package hasn't received a single maintainer upload since 2008, I suggest this package is dropped from Debian once all reverse depends are updated to use python-irc. (Actually, I suspect the python-irc package has been created in an attempt to get a recent version of the software in Debian, without following the proper procedures for taking over an unmaintained package and having a transition for the changed API). -- System Information: Debian Release: jessie/sid APT prefers testing-proposed-updates APT policy: (910, 'testing-proposed-updates'), (900, 'testing'), (900, 'stable'), (525, 'unstable'), (515, 'experimental'), (500, 'stable-updates'), (110, 'precise-updates'), (110, 'precise') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-irclib depends on: ii python 2.7.5-2 python-irclib recommends no packages. python-irclib suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/debian-bugs-rc
