Bug#953614: buster-pu: package dojo/1.14.2+dfsg1-1+deb10u2

[Xavier Guimard]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

2 new vulnerabilities have been published for dojo: prototype
pollutions. I imported the 2 upstream fixes here.

Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index f2dfbd6c..d4aae875 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+dojo (1.14.2+dfsg1-1+deb10u2) buster; urgency=medium
+
+  * Team upload
+  * Fix prototype pollution in deepCopy method (Closes: #953585,
+CVE-2020-5258)
+  * Fix Prototype Pollution in jqMix method (Closes: #953587, CVE-2020-5259)
+
+ -- Xavier Guimard   Wed, 11 Mar 2020 06:18:23 +0100
+
 dojo (1.14.2+dfsg1-1+deb10u1) buster; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2020-5258.diff 
b/debian/patches/CVE-2020-5258.diff
new file mode 100644
index ..4aefd61d
--- /dev/null
+++ b/debian/patches/CVE-2020-5258.diff
@@ -0,0 +1,20 @@
+Description: fix Prototype Pollution
+Author: Nick Nisi
+Origin: upstream, https://github.com/dojo/dojox/commit/c5901be1
+Bug: https://github.com/dojo/dojo/security/advisories/GHSA-jxfh-8wgv-vfr2
+Bug-Debian: https://bugs.debian.org/953585
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2020-03-11
+
+--- a/dojo/request/util.js
 b/dojo/request/util.js
+@@ -13,7 +13,7 @@
+   for (var name in source) {
+   var tval = target[name],
+   sval = source[name];
+-  if (tval !== sval) {
++  if (name !== '__proto__' && tval !== sval) {
+   if (sval && typeof sval === 'object' && 
!(has('native-formdata') && sval instanceof FormData)) {
+   if 
(Object.prototype.toString.call(sval) === '[object Date]') { // use this date 
test to handle crossing frame boundaries
+   target[name] = new Date(sval);
diff --git a/debian/patches/CVE-2020-5259.diff 
b/debian/patches/CVE-2020-5259.diff
new file mode 100644
index ..3d05ed7e
--- /dev/null
+++ b/debian/patches/CVE-2020-5259.diff
@@ -0,0 +1,20 @@
+Description: fix prototype pollution in jqMix method
+Author: Nick Nisi
+Origin: upstream, https://github.com/dojo/dojox/commit/c5901be1
+Bug: https://github.com/dojo/dojox/security/advisories/GHSA-3hw5-q855-g6cw
+Bug-Debian: https://bugs.debian.org/953587
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2020-03-11
+
+--- a/dojox/jq.js
 b/dojox/jq.js
+@@ -455,7 +455,7 @@
+   // inherited from Object.prototype.  For example, if 
obj has a custom
+   // toString() method, don't overwrite it with the 
toString() method
+   // that props inherited from Object.prototype
+-  if((tobj[x] === undefined || tobj[x] != props[x]) && 
props[x] !== undefined && obj != props[x]){
++  if(x !== '__proto__ ' && ((tobj[x] === undefined || 
tobj[x] != props[x])) && props[x] !== undefined && obj != props[x]){
+   if(dojo.isObject(obj[x]) && 
dojo.isObject(props[x])){
+   if(dojo.isArray(props[x])){
+   obj[x] = props[x];
diff --git a/debian/patches/series b/debian/patches/series
index b0f5ff11..d5b7db42 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,5 @@
 0002-Do-notrun-test-suite-in-build.patch
 0003-Disable-flash-storage.patch
 CVE-2019-10785.patch
+CVE-2020-5258.diff
+CVE-2020-5259.diff

Bug#953569:

[Daniel Kahn Gillmor]

On Wed 2020-03-11 03:50:00 +, Ben Hutchings wrote:
> If some of the packages providing a virtual package are explicitly
> installed, and some auto-installed, it could reasonably auto-remove the
> latter group (though I don't think it does).  But if all of them are
> auto-installed, which will be the case for kernel packages, it can't
> tell which should be kept and which removed.

hm, right, i can see how that would be a problem.  thanks for the
explanation.

> But nothing will auto-remove the wireguard package.  So you would have
> to keep it as a transitional package for one release cycle, even when
> it depends on just wireguard-tools.

I don't think it would be a problem to have a transitional package for
one release cycle.  do you?

> Yes, this is annoyingly complicated.  That's why I need there to be a
> plan.

I'm open to any suggestions that you think would work better than what
we've talked about so far.  Let me know what you prefer.

  --dkg


signature.asc
Description: PGP signature

Bug#953569:

[Daniel Kahn Gillmor]

On Tue 2020-03-10 22:23:18 -0600, Jason A. Donenfeld wrote:
> https://data.zx2c4.com/wireguard-5.5.8-20a586ec4f5acf195f71caea55c5a33c574078cb69712da591467ffc08dd8b72.zip

Thanks, Jason!

> - A user is on stock Debian and runs `apt install wireguard`: only
> wireguard-tools is pulled in.
> - A user is on weird Debian (say, some AWS kernel) and runs `apt
> install wireguard`: wireguard-tools and wireguard-dkms are pulled in.

Are you thinking about kernel 5.5 or kernel 5.6 or later?

if wg is mainlined in 5.6 and the user is on a 5.6 or later kernel, then
i don't think we want wireguard-dkms at all, right?

> I was under the impression that the "Provides" mechanism does a good
> job at that. But perhaps there's another good way you have in mind.

The automatic uninstallation of packages with legacy kernel ABIs is what
Ben has identified as a sticking point for putting a Provides: on the
"real" kernel package.  But it doesn't sound like that's a problem for
the kernel metapackages.

--dkg


signature.asc
Description: PGP signature

Bug#953613: boinc-manager: boincmgr doesn't connect when the -n option is specified

[Russell Coker]

Package: boinc-manager
Version: 7.16.5+dfsg-1
Severity: normal

The command "boincmgr -g 31416 -n localhost -e /etc/boinc-client" used to
connect to the server on localhost when it started, but now it doesn't do so.

Version 7.16.5+dfsg-1exp1 also has this problem.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages boinc-manager depends on:
ii  boinc-client  7.16.5+dfsg-1
ii  libboinc7 7.16.5+dfsg-1
ii  libc6 2.29-10
ii  libgcc-s1 10-20200304-1
ii  libglib2.0-0  2.62.5-1
ii  libgtk-3-03.24.14-1
ii  libnotify40.7.9-1
ii  libsqlite3-0  3.31.1-4
ii  libstdc++610-20200304-1
ii  libwxbase3.0-0v5  3.0.4+dfsg-15
ii  libwxgtk-webview3.0-gtk3-0v5  3.0.4+dfsg-15
ii  libwxgtk3.0-gtk3-0v5  3.0.4+dfsg-15

boinc-manager recommends no packages.

Versions of packages boinc-manager suggests:
ii  libgl1-mesa-glx  19.3.3-1
ii  libxt6   1:1.1.5-1+b3

-- no debconf information

Bug#953569:

[Jason A. Donenfeld]

On Tue, Mar 10, 2020 at 8:52 PM Ben Hutchings  wrote:
>
> On Tue, 2020-03-10 at 17:02 -0600, Jason A. Donenfeld wrote:
> > Please coordinate with me for doing this. Actually, if this sounds
> > interesting to you, I'll backport it myself, along with the missing
> > crypto/ bits, and send you a git bundle of patches for 5.5.
> >
> > In other words, just say "yes please", and I'll supply the rest.
>
> Either a git bundle or quilt patch series is fine.

Voila:

https://data.zx2c4.com/wireguard-5.5.8-20a586ec4f5acf195f71caea55c5a33c574078cb69712da591467ffc08dd8b72.zip

That will apply on top of 5.5.8. Let me know if you have any problems,
and please poke me after this is done so I can test it out.

>
> > Then you can apply this to your tree and add the Provides as dkg
> > asked.
>
> We definitely can't add a Provides on "real" kernel packages, because
> this breaks auto-removal of old packages.  We could possibly add it to
> the meta-packages, but there would have to be a plan for how we can
> drop it later (and have the Wireguard user-space just assume the kernel
> supports it).  We definitely shouldn't accumulate Provides for every
> component that was previously packaged out-of-tree.

There are tricky Debian concerns here I don't totally grok, but what
I'd like to happen is:

- A user is on stock Debian and runs `apt install wireguard`: only
wireguard-tools is pulled in.
- A user is on weird Debian (say, some AWS kernel) and runs `apt
install wireguard`: wireguard-tools and wireguard-dkms are pulled in.

I was under the impression that the "Provides" mechanism does a good
job at that. But perhaps there's another good way you have in mind.

Bug#953612: pcmanfm windows stays in foreground after deleting a file

[jfp]

Package: pcmanfm
Version: 1.3.1-1+b1
Severity: normal
Tags: upstream

Dear Maintainer,

Issue is as follows:
- delete a file in pcmanfm
- switch to another program
- other program windows get highlighted as current "focus" window but pcmanfm
stays in the foregound.

In fact pcmanfm stays in front of any other window until you select pcmanfm
then you can select any other window properly.




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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NZ:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pcmanfm depends on:
ii  libatk1.0-0  2.34.1-1
ii  libc62.29-10
ii  libcairo21.16.0-4
ii  libfm-gtk4   1.3.1-1+b1
ii  libfm4   1.3.1-1+b1
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-3
ii  libglib2.0-0 2.62.5-1
ii  libgtk2.0-0  2.24.32-4
ii  libpango-1.0-0   1.42.4-8
ii  libpangocairo-1.0-0  1.42.4-8
ii  libpangoft2-1.0-01.42.4-8
ii  libx11-6 2:1.6.9-2
ii  shared-mime-info 1.10-1

Versions of packages pcmanfm recommends:
ii  gnome-icon-theme 3.12.0-3
ii  gvfs-backends1.44.0-1
pn  gvfs-fuse
ii  policykit-1-gnome [polkit-1-auth-agent]  0.105-7
ii  tango-icon-theme 0.8.90-7

pcmanfm suggests no packages.

-- no debconf information

Bug#953569:

[Ben Hutchings]

On Tue, 2020-03-10 at 23:31 -0400, Daniel Kahn Gillmor wrote:
> Thanks to Ben and Jason for following up here.
> 
> On Wed 2020-03-11 02:52:43 +, Ben Hutchings wrote:
> > We definitely can't add a Provides on "real" kernel packages, because
> > this breaks auto-removal of old packages.
> 
> I'm not sure i understand this.  by "real" kernel packages i think you
> mean something like linux-image-5.4.0-4-amd64.
> 
> If linux-image-5.5.0-1-amd64 were installed, with such a Provides:, and
> then linux-image-5.5.0-2-amd64 were installed, also with such a
> Provides:, then why wouldn't autoremoval of linux-image-5.5.0-1-amd64
> still work?  The system would still have the Provides: satisfied.
> 
> Feel free to point me at some piece of Apt or dpkg documentation if i'm
> missing something obvious.

I don't know where/if it's explicitly documented, but it would be with
apt if anywhere.

If some of the packages providing a virtual package are explicitly
installed, and some auto-installed, it could reasonably auto-remove the
latter group (though I don't think it does).  But if all of them are
auto-installed, which will be the case for kernel packages, it can't
tell which should be kept and which removed.

> > We could possibly add it to the meta-packages, but there would have to
> > be a plan for how we can drop it later (and have the Wireguard
> > user-space just assume the kernel supports it).
> 
> When we can just assume that the kernel supports it, we might just drop
> the "wireguard" package entirely, and supply only the "wireguard-tools"
> package (maybe at that point, we make "wireguard-tools" itself Provide:
> wireguard).

But nothing will auto-remove the wireguard package.  So you would have
to keep it as a transitional package for one release cycle, even when
it depends on just wireguard-tools.

Yes, this is annoyingly complicated.  That's why I need there to be a
plan.

Ben.

> At that point, we certainly wouldn't need the Provides: on
> the kernel.
> 
> > We definitely shouldn't accumulate Provides for every component that
> > was previously packaged out-of-tree.
> 
> I can see how that would be problematic :)
> 
>   --dkg
-- 
Ben Hutchings
Humour is the best antidote to reality.



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

Bug#953569:

[Daniel Kahn Gillmor]

Thanks to Ben and Jason for following up here.

On Wed 2020-03-11 02:52:43 +, Ben Hutchings wrote:
> We definitely can't add a Provides on "real" kernel packages, because
> this breaks auto-removal of old packages.

I'm not sure i understand this.  by "real" kernel packages i think you
mean something like linux-image-5.4.0-4-amd64.

If linux-image-5.5.0-1-amd64 were installed, with such a Provides:, and
then linux-image-5.5.0-2-amd64 were installed, also with such a
Provides:, then why wouldn't autoremoval of linux-image-5.5.0-1-amd64
still work?  The system would still have the Provides: satisfied.

Feel free to point me at some piece of Apt or dpkg documentation if i'm
missing something obvious.

> We could possibly add it to the meta-packages, but there would have to
> be a plan for how we can drop it later (and have the Wireguard
> user-space just assume the kernel supports it).

When we can just assume that the kernel supports it, we might just drop
the "wireguard" package entirely, and supply only the "wireguard-tools"
package (maybe at that point, we make "wireguard-tools" itself Provide:
wireguard).  At that point, we certainly wouldn't need the Provides: on
the kernel.

> We definitely shouldn't accumulate Provides for every component that
> was previously packaged out-of-tree.

I can see how that would be problematic :)

  --dkg


signature.asc
Description: PGP signature

Bug#924040: #924040 ITP: archivebox -- open source self-hosted web archive

[Dmitry Smirnov]

Dear colleagues,

I mourn loss of Scrapbook and ArchiveBox appears to be a viable alternative.

I've noticed this ITP but since there are no signs of initial packaging I 
took the liberty of making a first draft:

  https://salsa.debian.org/debian/archivebox

Let's work together on it, shall we? I hope that my initial packaging could 
be of help as a starting point.

Thanks.

-- 
Regards,
 Dmitry Smirnov.

---

It is a mistake to try to look too far ahead. The chain of destiny can only
be grasped one link at a time.
-- Winston Churchill


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

Bug#953611: wesnoth-1.14-tools: needs Recommends: imagemagick

[Trent W. Buck]

Package: wesnoth-1.14-tools
Version: 1:1.14.5-1
Severity: wishlist

When I do this:

/usr/share/games/wesnoth/1.14/data/tools/wesnoth_addon_manager --html tmp

I get an initial prelude of normal stuff:

Opening socket to add-ons.wesnoth.org:15014 for 1.14.x
Connected as 42.
Receiving 465199 bytes.
Received 465199 bytes.
Closing socket.
Cannot find icon units/human-vikings/viking-valnir.png
Cannot find icon data/add-ons/Home_of_the_Undead/images/zombicon.png
Cannot find icon data/add-ons/Bears_Campaign/images/animals/brown-bear.png
Cannot find icon units/legendary/unicorn-healing.png
Cannot find icon units/human-aragwaithi/eagle-master.png
Cannot find icon projectiles/nagas_merman.png
Cannot find icon data/add-ons/The_Dark_Master/images/marshalC1.png
Cannot find icon data/core/images/portraits/wolves/wolf-dark.png
Cannot find icon data/core/images/portraits/wolves/wolf-dark.png
Cannot find icon data/add-ons/Potlot_mystic/images/circleacho.png
Done outputting html, now generating 467 TC'ed images

Then a huge stream of these:

FileNotFoundError: [Errno 2] No such file or directory: 'convert': 'convert'

The only interesting part of the backtrace is:

File 
"/usr/share/games/wesnoth/1.14/data/tools/addon_manager/../unit_tree/TeamColorizer",
 line 278, in 

This is because it's using imagemagick's "convert" binary to do something, and 
imagemagick isn't installed.

Adding "Recommends: imagemagick" will make this error easier to understand and 
rectify.
(The only reason I say "Recommends" not "Depends" is that this particular code 
path is probably not used much.)



-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'proposed-updates'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#922724: Lots of security issues

[Dmitry Smirnov]

On Wednesday, 20 February 2019 8:28:26 AM AEDT Moritz Muehlenhoff wrote:
> We should generally restrict the level of security support to something
> sensible. A video surveillance systems is obviously something
> that only should be exposed to trusted parties anyway, so I'd suggest
> we treat zoneminder similar to e.g. ganglia (#702775), i.e.
> - add a note to debian-security-support so that it flags the status
>   of it
> - Add a short README.Debian.security (or similar to document it also
>   within the package)

Yes indeed, it makes perfect sense. Would the following work?

  https://salsa.debian.org/debian/zoneminder/-/commit/0cee6e0e
  https://salsa.debian.org/debian/debian-security-support/-/commit/2965940a

Thanks.

-- 
Best wishes,
 Dmitry Smirnov.

---

In individuals, insanity is rare; but in groups, parties, nations and
epochs, it is the rule.
-- Friedrich Nietzsche


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

Bug#953569:

[Ben Hutchings]

On Tue, 2020-03-10 at 17:02 -0600, Jason A. Donenfeld wrote:
> Please coordinate with me for doing this. Actually, if this sounds
> interesting to you, I'll backport it myself, along with the missing
> crypto/ bits, and send you a git bundle of patches for 5.5.
> 
> In other words, just say "yes please", and I'll supply the rest.

Either a git bundle or quilt patch series is fine.

> Then you can apply this to your tree and add the Provides as dkg
> asked.

We definitely can't add a Provides on "real" kernel packages, because
this breaks auto-removal of old packages.  We could possibly add it to
the meta-packages, but there would have to be a plan for how we can
drop it later (and have the Wireguard user-space just assume the kernel
supports it).  We definitely shouldn't accumulate Provides for every
component that was previously packaged out-of-tree.

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.




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

Bug#823597: npm: If npm is updated with npm install npm -g, /usr/share/npm/npmrc is lost

[Jonathan Rubenstein]

Maybe the Debian npm package should disallow updating itself, many other 
Debian packages disable self-update functions of packages.



Fixing this bug would be great, though. However it's done.

Bug#953610: spambayes: should this package be removed?

[Sandro Tosi]

Package: spambayes
Severity: serious

Hello,
i believe spambayes should be removed from debian:

* python2-only and upstream shows no progress in porting to python3
* low popcon
* no reverse dependencies
* blocks python2 removal effort in Debian.

if i dont hear back within a week with a good reason to keep this packaeg in
Debian, i'll file for its removal.

Regards,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 spambayes depends on:
ii  python   2.7.16-1
pn  python-dns   
pn  python-lockfile  

spambayes recommends no packages.

spambayes suggests no packages.

Bug#953609: bley: should this package be removed?

[Sandro Tosi]

Package: bley
Severity: serious

Hello,
i believe bley should be removed from Debian:

* python2-only
* no reverse dependencies
* extremely low popcon
* 3 RC bugs already pending
* last upstream release in 2014 (ok, upstream and DD coincide)

if i dont hear back within a week with a good reason to keep this package in
Debian, i'll file for its removal.

Regards,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 bley depends on:
ii  adduser3.118
pn  dbconfig-common
ii  debconf [debconf-2.0]  1.5.72
ii  init-system-helpers1.57
ii  python 2.7.16-1
pn  python-dns 
pn  python-ipaddr  
pn  python-publicsuffix
pn  python-spf 
ii  python-twisted-core18.9.0-3
pn  python-twisted-names   

Versions of packages bley recommends:
pn  postfix | exim4 
pn  postgresql-client | mysql-client | sqlite3  
ii  python-mysqldb  1.3.10-2

bley suggests no packages.

Bug#951387: Please accept https://salsa.debian.org/installer-team/console-setup/merge_requests/3

[Nicholas D Steeves]

Hi Adrian,

John Paul Adrian Glaubitz  writes:

> On 3/9/20 10:33 PM, Nicholas D Steeves wrote:
>>> Hi, why such simple patch isn't accepted - 3 weeks already passed...
>>>
>> 
>> Don't feel bad!  Here's one I've been waiting three years for (tested
>> with custom install media in a VM):
>> 
>>   
>> https://salsa.debian.org/installer-team/partman-btrfs/-/merge_requests/1/commits
>
> I can have a look tomorrow.
>

Thank you!

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#953608: nm.debian.org: Some data belonging to legacy processes is no longer shown on the site

[Judit Foglszinger]

Package: nm.debian.org
Severity: minor

Some data belonging to legacy processes is no longer shown on the site

- Mailbox view (https://nm.debian.org/legacy/display-mail-archive/$PNR) 
doesn't show any mails

- On the process page (https://nm.debian.org/legacy/process/$PNR)
-- "Personal information"
advocates are not shown and neither the former graphic for Mailbox stats.
-- "Process log"
"Changed by" does not show uids

- On pages of Persons and AMs (https://nm.debian.org/person/$uid)
Old style process tables are also missing advocates

added a patch for the advocates and "Changed by" parts.>From 9bfbcd607d8e233302d9f0fe20c468117a825afd Mon Sep 17 00:00:00 2001
From: Judit Foglszinger 
Date: Wed, 11 Mar 2020 05:39:13 +0600
Subject: [PATCH] fix some references to uid (now person.ldap_fields.uid)

---
 legacy/templates/legacy/process.html  | 4 ++--
 public/templates/public/person_process_table.html | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/legacy/templates/legacy/process.html b/legacy/templates/legacy/process.html
index 61c63f9..63c171f 100644
--- a/legacy/templates/legacy/process.html
+++ b/legacy/templates/legacy/process.html
@@ -17,7 +17,7 @@
 {% trans "Advocate" %}{{process.advocates.count|pluralize}}
 
 {% for a in process.advocates.all %}
-{{a.uid}}{% if not forloop.last %},{% endif %}
+{{a.person.ldap_fields.uid}}{% if not forloop.last %},{% endif %}
 {% endfor %}
 
 
@@ -103,7 +103,7 @@
 {% endif %}
 {{l.logdate|date:"Y-m-d"}}
 
-{{l.changed_by.uid}}
+{{l.changed_by.person.ldap_fields.uid}}
 
 {{l.progress|desc_progress}}
 {% if visitor.am %}
diff --git a/public/templates/public/person_process_table.html b/public/templates/public/person_process_table.html
index 91a965c..9aa9f30 100644
--- a/public/templates/public/person_process_table.html
+++ b/public/templates/public/person_process_table.html
@@ -30,7 +30,7 @@
 
 
 {% for a in p.advocates.all %}
-{{a.uid}}{% if not forloop.last %},{% endif %}
+{{a.person.ldap_fields.uid}}{% if not forloop.last %},{% endif %}
 {% endfor %}
 
 
-- 
2.25.1



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

Bug#953604: vile: Mismatched source format vs source version

[Brendan O'Dea]

On Wed, Mar 11, 2020 at 12:57:59AM +0100, Guillem Jover wrote:
>From the historical data in snapshot.debian.org, this would appear as
>the build was done with a missing orig so dpkg-source considered it a
>native format?

Thanks for the report, and the pointer to the possible cause.

Indeed, this error was introduced into the builds of 9.8t-2 and -3, probably
as a result of the .orig.tar.gz having been inadvertantly removed.

I'll build a non-native 9.8t-4 now.

--bod

Bug#953603: [Tts-project] Bug#953603: festlex-oald: Mismatched source format vs source version

[Samuel Thibault]

Control: tags -1 + pending

Hello,

Guillem Jover, le mer. 11 mars 2020 00:53:36 +0100, a ecrit:
> From the historical data in snapshot.debian.org, this would appear as
> the build was done with a missing orig so dpkg-source considered it a
> native format?

It seems that's what happened indeed.  I guess I didn't run lintian
because the change in my dgit clone seemed trivial.

Thanks!
Samuel

Bug#953086: (no subject)

[Matthew Smith]

Exactly the same issue. Had to apt-get download the samba packages and 
--ignore-depends.


--
Matt Smith

Bug#947990: Two gdcm bugs fixed in Git

[peter green]

...
The following packages have unmet dependencies:
  python3-vtk7 : Depends: python3 (< 3.8) but 3.8.2-1 is to be installed
Unable to resolve dependencies!  Giving up...
...

This was a result of the python 3.8 transition, vtk7 has now been rebuilt on 
most architectures (mips is still building) and so it is now possible to 
satisfy the build-dependencies of gdcm.

I just did a test build, but unfortunately it failed.

cd /gdcm/obj-x86_64-linux-gnu/Utilities/VTK && /usr/bin/cmake -E make_directory /gdcm/obj-x86_64-linux-gnu/Utilities/VTK /gdcm/obj-x86_64-linux-gnu/Utilities/VTK/CMakeFiles/vtkgdcmsharpglue.dir && /usr/bin/cmake -E env SWIG_LIB=/usr/share/swig4.0 /usr/bin/swig4.0 -csharp -namespace vtkgdcm -dllimport vtkgdcmsharpglue -outdir /gdcm/obj-x86_64-linux-gnu/Utilities/VTK -c++ -I/usr/include -I/usr/include/vtk-7.1 -I/usr/include/freetype2 -I/usr/include/x86_64-linux-gnu -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/include/python3.8 -I/usr/include/hdf5/openmpi -I/usr/include/jsoncpp -I/usr/include/libxml2 -I/usr/include/tcl -I/gdcm/obj-x86_64-linux-gnu/Source/Common -I/gdcm/Source/Common -I/gdcm/Source/DataStructureAndEncodingDefinition -I/gdcm/Source/MediaStorageAndFileFormat -I/gdcm/Source/DataDictionary -I/gdcm/Utilities/VTK -o /gdcm/obj-x86_64-linux-gnu/Utilities/VTK/CMakeFiles/vtkgdcmsharpglue.dir/vtkgdcmCSHARP_wrap.cxx 
/gdcm/Utilities/VTK/vtkgdcm.i

/usr/include/vtk-7.1/vtkStringArray.h:36: Warning 402: Base class 
'vtkAbstractArray' is incomplete.
/usr/include/vtk-7.1/vtkAlgorithm.h:38: Warning 402: Only forward declaration 
'vtkAbstractArray' was found.
/gdcm/Utilities/VTK/vtkgdcm.i:354: Error: A deprecated csdestruct_derived 
typemap was found for vtkGDCMTesting, please remove it and replace all 
csdestruct, csdestruct_derived and csfinalize typemaps by the csdispose, 
csdispose_derived, csdisposing and csdisposing_derived typemaps.
/gdcm/Utilities/VTK/vtkgdcm.i:365: Error: A deprecated csdestruct_derived 
typemap was found for vtkGDCMImageReader, please remove it and replace all 
csdestruct, csdestruct_derived and csfinalize typemaps by the csdispose, 
csdispose_derived, csdisposing and csdisposing_derived typemaps.
/gdcm/Utilities/VTK/vtkgdcm.i:376: Error: A deprecated csdestruct_derived 
typemap was found for vtkGDCMImageWriter, please remove it and replace all 
csdestruct, csdestruct_derived and csfinalize typemaps by the csdispose, 
csdispose_derived, csdisposing and csdisposing_derived typemaps.
ninja: build stopped: subcommand failed.
dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j1 -v 
returned exit code 1
make[1]: *** [debian/rules:110: override_dh_auto_build-arch] Error 25
make[1]: Leaving directory '/gdcm'
make: *** [debian/rules:54: build] Error 2

Bug#953607: mgetty: Mismatched source format vs source version

[Guillem Jover]

Source: mgetty
Version: 1.2.1-1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
will start producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

From the historical data in snapshot.debian.org, this would appear as
the build was done with a missing orig so dpkg-source considered it a
native format?

Thanks,
Guillem

Bug#953606: wmxres: Mismatched source format vs source version

[Guillem Jover]

Source: wmxres
Version: 1.2-10.1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
will start producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

From the historical data in snapshot.debian.org, this would appear as
the build was done with a missing orig so dpkg-source considered it a
native format?

Thanks,
Guillem

Bug#953605: vmfs-tools: Mismatched source format vs source version

[Guillem Jover]

Source: vmfs-tools
Version: 0.2.5-1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
will start producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

From the historical data in snapshot.debian.org, this would appear as
the build was done with a missing orig so dpkg-source considered it a
native format?

Thanks,
Guillem

Bug#953604: vile: Mismatched source format vs source version

[Guillem Jover]

Source: vile
Version: 9.8t-3
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
will start producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

From the historical data in snapshot.debian.org, this would appear as
the build was done with a missing orig so dpkg-source considered it a
native format?

Thanks,
Guillem

Bug#953603: festlex-oald: Mismatched source format vs source version

[Guillem Jover]

Source: festlex-oald
Version: 2.4-2
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
will start producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

From the historical data in snapshot.debian.org, this would appear as
the build was done with a missing orig so dpkg-source considered it a
native format?

Thanks,
Guillem

Bug#953602: sec: Mismatched source format vs source version

[Guillem Jover]

Source: sec
Version: 2.8.2-1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
will start producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

From the historical data in snapshot.debian.org, this would appear as
the build was done with a missing orig so dpkg-source considered it a
native format?

Thanks,
Guillem

Bug#953601: mailsync: Mismatched source format vs source version

[Guillem Jover]

Source: mailsync
Version: 5.2.2-3.1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
will start producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

Thanks,
Guillem

Bug#953600: hp-ppd: Mismatched source format vs source version

[Guillem Jover]

Source: hp-ppd
Version: 0.9-0.3
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
will start producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

It would appear as if the problem was caused when the first NMU was
done by switching the version to a non-native scheme (instead of using
the newer convention of +nmuN). Doing so now would fix this issue.

Thanks,
Guillem

Bug#953599: aspell-cs: Mismatched source format vs source version

[Guillem Jover]

Source: aspell-cs
Version: 0.51.0-1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
will start producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

It would appear as if this was built with a missing orig tarball so
the 1.0 format "support" considered it a native format. Rebuilding
with the correct orig should fix this I guess.

Thanks,
Guillem

Bug#953598: focalinux: Mismatched source format vs source version

[Guillem Jover]

Source: focalinux
Version: 2010-09-3
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
will start producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

It seems this problem stems from trying to use a date formatted
version. The easiest fix would be to switch to use something like
«2010.09.03» for example which is greated than the current version.

Thanks,
Guillem

Bug#953561: mupdf: only displays first page of a PDF

[Kan-Ru Chen]

Hi,

On Wed, Mar 11, 2020, at 1:18 AM, Thorsten Glaser wrote:
> Package: mupdf
> Version: 1.16.1+ds1-1
> Severity: grave
> Justification: renders package unusable
> 
> mupdf only displays the first page of any PDF now, despite
> showing 1/2 in the title bar.
> 

I can partially reproduce this on my installation. If you advance page by the 
space key then sometimes it does not work. However if you use pageup/pagedown 
or ./, key then it always work.

Can you confirm?

Thanks,
Kanru

Bug#953597: dpkg-cross: Mismatched source format vs source version

[Guillem Jover]

Source: dpkg-cross
Version: 2.6.15-3
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
will start producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

Thanks,
Guillem

Bug#953596: dhcp-helper: Mismatched source format vs source version

[Guillem Jover]

Source: dhcp-helper
Version: 1.2-1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
will start producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

In addition this means this package cannot benefir from shipping
pristine upstream sources with their matching upstream signatures for
better provenance verifiability.

Thanks,
Guillem

Bug#953588: debootstrap: fails for mirrors without translations

[Johannes Schauer]

Control: block 953592 by -1

On Tue, 10 Mar 2020 23:04:03 +0100 Johannes 'josch' Schauer  
wrote:
> recent debootstrap fails silently if the given mirror does not contain
> translations.

this breaks the autopkgtest of mmdebstrap, thus adding the blocking bug.

It seems that even creating an APT_CONFIG with ' Acquire::Languages "none";' in
it gets ignored. Maybe the environment is somehow cleaned before debootstrap
calls apt-get?

signature.asc
Description: signature

Bug#953595: cramfsswap: Mismatched source format vs source version

[Guillem Jover]

Source: cramfsswap
Version: 1.4.1-1.1
Severity: important

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
will start producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

Thanks,
Guillem

Bug#952355: minlog: FTBFS: pdflatex error

[Andreas Beckmann]

Control: tag -1 unreproducible
Control: close -1

On Sun, 23 Feb 2020 14:48:21 +0100 Lucas Nussbaum  wrote:
> Source: minlog
> Version: 4.0.99.20100221-6
> Usertags: ftbfs-20200222 ftbfs-bullseye

> > pdflatex mpcref.tex >> /dev/null
> > make[2]: *** [Makefile:19: mpcref.pdf] Error 1

I cannot reproduce this in bullseye/sid as of today. There has been a
texlive upload inbetween, so this was probably a texlive bug.
I'm not going to investigate further but close this bug now.
Feel free to reopen if you can still reproduce it in your setup.

Andreas

Bug#953594: debootstrap: not anymore possible to do stable debootstrap from snapshot.d.o

[Johannes 'josch' Schauer]

Package: debootstrap
Version: 1.0.121
Severity: normal

Hi,

when I debootstrap a stable release from snapshot.d.o, the security
mirror gets added to the sources.list and an upgrade is performed. There
is no option to prevent this from happening. This means that I cannot
anymore create a chroot of a specific stable snapshot with debootstrap
because debootstrap will enforce an upgrade from the current security
mirror. I think it should be possible to use debootstrap for this
purpose.

Thanks!

cheers, josch


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

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

Versions of packages debootstrap depends on:
ii  wget  1.20.1-1.1

Versions of packages debootstrap recommends:
ii  arch-test   0.15-2
ii  debian-archive-keyring  2019.1
ii  gnupg   2.2.19-2

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client   
ii  ubuntu-keyring [ubuntu-archive-keyring]  2018.09.18.1-5

-- no debconf information

Bug#899425: O: gkremldk -- mldonkey plugin for gkrellm2

[Guillem Jover]

Control: retitle -1 RM: gkremldk -- RoQA; dead upstream, unmaintained, bogus 
source format
Control: reassign -1 ftp.debian.org

Hi!

I was about to NMU this package to fix its source format not matching
its version format, then I noticed that upstream has just disappeared.

   → 404

So I think it would be best to instead remove it.

Thanks,
Guillem

Bug#953569:

[Jason A. Donenfeld]

Please coordinate with me for doing this. Actually, if this sounds
interesting to you, I'll backport it myself, along with the missing
crypto/ bits, and send you a git bundle of patches for 5.5.

In other words, just say "yes please", and I'll supply the rest. Then
you can apply this to your tree and add the Provides as dkg asked.

Bug#953593: debootstrap: --no-check-gpg and --keyring options not working with Debian stable chroots

[Johannes 'josch' Schauer]

Package: debootstrap
Version: 1.0.121
Severity: normal

Hi,

the --keyring and --no-check-gpg options do not seem to be passed on to
"apt-get update". When I try to debootstrap with these options I get in
my debootstrap.log:

Ign:1 http://127.0.0.1:8000/debian stable InRelease
Hit:2 http://127.0.0.1:8000/debian stable Release
Ign:3 http://127.0.0.1:8000/debian stable Release.gpg
Get:4 http://security.debian.org/debian-security stable/updates InRelease [65.4 
kB]
Get:5 http://security.debian.org/debian-security stable/updates/main amd64 
Packages [182 kB]
Get:6 http://security.debian.org/debian-security stable/updates/main 
Translation-en [96.0 kB]
Reading package lists...
E: The repository 'http://127.0.0.1:8000/debian stable Release' is not signed.

The rest of debootstrap before worked fine because I used --no-check-gpg
but it fails at this step. Same with the --keyring option.

Thanks!

cheers, josch


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

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

Versions of packages debootstrap depends on:
ii  wget  1.20.1-1.1

Versions of packages debootstrap recommends:
ii  arch-test   0.15-2
ii  debian-archive-keyring  2019.1
ii  gnupg   2.2.19-2

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client   
ii  ubuntu-keyring [ubuntu-archive-keyring]  2018.09.18.1-5

-- no debconf information

Bug#953523: ITP: filetype.py -- Small module to infer binary file types via signature

[Eriberto]

Em ter., 10 de mar. de 2020 às 17:52, Scott Kitterman
 escreveu:
>
> It's ok.  Python policy only addresses binary package name.
>
> Scott K

Ok, thanks!

Bug#953589: smartlist: Use salsa (and Vcs-* fields, and gbp, and DEP-14) for smartlist debian packaging

[Santiago Vila]

On Tue, Mar 10, 2020 at 06:21:34PM -0400, Daniel Kahn Gillmor wrote:
> Package: src:smartlist
> Version: 3.15-25
> Severity: wishlist
> X-Debbugs-Cc: Santiago Vila , sanv...@debian.org
> 
> Santiago, I see that you've been responsible for smartlist in debian,
> and i noticed that the debian packaging for it it wasn't in any sort of
> VCS that i could find via the usual methods.
> 
> I find having my packages in a VCS make it easier to get help from other
> people but sometimes getting it into a public VCS is a pain.  So i took
> the step of collecting existing dsc's from snapshot.debian.org and
> applied them using "gbp" style and put a repo up at
> https://salsa.debian.org/debian/smartlist
> 
> If you like this change and are up for using this repo, i've made an MR
> that adds some VCS metadata to it:
> 
> https://salsa.debian.org/debian/smartlist/-/merge_requests/1
> 
> (and the patch is also attached here; we can do more substantive work
> later, if you like, such as trying to convert the packaging to dh)

I appreciate the effort, but there are a few things I dislike.
To name a few:

* The fact that several consecutive Debian releases are folded into the
same git commit.

* The fact that the master branch seems to be a mix of unstable + any
other security upload which happened in the past. IMHO, master should
match unstable and only unstable, and security releases should be in
extra branches. If this is against DEP-14 (I hope not), then I
definitely would not want to adopt DEP-14.

This is not to say that I don't want to switch to git and salsa in a
general sense, some day, but I do not feel comfortable with smartlist
being the first package to do the switch if done in this way.

I'd like to know what you think about this.

> If you don't like this move, close this bug as wontfix and i'll delete
> the repo from salsa!

The bug is ok as a wishlist in the sense of "please put smartlist in
salsa", but I do not feel like using the repo in its current state, I
would certainly have done it differently, so maybe yes it would be
better to remove the repo.

(However, I will appreciate any kind of mentoring towards putting
smartlist and all my packages, some day, in salsa, please contact me
privately if you would like to help me for that).

Thanks.

Bug#644757: Removing ocaml-book?

[Guillem Jover]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: ocaml-book -- RoQA: unmaintained, partial, non-free, 
bogus source format

On Sat, 2014-01-25 at 23:38:19 +0200, Adrian Bunk wrote:
> since ocaml-book is:
> - orphaned since 2011 and
> - in non-free and
> - a small subset of what a user gets when goes to [1]
> I wonder whether it actually makes sense to keep ocaml-book in non-free, 
> or whether it could be removed.

> [1] http://caml.inria.fr/resources/doc/index.en.html

Yes. In addition I was about to NMU it to fix its bogus source format
relative to its source version, and noticed it's in non-free and has
been unmaintained now for a very long time.

Thanks,
Guillem

Bug#953592: mmdebstrap: autopkgtest fails

[Johannes 'josch' Schauer]

Package: mmdebstrap
Version: 0.6.0-4
Severity: normal

mmdebstrap compares its output to debootstrap in its autopkgtest. But
currently, debootstrap fails to create a stable chroot for mirrors
without translations enabled. This breaks the autopkgtest of mmdebstrap.


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

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

Versions of packages mmdebstrap depends on:
ii  apt   1.9.10
ii  perl  5.30.0-9

Versions of packages mmdebstrap recommends:
ii  arch-test   0.15-2
ii  fakechroot  2.19-3.2
ii  fakeroot1.24-1
ii  gpg 2.2.19-2
ii  mount   2.34-0.1
ii  uidmap  1:4.5-1.1

Versions of packages mmdebstrap suggests:
ii  binfmt-support2.2.0-2
ii  dpkg-dev  1.19.7
ii  perl-doc  5.30.0-9
ii  proot 5.1.0-1.3
ii  qemu-user 1:3.1+dfsg-8+deb10u4
ii  qemu-user-static  1:4.2-3

-- debconf-show failed

Bug#953591: bash: colors should be enabled by default (force_color_prompt)

[Cameron Tacklind]

Package: bash
Version: 5.0-4ubuntu1
Severity: minor
Tags: a11y

Dear Maintainer,

It is now 2020 and colors on a terminal are generally very well supported.
That colors are not enabled by default does not make sense to me. When a
terminal does not support colors, I've rarely, if ever, had that
incorrectly detected.

The Debian Wiki for [BashColors](https://wiki.debian.org/BashColors)
says "Its output can be colorized to increase human readability." However,
that seems to go against the text in `/etc/skel/.bashrc` that states
colors are "turned off by default to not distract the user".

Frankly, imho, the reasoning in the `.bashrc` file does not make sense,
nor does it to all of the people that have commented on the Stack
Exchange post referenced on the Wiki (the title, and thus URL, has been
changed and thus the link in the wiki is broken):
https://unix.stackexchange.com/questions/329581/why-is-debians-default-bash-shell-colorless

It looks to me like the Debian package is where the offending `.bashrc`
is defined and thus copied to many other systems.

It is my opinion that the color handling section of `.bashrc` should be
rewritten. There is already some confusion about `force_color_prompt`
because it does not *force* colors in all cases. I think a more
appropriate variable/setting would be something like `colorless_prompt`
or `force_colorless_prompt` for those that prefer bash to be colorless.

Thank you for considering this request.

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

Kernel: Linux 5.3.0-40-generic (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 bash depends on:
ii  base-files   10.2ubuntu7
ii  debianutils  4.8.6.3
ii  libc62.30-0ubuntu2
ii  libtinfo66.1+20190803-1ubuntu1

Versions of packages bash recommends:
ii  bash-completion  1:2.9-1ubuntu1

Versions of packages bash suggests:
pn  bash-doc  

-- Configuration Files:
/etc/skel/.bashrc changed [not included]

-- no debconf information

Bug#953590: libplacebo21: Upload to unstable, please

[Sebastian Ramacher]

Control: tags -1 + wontfix

On 2020-03-10 23:39:42, Daniel Vacek wrote:
> Package: libplacebo21
> Version: 1.21.0+dfsg1-1
> Severity: wishlist
> 
> Latest version of mpv media player could use libplacebo >= 1.18 to enable
> the Vulkan based video renderer. It would be nice to have this option as
> an alternative to the OpenGL based one.
> 
> I am not sure why libplacebo was not updated in sid lately but if it is
> possible, please do so for the benefit of the mpv at least.

VLC 3.0.8 does not build with libplacebo 1.21.0, so that's not going to
happen until VLC gets fixed.

Best
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#953554: Please permit Debian revisions with 1.0 native packages

[Felix Lechner]

Hi Ian,

On Tue, Mar 10, 2020 at 7:51 AM Ian Jackson
 wrote:
>
> I am packaging a small program for which I am the upstream.  It does
> not make sense to use a complicated source format; 1.0 native is
> perfect.

I too would like to see versions decoupled from the native/non-native
question, but I think there are big technical hurdles.

Maybe one day all version strings will be legal, even when a native
format was declared. It would not work with format 1.0, which contains
no such declaration.

Kind regards
Felix Lechner

Bug#953590: libplacebo21: Upload to unstable, please

[Daniel Vacek]

Package: libplacebo21
Version: 1.21.0+dfsg1-1
Severity: wishlist

Latest version of mpv media player could use libplacebo >= 1.18 to enable
the Vulkan based video renderer. It would be nice to have this option as
an alternative to the OpenGL based one.

I am not sure why libplacebo was not updated in sid lately but if it is
possible, please do so for the benefit of the mpv at least.

Thank you. Have a nice day!

--nX

Bug#953589: smartlist: Use salsa (and Vcs-* fields, and gbp, and DEP-14) for smartlist debian packaging

[Daniel Kahn Gillmor]

Package: src:smartlist
Version: 3.15-25
Severity: wishlist
X-Debbugs-Cc: Santiago Vila , sanv...@debian.org

Santiago, I see that you've been responsible for smartlist in debian,
and i noticed that the debian packaging for it it wasn't in any sort of
VCS that i could find via the usual methods.

I find having my packages in a VCS make it easier to get help from other
people but sometimes getting it into a public VCS is a pain.  So i took
the step of collecting existing dsc's from snapshot.debian.org and
applied them using "gbp" style and put a repo up at
https://salsa.debian.org/debian/smartlist

If you like this change and are up for using this repo, i've made an MR
that adds some VCS metadata to it:

https://salsa.debian.org/debian/smartlist/-/merge_requests/1

(and the patch is also attached here; we can do more substantive work
later, if you like, such as trying to convert the packaging to dh)

If you don't like this move, close this bug as wontfix and i'll delete
the repo from salsa!

Or, if you've got your own repo that you use for this, and prefer to
wipe out the existing salsa repo and replace it with that one, that'd be
fine too.

I appreciate all the work you've done on smartlist over the years!

Hope this is helpful,

 --dkg

From d2534c4736ff817f8fda92feeb945f86cebdd43f Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Tue, 10 Mar 2020 18:03:54 -0400
Subject: [PATCH] added Vcs headers and acknowledge attempt to use DEP-14

---
 debian/control  | 2 ++
 debian/gbp.conf | 2 ++
 2 files changed, 4 insertions(+)
 create mode 100644 debian/gbp.conf

diff --git a/debian/control b/debian/control
index 514bbc8..dafcb93 100644
--- a/debian/control
+++ b/debian/control
@@ -3,6 +3,8 @@ Section: mail
 Priority: optional
 Maintainer: Santiago Vila 
 Standards-Version: 3.8.3
+Vcs-Git: https://salsa.debian.org/debian/smartlist.git
+Vcs-Browser: https://salsa.debian.org/debian/smartlist
 
 Package: smartlist
 Architecture: any
diff --git a/debian/gbp.conf b/debian/gbp.conf
new file mode 100644
index 000..3879982
--- /dev/null
+++ b/debian/gbp.conf
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch=debian/master
-- 
2.25.1



signature.asc
Description: PGP signature

Bug#951709: /boot should get a bigger share of disk in default installation

[Julien Cristau]

On Tue, Mar 10, 2020 at 09:50:07PM +0100, Holger Wansing wrote:
> Hi,
> 
> Ben Hutchings  wrote:
> > On Thu, 2020-02-20 at 18:50 +0530, Pirate Praveen wrote:
> > > Package: debian-installer
> > > Version: 20190702+deb10u3
> > > Severity: important
> > > 
> > > With initrd around 60+ MBs, 236 MB /boot in a 300 GB hard disk can hold 
> > > only 2 versions of the kernels at the same time. When installing a 3rd 
> > > kernel /boot gets filled up. I think it should be able to store at 
> > > least 3 kernels and ideally 4 or even more.
> > >
> > > The paritions were created automatically with just /home in a separate 
> > > partition with lvm by debian buster installer.
> > 
> > I agree; the default size of /boot is now too small.  I think we should
> > normally allocate at least 500 MB to it.
> 
> This has just been addressed; see
> https://salsa.debian.org/installer-team/partman-auto/-/commit/cf6b2d152b08b6c78da6a6f7ca26a99bdadfdfce
> 
Not quite.  If Ben says we need at least 500M, then we'll have to
adjust further, as that commit uses 512M as a maximum.  For comparison
Ubuntu's partman-auto sets the min at 512M and max at 768M.  Do people
feel that's where we should go?

Cheers,
Julien

Bug#953588: debootstrap: fails for mirrors without translations

[Johannes 'josch' Schauer]

Package: debootstrap
Version: 1.0.121
Severity: normal

Hi,

recent debootstrap fails silently if the given mirror does not contain
translations. From debootstrap.log:

Ign:1 http://127.0.0.1/debian stable InRelease
Hit:2 http://127.0.0.1/debian stable Release
Ign:4 http://127.0.0.1/debian stable/main Translation-en
Ign:4 http://127.0.0.1/debian stable/main Translation-en
Ign:4 http://127.0.0.1/debian stable/main Translation-en
Err:4 http://127.0.0.1/debian stable/main Translation-en
  404  File not found [IP: 127.0.0.1 80]
Get:5 http://security-cdn.debian.org/debian-security stable/updates InRelease 
[65.4 kB]
Get:6 http://security-cdn.debian.org/debian-security stable/updates/main amd64 
Packages [182 kB]
Get:7 http://security-cdn.debian.org/debian-security stable/updates/main 
Translation-en [96.0 kB]
Fetched 343 kB in 1s (501 kB/s)
Reading package lists...
E: Failed to fetch 
http://127.0.0.1/debian/dists/stable/main/i18n/Translation-en  404  File not 
found [IP: 127.0.0.1 80]
E: Some index files failed to download. They have been ignored, or old ones 
used instead.


Another problem is, that this happens silently after the message "I:
Base system installed successfully." I noticed the problem because my
shell is printing the exit status of the last command but other users
might just think that debootstrap finished successfully. There should
definitely be some kind of error message when apt fails. Best including
either the reason or a pointer to debootstrap.log which is currently not
documented in the man page.

Thanks!

cheers, josch


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

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

Versions of packages debootstrap depends on:
ii  wget  1.20.1-1.1

Versions of packages debootstrap recommends:
ii  arch-test   0.15-2
ii  debian-archive-keyring  2019.1
ii  gnupg   2.2.19-2

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client   
ii  ubuntu-keyring [ubuntu-archive-keyring]  2018.09.18.1-5

-- debconf-show failed

Bug#953389: [Pkg-zsh-devel] Processed: Fwd: [zsh:code] New commit [0d7f88] by Romain Porte

[Daniel Shahaf]

Debian Bug Tracking System wrote on Tue, 10 Mar 2020 15:48 +00:00:
> Processing commands for cont...@bugs.debian.org:
> > tag 953389 fixed-upstream
> Bug #953389 [zsh-common] zsh-common: completion for dscverify is missing
> Added tag(s) fixed-upstream.

The upstream commit hash was recorded in the message to control@ below
the «thanks» line:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953389;msg=38

Cheers,

Daniel

> > thanks
> Stopping processing here.
> > ⋮

Bug#936629: gnukhata-core-engine: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:19:09AM +, Matthias Klose wrote:
> Package: src:gnukhata-core-engine
> Version: 2.6.1-3
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

There hasn't been a gnukhata-core-engine upload since four years,
should it be removed or are you planning to port it to Python 3?

Cheers,
Moritz

Bug#936216: bley: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Fri, Aug 30, 2019 at 07:11:48AM +, Matthias Klose wrote:
> Package: src:bley
> Version: 2.0.0-2
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.

Hi,
Are you planning to port bley to Python 3 or should it be removed?

Cheers,
Moritz

Bug#953586: RM: twextpy -- RoQA; Depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove twextpy. It depends on Python 2. It's only
reverse dependency (calendarserver) was recently removed.

Cheers,
Moritz

Bug#953587: dojo: CVE-2020-5259

[Salvatore Bonaccorso]

Source: dojo
Version: 1.15.2+dfsg1-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for dojo.

CVE-2020-5259[0]:
| In affected versions of dojox (NPM package), the jqMix method is
| vulnerable to Prototype Pollution. Prototype Pollution refers to the
| ability to inject properties into existing JavaScript language
| construct prototypes, such as objects. An attacker manipulates these
| attributes to overwrite, or pollute, a JavaScript application object
| prototype of the base object by injecting other values. This has been
| patched in versions 1.11.10, 1.12.8, 1.13.7, 1.14.6, 1.15.3 and 1.16.2


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-2020-5259
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5259
[1] https://github.com/dojo/dojox/security/advisories/GHSA-3hw5-q855-g6cw
[2] 
https://github.com/dojo/dojox/commit/47d1b302b5b23d94e875b77b9b9a8c4f5622c9da

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#953584: libsbml: FTBFS on mipsel

[Ivo De Decker]

package: src:libsbml
version: 5.18.0+dfsg-1
severity: serious
tags: ftbfs

Hi,

The latest upload of libsbml to unstable fails on mipsel:

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

Cheers,

Ivo

Bug#953585: dojo: CVE-2020-5258

[Salvatore Bonaccorso]

Source: dojo
Version: 1.15.2+dfsg1-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for dojo.

CVE-2020-5258[0]:
| In affected versions of dojo (NPM package), the deepCopy method is
| vulnerable to Prototype Pollution. Prototype Pollution refers to the
| ability to inject properties into existing JavaScript language
| construct prototypes, such as objects. An attacker manipulates these
| attributes to overwrite, or pollute, a JavaScript application object
| prototype of the base object by injecting other values. This has been
| patched in versions 1.12.8, 1.13.7, 1.14.6, 1.15.3 and 1.16.2


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-2020-5258
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5258
[1] https://github.com/dojo/dojo/security/advisories/GHSA-jxfh-8wgv-vfr2
[2] https://github.com/dojo/dojo/commit/20a00afb68f5587946dc76fbeaa68c39bda2171d

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#953583: gthumb: Please package new upstream version (3.9.1)

[Boyuan Yang]

Source: gthumb
Severity: important
Version: 3:3.8.0-2.1
X-Debbugs-CC: h...@debian.org

Dear Debian gthumb maintainer,

The upstream developer of gthumb has released a new version (v3.9.1). Please
consider packaging it in Debian.

-- 
Regards,
Boyuan Yang


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

Bug#953582: imap-dl: update documentation to be less about getmail

[Daniel Kahn Gillmor]

Package: mailscripts
Version: 0.18-1
Severity: wishlist
Control: tags -1 + patch
X-debbugs-cc: Antoine Beaupré 

imap-dl's documentation was written from where i was coming from when i
wrote imap-dl.

Some new users have found it recently and wondered why they needed to
refer to getmail documentation to understand it.  This patch fixes that
concern.

I also want potential new features (like
https://github.com/spwhitton/mailscripts/pull/1) to have a place to
document any particular configuration options that they might add.

You can also find the attached patch on my "documentation" branch at
https://salsa.debian.org/dkg/mailscripts.

Thanks for maintaining imap-dl in mailscripts!

   --dkg

fFrom 66a987a52a66aa36b3dfdb4ab8fa6af1c0d5ccf2 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Tue, 10 Mar 2020 17:16:10 -0400
Subject: [PATCH] imap-dl: update documentation to be less explicitly
 "getmail"y

The fact that imap-dl came out of getmail and borrows a bit of
configuration shouldn't be relevant for new users.

Make the documentation more agnostic about where they're coming from.

Signed-off-by: Daniel Kahn Gillmor 
---
 imap-dl   | 19 ---
 imap-dl.1.pod | 48 +---
 2 files changed, 41 insertions(+), 26 deletions(-)

diff --git a/imap-dl b/imap-dl
index 469b81d..de6be60 100755
--- a/imap-dl
+++ b/imap-dl
@@ -17,22 +17,9 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see .
 
-DESCRIPTION = '''A simple replacement for a minimalist use of getmail.
+DESCRIPTION = '''Fetch messages from an IMAP inbox into a maildir
 
-In particular, if you use getmail to reach an IMAP server as though it
-were POP (retrieving from the server and optionally deleting), you can
-point this script to the getmail config and it should do the same
-thing.
-
-It tries to ensure that the configuration file is of the expected
-type, and will terminate raising an exception, and it should not lose
-messages.
-
-If there's any interest in supporting other similarly simple use cases
-for getmail, patches are welcome.
-
-If you've never used getmail, you can make the simplest possible
-config file like so:
+Example config file:
 
 --
 [retriever]
@@ -46,6 +33,8 @@ path = /home/foo/Maildir
 [options]
 delete = True
 --
+
+Run "man imap-dl" for more details.
 '''
 
 import re
diff --git a/imap-dl.1.pod b/imap-dl.1.pod
index 9fb77c3..901c7e8 100644
--- a/imap-dl.1.pod
+++ b/imap-dl.1.pod
@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-imap-dl -- a simple replacement for a minimalist user of getmail
+imap-dl -- fetch messages from an IMAP inbox into a maildir
 
 =head1 SYNOPSIS
 
@@ -10,35 +10,61 @@ B [B<-v>|B<--verbose>] B...
 
 =head1 DESCRIPTION
 
+B tries to retrieve all messages from an IMAP inbox and put
+them in a maildir.
+
 If you use getmail to reach an IMAP server as though it were POP
 (retrieving from the server, storing it in a maildir and optionally
-deleting), you can point this script to the getmail config and it
-should do the same thing.
+deleting), you can point this script to the getmail configfile and it
+should do the same thing.  While the minimal configuration file
+matches the syntax for common getmail configurations, some other
+options might be specific to B.
 
-It tries to ensure that the configuration file is of the expected
-type, and otherwise it will terminate with an error.  It should not
-lose e-mail messages.
+B tries to ensure that the configuration file is of the
+expected type, and otherwise it will terminate with an error.  It
+should never lose e-mail messages.
 
 If there's any interest in supporting other similarly simple use cases
-for getmail, patches are welcome.
+for fetching messages from an IMAP account into a maildir, patches are
+welcome.
 
 =head1 OPTIONS
 
 B<-v> or B<--verbose> causes B to print more details
 about what it is doing.
 
+=head1 CONFIGFILE OPTIONS
+
+B uses an ini-style configfile, with [Sections] which each
+have keyword arguments within them.  We use the syntax B here
+to mean keyword B in section B.  B inherits some
+basic configuration options from B, including the following
+options:
+
+B is the dns name of the mailserver.
+
+B is the username of the IMAP account.
+
+B is the password for the IMAP account when using
+plaintext passwords.
+
+B is the location of the target maildir.
+
+B is a boolean, whether to delete the messages that
+were successfully retreived (default: false).
+
 In addition to parts of the standard B configuration,
-B supports the following keywords in the config file:
+B supports the following keywords in the configfile:
 
 B can be set to B, B, or
 B.  This governs what to do when the remote IMAP server claims a
 different size in the message summary list than the actual message
 retrieval (default: B).
 
-=head1 EXAMPLE CONFIG
+=head1 EXAMPLE CONFIGFILE
 
-If you've never used 

Bug#886870: ldapvi FTCBFS: uses the build architecture pkg-config

[Sudip Mukherjee]

I have tried to cross-build on arm64 with the attached patch but it
fails with the error:

Package glib-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glib-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glib-2.0' found
Package glib-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glib-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glib-2.0' found

And then fails to find "glib.h".

Same for armel also.

-- 
Regards
Sudip

Bug#953527: [apt] colour highlighted error/warn labels

[jnqnfe]

On Tue, 2020-03-10 at 21:10 +0100, Julian Andres Klode wrote:
> Control: severity -1 wishlist
> Control: tag -1 confirmed
> 
> On Tue, Mar 10, 2020 at 06:13:28AM +, jnq...@gmail.com wrote:
> > Package: src:apt
> > Version: 2.0.0
> > 
> > Please add red/yellow colour highlighting to the 'E'/'W' prefixex
> > respectively output for errors/warnings respectively. (UX
> > improvement).
> > 
> > This would not only benefit direct use of apt binaries, but also be
> > beneficial when used in scripting, such as with live-build where a
> > warnign could be hidden in the middle of a great deal more output
> > that
> > with direct use.
> 
> How does the attached look? Bold red for error, bold yellow for
> warning and yellow for notice; matching dpkg.

looks perfectly fine to me in principle. I'm familiar with dpkg's
colouring which sticks to the common values of "\033[1;31m" (red+bold)
for error and "\033[1;33m" (yellow+bold) for warnings, which is what
I'm sure you've probably used also and is inline with my expectations
:)

Bug#953554: Please permit Debian revisions with 1.0 native packages

[Guillem Jover]

Hi!

[ I was pointed out to this bug, so chiming in. :) ]

On Tue, 2020-03-10 at 14:47:12 +, Ian Jackson wrote:
> Package: lintian
> Version: 2.55.0

> I am packaging a small program for which I am the upstream.  It does
> not make sense to use a complicated source format; 1.0 native is
> perfect.
> 
> Even though I am both upstream and Debian maintainer, this is not a
> Debian-specific package and it might have both (i) changes in Debian
> that have no upstream implications and (ii) changes upstream that
> affect more than Debian.

I see why using a native source package in such case can be more
convenient. And I also think it is reasonable and something that a
maintainer should be able to decide whenever and whether the
trade-offs are worth it.

Personally, this is something that I'd never do, because I find it
alters the nature of native source packages, and makes it more confusing
for others to understand and handle within Debian and relative to
upstream, but I also obviously consider it acceptable for others to
disagree with this view!

> A non-native version is the best way to reflect that.

But, I don't find this to be very reasonable, because while the previous
is a conceptual mismatch (what we consider upstream and packaging,
etc), this one is a technical or interface mismatch, that makes dealing
with these packages more complex and in need of special casing, etc.

So…

> However,
> 
> E: chiark-tcl-applet source: malformed-debian-changelog-version 1.0-1~
> (for native)
> 
> For the reasons above I disagree with calling this an error.
> Previously it was a warning.  (Full disclosure: I know the dpkg
> maintainer disagrees with my position here.)

…would you be amenable to instead change the way you version these
kind of packages, and use some other marker instead of «-»? Say «+» or
a word like «rev» like in «1.0rev1» or similar construct?

Which would give you the properties you look for, while not messing
with the semantics of the source and version formats, so that we can
keep them consistent?


I am also, as mentioned on d-d, already in the process to start
obsoleting this in dpkg-dev, and already prepared an initial patch for
dpkg yesterday [O], because we currently only have 33 such packages in
the archive, where I have the impression most if not all (except at least
for the one you maintain and the python default packages) seem due to
packaging error.

[O] 


Thanks,
Guillem

Bug#953554: Please permit Debian revisions with 1.0 native packages

[Chris Lamb]

Mattia Rizzolo wrote:

> In my opinion your statements here doesn't make any sense: using a 
> Debian revision when you are not relying on a single upstream tarball 
> (i.e., non-native) really is going against the implied meaning of a 
> Debian revision: something that is not supposed to change the upstream 
> part.

Whilst I would broadly agree with Mattia's view, I would also concede
that there is something just a little unsatisfactory about an upload
just changing, for example, a single entry in debian/control and that
bumping the [upstream] version number.

However, I would be minded to not adjust Lintian in this particular
case regardless of the above: I suspect in the overwhelming majority
of cases where this tag is emitted it is due to a temporary mistake
such as a typo on behalf of the maintainer which is then immediately
corrected locally. Indeed, I am often guilty of "dch -v 1.0-1" for
packages where I definitely do not intend this suffix and I would very
much like to see that prior to an upload.

Have you considered adding a (commented!) override for this particular
package? I suspect your response may be to suggest we allow this for
1.0 version source packages, but I must confess it would need
explaining to me that the version (eg. "native (1.0)" vs "native
(3.0)") is a distinction to be made here at all.


Best wishes,

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

Bug#947936: chrony: Does (still) not start properly on boot on buster

[Vincent Blut]

Control: tags -1 pending

Santiago, Michael, does that changelog entry about this issue feels 
clear to you?


https://salsa.debian.org/debian/chrony/-/blob/master/debian/changelog


On 2020-01-02T13:38+0100, Santiago Vila wrote:

Package: chrony
Version: 3.4-4
Severity: important

Dear maintainer:

Apparently, installing chrony does not ensure at all that it will work.

Google has moved from ntp in Debian 9 to chrony in Debian 10 for their
default Debian GCE images, and I discovered this on a lot of GCE
instances having a clock several minutes off.

The problem I found is very similar to the one described here:

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

I believe the best summary of the problem was made by Michael Biebl
here:

https://github.com/systemd/systemd/issues/7104#issuecomment-471329392

Quoting Michael:

As it stands, the current practice of having systemd-timesyncd.service
enabled by default (in Debian) and alternative implementations like
chrony or ntpd declare Conflicts=systemd-timesyncd.service in their
service file does not work reliably.



AFAIK, this has been fixed on the systemd side in version 241-3 by
dropping the "Conflicts" systemd had on chrony or ntpd.

Unfortunately, AFAIK, conflicts are bi-directional, so apparently the
problem will persist in buster as far as chrony still has conflicts
in the systemd unit file.

I've noticed this problem happens randomly (it happens in some
instances, it does not happens in some others), so I don't have a
"recipe" as such to reproduce it.

However, I have a particular instance at GCE showing this behaviour
which I could try to clone to give you ssh access if required (please
contact me privately for details).

The behaviour is the following:

Both systemd-timesyncd and chrony are enabled (which is the default
on GCE instances). Just after a reboot, "systemctl status chrony" shows this:

● chrony.service - chrony, an NTP client/server
  Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: 
enabled)
  Active: inactive (dead)
  Docs: man:chronyd(8)
  man:chronyc(1)
  man:chrony.conf(5)

and I see this in the boot log:

systemd[1]: Condition check resulted in Network Time Synchronization being 
skipped.

If I do "systemctl disable systemd-timesyncd" and reboot, chrony is
properly loaded and it runs.

If I do "systemctl enable systemd-timesyncd" again and reboot, chrony
is shown as "inactive (dead)" again.

At this point, if I edit 
/etc/systemd/system/multi-user.target.wants/chrony.service
to remove the Conflicts line and reboot, chrony is properly loaded and it runs.

[ I'm reporting this as "important" because I believe it to be the kind
 of bug that should be fixed in a point release of Debian 10 ].

[ Cc to Michael Biebl in case he would like to comment on the issue ].

Thanks.


signature.asc
Description: PGP signature

Bug#953581: manila: CVE-2020-9543: Unprivileged users can retrieve, use and manipulate share networks

[Salvatore Bonaccorso]

Source: manila
Version: 1:9.0.0-3
Severity: important
Tags: security upstream
Forwarded: https://bugs.launchpad.net/manila/+bug/1861485
Control: found -1 1:7.0.0-1
Control: found -1 1:3.0.0-5

Hi,

The following vulnerability was published for manila.

CVE-2020-9543[0]:
Unprivileged users can retrieve, use and manipulate share networks

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-2020-9543
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9543
[1] https://bugs.launchpad.net/manila/+bug/1861485

Regards,
Salvatore

Bug#953547: RFS: libusb3380/0.0.1+git20190125.c83d1e9-1 [ITP] -- USB3380 abstraction layer for libusb: development

[Sepi Gair]

Hello, Christoph,

I fixed both issues.

On Tue, 2020-03-10 at 17:44 +0100, Christoph Berg wrote:
> Hi Sepi,
> 
> there's a missing copyright attribution:
> 
> ./cmake_modules/Findlibusb-1.0.cmake:
> #  Adapted from cmake-modules Google Code project
> #
> #  Copyright (c) 2006 Andreas Schneider
> #
> #  (Changes for libusb) Copyright (c) 2008 Kyle Machulis
> #
> # Redistribution and use is allowed according to the terms of the New
> BSD license.
> #
> # CMake-Modules Project New BSD License
> #
> # Redistribution and use in source and binary forms, with or without
> # modification, are permitted provided that the following conditions
> are met:
> #
> # * Redistributions of source code must retain the above copyright
> notice, this
> #   list of conditions and the following disclaimer.
> #
> # * Redistributions in binary form must reproduce the above copyright
> notice,
> #   this list of conditions and the following disclaimer in the
> #   documentation and/or other materials provided with the
> distribution.
> #
> # * Neither the name of the CMake-Modules Project nor the names of
> its
> #   contributors may be used to endorse or promote products derived
> from this
> #   software without specific prior written permission.
> #
> # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS" AND
> # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE IMPLIED
> # WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> ARE
> # DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
> BE LIABLE FOR
> # ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> CONSEQUENTIAL DAMAGES
> # (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> SERVICES;
> #  LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> CAUSED AND ON
> 
> This looks like the lib should be linked with pthreads:
> 
> dpkg-shlibdeps: warning: symbol pthread_setname_np used by
> debian/libusb3380-0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1
> found in none of the libraries
> dpkg-shlibdeps: warning: symbol sem_destroy used by
> debian/libusb3380-0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1
> found in none of the libraries
> dpkg-shlibdeps: warning: symbol sem_post used by debian/libusb3380-
> 0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1 found in none of the
> libraries
> dpkg-shlibdeps: warning: symbol pthread_join used by
> debian/libusb3380-0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1
> found in none of the libraries
> dpkg-shlibdeps: warning: symbol pthread_sigmask used by
> debian/libusb3380-0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1
> found in none of the libraries
> dpkg-shlibdeps: warning: symbol pthread_create used by
> debian/libusb3380-0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1
> found in none of the libraries
> dpkg-shlibdeps: warning: symbol sem_init used by debian/libusb3380-
> 0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1 found in none of the
> libraries
> dpkg-shlibdeps: warning: symbol sem_wait used by debian/libusb3380-
> 0/usr/lib/x86_64-linux-gnu/libusb3380.so.0.0.1 found in none of the
> libraries
> 
> /usr/lib/x86_64-linux-gnu/libpthread.so:00011370 T sem_close
> /usr/lib/x86_64-linux-gnu/libpthread.so:00010b60 T
> sem_destroy@@GLIBC_2.2.5
> /usr/lib/x86_64-linux-gnu/libpthread.so:000115a0 T
> sem_getvalue@@GLIBC_2.2.5
> /usr/lib/x86_64-linux-gnu/libpthread.so:00010b20 T
> sem_init@@GLIBC_2.2.5
> /usr/lib/x86_64-linux-gnu/libpthread.so:00010e60 T sem_open
> /usr/lib/x86_64-linux-gnu/libpthread.so:000119c0 T
> sem_post@@GLIBC_2.2.5
> /usr/lib/x86_64-linux-gnu/libpthread.so:00011950 T
> sem_timedwait
> /usr/lib/x86_64-linux-gnu/libpthread.so:00011780 T
> sem_trywait@@GLIBC_2.2.5
> /usr/lib/x86_64-linux-gnu/libpthread.so:00011470 T sem_unlink
> /usr/lib/x86_64-linux-gnu/libpthread.so:00011740 T
> sem_wait@@GLIBC_2.2.5
> 
> (Not sure this is the correct solution, though.)
> 
> The rest is fine and good to go I think.
> 
> Christoph
> 

Bug#953523: ITP: filetype.py -- Small module to infer binary file types via signature

[Scott Kitterman]

It's ok.  Python policy only addresses binary package name.

Scott K

Bug#953580: Wishlist: pushing xorg-server into buster-backports repo

[Luna Vermilion]

Package: xorg-server
Version:  2:1.20.7-4
Severity: wishlist

Dear Developers,

Noticing that the package xorg-server 2:1.20.7-3 has been in the testing
repo for around a month. I wonder if it is possible to get it pushed into
the buster-backports repo.

To be more specific, the feature I am expecting is the function of prime
GPU offloading of Nvidia graphic cards for optimus systems, which has been
added into xserver-xorg-core since 1.20.6.

Thanks for your time and help.

Bug#951709: /boot should get a bigger share of disk in default installation

[Holger Wansing]

Hi,

Ben Hutchings  wrote:
> On Thu, 2020-02-20 at 18:50 +0530, Pirate Praveen wrote:
> > Package: debian-installer
> > Version: 20190702+deb10u3
> > Severity: important
> > 
> > With initrd around 60+ MBs, 236 MB /boot in a 300 GB hard disk can hold 
> > only 2 versions of the kernels at the same time. When installing a 3rd 
> > kernel /boot gets filled up. I think it should be able to store at 
> > least 3 kernels and ideally 4 or even more.
> >
> > The paritions were created automatically with just /home in a separate 
> > partition with lvm by debian buster installer.
> 
> I agree; the default size of /boot is now too small.  I think we should
> normally allocate at least 500 MB to it.

This has just been addressed; see
https://salsa.debian.org/installer-team/partman-auto/-/commit/cf6b2d152b08b6c78da6a6f7ca26a99bdadfdfce

I will adjust the changelog to close this bug as well.


Holger

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

Bug#953578: libarchive: CVE-2019-20509

[Salvatore Bonaccorso]

Source: libarchive
Version: 3.4.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libarchive/libarchive/issues/1284

Hi,

The following vulnerability was published for libarchive.

CVE-2019-20509[0]:
| archive_read_support_format_lha.c in libarchive before 3.4.1 does not
| ensure valid sizes for UTF-16 input, which allows remote attackers to
| cause a denial of service (heap-based buffer over-read and application
| crash) via a crafted LHA archive.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-20509
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20509
[1] https://github.com/libarchive/libarchive/issues/1284
[2] 
https://github.com/libarchive/libarchive/commit/91cf9372e89f7af4582964b15ceb7fc6d1b37471

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#953579: ITP: vir2-p2v -- Convert a physical machine to use KVM

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: virt-p2v
  Version : 1.42.0
  Upstream Author : Red Hat Inc.
* URL or Web page : https://libguestfs.org/
* License : GPL2+
  Description : Convert a physical machine to use KVM

As of version 1.42.0, virt-p2v is no longer part of libguestfs but
distributed as a sepearate package.

Bug#953577: pam-geoip: Breaks Git over SSH with error message from libgeoip

[Michael Fladischer]

Source: pam-geoip
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I installed libpam-geoip and use it with the GeoIp databases from the package
geoip-database. This results in a nasty error message written to stdout:

Invalid database type GeoIP Country Edition, expected GeoIP City Edition, Rev 1

It comes from libgeoip:

https://github.com/maxmind/geoip-api-c/blob/master/libGeoIP/GeoIPCity.c#L190

This breaks Git over SSH:

$ git push
fatal: protocol error: bad line length character: Inva

This seems to be a known issue but geoip-api-c is in maintainance mode
and superseded by libmaxminddb.

https://github.com/maxmind/geoip-api-c/issues/67

There is a port of pam-geoip to the libmaxminddb API which should be a
drop-in-replacement:

https://github.com/amishmm/pam_geoip

Would you consider switching to this new port which uses a library that does not
write arbitrary messages to stdout?


Kind regards,
Michael

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

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

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl5n9rYRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WpwVggAubfX+2PZ32BniqmET52VZc/3gduDiNic
2xAvXgi22sBbIeYtG83MPi4Z5xmus7S1E8Df2DVBlkD4RFI0LANqpWQkqNB/X23X
Hj9dJXqTLLdfeg6oZgcHnmz1eW4BZdIKJDguFWQw8QZzZajwq9I+is2Hllktzbbi
0FWMWu8kUvx/Cj4ZoHjqZ091UaU/VfyReQUPnALC1Vh4lr2UnRjuWiCzR2ILwpPN
orPQnEIvZL3i+PZVzwupOkZSDKIr4myNi1GIMJ+lrb5qlnq/915qSgncKUyFAFyy
hbwtuLEWliYzo8WGwtaWWes4ZoU6QP9t3DdsT7dREtY/MMgsZXR8MA==
=GRTW
-END PGP SIGNATURE-

Bug#953576: dovecot: flaky arm64 autopkgtest: debian/tests/usage/00_setup exited with return code 75

[Paul Gevers]

Source: dovecot
Version: 1:2.3.7.2-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

With a recent upload of gcc-10 to unstable, the autopkgtest of dovecot
failed on arm64 in testing when that autopkgtest was run with the binary
packages of gcc-10 from unstable. Because of that, I looked into the
history of your autopkgtest and it fails very often on arm64.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests. Please either fix the test to be more robust, or use the
"flaky" restriction for the offending test until a solution has been found.

I copied the output at the bottom of this report. All the failing tests
that I inspected look like it.

I'll have the migration software ignore the results of your autopkgtest
on arm64 until this bug is fixed.

Paul

https://ci.debian.net/data/autopkgtest/testing/arm64/d/dovecot/4516937/log.gz

autopkgtest [10:26:26]: test command1: run-parts --report
--exit-on-error debian/tests/usage
autopkgtest [10:26:26]: test command1: [---
debian/tests/usage/00_setup:
Setting up dovecot for the test
Restarting the service
Sending a test message via the LDA
run-parts: debian/tests/usage/00_setup exited with return code 75
autopkgtest [10:26:30]: test command1: ---]



signature.asc
Description: OpenPGP digital signature

Bug#896463: autopkgtest-build-lxc times out waiting for network-online.target

[Paul Gevers]

Hi all,

On 06-03-2020 12:35, wf...@niif.hu wrote:
> On Mon, 2 Jul 2018 12:10:34 +0200 Paul Gevers  wrote:
>>> Maybe an alternate solution could be designed by installing a systemd
>>> service in the guest to run the setup-testbed and customize scripts
>>> without requiring these lxc-attach commands.  Just an idea, I'll be
>>> happy with any fix you prefer.
>>
>> I think this isn't a great solution either, as that means we depend on
>> systemd in the guest. I don't think we should (yet?).
> 
> Hi Paul,
> 
> What about forgetting about network-online.target and similar hacks
> (https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
> doesn't think about it highly) altogether, and instead configuring
> apt-get for a dozen or so retries (that seems to be the first command in
> setup-testbed requiring network access).  The build process is rather
> noisy already, so this could be a simple init-system-agnostic solution.

I think we are seeing this quite a bit ourselves now in the arm64
workers. E.g.

https://ci.debian.net/data/autopkgtest/testing/arm64/r/ros-ros-comm/4516943/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/r/ros-ros-comm/4519579/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/r/ros-ros-comm/4518550/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/d/dovecot/4475046/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/d/dovecot/4033240/log.gz

Paul



signature.asc
Description: OpenPGP digital signature

Bug#953527: [apt] colour highlighted error/warn labels

[Julian Andres Klode]

Control: severity -1 wishlist
Control: tag -1 confirmed

On Tue, Mar 10, 2020 at 06:13:28AM +, jnq...@gmail.com wrote:
> Package: src:apt
> Version: 2.0.0
> 
> Please add red/yellow colour highlighting to the 'E'/'W' prefixex
> respectively output for errors/warnings respectively. (UX improvement).
> 
> This would not only benefit direct use of apt binaries, but also be
> beneficial when used in scripting, such as with live-build where a
> warnign could be hidden in the middle of a great deal more output that
> with direct use.

How does the attached look? Bold red for error, bold yellow for
warning and yellow for notice; matching dpkg.

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

Bug#953575: dgit infrastructure issue (possible resource exhaustion)

[peter green]

Package: dgit

Hi.

I just ran into the following error:

['dgit', 'import-dsc', 
'/build/workingrepo/pool/main/g/gtk+3.0/gtk+3.0_3.24.14-1.dsc', 
'+workingbranch']
Dgit metadata in .dsc: specified git info (debian)
dgit: import-dsc of .dsc with Dgit field, using git hash
.dsc names distro debian: fetching rewrite map
.dsc names distro debian: fetching additional commits
remote: fatal: unable to create thread: Resource temporarily unavailable
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header
dgit: failed command: git fetch -p -n -q 'https://git.dgit.debian.org/gtk+3.0' 
'+refs/tags/archive/debian/3.24.14-1:refs/dgit-fetch/debian/tags/archive/debian/3.24.14-1'

dgit: error: subprocess failed with error exit status 128

I presume this is some sort of resource exhaustion on the dgit server. I tried to work 
around by pre-fetching needed commits from elsewhere, trying to specify a maximum depth 
and trying to specify explicit negotiation tips (which resulted in "warning: 
Ignoring --negotiation-tip because the protocol does not support it.") but none of 
these things helped.

Bug#953574: ITP: python-pysol-cards -- Deal PySol FC Cards

[Juhani Numminen]

Package: wnpp
Severity: wishlist
Owner: Juhani Numminen 

* Package name: python-pysol-cards
  Version : 0.8.8
  Upstream Author : Shlomi Fish 
* URL : https://github.com/shlomif/pysol_cards
* License : Expat
  Programming Lang: Python
  Description : Deal PySol FC Cards

Long Description:
 The pysol-cards python modules allow the python developer to generate the
 initial deals of some PySol FC games. It also supports PySol legacy deals
 and Microsoft FreeCell / Freecell Pro deals.


This package is a new dependency for recent releases of pysolfc (2.8.0) and
freecell-solver (5.20.0).

Bug#951679: [gedit] sh syntax highlighting bug

[jnqnfe]

control: fixed 3.36.0-1

I no longer experience this with gedit 3.36

I reported it upstream earlier ([1]), which I've left open in case they
want to still address the bug in gtksourceview 3.24, but no longer
affects me as gedit 3.36 uses gtksourceview v4 which does not suffer
from it (and has nicer highlighting on top).

[1]: https://gitlab.gnome.org/GNOME/gedit/issues/274

Bug#953573: file-roller: Error when starting file-roller

[Simon McVittie]

On Tue, 10 Mar 2020 at 21:27:57 +0200, Andoru wrote:
> > $ file-roller
> > file-roller: symbol lookup error: file-roller: undefined symbol:
> > archive_write_add_filter_zstd

That symbol should be available since libarchive 3.3.3.

Do you have a non-system copy of libarchive.so.13, perhaps in /usr/local,
that file-roller is finding instead of the system copy?

smcv

Bug#953542: Cross-Check with arch linux version

[Lukas F. Hartmann]

So I downloaded a similar build, 73.0-1 for Arch Linux arm64 and replaced
/usr/lib/firefox on my Debian sid installation with the respective
contents of that build. And it works. So my guess is that it's something
with the Debian build.

The build I tried is "firefox-73.0-1-aarch64.pkg.tar.xz" from
http://tardis.tiny-vps.com/aarm/packages/f/firefox/

Bug#953551: apt: trouble with "singular" packages from experimental

[Julian Andres Klode]

On Tue, Mar 10, 2020 at 02:43:25PM +0100, Laurent Bonnaud wrote:
> Package: apt
> Version: 2.0.0
> Severity: normal
> 
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> Those packages are installed on my system:
> 
> ii  libsingular4m1:amd64
> 1:4.1.1-p2+ds-4+b1
>  amd64Computer Algebra System for 
> Polynomial Computations -- library package
> ii  singular
> 1:4.1.2-p1+ds-2+b1
>  amd64Computer Algebra System for 
> Polynomial Computations
> ii  singular-data   
> 1:4.1.1-p2+ds-4   
>  all  Computer Algebra System for 
> Polynomial Computations -- shared data
> ii  singular-doc
> 1:4.1.2-p1+ds-2   
>  all  Computer Algebra System for 
> Polynomial Computations -- user documentation
> ii  singular-modules:amd64  
> 1:4.1.1-p2+ds-4+b1
>  amd64Computer Algebra System for 
> Polynomial Computations -- module package
> ii  singular-ui 
> 1:4.1.1-p2+ds-4+b1
>  amd64Computer Algebra System for 
> Polynomial Computations -- console user interface
> 
> and I am trying to update packages that are in experimental.
> 
>* What was the outcome of this action?
> 
> # apt -t experimental upgrade

Don't do this. Upgrading the distro to experimental is not supported, and likely
does not work. If you want packages from experimental, only upgrade/install the 
packages
you actually want, by using apt install.


> [...]
> The following packages have unmet dependencies:
>  libsingular4m1 : Breaks: libsingular
> E: Broken packages
> 
>* What outcome did you expect instead?
> 
> At least a list of packages that cannot be updated because of dependencies 
> problems (this is expected in experimental).  apt-get does it nicely:
> 
> # apt-get -t experimental upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> The following packages have been kept back:
>   chef-zero default-jdk default-jdk-doc default-jdk-headless default-jre 
> default-jre-headless
> [...]
> 
> And apt should also upgrade packages that require additional dependencies 
> (which apt-get does not upgrade). 

apt-get upgrade only upgrades existing packages, apt upgrade also installs
new one. Hence apt-get upgrade has a much higher chance of working.

PS. Thanks to your aggressive DMARC policy, your bug report did not
reach any actual people. It made it to the bug tracker, but not from
there to the mailing lists. Only saw it because of a BTS IRC notification
bot. Please don't send emails with a quarantine or reject policy, they
do not work - BTS needs to rewrite messages, and then messages get forwarded
from BTS to lists, to debian.org, and after that to the user's configured
address (in my case a forwarder again).

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

Bug#953573: file-roller: Error when starting file-roller

[Andoru]

Package: file-roller
Version: 3.36.0-1

For a week now I've been unable to start file-roller. There have been a few
upgrades in the last few days, but this error persists.
Here's what I get when I start file-roller from the terminal:

> $ file-roller
> file-roller: symbol lookup error: file-roller: undefined symbol:
> archive_write_add_filter_zstd

This error seems to be related to libarchive, but I wasn't sure if I should
report this against it, or file-roller.


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

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

Versions of packages file-roller depends on:
ii  bzip21.0.8-2
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-2
ii  libarchive13 3.4.0-2
ii  libc62.29-10
ii  libcairo21.16.0-4
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-3
ii  libglib2.0-0 2.62.5-1
ii  libgtk-3-0   3.24.14-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libnautilus-extension1a  3.34.1-1
ii  libnotify4   0.7.9-1
ii  libpango-1.0-0   1.42.4-8
ii  p7zip-full   16.02+dfsg-7

Versions of packages file-roller recommends:
ii  gvfs  1.44.0-1
ii  yelp  3.34.0-1

Versions of packages file-roller suggests:
ii  arj  3.10.22-23
pn  lha  
pn  lzip 
ii  lzop 1.04-1
pn  ncompress
pn  rpm2cpio 
ii  rzip 2.1-4.1
pn  sharutils
pn  squashfs-tools   
ii  unace1.2b-18
ii  unalz0.65-7
pn  unar 
ii  unzip6.0-25
ii  xz-utils [lzma]  5.2.4-1+b1
ii  zip  3.0-11+b1
ii  zoo  2.10-28

-- no debconf information

Bug#953571: src:nspr: please package recent version 4.25

[Carsten Schoenert]

Package: src:nspr
Severity: wishlist

Hello Mike,

could you please consider to package the most recent version 4.25 of NSPR?

I'm working on the current beta versions for Thunderbird and this is
requiring the most recent version of NSPR.

Regards
Carsten

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#953572: ditaa: should depend on default-jre-headless (not default-jre or default-jdk)

[Jonas Smedegaard]

Package: ditaa
Version: 0.10+ds1-1.2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- From the long description, ditaa seems to not be tied to development nor X11.

Please check if possible for this package to depend on default-jre-headless
and not default-jre or default-jdk.

I want to use plantuml without as little baggage as possible.
Today https://bugs.debian.org/927340 was fixed but at the same time
plantuml grew a dependency on ditaa making the situation even worse,
so that plantuml now requires 242MB development packages instead of
the expected release of X11-related packages.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl5n58cACgkQLHwxRsGg
ASGplRAAimnlaeqD69477tK8FA/aRJ5cATLv6sPA3MrUkYj5LOWZqP6jPyP9h0bV
oJWk8IFM5vgQPO0jZN+rtnTInN0I248IS56REAS1IHN4hDLCP+PXnz3SEFSpK0n3
MA7nSvugX/HCf2mYdf71dugNsUT1/qbSDbe0HCUeaHlJzlfwo4HhmBJojxFAxkja
J9WZzLUmucOA09scASgyXcNvQvnEi8HZu75kJK3nuwmXWB+UZmW3vLx5OzbsB5pu
m7vTfNIYr0VpkTsji/Y+xnEH++6VWzZu2U9BEp3zsHUFyP9k6wCOXdCL/FPAD1mA
Y5aymRxGDFhecyRoJViL5eib5+5ecD1J3cNDWH/nDUeaRN+Ndom+b6YgPW9bLckH
1R6Bur8NDh4XwO44ZciCdvBXMVml9Pz4faMpGZMi8T1KmGoXq0o+QRGnJbGUjp6u
YcVQddwJjNR3uInDPHbUlO/X7nd1sbmCZ4+zUmHP2P2fM09ZAnt4gZoUjZVA6pEG
HTdeuauDLJviceuzk9CPcuY8uMmJ5elB3eiWaJw2Qq03ozdKVsPrUK+aPYdqrgdc
uBiJEjLb+VVGWC0Htn7BnWP7ZIqCWeKhbP4xw2z6u2D/K+ue8d2dx45p106G18qW
5wr4EcAI8aa0GheLSOrp5EdClrvoAPFg4gEAcdC5NR+JXOgwEWs=
=Ppqk
-END PGP SIGNATURE-

Bug#953570: gnupg2: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: gnupg2
Version: 2.2.19-3
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The gnupg2 tests currently fail in this environment, because they declare a
test dependency on diffutils, which forces the testbed to try to remove the
essential diffutils package in favor of the foreign-arch diffutils:i386, and
apt rightly objects.

Because diffutils is essential, I think a test dependency doesn't need to be
declared, so I have uploaded the attached patch to Ubuntu to fix this test
failure.  However, if you think the diffutils test dependency is necessary,
I would suggest declaring this as diffutils:native instead.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gnupg2-2.2.19/debian/tests/control gnupg2-2.2.19/debian/tests/control
--- gnupg2-2.2.19/debian/tests/control  2020-02-27 13:27:37.0 -0800
+++ gnupg2-2.2.19/debian/tests/control  2020-03-10 02:59:47.0 -0700
@@ -7,5 +7,5 @@
 Restrictions: allow-stderr
 
 Tests: migration
-Depends: gpg, gnupg1, gnupg-utils, debian-archive-keyring, diffutils
+Depends: gpg, gnupg1, gnupg-utils, debian-archive-keyring
 Restrictions: allow-stderr

Bug#952359: strophejs: FTBFS: Error: ERROR: module path does not exist: /usr/lib/nodejs/almond/almond.js for module named: /usr/lib/nodejs/almond/almond.js. Path is relative to: /<>

[Sunil Mohan Adapa]

tag 952359 + patch
thanks

On Sun, 23 Feb 2020 14:58:00 +0100 Lucas Nussbaum  wrote:
> Source: strophejs
> Version: 1.2.14+dfsg-4
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> >  debian/rules build
> > dh build
> >dh_update_autotools_config
> >dh_auto_configure
> >debian/rules override_dh_auto_build
> > make[1]: Entering directory '/<>'
> > node /usr/lib/nodejs/requirejs/r.js -o build.js 
> > name=/usr/lib/nodejs/almond/almond.js insertRequire=strophe-polyfill 
> > include=strophe-polyfill out=strophe.min.js
> > Error: Error: ERROR: module path does not exist: 
> > /usr/lib/nodejs/almond/almond.js for module named: 
> > /usr/lib/nodejs/almond/almond.js. Path is relative to: /<>
> > at /usr/lib/nodejs/requirejs/r.js:28446:35
> > 
> > make[1]: *** [debian/rules:17: override_dh_auto_build] Error 1
> 
> The full build log is available from:
>http://qa-logs.debian.net/2020/02/22/strophejs_1.2.14+dfsg-4_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
> 
> 

The problem seem that node-almond no longer installs itself in /usr/lib
but is now available in /usr/share. The attached patch updates the patch
and makes the package build-depend on the version node-almond that made
the switch. With the patch, the build was successful again.

Please apply the patch and make a new release to prevent libjs-jsxc
(used by FreedomBox) from getting removed from testing.

Thanks,

-- 
Sunil
From f7efcae2cddb5f62b81093fece5496fa1298 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Tue, 10 Mar 2020 20:27:40 +0200
Subject: [PATCH] d/control,rules: Fix path for almond and depend on newer
 version

Signed-off-by: Sunil Mohan Adapa 
---
 debian/control | 2 +-
 debian/rules   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 419b60b..7f3e818 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: Debian XMPP Maintainers 
 Uploaders: Marcelo Jorge Vieira 
 Build-Depends: debhelper (>= 9.0.0),
-   node-almond,
+   node-almond (>= 0.3.3+dfsg-3),
node-uglify,
node-requirejs,
 Standards-Version: 4.1.3
diff --git a/debian/rules b/debian/rules
index 0a1b858..63747b3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 RJS ?= /usr/lib/nodejs/requirejs/r.js
-ALMOND ?= /usr/lib/nodejs/almond/almond.js
+ALMOND ?= /usr/share/nodejs/almond/almond.js
 
 STROPHE=strophe.js
 STROPHE_MIN=strophe.min.js
-- 
2.25.1



signature.asc
Description: OpenPGP digital signature

Bug#953522: reassign 953522 to firmware-realtek

[Sven Joachim]

Control: tags -1 + fixed-upstream

On 2020-03-10 18:10 +, Ben Hutchings wrote:

> reassign 953522 firmware-realtek
> thanks

For the record, the file has been added to firmware-linux.git in
September[1].  I think upgrading firmware-nonfree to 20200122 would be
rather useful.

Cheers,
   Sven


1. 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/rtl_nic/rtl8125a-3.fw?h=20200122=f667c005600bd4fe24a0a439b7a3f3eadcce753a

Bug#953558: binNMU: zita-dc1_0.3.3-1

[Dennis Braun]

summary 953559 nmu zita-dc1_0.3.3-1 . amd64 . unstable . -m "Rebuild on buildd"

@Sebastian sorry, i misunderstood.



signature.asc
Description: OpenPGP digital signature

Bug#953559: nmu: zita-dpl1_0.3.3-1

[Dennis Braun]

summary 953559 nmu zita-dpl1_0.3.3-1 . amd64 . unstable . -m "Rebuild on buildd"



signature.asc
Description: OpenPGP digital signature

Bug#925162: NMU uploaded to delayed/10

[Matthew Vernon]

Hi,

I've made an NMU with this change in, in the delayed/10 queue. I hope 
that's OK!


I made the NMU with dgit; I attach the patch I used, and the automatic 
quilt-fettling that dgit did for me.


Regards,

Matthew
>From 27699de4cc2e047cc3c396a3d42024788fd65654 Mon Sep 17 00:00:00 2001
From: Matthew Vernon 
Date: Wed, 20 Mar 2019 15:37:46 +
Subject: [PATCH 1/2] add -L option to output day and month name in list view

---
 bdengine.c   | 16 
 birthday.c   |  5 -
 birthday.h   |  1 +
 birthday.man |  4 
 debian/changelog |  7 +++
 5 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/bdengine.c b/bdengine.c
index 7985843..1e53bfb 100644
--- a/bdengine.c
+++ b/bdengine.c
@@ -63,6 +63,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef UNIX
 #include 
@@ -83,6 +84,7 @@ struct event *dir_include(char *dir, char *parm, const struct date *today);
 int iDWarn   = DEF_WARN;
 int iMaxWarn = MAX_WARN;
 int iMinWarn = MIN_WARN;
+int iPrintDate = 0;
 
 const unsigned MLENDAT[]={31,-1,31,30,31,30,31,31,30,31,30,31};
 
@@ -252,6 +254,7 @@ void liststrings(struct event *evl, prnfunc outf, const struct date *today) {
int i,j;
char *buf, *tmp;
int size;
+   struct tm *tmptime;

for (i = 0; evl[i].text != NULL; i++) {
   buf = xmalloc(128);
@@ -266,6 +269,19 @@ void liststrings(struct event *evl, prnfunc outf, const struct date *today) {
 append(buf, " ");
 tmp = tdelta(&(evl[i].date), today);
 append(buf, tmp);
+	/* only print date if it's not today or tomorrow */
+	if ((iPrintDate > 0) && (delta([i].date, today) > 1)) {
+	  tmptime = (struct tm *)xmalloc(sizeof *tmptime);
+	  tmptime = (struct tm *)memset(tmptime,0,(sizeof *tmptime));
+	  tmptime->tm_mday = evl[i].date.day;
+	  /*struct tm tm_mon is [0-11], our month is [1-12]*/
+	  tmptime->tm_mon = evl[i].date.month - 1;
+	  if (strftime(tmp,128," (%e %B)",tmptime))
+		append(buf, tmp);
+	  else
+		fatal("strftime failed\n");
+	  free(tmptime);
+	}
 free(tmp);
  }
   } else {
diff --git a/birthday.c b/birthday.c
index 59daf07..717bdc7 100644
--- a/birthday.c
+++ b/birthday.c
@@ -61,7 +61,7 @@ int main(int argc, char *argv[])
   func = F_WARN;
   settoday(  );
 
-  while ((i = getopt (argc, argv, "wcf:W:M:m:l:p:d:i:T:")) != -1)
+  while ((i = getopt (argc, argv, "wcLf:W:M:m:l:p:d:i:T:")) != -1)
 switch (i)
   {
   case 'w':
@@ -85,6 +85,9 @@ int main(int argc, char *argv[])
   case 'l':
 	iCLines=atoi(optarg);
 	break;
+  case 'L':
+	iPrintDate = 1;
+	break;
   case 'p':
 	iCWeeks=atoi(optarg);
 	break;
diff --git a/birthday.h b/birthday.h
index 6df7e70..0106701 100644
--- a/birthday.h
+++ b/birthday.h
@@ -114,6 +114,7 @@ extern struct date today;
 extern int iDWarn;
 extern int iMaxWarn;
 extern int iMinWarn;
+extern int iPrintDate;
 
 extern int iCLines;
 extern int iCWidth;
diff --git a/birthday.man b/birthday.man
index f0f0f6f..2fcde03 100644
--- a/birthday.man
+++ b/birthday.man
@@ -18,6 +18,7 @@ birthday \- warn about upcoming birthdays and other events
 .IR total ]
 .RB [ -i
 .IR width ]
+.RB [ -L ]
 
 .SH DESCRIPTION
 The 
@@ -70,6 +71,9 @@ days in advance. This overrides any flag given in the file.
 Warn at least
 .I min
 days in advance. This overrides any flag given in the file.
+.TP
+.B -L
+Also output the day and name of month after the number of days hence.
 
 .SS Calendar Options
 
diff --git a/debian/changelog b/debian/changelog
index 56d7c73..0f95785 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+birthday (1.6.2-4.1) unstable; urgency=low
+
+  * NMU
+  * Add a -L option to output day and month name in list view
+
+ -- Matthew Vernon   Tue, 10 Mar 2020 17:38:37 +
+
 birthday (1.6.2-4) unstable; urgency=low
 
   * New maintainer (Closes: 673226).
-- 
2.11.0

>From 3c190702a621c8cd05c015a6d0bc98598afa2ea3 Mon Sep 17 00:00:00 2001
From: Matthew Vernon 
Date: Tue, 10 Mar 2020 17:40:38 +
Subject: [PATCH 2/2] Commit Debian 3.0 (quilt) metadata

[dgit (8.5~bpo9+1) quilt-fixup]
---
 .../add--l-option-to-output-day-and-month-na.patch | 105 +
 debian/patches/series  |   1 +
 2 files changed, 106 insertions(+)
 create mode 100644 debian/patches/add--l-option-to-output-day-and-month-na.patch

diff --git a/debian/patches/add--l-option-to-output-day-and-month-na.patch b/debian/patches/add--l-option-to-output-day-and-month-na.patch
new file mode 100644
index 000..ac14c0b
--- /dev/null
+++ b/debian/patches/add--l-option-to-output-day-and-month-na.patch
@@ -0,0 +1,105 @@
+From: Matthew Vernon 
+Date: Wed, 20 Mar 2019 15:37:46 +
+X-Dgit-Generated: 1.6.2-4.1 27699de4cc2e047cc3c396a3d42024788fd65654
+Subject: add -L option to output day and month name in list view
+
+
+---
+
+--- birthday-1.6.2.orig/bdengine.c
 birthday-1.6.2/bdengine.c
+@@ -63,6 +63,7 @@
+ #include 
+ 

Bug#549233: docbook-to-man: Does not accept (some) (unicode) characters)

[Agustin Martin]

On Thu, Feb 27, 2020 at 03:48:44PM +0100, Agustin Martin wrote:
> 
> I recently tried to play with linuxdoc and utf-8 documents and run into the
> same problem,
> 
> onsgmls: ... 01.precmdout:1559:71:E: non SGML character number 141
> 
> This time I was lucky and a web search pointed me to
> https://bugzilla.redhat.com/show_bug.cgi?id=66179. After that suggestion, 
> 
> SP_CHARSET_FIXED=yes SP_ENCODING=xml sgml2html FAQ-CervanTeX-utf8.sgml

Better, for utf-8

$ SP_CHARSET_FIXED=yes SP_ENCODING=utf-8 sgml2html FAQ-CervanTeX-utf8.sgml

-- 
Agustin

Bug#953569: linux: please cherry-pick wireguard patches from 5.6

[Daniel Kahn Gillmor]

Package: src:linux
Severity: wishlist
Control: affects -1 src:wireguard-linux-compat src:wireguard

Hi Debian kernel folks--

Please cherry-pick the wireguard patches from Linux's 5.6 development
branch into future debian builds of 5.5 (and 5.4?) builds of the Linux
kernel.

The Wireguard VPN mechanism is due to be released in upstream kernel
5.6.  Debian unstable and testing currently have all the tooling needed
to configure and control wireguard interfaces as long as the kernel
module is available.  In particular, systemd-networkd is capable of
configuring wireguard interfaces in some standard configurations, and
the "wireguard-tools" source package offers fine-grained control via
/usr/bin/wg and a "wg-quick@" systemd unit template.

The kernel module itself has been available for a few years now for
people with machines that can afford to compile source code via
wireguard-dkms, but the dkms fooptprint and failure modes make it more
heavyweight than just having the module available directly.

I was looking into how to simplify this, and part of it involved
packaging a kernel module, but i've been dissuaded by folks on the
#debian-kernel IRC channel from trying to keep such a thing in debian.

bwh suggested cherry-picking the wireguard patches into src:linux 5.5,
which would be great.

the wireguard metapackage currently has:

Depends: wireguard-dkms (>= 0.0.20200121-2) | wireguard-modules (>= 
0.0.20191219)

so it would be nice if you could add the following metadata to any
generated binary packages:

Provides: wireguard-modules (= 0.0.20200121-2)

(you can replace the version number with whatever version info is
present in the upstream series that you cherry-pick, of course)

I understand from some folks on #debian-kernel that they don't think
this sort of dependency resolution mechanism is good to do, but it
doesn't appear to hurt anything, and it should smooth out the default
use case, so it seems like a win to me.

Thanks for considering this,

  --dkg


signature.asc
Description: PGP signature

Bug#952970: mksh cannot handle non-BMP characters in \Uxxxxxxxx

[Thorsten Glaser]

severity 952970 wishlist
tags 952970 upstream
forwarded 952970 miros-mkshmirbsd.org
close 952970
thanks

>This isn’t a packaging bug, so I’ll probably close this, but we can
>discuss this upstream.

Closing as announced, but I’ve added it to the plans:
http://www.mirbsd.org/mksh.htm#plans

PS: Mails from Googlemail may not reach *@mirbsd.* addresses
(both me and the mailing list), or after a large delay only.
Use tg  debian.org if you need direct contact, or Launchpad,
or a different eMail provider.

Bug#675008: bash: should handle /etc/bashrc.d (or similar) for non-login interactive shell

[Laurent Bigonville]

Le 10/03/20 à 18:37, Laurent Bigonville a écrit :
The default experience for gnome-terminal users is not good as nothing 
is sourcing /etc/profile.d/vte-2.91.sh for non-login interactive 
shells, meaning that the CWD is not set properly when opening new 
windows or tabs.


Actually the inheritance of the cwd in gnome-terminal is working fine as 
we have a custom patch for it that we carry since 2015, I don't think 
that others have

Bug#675008: bash: should handle /etc/bashrc.d (or similar) for non-login interactive shell

[Laurent Bigonville]

Hello,

Would anything eventually be done for this?

The default experience for gnome-terminal users is not good as nothing 
is sourcing /etc/profile.d/vte-2.91.sh for non-login interactive shells, 
meaning that the CWD is not set properly when opening new windows or tabs.


Being able to source snippets is a desirable feature in any cases, other 
distributions have gone the way of using /etc/profile.d/ and some (27) 
packages are already shipping files there in debian.


So either debian/we come with something better (and preferably 
compatible with other distributions) or we also go the way of sourcing 
/etc/profile.d/ for non-login interactive shell.


Kind regards,

Laurent Bigonville

Bug#953564: RFS: pygresql/1:5.1.1-1 [QA] -- PostgreSQL module for Python3

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "pygresql"

 * Package name: pygresql
   Version : 1:5.1.1-1
   Upstream Author : PyGreSQL team  
 * URL : https://www.pygresql.org/index.html
 * License : PostgreSQL
 * Vcs : https://salsa.debian.org/debian/pygresql
   Section : python

It builds those binary packages:

  python3-pygresql - PostgreSQL module for Python3
  python-pygresql-doc - Python Pygresql (common documentation)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/pygresql

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/p/pygresql/pygresql_5.1.1-1.dsc

Changes since the last upload:

   * QA upload.
   * New upstream version 5.1.1
   * d/copyright
 - Update copyright year
 - Change source, development is now on GitHub
 - Removed obsolete entries, upstream cleaned up the docs folder
   * Use secure URI on homepage
   * Set upstream metadata fields: Bug-Database, Repository,
 Repository-Browse, Bug-Submit
   * Remove obsolete lintian-overrides
   * Remove deletion and substitution of jquery.js from d/rules

Regards,
Håvard

Bug#952951: botan: Replace PKCS11 headers provided by OASIS

[GCS]

On Tue, Mar 10, 2020 at 1:27 PM Jack Lloyd  wrote:
> On Mon, Mar 02, 2020 at 10:09:32PM -0700, Sean Whitton wrote:
> > > In short, OASIS Open is a DFSG compliant license or not?
> >
> > Thanks.  It looks like the license which does not permit modification
> > applies to the specification, so the specification is not DFSG-free.
> >
> > As for pkcs11.h, I can't see any statement that it is under any license
> > at all, never mind a DFSG-free license.
> >
> > So the bug severity would seem to be correct.
 Meanwhile I've found the official GitHub repository hosting the work
of PKCS 11 [1]. Its README.md [2] states: "Content in this repository
is intended to be part of the PKCS 11 TC's permanent record of
activity, visible and freely available for all to use, subject to
applicable OASIS policies, as presented in the repository LICENSE
file."
Its CONTRIBUTING.md [3] adds: "Subject to applicable licensing rules,
the repository content may be re-used freely, including the creation
and publication of derivative works."
In my reading this complies with DFSG. It's free to redistribute,
source code is available and allows publication of derived works. It
doesn't discriminate any persons, groups or fields of use. It doesn't
restrict other software even.
But of course, I would like to hear your opinion Sean and probably from Jack.

> I'm concerned though that the alternative of using the p11-kit headers seems
> much worse, because it is blindingly obvious that the p11-kit versions are a
> derivative of the OASIS headers. Unless somehow the developers happened to
> choose the same names, bitmasks, and struct layouts by chance? As it is we
> [Botan upstream] are not violating the OASIS license, but as far as I can tell
> p11-kit headers *are*, by removing OASIS copyright and license, and also
> violating the license, due to modifying the headers.
 I do confirm this. The OASIS work is separated to three files and
p11-kit is amended those to one file it seems. As such, their cryptoki
version numbers are the same as well [4][5]. Some typedefs definied an
other way, see CK_BYTE and CK_CHAR for example [6][7]: OASIS define
the former as 'unsigned char' and the latter as the same as the former
- while p11-kit defines these individually to 'unsigned char'. Please
note that _some_ (small number) of their constants are differ [8][9].

Regards,
Laszlo/GCS
[1] https://github.com/oasis-tcs/pkcs11
[2] https://github.com/oasis-tcs/pkcs11/blob/master/README.md
[3] https://github.com/oasis-tcs/pkcs11/blob/master/CONTRIBUTING.md
[4] 
https://github.com/oasis-tcs/pkcs11/blob/master/published/2-40-errata-1/pkcs11t.h#L20
[5] https://github.com/p11-glue/p11-kit/blob/master/common/pkcs11.h#L64
[6] 
https://github.com/oasis-tcs/pkcs11/blob/master/published/2-40-errata-1/pkcs11t.h#L37
[7] https://github.com/p11-glue/p11-kit/blob/master/common/pkcs11.h#L1552
[8] 
https://github.com/oasis-tcs/pkcs11/blob/master/published/2-40-errata-1/pkcs11t.h#L1151
[9] https://github.com/p11-glue/p11-kit/blob/master/common/pkcs11.h#L1529

Bug#953568: alsa-lib FTFS in testing.

[peter green]

Package: alsa-lib
Version: 1.2.2-2.1
Severity: serious
Tags: bullseye, patch

I just ran into the following build failure in raspbian bullseye, checking on 
reproducible builds confirmed that the failure is not raspbian specific.

http://buildd.raspbian.org/status/fetch.php?pkg=alsa-lib=armhf=1.2.2-2.1=1583817597
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/alsa-lib.html


/bin/bash ../../../libtool  --tag=CC   --mode=link gcc -I/usr/include/python3.7m 
-I/usr/include/python3.7m -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -module -avoid-version 
-Wl,-z,defs -Wl,-z,relro -Wl,-z,now -o smixer-python.la -rpath 
/usr/lib/arm-linux-gnueabihf/alsa-lib/smixer smixer_python_la-python.lo 
../../../src/libasound.la Usage: /usr/bin/python3-config 
--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--abiflags|--configdir
/bin/bash: --exec-prefix: command not found
/bin/bash: --includes: command not found
/bin/bash: --cflags: command not found
/bin/bash: --libs: command not found
/bin/bash: --extension-suffix: command not found
/bin/bash: --ldflags: command not found
/bin/bash: --help: command not found
/bin/bash: --configdir: command not found
/bin/bash: --abiflags: command not found
make[4]: *** [Makefile:474: smixer-python.la] Error 127

The python 3.8 patch is to blame and is breaking builds with 3.7 (still the 
default in testing). I whipped up the attached debdiff and was able to get 
successful builds in raspbian bullseye and debian sid armhf.

While I was working on this I also discovered the clean target was not cleaning 
up properly, so I fixed that too.

diff -Nru alsa-lib-1.2.2/debian/changelog alsa-lib-1.2.2/debian/changelog
--- alsa-lib-1.2.2/debian/changelog 2020-03-07 18:21:22.0 +
+++ alsa-lib-1.2.2/debian/changelog 2020-03-10 15:12:02.0 +
@@ -1,3 +1,10 @@
+alsa-lib (1.2.2-2.1+rpi1) bullseye-staging; urgency=medium
+
+  * Modify python 3.8 patch so builds with 3.7 still work.
+  * Fix clean target.
+
+ -- Peter Michael Green   Tue, 10 Mar 2020 15:12:02 
+
+
 alsa-lib (1.2.2-2.1) unstable; urgency=medium
 
   [ Matthias Klose ]
diff -Nru alsa-lib-1.2.2/debian/patches/python3.8.diff 
alsa-lib-1.2.2/debian/patches/python3.8.diff
--- alsa-lib-1.2.2/debian/patches/python3.8.diff2020-03-04 
08:23:20.0 +
+++ alsa-lib-1.2.2/debian/patches/python3.8.diff2020-03-10 
15:12:02.0 +
@@ -10,7 +10,7 @@
pythoninc0=
if test "$build_python2" != "yes"; then
 -pythonlibs0=$(python3-config --libs)
-+pythonlibs0=$(python3-config --libs --embed)
++pythonlibs0=$(python3-config --libs `python3 -c 'import sys;print("" if 
sys.version_info < (3,8) else "--embed")'`)
  pythoninc0=$(python3-config --includes)
fi
if test -z "$pythonlibs0"; then
diff -Nru alsa-lib-1.2.2/debian/rules alsa-lib-1.2.2/debian/rules
--- alsa-lib-1.2.2/debian/rules 2020-02-29 15:51:16.0 +
+++ alsa-lib-1.2.2/debian/rules 2020-03-10 15:12:02.0 +
@@ -38,3 +38,8 @@
 
 override_dh_makeshlibs:
dh_makeshlibs -- -c4
+
+override_dh_auto_clean:
+   rm -rf doc/doxygen
+   rm -f src/control/ctl_symbols_list.c src/control/libcontrol.la 
src/hwdep/libhwdep.la src/mixer/libmixer.la src/pcm/libpcm.la 
src/pcm/pcm_symbols_list.c src/rawmidi/librawmidi.la src/seq/libseq.la 
src/timer/libtimer.la src/ucm/libucm.la
+   dh_auto_clean