Bug#937260: [pcp] Bug#937260: Offering NMU

[Martin Pitt]

Hello Nathan,

Nathan Scott [2019-12-02 10:51 +1100]:
> Thanks!  I've updated the PCP deb builds in the upstream PCP repo and plan
> to close this issue out with the pcp-5.0.2 release (scheduled for Wed 11th).  
> If
> you need the fix sooner though, feel free to NMU.

Nice, thanks! That's soon enough for sure, pcp's autoremoval is currently
scheduled for Jan 1.

Martin

Bug#922246: www/lts: if DLA-1234-1 and DLA-1234-2 exist, only that last one shows up in indexes

[Brian May]

Brian May  writes:

> When I just tested it I found that the index contains entries for both
> files, however the DSA--2 entry is incorrectly titled as DSA- instead
> of DSA--2.

Actually it looks like this was deliberate.

The file template/debian/recent_list_security.wml has the function
get_dsa_data which contains the line:

$title =~ s/(D[LS]A-\d{2,})-\d{1}/$1/; # strip off the revision in the DSA 
number

I haven't tested it yet, but to me it looks like if I delete this line
it will do the right thing.

Is it OK if we simply delete this line?

Will double check this tomorrow.
-- 
Brian May 

Bug#945982: reverse-depends outputs to stderr

[Andrey Rahmatullin]

Package: ubuntu-dev-tools
Version: 0.175
Severity: normal

Since updating from 0.174 to 0.175 reverse-depends started printing the output
to stderr instead of stdout. I guess it's related to "Unify the logging using
the standard python logging module" and may be applicable to other tools too.



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

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

Versions of packages ubuntu-dev-tools depends on:
ii  binutils2.33.1-4
ii  dctrl-tools 2.24-3+b1
ii  devscripts  2.19.7
ii  diffstat1.63-1
ii  distro-info 0.22
ii  dpkg-dev1.19.7
ii  lsb-release 11.1.0
ii  perl5.30.0-9
ii  python3 3.7.5-3
ii  python3-apt 1.8.4+b1
ii  python3-debian  0.1.36
ii  python3-distro-info 0.22
ii  python3-httplib20.11.3-2
ii  python3-launchpadlib1.10.9-1
ii  python3-lazr.restfulclient  0.14.2-2
ii  python3-ubuntutools 0.175
ii  sensible-utils  0.0.12+nmu1
ii  sudo1.8.29-1

Versions of packages ubuntu-dev-tools recommends:
pn  bzr | brz
pn  bzr-builddeb | brz-debian
ii  ca-certificates  20190110
ii  cowbuilder   0.88
ii  debian-archive-keyring   2019.1
ii  debian-keyring   2019.09.24
ii  debootstrap  1.0.116
ii  dput-ng [dput]   1.28
ii  genisoimage  9:1.1.11-3+b2
ii  libwww-perl  6.43-1
ii  lintian  2.39.0
ii  patch2.7.6-6
ii  pbuilder 0.230.4
ii  python3-debianbts3.0.2
pn  python3-dns  
ii  quilt0.65-3
ii  reportbug7.5.3
ii  sbuild   0.78.1-2
pn  ubuntu-keyring | ubuntu-archive-keyring  

Versions of packages ubuntu-dev-tools suggests:
ii  qemu-user-static  1:4.1-2

-- no debconf information

Bug#922246: www/lts: if DLA-1234-1 and DLA-1234-2 exist, only that last one shows up in indexes

[Brian May]

On Sat, Feb 09, 2019 at 03:55:44AM +0100, Laura Arjona Reina wrote:
> * The /lts/security//index.*.html files show the last advisory for
> the cases where there are several files with the same beginning (e.g.
> for DSA- and DSA--2, both html files are generated, but the
> index only points to the -2 file). If this is not the intended
> behaviour, changes in index.wml and Makefiles are needed.

Hopefully I attributed this correctly. Apologise if I got it wrong.

When I just tested it I found that the index contains entries for both
files, however the DSA--2 entry is incorrectly titled as DSA- instead
of DSA--2.
-- 
Brian May 

Bug#945795: [signing-party] gpg-key2ps prints ed25519 key as eddsa256 key

[Guilhem Moulin]

Control: severity -1 minor
Control: retitle -1 gpg-key2ps should list curve names for ECC keys rather than 
$ALGO$LENGTH

Hi,

On Thu, 28 Nov 2019 at 21:59:18 +0200, Mikaela Suomalainen wrote:
> my key is printed as eddsa256/BAE30723, while I believe it should be
> ed25519 as reported by `gpg --list-keys`.

Lowered the severity as there is AFAICT no promise that the output
format matches the one from `gpg --list-keys`.  Showing $ALGO$LENGTH for
ECC keys, like what's done for RSA, DSA and ElGalmal keys isn't wrong,
even though showing the curve name would be more precise.  I don't
really speak PostScript so I'm unlikely to change that myself; patch
welcome :-)  See also https://bugs.debian.org/869398 .

In the meantime one can use gpg-key2latex(1) from the same package,
which doesn't have this issue, at the expense of heavier dependencies
(the TexLive suite).

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#405762: Actualizați-vă contul de e-mail

[Intranet UTCN]

-- 
Stimate abonat,

Cele cinci mail-uri de intrare tocmai au fost plasate pe starea
pendinte datorită actualizării recente a bazei noastre de date, Pentru
a primi mesajele Conectați-vă pentru a vă autentifica și așteptați
răspunsurile de la utcluj.ro, ne cerem scuze pentru orice inconvenient
și apreciem înțelegerea dvs.

Iată linkul de utilizat .. https://user-parola-uitat-a-student-nou.weebly.com/


Cu stimă,

Administratorul site-ului
Universitatea Tehnica din Cluj-Napoca

Bug#945506: openafs-modules-dkms: module FTBFS for Linux 5.3.0-2-amd64

[Benjamin Kaduk]

Hi Andreas,

On Tue, Nov 26, 2019 at 02:38:21AM +0100, Andreas Beckmann wrote:
> Package: openafs-modules-dkms
> Version: 1.8.5-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> openafs-modules-dkms/sid fails to build the kernel module for the
> current kernel (5.3.0-2-amd64) in a minimal sid chroot with
> linux-headers-amd64 installed:
> 
>   Setting up openafs-modules-dkms (1.8.5-1) ...
>   Loading new openafs-1.8.5 DKMS files...
>   It is likely that 5.2.14 belongs to a chroot's host
>   Building for 5.3.0-2-amd64
>   Building initial module for 5.3.0-2-amd64
>   Error! Bad return status for module build on kernel: 5.3.0-2-amd64 (x86_64)
>   Consult /var/lib/dkms/openafs/1.8.5/build/make.log for more information.
>   dpkg: error processing package openafs-modules-dkms (--configure):
>installed openafs-modules-dkms package post-installation script subprocess 
> returned error exit status 10
>   Processing triggers for libc-bin (2.29-3) ...
>   Errors were encountered while processing:
>openafs-modules-dkms
> 
> make.log contains:
> 
> DKMS make.log for openafs-1.8.5 for kernel 5.3.0-2-amd64 (x86_64)
> Fri Nov 15 21:42:48 UTC 2019
> checking for gcc... no
> checking for cc... no
> checking for cl.exe... no
> configure: error: in `/var/lib/dkms/openafs/1.8.5/build':
> configure: error: no acceptable C compiler found in $PATH
> See `config.log' for more details
> 
> So the sources are looking for "gcc" while they should get the correct
> compiler to use from the kernel headers ... the module must be built
> with the same compiler version as the kernel itself, which is not
> neccessarily the system default "gcc", and for Debian it's always a
> versioned gcc-N. (The linux-headers- packages transitively
> depend on the correct versioned gcc package.)

I think I need some help to figure out the best thing to do here.
For background, openafs is portable to a wide variety of OSes including
Linux, Solaris, several BSDs, macOS, and AIX, and uses a kernel module to
provide the network filesystem client functionality.  The configure script
does of course conditionalize its checks based on detected OS, but with my
upstream hat on I'm pretty skeptical of encoding any distro-specific checks
that would involve querying the dpkg database.

(I'm also not sure I properly understand the need to use the exact same
compiler as the base kernel -- is the calling convention ABI really going
to change regularly?  But feel free to treat that as an aside, as it's not
unreasonable to expect)

So, are you just saying that configure should be looking for various gcc-N
while searching for a compiler, or are you saying that the debian packaging
needs to be chasing the dpkg database for the kernel in question to find
the appropriate compiler, and hardcoding that as the CC argument to
configure?  (This is of course more exciting since the actual kernel module
build for openafs-modules-dkms does not occur at package build time, and
the package also produces a package with module sources for non-dkms
builds.)

Your insight would be greatly appreciated.

Thanks,

Ben

Bug#944815: RFS: ledmon/0.93-2 -- Enclosure LED Utilities

[Hsieh-Tseng Shen]

Package: sponsorship-requests
Followup-For: Bug #944815

Dear Maintainer,

I've uploaded 0.93-2 revision for fixing build failure, please review
ledmon again. Thanks,

Upstream already had related commit about address-of-packed-member, but
it seems to remove -Werror directly. Following up this will be next
release if 0.93-2 can be merged first.

BRs,
Woodrow


signature.asc
Description: PGP signature

Bug#807245: myrepos: --jobs m should override jobs=m config option

[Paul Wise]

Control: tags -1 + fixed-upstream
Control: forwarded -1 
http://source.myrepos.branchable.com/?p=source.git;a=commitdiff;h=6a1df1a

On Fri, 15 Sep 2017 11:56:50 -0300 David Bremner wrote:

> myrepos: --jobs m should override jobs=m config option

This now implemented in git.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#937552: [Python-modules-team] Bug#937552: re: pysvn: Python2 removal in sid/bullseye

[peter green]

I'm deleting this from deferred for now, until reverse-dependencies are kicked 
out from testing or fixedT


The current pysvn is already rc buggy thanks to the removal of python-cxx-dev. 
If not fixed this will cause pysvn and all it's rdeps to be kicked out of 
testing. So IMO it makes more sense to go ahead with the upload (which will 
allow pysvn and svn-load to stay in testing, while svn-workbench is kicked out) 
than it does to leave things in their present state (which will cause pysvn, 
svn-load and svn-workbench to all get kicked out*).

* rabbitvcs has already been kicked out of testing, rope is only a recommends, 
so won't be affected by any automatic removals triggered by pysvn.

Bug#937458: html5-parser: Python2 removal in sid/bullseye

[peter green]

Severity 937458 serious
Thanks

pyicu build-depends on the python-pkgconfig binary package which is no longer 
built by the python-pkgconfig source package and is no longer in testing or 
unstable.

Bug#937293: piuparts: Python2 removal in sid/bullseye

[peter green]

severity 937293 serious
thanks

piuparts build-depends on the python-mox3 binary package, which is no longer 
built by the python-mox3 source package and is no longer present in testing or 
unstable.

Bug#945981: pathspider build-depends on cruft package.

[peter green]

Package: pathspider
Version: 2.0.1-2
Severity: serious

Pathspider build-depends on pylint3, which is no longer built by the pylint source 
package. Please consider changing your build-dependency to pylint (>= 2.2.2-2). 
I have not done a test build in this case, because your package already has a 
FTBFS bug.

Bug#710477:

[Chris Denley]

Putting a simple test script together, I found my problem. The client_ip
method doesn't work on Apache2::Connection objects unless the
Apache2::Connection module is loaded in the current namespace.

package test;
use strict;
use warnings;
use Apache2::RequestRec ();
use Apache2::Const -compile => 'OK';

sub handler {
   my $r = shift;
   $r->content_type('text/plain');
   my $ref = ref($r);
   print "ref(\$r) = $ref\n";
   my $conn = $r->connection;
   $ref = ref($conn);
   print "ref(\$conn) = $ref\n";
   for(1..2) {
  if($_==2) {
 print "require Apache2::Connection\n";
 require Apache2::Connection;
  }
  if($conn->can('client_ip')) {
 print "client_ip: ".$conn->client_ip."\n";
  }
  else {
 print "\$conn cannot client_ip\n";
  }
  if($conn->can('remote_ip')) {
 print "remote_ip: ".$conn->remote_ip."\n";
  }
  else {
 print "\$conn cannot remote_ip\n";
  }
   }
   return Apache2::Const::OK;
}
1;

ref($r) = Apache2::RequestRec
ref($conn) = Apache2::Connection
$conn cannot client_ip
$conn cannot remote_ip
require Apache2::Connection
client_ip: 127.0.0.1
$conn cannot remote_ip


On Thu, 28 Nov 2019 22:44:26 +0200 Damyan Ivanov  wrote:
> -=| Chris Denley, 28.11.2019 08:02:52 -0600 |=-
> > client_ip and remote_ip do not work. Is there no way to get this value
anymore?
> >
> > Can't locate object method "remote_ip" via package "Apache2::Connection"
> > Can't locate object method "client_ip" via package "Apache2::Connection"
> > Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 mod_apreq2-20090110/2.8.0
mod_perl/2.0.10
> > Perl/v5.26.1
>
> the following works for me:
>
> my $conn = $r->connection;
>
> my $ip_addr
> = $conn->can('client_ip')
> ? $conn->client_ip
> : $conn->remote_ip;
>
> so one of them works, and I bet it is 'client_ip'
>
> (Debian/sid and Debian/buster (and several releases before that))
>
> Can you share the code that fails for you?
>
> -- Damyan
>
>

Bug#945980: obfs4proxy, build-depends on package that is no longer in testing.

[peter green]

Package: obfs4proxy
Version: 0.0.7-4
Severity: serious
Tags: bullseye, sid

obfs4proxy build-depends on golang-go.net-dev which has been dropped by the 
golang-golang-x-net-dev source package. It is still present in unstable as a 
cruft package but is completely gone from testing.

Please update your build-dependency to golang-golang-x-net-dev

Bug#945911: APT leaks repository credentials

[Florian Zumbiehl]

Hi,

> [ lots of blah blah ]

.o()

> > > > > > - The redirect could point to an HTTP URI to expose the credentials 
> > > > > > as
> > > > > >   plain text on the wire, even where the sources.list entries for 
> > > > > > the
> > > > > >   respective server point only to HTTPS URIs to protect from 
> > > > > > eavesdroppers.
> > > > > 
> > > > > HTTPS->HTTP redirects are not allowed.
> > > > 
> > > > Well, that's good, I suppose? But it's also irrelevant for this attack
> > > > scenario?!
> > > 
> > > You didn't explain well, so Julian misunderstood you. I think you where
> > > trying to say that http://foo.example.org is made to redirect to
> > > http://bar.example.org which would sent the auth for bar.example.org
> > > over the wire unencrypted (and so could be observed by a MITM) even if
> > > you usually access via https://bar.example.org (note the s).
> > 
> > That doesn't require MitM, but other than that, yes.
> 
> 1) Yes, they do require MitM

No, they don't.

>(1) MITM on the DNS to hihack requests to bar to your own server

Nothing of the sort.

>(2) MITM on the Network routing to directly read requests

1. Reading requests does not require MitM.

2. Nothing of that sort either.

> On further thought, I'd like to add a "proto" field to auth.conf,
> defaulting to https, tor+https, so we can look at that, and only
> send credentials over encrypted connections. Or should we parse the
> protocol out of the machine field? idk. (specifying port 443 would
> not help as much, as you could do http over 443).

Well, that's certainly not a bad idea, and would even stop many of the
possible attacks, but it's not a full solution to the problem.

> This prevents us from sending credentials to men in the middle,
> and should hence address all of your concerns.

No, it wouldn't, plus still no MitM.

> The security implications of this are minimal, and the change is
> not suitable for backporting to older releases.

Well, I obviously disagree, at least on the former.

> I just have to say it was hard to figure out what the problem is,
> with your sidelines to redirects, and your saying there is no mitm
> involved, when the bug report basically comes down to "people can
> mitm http connections, and you'd send credentials over them". A more
> focused and thought out bug report would have been useful.

Erm, wut? You simply invent that it's a MitM problem, when it's not, that
it's not about redirects, when it is, and then complain that I am not
explaining clearly that it is about MitM and not about redirects!?

The second sentence of my original bug report was:

| Unfortunately, the way these credentials are handled causes a confused
| deputy style problem:

That is the core problem, and redirects are the mechanism that enables
this, because redirects are how an attacking server (or potentially a MitM,
of course) can instruct APT to issue an HTTP request to a URI of its
choosing, using credentials that are not meant to be used by that server,
thus acting as a confused deputy.

I really don't see how I could have been any more focused than that.

The following you sent to (me and) 945...@bugs.debian.orgg, which I suppose
was a typo, so I am quoting it here:

> On Sun, Dec 01, 2019 at 09:35:46PM +0100, Julian Andres Klode wrote:
> [...]
> > 1) Yes, they do require MitM
> > 
> >(1) MITM on the DNS to hihack requests to bar to your own server
> >(2) MITM on the Network routing to directly read requests
> > 
> > 2) In practice, credentials are combined with HTTPS. We do not allow
> >HTTP to HTTPS redirects, hence you need to actually have certificates
> >for _both_ foo and bar.
> 
> I'm sorry, this was of course wrong, e.g. if you use http:/deb.debian.org/
> and https://internal.example/, the former can send to APT
> 
> Location: http://internal.example/ (possibly with a :443 port)
> 
> and apt would happily send the credentials in plain text. Fixing apt to
> send credentials only over https unless configured otherwise (per auth.conf
> entry) would fix it :-)

That would be the second example scenario that I listed in my original bug
report, yes, and defaulting to sending credentials over HTTPS only would
indeed fix that scenario.

However, it certainly would not fix the third scenario, and it would also
not fix the first scenario in the case where people do explicitly configure
credentials for HTTP, such as for internal servers that are accessed
through a trusted network where eavesdropping is not a concern.

Ultimately, to solve a confused deputy problem, you have to allow the user
to specify who is allowed to use a given set of credentials, which in this
case in particular means which server is allowed to "use" a given set of
credentials (by issuing a redirect), and the default policy should allow
only credentials to be used that match the entry in the sources.list that
is being processed.

Regards, Florian

Bug#936710: html5-parser: Python2 removal in sid/bullseye

[peter green]

Severity 936710 serious
Thanks

html5-parser build-depends on the python-pkgconfig binary package which is no 
longer built by the python-pkgconfig source package. It is still present in 
unstable as a cruft package, but is completely gone from testing.

Bug#711135: Deadline Extension: CLOUD COMPUTING 2020 || April 26 - 30, 2020 - Nice, France

[CLOUD COMPUTING 2020]

INVITATION:

=

Please consider to contribute to and/or forward to the appropriate groups the 
following opportunity to submit and publish original scientific results to:

- CLOUD COMPUTING 2020, The Eleventh International Conference on Cloud 
Computing, GRIDs, and Virtualization

The submission deadline has been extended to December 30, 2019

Authors of selected papers will be invited to submit extended article versions 
to one of the IARIA Journals: http://www.iariajournals.org

=


== CLOUD COMPUTING 2020 | Call for Papers ===

CALL FOR PAPERS, TUTORIALS, PANELS


CLOUD COMPUTING 2020, The Eleventh International Conference on Cloud Computing, 
GRIDs, and Virtualization

General page: http://www.iaria.org/conferences2020/CLOUDCOMPUTING20.html

Submission page: 
http://www.iaria.org/conferences2020/SubmitCLOUDCOMPUTING20.html


Event schedule: April 26 - 30, 2020 - Nice, France


Contributions:

- regular papers [in the proceedings, digital library]

- short papers (work in progress) [in the proceedings, digital library]

- ideas: two pages [in the proceedings, digital library]

- extended abstracts: two pages [in the proceedings, digital library]

- posters: two pages [in the proceedings, digital library]

- posters:  slide only [slide-deck posted at www.iaria.org]

- presentations: slide only [slide-deck posted at www.iaria.org]

- demos: two pages [posted at www.iaria.org]

- doctoral forum submissions: [in the proceedings, digital library]


Proposals for:

- mini symposia: see http://www.iaria.org/symposium.html

- workshops: see http://www.iaria.org/workshop.html

- tutorials:  [slide-deck posed on www.iaria.org]

- panels: [slide-deck posed on www.iaria.org]


Submission deadline: December 30, 2019


Sponsored by IARIA, www.iaria.org

Extended versions of selected papers will be published in IARIA Journals:  
http://www.iariajournals.org

Print proceedings will be available via Curran Associates, Inc.: 
http://www.proceedings.com/9769.html

Articles will be archived in the free access ThinkMind Digital Library: 
http://www.thinkmind.org


The topics suggested by the conference can be discussed in term of concepts, 
state of the art, research, standards, implementations, running experiments, 
applications, and industrial case studies. Authors are invited to submit 
complete unpublished papers, which are not under review in any other conference 
or journal in the following, but not limited to, topic areas.

All tracks are open to both research and industry contributions, in terms of 
Regular papers, Posters, Work in progress, Technical/marketing/business 
presentations, Demos, Tutorials, and Panels.

Before submission, please check and comply with the editorial rules: 
http://www.iaria.org/editorialrules.html


CLOUD COMPUTING 2020 Topics (for topics and submission details: see CfP on the 
site)

Call for Papers: http://www.iaria.org/conferences2020/CfPCLOUDCOMPUTING20.html



TRENDS: New trends

Fog-computing; Mobile Edge Computing; Cloudlets; Hosted Cloud services (WebRTC, 
Containers, Cloud micro-services); Cloud computing and SDN/NFV; Cloud computing 
and 5G; Cloud computing and LTE Pro 4.5; Cloud computing ad Big Data; High 
performance computing (HPC) in the Cloud; Superfluid Clouds; Mobile Apps to the 
public Clouds; Vehicular Cloud networks; Cloud orchestration features; 
Converged edge systems; Cloud federation; Micro-cloud provider federation; 
Open-implementation Cloud infrastructures; Untrusted Cloud environments; 
Multiple Clouds and data centers; Power Constrained VMs; Cloud Green 
abstraction layer

CLOUD: Cloud computing

Cloud economics; Core cloud services; Cloud technologies; Cloud computing; 
On-demand computing models; Hardware-as-a-service; Software-as-a-service [SaaS 
applications]; Platform-as-service; Storage as a service in cloud; 
Data-as-a-Service; Service-oriented architecture (SOA); Cloud computing 
programming and application development; Scalability, discovery of services and 
data in Cloud computing infrastructures; Trust and clouds; Client-cloud 
computing challenges; Geographical constraints for deploying clouds

CLOUD: Challenging features

Privacy, security, ownership and reliability issues; Performance and QoS; 
Dynamic resource provisioning; Power-efficiency and Cloud computing; Load 
balancing; Application streaming; Cloud SLAs; Business models and pricing 
policies; Cloud service subscription models; Cloud standardized SLA; 
Cloud-related privacy; Cloud-related control; Managing applications in the 
clouds; Mobile clouds; Roaming services in Clouds; Agent-based cloud computing; 
Cloud brokering; Cloud contracts (machine readable); Cloud security; Security 
and assurance properties in cloud environments; Big Data Analytics in clouds; 
Cloud computing back-end solutions; Cloud applications portability; 
Cloud-native application design; Security by

Bug#945979: zhpy: Please consider removing the package

[Boyuan Yang]

Source: zhpy
Version: 1.7.3.1-1.1
Severity: important
X-Debbugs-CC: dreamerwolf...@gmail.com

Dear zhpy maintainer,

It looks like the zhpy upstream is dead and that your package is currently
affected by python2 removal in Debian. As a result, I think we should have
your package removed from Debian.

Please let me know if you have any thoughts on this package in Debian.
Otherwise I will submit a removal bug to Debian FTP Masters in 21 days (by
2019-12-21).

Please feel free to let me know if you have any questions.

-- 
Best Regards,
Boyuan Yang


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

Bug#945978: src:requests: FTBFS against python-urllib3 1.25 and newer

[jrnieder]

Source: requests
Version: 2.21.0-1
Tags: upstream

debian/control in the requests package contains

 Build-Depends:
  python-chardet (>= 3.0.2), python-chardet (<< 3.1.0),
  python-urllib3 (>= 1.21.1), python-urllib3 (<< 1.25),
  python3-chardet (>= 3.0.2), python3-chardet (<< 3.1.0),
  python3-urllib3 (>= 1.21.1), python3-urllib3 (<< 1.25),

This prevents running test builds against newer versions of these
libraries.

