Bug#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11

[Jan Gru]

Hello Adrian,
hello Samuel,

great news!

On 10.06.21 03:50, Samuel Henrique wrote:

Hello all,


Everything about this bug looks like better compiler optimization
hitting code with a latent bug, and as expected using either gcc-9
or -O2 "fixes" the problem.
Glad, that you could identify the source of the issue and find a 
workaround!
Actually I've stumbled over a similar issue regarding a fork of 
aeskeyfind a while back, but unfortunately I had not found time yet to 
check it [0].

Thank you very much for your finding and the explaination!

I have uploaded a workaround for this issue (removing the -O4 flag,
keeping -O2).
It's not an ideal solution but it's better than leaving it broken with
-O4, I will be asking the release team to unblock the migration to
testing.
I appreciate your quick patch, Samuel. Hope, that the workaround will 
find its way into frozen testing. Thanks!


The investment of the time in the autopkgtests was obviously not for 
nothing...


See you
    Jan

[0] https://github.com/makomk/aeskeyfind/issues/2

Bug#740594: xdelta3: have an upstream changelog with xdelta3

[shirish शिरीष]

At bottom :-

On 18/05/2021, Romain Porte  wrote:
> Hi,
>
> On Mon, 3 Mar 2014 15:45:20 +0530
> =?UTF-8?B?c2hpcmlzaCDgpLbgpL/gpLDgpYDgpLc=?=  wrote:
>
>> Package: xdelta3
>> Version: 3.0.8-dfsg-1
>> Severity: normal
>>
>> Dear Maintainer,
>> There is/was no upstream changelog with xdelta3. The only changelog is
>> the debian changelog which doesn't tell/share what changes were made
>> in a new release.
>
> This seems like an issue with upstream not providing a changelog. I
> think it would be quite time-consuming for the maintainer to maintain an
> upstream changelog themself. Anyway, since this package is not moving
> that much sinche 2017 or so, maybe we can close this bug (or mark as
> wontfix?).
>
> Bests,
>
> Romain.
>
> --
> To unsubscribe, send mail to 740594-unsubscr...@bugs.debian.org.
>

That is upto you, although don't think it should be that hard when you
have git log. Just having git log in a nice way would probably be more
than enough of a changelog but that is upto you. I believe it is
something like git log --pretty or some switch like that which perhaps
just needs to be outputted into changelog and gzipped.

If and when it does get updated, just get the new one on top of it
with the version number.

But again, I leave it in your expert ends as to what you think is
best. If you feel won't fix is the answer, go ahead no issues :(

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#989674: netselect-apt was unable to obtain a list of valids hosts

[Marcos Carot]

Package: netselect-apt
Version: 0.3.ds1-28.1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: marcos.ca...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
Running sudo netselect-apt
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

Script iniciado en 2021-06-10 12:18:39+08:00 [TERM="screen" TTY="/dev/pts/2" 
COLUMNS="236" LINES="55"]
marcos@Salacia:~$ sudo netselect-apt 
[sudo] password for marcos: 
Using distribution stable.
Retrieving the list of mirrors from www.debian.org...

URL transformed to HTTPS due to an HSTS policy
--2021-06-10 12:18:49--  https://www.debian.org/mirror/mirrors_full
Resolving www.debian.org (www.debian.org)... 150.203.164.62
Conectando con www.debian.org (www.debian.org)[150.203.164.62]:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 131327 (128K) [text/html]
Grabando a: «/tmp/netselect-apt.y9CvAv»

/tmp/netselect-apt.y9CvAv  
100%[>]
 128.25K   822KB/sen 0.2s

2021-06-10 12:18:49 (822 KB/s) - «/tmp/netselect-apt.y9CvAv» guardado 
[131327/131327]

Choosing a main Debian mirror using netselect.
netselect-apt was unable to obtain a list of valid hosts from
the file downloaded from the url 'http://www.debian.org/mirror/mirrors_full'.
This might happen because of any of the following reasons: 
   - there was an error in the file 
   - the file is not in the format netselect-apt expected 
   - there is a bug in netselect-apt 
Please manually check the file. If you believe its contents are correct, file 
a bug (hint: use 'reportbug') against netselect-apt and provide the file as 
well as the output generated by the program (hint: use 'script').
marcos@Salacia:~$ exit
exit

Script terminado en 2021-06-10 12:18:51+08:00 [CÓDIGO_SALIDA_ORDEN="2"]



   * What outcome did you expect instead?
A list of mirrors is dounloaded and tested for the fastest

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.12.0-9.2-liquorix-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:es:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages netselect-apt depends on:
ii  netselect  0.3.ds1-28.1
ii  wget   1.21-1+b1

Versions of packages netselect-apt recommends:
ii  curl  7.74.0-1.2

Versions of packages netselect-apt suggests:
ii  dpkg-dev  1.20.9

-- no debconf information

Bug#495015: Jour merveilleux _

[chantal durant]

C'est juste génial https://bit.ly/3v8r3LY



 chantal durant

Bug#989643: unblock: formiko/1.3.0

[Paul Wise]

Control: tags -1 - moreinfo

On Wed, Jun 9, 2021 at 5:21 PM Sebastian Ramacher wrote:

> This appears to be a pre-approval request. Please remove the moreinfo
> tag once the new version is available in unstable.

Sponsored the package.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#989673: ITP: yugabyte-db -- The high-performance distributed SQL database for global, internet-scale apps

[Mikhail Bautin]

Package: wnpp
Severity: wishlist
Owner: Mikhail Bautin 

* Package name: yugabyte-db
  Version : 2.7.1.1
  Upstream Author : YugabyteDB Authors 
* URL : https://github.com/yugabyte/yugabyte-db
* License : Apache 2.0
  Programming Lang: C, C++, Python, Java
  Description : The high-performance distributed SQL database for
global, internet-scale apps.

YugabyteDB is a high-performance, cloud-native distributed SQL database
that aims to support all PostgreSQL features. It is best to fit for
cloud-native OLTP (i.e. real-time, business-critical) applications that
need absolute data correctness and require at least one of the
following: scalability, high tolerance to failures, or
globally-distributed deployments.

We would like to contribute new releases of YugabyteDB packages to
Debian on a continuous basis.

Bug#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11

[Samuel Henrique]

Hello all,

> Everything about this bug looks like better compiler optimization
> hitting code with a latent bug, and as expected using either gcc-9
> or -O2 "fixes" the problem.

That's a great finding, thank's Adrian,

I have uploaded a workaround for this issue (removing the -O4 flag,
keeping -O2).
It's not an ideal solution but it's better than leaving it broken with
-O4, I will be asking the release team to unblock the migration to
testing.

Cheers,

-- 
Samuel Henrique 

Bug#989589: Real fix just got merged

[Roderick W. Smith]

I'm the upstream developer, and I've just released version 1.0.8, which
incorporates the fixes under discussion. This version also includes a
new feature that enables users to correct any partition name that's been
corrupted by this bug.

-- 
Rod Smith
rodsm...@rodsbooks.com

Bug#964511: Tests are failing, need to depends on the svg loader

[Paul Wise]

On Wed, 2021-06-09 at 11:00 +0200, Ondřej Tůma wrote:

> Here is fixed package in mentors, i hope right fixed...
> https://mentors.debian.net/package/formiko/

That looks good to me.

> And here is unblock request
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989643

I see the release team approved it.

I've uploaded and removed the moreinfo tag.

> And sorry for my bad fixing procedure, I'm so inexperienced
> maintainer.

No problem, everyone starts at the beginning and gets more experienced.

Thanks for maintaining formiko, I'm using it for editing my website.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#987368: Installer fails at first menu "Choose language"

[Steve McIntyre]

Argh...

Minor thing: James, please don't top-post on Debian lists. It breaks
conversation threads, particularly when others are doing inline
quoting.

On Sun, Jun 06, 2021 at 10:08:09PM +0100, James Addison wrote:
>Thanks Cyril, Frédéric - it feels like we're reaching a consensus that
>udpkg may not be multi-process safe (although, strictly speaking, I
>would say we haven't proven that yet).
>
>The authors of multi-console support could be the best people to
>recommend a path forward, as they may have close knowledge of the
>level of testing and completion of the change.  I've attempted to add
>them as subscribers to the bug although I expect that is opt-in and
>I'm not sure whether I added them correctly.

I saw nothing here, I'm afraid. But I do read debian-boot when I have
the time.

>Until any feedback from them, I'll mention a few possible routes that
>had occurred to me:
>
>- Backtracking: if we feel this is a problem that would likely affect
>and/or annoy a significant number of users, we could disable
>multi-console support for bullseye
>- Known-issue: if we feel the issue is serious but rare, we could
>indicate that it is a known problem (and perhaps prepare and document
>workarounds)
>- Scripting fix: we could perhaps adjust the installation scripts so
>that d-i runs in a single-process condition until after udpkg has
>completed, and only begin multiple debian-installer processes after
>that
>- Process-safety fix: in some sense an 'ideal' fix, we could add
>multi-process safety to udpkg, either by using careful rewriting or
>perhaps by using a lockfile or other safety mechanism(s)

Looking at the history in this bug, things are not working as we hoped
when we added the multi-console support. When I initially worked with
Wookey on this, we didn't see errors like this at all in
testing. That's not to say that there's *not* a problem here, but
maybe other changes made since then have caused it to be uncovered.

Multi-console support is a significant improvement for a number of
non-x86 users. This is particularly the case for those with arm64
systems where the firmware might default to the primary console being
a serial port but the user doesn't even know that. We wanted to be
able to start d-i on all the likely-looking consoles (serial *and* tty
*and* graphical), allowing the user to interact with the one they
preferred.

In our testing, I don't remember ever seeing udpkg invocations racing
against each other like this. But in my own testing for d-i Bullseye
RC2 in an arm64 VM here I've just seen this exact problem myself so
it's clearly a thing!

I'm looking at udpkg now to see what I can do there. I'm hoping that
it might be a reasonably quick fix use filesytem-based locking around
status file updates.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer

Bug#986001: glib2.0 2.58.3-2+deb10u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 986001 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: glib2.0
Version: 2.58.3-2+deb10u3

Explanation: fix several integer overflow issues [CVE-2021-27218 
CVE-2021-27219]; fix a symlink attack affecting file-roller [CVE-2021-28153]

Bug#989579: arm-trusted-firmware: Raspberry pi builds

[Nolan]

On 6/8/21 8:46 PM, Vagrant Cascadian wrote:

I ended up uploading to experimental with both rpi4 and rpi3. The rpi3
build instructions were confusing; hopefully the defaults are
reasonable.

Please test it when you get a chance!


Awesome, thanks for putting this together!

Not a comprehensive test, but it boots to u-boot and then on to Linux 
userspace on my pi4. Adds a few seconds to boot time, which is more than 
I expected, but also perfectly fine.


I don't have a pi3 handy, so I tried qemu's raspi3b machine type, using 
"-bios bl31.bin". Qemu segfaulted pretty much instantly in 
arm_setup_firmware_boot trying to set the kernel commandline in fw_cfg. 
This probably doesn't tell us much about how well it would work on a 
real pi3...


- nolan

Bug#989645: /usr/sbin/grub-mkconfig: dpkg: error processing package linux-image-powerpc (--configure):

[Colin Watson]

On Wed, Jun 09, 2021 at 02:34:06PM -0700, Rick Thomas wrote:
> You're right that /boot/grub somehow has gotten read-only.  I didn't
> do that myself, so something else must have done that.  Have you any
> clue you can share with me as to which package I should re-file this
> report against?

I'm afraid I have no idea.  You might find something of use in syslog or
dmesg?

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#989594: golang-github-masterminds-semver-dev: Outdated package

[陳昌倬]

On Wed, Jun 09, 2021 at 07:06:49PM +, Peymaneh Nejad wrote:
> Please let me now if you have concerns with this procedure.

No problem for me. Thanks for the help


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#989672: openshot: fails to import normal DVB-S recordings (MPEG2)

[Norbert Pechiny]

Package: openshot
Version: 2.4.3+dfsg1-1
Severity: normal

Dear Maintainer,

after upgrading to Buster AMD64, openshot does not import DVB-S recordings
(*.ts MPEG2-files) any more. The aspect ratio seems to be wrong and sound is
just a strange noise.

On an fresh Buster install the situation is the same. I can use kdenlive
instead with the same recordings and it works fine (but I'd prefer using
openshot if it only worked).

Those problems were not present on Debian 9. So I have no idea how to fix it. I
would like to stick to Debian stable. So a bugfix would be great. My workaroud
for now is using kdenlive.

Kind regards,
Norbert




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

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

Versions of packages openshot depends on:
ii  openshot-qt  2.4.3+dfsg1-1

openshot recommends no packages.

openshot suggests no packages.

-- no debconf information

Bug#989645: /usr/sbin/grub-mkconfig: dpkg: error processing package linux-image-powerpc (--configure):

[Rick Thomas]

On Wed, Jun 9, 2021, at 3:15 AM, John Paul Adrian Glaubitz wrote:
> Control: severity -1 normal
> 
> Hello Rick!
> 
> On 6/9/21 11:15 AM, Rick Thomas wrote:
> > Package: grub-common
> > Version: 2.04-18
> > Severity: grave
> > File: /usr/sbin/grub-mkconfig
> > Justification: renders package unusable
> 
> Since powerpc is not a release architecture, setting the severity to 
> "grave" is not
> allowed here. I am therefore downgrading this to "normal".
> 

Got it.  Thanks for the info!

> > This is what happens when I attempt to do "aptitude full-upgrade" on my 
> > PowerPC machine:
> > 
> > root@dillserver:/home/rbthomas# aptitude full-upgrade
> > The following partially installed packages will be configured:
> >   linux-image-5.10.0-7-powerpc linux-image-powerpc 
> > No packages will be installed, upgraded, or removed.
> > 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> > Need to get 0 B of archives. After unpacking 0 B will be used.
> > Setting up linux-image-5.10.0-7-powerpc (5.10.40-1) ...
> > /etc/kernel/postinst.d/initramfs-tools:
> > update-initramfs: Generating /boot/initrd.img-5.10.0-7-powerpc
> > /etc/kernel/postinst.d/zz-update-grub:
> > /usr/sbin/grub-mkconfig: 257: cannot create /boot/grub/grub.cfg.new: 
> > Read-only file system
> 
> Your HFS filesystem on /boot/grub is read-only. This is not related to GRUB 
> but
> to either your custom environment or something in the partitioning setup in 
> d-i
> that I need to fix.
> 
> Adrian

This happened on two machines (a G5 Mac and a G4 Mac), both of which were 
originally installed from the respective NETINST-1 iso from 2021-02-02.  For 
specificity, here are the checksums of the iso images:

9745c507771d6066546146c3d33755ac3b1ca0d4d489647d6a07da38c9612bfc  
debian-10.0.0-powerpc-NETINST-1.iso
cf357436e812b50ee8c381abf61c0f7ff634c5bdfd18f4ea8b55a4230a657f00  
debian-10.0.0-ppc64-NETINST-1.iso

I have run occasional (roughly weekly) "aptitude update ; aptitude 
full-upgrade" on each of them since installation.

I did nothing to affect the read-write-ability of /boot/grub on either of them. 
 So I'm guessing this is a bug you need to fix?

What can I do to help?  (Both of these machines exist at the moment solely to 
assist in testing your efforts, so I would have no problem re-installing either 
or both if that would help.)

Thanks for all your work!
Rick

Bug#989667: unblock: policykit-1/0.105-31

[Simon McVittie]

On Wed, 09 Jun 2021 at 21:19:45 +0200, Salvatore Bonaccorso wrote:
> The upload to unstable, 0.105-31, fixes CVE-2021-3560, cf. #989429 a
> local privilege escalation vulnerability affecting bullseye due to
> 0.113 patches backported in 0.105-26.

Just to confirm for the release team: yes, I did intend this upload to
be targeted for inclusion in bullseye (I know some maintainers do upload
things not intended to migrate into unstable even during the freeze,
but I don't). I'd forgotten to do the unblock request, thanks for picking
that up!

smcv

Bug#989671: kontact: Trying to archive a Mail folder makes it crash

[Diederik de Haas]

Package: kontact
Version: 4:21.04.1-1
Severity: important

I'm filing it against kontact, but kmail is maybe more appropriate.
However with kontact I could generate a stacktrace, which failed with
kmail, so therefor I chose kontact. Feel free to reassign.

In 'Local Folder' I have a Mail-Achive folder with 2 subfolders 
for 2 of my mail accounts.
Earlier today I moved a bunch of mails from my (IMAP) account to the
corresponding Mail-Archive folder and that seems to went fine.
When you right-click on a folder, you can choose 'Archive Folder...' to
make an export of that folder to a .tar.bz2 file and I use that for
backup purposes. It starts the process (no idea where the/a temp file is
created though) and then at some point it crashes.

=== KCrash output 1 ===
Application: Kontact (kontact), signal: Aborted

[KCrash Handler]
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#5  0x7fe28cc98537 in __GI_abort () at abort.c:79
#6  0x7fe28ced27ec in __gnu_cxx::__verbose_terminate_handler () at 
../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95
#7  0x7fe28cedd966 in __cxxabiv1::__terminate (handler=) at 
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:48
#8  0x7fe28cedd9d1 in std::terminate () at 
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:58
#9  0x7fe28ceddc65 in __cxxabiv1::__cxa_throw 
(obj=obj@entry=0x55c80b21ebd0, tinfo=0x7fe1d83ef348 , dest=0x7fe1d82b01f0 
) at 
../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:95
#10 0x7fe1d8265b41 in Akonadi::Item::throwPayloadException 
(this=this@entry=0x55c818322738, spid=spid@entry=-1, mtid=mtid@entry=-1) at 
./src/core/item.cpp:463
#11 0x7fe1b900ae92 in Akonadi::Item::payload 
> (this=0x55c818322738) at /usr/include/KF5/AkonadiCore/item.h:791
#12 MailCommon::BackupJob::processMessage (this=0x7fe270009790, item=...) at 
./src/job/backupjob.cpp:232
#13 0x7fe1b900b048 in MailCommon::BackupJob::itemFetchJobResult 
(this=0x7fe270009790, job=0x7ffef3a31cd0) at ./src/job/backupjob.cpp:271
#14 0x7fe28d2eb5a6 in QtPrivate::QSlotObjectBase::call (a=0x7ffef3a31e20, 
r=0x7fe270009790, this=0x55c8016c4130) at 
../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#15 doActivate (sender=0x7fe19c46a4b0, signal_index=6, 
argv=argv@entry=0x7ffef3a31e20) at kernel/qobject.cpp:3886
#16 0x7fe28d2e4900 in QMetaObject::activate 
(sender=sender@entry=0x7fe19c46a4b0, m=m@entry=0x7fe28e40dca0 
, local_signal_index=local_signal_index@entry=3, 
argv=argv@entry=0x7ffef3a31e20) at kernel/qobject.cpp:3946
#17 0x7fe28e3b76fc in KJob::result (this=this@entry=0x7fe19c46a4b0, 
_t1=, _t1@entry=0x7fe19c46a4b0, _t2=...) at 
./obj-x86_64-linux-gnu/src/lib/KF5CoreAddons_autogen/include/moc_kjob.cpp:636
#18 0x7fe28e3b8433 in KJob::finishJob (this=0x7fe19c46a4b0, 
emitResult=) at ./src/lib/jobs/kjob.cpp:94
#19 0x7fe28d2e0ff1 in QObject::event (this=0x7fe19c46a4b0, 
e=0x55c80c32d5d0) at kernel/qobject.cpp:1314
#20 0x7fe28dd7715f in QApplicationPrivate::notify_helper (this=, receiver=0x7fe19c46a4b0, e=0x55c80c32d5d0) at kernel/qapplication.cpp:3632
#21 0x7fe28d2b4fca in QCoreApplication::notifyInternal2 
(receiver=0x7fe19c46a4b0, event=0x55c80c32d5d0) at 
kernel/qcoreapplication.cpp:1063
#22 0x7fe28d2b7a01 in QCoreApplicationPrivate::sendPostedEvents 
(receiver=0x0, event_type=0, data=0x55c7ff9a28f0) at 
kernel/qcoreapplication.cpp:1817
#23 0x7fe28d30ce93 in postEventSourceDispatch (s=0x55c7ffadae00) at 
kernel/qeventdispatcher_glib.cpp:277
#24 0x7fe2836e1e6b in g_main_dispatch (context=0x7fe270005000) at 
../../../glib/gmain.c:3325
#25 g_main_context_dispatch (context=0x7fe270005000) at 
../../../glib/gmain.c:4043
#26 0x7fe2836e2118 in g_main_context_iterate 
(context=context@entry=0x7fe270005000, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4119
#27 0x7fe2836e21cf in g_main_context_iteration (context=0x7fe270005000, 
may_block=may_block@entry=1) at ../../../glib/gmain.c:4184
#28 0x7fe28d30c51f in QEventDispatcherGlib::processEvents 
(this=0x55c7ffadbd60, flags=...) at kernel/qeventdispatcher_glib.cpp:423
#29 0x7fe28d2b398b in QEventLoop::exec (this=this@entry=0x7ffef3a32210, 
flags=..., flags@entry=...) at 
../../include/QtCore/../../src/corelib/global/qflags.h:69
#30 0x7fe28d2bbc00 in QCoreApplication::exec () at 
../../include/QtCore/../../src/corelib/global/qflags.h:121
#31 0x55c7fe2cb02b in main (argc=, argv=) at 
./src/main.cpp:208
[Inferior 1 (process 2390) detached]

=== end KCrash output 1 ===

Then I rebooted my machine and tried again. And it crashed again:

=== KCrash output 2 ===
Application: Kontact (kontact), signal: Aborted

[KCrash Handler]
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#5  0x7f2bfb2e2537 in __GI_abort () at abort.c:79
#6  0x7f2bfb51c7ec in __gnu_cxx::__verbose_terminate_handler () at 
../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95
#7  

Bug#989657: Current sogo-connector does not work with current Mozilla Thunderbird

[Carsten Schoenert]

Hello Narcis,

Am Wed, Jun 09, 2021 at 05:17:39PM +0200 schrieb Narcis Garcia:
 
> thunderbird(68) + lightning(68) + webext-sogo-connector(68) do show
> "Subscribe to addressbook" button at Address book page.
> I suppose webext-sogo-connector needs to be packaged as version(78)
> compatible with thunderird 78.

if upstream would release a newer version than the current avialable I'm
happy to package it.

https://github.com/inverse-inc/sogo-connector

But there isn't any newer version than the one in the archive released
by upstream in between. So it's probably better to remove the current
package from the archive.

Regards
Carsten

Bug#983712: RFS: lebiniou/3.55.0-1 -- user-friendly, powerful music visualization / VJing tool

[Olivier Girondel]

On 6/9/21 8:48 PM, Tobias Frost wrote:

Control: tags -1 moreinfo

Hi Olivier,

just for some quick feedback,

As we are currently frozen and an upload to unstable of a new upstream version
is a bit out of scope right now:
Do you want to target experimental or do you want wait for the bullseye release?

It seems that upstream has released 3.56 in the meantime, so depending on
the above question, do you want to update to that new version as well?

(I did not look at the package yet, just soliciating that feedback)

(Formally tagging moreinfo as this needs feedback and is not actionable until
then… Just remove the tag when ready for a review and I try to reserve time for
it.)


Hi Tobias,

Well this RFS is 4 months old, so yes it's a little late for it to reach 
bullseye :)


We're about to relase 3.60 soon anyway, so depending on bullseye's 
release date (do you have some idea btw ?) it might be possible that I 
close these RFS.


Question: in case 3.55 and 3.56 never make it in Debian, should I remove 
the entries from d/changelog ?


Thanks !

--
Olivier

Bug#989669: mali-t76x-x11-driver is not installable (armhf)

[Wookey]

On 2021-06-09 22:46 +0300, Andrew M wrote:

>  The following packages have unmet dependencies:
>   mali-t76x-x11-driver:armhf : Depends: mali-midgard-dkms:armhf but it is not 
> installable
>  E: Unable to correct problems, you have held broken packages.

Hmm. Sorry that's not working. The mali binary drivers have now been
removed from Debian because they are superseded by the panfrost free
driver, and were never much practical use anyway.
https://wiki.debian.org/PanfrostLima

The binary drivers only ever worked on small subset of hardware
because of the way the binary driver was designed. They worked on
Firefly boards, and maybe some others but I'm not aware of any
demonstrations of that.

>  but there is mali-midgard-dkms with all architecture and it is installable

Hmm, there does seem to be some kind of multiarch problem
there. mali-midgard-dkms has always been arch:all. I'm not sure what's
gone wrong to produce the failing dependency, but I don't think there
is much point investigating at this stage. Sorry.

That package too is pending removal.

What did you hope to use it for?

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#989670: azure-cli: az network commands throw ImportError

[Alexis]

Package: azure-cli
Version: 2.18.0-2
Severity: important

When trying to use any az network commands, an error is thrown and the command
fails. For example, "az network dns zone list" gives this output:

CLIInternalError: The command failed with an unexpected error. Here is the
traceback:
cannot import name 'BatchManagementClient' from 'azure.mgmt.batch'
(/usr/lib/python3/dist-packages/azure/mgmt/batch/__init__.py)
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/knack/cli.py", line 233, in invoke
cmd_result = self.invocation.execute(args)
  File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py",
line 558, in execute
self.commands_loader.load_arguments(command)
  File "/usr/lib/python3/dist-packages/azure/cli/core/__init__.py", line 481,
in load_arguments
loader.load_arguments(command)  # this adds entries to the argument
registries
  File "/usr/lib/python3/dist-
packages/azure/cli/command_modules/network/__init__.py", line 39, in
load_arguments
load_arguments(self, command)
  File "/usr/lib/python3/dist-
packages/azure/cli/command_modules/network/_params.py", line 2000, in
load_arguments
from
azure.cli.command_modules.network.private_link_resource_and_endpoint_connections.custom
import TYPE_CLIENT_MAPPING, register_providers
  File "/usr/lib/python3/dist-
packages/azure/cli/command_modules/network/private_link_resource_and_endpoint_connections/custom.py",
line 9, in 
from .resource_providers.batch_provider import BatchPrivateEndpointClient
  File "/usr/lib/python3/dist-
packages/azure/cli/command_modules/network/private_link_resource_and_endpoint_connections/resource_providers/batch_provider.py",
line 6, in 
from azure.mgmt.batch import BatchManagementClient
ImportError: cannot import name 'BatchManagementClient' from 'azure.mgmt.batch'
(/usr/lib/python3/dist-packages/azure/mgmt/batch/__init__.py)
To open an issue, please run: 'az feedback'

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

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

Versions of packages azure-cli depends on:
ii  python33.9.2-3
ii  python3-azure-cli  2.18.0-2

azure-cli recommends no packages.

azure-cli suggests no packages.

Bug#989659: initramfs-tools: error when /etc/initramfs-tools/scripts inexistent

[Mathias BOCQUET]

Package: initramfs-tools
Version: 0.140
Severity: normal
X-Debbugs-Cc: m...@sekoya.org

Dear Maintainer,

During an apt installation :

apt install dmraid gpart jfsutils kpartx reiser4progs reiserfsprogs udftools

this error dropped during process :

 Processing triggers for initramfs-tools (0.140) ...
 update-initramfs: Generating /boot/initrd.img-5.10.0-6-amd64
 /usr/sbin/mkinitramfs: 329: cd: can't cd to /etc/initramfs-tools/scripts

I created this folder : mkdir /etc/initramfs-tools/scripts
ran : update-initramfs -u

The error is gone.

Perhaps this folder needs to be checked for existence and create it somewhere 
in initramfs-tools related scripts ?

-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 23M May 17 09:52 /boot/initrd.img-5.10.0-6-amd64
-rw-r--r-- 1 root root 23M Jun  9 16:51 /boot/initrd.img-5.10.0-7-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.10.0-7-amd64 root=/dev/mapper/sys-root ro quiet 
intel_iommu=on

-- resume
RESUME=/dev/mapper/sys-swap_1
-- /proc/filesystems
ext3
ext2
ext4
fuseblk
vfat
xfs

-- lsmod
Module  Size  Used by
cpuid  16384  0
nouveau  2326528  1
mxm_wmi16384  1 nouveau
ttm   114688  1 nouveau
ctr16384  2
ccm20480  6
rfcomm 90112  0
xt_conntrack   16384  1
nft_chain_nat  16384  3
xt_MASQUERADE  20480  1
nf_nat 53248  2 nft_chain_nat,xt_MASQUERADE
nf_conntrack_netlink57344  0
nf_conntrack  176128  4 
xt_conntrack,nf_nat,nf_conntrack_netlink,xt_MASQUERADE
nf_defrag_ipv6 24576  1 nf_conntrack
nf_defrag_ipv4 16384  1 nf_conntrack
xfrm_user  45056  1
xfrm_algo  16384  1 xfrm_user
nft_counter16384  15
xt_addrtype16384  2
nft_compat 20480  4
nf_tables 245760  43 nft_compat,nft_counter,nft_chain_nat
nfnetlink  16384  4 nft_compat,nf_conntrack_netlink,nf_tables
br_netfilter   32768  0
bridge253952  1 br_netfilter
stp16384  1 bridge
llc16384  2 bridge,stp
cmac   16384  11
overlay   143360  0
algif_hash 16384  5
algif_skcipher 16384  5
af_alg 32768  22 algif_hash,algif_skcipher
bnep   28672  2
hid_logitech_hidpp 49152  0
intel_pmc_core_pltdrv16384  0
intel_pmc_core 45056  0
xfs  1773568  1
iTCO_wdt   16384  0
snd_soc_skl_hda_dsp28672  5
rtsx_pci_sdmmc 32768  0
intel_pmc_bxt  16384  1 iTCO_wdt
snd_soc_hdac_hdmi  45056  1 snd_soc_skl_hda_dsp
mei_wdt16384  0
iTCO_vendor_support16384  1 iTCO_wdt
snd_soc_dmic   16384  1
mei_hdcp   24576  0
libcrc32c  16384  4 nf_conntrack,nf_nat,nf_tables,xfs
ee1004 20480  0
mmc_core  188416  1 rtsx_pci_sdmmc
watchdog   28672  2 iTCO_wdt,mei_wdt
intel_rapl_msr 20480  0
sparse_keymap  16384  0
intel_wmi_thunderbolt20480  0
snd_hda_codec_realtek   151552  1
wmi_bmof   16384  0
snd_hda_codec_generic98304  1 snd_hda_codec_realtek
snd_sof_pci24576  0
x86_pkg_temp_thermal20480  0
snd_sof_intel_byt  24576  1 snd_sof_pci
intel_powerclamp   20480  0
snd_sof_intel_ipc  20480  1 snd_sof_intel_byt
coretemp   20480  0
snd_hda_codec_hdmi 73728  2
snd_sof_intel_hda_common   102400  1 snd_sof_pci
snd_sof_xtensa_dsp 16384  2 snd_sof_intel_hda_common,snd_sof_intel_byt
snd_sof   139264  4 
snd_sof_pci,snd_sof_intel_hda_common,snd_sof_intel_byt,snd_sof_intel_ipc
kvm_intel 327680  0
snd_sof_intel_hda  20480  1 snd_sof_intel_hda_common
snd_soc_hdac_hda   24576  1 snd_sof_intel_hda_common
snd_hda_ext_core   36864  4 
snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_soc_hdac_hda,snd_sof_intel_hda
snd_soc_acpi_intel_match45056  2 snd_sof_pci,snd_sof_intel_hda_common
snd_soc_acpi   16384  3 
snd_soc_acpi_intel_match,snd_sof_intel_hda_common,snd_sof_intel_byt
kvm   917504  1 kvm_intel
snd_hda_intel  57344  2
iwlmvm339968  0
snd_intel_dspcfg   28672  3 
snd_hda_intel,snd_sof_pci,snd_sof_intel_hda_common
btusb  61440  0
btrtl  24576  1 btusb
soundwire_intel45056  2 snd_sof_intel_hda_common,snd_intel_dspcfg
btbcm  20480  1 btusb
btintel32768  1 btusb
soundwire_generic_allocation16384  1 soundwire_intel
irqbypass  16384  1 kvm
mac80211  983040  1 iwlmvm
bluetooth 737280  33 btrtl,btintel,btbcm,bnep,btusb,rfcomm
crc32_pclmul   16384  0
snd_soc_core  315392  7 

Bug#989669: mali-t76x-x11-driver is not installable (armhf)

[Andrew M]

Package: mali-t76x-x11-driver
Version: 0.1-3

When I try to install it says

root@orangepi3:~# apt-get install mali-t76x-x11-driver
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 mali-t76x-x11-driver:armhf : Depends: mali-midgard-dkms:armhf but it
is not installable
E: Unable to correct problems, you have held broken packages.


root@orangepi3:~# apt-cache policy mali-midgard-dkms
mali-midgard-dkms:
  Installed: 16.0+pristine-4
  Candidate: 16.0+pristine-4
  Version table:
 *** 16.0+pristine-4 500
500 http://mirrors.tuna.tsinghua.edu.cn/debian buster/contrib
arm64 Packages
500 http://mirrors.tuna.tsinghua.edu.cn/debian buster/contrib
armhf Packages
100 /var/lib/dpkg/status

but there is mali-midgard-dkms with all architecture and it is installable

root@orangepi3:~# dpkg -l mali-midgard-dkms
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture Description
+++-=-===--===
ii  mali-midgard-dkms 16.0+pristine-4 all  Mali kernel driver
for midgard hardware in DKMS format.



system information:

root@orangepi3:~# cat /etc/debian_version
10.9

Bug#980311: some more debug output needed

[Wolfram Sang]

Hi,

> > SANE_DEBUG_GT68XX=5 scanimage -L

Could you kindly also provide this output?

SANE_DEBUG_GT68XX=5 SANE_DEBUG_DLL=3 scanimage -L

Let's hope this will bring something new...

Kind regards,

   Wolfram



signature.asc
Description: PGP signature

Bug#989668: buster-pu: package isync/1.3.0-2.2~deb10u1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: car...@debian.org

Hi Stable release managers,

I would like to propose to include in the upcoming point release an
isync update, versioned as 1.3.0-2.2~deb10u1, which is a rebuild of
the version in unstable containing two CVE fixes.

I decided to opt for the rebuild including the CVE fixes because the
only other change in 1.3.0-2.1 was the debian/watch switch to the
https URL.

[ Reason ]
Fix for CVE-2021-3578 and CVE-2021-20247 for buster.

[ Impact ]
We keep CVE-2021-3578 and CVE-2021-20247 affecting buster. The CVEs on
the other hand are not warranting a DSA.

[ Tests ]
None specifically.

[ Risks ]
We apply the same changes as in unstable, and TTBOMK no regression
reports were reported. The update was acked to be unblocked to
testing.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Apply the upstream fixes for CVE-2021-3578 and CVE-2021-20247,
additionally Ondrej Novy updated the debian/watch used URL to use
HTTPS.

[ Other info ]
None

