Bug#866472: Uniconvertor 2.0 upstream depends on python-pil and has some .debs
Hello. Maybe you know already (because the problem seems to be lack of maintainer). But there is a python-uniconvertor 2.0 that no longer depends on python-imaging but on python-pil (python2, I believe) https://sk1project.net/modules.php?name=Products&product=uniconvertor&op=download They offer source and some .debs for a couple architechtures and Debian 9, but I haven't tried them or audited the licenses or anything. I suppose it would still require packaging. Unfortunately I don't know enough about debian policies or about python. I might try to learn, but I think Debian is frozen now ?
Bug#930618: node-terser does not install file mentioned in package.json's main field and fails Error: Cannot find module 'terser'
On 2019, ജൂൺ 20 5:08:24 PM IST, Xavier wrote: >Hello, > >there is something wrong with your patch: >W: node-terser source: binaries-have-file-conflict node-terser >uglifyjs.terser usr/lib/nodejs/terser/dist/bundle.js > >Your link overrides a regular file Only node-terser should include this file, uglifyjs.terser already depends on node-terser. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Processed: bug 883731 has no owner
Processing commands for cont...@bugs.debian.org:
> noowner 883731
Bug #883731 {Done: Andrej Shadura } [audacious] audacious:
Debian packaging has incorrect license
Removed annotation that Bug was owned by Nicholas D Steeves
.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
883731: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883731
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#930693: ksh: previous versions have the info
Processing control commands: > severity -1 important Bug #930693 [ksh] ksh: no Source field in copyright file Severity set to 'important' from 'serious' > fixed -1 2020.0.0~alpha1-1~exp1 Bug #930693 [ksh] ksh: no Source field in copyright file Marked as fixed in versions ksh/2020.0.0~alpha1-1~exp1. -- 930693: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930693 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#930693: ksh: previous versions have the info
Control: severity -1 important Control: fixed -1 2020.0.0~alpha1-1~exp1 在 2019-06-18二的 17:30 -0400，Greg Wooledge写道： > Having ksh removed from buster is definitely not my preferred outcome. > Getting one line added to the copyright file would be ideal, but if > that's not allowed, then I can live with "fixed after buster". Doing so accordingly. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#916310: New maintainers
Hello everyone, At https://salsa.debian.org/phpmyadmin-team/phpmyadmin/project_members new members have joined the team and a new version is available (4.9.0.1) : https://tracker.debian.org/action-items/776413 I just wanted to keep you updated and to let you know that some work is being done to repair the package (patches and new versions..). You can browse https://salsa.debian.org/groups/phpmyadmin-team/-/issues to see what is going on and follow the progress. I also joined the team https://salsa.debian.org/phpmyadmin-team as a phpMyAdmin team member. Regards, William Desportes signature.asc Description: OpenPGP digital signature
Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language
Control: tags -1 + buster-ignore Hello, Holger Wansing, le jeu. 20 juin 2019 10:31:39 +0200, a ecrit: > ButterflyOfFire wrote: > > I think it is okay for those diacritics. > > I have uploaded that fix now. Thanks! > Leaving this bug open as a reminder for the "real" problem inside of gtk (?) Tagging accordingly. To gtk+2.0 maintainers: the debian installer is getting hung inside the graphical debconf (and not in the textual debconf) when trying to make gtk+2.0 display "لاحقاً" and we have replaced it with "لاحقا" as a workaround for Buster, but we'll have to fix this bug eventually. Samuel
Processed: Re: Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language
Processing control commands: > tags -1 + buster-ignore Bug #929877 [installation-reports] installation-reports: Buster installer hangs at hard disk step with arabic language Added tag(s) buster-ignore. -- 929877: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929877 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1
Package: hdparm Version: 9.58+ds-1 Severity: serious Dear Maintainers, In this version of hdparm, a new option 'force_spindown_time' was introduced to set the spindown time for disks that don't support APM. This option is supposed to translate to hdparm -S, similarly to the original option 'spindown_time'. hdparm package comes with 3 main scripts: 1) /usr/lib/pm-utils/power.d/95hdparm-apm This script will translate 'force_spindown_time' to hdparm -S and apply the option even if APM was not detected. This is the desired behavior. 2) /etc/apm/event.d/20hdparm This script will ignore /etc/hdparm.conf and apply hard-coded defaults instead. This behavior is unexpected. Expected/Desired behavior: Read /etc/hdparm.conf and apply relevant options. 3) /lib/hdparm/hdparm-functions (sourced from /lib/udev/hdparm, which is invoked by udev rule /lib/udev/rules.d/85-hdparm.rules) - 'force_spindown_time' is buggy because it is not converted back to -S, which leads to a syntax error during hdparm execution (e.g. hdparm force_spindown_time$VALUE instead of hdparm -S$VALUE). - Both options 'spindown_time' and 'force_spindown_time' are processed even if APM is not supported. From the comments in the configuration file (/etc/hdparm.conf), it is understood that 'spindown_time' will be applied for APM disks only and 'force_spindown_time' for all disks (or possibly for non-APM disks only). - The scripts will also apply hard-coded defaults for -S and -B if APM was detected. The hard-coded defaults differ from those used in /etc/apm/event.d/20hdparm, leading to inconsistent behavior. 4) Additional issues with non-APM disks: - Manually invoking hdparm -S$VALUE /dev/sdx is simply ignored even though hdparm executes successfully. The disks do not spin down after the time delay when there was no access. - Manually invoking hdparm -y /dev/sdx will spin down the disks immediately. The disks will not wake up unless they are accessed, which is the expected behavior. These were all working fine in hdparm 9.51+ds-1+deb9u1, which is the current version in stretch. In short, it is currently impossible to obtain a consistent and working configuration for non-APM disks. Many thanks and regards, Sebastien Behuret
Bug#928214: marked as done (mingw-w64 GCC is built without linker plugin support making LTO unusable)
Your message dated Thu, 20 Jun 2019 16:34:01 +
with message-id
and subject line Bug#928214: fixed in gcc-mingw-w64 21.3~deb10u1
has caused the Debian Bug report #928214,
regarding mingw-w64 GCC is built without linker plugin support making LTO
unusable
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
928214: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928214
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: gcc-mingw-w64
Version: 21.2
Hi!
I've discovered that mingw-w64 GCC in Debian is configured without
linker plugin support:
$ x86_64-w64-mingw32-gcc -x c - -flto -fno-fat-lto-objects <<<'int
main() {}'
cc1: error: -fno-fat-lto-objects are supported only with linker plugin
This makes LTO unusable in many real-world cases. Consider the following
example:
$ grep . *.c
foo.c:int foo() {return 42;}
main.c:int main() {return foo();}
$ x86_64-w64-mingw32-gcc -flto -O2 foo.c main.c -c
$ x86_64-w64-mingw32-ar cr app.a main.o foo.o
$ x86_64-w64-mingw32-gcc -flto -O2 app.a
$ x86_64-w64-mingw32-objdump -d a.exe | grep ':' -A 5
00402c30 :
402c30: 48 83 ec 28 sub$0x28,%rsp
402c34: e8 d7 e9 ff ff callq 401610 <__main>
402c39: 90 nop
402c3a: 48 83 c4 28 add$0x28,%rsp
402c3e: e9 0d e9 ff ff jmpq 401550 # 'foo' is
not inlined
Note that 'foo' is not inlined because the archived object files weren't
processed by LTO (they were processed by the linker as normal objects
because they are "fat" LTO objects, i.e. they contain both normal object
code and GCC IR).
$ x86_64-w64-mingw32-gcc -flto -O2 main.o foo.o
$ x86_64-w64-mingw32-objdump -d a.exe | grep ':' -A 5
00402c30 :
402c30: 48 83 ec 28 sub$0x28,%rsp
402c34: e8 d7 e9 ff ff callq 401610 <__main>
402c39: b8 2a 00 00 00 mov$0x2a,%eax # Good, 'foo'
is inlined!
402c3e: 48 83 c4 28 add$0x28,%rsp
402c42: c3 retq
In this case, legacy LTO implementation was used: GCC driver looked at
the objects and called its 'lto-wrapper' helper. But it can't do that
with archives.
This misconfiguration is caused by the incorrect use of
'--with-plugin-ld' GCC configure option (or its strange behavior,
depending on how you look at it):
$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu
--prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man'
--infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu'
--libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode
--disable-dependency-tracking --prefix=/usr --enable-shared
--enable-static --disable-multilib --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib
--enable-libstdcxx-time=yes --with-tune=generic
--with-headers=/usr/x86_64-w64-mingw32/include
--enable-version-specific-runtime-libs --enable-fully-dynamic-string
--enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada
--enable-lto --with-plugin-ld --enable-threads=win32
--program-suffix=-win32 --program-prefix=x86_64-w64-mingw32-
--target=x86_64-w64-mingw32 --with-as=/usr/bin/x86_64-w64-mingw32-as
--with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic
--enable-libstdcxx-filesystem-ts=yes
Thread model: win32
gcc version 8.3-win32 20190406 (GCC)
The problem is that "--with-plugin-ld" expects a linker path as the
value, but if it's not given, the value becomes 'yes' and is then tested
for plugin support, without much success (lookup "checking linker plugin
support" in
"https://buildd.debian.org/status/fetch.php?pkg=gcc-mingw-w64&arch=amd64&ver=21.2&stamp=1555227419&raw=0";).
This option is actually not needed since there is no need to use an
"alternative" linker for plugins: the one that is passed with
"--with-ld" will do. I've checked manually that if I remove
"--with-plugin-ld" from the configuration of gcc-mingw-w64 source
package, the linker plugin support is detected properly.
Ubuntu packages are also affected by this problem. I've checked that
OpenSUSE Tumbleweed packages are not affected (they don't use
"--with-plugin-ld").
I suggest to remove "--with-plugin-ld" from GCC configuration options.
Thanks!
-Alexey
--- End Messag
Bug#930722: arc, arcanist: Both ship arc binary
On Wed, Jun 19, 2019 at 06:23:51AM -0700, Sylvestre Ledru wrote: > > Le 19/06/2019 à 12:14, Julian Andres Klode a écrit : > > Package: arc,arcanist > > Severity: serious > > > > arc: /usr/bin/arc > > arcanist: /usr/bin/arc > > > > One of them needs to be renamed, or both. > > Or change the Debian policy as it is a waste of our time... and no gain for > the user. ;) I guess arcanist will also become irrelevant once KDE gets rid of that phabricator nuisance. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#930774: guile-2.2: FTBFS when built with dpkg-buildpackage -A
Santiago Vila writes: > To reproduce please try "dpkg-buildpackage -A". Thanks. I should have time to work on this over the weekend. > While we are at it, uploading in source-only form (dpkg-buildpackage -S) > helps a lot > to discover these kind of bugs sooner. Right -- that's what I intend to be doing, but I must have forgotten to use the right arguments this time. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Processed: limit package to itstool, severity of 918953 is serious
Processing commands for cont...@bugs.debian.org: > limit package itstool Limiting to bugs with field 'package' containing at least one of 'itstool' Limit currently set to 'package':'itstool' > severity 918953 serious Bug #918953 [itstool] itstool: Messed up with encoding when output is redirected (regression?) Severity set to 'serious' from 'important' > thanks Stopping processing here. Please contact me if you need assistance. -- 918953: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918953 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Preserving the rather large CC list for now… On Thu, Jun 20, 2019 at 06:05:22AM -0400, Sam Hartman wrote: I feel very uncomfortable with a change as big as this revert happening this late in the release cycle. How big is big? The MR I raised resurrects a patch that changes one line of code, and was shipped in the last stable release. Although it looks like further work is needed to make the change as smooth as possible so this would grow. However, the patch certainly needs more testing. Is the issue that it results in a large change in terms of what software is executed by the user as a consequence, and what of that has been tested thus far in the freeze? How late is late? How would you have felt about it back in early April, when I first raised it? I was surprised to discover it then, and I felt it was late in the cycle even then. But mostly whats happened since is nothing. I absolutely do not blame the GNOME team here. Simon McVittie and Michael Biebl in particular have taken risks sticking their heads above the parapet to engage with me on this matter, and both have made it clear that it would be unreasonable for them to make the call given their respective levels of involvement. I respect that, and I am extremely grateful for them engaging with the issue. The others are either too busy or have taken a decision not to engage with a potentially toxic issue, and I respect that, too: we are all volunteers who have to make our own choices about what we are prepared to do and engage in. Besides, like many teams, the GNOME team is clearly under-resourced. I am a *little* disappointed that this does not seem to have been thought of as an important, project-wide issue. Regardless of whether one uses GNOME or Wayland oneself, the matter of the default desktop for the distribution we are all working to produce, and the experience that our users will get out of the box, I would have thought was important for all of us. It reinforces the idea, to me, that we are largely working in our own silos, and not concerned (enough) about the holistic distribution as a whole. And yet, the lack of a clear reconfirmation in this time line even given the wonderfully civil discussion is telling. I'm very pleased that the discussion has come across as civil. I've tried really hard from my end to achieve that, I know that issues around GNOME can result in some very toxic communications. My proposal--which again I have no power to implement--is that we go forward with the current default. However, we remain open to a revert in the first couple of buster point releases. There are caveats with switching the default in either direction. Let's say we go with Wayland now, and later decide to switch as per the criteria/process you sketch below. • users of the default, who got Wayland from Buster onwards and had no problems, would subsequently find themselves switched to Xorg by stable-updates, which IMHO would be unexpected (if noticed) and contrary to the expectations of a stable release. • A user who installed or upgraded and got Wayland by default but had problems, would have likely addressed them by switching to the Xorg session explicitly (assuming they could figure out that doing so mitigated their issues). Changing the default would only prevent *future* users from hitting the same problems. The criteria for that revert should be based on the actual severity and frequence of problems our users run into, but should specifically exclude the blanket reluctance to make a change like that in a point release. We would still need adequate testing of such a revert. My concern with this is it's a new set of policies and procedures, not codified anywhere, with a lot of detail to work out "on the hoof" (how do we measure frequency of problems? do we go with the existing bug severity guidelines? How much is adequate testing? etc.) So combined with the user experience above, I think we would be best not to change the default within a stable release cycle, unless there was some kind of enormous catastrophic issue with Wayland that we don't know about yet, and that's unlikely. I still argue that the traditional Debian conservative, when-its-ready approach would be the distribution status quo (Xorg), but I recognise the concerns about the proposed patch, further work needed, lack of testing etc.; and those are not issues I think I can resolve alone. -- Jonathan Dowland
Bug#919690: marked as done (ionit runs too late for /etc/network/interfaces)
Your message dated Thu, 20 Jun 2019 14:39:15 + with message-id and subject line Bug#919690: fixed in ionit 0.3.2+really0.2.1-1 has caused the Debian Bug report #919690, regarding ionit runs too late for /etc/network/interfaces to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 919690: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919690 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: ifupdown Version: 0.8.34 Severity: important Hi, I have a Debian live system (using live-boot) launched in QEMU with a static network configuration. live-boot brings up the network interface ens3 in the initrd to fetch the squashfs root image. The ifup@ens3.service fails: ``` $ systemctl status ifup@ens3.service ● ifup@ens3.service - ifup for ens3 Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2019-01-18 15:26:29 UTC; 9min ago Process: 696 ExecStart=/bin/sh -ec ifup --allow=hotplug ens3; ifquery --state ens3 (code=exited, status=1/FAILURE) Main PID: 696 (code=exited, status=1/FAILURE) Jan 18 15:26:29 systemd[1]: Started ifup for ens3. Jan 18 15:26:29 systemd[1]: ifup@ens3.service: Main process exited, code=exited, status=1/FAILURE Jan 18 15:26:29 systemd[1]: ifup@ens3.service: Failed with result 'exit-code'. ``` Adding --verbose to ifup and ifquery revealed that ifquery fails with exit code 1, but does not produce any output. The journal shows that ifup@ens3.service exits before ens3 is ready: ``` Jan 18 15:26:29 systemd[1]: Started ifup for ens3. Jan 18 15:26:29 systemd[1]: ifup@ens3.service: Main process exited, code=exited, status=1/FAILURE Jan 18 15:26:29 systemd[1]: ifup@ens3.service: Failed with result 'exit-code'. Jan 18 15:26:30 systemd-udevd[491]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Jan 18 15:26:30 systemd-udevd[491]: Could not generate persistent MAC address for ethoipsix0: No such file or directory Jan 18 15:26:30 kernel: IPv6: ADDRCONF(NETDEV_UP): ens3: link is not ready Jan 18 15:26:30 kernel: e1000: ens3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Jan 18 15:26:30 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): ens3: link becomes ready ``` -- Package-specific info: --- /etc/network/interfaces: # interfaces(5) file used by ifup(8) and ifdown(8) # Include files from /etc/network/interfaces.d: source-directory /etc/network/interfaces.d # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto ens3 iface ens3 inet static address 10.91.240.1/22 pre-up ip address flush dev $IFACE up ip route add 10.0.0.0/8 via 10.91.243.254 dev $IFACE up ip route add 192.168.0.0/16 via 10.91.243.254 dev $IFACE up sysctl -w net.ipv4.conf.ens3.forwarding=0 --- up and down scripts installed: /etc/network/if-down.d: total 1 -rwxr-xr-x 1 root root 256 Apr 1 2016 resolvconf /etc/network/if-post-down.d: total 0 /etc/network/if-pre-up.d: total 1 -rwxr-xr-x 1 root root 344 Jun 30 2016 ethtool /etc/network/if-up.d: total 3 -rwxr-xr-x 1 root root 817 Apr 1 2016 000resolvconf -rwxr-xr-x 1 root root 1685 Jun 30 2016 ethtool -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ifupdown depends on: ii adduser 3.118 ii iproute2 4.20.0-2 ii libc6 2.28-5 ii lsb-base 10.2018112800 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.4.1-2 Versions of packages ifupdown suggests: pn ppp pn rdnssd -- no debconf information --- End Message --- --- Begin Message --- Source: ionit Source-Version: 0.3.2+really0.2.1-1 We believe that the bug you reported is fixed in the latest version of ionit, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 919...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Benjamin Drung (supplier of updated ionit package) (This message was generated automatically at their request; if you believe that there is a problem wi
Bug#930387: rdekstop: security issues fixed in 1.8.5 and 1.8.6
On Tue, Jun 11, 2019 at 09:22:30PM +0200, Salvatore Bonaccorso wrote: > Source: rdesktop > Version: 1.8.4-1 > Severity: grave > Tags: security upstream fixed-upstream > Justification: user security hole > Control: fixed -1 1.8.6-1 > > Hi > > 1.8.6-1 mentions a new upstream release with many security fixes, but > none of those apparently have (yet) a CVE. Filling this bug for having > an unique identifier for the tracker in meanwhile. > > Reference: > https://tracker.debian.org/news/1041036/accepted-rdesktop-186-1-source-into-unstable/ AFAICS there is not clear information on which issues are fixed exactly, https://groups.google.com/forum/#!topic/rdesktop-announce/czgpKDfm2D0 is a bit scarce on information. Probably if we are going to release a stretch-security update it might be worth doing an import of 1.8.6 for the security update itself and moving from 1.8.4-1~deb9u1 to the new upstream version. Regards, Salvatore
Bug#930671: libauthen-radius-perl: most basic usage stopped working
Control: tag -1 patch
Control: forwarded -1 https://rt.cpan.org/Ticket/Display.html?id=129869
On Wed, Jun 19, 2019 at 08:27:51PM +0300, Niko Tyni wrote:
> On Tue, Jun 18, 2019 at 10:52:03AM +0200, Ferenc Wágner wrote:
> > Package: libauthen-radius-perl
> > Version: 0.29-1
> > Severity: important
>
> > I recently upgraded to buster and noticed that our RADIUS test plugin
> > does not work anymore. Downgrading libauthen-radius-perl to 0.27-1
> > fixes the issue. Take the first example from the top of the man page:
> >
> > use Authen::Radius;
> > $r = new Authen::Radius(Host => 'myserver', Secret => 'mysecret');
> > print "auth result=", $r->check_pwd('myname', 'mypwd'), "\n";
> > unknown attr name 1 at /usr/share/perl5/Authen/Radius.pm line 865.
> This needs to be reported and fixed upstream; I'll look at it in the
> next few days unless someone else beats me to it.
I've reported this upstream with the attached proposed patch.
Will wait a bit before applying the patch for Debian in case upstream
has comments.
--
Niko Tyni nt...@debian.org
>From ba0078591c35d1d6a404828aab9d06fb43c4d5fc Mon Sep 17 00:00:00 2001
From: Niko Tyni
Date: Thu, 20 Jun 2019 16:43:30 +0300
Subject: [PATCH] Fix 0.28 regression with check_pwd()
add_attributes() is documented to accept raw numeric attributes,
and check_pwd() uses those.
Bug-Debian: https://bugs.debian.org/930671
---
Radius.pm | 3 ++-
t/error.t | 13 -
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/Radius.pm b/Radius.pm
index fd0a6c9..3497e99 100644
--- a/Radius.pm
+++ b/Radius.pm
@@ -862,7 +862,8 @@ sub add_attributes {
$attr_name = $1;
}
-die 'unknown attr name '.$attr_name if (! exists $dict_name{$attr_name});
+die 'unknown attr name '.$attr_name
+if ($attr_name =~ /\D/ and ! exists $dict_name{$attr_name});
$id = $dict_name{$attr_name}{id} // int($attr_name);
$vendor = vendorID($attr);
diff --git a/t/error.t b/t/error.t
index 6a02cb3..e1c8f5f 100644
--- a/t/error.t
+++ b/t/error.t
@@ -1,6 +1,6 @@
use strict;
use warnings;
-use Test::More tests => 9;
+use Test::More tests => 12;
use Test::NoWarnings;
BEGIN { use_ok('Authen::Radius') };
@@ -17,3 +17,14 @@ ok( $auth->clear_attributes, 'clear attributes');
is($auth->get_error(), 'ENONE', 'error was reset');
is(Authen::Radius->get_error(), 'ENONE', 'global error also reset');
+
+my @attributes = (
+{ Name => 1, Value => 'user', Type => 'string' },
+{ Name => 2, Value => 'pass', Type => 'string' },
+{ Name => 4, Value => '127.0.0.1', Type => 'ipaddr' }
+);
+
+# called by check_pwd()
+ok( $auth->add_attributes(@attributes), 'add attributes');
+is($auth->get_error(), 'ENONE', 'no error with add_attributes');
+is(Authen::Radius->get_error(), 'ENONE', 'no global error either');
--
2.20.1
Processed: Re: Bug#930671: libauthen-radius-perl: most basic usage stopped working
Processing control commands: > tag -1 patch Bug #930671 [libauthen-radius-perl] libauthen-radius-perl: most basic usage stopped working Added tag(s) patch. > forwarded -1 https://rt.cpan.org/Ticket/Display.html?id=129869 Bug #930671 [libauthen-radius-perl] libauthen-radius-perl: most basic usage stopped working Set Bug forwarded-to-address to 'https://rt.cpan.org/Ticket/Display.html?id=129869'. -- 930671: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930671 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#930618: node-terser does not install file mentioned in package.json's main field and fails Error: Cannot find module 'terser'
Hello, there is something wrong with your patch: W: node-terser source: binaries-have-file-conflict node-terser uglifyjs.terser usr/lib/nodejs/terser/dist/bundle.js Your link overrides a regular file
Bug#919690: marked as done (ionit runs too late for /etc/network/interfaces)
Your message dated Thu, 20 Jun 2019 11:06:38 + with message-id and subject line Bug#919690: fixed in ionit 0.3.2-1 has caused the Debian Bug report #919690, regarding ionit runs too late for /etc/network/interfaces to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 919690: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919690 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: ifupdown Version: 0.8.34 Severity: important Hi, I have a Debian live system (using live-boot) launched in QEMU with a static network configuration. live-boot brings up the network interface ens3 in the initrd to fetch the squashfs root image. The ifup@ens3.service fails: ``` $ systemctl status ifup@ens3.service ● ifup@ens3.service - ifup for ens3 Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2019-01-18 15:26:29 UTC; 9min ago Process: 696 ExecStart=/bin/sh -ec ifup --allow=hotplug ens3; ifquery --state ens3 (code=exited, status=1/FAILURE) Main PID: 696 (code=exited, status=1/FAILURE) Jan 18 15:26:29 systemd[1]: Started ifup for ens3. Jan 18 15:26:29 systemd[1]: ifup@ens3.service: Main process exited, code=exited, status=1/FAILURE Jan 18 15:26:29 systemd[1]: ifup@ens3.service: Failed with result 'exit-code'. ``` Adding --verbose to ifup and ifquery revealed that ifquery fails with exit code 1, but does not produce any output. The journal shows that ifup@ens3.service exits before ens3 is ready: ``` Jan 18 15:26:29 systemd[1]: Started ifup for ens3. Jan 18 15:26:29 systemd[1]: ifup@ens3.service: Main process exited, code=exited, status=1/FAILURE Jan 18 15:26:29 systemd[1]: ifup@ens3.service: Failed with result 'exit-code'. Jan 18 15:26:30 systemd-udevd[491]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Jan 18 15:26:30 systemd-udevd[491]: Could not generate persistent MAC address for ethoipsix0: No such file or directory Jan 18 15:26:30 kernel: IPv6: ADDRCONF(NETDEV_UP): ens3: link is not ready Jan 18 15:26:30 kernel: e1000: ens3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Jan 18 15:26:30 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): ens3: link becomes ready ``` -- Package-specific info: --- /etc/network/interfaces: # interfaces(5) file used by ifup(8) and ifdown(8) # Include files from /etc/network/interfaces.d: source-directory /etc/network/interfaces.d # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto ens3 iface ens3 inet static address 10.91.240.1/22 pre-up ip address flush dev $IFACE up ip route add 10.0.0.0/8 via 10.91.243.254 dev $IFACE up ip route add 192.168.0.0/16 via 10.91.243.254 dev $IFACE up sysctl -w net.ipv4.conf.ens3.forwarding=0 --- up and down scripts installed: /etc/network/if-down.d: total 1 -rwxr-xr-x 1 root root 256 Apr 1 2016 resolvconf /etc/network/if-post-down.d: total 0 /etc/network/if-pre-up.d: total 1 -rwxr-xr-x 1 root root 344 Jun 30 2016 ethtool /etc/network/if-up.d: total 3 -rwxr-xr-x 1 root root 817 Apr 1 2016 000resolvconf -rwxr-xr-x 1 root root 1685 Jun 30 2016 ethtool -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ifupdown depends on: ii adduser 3.118 ii iproute2 4.20.0-2 ii libc6 2.28-5 ii lsb-base 10.2018112800 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.4.1-2 Versions of packages ifupdown suggests: pn ppp pn rdnssd -- no debconf information --- End Message --- --- Begin Message --- Source: ionit Source-Version: 0.3.2-1 We believe that the bug you reported is fixed in the latest version of ionit, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 919...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Benjamin Drung (supplier of updated ionit package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Am 20.06.19 um 11:25 schrieb Jonathan Carter: > I just have a small proposal: > > Selecting "Gnome on Xorg" is really easy from GDM for anyone who has > trouble on Wayland. It might be worth while adding that to the release > notes so that users who are not quite ready for Wayland yet know that > there's an easy way to get the old behavior back without having to > re-install stretch or some other distro. That seems like a very good idea to document this prominently in the release notes. After all, we do install both Xorg and Wayland support, so switching the desktop session is indeed trivial. I was about to file a bug report against release-notes to add such a section, but then it probably makes sense to wait for a final decision. Related to that, we already have https://salsa.debian.org/ddp-team/release-notes/commit/5496e24 Assuming it is decided, that the default is switched back to Xorg, this existing paragraph in the release notes should be adapted accordingly. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#930774: guile-2.2: FTBFS when built with dpkg-buildpackage -A
Package: src:guile-2.2
Version: 2.2.4+1-2
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in buster but it failed:
[...]
debian/rules build-indep
dh build-indep --parallel --with autoreconf
debian/rules override_dh_testdir
make[1]: Entering directory '/<>/guile-2.2-2.2.4+1'
dh_testdir debian/guile.postinst
make[1]: Leaving directory '/<>/guile-2.2-2.2.4+1'
dh_update_autotools_config -i -O--parallel
debian/rules override_dh_autoreconf
make[1]: Entering directory '/<>/guile-2.2-2.2.4+1'
echo '2.2.4' > .version
cp -a .version .tarball-version
dh_autoreconf ./autogen.sh
autoconf (GNU Autoconf) 2.69
[... snipped ...]
make[6]: Entering directory '/<>/guile-2.2-2.2.4+1/guile-readline'
make[6]: Nothing to be done for 'install-exec-am'.
/bin/mkdir -p
'/<>/guile-2.2-2.2.4+1/debian/tmp/usr/lib/x86_64-linux-gnu/guile/2.2/extensions'
/bin/bash ../libtool --mode=install install -p guile-readline.la
'/<>/guile-2.2-2.2.4+1/debian/tmp/usr/lib/x86_64-linux-gnu/guile/2.2/extensions'
libtool: warning: relinking 'guile-readline.la'
libtool: install: (cd /<>/guile-2.2-2.2.4+1/guile-readline; /bin/bash
"/<>/guile-2.2-2.2.4+1/libtool" --tag CC --mode=relink gcc
-std=gnu11 -Wall -Wmissing-prototypes -Wdeclaration-after-statement
-Wpointer-arith -Wswitch-enum -fno-strict-aliasing -fwrapv -g -O2
-fdebug-prefix-map=/<>/guile-2.2-2.2.4+1=. -fstack-protector-strong
-Wformat -Werror=format-security -DPACKAGE_PACKAGER=\"Debian\"
-DPACKAGE_PACKAGER_VERSION=\"2.2.4-deb+1-2\"
-DPACKAGE_PACKAGER_BUG_REPORTS=\"http://www.debian.org/Bugs/Reporting\";
-fno-stack-protector -export-dynamic -no-undefined -module -Wl,-z,relro -o
guile-readline.la -rpath /usr/lib/x86_64-linux-gnu/guile/2.2/extensions
readline.lo -L/usr/lib/x86_64-linux-gnu -lreadline -lncurses
../libguile/libguile-2.2.la ../lib/libgnu.la -lcrypt -lm -inst-prefix-dir
/<>/guile-2.2-2.2.4+1/debian/tmp)
libtool: relink: gcc -std=gnu11 -shared -fPIC -DPIC .libs/readline.o
-Wl,--whole-archive ../lib/.libs/libgnu.a -Wl,--no-whole-archive
-L/usr/lib/x86_64-linux-gnu -lreadline -lncurses
-L/<>/guile-2.2-2.2.4+1/debian/tmp/usr/lib/x86_64-linux-gnu
-lguile-2.2 -lunistring -lcrypt -lm -g -O2 -fstack-protector-strong -Wl,-z
-Wl,relro -pthread -Wl,-soname -Wl,guile-readline.so.0 -o
.libs/guile-readline.so.0.0.0
libtool: install: install -p .libs/guile-readline.so.0.0.0T
/<>/guile-2.2-2.2.4+1/debian/tmp/usr/lib/x86_64-linux-gnu/guile/2.2/extensions/guile-readline.so.0.0.0
libtool: install: (cd
/<>/guile-2.2-2.2.4+1/debian/tmp/usr/lib/x86_64-linux-gnu/guile/2.2/extensions
&& { ln -s -f guile-readline.so.0.0.0 guile-readline.so.0 || { rm -f
guile-readline.so.0 && ln -s guile-readline.so.0.0.0 guile-readline.so.0; }; })
libtool: install: (cd
/<>/guile-2.2-2.2.4+1/debian/tmp/usr/lib/x86_64-linux-gnu/guile/2.2/extensions
&& { ln -s -f guile-readline.so.0.0.0 guile-readline.so || { rm -f
guile-readline.so && ln -s guile-readline.so.0.0.0 guile-readline.so; }; })
libtool: install: install -p .libs/guile-readline.lai
/<>/guile-2.2-2.2.4+1/debian/tmp/usr/lib/x86_64-linux-gnu/guile/2.2/extensions/guile-readline.la
libtool: install: install -p .libs/guile-readline.a
/<>/guile-2.2-2.2.4+1/debian/tmp/usr/lib/x86_64-linux-gnu/guile/2.2/extensions/guile-readline.a
libtool: install: chmod 644
/<>/guile-2.2-2.2.4+1/debian/tmp/usr/lib/x86_64-linux-gnu/guile/2.2/extensions/guile-readline.a
libtool: install: ranlib
/<>/guile-2.2-2.2.4+1/debian/tmp/usr/lib/x86_64-linux-gnu/guile/2.2/extensions/guile-readline.a
libtool: warning: remember to run 'libtool --finish
/usr/lib/x86_64-linux-gnu/guile/2.2/extensions'
/bin/mkdir -p
'/<>/guile-2.2-2.2.4+1/debian/tmp/usr/include/guile/2.2'
install -p -m 644 readline.h
'/<>/guile-2.2-2.2.4+1/debian/tmp/usr/include/guile/2.2'
/bin/mkdir -p '/<>/guile-2.2-2.2.4+1/debian/tmp/usr/share/guile/2.2/'
/bin/mkdir -p
'/<>/guile-2.2-2.2.4+1/debian/tmp/usr/share/guile/2.2//ice-9'
install -p -m 644 ice-9/readline.scm
'/<>/guile-2.2-2.2.4+1/debian/tmp/usr/share/guile/2.2//ice-9'
/bin/mkdir -p
'/<>/guile-2.2-2.2.4+1/debian/tmp/usr/lib/x86_64-linux-gnu/guile/2.2/ccache/'
/bin/mkdir -p
'/<>/guile-2.2-2.2.4+1/debian/tmp/usr/lib/x86_64-linux-gnu/guile/2.2/ccache//ice-9'
install -p -m 644 ice-9/readline.go
'/<>/guile-2.2-2.2.4+1/debian/tmp/usr/lib/x86_64-linux-gnu/guile/2.2/ccache//ice-9'
make[6]: Leaving directory '/<>/guile-2.2-2.2.4+1/guile-readline'
make[5]: Leaving directory '/<>/guile-2.2-2.2.4+1/guile-readline'
make[4]: Leaving directory '/<>/guile-2.2-2.2.4+1/guile-readline'
Making install in examples
make[4]: Entering directory '/<>/guile-2.2-2.2.4+1/examples'
make[5]: Entering directory '/<>/guile-2.2-2.2.4+1/examples'
make[5]: Nothing to be done for 'install-exec-am'.
make[5]: Nothing to be done for 'install-data-am'.
make[5]: Leaving directory '/<>/guile-2.2-2.2.4+1/examples'
make[4]: Leaving directory
Processed: ionit runs too late for /etc/network/interfaces
Processing commands for cont...@bugs.debian.org: > reassign 919690 ionit 0.2.1-1 Bug #919690 [ifupdown] ifupdown: ifquery from ifup@.service fails with exit code 1 on boot Bug reassigned from package 'ifupdown' to 'ionit'. No longer marked as found in versions ifupdown/0.8.34. Ignoring request to alter fixed versions of bug #919690 to the same values previously set Bug #919690 [ionit] ifupdown: ifquery from ifup@.service fails with exit code 1 on boot Marked as found in versions ionit/0.2.1-1. > severity 919690 serious Bug #919690 [ionit] ifupdown: ifquery from ifup@.service fails with exit code 1 on boot Severity set to 'serious' from 'important' > retitle 919690 ionit runs too late for /etc/network/interfaces Bug #919690 [ionit] ifupdown: ifquery from ifup@.service fails with exit code 1 on boot Changed Bug title to 'ionit runs too late for /etc/network/interfaces' from 'ifupdown: ifquery from ifup@.service fails with exit code 1 on boot'. > thanks Stopping processing here. Please contact me if you need assistance. -- 919690: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919690 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#930770: marked as done (bochs: missing Voodoo and e1000 plugins)
Your message dated Thu, 20 Jun 2019 10:06:42 + with message-id and subject line Bug#930770: fixed in bochs 2.6.9+dfsg-3 has caused the Debian Bug report #930770, regarding bochs: missing Voodoo and e1000 plugins to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 930770: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930770 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: bochs Version: 2.6.9+dfsg-2 Severity: serious Justification: missing files Dear Maintainer, The bochs package is built with support for Voodoo and e1000, but the corresponding plugins aren’t shipped in the package. Regards, Stephen -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-9-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bochs depends on: ii bochs-wx [bochs-gui] 2.6.9+dfsg-2 ii bochs-x [bochs-gui] 2.6.9+dfsg-2 ii bochsbios 2.6.9+dfsg-2 ii libasound21.1.3-5 ii libc6 2.24-11+deb9u4 ii libgcc1 1:6.3.0-18+deb9u1 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libltdl7 2.4.6-2 ii libpango-1.0-01.40.5-1 ii libreadline7 7.0-3 ii libsdl2-2.0-0 2.0.9+dfsg1-1~bpo9+1 ii libstdc++66.3.0-18+deb9u1 ii vgabios 0.7a-6 Versions of packages bochs recommends: ii bximage 2.6-5 Versions of packages bochs suggests: ii bcc [c-compiler]0.16.17-3.2 pn bochs-doc ii clang-3.8 [c-compiler] 1:3.8.1-24 ii clang-3.9 [c-compiler] 1:3.9.1-9 ii debootstrap 1.0.89 ii gcc [c-compiler]4:6.3.0-4 ii gcc-6 [c-compiler] 6.3.0-18+deb9u1 pn grub-rescue-pc ii libc6-dev [libc-dev]2.24-11+deb9u4 ii tcc [c-compiler]0.9.27~git20161217.cd9514ab-3 -- no debconf information --- End Message --- --- Begin Message --- Source: bochs Source-Version: 2.6.9+dfsg-3 We believe that the bug you reported is fixed in the latest version of bochs, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 930...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Stephen Kitt (supplier of updated bochs package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 20 Jun 2019 10:37:44 +0200 Source: bochs Binary: bochs bochs-doc bochsbios bochs-wx bochs-sdl bochs-term bochs-x bximage sb16ctrl-bochs Architecture: source Version: 2.6.9+dfsg-3 Distribution: unstable Urgency: medium Maintainer: Stephen Kitt Changed-By: Stephen Kitt Description: bochs - IA-32 PC emulator bochs-doc - Bochs upstream documentation bochs-sdl - SDL plugin for Bochs bochs-term - Terminal (ncurses-based) plugin for Bochs bochs-wx - WxWindows plugin for Bochs bochs-x- X11 plugin for Bochs bochsbios - BIOS for the Bochs emulator bximage- Disk Image Creation Tool for Bochs sb16ctrl-bochs - control utility for Bochs emulated SB16 card Closes: 930770 Changes: bochs (2.6.9+dfsg-3) unstable; urgency=medium . * Ship the Voodoo and e1000 plugins; thanks to Christian Ehrhardt for the patch. Closes: #930770. LP: #1830094. Checksums-Sha1: 73de3da1052a894ba160202676184c27f0b234ca 2618 bochs_2.6.9+dfsg-3.dsc ca47d2fd043bcf5ae58a51ce482f46ff472325d7 53880 bochs_2.6.9+dfsg-3.debian.tar.xz 53bba5374c6b5f8da8358e3cea471ef451a856d6 11728 bochs_2.6.9+dfsg-3_source.buildinfo Checksums-Sha256: b069f5bdb379e185f41cf59feeb0f008cfac4c055ca7cd1c3e1c595ccd53b8a5 2618 bochs_2.6.9+dfsg-3.dsc bc8c7c3fc76277096c8186878527930b39bcf1530f23960918de8950b6041cfc 53880 bochs_2.6.9+dfsg-3.debian.tar.xz 0aefe845c80b104adc1d452cb48436183faa328291f1d14c0377e83a0330e048 11728 bochs_2.6.9+dfsg-3_source.buil
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
I'm writing with my DPL hat on in the role of a facilitator/mediator. I have no actual power in this situation and it is entirely reasonable to ignore me. I feel very uncomfortable with a change as big as this revert happening this late in the release cycle. I think that my reading of how the release team handles issues is sufficient to say that they almost certainly have serious concerns about that big of a change this late too. And yet, the lack of a clear reconfirmation in this time line even given the wonderfully civil discussion is telling. My proposal--which again I have no power to implement--is that we go forward with the current default. However, we remain open to a revert in the first couple of buster point releases. The criteria for that revert should be based on the actual severity and frequence of problems our users run into, but should specifically exclude the blanket reluctance to make a change like that in a point release. We would still need adequate testing of such a revert. So, what I think this would require to be a viable proposal is: * an ack from the buster stable release managers that if we run into real problems they would accept such a change * an ack from gnome that if we do need to do a revert we'd be willing to revert in unstable and testing for a while to do as much testing of the revert in those environments. Obviously such testing is imperfect given that gnome may (hopefully will) have moved on in Debian by then. Again, feel free to ignore this message entirely if it does not move the conversation forward. I'm just seeing a stuck issue and proposing a way to try and unstick it. --Sam signature.asc Description: PGP signature
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Hi everyone Am 20.06.19 um 11:12 schrieb Iain Lane: >> I've left some comments on >> https://salsa.debian.org/gnome-team/gdm/merge_requests/8 regarding the >> technical side of the proposed change. > Someone could probably look in Ubuntu's gdm3 package to see what we're > doing. We provide "GNOME" (Xorg, the default) and "GNOME on Wayland" > sessions. Afair, this required changing gnome-session. I left a comment in the gdm MR. If the point is, to not switch the desktop session automatically on upgrades, then the session files would have to be renamed (back again) to gnome.desktop (Xorg) and gnome-wayland.desktop from gnome.desktop (Wayland) and gnome-xorg.desktop. At least this is how I remember the details from back then in 2016. I haven't checked if the situation is still the same today. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Hi Simon, others, Thanks to those involved so far in shepherding this side of the issue along. And also for poking me (repeatedly!) to reply. On Wed, Jun 19, 2019 at 09:19:49PM +0100, Simon McVittie wrote: > On Wed, 19 Jun 2019 at 17:33:55 +0100, Jonathan Dowland wrote: > > So far as I am aware there is still radio silence from active GNOME > > packaging team members regarding this issue. No comment yet on the > > patch I adapted, positive or negative; this bug (#927667) remains > > at an RC severity. Right, sorry about that. It's a big lack of spoons for me (please consider that if you are thinking about rebutting my points below). I personally find this kind of topic a bit draining, although I appreciate that the temperature of the bug (not the previous -devel thread) is quite low. Thanks for that. > (Adding debian-gtk-gnome, debian-desktop and some people who might have > useful input to Cc) > […] > - Ubuntu GNOME team: which recent Ubuntu versions, if any, are using > Wayland for their GNOME-based desktop? Seb's explained that, and the reasons why that decision was made. So you can have my inconclusive personal opinion: I've been deliberately using Wayland-on-Ubuntu and Wayland-on-Debian the whole time, and the only thing that has irritated *me* was one time I couldn't screen share from Firefox. I *like* that it's raised the bar for privilege separation (the Synaptic case), as I find it quite distasteful to be running the entire thing as root. I acknowledge that the shell-crashing-crashes-the-session model could be uncomfortable sometimes — but my experience has not been one where that happens. Some of the upstream improvements (e.g. fractional scaling, which is still experimental) are Wayland-only. I've read and understood the counter-arguments posted on the bug. I don't feel in a particularly good position with respect to weighing up the balance here. If you are affected by a Wayland-specific bug, especially if it impacts you frequently (e.g. you can't do something you need to do, or the shell repeatedly crashes / the mouse becomes unresponsive / similar), that is going to be really quite irritating. And I share Ansgar's concern about this all being very late now. Part of that is down to our (GNOME team at large) lack of engagement on the bug — apologies again — but it would have felt late to me even at the end of April. That said, Ubuntu has been shipping with this configuration and we don't know of any particular issues. Release team, what do you think? In conclusion, I will not stand in the way of anyone if they want to execute this change, but it's not likely to be me doing it. > I've left some comments on > https://salsa.debian.org/gnome-team/gdm/merge_requests/8 regarding the > technical side of the proposed change. Someone could probably look in Ubuntu's gdm3 package to see what we're doing. We provide "GNOME" (Xorg, the default) and "GNOME on Wayland" sessions. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#930368: Bug#930727: unblock: gatb-core/1.4.1+git20181225.44d5a44+dfsg-3
On Thu, Jun 20, 2019 at 10:22:28AM +0200, Paul Gevers wrote: > On 19-06-2019 13:40, Andreas Tille wrote: > > - > > _ZNSt6vectorISt5tupleIJjN4gatb4core5tools4math8LargeIntILi2EEEjjjEESaIS7_EE12emplace_backIJS7_EEEvDpOT_@Base > > 1.4.1+git20181225.44d5a44+dfsg > > [...] > > > - _ZNSt6vectorIbSaIbEE13_M_initializeEm@Base 1.4.1+git20181225.44d5a44+dfsg > > These look like c++ injected symbols, and I know they can sometimes be > safely removed (but that is all I know about it). Can you explain what > you did to check that this is the right action here? I did a rebuild which showed the same diff and thus applied. I did nothing else. The only other fix I could provide would be to simply remove the symbols file which is simply a maintenance burden in this case. It was discussed several times that C++ symbols can be a moving target so I was always tempted to spare it for this extremely low popcon library which is only used by two dependencies. Its also for a reason that it exists only for amd64 since maintaining it for other architectures is just a waste of time. I used the symbols file to realise if upstream has changed the ABI - which they are doing most of the time thus I need to check anyway. If you are unsure whether the current upload is the correct solution please let me know and I'll remove the symbols file. Kind regards Andreas. -- http://fam-tille.de
Bug#915333: marked as done (git-annex: Illegal Instruction on armel (Fujitsu Q700 like QNAP TS-21x/TS-22x))
Your message dated Thu, 20 Jun 2019 08:36:35 + with message-id and subject line Bug#915333: fixed in ghc 8.6.4+dfsg1-2 has caused the Debian Bug report #915333, regarding git-annex: Illegal Instruction on armel (Fujitsu Q700 like QNAP TS-21x/TS-22x) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 915333: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915333 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: git-annex Version: 7.20181121-1 Severity: important Dear Maintainer, I wanted to use git-annex on this machine (Fujitsu Q700 NAS), but it Crashes with "Illegal Instruction". I don't have these problems with other Packages or with the upstream build of git-annex. Many Thanks for Maintaining the Debian Package. Regards, Lukas Straub /proc/cpuinfo: processor : 0 model name : Feroceon 88FR131 rev 1 (v5l) BogoMIPS: 400.00 Features: swp half thumb fastmult edsp CPU implementer : 0x56 CPU architecture: 5TE CPU variant : 0x2 CPU part: 0x131 CPU revision: 1 Hardware: Marvell Kirkwood (Flattened Device Tree) Revision: Serial : -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: armel (armv5tel) Kernel: Linux 4.18.0-0.bpo.1-marvell Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages git-annex depends on: ii curl7.62.0-1 ii git 1:2.19.2-1 ii libatomic1 8.2.0-9 ii libc6 2.27-8 ii libffi6 3.2.1-9 ii libgmp102:6.1.2+dfsg-3 ii libmagic1 1:5.34-2 ii libsqlite3-03.25.3-2 ii libxml2 2.9.4+dfsg1-7+b2 ii netbase 5.5 ii openssh-client 1:7.9p1-4 ii rsync 3.1.2-2.2 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages git-annex recommends: ii aria2 1.34.0-3 ii bind9-host 1:9.11.5+dfsg-1 ii git-remote-gcrypt 1.1-1 ii gnupg 2.2.11-1 ii lsof 4.89+dfsg-0.1 ii nocache1.0-1 Versions of packages git-annex suggests: pn adb pn bup pn libnss-mdns pn magic-wormhole pn tahoe-lafs ii tor 0.3.4.9-5 pn uftp pn xdot pn youtube-dl -- no debconf information --- End Message --- --- Begin Message --- Source: ghc Source-Version: 8.6.4+dfsg1-2 We believe that the bug you reported is fixed in the latest version of ghc, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 915...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Gianfranco Costamagna (supplier of updated ghc package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 20 Jun 2019 10:18:39 +0200 Source: ghc Binary: ghc ghc-prof ghc-doc Architecture: source Version: 8.6.4+dfsg1-2 Distribution: experimental Urgency: medium Maintainer: Debian Haskell Group Changed-By: Gianfranco Costamagna Description: ghc- The Glasgow Haskell Compilation system ghc-doc- Documentation for the Glasgow Haskell Compilation system ghc-prof - Profiling libraries for the Glasgow Haskell Compilation system Closes: 915333 919518 923445 Changes: ghc (8.6.4+dfsg1-2) experimental; urgency=medium . * Merge with unstable changes in 8.4.4+dfsg1-3 . ghc (8.4.4+dfsg1-3) unstable; urgency=medium . * Use the ARM7TDMI core on armel (Closes: #915333) . ghc (8.4.4+dfsg1-2) unstable; urgency=medium . [ Clint Adams ] * Patch Sphinx config to use locally-installed MathJax instead of a copy on the Internet. closes: #919518. . [ Gianfranco Costamagna ] * Fix sphinx 1.8 build with upstream patch (Closes: #923445) Checksums-Sha1: ccc7cb0d8c4588415e798894363fa277bc299d98 2371 ghc_8.6.4+dfsg1-2.dsc d99fca640e83a7a8117ee2de52aafa612c173edf 18950064 ghc_8.6.4+dfsg1.orig.tar.xz f68cebb1db9be301b307522f932f8b47621cf30a 51356 ghc_8.6.4+dfsg1-2.debian.tar.xz 3f1360e29c2817dceb4d57da1a69f02f18e25ca
Bug#930770: bochs: missing Voodoo and e1000 plugins
Package: bochs Version: 2.6.9+dfsg-2 Severity: serious Justification: missing files Dear Maintainer, The bochs package is built with support for Voodoo and e1000, but the corresponding plugins aren’t shipped in the package. Regards, Stephen -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-9-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bochs depends on: ii bochs-wx [bochs-gui] 2.6.9+dfsg-2 ii bochs-x [bochs-gui] 2.6.9+dfsg-2 ii bochsbios 2.6.9+dfsg-2 ii libasound21.1.3-5 ii libc6 2.24-11+deb9u4 ii libgcc1 1:6.3.0-18+deb9u1 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libltdl7 2.4.6-2 ii libpango-1.0-01.40.5-1 ii libreadline7 7.0-3 ii libsdl2-2.0-0 2.0.9+dfsg1-1~bpo9+1 ii libstdc++66.3.0-18+deb9u1 ii vgabios 0.7a-6 Versions of packages bochs recommends: ii bximage 2.6-5 Versions of packages bochs suggests: ii bcc [c-compiler]0.16.17-3.2 pn bochs-doc ii clang-3.8 [c-compiler] 1:3.8.1-24 ii clang-3.9 [c-compiler] 1:3.9.1-9 ii debootstrap 1.0.89 ii gcc [c-compiler]4:6.3.0-4 ii gcc-6 [c-compiler] 6.3.0-18+deb9u1 pn grub-rescue-pc ii libc6-dev [libc-dev]2.24-11+deb9u4 ii tcc [c-compiler]0.9.27~git20161217.cd9514ab-3 -- no debconf information
Bug#923445: marked as done (ghc: FTBFS (The 'ghc-flag' directive is already registered to domain std))
Your message dated Thu, 20 Jun 2019 08:36:35 + with message-id and subject line Bug#923445: fixed in ghc 8.6.4+dfsg1-2 has caused the Debian Bug report #923445, regarding ghc: FTBFS (The 'ghc-flag' directive is already registered to domain std) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 923445: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923445 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:ghc Version: 8.4.4+dfsg1-1 Severity: serious Tags: ftbfs Dear maintainer: I tried to build this package in buster but it failed: [...] debian/rules binary-indep dh binary-indep dh_update_autotools_config -i debian/rules override_dh_autoreconf make[1]: Entering directory '/<>/ghc-8.4.4+dfsg1' dh_autoreconf perl -- boot Creating libraries/ghc-prim/ghc.mk Creating libraries/text/ghc.mk [... snipped ...] /usr/bin/sphinx-build -b html -d docs/users_guide/.doctrees-html -D latex_paper_size=letter docs/users_guide docs/users_guide/build-html/users_guide Running Sphinx v1.8.4 Extension error: The 'ghc-flag' directive is already registered to domain std make[3]: *** [docs/users_guide/ghc.mk:16: docs/users_guide/build-html/users_guide/index.html] Error 2 make[2]: *** [Makefile:127: all] Error 2 make[2]: Leaving directory '/<>/ghc-8.4.4+dfsg1' dh_auto_build: make -j1 returned exit code 2 make[1]: *** [debian/rules:132: override_dh_auto_build] Error 2 make[1]: Leaving directory '/<>/ghc-8.4.4+dfsg1' make: *** [debian/rules:58: binary-indep] Error 2 dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit status 2 The build was made in my autobuilder with "dpkg-buildpackage -A" and it also fails here: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ghc.html If this is really a bug in one of the build-depends, please use reassign and affects, so that this is still visible in the BTS web page for this package. Thanks. --- End Message --- --- Begin Message --- Source: ghc Source-Version: 8.6.4+dfsg1-2 We believe that the bug you reported is fixed in the latest version of ghc, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 923...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Gianfranco Costamagna (supplier of updated ghc package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 20 Jun 2019 10:18:39 +0200 Source: ghc Binary: ghc ghc-prof ghc-doc Architecture: source Version: 8.6.4+dfsg1-2 Distribution: experimental Urgency: medium Maintainer: Debian Haskell Group Changed-By: Gianfranco Costamagna Description: ghc- The Glasgow Haskell Compilation system ghc-doc- Documentation for the Glasgow Haskell Compilation system ghc-prof - Profiling libraries for the Glasgow Haskell Compilation system Closes: 915333 919518 923445 Changes: ghc (8.6.4+dfsg1-2) experimental; urgency=medium . * Merge with unstable changes in 8.4.4+dfsg1-3 . ghc (8.4.4+dfsg1-3) unstable; urgency=medium . * Use the ARM7TDMI core on armel (Closes: #915333) . ghc (8.4.4+dfsg1-2) unstable; urgency=medium . [ Clint Adams ] * Patch Sphinx config to use locally-installed MathJax instead of a copy on the Internet. closes: #919518. . [ Gianfranco Costamagna ] * Fix sphinx 1.8 build with upstream patch (Closes: #923445) Checksums-Sha1: ccc7cb0d8c4588415e798894363fa277bc299d98 2371 ghc_8.6.4+dfsg1-2.dsc d99fca640e83a7a8117ee2de52aafa612c173edf 18950064 ghc_8.6.4+dfsg1.orig.tar.xz f68cebb1db9be301b307522f932f8b47621cf30a 51356 ghc_8.6.4+dfsg1-2.debian.tar.xz 3f1360e29c2817dceb4d57da1a69f02f18e25ca7 9095 ghc_8.6.4+dfsg1-2_source.buildinfo Checksums-Sha256: c4926375d7069523b16043793d0b1bb2419da25b2172aad1824455d48d09ba88 2371 ghc_8.6.4+dfsg1-2.dsc fe0170c74e57acebfbd48b9ba47955d39893fcd001cac1e9212fd3848d8d0a8d 18950064 ghc_8.6.4+dfsg1.orig.tar.xz 29249088071d8627ba490d575b545c7528d377529e4214371bf1e25a07961c2b 51356 ghc_8.6.4+dfsg1-2.debian.tar.xz 793e4cd7b
Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language
Hi, ButterflyOfFire wrote: > Hi, > I think it is okay for those diacritics. > Regards, I have uploaded that fix now. Leaving this bug open as a reminder for the "real" problem inside of gtk (?) Holger > ‐‐‐ Original Message ‐‐‐ > Le mardi 18 juin 2019 22:26, Holger Wansing a écrit : > > > Hi, > > > > Samuel Thibault sthiba...@debian.org wrote: > > > > > Hello, > > > Holger Wansing, le mar. 04 juin 2019 20:59:12 +, a ecrit: > > > > > > > Am Sonntag, 2. Juni 2019 schrieb Holger Wansing: > > > > > > > > > Am Sonntag, 2. Juni 2019 schrieb Samuel Thibault: > > > > > > > > > > > ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit: > > > > > > > > > > > > > > > "لاحقاً" > > > > > > > > > > > > > > This word means "later" and can be replaced by "لاحقا". > > > > > > > > > > > > That avoids the issue here indeed. I however see it used in various > > > > > > > > > > Hmm. > > > > > There has been no changing in the ar.po of partman-auto > > > > > for 3 years now (JFTR), thus the real problem seems to be > > > > > sitting somewhere else ... > > > > > > > > How should we proceed here? > > > > Since we are late in the freeze, and it's most probably not that > > > > easy to find out what happened and what the real issue is: > > > > should we go with the "work-around" proposed by > > > > Butterflyoffire and confirmed to fix the issue by Samuel? > > > > > > Personally, I don't think I'll have the time to debug what is actually > > > happening inside gtk until the release, so even if it's ugly, I guess > > > the browntape fix is the least worst I can come up with. > > > > That looks fair. > > I have committed the proposed fix now. > > > > @butterflyoffire: could you please take a look at > > https://salsa.debian.org/installer-team/d-i/commit/fa17b7afffb2ee4888a371efa4153c5c075915e7 > > to double-check if the fix is fine by you? > > Thanks! > > > > Holger > > > > > > - > > > > Holger Wansing hwans...@mailbox.org > > PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076 > > -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Michael Biebl writes: > On Wed, 19 Jun 2019 22:16:58 +0200 Ansgar Burchardt wrote: >> I'm just a GNOME user, but from gdm3's changelog the default was >> switched to Wayland in July 2017 (or August 2017 for unstable). I >> myself only noticed the switch after reading it happened somewhere on >> the internet shortly after it happened. [...] > When you talk about "gdm3's default", what exactly do you mean: the > display technology gdm is using or the type of GNOME session that is > started as default? I meant the GNOME session; that is the only thing that changed in July/August 2017 as gdm itself used Wayland already before as far as I understand. For something that has been the default for almost two years to be switched back two weeks before the release there has to be some really huge issues for me. Any change will not see much testing given the time after all and risks new regressions. Ansgar
Processed: Re: Bug#930727: unblock: gatb-core/1.4.1+git20181225.44d5a44+dfsg-3
Processing control commands:
> tags -1 moreinfo
Bug #930727 [release.debian.org] unblock:
gatb-core/1.4.1+git20181225.44d5a44+dfsg-3
Added tag(s) moreinfo.
> tags 930368 ftbfs
Bug #930368 {Done: Andreas Tille } [src:gatb-core] gatb-core:
FTBFS due to inaccurate symbols file
Added tag(s) ftbfs.
--
930368: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930368
930727: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930727
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
