Bug#796435:
I just got the same errors here with both the text and the gtk ui.
Bug#796485: /lib/modules/4.1.0-1-amd64/kernel/drivers/net/wireless/rtlwifi/rtlwifi.ko: rtlwifi dereferencing NULL pointer when creating hotspot
Package: src:linux Version: 4.1.3-1 Severity: important File: /lib/modules/4.1.0-1-amd64/kernel/drivers/net/wireless/rtlwifi/rtlwifi.ko Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Maintainer, When creating a hotspot with gnome-network-manager the rtlwifi seems to dereference a NULL pointer. This causes the kernel to go berserk and ultimately requires a hard reboot. I used to be able to create hotspots on the same hardware a while back. It only broke in the last 2 or 3 months. This bug seems to have been reported upstream: * https://bugzilla.kernel.org/show_bug.cgi?id=97441 * http://thread.gmane.org/gmane.linux.kernel.wireless.general/138645 I have attached the relevant part (as far as I can tell) of syslog in the `kernel log` section. Please let me know if you need anymore information, I'd be happy to help. Thanks a lot for your help. - -- Package-specific info: ** Version: Linux version 4.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.3 (Debian 4.9.3-3) ) #1 SMP Debian 4.1.3-1 (2015-08-03) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.1.0-1-amd64 root=UUID=f58c2952-f542-4ad4-a9f6-63538d32a369 ro quiet init=/bin/systemd ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: dbus[916]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' nm-dispatcher: Dispatching action 'down' for wlan0 systemd[1]: Started Network Manager Script Dispatcher Service. NetworkManager[836]: info Config: set interface ap_scan to 2 wpa_supplicant[973]: Using interface wlan0 with hwaddr e0:b9:a5:4a:49:f3 and ssid shiki NetworkManager[836]: info wpa_supplicant stopped NetworkManager[836]: info (wlan0): supplicant interface state: disconnected - down kernel: [ 1128.378224] BUG: unable to handle kernel NULL pointer dereference at 0006 kernel: [ 1128.378240] IP: [a0420959] rtl_get_tcb_desc+0x59/0x760 [rtlwifi] kernel: [ 1128.378258] PGD 0 kernel: [ 1128.378263] Oops: 0002 [#1] SMP kernel: [ 1128.378270] Modules linked in: fuse ecb ctr ccm binfmt_misc pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp intel_rapl iosf_mbi nvidia(PO) coretemp kvm_intel kvm snd_hda_codec_realtek snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel joydev snd_hda_controller aesni_intel snd_hda_codec aes_x86_64 iTCO_wdt lrw snd_hda_core iTCO_vendor_support gf128mul snd_hwdep evdev glue_helper ablk_helper psmouse arc4 cryptd snd_pcm serio_raw rtl8192ce rtl_pci rtl8192c_common jmb38x_ms rtlwifi sg memstick mac80211 lpc_ich mei_me pcspkr mei i2c_i801 cfg80211 rfkill snd_timer snd mfd_core soundcore ac video battery button processor drm shpchp wmi ecryptfs parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 sr_mod cdrom sd_mod uas usb_storage hid_generic usbhid hid crc32c_intel ahci libahci libata firewire_ohci xhc i_pci ehci_pci scsi_mod sdhci_pci xhci_hcd ehci_hcd firewire_core sdhci crc_itu_t jme mmc_core mii usbcore usb_common thermal thermal_sys kernel: [ 1128.378385] CPU: 2 PID: 973 Comm: wpa_supplicant Tainted: P O4.1.0-1-amd64 #1 Debian 4.1.3-1 kernel: [ 1128.378387] Hardware name: CLEVO P150HMx/P150HMx, BIOS 4.6.4 04/22/2011 kernel: [ 1128.378388] task: 8800ca02e290 ti: 8800c930 task.ti: 8800c930 kernel: [ 1128.378389] RIP: 0010:[a0420959] [a0420959] rtl_get_tcb_desc+0x59/0x760 [rtlwifi] kernel: [ 1128.378393] RSP: 0018:8800c93037e8 EFLAGS: 00010086 kernel: [ 1128.378394] RAX: RBX: 880224e406a0 RCX: kernel: [ 1128.378395] RDX: RSI: 880224e41908 RDI: 880224e406a0 kernel: [ 1128.378396] RBP: 880206fd7c28 R08: R09: 08916d2d kernel: [ 1128.378397] R10: 0212 R11: 0004 R12: 8800be8b2da0 kernel: [ 1128.378399] R13: 0080 R14: 880224e413a0 R15: 8800be8b2da0 kernel: [ 1128.378400] FS: 7f97e0648700() GS:88022f48() knlGS: kernel: [ 1128.378401] CS: 0010 DS: ES: CR0: 80050033 kernel: [ 1128.378402] CR2: 0006 CR3: caacb000 CR4: 000407e0 kernel: [ 1128.378403] Stack: kernel: [ 1128.378404] 880224e413a0 8800366c6000 8800366c6000 kernel: [ 1128.378406] 880224e406a0 880224e413a0 be8b2da0 a0511f22 kernel: [ 1128.378408] 8800c9303898 880206fd7c28 880206fd7c10 8800c9303920 kernel: [ 1128.378410] Call Trace: kernel: [ 1128.378415] [a0511f22] ? rtl92ce_tx_fill_desc+0x1b2/0x740 [rtl8192ce] kernel: [ 1128.378418] [a037bafb] ? rtl_pci_tx+0x19b/0x450 [rtl_pci] kernel: [ 1128.378422] [a042460f] ?
Bug#787131: debian-installer-launcher: stores the distribution name at build-time (Debian sid even in Jessie)
Hi, Stephen Kitt sk...@debian.org (2015-05-28): Package: debian-installer-launcher Version: 19 Severity: minor Dear Maintainer, I noticed in the LXDE live CD that the icon label and menu entry for debian-installer say Install Debian sid. I suppose that's because the .desktop file is processed at build time in unstable, but I don't know what the right fix should be... Since the question was asked on IRC (esp. WRT stable), here's my answer, slightly massaged: It should be fixed in unstable first, possibly migrating to testing; after that (at least the unstable part) a stable update can be considered. At first glance, I fail to see why that should be set at build time in the buildd chroots; should probably be stored in the source package, and bumped when a new debian release is out. This would be done the same way as in src:debian-installer. Mraw, KiBi. signature.asc Description: Digital signature
Bug#795527: gmic: please package the Hald-CLUT files
Upstream has made[0] an archive with all the files: http://gmic.eu/gmic_all_data.zip The license is: CC-BY-SA 4.0 Cheers, Chris. [0] https://github.com/dtschump/gmic-community/issues/15#issuecomment -131894845 smime.p7s Description: S/MIME cryptographic signature
Bug#786115: fixed in vim-latexsuite 20141116.812-1
On Thu, 20 Aug 2015 01:49:04 + Johann Felix Soden joh...@debian.org wrote: Source: vim-latexsuite Source-Version: 20141116.812-1 We believe that the bug you reported is fixed in the latest version of vim-latexsuite, which is due to be installed in the Debian FTP archive. This updated version in sid is not installable due to a new dependency on python2, which doesn't exist in the archive; I suspect that dependency should be python2.7 instead. Thanks, Jason Rhinelander
Bug#796449: Bug should be against mate-control-center
This is actually a bug against mate-control-center and is a duplicate of #794676 / #795381. So please close or merge this bug. Thanks, Simon
Bug#782011: [Pkg-xfce-devel] Bug#782011:
control: tag -1 upstream wontfix On Mon, Apr 06, 2015 at 02:13:27PM +0100, Chris Bainbridge wrote: Package: lightdm Version: 1.10.3-3 Severity: wishlist gdm3 now puts the Xorg log in systemd journal (a Debian specific patch from bug #765771 also keeps the old style logs). It would be nice for consistency if lightdm also logged Xorg to the system journal, otherwise users might be confused as to why a command like `journalctl /usr/bin/Xorg` does not work on some Debian desktops. That's something for upstream anyway. But I personnaly don't see why lightdm should specifically log to journalct actually. Maybe it should log stuff to syslog directly, but I don't think depending on journalctl is the right thing to do. Regards, -- Yves-Alexis Perez signature.asc Description: Digital signature
Bug#795808: [ITR] templates://virtualbox-ext-pack/{templates}
Quoting Gianfranco Costamagna (costamagnagianfra...@yahoo.it): Hi Christian, All parts of the process will be carried out in close collaboration with you, and, unless you explicitly ask for it, no upload nor NMU will happen for virtualbox-ext-pack. If you approve this process, please let us know by replying to this mail. If some work in progress on your side would conflict with such a rewrite (such as adding or removing debconf templates), please say so, and we will defer the review to later in the development cycle. You have my thanks and my complete approval for everything you might need to do in order to fix this bug :) Actually, I need time. Despite what the (automated) message says, it may take a bit more time as, next week, I'll be running a very long and though race and few of my time will be devoted to Debian. signature.asc Description: Digital signature
Bug#796451: pytrainer does not parse commandline arguments
Quoting Winfried Tilanus (winfr...@tilanus.com): Package: pytrainer Version: 1.10.1-4 Severity: normal Tags: patch The pytrainer script does not pass any commandline options to the pytr script. This blocks options like using an alternate config dir or enabling debug logging. Adding $@ to the end of the pytrainer script solves this. I see no patch attached (not that I insist on getting one as the fix is trivial, but it may help). Thanks for your report, of course. I'll fix this ASAP but I'm currently busy with real life activities (related to some running, see my blog) and , also, pytrainer is sadly broken indirectly by the GCC5 transition, in unstable and testing...:-( signature.asc Description: Digital signature
Bug#796484: ITP: kxstitch -- Cross stitch pattern editor.
Package: wnpp Version: 1.2.0 Severity: Wishlist KXstitch is a stable application from KDE Extragear. The original sources can be found at http://download.kde.org/stable/kxstitch/1.2.0/src/ The sources are GPL 2+ and the dependencies are Qt4, kdelibs, and imagemagick. Steve Allewell is in the process of porting it to Qt5 and KF5 but I thought a package of the last qt4 version would be good to have. I have a source package which builds and works here on my debian stretch machine. thanks, Jeremy Whiting
Bug#790347: [Pkg-xfce-devel] Bug#790347: lightdm: visiting googlemaps with iceweasel boosts the cpu usage up to almost 100% and makes the machine almost unusable
control: tag -1 unreproducible moreinfo On Sun, Jun 28, 2015 at 11:56:53AM +0100, olsen wrote: Package: lightdm Version: 1.10.3-3 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? browsing websites like googlemaps slows down my computer, htop indicates USER: 'root' CPU: '98%' Command: '/usr/bin/X :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch' * What exactly did you do (or not do) that was effective (or ineffective)? opening googlemaps e.g. https://www.google.com/maps/place/Roundhouse/@51.501822,-0.1776486,15z/data=!4m2!3m1!1s0x48761ae583feca3d:0xda651372738f331e?hl=en * What was the outcome of this action? severe cut down of computer's performance * What outcome did you expect instead? less cpu usage, same process on other website like http://apod.nasa.gov/apod/astropix.html ranges between 3-8% Why exactly are you reporting this against lightdm? -- Yves-Alexis Perez signature.asc Description: Digital signature
Bug#786248: add patch
Control: tags -1 + patch pending attaching patch and uploading to delayed diff -Nru python-pushy-0.5.1/debian/changelog python-pushy-0.5.1/debian/changelog --- python-pushy-0.5.1/debian/changelog 2012-11-19 09:10:39.0 +0100 +++ python-pushy-0.5.1/debian/changelog 2015-08-22 07:33:33.0 +0200 @@ -1,3 +1,10 @@ +python-pushy (0.5.1-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Build using dh-python. Closes: #695572, #786248. + + -- Matthias Klose d...@debian.org Sat, 22 Aug 2015 07:32:16 +0200 + python-pushy (0.5.1-1) unstable; urgency=low * Initial release (Closes: #693675) diff -Nru python-pushy-0.5.1/debian/control python-pushy-0.5.1/debian/control --- python-pushy-0.5.1/debian/control 2012-11-19 09:10:47.0 +0100 +++ python-pushy-0.5.1/debian/control 2015-08-22 07:32:02.0 +0200 @@ -2,7 +2,7 @@ Section: python Priority: optional Maintainer: Martin Loschwitz madk...@debian.org -Build-Depends: debhelper (= 9.0.0), python-all-dev, python-support +Build-Depends: debhelper (= 9.0.0), python-all-dev, dh-python Standards-Version: 3.9.3 Homepage: http://packages.python.org/pushy XS-Python-Version: = 2.6 diff -Nru python-pushy-0.5.1/debian/rules python-pushy-0.5.1/debian/rules --- python-pushy-0.5.1/debian/rules 2012-11-19 09:08:20.0 +0100 +++ python-pushy-0.5.1/debian/rules 2015-08-22 07:32:13.0 +0200 @@ -10,4 +10,4 @@ export DH_VERBOSE=1 %: - dh $@ + dh $@ --with python2
Bug#796207: [INTL:tr] turkish translation update of iso-codes/iso_3166
package iso-codes tag 796207 pending found 796207 3.60-1 thanks Am 20.08.2015 um 12:22 schrieb Artı Endüstriyel Elektronik: Please find attached the Turkish translation of postfix package. Regards, Atila KOÇ Hi Atila, thanks for the update, it'll be part of the next release. Don't worry about the wrong e-mail address. Regards, Tobias signature.asc Description: OpenPGP digital signature
Bug#796459: apt: Unable to create caches as file usage is disabled [..]
The message itself comes (or at least should) in response to Dir::Cache::pkgcache and Dir::Cache::srcpkgcache being empty and if the cache is forbidden to be build entirely in memory – which is the case for apt running as root for, well, reasons. I guess we should drop this, even through keeping everything in memory can be very slow… I'm not opposed to changing/removing that config (or adding more config as appropriate), but I would note that this is documented in apt.conf(5): | Generation of caches can be turned off by setting pkgcache or | srcpkgcache to . This will slow down startup but save disk space. It | is probably preferable to turn off the pkgcache rather than the | srcpkgcache. The goal in the Docker case is that we can have a layer in an image whose filesystem changes consist only of the files from the packages we've installed, and the metadata updates noting which packages were indeed installed. The configuration we've got now actually gets us reasonably close to that via incantations like the following: | RUN apt-get update apt-get install -y some-packages rm -rf /var/lib/apt/lists/* Relevant list for a simple package like busybox-static: | A /bin/busybox | A /usr/share/man/man1/busybox.1.gz | A /usr/share/doc/busybox-static/changelog.Debian.gz | ... | A /usr/share/doc/busybox-static/syslog.conf.txt | A /usr/share/initramfs-tools/hooks/zz-busybox | C /var/lib/dpkg/status-old | C /var/lib/dpkg/triggers | C /var/lib/dpkg/triggers/Lock | C /var/lib/dpkg/info | A /var/lib/dpkg/info/busybox-static.list | A /var/lib/dpkg/info/busybox-static.md5sums | C /var/lib/dpkg/status | C /var/lib/dpkg/lock | A /var/lib/apt/extended_states | A /var/lib/apt/lists/httpredir.debian.org_debian_dists_sid_InRelease | A /var/lib/apt/lists/httpredir.debian.org_debian_dists_sid_main_binary-amd64_Packages.gz | A /var/lib/apt/lists/lock | A /var/log/apt/history.log | A /var/log/apt/term.log | C /var/log/dpkg.log If there's a better way to accomplish this, I'm very interested, because I'm not particularly happy about hard-coding so much APT internal knowledge (especially since the /var/lib/apt/lists bit there gets encoded in actual end-user Dockerfiles, not just baked into the base image). The full source of all configuration modifications is in the script that builds the images: https://github.com/docker/docker/blob/5fd15da7daad56c07842ecda082e9c5d0e6ff620/contrib/mkimage/debootstrap#L36-L152 ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Bug#796321: contributors.debian.org: foo-source.json example doesn't work
Package: nm.debian.org Severity: minor Tags: patch Firstly, thanks for your work. The following command doesn't add the foo source. ./manage.py import_sources foo-source.json The following commit solves it: https://gitlab.com/sim6/debian_contributors/commit/ac97c8e776331ecee2eaa3bb2a8b8d77307d5449 Thanks again. signature.asc Description: PGP signature
Bug#796328: dh_apache2: add dependence on a real apache2 package
Package: dh-apache2 Severity: important Debhelper script puts apache2-bin ( = 2.4.16 ) line, this is wrong, according to the apache2-module-depends-on-real-apache2-package lintian error: --8-- Binary module packages must depend on the virtual apache2-api-MMNN package only in order to ease transitions in future. In particular, module packages must not pull the full web server or any of its associated data packages as a dependency. --8--
Bug#796330: d-shlibs: locale-dependent sorting
Source: d-shlibs Version: 0.62 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: toolchain locale X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi! While working on the reproducible builds effort [1], we have noticed that the order of dependencies generated by d-devlibdeps varies depending on the configured locale. The attached patch fixes this by sorting with the C locale. Regards, Reiner [1]: https://wiki.debian.org/ReproducibleBuilds diff --git a/d-devlibdeps b/d-devlibdeps index 9e23e6c..2e59ee0 100755 --- a/d-devlibdeps +++ b/d-devlibdeps @@ -232,7 +232,7 @@ outputtmp=$(tempfile) getname $A echo $RETURN-dev | overridedevlibdeps done \ - | sort \ + | LC_ALL=C sort \ | uniq \ | while read B B_alt; do if validate_package $B; then signature.asc Description: OpenPGP digital signature
Bug#796331: emdebian-archive-keyring: The following signatures were invalid: REVKEYSIG B5B7720097BB3B58
Package: emdebian-archive-keyring Version: 2.0.5 Severity: grave Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I upgraded from wheezy to jessie a Virtual Machine (Virtualbox) I use to develop ARM code. At end of dist-upgrade I started consistently to have the following error: root@ariag25:~# apt-get update Hit http://ftp.it.debian.org jessie InRelease Get:1 http://www.emdebian.org jessie InRelease [5,012 B] Hit http://security.debian.org jessie/updates InRelease Hit http://ftp.it.debian.org jessie-updates InRelease Ign http://www.emdebian.org jessie InRelease Hit http://ftp.it.debian.org jessie/main Sources Hit http://security.debian.org jessie/updates/main Sources Hit http://ftp.it.debian.org jessie/main amd64 Packages Ign http://www.emdebian.org jessie/main amd64 Packages/DiffIndex Hit http://security.debian.org jessie/updates/main amd64 Packages Hit http://ftp.it.debian.org jessie/non-free amd64 Packages Hit http://security.debian.org jessie/updates/non-free amd64 Packages Hit http://ftp.it.debian.org jessie/main Translation-en Hit http://ftp.it.debian.org jessie/non-free Translation-en Hit http://security.debian.org jessie/updates/main Translation-en Hit http://ftp.it.debian.org jessie-updates/main Sources Hit http://security.debian.org jessie/updates/non-free Translation-en Get:2 http://ftp.it.debian.org jessie-updates/main amd64 Packages/DiffIndex [643 B] Hit http://ftp.it.debian.org jessie-updates/non-free amd64 Packages Get:3 http://ftp.it.debian.org jessie-updates/main Translation-en/DiffIndex [229 B] Hit http://ftp.it.debian.org jessie-updates/non-free Translation-en Hit http://www.emdebian.org jessie/main amd64 Packages Ign http://www.emdebian.org jessie/main Translation-en_US Ign http://www.emdebian.org jessie/main Translation-en Fetched 5,884 B in 1s (4,079 B/s) Reading package lists... Done W: GPG error: http://www.emdebian.org jessie InRelease: The following signatures were invalid: REVKEYSIG B5B7720097BB3B58 Emdebian Archive Signing Key * What exactly did you do (or not do) that was effective (or ineffective)? I tried to manually install the key: root@ariag25:/media/cdrom# gpg --keyserver pgp.mit.edu --recv-keys B5B7720097BB3B58 gpg: directory `/root/.gnupg' created gpg: new configuration file `/root/.gnupg/gpg.conf' created gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/root/.gnupg/secring.gpg' created gpg: keyring `/root/.gnupg/pubring.gpg' created gpg: requesting key 97BB3B58 from hkp server pgp.mit.edu gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key 97BB3B58: public key Emdebian Archive Signing Key imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 root@ariag25:/media/cdrom# gpg --armor --export 97BB3B58 | apt-key add - OK I also (manually) upgraded to new version (from sid archives): root@ariag25:~# wget http://ftp.fi.debian.org/debian/pool/main/e/emdebian-archive-keyring/emdebian-archive-keyring_2.0.5_all.deb --2015-08-21 12:34:09-- http://ftp.fi.debian.org/debian/pool/main/e/emdebian-archive-keyring/emdebian-archive-keyring_2.0.5_all.deb Resolving ftp.fi.debian.org (ftp.fi.debian.org)... 130.230.54.99, 2001:708:310:54::99 Connecting to ftp.fi.debian.org (ftp.fi.debian.org)|130.230.54.99|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 6942 (6.8K) [application/x-debian-package] Saving to: ‘emdebian-archive-keyring_2.0.5_all.deb’ emdebian-archive-keyring_2.0.5_ 100%[===] 6.78K --.-KB/s in 0.02s 2015-08-21 12:34:09 (350 KB/s) - ‘emdebian-archive-keyring_2.0.5_all.deb’ saved [6942/6942] root@ariag25:~# dpkg -i emdebian-archive-keyring_2.0.5_all.deb Selecting previously unselected package emdebian-archive-keyring. (Reading database ... 78608 files and directories currently installed.) Preparing to unpack emdebian-archive-keyring_2.0.5_all.deb ... Unpacking emdebian-archive-keyring (2.0.5) ... Setting up emdebian-archive-keyring (2.0.5) ... OK * What was the outcome of this action? No difference: the error is absolutely the same. * What outcome did you expect instead? I expected to be able to apt-get update with no errors. I asssume the problem is with key generation (apparently missing the revocation certificate). I will install with the --allow-unauthenticated, but that does not seem right, does it? *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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
Bug#796318: Acknowledgement (roundcube-core: tinymce fails to load after upgrade from 1.1.1+dfsg.1-2)
PS: dpkg --force-depends --remove roundcube-core; apt-get install roundcube-core resolved the situation for me.
Bug#792631: python-librtmp: diff for NMU version 0.2.2-1.1
Control: tags 792631 + patch
Control: tags 792631 + pending
Dear maintainer,
I've prepared an NMU for python-librtmp (versioned as 0.2.2-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards,
SR
diff -Nru python-librtmp-0.2.2/debian/changelog python-librtmp-0.2.2/debian/changelog
--- python-librtmp-0.2.2/debian/changelog 2015-05-12 19:38:08.0 +0200
+++ python-librtmp-0.2.2/debian/changelog 2015-08-21 12:55:23.0 +0200
@@ -1,3 +1,12 @@
+python-librtmp (0.2.2-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Build-Depend on python{,3}-cffi-backend-dbg instead of
+python{,3}-cffi-dbg, it was renamed without a transition package
+(Closes: #792631).
+
+ -- Stefano Rivera stefa...@debian.org Fri, 21 Aug 2015 12:54:19 +0200
+
python-librtmp (0.2.2-1) unstable; urgency=low
* New upstream version
diff -Nru python-librtmp-0.2.2/debian/control python-librtmp-0.2.2/debian/control
--- python-librtmp-0.2.2/debian/control 2015-05-12 19:38:08.0 +0200
+++ python-librtmp-0.2.2/debian/control 2015-08-21 12:54:16.0 +0200
@@ -12,8 +12,8 @@
python3-all-dbg,
python-cffi,
python3-cffi,
- python-cffi-dbg,
- python3-cffi-dbg,
+ python-cffi-backend-dbg,
+ python3-cffi-backend-dbg,
python-setuptools,
python3-setuptools,
python-singledispatch,
Bug#768724: fixed in auctex 11.87-3
Hi, On Tue, Nov 11, 2014 at 10:19:01PM +, Davide G. M. Salvetti wrote: auctex (11.87-3) testing; urgency=medium . * [59fd7bc] Drop emacs23 dependencies, keep emacs24 to the front. Thanks to Lucas Nussbaum (Closes: #768724) This bug is fixed in testing, but the version in unstable is still affected by it. Could you do an upload for that as well? Cheers, Ivo
Bug#793991: Update on bug#793991: lazarus: armel and armhf builds stall
Just so everybody can be aware, Graham and me here at Debconf15 have been working on a strategy to tackle this and I have been working on and off the last couple of days to work on the first track with mild success. Graham will hopefully be able to work on the second track when he returns home. Track 1): - Hypothesis: the issue exposes a threading problem in the arm implementation of fpc - This track will only help us to get more upstream involvement and maybe solve the issue in experimental - This may mean that all the build packages on ARM don't work properly anyways if they use threading - Actions1: * Build fpc from the trunk tree (maybe the issue is solved already upstream) * Build lazarus with that * Build a reverse dependency and see that the issue is gone. - Actions2: * Run the reverse dependencies on ARM hardware and see if they work Track 2): - Hypothesis: the new lazbuild implementation is broken on arm - This track can just be applied in the current unstable but is not sustainable in the future. - Actions: * Revert (only) the change in lazbuild * Build a reverse dependency and see that the issue is gone. Track 3): - Hypothesis: there is an issue with the current optimization on ARM (maybe this explains why the debugging rebuild of Abou run successfully.) - This may be a full solution for Debian - Actions: * Rebuild the whole stack with debugging symbols on (this is the default for c programs in Debian anyways) * Rebuild the whole stack with different optimization (on ARM only?) Question to Abou: - how did you build with debugging symbols on? - how did you install your new packages in order to build the package with your new package on the porterbox? Paul signature.asc Description: OpenPGP digital signature
Bug#775140: Patch to build with libmaa-dev package
On Fri, 2015-08-21 at 08:36 +0200, Edward Betts wrote: I managed to get dict-gcide to build with the libmaa-dev package. Here is a patch. Thank you Edward, for the bug report and the patch. I'll prepare the package soon and push an upload. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#796333: mirror submission for ftp.uni-mainz.de
Package: mirrors Severity: wishlist Submission-Type: new Site: ftp.uni-mainz.de Type: leaf Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc Archive-ftp: /debian/ Archive-http: /debian/ IPv6: yes Archive-upstream: ftp.de.debian.org Updates: four Maintainer: Christoph Martin mar...@uni-mainz.de Country: DE Germany Location: Mainz Sponsor: Johannes Gutenberg University Mainz, ZDV http://www.zdv.uni-mainz.de Comment: I tried to create this entry several times in the last years and never got a feedback.
Bug#796324: fftw3: please make the build reproducible
Source: fftw3
Version: 3.3.4-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi!
While working on the reproducible builds effort [1], we have noticed
that fftw3 could not be built reproducibly.
The current date is embedded into documentation files.
The attached patch removes those timestamps as they provides no
useful information.
Regards,
Reiner
[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible_build.patch b/debian/patches/reproducible_build.patch
new file mode 100644
index 000..702ca3d
--- /dev/null
+++ b/debian/patches/reproducible_build.patch
@@ -0,0 +1,52 @@
+Author: Reiner Herrmann rei...@reiner-h.de
+Description: Remove dates from documentation to get reproducible documentation
+
+Index: fftw3-3.3.4/doc/FAQ/fftw-faq.bfnn
+===
+--- fftw3-3.3.4.orig/doc/FAQ/fftw-faq.bfnn
fftw3-3.3.4/doc/FAQ/fftw-faq.bfnn
+@@ -12,7 +12,7 @@
+ \call-html startup html.refs2
+ \copyto ASCII
+ FFTW FREQUENTLY ASKED QUESTIONS WITH ANSWERS
+-`date '+%d %h %Y'`
++
+ Matteo Frigo
+ Steven G. Johnson
+ f...@fftw.org
+@@ -28,7 +28,7 @@ END-INFO-DIR-ENTRY
+ File: $prefix.info, Node: Top, Next: Question 1.1, Up: (dir)
+
+ FFTW FREQUENTLY ASKED QUESTIONS WITH ANSWERS
+-`date '+%d %h %Y'`
++
+ Matteo Frigo
+ Steven G. Johnson
+ f...@fftw.org
+Index: fftw3-3.3.4/doc/FAQ/m-html.pl
+===
+--- fftw3-3.3.4.orig/doc/FAQ/m-html.pl
fftw3-3.3.4/doc/FAQ/m-html.pl
+@@ -33,8 +33,6 @@ sub html_init {
+ print HTML html\n;
+ $html_needpara= -1;
+ $html_end='';
+-chop($html_date=`date '+%d %B %Y'`);
+-chop($html_year=`date '+%Y'`);
+ }
+
+ sub html_startup {
+@@ -70,11 +68,10 @@ END
+ }
+
+ sub html_close {
+-print HTML $html_end,address\n$user_author\n;
+-print HTML - $html_date\n/addressbr\n;
++print HTML $html_end,address\n$user_author\n/addressbr\n;
+ print HTML Extracted from $user_title,\n;
+ print HTML A href=\$html_copyrighthref\ if length($html_copyrighthref);
+-print HTML Copyright copy; $html_year $user_copyholder.;
++print HTML Copyright copy; 2015 $user_copyholder.;
+ print HTML /A if length($html_copyrighthref);
+ print HTML \n/body/html\n;
+ close(HTML);
diff --git a/debian/patches/series b/debian/patches/series
index 81a516c..0aadf6c 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
fix-runtime-neon-detection.patch
+reproducible_build.patch
signature.asc
Description: OpenPGP digital signature
Bug#796322: visolate: Does not start
Package: visolate Version: 2.1.6~svn8+dfsg1-2 Severity: grave Justification: renders package unusable Hi, I am not able to start visolate without hacking the LD_LIBRARY_PATH. formorer@smithers ~ % visolate Exception in thread main java.lang.UnsatisfiedLinkError: no j3dcore-ogl in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1865) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1122) at javax.media.j3d.NativePipeline$1.run(NativePipeline.java:231) at java.security.AccessController.doPrivileged(Native Method) at javax.media.j3d.NativePipeline.loadLibrary(NativePipeline.java:200) at javax.media.j3d.NativePipeline.loadLibraries(NativePipeline.java:157) at javax.media.j3d.MasterControl.loadLibraries(MasterControl.java:987) at javax.media.j3d.VirtualUniverse.clinit(VirtualUniverse.java:299) at visolate.Display.init(Display.java:100) at visolate.Visolate.init(Visolate.java:75) at visolate.Visolate.init(Visolate.java:69) at visolate.Main.main(Main.java:104) If I set export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni it works. Thanks -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages visolate depends on: ii libcommons-cli-java 1.3.1-2 ii libjava3d-java 1.5.2+dfsg-11 ii libvecmath-java 1.5.2-5 visolate recommends no packages. visolate suggests no packages. -- no debconf information
Bug#796323: stretch-pu: package icedove/38.2.0-1~stretch
Package: release.debian.org Severity: normal Tags: strech User: release.debian@packages.debian.org Usertags: pu Hello there, due the GCC-5 transition we would like to upload the current Icedove ESR version (aka Thunderbird 38.2.0) to proposed updates for jessie. The latest beta version 40.0~b1 is uploaded several days ago to experimental and the previous version 38.1.0-1 is currently in unstable. Due not go out of sync to current upstream versions we would like to place a recent version into stretch via proposed updated. We are working also on providing versions for stable-security and oldstable-security, but that's not the focus here. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#796325: linux-image-3.16-3-amd64: Kernel crash in skb_warn_bad_offload(?) since upgrading to 3.16.0-4-amd64
Package: src:linux Version: 3.16.5-1 Severity: normal Dear Maintainer, on 2015-08-13 I rebooted this computer to update the Kernel from 3.16-3 to 3.16.0-4. Since then I have from 200 to 2000 Events of these kind a day. This is the trace from the logs: Aug 21 06:27:36 node2 kernel: [1106326.225132] [ cut here ] Aug 21 06:27:36 node2 kernel: [1106326.225159] WARNING: CPU: 1 PID: 1523 at /build/linux-ELRFVQ/linux-3.16.7-ckt11/net/core/dev.c:2247 skb_warn_bad_offload+0xc6/0xd1() Aug 21 06:27:36 node2 kernel: [1106326.225202] r8169: caps=(0x00044180, 0x) len=1714 data_len=0 gso_size=1448 gso_type=5 ip_summed=0 Aug 21 06:27:36 node2 kernel: [1106326.225242] Modules linked in: xt_nat vhost_net vhost macvtap macvlan xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ip6t_REJECT ip6table_filter ip6_tables ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc tun binfmt_misc cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative x86_pkg_temp_thermal intel_powerclamp intel_rapl coretemp kvm_intel kvm crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul iTCO_wdt iTCO_vendor_support mxm_wmi glue_helper ppdev parport_pc parport ablk_helper evdev cryptd i2c_i801 shpchp i2c_core serio_raw mei_me mei lpc_ich mfd_core wmi battery video tpm_infineon tpm_tis tpm processor button loop autofs4 ext4 crc16 mbcache jbd2 btrfs xor raid6_pq dm_mod raid1 md_mod sg sd_mod crc_t10dif crct10dif_generic ahci libahci crct10dif_pclmul libata ehci_pci crct10dif_common ehci_hcd xhci_hcd crc32c _intel r8169 usbcore scsi_mod mii usb_common thermal fan thermal_sys Aug 21 06:27:36 node2 kernel: [1106326.225593] CPU: 1 PID: 1523 Comm: qemu-system-x86 Tainted: GW 3.16.0-4-amd64 #1 Debian 3.16.7-ckt11-1+deb8u3 Aug 21 06:27:36 node2 kernel: [1106326.225634] Hardware name: MSI MS-7816/H87-G43 (MS-7816), BIOS V2.14B11 06/30/2014 Aug 21 06:27:36 node2 kernel: [1106326.225669] 0009 8150b3a5 88081ea43ab0 81067767 Aug 21 06:27:36 node2 kernel: [1106326.225706] 8807fd23c800 88081ea43b00 0005 Aug 21 06:27:36 node2 kernel: [1106326.225742] 8807fd23c800 810677cc 81776548 0030 Aug 21 06:27:36 node2 kernel: [1106326.225779] Call Trace: Aug 21 06:27:36 node2 kernel: [1106326.225795] IRQ [8150b3a5] ? dump_stack+0x41/0x51 Aug 21 06:27:36 node2 kernel: [1106326.225822] [81067767] ? warn_slowpath_common+0x77/0x90 Aug 21 06:27:36 node2 kernel: [1106326.225844] [810677cc] ? warn_slowpath_fmt+0x4c/0x50 Aug 21 06:27:36 node2 kernel: [1106326.225869] [8150cb3d] ? skb_warn_bad_offload+0xc6/0xd1 Aug 21 06:27:36 node2 kernel: [1106326.225892] [8141e4a1] ? __skb_gso_segment+0x71/0xc0 Aug 21 06:27:36 node2 kernel: [1106326.225914] [8141e7ea] ? dev_hard_start_xmit+0x16a/0x560 Aug 21 06:27:36 node2 kernel: [1106326.225940] [8143edf9] ? sch_direct_xmit+0xc9/0x1a0 Aug 21 06:27:36 node2 kernel: [1106326.225961] [8141edd4] ? __dev_queue_xmit+0x1f4/0x4c0 Aug 21 06:27:36 node2 kernel: [1106326.225984] [814585ab] ? ip_finish_output+0x68b/0x840 Aug 21 06:27:36 node2 kernel: [1106326.226007] [8141cd23] ? __netif_receive_skb_core+0x533/0x750 Aug 21 06:27:36 node2 kernel: [1106326.226030] [8141cfbf] ? netif_receive_skb_internal+0x1f/0x90 Aug 21 06:27:36 node2 kernel: [1106326.226055] [a04a2e92] ? br_handle_frame_finish+0x1c2/0x3c0 [bridge] Aug 21 06:27:36 node2 kernel: [1106326.226092] [a04a98d0] ? br_nf_pre_routing_finish+0x120/0x390 [bridge] Aug 21 06:27:36 node2 kernel: [1106326.226128] [a04a9dcb] ? br_nf_pre_routing+0x28b/0x630 [bridge] Aug 21 06:27:36 node2 kernel: [1106326.226152] [a04a2cd0] ? br_handle_local_finish+0x80/0x80 [bridge] Aug 21 06:27:36 node2 kernel: [1106326.226188] [8144d6c5] ? nf_iterate+0x65/0xa0 Aug 21 06:27:36 node2 kernel: [1106326.226210] [a04a2cd0] ? br_handle_local_finish+0x80/0x80 [bridge] Aug 21 06:27:36 node2 kernel: [1106326.226245] [8144d776] ? nf_hook_slow+0x76/0x130 Aug 21 06:27:36 node2 kernel: [1106326.226267] [a04a2cd0] ? br_handle_local_finish+0x80/0x80 [bridge] Aug 21 06:27:36 node2 kernel: [1106326.226302] [a04a3200] ? br_handle_frame+0x170/0x240 [bridge] Aug 21 06:27:36 node2 kernel: [1106326.226325] [8141c9a4] ? __netif_receive_skb_core+0x1b4/0x750 Aug 21 06:27:36 node2 kernel: [1106326.226349] [810446cf] ? lapic_next_deadline+0x2f/0x40 Aug 21 06:27:36 node2 kernel: [1106326.226371] [8141db65] ? process_backlog+0x95/0x160 Aug 21 06:27:36 node2 kernel: [1106326.226393] [8141d350] ? net_rx_action+0x140/0x240 Aug 21 06:27:36 node2 kernel: [1106326.226415] [8106c611] ?
Bug#795262: nvidia-cuda-toolkit: Reboot, after package installation, do not unload the Nouveau drivers
On 21 August 2015 at 11:15, François Legendre f.legen...@u-pec.fr wrote: Hello, I thought IMHO that the maintainers of nvidia-cuda-toolkit should set a dependency : nvidia-cuda-toolkit depends on nvidia-driver as nouveau drivers are not able to run a CUDA application. Hello François, Thanks for sharing your view. In my opinion that would not be desirable, because as far as I understand the toolkit can be used to just build the applications, and it should be entirely possible to do so on a headless machine designated as a build server with no graphics stack installed. If we added a dependency on the driver, this would no longer be possible, and the toolkit would then depend on the whole X stack. I think it's good that there is a clear separation between the build stack and the runtime stack, as it is often the case. The toolkit dependency chain already has a suggests on the nvidia-driver package (there might even be a recommends along the way, can't remember), and on top of that the Nvidia documentation makes clear that the driver is required to run the programs. In my opinion, this should be enough. Vincent, Graham, Andreas, thoughts? Kind regards, Luca Boccassi
Bug#796314: openssh: copying special crafted filenames executes shell-command
On Fri, Aug 21, 2015 at 11:35:08AM +0200, bgr...@toplitzer.net wrote: According to [1] special crafted filenames containing control characters can cause scp to execute commands in the current shell. For clarity, that's not what the upstream bug report says. This is *not* a matter of scp executing commands in the current shell, but rather a matter of scp sending escape sequences to the terminal; quite a different thing. That is, tput clear emits an escape sequence which causes the terminal to clear the screen, and when scp prints the file name it reproduces that escape sequence and thereby clears the screen. -- Colin Watson [cjwat...@debian.org]
Bug#796326: nmu: gtkspellmm_3.0.3+dfsg-1+b1 on arm64
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu I think gtkspellmm needs a binNMU on arm64. https://buildd.debian.org/status/package.php?p=gimagereadersuite=sid says: Dependency installability problem for gimagereader on arm64: gimagereader build-depends on: - arm64:libgtkmm-3.0-dev arm64:libgtkmm-3.0-dev depends on: - arm64:libgtkmm-3.0-1v5 (= 3.16.0-2) gimagereader build-depends on: - arm64:libgtkspellmm-3.0-dev arm64:libgtkspellmm-3.0-dev depends on: - arm64:libgtkspellmm-3.0-0 (= 3.0.3+dfsg-1+b1) arm64:libgtkspellmm-3.0-0 depends on: - arm64:libgtkmm-3.0-1 (= 3.16.0) arm64:libgtkmm-3.0-1v5 conflicts with: - arm64:libgtkmm-3.0-1
Bug#796327: nmu: libgnomecanvasmm2.6_2.26.0-1.1+b1 on arm64
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu I think libgnomecanvasmm2.6 needs a binNMU on arm64. https://buildd.debian.org/status/package.php?p=ardour3suite=sid says: Dependency installability problem for ardour3 on arm64: ardour3 build-depends on: - arm64:libpangomm-1.4-dev (= 2.28.4) arm64:libpangomm-1.4-dev depends on: - arm64:libpangomm-1.4-1v5 (= 2.36.0-2) ardour3 build-depends on: - arm64:libgnomecanvasmm-2.6-dev (= 2.26.0) arm64:libgnomecanvasmm-2.6-dev depends on: - arm64:libgnomecanvasmm-2.6-1c2a (= 2.26.0-1.1+b1) arm64:libgnomecanvasmm-2.6-1c2a depends on: - arm64:libpangomm-1.4-1 (= 2.36.0) arm64:libpangomm-1.4-1v5 conflicts with: - arm64:libpangomm-1.4-1
Bug#788708: iceweasel: GStreamer causes segmentation fault
This looks at first glance like some GStreamer element(s) could not be created, such as appsink, maybe others too; possibly because the required GStreamer plugins are not installed. Combined with insufficient error handling. I note that this bug was reported against an iceweasel version that uses the old and unmaintained GStreamer 0.10.x. The current iceweasel version uses GStreamer 1.x, and I can't reproduce this problem with 38.2.0esr-1 either.
Bug#793412: Bug#796314: openssh: copying special crafted filenames executes shell-command
On 2015-08-21 11:35:08 +0200, bgr...@toplitzer.net wrote: According to [1] special crafted filenames containing control characters can cause scp to execute commands in the current shell. It cannot execute arbitrary shell commands (except if the terminal has an extension to do that via escape sequences, but without a signature mechanism, such a feature would be too risky in practice), but it can do everything what is possible via escape sequences. In practice: * make the terminal unusable (a terminal reset may be needed, in which case one also loses all the data that were in it); * possibly send a copy of the terminal to the default printer, which may be a shared printer in a lab (this xterm feature is now disabled by default, but some users may have enabled it because they use it); * try to exploit another security bug. For instance, one can set the window title to an arbitrary string, so that this may be a vector of attack against the X server and the window manager. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#796329: dracut: tries to locate plugins in /lib64
Source: dracut Severity: normal Hi, /usr/lib/dracut/dracut-functions.sh contains this snippet: # Detect lib paths if ! [[ $libdirs ]] ; then if [[ $(ldd /bin/sh) == */lib64/* ]] /dev/null \ [[ -d /lib64 ]]; then libdirs+= /lib64 [[ -d /usr/lib64 ]] libdirs+= /usr/lib64 else This won't work out, because $ ldd /bin/sh linux-vdso.so.1 (0x7ffe5bd8f000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f0ad85de000) /lib64/ld-linux-x86-64.so.2 (0x7f0ad8ba8000) but ld-linux-x86-64.so.2 is the only file in /lib64, and as a result, inst_libdir_file libmultipath* multipath/* in /usr/lib/dracut/modules.d/90multipath/module-setup.sh won't install /lib/multipath/* into the initramfs. Btw. the libmultipath* part is not needed, because that's a dependency of /sbin/multipath, thus gets included by other means. Other modules with dynamic plugins may also be affected. I recommend dropping the first part of the libdir detection logic above, and just using /lib and /usr/lib all the time, as in the else branch. Debian adheres to the multiarch specification, so /lib64 is not used by the dynamic linker. -- Thanks, Feri.
Bug#796302: curl: enable http2
Control: block -1 by 784666 On Fri, Aug 21, 2015 at 10:59:41am +0200, Arnout Engelen wrote: Package: curl Version: 7.44.0-1 Severity: normal Dear Maintainer, When making a request with '--http2', I get the error message curl: (1) Unsupported protocol. Unfortunately the version of the nghttp2 library (which is used by curl to implement HTTP/2 support) in Debian is too old. Cheers signature.asc Description: Digital signature
Bug#682580: [bug-gettext] Bug#682580: xgettext: fails to properly replace some placeholders in output .pot (PACKAGE, YEAR, C. HOLDER) (fwd)
On Fri, Aug 21, 2015 at 05:49:00PM +0900, Daiki Ueno wrote: What else was remaining to close this bug? In Debian we usually close a bug when there is a new package available in unstable fixing the bug. This is what I will do for the Debian package but of course you might have different rules for the gettext bugzilla.
Bug#685416: sbuild: symlink to build log is absolute
Hi,
On Fri, 21 Aug 2015 09:24:21 +0200 Joachim Breitner nome...@debian.org wrote:
On Mon, 20 Aug 2012 18:53:02 +0200 Jakub Wilk jw...@debian.org wrote:
The symlink to build log that sbuild creates is absolute:
$ readlink python-pipeline_0.1.3-3_i386.build
/home/jwilk/python-pipeline_0.1.3-3_i386-20120820-1846.build
It used to be relative in older (= 0.63.1-1) versions of sbuild. Could you
restore the previous behavior? Thanks.
the bug is still present, and has caused me a minor annoyance.
same here.
Please find a patch attached which uses a relative symlink if the log directory
is equal to the build directory (the default) and if sbuild is not in buildd
mode.
Would this solve the problem?
Thanks!
cheers, josch
diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index 41a8f68..5661cd7 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -2161,7 +2161,13 @@ sub open_build_log {
$self-get_conf('BUILD_DIR') . '/current-' .
$self-get_conf('DISTRIBUTION'));
} else {
- $self-log_symlink($filename,
+ my $symlinktarget = $filename;
+ # if symlink target is in the same directory as the symlink
+ # itself, make it a relative link instead of an absolute one
+ if (Cwd::abs_path($self-get_conf('BUILD_DIR')) eq Cwd::abs_path(dirname($filename))) {
+ $symlinktarget = basename($filename)
+ }
+ $self-log_symlink($symlinktarget,
$self-get_conf('BUILD_DIR') . '/' .
$self-get('Package_SVersion') . '_' .
$self-get('Host Arch') . .build);
signature.asc
Description: signature
Bug#796293: insufficient/confusing documentation for pgpsigurlmangle
Hi Thomas-- Thanks for the useful feedback. The documentation tries to be short but complete, and clearly we have a ways to go for improvement. I'll answer your questions below -- maybe you can propose a patch that would make these answers clearer without bloating or overcomplicating uscan(1) ? On Fri 2015-08-21 09:13:02 +0200, Thomas Koch wrote: There are a few related shortcomings with the documentation of pgpsigurlmangle and the related lintian tag debian-watch-may-check-gpg-signature. 1) The uscan manpage says: This signature must be made by a key found in the keyring debian/upstream/signing-key.pgp or the armored keyring debian/upstream/signing-key.asc. A keyring is a linear concatenation of OpenPGP Transferable Public Keys https://tools.ietf.org/html/rfc4880#section-11.1 - - What is an armored keyring? The difference between an armored keyring and a non-armored keyring is ASCII armoring: https://tools.ietf.org/html/rfc4880#section-6.2 - - Isn't it, that the .asc file is just one public key as produced by gpg --armor --export $KEYID? No, you can have multiple signing keys in the file -- for example, some projects have multiple release managers. - - Please give an example how to correctly produce this file. gpg --export-options export-minimal --armor --export $FINGERPRINT debian/upstream/signing-key.asc - - How can I produce a keyring .pgp file? Same as above, but without --armor. - - Which format should be preferred? I don't like choices. The currently encouraged format is the armored one: debian/upstream/signing-key.asc We support the other options because they already exist in the archive: debian/upstream/signing-key.pgp debian/upstream-signing-key.pgp debian/upstream-signing-key.asc Maybe what we could do is find all of them in the archive, get them switched over, and then drop support for the old ones to make it less confusing for new adopters? I'm having a hard time finding these files via codesearch, but maybe i'm just searching wrong. 2) There is no example of a full watch file with a pgpsigurlmangle option. I needed several tries to get it right because it was the first time that I had to produce a non trivial watch file with an option. I believe that many others might be in the same situation. Please add an example to the uscan manpage or the lintian tag or both. agreed, fully! The openssh debian/watch file is probably fine: 0 dkg@alice:~/src/openssh/debian$ cat debian/watch version=3 opts=pgpsigurlmangle=s/$/.asc/ \ ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-(.*)\.tar\.gz 0 dkg@alice:~/src/openssh/debian$ 3) The lintian tag says: verified against a keyring stored in debian/upstream-signing-key.asc The manpage does not mention this file. It seems that the code still uses it, but it is confusing. yes, we should adjust the lintian tag info. 4) How about a script, that checks all watch files, tries GET requests against $URL.sig, $URL.asc and proposes a new watch file to the maintainer in case it finds something? I believe uscan already does this autosearch, but doesn't propose an explicit watch file edit. patches to uscan for this? --dkg signature.asc Description: PGP signature
Bug#796332: ITP: node-through -- Create a ReadableWritable stream - Node.js module
Package: wnpp Severity: wishlist Package name: node-through Version: 2.3.8 Upstream Author: Dominic Tarr URL: https://github.com/dominictarr/through License: Apache-2 or Expat Description: through is a Node.js module that can easily create a Stream that is both readable and writable. It automatically takes care of pause and resume logic, and exposes tools to help manage flow. -- Harlan Lieberman-Berg ~hlieberman
Bug#741147: mutt writes header contradicting pkcs7 signature
Hello. I can verify the problem and also that the workaround from Raoul Borenius solves the problem. The string sha1 that goes into the header is hardcoded in smime.c. Please include this in an update for jessie, since it makes s/mime support behave badly. /Tomas -- Tomas Forsman, st...@cs.umu.se, http://www.cs.umu.se/~stric/ `- SysAdmin at Computing Science, University of Umeå smime.p7s Description: S/MIME cryptographic signature
Bug#796303: guessnet: FTBFS: undefined reference to `std::__cxx11::basic_stringchar, std::char_traits [..]
On 21/08/15 11:03, Chris Lamb wrote: guessnet fails to build from source on testing/amd64: Chris, I don't maintain or use this package anymore. Also, I know little to nothing about C++11 and the transition, so I don't think I can actually fix this breakage. Should you prepare a patch to fix the issue, please feel free to do an NMU. -- Cheers, Andrew signature.asc Description: OpenPGP digital signature
Bug#742627: mutt-patched: full text search (l + ~b text) is extremely slow
Hello. I can verify the problem and that the commit in http://dev.mutt.org/hg/mutt/rev/755a18da99bc restores performance from abysmal to usable. When checking my inbox, mutt does a clone() over 20 times, which seems a bit excessive. Please include this in an update for jessie, since body searches are no longer usable in the current state with no easy method to abort (apart from ^Z and kill %1). /Tomas -- Tomas Forsman, st...@cs.umu.se, http://www.cs.umu.se/~stric/ `- SysAdmin at Computing Science, University of Umeå
Bug#682798: ERROR: Node N cannot be found in the node store M (too many open files)
same problem here with Debian Jessie on amd64 with python-larch 1.20131130-1 and obnam 1.8-1. Did anyone found an alternative? I just need: * backup over sftp * gpg encryption support (signature using different key would be nice too) * automatic checkpoints * should be in Debian Jessie * old backups should be possible to get removed * incremental backup
Bug#796345: transition: perl 5.22
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-p...@lists.debian.org Hello, This is a tracking bug for the planned transition to perl 5.22. We would like this to be considered for sometime after the gcc-5 transition, and expect to be mostly ready to go within the next few weeks. The current stats for this transition are as follows: * Number of binNMUs needed: 571[1] * Number of arch:any packages which FTBFS with perl 5.22: 9 * 1 fix in DELAYED; 2 mostly fixed but awaiting upload; 6 needing more work or removal. * The most significant problem at the moment is libapache2-mod-perl2, where upstream have not yet provided support for perl 5.22 (help welcome: #787493). For most of the others[2] removal is a plausible option. * Number of arch:all packages which FTBFS with perl 5.22: approx 60[3] * We obviously need to get this number down; most of them are fairly straightforward changes that the pkg-perl will hopefully be able to help with (either because they are team maintained, or via NMUs) * I am still waiting for the results of another mass-rebuild, and to retest some corner cases, so a few new bugs may still be reported, but we now have the vast majority of them The version of perl we expect to upload to unstable will differ from that currently in experimental (5.22.0-2) in including (hopefully) changes which will make the package fully reproducible, as well as a few other minor fixes. We don't expect these changes to reveal any further compatibility issues. It's also just possible that perl 5.22.1 will be released before we go ahead with the transition (it's currently scheduled for some time in September) in which case it would be better to use that for the transition. The other change worth mentioning is the introduction of a revised package layout (option 'S' in [4]). We will send a mail out to debian-devel prior to the transition starting, explaining this and other general information. Hopefully I've covered everything I need to at this point, but just let me now if anything needs clarifying. Cheers, Dominic (for the perl and pkg-perl teams) [1] https://release.debian.org/transitions/html/perl.html [2] libdata-alias-perl, libb-hooks-op-check-entersubforcv-perl, libdata-dump-streamer-perl, libdevel-findref-perl, libcoro-perl [3] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.22-transition;users=debian-p...@lists.debian.org [4] https://people.debian.org/~ntyni/perl/libperl/
Bug#796344: CVE-2009-5147
Package: ruby2.1 Version: 2.1.5-4 Severity: important Tags: security This has been assigned CVE-2009-5147: http://seclists.org/oss-sec/2015/q3/222 Cheers, Moritz
Bug#792631: python-librtmp: diff for NMU version 0.2.2-1.1
Hi Stefan (2015.08.21_14:20:57_+0200) no, please continue with the upload. Rescheduled to day 0. Thank you all for debugging and patching the issue. I missed the original mails because they were marked as spam. I'll look into improving that, so that I am more responsive in the future. I could have done something sooner, too. I've been ignoring this :) SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#792447: Fwd: Re: Bug#792447: RFS: python-afl/0.2.1-1 -- American Fuzzy Lop fuzzy testing for Python code [ITP]
Forwarded Message Subject: Re: Bug#792447: RFS: python-afl/0.2.1-1 -- American Fuzzy Lop fuzzy testing for Python code [ITP] Date: Fri, 21 Aug 2015 14:25:34 +0200 From: Daniel Stender deb...@danielstender.com To: Gianfranco Costamagna costamagnagianfra...@yahoo.it On 21.08.2015 14:19, Gianfranco Costamagna wrote: Control: tags -1 moreinfo Hi Daniel, I do not remember how we left this one, anyway: now with the llvm stuff being fixed/rebuilt, I asked for a give back of afl, and it is actually building almost everywhere (just arm64 needs investigation, and s390x/kfreebsd-amd64 needs an llvm-toolchain-3.6 rebuild, ongoing right now) How do you feel about updating afl, checking if everything is good and then followup with python-afl? cheers, Gianfranco Hi Gianfranco, ... yes I was thinking about asking you if you would like to make a wrap out of both. AFL build again fine after the latest lvm-toolchain-3.5 update, so that are only the manpages are missing. I'm going to fix the AFL ITA over the weekend and come back then! Thanks! Daniel -- http://www.danielstender.com/blog/ 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Alex, let's review :) d/changelog please set to unstable, and update the timestamp d/rules: wl-asneeded is good if enable, does it introduce some problems? are both autotools-dev and autoreconf needed? usually the latter should superceed the former d/rules: I personally do not like calling bootstrap, specially when the only thing needed there seems to be applying one patch and calling and generating changelogs/manpages. I would generate them with dh_installmanpages or the equivalent dh call. d/patches/*: they seem to come from a git export-patch, are them already upstream? so why don't just ask to release a new tarball? carrying 30 patches might be a maintenance problem. debian/repack seems not policy compliant (didn't check) maybe get-orig-source.sh is better as a name also source_package_build.bash but I guess this might be a nitpick, since they are called by uscan so the user/developer never need to call them directly. d/watch what is the timestamp there? oh well, seems that upstream in that way doesn't increase the version number when releasing bad numbering is bad :) let me know, (I didn't try to build the package, and didn't check the copyrights) cheers, G. d/copyright: expat seems commented (even if not a problem) same for gpl Il Venerdì 21 Agosto 2015 14:20, Alex Vong alexvong1...@gmail.com ha scritto: Package: sponsorship-requests Severity: wishlist Hi mentors, I am looking for a sponsor for my package mlucas, I have uploaded a new version of the package to fix issues pointed out by Jakub Wilk, please see previous message in the bug report to see what issues are fixed I will now elaborate more on why this package is suitable for Debian, feel free to skip it __BEGIN_ELABORATION__ Great Internet Mersenne Prime Search (GIMPS) is a collaborative project of volunteers who use freely available software to search for Mersenne prime numbers (quote from Wikipedia). The most popular client `mprime' was available in Debian Potato as the package `prime-net' as shown in this post http://www.mersenneforum.org/showthread.php?t=7181. However, it appears the maintainer had lost interest in it because it was classified as `non-free'. `mlucas' has been developed as an alternative since 1996. While it is not as efficient as `mprime', it is licensed under GPL-2+ and thus suitable to be included in `main'. It has been used in the verification of various Mersenne primes, including the 45th (found in 2008), 46th (found in 2009) and 48th (found in 2013) found Mersenne prime. Therefore, the underlying algorithm is believed to be reliable, thus suitable to be included in Debian. __END_ELABORATION__ * Package name: mlucas Version : 14.1+dfsg-1 Upstream Author : Ernst W. Mayer ewma...@aol.com * URL : http://hogranch.com/mayer/README.html * License: GPL-2+ Section : math It builds those binary packages: mlucas - program to perform Lucas-Lehmer test on a Mersenne number To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mlucas Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mlucas/mlucas_14.1+dfsg-1.dsc Changes since the last upload: mlucas (14.1+dfsg-1) UNRELEASED; urgency=low * Initial release (Closes: #786656) -- Alex Vong alexvong1...@gmail.com Sun, 02 Aug 2015 03:13:37 +0800 Cheers, Alex
Bug#796108: [PKG-Openstack-devel] Bug#796108: CVE-2015-5694 CVE-2015-5695
On 08/19/2015 08:28 PM, Moritz Mühlenhoff wrote: On Wed, Aug 19, 2015 at 06:24:39PM +0100, Graham Hayes wrote: Ice house was not vulnerable to CVE-2015-5694 , as the affected designate component didn't exist during icehouse. Thanks, I've updated the Debian security tracker. Cheers, Moritz Hi Moritz, Should I prepare a security upload for Jessie, or do it through the release team oversight? I'll do the Sid/Testing updates when I come back home next week. Cheers, Thomas Goirand (zigo)
Bug#795925: re: testing
Hi people, The email wasn't send to Dale. Now everybody is conected. Dale please read below. On Thu, 20 Aug 2015 09:40:54 +0200 Marcus Meissner mar...@jet.franken.de wrote: Hi, Can you check if the permissions worked? after the cameras is attached: lsusb | grep Canon from output: Bus 001 Device 008: ID 04a9:30ee Canon, Inc. EOS 350D then do ls -l /dev/bus/usb/001/008 ? Ciao, Marcus regards, -- Herbert Parentes Fortes Neto (hpfn)
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Gianfranco, Thanks for the quick reply, I have just finished dinner. 2015-08-21 20:46 GMT+08:00, Gianfranco Costamagna costamagnagianfra...@yahoo.it: Hi Alex, let's review :) d/changelog please set to unstable, and update the timestamp Okay. d/rules: wl-asneeded is good if enable, does it introduce some problems? Okay I will add it. are both autotools-dev and autoreconf needed? usually the latter should superceed the former Okay I will remove autotools-dev. d/rules: I personally do not like calling bootstrap, specially when the only thing needed there seems to be applying one patch and calling and generating changelogs/manpages. I would generate them with dh_installmanpages or the equivalent dh call. d/patches/*: they seem to come from a git export-patch, are them already upstream? so why don't just ask to release a new tarball? carrying 30 patches might be a maintenance problem. Okay. I think this needs further explaination. Upstream does not include a build system, not even a Makefile. Building is done by invoking gcc directly using different flags for different platform. This is however cumbersome, so I add autotools to ease building. I use git for development https://gitlab.com/mlucas-ll/mlucas. The 29 patches can be divided into 3 groups. 0001 - 0012, 0027 are patches related to the source, forwarded upstream to be included in the next version. The rest are patches to add the build system and script to generate man page, NEWS, ChangeLog... Any advice on this? debian/repack seems not policy compliant (didn't check) maybe get-orig-source.sh is better as a name Okay changed. also source_package_build.bash but I guess this might be a nitpick, since they are called by uscan so the user/developer never need to call them directly. I do not understand. What should I do with `source_package_build.bash' ? d/watch what is the timestamp there? oh well, seems that upstream in that way doesn't increase the version number when releasing bad numbering is bad :) Upstream uses Mlucas_MM.DD..tbz2 instead of mlucas_14.1.tar.bz2 for backward capability, so we need to update debian/watch version string for every new release... let me know, (I didn't try to build the package, and didn't check the copyrights) cheers, G. d/copyright: expat seems commented (even if not a problem) same for gpl I do it beacuse lintian will complain about empty license if add `License:' in the header paragraph. While lintian will complain about unused license if I seperate the Expat-licnesed files in a seperate file paragraph. What is your recommendation? This email is probably too long... Cheers, Alex
Bug#796356: python-urllib3: broken when python-future is installed, fix available upstream
Package: python-urllib3
Version: 1.11-1
Severity: normal
This version of the package fails to work when python-future is installed.
$ python
Python 2.7.10 (default, Jul 1 2015, 10:54:53)
[GCC 4.9.2] on linux2
Type help, copyright, credits or license for more information.
import requests
requests.get('http://debian.org/')
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.7/dist-packages/requests/api.py, line 69, in get
return request('get', url, params=params, **kwargs)
File /usr/lib/python2.7/dist-packages/requests/api.py, line 50, in request
response = session.request(method=method, url=url, **kwargs)
File /usr/lib/python2.7/dist-packages/requests/sessions.py, line 465, in
request
resp = self.send(prep, **send_kwargs)
File /usr/lib/python2.7/dist-packages/requests/sessions.py, line 573, in
send
r = adapter.send(request, **kwargs)
File /usr/lib/python2.7/dist-packages/requests/adapters.py, line 370, in
send
timeout=timeout
File /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py, line
557, in urlopen
body=body, headers=headers)
File /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py, line
388, in _make_request
assert_header_parsing(httplib_response.msg)
File /usr/lib/python2.7/dist-packages/urllib3/util/response.py, line 49,
in assert_header_parsing
if not isinstance(headers, httplib.HTTPMessage):
AttributeError: 'module' object has no attribute 'HTTPMessage'
$
The start of urllib3/util/response.py looks like:
try:
import http.client as httplib
except ImportError:
import httplib
The try is expected to fail on Python 2.7, but it succeeds because
python-future includes /usr/lib/python2.7/dist-packages/http/client.py which
looks like this:
from __future__ import absolute_import
import sys
assert sys.version_info[0] 3
from httplib import *
Here is the upstream fix:
https://github.com/shazow/urllib3/commit/f4eb94bc36277d5d584683a03fc9eb3950429a15
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages python-urllib3 depends on:
ii python-six 1.9.0-3
pn python:any none
Versions of packages python-urllib3 recommends:
ii ca-certificates 20150426
ii python-ndg-httpsclient 0.4.0-1
ii python-openssl 0.15.1-2
ii python-pyasn1 0.1.8-1
Versions of packages python-urllib3 suggests:
pn python-ntlm none
-- no debconf information
--
Edward.
Bug#796355: ITP: node-readable-stream -- Streams3, a user-land copy of the stream library from iojs v2.x
Package: wnpp Severity: wishlist Owner: Ross Gammon rossgam...@mail.dk X-Debbugs-CC: debian-de...@lists.debian.org X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org * Package name: node-readable-stream Version : 2.0.2 Upstream Author : Streams WG Team christopher.s.dickin...@gmail.com * URL : https://github.com/nodejs/readable-stream#readme * License : Expat Programming Lang: JavaScript Description : Streams3, a user-land copy of the stream library This package is a mirror of the Streams2 and Streams3 implementations in Node-core, including documentation. . If you want to guarantee a stable streams base, regardless of what version of Node you, or the users of your libraries are using, use readable-stream only and avoid the stream module in Node-core. . As of version 2.0.0 readable-stream uses semantic versioning. . Node.js is an event-based server-side JavaScript engine. Node-readable-stream is a dependency of node-concat-stream and will also be maintained in the Debian Javascript Team. signature.asc Description: OpenPGP digital signature
Bug#796367: PTS: ports link no longer needed
Package: qa.debian.org User: qa.debian@packages.debian.org Usertags: pts buildd.debian-ports.org has been merged into buildd.debian.org, so the ports link is no longer needed. -- Jakub Wilk
Bug#783659: wheezy-pu: package unrar-nonfree/1:4.1.4-1+deb7u1
Control: tags -1 + confirmed On Tue, 2015-04-28 at 22:06 +0200, Felix Geyer wrote: unrar-nonfree is affected by a symlink directory traversal vulnerability, see bug #774171. Please go ahead; apologies for the delay. Regards, Adam
Bug#75773: closed by Debian FTP Masters ftpmas...@ftp-master.debian.org (Bug#796274: Removed package(s) from unstable)
reopen 75773 reassign 75773 gcc quit On Fri, Aug 21, 2015 at 01:47:05PM +, Debian Bug Tracking System wrote: Dear submitter, as the package gcc-4.6 has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. The bug still exists in gcc. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#750010: pu: package mlmmj/1.2.18.1-1
On Sat, 2015-04-25 at 18:26 +0100, Adam D. Barratt wrote: On Sat, 2015-01-17 at 12:12 +, Adam D. Barratt wrote: On 2014-09-20 19:26, Adam D. Barratt wrote: [...] That looks like it should be okay, but I'd appreciate a debdiff of the proposed package, rebuilt (and tested :-) on a wheezy system and versioned as 1.2.18.1-1~deb7u1. Ping? Re-ping. ... and again
Bug#796338: check-all-the-things: Ctrl-C only stops current check, not check-all-the-things itself
Package: check-all-the-things Severity: normal Version: 2015.08.11.1 If I want to stop check-all-the-things and press Ctrl-C for that, it only seems to abort the current check and continues with the next. I need to permanently press Ctrl-C until it hits check-all-the-things inbetween two two checks. IMHO it should abort completely upon Ctrl-C.
Bug#796337: ITP: node-cross-spawn-async -- Cross platform child_process#spawn
Package: wnpp Severity: wishlist Owner: Ross Gammon rossgam...@mail.dk X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-cross-spawn-async Version : 2.0.0 Upstream Author : IndigoUnited he...@indigounited.com (http://indigounited.com) * URL : https://github.com/IndigoUnited/node-cross-spawn-async#readme * License : Expat Programming Lang: JavaScript Description : Cross platform child_process#spawn A cross platform solution to node's spawn. . The same module can be used on WIndows and Linux. It correctly handles PATHEXT, shebangs, del or dir and, escape arguments with spaces or special characters. . Node.js is an event-based server-side JavaScript engine. This package is a new dependency for the latest node-cross-spawn, and will be maintained alongside node-cross-spawn in the Debian Javascript Team. signature.asc Description: OpenPGP digital signature
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Package: sponsorship-requests Severity: wishlist Hi mentors, I am looking for a sponsor for my package mlucas, I have uploaded a new version of the package to fix issues pointed out by Jakub Wilk, please see previous message in the bug report to see what issues are fixed I will now elaborate more on why this package is suitable for Debian, feel free to skip it __BEGIN_ELABORATION__ Great Internet Mersenne Prime Search (GIMPS) is a collaborative project of volunteers who use freely available software to search for Mersenne prime numbers (quote from Wikipedia). The most popular client `mprime' was available in Debian Potato as the package `prime-net' as shown in this post http://www.mersenneforum.org/showthread.php?t=7181. However, it appears the maintainer had lost interest in it because it was classified as `non-free'. `mlucas' has been developed as an alternative since 1996. While it is not as efficient as `mprime', it is licensed under GPL-2+ and thus suitable to be included in `main'. It has been used in the verification of various Mersenne primes, including the 45th (found in 2008), 46th (found in 2009) and 48th (found in 2013) found Mersenne prime. Therefore, the underlying algorithm is believed to be reliable, thus suitable to be included in Debian. __END_ELABORATION__ * Package name: mlucas Version : 14.1+dfsg-1 Upstream Author : Ernst W. Mayer ewma...@aol.com * URL : http://hogranch.com/mayer/README.html * License: GPL-2+ Section : math It builds those binary packages: mlucas - program to perform Lucas-Lehmer test on a Mersenne number To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mlucas Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mlucas/mlucas_14.1+dfsg-1.dsc Changes since the last upload: mlucas (14.1+dfsg-1) UNRELEASED; urgency=low * Initial release (Closes: #786656) -- Alex Vong alexvong1...@gmail.com Sun, 02 Aug 2015 03:13:37 +0800 Cheers, Alex
Bug#796341: please add Homepage and VCS Headers to debian/control
Package: radvd Version: 1:2.11-1 Severity: wishlist Hi, please list the radvd upstream homepage http://www.litech.org/radvd/ in debian/control. If you maintain radvd in a publicly available VCS, please document its URLs in debian/control as well. Greetings Marc -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.5-zgws1 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages radvd depends on: ii adduser 3.113+nmu3 ii libc62.19-18 radvd recommends no packages. radvd suggests no packages. -- no debconf information
Bug#792631: python-librtmp: diff for NMU version 0.2.2-1.1
Hello, no, please continue with the upload. Thank you all for debugging and patching the issue. I missed the original mails because they were marked as spam. I'll look into improving that, so that I am more responsive in the future. Stefan
Bug#796347: May be a ofono issue
After some further testing I discovered that after restarting the ofono service, my cell connection reappears in connman. This leads me to believe the issue may originate from ofono.
Bug#787193: xen-utils-common: xen-init-list crashes with TypeError, renders reboots unfeasible after upgrade from wheezy to jessie
This bug was already reported as #763102 and was brushed off because maintainer says it implicates xend which is not there in 4.4 anymore. Quoting the explanation sent when closing #763102: If you think a bug has been associated with xend in error please check if it still reproduces with the packages in Jessie (currently 4.4.1-3) and reopen. I'm sorry you felt this was being brushed off but it explicitly acknowledge the possibility of mistakes and explained what to do in such cases. Ian.
Bug#796343: Fixed in llvm-3.7+
Hi Daniel, Jakub, as said in the python-afl RFS bug, arm64 has some (many) problems with older llvm such as the currently Debian default one. I tried to reproduce this (really nice) bug report, and I succeeded with llvm-3.4, 3.5 and 3.6. fortunately 3.7+ seems to be working, so I ask you: how do you feel about temporarily forcing clang-3.7 (I would avoid 3.8 since it is only in unstable) as build-dependency for arm64? cheers, G.
Bug#796350: RFA: python-scriptutil -- Python module which provides the functionality of find and grep
Package: wnpp Severity: normal retitle 660444 ITA: python-scriptutil -- Python module which provides the functionality of find and grep I request an adopter for the python-scriptutil package. The package description is: This package contains a python module which provides a recursive find on the filesystem and searching within those files.
Bug#796354: libimage-info-perl: FTBFS: Failed 1/13 test programs. 1/134 subtests failed.
Source: libimage-info-perl
Version: 1.28-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Dear Maintainer,
libimage-info-perl fails to build from source in testing/amd64:
[..]
# Failed test '../img/test.svg'
# at t/string.t line 68.
# Structures begin differing at:
# $got-{Warn} = 'Warning: XML::LibXML compiled against
libxml2 20902, but runtime libxml2 is older 20901
# '
# $expected-{Warn} = Does not exist
# Looks like you failed 1 test of 22.
t/string.t .
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/22 subtests
t/svg.t ok
t/tiff.t ... ok
t/tiff_e.t . ok
t/tiny-pgm.t ... ok
Test Summary Report
---
t/string.t (Wstat: 256 Tests: 22 Failed: 1)
Failed test: 16
Non-zero exit status: 1
Files=13, Tests=134, 1 wallclock secs ( 0.05 usr 0.00 sys + 0.38
cusr 0.04 csys = 0.47 CPU)
Result: FAIL
Failed 1/13 test programs. 1/134 subtests failed.
Makefile:797: recipe for target 'test_dynamic' failed
make[1]: *** [test_dynamic] Error 255
make[1]: Leaving directory
'/home/lamby/temp/cdt.20150821143313.UcCLpsTkSX/libimage-info-perl-1.28'
debian/rules:29: recipe for target 'build-stamp' failed
make: *** [build-stamp] Error 2
[..]
The full build log is attached.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
dpkg-buildpackage -rfakeroot -D -us -uc -b
dpkg-buildpackage: source package libimage-info-perl
dpkg-buildpackage: source version 1.28-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Don Armstrong d...@debian.org
dpkg-source --before-build libimage-info-perl-1.28
dpkg-buildpackage: host architecture amd64
fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f *-stamp
if [ -e Makefile ]; then \
/usr/bin/make distclean;\
fi
dh_clean
dh_clean: Compatibility levels before 5 are deprecated (level 4 in use)
debian/rules build
dh_testdir
/usr/bin/perl Makefile.PL INSTALLDIRS=vendor
Cannot determine perl version info from lib/Image/Info.pm
Cannot determine license info from lib/Image/Info.pm
*** Module::AutoInstall version 1.03
*** Checking for Perl dependencies...
[Core Features]
- Test::More ...loaded. (1.001002 = 0.62)
*** Module::AutoInstall configuration finished.
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Image::Info
Writing MYMETA.yml and MYMETA.json
/usr/bin/make
make[1]: Entering directory
'/home/lamby/temp/cdt.20150821143313.UcCLpsTkSX/libimage-info-perl-1.28'
cp lib/Image/Info/XBM.pm blib/lib/Image/Info/XBM.pm
cp lib/Image/Info/GIF.pm blib/lib/Image/Info/GIF.pm
cp lib/Image/Info/JPEG.pm blib/lib/Image/Info/JPEG.pm
cp lib/Image/Info/PNG.pm blib/lib/Image/Info/PNG.pm
cp lib/Image/Info/BMP.pm blib/lib/Image/Info/BMP.pm
cp lib/Image/Info/PPM.pm blib/lib/Image/Info/PPM.pm
cp lib/Image/Info/TIFF.pm blib/lib/Image/Info/TIFF.pm
cp lib/Image/TIFF.pm blib/lib/Image/TIFF.pm
cp lib/Image/Info/XPM.pm blib/lib/Image/Info/XPM.pm
cp lib/Image/Info/SVG.pm blib/lib/Image/Info/SVG.pm
cp lib/Image/Info.pm blib/lib/Image/Info.pm
Manifying blib/man3/Image::Info.3pm
Manifying blib/man3/Image::Info::BMP.3pm
Manifying blib/man3/Image::Info::PPM.3pm
Manifying blib/man3/Image::Info::SVG.3pm
Manifying blib/man3/Image::Info::TIFF.3pm
Manifying blib/man3/Image::Info::XBM.3pm
Manifying blib/man3/Image::Info::XPM.3pm
make[1]: Leaving directory
'/home/lamby/temp/cdt.20150821143313.UcCLpsTkSX/libimage-info-perl-1.28'
/usr/bin/make test
make[1]: Entering directory
'/home/lamby/temp/cdt.20150821143313.UcCLpsTkSX/libimage-info-perl-1.28'
PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -MTest::Harness
-e undef *Test::Harness::Switches; test_harness(0, 'inc', 'blib/lib',
'blib/arch') t/00_basics.t t/bmp.t t/dim.t t/exif.t t/jpg_hang.t t/png.t
t/pod.t t/pod_cov.t t/string.t t/svg.t t/tiff.t t/tiff_e.t t/tiny-pgm.t
t/00_basics.t .. ok
t/bmp.t ok
t/dim.t ok
t/exif.t ... ok
# Ignoring unknown type code 0
# Ignoring unknown type code 20
t/jpg_hang.t ... ok
t/png.t ok
t/pod.t ok
t/pod_cov.t ok
# Failed test '../img/test.svg'
# at t/string.t line 68.
# Structures begin differing at:
# $got-{Warn} = 'Warning: XML::LibXML compiled against libxml2 20902,
but runtime libxml2 is older 20901
# '
# $expected-{Warn} = Does not exist
# Looks like you failed 1 test of 22.
t/string.t .
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/22 subtests
t/svg.t ok
t/tiff.t ... ok
t/tiff_e.t . ok
t/tiny-pgm.t ... ok
Test Summary Report
---
t/string.t (Wstat: 256 Tests: 22 Failed: 1)
Failed test: 16
Non-zero exit status: 1
Files=13, Tests=134, 1 wallclock secs ( 0.05 usr 0.00
Bug#770232: #770232
Hi,
it is not enough to remove the xpi only from the code to fulfill the
requirements for main. We have also to remove the xpi from the source
before we do the import.
After the patch you can't use it without any updates and the main
functionality will not work.
If you try the example from the homepage[1]:
from selenium import webdriver
browser = webdriver.Firefox()
browser.get('http://seleniumhq.org/')
You got the error below:
IOError: [Errno 2] No such file or directory:
'/usr/lib/python2.7/dist-packages/selenium/webdriver/firefox/webdriver.xpi'
I think that is not the expected functionality of the python-selenium
package for someone who installed this package. It's possible to install
the chromedriver and use the python-selenium stuff with chromium. Imho
it will be the best to split the package into a 'free' and a 'non-free'
package and do it in a same way like the chromedriver. We don't should
remove the xpi without providing a alternative package because there are
several users who will use it with firefox.
I will do the updates and try to package the xpi.
Regards
Sascha
[1] https://pypi.python.org/pypi/selenium
signature.asc
Description: OpenPGP digital signature
Bug#796358: networkd segfaults as DHCP client
Hi Am 21.08.2015 um 15:59 schrieb Marc Haber: I have systemd-networkd segfault when it works as a DHCP client for IPv4 on a banana pi. Googling has led me to https://bugs.archlinux.org/task/45855 and to https://github.com/systemd/systemd/issues/827, which contains a patch which was merged by upstream into mainline systemd. Have you verified that this patch works for you? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#740753: packaging cli
Hello, I intend to help with this. I have already started with github.com/mitchellh/cli. See you guys on #debian-golang -- Alexandre Viau alexan...@alexandreviau.net
Bug#796365: ITP: node-util-deprecate -- The Node.js `util.deprecate()` function with browser support
Package: wnpp Severity: wishlist Owner: Ross Gammon rossgam...@mail.dk X-Debbugs-CC: debian-de...@lists.debian.org X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org * Package name: node-util-deprecate Version : 1.0.1 Upstream Author : Nathan Rajlich nat...@tootallnate.net (http://n8.io/) * URL : https://github.com/TooTallNate/util-deprecate * License : Expat Programming Lang: JavaScript Description : The Node.js `util.deprecate()` function with browser support In Node.js, this module simply re-exports the util.deprecate() function. . In the web browser (i.e. via browserify), a browser-specific implementation of the util.deprecate() function is used. . Node.js is an event-based server-side JavaScript engine. Node-util-deprecate is a dependency of readable-stream which I also intend to maintain within the Debian Javasript Team. signature.asc Description: OpenPGP digital signature
Bug#796366: dh-strip-nondeterminism: missing dependency on libtimedate-perl
Package: dh-strip-nondeterminism Version: 0.009-1 Severity: important Dear Maintainer, dh_strip_nondeterminism uses Date/Parse.pm. Currently, one needs to manually install libtimedate-perl to make it work. Cheers, -- Stéphane -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#796362: ITP: node-process-nextick-args -- process.nextTick but always with args
Package: wnpp Severity: wishlist Owner: Ross Gammon rossgam...@mail.dk X-Debbugs-CC: debian-de...@lists.debian.org X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org * Package name: node-process-nextick-args Version : 1.0.2 Upstream Author : Calvin Metcalf * URL : https://github.com/calvinmetcalf/process-nextick-args * License : Expat Programming Lang: JavaScript Description : process.nextTick but always with args With node-process-nextick-args you will always be able to pass arguments to process.nextTick, no matter which platform you use. . Node.js is an event-based server-side JavaScript engine. Node-process-nextick-args is a dependency of readable-stream which I also intend to maintain within the Debian Javascript Team. signature.asc Description: OpenPGP digital signature
Bug#796360: libical: please make the build reproducible
Source: libical
Version: 1.0.1-0.1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi,
While working on the reproducible builds effort [1], we have noticed
that libical could not be built reproducibly.
The attached patch removes randomess caused Perl hash order, resulting
in the generated icalderivedvalue.c file. Once applied, libical can
be
built reproducibly in our reproducible toolchain.
[1]: https://wiki.debian.org/ReproducibleBuilds
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/0001-reproducible-build.patch 1970-01-01
01:00:00.0 +0100
--- b/debian/patches/0001-reproducible-build.patch 2015-08-21
15:15:04.106535730 +0100
@@ -0,0 +1,11 @@
+--- libical-1.0.1.orig/scripts/mkderivedvalues.pl
libical-1.0.1/scripts/mkderivedvalues.pl
+@@ -141,7 +141,7 @@ if($opt_c){
+ my $count = scalar(keys %h) + 1;
+ print static const struct icalvalue_kind_map value_map[$count]={\n;
+
+- foreach $value (keys %h) {
++ foreach $value (sort keys %h) {
+
+ next if $value eq 'NO' or $value eq 'ANY';
+
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2015-08-21 15:15:01.242512715 +0100
@@ -0,0 +1 @@
+0001-reproducible-build.patch
Bug#796361: python-lzma: FTBFS when building with DEB_BUILD_OPTIONS 'nocheck nobench'
Package: python-lzma Version: 0.5.3-3 Severity: normal Hello! python-lzma fails to build from source when disabling the test suite by setting the appropriate DEB_BUILD_OPTIONS flags 'nocheck nobench': debian/rules override_dh_auto_test make[1]: Entering directory '/«PKGBUILDDIR»' make[1]: *** No rule to make target 'test2.7', needed by 'override_dh_auto_test'. Stop. make[1]: Leaving directory '/«PKGBUILDDIR»' make: *** [build-arch] Error 2 debian/rules:42: recipe for target 'build-arch' failed dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 While disabling the testsuite is normally not advised, it is often desirable when doing a quick test build, especially when building the package on slower machines like the m68k or sh4 buildds. Could you please drop the dependency of the override_dh_auto_test target on the target test2.7 such that python-lzma builds fine even when tests are disabled? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#745113: I'm Working this bug
Hi, I’m new matter this package. Your Bug next fix in new uploaded package Thanks a lot Júnior Santos ITIL® Foundation Certificate in IT Service Management Registration number 4365854.1019776 E-mail: j.s.jun...@live.com signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#789214: jessie-pu: package cloud-init/0.7.6~bzr976-2 - -3
On 08/19/2015 04:01 AM, Charles Plessy wrote: Hi Julien and Thomas, in May, Mehdi Abaakouk wrote in #784083: After further investigation, the whole cloud-init dependencies chains is completely broken with systemd. [...] This issue is more critical, that I have thought initially, because with systemd, the cloud-init behavior is completely unpredictable... Also, the current packaged debian version source contains the systemd unit files, but the binary package doesn't install them. Then Thomas added the unit files, which fixed the problem. Then in July, Mehdi Abaakouk confirmed this #784083: Note, that I have tested on jessie, the packages that zigo have uploaded in sid (0.7.6~bzr976-4) and it works as expected. Can we go ahead with the proposed stable update ? Have a nice day, Charles Charles, Julien, Julien told me he will review this issue again next week, so let's wait that. After it's done, the team behind Azure images urgently needs an update to the latest version of cloud-init in Sid. Julien, is it ok if we upgrade Sid to the latest upstream, or will it affect the upload to Stable? Cheers, Thomas Goirand (zigo)
Bug#704214: little update -- Git repo is available with initial packaging
retitle 704214 ITP: numbers -- database of interesting numbers and a tool to compare against it owner 704214 ! thanks http://anonscm.debian.org/cgit/collab-maint/numbers.git/ -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Bug#796347: connman: After disconnecting cellular service, service is removed and can't reconnect
Package: connman
Version: 1.21-1.2
Severity: normal
Dear Maintainer,
* What led up to the situation?
I'd like to use a MultiTech rCell 100 USB modem to connect to the
internet. This modem is based on a Telit HE910 chipset.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Initially, I got nowhere. Connman was completely unable to use the
modem to connect to the Internet.Then I ran the command
echo tun /etc/modules-load.d/tun.conf
After this, the modem connects to the internet right after boot.
However, after I disconnect connman using econnman, the service is
not just disconnected, but removed from the services list.
* What was the outcome of this action?
The cellular technology is still available, but I can't reconnect.
* What outcome did you expect instead?
The service from my cellular ISP should be in the services list,
letting me reconnect to it.
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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 connman depends on:
ii dbus 1.8.18-0+deb8u1
ii init-system-helpers 1.22
ii libc62.19-18
ii libdbus-1-3 1.8.18-0+deb8u1
ii libglib2.0-0 2.42.1-1
ii libgnutls-deb0-283.3.8-6+deb8u2
ii libreadline6 6.3-8+b3
ii libxtables10 1.4.21-2+b1
ii lsb-base 4.1+Debian13+nmu1
Versions of packages connman recommends:
ii bluez 5.23-2+b1
ii ofono 1.15-3
ii wpasupplicant 2.3-1+deb8u1
Versions of packages connman suggests:
pn indicator-network none
-- Configuration Files:
/etc/init/connman.conf changed:
description Connection Manager
start on started dbus
stop on stopping dbus
expect fork
respawn
exec connmand --nobacktrace -d
-- no debconf information
-- output of `grep -E '(connman|ofono)' /var/log/syslog`
Aug 21 14:27:03 inname-test ofonod[416]: oFono version 1.15
Aug 21 14:27:03 inname-test connman-vpnd[411]: Connection Manager VPN daemon
version 1.21
Aug 21 14:27:03 inname-test connmand[409]: Connection Manager version 1.21
Aug 21 14:27:03 inname-test connman-vpnd[411]: lo {newlink} index 1 operstate 0
UNKNOWN
Aug 21 14:27:03 inname-test connman-vpnd[411]: eth0 {create} index 2 type 1
ETHER
Aug 21 14:27:03 inname-test connman-vpnd[411]: eth0 {update} flags 4098 DOWN
Aug 21 14:27:03 inname-test connman-vpnd[411]: eth0 {newlink} index 2 address
00:1C:42:01:24:58 mtu 1500
Aug 21 14:27:03 inname-test connman-vpnd[411]: eth0 {newlink} index 2 operstate
2 DOWN
Aug 21 14:27:03 inname-test connmand[409]: Checking loopback interface settings
Aug 21 14:27:03 inname-test connmand[409]: System hostname is inname-test
Aug 21 14:27:03 inname-test connmand[409]: lo {newlink} index 1 operstate 0
UNKNOWN
Aug 21 14:27:03 inname-test connmand[409]: eth0 {create} index 2 type 1 ETHER
Aug 21 14:27:03 inname-test connmand[409]: eth0 {update} flags 4098 DOWN
Aug 21 14:27:03 inname-test connmand[409]: eth0 {newlink} index 2 address
00:1C:42:01:24:58 mtu 1500
Aug 21 14:27:03 inname-test connmand[409]: eth0 {newlink} index 2 operstate 2
DOWN
Aug 21 14:27:03 inname-test connman-vpnd[411]: eth0 {update} flags 102467
UP,RUNNING,LOWER_UP
Aug 21 14:27:03 inname-test connman-vpnd[411]: eth0 {newlink} index 2 address
00:1C:42:01:24:58 mtu 1500
Aug 21 14:27:03 inname-test connman-vpnd[411]: eth0 {newlink} index 2 operstate
6 UP
Aug 21 14:27:03 inname-test connmand[409]: Adding interface eth0 [ ethernet ]
Aug 21 14:27:03 inname-test connmand[409]: eth0 {RX} 1 packets 451 bytes
Aug 21 14:27:03 inname-test connmand[409]: eth0 {TX} 0 packets 0 bytes
Aug 21 14:27:03 inname-test connmand[409]: eth0 {update} flags 102467
UP,RUNNING,LOWER_UP
Aug 21 14:27:03 inname-test connmand[409]: eth0 {newlink} index 2 address
00:1C:42:01:24:58 mtu 1500
Aug 21 14:27:03 inname-test connmand[409]: eth0 {newlink} index 2 operstate 6
UP
Aug 21 14:27:03 inname-test connmand[409]: Skipping disconnect of carrier,
network is connecting.
Aug 21 14:27:03 inname-test connmand[409]: Setting domainname to localdomain
Aug 21 14:27:03 inname-test connmand[409]: eth0 {add} route fe80:: gw :: scope
0 UNIVERSE
Aug 21 14:27:03 inname-test connmand[409]: Method ListAdapters with signature
on interface org.bluez.Manager doesn't exist
Aug 21 14:27:03 inname-test connmand[409]: eth0 {add} address 10.211.55.7/24
label eth0 family 2
Aug 21 14:27:03 inname-test connmand[409]: eth0 {add} route 10.211.55.0 gw
0.0.0.0 scope 253 LINK
Aug 21 14:27:03 inname-test connmand[409]: eth0 {add} route 10.211.55.1 gw
0.0.0.0 scope 253 LINK
Aug 21 14:27:03 inname-test connmand[409]: eth0 {add} route 0.0.0.0 gw
Bug#749531: Still not compiling with vtk6
Just for the record. I still fail to compile this package with vtk6. VTK6.1 shows the previous Qt5 linker resolution issue. VTK6.1 fails due to some MOC incompatibility, ala: /home/mih/debian/fsl/fslview/obj-x86_64-linux-gnu/src/fslview/moc_application.cxx:15:2: error: #error This file was generated using the moc from 5.4.2. It #error This file was generated using the moc from 5.4.2. It ^ /home/mih/debian/fsl/fslview/obj-x86_64-linux-gnu/src/fslview/moc_application.cxx:16:2: error: #error cannot be used with the include files from this version of Qt. #error cannot be used with the include files from this version of Qt. ^ /home/mih/debian/fsl/fslview/obj-x86_64-linux-gnu/src/fslview/moc_application.cxx:17:2: error: #error (The moc has changed too much.) #error (The moc has changed too much.) ^ /home/mih/debian/fsl/fslview/obj-x86_64-linux-gnu/src/fslview/moc_application.cxx:22:5: error: ‘QByteArrayData’ does not name a type QByteArrayData data[37]; Michael -- Michael Hanke http://mih.voxindeserto.de
Bug#733489: Remaining patches for bug #733489
Fair points. I'll update the commit and ping you once it is ready for review.
Bug#796343: clang-3.5: [arm64] segfault in 'Greedy Register Allocator'
* Gianfranco Costamagna costamagnagianfra...@yahoo.it, 2015-08-21, 13:22: how do you feel about temporarily forcing clang-3.7 It's not as easy as compiling the code with clang-3.7. You would also have to patch afl-clang-fast to execute the right compiler, and get Depends right. I don't think it's worth the effort. I'd rather wait until 3.7 is the default; and in the mean time remove afl arm64 binaries from the archive. But of course, it's up to Daniel. -- Jakub Wilk
Bug#791878: ITP: sauvegarde -- Saves files live while beeing created or modified in a deduplicated manner.
New version v0.0.3 is now out and can be found at http://src.delhomme.org/download/sauvegarde/releases/sauvegarde-0.0.3.tar.xz Source code is at https://github.com/dupgit/sauvegarde It is licensed with GPL v3 and has the following dependencies : . autotools (2.59) . glib and gio (2.26) . libmicrohttpd (0.9.5) . libcurl (7.22.0) . sqlite (3.6.20) . jansson (2.5) Building process is using autotools and a configure script. I managed to compile nicely under debian jessie on x86_64 and 32 bits arm7l architectures. I'd love to go through the process for an inclusion of sauvegarde project into debian testing. Thanks for your time, Olivier Delhomme.
Bug#796357: ITP: golang-github-mitchellh-cli -- library for implementing command-line interfaces
Package: wnpp Severity: wishlist Owner: Alexandre Viau alexan...@alexandreviau.net * Package name: golang-github-mitchellh-cli Version : 0.0~git20150618.0.8102d0e-1 Upstream Author : Mitchell Hashimoto mitchell.hashim...@gmail.com * URL : https://github.com/mitchellh/cli * License : MPL-2.0 Programming Lang: Go Description : library for implementing command-line interfaces -- Alexandre Viau alexan...@alexandreviau.net
Bug#796359: ITP: node-typedarray -- TypedArray polyfill for old browsers
Package: wnpp Severity: wishlist Owner: Ross Gammon rossgam...@mail.dk X-Debbugs-CC: debian-de...@lists.debian.org X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org * Package name: node-typedarray Version : 0.0.6 Upstream Author : James Halliday m...@substack.net (http://substack.net) * URL : https://github.com/substack/typedarray * License : Expat Programming Lang: JavaScript Description : TypedArray polyfill for old browsers Node-typedarray is a fork of the inexorabletash version of polyfill. . Node.js is an event-based server-side JavaScript engine. Node-typedarray is a dependency of node-concat-stream which I also intend to maintain within the Debian Javascript Team. signature.asc Description: OpenPGP digital signature
Bug#796358: networkd segfaults as DHCP client
On Fri, Aug 21, 2015 at 04:07:56PM +0200, Michael Biebl wrote: Am 21.08.2015 um 15:59 schrieb Marc Haber: I have systemd-networkd segfault when it works as a DHCP client for IPv4 on a banana pi. Googling has led me to https://bugs.archlinux.org/task/45855 and to https://github.com/systemd/systemd/issues/827, which contains a patch which was merged by upstream into mainline systemd. Have you verified that this patch works for you? No. I am not going to compile systemd. I have verified that the workaround UseHostname=no works for me. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#505092: unkillable rred process
On Thu, Nov 10, 2011 at 03:01:22PM -0600, Troy Benjegerdes wrote: I am also observing an unkillable rred proces.. root 27794 0.0 0.0 12472 556 ?Ss 12:13 0:00 /usr/sbin/anacron -s root 28322 0.0 0.0 4148 260 ?S12:18 0:00 \_ /bin/sh -c nice run-parts --report /etc/cron.daily root 28323 0.0 0.0 4044 248 ?SN 12:18 0:00 \_ run-parts --report /etc/cron.daily root 28327 0.0 0.0 4148 356 ?SN 12:18 0:00 \_ /bin/sh /etc/cron.daily/apt root 28415 0.0 0.0 23736 1460 ?SN 12:21 0:02 \_ apt-get -qq -y update root 28419 0.0 0.0 31220 860 ?SN 12:21 0:00 \_ /usr/lib/apt/methods/http root 28420 0.0 0.0 31220 840 ?SN 12:21 0:00 \_ /usr/lib/apt/methods/http root 28421 0.0 0.0 31220 764 ?SN 12:21 0:00 \_ /usr/lib/apt/methods/http root 28423 0.0 0.0 22828 664 ?SN 12:21 0:00 \_ /usr/lib/apt/methods/gpgv root 28429 0.0 0.0 22812 708 ?SN 12:21 0:00 \_ /usr/lib/apt/methods/bzip2 root 28436 98.8 0.0 44764 592 ?RN 12:21 155:33 \_ /usr/lib/apt/methods/rred There were lots of rewrites in that code, so I'm closing this bug now. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 Netiquette. - If you don't I might ignore you.
Bug#795610: Re : Re: Re : Re: Bug#795610: Linux kernel backport 4.1 breaks NVidia drivers
No problem with that. It's true that it is a bit long but I prefer that and having a rock solid damn stable OS than a cutting edge unstable one. Envoyé depuis Yahoo Mail pour Android De:Luca Boccassi luca.bocca...@gmail.com Date:Ven j Aoû PM à 12:08 Objet:Re: Re : Re: Bug#795610: Linux kernel backport 4.1 breaks NVidia drivers On 21 August 2015 at 10:56, Julien Aubin julien_aubin...@yahoo.fr wrote: Hi Any news towards this issue ? Looks like a blocker for anyone using desktop Debian are they're the most likely to use backports. Of course it is still possible to downgrade the kernel but annoying when you need to perform updates again. Hi Julien, Please be patient, Vincent uploaded the packages with the fixes to the backports queue, but now they need approval from the FTP overlords. It might take from a few hours to a few days, but eventually they'll be available in jessie-backports. You can follow the progress here: https://ftp-master.debian.org/backports-new.html Kind regards, Luca Boccassi
Bug#794977: Progress
This bug now hits dselect in Testing. Is there an ETA for the updated/fixed version? Since this bug makes dselect unusuable, I think a severity upgrade is in order. Mark
Bug#796181: mirror submission for mirror.coupofy.com
Control: tag -1 +moreinfo Hi, Thank you for your support and for mirroring Debian. Your submission indicates that the mirror will carry amd64 and i386, however the actual mirror is serving: amd64, i386, arm64, and ppc64. Please advise if you will continue in carrying the 4 archives. The mirror is also not displaying the README.html file in the top level directory. Please check your configuration advise of how you would like to proceed. Best regards, Donald Norwood On Thu, 20 Aug 2015 01:52:23 + Janez mirr...@coupofy.com wrote: Package: mirrors Severity: wishlist Submission-Type: new Site: mirror.coupofy.com Type: leaf Archive-architecture: amd64 i386 Archive-http: /debian/ IPv6: no Archive-upstream: mirrors.liquidweb.com Updates: once Maintainer: Janez mirr...@coupofy.com Country: DE Germany Sponsor: Coupofy http://www.coupofy.com/ signature.asc Description: OpenPGP digital signature
Bug#779670: wheezy-pu: package maven2-core/2.2.1-8+deb7u1
On Fri, 2015-03-06 at 18:51 +, Adam D. Barratt wrote: Control: tags -1 + confirmed On Tue, 2015-03-03 at 22:02 +0100, Emmanuel Bourg wrote: Please accept maven2-core/2.2.1-8+deb7u1 in stable-updates to backport the security fix recently applied to Maven 2 in testing/unstable. Please go ahead. Ping? Regards, Adam
Bug#776617: wheezy-pu: fso stack
On Sat, 2015-04-25 at 17:15 +0100, Adam D. Barratt wrote: Control: tags -1 + confirmed Apologies for managing to overlook this when you filed it. On Fri, 2015-01-30 at 01:43 +0100, Sebastian Reichel wrote: I just requested unblocking of the fso stack for unstable - testing migration. I also prepared fixed packages for wheezy and the security team send me here. This is the debdiff for the proposed stable updates: === debdiff fso-datad_0.11.0-1.dsc fso-datad_0.11.0-1+deb7u1.dsc === diff -Nru fso-datad-0.11.0/debian/changelog fso-datad-0.11.0/debian/changelog --- fso-datad-0.11.0/debian/changelog 2012-05-26 10:29:47.0 +0200 +++ fso-datad-0.11.0/debian/changelog 2015-01-28 00:18:22.0 +0100 @@ -1,3 +1,9 @@ +fso-datad (0.11.0-1+deb7u1) wheezy-security; urgency=high + + * Fix DBus permissions (Closes: CVE-2014-8156) With s/-security//g in each of the new changelog stanzas, please go ahead; thanks. Ping? Regards, Adam
Bug#796351: ITP: node-concat-stream -- writable stream that concatenates
Package: wnpp Severity: wishlist Owner: Ross Gammon rossgam...@mail.dk X-Debbugs-CC: debian-de...@lists.debian.org X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org * Package name: node-concat-stream Version : 1.5.0 Upstream Author : Max Ogden m...@maxogden.com * URL : https://github.com/maxogden/concat-stream#readme * License : Expat Programming Lang: JavaScript Description : writable stream that concatenates strings Node-concat-stream creates a writable stream that concatenates strings or binary data and calls a callback with the resultor binary data and calls a callback with the result. . Node.js is an event-based server-side JavaScript engine. Node-concat-stream is a dependency of node-spawn-sync which I also intend to maintain within the Debian Javascript Team. signature.asc Description: OpenPGP digital signature
Bug#786650: virt-aa-helper: incomplete apparmor profile
Hi, On Fri, Aug 21, 2015 at 11:12:33AM +0200, intrigeri wrote: Hi, Guido Günther wrote (21 Aug 2015 08:37:53 GMT) : On Fri, Aug 21, 2015 at 09:08:46AM +0200, intrigeri wrote: Felix Geyer wrote (20 Aug 2015 09:18:59 GMT) : The deny rules aren't strictly necessary but they silence those (harmless) denials. Thanks for the clarification. I don't think that silencing harmless denials qualifies for a stable pu. Great. Can one of you add this to #796088 - I did but it might make sense if somebody with more apparmor skills does. The path I would prefer is: submit an updated debdiff that does not contain these bonus deny rules. I could prepare it if we agree on that, assuming the current state of this stable pu is in Vcs-Git. But if someone else disagrees and prefers to argue in favour of including these changes in the stable pu, feel free to do so :) I'm fine with this as well. The debian/jessie branch on alioth is up to date. Cheers, -- Guido
Bug#796352: please warn about a missing dependency on the gfortran module version
Package: lintian When the gfortran module version changes, at least all the library packages providing a fortran 90 module need a rebuild. Currently people have to scan the archive them self to identify all the packages which need a rebuild. Please warn about about -dev packages shipping a fortran module in a -dev package without having a dependency on gfortran-mod-n, where n is the number of the module version (e.g. gfortran-mod-14 for modules built using GCC 5). The .mod file still can be located in /usr/include or /usr/lib. [1] has some information how to identify a .mod file and extract the version number. Debian bug #714730 has the discussion about how to standardize the location. Thanks, Matthias [1] http://anonscm.debian.org/cgit/debian-science/packages/dh-fortran-mod.git/tree/dh_fortran_mod
Bug#784915: jessie-pu: package rsnapshot/1.3.1-4
On Sun, 2015-05-10 at 17:23 +0100, Adam D. Barratt wrote: Control: tags -1 + moreinfo On Sun, 2015-05-10 at 17:52 +0200, Guillaume Delacour wrote: I've introduced [1] in rsnapshot version 1.3.1-4 a problem which affects multiple user: when defining custom ssh_args they're not properly interpreted (erroneously quoted). [...] [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717451 The metadata for that bug indicates that it also affects the version of rsnapshot in unstable. If that's correct, please fix the bug in unstable; if not, please fix the metadata. The package in unstable and testing appears to have been fixed now. In either case, when it comes to an update in stable we'll need a source debdiff of the proposed updated package, built and tested in a Jessie environment, rather than pointers to online patches. This is still true, however. Regards, Adam
Bug#792447: RFS: python-afl/0.2.1-1 -- American Fuzzy Lop fuzzy testing for Python code [ITP]
Control: tags -1 moreinfo Hi Daniel, I do not remember how we left this one, anyway: now with the llvm stuff being fixed/rebuilt, I asked for a give back of afl, and it is actually building almost everywhere (just arm64 needs investigation, and s390x/kfreebsd-amd64 needs an llvm-toolchain-3.6 rebuild, ongoing right now) How do you feel about updating afl, checking if everything is good and then followup with python-afl? cheers, Gianfranco Il Lunedì 10 Agosto 2015 11:36, Daniel Stender deb...@danielstender.com ha scritto: On 10.08.2015 11:04, Gianfranco Costamagna wrote: I did a look, and the packaging looks really good (and the upstream maintainer too :) ). However prior to sponsor I would like to see afl working, otherwise it would be not installable on sid. (I'll try to work on llvm side in the next few days) Little (I guess not trivial to fix) nitpick: you might avoid pthread link dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/python-afl/usr/lib/python2.7/dist-packages/afl.x86_64-linux-gnu.so was not linked against libpthread.so.0 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/python3-afl/usr/lib/python3/dist-packages/afl.cpython-34m-x86_64-linux-gnu.so was not linked against libpthread.so.0 (it uses none of the library's symbols) But I really do not think this is trivial to solve (more a cython problem than a python-afl one IIRC) cheers, Gianfranco Very much welcome! :-) Deal, when you've successfully fuzzed with it we go on with the sponsoring, I'll get into that link issue in the meanwhile. Best, Daniel -- http://www.danielstender.com/blog/ 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
Bug#796339: ITP: node-spawn-sync -- Prollyfill for child_process.spawnSync
Package: wnpp Severity: wishlist Owner: Ross Gammon rossgam...@mail.dk X-Debbugs-CC: debian-de...@lists.debian.org X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org * Package name: node-spawn-sync Version : 1.0.13 Upstream Author : ForbesLindesay * URL : https://github.com/ForbesLindesay/spawn-sync * License : Expat Programming Lang: JavaScript Description : Prollyfill for child_process.spawnSync On iojs and node = 0.12 it will just export the built in child_process.spawnSync. On platforms that support compiling native modules it uses the thread-sleep module to wait for an output file to exist in a tight loop. In this way it gains excellent cross platform support, but don't expect it to be efficient on all platforms. . Node.js is an event-based server-side JavaScript engine. This package is a new dependency for node-cross-spawn, and will be maintained within the Debian Javascript Team. signature.asc Description: OpenPGP digital signature
Bug#795207: samizdat: FTBFS: NameError: uninitialized constant Psych::ENGINE
owner 795207 ! reassign 795207 ruby-whitewash retitle 795207 ruby-whitewash: Broken when used with ruby2.2 due to YAML/Psych changes severity 795207 important affects 795207 src:samizdat thanks On Tue, Aug 11, 2015 at 07:56:17PM +0100, Chris West (Faux) wrote: Source: samizdat Version: 0.7.0-1 Severity: serious Justification: fails to build from source Tags: sid stretch User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. Faith means not wanting to know what is true. -- Nietzsche
