Bug#918520: libfiu: FTBFS randomly when built with eatmydata
Chris Lamb wrote: > > I'll dig in a bit more and see if I can fix libeatmydata, but it might > > end up being too invasive and time consuming. I'll send another message > > once I know more. > > Oh, nice analysis so far. Sounds like that needs to get (at least > copied...) upstream at the very least so that it doesn't > accidentally lost in this "branch" bug report. > > (Probably has implications for other packages that Santiago is > testing too, naturally…) Any further thoughts folks? :) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#921212: open-infrastructure-ceph-tools: missing Breaks+Replaces: open-infrastructure-storage-tools (<< 20180915-2)
Package: open-infrastructure-ceph-tools Version: 20180915-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces From the attached log (scroll to the bottom...): Preparing to unpack .../open-infrastructure-ceph-tools_20180915-2_all.deb ... Unpacking open-infrastructure-ceph-tools (20180915-2) ... dpkg: error processing archive /var/cache/apt/archives/open-infrastructure-ceph-tools_20180915-2_all.deb (--unpack): trying to overwrite '/etc/apache2/conf-available/ceph-info.conf', which is also in package open-infrastructure-storage-tools 20180915-1 Errors were encountered while processing: /var/cache/apt/archives/open-infrastructure-ceph-tools_20180915-2_all.deb This is the list of "shared" files: etc/apache2/conf-available/ceph-info.conf etc/cron.d/ceph-info etc/cron.d/cephfs-snap etc/logrotate.d/ceph-log etc/logrotate.d/cephfs-snap lib/systemd/system/ceph-log.service usr/bin/ceph-dns usr/bin/ceph-info usr/bin/ceph-log usr/bin/ceph-remove-osd usr/bin/cephfs-snap usr/share/man/man1/ceph-info.1.gz usr/share/man/man1/ceph-log.1.gz usr/share/man/man1/ceph-remove-osd.1.gz usr/share/man/man1/cephfs-snap.1.gz usr/share/man/man7/storage-tools.7.gz usr/share/storage-tools/ceph-info/web/bootstrap.min.css usr/share/storage-tools/ceph-info/web/bootstrap.min.js usr/share/storage-tools/ceph-info/web/ceph-df.txt usr/share/storage-tools/ceph-info/web/ceph-health-detail.txt usr/share/storage-tools/ceph-info/web/ceph-osd-df.txt usr/share/storage-tools/ceph-info/web/ceph-osd-tree.txt usr/share/storage-tools/ceph-info/web/ceph-status.txt usr/share/storage-tools/ceph-info/web/ceph-versions.txt usr/share/storage-tools/ceph-info/web/ceph-watch.log usr/share/storage-tools/ceph-info/web/date.txt usr/share/storage-tools/ceph-info/web/font-awesome usr/share/storage-tools/ceph-info/web/index.html usr/share/storage-tools/ceph-info/web/jquery.min.js usr/share/storage-tools/ceph-info/web/logtail.js usr/share/storage-tools/ceph-info/web/navbar.css cheers, Andreas open-infrastructure-storage-tools=20180915-1_open-infrastructure-ceph-tools=20180915-2.log.gz Description: application/gzip
Bug#921211: r-cran-natserv: testing migration blocked by autopkgtest regression
Source: r-cran-natserv
Version: 0.3.0+dfsg-1
Severity: serious
https://ci.debian.net/packages/r/r-cran-natserv/unstable/amd64/
...
autopkgtest [20:57:22]: test run-unit-test: [---
BEGIN TEST test-all.R
R version 3.5.2 (2018-12-20) -- "Eggshell Igloo"
Copyright (C) 2018 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> library("testthat")
> test_check("natserv")
Loading required package: natserv
Error in library("vcr") : there is no package called 'vcr'
Calls: test_check ... source_dir -> lapply -> FUN -> eval -> eval -> library
Execution halted
autopkgtest [20:57:23]: test run-unit-test: ---]
autopkgtest [20:57:23]: test run-unit-test: - - - - - - - - - - results - - -
- - - - - - -
run-unit-testFAIL non-zero exit status 1
autopkgtest [20:57:23]: summary
run-unit-testFAIL non-zero exit status 1
Bug#921198: hard to track down
Hi, just for the record, I tried to reproduce the build failure on eller (mipsel porterbox), but it builds fine there. I'm wondering whether the timeout set on line 232 of tests/srp.c (40 seconds) is too short for slower build hosts. Willi
Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
Hi, Please note that the issues raised have been mostly dealt with. There is a man page, the descriptions in the control file have been changed, the copyright has been updated, and now usr/bin/brightness-controller calls an interpreter. Thanks, Archisman On Wed, Jan 23, 2019, 12:35 AM Archisman Panigrahi > > -- Forwarded message - > From: Archisman Panigrahi > Date: Tue, Jan 22, 2019 at 8:15 PM > Subject: Re: Bug#920039: RFS: brightness-controller/2.2.3 [ITP] > To: Adam Borowski > > > Hi, > > I have uploaded version 2.2.3-1. > Now the /usr/bin calls the interpreter python to run > /usr/share/brightness-controller/init.py. > > Thanks, > Archisman > > On Tue, Jan 22, 2019 at 8:05 PM Adam Borowski wrote: > >> On Tue, Jan 22, 2019 at 07:54:45PM +0530, Archisman Panigrahi wrote: >> > On Tue, Jan 22, 2019 at 5:41 PM Adam Borowski >> wrote: >> > >> > > On Tue, Jan 22, 2019 at 04:57:20PM +0530, Archisman Panigrahi wrote: >> > > > I am not sure about the native package issue. Has it got something >> to >> > > > do with /debian/source/format? I did not exactly understand what is >> > > > the difference between native and quilt, so went for native. Any >> > > > suggestion is welcome. >> > > >> > > The "native" format is adequate only when there's no separate >> upstream (and >> > > often not even then); in this case you are packaging Amit's software >> that >> > > has proper releases, tarballs, and all proper trappings. >> > > >> > > The packaging is supposed to be composed of two pieces: >> > > * the upstream (.orig) tarball >> > > * a packaging tarball, that includes the debian/ dir and a (possibly >> empty) >> > > patch series >> > > >> > > This was somewhat different with the 1.0 format, but you don't want >> it -- >> > > even if you (like me) despite quilt, the "3.0 (quilt)" format with a >> single >> > > patch is strictly better than 1.0. >> > >> > I am now using 3.0 (quilt). I have uploaded a new release (under the >> same >> > version number), please check. >> > There is some lintian error >> > "debian-changelog-version-requires-debian-revision". Is it due to the >> fact >> > that the debian/changelog in .orig.tar.gz >> >> Lintian has a nice set of explanations for its error messages, they get >> enables by "-I". These tend to be better than one-paragraph responses >> reviewers like me reply with (even though an automated tool is not as good >> at understanding the context). >> >> In this case, the version number should end in "-1". >> >> > init.py calls other python files in usr/share/brightness-controller/ui >> and >> > usr/share/brightness-controller/util, so I want init.py >> > to be in usr/share/brightness-controller/ as well. Otherwise I will >> need to >> > import them across directories which I want to avoid. >> >> That's a Python specific question, I can't answer those. I'm afraid that >> I >> need to pass you to other people on this mailing list. If you happen to >> have any Perl questions, though... >> >> >> Meow! >> -- >> ⢀⣴⠾⠻⢶⣦⠀ >> ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands >> ⢿⡄⠘⠷⠚⠋⠀ for Privacy. >> ⠈⠳⣄ > > >
Bug#351856: auto-subscription - perhaps reportbug is a better place to implement this
على ٢٨/٥/١٤٤٠ هـ ١:٥٧ ص، كتب Afif Elghraoui: > Control: subscribe -1 ! > silly me--- I mistook this for a control command since I usually use devscripts' `bts subscribe ...`. Never mind my previous message and apologies for the noise. regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Bug#920664: unable to decrypt drive from grub after alpha4 setup)
I am able to decrypt the partition outside of a VM without the rescue "CD". Since I can also decrypt using the installer CD as rescue, this means the failure is specific to booting via grub and initrd. This seems to indicate the installer created the encrypted partition properly but the boot environment it created is either handling the pass-phrase incorrectly (e.g., include \n) or is missing some other part of the machinery necessary. The most obvious candidate is from the error message > Check that kernel supports aes-xts-plain64 cipher I don't know how to check that, but looking in config-4.19.0-1-amd64 on the boot partition, I see some partial matches that might be relevant: CONFIG_CRYPTO_AES=y # CONFIG_CRYPTO_AES_TI is not set CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_XTS=m I don't see anything that looks like plain. The buster system created by the installer includes aesni-intel.ko, but the initrd does not. Ross
Bug#921195: mcabber: does not connect to Jabber via IPv6 (fails Etch release goal)
On 2019-02-02 Thorsten Glaser wrote: > Package: mcabber > Version: 1.1.0-1.1 > Severity: serious > Tags: ipv6 > Justification: fails release goal > I’m currently in the FOSDEM WLAN (IPv6-only, not FOSDEM-legacy), > and I can neither connect to the Jabber server with SRV RRs nor > when hardcoding commu.teckids.org in mcabberrc. > A netcat on commu.teckids.org port 5223 works, so it’s the client. commu.teckids.org offers TLS 1.3, so I a suspect the TLS code is not up to date for TLS 1.3. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#921210: kerneloops.service: ExecStartPre uses non-existent --test option
Package: kerneloops Version: 0.12+git20140509-6 Severity: normal File: /lib/systemd/system/kerneloops.service Usertags: warnings The ExecStartPre option in kerneloops.service uses the non-existent kerneloops --test command-line option. This causes systemd to print a notice message to the journal whenever starting the kerneloops service because it detects a left-over process in the control group. This is also because kerneloops does not exit when given a non-existent option. $ grep -- -- /lib/systemd/system/kerneloops.service ExecStartPre=/usr/sbin/kerneloops --test $ strings /usr/sbin/kerneloops | grep -- '--[a-z]\+$' --nodaemon --debug --file $ journalctl --system --priority notice --follow --lines 0 --quiet --unit kerneloops & [1] 21835 $ systemctl restart kerneloops ; sleep 1 Feb 03 14:20:03 chianamo systemd[1]: kerneloops.service: Found left-over process 21862 (kerneloops) in control group while starting unit. Ignoring. Feb 03 14:20:03 chianamo systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies. $ /usr/sbin/kerneloops --nodaemon --asdjasbdkajdfksdfbasldkfbasdf ^C -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kerneloops depends on: ii init-system-helpers 1.56+nmu1 ii libc62.28-5 ii libcurl3-gnutls 7.63.0-1 ii libdbus-1-3 1.12.12-1 ii libdbus-glib-1-2 0.110-4 ii libglib2.0-0 2.58.2-3 ii lsb-base 10.2018112800 Versions of packages kerneloops recommends: ii kerneloops-applet 0.12+git20140509-6 kerneloops suggests no packages. -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#756954: subscription by uploaders
Control: subscribe -1 Hello, I was just about to file a bug about this and found it already existing. The way I was hoping this could work is that Uploaders are automatically subscribed. I don't know of any reason why an Uploader should not be following their packages. I think it would also motivate people who really don't co-maintain a package to get themelves removed from the Uploaders list, thereby correcting the package metadata. I think this would also be simpler to implement than subscription keywords in d/control (as mentioned in the OP). If it's still too far out of you way, I'd be willing to implement a patch, but would appreciate a tip about where to look in the code-base. I looked around it and couldn't find a good starting point in the file hierarchy. thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Bug#908832: Please include application/wasm MIME type for WebAssembly files
On Sat, Feb 02, 2019 at 01:40:18PM +0900, Charles Plessy wrote: > Le Fri, Sep 14, 2018 at 10:19:31AM -0700, Josh Triplett a écrit : > > > > Browsers require WebAssembly files to get served with the proper MIME > > type, application/wasm. To help web servers such as the one in Python, > > which read /etc/mime.types, could you please include an entry for > > `application/wasm wasm` in /etc/mime.types? > > Le Mon, Jan 28, 2019 at 11:45:10AM +0100, Josh Triplett a écrit : > > Any updates on this bug? It'd be helpful to have this mime entry in > > the next stable release. > > Hi Josh, > > sorry for the delay, > > I do not see application/wasm on the IANA website. Is there a chance > that relevant people in charge for WebAssembly could submit their media > type there ? It's already on https://www.iana.org/assignments/provisional-standard-media-types/provisional-standard-media-types.xhtml
Bug#921094: [Pkg-fonts-devel] Bug#921094: fonts-fantasque-sans: Single quote/apostrophe is not clearly readable
Cyril Augier writes: > Package: fonts-fantasque-sans > Version: 1.7.1~dfsg-1 > Severity: important > > Hi ! > > According to the issues on Github, the problem is solved in the higher > versions. > > I installed the latest version from GitHub and it works perfectly. Which version did you check with?. I'm doubtful to make it to buster but definitely can be fixed for buster+1. Cheers,
Bug#921209: alsamixer: lots of qqqqq after installing pulseaudio
Package: alsa-utils Version: 1.1.7-1 Severity: wishlist After installing pulseaudio, alsamixer looks like this, lq AlsaMixer v1.1.7 qqk x Card: PulseAudio F1: Help x x Chip: PulseAudio F2: System information x x View: F3:[Playback] F4: Capture F5: All F6: Select sound card x x Item: Master Esc: Exit x Lots of 's.
Bug#921208: hexchat: Hexchat dumped core
Package: hexchat Version: 2.14.2-3 Severity: important Dear Maintainer, I was away from the computer for hours. When I returned and tried to play music, I saw the following in /var/log/syslog: Feb 2 20:10:30 bonnet pulseaudio[1276]: E: [alsa-sink-ALC1200 Analog] alsa-sink.c: Error opening PCM device front:0: Device or resource busy Feb 2 20:10:30 bonnet pulseaudio[1276]: E: [alsa-sink-ALC1200 Analog] alsa-sink.c: Error opening PCM device front:0: Device or resource busy Feb 2 20:11:53 bonnet pulseaudio[1276]: E: [alsa-sink-ALC1200 Analog] alsa-sink.c: Error opening PCM device front:0: Device or resource busy Feb 2 20:12:58 bonnet systemd[1]: Started Process Core Dump (PID 6097/UID 0). Feb 2 20:12:58 bonnet systemd-coredump[6098]: Process 24511 (hexchat) of user 1000 dumped core.#012#012Stack trace of thread 24511:#012#0 0x7ff9c13c885b __GI_raise (libc.so.6)#012#1 0x7ff9c13b3535 __GI_abort (libc.so.6)#012#2 0x7ff9b505cd66 n/a (libpython3.7m.so.1.0)#012#3 0x7ff9b5161823 Py_FatalError (libpython3.7m.so.1.0)#012#4 0x7ff9b5163dab PyInterpreterState_Delete (libpython3.7m.so.1.0)#012#5 0x7ff9b5164b04 Py_FinalizeEx (libpython3.7m.so.1.0)#012#6 0x7ff9b6007fee hexchat_plugin_deinit (python3.so)#012#7 0x55f79020ba86 n/a (hexchat)#012#8 0x55f79020ddb1 plugin_kill_all (hexchat)#012#9 0x55f7901fb95d hexchat_exit (hexchat)#012#10 0x7ff9c2141c7d g_closure_invoke (libgobject-2.0.so.0)#012#11 0x7ff9c2155333 n/a (libgobject-2.0.so.0)#012#12 0x7ff9c215e2c2 g_signal_emit_valist (libgobject-2.0.so.0)#012#13 0x7ff9c215e90f g_signal_emit (libgobject-2.0.so.0)#012#14 0x7ff9c1e0d320 n/a (libgtk-x11-2.0.so.0)#012#15 0x7ff9c2141c7d g_closure_invoke (libgobject-2.0.so.0)#012#16 0x7ff9c2155333 n/a (libgobject-2.0.so.0)#012#17 0x7ff9c215d983 g_signal_emit_valist (libgobject-2.0.so.0)#012#18 0x7ff9c215e90f g_signal_emit (libgobject-2.0.so.0)#012#19 0x7ff9c1c35198 gtk_accel_group_activate (libgtk-x11-2.0.so.0)#012#20 0x7ff9c1c3663d gtk_accel_groups_activate (libgtk-x11-2.0.so.0)#012#21 0x7ff9c1e25046 gtk_window_activate_key (libgtk-x11-2.0.so.0)#012#22 0x7ff9c1e250a1 n/a (libgtk-x11-2.0.so.0)#012#23 0x7ff9c1cf81eb n/a (libgtk-x11-2.0.so.0)#012#24 0x7ff9c2141c7d g_closure_invoke (libgobject-2.0.so.0)#012#25 0x7ff9c2154b64 n/a (libgobject-2.0.so.0)#012#26 0x7ff9c215d983 g_signal_emit_valist (libgobject-2.0.so.0)#012#27 0x7ff9c215e90f g_signal_emit (libgobject-2.0.so.0)#012#28 0x7ff9c1e0ecac n/a (libgtk-x11-2.0.so.0)#012#29 0x7ff9c1cf655d gtk_propagate_event (libgtk-x11-2.0.so.0)#012#30 0x7ff9c1cf687b gtk_main_do_event (libgtk-x11-2.0.so.0)#012#31 0x7ff9c1b69bac n/a (libgdk-x11-2.0.so.0)#012#32 0x7ff9c205fe0e g_main_context_dispatch (libglib-2.0.so.0)#012#33 0x7ff9c20600a8 n/a (libglib-2.0.so.0)#012#34 0x7ff9c20603a2 g_main_loop_run (libglib-2.0.so.0)#012#35 0x7ff9c1cf58e7 gtk_main (libgtk-x11-2.0.so.0)#012#36 0x55f7901c0679 fe_main (hexchat)#012#37 0x55f7901b4928 main (hexchat)#012#38 0x7ff9c13b509b __libc_start_main (libc.so.6)#012#39 0x55f7901b4a6a _start (hexchat)#012#012Stack trace of thread 24512:#012#0 0x7ff9c147fb39 __GI___poll (libc.so.6)#012#1 0x7ff9c2060016 n/a (libglib-2.0.so.0)#012#2 0x7ff9c206013c g_main_context_iteration (libglib-2.0.so.0)#012#3 0x7ff9c2060181 n/a (libglib-2.0.so.0)#012#4 0x7ff9c2088325 n/a (libglib-2.0.so.0)#012#5 0x7ff9c1559fa3 start_thread (libpthread.so.0)#012#6 0x7ff9c148a7ef __clone (libc.so.6)#012#012Stack trace of thread 24513:#012#0 0x7ff9c147fb39 __GI___poll (libc.so.6)#012#1 0x7ff9c2060016 n/a (libglib-2.0.so.0)#012#2 0x7ff9c20603a2 g_main_loop_run (libglib-2.0.so.0)#012#3 0x7ff9c228cd26 n/a (libgio-2.0.so.0)#012#4 0x7ff9c2088325 n/a (libglib-2.0.so.0)#012#5 0x7ff9c1559fa3 start_thread (libpthread.so.0)#012#6 0x7ff9c148a7ef __clone (libc.so.6) Feb 2 20:12:58 bonnet systemd[1]: systemd-coredump@82-6097-0.service: Succeeded. Feb 2 20:13:00 bonnet systemd[1]: Started Process Core Dump (PID 6103/UID 0). Feb 2 20:13:01 bonnet systemd-coredump[6104]: Process 24515 (hexchat) of user 1000 dumped core.#012#012Stack trace of thread 24515:#012#0 0x7f1b3e43685b __GI_raise (libc.so.6)#012#1 0x7f1b3e421535 __GI_abort (libc.so.6)#012#2 0x7f1b31e66d66 n/a (libpython3.7m.so.1.0)#012#3 0x7f1b31f6b823 Py_FatalError (libpython3.7m.so.1.0)#012#4 0x7f1b31f6ddab PyInterpreterState_Delete (libpython3.7m.so.1.0)#012#5 0x7f1b31f6eb04 Py_FinalizeEx (libpython3.7m.so.1.0)#012#6 0x7f1b38524fee hexchat_plugin_deinit (python3.so)#012#7 0x56037e48ca86 n/a (hexchat)#012#8 0x56037e48edb1 plugin_kill_all (hexchat)#012#9 0x56037e47c95d hexchat_exit (hexchat)#012#10 0x7f1b3f1afc7d g_closure_invoke (libgobject-2.0.so.0)#012#11 0x7f1b3f1c n/a
Bug#921207: Octave GEMM error on large matrix due to openmp thread race condition
Package: octave Version: 4.4.1-4 Severity: grave X-Debbugs-CC: debian-scie...@lists.debian.org, ido...@neto.net.il Dear octave maintainer, I received an astonishing bug report[1] saying that MKL returns wrong result for matrix multiplication. However, my further investigation suggests that the problem is very likely a threading bug of octave. OpenMP is highly suspected according to my following experimental results. === Please reproduce the problem with the following octave script: 921193.m ``` x=1:10; y=[x;x]*[x;x]'; disp(reshape(y, 1, 4)) ``` The correct result is 385 385 385 385 However sometimes octave yields random results, which is possibly a symptom of race condition between threads or alike. MKL -- libblas.so, libblas.so.3 = libmkl_rt.so $ octave 921193.m 1.1033e+15 1.1033e+15 1.1038e+15 1.1038e+15 $ MKL_NUM_THREADS=1 octave 921193.m 385 385 385 385 $ MKL_NUM_THREADS=2 octave 921193.m 642428448891136 642428448891136 642428448891136 642428448891136 $ MKL_NUM_THREADS=2 MKL_THREADING_LAYER=intel octave 921193.m 489859913436624 489859913436624 488279025495504 488279025495504 $ MKL_NUM_THREADS=2 MKL_THREADING_LAYER=gnu octave 921193.m 385 385 385 385 $ MKL_NUM_THREADS=2 MKL_THREADING_LAYER=tbb octave 921193.m 385 385 385 385 $ MKL_NUM_THREADS=2 MKL_THREADING_LAYER=sequential octave 921193.m 385 385 385 385 The default threading model used by libmkl_rt is the "intel" threading aka. libiomp5 . It seems that Octave isn't happy with libiomp5 . In contrast, gomp (gnu), tbb, serial/sequential threading users are not affected. --- Netlib -- libblas.so, libblas.so.3 = netlib blas $ octave 921193.m 824104476280848 824104476280848 828286951663952 828286951663952 $ octave 921193.m 385 385 385 385 $ OMP_NUM_THREADS=1 octave 921193.m 385 385 385 385 Netlib blas has no multi-thread implementation. This result indicates that octave's multi-threading functionality is questionable. -- BLIS (openmp) libblas.so, libblas.so.3 = blis (openmp). Please note that BLIS use single thread by default even if it's compiled with openmp/pthread threading model. $ octave 921193.m 757875851200128 757875851200128 796692912410048 796692912410048 $ BLIS_NUM_THREADS=1 octave 921193.m 531523819460688 531523819460688 543945552290544 543945552290544 $ OMP_NUM_THREADS=1 octave 921193.m 385 385 385 385 Again, octave's multi-threading functionality is questionable. --- OpenBLAS --- libblas.so, libblas.so.3 = openblas $ octave 921193.m 907773323384928 907773323384928 925793789579664 925793789579664 $ octave 921193.m 385 385 385 385 $ OPENBLAS_NUM_THREADS=1 octave 921193.m 737565604371072 737565604371072 741382086552384 741382086552384 $ OMP_NUM_THREADS=1 octave 921193.m 385 385 385 385 = According to the above experimental results, I think BLAS libraries are innocent. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921193
Bug#921068: enlightenment: Crashes when failing to load ALSA on start up.
On Fri, Feb 01, 2019 at 09:59:46AM +0100, Nicolas Cavallari wrote:
> A recent pulseaudio upgrade broke the ALSA configuration. Since this
> machine seldom needs to play sounds, this is a minor problem.
>
> However, as a result, Enlightenment SEGVs on load. Trying to restart
> it with F1 does not work, unless the ALSA configuration is fixed:
Thanks for the report, I can reproduce. I don't see anything related to the
mixer in your backtrace, but it shows up in mine (attached).
> (The original ALSA problem is that the documented way to disable
> redirecting ALSA applications to pulseaudio was to divert
> /usr/share/alsa/alsa.conf.d/pulse.conf away)
There is a recent patch in upstream git that sounds like it could be related
(a841544d0). I hope to have some time to test tomorrow.
Ross
Thread 6 (Thread 0x7f03b957d700 (LWP 9067)):
#0 0x7f03c5e3c357 in __GI___select (nfds=45,
readfds=readfds@entry=0x7f03b957c730, writefds=writefds@entry=0x7f03b957c7b0,
exceptfds=exceptfds@entry=0x7f03b957c830, timeout=timeout@entry=0x7f03b957c710)
at ../sysdeps/unix/sysv/linux/select.c:41
resultvar = 18446744073709551102
sc_cancel_oldtype = 1
sc_ret =
#1 0x7f03c5f50466 in _drm_tick_core (data=,
thread=0x55d33c9d5830) at lib/ecore_x/ecore_x_vsync.c:358
wfds = {fds_bits = {0 }}
ret =
tv = {tv_sec = 0, tv_usec = 87258}
rfds = {fds_bits = {17592186044416, 0 }}
exfds = {fds_bits = {0 }}
max_fd =
msg =
ref = 0x55d33d07b3c0
tick = 1
__FUNCTION__ =
#2 0x7f03c68b9e5c in _ecore_direct_worker (work=0x55d33c9d5830) at
lib/ecore/ecore_thread.c:484
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf =
{94365743405104, -2636936008978456277, 140720380279134, 140720380279135,
94365743404976, 0, -2637060908116401877, -2636936008885001941},
__mask_was_saved = 0}}, __pad = {0x7f03b957ca30, 0x0, 0x7f03c6960d44
<_eina_debug_thread_add+164>, 0x0}}
__cancel_routine = 0x7f03c68ba0e0 <_ecore_direct_worker_cleanup>
__cancel_arg = 0x55d33c9d5830
__not_first_call =
#3 0x7f03c698f0e0 in _eina_internal_call (context=0x55d33c9d57b0) at
lib/eina/eina_thread.c:151
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0,
2693211662942937387, 140720380279134, 140720380279135, 139653971171072, 0,
-2637060908101721813, -2636936140606463701}, __mask_was_saved = 0}}, __pad =
{0x7f03b957c9c0, 0x0, 0x0, 0x0}}
__cancel_routine =
__cancel_arg =
__not_first_call =
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0,
2693211662942937387, 140720380279134, 140720380279135, 139653971171072, 0,
-2637060908101721813, -2636936140634513109}, __mask_was_saved = 0}}, __pad =
{0x7f03b957cad0, 0x0, 0x0, 0x0}}
__cancel_routine =
__cancel_arg = 0x55d33c9d57b0
__not_first_call =
c = 0x55d33c9d57b0
r =
self = 139653971171072
#4 0x7f03c692bfa3 in start_thread (arg=) at
pthread_create.c:486
ret =
pd =
now =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139653971171072,
2693211662942937387, 140720380279134, 140720380279135, 139653971171072, 0,
-2637060908007349973, -2636936087314554581}, mask_was_saved = 0}}, priv = {pad
= {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call =
#5 0x7f03c5e447ef in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 5 (Thread 0x7f03b9d7e700 (LWP 9066)):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x55d33c8f171c) at
../sysdeps/unix/sysv/linux/futex-internal.h:88
__ret = -512
oldtype = 0
err =
oldtype =
err =
__ret =
resultvar =
__arg4 =
__arg3 =
__arg2 =
__arg1 =
_a4 =
_a3 =
_a2 =
_a1 =
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x55d33c8f16c8,
cond=0x55d33c8f16f0) at pthread_cond_wait.c:502
spin = 0
buffer = {__routine = 0x7f03c6931d20 <__condvar_cleanup_waiting>, __arg
= 0x7f03b9d7d940, __canceltype = 1026572816, __prev = 0x0}
cbuffer = {wseq = 7, cond = 0x55d33c8f16f0, mutex = 0x55d33c8f16c8,
private = 0}
rt =
err =
g = 1
flags =
g1_start =
signals =
result = 0
wseq = 7
seq = 3
private = 0
maxspin =
err =
result =
wseq =
g =
seq =
flags =
private =
signals =
g1_start =
spin =
buffer =
cbuffer =
rt =
s =
#2 __pthread_cond_wait (cond=0x55d33c8f16f0, mutex=0x55d33c8f16c8) at
pthread_cond_wait.c:655
No locals.
#3 0x7f03ba339a32 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
No symbol table info available.
#4 0x7f03ba3395f7 in ?? () from
Bug#921206: qttools-opensource-src: build-dep llvm-dev on mips*r6 and mips64 please
Package: src:qttools-opensource-src Version: 5.11.3-4 llvm is available on all mips r6 ports. Please build-dep on llvm also for them: mipsr6 mipsr6el mips64r6el mips64r6 mips64 -- YunQiang Su
Bug#916496: xcom-ufo: cannot build package from GOG 2.0.0.4 installer
I've done some more research, and come up with more details. As I understand it, the original X-COM for DOS was released as version 1.0, then had a bunch of fixes up to version 1.4. Later, a "collector's edition" was released which ported the game to Windows and included even more fixes. PCGamingWiki says[1] that the GOG build is straight up version 1.4, bundled with DOSBox to make it run on modern OSs. It also says that the Steam build uses the 1.4 engine for DOS, but with some Collector's Edition data files. [1]: https://pcgamingwiki.com/wiki/X-COM:_UFO_Defense#Availability I found some details on the files that shipped with the Collector's Edition, so together with the official patches I acquired earlier, I believe I can trace all these variations. Going back to the original list of missing files... # assets not in setup_xcom_ufo_defense_2.0.0.4.exe: # group_members: | # 44288 6a2b1ec8182f5025ee505c6949356925 GEODATA/BIGLETS.DAT # 12456 5ae490e16959e1961071f0172c793c94 GEODATA/SMALLSET.DAT These files come from the Collector's Edition. Compared to the 1.4 versions, they add extra characters that weren't in the original DOS character set[2][3]. I imagine the DOS engine doesn't actually use them, but OpenXCOM might. [2]: https://www.ufopaedia.org/index.php/BIGLETS.DAT [3]: https://www.ufopaedia.org/index.php/SMALLSET.DAT # 46601 1770cf9f3a18350c7afa54b0e271c359 GEODATA/ENGLISH.DAT # 52672 eacbbca8d2de655cda7aa403702bec46 GEODATA/FRENCH.DAT # 53587 1cd8dd5069970d0f2a6983339057a34b GEODATA/GERMAN.DAT These files come from the Collector's Edition. Comparing them to the 1.4 versions, the only differences are that the message "Quit to DOS" (or its translated equivalent) has been changed to "Quit" (or translated etc.). # 93853 7194c1480e6ce2d3e188133ece4fdefb SOUND/ROLAND.CAT As discussed previously, this file comes from the 1.4 patch. Looking at the original list of obsolete files: # obsolete: # group_members: | # 32768 9f20ed66008a2fbc055c10db74c44307 GEODATA/BIGLETS.DAT?orig # 9216 3943027ebeab34adfa3d31c04adc886d GEODATA/SMALLSET.DAT?orig These are the versions from the GOG release, and since they doesn't appear in any other patches, presumably from the original 1.0 release. # 46608 a28031075f0e531d5896ffca8125d7bc GEODATA/ENGLISH.DAT?orig # 52679 1538fc2f7d85aa81d06b4bff319d9902 GEODATA/FRENCH.DAT?orig # 53594 342570230da352242219d6fea289d8b1 GEODATA/GERMAN.DAT?orig These are the versions from the 1.2 and 1.3 patches. Lastly, the mysterious extra ROLAND.CAT. As I understand it: - 1.0 through 1.3 came with music data for AdLib (in ADLIB.CAT) and Roland CM-32 (in ROLAND.CAT) devices. - 1.4 switched to a different music engine[4], which used different formats. ADLIB.CAT was updated to use the new format, and a new GM.CAT was supplied to support General MIDI devices, but ROLAND.CAT was left untouched. - Therefore, if you tried to use Roland CM-32 support in 1.4, the game would hang[5] as the new music engine tried to interpret the ROLAND.CAT file in the old format. - A fan reverse-enginered the old and new file-formats and repackaged the Roland music data from 1.3 in the format 1.4 expects[6], which is the version bundled with the GOG release. - However, OpenXCOM does not use or care about ROLAND.CAT, only GM.CAT, so there's no point packaging it at all. [4]: https://www.ufopaedia.org/index.php/SOUND [5]: https://pcgamingwiki.com/wiki/X-COM:_UFO_Defense#Game_hang_when_attempting_to_use_the_MT-32_in_version_1.4_.28DOS.29 [6]: https://www.vogons.org/viewtopic.php?t=21542l=32 On Sat, Feb 02, 2019 at 11:06:29AM +, Simon McVittie wrote: > On Sat, 02 Feb 2019 at 20:17:38 +1100, Tim Allen wrote: > > I found a site[1] claiming to host the official 1.1, 1.2, 1.3 and 1.4 > > patches, alongside a bunch of other unofficial patches. It turns out > > that the ROLAND.CAT that game-data-packager was looking for (MD5: > > 7194c14...) is part of the UFO 1.4 update. The site says[2]: > > > > # This patch fixes many stability issues, some game stopping research > > # bugs And removed the startup copy protection. However it also replaces > > # the sounds with ones that are not as good as the originals. > > Should we be preferring to package the unpatched ROLAND.CAT (143866 bytes, as > shipped by GOG) rather than the v1.4 ROLAND.CAT (93853 bytes, as shipped by > Steam) if we can see both, then? The YAML syntax lets us prefer one version > over others. Now that I know OpenXCOM doesn't use it, there's probably no point packaging it at all. Perhaps OpenXCOM might use it at some point in the future, but that seems very unlikely given that GM.CAT is almost exactly the same thing, and ADLIB.CAT is probably the one people care about for nostalgic reasons. > > The BIGLETS.DAT and SMALLSET.DAT files don't appear in any > > patch, official or unofficial, expected hash or
Bug#921205: socket bind() to port 25 for address (any IPv6) failed: Address already in use: daemon abandoned
Package: exim4-daemon-light Version: 4.92~RC5-1 For the last two upgrades, /var/log/exim4/paniclog: 2019-02-02 21:47:07 socket bind() to port 25 for address (any IPv6) failed: Address already in use: daemon abandoned As we see from timestamps, it is upgrade related. # ls -dog /var/log/exim4/paniclog /usr/share/doc/exim4-config/examples/ drwxr-xr-x 2 4096 02-02 21:41 /usr/share/doc/exim4-config/examples/ -rw-r- 1 117 02-02 21:47 /var/log/exim4/paniclog -- debconf information: * exim4-daemon-light/drec: P.S., a cronjob then sends exim paniclog on jidanni2.jidanni.org has non-zero size to the user the next boot.
Bug#921204: RFS: austin/0.6.1-beta-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "austin" * Package name: austin Version : 0.6.1-beta-1 Upstream Author : Gabriele N. Tornetta * URL : https://github.com/P403n1x87/austin * License : GPLv3 Section : devel It builds those binary packages: austin - a frame stack sampler for CPython To access further information about this package, please visit the following URL: https://mentors.debian.net/package/austin Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/austin/austin_0.6.1-beta-1.dsc More information about austin can be obtained from https://www.example.com. Changes since the last upload: austin (0.6.1-beta-1) unstable; urgency=medium * Initial release (Closes: #918518) -- Gabriele N. Tornetta Fri, 04 Jan 2019 23:13:40 + Regards, Gabriele N. Tornetta
Bug#921203: RFP: scenarist -- KIT Scenarist – screenplay editor
Package: wnpp Severity: wishlist * Package name: scenarist Version : 0.7.2 Upstream Author : Дмитрия Новикова (Dmitry Novikov) * URL : https://kitscenarist.ru/en/ * License : GPL Programming Lang: C++ (Qt) Description : KIT Scenarist – screenplay editor KIT Scenarist is a program for creating screenplays which oriented at international standards in the field of film production. The program is a full-featured studio for creating stories from the birth of the idea and before the transfer of the script to production.
Bug#921202: ITP: votca-xtp -- Exciton transport simulation for VOTCA
Package: wnpp Severity: wishlist Owner: Debichem Team * Package name: votca-xtp Version : 1.5.0 Upstream Author : Christoph Junghans and others * URL : http://www.votca.org/ * License : Apache 2.0 Programming Lang: C++ Description : Exciton transport simulation for VOTCA VOTCA is a software package which focuses on the analysis of molecular dynamics data, the development of systematic coarse-graining techniques as well as methods used for simulating microscopic charge transport in disordered semiconductors. . xtp is Votca's exciton transport simulation engine. This extends the existing src:votca-tools and src:votca-csg, and will be maintained by the Debichem team.
Bug#921201: ruby-sinatra: Remove self-build-depends on ruby-rack-protection, ruby-sinatra-contrib
Package: ruby-sinatra Version: 2.0.5-4 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu disco ubuntu-patch The latest ruby-sinatra package build-depends on ruby-sinatra-contrib and ruby-rack-protection, but these are binary packages built from this very same source. This unnecessarily complicates bootstrapping of the package; although these dependencies can be bypassed via a 'nocheck' build, that is an unnecessary extra step given that the bits provided by these external packages are guaranteeably already present in the source. In order to bootstrap this package for Ubuntu, I have dropped these self-build-dependencies and the package built with no issues. Please consider applying this patch in Debian. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org diff -Nru ruby-sinatra-2.0.5/debian/control ruby-sinatra-2.0.5/debian/control --- ruby-sinatra-2.0.5/debian/control 2019-01-21 13:02:20.0 -0800 +++ ruby-sinatra-2.0.5/debian/control 2019-02-02 16:13:57.0 -0800 @@ -23,13 +23,11 @@ ruby-nokogiri , ruby-rabl , ruby-rack (>= 2.0~) , - ruby-rack-protection (>= 2.0.5~) , ruby-rack-test , ruby-rdiscount , ruby-redcarpet , ruby-redcloth , ruby-sass , - ruby-sinatra-contrib , ruby-slim (>= 3.0~) , ruby-tilt (>= 2.0~) , ruby-wikicloth ,
Bug#778664: pam: Patch for pam_1.1.8-3.6
Package: pam Version: 1.1.8-3.6 Followup-For: Bug #778664 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu disco ubuntu-patch Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: The patch fixes the issue, please see LP bug 1666203. Following fix was implemented as mentioned by the reporter of the LP bug: https://github.com/linux-pam/linux-pam/commit/c5f829931a22c65feffee16570efdae036524bee I tested the patch and it indeed resolves the issue: pam_tty_audit now works as expected and users are still able to login after adding: session required pam_tty_audit.so enable=root to /etc/pam.d/common-session "aureport --tty" shows the expected output. * Fix: pam_tty_audit failed in pam_open_session (LP: #1666203) Thanks for considering the patch. -- System Information: Debian Release: buster/sid APT prefers bionic-updates APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 'bionic'), (100, 'bionic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-44-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru pam-1.1.8/debian/control pam-1.1.8/debian/control --- pam-1.1.8/debian/control2018-04-04 23:56:02.0 +0200 +++ pam-1.1.8/debian/control2019-02-03 01:01:57.0 +0100 @@ -2,8 +2,7 @@ Section: libs Priority: optional Uploaders: Sam Hartman , Roger Leigh -Maintainer: Ubuntu Developers -XSBC-Original-Maintainer: Steve Langasek +Maintainer: Steve Langasek Standards-Version: 3.9.8 Build-Depends: libcrack2-dev (>= 2.8), bzip2, debhelper (>= 9), quilt (>= 0.48-1), flex, libdb-dev, libselinux1-dev [linux-any], po-debconf, dh-autoreconf, autopoint, libaudit-dev [linux-any], pkg-config, libfl-dev, libfl-dev:native, docbook-xsl, docbook-xml, xsltproc, libxml2-utils, w3m Build-Conflicts-Indep: fop diff -Nru pam-1.1.8/modules/pam_tty_audit/pam_tty_audit.c pam-1.1.8/modules/pam_tty_audit/pam_tty_audit.c --- pam-1.1.8/modules/pam_tty_audit/pam_tty_audit.c 2018-04-04 23:56:02.0 +0200 +++ pam-1.1.8/modules/pam_tty_audit/pam_tty_audit.c 2019-02-03 01:01:57.0 +0100 @@ -36,6 +36,7 @@ USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ +#include "config.h" #include #include #include @@ -275,6 +276,8 @@ return PAM_SESSION_ERR; } + memcpy(_status, old_status, sizeof(new_status)); + new_status.enabled = (command == CMD_ENABLE ? 1 : 0); #ifdef HAVE_STRUCT_AUDIT_TTY_STATUS_LOG_PASSWD new_status.log_passwd = log_passwd;
Bug#920116: u-boot-exynos: broken console setting on odroid-U3
Hi,
On Mon, 21 Jan 2019 15:00:11 -0800 Vagrant Cascadian wrote:
> Package: u-boot-exynos
> Version: 2019.01+dfsg-1
> Severity: important
>
> Upstream reverted a patch that was present in all v2018.x u-boot
> versions that sets the console variable to include the console=
> argument, so boot scripts will set console=console=ttyAC1,115200
instead
> of console=ttyAC1,115200.
>
>
https://git.denx.de/?p=u-boot.git;a=commit;h=767edf0f6b3eaa0303f3fd6afdc14ddce0aca70c
>
> In order for platforms to behave consistantly on Debian, Debian's u-
boot
> package should re-apply the patch (which was carried in one form or
> another for prior Debian u-boot-exynos packages)...
>
> Interestingly enough, as of stretch's kernel, odroid-U3 doesn't need
to
> set a console= argument at all, linux will get the appropriate values
> from the device-tree.
I stumbled over exactly the same issue with my Odroid HC1 board.
Attached a patch to address the reason for the revert and revert the
revert.
--
Benjamin Drung
Debian & Ubuntu Developer
From 82987dbf64ab031482eee52267e2fb1edce52531 Mon Sep 17 00:00:00 2001
From: Dongjin Kim
Date: Sat, 28 Oct 2017 00:22:27 -0400
Subject: [PATCH] arm: config: fix default console only to specify the device
This reverts commit 767edf0f6b3eaa0303f3fd6afdc14ddce0aca70c and restores
commit 232ed3ca534708527a9515c7c41bc3542949525c.
Debian's flash-kernel expect the console variable to just contain the device,
because it will set the bootargs to "console=${console}". So revert adding
"console=" to the console parameter, but also adjust the shipped bootscripts
for exynos boards to cope with it.
Bug-Debian: https://bugs.debian.org/920116
Signed-off-by: Benjamin Drung
---
board/samsung/common/bootscripts/autoboot.cmd | 2 +-
board/samsung/common/bootscripts/bootzimg.cmd | 4 ++--
board/samsung/common/dfu_sample_env.txt | 4 ++--
include/configs/odroid.h | 4 ++--
include/configs/odroid_xu3.h | 4 ++--
include/configs/s5p_goni.h| 4 ++--
include/configs/s5pc210_universal.h | 4 ++--
include/configs/trats.h | 4 ++--
include/configs/trats2.h | 4 ++--
9 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/board/samsung/common/bootscripts/autoboot.cmd b/board/samsung/common/bootscripts/autoboot.cmd
index 11c724c4e09..e0c691e6656 100644
--- a/board/samsung/common/bootscripts/autoboot.cmd
+++ b/board/samsung/common/bootscripts/autoboot.cmd
@@ -12,7 +12,7 @@ setenv initrdaddr "4200"
setenv loaddtb "load mmc ${mmcbootdev}:${mmcbootpart} ${fdtaddr} ${fdtfile}"
setenv loadinitrd "load mmc ${mmcbootdev}:${mmcbootpart} ${initrdaddr} ${initrdname}"
setenv loadkernel "load mmc ${mmcbootdev}:${mmcbootpart} '${kerneladdr}' '${kernelname}'"
-setenv kernel_args "setenv bootargs ${console} root=/dev/mmcblk${mmcrootdev}p${mmcrootpart} rootfstype=${rootfstype} rootwait ${opts}"
+setenv kernel_args "setenv bootargs console=${console} root=/dev/mmcblk${mmcrootdev}p${mmcrootpart} rootfstype=${rootfstype} rootwait ${opts}"
Routine: check_dtb - check that target.dtb exists on boot partition
setenv check_dtb "
diff --git a/board/samsung/common/bootscripts/bootzimg.cmd b/board/samsung/common/bootscripts/bootzimg.cmd
index 2fb4c163a73..ea4bec47646 100644
--- a/board/samsung/common/bootscripts/bootzimg.cmd
+++ b/board/samsung/common/bootscripts/bootzimg.cmd
@@ -1,5 +1,5 @@
setenv kernelname zImage;
-setenv boot_kernel "setenv bootargs \"${console} root=/dev/mmcblk${mmcrootdev}p${mmcrootpart} rootfstype=${rootfstype} rootwait ${opts}\";
+setenv boot_kernel "setenv bootargs \"console=${console} root=/dev/mmcblk${mmcrootdev}p${mmcrootpart} rootfstype=${rootfstype} rootwait ${opts}\";
load mmc ${mmcbootdev}:${mmcbootpart} 0x40007FC0 '${kernelname}';
if load mmc ${mmcbootdev}:${mmcbootpart} 4080 ${fdtfile}; then
bootz 0x40007FC0 - 4080;
@@ -7,4 +7,4 @@ else
echo Warning! Booting without DTB: '${fdtfile}'!;
bootz 0x40007FC0 -;
fi;"
-run boot_kernel;
\ No newline at end of file
+run boot_kernel;
diff --git a/board/samsung/common/dfu_sample_env.txt b/board/samsung/common/dfu_sample_env.txt
index d6ee8a228a8..cbd788ec670 100644
--- a/board/samsung/common/dfu_sample_env.txt
+++ b/board/samsung/common/dfu_sample_env.txt
@@ -1,9 +1,9 @@
-mmcboot=setenv bootargs root=/dev/mmcblk${mmcdev}p${mmcrootpart} ${rootfstype} rootwait ${console}; run loaduimage; bootm 0x40007FC0
+mmcboot=setenv bootargs root=/dev/mmcblk${mmcdev}p${mmcrootpart} ${rootfstype} rootwait console=${console}; run loaduimage; bootm 0x40007FC0
rootfstype=ext4
loaduimage=ext4load mmc ${mmcdev}:${mmcbootpart} 0x40007FC0 uImage
mmcdev=0
mmcbootpart=2
mmcrootpart=5
-console=console=ttySAC2,115200n8
+console=ttySAC2,115200n8
bootcmd=run mmcboot
dfu_alt_info=u-boot mmc 80 800;params.bin mmc 0x38 0x8;uImage ext4 0 2
diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index
Bug#804299: smartmontools: update-smart-drivedb currently risky
On Sat, 2019-02-02 at 22:11 +0100, Christian Franke wrote: > The script creates a temporary gpg homedir, imports the key, > verifies > the file and then removes the gpg homedir. See function gpg_verify(). Seems you're right... as I've said previously I only had a very short glance over the current version of script :-) Cheers, Chris.
Bug#821254: systemd[1]: xendomains.service start operation timed out.
Hi Hans, On Sat, Feb 02, 2019 at 11:24:36PM +0100, Hans van Kranenburg wrote: > When working on actually shipping systemd units we'd really need > to have a group of users that want to actively help testing > everything. Downgrade, upgrade, try to break it etc... I actually ended up going from Debian-packaged 4.4.x to Mark Pryor's Debian packages because I needed to upgrade version and patch some XSAs during embargo. At the time there wasn't much going on with the Debian packaging and I didn't feel confident to do it myself, so I based things off of Mark's work. I used that as a basis for 4.8.x and now 4.10.x packages. Now that you are helping with Debian packaging I would like to come back to Debian's packages, probably along with an upgrade to buster. The systemd stuff from those packages of Mark's did solve this problem though. I assume this is upstream content. I think in 4.4 it was generating a systemd service from an init script, whereas now it's a native systemd service. Here's /lib/systemd/system/xendomains.service: [Unit] Description=Xendomains - start and stop guests on boot and shutdown Requires=proc-xen.mount xenstored.service After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service After=network-online.target After=remote-fs.target ConditionPathExists=/proc/xen/capabilities Conflicts=libvirtd.service [Service] Type=oneshot RemainAfterExit=true ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities ExecStart=-/usr/lib/xen-4.10/bin/xendomains start ExecStop=/usr/lib/xen-4.10/bin/xendomains stop ExecReload=/usr/lib/xen-4.10/bin/xendomains restart [Install] WantedBy=multi-user.target Those packages came from: http://107.185.106.30/xen/debian/stretch-nmu/4ax/ (plus the XSAs published since then) Would it be helpful if I installed buster and xen-hypervisor-4.11-amd64 and checked how the systemd unit files cope with trying to start 75 or so domains? If so I will try to find some time to try that, Cheers, Andy
Bug#921200: vkd3d: misses dependency on libvulkan1
Source: vkd3d Version: 1.1-2 Severity: normal [resend to the bts] Hi Mike On 02.02.19 08:56, Michael Gilbert wrote: > On Fri, Feb 1, 2019 at 10:38 PM Jens Reyer wrote: >> vkd3d has no runtime dependency on libvulkan1 or any other vulkan >> related packages. So with the currently existing package relationships >> you can build vkd3d with newer vulkan and then install it next to wine >> with older vulkan.[1] > > This is an error in the packaging. Vulkan is loaded via dlopen, so an > explicit dependency is needed but missing. That could be automated as > is done in wine with sonames2elf. Ah, now I understand, thanks! Filing this as a bug for now. I had a first look into libvulkan1' symbols and (if I get this correctly) it seems symbols get frequently dropped. I'll have to talk vulkan's maintainers about that. Greets jre
Bug#897752: freefem3d: ftbfs with GCC-8
Control: tags -1 patch The error is In file included from FatBoundary.cpp:25: ./FEMDiscretization.hpp:647:7: error: too many template-parameter-lists class FEMDiscretization ^~~~ Fix: Description: Use correct syntax for partial template specialization This is probably unused (the use in FatBoundary is commented out), which would explain it only being an FTBFS in GCC 8 and not sooner: https://gcc.gnu.org/gcc-8/porting_to.html#hypothetical-instantiation Author: Rebecca N. Palmer Bug-Debian: https://bugs.debian.org/897752 Forwarded: no --- a/solver/FEMDiscretization.hpp +++ b/solver/FEMDiscretization.hpp @@ -642,7 +642,6 @@ public: * It is an important specialization since the elementary matrices are * computed \b once for all! */ -template <> template class FEMDiscretization : public BaseFEMDiscretization
Bug#908172: next steps ? sbuild working etc...
So I have sbuild working now with no lintian error for 1.3.1-1 How can we turn it into an actual debian package/what are the next steps? https://github.com/fortio/fortio/releases/tag/v1.3.1 Thanks Laurent
Bug#821254: systemd[1]: xendomains.service start operation timed out.
Hi Andy, Just to set expectations... Ian is not using systemd at all, and for me, the current whatever init script stuff there is does its thing for my usecase at work. I don't use xendomains, I use live migrate to drain physical servers so I can reboot / upgrade / whatever them without any need to hurry. TBH, all the extra-time I had for working on Debian/Xen in the last months was eaten by getting things fixed for myself, like live migration bugs. Yesterday, we spend the day working on the Buster TODO list, and in the beginning of the day we identified "init scripts and systemd" as the main topic of the day. However, when starting to look into that, it quickly became clear that "just" merging the debian and upstream init scripts is not a trivial operation (it needs discussion with the redhat-based users). When working on actually shipping systemd units we'd really need to have a group of users that want to actively help testing everything. Downgrade, upgrade, try to break it etc... For buster, there will be a notice in the "known-issues" section of README.Debian about this issue. If you have an idea about how to change this timeout then please share. Don't wait for it to magically happen. :) Hans
Bug#921199: /usr/lib/php/20180731/intl.so: undefined symbol: spoofchecker_register_constants
Package: php7.3-common Version: 7.3.1-2 Severity: normal Hi! The change for "#916110 php7.3: Please use pkg-config to detect icu" seems to cause a regression, because since then PHP throws errors like this: Feb 02 22:39:03 server sessionclean[3281181]: PHP Warning: PHP Startup: Unable to load dynamic library 'intl.so' (tried: /usr/lib/php/20180731/intl.so (/usr/lib/php/20180731/intl.so: undefined symbol: spoofchecker_register_constants), /usr/lib/php/20180731/intl.so.so (/usr/lib/php/20180731/intl.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0 Or when starting FPM: Feb 02 23:07:35 server systemd[1]: Starting The PHP 7.3 FastCGI Process Manager... Feb 02 23:07:36 server php-fpm7.3[3314177]: [02-Feb-2019 23:07:36] NOTICE: PHP message: PHP Warning: PHP Startup: Unable to load dynamic library 'intl.so' (tried: /usr/lib/php/20180731/intl.so (/usr/lib/php/20180731/intl.so: undefined symbol: spoofchecker_register_constants), /usr/lib/php/20180731/intl.so.so (/usr/lib/php/20180731/intl.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0 Feb 02 23:07:36 server systemd[1]: Started The PHP 7.3 FastCGI Process Manager. There also exists a Ubuntu bug for this: https://bugs.launchpad.net/ubuntu/+source/php7.3/+bug/1813438 Grüße, Sven. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (200, 'experimental'), (1, 'experimental-debug') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages php7.3 depends on: ii php7.3-cgi 7.3.1-2 ii php7.3-common 7.3.1-2 ii php7.3-fpm 7.3.1-2 php7.3 recommends no packages. php7.3 suggests no packages. Versions of packages php7.3-common depends on: ii libc6 2.28-5 ii libssl1.1 1.1.1a-1 ii php-common 2:69 ii ucf 3.0038+nmu1 -- debconf-show failed
Bug#921198: gnutls28/3.6.6-2 FTBFS on mipsel (Failing test?)
Source: gnutls28 Version: 3.6.6-2 Severity: serious Justification: FTBFS Hi gnutls28/3.6.6-2 FTBFS on mipsel: https://buildd.debian.org/status/fetch.php?pkg=gnutls28=mipsel=3.6.6-2=1549113962=0 apparently a failing test, not sure if it was already know, so filling the bug for tracking the issue. But from previous builds it looks the build failed as well for previous versions at least depending of version and build host. Regards, Salvatore
Bug#921197: glade: GtkStatusbar is missing from the Containers list
Package: glade Version: 3.22.1-3 Severity: normal Dear Maintainer, while trying to find a way to add a GtkStatusbar on a window, no relative selection is found on Glade's GUI A web search revealed https://gitlab.gnome.org/GNOME/glade/issues/302 which in short informs that: a. the GtkStatusbar appears in version 3.20.0, but it is not in 3.22.1 b. the issue is resolved on master 9 months ago c. the workaround is to edit /usr/share/glade/catalogs/gtk+.xml and add just below I confirm the above workaround is working on my system. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), LANGUAGE=el_GR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages glade depends on: ii libc6 2.28-5 ii libcairo2 1.16.0-2 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libgladeui-2-6 3.22.1-3 ii libglib2.0-02.58.2-3 ii libgtk-3-0 3.24.4-1 ii libpango-1.0-0 1.42.4-6 Versions of packages glade recommends: ii devhelp 3.30.1-1 ii libgtk-3-dev 3.24.4-1 glade suggests no packages. -- no debconf information
Bug#897722: clsparse: ftbfs with GCC-8
Control: tags -1 upstream patch
Control: forwarded -1 https://github.com/clMathLibraries/clSPARSE/pull/210
fix for this:
Description: Remove unused and unbuildable GetTypecode
This template function is unused (not in any public headers and
not called from within clSPARSE), and has always been
non-instantiable (and hence unusable) as char[4] to char& is an
invalid conversion.
Older GCC didn't check this until it was attempted, which it isn't
(instantiating a class template only instantiates those member
functions that are used), but in GCC 8 its existence is an error.
Author: Rebecca N. Palmer
Bug-Debian: https://bugs.debian.org/897722
Forwarded: https://github.com/clMathLibraries/clSPARSE/pull/210
--- a/src/benchmarks/cusparse-bench/src/mm_reader.cpp
+++ b/src/benchmarks/cusparse-bench/src/mm_reader.cpp
@@ -103,11 +103,6 @@ public:
return isSymmetric;
}
-char ( )
-{
-return Typecode;
-}
-
Coordinate *GetUnsymCoordinates( )
{
return unsym_coords;
--- a/src/library/io/mm-reader.cpp
+++ b/src/library/io/mm-reader.cpp
@@ -118,11 +118,6 @@ public:
return isSymmetric;
}
-char ( )
-{
-return Typecode;
-}
-
Coordinate *GetUnsymCoordinates( )
{
return unsym_coords;
Bug#920777: Acknowledgement (ITP: libxmlb -- XML binary library)
Packaging moved to https://salsa.debian.org/efi-team/libxmlb/tree/debian > -Original Message- > From: Limonciello, Mario > Sent: Monday, January 28, 2019 8:44 PM > To: 920...@bugs.debian.org > Subject: Bug#920777: Acknowledgement (ITP: libxmlb -- XML binary library) > > > [EXTERNAL EMAIL] > > Initial packaging available here: > https://github.com/superm1/libxmlb/tree/debian
Bug#921095: gajim: traceback when starting gajim: got an unexpected keyword argument 'lang'
Control: severity -1 normal Hi, please install python3-nbxmpp 0.6.9-1 from testing, then it will be OK. The gajim package is still missing the correctly versioned dependency, but it's solved in git since ten days: https://salsa.debian.org/xmpp-team/gajim/commit/04fa00c7b1cff05e6e63ada6751f2d13a3955577 So this will be fixed with the next upload. Sorry for the inconvenience! Cheers
Bug#912381: pygrub is borken in 4.11
Hi, We aim to have a working pygrub in Buster, regardless of the fact that using grub2-based boot images is the prefered upgrade path. This issue is on our Buster TODO list: https://salsa.debian.org/xen-team/debian-xen/issues/24 Hans
Bug#862236: xen-utils-common hotplugpath.sh has architecture dependent bits
Hi, This issue is on our Buster TODO list: https://salsa.debian.org/xen-team/debian-xen/issues/24 Hans
Bug#798510: utils-common: xendomains domU auto-starting fails (dependency on network)
Hi, Thanks for your report. FYI Actually fixing this is on the TODO list for Buster: https://salsa.debian.org/xen-team/debian-xen/issues/24 It's true that in order to have xendomains restore things after reboot, the network bridge has to be functional, so it's clear that this has to be fixed. Hans
Bug#920984: nextcloud-desktop: Client forgets credentials
Package: nextcloud-desktop Version: 2.5.1-1 Followup-For: Bug #920984 I can confirm this with XFCE. That is the same issue I filed against the owncloud-client. Building the package with libsecret installed, solved it. I know, there is no dependency on libsecret, but it worked. Regards Thomas -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nextcloud-desktop depends on: ii libc6 2.28-5 ii libgcc1 1:8.2.0-15 ii libnextcloudsync0 2.5.1-1 ii libqt5concurrent5 5.11.3+dfsg-2 ii libqt5core5a 5.11.3+dfsg-2 ii libqt5dbus5 5.11.3+dfsg-2 ii libqt5gui55.11.3+dfsg-2 ii libqt5keychain1 0.9.0-2 ii libqt5network55.11.3+dfsg-2 ii libqt5positioning55.11.3+dfsg-2 ii libqt5printsupport5 5.11.3+dfsg-2 ii libqt5qml55.11.3-2 ii libqt5quick5 5.11.3-2 ii libqt5sql5-sqlite 5.11.3+dfsg-2 ii libqt5webchannel5 5.11.3-2 ii libqt5webenginecore5 5.11.3+dfsg-2+b1 ii libqt5webenginewidgets5 5.11.3+dfsg-2+b1 ii libqt5webkit5 5.212.0~alpha2-19 ii libqt5widgets55.11.3+dfsg-2 ii libqt5xml55.11.3+dfsg-2 ii libsqlite3-0 3.26.0+fossilbc891ac6b-2 ii libssl1.1 1.1.1a-1 ii libstdc++68.2.0-15 ii nextcloud-desktop-common 2.5.1-1 ii nextcloud-desktop-l10n2.5.1-1 ii zlib1g1:1.2.11.dfsg-1 Versions of packages nextcloud-desktop recommends: ii nextcloud-desktop-doc 2.5.1-1 nextcloud-desktop suggests no packages. -- no debconf information
Bug#921196: RM: os-autoinst [arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x kfreebsd-amd64] -- ANAIS; no longer built for all architectures
Package: ftp.debian.org Severity: normal os-autoinst (4.5.1527308405.8b586d5-4) unstable; urgency=medium * debian/control - just build for i386 and amd64 for now... -- Hideki Yamane Sun, 06 Jan 2019 15:22:32 +0900
Bug#921195: mcabber: does not connect to Jabber via IPv6 (fails Etch release goal)
Package: mcabber Version: 1.1.0-1.1 Severity: serious Tags: ipv6 Justification: fails release goal I’m currently in the FOSDEM WLAN (IPv6-only, not FOSDEM-legacy), and I can neither connect to the Jabber server with SRV RRs nor when hardcoding commu.teckids.org in mcabberrc. A netcat on commu.teckids.org port 5223 works, so it’s the client. -- System Information: Debian Release: buster/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages mcabber depends on: ii libaspell15 0.60.7~20110707-5 ii libassuan0 2.5.2-1 ii libc62.28-5 ii libglib2.0-0 2.58.2-4 ii libgpg-error01.33-3 ii libgpgme11 1.12.0-6 ii libidn11 1.33-2.2 ii libloudmouth1-0 1.5.3-4 ii libncursesw6 6.1+20181013-1 ii libotr5 4.1.1-3 ii libtinfo66.1+20181013-1 mcabber recommends no packages. mcabber suggests no packages. -- no debconf information
Bug#921194: amarok: Amarok depends on libmariadbd18, which doesn't exist any longer
Package: amarok Version: 2.9.0-1+b1 Severity: normal Tags: a11y Dear Maintainer, libmariadbd18 does not exist any longer, but Amarok still depends on it. This would make Amarok uninstallable unless one has installed it from other sources or has kept it from when it was available in the repos. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), LANGUAGE=sv (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages amarok depends on: ii amarok-common2.9.0-1 ii amarok-utils 2.9.0-1+b1 ii kde-runtime 4:17.08.3-2 ii libavcodec58 10:4.1-dmo4 ii libavformat5810:4.1-dmo4 ii libavutil56 10:4.1-dmo4 ii libc62.28-5 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libgl1 1.1.0-1 ii libglib2.0-0 2.58.2-3 ii libgpod4 0.8.3-13 ii libkcmutils4 4:4.14.38-3 ii libkdecore5 4:4.14.38-3 ii libkdeui54:4.14.38-3 ii libkdewebkit54:4.14.38-3 ii libkdnssd4 4:4.14.38-3 ii libkfile44:4.14.38-3 ii libkio5 4:4.14.38-3 ii libknewstuff3-4 4:4.14.38-3 ii libktexteditor4 4:4.14.38-3 ii liblastfm1 1.0.9-1 ii libmariadbclient18 [libmariadbclient18] 1:10.3.12-2 ii libmariadbd181:10.1.37-3 ii libmtp9 1.1.16-1 ii libofa0 0.9.3-19 ii libphonon4 4:4.10.2-1 ii libplasma3 4:4.14.38-3 ii libqca2 2.1.3-2 ii libqjson00.8.1-3+b1 ii libqt4-dbus 4:4.8.7+dfsg-17 ii libqt4-network 4:4.8.7+dfsg-17 ii libqt4-opengl4:4.8.7+dfsg-17 ii libqt4-script4:4.8.7+dfsg-17 ii libqt4-scripttools 4:4.8.7+dfsg-17 ii libqt4-sql 4:4.8.7+dfsg-17 ii libqt4-svg 4:4.8.7+dfsg-17 ii libqt4-xml 4:4.8.7+dfsg-17 ii libqtcore4 4:4.8.7+dfsg-17 ii libqtgui44:4.8.7+dfsg-17 ii libqtscript4-core0.2.0-1+b1 ii libqtscript4-gui 0.2.0-1+b1 ii libqtscript4-network 0.2.0-1+b1 ii libqtscript4-sql 0.2.0-1+b1 ii libqtscript4-uitools 0.2.0-1+b1 ii libqtscript4-xml 0.2.0-1+b1 ii libqtwebkit4 2.3.4.dfsg-10 ii libsolid44:4.14.38-3 ii libstdc++6 8.2.0-15 ii libthreadweaver4 4:4.14.38-3 ii libx11-6 2:1.6.7-1 ii phonon 4:4.10.2-1 Versions of packages amarok recommends: pn clamz pn kio-audiocd Versions of packages amarok suggests: pn amarok-doc ii libqt4-sql-mysql 4:4.8.7+dfsg-17 pn libqt4-sql-psql ii libqt4-sql-sqlite 4:4.8.7+dfsg-17 pn moodbar Versions of packages amarok-common depends on: ii perl 5.28.1-3 amarok-common recommends no packages. Versions of packages amarok is related to: ii phonon-backend-gstreamer [phonon-backend] 4:4.9.0-1 -- no debconf information
Bug#921193: libmkl-rt: Octave returns wrong results when large arrays are multiplied
Package: libmkl-rt Version: 2019.1.144-4 Severity: important Dear Maintainer, After installing intel-mkl and setting MKL as default BLAS/LAPACK implementation, wrong results are obtained when large arrays are multiplied in octave. Here is the output of a MWE: octave:1> x1=0:10;[x1;x1]*[x1;x1]' ans = 450792059465624 472496191531028 512874660819596 531922410008450 This result is absolutely wrong. All the elements in the 'ans' matrix should have the same value. For example, after changing back to the original BLAS/LAPACK implementation, the result is octave:1> x1=0:10;[x1;x1]*[x1;x1]' ans = 385 385 385 385 which is the right one. Regards Ido -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libmkl-rt depends on: ii debconf [debconf-2.0] 1.5.70 ii libatlas3-base [liblapack.so.3]3.10.3-7+b1 ii libblas3 [libblas.so.3]3.8.0-2 ii libc6 2.28-5 ii libgcc-5-dev 5.4.1-4 ii libgcc-6-dev 6.5.0-1 ii libgcc-7-dev 7.4.0-2 ii libgcc-8-dev 8.2.0-15 ii liblapack3 [liblapack.so.3]3.8.0-2 ii libmkl-locale 2019.1.144-4 ii libmkl-meta-computational 2019.1.144-4 ii libmkl-meta-interface 2019.1.144-4 ii libmkl-meta-threading 2019.1.144-4 ii libomp-7-dev 1:7.0.1-4 ii libomp-dev 1:7.0-47 ii libopenblas-base [liblapack.so.3] 0.3.5+ds-1 libmkl-rt recommends no packages. libmkl-rt suggests no packages. -- debconf information: * libmkl-rt/use-as-default-blas-lapack: true * libmkl-rt/exact-so-3-selections: libblas.so.3, liblapack.so.3, libblas64.so.3, liblapack64.so.3, libmkl-rt/title:
Bug#921192: libmojo-sqlite-perl: binary-all package with :amd64 dependencies
Package: libmojo-sqlite-perl Version: 3.001-1 Severity: serious Package: libmojo-sqlite-perl Architecture: all Depends: libdbd-sqlite3-perl:amd64 (>= 1.54), libdbi-perl:amd64 (>= 1.627), ... This does not make sense - either it works without the :amd64, or it should become Architecture: amd64 (and also drop the :amd64).
Bug#921191: RFP: edit-indirect -- Edit regions in separate buffers, like `org-edit-src-code' but for arbitrary regions
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: edit-indirect Version : 0.1.5 Upstream Author : Fanael Linithien * URL : https://github.com/Fanael/edit-indirect.git * License : BSD Programming Lang: emacs-lisp Description : Edit regions in separate buffers, like `org-edit-src-code' but for arbitrary regions Edit the region BEG..END in a separate buffer. The region is copied, without text properties, to a separate buffer, called edit-indirect buffer, and `edit-indirect-guess-mode-function' is called to set the major mode. When done, exit with `edit-indirect-commit', which will remove the original region and replace it with the edited version; or with `edit-indirect-abort', which will drop the modifications. This differs from `clone-indirect-buffer' with narrowing in that the text properties are not shared, so the parent buffer major mode and the edit-indirect buffer major mode will not be able to tread on each other's toes by setting up potentially conflicting text properties, which happens surprisingly often when the font-lock mode is used. This should be maintained by the emacs-addons-team. If no-one else is inspired, I'll eventually get around to packaging it. There is preliminary packaging at https://salsa.debian.org/emacsen-team/edit-indirect -BEGIN PGP SIGNATURE- iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlxWCGIACgkQ8gKXHaSn nizAsAv6AlH8FrLzm8DQVxJWQwh25fhJKIpMqCZm41+UyVhWvtUBVLRL2lunVeuJ 3I48bcDr8z764uSgpAsnh58dXWiid9HLIUgKMg6NpO5tMlKUqkdQK7zrQrhkQZ3w fHAQdgBi6vQVHoeXyD3hGcoiAT7oXtzQkVMLs+8DCz06+W/XLUmCl8y0zRB4r+Rl gB3ZtidE4mznNKagqNy9FGh7iDI7LRqIky0/ap7jvvTz8y8OYStRITPQpcxxLJsl j9DLERDkTEubtyz0XEOSr+Ql1j67YkeMIwNzxm5RzzxwCspDVz/SRJ0yNTQ/sEm7 3/QtbDsTWpPPngEHDM8i0F6WMyJH4YSOO6uCabhdk20ERdH4Aa9a8pN9+XvJ84dD r+iVcvUzMFtXxWOPtgHxOLOk6HdgDmKUpXsmfgY7KGpC1NymJ+bDPT5eVpd84L62 1Po1fEdW3d7s4U8bhz3Tqf5ewWF+et+qyd+XFLW5DjFksIwYGmHUPr9LkEa6ROHk OrDVXT+j =MrLQ -END PGP SIGNATURE-
Bug#804299: smartmontools: update-smart-drivedb currently risky
Marc Haber wrote: On Thu, Jan 10, 2019 at 03:47:24PM +0100, Christoph Anton Mitterer wrote: ... Plus it automatically imports the shipped public key into the keyring of the executing user… which is IMO also unacceptable. Agreed, the script should use its own keyring. The script creates a temporary gpg homedir, imports the key, verifies the file and then removes the gpg homedir. See function gpg_verify(). So it actually uses its own keyring and does not touch user's ~/.gnupg :-) Cheers, Christian
Bug#921190: ClamAV installation is OUTDATED
Package: clamav Version: 0.100.2+dfsg-0+deb9u1 Since Feb 1, freshclam will log: WARNING: Your ClamAV installation is OUTDATED! WARNING: Local version: 0.100.2 Recommended version: 0.101.1 Is it possible to back port 0.101.1+dfsg-1? into stable? Thanks, -- Frans van Berckel Media Engineer / Linux Master LinkedIn: https://www.linkedin.com/in/fransvberckel/
Bug#921189: postsrsd FTBFS on 64bit big endian: AllTests (Failed)
Source: postsrsd
Version: 1.5-1
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/package.php?p=postsrsd
...
dh_auto_test -a -O--buildsystem=cmake
cd obj-s390x-linux-gnu && make -j2 test ARGS\+=-j2
make[1]: Entering directory '/<>/obj-s390x-linux-gnu'
Running tests...
/usr/bin/ctest --force-new-ctest-process -j2
Test project /<>/obj-s390x-linux-gnu
Start 1: AllTests
1/1 Test #1: AllTests .***Failed0.00 sec
srs_forward("n@w", "example.com") = 0
srs_reverse("SRS0=Nl1u=P7=w=n...@example.com") = 0
srs_reverse("SRS0=Nl1u=P7=w=o...@example.com") = 0
0% tests passed, 1 tests failed out of 1
Total Test time (real) = 0.00 sec
The following tests FAILED:
1 - AllTests (Failed)
Errors while running CTest
make[1]: *** [Makefile:99: test] Error 8
Bug#900761: please separate passwd manipulation from the library package, together with expect et al
Control: -1 tags +wontfix Hello Josip, On 6/4/18 2:16 PM, Josip Rodin wrote: > For some reason there exists an expect script in > /usr/lib/courier/courier-authlib/authsystem.passwd > which seems to be calling passwd(1), > which causes courier-authlib to depend on expect(1), > which in turn has a bunch of other dependencies, > which in turn gets installed on all systems where users want packages > that happen to depend on courier-authlib (regardless of whether those > users actually use the authlib's facilities) the authlib library itself actually provides means to change passwords, using expect in case you're using system accounts (as opposed to some database for example). The recommendation to install expect therefore seems entirely justified. It's not like you cannot remove it or ignore the recommendation. > In my case, the latter is maildrop, which honestly I have no idea whatsoever > how it could ever come into a situation where it would want the > authentication subsystem to invoke a user password change. Ugh.. how else would you change the password, if not via the authentication subsystem? > In fact I'm pretty sure someone would slap us with a critical security bug > if it ever came to pass that a mail filtering utility was even attempting > to manipulate the password of a user for whom it was filtering mail. I agree here. > Please separate this functionality from the library package into a separate > package, which can then depend on and invoke whatever it needs. I fear that's not possible, as it would mean splitting the library itself. Please speak up if you have ideas or wishes on what the packaging could do to improve your use case. Otherwise, I'll close this issue. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature
Bug#921187: Getting rid of rdepends on libxenmisc4.X so we can do backports
Package: src:xen Version: 4.11.1-1 Currently, these are rdepends: -$ apt-cache rdepends libxenmisc4.11 libxenmisc4.11 Reverse Depends: libxen-dev xen-utils-4.11 collectd qemu-system-x86 libvirt-daemon collectd-core It's on the wishlist to start doing buster-backports for Xen. If the user has a cluster of servers and can make use of live migrate, then this allows the user to keep rolling-upgrading and following new Xen releases without domU mass-reboots and downtime. Live migration is only supported from N to N+1 versions, so e.g. from 4.10 to 4.11, but not e.g. from 4.4 to 4.10. The qemu one here is the most important/urgent one. Having this dependency means that users of backports cannot use HVM, or that there also need to be qemu backports. When redoing the packaging in Q3 2018, all libraries with upstream stable ABI were split off into packages with its own version number, like libxendevicemodel1, libxenevtchn1, etc. We think there's technically no reason that qemu has to depend on libxenmisc4.11, so maybe it's the shlibs machinery that is confused. Task here: find out why this is happening and see if the dependency can be removed. Apparently collectd and libvirt have a similar problem.
Bug#921188: Include pkgconfig file
Package: libbpfcc-dev Version: 0.8.0-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey! Could you please include the .pc file which is provided upstream? It would help to build projects depending on libbcc (like bpftrace). Also, the -dev is missing the .so which is shipped in the non -dev package. You should move it to the -dev package. Thanks! - -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libbpfcc-dev depends on: ii libbpfcc 0.8.0-1 libbpfcc-dev recommends no packages. libbpfcc-dev suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAlxV/UcSHGJlcm5hdEBk ZWJpYW4ub3JnAAoJEJWkL+g1NSX5dOYP/RnmtE2B7Ngwy5VlegOoixUB4L6SZdkr kLOY5IWL9hkagLHQcwdznG5oQMHKq3ItCdGxZ3Vavh0HETzA0yRONdkocd+yJzK6 DMXmEGagDuypseJtZ8Rct3BLjaNhYm+YYTjGhZxev75uNaFA5MkHGLd05JWgRQnl XQLNsJxvjG1M8Lj0hmD9gkGWEnXhyeJ+hT2d6e5tiTQRKlfLYnuBstQIPFjeLTTR BlfOBO6rVP9q9zD1d82zHt0w3Blbj3PLjPlUbAXKXruksWXYz9iLtWY3g5H3v2Gy oU6QzxCcLgEK3jfWYYkOFTCScph3HTnoSU1ER24eHGMY0SUbL6OAKS4Os6gIEpk4 o8PVzLWdOXzmCqF6nN12/zV7iL5mP1GpKIquxD8qx5DVTLJgaUzdmZDFi3Ivpbnq KqNG/tY+OOTIh2MslBzDD2Pq+E7jcDAjfrtU5yQMehqRzXLZ0F6PzCXMr0GSAV6d Uh5qWbgh8zkpndPupkdd8wc5foqNl5bGGCVWyq3a4CdloAoa5R3wndRP57HQcnNp QIzB1RbLuQSVYsYgAGvkfJYohMfvisrkwigbdvEpeGsqBz59SEj6gPHVOHzlUxnk plZbEDSIY5GN+EblkI/t8z9s9kD5DsFPLqZ+Lrx8dJwB72mG7zYh8Kp1x9qg6C+1 DHgCpQhwEATT =vVGM -END PGP SIGNATURE-
Bug#893163: Re[2]: Bug#893163: caja-dropbox: drop down menu does not appears when clicking on icon (left or right click) in version 1.20
Hi, > Only remove that patch? Or add some other code? Yes, only remove it. My tests showed that it's enough to fix the menu (as I wrote in the upstream report). Oh, I see it's already fixed by now, thanks :)
Bug#883650: libev: diff for NMU version 1:4.22-1.1
Control: tag -1 + patch pending
X-Debbugs-CC: kapo...@melix.org
Dear libev maintainer,
I've prepared an NMU for libev (versioned as 1:4.22-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru libev-4.22/debian/changelog libev-4.22/debian/changelog
--- libev-4.22/debian/changelog 2016-01-11 16:03:13.0 -0500
+++ libev-4.22/debian/changelog 2019-02-02 14:29:37.0 -0500
@@ -1,3 +1,17 @@
+libev (1:4.22-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Rebuild for Debian Buster.
++ Automatically generate debug packages. (Closes: #642110)
+ * debian/control:
++ Drop obsoleted package priority extra.
++ Update Vcs-* fields and use git repo under Salsa Debian group.
++ Declare compliance with Debian Policy 4.3.0.
++ Update Homepage information. (Closes: #883650)
+ * debian/copyright: Use secure uri for Format field.
+
+ -- Boyuan Yang Sat, 02 Feb 2019 14:29:37 -0500
+
libev (1:4.22-1) unstable; urgency=medium
* Imported Upstream version 4.22
diff -Nru libev-4.22/debian/control libev-4.22/debian/control
--- libev-4.22/debian/control 2016-01-11 16:02:46.0 -0500
+++ libev-4.22/debian/control 2019-02-02 14:28:10.0 -0500
@@ -2,14 +2,13 @@
Priority: optional
Maintainer: Jérémy Lal
Build-Depends: dpkg-dev (>= 1.14.9), debhelper (>= 9), dh-autoreconf
-Standards-Version: 3.9.6
+Standards-Version: 4.3.0
Section: libs
-Homepage: http://libev.schmorp.de/
-Vcs-Git: git://anonscm.debian.org/collab-maint/libev.git
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/libev.git
+Homepage: http://software.schmorp.de/pkg/libev.html
+Vcs-Git: https://salsa.debian.org/debian/libev.git
+Vcs-Browser: https://salsa.debian.org/debian/libev
Package: libev-dev
-Priority: extra
Section: libdevel
Architecture: any
Depends: ${misc:Depends}, libev4 (= ${binary:Version})
@@ -28,7 +27,6 @@
libev supports select, poll, epoll, kqueue, and inotify.
Package: libev-libevent-dev
-Priority: extra
Section: libdevel
Architecture: all
Depends: ${misc:Depends},
diff -Nru libev-4.22/debian/copyright libev-4.22/debian/copyright
--- libev-4.22/debian/copyright 2016-01-11 16:02:46.0 -0500
+++ libev-4.22/debian/copyright 2019-02-02 14:28:52.0 -0500
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Source: http://dist.schmorp.de/libev/
Files: *
signature.asc
Description: This is a digitally signed message part
Bug#921124: elpa-git-commit: magit components can't handle - character
Hello, On February 01 2019, Robbie Harwood wrote > Package: elpa-git-commit > Version: 2.90.1-1 > Severity: important > > Dear Maintainer, > > elpa-git-commit and magit's interactive rebase mode don't seem to be > able to handle the - character in pathnames/branches. I did some test, and found no problem. > I wish I could provide a more helpful error, but the result is that > when I try to type in the window, it hangs up the emacs process and > barfs on the terminal state machine, leaving garbage. Could you link to a git repository where you encounter the problem, or at least give me a step by step procedure leading to your problem? Thanks Rémi,
Bug#921185: picard-tools should become Architecture: amd64
Package: picard-tools Version: 2.18.25+dfsg-1 Severity: serious The dependency libgkl-java is amd64-only, and the easiest way to fix testing migration as well as being generally correct (what's the point of binary-all when it is only installable on 1 architecture?) is Architecture: all -> amd64 for all packages.
Bug#921184: RM: audex -- ROM; No active maintainers, dead upstream, low popcon
Package: ftp.debian.org Severity: normal Hi! With my team-maintainer hat on: this package currently has no active maintainers, is dead upstream and it's popcon is low. Moreover the functionality can be found in other packages in the archive. So please remove this package. Thanks, Lisandro.
Bug#921183: python3-surfer: missing Breaks+Replaces: python-surfer (<< 0.9.0)
Package: python3-surfer Version: 0.9.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces From the attached log (scroll to the bottom...): Preparing to unpack .../python3-surfer_0.9.0-1_all.deb ... Unpacking python3-surfer (0.9.0-1) ... dpkg: error processing archive /var/cache/apt/archives/python3-surfer_0.9.0-1_all.deb (--unpack): trying to overwrite '/usr/bin/pysurfer', which is also in package python-surfer 0.7-2.1 Errors were encountered while processing: /var/cache/apt/archives/python3-surfer_0.9.0-1_all.deb cheers, Andreas python-surfer=0.7-2.1_python3-surfer=0.9.0-1.log.gz Description: application/gzip
Bug#921182: ITP: braker -- guides from NGS to whole genome annotation
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: braker Version : 2.1.2 Upstream Author : K.J. Hoff * URL : https://github.com/Gaius-Augustus/BRAKER * License : Artistic Programming Lang: Perl Description : guides from NGS to whole genome annotation The package is team-maintained on https://salsa.debian.org/med-team/braker
Bug#919231: Salt-master unable to access directories
Hi Benjamin, Can you tell me what info you need? Anything I should check? Salt-master and systemd package info: $ apt policy systemd systemd: Installed: 240-4 Candidate: 240-4 Version table: 240-5 50 50 http://cdn-fastly.deb.debian.org/debian sid/main amd64 Packages *** 240-4 450 450 http://cdn-fastly.deb.debian.org/debian buster/main amd64 Packages 450 http://cdn-fastly.deb.debian.org/debian testing/main amd64 Packages 100 /var/lib/dpkg/status $ apt policy salt-master salt-master: Installed: 2018.3.3+dfsg1-2 Candidate: 2018.3.3+dfsg1-2 Version table: *** 2018.3.3+dfsg1-2 450 450 http://cdn-fastly.deb.debian.org/debian buster/main amd64 Packages 450 http://cdn-fastly.deb.debian.org/debian testing/main amd64 Packages 50 http://cdn-fastly.deb.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status
Bug#921181: pescetti: recommends unavailable package dds
Package: pescetti Version: 0.5-3 Hi, pescetti recommends dds which isn't available anymore, at least in buster and sid. Regards, Gabriele Stilli
Bug#920691: lintian gets stuck collecting info after failed objdump-info
On Mon, Jan 28, 2019 at 07:01:52PM -0800, Felix Lechner wrote: > Maybe the pending Perl commit 672eb451 will help? Details in #916313. FYI I've just uploaded perl/5.28.1-4 which fixes #916313. Hope that helps. -- Niko Tyni nt...@debian.org
Bug#909510: [PATCH] New tag: script-uses-unversioned-python-in-shebang
Hi Dmitry,
> +Tag: script-uses-unversioned-python-in-shebang
> +Severity: normal
^^
Hmm, I thought we were just going to use this to see the numbers
rather than ask maintainers to "fix" this?
> +# Check for unversioned python shebang (#909510).
> +for my $file ($info->sorted_index) {
> +next unless $file->is_file;
(I think we want to check "is_open_ok" here too?)
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#921163: coreutils such as /bin/mkdir are duplicated in /usr/bin/mkdir
Control: forcemerge 914915 -1 Hi Patrick, Quoting Patrick Schleizer (2019-02-02 15:05:00) > # How to reproduce: > > sudo mmdebstrap --mode=root > --aptopt=/home/user/whonix_binary/aptgetopt.conf stretch > /var/cache/pbuilder/base.cow > /home/user/whonix_dot/Whonix/build_sources/debian_stable_current_clearnet.list > > (Could probably simplified but I hope you can reproduce this easily / > hope you also have usr/bin/mkdir.) > > # Expected result: > > base.cow/bin/mkdir exists. > > base.cow/usr/bin/mkdir does not exist > > # Actual result: > > base.cow/bin/mkdir exists. > > base.cow/usr/bin/mkdir exists. > > base.cow/usr/bin/mkdir matches base.cow/bin/mkdir. > > diff base.cow/usr/bin/mkdir base.cow/bin/mkdir ; echo $? > 0 > > Also many (if not all) other coreutils that should only reside in /bin > such as /bin/rm are duplicated in /usr/bin such as /usr/bin/rm. > > # Why this is a problem: > > /usr/bin is preferred over /bin with default $PATH setting. > > - When coreutils is later updated, it will only update /bin/mkdir and so > forth but not /usr/bin/mkdir. This is because /bin/mkdir is owned by > coreutils (dpkg -S /bin/mkdir) but /usr/bin/mkdir is owned by no package > (dpkg -S /usr/bin/mkdir). > > - This leads to apparmor issues. In apparmor profiles one has to > hardcode for example /bin/mkdir but since /usr/bin/mkdir exists, this > call will be denied. > > # Misc: > > I couldn't figure out from the source code why this is happening. > Intended or unintended behavior? If intended, can this be turned off? > Are also other files in unusual places? the observations you describe are due to the following symlinks (using your paths as examples): base.cow/bin -> usr/bin base.cow/sbin -> usr/sbin base.cow/lib -> usr/lib And depending on your architecture there are even a few more of those. So you will see that the files base.cow/bin/mkdir and base.cow/usr/bin/mkdir are actually the same files. You can use $(stat -c '%i') to compare the inode numbers. The idea behind creating these symlinks from foo to usr/foo is called "merged /usr", "usr merge" or "usr move" and is a concept that has been introduced in other distributions like Fedora: https://fedoraproject.org/wiki/Features/UsrMove And also Debian is doing experiments with it: https://wiki.debian.org/UsrMerge For a while, the tool debootstrap which is doing something very similar to mmdebstrap was creating "merged /usr" systems that include these symlinks by default. It then turned out that it was a bad idea to have this default before other problems aren't solved yet and thus the default was changed back to the old behaviour. Unfortunately, I wrote mmdebstrap in the timeframe when debootstrap still defaulted to the "merged /usr" behaviour and since I just wanted to provide the same feature as debootstrap, this became the default of mmdebstrap as well. Due to the discovered problems, "merged /usr" should *not* be the default for mmdebstrap for now and that's why this bug was reported already: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914915 As a result, "merged /usr" has been disabled in mmdebstrap since this commit: https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/97d273aaf6ada19f496ba75d907ee64b0a75 So the only thing that is needed, is for a new mmdebstrap release and then this bug will be fixed. :) Thanks! cheers, josch signature.asc Description: signature
Bug#911511: light-locker: sometimes I've to unlock my system twice
I've tested light-locker a bit more but still am not able to reproduce the bug reliable. Sometimes it happens direct and sometimes not even after having the system locked for hours. Is there anything I can do to debug this? Axel
Bug#782644: xscreensaver always rejects my password
Package: xscreensaver Version: 5.42+dfsg1-1 Followup-For: Bug #782644 Dear Maintainer, I have the same bug but it’s worse: I did not launch xscreensaver by myself. I suspend the computer with the Moon key and when I wake it back, xscreensaver is launched and refuses my password. I can’t even kill it in a tty, Ctrl-Alt-Fx won’t work and ssh seems locked too. I only can reboot. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.17.0-3-686-pae (SMP w/3 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR:fr:en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xscreensaver depends on: ii libatk1.0-0 2.30.0-2 ii libc62.28-5 ii libcairo21.16.0-2 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libglade2-0 1:2.6.4-2+b1 ii libglib2.0-0 2.58.2-4 ii libgtk2.0-0 2.24.32-3 ii libice6 2:1.0.9-2 ii libpam0g 1.1.8-4 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpangoft2-1.0-01.42.4-6 ii libsm6 2:1.2.2-1+b3 ii libx11-6 2:1.6.7-1 ii libxext6 2:1.3.3-1+b2 ii libxi6 2:1.7.9-1 ii libxinerama1 2:1.1.4-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxmu6 2:1.1.2-2 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxt6 1:1.1.5-1 ii libxxf86vm1 1:1.1.4-1+b2 ii xscreensaver-data5.42+dfsg1-1 Versions of packages xscreensaver recommends: ii libjpeg-turbo-progs 1:1.5.2-2+b1 ii miscfiles [wordlist] 1.5+dfsg-2 ii perl 5.28.1-3 ii wamerican [wordlist] 2018.04.16-1 ii wfrench [wordlist]1.2.4-1 Versions of packages xscreensaver suggests: ii chimera2 [www-browser] 2.0a19-8+b3 ii chromium [www-browser] 72.0.3626.53-1 ii conkeror [www-browser] 1.0.4-1 ii dillo [www-browser]3.0.5-5 ii dwb [www-browser] 20150419git-2+b1 ii elinks [www-browser] 0.12~pre6-14 ii firefox [www-browser] 65.0-1 ii firefox-esr [www-browser] 60.5.0esr-1 ii fortune-mod [fortune] 1:1.99.1-7+b1 ii gdm3 3.30.2-1 ii konqueror [www-browser]4:18.12.0-1 ii links2 [www-browser] 2.18-1 ii lynx [www-browser] 2.8.9rel.1-3 ii midori [www-browser] 7.0-1 ii netrik [www-browser] 1.16.1-2+b2 pn qcam | streamer ii uzbl [www-browser] 0.0.0~git.20120514-1.2 pn xdaliclock ii xfishtank 2.5-1+b1 ii xscreensaver-data-extra5.42+dfsg1-1 ii xscreensaver-gl5.42+dfsg1-1 ii xscreensaver-gl-extra 5.42+dfsg1-1 -- no debconf information
Bug#921004: amdgpu: The CS has been cancelled because the context is lost.
Sorry if I created a burden. I didn't wanted to achieve anything
particular except to find the good location where to report the bug. In
fact I am not really sure which package is 'responsible' of this bug: At
first glance, this is a driver issue because the bug is not reproducible
with GPUs from other manufacturers (tested with nVidia and Intel).
Downgrading the firmware resolves partially the issue, therefore the
firmware package maintainers might have clue about this. Finally, the
error message is raised by Mesa.
For about the Debian version, this is a mistake on my side. It is indeed
in Buster.
It is a regression because prior to upgrading to the latest {firwmare,
xserver-xorg, Mesa} there was no bugs.
There were no bugs with the previous version of firmware-amd-graphics,
that is 20180825-1 along with the previous version of Mesa, that is the
18.2 branch.
Regards.
Le 02/02/2019 à 17:28, Bernhard Übelacker a écrit :
Hello Jean-Dominique Frattini,
I am not involved in packaging any of these packages,
but I noted that you opened the last three days nearly
the same issue against three different packages?
What are you trying to achive that way?
And you noted versions contained in current Buster,
but you claim it is Stretch?
You write it is a regression - do you know the package
versions or the date when it was working like expected?
Also giving an example application that triggers that
error message could maybe make the bug report more
attractive to get some one having the matching hardware
looking at it.
Kind regards,
Bernhard
Bug#921180: RM: libswagger2-perl -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal We are requesting the removal of libswagger2-perl: * Upstream deprecated the module in 2017 [1] * Upstream website/repository is no longer available [2] * No reverse dependencies [1] https://metacpan.org/pod/release/JHTHORSEN/Swagger2-0.89/lib/Swagger2.pm [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917036 Thanks, Nick Morrott on behalf of the Debian Perl team
Bug#920976: Reproducibility
Hello tobi, thanks for your bug report! Could you provide two file sets (for two directories) which trigger the bug when kdiff3 is called upon them? Ciao, Eike signature.asc Description: This is a digitally signed message part.
Bug#827827: ERROR: php-elisp is broken - called emacs-package-install as a new-style add-on, but has no compat file.
On 2019-02-01 18:35:11, Nicholas D Steeves wrote: > Hi Antoine! > > On Wed, Oct 31, 2018 at 11:46:20AM -0400, Antoine Beaupre wrote: >> On Fri, Jul 29, 2016 at 07:42:00AM +0200, Ola Lundqvist wrote: >> > Hi >> > >> > Sorry for the delayed answer. I tried to reproduce your problem myself but >> > failed. >> > >> > What was your from version? >> > >> > Are you running sid or what version of debian in general? >> >> This is reproducible right now in Debian Buster. >> >> $ sudo apt install php-elisp >> Lecture des listes de paquets... Fait >> Construction de l'arbre des dépendances >> Lecture des informations d'état... Fait >> Paquets suggérés : >> php5 php5-cli >> Paquets recommandés : >> speedbar >> Les NOUVEAUX paquets suivants seront installés : >> php-elisp >> 0 mis à jour, 1 nouvellement installés, 0 à enlever et 1 non mis à jour. >> Il est nécessaire de prendre 26,7 ko dans les archives. >> Après cette opération, 150 ko d'espace disque supplémentaires seront >> utilisés. >> Réception de:1 http://cdn-fastly.deb.debian.org/debian buster/main amd64 >> php-elisp all 1.13.5-3 [26,7 kB] >> 26,7 ko réceptionnés en 1s (52,9 ko/s) >> [master baf904a] saving uncommitted changes in /etc prior to apt run >> Author: Antoine Beaupré >> 2 files changed, 70 deletions(-) >> delete mode 100644 libvirt/qemu/stretch64_default.xml >> Récupération des rapports de bogue… Fait >> Analyse des informations Trouvé/Corrigé… Fait >> Sélection du paquet php-elisp précédemment désélectionné. >> (Lecture de la base de données... 616958 fichiers et répertoires déjà >> installés.) >> Préparation du dépaquetage de .../php-elisp_1.13.5-3_all.deb ... >> Dépaquetage de php-elisp (1.13.5-3) ... >> Paramétrage de php-elisp (1.13.5-3) ... >> ERROR: php-elisp is broken - called emacs-package-install as a new-style >> add-on, but has no compat file. >> Install php-elisp for emacs >> Install php-elisp for emacs > > I think the issue might be that php-elisp_1.13.5-3 is missing the > "new-style" (now "old-style" since dh-elpa is new-style) > debian/foo.emacsen.compat. The issue still exists when upgrading to > php-elisp_1.21.0-1 (dummy transitional package), which is particularly > bizarre, but as far as I can tell it's harmless, and piuparts seems to > confirm this. Understood - does that mean we can just close this issue and pretend it will disappear in the new-style package? > BTW, if you have time could you look at this php-elisp RFS?: #921130 Done! A. -- The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do. - Ted Nelson
Bug#921114: no display on GL applications
On Sat, 2019-02-02 at 13:23 +0100, at46 wrote: > Hi Jean-Dominique, > > are you mixing stable and testing? As far as I can see > Firmware-nonfree/20190114-1 isn't available for stable/stretch. Maybe > you also need to use a newer kernel. The Debian changelog > (https://tracker.debian.org/media/packages/f/firmware-nonfree/changelog-20190114-1) > > mention "Update to linux-support 4.19.0-1". The binary packages built from firmware-nonfree intentionally do not have any relations to kernel versions. Whenever there is an ABI- incompatible change in firmware, the firmware should be given a new filename. It is not an error to use a new firmware package with an old kernel. Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Bug#921137: [Pkg-mailman-hackers] Bug#921137: emails sent from /etc/mailname, ignoring configured domain
On 2019-02-02 17:52:50, Pierre-Elliott Bécue wrote:
> Le vendredi 01 février 2019 à 20:26:07-0500, Antoine Beaupre a écrit :
>> Package: mailman3
>> Version: 3.2.0-4~bpo9+1
>> Severity: grave
>>
>> I'm finding it difficult to use the "domain" feature of Mailman 3. From
>> what I understand, it allows you to have two distinct mailing lists
>> named "test" on (say) t...@example.com and t...@example.net.
>>
>> Here I'm specifically using the feature to host my mailing lists on
>> lists.anarc.at instead of plain anarc.at. Yet I don't know what I'm
>> doing wrong, but all outgoing email comes from t...@anarc.at instead of
>> t...@lists.anarc.at. This makes replies obviously fail as the LTMP maps
>> don't have that domain:
>>
>> # grep ^[^#] /var/spool/postfix/mailman3/postfix_domains
>> # /var/spool/postfix/mailman3/postfix_lmtp
>> /var/spool/postfix/mailman3/postfix_domains:lists.anarc.at lists.anarc.at
>> /var/spool/postfix/mailman3/postfix_lmtp:
>> /var/spool/postfix/mailman3/postfix_lmtp:t...@lists.anarc.at
>> lmtp:[127.0.0.1]:8024
>> /var/spool/postfix/mailman3/postfix_lmtp:test-boun...@lists.anarc.at
>> lmtp:[127.0.0.1]:8024
>> /var/spool/postfix/mailman3/postfix_lmtp:test-conf...@lists.anarc.at
>> lmtp:[127.0.0.1]:8024
>> /var/spool/postfix/mailman3/postfix_lmtp:test-j...@lists.anarc.at
>> lmtp:[127.0.0.1]:8024
>> /var/spool/postfix/mailman3/postfix_lmtp:test-le...@lists.anarc.at
>> lmtp:[127.0.0.1]:8024
>> /var/spool/postfix/mailman3/postfix_lmtp:test-ow...@lists.anarc.at
>> lmtp:[127.0.0.1]:8024
>> /var/spool/postfix/mailman3/postfix_lmtp:test-requ...@lists.anarc.at
>> lmtp:[127.0.0.1]:8024
>> /var/spool/postfix/mailman3/postfix_lmtp:test-subscr...@lists.anarc.at
>> lmtp:[127.0.0.1]:8024
>> /var/spool/postfix/mailman3/postfix_lmtp:test-unsubscr...@lists.anarc.at
>> lmtp:[127.0.0.1]:8024
>>
>> I've tried various things to fix this: I recreated the "domain" in the
>> Posterious interface. I have changed the "mailname" when running
>> dpkg-reconfigure mailman3-web, restarting it, which gave me this diff:
>>
>> --- a/mailman3/mailman-web.py
>> +++ b/mailman3/mailman-web.py
>> @@ -130,7 +130,7 @@ USE_TZ = True
>>
>>
>> # Set default domain for email addresses.
>> -EMAILNAME = 'localhost.local'
>> +EMAILNAME = 'anarc.at'
>>
>> # If you enable internal authentication, this is the address that the emails
>> # will appear to be coming from. Make sure you set a valid domain name,
>>
>> Still, "mass subscribe" emails come out as "t...@anarc.at", even though
>> the footer clearly reads:
>>
>> To unsubscribe send an email to test-le...@lists.anarc.at
>>
>> When I write an email there, I get a reply saying to reply to:
>>
>> test-confirm+14ea1ffec9434c30b983e1d5ab071b4988af4...@anarc.at
>>
>> ... which is still wrong and will (obviously) bounce.
>>
>> What's going on here?
>>
>> Here's a log of an admin mass-subscribing a user:
>>
>> ==> /var/log/mailman3/web/mailman-web.log <==
>> [pid: 2680|app: 0|req: 5/5] 192.168.0.7 () {82 vars in 1587 bytes} [Sat Feb
>> 2 01:22:11 2019] POST
>> /mailman3/postorius/lists/test.lists.anarc.at/mass_subscribe/ => generated
>> 9458 bytes in 468 msecs (HTTP/2.0 200) 6 headers in 317 bytes (3 switches on
>> core 0)
>>
>> ==> /var/log/mail.log <==
>> Feb 1 20:22:12 marcos postfix/smtpd[4889]: connect from
>> localhost[127.0.0.1]
>> Feb 1 20:22:12 marcos postfix/smtpd[4889]: DD2E510E1D8:
>> client=localhost[127.0.0.1]
>> Feb 1 20:22:12 marcos postfix/cleanup[5789]: DD2E510E1D8:
>> message-id=<154907053190.742.3083806269187387...@marcos.anarc.at>
>>
>> ==> /var/log/mailman3/smtp.log <==
>> Feb 01 20:22:12 2019 (746)
>> <154907053190.742.3083806269187387...@marcos.anarc.at> smtp to
>> t...@lists.anarc.at for 1 recips, completed in 0.03175711631774902 seconds
>>
>> ==> /var/log/mail.log <==
>> Feb 1 20:22:12 marcos postfix/qmgr[31811]: DD2E510E1D8:
>> from=, size=581, nrcpt=1 (queue active)
>> Feb 1 20:22:12 marcos postfix/smtpd[5791]: connect from
>> localhost[127.0.0.1]
>>
>> ==> /var/log/mailman3/smtp.log <==
>> Feb 01 20:22:12 2019 (746)
>> <154907053190.742.3083806269187387...@marcos.anarc.at> post to
>> t...@lists.anarc.at from test-requ...@lists.anarc.at, 362 bytes
>>
>> ==> /var/log/mail.log <==
>> Feb 1 20:22:12 marcos postfix/smtpd[4889]: disconnect from
>> localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 commands=4
>> Feb 1 20:22:12 marcos postfix/smtpd[5791]: EAED510E1DA:
>> client=localhost[127.0.0.1]
>> Feb 1 20:22:13 marcos spampd[24505]: processing message
>> <154907053190.742.3083806269187387...@marcos.anarc.at> for
>> ORCPT=rfc822;anar...@example.net
>> Feb 1 20:22:14 marcos spampd[24505]: clean message
>> <154907053190.742.3083806269187387...@marcos.anarc.at> (-1.31/5.00) from
>> for
>> ORCPT=rfc822;anar...@example.net in 1.10s, 1087 bytes.
>> Feb 1 20:22:14 marcos postfix/cleanup[5789]: EAED510E1DA:
>> message-id=<154907053190.742.3083806269187387...@marcos.anarc.at>
>> Feb
Bug#921137: [Pkg-mailman-hackers] Bug#921137: emails sent from /etc/mailname, ignoring configured domain
Oh, and I forgot to mention I document the steps I took to configure mailman here: https://anarc.at/services/mail/ There are other configurations there, naturally, in particular spamd integration, dkim and other stuff, which might create problems... a. -- Advertisers, not governments, are the primary censors of media content in the United States today. - C. Edwin Baker
Bug#918992: Package in NEW queue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I sorted out the remainder of the packaging issues with debalance and he sponsored the package. It is now in the NEW queue: https://ftp-master.debian.org/new/evdi_1.5.1+dfsg-1.html -BEGIN PGP SIGNATURE- iQFABAEBCgAqIxxIYW5ubyBTdG9jayA8aGFubm9AaGFubm8tc3RvY2suZGU+BQJc VdDuAAoJEBwZ4QllLgSjz4MH/irF4Tk5XakuYOTkW2lXYvsASPJk7HwiYUEd5wE3 p+DT32QBWLe9FLkva+LGERVGDobw562Y7kE8sNCOK5IpB/frPNSZYZNOFBM+v2b1 ANb+O4THy/uRrt60lWziDp65lR1nN0N25F52z50dcQAdV8rjLFBHVeDUhIAH1G8s 3BhZao2A/JP/6TaiaiY2/l8QOaMlZWMIxMczTRVP5FxWgbEB1Au4frc66uBos6Ha zUqpPpWAGcxAm6rfmpll58S8eY8d19eiBUswggsd273kab8zyQ5kUTtfh/swggaL VYp0wghh6jTYYnxdbKkX24xBlegEu5BFE4erk/3Jbruins0= =EO/H -END PGP SIGNATURE-
Bug#921137: [Pkg-mailman-hackers] Bug#921137: emails sent from /etc/mailname, ignoring configured domain
Le vendredi 01 février 2019 à 20:26:07-0500, Antoine Beaupre a écrit :
> Package: mailman3
> Version: 3.2.0-4~bpo9+1
> Severity: grave
>
> I'm finding it difficult to use the "domain" feature of Mailman 3. From
> what I understand, it allows you to have two distinct mailing lists
> named "test" on (say) t...@example.com and t...@example.net.
>
> Here I'm specifically using the feature to host my mailing lists on
> lists.anarc.at instead of plain anarc.at. Yet I don't know what I'm
> doing wrong, but all outgoing email comes from t...@anarc.at instead of
> t...@lists.anarc.at. This makes replies obviously fail as the LTMP maps
> don't have that domain:
>
> # grep ^[^#] /var/spool/postfix/mailman3/postfix_domains
> # /var/spool/postfix/mailman3/postfix_lmtp
> /var/spool/postfix/mailman3/postfix_domains:lists.anarc.at lists.anarc.at
> /var/spool/postfix/mailman3/postfix_lmtp:
> /var/spool/postfix/mailman3/postfix_lmtp:t...@lists.anarc.at
> lmtp:[127.0.0.1]:8024
> /var/spool/postfix/mailman3/postfix_lmtp:test-boun...@lists.anarc.at
> lmtp:[127.0.0.1]:8024
> /var/spool/postfix/mailman3/postfix_lmtp:test-conf...@lists.anarc.at
> lmtp:[127.0.0.1]:8024
> /var/spool/postfix/mailman3/postfix_lmtp:test-j...@lists.anarc.at
> lmtp:[127.0.0.1]:8024
> /var/spool/postfix/mailman3/postfix_lmtp:test-le...@lists.anarc.at
> lmtp:[127.0.0.1]:8024
> /var/spool/postfix/mailman3/postfix_lmtp:test-ow...@lists.anarc.at
> lmtp:[127.0.0.1]:8024
> /var/spool/postfix/mailman3/postfix_lmtp:test-requ...@lists.anarc.at
> lmtp:[127.0.0.1]:8024
> /var/spool/postfix/mailman3/postfix_lmtp:test-subscr...@lists.anarc.at
> lmtp:[127.0.0.1]:8024
> /var/spool/postfix/mailman3/postfix_lmtp:test-unsubscr...@lists.anarc.at
> lmtp:[127.0.0.1]:8024
>
> I've tried various things to fix this: I recreated the "domain" in the
> Posterious interface. I have changed the "mailname" when running
> dpkg-reconfigure mailman3-web, restarting it, which gave me this diff:
>
> --- a/mailman3/mailman-web.py
> +++ b/mailman3/mailman-web.py
> @@ -130,7 +130,7 @@ USE_TZ = True
>
>
> # Set default domain for email addresses.
> -EMAILNAME = 'localhost.local'
> +EMAILNAME = 'anarc.at'
>
> # If you enable internal authentication, this is the address that the emails
> # will appear to be coming from. Make sure you set a valid domain name,
>
> Still, "mass subscribe" emails come out as "t...@anarc.at", even though
> the footer clearly reads:
>
> To unsubscribe send an email to test-le...@lists.anarc.at
>
> When I write an email there, I get a reply saying to reply to:
>
> test-confirm+14ea1ffec9434c30b983e1d5ab071b4988af4...@anarc.at
>
> ... which is still wrong and will (obviously) bounce.
>
> What's going on here?
>
> Here's a log of an admin mass-subscribing a user:
>
> ==> /var/log/mailman3/web/mailman-web.log <==
> [pid: 2680|app: 0|req: 5/5] 192.168.0.7 () {82 vars in 1587 bytes} [Sat Feb
> 2 01:22:11 2019] POST
> /mailman3/postorius/lists/test.lists.anarc.at/mass_subscribe/ => generated
> 9458 bytes in 468 msecs (HTTP/2.0 200) 6 headers in 317 bytes (3 switches on
> core 0)
>
> ==> /var/log/mail.log <==
> Feb 1 20:22:12 marcos postfix/smtpd[4889]: connect from localhost[127.0.0.1]
> Feb 1 20:22:12 marcos postfix/smtpd[4889]: DD2E510E1D8:
> client=localhost[127.0.0.1]
> Feb 1 20:22:12 marcos postfix/cleanup[5789]: DD2E510E1D8:
> message-id=<154907053190.742.3083806269187387...@marcos.anarc.at>
>
> ==> /var/log/mailman3/smtp.log <==
> Feb 01 20:22:12 2019 (746)
> <154907053190.742.3083806269187387...@marcos.anarc.at> smtp to
> t...@lists.anarc.at for 1 recips, completed in 0.03175711631774902 seconds
>
> ==> /var/log/mail.log <==
> Feb 1 20:22:12 marcos postfix/qmgr[31811]: DD2E510E1D8:
> from=, size=581, nrcpt=1 (queue active)
> Feb 1 20:22:12 marcos postfix/smtpd[5791]: connect from localhost[127.0.0.1]
>
> ==> /var/log/mailman3/smtp.log <==
> Feb 01 20:22:12 2019 (746)
> <154907053190.742.3083806269187387...@marcos.anarc.at> post to
> t...@lists.anarc.at from test-requ...@lists.anarc.at, 362 bytes
>
> ==> /var/log/mail.log <==
> Feb 1 20:22:12 marcos postfix/smtpd[4889]: disconnect from
> localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 commands=4
> Feb 1 20:22:12 marcos postfix/smtpd[5791]: EAED510E1DA:
> client=localhost[127.0.0.1]
> Feb 1 20:22:13 marcos spampd[24505]: processing message
> <154907053190.742.3083806269187387...@marcos.anarc.at> for
> ORCPT=rfc822;anar...@example.net
> Feb 1 20:22:14 marcos spampd[24505]: clean message
> <154907053190.742.3083806269187387...@marcos.anarc.at> (-1.31/5.00) from
> for
> ORCPT=rfc822;anar...@example.net in 1.10s, 1087 bytes.
> Feb 1 20:22:14 marcos postfix/cleanup[5789]: EAED510E1DA:
> message-id=<154907053190.742.3083806269187387...@marcos.anarc.at>
> Feb 1 20:22:14 marcos postfix/qmgr[31811]: EAED510E1DA:
> from=, size=1583, nrcpt=1 (queue active)
> Feb 1 20:22:14 marcos postfix/smtp[5799]: DD2E510E1D8:
> to=,
Bug#921179: FTBFS: several test failures
Source: coquelicot Version: 0.9.6-1.1 Severity: serious Tags: ftbfs Justification: fails to build from source coquelicot currently fails to build in both unstable and buster, with several test failures. Log attached. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled coquelicot.txt.gz Description: application/gzip signature.asc Description: PGP signature
Bug#921176: redis-server service is failing to start in buster lxc container
tags 921176 + moreinfo thanks Hi Pirate, > journalctl -xe shows this error. This used to work before. It is clean > lxc install on a sid host. I just tried to quickly reproduce this but my lxc-foo is lacking… :( However, I suspect that we are using too aggressive a set of security hardening features, including perhaps: ProtectKernelTunables=Yes Can you try starting redis-server with this flag disabled? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#921178: libreoffice: Crashes on startup around utl::ConfigManager::acquireTree
Package: libreoffice Version: 1:6.1.5~rc1-2 Severity: important Crashes in the splash binary: $ libreoffice Fatal exception: Signal 11 Stack: /usr/lib/libreoffice/program/libuno_sal.so.3(+0x3d593)[0x7f284572f593] /usr/lib/libreoffice/program/libuno_sal.so.3(+0x3d7a3)[0x7f284572f7a3] /lib/x86_64-linux-gnu/libc.so.6(+0x378e0)[0x7f284553c8e0] /usr/lib/libreoffice/program/libuno_cppu.so.3(+0x14af2)[0x7f2842556af2] /usr/lib/libreoffice/program/libuno_cppu.so.3(uno_type_any_assign+0x97)[0x7f2842556167] /usr/lib/libreoffice/program/libmergedlo.so(+0x2a98328)[0x7f28481e8328] /usr/lib/libreoffice/program/libmergedlo.so(+0x2a99005)[0x7f28481e9005] /usr/lib/libreoffice/program/libmergedlo.so(_ZN3utl10ConfigItemC2ERKN3rtl8OUStringE14ConfigItemMode+0x7b)[0x7f28481dda5b] /usr/lib/libreoffice/program/libmergedlo.so(+0x2aed8b8)[0x7f284823d8b8] /usr/lib/libreoffice/program/libmergedlo.so(_ZN19SvtSysLocaleOptionsC1Ev+0x11f)[0x7f284823edaf] /usr/lib/libreoffice/program/libmergedlo.so(_Z7InitVCLv+0x1a0)[0x7f2848590470] /usr/lib/libreoffice/program/libmergedlo.so(+0x2e41a0d)[0x7f2848591a0d] /usr/lib/libreoffice/program/libmergedlo.so(_Z6SVMainv+0x30)[0x7f2848591a60] /usr/lib/libreoffice/program/libmergedlo.so(soffice_main+0x91)[0x7f284766e321] /usr/lib/libreoffice/program/soffice.bin(+0x107b)[0x55a86cc2507b] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f284552909b] /usr/lib/libreoffice/program/soffice.bin(+0x10ba)[0x55a86cc250ba] $ Here is a gdbtrace: # cat gdbtrace.log warning: Currently logging to gdbtrace.log. Turn the logging off and on to make the new setting effective. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Detaching after fork from child process 63983] [New Thread 0x7fdc566cb700 (LWP 63984)] [New Thread 0x7fdc54702700 (LWP 64022)] Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault. 0x7fdc5ac04af2 in cppu::_copyConstructAnyFromData (mapping=0x0, acquire=0x7fdc5f05f870 , pTypeDescr=, pType=, pSource=0x7ffc2d040880, pDestAny=0x56016649e0a8) at ./include/typelib/typedescription.h:1016 1016./include/typelib/typedescription.h: No such file or directory. #0 0x7fdc5ac04af2 in cppu::_copyConstructAnyFromData (mapping=0x0, acquire=0x7fdc5f05f870 , pTypeDescr=, pType=, pSource=0x7ffc2d040880, pDestAny=0x56016649e0a8) at ./include/typelib/typedescription.h:1016 #1 cppu::_copyConstructAny (pDestAny=pDestAny@entry=0x56016649e0a8, pSource=pSource@entry=0x7ffc2d040880, pType=, pType@entry=0x5601663f94f0, pTypeDescr=pTypeDescr@entry=0x0, acquire=acquire@entry=0x7fdc5f05f870 , mapping=mapping@entry=0x0) at ./cppu/source/uno/copy.hxx:264 #2 0x7fdc5ac04167 in uno_type_any_assign (pDest=pDest@entry=0x56016649e0a8, pSource=pSource@entry=0x7ffc2d040880, pType=0x5601663f94f0, acquire=acquire@entry=0x7fdc5f05f870 , release=release@entry=0x7fdc5f05f880 ) at ./cppu/source/uno/any.cxx:39 #3 0x7fdc60896328 in com::sun::star::uno::operator<<= (value=..., rAny=Python Exception : ) at ./include/com/sun/star/uno/Type.h:155 #4 utl::ConfigManager::acquireTree (item=...) at ./unotools/source/config/configmgr.cxx:151 #5 0x7fdc60897005 in utl::ConfigManager::addConfigItem (this=0x7fdc61f6cfb0 ::get()::instance>, item=...) at ./unotools/source/config/configmgr.cxx:174 #6 0x7fdc6088ba5b in utl::ConfigItem::ConfigItem (this=0x5601664919e0, rSubTree="Setup/L10N", nSetMode=) at ./unotools/source/config/configitem.cxx:166 #7 0x7fdc608eb8b8 in SvtSysLocaleOptions_Impl::SvtSysLocaleOptions_Impl (this=0x5601664919e0) at ./include/rtl/stringutils.hxx:170 #8 0x7fdc608ecdaf in __gnu_cxx::new_allocator::construct (this=, __p=0x5601664919e0) at /usr/include/c++/8/new:169 #9 std::allocator_traits >::construct (__a=..., __p=0x5601664919e0) at /usr/include/c++/8/bits/alloc_traits.h:475 #10 std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>::_Sp_counted_ptr_inplace<>(std::allocator) (__a=..., this=0x5601664919d0) at /usr/include/c++/8/bits/shared_ptr_base.h:541 #11 std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count>(std::_Sp_make_shared_tag, SvtSysLocaleOptions_Impl*, std::allocator const&) (__a=..., this=) at /usr/include/c++/8/bits/shared_ptr_base.h:658 #12 std::__shared_ptr::__shared_ptr>(std::_Sp_make_shared_tag, std::allocator const&) (__a=..., __tag=..., this=) at /usr/include/c++/8/bits/shared_ptr_base.h:1324 #13 std::shared_ptr::shared_ptr>(std::_Sp_make_shared_tag, std::allocator const&) (__a=..., __tag=..., this=) at /usr/include/c++/8/bits/shared_ptr.h:360 #14 std::allocate_shared>(std::allocator const&) (__a=...) at /usr/include/c++/8/bits/shared_ptr.h:707 #15 std::make_shared () at /usr/include/c++/8/bits/shared_ptr.h:723 #16 SvtSysLocaleOptions::SvtSysLocaleOptions (this=0x7ffc2d040a80) at ./unotools/source/config/syslocaleoptions.cxx:543 #17 0x7fdc60c3e470 in InitVCL () at ./vcl/source/app/svmain.cxx:337 #18 0x7fdc60c3fa0d
Bug#921177: does not promptly restart dhclient after suspend/resume
Package: wpasupplicant
Version: 2:2.7-3
Severity: normal
wpasupplicant does not promptly restart dhclient after suspending and
resuming my laptop.
Expected behaviour: if I suspend my laptop, move to a different
location, and resume my laptop, wpasupplicant should associate to the
new network and promptly get a new DHCP lease.
Current behaviour: wpasupplicant associates to the new network but takes
several minutes to attempt to get a new lease. (It is not clear to me
whether dhclient gets a new lease on its own or because it gets prodded
by wpa_supplicant.) Practically speaking, this means I end up having to
manually put the interface down and up again.
Notice the significant lag between associating (11:16:17) and dhclient
finally attempting to get a lease (11:18:43) in the output of journalctl
below. This was after suspending my laptop and moving it from work to
home.
-journalctl-
rak@zeta:~$ sudo journalctl -xe --since=2019-02-02 | egrep -i '(wpa|wlp2)'
Feb 02 11:16:14 zeta kernel: wlp2s0: deauthenticating from b4:5d:50:cc:f3:f3 by
local choice (Reason: 3=DEAUTH_LEAVING)
Feb 02 11:16:14 zeta wpa_supplicant[1006]: wlp2s0: CTRL-EVENT-DISCONNECTED
bssid=b4:5d:50:cc:f3:f3 reason=0
Feb 02 11:16:14 zeta wpa_supplicant[1006]: wlp2s0: PMKSA-CACHE-REMOVED
b4:5d:50:cc:f3:f3 0
Feb 02 11:16:17 zeta wpa_supplicant[1006]: wlp2s0: Trying to associate with
c4:e9:84:e2:28:8e (SSID='MySSID' freq=2422 MHz)
Feb 02 11:16:17 zeta wpa_supplicant[1006]: Failed to add supported operating
classes IE
Feb 02 11:16:17 zeta kernel: wlp2s0: authenticate with c4:e9:84:e2:28:8e
Feb 02 11:16:17 zeta kernel: wlp2s0: send auth to c4:e9:84:e2:28:8e (try 1/3)
Feb 02 11:16:17 zeta kernel: wlp2s0: authenticated
Feb 02 11:16:17 zeta kernel: wlp2s0: associate with c4:e9:84:e2:28:8e (try 1/3)
Feb 02 11:16:17 zeta wpa_supplicant[1006]: wlp2s0: Associated with
c4:e9:84:e2:28:8e
Feb 02 11:16:17 zeta kernel: wlp2s0: RX AssocResp from c4:e9:84:e2:28:8e
(capab=0x31 status=0 aid=2)
Feb 02 11:16:17 zeta kernel: wlp2s0: associated
Feb 02 11:16:17 zeta wpa_supplicant[1006]: wlp2s0: CTRL-EVENT-EAP-SUCCESS EAP
authentication completed successfully (based on lower layer success)
Feb 02 11:16:17 zeta wpa_supplicant[1006]: wlp2s0: WPA: Key negotiation
completed with c4:e9:84:e2:28:8e [PTK=CCMP GTK=CCMP]
Feb 02 11:16:17 zeta wpa_supplicant[1006]: wlp2s0: CTRL-EVENT-CONNECTED -
Connection to c4:e9:84:e2:28:8e completed [id=2 id_str=]
Feb 02 11:17:20 zeta dhclient[1505]: XMT: Solicit on wlp2s0, interval 123840ms.
Feb 02 11:18:43 zeta charon[6269]: 09[KNL] 128.237.183.78 disappeared from
wlp2s0
Feb 02 11:18:43 zeta charon-systemd[1137]: 128.237.183.78 disappeared from
wlp2s0
Feb 02 11:18:43 zeta dhclient[1367]: DHCPDISCOVER on wlp2s0 to 255.255.255.255
port 67 interval 7
Feb 02 11:18:44 zeta dhclient[1367]: DHCPREQUEST for 192.168.0.51 on wlp2s0 to
255.255.255.255 port 67
Feb 02 11:18:44 zeta charon[6269]: 11[KNL] 192.168.0.51 appeared on wlp2s0
Feb 02 11:18:44 zeta charon-systemd[1137]: 192.168.0.51 appeared on wlp2s0
Feb 02 11:19:24 zeta dhclient[1505]: XMT: Solicit on wlp2s0, interval 123140ms.
Feb 02 11:21:27 zeta dhclient[1505]: XMT: Solicit on wlp2s0, interval 115530ms.
-
/etc/network/interfaces--
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eno1
iface eno1 inet dhcp
auto wlp2s0
allow-hotplug wlp2s0
iface wlp2s0 inet manual
wpa-driver wext
wpa-roam /home/rak/.config/wpa_supplicant.conf
iface default inet dhcp
iface default inet6 dhcp
-
/home/rak/.config/wpa_supplicant.conf
# Use the following command to generate a new network block:
# wpa_passphrase SSID PASSPHRASE
ap_scan=1
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
network={
ssid="CMU-SECURE"
priority=10
scan_ssid=1
proto=RSN
key_mgmt=WPA-EAP
pairwise=CCMP
eap=PEAP
domain_suffix_match="cmu.edu"
identity=XXX
password=XXX
ca_path="/etc/ssl/certs"
}
network={
ssid="eduroam"
priority=5
scan_ssid=1
key_mgmt=WPA-EAP
eap=PEAP
phase2="auth=MSCHAPV2"
domain_suffix_match="queensu.ca"
identity=XXX
password=XXX
ca_path="/etc/ssl/certs"
}
network={
ssid="MySSID"
priority=2
scan_ssid=1
psk=XXX
}
network={
ssid="FlyPittsburgh"
scan_ssid=1
}
network={
ssid="VIA_WIFI_VIDEO"
Bug#921004: amdgpu: The CS has been cancelled because the context is lost.
Hello Jean-Dominique Frattini, I am not involved in packaging any of these packages, but I noted that you opened the last three days nearly the same issue against three different packages? What are you trying to achive that way? And you noted versions contained in current Buster, but you claim it is Stretch? You write it is a regression - do you know the package versions or the date when it was working like expected? Also giving an example application that triggers that error message could maybe make the bug report more attractive to get some one having the matching hardware looking at it. Kind regards, Bernhard
Bug#862771: sciplot FTBFS on ppc64{,el}: ld: unrecognised emulation mode: minimal-toc
Thanks. I wrote autotools scripts a while ago, need to dust them off and get them working...
Bug#841270: RFS: debrequest/0.2 ITP
user devscri...@packages.debian.org usertag 841270 new retitle 841270 new script: debrequest -- tool to generate RFS and ITP requests mails thanks [ Thanks to Bart for reassigning the bug ] On Wed, Jan 30, 2019 at 08:48:57PM +, Dmitry Bogatov wrote: > [2016-10-21 08:09] Gianfranco Costamagna > > >It might be more useful to add this to `devscripts` or some other > > >existing package rather than adding a new package. > > Hi! > > For now, I uploaded debrequest into experimental, but ideally it should > be merged into devscripts. Then it would most likely make sense to reject that package first and talk about having it integrated, before needless conflicts appear. > Dear devscript maintainers, how should we proceed? Please work on a patch (I'd prefer a MR on salsa, but I can work with patches as well) to integrate it. Incidentally, looking at https://salsa.debian.org/kaction/debrequest/blob/master/debrequest/templates/ITP I already see things that are wrong, like X-Debug-Cc: debian-de...@lists.debian.org (that should be X-Debbugs-Cc) or the equivalent in the RFS template, which shouldn't be X-Debbugs-CC anybody, since RFSs mails are already sent to d-mentors@ by themselves. Also, I'd like for you to check with the mentors.d.n code and make sure the template matches, keeping in mind that there is some kind of plan to make mentors send such mail automatically. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#921161: popularity-contest: Minor error in Russian translation
On Sat, Feb 02, 2019 at 04:40:17PM +0300, Rince wrote: > Package: popularity-contest > Version: 1.64 > Severity: minor > > Dear Maintainer, > > We noticed a misprint in the Russian translation of the package > configuration dialogue and corrected the mistake Dear Rince, Your report seems a duplicate of bug #863017 This patch was already applied to popcon 1.65 released on the 17 Jun 2017. Cheers, -- Bill. Imagine a large red swirl here.
Bug#921120: [Debian-science-sagemath] sagetex autopkgtest regression due to python-tk
Hello Tobias, On 02/02/2019 19:28, Tobias Hansen wrote: > I can also add it to sagemath, I have to do another upload anyway. I have just added to python-sagetex wrt Alexis hints. Cheers, Jerome > > Best, > Tobias > > On 2/2/19 7:06 AM, Jerome BENOIT wrote: >> tags 921120 ftbfs >> thanks >> >> On 01/02/2019 20:45, Tobias Hansen wrote: >>> Hi all, >>> >>> in the last update of sagemath I removed the dependency on python-tk. Now >>> the sagetex autopkgtest failed because python-matplotlib only recommends >>> python-tk and autopkgtests apparently don't install recommends. I guess the >>> one at fault here are the autopkgtesters for not installing recommends, but >>> I filed a bug against matplotlib2 asking to make it a dependency >>> (https://bugs.debian.org/921108) which was closed as "works as intended". >>> >>> Not sure what to do here. As long as it doesn't prevent sagemath 8.6-4 from >>> entering testing... >> sagetex now fails to build from source. >> >> I can add python-tk to the Depends field in d/control , but I think it must >> be corrected earlier in the Dependency chain: >> sagemath seem the right place if matplotlib2 does not want to add it. >> >> Please let me know if I have to add python-tk to the Depends field of the >> SageTeX Debian pacakge. >> >> Cheers, >> Jerome >> >>> Best, >>> >>> Tobias >>> >>> >>> >>> ___ >>> Debian-science-sagemath mailing list >>> debian-science-sagem...@alioth-lists.debian.net >>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath >>> >> >> ___ >> Debian-science-sagemath mailing list >> debian-science-sagem...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath > > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Bug#921176: redis-server service is failing to start in buster lxc container
package: redis-server version: 5:5.0.3-4 severity: grave justification: unstable to start the service journalctl -xe shows this error. This used to work before. It is clean lxc install on a sid host. sudo lxc-create -n buster -t debian -- -r buster I was trying to install gitlab, but that failed because redis-server is not running. -- The job identifier is 1139.5:5.0.3-4 ഫെബ്രു 02 15:47:54 gitlab-buster systemd[4302]: redis-server.service: Failed to set up mount namespacing: Permission denied ഫെബ്രു 02 15:47:54 gitlab-buster systemd[4302]: redis-server.service: Failed at step NAMESPACE spawning /usr/bin/redis-server: Permission denied -- Subject: Process /usr/bin/redis-server could not be executed
Bug#794624: already in new
https://ftp-master.debian.org/new/web-mode_16.0.21-1.html
Bug#921175: fwupdmgr: doesn't install latest firmware update (0.1.25) on Thinkpad X280
Package: fwupd Version: 1.1.4-1 Severity: important Dear Maintainer, after doing "fwupdmgr refresh", "fwupdmgr update" downloads the latest firmware update for my Thinkpad X280 and, as always, asks for a reboot to install it. With the former updates, after reboot, it installed the firmware update and rebooted again. Now, with the latest update (0.1.25), the reboot is just like a normal reboot. It boots into Debian without installing the firmware update. The current firmware is 0.1.23 Cheers Armin -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fwupd depends on: ii libappstream-glib8 0.7.14-1 ii libarchive13 3.3.3-3 ii libc6 2.28-5 ii libefiboot137-1 ii libefivar1 37-1 ii libelf10.175-2 ii libfwupd2 1.1.4-1 ii libgcab-1.0-0 1.2-2 ii libglib2.0-0 2.58.2-4 ii libgnutls303.6.6-2 ii libgpg-error0 1.33-3 ii libgpgme11 1.12.0-6 ii libgudev-1.0-0 232-2 ii libgusb2 0.3.0-1 ii libjson-glib-1.0-0 1.4.4-2 ii libpolkit-gobject-1-0 0.105-25 ii libsmbios-c2 2.4.1-1 ii libsoup2.4-1 2.64.2-2 ii libsqlite3-0 3.26.0+fossilbc891ac6b-2 ii libuuid1 2.33.1-0.1 Versions of packages fwupd recommends: ii bolt 0.7-2 ii fwupd-amd64-signed [fwupd-signed] 1.1.4+1 ii python33.7.2-1 fwupd suggests no packages. -- no debconf information
Bug#794624: RFP: web-mode -- web template editing mode for emacs
On 2019-02-01 18:49:53, Nicholas D Steeves wrote: > Hi Antoine and Emacsen team, > > On Tue, Aug 04, 2015 at 09:43:38PM -0700, Francois Marier wrote: >> Package: wnpp >> Severity: wishlist >> >> * Package name: web-mode >> Version : 12 >> Upstream Author : François-Xavier Bois >> * URL : http://web-mode.org/ >> * License : GPL >> Programming Lang: emacs lisp >> Description : web template editing mode for emacs >> >> web-mode.el is an autonomous emacs major-mode for editing web templates. >> HTML documents can embed parts (CSS / JavaScript) and blocks (client / >> server side). > > Do you want to co-maintain this one? PHP-mode recommends using > web-mode for files that are HTML+PHP blocks. I think it would be a > useful addition to the archive, but I don't use it myself... > > With a MELPA popcon at 99.12 percentile, it really ought to be packaged. I can sponsor you if necessary, but I don't feel like co-maintaining, if you don't mind. A. -- Sous le projecteur, on ne voit pas les autres. - Félix Leclerc
Bug#921120: [Debian-science-sagemath] Bug#921120: sagetex autopkgtest regression due to python-tk
Ok, thanks. Also has the advantage that we can avoid a sagemath upload now, which would delay testing migration of all these packages another two days. Best, Tobias On 2/2/19 4:42 PM, Jerome BENOIT wrote: > Hello Tobias, > > On 02/02/2019 19:28, Tobias Hansen wrote: >> I can also add it to sagemath, I have to do another upload anyway. > I have just added to python-sagetex wrt Alexis hints. > > Cheers, > Jerome > >> Best, >> Tobias >> >> On 2/2/19 7:06 AM, Jerome BENOIT wrote: >>> tags 921120 ftbfs >>> thanks >>> >>> On 01/02/2019 20:45, Tobias Hansen wrote: Hi all, in the last update of sagemath I removed the dependency on python-tk. Now the sagetex autopkgtest failed because python-matplotlib only recommends python-tk and autopkgtests apparently don't install recommends. I guess the one at fault here are the autopkgtesters for not installing recommends, but I filed a bug against matplotlib2 asking to make it a dependency (https://bugs.debian.org/921108) which was closed as "works as intended". Not sure what to do here. As long as it doesn't prevent sagemath 8.6-4 from entering testing... >>> sagetex now fails to build from source. >>> >>> I can add python-tk to the Depends field in d/control , but I think it must >>> be corrected earlier in the Dependency chain: >>> sagemath seem the right place if matplotlib2 does not want to add it. >>> >>> Please let me know if I have to add python-tk to the Depends field of the >>> SageTeX Debian pacakge. >>> >>> Cheers, >>> Jerome >>> Best, Tobias ___ Debian-science-sagemath mailing list debian-science-sagem...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath >>> ___ >>> Debian-science-sagemath mailing list >>> debian-science-sagem...@alioth-lists.debian.net >>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath >> > > ___ > Debian-science-sagemath mailing list > debian-science-sagem...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
Bug#601054: add comments to /etc/init.d/.depend.* saying what program put them there
On 2/2/19 6:26 AM, Dmitry Bogatov wrote: > I believe we already discussed this issue and came to conclusion, that > the right thing to do would be to generate .depends files in > /var/lib/insserv and adjust `startpar' accordingly. Someone suggested doing this, it was an option on the table. But no agreement has been come to so far as I know.
Bug#921120: sagemath breaks sagetex autopkgtest: ImportError: No module named _tkinter, please install the python-tk package
Dear Alexis, thanks for your analysis.
I am on my way to repack sagetex
Cheers,
Jerome
On 02/02/2019 18:36, Alexis Murzeau wrote:
> On Fri, 1 Feb 2019 20:45:08 +0100 Paul Gevers wrote:
>> reassign 921120 src:sagetex 3.2+ds-1
>> retitle 921120 sagetex (autopkgtest) depends misses python-tk
>> affects 921120 src:sagemath
>> thanks
>>
>> Hi Tobias, sagemath maintainers
>>
>> On 01-02-2019 20:35, Tobias Hansen wrote:
>>> I guess the solution is to add python-tk to Depends: in the sagetex
>>> autopkgtest control file.
>>
>> I think so too, thus reassigning. Mind you, I haven't checked if sagetex
>> needs the python-tk regular dependency even.
>>
>> Paul
>>
>
> Hi,
>
> I didn't know about sagetex before but checked what's wrong to unblock
> sphinx migration.
>
> I found that sagetex might require python-tk as a backend when using
> \sageplot in latex.
> Autopkgtest fail when testing that line [0]:
> ```
> \sageplot[width=.75\textwidth]{p, axes=False}
> ```
>
> So this is not really a test-only dependency, but also a sagetex itself one.
>
> Actually, I found in [1] that matplotlib can use many different
> backends. There are rendering backends and interactive backends. Cairo
> is a rendering backend for example, and TK is an interactive one.
> The default used backend is choosen according to different things
> (configuration file, environment variable, python function call).
>
> Actually, sagetex is using the default backend which is TkAgg and so
> require python-tk when doing `\sageplot`.
>
> => the minimal solution is to add a dependency on python-tk in sagetex.
>
> But I don't think sagetex require an interactive backend, but just
> something that can generate a pdf, eps of image file is enough.
> So a rendering backend could be enough for sagetex.
> Also, sagetex should not depend on user configuration of matplotlib.
>
> => So in the long run, I think sagetex should:
> - Depend on a specific rendering backend like cairo that does all
> required formats (eps, pdf, png and formats provided by users)
> - Use matplotlib.use('cairo') (or another backend) so only a known
> working backend is used and not whatever the user configured.
>
> According to [1], cairo is the only one to support multiple formats
> including eps, pdf and png.
>
> But switching now from the default python-tk to cairo might be a too big
> change now that the soft freeze is near and that it blocks other
> packages from migrating ...
>
> So I suggest to just add a dependency on python-tk in sagetex for buster
> and implement the other solution with longer thinking of impacts later.
>
> [0] https://salsa.debian.org/tex-team/sagetex/blob/master/example.tex#L97
> [1] https://matplotlib.org/faq/usage_faq.html#what-is-a-backend
>
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
signature.asc
Description: OpenPGP digital signature
Bug#921120: sagemath breaks sagetex autopkgtest: ImportError: No module named _tkinter, please install the python-tk package
Le 02/02/2019 à 16:23, Jerome BENOIT a écrit : > Dear Alexis, thanks for your analysis. > I am on my way to repack sagetex > Cheers, > Jerome > Hi, Ok nice, thanks :) -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#920607: Debian Buster installer on qnap ts-21x / Fujitsu Q700 : /dev/mtdblock* missing
Control: tag -1 + pending On Wed, Jan 30, 2019 at 09:42:32PM +0100, Uwe Kleine-König wrote: > Maybe adding spi-orion to > debian/installer/modules/armel-marvell/mtd-modules is the right fix > here, but I don't understand enough about the generation of udebs to > judge if this is right. After getting some feedback off-list I committed this to linux.git (https://deb.li/i78Aj). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Bug#921120: [Debian-science-sagemath] sagetex autopkgtest regression due to python-tk
I can also add it to sagemath, I have to do another upload anyway. Best, Tobias On 2/2/19 7:06 AM, Jerome BENOIT wrote: > tags 921120 ftbfs > thanks > > On 01/02/2019 20:45, Tobias Hansen wrote: >> Hi all, >> >> in the last update of sagemath I removed the dependency on python-tk. Now >> the sagetex autopkgtest failed because python-matplotlib only recommends >> python-tk and autopkgtests apparently don't install recommends. I guess the >> one at fault here are the autopkgtesters for not installing recommends, but >> I filed a bug against matplotlib2 asking to make it a dependency >> (https://bugs.debian.org/921108) which was closed as "works as intended". >> >> Not sure what to do here. As long as it doesn't prevent sagemath 8.6-4 from >> entering testing... > sagetex now fails to build from source. > > I can add python-tk to the Depends field in d/control , but I think it must > be corrected earlier in the Dependency chain: > sagemath seem the right place if matplotlib2 does not want to add it. > > Please let me know if I have to add python-tk to the Depends field of the > SageTeX Debian pacakge. > > Cheers, > Jerome > >> Best, >> >> Tobias >> >> >> >> ___ >> Debian-science-sagemath mailing list >> debian-science-sagem...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath >> > > ___ > Debian-science-sagemath mailing list > debian-science-sagem...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
Bug#921174: RM: wsjtx [kfreebsd-i386 kfreebsd-i386 hurd-i386] -- ANAIS; package is now linux-any
Package: ftp.debian.org X-Debbugs-Cc: ws...@packages.debian.org Control: block 920171 by -1 wsjtx is now linux-any since, so these old binaries are now cruft. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#921173: RM: sdpa [armel hurd-i386 mips mipsel] -- RoQA; not buildable anymore since a build-dep is gone
Package: ftp.debian.org Control: block 920171 by -1 X-Debbugs-Cc: s...@packages.debian.org sdpa build-depends on openblas, but openblas is not built on those architectures anymore, therefore sdpa can't be built there anymore. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#921172: qmath3d: Please stop build-depending on gcc-6
Source: qmath3d Version: 0~1.0-1 Severity: serious Control: block 920171 by -1 X-Debbugs-Cc: Wookey Dear maintainer, your new package qmath3d has Build-Depends: debhelper (>= 10), qbs, qtbase5-dev, dh-exec, libstdc++-6-dev We are going to remove gcc-6 soon, so please stop build-depending on libstdc++-6-dev. I would also be curious to know such an odd dependency is needed, libstdc++-7-dev (which is pulled in by build-essential) is no good? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#921171: ITP: liblogger-simple-perl -- Simran-Log-Log and Simran-Error-Error modules
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: liblogger-simple-perl Version : 2.0 Upstream Author : Thomas Stanley * URL : https://metacpan.org/pod/distribution/Logger-Simple/Simple.pm * License : GPL or Artistic Programming Lang: Perl Description : Simran-Log-Log and Simran-Error-Error modules This module provides an easier interface for functionality known from the Simran::Log::Log and Simran::Error::Error modules.
Bug#921170: soupsieve: FTBFS in sid (test_namespace_xml_with_namespace fails)
Package: src:soupsieve
Version: 1.7.3+dfsg-1
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in sid but it failed:
[...]
debian/rules binary-indep
dh binary-indep --with python2,python3,pypy --buildsystem=pybuild
dh_update_autotools_config -i -O--buildsystem=pybuild
dh_autoreconf -i -O--buildsystem=pybuild
dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config
running config
I: pybuild base:217: python3.7 setup.py config
running config
I: pybuild base:217: pypy setup.py config
running config
dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python setup.py build
running build
running build_py
creating
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython2_2.7_soupsieve/build/soupsieve
copying soupsieve/util.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython2_2.7_soupsieve/build/soupsieve
copying soupsieve/css_parser.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython2_2.7_soupsieve/build/soupsieve
copying soupsieve/__init__.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython2_2.7_soupsieve/build/soupsieve
copying soupsieve/__meta__.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython2_2.7_soupsieve/build/soupsieve
copying soupsieve/css_types.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython2_2.7_soupsieve/build/soupsieve
copying soupsieve/css_match.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython2_2.7_soupsieve/build/soupsieve
I: pybuild base:217: /usr/bin/python3 setup.py build
running build
running build_py
creating
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython3_3.7_soupsieve/build/soupsieve
copying soupsieve/util.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython3_3.7_soupsieve/build/soupsieve
copying soupsieve/css_parser.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython3_3.7_soupsieve/build/soupsieve
copying soupsieve/__init__.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython3_3.7_soupsieve/build/soupsieve
copying soupsieve/__meta__.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython3_3.7_soupsieve/build/soupsieve
copying soupsieve/css_types.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython3_3.7_soupsieve/build/soupsieve
copying soupsieve/css_match.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython3_3.7_soupsieve/build/soupsieve
I: pybuild base:217: /usr/bin/pypy setup.py build
running build
running build_py
creating
/<>/soupsieve-1.7.3+dfsg/.pybuild/pypy_6.0_soupsieve/build/soupsieve
copying soupsieve/util.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/pypy_6.0_soupsieve/build/soupsieve
copying soupsieve/css_parser.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/pypy_6.0_soupsieve/build/soupsieve
copying soupsieve/__init__.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/pypy_6.0_soupsieve/build/soupsieve
copying soupsieve/__meta__.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/pypy_6.0_soupsieve/build/soupsieve
copying soupsieve/css_types.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/pypy_6.0_soupsieve/build/soupsieve
copying soupsieve/css_match.py ->
/<>/soupsieve-1.7.3+dfsg/.pybuild/pypy_6.0_soupsieve/build/soupsieve
dh_auto_test -i -O--buildsystem=pybuild
I: pybuild base:217: cd
/<>/soupsieve-1.7.3+dfsg/.pybuild/cpython2_2.7_soupsieve/build;
python2.7 -m pytest tests
= test session starts ==
platform linux2 -- Python 2.7.15+, pytest-3.10.1, py-1.7.0, pluggy-0.8.0
rootdir: /<>/soupsieve-1.7.3+dfsg, inifile: tox.ini
collected 227 items
tests/test_bs4_cases.py F[ 2%]
tests/test_extra.py .. [ 6%]
tests/test_level1.py .. [ 18%]
tests/test_level2.py [ 33%]
tests/test_level3.py ... [ 56%]
.[ 56%]
tests/test_level4.py ... [ 79%]
... [ 82%]
tests/test_soupsieve.py [ 98%]
tests/test_versions.py [100%]
=== FAILURES ===
__ test_namespace_xml_with_namespace ___
@util.requires_lxml
def test_namespace_xml_with_namespace():
"""Test namespace selectors with XML."""
xml = BeautifulSoup(NAMESPACE_XML, "xml")
> assert xml.select_one("x|Envelope", namespaces=NAMESPACES)
E TypeError: select_one() got an unexpected keyword argument 'namespaces'
tests/test_bs4_cases.py:142: TypeError
= 1 failed, 226 passed in 2.62 seconds =
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd
