Bug#931302: syslog-ng: FTBFS on i386 and s390x

[Hilmar Preuße]

On 01.07.19 10:51, Gianfranco Costamagna wrote:

Hi,

> looks like syslog-ng started failing to build on at least i386 and s390x
> 
> http://debomatic-i386.debian.net/distribution#unstable/syslog-ng/3.19.1-5/buildlog
> 
> on s390x the error seems related to an ENOMEMORY during grep
> /bin/grep: memory exhausted
> 
Not sure if that helps anyhow: I'm failing to reproduce the FTBFS on
i386. No, this is not a buildd, just an unstable installation.

I must admit that the build log is quite huge, which /could/ cause a
"memory exhausted", if one tries to parse that file.

> I blame the new bison FWIW
> 
Indeed after downgrading bison to the version from testing the build log
is much smaller by factor 1000.

hille@sid:~ $ ls -ld syslog-ng*build*
-rw-r--r-- 1 hille users1146956 Jul  2 08:41
syslog-ng_3.19.1-5_i386.build
-rw-r--r-- 1 hille users 1022437607 Jul  2 08:19
syslog-ng_3.19.1-5_i386.build_1

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



signature.asc
Description: OpenPGP digital signature

Bug#931059: mesa-va-driver: Crash 19.1 when encoding movie with VAAPI.

[K.Ohta]

This is more information of BUG#931059.

With hardware acceled deinterlacer (with ffmpeg, -filter_complex 
"deinterlace_vaapi"), this issue happened.
But, without this feature, this issue not happened.
This seem to be caused with any deinterlacer (i.e. bob, motion_adaptive...).

With 19.1.1-1, this issue has reproduced, but with 19.0.3-1, not happened.
Regards,
Ohta.

On Tue, 25 Jun 2019 19:53:08 +0900
Kyuma Ohta  wrote:

> Package: mesa-va-drivers
> Version: 19.1.0-1
> Severity: important
> File: mesa-va-driver
> 
> Dear Maintainer,
> 
>  When encoding movie with VAAPI (via ffmpeg),with 19.1.0-1,
>  crash screen with below kernel log.
>  This issue happend encoding with both H264 and HEVC.
>  But, with 19.0.*, this issue has not happened.
>  I'm using RADEON RX560 with amdgpu driver(s).
> 
> Regards,
>  Ohta.
> 
> -- LOG --
(snip)
> 

Bug#931331: linux-image-4.19.0-5-amd64: system fails to start to X even with nomodeset, restarts forever without

[Robert Pommrich]

Package: linux-image-4.19.0-5-amd64
Severity: critical
Justification: breaks the whole system

Dear Maintainer,



   * What led up to the situation?
   Upgrade from jessie to stretch
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   Installing the shipped kernel
   * What was the outcome of this action?
   The system starts to boot in a loop
   * What outcome did you expect instead?
   Normal start of the system to X

I reported the issue already in bug report 914517, which got way to few 
attention, which is very disapointing.

This bug prevents me from moving completely to stretch, not to think of 
upgrading to buster.

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

Kernel: Linux 4.19.0-0.bpo.5-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#930539: [Pkg-utopia-maintainers] Bug#930539: upowerd cannot start due to searching the wrong libssl version

[Andrey Rahmatullin]

Doing anything with libimobiledevice4 packages won't touch your locally
installed bad library. You should remove it, and any other locally
installed libraries, and never do such installs again, at least while you
don't fully understand the consequences.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#931330: BUG: unable to handle kernel NULL pointer dereference at 0000000000000337

[sergio]

Package: src:linux
Version: 4.19.37-5
Severity: normal

Dear Maintainer,

This is a copy of https://bugzilla.kernel.org/show_bug.cgi?id=203681.

Steps to reproduce:

1. iptables is a symlink to iptables-nft (with iptables-legacy all works fine)

2. I'm not able to reproduce this manually, calling iptables or ferm. Only at 
boot time.

3. just a minimal debian with only ferm installed

$ cat /etc/ferm/ferm.conf
table filter {
chain BadTcp proto tcp !syn mod conntrack ctstate NEW {
mod limit limit 3/minute limit-burst 3
NFLOG nflog-group 0 nflog-prefix "NEW not SYN: ";
}
chain AllowedTcp mod conntrack ctstate (ESTABLISHED RELATED) ACCEPT;
}

that produces the following rules:

# ferm --remote /etc/ferm/ferm.conf
# Generated by ferm 2.4 on Thu May 23 04:56:59 2019
*filter
:AllowedTcp - [0:0]
:BadTcp - [0:0]
-A AllowedTcp --match conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT
-A BadTcp --protocol tcp ! --syn --match conntrack --ctstate NEW --match limit 
--limit 3/minute --limit-burst 3 --jump NFLOG --nflog-group 0 --nflog"
COMMIT

trying to run it at boot time gives:

[2.810581] BUG: unable to handle kernel NULL pointer dereference at 
0337
[2.811972] #PF error: [normal kernel read fault]
[2.812727] PGD 0 P4D 0
[2.813149] Oops:  [#1] SMP PTI
[2.813713] CPU: 0 PID: 227 Comm: iptables-restor Not tainted 
5.0.0-trunk-amd64 #1 Debian 5.0.2-1~exp1
[2.815195] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-1 04/01/2014
[2.816509] RIP: 0010:module_put+0xe/0x80
[2.817224] Code: 8e 00 48 8b 4d 00 48 85 c9 75 e4 eb 98 66 66 2e 0f 1f 84 
00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 48 85 ff 74 71 41 54 55 53 <5
[2.820387] RSP: 0018:b82d402df990 EFLAGS: 00010286
[2.821242] RAX: 9b0ffc9fa400 RBX: 0003 RCX: 0005
[2.822375] RDX: 0002 RSI: c04612d0 RDI: 
[2.823542] RBP: 9b0ffbc301b0 R08:  R09: 0074
[2.824675] R10: b82d402df8f8 R11: e7cfc0f5d508 R12: 0004
[2.825585] R13: 00ec R14: fff5 R15: 0007
[2.826456] FS:  7f06a8bfd740() GS:9b0ffea0() 
knlGS:
[2.827378] CS:  0010 DS:  ES:  CR0: 80050033
[2.828036] CR2: 0337 CR3: 36256000 CR4: 06f0
[2.828873] Call Trace:
[2.829244]  nf_tables_newrule+0x585/0x8c0 [nf_tables]
[2.829968]  nfnetlink_rcv_batch+0x4a1/0x660 [nfnetlink]
[2.830714]  ? nfnetlink_rcv_msg+0x13c/0x260 [nfnetlink]
[2.831460]  ? copyout+0x25/0x30
[2.831919]  ? _copy_to_iter+0x9d/0x3f0
[2.832482]  ? __skb_try_recv_datagram+0xcb/0x170
[2.833170]  ? refcount_inc_checked+0x5/0x30
[2.833741]  ? __nla_parse+0x34/0x120
[2.834265]  nfnetlink_rcv+0x106/0x13b [nfnetlink]
[2.834941]  netlink_unicast+0x1ba/0x250
[2.835498]  netlink_sendmsg+0x204/0x3d0
[2.836009]  sock_sendmsg+0x36/0x40
[2.836423]  ___sys_sendmsg+0x295/0x2f0
[2.836877]  ? page_add_file_rmap+0x13/0x210
[2.837372]  ? filemap_map_pages+0x1b9/0x390
[2.838011]  ? refcount_inc_checked+0x5/0x30
[2.838599]  ? apparmor_capable+0x72/0xa0
[2.839151]  ? security_capable+0x35/0x50
[2.839702]  ? release_sock+0x19/0x90
[2.840207]  __sys_sendmsg+0x57/0xa0
[2.840702]  do_syscall_64+0x53/0x100
[2.841239]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[2.841947] RIP: 0033:0x7f06a8cff914
[2.842440] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 
00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75 13 b8 2e 00 00 00 0f 05 <3
[2.845050] RSP: 002b:7ffe92365cf8 EFLAGS: 0246 ORIG_RAX: 
002e
[2.845890] RAX: ffda RBX: 7ffe92365d10 RCX: 7f06a8cff914
[2.846814] RDX:  RSI: 7ffe92366d90 RDI: 0003
[2.847647] RBP: 7ffe92367410 R08: 0004 R09: 7f06a8b99410
[2.848478] R10: 7ffe92366d7c R11: 0246 R12: 5652c9eee8f0
[2.849402] R13: 7ffe92369ce0 R14: 7ffe92365d00 R15: 7ffe92369d18
[2.850403] Modules linked in: nft_limit nft_counter xt_NFLOG xt_limit 
xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32y
[2.856394] CR2: 0337
[2.856835] ---[ end trace 0bda5f9a9cded6f1 ]---
[2.857542] RIP: 0010:module_put+0xe/0x80
[2.858140] Code: 8e 00 48 8b 4d 00 48 85 c9 75 e4 eb 98 66 66 2e 0f 1f 84 
00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 48 85 ff 74 71 41 54 55 53 <5
[2.860755] RSP: 0018:b82d402df990 EFLAGS: 00010286
[2.861508] RAX: 9b0ffc9fa400 RBX: 0003 RCX: 0005
[2.862548] RDX: 0002 RSI: c04612d0 RDI: 
[2.863559] RBP: 9b0ffbc301b0 R08:  R09: 0074
[2.864563] R10: b82d402df8f8 R11: e7cfc0f5d508 

Bug#911623: not RC in my opinion

[Nicholas D Steeves]

Hi Adam,

Sorry for the belated reply, I didn't receive this email for some
reason until I bts show --mbox to update it a notice I filed a MR.

On Sat, Jun 08, 2019 at 03:57:13PM +0200, Adam Borowski wrote:
> Control: severity -1 important
> 
> > Severity: serious
> > Justification: Debian Policy violation
> 
> > /bin/mkfs.btrfs and /bin/fsck.btrfs are Policy and FHS violations.
> 
> I don't believe this is in any way RC -- for Buster nor likely any future
> release.  There's no functional lossage, AFAIK.
>

Yeah, it's in the class of legalistic RCs.  Standards aren't standards
if nobody follows them...  Of course we have the freedom to do
whatever we want though ;-)

> fsck probably should indeed be moved away from /bin -- it's a legacy
> atavistic thing that's not of much use to users.  Filesystems of old
> suffered corruption on every unexpected power loss and thus required automated
> fsck.  That's not the case during current millenium.  Among mainstream
> filesystems, only ext4 still ships real fsck (mostly for historic reasons),
> I think jfs has it trigger log replay; the rest (btrfs, xfs, f2fs, ...) ship
> just a stub that does nothing.  There are actual repair tools but those
> shouldn't generally be run other than as a hail mary effort; regular checks
> are supposed to use online scrub instead, without downtime.
>

Have you seen Qu Wenruo's view on this yet?  tldr; btrfs check
--readonly after unclean shutdown, to catch early warning signs.

  https://www.spinics.net/lists/linux-btrfs/msg90485.html

