Bug#310148: diary.docbook

[Hilmar Preuße]

merge 170477 310148
stop

On 09.07.19 02:32, Brian May wrote:
> Hilmar Preuße  writes:

Hi,

>> Are you still interested in having this issue solved? If yes I'd find
>> out, where the bug is located (I guess xmltex is correct as you found
>> out) and then report @upstream.
> 
> I am no longer using docbook stuff in Debian.
> 
I'm merging your bug w/ bug collection #170477.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#926242: [rb-general] Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Cyril Brulebois]

Chris Lamb  (2019-07-08):
> Chris Lamb wrote:
> 
> > In light of that (and whilst my shell is a little rusty) but how about
> > we just make this all more explicit instead of abusing sed/awk?
> > 
> > For example:
> 
> […]
> 
> So, I heard a vague rumour that this "buster" thing was released? I
> was thus wondering whether we could apply my patch from:
> 
>   https://bugs.debian.org/926242#127
>   
> :)

My current plan is (1) breathing a little, (2) getting the needed
bugfixes into 10.1.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#475122: Powiadomienie o Zawieszeniu Wiadomosci E-mail

[Agata Sosinska]

Szanowny w2aBcicielu konta,


Twoje konto zostanie zawieszone w ci5gu 48 godzin z powodu 
podejrzanych dzia2a4 w skrzynce pocztowej. Administrator wykry2 inregullat 
acttivites w swojej skrzynce pocztowej.  PROSIMY O KLIKNI8CIE TUTAJ   Aby 
ponownie zweryfikowa7 konto e-mail w innym, aby unikn57 zawieszenia konta


Z powaCaniem,

 Administrator poczty e-mail. � Copyright 2019

Bug#931666: [Pkg-sugar-devel] Bug#931666: sugar-toolkit-gtk3: Latest version 0.114 compatible with both Python and Python 3 is not packaged

[aniket mathur]

Agreed. Thanks :-)

On Tue, 9 Jul 2019, 9:13 am Jonas Smedegaard,  wrote:

> control: severity -1 wishlist
>
> Hi Aniket,
>
> Quoting Aniket Mathur (2019-07-09 00:08:40)
> > Source: sugar-toolkit-gtk3
> > Severity: important
> >
> > Dear Maintainer,
> >
> >
> >* What led up to the situation?
> > The latest version of the sugar-toolkit-gtk3 is now compatible
> with both
> > Python and Python 3, but the packages for the same are not
> available
> > , which prevents use, scaled testing and thus proper
> maintainance for
> > the Python 3 language.
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > Have multiversion packages of the sugar-toolkit-gtk3.
> >* What was the outcome of this action?
> > Not able to develop packages that build for both Python and
> Python3.
> >* What outcome did you expect instead?
>
> Thanks for reporting this issue.
>
> It affects only future use, not current use, so its severity is only
> wishlist.
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>

Bug#931669: ephoto doesn't even start up

[Michael Meier]

Package: ephoto
Version: 1.5-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I've just installed ephoto to try it out. I didn't get very far. It doesn't
even start up. If I try to start it up on the console, that's what it tells me:

ERR<26189>:ecore_evas lib/elementary/efl_ui_win.c:5300
_elm_win_finalize_internal() Cannot create window.
## Copy & Paste the below (until EOF) into a terminal, then hit Enter

eina_btlog << EOF
/usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71dcc0c 0x7f5ce71b3000
/usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71dd901 0x7f5ce71b3000
/usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71decd3 0x7f5ce71b3000
/usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b84c6a 0x7f5ce690
/usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b870c1 0x7f5ce690
/usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d127a7 0x7f5ce6d01000
/usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b8750c 0x7f5ce690
/usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d127a7 0x7f5ce6d01000
/usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d0f8e4 0x7f5ce6d01000
/usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b8742b 0x7f5ce690
/usr/bin/ephoto  0x563c68457604 0x563c6843b000
/usr/bin/ephoto  0x563c68444b7f 0x563c6843b000
/usr/bin/ephoto  0x563c684448dc 0x563c6843b000
/lib/x86_64-linux-gnu/libc.so.6  0x7f5ce641e09b 0x7f5ce63fa000
/usr/bin/ephoto  0x563c6844491a 0x563c6843b000
EOF

ERR<26189>:eo lib/eo/eo.c:993 _efl_add_internal_end() Object of class
'Efl.Ui.Win_Legacy' - Not all of the object constructors have been executed.
## Copy & Paste the below (until EOF) into a terminal, then hit Enter

eina_btlog << EOF
/usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71dcc0c 0x7f5ce71b3000
/usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71dd901 0x7f5ce71b3000
/usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71decd3 0x7f5ce71b3000
/usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d0f9bc 0x7f5ce6d01000
/usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b8742b 0x7f5ce690
/usr/bin/ephoto  0x563c68457604 0x563c6843b000
/usr/bin/ephoto  0x563c68444b7f 0x563c6843b000
/usr/bin/ephoto  0x563c684448dc 0x563c6843b000
/lib/x86_64-linux-gnu/libc.so.6  0x7f5ce641e09b 0x7f5ce63fa000
/usr/bin/ephoto  0x563c6844491a 0x563c6843b000
EOF

ERR<26189>:evas_main lib/evas/canvas/evas_object_smart.c:718
_efl_canvas_group_efl_object_destructor() efl_canvas_group_del() was not called
on this object: 0x40007457 (Efl.Ui.Win_Legacy)
## Copy & Paste the below (until EOF) into a terminal, then hit Enter

eina_btlog << EOF
/usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71dcc0c 0x7f5ce71b3000
/usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71dd901 0x7f5ce71b3000
/usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71decd3 0x7f5ce71b3000
/usr/lib/x86_64-linux-gnu/libevas.so.1   0x7f5ce6f9c2c8 0x7f5ce6f02000
/usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000
/usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000
/usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b7025c 0x7f5ce690
/usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000
/usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6be29a4 0x7f5ce690
/usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000
/usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b82d9b 0x7f5ce690
/usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000
/usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d0fcec 0x7f5ce6d01000
/usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b8742b 0x7f5ce690
/usr/bin/ephoto  0x563c68457604 0x563c6843b000
/usr/bin/ephoto  0x563c68444b7f 0x563c6843b000
/usr/bin/ephoto  0x563c684448dc 0x563c6843b000
/lib/x86_64-linux-gnu/libc.so.6  0x7f5ce641e09b 0x7f5ce63fa000
/usr/bin/ephoto  0x563c6844491a 0x563c6843b000
EOF

1 rmm@RMMbook ~ % ERR<26198>:efreet_desktop lib/efreet/efreet_desktop.c:986
efreet_desktop_generic_fields_parse() no Name or _Name fields in file
'/home/rmm/.local/share/applications/_home_rmm_local_eclipse_jee-2018-12_eclipse_.desktop'
## Copy & Paste the below (until EOF) into a terminal, then hit Enter

eina_btlog << EOF
/usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f1dabe73c0c 0x7f1dabe4a000
/usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f1dabe74901 0x7f1dabe4a000
/usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f1dabe75cd3 0x7f1dabe4a000
/usr/lib/x86_64-linux-gnu/libefreet.so.1 0x7f1dabe0f1ab 0x7f1dabe01000
/usr/lib/x86_64-linux-gnu/efreet/v-1.21/efreet_desktop_cache_create
0x55c6a298ee5f 0x55c6a298b000
/usr/lib/x86_64-linux-gnu/efreet/v-1.21/efreet_desktop_cache_create
0x55c6a298dba0 0x55c6a298b000
/lib/x86_64-linux-gnu/libc.so.6  0x7f1dabc6209b 0x7f1dabc3e000
/usr/lib/x86_64-linux-gnu/efreet/v-1.21/efreet_desktop_cache_create
0x55c6a298e95a 0x55c6a298b000
EOF




-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (900, 'stable'), (600, 'unstable')
Architecture: amd64 

Bug#931668: gnome-clocks is able to trace geo-location of a host

[Damien]

Package: gnome-clocks
Version: 3.30.1-2
Severity: important
Tags: l10n

Dear Maintainer,

Hello gnome-clock dev team. First, i would like to thank you for your 
development efforts.

But I would like to address a concern i have. It came to my attention that 
current stable version of the package distributed via apt repository with 
Debian 10 (Buster), seems to be able to read and very precisely identify a 
physical location of the host machine.

As a matter of security review, currently done against the new Debian Buster 
distribution, could some one from the dev team comment and clarify how such 
functionality is possible?

The OS is running on a physical host with a coreboot bios with Intel ME removed 
from the host. Host doesn't have any physical hardware, like a GPS receiver to 
identify it's location. Host has a network connectivity via network stack - 
tcp/ip to a open internet.

During the installation of the OS, only general time zone was provided (Los 
Angeles USA).

No additional customization was done to any of the components/packages/settings 
or config files, and yet, when gnome-clocks was launched, it immediately was 
able to identify the city where the host is connected to the network as San 
Jose California.

Please note, while a general time zone was provided, package gone-clocks was 
able to identify host location in its actual point of presence (City of San 
Jose) with in the the same time zone as Los Angeles.

This essentially demonstrate an ability to trace the hosts location right down 
to a City, while a user/owner of the host never explicitly authorized/enabled 
such trace. Potentially this functionality can be used with a malicious intent 
by a hacker/state actor against the user/owner of the said host.

So, my question(s):

Is this functionality specific to the code of the gnome-clocks package, or
Was the location of the host's city was derived from with in the OS itself?
Is there a way to stop gnome-clocks from identifying by default host's 
geographical location.

Your feedback would be greatly appreciate, thank you for your time. Damien.

PS: Gnome-clocks version 3.22.1-1 running on Debian 9.9 (Stretch) did not 
demonstrated this behavior.


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

Kernel: Linux 4.19.0-5-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-clocks depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  geoclue-2.0  2.5.2-1
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgeoclue-2-0   2.5.2-1
ii  libgeocode-glib0 3.26.1-1
ii  libglib2.0-0 2.58.3-2
ii  libgnome-desktop-3-173.30.2.1-2
ii  libgsound0   1.0.2-4
ii  libgtk-3-0   3.24.5-1
ii  libgweather-3-15 3.28.2-2

gnome-clocks recommends no packages.

gnome-clocks suggests no packages.

-- no debconf information

Bug#931666: [Pkg-sugar-devel] Bug#931666: sugar-toolkit-gtk3: Latest version 0.114 compatible with both Python and Python 3 is not packaged

[Jonas Smedegaard]

control: severity -1 wishlist

Hi Aniket,

Quoting Aniket Mathur (2019-07-09 00:08:40)
> Source: sugar-toolkit-gtk3
> Severity: important
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation?
> The latest version of the sugar-toolkit-gtk3 is now compatible with 
> both
> Python and Python 3, but the packages for the same are not available
> , which prevents use, scaled testing and thus proper maintainance for 
> the Python 3 language. 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Have multiversion packages of the sugar-toolkit-gtk3.
>* What was the outcome of this action?
> Not able to develop packages that build for both Python and Python3.  
>   
>* What outcome did you expect instead?

Thanks for reporting this issue.

It affects only future use, not current use, so its severity is only wishlist.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#931667: release-notes: Postfix version in 10 (buster)

[Rob]

Package: release-notes
Severity: minor

Dear Maintainer,

Section 2.2 of the releas notes mentions shipping Postfix MTA version 3.3.2
with 10 (buster) however the version appears to be 3.4.5

Bug#931666: sugar-toolkit-gtk3: Latest version 0.114 compatible with both Python and Python 3 is not packaged

[Aniket Mathur]

Source: sugar-toolkit-gtk3
Severity: important

Dear Maintainer,


   * What led up to the situation?
The latest version of the sugar-toolkit-gtk3 is now compatible with both
Python and Python 3, but the packages for the same are not available
, which prevents use, scaled testing and thus proper maintainance for 
the Python 3 language. 
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Have multiversion packages of the sugar-toolkit-gtk3.
   * What was the outcome of this action?
Not able to develop packages that build for both Python and Python3.
   * What outcome did you expect instead?


