Bug#927775: monit: CVE-2019-11454 CVE-2019-11455
On Sun, Jun 09, 2019 at 01:44:18PM +0200, Salvatore Bonaccorso wrote: > I gave a reason though now in my previous mail I was expecting such explanation before changing in severity... > > > Could you please work out with the Release team via an unblock request > > > if they would wave through the version or a sheduled a targeted fix > > > via testing-proposed-updates? > > > > Yes, I'm planing backports for these fixes. I don't know why this > > require increase in the bug severity. > > Perfect, thanks! The increase in severity was done as per above, to > make sure it is marked release critical and not missed for the > release of buster. > > I still do not get it why a new upstream version was uploaded to > unstable at this point in the freeze, though. I hope, release team will unblock transition, it's a bugfix release.
Bug#930195: avr-libc: Upstream avr-libc maintainers appear to be MIA; can another source be found?
Hi, Apache 2.0 licence is fine, but for the main distribution we need the source as well. On Mon, Jun 10, 2019 at 12:28 PM Paul "LeoNerd" Evans < leon...@leonerd.org.uk> wrote: > On Mon, 10 Jun 2019 11:07:29 +0200 > Hakan Ardo wrote: > > > There have been a sugestion to use Microchip Packs Repository: > > > > http://packs.download.atmel.com/ > > > > But as far as I can tell, these are binary distributions and thus not > > suitable for mainstream debian (I suppose placing them i non-free > > could be an option). > > This is the preferred method I believe. In fact, it's what I use as a > workaround at the moment. > > I've written myself a "reminder to self" blog post, which illustrates > the steps I took to fix this problem: > > > https://leonerds-code.blogspot.com/2019/06/building-for-new-attiny-1-series-chips.html > > Having done that, I can build code for these new chips just fine. > > Maybe that's all that is required? The pack files are Apache 2.0 > licenced, so hopefully that is acceptable to Debian? > > -- > Paul "LeoNerd" Evans > > leon...@leonerd.org.uk | https://metacpan.org/author/PEVANS > http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ > -- Håkan Ardö
Bug#930195: avr-libc: Upstream avr-libc maintainers appear to be MIA; can another source be found?
On Mon, 10 Jun 2019 11:07:29 +0200 Hakan Ardo wrote: > There have been a sugestion to use Microchip Packs Repository: > > http://packs.download.atmel.com/ > > But as far as I can tell, these are binary distributions and thus not > suitable for mainstream debian (I suppose placing them i non-free > could be an option). This is the preferred method I believe. In fact, it's what I use as a workaround at the moment. I've written myself a "reminder to self" blog post, which illustrates the steps I took to fix this problem: https://leonerds-code.blogspot.com/2019/06/building-for-new-attiny-1-series-chips.html Having done that, I can build code for these new chips just fine. Maybe that's all that is required? The pack files are Apache 2.0 licenced, so hopefully that is acceptable to Debian? -- Paul "LeoNerd" Evans leon...@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Bug#929451: linking shaders twice fails, fixed by rebuilding the package
On Thu, May 23, 2019 at 10:09:21PM +0200, Steinar H. Gunderson wrote: > Unfortunately, even after clearing the shader cache, I can provoke these > issues with a bit of work. So something is corrupting the shader cache. I tracked this to https://bugs.freedesktop.org/show_bug.cgi?id=110872 which is related to a Qt bug: https://bugreports.qt.io/browse/QTBUG-76299 Given that it breaks Nageru on i965 (and probably not a lot of other things, given the analysis), but is unlikely to be fixed in Mesa, at least not for buster, I'm going to add a workaround to Nageru. (It's possible Qt should have a fix, too, but it's unlikely to be RC for Qt.) Reassigning to Nageru and making RC. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#930091: bison is wrongly marked Multi-Arch: foreign
On 06.06.19 20:08, Helmut Grohne wrote: > Package: bison > Version: 2:3.3.2.dfsg-1 > Severity: important > > bison is marked Multi-Arch: foreign and Depends on libbison-dev. > Packages Build-Depend on bison and expect a libbison-dev (for the host > architecture). This is broken. > > We had this problem earlier with flex and I can provide the same options > to fix it. > > A. Depend on libbison-dev explicitly. We consider that a dependency on >bison does not include libbison-dev. Not every user of bison needs >libbison-dev and only those that do need it, need the dependency. >This change is quite simple: Drop the libbison-dev dependency from >bison. It makes a pile of packages FTBFS until they add the >dependency. bison has around 540 build-rdeps. I haven't examined how >many need libbison-dev. flex went this way. > > B. Reverse dependencies. This is the "tricky multiarch fix". It may take >a while to understand, but we can fix the whole issue with a single >upload of bison: > >* Drop the dependency on libbison-dev from bison. >* Rename bison to bison-bin. >* Update the description of bison-bin (formerly bison) to explain > that this package is an implementation detail and people should > continue depending on bison. >* Rename libbison-dev to bison. >* Make the new bison (former libbison-dev) depend on bison-bin > (formerly bison). >* Add Provides: libbison-dev to the new bison (formerly > libbison-dev). > >After performing these changes, a Build-Depends: bison will result in >the build architecture bison executable together with the host >architecture liby.a. Things will just work without any need for >modifying downstream packages. People won't have to be aware of the >distinction between the library and the code generator. > > Comparing these approaches I see the following trade-offs: > > * A makes a ton of packages FTBFS and will need possibly hundreds of >uploads. > * A is consistent with flex. > * A is slightly better for cross building. Given the experience with >flex, I expect that the majority of rdeps won't need libbison-dev. >For cross building this means that bison doesn't have to be available >for the host architecture. > > We need a decision on which approach to take. Preferrably soon. I'm > happy to implement either. I'm also happy to take care of the MBF if we > opt for A. This bug should not be fixed for buster. If you ask me, I'd > slightly preferred option B, but since flex did A, I favour consistency > and thus A. What is your (maintainer) preference? Do we need to know how > many packages would ftbfs before deciding? I would go for the "cleaner" solution A. It matches what it is done with flex. And it matches with yet another autotools related tool: libtool. libtool also doesn't have an explicit dependency on libltdl-dev. Matthias
Bug#902174: #902174: RFP: mes
On 2019-06-10, Jan Nieuwenhuizen wrote:
> Vagrant Cascadian writes:
>> Mes itself still fails to build
...
>> configure fails to detect nyacc. It may be an issue
>> with multi-arch paths (e.g. /usr/lib/guile/2.2
>> vs. /usr/lib/x86_64-linux-gnu/guile/2.2).
>
> Oops, that looks like a bug, thanks. I hope it's harmless...
The configure script still fails to detect nyacc (with version 0.86.0,
0.86.9, 0.92.0, 0.93.0 or 0.94.0):
checking for nyacc [0.86.0]... command[11]: ("/usr/bin/guile-2.2 -c
'(use-modules (nyacc lalr)) (display *nyacc-version*)'" "--version") => []
no
When I run the command from the commandline:
$ /usr/bin/guile-2.2 -c '(use-modules (nyacc lalr)) (display
*nyacc-version*)'
0.94.0
Same with any of the other versions of nyacc...
So not sure why ./configure is getting an empty result... how is
configure passing the "--version" argument?
>> Will need to do some better troubleshooting later... but this appears to
>> be the last build failure i tried based on the wip branch:
>>
>> ../pre-inst-env mescc -m 64 -c -D HAVE_CONFIG_H=1 -I include -I
>> ../include -I ../include/linux/x86_64 -static -o crt1.o
>> ../lib/linux/x86_64-mes-mescc/crt1.c
>> unhandled exception:unbound-variable:(move-specl-attr)
>> Backtrace:
>> /<>/scripts/mescc: line 56: 24904 Segmentation fault
>> ${SCHEME-$MES} --no-auto-compile -e main -L /usr/share/guile/site/2.2 -C
>> /usr/lib/guile/2.2/site-ccache $bindir/mescc.scm $sep "$@"
>> make[1]: *** [GNUmakefile:95: build] Error 139
>
> This could be a problem with Nyacc 0.93.0, find a patch attached for
> that.
Patch seems to have fixed that issue.
After some aggressive patching for /bin/sh -> /bin/bash and using bash
-x, it manages to get further, but it still fails building libmes:
+ trace 'CC lib/libmes.c' /usr/bin/gcc -c -Wdate-time
-D_FORTIFY_SOURCE=2 -D POSIX=1 -D WITH_GLIBC=1 -D POSIX=1 -D
WITH_GLIBC=1 -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -o lib/libmes.o lib/libmes.c
+ echo ' CC lib/libmes.c'
CC lib/libmes.c
+ shift
+ eval /usr/bin/gcc -c -Wdate-time -D_FORTIFY_SOURCE=2 -D POSIX=1 -D
WITH_GLIBC=1 -D POSIX=1 -D WITH_GLIBC=1 -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -o lib/libmes.o lib/libmes.c '>>build.log'
'2>&1'
++ /usr/bin/gcc -c -Wdate-time -D_FORTIFY_SOURCE=2 -D POSIX=1 -D
WITH_GLIBC=1 -D POSIX=1 -D WITH_GLIBC=1 -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -o lib/libmes.o lib/libmes.c
make[1]: *** [GNUmakefile:83: build] Error 1
make[1]: Leaving directory '/<>'
dh_auto_build: make -j4 returned exit code 2
make: *** [debian/rules:9: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned
exit status 2
I also tried without the hardening build flags, but no real difference.
live well,
vagrant
Bug#930247: grep: inconsistent behaviour with anchored regex containing back-references
Control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36148 Control: tags -1 + upstream Thanks for your bug report, -- Santiago El 09/06/19 a las 11:22, g1 escribió: > Package: grep > Version: 2.27-2 > Severity: normal > > There seems to be a problem with beginning/end-of-line anchors in regex > containing back-references: > > $ cat words > ana > deed > ill > stats > > Using -x to match whole line works: > > $ egrep -x '(.?)(.?).?\2\1' words > ana > deed > stats > > Using explicit anchors emits false positives: > > $ egrep '^(.?)(.?).?\2\1$' words > ana > deed > ill <<< > stats > > On the other hand, colouring the output shows that grep somewhat knows its > mistake: > > $ egrep --color '^(.?)(.?).?\2\1$' words > ana (coloured) > deed(coloured) > ill > stats (coloured) > > -- System Information: > Debian Release: 9.9 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) > Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C > (charmap=ANSI_X3.4-1968) > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > > Versions of packages grep depends on: > ii dpkg 1.18.25 > ii install-info 6.3.0.dfsg.1-1+b2 > ii libc6 2.24-11+deb9u4 > ii libpcre3 2:8.39-3 > > grep recommends no packages. > > Versions of packages grep suggests: > ii libpcre3 2:8.39-3 > > -- no debconf information > signature.asc Description: PGP signature
Bug#924623: Please update golang-defaults/golang-go
Am 06.06.19 um 04:45 schrieb Nye Liu: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924623 > > diff -ur golang-defaults-1.11~1/debian/changelog > golang-defaults-1.12~1/debian/changelog > --- golang-defaults-1.11~1/debian/changelog 2018-12-29 05:55:11.0 > -0800 > +++ golang-defaults-1.12~1/debian/changelog 2019-03-15 00:24:00.302072020 > -0700 > @@ -1,3 +1,9 @@ > +golang-defaults (2:1.12~1) unstable; urgency=medium > + > + * Update to Go 1.12 (src:golang-1.12) > + > + -- Nye Liu mailto:n...@nyet.org>> Fri, 15 Mar 2019 > 00:23:11 -0700 > + Hi Liu, thanks for your bug report and patch. In the normal development cycle, golang is updated fairly regularly. However, currently Debian is in a freeze for the next stable release of Debian. Therefore, I will not apply this change until after the release. Regards, Tobias signature.asc Description: OpenPGP digital signature
Bug#930312: python-docker: Please package a more recent version e.g. 3.6.0
Package: python-docker Version: 3.4.1-4 Severity: wishlist Dear Maintainer, Thank you for working on python-docker! Could you please package a more recent version of it? -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 python-docker depends on: ii python 2.7.16-1 ii python-backports.ssl-match-hostname 3.5.0.1-1 ii python-dockerpycreds 0.3.0-1 ii python-ipaddress 1.0.17-1 ii python-requests 2.21.0-1 ii python-six 1.12.0-1 ii python-websocket 0.53.0-1 python-docker recommends no packages. python-docker suggests no packages. -- no debconf information
Bug#930311: lintian: Possible exception to package-contains-documentation-outside-usr-share-doc
Package: lintian
Version: 2.15.0
Severity: normal
Hi,
I noticed that the dh-r package by default creates an override for
package-contains-documentation-outside-usr-share-doc when the R
package puts documentation in usr/lib/R/site-library:
"""
my $check_for_docs = `find debian/$dh{FIRSTPACKAGE} -type f -name "*.md" -o
-name "*.Rmd" -o -name "README" -o -name "README.md" | grep -v 'usr/share/doc'`;
if ( $check_for_docs ) {
say "Create lintian-override for
package-contains-documentation-outside-usr-share-doc due to $check_for_docs";
open(my $lintian, ">>", "debian/lintian-overrides");
say $lintian "# The documentation is where it is expected by GNU R
users";
say $lintian "$dh{FIRSTPACKAGE}:
package-contains-documentation-outside-usr-share-doc usr/lib/R/site-library/*";
close $lintian;
}
"""
(source: https://sources.debian.org/src/dh-r/20190121/dh/R.pm/?hl=3#L268)
My question is: Should we move this exception to lintian itself and
stop having people automate overrides or should something else be
done? (To be explicit: The latter is an open question as I am not
sure what the "proper something else" would be in this case)
Thanks,
~Niels
Bug#930195: avr-libc: Upstream avr-libc maintainers appear to be MIA; can another source be found?
Hi, avr packages in debian have for the last couple of years been based on a distribution from atmel: http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-%20Toolchain/3.4.4/ However it's recently gone away too... There have been a sugestion to use Microchip Packs Repository: http://packs.download.atmel.com/ But as far as I can tell, these are binary distributions and thus not suitable for mainstream debian (I suppose placing them i non-free could be an option). On Sat, Jun 8, 2019 at 12:45 AM Paul "LeoNerd" Evans wrote: > Package: avr-libc > Version: 1:2.0.0+Atmel3.6.1-2 > Severity: normal > > Dear Maintainer, > > Hi all, > > The upstream project at https://savannah.nongnu.org/projects/avr-libc/ > appears to have stalled, because no actual updates have been made in a > couple of years now. Meanwhile there are many new types of AVR chip that > the library does not yet support. I've been reporting bugs upstream and > not getting any responses. E.g. > > https://savannah.nongnu.org/bugs/?54652 > > https://savannah.nongnu.org/bugs/?54977 > > Would it be possible for Debian to find another source of this - perhaps > by using the Atmel part files more directly? Specifically, newer chips > that this Debian package does not support that I have been trying to > work on are: > > ATmega328PB > > ATtiny214, ATtiny414, ATtiny814, ATtiny1614, ATtiny3214 > ATtiny416, ATtiny816, ATtiny1616, ATtiny3216 > ATtiny417, ATtiny817, ATtiny1717, ATtiny3217 > (i.e. the entire new ATtiny 1-series) > > ATmega3208, ATmega4808 > ATmega3209, ATmega4809 > (i.e. the entire new ATmega 0-series) > > A number of folks on #avr on Freenode have been aware of this for some > time, and we're getting close to the point of declaring a fork of the > original nongnu project so we can continue to make progress adding the > newer chips from the last few years. > > Before we look into that, is Debian aware of any other sources for this > sort of thing, that we could talk to instead? > > Thanks, > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, > 'testing-debug'), (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages avr-libc depends on: > ii binutils-avr 2.26.20160125+Atmel3.6.1-4 > ii gcc-avr 1:5.4.0+Atmel3.6.1-2 > > avr-libc recommends no packages. > > avr-libc suggests no packages. > > -- no debconf information > > -- debsums errors found: > debsums: changed file /usr/lib/avr/include/avr/io.h (from avr-libc package) > > > -- > Paul "LeoNerd" Evans > > leon...@leonerd.org.uk | https://metacpan.org/author/PEVANS > http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/ > -- Håkan Ardö
Bug#930309: O: libtomcrypt
Package: wnpp Severity: normal Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/
Bug#930310: O: dunst -- dmenu-ish notification-daemon
Package: wnpp Severity: normal Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/
Bug#930304: O: wiipdf -- present a PDF file using your wiimote
Package: wnpp Severity: normal Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/
Bug#930307: O: simple-tpm-pk11 -- simple library for using the TPM chip to secure SSH keys
Package: wnpp Severity: normal Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/
Bug#930306: O: teensy-loader-cli -- load and run programs onto your Teensy micro controller
Package: wnpp Severity: normal Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/
Bug#930305: O: unworkable -- efficient, simple and secure bittorrent client
Package: wnpp Severity: normal Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/
Bug#930303: O: wit -- manipulate Wii and GameCube ISO images and WBFS containers
Package: wnpp Severity: normal Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/
Bug#930308: O: mscompress -- Microsoft "compress.exe/expand.exe" compatible (de)compressor
Package: wnpp Severity: normal Please see https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/
Bug#903635: This is RC; breaks unrelated software
clone 903635 -1 retitle -1 installing and starting docker changes iptables FORWARD policy, breaking unrelated things severity 903635 important found 903635 18.09.1+dfsg1-7 found -1 18.09.1+dfsg1-7 thanks On Mon, Jun 10, 2019 at 01:27:45AM +0800, Shengjing Zhu wrote: Could you provide more info about "changed my FORWARD chain policy to DROP"? In a fresh test Buster installation. Before: # iptables -L | grep FORWARD Chain FORWARD (policy ACCEPT) # dpkg -l docker.io # dpkg-query: no packages found matching docker.io # apt install -y docker.io After # iptables -L | grep FORWARD Chain FORWARD (policy ACCEPT) # systemctl start docker # iptables -L | grep FORWARD Chain FORWARD (policy DROP) So: Installing (*and* starting) Docker, with no other configuration steps performed by the user, changes the FORWARD table policy, which breaks e.g. any running VMs on the host. I set add `"iptables": false` to `/etc/docker/daemon.json`. Then reboot my laptop. Then run `iptables-save`. Setting that does stop this from happening, yes. If this was the package default that would resolve the issue I have. But that would not address the original filer's issue (unnecessary chain DOCKER-USER creation, which I can reproduce). I should have filed a separate issue really, sorry. I've cloned now. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄
Bug#903635: docker.io: use of iptables-legacy is incompatible with nftables-based iptables
On Sat, Jun 08, 2019 at 10:13:03PM -0400, Afif Elghraoui wrote: I don't understand... I thought the whole point of making a bug release-critical is to keep the bug out of the release (either by having it fixed or removing the package). No, that's not the point; it's the consequence. There are clear criteria for the bug categories, "breaks unrelated software" is one of them and what is happening here. if you want to pursue a buster-ignore tag, someone please contact the release team and make it happen. https://www.debian.org/Bugs/Developer says explicit authorization is needed from the release managers, but I'd worry that an email to debian-rele...@lists.debian.org might get lost and it'd be weird to file a bug on release.debian.org asking to apply a tag to another bug. Someone should indeed do this. I might get around to it, but I can't promise, I'm very busy this week. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Bug#907135: [Box Backup] Debian now requires 2048bit RSA keys
Hi Reinhard, I don't blame you. I think that for Debian to upgrade a package, changing a global setting, break some of its dependencies, and then kick out the resulting broken packages a month later (nearly a year before the expected release date) seems pretty harsh. In this case it took me 4.5 months to fix the issue from when you reported it to me, so unless a package has at least one full-time developer, a month simply isn't enough to fix this issue. Not even close for a hobbyist like myself. Thanks, Chris. On Sun, 9 Jun 2019 at 23:26, Reinhard Tartler wrote: > Agreed! > > In this case, the bug was reported on Aug 24 2018 by Adrian Bunk. It was > removed about a months later, namely on September 23, for failing to build > from source. Four weeks is arguably quite fast. Or quite slow, depending on > whom you talk to. > > I probably could have reacted by disabling the test suite. Or by prodding > you in those four weeks harder. Or at last have the bug fixed by end of > last year, which would have left enough time to re-migrate to testing. In > the future, I'll know better. > > Again, sorry. I'm happy to help with getting the package to > buster-backports once it opens. > > -rt > > On Sun, Jun 9, 2019 at 5:29 PM Chris Wilson > wrote: > >> Hi all, >> >> It seems a bit egregious to kick out packages that were broken by a minor >> version upgrade in one of their dependencies (which after all is not >> supposed to break anything), without any warning, let alone time to fix >> such a complex issue properly. >> >> I hope that Debian will consider carefully whether this course of action >> was really in the best interests of its users. >> >> Thanks, Chris. >> > > -- > regards, > Reinhard >
Bug#930301: RM: liguidsoap [all] -- RoQA; NBS; obsolete arch:all package
Package: ftp.debian.org Severity: normal liguidsoap is arch:all cruft liguidsoap | 1.1.1-7.2 | unstable | all liquidsoap | 1.1.1-7.2 | unstable | source liquidsoap | 1.3.4-1 | unstable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x liquidsoap-mode | 1.3.4-1 | unstable | all Andreas
Bug#930300: libghc-argon2-dev: switch dependency to libargon2-dev
Package: libghc-argon2-dev Version: 1.3.0.1-4 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: affects -1 + libghc-argon2-prof Hi, during a test with piuparts I noticed your package causes problems during the upgrade from stretch to buster. >From the attached log (scroll to the bottom...): ... Starting 2 pkgProblemResolver with broken count: 4 Investigating (0) libargon2-0-dev:amd64 < 0~20160821-1+b1 @ii mK Ib > Broken libargon2-0-dev:amd64 Depends on libargon2-0:amd64 < 0~20160821-1+b1 -> 0~20171227-0.2 @ii umU > (= 0~20160821-1+b1) Considering libargon2-0:amd64 0 as a solution to libargon2-0-dev:amd64 0 Removing libargon2-0-dev:amd64 rather than change libargon2-0:amd64 Investigating (1) libghc-argon2-dev:amd64 < 1.2.0-3+b1 -> 1.3.0.1-4+b2 @ii umU Ib > Broken libghc-argon2-dev:amd64 Depends on libargon2-0-dev:amd64 < 0~20160821-1+b1 @ii mR > Considering libargon2-0-dev:amd64 0 as a solution to libghc-argon2-dev:amd64 1 Added libargon2-0-dev:amd64 to the remove list Fixing libghc-argon2-dev:amd64 via keep of libargon2-0-dev:amd64 Investigating (1) libargon2-0-dev:amd64 < 0~20160821-1+b1 @ii mK Ib > Broken libargon2-0-dev:amd64 Depends on libargon2-0:amd64 < 0~20160821-1+b1 -> 0~20171227-0.2 @ii umU > (= 0~20160821-1+b1) Considering libargon2-0:amd64 0 as a solution to libargon2-0-dev:amd64 0 Removing libargon2-0-dev:amd64 rather than change libargon2-0:amd64 Investigating (2) libghc-argon2-dev:amd64 < 1.2.0-3+b1 -> 1.3.0.1-4+b2 @ii umU Ib > Broken libghc-argon2-dev:amd64 Depends on libargon2-0-dev:amd64 < 0~20160821-1+b1 @ii mR > Considering libargon2-0-dev:amd64 0 as a solution to libghc-argon2-dev:amd64 1 Added libargon2-0-dev:amd64 to the remove list Fixing libghc-argon2-dev:amd64 via keep of libargon2-0-dev:amd64 Investigating (2) libargon2-0-dev:amd64 < 0~20160821-1+b1 @ii mK Ib > Broken libargon2-0-dev:amd64 Depends on libargon2-0:amd64 < 0~20160821-1+b1 -> 0~20171227-0.2 @ii umU > (= 0~20160821-1+b1) Considering libargon2-0:amd64 0 as a solution to libargon2-0-dev:amd64 1 Added libargon2-0:amd64 to the remove list Fixing libargon2-0-dev:amd64 via keep of libargon2-0:amd64 Try to Re-Instate (2) libargon2-0:amd64 Done ... The following packages have been kept back: libargon2-0 ... apt does not find a proper upgrade path switching from the installed real libargon2-0-dev package to the virtual one provided by libargon2-dev. Please switch the dependency from libargon2-0-dev to libargon2-dev. cheers, Andreas libghc-argon2-prof_1.3.0.1-4+b2.log.gz Description: application/gzip
Bug#930299: apt: A warning "Ignoring Provides line with non-equal DepCompareOp for package" for two packages
Package: apt Version: 1.8.2 Severity: normal Dear Maintainer, After yesterday's apt-get update, I get this message everytime I run it W: Ignoring Provides line with non-equal DepCompareOp for package firefox-l10n-bn-bd W: Ignoring Provides line with non-equal DepCompareOp for package firefox-l10n-bn-in And I am pretty sure I saw it on some output of apt-cache. Everything else works fine however, so it is just a minor issue for these 2 packages I guess. -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "0"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-source-4\.19\.0-5-amd64$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-modules"; APT::VersionedKernelPackages:: "linux-modules-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "linux-image-unsigned"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::VersionedKernelPackages:: "linux-cloud-tools"; APT::VersionedKernelPackages:: "linux-buildinfo"; APT::VersionedKernelPackages:: "linux-source"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::Default-Release "testing"; APT::AutoRemove ""; APT::AutoRemove::SuggestsImportant "false"; APT::AutoRemove::RecommendsImportant "false"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::zstd ""; APT::Compressor::zstd::Name "zstd"; APT::Compressor::zstd::Extension ".zst"; APT::Compressor::zstd::Binary "false"; APT::Compressor::zstd::Cost "60"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "xz"; APT::Compressor::xz::Cost "200"; APT::Compressor::xz::CompressArg "";
Bug#930297: unblock: fastforward/1:0.51-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package fastforward diff -Nru fastforward-0.51/debian/changelog fastforward-0.51/debian/changelog --- fastforward-0.51/debian/changelog 2019-01-13 00:29:15.0 +0100 +++ fastforward-0.51/debian/changelog 2019-05-28 09:09:15.0 +0200 @@ -1,3 +1,13 @@ +fastforward (1:0.51-6) unstable; urgency=medium + + * QA upload. + * Bump version to 1:0.51-6 to not reuse a version number that was used +before the epoch was added (last pre-epoch upload was 0.51-5.1). This +avoids clashes on filenames in the archive (versions in filenames don't +include the epoch). + + -- Andreas Beckmann Tue, 28 May 2019 09:09:15 +0200 + fastforward (1:0.51-4) unstable; urgency=medium * QA upload. diff -Nru fastforward-0.51/debian/.gitlab-ci.yml fastforward-0.51/debian/.gitlab-ci.yml --- fastforward-0.51/debian/.gitlab-ci.yml 1970-01-01 01:00:00.0 +0100 +++ fastforward-0.51/debian/.gitlab-ci.yml 2019-05-28 09:09:15.0 +0200 @@ -0,0 +1,5 @@ +include: + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml +variables: + RELEASE: experimental The .gitlab-ci.yml was already committed in the git repository. unblock fastforward/1:0.51-6
Bug#930298: unblock: dot-forward/1:0.71-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package dot-forward diff -Nru dot-forward-0.71/debian/changelog dot-forward-0.71/debian/changelog --- dot-forward-0.71/debian/changelog 2019-01-11 21:46:13.0 +0100 +++ dot-forward-0.71/debian/changelog 2019-05-28 01:50:05.0 +0200 @@ -1,3 +1,13 @@ +dot-forward (1:0.71-5) unstable; urgency=medium + + * QA upload. + * Bump version to 1:0.71-5 to not reuse a version number that was used +before the epoch was added (last pre-epoch upload was 0.71-4). This avoids +clashes on filenames in the archive (versions in filenames don't include +the epoch). + + -- Andreas Beckmann Tue, 28 May 2019 01:50:05 +0200 + dot-forward (1:0.71-3) unstable; urgency=medium * QA upload. diff -Nru dot-forward-0.71/debian/.gitlab-ci.yml dot-forward-0.71/debian/.gitlab-ci.yml --- dot-forward-0.71/debian/.gitlab-ci.yml 1970-01-01 01:00:00.0 +0100 +++ dot-forward-0.71/debian/.gitlab-ci.yml 2019-05-28 01:50:05.0 +0200 @@ -0,0 +1,5 @@ +include: + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml +variables: + RELEASE: experimental unblock dot-forward/1:0.71-5 Andreas
Bug#930296: RM: git-core [all] -- RoQA; NBS; obsolete arch:all package; provided by git
Package: ftp.debian.org Severity: normal Please clean up the obsolete transitional git-core package. All rdepends are satisfied by the Provides in git. Thanks. Andreas
Bug#930005: regina-rexx: rexxutil error
Package: libregina3 Version: 3.6-2.1 Followup-For: Bug #930005 Dear Maintainer, I took a look at this since I thought it would be a simple `-ltinfo` fix, but it's more complicated than that. As it is, the package can't possibly run on 64-bit platforms. There are a *lot* of dangerous warnings; somebody needs to build with -Werror and fix all of them. This would be a very invasive patch. If upstream is dead, perhaps the package should simply be removed from Debian. -Ben
Bug#902174: #902174: RFP: mes
Vagrant Cascadian writes:
Hi!
> Mes itself still fails to build, but I updated to 0.19, and made a
> branch based off of janneke's wip branch as well
> (debian/master-wip). configure fails to detect nyacc. It may be an issue
> with multi-arch paths (e.g. /usr/lib/guile/2.2
> vs. /usr/lib/x86_64-linux-gnu/guile/2.2).
Oops, that looks like a bug, thanks. I hope it's harmless...
> Many of the '#! /bin/sh' scripts contain bashisms which may not be
> compatible with Debian's (usual) /bin/sh, dash after a quick check with
> "checkbashisms". I could patch all the #! headers and audit all the
> calls to "sh" directly, but that seems a bit unmaintainable in the
> long-run.
Sure, this needs to be fixed; I'll look into it, thanks.
> Will need to do some better troubleshooting later... but this appears to
> be the last build failure i tried based on the wip branch:
>
> ../pre-inst-env mescc -m 64 -c -D HAVE_CONFIG_H=1 -I include -I
> ../include -I ../include/linux/x86_64 -static -o crt1.o
> ../lib/linux/x86_64-mes-mescc/crt1.c
> unhandled exception:unbound-variable:(move-specl-attr)
> Backtrace:
> /<>/scripts/mescc: line 56: 24904 Segmentation fault
> ${SCHEME-$MES} --no-auto-compile -e main -L /usr/share/guile/site/2.2 -C
> /usr/lib/guile/2.2/site-ccache $bindir/mescc.scm $sep "$@"
> make[1]: *** [GNUmakefile:95: build] Error 139
This could be a problem with Nyacc 0.93.0, find a patch attached for
that.
Thank you,
Greetings, janneke
>From b3fa6273210200cf2694491b07ed5a328e9a4e62 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen
Date: Sun, 9 Jun 2019 19:42:42 +0200
Subject: [PATCH] mes: Update to Nyacc 0.93.
* mes/module/nyacc/lang/c99/util.mes: New file.
* mes/module/nyacc/lang/c99/parser.mes: Use it.
* module/mescc/compile.scm (ast->info): Update for Nyacc 0.93.0.
* module/mescc/preprocess.scm (need-progress): Likewise.
(ast-strip-comment): Likewise.
---
mes/module/nyacc/lang/c99/parser.mes | 3 +-
mes/module/nyacc/lang/c99/util.mes | 45
module/mescc/compile.scm | 4 +++
module/mescc/preprocess.scm | 3 +-
4 files changed, 53 insertions(+), 2 deletions(-)
create mode 100644 mes/module/nyacc/lang/c99/util.mes
diff --git a/mes/module/nyacc/lang/c99/parser.mes b/mes/module/nyacc/lang/c99/parser.mes
index 1a9aaf732..9fbb5fd1e 100644
--- a/mes/module/nyacc/lang/c99/parser.mes
+++ b/mes/module/nyacc/lang/c99/parser.mes
@@ -1,7 +1,7 @@
;;; -*-scheme-*-
;;; GNU Mes --- Maxwell Equations of Software
-;;; Copyright © 2016,2017 Jan (janneke) Nieuwenhuizen
+;;; Copyright © 2016,2017,2019 Jan (janneke) Nieuwenhuizen
;;;
;;; This file is part of GNU Mes.
;;;
@@ -35,5 +35,6 @@
(mes-use-module (nyacc lang sx-util))
(mes-use-module (nyacc lang util))
(mes-use-module (nyacc lang c99 cpp))
+(mes-use-module (nyacc lang c99 util))
(include-from-path "nyacc/lang/c99/parser.scm")
diff --git a/mes/module/nyacc/lang/c99/util.mes b/mes/module/nyacc/lang/c99/util.mes
new file mode 100644
index 0..b4e24885a
--- /dev/null
+++ b/mes/module/nyacc/lang/c99/util.mes
@@ -0,0 +1,45 @@
+;;; -*-scheme-*-
+
+;;; GNU Mes --- Maxwell Equations of Software
+;;; Copyright © 2019 Jan (janneke) Nieuwenhuizen
+;;;
+;;; This file is part of GNU Mes.
+;;;
+;;; GNU Mes is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Mes is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Mes. If not, see
Bug#927267: nitroshare: Nitroshare on pc is undiscoverable by nitroshare on mobile, and vice versa, due to old version
Package: nitroshare Version: 0.3.3-1.1 Followup-For: Bug #927267 I think its severity should be raised to grave, since it does make the package unsusable. There is also a issue report on the project's github page by a kubuntu user who has exactly the same issue. -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nitroshare depends on: ii libappindicator1 0.4.92-7 ii libatk1.0-0 2.30.0-2 ii libc62.28-10 ii libcairo21.16.0-4 ii libdbusmenu-glib418.10.20180917~bzr490+repack1-1 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2 ii libgtk2.0-0 2.24.32-3 ii libnotify4 0.7.7-4 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpangoft2-1.0-01.42.4-6 ii libqhttpengine0 0.1.0+dfsg1-1+b2 ii libqt5core5a 5.11.3+dfsg1-1 ii libqt5gui5 5.11.3+dfsg1-1 ii libqt5network5 5.11.3+dfsg1-1 ii libqt5svg5 5.11.3-2 ii libqt5widgets5 5.11.3+dfsg1-1 ii libstdc++6 8.3.0-6 nitroshare recommends no packages. Versions of packages nitroshare suggests: pn nitroshare-nautilus -- no debconf information
