Bug#932431: DDPO: package removed from experimental but still shown in DDPO column
control: tags -1 +wontfix On Sun, Sep 27, 2020 at 2:38 PM Paul Wise wrote: > > It seems if a package from experimental has Built-Using on a package in > unstable, then dak pulls the unstable source package into experimental > and adds ESO: yes. I think above perfectly explains why the original issue of the ticket occurs, and it's by design. So I add the "wontfix" tag to this ticket. Thanks! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#971065: korganizer: org.kde.korgac.desktop executable
Package: korganizer Version: 4:20.04.1-2 Severity: minor In the logs I get the following error message: Aug 15 21:46:20 samd systemd[232194]: Configuration file /etc/xdg/autostart/org.kde.korgac.desktop is marked executable. Please remove executable permission bits. Proceeding anyway. And indeed, it is the only executable desktop file in this directory. Please consider removing the executable bit. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages korganizer depends on: ii kdepim-runtime 4:20.04.1-2 ii kio 5.70.1-1 ii libc62.31-3 ii libgcc-s110.2.0-9 ii libkf5akonadicalendar5abi1 [libkf5akonadicalendar5-20.04]4:20.04.1-2 ii libkf5akonadicontact5 [libkf5akonadicontact5-20.04] 4:20.04.1-2 ii libkf5akonadicore5abi2 [libkf5akonadicore5-20.04]4:20.04.1-2+b1 ii libkf5akonadimime5 [libkf5akonadimime5-20.04]4:20.04.1-2 ii libkf5akonadinotes5 [libkf5akonadinotes5-20.04] 4:20.04.1-1 ii libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-20.04] 4:20.04.1-2+b1 ii libkf5calendarcore5abi2 5:5.70.0-2 ii libkf5calendarsupport5abi1 [libkf5calendarsupport5-20.04]4:20.04.1-2 ii libkf5calendarutils5 [libkf5calendarutils5-20.04]4:20.04.1-2 ii libkf5codecs55.70.0-1 ii libkf5completion55.70.0-1 ii libkf5configcore55.70.0-1 ii libkf5configgui5 5.70.0-1 ii libkf5configwidgets5 5.70.0-2 ii libkf5contacts5 5:5.70.0-4 ii libkf5coreaddons55.70.0-2 ii libkf5crash5 5.70.0-1 ii libkf5dbusaddons55.70.0-1 ii libkf5eventviews5abi1 [libkf5eventviews5-20.04] 4:20.04.1-2 ii libkf5holidays5 1:5.70.0-1 ii libkf5i18n5 5.70.0-1 ii libkf5iconthemes55.70.0-1 ii libkf5identitymanagement5 [libkf5identitymanagement5-20.04] 20.04.1-2 ii libkf5incidenceeditor5abi1 [libkf5incidenceeditor5-20.04]20.04.1-1 ii libkf5itemmodels55.70.0-3 ii libkf5itemviews5 5.70.0-1 ii libkf5jobwidgets55.70.0-1 ii libkf5kcmutils5 5.70.0-1 ii libkf5kdepimdbusinterfaces5 [libkf5kdepimdbusinterfaces5-20 4:20.04.1-2 ii libkf5kiocore5 5.70.1-1 ii libkf5kiowidgets55.70.1-1 ii libkf5kontactinterface5 [libkf5kontactinterface5-20.04] 20.04.1-2 ii libkf5libkdepim5 [libkf5libkdepim5-20.04]4:20.04.1-2 ii libkf5libkdepimakonadi5 [libkf5libkdepimakonadi5-20.04] 4:20.04.1-2 ii libkf5mailtransport5 [libkf5mailtransport5-20.04]20.04.1-2 ii libkf5mailtransportakonadi5 [libkf5mailtransportakonadi5-20 20.04.1-2 ii libkf5mime5abi1 [libkf5mime5-20.04] 20.04.1-1 ii libkf5newstuff5 5.70.0-1 ii libkf5notifications5 5.70.0-1 ii libkf5parts5 5.70.0-1 ii libkf5pimcommon5abi2 [libkf5pimcommon5-20.04]4:20.04.1-2 ii libkf5pimcommonakonadi5abi1 [libkf5pimcommonakonadi5-20.04] 4:20.04.1-2 ii libkf5pimtextedit5abi2 [libkf5pimtextedit5-20.04]20.04.1-3 ii libkf5service-bin5.70.0-1 ii libkf5service5 5.70.0-1 ii libkf5widgetsaddons5 5.70.0-1 ii libkf5windowsystem5 5.70.0-1 ii libkf5xmlgui55.70.0-1+b1 ii libphonon4qt5-4 4:4.11.1-3 ii libqt5core5a 5.14.2+dfsg-6 ii libqt5dbus5 5.14.2+dfsg-6
Bug#932431: DDPO: package removed from experimental but still shown in DDPO column
On Sun, 2020-09-27 at 14:27 +0900, Roger Shimizu wrote: > I think this can explain why an old version of package is still in > archive, but still cannot explain why it appears in *experimental* > column in DDPO page. This simply because DDPO just reflects what is in the archive, if you grep the Packages/Sources files from the archive you can confirm this. > I checked one package I mentioned previously: > > $ apt-cache showsrc golang-github-google-go-github | grep -E > '^(Version|Extra-Source-Only|)(:|$)' I see more versions than you for some reason: $ apt-cache showsrc golang-github-google-go-github | grep -E '^(Version|Extra-Source-Only|)(:|$)' Version: 32.1.0-1 Version: 32.1.0-1 Extra-Source-Only: yes Version: 32.1.0-2 Version: 28.1.1-1 Extra-Source-Only: yes > But 28.1.1-1 still appears in my DDPO [2] in experimental column. It also appears in the archive too, in experimental vault:amd64 has Built-Using with that version of golang-github-google-go-github and src:golang-github-google-go-github is present too with ESO: yes. > - golang-github-google-go-github version 28.1.1-1 was never uploaded > to experimental, but unstable. It seems if a package from experimental has Built-Using on a package in unstable, then dak pulls the unstable source package into experimental and adds ESO: yes. > - golang-github-google-go-github 28.1.1-1 is not in ESO anymore, but > still appears in DDPO. It definitely is, in experimental. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#932431: DDPO: package removed from experimental but still shown in DDPO column
On Sun, Sep 27, 2020 at 9:08 AM Paul Wise wrote: > > On Sat, Sep 26, 2020 at 1:57 PM Roger Shimizu wrote: > > > So what's ESO? > > A package which has this in the Packages file: > > Extra-Source-Only: yes > > dak uses this to indicate that the source package is only kept around > for license compliance purposes because another package still has a > Built-Using header with the ESO version of the package. Once the other > package has been rebuilt against the newer version, then the ESO > version can be removed. > > https://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using Thanks for the explanation! I think this can explain why an old version of package is still in archive, but still cannot explain why it appears in *experimental* column in DDPO page. > > How can I check the ESO status for a specific package? > > $ apt-cache showsrc golang-github-jinzhu-inflection | grep -E > '^(Version|Extra-Source-Only|)(:|$)' Great example. Thanks again! I checked one package I mentioned previously: $ apt-cache showsrc golang-github-google-go-github | grep -E '^(Version|Extra-Source-Only|)(:|$)' Version: 32.1.0-1 Extra-Source-Only: yes Version: 32.1.0-2 But 28.1.1-1 still appears in my DDPO [2] in experimental column. So I think there might be two possible bugs in DDPO: - golang-github-google-go-github version 28.1.1-1 was never uploaded to experimental, but unstable. - golang-github-google-go-github 28.1.1-1 is not in ESO anymore, but still appears in DDPO. [2] https://qa.debian.org/developer.php?login=rosh Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#971064: triggerhappy systemd unit doesn't respect /etc/default/triggerhappy
package: triggerhappy version: 0.5.0-1 severity: important the /etc/default/triggerhappy is not sourced by the systemd unit file, and thus daemon options there are ignored. It makes a way to apply site-specific options that will survive upgrades unnecessarily complex and the existence of the file and existing documentation confusing. As we now use systemd, please update this package to properly work with systemd while respecting the /etc/default/ convention. Thank you.
Bug#971063: systemsettings > display/monitor window is empty
Package: systemsettings Version: 4:5.14.5-1.1 Severity: normal Dear Maintainer, I ran systemsettings5 > hardware > display and monitors; and the righthand pane: "configure monitors and displays" is empty except for the blue dot with an 'i', which does nothing. Below are the messages/errors: rex@debian11:~$ systemsettings5 QCoreApplication::arguments: Please instantiate the QApplication object first Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway. Using Wayland-EGL Using the 'xdg-shell-v6' shell integration WARNING: viewBackgroundColor is deprecated, use backgroundColor with colorSet: Theme.View instead KActivities: Database connection: "kactivities_db_resources_139767671356608_readonly" query_only: QVariant(qlonglong, 1) journal_mode:QVariant(QString, "wal") wal_autocheckpoint: QVariant(qlonglong, 100) synchronous: QVariant(qlonglong, 0) Nothing to load - the client id is empty Nothing to load - the client id is empty qt.qpa.wayland: Wayland does not support QWindow::requestActivate() kscreen.kwayland: Connection to Wayland server at socket: "wayland-0" timed out. kscreen.kwayland: Loading Wayland backend. kscreen.kwayland: Connection to Wayland server at socket: "wayland-0" timed out. kf5.kcoreaddons.kdirwatch: Cannot watch QRC-like path ":/icons/hicolor/index.theme" KActivitiesStats( 0x564f025e6bb0 ) ResultModelPrivate::onResultScoreUpdated result added: "kcm:kcm_kscreen.desktop" score: 3.9077 last: 1601145839 first: 1601013704 end I realize the transition to wayland is fraught with pitfalls, extra work for everyone, and just one big PITA. But the open-source/Linux community really needs to correct a number of issues with X. I don't think it will be as difficult as some have imagined. The unwillingness of certain maintainers to update their packages for wayland appears to be contagious in a "Then I don't have to either!" sort of way, and everyone jumping on the gnome developers for defaulting to wayland. I know there will be problems, even with 'stable'. Don't worry! It's very frustrating for developers when documentation is incorrect, incomplete and/or nonexistent. We can each do our part to figure this thing out. -- 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-10-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8), LANGUAGE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemsettings depends on: ii kio 5.54.1-1 ii kpackagetool5 5.54.0-1 ii libc6 2.28-10 ii libkf5activities5 5.54.0-1 ii libkf5activitiesstats15.54.0-1 ii libkf5auth5 5.54.0-2 ii libkf5completion5 5.54.0-1 ii libkf5configcore5 5.54.0-1+deb10u1 ii libkf5configgui5 5.54.0-1+deb10u1 ii libkf5configwidgets5 5.54.0-1 ii libkf5coreaddons5 5.54.0-1 ii libkf5crash5 5.54.0-1 ii libkf5dbusaddons5 5.54.0-1 ii libkf5declarative55.54.0-1 ii libkf5i18n5 5.54.0-1 ii libkf5iconthemes5 5.54.0-1 ii libkf5itemviews5 5.54.0-1 ii libkf5kcmutils5 5.54.0-1 ii libkf5khtml5 5.54.0-1 ii libkf5kiowidgets5 5.54.1-1 ii libkf5package55.54.0-1 ii libkf5quickaddons55.54.0-1 ii libkf5service-bin 5.54.0-1 ii libkf5service55.54.0-1 ii libkf5widgetsaddons5 5.54.0-1 ii libkf5windowsystem5 5.54.0-1 ii libkf5xmlgui5 5.54.0-1 ii libkworkspace5-5 4:5.14.5.1-1 ii libqt5core5a 5.11.3+dfsg1-1+deb10u4 ii libqt5dbus5 5.11.3+dfsg1-1+deb10u4 ii libqt5gui55.11.3+dfsg1-1+deb10u4 ii libqt5qml55.11.3-4 ii libqt5quick5 5.11.3-4 ii libqt5quickwidgets5 5.11.3-4 ii libqt5widgets55.11.3+dfsg1-1+deb10u4 ii libstdc++610.2.0-7 ii qml-module-org-kde-kcm5.54.0-1 ii qml-module-org-kde-kirigami2 5.54.0-1 ii qml-module-qtquick-controls 5.11.3-2 ii qml-module-qtquick-layouts5.11.3-4 ii qml-module-qtquick2 5.11.3-4 systemsettings recommends no packages. systemsettings suggests no packages. -- no debconf information
Bug#971062: buster-pu: package plinth/19.1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jvalle...@mailbox.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
This update proposes to fix security tracker issue CVE-2020-25073,
where a remote attackers could obtain sensitive information from the
/server-status page of the Apache HTTP Server, because a connection
from the Tor onion service (or from PageKite) is considered a local
connection.
This issue also exists in stretch.
If the update is not approved, then users who enable Tor onion service
or Pagekite risk the apache server logs being publicly visible through
the onion address or kite URL.
To test, you would need to install freedombox package, click through
the initial setup, install Tor through the FreedomBox interface, and
then check if /server-status can be accessed through Tor browser using
the onion address displayed in the interface.
The change has already been applied in unstable, testing, and
buster-backports, and has been confirmed to solve the problem. The
change modifies the initial setup of apache web server so that
mod_status is disabled.
FreedomBox software does encourage use of backports, so I expect
nearly all users already have the fix. However, it is still good to
have it properly fixed in buster.
Please let know if you need any more information.
Thanks,
James
-BEGIN PGP SIGNATURE-
iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAl9v+x8WHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICHLQD/oC5eSNW31WHHPQkAefjKzpHojN
qFqb73JtgGaXquHo5REeNEQvrNO2b0AMOdYNBJPIEkPQu42ffznLggbleP1soapw
K/R7UjESVkXmNNDdzgAbjUy9YpdGLM0nNCG72wY2cuQse9nLIRZa3gPQ8+4MxizR
zInnTz7uAkcyd6J2RRF2h6GF0qvAfFWc0gniDtBdJQc2oNcHQsf3Nl81e91THrSm
Law5SrDeu/1wjH+OWZcPnyBrq0abA+V6kDFYjprzM9dnjRnln5ONOUvOdfMeJ8aa
BSWXfKcMZPyOtKZAFQ4lAQTIZivoZWS1TZjI7fLMKydT4Vda3fvwLYtULxDXorp1
Q5uxN4VwV4rF1I/OhaJeAV702emMLEdZ104OwegG2+ND6JqUlgYHPViA2xMIHzI4
DanaeIqHjd8oDYTClq5rgHGZgqbc7bMr0rbGxB8iSrJAqP0AXFMc8RiZVVZXLsEf
aqawiwU02Whq4VxWPLP4rOB1m84LB1YYZ4/fkqjjWcvfWyfK+hASGZYp8k7npP/S
Lia+g5Ibx3/b9PXdEg0Opn92SJcVbp9JDirx4PdRPd9/80qirBuDOkA3oHrog/X/
sO9IKRXfWxzuN4PDEv4Fn6tpZeqEbTlY6mBvWaxEdNhhizOOrUuvzIuPbz143aaw
tA9xT532YZqFuymT8Q==
=Nhun
-END PGP SIGNATURE-
diff -Nru plinth-19.1/actions/apache plinth-19.1+deb10u1/actions/apache
--- plinth-19.1/actions/apache 2019-02-14 06:01:19.0 -0500
+++ plinth-19.1+deb10u1/actions/apache 2020-09-21 21:40:22.0 -0400
@@ -122,6 +122,9 @@
webserver.enable('proxy_fcgi', kind='module')
webserver.enable('rewrite', kind='module')
+# Disable /server-status page to avoid leaking private info.
+webserver.disable('status', kind='module')
+
# switch to mod_ssl from mod_gnutls
webserver.disable('gnutls', kind='module')
webserver.enable('ssl', kind='module')
diff -Nru plinth-19.1/debian/changelog plinth-19.1+deb10u1/debian/changelog
--- plinth-19.1/debian/changelog2019-02-14 06:01:19.0 -0500
+++ plinth-19.1+deb10u1/debian/changelog2020-09-21 21:40:22.0
-0400
@@ -1,3 +1,9 @@
+plinth (19.1+deb10u1) buster; urgency=medium
+
+ * apache: Disable mod_status (CVE-2020-25073)
+
+ -- James Valleroy Mon, 21 Sep 2020 21:40:22 -0400
+
plinth (19.1) unstable; urgency=medium
[ James Valleroy ]
Bug#971059: linux-image-5.8.0-2-armmp-lpae: PCI invisible on Raspberry Pi 4B 8GB
Package: src:linux Version: 5.8.10-1 Severity: normal Dear Maintainer, I am reporting a similar symptom to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968109 for a different kernel package (armmp-lpae). PCI peripherals of Raspberry Pi 4B (8GB model) are completely invisible. lspci shows nothing. As a result, USB is unusable. Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.8.0-2-armmp-lpae (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-8) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.10-1 (2020-09-19) ** Command line: video=HDMI-A-1:3840x2160M@30,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48 dma.dmachans=0x71f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 console=tty0 console=ttyS1,115200 root=/dev/mmcblk1p2 rw elevator=deadline fsck.repair=yes net.ifnames=0 rootwait ** Tainted: CE (9216) * staging driver was loaded * unsigned module was loaded ** Kernel log: [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 5.8.0-2-armmp-lpae (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-8) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.10-1 (2020-09-19) [0.00] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.4 [0.00] Memory policy: Data cache writealloc [0.00] efi: UEFI not found. [0.00] Reserved memory: created CMA memory pool at 0x3700, size 64 MiB [0.00] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [0.00] Zone ranges: [0.00] DMA [mem 0x-0x2fff] [0.00] Normal empty [0.00] HighMem [mem 0x3000-0x0001] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x3b3f] [0.00] node 0: [mem 0x4000-0xfbff] [0.00] node 0: [mem 0x0001-0x0001] [0.00] Initmem setup node 0 [mem 0x-0x0001] [0.00] On node 0 totalpages: 2061312 [0.00] DMA zone: 2304 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 196608 pages, LIFO batch:63 [0.00] HighMem zone: 1864704 pages, LIFO batch:63 [0.00] percpu: Embedded 21 pages/cpu s54220 r8192 d23604 u86016 [0.00] pcpu-alloc: s54220 r8192 d23604 u86016 alloc=21*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 2059008 [0.00] Kernel command line: video=HDMI-A-1:3840x2160M@30,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48 dma.dmachans=0x71f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 console=tty0 console=ttyS1,115200 root=/dev/mmcblk1p2 rw elevator=deadline fsck.repair=yes net.ifnames=0 rootwait [0.00] Kernel parameter elevator= does not have any effect anymore. Please use sysfs to set IO scheduler for individual devices. [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:on, heap free:off [0.00] software IO TLB: mapped [mem 0x23985000-0x27985000] (64MB) [0.00] Memory: 7974884K/8245248K available (10240K kernel code, 1263K rwdata, 3228K rodata, 2048K init, 336K bss, 204828K reserved, 65536K cma-reserved, 7393280K highmem) [0.00] random: get_random_u32 called from __kmem_cache_create+0x48/0x570 with crng_init=0 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] ftrace: allocating 35987 entries in 71 pages [0.00] ftrace: allocated 71 pages with 4 groups [0.00] rcu: Hierarchical RCU implementation. [0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4. [0.00] Rude variant of Tasks RCU enabled. [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] GIC: Using split EOI/Deactivate mode [0.09]
Bug#971058: linux-image-4.19.0-11-686: "Unchecked MSR access error: RDMSR" on Geode LX on 4.19.0-11-686; seems present on -10 too
Package: src:linux Version: 4.19.146-1 Severity: normal Dear Maintainer, Debian 4.19 kernels (unsure for how long) are giving MSR access error upon boot on Geode LX CPUs. (System otherwise is working OK. Is this potentially due to the not-quite-686-compatibility of the Geode? If so, how hard would it be for us to officially support Geode as the bottom end?) -- Package-specific info: ** Version: Linux version 4.19.0-11-686 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.146-1 (2020-09-17) ** Command line: BOOT_IMAGE=/vmlinuz-4.19.0-11-686 root=UUID=76c41045-2df9-4e27-8c60-c6ce79a87590 ro console=ttyS0,38400n8 ** Not tainted ** Kernel log: Sep 26 12:20:42 dubbo kernel: [0.00] Linux version 4.19.0-11-686 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.146-1 (2020-09-17) Sep 26 12:20:42 dubbo kernel: [0.00] x86/fpu: x87 FPU will use FSAVE Sep 26 12:20:42 dubbo kernel: [0.00] BIOS-provided physical RAM map: Sep 26 12:20:42 dubbo kernel: [0.00] BIOS-e820: [mem 0x-0x0009] usable Sep 26 12:20:42 dubbo kernel: [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved Sep 26 12:20:42 dubbo kernel: [0.00] BIOS-e820: [mem 0x0010-0x0fff] usable Sep 26 12:20:42 dubbo kernel: [0.00] BIOS-e820: [mem 0xfff0-0x] reserved Sep 26 12:20:42 dubbo kernel: [0.00] Notice: NX (Execute Disable) protection missing in CPU! Sep 26 12:20:42 dubbo kernel: [0.00] DMI not present or invalid. Sep 26 12:20:42 dubbo kernel: [0.00] tsc: Fast TSC calibration using PIT Sep 26 12:20:42 dubbo kernel: [0.00] tsc: Detected 498.037 MHz processor Sep 26 12:20:42 dubbo kernel: [0.032706] e820: update [mem 0x-0x0fff] usable ==> reserved Sep 26 12:20:42 dubbo kernel: [0.032725] e820: remove [mem 0x000a-0x000f] usable Sep 26 12:20:42 dubbo kernel: [0.032753] last_pfn = 0x1 max_arch_pfn = 0x10 Sep 26 12:20:42 dubbo kernel: [0.032769] Disabled Sep 26 12:20:42 dubbo kernel: [0.032785] x86/PAT: MTRRs disabled, skipping PAT initialization too. Sep 26 12:20:42 dubbo kernel: [0.032803] x86/PAT: Configuration [0-7]: WB WT UC- UC WB WT UC- UC Sep 26 12:20:42 dubbo kernel: [0.071434] initial memory mapped: [mem 0x-0x0dff] Sep 26 12:20:42 dubbo kernel: [0.071774] RAMDISK: [mem 0x0e31a000-0x0f7b9fff] Sep 26 12:20:42 dubbo kernel: [0.071796] ACPI: Early table checksum verification disabled Sep 26 12:20:42 dubbo kernel: [0.073045] ACPI BIOS Error (bug): A valid RSDP was not found (20180810/tbxfroot-210) Sep 26 12:20:42 dubbo kernel: [0.073076] 0MB HIGHMEM available. Sep 26 12:20:42 dubbo kernel: [0.073091] 256MB LOWMEM available. Sep 26 12:20:42 dubbo kernel: [0.073106] mapped low ram: 0 - 1000 Sep 26 12:20:42 dubbo kernel: [0.073118] low ram: 0 - 1000 Sep 26 12:20:42 dubbo kernel: [0.073155] Zone ranges: Sep 26 12:20:42 dubbo kernel: [0.073168] DMA [mem 0x1000-0x00ff] Sep 26 12:20:42 dubbo kernel: [0.073188] Normal [mem 0x0100-0x0fff] Sep 26 12:20:42 dubbo kernel: [0.073207] HighMem empty Sep 26 12:20:42 dubbo kernel: [0.073222] Movable zone start for each node Sep 26 12:20:42 dubbo kernel: [0.073233] Early memory node ranges Sep 26 12:20:42 dubbo kernel: [0.073251] node 0: [mem 0x1000-0x0009] Sep 26 12:20:42 dubbo kernel: [0.073267] node 0: [mem 0x0010-0x0fff] Sep 26 12:20:42 dubbo kernel: [0.073288] Initmem setup node 0 [mem 0x1000-0x0fff] Sep 26 12:20:42 dubbo kernel: [0.073308] On node 0 totalpages: 65439 Sep 26 12:20:42 dubbo kernel: [0.078811] DMA zone: 40 pages used for memmap Sep 26 12:20:42 dubbo kernel: [0.078818] DMA zone: 0 pages reserved Sep 26 12:20:42 dubbo kernel: [0.078827] DMA zone: 3999 pages, LIFO batch:0 Sep 26 12:20:42 dubbo kernel: [0.079253] Normal zone: 600 pages used for memmap Sep 26 12:20:42 dubbo kernel: [0.079263] Normal zone: 61440 pages, LIFO batch:15 Sep 26 12:20:42 dubbo kernel: [0.085496] Using APIC driver default Sep 26 12:20:42 dubbo kernel: [0.085575] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org Sep 26 12:20:42 dubbo kernel: [0.086503] No local APIC present or hardware disabled Sep 26 12:20:42 dubbo kernel: [0.086515] APIC: disable apic facility Sep 26 12:20:42 dubbo kernel: [0.086526] APIC: switched to apic NOOP Sep 26 12:20:42 dubbo kernel: [0.086543] smpboot: Allowing 1 CPUs, 0 hotplug CPUs Sep 26 12:20:42 dubbo kernel: [0.086600] PM: Registered nosave memory: [mem 0x-0x0fff] Sep 26 12:20:42 dubbo kernel: [0.086622] PM: Registered nosave memory: [mem 0x000a-0x000e] Sep
Bug#969205:
Hi, I'm potentially interested in adopting avr-libc and its related toolchain packages, however I was wondering how much work is generally advised, if the packaging are in need of any substantial refactors, and also of how responsive upstream is. Years ago I was a heavy user of avr-libc, so I have some familiarity with it. Thanks! -Chris
Bug#970752: system-detect-virt with Debian under VirtualBox
$ systemd-detect-virt oracle
Bug#932431: DDPO: package removed from experimental but still shown in DDPO column
On Sat, Sep 26, 2020 at 1:57 PM Roger Shimizu wrote: > So what's ESO? A package which has this in the Packages file: Extra-Source-Only: yes dak uses this to indicate that the source package is only kept around for license compliance purposes because another package still has a Built-Using header with the ESO version of the package. Once the other package has been rebuilt against the newer version, then the ESO version can be removed. https://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using > How can I check the ESO status for a specific package? $ apt-cache showsrc golang-github-jinzhu-inflection | grep -E '^(Version|Extra-Source-Only|)(:|$)' Version: 0.0~git20170102.0.1c35d90-2 Extra-Source-Only: yes Version: 1.0.0-1 Version: 1.0.0-1 Extra-Source-Only: yes -- bye, pabs https://wiki.debian.org/PaulWise
Bug#971025: RFP: amnesia-amachineforpigs -- A survival horror adventure video game
On Sat, Sep 26, 2020 at 12:57 PM Bertrand Marc wrote: > * URL : https://github.com/FrictionalGames/AmnesiaAMachineForPigs > * License : GPLv3 Please note that the data for this game is still proprietary, so this will have to go to contrib if someone packages it and probably it would be useful to have support for it in game-data-packager. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#971026: RFP: amnesia-thedarkdescent -- A survival horror adventure video game
On Sat, Sep 26, 2020 at 1:00 PM Bertrand Marc wrote: > * URL : https://github.com/FrictionalGames/AmnesiaTheDarkDescent > * License : GPLv3 Please note that the data for this game is still proprietary, so this will have to go to contrib if someone packages it and probably it would be useful to have support for it in game-data-packager. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#917485: ckermit: relax openssl version check or tighten libssl1.x.y dependencies
On Sat, 2020-09-26 at 10:12 +0200, Sébastien Villemot wrote: > The bug was fixed by a patch in 302-5.3+deb9u1. The reintroduction of > the package, even if it no longer contains the patch, did not > reintroduce the bug, because upstream fixed it in another way: the > dynamic check against the version of OpenSSL has been improved, in the > sense that it accept changes in the patchlevel version (e.g. if the > package was compiled against OpenSSL 1.1.0, the dynamic check will > allow execution against 1.1.1, since there is ABI stability). At first glance the code didn't seem to have fixed the issue. Thanks for the info and the clarification and sorry for the noise. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#969768: lib-io-socket-ip-perl: do not release with bullseye
On Sat, 26 Sep 2020 23:52:42 +0100, Dominic Hargreaves wrote: > > I guess we should update libio-socket-ip-perl to 0.41 and close this > > bug with the upload (and close #969967 in libtest-tcp-perl as well). > > > > I've pushed libio-socket-ip-perl_0.41-1 to git but wanted to give > > others a chance to comment before the actual upload. > > Fine by me! Thanks Dom! libio-socket-ip-perl 0.41-1 uploaded (and #969967 closed manually). Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Jerry Lee Lewis: Crazy Arms signature.asc Description: Digital Signature
Bug#970752: systemd-detect-virt
Results of 'systemd-detect-virt' detect 'vmware' correctly in both VirtualBox and VMplayer: $ systemd-detect-virt vmware
Bug#971001: Please support caching packages outside the chroot
Quoting Johannes Schauer (2020-09-26 23:18:54) > Quoting Josh Triplett (2020-09-26 22:47:50) > > On Sat, 26 Sep 2020 22:09:57 +0200 Johannes Schauer > > wrote: > > > This will not work with all modes. I guess you are using root or > > > fakechroot mode? > > > > Yes, I'm using root mode, as I need a directory of files I can feed > > to `mkfs.ext4 -d`. In theory I might be able to use fakechroot mode > > and run mkfs.ext4 underneath mmdebstrap; I may try that once I've > > gotten the existing setup to do everything I need it to. > > Maybe the ability of mmdebstrap to produce ext2 filesystems directly > can be useful for you. You will then not need root privileges. Ohh, that would be really useful to me :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#969768: lib-io-socket-ip-perl: do not release with bullseye
On Sat, Sep 26, 2020 at 05:07:13PM +0200, gregor herrmann wrote: > Control: tag -1 + pending > > On Mon, 07 Sep 2020 23:50:03 +0100, Dominic Hargreaves wrote: > > > IO-Socket-IP is bundled with perl 5.30, so there is no need to ship > > this separately. > > IO-Socket-IP 0.41 has been released, without the patch for #964902 > but with some other changes: > https://metacpan.org/pod/IO::Socket::IP > > IO::Socket::IP 0.41 is bundled with perl ony starting with v5.33.2, > which won't be in Debian any time soon. > > I guess we should update libio-socket-ip-perl to 0.41 and close this > bug with the upload (and close #969967 in libtest-tcp-perl as well). > > I've pushed libio-socket-ip-perl_0.41-1 to git but wanted to give > others a chance to comment before the actual upload. Fine by me!
Bug#971057: gnome-shell: [Wayland] Session crashes if any window is opened in the first ~10 seconds
Thank you for the quick reply. On Sat, 2020-09-26 at 23:18 +0100, Simon McVittie wrote: > Are you using any GNOME Shell extensions? If you are, please try > disabling > them and see whether this still happens. I'm not using any extensions, precisely to remove that factor when testing. > > From the kernel log: > > gnome-shell[3136]: segfault at 1c ip 7f1520c0de27 sp 7ffd81363130 > > error 4 in libmutter-7.so.0.0.0[7f1520b89000+115000] > > Can you get a backtrace from this crash? Sure thing, you can find it attached. > It would also be useful if you could log in to a Wayland session, *not* > open any windows (so this crash doesn't happen), then look at the systemd > journal for the log messages that happened around 10 seconds after login - > that might give us some clues about what event you have to wait for to > avoid this crash. The error messages in the gnome-shell journal are not terribly useful, whether I open or not windows. It will still spit something about the clutter stage. Sorry for not clarying this earlier. I will try to get cleaner logs, meanwhile, the last bit is interesting. --- After a bit more of testing, I can now reliably fix/reproduce this issue. 1. I have a laptop and an external monitor. Sometimes I use this as a two display configuration (laptop being the main display). When testing this, my laptop lid was closed. 2. It seems that mutter assumed for some reason that my laptop screen was still active. That's where the mouse was "hiding". 3. Upon opening a window, gnome-shell tried to open it in the display where the mouse was. *Here* is the crash. 4. If upon logging in I move my mouse up (a lot) to "move it" to my external monitor (from the ghost laptop display), then windows can be opened safely and no crash happens. So it seems that the display settings are behaving weirdly across sessions. To reproduce reliably (at least for me): 1. Use a two-monitor configuration (two active displays) 2. Log out while the mouse is in the laptop screen (primary display) 3. While in GDM, close the lid (so only the external monitor is on) 3. Log in, mouse is "lost" 4. Open a window quickly using the keyboard -> crash Hope it helps, Santiago coredumpctl gdb Hint: You are currently not seeing messages from other users and the system. Users in groups 'adm', 'systemd-journal' can see all messages. Pass -q to turn off this notice. PID: 6385 (gnome-shell) UID: 1000 (santi) GID: 1000 (santi) Signal: 11 (SEGV) Timestamp: Sat 2020-09-26 18:30:48 EDT (26s ago) Command Line: /usr/bin/gnome-shell Executable: /usr/bin/gnome-shell Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@wayland.service Unit: user@1000.service User Unit: org.gnome.Shell@wayland.service Slice: user-1000.slice Owner UID: 1000 (santi) Boot ID: e139577ce6f44483a3c529225c071a15 Machine ID: f7263c2151e147e98482ab09b3588304 Hostname: T540p Storage: /var/lib/systemd/coredump/core.gnome-shell.1000.e139577ce6f44483a3c529225c071a15.6385.160115944800.zst Message: Process 6385 (gnome-shell) of user 1000 dumped core. Stack trace of thread 6385: #0 0x7fd5215fbe27 meta_window_place (libmutter-7.so.0 + 0xcbe27) #1 0x7fd5215e606c place_window_if_needed (libmutter-7.so.0 + 0xb606c) #2 0x7fd52160a262 meta_window_move_resize_internal (libmutter-7.so.0 + 0xda262) #3 0x7fd52160a40a meta_window_force_placement (libmutter-7.so.0 + 0xda40a) #4 0x7fd521663455 xdg_toplevel_set_maximized (libmutter-7.so.0 + 0x133455) #5 0x7fd520a6cccd n/a (libffi.so.7 + 0x6ccd) #6 0x7fd520a6c25a n/a (libffi.so.7 + 0x625a) #7 0x7fd520ff64d2 n/a (libwayland-server.so.0 + 0xd4d2) #8 0x7fd520ff1ae2 n/a (libwayland-server.so.0 + 0x8ae2) #9 0x7fd520ff4492 wl_event_loop_dispatch (libwayland-server.so.0 + 0xb492) #10 0x7fd521643aa7 wayland_event_source_dispatch (libmutter-7.so.0 + 0x113aa7) #11 0x7fd5221cab8b g_main_context_dispatch (libglib-2.0.so.0 + 0x51b8b) #12 0x7fd5221cae38 n/a (libglib-2.0.so.0 + 0x51e38) #13 0x7fd5221cb12b g_main_loop_run (libglib-2.0.so.0 + 0x5212b) #14 0x7fd5215f4a6e meta_run (libmutter-7.so.0 + 0xc4a6e) #15 0x560c06f72838 n/a (gnome-shell + 0x2838) #16 0x7fd52138fcca __libc_start_main (libc.so.6 + 0x26cca) #17 0x560c06f72a1a n/a (gnome-shell + 0x2a1a) Stack trace of thread 6395: #0 0x7fd52145c4bf __GI___poll (libc.so.6 + 0xf34bf) #1 0x7fd5221cadce n/a
Bug#906124: grub-efi-amd64: Also in grub-efi-amd64
Hello, Has this bug been fixed ?
Bug#970352: unprivileged podman dies with gibberish
Control: close -1 Control: tag -1 unreproducible Hi Harald, On Sun, Sep 20, 2020 at 11:32 AM Reinhard Tartler wrote: > Control: tag -1 upstream > > On Sun, Sep 20, 2020 at 9:28 AM Harald Dunkel wrote: > >> I think there is a misunderstanding: The problem is not the error, >> but the error *message*. Can you do without complaining about bad >> HTTP code and URLs that don't work? Surely they don't give a hint >> about what is wrong. They are just distracting. >> >> > That was not clear to me from the initial description. In any case, I > think the most efficient way to resolve this is to ask upstream. May I ask > you to file an upstream report at > https://github.com/containers/podman/issues/new ? I could do so on your > behalf, but it'd be more efficient if you could do so yourself. > > Let me know how you prefer to proceed. > > I've read the 'gibberish' again, and have to ask for clarification. It seems to be this report is actually about two The "gibberish" is not what is causing podman to "die". The relevant part of the output probably is this: ApplyLayer exit status 1 stdout: stderr: there might not be enough IDs available in the namespace (requested 0:42 for /etc/gshadow): lchown /etc/gshadow: invalid argument I would have hoped that the instruction in README.Debian would have helped, but you indicated that you are using a custom, non-Debian kernel, so there is no way for me to reproduce this crash. I have to ask you to try again with a Debian kernel and report this issue to upstream. The other issue in your report happens when you instruct podman to fetch an image without fully qualifying what registry to get the image from. In this case, podman will search several registries as configured in /etc/containers/registries.conf. The Debian package configures "quay.io" and "docker.io" in that order. The image you specified is not available on quay.io, but on docker.io, and this causes some warnings that might be considered confusing. I'm not sure what kind of formatting or behavior would be more helpful to both users and developers that have to triage user errors. As package maintainer, I don't think I can support you well with either of these issues. I'd strongly encourage you to discuss both upstream at https://github.com/containers/podman/issues/new. Let me know the bug numbers, I'm happy to repoen this report with appropriate linking to the upstream bug. -- regards, Reinhard
Bug#971057: gnome-shell: [Wayland] Session crashes if any window is opened in the first ~10 seconds
On Sat, 26 Sep 2020 at 17:35:58 -0400, Santiago Batista wrote: > In a Wayland session, the mouse is not visible in the first ~10 > seconds of the session. If the user tries to open any window shortly > after logging in (using the keyboard), the session immediately crashes. Are you using any GNOME Shell extensions? If you are, please try disabling them and see whether this still happens. > From the kernel log: > gnome-shell[3136]: segfault at 1c ip 7f1520c0de27 sp 7ffd81363130 > error 4 in libmutter-7.so.0.0.0[7f1520b89000+115000] Can you get a backtrace from this crash? Since you're using systemd, the easiest way is probably to install systemd-coredump and gdb, reboot, then reproduce the crash. "coredumpctl gdb" will load the resulting crash dump into gdb for analysis. To get a useful backtrace, you will need to install at least libmutter-7-0-dbgsym from the debian-debug archive. See https://wiki.debian.org/HowToGetABacktrace for more details. It would also be useful if you could log in to a Wayland session, *not* open any windows (so this crash doesn't happen), then look at the systemd journal for the log messages that happened around 10 seconds after login - that might give us some clues about what event you have to wait for to avoid this crash. Thanks, smcv
Bug#971038: budgie-desktop: please build against libmutter-7-dev in unstable
On Sat, 26 Sep 2020 at 22:00:35 +0100, David Mohammed wrote: > sbuild is failing at the moment - I presume mutter-7 hasn't been > uploaded yet since its a dependency failure. It was uploaded and built on all architectures a few hours ago, but could take a few more hours to get into the main archive and then to your mirror. Packages should be generally available tomorrow. If now is more convenient for you, see https://incoming.debian.org/ for details of how the official buildds access just-built packages (it is possible to configure your local sbuild/apt to access it too). Thanks for responding so quickly! smcv
Bug#971057: gnome-shell: [Wayland] Session crashes if any window is opened in the first ~10 seconds
Package: gnome-shell Version: 3.38.0-2 Severity: important X-Debbugs-Cc: santibati...@gmail.com Dear Maintainer, Thank you for packaging 3.38. Upon upgrading the Gnomee stack, I tried testing the new version. In a Wayland session, the mouse is not visible in the first ~10 seconds of the session. If the user tries to open any window shortly after logging in (using the keyboard), the session immediately crashes. From the kernel log: gnome-shell[3136]: segfault at 1c ip 7f1520c0de27 sp 7ffd81363130 error 4 in libmutter-7.so.0.0.0[7f1520b89000+115000] From the gnome-shell log: gnome-shell[2764]: Registering session with GDM gnome-shell[2764]: Can't update stage views actor StLabel is on because it needs an allocation. gnome-shell[2764]: Can't update stage views actor ClutterText is on because it needs an allocation. gnome-shell[2764]: Can't update stage views actor ClutterText is on because it needs an allocation. gnome-shell[2764]: Can't update stage views actor StLabel is on because it needs an allocation. gnome-shell[2764]: Can't update stage views actor ClutterText is on because it needs an allocation. gnome-shell[3136]: Some code accessed the property 'CredentialManager' on the module 'credentialManager'. That property was defined with 'let' or 'const' inside the mo> gnome-shell[3136]: Skipping parental controls support as it’s disabled gnome-shell[3136]: Unset XDG_SESSION_ID, getCurrentSessionProxy() called outside a user session. Asking logind directly. gnome-shell[3136]: Will monitor session 6 gnome-shell[3136]: clutter_do_event: Event does not have a stage: discarding. gnome-shell[3136]: _clutter_stage_queue_event: assertion 'CLUTTER_IS_STAGE (stage)' failed gnome-shell[3136]: clutter_do_event: Event does not have a stage: discarding. gnome-shell[3136]: _clutter_stage_queue_event: assertion 'CLUTTER_IS_STAGE (stage)' failed gnome-shell[3136]: clutter_do_event: Event does not have a stage: discarding. gnome-shell[3136]: Error looking up permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation gnome-shell[3136]: _clutter_stage_queue_event: assertion 'CLUTTER_IS_STAGE (stage)' failed gnome-shell[3136]: clutter_do_event: Event does not have a stage: discarding. gnome-shell[3136]: _clutter_stage_queue_event: assertion 'CLUTTER_IS_STAGE (stage)' failed gnome-shell[2764]: Failed to set CRTC gamma: drmModeCrtcSetGamma on CRTC 45 failed: Permission denied gnome-shell[2764]: Failed to set CRTC gamma: drmModeCrtcSetGamma on CRTC 45 failed: Permission denied If, instead of opening something, the user waits ~10 seconds, the mouse appears and the session can be then used normally. I didn't observe this problem when using the X11 backend. Best, Santiago -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en 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.38.0-1 ii evolution-data-server3.36.4-1 ii gir1.2-accountsservice-1.0 0.6.55-3 ii gir1.2-atspi-2.0 2.38.0-2 ii gir1.2-freedesktop 1.66.0-1 ii gir1.2-gcr-3 3.36.0-2 ii gir1.2-gdesktopenums-3.0 3.38.0-2 ii gir1.2-gdm-1.0 3.38.0-2 ii gir1.2-geoclue-2.0 2.5.6-1 ii gir1.2-glib-2.0 1.66.0-1 ii gir1.2-gnomebluetooth-1.03.34.1-1 ii gir1.2-gnomedesktop-3.0 3.38.0-2 ii gir1.2-gtk-3.0 3.24.23-1 ii gir1.2-gweather-3.0 3.36.1-1 ii gir1.2-ibus-1.0 1.5.22-5 ii gir1.2-mutter-7 3.38.0-2 ii gir1.2-nm-1.01.26.2-1 ii gir1.2-nma-1.0 1.8.30-1 ii gir1.2-pango-1.0 1.46.1-1 ii gir1.2-polkit-1.00.105-29 ii gir1.2-rsvg-2.0 2.48.8+dfsg-1 ii gir1.2-soup-2.4 2.70.0-1 ii gir1.2-upowerglib-1.00.99.11-2 ii gjs 1.66.0-1 ii gnome-backgrounds3.38.0-1 ii gnome-settings-daemon3.38.0-2 ii gnome-shell-common 3.38.0-2 ii gsettings-desktop-schemas3.38.0-2 ii gstreamer1.0-pipewire0.3.12-1 ii libatk-bridge2.0-0 2.38.0-1 ii libatk1.0-0
Bug#941659: Build purelibc on ppc64el
On Thu, 3 Oct 2019 15:10:53 +0200 =?UTF-8?B?RnLDqWTDqXJpYw==?= Bonnard wrote: > Dear maintainer, > is there any reason that purelibc isn't built on ppc64el ? > I tested on ppc64el and it built well. Built: https://buildd.debian.org/status/fetch.php?pkg=purelibc=mips64el=1.0.3-1=1601118271=0 Best Regards -- Andrea Capriotti
Bug#941659: Build purelibc on ppc64el
Il giorno sab, 26/09/2020 alle 23.26 +0200, Andrea Capriotti ha scritto: > On Thu, 3 Oct 2019 15:10:53 +0200 =?UTF-8?B?RnLDqWTDqXJpYw==?= > Bonnard > wrote: > > > Dear maintainer, > > is there any reason that purelibc isn't built on ppc64el ? > > I tested on ppc64el and it built well. > > Built: > > https://buildd.debian.org/status/fetch.php?pkg=purelibc=mips64el=1.0.3-1=1601118271=0 Sorry, wrong link. https://buildd.debian.org/status/fetch.php?pkg=purelibc=ppc64el=1.0.3-1=1601118006=0 Best Regards -- Andrea Capriotti
Bug#971001: Please support caching packages outside the chroot
Hi, Quoting Josh Triplett (2020-09-26 22:47:50) > On Sat, 26 Sep 2020 22:09:57 +0200 Johannes Schauer wrote: > > Quoting Josh Triplett (2020-09-26 21:47:56) > > > > so... you want something like this: > > > > > > > > $ mmdebstrap --customize-hook='sync-out /var/cache/apt/archives > > > > ./cache' unstable /dev/null > > > > $ mmdebstrap --variant=apt --setup-hook='mkdir -p > > > > "$1"/var/cache/apt/archives' --setup-hook='sync-in ./cache > > > > /var/cache/apt/archives' unstable output.tar > > > > > > > > The first command fills your local directory "./cache" with the > > > > contents of > > > > /var/cache/apt/archives from the first run while the second invocation > > > > gets the > > > > contents from that directory and thus is able to operate a bit faster. > > > > > > By the time customize-hook runs, mmdebstrap has already cleared > > > /var/cache/apt/archives, so there's nothing to copy out. > > > > then why is my ./cache directory filled with lots of *.deb files? I tried > > out > > the commands above before hitting the send button. > > Try this: > > sudo mmdebstrap \ > --mode=sudo \ the sudo mode is automatically chosen, when you run mmdebstrap as root > --variant=apt \ > --include='systemd-sysv udev' \ > --setup-hook='mkdir -p cache "$1"/var/cache/apt/archives' \ > --setup-hook='sync-in ./cache /var/cache/apt/archives' \ > --customize-hook='ls -l "$1"/var/cache/apt/archives' \ > --customize-hook='sync-out /var/cache/apt/archives ./cache' \ > --customize-hook='rm -rf "$1/var/log/journal"' \ > --dpkgopt='path-exclude=/lib/systemd/system/fstrim.*' \ > --dpkgopt='path-exclude=/lib/systemd/system/*.timer' \ > --dpkgopt='path-exclude=/usr/share/bash-completion/*' \ > --dpkgopt='path-exclude=/usr/share/bug/*' \ > --dpkgopt='path-exclude=/usr/share/doc/*' \ > --dpkgopt='path-exclude=/usr/share/info/*' \ > --dpkgopt='path-exclude=/usr/share/lintian/*' \ > --dpkgopt='path-exclude=/usr/share/locale/*' \ > --dpkgopt='path-exclude=/usr/share/man/*' \ > --dpkgopt='path-include=/usr/share/man/man[0-9]/' \ > --dpkgopt='path-exclude=/usr/share/zsh/*' \ > sid target > > Try running that twice. The first time, the ls at the end does show some > archives (though only for the subset of packages installed later by > --include and its dependencies, not the essential packages). The second > time, apt still does the download, and the ls shows nothing. > > Is there something wrong with the above? Yes, one bit is missing. For the initial Essential:yes package set, mmdebstrap deletes the *.deb files itself after installing them. So you have to copy them out of the chroot before the deletion happens, so between downloading and extracting. Like so: $ sudo mmdebstrap --variant=apt --include='systemd-sysv udev' \ > --setup-hook='mkdir -p cache "$1"/var/cache/apt/archives' \ > --setup-hook='sync-in ./cache /var/cache/apt/archives' \ > --extract-hook="sync-out /var/cache/apt/archives ./cache" \ > --customize-hook='sync-out /var/cache/apt/archives ./cache' \ > unstable debian-unstable > > This will not work with all modes. I guess you are using root or fakechroot > > mode? > > Yes, I'm using root mode, as I need a directory of files I can feed to > `mkfs.ext4 -d`. In theory I might be able to use fakechroot mode and > run mkfs.ext4 underneath mmdebstrap; I may try that once I've gotten the > existing setup to do everything I need it to. Maybe the ability of mmdebstrap to produce ext2 filesystems directly can be useful for you. You will then not need root privileges. Thanks! cheers, josch signature.asc Description: signature
Bug#971056: gkrellm-gkrellmpc FTCBFS: uses the build architecture pkg-config
Source: gkrellm-gkrellmpc Version: 0.1~beta10-4 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs gkrellm-gkrellmpc fails to cross build from source, because the upstream Makefile hard codes the build architecture pkg-config. It becomes cross buildable once making pkg-config substitutable. Please consider applying the attached patch. Helmut --- gkrellm-gkrellmpc-0.1~beta10.orig/Makefile +++ gkrellm-gkrellmpc-0.1~beta10/Makefile @@ -7,11 +7,12 @@ OBJECTS = gkrellmpc.o mpd.o conf.o playlist.o addlist.o url.o CC ?= gcc -CFLAGS += -Wall -fPIC `pkg-config gtk+-2.0 --cflags` -DPACKAGE="\"gkrellmpc\"" +PKG_CONFIG ?= pkg-config +CFLAGS += -Wall -fPIC `$(PKG_CONFIG) gtk+-2.0 --cflags` -DPACKAGE="\"gkrellmpc\"" ifeq ($(enable_nls),1) CFLAGS += -DENABLE_NLS endif -LIBS += `pkg-config gtk+-2.0 --libs` `curl-config --libs` +LIBS += `$(PKG_CONFIG) gtk+-2.0 --libs` `curl-config --libs` .PHONY: all clean dist install install_lib install_local_lib install_home install_instructions deinstall uninstall test strip
Bug#971038: budgie-desktop: please build against libmutter-7-dev in unstable
Hi Simon, sure - I'll upload. sbuild is failing at the moment - I presume mutter-7 hasn't been uploaded yet since its a dependency failure. I'll try again regularly over the next few days and upload once the build works with the updated packages. On Sat, 26 Sep 2020 at 17:39, Simon McVittie wrote: > > Source: budgie-desktop > Version: 10.5.1+git20200715-2 > Severity: important > Control: block 969321 by -1 > > Please upload a version of budgie-desktop to unstable that builds with > libmutter-7-dev. The version in experimental seems suitable. > > Someone from the GNOME team might be able to NMU it if you're too > busy. If you're happy for a NMU to go ahead with no further delay, > please let us know so we can keep this transition moving. > > Thanks, > smcv
Bug#971054: winedbg --gdb does not work with 32-bit WINEPREFIX
Package: wine Version: 5.0-4 Severity: normal Hi, Trying to use the --gdb flag with winedbg does not work with 32-bit WINEPREFIXes. Instead of spawning gdb, it just exits: user@host:~$ WINEPREFIX=~/.wine32 winedbg --gdb notepad.exe 002a:002b: create process 'C:\windows\system32\notepad.exe' /0x1106b0 @0x7fa07e50 (0<0>) 002a:002b: create thread I @0x7fa07e50 user@host:~$ Running the same command with a 64-bit prefix works as expected: user@host:~$ winedbg --gdb notepad.exe 002b:002c: create process 'C:\windows\system32\notepad.exe'/0x10980 @0x7f8993d81b60 (0<0>) 002b:002c: create thread I @0x7f8993d81b60 GNU gdb (Debian 8.2.1-2+b3) 8.2.1 002b:002c: loads DLL C:\windows\system32\uxtheme.dll @0x7f899094 (0<0>) warning: remote target does not support file transfer, attempting to access files from local filesystem. 0x7bc961e5 in DbgBreakPoint () from /usr/lib/wine/../x86_64-linux-gnu/wine/ntdll.dll.so Wine-gdb> I was able to reproduce the issue on a VM running only bullseye i386 (no foreign architectures), so it doesn't appear to be a multi-arch related issue. Also, the upstream packages work as expected on bullseye i386. I haven't tested them on buster. Tested, not working: --- Buster, amd64, wine 4.0-2 from buster repo, 32-bit WINEPREFIX Bullseye, i386, wine 5.0-4 from bullseye repo, 32-bit WINEPREFIX Tested, working as expected: --- Buster, amd64, wine 4.0-2 from buster repo, 64-bit WINEPREFIX Bullseye, i386, winehq-stable 4.0.2~bullseye from winehq repo, 32-bit WINEPREFIX Bullseye, i386, winehq-stable 5.0.2~bullseye from winehq repo, 32-bit WINEPREFIX Bullseye, i386, winehq-devel 5.18~bullseye from winehq repo, 32-bit WINEPREFIX Best regards, Bill
Bug#971055: extlinux: Please provide a way for --device to bypass the "doesn't match device" check
Package: extlinux Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3 Severity: normal X-Debbugs-Cc: j...@joshtriplett.org I'd like to use extlinux as part of building a bootable disk image, without requiring root. Given a directory of files, I can build an ext4 image containing those files using the `-d` option to `mkfs.ext4`. However, I haven't found any way to get extlinux to write its files to a directory while writing its boot sector to the disk image file. Running `extlinux --device disk.img --install target/boot` results in an error message `path target/boot doesn't match device disk.img`. I'd like to bypass that error, and get extlinux to write `ldlinux.*` to `target/boot` while writing the corresponding boot track to `disk.img`. That's the last missing component to being able to set up extlinux for a disk image entirely as non-root. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages extlinux depends on: ii libc6 2.31-3 Versions of packages extlinux recommends: ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-3 extlinux suggests no packages. -- no debconf information
Bug#971053: gcc.1: wrong point size after string "C+"
Package: gcc-10-doc Version: 10.1.0-1 Severity: normal Dear Maintainer, the definition of the string "C+" contains size escapes "\s-2...\s0". That string is used in a reduced point size environment, so the overall size changes are: \s-1...\s-2...\s0...s\0 Size changes \s0...\s0 do not work correctly, so the actual size after the second \s0 is three points lower than expected. Test (simplest with "groff -a", (or groff -Tpdf > .pdf) as "nroff" does not change the point size at all): .ds Ex \s-2Example\s0 size of text is \n(.s .br Test \s-1\*(Ex something\s0 .br size of this text is \n(.s ### The bug in the pod2man (Man.pm) file was reported in Debian bug 871225. The bug was now also sent to "bug-debian-modulel...@rt.cpan.org". The file "Man.pm" (in package perl-modules) that is used to create the manual must be corrected locally before it is used to make "gcc.1". The line with the definition of the string C+ is .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' The "\s0" must be changed to "\s+2" (use the reverse absolute value) ### The line $1 . '\s-1' . $2 . '\s0' similarly, the "\s0" must be change to the reverse absolute size change "\s+1". This change could have some effect on later code. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.7-1 (SMP w/2 CPU threads) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages gcc-10-doc depends on: ii gcc-doc-base 10.1.0-1 gcc-10-doc recommends no packages. Versions of packages gcc-10-doc suggests: ii doc-base 0.10.9 -- no debconf information -- Bjarni I. Gislason
Bug#971052: hocr FTCBFS: uses the build architecture pkg-config
Source: hocr Version: 0.10.18-3.2 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs hocr fails to cross build from source, because it uses the build architecture pkg-config and thus fails finding packages. Please consider applying the attached patch to make it use the host architecture pkg-config. Once doing so, hocr becomes cross buildable. Helmut --- hocr-0.10.18.orig/configure.ac +++ hocr-0.10.18/configure.ac @@ -13,7 +13,7 @@ AM_PROG_LIBTOOL dnl check for pkg-config -AC_PATH_PROG(PKG_CONFIG, pkg-config, no) +PKG_PROG_PKG_CONFIG dnl dnl check host system
Bug#971051: ratmenu FTCBFS: strips with the build architecture strip
Source: ratmenu Version: 2.3.22 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs ratmenu fails to cross build from source, because it strips with the build architecture strip during make install via install -s. Beyond breaking cross compilation, doing so also breaks DEB_BUILD_OPTIONS=nostrip as well as generation of -dbgsym packages. It is best to leave stripping up to dh_strip. Please consider applying the attached patch to fix all of the above. Once updating the compat level to 11 or higher, you can drop the override. Helmut diff --minimal -Nru ratmenu-2.3.22/Makefile ratmenu-2.3.22+nmu1/Makefile --- ratmenu-2.3.22/Makefile 2014-06-29 21:28:52.0 +0200 +++ ratmenu-2.3.22+nmu1/Makefile2020-09-26 22:39:55.0 +0200 @@ -12,6 +12,7 @@ OPTIMIZE ?= -O2 DEBUG?= WARN ?= -Wall -pedantic +INSTALL ?= install LIBS = -L/usr/X11R6/lib -lX11 CFLAGS += $(OPTIMIZE) $(WARN) $(DEBUG) @@ -38,6 +39,6 @@ groff -Tascii -man ratmenu.1|less install: $(PROG) - install -D -p -m 755 -s $(PROG) $(PREFIX)/bin/$(PROG) + $(INSTALL) -D -p -m 755 -s $(PROG) $(PREFIX)/bin/$(PROG) # ends up in *both* /usr/man and /usr/share/man, just give up here # install -D -p -m 755 $(PROG).1 $(MANDIR)/man1/$(PROG).1 diff --minimal -Nru ratmenu-2.3.22/debian/changelog ratmenu-2.3.22+nmu1/debian/changelog --- ratmenu-2.3.22/debian/changelog 2014-06-29 21:32:05.0 +0200 +++ ratmenu-2.3.22+nmu1/debian/changelog2020-09-26 22:40:29.0 +0200 @@ -1,3 +1,10 @@ +ratmenu (2.3.22+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1) + + -- Helmut Grohne Sat, 26 Sep 2020 22:40:29 +0200 + ratmenu (2.3.22) unstable; urgency=medium * debian/compat, debian/rules, debian/control: strip down to minimal dh diff --minimal -Nru ratmenu-2.3.22/debian/rules ratmenu-2.3.22+nmu1/debian/rules --- ratmenu-2.3.22/debian/rules 2014-06-29 21:19:42.0 +0200 +++ ratmenu-2.3.22+nmu1/debian/rules2020-09-26 22:40:25.0 +0200 @@ -5,3 +5,6 @@ %: dh $@ + +override_dh_auto_install: + dh_auto_install -- INSTALL='install --strip-program=true'
Bug#971001: Please support caching packages outside the chroot
On Sat, 26 Sep 2020 22:09:57 +0200 Johannes Schauer wrote: > Quoting Josh Triplett (2020-09-26 21:47:56) > > > so... you want something like this: > > > > > > $ mmdebstrap --customize-hook='sync-out /var/cache/apt/archives ./cache' > > > unstable /dev/null > > > $ mmdebstrap --variant=apt --setup-hook='mkdir -p > > > "$1"/var/cache/apt/archives' --setup-hook='sync-in ./cache > > > /var/cache/apt/archives' unstable output.tar > > > > > > The first command fills your local directory "./cache" with the contents > > > of > > > /var/cache/apt/archives from the first run while the second invocation > > > gets the > > > contents from that directory and thus is able to operate a bit faster. > > > > By the time customize-hook runs, mmdebstrap has already cleared > > /var/cache/apt/archives, so there's nothing to copy out. > > then why is my ./cache directory filled with lots of *.deb files? I tried out > the commands above before hitting the send button. Try this: sudo mmdebstrap \ --mode=sudo \ --variant=apt \ --include='systemd-sysv udev' \ --setup-hook='mkdir -p cache "$1"/var/cache/apt/archives' \ --setup-hook='sync-in ./cache /var/cache/apt/archives' \ --customize-hook='ls -l "$1"/var/cache/apt/archives' \ --customize-hook='sync-out /var/cache/apt/archives ./cache' \ --customize-hook='rm -rf "$1/var/log/journal"' \ --dpkgopt='path-exclude=/lib/systemd/system/fstrim.*' \ --dpkgopt='path-exclude=/lib/systemd/system/*.timer' \ --dpkgopt='path-exclude=/usr/share/bash-completion/*' \ --dpkgopt='path-exclude=/usr/share/bug/*' \ --dpkgopt='path-exclude=/usr/share/doc/*' \ --dpkgopt='path-exclude=/usr/share/info/*' \ --dpkgopt='path-exclude=/usr/share/lintian/*' \ --dpkgopt='path-exclude=/usr/share/locale/*' \ --dpkgopt='path-exclude=/usr/share/man/*' \ --dpkgopt='path-include=/usr/share/man/man[0-9]/' \ --dpkgopt='path-exclude=/usr/share/zsh/*' \ sid target Try running that twice. The first time, the ls at the end does show some archives (though only for the subset of packages installed later by --include and its dependencies, not the essential packages). The second time, apt still does the download, and the ls shows nothing. Is there something wrong with the above? > > (Also, I'd prefer to use hardlinks, to avoid making unnecessary copies.) > > This will not work with all modes. I guess you are using root or fakechroot > mode? Yes, I'm using root mode, as I need a directory of files I can feed to `mkfs.ext4 -d`. In theory I might be able to use fakechroot mode and run mkfs.ext4 underneath mmdebstrap; I may try that once I've gotten the existing setup to do everything I need it to.
Bug#971050: dhcpcd5: quiet option in config file is ignored
Package: dhcpcd5 Version: 7.1.0-2 Severity: normal Tags: upstream Dear Maintainer, when I start a global instance of dhcpcd via the initscript, I get its output messages (about getting or renewing a lease, binding interfaces, etc.) on tty1, mixed with the messages from sysvinit/rc. This makes the latter hard or impossible to read because they scroll off. According to the dhcpcd manpage, adding the quiet option to the config file should silence such output, so I did that (see included config at bottom). However it makes no difference whatsoever. Looking at the code I can see nowhere that any action is taken on this option. The big switch statement in parse_option() in if-options.c only has a trivial no-op case for 'q' which seems to be the argument it might get in this situation. -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages dhcpcd5 depends on: ii libc6 2.28-10 ii lsb-base 10.2019051400 Versions of packages dhcpcd5 recommends: pn openresolv | resolvconf Versions of packages dhcpcd5 suggests: pn dhcpcd-gtk -- Configuration Files: /etc/dhcpcd.conf changed: quiet hostname duid persistent option rapid_commit option domain_name_servers, domain_name, domain_search, host_name option classless_static_routes option interface_mtu require dhcp_server_identifier slaac hwaddr waitip 4 waitip 6 -- no debconf information
Bug#971001: Please support caching packages outside the chroot
Quoting Josh Triplett (2020-09-26 21:47:56) > > so... you want something like this: > > > > $ mmdebstrap --customize-hook='sync-out /var/cache/apt/archives ./cache' > > unstable /dev/null > > $ mmdebstrap --variant=apt --setup-hook='mkdir -p > > "$1"/var/cache/apt/archives' --setup-hook='sync-in ./cache > > /var/cache/apt/archives' unstable output.tar > > > > The first command fills your local directory "./cache" with the contents of > > /var/cache/apt/archives from the first run while the second invocation gets > > the > > contents from that directory and thus is able to operate a bit faster. > > By the time customize-hook runs, mmdebstrap has already cleared > /var/cache/apt/archives, so there's nothing to copy out. then why is my ./cache directory filled with lots of *.deb files? I tried out the commands above before hitting the send button. > (Also, I'd prefer to use hardlinks, to avoid making unnecessary copies.) This will not work with all modes. I guess you are using root or fakechroot mode? > And it appears that copying the cache in via setup-hook does not end up > taking effect; either something is clearing/invalidating the cache by the > time apt runs, or apt isn't using it. Works fine for me. Strangely it says you are already on the latest mmdebstrap version... hrm... > I'd be happy to do this with hooks, but at the moment, I don't see a way to > do so successfully. signature.asc Description: signature
Bug#971033: Evince in Debian11 loads CBR verrry slowly (in Debian10 fast)
Package: evince Version: 3.38.0-1 When I try to load a CBR file (detailed below), evince in Debian11 opens it so slowly I can have a cup of coffee in the meantime. Afterwards, the whole computer is slowed down. When I do it with Debian10, evince loads the file fast and computer speed is not affected. This is the file: Go to The Cartoons of Cobean | Samuel [Sam] E Cobean | download and hit the blue [Download (cbr, 113.07 MB)] button. Can this be corrected? I am using Description: Debian GNU/Linux bullseye/sid Release: testing Codename: bullseye Linux debian11 5.8.0-2-amd64 #1 SMP Debian 5.8.10-1 (2020-09-19) x86_64 GNU/Linux Thank you, siggi2 | | | | The Cartoons of Cobean | Samuel [Sam] E Cobean | download The Cartoons of Cobean | Samuel [Sam] E Cobean | download | B–OK. Download books for free. Find books | | |
Bug#971049: ITP: golang-github-axgle-mahonia -- Character-set conversion library implemented in Go
Package: wnpp Severity: wishlist Owner: Arun Kumar Pariyar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: golang-github-axgle-mahonia Version : 0.0~git20180208.3358181-1 Upstream Author : axgle * URL : https://github.com/axgle/mahonia * License : BSD-3-clause Programming Lang: Go Description : Character-set conversion library implemented in Go. Mahonia is a character-set conversion library implemented in Go. All data is compiled into the executable; it doesn't need any external data files.
Bug#821405: dhcpcd no longer starts wpa_supplicant
You do have the file /lib/dhcpcd/dhcpcd-hooks/10-wpa_supplicant right? And if it is a symlink, it points to an existing file? Ian
Bug#971001: Please support caching packages outside the chroot
On Sat, 26 Sep 2020 12:14:38 +0200 Johannes Schauer wrote: > Hi, > > Quoting Josh Triplett (2020-09-26 11:03:12) > > On Sat, Sep 26, 2020 at 07:28:57AM +0200, Johannes Schauer wrote: > > > Quoting Josh Triplett (2020-09-26 06:28:18) > > > > mmdebstrap seems to re-download packages every time it runs. I'd love > > > > to have > > > > a way to cache those packages, so that it can run substantially faster > > > > the > > > > second and subsequent times. > > > > > > Do one thing and do it well. > > > > > > I'm sure you are aware of apt-cacher or apt-cacher-ng? > > > > > > In other situation, for example the mmdebstrap testsuite, I built my own > > > caching mechanism: > > > > > > https://sources.debian.org/src/mmdebstrap/0.7.1-1/make_mirror.sh/ > > > > > > Adding a cache is so simple, you can use a snippet of Python from this > > > pull > > > request of mine: > > > > > > https://salsa.debian.org/debian/devscripts/-/blob/d1c6f2f6a3dca51b77a4a9b37c7d68c1d69270dd/scripts/debbisect#L113 > > > > > > But why add it to mmdebstrap? That just adds additional complexity and > > > feature > > > creep. It makes an already complex tool even more complex. Why not keep > > > this > > > functionality in an additional piece of software? > > > > > > Please convince me. > > > > I'm definitely not proposing integrating a caching proxy of any kind > > into mmdebstrap; that should absolutely be a separate piece of software. > > But a caching proxy doesn't solve the problem for me. Using a caching > > proxy would require one or both of: > > - Using http, rather than https > > - Configuring the target system to use the proxy directly in its config > > > > What I was hoping to see integrated into mmdebstrap would be support for > > just directly copying the relevant files into the target's > > /var/cache/apt, where apt could use them rather than re-downloading > > them. Such files could either come from the host system's > > /var/cache/apt, or from a directory given to mmdebstrap as a > > command-line option (where the latter would also allow mmdebstrap to > > store files from the target's /var/cache/apt before deleting them). > > > > I'm hoping that has the right combination of "sufficiently narrowly > > scoped" and "requires integration" to make sense as a part of > > mmdebstrap. > > so... you want something like this: > > $ mmdebstrap --customize-hook='sync-out /var/cache/apt/archives ./cache' > unstable /dev/null > $ mmdebstrap --variant=apt --setup-hook='mkdir -p > "$1"/var/cache/apt/archives' --setup-hook='sync-in ./cache > /var/cache/apt/archives' unstable output.tar > > The first command fills your local directory "./cache" with the contents of > /var/cache/apt/archives from the first run while the second invocation gets > the > contents from that directory and thus is able to operate a bit faster. By the time customize-hook runs, mmdebstrap has already cleared /var/cache/apt/archives, so there's nothing to copy out. (Also, I'd prefer to use hardlinks, to avoid making unnecessary copies.) And it appears that copying the cache in via setup-hook does not end up taking effect; either something is clearing/invalidating the cache by the time apt runs, or apt isn't using it. I'd be happy to do this with hooks, but at the moment, I don't see a way to do so successfully.
Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.
On 14.06.20 17:20, Philipp Kern wrote:
> On 11.05.20 11:53, Winfried Münch wrote:
>> package: s390-tools
>>
>> Version: current Installer from 04.05.2020 21:14
>> http://ftp.halifax.rwth-aachen.de/debian/dists/buster/main/installer-s390x/current/images/generic/
>>
>>
>> When I install debian I run in this Problem (from console 4):
>>
>> May 11 09:43:43 debootstrap: Errors were encountered while processing:
>> May 11 09:43:43 debootstrap: s390-tools
>> May 11 09:43:44 debootstrap: dpkg: dependency problems prevent
>> configuration of s390-tools:
>> May 11 09:43:44 debootstrap: s390-tools depends on perl:any.
>> May 11 09:43:44 debootstrap:
>> May 11 09:43:44 debootstrap: dpkg: error processing package s390-tools
>> (--configure):
>> May 11 09:43:44 debootstrap: dependency problems - leaving unconfigured
>>
>> Installation failed in step install base system.
>
> perl:any is not part of the transitive closure that debootstrap
> calculates. To me it looks like a bug in debootstrap in that it does not
> find a deb to download because it does not drop the :any - either in
> pkgdetails or before.
>
> This was presumably broken by 2.3.0-1 which packaged ziomon and included
> a ${perl:Depends} on the main package as well - possibly because Lintian
> alerted about the missing dependency. That was technically correct, as
> it includes binaries that require modules from perl rather than
> perl-base. And it would presumably have worked if "perl:any" had instead
> been substituted as "perl".
>
> It's pretty telling how late this was discovered, sort of pointing out
> that Debian s390x has no users at all if that kind of bug slips into a
> stable release. Ubuntu forked the base tooling and thus was not
> affected. To be honest, that tells me that the port should be demoted
> and not be part of the next release. Especially given the lack of
> (motivated) porters.
The good news is that with Debian stable 10.6 that was released today
the installation actually works again and I was able to conduct a
successful one from within z/VM.
Kind regards
Philipp Kern
signature.asc
Description: OpenPGP digital signature
Bug#971048: samba: CVE-2020-1472
Source: samba Version: 2:4.12.5+dfsg-3 Severity: grave Tags: security upstream fixed-upstream Justification: user security hole Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=14497 X-Debbugs-Cc: car...@debian.org, Debian Security Team Control: found -1 2:4.9.5+dfsg-5+deb10u1 Control: found -1 2:4.9.5+dfsg-5 Control: found -1 2:4.5.16+dfsg-1+deb9u2 Control: found -1 2:4.5.16+dfsg-1 Hi, The following vulnerability was published for samba. CVE-2020-1472[0]: | An elevation of privilege vulnerability exists when an attacker | establishes a vulnerable Netlogon secure channel connection to a | domain controller, using the Netlogon Remote Protocol (MS-NRPC), aka | 'Netlogon Elevation of Privilege Vulnerability'. I realize that setting the RC severity might be disputed, given by default since 4.8 versions are not 'vulnerable' unless admins have switched to 'server schannel = no' or 'server schannel = auto' from the default. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-1472 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1472 [1] https://bugzilla.samba.org/show_bug.cgi?id=14497 [2] https://www.openwall.com/lists/oss-security/2020/09/17/2 [3] https://www.samba.org/samba/security/CVE-2020-1472.html Regards, Salvatore
Bug#971047: wordpress: permalinks fails if wordpress sites have different url prefix paths
Package: wordpress
Version: 5.5.1+dfsg1-1
Severity: normal
Debian wordpress allows for multiple instances of wordpress to be served
from the same box by using config fragments in /etc/wordpress/config-.php
However, /usr/share/wordpress/.htaccess is not fragmented. This is
a problem because permalinks, when enabled places the prefix base into
the htaccess file. So the htaccess file for http://blog.example.com/
is
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
But the htaccess for http://www.example.com/my/site is
RewriteEngine On
RewriteBase /my/site
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /my/site/index.php [L]
Which are completely incompatible, only one or other can work.
There is actually a compatible .htaccess way of doing this, which is
to eliminate the absolute path and use the ability of apache 2.4.16+
to use Alias relative htaccss rewrites, so the .htaccess file
supporting both URLs becomes
RewriteEngine On
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]
This still has the bug that all sites or none must use permalinks, but
at least it allows multiple sites with different prefix directories.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 5.8.0-2-686 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages wordpress depends on:
ii apache2 [httpd] 2.4.46-1
ii ca-certificates 20200601
ii libapache2-mod-php 2:7.4+76
ii libapache2-mod-php5 5.6.30+dfsg-0+deb8u1
ii libapache2-mod-php7.4 [libapache2-mod-php] 7.4.9-2
ii libjs-cropper 1.2.2-1
ii libjs-underscore1.9.1~dfsg-1
ii mysql-client-5.6 [virtual-mysql-client] 5.6.30-1
ii php 2:7.4+76
ii php-gd 2:7.4+76
ii php-getid3 1.9.20+dfsg-1
ii php55.6.30+dfsg-0+deb8u1
ii php5-gd 5.6.30+dfsg-0+deb8u1
ii php5-mysql 5.6.30+dfsg-0+deb8u1
ii php7.4 [php]7.4.9-2
ii php7.4-gd [php-gd] 7.4.9-2
ii php7.4-mysql [php-mysqlnd] 7.4.9-2
Versions of packages wordpress recommends:
ii wordpress-l10n5.5.1+dfsg1-1
ii wordpress-theme-twentytwenty 5.5.1+dfsg1-1
Versions of packages wordpress suggests:
ii mysql-server-5.6 [virtual-mysql-server] 5.6.30-1
pn php-ssh2
-- Configuration Files:
/etc/wordpress/htaccess changed [not included]
-- no debconf information
Bug#971046: ITP: golang-github-kelvins-sunrisesunset -- Go package that provides the sunrise and sunset equation. (library)
Package: wnpp Severity: wishlist Owner: Arun Kumar Pariyar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: golang-github-kelvins-sunrisesunset Version : 1.0-1 Upstream Author : Kelvin S. do Prado * URL : https://github.com/kelvins/sunrisesunset * License : Expat Programming Lang: Go Description : Go package that provides the sunrise and sunset equation. (library) This package is used to calculate the apparent sunrise and sunset times based on latitude, longitude, date and UTC offset. It was created based on the Corrected Sunrise, Sunset, Noon Times in Seconds - and Solar Angles Matlab function developed by Richard Droste, that was created based on the spreadsheets available in the Earth System Research Laboratory website from the National Oceanic & Atmospheric Administration (NOAA).
Bug#971044: iputils-ping: ping reports socket error when IPv6 is disabled
Package: iputils-ping Version: 3:20200821-2 Severity: normal X-Debbugs-Cc: zbynek.mi...@gmail.com Dear Maintainer, After iputils-ping upgrade to the recent version (3:20200821-2) I can see this error message when trying to ping any IPv4 address. # ping -c 1 127.0.0.1 ping: socket: Address family not supported by protocol PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.041 ms --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.041/0.041/0.041/0.000 ms It seems that it is because ping tries to open an IPv6 socket: # strace ping -c 1 127.0.0.1 2>&1 | grep 'AF_INET6' socket(AF_INET6, SOCK_DGRAM, IPPROTO_ICMPV6) = -1 EAFNOSUPPORT (Address family not supported by protocol) I have IPv6 disabled in my system (by ipv6.disable=1 kernel option), so I would expect ignoring the IPv6 stuff at all (even without using "-4" ping parameter explicitly). I did not see this behaviour in the previous ping version. Regards Zbynek -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=cs_CZ.utf8, LC_CTYPE=cs_CZ.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages iputils-ping depends on: ii libc62.31-3 ii libcap2 1:2.43-1 ii libcap2-bin 1:2.43-1 ii libidn2-02.3.0-1 iputils-ping recommends no packages. iputils-ping suggests no packages. -- no debconf information
Bug#971043: ITP: gap-fga -- GAP FGA - Free Group Algorithms
Package: wnpp Severity: wishlist Owner: Joachim Zobel X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gap-fga Version : 1.4.0 Upstream Author : Christian Sievers * URL : http://www.gap-system.org/Packages/fga.html * License : GPL2+ Programming Lang: GAP 4 Description : GAP FGA - Free Group Algorithms The FGA package installs methods for computations with finitely generated subgroups of free groups and provides a presentation for their automorphism groups. This is a dependency for gap-hap. I am working on packaging this (see #968545).
Bug#971042: ITP: golang-github-dkolbly-wl -- Golang wayland protocol implementation. (library)
Package: wnpp Severity: wishlist Owner: Arun Kumar Pariyar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: golang-github-dkolbly-wl Version : 0.0~git20180220.b06f57e-1 Upstream Author : Donovan Kolbly * URL : https://github.com/dkolbly/wl * License : BSD-2-clause Programming Lang: Go Description : Golang wayland protocol implementation. (library) This package is a Go implementation of the Wayland protocol. The protocol files themselves (client.go and xdg/shell.go) are built using the tool in github.com/dkolbly/wl-scanner from the XML protocol specification files.
Bug#958910: debci: 'debci setup -a armhf' fails to set up an lxc container on an amd64 host
> Does networking work in n ative plain lxc container? Networking works with plain native containers as is does with debci generated native ones. root@e580sg:~# lxc-start -n amd64 root@e580sg:~# lxc-attach -n amd64 root@amd64:~# LANG=C apt update Get:1 http://security.debian.org stable/updates InRelease [65.4 kB] Hit:2 http://deb.debian.org/debian stable InRelease Get:3 http://deb.debian.org/debian stable/main Translation-en [5968 kB] Get:4 http://security.debian.org stable/updates/main amd64 Packages [233 kB] Get:5 http://security.debian.org stable/updates/main Translation-en [125 kB] Fetched 6392 kB in 5s (1329 kB/s) Reading package lists... Done Building dependency tree... Done All packages are up to date. root@amd64:~# exit exit root@e580sg:~# lxc-stop -n amd64 Note: lxc-stop terminates quickly and without any error message. > What does your/etc/lxc/default.conf look like? lxc.net.0.type = veth lxc.net.0.link = br0 lxc.net.0.flags = up lxc.apparmor.profile = generated lxc.apparmor.allow_nesting = 1 Sven signature.asc Description: This is a digitally signed message part
Bug#971041: gnome-shell-extension-hard-disk-led: incompatible with GNOME Shell 3.38
Package: gnome-shell-extension-hard-disk-led Version: 19-1 Severity: grave Tags: upstream bullseye sid Justification: renders package unusable in unstable (as of today) Control: block 969321 by -1 This extension doesn't seem to be compatible with Shell 3.38 (coming soon to an unstable mirror near you, or already available in experimental). It fails to load with this traceback: JS ERROR: Extension harddisk...@bijidroid.gmail.com: Error: No property x_fill on StBin init@/usr/share/gnome-shell/extensions/harddisk...@bijidroid.gmail.com/extension.js:32:14 _callExtensionInit@resource:///org/gnome/shell/ui/extensionSystem.js:428:50 loadExtension@resource:///org/gnome/shell/ui/extensionSystem.js:345:27 _loadExtensions/<@resource:///org/gnome/shell/ui/extensionSystem.js:586:18 collectFromDatadirs@resource:///org/gnome/shell/misc/fileUtils.js:27:28 _loadExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:565:19 _enableAllExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:595:18 _sessionUpdated@resource:///org/gnome/shell/ui/extensionSystem.js:626:18 init@resource:///org/gnome/shell/ui/extensionSystem.js:56:14 _initializeUI@resource:///org/gnome/shell/ui/main.js:269:22 start@resource:///org/gnome/shell/ui/main.js:159:5 @:1:47 If this is not straightforward to fix, then the extension should be removed from testing when GNOME 3.38 migrates. Regards, smcv
Bug#971040: gnome-shell-extension-easyscreencast: please test with GNOME Shell 3.38 and update dependency
Package: gnome-shell-extension-easyscreencast Version: 1.1.0-2 Severity: grave Justification: renders package unusable Control: block 969321 by -1 GNOME Shell 3.38 is on its way into unstable, which makes gnome-shell-extension-easyscreencast uninstallable. Please test with GNOME Shell 3.38, and if possible upload a version that is compatible. If it isn't possible to make this extension compatible, then this extension will need to be removed from testing to let the new GNOME release migrate. A new version 1.2.0 seems to be available upstream. I don't know whether it will work with 3.38, but it seems more likely than 1.1.0. Thanks, smcv
Bug#971038: budgie-desktop: please build against libmutter-7-dev in unstable
Source: budgie-desktop Version: 10.5.1+git20200715-2 Severity: important Control: block 969321 by -1 Please upload a version of budgie-desktop to unstable that builds with libmutter-7-dev. The version in experimental seems suitable. Someone from the GNOME team might be able to NMU it if you're too busy. If you're happy for a NMU to go ahead with no further delay, please let us know so we can keep this transition moving. Thanks, smcv
Bug#971039: should handle manpage symlinks
Package: debhelper Severity: wishlist Hi, a lot of packages have manpages and symlinks to manpages in case a manpage handles multiple things that need explaining. This needs to be manually handled in the "debian/manpages" and "debian/links" files. If a symlink is listed in debian/manpage file symlink is followed and the file copied. Would it be possible do change dh_installman's logic to the following: - first copy all plain files listed in debian/manpages - then iterate though all symlinks in debian/manpages - if the target exists in the target directory, make a symlink - otherwise, copy the file This would save package maintainers from a lot of busy work, and is fully backwards compatible. Thanks for considering this. Greetings Marc -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.11-zgsrv20080 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debhelper depends on: pn autotools-dev pn dh-autoreconf pn dh-strip-nondeterminism ii dpkg 1.20.5 ii dpkg-dev 1.20.5 pn dwz ii file 1:5.38-5 pn libdebhelper-perl ii libdpkg-perl 1.20.5 ii man-db 2.9.3-2 ii perl 5.30.3-4 pn po-debconf debhelper recommends no packages. Versions of packages debhelper suggests: pn dh-make
Bug#971037: lbreakout2: Random pauses in the game
Package: lbreakout2 Version: 2.6.5a-1.1 Severity: important X-Debbugs-Cc: bitfreak25 The game pauses randomly. I can only play it if I have the "p" key in reach. In window mode, once it pauses the first time (e.g. the mouse leaves the window) I cannot restart, it switches to pause immediately again. In fullscreen mode it works slightly better as I can play something between a few seconds and 20-30 seconds without pausing. The description in the long closed bug 916606 fits it quite accurately, maybe that bug needs to be reopened and this one merged? If you need further information, like running in gdb etc., please let me know. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lbreakout2 depends on: ii lbreakout2-data 2.6.5a-1.1 ii libc62.31-3 ii libpng16-16 1.6.37-3 ii libsdl-mixer1.2 1.2.12-16+b1 ii libsdl1.2debian 1.2.15+dfsg2-5 ii zlib1g 1:1.2.11.dfsg-2 lbreakout2 recommends no packages. lbreakout2 suggests no packages. -- no debconf information -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#971036: debhelper: dh_missing error due to usr/share/info/dir
Package: debhelper Severity: minor (Credit to "zwol" who mentioned this issue on IRC) Some upstreams install "usr/share/info/dir", which Debian deliberately ignores because 1) it needs to be regenerated on the target system and 2) it would cause file conflicts. However, we can end up in a situation where dh_missing complains about even though dh_installinfo has been run: """ dh_missing: warning: usr/share/info/dir exists in debian/tmp but is not installed to anywhere dh_missing: error: missing files, aborting """ In this case, we can trivially abuse dh_installinfo to tag usr/share/info/dir as "handled" to avoid errors and avoid people having to think about it. Thanks, ~Niels
Bug#971035: RFS: tnftp/20200705-1 -- enhanced ftp client
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "tnftp": * Package name : tnftp Version : 20200705-1 Upstream Author : Luke Mewburn * URL : http://en.wikipedia.org/wiki/Tnftp * License : Unlicense * Vcs : [fill in URL of packaging vcs] Section : net It builds those binary packages: tnftp - enhanced ftp client To access further information about this package, please visit the following URL: https://mentors.debian.net/package/tnftp/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/t/tnftp/tnftp_20200705-1.dsc Changes since the last upload: tnftp (20200705-1) unstable; urgency=medium . [ 肖盛文 ] * New upstream version 20200705 Regards, -- 肖盛文 xiao sheng wen Faris Xiao 微信(wechat)：atzlinux 《铜豌豆 Linux》 基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com GnuPG Public Key: 0x339240CB signature.asc Description: OpenPGP digital signature
Bug#971034: libpfm4 FTCBFS: misdetects some architectures
Source: libpfm4 Version: 4.10.1+git44-ga2909cd-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs libpfm4 is already quite well prepared for cross compilation. Unfortunately, the ARCH= flag is not passed for every architectures. For some such as s390x is missing and there it fails to build. Please consider applying the attached patch to always pass it. Helmut diff --minimal -Nru libpfm4-4.10.1+git44-ga2909cd/debian/changelog libpfm4-4.10.1+git44-ga2909cd/debian/changelog --- libpfm4-4.10.1+git44-ga2909cd/debian/changelog 2020-03-08 14:23:00.0 +0100 +++ libpfm4-4.10.1+git44-ga2909cd/debian/changelog 2020-09-26 18:14:34.0 +0200 @@ -1,3 +1,10 @@ +libpfm4 (4.10.1+git44-ga2909cd-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Pass ARCH= for any architecture. (Closes: #-1) + + -- Helmut Grohne Sat, 26 Sep 2020 18:14:34 +0200 + libpfm4 (4.10.1+git44-ga2909cd-1) unstable; urgency=medium * New upstream GIT snapshot. diff --minimal -Nru libpfm4-4.10.1+git44-ga2909cd/debian/rules libpfm4-4.10.1+git44-ga2909cd/debian/rules --- libpfm4-4.10.1+git44-ga2909cd/debian/rules 2020-03-08 14:23:00.0 +0100 +++ libpfm4-4.10.1+git44-ga2909cd/debian/rules 2020-09-26 18:12:05.0 +0200 @@ -16,12 +16,12 @@ # architecture mapping $(DEB_HOST_ARCH) => libpfm4 ARCH # in case that can't be derived from the cpu correctly # e.g. cross-compiling for a 32-bit architecture on a 64-bit cpu +LIBPFM4_ARCH_amd64 = x86_64 LIBPFM4_ARCH_armel = arm LIBPFM4_ARCH_armhf = arm -LIBPFM4_ARCH_i386 = i386 LIBPFM4_ARCH_ppc64el= powerpc -LIBPFM4_ARCH_FLAG = $(foreach a,$(strip $(LIBPFM4_ARCH_$(DEB_HOST_ARCH))),ARCH=$a) +LIBPFM4_ARCH_FLAG = ARCH=$(or $(LIBPFM4_ARCH_$(DEB_HOST_ARCH_CPU)),$(DEB_HOST_ARCH_CPU)) %: dh $@
Bug#970520:
Oh, many thanks Davide! (At least *someone* cares...) I can start and play the game that way.
Bug#958910: debci: 'debci setup -a armhf' fails to set up an lxc container on an amd64 host
On Sat, Sep 26, 2020 at 04:09:34PM +0200, Sven Geuer wrote: > Further tests show that networking does not seem to work: > > root@e580sg:~# lxc-start -n armhf > root@e580sg:~# lxc-attach -n armhf > root@armhf:~# LANG=C apt update > Err:1 http://security.debian.org stable/updates InRelease > Temporary failure resolving 'security.debian.org' > Err:2 http://deb.debian.org/debian stable InRelease > Temporary failure resolving 'deb.debian.org' > Reading package lists... Done > Building dependency tree... Done > All packages are up to date. > W: Failed to fetch http://deb.debian.org/debian/dists/stable/InRelease > Temporary failure resolving 'deb.debian.org' > W: Failed to fetch > http://security.debian.org/dists/stable/updates/InRelease Temporary > failure resolving 'security.debian.org' > W: Some index files failed to download. They have been ignored, or old > ones used instead. > root@armhf:~# exit > exit > root@e580sg:~# lxc-stop -n armhf > lxc-stop: armhf: commands_utils.c: lxc_cmd_sock_rcv_state: 72 Resource > temporarily unavailable - Failed to receive message Does networking work in n ative plain lxc container? What does your /etc/lxc/default.conf look like? signature.asc Description: PGP signature
Bug#969768: lib-io-socket-ip-perl: do not release with bullseye
Control: tag -1 + pending On Mon, 07 Sep 2020 23:50:03 +0100, Dominic Hargreaves wrote: > IO-Socket-IP is bundled with perl 5.30, so there is no need to ship > this separately. IO-Socket-IP 0.41 has been released, without the patch for #964902 but with some other changes: https://metacpan.org/pod/IO::Socket::IP IO::Socket::IP 0.41 is bundled with perl ony starting with v5.33.2, which won't be in Debian any time soon. I guess we should update libio-socket-ip-perl to 0.41 and close this bug with the upload (and close #969967 in libtest-tcp-perl as well). I've pushed libio-socket-ip-perl_0.41-1 to git but wanted to give others a chance to comment before the actual upload. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Status Quo: Anniversary Waltz Part 2 (Medley) signature.asc Description: Digital Signature
Bug#971021: okular: page up and down with annoying animation
Package: okular Version: 4:20.08.1-1 Severity: wishlist Tags: upstream Dear Maintainer, scrolling through documents with page up/page down is animated by gradually trasition to the previous/next page. I find it very annoying and wish to be able to use the older behavior when okular just jumped one page backward/forward like mupdf. -- System Information: Debian Release: bullseye/sid Versions of packages okular depends on: ii kinit 5.70.0-1 ii kio 5.70.1-1 ii libc6 2.31-3 ii libfreetype6 2.10.2+dfsg-3 ii libjpeg62-turbo 1:2.0.5-1.1 ii libkf5activities5 5.70.0-1 ii libkf5archive55.70.0-1 ii libkf5bookmarks5 5.70.0-1 ii libkf5codecs5 5.70.0-1 ii libkf5completion5 5.70.0-1 ii libkf5configcore5 5.70.0-1 ii libkf5configgui5 5.70.0-1 ii libkf5configwidgets5 5.70.0-2 ii libkf5coreaddons5 5.70.0-2 ii libkf5crash5 5.70.0-1 ii libkf5i18n5 5.70.0-1 ii libkf5iconthemes5 5.70.0-1 ii libkf5itemviews5 5.70.0-1 ii libkf5jobwidgets5 5.70.0-1 ii libkf5kexiv2-15.0.0 20.04.3-1 ii libkf5kiocore55.70.1-1 ii libkf5kiowidgets5 5.70.1-1 ii libkf5parts5 5.70.0-1 ii libkf5pty55.70.0-1 ii libkf5purpose-bin 5.70.0-2 ii libkf5purpose55.70.0-2 ii libkf5service-bin 5.70.0-1 ii libkf5service55.70.0-1 ii libkf5textwidgets55.70.0-1 ii libkf5wallet-bin 5.70.0-1 ii libkf5wallet5 5.70.0-1 ii libkf5widgetsaddons5 5.70.0-1 ii libkf5windowsystem5 5.70.0-1 ii libkf5xmlgui5 5.70.0-1+b1 ii libokular5core9 4:20.08.1-1 ii libphonon4qt5-4 4:4.11.1-3 ii libpoppler-qt5-1 20.09.0-2 ii libqca-qt5-2 2.3.1-1 ii libqmobipocket2 4:20.04.3-1 ii libqt5core5a 5.14.2+dfsg-6 ii libqt5dbus5 5.14.2+dfsg-6 ii libqt5gui55.14.2+dfsg-6 ii libqt5printsupport5 5.14.2+dfsg-6 ii libqt5svg55.14.2-2 ii libqt5texttospeech5 5.14.2-2 ii libqt5widgets55.14.2+dfsg-6 ii libqt5xml55.14.2+dfsg-6 ii libspectre1 0.2.9-1 ii libstdc++610.2.0-9 ii phonon4qt54:4.11.1-3 ii zlib1g1:1.2.11.dfsg-2 Versions of packages okular recommends: pn cups-bsd Versions of packages okular suggests: ii ghostscript9.52.1~dfsg-1 ii okular-extra-backends 4:20.08.1-1 ii poppler-data 0.4.9-2 ii texlive-binaries 2020.20200327.54578-4+b1 -- no debconf information -- signature.asc Description: PGP signature
Bug#971032: New upstream dev release available
Package: wine-development Version: 5.5-5 Severity: wishlist The current development package is a bit lagging against upstream. Upstream's wine-development is at 5.18.
Bug#971031: ITP: gensio -- A library to abstract stream I/O like serial port, TCP, telnet, UDP, SSL, IPMI SOL
Package: wnpp Severity: wishlist Owner: Marc Haber X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gensio Version : 2.1.5 Upstream Author : Corey Minyard * URL : https://github.com/cminyard/gensio/releases * License : GPL2 Programming Lang: C Description : A library to abstract stream I/O like serial port, TCP, telnet, UDP, SSL, IPMI SOL This library (pronounced gen'-see-oh) is a framework for giving a consistent view of various stream (and packet) I/O types. You create a gensio object (or a gensio), and you can use that gensio without having to know too much about what is going on underneath. You can stack gensio on top of another one to add protocol funcionality. For instance, you can create a TCP gensio, stack SSL on top of that, and stack Telnet on top of that. It supports a number of network I/O and serial ports. Gensio can be used for sending and receiving ports, and it also supports establishing encrypted and authenticated connections. The package is needed as a dependency of the current version of ser2net, the serial port to network proxy. I plan to maintain it myself, I am a DD, will accept co-maintainers and have the repository hosted on Salsa in https://salsa.debian.org/debian/gensio
Bug#958910: debci: 'debci setup -a armhf' fails to set up an lxc container on an amd64 host
Further tests show that networking does not seem to work: root@e580sg:~# lxc-start -n armhf root@e580sg:~# lxc-attach -n armhf root@armhf:~# LANG=C apt update Err:1 http://security.debian.org stable/updates InRelease Temporary failure resolving 'security.debian.org' Err:2 http://deb.debian.org/debian stable InRelease Temporary failure resolving 'deb.debian.org' Reading package lists... Done Building dependency tree... Done All packages are up to date. W: Failed to fetch http://deb.debian.org/debian/dists/stable/InRelease Temporary failure resolving 'deb.debian.org' W: Failed to fetch http://security.debian.org/dists/stable/updates/InRelease Temporary failure resolving 'security.debian.org' W: Some index files failed to download. They have been ignored, or old ones used instead. root@armhf:~# exit exit root@e580sg:~# lxc-stop -n armhf lxc-stop: armhf: commands_utils.c: lxc_cmd_sock_rcv_state: 72 Resource temporarily unavailable - Failed to receive message signature.asc Description: This is a digitally signed message part
Bug#932431: DDPO: package removed from experimental but still shown in DDPO column
Dear Mattia, I also met this issue on a few packages I uploaded [2]: - golang-golang-x-xerrors - golang-github-google-go-github - golang-go.crypto [2] https://qa.debian.org/developer.php?login=rosh >> I have noticed that the package 'golang-github-jinzhu-inflection' is >> still listed in the experimental column of my DDPO page [1] but it has >> in the meantime been superseded by a newer version in testing. rmadison >> also shows this package to no longer be in experimental: > > As a data point, that package is listed there in the version of > 0.0~git20170102.0.1c35d90-2, which indeed is listed in the experimental > Sources index as ESO. So what's ESO? How can I check the ESO status for a specific package? > So it might just be that whatever in DDPO is in charge of cleaning up > disappearing sources doesn't do the job if the source is left there as > ESO. So what do you suggest to solve this issue? Thanks! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#971030: soapysdr, libaudioSupport: libarmmem-${PLATFORM}.so => libarmmem-v7l.so
Package: soapysdr0.6-module-audio
Version: 0~git20160607-3
On a Pi: Found a strange link, with name brackets, when exec ldd.
$ ldd /usr/lib/arm-linux-
gnueabihf/SoapySDR/modules0.6/libaudioSupport.so
linux-vdso.so.1 (0xbefe5000)
/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-
linux-gnueabihf/libarmmem-v7l.so (0xb6f51000)
libhamlib.so.2 => /usr/lib/arm-linux-gnueabihf/libhamlib.so.2
(0xb6ca4000)
Thanks,
--
Frans van Berckel
Media Engineer / Linux Master
LinkedIn: https://www.linkedin.com/in/fransvberckel/
Bug#958910: debci: 'debci setup -a armhf' fails to set up an lxc container on an amd64 host
Hello Antonio, > e.g. does this work: > > sudo lxc-create --template=debian --name=armhf -- --arch=armhf > sudo lxc-start --name=armhf > sudo lxc-attach --name=armhf > > ? It seems to work in some way. But there are some errors at the end of the installation process. Also, lxc-stop takes several seconds to complete and it comes back with an error. Here's the relevant output: root@e580sg:~# lxc-create --template=debian --name=armhf -- -- arch=armhf debootstrap ist /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-stable-armhf ... Downloading debian minimal ... I: Target architecture can be executed I: Retrieving InRelease I: Checking Release signature I: Valid Release signature (key id 6D33866EDD8FFA41C0143AEDDCC9EFBF77E11517) I: Retrieving Packages I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Checking component main on http://deb.debian.org/debian... [...] I: Base system installed successfully. Download complete. Copying rootfs to /var/lib/lxc/armhf/rootfs...Generating locales (this might take a while)... de_DE.UTF-8... done de_DE.UTF-8... done Generation complete. update-rc.d: error: cannot find a LSB script for checkroot.sh update-rc.d: error: cannot find a LSB script for umountfs Failed to disable unit, unit hwclock.sh.service does not exist. update-rc.d: error: cannot find a LSB script for hwclockfirst.sh Creating SSH2 RSA key; this may take some time ... 2048 SHA256:eyTvbzzRV0YzdRVk9sFLWp9dzK0nRuUPgN2k6QMpkMY root@e580sg (RSA) Creating SSH2 ECDSA key; this may take some time ... 256 SHA256:CfbEORbaL5SptfEnhIQDdg3M/3tNkRPX1mkL5FwUyOE root@e580sg (ECDSA) Creating SSH2 ED25519 key; this may take some time ... 256 SHA256:rGf9JbAsSf8Go+5CZGLQH5Vag4reEEey/PjEWfVl8Vg root@e580sg (ED25519) invoke-rc.d: could not determine current runlevel invoke-rc.d: policy-rc.d denied execution of start. Current default time zone: 'Etc/UTC' Local time is now: Sat Sep 26 13:31:23 UTC 2020. Universal Time is now: Sat Sep 26 13:31:23 UTC 2020. root@e580sg:~# lxc-start --name=armhf root@e580sg:~# lxc-attach --name=armhf root@armhf:~# uname -a Linux armhf 5.8.0-2-amd64 #1 SMP Debian 5.8.10-1 (2020-09-19) armv7l GNU/Linux root@armhf:~# exit exit root@e580sg:~# lxc-stop --name=armhf lxc-stop: armhf: commands_utils.c: lxc_cmd_sock_rcv_state: 72 Resource temporarily unavailable - Failed to receive message Hope this helps. Sven signature.asc Description: This is a digitally signed message part
Bug#971029: rakudo 2020.08.2-1 breaks perl6-* modules
Package: rakudo
Version: 2020.08.2-1
Followup-For: Bug #969578
Dear Maintainer,
Adding on to what's already reported, it seems that the installed
rakudo comes without any of the core modules mentioned in
https://docs.raku.org/language/modules-core:
: ; rakudo -e 'use CompUnit::Repository::Staging'
===SORRY!=== Error while compiling -e
Could not find CompUnit::Repository::Staging in:
inst#/home/levitte/.raku
inst#/usr/share/perl6/site
inst#/usr/share/perl6/vendor
inst#/usr/share/perl6/core
ap#
nqp#
perl5#
at -e:1
: ; rakudo -e 'use CompUnit::Repository::Perl6'
===SORRY!=== Error while compiling -e
Could not find CompUnit::Repository::Perl6 in:
inst#/home/levitte/.raku
inst#/usr/share/perl6/site
inst#/usr/share/perl6/vendor
inst#/usr/share/perl6/core
ap#
nqp#
perl5#
at -e:1
: ; rakudo -e 'use CompUnit::Repository::RepositoryRegistry'
===SORRY!=== Error while compiling -e
Could not find CompUnit::Repository::RepositoryRegistry in:
inst#/home/levitte/.raku
inst#/usr/share/perl6/site
inst#/usr/share/perl6/vendor
inst#/usr/share/perl6/core
ap#
nqp#
perl5#
at -e:1
: ; rakudo -e 'use NativeCall'
===SORRY!=== Error while compiling -e
Could not find NativeCall in:
inst#/home/levitte/.raku
inst#/usr/share/perl6/site
inst#/usr/share/perl6/vendor
inst#/usr/share/perl6/core
ap#
nqp#
perl5#
at -e:1
: ; rakudo -e 'use NativeCall::Types'
===SORRY!=== Error while compiling -e
Could not find NativeCall::Types in:
inst#/home/levitte/.raku
inst#/usr/share/perl6/site
inst#/usr/share/perl6/vendor
inst#/usr/share/perl6/core
ap#
nqp#
perl5#
at -e:1
: ; rakudo -e 'use NativeCall::Compiler::GNU'
===SORRY!=== Error while compiling -e
Could not find NativeCall::Compiler::GNU in:
inst#/home/levitte/.raku
inst#/usr/share/perl6/site
inst#/usr/share/perl6/vendor
inst#/usr/share/perl6/core
ap#
nqp#
perl5#
at -e:1
: ; rakudo -e 'use NativeCall::Compiler::MSVC'
===SORRY!=== Error while compiling -e
Could not find NativeCall::Compiler::MSVC in:
inst#/home/levitte/.raku
inst#/usr/share/perl6/site
inst#/usr/share/perl6/vendor
inst#/usr/share/perl6/core
ap#
nqp#
perl5#
at -e:1
: ; rakudo -e 'use Pod::To::Text'
===SORRY!=== Error while compiling -e
Could not find Pod::To::Text in:
inst#/home/levitte/.raku
inst#/usr/share/perl6/site
inst#/usr/share/perl6/vendor
inst#/usr/share/perl6/core
ap#
nqp#
perl5#
at -e:1
: ; rakudo -e 'use Test'
===SORRY!=== Error while compiling -e
Could not find Test in:
inst#/home/levitte/.raku
inst#/usr/share/perl6/site
inst#/usr/share/perl6/vendor
inst#/usr/share/perl6/core
ap#
nqp#
perl5#
at -e:1
: ; rakudo -e 'use experimental'
===SORRY!=== Error while compiling -e
Could not find experimental in:
inst#/home/levitte/.raku
inst#/usr/share/perl6/site
inst#/usr/share/perl6/vendor
inst#/usr/share/perl6/core
ap#
nqp#
perl5#
at -e:1
: ; rakudo -e 'use newline'
===SORRY!=== Error while compiling -e
Could not find newline in:
inst#/home/levitte/.raku
inst#/usr/share/perl6/site
inst#/usr/share/perl6/vendor
inst#/usr/share/perl6/core
ap#
nqp#
perl5#
at -e:1
Among others, it affects the installation of perl6-zef:
Setting up perl6-zef (0.8.5-2) ...
===SORRY!=== Error while compiling /usr/share/perl6/tools/install-dist.p6
Could not find CompUnit::Repository::Staging in:
inst#/root/.raku
inst#/usr/share/perl6/site
inst#/usr/share/perl6/vendor
inst#/usr/share/perl6/core
ap#
nqp#
perl5#
at /usr/share/perl6/tools/install-dist.p6:35
"perl6 /usr/share/perl6/tools/install-dist.p6
--from=/usr/share/perl6/debian-sources/perl6-zef --to=/tmp/3Sv7EedD5s/build
--for=vendor" unexpectedly returned exit value 1 at
/usr/share/perl5/IPC/System/Simple.pm line 578.
IPC::System::Simple::_check_exit("perl6
/usr/share/perl6/tools/install-dist.p6 --from=/usr/shar"..., 1,
ARRAY(0x55e36f7202e0)) called at /usr/share/perl5/IPC/System/Simple.pm line 550
IPC::System::Simple::_process_child_error(256, "perl6
/usr/share/perl6/tools/install-dist.p6 --from=/usr/shar"...,
ARRAY(0x55e36f7202e0)) called at /usr/share/perl5/IPC/System/Simple.pm line 190
IPC::System::Simple::run("perl6 /usr/share/perl6/tools/install-dist.p6
--from=/usr/shar"...) called at (eval 29) line 12
Bug#942814: libhibernate-validator-java: update to 5.3.6 breaks reverse-dependencies
Am 26.09.20 um 10:27 schrieb Emmanuel Bourg: > On 25/09/2020 13:50, Markus Koschany wrote: > >> Why did you upgrade hibernate-validator to version 5.x when >> no other package in Debian requires it? Wouldn't it have been >> simpler to revert the upgrade instead of creating a separate >> hibernate-validator4 package? > > The version 5.x is a prerequisite to upgrade Spring to the next major > release. Also the version 4.x is no longer supported and security issues > are frequently reported. The idea is to use libhibernate-validator4-java > as a transitional package until all reverse dependencies are updated to > use the version 5.x. That sounds like a sensible reason to upgrade a package. Though when I look closer into the details I find only four reported security vulnerabilities in the past six years. The last two in 2019 and 2020 did only affect the 5.x and later versions specifically which is rather an argument against upgrading hibernate-validator. So the real reason for 5.x is to upgrade Spring which is also fine. However the update has not materialized so far but in the meantime pdfsam was broken in two Ubuntu releases and unstable. I would recommend to upload such a package to experimental first or release it to unstable when the complete work is done. I believe this all could have been avoided if you had outlined your goals beforehand or if you had responded to this bug report in time. Then we both could actually seek for a solution to make this work. The current situation is a bit demotivating though because I don't want to guess why something is broken and I don't want to invest time to clean up the fallout when the key problem is communication. I will switch pdfsam to use libhibernator-validator4-java now but I can only address this problem when libsejda-commons-java has been approved by the ftp team. This may take a while. Markus signature.asc Description: OpenPGP digital signature
Bug#971028: RFS: yadifa/2.3.10-1 -- Internet Domain Name Server
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "yadifa": * Package name: yadifa Version : 2.3.10-1 Upstream Author : yadifa-us...@mailinglists.yadifa.eu * URL : https://www.yadifa.eu * License : EURid-BSD-like, BSD-3-clause, other-BSD * Vcs : https://salsa.debian.org/dns-team/yadifa Section : net It builds those binary packages: libyadifa-dev - development libraries and header files for YADIFA yadifa - Internet Domain Name Server To access further information about this package, please visit the following URL: https://mentors.debian.net/package/yadifa/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_2.3.10-1.dsc Changes since the last upload: yadifa (2.3.10-1) unstable; urgency=medium . * New upstream version 2.3.10 * Drop gcc 10 patch included upstream * Use secure URI in Homepage field. * Remove obsolete field Name from debian/upstream/metadata (already present in machine-readable debian/copyright) Regards, Markus
Bug#971027: vlc: segmentation fault with all video since update to 3.0.11.1-2
Package: vlc
Version: 3.0.11.1-2
Severity: important
Dear Maintainer,
Since update to 3.0.11.1-2 version two days ago, vlc crashes with all videos
with a segmentation fault :
$vlc -vvv I\ Like\ To\ Make\ Stuff-20200920-U.S.\ Navy\ Mobile\ Shelter\
Challenge\ _\ Sailor\ VS-1920x1080.mkv
VLC media player 3.0.11.1 Vetinari (revision 3.0.11.1-0-g52483f3ca2)
[5595ac1b4460] main libvlc debug: VLC media player - 3.0.11.1 Vetinari
[5595ac1b4460] main libvlc debug: Copyright © 1996-2020 the VideoLAN team
[5595ac1b4460] main libvlc debug: revision 3.0.11.1-0-g52483f3ca2
[5595ac1b4460] main libvlc debug: configured with ./configure '--
build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--
mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--
sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-
silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '
--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-debug' '
--config-cache' '--disable-update-check' '--enable-fast-install' '--
docdir=/usr/share/doc/vlc' '--with-binary-version=3.0.11.1-2' '--enable-a52' '
--enable-aa' '--enable-aribsub' '--enable-avahi' '--enable-bluray' '--enable-
caca' '--enable-chromaprint' '--enable-chromecast' '--enable-dav1d' '--enable-
dbus' '--enable-dca' '--enable-dvbpsi' '--enable-dvdnav' '--enable-faad' '--
enable-flac' '--enable-fluidsynth' '--enable-freetype' '--enable-fribidi' '--
enable-gles2' '--enable-gnutls' '--enable-harfbuzz' '--enable-jack' '--enable-
kate' '--enable-libass' '--enable-libmpeg2' '--enable-libxml2' '--enable-lirc'
'--enable-live555' '--enable-mad' '--enable-matroska' '--enable-mod' '--enable-
mpc' '--enable-mpg123' '--enable-mtp' '--enable-ncurses' '--enable-notify' '--
enable-ogg' '--enable-opus' '--enable-pulse' '--enable-qt' '--enable-realrtsp'
'--enable-samplerate' '--enable-sdl-image' '--enable-sftp' '--enable-shine' '--
enable-shout' '--enable-skins2' '--enable-sndio' '--enable-soxr' '--enable-
spatialaudio' '--enable-speex' '--enable-svg' '--enable-svgdec' '--enable-
taglib' '--enable-theora' '--enable-twolame' '--enable-upnp' '--enable-vdpau' '
--enable-vnc' '--enable-vorbis' '--enable-x264' '--enable-x265' '--enable-zvbi'
'--with-kde-solid=/usr/share/solid/actions/' '--disable-aom' '--disable-
crystalhd' '--disable-d3d11va' '--disable-decklink' '--disable-directx' '--
disable-dsm' '--disable-dxva2' '--disable-fdkaac' '--disable-fluidlite' '--
disable-freerdp' '--disable-goom' '--disable-gst-decode' '--disable-libtar' '--
disable-macosx' '--disable-macosx-avfoundation' '--disable-macosx-qtkit' '--
disable-microdns' '--disable-mfx' '--disable-opencv' '--disable-projectm' '--
disable-schroedinger' '--disable-sparkle' '--disable-srt' '--disable-telx' '--
disable-vpx' '--disable-vsxu' '--disable-wasapi' '--enable-alsa' '--enable-
dc1394' '--enable-dv1394' '--enable-libplacebo' '--enable-linsys' '--enable-
nfs' '--enable-udev' '--enable-v4l2' '--enable-wayland' '--enable-libva' '--
enable-vcd' '--enable-smbclient' '--disable-oss' '--enable-mmx' '--enable-sse'
'--disable-neon' '--disable-altivec' '--disable-omxil'
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-
map=/build/vlc-0h6PBx/vlc-3.0.11.1=. -fstack-protector-strong -Wformat
-Werror=format-security ' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-
time -D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fdebug-prefix-
map=/build/vlc-0h6PBx/vlc-3.0.11.1=. -fstack-protector-strong -Wformat
-Werror=format-security ' 'OBJCFLAGS=-g -O2 -fdebug-prefix-
map=/build/vlc-0h6PBx/vlc-3.0.11.1=. -fstack-protector-strong -Wformat
-Werror=format-security'
[5595ac1b4460] main libvlc debug: searching plug-in modules
[5595ac1b4460] main libvlc debug: loading plugins cache file
/usr/lib/x86_64-linux-gnu/vlc/plugins/plugins.dat
[5595ac1b4460] main libvlc debug: recursively browsing
`/usr/lib/x86_64-linux-gnu/vlc/plugins'
[5595ac1b4460] main libvlc debug: plug-ins loaded: 511 modules
[5595ac1b4460] main libvlc debug: opening config file
(/home/sebastien/.config/vlc/vlcrc)
[5595ac1b47b0] main logger debug: looking for logger module matching "any":
4 candidates
[5595ac1b47b0] main logger debug: using logger module "console"
[5595ac1b4460] main libvlc debug: translation test: code is "C"
[5595ac249370] main keystore debug: looking for keystore module matching
"memory": 4 candidates
[5595ac249370] main keystore debug: using keystore module "memory"
[5595ac1b4460] main libvlc debug: CPU has capabilities MMX MMXEXT SSE SSE2
SSE3 SSSE3 SSE4.1 FPU
[5595ac251fe0] main input debug: Creating an input for 'Media Library'
[5595ac251fe0] main input debug: Input is a meta file: disabling unneeded
options
[5595ac251fe0] main input debug: using timeshift granularity of 50 MiB
[5595ac251fe0] main input debug: using default timeshift path
[5595ac251fe0] main input debug:
Bug#958910: debci: 'debci setup -a armhf' fails to set up an lxc container on an amd64 host
On Fri, Sep 25, 2020 at 10:08:40PM +0200, Sven Geuer wrote: > Hello Antonio, > > I have no issue with containers of the native amd64 architecture of my > system. Setting up and using a i386 container also works flawlessly. I > have been using them even before trying to setup a container of a > foreign architecture. > > I seem to have a general issue to setup containers of a foreign > architecture, armhf is a mere example. I repeated a armhf setup. It > keeps failing, while the error looks different now compared to my first > post. It presents itself as a network access error: > > [...] > Running setup script /usr/share/autopkgtest/setup-commands/setup- > testbed... > /usr/bin/sh: Attempting to set up Debian/Ubuntu apt sources > automatically > /usr/bin/sh: Distribution assumed to resemble Debian > Err:1 http://deb.debian.org/debian unstable InRelease > Temporary failure resolving 'deb.debian.org' > Reading package lists... > W: Failed to fetch > http://deb.debian.org/debian/dists/unstable/InRelease Temporary > failure resolving 'deb.debian.org' > [...] > > Please see attach a complete log of the setup run. Hope this helps to > track down what going on. I already knew you couldn't setup a debci container, that's why I asked if you are able to create and start a plain lxc container in a foreign architecture, so we can track down whether the issue is in debci, lxc, or something else that is broken on your end (since it works for me). e.g. does this work: sudo lxc-create --template=debian --name=armhf -- --arch=armhf sudo lxc-start --name=armhf sudo lxc-attach --name=armhf ? signature.asc Description: PGP signature
Bug#971024: transition: botan
Control: tags -1 + confirmed On 2020-09-26 14:50:06 +0200, László Böszörményi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi RMs, > > I would like to update Botan from libbotan-2-13 to libbotan-2-15 in Sid. > Bit complex situation. Transition tracker shows biboumi as the only > reverse dependency. I didn't try to build it with the new Botan as it > fails to build with GCC 10 anyway. For this, an RC bug already exists > and the package was removed from testing some time ago. Last > maintainer upload was over two years ago. Please go ahead. > But Thunderbird also affected, if only the version in experimental. > Build tested it with the new Botan version. Builds correctly, but I > doubt you will binNMU it there. If we know about it, we can schuedle binNMUs for it. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#971026: RFP: amnesia-thedarkdescent -- A survival horror adventure video game
Package: wnpp Severity: wishlist User: pkg-games-de...@lists.alioth.debian.org Usertags: wnpp X-Debbugs-Cc: debian-devel-ga...@lists.debian.org * Package name : amnesia-thedarkdescent Upstream Author : Frictional Games * URL : https://github.com/FrictionalGames/AmnesiaTheDarkDescent * License : GPLv3 Programming Lang: C++ Description : A survival horror adventure video game Amnesia: The Dark Descent is a first-person adventure game with survival horror elements. The player takes control of Daniel, who must navigate Brennenburg Castle while avoiding various dangers and solving puzzles. The gameplay retains the physical object interaction used in the Penumbra series, allowing for physics-based puzzles and interactions such as opening doors and fixing machinery.
Bug#971025: RFP: amnesia-amachineforpigs -- A survival horror adventure video game
Package: wnpp Severity: wishlist User: pkg-games-de...@lists.alioth.debian.org Usertags: wnpp X-Debbugs-Cc: debian-devel-ga...@lists.debian.org * Package name : amnesia-amachineforpigs Upstream Author : Frictional Games * URL : https://github.com/FrictionalGames/AmnesiaAMachineForPigs * License : GPLv3 Programming Lang: C++ Description : A survival horror adventure video game Amnesia: A Machine for Pigs is a first-person adventure game with survival horror elements. Players explore the environments using a lantern, with diary entries and notes providing information on the lost memory of the title character.
Bug#971024: transition: botan
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, I would like to update Botan from libbotan-2-13 to libbotan-2-15 in Sid. Bit complex situation. Transition tracker shows biboumi as the only reverse dependency. I didn't try to build it with the new Botan as it fails to build with GCC 10 anyway. For this, an RC bug already exists and the package was removed from testing some time ago. Last maintainer upload was over two years ago. But Thunderbird also affected, if only the version in experimental. Build tested it with the new Botan version. Builds correctly, but I doubt you will binNMU it there. Thanks, Laszlo/GCS
Bug#971023: Version field (5.6.12) and colons
Package: debian-policy Version: 4.5.0.3 Severity: minor Hi, with regards to colons in version numbers, 5.6.12 states on the "epoch" fragment: "If it is omitted then the upstream_version may not contain any colons." However, this seems superfluous, as it states on the "upstream_version" fragment: "The upstream_version may contain only alphanumerics and the characters . + - ~ (full stop, plus, hyphen, tilde)" Best, Christian
Bug#971022: unblock: src:debian-parl/1.9.25
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please unblock package src:debian-parl [ Reason ] Bug in piuparts: https://alioth-lists.debian.net/pipermail/piuparts-devel/2020-September/009165.html This same issue was already unblocked by Paul Gevers for previous release of debian-parl, as discussed on d-devel@l.d.o: Message-ID: <842301ac-bb3e-f551-6bcd-422a7ebd0...@debian.org> unblock src:debian-parl/1.9.25 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl9vNxgACgkQLHwxRsGg ASEX1g//UPscpilxby5wsQX62Fy8BCPUlpEcz9S6D5qXuCRqTfVv7/rnCRYYeQ3E EpFzVJTyYZh90AOVqSOEqPKOOaXczM5NHWfkS7Uc44DrsGWJNNAdDxc0yONfkTNT iNKiYatwv8RRcSblvb4XcEw5FvNzhHXen8Ofk92MormHlD+XaJPXacR9acykdaH+ eearUMSW7NMhFofh9vSIvSlD9q1zRrocuKQOxDVBN49TVluZr7GXe08ZEbEeszce jHZzgPblf/X2S5O9jIE2KmtPjcpJMKyRW2G1DwT7KEkh9a4lFijTOvOIC0XmDNEe VZ+fhOgXO0h3vb69Zyd7i/HmHEoieKbv/lYMMR8ZFT6wSkpzXMrqjsqF6ydupU2P pbykCsVm0Pdn3g03Nf2qmZlcCAbrpzle/sAb4qk5Gi8edbzLcEAbPu9TCN887RXU 9/5Dn2mi3hs5q2tCqpUtgbO6AM2l3QRiDoP74vJPJHrFN0e4VPwhlCKT8SQw+Nku JJvZZTgpvRmV2TWYSkt1EntVsoFXZyZwlzwGXd2vBVRzYTAo5uymhPfPxJeoUnbm b053ystkLIy4IX9s5zfSSaI9r9BS5NDiVnAyDHVs9FvZsJY+GzmGppxJxvSBAQhC f6rut2JPO2o1HQLg0SArQJm0ms50jTkVz8RLfqh6clgDJtAlfmw= =RP6H -END PGP SIGNATURE-
Bug#968681: [Pkg-javascript-devel] Bug#968681: nodejs: regresses in ppc64el ( node-create-hash, node-crypto-browserify, node-sha.js)
Le sam. 26 sept. 2020 à 14:18, Gianfranco Costamagna < locutusofb...@debian.org> a écrit : > Hello, > > On Wed, 19 Aug 2020 22:39:03 +0200 =?UTF-8?B?SsOpcsOpbXkgTGFs?= < > kapo...@melix.org> wrote: > > Le mer. 19 août 2020 à 21:12, Gianfranco Costamagna < > > locutusofb...@debian.org> a écrit : > > > > > Source: nodejs > > > Version: 12.18.2~dfsg-1 > > > Severity: serious > > > > > > Hello, looks like node-create-hask, node-crypto-browserify, node-sha.js > > > have autopkgtests failures on ppc64el. > > > > > > there might be an upstream patch according to Ubuntu bug [1] and v8 > > > commits > > > > > > > > > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/n/node-crypto-browserify/6740061/log.gz > > > > > > > > > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/n/node-sha.js/6740057/log.gz > > > > > > > > > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/n/node-create-hash/6738537/log.gz > > > > > > > > > the attached diff (based on upstream changes) might help in fixing the > > > failures. > > > > > > [1] > > > > https://bugs.launchpad.net/ubuntu/+source/node-create-hash/+bug/1887144 > > > > > > I just uploaded in Ubuntu, will see in 24h or so if the problem is > fixed > > > or not. > > > > > > > Thanks, i'll apply the patch later this week, then. > > > > Jérémy > > > ping please? > Oops sorry i really thought i dealt with it :( Anyway now this fix has been backported to upstream 12.x and they planned a release in a few days: https://github.com/nodejs/Release/issues/494 Jérémy
Bug#968681: [Pkg-javascript-devel] Bug#968681: nodejs: regresses in ppc64el ( node-create-hash, node-crypto-browserify, node-sha.js)
Hello, On Wed, 19 Aug 2020 22:39:03 +0200 =?UTF-8?B?SsOpcsOpbXkgTGFs?= wrote: > Le mer. 19 août 2020 à 21:12, Gianfranco Costamagna < > locutusofb...@debian.org> a écrit : > > > Source: nodejs > > Version: 12.18.2~dfsg-1 > > Severity: serious > > > > Hello, looks like node-create-hask, node-crypto-browserify, node-sha.js > > have autopkgtests failures on ppc64el. > > > > there might be an upstream patch according to Ubuntu bug [1] and v8 > > commits > > > > > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/n/node-crypto-browserify/6740061/log.gz > > > > > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/n/node-sha.js/6740057/log.gz > > > > > > https://ci.debian.net/data/autopkgtest/unstable/ppc64el/n/node-create-hash/6738537/log.gz > > > > > > the attached diff (based on upstream changes) might help in fixing the > > failures. > > > > [1] > > https://bugs.launchpad.net/ubuntu/+source/node-create-hash/+bug/1887144 > > > > I just uploaded in Ubuntu, will see in 24h or so if the problem is fixed > > or not. > > > > Thanks, i'll apply the patch later this week, then. > > Jérémy ping please? G.
Bug#970901: black: cannot run, "ModuleNotFoundError: No module named '_black_version'"
tags 970901 + patch thanks Hi, > black: cannot run, "ModuleNotFoundError: No module named '_black_version'" The following patch works for me, but there is likely a cleaner solution; seems like the Black package maintainers are doing special things with the version handling and I am missing some nuance. --- a/debian/rules +++ b/debian/rules @@ -16,6 +16,8 @@ export VERSION=$(shell dpkg-parsechangelog -S Version|cut -d- -f1) %: echo "version = '$(VERSION)'" > _black_version.py + mkdir -p src + cp _black_version.py src/ dh $@ --with sphinxdoc,python3 --buildsystem=pybuild override_dh_auto_build: Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-diff --git a/debian/rules b/debian/rules index 09908f4..1a70969 100755 --- a/debian/rules +++ b/debian/rules @@ -16,6 +16,8 @@ export VERSION=$(shell dpkg-parsechangelog -S Version|cut -d- -f1) %: echo "version = '$(VERSION)'" > _black_version.py + mkdir -p src + cp _black_version.py src/ dh $@ --with sphinxdoc,python3 --buildsystem=pybuild override_dh_auto_build:
Bug#970818: mrpt: FTBFS on mipse64el: E: Build killed with signal TERM after 150 minutes of inactivity
On Sat, Sep 26, 2020 at 3:30 AM Scott Talbert wrote: > If you don't mind, please do a new package upload to mentors. Sure! Done here: https://mentors.debian.net/debian/pool/main/m/mrpt/mrpt_2.1.0-2.dsc Best, JL
Bug#971020: ITP: node-rollup-plugin-inject -- Scan modules for global variables and inject import statements
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-de...@lists.debian.org Control: block 970550 by -1 * Package name : node-rollup-plugin-inject Version : 3.0.2 Upstream Author : Rich Harris * URL : https://github.com/rollup/rollup-plugin-inject#readme * License : Expat Programming Lang: JavaScript Description : Scan modules for global variables and inject import statements Newer versions are available as @rollup/plugin-inject but the new version is not yet compatible with rollup-plugin-node-polyfills (which is required for building libjs-autoprefixer, see #970550).
Bug#971019: accidental chaining of debconf commands
Package: cdebconf Version: 0.249 Severity: critical I have a problem with the debian installer, at the finish-install stage in the udeb clock-setup. The following code path produces a strange protocol interaction: if db_fget clock-setup/utc seen && [ "$RET" = true ]; then # keep preseeded value : else probed="" if arch_has_os_needing_local_clock; then # os-prober may not yet be installed... anna-install os-prober-udeb || true probed=$(os-prober) || true if [ -z "$probed" ]; then # installing the only OS, so use UTC db_set clock-setup/utc true pri=low fi fi db_input $pri clock-setup/utc || true if ! db_go; then | exit 10 # back to main menu fi The interaction in the syslog during install (manually copied from screen): finish-install: info: Running /usr/lib/finish-install.d/10clock-setup debconf: --> FGET clock-setup/utc seen debconf: <-- 0 true debconf: --> SET clock-setup/utc true INPUT low clock-setup/utc debconf: <-- 0 value set debconf: --> GO debconf: <-- 0 ok debconf: --> GET clock/setup/utc debconf: <-- 0 true INPUT low clock-setup/utc debconf: --> GET clock-setup/system-time-changed debconf: <-- 0 false finish-install: /usr/lib/finish-install.d/10clock-setup: return: line 46: illegal number: INPUT finish-install: warning: /usr/lib/finish-install.d/10clock-setup returned error code 2 For reproducing the error if that's required: This is a preseeded Debian Buster install on VMWare ESXi, relevant preseed config: ### Clock and timezone setup # Controls whether or not the hardware clock is set to UTC. d-i clock-setup/utc boolean true # You may set this to any valid setting for $TZ; see the contents of # /usr/share/zoneinfo/ for valid values. d-i time/zone string Europe/Amsterdam # Controls whether to use NTP to set the clock during the install d-i clock-setup/ntp boolean true # NTP server to use. The default is almost always fine here. #d-i clock-setup/ntp-server string ntp.example.org I can't really see why this path would be hit, "db_fget clock-setup/utc seen" should return true and this whole thing should be skipped, but somehow that is not how it works out.. and the debconf confmodule just chains 2 commands together without any separation or wait time, causing an error during finish-install, effectively halting all installs. seems like either a clear separator is missing (newline?) or a buffer must be flushed after every SET.. Kind regards, Wilco Baan Hofman
Bug#850644: ITP: guix -- A functional package manager based on Scheme
Hi, Vagrant Cascadian writes: > Last I tried the packaging branch above it did actually work (with the > test suite results ignored), but that was a while ago. "me too". e65c5f7b did build successfully and works as far as I can tell; this is my first taste of guix. (I also use the script mentioned in [1] and did restarted systemd-sysusers once to make the build users available. Not sure if any of this is needed. A pointer to recommended readings would be nice.) Thank you for working on this. Regards, itd [1]: https://wiki.archlinux.org/index.php/Guix#Manual_Installation
Bug#971014: Reproducible bug in inline_data handling with ACL
Adding CC to linux-ext4@. On Sat, Sep 26, 2020 at 01:23:33AM -0700, Josh Triplett wrote: > In the course of creating some filesystems containing Debian > installations using `mke2fs -d`, I managed to find a bug in the > `inline_data` handling, which seems to apply to files containing ACLs. > On a default Debian installation, /var/log/journal triggered this > problem. > > I managed to create a minimal test case. To reproduce: > > mkdir -p target/testdir > setfacl --restore=- < # file: target/testdir/ > user::rwx > group::r-x > group:adm:r-x > mask::r-x > other::r-x > default:user::rwx > default:group::r-x > default:group:adm:r-x > default:mask::r-x > default:other::r-x > EOF > mke2fs -b 4096 -I 256 -O sparse_super2,inline_data,^has_journal -d target > disk.img 8M > > and then run: > > e2fsck -n -f disk.img > > This will show: > > e2fsck 1.46-WIP (03-Oct-2019) > Pass 1: Checking inodes, blocks, and sizes > Inode 12 has INLINE_DATA_FL flag but extended attribute not found. Truncate? > no > > Pass 2: Checking directory structure > Pass 3: Checking directory connectivity > Pass 4: Checking reference counts > Pass 5: Checking group summary information > > disk.img: ** WARNING: Filesystem still has errors ** > > disk.img: 12/2048 files (0.0% non-contiguous), 137/2048 blocks > > > And the kernel ext4 implementation will fail to handle that inode, with > a message like this: > > EXT4-fs error (device loop0): __ext4_iget:4776: inode #3215: block 56: comm > ls: invalid block > > > The size of 8M doesn't matter; the issue reproduces with other sizes. > /etc/mke2fs.conf is unchanged from the defaults. `tune2fs -l disk.img` > shows the following: > > tune2fs 1.46-WIP (03-Oct-2019) > Filesystem volume name: > Last mounted on: > Filesystem UUID: 931e3151-83db-4c33-be5f-655c9323fab4 > Filesystem magic number: 0xEF53 > Filesystem revision #:1 (dynamic) > Filesystem features: ext_attr resize_inode dir_index sparse_super2 > filetype inline_data sparse_super large_file > Filesystem flags: signed_directory_hash > Default mount options:user_xattr acl > Filesystem state: clean > Errors behavior: Continue > Filesystem OS type: Linux > Inode count: 2048 > Block count: 2048 > Reserved block count: 102 > Free blocks: 1911 > Free inodes: 2036 > First block: 0 > Block size: 4096 > Fragment size:4096 > Blocks per group: 32768 > Fragments per group: 32768 > Inodes per group: 2048 > Inode blocks per group: 128 > Filesystem created: Sat Sep 26 00:50:53 2020 > Last mount time: n/a > Last write time: Sat Sep 26 00:50:53 2020 > Mount count: 0 > Maximum mount count: -1 > Last checked: Sat Sep 26 00:50:53 2020 > Check interval: 0 () > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > First inode: 11 > Inode size: 256 > Required extra isize: 32 > Desired extra isize: 32 > Default directory hash: half_md4 > Directory Hash Seed: df46d104-ed26-4cea-ac61-0feff2a54622
Bug#964133: veusz: Please switch from sip4 to sip5
Hi Jeremy! On Thu, Jul 02, 2020 at 01:37:34PM +0300, Dmitry Shachnev wrote: > Please stage your changes in experimental (or in a VCS) for now. They will > need to be uploaded to unstable together with pyqt5. New pyqt5 is in unstable now, so veusz is now broken [1]. The SIP 5 version is prepared in git, can you please upload it now? If you need sponsorship, please ping me. [1]: https://ci.debian.net/data/autopkgtest/testing/amd64/v/veusz/7187977/log.gz -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#971001: Please support caching packages outside the chroot
Hi, Quoting Josh Triplett (2020-09-26 11:03:12) > On Sat, Sep 26, 2020 at 07:28:57AM +0200, Johannes Schauer wrote: > > Quoting Josh Triplett (2020-09-26 06:28:18) > > > mmdebstrap seems to re-download packages every time it runs. I'd love to > > > have > > > a way to cache those packages, so that it can run substantially faster the > > > second and subsequent times. > > > > Do one thing and do it well. > > > > I'm sure you are aware of apt-cacher or apt-cacher-ng? > > > > In other situation, for example the mmdebstrap testsuite, I built my own > > caching mechanism: > > > > https://sources.debian.org/src/mmdebstrap/0.7.1-1/make_mirror.sh/ > > > > Adding a cache is so simple, you can use a snippet of Python from this pull > > request of mine: > > > > https://salsa.debian.org/debian/devscripts/-/blob/d1c6f2f6a3dca51b77a4a9b37c7d68c1d69270dd/scripts/debbisect#L113 > > > > But why add it to mmdebstrap? That just adds additional complexity and > > feature > > creep. It makes an already complex tool even more complex. Why not keep this > > functionality in an additional piece of software? > > > > Please convince me. > > I'm definitely not proposing integrating a caching proxy of any kind > into mmdebstrap; that should absolutely be a separate piece of software. > But a caching proxy doesn't solve the problem for me. Using a caching > proxy would require one or both of: > - Using http, rather than https > - Configuring the target system to use the proxy directly in its config > > What I was hoping to see integrated into mmdebstrap would be support for > just directly copying the relevant files into the target's > /var/cache/apt, where apt could use them rather than re-downloading > them. Such files could either come from the host system's > /var/cache/apt, or from a directory given to mmdebstrap as a > command-line option (where the latter would also allow mmdebstrap to > store files from the target's /var/cache/apt before deleting them). > > I'm hoping that has the right combination of "sufficiently narrowly > scoped" and "requires integration" to make sense as a part of > mmdebstrap. so... you want something like this: $ mmdebstrap --customize-hook='sync-out /var/cache/apt/archives ./cache' unstable /dev/null $ mmdebstrap --variant=apt --setup-hook='mkdir -p "$1"/var/cache/apt/archives' --setup-hook='sync-in ./cache /var/cache/apt/archives' unstable output.tar The first command fills your local directory "./cache" with the contents of /var/cache/apt/archives from the first run while the second invocation gets the contents from that directory and thus is able to operate a bit faster. Thanks! cheers, josch signature.asc Description: signature
Bug#971018: libgnatcoll-db: FTBFS on mips(64)el with assembler message: branch out of range
Source: libgnatcoll-db Version: 20.0-1 Severity: serious Justification: fails to build from scratch on previously built architectures Hello. libgnatcoll-db/20.0-1 in experimental fails to build on mipsel and mips64el with the following messages [1]. /tmp/ccl8IVnY.s: Assembler messages: /tmp/ccl8IVnY.s:692755: Error: branch out of range /tmp/ccl8IVnY.s:693545: Error: branch out of range /tmp/ccl8IVnY.s:693669: Error: branch out of range The problem seems related to a previous bug [2] with similar symptoms [3]. xref/gnatcoll-xref.adb: In function ‘GNATCOLL.XREF’: xref/gnatcoll-xref.adb:40:1: note: variable tracking size limit exceeded with ‘-fvar-tracking-assignments’, retrying without Assembler messages: 678119: Error: branch out of range CFLAGS+=-mxgot has fixed the issue then, but does not seem sufficient anymore. Any advice would be welcome. [1] https://buildd.debian.org/status/package.php?p=libgnatcoll-db=experimental [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953069 [3] https://buildd.debian.org/status/fetch.php?pkg=libgnatcoll-db=mipsel=19.2-2=1584014543=0
Bug#970910: [Pkg-javascript-devel] Bug#970910: node-rollup-plugin-babel: autopkgtest failures [PATCH]
Hello, On Sat, 26 Sep 2020 08:41:38 + (UTC) Gianfranco Costamagna wrote: > Hello, > > >debian/tests/autopkgtest-pkg-nodejs.conf contains > > > > "extra_depends=mocha, node-tape, node-rollup-plugin-json (>= 4.1.0)" > > > >which should be enough for autodep8 ≥ 0.23. If you use autodep8 ≥ 0.23, > >this bug should be reassigned to autodep8. > > > interesting, I don't see autodep8 installed in both Debian and Ubuntu, but > maybe its outside the build log (of course) > https://autopkgtest.ubuntu.com/packages/n/node-rollup-plugin-babel/groovy/amd64 > > Do you have any clue? > > Gianfranco > > I confirm it works on my machine after updating autodep8. Thanks for the help! I hope Ubuntu folks will update autodep8 soon too. (for now I workarounded adding the 3 dependencies as build-deps) G.
Bug#963124: python-pyqtgraph: please make the build reproducible
sorry for the delay! G. Il giovedì 24 settembre 2020, 14:06:06 CEST, Chris Lamb ha scritto: Chris Lamb wrote: > [..] Friendly ping on this? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#971017: linux: Select INTEL_PMC_CORE to include Intel PMC Core driver
Dear Debian folks, Am 26.09.20 um 10:57 schrieb Paul Menzel: Package: src:linux Version: 5.8.10-1 Severity: normal […] Currently, certain information regarding the Intel Power Management Controller is unaccessible, as the driver is not packaged by the Debian Linux kernel. $ grep INTEL_PMC_CORE /boot/config-5.8.0-2-amd64 # CONFIG_INTEL_PMC_CORE is not set This makes it harder to analyze, how power management works, why it often does not, like for example, why package C-State C10 is not reached on the Dell Latitude E7250. It’d be great, if you selected `INTEL_PMC_CORE` in the configuration to build the driver. config INTEL_PMC_CORE tristate "Intel PMC Core driver" depends on PCI help The Intel Platform Controller Hub for Intel Core SoCs provides access to Power Management Controller registers via a PCI interface. This driver can utilize debugging capabilities and supported features as exposed by the Power Management Controller. Supported features: - SLP_S0_RESIDENCY counter - PCH IP Power Gating status - LTR Ignore - MPHY/PLL gating status (Sunrisepoint PCH only) Ubuntu ships with /boot/config-5.4.0-48-generic:CONFIG_INTEL_PMC_CORE=y but I do not know, why it’s not built as a module. Kind regards, Paul
Bug#971001: Please support caching packages outside the chroot
On Sat, Sep 26, 2020 at 07:28:57AM +0200, Johannes Schauer wrote: > Quoting Josh Triplett (2020-09-26 06:28:18) > > mmdebstrap seems to re-download packages every time it runs. I'd love to > > have > > a way to cache those packages, so that it can run substantially faster the > > second and subsequent times. > > Do one thing and do it well. > > I'm sure you are aware of apt-cacher or apt-cacher-ng? > > In other situation, for example the mmdebstrap testsuite, I built my own > caching mechanism: > > https://sources.debian.org/src/mmdebstrap/0.7.1-1/make_mirror.sh/ > > Adding a cache is so simple, you can use a snippet of Python from this pull > request of mine: > > https://salsa.debian.org/debian/devscripts/-/blob/d1c6f2f6a3dca51b77a4a9b37c7d68c1d69270dd/scripts/debbisect#L113 > > But why add it to mmdebstrap? That just adds additional complexity and feature > creep. It makes an already complex tool even more complex. Why not keep this > functionality in an additional piece of software? > > Please convince me. I'm definitely not proposing integrating a caching proxy of any kind into mmdebstrap; that should absolutely be a separate piece of software. But a caching proxy doesn't solve the problem for me. Using a caching proxy would require one or both of: - Using http, rather than https - Configuring the target system to use the proxy directly in its config What I was hoping to see integrated into mmdebstrap would be support for just directly copying the relevant files into the target's /var/cache/apt, where apt could use them rather than re-downloading them. Such files could either come from the host system's /var/cache/apt, or from a directory given to mmdebstrap as a command-line option (where the latter would also allow mmdebstrap to store files from the target's /var/cache/apt before deleting them). I'm hoping that has the right combination of "sufficiently narrowly scoped" and "requires integration" to make sense as a part of mmdebstrap.
Bug#971017: linux: Select INTEL_PMC_CORE to include Intel PMC Core driver
Package: src:linux Version: 5.8.10-1 Severity: normal Dear Debian folks, Currently, certain information regarding the Intel Power Management Controller is unaccessible, as the driver is not packaged by the Debian Linux kernel. $ grep INTEL_PMC_CORE /boot/config-5.8.0-2-amd64 # CONFIG_INTEL_PMC_CORE is not set This makes it harder to analyze, how power management works, why it often does not, like for example, why package C-State C10 is not reached on the Dell Latitude E7250. It’d be great, if you selected `INTEL_PMC_CORE` in the configuration to build the driver. config INTEL_PMC_CORE tristate "Intel PMC Core driver" depends on PCI help The Intel Platform Controller Hub for Intel Core SoCs provides access to Power Management Controller registers via a PCI interface. This driver can utilize debugging capabilities and supported features as exposed by the Power Management Controller. Supported features: - SLP_S0_RESIDENCY counter - PCH IP Power Gating status - LTR Ignore - MPHY/PLL gating status (Sunrisepoint PCH only) Kind regards, Paul
Bug#970744: ben: please provide machine-parseable version of transition status
Le 25/09/2020 à 22:55, Sebastian Ramacher a écrit : >> I just realized there is already a JSON output, made by Mehdi in 2015... >> maybe it could suit your needs? > > If I'm not missing a switch somewhere, the JSON output can only be used > with `ben monitor`, right? Indeed, HTML output seems hard-coded in `ben tracker`. > Could that somehow be integrated into `ben > tracker` and extended with the other fields? Yes. There are two tasks here, which I think are independent: 1. extend `ben tracker` with --outputs a,b,... for all supported (or a selected subset of) outputs of `ben monitor` 2. enrich JSON output with "the other fields" I can do both. It will take more time than I expected, though. Cheers, -- Stéphane
Bug#971016: leafpad: Edit-and-save remote file over PCManFM-sftp-connection deletes all file content
Package: leafpad Version: 0.8.18.1-5 Severity: important X-Debbugs-Cc: riveravaldezm...@gmail.com Dear Maintainer, * What led up to the situation? On Debian Testing (updated) I've seen this bug for a couple of years now. Using PCManFM's built-in remote-server connection (Menu: Go → Connect with server) and choosing SSH you can mount a remote filesystem. Now, if in any folder of that system you edit a plain text file with leafpad and save it, all the file content gets erased. * What exactly did you do (or not do) that was effective (or ineffective)? With leafpad this problem is consistent. With other editors (nano, mousepad) the problem doesn't exists. If the mounting is done through sshfs, then leafpad works fine. * What was the outcome of this action? Edit and save a file with leafpad on this circumstances (using PCManFM's built-in connection method) results in complete deletion of all file's content. * What outcome did you expect instead? Normal edit-and-save. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/3 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages leafpad depends on: ii libc62.30-8 ii libcairo21.16.0-4 ii libglib2.0-0 2.66.0-2 ii libgtk2.0-0 2.24.32-4 ii libpango-1.0-0 1.46.1-1 ii libpangocairo-1.0-0 1.46.1-1 leafpad recommends no packages. Versions of packages leafpad suggests: pn evince-gtk -- no debconf information
Bug#970910: [Pkg-javascript-devel] Bug#970910: node-rollup-plugin-babel: autopkgtest failures [PATCH]
Hello, >debian/tests/autopkgtest-pkg-nodejs.conf contains > > "extra_depends=mocha, node-tape, node-rollup-plugin-json (>= 4.1.0)" > >which should be enough for autodep8 ≥ 0.23. If you use autodep8 ≥ 0.23, >this bug should be reassigned to autodep8. interesting, I don't see autodep8 installed in both Debian and Ubuntu, but maybe its outside the build log (of course) https://autopkgtest.ubuntu.com/packages/n/node-rollup-plugin-babel/groovy/amd64 Do you have any clue? Gianfranco
Bug#971015: RFS: vim-ultisnips/3.1-3.1 [NMU] [RC] -- snippet solution for Vim
Package: sponsorship-requests Severity: important Control: block 938777 by -1 X-Debbugs-CC: Debian Vim Maintainers X-Debbugs-CC: Michael Fladischer Dear mentors, I am looking for a sponsor for my package "vim-ultisnips": * Package name: vim-ultisnips Version : 3.1-3.1 Upstream Author : Holger Rapp * URL : https://github.com/SirVer/ultisnips * License : GPL-3+ * Vcs : https://salsa.debian.org/vim-team/vim-ultisnips Section : editors It builds those binary packages: vim-ultisnips - snippet solution for Vim To access further information about this package, please visit the following URL: https://mentors.debian.net/package/vim-ultisnips/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/v/vim-ultisnips/vim-ultisnips_3.1-3.1.dsc Or you can see diff in recently imported Git project at salsa.d.o: https://salsa.debian.org/vim-team/vim-ultisnips/-/commit/01d9924e156a02d3d43d1997055a53b7405fed93 Changes since the last upload: vim-ultisnips (3.1-3.1) unstable; urgency=medium . * Non-maintainer upload. * Shift to Python 3 already supported by the plugin. (Closes: #938777) * Move packaging repository to a new GitLab instance at salsa.debian.org. I was trying to keep the changes as little as possible. I only replaced python2 string with python3 where found, and I excluded ".pyc" files related to second Python. The plugin itself works okay with Python 3.8 from buster. Any other warnings reported by lintian still left untouched. If Michael Fladischer does not mind, I could adopt the package and bring to a fresh form, switching to a modern "packadd" feature and dh-vim-addon instead of obsoleted vim-addon-manager. Regards, signature.asc Description: This is a digitally signed message part
Bug#970420: python dependencies now uninstallable
please stop spreading fud. this message is full of wrong assumptions and spreading fud. On 9/25/20 6:35 PM, Christoph Anton Mitterer wrote: > Matthias Klose wrote: >> there are *no* packages in testing depending on python. > > Well there are so many people that run on unstable and for them a > considerable number of packages became uninstallable (respectively > python2 won't upgrade anymore, thus potentially lacking any security > updates added to it). running unstable is not recommended, and there are no security updates in a dependency package. > Wouldn't it at least be possible to get some mass-bug-filing against > all packages that depend strictly on "python" or any other of the no > longer built packages, asking them to simply add the "2" as an > intermediate solution (till they'll anyway need to migrate to 3)? These are filed, and I'm not repeating what was communicated on the debian-python ML. So please just stop it. Matthias