-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-52-generic (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#931665: linux-image-5.2.0: RTL8822BE no longer there

[Bo Forslund]

Package: linux-image-5.2.0
Version: 5.2.0-1
Severity: important
Tags: upstream

Dear Maintainer,

I compiled and installed linux-5.2.0. Wireless wifi no longer worked on ASUS
ROG Strix X399-E Gaming. Compared make xconfig with kernel 5.0.16. There is no
longer a menu option for RTL9922BE (handling trhreadless wifi and Bluetooth).
have to go with 5.xx kernels for wireless wifi.

Lots of ALSA and firewire fixes in 5.2.0, good for audio recording. wireless
wifi would be nice in 5.2.0 too.

Thanks Bo



-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.16 (SMP w/24 CPU cores; PREEMPT)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#874632: texinfo: inconsistent papersize for generated dvi and ps

[Norbert Preining]

Hi

> Yes, running "dpkg-reconfigure libpaper1", then choosing "letter",
> then running dpkg-reconfigure libpaper1" again, then choosing "a4"
> fixes the configuration.

Hmmm, I simply cannot reproduce that. At my place every invocation of
dpkg-reconfigure libpaper1 changes all settings as expected.

>  Name: texlive-base/binary_chooser
>  Template: texlive-base/binary_chooser
> +Value: pdftex, dvips, dvipdfmx, xdvi
>  Owners: texlive-base
> +Flags: seen
> +Variables:
> + libpaperPaper = letter

Interesting ... not that I really understand what was going on here.

The libpaper1 texlive-base code checks
- whether the current settings for the four programs agree and agree
  with the libpaper setting
- if this is the case, then set all programs to the new values
- if this is not the case 
  - ask a debconf question about which programs should be set to
the new paper size

I can reproduce this on my computer, and the debconf actions are
correctly carried out. So hmmm - strange ...


Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#931632: lintian: Testsuite hangs in/around "debian/test-out/tags/checks/version-substvars/legacy-etcfiles"

[Chris Lamb]

Hi Felix,

> Runner died for debian/test-out/tags/checks/binaries/binaries-general:
> cd debian/test-out/tags/checks/binaries/binaries-general; make --trace
> DEFAULT_DH_COMPAT=12 failed at t/bin/build-test-packages line 375. at
> t/bin/build-test-packages line 318.

Good spot:

  https://gist.github.com/lamby/3b425bef475c7444160e438bbd581c90/raw

(dh_dwz related...)


Regards,

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

Bug#874632: texinfo: inconsistent papersize for generated dvi and ps

[Norbert Preining]

On Tue, 09 Jul 2019, Vincent Lefevre wrote:
> Actually they can, though this may be non-standard. After generating
> the dvi file from the MPFR 4.0.0 tarball ("make dvi"), I get:

Yes, using geometry package and "specials" this information can be put
into the dvi format, but it is a "special" which means it can in
principle contain anything. Some specials are interpreted by some
drivers in a certain way.

Recent drivers somehow agree on how to deal with paper sizes, thus this
has been improving.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#848579: calibre: Archos Tablet (101b oxygen) not recognised (android 6)

[Nicholas D Steeves]

Hi Florian,

On Mon, Feb 18, 2019 at 10:52:39PM +, Florian Gruel wrote:
>Hello,  i have just make a test. Tablet ok (read write)with nemo and
>nautilus.
>From calibre , there is now way to "send to device", but "save as" is
>working as workaround
>I can make more tests if you want
>Envoyé depuis mon smartphone.

Sorry it took me so long to reply, I must confess that I
missed/lost/maybe didn't receive your email.

When you write "there is now way to", do you mean "there is now a way
to" or "there is no way to"?  Being able to "save as" sounds like good
news, because that means mtp support is finally working correctly.

Four things to try that might allow "send to device" to work:
   
  1. Try plugging in the tablet after Calibre has finished
  initialising, to test to see if it's detection is failing somehow.

  2. Try creating a new user who doesn't have a Calibre configuration
  or library, download some public domain epubs as that user, and see
  if that works.  If it works, the problem is somewhere in your
  config.

  3. If the problem is somewhere in your config, then you'll need to
  make Calibre forget your tablet (do this when it's unplugged).  The
  objective here is to trigger the "new device setup" wizard.  Part of
  this step is also finding and deleting the "driveinfo.calibre" and
  "metadata.calibre" files on your device.

  4. https://www.mobileread.com/forums/showpost.php?p=1117505=3

  5. Try using the calibre web interface to browse your library
  wirelessly on your tablet.  I haven't tried it yet, but it seems
  like it ought to allow you to download books to your Downloads
  folder.  
https://manual.calibre-ebook.com/faq.html#how-do-i-use-calibre-with-my-android-phone-tablet-or-kindle-fire-hd
  

  5. Only read the following instructions and search for some custom
  configuration that may have been done in the past:
  
http://www.bernaerts-nicolas.fr/linux/74-ubuntu/268-ubuntu-automount-any-mtp-device
  This is to eliminate custom config outside of Calibre's control as a
  possible variable.

As a worst-case scenario the Android "Calibre Companion" is supposed
to have a demo version that doesn't cost anything, but I can't in good
conscience recommend it, because know if it's software libre, and I've
never tried it.  There's an article on it here:
https://m.wikihow.com/Get-Calibre-for-Android


Let me know how it goes, and please don't send a follow up message if
I take more than two weeks to reply.

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#929729: lintian: \n in filenames cause "md5sum: ...: No such file or directory"

[Chris Lamb]

Russ Allbery wrote:;

> >> The name of the files and directories installed by binary packages
> >> outside the system PATH must be encoded in UTF-8 and should be
> >> restricted to ASCII when it is possible to do so.

I ACK all the other comments here, just to add that whilst I would
concede that Policy §10.10 states the above, it is of no great use if
Lintian "blows up"; we are meant to be checking for such Policy
violations in the first place...


Best wishes,

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

Bug#826971: Please confirm if bug affects a supported Calibre version

[Nicholas D Steeves]

Control: tag -1 unreproducible

Hi Gunnar,

Gentle ping to request an update to this bug.  I have been unable to
reproduce it in either stretch or buster.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#928634: nvidia-legacy-390xx-kernel-source: Fails to build with kernel 5.1

[Kevin Locke]

Here is an additional patch with backports from 430.14 to build with
kernel 5.2.  Again tested by me on amd64 but not arm or i386.

Cheers,
Kevin
Author: Kevin Locke 
Description: backport changes from 430.14 for kernel 5.2

Note: addition of set_page_dirty backported due to fc1d8e7cca2d

--- a/nvidia-uvm/uvm8_tools.c
+++ b/nvidia-uvm/uvm8_tools.c
@@ -204,18 +204,21 @@
 return event_tracker != NULL && !event_tracker->is_queue;
 }
 
-static void put_user_pages(struct page **pages, NvU64 page_count)
+static void uvm_put_user_pages_dirty(struct page **pages, NvU64 page_count)
 {
 NvU64 i;
-for (i = 0; i < page_count; i++)
+
+for (i = 0; i < page_count; i++) {
+set_page_dirty(pages[i]);
 put_page(pages[i]);
+}
 }
 
 static void unmap_user_pages(struct page **pages, void *addr, NvU64 size)
 {
 size = DIV_ROUND_UP(size, PAGE_SIZE);
 vunmap((NvU8 *)addr);
-put_user_pages(pages, size);
+uvm_put_user_pages_dirty(pages, size);
 uvm_kvfree(pages);
 }
 
@@ -279,7 +282,7 @@
 uvm_kvfree(vmas);
 
 if (ret > 0)
-put_user_pages(*pages, ret);
+uvm_put_user_pages_dirty(*pages, ret);
 else if (ret < 0)
 status = errno_to_nv_status(ret);
 

Bug#310148: diary.docbook

[Brian May]

Hilmar Preuße  writes:

> Are you still interested in having this issue solved? If yes I'd find
> out, where the bug is located (I guess xmltex is correct as you found
> out) and then report @upstream.

I am no longer using docbook stuff in Debian.

Regards
-- 
Brian May 
https://linuxpenguins.xyz/brian/

Bug#931295: u-boot-sunxi: cannot stop autoboot with usb keyboard on cubietruck

[Vagrant Cascadian]

On 2019-07-08, Vagrant Cascadian wrote:
> On 2019-07-03, Phil Morrell wrote:
>> Looking through [configs/Cubietruck_defconfig], it seems highly likely
>> to me that commit [29d280c8] is the fix. I don't know if it's
>> backportable and I'm not sure how to rebuild this package, but I'm happy
>> to test any images built with:
>>
>> CONFIG_USB_OHCI_HCD=y
>
>> I was also not sure if this should be important (because it only affects
>> some hardware) or grave because for the hardware it does affect, I'm
>> unable to install Buster.
>
> I don't think it warrants a higher severity, as you can also install or
> use it over serial console.
>
>
>> [29d280c8]: 
>> https://gitlab.denx.de/u-boot/u-boot/commit/29d280c88a1ff331dce2d4c7a5aaf2402aa0fd8a#0eebb5a51fc5f88e9eddcca0b9a87309b0c07e0c
>
> This commit is present upstream as of v2019.04-rc1.
>
> Would you please test if it is fixed in newer versions in experimental?
> Currently 2019.07~rc4+dfsg-1, though I'm likely to upload the released
> version shortly.
>
> If you can confirm it's fixed in newer versions, it's worth looking
> deeper into fixing it in a buster point release...

I just realized re-reading the thread that you already tested the
working version, sorry for the noise.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#931305: xterm: problems with Greek pi (π) and box-drawing

[Thomas Dickey]

On Mon, Jul 01, 2019 at 01:27:28PM +0300, Protesilaos Stavrou wrote:
> Package: xterm
> Version: 344-1
> Severity: normal
> 
> Dear Maintainer,
> 
> While using proportional fonts, the Greek letter pi (π) is treated as
> a box-drawing character or, more likely, as missing from the
> proportional font altogether.  This happens _only at certain point
> sizes_ AND/OR _only with specific fonts_.
> 
> Scenario 1: Greek pi works, but box-drawing does not
> 
> 
> With these settings:
> 
>   xterm.vt100.faceName: DejaVu Sans Mono

actually that's not a proportional font (it's fixed-pitch)

>   xterm.vt100.faceSize: 10
>   XTerm.vt100.forceBoxChars: false
> 
> The greek letter pi is displayed correctly, but the second vertical line
> (drawn with U+2502) is almost the same as the first one (drawn with
> U+007C).
...

> Regardless of typeface, enabling forceBoxChars will always draw the
> letter pi in a bitmap font.

   forceBoxChars (class ForceBoxChars)
   Specifies whether xterm-dev should assume the normal and bold
   fonts have VT100 line-drawing characters:
 
That sounds as expected: the lower-case "pi" happens to be one of the
VT100 graphic characters (if I made the manpage say "graphic", there
would be more confusion than referring to them as line-drawing).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#931631: Wrong dependency on virtual logind packages

[Michael Biebl]

Am 09.07.19 um 01:49 schrieb Colin Watson:
> On Tue, Jul 09, 2019 at 12:44:20AM +0200, Michael Biebl wrote:
>> Am 08.07.19 um 18:13 schrieb Colin Watson:
>>> CCing Adam, who suggested the default-logind | logind part of this; I
>>> know very little about elogind myself.
>>>
>>> I can see how an "artificial" dependency like this might make sense to
>>> avoid libpam-systemd being pulled in for people who aren't using
>>> systemd, though, even if other logind implementations don't provide the
>>> same session registration features.
>>
>> Well, if that is the sole reason why that alternative dependency was
>> added, then this is a poor choice.
> 
> Assuming that my attempt to restate the requirement is correct, what's
> your concrete alternative proposal, implementable in openssh, that also
> satisfies that requirement?

Assuming it is, there is none (atm), or is there?
So imho it's best to revert this change since it doesn't achieve what it
is supposed to achieve and is simply confusing.



-- 
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#931658: runit-init: Boot hangs with QEMU if openssh-server is installed

[Colin Watson]

On Tue, Jul 09, 2019 at 12:20:50AM +0200, Lorenzo Puliti wrote:
> Dear runit and openssh maintainers,
> 
> when rebooting a QEMU image (debian Sid, from autopkgtest) with runit-init, 
> if ssh server 
> is installed and enabled, the system hangs at boot because the ssh server is 
> stuck and unresponsive 
> (see bug 930758 message 50).
> Also, I suspect that the same problem can happen with Virtualbox (see 838480 
> message 49).
> I'm not sure if this is a bug with runit or openssh-server and it's not easy 
> for me to
> understand what triggers this bug; for example in my system i have ssh server
> and runit as init and all is working as expected..

Is this just another instance of problems with your virtual machine not
having enough entropy (#912616 etc.)?  You might well not see the same
thing on bare metal due to a hardware RNG.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#931631: Wrong dependency on virtual logind packages

[Colin Watson]

On Tue, Jul 09, 2019 at 12:44:20AM +0200, Michael Biebl wrote:
> Am 08.07.19 um 18:13 schrieb Colin Watson:
> > CCing Adam, who suggested the default-logind | logind part of this; I
> > know very little about elogind myself.
> > 
> > I can see how an "artificial" dependency like this might make sense to
> > avoid libpam-systemd being pulled in for people who aren't using
> > systemd, though, even if other logind implementations don't provide the
> > same session registration features.
> 
> Well, if that is the sole reason why that alternative dependency was
> added, then this is a poor choice.

Assuming that my attempt to restate the requirement is correct, what's
your concrete alternative proposal, implementable in openssh, that also
satisfies that requirement?  I'm not enthusiastic about simply reverting
the change from #923199, unless the people who requested it tell me that
it's not in fact needed.

> Also, it would have been a good idea to mention that in the changelog.

To be fair I'm reverse-engineering this from bug records and the like;
it didn't seem a big deal to me at the time, so I didn't work out all
the details sufficiently to describe them in the changelog.

> What you really want to fix is apt trying to satisfy a recommends over
> uninstalling/installing a new init system (which tbh I find kinda odd,
> that apt prefers to uninstall a package over not installing a recommends).

It's not in my power to change apt's dependency resolution in a
reasonable time frame.

> And also, this alternative dependency is completely useless if you don't
> already have elogind installed, which I suspect is the case (about 1%
> have sysvinit installed, the number for elogind is only statistic noise).

Well, I may also have made a wrong guess as to the underlying reason for
the request, so hopefully Adam can fill in more detail.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#931499: initramfs hook scripts which use log_* functions die

[Ben Hutchings]

[Please use "reply to all", to record your messages in the bug
reporting system.]

On Sun, 2019-07-07 at 19:38 +0200, Guenther Brunthaler wrote:
> Am 2019-07-07 um 15:50 schrieb Ben Hutchings:
> 
> > These functions are meant to be used by boot scripts, not by hook
> > scripts.
> 
> Thank you, this is good to know!
> 
> Unfortunatly, this wasn't so clear for me.
> 
> > The documentation is consistent with that.
> 
> Actually, the documentation is *lacking* in this area.
> 
> It does not explain at all how a hook script shall emit its diagnostic
> messages.
> 
> So the reader is left to speculations.
[...]

Yes, I can see how you went down this path.  We should separate
functions meant for use at boot time, and those few functions meant for
use at either build or boot time; and then only include definitions of
the latter in "hook-functions".

The answer to "how to log messages" is largely the same as for any
shell script: use echo or printf, and redirect warnings and errors to
stderr.  If you have messages that should only appear in verbose mode
(mkinitramfs -v), test the "verbose" variable, e.g.:

[ "${verbose}" = y ] && echo "Doing my thing"

Ben.

-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.




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

Bug#931499: [Fwd: Re: initramfs hook scripts which use log_* functions die]

[Ben Hutchings]

 Forwarded Message 
From: Guenther Brunthaler 
To: Ben Hutchings 
Subject: Re: initramfs hook scripts which use log_* functions die
Date: Sun, 7 Jul 2019 19:38:00 +0200
Message-Id: <26898f5b-40b3-d225-03c1-3f4955035...@gmx.net>

Am 2019-07-07 um 15:50 schrieb Ben Hutchings:

> These functions are meant to be used by boot scripts, not by hook
> scripts.

Thank you, this is good to know!

Unfortunatly, this wasn't so clear for me.

> The documentation is consistent with that.

Actually, the documentation is *lacking* in this area.

It does not explain at all how a hook script shall emit its diagnostic
messages.

So the reader is left to speculations.

And there are ample of such logging functions for boot scripts
documented only a few paragraphs later.

This makes someone trying to find for a way to emit messages in hook
scripts at least wonder whether the same functions could also be used in
hook scripts.

Visual inspection of the helper script revealed that its logging
functions might work in hook scripts as well - and practical tests
verified this in Debian 8 and Debian 9.

Suddenly, in Debian 10, now it won't work any longer.

So, summing up, this bug is not really a regression.

It is an unfortunate consequence of lacking information in the man page.

I would therefore suggest to enhance the text of the manual page in the
section about hook scripts either by

* Explaining where to or how a hook script should emit its diagnostic
messages

* Stating that a hook script must not emit such messages at all (i. e.
redirect it to some private file instead if absolutely required)

Then the reader knows what to do and does not have to wonder any longer.

> Which hook scripts are using them?

My own ones!

For instance, I have tmux in my initramfs for additional comfort when
repairing a damaged "/"-filesystem remotely via dropbear.

tmux requires a UTF-8 locale in order to work, so I added the following
hook script to install one:


$ cat /etc/initramfs-tools/hooks/locale-j2mkmlcr0gu1pkjv7vn84ksnl
#! /bin/sh
# Copyright (c) 2018 Guenther Brunthaler. All rights reserved.
#
# This script is free software.
# Distribution is permitted under the terms of the GPLv3.

locale=C.UTF-8
locale_data=/usr/lib/locale/$locale
ti_src=/lib/terminfo
ti_dst=/etc/terminfo
tinfos='linux screen xterm'

set -e

case $1 in
 prereqs) echo; exit
esac

. /usr/share/initramfs-tools/scripts/functions

log_begin_msg "Installing $locale locale"
find -H "$locale_data" \
> while IFS= read -r fso
do
 dest=$DESTDIR$fso
 if test -d "$fso"
 then
 mode=`stat -c %a -- "$fso"`
 mkdir -pm "$mode" -- "$dest"
 else
 cp -Pp -- "$fso" "$dest"
 fi
done
log_end_msg


Although not all of my hook scripts produce output, some of them like
the one above do, and it has worked without any problems in Debian 8 and
Debian 9.

Now it does't any more, at least not without my kludge.

Of course, with the newfound knowledge obtained from your statement, I
will now replace /usr/share/initramfs-tools/scripts/functions with my
own implementation of the same functions. (Or rather with a private copy
of the Debian 8 version of the script functions, as I would like to
avoid reinventing the wheel.)
-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Vagrant Cascadian]

On 2019-07-09, Francesco Poli wrote:
> On Wed, 19 Jun 2019 08:39:50 +0200 Salvatore Bonaccorso wrote:
>
> [...] 
>> On Tue, Jun 18, 2019 at 09:03:23PM +0200, Ansgar Burchardt wrote:
> [...]
>> > We could also just not accept .buildinfo uploads when they don't contain
>> > useful information about published binaries, that is for source-only
>> > uploads.
>> > 
>> > Maybe I should reenable the check for this at least on security-master?
>> > It was rejecting uploads that are okay for unstable/experimental so I
>> > disabled it again the last time.
>> 
>> Thank you I think that would be a good compromise. Source-only uploads
>> remain possible for security uploads,
> [...]
>> and instead uploads which
>> contain a buildinfo file rejected giving the uploader a explanation
>> why, and the possiblity to just reupload a "proper" source only one.
> [...]
>
>
> Hello all,
> sorry for adding noise to this long discussion.
>
> Maybe it's a naive question: what's the use of including a .buildinfo
> file into a source-only upload? Is it superfluous?

It's an attestation from the uploader that they built the package, what
the hashes of their build are, and the build environment used to produce
those binary packages. If there are differences between the buildd build
of the package and the uploader's build of the package, it may be
possible to compare the results.

I usually use sbuild's --source-only-changes feature to produce a
.changes that also includes the .buildinfo that produced my local debs
without uploading the actual .deb files to the archive.

This is certainly desireable from a reproducible builds perspective.


> If it's indeed superfluous and it also causes issues on some queues,
> maybe source-only .changes files should _never_ include .buildinfo
> files...

.buildinfo files without any hashes of .deb files do seem less useful,
unless you consider the building of the .dsc as a build process
itself.


