Bug#913414: [Pkg-rust-maintainers] Bug#913414: Bug#913414: rustc: fails to compile release binaries due to non -fPIC code

[Sylvestre Ledru]

Hello


Does it work with 1:7.0.1~+rc2-3?
I tried to reproduce it and I am getting:
error: Edition 2018 is unstable and only available for nightly builds of rustc.

S


Le 11/11/2018 à 00:48, Ximin Luo a écrit :
> Control: reassign -1 llvm-7 1:7.0.1~+rc2-2
> 
> LLVM-7 1:7-6 works fine for me, 1:7.0.1~+rc2-2 is broken.
> 
> With 1:7.0.1~+rc2-2, you can work around the failure by using "rustc -C 
> relocation-model=default". I have no idea why this works, but it does.
> 
> X
> 
> Ximin Luo:
>> The version of LLVM-7 in Debian unstable breaks rustc currently.
>>
>> Can you try it with the LLVM-7 from Debian testing? i.e. this one:
>>
>> $ apt-cache policy llvm-7
>> llvm-7:
>>   Installed: 1:7-6
>>   Candidate: 1:7-6
>>   Version table:
>>  1:7.0.1~+rc2-2 300
>> 300 http://deb.debian.org/debian unstable/main amd64 Packages
>>  *** 1:7-6 990
>> 990 http://deb.debian.org/debian testing/main amd64 Packages
>> 100 /var/lib/dpkg/status
>>
>> X
>>
>> brian m. carlson:
>>> Package: rustc
>>> Version: 1.30.0+dfsg1-2
>>> Severity: important
>>>
>>> If you attempt to build a release binary, rustc fails because of a bad
>>> relocation when making a PIE object.
>>>
>>> Steps to reproduce:
>>> 1. git clone https://github.com/rust-lang-nursery/rust-clippy.git
>>> 2. cd rust-clippy
>>> 3. git checkout v0.0.212
>>> 4. cargo build --verbose --release
>>> 5. Notice that the build fails.
>>> 6. Notice messages like the following:
>>>
>>>   = note: /usr/bin/ld: 
>>> /home/bmc/checkouts/external/rust-clippy/target/release/build/serde-3ddadc5e75c3de00/build_script_build-3ddadc5e75c3de00.build_script_build.140spq3r-cgu.2.rcgu.o:
>>>  relocation R_X86_64_32S against `.rodata.cst16' can not be used when 
>>> making a PIE object; recompile with -fPIC
>>>   /usr/bin/ld: 
>>> /home/bmc/checkouts/external/rust-clippy/target/release/build/serde-3ddadc5e75c3de00/build_script_build-3ddadc5e75c3de00.build_script_build.140spq3r-cgu.4.rcgu.o:
>>>  relocation R_X86_64_32 against symbol `rust_eh_personality' can not be 
>>> used when making a PIE object; recompile with -fPIC
>>>   /usr/bin/ld: 
>>> /home/bmc/checkouts/external/rust-clippy/target/release/build/serde-3ddadc5e75c3de00/build_script_build-3ddadc5e75c3de00.build_script_build.140spq3r-cgu.6.rcgu.o:
>>>  relocation R_X86_64_32 against symbol `rust_eh_personality' can not be 
>>> used when making a PIE object; recompile with -fPIC
>>>   /usr/bin/ld: 
>>> /home/bmc/checkouts/external/rust-clippy/target/release/build/serde-3ddadc5e75c3de00/build_script_build-3ddadc5e75c3de00.build_script_build.140spq3r-cgu.9.rcgu.o:
>>>  relocation R_X86_64_32 against symbol `rust_eh_personality' can not be 
>>> used when making a PIE object; recompile with -fPIC
>>>   /usr/bin/ld: final link failed: nonrepresentable section on output
>>>   collect2: error: ld returned 1 exit status
>>>
>>> I see similar errors on a project of my own which compiled fine on
>>> November 3.  I also see this failure with rust 1.31.0 beta from
>>> experimental.
>>>
>>> -- System Information:
>>> Debian Release: buster/sid
>>>   APT prefers unstable-debug
>>>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
>>> (1, 'experimental-debug'), (1, 'experimental')
>>> Architecture: amd64 (x86_64)
>>> Foreign Architectures: i386
>>>
>>> Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
>>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
>>> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
>>> Shell: /bin/sh linked to /bin/dash
>>> Init: systemd (via /run/systemd/system)
>>> LSM: AppArmor: enabled
>>>
>>> Versions of packages rustc depends on:
>>> ii  binutils  2.31.1-7
>>> ii  gcc   4:8.2.0-2
>>> ii  libc6 2.27-8
>>> ii  libc6-dev [libc-dev]  2.27-8
>>> ii  libgcc1   1:8.2.0-9
>>> ii  libllvm7  1:7.0.1~+rc2-2
>>> ii  libstd-rust-dev   1.30.0+dfsg1-2
>>> ii  libstdc++68.2.0-9
>>>
>>> Versions of packages rustc recommends:
>>> ii  cargo 0.31.0-2
>>> ii  rust-gdb  1.30.0+dfsg1-2
>>>
>>> Versions of packages rustc suggests:
>>> ii  rust-doc  1.30.0+dfsg1-2
>>> pn  rust-src  
>>>
>>> -- no debconf information
>>>
>>
>>
> 
> 

Bug#762936: This also breaks pavucontrol

[martin]

took a while to track down hence me raising this but with this package 
installed pavucontrol is unusable along with all volume controls in xfce
removing this package fixes the problem - maybe we should consider 
removing this package if upstream don't support it any more

Bug#762936: This also breaks pavucontrol

[martin]

my solution was simply to remove the package:

dpkg --purge gtk3-engines-xfce

Just to help others find the issue these are the errors on the console 
when running pavucontrol:


