Bug#910327: Fwd: Bug#910327: RFS: javapoet/1.11.1-1 [ITP]
On Fri, Oct 5, 2018 at 5:43 AM tony mancill wrote: > > Hello Miroslav, > > Thank you for packaging javapoet. I was looking at doing this as a > dependency for some of the OpenHFT libraries. > > One minor change I think we need to make to debian/copyright is to > explicitly list the files that have Google and not Square as the > copyright holder, but otherwise the package looks good. > > Just as you suggest below, I will push the packaging into a repo on > salsa.debian.org (so the same as with picocli) and bring the package > under Debian Java Maintainers with you as an Uploader. > > Cheers, > tony > > On Thu, Oct 04, 2018 at 10:25:04PM +0200, Miroslav Kravec wrote: > > Dear package maintainers, > > > > I'm looking for a sponsor for javapoet (see details of forwarded message). > > > > The package can be moved under Debian Java Maintainers, as was done for: > > > > * https://tracker.debian.org/pkg/picocli , > > * https://tracker.debian.org/pkg/gradle-apt-plugin . > > > > Or, you can leave me as maintainer, if you wouldn't like to move it > > under Debian Java Maintainers. > > > > Kind regards, > > Miroslav Kravec > > > > -- Forwarded message - > > From: Miroslav Kravec > > Date: Thu, Oct 4, 2018 at 10:09 PM > > Subject: Bug#910327: RFS: javapoet/1.11.1-1 [ITP] Hello Tony, thank you for review of packaging work. I'm glad you're interested in getting this package to Debian. I'll fix debian/copyright, and upload new version to mentors. Kind regards, Miroslav Kravec
Bug#910346: kraptor FTCBFS: uses the build architecture compiler
Source: kraptor Version: 0.0.20040403+ds-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap kraptor fails to cross build from source, because it uses the build architecture compiler. The packaging uses dh_auto_build, which passes a cross compiler via CC, but the upstream Makefile expects the compiler in GCC. Thus it keeps using the default value. The attached also sets GCC to make kraptor cross build. Alternatively, you could ask upstream to change the variable name from "GCC" to the way more common "CC". That felt a lot more intrusive, so my patch opts for the one-line packaging change. Please consider applying it. Helmut diff --minimal -Nru kraptor-0.0.20040403+ds/debian/changelog kraptor-0.0.20040403+ds/debian/changelog --- kraptor-0.0.20040403+ds/debian/changelog2017-07-12 20:38:31.0 +0200 +++ kraptor-0.0.20040403+ds/debian/changelog2018-10-05 06:03:31.0 +0200 @@ -1,3 +1,10 @@ +kraptor (0.0.20040403+ds-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Pass compiler via GCC variable. (Closes: #-1) + + -- Helmut Grohne Fri, 05 Oct 2018 06:03:31 +0200 + kraptor (0.0.20040403+ds-1) unstable; urgency=medium * Team upload. diff --minimal -Nru kraptor-0.0.20040403+ds/debian/rules kraptor-0.0.20040403+ds/debian/rules --- kraptor-0.0.20040403+ds/debian/rules2017-07-12 20:38:31.0 +0200 +++ kraptor-0.0.20040403+ds/debian/rules2018-10-05 06:03:29.0 +0200 @@ -7,7 +7,7 @@ override_dh_auto_build: ./fix.sh linux - dh_auto_build + dh_auto_build -- GCC='$$(CC)' override_dh_auto_install: cp bin/kraptor_linux.bin bin/kraptor
Bug#910305: easyloggingpp FTBFS: configure: error: cannot find install-sh, install.sh, or shtool in build-aux ".."/build-aux
On Thursday, October 4, 2018 12:37:45 PM CDT Sven Joachim wrote: > Almost certainly it is has been triggered by the recent upload of > googletest, since the gtest-source directory is just a copy (via cp -a) > of /usr/src/googletest/googletest. Looks like that googletest upload > broke out-of-tree builds. Yes, it is triggered by new googletest; but the root cause is more subtle. The easyloggingpp package uses this rule to build gtest: override_dh_auto_configure: # We need to build googletest first mkdir gtest-build cp -a /usr/src/googletest/googletest gtest-source dh_auto_configure -Dgtest-source -Bgtest-build dh_auto_build -Dgtest-source -Bgtest-build If you look at the "good" build log [1], you'll see that the above code was actually configuring & building with cmake. With googletest 1.8.1, it flipped to using automake -- due to the presence of file "configure". Unfortunately, the autoconf build is broken. Suggest you add "--buildsystem=cmake" to the dh_auto_configure line. Then it builds fine with googletest 1.8.1. Best, -Steve [1] https://buildd.debian.org/status/fetch.php? pkg=easyloggingpp=all=9.96.5%2Bdfsg-1=1536739463=0
Bug#908927: Debian Linux version 3.16.0-7-586 (3.16.59-1) gives a partial fix for SMB 3.0 mounts
Ok, I installed 3.16.0-7-586 (3.16.59-1) which allowed me to mount the remote share using the version 3.0 protocol, but it got some console errors and a kernel oops in the journal, so there are still some issues here: Oct 05 04:30:38 pentium kernel: Linux version 3.16.0-7-586 (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) ) #1 Debian 3.16.59-1 (2018-10-03) ... Oct 05 04:35:08 pentium systemd[1]: Got automount request for /mnt/share, triggered by 954 (mount.cifs) Oct 05 04:35:08 pentium systemd[1]: Mounting /mnt/share... Oct 05 04:35:08 pentium kernel: Key type dns_resolver registered Oct 05 04:35:08 pentium kernel: FS-Cache: Netfs 'cifs' registered for caching Oct 05 04:35:08 pentium kernel: Key type cifs.spnego registered Oct 05 04:35:08 pentium kernel: Key type cifs.idmap registered Oct 05 04:35:09 pentium systemd[1]: Mounted /mnt/share. Oct 05 04:35:09 pentium kernel: BUG: unable to handle kernel NULL pointer dereference at 0034 Oct 05 04:35:09 pentium kernel: IP: [] crypto_shash_setkey+0xe/0xb0 Oct 05 04:35:09 pentium kernel: *pde = Oct 05 04:35:09 pentium kernel: Oops: [#1] Oct 05 04:35:09 pentium kernel: Modules linked in: arc4 ecb md4 hmac nls_utf8 cifs dns_resolver nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc ppdev snd_emu10k1 snd_util_mem snd_rawmidi snd_hwdep snd_seq_device snd_ac97_codec snd_pcm snd_timer evdev snd pcspkr serio_raw soundcore ac97_bus emu10k1_gp gameport parport_pc parport processor button fuse autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sg hid sd_mod sr_mod crc_t10dif crct10dif_generic cdrom crct10dif_common ata_generic ata_piix uhci_hcd libata ehci_hcd usbcore i2c_piix4 3c59x scsi_mod mii i2c_core thermal fan usb_common thermal_sys floppy Oct 05 04:35:09 pentium kernel: CPU: 0 PID: 954 Comm: mount.cifs Not tainted 3.16.0-7-586 #1 Debian 3.16.59-1 Oct 05 04:35:09 pentium kernel: Hardware name: /i430TX-SMC669, BIOS 4.51 PG 07/20/98 Oct 05 04:35:09 pentium kernel: task: ccf7e5a0 ti: cc06c000 task.ti: cc06c000 Oct 05 04:35:09 pentium kernel: EIP: 0060:[] EFLAGS: 00010296 CPU: 0 Oct 05 04:35:09 pentium kernel: EIP is at crypto_shash_setkey+0xe/0xb0 Oct 05 04:35:09 pentium kernel: EAX: EBX: c035e8e0 ECX: 0010 EDX: cd9630c4 Oct 05 04:35:09 pentium kernel: ESI: cc06dd18 EDI: cbffa000 EBP: cc06dc30 ESP: cc06dc18 Oct 05 04:35:09 pentium kernel: DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 Oct 05 04:35:09 pentium kernel: CR0: 8005003b CR2: 0034 CR3: 0c03c000 CR4: 0010 Oct 05 04:35:09 pentium kernel: Stack: Oct 05 04:35:09 pentium kernel: 0246 c10f0692 00011200 c035e8e0 cc06dd18 cbffa000 cc06dc7c d0ee2e39 Oct 05 04:35:09 pentium kernel: c10f0692 0011 cc06dcd0 c035e8e0 cbffa008 c6711f1a 0002 c15e3ac0 Oct 05 04:35:09 pentium kernel: 0246 f439365f cdd23340 cd963000 Oct 05 04:35:09 pentium kernel: Call Trace: Oct 05 04:35:09 pentium kernel: [] ? mempool_alloc+0x42/0x120 Oct 05 04:35:09 pentium kernel: [] ? smb3_calc_signature+0xb9/0x2a0 [cifs] Oct 05 04:35:09 pentium kernel: [] ? mempool_alloc+0x42/0x120 Oct 05 04:35:09 pentium kernel: [] ? smb2_sign_rqst+0x2f/0x60 [cifs] Oct 05 04:35:09 pentium kernel: [] ? smb2_setup_request+0x8c/0x130 [cifs] Oct 05 04:35:09 pentium kernel: [] ? SendReceive2+0xac/0x3f0 [cifs] Oct 05 04:35:09 pentium kernel: [] ? set_next_entity+0x52/0x70 Oct 05 04:35:09 pentium kernel: [] ? SMB2_ioctl+0x133/0x2e0 [cifs] Oct 05 04:35:09 pentium kernel: [] ? smb3_validate_negotiate+0x123/0x310 [cifs] Oct 05 04:35:09 pentium kernel: [] ? SMB2_tcon+0x261/0x480 [cifs] Oct 05 04:35:09 pentium kernel: [] ? kstrdup+0x3a/0x50 Oct 05 04:35:09 pentium kernel: [] ? smb2_writev_callback+0xe0/0xe0 [cifs] Oct 05 04:35:09 pentium kernel: [] ? cifs_get_tcon+0x192/0x400 [cifs] Oct 05 04:35:09 pentium kernel: [] ? cifs_mount+0x49d/0xc40 [cifs] Oct 05 04:35:09 pentium kernel: [] ? cifs_do_mount+0xc9/0x5b0 [cifs] Oct 05 04:35:09 pentium kernel: [] ? cifs_drop_inode+0x40/0x40 [cifs] Oct 05 04:35:09 pentium kernel: [] ? mount_fs+0x36/0x190 Oct 05 04:35:10 pentium kernel: [] ? kstrdup+0x3a/0x50 Oct 05 04:35:10 pentium kernel: [] ? vfs_kern_mount+0x48/0xf0 Oct 05 04:35:10 pentium kernel: [] ? do_mount+0x1e8/0xa60 Oct 05 04:35:10 pentium kernel: [] ? strndup_user+0x39/0xc0 Oct 05 04:35:10 pentium kernel: [] ? copy_mount_options+0x2f/0x1c0 Oct 05 04:35:10 pentium kernel: [] ? SyS_mount+0x9c/0xf0 Oct 05 04:35:10 pentium kernel: [] ? syscall_call+0x10/0x10 Oct 05 04:35:10 pentium kernel: Code: 26 00 8b 55 f0 83 c4 10 5b 5e 89 d0 5f 5d c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 57 56 53 83 ec 0c 3e 8d 74 26 00 <8b> 78 34 89 4d f0 89 c3 89 d6 8b 4f 1c 85 ca 74 59 89 c8 ba d0 Oct 05 04:35:10 pentium kernel: EIP: [] crypto_shash_setkey+0xe/0xb0 SS:ESP 0068:cc06dc18 Oct 05 04:35:10 pentium kernel: CR2: 0034 Oct 05 04:35:10 pentium kernel: ---[ end
Bug#910345: mate-panel: Some panel applets are narrow and truncated on HiDPI screen
Package: mate-panel Version: 1.20.3-1 Severity: normal Tags: patch Some MATE panel applets are narrow and only the left part is visible. This may have to do with the fact I have a HiDPI screen. The notification area only shows me bluetooth & ibus statuses; sound, network, and battery indicators do not appear in the allocated width. The clock applet shows a weather icon and the day of the week; anything to the right of that is truncated. The window list and show desktop button applets are half-width, but usable (with difficulty). The workspace switcher applet is narrow, but appears to be scaled rather than truncated so it is usable. Menu and launcher applets are not affected. This issue seems very much like the one reported upstream at https://github.com/mate-desktop/mate-panel/issues/843 , but that is reported to have been fixed. Attached is a screenshot showing the truncated clock applet. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mate-panel depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.0-1 ii libatk1.0-0 2.30.0-1 ii libc62.27-6 ii libcairo-gobject21.15.12-1 ii libcairo21.15.12-1 ii libdbus-1-3 1.12.10-1 ii libdbus-glib-1-2 0.110-3 ii libdconf10.30.0-1 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6 ii libglib2.0-0 2.58.1-2 ii libgtk-3-0 3.24.1-2 ii libice6 2:1.0.9-2 ii libmate-desktop-2-17 1.20.3-2 ii libmate-menu21.20.1-1 ii libmate-panel-applet-4-1 1.20.3-1 ii libmateweather1 1.20.1-1 ii libpango-1.0-0 1.42.4-3 ii libpangocairo-1.0-0 1.42.4-3 ii librsvg2-2 2.40.20-3 ii libsm6 2:1.2.2-1+b3 ii libstartup-notification0 0.12-5 ii libwnck-3-0 3.30.0-1 ii libx11-6 2:1.6.6-1 ii libxau6 1:1.0.8-1+b2 ii libxrandr2 2:1.5.1-1 ii mate-desktop 1.20.3-2 ii mate-menus 1.20.1-1 ii mate-panel-common1.20.3-1 ii mate-polkit 1.20.1-1 ii menu-xdg 0.5 mate-panel recommends no packages. mate-panel suggests no packages. -- no debconf information
Bug#910237: googletest breaks mathicgb autopkgtest: invalid cast
On Wednesday, October 3, 2018 1:26:14 PM CDT Paul Gevers wrote: > Currently this regression is contributing to the delay of the migration > of googletest to testing [1]. Due to the nature of this issue, I filed > this bug report against both packages. Can you please investigate the > situation and reassign the bug to the right package? If needed, please > change the bug's severity. I had a look, but it's over my head. Suggest to file bug upstream. -Steve
Bug#902313: gimp-help-en: tries (and fails) to access the 'Net instead of local help
Yes, gimp-help is nonfunctional, but that's because of gimp not because of gimp-help. The embedded gimp help browser uses WebKit. The only supported version of WebKit for GTK is webkit2gtk which only supports gtk3. gimp 2.10 still uses gtk2 but the next major gimp release will support gtk3. The broken help web link issue has been filed upstream as https://gitlab.gnome.org/GNOME/gimp-help/issues/93 Thanks, Jeremy Bicha
Bug#874727: closed by Anton Gladky (Bug#874727: fixed in coin3 3.1.4~abc9f50+dfsg2-1)
Hi Christoph, it's a packaging bug - libcoin is statically linked with libexpat, and the version being used is outdated. So anything that uses libcoin and libexpat will run into a segfault. I am not aware of any other application that uses libcoin. HTH, Markus On Tue, 2 Oct 2018 10:37:00 +0200 Christoph Berg wrote: > Control: tags -1 moreinfo > > Re: mlampert 2018-01-06 <20180104145135.59a157e4@occ7> > > Version libcoin89-dev 3.1.4-abc9f50+dfsg3-2 (in Debian Testing as > > of yesterday) still has a statically linked version of libexpat - > > and still causes any application using the system version libexpat > > to segfault. > > Re: Vincas Dargis 2018-07-25 > > > Are there any workarounds for this issue? Seems same problem as > > discovered on Kbuntu 18.04 that FreeCAD crashes when importing from > > SVG file. > > Hi, > > do we have any evidence that this is a bug in coin3, and not simply > freecad being buggy? The freecad version currently in unstable crashes > in all sorts of ways. > > Markus: did you see the bug in any other application? > > Christoph
Bug#910110: aptitude: aptitude does not update libxapian30 during aptitude "self upgrade"
On Tue, Oct 02, 2018 at 11:10:46PM +0200, Sven Joachim wrote: > Indeed, but that needs to be fixed in libxapian30's shlibs file. Fixed there by xapian-core 1.4.7-3. > Then aptitude (and other reverse dependencies of libxapian30 that > might be affected) can be rebuilt to pick up the changed dependency. I've pulled out a list of the packages which need rebuilding from the buildinfo files on mirror.ftp-master.d.o (anything built against libxapian-dev 1.4.6-1 or higher which doesn't already have a suitably versioned dependency): 07/10/pinot_1.05-2_kfreebsd-i386.buildinfo: libxapian-dev (= 1.4.6-1), 07/10/zeitgeist_1.0.1-0.2_kfreebsd-i386.buildinfo: libxapian-dev (= 1.4.6-1), 08/08/maildir-utils_1.0-6_amd64.buildinfo: libxapian-dev (= 1.4.7-2), 08/17/baloo-kf5_5.49.0-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2), 08/28/recoll_1.24.1-3_amd64.buildinfo: libxapian-dev (= 1.4.7-2), 09/06/plasma-desktop_5.13.5-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2), 09/06/plasma-workspace_5.13.5-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2), 09/07/aptitude_0.8.11-3_amd64.buildinfo: libxapian-dev (= 1.4.7-2), 09/29/packagesearch_2.7.9_amd64.buildinfo: libxapian-dev (= 1.4.7-2), 10/02/cyrus-imapd_2.5.11-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2), 10/03/akonadiconsole_18.08.1-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2), 10/03/akonadi-search_18.08.1-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2), 10/04/notmuch_0.28~rc0-1_amd64.buildinfo: libxapian-dev (= 1.4.7-2), 10/05/libsearch-xapian-perl_1.2.25.2-1_kfreebsd-amd64.buildinfo: libxapian-dev (= 1.4.7-2), I'll request rebuilds once 1.4.7-3 has built on most architectures, and recheck the latest buildinfo files in case anything gets built against the current libxapian-dev before the new one propagates everywhere. Cheers, Olly
Bug#910344: libgssapi-krb5-2: conffiles not removed
Package: libgssapi-krb5-2
Version: 1.16.1-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate
The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.
https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb
This bug report brought to you by adequate:
http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/
$ pkg=libgssapi-krb5-2 ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg
| grep obsolete
libgssapi-krb5-2:amd64: obsolete-conffile /etc/gss/mech.d/README
/etc/gss/mech.d/README 27e753ba1dc72900d2892b8efef6e35e obsolete
-- System Information:
Debian Release: buster/sid
APT prefers testing-debug
APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libgssapi-krb5-2 depends on:
ii libc62.27-6
ii libcom-err2 1.44.4-2
ii libk5crypto3 1.16.1-1
ii libkeyutils1 1.5.9-9.3
ii libkrb5-31.16.1-1
ii libkrb5support0 1.16.1-1
libgssapi-krb5-2 recommends no packages.
Versions of packages libgssapi-krb5-2 suggests:
pn krb5-doc
pn krb5-user
-- no debconf information
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#910280: pandoc: Please reduce the binary size
[2018-10-05 00:50] Jonas Smedegaard > Quoting John MacFarlane (2018-10-04 19:58:54) > > Jonas Smedegaard writes: > > > > > The proper solution here, I guess (but am not expert in Haskell so > > > may be wrong) is to switch to using shared linking, so that 5 > > > Haskell binaries will not consume 5 x the disk space of the parts > > > reused among them. We could generate packages with compressed binaries in a way, similar to *-dbg packages. All compiled languages, except C (Go, Rust, Haskell) would benefit, but it is quite a bit of work -- changes to debhelper and reprorepo, at least.
Bug#887045: iwlwifi: TX_STATUS_FAIL_DEST_PS at iwlwifi/mvm/tx.c:1363 using hostapd NOT RESOLVED in 4.18.8
https://github.com/torvalds/linux/commit/20932750d9c78d307e4f2f18f9c6a32b82b1e0e8 is not in https://elixir.bootlin.com/linux/v4.18.8/source/net/mac80211/rx.c#L1614
Bug#887045: iwlwifi: TX_STATUS_FAIL_DEST_PS at iwlwifi/mvm/tx.c:1363 using hostapd
Not fixed in 4.18.8-1 WARNING: CPU: 3 PID: 379 at /build/linux-GZkygY/linux-4.18.8/drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1410 iwl_mvm_rx_tx_cmd+0x3d1/0x630 [iwlmvm]
Bug#909846: libglib2.0-dev: absolute paths in gio-2.0.pc break reverse dependencies
On Sat, 29 Sep 2018 at 10:22:06 -0400, Jeremy Bicha wrote: > I believe we don't consider this a bug in glib2.0. It doesn't look as though this is going to be changed upstream, so I don't think diverging is a good idea in the long term; and only two packages seem to be affected, so fixing those packages seems a reasonable short-term solution. I've opened RC bugs on tpm2-abrmd (#910340, proposing the patch that its upstream already applied) and playerctl (#910342, proposing a new patch that is equally straightforward) and marked them as blocking this one. I'm still trying to get clarification from the GLib upstream maintainers on what their recommendation is for Autotools projects (other than "stop using Autotools", which might be preferred in the long term but scales poorly). The two reasonable possibilities seem to be: PKG_CHECK_VAR([GDBUS_CODEGEN], [gio-2.0], [gdbus_codegen]) or AC_PATH_PROG([GDBUS_CODEGEN], [gdbus-codegen]) (Neither is particularly better than the other for Debian systems; they only have different characteristics in situations that Debian package builds shouldn't encounter, such as GLib in a non-default $prefix.) Either way, anyone with special requirements (e.g. cross-compiling on a non-Debian system) can use "./configure GDBUS_CODEGEN=my-gdbus-codegen" to override the default. smcv
Bug#910280: pandoc: Please reduce the binary size
Quoting John MacFarlane (2018-10-04 19:58:54) > Jonas Smedegaard writes: > > > The proper solution here, I guess (but am not expert in Haskell so > > may be wrong) is to switch to using shared linking, so that 5 > > Haskell binaries will not consume 5 x the disk space of the parts > > reused among them. > > Yes, in theory. But this didn't work well in practice when arch linux > tried it. It meant that installing pandoc forced installation of a > very large number of dynamic libraries, and people really didn't like > this. > > https://www.reddit.com/r/haskell/comments/6jj8ha/whats_going_on_in_archlinux_pandoc_requires_1gb/ Well, seems they chose to not properly separate development code from runtime code. Try install a single KDE program program - e.g. Krita - on an otherwise GNOME or Xfce system - that'll also pull in several hundred megabytes. But then the next one will not. I would expect similarly that installing Pandoc as the _only_ application written in Haskell would pull in maybe 50 MB or maybe 150 MB (but not 1GB when sensibly packaged) and then installing another Haskell-based application would require far less. But I don't know. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#796400: [pkg-go] Bug#796400: Bug#796400: Bug#796400: golang-github-jacobsa-ratelimit: Non-determistically FTBFS due to unreliable timing in tests
Should we fill a RM bug? I'll do it if this bug stays inactive. Cheers, -- Alexandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#910343: cowsay-off: What's the point of cowsay-off if you remove offensive ones?
Package: cowsay-off Version: 3.03+dfsg2-5 Severity: grave Justification: renders package unusable Dear Maintainer, what is even the point of this package existing if the offensive ascii arts are removed? Please just drop this. Best -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.1 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cowsay-off depends on: ii cowsay 3.03+dfsg2-5 cowsay-off recommends no packages. cowsay-off suggests no packages. -- no debconf information
Bug#476150: [scite] leaves /usr/share/app-install/desktop/scite.desktop even after purging
wrote: > Hi, > > Scite leaves the file /usr/share/app-install/desktop/scite.desktop on > my system although I have purged the package. > Hi! Despite the name, that file isn't a part of the scite package, but it looks like is a part of the app-install-data package - and I believe it's presence is correct even if the SciTE package isn't installed, so I would like to close this bug. (The file listed in the app-install-data package is /usr/share/app-install/desktop/SciTE.desktop but I assume that the capitalisation is simply a typo of yours). Please confirm that I can close this bug. thanks -- Andreas Rönnquist gus...@debian.org
Bug#910262: devscripts: autopkgtest regression
On Thu, Oct 04, 2018 at 01:37:51PM +0200, Xavier wrote: > fakeroot is a recommended package of devscripts. The removal of > "needs-recommends" should have generate this issue (NB: I can't > reproduce it there) Note that fakeroot might be pre-installed in many chroots, as many packages took it from granted (but now slowly some are opting out of it with Rules-Requires-Root:no...). If you note, I explicitly added it to devscripts' build-depends for this reason :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#910342: playerctl: FTBFS with GLib 2.58.1: redundant use of AC_PATH_PROG
Source: playerctl Version: 0.6.1-1 Severity: serious Tags: patch upstream Justification: fails to build from source Control: block 909846 by -1 playerctl has this pattern in configure.ac: AC_PATH_PROG([GDBUS_CODEGEN], [`$PKG_CONFIG --variable=gdbus_codegen gio-2.0`]) This doesn't work with recent versions of GLib, in which the pkg-config call produces an absolute path. AC_PATH_PROG only accepts a basename for its second argument. There is some debate over whether the recommended way to check for tools like these is to search the PATH: AC_PATH_PROG([GDBUS_CODEGEN], [gdbus-codegen]) or to ask pkg-config: PKG_CHECK_VAR([GDBUS_CODEGEN], [gio-2.0], [gdbus_codegen]) but combining AC_PATH_PROG with pkg-config certainly doesn't seem to be what's intended. Either of those macro invocations would allow the location to be overridden with "./configure GDBUS_CODEGEN=..." if required. I have confirmed that the attached patch makes playerctl build successfully in sbuild. smcv From: Simon McVittie Date: Thu, 4 Oct 2018 21:08:27 +0100 Subject: build: Use PKG_CHECK_VAR to check for gdbus-codegen Recent versions of GLib define $gdbus_codegen to the absolute path to gdbus-codegen, but AC_PATH_PROG doesn't work for an absolute path as its second argument, causing configure to fail. There's actually no need to use AC_PATH_PROG here, because we don't need an absolute path to gdbus-codegen: if it's just a basename that AC_PATH_PROG could find in the PATH, then the Makefile can also find it in the PATH. Using PKG_CHECK_VAR (from pkg-config 0.28+) preserves the ability for a user to specify the path to a gdbus-codegen tool as a configure argument, defaulting to the value of $gdbus_codegen from gio-2.0.pc. --- configure.ac | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 21679fa..9a137c9 100644 --- a/configure.ac +++ b/configure.ac @@ -21,10 +21,8 @@ AC_PROG_INSTALL PKG_CHECK_MODULES([GOBJECT], [gobject-2.0 >= 2.38]) PKG_CHECK_MODULES([GIO], [gio-unix-2.0]) -AC_PATH_PROG([GDBUS_CODEGEN], [`$PKG_CONFIG --variable=gdbus_codegen gio-2.0`]) -if test -z "$GDBUS_CODEGEN"; then -AC_MSG_ERROR([*** gdbus-codegen is required to build playerctl]) -fi +PKG_CHECK_VAR([GDBUS_CODEGEN], [gio-2.0], [gdbus_codegen], [], + [AC_MSG_ERROR([*** gdbus-codegen is required to build playerctl])]) # Checks for typedefs, structures, and compiler characteristics AC_PROG_CC_STDC
Bug#910341: tpm2-abrmd: unnecessarily skips one unit test, could use dbus-run-session instead
Source: tpm2-abrmd Version: 1.3.1-1 Severity: minor Tags: patch While testing the upstream patch for tpm2-abrmd's FTBFS against recent GLib (see separate bug), I happened to notice a patch that disables one unit test, which requires a D-Bus session bus. It's true that autobuilder environments do not usually have a D-Bus session bus. However, dbus >= 1.8 comes with the dbus-run-session tool, which starts a temporary session bus: it is designed to be used in automated tests and similar environments. If you wrap the build-time tests with dbus-run-session, as in the attached patch, then you don't need to disable test coverage. I have checked that the attached patch works in sbuild (when combined with applying the upstream patch for the FTBFS with recent GLib). Ideally, the build-time tests would be altered upstream to start their own temporary session bus, for example by using dbus-run-session (like the dbus-python source package does) or by starting a dbus-daemon as a subprocess. Regards, smcv >From 1e96aef7bc661e1657c4bc8d06555f923c25deab Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Thu, 4 Oct 2018 23:12:59 +0100 Subject: [PATCH] Use dbus-run-session to give unit tests a temporary session bus This means that tss2-tcti-tabrmd_unit does not have to be skipped. --- debian/control| 1 + ...2-remove-unit-test-needs-dbus-daemon.patch | 19 --- debian/patches/series | 1 - debian/rules | 5 + 4 files changed, 6 insertions(+), 20 deletions(-) delete mode 100644 debian/patches/0002-remove-unit-test-needs-dbus-daemon.patch diff --git a/debian/control b/debian/control index 19b15d2..50afa23 100644 --- a/debian/control +++ b/debian/control @@ -6,6 +6,7 @@ Uploaders: Ying-Chun Liu (PaulLiu) Build-Depends: autoconf, autoconf-archive, automake, + dbus , debhelper (>= 11), libcmocka-dev, libdbus-1-dev, diff --git a/debian/patches/0002-remove-unit-test-needs-dbus-daemon.patch b/debian/patches/0002-remove-unit-test-needs-dbus-daemon.patch deleted file mode 100644 index 8f2837e..000 --- a/debian/patches/0002-remove-unit-test-needs-dbus-daemon.patch +++ /dev/null @@ -1,19 +0,0 @@ -Description: Remove some unit test requires dbus to be run. - On build servers there's no dbus running. We shouldn't start the service - and connected to dbus. Thus we remove unit tests that requires dbus. -Author: Ying-Chun Liu (PaulLiu) -Forwarded: not-needed -Last-Update: 2018-05-02 - -Index: tpm2-abrmd/Makefile.am -=== tpm2-abrmd.orig/Makefile.am -+++ tpm2-abrmd/Makefile.am -@@ -38,7 +38,6 @@ TESTS_UNIT = \ - test/thread_unit \ - test/tpm2-command_unit \ - test/tpm2-response_unit \ --test/tss2-tcti-tabrmd_unit \ - test/tss2-tcti-echo_unit \ - test/util_unit - if TCTI_DEVICE diff --git a/debian/patches/series b/debian/patches/series index 763fea8..5151d6c 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,2 +1 @@ 0001-Since-Debian-source-package-did-not-contain-.git-fil.patch -0002-remove-unit-test-needs-dbus-daemon.patch diff --git a/debian/rules b/debian/rules index 3a6df7a..cb64ccb 100755 --- a/debian/rules +++ b/debian/rules @@ -17,5 +17,10 @@ override_dh_autoreconf: override_dh_auto_configure: dh_auto_configure -- --enable-unit +override_dh_auto_test: +ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) + dbus-run-session -- dh_auto_test +endif + override_dh_missing: dh_missing --fail-missing -- 2.19.0
Bug#890606: Patch for kopete 18.04.2-1 in experimental
Hi Bernhard, Here is a patch for kopete 18.04.2-1 in experimental. Thank you! Kind regards, Felix Lechner fix-mediastreamer-ftbfs.patch.xz Description: application/xz
Bug#910292: transition: libsrtp0-rm
On Thu, Oct 04, 2018 at 11:54:12PM +0200, Bernhard Schmidt wrote: > outdated auto tracker at > https://release.debian.org/transitions/html/auto-srtp.html which is a > bit confusing. this will go away as soon as the package is removed from experimental… > > 1 File a RC bug against src:srtp so the autoremoval clocks starts > >ticking. If the package is a key-package (not the case) or you want > >it removed from testing sooner than you can get the releease team > >involved of course. > > I think it's transitively key due to being a rdep of kopete (which is > core part of the KDE desktop). bad me. I wrote the "(not the case)" thinking I'd check before sending, which obviously I didn't… It seems the reason is not the dependency itself but "popcon" :) > > Checking reverse dependencies... > > # Broken Depends: > > asterisk: asterisk-modules [hurd-i386] > > gst-plugins-bad1.0: gstreamer1.0-plugins-bad [hurd-i386 kfreebsd-amd64 > > kfreebsd-i386] > > Those are non-release arches and they are just outdated. I guess those > can be ignored? They can be ignored (you should remember to mention this in the RM bug). Of course if you could at least glance at why they are outdated, quite often the fix is not that hard… For asterisk the fix is asking for removal of the binaries there, since an rdep is not building on hurd anymore, for the other the work is in progress (I think #829570 is all it will take…). > > kopete: kopete [amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el > > s390x] > > That's the blocker > > > opal: libopal-dev [amd64 armel i386 mips mipsel] > > libopal3.10.10 [amd64 armel i386 mips mipsel] > Only in unstable and RC-buggy for a while, we've already orphaned opal. You haven't orphaned it, being a RFA. Also, if that's the reaction to RC bugs, then you should probably get the package removed instead, as orphaning doesn't automagically fix bugs. > > resiprocate: librecon-1.11 [amd64 arm64 armel armhf i386 mips mips64el > > mipsel ppc64el s390x] Despite all the RC bugs and being unstable-only, it still builds. Please consider patching that instead breaking it. > I think that's a false positive. libsrtp0-dev (in unstable) provides > libsrtp-dev. Also, I think src:qtwebengine-opensource-src isn't really > using srtp at all, I've filed #910300 for that. dak sadly still doesn't cope with virtual packages :( Anyway, I saw you filed those bugs as whishlist/normal. In my experience, don't expect much traction with just wishlist bugs… Also, consider providing patches… Considering that your rdep is indirectly kde-standard, you should imho ask for removal from testing only once kopete is fixed… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#890606: Upstream review
Hi Pino, > Can you please open a new review request upstream [1]? You will need > to download kopete from git though, although it should not be an issue > (it is like building 18.04.x from experimental). > > [1] https://phabricator.kde.org/ Here it is: https://phabricator.kde.org/D15956. Thank you! Kind regards, Felix Lechner
Bug#910340: tpm2-abrmd: FTBFS with GLib 2.58.1: redundant use of AC_PATH_PROG
Source: tpm2-abrmd Version: 1.3.1-1 Severity: serious Tags: patch upstream Justification: fails to build from source Control: block 909846 by -1 tmp2-abrmd has this pattern in configure.ac: AC_PATH_PROG([GDBUS_CODEGEN], [`$PKG_CONFIG --variable=gdbus_codegen gio-2.0`]) This doesn't work with recent versions of GLib, in which the pkg-config call produces an absolute path. AC_PATH_PROG only accepts a basename for its second argument. There is some debate over whether the recommended way to check for tools like these is to search the PATH: AC_PATH_PROG([GDBUS_CODEGEN], [gdbus-codegen]) or to ask pkg-config: PKG_CHECK_VAR([GDBUS_CODEGEN], [gio-2.0], [gdbus_codegen]) but combining AC_PATH_PROG with pkg-config certainly doesn't seem to be what's intended. Either of those macro invocations would allow the location to be overridden with "./configure GDBUS_CODEGEN=..." if required. The upstream developer of tpm2-abrmd already applied a patch to use AC_PATH_PROG([GDBUS_CODEGEN], [gdbus-codegen]): https://github.com/tpm2-software/tpm2-abrmd/commit/b4036908dd067f8eadc9d53b1a2a39032aed109d so I would suggest applying that (attached). I can confirm that applying that patch fixes the build in sbuild. smcv From: Jonas Witschel Date: Tue, 11 Sep 2018 13:14:36 +0200 Subject: Fix gdbus-codegen lookup for recent versions of GLib If GLib is built using Meson, the gdbus_codegen variable contains the whole path to the binary instead of just the binary name. This cannot be parsed by AC_PATH_PROG and leads to an error in the configure script. According to https://gitlab.gnome.org/GNOME/glib/issues/1521#note_313402, the recommended way to solve this is to look up gdbus-codegen directly without using the pkg-config variable. Origin: upstream, 2.0.3, commit:b4036908dd067f8eadc9d53b1a2a39032aed109d --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index fe278e3..d1ea91b 100644 --- a/configure.ac +++ b/configure.ac @@ -32,7 +32,7 @@ PKG_CHECK_MODULES([GLIB], [glib-2.0]) PKG_CHECK_MODULES([GOBJECT], [gobject-2.0]) PKG_CHECK_MODULES([SAPI],[sapi < 2.0.0]) AC_ARG_VAR([GDBUS_CODEGEN],[The gdbus-codegen executable.]) -AC_PATH_PROG([GDBUS_CODEGEN], [`$PKG_CONFIG --variable=gdbus_codegen gio-2.0`]) +AC_PATH_PROG([GDBUS_CODEGEN], [gdbus-codegen]) if test -z "$GDBUS_CODEGEN"; then AC_MSG_ERROR([*** gdbus-codegen is required to build tpm2-abrmd]) fi
Bug#909965: apcalc hard codes location of standard C headers
Thanks for your patch. There has been a discussion about a similar problem on MacOS on the calc mailing list a few days ago. I'll forward your patch there and see whether I can get it included upstream. Martin
Bug#910339: RM: srtp/experimental -- ROM; outdated, superseded by src:libsrtp2
Am 05.10.18 um 00:02 schrieb Bernhard Schmidt: > mediastreamer2 was an accident and is already fixed in unstable s/unstable/experimental/
Bug#910339: RM: srtp/experimental -- ROM; outdated, superseded by src:libsrtp2
Package: ftp.debian.org Severity: normal Hi, on behalf of Jonas Smedegaard I'm asking to RM src:srtp from experimental. It is a left-over from a failed transition attempt a few years ago. The whole src:srtp has been superseded by src:libsrtp2. We will try to remove src:srtp from Buster as well. dak says dak rm -Rn -s experimental srtp Will remove the following packages from experimental: libsrtp-dev | 1.5.3~dfsg-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x libsrtp1 | 1.5.3~dfsg-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x libsrtp1-dbg | 1.5.3~dfsg-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x srtp | 1.5.3~dfsg-1 | source srtp-docs | 1.5.3~dfsg-1 | all srtp-utils | 1.5.3~dfsg-1 | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x Maintainer: Jonas Smedegaard --- Reason --- -- Checking reverse dependencies... # Broken Depends: mediastreamer2: libmediastreamer-voip10 [armel armhf mips64el mipsel] # Broken Build-Depends: qtwebengine-opensource-src: libsrtp-dev Dependency problem found. mediastreamer2 was an accident and is already fixed in unstable, the slow architectures are in the buildd queue. qtwebengine-opensource-src is a false positive I think, since libsrtp0-dev in unstable Provides libsrtp-dev. It also doesn't seem to use srtp anyway (Bug#910300) Thanks, Bernhard
Bug#910122: apt-listbugs: executes xdg-open as root user
On Thu, 4 Oct 2018 10:48:08 +1000 Carl Suster wrote: [...] > Thanks for your reply, You're welcome! > and sorry I missed the archived bugs on this > topic. Don't worry about that. > I'm not sure yet that I fully understand the problems, It's rather complicated, indeed. > but > perhaps the situation is slightly different now in that the browser is > being launched with xdg-open rather than sensible-browser? I'll have a > look soon and see what I can find out. Actually apt-listbugs still uses sensible-browser for its own browser calling feature. But, as I said, you experienced the issue while in a querybts menu... It's querybts that uses xdg-open... As far as I could quickly check, the situation has not changed much. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpHxfxBIIOc4.pgp Description: PGP signature
Bug#910292: transition: libsrtp0-rm
Control: reassign -1 src:srtp Control: severity -1 serious Control: retitle -1 Do not release srtp 1.x with Buster Hi Mattia, thanks for your response! > On Thu, Oct 04, 2018 at 04:16:50PM +0200, Bernhard Schmidt wrote: >> on behalf of Jonas I'm filing a transition bug to track removal of the old >> libsrtp0 from Debian. >> >> src:srtp has built libsrtp0 and libsrtp0-dev. It is several years out of >> date. >> The successor is src:libsrtp2 building libsrtp2-1 and libsrtp2-dev. Most >> rdeps >> have already migrated. We'd like to avoid releasing libsrtp0 with Buster if >> possible. > > The release team is not usually involved in these things, that don't > really count as "transitions" usually. Too bad, I was hoping for a tracker and pressure to get that outdated software removed :-) From the failed transition attempt there is an outdated auto tracker at https://release.debian.org/transitions/html/auto-srtp.html which is a bit confusing. > The normal procedure is: > > 1 File a RC bug against src:srtp so the autoremoval clocks starts >ticking. If the package is a key-package (not the case) or you want >it removed from testing sooner than you can get the releease team >involved of course. I think it's transitively key due to being a rdep of kopete (which is core part of the KDE desktop). > 2 File a RM bug against ftp.debian.org, tagged moreinfo as the removal >can't be processed right away > 3 File RC bugs against all the reverse dependencies, stating that they >need to migrate away from src:srtp, make these bugs block the RM bug >filed at point 2. Okay, will do. > > > According to my dak rm: > > Checking reverse dependencies... > # Broken Depends: > asterisk: asterisk-modules [hurd-i386] > gst-plugins-bad1.0: gstreamer1.0-plugins-bad [hurd-i386 kfreebsd-amd64 > kfreebsd-i386] Those are non-release arches and they are just outdated. I guess those can be ignored? > kopete: kopete [amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el > s390x] That's the blocker > opal: libopal-dev [amd64 armel i386 mips mipsel] > libopal3.10.10 [amd64 armel i386 mips mipsel] > resiprocate: librecon-1.11 [amd64 arm64 armel armhf i386 mips mips64el mipsel > ppc64el s390x] Only in unstable and RC-buggy for a while, we've already orphaned opal. > # Broken Build-Depends: > kopete: libsrtp0-dev > > > Those are the packages you should interact with. > >> There has been an incomplete attempt to update libsrtp 1.x in experimental a >> few years ago (building libsrtp1). This has never gained traction and has >> been >> superseded by libsrtp2. The only accidental rdep inside experimental is >> waiting >> for the buildds to catch up, then I'll request removal from experimental as >> well. > > Right, you can file the RM already, specifying that it's fine to break > rdeps. > But there is also src:qtwebengine-opensource-src that is build-depending > on libsrtp-dev (which is experimental only). You'll need to bug that > package as well. I think that's a false positive. libsrtp0-dev (in unstable) provides libsrtp-dev. Also, I think src:qtwebengine-opensource-src isn't really using srtp at all, I've filed #910300 for that. Regards, Bernhard
Bug#909511: lintian: check for update-inetd --group without --add, --pattern with --add
tags 909511 + pending thanks Fixed in Git, pending upload: https://salsa.debian.org/lintian/lintian/commit/0da150d2f08ec8ccddbd0de217fc813deef17b55 checks/scripts.desc| 17 + checks/scripts.pm | 9 + debian/changelog | 3 +++ .../debian/debian/postinst | 18 ++ .../desc | 6 ++ .../tags | 4 6 files changed, 57 insertions(+) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#910334: lintian: Please warn about redundant entries in Files-Excluded
On Thu, Oct 04, 2018 at 10:40:53PM +0100, Chris Lamb wrote: > I am, of course, an idiot. Please, I really appreciate the huge work you are throwing at lintian nearly every day, including the openess to constantly looking for more things to check! :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#909545: SSL CERTIFICATE_VERIFY_FAILED when using gs (Google Cloud Storage) backend.
control: forwarded -1 https://github.com/boto/boto/pull/3836
On 2018-09-30 22:17:05 [+0200], Witold Baryluk wrote:
> Needed a small change to your patch:
>
> Line 126 in boto/https_connection.py in connect function needs to be
> protected by check::
>
> 126 if self.key_file:
> 127 context.load_cert_chain(certfile=self.cert_file,
> keyfile=self.key_file)
Thank you. Attached the fixed version and forwarded upstream.
Sebastian
>From f5e7f6c98b46ff622f60a4661ffc9ce07216d109 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Sat, 29 Sep 2018 21:47:11 +0200
Subject: [PATCH] boto: try to add SNI support
Add SNI support. Newer OpenSSL (with TLS1.3) fail to connect if the
hostname is missing.
Link: https://bugs.debian.org/bug=909545
Tested-by: Witold Baryluk
Signed-off-by: Sebastian Andrzej Siewior
---
boto/connection.py | 19 ++-
boto/https_connection.py | 22 +++---
2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/boto/connection.py b/boto/connection.py
index 34b428f101df7..b4867a7657465 100644
--- a/boto/connection.py
+++ b/boto/connection.py
@@ -824,23 +824,24 @@ DEFAULT_CA_CERTS_FILE = os.path.join(os.path.dirname(os.path.abspath(boto.cacert
h = http_client.HTTPConnection(host)
if self.https_validate_certificates and HAVE_HTTPS_CONNECTION:
+context = ssl.create_default_context()
+context.verify_mode = ssl.CERT_REQUIRED
+context.check_hostname = True
+
msg = "wrapping ssl socket for proxied connection; "
if self.ca_certificates_file:
msg += "CA certificate file=%s" % self.ca_certificates_file
+context.load_verify_locations(cafile=self.ca_certificates_file)
else:
msg += "using system provided SSL certs"
+context.load_default_certs()
boto.log.debug(msg)
key_file = self.http_connection_kwargs.get('key_file', None)
cert_file = self.http_connection_kwargs.get('cert_file', None)
-sslSock = ssl.wrap_socket(sock, keyfile=key_file,
- certfile=cert_file,
- cert_reqs=ssl.CERT_REQUIRED,
- ca_certs=self.ca_certificates_file)
-cert = sslSock.getpeercert()
-hostname = self.host.split(':', 0)[0]
-if not https_connection.ValidateCertificateHostname(cert, hostname):
-raise https_connection.InvalidCertificateException(
-hostname, cert, 'hostname mismatch')
+if key_file:
+context.load_cert_chain(certfile=cert_file, keyfile=key_file)
+
+sslSock = context.wrap_socket(sock, server_hostname=host)
else:
# Fallback for old Python without ssl.wrap_socket
if hasattr(http_client, 'ssl'):
diff --git a/boto/https_connection.py b/boto/https_connection.py
index ddc31a152292e..a5076f6f9b261 100644
--- a/boto/https_connection.py
+++ b/boto/https_connection.py
@@ -119,20 +119,20 @@ from boto.compat import six, http_client
sock = socket.create_connection((self.host, self.port), self.timeout)
else:
sock = socket.create_connection((self.host, self.port))
+
+context = ssl.create_default_context()
+context.verify_mode = ssl.CERT_REQUIRED
+context.check_hostname = True
+if self.key_file:
+context.load_cert_chain(certfile=self.cert_file, keyfile=self.key_file)
+
msg = "wrapping ssl socket; "
if self.ca_certs:
msg += "CA certificate file=%s" % self.ca_certs
+context.load_verify_locations(cafile=self.ca_certs)
else:
msg += "using system provided SSL certs"
+context.load_default_certs()
boto.log.debug(msg)
-self.sock = ssl.wrap_socket(sock, keyfile=self.key_file,
-certfile=self.cert_file,
-cert_reqs=ssl.CERT_REQUIRED,
-ca_certs=self.ca_certs)
-cert = self.sock.getpeercert()
-hostname = self.host.split(':', 0)[0]
-if not ValidateCertificateHostname(cert, hostname):
-raise InvalidCertificateException(hostname,
- cert,
- 'remote hostname "%s" does not match '
- 'certificate' % hostname)
+
+self.sock = context.wrap_socket(sock, server_hostname=self.host)
--
2.19.0
Bug#910333: fontcustom: privacy breach
Hello, On 2018-10-04 4:55 p.m., Chris Lamb wrote: > (It would also be nice to see privacy-breach-generic addressed.) Done. There was no use for this code unless you run browsers that you find in museums anyways ;) Cheers, -- Alexandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Bug#910333: fontcustom: Incomplete debian/copyright?
Hi Alexandre, > Fontcustom is a program that, amongst other things, parses the output of > fontforge, which outputs this message. The string in spec_helper.rb is > just for testing purposes, but does not apply to any file in fontcustom. > > I'll close this bug. Thanks for clarifying & checking! Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#910334: lintian: Please warn about redundant entries in Files-Excluded
On Thu, Oct 04, 2018 at 09:55:31PM +0100, Chris Lamb wrote: > https://lintian.debian.org/tags/source-includes-file-in-files-excluded.html > > … which triggers when a file specified in the Files-Excluded field in > debian/copyright exists in the source tree, we could also check for > seemingly-redundant entries such as: > > Files-Excluded: ./file-does-not-exist > > This would catch typos and strange things such as #910330. I'm concerned as to how you would go about checking for this. You can't quite check for non-existent files that shouldn't be existing anyway... -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#910338: ITP: mdk4 - poc tool to exploit common IEEE 802.11 protocol weaknesses
Package: wnpp Owner: "Samuel Henrique" Severity: wishlist User: samuel...@debian.org Usertags: gsoc2018-portkalipackages-extra * Package name: mdk4 * URL : https://github.com/aircrack-ng/mdk4 * License : GPL2+ Programming Lang: C Description : This package contains a proof-of-concept tool to exploit common IEEE 802.11 protocol weaknesses. . MDK4 is a new version of MDK3. MDK4 is a Wi-Fi testing tool from E7mer of 360PegasusTeam, ASPj of k2wrlz, it uses the osdep library from the aircrack-ng project to inject frames on several operating systems. Features: * Supports two WiFi card (one for receiving data, another for injecting data). * Supports block the specified ESSID/BSSID/Station MAC in command option. * Supports both 2.4 to 5GHz (Linux). * Supports IDS Evasion (Ghosting, Fragmenting, Does not fully work with every driver). * Supports packet fuzz testing. I intend to maintain this package under the Debian Security Tools Packaging Team (pkg-security). -- Samuel Henrique
Bug#910292: transition: libsrtp0-rm
On Thu, Oct 04, 2018 at 04:16:50PM +0200, Bernhard Schmidt wrote: > on behalf of Jonas I'm filing a transition bug to track removal of the old > libsrtp0 from Debian. > > src:srtp has built libsrtp0 and libsrtp0-dev. It is several years out of date. > The successor is src:libsrtp2 building libsrtp2-1 and libsrtp2-dev. Most rdeps > have already migrated. We'd like to avoid releasing libsrtp0 with Buster if > possible. The release team is not usually involved in these things, that don't really count as "transitions" usually. The normal procedure is: 1 File a RC bug against src:srtp so the autoremoval clocks starts ticking. If the package is a key-package (not the case) or you want it removed from testing sooner than you can get the releease team involved of course. 2 File a RM bug against ftp.debian.org, tagged moreinfo as the removal can't be processed right away 3 File RC bugs against all the reverse dependencies, stating that they need to migrate away from src:srtp, make these bugs block the RM bug filed at point 2. According to my dak rm: Checking reverse dependencies... # Broken Depends: asterisk: asterisk-modules [hurd-i386] gst-plugins-bad1.0: gstreamer1.0-plugins-bad [hurd-i386 kfreebsd-amd64 kfreebsd-i386] kopete: kopete [amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x] opal: libopal-dev [amd64 armel i386 mips mipsel] libopal3.10.10 [amd64 armel i386 mips mipsel] resiprocate: librecon-1.11 [amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x] # Broken Build-Depends: kopete: libsrtp0-dev Those are the packages you should interact with. > There has been an incomplete attempt to update libsrtp 1.x in experimental a > few years ago (building libsrtp1). This has never gained traction and has been > superseded by libsrtp2. The only accidental rdep inside experimental is > waiting > for the buildds to catch up, then I'll request removal from experimental as > well. Right, you can file the RM already, specifying that it's fine to break rdeps. But there is also src:qtwebengine-opensource-src that is build-depending on libsrtp-dev (which is experimental only). You'll need to bug that package as well. Really, the release team is not the body you need to involve for these changes, they need to be all handled by the maintainer of srtp (or anybody else, with the maintainer's ack), and a transition tracker won't really help you, all you need is asking `dak rm`'s opinion :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#910337: squid: crash when rotating logs and no cache_dir
Package: squid Version: 4.2-2 Severity: normal Dear Maintainer, In a default install of squid, the following shows an assertion error in /var/log/squid/cache.log: squid -k rotate cache.log: 2018/10/04 20:34:14 kid1| logfileRotate: daemon:/var/log/squid/access.log 2018/10/04 20:34:14 kid1| assertion failed: comm.cc:428: "!isOpen(conn->fd)" 2018/10/04 20:34:15 kid1| Set Current Directory to /var/spool/squid Turns out if squid.conf has a cache_dir configuration, then the crash does not happen. For example, from squid-deb-proxy: cache_dir aufs /var/cache/squid-deb-proxy 4 16 256 There is an upstream bug about this, to which I added the above information: https://bugs.squid-cache.org/show_bug.cgi?id=4796 The upstream bug seems to have stalled, or maybe it was moved to another forum. I didn't find it on github after a quick search. Thanks!
Bug#910336: sword: fails to build except on arch: all
Source: sword Version: 1.7.3.1+dfsg-1 Severity: serious Tags: ftbfs X-Debbugs-CC: domini...@corbex.org, teusjanne...@gmail.com sword fails to build: https://buildd.debian.org/status/package.php?p=sword It looks like the problem is that it doesn't handle builds where the arch-independent package libsword-common isn't built. By the way, sword 1.8.1 was released in January. Build log excerpt --- dh_install --list-missing dh_install: Please use dh_missing --list-missing/--fail-missing instead dh_install: This feature will be removed in compat 12. # Fixes FTBFS if running binary-arch target only chmod -x debian/libsword-common/usr/share/sword/locales.d/* chmod: cannot access 'debian/libsword-common/usr/share/sword/locales.d/*': No such file or directory make[1]: [debian/rules:32: override_dh_install] Error 1 (ignored) # Remove empty directory: usr/share/sword/modules rmdir debian/libsword-common/usr/share/sword/modules rmdir: failed to remove 'debian/libsword-common/usr/share/sword/modules': No such file or directory make[1]: *** [debian/rules:34: override_dh_install] Error 1 Thanks, Jeremy Bicha
Bug#910303: Xdvi stoped showing emedded EPS figures after updating ghostscript
I just made the test and can confirm that removing "/flushpage" from the line /.devicename /.doneshowpage /flushpage /.getbitsrect /.getdevice /.getdefaultdevice /.getdeviceparams /.gethardwareparams (line number 2176) of the "/usr/share/ghostscript/9.20/Resource/Init/gs_init.ps" (provided by the package "libgs9-common", version 9.20~dfsg-3.2+deb9u5) solves the problem. Apparently, xdvi also uses flushpage to display EPS files. This can perhaps be changed on the xdvi side, but since the upstream seem to have decided to restore flushpage anyway, there is probably no need for that. S. Dachian
Bug#910335: zziplib: CVE-2018-16548: Memory leak triggered in the function __zzip_parse_root_directory in zip.c
Source: zziplib Version: 0.13.62-3 Severity: normal Tags: security upstream Forwarded: https://github.com/gdraheim/zziplib/issues/58 Hi, The following vulnerability was published for zziplib. CVE-2018-16548[0]: | An issue was discovered in ZZIPlib through 0.13.69. There is a memory | leak triggered in the function __zzip_parse_root_directory in zip.c, | which will lead to a denial of service attack. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-16548 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16548 [1] https://github.com/gdraheim/zziplib/issues/58 Regards, Salvatore
Bug#909995: Looks like LyX?
Weird. This built fine in my sbuild environment for upload to the archive, but is now failing, so looks like one of the deps has changed. The failing build log includes: Traceback (most recent call last): File "/usr/share/lyx/configure.py", line 1886, in ret = checkLatexConfig(lyx_check_config and LATEX != '', bool_docbook) File "/usr/share/lyx/configure.py", line 1368, in checkLatexConfig retval = processLayoutFile(file, bool_docbook) File "/usr/share/lyx/configure.py", line 1316, in processLayoutFile % (classname, opt, desc, avai, prereq)) TypeError: %b requires a bytes-like object, or an object that implements __bytes__, not 'str' support/Systemcall.cpp (294): Systemcall: 'python3 -tt "/usr/share/lyx/configure.py" --binary-dir="/usr/bin/"' finished with exit code 1 LyX: Done! LayoutFile.cpp (172): LayoutFileList::Read: no textclasses found! Error: Document class not found and later: Error: Cannot convert file No information for converting svg format files to eps. Define a converter in the preferences. which implies LyX wants something extra now. Will poke. J. -- They say that sex is like napalm.
Bug#910333: fontcustom: Incomplete debian/copyright?
Source: fontcustom Version: 2.0.0+ds4-1 Severity: serious Justication: Policy 12.5 X-Debbugs-CC: Alexandre Viau , ftpmas...@debian.org Hi, I just ACCEPTed fontcustom from NEW but noticed it was missing attribution in debian/copyright for at least the spec_helper.rb Ruby script. This is in no way exhaustive so please check over the entire package carefully and address these on your next upload. (It would also be nice to see privacy-breach-generic addressed.) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#910334: lintian: Please warn about redundant entries in Files-Excluded
Package: lintian Version: 2.5.107 Severity: wishlist Hi, Whilst we have: https://lintian.debian.org/tags/source-includes-file-in-files-excluded.html … which triggers when a file specified in the Files-Excluded field in debian/copyright exists in the source tree, we could also check for seemingly-redundant entries such as: Files-Excluded: ./file-does-not-exist This would catch typos and strange things such as #910330. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#910332: mtree-netbsd: Incomplete debian/copyright?
Source: mtree-netbsd Version: 20180822-2 Severity: serious Justication: Policy 12.5 X-Debbugs-CC: John Goerzen , ftpmas...@debian.org Hi, I just ACCEPTed mtree-netbsd from NEW but noticed it was missing attribution in debian/copyright for at least MIT, NetBSD, etc. This is in no way exhaustive so please check over the entire package carefully and address these on your next upload. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#910331: libnbcompat: Incomplete debian/copyright?
Source: libnbcompat Version: 20180822-1 Severity: serious Justication: Policy 12.5 X-Debbugs-CC: John Goerzen , ftpmas...@debian.org Hi, I just ACCEPTed libnbcompat from NEW but noticed it was missing attribution in debian/copyright for at least Todd Miller, Henry Spencer, Tobias Nygren, etc. This is in no way exhaustive so please check over the entire package carefully and address these on your next upload. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#910330: fswatch: Please clarify strange Files-Excluded entries
Source: fswatch Version: 1.13.0+repack-1 Severity: wishlist X-Debbugs-CC: Alf Gaida , ftpmas...@debian.org Hi, I just ACCEPTed fswatch from NEW but was wondering if you could clarify (in the package itself, not here) the strange Files-Excluded entries such as: __Remove_things_that_are_to_be_removed_by_debclean__ (eg. Why not use a regular comment? And, also, I wonder why we don't have a Lintian warning for this.) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#904653: python3-yowsup: fails to install with Python 3.7
On 26.07.18 Andreas Beckmann (a...@debian.org) wrote: Hi Josué, > during a test with piuparts I noticed your package failed to install. As > per definition of the release team this makes the package too buggy for > a release, thus the severity. > > From the attached log (scroll to the bottom...): > AFAICT you have already the fix on salsa fro 2 month. Would you be so kind to upload the fixed package to Debian? Thanks! -- sigmentation fault signature.asc Description: PGP signature
Bug#910329: golang-github-influxdata-influxql: Packaging cleanups
Source: golang-github-influxdata-influxql
Source-Version: 0.0~git20180330.145e067-2
Severity: normal
Tags: patch
Hi!
While backporting these packages I noticed some issue with the
packaging. Here's a couple of patches fixing them:
- Add golang-github-gogo-protobuf-dev as a first dependency
alternative.
- Remove incorrect shlibs:Depends substvars.
Thanks,
Guillem
From 6342140575eaeb7f7fc19d66d7038d2a0a35a2d8 Mon Sep 17 00:00:00 2001
From: Guillem Jover
Date: Thu, 4 Oct 2018 20:13:48 +0200
Subject: [PATCH 1/2] Add golang-github-gogo-protobuf-dev as a first dependency
alternative
The golang-gogoprotobuf-dev is a deprecated transitional package.
---
debian/control | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/debian/control b/debian/control
index 1af8918..5ef85d7 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Build-Depends: debhelper (>= 10),
dh-golang,
golang-any,
tzdata,
- golang-gogoprotobuf-dev
+ golang-github-gogo-protobuf-dev | golang-gogoprotobuf-dev,
Standards-Version: 4.1.1
Homepage: https://github.com/influxdata/influxql
Vcs-Browser: https://salsa.debian.org/go-team/packages/golang-github-influxdata-influxql
@@ -19,7 +19,7 @@ Package: golang-github-influxdata-influxql-dev
Architecture: all
Depends: ${shlibs:Depends},
${misc:Depends},
- golang-gogoprotobuf-dev
+ golang-github-gogo-protobuf-dev | golang-gogoprotobuf-dev,
Description: parser for the InfluxDB query language
Package influxql implements a parser for the InfluxDB query language.
.
--
2.19.0
From 657aeca2e06bee934721189958f221307b64bf7c Mon Sep 17 00:00:00 2001
From: Guillem Jover
Date: Thu, 4 Oct 2018 20:15:18 +0200
Subject: [PATCH 2/2] Remove incorrect shlibs:Depends substvars
This is an arch:all package.
---
debian/control | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index 5ef85d7..1deb459 100644
--- a/debian/control
+++ b/debian/control
@@ -17,9 +17,9 @@ Testsuite: autopkgtest-pkg-go
Package: golang-github-influxdata-influxql-dev
Architecture: all
-Depends: ${shlibs:Depends},
- ${misc:Depends},
- golang-github-gogo-protobuf-dev | golang-gogoprotobuf-dev,
+Depends:
+ ${misc:Depends},
+ golang-github-gogo-protobuf-dev | golang-gogoprotobuf-dev,
Description: parser for the InfluxDB query language
Package influxql implements a parser for the InfluxDB query language.
.
--
2.19.0
Bug#910328: golang-github-shirou-gopsutil: Missing version on Build-Depends
Source: golang-github-shirou-gopsutil Source-Version: 2.18.06-1 Severity: minor Tags: patch Hi! While locally backporting this package, noticed that it requires a newer golang-golang-x-sys-dev version, I've not checked exactly which one, but using the version from Buster is enough, so I went for that, perhaps you want to track the specific version down. Here's a proposed patch implementing this approximation. Thanks, Guillem diff --git i/debian/control w/debian/control index 0bea942..dfabcdb 100644 --- i/debian/control +++ w/debian/control @@ -9,7 +9,7 @@ Build-Depends: debhelper (>= 11), dh-golang (>= 1.17~), golang-any, golang-github-stretchr-testify-dev, - golang-golang-x-sys-dev, + golang-golang-x-sys-dev (>= 0.0~git20180510.7dfd129~), lsof, procps, Standards-Version: 4.1.4
Bug#910327: RFS: javapoet/1.11.1-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "javapoet": * Package name: javapoet Version : 1.11.1-1 Upstream Author : Square, Inc. * URL : https://github.com/square/javapoet * License : Apache-2.0 Section : java It builds those binary packages: libjavapoet-java - Java API for generating .java source files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/javapoet Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/j/javapoet/javapoet_1.11.1-1.dsc Changes since the last upload: * Initial release (Closes: #910313) Kind regards, Miroslav Kravec
Bug#908913: stretch-pu: package systemd/232-25+deb9u5
Hi Adam Am 04.10.18 um 21:19 schrieb Adam D. Barratt: > Please go ahead. Thanks a lot! Uploaded. Regards, 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#908796: udev (with sysvinit) fails to find devices at boot
Am 03.10.18 um 13:20 schrieb Trek: > > thanks to Bill Brelsford, the last test confirmed we are in the worst > situation: udev is running, the control file is created, but udev is > not ready to listen new events > > so we must to rethink about the 791944 bug: it was caused because udev > no longer removes the control file on stop > > we have at least three options to workaround it: > > 1) revert the 791944 patch, create a new init.d/udev-clear script to > remove the control file and run it just after sendsigs (this will > restore the old well tested behavior) The removal of the control file should be bound to the live time of the udev service, so splitting it off into a separate init script is not a good idea. > 2) revert the 791944 patch, remove the control file on stop in > init.d/udev, stop it after sendsigs and remove udev from the Should-Stop > header in any script, probably cryptdisks, mdadm and lvm2 (this could > break any script that depends on udev and not distributed by debian) If you revert 791944, i.e. don't add the pid file to /run/sendsigs.omit.d, the systemd-udevd process will be killed by the sendsigs init script. Which means there is a time window where /run/udev/control exists but no functional udev service. In other words, not a proper solution either. > 3) do not revert, but start with udevd --background and create the > pidfile using pidof udevd (this could break if there are more than one > process of udevd) As you already mentioned, an approach using pidof is not going to work. For one thing, containers are a thing nowadays (and some containers run udev), and second, udevd will spawn off worker processes. Using pidof you don't know which process you will actually get. > what do you think about? None of the above proposals does really solve the problem, unfortunately. Afaics this problem is unfortunately not really fixable with the limited facilities sysvinit/sysv-rc provides. I'm of course happy if someone proves me wrong. Regarding the changes that were made for #791944, I'm ok with reverting them, if you want me to. Which means we will simply break the boot for another set of (sysvinit) users. A proper solution might (emphasis on might, as I haven't checked this) be to teach start-stop-daemon about daemons using the sd-notify interface. This is a more elaborate fix, for sure, but everything else feels like an incomplete hack. 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#910013: modemmanager: new upstream release - 1.8.2
On Mon, Oct 1, 2018 at 7:09 AM SZ Lin wrote: > > Source: modemmanager > Version: 1.7.990-1 > Severity: wishlist > > Dear Maintainer, > > Please update modemmanager to latest release 1.8.2, > I am willing to offer my help in new version of packaging. > Thanks! This is already in progress (well, pretty much done, really). I'm waiting for my sponsor to review the package and upload it. Kindly, Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1
Bug#910326: parted: include sys/sysmacros.h missing for major(), minor()
Package: parted Version: 3.2-21 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu cosmic ubuntu-patch Dear Maintainer, parted 3.2-21 FTBFS in latest test rebuild on ubuntu. major() and minor() macros are being used without include sys/sysmacros.h, leading to undefined symbols at linking for these macros. In Ubuntu, the attached patch was applied to achieve the following: * debian/patches/sysmacros_for_major_minor.patch: include sys/sysmacros.h to account for the user of major() and minor() macros. Thanks for considering the patch. -- System Information: Debian Release: buster/sid APT prefers cosmic-security APT policy: (500, 'cosmic-security'), (500, 'cosmic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-7-generic (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru parted-3.2/debian/patches/series parted-3.2/debian/patches/series --- parted-3.2/debian/patches/series2018-04-09 07:15:46.0 -0400 +++ parted-3.2/debian/patches/series2018-10-04 14:45:21.0 -0400 @@ -27,3 +27,4 @@ libparted-dasd-add-test-cases-for-the-new-fdasd-func.patch fat-resize-long-path.patch fat-resize-retain-boot-code.patch +sysmacros_for_major_minor.patch diff -Nru parted-3.2/debian/patches/sysmacros_for_major_minor.patch parted-3.2/debian/patches/sysmacros_for_major_minor.patch --- parted-3.2/debian/patches/sysmacros_for_major_minor.patch 1969-12-31 19:00:00.0 -0500 +++ parted-3.2/debian/patches/sysmacros_for_major_minor.patch 2018-10-04 14:55:03.0 -0400 @@ -0,0 +1,19 @@ +From: Mathieu Trudel-Lapierre +Subject: Incldue sys/sysmacros.h for major() and minor() + +--- + libparted/arch/linux.c | 51 - + 1 file changed, 26 insertions(+), 25 deletions(-) + +Index: b/libparted/arch/linux.c +=== +--- a/libparted/arch/linux.c b/libparted/arch/linux.c +@@ -40,6 +40,7 @@ + #include + #include + #include /* for uname() */ ++#include /* for major(), minor() */ + #include + #include + #ifdef ENABLE_DEVICE_MAPPER
Bug#904302: Whether vendor-specific patch series should be permitted in the archive
On Thu, Oct 04, 2018 at 08:21:07PM +0200, Philip Hands wrote: >... > IMO policy should recomend the use of separate source packages as the > prefered solution to the problem that vendor-specific patch series were > supposed to address. In this case please make an explicit decision on whether build-time patching is the recommended replacement for vendor-specific patch series, or what kinds of build-time patching will no longer be permitted. The current situation in the archive is: - 18 packages with vendor-specific patch series - an unknown number of packages (e.g. src:gcc-8) that are doing vendor-specific build-time patching and/or patching based on other factors like architecture - > 100 packages that are doing patching and/or configuration based on dpkg-vendor - an unknown number of packages (e.g. src:gcc-8) that are doing patching and/or configuration based on other tools like lsb_release It is not clear at all which of the above exactly you want to have removed from the archive and moved as permanent deltas downstream. The status quo is that everything is permitted, which is a pretty clear situation. The TC was asked to make a decision, and a decision turning a clear situation into a blurry "it is permitted but kinda recommended against" would only create future conflicts. A 1:1 vendor-specific patch series -> build-time patching change would be a mostly technical change. As already said this could even be implemented before buster. If the TC wants to additionally change the status quo on the high-level question whether Debian wants permanent downstream deltas maintained in Debian or downstream, it should make an explicit decision on that. > Cheers, Phil. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#904302: Whether vendor-specific patch series should be permitted in the archive
Philip Hands writes ("Re: Bug#904302: Whether vendor-specific patch series
should be permitted in the archive"):
> IMO policy should recomend the use of separate source packages as the
> prefered solution to the problem that vendor-specific patch series were
> supposed to address.
That would be great. (I suspect that it is rather controversial,
though, even though I think it is obviously correct...)
If there is consensus in the TC that this is the best approach,
putting something about it in the TC resolution as a recommendation
would have about as much weight as putting it in policy, and avoid
jurisdictional questions.
Ian.
Bug#908474: stretch-pu: package zutils/1.5-5
Control: tags -1 + confirmed On Mon, 2018-09-10 at 11:16 +0200, Daniel Baumann wrote: > a buffer underrun has been fixed in zutils 1.7-3 (sid), here's an > updated package for stretch: > Please go ahead. Regards, Adam
Bug#910325: libdebian-installer: Build correctly with Werror=implicit-fallthrough
Package: libdebian-installer Version: 0.110 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu cosmic ubuntu-patch Dear Maintainer, it appears that libdebian-installer fails to build in our latest rebuild tests with GCC 7 -- implicit-fallthrough warning / error is in place, which means GCC will complain about src/tree.c's code for rotating trees when adding new nodes. The fix is pretty simple, as the code is straightforward. In Ubuntu, the attached patch was applied to achieve the following: * src/tree.c: Silence GCC's implicit-fallthrough warning by being explicit in this binary tree rotate code that there's not fallthrough; we're covering all tree rotation cases already (all paths in switch() already return(). Thanks for considering the patch. -- System Information: Debian Release: buster/sid APT prefers cosmic-security APT policy: (500, 'cosmic-security'), (500, 'cosmic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-7-generic (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru libdebian-installer-0.110ubuntu2/src/tree.c libdebian-installer-0.110ubuntu3/src/tree.c --- libdebian-installer-0.110ubuntu2/src/tree.c 2017-05-04 11:46:32.0 -0400 +++ libdebian-installer-0.110ubuntu3/src/tree.c 2018-10-04 14:22:53.0 -0400 @@ -198,6 +198,7 @@ case 1: return di_tree_node_rotate_right_double (node); } + break; case -1: case 0: case 1:
Bug#908958: stretch-pu: package xmotd/1.17.3b-9+deb9u1
Control: tags -1 + confirmed On Sun, 2018-09-16 at 21:45 +0300, Adrian Bunk wrote: > xmotd in stretch currently just crashes. Please go ahead. Regards, Adam
Bug#908956: stretch-pu: package gphoto2-cffi/0.3~a1-1.1~deb9u1
Control: tags -1 + confirmed On Sun, 2018-09-16 at 20:43 +0300, Adrian Bunk wrote: > python3-gphoto2cffi in stretch is currently completely > broken, just trying to import it fails: > Please go ahead. Regards, Adam
Bug#908893: stretch-pu: package globus-gsi-credential_7.11-1+deb9u1
Control: tags -1 + confirmed On Sat, 2018-09-15 at 17:19 +0200, Mattias Ellert wrote: > This is a proposed update to the globus-gsi-credential package in > Debian 9 (stretch). I have created it in response to a request that > was > sent to me via e-mail (included below). > [...] > https://github.com/globus/globus-toolkit/issues/115 > affecting cvmfs-x509-helper in Debian testing libglobus-gsi- > credential1 Please go ahead. Regards, Adam
Bug#807418: This bug applies to the Debian Buster firefox-esr package as well
I independently discovered this bug for firefox-esr (Version: 52.9.0esr-1 from Debian Buster) when comparing rsync results with and without the --checksum option. irwin@merlin> ls -l /usr/share/firefox-esr/browser/defaults/preferences total 100 -rw-r--r-- 1 root root 16101 Dec 31 2009 devtools.js -rw-r--r-- 1 root root 1738 Dec 31 2009 firefox-branding.js -rw-r--r-- 1 root root 72676 Dec 31 2009 firefox.js -rw-r--r-- 1 root root 238 Jun 26 15:29 vendor.js -rw-r--r-- 1 root root 2053 Dec 31 2009 webide-prefs.js And as previously explained the combination of those bad Dec 31 2009 dates on those files plus updates on three of them that only involve version numbers (so the length of the file is unchanged) is probablematic for rsync without the --checksum option. And most people avoid the --checksum option because it takes so much longer than running rsync without that option. Anyhow, I hope the availability of the "touch" fix that has been suggested before inspires someone from the team of maintainers for this package to fix this bug since giving the highest priority to all the easy bugs like this one should considerably simplify the list of outstanding bugs for firefox-esr. Alan __ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Bug#908913: stretch-pu: package systemd/232-25+deb9u5
Control: tags -1 + confirmed On Sat, 2018-09-15 at 21:49 +0200, Michael Biebl wrote: > I'd like to make a stable upload for systemd, fixing #901834: > systemd-networkd fails to start the network service because of race > condition to dbus > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901834 > > Full debdiff is attached, the changelog reads > > systemd (232-25+deb9u5) stretch; urgency=medium > > * networkd: Do not fail manager_connect_bus() if dbus is not active > yet > Please go ahead. Regards, Adam
Bug#909807: tomcat-native 1.2.12-2+deb9u2 flagged for acceptance
Control: tags -1 + pending Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: tomcat-native Version: 1.2.12-2+deb9u2 Explanation: fix OSCP responder issue that made it possible for users to authenticate with revoked certificates when using mutual TLS [CVE-2018-8019 CVE-2018-8020]
Bug#907899: mailman 2.1.23-1+deb9u4 flagged for acceptance
Control: tags -1 + pending Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: mailman Version: 2.1.23-1+deb9u4 Explanation: fix arbitrary text injection vulnerability in Mailman CGIs [CVE-2018-13796]
Bug#909526: dom4j 1.6.1+dfsg.3-2+deb9u1 flagged for acceptance
Control: tags -1 + pending Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: dom4j Version: 1.6.1+dfsg.3-2+deb9u1 Explanation: fix XML injection attack [CVE-2018-1000632]; compile with source/target 1.5 to fix a compilation issue with String.format
Bug#910324: freebayes parallel FTBFS
Source: freebayes Version: 1.2.0-1 Severity: serious Tags: ftbfs freebayes fails to build from source in sbuild on unstable/amd64 when performing a parallel build. The linker invocation is run before all relevant objects are compiled. A build log ends with: | g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -I../ttmath -I/usr/include/bamtools `pkg-config --cflags libvcflib` `pkg-config --cflags libseqlib` `pkg-config --cflags htslib` `pkg-config --cflags jsoncpp` bamleftalign.o BedReader.o CNV.o fastlz.o Fasta.o Parameters.o Allele.o Sample.o Result.o AlleleParser.o Utility.o Genotype.o DataLikelihood.o Multinomial.o Ewens.o ResultData.o Dirichlet.o Marginals.o split.o LeftAlign.o IndelAllele.o Bias.o Contamination.o NonCall.o SegfaultHandler.o -o ../bin/bamleftalign -lbamtools -ltabixpp -lz -lm -lpthread `pkg-config --libs libvcflib` `pkg-config --libs htslib` `pkg-config --libs libseqlib` `pkg-config --libs jsoncpp` | g++: error: AlleleParser.o: No such file or directory | g++: error: Genotype.o: No such file or directory | g++: error: ResultData.o: No such file or directory | make[2]: *** [Makefile:81: ../bin/bamleftalign] Error 1 | make[2]: *** Waiting for unfinished jobs | make[2]: Leaving directory '/<>/src' | make[1]: *** [Makefile:2: all] Error 2 | make[1]: Leaving directory '/<>' | dh_auto_build: make -j12 "INSTALL=install --strip-program=true" returned exit code 2 | make: *** [debian/rules:6: build] Error 2 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 The issue is also seen during reproducible builds: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/freebayes_1.2.0-1.rbuild.log.gz Helmut
Bug#910323: nmu: dovecot-antispam_2.0+20171229-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear Release Team, Please schedule a binNMU for dovecot-antispam to build against dovecot 2.3.3. Regards, Apollon nmu dovecot-antispam_2.0+20171229-1 . ANY . unstable . -m "Rebuild against dovecot 2.3.3" dw dovecot-antispam_2.0+20171229-1 . ANY . unstable . -m "dovecot-dev (>= 1:2.3.3-1)"
Bug#910322: foo2zjs hard codes location of stdio.h
Source: foo2zjs Version: 20171202dfsg0-1 Tags: patch upstream Control: block 798955 by -1 foo2zjs's Makefile hard codes the location of stdio.h. That breaks with non-glibc libcs and with a glibc that fixes #798955 as it will move stdlib.h to /usr/include//stdio.h. The attached patch removes the broken check and doing so is sufficient to make foo2zjs build again. Please consider applying the patch. Helmut --- foo2zjs-20171202dfsg0.orig/Makefile +++ foo2zjs-20171202dfsg0/Makefile @@ -399,15 +399,6 @@ echo " ***"; \ exit 1; \ fi - @if ! test -f /usr/include/stdio.h; then \ - echo " ***"; \ - echo " *** Error: /usr/include/stdio.h is not installed!"; \ - echo " ***"; \ - echo " *** Install Software Development (gcc) package"; \ - echo " *** for Ubuntu: sudo apt-get install build-essential"; \ - echo " ***"; \ - exit 1; \ - fi @if ! type gs >/dev/null 2>&1; then \ echo " ***"; \ echo " *** Error: gs is not installed!"; \
Bug#910255: libsane-common: error upgrading libsane-common (1.0.27-2) over (1.0.25-4.1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 tags 910255 + pending thanks Hello Michael, thank you for spending your time helping to make Debian better with this bug report. I have fixed your bug. The new release will be uploaded as soon as possible. CU Jörg - -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlu2YqUACgkQCfifPIyh 0l32rw/7BHZKyptl5VkiBTgqWqYV1syKifZNjYOuU6k4Iavz2AYUSbRIWtP29jK1 EOaoL+qVWzSACGQaWmKYxKk59MnHKPVcuQOVaLdD9T704VOg/GUzzKOJ3+m5g8UE ioH7fG1DEfV/wv2qv58Owuw9mmeAXW8Pe3wJDQxbrZglp+VX+JB5yfX542lnj80B 8ji5SR25mC+oIK6ubCT/YpTJauRtIE63ssWdjt/PpMM4O4zqdY/10A4hnXdA545M 5CI3lbgsTXQLH9smDX5XfbwqUwaGXgMEPJBqjvZUrSWfghXN4/lGt/K4MPdv2mDs kO64/8oGqeeIKq/TiO4D+/ZUMHpJRfpgHSuXDa2hiMSXlwrfBbFw4NckCWcgTs2S x65lud6FsKpejI54b4PQflW5BrNoOXUiFy/Wm5zptbWR0cCX6HNSMz78Io0ADqB4 UCw3kEQT+Pl8DBqyFOLZSaLbEgcdG8sKixBlHwNTvLX5C+uNtHNVgxcY1vDrA6p2 NqJllErDIAqKOytbFGYjBoGXTkN7hydlDSLFi2hXrPNww8b5EGxbzE63J2P063F/ yeR0Ce7jF9Qo18cclOolOvMc/IRfS4D7cG8hA80WHLOo4tJT8WWWRyTUANA/WQmi L9Wy8CmoeJwx5+LI1NItgH/91ibmVlaF2ucqpGblJMx2cmFTmZ4= =8hyb -END PGP SIGNATURE-
Bug#910309: RFS: mercurial-keyring/1.2.0-1 [RC]
On Thu, 4 Oct 2018 at 19:18, Christoph Mathys wrote: > > Package: sponsorship-requests > Severity: important > > Dear mentors, > > I am looking for a sponsor for my package "mercurial-keyring" > > * Package name: mercurial-keyring > Version : 1.2.0-1 > Upstream Author : Marcin Kasperski > * URL : http://pypi.python.org/pypi/mercurial_keyring > * License : BSD-3-clause > Section : python > > It builds those binary packages: > > mercurial-keyring - Mercurial Keyring Extension > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/mercurial-keyring > > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/m/mercurial-keyring/mercurial-keyring_1.2.0-1.dsc > > More information about mercurial-keyring can be obtained from > http://pypi.python.org/pypi/mercurial_keyring > > Changes since the last upload: > >* New upstream release (Closes: #909004) >* Bump compat to 11 without changes. >* Bump std version to 4.2.1 without changes. Hi, I can sponsor this. -- Cheers, Andrej
Bug#909852: linux-image-4.18-0-0.bpo.1-amd64: backtrace in dmesg after suspend
Package: src:linux Version: 4.18.6-1~bpo9+1 Followup-For: Bug #909852 Dear Maintainer, I tried to suspend the system today and it resulted with a backtrace after waking the system. The dmesg shows that amdgpu is involved with this backtrace. It looks to me it has trouble to resume. Interesting thing is that if i suspend/resume the first time after boot, the backtrace appears. This first attempt was aproximatly two hours after system boot. But if i do it again then the suspend/resume performs correctly. This event doesn not affect the system as whole, only this message in dmesg. Thank you for your time and i hope this helps debian to better stability. -- Package-specific info: ** Version: Linux version 4.18.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.18.6-1~bpo9+1 (2018-09-13) ** Command line: BOOT_IMAGE=/vmlinuz-4.18.0-0.bpo.1-amd64 root=/dev/mapper/debian--stretch-root ro quiet ** Tainted: WO (4608) * Taint on warning. * Out-of-tree module has been loaded. ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: System manufacturer product_name: System Product Name product_version: System Version chassis_vendor: Default string chassis_version: Default string bios_vendor: American Megatrends Inc. bios_version: 3401 board_vendor: ASUSTeK COMPUTER INC. board_name: PRIME A320M-K board_version: Rev X.0x ** Loaded modules: pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) xt_tcpudp xt_conntrack iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter binfmt_misc dm_thin_pool dm_persistent_data amdkfd dm_bio_prison dm_bufio libcrc32c eeepc_wmi asus_wmi sparse_keymap rfkill wmi_bmof amdgpu edac_mce_amd kvm_amd snd_hda_codec_realtek ccp snd_hda_codec_generic chash gpu_sched snd_hda_codec_hdmi rng_core snd_hda_intel ttm kvm snd_hda_codec drm_kms_helper snd_hda_core irqbypass drm snd_hwdep snd_pcm evdev pcspkr sg serio_raw crct10dif_pclmul crc32_pclmul snd_timer ghash_clmulni_intel snd i2c_algo_bit soundcore fam15h_power k10temp sp5100_tco video wmi button pcc_cpufreq acpi_cpufreq parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb sr_mod cdrom dm_mod hid_generic uas usbhid usb_storage hid sd_mod crc32c_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper ahci xhci_pci libahci i2c_piix4 xhci_hcd libata r8169 scsi_mod mii usbcore usb_common gpio_amdpt gpio_generic ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:1576] Subsystem: ASUSTeK Computer Inc. Device [1043:8719] Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Carrizo [1002:9874] (rev e2) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Carrizo [1043:8719] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: amdgpu Kernel modules: amdgpu 00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Kabini HDMI/DP Audio [1002:9840] Subsystem: ASUSTeK Computer Inc. Kabini HDMI/DP Audio [1043:8719] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:157b] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:157b] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:09.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:157d] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI
Bug#907719: libtirpc 0.2.5-1.2+deb9u1 flagged for acceptance
Control: tags -1 + pending Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: libtirpc Version: 0.2.5-1.2+deb9u1 Explanation: rendezvous_request: check the makefd_xprt return value [CVE-2018-14622]
Bug#910321: sludge FTCBFS: does not pass --host to ./configure
Source: sludge Version: 2.2.2-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap sludge fails to cross build from source, because it attempts to perform a native build by not passing any --host flag. The easiest way of fixing that is using dh_auto_configure. After doing so, sludge cross builds successfully. Please consider applying the attached patch. Helmut diff --minimal -Nru sludge-2.2.2/debian/changelog sludge-2.2.2/debian/changelog --- sludge-2.2.2/debian/changelog 2018-09-18 19:57:35.0 +0200 +++ sludge-2.2.2/debian/changelog 2018-10-04 20:36:26.0 +0200 @@ -1,3 +1,10 @@ +sludge (2.2.2-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1) + + -- Helmut Grohne Thu, 04 Oct 2018 20:36:26 +0200 + sludge (2.2.2-1) unstable; urgency=medium * New upstream release (Closes: #880853, #908352). diff --minimal -Nru sludge-2.2.2/debian/rules sludge-2.2.2/debian/rules --- sludge-2.2.2/debian/rules 2018-09-18 17:27:13.0 +0200 +++ sludge-2.2.2/debian/rules 2018-10-04 20:36:24.0 +0200 @@ -6,7 +6,7 @@ dh $@ override_dh_auto_configure: - ./configure --prefix=/usr --datadir=/usr/share --enable-engine --enable-devkit --enable-doc + dh_auto_configure -- --datadir=/usr/share --enable-engine --enable-devkit --enable-doc override_dh_auto_build: xsltproc --nonet \
Bug#904302: Whether vendor-specific patch series should be permitted in the archive
Ian Jackson writes:
> Adrian Bunk writes ("Bug#904302: Whether vendor-specific patch series should
> be permitted in the archive"):
>> On Wed, Sep 19, 2018 at 02:39:23PM +0200, Philip Hands wrote:
>> > The Committee therefore resolves that:
>> >
>> > 1. Any use of dpkg's vendor-specific patch series feature is a bug for
>> > packages in the Debian archive (including contrib and non-free),
>>
>> This misses an important part of the previous proposal:
>
> I think Phil was just intending to leave the recitals part alone, and
> proposing only a change to the operative part - not to delete the
> recitals.
Correct -- sorry if that wasn't clear.
>> The Committee recognises that there is a need for packages to behave
>> differently when built on different distributions, but this should be
>> done as part of the build process, using current and future practices
>> such as patches with conditional behaviour, patching of files during the
>> build, rather than at source unpacking time.
>
> However, now that we are talking about the recitals I would like to
> suggest that the recitals should include *maintaining different source
> packages in different distributions* as one of the suggested options.
>
> IMO it is far superior to patches which are conditional (at runtime or
> at build-time) on dpkg-vendor and I would not like to see that
> perpetuated.
As you say, a separate source package seems like the right way to deal
with this situation.
IMO policy should recomend the use of separate source packages as the
prefered solution to the problem that vendor-specific patch series were
supposed to address.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Bug#910319: fast-histogram FTBFS: fast_histogram/_histogram_core.c:1:10: fatal error: Python.h: No such file or directory
Source: fast-histogram
Version: 0.4-1
Severity: serious
fast-histogram fails to build from source in sbuild on unstable/amd64. A
build log ends with:
|dh_auto_build -O--buildsystem=pybuild
| I: pybuild base:217: /usr/bin/python3.7 setup.py build
| running build
| running build_py
| creating
/<>/.pybuild/cpython3_3.7_fast-histogram/build/fast_histogram
| copying fast_histogram/__init__.py ->
/<>/.pybuild/cpython3_3.7_fast-histogram/build/fast_histogram
| copying fast_histogram/histogram.py ->
/<>/.pybuild/cpython3_3.7_fast-histogram/build/fast_histogram
| creating
/<>/.pybuild/cpython3_3.7_fast-histogram/build/fast_histogram/tests
| copying fast_histogram/tests/test_histogram.py ->
/<>/.pybuild/cpython3_3.7_fast-histogram/build/fast_histogram/tests
| copying fast_histogram/tests/__init__.py ->
/<>/.pybuild/cpython3_3.7_fast-histogram/build/fast_histogram/tests
| running build_ext
| building 'fast_histogram._histogram_core' extension
| creating build
| creating build/temp.linux-amd64-3.7
| creating build/temp.linux-amd64-3.7/fast_histogram
| x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
-I/usr/include/python3.7m -I/usr/lib/python3/dist-packages/numpy/core/include
-c fast_histogram/_histogram_core.c -o
build/temp.linux-amd64-3.7/fast_histogram/_histogram_core.o
| fast_histogram/_histogram_core.c:1:10: fatal error: Python.h: No such file or
directory
| #include
| ^~
| compilation terminated.
| error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
| E: pybuild pybuild:338: build: plugin distutils failed with: exit code=1:
/usr/bin/python3.7 setup.py build
| dh_auto_build: pybuild --build -i python{version} -p "3.7 3.6" returned exit
code 13
| make: *** [debian/rules:9: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
It also fails to build during reproducible tests:
https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/fast-histogram_0.4-1.rbuild.log.gz
Helmut
Bug#910320: ITP: jiconfont-font-awesome -- jIconFont - Font Awesome
Package: wnpp Severity: wishlist Owner: Markus Koschany * Package name: jiconfont-font-awesome Version : 4.7.0.0 Upstream Author : Cadu Andrade * URL : https://github.com/jIconFont/jiconfont-font_awesome * License : MIT, SIL-OFL 1.1 Programming Lang: Java Description : jIconFont - Font Awesome jIconFont is an API to provide icons generated from any IconFont. These icons can be used in Java GUI toolkits, such as Swing and JavaFX. This package provides support for the Font Awesome icon font.
Bug#910318: factory-boy FTBFS: RuntimeError: generator raised StopIteration
Source: factory-boy
Version: 2.8.1-2
Severity: serious
Tags: ftbfs
factory-boy fails to build from source in sbuild on unstable/amd64. A
build ends with:
| ==
| ERROR: test_reset_after_end (tests.test_utils.ResetableIteratorTestCase)
| --
| Traceback (most recent call last):
| File "/<>/factory/utils.py", line 158, in __iter__
| value = next(self.iterator)
| StopIteration
|
| The above exception was the direct cause of the following exception:
|
| Traceback (most recent call last):
| File "/<>/tests/test_utils.py", line 343, in
test_reset_after_end
| self.assertRaises(StopIteration, next, iterator)
| File "/usr/lib/python3.7/unittest/case.py", line 743, in assertRaises
| return context.handle('assertRaises', args, kwargs)
| File "/usr/lib/python3.7/unittest/case.py", line 178, in handle
| callable_obj(*args, **kwargs)
| RuntimeError: generator raised StopIteration
|
| --
| Ran 381 tests in 0.311s
|
| FAILED (errors=2, skipped=30)
| Test failed:
| Creating test database for alias 'default'...
| Creating test database for alias 'replica'...
| Destroying test database for alias 'default'...
| Destroying test database for alias 'replica'...
| Creating test database for alias 'default'...
| Creating test database for alias 'replica'...
| Destroying test database for alias 'default'...
| Destroying test database for alias 'replica'...
| Creating test database for alias 'default'...
| Creating test database for alias 'replica'...
| Destroying test database for alias 'default'...
| Destroying test database for alias 'replica'...
| Creating test database for alias 'default'...
| Creating test database for alias 'replica'...
| Destroying test database for alias 'default'...
| Destroying test database for alias 'replica'...
| error: Test failed:
| make[1]: *** [debian/rules:33: override_dh_auto_test] Error 1
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:12: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
Wild guess: It didn't test on Python 3.7 earlier.
Helmut
Bug#910316: erlang-ranch FTBFS: src/ranch_ssl.erl:128: ssl:ssl_accept/2: deprecated; use ssl:handshake/2 instead
Source: erlang-ranch Version: 1.3.0-1 Severity: serious Tags: ftbfs erlang-ranch fails to build from source using sbuild on unstable/amd64. A build log ends with: |debian/rules override_dh_auto_build | make[1]: Entering directory '/<>' | make SKIP_DEPS=yes | make[2]: Entering directory '/<>' | DEPEND ranch.d | ERLC ranch.erl ranch_acceptor.erl ranch_acceptors_sup.erl ranch_app.erl ranch_conns_sup.erl ranch_listener_sup.erl ranch_protocol.erl ranch_server.erl ranch_ssl.erl ranch_sup.erl ranch_tcp.erl ranch_transport.erl | compile: warnings being treated as errors | src/ranch_ssl.erl:128: ssl:ssl_accept/2: deprecated; use ssl:handshake/2 instead | make[3]: *** [erlang.mk:5069: ebin/ranch.app] Error 1 | make[2]: *** [erlang.mk:4872: app] Error 2 | make[2]: Leaving directory '/<>' | make[1]: *** [debian/rules:10: override_dh_auto_build] Error 2 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:7: build] Error 2 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 This is also seen by reproducible builds: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/erlang-ranch_1.3.0-1.rbuild.log.gz Helmut
Bug#910317: QtWebEngine in unstable is constantly crashing
Package: python3-pyqt5.qtwebengine
Version: 5.11.2+dfsg-1
Severity: serious
X-Debbugs-CC: debian-qt-...@lists.debian.org
Control: affects -1 + libqt5webengine5
Dear Debian Qt/KDE maintainers and pyqt5.qtwebengine maintainers,
Current QtWebEngine in Debian Unstable would easily crash. That
happens after recent upgrade of libkf5.
For example, run the following script under python3:
$ export LC_ALL=C.UTF-8
$ export LANG=C
$ cat ./test.py
import sys
from PyQt5.QtWidgets import QApplication
from PyQt5.QtWidgets import QMainWindow
from PyQt5.QtWebEngineWidgets import QWebEngineView
from PyQt5.QtCore import QUrl
def main():
app = QApplication(sys.argv)
window = QMainWindow()
window.setWindowTitle('PyQt Demo')
window.setGeometry(320, 180, 960, 540)
view = QWebEngineView()
view.load(QUrl('http://leafletjs.com/')) # error here
window.setCentralWidget(view)
window.show()
sys.exit(app.exec_())
if __name__ == '__main__':
main()
$ python3 ./test.py
[1004/140404.438632:WARNING:stack_trace_posix.cc(699)] Failed to open
file: /tmp/.glBfSxZo (deleted)
Error: No such file or directory
[8494:8515:1004/140404.647050:ERROR:nss_util.cc(727)] After loading
Root Certs, loaded==false: NSS error code: -8018
Received signal 11 SEGV_MAPERR 0010
#0 0x7fc98c03e76e
#1 0x7fc98c03e880
#2 0x7fc98c03eeb7
#3 0x7fc9969db8e0
#4 0x7fc990771604
#5 0x7fc98aa8d660
#6 0x7fc98aabde3c
#7 0x7fc98a0af500 QQuickWindowPrivate::updateDirtyNode()
#8 0x7fc98a0af963 QQuickWindowPrivate::updateDirtyNodes()
#9 0x7fc98a0b0e22 QQuickWindowPrivate::syncSceneGraph()
#10 0x7fc98a16ce49 QQuickRenderControl::sync()
#11 0x7fc989c7e0c6
#12 0x7fc989c7e2a6
#13 0x7fc994b0003b QObject::event()
#14 0x7fc99548ac6b QWidget::event()
#15 0x7fc989c81e2d QQuickWidget::event()
#16 0x7fc990771bf0
#17 0x7fc99544c4a1 QApplicationPrivate::notify_helper()
#18 0x7fc995453ae0 QApplication::notify()
#19 0x7fc995d1f11e
#20 0x7fc994ad6589 QCoreApplication::notifyInternal2()
#21 0x7fc994b27648 QTimerInfoList::activateTimers()
#22 0x7fc994b27ea4
#23 0x7fc9939acc3e g_main_context_dispatch
#24 0x7fc9939aced8
#25 0x7fc9939acf6c g_main_context_iteration
#26 0x7fc994b28233 QEventDispatcherGlib::processEvents()
#27 0x7fc97df51ee1
#28 0x7fc994ad525b QEventLoop::exec()
#29 0x7fc994add3d2 QCoreApplication::exec()
#30 0x7fc995ce214b
#31 0x005068bf
#32 0x0050a4e9 _PyEval_EvalFrameDefault
#33 0x00505d58
#34 0x00506a8d
#35 0x0050a4e9 _PyEval_EvalFrameDefault
#36 0x005088b8
#37 0x0050a023 PyEval_EvalCode
#38 0x00635f82
#39 0x0063603a PyRun_FileExFlags
#40 0x006397f8 PyRun_SimpleFileExFlags
#41 0x0063a38a Py_Main
#42 0x004ac090 main
#43 0x7fc996433b17 __libc_start_main
#44 0x005b35aa _start
r8: 17281b04 r9: 017ae3e0 r10: 17281b04
r11: 0001
r12: r13: 017651c0 r14: 7fc994b91660
r15: 017650e0
di: 01728da0 si: bp: 7ffc01652bc0
bx: 01713dd0
dx: 7fc994b91660 ax: 01082000 cx: 7fc994b91678
sp: 7ffc016527e0
ip: 7fc990771604 efl: 00010202 cgf: 002b0033
erf: 0004
trp: 000e msk: cr2: 0010
[end of stack trace]
Calling _exit(1). Core file will not be generated.
$
--
Thanks,
Boyuan Yang
Bug#910315: zita-ajbridge FTCBFS: hard codes the build architecture compiler
Source: zita-ajbridge Version: 0.7.0-1 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap zita-ajbridge fails to cross build from source, because source/Makefile hard codes the build architecture compiler g++. After making it substitutable, zita-ajbridge cross builds successfully. Please consider applying the attached patch. Helmut --- zita-ajbridge-0.7.0.orig/source/Makefile +++ zita-ajbridge-0.7.0/source/Makefile @@ -40,7 +40,7 @@ zita-a2j: CPPFLAGS += -DAPPNAME=\"zita-a2j\" zita-a2j: LDLIBS += -lzita-resampler -lzita-alsa-pcmi -ljack -lasound -lpthread -lm -lrt zita-a2j: $(ZITA-A2J_O) - g++ $(LDFLAGS) -o $@ $(ZITA-A2J_O) $(LDLIBS) + $(CXX) $(LDFLAGS) -o $@ $(ZITA-A2J_O) $(LDLIBS) ZITA-J2A_O = zita-j2a.o alsathread.o jackclient.o pxthread.o lfqueue.o @@ -49,7 +49,7 @@ zita-j2a: CPPFLAGS += -DAPPNAME=\"zita-j2a\" zita-j2a: LDLIBS += -lzita-resampler -lzita-alsa-pcmi -ljack -lasound -lpthread -lm -lrt zita-j2a: $(ZITA-J2A_O) - g++ $(LDFLAGS) -o $@ $(ZITA-J2A_O) $(LDLIBS) + $(CXX) $(LDFLAGS) -o $@ $(ZITA-J2A_O) $(LDLIBS) #zita-ajbridge.1.gz: zita-ajbridge.1
Bug#901761: Not installable at amd64 because of libgcj17 dependency
On 2018-10-04 19:33, Johann Felix Soden wrote: > On 03.10.2018 11:17 Andreas Beckmann wrote: > >> Rather pdftk-java should take over the pdftk binary package, s.t. there >> is an upgrade path. (A Provides: pdftk does not create an upgrade path). >> That should make the old pdftk source package go away ... > > My plan for the upgrade path was to release pdftk 2.02-3 as an > transition package that depends on pdftk-java. That would work as well, especially if you have some hope left that pdktk upstream will resurrect it some day. There just needs to be an installable pdftk package to provide a clean upgrade path ... Andrea
Bug#910280: pandoc: Please reduce the binary size
Jonas Smedegaard writes: > The proper solution here, I guess (but am not expert in Haskell so may > be wrong) is to switch to using shared linking, so that 5 Haskell > binaries will not consume 5 x the disk space of the parts reused among > them. Yes, in theory. But this didn't work well in practice when arch linux tried it. It meant that installing pandoc forced installation of a very large number of dynamic libraries, and people really didn't like this. https://www.reddit.com/r/haskell/comments/6jj8ha/whats_going_on_in_archlinux_pandoc_requires_1gb/
Bug#910314: ITP: jiconfont-swing -- jIconFont - Swing support
Package: wnpp Severity: wishlist Owner: Markus Koschany * Package name: jiconfont-swing Version : 1.0.1 Upstream Author : Cadu Andrade * URL : https://github.com/jIconFont/jiconfont-swing * License : MIT Programming Lang: Java Description : jIconFont - Swing support jIconFont is an API to provide icons generated from any IconFont. This package provides icon support for the Swing Java GUI toolkit.
Bug#910313: ITP: javapoet -- Java library for generating .java source files
Package: wnpp Severity: wishlist Owner: kravec.miros...@gmail.com * Package name: javapoet Version : 1.11.1 Upstream Author : Square, Inc. * URL : https://github.com/square/javapoet * License : Apache-2.0 Programming Lang: Java Description : Java library for generating .java source files JavaPoet is a Java API for generating .java source files. Source file generation can be useful when doing things such as annotation processing or interacting with metadata files (e.g., database schemas, protocol formats). By generating code, you eliminate the need to write boilerplate while also keeping a single source of truth for the metadata. Maven: https://mvnrepository.com/artifact/com.squareup/javapoet
Bug#910303: Xdvi stoped showing emedded EPS figures after updating ghostscript
Control: tag -1 patch Control: forwarded -1 http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=19ebb5f Quoting Serguei DACHIAN (2018-10-04 19:30:46) > I don't know how to make the problem appear directly with Ghostscript, > but here is a typycal output from xdvi: [...] > After googling a bit, I find out that exactly the same problem already > appeared (approximately at the same time, in September) in ubuntu and > the solutions are more or less known, cf. > https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/1793742 > > Hope this helps, and thank you once more. That looks helpful indeed. @Moritz, it seems the stable update need the referenced patch. Can you please include that? And thanks a lot for handling those many CVEs! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#884635: Linphone block
Hi, Before removing Linphone, please have a look at the kopete patch I posted yesterday. [1] Thank you! Kind regards, Felix Lechner [1] https://bugs.debian.org/890606#48
Bug#910312: erlang-jose FTBFS: erlang:get_stacktrace/0: deprecated; use the new try/catch syntax for retrieving the stack backtrace
Source: erlang-jose
Version: 1.8.4-3
Severity: serious
Tags: ftbfs
erlang-jose fails to build from source in sbuild on unstable/amd64. A
build log ends with:
| Compiled src/jose_server.erl
| Compiled src/jose_jwt.erl
| Compiled src/jose_sha3_keccakf1600_nif.erl
| Compiled src/jose_jwk_kty_oct.erl
| Compiled src/jose_jwk_kty_okp_ed448.erl
| src/jose_public_key.erl:44: erlang:get_stacktrace/0: deprecated; use the new
try/catch syntax for retrieving the stack backtrace
| src/jose_public_key.erl:60: erlang:get_stacktrace/0: deprecated; use the new
try/catch syntax for retrieving the stack backtrace
| src/jose_public_key.erl:84: erlang:get_stacktrace/0: deprecated; use the new
try/catch syntax for retrieving the stack backtrace
| src/jose_public_key.erl:107: erlang:get_stacktrace/0: deprecated; use the new
try/catch syntax for retrieving the stack backtrace
| src/jose_public_key.erl:122: erlang:get_stacktrace/0: deprecated; use the new
try/catch syntax for retrieving the stack backtrace
| src/jose_public_key.erl:234: erlang:get_stacktrace/0: deprecated; use the new
try/catch syntax for retrieving the stack backtrace
| Compiling src/jose_public_key.erl failed:
| DEBUG: Worker compilation failed: {{error,
| {error,[],
| [["src/jose_public_key.erl:44:
erlang:get_stacktrace/0: deprecated; use the new try/catch syntax for
retrieving the stack backtrace\n",
|"src/jose_public_key.erl:60:
erlang:get_stacktrace/0: deprecated; use the new try/catch syntax for
retrieving the stack backtrace\n",
|"src/jose_public_key.erl:84:
erlang:get_stacktrace/0: deprecated; use the new try/catch syntax for
retrieving the stack backtrace\n",
|"src/jose_public_key.erl:107:
erlang:get_stacktrace/0: deprecated; use the new try/catch syntax for
retrieving the stack backtrace\n",
|"src/jose_public_key.erl:122:
erlang:get_stacktrace/0: deprecated; use the new try/catch syntax for
retrieving the stack backtrace\n",
|"src/jose_public_key.erl:234:
erlang:get_stacktrace/0: deprecated; use the new try/catch syntax for
retrieving the stack backtrace\n"]]}},
|{source,"src/jose_public_key.erl"}}
| ERROR: compile failed while processing /<>: rebar_abort
| make[1]: *** [/usr/share/dh-rebar/make/dh-rebar.Makefile:126: rebar_compile]
Error 1
| dh_auto_build: make --no-print-directory -f
/usr/share/dh-rebar/make/dh-rebar.Makefile build returned exit code 2
| make: *** [debian/rules:11: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
Helmut
Bug#905411: New list creation: debian-fundraising
On Wed, 03 Oct 2018, Louis-Philippe Véronneau wrote: > On 2018-10-03 1:30 p.m., Hanno 'Rince' Wagner wrote: > > Hi Louis-Philippe! > > > > On Wed, 29 Aug 2018, Louis-Philippe Véronneau wrote: > > > >> Any news regarding the creation of this ML? > >> > >> I know you said 'This has to be discussed within the team.', but it's > >> been a month and it's hard to go forward with this project if we don't > >> have a platform to discuss on... > > > > I am sorry that this has been delayed. > > > >> Is the answer to our request of a closed ML from listmasters is a strait > >> 'No'? > > > > our experience is that closed lists make much more work than it is > > worth. I do not know your reasoning for a closed list - just > > confidentiality or more - but we would prefer an open list since this > > is just easier to maintain. > > > >> If that is the only blocker for the creation of that mailing list, I > >> guess we can work on an open ML for now. I don't think we'll be dealing > >> with sponsors directly for the next year anyway. > > > > Okay, then If you agree to this, I can create that list without an > > archive. so please confirm that the list can be open. > > > > best regards, Hanno Wagner, Listmaster of the day > > > > I don't think we will discuss confidential sponsor infos on that list > for now, as we are only starting the process. > > An open list without archive thus suits me just fine. > > Thanks for your work maintaining the lists! By the way, what differentates that list from debconf-sponsoring? Why do you need two lists that do more or less the same? Alex signature.asc Description: PGP signature
Bug#910305: easyloggingpp FTBFS: configure: error: cannot find install-sh, install.sh, or shtool in build-aux ".."/build-aux
Am 04.10.2018 um 18:53 schrieb Helmut Grohne:
> Source: easyloggingpp
> Version: 9.96.5+dfsg-1
> Severity: serious
> Tags: ftbfs
>
> easyloggingpp fails to build from source in unstable. The build log
> essentially looks like this:
>
> | dpkg-buildpackage: info: source package easyloggingpp
> | dpkg-buildpackage: info: source version 9.96.5+dfsg-1
> | dpkg-buildpackage: info: source distribution unstable
> | dpkg-buildpackage: info: source changed by Stephen Kitt
> | dpkg-source --before-build .
> | dpkg-buildpackage: info: host architecture amd64
> | debian/rules clean
> | dh clean
> |dh_clean
> | debian/rules binary
> | dh binary
> |dh_update_autotools_config
> |dh_autoreconf
> |debian/rules override_dh_auto_configure
> | make[1]: Entering directory '/<>'
> | mkdir gtest-build
> | cp -a /usr/src/googletest/googletest gtest-source
> | dh_auto_configure -Dgtest-source -Bgtest-build
> | cd gtest-build && ../gtest-source/configure
> --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include
> --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
> --sysconfdir=/etc --localstatedir=/var --disable-silent-rules
> --libdir=\${prefix}/lib/x86_64-linux-gnu
> --libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
> --disable-maintainer-mode --disable-dependency-tracking
> | configure: WARNING: unrecognized options: --disable-maintainer-mode
> | configure: error: cannot find install-sh, install.sh, or shtool in
> build-aux ".."/build-aux
> | cd gtest-build && tail -v -n \+0 config.log
> | ==> config.log <==
> | ...
> | dh_auto_configure: cd gtest-build && ../gtest-source/configure
> --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include
> --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
> --sysconfdir=/etc --localstatedir=/var --disable-silent-rules
> --libdir=\${prefix}/lib/x86_64-linux-gnu
> --libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
> --disable-maintainer-mode --disable-dependency-tracking returned exit code 1
> | make[1]: *** [debian/rules:13: override_dh_auto_configure] Error 2
> | make[1]: Leaving directory '/<>'
> | make: *** [debian/rules:7: binary] Error 2
> | dpkg-buildpackage: error: debian/rules binary subprocess returned exit
> status 2
>
> This looks like some dependency changed possibly debhelper or autoconf
> or something.
Almost certainly it is has been triggered by the recent upload of
googletest, since the gtest-source directory is just a copy (via cp -a)
of /usr/src/googletest/googletest. Looks like that googletest upload
broke out-of-tree builds.
Cheers,
Sven
Bug#901761: Not installable at amd64 because of libgcj17 dependency
On 03.10.2018 11:17 Andreas Beckmann wrote: > Rather pdftk-java should take over the pdftk binary package, s.t. there > is an upgrade path. (A Provides: pdftk does not create an upgrade path). > That should make the old pdftk source package go away ... My plan for the upgrade path was to release pdftk 2.02-3 as an transition package that depends on pdftk-java. Currently, pdftk-java is the only working alternative, but maybe upstream or someone else finds another way to solve the GCJ issue... >From my perspective, providing the pdftk binary package in pdftk-java seems to be a bit misleading, since the upstream is different. (The pdftk binary itself is currently provided by update-alternatives in pdftk-java) What do you think, Andreas? Best wishes, Johann Felix -- Johann Felix Soden, joh...@debian.org, DD
Bug#910311: elpy FTBFS randomly: test elpy-promise-wait-should-return-early-for-resolved-promise fails
Source: elpy
Version: 1.24.0-1
Severity: serious
Tags: ftbfs
elpy fails to build from source randomly. A build log contains:
| Test elpy-promise-wait-should-return-early-for-resolved-promise backtrace:
| (if (unwind-protect (setq value-774 (apply fn-772 args-773)) (setq f
| (let (form-description-776) (if (unwind-protect (setq value-774 (app
| (let ((value-774 (quote ert-form-evaluation-aborted-775))) (let (for
| (let ((fn-772 (function elpy-promise-resolved-p)) (args-773 (list pr
| (let ((start-time (current-time)) (promise (elpy-promise nil))) (run
| (progn (let ((start-time (current-time)) (promise (elpy-promise nil)
| (progn (setq elpy-rpc-timeout 100) (progn (let ((start-time (current
| (unwind-protect (progn (setq elpy-rpc-timeout 100) (progn (let ((sta
| (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn
| (let ((temp-buffer (generate-new-buffer " *temp*"))) (save-current-b
| (progn (let ((temp-buffer (generate-new-buffer " *temp*"))) (save-cu
| (unwind-protect (progn (let ((temp-buffer (generate-new-buffer " *te
| (let ((old-process-list (process-list)) (old-buffer-list (buffer-lis
| (lambda nil (let ((old-process-list (process-list)) (old-buffer-list
| ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
| ert-run-test([cl-struct-ert-test elpy-promise-wait-should-return-ear
| ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test e
| ert-run-tests(t #[385 "\306^B\307\"\203G^@\211\211G\310U\203^T^@\211@\20
| ert-run-tests-batch(nil)
| ert-run-tests-batch-and-exit()
| eval((ert-run-tests-batch-and-exit))
| command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
| command-line()
| normal-top-level()
| Test elpy-promise-wait-should-return-early-for-resolved-promise condition:
| (ert-test-failed
| ((should
|(elpy-promise-resolved-p promise))
| :form
| (elpy-promise-resolved-p
|[*elpy-promise* nil nil # nil])
| :value nil))
|FAILED 222/362 elpy-promise-wait-should-return-early-for-resolved-promise
This happened in sbuild on unstable/amd64.
The reproducible builds folks encountered the same failure in one out of
two builds using pbuilder:
https://tests.reproducible-builds.org/debian/logs/unstable/amd64/elpy_1.24.0-1.build2.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/elpy_1.24.0-1.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/elpy_1.24.0-1.rbuild.log.gz
For amd64, only the second build failed. When I tried it locally in
sbuild, three builds succeeded. I have no clue how the failure is
caused, but it is evident that it is not broken infrastructure.
Helmut
Bug#910280: pandoc: Please reduce the binary size
Control: tag -1 wontfix Hi Горбешко, Quoting Горбешко Богдан (2018-10-04 13:02:59) > the pandoc binary is extremely large. It's the largest file in my > /usr/bin, exceeding even blender's binary in almost 2 times. > > From my experience, ghc is not good at making small binaries, and > even stripping doesn't do much. However UPX does it's job great on > binaries produced by ghc. I tried compressing pandoc in --best mode > and achieved 14% compression (from 141M to 20M); however the > compression took more than an hour on my system. > > If you are afraid of performance decreasing that may arise because of > UPXing, you can make pandoc a virtual package, pointing by default to > a non-compressed real package, but providing a compressed real package > as well, for those who care about disk space. I agree that the binary is big, but I disagree with shipping a compressed binary - even as an alternative only. Reason Pandoc is big is that it is statically linked. If statically linked with FFmpeg, Boost, Cairo, Mesa, GDAL, GTK+, HDF4, HDF5, Lapack, etc., Blender would be much much larger than Pandoc. Providing a compressed binary will just shift the burden elsewhere, and providing as alternative shifts the burden to the distribution mirrors. The proper solution here, I guess (but am not expert in Haskell so may be wrong) is to switch to using shared linking, so that 5 Haskell binaries will not consume 5 x the disk space of the parts reused among them. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#909779: vows: Cannot find module 'glob'
Control: severity -1 wishlist Control: retitle -1 vows: Should give more sensible error when unable to find /proc/self/fd/1 I got some help from Sunil, and we managed to track down this issue to the simple fact that my chroot did not have /proc/ mounted, and this caused vows to fail to find any javascript library. It would be nice if vows mentioned its inability to find /proc/self/fd/1 instead of complaining that glob is missing. -- Happy hacking Petter Reinholdtsen
Bug#910309: RFS: mercurial-keyring/1.2.0-1 [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "mercurial-keyring" * Package name: mercurial-keyring Version : 1.2.0-1 Upstream Author : Marcin Kasperski * URL : http://pypi.python.org/pypi/mercurial_keyring * License : BSD-3-clause Section : python It builds those binary packages: mercurial-keyring - Mercurial Keyring Extension To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mercurial-keyring Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mercurial-keyring/mercurial-keyring_1.2.0-1.dsc More information about mercurial-keyring can be obtained from http://pypi.python.org/pypi/mercurial_keyring Changes since the last upload: * New upstream release (Closes: #909004) * Bump compat to 11 without changes. * Bump std version to 4.2.1 without changes. Regards, Christoph Mathys
Bug#910308: ITP: jiconfont -- API to provide icons generated by any icon font
Package: wnpp Severity: wishlist Owner: Markus Koschany * Package name: jiconfont Version : 1.0.0 Upstream Author : jiconfont * URL : https://github.com/jIconFont/jiconfont * License : MIT Programming Lang: Java Description : API to provide icons generated by any icon font jIconFont is an API to provide icons generated from any IconFont. These icons can be used in Java GUI toolkits, such as Swing and JavaFX. Create your own icon fonts or use some of the existing ones like Elusive, Entypo, Font Awesome, Google Material Design Icons, Open Iconic or Typicons. This is a new dependency for mediathekview.
Bug#910310: RFS: mercurial-extension-utils/1.3.6-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "mercurial-extension-utils" * Package name: mercurial-extension-utils Version : 1.3.6-1 Upstream Author : Marcin Kasperski * URL : http://pypi.python.org/pypi/mercurial_extension_utils * License : BSD-3-clause Section : python It builds those binary packages: mercurial-extension-utils - Contains functions for writing Mercurial extensions. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mercurial-extension-utils Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mercurial-extension-utils/mercurial-extension-utils_1.3.6-1.dsc More information about mercurial-extension-utils can be obtained from http://pypi.python.org/pypi/mercurial_extension_utils Changes since the last upload: * New upstream release. * Bump compat to 11 without changes. * Increase std version to 4.2.1 without changes. Regards, Christoph Mathys
Bug#910307: elixir-lang FTBFS: tests fail: Killed
Source: elixir-lang
Version: 1.6.5-1
Severity: serious
Tags: ftbfs
elixir-lang fails to build from source in sbuild on unstable/amd64. A
build log ends with:
| 5) test translates :supervisor_bridge progress (Logger.TranslatorTest)
| test/logger/translator_test.exs:751
| Assertion with =~ failed
| code: assert capture_log(:info, fn ->
| trap = Process.flag(:trap_exit, true)
| {:ok, pid} = :supervisor_bridge.start_link(MyBridge, :normal)
| receive() do
| {:EXIT, ^pid, _} ->
| :ok
| end
| Process.flag(:trap_exit, trap)
| end) =~ ~r"\\[info\\] Child of Supervisor
#PID<\\d+\\.\\d+\\.\\d+> \\(Logger\\.TranslatorTest\\.MyBridge\\) started\nPid:
#PID<\\d+\\.\\d+\\.\\d+>\nStart Call:
Logger.TranslatorTest.MyBridge.init\\(:normal\\)\n"
| left: ""
| right: ~r/\[info\] Child of Supervisor #PID<\d+\.\d+\.\d+>
\(Logger\.TranslatorTest\.MyBridge\) started\nPid: #PID<\d+\.\d+\.\d+>\nStart
Call: Logger.TranslatorTest.MyBridge.init\(:normal\)\n/
| stacktrace:
|test/logger/translator_test.exs:752: (test)
|
| =INFO REPORT 4-Oct-2018::17:13:59.511859 ===
| application: logger
| exited: stopped
| type: temporary
| .
|
| Finished in 0.7 seconds (0.3s on load, 0.4s on tests)
| 1 doctest, 109 tests, 5 failures
|
| Randomized with seed 183795
| make[2]: *** [Makefile:92: test_logger] Error 1
| make[2]: Leaving directory '/<>'
| dh_auto_test: make -j18 test returned exit code 2
| epmd: Thu Oct 4 17:13:59 2018: got KILL_REQ - terminates normal
|
| Killed
| make[1]: *** [debian/rules:12: override_dh_auto_test] Error 2
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:9: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
It also fails on the reproducible builds infrastructure:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/elixir-lang_1.6.5-1.rbuild.log.gz
Helmut