Are the newer versions known to break the package?  Are there bugs or
other information available to help with upgrading?  (I checked for a
README.source with this kind of information but wasn't able to find it.)

Upstream bumped its declared maximum version of urllib3 in
https://github.com/psf/requests/commit/aeda65bbe57ac5edbcc2d80db85d010befb7d419.
Do we know why upstream supplies these upper bounds on versions of
dependent packages to build against?  Using < instead of != in
dependencies makes it harder to find a set of package versions that
works well together.

Thanks,
Jonathan

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

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

Bug#945976: octave-dicom: fails to find GDCM on many architectures.

[peter green]

Package: octave-dicom
Version: 0.2.2-4
Severity: serious

octave-dicom failed to build on armel, armhf, i386 and mips64el. It seems the 
problem was a failure to find gdcm.


checking for GDCM... CMake Error: Problem processing arguments. Aborting.

CMake Error: Problem processing arguments. Aborting.

no
configure: WARNING: No GDCM detected using cmake - trying fallback detection
checking for gdcm headers path... not found
configure: error: Unable to find GDCM headers


This does not seem like it was a transient or random issue as the successes and 
failures on the reproducible builds site were consistent with those in Debian.

Bug#945977: displaycal: apparent missing dependency on dbuslaunch

[Marc Lehmann]

Package: displaycal
Version: 3.7.1.4-1
Severity: normal

Dear Maintainer,

After installing displaycal, starting it gave me the following backtrace and a 
crash.

Installing dbus-x11 fixed this, so I guess displaycal (or a component it
uses that requires it) should depend on this.

XDG: [Errno 2] No translation file found for domain: xdg-user-dirs
displaycal 3.8.8.1 2019-11-07T21:22:40.565184Z
debian 10.2  x86_64
Python 2.7.16 (default, Oct 10 2019, 22:02:15) 
[GCC 8.3.0]
ImportError: No module named faulthandler
wxPython 3.0.2.0 gtk3 (classic)
Encoding: UTF-8
File system encoding: UTF-8
┌──┐
│ Traceback (most recent call last):   │
│   File "/usr/lib/python2.7/dist-packages/DisplayCAL/main.py", line 353, in   │
│ main │
│ _main(module, name, applockfilename) │
│   File "/usr/lib/python2.7/dist-packages/DisplayCAL/main.py", line 283, in   │
│ _main│
│ from wxwindows import BaseApp│
│   File "/usr/lib/python2.7/dist-packages/DisplayCAL/wxwindows.py", line 26,  │
│ in   │
│ import ICCProfile as ICCP│
│   File "/usr/lib/python2.7/dist-packages/DisplayCAL/ICCProfile.py", line 37, │
│ in   │
│ import colord│
│   File "/usr/lib/python2.7/dist-packages/DisplayCAL/colord.py", line 27, in  │
│  │
│ from util_dbus import DBusObject, DBusException, BUSTYPE_SYSTEM  │
│   File "/usr/lib/python2.7/dist-packages/DisplayCAL/util_dbus.py", line 21,  │
│ in   │
│ dbus_session = Gio.bus_get_sync(Gio.BusType.SESSION, None)   │
│ Error: g-exec-error-quark: Failed to execute child process “dbus-launch” (No │
│ such file or directory) (8)  │
└──┘
Exiting displaycal
Ran application exit handlers

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

Kernel: Linux 5.2.21-050221-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.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 displaycal depends on:
ii  argyll   2.0.1+repack-1
ii  libc62.28-10
ii  libjs-jquery 3.3.1~dfsg-3
ii  libx11-6 2:1.6.7-1
ii  libxinerama1 2:1.1.4-2
ii  libxrandr2   2:1.5.1-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  python   2.7.16-1
ii  python-numpy 1:1.16.2-1
ii  python-wxgtk3.0  3.0.2.0+dfsg-8

Versions of packages displaycal recommends:
ii  colord1.4.3-4
ii  gir1.2-colordgtk-1.0  0.1.26-2

displaycal suggests no packages.

-- no debconf information

Bug#945975: nmu libgnatcoll_18-4 libgnatcoll-bindings_18-2.1 libgnatcoll-db_18-4 asis_2018-2 libaws_19.0-2

[Nicolas Boulenguez]

With the attachment.


gpr-graph.pdf
Description: Adobe PDF document

Bug#945943: exim4: FTBFS on hurd-i386: "operating system GNU is not supported"

[Samuel Thibault]

Control: forwarded -1 https://bugs.exim.org/show_bug.cgi?id=2476

I have forwarded the request to upstream.

Samuel

Bug#945943: exim4: FTBFS on hurd-i386: "operating system GNU is not supported"

[Samuel Thibault]

Samuel Thibault, le lun. 02 déc. 2019 01:36:32 +0100, a ecrit:
> The attached patch is also required, otherwise exim4 will consider using
> fastopen, but not actually do it, thus completely failing to connect.
> I'll submit upstream once I get my account there confirmed.

This is now on 

https://bugs.exim.org/show_bug.cgi?id=2475

Samuel

Bug#945943: exim4: FTBFS on hurd-i386: "operating system GNU is not supported"

[Samuel Thibault]

Hello,

Paul Sonnenschein, le dim. 01 déc. 2019 13:56:26 +0100, a ecrit:
> > *** Sorry - operating system GNU is not supported
> > *** See OS/Makefile-* for supported systems
> 
> See [1] for the complete build log.
> 
> It however builds successfully if the files OS/unsupported/*-GNU are
> moved into the directory OS/.
> 
> Could you take a look?

The attached patch is also required, otherwise exim4 will consider using
fastopen, but not actually do it, thus completely failing to connect.
I'll submit upstream once I get my account there confirmed.

Samuel
Index: exim4-4.93~RC5/src/ip.c
===
--- exim4-4.93~RC5.orig/src/ip.c
+++ exim4-4.93~RC5/src/ip.c
@@ -292,8 +292,7 @@ if (fastopen_blob && f.tcp_fastopen_ok)
   debug_printf("Tried TCP Fast Open but apparently not enabled by 
sysctl\n");
 goto legacy_connect;
 }
-# endif
-# ifdef EXIM_TFO_CONNECTX
+# elif defined(EXIM_TFO_CONNECTX)
   /* MacOS */
   sa_endpoints_t ends = {
 .sae_srcif = 0, .sae_srcaddr = NULL, .sae_srcaddrlen = 0,
@@ -326,12 +325,14 @@ if (fastopen_blob && f.tcp_fastopen_ok)
 else   /* assume that no data was queued; block in send */
   rc = send(sock, fastopen_blob->data, fastopen_blob->len, 0);
 }
+# else
+goto legacy_connect;
 # endif
   }
 else
 #endif /*TCP_FASTOPEN*/
   {
-#if defined(TCP_FASTOPEN) && defined(MSG_FASTOPEN)
+#if defined(TCP_FASTOPEN) && (defined(MSG_FASTOPEN) || 
!defined(EXIM_TFO_CONNECTX))
 legacy_connect:
 #endif
 

Bug#945975: nmu libgnatcoll_18-4 libgnatcoll-bindings_18-2.1 libgnatcoll-db_18-4 asis_2018-2 libaws_19.0-2

[Nicolas Boulenguez]

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

Hello.

As reported in #945197, the grpc and gprbuild source packages both
build libgpr.so. In order to fix the conflict, version 2018-7 of the
libgpr2-dev binary package renames libgpr.so to libgnatprj.so.

The reverse dependencies must be linked against the new library name.

No modification of the source should be required (the dependencies
read the changed -l option from a .gpr file updated by libgr2-dev),
but I think that some NMUs are required in order to create new
versions and enforce the order of the builds.  The attached graph
describes what I want to acheive.

The proper fix, far more intrusive, will rename the libgpr*.deb
packages accordingly, to libgnatprj*.deb. Reverse dependencies will
then require manual edition. I intend to debug this in experimental,
as part of the current (unrelated) transition.

dw dh-ada-library_6.15 libgnatcoll_18-4 . ANY . unstable . -m 
'libgpr2-dev (>= 2018-7)'
dw libgnatcoll-bindings_18-2.1 asis_2018-2  . ANY . unstable . -m 
'libgnatcoll17-dev (>= 18-4+b1)
dw libgnatcoll-db_18-4  . ANY . unstable . -m 
'libgnatcoll-iconv17-dev (>= 18-2.1+b1)
dw gnat-gps_18-5. ANY . unstable . -m 
'libgnatcoll-xref18-dev (>= 18-4+b1)'
dw adacontrol_1.21r3-3 adabrowse_4.0.3-10 libaws_19.0-2 . ANY . unstable . -m 
'libasis2018-dev (>= 2018-2+b1)
dw log4ada_1.3-5. ANY . unstable . -m 
'libaws18-dev (>= 19.0-2+b1)'
nmu libgnatcoll_18-4 libgnatcoll-bindings_18-2.1 libgnatcoll-db_18-4 
asis_2018-2 libaws_19.0-2 . ANY . unstable . -m 'Rebuild against renamed 
libgpr.so, see #945197.'

Thanks.

Bug#945974: For certain operations FF "recomposes" the screen and takes a long time

[Mauro Sacchetto]

Package: FontForge
Version: 1:20190801~dfsg-2 and others

I installed the last version available for Sid.
When I start a process as glyph simplification,
adding extremum an so on, for every glyphs FontForge
"recomposes" the screen every time as if browsed from top to bottom
and consequently takes a very long time to perform glyph operations.
I realize that my description is obscure, so I am attaching
the screen shot. With the correct functioning, the screen is fixed,
only the bar proceeds and consequently the process is very fast

https://www.dropbox.com/s/5mguq0h8vmo1wyp/20191201_232044.mp4?dl=0

Thank you
ms

Bug#937260: [pcp] Bug#937260: Offering NMU

[Nathan Scott]

Hi Martin,

On Mon, Dec 2, 2019 at 10:48 AM Martin Pitt via Groups.Io
 wrote:
>
> Hello,
>
> I just checked that python-pcp has zero reverse build and binary dependencies,
> so it's fine to just drop it and thus fix this RC bug. If you don't have time,
> I'm happy to do an NMU for this (as cockpit maintainer I don't want cockpit to
> get dropped from testing due to pcp disappearing).

Thanks!  I've updated the PCP deb builds in the upstream PCP repo and plan
to close this issue out with the pcp-5.0.2 release (scheduled for Wed 11th).  If
you need the fix sooner though, feel free to NMU.

cheers.

--
Nathan

Bug#945973: Please add symbols files for improved shlibs dependencies

[Michael Biebl]

Source: pcre2
Version: 10.34-1
Severity: wishlist
Tags: patch

Hi,

please consider applying the attached patch which adds symbols files for
the libraries shipped in src:pcre2

See man dpkg-gensymbols(1), man deb-symbols(5),
https://wiki.debian.org/Projects/ImprovedDpkgShlibdeps

Thanks for considering,
Michael

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 2732d94d8a79e0da34d0db53a2518f2b6542290e Mon Sep 17 00:00:00 2001
From: Michael Biebl 
Date: Mon, 2 Dec 2019 00:34:16 +0100
Subject: [PATCH] Add symbols files for impoved shlibs dependencies

See man dpkg-gensymbols(1), man deb-symbols(5),
https://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
---
 debian/libpcre2-16-0.symbols   | 74 ++
 debian/libpcre2-32-0.symbols   | 74 ++
 debian/libpcre2-8-0.symbols| 74 ++
 debian/libpcre2-posix0.symbols |  9 +
 4 files changed, 231 insertions(+)
 create mode 100644 debian/libpcre2-16-0.symbols
 create mode 100644 debian/libpcre2-32-0.symbols
 create mode 100644 debian/libpcre2-8-0.symbols
 create mode 100644 debian/libpcre2-posix0.symbols

diff --git a/debian/libpcre2-16-0.symbols b/debian/libpcre2-16-0.symbols
new file mode 100644
index 000..dad5aa4
--- /dev/null
+++ b/debian/libpcre2-16-0.symbols
@@ -0,0 +1,74 @@
+libpcre2-16.so.0 libpcre2-16-0 #MINVER#
+ pcre2_callout_enumerate_16@Base 10.34
+ pcre2_code_copy_16@Base 10.34
+ pcre2_code_copy_with_tables_16@Base 10.34
+ pcre2_code_free_16@Base 10.34
+ pcre2_compile_16@Base 10.34
+ pcre2_compile_context_copy_16@Base 10.34
+ pcre2_compile_context_create_16@Base 10.34
+ pcre2_compile_context_free_16@Base 10.34
+ pcre2_config_16@Base 10.34
+ pcre2_convert_context_copy_16@Base 10.34
+ pcre2_convert_context_create_16@Base 10.34
+ pcre2_convert_context_free_16@Base 10.34
+ pcre2_converted_pattern_free_16@Base 10.34
+ pcre2_dfa_match_16@Base 10.34
+ pcre2_general_context_copy_16@Base 10.34
+ pcre2_general_context_create_16@Base 10.34
+ pcre2_general_context_free_16@Base 10.34
+ pcre2_get_error_message_16@Base 10.34
+ pcre2_get_mark_16@Base 10.34
+ pcre2_get_match_data_size_16@Base 10.34
+ pcre2_get_ovector_count_16@Base 10.34
+ pcre2_get_ovector_pointer_16@Base 10.34
+ pcre2_get_startchar_16@Base 10.34
+ pcre2_jit_compile_16@Base 10.34
+ pcre2_jit_free_unused_memory_16@Base 10.34
+ pcre2_jit_match_16@Base 10.34
+ pcre2_jit_stack_assign_16@Base 10.34
+ pcre2_jit_stack_create_16@Base 10.34
+ pcre2_jit_stack_free_16@Base 10.34
+ pcre2_maketables_16@Base 10.34
+ pcre2_maketables_free_16@Base 10.34
+ pcre2_match_16@Base 10.34
+ pcre2_match_context_copy_16@Base 10.34
+ pcre2_match_context_create_16@Base 10.34
+ pcre2_match_context_free_16@Base 10.34
+ pcre2_match_data_create_16@Base 10.34
+ pcre2_match_data_create_from_pattern_16@Base 10.34
+ pcre2_match_data_free_16@Base 10.34
+ pcre2_pattern_convert_16@Base 10.34
+ pcre2_pattern_info_16@Base 10.34
+ pcre2_serialize_decode_16@Base 10.34
+ pcre2_serialize_encode_16@Base 10.34
+ pcre2_serialize_free_16@Base 10.34
+ pcre2_serialize_get_number_of_codes_16@Base 10.34
+ pcre2_set_bsr_16@Base 10.34
+ pcre2_set_callout_16@Base 10.34
+ pcre2_set_character_tables_16@Base 10.34
+ pcre2_set_compile_extra_options_16@Base 10.34
+ pcre2_set_compile_recursion_guard_16@Base 10.34
+ pcre2_set_depth_limit_16@Base 10.34
+ pcre2_set_glob_escape_16@Base 10.34
+ pcre2_set_glob_separator_16@Base 10.34
+ pcre2_set_heap_limit_16@Base 10.34
+ pcre2_set_match_limit_16@Base 10.34
+ pcre2_set_max_pattern_length_16@Base 10.34
+ pcre2_set_newline_16@Base 10.34
+ pcre2_set_offset_limit_16@Base 10.34
+ pcre2_set_parens_nest_limit_16@Base 10.34
+ pcre2_set_recursion_limit_16@Base 10.34
+ pcre2_set_recursion_memory_management_16@Base 10.34
+ pcre2_set_substitute_callout_16@Base 10.34
+ pcre2_substitute_16@Base 10.34
+ pcre2_substring_copy_byname_16@Base 10.34
+ pcre2_substring_copy_bynumber_16@Base 10.34
+ pcre2_substring_free_16@Base 10.34
+ pcre2_substring_get_byname_16@Base 10.34
+ pcre2_substring_get_bynumber_16@Base 10.34
+ pcre2_substring_length_byname_16@Base 10.34
+ pcre2_substring_length_bynumber_16@Base 10.34
+ pcre2_substring_list_free_16@Base 10.34
+ pcre2_substring_list_get_16@Base 10.34
+ pcre2_substring_nametable_scan_16@Base 10.34
+ pcre2_substring_number_from_name_16@Base 10.34
diff --git a/debian/libpcre2-32-0.symbols b/debian/libpcre2-32-0.symbols
new file mode 100644
index 000..83e2c98
--- /dev/null
+++ b/debian/libpcre2-32-0.symbols
@@ -0,0 +1,74 @@
+libpcre2-32.so.0 libpcre2-32-0 #MINVER#
+ pcre2_callout_enumerate_32@Base 10.34
+ pcre2_code_