Yeah, I agree, that's not supposed to be necessary with a next-gen fs
:-( But Qu recommends it...  It's easy to enable this on an opt-in
basis with something like a /forcefsck that is created when the fs is
mounted and removed during shutdown, but I imagine autodetecting and
deduplicating the list of mount points is problematic in cases where
there are many "-o subvol=foo" mounts and where subvolid=5 isn't
mounted. eg: default to nil, don't do anything, and if users want
this upstream-recommended behaviour then they can configure a list of
mounts to check.

> Moving that stub has been requested in #798072.
>

Thanks for fixing it!

> mkfs on the other hand is widely used by non-root users these days.  On raw
> metal, you generally mkfs once per hardware replacement, while VMs or board
> images get created often.
> 
> Thus, I'd rather ask for Policy change than to alter the package.
>

Btrfs-progs is the only package that has this issue...  Why is it a
valid special snowflake?  <- A question the Policy team will ask.

> This means, I don't consider the bug to be serious.
> 

I agree that it's "policy serious" and not "practical serious".

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#928604: New version of soscleaner : 0.4.4

[Eric Desrochers]

Upstream just released the new version (0.4.4):
https://github.com/jduncan-rva/soscleaner/releases

Please disregard version "0.4.3" in favour of "0.4.4" version from now on.

I will package soscleaner, test, ... and once ready I'll ask for DD
sponsorship as stated in previous updates.

- Eric

Bug#931307: linux-image-4.9.0-9-amd64: Problems with Samba Shares?

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 2019-07-01 at 14:13 +0200, Werner Detter wrote:
> Package: src:linux
> Version: 4.9.168-1+deb9u3
> Severity: important
> 
> Dear Maintainer,
> 
> after upgrading to the latest linux-image-adm64 on stretch we're experiencing 
> strange issues on a 
> fileserver with samba: directory listings in subfolder of shares don't work 
> after upgrading to 
> 4.9.168-1+deb9u3 on the clients. I've rebooted the machine to 
> linux-image-4.9.0-8-amd64 - with that 
> version everything is working. 
> 
> So I'm wondering if there are other users which experience similar problems 
> with the latest 
> kernel and samba? 

There is a known regression that will be fixed soon, affecting programs
that use small socket buffers.

I think it was once recommended to set the SO_SNDBUF parameter in
smb.conf, which can trigger this bug.  This parameter is now
deprecated, and if it is present in your configuration file it should
be safe to remove it.

Please let us know if that change fixes the issue.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.



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

Bug#928604: New release of soscleaner soon !

[Eric Desrochers]

Quick update:

In a couple of days, upstream should make a new release available,
including some fixes of mine.

I will wait until it is released and then will ask Robie Basak (DD) to
review as we both agreed in previous irc conversation.

Will update the bug with the new soscleaner release number once released.

- Eric

Bug#930795: unblock: ruby-airbrussh/1.3.2-1

[Samuel Henrique]

Control: tags -1 - moreinfo

Hello Paul,

Control: tags -1 moreinfo
>

I removed the moreinfo tag as I assume now you will have enough information
to make a judgement call on this one, feel free to tell me if I should not
have done so.


> > I'm asking for the unblock of ruby-airbrussh
> > because a critical bug was solved in the last upload.
> >
> > The bug is related to the package throwing an exception when dealing
> > with non UTF-8 characters coming from SSH.
>
> Can you elaborate a bit why the severity? (Would have been nice to have
> that description in the bug you didn't file). Looking at the upstream
> bug, it may just be confusing to the user and ugly of course as rsync
> was said to keep on running. Is rsync in Debian broken in the same way?
>

So, the main problem here is that when using capistrano (a deployment
tool), the user will think that the deployment failed because
ruby-airbrussh will have problems with non UTF-8 characters coming from
SSH`ed rsync.
I do not have reasons to think that rsync is broken in the same way, as the
main problem here is misguiding the user into thinking that there is
something wrong with the deployment.
Capistrano is used for production critical pipelines at some companies.

In summary, the deployment will probably occur normally, but the only
guarantee of that would be the user having to manually debug the error and
checking whether it succeeded or not under the hood.


> > I decided to upload the latest release instead of patching the previous
> > release
>
> Which still means review work by us. We do have quite some unblocks
> coming in this last freeze moment.
>

I can see you have lots of work to do, so if you feel like this should not
be fixed for the first Buster release, I will try to address this with
stable-updates, if you think that's acceptable.

With my maintainer's hat on I say that it's important to fix this before
releasing Buster, and the changes are very trivial, but I do acknowledge
that the best person to make the call here is someone from the release
team, so whatever you say I'm fine with it.


-- 
Samuel Henrique 

Bug#930539: [Pkg-utopia-maintainers] Bug#930539: upowerd cannot start due to searching the wrong libssl version

[Andreas von Heydwolff]

On 01.07.19 19:48, Michael Biebl wrote:
> Am 01.07.2019 um 19:35 schrieb Andreas v. Heydwolff:
>> (0x7f0eecfc2000)
>> libimobiledevice.so.6 => /usr/local/lib/libimobiledevice.so.6
> 
> It's as Andrey suspected a locally installed library.
> 

Just for testing purposes I rolled back upower and libidevice to the
respective Jessie versions

upower:amd64 0.99.1-3.2 install ok installed
libimobiledevice4:amd64 1.1.6+dfsg-3.1 install ok installed
libimobiledevice6:amd64 not installed

Now the SDDM login box, KDE control panel and file save dialogs were no
longer lagging for half a minute or more, and KDE's dolphin started as
fast as always. However, upowerd would not start although ldd found all
related libs. Perhaps this is due to some by now obsolete incompatibility.

Then I upgraded upower to the standard Stretch version (no backport)
with upower pulling in libidevice6 as it's only dependency. The
situation was then:

upower:amd64/stable 0.99.4-4+b1 uptodate
libimobiledevice4:amd64 1.1.6+dfsg-3.1 install ok installed
libimobiledevice4:amd64 1.1.6+dfsg-3.1 installed: No available version
in archive
libimobiledevice6:amd64 1.2.0+dfsg-3.1 install ok installed
libimobiledevice6:i386 not installed
libimobiledevice6 (1.2.0+dfsg-3.1 Debian:9.9/stable [amd64])

Now ldd for upowerd shows again

libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found

and upowerd is not starting as described in the initial bug report.
Stand-by and waking up of SDDM up to the login box KDE start and save
dialogs were fast as usual at this time.

Upgrading libimobiledevice6 to the latest

libimobiledevice6:amd64 (1.2.1~git20181030.92c5462-1)

slowed down the login box of SDDM, KDE start process and the save
dialogs again. Reverting libimobiledevice6 from testing/sid to stable
did not help, neither did a restart. Deinstalling upower and leaving
libimobiledevice6 in place with dpkg -r --force-all upower was
sufficient resolved the lags.

I guess the next step is to file a bug report against libimobiledevice6
testing/stable, would the upower maintainers agree?

Regards

Bug#931328: RFA: inosync -- notification-based directory synchronization daemon

[Carsten Leonhardt]

Package: wnpp
Severity: normal

I request an adopter for the inosync package. It is written in
Python 2 and the original upstream maintainer hasn't been active in
more than four years. If nobody picks this package up, it will
probably be removed when Python 2 will be removed.

The package description is:
 The inosync daemon uses the inotify service available in recent Linux
 kernels to monitor and synchronize changes within directories to
 remote nodes using rsync.
 .
 System administrators have relied on cron+rsync for years to
 constantly synchronize files and directories to remote machines. It
 is not feasible to let authors wait for their content to get
 synchronized every x hours with regard to the enormous pace of
 articles and podcasts nowadays.

Bug#931317: debian-installer: A feature to "secure erase" SSDs would be nice

[Ben Hutchings]

On Mon, 2019-07-01 at 22:09 +0200, Philip Hands wrote:
> "Karl O. Pinc"  writes:
> 
> > Package: debian-installer
> > Severity: wishlist
> > Tags: d-i
> > 
> > Hello,
> > 
> > It would be nice if the debian installer included the option to
> > "secure erase" SSDs before creating a partition table during
> > installation.
> > 
> > A used SSD may have been "over-filled", especially a consumer grade
> > device that is not over-provisioned.  By this I mean that it has had
> > enough cells written that writing requires erasure, which results in
> > write-amplification and poor performance.  A "secure erase" operation
> > restores the original performance of the drive.
> > 
> > I have not put any thought into whether this feature is feasible.
> 
> I think it's probably rather hard to do safely, as IIRC one often needs
> to try hdparm, then in order to cause the drive not to be locked do
> something like suspend and resume the system, then set an admin
> password, and only then do the secure erase ... which then takes
> quite a while.

I believe that modern drives (both HD and SSD) often have their own
encryption layer, and secure erase is implemented by erasing the
encryption key and (on an SSD) marking all blocks free in the flash
translation layer.

But of course we cannot assume that all drives work that way.

> Doing that inside d-i reliably seems likely to be quite a challenge, and
> then if someone gets bored and turns off the power, their first and last
> experience of Debian might well be us converting their SSD into a brick.
> 
> A suggestion for them to think about doing it before installation, in
> the installation manual, might be better.

That would certainly be a lot easier for us.

Ben.

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


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

Bug#851774: Bug#928931: more info

[Raphaël Halimi]

Le 02/07/2019 à 00:06, Cyril Brulebois a écrit :
>> (There was also a merge request based on this patch [2] which didn't
>> receive any answer)
> 
> Merge request, MR.
> 
> So you're pointing out exactly what I was referring to.

Hum. I'm disappointed in myself.

>> Please enlighten me (I'm not being ironic here, this is a legitimate
>> question, I really don't understand how releasing Buster with a partly
>> broken apt-setup is preferable to merging a patch which is admittedly
>> not tested by a lot of people, but is so simple that it's very
>> unlikely to fail, especially when 60local nearly **always** fail
>> without a fix).
> 
> Because it makes no sense to be making changes until the very last
> minute. Especially for a highly specific use case where one would expect
> advanced users to be able to find the relevant bug report(s).

Well, I wasn't able to, when I first submitted the duplicate bug report
(#929911). Keep in mind that the error in the installer syslog is very
cryptic:

"apt-setup: warning: /usr/lib/apt-setup/generators/60local returned
error code 255; discarding output"

It's really not obvious that it's caused by the absence of gnupg, I
didn't get it until you closed the duplicate and pointed me to #928931.

Note that, before filling the bug report, I briefly searched through the
current d-i bugs; I don't remember the patterns I used, but I didn't
find this one (although I admit I find it weird that I didn't search for
"local" or "apt-setup"; that being said, looking at the time of my
e-mail, I was probably a bit tired after a long night of work).

> If you personally don't mind, you may want to just trust us to make the
> right call. Hypothetical users that haven't been testing release
> candidates and haven't noticed the issue can surely 1) find bug reports
> when they run into this issue; 2) apply a workaround; 3) or wait until
> 10.1 is released.

Right. My apologies.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#851774: Bug#928931: more info

[Cyril Brulebois]

Hi,

Raphaël Halimi  (2019-07-01):
> Le 29/06/2019 à 16:20, Cyril Brulebois a écrit :
> > Plus, we've got a MR against apt-setup now, see #851774. It's also
> > come late and nobody reviewed it yet. Plus, the other, serious bug
> > report was marked as buster-ignore by a release team member, so
> > there's no *need* to fix this before buster.
> 
> What exactly does "MR" mean ? I googled but I didn't find anything.
> 
> > All in all, it looks like we're instead going to consider the MR at the
> > beginning of the bullseye release cycle, and backport the fix to buster
> > if it proves to be working fine.
> 
> That's where I disagree. More precisely, I don't understand how the
> current situation (which is that generators/60local crashes
> systematically, unless in the very rare case that an unsigned
> repository is configured, **and**
> debian-installer/allow_unauthenticated is set) can be preferable to
> merging the patch in [1] before release.
> 
> (There was also a merge request based on this patch [2] which didn't
> receive any answer)

Merge request, MR.

So you're pointing out exactly what I was referring to.

> Please enlighten me (I'm not being ironic here, this is a legitimate
> question, I really don't understand how releasing Buster with a partly
> broken apt-setup is preferable to merging a patch which is admittedly
> not tested by a lot of people, but is so simple that it's very
> unlikely to fail, especially when 60local nearly **always** fail
> without a fix).

Because it makes no sense to be making changes until the very last
minute. Especially for a highly specific use case where one would expect
advanced users to be able to find the relevant bug report(s).

> Personally, I don't mind, since my PXE server has a complex preseed
> system with preseed file snippets, scripts and hooks everywhere, so
> adding a hook to replace 60local for Buster was very easy; but I'm
> thinking of people who use a single preseed file, they will have a
> really bad surprise when Buster is released.

If you personally don't mind, you may want to just trust us to make the
right call. Hypothetical users that haven't been testing release
candidates and haven't noticed the issue can surely 1) find bug reports
when they run into this issue; 2) apply a workaround; 3) or wait until
10.1 is released.

> If you don't change your mind, please at least agree that this bug
> (and its possible workarounds) must absolutely be documented with big
> fat warnings in the preseed documentation [3].

An errata item might be in order; but then, we tend to put out .1 rather
quickly so that might mean more work for translators for little benefits
anyway.

> I have to say that I **really** miss the times when a new Debian
> release was ready "when it's ready"... :(

I'll refrain from adding my own “I have to say” here.


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


signature.asc
Description: PGP signature

Bug#931327: ntpsec security update 1.1.5

[Christoph]

Package: ntpsec

A new upstream version is available:
https://blog.ntpsec.org/2019/06/30/version-1.1.5.html

Bug#931225: Please make Classic style the default

[Guillem Jover]

Hi!

On Fri, 2019-06-28 at 15:50:19 +0100, Ian Jackson wrote:
> Package: wiki.debian.org
> Control: block 864925 by -1
> Control: block 931224 by -1

> The default style has two bugs, at least one of which is IMO fairly
> serious and has gone unfixed for 2 years now:
>   | #864925 wiki.debian.org: gridlines in tables
> 
> The Classic style does not have these bugs.  I have been using it as
> my personal style for some time and I have not noticed any
> misrendering.

Ah! This has been bothering me for so long, and I was not aware it was
due to the Debian specific theming. Thanks! Although I tried the
Classic theme and it was too ugly for my taste, the Modern one looked
slightly better though, which is what I've switched to for now. :)

> In the interests of correctness and readability of tables, at least,
> could the default style be changed (at least until the newer style is
> fixed) ?

This feels a bit too drastic, but I fully understand the sentiment.

I assume a MR for the CSS as proposed in the referenced bug might help
move this, but I notice the theming is not included in the git repo at
, and there's a MR
about that already too, which would need to be solved first
. :)

Thanks,
Guillem

Bug#931324: Fixed http url

[Михаил Миловидов]

Package: wnpp
Severity: wishlist

* Package name: daggy
  Version : 1.1.2
  Upstream Authors: Mikhail Milovidov 
* URL : https://daggy.dev
* License : Expat
  Description : Daggy - Data Aggregation Utilty - is an IT automation tool.
It can run terminal commands on local or remote serveres
and aggregate their output locally.

Daggy main goals are simplicity and ease-of-use.
If you know about yaml/json, bash/powershell
and ssh you know how to use Daggy.

Daggy can be helpful for developers, QA, DevOps and
engenieers for debug, analyze and control
distributed network systems, for example,
based on microservice architecture.

Daggy is serverless, cross-platform solution and
don't require installation on remote servers.
Commands execution work under SSH transport protocol or
via local terminal.

-- System Information:
Debian Release: testing/unstable
Architecture: any

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

[Dmitry Bogatov]

[2019-06-22 19:53] Lorenz 
> As for other observations you made, i will have a look and send new patches
> soon

In mean time I managed to create qemu image with
`autopkgtest-qemu-build`. On my machine test fails with error about
removing "init". Any ideas how to fix it (apart to manually tweaking
image)?

autopkgtest [19:57:58]: version 5.10
autopkgtest [19:57:58]: host neophite.local; command line: /usr/bin/autopkgtest 
../runit-init_2.1.2-32_all.deb ../runit_2.1.2-32_amd64.deb 
../getty-run_2.1.2-32_all.deb . -- qemu ../autopkgtest.img
qemu-system-x86_64: warning: host doesn't support requested feature: 
CPUID.01H:ECX.vmx [bit 5]
autopkgtest [19:58:16]: testbed dpkg architecture: amd64
autopkgtest [19:58:19]: testbed running kernel: Linux 4.19.0-5-amd64 #1 SMP 
Debian 4.19.37-5 (2019-06-19)
autopkgtest [19:58:19]:  built-tree .
autopkgtest [19:58:19]: testing package runit version 2.1.2-32
autopkgtest [19:58:19]: test init-switch: preparing testbed
Get:1 file:/tmp/autopkgtest.kRENL9/binaries  InRelease
Ign:1 file:/tmp/autopkgtest.kRENL9/binaries  InRelease
Get:2 file:/tmp/autopkgtest.kRENL9/binaries  Release [816 B]
Get:2 file:/tmp/autopkgtest.kRENL9/binaries  Release [816 B]
Get:3 file:/tmp/autopkgtest.kRENL9/binaries  Release.gpg
Ign:3 file:/tmp/autopkgtest.kRENL9/binaries  Release.gpg
Get:4 file:/tmp/autopkgtest.kRENL9/binaries  Packages [3921 B]
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Correcting dependencies...Starting pkgProblemResolver with broken count: 2
Starting 2 pkgProblemResolver with broken count: 2
Investigating (0) init:amd64 < 1.57 @ii mK Ib >
Broken init:amd64 PreDepends on systemd-sysv:amd64 < 241-5 @ii mR >
  Considering systemd-sysv:amd64 3 as a solution to init:amd64 5103
  Added systemd-sysv:amd64 to the remove list
Broken init:amd64 PreDepends on sysvinit-core:amd64 < none | 2.93-8 @un uH >
  Considering sysvinit-core:amd64 0 as a solution to init:amd64 5103
  Try Installing sysvinit-core:amd64 < none | 2.93-8 @un uH > before changing 
init:amd64
  Fixing init:amd64 via keep of systemd-sysv:amd64
Investigating (0) systemd-sysv:amd64 < 241-5 @ii mK Ib >
Broken systemd-sysv:amd64 Conflicts on sysvinit-core:amd64 < none -> 2.93-8 @un 
uN Ib >
  Considering sysvinit-core:amd64 0 as a solution to systemd-sysv:amd64 3
  Added sysvinit-core:amd64 to the remove list
  Fixing systemd-sysv:amd64 via keep of sysvinit-core:amd64
Investigating (0) runit-init:amd64 < none -> 2.1.2-32 @un uN Ib >
Broken runit-init:amd64 Conflicts on systemd-sysv:amd64 < 241-5 @ii mK >
  Considering systemd-sysv:amd64 3 as a solution to runit-init:amd64 2
  Holding Back runit-init:amd64 rather than change systemd-sysv:amd64
Investigating (0) autopkgtest-satdep:amd64 < 0 @iU mK Nb Ib >
Broken autopkgtest-satdep:amd64 Depends on runit-init:amd64 < none | 2.1.2-32 
@un uH >
  Considering runit-init:amd64 2 as a solution to autopkgtest-satdep:amd64 -2
  Removing autopkgtest-satdep:amd64 rather than change runit-init:amd64
Done
 Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following additional packages will be installed:
  psmisc
The following packages will be REMOVED:
  autopkgtest-satdep
The following NEW packages will be installed:
  psmisc
0 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 126 kB of archives.
After this operation, 652 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian unstable/main amd64 psmisc amd64 23.2-1 [126 
kB]
Fetched 126 kB in 0s (0 B/s)
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 18668 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
Selecting previously unselected package psmisc.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 18668 files and directories currently installed.)
Preparing to unpack .../ps

Bug#930856: autopkgtest-build-qemu: captures something from host

[Dmitry Bogatov]

control: close -1

[2019-06-30 10:13] Bastian Blank 
>
> part   text/plain 687
> On Sat, Jun 29, 2019 at 04:44:32PM +0200, Bastian Blank wrote:
> > On Sat, Jun 29, 2019 at 02:25:55PM +, Dmitry Bogatov wrote:
> > > Note that APT tries to use Devuan keyring to validate Debian release and
> > > fail. How does `debootstrap' decides, which keyring to use?
> > "dpkg -s debootstrap"?  How did that keyring get on the system in the
> > first place?
>
> Devuan includes a patched version of debootstrap.  See
> https://pkginfo.devuan.org/stage/ascii/ascii/debootstrap_1.0.89+devuan2.1.html

That was the cause. My mistake, I forgot to check version of
debootstrap.

Sorry for noise.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#931326: gnome-maps: Segfault when looking for a location

[darthcat]

Package: gnome-maps
Version: 3.22.2-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

when trying to look for a location, gnome-maps makes a segfault error. In the 
past the focus on the map moved to the location entered in the location box but 
this doesn't work anymore.

Thanks for your help.

Best regards

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

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

Versions of packages gnome-maps depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  geoclue-2.0  2.4.5-1
ii  gir1.2-champlain-0.120.12.15-1
ii  gir1.2-clutter-1.0   1.26.0+dfsg-3
ii  gir1.2-cogl-1.0  1.22.2-2
ii  gir1.2-gdkpixbuf-2.0 2.36.5-2+deb9u2
ii  gir1.2-geoclue-2.0   2.4.5-1
ii  gir1.2-geocodeglib-1.0   3.20.1-2
ii  gir1.2-gfbgraph-0.2  0.2.3-1+b2
ii  gir1.2-glib-2.0  1.50.0-1+b1
ii  gir1.2-goa-1.0   3.22.5-1
ii  gir1.2-gtk-3.0   3.22.11-1
ii  gir1.2-gtkchamplain-0.12 0.12.15-1
ii  gir1.2-gtkclutter-1.01.8.2-2
ii  gir1.2-gweather-3.0  3.20.4-1
ii  gir1.2-rest-0.7  0.8.0-2
ii  gir1.2-secret-1  0.18.5-3.1
ii  gir1.2-soup-2.4  2.56.0-2+deb9u2
ii  gir1.2-webkit2-4.0   2.18.6-1~deb9u1
ii  gjs  1.46.0-1+b2
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u4
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libchamplain-0.12-0  0.12.15-1
ii  libclutter-1.0-0 1.26.0+dfsg-3
ii  libcogl-pango20  1.22.2-2
ii  libcogl-path20   1.22.2-2
ii  libcogl201.22.2-2
ii  libdrm2  2.4.74-1
ii  libegl1-mesa [libegl1-x11]   13.0.6-1+b2
ii  libfolks25   0.11.3-2
ii  libgbm1  13.0.6-1+b2
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libgee-0.8-2 0.18.1-1
ii  libgeocode-glib0 3.20.1-2
ii  libglib2.0-0 2.50.3-2
ii  libglib2.0-bin   2.50.3-2
ii  libgtk-3-0   3.22.11-1
ii  libjson-glib-1.0-0   1.2.6-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  librest-0.7-00.8.0-2
ii  libsoup2.4-1 2.56.0-2+deb9u2
ii  libwayland-client0   1.12.0-1+deb9u1
ii  libwayland-cursor0   1.12.0-1+deb9u1
ii  libwayland-egl1-mesa [libwayland-egl1]   13.0.6-1+b2
ii  libwayland-server0   1.12.0-1+deb9u1
ii  libx11-6 2:1.6.4-3+deb9u1
ii  libxcomposite1   1:0.4.4-2
ii  libxdamage1  1:1.1.4-2+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxkbcommon00.7.1-2~deb9u1
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2
ii  libxrandr2   2:1.5.1-1

gnome-maps recommends no packages.

gnome-maps suggests no packages.

-- no debconf information

Bug#910455: bitcoin FTBFS on 32bit: test failure

[Laurence Parry]

This bug was reported upstream here:
https://github.com/bitcoin/bitcoin/issues/14580

It appears to be a GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348

The fix merged for the upcoming 0.19.0, 0.18.1 and 0.17.2 was to
compile with -fno-stack-reuse:
https://github.com/bitcoin/bitcoin/pull/15983

The patch for 0.18 is:
https://github.com/bitcoin/bitcoin/pull/16035/commits/5935f0126ef37175a8fbfee017b470af13aad46d
from https://github.com/bitcoin/bitcoin/pull/16035

Maybe it would be better to go to 0.18.1? But I imagine that would not
count as a targeted fix at this stage of the release cycle.

-- 
Laurence "GreenReaper" Parry
httsp://www.greenreaper.co.uk/

Bug#851774: Bug#928931: more info

[Raphaël Halimi]

Le 01/07/2019 à 22:46, Moritz Mühlenhoff a écrit :
> This is already broken in Stretch, so you're overly dramatic...

Wrong :) I may be overly dramatic, but Stretch didn't have this problem.

The reason is simple: gnupg was "Priority: important" on Stretch, so it
was installed with the base system, alongside apt (during the initial
debootstrap), so apt-key didn't fail to add a key to its trusted keyring.

With Buster, gunpg was demoted to "Priority: optional", **and** demoted
to a Suggests in apt dependencies (whereas it used to be a Recommends),
so, unless gnupg is installed manually before the apt-setup phase,
apt-key can't add a key to its trusted keyring.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#931316: python-django: CVE-2019-12308: Incorrect HTTP detection with reverse-proxy connecting via HTTPS

[Chris Lamb]

[Adding t...@security.debian.org, to CC]

Hi Salvatore,

> Control: found -1 2:2.2.1-1
> Control: found -1 1:1.10.7-2+deb9u4
> Control: found -1 1:1.10.7-1

I've uploaded fixes to experimental, unstable and to jessie LTS. 

Security team (added to CC), would you like an upload for stable?


Best wishes,

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

Bug#851774: Bug#928931: more info

[Moritz Mühlenhoff]

On Mon, Jul 01, 2019 at 08:40:22PM +0200, Raphaël Halimi wrote:
> Hi Cyril,
> 
> Le 29/06/2019 à 16:20, Cyril Brulebois a écrit :
> >> If installing gnupg is what it takes to fix the bug, IMHO it should be
> >> done; anyway, with this patch, it would be installed only if a local
> >> repository with a GnuPG key is used at all.

@kibi: Fixing this for the 10.1 point release sounds good, I can easily
reproduce this against apt.wikimedia.org, so happy to test a build when
the MR is merged.

> > Well, I proposed doing so a while ago but that didn't happen. Looking at
> > the current gnupg package, it's not about installing just a single,
> > extra package:
> > 
> > Depends: dirmngr (<< 2.2.13-2.1~), dirmngr (>= 2.2.13-2), gnupg-l10n (= 
> > 2.2.13-2), gnupg-utils (<< 2.2.13-2.1~), gnupg-utils (>= 2.2.13-2), gpg (<< 
> > 2.2.13-2.1~), gpg (>= 2.2.13-2), gpg-agent (<< 2.2.13-2.1~), gpg-agent (>= 
> > 2.2.13-2), gpg-wks-client (<< 2.2.13-2.1~), gpg-wks-client (>= 2.2.13-2), 
> > gpg-wks-server (<< 2.2.13-2.1~), gpg-wks-server (>= 2.2.13-2), gpgsm (<< 
> > 2.2.13-2.1~), gpgsm (>= 2.2.13-2), gpgv (<< 2.2.13-2.1~), gpgv (>= 2.2.13-2)
> 
> I agree with you on the fact that the dependencies are quite heavy. I
> noticed that, but I didn't realize that the GnuPG keys could just be
> dropped in /etc/apt/trusted.gpg.d/ (more on that later). Good point.

There's a simple workaround you can use in your preseed config (which we've
also applied for the Wikimedia servers):
https://github.com/wikimedia/puppet/commit/d783a56d7ef7a1bc44a5b4b0323565c24e7ae6a1