Regards,
Salvatore
diff -Nru isync-1.3.0/debian/changelog isync-1.3.0/debian/changelog
--- isync-1.3.0/debian/changelog2018-09-02 19:31:35.0 +0200
+++ isync-1.3.0/debian/changelog2021-06-09 21:21:48.0 +0200
@@ -1,3 +1,31 @@
+isync (1.3.0-2.2~deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for buster
+
+ -- Salvatore Bonaccorso   Wed, 09 Jun 2021 21:21:48 +0200
+
+isync (1.3.0-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * fix handling of unexpected APPENDUID response code (CVE-2021-3578)
+(Closes: #989564)
+
+ -- Salvatore Bonaccorso   Mon, 07 Jun 2021 21:03:56 +0200
+
+isync (1.3.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Ondřej Nový ]
+  * d/watch: Use https protocol
+
+  [ Salvatore Bonaccorso ]
+  * reject funny mailbox names from IMAP LIST/LSUB (CVE-2021-20247)
+(Closes: #983351)
+
+ -- Salvatore Bonaccorso   Mon, 22 Feb 2021 21:09:21 +0100
+
 isync (1.3.0-2) unstable; urgency=medium
 
   * Update vcs-* to point to salsa.d.o
diff -Nru 
isync-1.3.0/debian/patches/fix-handling-of-unexpected-APPENDUID-response-code--1.3.patch
 
isync-1.3.0/debian/patches/fix-handling-of-unexpected-APPENDUID-response-code--1.3.patch
--- 
isync-1.3.0/debian/patches/fix-handling-of-unexpected-APPENDUID-response-code--1.3.patch
1970-01-01 01:00:00.0 +0100
+++ 
isync-1.3.0/debian/patches/fix-handling-of-unexpected-APPENDUID-response-code--1.3.patch
2021-06-09 21:21:48.0 +0200
@@ -0,0 +1,80 @@
+From 5fbed519180f155a017a438e479b6268b74b9526 Mon Sep 17 00:00:00 2001
+From: Oswald Buddenhagen 
+Date: Wed, 14 Apr 2021 16:58:27 +0200
+Subject: [PATCH] fix handling of unexpected APPENDUID response code
+
+if the code was sent in response to anything but a STORE, we'd overwrite
+a data pointer in one of our imap_cmd subclasses, an allocator data
+structure, or the start of the next allocation, with an int that was
+completely under the server's control. it's plausible that this could be
+exploited for remote code execution.
+
+to avoid this, we could ensure that the object is of the right type
+prior to casting, by using a new flag in the parameter block. but it's
+easier to just dispose of the out_uid field altogether and reuse the uid
+field that is present in the parameter block anyway, but was used only
+for FETCH commands so far.
+
+this problem was found by Lukas Braun  using a
+fuzzer.
+---
+ src/drv_imap.c | 19 ++-
+ 1 file changed, 14 insertions(+), 5 deletions(-)
+
+diff --git a/src/drv_imap.c b/src/drv_imap.c
+index fbe2fed..4cc3b2a 100644
+--- a/src/drv_imap.c
 b/src/drv_imap.c
+@@ -181,7 +181,6 @@ typedef struct {
+   imap_cmd_t gen;
+   void (*callback)( int sts, uint uid, void *aux );
+   void *callback_aux;
+-  uint out_uid;
+ } imap_cmd_out_uid_t;
+ 
+ typedef struct {
+@@ -1184,11 +1183,22 @@ parse_response_code( imap_store_t *ctx, imap_cmd_t 
*cmd, char *s )
+*/
+   for (; isspace( (uchar)*p ); p++);
+   error( "*** IMAP ALERT *** %s\n", p );
+-  } else if (cmd && !strcmp( "APPENDUID", arg )) {
++  } else if (!strcmp( "APPENDUID", arg )) {
++  // The checks ensure that:
++  // - cmd => this is the final tagged response of a command, at 
which
++  //   point cmd was already removed from ctx->in_progress, so 
param.uid
++  //   is available for reuse.
++  // - !param.uid => the command isn't actually a FETCH. This 
doesn't
++  //   really matter, as the field is safe to overwrite given the
++  //   previous condition; it just has no effect for non-APPENDs.
++ 

Bug#989667: unblock: policykit-1/0.105-31

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: car...@debian.org,s...@pseudorandom.co.uk

Hi Release team

Please unblock package policykit-1

[ Reason ]
The upload to unstable, 0.105-31, fixes CVE-2021-3560, cf. #989429 a
local privilege escalation vulnerability affecting bullseye due to
0.113 patches backported in 0.105-26.

[ Impact ]
Unfixed local privilege escalation issue unfixed in bullseye.

[ Tests ]
None specifically.

[ Risks ]
Low, IMHO, the patch is very isolated to the change in
polkit_system_bus_name_get_creds_sync().

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
None.

unblock policykit-1/0.105-31

Regards,
Salvatore
diff -Nru policykit-1-0.105/debian/changelog policykit-1-0.105/debian/changelog
--- policykit-1-0.105/debian/changelog  2021-02-04 14:56:09.0 +0100
+++ policykit-1-0.105/debian/changelog  2021-06-03 18:06:34.0 +0200
@@ -1,3 +1,13 @@
+policykit-1 (0.105-31) unstable; urgency=medium
+
+  [ Salvatore Bonaccorso ]
+  * d/p/CVE-2021-3560.patch:
+Fix local privilege escalation involving
+polkit_system_bus_name_get_creds_sync() (CVE-2021-3560)
+(Closes: #989429)
+
+ -- Simon McVittie   Thu, 03 Jun 2021 17:06:34 +0100
+
 policykit-1 (0.105-30) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru policykit-1-0.105/debian/patches/CVE-2021-3560.patch 
policykit-1-0.105/debian/patches/CVE-2021-3560.patch
--- policykit-1-0.105/debian/patches/CVE-2021-3560.patch1970-01-01 
01:00:00.0 +0100
+++ policykit-1-0.105/debian/patches/CVE-2021-3560.patch2021-06-03 
18:06:34.0 +0200
@@ -0,0 +1,22 @@
+Description: local privilege escalation using 
polkit_system_bus_name_get_creds_sync()
+Origin: upstream
+Bug: https://gitlab.freedesktop.org/polkit/polkit/-/issues/140
+Bug-Debian: https://bugs.debian.org/989429
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-3560
+Forwarded: not-needed
+Author: Salvatore Bonaccorso 
+Last-Update: 2021-06-03
+
+--- a/src/polkit/polkitsystembusname.c
 b/src/polkit/polkitsystembusname.c
+@@ -435,6 +435,9 @@ polkit_system_bus_name_get_creds_sync (PolkitSystemBusName 
  *system_bus
+   while (!((data.retrieved_uid && data.retrieved_pid) || data.caught_error))
+ g_main_context_iteration (tmp_context, TRUE);
+ 
++  if (data.caught_error)
++goto out;
++
+   if (out_uid)
+ *out_uid = data.uid;
+   if (out_pid)
+
diff -Nru policykit-1-0.105/debian/patches/series 
policykit-1-0.105/debian/patches/series
--- policykit-1-0.105/debian/patches/series 2021-02-04 14:56:09.0 
+0100
+++ policykit-1-0.105/debian/patches/series 2021-06-03 18:06:34.0 
+0200
@@ -60,3 +60,4 @@
 Move-D-Bus-policy-file-to-usr-share-dbus-1-system.d.patch
 Statically-link-libpolkit-backend1-into-polkitd.patch
 Remove-example-null-backend.patch
+CVE-2021-3560.patch

Bug#989605: mirror submission for mirror.alwyzon.net

[Peter Palfrader]

On Tue, 08 Jun 2021, Michael Hohl wrote:

> Sure, I'm just not sure why you would think that Alwyzon.com runs on
> one Nameserver? There are two nameservers, ns1.alwyzon.net and
> ns3.alwyzon.net (for historical reasons, there is no longer a ns2).
> Both have IPv4 addresses assigned and run in geographically separate
> locations (Austria and the Netherlands):

However, your mirror is in the alwyzon.net domain:

;; AUTHORITY SECTION:
alwyzon.net.172800  IN  NS  ns1.hohl.it.
alwyzon.net.172800  IN  NS  ns2.hohl.it.

And when I checked yesterday, I only got an A record for one of them.
Seems that has changed now.

> Btw. your mail setup seems a bit off: the email has a "Reply-To: Debian
> Mirror Team <989...@debian.org>" header set, but that address doesn't seem to
> exist.

Thanks.  Badly hand-edited. :)

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#989624: golang-github-klauspost-cpuid-dev: Outdated package

[Peymaneh Nejad]

Hello,

Am 09.06.21 um 01:22 schrieb Peymaneh Nejad:

Package: golang-github-klauspost-cpuid-dev

I wish to package github.com/caddyserver/certmagic[1] which
depends on v2.0.6 of this library.


As this would be a major version change, it was proposed on the debian-go 
mailing list to upload v2 of this package to experimental until the freeze is done.




For that I would write the respective changes to a new debian/experimental 
branch on the salsa repo.




Please let me now if you have concerns this procedure.



kind regards

Peymaneh

Bug#989662: connman: diff for NMU version 1.36-2.2

[Salvatore Bonaccorso]

Control: tags 989662 + patch
Control: tags 989662 + pending


Dear maintainer,

I've prepared an NMU for connman (versioned as 1.36-2.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Alf, this is sort of not respecting the rules for NMU, my goal here
would be to make it possible to make as well an update for buster in
time. So if you agree I would even shorten the delay.

If you want to override the upload this is obviously perfectly fine!

Regards,
Salvatore
diff -Nru connman-1.36/debian/changelog connman-1.36/debian/changelog
--- connman-1.36/debian/changelog	2021-02-05 14:42:50.0 +0100
+++ connman-1.36/debian/changelog	2021-06-09 20:48:07.0 +0200
@@ -1,3 +1,11 @@
+connman (1.36-2.2) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * dnsproxy: Check the length of buffers before memcpy (CVE-2021-33833)
+(Closes: #989662)
+
+ -- Salvatore Bonaccorso   Wed, 09 Jun 2021 20:48:07 +0200
+
 connman (1.36-2.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru connman-1.36/debian/patches/dnsproxy-Check-the-length-of-buffers-before-memcpy.patch connman-1.36/debian/patches/dnsproxy-Check-the-length-of-buffers-before-memcpy.patch
--- connman-1.36/debian/patches/dnsproxy-Check-the-length-of-buffers-before-memcpy.patch	1970-01-01 01:00:00.0 +0100
+++ connman-1.36/debian/patches/dnsproxy-Check-the-length-of-buffers-before-memcpy.patch	2021-06-09 20:46:50.0 +0200
@@ -0,0 +1,68 @@
+From: Valery Kashcheev 
+Date: Mon, 7 Jun 2021 18:58:24 +0200
+Subject: dnsproxy: Check the length of buffers before memcpy
+Origin: https://git.kernel.org/pub/scm/network/connman/connman.git/commit?id=eceb2e8d2341c041df55a5e2f047d9a8c491463c
+Bug-Debian: https://bugs.debian.org/989662
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-33833
+
+Fix using a stack-based buffer overflow attack by checking the length of
+the ptr and uptr buffers.
+
+Fix debug message output.
+
+Fixes: CVE-2021-33833
+---
+ src/dnsproxy.c | 20 +++-
+ 1 file changed, 11 insertions(+), 9 deletions(-)
+
+diff --git a/src/dnsproxy.c b/src/dnsproxy.c
+index de52df5ad0a0..38dbdd71e425 100644
+--- a/src/dnsproxy.c
 b/src/dnsproxy.c
+@@ -1788,17 +1788,15 @@ static char *uncompress(int16_t field_count, char *start, char *end,
+ 		 * tmp buffer.
+ 		 */
+ 
+-		debug("pos %d ulen %d left %d name %s", pos, ulen,
+-			(int)(uncomp_len - (uptr - uncompressed)), uptr);
+-
+-		ulen = strlen(name);
+-		if ((uptr + ulen + 1) > uncomp_end) {
++		ulen = strlen(name) + 1;
++		if ((uptr + ulen) > uncomp_end)
+ 			goto out;
+-		}
+-		strncpy(uptr, name, uncomp_len - (uptr - uncompressed));
++		strncpy(uptr, name, ulen);
++
++		debug("pos %d ulen %d left %d name %s", pos, ulen,
++			(int)(uncomp_end - (uptr + ulen)), uptr);
+ 
+ 		uptr += ulen;
+-		*uptr++ = '\0';
+ 
+ 		ptr += pos;
+ 
+@@ -1841,7 +1839,7 @@ static char *uncompress(int16_t field_count, char *start, char *end,
+ 		} else if (dns_type == ns_t_a || dns_type == ns_t_) {
+ 			dlen = uptr[-2] << 8 | uptr[-1];
+ 
+-			if (ptr + dlen > end) {
++			if ((ptr + dlen) > end || (uptr + dlen) > uncomp_end) {
+ debug("data len %d too long", dlen);
+ goto out;
+ 			}
+@@ -1880,6 +1878,10 @@ static char *uncompress(int16_t field_count, char *start, char *end,
+ 			 * refresh interval, retry interval, expiration
+ 			 * limit and minimum ttl). They are 20 bytes long.
+ 			 */
++			if ((uptr + 20) > uncomp_end || (ptr + 20) > end) {
++debug("soa record too long");
++goto out;
++			}
+ 			memcpy(uptr, ptr, 20);
+ 			uptr += 20;
+ 			ptr += 20;
+-- 
+2.32.0
+
diff -Nru connman-1.36/debian/patches/series connman-1.36/debian/patches/series
--- connman-1.36/debian/patches/series	2021-02-05 14:41:13.0 +0100
+++ connman-1.36/debian/patches/series	2021-06-09 20:47:04.0 +0200
@@ -4,3 +4,4 @@
 gdhcp-Avoid-reading-invalid-data-in-dhcp_get_option.patch
 gdhcp-Avoid-leaking-stack-data-via-unitiialized-vari.patch
 dnsproxy-Add-length-checks-to-prevent-buffer-overflo.patch
+dnsproxy-Check-the-length-of-buffers-before-memcpy.patch

Bug#989594: golang-github-masterminds-semver-dev: Outdated package

[Peymaneh Nejad]

Hello,

Am 08.06.21 um 10:45 schrieb Peymaneh Nejad:

Package: golang-github-masterminds-semver-dev




I am packaging the golang library github.com/Masterminds/sprig which
depends on version 3 this library


As this would be a major version change, it was proposed on the debian-go 
mailing list to upload v3 of golang-github-masterminds-semver-dev to 
experimental until the freeze is done.


For that I would write the respective changes to a new debian/experimental 
branch on the salsa repo.


Please let me now if you have concerns with this procedure.

kind regards
Peymaneh

Bug#960049: RFS: libatl/2.2.2-1 [ITP] -- Binary representation of lists of name/value pairs

[Tobias Frost]

Control: tags -1 moreinfo

Hi Kyle,

I'm currently looking over (old) RFS bugs… And this one is very old :( Sorry for
that … So, before looking into it, can you confirm that you still interested in
maintaining this library?

Other than that, I prefer to sponsor only based on .dsc-files, preferable
uploaded to mentors.debian.net, as this is a (IMHO) more concise defintion
about exactly what to sponsor and selfish /me has also some automation in place
for mentos…

So I'd take a look at libatl after you confirmed and have some .dsc for me :)

Just remove the moreinfo tag when ready and I will take a look :)

--
Cheers,
tobi

Bug#989666: [pre-approval] unblock: firmware-sof/1.7-1

[Vincent Bernat]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Mark Pearson 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This is a pre-approval for package firmware-sof.

[ Reason ]
It ships SOF audio firmware signed by Intel and is needed on modern
platforms using SOF. The 1.7 release will be needed to make hardware
that would be released in September work. I have tested the resulting
package on my laptop and it works fine. Mark has tested it on more
laptops and didn't get any problems in the past months with it. We
think it would be better to ship this release with Bullseye to not let
people need to use backports to get a working sound card.

There are some packaging changes because upstream seems to not have
made its mind with the way firmwares should be installed in
/lib/firmware/intel.

I am attaching only a debdiff of debian/ since the remaining is mostly
binary files.

[ Impact ]
No sound out of the box for users with hardware more recent than
September 2021.

[ Tests ]
Tested on my Thinkpad X1 Carbon Gen7. Tested by Mark on other platforms.

[ Risks ]
Regression on existing hardware.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing



-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmDBDxESHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5IHsQAIThxi/kLmPomKZSLgM2UVlm+39c9PzO
3jRRNEMmuijE1aUiqqR8jOYr1psWFnWD+z4u2J3Peg+QPJXd9aKcgKFwiQHKnFOx
OcYClLggCA20fA8qY3WpzSjx6TN9Jaa+meMQfl7p8SS778KMJECyciZYjSKd7BbF
qfEulSuUvMtdV0JTtL2wh6xwLbJMtFIKfhy2zu+l5RUxaknigGThNZwSMlMrsidf
H6ppnMnB5jTDMqQGBnEHEDaR6lLOlQU6igCnhuCdckWVOvInP5B3TaWwbi7Y7M98
huAaVO/nP1MimQkokZxJ9rxXkr0gAVtGqtMfTtjlv9n6UT2YzpbSGqN7vm9ybUJ4
DkX3/dLMbLtBw/8iylI31+zU+Y6D3ezzUJ11gKTEDKx9L8OTPFvc2giBDdMW1dH4
KR42d4Qe1D9k6EM+QuwZJ9/unpNcEPKCY5JSXl9qbNawGOxbKfFxWfdIXxZh8OVL
YUYj3/GUCdDm+vgCqlE/TpVP2VsRYEFejmNrkKk632P4+5W79nd/mcr1pJJQGRBd
ddSH14sdQmuun0thsGaFy6UWwNDu8km126+lZFWo844QUeinHvzdkMTBgAuyuhNL
8biei0fvj/WqypNHmMOMPaEAKe+umamna14/xUmBUMtQvIQxav5JGCXBiHATBKPk
kVnHbdqKXp8v
=VKK6
-END PGP SIGNATURE-
diff --git a/debian/changelog b/debian/changelog
index bad2d5f15547..814f5976ef54 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+firmware-sof (1.7-1) UNRELEASED; urgency=medium
+
+  * Update to upstream version 1.7
+
+ -- Mark Pearson   Fri, 09 Apr 2021 21:59:16 -0400
+
 firmware-sof (1.6.1-2) unstable; urgency=medium
 
   * Remove postinst file as we don't need to add files to initramfs
diff --git a/debian/rules b/debian/rules
index 4012951ae2ad..00e2ae53d553 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,11 +4,14 @@ include /usr/share/dpkg/pkg-info.mk
 
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
+export SOF_INSTALL_DIR=$$(pwd)/builddir/usr/lib/firmware/intel
 
 %:
dh $@
 
 override_dh_auto_install:
-   mkdir -p $$(pwd)/builddir/usr/lib/firmware
-   ROOT=$$(pwd)/builddir/usr SOF_VERSION="v$(DEB_VERSION_UPSTREAM)" ./go.sh
+   mkdir -p $(SOF_INSTALL_DIR)
+   cp -a sof-v$(DEB_VERSION_UPSTREAM) $(SOF_INSTALL_DIR)/sof
+   cp -a sof-tplg-v$(DEB_VERSION_UPSTREAM) $(SOF_INSTALL_DIR)
+   ln -s sof-tplg-v$(DEB_VERSION_UPSTREAM) $(SOF_INSTALL_DIR)/sof-tplg
dh_auto_install

Bug#983712: RFS: lebiniou/3.55.0-1 -- user-friendly, powerful music visualization / VJing tool

[Tobias Frost]

Control: tags -1 moreinfo

Hi Olivier,

just for some quick feedback, 

As we are currently frozen and an upload to unstable of a new upstream version
is a bit out of scope right now: 
Do you want to target experimental or do you want wait for the bullseye release?

It seems that upstream has released 3.56 in the meantime, so depending on 
the above question, do you want to update to that new version as well?

(I did not look at the package yet, just soliciating that feedback)

(Formally tagging moreinfo as this needs feedback and is not actionable until
then… Just remove the tag when ready for a review and I try to reserve time for
it.)

--

Cheers,
tobi

Bug#982455: missing /usr/lib/python3.9/site-packages/cadabra2_defaults.py and missing dependencies

[zyli]

Package: cadabra2
Version: 2.3.6.8-1
Architecture: amd64 (x86_64)

Debian testing live, weekly-build 2021-06-07:
"Official Debian GNU / Linux Live testing snapshot cinnamon 
2021-06-07T05: 46"


I was able to run cadabra2 ver. 2.3.6.8-1 under Debian Live Bullseye 
after following the steps below:


1.implementation of the link:
ln -s /usr/lib/python3/dist-packages /usr/lib/python3.9/site-packages

2. Installing packages:
texlive-science
texlive-latex-extra
dvipng
python3-sympy
python3-matplotlib
python3-gmpy2

In my opinion, the following command worked well (also the "Evaluate 
all" command):


cadabra2-gtk /usr/share/doc/cadabra2/examples/schwarzschild.ipynb

cadabra2-gtk /usr/share/doc/cadabra2/examples/plotting.cnb

Command doesn't work:
cadabra2-gtk /usr/share/doc/cadabra2/examples/beginners.cnb
("Latex error")

Bug#989653: gnome-shell-extension-dashtodock: Show Application Animation is Glitchy

[I am using Debian 11 Bullseye Testing version (latest one). I am getting a glitch in GNOME desktop when I click Show Applications. I found similar issue on GNOME's Gitlab. Here's the link: https://]

Package: gnome-shell-extension-dashtodock
Version: other
Severity: normal
X-Debbugs-Cc: sp8...@protonmail.com

Dear Maintainer,


   * What led up to the situation?
I installed Debian 11 bullseye and installed gnome-shell-extension-dashtodock
from gnome shell extensions website and I am facing glitch in Show Applications.
This is the problem I'm facing(I found on gitlab) : 
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3353 
   

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

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

Versions of packages gnome-shell-extension-dashtodock depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gnome-shell  3.38.4-1

Versions of packages gnome-shell-extension-dashtodock recommends:
ii  gnome-shell-extension-prefs  3.38.4-1

gnome-shell-extension-dashtodock suggests no packages.

Bug#989665: user-mode-linux FTBFS: link error

[Adrian Bunk]

Source: user-mode-linux
Version: 5.10um2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=user-mode-linux=sid

...
  LD  .tmp_vmlinux.kallsyms1
/usr/bin/ld: anonymous version tag cannot be combined with other version tags
/usr/bin/ld: init/main.o: warning: relocation in read-only section `.text'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:1167: vmlinux] Error 1

Bug#989664: xterm: .Xresources VT100 override for copy/paste ignored

[Casey M. Bessette]

Package: xterm
Version: 366-1
Severity: normal
X-Debbugs-Cc: casey.besse...@gmail.com

Dear Maintainer,

My .Xresources file has this in it:

!enable copy/paste:
!http://unix.stackexchange.com/questions/225062/how-can-i-copy-text-from-xterm-awesome-debian-virtualbox
xterm*VT100.Translations: #override \
 Ctrl Shift V:insert-selection(CLIPBOARD) \n\
 Ctrl Shift C:copy-selection(CLIPBOARD)

I run xrdb -merge ~/.Xresources after editing the file.  This has enabled me to 
use ctrl-shift-c to copy and ctrl-shift-v to paste in and out of xterm.

In bullseye, this no longer works.  Now if I hit ctrl-shift-c, it acts
no different than if I hit ctrl-c.  This worked for me on jessie and stretch.  
I haven't used buster.

If I modify other lines in my .Xresources file, such as the size of the
font, colors, or xterm geometry, those changes are still honored and
work as expected.

I'm using Xfce 4.16 and X.Org 1.20.11.


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xterm depends on:
ii  libc6   2.31-12
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1
ii  libice6 2:1.0.10-1
ii  libtinfo6   6.2+20201114-2
ii  libutempter01.2.1-2
ii  libx11-62:1.7.1-1
ii  libxaw7 2:1.0.13-1.1
ii  libxext62:1.3.3-1.1
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.2.0-1
ii  xbitmaps1.1.1-2.1

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

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

Bug#989663: ferm --remote --slow does not produce deterministic output

[Eric Cooper]

Package: ferm
Version: 2.5.1-1
Severity: normal

Running "ferm --remote --slow" produces iptables rules in different
orders on different runs. This makes it difficult to compare outputs
for regression testing, version control, etc.

For example, on two successive runs this input produced the following
output:
table filter {
chain INPUT policy DROP;
chain FORWARD policy DROP;
chain OUTPUT policy ACCEPT;
}

run #1
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT
iptables -t filter -P INPUT ACCEPT
iptables -t filter -F
iptables -t filter -X
iptables -t filter -P FORWARD DROP
iptables -t filter -P INPUT DROP
run #2
iptables -t filter -P INPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -F
iptables -t filter -X
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP

I think this behavior comes from Perl's randomized hash tables and the use of 
while (my ($chain, $chain_info) = each %{$table_info->{chains}}) { ... }
constructs.  Changing these to loops over sorted keys should fix the problem.

Bug#989651: python3-sqlalchemy: Please package new upstream version

[Matt Zagrabelny]

Package: python3-sqlalchemy
Version: 1.3.22+ds1-1
Severity: wishlist

Thank you for contributing to Debian. It is very appreciated.

Please consider packaging the latest upstream version (currently 1.4.17) of 
SQLAlchemy.

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-sqlalchemy depends on:
ii  python3  3.9.1-1

Versions of packages python3-sqlalchemy recommends:
ii  python3-sqlalchemy-ext  1.3.22+ds1-1

Versions of packages python3-sqlalchemy suggests:
pn  python-sqlalchemy-doc  
pn  python3-fdb
pn  python3-mysqldb
ii  python3-psycopg2   2.8.6-2
pn  python3-pymssql

-- no debconf information

Bug#989587: unblock: uacme/1.7.1-1

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-06-08 08:24:43, Nicola Di Lieto wrote:
> Subject: unblock: uacme/1.7.1-1
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: unblock
> Severity: normal
> 
> Please unblock package uacme 1.7.1-1

This appears to be a pre-approval request. Please provide a debdiff
between the source package in bullseye and unstable.

Cheers

> 
> https://mentors.debian.net/package/uacme
> 
> [ Reason ]
> New upstream bugfix version with two small changes:
> 
> 1) uacme: fix unpredictable behavior between issue IDENTIFIER and issue
> CSRFILE when run with sudo or doas in a directory without access.  See
> https://github.com/ndilieto/uacme/issues/41
> 
> 2) ualpn: use default user group when -u  is specified without
> explicit group.
> 
> [ Impact ]
> Two bugs fixed.
> 
> [ Tests ]
> It was manually tested. The software does not have a test suite because it
> needs to interact with an online ACMEv2 server to issue certificates.
> 
> [ Other info ]
> The changes are in these two commits
> https://github.com/ndilieto/uacme/commit/c80d85ab1f8b12aebb064346572a1c1f6c30cfa7
> https://github.com/ndilieto/uacme/commit/b2cf90410c3bf42f843690bde624ab6daacf1b4b
> 
> The changelogs are at
> https://github.com/ndilieto/uacme/blob/debian/master/ChangeLog
> https://github.com/ndilieto/uacme/blob/debian/master/debian/changelog
> 
> [ Checklist ]
>  [x] all changes are documented in the d/changelog
>  [x] I reviewed all changes and I approve them
>  [x] attach debdiff against the package in testing
> 
> > File lists identical (after any substitutions)
> > 
> > Control files: lines which differ (wdiff format)
> > 
> > Version: [-1.7-1-] {+1.7.1-1+}
> 

-- 
Sebastian Ramacher

Bug#989643: unblock: formiko/1.3.0

[Sebastian Ramacher]

Control: tags -1 confirmed moreinfo
Control: retitle -1 unblock: formiko/1.3.0-2

On 2021-06-09 10:49:42, Ondřej Tůma wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: mc...@zeropage.cz
> 
> Please unblock package formiko

This appears to be a pre-approval request. Please remove the moreinfo
tag once the new version is available in unstable.

Cheers

> 
> [ Reason ]
> I was fix the errors.
> 
> [ Impact ]
> Formiko package will be still in Debian.
> 
> [ Tests ]
> Package has two simple tests.
> 
> [ Risks ]
> No risks
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [ ] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing

> diff -Nru formiko-1.3.0/debian/control formiko-1.3.0/debian/control
> --- formiko-1.3.0/debian/control  2018-01-16 08:48:07.0 +0100
> +++ formiko-1.3.0/debian/control  2021-05-25 12:43:39.0 +0200
> @@ -6,10 +6,11 @@
>   debhelper (>= 11),
>   dh-python,
>   python3-all,
> + python3-docutils,
>   python3-setuptools,
>  Standards-Version: 4.1.3
>  Homepage: https://github.com/ondratu/formiko
> -X-Python3-Version: >= 3.2
> +X-Python3-Version: >= 3.8
>  Vcs-Git: https://github.com/ondratu/formiko-debian.git
>  Vcs-Browser: https://github.com/ondratu/formiko-debian
>  
> @@ -19,6 +20,7 @@
>   gir1.2-gtksource-3.0,
>   gir1.2-gtkspell3-3.0,
>   gir1.2-webkit2-4.0,
> + librsvg2-common,
>   python3-docutils,
>   python3-gi,
>   python3-recommonmark,
> diff -Nru formiko-1.3.0/debian/changelog formiko-1.3.0/debian/changelog
> --- formiko-1.3.0/debian/changelog2018-01-16 08:48:07.0 +0100
> +++ formiko-1.3.0/debian/changelog2021-05-25 12:43:39.0 +0200
> @@ -1,3 +1,26 @@
> +formiko (1.3.0-2) unstable; urgency=medium
> +
> +  [ Sebastien Bacher ]
> +  * debian/control:
> +- Depends on librsvg2-common, the svg loader is needed and used to
> +  be pulled in by indirect depends but isn't anymore (Closes: #964511)
> +
> +  [ Debian Janitor ]
> +  * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
> +Repository-Browse.
> +  * Replace use of deprecated $ADTTMP with $AUTOPKGTEST_TMP.
> +
> +  [ Ondřej Tůma ]
> +  * debian/tests/control:
> +- Mark tests as superficial (Closes: #974458)
> +  * debian/watch:
> +- changed - pypi doesn't support signatures
> +  * debian/control:
> +- Depends on python3-docutils, which is need for it's main functionality
> +- Bump X-Python3-Version to 3.8 which is recommended by authors
> +
> + -- Ondřej Tůma   Tue, 25 May 2021 12:43:39 +0200
> +
>  formiko (1.3.0-1) unstable; urgency=medium
>  
>* New upstream release
> diff -Nru formiko-1.3.0/debian/tests/control 
> formiko-1.3.0/debian/tests/control
> --- formiko-1.3.0/debian/tests/control2018-01-16 08:48:07.0 
> +0100
> +++ formiko-1.3.0/debian/tests/control2021-05-25 12:43:39.0 
> +0200
> @@ -1,6 +1,7 @@
>  Test-Command: formiko --help
>  Depends: python3-all, formiko
> -Restrictions: allow-stderr
> +Restrictions: allow-stderr, superficial
>  
> -Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd 
> "$ADTTMP" ; echo "Testing with $py:" ; $py -c "import formiko; 
> print(formiko)" ; done
> +Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd 
> "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import formiko; 
> print(formiko)" ; done
>  Depends: python3-all, formiko
> +Restrictions: superficial
> diff -Nru formiko-1.3.0/debian/upstream/metadata 
> formiko-1.3.0/debian/upstream/metadata
> --- formiko-1.3.0/debian/upstream/metadata1970-01-01 01:00:00.0 
> +0100
> +++ formiko-1.3.0/debian/upstream/metadata2021-05-25 12:43:39.0 
> +0200
> @@ -0,0 +1,5 @@
> +---
> +Bug-Database: https://github.com/ondratu/formiko/issues
> +Bug-Submit: https://github.com/ondratu/formiko/issues/new
> +Repository: https://github.com/ondratu/formiko.git
> +Repository-Browse: https://github.com/ondratu/formiko
> diff -Nru formiko-1.3.0/debian/watch formiko-1.3.0/debian/watch
> --- formiko-1.3.0/debian/watch2018-01-16 08:48:07.0 +0100
> +++ formiko-1.3.0/debian/watch2021-05-25 12:43:39.0 +0200
> @@ -1,5 +1,5 @@
>  # Compulsory line, this is a version 4 file
>  version=4
>  
> -opts=uversionmangle=s/(rc|a|b|c)/~$1/,pgpsigurlmangle=s/$/.asc/ \
> +opts=uversionmangle=s/(rc|a|b|c)/~$1/ \
>  
> https://pypi.debian.net/formiko/formiko-(.+)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))


-- 
Sebastian Ramacher

Bug#989662: connman: CVE-2021-33833: dnsproxy: Check the length of buffers before memcpy

[Salvatore Bonaccorso]

Source: connman
Version: 1.36-2.1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.36-2.1~deb10u1

Hi,

The following vulnerability was published for connman. Choosing RC
severity to make sure the fix land in bullseye.

CVE-2021-33833[0]:
| dnsproxy: Check the length of buffers before memcpy

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-2021-33833
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33833
[1] https://www.openwall.com/lists/oss-security/2021/06/09/1
[2] 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=eceb2e8d2341c041df55a5e2f047d9a8c491463c

Regards,
Salvatore

Bug#987639: smlsharp: diff for NMU version 1.2.0-2.1

[Adrian Bunk]

Control: tags 987639 + patch

Dear maintainer,

I've prepared an NMU for smlsharp (versioned as 1.2.0-2.1) and uploaded 
it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru smlsharp-1.2.0/debian/changelog smlsharp-1.2.0/debian/changelog
--- smlsharp-1.2.0/debian/changelog	2013-09-21 07:42:05.0 +0300
+++ smlsharp-1.2.0/debian/changelog	2021-06-09 20:00:54.0 +0300
@@ -1,3 +1,10 @@
+smlsharp (1.2.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with -fcommon to workaround FTBFS with gcc 10. (Closes: #987639)
+
+ -- Adrian Bunk   Wed, 09 Jun 2021 20:00:54 +0300
+
 smlsharp (1.2.0-2) unstable; urgency=low
 
   * Update debian/control.
diff -Nru smlsharp-1.2.0/debian/rules smlsharp-1.2.0/debian/rules
--- smlsharp-1.2.0/debian/rules	2013-09-21 07:42:05.0 +0300
+++ smlsharp-1.2.0/debian/rules	2021-06-09 20:00:52.0 +0300
@@ -12,7 +12,7 @@
 
 override_dh_auto_configure:
 	CC="gcc -m32" LD="ld -m elf_i386"	\
-		CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" \
+		CFLAGS="$(CFLAGS) -fcommon" LDFLAGS="$(LDFLAGS)" \
 		./configure --prefix=/usr --enable-fast-build	\
 		--enable-thread
 

Bug#989661: libmaus2: binary packages built using libsecrecy

[Étienne Mollier]

Source: libmaus2
Version: 2.0.768+dfsg-1
Severity: serious
Tags: patch
Justification: Policy 7.8

Greetings,

I recalled about libsecrecy being a headers only library, and
that it was inlined in libmaus2.  The libmaus2 is for the most
part a GPL-3+ software.  This means the full source code to
build the libmaus2 must be made available, including the exact
version of the libsecrecy used for constructing the following
binary packages:

  * libmaus2-2, which embeds shared objects built using
libsecrecy headers,
  * and libmaus2-dev, which offers among other things, the
corresponding static libraries.

To be able to rebuild these packages, one would have to know
they have been built using the current version of libsecrecy,
presently 0.0.2+dfsg-2.  This needs to be documented throught
the following Built-Using field applied against control files of
the two binary package:

Built-Using: libsecrecy (= 0.0.2+dfsg-2)

Following the model in use for SIMDe[1], I intend to apply the
patch in attachment and upload the package.  This bug entry is
mostly to document the issue for the release team, as we're in
hard-freeze.

[1]: https://wiki.debian.org/SIMDEverywhere

Cheers,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
diff --git a/debian/changelog b/debian/changelog
index 1116227..b92f146 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libmaus2 (2.0.768+dfsg-2) unstable; urgency=medium
+
+  * Built-Using: libsecrecy
+Closes: #-1
+
+ -- Étienne Mollier   Wed, 09 Jun 2021 17:24:41 +0200
+
 libmaus2 (2.0.768+dfsg-1) unstable; urgency=medium
 
   * New upstream version
diff --git a/debian/control b/debian/control
index 643c155..233d5f3 100644
--- a/debian/control
+++ b/debian/control
@@ -22,6 +22,7 @@ Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  zlib1g
+Built-Using: ${libsecrecy:Built-Using}
 Description: collection of data structures and algorithms for biobambam
  Libmaus2 is a collection of data structures and algorithms. It contains
  .
@@ -39,6 +40,7 @@ Depends: libmaus2-2 (= ${binary:Version}),
  zlib1g-dev,
  ${shlibs:Depends},
  ${misc:Depends}
+Built-Using: ${libsecrecy:Built-Using}
 Description: collection of data structures and algorithms for biobambam (devel)
  Libmaus2 is a collection of data structures and algorithms. It contains
  .
diff --git a/debian/rules b/debian/rules
index 2d60460..cbbef1d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,11 @@
 
 # DH_VERBOSE := 1
 export LC_ALL=C.UTF-8
+BUILT_USING_SECRECY = $(shell \
+	dpkg-query \
+		-f '$${source:Package} (= $${source:Version}), ' \
+		-W 'libsecrecy-dev' \
+)
 
 # include /usr/share/dpkg/default.mk
 
@@ -35,6 +40,9 @@ override_dh_install:
 override_dh_installchangelogs:
 	dh_installchangelogs ChangeLog
 
+override_dh_gencontrol:
+	dh_gencontrol -- -Vlibsecrecy:Built-Using="$(BUILT_USING_SECRECY)"
+
 ### When overriding auto_test make sure DEB_BUILD_OPTIONS will be respected
 #override_dh_auto_test:
 #ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))


signature.asc
Description: PGP signature

Bug#989593: installation report Raspberry Pi 4 UEFI

[Marc Haber]

On Wed, Jun 09, 2021 at 12:24:33AM +0200, Geert Stappers wrote:
> Repeating this:

I apologize for waiting for delivery of a new usb stick so that the
new installation would not be a complete waste of time.

> If you were to retry the installation, saving /var/log/syslog manually
> before rebooting into the installed system would be useful. Without it,
> I fear much guessing would be needed to try and figure out what happened
> on that system specifically. Unless someone else has better ideas of
> course.

I have attached the installer's syslog of a new installation. All issues
that I reported were observed during this installation.

Let me know if I can be of additional help. I appreciate the swiftness
of your reactions, this is very helpful.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421


syslog.xz
Description: application/xz

Bug#988453: buster-pu: package rust-rustyline/3.0.0-2

[peter green]

On 29/05/2021 15:17, Adam D. Barratt wrote:

Control: tags -1 + confirmed

On Thu, 2021-05-13 at 11:13 +0100, plugwash wrote:

rust-rustyline fails to build in buster due to a change of behaviour
in rustc,
this has been fixed in bullseye/sid for some time and I was able to
locate
the upstream commit that fixes the failure by bisecting and then
apply it to
the package from buster.



Please go ahead.


I uploaded the package.

Unfortunately it seems that the binaries were rejected due to a file
with a 1970 timestamp (this timestamp already exists in the version
currently in buster), should I go ahead and prepare another upload
fixing that?



Regards,

Adam

Bug#989660: spyder: When autoformat-on-save is on, the code is duplicated in the code editor

[Amr Ibrahim]

Package: spyder
Version: 4.2.1+dfsg1-3
Severity: important
X-Debbugs-Cc: amribrahim1...@hotmail.com

Dear Maintainer,

When autoformat-on-save with black is turned on, the code is duplicated in the 
code editor by itself when saving.

Upstream issue:
https://github.com/spyder-ide/spyder/issues/14653

Fix:
https://github.com/spyder-ide/spyder/commit/9325d0d7be1a88602b8092d35be309edc876aa38

Please cherry-pick the fix for Debian Bullseye.


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

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

Versions of packages spyder depends on:
ii  python3 3.9.2-3
ii  python3-spyder  4.2.1+dfsg1-3

spyder recommends no packages.

spyder suggests no packages.

Versions of packages python3-spyder depends on:
ii  ipython3  7.20.0-1
ii  libjs-jquery  3.5.1+dfsg+~3.5.5-7
ii  libjs-mathjax 2.7.9+dfsg-1
ii  pylint2.7.2-1
ii  python3   3.9.2-3
ii  python3-atomicwrites  1.4.0-2
ii  python3-chardet   4.0.0-1
ii  python3-cloudpickle   1.6.0-1
ii  python3-diff-match-patch  20200713-1
ii  python3-docutils  0.16+dfsg-4
ii  python3-intervaltree  3.0.2-1.1
ii  python3-ipython   7.20.0-1
ii  python3-jedi  0.18.0-1
ii  python3-jsonschema3.2.0-3
ii  python3-keyring   22.0.1-1
ii  python3-nbconvert 5.6.1-3
ii  python3-numpydoc  1.1.0-3
ii  python3-parso 0.8.1-1
ii  python3-pexpect   4.8.0-2
ii  python3-pickleshare   0.7.5-3
ii  python3-pkg-resources 52.0.0-3
ii  python3-psutil5.8.0-1
ii  python3-pygments  2.7.1+dfsg-2
ii  python3-pyls  0.36.2-3
ii  python3-pyls-black0.4.6-3
ii  python3-pyls-spyder   0.3.0-3
ii  python3-qdarkstyle2.8.1+ds1-3
ii  python3-qtawesome 1.0.2-1
ii  python3-qtconsole 5.0.2-2
ii  python3-qtpy  1.9.0-3
ii  python3-setuptools52.0.0-3
ii  python3-sphinx3.4.3-2
ii  python3-spyder-kernels1.10.2-1
ii  python3-textdistance  4.2.0-2
ii  python3-three-merge   0.1.1-2
ii  python3-watchdog  1.0.2-2
ii  python3-xdg   0.27-2
ii  python3-zmq   20.0.0-1+b1
ii  spyder-common 4.2.1+dfsg1-3

Versions of packages python3-spyder recommends:
ii  python3-autopep8 1.5.5-1
ii  python3-mccabe   0.6.1-3
ii  python3-pycodestyle  2.6.0-1
pn  python3-pydocstyle   
pn  python3-pyflakes 
pn  python3-rope 
ii  python3-yapf 0.30.0-1

Versions of packages python3-spyder suggests:
pn  cython3 
ii  python3-matplotlib  3.3.4-1
ii  python3-numpy   1:1.19.5-1
ii  python3-pandas  1.1.5+dfsg-2
ii  python3-pil 8.1.2+dfsg-0.1
ii  python3-scipy   1.6.0-2
ii  python3-sympy   1.7.1-3

Versions of packages python3-pyqt5 depends on:
ii  libc6 2.31-12
ii  libgcc-s1 10.2.1-6
ii  libpython3.9  3.9.2-1
ii  libqt5core5a [qtbase-abi-5-15-2]  5.15.2+dfsg-5
ii  libqt5dbus5   5.15.2+dfsg-5
ii  libqt5designer5   5.15.2-5
ii  libqt5gui55.15.2+dfsg-5
ii  libqt5help5   5.15.2-5
ii  libqt5network55.15.2+dfsg-5
ii  libqt5printsupport5   5.15.2+dfsg-5
ii  libqt5test5   5.15.2+dfsg-5
ii  libqt5widgets55.15.2+dfsg-5
ii  libqt5xml55.15.2+dfsg-5
ii  libstdc++610.2.1-6
ii  python3   3.9.2-3
ii  python3-pyqt5.sip 12.8.1-1+b2

Versions of packages python3-pyqt5 suggests:
pn  python3-pyqt5-dbg  

-- no debconf information

Bug#981982: RFS: codelite/15.0+dfsg-1 [QA] -- Powerful and lightweight IDE

[Tobias Frost]

Hi David,

(Note: Due to the freeze, an upload to unstable is currently out of scope.  You
might either want to wait for bullseye's release or target experimental for now)

Thanks for the updated package…
Some questions though:
- d/control:
  - I see in the diff
- that you start Depend: on clangd and clang-format.
Is codelite _really_ depending as in Policy-Depends on it?
   (there are some *arch-dependent* Build-Depends on clang stugg that seems to
be in contradiction… as the Depends are not arch-depenent this does not fit
somehow…)
- note this change is not documented in d/changelog, thats why I had to
  guess: PLEASE document the _whys_ of your changes to help the sponsor out
  until they improve in reading your mind… ;-)

nitpick:
 - d/copyright does not need all those extra blank lines :)

PS: You know the package is orphaned :) Could we talk you into adopting it?
(Its okay if you decline, but TIA for considering!)

Tagging moreinfo because of the questions above (clang and freeze)
Remove the tag when you think the package is ready for a second review…

Cheers,

-- 
tobi

Bug#989658: openboard: App uses generic icon in gnome-shell, not app icon

[Amr Ibrahim]

Package: openboard
Version: 1.5.4+dfsg1-2
Severity: normal
X-Debbugs-Cc: amribrahim1...@hotmail.com

Dear Maintainer,

The app uses a generic icon in gnome-shell in X11 and Wayland. It should use 
its own icon.


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

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

Versions of packages openboard depends on:
ii  libavcodec58  7:4.3.2-0+deb11u1
ii  libavformat58 7:4.3.2-0+deb11u1
ii  libavutil56   7:4.3.2-0+deb11u1
ii  libc6 2.31-12
ii  libgcc-s1 10.2.1-6
ii  libgomp1  10.2.1-6
ii  libpoppler102 20.09.0-3.1
ii  libqt5core5a  5.15.2+dfsg-5
ii  libqt5gui55.15.2+dfsg-5
ii  libqt5multimedia5 5.15.2-3
ii  libqt5multimediawidgets5  5.15.2-3
ii  libqt5network55.15.2+dfsg-5
ii  libqt5script5 5.15.2+dfsg-2
ii  libqt5svg55.15.2-3
ii  libqt5webkit5 5.212.0~alpha4-11
ii  libqt5widgets55.15.2+dfsg-5
ii  libqt5xml55.15.2+dfsg-5
ii  libquazip5-1  0.9.1-1
ii  libssl1.1 1.1.1k-1
ii  libstdc++610.2.1-6
ii  libswresample37:4.3.2-0+deb11u1
ii  libswscale5   7:4.3.2-0+deb11u1
ii  libx11-6  2:1.7.1-1
ii  openboard-common  1.5.4+dfsg1-2
ii  zlib1g1:1.2.11.dfsg-2

openboard recommends no packages.

Versions of packages openboard suggests:
ii  openboard-contrib  1.5.4+dfsg1-2

-- no debconf information

Bug#989657: Current sogo-connector does not work with current Mozilla Thunderbird

[Narcis Garcia]

Package: webext-sogo-connector
Version: 68.0.1-2~deb10u1
Severity: grave

thunderbird package is updated to version 78 on Main repository but
neither webext-sogo-connector nor xul-ext-sogo-connector do not:
sogo-connector is still packaged as version 68 and does not work with
current only installable Thunderbird (78).

With both thunderbird(78) and webext-sogo-connector(68) installed,
Address book page has no option to subscribe to CardDAV Address book.

thunderbird(68) + lightning(68) + webext-sogo-connector(68) do show
"Subscribe to addressbook" button at Address book page.
I suppose webext-sogo-connector needs to be packaged as version(78)
compatible with thunderird 78.


-- 

Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this tracker archive. Public archive administrator
should fix this against automated addresses collectors.

Bug#989656: Xen misusing syslog

[Phillip Susi]

Package: xen-utils-common
Version: 4.14.1+11-gb0b734a8b3-1

My syslog has entries that look like this:

Jun 09 10:54:26 hyper1 root[621]: /etc/xen/scripts/block: add
XENBUS_PATH=backend/vbd/1/768

The third field is supposed to be the program name, which I would expect
to either be xen or xl or something, but instead it appears to be
passing $USER.

Bug#981702: RFS: privacybadger/2021.2.2-1 -- browser extension automatically learns to block invisible trackers

[Tobias Frost]

Control: tags -1 moreinfo

Hi John,

On Tue, 02 Feb 2021 19:11:34 -0500 John Scott  wrote:
>    * Friendly takeover back into the WebExt team.

I can't find any documentation about that have been ACKed by the current
maintainer. (CCing Jonas so that he can response/confirm, to put it on record
that this is not an hijack…)

Cheers,
-- 
tobi

Bug#954176: WIP snowflake package

[meskio]

I'm working on the snowflake package. I have a package that works:
https://gitlab.torproject.org/meskio/snowflake-debian

Looking for a mentor to review it and a place to put it in salsa, I'm asking 
the 
go-team to see if it will fit under their umbrella.


-- 
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.

signature.asc
Description: signature

Bug#971594: Asciidoc new package. Check why those existed

[Tobias Frost]

Control: tags -1 moreinfo 

Hi Leon,

I'm not sure about the status of this RFS / it seems that there is some
confusion… So lets try to untangle this…

What I can see from the diff is that the only package dropped is vim-ascidoc.
This looks sane to me, and due to the fact that vim depends on vim-runtime
on any vim flavour != tiny, people possibly have already vim-runtime installed.

However -- as popcon of the package is rather high -- I would put up some
NEWS.Debian file saying that this is dropped in favour of vim-runtime; 
This is especially useful, if (I did not check if that is the case!) the
user needs to do someting to switch to the vim-runtime provided thingy.
What do you think?

However, as Debian is frozen and an upload to unstable is out of scope
currently: Would you like to target experimental for now or
do you want to wait until bullseye have been released and/or maybe looking
into packaging the new upstream release?

(I'm marking the bug as moreinfo for now, just to keep the RFS bugs list
"actionable". Feel free to remove the tag once it make sense to proceed with
the sponsoring -- be it experimental or post-bullseye-release…)

-- 
Cheers,
tobi

Bug#989629: ITP: elementary-code -- Essential code editor with tab support

[Francisco M Neto]

Hello!

Thanks for your comment!

On 6/9/21 9:19 AM, Nicholas D Steeves wrote:
> Cool :-)  By the way, how is Elementary Code, an IDE?  Upstream calls
> it a "[code-specific] text-editor" here (
> https://medium.com/elementaryos/scratch-is-now-code-2838e03134c7 ),
> and it sounds like Code is intended to be like Atom, "a hackable text
> editor" ( https://atom.io ), rather than something like GNOME Builder
> or XCode ( 
> https://www.reddit.com/r/linux/comments/7oi8nf/scratch_text_editor_is_now_elementary_code/dsafxmb/?utm_source=reddit_medium=web2x=3).

If I had to compare it I'd say it's more like Atom, yes. I have never
heard of XCode, so I can't really say anything about it, but GNOME
Builder is pretty much targeted at people developing for GNOME. Not that
it's not useful elsewhere, but it really focuses on it, having
"official" support only for the languages they use the most with GNOME
(like C/C++, Python or Rust). And it behaves a lot more like an IDE with
a lot of extra features.

> If you'd like to use "IDE" in the long description to make it
> discoverable with keyword or regex searches, maybe something could be
> written about how Code is more than a text editor, but that it's for
> people who don't want a full-featured IDE?  Does it support templates,
> macros, code folding, any kind of linting or language server-based IDE
> features (LSP), tab completion of variable, function, or class names,
> etc?  More simply, does it have an LSP plugin like
> https://github.com/atom-community/atom-languageclient or is one
> planned?  Ideally it'd be nice if upstream could make a statement
> about their vision and objectives for Code on its homepage
> https://github.com/elementary/code

That's a good point. In fact, in their original description for it,
they mention that it _can_ become a full featured IDE if the user wants
it to. But it's designed with minimalism in mind, and has basic
features. It doesn't have all the features GNOME Builder has but, in
their words, one can "install extensions to turn Code into a full-blown
IDE".

> Because you use the keyword "minimalist", I wonder if the authors of
> this software (and perhaps yourself) believe that full-featured IDEs
> are not the best way to work ;-)  Not being an IDE can be a desirable
> feature, after all!

I don't know about the authors; as far as I'm concerned, I've coded
with emacs for 20+ years so I'm still trying to decide which way to go.
I guess it depends on project/language. But I do like Code's
minimalistic approach.

-- 
[]'s,

Francisco M Neto 
www.fmneto.com

3E58 1655 9A3D 5D78 9F90
CFF1 D30B 1694 D692 FBF0


OpenPGP_0xD30B1694D692FBF0.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#989655: unblock: dolfinx/2019.2.0~git20210130.c14cb0a-5

[Drew Parsons]

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

Please unblock package dolfinx

[ Reason ]

Privacy hacking on the mathjax url in documentation was incorrect, so
that mathematical equations in docs (in particular for demos) was not
correctly formatted (shown as raw TeX).

This patch fixes the privacy hack so documentation can be read
properly as intended.

[ Impact ]

Mathematical equations in docs are rendered as TeX texts, making them
almost useless. Documentation for a stable release should display
correctly.

[ Tests ]

debci tests are in place.
The documentation correction made here has been checked manually.

[ Risks ]

Patch is trivial, fixing documentation url.
No substantive code changes, so risks are negligible.

[ Checklist ]
  [x ] all changes are documented in the d/changelog
  [x ] I reviewed all changes and I approve them
  [x ] attach debdiff against the package in testing

[ Other info ]

This is the equivalent patch for dolfinx which has also been applied
to dolfin in unblock request Bug#989654

unblock dolfinx/2019.2.0~git20210130.c14cb0a-5
diff -Nru dolfinx-2019.2.0~git20210130.c14cb0a/debian/changelog 
dolfinx-2019.2.0~git20210130.c14cb0a/debian/changelog
--- dolfinx-2019.2.0~git20210130.c14cb0a/debian/changelog   2021-02-13 
02:28:09.0 +0100
+++ dolfinx-2019.2.0~git20210130.c14cb0a/debian/changelog   2021-06-09 
14:59:59.0 +0200
@@ -1,3 +1,10 @@
+dolfinx (2019.2.0~git20210130.c14cb0a-5) unstable; urgency=medium
+
+  * use triple-slash (file:///) for mathjax local url replacement to
+make docs for demos properly legible.
+
+ -- Drew Parsons   Wed, 09 Jun 2021 14:59:59 +0200
+
 dolfinx (2019.2.0~git20210130.c14cb0a-4) unstable; urgency=medium
 
   * update fenics:Upstream-Version to 2019.2.0~git20210116 to ensure
diff -Nru dolfinx-2019.2.0~git20210130.c14cb0a/debian/rules 
dolfinx-2019.2.0~git20210130.c14cb0a/debian/rules
--- dolfinx-2019.2.0~git20210130.c14cb0a/debian/rules   2021-02-13 
02:28:09.0 +0100
+++ dolfinx-2019.2.0~git20210130.c14cb0a/debian/rules   2021-06-09 
14:59:59.0 +0200
@@ -307,8 +307,8 @@
 
 override_dh_sphinxdoc-indep:
dh_sphinxdoc -i
-   grep "https://cdn.mathjax.org/mathjax/latest/MathJax.js; 
debian/dolfinx-doc/usr/share/doc/dolfinx-doc/* -r --files-with-matches | xargs 
sed 
"s|src=\"https://cdn.mathjax.org/mathjax/latest/MathJax.js|src=\"file://usr/share/javascript/mathjax/MathJax.js|g"
 -i
-   grep "https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js; 
debian/dolfinx-doc/usr/share/doc/dolfinx-doc/* -r --files-with-matches | xargs 
sed 
"s|src=\"https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js|src=\"file://usr/share/javascript/mathjax/unpacked/latest.js|g"
 -i
+   grep "https://cdn.mathjax.org/mathjax/latest/MathJax.js; 
debian/dolfinx-doc/usr/share/doc/dolfinx-doc/* -r --files-with-matches | xargs 
sed 
"s|src=\"https://cdn.mathjax.org/mathjax/latest/MathJax.js|src=\"file:///usr/share/javascript/mathjax/MathJax.js|g"
 -i
+   grep "https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js; 
debian/dolfinx-doc/usr/share/doc/dolfinx-doc/* -r --files-with-matches | xargs 
sed 
"s|src=\"https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js|src=\"file:///usr/share/javascript/mathjax/unpacked/latest.js|g"
 -i
 
 # python module so files are already stripped by setup.py (setuptools)
 override_dh_dwz:

Bug#989654: unblock: dolfin/2019.2.0~git20201207.b495043-5

[Drew Parsons]

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

Please unblock package dolfin

[ Reason ]

Privacy hacking on the mathjax url in documentation was incorrect, so
that mathematical equations in docs (in particular for demos) was not
correctly formatted (shown as raw TeX).

This patch fixes the privacy hack so documentation can be read
properly as intended.

[ Impact ]

Mathematical equations in docs are rendered as TeX texts, making them
almost useless. Documentation for a stable release should display
correctly.

[ Tests ]

debci tests are in place.
The documentation correction made here has been checked manually.

[ Risks ]

Patch is trivial, fixing documentation url.
No substantive code changes, so risks are negligible.

[ Checklist ]
  [x ] all changes are documented in the d/changelog
  [x ] I reviewed all changes and I approve them
  [x ] attach debdiff against the package in testing

unblock dolfin/2019.2.0~git20201207.b495043-5
diff -Nru dolfin-2019.2.0~git20201207.b495043/debian/changelog 
dolfin-2019.2.0~git20201207.b495043/debian/changelog
--- dolfin-2019.2.0~git20201207.b495043/debian/changelog2021-01-29 
17:09:57.0 +0100
+++ dolfin-2019.2.0~git20201207.b495043/debian/changelog2021-06-09 
13:23:16.0 +0200
@@ -1,3 +1,10 @@
+dolfin (2019.2.0~git20201207.b495043-5) unstable; urgency=medium
+
+  * use triple-slash (file:///) for mathjax local url replacement to
+make docs for demos properly legible.
+
+ -- Drew Parsons   Wed, 09 Jun 2021 13:23:16 +0200
+
 dolfin (2019.2.0~git20201207.b495043-4) unstable; urgency=medium
 
   * debian/tests: add ppc64el to the list of arches skipping some tests
diff -Nru dolfin-2019.2.0~git20201207.b495043/debian/rules 
dolfin-2019.2.0~git20201207.b495043/debian/rules
--- dolfin-2019.2.0~git20201207.b495043/debian/rules2021-01-29 
17:09:57.0 +0100
+++ dolfin-2019.2.0~git20201207.b495043/debian/rules2021-06-09 
13:23:16.0 +0200
@@ -326,7 +326,7 @@
 
 override_dh_sphinxdoc-indep:
dh_sphinxdoc -i
-   grep "https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js; 
debian/dolfin-doc/usr/share/doc/dolfin-doc/* -r --files-with-matches | xargs 
sed 
"s|src=\"https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js|src=\"file://usr/share/javascript/mathjax/unpacked/latest.js|g"
 -i
+   grep "https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js; 
debian/dolfin-doc/usr/share/doc/dolfin-doc/* -r --files-with-matches | xargs 
sed 
"s|src=\"https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js|src=\"file:///usr/share/javascript/mathjax/unpacked/latest.js|g"
 -i
 
 # set petsc:Depends to something like "libpetsc-real3.8-dev, 
libslepc-real3.8-dev, python-petsc4py (>= 3.8), python-petsc4py (<< 3.9), 
python-slepc4py (>= 3.8), python-slepc4py (<< 3.9)"
 PETSC_DEV_DEPENDS="libpetsc-real$(PETSC_VERSION)-dev | 
libpetsc$(PETSC_UPSTREAM_VERSION)-dev, libslepc-real$(SLEPC_VERSION)-dev | 
libslepc$(SLEPC_UPSTREAM_VERSION)-dev"

Bug#989651: python3-sqlalchemy: Please package new upstream version

[Piotr Ożarowski]

Hi

> Please consider packaging the latest upstream version (currently 1.4.17) of 
> SQLAlchemy.

I will upload 1.4.X soon after Debian Bullseye is released

Bug#989652: vino

[Matthias Brennwald]

Package: vino
Version: 3.22.0-5
Severity: normal

Dear Maintainer

I have a server that provides a WiFi hotspot, and clients connect to the
server via the this WiFi hotspot. Sharing the server screen to the clients
works fine if the server is connected to another/wired network connection.
Once this other/wired connection is deactivated, the screen sharing stops
working.

As far as I can tell, the other/wired connection is not used in any way for
the data transfer involved with the screen sharing, as the clients are
connected to the server using the WiFi hotspot only. I would therefore
expect vino to handle the screen sharing in the same way, no matter if the
server is connected to the other/wired network or not.

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

Kernel: Linux 4.19.0-16-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 vino depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libavahi-client3 0.7-4+deb10u1
ii  libavahi-common3 0.7-4+deb10u1
ii  libavahi-glib1   0.7-4+deb10u1
ii  libc62.28-10
ii  libcairo21.16.0-4+deb10u1
ii  libgcrypt20  1.8.4-5
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgnutls30  3.6.7-4+deb10u6
ii  libgtk-3-0   3.24.5-1
ii  libice6  2:1.0.9-2
ii  libjpeg62-turbo  1:1.5.2-2+deb10u1
ii  libnotify4   0.7.7-4
ii  libsecret-1-00.18.7-1
ii  libsm6   2:1.2.3-1
ii  libx11-6 2:1.6.7-1+deb10u2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages vino recommends:
ii  gvfs  1.38.1-5

Versions of packages vino suggests:
ii  gnome-control-center  1:3.30.3-2~deb10u1

Bug#989648: clevis luks bind tpm2 issue

[Christoph Biedl]

Control: severity 989648 important
Control: tags 989648 confirmed upstream patch
Control: fixed 989648 12-1

Anton Lundin wrote...

> I'm playing around with a tpm which only supports sha256, and the clevis
> fails:
>
> # clevis luks bind -k X -d /dev/Y tpm2 '{"pcr_bank": "sha256",
> # "pcr_ids":"7"}'
> WARN: Ignore unsupported bank/algorithm: sha1(0x0004)
> ERROR: Unable to run tpm2_pcrlist
> Creating PCR hashes file failed!
>
> This is because a bug in clevis-tpm2:
> https://github.com/latchset/clevis/commit/67fc67c15fdf6fd053b261d123ae58d9e55f1991
>
> I suggest backporting that upstream fix to get clevis-tpm2 working
> with sha256 tpm's.

Hello,

thanks for reporting - since there is a buster point release in ten
days, there is a chance to have this fixed very soon. However, as I
cannot access my test hardware in that short time, can you confirm that
the patch mentioned fixes your issue, and there are no other related
issues that should get handled as well? (The latter since I'd really
like to avoid having to do another bugfix upload later.)

Since I'd need a day for the related paperwork, please reply by tomorrow
(June 10th) evening the latest. Else it would have to wait another two
or three months.

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#989650: tracker-miner: tracker-miner-fs starts indexing, search works while indexing, does not save index when finished

[Velophil]

Package: tracker-miner-fs
Version: 2.3.5-2
Severity: important
File: tracker-miner
X-Debbugs-Cc: velop...@philipsauter.com

Dear Maintainer,

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

   * What led up to the situation? -> fresh Debian 11 install on Thinkpad T450s
   * What exactly did you do (or not do) that was effective (or
 ineffective)? -> system started indexing correctly, tracker status showed 
number of indexed files and remaining time, search worked for the time of index 
in progress
   * What was the outcome of this action? -> after indexing was finished, 
tracker status showed 0 indexed files, searching offered no results, cold reset 
of tracker with same result
   * What outcome did you expect instead? -> save the indexed files, and 
working search function

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tracker-miner-fs depends on:
ii  init-system-helpers  1.60
ii  libc62.31-12
ii  libglib2.0-0 2.66.8-1
ii  libtracker-miner-2.0-0   2.3.6-2
ii  libtracker-sparql-2.0-0  2.3.6-2
ii  libupower-glib3  0.99.11-2
ii  procps   2:3.3.17-5
ii  tracker  2.3.6-2
ii  tracker-extract  2.3.5-2

tracker-miner-fs recommends no packages.

tracker-miner-fs suggests no packages.

-- no debconf information

Bug#989649: libjs-mathjax: integrate with dh_sphinxdoc

[Drew Parsons]

Package: libjs-mathjax
Version: 2.7.9+dfsg-1
Severity: normal

dh_sphinxdoc provides aids for automatically updating references to
.js scripts used in docs generated through sphinx.  In particular it
helps maintain privacy policies by removing the need to reference
external websites such as
https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.9/MathJax.js
from documentation.

At the moment mathjax is not integrating into the dh_sphinxdoc
capabilities. This means privacy hacks need to be made manually for
every package that uses math formatting in its rst or md docs.

Can mathjax be introduced to the dh_sphinxdoc system?


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libjs-mathjax depends on:
ii  fonts-mathjax  2.7.9+dfsg-1

libjs-mathjax recommends no packages.

Versions of packages libjs-mathjax suggests:
pn  fonts-mathjax-extras  
ii  fonts-stix1.1.1-4.1
pn  libjs-mathjax-doc 

-- no debconf information

Bug#989648: clevis luks bind tpm2 issue

[Anton Lundin]

Package: clevis-dracut
Version: 11-2+deb10u1

Hi.

I'm playing around with a tpm which only supports sha256, and the clevis
fails:

# clevis luks bind -k X -d /dev/Y tpm2 '{"pcr_bank": "sha256",
# "pcr_ids":"7"}'
WARN: Ignore unsupported bank/algorithm: sha1(0x0004)
ERROR: Unable to run tpm2_pcrlist
Creating PCR hashes file failed!


This is because a bug in clevis-tpm2: 
https://github.com/latchset/clevis/commit/67fc67c15fdf6fd053b261d123ae58d9e55f1991

I suggest backporting that upstream fix to get clevis-tpm2 working
with sha256 tpm's.


//Anton

Bug#820838: os-prober: 40grub2 does not handle multiple initrd paths

[Simon McVittie]

Control: unmerge 820838 838177
Control: forwarded 820838 
https://salsa.debian.org/installer-team/os-prober/-/merge_requests/8
Control: retitle 838177 grub-common: grub.d/30_os-prober does not handle 
multiple initrd paths
Control: reassign 838177 grub-common 2.02+dfsg1-20
Control: forwarded 838177 https://savannah.gnu.org/bugs/index.php?47681

A recap of this bug for maintainers, since it has been a while:

In Arch Linux and its derivatives like Manjaro, instead of concatenating
CPU microcode and early user-space into a single initrd blob like we
do in Debian, the CPU microcode and the rest of early user-space are
supplied as two separate initrd archives. When Debian's grub integration
scripts detect other operating systems, they successfully identify Arch
Linux and add it to Debian's grub menu, but only the first initrd gets
added to grub.cfg, resulting in boot failure for the Arch menu entry
(because the first initrd happens to be the CPU microcode, so early
user-space is missing).

I can reproduce this on a Debian 11 test system that dual-boots into Arch,
by running update-grub and grub-install while booted into Debian 11.

Solving this requires changes in two packages: os-prober and grub-common.
I have verified that with the patches attached here, Debian's grub menu
boots Arch successfully. Unfortunately, I think we might be in a situation
where grub is waiting for os-prober and os-prober is waiting for grub.

For os-prober, the patch supplied by "General Chaos" in 2016 seems good.
I attach a clean version without the change to the Maintainer field, and
a follow-up patch that just reindents it to match the prevailing style.
Please see attached os-prober-*.patch or the merge request
.

On Thu, 23 Feb 2017 at 10:56:22 +0100, Johannes Rohr wrote:
> I've tested the patch. The initrd stanza generated is not totally correct:
> 
> іnitrd /boot/intel-ucode.img^/boot/initramfs-linux-pf.img
> 
> (note the ^ where there should be a blank)

This is a bug in integration scripts supplied by grub2: after
modifying os-prober to be able to emit more than one initrd, it
is also necessary to modify the corresponding script in grub2 to
be able to consume more than one initrd. "General Chaos" proposed
a patch upstream in 2016, which upstream said would be OK to apply
after os-prober was fixed, but there was never a Debian bug report
specifically for this. I'm repurposing 838177 to be that Debian
bug report. Please see attached grub2-*.patch or the merge request
.

At this stage in the freeze these changes seem unlikely to make it into
Debian 11, but it would be great if they can be landed at the beginning
of the Debian 12 cycle, or perhaps even incorporated into a Debian 11
point release.

Thanks,
smcv
>From 1f982e2a7c35e14d5a92c76db998afafd1bd9e87 Mon Sep 17 00:00:00 2001
From: General Chaos 
Date: Tue, 12 Apr 2016 22:28:52 +
Subject: [PATCH] os-prober: Allow initrd to contain spaces

linux-boot-prober produces structured output with newline-terminated rows
representing kernels, each with colon-delimited columns. We translate
this into a sequence of space-separated words representing kernels,
each containing colon-delimited fields where spaces are represented by
carets.

When we parse each of those words into colon-delimited fields, if the
field could conceivably contain spaces then we need to translate
carets back into spaces. We did this for label and parameters, but not
for the initrd.

In particular, when CPU microcode is installed on Arch Linux or its
derivatives, they write CPU microcode into one initrd archive and the
rest of early user-space into another, instead of concatenating the
archives into a single file like Debian derivatives do. To boot Arch
successfully from the grub menu, we need to add all of their initrds
to the grub menu entry (detecting this situation requires an os-prober
patch, for which see ).

[Commit message added by Simon McVittie ]

Bug: https://savannah.gnu.org/bugs/index.php?47681
Bug-Debian: https://bugs.debian.org/838177
Forwarded: https://savannah.gnu.org/bugs/index.php?47681
Closes: #838177
---
 util/grub.d/30_os-prober.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/util/grub.d/30_os-prober.in b/util/grub.d/30_os-prober.in
index da5f28876..d0609d9a4 100644
--- a/util/grub.d/30_os-prober.in
+++ b/util/grub.d/30_os-prober.in
@@ -243,7 +243,7 @@ EOF
 LBOOT="`echo ${LINUX} | cut -d ':' -f 2`"
 LLABEL="`echo ${LINUX} | cut -d ':' -f 3 | tr '^' ' '`"
 LKERNEL="`echo ${LINUX} | cut -d ':' -f 4`"
-LINITRD="`echo ${LINUX} | cut -d ':' -f 5`"
+LINITRD="`echo ${LINUX} | cut -d ':' -f 5 | tr '^' ' '`"
 LPARAMS="`echo ${LINUX} | cut -d ':' -f 6- | tr '^' ' '`"
 
 if [ -z "${LLABEL}" ] ; then
-- 
2.32.0

>From 7641c2da0c81f78c5f2ee2a66a1c21350cab03fc 

Bug#989629: ITP: elementary-code -- Essential code editor with tab support

[Nicholas D Steeves]

Hi Francisco!

On Tue, 8 Jun 2021 at 23:51, Francisco M Neto  wrote:
>
> Elementary Code earlier called Scratch, is an IDE
> designed with simplicity in mind. It offers essential functionalities
> such as git support, multi-panel and miniview support and extensions
> for integration with the Terminal and web visualization.
>
> It is written from scratch, with support for plugins. Its purpose is
> to be lightweight and extensible, with plenty of customization
> options. It support syntax highlighting for a wide range of
> programming languages.
>
> It is a minimalist, extensible GTK-based IDE that is not dependent
> on GNOME. It follows the Elementary Human Interface Guidelines.

Cool :-)  By the way, how is Elementary Code, an IDE?  Upstream calls
it a "[code-specific] text-editor" here (
https://medium.com/elementaryos/scratch-is-now-code-2838e03134c7 ),
and it sounds like Code is intended to be like Atom, "a hackable text
editor" ( https://atom.io ), rather than something like GNOME Builder
or XCode ( 
https://www.reddit.com/r/linux/comments/7oi8nf/scratch_text_editor_is_now_elementary_code/dsafxmb/?utm_source=reddit_medium=web2x=3
).

If you'd like to use "IDE" in the long description to make it
discoverable with keyword or regex searches, maybe something could be
written about how Code is more than a text editor, but that it's for
people who don't want a full-featured IDE?  Does it support templates,
macros, code folding, any kind of linting or language server-based IDE
features (LSP), tab completion of variable, function, or class names,
etc?  More simply, does it have an LSP plugin like
https://github.com/atom-community/atom-languageclient or is one
planned?  Ideally it'd be nice if upstream could make a statement
about their vision and objectives for Code on its homepage
https://github.com/elementary/code

Because you use the keyword "minimalist", I wonder if the authors of
this software (and perhaps yourself) believe that full-featured IDEs
are not the best way to work ;-)  Not being an IDE can be a desirable
feature, after all!

Regards,
Nicholas

Bug#989632: dash: remove unnecessary diversion of /bin/sh

[Helmut Grohne]

Hi Jonathan,

it's rare for me to receive such detailed and quick feedback on a patch.
Thank you very much!

On Wed, Jun 09, 2021 at 12:40:58AM -0700, Jonathan Nieder wrote:
> My ideal would be to go even further and not include /bin/sh in any
> shell's package (in other words, to treat the symlink something like a
> configuration file).  That way, one could bootstrap with any choice of
> shell instead of dash needing to be essential.

Oh. That's an interesting vision. Personally, I was hoping that dash
could keep being the primary provider of /bin/sh and that we could make
bash non-essential. Non-essential dash seems a little utopical to me.

> We're already closer to that ideal than we used to be, since bash
> doesn't ship /bin/sh nowadays; only dash does.

I don't quite understand how we are closer now that we have two
essential shells instead of just one, but I'll try to follow.

> What would be required to make that work?
> 
>  1. On initial install (bootstrap), we need to be able to run preinst
> for essential packages.  Most preinsts are shell scripts with
> /bin/sh shebang, so this means that one of the following would
> have to happen:
> 
>  1a. run preinst for dash before any other package; it could use
>  e.g. a #!/usr/bin/perl script to install the /bin/sh symlink

Difficult. The Debian policy explicitly keeps itself muted on what
happens during installation bootstrap. Such ordering is already frowned
upon and not a very reliable method as we have seen numerous times in
the past. In any case, we don't have any metadata that would allow us to
express such ordering.

>  1b. as custom logic in the bootstrap utility, write the /bin/sh
>  symlink

What do you mean with "the bootstrap utility"? debootstrap?
cdebootstrap? multistrap? mmdebstrap? zdebootstrap? People using bare
apt?

I don't think we want to go down this road.

> 1b'. introduce a new maintainer script that is specifically for
>  bootstrapping.  (I would love this; it's probably worth a
>  separate DEP, but it's overkill for this application alone.)

This one sounds sane to me. My primary motivation for working on this
bug happens to be improving the installation bootstrap to cover more use
cases. A quite central document on this work is
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap. As it happens,
there is a proposal asking quite precisely for what you ask here.

>  1c. include the /bin/sh symlink in a separate "sh-is-dash"
>  package

Likely base-files would depend on sh-is-dash | sh-is-bash | sh-is-...
I suppose that this approach would just work. It feels a bit excessive
in terms of small packages.

> Of these, 1b seems simple enough so it's surmountable.

Much to the contrary, 1b is the one that I'd rule out first due to the
existing zoo of bootstrap utilities.

>  2. On upgrade of dash in existing systems, we need to avoid removing
> the /bin/sh symlink:

I'm skipping the upgrade path, because I generally think that it is
solvable if we can form consensus on the goal.

>  3. After an upgrade, we want to end up with a clean state with no
> diversions.  We could handle that by removing the diversion in
> dash's postinst.

That much we agree on. I might put this to a weaker form though. The
default case (sh is dash) should work without diversions. I'm less sure
that non-default must work without diversions and that dash needs to be
non-essential.

You did not manage to fully convince me of the world where dash is no
longer essential. What you write feels to sketchy to me and I don't see
that much benefit, because dash is so small and widely used that I
wouldn't invest any time into that future. Non-essential bash is a
different story. Getting there actually requires fixing the diversion
mess left behind. :)

> Upshot: the proposal below doesn't bring us closer to that ideal, but
> it doesn't bring us further away either.  And I like the idea of
> making the default configuration simpler.

\o/

> nit: this should say "removing" instead of "taking over".

Fixed. Thanks.

> > # ourselves on behalf of bash.
> > dpkg-divert --package dash --no-rename --remove $dfile
> > echo "This should never be reached"
> > exit 1
> 
> Isn't this reachable now, in the "$diverter" = dash case?  Or is the idea that
> the drop_obsolete_diversion case is meant to have taken care of that?  I think
> treating this as reachable would make the code easier to reason about (and 
> then
> we can simplify further after this code has been live in one stable release).

drop_obsolete_diversion should have removed any diversion owned by dash.
For that reason, this code should be unreachable.

> I find the new control flow harder to follow: it takes longer to get
> the "what do we do if we're already in a good state?" case out of the
> way, and it splits up the other cases.

Swapped and separated.

> Doesn't this make this 'elif' 

Bug#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11

[Adrian Bunk]

On Sun, Jun 06, 2021 at 10:18:34AM +0200, Jan Gruber wrote:
>...
> Therefore it looks like to me, that the error stems from some
> changes related to glibc 2.31-11 (or maybe even the kernel in Version
> 5.10.0.6).
>...

Everything about this bug looks like better compiler optimization 
hitting code with a latent bug, and as expected using either gcc-9
or -O2 "fixes" the problem.

-fsanitize=undefined finds:
util.h:11:26: runtime error: shift exponent -8 is negative
util.h:11:44: runtime error: shift exponent -8 is negative

The buggy code is:
https://salsa.debian.org/pkg-security-team/aeskeyfind/-/blob/debian/master/aes.h#L14-15
https://salsa.debian.org/pkg-security-team/aeskeyfind/-/blob/debian/master/util.h#L11

> Best regards,
>    Jan
>...

cu
Adrian

Bug#971065: korganizer: org.kde.korgac.desktop executable

[Diederik de Haas]

On zondag 27 september 2020 07:39:42 CEST Helge Kreutzmann wrote:
> Package: korganizer
> Version: 4:20.04.1-2
> Severity: minor
> 
> In the logs I get the following error message:
> Aug 15 21:46:20 samd systemd[232194]: Configuration file
> /etc/xdg/autostart/org.kde.korgac.desktop is marked executable. Please
> remove executable permission bits. Proceeding anyway.
> 
> And indeed, it is the only executable desktop file in this directory.
> 
> Please consider removing the executable bit.

If I download the .deb file and look inside it, that file has 644 permissions, 
iow no executable bit set.

https://invent.kde.org/pim/korganizer/-/commit/14138650407be94cdecabecd40d1435420df8fdd
is the upstream commit from 2017-03-02 where the executable bit
was removed.
I don't know why +x is set on your system, but the package seem fine.

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

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Sebastiaan Couwenberg]

On 6/9/21 12:11 PM, Andreas Beckmann wrote:
> On 08/06/2021 11.56, Andreas Beckmann wrote:
>> gdal can rename gdal-data to gdal3-data, build with
>> --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
>> Thus libgdal20 + gdal-data from buster should be co-installable with
>> libgdal28 + gdal3-data from bullseye and survive the upgrade if needed.
>>
>> A patch doing this is attached, I'm now testing the upgrade paths
>> (along the introduction of the libhdf5*-103 metapackages).
> 
> If the gdal-data issue is solved, the next problem shows up:
> 
> libgdal20 Depends: libogdi3.2
> libgdal28 Depends: libogdi4.1
> 
> but the two ogdi library packages are not co-installable (both ship
> plugins in the same unversioned path).
> 
> So even if we fix hdf5, libgdal20 is unlikely to be able to survive
> upgrades from buster. (Sime something that was built against libgdal20
> in buster now likely depends on libgdal28 in bullseye)
> But I'd still like to add a Breaks: libgdal20 to libgdal28 to make this
> explicit, since transitive Breaks don't work well.

I'm only willing to update gdal in unstable if the 3.2.2+dfsg-1 changes
don't need to be reverted. Since that goes against the freeze policy,
that's highly unlikely as the RMs seem unwilling to make exceptions.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#989647: With glib2 2.68 gdebi is an FTBFS (hangs)

[Christian Ehrhardt]

Package: gdebi
Version: 0.9.5.7+nmu5

At build time it is getting stuck until a timeout kills it:

For example in Ubuntu here:
https://launchpadlibrarian.net/542966965/buildlog_ubuntu-impish-amd64.gdebi_0.9.5.7+nmu5_BUILDING.txt.gz

This isn't a problem yet as 2.68 is only in experimental for now.

Log:
```
running build_ext
test_simple (tests.test_gdebi_gtk.GDebiGtkTestCase) ...
WARNING:root:Error loading logo gtk-icon-theme-error-quark: Icon
'gnome-mime-application-x-deb' not present in theme Yaru (0)

(setup.py:7825): Gtk-WARNING **: 05:55:50.408: Error loading theme
icon 'dialog-error' for stock: Icon 'dialog-error' not present in
theme Yaru
E: Build killed with signal TERM after 150 minutes of inactivity
```

This is reproducible locally and the process tree looks like:

F   UID PIDPPID PRI  NIVSZ   RSS WCHAN  STAT TTYTIME COMMAND
4 0   39842   0  20   0   9328  3000 do_wai Ss   pts/2  0:00 bash
0 0   40835   39842  20   0  22136 13032 do_wai S+   pts/2
0:00  \_ /usr/bin/perl /usr/bin/debuild -i -us -uc -b
0 0   40852   40835  20   0   7392   604 pipe_w S+   pts/2
0:00  \_ tee ../gdebi_0.9.5.7+nmu5_amd64.build
0 0   40853   40835  20   0  25328 16328 do_wai S+   pts/2
0:00  \_ /usr/bin/perl /usr/bin/dpkg-buildpackage -us -uc -ui -i
-b
0 0   40891   40853  20   0   7764  1616 do_wai S+   pts/2
0:00  \_ /usr/bin/make -f debian/rules build
0 0   40892   40891  20   0  24356 15260 do_wai S+   pts/2
0:00  \_ /usr/bin/perl /usr/bin/dh build --with python3
--buildsystem pybuild
0 0   41533   40892  20   0   7764  1572 do_wai S+   pts/2
0:00  \_ /usr/bin/make -f debian/rules
override_dh_auto_test
0 0   41535   41533  20   0   2620  1320 do_wai S+   pts/2
0:00  \_ /bin/sh /usr/bin/xvfb-run -a python3.9
setup.py test
4 0   41545   41535  20   0 1034648 37536 ep_pol Sl+ pts/2
0:00  \_ Xvfb :99 -screen 0 1280x1024x24
-nolisten tcp -auth /tmp/xvfb-run.RlZdX8/Xauthority
0 0   41560   41535  20   0 1331396 131060 poll_s Sl+ pts/2
0:01  \_ python3.9 setup.py test


>From there the test is stuck.
Some debugging revealed that it does no more come back from:
GDebiGtkTestCase
 -> test_lintian
  -> GDebiGtk (init)
-> gio_copy_in_place
  -> show_alert

That alert only happens because we run as root, but even if that is avoided
(e.g. by running as another user) then it blocks at the next message. E.g.
when failing to download.

But these blocking alerts are only secondary symptoms.

I've found that all issues come back to a check that seems wrong.
The test wants to copy a non-existing file into a temp path.
At least the current version of Gio.File hates this and errors out
  g-io-error-quark: Operation not supported (15)

Maybe Gio was more tolerant in the past, but checking a non existing
file makes no sense anyway. We can guard that step a bit better than all works.

A fix could look like:
--- /home/ubuntu/gdebi-0.9.5.7+nmu5/GDebi/GDebiGtk.py 2021-06-09
10:17:06.516869439 +
+++ /root/gdebi-0.9.5.7+nmu5/GDebi/GDebiGtk.py 2021-06-09
10:09:35.113662314 +
@@ -119,7 +119,8 @@
  self.on_window_main_drag_data_received)

 # Check file with gio
-file = self.gio_copy_in_place(file)
+if file != "" and os.path.exists(file):
+file = self.gio_copy_in_place(file)

 #self.vte_terminal.set_font_from_string("monospace 10")
 self.cprogress = self.CacheProgressAdapter(self.progressbar_cache)

I've proposed the same to the project [1], but I'm unsure about the speed this
is picked up there - so to avoid this being broken once the switch to 2.68
happens I filed this bug for you.

[1]: https://code.launchpad.net/~paelzer/gdebi/gdebi-fix-glib-2.68/+merge/403954

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#989646: [Pkg-samba-maint] Bug#989646: samba: Samba AD backup does not work with includes in smb.conf

[Andrew Bartlett]

Please file your issue upstream at bugzilla.samba.org.  I've sent you
an invite.  Like this BTS, is is a public bug tracker, so if that isn't
OK then just ignore the mail, otherwise that is a much better place to
make this request.

Debian has not resources to develop Samba patches, won't carry not-
upstream patches in any case and and doesn't in general backport them
anyway (due resources), so it just makes much more sense to work with
us upstream.

Sorry!

Andrew Bartlett
-- 
Andrew Bartlett (he/him)   https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Samba Development and Support, Catalyst IT - Expert Open Source
Solutions

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Andreas Beckmann]

On 08/06/2021 11.56, Andreas Beckmann wrote:

gdal can rename gdal-data to gdal3-data, build with
--datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
Thus libgdal20 + gdal-data from buster should be co-installable with
libgdal28 + gdal3-data from bullseye and survive the upgrade if needed.

A patch doing this is attached, I'm now testing the upgrade paths
(along the introduction of the libhdf5*-103 metapackages).


If the gdal-data issue is solved, the next problem shows up:

libgdal20 Depends: libogdi3.2
libgdal28 Depends: libogdi4.1

but the two ogdi library packages are not co-installable (both ship 
plugins in the same unversioned path).


So even if we fix hdf5, libgdal20 is unlikely to be able to survive 
upgrades from buster. (Sime something that was built against libgdal20 
in buster now likely depends on libgdal28 in bullseye)
But I'd still like to add a Breaks: libgdal20 to libgdal28 to make this 
explicit, since transitive Breaks don't work well.


Andreas

Bug#989645: /usr/sbin/grub-mkconfig: dpkg: error processing package linux-image-powerpc (--configure):

[John Paul Adrian Glaubitz]

Control: severity -1 normal

Hello Rick!

On 6/9/21 11:15 AM, Rick Thomas wrote:
> Package: grub-common
> Version: 2.04-18
> Severity: grave
> File: /usr/sbin/grub-mkconfig
> Justification: renders package unusable

Since powerpc is not a release architecture, setting the severity to "grave" is 
not
allowed here. I am therefore downgrading this to "normal".

> This is what happens when I attempt to do "aptitude full-upgrade" on my 
> PowerPC machine:
> 
> root@dillserver:/home/rbthomas# aptitude full-upgrade
> The following partially installed packages will be configured:
>   linux-image-5.10.0-7-powerpc linux-image-powerpc 
> No packages will be installed, upgraded, or removed.
> 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B of archives. After unpacking 0 B will be used.
> Setting up linux-image-5.10.0-7-powerpc (5.10.40-1) ...
> /etc/kernel/postinst.d/initramfs-tools:
> update-initramfs: Generating /boot/initrd.img-5.10.0-7-powerpc
> /etc/kernel/postinst.d/zz-update-grub:
> /usr/sbin/grub-mkconfig: 257: cannot create /boot/grub/grub.cfg.new: 
> Read-only file system

Your HFS filesystem on /boot/grub is read-only. This is not related to GRUB but
to either your custom environment or something in the partitioning setup in d-i
that I need to fix.

Adrian

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

Bug#989433: tcpdump: -Z doesn't seem to work properly

[Romain Francoise]

Hi,

On Thu, Jun 3, 2021 at 7:30 PM Dennis Boone  wrote:
> The following session was executed as root:
>
> ozymandias 179 # tcpdump -r /tmp/ax0.cap -Z root
> tcpdump: /tmp/ax0.cap: Permission denied
> ozymandias 180 # tcpdump -r /tmp/ax0.cap -Z tcpdump
> tcpdump: /tmp/ax0.cap: Permission denied
> ozymandias 181 # dir /tmp/ax0.cap
> -rw-r--r-- 1 tcpdump tcpdump 434176 jun  3 11:41 /tmp/ax0.cap
>
> Order of the "-r" and "-Z" options make no difference.

Thanks for the report. Is there anything specific to your setup that
could explain this? I can't reproduce it and as described it seems
surprising that root would get EPERM no matter what -Z option is used.
What are the mount options on /tmp? Does this file have extended
attributes?

Bug#989041: eterm: CVE-2021-33477

[Utkarsh Gupta]

Hi Jose,

Patch attached. Please let me know if I can upload to unstable
directly? This also needs to go to buster-pu.

Let me know if you have questions or concerns.


- u
--- a/src/term.c
+++ b/src/term.c
@@ -1176,6 +1176,11 @@
 case 'E':
 scr_add_lines((unsigned char *) "\n\r", 1, 2);
 break;
+/*
+ disabled because embedded newlines can make exploits easier
+ https://github.com/exg/rxvt-unicode/commit/2e7149935839bb7aa69b5bfe9558ba449e4db363
+ */
+#if 0
 case 'G':
 if ((ch = cmd_getc()) == 'Q') { /* query graphics */
 tt_printf((unsigned char *) "\033G0\n");/* no graphics */
@@ -1185,6 +1190,7 @@
 } while (ch != ':');
 }
 break;
+#endif
 case 'H':
 scr_set_tab(1);
 break;

Bug#989642: budgie-desktop-view: Right-clicking on the wallpaper canvas: missing items

[David Mohammed]

Remember to tick the enable desktop icons option in budgie desktop settings.

The number of options available for the desktop icons implementation
is limited as per upstream's README
https://github.com/getsolus/budgie-desktop-view.

If you want a fully featured desktop icons interface then
desktop-folder or nemo-desktop are also supported options - you enable
those through a org.solus-project dconf option - remember to uninstall
budgie-desktop-view.

On Wed, 9 Jun 2021 at 09:45, krikom  wrote:
>
> Package: budgie-desktop-view
> Version: 1.1.1-1
> Severity: normal
> X-Debbugs-Cc: whiteredcoo...@gmail.com
>
> Dear Maintainer,
>
> right-clicking on the wallpaper canvas ("desktop") just returns 2 items: 
> "Budgie Desktop Settings"
> and "System Settings". Instead, many more items shoud appear, including icons 
> sorting options.
> Also, it's impossible to right-click on desktop icons.
>
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages budgie-desktop-view depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
> ii  libc62.31-12
> ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
> ii  libglib2.0-0 2.66.8-1
> ii  libgtk-3-0   3.24.24-4
>
> budgie-desktop-view recommends no packages.
>
> budgie-desktop-view suggests no packages.
>
> -- no debconf information

Bug#989646: samba: Samba AD backup does not work with includes in smb.conf

[Juergen Pfennig]

Package: samba
Version: 2:4.13.5+dfsg-2
Severity: normal

Dear Maintainer,

As 'basic samba' is deprecated more sites have to use a samba full ad setup.
This causes some implementation problems to affect more sites. Using ad,
for maintenance on will have to create ad backups using 'samba-tool' as
decribed at:

   https://wiki.samba.org/index.php/Back_up_and_Restoring_a_Samba_AD_DC

This procedure fails when your smb.conf contains "include" statements.
The error-generated message is meaningless, the python code does not
help, the smb.conf parser is not implemented in python (is native code).

There are good reasons to use includes, in my case some of the included
data is auto-generated by other tools. Here is my (simplified) smb.conf:

[global]
realm = CENTAURI.HOME
server role = active directory domain controller
workgroup = CENTAURI
dns forwarder = 127.0.0.2
idmap_ldb:use rfc2307 = yes
kdc:server ticket lifetime = 60
kdc:user ticket lifetime = 60
kdc:user renewal lifetime = 189
###
   include = /etc/samba/networks.conf
###
netbios name = ALPHA1
netbios aliases = ALPHA
disable netbios = no
###
   include = /etc/samba/services.conf
###
[netlogon]
path = /var/lib/samba/sysvol/centauri.home/scripts
read only = No
[sysvol]
path = /var/lib/samba/sysvol
read only = No

Thanks
Jürgen

-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf present, but not attached

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages samba depends on:
ii  adduser  3.118
ii  dpkg 1.20.9
ii  init-system-helpers  1.60
ii  libbsd0  0.11.3-1
ii  libc62.31-12
ii  libgnutls30  3.7.1-3
ii  libldb2  2:2.2.0-3.1
ii  libpam-modules   1.4.0-7
ii  libpam-runtime   1.4.0-7
ii  libpopt0 1.18-2
ii  libpython3.9 3.9.2-1
ii  libtalloc2   2.3.1-2+b1
ii  libtasn1-6   4.16.0-2
ii  libtdb1  1.4.3-1+b1
ii  libtevent0   0.10.2-1
ii  libwbclient0 2:4.13.5+dfsg-2
ii  lsb-base 11.1.0
ii  procps   2:3.3.17-5
ii  python3  3.9.2-3
ii  python3-dnspython2.0.0-1
ii  python3-samba2:4.13.5+dfsg-2
ii  samba-common 2:4.13.5+dfsg-2
ii  samba-common-bin 2:4.13.5+dfsg-2
ii  samba-libs   2:4.13.5+dfsg-2
ii  tdb-tools1.4.3-1+b1

Versions of packages samba recommends:
ii  attr1:2.4.48-6
ii  logrotate   3.18.0-2
ii  python3-markdown3.3.4-1
ii  samba-dsdb-modules  2:4.13.5+dfsg-2
ii  samba-vfs-modules   2:4.13.5+dfsg-2

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
ii  ldb-tools  2:2.2.0-3.1
ii  ntp1:4.2.8p15+dfsg-1
pn  smbldap-tools  
pn  ufw
ii  winbind2:4.13.5+dfsg-2

-- no debconf information

Bug#989645: /usr/sbin/grub-mkconfig: dpkg: error processing package linux-image-powerpc (--configure):

[Rick Thomas]

Package: grub-common
Version: 2.04-18
Severity: grave
File: /usr/sbin/grub-mkconfig
Justification: renders package unusable
X-Debbugs-Cc: debian-powe...@lists.debian.org, glaub...@physik.fu-berlin.de, 
rbtho...@pobox.com

This is what happens when I attempt to do "aptitude full-upgrade" on my PowerPC 
machine:

root@dillserver:/home/rbthomas# aptitude full-upgrade
The following partially installed packages will be configured:
  linux-image-5.10.0-7-powerpc linux-image-powerpc 
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Setting up linux-image-5.10.0-7-powerpc (5.10.40-1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.10.0-7-powerpc
/etc/kernel/postinst.d/zz-update-grub:
/usr/sbin/grub-mkconfig: 257: cannot create /boot/grub/grub.cfg.new: Read-only 
file system
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 2
dpkg: error processing package linux-image-5.10.0-7-powerpc (--configure):
 installed linux-image-5.10.0-7-powerpc package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-powerpc:
 linux-image-powerpc depends on linux-image-5.10.0-7-powerpc (= 5.10.40-1); 
however:
  Package linux-image-5.10.0-7-powerpc is not configured yet.

dpkg: error processing package linux-image-powerpc (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-5.10.0-7-powerpc
 linux-image-powerpc
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up linux-image-5.10.0-7-powerpc (5.10.40-1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.10.0-7-powerpc
/etc/kernel/postinst.d/zz-update-grub:
/usr/sbin/grub-mkconfig: 257: cannot create /boot/grub/grub.cfg.new: Read-only 
file system
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 2
dpkg: error processing package linux-image-5.10.0-7-powerpc (--configure):
 installed linux-image-5.10.0-7-powerpc package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-powerpc:
 linux-image-powerpc depends on linux-image-5.10.0-7-powerpc (= 5.10.40-1); 
however:
  Package linux-image-5.10.0-7-powerpc is not configured yet.

dpkg: error processing package linux-image-powerpc (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-5.10.0-7-powerpc
 linux-image-powerpc
 
-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/dill-root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/mapper/dill-home /home ext4 rw,relatime 0 0
/dev/sda3 /boot ext2 rw,relatime 0 0
/dev/sda2 /boot/grub hfs ro,relatime,uid=0,gid=0 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_apple
insmod lvm
insmod ext2
set 
root='lvmid/KyeuOm-Fceg-PCoI-LcmV-eVLL-RnL7-Xh0WT4/Ut9qE2-72vC-tTDE-XyVH-6Z0i-GXy3-lyyiCh'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/KyeuOm-Fceg-PCoI-LcmV-eVLL-RnL7-Xh0WT4/Ut9qE2-72vC-tTDE-XyVH-6Z0i-GXy3-lyyiCh'
  9151f254-2918-4435-bd1c-9a0e70edfdf7
else
  search --no-floppy --fs-uuid --set=root 9151f254-2918-4435-bd1c-9a0e70edfdf7
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set 

Bug#866502: ITP: element-web: web-based matrix client

[Jonas Smedegaard]

Hi Robbi,

Quoting Robbi Nespu (2021-06-09 05:11:47)
> Hello! Is there any update for this ITP?
> If there is pending issue, where I can take a look the existing work?

Preparations was done privately till now.  Thanks to your sharing 
interest in it, I have now pushed my (still preliminary) work and will 
from now on maintain it publicly at 
https://salsa.debian.org/matrix-team/matrix-element

As is common for Node.js projects, the pending issues are a range of 
Node.js libraries not yet packaged for Debian - see e.g. the commented 
out lines at 
https://salsa.debian.org/matrix-team/matrix-element/-/blob/debian/latest/debian/control

In case you (or others reading this) want to help, then concretely the 
most urgently needed library is cpx - but you are welcome to dive in and 
package any of the missing libraries, of course :-).


Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#989371: Update

[Rich]

I have learned after someone else pointed it out to me that this bug
got a CVE - CVE-2019-13045.

Bug#989643: unblock: formiko/1.3.0

[Ondřej Tůma]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: mc...@zeropage.cz

Please unblock package formiko

[ Reason ]
I was fix the errors.

[ Impact ]
Formiko package will be still in Debian.

[ Tests ]
Package has two simple tests.

[ Risks ]
No risks

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing
diff -Nru formiko-1.3.0/debian/control formiko-1.3.0/debian/control
--- formiko-1.3.0/debian/control2018-01-16 08:48:07.0 +0100
+++ formiko-1.3.0/debian/control2021-05-25 12:43:39.0 +0200
@@ -6,10 +6,11 @@
  debhelper (>= 11),
  dh-python,
  python3-all,
+ python3-docutils,
  python3-setuptools,
 Standards-Version: 4.1.3
 Homepage: https://github.com/ondratu/formiko
-X-Python3-Version: >= 3.2
+X-Python3-Version: >= 3.8
 Vcs-Git: https://github.com/ondratu/formiko-debian.git
 Vcs-Browser: https://github.com/ondratu/formiko-debian
 
@@ -19,6 +20,7 @@
  gir1.2-gtksource-3.0,
  gir1.2-gtkspell3-3.0,
  gir1.2-webkit2-4.0,
+ librsvg2-common,
  python3-docutils,
  python3-gi,
  python3-recommonmark,
diff -Nru formiko-1.3.0/debian/changelog formiko-1.3.0/debian/changelog
--- formiko-1.3.0/debian/changelog  2018-01-16 08:48:07.0 +0100
+++ formiko-1.3.0/debian/changelog  2021-05-25 12:43:39.0 +0200
@@ -1,3 +1,26 @@
+formiko (1.3.0-2) unstable; urgency=medium
+
+  [ Sebastien Bacher ]
+  * debian/control:
+- Depends on librsvg2-common, the svg loader is needed and used to
+  be pulled in by indirect depends but isn't anymore (Closes: #964511)
+
+  [ Debian Janitor ]
+  * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
+Repository-Browse.
+  * Replace use of deprecated $ADTTMP with $AUTOPKGTEST_TMP.
+
+  [ Ondřej Tůma ]
+  * debian/tests/control:
+- Mark tests as superficial (Closes: #974458)
+  * debian/watch:
+- changed - pypi doesn't support signatures
+  * debian/control:
+- Depends on python3-docutils, which is need for it's main functionality
+- Bump X-Python3-Version to 3.8 which is recommended by authors
+
+ -- Ondřej Tůma   Tue, 25 May 2021 12:43:39 +0200
+
 formiko (1.3.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru formiko-1.3.0/debian/tests/control formiko-1.3.0/debian/tests/control
--- formiko-1.3.0/debian/tests/control  2018-01-16 08:48:07.0 +0100
+++ formiko-1.3.0/debian/tests/control  2021-05-25 12:43:39.0 +0200
@@ -1,6 +1,7 @@
 Test-Command: formiko --help
 Depends: python3-all, formiko
-Restrictions: allow-stderr
+Restrictions: allow-stderr, superficial
 
-Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd 
"$ADTTMP" ; echo "Testing with $py:" ; $py -c "import formiko; print(formiko)" 
; done
+Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd 
"$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import formiko; 
print(formiko)" ; done
 Depends: python3-all, formiko
+Restrictions: superficial
diff -Nru formiko-1.3.0/debian/upstream/metadata 
formiko-1.3.0/debian/upstream/metadata
--- formiko-1.3.0/debian/upstream/metadata  1970-01-01 01:00:00.0 
+0100
+++ formiko-1.3.0/debian/upstream/metadata  2021-05-25 12:43:39.0 
+0200
@@ -0,0 +1,5 @@
+---
+Bug-Database: https://github.com/ondratu/formiko/issues
+Bug-Submit: https://github.com/ondratu/formiko/issues/new
+Repository: https://github.com/ondratu/formiko.git
+Repository-Browse: https://github.com/ondratu/formiko
diff -Nru formiko-1.3.0/debian/watch formiko-1.3.0/debian/watch
--- formiko-1.3.0/debian/watch  2018-01-16 08:48:07.0 +0100
+++ formiko-1.3.0/debian/watch  2021-05-25 12:43:39.0 +0200
@@ -1,5 +1,5 @@
 # Compulsory line, this is a version 4 file
 version=4
 
-opts=uversionmangle=s/(rc|a|b|c)/~$1/,pgpsigurlmangle=s/$/.asc/ \
+opts=uversionmangle=s/(rc|a|b|c)/~$1/ \
 
https://pypi.debian.net/formiko/formiko-(.+)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))

Bug#989642: budgie-desktop-view: Right-clicking on the wallpaper canvas: missing items

[krikom]

Package: budgie-desktop-view
Version: 1.1.1-1
Severity: normal
X-Debbugs-Cc: whiteredcoo...@gmail.com

Dear Maintainer,

right-clicking on the wallpaper canvas ("desktop") just returns 2 items: 
"Budgie Desktop Settings"
and "System Settings". Instead, many more items shoud appear, including icons 
sorting options.
Also, it's impossible to right-click on desktop icons.


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages budgie-desktop-view depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  libc62.31-12
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4

budgie-desktop-view recommends no packages.

budgie-desktop-view suggests no packages.

-- no debconf information

Bug#989641: ITP: simplematch -- Minimal, super readable string pattern matching for Python

[Frédéric Bonnard]

Package: wnpp
Owner: Frédéric Bonnard 
Severity: wishlist

* Package name: simplematch
  Version : 1.3
  Upstream Author : Thomas Feldmann 
* URL : https://github.com/tfeldmann/simplematch
* License : Expat
  Programming Lang: Python
  Description : Minimal, super readable string pattern matching for Python

simplematch aims to fill a gap between parsing with str.split() and
regular expressions. It should be as simple as possible, fast and
stable.
The simplematch syntax is transpiled to regular expressions under the
hood, so matching performance should be just as good.

This small library is a dependency of "organize" tool that I intend to
package as well.

--
F.


signature.asc
Description: PGP signature

Bug#989602: closed by Guillem Jover (Re: Bug#989602: dpkg-deb overwrites symlinks with directories)

[Marc Haber]

On Wed, Jun 09, 2021 at 12:24:04AM +, Debian Bug Tracking System wrote:
> I'm assuming this was done on a system installed or migrated to the
> broken merged-usr-via-aliased-dirs layout, which dpkg does not really
> support.

It was installed on a platform without official support using the
offical current installer, the one we're planning to release as "Debian
stable, the Universal Operating System" in six weeks.


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#989640: unblock: qtbase-opensource-src-gles/5.15.2+dfsg-4

[Dmitry Shachnev]

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

Please unblock package qtbase-opensource-src-gles

[ Reason ]
As qtbase-opensource-src source has already been unblocked (#989469),
please also unblock the -gles variant.

To properly fix the upgrade issue, Breaks: need to be added in both sources.
Having the fix in only qtbase-opensource-src has not been tested and may
potentially make the situation even worse.

[ Impact ]
This affects users of testing who have not upgraded their system for quite
a long time (since October 2020) and have qt5-default installed.

When these users finally upgrade, apt can replace libqt5gui5 with
libqt5gui5-gles, which is not suitable for most desktop systems and can
result in all kinds of broken UI (such as missing icons).

[ Tests ]
Manual upgrade tests have been performed. See also my discussions with
David Kalnischkies, one of apt developers:

https://lists.debian.org/debian-devel/2021/05/msg00076.html
https://lists.debian.org/debian-devel/2021/05/msg00150.html
https://lists.debian.org/debian-devel/2021/05/msg00162.html

[ Risks ]
The code is adding Breaks: against obsolete qt5-default in two packages:
qtbase5-gles-dev and libqt5gui5-gles. This will affect apt's dependency
resolver, hopefully only positively and not negatively.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
See this post for details on what the -gles packages are:
https://mitya57.me/weblog/2020/01/qt-opengl-es-packages-available.html

Also see this comment where I collected some links to stories of users who
were affected by this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976389#10

unblock qtbase-opensource-src-gles/5.15.2+dfsg-4

--
Dmitry Shachnev
diff -Nru qtbase-opensource-src-gles-5.15.2+dfsg/debian/changelog qtbase-opensource-src-gles-5.15.2+dfsg/debian/changelog
--- qtbase-opensource-src-gles-5.15.2+dfsg/debian/changelog	2021-01-27 20:24:23.0 +0300
+++ qtbase-opensource-src-gles-5.15.2+dfsg/debian/changelog	2021-05-14 21:35:45.0 +0300
@@ -1,3 +1,10 @@
+qtbase-opensource-src-gles (5.15.2+dfsg-4) unstable; urgency=medium
+
+  * Make libqt5gui5-gles and qtbase5-gles-dev break qt5-default (closes:
+#976389, LP: #1920130).
+
+ -- Dmitry Shachnev   Fri, 14 May 2021 21:35:45 +0300
+
 qtbase-opensource-src-gles (5.15.2+dfsg-3) unstable; urgency=medium
 
   * Merge qtbase-opensource-src 5.15.2+dfsg-3 upload.
diff -Nru qtbase-opensource-src-gles-5.15.2+dfsg/debian/control qtbase-opensource-src-gles-5.15.2+dfsg/debian/control
--- qtbase-opensource-src-gles-5.15.2+dfsg/debian/control	2021-01-27 20:24:23.0 +0300
+++ qtbase-opensource-src-gles-5.15.2+dfsg/debian/control	2021-05-14 21:35:45.0 +0300
@@ -88,7 +88,8 @@
 Depends: fontconfig, ${misc:Depends}, ${shlibs:Depends}
 Recommends: libqt5svg5, qt5-gtk-platformtheme
 Breaks: libqt5egldeviceintegration5 (<< 5.6.0~beta+dfsg-5~),
-libqt5xcbqpa5 (<< 5.6.0~beta+dfsg-5~)
+libqt5xcbqpa5 (<< 5.6.0~beta+dfsg-5~),
+qt5-default
 Replaces: libqt5egldeviceintegration5 (<< 5.6.0~beta+dfsg-5~),
   libqt5xcbqpa5 (<< 5.6.0~beta+dfsg-5~)
 Suggests: qt5-image-formats-plugins, qtwayland5
@@ -130,7 +131,8 @@
   libpq-dev,
   libsqlite3-dev,
   unixodbc-dev
-Breaks: qt5-qmake (<< 5.11.3+dfsg-3~),
+Breaks: qt5-default,
+qt5-qmake (<< 5.11.3+dfsg-3~),
 qtbase5-dev-tools (<< 5.12.5+dfsg-3~),
 qtbase5-private-gles-dev (<< 5.12.2+dfsg-1~)
 Replaces: qt5-qmake (<< 5.11.3+dfsg-3~),


signature.asc
Description: PGP signature

Bug#989639: ITP: organize -- File management automation tool

[Frédéric Bonnard]

Package: wnpp
Owner: Frédéric Bonnard 
Severity: wishlist

* Package name: organize
  Version : 1.10.1
  Upstream Author : Thomas Feldmann 
* URL : https://github.com/tfeldmann/organize
* License : Expat
  Programming Lang: Python
  Description : File management automation tool

organize is a command line utility to automate file organization tasks.
A list of folders containing files to organize are provided in a
configuration file.
A list of filters can be applied to those files : filtering can be done by
file extension, last modified date, regular expressions and many more.
And a list of actions will be applied to the filtered files : they can
put them into the trash, move them into another folder and many more.

--
F


signature.asc
Description: PGP signature

Bug#989638: qemu-kvm dependency isn't available on all Architecture: any

[Christian Ehrhardt]

Package: qemu-web-desktop
Version: 21.05.03-1

Hi,
I've seen that this is blocked migrating in Debian and Ubuntu due to
missing dependencies.

Debian:
qemu-web-desktop/mips64el has unsatisfiable dependency
qemu-web-desktop/mipsel has unsatisfiable dependency
qemu-web-desktop/s390x has unsatisfiable dependency
Ubuntu:
qemu-web-desktop/riscv64 has unsatisfiable dependency

That is due to the explicit listing of qemu-kvm
This package is most likely no more the right package to depend on anyway.
Usually it is expected to depend on just the right qemu-system-$arch
that you'd need - and if you really can't decide at all then qemu-system
which depends on all the others.

qemu-kvm doesn't exist anymore as a package, you only see old ones:
qemu-kvm   | 1:2.1+dfsg-12+deb8u6 | oldoldstable | amd64, i386
qemu-kvm   | 1:2.8+dfsg-6+deb9u9  | oldstable| amd64, i386
qemu-kvm   | 1:3.1+dfsg-8+deb10u8 | stable   | amd64, i386
But the newer qemu-system-$arch have a provides

root@d10-sid:~# apt-cache show qemu-system-x86 | grep '^Provides'
Provides: qemu-kvm, qemu-system-i386, qemu-system-x86-64

The description of the also old "qemu" outlines it the best IMHO:
142  If you want full system emulation of some architecture, install one or more
143  of qemu-system-ARCH packages. If you want user-mode emulation, install
144  qemu-user or qemu-user-static package. If you need utilities, use
qemu-utils
145  package.

So what does qemu-web-desktop actually use:
$ grep -Hrn qemu-system
README.md:173:qemu-system-x86_64  -m 4096 -smp 4 -hda machine1.qcow2
-name MySuperbVM -boot d -cdrom file.iso -enable-kvm -cpu host -vga
qxl -net user -net nic,model=ne2k_pci
README.md:378:qemu-system-x86_64: -device
vfio-pci,host=:4c:00.0,multifunction=on: VFIO_MAP_DMA: -12
README.md:379:qemu-system-x86_64: -device
vfio-pci,host=:4c:00.0,multifunction=on:
vfio_dma_map(0x55966269d230, 0x10, 0xbff0, 0x7f55b7f0) =
-12 (Cannot allocate memory)
README.md:411:qemu-system-x86_64  -m 8192 -smp 4 -hda
machine1-snapshot.qcow2 -device ich9-ahci,id=ahci -enable-kvm -cpu
host -vga qxl -netdev user,id=mynet0 -device virtio-net,netdev=mynet0
-device virtio-balloon
src/config.pl:63:$config{qemu_exec}= "qemu-system-x86_64";

So the default is x86 only, there is nothing in d/rules that overwrites this.

Thereby chances are quite high that this was only ever tested and meant for
x86_64 anyway. Therefore the simple and most reasonable short term fix
would IMHO be:

--- qemu-web-desktop-21.05.03/debian/control 2021-05-17 18:51:33.0 +0200
+++ qemu-web-desktop-21.05.03/debian/control 2021-06-09 09:43:35.0 +0200
@@ -10,7 +10,7 @@
 Homepage: 
https://gitlab.com/soleil-data-treatment/soleil-software-projects/remote-desktop

 Package: qemu-web-desktop
-Architecture: any
+Architecture: amd64
 Depends: ${shlibs:Depends}, ${misc:Depends},
   apache2,
   libapache2-mod-perl2,

If you want to really support other architectures then you'd most likely want
to
1. overwrite the default in config.pl at build time per architecture
2. select the architectures you really expect to work (e.g. there is no system
   emulation at all for risscv yet) and mark it only for those
3. depend on the matching qemu-system-$arch
4. after having done so have at least a quick try if it works there at all
   before moving it out of experimental

!Untested! example for this more complex solution:

diff -Nru qemu-web-desktop-21.05.03/debian/control
qemu-web-desktop-21.05.03/debian/control
--- qemu-web-desktop-21.05.03/debian/control 2021-05-17 18:51:33.0 +0200
+++ qemu-web-desktop-21.05.03/debian/control 2021-06-09 09:43:44.0 +0200
@@ -10,13 +10,15 @@
 Homepage: 
https://gitlab.com/soleil-data-treatment/soleil-software-projects/remote-desktop

 Package: qemu-web-desktop
-Architecture: any
+Architecture: amd64 ppc64el arm64
 Depends: ${shlibs:Depends}, ${misc:Depends},
   apache2,
   libapache2-mod-perl2,
   libapache2-mpm-itk,
   websockify,
-  qemu-kvm,
+  qemu-system-x86 [amd64],
+  qemu-system-arm [arm64],
+  qemu-system-ppc [ppc64el],
   bridge-utils,
   qemu,
   iptables,
diff -Nru qemu-web-desktop-21.05.03/debian/rules
qemu-web-desktop-21.05.03/debian/rules
--- qemu-web-desktop-21.05.03/debian/rules 2021-05-03 17:06:35.0 +0200
+++ qemu-web-desktop-21.05.03/debian/rules 2021-06-09 09:43:44.0 +0200
@@ -1,10 +1,19 @@
 #!/usr/bin/make -f

+SYSEMULATOR=qemu-system-x86_64
+ifeq ($(DEB_HOST_ARCH),arm64)
+  SYSEMULATOR=qemu-system-aarch64
+endif
+ifeq ($(DEB_HOST_ARCH),ppc64el)
+  SYSEMULATOR=qemu-system-ppc64
+endif
+
 %:
  dh $@ --with apache2 --with sysuser

 override_dh_auto_build:
  mkdir build
+ sed -e 's/qemu-system-x86_64/$(SYSEMULATOR)/' src/config.pl
  cp src/apache.conf build/qemu-web-desktop.conf
  pandoc -s -o build/qwdctl.1 src/qwdctl.md


-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#987941: Acknowledgement (buster-pu: package pacemaker/2.0.1-5+deb10u2)

[wferi]

Andreas kindly provided further refinements for his patch in #985173.
I'll update this stable update request with the new debdiff shortly.
-- 
Feri

Bug#989632: dash: remove unnecessary diversion of /bin/sh

[Jonathan Nieder]

Hi Helmut,

Helmut Grohne wrote:

> At present, /bin/sh is always diverted. The diversion takes one of three
> forms:
>
>  A. diverted by package dash, pointing to dash
>  B. diverted by package bash (but performed by dash.postinst), pointing
> to bash
>  C. local diversion
>
> The local diversion gives freedom to administrators to manually point
> their /bin/sh at bash and seems to be still in use. dash.postinst takes
> care not to mess with such diversions and that should continue to work.

Sure, that makes sense (re local diversions).

> Unless there is a local diversion, dash.postinst sets up either A or B
> depending on a debconf question defaulting to A. Since /bin/sh normally
> points to dash when not diverted, the diversion A seems unnecessary. B
> will have to continue to exist for as long as dash supports changing
> /bin/sh via debconf.

My ideal would be to go even further and not include /bin/sh in any
shell's package (in other words, to treat the symlink something like a
configuration file).  That way, one could bootstrap with any choice of
shell instead of dash needing to be essential.

We're already closer to that ideal than we used to be, since bash
doesn't ship /bin/sh nowadays; only dash does.

What would be required to make that work?

 1. On initial install (bootstrap), we need to be able to run preinst
for essential packages.  Most preinsts are shell scripts with
/bin/sh shebang, so this means that one of the following would
have to happen:

 1a. run preinst for dash before any other package; it could use
 e.g. a #!/usr/bin/perl script to install the /bin/sh symlink

 1b. as custom logic in the bootstrap utility, write the /bin/sh
 symlink

1b'. introduce a new maintainer script that is specifically for
 bootstrapping.  (I would love this; it's probably worth a
 separate DEP, but it's overkill for this application alone.)

 1c. include the /bin/sh symlink in a separate "sh-is-dash"
 package

Of these, 1b seems simple enough so it's surmountable.

 2. On upgrade of dash in existing systems, we need to avoid removing
the /bin/sh symlink:

- if another package is diverting /bin/sh, this happens
  automatically (good)

- if dash is diverting /bin/sh, preinst can handle this by passing
  ownership of the diversion to another package

- after the patch proposed below, there is a third case: if no
  package is diverting /bin/sh, dash's preinst can still handle
  this by creating a diversion on behalf of another package

So the patch below doesn't lose flexibility in that dimension (good).

 3. After an upgrade, we want to end up with a clean state with no
diversions.  We could handle that by removing the diversion in
dash's postinst.

Upshot: the proposal below doesn't bring us closer to that ideal, but
it doesn't bring us further away either.  And I like the idea of
making the default configuration simpler.

[...]
> --- dash-0.5.11+git20210120+802ebd4/debian/dash.postinst  2021-03-04 
> 10:22:32.0 +0100
> +++ dash-0.5.11+git20210120+802ebd4/debian/dash.postinst  2021-06-03 
> 20:19:40.0 +0200
> @@ -25,7 +25,7 @@
>   diverter=$(dpkg-divert --listpackage $dfile)
>   truename=$(dpkg-divert --truename $dfile)
>  
> - if [ "$diverter" = dash ]; then
> + if [ -z "$diverter" ]; then
>   # good.
>   return
>   fi
> @@ -35,7 +35,7 @@
>   return
>   fi
>  
> - if [ -n "$diverter" ] && [ "$diverter" != bash ]; then
> + if [ "$diverter" != bash ]; then
>   # Let dpkg-divert error out; we are not taking
>   # over the diversion, unless we added it

nit: this should say "removing" instead of "taking over".

>   # ourselves on behalf of bash.
>   dpkg-divert --package dash --no-rename --remove $dfile
>   echo "This should never be reached"
>   exit 1

Isn't this reachable now, in the "$diverter" = dash case?  Or is the idea that
the drop_obsolete_diversion case is meant to have taken care of that?  I think
treating this as reachable would make the code easier to reason about (and then
we can simplify further after this code has been live in one stable release).

> @@ -45,7 +45,6 @@
>   fi
>  
>   dpkg-divert --package bash --no-rename --remove $dfile
> - dpkg-divert --package dash --no-rename --divert $distrib --add $dfile

dash is the only package that ships /bin/sh, so this has no effect on what
happens during unpacking.  Good.

[...]
> @@ -58,18 +57,20 @@
>   diverter=$(dpkg-divert --listpackage $dfile)
>   truename=$(dpkg-divert --truename $dfile)
>  
> - if [ "$diverter" != dash ]; then
> + if [ "$diverter" = dash ]; then
> + # Should not happen. Handle anyway.
> + dpkg-divert --package dash --no-rename --remove "$dfile"
> + if [ -n "$truename" ]; then
> +

Bug#964074: Status?

[Julien Puydt]

Le mercredi 09 juin 2021 à 08:56 +0200, Adam Cecile a écrit :
> It's actually packaged but not uploaded:
> https://salsa.debian.org/python-team/packages/python-jose
> If you're interested in sponsoring the upload, please let me know so
> I can first make a quick refresh of packaging.

I found this packaging after I filed the report. We're in deep freeze,
so I won't upload anything yet, but you can still work on it :

1. lintian finds quite a few things to complain about (I ran lintian -I
--pedantic on the .dsc) ; some might require a source repack to get
around (the RFC licensing issue) ;

2. lintian didn't complain but standards-version isn't up to date
either ;

3. a new upstream is out.

Cheers,

JP

Bug#989637: Please package latest upstream

[Julien Puydt]

Package: python3-jwt
Version: 1.7.1-2
Severity: wishlist

When the freeze is over, I'd like to see the latest upstream in Debian,
as I need it for some other packages. I can even lend a hand, as I'm
part of the DPT.

Cheers,

JP

Bug#989621: texlive-latex-extra: incompatible regexpatch.sty version

[Hilmar Preuße]

Control: tags -1 + pending
Control: tags -1 + fixed-upstream

Am 08.06.2021 um 23:32 teilte Nelson mit:

Hi,


The latest LaTeX executables (included in texlive-latex-base 2020.20210202-3)
removed some previously deprecated macros. The regexpatch package included in
texlive-latex-extra 2020.20210202-3 is too old and, therefore, fails with this
version of LaTeX. The current version of the package, available at ctan, fixes
this problem. A simple test document:

Sorry, the report is a little bit late: we are in deep freeze so the 
change won't be accepted for next stable Debian release. The next upload 
will contain a new CTAN snapshot and hence the fix for your issue.


Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#989635: unattended-upgrades: [INTL:fr] French templates translation

[jenapierregirau...@free.fr]

Package: unattended-upgrades
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french templates translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

Jean-Pierre Giraud



fr.po.xz
Description: application/xz

Bug#989636: rust-rustyline_3.0.0-2+deb10u1_s390x.changes REJECTED

[Aurelien Jarno]

Source: rust-rustyline
Version: 3.0.0-2+deb10u1
Severity: serious

On 2021-06-09 02:54, Debian FTP Masters wrote:
> 
> 
> librust-rustyline-dev_3.0.0-2+deb10u1_s390x.deb: has 1 file(s) with a 
> timestamp too far in the past:
>   usr/share/cargo/registry/rustyline-3.0.0/.cargo_vcs_info.json (Thu Jan  1 
> 00:00:00 1970)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#989634: autopkgtest fails by missing python3-tomlkit dependency

[Christian Ehrhardt]

Package: lintian-brush
Version: 0.104

Hi,
I've seen the autopkgtests fail in Debian
https://ci.debian.net/data/autopkgtest/unstable/amd64/l/lintian-brush/12796854/log.gz
And Ubuntu
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/l/lintian-brush/20210524_182220_e891a@/log.gz

While it seems that there might be more hidden underneath as tests behave
differently on re-runs and if executed locally there is one issue that
persists everywhere.

from lintian_brush.fixer import control, report_result, LintianIssue
  File "/usr/lib/python3/dist-packages/lintian_brush/fixer.py", line
235, in 
from debmutate.debcargo import DebcargoControlShimEditor, DebcargoEditor
  File "/usr/lib/python3/dist-packages/debmutate/debcargo.py", line
28, in 
from tomlkit import loads, dumps
ModuleNotFoundError: No module named 'tomlkit'

Installing python3-tomlkit avoids that issue as one would expect.
It only is an indirect recommends and therefore isn't auto-installed.

Resolving this gets the test working in a local autopkgtest
VM based run (in Ubuntu).
Logs => https://paste.ubuntu.com/p/8bSFTkNCFS/

Let me know if you need an MP or debdiff for this, but since it is so
trivial I've just posted it here:

diff -Nru lintian-brush-0.104/debian/tests/control
lintian-brush-0.104/debian/tests/control
--- lintian-brush-0.104/debian/tests/control 2021-03-29 19:56:27.0 +0200
+++ lintian-brush-0.104/debian/tests/control 2021-03-29 19:56:27.0 +0200
@@ -1,5 +1,5 @@
 Tests: tool-testsuite
-Depends: lintian-brush, python3-breezy.tests, gpg, dos2unix,
libdebhelper-perl, lintian (>= 2.104.0), python3-iniparse,
python3-levenshtein, decopy, po-debconf, python3-toml |
python3-upstream-ontologist (>> 0.1.12), python3-markdown,
python3-docutils, python3-bs4, python3-lxml
+Depends: lintian-brush, python3-breezy.tests, gpg, dos2unix,
libdebhelper-perl, lintian (>= 2.104.0), python3-iniparse,
python3-levenshtein, decopy, po-debconf, python3-toml |
python3-upstream-ontologist (>> 0.1.12), python3-markdown,
python3-docutils, python3-bs4, python3-lxml, python3-tomlkit
 Restrictions: allow-stderr

 Test-Command: deb-scrub-obsolete --version

I hope that helps to resolve this,
Christian Ehrhardt

Bug#989633: breezy 3.2 breaks lintian-brush patch handling

[Christian Ehrhardt]

Package: lintian-brush
Version: 0.104

Hi,
while debugging another issue in the lintian-brush autopkgtests I've seen
this issue:

Next I've seen that with python3-breezy 3.2 that is in unstable you get
Traceback (most recent call last):
  File 
"/tmp/autopkgtest.tAETVe/build.tjd/src/lintian_brush/tests/test_patches.py",
line 299, in test_upstream_branch
with upstream_with_applied_patches(self.tree, patches) as t:
  File "/usr/lib/python3.9/contextlib.py", line 117, in __enter__
return next(self.gen)
  File "/tmp/autopkgtest.tAETVe/build.tjd/src/lintian_brush/patches.py",
line 193, in upstream_with_applied_patches
with AppliedPatches(upstream_tree, patches) as tree:
  File "/tmp/autopkgtest.tAETVe/build.tjd/src/lintian_brush/patches.py",
line 133, in __enter__
from breezy.transform import TransformPreview
ImportError: cannot import name 'TransformPreview' from
'breezy.transform'
(/usr/lib/python3/dist-packages/breezy/transform.py)

I've found that this is from the new:
  breezy | 3.2.0+bzr7542-1| unstable| source

You can switch in/out that state by switching back to
  breezy | 3.1.0-8| testing | source

It seems this was split from
breezy/transform.py:1971:class TransformPreview(DiskTreeTransform):
Into:
breezy/git/transform.py:1520:class GitTransformPreview(GitTreeTransform):
breezy/bzr/transform.py:1860:class TransformPreview(InventoryTreeTransform):

The following fixes this for me in a local autopkgtest VM run:

--- lintian-brush-0.104/lintian_brush/patches.py 2021-03-29
19:56:27.0 +0200
+++ lintian-brush-0.104/lintian_brush/patches.py 2021-03-29
19:56:27.0 +0200
@@ -130,7 +130,7 @@

 def __enter__(self):
 if self.patches:
-from breezy.transform import TransformPreview
+from breezy.bzr.transform import TransformPreview

 self._tt = TransformPreview(self.tree)
 apply_patches(self._tt, self.patches, prefix=self.prefix)

I don't know if you eventually want a version dependent switch for the import,
but that should get you going and since I was not finding a bug for it yet I
thought filing this for awareness might help in any case.

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#979809: libopencv-contrib4.5 has circular Depends on libopencv-superres4.5

[Andreas Beckmann]

Followup-For: Bug #979809

/usr/lib/x86_64-linux-gnu/libopencv_superres.so.4.5.1 is linked against
these libraries from libopencv-contrib4.5:
   /usr/lib/x86_64-linux-gnu/libopencv_optflow.so.4.5
   /usr/lib/x86_64-linux-gnu/libopencv_ximgproc.so.4.5

Andreas

Bug#964074: Status?

[Adam Cecile]

Hello,

It's actually packaged but not uploaded:

https://salsa.debian.org/python-team/packages/python-jose

If you're interested in sponsoring the upload, please let me know so I 
can first make a quick refresh of packaging.


Regards, Adam.

On 6/9/21 8:43 AM, Julien Puydt wrote:

Hi,

I stumbled on a project where I would need python-jose -- what's the
status of this ITP?

JP

Bug#989193: [pkg-apparmor] Bug#989193: breaks apt-cacher-ng by blocking link operation

[intrigeri]

Control: severity -1 serious

Hi,

Eduard Bloch (2021-06-08):
> I set it RC because it deliberately breaks other package's (legal)
> operations,

The whole purpose of AppArmor policy is to restrict operations to
a pre-defined set. This package does nothing else than shipping opt-in
extra AppArmor policy so its whole point is to restrict operations.
Some of the forbidden operations may be, or become, legit: that's
a bug (or a conscious trade-off) of AppArmor policy.

If you combine these with your reasoning, then any bug in AppArmor
policy that makes it block a legit operation, would be RC: I don't
think this is a reasonable way to approach bug severity for AppArmor
policy, because basically it would make bug severity a constant, and
thus we can't use it anymore to prioritize our work, do release
management, etc.

Instead, the way we do it usually is to take into account the impact
and risk of occurrence of such bugs. Which is why I asked for more
information here :)

> and installing such booby traps was not properly announced.

I'm sorry I did not let you know that we were shipping AppArmor policy
for apt-cacher-ng in apparmor-profiles-extra. I'm grateful that
Laurent Bigonville did in July 2019 (#932177), though.

I would appreciate if you used language less loaded than "booby traps"
to express your thoughts here: as I understand it, a booby trap is
meant to intentionally cause harm., which is _not_ my intention here.

One thing to keep in mind here: apparmor-profiles-extra is opt-in.
Users who have it installed intentionally decided to have more
programs confined by AppArmor.

> And because you take away the control over the package's behavior
> from the maintainers and push them to "collaboration" […]. In a way
> I don't like (shoot first, ask later).

Point taken.

I understand parts of your concerns here are more general than "breaks
apt-cacher-ng by blocking link operation". Would some help from me,
towards solving #932177 post-Bullseye, be sufficient to reach
a mutually agreeable solution? I'm also open to removing the
apt-cacher-ng profile from apparmor-profiles-extra, without blocking
on #932177, if you prefer: I don't want to force AppArmor policy on
you. This is negotiable.

>> I can't find traces of such denials in my logs.
>
> Please. Just because you don't see issues does not mean that issues
> don't exist.

Of course. This is precisely why I asked you to help me understand
in which cases these issues do exist, so I can assess severity.

>> Could you please help me understand what kind of apt-cacher-ng
>> operations (or configuration) trigger these denials and are broken by
>> the current AppArmor policy?
>
> When the mentioned mechanism was put in place, regular operation started
> breaking. This also affects the expiration jobs, therefore your cache
> will keep growing when users use non-stable distros.

OK, then indeed I think this bug is RC. Thanks!

> Or what exactly did make you think that "rw" is okay and everything
> else can be dumped? Where are we? "I see all cars on my road are
> driving straight, means that we can remove all steering wheels"?
> *facepalm*

I hear you're unhappy and perhaps angry, but I think you're out of
line here. This tone hurts and makes it more difficult and costly for
me to keep striving for constructive communication and collaboration.

Given the tone of this last paragraph, I'll assume these are
rhetorical questions and won't spend time answering them. However, if
you're genuinely interested in understanding why the profile has "rw"
and not "allow everything", I'll happy to shed some light on how
I usually develop AppArmor policy.

Cheers!