> But dpkg-genchanges shipped in dpkg-dev/1.19.7 seems to
> include .buildinfo files into every .changes file (even for source-only
> uploads):
>
> [snip from /usr/bin/dpkg-genchanges]
> 317 if (defined $file->{package} && $file->{package_type} eq 'buildinfo') 
> {
> 318 # We always distribute the .buildinfo file.
> 319 $checksums->add_from_file("$uploadfilesdir/$f", key => $f);
> 320 next;
> 321 }
> 322 
> 323 # If this is a source-only upload, ignore any other artifacts.
> 324 next if build_has_none(BUILD_BINARY);
>
> This puzzles me.
>
> Would it be better, if dpkg-genchanges completely refrained from
> including .buildinfo files into source-only .changes files?

Or calling the .buildinfo by a different name, e.g. source.buildinfo or
source-arch.buildinfo, etc.


> At the same time, dak could reject any source-only upload which also
> include a .buildinfo file.

I hope this doesn't end up being the solution.


Though a workable solution would be really welcome at this point...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#931664: nagios4: Broken configuration according to apache2_reload

[Jorge Maldonado Ventura]

Package: nagios4
Version: 4.3.4-3
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

After the installation, I cannot access the web interface
(http://localhost/nagios), and I get the following output
from `journalctl -xe`

[...]
Jul 08 18:18:46 falcot nagios4-cgi[13212]: apache2_invoke: Enable configuration
nagios4-cgi
Jul 08 18:18:46 falcot nagios4-cgi[13217]: apache2_reload: Your configuration
is broken. Not reloading
Jul 08 18:18:46 falcot nagios4-cgi[13220]: apache2_reload: AH00526: Syntax
error on line 37 of /etc/apa
Jul 08 18:18:46 falcot nagios4-cgi[13221]: apache2_reload: Invalid command
'AuthDigestDomain', perhaps
[...]


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I executed /sbin/a2enmod authz_groupfile and restarted the Apache2 server with
`systemctl restart apache2`.

   * What was the outcome of this action?

Job for apache2.service failed because the control process exited with error
code.
See "systemctl status apache2.service" and "journalctl -xe" for details.

And from `journalctl -xe` I got:

Jul 08 18:44:46 falcot apachectl[14775]: AH00526: Syntax error on line 37 of
/etc/apache2/conf-enabled/nagios4-c
Jul 08 18:44:46 falcot apachectl[14775]: Invalid command 'AuthDigestDomain',
perhaps misspelled or defined by a
Jul 08 18:44:46 falcot apachectl[14775]: Action 'start' failed.
Jul 08 18:44:46 falcot apachectl[14775]: The Apache error log may have more
information.

I didn't found anything relevant in the Apache error log.

   * What outcome did you expect instead?

I expected the package to work out-of-the-box.



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

Kernel: Linux 4.19.0-5-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nagios4 depends on:
ii  nagios4-cgi 4.3.4-3
ii  nagios4-common  4.3.4-3
ii  nagios4-core4.3.4-3

nagios4 recommends no packages.

Versions of packages nagios4 suggests:
pn  nagios-nrpe-plugin  

-- no debconf information

Bug#931636: doesnt bring up virtio interface link with kernel 5.2

[Ben Hutchings]

On Mon, 2019-07-08 at 17:52 +0200, Michael Biebl wrote:
> Am 08.07.19 um 16:41 schrieb Marc Haber:
> > Package: systemd
> > Version: 241-5
> > Severity: wishlist
> > File: systemd-networkd
> > 
> > Hi,
> > 
> > my buster (and sid) test systems don't bring up the virtio network
> > interface in systemd-networkd. systemd-networkd sends a command to a
> > netlink socket and gets back EINVAL.
> > 
> > A manually issued ip link set dev ens3 up finishes network init and the
> > interface becomse useable.
> > 
> > I will attach straces of a working and a non-working case once the bug
> > number is known. If you need additional information, I will help.
> > 
> > Going back to 5.1.16 also fixes the issue.
> 
> Could this be a kernel regression? Or a deliberate change?
> Ben, any ideas?

Whether or not there was a deliberate change, such regressions for
"real" programs are not allowed.  So I would suggest reporting this
upstream (net...@vger.kernel.org).

(I did find a change to netlink validation functions:

commit 8cb081746c031fb164089322e2336a0bf5b3070c
Author: Johannes Berg 
Date:   Fri Apr 26 14:07:28 2019 +0200

netlink: make validation more configurable for future strictness

but it looks like that is only meant to allow for stricter validation
of newly defined messages.)

Ben.

-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.




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

Bug#931663: apt: Please add 'allow-releaseinfo-change' in bash-completion

[Alban Vidal]

Package: apt
Version: 1.8.2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Dear Maintainers,

Please can you add the following option to the bash-completion file for the apt 
package (/usr/share/bash-completion/completions/apt)

- --allow-releaseinfo-change

Thanks
Regards,

Alban

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEErkjA9ZsZmKBikqaZlr1P9k5wn94FAl0j0BwTHHpvcmRoYWtA
ZGViaWFuLm9yZwAKCRCWvU/2TnCf3vhFD/9uCMbUPUh9T9LXfSGxSR1Hr4c5sS+Z
CkPslSQqNwnOFyrJdxnG9u+DcEyMjBlMDn5FGNmooZneDMaFmkNJDuYPb8yqugHm
5Fs60B06YZdnJlLEPCQc7yPoXUHPJVsISf6+mOFZS6qkaGD8x7k/zCDUOW+tBQPK
RPdlGoAruUa82nW2YhRrfdCVbpJ8MnOSxHnC5IePIUGG+00TZ2nYuOSroOnmzkfm
spS4HiNHfOGsjf1CZyfLe3nB1OBn9j58eKnhG7idW9eysO68gq9aqlWUOgtqvcpL
6E7XQrPCvSKW9HsnOn36Px/trEccDXH/zlf3OhiZY9dMGweodpReCJrnzhGrDaFL
Kkc+nQ5OtQYggjnNUMKTKbBCmHQPKPXHtj0USNNRF/77qgdBjd80EyVImajy3Ec6
XaAhByEue+HLGCzIdd/gBUasN0my8jnBF2ug5ryhiHYvyIieoz0jw028lL65Twol
IscUFAcvXYkD41oSLXgHR1/47FCpW38oS+WpC7QZ6aS9KiNDOVlwbgjbe1CujMhP
k/rAyjNKCrBZvj5n+JJmAGM7jiILjNuUV1Sq03Uo6N3sRpKbwq/m1AWCEk6OHwg1
MwLQgZ9R6paxCKDMqxe3PSpKAMA1juv08Dnu/bZK8mhpKrdoRMyPEebj3sk7dUGS
eLoZolua4L5O4w==
=X/8X
-END PGP SIGNATURE-

Bug#931295: u-boot-sunxi: cannot stop autoboot with usb keyboard on cubietruck

[Vagrant Cascadian]

On 2019-07-03, Phil Morrell wrote:
> Looking through [configs/Cubietruck_defconfig], it seems highly likely
> to me that commit [29d280c8] is the fix. I don't know if it's
> backportable and I'm not sure how to rebuild this package, but I'm happy
> to test any images built with:
>
> CONFIG_USB_OHCI_HCD=y

> I was also not sure if this should be important (because it only affects
> some hardware) or grave because for the hardware it does affect, I'm
> unable to install Buster.

I don't think it warrants a higher severity, as you can also install or
use it over serial console.


> [29d280c8]: 
> https://gitlab.denx.de/u-boot/u-boot/commit/29d280c88a1ff331dce2d4c7a5aaf2402aa0fd8a#0eebb5a51fc5f88e9eddcca0b9a87309b0c07e0c

This commit is present upstream as of v2019.04-rc1.

Would you please test if it is fixed in newer versions in experimental?
Currently 2019.07~rc4+dfsg-1, though I'm likely to upload the released
version shortly.

If you can confirm it's fixed in newer versions, it's worth looking
deeper into fixing it in a buster point release...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#909469: Bug #909469: lilyterm: crash when closing 2nd window

[Egmont Koblinger]

Hi,

> I could not find an upstream bug or commit that looks related.

Funnily, one was opened just a few hours after you made this comment.
It's at https://github.com/Tetralet/LilyTerm/issues/134.

cheers,
egmont

Bug#931662: gitlab-workhorse autopkgtest requires netstat but lacks test dep

[Steve Langasek]

Source: gitlab-workhorse
Version: 7.6.0+debian-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear maintainers,

The autopkgtests for gitlab-workhorse have recently started failing in
Ubuntu, because they need the 'netstat' command to be available but lack a
test dependency on this tool:

[...]
autopkgtest [21:45:46]: test listeningPort: [---
+ timeout 15 bash -c until echo > /dev/tcp/localhost/8181; do sleep 0.5; done
+ gitlab-workhorse
bash: connect: Connection refused
bash: /dev/tcp/localhost/8181: Connection refused
time="2019-07-08T21:45:46Z" level=info msg=Starting version="gitlab-workhorse 
(unknown version)"
+ grep 8181
+ netstat -ntap
/tmp/autopkgtest.eQTsKe/build.WGQ/src/debian/tests/listeningPort: 6: 
/tmp/autopkgtest.eQTsKe/build.WGQ/src/debian/tests/listeningPort: netstat: not 
found
autopkgtest [21:45:47]: test listeningPort: ---]
[...]

   (http://autopkgtest.ubuntu.com/packages/g/gitlab-workhorse/eoan/amd64)

It happens that the netstat is present preinstalled in the Debian
autopkgtest environment, which is why tests don't fail on ci.debian.net. 
However, net-tools is not an essential package, and is in fact in the
process of being deprecated in favor of iproute2, so is not guaranteed to be
installed going forward.

To fix this, gitlab-workhorse can simply add net-tools to the list of
depends in debian/tests/control.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#886165: lxterminal: gtk warning on vertical resize

[Egmont Koblinger]

Hi,

This was fixed in mainstream VTE (libvte-2.91-0) version 0.52.0.
See https://bugzilla.gnome.org/show_bug.cgi?id=793435 for details.

cheers,
egmont

Bug#931661: ladspa-sdk: FTBFS on hppa - missing -fPIE/-fPIC compilation option

[John David Anglin]

Package: ladspa-sdk
Version: 1.13-3
Severity: normal

Dear Maintainer,

Build fails on hppa here:

cc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o load.o load.c
cc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o default.o 
default.c
cc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o applyplugin.o 
applyplugin.c
cc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o listplugins.o 
listplugins.c
cc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o search.o search.c
cc -g -O2 -fdebug-prefix-map=/<>=. -Wformat 
-Werror=format-security -fPIE -pie \
-o ../bin/analyseplugin \
analyseplugin.o load.o default.o\
-ldl -lm\
-Wl,--as-needed
/usr/bin/ld: analyseplugin.o: relocation R_PARISC_DPREL21L can not be used when 
making a shared object; recompile with -fPIC
/usr/bin/ld: load.o: relocation R_PARISC_DPREL21L can not be used when making a 
shared object; recompile with -fPIC

As noted in the messages above, objects linked into a shared (pie) executable
need to be compiled with -fPIC or -fPIE.  Probably in this case, they should be
compiled with -fPIE for consistency.

This is a build issue.  Fixing the above will fix ld error.

Regards,
Dave Anglin


-- System Information:
Debian Release: 10.0
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.14.132+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ladspa-sdk depends on:
ii  libc6   2.28-10
ii  libgcc4 1:8.3.0-7
ii  libstdc++6  8.3.0-7

ladspa-sdk recommends no packages.

ladspa-sdk suggests no packages.

-- no debconf information

Bug#931631: Wrong dependency on virtual logind packages

[Michael Biebl]

Am 08.07.19 um 18:13 schrieb Colin Watson:
> On Mon, Jul 08, 2019 at 03:14:59PM +0200, Michael Biebl wrote:
>> in #923199, the recommends libpam-systemd was changed to
>> default-logind | logind | libpam-systemd
>>
>> This doesn't really make sense, as openssh does not use any of the
>> logind D-Bus interfaces that are supposed to be provided by those
>> virtual facilities.
>> The libpam-systemd recommends is there to ensure that login sessions are
>> registered by logind and properly moved into their own cgroups.
>> This is not a functionality that is provided by elogind or even relevant
>> for elogind.
> 
> CCing Adam, who suggested the default-logind | logind part of this; I
> know very little about elogind myself.
> 
> I can see how an "artificial" dependency like this might make sense to
> avoid libpam-systemd being pulled in for people who aren't using
> systemd, though, even if other logind implementations don't provide the
> same session registration features.

Well, if that is the sole reason why that alternative dependency was
added, then this is a poor choice.
Also, it would have been a good idea to mention that in the changelog.
What you really want to fix is apt trying to satisfy a recommends over
uninstalling/installing a new init system (which tbh I find kinda odd,
that apt prefers to uninstall a package over not installing a recommends).
And also, this alternative dependency is completely useless if you don't
already have elogind installed, which I suspect is the case (about 1%
have sysvinit installed, the number for elogind is only statistic noise).

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#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Francesco Poli]

On Wed, 19 Jun 2019 08:39:50 +0200 Salvatore Bonaccorso wrote:

[...] 
> On Tue, Jun 18, 2019 at 09:03:23PM +0200, Ansgar Burchardt wrote:
[...]
> > We could also just not accept .buildinfo uploads when they don't contain
> > useful information about published binaries, that is for source-only
> > uploads.
> > 
> > Maybe I should reenable the check for this at least on security-master?
> > It was rejecting uploads that are okay for unstable/experimental so I
> > disabled it again the last time.
> 
> Thank you I think that would be a good compromise. Source-only uploads
> remain possible for security uploads,
[...]
> and instead uploads which
> contain a buildinfo file rejected giving the uploader a explanation
> why, and the possiblity to just reupload a "proper" source only one.
[...]


Hello all,
sorry for adding noise to this long discussion.

Maybe it's a naive question: what's the use of including a .buildinfo
file into a source-only upload? Is it superfluous?

If it's indeed superfluous and it also causes issues on some queues,
maybe source-only .changes files should _never_ include .buildinfo
files...


But dpkg-genchanges shipped in dpkg-dev/1.19.7 seems to
include .buildinfo files into every .changes file (even for source-only
uploads):

[snip from /usr/bin/dpkg-genchanges]
317 if (defined $file->{package} && $file->{package_type} eq 'buildinfo') {
318 # We always distribute the .buildinfo file.
319 $checksums->add_from_file("$uploadfilesdir/$f", key => $f);
320 next;
321 }
322 
323 # If this is a source-only upload, ignore any other artifacts.
324 next if build_has_none(BUILD_BINARY);

This puzzles me.

Would it be better, if dpkg-genchanges completely refrained from
including .buildinfo files into source-only .changes files?


At the same time, dak could reject any source-only upload which also
include a .buildinfo file.


Perhaps I am completely off-track.
Please someone clarify!


-- 
 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


pgpqusOf6rUBG.pgp
Description: PGP signature

Bug#931660: rdesktop: failed to connect to xrdp security_layer=tls, freerdp works

[Imre Szőllősi]

Package: rdesktop
Version: 1.8.6-2~deb9u1
Severity: important

Dear Maintainer,

i use xrdp with security_layer=tls, and i add xrdp user to ssl-cert group
when i connect rdesktop (stretch) to xrdp (stretch) it works.
when i connect rdesktop (stretch or buster) to xrdp (buster) it can't connect 
with: "140457452530496:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert 
protocol version:../ssl/record/rec_layer_s3.c:1407:SSL alert number 70
Failed to connect, SSL required by server."
when i connect xfreerdp (stretch) to xrdp (buster) it works.

Thanks!

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

Kernel: Linux 4.9.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=hu 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rdesktop depends on:
ii  libasound21.1.3-5
ii  libc6 2.24-11+deb9u4
ii  libgssglue1   0.4-2
ii  libpcsclite1  1.8.20-1
ii  libssl1.1 1.1.0k-1~deb9u1
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libxrandr22:1.5.1-1

rdesktop recommends no packages.

Versions of packages rdesktop suggests:
ii  pcscd  1.8.20-1

-- no debconf information

Bug#931659: transition: rm python2

[Scott Kitterman]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

The Debian Python teams are working to push early for reduction/removal
of our python(2) packages with the goal of releasing bullseye with
python3 only.  is_bad includes all the binaries in python-defaults and
python2.7 source packages.

A transition tracker would help us track the work.

Scott K

Ben file:

title = "python-defaults";
is_affected = .depends ~ 
/python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg/
 | .depends ~ "''";
is_good = .depends ~ "''";
is_bad = .depends ~ 
/python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg/;

Bug#930758: runit: Add a test for switching init (systemd-->runit)

[Lorenz]

Dmitry Bogatov:
>Can't we just conflict with libnss-systemd?
Yes, that would solve the issue for runit

>Can you please file separate bug about hang boot?
Done. I'm still digging on this, but no luck so far..

Thanks,
Lorenzo



Il giorno gio 4 lug 2019 alle ore 19:41 Dmitry Bogatov 
ha scritto:

>
> [2019-07-03 02:36] Lorenz 
> > Dmitry,
> > sorry it took so long to send the patches,
>
> No need to be sorry :) You are doing awesome job at tasks I do not dare
> to tackle.
>
> > but while updating the test i run into several issues i'm not able to
> > solve by myself:
> > * I try to include openssh into the test but it makes the test fail
> because
> > ssh get stuck
> >at boot (same issue as reported by Martin Pitt in #838480 message #49)
>
> I confirm addition of `openssh-server' into test dependency indeed makes
> it hang (my log is at bottom). I will take a look and try to reproduce
> bug interactively (over VNC).
>
> > * then i try a Vbox VM and i failed to reproduce the ssh issue, but i run
> > into several other issues, see #931356
>
> Can't we just conflict with libnss-systemd?
>
> > Althought the test as it is now in the patches pass, we should deal
> > with the above issues as they are likely hitting users that attempt
> > the switch
>
> Not sure about libnss, but I agree -- ssh server is extremely important.
> Can you please file separate bug about hang boot?
>
>
>
>

Bug#874632: texinfo: inconsistent papersize for generated dvi and ps

[Vincent Lefevre]

On 2019-07-08 23:29:41 +0900, Norbert Preining wrote:
> On Fri, 08 Sep 2017, Vincent Lefevre wrote:
> > generated dvi and ps have a letter papersize, so that the contents
> 
> dvi files don't have a paper size whatsoever attached.

Actually they can, though this may be non-standard. After generating
the dvi file from the MPFR 4.0.0 tarball ("make dvi"), I get:

zira:...ls/mpfr-4.0.0/doc> strings mpfr.dvi | head -3
 TeX output 2019.07.09:0011
papersize=8.5in,11in
papersize=210mm,297mm

and dvips generates a file with A4 paper size, even when the system
is configured for letter.

So a part of the problem has been solved in the new texinfo.tex file
(at least 2017-12-18.20, i.e. the one used in MPFR 4.0.0, is OK).

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

Bug#931658: runit-init: Boot hangs with QEMU if openssh-server is installed

[Lorenzo Puliti]

Package: runit-init
Version: 2.1.2-30
Severity: normal

Dear runit and openssh maintainers,

when rebooting a QEMU image (debian Sid, from autopkgtest) with runit-init, if 
ssh server 
is installed and enabled, the system hangs at boot because the ssh server is 
stuck and unresponsive 
(see bug 930758 message 50).
Also, I suspect that the same problem can happen with Virtualbox (see 838480 
message 49).
I'm not sure if this is a bug with runit or openssh-server and it's not easy 
for me to
understand what triggers this bug; for example in my system i have ssh server
and runit as init and all is working as expected..

Lorenzo


-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit-init depends on:
ii  getty-run   2.1.2-25
ii  initscripts 2.93-8
ii  runit   2.1.2-31
ii  runit-helper2.8.10
ii  sysuser-helper  1.3.3
ii  sysv-rc 2.93-8

runit-init recommends no packages.

runit-init suggests no packages.

-- no debconf information

Bug#931646: Kmail crashes when I click on mail

[Bernhard Übelacker]

Hello Francis Laniel,
I am just looking at some crashes in some random packages,
and found this nouveau issue familiar.

I guess __pthread_cond_wait_common should be able to
handle a NULL for abstime - e.g. should "Block without a timeout".
https://sources.debian.org/src/glibc/2.28-10/nptl/pthread_cond_wait.c/#L499

There are also some many more bugs reported that all end with these
nouveau_pushbuf_kick/nouveau_pushbuf_data calls triggering
that "Assertion `kref' failed.", that might be related:
https://bugs.debian.org/927954
https://bugs.debian.org/929130
https://bugs.freedesktop.org/show_bug.cgi?id=91632
https://bugs.freedesktop.org/show_bug.cgi?id=98039
https://bugzilla.redhat.com/show_bug.cgi?id=1350275
https://bugs.archlinux.org/task/59057
https://bugreports.qt.io/browse/QTBUG-41242

The last one mentions as a workaround setting an
environment variable LIBGL_ALWAYS_SOFTWARE=1 or
QT_XCB_FORCE_SOFTWARE_OPENGL=1, maybe on of these still helps?

Kind regards,
Bernhard

Bug#917455: command-not-found: "local variable 'cnf' referenced before assignment" shown when entering an unknown command

[Matteo Croce]

I confirm the bug on a stretch upgraded to buster just now.

Regards,
-- 
Matteo Croce
per aspera ad upstream

Bug#931529: gnome : session freezed when I've tried to lock it

[Charles BLANC ROLIN]

Hi,

Today when I've tried to lock my session, my system has totaly freeze.

I've needed to halt system from power button.

Best regards,

Charles




signature.asc
Description: OpenPGP digital signature

Bug#874632: texinfo: inconsistent papersize for generated dvi and ps

[Vincent Lefevre]

On 2019-07-08 22:58:22 +0200, Hilmar Preuße wrote:
> I just had the same on my Debian stable installation: for any reason the
> debconf setting was ignored for dvips. See attached screen session, how
> I could fix that. Does it help to fix paper setting on zira?

Yes, running "dpkg-reconfigure libpaper1", then choosing "letter",
then running dpkg-reconfigure libpaper1" again, then choosing "a4"
fixes the configuration.

zira:~> tl-paper
Current context paper size (from 
/var/lib/texmf/tex/context/user/cont-sys-paper.tex): a4
Current dvipdfmx paper size (from /var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg): 
a4
Current dvips paper size (from /var/lib/texmf/dvips/config/config-paper.ps): a4
Current pdftex paper size (from 
/var/lib/texmf/tex/generic/config/pdftexconfig.tex): a4
Current xdvi paper size (from /var/lib/texmf/xdvi/XDvi-paper): a4

I can notice a change in the config.dat file:

 Name: texlive-base/binary_chooser
 Template: texlive-base/binary_chooser
+Value: pdftex, dvips, dvipdfmx, xdvi
 Owners: texlive-base
+Flags: seen
+Variables:
+ libpaperPaper = letter

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

Bug#931657: new upstream (2.12.16)

[Daniel Baumann]

Package: textstudio
Severity: minor

Hi Tom,

thank you for maintaining texstudio in Debian.

It would be nice if you could upgrade to the current upstream version
(2.12.16).

Regards,
Daniel

Bug#931656: libtorrent20: sends private IP address to trackers

[Kevin Locke]

Package: libtorrent20
Version: 0.13.7-1
Severity: normal
Tags: patch

Dear Maintainer,

I just upgraded to buster and found that rtorrent now sends my private
IP address to trackers unless manually configured (to send a bogus
address or the public address, via scripting if dynamic).  For details,
see .

Leaking the private IP can be a security and privacy issue which is not
obvious to users, unless trackers report a warning or error (most do
not).

The issue is fixed by a 2-line patch to libtorrent that has been merged,
but not released: https://github.com/rakshasa/libtorrent/pull/176

Is there any chance you would consider applying this patch, ideally in
both sid and stable?

Thanks,
Kevin


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.11 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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 libtorrent20 depends on:
ii  libc6  2.28-10
ii  libcppunit-1.14-0  1.14.0-3
ii  libgcc11:8.3.0-6
ii  libssl1.1  1.1.1c-1
ii  libstdc++6 8.3.0-6
ii  zlib1g 1:1.2.11.dfsg-1

libtorrent20 recommends no packages.

libtorrent20 suggests no packages.

-- no debconf information

Bug#931632: lintian: Testsuite hangs in/around "debian/test-out/tags/checks/version-substvars/legacy-etcfiles"

[Felix Lechner]

On Mon, Jul 8, 2019 at 7:06 AM Chris Lamb  wrote:
>
> I can't seem to get the build
> process to complete in the testsuite:

I am unable to reproduce this error using schroot and
'DEB_BUILD_OPTIONS=parallel=1 debuild'.

Looking at your log, however, I did see this:

Runner died for debian/test-out/tags/checks/binaries/binaries-general:
cd debian/test-out/tags/checks/binaries/binaries-general; make --trace
DEFAULT_DH_COMPAT=12 failed at t/bin/build-test-packages line 375. at
t/bin/build-test-packages line 318.

Will you please post debian/test-out/tags/checks/binaries/binaries-general/log?

Kind regards
Felix

Bug#931640: webext-ublock-origin: no longer functional in firefox-esr

[Markus Koschany]

Hello,

Am 08.07.19 um 17:50 schrieb Sven Joachim:
> Package: webext-ublock-origin
> Version: 1.19.0+dfsg-2
> Severity: important
> 
> After upgrading from 1.18.4+dfsg-2 I found that uBlock Origin was no
> longer functional in firefox-esr.  Some observations so far:

[...]

Thanks for reporting. I believe in order to debug this issue it would be
most effective to add your customizations one by one to a new profile
and compare the results. There will be a new firefox-esr version at the
end of the year, so it could make sense to try the most recent Firefox
release in Debian too and to use this one for debugging. If we can
narrow the issue down, I can file an upstream bug report.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#931655: ITP: vokoscreen-ng -- easy to use screencast creator

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 

* Package name: vokoscreen-ng
  Version : 2.9.8
  Upstream Author : Volker Kohaupt 
* URL : https://github.com/vkohaupt/vokoscreenNG
* License : GPL-2
  Programming Lang: C++
  Description : easy to use screencast creator

 vokoscreenNG can be used to record educational videos, live recordings
 of browser, installations, videoconferences, etc. You can capture an
 alone video or video and sound.
 .
 The program is very simple and uses an intuitiive GUI. It also can
 capture your face using a webcam in the same time, so this feature is
 especially suitable for screencasting purposes. Another feature is the
 direct capture from IEEE1394 digital cameras.
 .
 This program can save the captures in some formats, as AVI, MP4, FLV
 and MKV for video and MP3 for audio.
 .
 vokoscreenNG is a modern replacement for vokoscreen.

Bug#929729: lintian: \n in filenames cause "md5sum: ...: No such file or directory"

[Felix Lechner]

On Mon, Jul 8, 2019 at 2:35 PM Russ Allbery  wrote:
>
> I see that what you're
> trying to do is get the data deep enough into Lintian so that you can
> issue appropriate tags, and the problem is with the data representation in
> advance of tag processing, for which this isn't super-relevant.

The policy reference was very helpful. Thank you.

Bug#929729: lintian: \n in filenames cause "md5sum: ...: No such file or directory"

[Russ Allbery]

Felix Lechner  writes:
> On Mon, Jul 8, 2019 at 12:50 PM Russ Allbery  wrote:

>> The name of the files and directories installed by binary packages
>> outside the system PATH must be encoded in UTF-8 and should be
>> restricted to ASCII when it is possible to do so.

> And that reads like the tag 'file-name-is-not-valid-UTF-8'.

Yeah, apologies, I think I misunderstood your message and what you meant
by not looking at UTF-8 validity in Lintian.  I see that what you're
trying to do is get the data deep enough into Lintian so that you can
issue appropriate tags, and the problem is with the data representation in
advance of tag processing, for which this isn't super-relevant.

-- 
Russ Allbery (r...@debian.org)   

Bug#930505: display problems summary gauges with strict browsers

[Daniel Baumann]

close 930505 1.16.0-1
thanks

this has been fixed in above version, closing.

Regards,
Daniel

Bug#931654: node-json3: json3 is no more maintained

[Xavier Guimard]

Package: node-json3
Severity: normal
Tags: security upstream

According to https://github.com/bestiejs/json3, node-json3 is no more
maintained and easy to replace by native JSON.parse/JSON.stringify
functions.

A ROM-RM issue is opened (#931653). This one will avoid testing
migration.

Bug#931653: RM: node-json3 -- ROM; Dead upstream

[Xavier Guimard]

Package: ftp.debian.org
Severity: normal

Hi all,

node-json3 is no more maintained according to
https://github.com/bestiejs/json3

This package has no reverse dependencies, so it can safely be removed
from Debian archive.

Cheers,
Xavier

Bug#170477: xmlto: unable to generate a dvi or ps file from a DocBook document

[Hilmar Preuße]

On 24.11.02 01:40, Jean-Philippe Guérard wrote:

Hi,

Looks very similar to #310148. Do you still follow the work flow? Should
I try to figure, which piece of software is the root cause and
eventually report this bug to upstream?

Thanks,
  Hilmar

> This error is occuring when I try to compile a document written in 
> DocBook XML. I was able to reproduce this with the Sample XML DocBook 
> document provided by the Linux Documentation Project :
> 
> http://www.tldp.org/authors/template/Sample-HOWTO.xml
> 
> To compile this document, I use :
> 
> $ xmlto ps Sample-HOWTO.xml
> 
> I then get the following error.
> 
> --
> 
> ! LaTeX Error: Something's wrong--perhaps a missing \item.
> 
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
>  ...  
>   
> l.5 ...er.optimum="1em" space-after.maximum="2em">
>xmlns:fo="http:/...
> 
> ? 
> ! Emergency stop.
>  ...  
>   
> l.5 ...er.optimum="1em" space-after.maximum="2em">
>xmlns:fo="http:/...
> 
> No pages of output.
> --
> 
> Exactly the same thing happens when I try to generate a dvi file.
> 

-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#874632: texinfo: inconsistent papersize for generated dvi and ps

[Hilmar Preuße]

On 08.07.19 16:12, Vincent Lefevre wrote:

Hi,

> Non-existent in both cases.
> 
> I've eventually found the file showing a difference:
> 
> /var/lib/texmf/dvips/config/config-paper.ps
> 
I wasn't really sure if that config file sets the default size or if it
just contains the paper size definitions. But:

/usr/share/texlive/tlpkg/TeXLive/TLPaper.pm

# the first paper definition is the default

> but I get:
> 
> zira:~> tl-paper
> Current context paper size (from /etc/texmf/tex/context/user/cont-sys.rme): a4
> Current dvipdfmx paper size (from 
> /var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg): letter
> Current dvips paper size (from /var/lib/texmf/dvips/config/config-paper.ps): 
> letter
> Current pdftex paper size (from 
> /var/lib/texmf/tex/generic/config/pdftexconfig.tex): a4
> Current xdvi paper size (from /var/lib/texmf/xdvi/XDvi-paper): letter
> 
I just had the same on my Debian stable installation: for any reason the
debconf setting was ignored for dvips. See attached screen session, how
I could fix that. Does it help to fix paper setting on zira?

Hilmar
-- 
sigfault
#206401 http://counter.li.org
hille@haka:~$ tl-paper 
Current context paper size (from /etc/texmf/tex/context/user/cont-sys.rme): a4
Current dvipdfmx paper size (from /var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg): 
letter
Current dvips paper size (from /var/lib/texmf/dvips/config/config-paper.ps): 
letter
Current pdftex paper size (from 
/var/lib/texmf/tex/generic/config/pdftexconfig.tex): a4
Current xdvi paper size (from /var/lib/texmf/xdvi/XDvi-paper): letter
hille@haka:~$ sudo -i
[sudo] password for hille: 
root@haka:~# dpkg-reconfigure libpaper1 



root@haka:~# tl-paper 
Current context paper size (from /etc/texmf/tex/context/user/cont-sys.rme): a4
Current dvipdfmx paper size (from /var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg): 
letter
Current dvips paper size (from /var/lib/texmf/dvips/config/config-paper.ps): 
letter
Current pdftex paper size (from 
/var/lib/texmf/tex/generic/config/pdftexconfig.tex): a4
Current xdvi paper size (from /var/lib/texmf/xdvi/XDvi-paper): letter

--> selection partially ignored.

root@haka:~# dpkg-reconfigure libpaper1 
Replacing config file /etc/papersize with new version
a4
/usr/bin/tl-paper: setting paper size for pdftex to a4.
Running mktexlsr. This may take some time... done.
Building format(s) --refresh.
This may take some time... done.
a4
/usr/bin/tl-paper: setting paper size for dvips to a4.
Running mktexlsr. This may take some time... done.
a4
/usr/bin/tl-paper: setting paper size for dvipdfmx to a4.
Running mktexlsr. This may take some time... done.
a4
/usr/bin/tl-paper: setting paper size for xdvi to a4.
Running mktexlsr. This may take some time... done.
root@haka:~# tl-paper 
Current context paper size (from /etc/texmf/tex/context/user/cont-sys.rme): a4
Current dvipdfmx paper size (from /var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg): 
a4
Current dvips paper size (from /var/lib/texmf/dvips/config/config-paper.ps): a4
Current pdftex paper size (from 
/var/lib/texmf/tex/generic/config/pdftexconfig.tex): a4
Current xdvi paper size (from /var/lib/texmf/xdvi/XDvi-paper): a4
root@haka:~# dpkg-reconfigure libpaper1 



Replacing config file /etc/papersize with new version
/usr/bin/tl-paper: setting paper size for context to letter.
/usr/bin/tl-paper: setting paper size for dvipdfmx to letter.
/usr/bin/tl-paper: setting paper size for dvips to letter.
/usr/bin/tl-paper: setting paper size for pdftex to letter.
/usr/bin/tl-paper: setting paper size for xdvi to letter.
Running mktexlsr. This may take some time... done.
Building format(s) --refresh.
This may take some time... done.
root@haka:~# tl-paper 
Current context paper size (from 
/var/lib/texmf/tex/context/user/cont-sys-paper.tex): letter
Current dvipdfmx paper size (from /var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg): 
letter
Current dvips paper size (from /var/lib/texmf/dvips/config/config-paper.ps): 
letter
Current pdftex paper size (from 
/var/lib/texmf/tex/generic/config/pdftexconfig.tex): letter
Current xdvi paper size (from /var/lib/texmf/xdvi/XDvi-paper): letter
root@haka:~# 



signature.asc
Description: OpenPGP digital signature

Bug#929729: lintian: \n in filenames cause "md5sum: ...: No such file or directory"

[Felix Lechner]

Hi Russ,

On Mon, Jul 8, 2019 at 12:50 PM Russ Allbery  wrote:
>
> Policy 10.10:

Thank you for the pointer to policy.

> The name of the files installed by binary packages in the system PATH
> (namely /bin, /sbin, /usr/bin, /usr/sbin and /usr/games) must be
> encoded in ASCII.

That policy appears to be enforced by checks/files.pm. It reads like
the description for the tag 'file-name-in-PATH-is-not-ASCII'.

> The name of the files and directories installed by binary packages
> outside the system PATH must be encoded in UTF-8 and should be
> restricted to ASCII when it is possible to do so.

And that reads like the tag 'file-name-is-not-valid-UTF-8'.

Kind regards
Felix

Bug#929729: lintian: \n in filenames cause "md5sum: ...: No such file or directory"

[Felix Lechner]

Hi Chris,

On Mon, Jul 8, 2019 at 12:42 PM Chris Lamb  wrote:
>
> Do we need any of these techniques? Can we decree that the index files
> are escaped or unescaped (I'd be +1 on the latter, mind)

The index files seem to be inspired by the 't' option in tar. My sense
is that we need more encoding rather than less to preserve the meaning
of whitespace, and especially newlines, in those files. I do not think
we can leave the filenames unescaped, if that is what you are
suggesting.

> and then
> adjust all the consumer/producers of that data to reflect that? The
> current situation as I understand it is that some assume the former,
> some the latter.

I believe there is only one of each. Please let me know if you found others.

This is the producer:

https://salsa.debian.org/lintian/lintian/blob/master/collection/unpacked#L96-100

and this is the consumer:

https://salsa.debian.org/lintian/lintian/blob/master/lib/Lintian/Collect/Package.pm#L518

which uses the subroutine 'dequote_name' from here:

https://salsa.debian.org/lintian/lintian/blob/master/lib/Lintian/Util.pm#L775-795

Bug#925371: for Emacs 26.2, I guess

[Chris Waters]

Apparently this request (Enable dynamic modules) doesn't really make
sense for Debian before 26.2 is packaged; with 26.1 and earlier, it
can't be used outside the Emacs source tree. But with 26.2 (which I
assume we'll see soon now that Buster is released), "[t]he
emacs-module.h file is now installed in the system-wide include
directory as part of the Emacs installation", according to the NEWS
file in GNU's git.

(You probably know all this; I just thought it should be on record in
the BTS report.)

cheers

Bug#915948: dak: arch:all lag from amd64 causes old binaries to disappear?

[Sven Joachim]

Control: severity -1 important

On 2018-12-08 11:19 +0200, Niko Tyni wrote:

> Package: ftp.debian.org
> User: ftp.debian@packages.debian.org
> Usertags: dak
>
> The source-only upload of perl_5.28.1-3 yesterday resulted in a mirror
> push where the new arch:any binaries (perl, perl-base etc.) were in the
> amd64 Packages list, but the arch:all ones (perl-modules-5.28, perl-doc
> etc.) were missing altogether. This caused issues for people upgrading
> their chroots, as for instance build-essential was not installable
> anymore. The situation was fixed with the next mirror push.

Upgrading chroots is not so much of a problem (perl will just be held
back), but creating new ones is problematic (or, as in the above case,
impossible).

> The problem is visible in
>
>  
> http://snapshot.debian.org/archive/debian/20181207T214432Z/dists/sid/main/binary-amd64/Packages.xz

Another example is

https://snapshot.debian.org/archive/debian/20180717T222551Z/dists/sid/main/binary-amd64/Packages.xz

where there is no ncurses-base present.  This is much worse than the
perl example above, since debootstrap will happily create a chroot
lacking the ncurses-base package, but without any terminfo files all
kind of breakages will happen there. :-/

For those who want to see for themselves,

# debootstrap --variant=minbase sid /whatever/dir 
https://snapshot.debian.org/archive/debian/20180717T222551Z

Then chroot into /whatever/dir, even bash is already "interesting" to
use with backspace and delete keys producing funny results.

> I assume this happened because the amd64 builds were finished three
> hours before the 'all' builds, and the mirror push happened in between.
>
> ISTR there at least used to be a check where arch:all binaries are not
> exposed before the corresponding arch:any ones are built, but it looks
> like the reverse is not true? In any case, even the old versions (5.28.1-2
> in this case) of the arch:all binaries disappearing seems incorrect to me?

Cheers,
   Sven

Bug#919194: Merge Request with the upstream patch for LargeArrayBuilder

[Timotheus Pokorra]

The merge request is:

https://salsa.debian.org/dotnet-team/mono/merge_requests/3

Bug#929729: lintian: \n in filenames cause "md5sum: ...: No such file or directory"

[Russ Allbery]

Felix Lechner  writes:

> Since filenames are arbitrary byte sequences that serve as valid
> identifiers in the file system, I am not sure it makes sense to impose
> UTF-8 validation in Lintian.

Policy 10.10:

The name of the files installed by binary packages in the system PATH
(namely /bin, /sbin, /usr/bin, /usr/sbin and /usr/games) must be
encoded in ASCII.

The name of the files and directories installed by binary packages
outside the system PATH must be encoded in UTF-8 and should be
restricted to ASCII when it is possible to do so.

-- 
Russ Allbery (r...@debian.org)   

Bug#931652: Error in `/usr/share/doc-base/python-django-doc', line 19: all `Format' sections are invalid.

[Daniel Kahn Gillmor]

Package: python-django-doc
Version: 2:2.2.3-2

on upgrading to the above package, on a system with doc-base 0.10.8:

Processing 9 changed doc-base files...
Error in `/usr/share/doc-base/python-django-doc', line 19: all `Format' 
sections are invalid.
Note: `install-docs --verbose --check file_name' may give more details about 
the above error.

here's the output of the proposed command:

0 root@xxx:~# install-docs --verbose --check 
/usr/share/doc-base/python-django-doc 
Warning in `/usr/share/doc-base/python-django-doc', line 19: file 
`/usr/share/doc/python-django/html/index.html' does not exist.
Error in `/usr/share/doc-base/python-django-doc', line 19: all `Format' 
sections are invalid.
/usr/share/doc-base/python-django-doc: Fatal error found, the file won't be 
registered.
0 root@xxx:~# 

Thanks for maintaining django in debian!

   --dkg


signature.asc
Description: PGP signature

Bug#929729: lintian: \n in filenames cause "md5sum: ...: No such file or directory"

[Chris Lamb]

Hi Felix,

> After a cursory review of filename handling in Lintian's index files I
> can think of three possible solutions:
> 
> 1. Use String::Escape in both directions to make sure the
> transformation is reversible. (It currently isn't.)
> 2. Use Base64 to encode file names in the index.
> 3. Use an embedded DB such as SQLite in collections.

Do we need any of these techniques? Can we decree that the index files
are escaped or unescaped (I'd be +1 on the latter, mind) and then
adjust all the consumer/producers of that data to reflect that? The
current situation as I understand it is that some assume the former,
some the latter.

> > Sure thing. (I wonder whether we should also check for (at least) \t
> > and possibly even *invalid* unicode characters; those are a great way
> > to make programs blow up.)
> 
> Since filenames are arbitrary byte sequences that serve as valid
> identifiers in the file system, I am not sure it makes sense to impose
> UTF-8 validation in Lintian.

Exactly — this is what I was trying to say, sorry..


Regards,

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

Bug#806214: Status of build time test suites of tree-puzzle

[Andreas Tille]

Hi,

after switching tree-puzzle debhelper level to 9  I was cheating around
the build time test suite via

override_dh_auto_test:
# unfortunately most tests are failing for the moment
# the issue is documented in
#   debian/patches/patch_test_results.patch
# and needs to be discussed with upstream
dh_auto_test || true

The rationale was that just by switching the debhelper level the build
time test suite was run at all.  Most probably it was failing all the
time before and simply nobody realised this.  To sort this out we need
to talk to upstream.  The issue is documented in bug #806214 (bug in
CC).

I now bumped the upstream source in Git to the latest upstream release
candidate.  Since this had not changed quite some time I assume upstream
is not very rapidly pushing a final release.  However, this might be the
right point in time to sort things out.

If you check the build log of 5.2-11 at

   
https://buildd.debian.org/status/fetch.php?pkg=tree-puzzle=all=5.2-11=1539685923=0

you can find

...
dh_auto_test || true
 make -j1 check VERBOSE=1
make[2]: Entering directory '/<>'
Making check in src
make[3]: Entering directory '/<>/src'
make[3]: Leaving directory '/<>/src'
Making check in doc
make[3]: Entering directory '/<>/doc'
make[4]: Entering directory '/<>/doc'
make[4]: Nothing to be done for 'check-am'.
make[4]: Leaving directory '/<>/doc'
make[3]: Leaving directory '/<>/doc'
Making check in data
make[3]: Entering directory '/<>/data'
make[3]: Nothing to be done for 'check'.
make[3]: Leaving directory '/<>/data'
Making check in tests
make[3]: Entering directory '/<>/tests'
make  check-TESTS
make[4]: Entering directory '/<>/tests'
make[5]: Entering directory '/<>/tests'
SKIP: build-puzzle
FAIL: qp-pure-bin.test
FAIL: qp-pure-nucl.test
FAIL: qp-tn-nucl.test
FAIL: qp-hky-clock-nucl.test
FAIL: qp-hky-rhet-nucl.test
FAIL: qp-hky-rhet-clock-nucl.test
FAIL: qp-pure-prot.test
FAIL: qp-mtrev-prot.test
FAIL: qp-vt-prot.test
FAIL: qp-wag-prot.test
FAIL: qp-clock.test
FAIL: qp-jtt-prot.test
FAIL: qp-jtt-rhet-prot.test
FAIL: qp-jtt-rhet-clock-prot.test
FAIL: lm-pure-prot.test
FAIL: ut-pure-prot.test
PASS: cons-pure-prot.test
SKIP: build-remark

   : tests/test-suite.log


# TOTAL: 19
# PASS:  1
# SKIP:  2
# XFAIL: 0
# FAIL:  16
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2
...


This situation has not changed much in 5.3~rc16 and we now have time for
one release cycle to investigate this issue.  I think the first step
should be to find out the reason for at least one test suite failure.  I
have some gut feeling that the test files for comparison do not really
fit the proper result.  However, I'd like to leave this issue for
somebody who is more familiar with thy phylogeny stuff.

If we have some better understanding about these failures we should
approach upstream (in the best case with a patch).  Once we will have
managed the build time issue (hopefully) we should be able to write
autopkgtests according to the build time tests.

Any comments, hints, suggestions?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#731016: ok

[Johnson Andy]

Hea päev, palun, kas mul on sinuga sõna?

Bug#906542: adminer: Assumes ../adminer/static/default.css

[Noah St. Amand]

On Mon, 3 Jun 2019 12:13:03 +0200 Alexandre Rossi  
wrote:
> 
> I've tried to install adminer using the Debian package.
> 
> I have found the following limitations that seem at least partially related
> to this bug report.
> 
> 1) Mandatory adminer/ directory
> 
> I have not found any way to make adminer work without a /adminer/ directory.
> 
> This makes it a bit complicated to to deploy in a custom path or without
> exposing the whole /usr/share/adminer even if other files are not required.
> 
> As I understand it, this is what is described in this bug report: the problem
> is the hardcoded paths in CSS/js resources.

It looks like Adminer is actually supposed to be compiled from the files 
included in this package—I was able to get it working using the instructions 
provided here for Ubuntu 18.04:

https://stackoverflow.com/questions/52480057/install-adminer-on-ubuntu-18-04-bionic

These instructions don't solve the problem of exposing all the other files over 
HTTP, however, so after compiling I moved the resulting file to a new 
subdirectory "/usr/share/adminer/web” and aliased that in Apache rather than 
the parent directory—once it’s been compiled, it doesn’t look like the paths to 
CSS and JS files have to be maintained, so this appears to work fine.
 
> 2) No config file support
> 
> I have found no ovious way of configuring adminer using the files from the
> Debian package (e.g. enabling a plugin).

I think that this issue will go away once you’re using a compiled version 
rather than the sources, and you’ll be able to use the instructions at 
adminer.org to customize the configuration.

I’ve only just started working with this, so I’m not sure that what I’ve 
described here is the right way to get everything working, but so far it 
appears to be the right track.

Since there’s no phpMyAdmin package for Debian 10, I suspect that the Adminer 
package might suddenly start to get a lot more popular.

Cheers,
Noah

Bug#919194: upstream patch to fix this issue

[Timotheus Pokorra]

Hello,

This bug does not affect only Docky, but it is a more general issue.

At Fedora, we have had the same problem, and it is about LargeArrayBuilder.

See for details: https://bugzilla.redhat.com/show_bug.cgi?id=1704847

That bug report includes a small C# test code, that reproduces the 
error: https://bugzilla.redhat.com/attachment.cgi?id=1560358


The output looks very similar:

LINQed list:
#%&
ToArray'd list:

Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance 
of an object
  at System.Collections.Generic.LargeArrayBuilder`1[T].GetBuffer 
(System.Int32 index) [0x00022] in <13c0993ff82548209b09f271bd5e6a78>:0
  at System.Collections.Generic.LargeArrayBuilder`1[T].CopyTo 
(System.Collections.Generic.CopyPosition position, T[] array, 
System.Int32 arrayIndex, System.Int32 count) [0x00041] in 
<13c0993ff82548209b09f271bd5e6a78>:0
  at System.Collections.Generic.SparseArrayBuilder`1[T].CopyTo (T[] 
array, System.Int32 arrayIndex, System.Int32 count) [0x0009a] in 
<13c0993ff82548209b09f271bd5e6a78>:0
  at System.Collections.Generic.SparseArrayBuilder`1[T].ToArray () 
[0x00028] in <13c0993ff82548209b09f271bd5e6a78>:0
  at System.Linq.Enumerable+Concat2Iterator`1[TSource].ToArray () 
[0x00024] in <13c0993ff82548209b09f271bd5e6a78>:0
  at System.Linq.Enumerable.ToArray[TSource] 
(System.Collections.Generic.IEnumerable`1[T] source) [0x00021] in 
<13c0993ff82548209b09f271bd5e6a78>:0
  at Program.Explodinate (System.Char[] list) [0x00056] in 
:0
  at Program.Main (System.String[] args) [0x5] in 
:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object 
reference not set to an instance of an object
  at System.Collections.Generic.LargeArrayBuilder`1[T].GetBuffer 
(System.Int32 index) [0x00022] in <13c0993ff82548209b09f271bd5e6a78>:0
  at System.Collections.Generic.LargeArrayBuilder`1[T].CopyTo 
(System.Collections.Generic.CopyPosition position, T[] array, 
System.Int32 arrayIndex, System.Int32 count) [0x00041] in 
<13c0993ff82548209b09f271bd5e6a78>:0
  at System.Collections.Generic.SparseArrayBuilder`1[T].CopyTo (T[] 
array, System.Int32 arrayIndex, System.Int32 count) [0x0009a] in 
<13c0993ff82548209b09f271bd5e6a78>:0
  at System.Collections.Generic.SparseArrayBuilder`1[T].ToArray () 
[0x00028] in <13c0993ff82548209b09f271bd5e6a78>:0
  at System.Linq.Enumerable+Concat2Iterator`1[TSource].ToArray () 
[0x00024] in <13c0993ff82548209b09f271bd5e6a78>:0
  at System.Linq.Enumerable.ToArray[TSource] 
(System.Collections.Generic.IEnumerable`1[T] source) [0x00021] in 
<13c0993ff82548209b09f271bd5e6a78>:0
  at Program.Explodinate (System.Char[] list) [0x00056] in 
:0
  at Program.Main (System.String[] args) [0x5] in 
:0


The solution is to backport this commit from upstream, to Mono 5.18:

https://github.com/mono/corefx/commit/0bf46dbe2cf0a215ca6e64793b7c434433f50722

I am new to Debian packaging, if I should prepare a merge request at 
https://salsa.debian.org/dotnet-team/mono/merge_requests, I would be 
happy to do that.


All the best,

  Timotheus Pokorra

Bug#929729: lintian: \n in filenames cause "md5sum: ...: No such file or directory"

[Felix Lechner]

On Sun, Jul 7, 2019 at 7:33 AM Chris Lamb  wrote:
>

After a cursory review of filename handling in Lintian's index files I
can think of three possible solutions:

1. Use String::Escape in both directions to make sure the
transformation is reversible. (It currently isn't.)
2. Use Base64 to encode file names in the index.
3. Use an embedded DB such as SQLite in collections.

I am happy to contribute patches if we can agree on a way forward.

> Sure thing. (I wonder whether we should also check for (at least) \t
> and possibly even *invalid* unicode characters; those are a great way
> to make programs blow up.)

Since filenames are arbitrary byte sequences that serve as valid
identifiers in the file system, I am not sure it makes sense to impose
UTF-8 validation in Lintian.

Bug#931651: false positive: Match data clobbered by buffer modification hooks

[Nicholas D Steeves]

Package: emacs-nox
Version: 1:26.1+1-3.2
Severity: normal
Tags: upstream
Forwarded: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35557

Hi Rob,

I'm making this copy of David's upstream bug in the hopes that someone
might be inspired to work on it from our side.  Please add any
usertags that would make it more discoverable for someone at DebCamp.

Upstream requested reproducing with Emacs 26.2 after David filed this bug:

1. Save the following as test.el

(let ((inhibit-modification-hooks t))
  (with-temp-buffer
(insert "P'")
(goto-char (point-min))
(while (re-search-forward "\\([^\\]\\)'" nil t)
  (replace-match"\\1`"))
(buffer-substring (point-min) (point-max

2. run "emacs --batch --quick --load ./test.el"

3. Under docker, with Debian's emacs-nox (but not emacs-lucid or
   emacs-gtk, I get an error "Match data clobbered by buffer modification
   hooks".

I don't think this is Debian specific, as someone was also able to
duplicate it with "nixpkgs.emacs26-nox" (also in Docker).
   
I agree the setup sounds pretty specific, but it is used by a Debian CI
setup, which is why I care.

Here's the build info, copied out of docker:

In GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu)
 of 2019-02-03, modified by Debian built on zam904
Recent messages:
Loading /etc/emacs/site-start.d/00debian.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --enable-libsystemd --with-pop=yes
 
--enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd
 --with-pop=yes
 
--enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --with-x=no
 --without-gsettings 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs-26.1+1=. -fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'
 

Bug#931650: nautilus: Sidebar fails to show Desktop directory

[John Webster]

Package: nautilus
Version: 3.30.5-2
Severity: normal

Dear Maintainer,


   I upgraded from Debian 9.9 with XFCE to Debian 10 with XFCE. Because
   XFCE would not wake from suspend or hibernate in response to keyboard
   or mouse movement (a known bug in XFCE when using an external
   monitor--which I have), I uninstalled XFCE and installed Gnome. 
   With Gnome installed I discovered the sidebar of the Nautilus file
   manager application failed to show a shortcut to the "Desktop" folder in
   my user account's Home directory. I used Nautilus as a file manaager in XFCE 
and did not
   encounter this problem; within XFCE, Nautilus did show "Desktop" in its
   sidebar navigation shortcuts.

 I was able to create a shortcut to my Desktop folder in the Gnome
 Nautilus sidebar,
 by hitting "Ctrl+d" while viewing contents of ~/Desktop with
 Nautilus. However this shortcut appears at the bottom of the
 sidebar. Desktop is so fundamental to the user's file system that I
 believe it should appear automatically at the top of the sidebar
 along with other major directories such as Documents and Downloads.
 I tried "sudo apt-get install Nautilus" but got a message that my
 version of Nautilus was already the latest. My sources.list file
 for apt-get lists "buster" as the Debian version instead of
 "stretch."



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

Kernel: Linux 4.19.0-5-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 nautilus depends on:
ii  bubblewrap 0.3.1-4
ii  desktop-file-utils 0.23-4
ii  gsettings-desktop-schemas  3.28.1-1
ii  gvfs   1.38.1-5
ii  libatk1.0-02.30.0-2
ii  libc6  2.28-10
ii  libcairo-gobject2  1.16.0-4
ii  libcairo2  1.16.0-4
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libgexiv2-20.10.9-1
ii  libglib2.0-0   2.58.3-2
ii  libglib2.0-data2.58.3-2
ii  libgnome-autoar-0-00.2.3-2
ii  libgtk-3-0 3.24.5-1
ii  libnautilus-extension1a3.30.5-2
ii  libpango-1.0-0 1.42.4-6
ii  libpangocairo-1.0-01.42.4-6
ii  libseccomp22.3.3-4
ii  libselinux12.8-1+b1
ii  libtracker-sparql-2.0-02.1.8-2
ii  nautilus-data  3.30.5-2
ii  shared-mime-info   1.10-1
ii  tracker2.1.8-2

Versions of packages nautilus recommends:
ii  gnome-sushi  3.30.0-2
ii  gvfs-backends1.38.1-5
ii  librsvg2-common  2.44.10-2.1

Versions of packages nautilus suggests:
ii  atril [pdf-viewer]  1.20.3-1
ii  eog 3.28.4-2+b1
ii  evince [pdf-viewer] 3.30.2-3
ii  nautilus-extension-brasero  3.12.2-5
ii  nautilus-sendto 3.8.6-3
ii  totem   3.30.0-4
ii  vlc [mp3-decoder]   3.0.7-1
ii  xdg-user-dirs   0.17-2
ii  xpdf [pdf-viewer]   3.04-13

-- no debconf information

Bug#931373: Fix for buster (stable)

[Jonathan Carter]

Attached is a debdiff for buster-security.
diff -Nru calamares-settings-debian-10.0.20/debian/changelog 
calamares-settings-debian-10.0.20/debian/changelog
--- calamares-settings-debian-10.0.20/debian/changelog  2019-04-18 
10:18:37.0 +0200
+++ calamares-settings-debian-10.0.20/debian/changelog  2019-07-03 
15:05:47.0 +0200
@@ -1,3 +1,11 @@
+calamares-settings-debian (10.0.20-1+deb10u1) buster-security; urgency=medium
+
+  * New upstream release
+-  Fixes permissions for initramfs image when full-desk encryption
+   is enabled. (CVE-2019-13179) (Closes: #931373)
+
+ -- Jonathan Carter   Wed, 03 Jul 2019 13:05:47 +
+
 calamares-settings-debian (10.0.20-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
calamares-settings-debian-10.0.20/debian/patches/fix-initramfs-permissions 
calamares-settings-debian-10.0.20/debian/patches/fix-initramfs-permissions
--- calamares-settings-debian-10.0.20/debian/patches/fix-initramfs-permissions  
1970-01-01 02:00:00.0 +0200
+++ calamares-settings-debian-10.0.20/debian/patches/fix-initramfs-permissions  
2019-07-03 15:05:47.0 +0200
@@ -0,0 +1,26 @@
+Description: fix umask for initramfs permissions
+ By default, initramfs is world-readable. This configures a snippet
+ to ensure that the initramfs that will be generated is only accessable
+ by root.
+Author: Jonathan Carter 
+Bug-Debian: https://bugs.debian.org/931373
+Bug: https://github.com/calamares/calamares/issues/1191
+Last-Update: 2019-07-08
+
+--- calamares-settings-debian-10.0.20.orig/scripts/bootloader-config
 calamares-settings-debian-10.0.20/scripts/bootloader-config
+@@ -2,6 +2,14 @@
+ 
+ CHROOT=$(mount | grep proc | grep calamares | awk '{print $3}' | sed -e 
"s#/proc##g")
+ 
++# Set secure permissions for the initramfs if we're configuring
++# full-disk-encryption. The initramfs is re-generated later in the
++# installation process so we only set the permissions snippet without
++# regenerating the initramfs right now:
++if [ "$(mount | grep $CHROOT" " | cut -c -16)" = "/dev/mapper/luks" ]; then
++echo "UMASK=0077" > 
$CHROOT/etc/initramfs-tools/conf.d/initramfs-permissions
++fi
++
+ echo "Running bootloader-config..."
+ 
+ if [ -d /sys/firmware/efi/efivars ]; then
diff -Nru calamares-settings-debian-10.0.20/debian/patches/series 
calamares-settings-debian-10.0.20/debian/patches/series
--- calamares-settings-debian-10.0.20/debian/patches/series 1970-01-01 
02:00:00.0 +0200
+++ calamares-settings-debian-10.0.20/debian/patches/series 2019-07-03 
15:05:47.0 +0200
@@ -0,0 +1 @@
+fix-initramfs-permissions

Bug#931649: apt: Please advise users on moved or EOL'd repositories

[Balint Reczey]

Package: apt
Version: 1.9.1
Severity: wishlist

Dear APT Maintainers,

When a repository is no longer available APT does tell that but gives
little help to the user who the issue could be resolved:

root@teaching-dolphin:~# apt update
Ign:1 http://archive.ubuntu.com/ubuntu artful InRelease
Ign:2 http://security.ubuntu.com/ubuntu artful-security InRelease
Err:3 http://security.ubuntu.com/ubuntu artful-security Release
  404  Not Found
...
Reading package lists... Done
...
E: The repository 'http://archive.ubuntu.com/ubuntu artful-backports
Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is
therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user
configuration details.
root@teaching-dolphin:~# do-release-upgrade
Checking for a new Ubuntu release
Your Ubuntu release is not supported anymore.
For upgrade information, please visit:
http://www.ubuntu.com/releaseendoflife

On the other hand if the user knows about do-release-upgrade or can
update /etc/apt/sources.list manually the system can be upgraded to a
still supported version or changed to use the new location of the
repositories if they moved.

Please consider printing hints in well known cases to help users
getting out of the situation by either suggesting upgrading the the
system or redirecting them to the new repository URLs.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#931648: newpid: Update newpid tests for new iputils output

[Steve Langasek]

Package: newpid
Version: 10
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Hi Christoph,

In Ubuntu and Debian, the newpid autopkgtests are now failing because
iputils 20190515 has changed the output on failure, causing a mismatch with
expected output:

diff -u newnet.expected newnet.out
--- newnet.expected 2015-09-30 09:36:41.0 +
+++ newnet.out  2019-07-08 02:57:06.832695992 +
@@ -3,4 +3,4 @@
 --- 127.0.0.1 ping statistics ---
 1 packets transmitted, 1 received, 0% packet loss, 
 
-connect: Network is unreachable
+ping: connect: Network is unreachable
make[1]: *** [Makefile:10: check-newnet] Error 1

  (https://ci.debian.net/packages/n/newpid/testing/amd64/)

The attached patch simply updates the expected file to include the new
'ping: ' prefix.

Please consider including this in Debian, to unblock iputils for testing.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru newpid-10/test/newnet.expected newpid-10ubuntu1/test/newnet.expected
--- newpid-10/test/newnet.expected  2015-09-30 02:36:41.0 -0700
+++ newpid-10ubuntu1/test/newnet.expected   2019-07-08 11:50:05.0 
-0700
@@ -3,4 +3,4 @@
 --- 127.0.0.1 ping statistics ---
 1 packets transmitted, 1 received, 0% packet loss, 
 
-connect: Network is unreachable
+ping: connect: Network is unreachable

Bug#931647: movim deb package does not save URL edits during installation; later dpkg-reconfigure works OK

[Federico Grau]

Package: movim
Version: 0.14.1-5
Severity: minor

Dear Maintainer,


   * What led up to the situation?
 Started with a fresh VM installation of debian 10 buster with only
 SSH server selected.  Attempted to install debian "movim" package.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 During movim debian package installation, edits to the URL value do
 not get saved.
   * What was the outcome of this action?
 Incorrect running movim daemon configuration.  Had to correct by
 running "dpkg-reconfigure movim" manually afterwards, which fixed
 the installer issue.
   * What outcome did you expect instead?
The URL should be "http://foourl.bardomain.org/movim/;, not:
debconf value * movim/public_url: http://localhost/movim/

   * Resending from my email client, as I'm not sure if the MTA or reportbug
 was setup correctly on my test VM.




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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages movim depends on:
ii  composer1.8.4-1
ii  dbconfig-sqlite32.0.11
ii  debconf [debconf-2.0]   1.5.71
ii  fonts-open-sans 1.11-1
ii  libjs-favico.js 0.3.10~dfsg1-3
ii  php-cboden-ratchet  0.4.1-2
ii  php-cli 2:7.3+69
ii  php-cocur-slugify   3.1-1
ii  php-common  2:69
ii  php-curl2:7.3+69
ii  php-defuse-php-encryption   2.2.1-1
ii  php-dflydev-fig-cookies 2.0.0-1
ii  php-doctrine-dbal   2.9.2-1
ii  php-embed   3.3.9-1
ii  php-fabiang-sasl1.0.0-1
ii  php-gd  2:7.3+69
ii  php-htmlpurifier4.10.0-1
ii  php-illuminate-database 5.7.27-1
ii  php-imagick 3.4.3-4.1
ii  php-markdown1.8.0-1
ii  php-mbstring2:7.3+69
ii  php-monolog 1.24.0-1
ii  php-raintpl 3.1.0+dfsg-1
ii  php-ratchet-pawl0.3.4-1
ii  php-react-child-process 0.5.2-2
ii  php-react-dns   0.4.16-1
ii  php-react-http  0.8.3-3
ii  php-respect-validation  1.1.29-2
ii  php-robmorgan-phinx 0.9.2-1
ii  php-sqlite3 2:7.3+69
ii  php-symfony-console 3.4.22+dfsg-2
ii  php-xml 2:7.3+69
ii  php7.3-cli [php-cli]7.3.4-2
ii  php7.3-curl [php-curl]  7.3.4-2
ii  php7.3-gd [php-gd]  7.3.4-2
ii  php7.3-json [php-json]  7.3.4-2
ii  php7.3-mbstring [php-mbstring]  7.3.4-2
ii  php7.3-sqlite3 [php-sqlite3]7.3.4-2
ii  php7.3-xml [php-xml]7.3.4-2

Versions of packages movim recommends:
ii  apache2 [httpd]   2.4.38-3
ii  php-fpm   2:7.3+69
ii  php7.3-fpm [php-fpm]  7.3.4-2

Versions of packages movim suggests:
ii  ejabberd  18.12.1-2

-- debconf information:
  movim/passwords-do-not-match:
* movim/dbconfig-install: true
  movim/upgrade-backup: true
  movim/missing-db-package-error: abort
  movim/dbconfig-remove: true
  movim/purge: false
  movim/internal/reconfiguring: false
  movim/admin_user: admin
* movim/database-type: sqlite3
  movim/remove-error: abort
  movim/ws_port: 8080
  movim/upgrade-error: abort
  movim/install-error: abort
  movim/dbconfig-reinstall: false
  movim/db/dbname: movim
  movim/db/basepath: /var/lib/dbconfig-common/sqlite3/movim
* movim/public_url: http://localhost/movim/
  movim/internal/skip-preseed: false
  movim/dbconfig-upgrade: true

Bug#612993: BYHAND rules for debian-faq / Re: Bug#612993: Converted debian-faq to DocBook

[Javier Fernandez-Sanguino]

On Mon, 8 Jul 2019 at 06:55, Joost van Baal-Ilić <
joostvb-debian-faq-2017113...@mdcc.cx> wrote:

> > The only place where the BYHAND rules might still be needed is from the
> > fileservers (https://deb.debian.org/debian/doc/FAQ),
>
> Yes, afaik that's indeed what they're used for.
>

Correct, this is where they are used.


>
> > and I think that
> > nowadays the availability on the main website should suffice.
> >
> > What do you think?
>
> https://deb.debian.org/debian/doc/ also has documents we ship with the
> doc-debian package (social-contract, constitution, bug-reporting etc.)
> _If_ we
> choose to no longer ship the FAQ via the mirrors, we might also want to
> discuss
> what to do with these other documents.
>

Also relevant is that the documents from the mirror are used in the
DVD/CD/Blu-ray images. I would rather continue shiping the FAQ via the
mirrors.

This currently means using BYHAND rules, but maybe ftp-master can propose
an alternative mechanism to sync the contents to that directory? (there
could be a regular task to pull the information from the package or to pull
from the web).

I personally like our mirrors to be somewhat self-contained by shipping
> not just software but also some instructions.
>

I agreed with the above. Specially considering that some may receive this
content not via the mirrors network but via the media we prepare/distribute
with each release.

Best regards

Javier

Bug#906124: Additional debug info

[Vladislav Yarmak]

On Mon, 8 Jul 2019 14:57:08 +0100 Colin Watson 
wrote:
> I'm not aware of anyone working on it at the moment.  I won't directly
> revert the patch that introduced this problem because doing so would
> have too much other fallout, but I'd be happy to help you if you're
> interested in working on a patch to make GRUB behave differently in
> the presence of check_signatures while preserving the current default
> workflow.
> 
> -- 
> Colin Watson
> [cjwat...@debian.org]
> 
> 

Thanks!

Alright, here new version of linuxefi_disable_sb_fallback.patch
attached, which does what was discussed here.

I just tested it and it works. Here is gist link just in case if
bugtracker strips attaches:
https://gist.github.com/Snawoot/d669d8302262e7b377ac7a9e65f90b89

May I hope it'll be included into Debian updates?

-- 
Best Regards,
Vladislav Yarmak
>From 3627951693d3e40b5d263ca567ef990edf7b7c2f Mon Sep 17 00:00:00 2001
From: Linn Crosetto 
Date: Tue, 5 Apr 2016 11:49:05 -0600
Subject: Disallow unsigned kernels if UEFI Secure Boot is enabled

If UEFI Secure Boot is enabled and kernel signature verification fails, do not
boot the kernel. Before this change, if kernel signature verification failed
then GRUB would fall back to calling ExitBootServices() and continuing the
boot.

Patch-Name: linuxefi_disable_sb_fallback.patch

Signed-off-by: Linn Crosetto 
---
 grub-core/loader/i386/linux.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

Index: grub2-2.02+dfsg1/grub-core/loader/i386/linux.c
===
--- grub2-2.02+dfsg1.orig/grub-core/loader/i386/linux.c
+++ grub2-2.02+dfsg1/grub-core/loader/i386/linux.c
@@ -695,10 +695,8 @@ grub_cmd_linux (grub_command_t cmd __att
   using_linuxefi = 0;
   if (grub_efi_secure_boot ())
 {
-  /* Try linuxefi first, which will require a successful signature check
-	 and then hand over to the kernel without calling ExitBootServices.
-	 If that fails, however, fall back to calling ExitBootServices
-	 ourselves and then booting an unsigned kernel.  */
+  /* linuxefi requires a successful signature check and then hand over
+	 to the kernel without calling ExitBootServices. */
   grub_dl_t mod;
   grub_command_t linuxefi_cmd;
 
@@ -720,7 +718,16 @@ grub_cmd_linux (grub_command_t cmd __att
 		  return GRUB_ERR_NONE;
 		}
 	  grub_dprintf ("linux", "linuxefi failed (%d)\n", grub_errno);
-	  grub_errno = GRUB_ERR_NONE;
+	  /* Preserve default workflow if verify module is loaded and
+	 signatures are being checked. Condition below is even with
+	 code which parses "check_signatures" variable in verify.c */
+	  const char *env_chk_sig = grub_env_get ("check_signatures");
+	  if (env_chk_sig &&
+	  (env_chk_sig[0] == '1' || env_chk_sig[0] == 'e') &&
+	  grub_dl_get("verify"))
+	grub_errno = GRUB_ERR_NONE;
+	  else
+	goto fail;
 	}
 	}
 }

Bug#874632: texinfo: inconsistent papersize for generated dvi and ps

[Vincent Lefevre]

On 2019-07-08 16:40:51 +0200, Hilmar Preuße wrote:
> root@amd64-sid:~# dpkg-reconfigure libpaper1
> Replacing config file /etc/papersize with new version
> tl-paper: setting paper size for context to a4:
> /var/lib/texmf/tex/context/user/cont-sys-paper.tex
> tl-paper: setting paper size for dvipdfmx to a4:
> /var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg
> tl-paper: setting paper size for dvips to a4:
> /var/lib/texmf/dvips/config/config-paper.ps
> tl-paper: setting paper size for pdftex to a4:
> /var/lib/texmf/tex/generic/config/pdftexconfig.tex
> tl-paper: setting paper size for xdvi to a4: /var/lib/texmf/xdvi/XDvi-paper
> Running mktexlsr. This may take some time... done.
> Building format(s) --refresh.
>   This may take some time... done.
> 
> Not sure what the default value is, when there was no user interaction.

The default value is letter, but in 2015, I did
"dpkg-reconfigure libpaper1" and chose a4.

The config.dat file contains:

Name: libpaper/defaultpaper
Template: libpaper/defaultpaper
Value: a4
Owners: libpaper1, libpaper1:amd64
Flags: seen

but I get:

zira:~> tl-paper
Current context paper size (from /etc/texmf/tex/context/user/cont-sys.rme): a4
Current dvipdfmx paper size (from /var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg): 
letter
Current dvips paper size (from /var/lib/texmf/dvips/config/config-paper.ps): 
letter
Current pdftex paper size (from 
/var/lib/texmf/tex/generic/config/pdftexconfig.tex): a4
Current xdvi paper size (from /var/lib/texmf/xdvi/XDvi-paper): letter

/var/lib/texmf/dvips/config/config-paper.ps, for instance, was
regenerated during the latest texlive-base upgrade.

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

Bug#931644: Buster kernel entropy pool too low on VM boot

[Andy Smith]

Hi Michael,

On Mon, Jul 08, 2019 at 12:59:29PM -0400, Michael J. Redd wrote:
> After upgrading to Debian Buster, Xen PV guests' entropy pool is too
> low to start cryptographic services in a timely manner. This results in
> 30+ second delays in the startup of services such as SSH.

The release notes for buster do mention this issue and provide a
link to:

https://wiki.debian.org/BoottimeEntropyStarvation

which has your Haveged solution as one of its suggestions.

Cheers,
Andy

Bug#931632: lintian: Testsuite hangs in/around "debian/test-out/tags/checks/version-substvars/legacy-etcfiles"

[Chris Lamb]

Hi Felix,

> At first glance, that build looks fine. Are you sure parallel building
> is off?

Yes; from the build log in my opening mail:

make[1]: Leaving directory '/tmp/buildd/lintian-2.16.0'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/tmp/buildd/lintian-2.16.0'
 building test packages 
t/bin/build-test-packages \
-j 1 \
--work-dir="/tmp/buildd/lintian-2.16.0/debian/test-out"

Host architecture is amd64.

> […] to find the offending test (and log).

Not quite sure what you mean, beyond the log I previously sent...?


Regards,

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

Bug#874632: texinfo: inconsistent papersize for generated dvi and ps

[Vincent Lefevre]

On 2019-07-08 23:29:41 +0900, Norbert Preining wrote:
> > This silently occurs, so that for instance, one may upload incorrect
> > files to a web server, which is really annoying.
> 
> Well, dvips just follows what is configured for it. Since dvi does not
> have an embedded paper size, only what is defined in the dvips config
> files counts.

The global configuration is not OK since it may not match the
paper size for which the .dvi was generated. This is the case
on the machine where I can see the issue. Thus makeinfo should
use the "-t papertype" (or "-T papersize") dvips option.

> > The generated pdf is OK on both machines (a4 contents, a4 papersize).
> 
> ??? How do you generate it?

"make pdf", which executes makeinfo, which executes:

  texi2dvi --pdf --batch --build-dir=mpfr.t2p -o mpfr.pdf mpfr.texi

> > In case this matters (but this shouldn't), the paperconf command
> > outputs a4 on both machines.
> 
> paperconf should trigger updates to config-paper.ps, too, so there
> should be a4 also.

zira:~> paperconf
a4

but /var/lib/texmf/dvips/config/config-paper.ps has

%
% config-paper.ps
%
% This part is only used for the paper configuration of dvips
@ letter 8.5in 11in
@+ ! %%DocumentPaperSizes: Letter
@+ %%BeginPaperSize: Letter
@+ /setpagedevice where
@+  { pop << /PageSize [612 792] >> setpagedevice }
@+  { /letter where { pop letter } if }
@+ ifelse
@+ %%EndPaperSize

@ a4 210mm 297mm
@+ ! %%DocumentPaperSizes: a4
@+ %%BeginPaperSize: a4
@+ /setpagedevice where
@+  { pop << /PageSize [595 842] >> setpagedevice }
@+  { /a4 where { pop a4 } if }
@+ ifelse
@+ %%EndPaperSize
[...]

I don't know what this means, but I get the letter size.

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

Bug#931646: Kmail crashes when I click on mail

[Francis Laniel]

Package: kmail
Version: 4:18.08.3-1

When I click on a mail it sometimes crashes kmail.

The bug seems to be caused by the fact that argument abstime of function 
__pthread_cond_wait_common is NULL (see the attached traces).

I have this bug since update to Debian 10 with Linux 4.19.37-5.

Apparently, this bug is related to OpenGL and nouveau driver (https://
bugs.kde.org/show_bug.cgi?id=388050#c1).
If you have some information about it I would like to investigate.Application: KMail (kmail), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7ff1b582cf00 (LWP 1860))]

Thread 33 (Thread 0x7ff114d4d700 (LWP 1931)):
#0  futex_reltimed_wait_cancelable (private=0, reltime=0x7ff114d4c400, 
expected=0, futex_word=0x7ff114d4c5e8) at 
../sysdeps/unix/sysv/linux/futex-internal.h:142
#1  __pthread_cond_wait_common (abstime=0x7ff114d4c4a0, mutex=0x7ff114d4c598, 
cond=0x7ff114d4c5c0) at pthread_cond_wait.c:533
#2  __pthread_cond_timedwait (cond=0x7ff114d4c5c0, mutex=0x7ff114d4c598, 
abstime=0x7ff114d4c4a0) at pthread_cond_wait.c:667
#3  0x7ff1c3950a37 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#4  0x7ff1c395330a in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#5  0x7ff1c39533f2 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#6  0x7ff1c3957981 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#7  0x7ff1c3958e61 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#8  0x7ff1c3961c81 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#9  0x7ff1c9efffa3 in start_thread (arg=) at 
pthread_create.c:486
#10 0x7ff1cc4cb4cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 32 (Thread 0x7ff11554e700 (LWP 1930)):
#0  futex_reltimed_wait_cancelable (private=0, reltime=0x7ff11554d400, 
expected=0, futex_word=0x7ff11554d5e8) at 
../sysdeps/unix/sysv/linux/futex-internal.h:142
#1  __pthread_cond_wait_common (abstime=0x7ff11554d4a0, mutex=0x7ff11554d598, 
cond=0x7ff11554d5c0) at pthread_cond_wait.c:533
#2  __pthread_cond_timedwait (cond=0x7ff11554d5c0, mutex=0x7ff11554d598, 
abstime=0x7ff11554d4a0) at pthread_cond_wait.c:667
#3  0x7ff1c3950a37 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#4  0x7ff1c395330a in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#5  0x7ff1c39533f2 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#6  0x7ff1c3957981 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#7  0x7ff1c3958e61 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#8  0x7ff1c3961c81 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5
#9  0x7ff1c9efffa3 in start_thread (arg=) at 
pthread_create.c:486
#10 0x7ff1cc4cb4cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 31 (Thread 0x7ff115d4f700 (LWP 1929)):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x7ff1c14b8fb8) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x7ff1c14b8f68, 
cond=0x7ff1c14b8f90) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x7ff1c14b8f90, mutex=0x7ff1c14b8f68) at 
pthread_cond_wait.c:655
#3  0x7ff1c13c2e6a in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5
#4  0x7ff1c13c2e89 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5
#5  0x7ff1c9efffa3 in start_thread (arg=) at 
pthread_create.c:486
#6  0x7ff1cc4cb4cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 30 (Thread 0x7ff116550700 (LWP 1916)):
#0  0x7557db34 in clock_gettime ()
#1  0x7ff1cc4d8ff6 in __GI___clock_gettime (clock_id=1, tp=0x7ff11654f3e0) 
at ../sysdeps/unix/clock_gettime.c:115
#2  0x7ff1cc9d21a1 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#3  0x7ff1cc9d09d9 in QTimerInfoList::updateCurrentTime() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7ff1cc9d0fd5 in QTimerInfoList::timerWait(timespec&) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7ff1cc9d25fe in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7ff1c937a669 in g_main_context_prepare () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x7ff1c937b06b in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x7ff1c937b25c in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x7ff1cc9d287b in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x7ff1cc98027b in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7ff1cc7cfec6 in QThread::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7ff1cc7d9aa7 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x7ff1c9efffa3 in start_thread (arg=) at 
pthread_create.c:486