Bug#932957: Re Bug 932957 Please migrate Release Notes to reStructuredText

[Andrei POPESCU]

On Du, 01 dec 19, 20:35:35, Paul Gevers wrote:
> Hi Andrei,
> 
> On Thu, 25 Jul 2019 22:44:29 +0900 Osamu Aoki  wrote:
> > Yes.  It can be done.  I just converted developers-reference and someone
> > merged it ti main ;-)
> > 
> > If you follow my commit history, all tools and tricks are there.
> > 
> > https://salsa.debian.org/debian/developers-reference
> > 
> > I will work on build script more to make web page looks better.  But
> > source conversion was possible though it is non-trivial.
> > 
> > > Ok, I'll have a look at it, though I wouldn't mind if someone is faster 
> > > ;)
> > 
> > https://salsa.debian.org/debian/developers-reference/blob/1b0940a5c2879a5be3100b0e0f2bee6c5de58bdf/README.rst
> > 
> > This describes general tasks involved.
> > 
> > If someone makes broken PO file by copying some msgstr from random
> > msgstr, then conversion doesn't work well and it may be cryptic to
> > debug.
> 
> Are you still upto doing this change? I'm not expecting you worked on
> this recently, but now is a good time to get this on the rails. Should
> we first branch bullseye (bug #932853), make the relatively small fixes
> there and then work on that branch or do you have a different proposal?

As mentioned before, this is something I would be interested to work on, 
assuming I find the time for it.

In any case, if someone else is interested please go for it.

Regarding branches, wouldn't it make more sense to create a buster 
branch and continue work on master? Just asking, I'm fine either way.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#945521: [ltsp] libfuse3 / sshfs v3 don't support nonempty option anymore

[Petter Reinholdtsen]

Control: forwarded -1 https://github.com/ltsp/ltsp/issues/99
Control: tags -1 upstream

Fixed upstream, lets add the link.
-- 
Happy hacking
Petter Reinholdtsen

Bug#941198: please postpone until after the GR

[Sean Whitton]

Hello,

On Sun 01 Dec 2019 at 09:33AM -08, Russ Allbery wrote:

> I don't think there's any urgent need to put out a new normative version
> of Policy and we could hold the next release until January.  What do you
> think, Sean?

I'd be happy with an informal hold on normative releases, but before we
commit to that, I'd like to hear Adam explain how he thinks the GR
interacts with the bug at all, because so far as I can tell they're
orthogonal.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#945972: FTBFS on armel: test-suite failure

[Michael Biebl]

Source: pcre2
Version: 10.34-1
Severity: serious

Hi,

pcre2 FTBFS on armel:
https://buildd.debian.org/status/fetch.php?pkg=pcre2&arch=armel&ver=10.34-1&stamp=1574962559&raw=0

FAIL: RunTest
=


PCRE2 C library tests using test data from ./testdata
PCRE2 version 10.34 2019-11-21

 Testing 8-bit library 

Test 0: Unchecked pcre2test argument tests (to improve coverage)
  OK
Test 1: Main non-UTF, non-UCP functionality (compatible with Perl >= 5.10)
  OK
Segmentation fault
** pcre2test failed - check testtry
FAIL RunTest (exit status: 1)


Testsuite summary for PCRE2 10.34

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

See ./test-suite.log



The missing armel build and the binary upload prevent pcre2 from
migrating to testing, blocking other packages.
If pcre2 used a symbols file instead of dh_makeshlibs -V, this would be
less of an issue, as it wouldn't block other packages from testing
migration.

Regards,
Michael


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

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

Bug#945971: pull latest upstream version

[David Mandelberg]

Package: xkb-data
Version: 2.26-2
Severity: wishlist

Hi,

The latest upstream release is currently 2.28. Could you update this 
package please?


Upstream releases: 
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/tags

Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory

[Dimitri John Ledkov]

I guess I should have created a list of breaks, and uploaded with it, as
indeed a soname is dropped.

On Sun, 1 Dec 2019, 23:36 Dimitri John Ledkov,  wrote:

> No,
>
> All packages that use python have removal blocks already filed, and those
> bugs should be marked as blocking migration of boost.
>
> It will take a while for boost to migrate. There are only a few
> applications, a few dual py2/py3 packages, and majority already scheduled
> to be removed from the archive with RC bugs.
>
> All the broken packages, are RC buggy themselves already. Anything that is
> using py2 is RC buggy.
>
> And e.g. ledger, I started porting it locally. The buggy app here is ledger

Bug#944389: lxc: Fails to work with cgroupv2 / unified hierarchy

[Ryutaroh Matsumoto]

Package: lxc
Version: 3.2.1+master~20191129-1942-0ubuntu1~disco
Tags: fixed-upstream
Followup-For: Bug #944389

Dear Maintainer,

On the github I was advised to add
lxc.cgroup.devices.allow =
lxc.cgroup.devices.deny =
lxc.mount.auto = proc:mixed sys:mixed cgroup:rw:force

to /var/lib/lxc/container/config, and with above lines lxc can
start Debian 10.2, on the lxc 3.2.1+master~20191129-1942-0ubuntu1~disco
from https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/daily
even on cgroup 2 enabled Debian.

But Debian package 3.1.0+really3.0.4-2 is still unable to start
a container on unified cgroup hierarchy.

I added the fixed-upstream tag. On github I was also suggested to add
lxc.cgroup.relative = 1
to obey the systemd guideline at

https://github.com/systemd/systemd/blob/master/docs/CGROUP_DELEGATION.md#some-donts

Best regards,
Ryutaroh

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

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

Versions of packages lxc depends on:
ii  lxc-utils  3.2.1+master~20191129-1942-0ubuntu1~disco

lxc recommends no packages.

lxc suggests no packages.

-- no debconf information

Bug#945796: [Pkg-rust-maintainers] Bug#945796: rust-url-serde: (build-)depends on obsolete virtual package.

[Paride Legovini]

control: block -1

Wolfgang Silbermayr wrote on 29/11/2019:
> On 11/28/19 9:04 PM, peter green wrote:
>> Package: rust-url-serde
>> Version: 0.2.0-1
>> Severity: serious
>> Tags: bullseye, sid
>>
>> librust-url-serde-dev depends on and rust-url-serde build-depends on
>> librust-url-1+default-dev which is no longer provided by rust-url. It
>> seems to have been replaced by librust-url-2+default-dev
> 
> The url_serde crate has been updated the last time to 0.2.0 on April 30,
> 2017. It lived in the servo rust-url repository, where it got removed on
> July 15, 2019. To me it seems to be obsolete. Nothing (build-)depends on
> it yet. I assume it got packaged as a dependency for something else, but
> either that something didn't get packaged yet, or it doesn't require
> this crate any more.
> 
> @paride can you please check and file a ROM if no longer needed?

I filed at ROM RM request: #945959 [1]. The bug report had a
X-Debbugs-CC to this bug (945...@bugs.debian.org), the Acknowledgement
email correctly mentions it, but for some reason nothing is showing up
here...

Paride

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

Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory

[Dimitri John Ledkov]

No,

All packages that use python have removal blocks already filed, and those
bugs should be marked as blocking migration of boost.

It will take a while for boost to migrate. There are only a few
applications, a few dual py2/py3 packages, and majority already scheduled
to be removed from the archive with RC bugs.

All the broken packages, are RC buggy themselves already. Anything that is
using py2 is RC buggy.

And e.g. ledger, I started porting it locally. The buggy app here is ledger.

On Sun, 1 Dec 2019, 18:57 Giovanni Mascellani,  wrote:

> Hi,
>
> On Fri, 29 Nov 2019 16:42:58 +0100 Kiko Piris
>  wrote:> /usr/bin/ledger: error while loading
> shared libraries: libboost_python27.so.1.67.0: cannot open shared object
> file: No such file or directory
>
> Dimitri, it seems that removing Python 2 support for Boost 1.67 was a
> bit too quick. Apparently some packages are still using it, so this is
> causing breakages. Therefore I will upload a new version that re-enables
> Python 2. Of course Python 2 should never be enabled from Boost 1.71 on.
>
> Also, could you please check that you pushed 1.67.0-15 to the git
> repository? I cannot see it.
>
> Of course, reverse dependencies of Boost 1.67 be aware that you will
> break when 1.71 will be made the default Boost version, which hopefully
> will be relatively soon.
>
> Giovanni.
> --
> Giovanni Mascellani 
> Postdoc researcher - Université Libre de Bruxelles
>
>

Bug#937735: "..security-debian.org couldn't be accessed"

[Holger Wansing]

Control: reassign -1 apt-setup

Re-assign to the relevant package.


Benjamin Aigner  wrote:
> I can confirm, had the same wrong links yesterday in the non-gui 
> installer of the Debian testing netinst iso
> 
> 
> You can fix this problem by changing the links to:
> 
> deb http://security.debian.org/debian-security bullseye-security main
> deb-src http://security.debian.org/debian-security bullseye-security main




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

Bug#945970: meep: Incomplete debian/copyright?

[Chris Lamb]

Source: meep
Version: 1.12.0-1
Severity: serious
Justication: Policy §12.5
X-Debbugs-CC: Thorsten Alteholz , 
ftpmas...@debian.org

Hi,

I just ACCEPTed meep from NEW but noticed it was missing attribution 
in debian/copyright for at least mt19937ar.c.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#405762: Actualizați-vă contul de e-mail

[Intranet UTCN]

--
Stimate abonat,

Cele cinci mail-uri de intrare tocmai au fost plasate pe starea pendinte 
datorită actualizării recente a bazei noastre de date, Pentru a primi 
mesajele Conectați-vă pentru a vă autentifica și așteptați răspunsurile 
de la utcluj.ro, ne cerem scuze pentru orice inconvenient și apreciem 
înțelegerea dvs.


Iată linkul de utilizat .. 
https://user-parola-uitat-a-student-nou.weebly.com/



Cu stimă,

Administratorul site-ului
Universitatea Tehnica din Cluj-Napoca

Bug#887875: libqt5webenginecore5: libQt5WebEngineCore.so.5.9.2 claims to need an executable stack

[Russell Coker]

On Monday, 2 December 2019 6:08:27 AM AEDT Dmitry Shachnev wrote:
> reassign 944971 libqt5webenginecore5
> merge 887875 944971
> fixed 887875 qtwebengine-opensource-src/5.12.4+dfsg-1
> thanks
> 
> Hi,
> 
> On Sun, Jan 21, 2018 at 10:10:57PM +1100, Russell Coker wrote:
> > $ execstack -q /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5.9.2
> > X /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5.9.2
> > 
> > The shared object is listed as requiring an executable stack.  This
> > weakens
> > the security of every application that uses it.
> 
> This was fixed upstream in [1], which was applied in Qt 5.12.4.
> So this bug is now fixed in testing.
> 
> Do you want a fix for Buster?

It would be nice to have so that the various schemes that change executable 
actions based on shared object flags could all be more restrictive and thus 
protect programs that use the library.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#936717: ibus-array: Python2 removal in sid/bullseye

[Changwoo Ryu]

Control: Tags -1 + patch

A suggested patch is attached.
diff --git a/debian/control b/debian/control
index 303a216..ba06f15 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ Build-Depends: autoconf (>= 2.5),
autopoint,
debhelper (>= 9),
dh-autoreconf,
+   dh-python,
libibus-1.0-dev,
libsqlite3-dev,
libtool (>= 2.2),
diff --git a/debian/rules b/debian/rules
index 28e31a5..1dddbcf 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,6 +8,6 @@ export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed,-ldl
 	dh $@ --with python3,autoreconf
 
 override_dh_auto_configure:
-	dh_auto_configure -- \
+	env PYTHON=/usr/bin/python3 dh_auto_configure -- \
 		--libexecdir=/usr/lib/ibus
 

Bug#936537: py2removal RC severity updates - 2019-11-30 23:36:59.882354+00:00

[Sandro Tosi]

On Sun, Dec 1, 2019 at 4:46 AM Paul Gevers  wrote:
>
> Control: severity -1 important
>
> Sandro,
>
> Please note, with my RT hat on. Don't raise again until the reverse
> build dependency has been fixed.

i hope you do realize this is an automation and not me manually
raising severity. I'll link you to the thread where this was
discussed.

>
> On Sat, 30 Nov 2019 18:36:59 -0500 Sandro Tosi  wrote:
> > # Part of the effort for the removal of python from bullseye
> > #  * https://wiki.debian.org/Python/2Removal
> > #  * http://sandrotosi.me/debian/py2removal/index.html
> > # See https://lists.debian.org/debian-devel-announce/2019/11/msg0.html
> > # for more details on this severity bump
> >
> > # fontcustom is an application and has low popcon (22 < 300)
> > severity 936537 serious
> That's an unfair argument. fontcustom is used to build a package that

please bring this to the attention of the thread i'll link you to soon.


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#945969: tinyeartrainer: Intent to remove from Debian

[Jeremy Bicha]

Source: tinyeartrainer
Version: 0.1.0-4
Severity: serious
Tags: bullseye sid

tinyeartrainer was recently removed from Testing as part of the
Python2 removals.

It looks to me like tinyeartrainer's last release was a decade ago and
that it is unlikely to be ported away from pygtk and Python 2.

Therefore, I or someone else will file a bug soon to request that
tinyeartrainer be removed from Debian Unstable.

This package can easily be added back to Debian if someone does port
it to use supported libraries.

Thanks,
Jeremy Bicha

Bug#945922: please move/copy systemd.pc out of the daemon package

[Laurent Bigonville]

On Sun, 01 Dec 2019 04:19:25 +0100 Adam Borowski 
wrote:

>
> Hi!
> The pkg-config file for systemd is in the daemon package, rather than
a -dev
> package as one would expect. This means that the maintainer of any package
> that uses this .pc has to either:
> * make it unbuildable without a chroot
> * drop systemd support
> * reinvent what .pc would provide
>
> In some cases the last option is reasonable but still hacky, like:
>
https://github.com/kilobyte/ndctl/commit/fce6efb8bf5f39b6a4de13b5961e56abba6bd4ef
> but it can get nastier when recursive dependencies are involved.
>
> Because of bin:systemd's special status, the usual ways of gracefully
moving
> a file would be obnoxious, I propose to, in one package, ship
systemd.pc in
> /usr/share/pkgconfig/, and in the other, in /usr/lib/$MULTIARCH/pkgconfig/
> -- pkg-config's path search makes it DTRT, and, with a hard versioned
> dependency, it can't possibly get out of sync.
>

I'm not sure what you mean by "special status" and why systemd.pc file
should be moved to an other package.

The bin:systemd package is not switching the initsystem of the machine
to systemd, that's systemd-sysv.

Bug#945968: ITP: haskell-search-algorithms -- Library for common graph search algorithms

[Kilian Kilger]

Package: wnpp
Severity: wishlist
Owner: Kilian Kilger 

* Package name: haskell-search-algorithms
  Version : 0.3.1
  Upstream Author : Devon Hollowood 
* URL : https://github.com/devonhollowood/search-algorithms 

* License : BSD-3-clause
  Programming Lang: Haskell
  Description : Library for common graph search algorithms

This is a Haskell library containing common graph search algorithms,
including depth-first and breadth-first searches,
Dijkstra's algorithm, and A*. 

I will need a sponsor to upload this package. Could be uploaded to
mentors and Salsa when I get my ITP number.

Bug#943337: linux-image-5.3.0-1-amd64: Keyboard driver for SPI connected MacBooks not included

[Scott Mcdermott]

yes please, this is required for macbook pro 2016 and 2017 and later
keyboard to work, I am using the out-of tree dkms for this now, which
is kind of silly to use since this is actually in the kernel 5.3
already

dkms version (presumably same code) works fine on my laptop with
debian vendor kernel 5.3.0-2 (ie 5.3.9-3)

please enable CONFIG_KEYBOARD_APPLESPI=m so we can get working
keyboard on our laptops out of the box, thanks

Bug#945967: libgstreamer-plugins-base1.0-dev: depends explicitly on mesa

[Josua Mayer]

Package: libgstreamer-plugins-base1.0-dev
Severity: wishlist

Dear Maintainer,

The gstreamer devel packages currently depend explicitly on mesa -dev packages, 
libgl1-mesa-dev, libegl1-mesa-dev, libgles2-mesa-dev in particular.

I suggest using the virtual packages libgl-dev for starters, which will make it 
a little easier to install custom providers of OpenGL cleanly.
If there were virtual packages for gles2 and egl, I would suggest switching 
those too, but so far there isn't ... :(

br
Josua Mayer

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.35-05162-gee5a4376dc84-dirty (SMP w/4 CPU cores; PREEMPT)
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)