(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:36:10: 
The 'engine' property is ignored
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:38:23: 
Custom CSS properties are no longer supported.
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:39:22: 
Custom CSS properties are no longer supported.
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:41:39: 
The style property GtkWidget:focus-line-width is deprecated and 
shouldn't be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:42:39: 
The style property GtkWidget:focus-padding is deprecated and shouldn't 
be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:43:39: 
The style property GtkWidget:interior-focus is deprecated and shouldn't 
be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:45:39: 
The style property GtkButton:child-displacement-x is deprecated and 
shouldn't be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:46:39: 
The style property GtkButton:child-displacement-y is deprecated and 
shouldn't be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:47:39: 
The style property GtkButton:default-border is deprecated and shouldn't 
be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:48:39: 
The style property GtkButton:default-outside-border is deprecated and 
shouldn't be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:50:40: 
The style property GtkButtonBox:child-internal-pad-x is deprecated and 
shouldn't be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:51:40: 
The style property GtkButtonBox:child-internal-pad-y is deprecated and 
shouldn't be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:52:39: 
The style property GtkButtonBox:child-min-height is deprecated and 
shouldn't be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:53:39: 
The style property GtkButtonBox:child-min-width is deprecated and 
shouldn't be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:55:39: 
The style property GtkCheckButton:indicator-size is deprecated and 
shouldn't be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:57:39: 
The style property GtkExpander:expander-size is deprecated and shouldn't 
be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:58:39: 
The style property GtkExpander:expander-spacing is deprecated and 
shouldn't be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:60:39: 
The style property GtkMenuBar:internal-padding is deprecated and 
shouldn't be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:62:39: 
The style property GtkMenu:horizontal-padding is deprecated and 
shouldn't be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:63:39: 
The style property GtkMenu:vertical-padding is deprecated and shouldn't 
be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:65:39: 
The style property GtkPaned:handle-size is deprecated and shouldn't be 
used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:67:39: 
The style property GtkRange:slider-width is deprecated and shouldn't be 
used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:68:39: 
The style property GtkRange:stepper-size is deprecated and shouldn't be 
used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:69:39: 
The style property GtkRange:stepper-spacing is deprecated and shouldn't 
be used anymore. It will be removed in a future version
(pavucontrol:1527): Gtk-WARNING **: Theme parsing error: gtk.css:70:39: 
The style property GtkRange:trough-border is deprecated and shouldn't be 
used anymore. It will be remove

Bug#913928: grub-pc fails to install on the last of multiple devices

[Richard Laager]

Package: grub-pc
Version: 2.02+dfsg1-8
Severity: important
Tags: patch

When installing grub-pc to multiple devices, it fails installing on the
last device. For the failing device, all of the errors show a stray
comma at the end of the device name.

This is occurring because install_devices is a multiselect, and the
results are separated by commas. There is a comma at the end too. This
ends up being interpreted as part of the device name. The package has
code to remove the commas in the middle, but it does not remove the
comma at the end.

To reproduce this after the first failure, I had to do this (where that
device is the _last_ device, on which the install is failing):
grub-install /dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC18GCZ3 && 
DEBCONF_DEBUG=developer dpkg-reconfigure grub-pc

In the installed package's grub-pc.postinst, or the source package's
debian/postinst.in, this is the code in question (indentation reduced 8
spaces):
failed_devices=
for i in `echo $RET | sed -e 's/, / /g'` ; do
  real_device="$(readlink -f "$i")"
  if grub-install --target=i386-pc --force --no-floppy $real_device ; then
# We just installed GRUB 2; then also generate grub.cfg.
touch /boot/grub/grub.cfg
  else
failed_devices="$failed_devices $real_device"
  fi
done

For testing, I added a couple of echo statements:
 failed_devices=
+echo RET: $RET
 for i in `echo $RET | sed -e 's/, / /g'` ; do
   real_device="$(readlink -f "$i")"
+  echo REAL: $real_device
   if grub-install --target=i386-pc --force --no-floppy $real_device ; then
 # We just installed GRUB 2; then also generate grub.cfg.
 touch /boot/grub/grub.cfg
   else
 failed_devices="$failed_devices $real_device"
   fi
 done

This is the output:

debconf (developer): <-- GET grub-pc/install_devices
debconf (developer): --> 0 /dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC18FT84, 
/dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC18GPPQ, 
/dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC18GCZ3,
RET: /dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC18FT84, 
/dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC18GPPQ, 
/dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC18GCZ3,
REAL: /dev/sdb
Installing for i386-pc platform.
Installation finished. No error reported.
REAL: /dev/sdc
Installing for i386-pc platform.
Installation finished. No error reported.
REAL: /dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC18GCZ3,
Installing for i386-pc platform.
grub-install: error: cannot find a GRUB drive for 
/dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC18GCZ3,.  Check your device.map.
debconf (developer): <-- SUBST grub-pc/install_devices_failed FAILED_DEVICES  
/dev/disk/by-id/ata-ST4000NM0035-1V4107_ZC18GCZ3,

The issue is definitely the comma at the end.

To fix the issue, I changed the sed line to be like this:
for i in `echo $RET | sed -e 's/,\( \|$\)/ /g'` ; do

This strips the comma at the end, not just those in the middle (commas
followed by spaces).

Alternatively, if you prefer sed -E instead of backslashes for parens,
this also works:
for i in `echo $RET | sed -E 's/,( |$)/ /g'` ; do
or if -e is important, this also works:
for i in `echo $RET | sed -Ee 's/,( |$)/ /g'` ; do

-- 
Richard

Bug#911793: autopkgtest regression: Segmentation fault

[Paul Gevers]

Hi

On 16-11-18 11:08, Mattia Rizzolo wrote:
> On Fri, Nov 16, 2018 at 07:28:21AM +0100, Emmanuel Promayon wrote:
>> Thanks to the (great work) of Gert  on vtk7 and gdcm packages, version
>> 7.1.1+dfsg1-9 of vtk7 and version 2.8.8-2 of gdcm are now both in testing.
>> I sent a retry request for the autopkgtest of camitk version 4.1.2-2 but it
>> naturally failed as camitk 4.1.2-2 was built with the problematic version of
>> gdcm (error was at run time: "libvtkRenderingFreeTypeFontConfig-7.1.so.7.1:
>> cannot open shared object file: No such file or directory").
> 
> This is the signature of an ABI break not correctly handled.
> 
>> Would it possible for someone with the right credentials to ask for a
>> complete rebuild of camitk 4.1.2-2? (or please let me know if I am wrong
>> thinking that it is not the right course of actions!)
> 
> That's not the right action to take (or better, not only).  That
> situation must not happen, so most likely some versioned dependency or
> versioned break was missed somewhere.  Maybe Paul has more insight on
> the problem (I just read this single email and wanted to block a
> "simple" rebuild)

I am just the reporter, I don't have more insight into the issue than
already shared in this bug report.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#870468: grdesktop FTCBFS: broken PKG_CHECK_MODULES copy uses build arch pkg-config

[Helmut Grohne]

I suggest that we end the discussion here. It's much easier to simply
try cross building grdesktop than it is to argue what is going on.

Turns out, grdesktop does find the right pkg-config despite shipping the
outdated macro in aclocal.m4. Yavor's closure is correct.

On Sat, Nov 17, 2018 at 12:57:25AM +0200, Yavor Doganov wrote:
> No, in this particular case he is not right; you are both confusing
> two different use cases that have different (documented) behavior.
> The --force option causes the output file (aclocal.m4) to be generated
> always.  If the package is not shipping the third-party macro (as is
> the case with grdesktop -- it is not shipping pkg.m4), --force will
> always recreate aclocal.m4 using the macro definition as found in
> aclocal's search path (or autoreconf will fail if it cannot find it).
> 
> IOW, it is not necessary to patch aclocal.m4 as it is always going to
> be regenerated by dh_autoreconf.

Thank you for the detailed explanation. Today I learned something. In
particular, it'll result in me differentiating where macros are stored
and trying to send autoreconf patches for similar issues. Old ones
include #894039 #912837 #900433 and #900864. I wonder how many of them
get solved by autoreconfing with --force.

Helmut

Bug#913927: gemdropx FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Source: gemdropx
Version: 0.9-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gemdropx fails to cross build from source, because it builds for the
build architecture as a make default. It should be passing cross tools
to make and the easiest way of doing so is deferring to dh_auto_build.
That is sufficient to make gemdropx cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru gemdropx-0.9/debian/changelog gemdropx-0.9/debian/changelog
--- gemdropx-0.9/debian/changelog   2014-10-23 22:55:09.0 +0200
+++ gemdropx-0.9/debian/changelog   2018-11-17 06:36:27.0 +0100
@@ -1,3 +1,10 @@
+gemdropx (0.9-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 17 Nov 2018 06:36:27 +0100
+
 gemdropx (0.9-7) unstable; urgency=low
 
   * updated Standards-Version to 3.9.6
diff --minimal -Nru gemdropx-0.9/debian/rules gemdropx-0.9/debian/rules
--- gemdropx-0.9/debian/rules   2011-09-05 00:33:07.0 +0200
+++ gemdropx-0.9/debian/rules   2018-11-17 06:36:24.0 +0100
@@ -8,7 +8,7 @@
dh $@ 
 
 override_dh_auto_build:
-   make SOUND=YES JOY=YES DATA_PREFIX=/usr/share/games/gemdropx
+   dh_auto_build -- SOUND=YES JOY=YES DATA_PREFIX=/usr/share/games/gemdropx
 
 override_dh_auto_install:
dh_auto_install

Bug#913925: debsums incorrectly reports package as not installed

[Boyd Stephen Smith Jr.]

On Friday, November 16, 2018 9:07:13 PM CST Axel Beckert wrote:
> Please send us the output of "dpkg -l spamassassin".

---8<---
% dpkg -l spamassassin
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version   Architecture
  
Description
+++-=-=-
=-

iF  spamassassin  3.4.2-1~deb9u1all 
  
Perl-based spam filter using text analysis
--->8---

Sure enough.

Looks like some spamd process got stuck, and `service spamassassin stop` 
didn't find and kill it.  Searched it out manually, and got spamassassin to 
finish it's postinst (or whatever) setup and things are good.

debsums no longer reports that it is "not installed"

> This suspected issue has been fixed with debsums 2.2.3 (currently in
> buster and sid). From the 2.2.3 changelog entry:
> 
>   * Also allow half-configured packages to be checked.

Ah, I looked through the bugs that reportbug suggested, but none of them 
sounded like my issue.  Next time I'll try an upgrade first; the dependencies 
of debsums are generally light.  Sorry for the noise.

Feel free to close and/or reclassify as minor.

Thanks for the immediate turn-around.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Bug#913832: lists.debian.org: New mailing list: debian-runit

[Alexander Wirt]

On Sat, 17 Nov 2018, Lorenz wrote:

> On Thu, 15 Nov 2018 20:31:21 +0100
> > On Thu, 15 Nov 2018, Dmitry Bogatov wrote:
> >>...
> > > Please create new mailing list.
> >> 
> > >  Currently I do maintain runit init system and related tools {dh-runit
> > >  and *-run packages} myself, but as contributors appear, there is need
> > >  in coordinating efforts and team maintainance.
> 
> Alexander Wirt  wrote:
> > In my eyes this list is far too special for lists.debian.org.
> 
> Hi Alexander,
> as a runit user and contributor I support Dmitry request for a dedicated
> mailing list.
> Currently available way to contribute to runit are
>* Open a bug/whishlist, possibly providing a patch
>* Contact the maintainer privately with mail (1 to 1 comunication)
>* pull request on salsa
> Contributions are scattered across these three, sometimes a mix happens,
> and it's difficult to have a clear idea of what's going on.
> See bug #912937, an example of mixed public/private comunication,
> with the chat going offtopic towards runit's overall state in Debian.
> 
> A dedicated mailing list can help avoid duplication and maybe gather
> some new contributors. There is not a huge list of topics to discuss,
> but all are relevant/low level stuff like
>  * How (when/if) to integrate runit with 'init-system-helpers'
>  * maybe discuss a template for runscripts
>  * if and how introduce runlevel support
>  * how to handle emergency shell
> Those things can easily break a system and one wants to avoid
> "try --> error --> retry" routine, some discussion before may help.
> 
> Finally, for packages like *-run scripts, there will be (hopefully) more
> than one contributor,
> could be handy to have a runit mailing list to set as maintainer with
> contributors as uploaders..
> Hope you can change your mind
Thats possible, but lists.debian.org is not for package maintenance lists. 

Alex

Bug#913523: working workaround

[Carl Karsten]

using files from the syslinux package and 2 from
kernel.org/.../syslinux-6.04-pre1.tar

target=/media/sdc
sudo apt install syslinux
wget -N 
https://mirrors.edge.kernel.org/pub/linux/utils/boot/syslinux/Testing/6.04/syslinux-6.04-pre1.tar.gz
tar xf syslinux-6.04-pre1.tar.gz

mkdir -p $target/EFI/syslinux $target/EFI/BOOT
cp syslinux-6.04-pre1/efi64/efi/syslinux.efi $target/EFI/BOOT/BOOTX64.EFI
cp syslinux-6.04-pre1/efi64/com32/elflink/ldlinux/ldlinux.e64 $target/EFI/BOOT/
cp /usr/lib/syslinux/modules/efi64/* $target/EFI/syslinux

I think the fix will be something like the above (sans wget) and the
cp lines be added around here:

https://salsa.debian.org/installer-team/debian-installer/blob/master/build/config/x86.cfg#L113-115

mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/vesamenu.c32
::vesamenu.c32; \
mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/libcom32.c32
::libcom32.c32; \
mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/modules/bios/libutil.c32
::libutil.c32 ; \


-- 
Carl K

Bug#913864: kicad: Backtraces on opening cvpcb

[Seth Hillbrand]

Hi Julien-
Am 2018-11-16 22:37, schrieb Julien Goodwin:

It looks to me like the python-wxgtk and wxwidgets versioning is
orthogonal, it's just chance they happen to be similar.

I did try doing a rebuild of the python-wxgtk source package (on my
affected machine) to see if that would help, and it's the same 
behaviour.


One thing I forgot to mention, this also affected the last build of 
5.0,

before 5.0.1.


My apologies for the hasty response the first time.  I gave a poor 
response.


python-wxgtk3.0=3.0.2.0+dfsg-7 and higher are compiled against gtk3.0.  
This conflicts with the GTK2.0 versions of wxgtk3.0 that KiCad 5 is 
compiled against.  The latest version that can be used is 
python-wxgtk3.0=3.0.2.0+dfsg-6.  You will need to downgrade this 
package.


Best-
Seth

debian-bugs-dist@lists.debian.org

[Gconf is bullshit]

Package: chromium
Version: 70.0.3538.67-1~deb9u1
Severity: normal

--- Please enter the report below this line. ---

Please make gconf optional.


--- System information. ---
Architecture:
Kernel: Linux 4.9.0-8-amd64

Debian Release: 9.6
999 stable deb.debian.org
950 stretch-backports deb.debian.org
900 testing deb.debian.org
800 unstable deb.debian.org
700 experimental deb.debian.org

--- Package information. ---
Depends (Version) | Installed
==-+-===
libasound2 (>= 1.0.16) |
libatk1.0-0 (>= 1.12.4) |
libatomic1 (>= 4.8) |
libavcodec57 (>= 7:3.2.12) |
OR libavcodec-extra57 (>= 7:3.2.12) |
libavformat57 (>= 7:3.2.12) |
libavutil55 (>= 7:3.2.12) |
libc6 (>= 2.16) |
libcairo2 (>= 1.2.4) |
libcups2 (>= 1.4.0) |
libdbus-1-3 (>= 1.9.14) |
libdrm2 (>= 2.3.1) |
libevent-2.0-5 (>= 2.0.10-stable) |
libexpat1 (>= 2.0.1) |
libflac8 (>= 1.3.0) |
libfontconfig1 (>= 2.11) |
libfreetype6 (>= 2.4.2) |
libgcc1 (>= 1:4.0) |
libgdk-pixbuf2.0-0 (>= 2.22.0) |
libglib2.0-0 (>= 2.31.8) |
libgtk2.0-0 (>= 2.24.0) |
libicu57 (>= 57.1-1~) |
libjpeg62-turbo (>= 1:1.5.1-2) |
libminizip1 (>= 1.1) |
libnspr4 (>= 2:4.9-2~) |
libnss3 (>= 2:3.22) |
libopenjp2-7 (>= 2.0.0) |
libopus0 (>= 1.1) |
libpango-1.0-0 (>= 1.14.0) |
libpangocairo-1.0-0 (>= 1.14.0) |
libpangoft2-1.0-0 (>= 1.14.0) |
libpci3 (>= 1:3.5.2-1) |
libpng16-16 (>= 1.6.2-1) |
libpulse0 (>= 0.99.1) |
libre2-3 (>= 20160901) |
libsnappy1v5 |
libstdc++6 (>= 6) |
libvpx4 (>= 1.6.0) |
libwebp6 (>= 0.5.1) |
libwebpdemux2 (>= 0.5.1) |
libwebpmux2 (>= 0.5.1) |
libx11-6 (>= 2:1.4.99.1) |
libx11-xcb1 |
libxcb1 (>= 1.6) |
libxcomposite1 (>= 1:0.3-1) |
libxcursor1 (>> 1.1.2) |
libxdamage1 (>= 1:1.1) |
libxext6 |
libxfixes3 (>= 1:5.0) |
libxi6 (>= 2:1.2.99.4) |
libxml2 (>= 2.7.4) |
libxrandr2 (>= 2:1.2.99.3) |
libxrender1 |
libxslt1.1 (>= 1.1.25) |
libxss1 |
libxtst6 |
zlib1g (>= 1:1.2.2) |
x11-utils |
xdg-utils |


Recommends (Version) | Installed
===-+-===
libgl1-mesa-dri |
fonts-liberation |


Suggests (Version) | Installed
-+-===
chromium-l10n | 69.0.3497.92-1~deb9u1
chromium-shell |
chromium-driver |
chromium-widevine |

Bug#913864: kicad: Backtraces on opening cvpcb

[Julien Goodwin]

It looks to me like the python-wxgtk and wxwidgets versioning is
orthogonal, it's just chance they happen to be similar.

I did try doing a rebuild of the python-wxgtk source package (on my
affected machine) to see if that would help, and it's the same behaviour.

One thing I forgot to mention, this also affected the last build of 5.0,
before 5.0.1.

On 17/11/18 5:34 am, Seth Hillbrand wrote:
> Am 2018-11-16 12:39, schrieb Carsten Schoenert:
>> So downgrading is a bit difficult and right now before the soft freeze
>> for Buster not the right way I think.
> 
> That's a fair assessment.  I believe the issue is mixing versions.  So
> an alternate solution is to upgrade both to the 3.0.4 version.  I would
> be curious to hear if there were issues when both are running on 3.0.4
> as I haven't had any issues in Buster related to this.
> 
> -Seth

Bug#913925: debsums incorrectly reports package as not installed

[Axel Beckert]

Control: tag -1 + moreinfo

Hi,

thanks for the bug report.

b...@iguanasuicide.net wrote:
> % sudo debsums -s spamassassin
> debsums: package spamassassin is not installed
> % apt-cache policy spamassassin
> spamassassin:
>   Installed: 3.4.2-1~deb9u1
>   Candidate: 3.4.2-1~deb9u1
>   Version table:
>  3.4.2-1 700
> 700 http://mirrors.gandi.net/debian buster/main amd64 Packages
> 500 http://mirrors.gandi.net/debian sid/main amd64 Packages
>  *** 3.4.2-1~deb9u1 900
> 900 http://mirrors.gandi.net/debian stretch/main amd64 Packages
> 100 /var/lib/dpkg/status

Please send us the output of "dpkg -l spamassassin".

I suspect that the spamassassin is either not configured or half
installed or in another way not fully installed.

> Clearly, either apt-cache or debsums is wrong, and since spamassassin just
> scanned the last mail traveling through this server, I'm betting debsums is
> wrong.

Partially. That error message likely lacks the word "properly" or
"fully". because debsums up to 2.2.2 is known to report packages whose
"dpkg -l" output doesn't start with "ii" as "not installed". Hence my
suspicion that the package is not in the expected state.

This suspected issue has been fixed with debsums 2.2.3 (currently in
buster and sid). From the 2.2.3 changelog entry:

  * Also allow half-configured packages to be checked.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#913925: debsums incorrectly reports package as not installed

[bss]

Package: debsums
Version: 2.2.2
Severity: normal

Dear Maintainer,

See this zsh session:
---8<---
% sudo debsums -s spamassassin
debsums: package spamassassin is not installed
% apt-cache policy spamassassin
spamassassin:
  Installed: 3.4.2-1~deb9u1
  Candidate: 3.4.2-1~deb9u1
  Version table:
 3.4.2-1 700
700 http://mirrors.gandi.net/debian buster/main amd64 Packages
500 http://mirrors.gandi.net/debian sid/main amd64 Packages
 *** 3.4.2-1~deb9u1 900
900 http://mirrors.gandi.net/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
--->8---

Clearly, either apt-cache or debsums is wrong, and since spamassassin just
scanned the last mail traveling through this server, I'm betting debsums is
wrong.


-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'stable'), (850, 
'proposed-updates'), (700, 'testing'), (500, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-7-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debsums depends on:
ii  dpkg  1.18.25
ii  libdpkg-perl  1.18.25
ii  libfile-fnmatch-perl  0.02-2+b3
ii  perl  5.24.1-3+deb9u4
ii  ucf   3.0036

debsums recommends no packages.

debsums suggests no packages.

-- debconf information:
  debsums/apt-autogen: true

Bug#913924: ITP: project-generator-definitions -- collection of target/MCU definitions for project-generator

[Nick Morrott]

Package: wnpp
Owner: Nick Morrott 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: project-generator-definitions
  Version : 0.2.36
  Upstream Author : Martin Kojtal 
* URL : 
https://github.com/project-generator/project_generator_definitions
* License : Apache-2.0
  Programming Lang: Python
  Description : collection of target/MCU definitions for project-generator

project-generator-definitions is a dependency of project-generator [1].

  [1] https://bugs.debian.org/913923

I plan to maintain this package in the Python Applications Packaging Team.

Bug#913923: ITP: project-generator -- generate tailored project files for embedded tools (IDEs)

[Nick Morrott]

Package: wnpp
Owner: Nick Morrott 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: project-generator
  Version : 0.9.13
  Upstream Author : Martin Kojtal 
* URL : https://github.com/project-generator/project_generator
* License : Apache-2.0
  Programming Lang: Python
  Description : generate tailored project files for embedded tools (IDEs)

project-generator is a dependency of valinor [1].

  [1] https://bugs.debian.org/913920

I plan to maintain this package in the Python Applications Packaging Team.

Bug#913859: iwd: eats signals instead of dumping core

[Bernhard Übelacker]

Dear Maintainer,
while having a proper core dump would be desirable,
I tried to get some more information out this actual crash.


I assume the crash happens in the following functions,
while there might be a problem with a variable argument list.


Aborting (signal 11) [/usr/libexec/iwd]
 backtrace 
#0  0x7fb8c92d4fc0 in /lib/x86_64-linux-gnu/libc.so.6 |   
#1  0x55f5d9829edd in /usr/libexec/iwd| 0x.edd in 
l_dbus_message_new_error_valist
#2  0x55f5d9829fef in /usr/libexec/iwd| 0x.fef in 
l_dbus_message_new_error   388 reply = 
l_dbus_message_new_error_valist(method_call, name,
  |in 
dbus_error_from_errno
#3  0x55f5d97eabad in /usr/libexec/iwd| 0x.bad in 
station_dbus_scan_triggered1907reply = 
dbus_error_from_errno(err, station->scan_pending);
#4  0x55f5d97f4c75 in /usr/libexec/iwd| 0x.c75 in 
scan_request_trigger_failed128 sr->trigger(err, 
sr->userdata);
#5  0x55f5d97f64fc in /usr/libexec/iwd| 0x.4f7 in 
scan_triggered 242 
scan_request_trigger_failed(sr, err);
#6  0x55f5d9823948 in /usr/libexec/iwd| 0x.948 in 
received_data  415 
request->callback(msg, request->user_data);
#7  0x55f5d9820893 in /usr/libexec/iwd| 0x.893 in 
io_callback126 if 
(!io->read_handler(io, io->read_data)) {
#8  0x55f5d981fbcd in /usr/libexec/iwd| 0x.bcd in 
l_main_iterate (timeout=)
#9  0x55f5d981fc9c in /usr/libexec/iwd| 0x.c9c in 
l_main_run () at ell/main.c:434
#10 0x55f5d97dde97 in /usr/libexec/iwd| 0x.e97 in main 
(argc=, argv=) at src/main.c:489
#11 0x7fb8c92c1b17 in /lib/x86_64-linux-gnu/libc.so.6 | 0x.b17 in 
__libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
+++


Kind regards,
Bernhard





# buster
apt update
apt dist-upgrade

apt install gdb iwd
# Entpacken von iwd (0.10-1) ...




root@debian:~# gdb -q --pid 462
Attaching to process 462
Reading symbols from /usr/libexec/iwd...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...(no debugging symbols 
found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols 
found)...done.
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
0x7f9a110361c7 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x7f9a110361c7 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x55c3e8fe8b75 in ?? ()
#2  0x55c3e8fe8c9c in ?? ()
#3  0x55c3e8fa6e97 in ?? ()
#4  0x7f9a10f60b17 in __libc_start_main () from 
/lib/x86_64-linux-gnu/libc.so.6
#5  0x55c3e8fa747a in ?? ()
(gdb) detach
Detaching from program: /usr/libexec/iwd, process 462
(gdb) q




apt install mc devscripts dpkg-dev gdb iwd iwd-dbgsym libc6-dbg
apt build-dep iwd


mkdir iwd/orig -p
cdiwd/orig
apt source iwd
cd ../..


root@debian:~# gdb -q --pid 462
Attaching to process 462
Reading symbols from /usr/libexec/iwd...Reading symbols from 
/usr/lib/debug/.build-id/98/c983915707eecdbe437d08043dae58306ecaad.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...Reading symbols from 
/usr/lib/debug/.build-id/2b/51cce982e540854dd1995136601f770f127b05.debug...done.
done.
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from 
/usr/lib/debug/.build-id/e9/38fe6706abe362f6c3c7474373ccc626cf4805.debug...done.
done.
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from 
/usr/lib/debug/.build-id/fa/01a234506568b77ad2d1a6da398e45586c550b.debug...done.
done.
0x7f9a110361c7 in epoll_wait (epfd=3, events=events@entry=0x7fff609828f0, 
maxevents=maxevents@entry=10, timeout=-1) at 
../sysdeps/unix/sysv/linux/epoll_wait.c:30
30  ../sysdeps/unix/sysv/linux/epoll_wait.c: Datei oder Verzeichnis nicht 
gefunden.
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  0x7f9a110361c7 in epoll_wait (epfd=3, 
events=events@entry=0x7fff609828f0, maxevents=maxevents@entry=10, timeout=-1) 
at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1  0x55c3e8fe8b75 in l_main_iterate (timeout=) at 
ell/main.c:373
#2  0x55c3e8fe8c9c in l_main_run () at ell/main.c:434
#3  0x55c3e8fa6e97 in main (argc=, argv=) at 
src/main.c:489
(gdb) disassemble l_main_iterate
Dump of assembler code for function l_main_iterate:
   0x55c3e8fe8b40 <+0>: push   %r13
   0x55c3e8fe8b42 <+2>: mov%edi,%ecx
   0x55c3e8fe8b44 <+4>: mov$0xa,%edx
   0x55c3e8fe8b49 <+9>: push   %r12
   0x55c3e8fe8b4b <+11>:push   %rbp
   0x55c3e8fe8b4c <+12>:push

Bug#913914: gnustep-base-runtime: 717773 regression, gdomap autostarts

[Jean-Francois Pirus]

Hi, yes you are correct, it currently doesn't set it to enable any
more. Sorry about that.

Looks like it was enabled when I initially installed in on 8 March
2017.

It just kept the enabled status in later upgrades.

Thanks.


lrwxrwxrwx   1 root root16 Mar  8  2017 K01gdomap ->
../init.d/gdomap
lrwxrwxrwx   1 root root16 Mar  8  2017 K01gdomap ->
../init.d/gdomap
lrwxrwxrwx   1 root root16 Mar  8  2017 S03gdomap ->
../init.d/gdomap
lrwxrwxrwx   1 root root16 Mar  8  2017 S03gdomap ->
../init.d/gdomap
lrwxrwxrwx   1 root root16 Mar  8  2017 S03gdomap ->
../init.d/gdomap
lrwxrwxrwx   1 root root16 Mar  8  2017 S03gdomap ->
../init.d/gdomap
lrwxrwxrwx   1 root root16 Mar  8  2017 K01gdomap ->
../init.d/gdomap


On Sat, 2018-11-17 at 00:16 +0200, Yavor Doganov wrote:
> Control: tags -1 = moreinfo unreproducible
> 
> jfp wrote:
> > Package: gnustep-base-runtime
> > Version: 1.25.1-4+b1
> > On install of gnustep-base-runtime (dependency of unar)
> > 
> > It set the gdomap service to autotart.
> 
> Thanks for the report but I'm afraid I can't reproduce this:
> 
> $ systemctl status gdomap
> ● gdomap.service - LSB: Start the GNUstep distributed object mapper
>Loaded: loaded (/etc/init.d/gdomap; generated)
>Active: inactive (dead)
>  Docs: man:systemd-sysv-generator(8)
> 
> $ systemctl is-enabled gdomap
> gdomap.service is not a native service, redirecting to systemd-sysv-
> install.
> Executing: /lib/systemd/systemd-sysv-install is-enabled gdomap
> disabled
> 
> That should be the case for new installations AFAICT.
> 
> > Fix is:
> > in /etc/init.d/gdomap
> > change
> >  # Default-Start: 2 3 4 5
> > to
> >  # Default-Start:
> 
> Are you sure?  I don't think this LSB header is relevant for systemd
> but I'm not familiar enough with it to be certain.
> 
> Anyway, I'll also pass --no-start to dh_installinit, fortunately it
> helps...

Bug#913921: Acknowledgement (Please consider linking against prce2)

[Michael Biebl]

Forgot to update the dependencies of libselinux1-dev

Updated patch attached.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff -Nru libselinux-2.8/debian/changelog libselinux-2.8/debian/changelog
--- libselinux-2.8/debian/changelog 2018-05-28 20:50:31.0 +0200
+++ libselinux-2.8/debian/changelog 2018-11-17 02:17:10.0 +0100
@@ -1,3 +1,10 @@
+libselinux (2.8-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build against PCRE2. (Closes: #913921)
+
+ -- Michael Biebl   Sat, 17 Nov 2018 02:17:10 +0100
+
 libselinux (2.8-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru libselinux-2.8/debian/control libselinux-2.8/debian/control
--- libselinux-2.8/debian/control   2018-05-28 20:50:31.0 +0200
+++ libselinux-2.8/debian/control   2018-11-17 02:17:10.0 +0100
@@ -12,7 +12,7 @@
file,
gem2deb (>= 0.5.0~) ,
libsepol1-dev (>= 2.8),
-   libpcre3-dev,
+   libpcre2-dev,
pkg-config,
python-all-dev (>= 2.6.6-3~) ,
python3-all-dev ,
@@ -62,7 +62,7 @@
 Architecture: linux-any
 Depends: libselinux1 (= ${binary:Version}),
  libsepol1-dev (>= 2.8),
- libpcre3-dev,
+ libpcre2-dev,
  ${misc:Depends}
 Section: libdevel
 Multi-Arch: same
diff -Nru libselinux-2.8/debian/rules libselinux-2.8/debian/rules
--- libselinux-2.8/debian/rules 2018-05-28 20:50:31.0 +0200
+++ libselinux-2.8/debian/rules 2018-11-17 02:17:03.0 +0100
@@ -53,6 +53,7 @@
 extra_make_args = ARCH=$(DEB_HOST_GNU_CPU)
 extra_make_args += CC=$(DEB_HOST_GNU_TYPE)-gcc
 extra_make_args += PKG_CONFIG=$(PKG_CONFIG)
+extra_make_args += USE_PCRE2=y
 override_dh_auto_build: FORCE
+$(MAKE) $(extra_make_args) all
 


signature.asc
Description: OpenPGP digital signature

Bug#763703: Purpose of -f

[Jesse Smith]

The purpose of the (undocumented) startpar -f flag is to read from stdin
and write whatever it finds to to stdout. That's pretty much all it
does. And it keeps going until it runs out of input.

I'm not sure why it would do that or why someone would call startpar
with that parameter since it doesn't seem to do anything useful. The
program just keeps passing stdin to stdout until it reaches an
end-of-input flag (like ctrl-d) or someone kills it. I don't even think
startpar is running the given commands (sks and shellinabox) in the
above situations as it exits after doing its input-to-output copying.

So my suggestion is: looks like someone called startpar with -f, perhaps
by accident in a script. And the -f flag should probably not have been
used in that case. And the lingering startpar processes can be terminated.

- Jesse (upstream dev)

Bug#913921: Please consider linking against prce2

[Michael Biebl]

Source: libselinux
Version: 2.8-1+b1
Severity: normal
Tags: patch

Hi,

pcre2 is the successor of pcre.
Afaics, libselinux allows linking against pcre2 instead of pcre.
Please consider switching it over to the newer version of the library.

Build-tested patch is attached.

Regards,
Michael


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libselinux-2.8/debian/changelog libselinux-2.8/debian/changelog
--- libselinux-2.8/debian/changelog 2018-05-28 20:50:31.0 +0200
+++ libselinux-2.8/debian/changelog 2018-11-17 02:17:10.0 +0100
@@ -1,3 +1,10 @@
+libselinux (2.8-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build against PCRE2.
+
+ -- Michael Biebl   Sat, 17 Nov 2018 02:17:10 +0100
+
 libselinux (2.8-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru libselinux-2.8/debian/control libselinux-2.8/debian/control
--- libselinux-2.8/debian/control   2018-05-28 20:50:31.0 +0200
+++ libselinux-2.8/debian/control   2018-11-17 02:13:41.0 +0100
@@ -12,7 +12,7 @@
file,
gem2deb (>= 0.5.0~) ,
libsepol1-dev (>= 2.8),
-   libpcre3-dev,
+   libpcre2-dev,
pkg-config,
python-all-dev (>= 2.6.6-3~) ,
python3-all-dev ,
diff -Nru libselinux-2.8/debian/rules libselinux-2.8/debian/rules
--- libselinux-2.8/debian/rules 2018-05-28 20:50:31.0 +0200
+++ libselinux-2.8/debian/rules 2018-11-17 02:17:03.0 +0100
@@ -53,6 +53,7 @@
 extra_make_args = ARCH=$(DEB_HOST_GNU_CPU)
 extra_make_args += CC=$(DEB_HOST_GNU_TYPE)-gcc
 extra_make_args += PKG_CONFIG=$(PKG_CONFIG)
+extra_make_args += USE_PCRE2=y
 override_dh_auto_build: FORCE
+$(MAKE) $(extra_make_args) all
 

Bug#913922: policykit-1: "...Error executing command as another user: Not authorized..."

[Awtul]

Package: policykit-1
Version: 0.105-21
Severity: important

Dear Maintainer,

thunar won't be launched by pkexec:

"pkexec thunar %f
 AUTHENTICATING FOR org.xfce.thunar ===
Authentication is required to run Thunar as root.
Authenticating as: root
Password: 
polkit-agent-helper-1: error response to PolicyKit daemon: 
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
 AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

This incident has been reported."


--
auth.log:

Nov 16 19:45:10 xxx polkitd(authority=local): Registered Authentication Agent 
for unix-process:11239:790825 (system bus name :1.142 [pkexec thunar %f], 
object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Nov 16 19:45:16 xxx polkitd(authority=local): Operator of 
unix-process:11239:790825 FAILED to authenticate to gain authorization for 
action org.xfce.thunar for unix-process:11239:790825 [bash] (owned by 
unix-user:x)
Nov 16 19:45:16 xxx pkexec[11316]: x: Error executing command as another user: 
Not authorized [USER=root] [TTY=/dev/pts/3] [CWD=/home/x] 
[COMMAND=/usr/bin/thunar %f]
Nov 16 19:45:16 xxx polkitd(authority=local): Unregistered Authentication Agent 
for unix-process:11239:790825 (system bus name :1.142, object path 
/org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)

---

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_ES:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages policykit-1 depends on:
ii  dbus   1.12.10-1
ii  libc6  2.27-8
ii  libglib2.0-0   2.58.1-2
ii  libpam-systemd 239-11
ii  libpam0g   1.1.8-3.8
ii  libpolkit-agent-1-00.105-21
ii  libpolkit-backend-1-0  0.105-21
ii  libpolkit-gobject-1-0  0.105-21

policykit-1 recommends no packages.

policykit-1 suggests no packages.

-- no debconf information

Bug#907651: grep: dlopens libpcre, but is directly linked to it anyway

[Michael Biebl]

On Fri, 26 Oct 2018 10:31:08 +0200 Laurent Bigonville 
wrote:
> Hello,
> 
> Wasn't the initial idea of this patch to be able to have libpcre on 
> /usr/lib and grep on /bin? https://savannah.gnu.org/patch/?7017#comment0 
> seems to confirm that.
> 
> And now that libpcre is in installed in /lib, the patch has probably 
> lost his meaning.

Also keep in mind, that late-mounting of /usr is no longer supported.
/usr needs to be on the same partition as / or mounted via the
initramfs, so this patch has become obsolete.

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#913832: lists.debian.org: New mailing list: debian-runit

[Lorenz]

On Thu, 15 Nov 2018 20:31:21 +0100
> On Thu, 15 Nov 2018, Dmitry Bogatov wrote:
>>...
> > Please create new mailing list.
>> 
> >  Currently I do maintain runit init system and related tools {dh-runit
> >  and *-run packages} myself, but as contributors appear, there is need
> >  in coordinating efforts and team maintainance.

Alexander Wirt  wrote:
> In my eyes this list is far too special for lists.debian.org.

Hi Alexander,
as a runit user and contributor I support Dmitry request for a dedicated
mailing list.
Currently available way to contribute to runit are
   * Open a bug/whishlist, possibly providing a patch
   * Contact the maintainer privately with mail (1 to 1 comunication)
   * pull request on salsa
Contributions are scattered across these three, sometimes a mix happens,
and it's difficult to have a clear idea of what's going on.
See bug #912937, an example of mixed public/private comunication,
with the chat going offtopic towards runit's overall state in Debian.

A dedicated mailing list can help avoid duplication and maybe gather
some new contributors. There is not a huge list of topics to discuss,
but all are relevant/low level stuff like
 * How (when/if) to integrate runit with 'init-system-helpers'
 * maybe discuss a template for runscripts
 * if and how introduce runlevel support
 * how to handle emergency shell
Those things can easily break a system and one wants to avoid
"try --> error --> retry" routine, some discussion before may help.

Finally, for packages like *-run scripts, there will be (hopefully) more
than one contributor,
could be handy to have a runit mailing list to set as maintainer with
contributors as uploaders..
Hope you can change your mind

Best Regards,
Lorenzo

Bug#679630: Applying patch upstream

[Jesse Smith]

The patch makes sense to me and does not appear to have any side
effects. Am applying it upstream in startpar-0.61.

- Jesse

Bug#913920: ITP: valinor -- generate IDE project files to debug ELF files

[Nick Morrott]

Package: wnpp
Owner: Nick Morrott 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: valinor
  Version : 0.0.11+git20160222.486094a
  Upstream Author : ARM Limited
* URL : https://github.com/ARMmbed/valinor
* License : Apache-2.0
  Programming Lang: Python
  Description : generate IDE project files to debug ELF files

Valinor is used to generate debugger project files, and launch a debugger, when 
debugging an ELF file.

Valinor is designed to be used as a proxy debug command for yotta targets to 
provide as their scripts.debug command.

Valinor is a dependency of yotta [1].

  [1] https://bugs.debian.org/908781

I plan to maintain this package in the Python Applications Packaging Team.

Bug#913919: Policykit-1: "...Error executing command as another user: Not authorized..."

[Awtul]

Package: policykit-1
Version: 0.105-21
Severity: important

Dear Maintainer,

thunar won't open via pkexec. I get:

"pkexec thunar %f
 AUTHENTICATING FOR org.xfce.thunar ===
Authentication is required to run Thunar as root.
Authenticating as: root
Password: 
polkit-agent-helper-1: error response to PolicyKit daemon: 
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
 AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

This incident has been reported."

-

After executing "pkexec thunar %f" I see in /var/log/auth.log I see:

Nov 16 19:22:03 my-user-name polkitd(authority=local): Registered 
Authentication Agent for unix-process:9445:650488 (system bus name :1.129 
[pkexec thunar %f], object path 
/org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Nov 16 19:22:09 my-user-name polkitd(authority=local): Operator of 
unix-process:9445:650488 FAILED to authenticate to gain authorization for 
action org.xfce.thunar for unix-process:9445:650488 [bash] (owned by 
unix-user:xc)
Nov 16 19:22:09 my-user-name pkexec[9521]: xc: Error executing command as 
another user: Not authorized [USER=root] [TTY=/dev/pts/3] [CWD=/home/xc] 
[COMMAND=/usr/bin/thunar %f]
Nov 16 19:22:09 my-user-name polkitd(authority=local): Unregistered 
Authentication Agent for unix-process:9445:650488 (system bus name :1.129, 
object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)

--

Cheers,

Awtul

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_ES:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages policykit-1 depends on:
ii  dbus   1.12.10-1
ii  libc6  2.27-8
ii  libglib2.0-0   2.58.1-2
ii  libpam-systemd 239-11
ii  libpam0g   1.1.8-3.8
ii  libpolkit-agent-1-00.105-21
ii  libpolkit-backend-1-0  0.105-21
ii  libpolkit-gobject-1-0  0.105-21

policykit-1 recommends no packages.

policykit-1 suggests no packages.

-- no debconf information

Bug#913728: ganeti-2.15: Can not export/import VMs using gnt-backup

[Apollon Oikonomopoulos]

Control: tags -1 moreinfo

Hi again,

On 09:06 Wed 14 Nov , Maximiliano Boscovich wrote:
> root@lisa:~# gnt-backup export -n lisa acme.sf-az2-fe
> Wed Nov 14 08:13:51 2018 Shutting down instance acme.sf-az2-fe
> Wed Nov 14 08:15:53 2018 Creating a snapshot of disk/0 on node lisa
> Wed Nov 14 08:15:53 2018 Starting instance acme.sf-az2-fe
> Wed Nov 14 08:15:54 2018 Exporting snapshot/0 from lisa to lisa
> Wed Nov 14 08:15:57 2018 snapshot/0 is now listening, starting export
> Wed Nov 14 08:16:05 2018 snapshot/0 sent 0M, 0.0 MiB/s
> Wed Nov 14 08:16:55 2018  - WARNING: import
> 'import-disk0-2018-11-14_08_15_54-a5_3EV' on lisa failed: Exited due to
> signal 15
> Wed Nov 14 08:16:55 2018 snapshot/0 failed to receive data: Exited due to
> signal 15 (recent output: Child process didn't establish connection in time
> (60s), sending SIGTERM\nsocat: W exiting on signal 15)
> Wed Nov 14 08:16:55 2018  - WARNING: Aborting export
> 'export-disk0-2018-11-14_08_15_59-6wxfk8' on
> b2e076b8-499a-45a0-8a65-1a4d2005708f
> Wed Nov 14 08:16:57 2018  - WARNING: export
> 'export-disk0-2018-11-14_08_15_59-6wxfk8' on lisa failed: Exited due to
> signal 15
> Wed Nov 14 08:16:57 2018 snapshot/0 failed to send data: Exited due to
> signal 15 (recent output:   DUMP: Date of this level 0 dump: Wed Nov 14
> 08:15:59 2018\n  DUMP: Dumping
> /dev/mapper/vg--ganeti-76049ec2--8232--413d--8151--d263c3efa80e.disk0.snap-1
> (an unlisted file system) to standard output\n  DUMP: Label: none\n  DUMP:
> Writing 10 Kilobyte records\n  DUMP: mapping (Pass I) [regular files]\n
> DUMP: mapping (Pass II) [directories]\n  DUMP: estimated 247771 blocks.\n
> DUMP: Volume 1 started with block 1 at: Wed Nov 14 08:15:59 2018\n  DUMP:
> dumping (Pass III) [directories]\n  DUMP:   DUMP: The ENTIRE dump is
> aborted.\nSignal on pipe: cannot recover\n  DUMP: The ENTIRE dump is
> aborted.\nsocat: W exiting on signal 15)
> Wed Nov 14 08:16:57 2018 Removing snapshot of disk/0 on node lisa
> Wed Nov 14 08:16:57 2018  - WARNING: Some disk exports have failed; there
> may be leftover data for instance acme.sf-az2-fe on node lisa
> Failure: command execution error:
> Export failed, errors in export finalization, disk export: disk(s) 0

I can reproduce this when blocking the import/export connections between 
nodes. Are you running a firewall on the machine? If so, does it filter 
traffic on the loopback interface? Keep in mind that import/export uses 
two completely random, high ports for the transfer.

Regards,
Apollon

Bug#910943: libhtml-tidy-perl: Please upload pending 1.60-2 and coordinate with libtidy transition

[gregor herrmann]

On Fri, 16 Nov 2018 10:43:58 -0500, Boyuan Yang wrote:

> > > What do you think would be the proper solution? I suppose we upload
> > > a tidy-html5 2:5.6.0-9 to drop the reverted part since the next major
> > > version of tidy-html5 will adapt such behaviour change anyway.
> > Right, I think that makes sense.
> I have made the 2:5.6.0-9 upload and the autopkgtest is passing.

Thanks.
Let's hope this fix lasts for some time now :)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Cássia Eller: O Segundo Sol


signature.asc
Description: Digital Signature

Bug#913659: Document that not all bugs are policy violations

[Henrique de Moraes Holschuh]

On Fri, 16 Nov 2018, Sean Whitton wrote:
> On Fri 16 Nov 2018 at 12:22PM -0200, Henrique de Moraes Holschuh wrote:
> > How about also adding one that makes it clear that in *Debian*, policy
> > follows practice, and not the other way around (which should also
> > require seconds just to make sure people agree with this, even if it is
> > a decades-long practice in debian-policy)...
> 
> This is already there, in § 1.3.3

Not in such a clearly stated form, but yeah.  Anyway, that was a passing
comment, it is off-topic on this bug report, and for that I apologise...

-- 
  Henrique Holschuh

Bug#870301: systemd: Touchpad fix Dell Inspiron Mini 1012

[Michael Biebl]

On Sat, 17 Mar 2018 03:23:59 +0100 Michael Biebl  wrote:
> On Tue, 30 Jan 2018 04:30:58 -0500 (EST) bw  wrote:
> 
> > I'll go back and read your earlier posts, and see what I need to do.  I 
> > guess you are recommending that I upgrade systemd and use upstream bug 
> > reporting instead of debian bugtracker?
> 
> Yes, please upgrade to v238, try to reproduce your (libinput) problem,
> if it still exists, file a bug report upstream at
> https://github.com/systemd/systemd/issues
> and report back with the bug number.

Any updates here?

-- 
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#911424: systemd-rfkill screws up iwlwifi

[Michael Biebl]

On Sat, 20 Oct 2018 16:47:01 +0200 Michael Biebl  wrote:
> What happens if you manually (as root) execute
> /lib/systemd/systemd-rfkill
> 
> Does this have any influence on your wifi connection?
> 
...

On Sat, 20 Oct 2018 16:33:23 +0200 Michael Biebl 
wrote:> Am 20.10.18 um 04:02 schrieb bw:
> > Sorry, the file reportbug placed in /tmp was some kind of weird also.
> >
> > The short version is, frequent disconnects using iwlfifi device:
>
> systemd-rfkill seems to to be a symptom of your problem not the cause.
> "something" is triggering rfkill block/unblock requests for your WiFi
> hardware and systemd-rfkill reacts on that.
>
> Can you provide a "udevadm monitor" log with systemd-rfkill masked and
> one without it being masked.
>
> Ideally mark in the log when the disconnects happen.

Ping, any updates here?
-- 
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#913918: systemd improvements

[Simon Deziel]

Package: nsd
Version: 4.1.25-3

Hello,

I noticed the switch to Type=notify (yay!) and when playing with the
unpublished version (4.1.25-3), I found some things that could be
improved which lead me to open this merge request [1].

Regards,
Simon

1: https://salsa.debian.org/dns-team/nsd/merge_requests/1



signature.asc
Description: OpenPGP digital signature

Bug#870468: grdesktop FTCBFS: broken PKG_CHECK_MODULES copy uses build arch pkg-config

[Yavor Doganov]

Jeremy Bicha wrote:
> On Fri, Nov 16, 2018 at 2:26 AM Yavor Doganov  wrote:
> > > Using autoreconf is part of the solution. Usually though, autoreconf
> > > prefers macros in the source over system copies. So if your source still
> > > contains the (outdated) copy, autoreconf will prefer it.
> >
> > That's not true if autoreconf is being run with the --force option
> > (which dh_autoreconf does); all files are considered obsolete then.
> 
> In my experience, Helmut is right.

No, in this particular case he is not right; you are both confusing
two different use cases that have different (documented) behavior.
The --force option causes the output file (aclocal.m4) to be generated
always.  If the package is not shipping the third-party macro (as is
the case with grdesktop -- it is not shipping pkg.m4), --force will
always recreate aclocal.m4 using the macro definition as found in
aclocal's search path (or autoreconf will fail if it cannot find it).

IOW, it is not necessary to patch aclocal.m4 as it is always going to
be regenerated by dh_autoreconf.

> So in some of my packages, I've been adding the autoconf macros to
> Files-Excluded so that they aren't part of the Debian source when
> importing new tarball releases to ensure we actually build from the
> latest sources instead of sometimes ancient macros.

This happens when the package ships convenience copies of third-party
macros in the directory defined by AC_CONFIG_MACRO_DIR.  In this case
you are both right that --force will not replace these macros with the
ones from the system.  "aclocal --install" will do (respecting the
serial numbers so it won't downgrade macros); the other option is to
delete the files as you have been doing.  However, this sometimes
results in regression if the package was bootstrapped by the upstream
maintainer with a newer version of the package providing the third
party macro than the one in Debian.  (Happens all the time with
packages using gnulib as it's almost always outdated in Debian.)

Bug#911297: wpasupplicant needs to override default OpenSSL settings to work with enterprise networks

[Andrej Shadura]

On Fri, 16 Nov 2018 at 09:36, Sam Morris  wrote:
>
> Package: wpasupplicant
> Version: 2:2.4-1+deb9u1
> Followup-For: Bug #911297
>
> See /usr/share/doc/libssl1.1/NEWS.Debian.gz and try editing the end of
> /etc/ssl/openssl.cnf:
>
> MinProtocol = None
> CipherString = DEFAULT
>
> I believe OpenSSL clients can call SSL_CONF_cmd(3ssl) in order to
> change the new defaults (TLSv1.2, security level 2) back to something
> more permissive. wpasupplicant should probably be doing this because
> enterprise networks are not going to upgrade to anything as new as
> TLSv1.2 (2008) overnight.
>
> For bonus points, the minimum TLS version and CipherString could be
> exposed in NetworkManager's GUI and passed down to wpasupplicant, but
> that's way too much work given that we're about to freeze for buster!

This bug seems to be a dup for #907518. There’s a user-configurable
setting for wpa_supplicant already, and I’m not sure it’s a very good
idea to make this a default.

-- 
Cheers,
  Andrej

Bug#913917: ITP: gajim-openpgp -- OpenPGP for XMPP

[W. Martin Borgert]

Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert" 

* Package name: gajim-openpgp
  Version : 1.1.1
  Upstream Author : Philipp Hörist 
* URL : 
https://dev.gajim.org/gajim/gajim-plugins/blob/gajim_1.1/openpgp/manifest.ini
* License : GPL3
  Programming Lang: Python
  Description : OpenPGP for XMPP

This is an experimental plugin supporting the new OpenPGP for XMPP
standard XEP-0373 (https://xmpp.org/extensions/xep-0373.html).

The package will be maintained with the XMPP packaging team.

Bug#913116: Needs to depend on chromium-sandbox

[Josh Triplett]

On Fri, 16 Nov 2018 10:20:07 +0100 Bastian Blank  wrote:
> Debian does not support unprivileged user namespaces, so chromium needs
> to depend on -sandbox to get a working package.

Should we, perhaps, support unprivileged user namespaces? Or, at least,
a means of granting targeted permission to use such namespaces without
being full root?

Bug#885958: hostapd: iwlwifi 5GHz hw_mode=a causes microcode fault

[Andrej Shadura]

Control: reassing -1 linux-firmware

On Sun, 31 Dec 2017 15:24:18 -0800 Nye Liu  wrote:
> Package: hostapd
> Version: 2:2.6-15
> Severity: important
> 
> [51085.431307] iwlwifi :03:00.0: Microcode SW error detected.  Restarting 
> 0x8200.
> [51085.431410] iwlwifi :03:00.0: Start IWL Error Log Dump:
> [51085.431412] iwlwifi :03:00.0: Status: 0x0100, count: 6
> [51085.431413] iwlwifi :03:00.0: Loaded firmware version: 29.541020.0
> [51085.431414] iwlwifi :03:00.0: 0x14FC | ADVANCED_SYSASSERT
> [51085.431415] iwlwifi :03:00.0: 0x02F0 | trm_hw_status0
> [51085.431416] iwlwifi :03:00.0: 0x | trm_hw_status1
> [51085.431416] iwlwifi :03:00.0: 0x00043D58 | branchlink2
> [51085.431417] iwlwifi :03:00.0: 0x0004AFE2 | interruptlink1
> [51085.431418] iwlwifi :03:00.0: 0x | interruptlink2
> [51085.431419] iwlwifi :03:00.0: 0x3000 | data1
> [51085.431420] iwlwifi :03:00.0: 0x07E1 | data2
> [51085.431420] iwlwifi :03:00.0: 0x00090010 | data3
> [51085.431421] iwlwifi :03:00.0: 0x | beacon time
> [51085.431422] iwlwifi :03:00.0: 0x004CA5CA | tsf low
> [51085.431423] iwlwifi :03:00.0: 0x | tsf hi
> [51085.431424] iwlwifi :03:00.0: 0x | time gp1
> [51085.431425] iwlwifi :03:00.0: 0x004CA5CA | time gp2
> [51085.431425] iwlwifi :03:00.0: 0x0001 | uCode revision type
> [51085.431426] iwlwifi :03:00.0: 0x001D | uCode version major
> [51085.431427] iwlwifi :03:00.0: 0x0008415C | uCode version minor
> [51085.431428] iwlwifi :03:00.0: 0x0220 | hw version
> [51085.431429] iwlwifi :03:00.0: 0x00C89200 | board version
> [51085.431429] iwlwifi :03:00.0: 0x0022012B | hcmd
> [51085.431430] iwlwifi :03:00.0: 0x00022080 | isr0
> [51085.431431] iwlwifi :03:00.0: 0x | isr1
> [51085.431432] iwlwifi :03:00.0: 0x0002 | isr2
> [51085.431433] iwlwifi :03:00.0: 0x004000C0 | isr3
> [51085.431433] iwlwifi :03:00.0: 0x | isr4
> [51085.431434] iwlwifi :03:00.0: 0x002101D1 | last cmd Id
> [51085.431435] iwlwifi :03:00.0: 0x | wait_event
> [51085.431436] iwlwifi :03:00.0: 0x0080 | l2p_control
> [51085.431437] iwlwifi :03:00.0: 0x | l2p_duration
> [51085.431437] iwlwifi :03:00.0: 0x | l2p_mhvalid
> [51085.431438] iwlwifi :03:00.0: 0x | l2p_addr_match
> [51085.431439] iwlwifi :03:00.0: 0x0007 | lmpm_pmg_sel
> [51085.431440] iwlwifi :03:00.0: 0x15061956 | timestamp
> [51085.431441] iwlwifi :03:00.0: 0x2030 | flow_handler
> [51085.431443] ieee80211 phy0: Hardware restart was requested
> [51085.431478] iwlwifi :03:00.0: FW error in SYNC CMD BINDING_CONTEXT_CMD
> [51085.431481] CPU: 3 PID: 31109 Comm: hostapd Not tainted 4.14.0-2-amd64 #1 
> Debian 4.14.7-1
> [51085.431482] Hardware name: To Be Filled By O.E.M. To Be Filled By 
> O.E.M./H270M-ITX/ac, BIOS P2.00 03/29/2017
> [51085.431483] Call Trace:
> [51085.431487]  dump_stack+0x63/0x8b
> [51085.431493]  iwl_trans_pcie_send_hcmd+0x447/0x490 [iwlwifi]
> [51085.431496]  ? finish_wait+0x80/0x80
> [51085.431499]  iwl_trans_send_cmd+0x5c/0xc0 [iwlwifi]
> [51085.431504]  iwl_mvm_send_cmd_status+0x2f/0xb0 [iwlmvm]
> [51085.431507]  iwl_mvm_send_cmd_pdu_status+0x57/0x80 [iwlmvm]
> [51085.431511]  iwl_mvm_binding_update+0x169/0x230 [iwlmvm]
> [51085.431514]  ? iwl_mvm_binding_update+0x169/0x230 [iwlmvm]
> [51085.431517]  iwl_mvm_binding_add_vif+0x55/0x80 [iwlmvm]
> [51085.431520]  iwl_mvm_start_ap_ibss+0xb0/0x1c0 [iwlmvm]
> [51085.431534]  ieee80211_start_ap+0x2bd/0x4a0 [mac80211]
> [51085.431548]  nl80211_start_ap+0x497/0x780 [cfg80211]
> [51085.431552]  genl_family_rcv_msg+0x1f5/0x3e0

I’m not sure what exactly hostapd has to do with that. It is probably an
issue with the firmware, possibly with the kernel driver.

-- 
Cheers,
  Andrej

Bug#913914: gnustep-base-runtime: 717773 regression, gdomap autostarts

[Yavor Doganov]

Control: tags -1 = moreinfo unreproducible

jfp wrote:
> Package: gnustep-base-runtime
> Version: 1.25.1-4+b1

> On install of gnustep-base-runtime (dependency of unar)
> 
> It set the gdomap service to autotart.

Thanks for the report but I'm afraid I can't reproduce this:

$ systemctl status gdomap
● gdomap.service - LSB: Start the GNUstep distributed object mapper
   Loaded: loaded (/etc/init.d/gdomap; generated)
   Active: inactive (dead)
 Docs: man:systemd-sysv-generator(8)

$ systemctl is-enabled gdomap
gdomap.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install is-enabled gdomap
disabled

That should be the case for new installations AFAICT.

> Fix is:
> in /etc/init.d/gdomap
> change
>  # Default-Start: 2 3 4 5
> to
>  # Default-Start:

Are you sure?  I don't think this LSB header is relevant for systemd
but I'm not familiar enough with it to be certain.

Anyway, I'll also pass --no-start to dh_installinit, fortunately it
helps...

Bug#913880: ITP: overlay-userns -- Overlay mounting in user namespaces (DKMS)

[Ben Hutchings]

Why don't you talk to the kernel team about adding a module parameter
enable this, rather than packaging a fragile hack?

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.



signature.asc
Description: This is a digitally signed message part

Bug#657107: developers-reference : styles of handwriting are Bold

[Holger Wansing]

Control: tags -1 + wontfix


Nobuhiro Iwamatsu  wrote:
> A.2.2. debdiff,  A.5.3. dcut and A.6.7. dpkg-depcheck styles of
> handwriting are Bold.
> It seems that it will be changed into bold if it surrounds by .
> Commands other than these are surrounded by .
> Therefore, the style of handwriting is not Bold.

As I see it, this is only a very minor difference, and thus not worse a change.


So tagging this bug as wontfix.

Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#913916: grub-efi-amd64: UEFI boot option removed after update to grub2 2.02~beta3-5+deb9u1

[Tobias Hansen]

Package: grub-efi-amd64
Version: 2.02~beta3-5+deb9u1
Severity: critical

After updating grub2 in Debian stable to 2.02~beta3-5+deb9u1 the UEFI boot 
option was removed on my Dell Latitude 5480. After rebooting I was greeted with 
"No bootable devices found". In the setup utility (reached by pressing F2) the 
UEFI boot sequence was empty. I could fix the problem by adding a new boot 
option, selecting the file EFI/debian/grubx64.efi.

I could reproduce this by downgrading the installed grub2 packages 
(grub2-common, grub-common, grub-efi-amd64, grub-efi-amd64-bin) to 
2.02~beta3-5, making sure the boot option is there, and updating the packages 
to 2.02~beta3-5+deb9u1 again. After the update the boot option is gone. Just 
rebooting with either of the versions does not remove the boot option.

There is no indication during the update that something went wrong:

Setting up grub-efi-amd64 (2.02~beta3-5+deb9u1) ...

Installing for x86_64-efi platform.

Installation finished. No error reported.

Generating grub configuration file ...

Found background image: .background_cache.png

Found linux image: /boot/vmlinuz-4.9.0-8-amd64

Found initrd image: /boot/initrd.img-4.9.0-8-amd64

Found linux image: /boot/vmlinuz-4.9.0-7-amd64

Found initrd image: /boot/initrd.img-4.9.0-7-amd64

Adding boot menu entry for EFI firmware configuration

done

Best,
Tobias

Bug#871105: Status of debian-faq

[Dr. Tobias Quathamer]

Hi Joost,

are you still planning to do an upload of debian-faq? Or are any other
members of the maintaining team planning an upload?

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#911803: preliminary building package

[Jeffrey Cliff]

a building preliminary package is available at the above link, under a
slightly renamed package name.

It is giving a lintian warning still (see issue #3 -
https://notabug.org/makenotabuggreatagain/clog/issues/3 ), but it is
building

Bug#913846: qtox: Uninstallable on at least amd64 (might need binNMU against recent ffmpeg)

[Adrian Bunk]

Control: reassign -1 release.debian.org
Control: severity -1 normal
Control: retitle -1 nmu: qtox_1.15.0-1

On Thu, Nov 15, 2018 at 10:57:57PM +0100, Axel Beckert wrote:
> Package: qtox
> Version: 1.15.0-1
> Severity: serious
> 
> qtox is currently uninstallable on at least amd64 due its dependency on
> libavdevice57 (still available, but seems to have been replaced by
> libavdevice58 and likely will be removed soon) which again depends on
> the no more available libsndio6.1.
> 
> A binNMU against the most recent ffmpeg libraries might already help.
>...

Let's request that, it is not a surprise when some transition was missed 
that happened during the 5 months where this binary package was in NEW.

nmu qtox_1.15.0-1 . amd64 . unstable . -m "Rebuild on current unstable"

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#913913: apt-cache policy does not display all (security and updates) APT repos in buster

[Yaroslav Halchenko]

and I guess I can demystify right away what is going on (although I
didn't try to reconfirm by rebuilding or debugging):

https://salsa.debian.org/apt-team/apt/blob/master/apt-private/private-show.cc#L488

 if (F.Flagged(pkgCache::Flag::NoPackages))
continue;

so no apt entries are displayed if they provide no packages ATM.

Although I could see how it is useful generally, for our purpose it is
somewhat of a blow, since we are trying to use  apt-cache policy   output
to decide what APT sources in general are configured. and since we are
rolling back in time to use snapshots, they might have had packages at
that point in time, thus we better adjust them as well.

Also documentation has no hint on such a "feature":

   policy [pkg...]
   policy is meant to help debug issues relating to the preferences 
file. With no
   arguments it will print out the priorities of each source. Otherwise 
it prints
   out detailed information about the priority selection of the named 
package.

so "each source", but not each source is printed out!

I wish this "feature" of skipping APT sources without packages was somehow
optional/configurable.  Otherwise, at least documentation should mention such
feature.

Cheers!

On Fri, 16 Nov 2018, Yaroslav Halchenko wrote:

> Even though there are 3 APT sources available, apt-cache policy in buster
> reports only a single one ignoring security and updates:

>   $> docker run -it --rm debian:buster 
>   Unable to find image 'debian:buster' locally
>   buster: Pulling from library/debian
>   bac5159b230a: Pull complete 
>   Digest: 
> sha256:8d601936efd739539811324e431a559782740a96b0e2896a8740245e1aad8db2
> ...

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#913659: Document that not all bugs are policy violations

[Sean Whitton]

Hello,

On Fri 16 Nov 2018 at 12:22PM -0200, Henrique de Moraes Holschuh wrote:

> How about also adding one that makes it clear that in *Debian*, policy
> follows practice, and not the other way around (which should also
> require seconds just to make sure people agree with this, even if it is
> a decades-long practice in debian-policy)...

This is already there, in § 1.3.3

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#913905: i3-wm: focus sometimes stucks on the previous window

[Michael Stapelberg]

Hey, thanks for your report. This does not seem like a Debian-specific
issue. Could you please open an issue at https://github.com/i3/i3?

On Fri, Nov 16, 2018 at 6:39 PM Nicolas Évrard  wrote:

> Package: i3-wm
> Version: 4.16-1
> Severity: normal
>
> Dear Maintainer,
>
> This is a quite difficult bug to trigger but it happens at least on
> time per hour since the update to i3 version 4.16
>
> The symptom is pretty easy to describe: when switching from one window
> to another (either by calling a window from the scratchpad or by using
> "focus left/right") the focus stays on the previous window yet the
> window I expected to receive the focus appears (in case it's coming
> from the scratchpad) and is decorated just like a focused window.
>
> I have tried numerous way to reproduce this bug but I failed to find a
> pattern. I am sorry about that as I know that such an erratic bug can
> be a PITA without a reproducible scenario.
>
> But since it's pretty annoying I though I would report it anyway.
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.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 i3-wm depends on:
> ii  libc6 2.27-8
> ii  libcairo2 1.16.0-1
> ii  libev41:4.22-1+b1
> ii  libglib2.0-0  2.58.1-2
> ii  libpango-1.0-01.42.4-3
> ii  libpangocairo-1.0-0   1.42.4-3
> ii  libpcre3  2:8.39-11
> ii  libstartup-notification0  0.12-5
> ii  libxcb-cursor00.1.1-4
> ii  libxcb-icccm4 0.4.1-1+b1
> ii  libxcb-keysyms1   0.4.0-1+b2
> ii  libxcb-randr0 1.13.1-1
> ii  libxcb-util0  0.3.8-3+b2
> ii  libxcb-xinerama0  1.13.1-1
> ii  libxcb-xkb1   1.13.1-1
> ii  libxcb-xrm0   1.0-3
> ii  libxcb1   1.13.1-1
> ii  libxkbcommon-x11-00.8.2-1
> ii  libxkbcommon0 0.8.2-1
> ii  libyajl2  2.1.0-3
> ii  perl  5.28.0-3
>
> Versions of packages i3-wm recommends:
> ii  fonts-dejavu-core   2.37-1
> ii  libanyevent-i3-perl 0.17-1
> ii  libjson-xs-perl 3.040-1+b1
> ii  rxvt-unicode [x-terminal-emulator]  9.22-4+b1
> ii  xfonts-base 1:1.0.4+nmu1
>
> i3-wm suggests no packages.
>
> -- no debconf information
>


-- 
Best regards,
Michael

Bug#913915: juce: VST2 support has been dropped

[IOhannes m zmoelnig]

Source: juce
Severity: serious
Tags: upstream
Justification: makes rdeps FTBFS

juce-5.4 has dropped the built-in VST2 support and now depends on the Steinberg
SDK (which - apart from being proprietary and non-free - is no longer
available) for download at all.
This has severe implications on the the usability of JUCE (as it can no longer
be used to build VST2 plugins).

Until there is a proper solution for the problem, i suggest to keep JUCE from
migrating to testing.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#908284: thunderbird: Drag-and-drop of emails from the listings pane has become nearly unusable due to changed "drag icon" style

[Anne C. Hanna]

Thanks, Carsten.  The Bugzilla bug report is here, in case anybody else has
this problem:

https://bugzilla.mozilla.org/show_bug.cgi?id=1507930

 - Anne


On 11/1/18 5:56 AM, Carsten Schoenert wrote:
> Control: tags -1 upstream
> Control: severity -1 whishlist
>
> Hello Anne,
>
> On Fri, Sep 07, 2018 at 05:40:38PM -0400, Anne C. Hanna wrote:
> ... 
>> Please revert the click-and-drag icon for this case to a simple closed-fist
>> cursor or something similarly cursor-sized, so that it will be usable again.
>> If this is not desired, an alternative would be to force the giant rectangle
>> showing what's being dragged to snap to a specific fixed position relative to
>> the cursor point, so that the cursor point will always be slightly outside of
>> one of the corners of the rectangle and what it is hovering over can be
>> clearly seen.  As a last resort, some level of transparency applied to the
>> drag icon might at least mitigate the issue.
> sorry if my answer will you not satisfy.
> Debian hasn't changed anything here and will never do. All the different
> behavior against earlier versions you describe are done by Mozilla so
> you should report your concerns to Mozilla.
>
> The way to go is to open up a bug report on the Mozilla bugtracker.
>
>   https://bugzilla.mozilla.org/
>
> There is quite nothing we can do on this on the Debian side.
>
> Regards
> Carsten
>



signature.asc
Description: OpenPGP digital signature

Bug#913914: gnustep-base-runtime: 717773 regression, gdomap autostarts

[jfp]

Package: gnustep-base-runtime
Version: 1.25.1-4+b1
Severity: important
Tags: patch

Dear Maintainer,

On install of gnustep-base-runtime (dependency of unar)

It set the gdomap service to autotart. Which is a rarely used daemon listening
on port 538 and is not required for localhost.

This was disabled in 2013.

Fix is:
in /etc/init.d/gdomap
change
 # Default-Start: 2 3 4 5
to
 # Default-Start:



-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NZ.utf8, LC_CTYPE=en_NZ.utf8 (charmap=UTF-8), LANGUAGE=en_NZ:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnustep-base-runtime depends on:
ii  gnustep-base-common  1.25.1-4
ii  init-system-helpers  1.55
ii  libc62.27-8
ii  libgcc1  1:8.2.0-9
ii  libgnustep-base1.25  1.25.1-4+b1
ii  libobjc4 8.2.0-9
ii  lsb-base 9.20170808

gnustep-base-runtime recommends no packages.

gnustep-base-runtime suggests no packages.

-- no debconf information

Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb

[hikaru . debian]

Hello,

I understand the exchange between upstream and Debian is a bit sluggish here, 
but besides that, is there a reason why Pierre's patch has never been applied?
The current situation breaks mkdeb (in some cases?) (e.g. phc_intel [1]) and 
this part of Pierre's patch would fix this:

> - fix mkdeb (1): mkdeb failed because a mv command was looking for a
> package filename with -${debian_build_arch} instead of -all.

This situation has been kind of annoying ever since the Stretch release, and I 
(and some others) would really appreciate having this fixed for Buster.


[1] http://linux-phc.org/forum/viewtopic.php?f=7&t=267
(power saving module for older Intel CPUs)

Thanks, and kind regards
hikaru

Bug#913913: apt-cache policy does not display all (security and updates) APT repos in buster

[Yaroslav Halchenko]

Package: apt
Version: 1.8.0~alpha2
Severity: normal

NB1 Reporting from my laptop whenever original issue discovered within
minimalistic Singularity image, and then replicated  within docker
environments and demonstrated below

NB2 Loosely relates to a good old 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301464
pointing to the fact that documentation of apt-cache policy output/behavior is 
scarse

NB3 Originally reported/file at 
https://github.com/neurodebian/neurodebian/issues/46#issuecomment-439503153


Even though there are 3 APT sources available, apt-cache policy in buster
reports only a single one ignoring security and updates:

$> docker run -it --rm debian:buster 
Unable to find image 'debian:buster' locally
buster: Pulling from library/debian
bac5159b230a: Pull complete 
Digest: 
sha256:8d601936efd739539811324e431a559782740a96b0e2896a8740245e1aad8db2
Status: Downloaded newer image for debian:buster

root@f8b49c0582c3:/# apt-get update
Get:1 http://security-cdn.debian.org/debian-security buster/updates 
InRelease [38.3 kB]
Get:2 http://cdn-fastly.deb.debian.org/debian buster InRelease [150 kB]
Get:3 http://cdn-fastly.deb.debian.org/debian buster-updates InRelease 
[47.6 kB]
Get:4 http://cdn-fastly.deb.debian.org/debian buster/main amd64 
Packages [7743 kB]
Fetched 7978 kB in 3s (2661 kB/s)   
Reading package lists... Done

root@f8b49c0582c3:/# apt-cache policy
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 http://deb.debian.org/debian buster/main amd64 Packages
 release o=Debian,a=testing,n=buster,l=Debian,c=main,b=amd64
 origin deb.debian.org
Pinned packages:

root@f8b49c0582c3:/# cat /etc/apt/sources.list
deb http://deb.debian.org/debian buster main
deb http://security.debian.org/debian-security buster/updates main
deb http://deb.debian.org/debian buster-updates main


In the released stretch it seems to be behaving better and displays all
3:

$> docker run -it --rm debian:stretch

root@5bf72a002f55:/# cat /etc/apt/sources.list
deb http://httpredir.debian.org/debian stretch main
deb http://httpredir.debian.org/debian stretch-updates main
deb http://security.debian.org stretch/updates main

root@5bf72a002f55:/# apt-get update
Get:1 http://security.debian.org stretch/updates InRelease [94.3 kB]
Ign http://httpredir.debian.org stretch InRelease   

Get:2 http://security.debian.org stretch/updates/main amd64 Packages 
[572 kB]
Get:3 http://httpredir.debian.org stretch-updates InRelease [91.0 kB]
Get:4 http://httpredir.debian.org stretch Release.gpg [2434 B]  
  
Get:5 http://httpredir.debian.org stretch-updates/main amd64 Packages 
[5476 B]
Get:6 http://httpredir.debian.org stretch Release [118 kB]
Get:7 http://httpredir.debian.org stretch/main amd64 Packages [9488 kB]
Fetched 10.4 MB in 2s (5171 kB/s)   
Reading package lists... Done
W: There is no public key available for the following key IDs:
EF0F382A1A7B6500

root@5bf72a002f55:/# apt-cache policy
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 http://security.debian.org/ stretch/updates/main amd64 Packages
 release 
v=9,o=Debian,a=stable,n=stretch,l=Debian-Security,c=main
 origin security.debian.org
 500 http://httpredir.debian.org/debian/ stretch-updates/main amd64 
Packages
 release 
o=Debian,a=stable-updates,n=stretch-updates,l=Debian,c=main
 origin httpredir.debian.org
 500 http://httpredir.debian.org/debian/ stretch/main amd64 Packages
 release v=9.6,o=Debian,a=stable,n=stretch,l=Debian,c=main
 origin httpredir.debian.org
Pinned packages:

root@5bf72a002f55:/# apt-cache policy apt
apt:
  Installed: 1.0.10.2
  Candidate: 1.4.8
  Version table:
 1.4.8 0
500 http://httpredir.debian.org/debian/ stretch/main 
amd64 Packages
 *** 1.0.10.2 0
100 /var/lib/dpkg/status

I wonder if there is any workaround, i.e. any other way to figure out active
APT sources to be used.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug'), (100, 'stable')
Architecture: amd64 (x86_64)


-- debconf-show failed

Bug#900679: nmu: Migrating developers-reference to Salsa and minor updates

[Holger Wansing]

Aurélien COUDERC  wrote:
> I would like to NMU developers-reference for migrating the repository to Salsa
> and a couple of minor changes.
> 
> The complete changelog would be :
> 
> developers-reference (3.4.19+nmu1) UNRELEASED; urgency=medium
> 
>   [ Aurélien COUDERC ]
>   * Non-maintainer upload.
>   * Move repository to Salsa, update Vcs-* fields.
>   * d/control: Bump Standards-Version to 4.1.4, no change needed.
>   * Fix CSS text color to avoid the HTML version being unreadable when
> using a light on dark default browser stylesheet.

The above changings were committed in the meantime, so the target of the
OP and this bug is closed.

Thus this bug can closed, right?
Any objections? (There was some discussion about maintenance of the
devref package in this bug, however this does not deserve keeping this
bug open, or it should be renamed accordingly.)


Holger



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#865548: bash-completion: completion for OpenRC rc-service

[Gabriel F. T. Gomes]

>I'll forward the original file with the changes upstream.

Now forwarded upstream [1] and in the git repository [2] (notice that
it is not yet in the Debian archive.  I want to add more fixes before
releasing a new version).

[1] https://github.com/scop/bash-completion/pull/254
[2] 
https://salsa.debian.org/debian/bash-completion/commit/b544fe206a8e66ac1d57c05543304577fc65713a

Bug#913910: atop crashed with "Malloc failed for 1826553824 deviated tasks"

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/Atoptool/atop/issues/41

I've also reported the bug upstream.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#913912: libphp-phpmailer: CVE-2018-19296

[Salvatore Bonaccorso]

Source: libphp-phpmailer
Version: 5.2.14+dfsg-2.3
Severity: grave
Tags: patch security upstream

Hi,

The following vulnerability was published for libphp-phpmailer.

CVE-2018-19296[0]:
| PHPMailer before 5.2.27 and 6.x before 6.0.6 is vulnerable to an object
| injection attack.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-19296
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19296
[1] 
https://github.com/PHPMailer/PHPMailer/commit/f1231a9771505f4f34da060390d82eadb8448271

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#913910: atop crashed with "Malloc failed for 1826553824 deviated tasks"

[Vincent Lefevre]

Package: atop
Version: 2.3.0-1+b1
Severity: normal

I got the following error after a few minutes:

zira:~> atop  <21:09:41
Malloc failed for 1826553824 deviated tasks
zsh: exit 13atop
zira:~[13]>   <21:13:02

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages atop depends on:
ii  libc62.27-8
ii  libncurses6  6.1+20181013-1
ii  libtinfo66.1+20181013-1
ii  lsb-base 9.20170808
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages atop recommends:
ii  cron [cron-daemon]  3.0pl1-130

atop suggests no packages.

-- no debconf information

Bug#913911: larry6: a strange menu entry for larry-doc

[Roma Tentser]

Package: game-data-packager
Version: 60
Severity: minor

g-d-p create a strange desktop file when build larry-doc from the larry 
6 from gog (both version).


[Desktop Entry]
Name=Leisure Suit Larry Hits and Misses booklet
GenericName=Adult Humor Game
TryExec=scummvm
Icon=scummvm
Terminal=false
Type=Application
Categories=Game;AdultHumorGame;
Exec=scummvm -p /usr/share/games/larry-doc lsl6-cd

I'm not sure it's expected behavior (the doc packages from other larry 
games don't create the desktop files — i've checked with larry2, larry3 
and larry5). And i'm positive that a pdf file doesn't contain the game.



-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-8-686-pae (SMP w/1 CPU core)
Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8), 
LANGUAGE=ru_RU.utf8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages game-data-packager depends on:
ii  dpkg    1.18.25
ii  fakeroot    1.21-3.1
ii  python3 3.5.3-1
ii  python3-debian  0.1.30
ii  python3-yaml    3.12-1

Versions of packages game-data-packager recommends:
ii  game-data-packager-runtime  60

Versions of packages game-data-packager suggests:
pn  arj    
ii  binutils   2.28-5
pn  cabextract 
pn  cdparanoia 
pn  dynamite   
ii  gcc    4:6.3.0-4
pn  gdebi | gdebi-kde  
ii  gir1.2-gdkpixbuf-2.0   2.36.5-2+deb9u2
ii  innoextract    1.7-1
pn  lgc-pg 
ii  lgogdownloader 3.4-1
pn  lhasa | jlha-utils | lzh-archiver  
ii  make   4.1-9.1
ii  p7zip-full 16.02+dfsg-3+deb9u1
pn  steam  
pn  steamcmd   
pn  unace-nonfree  
ii  unar   1.10.1-1+b1
ii  unrar  1:5.3.2-1+deb9u1
pn  unshield   
ii  unzip  6.0-21
pn  vorbis-tools   
ii  xdelta 1.1.3-9.1+b1
ii  xdelta3    3.0.11-dfsg-1+b1

-- no debconf information

Bug#882845: thunderbird: Thunderbird don’t want send email

[Anne C. Hanna]

The only new information I have is that the recent update to apparmor purports
to resolve the bug that was stopping me from enabling Thunderbird's profile. 
I re-enabled it and attempted to send email to people who were not in my
address book, and the emails went out successfully.  So the problem is no
longer occurring for me.

 - Anne


On 10/22/18 7:36 AM, Carsten Schoenert wrote:
> It's unlikely we will see any useful information on this bug report I
> guess.
> I will close this report now. Please (re)open if you can provide any
> useful new information.
>
> Regards
> Carsten
>
> On Sat, Sep 08, 2018 at 10:13:21PM -0400, Anne C. Hanna wrote:
>> On 9/8/18 4:16 AM, Carsten Schoenert wrote:
>>> Hello Anna,
>>>
>>> On Fri, Sep 07, 2018 at 06:12:56PM -0400, Anne C. Hanna wrote:
 On Thu, 26 Jul 2018 18:15:21 +0800 Carsten Schoenert 
 
 wrote:

> If not already happen please disable the Thunderbird AA profile.
>
>  $ sudo aa-disable /etc/apparmor.d/usr.bin.thunderbird
>
> Did this "solve" your issues?
> If yes we would like to see the messages are provoked by apparmor.
>
> https://wiki.debian.org/AppArmor/Debug
 Apologies for not responding sooner.  For some reason I cannot seem to
 subscribe by email to thunderbird bugs, even though I have no problem with
 other packages.

 In any case, yes, this problem (along with one or two others) has been
 "solved" for a while now by disabling the thunderbird apparmor profile.
 Unfortunately, I disabled it long enough ago that I don't have any of the
 error messages available in my logs any more.
>>> then it should be easy to get these messages (again). Just turn on
>>> AppArmor and the AppAprmor profile for Thunderbird and grep the error
>>> messages from the logs, otherwise it's impossible to dig into a solution
>>> for this report.
>> Unfortunately, I can't enable the Thunderbird AppArmor profile right now
>> because of this bug (in AppArmor):
>>
>> https://bugs.launchpad.net/apparmor/+bug/1775591
>>
>> I'll try it again when the AppArmor fix is available.
>>
>>  - Anne
>>
>
>



signature.asc
Description: OpenPGP digital signature

Bug#913866: [Debian-ha-maintainers] Bug#913866: dlm FTCBFS: uses the wrong pkg-config

[Valentin Vidic]

On Fri, Nov 16, 2018 at 08:13:20PM +0100, Helmut Grohne wrote:
> Please refer to the manual pages of dpkg-buildpackage, sbuild or
> pbuilder for how to perform a cross build. The relevant flag is either
> --host-arch or --host.
> 
> It's not entirely clear whether you're referring to a manual cross build
> here. If you do, you set up the CC, PKG_CONFIG etc. to point at your
> cross toolchain. On a Debian system, you can simply prepend the GNU
> triplet to your tools to obtain a cross toolchain (e.g. "gcc" becomes
> "x86_64-linux-gnu-gcc" when building for amd64) if you install the
> relevant packages (sbuild and pbuilder do that for you).
> 
> When using sbuild, you likely also want to use workarounds for #905345,
> #905346, and #905347.
> 
> If that doesn't help, please include more details in your question.

Thanks for the additional info, I will give it a try.  Let me know if
you already sent the patch to the upstream so I don't send it again.

-- 
Valentin

Bug#690750: Broken links in developers-reference as published on the Debian's website

[Lev Lamberov]

Пт 16 ноя 2018 @ 20:07 Holger Wansing :

> Control: tags -1 + pending
>
> Lev Lamberov  wrote:
>> Вс 04 ноя 2018 @ 12:00 Holger Wansing :
>> 
>> > Proposal: maybe the easiest way to make all variants (view via debian.org
>> > and opened locally) work correctly, would be to change it this way:
>> >
>> > "This page is also available in
>> > https://www.debian.org/doc/devel-manuals#devref";>French, 
>> > German, 
>> > Italian, Russian, and Japanese."
>> >
>> > since the links on that page are fine and can be linked from everywhere
>> > with one single static link.
>> > Of course, there are still some corner cases which do not work (for 
>> > example, 
>> > when you have the packages installed locally, you cannot switch from the 
>> > local english to the local german version via that links, and when you
>> > have no internet connection, you also get an irritating situation), but 
>> > most 
>> > usecases should be fine, and it would be an improvement compared to the 
>> > current situation, where all links do not work!
>> >
>> > Would fix #690750 and #912724.
>> >
>> > Comments?
>> 
>> In case one take a look into other documentation (togather with its
>> translation), one will not find any such notes and links to
>> translations. Maybe there's no need in such note in "Debian Developer's
>> Reference"? Or at least no need in explicit links? What about to remove
>> it completely or change text to something like "This documentation is
>> also available in some other languages"?
>
> I have committed this now like this, while 'some  other languages' is a link
> to https://www.debian.org/doc/devel-manuals#devref

Thanks, Holger! Looks like this is the best option for now. Maybe better
variant will come later.

Cheers!
Lev

Bug#913360: libreoffice-base-drivers: please switch to libmariadb-java

[Rene Engelhard]

Hi,

On Fri, Nov 16, 2018 at 08:17:06PM +0100, Markus Koschany wrote:
> > But I think this will give us problems if we suggest libmariadb-java and 
> > don't get the
> > new class into this...
> > 
> > Can't we get some symlinks in libmariadb-java? :)
> 
> I'm not sure if I understand you correctly. The classname
> "org.mariadb.jdbc.Driver" can't be changed because this path is
> hardcoded in mariadb-java-client.jar. We could create a symlink to
> mysql-connector-java.jar but that wouldn't achieve anything. So this is

Hmm, true.

Ah, well, then the .NEWS then.

Regards,

Rene

Bug#908890: developers-reference: As alioth is gone, replace references to Salsa

[Holger Wansing]

Tobias Frost created a merge request for this, under
https://salsa.debian.org/debian/developers-reference/merge_requests/6


Any objections against me merging this?

Holger



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#913886: Optimize TJENER's squid.conf for DEB package caching

[Wolfgang Schweer]

On Fri, Nov 16, 2018 at 07:03:21PM +, Holger Levsen wrote:
> while this is true, I think this change should still go in the src:squid
> package, so that everyone profits.

Yes. Debian itself has a drop-in file /etc/squid/conf.d/debian.conf

imo it would be the right place for (commented) Deboian packages related 
settings.

Wolfgang


signature.asc
Description: PGP signature

Bug#818850: developers-reference: Join the two chapters about the 'default' field

[Holger Wansing]

Control: tags -1 + pending


Holger Wansing  wrote:
> Control: tags -1 - pending
> 
> 
> Maintainers, what do you think about
> https://salsa.debian.org/debian/developers-reference/merge_requests/8/diffs 
> to 
> fix this bug?
> 
> Any objections against me merging this?
> 

Since there were no objections, I have merged this into master now.

Tagging this bug as pending.


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#913360: libreoffice-base-drivers: please switch to libmariadb-java

[Markus Koschany]

Hi,

Am 16.11.18 um 19:49 schrieb Rene Engelhard:
[...]
>>> diff --git 
>>> a/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu 
>>> b/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
>>> index 77988448f..acd8bfdaf 100644
>>> --- 
>>> a/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
>>> +++ 
>>> b/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
>>> @@ -33,7 +33,7 @@
>>>  
>>>  
>>>
>>> -com.mysql.jdbc.Driver
>>> +org.mariadb.jdbc.Driver
>>>
>>>  
>>>  
>>> diff --git a/connectivity/source/drivers/mysql/YDriver.cxx 
>>> b/connectivity/source/drivers/mysql/YDriver.cxx
>>> index 95094265e..c0ad7802e 100644
>>> --- a/connectivity/source/drivers/mysql/YDriver.cxx
>>> +++ b/connectivity/source/drivers/mysql/YDriver.cxx
>>> @@ -54,7 +54,7 @@ namespace connectivity
>>>  css::uno::Sequence const & info)
>>>  {
>>>  return comphelper::NamedValueCollection(info).getOrDefault(
>>> -"JavaDriverClass", OUString("com.mysql.jdbc.Driver"));
>>> +"JavaDriverClass", OUString("org.mariadb.jdbc.Driver"));
>>>  }
>>>  }
>>>  
>>> @@ -185,7 +185,7 @@ namespace connectivity
>>>  aProps.push_back( PropertyValue(
>>>"JavaDriverClass"
>>>,0
>>> -  
>>> ,makeAny(OUString("com.mysql.jdbc.Driver"))
>>> +  
>>> ,makeAny(OUString("org.mariadb.jdbc.Driver"))
>>>,PropertyState_DIRECT_VALUE) );
>>>  }
>>>  }
> 
> But I think this will give us problems if we suggest libmariadb-java and 
> don't get the
> new class into this...
> 
> Can't we get some symlinks in libmariadb-java? :)

I'm not sure if I understand you correctly. The classname
"org.mariadb.jdbc.Driver" can't be changed because this path is
hardcoded in mariadb-java-client.jar. We could create a symlink to
mysql-connector-java.jar but that wouldn't achieve anything. So this is
a either-or situation. I can backport libmariadb-java to Stretch though,
if that helps.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#908564: Migration of dwarves-dfsg to samba.d.o

[Thomas Girard]

I am unable to push to salsa despite  my renewal of SSH keys to the LDAP
 gateway.

I'll try again this week-end. If I fail I'll upload to github.com.

Bug#913866: [Debian-ha-maintainers] Bug#913866: dlm FTCBFS: uses the wrong pkg-config

[Helmut Grohne]

On Fri, Nov 16, 2018 at 09:09:56AM +0100, Valentin Vidic wrote:
> > dlm fails to cross build from source, because the upstream Makefile hard
> > codes the build architecture pkg-config. The attached patch makes
> > pkg-config substitutable. dh_auto_build substitutes it and dlm becomes
> > cross buildable. Please consider applying it.
> 
> Sure, can you show me how to cross build by setting PKG_CONFIG?

Please refer to the manual pages of dpkg-buildpackage, sbuild or
pbuilder for how to perform a cross build. The relevant flag is either
--host-arch or --host.

It's not entirely clear whether you're referring to a manual cross build
here. If you do, you set up the CC, PKG_CONFIG etc. to point at your
cross toolchain. On a Debian system, you can simply prepend the GNU
triplet to your tools to obtain a cross toolchain (e.g. "gcc" becomes
"x86_64-linux-gnu-gcc" when building for amd64) if you install the
relevant packages (sbuild and pbuilder do that for you).

When using sbuild, you likely also want to use workarounds for #905345,
#905346, and #905347.

If that doesn't help, please include more details in your question.

Helmut

Bug#690750: Broken links in developers-reference as published on the Debian's website

[Holger Wansing]

Control: tags -1 + pending

Lev Lamberov  wrote:
> Вс 04 ноя 2018 @ 12:00 Holger Wansing :
> 
> > Proposal: maybe the easiest way to make all variants (view via debian.org
> > and opened locally) work correctly, would be to change it this way:
> >
> > "This page is also available in
> > https://www.debian.org/doc/devel-manuals#devref";>French, 
> > German, 
> > Italian, Russian, and Japanese."
> >
> > since the links on that page are fine and can be linked from everywhere
> > with one single static link.
> > Of course, there are still some corner cases which do not work (for 
> > example, 
> > when you have the packages installed locally, you cannot switch from the 
> > local english to the local german version via that links, and when you
> > have no internet connection, you also get an irritating situation), but 
> > most 
> > usecases should be fine, and it would be an improvement compared to the 
> > current situation, where all links do not work!
> >
> > Would fix #690750 and #912724.
> >
> > Comments?
> 
> In case one take a look into other documentation (togather with its
> translation), one will not find any such notes and links to
> translations. Maybe there's no need in such note in "Debian Developer's
> Reference"? Or at least no need in explicit links? What about to remove
> it completely or change text to something like "This documentation is
> also available in some other languages"?

I have committed this now like this, while 'some  other languages' is a link
to https://www.debian.org/doc/devel-manuals#devref


Tagging these bugs as pending

Holger




-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#913886: Optimize TJENER's squid.conf for DEB package caching

[Holger Levsen]

hi,

not sure why I dropped the bug in my initial reply, thus quoting more here
than usual...

On Fri, Nov 16, 2018 at 07:09:17PM +0100, Wolfgang Schweer wrote:
> On Fri, Nov 16, 2018 at 01:23:38PM +, Holger Levsen wrote:
> > On Fri, Nov 16, 2018 at 01:15:59PM +, Mike Gabriel wrote:
> > > I have adapted the Debian Edu squid.conf on TJENER with the below changes.
> > > This results in a tremendous speed improvement regarding the package
> > > download when installing multiple systems in one go via the Debian Edu PXE
> > > installer.
> > > 
> > > IMHO we should adapt our squid.conf. 
> 
> Since d-e-c 2.10.44 the stock squid.conf is no longer tweaked; instead 
> the Debian Edu custom settings file is dropped into /etc/squid/conf.d 
> (as debian-edu.conf). The settings would go into this file.

ah nice!

> > I'm not sure we should further vary from the package default.
> 
> See above: only addons are used, so it would be an additional allowed 
> customization.

while this is true, I think this change should still go in the src:squid
package, so that everyone profits.

> > > Note: these changes have been taken
> > > from the squid-deb-proxy package. Another option would be to implement
> > > support for squid-deb-proxy on a Debian Edu site.
> > or: why cant we simply install this package?
> afaict an additional cache would be used, also a lot of configuration 
> work would be needed; squid-deb-proxy won't work out of the box…

ah

> I can confirm that it works w/ the debian-edu.conf file modified like 
> proposed.

cool.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#913867: lintian: check source-contains-prebuilt-windows-binary: false alarm on tfm (TeX Font Metric) files

[Christoph Biedl]

tags 913867 confirmed
thanks

Chris Lamb wrote...

> I agree this is a false-positive being emitted but I think the bug
> might actually be in file(1), and not Lintian; we simply match the
> data returned from file(1):
>
>   
> https://salsa.debian.org/lintian/lintian/blob/master/data/cruft/warn-file-type#L16
>
> … which returns the incorrect:
>
>   $ file ./texmf-dist/fonts/tfm/public/cs/csitt12.tfm
> ./texmf-dist/fonts/tfm/public/cs/csitt12.tfm: WE32000 COFF executable (TV) 
> not stripped

Indeed. The COFF file format is a constant source of trouble, I'll try
to adjust the weights.

Christoph


signature.asc
Description: PGP signature

Bug#913908: osinfo-db: Please update to at least 20181116

[Jeremy Bicha]

Source: osinfo-db
Version: 0.20180929-1
Severity: wishlist

When you get a chance,  could you please update osinfo-db with a new snapshot?

In particular, as of today, it includes Pop_OS! 18.10, RHEL 8 Beta,
Fedora 29, and Ubuntu 18.10.

Thanks,
Jeremy Bicha

Bug#870468: grdesktop FTCBFS: broken PKG_CHECK_MODULES copy uses build arch pkg-config

[Jeremy Bicha]

On Fri, Nov 16, 2018 at 2:26 AM Yavor Doganov  wrote:
> > Using autoreconf is part of the solution. Usually though, autoreconf
> > prefers macros in the source over system copies. So if your source still
> > contains the (outdated) copy, autoreconf will prefer it.
>
> That's not true if autoreconf is being run with the --force option
> (which dh_autoreconf does); all files are considered obsolete then.

In my experience, Helmut is right. So in some of my packages, I've
been adding the autoconf macros to Files-Excluded so that they aren't
part of the Debian source when importing new tarball releases to
ensure we actually build from the latest sources instead of sometimes
ancient macros.

Fortunately, many of my packages have switched to meson which at least
doesn't have this issue. (I guess meson has some other cross-compiling
issues currently but hopefully those will get straightened out soon.)

Thanks,
Jeremy Bicha

Bug#913360: libreoffice-base-drivers: please switch to libmariadb-java

[Rene Engelhard]

Hi,

On Fri, Nov 09, 2018 at 11:45:41PM +0100, Rene Engelhard wrote:
> > diff --git a/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java 
> > b/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java
> > index a44f1b9d1..03a8293ef 100644
> > --- a/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java
> > +++ b/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java
> > @@ -59,7 +59,7 @@ public class JdbcLongVarCharTest extends ComplexTestCase
> >  
> >  String url = "jdbc:mysql://localhost:3306/mysql?user=root";
> >  com.sun.star.beans.PropertyValue prop[] = new PropertyValue[1];
> > -prop[0] = new PropertyValue("JavaDriverClass", 0, 
> > "com.mysql.jdbc.Driver", PropertyState.DIRECT_VALUE);
> > +prop[0] = new PropertyValue("JavaDriverClass", 0, 
> > "org.mariadb.jdbc.Driver", PropertyState.DIRECT_VALUE);
> 
> Not used, ttbomk. At least we have no test environment where this ever
> could work. No MySQL running.

OK, this is not used because of

--- snip ---
ifneq ($(filter QADEVOOO,$(BUILD_TYPE)),)
$(eval $(call gb_Module_add_subsequentcheck_targets,connectivity,\
Jar_ConnectivityTools \
))
# FIXME: Does not work. Convert to JUnit.
# JunitTest_complex \

endif
--- snip ---

> > diff --git 
> > a/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu 
> > b/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
> > index 77988448f..acd8bfdaf 100644
> > --- 
> > a/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
> > +++ 
> > b/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
> > @@ -33,7 +33,7 @@
> >  
> >  
> >
> > -com.mysql.jdbc.Driver
> > +org.mariadb.jdbc.Driver
> >
> >  
> >  
> > diff --git a/connectivity/source/drivers/mysql/YDriver.cxx 
> > b/connectivity/source/drivers/mysql/YDriver.cxx
> > index 95094265e..c0ad7802e 100644
> > --- a/connectivity/source/drivers/mysql/YDriver.cxx
> > +++ b/connectivity/source/drivers/mysql/YDriver.cxx
> > @@ -54,7 +54,7 @@ namespace connectivity
> >  css::uno::Sequence const & info)
> >  {
> >  return comphelper::NamedValueCollection(info).getOrDefault(
> > -"JavaDriverClass", OUString("com.mysql.jdbc.Driver"));
> > +"JavaDriverClass", OUString("org.mariadb.jdbc.Driver"));
> >  }
> >  }
> >  
> > @@ -185,7 +185,7 @@ namespace connectivity
> >  aProps.push_back( PropertyValue(
> >"JavaDriverClass"
> >,0
> > -  
> > ,makeAny(OUString("com.mysql.jdbc.Driver"))
> > +  
> > ,makeAny(OUString("org.mariadb.jdbc.Driver"))
> >,PropertyState_DIRECT_VALUE) );
> >  }
> >  }

But I think this will give us problems if we suggest libmariadb-java and don't 
get the
new class into this...

Can't we get some symlinks in libmariadb-java? :)

Did

diff --git a/changelog b/changelog
index fe843d07..bdb4d3dd 100644
--- a/changelog
+++ b/changelog
@@ -7,13 +7,17 @@ libreoffice (1:6.1.3-2) UNRELEASED; urgency=medium
 -Djdk.net.URLClassPath.disableClassPathURLCheck=true to JAVAIFLAGS;
 see https://gerrit.libreoffice.org/#/c/63118/2
 
+  * debian/patches/use-mariadb-java-instead-of-mysql-java.diff: as name says;
+use org.mariadb.jdbc.Driver instead of com.mysql.jdbc.Driver
   * debian/control.in:
-- Add libmariadb-java as new alternative before libmysql-java in
-  -base-drivers' Suggests: See #912916 for more information.
+- Suggest libmariadb-java instead of libmysql-java. See #912916 for more
+  information.
   * debian/patches/jdbc-driver-classpaths.diff: add org.mariadb.jdbc.Driver
-classpath to /usr/share/java/mariadb-java-client.jar
+classpath pointing to /usr/share/java/mariadb-java-client.jar
   * debian/libreoffice-base.bug-script.in: add libmariadb-java
-  (closes: #913360)
+  (closes: #913360, thanks Markus Koschany)
+
+  * debian/libreoffice-base-drivers.NEWS: add NEWS about above change
 
  -- Rene Engelhard   Fri, 09 Nov 2018 20:59:58 +0100
 
diff --git a/control b/control
index bb17ab05..635b538c 100644
--- a/control
+++ b/control
@@ -795,7 +795,7 @@ Depends: libreoffice-core, ${misc:Depends}, 
${shlibs:Depends}
 Architecture: alpha amd64 arm64 armel armhf i386 ia64 m68k mips mipsel 
mips64el powerpc ppc64 ppc64el s390x sparc64 powerpcspe kfreebsd-amd64 
kfreebsd-i386
 Section: database
 Suggests: libjtds-java,
-  libreoffice-mysql-connector | libmyodbc | libmariadb-java | 
libmysql-java,
+  libreoffice-mysql-connector | libmyodbc | libmariadb-java,
   libreoffice-sdbc-postgresql | odbc-postgresql | libpg-java,
   libsqliteodbc | tdso

Bug#912736: RFS: apt-listbugs/0.1.25

[Francesco Poli]

On Fri, 16 Nov 2018 00:25:00 +0100 Francesco Poli wrote:

[...]
> If the maintainer field is set to , then I would
> obviously need to subscribe to that list, and the e-mail traffic
> related to apt-listbugs would be intermingled with the rest of
> the messages directed there. I am not sure I can afford such an
> increase in my incoming e-mail traffic... Not in the short term, at
> least...

On a second thought, I could set the maintainer field to ,
without subscribing to the mailing list, and then subscribe my e-mail
address to the apt-listbugs package tracker notifications...

That way, I would receive the e-mail traffic related to apt-listbugs,
as I currently do, but not the rest of  traffic.
At the same time, all the e-mail traffic related to apt-listbugs would
be directed to , so that bug reports would get more
visibility and others could have an opportunity to comment on them, etc.

Would that be OK with you?
Or is that too asymmetrical, perhaps?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpfJ7Dk7qjVQ.pgp
Description: PGP signature

Bug#913864: kicad: Backtraces on opening cvpcb

[Seth Hillbrand]

Am 2018-11-16 12:39, schrieb Carsten Schoenert:

So downgrading is a bit difficult and right now before the soft freeze
for Buster not the right way I think.


That's a fair assessment.  I believe the issue is mixing versions.  So 
an alternate solution is to upgrade both to the 3.0.4 version.  I would 
be curious to hear if there were issues when both are running on 3.0.4 
as I haven't had any issues in Buster related to this.


-Seth

Bug#913907: does not start "Failed to register: Timeout was reached"

[Joey Hess]

Package: thunar
Version: 1.8.2-1
Severity: normal

Since upgrading, thunar does not start:

joey@darkstar:~>strace -o strace thunar 
Failed to register: Timeout was reached
joey@darkstar:~>echo $?
0

No window opens. thunar --daemon is running. However, it's not doing any
removable media automounting either, which is mostly what I use thunar
for.

https://bugs.archlinux.org/task/60229 is the same bug, and after
deleting ~/.cache/sessions/xfce4-session-* and killing and restarting
the thunar daemon, I am able to open thunar.

The strace is attached. It looks to me like thunar is talking with
dbus, over an eventfd, and fails to get a response, probably from the
daemon?

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-4
ii  exo-utils   0.12.2-2
ii  libatk1.0-0 2.30.0-1
ii  libc6   2.27-8
ii  libcairo2   1.16.0-1
ii  libexo-2-0  0.12.2-2
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
ii  libglib2.0-02.58.1-2
ii  libgtk-3-0  3.24.1-2
ii  libgudev-1.0-0  232-2
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-3
ii  libpango-1.0-0  1.42.4-3
ii  libsm6  2:1.2.2-1+b3
ii  libthunarx-3-0  1.8.2-1
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.10-1
ii  thunar-data 1.8.2-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1
ii  gvfs  1.38.1-1
ii  libcairo-gobject2 1.16.0-1
ii  libpangocairo-1.0-0   1.42.4-3
ii  libxfce4panel-2.0-4   4.12.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7
ii  thunar-volman 0.9.0-1
ii  tumbler   0.2.3-1
ii  udisks2   2.8.1-2
ii  xdg-user-dirs 0.17-1

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.4.0-2
ii  thunar-media-tags-plugin  0.3.0-2

-- no debconf information

-- 
see shy jo
execve("/usr/bin/thunar", ["thunar"], 0x7fff51c65070 /* 65 vars */) = 0
brk(NULL)   = 0x559683bd5000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=201936, ...}) = 0
mmap(NULL, 201936, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f898a649000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libthunarx-3.so.0", 
O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240H\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=59232, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f898a647000
mmap(NULL, 61696, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f898a637000
mprotect(0x7f898a63b000, 40960, PROT_NONE) = 0
mmap(0x7f898a63b000, 24576, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7f898a63b000
mmap(0x7f898a641000, 12288, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0xa000) = 0x7f898a641000
mmap(0x7f898a645000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd000) = 0x7f898a645000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libexo-2.so.0", O_RDONLY|O_CLOEXEC) 
= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\6\1\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=231336, ...}) = 0
mmap(NULL, 233872, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f898a5fd000
mmap(0x7f898a60b000, 122880, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe000) = 0x7f898a60b000
mmap(0x7f898a629000, 45056, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x2c000) = 0x7f898a629000
mmap(0x7f898a634000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x36000) = 0x7f898a634000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/li

Bug#913867: lintian: check source-contains-prebuilt-windows-binary: false alarm on tfm (TeX Font Metric) files

[Chris Lamb]

reassign 913867 src:file 1:5.34-2
affects 913867 + src:lintian
thanks

Hi Norbert,

>   W: texlive-lang source: source-contains-prebuilt-windows-binary texmf-
> dist/fonts/tfm/public/cs/csitt12.tfm
[..]
> Please exempt .tfm files from this check, it is incorrect.

I agree this is a false-positive being emitted but I think the bug
might actually be in file(1), and not Lintian; we simply match the
data returned from file(1):

  
https://salsa.debian.org/lintian/lintian/blob/master/data/cruft/warn-file-type#L16

… which returns the incorrect:

  $ file ./texmf-dist/fonts/tfm/public/cs/csitt12.tfm
./texmf-dist/fonts/tfm/public/cs/csitt12.tfm: WE32000 COFF executable (TV) not 
stripped


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#913890: nheko: More or less broken build-dependencies ("-dev" missing in many package names)

[Axel Beckert]

Hi Hubert,

Hubert Chathi wrote:
> Ugh.  Sorry for causing delays to the transition.

JFTR: I'm not involved in the transition, just a user who noticed that
he can't upgrade boost in unstable because of nheko and then seeing
that it waits for build-dependencies on nearly all architectures for
50 days or so due to the missing "-dev" in the package name. That's
also why I didn't file this as RC as I wasn't sure if it really is.

I must admit that I just noticed now that it was not blocking the
transition of boost to testing as the version in testing doesn't seem
to depend ob boost. Just the amd64 version of 0.6.1-1 (the only
architecture that got built) blocked installing a newer boost on
unstable.

Nevertheless it's good to have those copy-and-paste issues fixed as
they would have surely become an issue with the next boost after 1.67
since the versioned package names were the only ones which were
resolvable if at all.

> I'm rebuilding and will upload shortly.

Thanks for the prompt reaction! This looks much better now:
https://buildd.debian.org/status/package.php?p=nheko

No more "BD-Uninstallable" for any release architecture. And the
remaining "BD-Uninstallable" for many non-release architectures are
different per architecture and hence seem to be architecture issues
and not issues with the nheko package.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#913906: gparted reliably crashes on first start after boot

[Marc Lehmann]

Package: gparted
Version: 0.25.0-1+b1
Severity: normal

Dear Maintainer,

when starting gparted for the first time on a given DISPLAY, it crashes:

   The program 'gpartedbin' received an X Window System error.
   This probably reflects a bug in the program.
   The error was 'BadValue (integer parameter out of range for operation)'.
 (Details: serial 179 error_code 2 request_code 130 minor_code 3)
 (Note to programmers: normally, X errors are reported asynchronously;
  that is, you will receive the error a while after causing it.
  To debug your program, run it with the --sync command line
  option to change this behavior. You can then get a meaningful
  backtrace from your debugger if you break on the gdk_x_error() function.)

Immediately starting it again succeeds. This doesn't seem to be related to
the DISPLAY - rebooting the machine gparted runs on makes it crash again
the first time.

-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), 
(500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 
'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.17-041817-generic (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages gparted depends on:
ii  libatkmm-1.6-1v5  2.24.2-2
ii  libc6 2.27-8
ii  libgcc1   1:8.2.0-9
ii  libglib2.0-0  2.58.1-2
ii  libglibmm-2.4-1v5 2.50.0-1
ii  libgtk2.0-0   2.24.31-2
ii  libgtkmm-2.4-1v5  1:2.24.5-1
ii  libpangomm-1.4-1v52.40.1-3
ii  libparted-fs-resize0  3.2-17
ii  libparted23.2-17
ii  libsigc++-2.0-0v5 2.10.0-1
ii  libstdc++68.2.0-9
ii  libuuid1  2.29.2-1+deb9u1

gparted recommends no packages.

Versions of packages gparted suggests:
pn  dmraid 
ii  dmsetup2:1.02.137-2
ii  dosfstools 4.1-1
ii  gpart  1:0.3-3
pn  jfsutils   
ii  kpartx 0.6.4-5
ii  mtools 4.0.18-2+b1
ii  ntfs-3g1:2016.2.22AR.1+dfsg-1
ii  reiser4progs   1.1.0-3
ii  reiserfsprogs  1:3.6.25-4+b1
ii  xfsprogs   4.9.0+nmu1
ii  yelp   3.22.0-1

-- no debconf information

Bug#838480: Next revision, suggestion accounted

[Martin Pitt]

Hello Dmitry,

Dmitry Bogatov [2016-10-20 13:33 +0300]:
> runit_2.1.2-9 in testing, and it:
> 
>  - Depends on getty-run, which means that user end up without tty

Not sure what "getty-run" is, but indeed I don't get a TTY. But I don't even
get that far. This is my current experience:

 * Standard vmdebootstrap install of sid.
 * Install runit-init, "do as I say!", reboot (that works)
 * Boot does that:

| - runit: $Id: 25da3b86f7bed4038b8a039d2f8e8c9bbcf0822b $: booting.
| - runit: enter stage: /etc/runit/1
| [ ok ] Starting hotplug events dispatcher: systemd-udevd.
| [] Synthesizing the initial hotplug events...[1.808644] input: Power 
Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
| [1.833381] parport_pc 00:04: reported by Plug and Play ACPI
| [1.835655] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
| [1.840339] ACPI: Power Button [PWRF]
| [1.850222] systemd-udevd[375]: link_config: autonegotiation is unset or 
enabled, the speed and duplex are not writable.
| [1.861449] sr 1:0:0:0: Attached scsi generic sg0 type 5
| [1.872548] input: PC Speaker as /devices/platform/pcspkr/input/input5
| [1.875268] 9pnet: Installing 9P2000 support
| [ ok [1.927861] [drm] Found bochs VGA, ID 0xb0c0.
| [1.929126] [drm] Framebuffer size 16384 kB @ 0xfd00, mmio @ 
0xfebd.
| [1.938009] systemd-udevd[376]: link_config: autonegotiation is unset or 
enabled, the speed and duplex are not writable.
| done.
| [1.961434] [TTM] Zone  kernel: Available graphics memory: 1022516 kiB
| [1.963260] [TTM] Initializing pool allocator
| [1.979965] [TTM] Initializing DMA pool allocator
| [] Waiting for /dev to be fully populated...[1.994500] ppdev: 
user-space parallel port driver
| [2.009204] fbcon: bochsdrmfb (fb0) is primary device
| [2.012962] Console: switching to colour frame buffer device 128x48
| [2.024111] bochs-drm :00:02.0: fb0: bochsdrmfb frame buffer device
| [2.025381] [drm] Initialized bochs-drm 1.0.0 20130925 for :00:02.0 on 
minor 0
| done.
| [ ok ] Activating swap...done.
| [2.552988] EXT4-fs (vda1): re-mounted. Opts: errors=remount-ro
| [warn] Creating compatibility symlink from /etc/mtab to /proc/mounts. ... 
(warning).
| [ ok ] Activating lvm and md swap...done.
| [] Checking file systems...fsck from util-linux 2.32.1
| done.
| [ ok ] Cleaning up temporary files... /tmp.
| [ ok ] Mounting local filesystems...done.
| [ ok ] Activating swapfile swap...done.
| [ ok ] Cleaning up temporary files
| [ ok ] Starting Setting kernel variables: sysctl.
| [2.863970] random: dd: uninitialized urandom read (512 bytes read)
| [ ok ] Configuring network interfaces...done.
| [ ok ] Cleaning up temporary files
| [ ok ] Starting enhanced syslogd: rsyslogd.
| [ ok ] Starting ACPI services: acpid.
| [ ok ] Starting periodic command scheduler: cron.
| [] Starting system message bus: dbus[3.012871] random: dbus-daemon: 
uninitialized urandom read (12 bytes read)
| [3.017986] random: dbus-daemon: uninitialized urandom read (12 bytes read)

  and hangs for 90s. Then it gets a tiny bit further:

| . ok 
| [   93.081316] audit: type=1400 audit(1542390391.612:3): apparmor="DENIED" 
operation="mknod" profile="/usr/sbin/haveged" name="/run/hav0
| [ ok ] Starting SMP IRQ Balancer: irqbalance.
| [] Starting OpenBSD Secure Shell server: sshd

And from here on, nothing. I can't log in through sshd, and there's no VT
either.

Admittedly I didn't do any RTFM, but IMHO this isn't a very friendly default
behaviour. You get locked out of your machine completely, only grub and init=
come to the rescue.

>  - Provides `shutdown' and `reboot' scripts, which were tested via
>'fbpanel' buttons. Works correctly.

That does work now, at least immediately after installation. (Can't test on an
actual runit system). So, progress!

> Is there anything else needed for inclusion into init's pre-depends?

I wouldn't veto it, as the actual functionality for runit is not the
responsibility of the "init" metapackage. But I strongly recommend providing an
OOTB experience that gets a working system, before adding it as a pre-depends.
You should also ensure that this stays so by creating an autopkgtest that
installs runit, reboots, and makes sure that at least ssh and getty come up,
and runlevel is 2 (or 3, i. e. not S). This will ensure that this works on a
standard system, cover other architectures, and also prevent future
regressions.

Thank you!

Martin


signature.asc
Description: PGP signature

Bug#911297: wpasupplicant needs to override default OpenSSL settings to work with enterprise networks

[Sam Morris]

Package: wpasupplicant
Version: 2:2.4-1+deb9u1
Followup-For: Bug #911297

See /usr/share/doc/libssl1.1/NEWS.Debian.gz and try editing the end of
/etc/ssl/openssl.cnf:

MinProtocol = None
CipherString = DEFAULT

I believe OpenSSL clients can call SSL_CONF_cmd(3ssl) in order to
change the new defaults (TLSv1.2, security level 2) back to something
more permissive. wpasupplicant should probably be doing this because
enterprise networks are not going to upgrade to anything as new as
TLSv1.2 (2008) overnight.

For bonus points, the minimum TLS version and CipherString could be
exposed in NetworkManager's GUI and passed down to wpasupplicant, but
that's way too much work given that we're about to freeze for buster!

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (540, 'stable-updates'), (540, 'stable'), (520, 'testing'), (510, 
'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-6-686-pae (SMP w/1 CPU core)
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 wpasupplicant depends on:
ii  adduser   3.115
ii  libc6 2.24-11+deb9u3
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libnl-3-200   3.2.27-2
ii  libnl-genl-3-200  3.2.27-2
pn  libpcsclite1  
ii  libreadline7  7.0-3
ii  libssl1.0.2   1.0.2l-2+deb9u3
ii  libssl1.1 1.1.0f-3+deb9u2
ii  lsb-base  9.20161125

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

Bug#913864: kicad: Backtraces on opening cvpcb

[Carsten Schoenert]

Am 16.11.18 um 15:28 schrieb Seth Hillbrand:
> Hello Carsten-
> Am 2018-11-16 02:00, schrieb Carsten Schoenert:
>> Hello Seth,
>>
>> seems there is another issue with the RTTI implementation, now as far I
>> see on amd64.
>> Maybe this is already fixed in the current HEAD of the 5.x tree?
> 
> As I recall, this issue is an incompatibility between 3.0.2 and 3.0.4 of 
> the wx libraries.  If Julien downgrades libwxbase and libwxgtk3.0 to the 
> 3.0.2.0+dfsg-8, this issue should go away.  Please let me know if it 
> doesn't.

Just for the record, testing/unstable is providing 3.0.4+dfsg-4 and
stable/stretch is providing 3.0.2+dfsg-4, backports hold the same
version as testing.

> $ rmadison libwxgtk3.0-0v5 libwxbase3.0-0v5 python-wxgtk3.0
> libwxbase3.0-0v5 | 3.0.2+dfsg-4| stable | amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> libwxbase3.0-0v5 | 3.0.4+dfsg-4~bpo9+1 | stretch-backports  | amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> libwxbase3.0-0v5 | 3.0.4+dfsg-4| testing| amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> libwxbase3.0-0v5 | 3.0.4+dfsg-4| unstable   | amd64, arm64, 
> armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, 
> mipsel, ppc64el, s390x
> libwxgtk3.0-0v5  | 3.0.2+dfsg-4| stable | amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> libwxgtk3.0-0v5  | 3.0.4+dfsg-4~bpo9+1 | stretch-backports  | amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> libwxgtk3.0-0v5  | 3.0.4+dfsg-4| testing| amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> libwxgtk3.0-0v5  | 3.0.4+dfsg-4| unstable   | amd64, arm64, 
> armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, 
> mipsel, ppc64el, s390x
> python-wxgtk3.0  | 3.0.1.1+dfsg-2  | oldstable  | amd64, arm64, 
> armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x
> python-wxgtk3.0  | 3.0.1.1+dfsg-2  | oldstable-kfreebsd | kfreebsd-amd64, 
> kfreebsd-i386
> python-wxgtk3.0  | 3.0.2.0+dfsg-4  | stable | amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> python-wxgtk3.0  | 3.0.2.0+dfsg-8  | testing| amd64, arm64, 
> armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
> python-wxgtk3.0  | 3.0.2.0+dfsg-8  | unstable   | amd64, arm64, 
> armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, 
> mipsel, ppc64el, s390x

So downgrading is a bit difficult and right now before the soft freeze
for Buster not the right way I think.

I can try to build some recent version of 5.x for experimental. But
currently don't know if I will will find to do this in the next days.

-- 
Regards
Carsten Schoenert

Bug#912525: systemd: nobody group is created by systemd-sysusers automatically

[Martin Pitt]

Hello Keh-Ming Luoh, hello Michael,

sorry for the delay!

Keh-Ming Luoh [2018-10-31 19:22 -0700]:
> When I upgrade my systemd, I found there is a "nobody" group created
> automatically.

Thanks for tracking this down!

> -awk -F:  '{ i = ($3 == $4) ? $3 : $3":"$4; printf("u %-10s %-7s - %-20s 
> %s\n", $1,i,$6,$7) }'  < /usr/share/base-passwd/passwd.master
> +awk -F:  '{ i = $3":"$4; printf("u %-10s %-7s - %-20s %s\n", $1,i,$6,$7) }'  
> < /usr/share/base-passwd/passwd.master

This is not quite correct. If you specify the GID explicitly, then it needs to
exist before, i. e. the script would also need to be changed to create groups
like "sys:3" explicitly. I. e. the conditional

   # only take groups whose name+gid != the corresponding user in passwd.master

part would need to become unconditional. This would work, but would make both
the group and passwd list more unwieldy.

As all static Debian users and groups *except* nobody:nogroup have the same
name, I'd like to keep the "single ID" behaviour of systemd-sysusers, as it's
generally the right thing to do and more robust. So instead I'd like to
handle the "nogroup" special-case as such.

With the attached patch I seem to get the correct behaviour. The effective diff
of the generated sysusers.d is

-u nobody 65534   - /nonexistent /usr/sbin/nologin
+u nobody 65534:65534 - /nonexistent /usr/sbin/nologin

and nothing else. With current 239-11:

  # systemd-sysusers
  Creating group nobody with gid 999.

and with this patched /usr/lib/sysusers.d/basic.conf:

  # systemd-sysusers
  # grep nobody /etc/group
  #

i. e. it stops creating the group.

I also added some postinst cleanup with some reasonable defensiveness.
(Double-checking it now)

@Michael, does that seem ok to you?

Thanks,

Martin
>From b74313718d817e224e807b7979dd6434ba2fc120 Mon Sep 17 00:00:00 2001
From: Martin Pitt 
Date: Fri, 16 Nov 2018 18:21:29 +0100
Subject: [PATCH] Fix wrong "nobody" group from sysusers.d

Fix our make-sysusers-basic sysusers.d generator to special-case the
nobody group. "nobody" user and "nogroup" group both have the same ID
65534, which is the only special case for Debian's static users/groups.
So specify the gid explicitly, to avoid systemd-sysusers creating a
dynamic system group for "nobody".

Also clean up the group on upgrades.

Thanks to Keh-Ming Luoh for the original patch!

Closes: #912525
---
 debian/extra/make-sysusers-basic | 3 ++-
 debian/systemd.postinst  | 9 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/debian/extra/make-sysusers-basic b/debian/extra/make-sysusers-basic
index 0aaa65cc5c..8ff1b15900 100755
--- a/debian/extra/make-sysusers-basic
+++ b/debian/extra/make-sysusers-basic
@@ -14,4 +14,5 @@ done < /usr/share/base-passwd/group.master
 
 echo
 
-awk -F:  '{ i = ($3 == $4) ? $3 : $3":"$4; printf("u %-10s %-7s - %-20s %s\n", 
$1,i,$6,$7) }'  < /usr/share/base-passwd/passwd.master
+# treat "nobody:nogroup" specially: same ID, but different name, so prevent 
creating a "nobody" group
+awk -F:  '{ i = ($3 == $4 && $4 != 65534) ? $3 : $3":"$4; printf("u %-10s %-7s 
- %-20s %s\n", $1,i,$6,$7) }'  < /usr/share/base-passwd/passwd.master
diff --git a/debian/systemd.postinst b/debian/systemd.postinst
index 21210baab8..70f0b2334d 100644
--- a/debian/systemd.postinst
+++ b/debian/systemd.postinst
@@ -155,4 +155,13 @@ if dpkg --compare-versions "$2" lt-nl "236-1~"; then
 rm -f /var/lib/systemd/clock
 fi
 
+if dpkg --compare-versions "$2" lt-nl "239-12~"; then
+# clean up bogus "nobody" group from #912525; ensure that it's a system 
group
+gid=$(grep '^nobody:x:' /etc/group | cut -f3 -d:)
+if [ -n "$gid" ] && [ "$gid" -gt 0 ] && [ "$gid" -lt 1000 ]; then
+echo "Cleaning up erroneous nobody group"
+sed -i '/^nobody:x:/d' /etc/group
+fi
+fi
+
 #DEBHELPER#
-- 
2.19.1

Bug#913905: i3-wm: focus sometimes stucks on the previous window

[Nicolas Évrard]

Package: i3-wm
Version: 4.16-1
Severity: normal

Dear Maintainer,

This is a quite difficult bug to trigger but it happens at least on
time per hour since the update to i3 version 4.16

The symptom is pretty easy to describe: when switching from one window
to another (either by calling a window from the scratchpad or by using
"focus left/right") the focus stays on the previous window yet the
window I expected to receive the focus appears (in case it's coming
from the scratchpad) and is decorated just like a focused window.

I have tried numerous way to reproduce this bug but I failed to find a
pattern. I am sorry about that as I know that such an erratic bug can
be a PITA without a reproducible scenario.

But since it's pretty annoying I though I would report it anyway.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.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 i3-wm depends on:
ii  libc6 2.27-8
ii  libcairo2 1.16.0-1
ii  libev41:4.22-1+b1
ii  libglib2.0-0  2.58.1-2
ii  libpango-1.0-01.42.4-3
ii  libpangocairo-1.0-0   1.42.4-3
ii  libpcre3  2:8.39-11
ii  libstartup-notification0  0.12-5
ii  libxcb-cursor00.1.1-4
ii  libxcb-icccm4 0.4.1-1+b1
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-randr0 1.13.1-1
ii  libxcb-util0  0.3.8-3+b2
ii  libxcb-xinerama0  1.13.1-1
ii  libxcb-xkb1   1.13.1-1
ii  libxcb-xrm0   1.0-3
ii  libxcb1   1.13.1-1
ii  libxkbcommon-x11-00.8.2-1
ii  libxkbcommon0 0.8.2-1
ii  libyajl2  2.1.0-3
ii  perl  5.28.0-3

Versions of packages i3-wm recommends:
ii  fonts-dejavu-core   2.37-1
ii  libanyevent-i3-perl 0.17-1
ii  libjson-xs-perl 3.040-1+b1
ii  rxvt-unicode [x-terminal-emulator]  9.22-4+b1
ii  xfonts-base 1:1.0.4+nmu1

i3-wm suggests no packages.

-- no debconf information

Bug#913871: Fwd: Re: Bug#913871: [libboost-coroutine-dev] Projects using libboost-coroutine2 fails to compile with g++8 and -std=gnu++17

[Giovanni Mascellani]

Dear Bogdan,

Il 16/11/18 11:58, Bogdan Vatra ha scritto:
> I have a simple example:

Your example works on my installation, with all compatibility levels
from C++11 to C++17.

However, I just noticed that you are still using boost 1.62. Boost 1.67
has recently been uploaded to unstable. Your program should start
working as soon as you upload boost-defaults.

Bye, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles

Bug#913904: redsocks: Transparent proxy traffic no longer works on Debian Buster

[Clauzio Cristiano Perpétuo]

Package: redsocks
Version: 0.5-2
Severity: normal

Dear Maintainer,

Transparent proxy traffic no longer works...

The same configuration, as recommended in the official documentation,
worked on some previous updates. In the stable version (stretch) on the
same network, the traffic is ok. The iptables rules are the same as the
official documentation.

I do not know if the problem is in the redsocks package, the kernel version
or the iptables version.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages redsocks depends on:
ii  adduser  3.118
ii  libc62.27-8
ii  libevent-core-2.1-6  2.1.8-stable-4
ii  lsb-base 9.20170808

redsocks recommends no packages.

redsocks suggests no packages.

-- Configuration Files:
/etc/redsocks.conf changed:
base {
// debug: connection progress & client list on SIGUSR1
log_debug = off;

// info: start and end of client session
log_info = on;

/* possible `log' values are:
 *   stderr
 *   "file:/path/to/file"
 *   syslog:FACILITY  facility is any of "daemon",
"local0"..."local7"
 */
log = "syslog:daemon";

// detach from console
daemon = on;

/* Change uid, gid and root directory, these options require root
 * privilegies on startup.
 * Note, your chroot may requre /etc/localtime if you write log to
syslog.
 * Log is opened before chroot & uid changing.
 */
user = redsocks;
group = redsocks;
// chroot = "/var/chroot";

/* possible `redirector' values are:
 *   iptables   - for Linux
 *   ipf- for FreeBSD
 *   pf - for OpenBSD
 *   generic- some generic redirector that MAY work
 */
redirector = iptables;
}

redsocks {
/* 'local_ip' defaults to 127.0.0.1 for security reasons,
 * use 0.0.0.0 if you want to listen on every interface.
 * 'local_*' are used as port to redirect to.
 */
local_ip = 127.0.0.1;
local_port = 12345;

// 'ip' and 'port' are IP and tcp-port of proxy-server
// You can also use hostname instead of IP, only one (random)
// address of multihomed host will be used.
ip = 127.0.0.1;
port = 1080;


// known types: socks4, socks5, http-connect, http-relay
type = socks5;

login = "*";
password = "*";
}

redudp {
// `local_ip' should not be 0.0.0.0 as it's also used for outgoing
// packets that are sent as replies - and it should be fixed
// if we want NAT to work properly.
local_ip = 127.0.0.1;
local_port = 10053;

// 'ip' and `port' of socks5 proxy server.
ip = 127.0.0.1;
port = 1080;

// kernel does not give us this information, so we have to
duplicate it
// in both iptables rules and configuration file.  By the way, you
can
// set `local_ip' to 127.45.67.89 if you need more than 65535 ports
to
// forward ;-)
// This limitation may be relaxed in future versions using
contrack-tools.
dest_ip = 10.0.192.18;
dest_port = 53;

udp_timeout = 30;
udp_timeout_stream = 180;
}

dnstc {
// fake and really dumb DNS server that returns "truncated answer"
to
// every query via UDP, RFC-compliant resolver should repeat same
query
// via TCP in this case.
local_ip = 127.0.0.1;
local_port = 5300;
}

// you can add more 'redsocks' and 'redudp' sections if you need.

// dnsu2t {
// local_ip 127.0.0.1;
// local_port 5053;
// remote_ip 127.0.0.1;
// remote_port 10053;
// }


-- no debconf information
-- 

* Clauzio* 'KlauX' Perpétuo ∴

"Computers are like air-conditioners.
 They stop working when you open windows."

"... se alguém não quer trabalhar, também não coma." (2 Ts 3.10).

Bug#913903: ITP: centreon-web -- Network, system, applicative supervision and monitoring - main app

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 

* Package name: centreon-web
  Version : 18.10.0
  Upstream Author : Centreon
* URL : https://github.com/centreon/centreon
* License : GPL-2
  Programming Lang: PHP, JavaScript
  Description : Network, system, applicative supervision and monitoring - 
main app

Centreon is a modular and flexible platform for network, system and
applicative supervision and monitoring.

 * monitoring of network services
 * monitoring of host resources
 * simple plugin design that allows users to easily develop their own
   service checks
 * parallelized service checks
 * ability to define network hierarchies
 * contact notifications when service or host problems occur and get
   resolved (via email, page, or user-defined method)
 * ability to define event handlers to be run during service or host
   events for proactive problem resolution
 * automatic log file rotation
 * support for implementing redundant monitoring hosts

This package contains the main Centreon application.

Bug#913899: ITP: centreon-clib -- Network, system, applicative supervision and monitoring - core libraries

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 

* Package name: centreon-clib
  Version : 18.10.0
  Upstream Author : Centreon
* URL : https://github.com/centreon/centreon-clib
* License : Apache-2
  Programming Lang: C++
  Description : Network, system, applicative supervision and monitoring - 
core libraries

Centreon is a modular and flexible platform for network, system and
applicative supervision and monitoring.

 * monitoring of network services
 * monitoring of host resources
 * simple plugin design that allows users to easily develop their own
   service checks
 * parallelized service checks
 * ability to define network hierarchies
 * contact notifications when service or host problems occur and get
   resolved (via email, page, or user-defined method)
 * ability to define event handlers to be run during service or host
   events for proactive problem resolution
 * automatic log file rotation
 * support for implementing redundant monitoring hosts

This package contains the core clib libraries.

Bug#913902: ITP: centreon-lang-fr -- Network, system, applicative supervision and monitoring - French translation

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 

* Package name: centreon-lang-fr
  Version : 18.10.0
  Upstream Author : Centreon
* URL : https://github.com/centreon/centreon-translations
* License : Apache-2 ? 
(https://github.com/centreon/centreon-translations/issues/5)
  Programming Lang: None
  Description : Network, system, applicative supervision and monitoring - 
French translation

Centreon is a modular and flexible platform for network, system and
applicative supervision and monitoring.

 * monitoring of network services
 * monitoring of host resources
 * simple plugin design that allows users to easily develop their own
   service checks
 * parallelized service checks
 * ability to define network hierarchies
 * contact notifications when service or host problems occur and get
   resolved (via email, page, or user-defined method)
 * ability to define event handlers to be run during service or host
   events for proactive problem resolution
 * automatic log file rotation
 * support for implementing redundant monitoring hosts

This package contains the French language pack.

Bug#913890: nheko: More or less broken build-dependencies ("-dev" missing in many package names)

[Hubert Chathi]

On Fri, 16 Nov 2018 16:50:27 +0100, Axel Beckert  said:

> nheko seems to currently block the boost transition because it doesn't
> get rebuilt against boost 1.67 despite the alternative
> build-dependencies:

>   https://buildd.debian.org/status/package.php?p=nheko

> According to that page the issue seems to be that many of the primary
> build dependencies lack the "-dev" and hence refer to a non-existing
> and non-provided package
[...]

Ugh.  Sorry for causing delays to the transition.  I'm rebuilding and
will upload shortly.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#913901: ITP: centreon-engine -- Network, system, applicative supervision and monitoring - engine

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 

* Package name: centreon-engine
  Version : 18.10.0
  Upstream Author : Centreon
* URL : https://github.com/centreon/centreon-engine
* License : GPL-2
  Programming Lang: C++
  Description : Network, system, applicative supervision and monitoring - 
engine

Centreon is a modular and flexible platform for network, system and
applicative supervision and monitoring.

 * monitoring of network services
 * monitoring of host resources
 * simple plugin design that allows users to easily develop their own
   service checks
 * parallelized service checks
 * ability to define network hierarchies
 * contact notifications when service or host problems occur and get
   resolved (via email, page, or user-defined method)
 * ability to define event handlers to be run during service or host
   events for proactive problem resolution
 * automatic log file rotation
 * support for implementing redundant monitoring hosts

This package contains the engine daemon.

Bug#913898: ITP: centreon-broker -- Network, system, applicative supervision and monitoring - broker

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 

* Package name: centreon-broker
  Version : 18.10.0
  Upstream Author : Centreon
* URL : https://github.com/centreon/centreon-broker
* License : Apache-2
  Programming Lang: C++
  Description : Network, system, applicative supervision and monitoring - 
broker

Centreon is a modular and flexible platform for network, system and
applicative supervision and monitoring.

 * monitoring of network services
 * monitoring of host resources
 * simple plugin design that allows users to easily develop their own
   service checks
 * parallelized service checks
 * ability to define network hierarchies
 * contact notifications when service or host problems occur and get
   resolved (via email, page, or user-defined method)
 * ability to define event handlers to be run during service or host
   events for proactive problem resolution
 * automatic log file rotation
 * support for implementing redundant monitoring hosts

This package contains the broker daemon.

Bug#913900: ITP: centreon-connectors -- Network, system, applicative supervision and monitoring - connectors

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 

* Package name: centreon-connectors
  Version : 18.10.0
  Upstream Author : Centreon
* URL : https://github.com/centreon/centreon-connectors
* License : Apache-2
  Programming Lang: C++
  Description : Network, system, applicative supervision and monitoring - 
connectors

Centreon is a modular and flexible platform for network, system and
applicative supervision and monitoring.

 * monitoring of network services
 * monitoring of host resources
 * simple plugin design that allows users to easily develop their own
   service checks
 * parallelized service checks
 * ability to define network hierarchies
 * contact notifications when service or host problems occur and get
   resolved (via email, page, or user-defined method)
 * ability to define event handlers to be run during service or host
   events for proactive problem resolution
 * automatic log file rotation
 * support for implementing redundant monitoring hosts

This package contains the connectors.

Bug#913897: sssd: depending on mail attribute in AD, user is not resolvable or overwritten by other user

[Christian Schöniger]

Package: sssd
Version: 1.15.0-3
Severity: important

Using AD as id provider, sssd behaves strange on AD attribute 'mail'.

There are two user. If one of them has AD attribute 'mail' set the same like 
'userPrincipalName' of
the other user, sssd mixes up these users.

dn: CN=testuser1,OU=Users,DC=domain,DC=tld
name: testuser1
userPrincipalName: testus...@domain.tld

dn: CN=testuser2,OU=Users,DC=domain,DC=tld
name: testuser2
userPrincipalName: testus...@domain.tld
mail: testus...@domain.tld

# no probles here:
service sssd stop ; rm /var/lib/sss/db/*DOMAIN* ; service sssd start
id testuser1
uid=30875(testuser1) gid=10513(domänen-benutzer) 
groups=10513(domänen-benutzer),30882(testgrp)
id testuser2
uid=30876(testuser2) gid=10513(domänen-benutzer) 
groups=10513(domänen-benutzer),30882(testgrp)
getent group testgrp
testgrp:*:30882:testuser1,testuser2

# here the trouble starts:
sss_cache -E
id testuser1
id: ‘testuser1’: no such user
id testuser2
uid=30876(testuser2) gid=10513(domänen-benutzer) 
groups=10513(domänen-benutzer),30882(testgrp)

# changing order returns UID/groups of 'testuser2' also for 'testuser1'
service sssd stop ; rm /var/lib/sss/db/*DOMAIN* ; service sssd start
id testuser2
uid=30876(testuser2) gid=10513(domänen-benutzer) 
groups=10513(domänen-benutzer),30882(testgrp)
id testuser1
uid=30876(testuser2) gid=10513(domänen-benutzer) 
groups=10513(domänen-benutzer),30882(testgrp)
getent group testgrp
testgrp:*:30882:testuser2,testuser1

As far as I can tell, this has no obvious security implications, i.e. it's not 
possible to login
to users 'testuser2' account with password of 'testuser1'.

This issue can be solved by mapping users email address to a nonexisting AD 
attribute.
('ldap_user_email = not_in_use' in sssd.conf)


# content of /etc/sss/sssd.conf
[sssd]
services = nss, pam
config_file_version = 2
domains = DOMAIN.TLD

[domain/DOMAIN.TLD]
id_provider = ad
access_provider = ad
ldap_id_mapping = true
ldap_schema = ad
ldap_group_nesting_level = 5

min_id= 1
ldap_idmap_range_min  = 1
ldap_idmap_range_size = 5

# specifying domain SID disables id mapping hash algorithm
ldap_idmap_default_domain_sid = S-1-5-21-
ldap_idmap_default_domain = domain.tld

override_homedir = /home/%u
override_shell = /usr/bin/tcsh
ldap_user_fullname = displayName

# Enumeration is discouraged for performance reasons.
enumerate = false
ldap_referrals = false
ignore_group_members = false

debug_level = 1


-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core)
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 sssd depends on:
ii  python-sss   1.15.0-3
ii  sssd-ad  1.15.0-3
ii  sssd-common  1.15.0-3
ii  sssd-ipa 1.15.0-3
ii  sssd-krb51.15.0-3
ii  sssd-ldap1.15.0-3
ii  sssd-proxy   1.15.0-3

sssd recommends no packages.

sssd suggests no packages.

-- no debconf information


--
Mit freundlichen Grüßen - Best Regards

Christian Schöniger
Dipl.-Ing. (BA)
Systembetreuung
FES GmbH Fahrzeug-Entwicklung Sachsen / Auto-Entwicklungsring Sachsen GmbH
Crimmitschauer Straße 59, 08058 Zwickau

Tel.: +49 375 5660 254
Fax : +49 375 5660 92254
mailto:c...@fes-aes.de
http://www.fes-aes.de

* FES GmbH Fahrzeug-Entwicklung Sachsen
 USt.-Id. Nr.:  DE 141379336
 Registergericht:   Amtsgericht Chemnitz, Registernummer: HRB 4499
 Geschaeftsfuehrer: Christian Schwamberger (Vorsitzender), Ronny Tolliszus, 
Frank Weidenmueller

* Auto-Entwicklungsring Sachsen GmbH
 USt.-Id. Nr.:  DE 188743030
 Registergericht:   Amtsgericht Chemnitz, Registernummer: HRB 14770
 Geschaeftsfuehrer: Christian Schwamberger (Vorsitzender), Ronny Tolliszus, 
Frank Weidenmueller

Bug#913005: ruby-rack: CVE-2018-16471: Possible XSS vulnerability in Rack

[Chris Lamb]

Hi Salvatore et al.,

> Source: ruby-rack
[…]
> CVE-2018-16471[0]:
> Possible XSS vulnerability in Rack

Security team, like ruby-i18n, I would be more than happy to prepare
and upload a stable security upload of this package when addressing
it in jessie LTS.

Please let me know and I will come back with a debdiff.

Ruby team, again, I could easily upload to sid at the same time. Let
me know here too.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#913093: ruby-i18n: CVE-2014-10077

[Chris Lamb]

Hi Salvatore et al.,

> Source: ruby-i18n
[…]
> CVE-2014-10077[0]:
> | Hash#slice in lib/i18n/core_ext/hash.rb in the i18n gem before 0.8.0
> | for Ruby allows remote attackers to cause a denial of service
> | (application crash) via a call in a situation where :some_key is
> | present in keep_keys but not present in the hash.

Security team, I would be more than happy to prepare and upload a
stable security upload of this package when addressing it in jessie
LTS. Please let me know and I will come back with a debdiff.

Ruby team, I could easily upload to sid at the same time. Let me
know too. (I believe I have the requisite powers in Salsa already.)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#818618: dpkg-genchanges: Please exclude packages disabled in unstaged builds

[Samuel Thibault]

Hello,

Guillem Jover, le ven. 16 nov. 2018 17:19:20 +0100, a ecrit:
> On Sat, 2018-11-10 at 22:23:44 +0100, Samuel Thibault wrote:
> > Guillem Jover, le sam. 10 nov. 2018 02:46:27 +0100, a ecrit:
> > > You might want to try the problematic upload but removing the entry
> > > only from the Package-List field, keeping the entries in the .changes
> > > Binary field, and see what happens.
> > 
> > I got a reject:
> > 
> > Invalid dsc file: Package-List and Binaries fields have a different number 
> > of entries.
> 
> Ah right, sorry. I guess you could you try instead either of these
> scenarios:
> 
>   * Remove the problematic entries only from .dsc Package-List and
> Binary fields, keep them in the .changes file, and upload.
> 
>   * Remove the problematic entries only from .changes Binary and
> Description, keep them in the .dsc, and upload.
> 
> My assumption is that the first will let it through, while the second
> will not,

Indeed, the first upload got accepted without passing through NEW.

> which would indicate that dak needs to be adapted and not
> dpkg

Ok, so we need to reassign to ftpmaster?

> (although the next upload might just trim any non-generated artifact
> from the .changes file anyway).

Not sure to understand this :) Which "next upload" do you refer to?

Samuel