Bug#931641: perl: FTBFS under qemu-user

[Andreas Schwab]

On Jul 08 2019, Niko Tyni  wrote:

> I'm not sure yet where this should be fixed. I'd like to avoid reverting
> the -Dmksymlinks part introduced in 5.30.0-2 as I think enabling parallel
> builds was an improvement. But we'll see.

That should fix it:

https://github.com/openSUSE/qemu/commit/b9d571b22b86948586a3ee622a854b5fc694cc04
https://github.com/openSUSE/qemu/commit/3cec667753967b778563899cbd21cc2e617d4389

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Bug#799355: emacs-goodies-el: apache-mode has incorrect highlighting

[Nicholas D Steeves]

Control: tags -1 -moreinfo
Control: forwarded -1 https://github.com/emacs-php/apache-mode/pull/2

> On Fri, Sep 18, 2015 at 10:51:10AM +0200, Teddy Hogeborn wrote:
> > Package: emacs-goodies-el
> > Version: 35.12
> > Severity: minor
> > Tags: upstream
> > 
> > The apache-mode.el has incorrect highlighting; it highlights the word
> > "temporary" when in fact the correct syntax for Apache is "temp".
> > (See line 563 in apache-mode.el.)
> 

I assume you're referring to this?:

  temp
   Returns a temporary redirect status (302). This is the default.
  https://httpd.apache.org/docs/2.4/mod/mod_alias.html


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#931645: mcomix: Fails to start with python-pil (>= 6.0.0)