Versions of packages libgstreamer-plugins-base1.0-dev depends on:
ii  gir1.2-gst-plugins-base-1.0  1.16.1-1
ii  imx-gpu-viv-dev [libgles2-mesa-dev]  6.4.0.p1.0
ii  libc6-dev [libc-dev] 2.29-3
pn  libegl1-mesa-dev 
pn  libgl1-mesa-dev  
ii  libglib2.0-dev   2.62.3-1
ii  libgstreamer-gl1.0-0 1.16.1-1
ii  libgstreamer-plugins-base1.0-0   1.16.1-1
ii  libgstreamer1.0-dev  1.16.1-1
ii  liborc-0.4-dev   1:0.4.31-1
ii  pkg-config   0.29-6

libgstreamer-plugins-base1.0-dev recommends no packages.

libgstreamer-plugins-base1.0-dev suggests no packages.

Bug#945911: APT leaks repository credentials

[Julian Andres Klode]

Control: reopen -1
Control: retitle -1 only send credentials over https by default
Control: severity -1 normal

On Sun, Dec 01, 2019 at 09:35:46PM +0100, Julian Andres Klode wrote:
> On Sun, Dec 01, 2019 at 08:36:05PM +0100, Florian Zumbiehl wrote:
> > Hi,
> > 
> [ lots of blah blah ]
> > 
> > > > > > - The redirect could point to an HTTP URI to expose the credentials 
> > > > > > as
> > > > > >   plain text on the wire, even where the sources.list entries for 
> > > > > > the
> > > > > >   respective server point only to HTTPS URIs to protect from 
> > > > > > eavesdroppers.
> > > > > 
> > > > > HTTPS->HTTP redirects are not allowed.
> > > > 
> > > > Well, that's good, I suppose? But it's also irrelevant for this attack
> > > > scenario?!
> > > 
> > > You didn't explain well, so Julian misunderstood you. I think you where
> > > trying to say that http://foo.example.org is made to redirect to
> > > http://bar.example.org which would sent the auth for bar.example.org
> > > over the wire unencrypted (and so could be observed by a MITM) even if
> > > you usually access via https://bar.example.org (note the s).
> > 
> > That doesn't require MitM, but other than that, yes.
> 
> 1) Yes, they do require MitM
> 
>(1) MITM on the DNS to hihack requests to bar to your own server
>(2) MITM on the Network routing to directly read requests
> 
> 2) In practice, credentials are combined with HTTPS. We do not allow
>HTTP to HTTPS redirects, hence you need to actually have certificates
>for _both_ foo and bar.
> 
> 3) If we have credentials for bar configured, we'll also usually have bar
>in sources.list, hence we will make equests to bar in any case, whether
>or not foo redirects to it.
> 
>Apart from some imaginable exceptions where people configure a central
>load balancer that sends redirects to internal repos and configure
>passwords for those end points; in which case, you know, the behavior
>is precisely what they want.
> 
> Since the rest of your email is basically the same message, I'll not
> quote it and repeat myself.
> 

On further thought, I'd like to add a "proto" field to auth.conf,
defaulting to https, tor+https, so we can look at that, and only
send credentials over encrypted connections. Or should we parse the
protocol out of the machine field? idk. (specifying port 443 would
not help as much, as you could do http over 443).

This prevents us from sending credentials to men in the middle,
and should hence address all of your concerns.

The security implications of this are minimal, and the change is
not suitable for backporting to older releases.

I just have to say it was hard to figure out what the problem is,
with your sidelines to redirects, and your saying there is no mitm
involved, when the bug report basically comes down to "people can
mitm http connections, and you'd send credentials over them". A more
focused and thought out bug report would have been useful.

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

Bug#945820: sysvinit_2.96-2_amd64.changes REJECTED

[Aurelien Jarno]

On 2019-12-01 15:41, Dmitry Bogatov wrote:
> 
> [2019-11-29 09:49] Aurelien Jarno 
> > On 2019-11-28 22:04, Debian FTP Masters wrote:
> > > sysvinit-core_2.96-2_amd64.deb: has 2 file(s) with a timestamp too far in 
> > > the past:
> > >   usr/share/doc/sysvinit-core/copyright (Thu Jan  1 00:00:01 1970)  
> > > usr/share/doc/sysvinit-c
> > ore/changelog.Debian.gz (Thu Jan  1 00:00:01 1970)
> 
> I do not understand what happened. I did source-only upload, so I
> believe .deb files are generated by buildd, not me.

Those files are copied from debian/copyright and debian/changelog in the
source sysvinit_2.96-2.debian.tar.xz. For an unknown reason all the
files in the tarball are dated from 1970-01-01.

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

Bug#945820: sysvinit_2.96-2_amd64.changes REJECTED

[Thorsten Glaser]

On Sun, 1 Dec 2019, Dmitry Bogatov wrote:

> I do not understand what happened. I did source-only upload, so I
> believe .deb files are generated by buildd, not me.

Maybe they kept the timestamp from the .debian.tar.gz?
I recently also had fails with my archive normaliser setting
things to the Unix epoch and tools failing to pick them up,
even if I’d expected that.

In case of doubt, touch everything under the debian/ directory
to the timestamp of the HEAD commit before building. Taken
from another project and untested but should work:

ts=$(TZ=UTC git show --no-patch --pretty=format:%ad \
--date=format-local:%Y%m%d%H%M.%S)
find debian/ -print0 | TZ=UTC xargs -0r touch -h -t "$ts" --

gl hf,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

Bug#937260: Offering NMU

[Martin Pitt]

Hello,

I just checked that python-pcp has zero reverse build and binary dependencies,
so it's fine to just drop it and thus fix this RC bug. If you don't have time,
I'm happy to do an NMU for this (as cockpit maintainer I don't want cockpit to
get dropped from testing due to pcp disappearing).

Thanks,

Martin

Bug#945820: sysvinit_2.96-2_amd64.changes REJECTED

[Dmitry Bogatov]

[2019-11-29 09:49] Aurelien Jarno 
> On 2019-11-28 22:04, Debian FTP Masters wrote:
> > sysvinit-core_2.96-2_amd64.deb: has 2 file(s) with a timestamp too far in 
> > the past:
> >   usr/share/doc/sysvinit-core/copyright (Thu Jan  1 00:00:01 1970)  
> > usr/share/doc/sysvinit-c
> ore/changelog.Debian.gz (Thu Jan  1 00:00:01 1970)

I do not understand what happened. I did source-only upload, so I
believe .deb files are generated by buildd, not me.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#799358: Angband 4.2.x is out and is Free

[Chris Carr]

I've been meaning to do this for five or six years, so definitely any 
year now!


Seriously, I might actually get round to it in 2020, life is getting a 
bit easier ...


On 28/11/2019 19:27, Matthew Vernon wrote:

Hi,

Any chance of a 4.2 package, please? It's quite a major rewrite of the 
game, and it's DFSG-free, so could move this into main, which would be 
really good :)


Thanks,

Matthew

Bug#945966: python3-formencode: missing Breaks+Replaces: python-formencode (<< 1.3.0-4)

[Andreas Beckmann]

Package: python3-formencode
Version: 1.3.0-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-formencode_1.3.0-4_all.deb ...
  Unpacking python3-formencode (1.3.0-4) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-formencode_1.3.0-4_all.deb (--unpack):
   trying to overwrite '/usr/share/locale/cs/LC_MESSAGES/FormEncode.mo', which 
is also in package python-formencode 1.3.0-3
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-formencode_1.3.0-4_all.deb


cheers,

Andreas


python-formencode=1.3.0-3_python3-formencode=1.3.0-4.log.gz
Description: application/gzip

