Bug#1071575: dahdi-dkms: module fails to build for Linux 6.8.9: error: implicit declaration of function 'strlcpy'
Hi, On Mon, May 27, 2024 at 10:26:45AM +0200, Diederik de Haas via Pkg-voip-maintainers wrote: > Control: tag -1 upstream fixed-upstream patch Thanks for that. Just one note regarding the word "upstream". The current upstream of the package is the osmo fork. At the time when uploading previous version, that fork was looking more reliable than the main branch. This bug and its fix finally proves that the main Sangoma repo is the one to follow. Note to self: remove version.patch . -- mail / xmpp / matrix: tzaf...@cohens.org.il
Bug#1057734: dahdi-dkms: Update to v3.3.0 and re-enable wctdm for TDM400P hardware
Hi, On Thu, Dec 07, 2023 at 10:16:14AM -0800, Russ Dill wrote: > > I lost support for my TDM400P when updating to v3.1.0 as upstream had removed > the wctdm module. v3.3.0 brings it back, so an update to that version along > with re-enabling the module in dkms.conf.in would be greatly appreciated. The downside is that switching to it will remove support of some Junghanns-like BRI cards. I'll keep them supported for now in patches as they are trivial, but I really don't have the hardware to test it. Right now Digium seems slightly better maintained than the osmocom fork, but that fork seems to add some interesting hardware (and recent hardware is probably more useful). Furthermore, they are currently based on Debian, and I'd like to make it simpler for them to reduce the diff from Debian (although I have not seen such an effort from their side). So, anyone who actually uses: * Junghanns-like cards (including OpenVox BRI) * ZapHFC-based single-port PCI BRI cards * OSMOCom E1 USB device Please speak up! -- mail / xmpp / matrix: tzaf...@cohens.org.il
Bug#1042747: dahdi-dkms: dkms.conf still lists removed pciradio.ko
Hi, Thanks. Those modules were removed. I noticed that and fixed it locally (also added two extra modules zaphfc and icE1usb). Trying to figure out the cause for the other error https://ci.debian.net/data/autopkgtest/testing/amd64/d/dahdi-linux/36220583/log.gz 177s MODPOST /usr/src/modules/dahdi/drivers/dahdi/Module.symvers 178s ERROR: modpost: "unregister_hdlc_device" [/usr/src/modules/dahdi/drivers/dahdi/dahdi.ko] undefined! 178s ERROR: modpost: "ppp_unregister_channel" [/usr/src/modules/dahdi/drivers/dahdi/dahdi.ko] undefined! 178s ERROR: modpost: "ppp_unit_number" [/usr/src/modules/dahdi/drivers/dahdi/dahdi.ko] undefined! 178s ERROR: modpost: "alloc_hdlcdev" [/usr/src/modules/dahdi/drivers/dahdi/dahdi.ko] undefined! 178s ERROR: modpost: "ppp_channel_index" [/usr/src/modules/dahdi/drivers/dahdi/dahdi.ko] undefined! 178s ERROR: modpost: "ppp_register_channel" [/usr/src/modules/dahdi/drivers/dahdi/dahdi.ko] undefined! 178s ERROR: modpost: "hdlc_close" [/usr/src/modules/dahdi/drivers/dahdi/dahdi.ko] undefined! 178s ERROR: modpost: "hdlc_start_xmit" [/usr/src/modules/dahdi/drivers/dahdi/dahdi.ko] undefined! 178s ERROR: modpost: "ppp_input" [/usr/src/modules/dahdi/drivers/dahdi/dahdi.ko] undefined! 178s ERROR: modpost: "ppp_input_error" [/usr/src/modules/dahdi/drivers/dahdi/dahdi.ko] undefined! 178s WARNING: modpost: suppressed 3 unresolved symbol warnings because there were too many) 178s make[4]: *** [/usr/src/linux-headers-6.4.0-1-common/scripts/Makefile.modpost:136: /usr/src/modules/dahdi/drivers/dahdi/Module.symvers] Error 1 178s make[3]: *** [/usr/src/linux-headers-6.4.0-1-common/Makefile:2003: modpost] Error 2 > While updating d/dkms.conf.in, you can probably drop CONFIG_PCI from > BUILD_EXCLUSIVE_CONFIG (and update the comment) CONFIG_PCI is a pre-condition to just about any DAHDI card there except the USB devices (see drivers/dahdi/Kbuild). Will update comment. > and > switch from BUILD_EXCLUSIVE_KERNEL=...(regex)... to the more readable > BUILD_EXCLUSIVE_KERNEL_MIN="5.6" (supported since dkms in trixie). I want to make the job for backporters easy, so I'll avoid this feature for now. -- Tzafrir -- mail / xmpp / matrix: tzaf...@cohens.org.il
Bug#1029710: emacs-gtk: emacs uses Noto Rashi font for Hebrew
Package: emacs-gtk
Version: 1:28.2+1-10
Severity: normal
Tags: l10n
Dear Maintainer,
To reproduce:
1. Install fonts-noto-core
2. Start Emacs
3. Press 'C-h h' to show the sample Muliligual page
How to tell the difference:
The Rashi script is not that different from normal printed Hebrew for
most letters. Some letters are different. In case of the sample text,
one letter is noticably different:
The right-most character of that line on the script is the letter Shin.
See the shape of normal print Hebrew vs. the cursive form and the Rashi
one in:
https://en.wikipedia.org/wiki/Shin_(letter)#Hebrew_Shin_/_Sin
When I pres 'C-u C-x =' I get:
position: 1734 of 3715 (47%), column: 42
character: ש (displayed as ש) (codepoint 1513, #o2751, #x5e9)
charset: unicode (Unicode (ISO10646))
code point in charset: 0x05E9
script: hebrew
syntax: wwhich means: word
category: .:Base, R:Strong R2L
to input: type "C-x 8 RET 5e9" or "C-x 8 RET HEBREW LETTER SHIN"
buffer code: #xD7 #xA9
file code: #xD7 #xA9 (encoded by coding system utf-8-unix)
display: composed to form "שָׁ" (see below)
Composed with the following character(s) "ָׁ" using this font:
ftcrhb:-GOOG-Noto Rashi Hebrew-normal-normal-normal-*-15-*-*-*-*-0-iso10646-1
by these glyphs:
[0 2 1473 53 0 0 4 -1 4 [3 0 0]]
[0 2 1464 67 0 0 2 11 -9 [5 0 0]]
[0 2 1513 66 8 0 8 10 1 nil]
with these character(s):
ָ (#x5b8) HEBREW POINT QAMATS
ׁ (#x5c1) HEBREW POINT SHIN DOT
Character code properties: customize what to show
name: HEBREW LETTER SHIN
general-category: Lo (Letter, Other)
decomposition: (1513) ('ש')
Rashi is generally an older cursive script of Hebrew. It was once used in
handwritten letters (I have some letters written in it that are less than
100 years old). Nowadays it is mostly known for its use in some parts of a
Talmud page.
So I see here two issues:
1. does Noto Rashi Hebrew belong in the core set? Rashi is not useful
for daily Hebrew usage. It does not add coverage of new code points, AFAIK.
2. I should never get Rashi by default for Hebrew.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64
Kernel: Linux 6.0.0-6-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IL.UTF-8, LC_CTYPE=en_IL.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IL:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages emacs-gtk depends on:
ii emacs-bin-common 1:28.2+1-10
ii emacs-common 1:28.2+1-10
ii libacl1 2.3.1-3
ii libasound2 1.2.8-1+b1
ii libc62.36-8
ii libcairo21.16.0-7
ii libdbus-1-3 1.14.4-1
ii libfontconfig1 2.14.1-3
ii libfreetype6 2.12.1+dfsg-4
ii libgccjit0 12.2.0-14
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii libgif7 5.2.1-2.5
ii libglib2.0-0 2.74.4-1
ii libgmp10 2:6.2.1+dfsg1-1.1
ii libgnutls30 3.7.8-4
ii libgpm2 1.20.7-10+b1
ii libgtk-3-0 3.24.36-1
ii libharfbuzz0b6.0.0-1
ii libice6 2:1.0.10-1
ii libjansson4 2.14-2
ii libjpeg62-turbo 1:2.1.2-1+b1
ii liblcms2-2 2.14-1+b1
ii libm17n-01.8.0-5
ii libotf1 0.9.16-3+b1
ii libpango-1.0-0 1.50.12+ds-1
ii libpng16-16 1.6.39-2
ii librsvg2-2 2.54.5+dfsg-1
ii libselinux1 3.4-1+b4
ii libsm6 2:1.2.3-1
ii libsystemd0 252.4-1
ii libtiff6 4.5.0-3
ii libtinfo66.4-1
ii libx11-6 2:1.8.3-3
ii libxext6 2:1.3.4-1+b1
ii libxfixes3 1:6.0.0-2
ii libxml2 2.9.14+dfsg-1.1+b2
ii libxrender1 1:0.9.10-1.1
ii zlib1g 1:1.2.13.dfsg-1
Versions of packages emacs-gtk recommends:
ii fonts-noto-color-emoji 2.038-1
Versions of packages emacs-gtk suggests:
pn emacs-common-non-dfsg
-- no debconf information
Bug#1025460: ITP: mock -- Build rpm packages inside a chroot
Package: wnpp Severity: wishlist Owner: Tzafrir Cohen X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: mock Version : 3.5 Upstream Author : Pavel Raiskup * URL : https://github.com/rpm-software-management/mock * License : GPL-2+ Programming Lang: Python Description : Build rpm packages inside a chroot Mock creates chroots and builds rpms in them. Its only task is to reliably populate a chroot and attempt to build a package in that chroot. It is used be the Fedora Extras project to build their packages cleanly. Mock was previously included in Debian and was removed due to python2 removal. It was repackaged by Juri Grabowski and should probably be maintained by the pkg-rpm-team. See current packaging in https://salsa.debian.org/gratuxri/mock
Bug#1015971: ITP: pamixer -- pulseaudio command line mixer
Package: wnpp Severity: wishlist Owner: Tzafrir Cohen X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pamixer Version : 1.6 Upstream Author : Clément Démoulins * URL : https://github.com/cdemoulins/pamixer * License : GPL-3+ Programming Lang: C++ Description : pulseaudio command line mixer pamixer is like amixer but for pulseaudio. It can control the volume levels of the sinks. It is used by the SXMO mobile phone interface, an ITP to follow shortly. It will be packaged in the debian namespace on Salsa: https://salsa.debian.org/debian/pamixer
Bug#1015891: ITP: wayout -- Wayland desktop widgets from standard input text
Package: wnpp Severity: wishlist Owner: Tzafrir Cohen X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: wayout Version : 0.1.2 Upstream Author : Leon Plickat Maarten van Gompel * URL : https://git.sr.ht/~proycon/wayout * License : GPLv3 Programming Lang: C Description : Wayland desktop widgets from standard input text Wayout takes text from standard input and outputs it to a desktop-widget on Wayland desktops. Periodic updates are supported; e.g. newline separated input or any other delimiter of choice. This is called a *feed*. The desktop widget can be shown either on top (OSD-like functionality) or below other windows. Needed as a dependency for the SXMO mobile phone interface (ITP coming). Will be packages through the swaywm team. Packaging is available at https://salsa.debian.org/swaywm-team/wayout .
Bug#955803: ITP: bemenu -- Dynamic menu inspired by dmenu
Hi, I need bemenu for packaging of SXMO (soon to submit an ITP). I adapted and updated packaging and it is currently at: https://salsa.debian.org/tzafrir/bemenu Can I push this to https://salsa.debian.org/swaywm-team/bemenu ? I also intend to package: * wayout: Wayland desktop widgets from standard input text https://salsa.debian.org/tzafrir/wayout * lisgd: libinput synthetic gesture daemon https://salsa.debian.org/tzafrir/lisgd Do those packages also fit this team? -- mail / xmpp / matrix: tzaf...@cohens.org.il
Bug#1012316: dahdi-dkms: fails to build modules for Linux 5.17
There are tons of warnings The actual error is: On Fri, Jun 03, 2022 at 10:23:00PM +0200, Andreas Beckmann wrote: > /var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-7.5/build/drivers/dahdi/xpp/xbus-core.c: > In function 'xbus_read_proc_open': > /var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-7.5/build/drivers/dahdi/xpp/xbus-core.c:1841:50: > error: implicit declaration of function 'PDE_DATA'; did you mean > 'NODE_DATA'? [-Werror=implicit-function-declaration] > 1841 | return single_open(file, xbus_proc_show, PDE_DATA(inode)); > | ^~~~ > | NODE_DATA that is also used in several other places in the code. Need to use pde_data() in 5.17. I wrote a patch, and then noticed that the build also fails with 5.18: CC [M] /home/tzafrirc/Proj/Salsa/pkg-voip/dahdi-linux/dahdi-linux/drivers/dahdi/wctdm.o /home/tzafrirc/Proj/Salsa/pkg-voip/dahdi-linux/dahdi-linux/drivers/dahdi/wctdm.c: In function ‘wctdm_init_one’: /home/tzafrirc/Proj/Salsa/pkg-voip/dahdi-linux/dahdi-linux/drivers/dahdi/wctdm.c:2657:21: error: implicit declaration of function ‘pci_alloc_consistent’ [-Werror=implicit-function-declaration] 2657 |wc->writechunk = pci_alloc_consistent(pdev, DAHDI_MAX_CHUNKSIZE * 2 * 2 * 2 * 4, &wc->writedma); | ^~~~ /home/tzafrirc/Proj/Salsa/pkg-voip/dahdi-linux/dahdi-linux/drivers/dahdi/wctdm.c:2657:19: warning: assignment to ‘volatile unsigned int *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 2657 |wc->writechunk = pci_alloc_consistent(pdev, DAHDI_MAX_CHUNKSIZE * 2 * 2 * 2 * 4, &wc->writedma); | ^ /home/tzafrirc/Proj/Salsa/pkg-voip/dahdi-linux/dahdi-linux/drivers/dahdi/wctdm.c:2677:5: error: implicit declaration of function ‘pci_free_consistent’ [-Werror=implicit-function-declaration] 2677 | pci_free_consistent(pdev, DAHDI_MAX_CHUNKSIZE * 2 * 2 * 2 * 4, (void *)wc->writechunk, wc->writedma); | ^~~ cc1: some warnings being treated as errors BTW: as of two days ago or so, the official git repository and potentially maybe also the bug tracker for dahdi-linux and dahdi-tools are in Github: https://github.com/asterisk/dahdi-linux https://github.com/asterisk/dahdi-tools I'm not completely sure what this means about requirements for CLA. -- mail / xmpp / matrix: tzaf...@cohens.org.il
Bug#1008818: why is this rpm's fault?
On Mon, Apr 18, 2022 at 06:32:07PM +0200, Thomas Lange wrote: > > On Mon, 18 Apr 2022 16:16:18 +0300, Peter Pentchev > > said: > > > > If you run sudo without the "set_home" option, thus making it preserve > > the HOME environment variable, rpm run as root with HOME set to > > /home/something will indeed do the wrong thing. > I have no set_home entry in /etc/sudoers and everything in > /etc/sudo.conf is commented out. > > Here's a test: > > As normal user > $ export HOME=/tmp/b > $ sudo rpm -qa > > This still creates /root/.rpmdb > and not > /tmp/b/.rpmdb $ HOME=/tmp/b sudo rpm -q rpm; ls -a /tmp/b package rpm is not installed ls: cannot access '/tmp/b': No such file or directory $ HOME=/tmp/b sudo -E rpm -q rpm; ls -a /tmp/b package rpm is not installed . .. .rpmdb -- mail / xmpp / matrix: tzaf...@cohens.org.il
Bug#1005715: dahdi-linux: autopkgtest suggests breakage due to new linux kernel
See patch in https://issues.asterisk.org/jira/browse/DAHLIN-397 -- mail / xmpp / matrix: tzaf...@cohens.org.il
Bug#983474: ipp-usb: breaks scanning with HP Deskjet 5275
On 24/02/2021 22:06, Till Kamppeter wrote: You could install sane-airscan. This is an extra SANE backend which provides more sophisticated support for driverless scanning (scanning with ipp-usb, "IPP over USB" always uses driverless scanning and printing standards). Classic drivers (as HPLIP's "hpaio" work only without ipp-usb. Thanks. Installed sane-airscan and now scanimage --device 'airscan:e0:HP DeskJet 5200 series [FC8002] (USB)' # worked. Remmed-out hpaio in /etc/sane.d/dll.d/hplip and now all's well. -- Tzafrir
Bug#983474: ipp-usb: breaks scanning with HP Deskjet 5275
Package: ipp-usb Version: 0.9.17-1 Severity: normal Dear Maintainer, I recenty realised I cannot scan with my scanner (part of a multi-function printer/scanner HP Deskjet 5275). Disabling ipp-usb enabled scanning. With ipp-usb running: $ time scanimage -L device `escl:http://127.0.0.1:6' is a HP DeskJet 5200 series [FC8002] (USB) flatbed scanner device `hpaio:/usb/DeskJet_5200_series?serial=TH8A86C27C' is a Hewlett-Packard DeskJet_5200_series all-in-one real0m7.483s user0m0.102s sys 0m0.087s $ time scanimage -x 100 -y 100 --format=tiff >image.tiff scanimage: open of device escl:http://127.0.0.1:6 failed: Out of memory real0m7.511s user0m0.117s sys 0m0.109s $ time scanimage --device 'hpaio:/usb/DeskJet_5200_series?serial=TH8A86C27C' -x 100 -y 100 --format=tiff >image.tiff scanimage: open of device hpaio:/usb/DeskJet_5200_series?serial=TH8A86C27C failed: Error during device I/O real0m0.051s user0m0.037s sys 0m0.013s With ipp-usb stopped: $ time scanimage -L device `hpaio:/usb/DeskJet_5200_series?serial=TH8A86C27C' is a Hewlett-Packard DeskJet_5200_series all-in-one real0m7.528s user0m0.139s sys 0m0.103s $ time scanimage -x 100 -y 100 --format=tiff >image.tiff real0m9.892s user0m0.165s sys 0m0.105s $ identify image.tiff image.tiff TIFF 295x295 295x295+0+0 1-bit Bilevel Gray 11125B 0.000u 0:00.000 $ dpkg-query -W sane-utils libsane1 libsane1:amd64 1.0.31-4 sane-utils 1.0.31-4 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_IL, LC_CTYPE=en_IL (charmap=UTF-8), LANGUAGE=en_IL:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ipp-usb depends on: ii avahi-daemon 0.8-5 ii libavahi-client3 0.8-5 ii libavahi-common3 0.8-5 ii libc6 2.31-9 ii libusb-1.0-0 2:1.0.24-2 ipp-usb recommends no packages. ipp-usb suggests no packages. -- no debconf information
Bug#982389: dahdi-dkms: installer package must be in contrib
This script is part of the separate non-free dahdi-firmware package. It should not be part of DAHDI-linux and can be removed if it is. If dahdi-dkms is not co-installable with dahdi-firmware, it is probably a bug. -- Tzafrir
Bug#969072: dahdi-tools FTBFS on armel/mipsel/hppa/powerpc: pre-grohtml: fatal error: cannot create temporary file: File exists
Hi, On abel in a armel chroot the issue is reproduced by running: man -Thtml even on an empty man page. Right now you can try: $ schroot -r -c session:tzafrir-dahdi-tools -- man -Thtml ~tzafrir/test.8 >/dev/null pre-grohtml: fatal error: cannot create temporary file: File exists man: command exited with status 1: /usr/lib/man-db/zsoelim | /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl | groff -mandoc -Thtml Not reproduced in a armhf chroot there or in a qemu armel chroot on my laptop. -- Tzafrir
Bug#949863: #949863: please enable CONFIG_NET_SWITCHDEV
Hi, A patch for fix of the regression is in 4.19.145 (commit 044be307e550b4532960eadabfb6942de96751f0 "net/mlx5e: Don't support phys switch id if not in switchdev mode"). Please enable CONFIG_NET_SWITCHDEV once this is merged to the Buster kernel tree. -- Tzafrir
Bug#957470: FTBFS Bugs in Debian revdeps dahdi-tools and libpri
On 19/08/2020 12:31, Bernhard Schmidt wrote: Hi Tzafrir, could you have a look at Bug#957117 and #957470? They are causing Asterisk to be removed from testing. Uploaded a fix for dahdi-tools. As for libpri: this is basically using index from data[0] that is the end of the header. My "fix" is to silence those checks (see patches). There hopefully seems to be some upstream work, but I'm not sure how long it would take. -- Tzafrir ~/Proj/Salsa/pkg-voip/libpri/libpri/libpri-gerrit ~/Proj/Salsa/hpc/perftest/perftest ~/Proj/Salsa/pkg-voip/libpri/libpri/libpri-gerrit diff --git a/Makefile b/Makefile index 077b8bf..825a6fe 100644 --- a/Makefile +++ b/Makefile @@ -70,6 +70,7 @@ CFLAGS ?= -g CFLAGS += $(CPPFLAGS) CFLAGS += -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes CFLAGS += -fPIC $(ALERTING) $(LIBPRI_OPT) $(COVERAGE_CFLAGS) +CFLAGS += -Wno-zero-length-bounds -Wno-stringop-overflow INSTALL_PREFIX=$(DESTDIR) INSTALL_BASE=/usr libdir?=$(INSTALL_BASE)/lib
Bug#952061: Info received (Bug#952061: ibsim: FTBFS: umad2sim.c:110:30: error: ‘UMAD_DEV_DIR’ undeclared here (not in a function))
Hi, I had little time to work on this, but as it happened, I submitted a pull request with deb packaging (internal) to the Github project and tested its building. It builds indeed fine with rdma-core, it seems. -- Tzafrir
Bug#949863: Info received (#949863: please enable CONFIG_NET_SWITCHDEV)
Hi, > Also: please consider this change for inclusion in a stable update, if > possible. I see that this was merged into git. Thanks. What are the chances of this fix getting included into Debian 10.4 to allow OVS off-loading there? Thanks, -- Tzafrir
Bug#952061: ibsim: FTBFS: umad2sim.c:110:30: error: ‘UMAD_DEV_DIR’ undeclared here (not in a function)
ibsim moved to Github. The specific error seems to have been fixed by https://github.com/linux-rdma/ibsim/commit/7bf171bab9c8bf3cc6c8f822bfcbd85570ca9abc The warning: likely fixed by https://github.com/linux-rdma/ibsim/commit/8625a69de7a319a0a1f3e4c86a0f14eda7e1612c Latest version there is 0.9 . TODO: update the package. -- Tzafrir
Bug#949863: #949863: please enable CONFIG_NET_SWITCHDEV
Also: please consider this change for inclusion in a stable update, if possible. Thanks
Bug#949863: #949863: please enable CONFIG_NET_SWITCHDEV
Update: adding CONFIG_NET_SWITCHDEV adds the following extra config items (amd64, checked kernels 5.4 and 5.4): CONFIG_MLX5_ESWITCH=y CONFIG_MLX5_SW_STEERING=y CONFIG_NFP_APP_FLOWER=y CONFIG_NFP_APP_ABM_NIC=y The following two are added but disabled by default. # CONFIG_MSCC_OCELOT_SWITCH is not set # CONFIG_ROCKER is not set CONFIG_NET_SWITCHDEV is currently only enabled on armhf . I believe it should be enabled on all architectures. -- Tzafrir On 26/01/2020 11:21, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 949863: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949863. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian Kernel Team > > If you wish to submit further information on this problem, please > send it to 949...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. >
Bug#949863: linux: wishlist
Source: linux Version: Please enable switchdev support Severity: wishlist Dear Maintainer, When testing our networking-related hardware on various platforms, One feature that we miss in the Debian kernel is switchdev support: This is useful for us for switchdev hardware offloading with our hardware. Could ypu please set: CONFIG_NET_SWITCHDEV=y -- Tzafrir
Bug#934384: libvma: FTBFS: some symbols or patterns disappeared
On 10/08/2019 17:46, Niko Tyni wrote: > Source: libvma > Version: 8.8.1.really.8.7.7-1 > Severity: serious > Tags: ftbfs > > This package fails to build on current sid/amd64. > >>From my build log: > > dpkg-gensymbols: warning: some new symbols appeared in the symbols file: > see diff output below > dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols > file: see diff output below > dpkg-gensymbols: warning: debian/libvma8/DEBIAN/symbols doesn't match > completely debian/libvma8.symbols > --- debian/libvma8.symbols (libvma8_8.8.1.really.8.7.7-1_amd64) > +++ dpkg-gensymbolsBhlY4G 2019-08-10 14:41:41.948238949 + > @@ -542,7 +542,7 @@ > _ZN12sockinfo_tcp2rxE9rx_call_tP5ioveclPiP8sockaddrPjP6msghdr@Base > 8.8.1.really.8.7.7 > _ZN12sockinfo_tcp2txE9tx_call_tPK5iovecliPK8sockaddrj@Base > 8.8.1.really.8.7.7 > > _ZN12sockinfo_tcp30create_flow_tuple_key_from_pcbER10flow_tupleP7tcp_pcb@Base > 8.8.1.really.8.7.7 > - _ZN12sockinfo_tcp30return_reuse_buffers_postponedEv@Base > 8.8.1.really.8.7.7 > +#MISSING: 8.8.1.really.8.7.7-1# > _ZN12sockinfo_tcp30return_reuse_buffers_postponedEv@Base 8.8.1.really.8.7.7 > _ZN12sockinfo_tcp4bindEPK8sockaddrj@Base 8.8.1.really.8.7.7 > _ZN12sockinfo_tcp5fcntlEim@Base 8.8.1.really.8.7.7 > _ZN12sockinfo_tcp5ioctlEmm@Base 8.8.1.really.8.7.7 > [...] > dh_makeshlibs: failing due to earlier errors > make: *** [debian/rules:15: binary] Error 255 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit > status 2 > Sorry for the delay. Working on this and will have a fix this week. -- Tzafrir
Bug#935582: dahdi: dahdi_genconf fail with .../spantype: No such file or directory
On 24/08/2019 10:49, Petter Reinholdtsen wrote: > > Package: dahdi > Version: 1:2.11.1-3 > Severity: important > > I am trying to set up Asterisk on Debian Buster, and discovered that > dahdi_genconf do not work, possibly because 'dahdi_span_assignments > list' fail. I believe that this is https://bugs.debian.org/cgi-bin/916577 . Could you please test this with the Bullseye package (I believe you should be able to install it as-is on the Buster system)? -- Tzafrir
Bug#914022: libnice: rejected incoming Skype for Business calls to pidgin-sipe: please package 0.1.6
tags 914022 + patch thanks Update: with the the git snapshot I had a working system, but it crashed all too often. I recently built libnice 0.1.16 (upgraded the packaging) and it now seems to be more stable. Please see https://salsa.debian.org/telepathy-team/libnice/merge_requests/2 . -- Tzafrir
Bug#924276: unblock: dahdi-linux/1:2.11.1.0.20170917~dfsg-7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package dahdi-linux * Fix of a serius bug (#923983) * An autopkgtest that works (the existing one was failing) and that checks more functionality. * Many smaller packaging fixes. I initially intended version 1:2.11.1.0.20170917~dfsg-6 to meet the soft freeze deadline and hence included in it a number of cleanups. Apart from those trivial changes, the only real change in the package itself (rather than the tests) was the addition of the script /usr/share/dahdi/dahdi/dahdi-modules that I used extensively in my own private packages and consider well-tested. The upload triggered a bug due to hardwired scripts. I fixed this (no bug filed). I also realised that the tests were not working properly when run in the test bed (I only tried them manually before). Fixed one and did what I could for the other. So sadly there are quite a few changes. But I don't want to see this package removed, as this would force the removal of asterisk as well. -- Tzafrir Debdiff: diff -Nru dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog --- dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog 2018-10-12 14:35:56.0 +0300 +++ dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog 2019-03-10 15:49:50.0 +0200 @@ -1,3 +1,31 @@ +dahdi-linux (1:2.11.1.0.20170917~dfsg-7) unstable; urgency=medium + + * dkms: use standard scripts (Closes: #923983). + * work around #923983 at upgrade time. + * Use dh_dkms instead of dh --with dkms, for the m-a -generated package. + * Standard version 4.3.0. + * More comprehensive and robust autopkgtest tests. +- The dkms-modules test is skippable for now. + * debian/dahdi-dkms.install is a generated file. + * dkms metainfo: same license as source. + + -- Tzafrir Cohen Sun, 10 Mar 2019 15:49:50 +0200 + +dahdi-linux (1:2.11.1.0.20170917~dfsg-6) unstable; urgency=medium + + * install dahdi-modules + * A new test: dynamic-loc-call + * dkms: also install oct612 module (Closes: #922008) + * dkms test: try loading all modules + * Rules-Require-Root: no + * rules: remove get-orig-source + * trivial lintian fixes + * debhelper compat level 12 + * rules: Use dpkg makefiles instead of our own parsing + * tests: uninstall modules + + -- Tzafrir Cohen Mon, 04 Mar 2019 23:29:36 +0200 + dahdi-linux (1:2.11.1.0.20170917~dfsg-5) unstable; urgency=medium * Added dpkg-dev as dependency for dpkg-architecture used by the @@ -95,7 +123,7 @@ - Patch dahdi_linux_extra updated to the 2.9.2 branch. * Use hotplug support: - patch hotplug_mod_params: change default of module parameters. - * Multiarch support. + * Multiarch support. * udev rules moved to package dahdi (in source package dahdi-tools). * Add a test for non-free files in case uscan was used. * Remove unused variables from control file. @@ -115,7 +143,7 @@ dahdi-linux (1:2.7.0+dfsg-1) unstable; urgency=low - [ Tzafrir Cohen ] + [ Tzafrir Cohen ] * New upstream release: - Patch fix_define_dev dropped: merged upstream. - Patch fix_xpp_usermode dropped: merged upstream. @@ -155,13 +183,13 @@ * Updated dahdi-linux-extra: - "Upstream" is now a complete git mirror. - Actually include ap400 in the list of modules to build. -- Updated OpenVox drivers: opvxa1200 is a subdirectory +- Updated OpenVox drivers: opvxa1200 is a subdirectory - Updated OpenVox drivers: opvxd115 added (digital cards). * Patch define_spinlock: include a (slightly big) build fix from upstream. * Standards version 3.9.2 (no change needed). * Switch to dh. * Patch notest: Remove a bogus upstream 'test' target. - * Lintian override for an odd interpteter a dummy kernel module init script. + * Lintian override for an odd interpteter a dummy kernel module init script. * Dahdi udev rules are now named 'dahdi-linux.conf'. * Patch xpp_fix_2fxs6fxo: bugfix for Xorcom 2FXX6FXO module code. @@ -171,7 +199,7 @@ * New Upstream release. - Patch uk_rotary dropped: merged upstream. -- Patch oslec_include_2634 dropped: merged upstream. +- Patch oslec_include_2634 dropped: merged upstream. - Patch xpp_usb_buffer_2635 dropped: merged upstream. - Patch voicebus_sem_h_2635 dropped: merged upstream. * dahdi_linux_extra now includes AP400 drivers (Closes: #582095). @@ -195,7 +223,7 @@ dahdi-linux (1:2.3.0.1+dfsg-1) unstable; urgency=low * New upstream version (Closes: #546319). - * Patch no_dummy removed: merged upstream. + * Patch no_dummy removed: merged upstream. * Patch wcb4xxp_extra_trunk removed: merged upstream. * Patch chanmute: make it also explicitly disable the untested DAHDI_AUDIO_NOTIFY. @@ -214,10 +242,10 @@ * Patch wcb4xxp_extra_trunk: backport extra PCI IDs for wcb4xxp (more HFC-[248]S cards).
Bug#923983: dahdi-dkms: prerm fails if module was not on the system at remove time
Package: dahdi-dkms Version: 1:2.11.1.0.20170917~dfsg-5 Severity: important dahdi-dkms includes packaging from an patch from Ubuntu. It seems that the Debian packaging has since become more robust. The package has included its own postinst and prerm scripts and did not use the ones provided by dh_dkms. Specifically, if the package does not install the module at postinst (e.g. because it is a container running on a different kernel) or if it was manually removed before the package was removed, the prerm script doesn't check. It tries to remove, fails, and gives an error. This has caused the failure of puiparts (but only after a newer version was uploaded: https://piuparts.debian.org/sid/fail/dahdi-linux_1:2.11.1.0.20170917~dfsg-6.log -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IL, LC_CTYPE=en_IL (charmap=UTF-8), LANGUAGE=en_IL:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dahdi-dkms depends on: ii dkms 2.6.1-4 ii dpkg-dev 1.19.5 ii gawk 1:4.2.1+dfsg-1 ii gcc4:8.2.0-2 ii libc6-dev 2.28-7 ii make 4.2.1-1.2 ii wget 1.20.1-1 Versions of packages dahdi-dkms recommends: ii dahdi-linux 1:2.11.1.0.20170917~dfsg-5 dahdi-dkms suggests no packages. -- no debconf information
Bug#916577: dahdi: DAHDI spantype detection fails in Buster kernel
Hi On 16/12/2018 9:50, John Lines wrote: Package: dahdi Version: 1:2.11.1-3 Severity: important Dear Maintainer, Some kernel version - possibly 4.13.0, changed the name of the spantype attribute from spantype to dahdi_spantype. This breaks dahdi_span_assignments, dahdi_genconf, dahdi_span_types and possibly others Asterisk reference to the same issue at https://issues.asterisk.org/jira/browse/DAHTOOL-80 Simple fix for dahdi_span_assignments is 159,160c159 < # for local_spanno in `cut -d: -f1 "$device/spantype"` < for local_spanno in `cut -d: -f1 "$device/dahdi_spantype"` --- for local_spanno in `cut -d: -f1 "$device/spantype"` This patch does not fix all places. It also breaks older versions (and dahdi-tools should work with older versions of the driver). The fix is, indeed, rather simple. I started working on it. I hope to have it today or tomorrow. -- Tzafrir
Bug#922008: wct4xxp: fails to initialize card
Hi, I'm not really sure what the problem is, but just to rule out one thing: maybe you have old and incompatible modules loaded? Try: /usr/share/dahdi/dahdi-modules unload # hopefully no typo here modprobe wct4xxp -- Tzafrir
Bug#904842: #904842: Fails to compile with linux 4.15+ due to new timer interface
Note that this was fixes in DAHDI 3.0.0 . However that release removes support for older hardware. Is that acceptable? -- Tzafrir
Bug#881173: pidgin-sipe: Cannot accept incoming call
Hi, I had a similar issue. I traced it to an unresolved problem with libnice: https://bugs.debian.org/914022 -- Tzafrir
Bug#914022: libnice: rejected incoming Skype for Business calls to pidgin-sipe
Package: libnice10 Version: 0.1.14-1 Severity: normal Dear Maintainer, I'm using pidgin-sipe to connect to a Lync / Skype-for-business network. I use pidgin with the pidgin-sipe plugin to connect to the network. I had issues getting calls from others (outgoing calls sort of worked). I tried the current master (5496500b1535d9343fdac2a3408864643fe65d7e, Oct-31) and calls now work. See some more details at https://sourceforge.net/p/sipe/discussion/688534/thread/4031569137/ -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IL, LC_CTYPE=en_IL (charmap=UTF-8), LANGUAGE=en_IL:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libnice10 depends on: ii libc6 2.27-8 ii libglib2.0-02.58.1-2 ii libgnutls30 3.5.19-1+b1 ii libgupnp-1.0-4 1.0.3-1 ii libgupnp-igd-1.0-4 0.2.5-2 libnice10 recommends no packages. libnice10 suggests no packages. -- no debconf information
Bug#838522: dahdi-linux: Please announce supported hardware using AppStream
On 21/09/16 23:43, Petter Reinholdtsen wrote:
> Package: dahdi-linux
> Version: 2.11.1-1
> Severity: wishlist
> User: p...@hungry.com
> Usertags: appstream-modalias
>
> Hi.
>
> The dahdi-linux package is one of the packages in the Debian archive
> that should be proposed for installation when a given hardware dongle is
> inserted or available. Thanks to the appstream system, this can now be
> announced in a way other tools can use and act on. I've written the
> isenkram system to ask the current user if hardware specific packages
> should be installed when a new dongle is installed or already present on
> a machine, and isenkram now uses appstream as one source for hardware to
> package mappings.
>
> You can read more about this on my blog,
> http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
> >.
>
> Instructions on how to create the metadata XML file can be found in
> https://wiki.debian.org/AppStream/Guidelines >.
>
> It would be great if you could add an appstream metainfo file to the
> dahdi-linux package, with content similar to this:
>
>
>
>[...]
>
> pci:ve159d0001sv*
> lkmodule:dahdi
>
>
>
> If there are other hardware ids also supported by the package, please
> add those too. :)
DAHDI supports mostly PCI devices. There is a single type of USB
devices: the Xorcom Astribanks. The relevant PCI IDs are e4e4:11[3456]2
, although 1132 and 1142 are probably not around anymore, and 1152
should also be quite rate.
As for PCI devices (assuming you want them too):
Looking at /usr/share/misc/pci.ids , I see also:
Basically all of Digium's cards (vendor ID d161) are supported.
e159:0001 is an ISDN modem card. its chip was used by Digium for its
first cards. Thus it should not be used without the sub (vendor/product)
IDs. e159:0001 8086:0003 is the one of the old X100P/X101P or one of its
many clones (a modem reprogrammed as a Zaptel card). It does not show on
the pci.ids list but the wctdm driver (old fxs/fxo card. Not sold
anymore for a long time) uses a bunch of vendor sub-IDs under e159:0001.
static DEFINE_PCI_DEVICE_TABLE(wctdm_pci_tbl) = {
{ 0xe159, 0x0001, 0xa159, PCI_ANY_ID, 0, 0, (unsigned long)
&wctdm },
{ 0xe159, 0x0001, 0xe159, PCI_ANY_ID, 0, 0, (unsigned long)
&wctdm },
{ 0xe159, 0x0001, 0xb100, PCI_ANY_ID, 0, 0, (unsigned long)
&wctdme },
{ 0xe159, 0x0001, 0xb1d9, PCI_ANY_ID, 0, 0, (unsigned long)
&wctdmi },
{ 0xe159, 0x0001, 0xb118, PCI_ANY_ID, 0, 0, (unsigned long)
&wctdmi },
{ 0xe159, 0x0001, 0xb119, PCI_ANY_ID, 0, 0, (unsigned long)
&wctdmi },
{ 0xe159, 0x0001, 0xa9fd, PCI_ANY_ID, 0, 0, (unsigned long)
&wctdmh },
{ 0xe159, 0x0001, 0xa8fd, PCI_ANY_ID, 0, 0, (unsigned long)
&wctdmh },
{ 0xe159, 0x0001, 0xa800, PCI_ANY_ID, 0, 0, (unsigned long)
&wctdmh },
{ 0xe159, 0x0001, 0xa801, PCI_ANY_ID, 0, 0, (unsigned long)
&wctdmh },
{ 0xe159, 0x0001, 0xa908, PCI_ANY_ID, 0, 0, (unsigned long)
&wctdmh },
{ 0xe159, 0x0001, 0xa901, PCI_ANY_ID, 0, 0, (unsigned long)
&wctdmh },
under the vendor ID 10b5 (PLX Technology, Inc) there is 10b5:0557 10b5
9030, the tor2 card, and then near-by a bunch of Atcom (and other)
clones, most of which I believe we don't support. Another one is (the
original tor2 card) 10b5:d00d 10b5:9030 and a bunch of near-by (and
unsupported) clones (that did not notice 'd00d' was supposed to spell
'dude').
-- Tzafrir
Bug#721147: Potential fix (state: works for me)
On 12/10/18 09:41, Petter Reinholdtsen wrote: > Control: tags -1 + patch > > [Karsten Richter 2015-02-13] >> Patch: >> >> 1. Replace the struct sk_buff with a plain void * that is only allocated >> when needed. It’s a throw away buffer, so no need the added complexity of >> sk_buff. >> 2. Remove memcpy which copies frame data from the channel buffer to the SKB >> in the channel open case. >> 3. As a consequence of (2) the alloc/dealloc code is moved into the channel >> closed case of the if statement. >> >> The attached patch is tested successfully on my live EDSS1 line here in >> Germany. > Did you try to send this patch to the upstream developers? It seem like > a good idea to get their input on the changes, and it is probably best if > you have direct contact with them instead of trying to pass in through > others. > > I believe upstream uses https://issues.asterisk.org/jira/browse/DAHLIN > > as their bug tracker. > That specific driver was never included in upstream DAHDI and right now does not seem to have any upstream maintainers. I'm not sure if I tried to apply it and it caused problems, or not. -- Tzafrir
Bug#899446: update on hebrew packages addresses
Hi, Working on those. Almost all of those needed to be switched from SVN to Git as well. The new maitainer address will be that of the newly-created Hebrew team on tracker: https://tracker.debian.org/teams/hebrew/ (Except, maybe, for fribidi). FTR: Salsa group: https://salsa.debian.org/hebrew-team -- Tzafrir Cohen | Diasp: tzaf...@wk3.org | VIM is http://tzafrir.org.il | Matrix: t...@matrix.org | a Mutt's tzaf...@cohens.org.il | Mast: tzaf...@tooot.im | best tzaf...@debian.org|| friend
Bug#897412: asterisk res_pjsip supported ciphersuites limited to 100
On Wed, May 02, 2018 at 10:34:25AM +0200, Ondřej Holas wrote:
> Package: asterisk-modules
> Version: 1:13.20.0~dfsg-1
>
> In res_pjsip, the maximum number of supported SSL/TLS ciphersuites is
> limited to 100:
Thanks. See https://gerrit.asterisk.org/#/c/8906/ .
--
Tzafrir Cohen
+972-50-7952406 mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com
Bug#897375: xmonad: should recommend dmenu and gmrun or at least suggest gmrun
Package: xmonad Version: 0.13-7 Severity: wishlist Hi, I recently moved to a new system and copied my xmonad setup to it. But it was broken. Among the things that broke were -p and -shift-p. It took me a while to realise that I needed to install dmenu and gmrun. dmenu (now suckless-tools) is in the Suggests field whereas gmrun is not even there. Neither are mentioned in README.Debian. Suggestion for README.Debian: Several tools are used by the default configuration and need to be installed in order to get the functionality: * -p - application menu - package suckless-tools * -shift-p - run a program - package gmrun There are probably others I missed. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8), LANGUAGE=he_IL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#896908: busybox cpio: fails to extract absolute symlinks
Package: busybox-static Version: 1:1.27.2-2 Severity: normal I tried building debirf on a current Sid system (chroot, rather). The generated initramfs failed to properly boot. I noticed that the second-stage rootfs in it, is OK but when extracted misses /sbin/init and a number of other symlinks from /sbin and thus the system fails to boot due to a missing init. cpio on Stretch and on Sid as well as busybox cpio on Stretch (1:1.22.0-19+b3) extract the absolute symlinks OK, but busybox cpio on Sid does not extract absolute symlinks. A test for the problem: #!/bin/sh #cpio="cpio" cpio="/bin/busybox cpio" mkdir -p test_dir cd test_dir rm -rf src_dir mkdir src_dir cd src_dir ln -s /bin/true absolute_link touch a_file ln -s a_file relative_link # Create with the regular cpio: ls absolute_link a_file relative_link | cpio -H newc -o >../test.cpio cd .. rm -rf dst_dir mkdir dst_dir cd dst_dir # Extract with the tested cpio: $cpio -H newc -i <../test.cpio count=`ls | wc -l` if [ "$count" = 2 ]; then echo "absolute links were not extracted" fi -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8), LANGUAGE=he_IL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#895361: debirf: a system fails to boot: corrupted rootfs.cxz
Thanks for your reply,
TL; DR: not a debirf issue. Maybe a kernel issue. Maybe a hardware
problem. Two patches attached. First one: just helped me debug the
problem. The second one may be useful for debirf.
On Thu, Apr 12, 2018 at 08:30:23PM -0400, Daniel Kahn Gillmor wrote:
> On Thu 2018-04-12 13:28:34 +0200, Tzafrir Cohen wrote:
> > Update: a new version of the patch. It now works and supports all
> > compressors supported by busybox (I tried bzip2, gzip, lzma, lzop and
> > xz). lzma and xz fail. Others work.
>
> thanks for this work, Tzafrir! I'd be willing to incorporate this as a
> workaround, but i'm also always leery of introducing new control knobs
> in any software (we have to educate the users that they're there -- and
> we have to maintain the knobs!)
>
> I'd feel more comfortable incorporating this workaround as a temporary
> workaround if i knew that busybox was aiming to fix this. have you
> reported the problem to busybox upstream?
>From what I see, the problem seems to be that the initramfs extracted by
the kernel (by the kernel, right?) is corrupted. When I compress it with
xz or lzma, I get a corrupted rootfs.cxz (as verified by its md5sum).
With others the archive (which is larger) managed to be properly
extracted. But when I added an md5 checksum (see attachment), I got an
error about "junk in compressed archive" and the test failed because the
md5sum file was missing.
My current rootfs is roughly 100MB (xz compressed). I tried repeating
this with a minimal configuration with a Sid target system. As I needed
a Sid version to build it I used the default "minimal" configuration. I
likewise failed to boot due to a corrupt roofs.cxz (which resulted in
missing files).
Upon further testing we managed to mount the USB device itself (by
insmod-ing the required kernel modules of the partially-extracted
image). And them compared it to the original one. The md5 checksum was
different.
cmp -l , however, showed that it was only different in 48 different
bytes. rootfs.cxz as extracted on the system had the following written
to it at some point rughly at 3/4 of it (at around the 82,000,000th
byte):
2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
When we tried to extract rootfs.cgz (from the USB device) using
busybox's gunzip and cpio but while still on the stage 1 system, there
was no problem.
So it's down to either a kernel problem or a hardware problem. My bet is
on the latter.
Kernels in question:
* linux-image-4.9.0-6-amd64 4.9.82-1+deb9u3
* linux-image-4.15.0-2-amd64 4.15.11-1
Attached patches:
* debirf-md5sum-check-for-rootfs.cxz.patch
Create an md5 checksum or the (second-stage) rootfs.cxz at nested
initramfs build time and check it at run time.
* debirf-run-shell-in-case-of-an-error-in-nested-init.patch
If you have any error in the nested init, spawn a shell to see the
error message rather than let it hide behind a lengthy kernel panic
message. And yes, busybox ash supports functions and trap.
--
Tzafrir Cohen | VIM is
http://tzafrir.org.il | a Mutt's
tzaf...@cohens.org.il | best
tzaf...@debian.org| friend
>From 159df2f77b35916a206264e548f1d1b14e432263 Mon Sep 17 00:00:00 2001
From: Tzafrir Cohen
Date: Wed, 11 Apr 2018 17:03:24 +0300
Subject: [PATCH] debirf: md5sum check for rootfs.cxz
---
debirf | 14 ++
1 file changed, 14 insertions(+)
diff --git a/debirf b/debirf
index bf380a3..1a48a3b 100755
--- a/debirf
+++ b/debirf
@@ -48,6 +48,9 @@ ROOT_WARNING=true
# location of devices.tar.gz file
export DEVICE_ARCHIVE=${DEVICE_ARCHIVE:-/usr/share/debirf/devices.tar.gz}
+# If set, create a checksum of rootfs.cxz, and verify it at boot:
+DEBIRF_VERIFY_ROOTFS_CXZ=${DEBIRF_VERIFY_ROOTFS_CXZ:-false}
+
# default package include/excludes
DEBIRF_DEFAULT_PACKAGES=${DEBIRF_DEFAULT_PACKAGES:-/usr/share/debirf/packages}
@@ -218,6 +221,13 @@ if (grep -q break=preunpack /proc/cmdline); then
/bin/sh
fi
cd /newroot
+if $DEBIRF_VERIFY_ROOTFS_CXZ; then
+ echo verifying rootfs
+ if ! (cd ..; md5sum -cs rootfs.cxz.md5); then
+echo "Error: invalid checksum for rootfs.cxz."
+/bin/sh
+ fi
+fi
echo unpacking rootfs...
$DEBIRF_COMPRESS -d - < /rootfs.cxz | cpio -i
if (grep -q break=bottom /proc/cmdline); then
@@ -233,6 +243,10 @@ EOF
msg "creating rootfs.cxz..."
fakeroot_if_needed ln -sf /sbin/init "$DEBIRF_ROOT/init"
pack_rootfs "$NEST_ROOT"/rootfs.cxz
+if $DEBIRF_VERIFY_ROOTFS_CXZ; then
+msg "creating rootfs.cxz checksum..."
+(cd "$NEST_ROOT"; md5sum rootfs.cxz >rootfs.cxz.md5)
+fi
msg "creating wrapper cgz..."
fakeroot_if_needed sh -c "cd $NEST_ROOT && find * | cpio --create -H newc" | gzip -9 > "$INITRD"
Bug#895361: debirf: a system fails to boot: corrupted rootfs.cxz
Update: a new version of the patch. It now works and supports all
compressors supported by busybox (I tried bzip2, gzip, lzma, lzop and
xz). lzma and xz fail. Others work.
--
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il || best
tzaf...@debian.org|| friend
>From ca9802d44611873eee35c42aeb2ea1f729a0d4dc Mon Sep 17 00:00:00 2001
From: Tzafrir Cohen
Date: Tue, 10 Apr 2018 16:07:43 +0300
Subject: [PATCH] debirf: support different compressor for nested rootfs
Add configuration variable DEBIRF_COMPRESS, defaults to "xz".
May also be set to use any other similar compressor (tested with bzip2,
gzip, lzop and lzma). This is the compressor to use for the nested
rootfs.
For the sake of simplicity, the name of that file remains rootfs.cxz
regardless.
Gzip-compressed images are noticably larger (roughly 150% in my case).
However we had a case of an odd corruption of the xz image when the
compressor was xz (on one specific system, with an Atom D525 based Intel
board).
---
debirf | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/debirf b/debirf
index 1e20c5c..bf380a3 100755
--- a/debirf
+++ b/debirf
@@ -39,6 +39,9 @@ STAGE_ROOT=${STAGE_ROOT:-true}
STAGE_MODULES=${STAGE_MODULES:-true}
STAGE_INITRD=${STAGE_INITRD:-true}
+# The compressor to use for the root filesystem archive:
+DEBIRF_COMPRESS=${DEBIRF_COMPRESS:-xz}
+
# warn if running as root
ROOT_WARNING=true
@@ -48,6 +51,7 @@ export DEVICE_ARCHIVE=${DEVICE_ARCHIVE:-/usr/share/debirf/devices.tar.gz}
# default package include/excludes
DEBIRF_DEFAULT_PACKAGES=${DEBIRF_DEFAULT_PACKAGES:-/usr/share/debirf/packages}
+
###
### FUNCTIONS
@@ -159,7 +163,7 @@ pack_rootfs() {
# abort with a failure if our attempts to build the rootfs fail:
set -o pipefail
-fakeroot_if_needed bash -c ". $DEBIRF_COMMON && FAKECHROOT_EXCLUDE_PATH=/does-not-exist debirf_exec sh -c 'find * | grep -v -e ^run/ | cpio --create -H newc'" | xz -9 > "$1"
+fakeroot_if_needed bash -c ". $DEBIRF_COMMON && FAKECHROOT_EXCLUDE_PATH=/does-not-exist debirf_exec sh -c 'find * | grep -v -e ^run/ | cpio --create -H newc'" | $DEBIRF_COMPRESS -9 > "$1"
}
export -f pack_rootfs
@@ -215,7 +219,7 @@ if (grep -q break=preunpack /proc/cmdline); then
fi
cd /newroot
echo unpacking rootfs...
-unxz - < /rootfs.cxz | cpio -i
+$DEBIRF_COMPRESS -d - < /rootfs.cxz | cpio -i
if (grep -q break=bottom /proc/cmdline); then
echo "honoring break=bottom kernel arg"
/bin/sh
--
2.11.0
Bug#895361: debirf: a system fails to boot: corrupted rootfs.cxz
Package: debirf
Version: 0.37
Severity: minor
I'vve been looking for this issue for several days: our debirf-based
system generally works well (and debirf is a great tool!). However I get
one specific system kept failing to boot.
When I break in the first-stage loader, I see that rootfs.cxz has the
right size but an incorrect md5sum (compared to the one in nest/ , and
compared to the one extracted from the initrd.cgz file on the USB device
I boot from).
Eventually my workaround was to replace the compressor from xz to gzip
(See attached patch). I did verify that the issue is not the amount of
memory in the system, as the same image boots fine in KVM with slightly
less memory.
-- System Information:
Debian Release: 9.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf
Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8),
LANGUAGE=he_IL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages debirf depends on:
ii apt 1.4.8
ii cpio 2.11+dfsg-6
ii debootstrap 1.0.89
ii fakechroot 2.19-3
ii fakeroot 1.21-3.1
ii klibc-utils 2.0.4-9
ii xz-utils 5.2.2-1.2+b1
Versions of packages debirf recommends:
ii grub-common 2.02~beta3-5
ii lsb-release 9.20161125
ii xorriso 1.4.6-1+b1
Versions of packages debirf suggests:
ii syslinux-common 3:6.03+dfsg-14.1+deb9u1
-- no debconf information
>From 44c422ffd9df729d90b59c41a8f335c25913b593 Mon Sep 17 00:00:00 2001
From: Tzafrir Cohen
Date: Tue, 10 Apr 2018 16:07:43 +0300
Subject: [PATCH] debirf: support gzip for nested rootfs
Add configuration variable DEBIRF_COMPRESS, defaults to "xz".
May also be set to "gzip". This is the compressor to use for
the nested rootfs.
For the sake of simplicity, the name of that file remains rootfs.cxz
regardless.
Gzip-compressed images are noticably larger (roughly 150% in my case).
However we had a case of an odd corruption of the xz image when the
compressor was xz (on one specific system, with an Atom D525 based Intel
board).
---
debirf | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/debirf b/debirf
index 1e20c5c..9133a28 100755
--- a/debirf
+++ b/debirf
@@ -39,6 +39,8 @@ STAGE_ROOT=${STAGE_ROOT:-true}
STAGE_MODULES=${STAGE_MODULES:-true}
STAGE_INITRD=${STAGE_INITRD:-true}
+DEBIRF_COMPRESS=${DEBIRF_COMPRESS:xz}
+
# warn if running as root
ROOT_WARNING=true
@@ -48,6 +50,7 @@ export
DEVICE_ARCHIVE=${DEVICE_ARCHIVE:-/usr/share/debirf/devices.tar.gz}
# default package include/excludes
DEBIRF_DEFAULT_PACKAGES=${DEBIRF_DEFAULT_PACKAGES:-/usr/share/debirf/packages}
+
###
### FUNCTIONS
@@ -159,7 +162,7 @@ pack_rootfs() {
# abort with a failure if our attempts to build the rootfs fail:
set -o pipefail
-fakeroot_if_needed bash -c ". $DEBIRF_COMMON &&
FAKECHROOT_EXCLUDE_PATH=/does-not-exist debirf_exec sh -c 'find * | grep -v -e
^run/ | cpio --create -H newc'" | xz -9 > "$1"
+fakeroot_if_needed bash -c ". $DEBIRF_COMMON &&
FAKECHROOT_EXCLUDE_PATH=/does-not-exist debirf_exec sh -c 'find * | grep -v -e
^run/ | cpio --create -H newc'" | ${DEBIRF_COMPRESS} -9 > "$1"
}
export -f pack_rootfs
@@ -215,7 +218,7 @@ if (grep -q break=preunpack /proc/cmdline); then
fi
cd /newroot
echo unpacking rootfs...
-unxz - < /rootfs.cxz | cpio -i
+$DEBIRF_UNCOMRESS - < /rootfs.cxz | cpio -i
if (grep -q break=bottom /proc/cmdline); then
echo "honoring break=bottom kernel arg"
/bin/sh
@@ -317,6 +320,11 @@ setup_environment() {
# set fakechroot save file
DEBIRF_FAKEROOT_STATE="$DEBIRF_BUILDD/.fakeroot-state.${DEBIRF_LABEL}"
+DEBIRF_UNCOMRESS="unxz"
+if [ "${DEBIRF_COMPRESS}" = "gzip" ]; then
+DEBIRF_UNCOMRESS="gunzip"
+fi
+
# set the debirf distro variables based on host distro
set_distro
--
2.11.0
Bug#888993: fakeroot: "apt update" fails with "seccomp prevented execution of syscall 0000000182 on architecture powerpc"
On Wed, Jan 31, 2018 at 07:53:18PM -0500, Daniel Kahn Gillmor wrote:
> Package: fakeroot
> Version: 1.22-2
> Severity: normal
> Control: affects -1 + debirf apt
No idea how to properly fix this. I just wanted to post a workaround.
--- /usr/share/debirf/modules/a0_prep-root 2017-05-18 19:10:07.0
+0300
+++ minimal/modules/a0_prep-root2018-04-09 14:23:57.636397144 +0300
@@ -62,6 +62,8 @@
debconf debconf/frontend select Noninteractive
EOF
+echo 'APT::Sandbox::Seccomp "false";' >
"${DEBIRF_ROOT}/etc/apt/apt.conf.d/20-nosecconf"
+
# update/upgrade
debirf_exec apt-get --yes --force-yes update
debirf_exec apt-get --yes --force-yes upgrade
I'm using debirf of Stretch/amd64 and it works great. I tried
troubleshooting an issue with one system and tried using a Sid system
there (a Sid schroot on a Stretch system with a Stretch kernel), so I
ran into the same issue (the error message was about syscall 79).
--
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il || best
tzaf...@debian.org|| friend
Bug#894890: mini-dinstall: don't crash if PID file is empty
Package: mini-dinstall
Version: 0.6.31
Severity: normal
Tags: patch
mini-dinstall should not crash if its lock file is empty. I use
mini-dinstall in daemon mode.
>From 0348ac6092f1356eafe625ed2432e9d64ad7b013 Mon Sep 17 00:00:00 2001
From: Tzafrir Cohen
Date: Thu, 26 May 2016 13:40:09 +0300
Subject: [PATCH] Ignore an empty lock file
Signed-off-by: Tzafrir Cohen
---
mini-dinstall | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mini-dinstall b/mini-dinstall
index 77d1c34..6655c37 100755
--- a/mini-dinstall
+++ b/mini-dinstall
@@ -260,7 +260,10 @@ def process_exists(pid):
return 1
if os.access(lockfilename, os.R_OK):
-pid = int(open(lockfilename).read())
+try:
+pid = int(open(lockfilename).read())
+except ValueError:
+pid = 0 # likely an empty lock file
if not process_exists(pid):
if run_mode:
logger.error("No process running at %d; use mini-dinstall -k to
remove lockfile")
--
2.11.0
Bug#894889: mini-dinstall: please allow creating MD5 checksums for packages
Package: mini-dinstall Version: 0.6.31 Severity: wishlist I use mini-dinstall as a staging repository that sits in front of an aptly one. mini-dinstall is useful as it provides all the versions, and aptly allows me to easily select the versions I want to use. Aptly (versions before 1.0. THat is: versions before Buster) relies on MD5 checksums of packages: https://github.com/smira/aptly/issues/228 https://github.com/smira/aptly/issues/442 Mini-dinstall currently (as of c3615cbdcbf62ec275b047c6739c55a8a424c60b, 0.6.31) does not create MD5 checksums. For my own archive the following patch was good enough: diff --git a/mini-dinstall b/mini-dinstall index 6655c37..ab45f88 100755 --- a/mini-dinstall +++ b/mini-dinstall @@ -1150,7 +1150,7 @@ class ArchiveDirIndexer(threading.Thread): cmdline = ['apt-ftparchive', type, dir, '-o', 'APT::FTPArchive::AlwaysStat=true', '-o', 'APT::FTPArchive::SHA1=false', - '-o', 'APT::FTPArchive::MD5=false'] + '-o', 'APT::FTPArchive::MD5=true'] if arch: cmdline += ['--arch', arch] if not nodb_mode: -- Tzafrir
Bug#886984: asterisk: Version 15.2 available
On Fri, Jan 12, 2018 at 10:04:57AM +0100, Bernhard Schmidt wrote: > Am 12.01.2018 um 09:35 schrieb Matthias Urlichs: > > Hi Matthias, > > > Version 15.2 has just been released, while Debian's is still at 13. > > Do you need help with packaging it, or what's the hold-up? > > When Asterisk is released with Debian it needs to be supported for at > least three years (~2 years of stable and ~1 year of unstable). Thus > packaging in Debian uses the LTS train, which still is Asterisk 13. > > https://www.asterisk.org/downloads/asterisk/all-asterisk-versions > > If Asterisk 15 becomes LTS before Buster Freeze we will probably upgrade. https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions Asterisk 15 will not be LTS. The plan is now for Asterisk 16 to be LTS. Versions of Astrisk normally get released at Astricon, which is around October. This means: around freeze we'll have: Asterisk 13: mature, but aging. supported(*) until Oct 2021 Asterisk 15: reasonably mature. Supported until Oct 2019 Asterisk 16: fresh. supported(*) until 2025(?) (*) Support is for the branch. Which means backporting a host of features. We get a certain release and don't follow the branch. Fixes for the branch may or may not work. Asterisk 13 also got quite a few new features (and hence: some regressions). IIRC one of the recent security advisories did not apply to the stable version at is was in a code added for a new PJSIP-related feature. -- Tzafrir Cohen +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com
Bug#879043: dahdi-linux No longer compiled with m-a as of 4.13: unknown field ‘dev_attrs’
On Sat, Dec 30, 2017 at 11:47:21PM +0100, Bernhard Schmidt wrote: > On Wed, Oct 18, 2017 at 08:19:26PM +0300, Tzafrir Cohen wrote: > > Hi Tzafrir, > > > Version: 1:2.11.1.0.20170917~dfsg-1 > > Flags: patch upstream > > Forwarded: https://issues.asterisk.org/jira/browse/DAHLIN-356 > > Severity: grave > > > > As of kernel 4.13, build fails with the following error: > > Any update on this? The JIRA ticket seems to have a proposed patch > attached, but it's not merged yet. I pushed the fix to Upstream git. I don't think there's any upcoming version. So it looks like a new git snapshot will do (also for better hardware support). And then I noticed that it fails to build with 4.15. Can be fixed, but will require some more testing. I think I'll try to get this through before 4.15 gets into Unstable: https://issues.asterisk.org/jira/browse/DAHLIN-359 -- Tzafrir Cohen +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com
Bug#884345: asterisk: CVE-2017-17664: Remote Crash Vulnerability in RTCP Stack
control: found -1 1:13.14.1~dfsg-2+deb9u2 Thanks. This applies only to Asterisk >= 13. It does apply to the version in Stable, though not to the version in oldstable. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#879043: dahdi-linux No longer compiled with m-a as of 4.13: unknown field ‘dev_attrs’
Package: Justin Hallett Version: 1:2.11.1.0.20170917~dfsg-1 Flags: patch upstream Forwarded: https://issues.asterisk.org/jira/browse/DAHLIN-356 Severity: grave As of kernel 4.13, build fails with the following error: CC [M] /usr/src/modules/dahdi/drivers/dahdi/dahdi-sysfs.o /usr/src/modules/dahdi/drivers/dahdi/dahdi-sysfs.c:273:2: error: unknown field ‘dev_attrs’ specified in initializer .dev_attrs = span_dev_attrs, ^ /usr/src/modules/dahdi/drivers/dahdi/dahdi-sysfs.c:273:15: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .dev_attrs = span_dev_attrs, ^~ /usr/src/modules/dahdi/drivers/dahdi/dahdi-sysfs.c:273:15: note: (near initialization for ‘spans_bus_type.probe’) /usr/src/modules/dahdi/drivers/dahdi/dahdi-sysfs.c:711:2: error: unknown field ‘dev_attrs’ specified in initializer .dev_attrs = dahdi_device_attrs, ^ /usr/src/modules/dahdi/drivers/dahdi/dahdi-sysfs.c:711:15: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .dev_attrs = dahdi_device_attrs, ^~ -- Tzafrir Cohen +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com
Bug#872760: asterisk-opus: uninstallable in unstable
Hi, On Mon, Aug 21, 2017 at 12:07:40AM +0200, Jonas Smedegaard wrote: > Hi Sam, > > Quoting Sam Hartman (2017-08-20 23:24:25) > > The asterisk package in unstable provides > > asterisk-1fb7f5c06d7a2052e38d021b3d8ca151 > > > > but asterisk-opus depends on asterisk-fa819827cbff2ea35341af5458859233 > > > > It looks like this is a system that is very locked to the specific > > build of asterisk. Asterisk calculates a checksum of some of its build properties at build time. This checksum is built into the module loader and normally modules fail to load if the version of Asterisk at run-time is different than the one used to build it. Normally the checksum does not change. In fact, the rules file of the Debian packaging includes a copy of it and checks that it didn't change. Some time in the 13 cycle the calculation of the checksum changed to avoid including some irrelevant functions, and thus the checksum is different from the Stable version. > The tight dependency is build-time only: Generally a BinNMU is adequate. Right. -- Tzafrir Cohen +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com
Bug#820210: asterisk: Fail to show SIP registrations
On Wed, Apr 06, 2016 at 06:29:29PM +0300, Corcodel Marian wrote: > Package: asterisk > Version: 1:11.13.1~dfsg-2+b1 > Severity: normal > > When run from asterisk console command > "sip show registry" print on console > "0 SIP registrations." ,durring registrations > running from multiple times "sip show registry" > working but on short period of time. I'm not sure what you mean here. 'sip show registrations' shows remote hosts / devices registered to this system. Were there any such registrations? Could you please be more explicit on: 1. What you configured and did. 2. What you have expected to happen. 3. What happened in practice. -- Tzafrir Cohen +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com
Bug#821392: asterisk: Astersk take exclusive control of audio device
THanks for your report, On Mon, Apr 18, 2016 at 03:14:49PM +0300, Corcodel Marian wrote: > Package: asterisk > Version: 1:11.13.1~dfsg-2+b1 > Severity: normal > > Hi > Bigger issue is , when start asterisk server trigger and pulseaudio to start > and pulseaudio take axclusive control of alsa device under user asterisk. > Please do not add to default user asterisk to group audio. > For solve this issue i run this command gpasswd -d asterisk audio The alsa module has its uses. It can be handy to allow Asterisk to play sounds to the system's speaker, However in the common case it causes harm. Therefore in the common case chan_alsa (as well as the other "console" channel drivers) should be disabled. Eight disable them in the default configuration, or move them to a different sub-package (sub-packages?). Leaving this issue open for now. -- Tzafrir Cohen +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com
Bug#856332: asterisk: useragent string contains special characters (~)
On Mon, Feb 27, 2017 at 05:58:19PM -0500, Henning Follmann wrote: > Package: asterisk > Version: 1:11.13.1~dfsg-2+deb8u2 > Severity: minor > > During sip registration with an upstream provider some of the added > characters (~) caused some issues. > Please revert useragent string back to default "Asterisk PBX" or provide > the sample config entry in /etc/asterisk/sip.conf: > useragent="Asterisk PBX" For the record: if any server gets confused by such a character in the UA string, it is probably non standard compliant. There is a simple fix / workaround for this, as mentioned above (set useragent in sip.conf / pjsip.conf). This bug will be closed in the next release but only due to the fact that the minor issue of the sample pjsip.conf was fixed. -- Tzafrir Cohen +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com
Bug#820222: asterisk-config: Please set context on default
Control: tags -1 + wontfix On Thu, Apr 07, 2016 at 01:15:50AM +0300, asu wrote: > > > On 04/06/2016 11:05 PM, Jonas Smedegaard wrote: > > Hi Corcodel, > > > > Quoting Corcodel Marian (2016-04-06 19:56:35) > > > On asterisk context is set on public relative to examples from > > > users.conf which require default context(aka local). > > > When an new user try to use extensions bellow 6000 is hard to handle > > > this situation.On users.conf have context=international which is more > > > inapropiate. > > Not sure I understand exactly what it is you describe (english is not my > > native language, and it seems it isn't yours either). > > > > It sounds like you understand this issue well: Could you perhaps provide > > a concrete suggestion of what you believe should be changed? > > > > > > Regards, > > > > - Jonas > On sip.conf file replace "context=public " with ";context=default" Relevant upstream issue: https://issues.asterisk.org/jira/browse/ASTERISK-14122 I'm not sure I fully agree with the change, but from what I see, they won't change it, and I don't want to diverge from them on this petty issue for no good reason (think of documentation and support). Feel free to take this issue upstream and convince them. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#867346: #867346: asterisk: please transition to gmime 3.0
I wrote a simple patch (not tested yet), submitted upstream: https://gerrit.asterisk.org/#/c/6131/ I'll wait for this to get included upstream, but I guess there should be no problem. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#785480: Expanding interest in bcg729
On Tue, Aug 01, 2017 at 11:11:40PM +0200, Jaap Keuter wrote: > Hi, > > Recent developments in Wireshark have seen this library being used in RTP > stream > decoding. It would be appreciated by many users of Wireshark on Debian (and > derivatives) when this would be available for the Debian build of Wireshark. The package has a mediastreamer plugin. In version 1.0.2 it fails to build and from what I understand it seems it would need libmediastream2. >From what I see that plugin does not change the basic library. Thus I see no problem with starting just with the library itself. I figure you (Jaap) only need the library. Is that right? Adding the plugin later should not break anything. Anybody working on adding libmediastreamer2? Linphone4? Will there be a problem with adding them in the future? -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#850080: #850080: bash as the default shell
Control: tag -1 + patch
On Wed, Mar 01, 2017 at 08:46:53PM +0100, jhcha54008 wrote:
> Hi,
>
> May this bug #850080 be a consequence of #814358 (and [1]) ?
>
> It doesn't occur if /bin/sh is a symlink to bash.
Again, thanks for your fix. Works here. Attached again in a slightly
different format.
--
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il || best
tzaf...@debian.org|| friend
>From b661cea6e8606305e198ab2baa3c8b334903ed74 Mon Sep 17 00:00:00 2001
From: jhcha54008
Date: Wed, 1 Mar 2017 20:46:53 +0100
Subject: [PATCH 2/2] run fakeroot with bash (Closes: #850080)
bash caches internal functions even through calls to subshells. If
fakeroot is a subshell of bash, it preserves functions such as
debirf_info_sh. Otherwise such "commands" are missing.
---
src/common | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/common b/src/common
index 9930ef4..ca7e0b8 100755
--- a/src/common
+++ b/src/common
@@ -45,7 +45,7 @@ fakeroot_if_needed() {
failure "Debirf fakeroot state file '$DEBIRF_FAKEROOT_STATE' does not exist."
fi
# set up $PATH and $HOME as though we are superuser
- HOME=/root PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin fakeroot -i "$DEBIRF_FAKEROOT_STATE" -s "$DEBIRF_FAKEROOT_STATE" "$@"
+ HOME=/root PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin bash fakeroot -i "$DEBIRF_FAKEROOT_STATE" -s "$DEBIRF_FAKEROOT_STATE" "$@"
fi
}
export -f fakeroot_if_needed
--
2.11.0
Bug#833125: : debirf: fails to build rescue on sid/stretch: insserv not found
Control: -1 tag + patch On Wed, Mar 01, 2017 at 09:09:02PM +0100, jhcha54008 wrote: > Hi, > > What about the more conservative patch below ? Thanks. WorksForMe. Attached in a slightly different format. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend >From f88f462f9bf3a2a245f04246583e404b33c547e3 Mon Sep 17 00:00:00 2001 From: jhcha54008 Date: Wed, 1 Mar 2017 21:09:02 +0100 Subject: [PATCH 1/2] a0_prep-root: run insserv if installed (Closes: #833125) Module a0_prep-root runs insserv to fix issues in a sysv system. This workaround is not required in a systemd system. It is not included in a minimal systemd-based system. --- src/modules/a0_prep-root | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/modules/a0_prep-root b/src/modules/a0_prep-root index 21138a1..ea5d1cb 100755 --- a/src/modules/a0_prep-root +++ b/src/modules/a0_prep-root @@ -67,4 +67,4 @@ debirf_exec apt-get --yes --force-yes update debirf_exec apt-get --yes --force-yes upgrade # work around http://bugs.debian.org/686965 -debirf_exec sh -c 'cd /etc/init.d && insserv $(ls | grep -vFx -e rc -e rcS -e skeleton -e README)' +debirf_exec sh -c 'if `which insserv > /dev/null`; then cd /etc/init.d && insserv $(ls | grep -vFx -e rc -e rcS -e skeleton -e README); fi' -- 2.11.0
Bug#794495: Mock fails to track installed packages
tags -1 + patch
reassign -1 rpm
thanks
Hi,
Sorry for not answering earlier,
On Mon, Aug 03, 2015 at 06:08:49PM +, Vishvananda Ishaya wrote:
> Package: mock
> Version: 1.2.3-1
>
> Mock fails to track installed packages properly due to the rpm package
> changing the default rpmdb directory to ~/.rpmdb from /var/lib/rpm.
>
> There is an existing patch to remove the extra /buildroot/.rpmdb dir that
> gets created during the install, but we actually want the rpmdb to be in
> /var/lib/rpm
>
> To see an example of the problem, try:
> /usr/bin/mock --init
> followed by
> /usr/bin/mock --yum-cmd -- -C list installed
> It will show an empty list of packages because it can't find the rpmdb.
> This means that yum will attempt to reinstall packages that are already
> installed when doing rpm builds leading to subtle differences in dependency
> ordering when building on another distro.
>
> I have tried passing in the correct macro using -D:
> /usr/bin/mock -D '_dbpath %{_var}/lib/rpm' --init
> I have tried editing my user's .rpmmacros to add:
> %_dbpath %{_var}/lib/rpm
> Neither of these works.
Mock runs as root mostly. Maybe it reads root's .rpmmacros?
> Editing /usr/lib/rpm/macros to manually undo the .rpmdb patch works:
> %_dbpath%{_var}/lib/rpm
>
> I'm not sure what the best fix is here. This may also need to be reported
> against rpm, because the best option might be to remove the patch to
> /usr/lib/rpm/macros and instead document how a user could manually add the
> change to their .rpmmacros if they want it to include:
> %_dbpath %(echo $HOME)/.rpmdb
This is a Debian-specific change in the package rpm. RPM automatically
attempts to create its database if it does not exist. On Debian it does
not exist. This creates a harmless but noisy and annoying error message
whenever you try to use rpm on the Debian system.
Why would you use rpm on a Debian system?
* rpm -qp: annoying message
* rpm operations as root inside an RPM-based system in a chroot: that
fix breaks it.
I can't think of any way to fix this in mock or in yum. I think that the
proper way to fix it is in rpm: instead of editing _dbpath, don't
complain when you get EPERM trying to open the packages database. A
patch is attached (against 4.12.0.2, as it seems that patches fail to
apply for 4.13.0.1 in master).
I did not look deeper into it. Maybe it's possible to avoid opening the
database on rpm -qp?
--
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il | | best
tzaf...@debian.org|| friend
>From c99b518383686caf5200d0c9b975c7288ef7332d Mon Sep 17 00:00:00 2001
From: Tzafrir Cohen
Date: Tue, 18 Apr 2017 12:38:50 +0300
Subject: [PATCH] Add hush_rpmdb_warning.patch
---
debian/patches/hush_rpmdb_warning.patch | 51 +
debian/patches/series | 3 +-
2 files changed, 53 insertions(+), 1 deletion(-)
create mode 100644 debian/patches/hush_rpmdb_warning.patch
diff --git a/debian/patches/hush_rpmdb_warning.patch b/debian/patches/hush_rpmdb_warning.patch
new file mode 100644
index ..fe0e7778
--- /dev/null
+++ b/debian/patches/hush_rpmdb_warning.patch
@@ -0,0 +1,51 @@
+From: Tzafrir Cohen
+Subject: avoid permission denied warning about rpmdb
+
+Debian systems don't have an RPM database under /var/lib/rpm. However
+systems installed in a chroot from a Debian system may have such a
+database.
+
+So instead of changing the configuration, hush the warning RPM emits
+about failing to create the database. As the common use case will be
+'rpm -qp'.
+
+diff --git a/lib/rpmdb.c b/lib/rpmdb.c
+index b6d32472..332f6290 100644
+--- a/lib/rpmdb.c
b/lib/rpmdb.c
+@@ -157,9 +157,17 @@ static int pkgdbOpen(rpmdb db, int flags, dbiIndex *dbip)
+ dbSetFSync(db->db_dbenv, 0);
+ }
+ } else {
++ if (rc == EPERM) {
++ /* This is likely because a user tried to run 'rpm -qp' and
++ * the RPM databse does not exist:
++ */
++ rpmlog(RPMLOG_DEBUG, "Permission denied trying to open %s index using %s)\n",
++ rpmTagGetName(RPMDBI_PACKAGES), db->db_descr);
++ } else {
+ rpmlog(RPMLOG_ERR, _("cannot open %s index using %s - %s (%d)\n"),
+ rpmTagGetName(RPMDBI_PACKAGES), db->db_descr,
+ (rc > 0 ? strerror(rc) : ""), rc);
++ }
+ }
+
+ exit:
+@@ -203,9 +210,17 @@ static int indexOpen(rpmdb db, rpmDbiTagVal rpmtag, int flags, dbiIndex *dbip)
+ }
+ }
+ } else {
++ if (rc == EPERM) {
++ /* This is likely because a user tried to run 'rpm -qp' and
++ * the RPM databse does not exist:
++ */
++ rpmlog(RPMLOG_DEBUG, "Permission denied trying to open %s index using %s)\n",
++ rpmTagG
Bug#856979: asterisk-opus: No documentation on how to use this
On Mon, Mar 06, 2017 at 09:32:38PM +0100, Frederik Himpe wrote: > Package: asterisk-opus > Version: 13.7+20161113-3 > Severity: normal > > I had expected to find some documentation in /usr/share/doc/asterisk-opus > explaining me what I should add to sip.conf to allow usage of the opus codec. Generally it's yet another codec called 'opus'. Upstream now has a different codec with the same name and thus the documentation is the same. I see that this is not the only thing missing from README.Debian. I'm onto it. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#856332: asterisk: useragent string contains special characters (~)
On Tue, Feb 28, 2017 at 12:28:49PM +0100, Tzafrir Cohen wrote: > So I don't see anything that needs fixing here. Apart from the minor > issue with the text of the description of the pjsip.conf option > "user_agent". But that is for upstream. Upstreamed that: https://issues.asterisk.org/jira/browse/ASTERISK-26825 -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#856332: asterisk: useragent string contains special characters (~)
On Mon, Feb 27, 2017 at 05:58:19PM -0500, Henning Follmann wrote: > Package: asterisk > Version: 1:11.13.1~dfsg-2+deb8u2 > Severity: minor > > During sip registration with an upstream provider some of the added > characters (~) caused some issues. > Please revert useragent string back to default "Asterisk PBX" or provide > the sample config entry in /etc/asterisk/sip.conf: > useragent="Asterisk PBX" The user agent in the Debian package does not deviate from Upstream. However, the version string in the Debian package includes a '~' character that is not included in Upstream. sip.conf already includes an example line (remmed out): ;useragent=Asterisk PBX ; Allows you to change the user agent string ; The default user agent string also contains the Asterisk ; version. If you don't want to expose this, change the ; useragent string. Likewise in pjsip.conf (for Asterisk >= 13): ;user_agent=Asterisk PBX SVN-branch-12-r404375 ; Value used in User Agent ; header for SIP requests and ; Server header for SIP ; responses (default: "Asterisk ; PBX SVN-branch-12-r404375") I see indeed that this example configuration file needs fixing. The default value uses the current version, of course. So I don't see anything that needs fixing here. Apart from the minor issue with the text of the description of the pjsip.conf option "user_agent". But that is for upstream. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#855421: src:linphone: Vcs-Browser points to wrong package
Hi, Welcome to the pkg-voip team, On Fri, Feb 17, 2017 at 02:59:03PM -0500, Dara Adib wrote: > Source: linphone > Version: 3.6.1-3 > Severity: minor > Tags: patch > > Dear Maintainer, > > The Vcs-Browser field in debian/control points to asterisk. It should > point to linphone. > > Thanks! > > diff --git a/debian/control b/debian/control > index 9e954fa..5611967 100644 > --- a/debian/control > +++ b/debian/control > @@ -64,7 +64,7 @@ Build-Depends: autoconf, > Standards-Version: 3.9.6 > Homepage: http://www.linphone.org/ > Vcs-Git: https://anonscm.debian.org/git/pkg-voip/linphone.git > -Vcs-Browser: https://anonscm.debian.org/git/pkg-voip/asterisk.git > +Vcs-Browser: https://anonscm.debian.org/git/pkg-voip/linphone.git Thanks for reporting. Please feel free to fix this (branch jessie in git). >From what I see, a similar fix is needed in the master branch (use secure URLs: https instead of http and git). so the same URLs should be copied there. Unless the master branch should be left to linger? Also: are you subscribed to the pkg-voip list? You mentioned that you wanted to help with updating of linphone, so see a recent thread regarding that package: http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/2016-December/thread.html#29963 and the two messages that spilled to January: http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/2017-January/thread.html#30025 -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#785480: ITP: bcg729 -- ITU G.729 Annex A compatible audio codec
Control: retitle -1 ITP: bcg729 -- ITU G.729 Annex A compatible audio codec On Mon, May 18, 2015 at 04:23:42PM +0200, Tzafrir Cohen wrote: > On Mon, May 18, 2015 at 09:34:15AM -0300, Henrique de Moraes Holschuh wrote: > > G.729 is a patent minefield, and some of them are actively enforced last > > time I checked. > > > > Has the situation changed? > > This is an implementation of G.729A. The standard itself is roughly 20 > years old. Any idea when the relevan patents expire? It seems they have: http://www.sipro.com/G729.html Initial packaging (as before): https://anonscm.debian.org/cgit/pkg-voip/bcg729.git/ (Needs to be updated to version 1.0.2) -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#853615: pjproject: ftbfs with GCC-7
On Tue, Jan 31, 2017 at 09:35:08AM +, Matthias Klose wrote: > Package: src:pjproject > Version: 2.5.5~dfsg-5 > Severity: normal > Tags: sid buster > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-7 > > Please keep this issue open in the bug tracker for the package it > was filed for. If a fix in another package is required, please > file a bug for the other package (or clone), and add a block in this > package. Please keep the issue open until the package can be built in > a follow-up test rebuild. > > The package fails to build in a test rebuild on at least amd64 with > gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The > severity of this report may be raised before the buster release. > There is no need to fix this issue in time for the stretch release. > > The full build log can be found at: > http://people.debian.org/~doko/logs/gcc7-20170126/pjproject_2.5.5~dfsg-5_unstable_gcc7.log > The last lines of the build log are at the end of this report. > > To build with GCC 7, either set CC=gcc-7 CXX=g++-7 explicitly, > or install the gcc, g++, gfortran, ... packages from experimental. > > apt-get -t=experimental install g++ > > Common build failures are new warnings resulting in build failures with > -Werror turned on, or new/dropped symbols in Debian symbols files. > For other C/C++ related build failures see the porting guide at > http://gcc.gnu.org/gcc-7/porting_to.html Builds fine but symbols changed? Oh well, this can wait for pjproject 2.6 (just released, claims to support OpenSSL 1.1.x). -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#743145: [Debian-hebrew-package] Bug#743145: Bug#743145: Bidiv failed to build due to lack of libglib2.0-dev
Any news regarding this bug report? I'm not sure how to reproduce it. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#851938: unblock: aspell-he/1.0-0-7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package aspell-he Package includes packaging upgrade only and almost no change of content. The sole change in the content, besides the Debian changelog, is the following: * /usr/share/aspell/he.cwl.gz is different due to different gzip header. The original uncompressed files are the same in the old and the new. Packaging change: * Removal of a retired maintainer (Closes #759993) * Compat level: 5 -> 9 * A DEP-5 copyright file A debdiff of the change: diff -Nru aspell-he-1.0-0/debian/changelog aspell-he-1.0-0/debian/changelog --- aspell-he-1.0-0/debian/changelog2013-06-29 11:50:40.0 +0300 +++ aspell-he-1.0-0/debian/changelog2017-01-19 22:08:24.0 +0200 @@ -1,3 +1,13 @@ +aspell-he (1.0-0-7) unstable; urgency=medium + + * Switch to dh and compat level 9. + * Add myself as uploader and remove Baruch (retired, Closes: #759993). + * Use a secure browser URL. + * A DEP-5 copyrights file + * Standards-Version 3.9.8 + + -- Tzafrir Cohen Thu, 19 Jan 2017 22:08:24 +0200 + aspell-he (1.0-0-6) unstable; urgency=low [ Agustin Martin Domingo ] diff -Nru aspell-he-1.0-0/debian/control aspell-he-1.0-0/debian/control --- aspell-he-1.0-0/debian/control 2013-06-29 11:50:40.0 +0300 +++ aspell-he-1.0-0/debian/control 2017-01-19 21:44:52.0 +0200 @@ -2,12 +2,12 @@ Section: text Priority: optional Maintainer: Debian Hebrew Packaging Team -Uploaders: Baruch Even , Lior Kaplan , Shachar Shemesh -Standards-Version: 3.9.4 +Uploaders: Tzafrir Cohen , Lior Kaplan , Shachar Shemesh +Standards-Version: 3.9.8 Build-Depends: debhelper (>> 9) Build-Depends-Indep: aspell (>= 0.60.3-2), dictionaries-common-dev (>= 1.11.2) Vcs-Svn: svn://anonscm.debian.org/debian-hebrew/pkg/aspell-he -Vcs-Browser: http://anonscm.debian.org/viewvc/debian-hebrew/pkg/aspell-he +Vcs-Browser: https://anonscm.debian.org/viewvc/debian-hebrew/pkg/aspell-he Homepage: ftp://ftp.gnu.org/gnu/aspell/dict/he/ Package: aspell-he diff -Nru aspell-he-1.0-0/debian/copyright aspell-he-1.0-0/debian/copyright --- aspell-he-1.0-0/debian/copyright2005-07-23 22:43:04.0 +0300 +++ aspell-he-1.0-0/debian/copyright2017-01-18 21:58:22.0 +0200 @@ -1,25 +1,23 @@ -This package was debianized by Baruch Even on -Mon, 18 Jul 2005 17:01:07 +0100. - -It was downloaded from ftp://ftp.gnu.org/gnu/aspell/dict/he/ - -Copyright Holder: Nadav Har'El - Dan Kenigsberg - -License: - -The Aspell dictionary for Hebrew is based on Hspell and -released under the GNU GPL version 2. - -Hspell is copyright (C) 2000-2003, Nadav Har'El and Dan Kenigsberg. - -It is released to the public licensed under the GNU General Public License -(GPL). See the COPYING file included in this distribution for the whole text -of the GNU General Public License version 2. - -Note that not only the programs in the distribution, but also the -dictionary files and the generated word lists, are licensed under the GPL. -There is no warranty of any kind for the contents of this distribution. - -In a Debian system you can find the GPL version 2 license under -/usr/share/common-licenses/GPL-2 +Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ +Upstream-Name: aspell-he +Source: ftp://ftp.gnu.org/gnu/aspell/dict/he/ + +Files: * +Copyright: + 2000-2006, Nadav Har'El + 2000-2006, Dan Kenigsberg +License: GPL-2.0 + +Files: debian/* +Copyright: + 2005-2007, Baruch Even + 2005-2013, Lior Kaplan +License: GPL-2.0 + +License: GPL-2.0 + It is released to the public licensed under the GNU General Public License + (GPL). See the COPYING file included in this distribution for the whole text + of the GNU General Public License version 2. + . + On Debian systems you can find a version of the GNU General Public License + at /usr/share/common-licenses/GPL-2 unblock aspell-he/1.0-0-7 -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#800367: openchrome and "Modules" section [was: Re: [Openchrome-users] How to say No!! in a polite though ridiculous way]
On Wed, Jan 18, 2017 at 10:26:11AM +0100, Tamás Gajdos wrote: > Hi, > > I don't know if this is a packaging problem or not. But I had the same > issue with Ubuntu 17.04 around 2017.01.10. > > I solved the problem by adding some extra modules to the xorg.conf. > > Section "Module" > Load"vgahw" > Load"shadowfb" > Load"shadow" > Load"exa" > Load"fb" > Load"drm" > Load"ramdac" > EndSection > > Maybe not all of them is needed as I was trying to debug another issue. OK. So just to complete the report: With just "vgahw" and "shadow": libshadow now loads OK, and the next error is: [ 5933.945] (EE) Failed to load /usr/lib/xorg/modules/drivers/openchrome_drv.so: /usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol: exaWaitSync Next, add "exa". Now I get: [ 6218.682] (EE) Failed to load /usr/lib/xorg/modules/drivers/openchrome_drv.so: /usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol: fbScreenInit If I add "fb", the openchrome_drv loads fine. Thus the following seems to work for me: Section "Module" Load"vgahw" Load"shadow" Load"exa" Load"fb" EndSection -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#800367: [Openchrome-users] How to say No!! in a polite though ridiculous way
On Sun, Jan 15, 2017 at 08:51:06PM +0100, Tzafrir Cohen wrote: > On Fri, Jan 13, 2017 at 11:47:40PM +0100, Kevin Brace wrote: > > Hi Andreas, > > > > Throw this in your xorg.conf > > > > > > Section "Module" > > Load"vgahw" > > EndSection > > > > > > Other than that, your xorg.conf can be empty. > > I hope it works. > > Thanks. Works for me. Err... almost. It works. Only not using the openchrome module. Preiously the openchrome module probably failed the whole load and had to be moved aside. Now it merely fails to load but I can use vesa or whatever as a fallback. Without any extra config: [ 1618.153] (EE) Failed to load /usr/lib/xorg/modules/drivers/openchrome_drv.so: /usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol: vgaHWFreeHWRec vgaHWFreeHWRec indeed comes from vgahw. So add it. Now I get: [ 1747.417] (EE) Failed to load /usr/lib/xorg/modules/drivers/openchrome_drv.so: /usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol: shadowRemove Grepping further, I see shadowRemove comes from libshadow.so. So I try adding it. Now I get: [ 1830.755] (EE) LoadModule: Module libshadow does not have a libshadowModuleData data object. [ 1830.756] (II) UnloadModule: "libshadow" ... [ 1830.768] (EE) Failed to load /usr/lib/xorg/modules/drivers/openchrome_drv.so: /usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol: shadowRemove Anyone else have this issue of the openchrome driver not loading at all? Is this a packaging issue? -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#800367: [Openchrome-users] How to say No!! in a polite though ridiculous way
On Fri, Jan 13, 2017 at 11:47:40PM +0100, Kevin Brace wrote: > Hi Andreas, > > Throw this in your xorg.conf > > > Section "Module" > Load"vgahw" > EndSection > > > Other than that, your xorg.conf can be empty. > I hope it works. Thanks. Works for me. Debian Stretch. Before that I had to remove openchrome.so. I put that content as /usr/share/X11/xorg.conf.d/30-openchrome.conf and now it works fine. For the record, the hardware in question: 00:01.0 VGA compatible controller: VIA Technologies, Inc. VX855/VX875 Chrome 9 HCM Integrated Graphics (prog-if 00 [VGA controller]) Subsystem: VIA Technologies, Inc. VX855/VX875 Chrome 9 HCM Integrated Graphics Flags: bus master, fast devsel, latency 32, IRQ 11 Memory at d800 (32-bit, prefetchable) [size=64M] Memory at de00 (32-bit, non-prefetchable) [size=16M] [virtual] Expansion ROM at 000c [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit- Debian packaging: I would appreciate it if the Debian package could include such a file (if it is harmless) or at least as an example. Or find a way to avoid the extra configuration. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#849804: /etc/init.d/asterisk debug unusable for continous output
On Sat, Jan 14, 2017 at 09:21:59AM +0100, Joerg Dorchain wrote: > On Fri, Jan 13, 2017 at 06:53:15PM +0100, Bernhard Schmidt wrote: > > > > Can you try to diff the content of your /etc/asterisk and the package > > content of asterisk-config to find the relevant setting? > > > > I would like config parts containing personal access details > not to be part of the public bug tracker for avoiding security > breaches and direct monetary costs arrising from that, so I did > not sent them to the public bug report on purpose. Could you please then send such a diff (or set of config files, if that is smaller) privately to Bernhard and to me? -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com
Bug#850320: mock: CVE-2016-6299: privilige escalation via mock-scm
On Fri, Jan 06, 2017 at 01:37:58PM +, Holger Levsen wrote: > Hi Tzafrir, > > On Fri, Jan 06, 2017 at 12:25:07AM +0100, Tzafrir Cohen wrote: > > The version in Jessie-backports seems to be the only one affected by it. > > will you upload a fixed version to jessie-bpo or should I? (I'd be happy > if you did, but I was the person introducing mock to bpo, so I'd take > responsibility and fix, if needed.) I prepared a version in the branch jessie-backports in git[1]. It seems to work OK here. I don't hae my key in the backports keyring, so I prefer that you upload it. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#850320: mock: CVE-2016-6299: privilige escalation via mock-scm
My initial reading into this: neither the version in Stable (1.1.33-1) nor the version in Testing / Unstable (1.3.2-1) is volnurable. Not closing yet as I want to test this better. The version in Jessie-backports seems to be the only one affected by it. Impact: mock is a chroot building serer. You feed it with RPM source packages and they get built in chroots (that it creates). Package specifications may generally include various forms of executable code. The builder runs the builds as a non-root user. The issue was that the rpm spec file was evaluated accidentally as root. This issue was fixed upstream just before 1.2.22, and that fix is included in the current version (1.3.2). In 1.1.33 the parsing seems to be done before after temporarily dropping super-user privileges at startup. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#849804: /etc/init.d/asterisk debug unusable for continous output
Hi, On Sat, Dec 31, 2016 at 09:30:35AM +0100, Joerg Dorchain wrote: > Package: asterisk > Version: 1:13.13.1~dfsg-2 > > Hello, > > following testing, after upgrading to asterisk 1:13.13.1~dfsg-2, > /etc/init.d/asterisk debug endlessly repeats the following screen > output rapidly: > ... > 09:22:39.015 rtp0x558b74e70 Mutex: thread timer is waiting > 09:22:39.015 rtp0x558b74e70 Mutex acquired by thread timer AST_DEBUG_PARAMS=-cvd. That is: verbose level 4 and debug level 5. It also means that asterisk remains attached to the terminal it was run from and offers aconsole there. Frankly I hardly recall needing to use this while debugging and frankly I completely forgot this option. The messages comes from pjproject. The messages are relatively low priority ones there. However just from reading the code I'm a bit lost. That message seems to be at log priorty 6 in pjproject: http://sources.debian.net/src/pjproject/2.5.5~dfsg-5/pjlib/src/pj/os_core_unix.c/?hl=1361#L1361 (And likewise in 2.4.5) Asterisk maps by default pjproject log levels 3, 4 and 5 to "debug" (see pjproject.conf) and I don't see anything about 6. Do you have anything customized there? Can you play with the definitions in that file? That said, I'm not really surprise if at debug level 5 the console is not usable. I suppose there may be other messages that may lead to such a flood. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#849214: ITP: fonts-ldco -- set of Hebrew fonts by Louis Davis & Co.
Package: wnpp Severity: wishlist Owner: Tzafrir Cohen * Package name: fonts-ldco Version : 0.3.20161223 Upstream Author : Louis Davis & Co.<http://www.ldcodesign.com> * URL : http://www.ldcodesign.com/%D7%98%D7%99%D7%A4%D7%95%D7%92%D7%A8%D7%A4%D7%99%D7%94/ * License : OFL 1.1 Programming Lang: Fonts (TTF, OTF, WOFF) Description : set of Hebrew fonts by Louis Davis & Co. set of 20 Hebrew fonts by Louis Davis and Co. in OTF, TTF, and WOFF formats. . Fonts: Daniel, Eco, Hidekel, Josef, Kimchi, Miso, Neo, Sticks, YamSuf, Strokes, Mixer, Patch Serif, Patch Sans, Patch Stencil, Lilach, Amit, Noam, Har Sinai, Saiphan and Skechers. Note: homepage is Hebrew only. Initial packaging, for an earlier version: https://git.tzafrir.org.il/cgit/fonts-ldco.git/ Those fonts, while provided under OTF, only include a limited number of glyphs (basically Hebrew and numbers). They are indeed quite useful for writing "artistic" text, but may not be usable for more professional settings. The design studio intends to provide improved versions of those under a proprietary license. Is that acceptable for inclusion into Debian?
Bug#849143: libasterisk-agi-perl: Manager: fails to use ActionID
Package: libasterisk-agi-perl
Version: 1.03-1
Severity: minor
Just a reminder that it is all too easy to get things wrong with the
Asterisk::Manager module, as it fails to use ActionID-s and will just
return the first header you happen to have.
For instance, the following program:
my $astman = new Asterisk::Manager;
$astman->user('username');
$astman->secret('password');
$astman->host('localhost');
$astman->connect || die "Could not connect to " . $astman->host . "!\n";
print $astman->command('sip show peers');
print $astman->command('sip show peers');
$astman->disconnect;
will probably work if you don't have either 'security' or 'system' in
read for the manager user 'username'. If you have either, you'll get an
event or two before the response to the command.
* system: Event: FullyBooted
* security: Event: SuccessfulAuth
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf
Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libasterisk-agi-perl depends on:
ii perl 5.24.1~rc4-1
libasterisk-agi-perl recommends no packages.
libasterisk-agi-perl suggests no packages.
-- no debconf information
Bug#848584: asterisk: missing hook for automatic load of DAHDI channels
Package: asterisk Version: 1:13.12.2~dfsg-2 Severity: wishlist Dear Maintainer, The package dahdi (of source package dahdi-tools) includes the directory /usr/share/dahdi/span_config.d/ for scripts that get called (from udev, through a hook script) when a new DAHDI span appears. The allow applying custom operations on the span. As of version 1:2.10.0.1-1 of dahdi (now in Jessie) the Debian package has removed the hook that registers spans with Asterisk automatically[1] because this is the job of the Asterisk package (DAHDI should not tie itself to Asterisk). Thus this script should be added to Asterisk. If one wants to avoid a file conflict with dahdi <= 1:2.10.2-1 (pre-jessie versions), it should be safe to use the name '40-asterisk': * Calling the script twice (in case that older version installed) has a small performance issue, but nothing more. * This number (40) is already used in some unofficial packages used by the company I work for. I recommend to add it to the main package (asterisk) and not to asterisk-dahdi for the sake of simplicity: it does not add any real dependency on dahdi. [1] http://git.asterisk.org/gitweb/?p=dahdi/tools.git;a=blob;f=hotplug/span_config.d/50-asterisk;hb=HEAD -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages asterisk depends on: ii adduser 3.115 ii asterisk-config 1:13.12.2~dfsg-2 ii asterisk-core-sounds-en [asterisk-prompt-en] 1.4.22-1 ii asterisk-core-sounds-en-gsm 1.4.22-1 ii asterisk-modules 1:13.12.2~dfsg-2 ii init-system-helpers 1.46 ii libbsd0 0.8.3-1 ii libc6 2.24-7 ii libcap2 1:2.25-1 ii libedit2 3.1-20160903-2 ii libgcc1 1:6.2.1-5 ii libjansson4 2.9-1 ii libncurses5 6.0+20161126-1 ii libpopt0 1.16-10 ii libsqlite3-0 3.15.2-1 ii libssl1.1 1.1.0c-2 ii libstdc++66.2.1-5 ii libsystemd0 232-7 ii libtinfo5 6.0+20161126-1 ii liburiparser1 0.8.4-1 ii libuuid1 2.29-1 ii libxml2 2.9.4+dfsg1-2.1 ii libxslt1.11.1.29-2 ii lsb-base 9.20161125 Versions of packages asterisk recommends: pn asterisk-moh-opsound-gsm pn asterisk-voicemail | asterisk-voicemail-storage ii sox 14.4.1-5+b1 Versions of packages asterisk suggests: pn asterisk-dahdi ii asterisk-dev 1:13.12.2~dfsg-2 pn asterisk-doc pn asterisk-ooh323 pn asterisk-vpb -- no debconf information
Bug#847666: asterisk: AST-2016-008: Crash on SDP offer or answer from endpoint using Opus
On Sat, Dec 10, 2016 at 03:52:26PM +0100, Salvatore Bonaccorso wrote: > Source: asterisk > Version: 1:13.12.2~dfsg-1 > Severity: grave > Tags: security upstream patch > Forwarded: https://issues.asterisk.org/jira/browse/ASTERISK-26579 > > Hi > > AST-2016-008 was announced at > > http://downloads.asterisk.org/pub/security/AST-2016-008.html > > referencing patches as well for the 13.x release series. > > https://issues.asterisk.org/jira/browse/ASTERISK-26579 The patch does not seem to apply to the Debian package due to opus.patch. It seems however that the original issue likewise doesn't, as the code from opus.patch uses a different parsing of the Opus SDP headers. Attached a sipp scenario that crashes an unpatched upstream asterisk 13.13.0: sipp 127.0.0.1:5060 -sf SDP.xml -m 1 If anyone wants to give a second look to opus.patch (and maybe also amr.patch . vp8.patch looks more self-contained). The relevant upstream code must have had some extra checks at this point. Could someone else please double-check before closing this one? (But yes, there's still AST-2016-009 in another open bug) -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com sipp-AST-2016-008.xml Description: XML document
Bug#847464: [git-buildpackage/master] gbp-mock: handle single letter options
tag 847464 pending thanks Date: Thu Dec 8 15:04:23 2016 +0200 Author: Tzafrir Cohen Commit ID: d9b28f9ee7175f990553eb152e0995b63b37db47 Commit URL: https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff;h=d9b28f9ee7175f990553eb152e0995b63b37db47 Patch URL: https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff_plain;h=d9b28f9ee7175f990553eb152e0995b63b37db47 gbp-mock: handle single letter options by properly handling '-?' to request help output. Closes: #847464 A snapshot build including this change will be available at http://honk.sigxcpu.org:8001/job/git-buildpackage/
Bug#847464: git-buildpackage-rpm: mock script fails to handle single-letter parameters
Package: git-buildpackage-rpm
Version: 0.8.7
Severity: minor
Dear Maintainer,
There's a typo in gbp-builder-mock which makes it reject command-line
with a single-letter parameter:
$ gbp buildpackage-rpm --git-mock --git-dist=epel-5 -D "A B"
gbp:info: Creating (native) source archive git-buildpackage_0.7.0.tar.gz
from 'HEAD'
/usr/share/git-buildpackage/gbp-builder-mock: Must be run via 'gbp
buildpackage-rpm', see manpage for details
Patch attached ('\?' instead of '?'). I'm not really sure what the
author meant there, but maybe just remove the '?'?
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf
Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages git-buildpackage-rpm depends on:
ii cpio 2.11+dfsg-6
ii git-buildpackage 0.8.7
ii python-rpm4.12.0.2+dfsg1-1
pn python:any
ii rpm 4.12.0.2+dfsg1-1
Versions of packages git-buildpackage-rpm recommends:
ii pristine-tar 1.37
Versions of packages git-buildpackage-rpm suggests:
ii mock 1.2.18-1
ii python-notify 0.1.1-4
ii unzip 6.0-20
ii zipmerge 1.1.2-1.1
-- no debconf information
>From 5b591b915246d8bdee3f688c61bfa091a7a2ff22 Mon Sep 17 00:00:00 2001
From: Tzafrir Cohen
Date: Thu, 8 Dec 2016 14:55:40 +0200
Subject: [PATCH] builder-mock: Fix passing single-letter parameters
Fixes the following:
$ gbp buildpackage-rpm --git-mock --git-dist=epel-5 -D "A B"
gbp:info: Creating (native) source archive git-buildpackage_0.7.0.tar.gz
from 'HEAD'
/usr/share/git-buildpackage/gbp-builder-mock: Must be run via 'gbp
buildpackage-rpm', see manpage for details
---
bin/gbp-builder-mock | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bin/gbp-builder-mock b/bin/gbp-builder-mock
index 1e93493..3a251a6 100755
--- a/bin/gbp-builder-mock
+++ b/bin/gbp-builder-mock
@@ -38,7 +38,7 @@ usage() {
while [ $# != 0 ]; do
case "$1" in
- --help|-h|-?) usage 0;;
+ --help|-h|-\?) usage 0;;
*.spec) SPEC="$1";;
esac
shift
--
2.10.2
Bug#846936: git-buildpackage-rpm: import-srpm: upstream tag should only upstream version
On Sun, Dec 04, 2016 at 08:00:29PM +0100, Guido Günther wrote:
> control: tags -1 +confirmed
>
> On Sun, Dec 04, 2016 at 03:20:34PM +0200, Tzafrir Cohen wrote:
> > Package: git-buildpackage-rpm
> > Version: 0.8.7
> > Severity: minor
> >
> > Dear Maintainer,
> >
> > After I import a package with gbp import-srpm, I get the following tags:
> >
> > packaging/1.0-1 (Points to master)
> > upstream/1.0-1 (Points to upstream)
> >
> > The packaging tag is OK. However the upstream tag is not what gbp
> > buildpackage-rpm expects.
>
> Confirmed. The created upstream tag is not correct. I'll have a look...
Here's another one. dbus-1.6.12-14.el7_2.src.rpm .
Archive generated:
* 972922d (HEAD -> master, tag: packaging/1%1.6.12-14) Import Downstream
release 1:1.6.12-14
* a2f126a (tag: upstream/1%1.6.12-14, upstream) Import Upstream version 1.6.12
Version:
Epoch: 1
Version: 1.6.12
Release: 14%{?dist}
buildpackage-rpm looks for the tag 'upstream/1.6.12' (that is: with
no epoch), whereas import-srpm created a tag with epoch. Which should it
be? I suppose that the one with epoch.
--
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il || best
tzaf...@debian.org|| friend
Bug#846479: [git-buildpackage/master] specfile: handle %patch -F
tag 846479 pending thanks Date: Thu Dec 1 13:31:48 2016 +0200 Author: Tzafrir Cohen Commit ID: 73d30ef38a57fd5b10d862c8311a08196f24e001 Commit URL: https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff;h=73d30ef38a57fd5b10d862c8311a08196f24e001 Patch URL: https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff_plain;h=73d30ef38a57fd5b10d862c8311a08196f24e001 specfile: handle %patch -F The %patch macro of rpm supports the flag -F, which seems to be similar to that of patch(1): allow patches with a specific fuzz. Parse the option but ignore it since we don't want patches with fuzz. Closes: #846479 A snapshot build including this change will be available at http://honk.sigxcpu.org:8001/job/git-buildpackage/
Bug#846479: git-buildpackage-rpm: fails to handle %patch -F in specs
On Mon, Dec 05, 2016 at 07:20:42PM +0100, Guido Günther wrote: > Hi Tzafrir, > On Thu, Dec 01, 2016 at 01:31:48PM +0200, Tzafrir Cohen wrote: > > Package: git-buildpackage-rpm > > Version: 0.8.7 > > Severity: minor > > > > Dear Maintainer, > > > > I'm not sure yet as of which version, but the %patch macro of rpm > > supports the flag -F, which seems to be similar to that of > > patch(1): allow patches with a specific fuzz. > > > > If the spec has the line '%patch0 -p1 -F2', you would get the following > > error: > > > > Usage: gbp [options] > > > > gbp: error: no such option: -F > > > Can you please give some details _which_ subcommand you are invoking > with which options and which repo? Either buildpackagee-rpm or import-srpm. Options were irrelevant. OK. Here's a test case, sorry for not including it earlier: git init test cd test touch 1.patch cat <test.spec Name: test Version: 1.0 Release: 1 Summary: sum License: lic Patch1: 1.patch %description %prep %patch1 -F2 EOF git add test.spec 1.patch git commit -m "test repo" gbp buildpackage-rpm -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#846936: git-buildpackage-rpm: import-srpm: upstream tag should only upstream version
Package: git-buildpackage-rpm Version: 0.8.7 Severity: minor Dear Maintainer, After I import a package with gbp import-srpm, I get the following tags: packaging/1.0-1 (Points to master) upstream/1.0-1 (Points to upstream) The packaging tag is OK. However the upstream tag is not what gbp buildpackage-rpm expects. With this I get an error: gbp:error: Invalid upstream treeish upstream/1.0 Workaround: git tag -a -m upstream/1.0 upstream/1.0 upstream -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages git-buildpackage-rpm depends on: ii cpio 2.11+dfsg-5 ii git-buildpackage 0.8.7 ii python-rpm4.12.0.2+dfsg1-1 pn python:any ii rpm 4.12.0.2+dfsg1-1 Versions of packages git-buildpackage-rpm recommends: ii pristine-tar 1.37 Versions of packages git-buildpackage-rpm suggests: ii mock 1.2.18-1 ii python-notify 0.1.1-4 ii unzip 6.0-20 ii zipmerge 1.1.2-1.1 -- no debconf information
Bug#846479: git-buildpackage-rpm: fails to handle %patch -F in specs
Package: git-buildpackage-rpm
Version: 0.8.7
Severity: minor
Dear Maintainer,
I'm not sure yet as of which version, but the %patch macro of rpm
supports the flag -F, which seems to be similar to that of
patch(1): allow patches with a specific fuzz.
If the spec has the line '%patch0 -p1 -F2', you would get the following
error:
Usage: gbp [options]
gbp: error: no such option: -F
Which is also rather confusing and gives no good indication where to
look for the issue.
Workaround:
diff --git a/gbp/rpm/__init__.py b/gbp/rpm/__init__.py
index 2d37cca..0509bdc 100644
--- a/gbp/rpm/__init__.py
+++ b/gbp/rpm/__init__.py
@@ -326,6 +326,7 @@ class SpecFile(object):
patchparser.add_option("-P", dest="patchnum")
patchparser.add_option("-b", dest="backup")
patchparser.add_option("-E", dest="removeempty")
+patchparser.add_option("-F", dest="fuzz")
arglist = args.split()
return patchparser.parse_args(arglist)[0]
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf
Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages git-buildpackage-rpm depends on:
ii cpio 2.11+dfsg-5
ii git-buildpackage 0.8.7
ii python-rpm4.12.0.2+dfsg1-1
pn python:any
ii rpm 4.12.0.2+dfsg1-1
Versions of packages git-buildpackage-rpm recommends:
ii pristine-tar 1.37
Versions of packages git-buildpackage-rpm suggests:
ii mock 1.2.18-1
ii python-notify 0.1.1-4
ii unzip 6.0-20
ii zipmerge 1.1.2-1.1
-- no debconf information
Bug#845144: asterisk console scrambles (or misinterprets) input
control: tags -1 +patch +upstream On Sun, Nov 20, 2016 at 09:20:29PM +0200, Tzafrir Cohen wrote: > Thanks, > > This behaves even worse than I remembered it. > > It seems that there is a random unicode character (different at any > invocation) or-ed with the characters printed. I connected several times > and types 'abc', and got: > > pungenday*CLI> \U+89F61\U+89F62\U+89F63 > > pungenday*CLI> \U+7C61\U+7C62\U+7C63 > > pungenday*CLI> \U+4B61\U+4B62\U+4B63 > > Occasiionally when you press Enter it is not intepreted as a newline: > > pungenday*CLI> \U+AFD61\U+AFD62\U+AFD63\U+AFD0A\U+AFD0A\U+AFD0A\U+AFD0A > > Something is terribly wrong. I verified that this reproduced on git master from 4-Nov (which is what I had in my working copy), but after I updated to the latest version, the issue was resolved. It seems to be: https://issues.asterisk.org/jira/browse/ASTERISK-26592 So I guess we can wait for asterisk 13.13 (RC1 of it was tagged). -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com
Bug#845144: asterisk console scrambles (or misinterprets) input
Thanks, This behaves even worse than I remembered it. It seems that there is a random unicode character (different at any invocation) or-ed with the characters printed. I connected several times and types 'abc', and got: pungenday*CLI> \U+89F61\U+89F62\U+89F63 pungenday*CLI> \U+7C61\U+7C62\U+7C63 pungenday*CLI> \U+4B61\U+4B62\U+4B63 Occasiionally when you press Enter it is not intepreted as a newline: pungenday*CLI> \U+AFD61\U+AFD62\U+AFD63\U+AFD0A\U+AFD0A\U+AFD0A\U+AFD0A Something is terribly wrong. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com
Bug#845001: xdotool: incorrect example in man page regarding firefox
Package: xdotool Version: 1:3.20160512.1-1 Severity: minor Dear Maintainer, A trivial issue: The man page gives two example on how to search for a Firefox window: This search works: # Activate firefox and do a web search in a new tab for text in your clipboard xdotool behave_screen_edge --delay 1000 top-left \ search --classname Navigator \ windowactivate --sync key --delay 250 ctrl+t ctrl+k ctrl+v Retur This doesn't: xdotool search --class firefox windowactivate Relevant output from xprop: WM_CLASS(STRING) = "Navigator", "Firefox" Specifically: $ xdotool search --class firefox 109051905 109051975 109052004 109052008 109052035 109052843 109065960 109194407 110328564 110596174 109212393 110323309 109837753 110075782 110317473 110750531 110340178 110006557 110833306 110882835 110005980 110504017 110006740 109191739 109063479 109052011 $ xdotool search --class firefox getwindowname Firefox $ xdotool search --class firefox windowactivate XGetWindowProperty[_NET_WM_DESKTOP] failed (code=1) $ xdotool search --classname Navigator 109052011 $ xdotool search --classname Navigator getwindowname Bugs in package xdotool (version 1:3.20160512.1-1) in unstable -- Debian Bug report logs - Mozilla Firefox $ xdotool search --classname Navigator windowactivate # Switches to the Firefox window -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xdotool depends on: ii libc6 2.24-5 ii libx11-6 2:1.6.3-1 ii libxdo3 1:3.20160512.1-1 xdotool recommends no packages. xdotool suggests no packages. -- no debconf information
Bug#834582: git-buildpackage-rpm: pq-rpm export creates patches with full path names
control: tag -1 +patch
On Wed, Aug 17, 2016 at 12:15:35PM +0300, Tzafrir Cohen wrote:
>
> When exporting a patch series using 'gbp pq-rpm export', spec is updated
> to include them. However the patches are included with full pathes.
Patch attached: if patch file is under the working directory, a relative
path is used.
--
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il || best
tzaf...@debian.org|| friend
>From 972edd2445c09544cb6c480daaada7b25211230c Mon Sep 17 00:00:00 2001
From: Tzafrir Cohen
Date: Wed, 16 Nov 2016 18:15:14 +0200
Subject: [PATCH] rpm: pq-rpm export: relative patch names
'gbp pq-rpm export' will now create relative file names instead of
absolute ones.
---
gbp/rpm/__init__.py | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/gbp/rpm/__init__.py b/gbp/rpm/__init__.py
index 5a9a668..2d37cca 100644
--- a/gbp/rpm/__init__.py
+++ b/gbp/rpm/__init__.py
@@ -678,11 +678,14 @@ class SpecFile(object):
comment_text = "# Patches auto-generated by git-buildpackage:\n"
tag_line = self._content.insert_after(tag_line, comment_text)
for ind, patch in enumerate(patches):
+patch_path = patch
+if patch.find(os.getcwd()) == 0:
+patch_path = os.path.relpath(patch)
cmds = commands[patch] if patch in commands else {}
patchnum = startnum + ind
-tag_line = self._set_tag("Patch", patchnum, patch, tag_line)
+tag_line = self._set_tag("Patch", patchnum, patch_path, tag_line)
# Add '%patch' macro and a preceding comment line
-comment_text = "# %s\n" % patch
+comment_text = "# %s\n" % patch_path
macro_line = self._content.insert_after(macro_line, comment_text)
macro_line = self._set_special_macro('patch', patchnum, '-p1',
macro_line)
--
2.10.2
Bug#843654: Use Debian pjproject and libsrtp
On Tue, Nov 08, 2016 at 04:15:49PM +0100, Andrey Gursky wrote: > Source: ring > Version: 20161104.4.17a0616~dfsg1-2 > Severity: normal > > Dear maintainer, > > A week ago pjproject 2.5.5 has been made available in Debian. The same > as in ring-daemon contribs. However ring applies following patches: > endianness.patch > gnutls.patch > notestsapps.patch > ipv6.patch > ice_config.patch > multiple_listeners.patch > pj_ice_sess.patch > fix_turn_fallback.patch > fix_ioqueue_ipv6_sendto.patch > > The biggest one gnutls.patch can be dropped, since packaged pjproject > can dynamically link to a SSL library. Is the rest important? If not, > then the packaged pjproject could be used already. If not, is pjproject > not really usable without them? Then they should be forwarded upstream > and for now applied in the packaged pjproject. Or there are some issues > with that? Please share the current status. For the record, pjproject is currently used by a single other package: asterisk. Upstream of asterisk recommends applying a set of their own patches: http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=tree;f=third-party/pjproject/patches;hb=13 -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#759896: postfix: newaliases fails under qemu-user-static chroot
Hi, I'm not sure if this is what the original report was about, but this is a problem I have in Jessie, and seems to be resolved in Stretch. I create an armhf chroot using qemu-debootstrap. Installing postfix in it fails with the same error message. There's an existing bug report in Ubuntu about it with more details: https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1531299 It seems qemu fails to implement a certain kernel detail needed for netlink. I didn't dig deep enough down there to see why it was needed for newaliases. Reproduced in Jessie's postfix (2.11.3-1). Not reproduced with the version in Stretch (3.1.3-2). Both using the version of qemu in Stretch (qemu-user-static 1:2.7+dfsg-3). To reproduce: 0. Pre-requirements: apt install qemu-user-static deboostrap 1. create a new chroot: debootstrap --arch=armhf $DISTRO root-dir 2. install postfix in it: # for those without systemd: configure schroot. Or maybe even a plain # chroot would do: systemd-nspawn -D root-dir -- apt install postfix -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#842917: asterisk builds with -march=native
tag 842917 +pending thanks Also, On Wed, Nov 02, 2016 at 12:23:11PM +0200, Adrian Bunk wrote: > Source: asterisk > Version: 1:13.11.2~dfsg-1 > Severity: grave > > https://buildd.debian.org/status/fetch.php?pkg=asterisk&arch=amd64&ver=1:13.11.2~dfsg-1&stamp=1477641275 > > ... > checking for -march=native support... yes > ... For the record: The Asterisk configure script checks for -march=native regardless of whether or not it will be used later. So to see if this issue re-appears, check for -march=native in the build command itself and ignore the line above in the configure script output. Thanks for your report. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com
Bug#841004: dahdi-source: Provide dkms setup to build kernel module automatically?
On Sun, Oct 16, 2016 at 09:01:12PM +0200, Petter Reinholdtsen wrote: > > Package: dahdi-source > Version: 1:2.10.0.1~dfsg-1 > Severity: wishlist > > Hi. Looking at the dahdi-source package, it occured to me that perhaps > it would be a good idea to use the dkms system to build the dahdi kernel > module automatically? Would it be possible? Is it a good idea? This is one of the changes in the Ubuntu package. Personally for me I prefer d-i, as it allows producing stand-alone packages, which better fit my use case. As long as this is not broken, I have no objection. One annoying aspect of dkms is that there's a template that needs to be created. It is possible to create it manually. But it is annoying for a package with so many modules such as DAHDI (and some are added on patching). Automating it would be a bonus. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#776622: dahdi-linux: please make the build reproducible
On Fri, Sep 16, 2016 at 09:50:54AM +0100, Chris Lamb wrote: > Dear Maintainer, > > > Source: dahdi-linux > > Version: 1:2.3.0.1+dfsg-2 > > Tags: patch > > There hasn't seem to be any update on this bug in 32 days, in which > time the Reproducible Builds effort has come on a long way. :) > > Would you consider applying this patch and uploading? Thanks for the reminder. Half of this has already been fixed upstream. I have applied the other half. I'm waiting for a followup on another issue and this should be uploaded this week. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#795458: dahdi-linux: have a debian/README.source
On Mon, Aug 17, 2015 at 08:45:34PM +0300, Tzafrir Cohen wrote: > On Mon, Aug 17, 2015 at 12:41:52PM +0200, Geert Stappers wrote: > > On Sun, Aug 16, 2015 at 10:55:44PM +0300, Tzafrir Cohen wrote: > > > On Fri, Aug 14, 2015 at 09:50:53AM +0200, Geert Stappers wrote: > > > > > > > > Please provide a debian/README.source that tells > > > > how to build the dahdi-linux package > > > > > > Quoting the top of README.Debian from dahdi-linux / dahdi-source: > > > > > > Building kernel modules > > > --- > > > First, install dahdi-source package if you have not yet done so. > > > > > > You can build and install the modules package (as root) with the > > > following command: > > > # module-assistant a-i dahdi > > > > > > > > > > Benefits of knowning to build dahdi packages from > > Debian version control system: > > > > * Avoiding installing build dependencies on computer(s) with the DAHDI > > hardware > > * Building on faster computer > > * Having the workflow documented, making Aloith pkg-voip team stronger > > The package has a script, intended for internal testing, that runs m-a > build at the end of the pacage build to build a modules package: > debian/modulestest . > > Internally (in Xorcom) we have a modified package that builds kernel > modules at dahdi-linux package build time. The down side to that is that > you can only build modules for a single kernel (and have to set that > kernel version ahead of build time. We use an ugly hack to set that as > you really can't edit the build-depends in a package at build time. > > So, are you looking for better documentation of debian/modulestest ? Documenting this more explicitly in the README.Debian and closing the bug. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend
Bug#823952: dahdi-source: AXE400PL + linux 3.16.0-4-686-pae + dahdi 1:2.10.2-2
Hi,
On Tue, May 10, 2016 at 06:54:46PM +0200, Carlos Martin wrote:
> When system loads dahdi module yo can see the message "Warning: Span WCTDM/4
> didn't specify a spantype. Please fix driver!"
> Kernel driver in use: wctdm
Thanks for your report and sorry for not answering earlier.
>From what I can see, this issue should apply to original Digium cards as
well. As you can see in lspci, the driver handling this card is wctdm.
Sorry for not picking this up earlier.
The fix for this should be the following patch:
diff --git a/drivers/dahdi/wctdm.c b/drivers/dahdi/wctdm.c
index 9f43e52..cf5a537 100644
--- a/drivers/dahdi/wctdm.c
+++ b/drivers/dahdi/wctdm.c
@@ -2411,6 +2411,7 @@ static int wctdm_initialize(struct wctdm *wc)
wc->span.channels = NUM_CARDS;
wc->span.flags = DAHDI_FLAG_RBS;
wc->span.ops = &wctdm_span_ops;
+ wc->span.spantype = SPANTYPE_ANALOG_MIXED;
list_add_tail(&wc->span.device_node, &wc->ddev->spans);
if (dahdi_register_device(wc->ddev, &wc->dev->dev)) {
Any chance you could test this? I'll try to see if I have any such card
available.
--
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il || best
tzaf...@debian.org|| friend
Bug#834582: git-buildpackage-rpm: pq-rpm export creates patches with full path names
Package: git-buildpackage-rpm Version: 0.7.5 Severity: normal When exporting a patch series using 'gbp pq-rpm export', spec is updated to include them. However the patches are included with full pathes. For instance: Patch0: /path/to/work/dir/0001-fix-problem.patch ... # /path/to/work/dir/0001-fix-problem.patch %patch0 -p1 Instead of: Patch0: 0001-fix-problem.patch ... # 0001-fix-problem.patch %patch0 -p1 The comment is a cometic issue, but the full path to the file would be wrong when the package is used in a different directory. Note that merely stripping out the full path would not do, as the user may use a packaging directory: Patch0: /path/to/work/dir/rpm/0001-fix-problem.patch ... # /path/to/work/dir/rpm/0001-fix-problem.patch %patch0 -p1 With should instead be: Patch0: rpm/0001-fix-problem.patch ... # rpm/0001-fix-problem.patch %patch0 -p1 -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages git-buildpackage-rpm depends on: ii cpio 2.11+dfsg-5 ii git-buildpackage 0.7.5 ii python-rpm4.12.0.1+dfsg1-4 pn python:any ii rpm 4.12.0.1+dfsg1-4 Versions of packages git-buildpackage-rpm recommends: ii pristine-tar 1.34 Versions of packages git-buildpackage-rpm suggests: ii mock 1.2.18-1 ii python-notify 0.1.1-4 ii unzip 6.0-20 ii zipmerge 1.1.2-1.1 -- no debconf information
Bug#833167: git-buildpackage-rpm: rpmlint support
Package: git-buildpackage-rpm
Version: 0.7.5
Priority: wishlist
An idea I have and maybe I'll get to implement it one day:
I only now realized that rpmlint is included in Debian. It would be nice
to run it after the end of each build on:
* The spec
* The source package
* Each binary package
However, as-is it would probably be useless, as you'd get many messages.
Thus it would make sense to include an extra configuration file (say,
'rpmlint') in the packaging directory. This file will be in the format
of rpmlint config file (see /etc/rpmlint/config), but would typically
have only:
from Config import *
addFilter("filter1")
addFilter("filter2")
# ...
It will be used for the option -f of rpmlint.
A configuration file that is executable and turing complete is not such
a great idea, but then again, we have the spec.
The name 'rpmlint' may collide with other, existing files. I hope they
could not be interpreted as a lintian config file.
This is intended to eventually be a feature that could be enabled by
default if rpmlint is enabled, just like the lintian support in debuild.
--
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il || best
tzaf...@debian.org|| friend
Bug#833125: debirf: fails to build rescue on sid/stretch: insserv not found
Package: debirf Version: 0.36 Severity: important Dear Maintainer, I tried building a debirf image on my Stretch system. It failed building with an error regarding 'insserv not found' (IIRC). The error persisted when I set the DISTRO to stretch. My workaround: rem-out the last line in rescue/modules/a0_prep-root: # work around http://bugs.debian.org/686965 debirf_exec sh -c 'cd /etc/init.d && insserv $(ls | grep -vFx -e rc -e rcS -e skeleton -e README)' >From what I see, insserv is no longer pulled into a systemd-based system. Should this line become optional or should insserv be pulled explicitly? -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debirf depends on: ii apt 1.3~pre2 ii cpio 2.11+dfsg-5 ii debootstrap 1.0.81 ii fakechroot 2.18-1 ii fakeroot 1.21-1 ii klibc-utils 2.0.4-9 Versions of packages debirf recommends: ii grub-common 2.02~beta2-36 ii lsb-release 9.20160629 ii xorriso 1.4.4-1 Versions of packages debirf suggests: ii syslinux-common 3:6.03+dfsg-14 -- no debconf information
Bug#831179: pjproject: FTBFS with GCC 6: dh_makeshlibs: failing due to earlier errors
On Thu, Jul 14, 2016 at 10:06:57AM +0200, Lucas Nussbaum wrote: > Source: pjproject > Version: 2.5.1~dfsg-2 > Severity: serious > Tags: stretch sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20160713 qa-ftbfs > Justification: FTBFS with GCC 6 on amd64 Thanks for the report. So at first glance: it builds fine but the C++ ABI has changed (most of the pjproject libraries are C, with a single C++ library). -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com