[Tatsuki Sugiura]

Package: mcomix
Version: 1.2.1-1.1
Severity: important

Dear Maintainer,

After python-pil 6.1.0-1 is installed, mcomix stop working with
following message;

---
sugi@tempest:~% mcomix
Traceback (most recent call last):
  File "/usr/bin/mcomix", line 11, in 
load_entry_point('mcomix==1.2.1', 'console_scripts', 'mcomix')()
  File "/usr/lib/python2.7/dist-packages/mcomix/run.py", line 206, in run
assert PIL.Image.VERSION >= '1.1.5'
AttributeError: 'module' object has no attribute 'VERSION'
---

If I downgrade python-pil to stable version (=5.4.1-2), mcomix works well.

Actually, it seems to be fine by just commenting out the assert line for
PIL.Image.VERSION.


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

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE, TAINT_SOFTLOCKUP
Locale: LANG=C.UTF-8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mcomix depends on:
ii  python2.7.16-1
ii  python-gtk2   2.24.0-6
ii  python-pil5.4.1-2
ii  python-pkg-resources  41.0.1-1

mcomix recommends no packages.

Versions of packages mcomix suggests:
ii  unrar  1:5.6.6-2

-- no debconf information

Bug#930937: p7zip-full: Incorrect manual regarding -p{Password}

