Bug#1028408: Seems fixed
Hi, This email to say that it seems the bug seems to be fixed for me, I am using gnumeric 1.12.56-2+b1 now. Cheers, Eugen
Bug#1028408: Same here
severity 1028408 important thanks Hi, Just to say that the same applies for me. I have looked at the bur reports (https://gitlab.gnome.org/GNOME/gnumeric/-/issues/?sort=created_date=all_page_size=20), and have not found it. Given that formula results could be wrong, I would raise the severity of this bug. Thanks, Eugen
Bug#1028305: libcotp12: Update libotp to fix grave bug
Package: libcotp12
Version: 1.2.6-2
Severity: grave
Tags: upstream
Justification: renders package unusable
Dear Maintainer,
libotp, and hence otpclient and possibly other applications using this
library, has a grave bug preventing it to be used. Please update to
1.2.8, released yesterday (a few days after previous buggy version 1.2.7).
More information:
https://github.com/paolostivanin/libcotp/releases/tag/v1.2.8 ("This
release fixes a regression brought with v1.2.7. Users must either update
to this release or rollback to v1.2.6.")
Thanks,
Eugen
Bug#1019249: gnuplot-qt: 5.4.4 uninstallable
Subject: gnuplot-qt: 5.4.4 uninstallable Package: gnuplot-qt Version: 5.4.2+dfsg2-2 Severity: important Dear Maintainer, gnuplot-qt 4.4 cannot be installed because gnuplot-data 4.4 is not available: root@snoopy:~# apt-get install gnuplot-qt Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: gnuplot-qt : Depends: gnuplot-data (= 5.4.4+dfsg1-1) but 5.4.2+dfsg2-2 is to be installed E: Unable to correct problems, you have held broken packages. Best regards, Eugen -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnuplot-qt depends on: ii gnuplot-data 5.4.2+dfsg2-2 ii libc6 2.34-7 ii libcairo2 1.16.0-6 ii libedit2 3.1-20210910-1 ii libgcc-s1 12.2.0-1 ii libgd32.3.3-6 ii libglib2.0-0 2.73.3-3 ii liblua5.4-0 5.4.4-3 ii libpango-1.0-01.50.9+ds-1 ii libpangocairo-1.0-0 1.50.9+ds-1 ii libqt5core5a 5.15.4+dfsg-5 ii libqt5gui55.15.4+dfsg-5 ii libqt5network55.15.4+dfsg-5 ii libqt5printsupport5 5.15.4+dfsg-5 ii libqt5svg55.15.4-2 ii libqt5widgets55.15.4+dfsg-5 ii libstdc++612.2.0-1 ii libwxbase3.0-0v5 3.0.5.1+dfsg-4 ii libwxgtk3.0-gtk3-0v5 3.0.5.1+dfsg-4 ii libx11-6 2:1.8.1-2 gnuplot-qt recommends no packages. Versions of packages gnuplot-qt suggests: pn gnuplot-doc -- no debconf information
Bug#1017798: emacs-el
Hi, I had the same problem, and indeed installing emacs-el solved the issue. Best regards, Eugen
Bug#1009169: Any ETA?
Hi Rob, Do you have an ETA? Will it be packaged in one week, one month, several months? Thanks, Eugen
Bug#1005977: fwupd-signed
On 18/02/2022 17:31, Harlan Lieberman-Berg wrote: It looks like this is due to the migration of the efi capsule out to the virtual packages fwupd-signed and fwupd-unsigned. Installing one should fix the problem, but this bug should remain open to fix the underlying Recommends’ bug.-- Indeed, installing fwupd-signed fixes the problem, thank you. Eugen
Bug#1005977: fwupd: Cannot update anymore, fwupdx64.efi... cannot be found
Subject: fwupd: Cannot update anymore, fwupdx64.efi... cannot be found Package: fwupd Version: 1.7.5-1 Severity: grave Justification: renders package unusable Dear Maintainer, fwupd does not work on my system anymore. Here is the error when executing fwupdmgr update: Perform operation? [Y|n]: Downloading? [***] Downloading? [***] Decompressing? [***] Decompressing? [***] Authenticating? [***] Authenticating? [***] /usr/libexec/fwupd/efi/fwupdx64.efi and /usr/libexec/fwupd/efi/fwupdx64.efi.signed cannot be found The update had always worked until a few weeks ago. I do not remember when exactly I updated my system the last time, so I do not know exactly the recent version which introduced the problem for me. Tell me if you need me to check the last versions to see which one precisely exhibits the problem. Thank you, Eugen -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fwupd depends on: ii libc6 2.33-6 ii libcurl3-gnutls7.81.0-1 ii libefiboot137-6 ii libflashrom1 1.2-5 ii libfwupd2 1.7.5-1 ii libfwupdplugin51.7.5-1 ii libglib2.0-0 2.70.4-1 ii libgnutls303.7.3-4+b1 ii libgudev-1.0-0 237-2 ii libgusb2 0.3.10-1 ii libjcat1 0.1.9-1 ii libjson-glib-1.0-0 1.6.6-1 ii libmbim-glib4 1.26.2-1 ii libmbim-proxy 1.26.2-1 ii libmm-glib01.18.6-1 ii libpolkit-gobject-1-0 0.105-31.1+b1 ii libprotobuf-c1 1.3.3-1+b2 ii libqmi-glib5 1.30.4-1 ii libqmi-proxy 1.30.4-1 ii libsmbios-c2 2.4.3-1 ii libsqlite3-0 3.37.2-2 ii libsystemd0250.3-2 ii libtss2-esys-3.0.2-0 3.1.0-3 ii libxmlb2 0.3.6-2 ii shared-mime-info 2.1-2 Versions of packages fwupd recommends: ii bolt 0.9.2-1 ii dbus 1.12.20-3 pn fwupd-signed ii python33.9.8-1 pn secureboot-db ii udisks22.9.4-1 Versions of packages fwupd suggests: pn gir1.2-fwupd-2.0 -- no debconf information
Bug#998108: reopening 998108
On 21/11/2021 00:43, Christoph Anton Mitterer wrote: On Sat, 2021-11-20 at 15:30 -0800, Josh Triplett wrote: I'm still experiencing this bug regularly, with complete browser UI freezes that require killing and restarting Firefox. Hm perhaps something else? At least I haven't suffered from that particular issue since 94.0-2. 94.0-2 fixed the issue for me too.
Bug#998108: Tracking this bug down
Maybe I am wrong, but, for me, the simplest method to track this bug down is to check the changes between the two versions, 93.0 and 93.0-1+b1. Firefox code has not changed, only one or some libraries it depends on. I thought that the only change is in libvpx version, but, surprisingly, a previous comment mentions that rebuilding firefox with old vpx (libvpx6) still exhibits the bug. I think that libc6 is out of question, because the last package is 19 Sep, too old wrt this bug; the same for gcc-11, the last package being on 21 Oct. Doesn't this (checking the changes) sound like a good approach to find the cause of the problem?
Bug#998108: firefox freezes shortly after start
On Sat, 30 Oct 2021 20:33:31 +0200 Olivier Allard-Jacquin wrote: According to "strace" command, this is look faulted tab open nvidia library, so maybe issue is linker to video acceleration. I do not have nvidia, still I have this problem.
Bug#998108: Freeze with jitsi
I have similar problems. When I go to jitsi, for ex. https://meet.jit.si/toto, firefox is unresponsive: it does not finish loading the tab (the blue point in the tab moves left-right), and clicking anywhere in firefox window (menu, tabs, page content) does not change anything. I need to kill it with ctrl-c (in linux). Nothing is exchanged on the network; CPU is small, cf. 'top' tool: PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 15790 ededu 20 0 3376132 402248 170036 S 13.3 2.5 0:19.66 GeckoMain However, it is the first time I see GeckoMain shown in the first lines of 'top' (13.3% in the example above). Downgrading from 93.0-1+b1 to 93.0-1 fixes the problem.
Bug#976026: util-linux: man lsof gives 'No such file or directory' error
Subject: util-linux: man lsof gives 'No such file or directory' error Package: util-linux Version: 2.36.1-2 Severity: minor Dear Maintainer, 'man lsof' gives: man: can't open /usr/share/man/./version: No such file or directory No manual entry for lsof Best regards.
Bug#947613: [Pkg-utopia-maintainers] Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
On 08/01/2020 16:07, Michael Biebl wrote: Anyone willing to check the proposed fix https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/848b869c6ede3a796872a0b5cd8b2398804c3697 Hi, I tested the proposed patch on top of debian's 1.22.2-1 version. This patch does NOT fix the issue. I would say it is even worse. The network-manager-gnome icon in the task bar (I use awesome window manager) turns around and restarts several times, each time with a different MAC address (as shown by ifconfig) and getting and losing an inet6 address. After around 10 restarts, it finally stops and shows "NetworkManager is not running". I could provide a small video if it helps. Cheers. Eugen
Bug#947613: [Pkg-utopia-maintainers] Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
On 29/12/2019 13:40, Michael Biebl wrote: Can you provide a full, verbose debug log: https://wiki.gnome.org/Projects/NetworkManager/Debugging Which dhcp client do you use: internal, isc-dhcp-client, ...? I made more tests and noticed that when I upgrade from 1.22.0-2 to 1.22.2-1, the IPv4 still works, even if I associate several times to the Internet box. The problem comes when I *restart* my Internet box. So: I have my laptop running and IPv4 ok with 1.22.2-1. I restart my Internet box. Around one minute later, I have an IPv6 address, but no IPv4 address, as shown by syslog: root@snoopy:~# grep IPv /var/log/syslog|tail Dec 30 14:06:04 snoopy avahi-daemon[24644]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:06:04 snoopy avahi-daemon[24644]: Interface wlp1s0.IPv6 no longer relevant for mDNS. Dec 30 14:06:04 snoopy avahi-daemon[24644]: Leaving mDNS multicast group on interface wlp1s0.IPv4 with address 192.168.0.37. Dec 30 14:06:04 snoopy avahi-daemon[24644]: Interface wlp1s0.IPv4 no longer relevant for mDNS. Dec 30 14:07:44 snoopy kernel: [1688643.441802] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready Dec 30 14:07:44 snoopy avahi-daemon[24644]: Joining mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:07:44 snoopy avahi-daemon[24644]: New relevant interface wlp1s0.IPv6 for mDNS. Dec 30 14:07:47 snoopy avahi-daemon[24644]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:07:47 snoopy avahi-daemon[24644]: Joining mDNS multicast group on interface wlp1s0.IPv6 with address 2a01:e0a:290:82e0:5815:8149:bcb4:18b0. Dec 30 14:07:48 snoopy NetworkManager[2495]: [1577711268.6351] policy: set 'chenoisw' (wlp1s0) as default for IPv6 routing and DNS If I restart network-manager-gnome (the icon in the task bar, I use awesome window manager), syslog file insists on IPv6 only: root@snoopy:~# grep IPv /var/log/syslog|tail -11 Dec 30 14:07:48 snoopy NetworkManager[2495]: [1577711268.6351] policy: set 'chenoisw' (wlp1s0) as default for IPv6 routing and DNS Dec 30 14:21:33 snoopy avahi-daemon[24644]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address 2a01:e0a:290:82e0:5815:8149:bcb4:18b0. Dec 30 14:21:33 snoopy avahi-daemon[24644]: Joining mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:21:33 snoopy avahi-daemon[24644]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:21:33 snoopy avahi-daemon[24644]: Interface wlp1s0.IPv6 no longer relevant for mDNS. Dec 30 14:21:35 snoopy kernel: [1689473.467493] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready Dec 30 14:21:35 snoopy avahi-daemon[24644]: Joining mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:21:35 snoopy avahi-daemon[24644]: New relevant interface wlp1s0.IPv6 for mDNS. Dec 30 14:21:36 snoopy avahi-daemon[24644]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address fe80::bf01:6fea:9592:b415. Dec 30 14:21:36 snoopy avahi-daemon[24644]: Joining mDNS multicast group on interface wlp1s0.IPv6 with address 2a01:e0a:290:82e0:5815:8149:bcb4:18b0. Dec 30 14:21:38 snoopy NetworkManager[2495]: [1577712098.1291] policy: set 'chenoisw' (wlp1s0) as default for IPv6 routing and DNS root@snoopy:~# ifconfig shows: wlp1s0: flags=4163 mtu 1300 inet6 2a01:e0a:290:82e0:5815:8149:bcb4:18b0 prefixlen 64 scopeid 0x0 inet6 fe80::bf01:6fea:9592:b415 prefixlen 64 scopeid 0x20 ether ... txqueuelen 1000 (Ethernet) RX packets 15747787 bytes 15483453634 (14.4 GiB) [...] Now, I downgrade to previous version: root@snoopy:/home/ededu# dpkg -i *22.* dpkg: warning: downgrading gir1.2-nm-1.0:amd64 from 1.22.2-1 to 1.22.0-2 (Reading database ... 330241 files and directories currently installed.) Preparing to unpack gir1.2-nm-1.0_1.22.0-2_amd64.deb ... Unpacking gir1.2-nm-1.0:amd64 (1.22.0-2) over (1.22.2-1) ... dpkg: warning: downgrading libnm0:amd64 from 1.22.2-1 to 1.22.0-2 Preparing to unpack libnm0_1.22.0-2_amd64.deb ... Unpacking libnm0:amd64 (1.22.0-2) over (1.22.2-1) ... dpkg: warning: downgrading network-manager from 1.22.2-1 to 1.22.0-2 Preparing to unpack network-manager_1.22.0-2_amd64.deb ... Unpacking network-manager (1.22.0-2) over (1.22.2-1) ... Setting up libnm0:amd64 (1.22.0-2) ... Setting up network-manager (1.22.0-2) ... Setting up gir1.2-nm-1.0:amd64 (1.22.0-2) ... Processing triggers for libc-bin (2.29-6) ... Processing triggers for systemd (244-3) ... Processing triggers for dbus (1.12.16-2) ... Processing triggers for man-db (2.9.0-2) ... syslog shows some IPv4 activity: root@snoopy:/home/ededu# grep IPv /var/log/syslog|tail -15 Dec 30 14:21:38 snoopy NetworkManager[2495]: [1577712098.1291] policy: set 'chenoisw' (wlp1s0) as default for
Bug#947613: network-manager: Wi-Fi not working (does not get IPv4 address) with 1.22.2-1
Package: network-manager Version: 1.22.0-2 Severity: grave Justification: renders package unusable Dear Maintainer, I have an Internet box and connect to it through Wi-Fi. After upgrading network-manager to 1.22.2-1, my machine does not get an IPv4 address anymore. Specifically, ifconfig shows: wlp1s0: flags=4163 mtu 1300 inet6 ... prefixlen 64 scopeid 0x0 inet6 ... prefixlen 64 scopeid 0x20 ether ... txqueuelen 1000 (Ethernet) RX packets 14389956 bytes 13801531443 (12.8 GiB) RX errors 0 dropped 14956 overruns 0 frame 0 TX packets 3398391 bytes 958204966 (913.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 After downloading an older version of network-manager (from snapshot.debian.org) and downgrading everything works fine: root@snoopy:# dpkg -i *1.22.0-2* dpkg: warning: downgrading gir1.2-nm-1.0:amd64 from 1.22.2-1 to 1.22.0-2 (Reading database ... 330245 files and directories currently installed.) Preparing to unpack gir1.2-nm-1.0_1.22.0-2_amd64.deb ... Unpacking gir1.2-nm-1.0:amd64 (1.22.0-2) over (1.22.2-1) ... dpkg: warning: downgrading libnm0:amd64 from 1.22.2-1 to 1.22.0-2 Preparing to unpack libnm0_1.22.0-2_amd64.deb ... Unpacking libnm0:amd64 (1.22.0-2) over (1.22.2-1) ... dpkg: warning: downgrading network-manager from 1.22.2-1 to 1.22.0-2 Preparing to unpack network-manager_1.22.0-2_amd64.deb ... Unpacking network-manager (1.22.0-2) over (1.22.2-1) ... Setting up libnm0:amd64 (1.22.0-2) ... Setting up network-manager (1.22.0-2) ... Setting up gir1.2-nm-1.0:amd64 (1.22.0-2) ... Processing triggers for libc-bin (2.29-6) ... Processing triggers for systemd (244-3) ... Processing triggers for dbus (1.12.16-2) ... Processing triggers for man-db (2.9.0-2) ... Best regards, Eugen Dedu http://eugen.dedu.free.fr -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages network-manager depends on: ii adduser3.118 ii dbus 1.12.16-2 ii init-system-helpers1.57 ii libaudit1 1:2.8.5-2+b1 ii libbluetooth3 5.50-1+b1 ii libc6 2.29-6 ii libcurl3-gnutls7.67.0-2 ii libglib2.0-0 2.62.3-2 ii libgnutls303.6.11.1-2 ii libjansson42.12-1 ii libmm-glib01.10.4-0.1 ii libndp01.6-1+b1 ii libnewt0.520.52.21-4 ii libnm0 1.22.0-2 ii libpam-systemd 244-3 ii libpolkit-agent-1-00.105-26 ii libpolkit-gobject-1-0 0.105-26 ii libpsl50.20.2-2 ii libreadline8 8.0-3 ii libselinux13.0-1 ii libsystemd0244-3 ii libteamdctl0 1.29-1 ii libudev1 244-3 ii libuuid1 2.34-0.1 ii policykit-10.105-26 ii udev 244-3 ii wpasupplicant 2:2.9-3+b1 Versions of packages network-manager recommends: ii crda 3.18-1 ii dnsmasq-base [dnsmasq-base] 2.80-1.1 ii iptables 1.8.4-1 ii modemmanager 1.10.4-0.1 pn ppp Versions of packages network-manager suggests: ii isc-dhcp-client 4.4.1-2 pn libteam-utils -- no debconf information
Bug#598351: texlive-latex-base: Error when using lmodern fonts together with T1 fontenc
On 13/08/2019 17:50, Hilmar Preuße wrote: In case the solution above is acceptable for you, let me know. For me this is fine. Best regards, Eugen
Bug#598351: texlive-latex-base: Error when using lmodern fonts together with T1 fontenc
On 05/08/2019 17:18, Hilmar Preuße wrote:
Am 04.08.2019 um 21:39 teilte Hilmar Preuße mit:
Am 28.09.2010 um 14:30 teilte Eugen Dedu mit:
Hi,
Does this address work?
I have an error when using lmodern fonts together with T1 fontenc (as
required by French babel to have correct hyphenation on accentuated
characters). When using pdflatex or latex on the following text:
It is still unclear why the mf files from the EC fonts are used, when
lmodern fonts are requested. I forwarded the question to tex.sx.
https://tex.stackexchange.com/questions/502820/lmodern-latex-tries-to-create-tfm-files-for-ec-fonts
Update: add the following line right after loading the lmodern package
then it works:
\fontfamily{\familydefault}\selectfont
Now I have texlive-latex-recommended installed (it is needed by several
other packages), and there is no error. Do you want me to do something?
Eugen
Bug#925337: Upload to unstable?
On 29/03/2019 17:55, Markus Koschany wrote:
Am 29.03.19 um 17:38 schrieb Eugen Dedu:
Wouldn't it make sense to upload to unstable instead of experimental?
Currently, firefox 66 is in unstable, and does not work with ublock
origin from unstable. People who track unstable have to figure out that
they need to install ublock origin from experimental to make it work
with firefox.
I am sorry but Debian development is frozen. If someone discovers an
issue in ublock-origin that affects the Firefox ESR browser in testing,
I have to make an upload to unstable first which would replace the old
version in unstable. Also there is an easy workaround: just use Firefox
ESR for now, if you don't want to use the experimental version.
I am not sure that I have well understood the situation, so sorry if I
am wrong. I put myself in the place of debian users.
Currently in unstable we have two dependent packages which do not work
together. This is not what users expect: they expect debian to just
work, not bothering with installing some package from experimental to
make an unstable package work.
(This remembers me another story, with an update of an essential package
which made it stop functioning: I was told that this is not a
regression, I have just to create a file in my home directory ("look in
Internet for the lines to put inside") to make it work again. Can we
expect users do this??)
Even if debian is in freeze, I think there is a strong reason for debian
managers to accept the new ublock origin. Indeed, they uploaded the
huge firefox in unstable a few days ago, and now the two packages are
incompatible.
Sorry again if I missed something.
Cheers,
Eugen
Bug#925337: Upload to unstable?
Wouldn't it make sense to upload to unstable instead of experimental? Currently, firefox 66 is in unstable, and does not work with ublock origin from unstable. People who track unstable have to figure out that they need to install ublock origin from experimental to make it work with firefox.
Bug#902633: php-mode
On 02/02/2019 13:21, Eugen Dedu wrote: Ok, I add in CC bug 902633. Thank you, Nicholas, for having packaged yesterday the new release of php-mode. One more remark (perhaps out of topic): it seems to me that Debian recommends to use NEWS.gz instead of changelog.gz for the upstream changelog file name. Best regards, -- Eugen
Bug#902633: php-mode
Hi,
Ok, I add in CC bug 902633.
So basically we have been waiting for 6 months to package a new release
of php-mode because we have not obtained the copyright for the following
lines in the changelog:
php-elisp (1.5.0-1) unstable; urgency=low
* New upstream release (Closes: #368061, #291207)
* New maintainer (Closes: #525947)
* debian/control:
+ bumped Standards-Version to 3.8.4
+ added ${misc:Depends} in Depends
+ updated Depends to emacs23 | emacs22 | emacsen
+ updated Suggests to php5 | php5-cli
+ updated Section to lisp
+ added in Recommends field speedbar (Closes: #500120)
+ used debhelper 7
+ added Homepage field
+ added texi2html in Build-Depends to generate manual (Closes: #476197)
* debian/rules:
+ removed emacs21 references (Closes: #269650)
+ used binary-indep instead of binary-arch target
* debian/copyright
+ added copyright notice
* Added compat, docs, watch files
* switched to dpkg-source 3.0 (quilt) format
-- Thierry Randrianiriana Sun, 09 May 2010
09:00:55 +0300
As for the other 14 lines (I do see which lines you mention here,
perhaps only directory paths in *.dir files?), this means that any
program with the following code has already 7 copyrighted lines:
// Hello world program
#include
int main (int argc, char *argc) {
printf ("Hello world!");
return 0;
}
Perhaps I am wrong, but, to me, all this seems overstated.
Best regards,
Eugen
On 02/02/2019 00:54, Nicholas D Steeves wrote:
Hi Eugen,
For future reference, correspondences like this are supposed to be on
the Debian BTS. Reply follows inline.
On Sun, Jan 27, 2019 at 07:58:42PM +0100, Eugen Dedu wrote:
Hi Nicholas,
On 26/01/2019 21:56, Nicholas D Steeves wrote:
Hi Eugen,
On Sat, Jan 26, 2019 at 08:16:35PM +0100, Eugen Dedu wrote:
On 13/01/2019 09:58, Eugen Dedu wrote:
On 13/01/2019 04:04, Nicholas D Steeves wrote:
Hi Eugen,
On Wed, Jan 09, 2019 at 01:59:56PM +0100, Eugen Dedu wrote:
Hi Nicholas,
Have you succeeded in packaging the new php-mode ? It is a matter of
copy-paste from the other package (yasm... ?)
Regards,
--
Eugen
Yes, I completed the packaging some time ago (ready to upload since 23
jul 2018). I am still waiting for #903092 permission to relicense
debian/* contributions to GPL-3+ from Thierry Randrianiriana and
Pontus Ullgren.
Since we're almost into the soft-freeze I'll have to ask about the
best way to proceed; it may be that confirmation from those two
contributors are not needed; it may be that uploading a NEW
src:php-mode instead of src:php-elisp would be best; alternatively,
we're stuck with the old copyright format forever with undefined
licensing for debian/*
Well, could you contact hem again and explain that it is a matter of
licence? It would be silly to have a package ready since 6 months ago
and not to be added to debian because of a simple answer of GPL
licensing. If you wish, you can add me in CC of the e-mail, I will help
towards a fast solution.
Please do not, people who leave Debian often feel harassed by this.
I misinterpreted your previous e-mail, I thought you wait for debian
technical committee... (!)
No worries! I didn't think it was a severe enough issue to escalate
to the TC...maybe debian-legal will recommend this action though (see
#903092).
Anyway, perhaps I am wrong, but I do not see what debian/* file do you carry
from the current package when you upload the new version of php-mode. As
far as I see, you can use what you have written for yaml-mode :
https://sources.debian.org/src/yaml-mode/0.0.13-1/debian/. The debian
directory of this latter package has an almost empty rules file, and the
control file cannot surely be copy protected.
22 lines from d/changelog, plus at least 14L from various other
places. I'm believe he's still over the 25L limit (GNU standard) for
non-copyrightable contributions.
Otherwise said, you need relicensing from previous packagers if you still
use their contributions or files, but there will be none, since the new
debian/ directory will be almost empty, and without any contributions or
file from them! What is Thierry's contribution you will use in the new
package?
I might be missing something here, but I do not see what.
See above. I am not a lawyer and do not know whether these
contributions are sufficiently original to be considered
copyrightable.
Any news, Nicholas? If you do not do anything, nothing will happen...
I contacted the MIA team to find out if there was a reasonable
expectation of hearing back from Thierry before the mid-Feb freeze.
He's very much MIA, and it is probable we won't hear from him.
Because it is necessary to have all contributors consent, we cannot
move to machine-readable copyright at this time.
Knowing this, I am proceeding with some minor updates to the packaging
and plan to upload this week.
Ok, thank you!
You're welcome! By the way, unlike most people I appreciate the
follow-ups
Bug#919891: navit: Crash when starting for the first time due to XML
Package: navit Version: 0.5.3+dfsg.1-1 Severity: normal Tags: upstream Dear Maintainer, I try navit for the first time. I copied the XML file from http://wiki.navit-project.org/index.php/Configuration and put it in .navit/navit.xml: I start navit and have a crash: Reading symbols from navit...(no debugging symbols found)...done. Attaching to program: /usr/bin/navit, process 5561 Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...Reading symbols from /usr/lib/debug/.build-id/a7/0e1c821fa0b9649d341d929fe875c574a5324b.debug...done. done. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Reading symbols from /lib/x86_64-linux-gnu/libglib-2.0.so.0...(no debugging symbols found)...done. Reading symbols from /lib/x86_64-linux-gnu/libgmodule-2.0.so.0...(no debugging symbols found)...done. Reading symbols from /lib/x86_64-linux-gnu/libz.so.1...(no debugging symbols found)...done. Reading symbols from /lib/x86_64-linux-gnu/libpng16.so.16...(no debugging symbols found)...done. Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...Reading symbols from /usr/lib/debug/.build-id/5f/5bc3aba9c2600e38002c8471fb24e6005fd7c8.debug...done. done. Reading symbols from /lib/x86_64-linux-gnu/libm.so.6...Reading symbols from /usr/lib/debug/.build-id/84/aff20c33f05386e02c8a9d2629b9aa27fce0e8.debug...done. done. Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from /usr/lib/debug/.build-id/dd/2b8c469f69d0866039fcc75889451baca4e0f1.debug...done. done. Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/.build-id/f6/8476632fe338d209f9536ad0ebe7cfde5b5f28.debug...done. done. Reading symbols from /lib/x86_64-linux-gnu/libpcre.so.3...(no debugging symbols found)...done. 0x7f6609499757 in __GI___waitpid (pid=5562, stat_loc=stat_loc@entry=0x7ffeeaac04c8, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30 30 ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory. #0 0x7f6609499757 in __GI___waitpid (pid=5562, stat_loc=stat_loc@entry=0x7ffeeaac04c8, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30 #1 0x7f660941781f in do_system (line=) at ../sysdeps/posix/system.c:149 #2 0x55bcb6897ba0 in ?? () #3 #4 0x55bcb688b3d4 in ?? () #5 0x55bcb688b94f in ?? () #6 0x55bcb688c3ba in ?? () #7 0x7f66099cc5f2 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #8 0x7f66099cd716 in g_markup_parse_context_parse () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x55bcb688bd86 in ?? () #10 0x55bcb688df5f in config_load () #11 0x55bcb6886016 in main_real () #12 0x7f66093f709b in __libc_start_main (main=0x55bcb6885ca0 , argc=1, --Type for more, q to quit, c to continue without paging--argv=0x7ffeeaac21f8, Quit Detaching from program: /usr/bin/navit, process 5561 Cheers, Eugen Dedu -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages navit depends on: ii libc6 2.28-5 ii libdbus-1-3 1.12.12-1 ii libdbus-glib-1-20.110-3 ii libfontconfig1 2.13.1-2 ii libfreetype62.9.1-3 ii libfribidi0 1.0.5-3.1 ii libgarmin0 0~svn320-6 ii libglib2.0-02.58.2-4 ii libgps233.17-5+b1 ii libpng16-16 1.6.36-3 ii libspeechd2 0.8.8-9 ii navit-data 0.5.3+dfsg.1-1 ii navit-gui-internal 0.5.3+dfsg.1-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages navit recommends: ii gpsd 3.17-5+b1 Versions of packages navit suggests: pn maptool -- no debconf information
Bug#913045: Fixed?
Hi, I think this bug is fixed by the today's pulseaudio 12.2-3 update in Debian: * Ship link from /etc/alsa/conf.d/pulse.conf to /usr/share/alsa/alsa.conf.d/pulse.conf. Upstream alsa decided to stop supporting the /usr path (Closes: #915696) I cannot test right now, but only this week-end. Regards, -- Eugen
Bug#918045: emacs: Version 26.1 does not work with hunspell
Package: emacs Version: 1:26.1+1-3 Severity: normal Tags: upstream Dear Maintainer, Emacs 26.1 does not work with hunspell. The problem is known, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33493 and https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33606. It would be useful to include the patch in the next upload, I suppose many users use it. Cheers, Eugen http://eugen.dedu.free.fr -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages emacs depends on: ii emacs-gtk 1:26.1+1-3 emacs recommends no packages. emacs suggests no packages. -- no debconf information
Bug#552275: network-manager-gnome: Wifi icons not scalable for larger panel sizes
On Sat, 24 Oct 2009 17:09:07 -0700 Josh Triplett wrote: Package: network-manager-gnome Version: 0.7.1-1 Severity: normal I use a 48-pixel bottom panel and no top panel. Most tray icons scale to the appropriate size, but nm-applet's wifi icons remain small. (Some of nm-applet's other icons scale appropriately, making the icon change size depending on the networking state.) Hi, Is this bug still actual? I am not sure if this was the same bug like me, but I use awesome with a larger panel, and the wi-fi icon, but also Ethernet one, contained visual artifacts. Since a few days (I use Debian unstable), everything is normal, I have not found the reason (perhaps a recent update of libpng?) Regards, -- Eugen http://eugen.dedu.free.fr
Bug#916474: Font to install
Alan, could you install fonts-symbola and see if it solves your issue? See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914226 for a similar bug. Regards, -- Eugen Dedy
Bug#902633: Any progress?
On 27/12/2018 00:48, Nicholas D Steeves wrote: I wonder if it might be necessary to upload as src:php-mode. Bin:elpa-org-mode provides bin:php-elisp in any case. I do not understand. elpa-org-mode package does not exist in Debian. Anyway, I would put 'php-mode' in the name of the package, given that this is the name of the software. We can follow the same notation as yaml-mode you packaged. Please ping me in a week:-) Ok, I executed an 'at' command... :o) -- Eugen
Bug#902633: Any progress?
Hi everybody, Nicholas, is there any progress on updating this package? Also, any progress on "Clarify a point in README.md wrt PSR-5 status and PSR-7 status" https://github.com/ejmr/php-mode/issues/473 ? Is it so important to delay the packaging of the latest release? Ola, is there any svn of git repository for the Debian files of the package? I do not see it at https://packages.qa.debian.org/p/php-elisp.html. Or the latest version is in the package itself? Note that someone else took over the software, Kenta Usami, https://github.com/emacs-php/php-mode. I would like to work on this a few hours, hopefully today. I do not plan to take over this package, just package the latest release of the software. I am Debian maintainer, and maintained for a few years ekiga, ptlib, and opal. I could send to Ola a few patches to solve this. Regards, -- Eugen Dedu Associate Professor / Maître de conférences HDR OMNI team leader FEMTO-ST Institute, Univ. Bourgogne Franche-Comté, CNRS Montbéliard, France tel. +33 3 81 99 47 75 http://eugen.dedu.free.fr
Bug#895743: php-elisp package too old
Hi Ola, I use PHP within Emacs. As far as I know, php-mode (php-elisp) is the only Emacs package to provide a PHP mode. The current version of php-elisp in Debian does not even start in Emacs (I use 26.1). This means that currently Emacs in Debian does not support PHP language. Would it be possible to update the php-elisp package in Debian? Alternatively, package another recent package providing PHP mode? Finally, if you do not have time to maintain this Debian package, can you orphan it or fill an RFA, cf. https://wiki.debian.org/Orphaning? Best regards, -- Eugen Dedu Associate Professor / Maître de conférences HDR OMNI team leader FEMTO-ST Institute, Univ. Bourgogne Franche-Comté, CNRS Montbéliard, France tel. +33 3 81 99 47 75 http://eugen.dedu.free.fr
Bug#916804: libinput-bin: Provide a NEWS.gz file
Package: libinput-bin Version: 1.12.4-1 Severity: wishlist Dear Maintainer, It would be useful to have a NEWS.gz file to see the release notes. For 1.12.4 it could have the lines from https://lists.freedesktop.org/archives/wayland-devel/2018-December/039782.html. Generally, the information is at https://www.freedesktop.org/wiki/Software/libinput/ (not yet available for 1.12.4). Best regards, Eugen
Bug#907518: [RFC] Disable TLSv1.0 by default, but allow enabling it
On 05/12/2018 09:52, Andrej Shadura wrote: Hardcode a minimal version just for wpa-supplicant to TLSv1.0? What about ciphers? Anything else? Hi, In order to make it work with eduroam I have to change in ciphers too like this: MinProtocol = TLSv1.2 -> 1 CipherString = DEFAULT@SECLEVEL=2 -> 1 Best regards, -- Eugen
Bug#746415: Let's groups same bugs
forcemerge 868461 746415 forcemerge 819510 746415 forcemerge 851281 746415 tags 746415 d-i thanks I have recently installed a debian system: I choose C locale at the beginning of the installation, finish system installation, reboot and log in gnome: I cannot start any terminal, since gnome-terminal, the only terminal installed, refuses to start! (I had to enter a text console and install xterm to allow me to have a working terminal in gnome.) Starting gnome-terminal inside xterm shows the following error: Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached Note there is no error status (such as "exited with status 8"). By the way, uxterm too refuses to start when locale is C, and shows an error about locale. A workaround is dpkg-reconfigure locales and choose a UTF-8 locale, such as en_US.UTF-8 (I do not remember if it needs also to be made the default or not). This bug affects current debian installations, hence the d-i tag. -- Eugen
Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
On 23/11/2018 10:11, Elimar Riesebieter wrote: I have the same problem: sound has always worked, until installing 1.1.7 version. With 1.1.7 I have to write the .asoundrc file to make sound work. This happens on both my laptops. I might be wrong, but it seems to me that the problem has nothing to do with udev... Do all Debian users (at least those with Intel sound card) need to write the .asoundrc file to make sound work again? Reopening, since I use unstable and 1.1.7-3 does not work without .asoundrc file. Well, I don't know your environment. Please notice that the .asoundrc method is usual. What is wrong with configuring a asoundrc? And yes, I can't do more here. I'll leave the bug open and maybe tag it as wontfix in a few weeks On my machine, the following command fixes the issue: # mv /etc/alsa/conf.d/99-pulseaudio-default.conf.example /etc/alsa/conf.d/99-pulseaudio-default.conf Could that be the fix? -- Eugen
Bug#913045: [Pkg-alsa-devel] Bug#913045: Bug#913045: Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
reopen 913045
thanks
On Wed, 14 Nov 2018 06:10:35 +0100 Elimar Riesebieter
wrote:
* Pedro Silva [2018-11-13 23:48 +]:
> On Tue, 13 Nov 2018 23:44:35 +0100 Elimar Riesebieter
> wrote:
>
> > Heureka!
> >
> > Could you please test also libasound2-plugins 1.1.7-3 which arrived
>
> $ dpkg -l | grep libasound2 | awk {'print $2,$3'}
> libasound2:amd64 1.1.7-1
> libasound2:i386 1.1.7-1
> libasound2-data 1.1.7-1
> libasound2-dev:amd64 1.1.7-1
> libasound2-plugins:amd64 1.1.7-3
> libasound2-plugins:i386 1.1.7-3
>
> If ~/.asoundrc doesn't exist, same error:
>
> ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
>
> If previous ~/.asoundrc exists, everything works as expected.
Ok, so it seems to be udev's task to set the priority of soundcards.
I can't do more here so I am closing this bug hereby.
Hi Elimar,
I have the same problem: sound has always worked, until installing 1.1.7
version. With 1.1.7 I have to write the .asoundrc file to make sound
work. This happens on both my laptops.
I might be wrong, but it seems to me that the problem has nothing to do
with udev... Do all Debian users (at least those with Intel sound card)
need to write the .asoundrc file to make sound work again?
Reopening, since I use unstable and 1.1.7-3 does not work without
.asoundrc file.
Regards,
--
Eugen Dedu
http://eugen.dedu.free.fr
Bug#910807: webext-ublock-origin: Does not work with firefox
Package: webext-ublock-origin Version: 1.17.0+dfsg-1 Severity: grave Justification: renders package unusable Dear Maintainer, After upgrading to 1.17.0+dfsg-1 version, the package does not work with firefox anymore: it is not shown in Tools->Add-ons, and there is no icon at the right of the URL bar. Regards, Eugen Dedu -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages webext-ublock-origin depends on: ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-1 Versions of packages webext-ublock-origin recommends: ii firefox 62.0.3-1 Versions of packages webext-ublock-origin suggests: pn ublock-origin-doc -- no debconf information
Bug#899365: [Pkg-mozext-maintainers] Bug#899365: webext-ublock-origin: webext package does not work in Firefox
On 06/07/18 16:19, Sean Whitton wrote: Hello Daniel, On Fri, Jul 06 2018, Daniel Baumann wrote: I've looked at the git repository on salsa, and your last commit: https://salsa.debian.org/daniel-guest/ublock-origin/commit/0b9e4452552ce6243ae088a7880ef4d67c82d5f8 fixes this for sid (provided one has fonts-font-awesome 4.x which got recently re-uploaded; it works flawlessly but doesn't display icons in the popup when using fonts-font-awesome 5.x). would you mind the fix? That is a fix for a different bug. I didn't upload it because this bug is still present, making the package useless. Or is this bug no longer reproducible? I confirm that the commit on salsa above makes ublock origin working with my firefox. -- Eugen
Bug#899365: [Pkg-mozext-maintainers] Bug#899365: webext-ublock-origin: webext package does not work in Firefox
On 06/07/18 14:26, Daniel Baumann wrote: Hi Sean, I've looked at the git repository on salsa, and your last commit: https://salsa.debian.org/daniel-guest/ublock-origin/commit/0b9e4452552ce6243ae088a7880ef4d67c82d5f8 fixes this for sid (provided one has fonts-font-awesome 4.x which got recently re-uploaded; it works flawlessly but doesn't display icons in the popup when using fonts-font-awesome 5.x). would you mind the fix? What a beautiful day! Finally, an Internet without ads again! Thank you for the information! (It did not worked after restarting firefox, no icon in the firefox's toolbar, I had to disable and enable the plugin too.) -- Eugen
Bug#899365: Same thing
Hi, I have the same problem: the extension does not show up in the extension list in Firefox. Do you know how to debug? Cheers, -- Eugen
Bug#892721: cron: Warning during installation
Package: cron Version: 3.0pl1-129 Severity: normal Dear Maintainer, I have just upgraded cron from unstable, and, first of all, it gives a few warnings. Secondly, are this warnings benign or not? Setting up cron (3.0pl1-129) ... Installing new version of config file /etc/init.d/cron ... stat: cannot stat '*': No such file or directory stat: cannot stat '*': No such file or directory stat: cannot stat '*': No such file or directory Warning: * is not a regular file! I looked a bit in postinst file, and see that it executes three times stat. In my case, after installation, the directory /var/spool/cron/crontabs/ is empty. Cheers, Eugen -- Package-specific info: --- EDITOR: not set --- /usr/bin/editor: /usr/bin/vim.tiny --- /usr/bin/crontab: -rwxr-sr-x 1 root crontab 39352 Mar 11 22:38 /usr/bin/crontab --- /var/spool/cron: drwxr-xr-x 5 root root 4096 Feb 9 2015 /var/spool/cron --- /var/spool/cron/crontabs: drwx-wx--T 2 root crontab 4096 Oct 26 2014 /var/spool/cron/crontabs --- /etc/cron.d: drwxr-xr-x 2 root root 4096 Mar 12 10:00 /etc/cron.d --- /etc/cron.daily: drwxr-xr-x 2 root root 4096 Mar 12 10:00 /etc/cron.daily --- /etc/cron.hourly: drwxr-xr-x 2 root root 4096 Mar 12 10:00 /etc/cron.hourly --- /etc/cron.monthly: drwxr-xr-x 2 root root 4096 Mar 12 10:00 /etc/cron.monthly --- /etc/cron.weekly: drwxr-xr-x 2 root root 4096 Mar 12 10:00 /etc/cron.weekly -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cron depends on: ii adduser 3.117 ii debianutils 4.8.4 ii dpkg1.19.0.5 ii libc6 2.27-2 ii libpam-runtime 1.1.8-3.7 ii libpam0g1.1.8-3.7 ii libselinux1 2.7-2+b1 ii lsb-base9.20170808 Versions of packages cron recommends: ii exim4 4.90.1-2 ii exim4-daemon-light [mail-transport-agent] 4.90.1-2 Versions of packages cron suggests: ii anacron2.3-24 pn checksecurity ii logrotate 3.11.0-0.1 Versions of packages cron is related to: pn libnss-ldap pn libnss-ldapd pn libpam-ldap pn libpam-mount pn nis pn nscd -- Configuration Files: /etc/crontab changed [not included] -- no debconf information
Bug#892464: gcompris-qt: Need to install Recommends to have sound
Package: gcompris-qt Version: 0.81-1 Severity: important Dear Maintainer, I have just upgraded gcompris. I have no sound. However, in Tools sound and voices are activated. I noticed that gcompris Recommends libqt5multimedia5-plugins, which was not installed. I installed, just to try it, and now the sound works. I think that this package should not be in Recommends, but in Depends. Greetings, Eugen -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gcompris-qt depends on: ii gcompris-qt-data 0.81-1 ii libc6 2.27-1 ii libgcc11:8-20180308-1 ii libqt5core5a 5.9.2+dfsg-12 ii libqt5gui5 5.9.2+dfsg-12 ii libqt5network5 5.9.2+dfsg-12 ii libqt5qml5 5.9.2-3 ii libqt5quick5 5.9.2-3 ii libqt5sensors5 5.9.2-2 ii libqt5widgets5 5.9.2+dfsg-12 ii libstdc++6 8-20180308-1 ii qml-module-qtgraphicaleffects 5.9.2-2 ii qml-module-qtmultimedia5.9.2-1 ii qml-module-qtquick-controls5.9.2-2 ii qml-module-qtquick-particles2 5.9.2-3 Versions of packages gcompris-qt recommends: pn libqt5multimedia5-plugins gcompris-qt suggests no packages. -- no debconf information
Bug#891536: RFA: ekiga -- H.323 and SIP compatible VoIP client
Package: wnpp Severity: normal I request an adopter for the ekiga package. I have been interested in ekiga package because I have been an ekiga developer. Now, it has been 1-2 years since ekiga has not been updated, because of lack of developer time, so I do not have any incentive to maintain ptlib, opal and ekiga. My current job is more time hungry, and I do not have enough time to do all the things I would like to do. The package description is: H.323 and SIP compatible videoconferencing and VoIP/IP-Telephony application that allows you to make audio and video calls to remote users with H.323 hardware or software (such as Microsoft Netmeeting) as well as SIP endpoints. . It supports all modern videoconferencing features, such as contact roster, presence status, high-quality audio and video codecs, various video resolutions, registering to an LDAP directory, gatekeeper support, making multi-user conference calls using an external MCU, using modern Quicknet telephony cards, and making PC-To-Phone calls. . Evolution plugin is in ekiga-plugin-evolution package.
Bug#891535: RFA: opal -- Portable Tools Library
Package: wnpp Severity: normal I request an adopter for the opal package. I have been interested in opal package because ekiga depends on it, and I have been an ekiga developer. Now, it has been 1-2 years since ekiga has not been updated, because of lack of developer time, so I do not have any incentive to maintain ptlib, opal and ekiga. My current job is more time hungry, and I do not have enough time to do all the things I would like to do. The package description is: This package contains the shared version of the OPAL library. . The OPAL project aims to create a full featured, interoperable, Open Source implementation of the H.323 and SIP protocols that can be used freely by everybody. These protocols are most used for Voice over IP (VoIP) conferencing. . This package contains the shared version of the OPAL library, together with several audio and video codecs.
Bug#891534: RFA: ptlib -- Portable Tools Library
Package: wnpp Severity: normal I request an adopter for the ptlib package. I have been interested in ptlib package because ekiga depends on it, and I have been an ekiga developer. Now, it has been 1-2 years since ekiga has not been updated, because of lack of developer time, so I do not have any incentive to maintain ptlib, opal and ekiga. My current job is more time hungry, and I do not have enough time to do all the things I would like to do. The package description is: This package contains the shared version of the library PTLib, which is a moderately large class library that has its genesis many years ago as a method to produce applications to run on both Microsoft Windows and Unix X-Window systems. . This package also contains all the current PTLib plugins (alsa, oss, pulse, and v4l2).
Bug#867316: News?
So, no one interested in maintaining this package? -- Eugen
Bug#858170: I would like it too
I would like to have the new version in debian too. It fixes an annoying bug with un-maximization, which makes me not to use maximization anymore. Thank you, -- Eugen http://eugen.dedu.free.fr
Bug#852354: move ptlib.pc to a multiarch location
On 23/01/17 21:06, Helmut Grohne wrote: Source: ptlib Version: 2.10.11~dfsg-2.1 Tags: patch Control: affects -1 + src:opal User: helm...@debian.org Usertags: rebootstrap opal fails to cross build from source, because pkg-config cannot find ptlib.pc. During cross compilation /usr/lib/pkgconfig is not considered. Thus ptlib.pc should be moved to /usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig. The attached patch does just that. Please consider applying it. Hi Helmuth, Thank you for the patch. If you tested the patch and it works, do you mind to upload it too? Thank you, -- Eugen
Bug#401026: icedove-typeaheadfind: I do nt understand this extension
Good, thank you! Eugen On 27/12/16 14:08, Carsten Schoenert wrote: Hello Eugen, icedove-typeaheadfind isn't part of any Debian release anymore. So this report isn't solvable or useful. I will close this bug report now (after almost 1o years :/ ). Regrads Carsten On Thu, Nov 30, 2006 at 12:31:07PM +0100, Eugen Dedu wrote: Package: icedove-typeaheadfind Version: 1.5.0.8-3 Severity: normal I see that icedove suggests icedove-typeaheadfind. I execute "apt-cache show icedove-typeaheadfind", I read the Description but I do not understand what this extension is about. For example, in the description: "The Icedove/Thunderbird typeaheadfind is an accessibility extension adding enhanced search as you type capabilities to thunderbird". What is "capability"? Where is the enhanced search? I install it, I look at /usr/share/doc/icedove-typeaheadfind, nothing explains me what this extension is about. My question is: What is this extension about and how can I use it (for ex. is there a menu item added to icedove when I install icedove-typeaheadfind)? Regards, Eugen Dedu -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages icedove-typeaheadfind depends on: ii icedove 1.5.0.8-3free/unbranded thunderbird mail cl ii libc6 2.3.6.ds1-8 GNU C Library: Shared libraries ii libgcc1 1:4.2-20060923-1 GCC support library ii libstdc++6 4.1.1-19 The GNU Standard C++ Library v3 icedove-typeaheadfind recommends no packages. -- no debconf information
Bug#839783: marked as done (Please package Emacs 25.1)
On 24/12/16 13:48, Debian Bug Tracking System wrote: Your message dated Sat, 24 Dec 2016 13:44:44 +0100 with message-id <87r34xwl6r@gmail.com> and subject line Re: Bug#839783: Please package Emacs 25.1 has caused the Debian Bug report #839783, regarding Please package Emacs 25.1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. Would it be possible to make it the version by default? Currently, it is version 24. Thank you, -- Eugen
Bug#841297: I have this too
I have this too. The problem is that any user thinks there is a problem with his systme. I searched on Internet and I noticed that the problem is not with the system, but with grub... -- Eugen
Bug#846373: ptlib: diff for NMU version 2.10.11~dfsg-2.1
On 30/11/16 19:04, Andrey Rahmatullin wrote: Package: ptlib Version: 2.10.11~dfsg-2 Severity: normal Tags: patch pending Dear maintainer, I've prepared an NMU for ptlib (versioned as 2.10.11~dfsg-2.1) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. It is fine, thank you very much! The sooner, the better! -- Eugen
Bug#833508: Revert back the change
On 13/09/16 11:05, Eugen Dedu wrote: Hi, Would it be possible to revert back the change about using modesetting instead of intel (i.e. remove patches/06_use-intel-only-on-pre-gen4.diff), until the problem is fixed upstream? Moreover, at https://bugs.freedesktop.org/show_bug.cgi?id=96572, it seems they are still debating whether modesetting is better or not than intel driver. Hi, I ask again my question since at https://bugs.freedesktop.org/show_bug.cgi?id=96572#c11 they have just written that we should wait until linux 4.11, i.e. 6-9 months... Will xbacklight be unusable for so long time on our machines? Is there any problem to revert back the change about modesetting? -- Eugen
Bug#833508: Revert back the change
Hi, Would it be possible to revert back the change about using modesetting instead of intel (i.e. remove patches/06_use-intel-only-on-pre-gen4.diff), until the problem is fixed upstream? Moreover, at https://bugs.freedesktop.org/show_bug.cgi?id=96572, it seems they are still debating whether modesetting is better or not than intel driver. Kind regards, -- Eugen
Bug#833508: eDP1 changed to eDP-1
I have the same problem too. I noticed that the screen has always been called eDP1 (when it used to work), but now it is called eDP-1. Hope this helps, Eugen
Bug#817122: awesome: Package new 3.5.9 release
Package: awesome Version: 3.5.6-1 Severity: wishlist Dear Maintainer, Would it be possible to package the latest awesome release? It fixes an annoying bug for me. Thank you, Eugen
Bug#745405: [src:opal] Source package contains non-free IETF RFC/I-D
On 16/01/16 12:35, Francesco Poli wrote:
On Sat, 25 Oct 2014 19:53:57 +0200 Eugen Dedu wrote:
tags 745405 pending
Hello,
I see that this bug report has been pending for quite a long time.
I wondered what happened and saw that a changelog entry claims to fix
the issue, but seems to forget the Closes directive:
opal (3.10.10~dfsg2-1) unstable; urgency=low
* Remove one non free document (RFC) from source package.
[...]
-- Eugen Dedu <eugen.d...@pu-pm.univ-fcomte.fr> Mon, 27 Oct 2014 05:51:57
+0200
Maybe this bug report should be closed with a message to
<745405-cl...@bugs.debian.org> having the following pseudo-header:
Source: opal
Source-Version: 3.10.10~dfsg2-1
Do you agree?
Thank you very much for your e-mail. I have forgotten about this bug...
In that commit I removed
plugins/audio/iLBC/iLBC/draft-ietf-avt-ilbc-codec-05.txt file, but it
remains several rfc files. I have forgotten why I have not removed them
too, I think I wanted to investigate more what the problem is, and
afterwards I forgot about them.
I will take care of it soon (probably "find . -name rfc\*.txt -exec rm
{}" is the simplest solution), thank you again!
--
Eugen
Bug#803846: opal: FTBFS with FFmpeg 2.9
On 08/01/16 00:31, Andreas Cadhalpun wrote: Hi Eugen, On 09.11.2015 11:55, Eugen Dedu wrote: Thank you for the patch. We hope to upload a new release of opal in 2 months (very very approximately), which includes most if not all of your changes, so I prefer to wait a bit. The next version of FFmpeg is planned to be released this month (and it might be called 3.0 instead of 2.9). Two month have passed now, so I'm wondering what the status of this bug is: * Is the upstream release ready? * Do you plan an upload soon? If this bug isn't fixed soon, it will become release critical and thus the package will either get NMUed or removed from testing. Hi Andreas, The release have not happened and will not happen certainly this month. So I will very soon apply the path in debian. Happy new year! -- Eugen
Bug#808579: Not fixed?
On 26/12/15 15:14, Niels Thykier wrote: Eugen Dedu: Hi, I have had the same problem since apt 1.1 version. Now I have 1.1.6, but this bug is still not fixed: apt-get update takes much time during rred phase. Hi, For reference, the following commit was done today, which might be of interest: https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=0b29c72 """ Use a hardcoded buffer size of 4096 to fix performance The code uses memmove() to move parts of the buffer to the front when the buffer is only partially read. By simply reading one page at a time, the maximum size of bytes that must be moved has a hard limit, and performance improves: In one test case, consisting of a 430 MB Contents file, and a 75K PDiff, applying the PDiff previously took about 48 seconds and now completes in 2 seconds. Indeed, it is extremely fast now, thank you! Further speed up can be achieved by buffering writes, they account for about 60% of the run-time now. """ It will probably be a part of the next APT release. -- Eugen
Bug#808579: Not fixed?
Hi, I have had the same problem since apt 1.1 version. Now I have 1.1.6, but this bug is still not fixed: apt-get update takes much time during rred phase. -- Eugen
Bug#768581: opal: FTBFS in experimental: error: 'CodecID' has not been declared
On 30/10/15 09:49, Andreas Beckmann wrote: Control: reassign -1 ftp.debian.org Control: severity -1 normal Control: retitle -1 RM: opal/experimental -- ROM; obsolete release series On 2014-11-12 13:05, Eugen Dedu wrote: On 08/11/14 15:24, Andreas Beckmann wrote: Package: opal Version: 3.12.8~dfsg-1 opal/experimental fails to build in a current sid+experimental environment, see For me, the version in experimental should be simply removed. Honestly, I prefer spending the little time I have on testing version, and or on version 3.14 or master upstream, as a developer. OK, reassigning to request removal from experimental. Thank you. Could you please do the same for ptlib package? It is in the same situation as opal, and has the same author and the same repository. Thank you, -- Eugen
Bug#803846: opal: FTBFS with FFmpeg 2.9
On 09/11/15 20:36, Andreas Cadhalpun wrote: Hi Eugen, On 09.11.2015 11:55, Eugen Dedu wrote: Thank you for the patch. We hope to upload a new release of opal in 2 months (very very approximately), which includes most if not all of your changes, so I prefer to wait a bit. Hmm, this is vaguer than I prefer. And the Debian package is already several upstream version behind, so why wait another two months? This is because ekiga is not yet ready to use newer version of ptlib and opal. ptlib/opal often breaks API with each release, is not well tested on linux platforms, and ekiga has not kept up with the changes. Also, please make sure that all of this is actually fixed upstream, as that doesn't appear to be the case. I made a fast check, and I found one chunck of your patch not to be inside, and about 4 chuncks inside. So in short I wrote "most if not all your changes". I will do a full check upon uploading, anyway. Kind regards, -- Eugen
Bug#803846: opal: FTBFS with FFmpeg 2.9
On 02/11/15 22:07, Andreas Cadhalpun wrote: your package fails to build with the upcoming ffmpeg 2.9. This bug will become release-critical at some point when the ffmpeg2.9 transition gets closer. Attached is a patch replacing the deprecated functionality. It also works with ffmpeg 2.8. Please apply this patch and forward it upstream, if necessary. These changes have little regression potential. Hi Andreas, Thank you for the patch. We hope to upload a new release of opal in 2 months (very very approximately), which includes most if not all of your changes, so I prefer to wait a bit. If ffmpeg 2.9 appears in unstable (much) before that, I will test your patch and do an upload with only your patch. Feel free to answer me if that poses problems. Kind regards, -- Eugen
Bug#802886: I have the same problem
tags severity 802886 grave thanks Since 1-2 days, after upgrading vlc, qt etc., I have exactly the same problem as the reporter, except that in my case I see only about 20x200 pixels, i.e. almost not at all. It is an important bug, since when a user clicks in nautilus for example, he does not see a usable video. I played with output in video section without success. Kind regards, -- Eugen
Bug#797438: ekiga: FTBFS with g++-5: error: 'cout' is not a member of 'std'
On 30/08/15 20:11, Simon McVittie wrote: Source: ekiga Version: 4.0.1-5 Severity: serious Justification: fails to build from source (but built successfully in the past) I've just sponsored an upload of ptlib to do the libstdc++ transition, and test-built its reverse dependencies. opal and h323plus were successful, Good. but ekiga failed to build: ../../plugins/loudmouth/loudmouth-dialect.cpp: In member function 'void LM::Dialect::on_open_group_chat_submitted(bool, Ekiga::Form)': ../../plugins/loudmouth/loudmouth-dialect.cpp:153:3: error: 'cout' is not a member of 'std' std::cout Should enter the room ' name ' with pseudonym ' pseudo ' std::endl; ^ Makefile:641: recipe for target '../../plugins/loudmouth/loudmouth-dialect.lo' failed Full log attached. I think this is probably because it doesn't include all the headers it should, but in previous versions of libstdc++, the header that declares std::cout happened to be pulled in by a header that this file does include and so the build succeeded. I made a fix for a bug to this upstream, https://git.gnome.org/browse/ekiga/commit/?id=8561e159f2095651d8. I will do an upload as soon as ptlib enters unstable. The ptlib upload is in NEW but should hopefully be processed reasonably soon. I'm uploading source and an amd64 build to https://people.debian.org/~smcv/ if you need them before then. No, there is no need. Thanks, -- Eugen
Bug#791249: package needs a transition
On 30/08/15 15:14, Simon McVittie wrote: On Fri, 28 Aug 2015 at 15:45:58 +0200, Eugen Dedu wrote: I have also built the package, the generated files are at http://eugen.dedu.free.fr/ek-debian. Erreur 403 - Refus de traitement de la requête (Interdit - Forbidden). Oh, really sorry, this is because the server does not show directory contents... I fixed it with an .htaccess. Please upload the .dsc, .debian.tar.* and .orig.tar.* to somewhere public - if you have Alioth access, then you should be able to upload to ~/public_html/ there and make it a+rX; or you could use mentors.debian.net. I'm not going to try to review based on what's in svn, because I need an orig.tar.* to do the full debdiff. So everything should be ok, thanks. -- Eugen
Bug#791249: package needs a transition
On 27/08/15 00:46, Simon McVittie wrote: On Wed, 05 Aug 2015 at 17:53:15 +0200, Eugen Dedu wrote: The simplest solution is to simply upload ptlib version 2.10.11, instead of the current 2.10.10, knowing that ptlib changes soname with *each* release. As I am DM, not DD, I cannot upload such a package. So could someone from voip team (Mark?) simply upload the 2.10.11 version? Any update on this? Do you have a source package prepared for 2.10.11? If the DDs on the VoIP team are too busy, someone else could potentially sponsor it. It would be wonderful. Do the VoIP team consider the new upstream release to be low-risk? In particular, do all the reverse dependencies build successfully against it? 2.10.11 is very low risk. There are very few changes, here they are: 2013-08-14 23:20 rjongbloed * [r30295] revision.h.in, version.h: Update release version number to 2.10.11 2013-03-29 03:58 ededu * [r29384] src/ptlib/msos/directshow.cxx: Fix compile error after last commit 2013-03-26 23:23 rjongbloed * [r29328] ., include/ptlib/videoio.h, src/ptlib/common/videoio.cxx, src/ptlib/msos/directshow.cxx: Merged revision(s) 29327 from ptlib/branches/v2_12: Changed PVideoInputDevice_DirectShow::GetDeviceCapabilities() to use much simpler and cleaner STL method for getting an ordered unique list: std::set. 2013-03-07 18:22 ededu * [r29220] plugins/vidinput_v4l2/vidinput_v4l2.cxx: Do not crash when video driver/webcam is buggy 2013-03-06 13:32 ededu * [r29210] src/ptlib/msos/directshow.cxx: Increase timeout when waiting for images from camera device 2013-03-04 00:06 rjongbloed * [r29189] src/ptclib/httpsrvr.cxx: Fixed crash in PHTTPSpace::DelResource(), thanks Елена Валынец 2013-02-20 10:25 ededu * [r29154] samples/safetest/overview.cxx: Remove duplicate line 2013-02-17 22:19 rjongbloed * [r29134] src/ptclib/pxmlrpc.cxx: Fix GNU warning. 2013-02-16 02:57 rjongbloed * [r29122] version.h: Update version number for beta v2.10.11 The following reverse dependencies depend on libpt2.10.10 and need to be changed to depend on libpt2.10.11: Reverse Depends: t38modem,libpt2.10.10 libpt-dev,libpt2.10.10 2.10.10~dfsg-5 libpt-dbg,libpt2.10.10 2.10.10~dfsg-5 openam,libpt2.10.10 simpleopal,libpt2.10.10 libopal3.10.10,libpt2.10.10 libh323-1.24.0,libpt2.10.10 gnugk,libpt2.10.10 ekiga,libpt2.10.10 As the two versions 2.10.10 and .11 are API/ABI compatible, this is only a matter of changing .10 to .11 in debian/control for those packages. If 2.10.11 is considered risky, the alternative is to do the v5 rename, as Ubuntu have done: http://patches.ubuntu.com/p/ptlib/ptlib_2.10.10~dfsg-5ubuntu1.patch As with a new SONAME, a DD sponsor would be required; but if you attach a patch, someone could sponsor it. (I can't guarantee to do it myself, but I am not the only DD who has been sponsoring and NMUing for this transition.) I have just committed the changes in debian/ to allow building ptlib 2.10.11, they are at http://anonscm.debian.org/viewvc/pkg-voip/ptlib/branches/ptlib2.10-luyten. I have also built the package, the generated files are at http://eugen.dedu.free.fr/ek-debian. -- Eugen
Bug#791249: package needs a transition
On 28/08/15 18:00, Simon McVittie wrote: On 28/08/15 14:45, Eugen Dedu wrote: On 27/08/15 00:46, Simon McVittie wrote: On Wed, 05 Aug 2015 at 17:53:15 +0200, Eugen Dedu wrote: knowing that ptlib changes soname with *each* release ... As the two versions 2.10.10 and .11 are API/ABI compatible Please educate your upstream about what SONAMEs mean? You are right to follow upstream's SONAME scheme rather than inventing Debian-specific SONAMEs. However, the SONAME should normally only change if the new version's ABI is incompatible with the old; this is something that upstream developers of libraries are expected to get right. See: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html I know this is not classic. We have discussed this with upstream. Upstream changes often the API/ABI, and he has not the time to maintain older versions. ptlib/opal have 700 klines of code, and targets also windows, macos, various customers etc. Really, there is nothing we can do. this is only a matter of changing .10 to .11 in debian/control for those packages. I thought for a moment that you meant the reverse-dependencies hard-coded the ptlib version number, either directly or by build-depending on a -dev package with the version in. Thankfully, they do not: the -dev package is libptlib-dev, and simply rebuilding the reverse dependencies (which the release team will schedule to be done automatically) will result in picking up the new ptlib. You are right, sorry. I have just committed the changes in debian/ to allow building ptlib 2.10.11, they are at http://anonscm.debian.org/viewvc/pkg-voip/ptlib/branches/ptlib2.10-luyten. I have also built the package, the generated files are at http://eugen.dedu.free.fr/ek-debian. Thanks, I'll try to find time to check that. Ok. -- Eugen
Bug#791249: package needs a transition
On 10/07/15 17:25, Matthias Klose wrote: Control: tags -1 + confirmed needs a transition, or else at least h323plus fails to build. Thank you for the information about h323plus. The simplest solution is to simply upload ptlib version 2.10.11, instead of the current 2.10.10, knowing that ptlib changes soname with *each* release. As I am DM, not DD, I cannot upload such a package. So could someone from voip team (Mark?) simply upload the 2.10.11 version? Kind regards, -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778074: Patch for GCC 5 build issue
On 25/06/15 19:27, Martin Michlmayr wrote: tags 778074 + patch thanks Here's a patch for the GCC 5 build issue. Sorry, I'm not sure how best to send patches for packages using quilt. BTW, it seems this issue is no longer present upstream: svn ls svn://svn.code.sf.net/p/opalvoip/code/ptlib/trunk/include/ptlib/ | grep crit It seems this is properly handled in configure now. Thank you very much, I have uploaded it. I forgot to add your name in the changelog, sorry. Kind regards, -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789024: g++-mingw-w64: Cannot upgrade, wrong dependency
Package: g++-mingw-w64 Version: 4.9.2-10+15.1 Severity: grave Justification: renders package unusable Hi Stephen, With the recent upload in unstable, I cannot upgrade the package anymore: root@snoopy:/home/ededu# apt-get install g++-mingw-w64 ... The following packages have unmet dependencies: g++-mingw-w64 : Depends: gcc-mingw-w64-base (= 4.9.2-20+15.2) but 4.9.2-21+15.2 is to be installed snoopy:~$ apt-cache show gcc-mingw-w64-base Package: gcc-mingw-w64-base Source: gcc-mingw-w64 (15.2) Version: 4.9.2-21+15.2 ... Cheers, Eugen -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages g++-mingw-w64 depends on: ii g++-mingw-w64-i6864.9.2-21+15.2 ii g++-mingw-w64-x86-64 4.9.2-21+15.2 ii gcc-mingw-w64-base4.9.2-21+15.2 g++-mingw-w64 recommends no packages. g++-mingw-w64 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789024: g++-mingw-w64: Cannot upgrade, wrong dependency
On 17/06/15 10:59, Stephen Kitt wrote: In the meantime, I'd be very interested in your feedback on the version that's in experimental, and which is installable as is! It's built with gcc 5... Unfortunately, ekiga does not build currently for windows because I need a recent gtk and the last gtk provided is 3.6. I will do builds again when I have the time to tackle this issue, and let you informed. Thanks, -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781736: +1
Me too I would like to have it. It should fix two bugs on my machine. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781004: ekiga: randomly crash due to buffer overflow
Hi Alessandro, Is this crash reproducible 100%? If yes, could you please install ekiga-dbg and execute gdb ekiga and give us the output of thread apply all bt? See http://wiki.ekiga.org/index.php/Debugging_Ekiga#How_to_get_a_stack_backtrace_from_a_crash_or_freeze for more information. Thanks, -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781004: ekiga: randomly crash due to buffer overflow
On 25/03/15 01:33, Alessandro Barbieri wrote: Il 24/03/2015 22:37, Eugen Dedu ha scritto: Hi Alessandro, Is this crash reproducible 100%? If yes, could you please install ekiga-dbg and execute gdb ekiga and give us the output of thread apply all bt? See http://wiki.ekiga.org/index.php/Debugging_Ekiga#How_to_get_a_stack_backtrace_from_a_crash_or_freeze for more information. Thanks, I can reproduce it every day. I followed the guide. Backtrace attached. Thank you, I see where it crashes. It will be difficult for us to fix it on Ekiga version 4. However, we are working on the next release of Ekiga and it will surely fix this bug. The release is planned for the next few months. Thenk you for your patience. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778404: Henry Spencer regular expressions (regex) library contains a heap overflow vulnerability
tag 778404 fixed-upstream thanks On 16/02/15 17:33, Eugen Dedu wrote: On 16/02/15 17:19, Moritz Muehlenhoff wrote: severity 778404 minor thanks On Sat, Feb 14, 2015 at 03:39:19PM +0100, Luciano Bello wrote: Package: ptlib Severity: important Tags: security patch The security team received a report from the CERT Coordination Center that the Henry Spencer regular expressions (regex) library contains a heap overflow vulnerability. It looks like this package includes the affected code at that's the reason of this bug report. The configure script picks the glibc regex code, so this doesn't affect the Debian binary packages. Thank you for the analysis. It would still be useful to report this upstream, so that they update the local regex code (it could be that the local one is used when building with a libc other than glibc) I will do it, I have commit access. I have committed the patch upstream, thank you: https://sourceforge.net/p/opalvoip/code/33381/ and https://sourceforge.net/p/opalvoip/code/33382/ Shouldn't we close this bug in debian? -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778404: Henry Spencer regular expressions (regex) library contains a heap overflow vulnerability
On 16/02/15 17:19, Moritz Muehlenhoff wrote: severity 778404 minor thanks On Sat, Feb 14, 2015 at 03:39:19PM +0100, Luciano Bello wrote: Package: ptlib Severity: important Tags: security patch The security team received a report from the CERT Coordination Center that the Henry Spencer regular expressions (regex) library contains a heap overflow vulnerability. It looks like this package includes the affected code at that's the reason of this bug report. The configure script picks the glibc regex code, so this doesn't affect the Debian binary packages. Thank you for the analysis. It would still be useful to report this upstream, so that they update the local regex code (it could be that the local one is used when building with a libc other than glibc) I will do it, I have commit access. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769941: Not because of gstreamer
I often start iceweasel as another user (with sux) and when I load gmail I have this error too: ** (iceweasel:17775): CRITICAL **: gst_app_src_set_size: assertion 'GST_IS_APP_SRC (appsrc)' failed However, iceweasel does not crash. So I think the crash has nothing to do with the assertion failed. I use libgstreamer-plugins-base1.0-0 1.4.4-2 (current unstable). -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741615: I have it too
On 08/12/14 23:47, Eugen Dedu wrote: On 02/12/14 14:11, Erwann Thoraval wrote: Hi Eugen, On 01/12/2014 18:26, Eugen Dedu wrote: I was trying to use a camera to forward my thesis defense for the day after tomorrow. I am hit by this bug. I looked also at https://bugs.launchpad.net/ffmpeg2theora, nothing about it... Believe me or not, but it works on my machine, contrarily to what I said. I have just tested it. The only explanation I have is that during my previous tests I was not putting the - at the end of the command (which means reading from standard input). What an error I made, it is a shame!! And I spent 3-4 hours with this bug. Now, it seems that it is not your case. I think the only thing you can do is to look yourself at the code and see what is the problem. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741615: I have it too
On 02/12/14 14:11, Erwann Thoraval wrote: Hi Eugen, On 01/12/2014 18:26, Eugen Dedu wrote: I was trying to use a camera to forward my thesis defense for the day after tomorrow. I am hit by this bug. I looked also at https://bugs.launchpad.net/ffmpeg2theora, nothing about it... If you switch back to ffmpeg2theora version 0.27-2 (in debian stable) it works. I have taken a glance over differences between 0.27 and current 0.29 in unstable, and seen nothing related to DV. It seems to me that this issue is related to libav. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741615: I have it too
Hi, I was trying to use a camera to forward my thesis defense for the day after tomorrow. I am hit by this bug. I looked also at https://bugs.launchpad.net/ffmpeg2theora, nothing about it... -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770829: installation-report: Font too small on UltraHD screen
Package: installation-reports Version: 2.57 Severity: normal Dear Maintainer, I am installing debian on a laptop with 3840x2160 resolution. The first screen, allowing to choose Install, Graphical install etc. is fine. Afterwards, the following screens, in both text (newt) and graphical install, font is too small, almost unreadable on the screen. I put a video at http://eugen.dedu.free.fr/2014-11-24-130034.webm. It is not of so good quality, since I have not had a camera with me, and used the webcam, but allows to see the problem. I attach three files about the system. This is a somehow important problem, since nothing can be done to workaround it. The installer is also the first program a new user sees when installing linux. -- Package-specific info: Boot method: USB Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd, 21/11/2014 Date: Date and time of the install Machine: Lenovo Y50 Xorg.0.log.gz Description: GNU Zip compressed data hardware-summary.gz Description: GNU Zip compressed data syslog.gz Description: GNU Zip compressed data
Bug#770546: installation-report: Mouse not working in graphical install
Package: installation-reports Version: 2.57 Severity: normal Dear Maintainer, I choose graphical install. On subsequent screens mouse is not working: it is just shown in the middle of the screen, but cannot be moved. I attach Xorg.0.log, hardware-summary and syslog files. (Also, be aware that the first line Package: as completed by reportbug contains reports with s, whereas the package name is without s.) Cheers, Eugen -- Package-specific info: Boot method: USB Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd, 21/11/2014 Date: Date and time of the install Machine: Lenovo Y50 Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Xorg.0.log.gz Description: GNU Zip compressed data hardware-summary.gz Description: GNU Zip compressed data syslog.gz Description: GNU Zip compressed data
Bug#769751: ekiga: Ekiga segfaults as soon as SIP call connects
On 16/11/14 05:50, John Sullivan wrote: Whether I'm placing or receiving the call, Ekiga segfaults as soon as a SIP connection starts. It's been doing this for some months for me, but prior to that it was working on this system (which has been through many changes, being unstable). I've tested with video on and off, and with two different SIP servers. When I place the call, as soon as the other person answers, it crashes. Sometimes I can see the video for a moment first. When I receive the call, as soon as I click answer, it crashes. Hi Sullivan, and thank you for the bug report! I need a gdb stack, cf. http://wiki.ekiga.org/index.php/Debugging_Ekiga#How_to_get_a_stack_backtrace_from_a_crash_or_freeze, and better with -d 4 included. If you have confidentiality concerns, you can send them to me privately. Kind regards, -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768581: opal: FTBFS in experimental: error: 'CodecID' has not been declared
On 08/11/14 15:24, Andreas Beckmann wrote: Package: opal Version: 3.12.8~dfsg-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Hi, opal/experimental fails to build in a current sid+experimental environment, see https://buildd.debian.org/status/fetch.php?pkg=opalarch=arm64ver=3.12.8~dfsg-1stamp=1414123156 [CC] .common/dyna.cxx In file included from ../common/ffmpeg.cxx:41:0: .../common/ffmpeg.h:123:30: error: 'CodecID' has not been declared virtual bool InitEncoder(CodecID codecId); ^ .../common/ffmpeg.h:124:30: error: 'CodecID' has not been declared virtual bool InitDecoder(CodecID codecId); ^ I could reproduce this rebuilding it for amd64 locally. For me, the version in experimental should be simply removed. Honestly, I prefer spending the little time I have on testing version, and or on version 3.14 or master upstream, as a developer. Kind regards, -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728452: opal: FTBFS if $HOME does not exist
tags 728452 experimental thanks On 21/10/14 17:49, Mark Purcell wrote: I am trying to fix this bug. Where is the debian repository corresponding to opal v10, used to package opal 3.10.10? As far as I see, http://anonscm.debian.org/viewvc/pkg-voip/opal/ contains only trunk (opal v12 in experimental), not the stable opal (v10). Eugen, It should be under branches, but it looks like it hasn't been created yet. Ok, I made that. Now, about this bug: it appears only in experimental (v3.12). It has nothing to do with unstable version (v3.10). Upstream, this exists only in v3.12, it does not appear in v3.10 and v3.14. So putting low priority, I am fixing opal unstable bugs now... -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752246: OPAL is compiled without any optimization
On 21/06/14 17:02, Adrian Bunk wrote: Package: src:opal Version: 3.10.10~dfsg-2.2 Severity: important OPAL is currently compiled without any optimization due to a combination of 2 bugs: 1. configure.ac overwrites the default CFLAGS/CXXFLAGS that are set to -g -O2 by autoconf when these variables aren't set in the environment and 2. the Debian build does not seem to pass CFLAGS/CXXFLAGS to configure The result is that OPAL is: - bigger than it should be, - the code is much slower than it should be and - the debug information in libopal-dbg is incomplete (no -g in the build) Attached patch fixes 1., I haven't looked into how 2. could/should be fixed. I spent a bit of time trying to fix 2., without success. I will make an upload without this fix, sorry. It is very likely fixed in the new version of opal (v3.14), there were one or several commits about that. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728452: opal: FTBFS if $HOME does not exist
On 19/10/14 16:37, Balint Reczey wrote: Hi Eugen, Hi Mark, I am trying to fix this bug. Where is the debian repository corresponding to opal v10, used to package opal 3.10.10? As far as I see, http://anonscm.debian.org/viewvc/pkg-voip/opal/ contains only trunk (opal v12 in experimental), not the stable opal (v10). Cheers, -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728452: opal: FTBFS if $HOME does not exist
On 19/10/14 16:37, Balint Reczey wrote: Hi Eugen, Hi everybody, According to https://qa.debian.org/popcon.php?package=opal, libopal-doc has value 0 at Vote column. I think the best is to simply remove the libopal-doc package. The API is available at http://files.opalvoip.org/docs/opal-v3_10 anyway. Do you disagree with this? Cheers, -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766222: apt-get update shows each pdiff file twice
Package: apt Version: 1.0.9.3 Severity: normal Dear Maintainer, apt-get update shows twice each pdiff file, for ex.: Get:1 http://ftp.fr.debian.org unstable InRelease [242 kB] Get:2 http://ftp.fr.debian.org unstable/main amd64 Packages/DiffIndex [7,876 B] Get:3 http://ftp.fr.debian.org unstable/main Translation-en/DiffIndex [7,876 B] Get:4 http://ftp.fr.debian.org unstable/main amd64 2014-10-21-0842.51.pdiff [11.6 kB] Get:5 http://ftp.fr.debian.org unstable/main amd64 2014-10-21-0842.51.pdiff [11.6 kB] Get:6 http://ftp.fr.debian.org unstable/main 2014-10-21-0842.51.pdiff [765 B] Get:7 http://ftp.fr.debian.org unstable/main 2014-10-21-0842.51.pdiff [765 B] Fetched 270 kB in 5s (45.2 kB/s) As you see lines 4 and 5 are identical, the same for 6 and 7. I do not know if those files are also downloaded twice, I can check it if you need. Cheers, Eugen -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 0; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image-3\.16-2-amd64$; APT::NeverAutoRemove:: ^linux-image-3\.16-3-amd64$; APT::NeverAutoRemove:: ^linux-headers-3\.16-2-amd64$; APT::NeverAutoRemove:: ^linux-headers-3\.16-3-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-3\.16-2-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-3\.16-3-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-3\.16-2-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-3\.16-3-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.16-2-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.16-3-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.16-2-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.16-3-amd64$; APT::NeverAutoRemove:: ^gnumach-image-3\.16-2-amd64$; APT::NeverAutoRemove:: ^gnumach-image-3\.16-3-amd64$; APT::NeverAutoRemove:: ^.*-modules-3\.16-2-amd64$; APT::NeverAutoRemove:: ^.*-modules-3\.16-3-amd64$; APT::NeverAutoRemove:: ^.*-kernel-3\.16-2-amd64$; APT::NeverAutoRemove:: ^.*-kernel-3\.16-3-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.16-2-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.16-3-amd64$; APT::NeverAutoRemove:: ^linux-tools-3\.16-2-amd64$; APT::NeverAutoRemove:: ^linux-tools-3\.16-3-amd64$; APT::VersionedKernelPackages ; APT::VersionedKernelPackages:: linux-image; APT::VersionedKernelPackages:: linux-headers; APT::VersionedKernelPackages:: linux-image-extra; APT::VersionedKernelPackages:: linux-signed-image; APT::VersionedKernelPackages:: kfreebsd-image; APT::VersionedKernelPackages:: kfreebsd-headers; APT::VersionedKernelPackages:: gnumach-image; APT::VersionedKernelPackages:: .*-modules; APT::VersionedKernelPackages:: .*-kernel; APT::VersionedKernelPackages:: linux-backports-modules-.*; APT::VersionedKernelPackages:: linux-tools; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Update ; APT::Update::Post-Invoke-Success ; APT::Update::Post-Invoke-Success:: test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i; APT::Update::Post-Invoke-Success:: /usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service /usr/bin/test -S /var/run/dbus/system_bus_socket /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update /dev/null; /bin/echo /dev/null; APT::Architectures ; APT::Architectures:: amd64; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ; APT::Compressor::gzip::Name gzip; APT::Compressor::gzip::Extension .gz; APT::Compressor::gzip::Binary gzip; APT::Compressor::gzip::Cost 2; APT::Compressor::gzip::CompressArg ; APT::Compressor::gzip::CompressArg:: -9n; APT::Compressor::gzip::UncompressArg ; APT::Compressor::gzip::UncompressArg:: -d; APT::Compressor::bzip2 ; APT::Compressor::bzip2::Name bzip2; APT::Compressor::bzip2::Extension .bz2; APT::Compressor::bzip2::Binary bzip2; APT::Compressor::bzip2::Cost 3; APT::Compressor::bzip2::CompressArg ; APT::Compressor::bzip2::CompressArg:: -9; APT::Compressor::bzip2::UncompressArg ; APT::Compressor::bzip2::UncompressArg:: -d; APT::Compressor::xz ; APT::Compressor::xz::Name xz; APT::Compressor::xz::Extension .xz; APT::Compressor::xz::Binary xz; APT::Compressor::xz::Cost 4;
Bug#731541: ekiga: crashes on incoming call
On 06/12/13 13:57, Micha Lenk wrote: Package: ekiga Version: 3.2.7-6 Severity: important Dear Maintainer, * What led up to the situation? I configured ekiga as SIP client registering at a Swyx server. As soon as an incoming call is signaled ekiga crashes with a coredump. Dear Micha, Sorry to answer so late. 3.2.7 is too old, and unfortunately we do not have enough time to fix its bugs too. Please use version 4 if you can, it is better, especially for crashes. Cheers, -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748911: src:opal: FTBFS on 64 bits arch
On 10/10/14 06:43, YunQiang Su wrote: NUMed with this patch. On Thu, Oct 9, 2014 at 8:31 PM, Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com wrote: Hi YunQiang, On 09/27/2014 01:12 AM, YunQiang Su wrote: Can any ppc64el and arm64 guys help to test this patch? On 10/07/2014 11:58 PM, YunQiang Su wrote: I will NMU ptlib with the attached debdiff. If you don't agree with it, please cancel it or ask me to do it. Sorry for missing this one for a few days. For ppc64el, there's a small change required, because the machine name is powerpc64le (suffix 'le' vs. 'el'): Thank you for the patch/NMU and sorry for being in late. I have committed these patches upstream, http://sourceforge.net/p/opalvoip/code/33011/ (current stable branch) and http://sourceforge.net/p/opalvoip/code/33012/ (trunk). -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728452: opal: FTBFS if $HOME does not exist
On 19/10/14 16:37, Balint Reczey wrote: Since May there have ben several stable releases starting with 3.14.0. It would be nice if the package could be updated before the freeze. The package cannot be updated, because it breaks API in major ways with each version (even minor one!), and most importantly it breaks ekiga. Ekiga has almost finished the transition, but it is not in releasable state. So I will just fix this bug (FTFBS if HOME inexistent). Note that docs target was removed in v14 and trunk (I suppose it should be replaced with a simple call to doxygen), hence opal-docs package needs to be revisited in the future. Anyway, I will do a debian-only fix. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728452: opal: FTBFS if $HOME does not exist
On 19/10/14 16:37, Balint Reczey wrote: Since May there have ben several stable releases starting with 3.14.0. It would be nice if the package could be updated before the freeze. You are right. I am spending a very busy period, I am sorry. I will do it tomorrow. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541388: Xmodmap loss
Just to say that since a few days (I track unstable) this bug appears very rarely (once in say 6 resumes). -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633849: Me too
On 28/07/14 13:21, Vincent Lefevre wrote: On 2013-10-30 22:44:45 +0100, Eugen Dedu wrote: I have the same bug and I would really love to have it fixed. Since about 2 years (before, it worked) I have been forced to execute xmodmap ~/.xmodmap after each resume, since the key bindings I use in that file are lost at suspend. There's a workaround: save and restore the settings automatically via pm-utils. I wrote the attached /etc/pm/sleep.d/40xkb-save-restore script Thank you for the help. Just to say that since a few days (I track unstable) this bug appears very rarely (once in say 6 resumes). -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748690: mingw-w64: Some libraries are archive static instead of archive import
On 08/08/14 08:06, Stephen Kitt wrote: Hi Eugen, On Wed, 06 Aug 2014 13:12:18 +0200, Eugen Dedu eugen.d...@univ-fcomte.fr wrote: I made some insight in this issue. I can reproduce on a simple example. Excellent, thanks for taking the time to figure this out. Take a libtool file you created from a mingw build. I tested with one generated this month, and another one generated one year ago, where the build worked. Both exhibit the bug, so libtool does not have any problem, it seems. I attach a libtool in case you need one. Do you know what version of mingw-w64 you were using when the build worked? I've tried with various versions going back to 2.0.8-1 (from May 2013) and the error message always appears. I do not know what to say, since I am confused about all this. Those flags (-dxerr9 and all the libraries which pose problems) are found in ptlib.pc, Libs: line, so they get used by ekiga. I think this is an error, which triggers also the bug. If I remove those flags during ekiga linking, there is no warning and libekiga.dll is generated. In previous versions of ptlib, those flags were put in Libs.private: line, hence they were not used during linking of *ekiga*, that's why it worked. An alternative solution for me is to move those flags from Libs: back to Libs.private, but I fear it gives errors in other places/programs. Note that using -Wl,-ldxerr9 makes the warning away, but I met another error later. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748690: mingw-w64: Some libraries are archive static instead of archive import
On 08/08/14 12:29, Eugen Dedu wrote: On 08/08/14 08:06, Stephen Kitt wrote: Hi Eugen, On Wed, 06 Aug 2014 13:12:18 +0200, Eugen Dedu eugen.d...@univ-fcomte.fr wrote: I made some insight in this issue. I can reproduce on a simple example. Excellent, thanks for taking the time to figure this out. Take a libtool file you created from a mingw build. I tested with one generated this month, and another one generated one year ago, where the build worked. Both exhibit the bug, so libtool does not have any problem, it seems. I attach a libtool in case you need one. Do you know what version of mingw-w64 you were using when the build worked? I've tried with various versions going back to 2.0.8-1 (from May 2013) and the error message always appears. I do not know what to say, since I am confused about all this. Those flags (-dxerr9 and all the libraries which pose problems) are found in ptlib.pc, Libs: line, so they get used by ekiga. I think this is an error, which triggers also the bug. If I remove those flags during ekiga linking, there is no warning and libekiga.dll is generated. In previous versions of ptlib, those flags were put in Libs.private: line, hence they were not used during linking of *ekiga*, that's why it worked. An alternative solution for me is to move those flags from Libs: back to Libs.private, but I fear it gives errors in other places/programs. I did this and it compiled well! Hope it does not break elsewhere. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748690: mingw-w64: Some libraries are archive static instead of archive import
On 19/05/14 23:36, Stephen Kitt wrote:
Hi Eugen,
On Mon, 19 May 2014 19:28:53 +0200, Eugen Dedu
eugen.d...@pu-pm.univ-fcomte.fr wrote:
Thank you for maintaining mingw-w64 for debian!
It's always a pleasure!
I try to compile ekiga using mingw-w64 and the problem is that it
generates only a .a, not a .dll. The reason is that libtool gives
errors like this:
[...]
The problem is with the ones recognised as archive static. The
following files have this problem in my case:
libdxerr9.a, libdxguid.a, libstrmiids.a, libuuid.a.
Do you know why the above files have this problem? Feel free to ask me
more information if needed.
The archive static files are object archives, built from C files compiled
to object files and archived. The archive import files are stubs for DLLs,
build from definition files. For example, dsound which you mention is built
from mingw-w64-crt/lib32/dsound.def in the mingw-w64 source; whereas uuid is
built from a bunch of C source files (see mingw-w64-crt/Makefile.am for
details; look for src_libuuid).
What exactly are you trying to do? I know that it is possible to link both
static and import archives into a DLL, wine-gecko does that with libuuid
amongst others; looking through my build logs I see
i686-w64-mingw32-g++ -mwindows -shared -Wl,--out-implib -Wl,libmozglue.dll.a -o
mozglue.dll dummy.o ./module.res -lpthread -static-libgcc -static-libstdc++
-Wl,--enable-stdcall-fixup -Wl,--large-address-aware mozglue.def
../../mfbt/libmfbt.a
/tmp/buildd/wine-gecko-2.21-2.21+dfsg1/wine_gecko-2.21-x86/modules/zlib/src/libmozz.a
-luuid -lgdi32 -lwinmm -lwsock32 -luserenv -lsecur32 -lnetapi32
(and the resulting mozglue.dll is used later on in the build for other DLLs
and so forth).
I made some insight in this issue. I can reproduce on a simple example.
Take a simple main.cpp:
int main (){
return 0;
}
Take a libtool file you created from a mingw build. I tested with one
generated this month, and another one generated one year ago, where the
build worked. Both exhibit the bug, so libtool does not have any
problem, it seems. I attach a libtool in case you need one.
There is no problem when executing:
/bin/bash ../libtool --tag=CXX --mode=link i686-w64-mingw32-g++
-shared -module -no-undefined -avoid-version -ldxerr9 -o libekiga.la
main.cpp
The bug appears when adding -rpath / (or another directory):
/bin/bash ../libtool --tag=CXX --mode=link i686-w64-mingw32-g++
-shared -module -no-undefined -avoid-version -ldxerr9 -o libekiga.la
-rpath / main.cpp
This command yields:
*** Warning: linker path does not have real file for library -ldxerr9.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libdxerr9 and none of the candidates passed a file format test
*** using a file magic. Last file checked:
/usr/i686-w64-mingw32/lib/libdxerr9.a
*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module libekiga. Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.
If you add -lwinmm for ex., it does not generate the warning. It
appears only with some libraries, as described in the initial report of
this bug.
--
Eugen
libtool.gz
Description: application/gzip
Bug#751019: ekiga: Call reject timeout is limited to 60 seconds, while interface allows 300s
On 09/06/14 16:42, Tim Marston wrote: Package: ekiga Version: 4.0.1-4+b2 Severity: normal Dear Maintainer, In the UI, it is possible to configure the amount of time Ekiga will wait until it rejects an inbound call that has not been answered. The UI allows a settings in the range 10 to 299 seconds. Separately to this, where the value is used, itis limited to the range 5 to 60 seconds. This means that settings above 60 seconds have no effect (or the timeout is limited to 60 seconds, at any rate). This bug is trivial to fix. (There should be a bug tag for this!) In lib/engine/components/opal/opal-call.cpp, see set_reject_delay() and set_no_answer_forward(), both of which are = 2-line functions. In both of them: NoAnswerTimer.SetInterval (0, PMIN (delay, 60)); can be changed to: NoAnswerTimer.SetInterval (0, PMIN (delay, 299)); to honour the setting that the UI allows the user to make. Fixed upstream, sorry for having taken so long: https://git.gnome.org/browse/ekiga/commit/?id=c198acee52. Please tell if you need this in debian too, before the new release of ekiga. -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754862: closed by Julien Cristau jcris...@debian.org (Bug#754822: fixed in xorg-server 2:1.16.0-1)
On 18/07/14 00:51, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the xserver-xorg-core package: #754862: xserver-xorg-input-evdev: Mouse movement very slow wince last upgrade It has been closed by Julien Cristau jcris...@debian.org. It is fixed for me too, thank you! -- Eugen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