Bug#900015: missing pkg-config support is blocking switch to mbedTLS in libgit2

[Christoph Berg]

Re: James Cowgill 2019-04-30 <403b111b-ff0a-62a2-71d1-150b3c01b...@debian.org>
> > fldigi 4.1.02's configure check probes for mbedtls >= 2.16 using 
> > pkg-config (and builds the embedded copy otherwise), so it seems
> > this has been implemented upstream in mbedtls by now. Can we have
> > it in Debian, please?
> 
> I cannot find any trace of pkg-config in upstream mbedtls git. The
> issue and (newer) merge request are still open:

Retrospectively, I seem to have misinterpreted the fldigi build
system. The macro they use adds pkg-config support, but also adds
switches to manually specify the mbedtls location, and that's what
users are supposed to used, afaict.

Christoph

Bug#883263: Bug#884824: etckeeper: daily autocommit is run even though AVOID_DAILY_AUTOCOMMITS=1

[Antoine Beaupré]

On 2019-11-21 11:33:21, Luca Capello wrote:
> forcemerge 884824 904924
> severity 884824 important
> tags 884824 patch
> block 883263 by 884824
> thanks
>
> Hi there,
>
> On Wed, 20 Dec 2017 14:30:42 +1100, Martin Schwenke wrote:
>> Following a suggestion, I found that if I run:
>> 
>>   systemctl stop etckeeper.timer
>
> The systemd timer was activated just before you filed your report:
>
>   
>
> And I got hit as well since 2 days, i.e. since I upgraded my **work**
> machine from stretch to buster.
>
>> Then it is no longer listed by "systemctl list-units".
>> 
>> I should have spent more time reading systemctl(1):
>
> Nope, this is a bug in the /etc/etckeeper/daily shell script, which
> does not respect /etc/etckeeper/etckeeper.conf, the patch is simple:

[...]

I'm confused about which patch is necessary here (and by the multiple
overlapping bug reports). Mind clarifying that for me?

Thanks,

A.

-- 
The desire to sacrifice an entire lifetime to the noblest of ideals
serves no purpose if one works alone.
- Che Guevara

Bug#945965: buster-pu: package bgpdump/1.6.0-1

[Christoph Biedl]

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

Hello release team,

the bgpdump package has an embarrasing bug, starting the program
results in an immediate segmentation fault, that's #945881

Luckily, a fix was fairly simple. For unstable, version 1.6.0-2 was
accepted an hour ago, for Debian 10 ("buster") I've prepared
1.6.0-1+deb10u1 to fix this via a point relase. Some extra tests
were done to make sure the program is now working as intended.

Assuming that change will be accepted I'll upload the new version in a
few moments.

Regards,

Christoph

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



signature.asc
Description: PGP signature

Bug#945964: ITS: python-espeak

[Samuel Thibault]

Source: python-espeak
Version: 0.5-1.1
Severity: important

Hello,

We haven't had any new from the maintainer sgevatter, and bug #942620
("src:python-espeak: Maintainer email address not working") is now
making python-espeak getting out, thus dropping ibus-braille along it.

It seems sgevatter is generally inactive for a year, his ubuntu
address used in packages does not work any more, so I'm proposing
to salvage the python-espeak package by putting it under the
TTS team umbrella. I have pushed the existing Debian history to
https://salsa.debian.org/tts-team/python-espeak at made sgevatter's
salsa account member of the TTS team, so he can easily contribute again
if he gets time to do so again.

Samuel

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

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

-- 
Samuel
 (* If you have a precise idea of the intended use of the following code, 
please
write to eduardo.gime...@inria.fr and ask for the prize :-)
-- Eduardo (11/8/97) *)
 -+- N sur #ens-mim - et c'était un des développeurs -+-

Bug#933080: closed by Carlos Donizete Froes (Bug#933080: fixed in pekka-kana-2 1.2.3-1)

[Helmut Grohne]

Control: reopen -1

On Fri, Aug 09, 2019 at 06:24:04AM +, Debian Bug Tracking System wrote:
>* New upstream release. (Closes: #933080)

You applied half of the patch. Please also apply the pkg-config
substitution.

Helmut

Bug#945963: libgles2: still uses Priority: extra

[Thorsten Glaser]

Package: libgles2
Version: 1.1.0-1+b1
Severity: normal

Please change Priority extra to optional, in accordance with latest
Policy, as to not make packages depending on libgles2 but of a conforming
priority violate Policy’s requirement of not depending on packages with
a lower priority.


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

Kernel: Linux 5.3.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libgles2 depends on:
ii  libc6  2.29-3
ii  libglvnd0  1.1.0-1+b1

libgles2 recommends no packages.

libgles2 suggests no packages.

Versions of packages libgles2 is related to:
pn  libgl1-nvidia-glx-any  

-- no debconf information

Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'

[Daniel Schepler]

Source: xz-utils
Version: 5.2.4-1
Severity: serious

>From my pbuilder build log:

...
 debian/rules build
dh build --parallel
   dh_update_autotools_config -O--parallel
   dh_auto_configure -O--parallel
   dh_auto_build -O--parallel
   dh_auto_test -O--parallel
 fakeroot debian/rules binary
dh binary --parallel
   debian/rules install
make[1]: Entering directory '/build/xz-utils-5.2.4'
dh install --parallel
   debian/rules build
make[2]: Entering directory '/build/xz-utils-5.2.4'
dh build --parallel
make[2]: Leaving directory '/build/xz-utils-5.2.4'
   dh_testroot -O--parallel
   dh_prep -O--parallel
   debian/rules override_dh_auto_install
make[2]: Entering directory '/build/xz-utils-5.2.4'
dh_auto_install --builddirectory debian/xzdec-build
dh_auto_install --builddirectory debian/normal-build
dh_auto_install --builddirectory debian/static-build
set -e; arch=$(dpkg-architecture -qDEB_HOST_MULTIARCH); \
install -d debian/tmp/lib/$arch; \
mv debian/tmp/usr/lib/$arch/liblzma.so.* debian/tmp/lib/$arch/; \
dso=$(basename $(readlink debian/tmp/usr/lib/$arch/liblzma.so)); \
ln -s -f /lib/$arch/$dso debian/tmp/usr/lib/$arch/liblzma.so
mv: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*': No
such file or directory
make[2]: *** [debian/rules:34: override_dh_auto_install] Error 1
make[2]: Leaving directory '/build/xz-utils-5.2.4'
make[1]: *** [debian/rules:4: install] Error 2
make[1]: Leaving directory '/build/xz-utils-5.2.4'
make: *** [debian/rules:4: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2
-- 
Daniel Schepler

Bug#945962: libgl1: still uses Priority: extra

[Thorsten Glaser]

Package: libgl1
Version: 1.1.0-1+b1
Severity: normal

Please change Priority extra to optional, in accordance with latest
Policy, as to not make packages depending on libgl1 but of a conforming
priority violate Policy’s requirement of not depending on packages with
a lower priority.

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

Kernel: Linux 5.3.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libgl1 is related to:
pn  libgl1-nvidia-glx-any  

Bug#932957: Re Bug 932957 Please migrate Release Notes to reStructuredText

[Paul Gevers]

Hi Andrei,

On Thu, 25 Jul 2019 22:44:29 +0900 Osamu Aoki  wrote:
> Yes.  It can be done.  I just converted developers-reference and someone
> merged it ti main ;-)
> 
> If you follow my commit history, all tools and tricks are there.
> 
> https://salsa.debian.org/debian/developers-reference
> 
> I will work on build script more to make web page looks better.  But
> source conversion was possible though it is non-trivial.
> 
> > Ok, I'll have a look at it, though I wouldn't mind if someone is faster 
> > ;)
> 
> https://salsa.debian.org/debian/developers-reference/blob/1b0940a5c2879a5be3100b0e0f2bee6c5de58bdf/README.rst
> 
> This describes general tasks involved.
> 
> If someone makes broken PO file by copying some msgstr from random
> msgstr, then conversion doesn't work well and it may be cryptic to
> debug.