> If you don't change your mind, please at least agree that this bug (and
> its possible workarounds) must absolutely be documented with big fat
> warnings in the preseed documentation [3].
> 
> I have to say that I **really** miss the times when a new Debian release
> was ready "when it's ready"... :(

This is already broken in Stretch, so you're overly dramatic...

Cheers,
Moritz

Bug#931325: manpages-dev: io_cancel can fail with EINTR

[Marc Lehmann]

Package: manpages-dev
Version: 4.16-2
Severity: minor

Dear Maintainer,

I found that, at least with debians 4.19 kernel, io_cancel can fail with
EINTR on signal delivery, which should be documented as per similar calls.

Thanks!

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

Kernel: Linux 5.1.15-050115-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages manpages-dev depends on:
ii  manpages  4.16-2

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  konqueror [man-browser]  4:18.12.0-1
ii  man-db [man-browser] 2.8.5-2

-- no debconf information

Bug#931324: ITP: daggy - data aggregation utility, application that can run multiple commands on remote servers simultaneously and save output locally.

[Михаил Миловидов]

Package: wnpp
Severity: wishlist

* Package name: daggy
  Version : 1.1.2
  Upstream Authors: Mikhail Milovidov 
* URL : h ttps://daggy.dev
* License : Expat
  Description : Daggy - Data Aggregation Utilty - is an IT automation tool.
It can run terminal commands on local or remote serveres
and aggregate their output locally.

Daggy main goals are simplicity and ease-of-use.
If you know about yaml/json, bash/powershell
and ssh you know how to use Daggy.

Daggy can be helpful for developers, QA, DevOps and
engenieers for debug, analyze and control
distributed network systems, for example,
based on microservice architecture.

Daggy is serverless, cross-platform solution and
don't require installation on remote servers.
Commands execution work under SSH transport protocol or
via local terminal.

-- System Information:
Debian Release: testing/unstable
Architecture: any

Bug#931317: debian-installer: A feature to "secure erase" SSDs would be nice

[Philip Hands]

"Karl O. Pinc"  writes:

> Package: debian-installer
> Severity: wishlist
> Tags: d-i
>
> Hello,
>
> It would be nice if the debian installer included the option to
> "secure erase" SSDs before creating a partition table during
> installation.
>
> A used SSD may have been "over-filled", especially a consumer grade
> device that is not over-provisioned.  By this I mean that it has had
> enough cells written that writing requires erasure, which results in
> write-amplification and poor performance.  A "secure erase" operation
> restores the original performance of the drive.
>
> I have not put any thought into whether this feature is feasible.

I think it's probably rather hard to do safely, as IIRC one often needs
to try hdparm, then in order to cause the drive not to be locked do
something like suspend and resume the system, then set an admin
password, and only then do the secure erase ... which then takes
quite a while.

Doing that inside d-i reliably seems likely to be quite a challenge, and
then if someone gets bored and turns off the power, their first and last
experience of Debian might well be us converting their SSD into a brick.

A suggestion for them to think about doing it before installation, in
the installation manual, might be better.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#883346: release.debian.org: improve reportbug templates for pu and unblock bugs

[Paul Gevers]

Hi,

On Sat, 2 Dec 2017 19:14:01 +0100 Julien Cristau 
wrote:
> I brought this up in Cambridge, filing here so we can discuss specifics.
> 
> At Mozilla we're using a template in bugzilla [1] for requests to
> cherry-pick changes from trunk to a release branch, to help release
> management assess reward/risk from specific changes, and I thought
> something like that might be useful in Debian too.

I think this is a great idea.

> [Feature/Bug causing the regression]:
> [User impact if declined]:
> [Is this code covered by automated tests?]
> [Has the fix been verified in Nightly?]
> [Needs manual test from QE? If yes, steps to reproduce]:
> [List of other uplifts needed for the feature/fix]:
> [Is the change risky?]:
> [Why is the change risky/not risky?]:
> [String changes made/needed]:
> 
> I think most of it would also be useful here, framed something like:
> - when was the bug introduced, is it a regression
> - user impact of the bug
> - what automated or manual tests cover the affected code
> - has the change been verified in sid
> - some discussion of the risks involved, if only so the
>   maintainer/submitter asks themselves that question
> - l10n impact

- what does it mean if we don't have this in 
- key package / leaf package
- please explain *all* the changes (i.e. a new upstream release is very
often *not* a targeted fix)
- are *all* the changes documented in the changelog (checklist item)
- did you review all the changes personally and what is your judgment?

> It can't be too long or it will be a pain for people to write and for us
> to read, so maybe we should trim that down a bit, but if we can reduce
> the back and forth by having more relevant information in those bug
> reports I think that might be useful.

Yes. The example below from Ubuntu may be too long.

> Ubuntu may have something in their SRU bug process too?

https://wiki.ubuntu.com/StableReleaseUpdates says:
"""
3.1. SRU Bug Template

[Impact]

 * An explanation of the effects of the bug on users and

 * justification for backporting the fix to the stable release.

 * In addition, it is helpful, but not required, to include an
   explanation of how the upload fixes this bug.

[Test Case]

 * detailed instructions how to reproduce the bug

 * these should allow someone who is not familiar with the affected
   package to reproduce the bug and verify that the updated package fixes
   the problem.

[Regression Potential]

 * discussion of how regressions are most likely to manifest as a result
of this change.

 * It is assumed that any SRU candidate patch is well-tested before
   upload and has a low overall risk of regression, but it's important
   to make the effort to think about what ''could'' happen in the
   event of a regression.

 * This both shows the SRU team that the risks have been considered,
   and provides guidance to testers in regression-testing the SRU.

[Other Info]

 * Anything else you think is useful to include
 * Anticipate questions from users, SRU, +1 maintenance, security teams
and the Technical Board
 * and address these questions in advance
"""

Paul



signature.asc
Description: OpenPGP digital signature

Bug#931323: libmatio: CVE-2019-13107

[Salvatore Bonaccorso]

Source: libmatio
Version: 1.5.13-3
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for libmatio.

CVE-2019-13107[0]:
| Multiple integer overflows exist in MATIO before 1.5.16, related to
| mat.c, mat4.c, mat5.c, mat73.c, and matvar_struct.c


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-13107
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13107

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#931322: fdisk: command not found

[Roger]

Package: fdisk
Version: 2.33.1-0.1
Severity: important
Tags: a11y

Dear Maintainer,

   * What led up to the situation? Use of command in terminal
   * What exactly did you do (or not do) that was effective (or ineffective)?
Tried to use it.
   * What was the outcome of this action?  Would not run.
   * What outcome did you expect instead?  Should have given output.



-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing')
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 fdisk depends on:
ii  libc6  2.28-10
ii  libfdisk1  2.33.1-0.1
ii  libmount1  2.33.1-0.1
ii  libncursesw6   6.1+20181013-2
ii  libsmartcols1  2.33.1-0.1
ii  libtinfo6  6.1+20181013-2

fdisk recommends no packages.

fdisk suggests no packages.

-- no debconf information

Bug#931321: libxslt: CVE-2019-13117

[Salvatore Bonaccorso]

Source: libxslt
Version: 1.1.32-2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for libxslt.

CVE-2019-13117[0]:
| In numbers.c in libxslt 1.1.33, an xsl:number with certain format
| strings could lead to a uninitialized read in
| xsltNumberFormatInsertNumbers. This could allow an attacker to discern
| whether a byte on the stack contains the characters A, a, I, i, or 0,
| or any other character.

The oss-fuzz report and testcases are not public at this moment, but
still filling the bug according to source code view and patch to be
applied. I have no futher details unfortunately.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-13117
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13117
[1] 
https://gitlab.gnome.org/GNOME/libxslt/commit/c5eb6cf3aba0af048596106ed839b4ae17ecbcb1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#931320: libxslt: CVE-2019-13118

[Salvatore Bonaccorso]

Source: libxslt
Version: 1.1.32-2
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for libxslt.

CVE-2019-13118[0]:
| In numbers.c in libxslt 1.1.33, a type holding grouping characters of
| an xsl:number instruction was too narrow and an invalid
| character/length combination could be passed to
| xsltNumberFormatDecimal, leading to a read of uninitialized stack
| data.

The oss-fuzz report and testcases are not public at this moment, but
still filling the bug according to source code view and patch to be
applied. I have no futher details unfortunately.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-13118
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13118
[1] 
https://gitlab.gnome.org/GNOME/libxslt/commit/6ce8de69330783977dd14f6569419489875fb71b

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#867667: xsane: Preview window empty/unusable

[Sanne Grabisch]

Package: xsane
Version: 0.999-6+b1
Followup-For: Bug #867667

I can confirm the bug still exists in debian buster.
(the workaround deleting .sane/xsane works too.)



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xsane depends on:
ii  libc62.28-10
ii  libgimp2.0   2.10.8-2
ii  libglib2.0-0 2.58.3-2
ii  libgtk2.0-0  2.24.32-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  libpng16-16  1.6.36-6
ii  libsane  1.0.27-3.2
ii  libtiff5 4.0.10-4
ii  sensible-utils   0.0.12
ii  xsane-common 0.999-6
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages xsane recommends:
ii  cups-client2.2.10-6
ii  firefox-esr [www-browser]  60.7.2esr-1

Versions of packages xsane suggests:
ii  gimp  2.10.8-2
pn  gocr | cuneiform | tesseract-ocr | ocrad  
pn  gv
pn  hylafax-client | mgetty-fax   

-- no debconf information

Bug#931319: dwz: dwz.c:8562: adjust_exprloc: Assertion `refd != NULL && !refd->die_remove'

[Matthias Klose]

Package: src:dwz
Version: 0.12-3
Severity: important
Tags: upstream

This is seen when running dwz on an LTO optimized cc1plus, built from the GCC 8
branch.  The dwz call seems to work with binaries built from the gcc-9 branch.

$ dwz cc1plus
dwz: dwz.c:8562: adjust_exprloc: Assertion `refd != NULL && !refd->die_remove'
failed.
Aborted (core dumped)

binary at
https://people.debian.org/~doko/tmp/cc1plus-x86_64.xz

Bug#929834: Buster/XFCE unlock screen is blank

[Michael Umland]

I do not think this particular bug is dependent on any one driver (Intel or
otherwise) as previous posters have suggested. I have also experienced this
bug on a fresh installation using a Radeon 580 and the open-source amdgpu
driver.

I was able to work around the problem temporarily by changing the greeter
or using the CTRL+ALT+F7 key combination when I wanted to unlock the
screen. Unfortunately, this problem annoyed me enough that I have since
moved away from XFCE, so I am not able to perform any additional tests or
provide more detailed information. I just wanted to chime in and provide
what information I could about the bug.

Bug#931318: debian-installer: A feature to manually reserve space and so "over-provision" SSDs would be nice

[Karl O. Pinc]

Package: debian-installer
Severity: wishlist
Tags: d-i

Hello,

Because many consumer grade SSDs are not over-provisioned by the
manufacturer it might be nice to have an option, in the automatic
partitioning, that reserves a percentage (or a choice of percentages)
of a SSD and leaves the space un-partitioned.

Reserving unused space on an SSD that is never written to helps
prevent write-amplification and so preserves drive performance.
The need for this is dependent upon how much/whether the manufacturer
has over-provisioned the SSD.

See: https://en.wikipedia.org/wiki/Write_amplification

If this is implemented it would also probably be prudent to
suggest to those creating LVM physical volumes that they
may wish to use a partition instead of a raw physical volume
so that space can be reserved for manual SSD over-provisioning.

Regards,
Karl

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

Kernel: Linux 4.9.0-9-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)

Bug#931317: debian-installer: A feature to "secure erase" SSDs would be nice

[Karl O. Pinc]

Package: debian-installer
Severity: wishlist
Tags: d-i

Hello,

It would be nice if the debian installer included the option to
"secure erase" SSDs before creating a partition table during
installation.

A used SSD may have been "over-filled", especially a consumer grade
device that is not over-provisioned.  By this I mean that it has had
enough cells written that writing requires erasure, which results in
write-amplification and poor performance.  A "secure erase" operation
restores the original performance of the drive.

I have not put any thought into whether this feature is feasible.

Regards,
Karl

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

Kernel: Linux 4.9.0-9-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)

Bug#931316: python-django: CVE-2019-12308: Incorrect HTTP detection with reverse-proxy connecting via HTTPS

[Salvatore Bonaccorso]

Control: retitle -1 python-django: CVE-2019-12781: Incorrect HTTP detection 
with reverse-proxy connecting via HTTPS

On Mon, Jul 01, 2019 at 08:36:06PM +0200, Salvatore Bonaccorso wrote:
> Source: python-django
> Version: 1:1.11.21-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> Control: found -1 2:2.2.1-1
> Control: found -1 1:1.10.7-2+deb9u4
> Control: found -1 1:1.10.7-1

This is correct.

> CVE-2019-12308[0]:
> | An issue was discovered in Django 1.11 before 1.11.21, 2.1 before
> | 2.1.9, and 2.2 before 2.2.2. The clickable Current URL value displayed
> | by the AdminURLFieldWidget displays the provided value without
> | validating it as a safe URL. Thus, an unvalidated value stored in the
> | database, or a value provided as a URL query parameter payload, could
> | result in an clickable JavaScript link.

This was plain wrong for this bugreport, apologies for that. This bug
is meant to track the following CVE:

CVE-2019-12781[0]
| Incorrect HTTP detection with reverse-proxy connecting via HTTPS

as per [1].

 [0] https://security-tracker.debian.org/tracker/CVE-2019-12781
 [1] https://www.djangoproject.com/weblog/2019/jul/01/security-releases/

Please do ignore the above CVE description which belongs to another
issue already fixed for python-django.

Regards,
Salvatore

Bug#851774: Bug#928931: more info

[Raphaël Halimi]

Hi Cyril,

Le 29/06/2019 à 16:20, Cyril Brulebois a écrit :
>> If installing gnupg is what it takes to fix the bug, IMHO it should be
>> done; anyway, with this patch, it would be installed only if a local
>> repository with a GnuPG key is used at all.
> 
> Well, I proposed doing so a while ago but that didn't happen. Looking at
> the current gnupg package, it's not about installing just a single,
> extra package:
> 
> Depends: dirmngr (<< 2.2.13-2.1~), dirmngr (>= 2.2.13-2), gnupg-l10n (= 
> 2.2.13-2), gnupg-utils (<< 2.2.13-2.1~), gnupg-utils (>= 2.2.13-2), gpg (<< 
> 2.2.13-2.1~), gpg (>= 2.2.13-2), gpg-agent (<< 2.2.13-2.1~), gpg-agent (>= 
> 2.2.13-2), gpg-wks-client (<< 2.2.13-2.1~), gpg-wks-client (>= 2.2.13-2), 
> gpg-wks-server (<< 2.2.13-2.1~), gpg-wks-server (>= 2.2.13-2), gpgsm (<< 
> 2.2.13-2.1~), gpgsm (>= 2.2.13-2), gpgv (<< 2.2.13-2.1~), gpgv (>= 2.2.13-2)

I agree with you on the fact that the dependencies are quite heavy. I
noticed that, but I didn't realize that the GnuPG keys could just be
dropped in /etc/apt/trusted.gpg.d/ (more on that later). Good point.

> I'm also not sure what part of dirmngr and/or gpg-agent are going to
> stay around running, after calling “apt-key add” with gnupg installed.

I didn't even know that could be a problem. Again, good point.

> Testing that was conceivable a couple of weeks/months back; a few days
> before an archive freeze, not so much.

Well, the patch in [1] (which is far better than mine, by the way) dates
from April 9th, 2018, so it was not for a lack of trying... :)

> Plus, we've got a MR against apt-setup now, see #851774. It's also come
> late and nobody reviewed it yet. Plus, the other, serious bug report was
> marked as buster-ignore by a release team member, so there's no *need*
> to fix this before buster.

What exactly does "MR" mean ? I googled but I didn't find anything.

> All in all, it looks like we're instead going to consider the MR at the
> beginning of the bullseye release cycle, and backport the fix to buster
> if it proves to be working fine.

That's where I disagree. More precisely, I don't understand how the
current situation (which is that generators/60local crashes
systematically, unless in the very rare case that an unsigned repository
is configured, **and** debian-installer/allow_unauthenticated is set)
can be preferable to merging the patch in [1] before release.

(There was also a merge request based on this patch [2] which didn't
receive any answer)

Please enlighten me (I'm not being ironic here, this is a legitimate
question, I really don't understand how releasing Buster with a partly
broken apt-setup is preferable to merging a patch which is admittedly
not tested by a lot of people, but is so simple that it's very unlikely
to fail, especially when 60local nearly **always** fail without a fix).

Personally, I don't mind, since my PXE server has a complex preseed
system with preseed file snippets, scripts and hooks everywhere, so
adding a hook to replace 60local for Buster was very easy; but I'm
thinking of people who use a single preseed file, they will have a
really bad surprise when Buster is released.

If you don't change your mind, please at least agree that this bug (and
its possible workarounds) must absolutely be documented with big fat
warnings in the preseed documentation [3].

I have to say that I **really** miss the times when a new Debian release
was ready "when it's ready"... :(

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851774#61
[2] https://salsa.debian.org/installer-team/apt-setup/merge_requests/1
[3] https://www.debian.org/releases/stable/amd64/apb.html.en

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#931214: ImportError: No module named oslo.config

[Paul Gevers]

Hi,

On 01-07-2019 15:05, Thomas Goirand wrote:
> Looking further, it looks like python-os-collect-config is a *very* old
> package in Debian (ie: no update since 2014), and it's not adapted
> anymore to the version of python-oslo.config that is in Debian. ie:
> oslo.config has moved away from a namespace based system to a
> non-namespace, so it should now be "import oslo_config" and not "import
> oslo.config".
> 
> So, as a result, there's no way python-os-collect-config will work in
> Buster unless we update it to a much newer version, like for example
> version 9.2.1. Of course, it's already too late in the release process
> to do this, so we may just remove os-collect-config from Buster to fix
> the current situation.

I have hinted the package for removal. It will not be part of buster.
Thanks for the investigation.

> I'm sorry the OpenStack team failed to maintain this leaf package,

Happens. Wouldn't it be great if this package had an autopkgtest that
would have detected this... (Yeh, I know).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#931316: python-django: CVE-2019-12308: Incorrect HTTP detection with reverse-proxy connecting via HTTPS

[Salvatore Bonaccorso]

Source: python-django
Version: 1:1.11.21-1
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1 2:2.2.1-1
Control: found -1 1:1.10.7-2+deb9u4
Control: found -1 1:1.10.7-1

Hi,

The following vulnerability was published for python-django.

CVE-2019-12308[0]:
| An issue was discovered in Django 1.11 before 1.11.21, 2.1 before
| 2.1.9, and 2.2 before 2.2.2. The clickable Current URL value displayed
| by the AdminURLFieldWidget displays the provided value without
| validating it as a safe URL. Thus, an unvalidated value stored in the
| database, or a value provided as a URL query parameter payload, could
| result in an clickable JavaScript link.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-12308
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12308
[1] https://www.djangoproject.com/weblog/2019/jul/01/security-releases/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#923118: OpenJDK 12 symlink to sources doesn't point on src.zip

[Patrice Duroux]

Hi,
It is still there, isn't it?

In 
https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/commit/?id=803f5d7cab5dfe3afb6358e25cdc366d4eedaa49
why having the 2 following:

+ echo '$(TOP)/$(basename)/src.zip $(basedir)/lib/src.zip' >>
$(d_jdkhl).links
+ echo '$(TOP)/$(basename)/lib/src.zip $(basedir)/lib/src.zip' >>
$(d_jdkhl).links

as there can be only source relative for $(basedir)/lib/src.zip, no?
And the second should be the right one to me regarding my system.

Thanks,
Patrice

Bug#922526: Bug#931251: www.debian.org: /misc/laptops/ and /misc/related_links removed from repo but still served

[Laura Arjona Reina]

Hello Rafa
Thanks for reporting this.
The pages were still served because we have an issue in the website
tooling, that when we remove a page, the corresponding html files in the
www-master.debian.org server are not removed. This is being tracked in
#922526

For now, I have removed manually the files that shouldn't be there in
the /misc section. I guess the fix will be online in the next hours.

I will try to remove the ones that are present in other folders in the
following days/weeks, and I expect to work on the bug #922526 during
this summer if nobody beats me to it.

Closing this bug, please report any other related issue that you find to
the bug #922526

Thanks!

El 29/6/19 a las 15:05, Rafa escribió:
> Package: www.debian.org
> Severity: normal
> 
> Dear Maintainers,
> 
> I could be misinterpreting something but, taking into account that in
> commit 00ee01a963076d499ecc72b4197a38bf69001e36 misc/laptops/ and
> misc/related_links were removed from the repository (as one of bug
> #924888-related tasks), I expected that, as of today, pages
> https://www.debian.org/misc/laptops/index.html and
> https://www.debian.org/misc/related_links.html would return a 404 error
> code. However, those pages are still being served.
> 
> Is that correct?
> 
> Thanks.
> 
> Regards,
> 
> Rafa.
> 

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#928300: secure boot via removable media path unavailable

[Chris Nospam]

Dear Steve,

> It's odd that you have files in /boot/efi but on a separate filesystem
> (the rootfs?), not within the ESP.

yep, on the rootfs on /dev/sda2. Must have been done by the deb-installer. Now 
I removed the files from the root partition as ESP is mounted over them. As 
expected, no change.

>> The exact error message during booting with SB on is:
>> Image Autorization Fail.
> *Exactly* that, including the missing "h" in Authorization ? Or is
> that a typo on your part?

Defintively, I made the typo, since no cut&paste on the boot screen...

> So, I'm curious what keys your system claims to recognise then. The
> mokutil tool can dump the public keys in each of the key lists on your
> system, as listed in the man page:

# mokutil --pk
[key 1]
SHA1 Fingerprint: 77:a8:28:ba:0c:72:b4:49:79:5c:c0:5a:47:10:cf:a7:29:1c:0f:79
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
c3:1d:39:ca:ef:3d:8b:dd
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=Intel(R) Desktop Boards
Validity
Not Before: Feb  2 00:09:49 2013 GMT
Not After : Jan 31 00:09:49 2023 GMT
Subject: CN=Intel(R) Desktop Boards
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:e0:32:77:4d:a5:f3:31:41:5f:9f:36:39:d1:93:
ce:b2:16:f8:45:7f:4e:65:c1:42:2c:65:d5:96:5e:
99:22:5d:8a:16:2d:89:52:e3:e6:15:23:c7:7d:b8:
1e:55:84:7b:ca:2a:27:5d:ee:a4:33:6a:52:ff:39:
a9:d4:81:21:8f:c2:f5:b8:f8:3c:85:43:60:61:68:
23:72:f1:82:b1:6d:68:ad:69:0b:fb:d1:5a:ed:d2:
cd:c1:c4:81:d3:d2:ba:6f:ce:6f:ad:58:25:6f:39:
32:c5:06:ff:57:80:52:d6:8b:63:90:ec:a7:4b:cf:
2a:b0:2e:f7:13:2e:fc:a7:5b:6c:79:86:0d:d2:b3:
04:13:75:18:6d:8b:7a:35:b8:9c:71:00:1c:19:72:
a4:8c:24:d4:0d:d5:e9:ca:d0:3b:a0:36:c6:55:4b:
58:b3:f3:7d:58:2d:7b:92:f0:38:e3:3f:06:8d:aa:
79:32:2e:6e:50:dc:8c:1d:e1:f7:db:0f:4b:af:61:
bc:bd:d2:ba:d6:5f:ec:8f:79:3e:b8:c8:37:dc:a9:
5a:4d:80:ec:5b:ce:eb:6c:54:68:74:2a:5c:aa:bc:
25:d2:69:e1:c1:51:5b:35:c5:fb:cf:a6:58:a9:6c:
f8:73:33:c6:f5:a8:d2:0a:ef:eb:e2:1f:ec:f3:aa:
84:0b
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
D2:EE:76:04:80:00:C1:E6:56:D2:FE:D7:EF:8B:5A:D8:0C:3C:B1:39
X509v3 Authority Key Identifier:

keyid:D2:EE:76:04:80:00:C1:E6:56:D2:FE:D7:EF:8B:5A:D8:0C:3C:B1:39

X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
 38:e7:c3:21:94:97:9a:0c:96:5b:2d:0e:8a:77:1d:91:da:95:
 7f:c6:d2:bc:84:cc:9d:ec:84:7c:8c:09:36:27:2c:08:d2:90:
 8a:32:39:3e:4e:46:d9:42:ec:2d:90:94:38:34:24:e6:10:d9:
 2e:a5:f2:ce:b2:8e:c0:51:7f:1e:b0:79:17:8b:40:1e:2c:d5:
 8d:cb:70:89:ea:f9:2e:63:b1:23:80:c9:41:49:de:d0:5f:5a:
 bf:86:30:33:c4:57:c6:4e:2f:1a:b3:e9:63:5d:69:90:0d:b9:
 00:f6:b4:3e:89:d7:97:0f:d3:ee:2c:6e:ca:a8:cb:ba:d8:4a:
 38:46:de:01:6f:e1:8d:2e:6d:fe:ed:e2:55:f8:1a:6f:c7:7a:
 b8:7d:db:db:34:7f:3e:9e:9e:37:f7:3b:81:0e:52:ef:45:ac:
 d4:0b:ce:8c:f8:3d:36:ff:2f:9b:f4:e5:bc:9f:5f:d7:6b:8d:
 8b:fd:63:d4:b1:69:43:cb:ae:04:07:a1:1a:e8:ed:69:09:3a:
 09:3d:d2:b0:e8:b2:b7:6f:25:2c:9c:3e:24:a5:8a:5e:b6:0d:
 c5:1a:10:90:3f:8b:83:33:7d:d3:37:42:80:cb:6e:23:f8:09:
 dd:57:16:59:df:e3:8b:b4:fa:f7:82:42:90:d8:b1:71:c6:fe:
 16:79:1b:87

# mokutil --kek
[key 1]
SHA1 Fingerprint: 31:59:0b:fd:89:c9:d7:4e:d0:87:df:ac:66:33:4b:39:31:25:4b:30
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
61:0a:d1:88:00:00:00:00:00:03
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, 
CN=Microsoft Corporation Third Party Marketplace Root
Validity
Not Before: Jun 24 20:41:29 2011 GMT
Not After : Jun 24 20:51:29 2026 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, 
CN=Microsoft Corporation KEK CA 2011
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:c4:e8:b5:8a:bf:ad:57:26:b0:26:c3:ea:e7:fb:
57:7a:44:02:5d:07:0d:da:4a:e5:74:2a:e6:b0:0f:
ec:6d:eb:ec:7f:b9:e3:5a:63:32:7c:11:17:4f:0e:
e3:0b:a7:38:15:93:8e:c6:f5:e0:84:b1:9a:9b:2c:
e7:f5:b7:91:d6:09:e1:e2:c0:04:a8:ac:30:1c:df:
48:f3:06:50:9a:64:a7:51:7f:c8:85

Bug#930539: [Pkg-utopia-maintainers] Bug#930539: upowerd cannot start due to searching the wrong libssl version

[Michael Biebl]

Am 01.07.2019 um 19:35 schrieb Andreas v. Heydwolff:
> (0x7f0eecfc2000)
> libimobiledevice.so.6 => /usr/local/lib/libimobiledevice.so.6

It's as Andrey suspected a locally installed library.

-- 
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#931315: valgrind: helgrind+drd false positives, part 2

[Adam Borowski]

Package: valgrind
Version: 1:3.14.0-3
Severity: normal
Tags: patch

Hi!
The patch I submitted for #918023 was incomplete.  Or rather, it was
complete for amd64 only.

Thus, please add the following:


diff --git a/debian/supp/debian.supp b/debian/supp/debian.supp
index 0252ccc..2fe6de7 100644
--- a/debian/supp/debian.supp
+++ b/debian/supp/debian.supp
@@ -51,3 +51,19 @@
fun:_IO_new_file_xsputn
fun:_IO_file_xsputn@@GLIBC_2.2.5
 }
+
+{
+   helgrind false positive with glibc 2.28 bug#918023
+   Helgrind:Race
+   fun:mempcpy
+   fun:_IO_new_file_xsputn
+   fun:_IO_file_xsputn@@GLIBC_2.17
+}
+
+{
+   drd false positive with glibc 2.28 bug#918023
+   drd:ConflictingAccess
+   fun:mempcpy
+   fun:_IO_new_file_xsputn
+   fun:_IO_file_xsputn@@GLIBC_2.17
+}


I'm not sure if some other arch has a yet another symbol version.


Meow!
-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.2.0-rc7-17151-g2bf15134b691 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages valgrind depends on:
ii  libc6  2.28-10
ii  libc6-dbg  2.28-10

Versions of packages valgrind recommends:
ii  gdb   8.2.1-2
ii  valgrind-dbg  1:3.14.0-3.0kb2

Versions of packages valgrind suggests:
pn  alleyoop  
pn  kcachegrind   
pn  valgrind-mpi  
pn  valkyrie  

-- no debconf information

Bug#930539: upowerd cannot start due to searching the wrong libssl version

[Andreas v. Heydwolff]

Thanks, Andrey
On 01.07.19 16:02, Andrey Rahmatullin wrote:
> On Fri, Jun 14, 2019 at 10:16:50PM +0200, A. Heydwolff wrote:
>> Jun 14 21:10:58 karfiol upowerd[15367]: /usr/lib/upower/upowerd: error while 
>> loading shared libraries: libssl.so.1.0.0: cannot open shared object file: 
>> No such file or directory
> Note that /usr/lib/upower/upowerd isn't linked to libssl directly, and, at
> least in sid, not even indirectly. This means there is some problem with
> one of the libraries it loads and, I suspect, it's a library installed
> locally.
> You can start debugging this with ldd (or just looking into /usr/local).

Thanks, Andrey!

Using ldd I see again what systemd showed me:

 libssl.so.1.0.0 => *not found*
 libcrypto.so.1.0.0 => *not found*

Would one of the other libs that can be found in the output try to load
them:

# ldd /usr/lib/upower/upowerd
linux-vdso.so.1 (0x7ffd4d3f3000)
libupower-glib.so.3 =>
/usr/lib/x86_64-linux-gnu/libupower-glib.so.3 (0x7f0eedce2000)
libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
(0x7f0eed94c000)
libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0
(0x7f0eed733000)
libgudev-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgudev-1.0.so.0
(0x7f0eed529000)
libgobject-2.0.so.0 =>
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x7f0eed2d6000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x7f0eecfc2000)
libimobiledevice.so.6 => /usr/local/lib/libimobiledevice.so.6
(0x7f0eecd9c000)
libplist.so.3 => /usr/lib/x86_64-linux-gnu/libplist.so.3
(0x7f0eecb8d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f0eecb6c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f0eec9af000)
libgmodule-2.0.so.0 =>
/usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x7f0eec7ab000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f0eec591000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
(0x7f0eec367000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
(0x7f0eec34e000)
libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1
(0x7f0eec10)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1
(0x7f0eebedb000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6
(0x7f0eebcd2000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3
(0x7f0eeba5f000)
libssl.so.1.0.0 => *not found*
libcrypto.so.1.0.0 => *not found*
libusbmuxd.so.4 => /usr/lib/x86_64-linux-gnu/libusbmuxd.so.4
(0x7f0eeb855000)
/lib64/ld-linux-x86-64.so.2 (0x7f0eedd76000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0eeb85)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1
(0x7f0eeb60a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f0eeb5fe000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1
(0x7f0eeb5f5000)

- or is my libc6 too old to work together with the latest upowerd (on
Stretch with stretch-backports).

# file /usr/lib/upower/upowerd
/usr/lib/upower/upowerd: ELF 64-bit LSB shared object, x86-64, version 1
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=a1b060672d26001064a495a1dab0fbfb002ce8ef,
stripped

# ls -l /lib64/ld-linux-x86-64.so.2
[...] /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.27.so

# dpkg -l libc6
+++--=-=-==
ii  libc6:amd64  2.27-6amd64


> 
>> Installed are 
>> -rw-r--r-- 1 root root 349K Oct  7  2017 libssl3.so
>> -rw-r--r-- 1 root root 422K Feb 27 21:58 libssl.so.1.0.2
>> -rw-r--r-- 1 root root 576K Apr 16 21:31 libssl.so.1.1
>>
>> I created a 1.0.0 symlink to 1.0.2
> Never do this.

Of course not ... but I deleted it immediately after having used it for
the very clumsy attempt at diagnostics. ldd would have been the better
choice in first place ...

Regards

Bug#931126: unblock: enigmail/2:2.0.11+ds1-2

[Daniel Kahn Gillmor]

On Sun 2019-06-30 20:01:21 +0200, Paul Gevers wrote:
> The time for unblocks for buster has come and gone. The deadline was
> last Tuesday, we are now in deep freeze and we were not able to process
> your unblock request and give it an exception. I assume this should be
> fixed via the security archive, please confirm that (and I'll fix this
> bugs metadata). Otherwise I propose you prepare a stable release update
> targeting buster, such that this can be fixed in the first point release.

I'm fine with this going through either security or the first buster
point release.  So yes, Paul, if you can update this issue to be treated
as a security issue, that would be great.

thank you for your work on the release.

  --dkg


signature.asc
Description: PGP signature

Bug#928300: secure boot via removable media path unavailable

[Steve McIntyre]

Hi Chris,

On Mon, Jul 01, 2019 at 06:36:40PM +0200, Chris Nospam wrote:
>
>I try to deliver missing informations.
>
>> Can you get in to the system? I'm guessing (hoping!) just by disabling
>> SB for now.
>
>Fortunately, that is possible.

Phew. :-)

>> Then please do a listing of the EFi System Partition and
>> show us what boot variables are set:
>
>> # ls -lR /boot/efi
>/boot/efi:
>insgesamt 4
>drwx-- 4 root root 4096 Mär  7  2016 EFI
>
>/boot/efi/EFI:
>insgesamt 8
>drwx-- 2 root root 4096 Jul  1 18:04 BOOT
>drwx-- 2 root root 4096 Jul  1 18:04 debian
>
>/boot/efi/EFI/BOOT:
>insgesamt 3968
>-rwx-- 1 root root 1322936 Jul  1 18:04 BOOTX64.EFI
>-rwx-- 1 root root 1206824 Jul  1 18:04 fbx64.efi
>-rwx-- 1 root root 1529200 Jul  1 18:04 grubx64.efi
>
>/boot/efi/EFI/debian:
>insgesamt 5208
>-rwx-- 1 root root 108 Jul  1 18:04 BOOTX64.CSV
>-rwx-- 1 root root 1206824 Jul  1 18:04 fbx64.efi
>-rwx-- 1 root root 126 Jul  1 18:04 grub.cfg
>-rwx-- 1 root root 1529200 Jul  1 18:04 grubx64.efi
>-rwx-- 1 root root 1261192 Jul  1 18:04 mmx64.efi
>-rwx-- 1 root root 1322936 Jul  1 18:04 shimx64.efi

OK, that's very similar to my own system. (I've got
fwupdate-amd64-signed installed too, so a couple of extra files).

>> # efibootmgr -v
>BootCurrent: 
>Timeout: 1 seconds
>BootOrder: ,0008,0009,000A
>Boot* debian
>HD(1,GPT,ce8d01bc-8e1e-4bab-bd3f-10a56a1346cd,0x800,0x10)/File(\EFI\debian\shimx64.efi)
>Boot0008* UEFI : LAN : IP4 Intel(R) 82579V Gigabit Network Connection   
>PciRoot(0x0)/Pci(0x19,0x0)/MAC(4c72b926a1c7,0)/IPv4(0.0.0.00.0.0.0,0,0)AMBO
>Boot0009* UEFI : LAN : IP6 Intel(R) 82579V Gigabit Network Connection   
>PciRoot(0x0)/Pci(0x19,0x0)/MAC(4c72b926a1c7,0)/IPv6([::]:<->[::]:,0,0)AMBO
>Boot000A* UEFI : SATA : PORT 6G 0 : SAMSUNG SSD 830 Series : PART 0 : OS 
>Bootloader 
>PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/HD(1,GPT,ce8d01bc-8e1e-4bab-bd3f-10a56a1346cd,0x800,0x10)AMBO

OK, they all look sane enough.

># umount /boot/efi (if that should be of interest)
># ls -lR /boot/efi
>/boot/efi:
>insgesamt 4
>drwxr-xr-x 4 root root 4096 Mär  7  2016 EFI
>
>/boot/efi/EFI:
>insgesamt 8
>drwxr-xr-x 2 root root 4096 Feb 23  2018 BOOT
>drwxr-xr-x 2 root root 4096 Feb 23  2018 debian
>
>/boot/efi/EFI/BOOT:
>insgesamt 128
>-rwx-- 1 root root 131072 Jun 29 06:15 BOOTX64.EFI
>
>/boot/efi/EFI/debian:
>insgesamt 128
>-rwx-- 1 root root 131072 Jun 29 06:15 grubx64.efi

It's odd that you have files in /boot/efi but on a separate filesystem
(the rootfs?), not within the ESP. But they shouldn't be seen by the
UEFI firmware, so meh.

>The exact error message during booting with SB on is:
>Image Autorization Fail.

*Exactly* that, including the missing "h" in Authorization ? Or is
that a typo on your part?

>System cannot boot to this device due to Security Violation.
>Press Enter key to continue.
>
>
>Booting the live image like
>https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-xfce.iso
>with SB on is also not possible (actually I teststed last week's build). Win 
>10 by installer DVD is (and long time ago an installed system on (another) HDD 
>was) no problem with SB on.

OK, that's odd too. Exactly that image is booting fine in SB mode for
me on other systems. I've just tried it now to be sure!

>Note, I have not a dual boot system or something like that, solely Buster is 
>on my system.

ACK.

># gdisk -l /dev/sda
>GPT fdisk (gdisk) version 1.0.3
>
>Partition table scan:
>  MBR: protective
>  BSD: not present
>  APM: not present
>  GPT: present
>
>Found valid GPT with protective MBR; using GPT.
>Disk /dev/sda: 1000215216 sectors, 476.9 GiB
>Model: SAMSUNG SSD 830
>Sector size (logical/physical): 512/512 bytes
>Disk identifier (GUID): 1F83AB09-033C-4FA1-80CB-8DD29163E919
>Partition table holds up to 128 entries
>Main partition table begins at sector 2 and ends at sector 33
>First usable sector is 34, last usable sector is 1000215182
>Partitions will be aligned on 2048-sector boundaries
>Total free space is 2669 sectors (1.3 MiB)
>
>Number  Start (sector)End (sector)  Size   Code  Name
>   12048 1050623   512.0 MiB   EF00
>   2 1050624   933314559   444.5 GiB   8300
>   3   933314560  1000214527   31.9 GiB8200
># sgdisk --info=1 /dev/sda
>Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
>Partition unique GUID: CE8D01BC-8E1E-4BAB-BD3F-10A56A1346CD
>First sector: 2048 (at 1024.0 KiB)
>Last sector: 1050623 (at 513.0 MiB)
>Partition size: 1048576 sectors (512.0 MiB)
>Attribute flags: 
>Partition name: ''

So, I'm curious what keys your system claims to recognise then. The
mokutil tool can dump the public keys in each of the key lists on your
system, as listed in the man page:

...
  --pk  List the keys in PK
  --kek List the keys in KEK
  -

Bug#931211: s2s connections are broken after upgrading to buster

[Philipp Huebner]

I just upgraded my own ejabberd server from Stretch to Buster and
everything's fine.

I'll put your config on my test machine and see if it causes any
problems there, in the meantime you could provide the crash.log from
your server.

Best wishes
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#928300: secure boot via removable media path unavailable

[Chris Nospam]

Dear Steve,

I try to deliver missing informations.


> Can you get in to the system? I'm guessing (hoping!) just by disabling
> SB for now.

Fortunately, that is possible.


> Then please do a listing of the EFi System Partition and
> show us what boot variables are set:

> # ls -lR /boot/efi
/boot/efi:
insgesamt 4
drwx-- 4 root root 4096 Mär  7  2016 EFI

/boot/efi/EFI:
insgesamt 8
drwx-- 2 root root 4096 Jul  1 18:04 BOOT
drwx-- 2 root root 4096 Jul  1 18:04 debian

/boot/efi/EFI/BOOT:
insgesamt 3968
-rwx-- 1 root root 1322936 Jul  1 18:04 BOOTX64.EFI
-rwx-- 1 root root 1206824 Jul  1 18:04 fbx64.efi
-rwx-- 1 root root 1529200 Jul  1 18:04 grubx64.efi

/boot/efi/EFI/debian:
insgesamt 5208
-rwx-- 1 root root 108 Jul  1 18:04 BOOTX64.CSV
-rwx-- 1 root root 1206824 Jul  1 18:04 fbx64.efi
-rwx-- 1 root root 126 Jul  1 18:04 grub.cfg
-rwx-- 1 root root 1529200 Jul  1 18:04 grubx64.efi
-rwx-- 1 root root 1261192 Jul  1 18:04 mmx64.efi
-rwx-- 1 root root 1322936 Jul  1 18:04 shimx64.efi

> # efibootmgr -v
BootCurrent: 
Timeout: 1 seconds
BootOrder: ,0008,0009,000A
Boot* debian
HD(1,GPT,ce8d01bc-8e1e-4bab-bd3f-10a56a1346cd,0x800,0x10)/File(\EFI\debian\shimx64.efi)
Boot0008* UEFI : LAN : IP4 Intel(R) 82579V Gigabit Network Connection   
PciRoot(0x0)/Pci(0x19,0x0)/MAC(4c72b926a1c7,0)/IPv4(0.0.0.00.0.0.0,0,0)AMBO
Boot0009* UEFI : LAN : IP6 Intel(R) 82579V Gigabit Network Connection   
PciRoot(0x0)/Pci(0x19,0x0)/MAC(4c72b926a1c7,0)/IPv6([::]:<->[::]:,0,0)AMBO
Boot000A* UEFI : SATA : PORT 6G 0 : SAMSUNG SSD 830 Series : PART 0 : OS 
Bootloader 
PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/HD(1,GPT,ce8d01bc-8e1e-4bab-bd3f-10a56a1346cd,0x800,0x10)AMBO


# umount /boot/efi  (if that should be of interest)
# ls -lR /boot/efi
/boot/efi:
insgesamt 4
drwxr-xr-x 4 root root 4096 Mär  7  2016 EFI

/boot/efi/EFI:
insgesamt 8
drwxr-xr-x 2 root root 4096 Feb 23  2018 BOOT
drwxr-xr-x 2 root root 4096 Feb 23  2018 debian

/boot/efi/EFI/BOOT:
insgesamt 128
-rwx-- 1 root root 131072 Jun 29 06:15 BOOTX64.EFI

/boot/efi/EFI/debian:
insgesamt 128
-rwx-- 1 root root 131072 Jun 29 06:15 grubx64.efi


The exact error message during booting with SB on is:
Image Autorization Fail.
System cannot boot to this device due to Security Violation.
Press Enter key to continue.


Booting the live image like
https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-xfce.iso
with SB on is also not possible (actually I teststed last week's build). Win 10 
by installer DVD is (and long time ago an installed system on (another) HDD 
was) no problem with SB on.
Note, I have not a dual boot system or something like that, solely Buster is on 
my system.


# gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1000215216 sectors, 476.9 GiB
Model: SAMSUNG SSD 830
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 1F83AB09-033C-4FA1-80CB-8DD29163E919
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)

Number  Start (sector)End (sector)  Size   Code  Name
   12048 1050623   512.0 MiB   EF00
   2 1050624   933314559   444.5 GiB   8300
   3   933314560  1000214527   31.9 GiB8200
# sgdisk --info=1 /dev/sda
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
Partition unique GUID: CE8D01BC-8E1E-4BAB-BD3F-10A56A1346CD
First sector: 2048 (at 1024.0 KiB)
Last sector: 1050623 (at 513.0 MiB)
Partition size: 1048576 sectors (512.0 MiB)
Attribute flags: 
Partition name: ''


Thank you again for your interest and commitment!

Chris

Bug#774970: Reviewed for ubuntu

[Bryce Harrington]

We're reviewing the change for inclusion in Ubuntu; we've found more
affected users.  First we wanted to check if Debian has had a chance to
look at merging this, or if there are any issues to consider?

Bug#931214: ImportError: No module named oslo.config

[Jö Fahlke]

Am Mo,  1. Jul 2019, 15:05:30 +0200 schrieb Thomas Goirand:
> Jo, could you explain what your use case is for os-collect-config in
> Debian? I really don't get how it can be useful for you.

I'm trying to set up a Debian VM inside a OpenStack cluster using heat
orchestration.  As far as I understand it, you're supposed to do only the bare
minimum configuration using cloud-init, and do the bulk via something like
puppet, or in my case, ansible.  In that setup os-collect-config is needed to
run as a system service inside the VM to watch for configuration changes
published by heat, download the new configuration, and pass it (via some
indirection) to ansible.

I basically tried to follow this, stripping it down to only support ansible,
and adapting it to Debian:
https://developer.rackspace.com/docs/user-guides/orchestration/bootstrapping-software-config/
Since Debian has a package for os-collect-config, I tried using that rather
than using it from pip[1].

This should actually be useful outside of TripleO, unless I have completely
misunderstood something.


As a side note, the indirection mentioned above seems to be one or more of
os-apply-config (package python-os-apply-config; in stretch, buster and sid)
and os-refresh-config (package python-os-refresh-config; only in buster and
sid).  I did not verify this yet, but those packages are also ancient and
probably suffer from the same problem.


Thanks for looking into this,
regards,
Jö.

[1]: I'd prefer to use the Debian packages, since Debian actually cares about
 the trustworthiness and competence of its package maintainers...

-- 
Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,
University of Münster, Orleans-Ring 10, D-48149 Münster
Tel: +49 251 83 35146 Fax: +49 251 83 32729



signature.asc
Description: PGP signature

Bug#889919: Acknowledgement (ksystemlog: SIGSEGV in QAction::setEnabled)

[Nathaniel Morck Foley-Beaver]

As the bug is still reproducible, I have filed a bug report upstream:

https://bugs.kde.org/show_bug.cgi?id=409375

Bug#752709: Plan B - Debian Package antimicro

[Thorsten Glaser]

retitle 752709 ITP: antimicro -- GUI for mapping keyboard keys and mouse 
controls to a gamepad
owner 752709 !
thanks

I’ll work on it, sponsored by ⮡ tarent.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#931282: unblock: s-nail/14.9.11-3

[Sam Hartman]

> "Paride" == Paride Legovini  writes:


I think you could make a compelling argument for an important bug for
this because for those users it will make the package unusable.

I'm not a stable release team member though.

Bug#677036: latexmk does not see files read in using \verbatiminput

[Hilmar Preuße]

On 01.07.19 16:35, Norman Ramsey wrote:
>  > On 11.06.12 11:37, Norman Ramsey wrote:

Hi,

>  > > A file read using
>  > > 
>  > >   \verbatiminput{mumble.tex}
>  > > 
>  > > is not seen as a dependency.  I've confirmed by inspecting
>  > > the database and by using the -diagnostics option.
>  > > 
>  > I'm failing to understand your problem. How does your input file look
>  > like? How does latexmk behave and what would you expect instead to happen?
> 
> In your example, when mumble.tex changes, I expect latexmk to notice
> and to re-run latex.  It doesn't:
> 
latexmk bases it's decisions on the checksum of the files, so you have
change the file content to force a re-run. Simply touching the file
doesn't do the trick.

hille@sid:~/devel/TeXLive/open_bugs/677036 $ latexmk 677036.tex
Latexmk: This is Latexmk, John Collins, 25 October 2018, version: 4.61.
Latexmk: All targets (677036.dvi) are up-to-date
hille@sid:~/devel/TeXLive/open_bugs/677036 $ echo a >> mumble.tex
hille@sid:~/devel/TeXLive/open_bugs/677036 $ latexmk 677036.tex

Output written on 677036.dvi (1 page, 288 bytes).
Transcript written on 677036.log.
=== TeX engine is 'pdfTeX'
Latexmk: Log file says output to '677036.dvi'
Latexmk: All targets (677036.dvi) are up-to-date
hille@sid:~/devel/TeXLive/open_bugs/677036 $ latexmk 677036.tex
Latexmk: This is Latexmk, John Collins, 25 October 2018, version: 4.61.
Latexmk: All targets (677036.dvi) are up-to-date
hille@sid:~/devel/TeXLive/open_bugs/677036 $ touch mumble.tex
hille@sid:~/devel/TeXLive/open_bugs/677036 $ latexmk 677036.tex
Latexmk: This is Latexmk, John Collins, 25 October 2018, version: 4.61.
Latexmk: All targets (677036.dvi) are up-to-date
hille@sid:~/devel/TeXLive/open_bugs/677036 $

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



signature.asc
Description: OpenPGP digital signature

Bug#931297: Please support /usr/lib64/sane

[Gunnar Hjalmarsson]

On 2019-07-01 14:18, Brian Potkin wrote:

Shouldn't this be attended to by Brother?


In an ideal world, yes indeed. But, as I'm sure you know, the situation 
with drivers provided by third-party vendors is anything but ideal.



They have managed to have to done it for brscan4 in the package's > postinst. 
Also, the postinst in brscan3 links to /usr/lib/sane.


Please note that also /usr/lib/sane (which many providers use) is not 
right either, and the purpose of 0125-multiarch_dll_search_path.patch is 
to compensate for that.


So, given that we carry that patch anyway, adding the directory I 
suggest is very simple, as you can see in the attached diff. Quite a few 
users would be helped that way.


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#930428: debootstrap should ensure matching _apt uid

[Julian Andres Klode]

On Mon, Jul 01, 2019 at 02:47:08PM +0200, Michael Schaller wrote:
> Looks like there is no reply from the Apt maintainers. Should I open a
> bug against apt?

The _apt user is used in stable, and various Ubuntu LTS, and so far,
nobody cared about us creating it dynamically. So this is not a matter
of urgency.

> 
> Also could the proposed patch be added to debootstrap as a temporary
> workaround until this is fixed in Apt?

There is nothing to fix here in apt atm.

The only sensible option long term would be to migrate to a different
user I guess, and that sucks, because the user name is nice.

But this is a long-term effort, and not something that will take
place in the short term.

Adding a workaround to debootstrap sounds reasonable, but probably
to be done post-buster release.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#928956: Document removal of ecryptfs-utils from Buster

[Julian Andres Klode]

On Mon, Jul 01, 2019 at 11:52:42PM +0900, Osamu Aoki wrote:
> Hi,
> 
> On Sat, Jun 29, 2019 at 10:05:39AM +0200, Paul Gevers wrote:
> > Hi all,
> > 
> > On 01-06-2019 22:06, Paul Gevers wrote:
> > > On Wed, 15 May 2019 13:00:52 +0100 Justin B Rye
> > >  wrote:
> > >> Daniel Lange wrote:
> >    * reason for removal
> >  not essential, but it helps to understand the issue
> > >>> #765854
> > >>> ecryptfs cannot unmount encrypted home directories due to systemd 
> > >>> keeping
> > >>> the pam session active even after logout.
> > >>> Upstream bug https://github.com/systemd/systemd/issues/8598
> > >>> A work around (user unit file) has not been implemented and tested.
> ...
> > > In absence of other text, I am about to push the attached text to the
> > > release-notes. I hope this isn't the final text, but at least the draft
> > > document now mentions the problem.
> > 
> > Did anybody learn about (documented) migration paths in the mean time?
> 
> Unencrypt eCryptfs data and mount the unencrypted filesystem is one way.
> 
> But then we don't have encryption.
> 
> I can think of migration to dm-crypt/LUKS or encfs/FUSE is an technical
> possibility.  But that's something beyond this document should
> elaborate,

LUKS is the only sensible option, overlay file systems, especially
encfs are significantly less safe, which was among the reasons we
ended up here in the first place.


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#928956: Document removal of ecryptfs-utils from Buster

[Osamu Aoki]

Hi,

On Sat, Jun 29, 2019 at 10:05:39AM +0200, Paul Gevers wrote:
> Hi all,
> 
> On 01-06-2019 22:06, Paul Gevers wrote:
> > On Wed, 15 May 2019 13:00:52 +0100 Justin B Rye
> >  wrote:
> >> Daniel Lange wrote:
>    * reason for removal
>  not essential, but it helps to understand the issue
> >>> #765854
> >>> ecryptfs cannot unmount encrypted home directories due to systemd keeping
> >>> the pam session active even after logout.
> >>> Upstream bug https://github.com/systemd/systemd/issues/8598
> >>> A work around (user unit file) has not been implemented and tested.
...
> > In absence of other text, I am about to push the attached text to the
> > release-notes. I hope this isn't the final text, but at least the draft
> > document now mentions the problem.
> 
> Did anybody learn about (documented) migration paths in the mean time?

Unencrypt eCryptfs data and mount the unencrypted filesystem is one way.

But then we don't have encryption.

I can think of migration to dm-crypt/LUKS or encfs/FUSE is an technical
possibility.  But that's something beyond this document should
elaborate,

Realistically, I think best recommendation to people who wants to have
encryption is 
 * save all your data unencrypted (BACKUP!)
 * move them to freshly installed Debian on full disk encryption
   (RESTORE)

Osamu

Bug#930539: upowerd cannot start due to searching the wrong libssl version

[Andrey Rahmatullin]

On Fri, Jun 14, 2019 at 10:16:50PM +0200, A. Heydwolff wrote:
> Jun 14 21:10:58 karfiol upowerd[15367]: /usr/lib/upower/upowerd: error while 
> loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No 
> such file or directory
Note that /usr/lib/upower/upowerd isn't linked to libssl directly, and, at
least in sid, not even indirectly. This means there is some problem with
one of the libraries it loads and, I suspect, it's a library installed
locally.
You can start debugging this with ldd (or just looking into /usr/local).

> Installed are 
> -rw-r--r-- 1 root root 349K Oct  7  2017 libssl3.so
> -rw-r--r-- 1 root root 422K Feb 27 21:58 libssl.so.1.0.2
> -rw-r--r-- 1 root root 576K Apr 16 21:31 libssl.so.1.1
> 
> I created a 1.0.0 symlink to 1.0.2
Never do this.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#931314: Doesn't check if the vcs is current before importing

[Sebastien Bacher]

Package: git-buildpackage
Version: 0.9.13

While using gbp import-origin on GNOME sources (used a debian/master -
pristine-tar - upstream/latest layout) I've done the mistakes a few
times to do a gbp import-origin before doing a pull/checking if the
local checkout was uptodate.

The import does work without warning and update the 3 branches which put
you in a situation where you need to know git wizary to rollback the
buggy import and start it again.

Would it possible for gbp import commands to warn/ask for confirmation
when the checkout is outdated? (or to provide an easy command to undo
the import/fix the situation when an import is done on an outdated vcs)?

Thanks,

Bug#931213: rpush does not work with split brain quilt modes [and 1 more messages]

[Ian Jackson]

Control: severity -1 important

Ian Jackson writes ("rpush does not work with split brain quilt modes"):
> Nevertheless, given the simplicity of the fix, and the fact that this
> fix makes my new test case pass as expected, this is IMO a candidate
> for a stable update to buster.
> 
> So I propose to push it, and the corresponding new test case, to the
> "stable" branch.

Consistent with that, we need to set the bug priority to "important".

Ian.

Bug#806915: stow: chkstow -l only works for 'stow'

[Adam Spiers]

Thanks a lot - I'll take a look when I get back from holiday!

On Mon, 1 Jul 2019 at 08:00, Nathaniel Morck Foley-Beaver
 wrote:
>
> I have reported the bug upstream here:
>
> https://github.com/aspiers/stow/issues/61
>

Bug#931300: mime-support: update-mime incorrectly handles MimeType containing empty elements

[Alex Riesen]

Charles Plessy, Mon, Jul 01, 2019 15:26:03 +0200:
> Le Mon, Jul 01, 2019 at 09:05:36AM +0200, Alex Riesen a écrit :
> > 
> > elsif (m/MimeType=(.*)/i) {
> > -   push @types, split(/;/, $1);
> > +   push @types, grep {length>0} 
> > split(/\s*;\s*/, $1);
> 
> Do you think it would make sense to throw a warning on stderr when such
> a broken entry is found ?  In that case, would you have time to propose
> an updated patch ?

Of course. Like the below, perhaps? (I still filter them out).

Regards,
Alex


diff --git a/update-mime b/update-mime
index d27b8a9..55495ee 100755
--- a/update-mime
+++ b/update-mime
@@ -157,7 +157,10 @@ sub ReadDesktopEntries
$exec .= " %s" if ($exec !~ m/%s/);
}
elsif (m/MimeType=(.*)/i) {
-   push @types, split(/;/, $1);
+   my $err = 0;
+   push @types, grep { if (length>0) {1} 
else {++$err;0} }
+split(/\s*;\s*/, $1);
+   print STDERR "Warning: $file:$.: 
ignoring empty entries in MimeType\n" if $err;
}
}
if (!defined($exec) || !scalar(@types)) {

Bug#931313: vlc: short silence after resuming playback from pause

[Bert Schlumwig]

Package: vlc
Version: 3.0.7-1
Severity: normal

Since Buster there is a short silence after resuming video playback from pause.
This does NOT happen in Stretch (I just tested it), although both distributions
have the same VLC-version.

How to reproduce this behaviour under Buster:

1. Start video playback
2. Pause playback
3. Wait 10 or more seconds
4. Resume playback

You will have silence for a second while the movie continues.

Here is the VLC internal debugging output when this happens (debug-lvl 2):


main debug: toggling pause
dbus debug: Getting property Position
main debug: end of audio preroll
pulse debug: deferring start (297 us)
pulse debug: starting deferred
main warning: playback too late (60059): up-sampling
main warning: picture is too late to be displayed (missing 54 ms)
main debug: picture might be displayed late (missing 12 ms)
pulse debug: suspended
pulse debug: changing sink 0: alsa_output.pci-_00_14.2.analog-stereo
(Internes Audio Analog Stereo)
pulse debug: started
pulse debug: underflow
main warning: playback way too late (237746): flushing buffers
vlcpulse debug: write index corrupt
pulse debug: cannot synchronize start
pulse debug: deferring start (421921 us)
vlcpulse debug: write index corrupt
pulse debug: cannot synchronize start
pulse debug: deferring start (421321 us)
vlcpulse debug: write index corrupt
pulse debug: cannot synchronize start
pulse debug: deferring start (420726 us)
vlcpulse debug: write index corrupt
pulse debug: cannot synchronize start
pulse debug: deferring start (420111 us)
vlcpulse debug: write index corrupt
pulse debug: cannot synchronize start
pulse debug: deferring start (419431 us)
vlcpulse debug: write index corrupt
pulse debug: cannot synchronize start
pulse debug: deferring start (418837 us)
vlcpulse debug: write index corrupt
pulse debug: cannot synchronize start
pulse debug: deferring start (418237 us)
vlcpulse debug: write index corrupt
pulse debug: cannot synchronize start
pulse debug: deferring start (417535 us)
vlcpulse debug: write index corrupt
pulse debug: cannot synchronize start
pulse debug: deferring start (416885 us)
vlcpulse debug: write index corrupt
pulse debug: cannot synchronize start
pulse debug: deferring start (416260 us)
vlcpulse debug: write index corrupt
pulse debug: cannot synchronize start
pulse debug: deferring start (410916 us)
pulse debug: deferring start (131807 us)
pulse debug: deferring start (131787 us)
pulse debug: deferring start (131768 us)
pulse debug: deferring start (131752 us)
pulse debug: deferring start (131738 us)
pulse debug: deferring start (131723 us)
pulse debug: deferring start (131710 us)
pulse debug: deferring start (131696 us)
pulse debug: deferring start (131681 us)
pulse debug: deferring start (131667 us)
pulse debug: deferring start (131652 us)
pulse debug: deferring start (131638 us)
pulse debug: deferring start (131624 us)
pulse debug: changing sink 0: alsa_output.pci-_00_14.2.analog-stereo
(Internes Audio Analog Stereo)
pulse debug: deferring start (126778 us)
pulse debug: deferring start (106427 us)
pulse debug: deferring start (65944 us)
main debug: auto hiding mouse cursor
pulse debug: starting deferred
pulse debug: changing sink 0: alsa_output.pci-_00_14.2.analog-stereo
(Internes Audio Analog Stereo)
pulse debug: started
main warning: playback way too early (-233471): playing silence
main debug: inserting 10296 zeroes
main debug: toggling resume
main debug: toggling resume
dbus_screensaver debug: got cookie 16737
dbus debug: Getting property Position
pulse debug: changing sink 0: alsa_output.pci-_00_14.2.analog-stereo
(Internes Audio Analog Stereo)
pulse debug: suspended
pulse debug: changing sink 0: alsa_output.pci-_00_14.2.analog-stereo
(Internes Audio Analog Stereo)



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vlc depends on:
ii  vlc-bin  3.0.7-1
ii  vlc-plugin-base  3.0.7-1
ii  vlc-plugin-qt3.0.7-1
ii  vlc-plugin-video-output  3.0.7-1

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.7-1
pn  vlc-plugin-notify  
pn  vlc-plugin-samba   
pn  vlc-plugin-skins2  
pn  vlc-plugin-video-splitter  
pn  vlc-plugin-visualization   

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.28-10
ii  libvlc5  3.0.7-1

Versions of packages libvlc5 depends on:
ii  libc62.28-10
ii  libvlccore9  3.0.7-1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.7-1

Versions of packages vlc-bin depends on:
ii  libc6   2.28-10
ii  libvlc-bin  3.0.7-1
ii  libvlc5 3.0.7-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.

Bug#931267: times out and drops into useless emergency shell with fsck still ongoing

[Steve McIntyre]

Control: severity -1 normal

Hey Michael,

Agreed on the downgrade...

On Mon, Jul 01, 2019 at 02:14:26PM +0200, Michael Biebl wrote:
>
>with your additional information about the faulty fstab entry,
>I had another look.
>a/
>I first tried with a non-existing device. I also made sure the
>concurrently running fsck takes longer then 90s.
>
>The result is:
>https://people.debian.org/~biebl/bug931267/boot-missing-device.mp4
>
>systemd will indeed start the emergency shell after 90s, although the
>fsckd process is still ongoing and clobbers the output of the login prompt.
>
>Once the fsck is done, simply hitting enter one can log in without problems.
>
>b/
>Next I tried with a faulty mount point where the device exists but the
>mount options are non-sense, so will trigger a mount failure.
>The emergency shell is immediately started while fsck is still ongoing.
>See
>https://people.debian.org/~biebl/bug931267/boot-failing-mount.mp4
>
>I guess this is basically what happened in your case.
>The login prompt was again still usable.
>
>Given this, I'm inclined to downgrade the severity.
>
>I'm not entirely sure how to fix this though.
>Should systemd delay the start of the sulogin prompt until all fsck
>processes have finished? You can't interact with the system for a
>potentially very long time (the same way basically as is the case now).
>The only thing you'd gain is that the login prompt in such a case
>doesn't look clobbered.

Right. Starting things on a busy console like now is confusing for
users. I'm not sure there *is* a good answer here, tbh. :-/

Maybe(?) it would be possible to steal a few more characters of each
line of the terminal output at boot for a tiny status message? The you
could have that show that the boot has hit errors? Similar to the
existing LSB-style [ OK ] or [FAILED] messages for each servive, but
to show overall system status?

My own system looked a lot messier than what you're showing in your
simple video, of course - other services starting up around this added
a lot of noise. My server runs lots of services. Of course, I didn't
get to capture the output directly, just the logs.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross

Bug#421759: include feynmf

[Hilmar Preuße]

On 01.05.07 12:38, Tim Gershon wrote:

Hi Tim,

> First, the praise: I find the latexmk package extremely useful for
> nearly all of my needs.
> 
> Now, the request: when preparing documents including feynman diagrams
> (prepared with the feynmf package), latexmk doesn't quite do everything
> for me ... I still need to run feynmf in addition.  It would be great if
> latexmk could do this for me automatically.
> 
The CHANGES file for latexmk reads:

From v. 4.28c to 4.29a
Latexmk now works with the feynmp package and mpost,
   provided a suitable custom dependency is defined.  (See the
   example latexmkrc fragment mpost_latexmkrc in the
   example_rcfiles directory in the latexmk distribution.)

To me it seems that your request has been implemented yet. Can you
confirm this?

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



signature.asc
Description: OpenPGP digital signature

Bug#931300: mime-support: update-mime incorrectly handles MimeType containing empty elements

[Charles Plessy]

Control: clone 931300 -1
Control: reassign 931300 mime-support
Control: retile 931300 mime-support: update-mime incorrectly handles MimeType 
containing empty elements
Control: found 931300 3.60

Le Mon, Jul 01, 2019 at 10:21:24PM +0900, Charles Plessy a écrit :
> Control: clone -1
> Control: reassign -1 evince
> Control: retitle -1 evince: broken Desktop entry file in Stable
> Control: found -1 3.22.1-3+deb9u1
> Control: notfound -1 3.30.2-3
> 
> Dear Evince maintainers,

Sorry for the noise...

-- 
Charles

Bug#931300: mime-support: update-mime incorrectly handles MimeType containing empty elements

[Charles Plessy]

Le Mon, Jul 01, 2019 at 09:05:36AM +0200, Alex Riesen a écrit :
> 
> diff --git a/update-mime b/update-mime
> index d27b8a9..be4187f 100755
> --- a/update-mime
> +++ b/update-mime
> @@ -157,7 +157,7 @@ sub ReadDesktopEntries
>   $exec .= " %s" if ($exec !~ m/%s/);
>   }
>   elsif (m/MimeType=(.*)/i) {
> - push @types, split(/;/, $1);
> + push @types, grep {length>0} 
> split(/\s*;\s*/, $1);
>   }
>   }
>   if (!defined($exec) || !scalar(@types)) {

Dear Alex,

thank you for the report and for the patch.

Do you think it would make sense to throw a warning on stderr when such
a broken entry is found ?  In that case, would you have time to propose
an updated patch ?

Have a nice day,

Charles

-- 
Charles Plessy
Akano, Uruma, Okinawa, Japan

Bug#931300: mime-support: update-mime incorrectly handles MimeType containing empty elements

[Charles Plessy]

Control: clone -1
Control: reassign -1 evince
Control: retitle -1 evince: broken Desktop entry file in Stable
Control: found -1 3.22.1-3+deb9u1
Control: notfound -1 3.30.2-3

Dear Evince maintainers,

evince in Stable contains a broken Desktop file that causes mime-support
to produce a broken mailcap file:

Le Mon, Jul 01, 2019 at 09:05:36AM +0200, Alex Riesen a écrit :
> Package: mime-support
> Version: 3.60
> Severity: minor
> 
> I noticed a strange entry in /etc/mailcap:
> 
> application/x-ext-cb7; evince %s; test=test -n "$DISPLAY"
> ; evince %s; test=test -n "$DISPLAY"
> application/oxps; evince %s; test=test -n "$DISPLAY"
> 
> After a bit of investigation, it turned out that generation of the entry has
> been triggered by an empty item in evince.desktop (evince 3.22.1-3+deb9u1) 
> file:
> 
> 
> MimeType=application/pdf;application/x-bzpdf;application/x-gzpdf;application/x-xzpdf;application/x-ext-pdf;application/postscript;application/x-bzpostscript;application/x-gzpostscript;image/x-eps;image/x-bzeps;image/x-gzeps;application/x-ext-ps;application/x-ext-eps;application/x-dvi;application/x-bzdvi;application/x-gzdvi;application/x-ext-dvi;image/vnd.djvu;image/vnd.djvu+multipage;application/x-ext-djv;application/x-ext-djvu;image/tiff;application/x-cbr;application/x-cbz;application/x-cb7;application/x-ext-cbr;application/x-ext-cbz;application/vnd.comicbook+zip;application/x-ext-cb7;;application/oxps;application/vnd.ms-xpsdocument;

Indeed, desktop-file-validate rejects this entry:

desktop-file-validate /usr/share/applications/evince.desktop 
/usr/share/applications/evince.desktop: hint: value 
"GNOME;GTK;Office;Viewer;Graphics;2DGraphics;VectorGraphics;" for key 
"Categories" in group "Desktop Entry" contains more than one main category; 
application might appear more than once in the application menu
/usr/share/applications/evince.desktop: error: (will be fatal in the future): 
value 
"application/pdf;application/x-bzpdf;application/x-gzpdf;application/x-xzpdf;application/x-ext-pdf;application/postscript;application/x-bzpostscript;application/x-gzpostscript;image/x-eps;image/x-bzeps;image/x-gzeps;application/x-ext-ps;application/x-ext-eps;application/x-dvi;application/x-bzdvi;application/x-gzdvi;application/x-ext-dvi;image/vnd.djvu;image/vnd.djvu+multipage;application/x-ext-djv;application/x-ext-djvu;image/tiff;application/x-cbr;application/x-cbz;application/x-cb7;application/x-ext-cbr;application/x-ext-cbz;application/vnd.comicbook+zip;application/x-ext-cb7;;application/oxps;application/vnd.ms-xpsdocument;"
 for key "MimeType" in group "Desktop Entry" contains value "" which is an 
invalid MIME type: "" does not contain a subtype

I am not sure if this warrants a stable update, but at least I wanted to let 
you know the issue.

Have a nice day,

Charles

-- 
Charles Plessy
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Bug#931311: libsixel: Multiple security issues (CVE-2018-19756 CVE-2018-19757 CVE-2018-19759 CVE-2018-19761 CVE-2018-19762 CVE-2018-19763)

[Sylvain Beucler]

Package: libsixel
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for libsixel.

AFAICS upstream didn't act on them yet (see issues links).


CVE-2018-19756[0]:
| There is a heap-based buffer over-read at stb_image.h (function:
| stbi__tga_load) in libsixel 1.8.2 that will cause a denial of service.


CVE-2018-19757[1]:
| There is a NULL pointer dereference at function
| sixel_helper_set_additional_message (status.c) in libsixel 1.8.2 that
| will cause a denial of service.


CVE-2018-19759[2]:
| There is a heap-based buffer over-read at stb_image_write.h (function:
| stbi_write_png_to_mem) in libsixel 1.8.2 that will cause a denial of
| service.


CVE-2018-19761[3]:
| There is an illegal address access at fromsixel.c (function:
| sixel_decode_raw_impl) in libsixel 1.8.2 that will cause a denial of
| service.


CVE-2018-19762[4]:
| There is a heap-based buffer overflow at fromsixel.c (function:
| image_buffer_resize) in libsixel 1.8.2 that will cause a denial of
| service or possibly unspecified other impact.


CVE-2018-19763[5]:
| There is a heap-based buffer over-read at writer.c (function:
| write_png_to_file) in libsixel 1.8.2 that will cause a denial of
| service.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-19756
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19756
https://github.com/saitoha/libsixel/issues/80
[1] https://security-tracker.debian.org/tracker/CVE-2018-19757
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19757
https://github.com/saitoha/libsixel/issues/79
[2] https://security-tracker.debian.org/tracker/CVE-2018-19759
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19759
https://github.com/saitoha/libsixel/issues/77
[3] https://security-tracker.debian.org/tracker/CVE-2018-19761
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19761
https://github.com/saitoha/libsixel/issues/78
[4] https://security-tracker.debian.org/tracker/CVE-2018-19762
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19762
https://github.com/saitoha/libsixel/issues/81
[5] https://security-tracker.debian.org/tracker/CVE-2018-19763
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19763
https://github.com/saitoha/libsixel/issues/82

Please adjust the affected versions in the BTS as needed.

Cheers!
Sylvain Beucler, Debian LTS team

Bug#931309: Multiple security issues (CVE-2018-14449..14459, CVE-2018-18192..18197)

[Sylvain Beucler]

retitle 931309 libgig: Multiple security issues (CVE-2018-14449..14459,
CVE-2018-18192..18197)
thanks

(typo: not CVE-2018-14460)

Bug#931310: network-console: It isn't possible to preseed network-console/login

[Blazej]

Package: network-console
Severity: normal
Tags: d-i

Answering network-console/login causes network-console to exit
immediately upon login.

Steps to reproduce:
1. Include the following in a preseed.cfg:

d-i anna/choose_modules string network-console
d-i network-console/login string Start installer
2. Boot the installation image
3. SSH to installer@host
4. See that there's no window #1

Cause:
The cause is, for a reason that I do not understand, the following line in
`/bin/network-console-menu`:

db_input critical $TEMPLATE_ROOT/login

Workaround:
Removing this line solves the problem when the question is already
answered, although it probably doesn't work when it isn't.

Expected outcome:
Answering the question would start installation immediately after login,
without the need for the workaround.

This is important to me, because the network console in my case is used
only to monitor progress, and not for any interaction. Hence, having to
press Enter to start installation prevents me from fully automating the
installation process.

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

Kernel: Linux 4.9.0-9-amd64 (SMP w/12 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)

Bug#931214: ImportError: No module named oslo.config

[Thomas Goirand]

On 6/30/19 7:40 AM, Paul Gevers wrote:
> Hi Thomas,
> 
> On 29-06-2019 23:02, Thomas Goirand wrote:
>> On 6/29/19 10:12 AM, Paul Gevers wrote:
>>> On Fri, 28 Jun 2019 13:52:43 +0200 =?iso-8859-1?Q?J=F6?= Fahlke
>>>  wrote:
 Package: python-os-collect-config
 Version: 0.1.15-1
 Severity: grave
>>>
>>> This is on the radar of the release team, due to the very late time in
>>> the release. Please, any comment from your side helps judging what to do.
>>>
 I'm trying to use os-collect-config in a Debian stretch instance in an
 openstack cluster.  However, running it immediately leads to an import 
 error:
>>>
>>> [...]
>>>
 ImportError: No module named oslo.config
> 
>> It looks like it's just missing a runtime dependency. Just manually
>> installing oslo.config would fix this. So I do contest that the package
>> is not usable. It is, as long as you install pyhon-oslo.config.
> 
> Did you check that that dependency is missing? I checked before and I
> believe that python-oslo.config is in the listed dependencies *and*
> installed on the machine where the log came from. What am I missing?
> 
> Paul

Hi Paul,

Looking further, it looks like python-os-collect-config is a *very* old
package in Debian (ie: no update since 2014), and it's not adapted
anymore to the version of python-oslo.config that is in Debian. ie:
oslo.config has moved away from a namespace based system to a
non-namespace, so it should now be "import oslo_config" and not "import
oslo.config".

So, as a result, there's no way python-os-collect-config will work in
Buster unless we update it to a much newer version, like for example
version 9.2.1. Of course, it's already too late in the release process
to do this, so we may just remove os-collect-config from Buster to fix
the current situation.

I'm sorry the OpenStack team failed to maintain this leaf package,
however, my understanding is that this package is for TripleO, which
isn't, and wont ever, work in Debian.

Jo, could you explain what your use case is for os-collect-config in
Debian? I really don't get how it can be useful for you.

Cheers,

Thomas Goirand (zigo)

Bug#931297: Please support /usr/lib64/sane

[Brian Potkin]

On Mon 01 Jul 2019 at 01:34:28 +0200, Gunnar Hjalmarsson wrote:

> The patch 0125-multiarch_dll_search_path.patch makes /usr/lib/sane be
> recognized as a directory for SANE backends. However, some .deb files with
> scanner drivers, typically provided by Brother, install files in
> /usr/lib64/sane. It would be great if that directory could be supported too.
> 
> This was mentioned in , but it seems to have
> been overlooked.

Shouldn't this be attended to by Brother? They have managed to have
to done it for brscan4 in the package's postinst. Also, the postinst
in brscan3 links to /usr/lib/sane.

Regards,

Brian.

Bug#926943: closed by Thomas Goirand (Bug#926943: fixed in python-rtslib-fb 2.1.66-3)

[Thomas Goirand]

On 6/30/19 7:25 PM, George Diamantopoulos wrote:
> Hello,
> 
> Are there any plans to push this fix to buster before its release? Thank
> you.
> 
> BR,
> George

Hi George,

At this point, it's already too late for Buster, and this will have to
be pushed through the 1st point release update. I know because I
couldn't push an update for another package (cloudkitty, which FTBFS
after an update of SQLAlchemy to address a CVE).

Feel free to contribute it if you like.

Cheers,

Thomas Goirand (zigo)

Bug#931248: pan: No icon bar.

[Dominique Dumont]

On Saturday, 29 June 2019 13:16:25 CEST you wrote:
> After some years without launching Pan, I saw that the post message windows
> has no icons in the icon bar.

Porting pan to Gtk3 is not finished yet and the toolbar is not shown. See 
upstream bug https://gitlab.gnome.org/GNOME/pan/issues/74 for details

All the best

Bug#931308: bash: given path disappears with autocompletion

[Philipp Marek]

Package: bash
Version: 5.0-4
Severity: normal

To reproduce:

- Go into some directory with write permissions (eg /tmp)
- do # mkdir foo bar bar/boz bar/baz-$'\n'.
- do # cd foo
- enter 'ls -la ../ba' and press  to complete entries in there

Expected result:
I get a list of entries, with "boz" and "baz-?" to choose from.

Actual result:
 removes the whole parameter, and I end up with "ls -la .".


I know that a newline in a filename is a bad thing (I had a bug in a
"find -printf" line ;), but still it shouldn't break that way.


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 
'unstable'), (1, 'experimental')

Architecture: amd64 (x86_64)

Kernel: Linux 5.0.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de (charmap=UTF-8)

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

Versions of packages bash depends on:
ii  base-files   10.3
ii  debianutils  4.8.6.1
ii  libc62.28-10
ii  libtinfo66.1+20181013-2

Versions of packages bash recommends:
ii  bash-completion  1:2.8-6

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#931309: Multiple security issues (CVE-2018-14449..14460, CVE-2018-18192..18197)

[Sylvain Beucler]

Package: libgig
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for libgig.
See:
https://github.com/TeamSeri0us/pocs/blob/master/libgig/README.md
https://github.com/TeamSeri0us/pocs/blob/master/libgig/README-1008.md
for the initial report and reproducers.

As far as I can see, there was no discussion yet with you (package
maintainers), nor with upstream, so I'm opening this bug to clarify
their status.


CVE-2018-14449[0]:
| An issue was discovered in libgig 4.1.0. There is an out of bounds
| read in gig::File::UpdateChunks in gig.cpp.


CVE-2018-14450[1]:
| An issue was discovered in libgig 4.1.0. There is an out-of-bounds
| read in the "update dimension region's chunks" feature of the function
| gig::Region::UpdateChunks in gig.cpp.


CVE-2018-14451[2]:
| An issue was discovered in libgig 4.1.0. There is a heap-based buffer
| overflow in the function RIFF::Chunk::Read in RIFF.cpp.


CVE-2018-14452[3]:
| An issue was discovered in libgig 4.1.0. There is an out-of-bounds
| read in the "always assign the sample of the first dimension region of
| this region" feature of the function gig::Region::UpdateChunks in
| gig.cpp.


CVE-2018-14453[4]:
| An issue was discovered in libgig 4.1.0. There is a heap-based buffer
| overflow in pData[1] access in the function store16 in helper.h.


CVE-2018-14454[5]:
| An issue was discovered in libgig 4.1.0. There is an out-of-bounds
| read in the function RIFF::Chunk::Read in RIFF.cpp.


CVE-2018-14455[6]:
| An issue was discovered in libgig 4.1.0. There is an out-of-bounds
| write in pData[0] access in the function store32 in helper.h.


CVE-2018-14456[7]:
| An issue was discovered in libgig 4.1.0. There is an out-of-bounds
| write in the function DLS::Info::SaveString in DLS.cpp.


CVE-2018-14457[8]:
| An issue was discovered in libgig 4.1.0. There is an out-of-bounds
| write in the function DLS::Info::UpdateChunks in DLS.cpp.


CVE-2018-14458[9]:
| An issue was discovered in libgig 4.1.0. There is a heap-based buffer
| overflow in pData[1] access in the function store32 in helper.h.


CVE-2018-14459[10]:
| An issue was discovered in libgig 4.1.0. There is an out-of-bounds
| write in pData[0] access in the function store16 in helper.h.


CVE-2018-14460[11]:
| An issue was discovered in the HDF HDF5 1.8.20 library. There is a
| heap-based buffer over-read in the function H5O_sdspace_decode in
| H5Osdspace.c.


CVE-2018-18192[12]:
| An issue was discovered in libgig 4.1.0. There is a NULL pointer
| dereference in the function DLS::File::GetFirstSample() in DLS.cpp.


CVE-2018-18193[13]:
| An issue was discovered in libgig 4.1.0. There is operator new[]
| failure (due to a big pWavePoolTable heap request) in DLS::File::File
| in DLS.cpp.


CVE-2018-18194[14]:
| An issue was discovered in libgig 4.1.0. There is a heap-based buffer
| over-read in DLS::Region::GetSample() in DLS.cpp.


CVE-2018-18195[15]:
| An issue was discovered in libgig 4.1.0. There is an FPE (divide-by-
| zero error) in DLS::Sample::Sample in DLS.cpp.


CVE-2018-18196[16]:
| An issue was discovered in libgig 4.1.0. There is a heap-based buffer
| over-read in RIFF::List::GetListTypeString in RIFF.cpp.


CVE-2018-18197[17]:
| An issue was discovered in libgig 4.1.0. There is an operator new[]
| failure (due to a big pSampleLoops heap request) in
| DLS::Sampler::Sampler in DLS.cpp.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-14449
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14449
[1] https://security-tracker.debian.org/tracker/CVE-2018-14450
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14450
[2] https://security-tracker.debian.org/tracker/CVE-2018-14451
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14451
[3] https://security-tracker.debian.org/tracker/CVE-2018-14452
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14452
[4] https://security-tracker.debian.org/tracker/CVE-2018-14453
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14453
[5] https://security-tracker.debian.org/tracker/CVE-2018-14454
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14454
[6] https://security-tracker.debian.org/tracker/CVE-2018-14455
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14455
[7] https://security-tracker.debian.org/tracker/CVE-2018-14456
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14456
[8] https://security-tracker.debian.org/tracker/CVE-2018-14457
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14457
[9] https://security-tracker.debian.org/tracker/CVE-2018-14458
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14458
[10] https://security-tracker.debian.org/tracker/CVE-2018-14459
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-20

Bug#865443: dgit: Want different deletion handling in split brain mode

[Ian Jackson]

Version: 8.3

Felipe Sateler writes ("Bug#865443: dgit: Want different deletion handling in 
split brain mode"):
> I want to note that on this commit, currently dgit says:
> 
> dgit: error: --quilt=gbp specified, implying patches-unapplied git tree
> dgit:  but git tree differs from orig in upstream files.
> dgit: For full diff showing the problem(s), type:
> dgit:  git diff b8f8e91b20ed09dad30f2ab3d9af90d24e67ed97 HEAD -- :/ ':!debian'
> ':!/.gitignore' ':!*/.gitignore'
> 
> This is quite an improvement since I first wrote to this bug. From my own POV,
> this new, readable message fixes the issue.

Thanks.  I think, based on this, that it is probably best to close
this bug now.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#930930: dgit: suggestion to use -wga/-wgfa could also suggest using -wn --include-dirty

[Ian Jackson]

Sean Whitton writes ("Bug#930930: dgit: suggestion to use -wga/-wgfa could also 
suggest using -wn --include-dirty"):
> A third possibility is recommending that the user stage the files and
> then just --include-dirty should be sufficient.

--include-dirty has lots of problems (not compatible with many quilt
modes, awkwardnesses with clean handling, etc.) and I don't think we
should be suggesting it if they user doesn't think of it.  Certainly
we shouldn't recommend using it without reading the docs.

Is the idea of committing them not obvious enough ?

If not, maybe
  dgit: You can use --clean=git[-ff],always (-wga/-wgfa) to delete them.
  dgit: To include them, you should probably git add and commit them.
?

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#930956: [PATCH] dgit-maint-debrebase(7): Minor wording change apropos of #930956

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 dgit-maint-debrebase.7.pod | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod
index 6ffa2301..d75a6586 100644
--- a/dgit-maint-debrebase.7.pod
+++ b/dgit-maint-debrebase.7.pod
@@ -375,7 +375,7 @@ release:
 
 =back
 
-Additionally pass I<--name-status> and I<--diff-filter=ADR> to see
+Also, diff with I<--name-status> and I<--diff-filter=ADR> to see
 just the list of added or removed files, which is useful to determine
 whether there are any new or deleted files that may need accounting
 for in your copyright file.
-- 
2.11.0

Bug#923046: flatpak segfaults in live-build hook

[Simon McVittie]

Control: retitle -1 flatpak: segfault when no D-Bus system bus is available
Control: reassign -1 libpolkit-agent-1-0 0.105-18
Control: tags -1 + patch fixed-upstream

On Sat, 23 Feb 2019 at 16:23:20 +0100, Ronny Standtke wrote:
> (flatpak remote-add:9603): GLib-GIO-CRITICAL **:
> g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION
> (connection)' failed
> 
> ** (flatpak remote-add:9603): CRITICAL **:
> polkit_authority_register_authentication_agent_with_options_sync:
> assertion 'POLKIT_IS_AUTHORITY (authority)' failed
> 
> Segmentation fault

I've encountered this again in a different environment, and it appears
to be a libpolkit-agent-1-0 bug. A minimal reproducer is to run flatpak
with no D-Bus system bus available, for example by mounting a tmpfs over
/run/dbus on an ordinary desktop system:

bwrap --dev-bind / / --tmpfs /run/dbus flatpak list --system

resulting in these critical warnings:

(flatpak list:15619): GLib-GIO-CRITICAL **: 11:45:34.076: 
g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION 
(connection)' failed

** (flatpak list:15619): CRITICAL **: 11:45:34.077: 
polkit_authority_register_authentication_agent_with_options_sync: assertion 
'POLKIT_IS_AUTHORITY (authority)' failed

followed by this segmentation fault:

#0  0x7f989c459b62 in server_register 
(server=server@entry=0x55cff362b120, error=error@entry=0x7ffc7a6d95b8)
at polkitagentlistener.c:157
#1  0x7f989c45a281 in polkit_agent_listener_register_with_options
(listener=0x55cff3621d40, 
flags=POLKIT_AGENT_REGISTER_FLAGS_RUN_IN_THREAD, subject=0x55cff3620900, 
object_path=, options=, cancellable=0x0, 
error=0x7ffc7a6d95b8) at polkitagentlistener.c:457
#2  0x55cff2067405 in  ()
#3  0x7f989b82a09b in __libc_start_main (main=
0x55cff2067140, argc=3, argv=0x7ffc7a6d97f8, init=, 
fini=, rtld_fini=, stack_end=0x7ffc7a6d97e8) at 
../csu/libc-start.c:308

This was fixed in polkit 0.108 with the attached patch, which is
unfortunately missing from what is effectively a Debian fork of polkit
0.105 (in recent versions we have been quite thorough about backporting
bugfixes from 0.11x into 0.105, but some of the older changes have still
not been incorporated).

For post-buster, I think we should probably switch to the latest
upstream versions of polkit; and if the JavaScript policy format is still
considered unacceptable by the Debian polkit maintainers, then we should
version the package as 0.105+mostly0.116 or similar, and apply Debian
patches to disable the JavaScript policy engine and reinstate the old
"local authority" policy engine.

smcv
>From 44d4126e10515626c520585b9277f7615e0d3bf7 Mon Sep 17 00:00:00 2001
From: Adam Jackson 
Date: Tue, 9 Oct 2012 14:08:24 -0400
Subject: [PATCH] PolkitAgent: Avoid crashing if initializing the server object
 fails

Note that otherwise we return a freed server object.  Since later in
polkit_agent_listener_register_with_options we check against NULL to
determine failure, this makes for sad times later when we call
server_free() on it again.

Signed-off-by: David Zeuthen 
Origin: 0.108, commit:59f2d96ce3ac63173669f299a9453a7bf5e70a70
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=55776
Bug-Debian: https://bugs.debian.org/923046
---
 src/polkitagent/polkitagentlistener.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/polkitagent/polkitagentlistener.c b/src/polkitagent/polkitagentlistener.c
index 718b742..e0b7b57 100644
--- a/src/polkitagent/polkitagentlistener.c
+++ b/src/polkitagent/polkitagentlistener.c
@@ -257,10 +257,9 @@ server_new (PolkitSubject  *subject,
   if (!server_init_sync (server, cancellable, error))
 {
   server_free (server);
-  goto out;
+  return NULL;
 }
 
- out:
   return server;
 }
 
-- 
2.20.1

Bug#931267: times out and drops into useless emergency shell with fsck still ongoing

[Michael Biebl]

Hi Steve,

with your additional information about the faulty fstab entry,
I had another look.
a/
I first tried with a non-existing device. I also made sure the
concurrently running fsck takes longer then 90s.

The result is:
https://people.debian.org/~biebl/bug931267/boot-missing-device.mp4

systemd will indeed start the emergency shell after 90s, although the
fsckd process is still ongoing and clobbers the output of the login prompt.

Once the fsck is done, simply hitting enter one can log in without problems.

b/
Next I tried with a faulty mount point where the device exists but the
mount options are non-sense, so will trigger a mount failure.
The emergency shell is immediately started while fsck is still ongoing.
See
https://people.debian.org/~biebl/bug931267/boot-failing-mount.mp4

I guess this is basically what happened in your case.
The login prompt was again still usable.

Given this, I'm inclined to downgrade the severity.

I'm not entirely sure how to fix this though.
Should systemd delay the start of the sulogin prompt until all fsck
processes have finished? You can't interact with the system for a
potentially very long time (the same way basically as is the case now).
The only thing you'd gain is that the login prompt in such a case
doesn't look clobbered.




-- 
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#931307: linux-image-4.9.0-9-amd64: Problems with Samba Shares?

[Werner Detter]

Package: src:linux
Version: 4.9.168-1+deb9u3
Severity: important

Dear Maintainer,

after upgrading to the latest linux-image-adm64 on stretch we're experiencing 
strange issues on a 
fileserver with samba: directory listings in subfolder of shares don't work 
after upgrading to 
4.9.168-1+deb9u3 on the clients. I've rebooted the machine to 
linux-image-4.9.0-8-amd64 - with that 
version everything is working. 

So I'm wondering if there are other users which experience similar problems 
with the latest 
kernel and samba? 

Thanks,
Werner


-- Package-specific info:
** Kernel log: boot messages should be attached


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

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

Versions of packages linux-image-4.9.0-9-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod23-2
ii  linux-base  4.5

Versions of packages linux-image-4.9.0-9-amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2.3

Versions of packages linux-image-4.9.0-9-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta3-5+deb9u1
pn  linux-doc-4.9   

Versions of packages linux-image-4.9.0-9-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#695733: latexmk: bibtex does not find bib file

[Hilmar Preuße]

On 12.12.12 05:47, Andres Cimmarusti wrote:

Hi Andres,

> Using a local configuration/initialization file (latexmkrc in same 
> location as .tex file), I'm passing a path option to 'kpsewhich', so 
> that it knows where to look for my bib file:
> 
> $kpsewhich = "kpsewhich -path=bibliography %S";
> 
> This is the result of invoking latexmk:
> 


> So it seems latexmk finds the bib file (or rather kpsewhich does), but 
> somehow this information is not passed to bibtex which fails 
> catastrophically (the same happens to a similar tool as latexmk called 
> rubber).
> 
I'm trying to understand your bug report.

1. I do not understand your statement "latexmk finds the bib file (or
rather kpsewhich does)". On my system (Debian unstable) the kpsewhich
command does not find your bibliography.

hille@sid:~/devel/TeXLive/open_bugs/695733 $ kpsewhich
--path=bibliography latexmk_bibtex_test
hille@sid:~/devel/TeXLive/open_bugs/695733 $

Please note that %S expands to the TeX source file, if I understand
correctly. The kpsewhich works, when all informations about the bib file
are submitted:

hille@sid:~/devel/TeXLive/open_bugs/695733 $ kpsewhich
--path=$PWD/bibliography testbib.bib
/home/hille/devel/TeXLive/open_bugs/695733/bibliography/testbib.bib
hille@sid:~/devel/TeXLive/open_bugs/695733 $

..however I don't see much gain in doing it this way. Putting $PWD into
latexmkrc does not work anyway.

2. kpsewhich is very good in finding files, when they are indexed in a
ls-lR database, which is probably not the case four your personal files.

So my understanding is that you have wrong expectations, what kpsewhich
can do for you when searching files. Submitting the subdir directly in
the TeX source file seems to be a more smart solution:

\bibliography{bibliography/testbib}

Let me know your thoughts,
  Hilmar
-- 
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#806915: stow: chkstow -l only works for 'stow'

[Nathaniel Morck Foley-Beaver]

I have reported the bug upstream here:

https://github.com/aspiers/stow/issues/61

Bug#915841: newsbeuter FTBFS with json-c 0.13.1

[Nikos Tsipinakis]

On 01/07, Gianfranco Costamagna wrote:
> there is an upstream fix in a fork called newsboat
> 
> I'm attaching both patches to this bug report, please apply them!

I apologise for ignoring this issue earlier. I initially intended to convert
newsbeuter to a stub package pointing to newsboat but missed the buster 
deadline.

Given that upstream is abandoned and there is a functionally identical fork I
intend to remove newsbeuter from the archive. It doesn't make sense to become a
pseudo-upstream to keep it in Debian.

I'll file a removal request for it next week after the Buster release.

Bug#931306: TAG: joplin - open source note-taking app with sync

[mousebot]

Package: wnpp
Severity: RFP

Joplin desktop client for linux.

"Joplin is a free, open source note taking and to-do application, which
can handle a large number of notes organised into notebooks. The notes
are searchable, can be copied, tagged and modified either from the
applications directly or from your own text editor. The notes are in
Markdown format."

Downloads and License:
https://github.com/laurent22/joplin
(license at very bottom of page)

thx
m

-- 
book: https://material-s.blogspot.com/p/materialien-m.html
the internet: https://pleasantlybabykid.tumblr.com/
chaps: http://bulkynewspress.tumblr.com/
.
xmpp: mo...@gegensatz.hopto.org
matrix: @martianh:matrix.org

gpg pub key: 0xC169 D863 A911 4245
fingerprint: 6F41 F020 252C 96B1 D0CF 8344 C169 D863 A911 4245


0xC169D863A9114245.asc
Description: application/pgp-keys

Bug#651421: Hello

[Nelson Kwame]

Hello my dear please i want to know if you receive the last message of
business transaction i send to you please i am waiting for your response.

Bug#931280: gnome-shell: Keyboard layout randomly alternates

[Michael Biebl]

Am 01.07.19 um 10:29 schrieb Paul Menzel:
> On 30.06.19 15:58, Michael Biebl wrote:

>> I too have two keyboard layouts configured and this happens to me as
>> well, under GNOME/Xorg and afaics is simply me pressing by accident
>> Windows/Super + Space. This is the shortcut for switching the keyboard
>> layout.
>> I suspect it's the same for you.
>> You can reconfigure the shortcut in gnome-control-center.
>> Go to "Tastatur->Texteingabe->Zur nächsten Quelle wechseln"
> 
> I am pretty sure, it’s not it, because if I press this shortcut, a popup
> is shown and the notification in the top bar changes.

I only get this pop-up as long as I press Super. Once I release Super,
the popup is gone. If I do that quickly, then the popup is never shown here.
That said, my status indicator (in the upper right corner, I guess
that's what you meant with notification) *does* change.
So your case might be different indeed.
I just wanted to rule out the most obvious (e.g. by disabling this
shortcut temporarily)

Regards
-- 
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#929527: [pkg-netfilter-team] Bug#929527: Bug#914694

[Arturo Borrero Gonzalez]

On 6/28/19 11:56 AM, Rhonda D'Vine wrote:
>  Please don't abuse backports for bugfixes that belong in stable.  This
> won't solve the issues for users of stable.  Backports is for newer
> features in software, not for offering bugfixes for stable.
> 

Perhaps you didn't read my next point? "For important bugs [..] buster-stable"

> Custom chains aren't really something exotic like you try to imply.
> Most tools that offer a bit more of a complex possibility to maintain
> your firewall settings are using them.  And if a simple iptables-restore
> can trigger this segfault for a setup that is far from exotic then it's
> a regression that appears through the change of the tool that should
> rather ring alarm clocks instead of trying to downplay the issue, in my
> opinion. :/
> 

I think I didn't explain myself enough. Let me try again.

Usecase that triggers this bug:
=== 8< ===
* define a custom chain
* flush all rules of that custom chain (not required, because the chain was just
created)
* add a rule to that custom chain
=== 8< ===

i.e, this file:

*filter
:NEW-OUTPUT - [0:0]
-A OUTPUT -j NEW-OUTPUT
-F NEW-OUTPUT
-A NEW-OUTPUT -j ACCEPT
COMMIT

The problem here is the '-F CUSTOMCHAIN' call just after creating it. This -F
call is pointless, because the chain was just created and is thus empty. This
call to flush the chain that was just created is what is causing the bug.
Again, this is not the general case. Is a valid use case, indeed. But is not
something most people would use. I'm not negating the bug, but this is my
rationale for lowering the severity.

For completeness, usecase that doesn't trigger this bug:
=== 8< ===
* define a custom chain
* add a rule to that custom chain
=== 8< ===

I.e, this file:

*filter
:NEW-OUTPUT - [0:0]
-A OUTPUT -j NEW-OUTPUT
-A NEW-OUTPUT -j ACCEPT
COMMIT

This is the general case of defining and using a custom chain. This is bugfree.

>  I know that the release is happening next week, and I understand that
> it is considered too late to do anything right now - but please think
> about the impact of this for the first point release.
> 

All bugs are annoying. All bugs break someone workflow/usecase. They are bugs
for a reason :-) Severity of bugs can be put into perspective depending on how
common the workflow is, and this is clearly not a common case for the reasons
explained above.

That being said, the last upstream release contains the fix (which will be
backported to buster-backports) and I'm already working on discovering which
concrete patch fixes it for a potential inclusion into buster-stable.

Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1

[Sébastien Béhuret]

>
> For USB or FireWere disks, APM & spindown_time options are ignored,
>> other options are applied, force_spindown_time will be applied too.
>> There is bug, https://bugs.launchpad.net/bugs/515023
>> explaining why USB and FireWire drives are ignored, however the
>> situation might have improved since then.
>>
>
> I was unaware of this bug and never experienced this issue with external
> USB drives. I do remember external USB drives going into standby mode
> shortly after backup completion, but this does not occur anymore in debian
> buster/testing. The drives in question do not support APM so it makes sense
> given that -S36 is no longer applied in this case.
>

Correction: The external USB drives that used to go into standby mode were
not getting any hdparm settings (not event -S36) as they were not used on
battery mode and spindown feature is disabled by default for USB drives in
recent hdparm versions. This must have been an internal feature from WD as
documented here: https://support-en.wd.com/app/answers/detail/a_id/16047

The fact that automatic spindown does not work anymore for these drives in
buster/testing may indicate that there is some form of system noise (but
somehow this noise would not be sufficient to wake up the drives after
hdparm -y) or that something else is actively disabling automatic spindown.

Bug#857490: [PATCH] dgit-maint-bpo(7): new manpage

[Ian Jackson]

I took a look at this.

I think the merging workflow you describe will not go well if the sid
package develops changes to upstream files (through new upstream
version, or through changes to the delta queue).  Typically the
package is `3.0 (quilt)', so if there are any changes to the delta
queue, dgit patch linearisation will be needed, and it may well fail
after `git merge'.

Possible solutions may include:

 - being the maintainer in sid and knowing what your git workflow
   and branch format is and doing something workflow-specific

 - git-debcherry (blocked by #930881)

 - changing the source format

 - git-ffqrebase (does not exist yet, #869993)

 - git-debrebase convert-from-dgit-view may help in some cases;
I have used it for security updates with moderate success,
but I think repeated conversions may be troublesome

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

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

[Protesilaos Stavrou]

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

Image: 
https://protesilaos.com/assets/images/attachments/xterm_grpi_boxchars_scenario1.png

Scenario 2: Greek pi does not work, but box-drawing does


With these settings:

xterm.vt100.faceName: DejaVu Sans Mono
xterm.vt100.faceSize: 10
XTerm.vt100.forceBoxChars: true

The Greek letter pi is drawn using a fixed-size (bitmap) font.  The
second vertical line is properly displayed using box-drawing characters.

Image: 
https://protesilaos.com/assets/images/attachments/xterm_grpi_boxchars_scenario2.png

Scenario 3: faceSize: 9.5 forceBoxChars: false works for both
-

With these settings:

xterm.vt100.faceName: DejaVu Sans Mono
xterm.vt100.faceSize: 9.5
XTerm.vt100.forceBoxChars: false

Everything appears to work as intended.

Image: 
https://protesilaos.com/assets/images/attachments/xterm_grpi_boxchars_scenario3.png

Scenario 4: Fira Code works using settings from scenarios 1 and 3
-

With these:

xterm.vt100.faceName: Fira Code
xterm.vt100.faceSize: 10
XTerm.vt100.forceBoxChars: false

Or this changed:

xterm.vt100.faceSize: 9.5

Everything seems to work as intended.

Image: 
https://protesilaos.com/assets/images/attachments/xterm_grpi_boxchars_scenario4.png

Scenario 5: forceBoxChars always breaks Greek letter pi (π)
---

With these settings:

xterm.vt100.faceName: Fira Code
xterm.vt100.faceSize: 10
XTerm.vt100.forceBoxChars: true

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

Image: 
https://protesilaos.com/assets/images/attachments/xterm_grpi_boxchars_scenario5.png


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

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

Versions of packages xterm depends on:
ii  libc6   2.28-10
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3
ii  libice6 2:1.0.9-2
ii  libtinfo6   6.1+20181013-2
ii  libutempter01.1.6-3
ii  libx11-62:1.6.7-1
ii  libxaw7 2:1.0.13-1+b2
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1+b3
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+4

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

Bug#926228: update-alternatives: spurious warnings with --remove

[Marketa Calabkova]

I am afraid this bug got forgotten somehow... could you please look at
it and give some answers?



signature.asc
Description: OpenPGP digital signature

Bug#677036: latexmk does not see files read in using \verbatiminput

[Hilmar Preuße]

On 11.06.12 11:37, Norman Ramsey wrote:

Hi Norman,

> A file read using
> 
>   \verbatiminput{mumble.tex}
> 
> is not seen as a dependency.  I've confirmed by inspecting
> the database and by using the -diagnostics option.
> 
I'm failing to understand your problem. How does your input file look
like? How does latexmk behave and what would you expect instead to happen?

I've created a minimal input file:

\documentclass{article}
\usepackage{verbatim}
\begin{document}
test
\verbatiminput{mumble.tex}
\end{document}

At the end of the latexmk run I see:

=== TeX engine is 'pdfTeX'
Latexmk: Missing input file: 'mumble.tex' from line
  'No file mumble.tex.'
Latexmk: Log file says output to '677036.dvi'
Latexmk: All targets (677036.dvi) are up-to-date

IMHO this is a useful pointer to a missing file. latexmk is version 4.61.

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



signature.asc
Description: OpenPGP digital signature