Bug#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory
On Wed, Nov 22, 2023 at 09:47:37AM +0100, Preuße, Hilmar wrote: > >This patch passed all my testing. Pavel > > > Great! Patch is in repo and will be in next upload. For the record: people who are suffering from this bug on unpatched systems can workaround it by simply adding path to filename when calling a5toa4... Pavel
Bug#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory
On Tue, Nov 21, 2023 at 01:55:57PM +0100, Preuße, Hilmar wrote:
> > Hilmar, please hold on with upload. I need to improve the patch as it breaks
> > with absolute paths. Don't know where I made the mistake because I was
> > testing
> > for it before going public. Anyway I need to come with a better fix.
> > Will keep you posted...
> >
>
> Thanks for information. I'll comment the patch for now.
This patch passed all my testing. Pavel
--- pfarrei.tlu 2023-11-21 11:43:19.611137725 +0100
+++ pfarrei.tlu 2023-11-21 11:46:53.993277671 +0100
@@ -100,11 +100,15 @@
-- build the temporary tex file
local tmpdir = os.tmpdir("pfarrei.XX" )
local tmpfile = string.match( arg[i], '.*/(.*)$') or arg[i]
+ -- pdflatex's -output-directory search for source pdf works with path specification but fails
+ -- when simple file name in the current working directory is provided, we need to provide '../' then
+ local local_source=''
+ if tmpfile == arg[i] then local_source = '../' end
local basename = string.match( tmpfile,'(.*)%.[^.]*$') or tmpfile
tmpfile = tmpdir..'/'..basename..'.tex'
local file = assert( io.open( tmpfile, 'w' ) )
if booklet then assert( file:write("\\PassOptionsToPackage{booklet}{pfarrei}\n") ) end
- assert( file:write("\\def\\OriginalFile{",arg[i],"}\n") )
+ assert( file:write("\\def\\OriginalFile{"..local_source,arg[i],"}\n") )
assert( file:write("\\input{a5toa4.tex}\n") )
assert( file:flush() )
file:close()
Bug#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory
On Sun, 10 Sep 2023 23:26:05 +0200 =?UTF-8?B?UHJldcOfZSwgSGlsbWFy?= wrote: > > I got a response from Markus Kohm: > > The problem is known, but he does not intent to fix it because he does > > not have enough time. > > He recommends pdfjam which can do the same task. > > > > So I think a5toa4 should be removed. > > > > Thanks for the effort! > > I tag the bug wontfix, but I don't remove the package. You can try proposed fix on your current setup. https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg220760.html I plan to push it into CTAN, so it will hopefully get fixed in trixie (or bookworm if some cares to backport the fix). Pavel
Bug#1054112: mariadb-server-10.5: extreme query slowdown since upgrade from 10.5.19 to 10.5.21
Package: mariadb-server-10.5 Version: 1:10.5.21-0+deb11u1 Severity: normal Dear Maintainer, after upgrading from 10.5.19-0+deb11u2 to 10.5.21-0+deb11u1, execution of one particular SELECT query became extremely slow (approx 1000 to 1 times). The configuration (server, client) remained the same. Before upgrade (expected): MariaDB [test]> SELECT ... ... 4 rows in set (1.014 sec) After upgrade (actual): MariaDB [test]> SELECT ... ... 4 rows in set (25 min 54.964 sec) SHOW CREATE statements of tables included in query (these are standard WordPress tables), ANALYZE SELECT for both versions and full server config are attached. All tables have ~50k to 400k rows. FYI, the same problem appears in latest version of MariaDB 10.11 (probably). Best regards, Pavel -- System Information: Debian Release: 11.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-25-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages mariadb-server-10.5 depends on: ii adduser 3.118+deb11u1 ii debconf [debconf-2.0] 1.5.77 ii galera-4 26.4.11-0+deb11u1 ii gawk 1:5.1.0-1 ii iproute2 5.10.0-4 ii libc6 2.31-13+deb11u7 ii libdbi-perl 1.643-3+b1 ii libpam0g 1.4.0-9+deb11u1 ii libssl1.1 1.1.1w-0+deb11u1 ii libstdc++6 10.2.1-6 ii lsb-base 11.1.0 ii lsof 4.93.2+dfsg-1.1 ii mariadb-client-10.5 1:10.5.21-0+deb11u1 ii mariadb-common 1:10.5.21-0+deb11u1 ii mariadb-server-core-10.5 1:10.5.21-0+deb11u1 ii passwd 1:4.8.1-1 ii perl 5.32.1-4+deb11u2 ii procps 2:3.3.17-5 ii psmisc 23.4-2 ii rsync 3.2.3-4+deb11u1 ii socat 1.7.4.1-3 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 Versions of packages mariadb-server-10.5 recommends: ii libhtml-template-perl 2.97-1.1 Versions of packages mariadb-server-10.5 suggests: pn mailx pn mariadb-test pn netcat-openbsd -- debconf information: mariadb-server-10.5/old_data_directory_saved: mariadb-server-10.5/nis_warning: mariadb-server-10.5/postrm_remove_databases: false alter_algorithm = DEFAULT analyze_sample_percentage = 100.00 aria_block_size = 8192 aria_checkpoint_interval = 30 aria_checkpoint_log_activity = 1048576 aria_encrypt_tables = OFF aria_force_start_after_recovery_failures = 0 aria_group_commit = none aria_group_commit_interval = 0 aria_log_dir_path = /var/lib/mysql/ aria_log_file_size = 1073741824 aria_log_purge_type = immediate aria_max_sort_file_size = 9223372036853727232 aria_page_checksum = ON aria_pagecache_age_threshold = 300 aria_pagecache_buffer_size = 134217728 aria_pagecache_division_limit = 100 aria_pagecache_file_hash_size = 512 aria_recover_options = BACKUP,QUICK aria_repair_threads = 1 aria_sort_buffer_size = 268434432 aria_stats_method = nulls_unequal aria_sync_log_dir = NEWFILE aria_used_for_temp_tables = ON auto_increment_increment = 1 auto_increment_offset = 1 autocommit = ON automatic_sp_privileges = ON back_log = 150 basedir = /usr big_tables = OFF bind_address = :: binlog_annotate_row_events = ON binlog_cache_size = 32768 binlog_checksum = CRC32 binlog_commit_wait_count = 0 binlog_commit_wait_usec = 10 binlog_direct_non_transactional_updates = OFF binlog_file_cache_size = 16384 binlog_format = MIXED binlog_optimize_thread_scheduling = ON binlog_row_image = FULL binlog_row_metadata = NO_LOG binlog_stmt_cache_size = 32768 bulk_insert_buffer_size = 8388608 character_set_client = utf8mb4 character_set_connection = utf8mb4 character_set_database = utf8mb4 character_set_filesystem = binary character_set_results = utf8mb4 character_set_server = utf8mb4 character_set_system = utf8 character_sets_dir = /usr/share/mysql/charsets/ check_constraint_checks = ON collation_connection = utf8mb4_general_ci collation_database = utf8mb4_general_ci collation_server = utf8mb4_general_ci column_compression_threshold = 100 column_compression_zlib_level = 6 column_compression_zlib_strategy = DEFAULT_STRATEGY column_compression_zlib_wrap = OFF completion_type = NO_CHAIN concurrent_insert = AUTO connect_timeout = 10 core_file = OFF datadir = /var/lib/mysql/ date_format = %Y-%m-%d datetime_format = %Y-%m-%d = %H:%i:%s deadlock_search_depth_long = 15 deadlock_search_depth_short = 4 deadlock_timeout_long = 5000 deadlock_timeout_short = 1 debug_no_thread_alarm = OFF default_password_lifetime = 0 default_regex_flags = default_storage_engine = InnoDB default_tmp_storage_engine = default_week_format = 0 delay_key
Bug#1052613: Keepalived occasionally fails SSL_CHECK
Package: keepalived
Version: 1:2.2.7-1
I'm upgrading our servers from Bullseye to Bookworm. Some of them act as load
balancers using keepalived.
Right now I have one Bullseye and one Bookworm with the same configuration
checking the same services.
Several of our services are running on HTTPS therefore I'm using SSL_CHECK.
I can see that the Bookworm one occasionally fails SSL_CHECK for several
seconds on one service while the
Bullseye does not report any problem at all.
It's quite rare - not even once per hour with 2s loop delay.
I was looking for possible reason and I've found
https://github.com/openssl/openssl/issues/20365
https://github.com/pjsip/pjproject/issues/3632
https://stackoverflow.com/questions/18179128/how-to-manage-the-error-queue-in-openssl-ssl-get-error-and-err-get-error
They are all basically saying that you can have multiple SSL errors left in
error queue and you are supposed to
run|ERR_get_error() before calling |SSL_* functions.
I've tried to patch keepalived sources (see attachment) and the problem seems
to disappear.
I have no idea why is Bullseye package unaffected. It might be related to
different OpenSSL version.
What do you think about this?
--
Pavel Matěja
--- keepalived-2.2.7.orig/keepalived/check/check_ssl.c
+++ keepalived-2.2.7/keepalived/check/check_ssl.c
@@ -257,6 +257,7 @@ ssl_connect(thread_ref_t thread, int new
#endif
}
+ ERR_clear_error();
ret = SSL_connect(req->ssl);
return ret;
@@ -269,6 +270,7 @@ ssl_send_request(SSL * ssl, const char *
while (true) {
err = 1;
+ ERR_clear_error();
r = SSL_write(ssl, str_request, request_len);
if (SSL_ERROR_NONE != SSL_get_error(ssl, r))
break;
@@ -306,6 +308,7 @@ ssl_read_thread(thread_ref_t thread)
}
/* read the SSL stream - allow for terminating the data with '\0 */
+ ERR_clear_error();
r = SSL_read(req->ssl, req->buffer + req->len, (int)(MAX_BUFFER_LENGTH - 1 - req->len));
req->error = SSL_get_error(req->ssl, r);
Bug#1041272: transmission-daemon: Still SEGV
Package: transmission-daemon Followup-For: Bug #1041272 X-Debbugs-Cc: pkre...@gmail.com Please forget about my previous message. Went back to my self-packaged version and problem persists. It crashes in about 4 hours after starting. Maybe some dependency or unrelated package upgrade made this happen. I'm also affected by WebUI lockup already reported in another bug. Been running Transmission for years now without major problems, but it seems clear that 3.x is being way too problematic. Maybe maintainers should evaluate if their time is being properly used fixing what essentially looks like a broken version. Anyway, turning down to another seedbox-appropiate torrent client for the moment. Sorry for the rant.
Bug#1041272: transmission-daemon: Crashes every few hours, SEGV on systemctl error message
Package: transmission-daemon Followup-For: Bug #1041272 X-Debbugs-Cc: pkre...@gmail.com Don't know if this is related to the new patch or some other issue on my side, since this machine had some stability problemas a while ago. Please note I'm on ARM64, in case that could affect the results. Before trying the proposed update, I was running a self-packaged .deb with proposed patch on former issue and didn't have this problem. This is the output of systemctl status: Process: 22391 ExecStart=/usr/bin/transmission-daemon -f --log-error (code=killed, signal=SEGV) Main PID: 22391 (code=killed, signal=SEGV) Status: "Uploading 326.72 KBps, Downloading 158.81 KBps." CPU: 3h 13min 54.061s -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 6.1.0-12-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages transmission-daemon depends on: ii adduser3.134 ii libc6 2.36-9+deb12u1 ii libcurl4 7.88.1-10+deb12u1 ii libevent-2.1-7 2.1.12-stable-8 ii libminiupnpc17 2.2.4-1+b1 ii libnatpmp1 20150609-7.1+b2 ii libssl33.0.9-1 ii libsystemd0252.12-1~deb12u1 ii lsb-base 11.6 ii sysvinit-utils [lsb-base] 3.06-4 ii transmission-common3.00-2.1+deb12u1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages transmission-daemon recommends: ii transmission-cli 3.00-2.1+deb12u1 transmission-daemon suggests no packages. -- no debconf information
Bug#1050418: Conntrackd in Bookworm reverts byte order in src address sent by conntrackd in Bullseye
Package: conntrackd Version: 1:1.4.7-1+b2 Conntrackd package on Bullseye is 1:1.4.6-2. I'm upgrading our servers from Bullseye to Bookworm. Some of them act as load balancers and they are using conntrackd to synchronize TCP connection states using FTFW sync mode. I've noticed when I have primary server running Bullseye (conntrack v1.4.6) and secondary Bookworm (conntrack v1.4.7) I get bullseye:~$ sudo conntrack -L .. tcp 6 430554 ESTABLISHED src=x.y.49.137 dst=x.y.48.169 sport=35570 dport=636 src=10.170.0.153 dst=x.y.49.137 sport=636 dport=35570 [ASSURED] mark=0 use=1 .. bookworm:~$ sudo conntrack -L .. tcp 6 431388 ESTABLISHED src=x.y.49.137 dst=x.y.48.169 sport=35570 dport=636 src=153.0.170.10 dst=x.y.49.137 sport=636 dport=35570 [ASSURED] mark=0 use=1 .. Notice order of the 'src' address bytes. When failover occures all TCP connections via secondary balancer are broken as packets source addresses don't match those in conntrack table anymore. Downgrade of conntrack and conntrackd packages on Bookworm server solved this problem. I was unable to create 1.4.7 package for Bullseye. I'm not sure which version is considered to be acting correctly. Core of this problem might be related to https://git.netfilter.org/conntrack-tools/commit/?id=b55717d46ae3b7c3769192a66e565bc7c2d833a1 but I'm not familiar with conntrackd source code. I'm sorry I had to mask the public ip.
Bug#1043030: libmutter-11-0: Mutter crashes when closing mpv under Wayland
Package: libmutter-11-0 Version: 43.6-1~deb12u1 Severity: important Tags: upstream X-Debbugs-Cc: ann.deb...@rxtx.cx On Wayland session, GNOME Shell completely crashes when trying to close GPU accelerated windows, such as mpv (and probably alacritty) with segfault in libmutter-11-0. Seems like upstream bug: https://gitlab.gnome.org/GNOME/mutter/-/issues/2410 Steps to reproduce: - In GNOME Wayland session, open mpv to play some video; - Press "q" to quit mpv - If it does not crash, repeat - sometimes it does not crash in first quit dmesg: [62912.613013] gnome-shell[42148]: segfault at 0 ip 7f5a5ed5f1e0 sp 7ffc6671e3f8 error 4 in libmutter-11.so.0.0.0[7f5a5ec4f000+15a000] likely on CPU 23 (core 13, socket 0) [63316.119535] gnome-shell[436585]: segfault at 0 ip 7f3d9615f1e0 sp 7ffcea72ac58 error 4 in libmutter-11.so.0.0.0[7f3d9604f000+15a000] likely on CPU 20 (core 10, socket 0) [64056.582484] gnome-shell[446343]: segfault at 0 ip 7f1e4ed5f1e0 sp 7ffe012aca48 error 4 in libmutter-11.so.0.0.0[7f1e4ec4f000+15a000] likely on CPU 20 (core 10, socket 0) Expected action: do not crash:) -- System Information: Debian Release: 12.1 APT prefers stable APT policy: (900, 'stable'), (800, 'testing'), (700, 'unstable'), (600, 'experimental'), (500, 'stable-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.7 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libmutter-11-0 depends on: ii adwaita-icon-theme 43-1 ii gsettings-desktop-schemas 43.0-1 ii libatk1.0-02.46.0-5 ii libc6 2.36-9+deb12u1 ii libcairo-gobject2 1.16.0-7 ii libcairo2 1.16.0-7 ii libcanberra0 0.30-10 ii libcolord2 1.4.6-2.2 ii libdrm22.4.114-1+b1 ii libegl11.6.0-1 ii libfontconfig1 2.14.1-4 ii libfribidi01.0.8-2.1 ii libgbm122.3.6-1+deb12u1 ii libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1 ii libgl1 1.6.0-1 ii libglib2.0-0 2.74.6-2 ii libgnome-desktop-3-20 43.2-2 ii libgraphene-1.0-0 1.10.8-1 ii libgtk-3-0 3.24.37-2 ii libgudev-1.0-0 237-2 ii libice62:1.0.10-1 ii libinput10 1.22.1-1 ii libjson-glib-1.0-0 1.6.6-1 ii liblcms2-2 2.14-2 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-01.50.12+ds-1 ii libpangoft2-1.0-0 1.50.12+ds-1 ii libpipewire-0.3-0 0.3.65-3 ii libsm6 2:1.2.3-1 ii libstartup-notification0 0.12-6+b1 ii libsystemd0252.12-1~deb12u1 ii libudev1 252.12-1~deb12u1 ii libwacom9 2.6.0-1 ii libwayland-server0 1.21.0-1 ii libx11-6 2:1.8.4-2+deb12u1 ii libx11-xcb12:1.8.4-2+deb12u1 ii libxau61:1.0.9-1 ii libxcb-randr0 1.15-1 ii libxcb-res01.15-1 ii libxcb11.15-1 ii libxcomposite1 1:0.4.5-1 ii libxcursor11:1.2.1-1 ii libxdamage11:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxi6 2:1.8-1+b1 ii libxinerama1 2:1.1.4-3 ii libxkbcommon-x11-0 1.5.0-1 ii libxkbcommon0 1.5.0-1 ii libxkbfile11:1.1.0-1 ii libxrandr2 2:1.5.2-2+b1 ii libxtst6 2:1.2.3-1.1 ii mutter-common 43.6-1~deb12u1 libmutter-11-0 recommends no packages. libmutter-11-0 suggests no packages. Versions of packages libmutter-11-0 is related to: ii libegl-mesa0 [libegl-vendor] 22.3.6-1+deb12u1 ii libgl1-mesa-dri 22.3.6-1+deb12u1 ii libglx-mesa0 [libglx-vendor] 22.3.6-1+deb12u1 -- no debconf information
Bug#1037980: transmission-daemon: memory leaks
If this helps, I tried building Debian src package for my own system applying the Gentoo patch proposed on #1015003 instead of the Debian pkg openssl patch. Memory usage remains stable after several hours and didn't notice side effects for the moment, but didn't test the program deeply.
Bug#1015003: transmission-daemon: possible memory leaks in crypto-utils-openssl.c
Package: transmission-daemon Followup-For: Bug #1015003 X-Debbugs-Cc: pkre...@gmail.com Recently upgraded from Bullseye to Bookworm and hit what I think is this issue. Transmission-daemon gets killed by OOM every few hours. To be fair, I have a really huge amount of torrents, but it was running fine on the older version. Now it consumes every bit of RAM (8GB available) it has access to. In a torrent seedbox like this, it is completely unusable. Will version 4.0 reach stable or should i look into backports? -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 6.1.0-9-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages transmission-daemon depends on: ii adduser3.134 ii libc6 2.36-9 ii libcurl4 7.88.1-10 ii libevent-2.1-7 2.1.12-stable-8 ii libminiupnpc17 2.2.4-1+b1 ii libnatpmp1 20150609-7.1+b2 ii libssl33.0.9-1 ii libsystemd0252.6-1 ii lsb-base 11.6 ii sysvinit-utils [lsb-base] 3.06-4 ii transmission-common3.00-2.1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages transmission-daemon recommends: ii transmission-cli 3.00-2.1+b1 transmission-daemon suggests no packages. -- Configuration Files: /etc/transmission-daemon/settings.json [Errno 13] Permiso denegado: '/etc/transmission-daemon/settings.json' -- no debconf information
Bug#1034133: network-manager-pptp-gnome: no scrolling in vpn connection list. Debian 12
Package: gnome-shell Version: 43.3-3 Severity: wishlist Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** network-manager-pptp-gnome: no scrolling in vpn connection list. Debian 12 -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii gir1.2-accountsservice-1.0 22.08.8-6 ii gir1.2-adw-1 1.2.2-1 ii gir1.2-atk-1.0 2.46.0-5 ii gir1.2-atspi-2.0 2.46.0-5 ii gir1.2-freedesktop 1.74.0-3 ii gir1.2-gcr-3 3.41.1-1+b1 ii gir1.2-gdesktopenums-3.0 43.0-1 ii gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1 ii gir1.2-gdm-1.0 43.0-3 ii gir1.2-geoclue-2.0 2.6.0-2 ii gir1.2-glib-2.0 1.74.0-3 ii gir1.2-gnomebluetooth-3.042.5-3 ii gir1.2-gnomedesktop-3.0 43.2-2 ii gir1.2-graphene-1.0 1.10.8-1 ii gir1.2-gstreamer-1.0 1.22.0-2 ii gir1.2-gtk-3.0 3.24.37-2 ii gir1.2-gtk-4.0 4.8.3+ds-2 ii gir1.2-gweather-4.0 4.2.0-2 ii gir1.2-ibus-1.0 1.5.27-5 ii gir1.2-mutter-11 43.3-5 ii gir1.2-nm-1.01.42.4-1 ii gir1.2-nma-1.0 1.10.6-1 ii gir1.2-pango-1.0 1.50.12+ds-1 ii gir1.2-polkit-1.0122-3 ii gir1.2-rsvg-2.0 2.54.5+dfsg-1 ii gir1.2-soup-3.0 3.2.2-2 ii gir1.2-upowerglib-1.00.99.20-2 ii gir1.2-webkit2-4.1 2.40.0-3 ii gnome-backgrounds43.1-1 ii gnome-settings-daemon43.0-4 ii gnome-shell-common 43.3-3 ii gsettings-desktop-schemas43.0-1 ii gstreamer1.0-pipewire0.3.65-3 ii libatk-bridge2.0-0 2.46.0-5 ii libatk1.0-0 2.46.0-5 ii libc62.36-8 ii libcairo21.16.0-7 ii libecal-2.0-23.46.4-2 ii libedataserver-1.2-273.46.4-2 ii libgcr-base-3-1 3.41.1-1+b1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgirepository-1.0-11.74.0-3 ii libgjs0g 1.74.2-1 ii libgles2 1.6.0-1 ii libglib2.0-0 2.74.6-1 ii libglib2.0-bin 2.74.6-1 ii libgnome-autoar-0-0 0.4.3-1 ii libgnome-desktop-3-2043.2-2 ii libgraphene-1.0-01.10.8-1 ii libgtk-3-0 3.24.37-2 ii libgtk-4-1 4.8.3+ds-2 ii libical3 3.0.16-1+b1 ii libjson-glib-1.0-0 1.6.6-1 ii libmutter-11-0 43.3-5 ii libnm0 1.42.4-1 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libpolkit-agent-1-0 122-3 ii libpolkit-gobject-1-0122-3 ii libpulse-mainloop-glib0 16.1+dfsg1-2+b1 ii libpulse016.1+dfsg1-2+b1 ii libsecret-1-00.20.5-3 ii libsystemd0 252.6-1 ii libwayland-server0 1.21.0-1 ii libx11-6 2:1.8.4-2 ii libxfixes3 1:6.0.0-2 ii python3 3.11.2-1 Versions of packages gnome-shell recommends: ii bolt
Bug#1032349: libopenmpi-dev: MPI_Win_create fails with MPI_ERR_WIN for v4.1.0 and ob1
Package: libopenmpi-dev
Version: 4.1.0-10
Severity: important
Tags: newcomer
Dear Maintainer,
I have initially reported the issue at OpenMPI GiHub here:
https://github.com/open-mpi/ompi/issues/11466
But I can't reproduce it for the recent version 4.1.5 that I built from
source.
Also I can't reproduce it for the currently reported version 4.1.0 for
Fedora
So I believe that the issue is somehow related to Debian peculiarities.
The essence of the issue:
The following code:
```
#include
int main(int argc, char *argv[]) {
void *buf;
MPI_Win window;
MPI_Init(, );
MPI_Alloc_mem(16, MPI_INFO_NULL, );
MPI_Win_create(buf, 16, 1, MPI_INFO_NULL, MPI_COMM_WORLD, );
MPI_Win_free();
MPI_Free_mem(buf);
MPI_Finalize();
}
```
compiled as
```
gcc testwin2.c `pkg-config --cflags --libs ompi-c` -o testwin.x
```
and being launched as
```
mpiexec.openmpi -n 2 --mca osc_base_verbose 100 --mca pml_base_verbose 100
--mca btl_base_verbose 100 ./testwin.x
```
fails with error messages:
```
[localhost:43128] *** An error occurred in MPI_Win_create
[localhost:43128] *** reported by process [2029780993,1]
[localhost:43128] *** on communicator MPI_COMM_WORLD
[localhost:43128] *** MPI_ERR_WIN: invalid window
[localhost:43128] *** MPI_ERRORS_ARE_FATAL (processes in this communicator
will now abort,
[localhost:43128] ***and potentially your MPI job)
```
The same code works well on Fedora PC both with ucx and ob1 PML
implementations with the same OpenMPI version 4.1.0
-- System Information:
Debian Release: 11.6
APT prefers stable
APT policy: (900, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 libopenmpi-dev depends on:
ii gfortran [gfortran-mod-15] 4:10.2.1-1
ii gfortran-10 [gfortran-mod-15] 10.2.1-6
ii libevent-dev 2.1.12-stable-1
ii libhwloc-dev 2.4.1+dfsg-1
ii libibverbs-dev 33.2-1
ii libjs-jquery 3.5.1+dfsg+~3.5.5-7
ii libjs-jquery-ui1.12.1+dfsg-8+deb11u1
ii libopenmpi34.1.0-10
ii libpmix-dev4.0.0-4.1
ii openmpi-bin4.1.0-10
ii openmpi-common 4.1.0-10
ii zlib1g-dev 1:1.2.11.dfsg-2+deb11u2
Versions of packages libopenmpi-dev recommends:
ii libcoarrays-openmpi-dev 2.9.2-3
Versions of packages libopenmpi-dev suggests:
pn openmpi-doc
Bug#730111: Still present in 2.1.3-1
On Fri, 4 Dec 2020 21:24:23 +0100 Pavel Sanda wrote: > On Wed, 18 Mar 2015 12:28:48 +0100 Alexander Stiebing > wrote: > > Bug still like described in Nov. 2013, none of the proposed actions out > > of the comments have been done. > > The change of the message to be more informative will be fixed in lyx 2.3.7 & > 2.4. > https://www.lyx.org/trac/changeset/b670990bc12fe1dd1d9d7b5fa8258a32caa7e91a/lyxgit > > Moving RCS from suggested to Recommends look reasonable to me. > After that the bug can be closed. Dear Tobias, what is your take on this? 2.3.7 with fixed error handling is now in bookworm. - Either this is enough and we close the bug as wontfix - or we add RCS as Recommended and this is the right time to do it. I do not have strong opinion, what is your take on this? Pavel
Bug#1029234: lyx: Graphic problems editing a lyx file
On Mon, Jan 23, 2023 at 12:05:05PM +0100, Stefano Simonucci wrote: > With the driver nouveau instead of nvidia lyx is working also in the mate > (or gnome) environment. To sum, the offending commit in 2.3.7 is 8b6460e4f2d40 (Improve HiDpi handling). The suggestion is to add in ~/.lyx/preferences \draw_strategy backingstore and also report back the environment (Wayland/X11, Gnome/KDE/...), Qt version and whether HiDPI is used on the systema. Since I did not get any additional response from the reporter this is best we can have for the moment. Pavel
Bug#1029234: lyx: Graphic problems editing a lyx file
On Sun, Jan 22, 2023 at 08:04:09PM +0100, Dr. Tobias Quathamer wrote: > Sorry that I cannot provide any more useful ideas to narrow down this bug. We discovered meantime with Stefano the offending commit in 2.3.7 and opened the issue on lyx devel list. Pavel
Bug#1029234: lyx: Graphic problems editing a lyx file
On Fri, Jan 20, 2023 at 11:28:31AM +0100, Stefano Simonucci wrote: > I have updated the whole system. Do I try reinstalling lyx 2.3.6? If it's in your capabilities to build 2.3.6 on your own that would help. (apt build-dep lyx (as a root) and then compile locally as user and just try running it - happy to provide more instructions if necessary). Pavel
Bug#1029234: lyx: Graphic problems editing a lyx file
On Fri, Jan 20, 2023 at 11:13:31AM +0100, Stefano Simonucci wrote: > After the last upgrade of the package, the lyx editor is broken. Just to be sure: 1) it worked correcly with 2.3.6? 2) the only thing which was upgraded was LyX but not the rest of the system (e.g. Qt libes/ X libraries...)? Pavel
Bug#1026039: lyx: LyX is listed as proprietary software in Gnome-software
On Tue, Dec 13, 2022 at 04:23:21PM -0500, Jeremy Bicha wrote: > On Tue, Dec 13, 2022 at 4:19 PM Pavel Sanda wrote: > > > > On Tue, 13 Dec 2022 17:50:03 +0100 Lorenzo Bertini > > wrote: > > > LyX is listed on my system as proprietary software in gnome-software. > > > Looking online I found several people having this issue with other > > > programs, and the cause was always that the license couldn't be read by > > > gnome-software properly. > > > > > > Please ensure that gnome-software can properly read the license. If the > > > bug is not on our end, let me know and I will contact gnome-software > > > developers. > > > > Well, LyX installs it's licences where it should, i.e. into > > /usr/share/doc/lyx/copyright. > > If there is something specific WRT gnome, we can do it but we need > > gnome maintainers input... I don't use gnome personally so can't > > even test it. > > > > I CC maintainer of gnome-software if he has some hints for us. > > The GNOME Software app prefers to use AppStream metadata. > > https://wiki.debian.org/AppStream/Guidelines > https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html I see, thanks for your input. Ok, then this should be fixed in 2.4 series (cd5d1be8f8925) as org.lyx.LyX.metainfo.xml will be installed in /usr/share/metainfo/. For 2.3.x series appdata.xml is inside tarball but not installed. Tobias, 2.3.7 should be out within two weeks and I leave it to you whether manually fix it for bookworm's 2.3.7 or leave it for 2.4 which won't make it for the upcoming debian release. Pavel
Bug#1026039: lyx: LyX is listed as proprietary software in Gnome-software
On Tue, 13 Dec 2022 17:50:03 +0100 Lorenzo Bertini wrote: > LyX is listed on my system as proprietary software in gnome-software. Looking > online I found several people having this issue with other programs, and the > cause was always that the license couldn't be read by gnome-software properly. > > Please ensure that gnome-software can properly read the license. If the bug > is not on our end, let me know and I will contact gnome-software developers. Well, LyX installs it's licences where it should, i.e. into /usr/share/doc/lyx/copyright. If there is something specific WRT gnome, we can do it but we need gnome maintainers input... I don't use gnome personally so can't even test it. I CC maintainer of gnome-software if he has some hints for us. Pavel
Bug#1023555: fastnetmon: FTBFS with libbpf 1.0
Hello! I think I have one more question. For most of the platforms we support libbpf 1.0.1 works fine but I noticed issues with Debian 11 and Ubuntu 20 about enum declarations: In file included from /tmp/fastnetmon.build.dir.i2Ak87Hs7Y/fastnetmon/src/xdp_plugin/xdp_collector.cpp:14: /opt/fastnetmon-community/libraries/libbpf_1_0_1/include/bpf/bpf.h:396:6: error: use of enum 'bpf_stats_type' without previous declaration 396 | enum bpf_stats_type; /* defined in up-to-date linux/bpf.h */ | ^~ /opt/fastnetmon-community/libraries/libbpf_1_0_1/include/bpf/bpf.h:397:38: error: use of enum 'bpf_stats_type' without previous declaration 397 | LIBBPF_API int bpf_enable_stats(enum bpf_stats_type type); | ^~ In file included from /tmp/fastnetmon.build.dir.i2Ak87Hs7Y/fastnetmon/src/xdp_plugin/xdp_collector.cpp:15: /opt/fastnetmon-community/libraries/libbpf_1_0_1/include/bpf/libbpf.h:70:54: error: use of enum 'bpf_link_type' without previous declaration 70 | LIBBPF_API const char *libbpf_bpf_link_type_str(enum bpf_link_type t); | ^~~~ Did you experience similar errors previously by any chance? Thank you! On Tue, 8 Nov 2022 at 16:55, Pavel Odintsov wrote: > Hello! > > Added copy to all. > > I think I fixed it with these commits: > https://github.com/pavel-odintsov/fastnetmon/commit/c48497a6f109fc1a9f5da596b055c3b7cffb96d4 > and > https://github.com/pavel-odintsov/fastnetmon/commit/c718e88d0b25dcfbd724e9820f592fd5782eca6c > > I've used > https://lore.kernel.org/bpf/20220202225916.3313522-7-and...@kernel.org/ > and > https://lxr.missinglinkelectronics.com/linux+v5.19/samples/bpf/xdp1_user.c > as examples as this code was my reference during implementation. > > Would be great if you could review it a second time. > > Thank you! > > On Mon, 7 Nov 2022 at 11:59, Sudip Mukherjee > wrote: > >> Hi Pavel, >> >> On Mon, Nov 7, 2022 at 11:53 AM Pavel Odintsov >> wrote: >> > >> > Hello! >> > >> > Thank you for reaching me. >> > >> > Sure, I'll be happy to check. >> > >> > May I kindly ask what exactly changed to trigger these errors? I >> believe it was successfully built previously. >> >> Its the update of libbpf to v1.0.1 which removed some of the deprecated >> API. >> >> >> -- >> Regards >> Sudip >> > > > -- > Sincerely yours, Pavel Odintsov > -- Sincerely yours, Pavel Odintsov
Bug#1023555: fastnetmon: FTBFS with libbpf 1.0
Hello! Added copy to all. I think I fixed it with these commits: https://github.com/pavel-odintsov/fastnetmon/commit/c48497a6f109fc1a9f5da596b055c3b7cffb96d4 and https://github.com/pavel-odintsov/fastnetmon/commit/c718e88d0b25dcfbd724e9820f592fd5782eca6c I've used https://lore.kernel.org/bpf/20220202225916.3313522-7-and...@kernel.org/ and https://lxr.missinglinkelectronics.com/linux+v5.19/samples/bpf/xdp1_user.c as examples as this code was my reference during implementation. Would be great if you could review it a second time. Thank you! On Mon, 7 Nov 2022 at 11:59, Sudip Mukherjee wrote: > Hi Pavel, > > On Mon, Nov 7, 2022 at 11:53 AM Pavel Odintsov > wrote: > > > > Hello! > > > > Thank you for reaching me. > > > > Sure, I'll be happy to check. > > > > May I kindly ask what exactly changed to trigger these errors? I believe > it was successfully built previously. > > Its the update of libbpf to v1.0.1 which removed some of the deprecated > API. > > > -- > Regards > Sudip > -- Sincerely yours, Pavel Odintsov
Bug#1023555: fastnetmon: FTBFS with libbpf 1.0
Hello! Thank you for reaching me. Sure, I'll be happy to check. May I kindly ask what exactly changed to trigger these errors? I believe it was successfully built previously. On Mon, 7 Nov 2022 at 10:55, Patrick Matthäi wrote: > Hey, > > Am 06.11.2022 um 19:32 schrieb Sudip Mukherjee: > > On Sun, Nov 6, 2022 at 3:51 PM Sebastian Ramacher > wrote: > >> Source: fastnetmon > >> Version: 1.2.3-1 > >> Severity: serious > >> Tags: ftbfs > >> Justification: fails to build from source (but built successfully in > the past) > >> X-Debbugs-Cc: sramac...@debian.org, sudipm.mukher...@gmail.com > >> > >> > https://buildd.debian.org/status/fetch.php?pkg=fastnetmon=amd64=1.2.3-1%2Bb1=1667748889=0 > > oops, sorry I missed it in my list of packages depending on libbpf. It > > seems "fastnetmon" added the dependency on libbpf with the last upload > > and I generated my list before that. :( > > > > Please let me know if you want me to help with a patch to port the > > code to libbpf. > > > > > Yeah it is a new feature and was just added, dont worry :-) > > @Pavel: This is for you, if you need help maybe dont hestiate to ask > Sudip (thanks for your offer!) > > -- > /* > Mit freundlichem Gruß / With kind regards, > Patrick Matthäi > GNU/Linux Debian Developer > >Blog: https://www.linux-dev.org/ > E-Mail: pmatth...@debian.org > patr...@linux-dev.org > */ > > -- Sincerely yours, Pavel Odintsov
Bug#1014754: linux-image-5.10.0-13-amd64: ptrace does not substitute SIGSTOP correctly
Package: src:linux Version: 5.10.106-1 Severity: normal X-Debbugs-Cc: pa...@labath.sk, mgorny@moritz.systems Dear Maintainer, Using PTRACE_CONT with a signal number should immediately deliver that signal to the application. This is what happens whenever the applications is stopped due to some signal other than SIGSTOP. It is also what happens with SIGSTOPs on other linux distros I tried (this includes a 5.10-based gentoo kernel), but for some reason, it does not happen with the debian kernel. I assume this is due to some upstream bug/quirk, which has since been fixed. To reproduce, compile the attached program: - $ g++ repr-stop.cc $ ./a.out Unexpectedly stopped with User defined signal 1 a.out: repr-stop.cc:34: void parent(pid_t): Assertion `WIFEXITED(status)' failed. Aborted - The expected behavior is for the program to terminate with exit code zero and print the "hello from %x" message. -- Package-specific info: ** Version: Linux version 5.10.0-13-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.106-1 (2022-03-17) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-13-amd64 root=/dev/mapper/VOY-debian ro net.ifnames=0 quiet ** Not tainted ** Kernel log: No relevant messages in kernel log. ** Model information sys_vendor: HP product_name: HP ProBook 450 G7 product_version: chassis_vendor: HP chassis_version: bios_vendor: HP bios_version: S71 Ver. 01.07.02 board_vendor: HP board_name: 86A0 board_version: KBC Version 02.2F.00 ** Loaded modules: tun ctr ccm dm_crypt cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel bluetooth uvcvideo videobuf2_vmalloc snd_soc_skl_hda_dsp videobuf2_memops snd_soc_hdac_hdmi jitterentropy_rng videobuf2_v4l2 videobuf2_common drbg videodev ansi_cprng ecdh_generic mc ecc snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_soc_dmic snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_sof_xtensa_dsp intel_pmc_core_pltdrv intel_pmc_core snd_sof snd_sof_intel_hda snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi ledtrig_audio snd_hda_intel joydev snd_intel_dspcfg soundwire_intel soundwire_generic_allocation snd_soc_core snd_compress x86_pkg_temp_thermal soundwire_cadence intel_powerclamp coretemp snd_hda_codec kvm_intel kvm iwlmvm iTCO_wdt intel_pmc_bxt hid_multitouch iTCO_vendor_support hp_wmi mmc_block watchdog irqbypass hid_generic mei_hdcp crc32_pclmul intel_rapl_msr sparse_keymap wmi_bmof ghash_clmulni_intel rapl intel_cstate intel_uncore mac80211 binfmt_misc snd_hda_core ahci libarc4 snd_hwdep libahci soundwire_bus xhci_pci pcspkr efi_pstore libata xhci_hcd iwlwifi snd_pcm nls_ascii r8169 i2c_i801 snd_timer nls_cp437 i2c_smbus snd realtek vfat mdio_devres soundcore fat cfg80211 libphy scsi_mod usbcore sdhci_pci mei_me mei cqhci sdhci processor_thermal_device intel_lpss_pci ucsi_acpi typec_ucsi i2c_hid intel_lpss intel_rapl_common idma64 mmc_core rfkill usb_common intel_pch_thermal intel_soc_dts_iosf tpm_crb typec hid wmi battery int3403_thermal int340x_thermal_zone tpm_tis tpm_tis_core tpm hp_accel rng_core lis3lv02d acpi_pad int3400_thermal hp_wireless ac button acpi_thermal_rel parport_pc ppdev lp parport fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic i915 dm_mod i2c_algo_bit drm_kms_helper cec crc32c_intel drm aesni_intel nvme nvme_core glue_helper libaes crypto_simd cryptd evdev t10_pi crc_t10dif serio_raw crct10dif_generic crct10dif_pclmul crct10dif_common video ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Comet Lake-U v1 4c Host Bridge/DRAM Controller [8086:9b61] (rev 0c) Subsystem: Hewlett-Packard Company Comet Lake-U v1 4c Host Bridge/DRAM Controller [103c:86a0] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: skl_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation CometLake-U GT2 [UHD Graphics] [8086:9b41] (rev 02) (prog-if 00 [VGA controller]) DeviceName: Onboard IGD Subsystem: Hewlett-Packard Company UHD Graphics [103c:86a0] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 0c) Subsystem: Hewlett-Packard Company Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [103c:86a0] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr-
Bug#950307: YAML syntax highlight is broken on multiline blocks
On Fri, 31 Jan 2020 11:14:34 +0300 Vladimir K wrote: > Package: mc > Version: 3:4.8.24-2 > Severity: normal > Tags: upstream > > Dear Maintainer, in the newest version of mcedit syntax highlight for YAML > inline block highlight is started after '>' or '|' directives, but does not end > until EOF. > > Instead it should end after encountering any of: > - an empty line > - a line with the same indent as the key of current value > - a line with less indent than the first line of inline block > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (900, 'testing'), (400, 'unstable'), (300, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_USER > Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages mc depends on: > ii libc6 2.29-9 > ii libext2fs21.45.5-2 > ii libglib2.0-0 2.62.4-1+b1 > ii libgpm2 1.20.7-5+b1 > ii libslang2 2.3.2-4 > ii libssh2-1 1.8.0-2.1 > ii mc-data 3:4.8.24-2 > > Versions of packages mc recommends: > ii mime-support 3.64 > ii perl 5.30.0-9 > ii unzip 6.0-25 > > Versions of packages mc suggests: > ii arj 3.10.22-23 > ii bzip21.0.8-2 > pn dbview > pn djvulibre-bin > pn epub-utils > ii evince [pdf-viewer] 3.34.1-1+b1 > ii file 1:5.38-4 > ii genisoimage 9:1.1.11-3.1 > pn gv > ii imagemagick 8:6.9.10.23+dfsg-2.1+b2 > ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+b2 > pn libaspell-dev > ii lynx 2.9.0dev.4-1 > ii mupdf [pdf-viewer] 1.15.0+ds1-1+b1 > pn odt2txt > ii poppler-utils0.71.0-6 > ii python 2.7.17-2 Hello. I am trying to fix yaml syntax highliting for multiline blocks. There is the process: https://github.com/kran0/mc/blob/improve-mcedit-yaml.syntax/misc/syntax/yaml.syntax Please, test this variant and write what you think about it. To test it, just place yaml.syntax to ~/.local/share/mc/mcedit/yaml.syntax Thanks a lot. PS. My PR is: https://github.com/MidnightCommander/mc/pull/170 And i have commented the bug entry: https://midnight-commander.org/ticket/4059
Bug#1012265: timeshift: New upstream
Package: timeshift Severity: normal X-Debbugs-Cc: pavel.bore...@gmail.com Dear Maintainer, original maintainer handed of development of this backup tool to new one(s) - see: https://blog.linuxmint.com/?p=4323 "Unfortunately he (orig. developer) had to stop developing Timeshift to focus on his other projects. We got in touch with him to see how we could help and the decision was made to take over the maintenance." New source code home: https://github.com/linuxmint/timeshift Thanks for reflecting this -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-33-generic (SMP w/4 CPU threads) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages timeshift depends on: ii libc62.35-0ubuntu3 ii libcairo21.16.0-5ubuntu2 ii libgdk-pixbuf-2.0-0 2.42.8+dfsg-1 ii libgee-0.8-2 0.20.5-2 ii libglib2.0-0 2.72.1-1 ii libgtk-3-0 3.24.33-1ubuntu2 ii libjson-glib-1.0-0 1.6.6-1build1 ii libvte-2.91-00.68.0-1 ii psmisc 23.4-2build3 ii rsync3.2.3-8ubuntu3 timeshift recommends no packages. timeshift suggests no packages.
Bug#1010624: neuron-dev: Compilation/linking problems with nrnivmodl
Package: neuron-dev Version: 7.6.3-1+b3 Severity: normal X-Debbugs-Cc: sa...@lyx.org Dear Maintainer, I encountered several problems while trying to compile with nrnivmodl. When running it nrnivmodl expects that 1) for compilation openmpi (mpicc et al.) is present 2) for linking -lmeschach is expected to work 1. is solved by installing libopenmpi-dev 2. is solved by installing libmeschach-dev (libmeschach.so.1.2 was present, but for -lmeschach to work libmeschach.so link needs to be present and that is provided by libmeschach-dev) I wonder whether these should be dependencies (or at least suggested ones) for neuron-dev. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-13-amd64 (SMP w/8 CPU threads) Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages neuron-dev depends on: ii libc6 2.31-13+deb11u3 ii libstdc++6 10.2.1-6 ii neuron 7.6.3-1+b3 neuron-dev recommends no packages. neuron-dev suggests no packages. -- no debconf information
Bug#1010160: x11-xkb-utils: setxkbmap -layout cz_qwerty loads layout which fails with a particular dead-key combination
On Mon, Apr 25, 2022 at 04:25:04PM +0200, Julien Cristau wrote: > On Mon, Apr 25, 2022 at 03:53:22PM +0200, Pavel Sanda wrote: > > for keyboard configuration I use the following command on my system: > > setxkbmap -model pc105 -layout "us,cz_qwerty" -option > > "grp:alt_shift_toggle" > > > > The cz_qwerty layout works mostly fine, except one singular failure: > > dead-key ˇ (caron) + u (the same for upper-case variant ˇ+U). > > > > I am afraid non-native prepared/"fixed" this layout, because the layout > > logically ends up with caron+u, which is non-existent in czech while > > on all czech keyboards you end up with overring+u (ů, see > > https://en.wikipedia.org/wiki/Ring_(diacritic) ). > > > > It renders this layout unusable for continuous czech writing, can it get > > fixed? > > (Or at leat can you give me a hint where to fix this, I expect this could > > be two-liner change in some kayboard-layout files...) > > > The cz_qwerty layout is defined here: > https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/ade97960d7bfc7fde8d08e9fa5584e7c3c51c23b/symbols/cz#L81 > > Key combinations including those with dead keys live in Xlib though: > https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/master/nls/en_US.UTF-8/Compose.pre > > Reassigning to xkeyboard-config for now, let us know if you end up > reporting/fixing this upstream. Thanks. I figured out that this is actually minor problem as I can avoid dead caron altogether, as caps lock works with ů (for some reason I was mislead by seing the character " on top of the key ů, but of course caps lock is not identical to the shift key). So although I still consider this bug in the layout, its fairly minor and if we close this as wontfix, it's not big deal. Pavel
Bug#1010160: x11-xkb-utils: setxkbmap -layout cz_qwerty loads layout which fails with a particular dead-key combination
Package: x11-xkb-utils Version: 7.7+5 Severity: normal X-Debbugs-Cc: sa...@lyx.org Dear Maintainer, for keyboard configuration I use the following command on my system: setxkbmap -model pc105 -layout "us,cz_qwerty" -option "grp:alt_shift_toggle" The cz_qwerty layout works mostly fine, except one singular failure: dead-key ˇ (caron) + u (the same for upper-case variant ˇ+U). I am afraid non-native prepared/"fixed" this layout, because the layout logically ends up with caron+u, which is non-existent in czech while on all czech keyboards you end up with overring+u (ů, see https://en.wikipedia.org/wiki/Ring_(diacritic) ). It renders this layout unusable for continuous czech writing, can it get fixed? (Or at leat can you give me a hint where to fix this, I expect this could be two-liner change in some kayboard-layout files...) -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-13-amd64 (SMP w/8 CPU threads) Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages x11-xkb-utils depends on: ii libc62.31-13+deb11u3 ii libx11-6 2:1.7.2-1 ii libxaw7 2:1.0.13-1.1 ii libxkbfile1 1:1.1.0-1 ii libxt6 1:1.2.0-1 x11-xkb-utils recommends no packages. x11-xkb-utils suggests no packages. -- no debconf information
Bug#1008257: lyx: bash-completion not working
On Fri, Mar 25, 2022 at 01:53:53PM -0300, Hernán Gustavo Solari wrote: > I work as well as the other. The fix was committed to upstream and will be fixed in 2.4. Pavel
Bug#1008266: unar: obsolete syntax of bash-completion file
Package: unar Version: 1.10.1-2+b6 Severity: normal Tags: patch X-Debbugs-Cc: sa...@lyx.org Dear Maintainer, bash-completion script syntax is outdated for this package and as a result completion does not work here. The situation can be simply fixed by replacing "have" to "_have" keyword at lines 3 & 46. -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unar depends on: ii dpkg 1.20.9 ii gnustep-base-runtime 1.27.0-3 ii libbz2-1.01.0.8-4 ii libc6 2.31-13+deb11u2 ii libgcc-s1 10.2.1-6 ii libgnustep-base1.27 1.27.0-3 ii libicu67 67.1-7 ii libobjc4 10.2.1-6 ii libstdc++610.2.1-6 ii libwavpack1 5.4.0-1 ii zlib1g1:1.2.11.dfsg-2 unar recommends no packages. unar suggests no packages. -- no debconf information
Bug#1008257: lyx: bash-completion not working
On Fri, Mar 25, 2022 at 10:45:22AM -0300, Hernán Gustavo Solari wrote: > FIXED! > I am attaching the script. I think the end of script should be different though. See attached. Does this script work the way you expect? Pavel lyx Description: application/lyx
Bug#1008257: lyx: bash-completion not working
On Fri, Mar 25, 2022 at 09:39:54AM -0300, Hernán Gustavo Solari wrote: > The bash-complete script does not work. It calls "have lyx" but have is not a > program. Strange "have()" should have been defined in /usr/share/bash-completion/bash_completion which should be called via /etc/bash_completion But it does not work here either. Not completion expert, but I see bunch of other scripts using "have" as well so I wonder whether this is wider issue. Pavel
Bug#1008040: libelementary1 1.26.2-1+b1 should recommend same version of libelementary-bin
Package: libelementary1 Version: 1.26.2-1+b1 Severity: minor Dear Maintainer, the bookworm version of libelementary1 (1.26.2-1+b1) recommends old (now non-existing in archives) version of libelementary-bin: 1.26.2-1 instead of 1.26.2-1+b1. Thanks for fixing that, Pavel -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (840, 'testing'), (740, 'unstable'), (738, 'experimental'), (540, 'proposed-updates'), (540, 'stable'), (500, 'stable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libelementary1 depends on: ii libc6 2.33-7 ii libecore-con1 1.26.2-1+b1 ii libecore-evas11.26.2-1+b1 ii libecore-file11.26.2-1+b1 ii libecore-imf1 1.26.2-1+b1 ii libecore-input1 1.26.2-1+b1 ii libecore-wl2-11.26.2-1+b1 ii libecore-x1 1.26.2-1+b1 ii libecore1 1.26.2-1+b1 ii libedje1 1.26.2-1+b1 ii libeet1 1.26.2-1+b1 ii libefreet-bin 1.26.2-1+b1 ii libefreet1a 1.26.2-1+b1 ii libeina1a 1.26.2-1+b1 ii libeio1 1.26.2-1+b1 ii libelementary-data1.26.2-1 ii libemile1 1.26.2-1+b1 ii libemotion1 1.26.2-1+b1 ii libethumb-client-bin 1.26.2-1+b1 ii libethumb-client1 1.26.2-1+b1 ii libevas1 1.26.2-1+b1 ii libwayland-client01.20.0-1 Versions of packages libelementary1 recommends: hi libelementary-bin 1.26.2-1 libelementary1 suggests no packages. -- no debconf information
Bug#1007712:
Thank you very much for being so responsive and quick, Andrius! I deeply appreciate that :) The change will save my team a lot of hassle. One more thing though, while completely optional, would still be very nice - we use an OS release which has 4.8 version frozen in the repos (Ubuntu 20.04). If you can somehow affect that release to update (maybe by pushing the change to the 4.8 release branch), that would be very helpful. Either way, thanks a lot! Have a nice day Pavel
Bug#1007712: libantlr4-runtime-dev: CMake definitions (.cmake files) are missing
Package: libantlr4-runtime-dev Version: 4.8+dfsg-2build1 Severity: important Dear Andrius Merkys, I am trying to use antlr4-cpp-runtime package to provide ANTLR C++ runtime to my application which is being built by CMake. I've observed that antlr4-cpp-runtime/cmake/Antlr4Package.md file describes 2 exposed CMake packages upon library installation, but unfortunately none are included in the Debian package's filelist. Could you please include resulting .cmake files from the upstream's build to a respecting system directory, so that CMake could include headers installed by this Debian package? I suppose 'ANTLR4_INSTALL' CMake variable is not enabled, but maybe I am wrong. I am using package version 4.8, but I've checked the filelist for the latest version, and the issue still seems to be valid. Related issue: https://github.com/antlr/antlr4/issues/2606 Related comment: https://github.com/antlr/antlr4/issues/2606#issuecomment-524323579 -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (100, 'focal-backports') Architecture: arm64 (aarch64) Kernel: Linux 5.4.0-104-generic (SMP w/4 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) LSM: AppArmor: enabled Versions of packages libantlr4-runtime-dev depends on: ii libantlr4-runtime4.8 4.8+dfsg-2build1 libantlr4-runtime-dev recommends no packages. libantlr4-runtime-dev suggests no packages. -- no debconf information
Bug#1002821: lyx-common: String/Bytes Problem in layout2layout.py
On Mon, 3 Jan 2022 21:53:44 +0100 Pavel Sanda wrote: > On Wed, 29 Dec 2021 04:15:48 -0800 "Leo L. Schwab" wrote: > > Discovered this while trying to use Editorium's LyXBook modules. > > layout2layout.py was konking out with "TypeError: cannot use a bytes > > pattern on a string-like object." After a bunch of debugging, I found > > some strings in the script that hadn't been bytes-ified, which seemed to > > fix the problem. Patch attached. > > The patch can not be taken as is to the upstream. > Would you mind reporting the exact recipy how to reproduce your problem > (maybe attach layout and example lyx file?) The bug should be fixed upstream in lyx 2.4 https://www.lyx.org/trac/changeset/940d3ceeb9e6d8ce216afedf18c898ec075cc27d/lyxgit Pavel
Bug#1002821: lyx-common: String/Bytes Problem in layout2layout.py
On Wed, 29 Dec 2021 04:15:48 -0800 "Leo L. Schwab" wrote: > Discovered this while trying to use Editorium's LyXBook modules. > layout2layout.py was konking out with "TypeError: cannot use a bytes > pattern on a string-like object." After a bunch of debugging, I found > some strings in the script that hadn't been bytes-ified, which seemed to > fix the problem. Patch attached. The patch can not be taken as is to the upstream. Would you mind reporting the exact recipy how to reproduce your problem (maybe attach layout and example lyx file?) Thanks, Pavel
Bug#995170: mc: Subshell Ctrl+o stopped working with upgrade from 4.8.26-1.1 => 4.8.27-1
Package: mc Version: 3:4.8.27-1 Severity: normal Dear Maintainer, since the recent update of Midnight Commander to version 4.8.27-1 the subshell, normally accessible by Ctrl+o, is not working anymore for ordinary user. In the bottom line a simple '$' prompt is shown instead of full shell prompt, and after pressing Ctrl+o one cannot type any command - any keystroke returns back to the normal double-panel view. The problem is not present when running 'mc' as root. Removing user mc-configuration files does not help. Pavel -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (840, 'testing'), (740, 'unstable'), (738, 'experimental'), (540, 'proposed-updates'), (540, 'stable'), (500, 'stable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mc depends on: ii libc6 2.32-4 ii libext2fs21.46.4-1 ii libglib2.0-0 2.68.4-1 ii libgpm2 1.20.7-9 ii libslang2 2.3.2-5 ii libssh2-1 1.10.0-2 ii mc-data 3:4.8.27-1 Versions of packages mc recommends: ii mime-support3.66 ii perl5.32.1-5 ii sensible-utils 0.0.17 ii unzip 6.0-26 Versions of packages mc suggests: ii acroread [pdf-viewer]9.5.5-dmo14 ii arj 3.10.22-24 ii atril [pdf-viewer] 1.24.0-1+b1 ii bzip21.0.8-4 ii catdvi 0.14-12.1+b1 ii dbview 1.0.4-4 ii djvulibre-bin3.5.28-2 ii epub-utils 0.2.2-4+b4 ii evince [pdf-viewer] 40.4-2 ii file 1:5.39-3 ii genisoimage 9:1.1.11-3.2 ii gv [pdf-viewer] 1:3.7.4-2+b1 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3 ii libaspell-dev0.60.8-3 ii links2.24-1 ii lynx 2.9.0dev.9-2 ii odt2txt 0.5-7 ii okular [pdf-viewer] 4:21.08.1-1+b1 ii poppler-utils20.09.0-3.1 pn python pn python-boto ii python-tz2020.4-1 ii texlive-binaries 2021.20210626.59705-1 ii unar 1.10.1-2+b6 ii w3m 0.5.3+git20210102-6 pn wimtools ii zip 3.0-12 -- Configuration Files: /etc/mc/mc.ext changed [not included] -- no debconf information
Bug#995169: mc: Subshell Ctrl+o stopped working with upgrade from 4.8.26-1.1 => 4.8.27-1
Package: mc Version: 3:4.8.27-1 Severity: normal Dear Maintainer, since the recent update of Midnight Commander to version 4.8.27-1 the subshell, normally accessible by Ctrl+o, is not working anymore for ordinary user. In the bottom line a simple '$' prompt is shown instead of full shell prompt, and after pressing Ctrl+o one cannot type any command - any keystroke returns back to the normal double-panel view. The problem is not present when running 'mc' as root. Removing user mc-configuration files does not help. Pavel -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (840, 'testing'), (740, 'unstable'), (738, 'experimental'), (540, 'proposed-updates'), (540, 'stable'), (500, 'stable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mc depends on: ii libc6 2.32-4 ii libext2fs21.46.4-1 ii libglib2.0-0 2.68.4-1 ii libgpm2 1.20.7-9 ii libslang2 2.3.2-5 ii libssh2-1 1.10.0-2 ii mc-data 3:4.8.27-1 Versions of packages mc recommends: ii mime-support3.66 ii perl5.32.1-5 ii sensible-utils 0.0.17 ii unzip 6.0-26 Versions of packages mc suggests: ii acroread [pdf-viewer]9.5.5-dmo14 ii arj 3.10.22-24 ii atril [pdf-viewer] 1.24.0-1+b1 ii bzip21.0.8-4 ii catdvi 0.14-12.1+b1 ii dbview 1.0.4-4 ii djvulibre-bin3.5.28-2 ii epub-utils 0.2.2-4+b4 ii evince [pdf-viewer] 40.4-2 ii file 1:5.39-3 ii genisoimage 9:1.1.11-3.2 ii gv [pdf-viewer] 1:3.7.4-2+b1 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3 ii libaspell-dev0.60.8-3 ii links2.24-1 ii lynx 2.9.0dev.9-2 ii odt2txt 0.5-7 ii okular [pdf-viewer] 4:21.08.1-1+b1 ii poppler-utils20.09.0-3.1 pn python pn python-boto ii python-tz2020.4-1 ii texlive-binaries 2021.20210626.59705-1 ii unar 1.10.1-2+b6 ii w3m 0.5.3+git20210102-6 pn wimtools ii zip 3.0-12 -- Configuration Files: /etc/mc/mc.ext changed [not included] -- no debconf information
Bug#992592: lightdm fails to start after update to bullseye (missing '/var/lib/lightdm/data')
Package: lightdm Version: 1.26.0-7 Severity: grave Justification: renders package unusable X-Debbugs-Cc: sa...@lyx.org Dear Maintainer, updating debian to bullseye killed access to my desktop environment. It was actually stretch->buster and then (after appropriate reboots etc.) buster->bullseye, so not sure which of two steps broke it. lightdm used to be default DM and was not working anymore after the update. Checking logs with lightdm --test-mode --debug showed critical line about missing /var/lib/lightdm/data like in bugs #947319 and #931335. apt-get purge lightdm apt-get install lightdm fixed the situation (purge was clearly doing bunch of stuff in /etc/ which should be probably part of distro-update procedures(?). -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=C, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lightdm depends on: ii adduser3.118 ii dbus 1.12.20-2 ii debconf [debconf-2.0] 1.5.77 ii libaudit1 1:3.0-2 ii libc6 2.31-13 ii libgcrypt201.8.7-6 ii libglib2.0-0 2.66.8-1 ii libpam-systemd [logind]247.3-6 ii libpam0g 1.4.0-9 ii libxcb11.14-3 ii libxdmcp6 1:1.1.2-3 ii lightdm-gtk-greeter [lightdm-greeter] 2.0.8-2 ii lsb-base 11.1.0 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+22 Versions of packages lightdm suggests: ii accountsservice 0.6.55-3 ii upower 0.99.11-2 pn xserver-xephyr -- debconf information: * shared/default-x-display-manager: lightdm lightdm/daemon_name: /usr/sbin/lightdm
Bug#987124: console-setup not work properly with plymouth
Package: console-setup Version: 1.202 Severity: normal X-Debbugs-Cc: pvsamsono...@gmail.com Dear Maintainer, The /etc/init.d/console-setup.sh startup script does not change the system console font if the plymouth graphic splash screen is enabled at startup. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.31-tinyware-amd64 (SMP w/3 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages console-setup depends on: ii console-setup-linux 1.202 ii debconf 1.5.75 ii keyboard-configuration 1.202 ii xkb-data2.29-2 console-setup recommends no packages. Versions of packages console-setup suggests: ii locales 2.31-11 ii lsb-base 11.1.0 Versions of packages keyboard-configuration depends on: ii debconf 1.5.75 ii liblocale-gettext-perl 1.07-4+b1 Versions of packages console-setup-linux depends on: ii init-system-helpers 1.60 ii kbd 2.3.0-3 ii keyboard-configuration 1.202 console-setup-linux suggests no packages. Versions of packages console-setup is related to: pn console-common pn console-data pn console-tools pn gnome-control-center ii kbd 2.3.0-3 ii systemd 247.3-3 -- debconf-show failed
Bug#982250: Forking on MMSD
Hi!
> In talking to the Debian Developer Mr. Federico Ceratto, since I have
> been unable to get a hold of the Ofono Maintainers, the best course of
> action for packaging mmsd into Debian is to simply fork the project and
> submit my version upstream for packaging in Debian. My repository is
> here: https://source.puri.sm/kop316/mmsd/
Ofono maintainers are normally pretty responsive, and yes, you seem to
be cc-ing the right list.
I don't think forking ofono is good idea.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
signature.asc
Description: PGP signature
Bug#985691: nagios-nrpe-server: Default check_load limits are unnecessarily low.
Package: nagios-nrpe-server Version: 3.2.1-2 Severity: minor Dear Maintainer, Default configuration of check_load limits are unnecessarily low. Default values make alerts in common production server load. Default configuration: command[check_load]=/usr/lib/nagios/plugins/check_load -r -w .15,.10,.05 -c .30,.25,.20 Default proposal: command[check_load]=/usr/lib/nagios/plugins/check_load -r -w 15,10,05 -c 30,25,20 I mean this is mistype error. In old versions of package was values as in proposal (for examle: nagios-nrpe-server-3.0.1). Same error is in testing and unstable versions of package: nagios-nrpe-server_3.0.3 Best regards Pavel Polacek -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nagios-nrpe-server depends on: ii adduser3.118 ii libc6 2.28-10 ii libssl1.1 1.1.1d-0+deb10u5 ii libwrap0 7.6.q-28 ii lsb-base 10.2019051400 Versions of packages nagios-nrpe-server recommends: ii monitoring-plugins-basic 2.2-6 Versions of packages nagios-nrpe-server suggests: pn xinetd | inetd -- Configuration Files: /etc/nagios/nrpe.cfg changed [not included] /etc/nagios/nrpe_local.cfg changed [not included] -- no debconf information
Bug#981985: lyx: Frequently takes 100% CPU and hangs, sometimes until killed, sometimes just for seconds
On Sat, Feb 27, 2021 at 02:25:28PM +0100, Dr. Axel Stammler wrote: > It happens with all documents in different situations, one of them > reproducibly being: > > - file ??? save as > - trying to copy the filename by pressing ^C > - pressing to close the file dialogue > - Lyx now freezes for about 30s > - you get impatient and try to click on something (like ???cancel???) or to > close the file dialogue or Lyx by clicking on the window decoration Unfortunately I can not reproduce, though I am not sure I understand step 2 in the recipy. > I suspect it has something to do with Lyx's interaction with the window > manager. That migh well be. What WM do you use? It might also be that Qt version plays a role so we might want to recheck the problem once bullseye becomes stable. > > If you look on top report is 100% taken by lyx process itself or some > > conversion routine in background (e.g. conversion of figure). > > Lyx Is it in your capability to provide gdb backtrace from the freezing period or perhaps look whether strace reports something interesting at that time? (You might need something like $ strace /usr/bin/lyx 2>&1|grep -vE 'localtime|gettimeofday|clock_gettime|^read|POLLIN' to avoid excessive overreporting). Please keep bugs.debian.org CC-ed, thanks :) Pavel
Bug#981985: lyx: Frequently takes 100% CPU and hangs, sometimes until killed, sometimes just for seconds
On Fri, 05 Feb 2021 15:35:13 +0100 Axel Stammler wrote: > Package: lyx > Version: 2.3.2-1 > Severity: important > > Dear Maintainer, > > Lyx again and again suddenly stops reacting to pointer and keyboard and takes > all CPU > capacity. Sometimes it quickly recovers without any errors, sometimes it > needs to be killed > after, say, an hour. This will be hard to fix unless some more information is provided. Is there recipy how to reproduce this behaviour? Does it happen with some particular document? If you look on top report is 100% taken by lyx process itself or some conversion routine in background (e.g. conversion of figure). Pavel
Bug#980044: warning: while removing fonts-lyx, directory '/usr/share/fonts/truetype/lyx' not empty so not removed
On Wed, 13 Jan 2021 19:21:49 +0800 =?utf-8?B?56mN5Li55bC8?= Dan Jacobson wrote: > Removing fonts-lyx (2.3.6-1) ... > dpkg: warning: while removing fonts-lyx, directory > '/usr/share/fonts/truetype/lyx' not empty so not removed > > # find /usr/share/fonts/truetype/lyx > /usr/share/fonts/truetype/lyx > /usr/share/fonts/truetype/lyx/.uuid Dupe of your own bug #923939 from 2019. Haven't time to look at the issue, but the good news is that fontconfig should drop the .uuid feature in future releases. Pavel
Bug#867577: #867577 lyx: Alt-m triggers space dialog in math mode
On Fri, 30 Mar 2018 02:48:49 -0400 Paul Elliott wrote: > I have noticed this bug too. But only when using kde plasma, goes away when > using Gnome. I couldn't reproduce on plasma 5.18.5 & Qt 5.12.8. If you can still see this bug what versions of Qt and Plasma you are using? Pavel
Bug#915113: lyx: Has problem exporting to Postscript - fails on converting certain images
On Mon, Dec 14, 2020 at 03:41:37PM +0100, Pavel Sanda wrote:
> On Mon, 14 Dec 2020 12:11:50 +0100 Adrian Immanuel =?ISO-8859-1?Q?Kie=DF?=
> wrote:
> > the described problem of exporting to Postscript is gone.
>
> Good, closing this bug.
>
> > The problem, that seminar based slides are only exported to portrait
> > mode persist. Try to export a seminar based slide to landscape page
> > format, and it will always end up in portrait mode.
>
> Does adding
> \usepackage[landscape]{geometry}
> to preamble help?
If we are talking specifically about postscript, this bug might be related:
https://www.lyx.org/trac/ticket/2721
> Pavel
Bug#964090: Please upload backport
On Wed, 7 Oct 2020 13:15:23 -0700 Felix Lechner wrote: > Control: tags -1 + patch > > Hi, > > > Is this because of a ghostscript vulnerability? > > The PDF policy restriction is also in effect on Debian stable even > though that release ships with Ghostscript 9.27, which online sources > suggest is safe. [1] > > Converting images to PDF is a very common functionality. Please > provide a backport with the attached patch, or similar. Thanks! Another package negatively affected with the current restrictions is lyx - see bugs 911236 and 975678. PDF and EPS coders need to be allowed for normal functionality. Pavel
Bug#767072: lyx: default papersize neglect /etc/papersize ?
On Tue, 28 Oct 2014 14:12:48 +0100 SZABO Zsolt wrote: > I am very sorry, but it turned out after inspecting the situation more > precisely, that it is about the geometry package: > when I set margins explicitly then the geometry package is loaded > (of course) and its default papersize is different from the system default > which is overwritten... > > Anyway, I think it is still a (minor) bug, because a simple user who > originally used the default papersize setting and then sets the margins > does not expect that he should also set the papersize explicitly on a > different tab... I do not see that /etc/papersize is respected at all (in buster), not even LaTeX seem to respect it. This might not be trivial to get right. Moving to wishlist Pavel
Bug#915113: lyx: Has problem exporting to Postscript - fails on converting certain images
On Fri, 30 Nov 2018 17:05:58 +0100 Adrian Immanuel Kiess wrote: > currently in Debian/testing LyX fails on exporting to Postscript documents due > to error in exporting or converting certain images (if not all). Is this problem fixed for you now? Otherwise I would like to see the full output of when running postscript build (via View->Messages Pane). You ca ncopy paste the output directly into them email. Thanks, Pavel
Bug#930406: [lyx] lyx crashes on file dialog
On Wed, 12 Jun 2019 08:42:56 +0200 Tomasz Wartalski wrote: > Dear maintainer, > > * What led up to the situation? > > Opening lyx and trying to choose a file, e.g. a template. > > * What exactly did you do (or not do) that was effective (or ineffective)? > Opening a template file (e.g. in German: Datei -> Neu von Vorlage -> > choosing a template, eg. docbook article -> crash) > > * What was the outcome of this action? > lyx crashes > > * What outcome did you expect instead? > lyx should open a (template) file > > The same happens if i try to reconfigure lyx (in german: Werkzeuge -> > Neu konfigurieren). The problem is reproducible as it happens every time > i try to do one of the above. I´m using KDE at a recent debian testing. > > A backtrace is attached below. The backtrace is unfortunately not informative (and won't be unless you try to compile lyx on your own with debuging symbols enabled). I can not reproduce in stable-debian settings, so perhaps it has something to do with running unstable? Can you perhaps try whether it's better with 2.3.6 now? Pavel
Bug#935814: still actual for lyx (version 2.3.3-3) in debian unstable
On Thu, 23 Jan 2020 14:36:35 +0700 A L wrote: > Dear Maintainer, > this bug is still actual in lyx (version 2.3.3-3) in debian unstable This problem with non-ASCII paths should be fixed in 2.3.5. Can you give it a try in unstable? The lyx bug in question is here: https://www.lyx.org/trac/ticket/11146 Note however that some folks still report problems so we need more feedback on this: https://www.lyx.org/trac/ticket/11940 Note that in this bug underlying LaTeX version matters, so please report it together with lyx version. Thanks, Pavel
Bug#918504: lyx: `lyx --export latex ` outputs loads of errors [patch attached]
On Sun, 06 Jan 2019 20:52:44 +0100 Georges Khaznadar wrote: > > lyx --export latex someFile.lyx outputs loads of errors, with this pattern: > > Traceback (most recent call last): > File "/usr/share/lyx/scripts/convertDefault.py", line 38, in > output = output.decode() > AttributeError: 'str' object has no attribute 'decode' This should be fixed since lyx 2.3.3. Pavel
Bug#816173: [Pkg-lyx-devel] Bug#816173: Bug#816173: lyx: Lyx failed to start if the $HOME/.lyx does not exist
On Tue, 1 Mar 2016 10:40:49 +0100 Sven Hoexter wrote: > If not abort with an error message pointing > to the -userdir option. I think using the -userdir option is also the > way to go if you use lyx during build time in minimal build environments > like sbuild chroots. Agreed. I added hint for -userdir option in the error message. This will be fixed with lyx 2.4. Pavel
Bug#758875: Still wrongly named/typo
On Wed, 18 Mar 2015 12:28:30 +0100 Alexander Stiebing wrote: > The problem reported as "first" (and as "moreover"): > Confirmed that the menu entry is wrongly given in 'it/splash.lyx', but > it should by now be called 'Documento>Mostra (altri formati)>DVI', not > like the proposed string out of the bug report Reportedly this is fixed in 2.3. > > The problem reported as "third": > the reported typo is still in 'it/splash.lyx' This has been fixed now and will be part of lyx 2.3.7 & 2.4. Pavel
Bug#879602: [lyx] Broken svn auto-detecion
On Mon, 23 Oct 2017 12:14:41 +0200 Philipp Klaus Krause wrote: > lyx tries to autodetect if a file is under verison control. When lyx > 2.2.3 reads an input file, it recursively checks parent directories for > .svn, .git, etc. > > In case it find a .svn directory, it invokes svn info to parse the > output to see if the file is under version control. For svn, the code is > in SVN::findFile in lines 1154ff of src/VCBackend.cpp. > > However, there is a bug in checking if a file is in svn. If the file is > in a directory that is not under svn, but a parent directory is under > svn, lyx will invoke svn info. Since the directory itself is not under > svn, svn info will fail "svn: E155007: > '/home/philipp/sdcc-2/build/doc/sdccman.lyx' is not a working copy"; lyx > considers this an error. Looks like correct analysis. > This issue makes out-of-tree builds fail. Example: the sdcc manual is a > .lyx file. When checking out sdcc from svn, and then trying to do an > out-of-tree build in a directory build, it fails due to this bug. Despite the warning from svn info, lyx normally loads up the file, exports it etc. So I do not follow what "out-of-tree builds fail" exactly means or what kind of problem you actually encounter. Pavel
Bug#457232: [Pkg-lyx-devel] Bug#457232: lyx: Fails to fully parse document for display.
On Thu, 20 Dec 2007 23:06:26 +0100 Sven Hoexter wrote: > forwarded 457232 http://bugzilla.lyx.org/show_bug.cgi?id=449 > tags 457232 upstream > thanks > > Hi Nick, > it doesn't look like it's easy to fix. The problem is already reported > upstream so I'd suggest you read the comments on the report upstream > to maybe find a solution that fits your needs. > http://bugzilla.lyx.org/show_bug.cgi?id=449 Should be fixed in lyx 2.4.0. Pavel
Bug#786698: lyx: No mandatory rcs check-in before closing Lyx
On Sun, 24 May 2015 16:03:54 +0200 Martin Haase wrote: > I just realized that it is possible to exit from the program without > prior checking in the changes to a document. I find this rather peculiar, > and I don't think it should happen this way. Lyx should keep "in mind" > whether a document has been registered with rcs and change its exit > behaviour accordingly. I don't find it peculiar, but YMMV. In any case this is wishlist and unlikely to be solved on Debian BTS. Filing bug at LyX bugtracker might help thought I don't see it likely. Pavel
Bug#362052: [t...@lyx.org: Re: #4370: Please implement a check-in and re-checkout in one step menu item]
On Tue, 2 Nov 2010 20:59:57 +0100 Sven Hoexter wrote: > Status update ... The second reported issue is fixed since lyx 1.6, the first one is wontfix for 12 years already. As such I would close this bug. Pavel
Bug#730111: Still present in 2.1.3-1
On Wed, 18 Mar 2015 12:28:48 +0100 Alexander Stiebing wrote: > Bug still like described in Nov. 2013, none of the proposed actions out > of the comments have been done. The change of the message to be more informative will be fixed in lyx 2.3.7 & 2.4. https://www.lyx.org/trac/changeset/b670990bc12fe1dd1d9d7b5fa8258a32caa7e91a/lyxgit Moving RCS from suggested to Recommends look reasonable to me. After that the bug can be closed. Pavel
Bug#597676: Export options vanish every other time
On Wed, 6 Oct 2010 11:55:24 +1000 Brendon Higgins wrote: > (Original reporter here.) I just tried with a clean ~/.lyx, and things seem > to > behave themselves. So there's something in my .lyx that lyx does not like. It > turns out that it's certainly my preferences file. I narrowed it down after > comparing the two folders recursively and moving things to the clean .lyx one > by one. > > I had a look at the settings for these formats, and noticed that "Document > Format" is not ticked for them. If I change that for, say, "PDF (pdflatex)" > so > that it is ticked, then that particular option shows up in the Export menu > all > the time, as you ought to expect. > > Before anyone shouts PEBKAC, while I did change the viewer application option > (as you can tell), I don't believe I would have been silly enough to change > that tick mark. I reckon, somehow, that property must have been either > unchecked or not set by default properly when this property was introduced in > an earlier version. (I've been using lyx on this machine since 2006, and > would > have had similar settings, using kghostview rather than okular.) There are two ways how this could have happened 1) either user somehow unknowingly deselected that option or played manually with the preferences file 2) something weird happened while lyx converted the pref file from lyx 1.5 -> lyx 1.6. Anyway even if 2) is true (and I dont remember similar problem reports) we are today at >= 2.1 versions where ->1.6 conversions are irrelevant. As such we can close this bug. Pavel
Bug#524332: lyx: No toolbox in LyX's window
On Thu, 16 Apr 2009 12:18:09 +0200 Renaud Lacour wrote: > LyX's toolboxes are hidden and can't be displayed by the related menu > items. I can see a small piece of one toolbox on startup, which most > part seems to be hidden behind the menu bar. After loading a document, > there is no toolbox at all. > Clearing .lyx directory didn't help. It happened recently and *may* be > related to xorg's recent upgrade. This problem appears if Qt settings in .config/LyX/ get corrupted for whatever reason. There is very little you can do to programatically restore such corrupted files expcept manually delete them. I think this bug should be closed as wontfix. Pavel
Bug#507045: [Pkg-lyx-devel] Bug#507045: lyx: Several standard document classes not available
On Thu, 27 Nov 2008 20:49:51 -0800 "Marc J. Driftmeyer" wrote: > Better yet, provide a help document declaring the missing styles and > classes that aren't available under Debian; and then reference how to > install them locally to add those classes that don't comply with > Debian's strict licensing policy. That way it allows folks unfamiliar > with /usr/local/share/texmf/ how that works with the Debian mktexlsr > approach to updating local and global classes. I believe this is daunting task. Templates can (dis)appear even across minor lyx versions and tracking all this would be very time consuming and would have minor impact except of few niche users. In a decade no one volunteer to maintain such document and I don't see this will change. Non-debian specific document showing you which lyx related classes were detected on your system is always to be found in Help->LaTeX Configuration. The report 45 is a different bug already solved by clean up the cache. All in all I think this bug should be closed. Pavel
Bug#858535: lyx: Does not display ooint symbol
On Thu, 23 Mar 2017 08:44:47 +0100 "g.gragnani" wrote: > at my site the math symbol \oiint is no longer displayed when using the > math editor. Is is however inserted in the tex source code, but not > seeing it makes the program prone to typing errors. This is known bug, which I fixed for LyX 2.4, cf https://www.lyx.org/trac/ticket/8493 Pavel
Bug#911236: LyX: Error converting images
On Wed, 17 Oct 2018 15:44:23 +0200 Adrian Immanuel Kiess wrote: >* What exactly did you do (or not do) that was effective (or > ineffective)? > apt-get -u dist-upgrade >* What was the outcome of this action? > LyX has problems converting images This could be consequence of strict imagemagick policies, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975678 Does allowing pdf coders in /etc/ImageMagick-6/policy.xml helps your situation? Pavel
Bug#831839: Your mail
On Thu, 28 Dec 2017 13:02:44 +0100 Jean-Marc Lasgouttes wrote: > Is the situation better with LyX 2.2.3? There have been some changes in > to improve performance. Meantime there were multiple performance fixes committed and since we did not receive any feedback from the reporter I would close this bug. Pavel
Bug#975678: lyx: Strict imagemagick policies render LyX unusable when working with vector graphics
Package: lyx Version: 2.3.2-1 Severity: important Dear package maintainer(s), we (LyX developers) are getting repeated reports of LyX's broken handling of pdf/postscript graphics rendering (LaTeX export works fine). This is because of debian stringent policy in /etc/ImageMagick-6/policy.xml disabling ghostscript handling. This was likely introduced due to ghostcript vulnerabilities couple years back, which are fixed now, but the fear of new potential vulnerabilities probably caused the ongoing ban of ghostcript. While I understand the possible security implications on servers, the current policy renders LyX unusable for anyone on desktop, who wishes to use eps/pdf vector graphics, which is typical graphics input format in LaTeX world. On top of this, if user is not root as well, he can't even override these policies. This puts us in a weird position, that we can't help some users even when we detect why their documents do not compile anymore. Would you be willing to make some compromise on systems where users install LyX? I can imagine different ways, e.g.: - allow eps/pdf coders when LyX is installed - ask user when installing LyX whether he wants to to allow such coders - or at least issue warning that unless admin tweaks policy.xml LyX won't function properly. Or any other approach which would help to solve this issue. I see that the imagemagick policy patch in question is in buster but not in bullseye. Not sure whether it means debian wants to keep future imagemagick policies in their vanilla form or it was moved to debconf. In any case I would like raise our voice about this problem explicitely. While this bug is sort of generalized version of #971630 (we also want eps format to work) and might not be high priority from imagemagick POV (could be considered a corner case), I file this under LyX as the consequences are way more serious for its functionality. Thanks, Pavel -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-12-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=en_US.UTF-8 (charmap=ISO-8859-2) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lyx depends on: ii libc62.28-10 ii libenchant1c2a 1.6.0-11.1+b1 ii libgcc1 1:8.3.0-6 ii libmagic11:5.35-4+deb10u1 ii libmythes-1.2-0 2:1.2.4-3 ii libqt5core5a 5.11.3+dfsg1-1+deb10u4 ii libqt5gui5 5.11.3+dfsg1-1+deb10u4 ii libqt5svg5 5.11.3-2 ii libqt5widgets5 5.11.3+dfsg1-1+deb10u4 ii libstdc++6 8.3.0-6 ii lyx-common 2.3.2-1 ii xdg-utils1.1.3-1+deb10u1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages lyx recommends: ii dvipng 1.15-1.1 ii evince [pdf-viewer] 3.30.2-3+deb10u1 ii fonts-lyx2.3.2-1 ii ghostscript 9.27~dfsg-2+deb10u4 ii gv [pdf-viewer] 1:3.7.4-2 ii imagemagick 8:6.9.10.23+dfsg-2.1+deb10u1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+deb10u1 ii poppler-utils0.71.0-5 ii preview-latex-style 11.91-2 ii psutils 1.17.dfsg-4 ii texlive-fonts-recommended2018.20190227-2 ii texlive-generic-extra2018.20190227-2 ii texlive-generic-recommended 2018.20190227-2 ii texlive-latex-extra 2018.20190227-2 ii texlive-latex-recommended2018.20190227-2 ii texlive-science 2018.20190227-2 ii xpdf [pdf-viewer]3.04-13 Versions of packages lyx suggests: pn chktex pn gnuhtml2latex pn groff ii inkscape0.92.4-3 pn latex2rtf ii librsvg2-bin2.44.10-2.1 pn libtiff-tools pn linuxdoc-tools pn noweb ii rcs 5.9.4-5 pn sgmltools-lite ii texlive-plain-generic [tex4ht] 2018.20190227-2 pn texlive-xetex pn writer2latex pn wv -- no debconf information
Bug#960631: php-common: forces removal of previous PHP versions
06.10.2020 20:48, Ondřej Surý пишет: Hi, On Fri, 2 Oct 2020 at 16:18, Pavel <mailto:pavel2...@ngs.ru>> wrote: >Well, yes, that’s intentional. See the changelog for 76 version for the background. I read #911832 for the background. Can you please explain a bit, how autopkgtests and force removal of previous PHP versions are related? Solution to force removal of previous PHP versions looks hasty. I clearly understand that better solution requires more time, however. But maybe it is still possible to find another/better solution? No, I already spent hours on this. If that is possible to do without spending too much your time, can you please describe a sequence how autopkgtests works and why/how they fail, to reproduce that behaviour locally? In form like short guide: 1) Create Debian env from "testing"(?) repo 2) Install xxx packages from "testing"(?) 2) Install/update xxx packages from "unstable"(?) 3) Run... ? ... and get broken tests result Thanks. Yes, then you need to use php-common from the personal repositories, not from Debian. Thanks, that is acceptable solution, at least because we need to build custom pecl extensions packages anyway. Hope there will be no other changes which forbids other parts of this puzzle. Thanks for your work.
Bug#960631: php-common: forces removal of previous PHP versions
>Well, yes, that’s intentional. See the changelog for 76 version for the background. I read #911832 for the background. Can you please explain a bit, how autopkgtests and force removal of previous PHP versions are related? Solution to force removal of previous PHP versions looks hasty. I clearly understand that better solution requires more time, however. But maybe it is still possible to find another/better solution? >Besides there has been always only one supported PHP version per Debian release. In fact it is not. Thanks to your personal efforts, we [was] able to easily install several PHP versions in same environment: 1) Package naming scheme was changed to include minor version in package names (e.g php5-common -> php7.1-common), that was a step to allow several versions in same installation. 2) PHP interpreter version is choosed using 'update-alternatives' mechanism. 3) We are able to build binary packages of PECL extensions, which will support (provide binaries) for several PHP versions at once. Inside of this process the `phpquery` tool from this 'php-defaults' package is used too. All these confirms what use of several PHP versions was permitted.The `php-common-76` is the only thing which now forbids installation of several PHP versions in same environment. The change you did in version 76 is a regression. It will be quite unfortunate if that version will pass to stable. I hope to draw your attention to this problem again and find another solution. As I need to use several PHP versions in one environment, I'm able to build my own version of 'php-common' with removed 'Breaks' lines, to allow packages to be installed like it was before. Unfortunately, I'm not familar with php packaging and autotests process, to provide my own solution, but I ready to work on this issue to help you/with your help and instructions. Thanks for your work on Debian.
Bug#925561: xfce4-weather-plugin patch
Hello
I have made a patch to fix weather updates in current version in
xfce4-weather-plugin
--- xfce4-weather-plugin-0.8.10.orig/panel-plugin/weather.c
+++ xfce4-weather-plugin-0.8.10/panel-plugin/weather.c
@@ -619,17 +619,14 @@ update_handler(plugin_data *data)
end_tm = *localtime(_t);
/* build url */
-url = g_strdup_printf("https://api.met.no/weatherapi/sunrise/1.1/?;
+url = g_strdup_printf("https://api.met.no/weatherapi/sunrise/2.0/?;
"lat=%s;lon=%s;"
- "from=%04d-%02d-%02d;"
- "to=%04d-%02d-%02d",
+ "date=%04d-%02d-%02d;"
+ "offset=00:00",
data->lat, data->lon,
now_tm.tm_year + 1900,
- now_tm.tm_mon + 1,
- now_tm.tm_mday,
- end_tm.tm_year + 1900,
- end_tm.tm_mon + 1,
- end_tm.tm_mday);
+ now_tm.tm_mon + 1,
+ now_tm.tm_mday);
/* start receive thread */
g_message(_("getting %s"), url);
@@ -647,8 +644,8 @@ update_handler(plugin_data *data)
/* build url */
url =
g_strdup_printf("https://api.met.no/weatherapi;
-"/locationforecastlts/1.3/?lat=%s;lon=%s;msl=%d",
-data->lat, data->lon, data->msl);
+"/locationforecast/2.0/classic?lat=%s;lon=%s",
+data->lat, data->lon);
/* start receive thread */
g_message(_("getting %s"), url);
Bug#970259: Weather API update
Hello, I've fixed the plugin by bumping weather API version to 2.0
Patch is attached
--- xfce4-weather-plugin-0.8.10.orig/panel-plugin/weather.c
+++ xfce4-weather-plugin-0.8.10/panel-plugin/weather.c
@@ -619,17 +619,14 @@ update_handler(plugin_data *data)
end_tm = *localtime(_t);
/* build url */
-url = g_strdup_printf("https://api.met.no/weatherapi/sunrise/1.1/?;
+url = g_strdup_printf("https://api.met.no/weatherapi/sunrise/2.0/?;
"lat=%s;lon=%s;"
- "from=%04d-%02d-%02d;"
- "to=%04d-%02d-%02d",
+ "date=%04d-%02d-%02d;"
+ "offset=00:00",
data->lat, data->lon,
now_tm.tm_year + 1900,
- now_tm.tm_mon + 1,
- now_tm.tm_mday,
- end_tm.tm_year + 1900,
- end_tm.tm_mon + 1,
- end_tm.tm_mday);
+ now_tm.tm_mon + 1,
+ now_tm.tm_mday);
/* start receive thread */
g_message(_("getting %s"), url);
@@ -647,8 +644,8 @@ update_handler(plugin_data *data)
/* build url */
url =
g_strdup_printf("https://api.met.no/weatherapi;
-"/locationforecastlts/1.3/?lat=%s;lon=%s;msl=%d",
-data->lat, data->lon, data->msl);
+"/locationforecast/2.0/classic?lat=%s;lon=%s",
+data->lat, data->lon);
/* start receive thread */
g_message(_("getting %s"), url);
Bug#969909: xmoto-data: Broken links to DejaVu fonts
Package: xmoto-data Version: 0.6.1+repack-2 Severity: serious Justification: 4 Dear Maintainer, the links to DejaVu fonts are pointing to non-existent locations: /usr/share/games/xmoto/Textures/Fonts/DejaVuSans.ttf -> ../../../../fonts/truetype/ttf-dejavu/DejaVuSans.ttf /usr/share/games/xmoto/Textures/Fonts/DejaVuSansMono.ttf -> ../../../../fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf The correction locations are: ../../../../fonts/truetype/dejavu/DejaVuSans.ttf ../../../../fonts/truetype/dejavu/DejaVuSansMono.ttf (most likely connected with transition from ttf-dejavu-core to fonts-dejavu-core). Best reagards, Pavel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (840, 'testing'), (740, 'unstable'), (738, 'experimental'), (540, 'proposed-updates'), (540, 'stable'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xmoto-data depends on: ii fonts-arphic-bkai00mp 2.10-21 ii fonts-dejavu-core 2.37-2 xmoto-data recommends no packages. Versions of packages xmoto-data suggests: ii xmoto 0.6.1+repack-2 -- no debconf information
Bug#969784: cups: Cups fails to bind to a network ip address after system reboot
Package: cups Version: 2.2.10-6+deb10u3 Severity: important Dear Maintainer, Cups fails to bind to a network ip address after system reboot with error "Unable to open listen socket for address XXX.XXX.XXX.XXX:631 - Cannot assign requested address." If the services restarted manually after reboot is works as usual. Similar issues was reported to redhat while ago https://bugzilla.redhat.com/show_bug.cgi?id=970809 . To workaround the issues I added "After=network.target" to cups.service. With the dependency set it works with no problem. I suggest to add this dependency by default. -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups depends on: ii cups-client2.2.10-6+deb10u3 ii cups-common2.2.10-6+deb10u3 ii cups-core-drivers 2.2.10-6+deb10u3 ii cups-daemon2.2.10-6+deb10u3 ii cups-filters 1.21.6-5 ii cups-ppdc 2.2.10-6+deb10u3 ii cups-server-common 2.2.10-6+deb10u3 ii debconf [debconf-2.0] 1.5.71 ii ghostscript9.27~dfsg-2+deb10u4 ii libavahi-client3 0.7-4+b1 ii libavahi-common3 0.7-4+b1 ii libc6 2.28-10 ii libcups2 2.2.10-6+deb10u3 ii libcupsimage2 2.2.10-6+deb10u3 ii libgcc11:8.3.0-6 ii libstdc++6 8.3.0-6 ii libusb-1.0-0 2:1.0.22-2 ii poppler-utils 0.71.0-5 ii procps 2:3.3.15-2 Versions of packages cups recommends: ii avahi-daemon 0.7-4+b1 ii colord 1.4.3-4 ii cups-filters [ghostscript-cups] 1.21.6-5 ii printer-driver-gutenprint5.3.1-7 Versions of packages cups suggests: ii cups-bsd 2.2.10-6+deb10u3 pn cups-pdf ii foomatic-db-compressed-ppds [foomatic-db] 20181217-2 ii hplip 3.18.12+dfsg0-2 ii printer-driver-hpcups 3.18.12+dfsg0-2 pn smbclient ii udev 241-7~deb10u4 -- debconf information: cupsys/backend: lpd, socket, usb, snmp, dnssd cupsys/raw-print: true
Bug#964364: evolution-ews: E-mail sent via EWS replaces the recipient's name with a copy of their e-mail address.
Package: evolution-ews Version: 3.36.3-1 Severity: important Dear Maintainer, Since about a month ago, when I send an e-mail via my employer's Office365 setup using Evolution's EWS support, I find that the message that is placed into the Sent folder has the correct recipient names, but the message that is actually sent appears to replace the recipient's name with their e-mail address. For example, In composer: To: John Smith In Sent folder: To: John Smith Actually received: To: john.sm...@example.com I have attempted to isolate the problem by sending messages to myself. To summarise, I find that the name is preserved if *any* of the following situations: * Sending through the Office365 web Outlook (the webmail interface). * Sending from Evolution through Office356's SMTP interface (smtp.office365.com). * The recipient is within the employer's domain (e.g., if my domain is example.biz, then John Smith -> preserved John Smith -> jon.sm...@example.net ) It is only when sending to a recipient outside the employer's domain using Evolution's EWS that the problem occurs. For messages with multiple heterogeneous recipients, those in the domain have their names preserved, those outside rewritten. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evolution-ews depends on: ii evolution3.36.3-1 ii evolution-data-server3.36.3-1 ii libc62.31-0experimental0 ii libcamel-1.2-62 3.36.3-1 ii libebackend-1.2-10 3.36.3-1 ii libebook-1.2-20 3.36.3-1 ii libebook-contacts-1.2-3 3.36.3-1 ii libecal-2.0-13.36.3-1 ii libedata-book-1.2-26 3.36.3-1 ii libedata-cal-2.0-1 3.36.3-1 ii libedataserver-1.2-243.36.3-1 ii libedataserverui-1.2-2 3.36.3-1 ii libevolution 3.36.3-1 ii libglib2.0-0 2.64.3-2 ii libgtk-3-0 3.24.20-1 ii libical3 3.0.8-1+b1 ii libmspack0 0.10.1-2 ii libpango-1.0-0 1.44.7-4 ii libsoup2.4-1 2.70.0-1 ii libxml2 2.9.10+dfsg-5+b1 evolution-ews recommends no packages. evolution-ews suggests no packages. -- no debconf information
Bug#954780: Duplicate: almost identical content already shipped with vim-runtime
Package: vim-asciidoc Version: 8.6.10-3 Severity: minor Dear Maintainer, the effective contents of this package - the syntax file asciidoc.vim - is already shipped with vim-runtime. The files differ by just 4 lines, and the vim-runtime version seems newer. Therefore I think that this package is redundant and it can confuse users of vim and asciidoc. Please consider removing the package. Best regards, Pavel Krc -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages vim-asciidoc depends on: ii vim-addon-manager 0.5.10 vim-asciidoc recommends no packages. Versions of packages vim-asciidoc suggests: pn asciidoc-base
Bug#949369: i915: kernel crash in i915_active_acquire()
Source: linux Followup-For: Bug #949369 Dear Maintainer, I experienced the same crash after upgrading to kernel series 5.4.x (namely to 5.4.8) in mid of January. The crashes of the system were quite frequent (every few hours, making the system unusable). After few experiments I ended up with the linux kernel 5.5.0-rc5 from unstable, which seems to work relativelly well. However, today I got the same crash already twice, despite more than month of using it. There are numer of reports about the problems related to the i915 driver in the 5.3.x-5.5.x kernel series: https://bbs.archlinux.org/viewtopic.php?id=250765=7 https://linuxreviews.org/Linux_Kernel_5.5_Will_Not_Fix_The_Frequent_Intel_GPU_Hangs_In_Recent_Kernels https://forum.manjaro.org/t/random-freezing-with-resetting-rcs0-for-hang-on-rcs0/119313/29 https://www.phoronix.com/scan.php?page=news_item=Linux-5.5-Intel-Missed-Graphics Kernels 4.19.x in buster seems to be fine. Pavel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (840, 'testing'), (740, 'unstable'), (738, 'experimental'), (540, 'proposed-updates'), (540, 'stable'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-rc5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#949573: rsync systemd unit ignore default file
Package: rsync Version: 3.1.3-6 The rsync daemon starting via systemd unit including in the package ignore variables in file /etc/default/rsync. Could you fix this issue by adding EnvironmentFile into Service part of systemd unit? EnvironmentFile=-/etc/default/rsync Thx Pavel Raus
Bug#946058: pdfchain: Change dependence from pdftk to pdftk-java
Package: pdfchain Version: 1:0.4.4.2-1 Severity: minor Dear Maintainer, would it be possible to change the dependence on pdftk (now transitional) to pdftk-java ? Thanks, Pavel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (840, 'testing'), (740, 'unstable'), (738, 'experimental'), (540, 'proposed-updates'), (540, 'stable'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pdfchain depends on: ii libatkmm-1.6-1v52.28.0-2 ii libc6 2.29-3 ii libgcc1 1:9.2.1-19 ii libglibmm-2.4-1v5 2.62.0-1 ii libgtkmm-3.0-1v53.24.2-1 ii libsigc++-2.0-0v5 2.10.2-1 ii libstdc++6 9.2.1-19 ii pdftk 2.02-5+b1 ii pdftk-java [pdftk] 3.0.6-1 pdfchain recommends no packages. pdfchain suggests no packages. -- no debconf information
Bug#946057: xmoto-data: Replace dependence on ttf-dejavu-core by fonts-dejavu-core
Package: xmoto-data Version: 0.5.11+dfsg-8 Severity: minor Dear Maintainer, would it be possible to replace the dependence on the obsolete ttf-dejavu-core package by the new fonts-dejavu-core package ? Thanks, Pavel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (840, 'testing'), (740, 'unstable'), (738, 'experimental'), (540, 'proposed-updates'), (540, 'stable'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xmoto-data depends on: ii ttf-dejavu-core 2.37-1 xmoto-data recommends no packages. Versions of packages xmoto-data suggests: ii xmoto 0.5.11+dfsg-8+b1 -- no debconf information
Bug#943472: launchy: Rename icons cache folder to .weby-icon-cache or similar
Package: launchy Version: 2.5-4 Severity: wishlist Dear Maintainer, would it be possible to patch the package so that the application is storing its icons cache into a hidden directory, instead of ~/weby-icon-cache ? It is a bit distracting when such an obviously temp direcotry is always being recreated in my home dir. The patch should be trivial: just change launchy-2.5/plugins/weby/weby.cpp at line 95, e.g. to ~/.weby-icon-cache. Thank you, Pavel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (840, 'testing'), (740, 'unstable'), (738, 'experimental'), (540, 'proposed-updates'), (540, 'stable'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages launchy depends on: ii libc6 2.29-2 ii libgcc1 1:9.2.1-8 ii libqt4-network 4:4.8.7+dfsg-19 ii libqtcore4 4:4.8.7+dfsg-19 ii libqtgui4 4:4.8.7+dfsg-19 ii libstdc++6 9.2.1-8 ii libx11-62:1.6.8-1 launchy recommends no packages. Versions of packages launchy suggests: ii launchy-plugins 2.5-4 ii launchy-skins2.5-4 -- no debconf information
Bug#942492: netdata: build with SSL support (libssl-dev build requirement)
Package: netdata Version: 1.17.1-1 The affected 'netdata' package is built without SSL support. This results in inability to establish TLS connections to, for instance, master nodes using URLs like: example.com:1:SSL The suggested fix is to add libssl-dev as a build requirement.
Bug#942311: hostname ALL_FQDN size limited to 255 bytes
Package: hostname Version: 3.22 Size of buffer (buf) for all FQDN's is limited to 255 octets thus maximum size of getnameinfo() output is 254 octets + '\0' while RFC [1] specifies it to be 255 octets. Easiest fix would be to increase buffer size to 256 but getnameinfo(3) suggests to use char buf[NI_MAXHOST]; instead. [1] - https://tools.ietf.org/html/rfc1035#section-2.3.4
Bug#942128: installation-guide-amd64: security apt resource
Package: installation-guide-amd64 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? In installation of debian 10, testing, there is bad entry to /etc/apt/sources.list - installation procedure reports error when trying contact old security repository (up to 9). The instalation procedure should use the new one: deb http://security.debian.org testing-security main contrib non-free deb-src http://security.debian.org testing-security main contrib non-free Thank you. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#939558: System powers off or crashes when asking "suspend to ram" via GUI
Package: linux-image Version: 4.19.0-5-amd64 When I suspend my Lenovo x240 laptop via xfce UI, the screen goes dark as if it goes to sleep, but the power button LED doesn't start to "blink" as it normally does, it just turns of. If I close and open the lid to wake it up, it doesn't. Pressing the power button (a short press, which ... shouldn't power down it) turns on the laptop and the normal boot process starts. Here's what I have in /var/log/messages around that time: Sep 6 00:51:44 xemulnb NetworkManager[660]: [1567720304.3207] manager: sleep: sleep requested (sleeping: no enabled: yes) Sep 6 00:51:44 xemulnb NetworkManager[660]: [1567720304.3209] manager: NetworkManager state is now ASLEEP ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@Sep 6 10:48:50 xemulnb kernel: [0.00] Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) Sep 6 10:48:50 xemulnb kernel: [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 root=/dev/mapper/xemulnb--vg-root ro quiet Here's the /var/log/syslog contents: Sep 6 00:51:44 xemulnb NetworkManager[660]: [1567720304.3207] manager: sleep: sleep requested (sleeping: no enabled: yes) Sep 6 00:51:44 xemulnb NetworkManager[660]: [1567720304.3209] manager: NetworkManager state is now ASLEEP Sep 6 00:51:44 xemulnb systemd[1]: Reached target Sleep. Sep 6 00:51:44 xemulnb systemd[1]: Starting Suspend... ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@Sep 6 10:48:50 xemulnb kernel: [0.00] Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) -- Pavel
Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster
Sorry for late answer. On 17. 08. 19 22:18, Florian Weimer wrote: * Pavel Matěja: The strange means they appear only on 2 servers out of 6. Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon E3-1220 v6 produced crashes. It did not matter if the host Debian was Stretch or Buster. Do you see crashes on stretch as well? What does the backtrace look like there? I newer saw the SEGFAULT when we had Stretch based chroot. I had just one SEGFAULT on Stretch host but I didn't collect coredumps back then. Unfortunately the server is already running Buster. Since the bug is caused by new libc in chroot I should be able to install just kernel from Stretch and wait for the SEGFAULT, right? I think the backtrace will be the same anyway. SSLv3 and TLS code path looked quite distinct to cause the same problem. Based on info that SEGFAULTs are related to memory allocation in new libc and CPU performance I found http://51.15.138.76/patch/17499/ where Wilco Dijkstra discuss some problems with tcache which "leads to various crashes in benchtests" I was under the impression that this problem only occurs if one of the tunables has an out-of-bounds value. Do you set any tunables? No, I didn't even know they existed. I did not read the libc sources yet so I don't know what does the patch actually fixes neither if it helps with my problem. Pavel Matěja
Bug#933959: xfce4-panel: Option to configure panel placement on external monitor only
Hi Yves-Alexis, > I'm not sure I understand the use case here, can you be a little bit more > specific? Sure, sorry for not writing that clearly from the beginning. The use case is when one often switches between a "laptop-only" mode (typically at home) and a dual-display mode (at work, using both the laptop screen and the external monitor). The panel should behave like this: - - when there is an external display, the panel should be shown on the external display - - when there is no external display plugged, the panel should not be shown at all I.e. the wish is to have panel that appears on any external monitor, but never on the laptop screen. Xfce4 has an "automatic" panel placement option, but that settings shows the panel on the primary laptop screen when there is no external display. Moreover, in the recent past Xfce4 used to distinguish between how to external monitor is connected (video ports on laptop, connection from docking station). As a result, one would have to reconfigure the panel every time a different connection to the external monitor was used. The patch is written in a way it does not care how the external monitor is connected/named, but simply put it on whenever there is *any* external monitor present. Best regards, Pavel
Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster
Package: glibc Version: 2.28-10:amd64 Dear Maintainer, We are running manually compiled Apache and OpenSSL on Debian servers in Debian-based chroots. After chroot upgrade from Stretch to Buster we started to see strange SEGFAULTs. The strange means they appear only on 2 servers out of 6. Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon E3-1220 v6 produced crashes. It did not matter if the host Debian was Stretch or Buster. I was able to collect coredumps and get backtraces. They look like: (gdb) bt #0 tcache_get (tc_idx=0) at malloc.c:2934 #1 __GI___libc_malloc (bytes=3) at malloc.c:3042 #2 0x7fd8cc0961be in CRYPTO_malloc (num=3, file=0x7fd8cc2a548c "ssl/statem/extensions_clnt.c", line=1376) at crypto/mem.c:222 #3 0x7fd8cc26c7b9 in tls_parse_stoc_ec_pt_formats (s=0x7fd8640592d0, pkt=0x7fd864061810, context=256, x=0x0, chainidx=0) at ssl/statem/extensions_clnt.c:1376 #4 0x7fd8cc266af5 in tls_parse_extension (s=0x7fd8640592d0, idx=TLSEXT_IDX_ec_point_formats, context=256, exts=0x7fd864061770, x=0x0, chainidx=0) at ssl/statem/extensions.c:715 #5 0x7fd8cc266bbb in tls_parse_all_extensions (s=0x7fd8640592d0, context=256, exts=0x7fd864061770, x=0x0, chainidx=0, fin=1) at ssl/statem/extensions.c:748 #6 0x7fd8cc2798b6 in tls_process_server_hello (s=0x7fd8640592d0, pkt=0x7fd83cff8440) at ssl/statem/statem_clnt.c:1698 #7 0x7fd8cc277fc7 in ossl_statem_client_process_message (s=0x7fd8640592d0, pkt=0x7fd83cff8440) at ssl/statem/statem_clnt.c:1039 #8 0x7fd8cc275499 in read_state_machine (s=0x7fd8640592d0) at ssl/statem/statem.c:636 #9 0x7fd8cc274f15 in state_machine (s=0x7fd8640592d0, server=0) at ssl/statem/statem.c:434 #10 0x7fd8cc274a1b in ossl_statem_connect (s=0x7fd8640592d0) at ssl/statem/statem.c:250 #11 0x7fd8cc25b098 in SSL_do_handshake (s=0x7fd8640592d0) at ssl/ssl_lib.c:3599 #12 0x7fd8cc257199 in SSL_connect (s=0x7fd8640592d0) at ssl/ssl_lib.c:1653 #13 0x7fd8c957c934 in ssl_io_filter_handshake (filter_ctx=0x7fd85809a090) at ssl_engine_io.c:1243 #14 0x7fd8c957deca in ssl_io_filter_output (f=0x7fd85809a0e8, bb=0x7fd85406b8b0) at ssl_engine_io.c:1760 .. (gdb) bt #0 tcache_get (tc_idx=0) at malloc.c:2934 #1 __GI___libc_malloc (bytes=16) at malloc.c:3042 #2 0x7fd8cc0961be in CRYPTO_malloc (num=16, file=0x7fd8cc159913 "crypto/bio/bss_mem.c", line=115) at crypto/mem.c:222 #3 0x7fd8cc0961f1 in CRYPTO_zalloc (num=16, file=0x7fd8cc159913 "crypto/bio/bss_mem.c", line=115) at crypto/mem.c:230 #4 0x7fd8cbf9ca0a in mem_init (bi=0x7fd860044130, flags=0) at crypto/bio/bss_mem.c:115 #5 0x7fd8cbf9cb3d in mem_new (bi=0x7fd860044130) at crypto/bio/bss_mem.c:138 #6 0x7fd8cbf9541a in BIO_new (method=0x7fd8cc204980 ) at crypto/bio/bio_lib.c:94 #7 0x7fd8cc2454a3 in ssl3_init_finished_mac (s=0x7fd8600a7be0) at ssl/s3_enc.c:322 #8 0x7fd8cc281eae in tls_setup_handshake (s=0x7fd8600a7be0) at ssl/statem/statem_lib.c:91 #9 0x7fd8cc274ea2 in state_machine (s=0x7fd8600a7be0, server=0) at ssl/statem/statem.c:419 #10 0x7fd8cc274a1b in ossl_statem_connect (s=0x7fd8600a7be0) at ssl/statem/statem.c:250 #11 0x7fd8cc25b098 in SSL_do_handshake (s=0x7fd8600a7be0) at ssl/ssl_lib.c:3599 #12 0x7fd8cc257199 in SSL_connect (s=0x7fd8600a7be0) at ssl/ssl_lib.c:1653 #13 0x7fd8c957c934 in ssl_io_filter_handshake (filter_ctx=0x7fd8580e8b78) at ssl_engine_io.c:1243 #14 0x7fd8c957deca in ssl_io_filter_output (f=0x7fd8580e8bd0, bb=0x55b212b0d518) at ssl_engine_io.c:1760 .. SSLv3 and TLS code path looked quite distinct to cause the same problem. Based on info that SEGFAULTs are related to memory allocation in new libc and CPU performance I found http://51.15.138.76/patch/17499/ where Wilco Dijkstra discuss some problems with tcache which "leads to various crashes in benchtests" As workaround I tried to export GLIBC_TUNABLES=glibc.malloc.tcache_count=0 in Apache startup script and I saw no SEGFAULT since. I have coredumps but they contain production private keys for Apache which I can't share and to make things even worse they are 1,6GB each. I understand this is heisenbug which you won't be able to reproduce. The CPU model dependency is beyond my comprehension. I'm curious if you are familiar with the new tcache and if you think if the patch in discussion can help. I'll try to build libc6 package with it to confirm final solution but I'm confused by the patch tree so far. -- System Information: Debian Release: Buster Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) x86_64 GNU/Linux diff --git a/malloc/malloc.c b/malloc/malloc.c index 801ba1f499b566e677b763fc84f8ba86f4f7ccd0..4db7283cc27118cd7d39410febf7be8f7633780a 100644 --- a/malloc/malloc.c +++ b/malloc/malloc.c @@ -2915,10 +2915,12 @@ typedef struct tcache_entry time), this is for performance reasons. */ typedef struct
Bug#933959: xfce4-panel: Option to configure panel placement on external monitor only
Package: xfce4-panel
Version: 4.12.2-1
Severity: wishlist
Tags: patch upstream
Dear Maintainer,
The panel "Output" settings does not allow easily to configure option where it
would be placed on any connected external monitor (regardless of name of the
monitor), while not shown on the primary laptop monitor when there is no
external monitor attached. The patch adds and "Non-primary" option to the panel
preferences "Output" list allowing that behaviour.
Similar wish has been described e.g. here:
http://colinrrobinson.com/technology/linux/xfce/automatically-switch-xfce-panel-layout-plugging-monitor/
(there the solution is quite heavy, using Xubuntu tool xfpanel-switch).
Feel free to forward the bug upstream if you would find it useful.
Best regards,
Pavel
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (840, 'testing'), (740, 'unstable'), (738, 'experimental'), (540,
'proposed-updates'), (540, 'stable'), (500, 'oldstable-proposed-updates'),
(500, 'oldoldstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages xfce4-panel depends on:
ii exo-utils0.12.6-1
ii libatk1.0-0 2.32.0-2
ii libc62.28-10
ii libcairo21.16.0-4
ii libdbus-1-3 1.12.16-1
ii libdbus-glib-1-2 0.110-4
ii libexo-1-0 0.12.6-1
ii libfontconfig1 2.13.1-2
ii libfreetype6 2.9.1-4
ii libgarcon-1-00.6.3-1
ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii libglib2.0-0 2.60.6-1
ii libgtk2.0-0 2.24.32-3
ii libice6 2:1.0.9-2
ii libpango-1.0-0 1.42.4-6
ii libpangocairo-1.0-0 1.42.4-6
ii libpangoft2-1.0-01.42.4-6
ii libsm6 2:1.2.3-1
ii libwnck222.30.7-6
ii libx11-6 2:1.6.7-1
ii libxext6 2:1.3.3-1+b2
ii libxfce4ui-1-0 4.12.1-3
ii libxfce4util74.12.1-3
ii libxfconf-0-24.12.1-1+b1
xfce4-panel recommends no packages.
xfce4-panel suggests no packages.
-- no debconf information
--- old/panel/panel-preferences-dialog.c
+++ new/panel/panel-preferences-dialog.c
@@ -506,6 +506,15 @@
output_selected = TRUE;
span_monitors_sensitive = TRUE;
}
+ gtk_list_store_insert_with_values (GTK_LIST_STORE (store), , n++,
+ OUTPUT_NAME, "Non-primary",
+ OUTPUT_TITLE, _("Non-primary"), -1);
+ if (g_strcmp0 (output_name, "Non-primary") == 0)
+{
+ gtk_combo_box_set_active_iter (GTK_COMBO_BOX (object), );
+ output_selected = TRUE;
+ span_monitors_sensitive = TRUE;
+}
if (n_screens > 1)
{
--- old/panel/panel-window.c
+++ new/panel/panel-window.c
@@ -2040,6 +2040,8 @@
}
else
{
+ gint monitor_num_primary = gdk_screen_get_primary_monitor
(screen);
+ gboolean is_non_primary = g_strcmp0 (window->output_name,
"Non-primary") == 0;
/* detect the monitor number by output name */
for (n = 0, monitor_num = -1; n < n_monitors && monitor_num ==
-1; n++)
{
@@ -2065,7 +2067,9 @@
}
/* check if this is the monitor we're looking for */
- if (strcmp (window->output_name, name) == 0)
+ if ( is_non_primary && n != monitor_num_primary)
+monitor_num = n;
+ else if (strcmp (window->output_name, name) == 0)
monitor_num = n;
g_free (name);
Bug#931799: pulsemixer: Update to latest upstream version (1.5.0)
Package: pulsemixer Version: 1.4.0-1 Severity: wishlist Dear Maintainer, would it be possible to update to latest upstream version (1.5.0 as of now) ? It fixes problem of non-unique IDs of pulseaudio sources/sinks. Thanks, Pavel
Bug#930890: [Pkg-electronics-devel] Bug#930890: ghdl: Debian ghdl.wrapper prevents build when GHDL is not already installed.
Hello Jonathan, On Sunday 23 of June 2019 10:52:47 Jonathan McDowell wrote: > On Sat, Jun 22, 2019 at 12:26:36AM +0200, Pavel Pisa wrote: > > Source: ghdl > > Version: 0.36+20190617 > > This is not a version of GHDL from Debian. testing/unstable both have > 0.35+git20181129+dfsg-3. I don't think this is a valid bug against the > Debian package - it seems that you've obtained an updated package from > somewhere else, or have manually updated to a newer release? I have used original Debian package as "debian" directory source to port newer GHDL version for Debian Buster. I am not sure if the problem applies to old version, but solution should work for all versions. I have built older version but on the system where GHDL has already been installed. So I expect that the problem may be there as well. There is complete package with sources from which I have built http://pisa-virt.felk.cvut.cz/repos/apt/debian/pool/main/g/ghdl/ The compiled GHDL seems to run our complex tests of VHDL CTU CAN FD controller project as expected https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core There are still some problems after redesign of some parts, so the rest result is not all PASSED, but there has been no unexpected failure or SIGSEGV of GHDL. GHDL includes next patches to optimize WaveDump in addition https://github.com/mjerabek/ghdl/tree/grt-optimize-wave-dump But ghdl_0.36+20190617-1.debian.tar.xz should apply to any version of GHDL around 0.36 with gnat-8, gcc-8-source, which are default in Buster. Best wishes, Pavel
Bug#930890: ghdl: Debian ghdl.wrapper prevents build when GHDL is not already installed.
Source: ghdl Version: 0.36+20190617 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) When Debianized GHDL package is build it fails with message Error: No installed ghdl backend found. Terminating! in context install -m 755 -p libghdl-0_37_dev.so ../../debian/tmp/usr/lib/ghdl/mcode/ ../../debian/tmp/usr/bin/ghdl --disp-standard --std=87 > ../../debian/tmp/usr/lib/ghdl/mcode/vhdl/src/std/standard.v87 Error: No installed ghdl backend found. Terminating! make[2]: *** [Makefile:131: install] Error 2 make[2]: Leaving directory '/home/user/repo/ghdl/ghdl-git/builddir/mcode' make[1]: *** [debian/rules:140: override_dh_auto_install] Error 2 make[1]: Leaving directory '/home/user/repo/ghdl/ghdl-git' make: *** [debian/rules:54: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 The reason for the problem is the file /debian/ghdl.wrapper which prevents install when there is not already installed some "ghdl" package because it ignores "ghdl-mcode" already redy to be run in "debian/tmp/usr/bin" directory. Extending of file to find executables in the wrapper directory solves the problem #!/bin/sh set -e backend="$GHDL_BACKEND" ghdl_bin_dir="$(cd "$(dirname "$0")" ; pwd)" if [ ! -x "/usr/bin/ghdl-$backend" -a ! -x "$ghdl_bin_dir/ghdl-$backend" ]; then if [ -x "$ghdl_bin_dir/ghdl-mcode" ]; then backend=mcode elif [ -x "$ghdl_bin_dir/ghdl-gcc" ]; then backend=gcc elif [ -x "$ghdl_bin_dir/ghdl-llvm" ]; then backend=llvm elif [ -x /usr/bin/ghdl-mcode ]; then backend=mcode elif [ -x /usr/bin/ghdl-gcc ]; then backend=gcc elif [ -x /usr/bin/ghdl-llvm ]; then backend=llvm else echo >&2 "Error: No installed ghdl backend found. Terminating!" exit 2 fi fi if [ -x "$ghdl_bin_dir/ghdl-$backend" ]; then exec "$ghdl_bin_dir/ghdl-$backend" "$@" else exec "/usr/bin/ghdl-$backend" "$@" fi -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#818471: xserver-xorg-input-synaptics: syndaemon not disabling touch pad
Package: xserver-xorg-input-synaptics
Version: 1.9.1-1
Followup-For: Bug #818471
Dear Maintainer,
I am experiencing similar problem. The core of the issue is that some laptops
have separated touchpad-like driver for the touchpad itself and for the
buttons. As a result, two touchpad devices can be found in xinput -list. In my
case these are:
SYNA3071:00 06CB:82F1 Touchpad
SynPS/2 Synaptics TouchPad
The synclient and syndaemon programs are taking blindly the first touchpad-like
device they find, which is unfortunatelly the generic SynPS/2 one. A possible
dirty workaround is to disable 'psmouse' module, which makes that SynPS/2
touchpad to disappear, but at the same time the buttons next to the touchpad
stop (partly) working.
Attached is a patch to the synclient and syndaemon code, which makes sure the
SynPS/2 device is used only when there is no other touchpad-like device found.
At the same time a new option "-n device" is added so that user can select (by
name) which device is to be used by the synclient and syndaemon programs.
Feel free to alter the patch as/if needed.
Best regards,
Pavel
--- old/tools/synclient.c
+++ new/tools/synclient.c
@@ -30,6 +30,7 @@
#include
#include
+#include
#include
#include
#include
@@ -74,6 +75,8 @@
int prop_offset;/* Offset inside property */
};
+static const char *dev_substring;
+
static struct Parameter params[] = {
{"LeftEdge", PT_INT,0, 1, SYNAPTICS_PROP_EDGES,
32, 0},
{"RightEdge", PT_INT,0, 1, SYNAPTICS_PROP_EDGES,
32, 1},
@@ -245,12 +248,27 @@
return dpy;
}
+static void
+dp_get_device_unwind(Atom ** properties, XDevice ** dev, int error, Display *
dpy, XDeviceInfo * info)
+{
+if ( *properties ) {
+ XFree(*properties);
+ *properties = NULL;
+}
+if ( info ) XFreeDeviceList(info);
+if ( error && (*dev) ) {
+ XCloseDevice(dpy, *dev);
+ *dev = NULL;
+}
+}
+
static XDevice *
dp_get_device(Display * dpy)
{
XDevice *dev = NULL;
XDeviceInfo *info = NULL;
int ndevices = 0;
+int generic_device = -1;
Atom touchpad_type = 0;
Atom synaptics_property = 0;
Atom *properties = NULL;
@@ -267,16 +285,16 @@
if (!dev) {
fprintf(stderr, "Failed to open device '%s'.\n",
info[ndevices].name);
-error = 1;
-goto unwind;
+dp_get_device_unwind(, , error = 1, dpy, NULL);
+continue;
}
properties = XListDeviceProperties(dpy, dev, );
if (!properties || !nprops) {
fprintf(stderr, "No properties on device '%s'.\n",
info[ndevices].name);
-error = 1;
-goto unwind;
+dp_get_device_unwind(, , error = 1, dpy, NULL);
+continue;
}
while (nprops--) {
@@ -286,23 +304,41 @@
if (!nprops) {
fprintf(stderr, "No synaptics properties on device '%s'.\n",
info[ndevices].name);
-error = 1;
-goto unwind;
+dp_get_device_unwind(, , error = 1, dpy, NULL);
+continue;
}
-break; /* Yay, device is suitable */
+fprintf(stderr, "Found device '%s'.\n", info[ndevices].name);
+
+if ( dev_substring != NULL && strlen(dev_substring) > 0 &&
!strstr(info[ndevices].name, dev_substring) ) {
+fprintf(stderr, " - device '%s' not matching requested
name '%s'.\n",
+info[ndevices].name, dev_substring);
+dp_get_device_unwind(, , error = 1, dpy, NULL);
+continue;
+}
+
+if ( !strcmp(info[ndevices].name, "SynPS/2 Synaptics TouchPad") ) {
+fprintf(stderr, " - device '%s' is generic one, searching
for another candidate.\n",
+info[ndevices].name);
+generic_device = ndevices;
+dp_get_device_unwind(, , error = 1, dpy, NULL);
+continue;
+}
+
+fprintf(stderr, "Taking device '%s'.\n", info[ndevices].name);
+error = 0;
+break; /* Yay, device is suitable */
}
}
- unwind:
-XFree(properties);
-XFreeDeviceList(info);
-if (!dev)
-fprintf(stderr, "Unable to find a synaptics device.\n");
-else if (error && dev) {
-XCloseDevice(dpy, dev);
-dev = NULL;
+if ( generic_device != -1 && error && !dev ) {
+ fprintf(stderr, "Reverting back to generic device '%s'.\n",
+ info[generic_devi
Bug#926201: ITP: qtmips -- MIPS CPU simulator for education purposes with pipeline and cache visualization.
Package: wnpp Severity: wishlist Owner: Pavel Pisa * Package name: qtmips Version : 0.6.8 Upstream Author : Pavel Pisa * URL : https://github.com/cvut/QtMips/ * License : GPL Programming Lang: C++ Description : MIPS CPU simulator for education purposes with pipeline and cache visualization. The project has started as diploma theses work of Karel Koci. The complete text of the thesis Graphical CPU Simulator with Cache Visualization is available from the online archive of the Czech Technical University in Prague. https://dspace.cvut.cz/bitstream/handle/10467/76764/F3-DP-2018-Koci-Karel-diploma.pdf The document provides analysis of available alternative simulators, overview of the project architecture and basic usage information. The used MIPS CPU building block diagram, and a pipeline model matches lecture slides prepared by Michal Stepanovsky for the subject Computer Architectures. The course is based on the book Computer Organization and Design, The HW/SW Interface written by professors Paterson and Henessy. Reasons to package - We have not found appropriate tool for teaching of CPU pipeline and cache basis. There are expensive professional tools which work on real CPUs RTL level and many tools to provide approximation computations of the cache performance etc. We have used MipsIt emulator https://www.eit.lth.se/fileadmin/eit/courses/eit090/MipsIt/MipsITEnvRef.html in the past but it is Windows only and dated. SPIM is widely used but it provides no pipeline and extension is almost impossible because it interprets instructions directly. MARS is even better with IDE ideal for education but again its internals are centered about software instructions emulation. QtMips decodes instructions to set of signals which are propagated through pipeline stages similar way as on real hardware. Result is quite low speed with huge graphics overhead but with internal state visualization. On the other hand it is much faster then complete chip with RTL simulation. - The QtMips simulator is used in the course for 350 students now and even other faculty expressed interest to use it. It can be quite useful for many universities and it matches well the classic and widely used book for the subject. - I have led the diploma thesis and I have done substantial enhancements in the past months to make emulator fit needs of our seminaries. I have intent to mantain the package as time allows. The backup person is Karel Koci - initial project author. - Project is already built in Ubuntu launchapd https://launchpad.net/qtmips and Suse Open Build Service https://build.opensuse.org/package/show/home:ppisa/qtmips
Bug#925276: cron: Maximum crontab limit applied needlessly to system crontabs
Hi, We have a server with "big website". It's account has 567 lines, which is >50% of limit. So, 1000 lines is not unreachable in real world. Number of lines: root@web:/var/spool/cron/crontabs# cat website |wc -l 567 Number of tasks: root@web:/var/spool/cron/crontabs# cat website |grep -E "^[\*0-9]" |wc -l 382 Empty lines and comments: root@web:/var/spool/cron/crontabs# cat website |grep -E "^$" |wc -l 92 root@web:/var/spool/cron/crontabs# cat website |grep -E "^#" |wc -l 92 Thanks for your work on Debian packages.
Bug#924180: file-roller: Trims files extracted from iso images
Package: file-roller Version: 3.30.1-2 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? I tried to extract files from ISO images of WinXP and Win7 installation disks. * What was the outcome of this action? Extraction passed without any error. The I have mounted ISO files with "mount -i loop ..." and noticed that total size of files in mounted folder is larger than in extracted. I looked through these folders and noticed that one file that is about 5GB in mounted folder is about 1GB in extracted folder. In case of another image several extracted filed have zero size instead of several KB. So I think the problem is not specific to large files. * What outcome did you expect instead? Extracted image and folder mounted with "mount -i loop ..." should be the same. *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages file-roller depends on: ii bzip21.0.6-9 ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii gconf-gsettings-backend [gsettings-backend] 3.2.6-5 ii libarchive13 3.3.3-3 ii libc62.28-7 ii libcairo21.16.0-2 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libglib2.0-0 2.58.2-4 ii libgtk-3-0 3.24.4-1 ii libjson-glib-1.0-0 1.4.4-2 ii libnautilus-extension1a 3.30.5-1 ii libnotify4 0.7.7-4 ii libpango-1.0-0 1.42.4-6 ii p7zip-full 16.02+dfsg-6 Versions of packages file-roller recommends: ii gvfs 1.38.1-2+b1 pn yelp Versions of packages file-roller suggests: pn arj pn lha pn lzip ii lzop 1.03-4+b1 pn ncompress pn rpm2cpio pn rzip pn sharutils pn squashfs-tools pn unace pn unalz pn unar ii unzip6.0-21 ii xz-utils [lzma] 5.2.4-1 ii zip 3.0-11+b1 pn zoo -- debconf-show failed
Bug#856595:
It looks like all the dependencies are now in Buster, thanks to Kunal. It would be a shame to have it all, except for the actual user-facing app that uses it... Is there any chance that this package might make it into Buster? Is there any assistance I could provide to accelerate the process?
Bug#921883: [921883] emacspeak fails to byte-compile in some case
Correct, vm is installed and /etc/emacs/site-start.d/50vm.el exists. On Sun, Feb 10, 2019 at 6:32 PM Paul Gevers wrote: > Hi Pavel, > > On 10-02-2019 16:51, Pavel Kreuzt wrote: > > I suppose this is for debugging and not a solution, for it keeps > > failing. Attached log file. > > It was, yes. > > I am getting help on IRC from hartmans and bremner on #debian-devel, can > you confirm that you have vm installed and or > /etc/emacs/site-start.d/50vm.el left over? > > Paul > >
Bug#921883:
Actually I have not made any local changes to config files, they are as provided by packages. This is my list of emacs-related installed packages: elpa-restart-emacs 0.1.1-2 all [installed] emacs-bin-common 1:26.1+1-3.2 amd64 [installed,automatic] emacs-common-non-dfsg 1:26.1+1-1 all [installed] emacs-common 1:26.1+1-3.2 all [installed,automatic] emacs-el 1:26.1+1-3.2 all [installed,automatic] emacs-gtk 1:26.1+1-3.2 amd64 [installed,automatic] emacs-intl-fonts 1.2.1-10 all [installed] emacs-jabber 0.8.92+git98dc8e-4 all [installed] emacs 1:26.1+1-3.2 all [installed] emacsen-common 3.0.4 all [installed,automatic] emacspeak-espeak-server 49.0+dfsg-2 amd64 [installed] emacspeak 49.0+dfsg-2 all [installed] maxima-emacs 5.42.1-1 all [installed] xemacs21-basesupport 2009.02.17.dfsg.2-4 all [installed,automatic] xemacs21-bin 21.4.24-7 amd64 [installed,automatic] xemacs21-mule 21.4.24-7 amd64 [installed,automatic] xemacs21-mulesupport 2009.02.17.dfsg.2-4 all [installed,automatic] xemacs21-support 21.4.24-7 all [installed,automatic] xemacs21 21.4.24-7 all [installed]