[Avinash Sonawane]

On Sun, 23 Jun 2019 02:13:19 +0530 Avinash Sonawane 
wrote:
> Package: p7zip-full
> Version: 16.02+dfsg-3+deb9u1

This has been fixed on latest Debian stable Buster having p7zip-full
16.02+dfsg-6.

Regards,
Avinash Sonawane (rootKea)
PICT, Pune
https://rootkea.wordpress.com

Bug#929837: libgdk-pixbuf2.0-dev: Memory leak viewing animated gif

[Avinash Sonawane]

I can reproduce this bug on latest Debian stable Buster having
libgdk-pixbuf2.0-dev 2.38.1+dfsg-1

Regards,
Avinash Sonawane (rootKea)
PICT, Pune
https://rootkea.wordpress.com

Bug#931644: Buster kernel entropy pool too low on VM boot

[Michael J. Redd]

Package: linux-image-4.19.0-5-amd64
Version: 4.19.0-5

Issue:
==

After upgrading to Debian Buster, Xen PV guests' entropy pool is too
low to start cryptographic services in a timely manner. This results in
30+ second delays in the startup of services such as SSH. If I connect
to the VM's virtual VNC console and move the mouse during boot, the
system very rapidly collects entropy and crypto-dependent services like
SSH start with no delay.

