Bug#920673: firefox alsa
this is valid only for FF ESR. the latest versions are build without ALSA support per default. you would have to compile FF with ALSA enabled and PULSE disabled to get sound in FF on pure ALSA systems. please read: https://bugzilla.mozilla.org/show_bug.cgi?id=1247056#c178 On Wed, 13 Feb 2019 at 17:22, Mike Hommey wrote: > On Wed, Feb 13, 2019 at 04:41:28PM -0500, Erik Dobák wrote: > > Hi Mike, > > > > how was it fixed? > > > > i cant find an alternative alsa/firefox package when searching: > > The firefox package itself has support for alsa. >
Bug#922272: irssi-plugin-otr: trying to overwrite '/usr/share/irssi/help/otr', which is also in package irssi 1.2.0-1
Hi, you are right, but: This issue exists only with upgrade from the broken 1.2.0-1 package. Which isn't available anymore, it was there for way less than a day. I am much more leaning towards a "wontfix" than doing the Replaces & Conflicts dance and carry that for ... when would then be practical to remove it again? It doesn't affect upgrades from anything available right now already. Are you fine with ignoring this as an unfortunate side-effect for an issue that only existed in 1.2.0-1 which was available less than 13 hours? Thanks, Rhonda On 2/14/19 1:11 AM, Axel Beckert wrote: > Package: irssi-plugin-otr > Version: 1.2.0-1 > Severity: serious > > Hi Rhonda, > > unfortunately the file moving between irssi and irssi-plugin-otr doesn't > seem to completely fixed yet. When upgrading them from 1.2.0-1 to > 1.2.0-2, I get: > > Preparing to unpack .../04-irssi-plugin-otr_1.2.0-2_amd64.deb ... > Unpacking irssi-plugin-otr (1.2.0-2) over (1.2.0-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-dVLCdE/04-irssi-plugin-otr_1.2.0-2_amd64.deb (--unpack): > trying to overwrite '/usr/share/irssi/help/otr', which is also in package > irssi 1.2.0-1 > Preparing to unpack .../05-irssi_1.2.0-2_amd64.deb ... > Unpacking irssi (1.2.0-2) over (1.2.0-1) ... > > -- System Information: > Debian Release: buster/sid > APT prefers unstable > APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), > (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), > (1, 'buildd-experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > LSM: AppArmor: enabled > > Versions of packages irssi-plugin-otr depends on: > ii irssi1.2.0-2 > ii libc62.28-7 > ii libgcrypt20 1.8.4-5 > ii libotr5 4.1.1-3 > > irssi-plugin-otr recommends no packages. > > irssi-plugin-otr suggests no packages. > > -- no debconf information >
Bug#920673: firefox alsa
On Thu, Feb 14, 2019 at 07:56:48AM -0500, Erik Dobák wrote: > this is valid only for FF ESR. the latest versions are build without ALSA > support per default. you would have to compile FF with ALSA enabled and > PULSE disabled to get sound in FF on pure ALSA systems. please read: > https://bugzilla.mozilla.org/show_bug.cgi?id=1247056#c178 The latest versions are built with alsa enabled. https://salsa.debian.org/mozilla-team/firefox/blob/78b1595b87e4853b52be389021042078774f4cc8/debian/browser.mozconfig.in#L38
Bug#888556: closed by Andreas Tille (Bug#888556: fixed in etsf-io 1.0.4-3)
Control: found -1 1.0.4-3 On 2019-02-12 09:51, Debian Bug Tracking System wrote: >* libetsf-io-doc Breaks/Replaces: libetsf-io-dev (<= 1.0.4-1.1) That needs to be (<< 1.0.4-2) to also cover the binNMUs. Andreas
Bug#922243: mailman3-full : Depends: mailman3 but it is not going to be installed
Hi. mailman3 is not part of stretch but stretch-backports. Your sources.list has stretch-backports commented out. Please,uncomment the backports lines, run an aptitude update and try again installing mailman3-full Best regards. -- PEB from my phone.
Bug#918339: The patch seems to match
The patch https://github.com/dovecot/core/commit/3c5101ffdd2a8115e03ed7180d53578765dea4c9.patch that Peter mentions indeed seems to address the issue. Could this be merged? Thank you. The problem still persists here.
Bug#922286: python-apptools-doc: missing Breaks+Replaces: python-apptools (<< 4.4.0)
Package: python-apptools-doc Version: 4.4.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 .../python-apptools-doc_4.4.0-1_all.deb ... Unpacking python-apptools-doc (4.4.0-1) ... dpkg: error processing archive /var/cache/apt/archives/python-apptools-doc_4.4.0-1_all.deb (--unpack): trying to overwrite '/usr/share/doc/python-apptools/examples/appscripting/example.py', which is also in package python-apptools 4.3.0-1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/python-apptools-doc_4.4.0-1_all.deb cheers, Andreas python-apptools=4.3.0-1_python-apptools-doc=4.4.0-1.log.gz Description: application/gzip
Bug#920673: firefox alsa
thank you for that one. yes i see: ac_add_options --enable-alsa but please explain. does this one work with alsa and pulse? i always thought it is now alsa xor pulse. also please let me know the version number from which one this applies. On Thu, 14 Feb 2019 at 03:12, Mike Hommey wrote: > On Thu, Feb 14, 2019 at 07:56:48AM -0500, Erik Dobák wrote: > > this is valid only for FF ESR. the latest versions are build without ALSA > > support per default. you would have to compile FF with ALSA enabled and > > PULSE disabled to get sound in FF on pure ALSA systems. please read: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1247056#c178 > > The latest versions are built with alsa enabled. > > https://salsa.debian.org/mozilla-team/firefox/blob/78b1595b87e4853b52be389021042078774f4cc8/debian/browser.mozconfig.in#L38 >
Bug#782644: Re : Bug#782644: xscreensaver always rejects my password
Le 13/02/2019 23:24:41, Tormod Volden a écrit : > Nicolas, > I see that you are using a French locale and so probably have a French > keyboard. Is it possible that the keyboard mapping becomes wrong, so > it would work if you typed your password as if you had an English > keyboard? I suspect a problem with PAM because I can read a very quick yellow message from PAM on top of the screen. Note that Ctrl-Alt-Fx won’t let me out of X. Best regards, nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Bug#920673: firefox alsa
On Thu, Feb 14, 2019 at 08:25:12AM -0500, Erik Dobák wrote: > thank you for that one. yes i see: ac_add_options --enable-alsa > but please explain. does this one work with alsa and pulse? i always > thought it is now alsa xor pulse. yes, it works with alsa if pulse is not there. no, that's not supported upstream, so if it stops working in the future, don't be surprised. > also please let me know the version number from which one this applies. as per my first email: 62.0.3-1 Mike
Bug#922272: irssi-plugin-otr: trying to overwrite '/usr/share/irssi/help/otr', which is also in package irssi 1.2.0-1
Hi Rhonda, Rhonda D'Vine wrote: > you are right, but: This issue exists only with upgrade from the broken > 1.2.0-1 package. Which isn't available anymore, it was there for way > less than a day. I am much more leaning towards a "wontfix" than doing > the Replaces & Conflicts dance and carry that for ... when would then be > practical to remove it again? It doesn't affect upgrades from anything > available right now already. > > Are you fine with ignoring this [...] If that's the case, I'm totally fine with ignoring it. Feel free to close. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#922287: msxpertsuite-massxpert: missing Breaks+Replaces: massxpert
Package: msxpertsuite-massxpert Version: 5.8.5-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'stable'. It installed fine in 'stable', 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 This test intentionally skipped 'testing' to find file overwrite problems before packages migrate from 'unstable' to 'testing'. From the attached log (scroll to the bottom...): Preparing to unpack .../msxpertsuite-massxpert_5.8.5-1_amd64.deb ... Unpacking msxpertsuite-massxpert (5.8.5-1) ... dpkg: error processing archive /var/cache/apt/archives/msxpertsuite-massxpert_5.8.5-1_amd64.deb (--unpack): trying to overwrite '/usr/bin/massxpert', which is also in package massxpert 3.6.1-1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/msxpertsuite-massxpert_5.8.5-1_amd64.deb cheers, Andreas massxpert=3.6.1-1_msxpertsuite-massxpert=5.8.5-1.log.gz Description: application/gzip
Bug#922288: ruby-rails-assets-chartjs: doesn't build from upstream source
Source: ruby-rails-assets-chartjs Version: 1.0.2-1 Severity: serious Justification: doesn't build from source Control: affects -1 cacti ocsinventory-reports python3-ontospy Hi maintainer, While investigating ways to fix bug #896468 (new version for libjs-chartjs), I discovered that ruby-rails-assets-chartjs doesn't contain the source of Chart.js and for sure doesn't build Chart.js from the upstream source. Ironically, the same person (in a different team), packaged the same thing again in the node-chart.js source package. I propose to remove this package from Debian and all dependencies (in X-Debbugs-CC) must migrate to the new binary package. Paul signature.asc Description: OpenPGP digital signature
Bug#922243: mailman3-full : Depends: mailman3 but it is not going to be installed
Hi, Thanks for your help! :) I thought so, too, but I still doesn’t work. In detail, I changed my `/etc/apt/sources.list` to: > ## Note, this file is written by cloud-init on first boot of an instance > ## modifications made here will not survive a re-bundle. > ## if you wish to make changes you can: > ## a.) add 'apt_preserve_sources_list: true' to /etc/cloud/cloud.cfg > ## or do the same in user-data > ## b.) add sources in /etc/apt/sources.list.d > ## c.) make changes to template file > /etc/cloud/templates/sources.list.debian.tmpl > ### > > # See > http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.html > # for how to upgrade to newer versions of the distribution. > deb http://deb.debian.org/debian stretch main contrib non-free > deb-src http://deb.debian.org/debian stretch main contrib non-free > > ## Major bug fix updates produced after the final release of the > ## distribution. > deb http://security.debian.org/ stretch/updates main contrib non-free > deb-src http://security.debian.org/ stretch/updates main contrib non-free > deb http://deb.debian.org/debian stretch-updates main contrib non-free > deb-src http://deb.debian.org/debian stretch-updates main contrib non-free > > ## Uncomment the following two lines to add software from the 'backports' > ## repository. > ## > ## N.B. software from this repository may not have been tested as > ## extensively as that contained in the main release, although it includes > ## newer versions of some applications which may provide useful features. > deb http://deb.debian.org/debian stretch-backports main contrib non-free > deb-src http://deb.debian.org/debian stretch-backports main contrib non-free Then I tried to execute `sudo apt update` and `sudo apt install mailman3-full`; the result is the same: > The following packages have unmet dependencies: > mailman3-full : Depends: mailman3 but it is not going to be installed > Depends: mailman3-web (>= 0+20180916-1) but it is not going > to be installed > Depends: python3-mailman-hyperkitty but it is not going to > be installed > E: Unable to correct problems, you have held broken packages. Best, Keno > Am 14.02.2019 um 09:19 schrieb Pierre-Elliott Bécue : > > Hi. > > mailman3 is not part of stretch but stretch-backports. > > Your sources.list has stretch-backports commented out. > > Please,uncomment the backports lines, run an aptitude update and try again > installing mailman3-full > > Best regards. > -- > PEB from my phone.
Bug#905697: kdepimlibs: don't depend on libical
On Fri, 08 Feb 2019 at 22:46:21 +0100, Sandro Knauß wrote: > Keep in mind, that kdepimlibs is an old grufted lib set that we also would > like to kill. Perhaps you could ask the ftp team to override its Section to oldlibs to indicate this? > But we also have other packages depending on it like: > * basket > * kopete (it has a QT5 version in experimental, but this is suitable as > replacement yet). > and other that may can be killed. FYI, here is the size of the problem: smcv@coccia ~ % dak rm -R -n -s testing kdepimlibs libical ... Checking reverse dependencies... # Broken Depends: kde-runtime: kde-runtime kopete: kopete libkopete4 syncevolution: syncevolution-libs-kde # Broken Build-Depends: basket: kdepimlibs5-dev (>= 4:4.4.3) kde-runtime: kdepimlibs5-dev kopete: kdepimlibs5-dev syncevolution: kdepimlibs5-dev smcv
Bug#896189: update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave link same as main link /usr/bin/mpicc
clone 896644 -1 reassign -1 lam: lam alternatives break openmpi/mpich thanks Hi, This is due to lam not supporting the updated semantics for the mpi alternatives. The MPI alternatives in openmpi (default mpi) and mpich now honour multiarch, and the existing mpi alternatives in LAM need to be updated to do so. Alternatively, Lam could be removed (officially dead upstream since 2015 https://blogs.cisco.com/performance/a-farewell-to-lammpi) Regards Alastair On 12/02/2019 23:04, Ivo De Decker wrote: Control: reopen -1 Hi, On Fri, Apr 20, 2018 at 06:56:24PM +0300, Adrian Bunk wrote: [...] Setting up openmpi-bin (3.0.1-6) ... update-alternatives: using /usr/bin/mpirun.openmpi to provide /usr/bin/mpirun (mpirun) in auto mode update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave link same as main link /usr/bin/mpicc dpkg: error processing package openmpi-bin (--configure): installed openmpi-bin package post-installation script subprocess returned error exit status 2 It seems this issue is back in builds for netpipe: https://buildd.debian.org/status/fetch.php?pkg=netpipe&arch=amd64&ver=3.7.2-7.4%2Bb5&stamp=1550010019&raw=0 Setting up openmpi-bin (3.1.3-10) ... update-alternatives: using /usr/bin/mpirun.openmpi to provide /usr/bin/mpirun (mpirun) in auto mode update-alternatives: error: /var/lib/dpkg/alternatives/mpi corrupt: slave link same as main link /usr/bin/mpicc dpkg: error processing package openmpi-bin (--configure): installed openmpi-bin package post-installation script subprocess returned error exit status 2 Ivo -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#922243: mailman3-full : Depends: mailman3 but it is not going to be installed
Le jeudi 14 février 2019 à 09:40:46+0100, K E N O a écrit : > Hi, > > Thanks for your help! :) I thought so, too, but I still doesn’t work. In > detail, I changed my `/etc/apt/sources.list` to: > > > ## Note, this file is written by cloud-init on first boot of an instance > > ## modifications made here will not survive a re-bundle. > > ## if you wish to make changes you can: > > ## a.) add 'apt_preserve_sources_list: true' to /etc/cloud/cloud.cfg > > ## or do the same in user-data > > ## b.) add sources in /etc/apt/sources.list.d > > ## c.) make changes to template file > > /etc/cloud/templates/sources.list.debian.tmpl > > ### > > > > # See > > http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.html > > # for how to upgrade to newer versions of the distribution. > > deb http://deb.debian.org/debian stretch main contrib non-free > > deb-src http://deb.debian.org/debian stretch main contrib non-free > > > > ## Major bug fix updates produced after the final release of the > > ## distribution. > > deb http://security.debian.org/ stretch/updates main contrib non-free > > deb-src http://security.debian.org/ stretch/updates main contrib non-free > > deb http://deb.debian.org/debian stretch-updates main contrib non-free > > deb-src http://deb.debian.org/debian stretch-updates main contrib non-free > > > > ## Uncomment the following two lines to add software from the 'backports' > > ## repository. > > ## > > ## N.B. software from this repository may not have been tested as > > ## extensively as that contained in the main release, although it includes > > ## newer versions of some applications which may provide useful features. > > deb http://deb.debian.org/debian stretch-backports main contrib non-free > > deb-src http://deb.debian.org/debian stretch-backports main contrib non-free > > Then I tried to execute `sudo apt update` and `sudo apt install > mailman3-full`; the result is the same: The backports are pinned to not be installed from by default. You need to use the -t option. `sudo apt install -t stretch-backports mailman3-full` Regards. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them.
Bug#915559: coreutils: Use renameat2 from glibc instead of syscall
Control: severity -1 critical Hi Michael, On Wed, 06 Feb 2019 14:33:34 +0100 Johannes Schauer wrote: > Quoting Michael Stone (2019-02-06 14:22:10) > > On Wed, Feb 06, 2019 at 10:47:12AM +0100, Johannes Schauer wrote: > > >On Wed, 30 Jan 2019 12:07:37 +0100 Jonas Smedegaard wrote: > > >> Jus a friendly nudge: It would be great if this bug was fixed in time for > > >> Buster. > > >> > > >> Do you think you can find the time to have a look at the patches > > >> provided by Josch? > > >> > > >> Do you need some help? > > > > > >another week passed since Jonas' email. And more than seven weeks since > > >your > > >last activity in this bug. Unfortunately, fakechroot is not really usable > > >without mv(1). The mv(1) tool is used in apt and dash postinst maintainer > > >scripts, so this also affects debootstrap and mmdebstrap and thus in turn > > >also > > >packages using these tools. > > > > > >I thus hereby announce my intention to NMU coreutils with my two patches > > >in one > > >week (February 13) and a delay of 10 days (then in unstable by February > > >23). > > > > > >Please speak up if you are not okay with that plan. > > > > I'm not ok with that plan. > > what is your opinion about this bug and my proposed patch? > > What do you think would be the best way forward? Again, more than a week passed since my last message. You manage to reply within hours when it's about dismissing my offers to fix this bug in coreutils but when it is about explaining your reasoning you stay silent for weeks. Maybe my patch has a fatal flaw in it, maybe you want us to work together differently, maybe you want to fix the problem yourself (as indicated by your message "please just wait") or maybe I was missing something essential which makes my patch completely unacceptable. But so far you only left 9 words of text in this bug report offering no explanation at all. This is honestly very frustrating for me. :( I'm now raising the severity of this bug to "critical" because this bug "makes unrelated software on the system break" -- in this case it directly breaks fakechroot and it indirectly breaks the software using fakechroot. In case you do not agree with this severity level, please explain why you think that this bug is not RC even though it leads to another package becoming nearly unusable. Thanks! cheers, josch signature.asc Description: signature
Bug#905697: kdepimlibs: don't depend on libical
On 14/02/2019 09:50, Simon McVittie wrote: > On Fri, 08 Feb 2019 at 22:46:21 +0100, Sandro Knauß wrote: >> Keep in mind, that kdepimlibs is an old grufted lib set that we also would >> like to kill. > > Perhaps you could ask the ftp team to override its Section to oldlibs > to indicate this? > >> But we also have other packages depending on it like: >> * basket >> * kopete (it has a QT5 version in experimental, but this is suitable as >> replacement yet). >> and other that may can be killed. > > FYI, here is the size of the problem: > > smcv@coccia ~ % dak rm -R -n -s testing kdepimlibs libical > ... > Checking reverse dependencies... > # Broken Depends: > kde-runtime: kde-runtime > kopete: kopete > libkopete4 > syncevolution: syncevolution-libs-kde > > # Broken Build-Depends: > basket: kdepimlibs5-dev (>= 4:4.4.3) > kde-runtime: kdepimlibs5-dev > kopete: kdepimlibs5-dev > syncevolution: kdepimlibs5-dev kde-runtime has dozens of rdeps, so unless its dep on kdepimlibs can be broken somehow, this would be much harder to solve for buster. Emilio
Bug#921739: amtool: error: comment required by config
On Sat, Feb 09, 2019 at 12:06:50PM +, Martín Ferrari wrote: > Hi Santiago, > > On 08/02/2019 17:35, Santiago Vila wrote: > > > File /usr/share/doc/prometheus-alertmanager/README.md.gz suggests doing > > this: > > > > amtool silence add alertname=Test_Alert > > > > but this is what I get: > > > > amtool: error: comment required by config > > I don't know how that is configured, but you just need to add a comment > to the silence like '--comment="testing silences"' Ok, that worked, but I think it would be much better if such option could be added to the README.md.gz somewhere, or a README.Debian, or something. That will avoid searches in search engines, stackoverflow or the Debian BTS. There is yet another thing I didn't find anywhere and I would like to see documented somewhere in /usr/share/doc/prometheus-alertmanager: How do I add a silence which expires after one hour, for example? (The web UI allowed this, and in some sense it's basic stuff, so I think it should be documented as well). (Can you tell upstream to extend the README.md a little bit?) Thanks.
Bug#921382: kineticstools: autopkgtest needs update for new version of h5py
Hi Andreas,
On 13-02-2019 23:20, Andreas Tille wrote:
>> I don't want to offend you,
>
> You don't. ;-)
Good.
>> If you really don't know how to fix the issue, I guess you could reduce
>> the log-level in your test cases.
>
> OK, I tried
> + find test/cram -type f -name "*.t" -exec sed -i
> 's/--log-level=WARNING/--log-level=DEBUG/' \{\} \;
I meant the other direction. I don't know if it's the name, but
something like "--log-level=ERROR"
Paul
signature.asc
Description: OpenPGP digital signature
Bug#891324: radvd: Claims ::/64 prefix is invalid in the log
Hello, This is fixed upstream: https://github.com/reubenhwk/radvd/commit/b37baa1137d0bd5b9cceb2e447550f1c0a105ac6 -- With respect, Roman
Bug#922265: closed by Xavier Guimard (Bug#922265: fixed in lemonldap-ng 2.0.2+ds-2)
found 922265 2.0.2+ds-2 thanks Hello Xavier. I'm really sorry for the reopening, but this does not seem fixed: https://buildd.debian.org/status/fetch.php?pkg=lemonldap-ng&arch=all&ver=2.0.2%2Bds-2&stamp=1550093722&raw=0 If for whatever reason you could not reproduce this, please contact me privately. Sometimes, when not everybody is able to reproduce the failure, I offer a test machine to ssh into. Thanks.
Bug#896468: libjs-chartjs: Please upload newer versions
On Sat, 21 Apr 2018 12:24:49 +0100 Federico Ceratto wrote: > The package has not been updated since 2015. Can you please upload the > latest release? (Currently 2.7.2) gitlab was locked to 1.0.2, but they have also moved to 2.7.2 so I will update soon. Can someone check if python3-ontospy is also compatible? $ reverse-depends libjs-chartjs Reverse-Depends === * cacti * ocsinventory-reports * python3-ontospy * ruby-rails-assets-chartjs reverse-depends -b libjs-chartjs Reverse-Build-Depends = * ontospy signature.asc Description: OpenPGP digital signature
Bug#922290: cyrus-imapd: /usr/lib/tmpfiles.d/cyrus-imapd.conf is missing
Package: cyrus-imapd Version: 3.0.8-1 Severity: important Tags: patch Without this file cyrus doesn't start : cyrus/master[13622]: unable to bind to lmtpunix/unix socket: No such file or directory cyrus/master[13622]: unable to create lmtpunix listener socket: No such file or directory cyrus/master[13622]: unable to bind to notify/unix socket: No such file or directory cyrus/master[13622]: unable to create notify listener socket: No such file or directory -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/12 CPU cores) 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cyrus-imapd depends on: ii cyrus-common 3.0.8-1 ii dpkg 1.19.4 ii libc6 2.28-7 ii libcom-err2 1.44.5-1 ii libsasl2-22.1.27+dfsg-1 ii libssl1.1 1.1.1a-1 ii libwrap0 7.6.q-27 ii zlib1g1:1.2.11.dfsg-1 cyrus-imapd recommends no packages. cyrus-imapd suggests no packages. -- no debconf information diff -Nru cyrus-imapd-3.0.8.orig/debian/conffiles cyrus-imapd-3.0.8/debian/conffiles --- cyrus-imapd-3.0.8.orig/debian/conffiles 1970-01-01 01:00:00.0 +0100 +++ cyrus-imapd-3.0.8/debian/conffiles 2019-02-14 10:52:53.762162515 +0100 @@ -0,0 +1 @@ +/usr/lib/tmpfiles.d/cyrus-imapd.conf diff -Nru cyrus-imapd-3.0.8.orig/debian/cyrus-common.install cyrus-imapd-3.0.8/debian/cyrus-common.install --- cyrus-imapd-3.0.8.orig/debian/cyrus-common.install 2019-02-08 15:43:38.0 +0100 +++ cyrus-imapd-3.0.8/debian/cyrus-common.install 2019-02-13 16:27:22.539335189 +0100 @@ -44,6 +44,7 @@ usr/lib/cyrus/cyrus-*.txt usr/lib/cyrus/get-backtrace.gdb usr/lib/cyrus/upgrade/ +usr/lib/tmpfiles.d/cyrus-imapd.conf usr/sbin/cyrus usr/share/man/man5/cyrus.conf.5 usr/share/man/man5/imapd.conf.5 diff -Nru cyrus-imapd-3.0.8.orig/debian/cyrus-imapd.conf cyrus-imapd-3.0.8/debian/cyrus-imapd.conf --- cyrus-imapd-3.0.8.orig/debian/cyrus-imapd.conf 1970-01-01 01:00:00.0 +0100 +++ cyrus-imapd-3.0.8/debian/cyrus-imapd.conf 2019-02-13 16:25:55.871054843 +0100 @@ -0,0 +1,3 @@ +#Type Path Mode UID GID Age Argument +d /run/cyrus0755 cyrus mail - - +d /run/cyrus/socket 0750 cyrus mail - - diff -Nru cyrus-imapd-3.0.8.orig/debian/rules cyrus-imapd-3.0.8/debian/rules --- cyrus-imapd-3.0.8.orig/debian/rules 2019-02-08 15:43:38.0 +0100 +++ cyrus-imapd-3.0.8/debian/rules 2019-02-13 16:56:03.076879303 +0100 @@ -167,6 +167,10 @@ install -m 644 debian/logcheck.ignore $(TMPPKG)/etc/logcheck/ignore.d.server/cyrus-imapd install -m 644 debian/logcheck.violations.ignore $(TMPPKG)/etc/logcheck/violations.ignore.d/cyrus-imapd + # and tmpfile.d file + install -d -m 755 $(TMPPKG)/usr/lib/tmpfiles.d/ + install -m 644 debian/cyrus-imapd.conf $(TMPPKG)/usr/lib/tmpfiles.d/cyrus-imapd.conf + # And other upgrade helpers install -m 644 debian/cyrus-db-types.txt debian/cyrus-hardwired-config.txt \ $(TMPPKG)/usr/lib/cyrus
Bug#896596: poppler-glib always returns 0 length for PopplerInputStream
Control: tags -1 + patch
On Sat, 28 Apr 2018 at 20:59:16 +0900, d...@debian.org wrote:
> original bug report: https://bugs.debian.org/896596
> previous forwarded: https://github.com/ruby-gnome2/ruby-gnome2/issues/1159
>
> below comments and patch by Kouhei Sutou .
>
> > Poppler adds getLength() check at
> > https://cgit.freedesktop.org/poppler/poppler/commit/?id=a59f61641fcb36859b625749afb4561557e419f6
> > for https://bugs.freedesktop.org/show_bug.cgi?id=103552 .
> > But PopplerInputStream created by poppler-glib always returns 0 for
> > getLength():
> > https://cgit.freedesktop.org/poppler/poppler/tree/glib/poppler-document.cc#n301
Thanks for this diagnosis. It seems correct.
> > Ah, we can just use the length passed by argument:
> -str = new PopplerInputStream(stream, cancellable, 0, gFalse, 0,
> Object(objNull));
> +str = new PopplerInputStream(stream, cancellable, 0, gFalse, length,
> Object(objNull));
That doesn't actually work, because the function is documented to accept
-1 as a length (meaning "find the length automatically").
> > We'll be able to compute length by g_seekable_seek(0, G_SEEK_END) and
> > g_seekable_tell().
That's what I've done in the case where the caller used -1. The function
already requires that the stream is seekable, so it seems safe to assume
that this works.
Proposed patches attached. I've included a fairly minimal reproducer for
the bug, as a patch to the existing autopkgtest.
Also available as a merge request, here:
https://salsa.debian.org/freedesktop-team/poppler/merge_requests/1
Patch proposed upstream here:
https://gitlab.freedesktop.org/poppler/poppler/merge_requests/189
smcv
>From 739c81306bf0d58c857d6d664f63eaaa8d4c7317 Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Thu, 14 Feb 2019 09:45:52 +
Subject: [PATCH 1/3] Add patch to fix poppler_document_new_from_stream()
regression
Closes: #896596
---
...ate-PopplerInputStream-with-length-0.patch | 36 +++
debian/patches/series | 1 +
2 files changed, 37 insertions(+)
create mode 100644 debian/patches/glib-Don-t-create-PopplerInputStream-with-length-0.patch
diff --git a/debian/patches/glib-Don-t-create-PopplerInputStream-with-length-0.patch b/debian/patches/glib-Don-t-create-PopplerInputStream-with-length-0.patch
new file mode 100644
index 000..c59de03
--- /dev/null
+++ b/debian/patches/glib-Don-t-create-PopplerInputStream-with-length-0.patch
@@ -0,0 +1,36 @@
+From: Simon McVittie
+Date: Thu, 14 Feb 2019 09:43:32 +
+Subject: glib: Don't create PopplerInputStream with length 0
+
+Since commit a59f6164, PopplerInputStream requires a nonzero length.
+
+Loosely based on an earlier patch by Kouhei Sutou. This version adds
+support for length == -1, which is documented to work.
+
+Bug: https://gitlab.freedesktop.org/poppler/poppler/issues/414
+Bug-Debian: https://bugs.debian.org/896596
+Forwarded: https://gitlab.freedesktop.org/poppler/poppler/merge_requests/189
+---
+ glib/poppler-document.cc | 9 -
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/glib/poppler-document.cc b/glib/poppler-document.cc
+index ed37da4c..e04c8b42 100644
+--- a/glib/poppler-document.cc
b/glib/poppler-document.cc
+@@ -309,7 +309,14 @@ poppler_document_new_from_stream (GInputStream *stream,
+ }
+
+ if (stream_is_memory_buffer_or_local_file(stream)) {
+-str = new PopplerInputStream(stream, cancellable, 0, false, 0, Object(objNull));
++if (length == (goffset)-1) {
++ if (!g_seekable_seek(G_SEEKABLE(stream), 0, G_SEEK_END, cancellable, error)) {
++g_prefix_error(error, "Unable to determine length of stream: ");
++return nullptr;
++ }
++ length = g_seekable_tell(G_SEEKABLE(stream));
++}
++str = new PopplerInputStream(stream, cancellable, 0, false, length, Object(objNull));
+ } else {
+ CachedFile *cachedFile = new CachedFile(new PopplerCachedFileLoader(stream, cancellable, length), new GooString());
+ str = new CachedFileStream(cachedFile, 0, false, cachedFile->getLength(), Object(objNull));
diff --git a/debian/patches/series b/debian/patches/series
index d3a4373..6fed9f7 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
+glib-Don-t-create-PopplerInputStream-with-length-0.patch
#qt-visibility.diff
--
2.20.1
>From ebfd76c4664b43ba19185d2109532395724c7ff9 Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Thu, 14 Feb 2019 09:35:58 +
Subject: [PATCH 2/3] d/tests/glib: Add a test for #896596
---
debian/tests/glib| 2 ++
debian/tests/test-glib.c | 45
2 files changed, 47 insertions(+)
diff --git a/debian/tests/glib b/debian/tests/glib
index 7ad9ce4..5113160 100755
--- a/debian/tests/glib
+++ b/debian/tests/glib
@@ -5,3 +5,5 @@ SRCDIR=$(dirname $(realpath $0))
cd $ADTTMP
gcc -Wall -Werror -std=c99 -o poppler-glib-test $SRCDIR/test-glib.c `pkg-config --cflags --libs poppler-glib`
./poppler-glib
Bug#921299: It is not caffe that is broken
Control: tags -1 moreinfo
Control: reassign -1 doxygen
Control: retitle -1 "Doxygen breaks caffe"
Hi,
I've build caffe with latest doxygen and can not confirm the result you
wrote. The Build-Depends: doxygen-latex ensures that the style file
`listofitems.sty' is available. I rather get a different error:
...
[40] [41]
! Improper \prevdepth.
\tabu@verticalspacing ...tempdimc \the \prevdepth
\@tempdima \dimexpr \ht \t...
l.136 \end{DoxyParams}
?
! Emergency stop.
\tabu@verticalspacing ...tempdimc \the \prevdepth
\@tempdima \dimexpr \ht \t...
l.136 \end{DoxyParams}
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on refman.log.
make[2]: *** [Makefile:8: refman.pdf] Error 1
So yes, caffe is broken by doxygen but as far as I can see this is since
doxygen is breaking *lots* of other packages and it is always in the
same manner. Thus I'm reassigning this bug to doxygen.
Kind regards
Andreas.
--
http://fam-tille.de
Bug#908815: [libdmtx0a] Structs in dmtx.h have changed without new ABI number
On Fri, 14 Sep 2018 at 12:24:52 +0200, Sven Schmidt wrote: > In header file dmtx.h the structs and enumeration in version 0.7.5 have > changed to insert a new varible "fnc1" representing undefinded state. > > When loading older DMTX binary linked against new libdmtx.so the program > will crash with SIGSEGV. Same happens when loading newly compiled binary > with DMTX library version < 0.7.5. > > Both versions 0.7.4 and 0.7.5 are using the same ABI number for > their library version: libdmtx.so -> libdmtx.so.0.0.0 > > I think it is a good idea to increase ABI number of DMTX version 0.7.5 > to prevent loading wrong library version of libdmtx.so. Has there been any progress on resolving this for the buster release? If the SONAME is not increased upstream (which doesn't seem likely to happen soon), then the ABI break should be worked around in Debian by renaming libdmtx0a to libdmtx0b with Conflicts: libdmtx0a, similar to what was done for the transition from libdmtx0 to libdmtx0a. After doing this, the release team will need to trigger rebuilds for everything that depends on libdmtx0a. Thanks, smcv
Bug#922190: Fwd: Bug#922190: netbeans: Illegal reflective access by org.netbeans.core.windows.view.ui.MainWindow
Hi Gustavo, Am 13.02.19 um 23:23 schrieb Gustavo Castro: [...] > java.lang.SecurityException: sealing violation > at org.netbeans.JarClassLoader.doLoadClass(Unknown Source) > at org.netbeans.ProxyClassLoader.selfLoadClass(Unknown Source) > at org.netbeans.ProxyClassLoader.loadClass(Unknown Source) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:291) > at org.netbeans.modules.java.source.NoJavacHelper.hasNbJavac(Unknown [...] I have reported this one as Debian bug #920707 already. https://bugs.debian.org/920707 I really would like to fix that. There is another issue with Git support. Even when I install the Git plugin via the plugin store, it doesn't work. All those issues have to do with OSGi metadata but I have not found a fix yet. signature.asc Description: OpenPGP digital signature
Bug#922291: RM: python-social-auth -- ROM; superseded by social-auth-core et al
Package: ftp.debian.org python-social-auth is superseded by social-auth-core and social-auth-app-django. Please remove from unstable (and buster). Thanks.
Bug#922293: libxcomp3 must use -lpthread or -pthread (undefined symbol: pthread_key_create)
Package: libxcomp3 Version: 2:3.5.99.18-1 Severity: normal Dear Debian Remote Maintainers, quoting https://lists.debian.org/debian-backports/2019/02/msg00017.html: * Yuriy M. Kaminskiy [20190214 09:22]: > On 14.02.2019 10:53, Thomas Arendsen Hein wrote: > > I just installed x2goserver from stretch-backports and x2goclient > > from stretch on the same machine. Now x2goclient no longer works > > correctly due to the following error in nxproxy: > > > > $ nxproxy > > /usr/lib/nx/bin/nxproxy: symbol lookup error: > > /usr/lib/x86_64-linux-gnu/libXcomp.so.3: undefined symbol: > > pthread_key_create > > > > > > /usr/lib/x86_64-linux-gnu/libXcomp.so.3 is contained in libxcomp3 > > This sounds more like bug in libxcomp3 (if it uses symbols from libpthread, > it must link > to -lpthread [or -pthread]; newer nxproxy likely links to libpthread itself, > which hides > this bug; still, this must be fixed in libxcomp3); fwiw, dh_shlibdeps even > complained about this: > > === > https://buildd.debian.org/status/fetch.php?pkg=nx-libs&arch=amd64&ver=2%3A3.5.99.18-1&stamp=1548946175&raw=0 > ... > dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info > ... > dpkg-shlibdeps: warning: symbol pthread_setspecific used by > debian/libxcomp3/usr/lib/x86_64-linux-gnu/libXcomp.so.3.5.99 found in none of > the libraries > ... > === cut === > > (this bug seems still present in buster/sid, so I'd suggest filling bug > against nx-libs). I will add a pointer to the Debian bug report on the bpo list. Regards, Thomas -- Thomas Arendsen Hein - OpenPGP key: 0x5BB3F5195816791A https://blogs.intevation.de/thomas/ - https://intevation.de/~thomas/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998 Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Bug#922292: ITP: social-app-webpy -- Web.py component of the python-social-auth ecosystem
Package: wnpp Severity: wishlist Owner: "W. Martin Borgert" * Package name: social-app-webpy Version : 1.0.0 Upstream Author : Matías Aguirre * URL : https://pypi.python.org/pypi/social-auth-app-django * License : BSD-3 Programming Lang: Python Description : Web.py component of the python-social-auth ecosystem This is the web.py component of the python-social-auth ecosystem, it implements the needed functionality to integrate social-auth-core in a web.py based project.
Bug#834414: The bug is still there in APT 1.4.9 (stretch)
Dear Maintainer, My laptop is also connected to a WiFi, the connection of which is established after apt-daily. Although it seems to me that unattended-upgrades are invoked after the connection, updating the package list (apt-get update) is run before the connection: # journalctl -u apt-daily.service -- Reboot -- févr. 14 10:39:40 localhost.localdomain systemd[1]: Starting Daily apt download activities... févr. 14 10:39:43 localhost.localdomain apt.systemd.daily[1023]: verbose level 2 févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Lecture des listes de paquets… févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Construction de l'arbre des dépendances… févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Lecture des informations d'état… févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: check_stamp: interval=86400, now=1550098800, stamp=1550012400, delta=86 févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Err:1 http://deb.debian.org/debian stretch InRelease févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Ne parvient pas à résoudre « deb.debian.org » févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Err:2 http://security.debian.org/debian-security stretch/updates InRele févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Ne parvient pas à résoudre « security.debian.org » févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Err:3 http://deb.debian.org/debian stretch-updates InRelease févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Ne parvient pas à résoudre « deb.debian.org » févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Err:4 http://deb.debian.org/debian stretch-proposed-updates InRelease févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Ne parvient pas à résoudre « deb.debian.org » févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Err:5 http://deb.debian.org/debian stretch-backports InRelease févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Ne parvient pas à résoudre « deb.debian.org » févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Err:6 https://download.docker.com/linux/debian stretch InRelease févr. 14 10:39:45 localhost.localdomain apt.systemd.daily[1023]: Could not resolve host: download.docker.com févr. 14 10:39:50 localhost.localdomain apt.systemd.daily[1023]: Lecture des listes de paquets… févr. 14 10:39:50 localhost.localdomain apt.systemd.daily[1023]: W: Impossible de récupérer https://download.docker.com/linux/debian/dis févr. 14 10:39:50 localhost.localdomain apt.systemd.daily[1023]: W: Impossible de récupérer http://deb.debian.org/debian/dists/stretch/I févr. 14 10:39:50 localhost.localdomain apt.systemd.daily[1023]: W: Impossible de récupérer http://deb.debian.org/debian/dists/stretch-u févr. 14 10:39:50 localhost.localdomain apt.systemd.daily[1023]: W: Impossible de récupérer http://deb.debian.org/debian/dists/stretch-p févr. 14 10:39:50 localhost.localdomain apt.systemd.daily[1023]: W: Impossible de récupérer http://deb.debian.org/debian/dists/stretch-b févr. 14 10:39:50 localhost.localdomain apt.systemd.daily[1023]: W: Impossible de récupérer http://security.debian.org/debian-security/d févr. 14 10:39:50 localhost.localdomain apt.systemd.daily[1023]: W: Le téléchargement de quelques fichiers d'index a échoué, ils ont été févr. 14 10:39:50 localhost.localdomain apt.systemd.daily[1023]: download updated metadata (success). févr. 14 10:39:50 localhost.localdomain apt.systemd.daily[1023]: send dbus signal (success) févr. 14 10:39:50 localhost.localdomain apt.systemd.daily[1023]: check_stamp: interval=0 févr. 14 10:39:50 localhost.localdomain apt.systemd.daily[1023]: download upgradable (not run) févr. 14 10:39:54 localhost.localdomain apt.systemd.daily[1023]: unattended-upgrade -d (not run) févr. 14 10:39:54 localhost.localdomain systemd[1]: Started Daily apt download activities. I hope that this will be fixed in the next release. Best wishes, Frank
Bug#922294: ITP: social-examples -- collection of examples implementations of the python-social-auth ecosystem
Package: wnpp Severity: wishlist Owner: "W. Martin Borgert" * Package name: social-examples Version : n/a Upstream Author : Matías Aguirre * URL : https://github.com/python-social-auth/social-examples * License : BSD-3 Programming Lang: Python Description : collection of examples implementations of the python-social-auth ecosystem Python Social Auth is an easy to setup social authentication/ registration mechanism with support for several frameworks and auth providers. This is a collection of examples implementations of the python-social-auth ecosystem functionality.
Bug#922292: ITP: social-app-webpy -- Web.py component of the python-social-auth ecosystem
Correct homepage: https://github.com/python-social-auth/social-app-webpy
Bug#896468: [Pkg-javascript-devel] Bug#896468: libjs-chartjs: Please upload newer versions
Quoting Pirate Praveen (2019-02-14 11:04:03) > On Sat, 21 Apr 2018 12:24:49 +0100 Federico Ceratto > wrote: > > The package has not been updated since 2015. Can you please upload the > > latest release? (Currently 2.7.2) > > gitlab was locked to 1.0.2, but they have also moved to 2.7.2 so I will > update soon. Can someone check if python3-ontospy is also compatible? Onlyspy should be fine. Thanks! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#922295: libqtpas: should go away and binaries should be build from src:lazarus
Source: libqtpas Version: 2.6~beta-5 Severity: normal Control: clone -1 -2 Control: reassign -2 src:lazarus Control: block -1 by -2 Hi all, This is a reminder to myself that since lazarus ships the source of libqtpas, we should build the binaries from the lazarus source package instead of having it in a separate source. It's too late in the freeze to start doing this, so it will have to wait until after we release buster. Paul signature.asc Description: OpenPGP digital signature
Bug#877202: Bug #877202 in pyxdg marked as pending
On Mon, 30 Apr 2018 at 02:35:03 +, a...@debian.org wrote: > New upstream release. > - Add support for Scale and ScaledDirectories keys (Closes: #877202). > - DesktopEntry: New method findTryExec() (Closes: #618514). > * Drop patches applied upstream: fix-DesktopEntry-docstring.patch > prefer-first-glob-for-finding-mimetype.patch, and > fix-insecure-use-of-tmp.patch. Is there anything that makes this version unsuitable for buster? If the only reason it hasn't been uploaded yet is lack of time, I can look into doing a team upload for it. There seem to be significant changes to the menu code, so it should probably be tested with mate-menu or ukui-menu before uploading. Alternatively, uploading a version closely resembling the one in Ubuntu would be a low-risk option with a minimal fix for this bug. Thanks, smcv
Bug#922297: rxvt-unicode: *blink* *blink* *blink*
Package: rxvt-unicode Version: 9.22-5 Severity: grave Justification: makes my head hurt The terminal screen blinks all the time. -- System Information: Architecture: i386 Versions of packages rxvt-unicode depends on: ii libc6 2.28-7 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.2.0-20 ii libgdk-pixbuf2.0-02.38.0+dfsg-7 ii libglib2.0-0 2.58.3-1 ii libperl5.28 5.28.1-4 ii libstartup-notification0 0.12-6 ii libx11-6 2:1.6.7-1 ii libxft2 2.3.2-2 ii libxrender1 1:0.9.10-1 ii base-passwd 3.5.46 ii ncurses-base 6.1+20181013-2 ii ncurses-term 6.1+20181013-2 -- Jakub Wilk
Bug#922298: rxvt-unicode: invisible selection
Package: rxvt-unicode Version: 9.22-5 If you select text in the terminal, there's no visual indication what is selected. (Maybe related to #922289?) -- System Information: Architecture: i386 Versions of packages rxvt-unicode depends on: ii libc6 2.28-7 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.2.0-20 ii libgdk-pixbuf2.0-02.38.0+dfsg-7 ii libglib2.0-0 2.58.3-1 ii libperl5.28 5.28.1-4 ii libstartup-notification0 0.12-6 ii libx11-6 2:1.6.7-1 ii libxft2 2.3.2-2 ii libxrender1 1:0.9.10-1 ii base-passwd 3.5.46 ii ncurses-base 6.1+20181013-2 ii ncurses-term 6.1+20181013-2 -- Jakub Wilk
Bug#889651: ruby-debian: Still outstanding?
Package: ruby-debian Version: 0.3.9+b8 Followup-For: Bug #889651 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ruby-debian depends on: ii libapt-pkg5.0 1.8.0~rc2 ii libc6 2.28-6 ii libgcc11:8.2.0-16 ii libgmp10 2:6.1.2+dfsg-4 ii libruby2.5 2.5.3-3 ii libstdc++6 8.2.0-16 ii ruby 1:2.5.1 ruby-debian recommends no packages. ruby-debian suggests no packages. -- no debconf information This problem has been around for a fair time now. Any chance of a resolution?
Bug#922121: libnfs: autopkgtest fails on several Ubuntu architectures
Control: forwarded -1 https://github.com/sahlberg/libnfs/issues/285 Control: tags -1 confirmed Hi Jeremy, On Tue, Feb 12, 2019, 18:12 Jeremy Bicha Source: libnfs > Version: 3.0.0-2 > > Thanks for your libnfs update this week. The autopkgtest now passes on > Ubuntu's amd64 and s390x. > > It still fails on arm64, i386 and ppc64el. > > The valgrind test fails on arm64 and ppc64el. Maybe we should only run > the valgrind test on whitelisted architectures? > IMO those tests are valid and are not prohibitively expensive. Valgrind also have to be working on those architectures thus I'd like to keep the tests enabled. > i386 fails because -Wall -Werror is set. In my experience, that can > break easily. > Yes, I reported the issue upstream, let's see if it gets fixed there. Cheers, Balint > https://autopkgtest.ubuntu.com/packages/libn/libnfs > > Thanks, > Jeremy Bicha >
Bug#922290: cyrus-imapd: /usr/lib/tmpfiles.d/cyrus-imapd.conf is missing
This is already fixed and will be available with next version. Commit: https://salsa.debian.org/debian/cyrus-imapd/commit/161ba34038bea1f917870b3e6c5fbf6c8102fe35 On 2/14/19 11:13 AM, Jean Charles Delépine wrote: Package: cyrus-imapd Version: 3.0.8-1 Severity: important Tags: patch Without this file cyrus doesn't start : cyrus/master[13622]: unable to bind to lmtpunix/unix socket: No such file or directory cyrus/master[13622]: unable to create lmtpunix listener socket: No such file or directory cyrus/master[13622]: unable to bind to notify/unix socket: No such file or directory cyrus/master[13622]: unable to create notify listener socket: No such file or directory -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/12 CPU cores) 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cyrus-imapd depends on: ii cyrus-common 3.0.8-1 ii dpkg 1.19.4 ii libc6 2.28-7 ii libcom-err2 1.44.5-1 ii libsasl2-22.1.27+dfsg-1 ii libssl1.1 1.1.1a-1 ii libwrap0 7.6.q-27 ii zlib1g1:1.2.11.dfsg-1 cyrus-imapd recommends no packages. cyrus-imapd suggests no packages. -- no debconf information
Bug#922299: rxvt-unicode: laggy cursor
Package: rxvt-unicode Version: 9.22-5 When the cursor moves, it's briefly visible in both old and new locations. That's super annoying. To reproduce, set "Rxvt.cursorUnderline: yes" (because otherwise the cursor won't appear at all, as reported in #922289), run your shell and hold space for a while. The cursor will appear as a long horizontal line. -- System Information: Architecture: i386 Versions of packages rxvt-unicode depends on: ii libc6 2.28-7 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.2.0-20 ii libgdk-pixbuf2.0-02.38.0+dfsg-7 ii libglib2.0-0 2.58.3-1 ii libperl5.28 5.28.1-4 ii libstartup-notification0 0.12-6 ii libx11-6 2:1.6.7-1 ii libxft2 2.3.2-2 ii libxrender1 1:0.9.10-1 ii base-passwd 3.5.46 ii ncurses-base 6.1+20181013-2 ii ncurses-term 6.1+20181013-2 -- Jakub Wilk
Bug#922119: dup
On Thu, 14 Feb 2019 07:41:32 + Bart Martens wrote: > see 921925 > > Hi Bart, It's not a duplicate, this version corrects the failing test in debian/tests/control Thanks, -- Olivier
Bug#922300: unblock: chef/13.8.7-3, ohai/13.8.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hello, Please unblock package chef Hi, The ci.debian.net nodes are managed with chef, and during the weekend I realized that it was not in testing. There was an RC bug against chef (FTBFS, 3 tests broken by an update to the test framework, package just worked nevertheless) and ruby-cheffish (broken by openssl 1.1.1). I fixed both, and they were ACCEPTED in unstable Sunday morning within less than one hour of each other (ruby-cheffish at 11:53:21 + and chef at 12:34:15 +) https://tracker.debian.org/news/1029431/accepted-chef-1387-3-source-into-unstable/ https://tracker.debian.org/news/1029425/accepted-ruby-cheffish-1310-2-source-into-unstable/ ruby-cheffish migrated to testing before the freeze, but chef didn't even though they have a pathological circular build dependency. So ruby-cheffish can't be built in buster at the moment: The following packages have unmet dependencies: builddeps:ruby-cheffish : Depends: chef but it is not installable E: Unable to correct problems, you have held broken packages.' Maybe this a bug in britney; it should have migrated either both or none of them, but not one without the other. I would very much prefer to have this fixed by having chef migrate, since 1) that would make my life maintaining ci.debian.net much easier and 2) it will save a lot of Debian users the pain of not having chef in stable. OTOH I realize chef that the fixes came in late, so if it's unacceptable to have it in buster, ruby-cheffish needs to be removed. So I would ask you to unblock chef/13.8.7-3 unstable ohai/13.8.0-1 (ohai also has a circular dependency with chef and was removed from testing because of chef) OR remove ruby-cheffish/13.1.0-2 -- 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 signature.asc Description: PGP signature
Bug#921987: mysqld-akonadi: Could not open required defaults file
I removed mysql from my computer and installed akonadi-backend-mysql; that installed mariadb and mariadb started without problems and I am now using the mysql-backend. Reinhard
Bug#922303: RM: ruby-fog-vsphere -- ROM; not required, no reverse dependencies
Package: ftp.debian.org Severity: normal This was originally packaged as a dependency of ruby-fog, which is now removed. No other reverse dependencies.
Bug#922301: RM: ruby-fog-dynect -- ROM; not required, no reverse dependencies
Package: ftp.debian.org Severity: normal This was packaged as a dependency of ruby-fog which is now removed. There are no other reverse dependencies.
Bug#922302: RM: ruby-fog-xenserver -- ROM; not required, no reverse dependencies
Package: ftp.debian.org Severity: normal This was originally packaged as a dependency of ruby-fog, which is now removed. No other reverse dependencies.
Bug#890780: release-notes: document that s390x now require at least a z196 CPU
On Sun, 18 Feb 2018 21:52:07 +0100 Aurelien Jarno wrote: > Package: release-notes > Severity: normal > > The s390x baseline ISA has been raised to z196 in buster [1]. This > should be mentioned in the release notes. > > I'll try to work on a patch in the next days. I am filling this bug to > make sure I do not forget. > > [1] https://lists.debian.org/debian-s390/2018/02/msg8.html > > Hi Aurelien, Did you get around to look at a patch / wording for this? Note that we have moved release-notes to salsa.d.o[1] and accept MR there assuming it is easier for you. :) Thanks, ~Niels [1]: https://salsa.debian.org/ddp-team/release-notes CI builds show the generated HTML from master on: https://ddp-team.pages.debian.net/release-notes/amd64/release-notes/
Bug#922304: fswatch: manpage references "EVENT TYPES"" section which does not exist
Package: fswatch Version: 1.14.0+repack-2 Severity: minor The fswatch(7) manpage states, in the DESCRIPTION section, - A space-separated list of event types (see EVENT TYPES ). However, there is no EVENT TYPES section.
Bug#810615: postgresql-common: confirmation voor 10>11
Package: postgresql-common Version: 199.pgdg90+1 Followup-For: Bug #810615 Hallo, i suspect the postgresql.auto.conf is not read at all by pg_upgradecluster howto reproduce 1. create a new cluster version 10 2. change a setting like the port or even a settings that would give an error if not correct, for example ssl=on in the standard conf with a custom non default certificate via alter system 3. upgrade the cluster 3.1 port will not be applied 3.2 will not start unless the postgresql.auto.conf is copied over manually (in case of the custom certificate) hth, Wim -- System Information: Debian Release: 9.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages postgresql-common depends on: ii adduser 3.115 ii debconf [debconf-2.0] 1.5.61 ii init-system-helpers 1.48 ii lsb-base 9.20161125 ii postgresql-client-common 199.pgdg90+1 ii procps2:3.3.12-3+deb9u1 ii ssl-cert 1.0.39 ii ucf 3.0036 Versions of packages postgresql-common recommends: ii e2fsprogs 1.43.4-2 ii logrotate 3.11.0-0.1 Versions of packages postgresql-common suggests: pn libjson-perl -- debconf information: postgresql-common/obsolete-major: postgresql-common/catversion-bump: postgresql-common/ssl: true
Bug#922305: latexindent: please add dependency with liblog-log4perl-perl
Package: texlive-extra-utils Version: 2018.20190131-1 Severity: normal Dear Maintainer, When I use latexindent command in texlive-extra-utils, the command said: yabuki@Odayla:~$ latexindent Can't locate Log/Log4perl.pm in @INC (you may need to install the Log::Log4perl module) (@INC contains: /usr/share/texlive/texmf-dist/scripts/latexindent /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/texlive/texmf-dist/scripts/latexindent/LatexIndent/LogFile.pm line 22. BEGIN failed--compilation aborted at /usr/share/texlive/texmf-dist/scripts/latexindent/LatexIndent/LogFile.pm line 22. Compilation failed in require at /usr/share/texlive/texmf-dist/scripts/latexindent/LatexIndent/Document.pm line 25. BEGIN failed--compilation aborted at /usr/share/texlive/texmf-dist/scripts/latexindent/LatexIndent/Document.pm line 25. Compilation failed in require at /usr/bin/latexindent line 30. BEGIN failed--compilation aborted at /usr/bin/latexindent line 30. I installed liblog-log4perl-perl, latexindent works well. That is why, I'd like to add dpendency with liblog-log4perl-perl. Thank you. ## other files ## List of ls-R files -rw-rw-r-- 1 root staff 80 Jan 14 14:37 /usr/local/share/texmf/ls-R -rw-r--r-- 1 root root 1415 Feb 14 20:08 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 Sep 2 21:32 /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 Jan 31 12:53 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Jan 31 12:53 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files -rw-r--r-- 1 root root 475 Sep 4 19:07 /etc/texmf/web2c/texmf.cnf lrwxrwxrwx 1 root root 33 Jan 31 12:53 /usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN -rw-r--r-- 1 yabuki yabuki 25 Jan 18 14:29 /home/yabuki/.texlive2018/texmf-config/web2c/updmap.cfg -rw-r--r-- 1 root root 3377 Feb 14 20:07 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Aug 17 2017 mktex.cnf -rw-r--r-- 1 root root 475 Sep 4 19:07 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf -- 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) Kernel taint flags: TAINT_WARN Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages texlive-extra-utils depends on: ii libunicode-linebreak-perl 0.0.20170401-1+b1 ii python 2.7.15-4 ii tex-common 6.10 ii texlive-base 2018.20190131-1 ii texlive-binaries 2018.20181218.49446-1 ii texlive-latex-base 2018.20190131-1 Versions of packages texlive-extra-utils recommends: ii ghostscript9.26a~dfsg-2 ii libfile-homedir-perl 1.004-1 ii libyaml-tiny-perl 1.73-1 ii ruby 1:2.5.1 ii texlive-latex-recommended 2018.20190131-1 Versions of packages texlive-extra-utils suggests: pn chktex pn dvidvi ii dvipng 1.15-1.1 pn fragmaster pn lacheck pn latexdiff ii latexmk 1:4.61-0.1 pn purifyeps pn xindy Versions of packages tex-common depends on: ii dpkg 1.19.4 ii ucf 3.0038+nmu1 Versions of packages tex-common suggests: ii debhelper 12.1 Versions of packages texlive-extra-utils is related to: ii tex-common6.10 ii texlive-binaries 2018.20181218.49446-1 -- no debconf information
Bug#922306: linux: btrfs corruption (compressed data + hole data)
Source: linux Version: 4.19.20-1 Severity: critical Tags: upstream patch Justification: causes serious data loss Hi. Apparently there was a longer existing data corruption bug in btrfs[0], AFAIU it happened when compression was used together with holes in data and there was *no* recognition by checksumming. Seems some movement got into this the last days and a patch[1] may have been found fixing the issue. Due to potential silent data corruptpion it makes perhaps sense to cherry pick that fix (maybe waiting for confirmation from upstream whether it's the final one) instead of waiting for it being released in some upcoming stable release? Cheers, Chris. [0] https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg85407.html [1] https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg85492.html -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#921382: kineticstools: autopkgtest needs update for new version of h5py
Hi Paul,
On Thu, Feb 14, 2019 at 10:17:16AM +0100, Paul Gevers wrote:
> >> If you really don't know how to fix the issue, I guess you could reduce
> >> the log-level in your test cases.
> >
> > OK, I tried
>
> > + find test/cram -type f -name "*.t" -exec sed -i
> > 's/--log-level=WARNING/--log-level=DEBUG/' \{\} \;
>
> I meant the other direction. I don't know if it's the name, but
> something like "--log-level=ERROR"
Ahhh, all my thinking was concentrated on getting rid of the *reason*
for the warning (thus more debug info) but your idea was rather to get
rid of the warning itself, right?
Well, I've checked that the data result will not be different between
the python-h5py versions and suppressed the warnings by redirecting
stderr[1].
Build to upload this fix is running.
Thanks for your patience and your effort for autopkgtests
Andreas.
[1]
https://salsa.debian.org/med-team/kineticstools/commit/92cd03b82d3ccc26708775e738fe2c533a101f82
--
http://fam-tille.de
Bug#922284: wmaker-common: Should not set GNUSTEP_USER_ROOT; unable to build GNUstep software
Control: forwarded -1 wmaker-...@googlegroups.com We received the following bug report in Debian: On 2/14/19 2:24 AM, Yavor Doganov wrote: > Package: wmaker-common > Version: 0.95.8-3 > Severity: important > File: /usr/bin/wmaker > Control: affects -1 gnustep > > As evident from the prefix, GNUSTEP_USER_ROOT is a GNUstep variable and > Window Maker should not set it. Furthemore, it has been deprecated for > 12 years already. As of gnustep-make/2.7.0-4 the GNUstep build system > is configured in strict v2 mode which makes it impossible to compile > GNUstep software. In a terminal started from a Window Maker session: > > yavor@aneto:/tmp/gorm.app-1.2.24$ make > This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help. > Running in gnustep-make version 2 strict mode. > rm -f InterfaceBuilder; \ > ln -s GormLib InterfaceBuilder > /usr/share/GNUstep/Makefiles/config-noarch.make:121: *** GNUSTEP_USER_ROOT is > obsolete. Stop. > > It is also impossible to build gnustep-make from pristine upstream > source: > > yavor@aneto:/tmp$ wget -q > ftp://ftp.gnustep.org/pub/gnustep/core/gnustep-make-2.7.0.tar.gz > yavor@aneto:/tmp$ tar xzf gnustep-make-2.7.0.tar.gz > yavor@aneto:/tmp$ cd gnustep-make-2.7.0/ > yavor@aneto:/tmp/gnustep-make-2.7.0$ ./configure > ... > yavor@aneto:/tmp/gnustep-make-2.7.0$ make > config-noarch.make:121: *** GNUSTEP_USER_ROOT is obsolete. Stop. > > Note that the majority of GNUstep users use Window Maker as their window > manager and many of them build GNUstep software from source, mostly > because of the GNUstep Objective-C runtime which depends on Clang > (Debian packages use GCC and the GCC/GNU runtime). > > -- System Information: > Debian Release: buster/sid >APT prefers unstable-debug >APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, > 'unstable'), (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386, x32 > > Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores) > Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), > LANGUAGE=bg_BG.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > wmaker-common depends on no packages. > > wmaker-common recommends no packages. > > Versions of packages wmaker-common suggests: > ii wmaker 0.95.8-3 > > -- no debconf information We're currently using GNUSTEP_USER_ROOT so WINGs can find the user's configuration files. It seems like a straightforward fix would be to just replace this variable with our own, say WMAKER_USER_ROOT. Does this seem like a good idea? If so, I can prepare a patch. Thanks! Doug
Bug#736859: dput: Please set the default transport to use ssh-upload
Control: clone 736859 -2 Control: retitle -2 dput-ng: Please set the default transport to use ssh-upload On Wed 2019-02-13 12:15:33 -0500, micah anderson wrote: > Daniel Kahn Gillmor writes: >> So perhaps this bug report can be closed, since ssh.upload.debian.org >> does appear to be the default target for dupload today? i don't know >> when that changed. > > That may be true about dupload, but dupload is a different package, and > this was about dput. Sorry for the distraction about dupload! You're clearly right that dput is a separate package, i don't know what i was thinking. I note that dput-ng also appears to default to FTP-based upload, since /etc/dput.d/profiles/ftp-master.json has: "default_host_main": "ftp-master" (so i'm cloning this bug over there to recommend that dput-ng also default to ssh.upload.d.o) but the fact that dupload defaults to ssh.upload is promising, and suggests that it's not the end of the world for a comparable tool to use a sensible default. Could the dput or dput-ng maintainers weigh in on what is needed to make this change? --dkg signature.asc Description: PGP signature
Bug#919138: wpasupplicant: Fails to connect to some Wifi networks on version 2:2.7-3
>>> wlp5s0: WPA: IGTK keyid 1024 pn d0caa82e44b2 >>> WPA: IGTK - hexdump(len=16): [REMOVED] >>> wpa_driver_nl80211_set_key: ifindex=3 (wlp5s0) alg=4 addr=0x55e7e55d2909 >>> key_idx=1024 set_tx=0 seq_len=6 key_len=16 >> >> A key_idx=1024 looks wrong, it should be 4 or 5 for IGTK. I tend to >> think it's a fault of the AP which sends an invalid key index. >Just wondering, any updates on this? Is there any workaround I can >apply to make that work for most users? We've seen a couple of misbehaving routers when using PMF. A workaround that has proven successful is to byte swap the IGTK key index. 1024 happens to be index 4 in big endian. Not sure what Jouni thinks about working around faulty APs. Would of course be better if this was caught in certification tests but these APs are already out on the market. Anyway, I've just sent an RFC patch with the workaround to the mailing list: ?"[RFC] PMF: Allow Key ID in big endian format to workaround faulty APs" ? /Mikael?
Bug#922307: proftpd-basic aborting transfer
Package: proftpd-basic Version: 1.3.6-4 Some users (generally a distance away from the server) when attempting to upload files larger than 2mb the server closes the connection. Smaller files upload fine. Error as seen in the log (/var/log/proftpd/proftpd.log) for each attempt: notice: user testuser: aborting transfer: Interrupted system call The problem does not exist with the same configuration in version 1.3.5b-4. Added configuration items from stock. Various files in /etc/proftpd/conf.d/* containing DefaultRoot /home/UserName/Website UserName DeleteAbortedStores on AllowStoreRestart on and in proftpd.conf RequireValidShell off MasqueradeAddress insert.wan.ip.here This is on an up to date 14/02/2019 buster installation Seems to be the same problem as expressed here. https://github.com/proftpd/proftpd/issues/668#issuecomment-357406734 (https://github.com/proftpd/proftpd/issues/668#issuecomment-357406734)
Bug#919138: wpasupplicant: Fails to connect to some Wifi networks on version 2:2.7-3
>>> wlp5s0: WPA: IGTK keyid 1024 pn d0caa82e44b2 >>> WPA: IGTK - hexdump(len=16): [REMOVED] >>> wpa_driver_nl80211_set_key: ifindex=3 (wlp5s0) alg=4 addr=0x55e7e55d2909 >>> key_idx=1024 set_tx=0 seq_len=6 key_len=16 >> >> A key_idx=1024 looks wrong, it should be 4 or 5 for IGTK. I tend to >> think it's a fault of the AP which sends an invalid key index. >Just wondering, any updates on this? Is there any workaround I can >apply to make that work for most users? We've seen a couple of misbehaving routers when using PMF. A workaround that has proven successful is to byte swap the IGTK key index. 1024 happens to be index 4 in big endian. Not sure what Jouni thinks about working around faulty APs. Would of course be better if this was caught in certification tests but these APs are already out on the market. Anyway, I've just sent an RFC patch with the workaround to the mailing list: "[RFC] PMF: Allow Key ID in big endian format to workaround faulty APs" ? /Mikael
Bug#922309: php7.3: please set timezone in php.ini files to the system's timezone
Source: php7.3 Version: 7.3.2-3 Severity: normal Control: affects -1 cacti Hi, As maintainer of the Cacti package I have been asked by my upstream developers to make sure that the timezone is set. I explained to them that I can't do that in my package as the PHP configuration is off limits. If I understand the situation correctly (I am not very knowledgeable on PHP) there are multiple functions in PHP nowadays that also complain if the timezone isn't set. Instead of requiring every admin to set the timezone, couldn't the Debian package set the timezone during initial installation to the same timezone as the system has, as a default? See for more background the upstream issue where this appeared: https://github.com/Cacti/cacti/issues/2331 Paul signature.asc Description: OpenPGP digital signature
Bug#871105: Status of debian-faq
Dear FTP Masters, the package "debian-faq" has been uploaded three months ago and contains various important fixes. It's currently stuck in BYHAND. Is there any chance that we can get this package into buster? Regards, Tobias signature.asc Description: OpenPGP digital signature
Bug#922213: locales-all: Doesn't provide en_DE.UTF-8
Hi, On 2019-02-13 11:41, Charlemagne Lasse wrote: > Package: locales-all > Version: 2.28-6 > Severity: normal > X-Debbugs-CC: debian-qt-...@lists.debian.org, > debian-tex-ma...@lists.debian.org > > > > It is possible under KDE to change the locale to en_DE.UTF-8/German > for some specific parts (e.g. time) but it seems to be missing on the > system even when locales-all is installed. The en_DE locale doesn't exit in Debian, nor in upstream GNU libc. It's not going to happen, the en_DK locale exists, but it has been acknowledged that it was a mistake to create it. In that precise case, I am not even sure what en_DE means for LC_TIME. It is supposed to be the way to write the time in English in Germany? Should it be in the form day/month/year or month/day/year? 12h format or 24h format? The locale system has been defined so that you can choose the locale for a single category. That way you can choose if you want to display the time in English with the Australian or New-Zeland convention, while using a different convention for collation or monetary. > This breaks various things - here for example when I install > tex-common (via texlive package) and have LC_TIME set to en_DE.UTF-8: In general KDE should not offer to configure a locale that is not available on the system. That just creates issues like this one. In addition the list of available locales can evolve. I am therefore just tempted to reassign the bug to KDE. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#922310: unblock: ruby-jquery-ui-rails/6.0.1+dfsg-3
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Hey, Please unblock package ruby-jquery-ui-rails I am writing this on behalf of the Ruby team, requesting you to unblock ruby-jquery-ui-rails[1] by the soft freeze. The autopkgtest regression in testing was due to ruby-capybara[2], which was not in testing, which was blocked by an RC bug in puma[3]. Since they migrated on the last day before the soft freeze, there was no time to run autopkgtest for ruby-jquery-ui-rails and thus got blocked because of the same. Hence requesting you to unblock ruby-jquery-ui-rails/6.0.1+dfsg-3 [1]: https://tracker.debian.org/pkg/ruby-jquery-ui-rails [2]: https://tracker.debian.org/pkg/ruby-capybara [3]: https://tracker.debian.org/pkg/puma -- 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/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Best, Utkarsh
Bug#922311: should exercise testsuite in autopkgtest
Package: src:cl-fad Version: 20180430-2 Severity: wishlist Currently, the autopkgtest only tries to load the main cl-fad system. It should be expanded to exercise the testsuite. This first requires unit-test to be packaged. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org
Bug#922313: kopano-search: missing an end of line character in /etc/apparmor.d/usr.sbin.kopano-search
Package: kopano-search
Version: 8.7.0-1
Severity: serious
Justification: 2
Hello,
The kopano-search gives a parser error on the apparmor profile.
Setting up kopano-search (8.7.0-1) ...
AppArmor parser error for /etc/apparmor.d/usr.sbin.kopano-search in
/etc/apparmor.d/usr.sbin.kopano-search at line 39: missing an end of line
character? (entry: /etc/ssl/openssl.cnf)
Created symlink
/etc/systemd/system/multi-user.target.wants/kopano-search.service →
/lib/systemd/system/kopano-search.service.
Setting up kopano-core (8.7.0-1) ...
The solution is simple.
edit /etc/apparmor.d/usr.sbin.kopano-search
add a "," behind the line:
/etc/ssl/openssl.cnf r
Thank you for porting kopano.
Best regards,
Louis
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
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
Versions of packages kopano-search depends on:
ii catdoc 1:0.95-4.1
ii file 1:5.35-2
ii gawk 1:4.2.1+dfsg-1
ii init-system-helpers 1.56+nmu1
ii kopano-common8.7.0-1
ii lsb-base 10.2018112800
ii poppler-utils0.71.0-2
ii python3 3.7.2-1
ii python3-bsddb3 6.2.6-3
ii python3-dateutil 2.7.3-3
ii python3-kopano 8.7.0-1
ii python3-magic2:0.4.15-2
ii python3-xapian 1.4.9-1
ii unzip6.0-21
ii w3m 0.5.3-37
ii xsltproc 1.1.32-2
kopano-search recommends no packages.
kopano-search suggests no packages.
-- Configuration Files:
/etc/apparmor.d/usr.sbin.kopano-search changed:
/usr/sbin/kopano-search flags=(attach_disconnected) {
#include
#include
#include
#include
capability chown,
capability dac_override,
capability dac_read_search,
capability setgid,
capability setuid,
@{PROC}/@{pid}/cmdline r,
@{PROC}/@{pid}/fd r,
@{PROC}/@{pid}/mounts r,
@{PROC}/@{pid}/status r,
@{PROC}/@{pid}/task/@{tid}/comm rw,
deny /usr/lib/python{3,2.?}/dist-packages/kopano_search/*.pyc w,
/bin/dash Pix,
/bin/rm Pix,
# FIXME: it would be nice if search would use search- like pa
/dev/shm/* rwl,
/etc/gss/mech.d/ r,
/etc/gss/mech.d/*.conf r,
/etc/kopano/search.cfg r,
/etc/magic r,
/etc/mapi/ r,
/etc/mapi/kopano.inf r,
/etc/mapi/zcontacts.inf r,
/etc/ssl/openssl.cnf r,
/lib/@{multiarch}/ld-*.so mr,
/sbin/ldconfig Pix,
/run/kopano/search.pid rw,
/run/kopano/search.pid.lock lrw,
/run/kopano/search.sock rw,
/run/kopano/*.*-* rw,
/usr/bin/python{2,3}.? ix,
/usr/sbin/kopano-search r,
/var/lib/kopano/search/** rwlk,
/var/log/kopano/search.log rw,
}
-- no debconf information
Bug#922312: reportbug: No explanation in help nor manpage
Package: reportbug Version: 7.5.2 Severity: normal Tags: a11y Dear Maintainer, * What led up to the situation? Using report bug * What exactly did you do (or not do) that was effective (or ineffective)? I got 1-4/4) Is the bug you found listed above [y|N|b|m|r|q|s|f|e|?]? but nowhere could find an explanation for the letters: [y|N|b|m|r|q|s|f|e|?]? some are obvious to me but not all. * What was the outcome of this action? * What outcome did you expect instead? Find in the help or manpage what these letters mean. -- Package-specific info: ** Environment settings: EDITOR="vi" INTERFACE="text" ** /home/wim/.reportbugrc: reportbug_version "7.5.2" mode standard ui text realname "MMnbJEE" email "mmnbjee.p3ze...@dse.nl" smtphost "smtp.xs4all.nl" smtptls -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/2 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 reportbug depends on: ii apt1.8.0~rc2 ii python33.7.2-1 ii python3-reportbug 7.5.2 ii sensible-utils 0.0.12 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils pn debsums pn dlocate pn emacs24-bin-common | emacs25-bin-common ii exim4-daemon-light [mail-transport-agent] 4.92~RC5-2 ii file 1:5.35-2 ii gnupg 2.2.12-1 pn python3-urwid pn reportbug-gtk ii xdg-utils 1.1.3-1 Versions of packages python3-reportbug depends on: ii apt1.8.0~rc2 ii file 1:5.35-2 ii python33.7.2-1 ii python3-apt1.8.3 ii python3-debian 0.1.34 ii python3-debianbts 2.8.2 ii python3-requests 2.20.0-2 python3-reportbug suggests no packages. -- no debconf information
Bug#922314: python3-x2gobroker: insecure default SSH host key policy
Package: python3-x2gobroker Version: 0.0.4.0-3 The x2gobroker/agent.py source file contains the following lines in the _call_remote_broker_agent function: elif 'host_key_policy' not in remote_agent: remote_agent['host_key_policy'] = paramiko.WarningPolicy() This overrides the paramiko SSH library default which is RejectPolicy. I believe that should be the default in python3-x2gobroker as well, because it's the expected default in SSH clients and libraries, and because the (indirect) caller in broker/base_broker.py does not set a policy.
Bug#922279: debconf: Can't select long choices in dialog (whiptail) multiselect
On Wed, Feb 13, 2019 at 10:51:17PM -0700, Kevin Locke wrote: > Note that systemd does not appear in the output regardless of whether or > not the option is selected. The problem is that the ellipsized choice > text can't be mapped back to the choice value. I have attached a patch > which adds this mapping. It also handles the case that ellipsized > options become ambiguous by allowing screen overflow instead of blindly > mapping both to a single value. Oh dear. Thanks - but doesn't Debconf::Element::Dialog::Select have an analogous problem? -- Colin Watson [cjwat...@debian.org]
Bug#922315: "set " pulls in -o/+o names too
Package: bash-completion Version: 1:2.8-5 # ls m* my.rc.local # set m monitor my.rc.local So what good is doing # set monitor for? Oh, I see # mkdir /tmp/n # cd /tmp/n # set allexport hashall monitor nounset verbose braceexpand histexpandnoclobber onecmd vi emacs history noexecphysical xtrace errexit ignoreeof noglobpipefail errtrace interactive-comments nolog posix functrace keyword notifyprivileged They are supposed to be only after -o, +o etc.! All I wanted to do was set some filenames, without this interference.
Bug#922316: unblock: ruby-leaflet-rails/1.3.1+dfsg-1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Hey, Please unblock package ruby-leaflet-rails I am writing this on behalf of the Ruby team, requesting you to unblock ruby-leaflet-rails[1] by the soft freeze. The autopkgtest regression in testing was due to ruby-capybara[2], which was not in testing, which was blocked by an RC bug in puma[3]. Since they migrated on the last day before the soft freeze, there was no time to run autopkgtest for ruby-leaflet-rails and thus got blocked because of the same. Hence requesting you to unblock ruby-leaflet-rails/1.3.1+dfsg-1 [1]: https://tracker.debian.org/pkg/ruby-leaflet-rails [2]: https://tracker.debian.org/pkg/ruby-capybara [3]: https://tracker.debian.org/pkg/puma -- 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/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Best, Utkarsh
Bug#922297: rxvt-unicode: *blink* *blink* *blink*
Control: tags -1 unreproducible moreinfo On Thu, Feb 14, 2019 at 12:02:27PM +0100, Jakub Wilk wrote: > The terminal screen blinks all the time. What resources do you have set for URxvt? (See output of "appres URxvt".) What perl extensions are you using? I'll try to debug this bug (and all of the others that appeared after applying the 24bit colour patch) today, but failing that, I'll just revert the patch. Thanks, Ryan -- |)|/ Ryan Kavanagh | GPG: 4E46 9519 ED67 7734 268F |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A signature.asc Description: PGP signature
Bug#922317: FTBFS - rspamd on ppc64el fails with many errors
Package: rspamd
Version: 1.8.1-2
Severity: important
Hello,
Current build of rspamd on ppc64el fails with messages
Run Build Command:"/usr/bin/make" "cmTC_35eec/fast"
make[2]: Entering directory
'/<>/obj-powerpc64le-linux-gnu/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_35eec.dir/build.make
CMakeFiles/cmTC_35eec.dir/build
make[3]: Entering directory
'/<>/obj-powerpc64le-linux-gnu/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_35eec.dir/src.c.o
/usr/bin/cc -DPCRE2_CODE_UNIT_WIDTH=8 -g -O2 -fstrict-aliasing -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -pthread
-fPIC -W -Wall -Wpointer-arith -Wno-unused-parameter -Wno-unused-function
-Wunused-variable -Wno-pointer-sign -Wstrict-prototypes -Wnull-dereference
-Wduplicated-cond -Wno-unused-const-variable -Wno-sign-compare -std=c11
-Wno-implicit-fallthrough -DHAVE_ATOMIC_BUILTINS -o
CMakeFiles/cmTC_35eec.dir/src.c.o -c
/<>/obj-powerpc64le-linux-gnu/CMakeFiles/CMakeTmp/src.c
Linking C executable cmTC_35eec
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_35eec.dir/link.txt
--verbose=1
/usr/bin/cc -g -O2 -fstrict-aliasing -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -pthread
-fPIC -W -Wall -Wpointer-arith -Wno-unused-parameter -Wno-unused-function
-Wunused-variable -Wno-pointer-sign -Wstrict-prototypes -Wnull-dereference
-Wduplicated-cond -Wno-unused-const-variable -Wno-sign-compare -std=c11
-Wno-implicit-fallthrough -DHAVE_ATOMIC_BUILTINS -Wl,-z,relro -Wl,-z,now
-Wl,--as-needed -rdynamic CMakeFiles/cmTC_35eec.dir/src.c.o -o cmTC_35eec -lm
-lrt -ldl -lresolv -lnsl -levent
make[3]: Leaving directory
'/<>/obj-powerpc64le-linux-gnu/CMakeFiles/CMakeTmp'
make[2]: Leaving directory
'/<>/obj-powerpc64le-linux-gnu/CMakeFiles/CMakeTmp'
...and run output:
Return value: 1
Source file was:
#include
int main(int argc, char **argv) {
int a = 0, b = 0;
if (__atomic_compare_exchange_n(&a, &b, 1, false, __ATOMIC_RELEASE,
__ATOMIC_RELAXED)) {
return 0;
}
return -1;
}
cd obj-powerpc64le-linux-gnu && tail -v -n \+0 CMakeFiles/CMakeError.log
==> CMakeFiles/CMakeError.log <==
Determining if files sys/endian.h exist failed with the following output:
Change Dir: /<>/obj-powerpc64le-linux-gnu/CMakeFiles/CMakeTmp
We can note errors are while searching for sys/endian.h,
machine/endian.h and siginfo.h
However we can find these files in
/usr/include/powerpc64le-linux-gnu/bits/endian.h
/usr/include/endian.h
/usr/include/powerpc64le-linux-gnu/asm/siginfo.h
/usr/include/asm-generic/siginfo.h
so may be path for ppc64le arch should be reviewed.
libaio.h is part of package libaio-dev as /usr/include/libaio.h.
Bug#922095: light-locker: requires manually switching virtual terminals to unlock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2019-02-12 at 08:06 -0500, Dan Robinson wrote: > I was able to actually log in so I didn't realize that was an exact > duplicate. Yes sorry, this is a bit of a mess (which doesn't help user reporting bugs either). If you look at the end of #846278 there are bits about the vt-switch parts. There are other relevant bugs in lightdm/light-locker but unfortunately I didn't manage to merge everything to one single, readable bug. Regards, - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlxleOoACgkQ3rYcyPpX RFtyAQgA05ie1cJqQdy6xwBwG+YwqRjDI851kcRRXaORxcAnasY41EVvX4VmFn5z htxdjZ82Jms4Pr4WgXj6ADoDLiLxPAMwxqxX6im7h2hp4jgauBDQ7KaxetF3fCKn nQILTjeliRACxuNDGfRMrWyjHJdqaxlBnctpm8rS1mYUeQX/Q8kYuXYibzB79gXF iIOcHFucEAVsKA0iCs/NE+hK/G6tYGpgtOtzu9PZNm9xjnCRfzuOdcAntj5agwbg x0RW+xSKET6XtE4B/Epb4Dqv8IIhJ3RZWmIJ6Bw94GROoPaRaRe4j/a9eeBSylJM ZHSW3UoBrzN/bTw7QwQMEj7j+QdHqg== =JLhg -END PGP SIGNATURE-
Bug#922318: sloccount: Aborts because of binary (.o) files in the source tree
Package: sloccount Version: 2.26-5.2 Severity: normal # sloccount . Creating filelist for runtime Categorizing files. Finding a working MD5 command Found a working MD5 command. utf8 "\xB0" does not map to Unicode at /usr/bin/break_filelist line 663, line 1. Malformed UTF-8 character (fatal) at /usr/bin/break_filelist line 664, line 1. Upon encountering the first .o (or other binary) file, it aborts. I'd argue that having binary files in a source tree aren't that rare, and that sloccount should handle them gracefully - ignoring them, perhaps trying for UCS-16 first and then ignoring them, simply list them per extension as having one line each, or whatever. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=de_AT:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sloccount depends on: ii libc6 2.28-6 ii perl 5.28.1-4 sloccount recommends no packages. Versions of packages sloccount suggests: pn doc-base -- no debconf information --
Bug#919413: cascade of FTBFS
On Tuesday, 12 February 2019 16:54:12 CET Andreas Tille wrote: > I'm > not sure how to deal with the jquery.js one since this is potentially an > issue with lots of dependencies - I remember discussions about this > which I did not followed. Fortunately, jquery is available as a Debian package. We had a similar issue with libmojolicious-perl. This package now: - removes jquery from source tarball [1] using debian/copyright Files-excluded parameter - depends on libjs-jquery - provides a symlink to Debian's query instead of the regular jquery file using debian/libmojolicious-perl.links file [2] HTH [1] https://salsa.debian.org/perl-team/modules/packages/libmojolicious-perl/blob/master/debian/copyright#L7 [2] https://salsa.debian.org/perl-team/modules/packages/libmojolicious-perl/blob/master/debian/libmojolicious-perl.links
Bug#922145: closed by Rhonda D'Vine (Bug#922145: fixed in irssi 1.2.0-2)
On woensdag 13 februari 2019 15:51:04 CET you wrote: > #922145: irssi: trying to overwrite '/usr/share/irssi/help/otr', which is > also in package irssi-plugin-otr > > It has been closed by Rhonda D'Vine . I think it's not actually fixed as I just got the error again. Now with version 1.2.0-2, but 'the other way around'. Unpacking irssi-plugin-otr (1.2.0-2) over (1.2.0-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-y16KCS/03-irssi-plugin-otr_1.2.0-2_amd64.deb (--unpack): trying to overwrite '/usr/share/irssi/help/otr', which is also in package irssi 1.2.0-1 I always thought Breaks+Replaces were needed with these kind of changes. signature.asc Description: This is a digitally signed message part.
Bug#922145: closed by Rhonda D'Vine (Bug#922145: fixed in irssi 1.2.0-2)
nvm, doing another 'aptitude safe-upgrade' right after made the problem go away again. signature.asc Description: This is a digitally signed message part.
Bug#922319: Build libpam-slurm-adopt package for Slurm
Package: slurm-wlm Version: 18.08.3-1+b3 Slurm includes an alternative to libpam-slurm, called libpam-slurm- adopt. According to the SchedMD documentation libpam-slurm-adopt is "highly recommended for most installations" [1]. I created a merge request for it [2], but it's a bit behind. I think Debian should include this package. More information is available at SchedMD [3]. [1] https://slurm.schedmd.com/faq.html [2] https://salsa.debian.org/hpc-team/slurm-wlm/merge_requests/1 [3] https://slurm.schedmd.com/pam_slurm_adopt.html smime.p7s Description: S/MIME cryptographic signature
Bug#919413: cascade of FTBFS
Hi Dominique, see below Il 14/02/2019 15:16, Dominique Dumont ha scritto: On Tuesday, 12 February 2019 16:54:12 CET Andreas Tille wrote: I'm not sure how to deal with the jquery.js one since this is potentially an issue with lots of dependencies - I remember discussions about this which I did not followed. Fortunately, jquery is available as a Debian package. We had a similar issue with libmojolicious-perl. This package now: - removes jquery from source tarball [1] using debian/copyright Files-excluded parameter - depends on libjs-jquery - provides a symlink to Debian's query instead of the regular jquery file using debian/libmojolicious-perl.links file [2] HTH [1] https://salsa.debian.org/perl-team/modules/packages/libmojolicious-perl/blob/master/debian/copyright#L7 [2] https://salsa.debian.org/perl-team/modules/packages/libmojolicious-perl/blob/master/debian/libmojolicious-perl.links I 'm afraid we will not be able to avoid embedding jquery in doxygen, because it makes a weird use of it. The matter has been nicely put down by the former maintaners, see: https://salsa.debian.org/paolog-guest/doxygen/blob/master/debian/README.jquery Paolo
Bug#922320: plymouth: drop manpage link for plymouth-log-viewer
Package: plymouth Version: 0.9.4-1 Severity: minor Dear Maintainer, plymouth-log-viewer seems to have been removed in recent releases. As such, a symlink for the manpage in debian/plymouth.links is also not necessary: /usr/share/man/man8/plymouth.8.gz /usr/share/man/man8/plymouth-log-viewer.8.gz Thanks! Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1 -- System Information: Debian Release: buster/sid APT prefers disco APT policy: (500, 'disco') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-11-generic (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plymouth depends on: ii init-system-helpers 1.56+nmu1 ii libc62.28-0ubuntu1 ii libdrm2 2.4.97-1 ii libplymouth4 0.9.3-1ubuntu12 ii lsb-base 10.2018112800ubuntu1 ii systemd 240-5ubuntu3 ii udev 240-5ubuntu3 Versions of packages plymouth recommends: ii plymouth-theme-ubuntu-logo [plymouth-theme] 0.9.3-1ubuntu12 ii plymouth-theme-ubuntu-text [plymouth-theme] 0.9.3-1ubuntu12 Versions of packages plymouth suggests: pn desktop-base pn plymouth-themes -- no debconf information
Bug#922321: mosquitto security update corrupts retained messages
Package: mosquitto Version: 1.4.10-3+deb9u3 After apt dist-upgrade last night I found out the retained messages are corrupted. Hundreds of my clients are cut off right now from the server and their IoT devices. This is a very serious issue. Example of corrupted messages: teplomer/2229509/status <84>uW^Qu teplomer/2229509/relay/0/mode <84>uW teplomer/2229509/relay/0/state ȅu teplomer/2229509/system/heap <84>uWH teplomer/2229509/system/firmware ȅ teplomer/2229509/system/uptime teplomer/9363759/status ȅuW^Qu teplomer/9363759/relay/0/mode ȅuWHq teplomer/9363759/relay/0/state <84>u teplomer/13595007/status ȅuW^Qu teplomer/13595007/relay/0/mode ȅuWHq teplomer/13595007/relay/0/state <84>u teplomer/13594797/status <84>uW^Qu teplomer/13594797/relay/0/mode ȅuWHq teplomer/13594797/relay/0/state <84>u teplomer/13594797/system/firmware <84> teplomer/13594797/system/heap <84>uWH This is how the payloads should have been looking (ignore the topics, they're from different nodes): teplomer/15189239/status online teplomer/15189239/relay/0/mode auto teplomer/15189239/relay/0/state off teplomer/9803577/status offline teplomer/9803577/relay/0/mode auto teplomer/9803577/relay/0/state off teplomer/2856355/status online teplomer/2856355/relay/0/mode manual teplomer/2856355/relay/0/state off teplomer/2856355/system/firmware 27 teplomer/2856355/system/heap 24408 teplomer/2856355/system/uptime 3167107 teplomer/15189240/relay/0/state off teplomer/15189240/relay/0/mode auto teplomer/15189240/status online teplomer/15189240/system/heap 26864 teplomer/9980395/status online Restoring a backup is impossible because Mosquitto keeps all retained messages in one large DB file while some clients have updated some of the messages in the meantime. >From discussion with Roger Light (the maintainer) I understood that this issue is known and has been fixed in a yet unreleased patch. I'd like to urge Debian folks to release the fix ASAP or roll back this deb9u3 package that is causing serious issues in the wild. I'm using Debian Stretch, FYI. Thanks, Petr
Bug#888580: Bug#919413: cascade of FTBFS
On Thu, Feb 14, 2019 at 03:16:22PM +0100, Dominique Dumont wrote: > On Tuesday, 12 February 2019 16:54:12 CET Andreas Tille wrote: > > I'm > > not sure how to deal with the jquery.js one since this is potentially an > > issue with lots of dependencies - I remember discussions about this > > which I did not followed. > > Fortunately, jquery is available as a Debian package. Sure it is. I simply remember some discussions about why doxygen needs its own jquery. I'd be really happy if this is not the case any more. Kind regards Andreas. -- http://fam-tille.de
Bug#922218: gnome-shell fills up logs with an stack trace
O Mér, 13-02-2019 ás 11:30 +, Simon McVittie escribiu: > Control: tags -1 + moreinfo > > On Wed, 13 Feb 2019 at 11:51:08 +0100, Sergio Villar wrote: > > gnome-shell is making my system unusable by completelly filling up > > the /var partition due to the errors it spits into several log > > files > > like syslog, user.log and messages. > > Are you using any GNOME Shell extensions? > > If you are, does this problem persist if you disable them? > > Does this problem persist if you upgrade gnome-shell, mutter and gjs > to the versions in unstable? (These versions should have migrated to > testing a while ago, but are being held up by uninstallability on > s390x; > the release team assure me that they intend to get these versions > into > buster before the release.) That made it. I upgraded gnome-shell to unstable version and the problem is gone. BR
Bug#922293: libxcomp3 must use -lpthread or -pthread (undefined symbol: pthread_key_create)
Control: severity -1 important On Do 14 Feb 2019 11:33:57 CET, Thomas Arendsen Hein wrote: Package: libxcomp3 Version: 2:3.5.99.18-1 Severity: normal Dear Debian Remote Maintainers, quoting https://lists.debian.org/debian-backports/2019/02/msg00017.html: * Yuriy M. Kaminskiy [20190214 09:22]: On 14.02.2019 10:53, Thomas Arendsen Hein wrote: > I just installed x2goserver from stretch-backports and x2goclient > from stretch on the same machine. Now x2goclient no longer works > correctly due to the following error in nxproxy: > > $ nxproxy > /usr/lib/nx/bin/nxproxy: symbol lookup error: > /usr/lib/x86_64-linux-gnu/libXcomp.so.3: undefined symbol: > pthread_key_create > > > /usr/lib/x86_64-linux-gnu/libXcomp.so.3 is contained in libxcomp3 This sounds more like bug in libxcomp3 (if it uses symbols from libpthread, it must link to -lpthread [or -pthread]; newer nxproxy likely links to libpthread itself, which hides this bug; still, this must be fixed in libxcomp3); fwiw, dh_shlibdeps even complained about this: === https://buildd.debian.org/status/fetch.php?pkg=nx-libs&arch=amd64&ver=2%3A3.5.99.18-1&stamp=1548946175&raw=0 ... dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info ... dpkg-shlibdeps: warning: symbol pthread_setspecific used by debian/libxcomp3/usr/lib/x86_64-linux-gnu/libXcomp.so.3.5.99 found in none of the libraries ... === cut === (this bug seems still present in buster/sid, so I'd suggest filling bug against nx-libs). I will add a pointer to the Debian bug report on the bpo list. This needs to be addressed soon. I'll take a look tomorrow. Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpYvJ7g3Le0S.pgp Description: Digitale PGP-Signatur
Bug#922310: unblock: ruby-jquery-ui-rails/6.0.1+dfsg-3 (and 922316)
Hi On 14-02-2019 14:36, Utkarsh Gupta wrote: > The autopkgtest regression in testing was due to ruby-capybara[2], which > was not in testing, which was blocked by an RC bug in puma[3]. ^ which is bug #900156 which was filed on 26 May 2018 and didn't see a fix until 2 days before the soft freeze. Paul signature.asc Description: OpenPGP digital signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Thomas, > > it seems isohybrid can include a small FAT filesystem with the > > bootloader files. [...] > > https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI > > This describes the equipment of debian-live and debian-cd (DVD-*, BD-*, > netinst) ISOs. See e.g. debian-live-9.5.0-i386-xfce.iso and its > MBR partition table. I'm a bit confused by your message. When you say "This", are you referring to the syslinux isohybrid page? > Debian and nearly all others use GRUB 2 for their EFI capable ISOs. > See Knoppix 8.[12] for examples of SYSLINUX EFI in ISOs. > > SYSLINUX EFI stuff is known not to boot from CD, DVD, or BD, but only from > HDD, SSD, and alike. Again, I'm confused. If syslinux-efi is known not to boot from CD/DVD/BD, then why do they document how to include it into an isohybrid image? Or does it then only work when booting the isohybrid image from a HDD, rather than CD? Gr. Matthijs signature.asc Description: PGP signature
Bug#922306: linux: btrfs corruption (compressed data + hole data)
Here's the "proper" patch: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg85515.html
Bug#922323: [basilisk2] several newtork setups crash app
Package: basilisk2 Version: 0.9.20120331-4+b1 Severity: normal --- Please enter the report below this line. --- I try differents setups to get networking on BasiliskII and i get SIGSEGV constantly Caught SIGSEGV at address 0xbc2d04d9 [IP=0x55ebff7d80cb] D0: 0ff84c00 D1: 0ffea025 D2: 0003 D3: 00226d5e D4: ff00 D5: a201 D6: 0003 D7: 0ffe3d30 A0: 0ff84bf4 A1: 0ff79498 A2: 0004d876 A3: 1008787a A4: 0060 A5: 0ffb75e8 A6: 7b5f849d A7: 0ff84bd2 USP= ISP=0ff84bd2 MSP= VBR= T=00 S=1 M=0 X=1 N=0 Z=0 V=0 C=0 IMASK=0 FP0: nan FP1: nan FP2: nan FP3: nan FP4: nan FP5: nan FP6: nan FP7: nan N=0 Z=0 I=0 NAN=0 1000dc0c: 202e 003c 6010 200e c0b8 MOVE.L (A6,$003c) == $7b5f84d9,D0 next PC: 1000dc10 --- System information. --- Architecture: Kernel: Linux 4.9.0-8-rt-amd64 --- Package information. --- Depends (Version) | Installed ===-+- libatk1.0-0 (>= 1.12.4) | 2.22.0-1 libc6 (>= 2.15) | libcairo2(>= 1.2.4) | libesd0 (>= 0.2.35) | libfontconfig1 (>= 2.11) | libfreetype6 (>= 2.2.1) | libgcc1 (>= 1:3.0) | libgdk-pixbuf2.0-0 (>= 2.22.0) | libglib2.0-0 (>= 2.16.0) | libgtk2.0-0 (>= 2.8.0) | libpango-1.0-0 (>= 1.14.0) | libpangocairo-1.0-0 (>= 1.14.0) | libpangoft2-1.0-0 (>= 1.14.0) | libsdl1.2debian (>= 1.2.11) | libstdc++6 (>= 5.2) | Package's Recommends field is empty. Package's Suggests field is empty. -- Fernando Toledo Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar
Bug#922324: clojure breaks nrepl-clojure autopkgtest
Source: clojure, nrepl-clojure Control: found -1 clojure/1.10.0-1 Control: found -1 nrepl-clojure/0.6.0-1 X-Debbugs-CC: debian...@lists.debian.org Severity: important User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainers, With a recent upload of clojure the autopkgtest of nrepl-clojure fails in testing when that autopkgtest is run with the binary packages of clojure from unstable. It passes when run with only packages from testing. In tabular form: passfail clojurefrom testing1.10.0-1 nrepl-clojure from testing0.6.0-1 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. I don't know how bad this warning is, but if this is a warning, clearly the autopkgtest needs to be enhanced to either suppress it or accept output to stderr. Currently this regression is blocking the migration of clojure to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from clojure/1.10.0-1. I.e. due to versioned dependencies or breaks/conflicts. [1] https://qa.debian.org/excuses.php?package=clojure https://ci.debian.net/data/autopkgtest/testing/amd64/n/nrepl-clojure/1929935/log.gz autopkgtest [12:11:27]: test hello-nrepl: [--- WARNING: requiring-resolve already refers to: #'clojure.core/requiring-resolve in namespace: user, being replaced by: #'nrepl.misc/requiring-resolve "e7d1e44b-654f-4a09-8460-7c9e3d01d783" autopkgtest [12:11:32]: test hello-nrepl: ---] autopkgtest [12:11:32]: test hello-nrepl: - - - - - - - - - - results - - - - - - - - - - hello-nrepl FAIL stderr: WARNING: requiring-resolve already refers to: #'clojure.core/requiring-resolve in namespace: user, being replaced by: #'nrepl.misc/requiring-resolve signature.asc Description: OpenPGP digital signature
Bug#922325: pep8-naming: autopkgtest regression: No module named 'pep8ext_naming'
Source: pep8-naming Version: 0.8.2-1 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Dear maintainers, With a recent upload of pep8-naming the autopkgtest of pep8-naming fails in testing when that autopkgtest is run with the binary packages of pep8-naming from unstable. It passes when run with only packages from testing. In tabular form: passfail pep8-namingfrom testing0.8.2-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=pep8-naming https://ci.debian.net/data/autopkgtest/testing/amd64/p/pep8-naming/1929250/log.gz autopkgtest [09:13:15]: test python3-pep8-naming: [--- [*] testing python3.7: Traceback (most recent call last): File "run_tests.py", line 8, in import pep8ext_naming ModuleNotFoundError: No module named 'pep8ext_naming' autopkgtest [09:13:16]: test python3-pep8-naming: ---] signature.asc Description: OpenPGP digital signature
Bug#922326: Use background image file that is available on stretch and buster
Package: arctica-greeter Version: 0.99.1.1-1 Severity: important The current theming package break on Debian stretch. As we want to provide this package for stretch-backports, we need to use a desktop-theme background image that is available on buster and on stretch. It seems that /usr/share/desktop-base//login/background.svg is the best image to use as login manager background image. Patch coming soon... Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpBpNz8Y1Def.pgp Description: Digitale PGP-Signatur
Bug#922327: python-redis: autopkgtest regression: 7 failures
Source: python-redis Version: 3.1.0-1 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Dear maintainers, With a recent upload of python-redis the autopkgtest of python-redis fails in testing when that autopkgtest is run with the binary packages of python-redis from unstable. It passes when run with only packages from testing. In tabular form: passfail python-redis from testing3.1.0-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=python-redis https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-redis/1929237/log.gz autopkgtest [09:12:33]: test 0001-python2: [--- running test running egg_info creating redis.egg-info writing requirements to redis.egg-info/requires.txt writing redis.egg-info/PKG-INFO writing top-level names to redis.egg-info/top_level.txt writing dependency_links to redis.egg-info/dependency_links.txt writing manifest file 'redis.egg-info/SOURCES.txt' package init file 'redis/__init__.py' not found (or not a regular file) reading manifest file 'redis.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' warning: no previously-included files found matching '__pycache__' warning: no previously-included files matching '*.pyc' found under directory 'tests' writing manifest file 'redis.egg-info/SOURCES.txt' running build_ext = test session starts == platform linux2 -- Python 2.7.15+, pytest-3.10.1, py-1.7.0, pluggy-0.8.0 rootdir: /tmp/autopkgtest-lxc.ocipt8zk/downtmp/build.8FK/src, inifile: collected 400 items tests/test_commands.py . [ 12%] [ 30%] [ 48%] ..s.F.F...F..F..FF..F. [ 64%] tests/test_connection_pool.py .. [ 75%] .. [ 75%] tests/test_encoding.py .. [ 77%] tests/test_lock.py [ 83%] tests/test_pipeline.py . [ 87%] tests/test_pubsub.py ... [ 95%] tests/test_scripting.py ... [ 97%] tests/test_sentinel.py [100%] === FAILURES === _ TestRedisCommands.test_xack __ [XPASS(strict)] TestRedisCommands.test_xclaim _ [XPASS(strict)] __ TestRedisCommands.test_xgroup_delconsumer ___ [XPASS(strict)] TestRedisCommands.test_xinfo_consumers [XPASS(strict)] ___ TestRedisCommands.test_xpending [XPASS(strict)] TestRedisCommands.test_xpending_range _ [XPASS(strict)] __ TestRedisCommands.test_xreadgroup ___ [XPASS(strict)] === 7 failed, 392 passed, 1 skipped in 11.86 seconds === autopkgtest [09:12:45]: test 0001-python2: ---] signature.asc Description: OpenPGP digital signature
Bug#920643: mariadb-server-10.3: mariadb won't start when running inside an lxc container when running on debian testing
Control: forwarded -1 https://github.com/lxc/lxc/pull/2758 Matthew, I able to reproduce this and I have the exact same error (mariadb log + apparmor on host). Your workaround is working but it seems that removing only these 3 lines is sufficient: > ProtectSystem=full > PrivateDevices=true > ProtectHome=true You can leave this one: > ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld Another workaround is to disable completely apparmor: https://wiki.debian.org/AppArmor/HowToUse#Disable_AppArmor I think we should wait until some progress comes from https://github.com/lxc/lxc/pull/2758. Faustin
Bug#922324: clojure breaks nrepl-clojure autopkgtest
This is just a warning about name shadowing - all code continues to function as intended. > On Feb 14, 2019, at 9:45 AM, Paul Gevers wrote: > > Source: clojure, nrepl-clojure > Control: found -1 clojure/1.10.0-1 > Control: found -1 nrepl-clojure/0.6.0-1 > X-Debbugs-CC: debian...@lists.debian.org > Severity: important > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainers, > > With a recent upload of clojure the autopkgtest of nrepl-clojure fails > in testing when that autopkgtest is run with the binary packages of > clojure from unstable. It passes when run with only packages from > testing. In tabular form: > passfail > clojurefrom testing1.10.0-1 > nrepl-clojure from testing0.6.0-1 > versioned deps [0] from testingfrom unstable > all others from testingfrom testing > > I copied some of the output at the bottom of this report. I don't know > how bad this warning is, but if this is a warning, clearly the > autopkgtest needs to be enhanced to either suppress it or accept output > to stderr. > > Currently this regression is blocking the migration of clojure to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and > reassign the bug to the right package? If needed, please change the > bug's severity. > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [0] You can see what packages were added from the second line of the log > file quoted below. The migration software adds source package from > unstable to the list if they are needed to install packages from > clojure/1.10.0-1. I.e. due to versioned dependencies or breaks/conflicts. > [1] https://qa.debian.org/excuses.php?package=clojure > > https://ci.debian.net/data/autopkgtest/testing/amd64/n/nrepl-clojure/1929935/log.gz > > autopkgtest [12:11:27]: test hello-nrepl: [--- > WARNING: requiring-resolve already refers to: > #'clojure.core/requiring-resolve in namespace: user, being replaced by: > #'nrepl.misc/requiring-resolve > "e7d1e44b-654f-4a09-8460-7c9e3d01d783" > autopkgtest [12:11:32]: test hello-nrepl: ---] > autopkgtest [12:11:32]: test hello-nrepl: - - - - - - - - - - results - > - - - - - - - - - > hello-nrepl FAIL stderr: WARNING: requiring-resolve already > refers to: #'clojure.core/requiring-resolve in namespace: user, being > replaced by: #'nrepl.misc/requiring-resolve > > ___ > Pkg-clojure-maintainers mailing list > pkg-clojure-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-clojure-maintainers
Bug#922310: unblock: ruby-jquery-ui-rails/6.0.1+dfsg-3 (and 922316)
On Thu, 14 Feb 2019 16:35:22 +0100 Paul Gevers wrote: > Hi > > On 14-02-2019 14:36, Utkarsh Gupta wrote: > > The autopkgtest regression in testing was due to ruby-capybara[2], which > > was not in testing, which was blocked by an RC bug in puma[3]. >^ > which is bug #900156 which was filed on 26 May 2018 and didn't see a fix > until 2 days before the soft freeze. > rails 5 transition took longer than we expected. Without rails 5 in testing, we did not have any chance to get diaspora or redmine to buster. Once we got rails 5 to buster, we focused on the dependencies and noticed puma was blocking ruby-capybara. As discussed in #debci, ruby-jquery-ui-rails and ruby-leaflet-rails were eligible for testing migration in 2 days with autopkgtest passing in unstable, but it was not considered (posdibly because autopkgtest recorded failure in testing). -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#921784: [Debichem-devel] Bug#921784: gromacs: FTBFS (ld returned 1 exit status)
severity 921784 normal retitle 921784 gromacs: unhelpful error message from mpicxx.openmpi thanks After some tests, I believe the most probably reason for the failure I got was lack of disk space. Sorry for the false positive, I usually measure how much disk space is required and only try in a machine which has enough. Because this was a new upstream release, I was still using the disk estimation from the previous version. I've put the full build log which motivated this report here: https://people.debian.org/~sanvila/build-logs/gromacs/ I think there is still a problem here: Why is there not any "disk full" message anywhere? Why just "ld returned 1 exit status"? Should not also say the reason, like any other compiler usually does? Perhaps this should be reassigned to whatever package contains the "mpicxx.openmpi" command? Thanks.
Bug#905715: libgirepository1.0-dev: File conflict in multi-arch package
Dear Maintainers, is there a chance that this bug will be fixed for buster? What would be the right fix? Move all .gir files from /usr/share/gir-1.0/ to /usr/share/gir-1.0//? As Hugh pointed out, at the moment GLib-2.0.gir is the only gir with architecture specific definitions in this package. TIA & Cheers
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hey Luca, > At a quick glance it all sounds good to me, although I can't say I have > a lot of experience with syslinux. Ok. > For feature parity, I'd encourage to look into supporting Secure Boot > like the grub-efi implementation does, since we are preparing to ship > that in Debian 10. It's not much extra work on top of adding the rest > anyway. Can you elaborate a bit on how grub-efi supports Secure Boot exactly? I can't really find anything about this in the code? Looking at build/scripts/binary_grub-efi and build/scripts/efi-image, I see that a new efi firmware binary is built using grub-mkimage, so I suppose that that image is not already signed, and there is nothing suggesting that image is be signed at that time. Looking at binary_iso there is also no reference to signing or secure boot. AFAIU, to support secure boot, you need to sign the bootloader, typically using a key from MS. I've read about the Shim bootloader, which is signed and typically used to then load grub or other bootloaders (signed by the Debian key or other keys included in Shim). However, I can see no reference to shim either. Looking at the grub package more closely, I *think* that it installs shim alongside grub when using grub-install, but that is not used here? Regardless, how would you suggest we "support Secure Boot" with syslinux-efi exactly? AFAICT there is no syslinux-efi image available signed with the MS key, and I suspect it is not signed with the Debian key or any other key used by shim (also, since syslinux does not seem to support key verification on kernels, I guess there is no secure way to get syslinux booting under secure boot without compromising secure boot, but I might be missing an important point about SB here...). > > Since config sharing is easy and syslinux-efi is a matter of adding > > some files to the existing image, it would make sense to add > > syslinux-efi by default on normal syslinux hdd images (perhaps > > adding a new option to disable this?). I just noticed that lb config has a --bootloaders that supports *multiple* bootloaders, so that would be perfect way to support this. E.g. --bootloaders syslinux,syslinux-efi to have combined image (which would also become the default for hdd images), or an explicit --bootloaders syslinux or --bootloaders syslinux-efi to choose either one individually. Gr. Matthijs signature.asc Description: PGP signature