Are you still upto doing this change? I'm not expecting you worked on
this recently, but now is a good time to get this on the rails. Should
we first branch bullseye (bug #932853), make the relatively small fixes
there and then work on that branch or do you have a different proposal?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#945911: APT leaks repository credentials

[Florian Zumbiehl]

Hi,

> > > works. If I requests https://a/b/c and it redirects me to https://x/y/z,
> > > I need login details for x/y/z to login.
> > 
> > It may well be that you _need_ them. But that doesn't say anything about
> > whether you should _get_ them.
> > 
> > When a web server instructs a browser to submit some request to a different
> > origin, that request may also _need_ credentials for that other origin to
> > perform some operation. But just allowing any web server to submit requests
> > to any other origin with all credentials the browser knows about still is
> > considered a vulnerability, known as "cross site request forgery".
> 
> The vulnerability you describe in a browser is not that the credentials
> are used or that they are leaked somewhere – because they aren't, the
> intended receiver gets them – the problem is that with the state already
> present in the browser (which can be credentials, but also e.g. cookies)
> you can 'automate' things as if the user made that request intentionally
> – like deleting the account, authorizing a bank transfer or post some
> content. None of these things can happen with apt: It is accessing
> static data the user is allowed to receive by knowing the auth, there is
> no operation performed or content uploaded the user didn't intend to
> allow as there is nothing for them to allow.

1. Yes, the problem with CSRF is very much that credentials are used where
   they shouldn't be. For one, "credential" is not the name of a protocol
   field, it's a function of a piece of information. When a cookie
   authorizes you to perform an operation, then that cookie is a
   credential. And then, the fact that the credentials are sent to the
   intended receiver is just completely besides the point, because that is
   exactly the problem with confused deputy style vulnerabilities: The
   deputy uses privileges it has (such as credentials that allow it to
   perform a certain access) to perform an operation requested by a party
   that doesn't have those privileges and that shouldn't have those
   privileges.

   To maybe use a different example: Just because your company's access
   badge is intended to be presented to your company, does not mean that
   everything is fine when someone tricks you into presenting your badge in
   order to get them into the building.

   (And the solution to CSRF is to require another credential, AKA "CSRF
   token", when performing operations where the browser security model
   otherwise would allow confused deputy style attacks, and to keep that
   credential out of reach for other origins.)

1. Please note that I did not say APT had a CSRF vulnerability. I simply
   used a different confused deputy style vulnerability that you might be
   more familiar with to demonstrate a point. So, no, you probably can not
   get APT to authorize a bank transfer. 

   But, again, the fact that the user is allowed to access the data is
   completely besides the point. The user is also allowed to look at their
   bank transactions in their online banking, but still, a browser's
   security model prevents any other random website from accessing them,
   because *the other website is not the user*.

> > > > Examples for how this could be exploited are:
> > > > 
> > > > - The redirect could point to a different port on the server than where 
> > > > the
> > > >   repository is hosted, possibly an unprivileged port where an attacker 
> > > > on
> > > >   that server could be listening to receive the credentials.
> > > 
> > > I don't understand. FWIW; credentials can be limited by port, and path.
> > 
> > Yes, they can. But it is absolutely not clear from the documentation that
> > you are vulnerable to this type of attack if you don't do that. And even if
> > this were stated clearly in the documentation, it would still be bad
> > default behaviour.
> 
> The manpage says:
> | If no port is given the token matches for all ports

And how does it follow that therefore you are vulnerable?

> Anyhow, you are either starting from the position of a HTTP source where
> you need to be an MITM to make use of this "vulnerability" to … well, do
> what you can already do because you are a MITM anyhow. That is the
> problem of a HTTP source, we can't fix that.
> 
> Or it is a HTTPS source, but if you can attack those you again don't need
> this as you are again a MITM apparently with access to the private
> keys of the server which reduces the problem down to HTTP.

I have no idea what you are talking about here!? In particular I don't
understand where you got that MitM from ... none of the scenarios I
described require a MitM!? I mean, yes, a MitM could potentially also
exploit some of this, sure, but it's certainly not limited to MitM.

> > > > - The redirect could point to an HTTP URI to expose the credentials as
> > > >   plain text on the wire, even where the sources.list entries for the
> > > >   respective server point only to HTTPS URIs to protect from 
> > > > eaves

Bug#945960: removal of src:lilo from bullseye

[Paul Gevers]

Package: release-notes
Tags: bullseye

Hi Joachim,

On 30-11-2019 11:26, Joachim Wiedorn wrote:
> But then the only solution is making a transitional package "lilo" which
> have dependency to grub2, which will install grub2 and remove the binaries
> of lilo. This can entail many risks. Because of many different system
> structures it could be, that at the end there is no functioning booting on
> this system ... 

It's this last comment that I was expecting to hear from you. Thanks for
confirming. Then indeed, I think mentioning it in the release-notes is
the best solution for users of lilo.

Regarding the time-line, I suggest to get lilo removed well before the
transition freeze, so that it is well gone during the full period of the
bullseye freeze.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#945959: RM: rust-url-serde -- ROM; obsolete source package

[Paride Legovini]

Package: ftp.debian.org
Severity: normal

Please remove rust-url-serde. Reason for removal: the upstream package
does not exist anymore: its functionality has been incorporated in the
newer versions of the rust_url library, packaged in Debian as
src:rust-url. Currently no package in testing or unstable
(build-)depends on rust-url-serde.

Thanks,

Paride

Bug#887875: libqt5webenginecore5: libQt5WebEngineCore.so.5.9.2 claims to need an executable stack

[Dmitry Shachnev]

reassign 944971 libqt5webenginecore5
merge 887875 944971
fixed 887875 qtwebengine-opensource-src/5.12.4+dfsg-1
thanks

Hi,

On Sun, Jan 21, 2018 at 10:10:57PM +1100, Russell Coker wrote:
> $ execstack -q /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5.9.2
> X /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5.9.2
>
> The shared object is listed as requiring an executable stack.  This weakens
> the security of every application that uses it.

This was fixed upstream in [1], which was applied in Qt 5.12.4.
So this bug is now fixed in testing.

Do you want a fix for Buster?

[1]: https://codereview.qt-project.org/c/qt/qtwebengine/+/263545

--
Dmitry Shachnev

Bug#932501: squid-deb-proxy: daemon does not start due to the conf file not being allowed by apparmor

[Graham Cobb]

Package: squid-deb-proxy
Version: 0.8.14+nmu2
Followup-For: Bug #932501

I am just updating this report to indicate that this bug still exists in
this version.

The workround in the original report seems to work, but without it,
squid-deb-proxy is useless.


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

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

Versions of packages squid-deb-proxy depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  squid  4.9-2

Versions of packages squid-deb-proxy recommends:
ii  avahi-utils  0.7-4+b1

squid-deb-proxy suggests no packages.

-- Configuration Files:
/etc/squid-deb-proxy/squid-deb-proxy.conf changed [not included]

-- no debconf information

Bug#942999: Bug#945957: release.debian.org: Package pymecavideo falsely trageted for AUTORM

[Paul Gevers]

severity 942999 important
thanks

Dear Georges,

Thanks for reaching out.

On 01-12-2019 19:34, Georges Khaznadar wrote:
> I received an e-mail three days ago, Message-Id:  p...@respighi.debian.org>, stating that:
> 
> pymecavideo 6.5.1-1 is marked for autoremoval from testing on 2019-12-28
> 
> It (build-)depends on packages with these RC bugs:
> 942999: doxypy: Python2 removal in sid/bullseye
> 
> 
> 
> I double-checked this package, it does NOT build-depend on doxypy.
> Can you help me to prevent the AUTORM action?

Yes it does.

paul@testavoira ~ $ reverse-depends -r testing doxypy -b
Reverse-Build-Depends
=
* python-odf
* scolasync

paul@testavoira ~ $ reverse-depends -r testing python3-odf
Reverse-Depends
===
* python-odf-tools
* python3-mecavideo
* python3-tablib

It seems that the people pushing for the Python 2 removal from Debian
forgot to consider reverse BUILD dependencies when they mark leaf
packages RC. I have downgraded one of these bugs (#936537) today
already, and I'm doing the same with #942999 now, so that should
(temporarily) get the pressure of your package. But please feel invited
to help the situation of Python 2 removal.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#945957: release.debian.org: Package pymecavideo falsely trageted for AUTORM

[Mattia Rizzolo]

On Sun, Dec 01, 2019 at 07:34:53PM +0100, Georges Khaznadar wrote:
> pymecavideo 6.5.1-1 is marked for autoremoval from testing on 2019-12-28
> 
> It (build-)depends on packages with these RC bugs:
> 942999: doxypy: Python2 removal in sid/bullseye
> 
> 
> 
> I double-checked this package, it does NOT build-depend on doxypy.
> Can you help me to prevent the AUTORM action?

I'm pretty sure that it's becuase of some recursive (build-)dep, but I'm
too lazy to chase it right now.  Regardless, I trust the software to be
right.

> By the way, I am pushing a NEW
> package doxypypy (not doxypy), which is maintained upstream and provides the
> same features, and some improvements.

I wonder, is that a drop-in replacement?  Could it instead be uploaded
in place of the current doxpy?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#945958: gnome-builder: Changes to modified&unsaved files are when closing

[Antonio Trueba Gayol]

Package: gnome-builder
Version: 3.32.4-2
Severity: important
Tags: upstream

Hi,

While editing source files, if the user closes an editor pane before saving
changes to that file the pane is closed without saving changes or asking the
user for confirmation to save or discard changes, so every last minute changes
after the last autosave (if active) are lost without notice. This also happens
when closing the program, this time affecting every unsaved file still open.



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

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

Versions of packages gnome-builder depends on:
ii  clang1:8.0-48.3
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  exuberant-ctags  1:5.9~svn20110310-12
ii  gir1.2-dazzle-1.03.34.1-1
ii  gir1.2-ggit-1.0  0.28.0.1-1+b1
ii  gir1.2-glib-2.0  1.62.0-2
ii  gir1.2-gtk-3.0   3.24.12-1
ii  gir1.2-gtksource-4   4.4.0-1
ii  gir1.2-jsonrpc-1.0   3.34.0-1
ii  gir1.2-peas-1.0  1.22.0-4
ii  gir1.2-template-1.0  3.34.0-1
ii  gir1.2-vte-2.91  0.58.2-1
ii  gir1.2-webkit2-4.0   2.26.2-dmo1
ii  libatk1.0-0  2.34.1-1
ii  libc62.29-3
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libclang1-8  1:8.0.1-4
ii  libdazzle-1.0-0  3.34.1-1
ii  libdevhelp-3-6   3.34.0-1
ii  libenchant1c2a   1.6.0-11.3
ii  libflatpak0  1.4.3-1
ii  libfontconfig1   2.13.1-2+b1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libgirepository-1.0-11.62.0-2
ii  libgit2-glib-1.0-0   0.28.0.1-1+b1
ii  libgladeui-2-6   3.22.1-4
ii  libglib2.0-0 2.62.3-1
ii  libgspell-1-11.6.1-2
ii  libgtk-3-0   3.24.12-1
ii  libgtksourceview-4-0 4.4.0-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libjsonrpc-glib-1.0-13.34.0-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpcre3 2:8.39-12+b1
ii  libpeas-1.0-01.22.0-4
ii  libsoup2.4-1 2.68.2-1
ii  libtemplate-glib-1.0-0   3.34.0-1
ii  libvala-0.46-0   0.46.5-1
ii  libvala-0.46-dev [libvala-dev]   0.46.5-1
ii  libvte-2.91-00.58.2-1
ii  libwebkit2gtk-4.0-37 2.26.2-dmo1
ii  libxml2  2.9.4+dfsg1-8
ii  python3  3.7.5-1
ii  python3-gi   3.34.0-3
ii  sysprof  3.32.0-2

Versions of packages gnome-builder recommends:
ii  build-essential  12.8
ii  flatpak-builder  1.0.9-1
ii  gettext  0.19.8.1-10
ii  meson0.52.0-2
ii  pkg-config   0.29-6
ii  python3-jedi 0.14.1-1
ii  python3-lxml 4.4.1-1+b1
ii  valgrind 1:3.15.0-1

gnome-builder suggests no packages.

-- no debconf information

Bug#887371: nemo: crash/segfault whilst manipulating files in a folder

[N G]

Howdy,

Sorry for the late reply.  Had to wait until the right kernel was backported to 
Buster (new laptop).

Although it can become a bit laggy and/or slow,  I am glad to see that crash is 
no longer reproducible in the stable branch (nemo-3.8.5-1). Tried aggressive 
stuff,  like folders with hundreds of files, thumnails enabled in heavy files,  
and tried to move many files from folder to folder by dragging and dropping, or 
cutting and pasting.  Which was/is the crash formula for old stable,  
consolidating hundreds of files from many folders, into a single folder with 
thousands of files, was impossible.  No more crashes for me.


Happy holidays.


On Sat, 7 Sep 2019 12:30:12 +0200 Fabio Fantoni wrote:

> Hi, from a fast search this seems solved in nemo 4.2.1, can you confirm
> please?
>
>

Bug#945957: release.debian.org: Package pymecavideo falsely trageted for AUTORM

[Georges Khaznadar]

Package: release.debian.org
Severity: normal

Hello release masters,

I received an e-mail three days ago, Message-Id: , stating that:

pymecavideo 6.5.1-1 is marked for autoremoval from testing on 2019-12-28

It (build-)depends on packages with these RC bugs:
942999: doxypy: Python2 removal in sid/bullseye



I double-checked this package, it does NOT build-depend on doxypy.
Can you help me to prevent the AUTORM action?



The same day, I received a similar e-mail about my package scolasync, which I
could improve. By the way, I am pushing a NEW
package doxypypy (not doxypy), which is maintained upstream and provides the
same features, and some improvements.



-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (900, 'stable'), (499, 'testing'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#945956: libinih does not honour DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: libinih
Version: 45-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libinih fails to cross build from source, because it fails running tests
despite DEB_BUILD_OPTIONS=nocheck. Please consider applying the attached
patch to support the nocheck option.

Helmut
diff --minimal -Nru libinih-45/debian/changelog libinih-45/debian/changelog
--- libinih-45/debian/changelog 2019-08-04 14:13:32.0 +0200
+++ libinih-45/debian/changelog 2019-12-01 19:25:22.0 +0100
@@ -1,3 +1,10 @@
+libinih (45-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Honour DEB_BUILD_OPTIONS=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 01 Dec 2019 19:25:22 +0100
+
 libinih (45-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru libinih-45/debian/rules libinih-45/debian/rules
--- libinih-45/debian/rules 2019-08-04 14:13:32.0 +0200
+++ libinih-45/debian/rules 2019-12-01 19:25:20.0 +0100
@@ -20,6 +20,8 @@
dh_clean
rm -f libinih.so.1
 
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 override_dh_auto_test:
ln -s libinih.so libinih.so.1
+$(MAKE) test CFLAGS+=-I.. LDFLAGS+="-Wl,-rpath,.. -L.."
+endif

Bug#545258: heirloom-mailx: fails to set the charset to UTF-8 in From

[Martin-Éric Racine]

su 1. jouluk. 2019 klo 18.44 Paride Legovini (p...@ninthfloor.org) kirjoitti:
>
> On Sun, 06 Sep 2009  wrote:
> > Package: heirloom-mailx
> > Version: 12.4-1.1+b1
> > Severity: normal
> >
> > When piping text into heirloom-mailx, it fails to specify the charset used 
> > with
> > the From: line if the name inherited from /etc/passwd is in UTF-8.
> >
> > cat file | mail -s "some subject" u...@domain.ltd
> >
> > q-funk:x:1000:1000:Martin-Éric Racine,,,:/home/q-funk:/bin/bash
>
> Hello Martin-Éric,
>
> This bug is now >10 years old, so I somewhat hope it got fixed as the
> general adoption of UTF-8 increased in the last years. I tried to
> reproduce the issue you described with the latest version of s-nail in
> unstable (14.9.15-1), but I'm not sure I'm doing it right. The best
> thing would be if you could try to reproduce with a more recent version
> on s-nail and report back. Do you think you could give it a shot?

All my hosts currently run the traditional bsd-mailx.

Martin-Éric

Bug#945846: task-kde-desktop: Use print-manager instead of system-config-printer for KDE installation task

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

I'm redirecting you to the correct Qt/KDE mailing list for this. I'm
mostly into Qt so I don't know the details here :-(

On Sat, 30 Nov 2019 at 18:30, Holger Wansing  wrote:
>
> Hi,
>
> Shmerl  wrote:
> > Package: task-kde-desktop
> [...]
> > Currently, when selecting KDE in Debian installer, task-kde-desktop pulls in
> > system-config-printer for
> > printer settings, which is part of Gnome project and isn't well integrated 
> > with
> > KDE Plasma. Instead, it
> > should use print-manager, which provides printer settings in KDE's own 
> > System
> > Settings interface, and as
> > well allows printer queue access for active jobs in notifications area 
> > (system
> > tray).
>
> If print-manager is that well integrated in KDE, it should probably be a
> Recommends in the kde-baseapps or kde-plasma-desktop metapackage, maybe?
>
> CC'ing KDE people for advice.
>
>
> Holger
>
>
> --
> Holger Wansing 
> PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
>


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#942648:

[sudha alva]

Get Outlook for Android

Bug#945840: /usr/bin/ledger: error while loading shared libraries: libboost_python27.so.1.67.0: cannot open shared object file: No such file or directory

[Giovanni Mascellani]

Hi,

On Fri, 29 Nov 2019 16:42:58 +0100 Kiko Piris
 wrote:> /usr/bin/ledger: error while loading
shared libraries: libboost_python27.so.1.67.0: cannot open shared object
file: No such file or directory

Dimitri, it seems that removing Python 2 support for Boost 1.67 was a
bit too quick. Apparently some packages are still using it, so this is
causing breakages. Therefore I will upload a new version that re-enables
Python 2. Of course Python 2 should never be enabled from Boost 1.71 on.

Also, could you please check that you pushed 1.67.0-15 to the git
repository? I cannot see it.

Of course, reverse dependencies of Boost 1.67 be aware that you will
break when 1.71 will be made the default Boost version, which hopefully
will be relatively soon.

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



signature.asc
Description: OpenPGP digital signature

Bug#945955: RFS: micro-httpd/20051212-16 [ITA] -- really small HTTP server

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "micro-httpd"

 * Package name: micro-httpd
   Version : 20051212-16
   Upstream Author : Jef Poskanzer 
 * URL : http://www.acme.com/software/micro_httpd
 * License : BSD-2-Clause
 * Vcs : https://github.com/sudipm-mukherjee/micro-httpd.git
   Section : httpd

It builds those binary packages:

  micro-httpd - really small HTTP server

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

  https://mentors.debian.net/package/micro-httpd

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/micro-httpd/micro-httpd_20051212-16.dsc

Changes since the last upload:

   * Update Maintainer (Closes: #920132)
   * Update compat level to 12
   * Update Standards-Version to 4.4.1
   * Update Vcs to github
   * Update to correct manpage section
   * Option --group is not needed with update-inetd --remove (Closes: #909503)
   * Fix the postinst script to create systemd symlinks
   * Fix crosscompiling of source


-- 
Regards
Sudip

Bug#945954: monero: Scheduled network hard fork requires v0.15

[Mario Costa]

Package: monero
Version: 0.14.1.2-2
Severity: grave
Justification: renders package unusable

Since November 30th, a scheduled Monero network hard fork requires a version of
the Monero software >= 0.15.

Version 0.15.0.1 is currently the last upstream version.



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

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

Bug#941198: please postpone until after the GR

[Russ Allbery]

Adam Borowski  writes:

> This idea being discussed hasn't been announced anywhere.

I tried to draw attention to it in debian-devel, for the record, and
everyone there seemed happy with it as well.

> But, in the light of the ongoing GR, arguing would be a waste of time at
> this moment.  Thus, could you please put this change into abeyance, and
> once the GR is finished, we'll discuss whether to withdraw (or even
> reverse, it should be "should not"!), according to the GR's result.

I don't think there's any urgent need to put out a new normative version
of Policy and we could hold the next release until January.  What do you
think, Sean?

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

Bug#941198: please postpone until after the GR

[Sean Whitton]

Hello Adam,

On Sun 01 Dec 2019 at 06:07PM +01, Adam Borowski wrote:

> This idea being discussed hasn't been announced anywhere.  And, it's
> extremely harmful to the support of anything non-systemd, while providing
> very little if any benefit to systemd users as well.  It also would cause
> doubling of maintainer effort.
>
> But, in the light of the ongoing GR, arguing would be a waste of time at
> this moment.  Thus, could you please put this change into abeyance, and
> once the GR is finished, we'll discuss whether to withdraw (or even reverse,
> it should be "should not"!), according to the GR's result.

I'm afraid I fail to see how this bug interacts with the current GR at
all.  It seems to me that it could interact with the current GR only if
the current GR was about changing the default init system, but no-one is
proposing anything like that.

How do you think this bug is prejudicial to advocates of alternative
init systems?

At any rate, we're unlikely to do a normative Policy release before
voting is done because we usually wait until we have more than two
normative changes waiting on our 'next' branch before doing that.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Kevin Locke]

On Mon, 08 Jul 2019 16:01:47 -0600 Kevin Locke  wrote:
> The issue is fixed by a 2-line patch to libtorrent that has been merged,
> but not released: https://github.com/rakshasa/libtorrent/pull/176

Quick update:  This patch is included in 0.13.8.

Cheers,
Kevin

Bug#945953: ITP: RandomX -- proof of work (PoW) algorithm for CPUs

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : librandomx
  Version  : 1.1.6
  Upstream Author  : tevador 
* Url  : https://github.com/tevador/RandomX
* Licenses : BSD-3-clause
  Programming Lang : C++

 RandomX is a proof-of-work (PoW) algorithm
 that is optimized for general-purpose CPUs.
 RandomX uses random code execution (hence the name)
 together with several memory-hard techniques
 to minimize the efficiency advantage of specialized hardware.

This package is needed by recent releases of Monero.

I plan to maintain this package in the Debian Cryptocoin Team,
keeping debianization in following Git repository:

  https://salsa.debian.org/cryptocoin-team/librandomx.git

 - Jonas

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

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


signature.asc
Description: signature

Bug#941198: please postpone until after the GR

[Adam Borowski]

Hi!
This idea being discussed hasn't been announced anywhere.  And, it's
extremely harmful to the support of anything non-systemd, while providing
very little if any benefit to systemd users as well.  It also would cause
doubling of maintainer effort.

But, in the light of the ongoing GR, arguing would be a waste of time at
this moment.  Thus, could you please put this change into abeyance, and
once the GR is finished, we'll discuss whether to withdraw (or even reverse,
it should be "should not"!), according to the GR's result.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#945952: ITP: doxypypy -- More Pythonic version of doxypy, a Doxygen filter for Python

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: doxypypy
  Version : 0.8.8.6
  Upstream Author : Eric W. Brown 
* URL : https://github.com/Feneric/doxypypy
* License : GPL2+
  Programming Lang: Python
  Description : More Pythonic version of doxypy, a Doxygen filter for
Python

 For now Doxygen has limited support for Python. It recognizes Python
 comments, but otherwise treats the language as being more or less
 like Java. It doesn’t understand basic Python syntax constructs like
 docstrings, keyword arguments, generators, nested functions,
 decorators, or lambda expressions. It likewise doesn’t understand
 conventional constructs like doctests or ZOPE-style interfaces. It
 does however support inline filters that can be used to make input
 source code a little more like what it’s expecting.
 .
 The excellent doxypy makes it possible to embed Doxygen commands in
 Python docstrings, and have those docstrings converted to
 Doxygen-recognized comments on the fly per Doxygen’s regular input
 filtering process. It however does not address any of the other
 previously mentioned areas of difficulty.
 .
 This project started off as a fork of doxypy but quickly became quite
 distinct. It shares little (if any) of the same code at this point
 (but maintains the original license just in case). It is meant to
 support all the same command line options as doxypy, but handle
 additional Python syntax beyond docstrings.

-

Two of my packages rely on doxypy, whose packages has been unmaintained for
years. (and probably abandoned upstream).
Doxypy is not=w targeted by an AUTORM process.

I shall maintain doxypypy as one good replacement of the previous one.

Bug#545258: heirloom-mailx: fails to set the charset to UTF-8 in From

[Paride Legovini]

On Sun, 06 Sep 2009  wrote:
> Package: heirloom-mailx
> Version: 12.4-1.1+b1
> Severity: normal
> 
> When piping text into heirloom-mailx, it fails to specify the charset used 
> with
> the From: line if the name inherited from /etc/passwd is in UTF-8. 
> 
> cat file | mail -s "some subject" u...@domain.ltd
> 
> q-funk:x:1000:1000:Martin-Éric Racine,,,:/home/q-funk:/bin/bash

Hello Martin-Éric,

This bug is now >10 years old, so I somewhat hope it got fixed as the
general adoption of UTF-8 increased in the last years. I tried to
reproduce the issue you described with the latest version of s-nail in
unstable (14.9.15-1), but I'm not sure I'm doing it right. The best
thing would be if you could try to reproduce with a more recent version
on s-nail and report back. Do you think you could give it a shot?

Thanks!

Paride

Bug#945869: lintian: false positive for debian-rules-not-executable

[gregor herrmann]

On Sun, 01 Dec 2019 16:37:04 +, Chris Lamb wrote:

> > N:The debian/rules file for this package does not appear to be marked as
> > N:executable and should be changed to permission 0755.
> > 
> > and the "0755" seems incorrect as well.
> 
> Good spot. Updated in:
>   
> https://salsa.debian.org/lintian/lintian/commit/6d82f39c734396649b8e533467ec4fb732d52ab6

Thanks again!


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#945951: hp driver crashes for all documents

[VA]

Package: printer-driver-hpcups
Version: 3.19.11+dfsg0-1
Severity: important

All jobs I submit to CUPS fail with "Filter error". The most likely 
cuplrit in /var/log/cups/error_log is probably this:


D [01/Dec/2019:17:29:22 +0100] [Job 578] *** stack smashing detected 
***:  terminated
D [01/Dec/2019:17:29:22 +0100] [Job 578] prnt/backend/hp.c 919: ERROR: 
null print job total=0
D [01/Dec/2019:17:29:22 +0100] [Job 578] PID 1575 
(/usr/lib/cups/filter/hpcups) crashed on signal 6.
D [01/Dec/2019:17:29:22 +0100] [Job 578] PID 1576 
(/usr/lib/cups/backend/hp) exited with no errors.


Even the CUPS test page fails that way, so I guess it's not some 
malformed document but really something terribly wrong in hp driver.

Bug#945869: lintian: false positive for debian-rules-not-executable

[Chris Lamb]

Hi gregor,

> I think there's another tiny glitch left: The info for the tag says
> 
> N:The debian/rules file for this package does not appear to be marked as
> N:executable and should be changed to permission 0755.
> 
> and the "0755" seems incorrect as well.

Good spot. Updated in:

  
https://salsa.debian.org/lintian/lintian/commit/6d82f39c734396649b8e533467ec4fb732d52ab6


Regards,

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

Bug#945950: python3-autopep8: needs Breaks/Replaces on older python-autopep8

[Simon McVittie]

Package: python3-autopep8
Version: 1.4.4-2
Severity: serious
Justification: Policy 7.6

> Unpacking python3-autopep8 (1.4.4-2) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/python3-autopep8_1.4.4-2_all.deb (--unpack):
>  trying to overwrite '/usr/bin/autopep8', which is also in package 
> python-autopep8 1.4.4-1

python3-autopep8 needs Replaces: python-autopep8 (<< 1.4.4-2) and
Breaks: python-autopep8 (<< 1.4.4-2) for this transition.

Please see
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
for more details.

smcv

Bug#945869: lintian: false positive for debian-rules-not-executable

[gregor herrmann]

On Sun, 01 Dec 2019 09:35:50 +, Chris Lamb wrote:

> > I also note that lib/Lintian/Path.pm has
> > 
> > sub is_executable { return $_[0]->_any_bit_in_operm(0111); }
> 
> Neat; applied and pending release.

Thanks for the swift fix!

I think there's another tiny glitch left: The info for the tag says

N:The debian/rules file for this package does not appear to be marked as
N:executable and should be changed to permission 0755.

and the "0755" seems incorrect as well.
 

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#945949: ITP: libxstring-perl -- module containing isolated String helpers from B

[Nick Morrott]

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

* Package name: libxstring-perl
  Version : 0.002
  Upstream Author : Nicolas R 
* URL : https://metacpan.org/release/XString
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module containing isolated String helpers from B

The extremely lightweight XString module provides the string helpers from
the much larger B module (Perl compiler backend) in an isolated package.

Currently the cstring and perlstring helpers are available.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#945948: libexif: CVE-2019-9278

[Salvatore Bonaccorso]

Source: libexif
Version: 0.6.21-5.1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libexif/libexif/issues/26
Control: found -1 0.6.21-2

Hi,

The following vulnerability was published for libexif.

CVE-2019-9278[0]:
| In libexif, there is a possible out of bounds write due to an integer
| overflow. This could lead to remote escalation of privilege in the
| media content provider with no additional execution privileges needed.
| User interaction is needed for exploitation. Product: AndroidVersions:
| Android-10Android ID: A-112537774


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-9278
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9278
[1] https://github.com/libexif/libexif/issues/26

Regards,
Salvatore

Bug#945947: ITP: libxstring-perl -- isolated string helpers from B module

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libxstring-perl
  Version : 0.002
  Upstream Author : Nicolas R 
* URL : https://metacpan.org/release/XString
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : isolated string helpers from B module

XString provides the B string helpers in one isolated package. Right now only
cstring and perlstring are available.

The functions return a double-quote-surrounded escaped version which can be
used as a string in C source code or perl source code respectively.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#891624: Please drop libpcre2-dbg package and rely on -dbgsyms ones

[Michael Biebl]

Control: tags -1 + patch

Attached is a trivial patch to make the switch to dbgsym
It assumes that the next uploaded version will be 10.34-2


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff --git a/rules b/rules
index a68760a..1d1e5b7 100755
--- a/rules
+++ b/rules
@@ -29,4 +29,4 @@ override_dh_makeshlibs:
 	dh_makeshlibs -V --add-udeb=libpcre2-8-0-udeb
 
 override_dh_strip:
-	dh_strip --dbg-package=libpcre2-dbg
+	dh_strip --dbgsym-migration='libpcre2-dbg (<< 10.34-2~)'


signature.asc
Description: OpenPGP digital signature

Bug#943988: Usage message jumbled

[Paride Legovini]

control: severity -1 wishlist
control: tags -1 + wontfix

On Sat, 02 Nov 2019 Dan Jacobson  wrote:
> Package: iw
> Version: 5.3-1
> Severity: minor
> 
> $ iw
> prints a usage message, but it should be more sorted, not jumbled.

Hello Dan,

Thanks for your report. While I can see what you mean I think your
suggestion belongs to the upstream project. Changing the behavior of a
standard tool like iw wouldn't be a sensible choice for a distribution.

Paride