The symptoms are identical to a bug I reported for Debian 9 (bug
#897917).

Workaround:
===

Install `haveged`. If another RNG feeds the entropy pool, the VM and
its services boot as expected.

Bug#927477: ITS: fluxbox -- low resource X11 Window manager

[Paul R. Tagliamonte]

Awesome! I'll see if I can't do some testing and send a format-patch. I may
have some time this weekend 

Yeah that'd be awesome!
  paultag


On Mon, Jul 8, 2019, 12:53 PM Mathias Gumz  wrote:

> Hey,
>
> > How do we feel about a new release? If we tag a new one we can do the
> whole upload thing.
>
> http://git.fluxbox.org/fluxbox.git/log/?h=prep/release-1.4.0
>
> I have started to do that some YEARS ago. Never finished it. I am on
> vacation in early August, I aim to finalize the release there. If
> $someone wants to give a hand - every bit is welcome.
>
> Workwise I am fully loaded - no sparetime left at the moment.
>
> > Hope you're well!
>
> Yeah, thanks. Busy, but ok :)
>
> When are you back in Germany? Time for a beer or two.
>
> Cheers,
> --
> [uid] mathias gumz [www] http://www.fluxbox.org/
> [pgp] 1024D/F6F6B18C [irc] ak|ra at freenode.org
>

Bug#927477: ITS: fluxbox -- low resource X11 Window manager

[Mathias Gumz]

Hey,

> How do we feel about a new release? If we tag a new one we can do the whole 
> upload thing.

http://git.fluxbox.org/fluxbox.git/log/?h=prep/release-1.4.0

I have started to do that some YEARS ago. Never finished it. I am on
vacation in early August, I aim to finalize the release there. If
$someone wants to give a hand - every bit is welcome.

Workwise I am fully loaded - no sparetime left at the moment.

> Hope you're well!

Yeah, thanks. Busy, but ok :)

When are you back in Germany? Time for a beer or two.

Cheers,
-- 
[uid] mathias gumz [www] http://www.fluxbox.org/
[pgp] 1024D/F6F6B18C [irc] ak|ra at freenode.org

Bug#929868: midori: Segmenation fault on opening Youtube.com

[Avinash Sonawane]

I am not able to reproduce this on latest Debian stable (Buster).

Regards,
Avinash Sonawane (rootKea)
PICT, Pune
https://rootkea.wordpress.com

Bug#931643: ITP: ipmctl -- utility for configuring and managing Intel Optane DC persistent memory modules

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: ipmctl
  Version : v01.00.00.3455
  Upstream Author : Intel
* URL : https://github.com/intel/ipmctl
* License : BSD
  Programming Lang: C
  Description : utility for configuring and managing Intel Optane DC 
persistent memory modules

ipmctl is a utility for configuring and managing Intel Optane DC persistent 
memory modules (PMM).
It supports functionality to:

Discover PMMs on the platform.
Provision the platform memory configuration.
View and update the firmware on PMMs.
Configure data-at-rest security on PMMs.
Monitor PMM health.
Track performance of PMMs.
Debug and troubleshoot PMMs.

There's a library, a CLI tool, and a monitoring daemon.

This piece is for handling the hardware itself and is specific to Intel
NVDIMMs (Apache Pass and newer); you then use vendor-neutral ndctl to chop
the space into namespaces and configure block devices.

Bug#931641: perl: FTBFS under qemu-user

[John Paul Adrian Glaubitz]

Hi!

On 7/8/19 6:18 PM, Niko Tyni wrote:
> This can be reproduced under for instance qemu-armhf with
> 
>   mkdir b && cd b && ../Configure -des -Dmksymlinks
> 
> resulting in lots of 'Permission denied' errors when extracting cflags.SH
> because the script mistakes the shell absolute path for its argument and
> tries to write in the same directory where the shell resides.
> 
> An even simpler reproducer is
> 
>   touch config.sh && sh < cflags.SH
> 
> This is not specific to Perl 5.30, our packaging just started to use
> -Dmksymlinks there and triggered the issue.
> 
> I'm not sure yet where this should be fixed. I'd like to avoid reverting
> the -Dmksymlinks part introduced in 5.30.0-2 as I think enabling parallel
> builds was an improvement. But we'll see.

I will open a bug report upstream with qemu.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#931390: xfce4-places-plugin: manpage in wrong section

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2019-07-03 at 20:59 +0200, Laurent Bonnaud wrote:
> this manpage:
> 
>/usr/share/man/man2/xfce4-popup-places.22.gz
> 
> is in section 22, which is most certainly a mistake.

Indeed, thanks for the report. I've updated the manpage, that'll be part of
the next upload.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl0jbjUACgkQ3rYcyPpX
RFu9HggAoGcRGJEmlMz2HfflFQvNSatov8qlJ3JZJYeZMTZ53B/hgNY0DsMfThdF
bPPJSm536rzpZICR4VhAshOMRuWpVah7sSCwPkM76I++BAWFvpoZroQwawYEbGDv
2o+Bjo33dF0hi7b0ypsY0jGQZN5B5hoVbgULMJyj0REXzcnSmr0shBUSea3wWHhm
dtXDMuAcN6jhef5lQEWz34EF/tu+kArsVQUsdBDuUOAxlvHJrudwdqcBeLSwe2Uc
NlqZ88LpiluNGyBAxVGxOGjYySbrR7H1b0Yb85hwpzc/68LexG7jRNgKk8hlMs1n
43WT1UsUjg/KitxXv31vblQnlq52jQ==
=io2E
-END PGP SIGNATURE-

Bug#931477: libhtp: Please replace Priority: extra with Priority: optional

[Sascha Steinbiss]

Dear Boyuan Yang,

thanks for your bug report.

> As indicated in 
> https://lintian.debian.org/tags/priority-extra-is-replaced-by-priority-optional.html
> , your package is still using the deprecated Priority: extra instead of
> Priority: optional. Please replace "extra" with "optional" in the next upload.

First of all: is this a bug report against the libhtp binary package or
the source package? There is no current binary package named "libhtp",
we currently (1:0.5.30) only build libhtp-dev and libhtp2.
As far as the current situation is concerned, I can confirm that the
"optional" priority is already used since late 2017 [1].

Could you please clarify what exact package and version you are
referring to? Maybe I just don't see it...?

Best regards
Sascha

[1]
https://salsa.debian.org/pkg-suricata-team/pkg-libhtp/commit/ce7a66e06a61e01e5cbadf1b4c8a0c29473637a3




signature.asc
Description: OpenPGP digital signature

Bug#931272: openssh-server: incoming connections fail if openssl's afalg engine is enabled

[Colin Watson]

On Sun, Jun 30, 2019 at 05:25:42AM -0300, Emilio López wrote:
> After enabling afalg engine on OpenSSL and configuring OpenSSH server to use 
> the following
> ciphers, incoming ssh connections stop working. When a client tries to 
> connect, you can
> observe the following message on the server's dmesg output:
> 
> [271686.264598] audit: type=1326 audit(1561879548.303:14): auid=1000 
> uid=104 gid=65534 ses=99 subj==unconfined pid=8164 comm="sshd" 
> exe="/usr/sbin/sshd" sig=31 arch=4028 syscall=281 compat=0 ip=0xb6a5ee6c 
> code=0x0
> 
> The device is a Buffalo Linkstation LS-WXL (armel, kirkwood). I would like to 
> use the crypto
> hardware accelerator (marvell_cesa) on SSH to get better performance out of 
> it, that's why
> I enabled the afalg engine.
> 
> This happens both with openssh-server from buster and experimental. Syscall 
> 281 appears to be
> socket(...) from what I could gather. Maybe it is necessary to add a few more 
> allowed syscall
> rules to the seccomp sandbox in OpenSSH?

Thanks for your report.  Would you mind filing this directly upstream?
This is the sort of thing I'd much rather get upstream review of.

  https://bugzilla.mindrot.org/

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#905226: Acknowledgement (openssh-server: SSH AuthorizedKeysCommand hangs when output is too large)

[Colin Watson]

On Tue, Jun 25, 2019 at 11:29:31AM +0200, Moritz Muehlenhoff wrote:
> On Mon, Aug 06, 2018 at 12:04:46PM +0200, Dennis Schridde wrote:
> > I confirm that the patch [1] to the upstream bug report [2] solves the 
> > issue 
> > for us.
> 
> JFTR, we've also run into this at work at the Wikimedia Foundations's 
> Phabricator
> installation (https://phabricator.wikimedia.org/T224677) and can confirm
> that the attached patch fixes it.
> 
> Colin, from my PoV this seems suitable for an update shipped in
> a Stretch point release. I'd be happy to take care of an upload and
> interacting with SRMs if you agree.

I'm fine with this.  Please go ahead.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#931641: perl: FTBFS under qemu-user

[Niko Tyni]

Source: perl
Version: 5.30.0-2
Severity: important
Tags: upstream
User: debian-p...@lists.debian.org
Usertags: perl-5.30-transition
X-Debbugs-Cc: John Paul Adrian Glaubitz 

As discussed in the thread at

 
https://alioth-lists.debian.net/pipermail/perl-maintainers/2019-June/006711.html

 
https://alioth-lists.debian.net/pipermail/perl-maintainers/2019-July/006713.html

Perl fails to build under qemu-user with Configure -Dmksymlinks because
$0 contains an absolute path there and the build machinery can't deal
with that.

This can be reproduced under for instance qemu-armhf with

  mkdir b && cd b && ../Configure -des -Dmksymlinks

resulting in lots of 'Permission denied' errors when extracting cflags.SH
because the script mistakes the shell absolute path for its argument and
tries to write in the same directory where the shell resides.

An even simpler reproducer is

  touch config.sh && sh < cflags.SH

This is not specific to Perl 5.30, our packaging just started to use
-Dmksymlinks there and triggered the issue.

I'm not sure yet where this should be fixed. I'd like to avoid reverting
the -Dmksymlinks part introduced in 5.30.0-2 as I think enabling parallel
builds was an improvement. But we'll see.

This should possibly be considered a Perl 5.30 transition blocker as
at least some Debian ports (m68k, sh4) use qemu-user for buildds.
Adding the usertag for now.
-- 
Niko Tyni   nt...@debian.org

Bug#931639: linux-image-4.19.0-5-amd64: Does not boot - stuck at "Loading initial ramdisk"

[Kinky Nekoboi]

This is proberly linked to this Bug, also coreboot used as firmware on
the affected system:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930029

So its possible that this only apears in the combination linux 4.19 +
coreboot.

With earlyprintk= VALUE as bootparameter you can get more output ouput
the kernel panic / hang

Am 08.07.19 um 17:44 schrieb QWERTY man:
> Package: src:linux
> Version: 4.19.37-5
> Severity: critical
> Justification: breaks the whole system
>
>
> Dear Maintainer,
>
>
>* What led up to the situation?
>
> Upgraded from a very stable and largely vanilla Debian Stretch to Debian 
> Buster.
>
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>
> Rebooted, and it entered a loop of the following messages:
>
>   Loading Linux 4.19.0-5-amd64...
>   Loading initial ramdisk
>
> INFO: task swapper/0:1 blocked for more than 120 secs
> Not tainted 4.19.0-5-amd64 #1 Debian 4.19.37-5
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secds" disables this message
>
> INFO: task cpuhp/0:14 blocked for more than 120 secs
> Not tainted 4.19.0-5-amd64 #1 Debian 4.19.37-5
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secds" disables this message
>
> I then booted the system with the 4.9.0-9-amd64 kernel, and everything worked 
> as
> before.
>
> Note that same issue occurs on another system with the same motherboard and
> processor - D945GCLF2B - but different hard drive and PSU: it hangs at boot.
>
>
>* What outcome did you expect instead?
>
> I imagined Debian stable was uber stable based on past experience.
>
>
>
> -- Package-specific info:
> ** Kernel log: boot messages should be attached
>
> ** Model information
> sys_vendor: Intel
> product_name: D945GCLF  <--  It is actually D945GCLF2B
> product_version: 1.0
> chassis_vendor: Intel
> chassis_version: 
> bios_vendor: coreboot
> bios_version: 382892c
> board_vendor: Intel
> board_name: D945GCLF<--  Above
> board_version: 1.0
>
> ** PCI devices:
> 00:00.0 Host bridge [0600]: Intel Corporation 82945G/GZ/P/PL Memory 
> Controller Hub [8086:2770] (rev 02)
>   Subsystem: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub 
> [8086:464c]
>   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
>   Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-  SERR-Latency: 0
>   Capabilities: 
>
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 82945G/GZ 
> Integrated Graphics Controller [8086:2772] (rev 02) (prog-if 00 [VGA 
> controller])
>   Subsystem: Intel Corporation 82945G/GZ Integrated Graphics Controller 
> [8086:464c]
>   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
>   Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-  SERR-Latency: 0
>   Interrupt: pin A routed to IRQ 16
>   Region 0: Memory at e020 (32-bit, non-prefetchable) [size=512K]
>   Region 1: I/O ports at 2080 [size=8]
>   Region 2: Memory at c000 (32-bit, prefetchable) [size=512M]
>   Region 3: Memory at e028 (32-bit, non-prefetchable) [size=512K]
>   [virtual] Expansion ROM at 000c [disabled] [size=128K]
>   Capabilities: 
>   Kernel driver in use: i915
>   Kernel modules: i915
>
> 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High 
> Definition Audio Controller [8086:27d8] (rev 01)
>   Subsystem: Intel Corporation NM10/ICH7 Family High Definition Audio 
> Controller [8086:464c]
>   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR+ FastB2B- DisINTx+
>   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-  SERR-Latency: 0, Cache Line Size: 64 bytes
>   Interrupt: pin A routed to IRQ 27
>   Region 0: Memory at e030 (64-bit, non-prefetchable) [size=16K]
>   Capabilities: 
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
>
> 00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express 
> Port 1 [8086:27d0] (rev 01) (prog-if 00 [Normal decode])
>   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR+ FastB2B- DisINTx+
>   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-  SERR-Latency: 0, Cache Line Size: 64 bytes
>   Interrupt: pin A routed to IRQ 24
>   Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>   I/O behind bridge: 1000-1fff
>   Memory behind bridge: e010-e01f
>   Prefetchable memory behind bridge: e000-e00f
>   Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
>   PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>   Capabilities: 
>