Bug#1041288: ITP: cocotb -- coroutine based cosimulation library for writing VHDL and Verilog testbenches in Python

[Ahmed El-Mahmoudy]

Package: wnpp
Severity: wishlist
Owner: أحمد المحمودي (Ahmed El-Mahmoudy) 

* Package name: cocotb
  Version : 1.8.0
  Upstream Author : Chris Higgs, Stuart Hodgson 
* URL : https://github.com/cocotb/cocotb
* License : BSD
  Programming Lang: Python
  Description : coroutine based cosimulation library for writing VHDL and 
Verilog testbenches in Python

cocotb encourages the same philosophy of design re-use and randomized 
testing as UVM, however is implemented in Python.

With cocotb, VHDL or SystemVerilog are normally only used for the design 
itself, not the testbench.

cocotb has built-in support for integrating with continuous integration 
systems, such as Jenkins, GitLab, etc. through standardized, 
machine-readable test reporting formats.

cocotb was specifically designed to lower the overhead of creating a 
test.

cocotb automatically discovers tests so that no additional step is 
required to add a test to a regression.

All verification is done using Python

 - Intend to maintain it within Electronics team
 - Need a sponsor

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#1041285: ITP: pyuvm -- python implementation of UVM

[Ahmed El-Mahmoudy]

Package: wnpp
Severity: wishlist
Owner: أحمد المحمودي (Ahmed El-Mahmoudy) 

* Package name: pyuvm
  Version : 2.9.1
  Upstream Author : Ray Salemi 
* URL : https://github.com/pyuvm/pyuvm/
* License : Apache-2.0
  Programming Lang: Python
  Description : python implementation of UVM

pyuvm is the Universal Verification Methodology implemented in Python 
instead of SystemVerilog. pyuvm uses cocotb to interact with the 
simulator and schedule simulation events.

pyuvm implements the most often-used parts of the UVM while taking 
advantage of the fact that Python does not have strict typing and does 
not require parameterized classes. The project refactors pieces of the 
UVM that were either overly complicated due to typing or legacy code.

 - Intend to maintain it Electronics team
 - Need a sponsor

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#1034458: msmtp: Add XDG_CONFIG_PATH/msmtp/* to apparmor profile

[Ahmed El-Mahmoudy]

Package: msmtp
Version: 1.8.23-1
Severity: normal

Dear Maintainer,

A user might manually set XDG_CONFIG_DIR to another path than 
$HOME/.config, hence I suggest to add XDG_CONFIG_PATH/msmtp/* to 
apparmor profile

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

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

Versions of packages msmtp depends on:
ii  adduser3.118ubuntu2
ii  debconf [debconf-2.0]  1.5.73
ii  libc6  2.31-0ubuntu9.9
ii  libgnutls303.6.13-2ubuntu1.8
ii  libgsasl7  1.8.1-1
ii  ucf3.0038+nmu1

Versions of packages msmtp recommends:
ii  ca-certificates  20211016ubuntu0.20.04.1

Versions of packages msmtp suggests:
pn  msmtp-mta  

-- debconf information excluded

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#1034107: RFP: xmpppy -- XMPP implementation in Python

[Ahmed El-Mahmoudy]

Package: wnpp
Severity: wishlist

* Package name: xmpppy
  Version : 0.7.1
  Upstream Author : Alexey Nezhdanov 
* URL : https://github.com/xmpppy/xmpppy
* License : GPL-3
  Programming Lang: Python
  Description : XMPP implementation in Python
Python 2/3 implementation of XMPP (RFC3920, RFC3921).
This is a set of modules providing functionality for writing
XMPP-compliant clients or server components in Python.
This library was initially designed as "rework" of jabberpy library but 
lately become a separate product.
Unlike jabberpy it is distributed under the terms of GPL.

This was previously removed from Debian (formerly python-xmpp) because 
it was no longer updated by upstream. Yet Alexey has continued 
maintaining it on GitHub, and has added Python3 support.

At least the jabber weechat plugin (provided by weechat-scripts) uses 
it.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#1032483: unblock: drawtiming/0.7.1-8

[Ahmed El-Mahmoudy]

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

Please unblock package drawtiming

[ Reason ]
Fixes RC bug #984038

[Tests]
autopkgtest & Piuparts testsed OK: 
https://piuparts.debian.org/sid/source/d/drawtiming.html
https://salsa.debian.org/electronics-team/drawtiming/-/pipelines/508918

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

unblock drawtiming/0.7.1-8

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7
diff --git a/debian/changelog b/debian/changelog
index 72d0df3..335b42e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,20 @@
+drawtiming (0.7.1-8) unstable; urgency=medium
+
+  [ Aymeric Agon-Rambosson ]
+  * Add repair-build-c++-17.patch (Closes: #984038).
+  * d/control:
+- Add bison to Build-Depends (needed by upstream Makefile).
+- Replace graphicsmagick with imagemagick to avoid segfault during
+  tests.
+- Replace gsfonts with fonts-urw-base35 (transition), and add
+  fonts-urw-base35 as explicit runtime dependency to prevent segfault.
+
+  [ أحمد المحمودي (Ahmed El-Mahmoudy) ]
+  * Add gitlab-ci.yml
+  * d/gbp.conf: switch to bullseye branch
+
+ -- أحمد المحمودي (Ahmed El-Mahmoudy)   
Sat, 04 Mar 2023 03:07:13 +0100
+
 drawtiming (0.7.1-7) unstable; urgency=medium
 
   [ Dima Kogan ]
diff --git a/debian/control b/debian/control
index ac4079c..5448bb6 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,12 @@ Section: electronics
 Priority: optional
 Maintainer: Debian Electronics Team 

 Uploaders: أحمد المحمودي (Ahmed El-Mahmoudy) 

-Build-Depends: debhelper (>= 10), graphicsmagick-libmagick-dev-compat, 
pkg-config, gsfonts
+Build-Depends:
+ debhelper (>= 10),
+ libmagick++-6.q16-dev,
+ fonts-urw-base35,
+ pkg-config,
+ bison
 Standards-Version: 4.1.5
 Homepage: http://drawtiming.sourceforge.net/
 Vcs-Git: https://salsa.debian.org/electronics-team/drawtiming.git
@@ -11,7 +16,7 @@ Vcs-Browser: 
https://salsa.debian.org/electronics-team/drawtiming
 
 Package: drawtiming
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, fonts-urw-base35
 Description: tool for documenting hardware designs through timing diagrams
  Drawtiming is a command-line tool for documenting hardware designs through
  timing diagrams. In inputs textual signal descriptions and outputs image
diff --git a/debian/gbp.conf b/debian/gbp.conf
index f9636dc..c3d8c22 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,3 +1,3 @@
 [DEFAULT]
 pristine-tar = False
-debian-branch = pkg-debian
+debian-branch = bullseye
diff --git a/debian/gitlab-ci.yml b/debian/gitlab-ci.yml
new file mode 100644
index 000..5c575a1
--- /dev/null
+++ b/debian/gitlab-ci.yml
@@ -0,0 +1,6 @@
+include:
+ - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+ - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+ RELEASE: 'unstable'
diff --git a/debian/patches/repair-build-c++-17.patch 
b/debian/patches/repair-build-c++-17.patch
new file mode 100644
index 000..8c48ae4
--- /dev/null
+++ b/debian/patches/repair-build-c++-17.patch
@@ -0,0 +1,208 @@
+Description: Fix compile failures for newer g++ release
+Author: Thomas Sailer 
+Forwarded: yes
+Comment: Found on https://sourceforge.net/p/drawtiming/patches/12/
+--- a/src/parser.yy
 b/src/parser.yy
+@@ -42,13 +42,13 @@ statements:
+ statement { $$ = $1; deps.push_back ($1); }
+ | statements ',' statement { $$ = $3; deps.push_back ($3); }
+ | statements ';' statement { $$ = $3; deps.clear (); deps.push_back ($3); }
+-| statements CAUSE statement { $$ = $3; data.add_dependencies ($3, deps); 
++| statements CAUSE statement { $$ = $3; data_.add_dependencies ($3, deps); 
+ deps.clear (); deps.push_back ($3); }
+-| statements DELAY statement { $$ = $3; data.add_delay ($3, $1, $2); }
++| statements DELAY statement { $$ = $3; data_.add_delay ($3, $1, $2); }
+ 
+ statement:
+-SYMBOL '=' SYMBOL { $$ = $1; data.set_value ($1, n, timing::sigvalue ($3)); }
+-| SYMBOL '=' STRING { $$ = $1; data.set_value ($1, n, timing::sigvalue ($3, 
timing::STATE)); }
++SYMBOL '=' SYMBOL { $$ = $1; data_.set_value ($1, n, timing::sigvalue ($3)); }
++| SYMBOL '=' STRING { $$ = $1; data_.set_value ($1, n, timing::sigvalue ($3, 
timing::STATE)); }
+ | SYMBOL { $$ = $1; };
+ 
+ %%
+--- a/src/globals.h
 b/src/globals.h
+@@ -22,7 +22,7 @@
+ #define YYSTYPE std::string
+ 
+ extern unsigned n;
+-extern timing::data data;
++extern timing::data data_;
+ extern timing::signal_sequence deps;
+ 
+ #endif
+--- a/src/timing.cc
 b/src/timing.cc
+@@ -113,16 +113,16 @@ sigdata ::operator= (c

Bug#445966:

[el newbiew]

Bug#976907: golang-github-boltdb-bolt: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 -short github.com/boltdb/bolt github.co

[El boulangero]

> Can simply replacing the dependency in all of them with bbolt work?

I don't know myself, but some upstream think it's not a trivial change. For
example, see:

https://github.com/hashicorp/raft-boltdb/pull/19#issuecomment-703732437

In short: hashicorp-raft-boltdb wants to make sure there's no issue before
making the change. This change would impact reverse build deps of
hashicorp-raft-boltdb, like nomad or consul.

I think it's better to downgrade the severity here (as was done in
coreos-bbolt, see https://bugs.debian.org/976926).

Bug#979546: docker.io: version in Bullseye does not support "rootless mode", makes privilege escalation trivial

[El boulangero]

On Sat, Jan 9, 2021 at 2:00 AM Chris Mitchell  wrote:

> On Fri, 8 Jan 2021 11:38:59 +0700
> El boulangero  wrote:
>
> > Hi Chris,
> >
> > I believe what you refer to is a well-known issue with docker. I have
> > this reference from Apr. 2015:
> > https://fosterelli.co/privilege-escalation-via-docker.html
> >
> > This is how docker works. The most easy mitigation is NOT to add a
> > user to the docker group. This way, you will always invoke docker
> > with 'sudo docker', and then it's explicit that you're running
> > something as root. Explicit better than implicit maybe, at least no
> > more "accidental".
>
> This makes some sense. Given that it's apparently well-known that
> allowing a user to run Docker essentially gives them unrestricted root
> access, I'm rather surprised that no warning was presented at any point
> in this process.
>
> > Second thing, as you noted, docker can access a directory on the host
> > only if you share it with '--volume' or '--mount' or something. So
> > it's not really accidental if then the process in the container
> > writes to the host directory. It's something that you authorized
> > explicitly. And the fact that it's a root access is due to the fact
> > that the container is run as root, as you correctly noted.
>
> Ah, okay. This, I think, is where I fundamentally misunderstood the
> situation. I was picturing the "containerized app" as a single entity,
> presenting an all-or-nothing choice between "accept that anything you
> run in a Docker container has root access to your whole filesystem" or
> "don't use Docker". If Docker is providing meaningful enforcement and
> limiting the access of the "contained" app to only the directory(ies)
> you share with it in the container config (though not subject to the
> host system's *permissions*) that's a very different proposition.
>
> Trusting *myself* not to abuse Docker's privilege-escalation abilities
> (on a system where I already have root), checking carefully what paths
> are shared via the container configs, and making sure that the path
> containing those configs is never shared... That's within the realm of
> reasonable expectations.
>
> > If you download and run a containerized app as root, and share your
> > /home with the container, then you'd better trust this app 100%.
>
> To be clear, I did not knowingly or explicitly do any of these things
> except "download and run a containerized app". I downloaded the app as
> a regular user, used my sudo powers to add said user to the docker group
> (because all the "getting started" instructions just say that you need
> to be in the docker group to use Docker) and ran, as a regular user,
> "docker-compose -d up". Now that I know to go looking for it, I see
> that the "volumes" directive appears in one of the config files. While
> I acknowledge that the responsibility for understanding the tools I use
> ultimately falls to me, nothing in this sequence jumps out to me as
> "you are granting unrestricted root access!" or "you'd better trust
> this app 100%".
>

I never used docker-compose, only the docker command itself, so I've always
known more or less what was going on :)

docker-compose is a layer on top of docker, so it hides things away from
the user (in this case, the arguments for the docker command are in a
config file apparently). So things are even less explicit, for the sake of
simplicity.

I think two important things are 1) *which user* is running in the
container (root or non-root), and what volumes are shared. These are the
arguments that you would use the most often with 'docker run', and also the
king of things you'd want to check in a docker compose file.

There are many ways to run container with docker, depending on the
use-case. If you want to run a container manually, as your own user, and
while sharing only the current directory, you can do this:

sudo docker run -it --rm \
-u $(id -u):$(id -g) \
-v /etc/group:/etc/group:ro \
-v /etc/passwd:/etc/passwd:ro \
-v $(pwd):$(pwd) -w $(pwd) \
$YOUR_DOCKER_IMAGE

Note that the two first -v arguments are optional, but they allow that you
user id is known in the container. Try with and without, both work.

This is a command that I use often, but when you get started with docker,
it's unlikely you'll find that by yourself at the first try :)


>
> As a fairly experienced Debian user, I've been accustomed to add myself
> to all sorts of groups over the years, and the only one that has ever
> been presented as "this grants full root powers" is sudo, which then
> pops up a stern warning the first time you use it.

Bug#979546: docker.io: version in Bullseye does not support "rootless mode", makes privilege escalation trivial

[El boulangero]

Hi Chris,

I believe what you refer to is a well-known issue with docker. I have this
reference from Apr. 2015:
https://fosterelli.co/privilege-escalation-via-docker.html

This is how docker works. The most easy mitigation is NOT to add a user to
the docker group. This way, you will always invoke docker with 'sudo
docker', and then it's explicit that you're running something as root.
Explicit better than implicit maybe, at least no more "accidental".

Second thing, as you noted, docker can access a directory on the host only
if you share it with '--volume' or '--mount' or something. So it's not
really accidental if then the process in the container writes to the host
directory. It's something that you authorized explicitly. And the fact that
it's a root access is due to the fact that the container is run as root, as
you correctly noted.

If you download and run a containerized app as root, and share your /home
with the container, then you'd better trust this app 100%.

> a search for "docker" on backports.debian.org returned no results

Indeed, docker sits on top of 100+ dependencies, backporting would mean
backporting all those dependencies. Plus maybe the go compiler and the go
library. It would be such a huge work that it's not realistic.

Since Go is a statically compiled language, there's little value in
backporting anyway. You can just try your luck and install the docker from
Debian unstable into your Debian stable. It might work. Maybe some bugs
would be lurking here and there in the dark, maybe not, I just don't know.

As for rootless mode, it should be indeed supported in the 20.10 version. I
myself never tested it. If I'm not mistaken, everything is present in the
20.10 package provided in Debian unstable to run the rootless mode. You can
give it a try :)

All the best,

  Arnaud






On Fri, Jan 8, 2021 at 10:48 AM Chris  wrote:

> Package: docker.io
> Version: 18.09.1+dfsg1-7.1+deb10u2
> Severity: critical
> Tags: security
> Justification: root security hole
>
> Dear Maintainer,
>
> Unless I'm missing something, any program running in a Docker container
> using the Docker version currently available in Debian stable has a
> trivial-to-exploit path to full, persistent, root privilege escalation.
>
> Docker v18 only works when it's SUID root. Processes running as root
> *inside* the container accessing the *host* filesystem do so as root *on
> the host system* unless they are internally configured to map to a
> regular user on the host system. (According to my rough and inexpert
> understanding of the situation.)
>
> I installed docker.io from the official Debian stable repos, added a
> user to group "docker" in order to be able to use it, downloaded and
> ran a containerized program, and noticed that the program in the
> container was creating files and directories with root ownership in my
> home directory on the host system.
>
> A quick search of the web turned up a tutorial showing how easy it is
> to exploit this situation:
> https://medium.com/@Affix/privilege-escallation-with-docker-56dc682a6e17
> ...as well as tutorials on how not to *accidentally* create root-owned
> files on the host system when setting up Docker containers, eg:
> https://vsupalov.com/docker-shared-permissions/
>
> I discovered that newer versions of Docker have a "rootless mode" that
> doesn't require the main Docker executable to run SUID root (though it
> does rely on a couple of narrow-scope SUID helper utilities), which
> should hopefully mitigate this situation to a considerable extent:
> https://docs.docker.com/engine/security/rootless
> This capability was introduced as experimental in v19.03 and "graduated
> from experimental" in v20.10. Unsurprisingly, it requires that
> unprivileged_userns_clone be enabled.
>
> The version of docker.io in the Buster repos is 18.09 at the time of
> this writing, and a search for "docker" on backports.debian.org returned
> no results. While I am aware of the controversy around
> unprivileged_userns_clone, I gather that it will be enabled by default
> in Bullseye (starting with kernel 5.10, I believe) because at this point
> it presents the lesser evil.
>
> Unless I'm gravely mistaken about the situation, I'd much rather enable
> that potentially-exploitable kernel feature and run Docker in "rootless
> mode" than continue running Docker in a configuration that's so easily
> exploitable there are tutorials on how to prevent accidentally creating
> files as root when using Docker containers as a regular user.
>
> Accidental. Root. Filesystem access. As a regular user.
>
> I propose that — as a minimum — backporting the version of Docker in
> Bullseye (currently v20.10) to Buster be treated as an urgent security
> priority, so that users at least have the option to install Docker from
> an official Debian source and use it in the less-dangerous "rootless
> mode".
>
> Further, Docker is widespread and gaining popularity fast, it's already
> in the Debian stable repositories, and 

Bug#977652: Fix in golang-goprotobuf 1.3.4

[El boulangero]

> if I just disable code regeneration, the diff with 1.3.4-2 is really
minor.

Answering to myself, so I looked at that again, and the diff is not that
small. It's true that the only file impacted is plugin.pb.go (which is the
file that needs a fix), but the diff is not exactly minor.

Main differences:

-const _ = proto.ProtoPackageIsVersion3
+const _ = proto.ProtoPackageIsVersion2

-func (m *CodeGeneratorResponse_File) XXX_Unmarshal(b []byte) error {
+func (m *CodeGeneratorResponse_File) Unmarshal(b []byte) error {

-func (m *CodeGeneratorResponse_File) XXX_Marshal(b []byte, deterministic
bool) ([]byte, error) {
+func (m *CodeGeneratorResponse_File) Marshal(b []byte, deterministic bool)
([]byte, error) {

I really have no idea if these changes are significant.

On Wed, Jan 6, 2021 at 11:45 AM El boulangero 
wrote:

> It can be fixed with regeneration, in an ugly way. I patch the generated
> file after it's been generated, I didn't find a better solution... It could
> be a bug upstream. However upstream did a major code refactoring to go to
> version 1.4, so there's no fix that can be cherry-picked from their git
> history.
>
> But that's not the point. My concern is that if I rebuild the package with
> code regeneration, the diff with the current package "golang-goprotobuf-dev
> 1.3.4-2" is much bigger, and I'm afraid that it breaks things. On the other
> hand, if I just disable code regeneration, the diff with 1.3.4-2 is really
> minor.
>
> So I thought that, given the timeline, it was better to make as little
> change as possible to this package.
>
> On Wed, Jan 6, 2021 at 11:32 AM Shengjing Zhu  wrote:
>
>> On Wed, Jan 06, 2021 at 10:16:16AM +0700, El boulangero wrote:
>> > Hello Go Team,
>> >
>> > in order to solve #977652, I would need to modify & rebuild the package
>> > golang-goprotobuf.
>> >
>> > The issue is that this package has many reverse build deps, as you might
>> > know already:
>> >
>> > $ build-rdeps golang-goprotobuf-dev
>> > ...
>> > Found a total of 218 reverse build-depend(s) for
>> golang-goprotobuf-dev.
>> >
>> > I did some work already, and it seems that the least invasive way to fix
>> > #977652 is simply to disable code regeneration and rebuild
>> > golang-goprotobuf. The diff in the binary package golang-goprotobuf-dev
>> > will then be very minor. I can post a diff if anyone is interested.
>> >
>> > My question is: is it OK to update this package now, or is it too risky,
>> > and should I wait for after the freeze then?
>>
>> I think minor fix is ok. But OTOH I think we want to keep regenerating
>> files.
>> Can it be fixed with regeneration?
>>
>>

Bug#977652: Fix in golang-goprotobuf 1.3.4

[El boulangero]

It can be fixed with regeneration, in an ugly way. I patch the generated
file after it's been generated, I didn't find a better solution... It could
be a bug upstream. However upstream did a major code refactoring to go to
version 1.4, so there's no fix that can be cherry-picked from their git
history.

But that's not the point. My concern is that if I rebuild the package with
code regeneration, the diff with the current package "golang-goprotobuf-dev
1.3.4-2" is much bigger, and I'm afraid that it breaks things. On the other
hand, if I just disable code regeneration, the diff with 1.3.4-2 is really
minor.

So I thought that, given the timeline, it was better to make as little
change as possible to this package.

On Wed, Jan 6, 2021 at 11:32 AM Shengjing Zhu  wrote:

> On Wed, Jan 06, 2021 at 10:16:16AM +0700, El boulangero wrote:
> > Hello Go Team,
> >
> > in order to solve #977652, I would need to modify & rebuild the package
> > golang-goprotobuf.
> >
> > The issue is that this package has many reverse build deps, as you might
> > know already:
> >
> > $ build-rdeps golang-goprotobuf-dev
> > ...
> > Found a total of 218 reverse build-depend(s) for
> golang-goprotobuf-dev.
> >
> > I did some work already, and it seems that the least invasive way to fix
> > #977652 is simply to disable code regeneration and rebuild
> > golang-goprotobuf. The diff in the binary package golang-goprotobuf-dev
> > will then be very minor. I can post a diff if anyone is interested.
> >
> > My question is: is it OK to update this package now, or is it too risky,
> > and should I wait for after the freeze then?
>
> I think minor fix is ok. But OTOH I think we want to keep regenerating
> files.
> Can it be fixed with regeneration?
>
>

Bug#977019: ITP: golang-golang-x-term -- Go terminal and console support

[El boulangero]

Yes it's packaged already and waiting in the NEW queue:
https://ftp-master.debian.org/new.html

Cheers,
  Arnaud

On Wed, Dec 16, 2020 at 12:10 AM Roger Shimizu 
wrote:

> On Thu, Dec 10, 2020 at 2:18 PM Arnaud Rebillout 
> wrote:
> >
> > * Package name: golang-golang-x-term
> >   Version : 0.0~git20201207.ee85cb9-1
> >   Upstream Author : Go
> > * URL : https://github.com/golang/term
> > 
> > Why packaging: this is a new build dependency of docker.io 20.10.0
>
> Seems this is also a new dependency for golang-go.crypto package.
> Have you packaged anything? or already near upload?
>
> Thanks!
> --
> Roger Shimizu, GMT +9 Tokyo
> PGP/GPG: 4096R/6C6ACD6417B3ACB1
>

Bug#943981: Proposal: Switch to cgroupv2 by default

[El boulangero]

Hi! Docker 20.10 is now in unstable.

Best,

  Arnaud

On Sat, Dec 12, 2020 at 4:18 AM Michael Biebl  wrote:

> On Fri, 27 Nov 2020 15:50:03 +0700 El boulangero 
> wrote:
> > Hello all, here comes news from the docker package.
>
> Awesome news.
> I see you have uploaded docker  20.10.0+dfsg1-1 to experimental.
>
> Once systemd 247.1-4 has migrated to testing (i.e. in a couple of
> days), I intend to flip the switch to cgroupv2
> It would probably be good, if this was accompanied with a corresponding
> upload of docker.io 20.x to unstable.
>
> Regards,
> Michael
>

Bug#918375: Info received (dockerd segfaults can be repeated)

[El boulangero]

Thanks for the details.

So I just uploaded a new version in experimental, it is
20.10.0~rc1+dfsg3-1. In this version docker.io vendors the old go-radix, as
suggested.

If someone can give it a try and confirm that indeed the bug is fixed, that
would be great. Thanks again.

  Arnaud

On Wed, Dec 2, 2020 at 12:48 AM Shengjing Zhu  wrote:

> Sadly I see it in my log too. So after searching a bit, I find this
>
> https://github.com/moby/libnetwork/pull/2581
>
> So it's indeed caused by golang-github-armon-go-radix-dev 1.0.0
>
> And docker maintainer has proposed a patch to go-radix,
> https://github.com/armon/go-radix/pull/14
> But reading from the issue, it seems docker just implemented in the wrong
> way.
>
> So I suggest vendoring the old go-radix...
>
> On Mon, Sep 16, 2019 at 1:53 PM Arnaud Rebillout
>  wrote:
> >
> >
> > From: Vincent Smeets 
> >
> > Using journalctl, I see the following error:
> >
> > panic: runtime error: invalid memory address or nil pointer dereference
> > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0
> pc=0x564a9d3a2158]
> > goroutine 439 [running]:
> > github.com/armon/go-radix.recursiveWalk(0x0, 0xc4212bddb8, 0xc4212bdc00)
> > /build/docker.io-18.06.1+dfsg1/.gopath/src/
> github.com/armon/go-radix/radix.go:477 +0x28
> >
> >
> > Hans, do you also see the same logs in the journal? (trying to be sure
> it's the same issue)
> >
> > docker-ce builds against armon/go-radix
> e39d623f12e8e41c7b5529e9a9dd67a1e2261f80, Jan 2015 [1]
> >
> > docker.io builds against armon/go-radix v1.0, Aug 2018 [2], as you can
> see with:
> >
> >   $ rmadison golang-github-armon-go-radix-dev
> >   golang-github-armon-go-radix-dev | 1.0.0-1 |
> stable | all
> >   golang-github-armon-go-radix-dev | 1.0.0-1 |
> unstable   | all
> >
> > That could be the issue. Now, I don't know if you hit a bug in go-radix
> v1.0, or if you hit an incompatibility between docker and the version v1.0
> of go-radix.
>
>
> --
> Shengjing Zhu
>

Bug#974857: new upstream version 20.10.0-beta1

[El boulangero]

I just uploaded docker.io 20.10.0~rc1+dfsg2-3 to experimental. containerd
has been completely removed from this version. Now docker.io build-depends
on golang-github-containerd-containerd-dev, and at runtime it depends on
containerd.

There's still some work to be done on the package, mainly updating /
cleaning up the build depend tree. I'll work on that this week. Cheers.

  Arnaud

On Sat, Nov 28, 2020 at 12:35 AM Shengjing Zhu  wrote:

> On Fri, Nov 27, 2020 at 11:19 PM Shengjing Zhu  wrote:
> [...]
> >
> > > What do you think of that ? Would you mind looking at
> https://salsa.debian.org/docker-team/docker/-/commit/da70c7e, and tell me
> if that makes sense to apply these patches in containerd ? Or do you have a
> better idea ?
> > >
> >
> > I will try to backport.
>
> It's in experimental now.
>
> --
> Shengjing Zhu
>

Bug#975563: golang-k8s-sigs-structured-merge-diff: Please update to upstream version 4.0 or later

[El boulangero]

On Sat, Nov 28, 2020 at 11:35 PM Shengjing Zhu  wrote:

> Hi
>
> On Sun, Nov 29, 2020 at 12:06 AM El boulangero 
> wrote:
> >
> > This broke the build for containerd, and also for docker.io which
> embeds containerd:
> >
> >
> https://buildd.debian.org/status/fetch.php?pkg=docker.io=s390x=20.10.0%7Erc1%2Bdfsg1-1=1606547204=0
> >
> > /<>/.gopath/src/
> github.com/containerd/containerd/vendor/sigs.k8s.io/structured-merge-diff/v3/value
> (vendor tree)
> > /usr/lib/go-1.15/src/sigs.k8s.io/structured-merge-diff/v3/value (from
> $GOROOT)
> > /<>/.gopath/src/sigs.k8s.io/structured-merge-diff/v3/value
> (from $GOPATH)
> >
> > (the latest containerd builds were still against
> k8s-structured-merge-diff v3, so they succeeded, only this docker.io
> build was late enough to pick up the v4)
> >
> > By any chance, do you know if simply patching to use v4 instead of v3 in
> the import path will work? Or is there another way to handle this?
> >
>
> The code in k8s-structured-merge-diff which containerd uses, is same
> in v3 and v4. So in containerd, I just relax the version,
>
> https://salsa.debian.org/go-team/packages/containerd/-/blob/debian/sid/debian/patches/0004-relax-structured-merge-diff-version.patch


Thanks for that!

I didn't realize that containerd 1.4.1 used structured-merge-diff v3, while
containerd 1.4.2 that was just releases uses v4. So basically, no problem.
Sorry for the noise!



>
> --
> Shengjing Zhu
>

Bug#975563: golang-k8s-sigs-structured-merge-diff: Please update to upstream version 4.0 or later

[El boulangero]

This broke the build for containerd, and also for docker.io which embeds
containerd:

https://buildd.debian.org/status/fetch.php?pkg=docker.io=s390x=20.10.0%7Erc1%2Bdfsg1-1=1606547204=0

/<>/.gopath/src/
github.com/containerd/containerd/vendor/sigs.k8s.io/structured-merge-diff/v3/value
(vendor tree)
/usr/lib/go-1.15/src/sigs.k8s.io/structured-merge-diff/v3/value (from
$GOROOT)
/<>/.gopath/src/sigs.k8s.io/structured-merge-diff/v3/value
(from $GOPATH)

(the latest containerd builds were still against k8s-structured-merge-diff
v3, so they succeeded, only this docker.io build was late enough to pick up
the v4)

By any chance, do you know if simply patching to use v4 instead of v3 in
the import path will work? Or is there another way to handle this?

Cheers,

  Arnaud

Bug#943981: Proposal: Switch to cgroupv2 by default

[El boulangero]

Hello all, here comes news from the docker package.

I can confirm, if ever there was a need, that docker 19.03 does not work
with `systemd.unified_cgroup_hierarchy=true`.

  $ dpkg -l | grep docker
  ii  docker.io  19.03.13+dfsg3-2  amd64  Linux container runtime

  $ findmnt /sys/fs/cgroup
  TARGET SOURCE  FSTYPE  OPTIONS
  /sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate

  $ systemctl is-active docker
  active

  $ sudo docker run --rm -it debian
  docker: Error response from daemon: cgroups: cgroup mountpoint does not
exist: unknown.

Docker will support cgroupv2 in the upcoming `20.10` version. They released
a rc1 a few days ago:
- 

I packaged this version and I just uploaded it to experimental:
- 
- <
https://buildd.debian.org/status/package.php?p=docker.io=experimental>

I can confirm with a quick test that it seems to work:

  $ dpkg -l | grep docker
  ii  docker.io  20.10.0~rc1+dfsg1-1  amd64  Linux container runtime

  $ sudo docker run --rm -it debian echo 'hello world'
  hello world

Please note that the package I uploaded to experimental is a work in
progress. Please give it a try and report issues.

Whether Docker upstream will release a "stable" version in time for Debian
Bullseye is another question. Wait and see.

Cheers,

  Arnaud

Bug#974857: new upstream version 20.10.0-beta1

[El boulangero]

I just finished packaging 20.10.0~rc1. It's still a WIP, but good enough
for upload to experimental. The package should be available in experimental
soon. Here are some links:

- <https://salsa.debian.org/docker-team/docker/-/tree/experimental>
- <
https://buildd.debian.org/status/package.php?p=docker.io=experimental>

@Shengjing: For now the package still embeds containerd, as was the case
with docker.io 19.03.x. However it would be nice to remove this copy of
containerd from docker.io.

At the moment, here is the situation:
- Docker 20.10.0-rc1 "upstream" builds against containerd d4e7820, which is
somewhere on the MASTER branch after v1.4.0 (so it's NOT on the 1.4 branch).
- The package I prepared for Debian is built against containerd v1.4.1
though, as I want to use a stable version of containerd.
- In order to build against containerd v1.4.1, I needed to backport 3
patches from the master branch, see:
https://salsa.debian.org/docker-team/docker/-/commit/da70c7e
- These patches are needed to fix a FTBFS in moby/buildkit, which is a
(vendored) build depend of docker

So at the moment, if I want to COMPLETELY remove containerd from docker.io,
it means that either:
- containerd needs to backport these 3 patches, just so that docker.io can
build
- OR find a better solution (for example, revert patches in moby/buildkit
so that it can build against old containerd v1.4, but no, I tried, I don't
think it can work)

If we go for this solution, I think that:
- it can work for debian bullseye (ie. stable), because after it's released
nothing will change much
- however for debian unstable, I think it could be trouble. Containerd 1.5
will be released, then 1.6, and docker.io will lag behind and maybe require
more and more patching to build (unless containerd is very good at
preserving backward compatibility).

There is also another solution, a bit in the middle: docker.io keeps a
vendor copy of containerd (so that docker.io can patch its copy of
containerd as needed), but it uses this copy only for build time. For
runtime, docker can depend on the containerd package from Debian.

My proposition would be:
- try to completely remove containerd from docker.io for now, so that it's
nice and clean for debian stable
- then during maintenance in debian unstable, if it becomes too much of a
mess, revert to vendoring containerd in docker.io, but only as a build dep

What do you think of that ? Would you mind looking at
https://salsa.debian.org/docker-team/docker/-/commit/da70c7e, and tell me
if that makes sense to apply these patches in containerd ? Or do you have a
better idea ?

(( Of course, this assumes that there will be a docker v20.10 stable
release in time for Bullseye... ))

Cheers,

  Arnaud



On Thu, Nov 19, 2020 at 10:57 AM Shengjing Zhu  wrote:

> 20.10 is still in beta, so it shouldn't be candidate for bullseye. But if
> they release the stable version before bullseye freeze, maybe we should
> update.
>
> Regarding cgroupv2, systemd maintainer has proposed to switch to cgroupv2
> by default 1year ago. Please see #943981. It seems docker is the only
> blocker now.
>
> // send from my mobile device
>
> El boulangero  于 2020年11月19日周四 11:24写道：
>
>> Hi Shengjing,
>>
>> thanks for the message. I agree that we should start packaging docker
>> 20.10.x in experimental.
>>
>> Regarding docker 19.03.x: do you know if it will work at all in bullseye?
>> Right now it works for me, running Debian unstable. I guess it's because
>> both cgroup interfaces are available:
>>
>>   $ grep cgroup /proc/filesystems
>>   nodev cgroup
>>   nodev cgroup2
>>
>> Do you know if Bullseye will ship with both cgroup? Hence docker 19.03.x
>> will work?
>>
>> Personally I would be in favor of sticking to the Docker branch 19.03 for
>> bullseye, rather than shipping a beta that will then never be updated to
>> later point releases, due to Debian policy for the stable suite.
>>
>>
>>
>> On Sun, Nov 15, 2020 at 11:09 PM Shengjing Zhu  wrote:
>>
>>> Package: docker.io
>>> Version: 19.03.13+dfsg1-3
>>> Severity: wishlist
>>> X-Debbugs-Cc: z...@debian.org
>>>
>>> Hi,
>>>
>>> docker has released 20.10.0-beta1 for a while. Not sure the plan for
>>> stable
>>> release.
>>>
>>> But if we want 20.10 in bullseye, I suggest starting to package
>>> 20.10.0-beta1
>>> and upload to experimental. So people have time to test.
>>>
>>> A big improvement in 20.10 is supporting cgroupv2.
>>>
>>> https://github.com/docker/docker-ce/blob/master/VERSION
>>> https://github.com/moby/moby/releases/tag/v20.10.0-beta1
>>> https://github.com/docker/docker-ce/blob/master/CHANGELOG.md
>>>
>>

Bug#974857: new upstream version 20.10.0-beta1

[El boulangero]

Hi Shengjing,

thanks for the message. I agree that we should start packaging docker
20.10.x in experimental.

Regarding docker 19.03.x: do you know if it will work at all in bullseye?
Right now it works for me, running Debian unstable. I guess it's because
both cgroup interfaces are available:

  $ grep cgroup /proc/filesystems
  nodev cgroup
  nodev cgroup2

Do you know if Bullseye will ship with both cgroup? Hence docker 19.03.x
will work?

Personally I would be in favor of sticking to the Docker branch 19.03 for
bullseye, rather than shipping a beta that will then never be updated to
later point releases, due to Debian policy for the stable suite.



On Sun, Nov 15, 2020 at 11:09 PM Shengjing Zhu  wrote:

> Package: docker.io
> Version: 19.03.13+dfsg1-3
> Severity: wishlist
> X-Debbugs-Cc: z...@debian.org
>
> Hi,
>
> docker has released 20.10.0-beta1 for a while. Not sure the plan for stable
> release.
>
> But if we want 20.10 in bullseye, I suggest starting to package
> 20.10.0-beta1
> and upload to experimental. So people have time to test.
>
> A big improvement in 20.10 is supporting cgroupv2.
>
> https://github.com/docker/docker-ce/blob/master/VERSION
> https://github.com/moby/moby/releases/tag/v20.10.0-beta1
> https://github.com/docker/docker-ce/blob/master/CHANGELOG.md
>

Bug#971789: FTBFS: Could not determine section for ./.gopath/src/github.com/docker/cli/man/man1/docker-attach.1

[El boulangero]

I could solve the issue by patching spf13/cobra as suggested by Tianon. See
[1] for the patch. I just uploaded the package.

Since docker.io has to embed spf13/cobra, I could patch it there. But if
other packages in Debian have the same issue, then maybe this patch should
be applied to golang-github-spf13-cobra-dev.

Also, not that apparently the upstream bug is at
https://github.com/spf13/cobra/issues/1049



[1]:
https://salsa.debian.org/docker-team/docker/-/blob/master/debian/patches/cli-fix-spf13-cobra-man-docs.patch

On Tue, Oct 13, 2020 at 7:27 PM Sascha Steinbiss  wrote:

> Hi,
>
> has anyone taken any action here already? Some of my packages are
> affected by this as well.
>
> Cheers
> Sascha
>

Bug#970525: docker.io: Unable to start minikube/kubernetes containers: unable to find user 0: invalid argument

[El boulangero]

Then the issue must lie in this commit:
https://salsa.debian.org/docker-team/docker/-/commit/ad52cffa31359262a8e9d44daddf896c3e063dd2

The docker.io package didn't build anymore, due to runc `1.0.0~rc92` which
landed in debian unstable. Shengjing Zhu came up with the patch to fix
that, but it was not a straightforward patch. The issue could be in this
patch. Or maybe there's more work required to make docker.io 19.03.x work
with latest runc (ie. more patching is needed, not less, sorry :/).

Let me say it another way: when you install docker-ce from Docker's repo,
you also get the containerd.io package, that ships the runc binary. All of
these components are basically provided altogether by docker, and they are
at versions that were tested together. While in Debian, these separate
components (containerd, runc) are packaged independently, and these are not
the same versions as the ones shipped by Docker. So sometimes we hit this
kind of issues with the Debian package.

And to be more correct: in Debian we actually bundle containerd within the
docker.io package, because nobody has the bandwidth to try to make docker
19.03.x build-against / work-with containerd 1.4.x. So we build the version
of containerd that is vendored in the docker source tree, and ship it in
the docker.io package. But runc is NOT bundled in, it is provided
independently by the runc package, ie. version `1.0.0~rc92`.

I hope that this clarifies a bit what is the issue here.

I CC Shengjing in case he knows more about this issue. I will also try to
have a look on my side as well.

In the meantime I guess you can downgrade to docker.io version
19.03.12+dfsg1-3 and maybe use `apt-mark hold` to prevent any further
upgrade.

Cheers,

  Arnaud


On Tue, Sep 22, 2020 at 6:35 AM Tianon Gravi  wrote:

> On Mon, 21 Sep 2020 at 13:48,  wrote:
> > On Sun, Sep 20, 2020 at 09:58:45AM +0700, El boulangero wrote:
> > > Do you know what's special with the `tianon/true` image? On what
> OS/release
> > > is it based?
> >
> > It's an image that contains only a single binary that returns 0. That
> > binary uses no libraries, not even libc.
> >
> > It's intended as an extremely light-weight image for purposes that don't
> > need a whole OS. See, for example,
> >
> https://stackoverflow.com/questions/37120260/configure-docker-compose-override-to-ignore-hide-some-containers
> >
> > It seems that something changed between 19.03.12+dfsg1-3 and
> > 19.03.12+dfsg1-4 that is somehow or other assuming the container
> > contains more infrastructure. If you determine that the bug is upstream,
> > feel free to forward it to them (and, ideally, revert whatever patch was
> > added to 19.03.12+dfsg1-4 that caused the problem in the mean time to
> > avoid breaking other software on the system).
>
> I don't think this is an upstream bug -- I'm using their "docker-ce"
> package (version "5:19.03.12~3-0~debian-buster") on a host I've got,
> and here's the result of some tests there:
>
> $ docker run --rm tianon/true && echo ok
> ok
>
> $ docker run --rm --user 0:0 tianon/true && echo ok
> ok
>
> $ docker run --rm --user 1000:1000 tianon/true && echo ok
> ok
>
> ♥,
> - Tianon
>   4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4
>

Bug#970525: docker.io: Unable to start minikube/kubernetes containers: unable to find user 0: invalid argument

[El boulangero]

Hi,

I can indeed reproduce the issue. Note that this doesn't happen with the
`debian` image, only with the image `tianon/true`.

$ sudo docker run --rm -it debian echo ok
ok

Do you know what's special with the `tianon/true` image? On what OS/release
is it based?

Additionally, did you try with the docker package provided by docker.com?
See https://docs.docker.com/engine/install/debian/ . If you hit the same
problem, then you should report the issue upstream. If you don't, then
maybe there's something to investigate in the way we build the package for
Debian.

Cheers,

  Arnaud





On Fri, Sep 18, 2020 at 11:03 PM  wrote:

> Here's a simpler test case:
>
>   $ sudo dpkg -i docker.io_19.03.12+dfsg1-4_amd64.deb
>   (Reading database ... 257350 files and directories currently installed.)
>   Preparing to unpack docker.io_19.03.12+dfsg1-4_amd64.deb ...
>   Unpacking docker.io (19.03.12+dfsg1-4) over (19.03.12+dfsg1-3) ...
>   Setting up docker.io (19.03.12+dfsg1-4) ...
>   insserv: Script sysstat has overlapping Default-Start and Default-Stop
> runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
>   Processing triggers for systemd (246.5-1) ...
>   Processing triggers for man-db (2.9.3-2) ...
>   $ sudo systemctl restart docker
>   $ sudo docker run tianon/true && echo "ok"
>   docker: Error response from daemon: unable to find user 0: invalid
> argument.
>   ERRO[] error waiting for container: context canceled
>
> versus
>
>   $ sudo dpkg -i docker.io_19.03.12+dfsg1-3_amd64.deb
>   dpkg: warning: downgrading docker.io from 19.03.12+dfsg1-4 to
> 19.03.12+dfsg1-3
>   (Reading database ... 257350 files and directories currently installed.)
>   Preparing to unpack docker.io_19.03.12+dfsg1-3_amd64.deb ...
>   Unpacking docker.io (19.03.12+dfsg1-3) over (19.03.12+dfsg1-4) ...
>   Setting up docker.io (19.03.12+dfsg1-3) ...
>   insserv: Script sysstat has overlapping Default-Start and Default-Stop
> runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
>   Processing triggers for systemd (246.5-1) ...
>   Processing triggers for man-db (2.9.3-2) ...
>   $ sudo systemctl restart docker
>   $ sudo docker run tianon/true && echo "ok"
>   ok
>

Bug#969227: FTBFS with new runc 1.0.0~rc92 and libcap2 2.43

[El boulangero]

The patch test--fix-against-libcap2-2.43.patch actually fails the build for
me, in a sid chroot with libcap 2.43.


=== RUN   TestTarUntarWithXattr
archive_unix_test.go:267: assertion failed: string
"/tmp/docker-test-untar-origin293876876/2 = cap_block_suspend+ep\n" does
not contain "cap_block_suspend=ep": untar should have kept the
'security.capability' xattr
archive_unix_test.go:267: assertion failed: string
"/tmp/docker-test-untar-origin293876876/2 = cap_block_suspend+ep\n" does
not contain "cap_block_suspend=ep": untar should have kept the
'security.capability' xattr


This is not very important anyway, as this patch applies to a test that
requires root, hence is skipped on buildd.

The patch fix-build-against-runc-rc92.patch indeed fixes the build. Going
to upload  a new version of the docker.io package soon.

Thanks!

  Arnaud


On Sun, Aug 30, 2020 at 8:09 AM Dmitry Smirnov  wrote:

> On Sunday, 30 August 2020 3:01:34 AM AEST Shengjing Zhu wrote:
> > Please see the patches attached.
>
> Thank you very much!
>
>
> > BTW, is there any instruction to work with the docker.io git repo?
> > It seems `gbp buildpackage` or `gbp pq` are hard to use with it.
>
> Something like the following:
>
>   https://salsa.debian.org/onlyjob/notes/-/wikis/bp
>
> Start with "debian" directory, obtain and extract orig tarballs with
> 'origtargz' then build with your preferred method (e.g. pbuilder).
>
> MUT and complex Golang packages are ridiculously difficult to maintain
> with GBP...
>
> See also https://salsa.debian.org/onlyjob/notes/-/wikis/no-gbp
>
> --
> Best wishes,
>  Dmitry Smirnov.
>
> ---
>
> Truth — Something somehow discreditable to someone.
> -- H. L. Mencken, 1949
>
> ---
>
> A study on infectivity of asymptomatic SARS-CoV-2 carriers, concludes weak
> transmission. "The median contact time for patients was four days and that
> for family members was five days."
> -- https://pubmed.ncbi.nlm.nih.gov/32513410/
>

Bug#965123: docker.io: Please apply some upstream patches for podman 2.0

[El boulangero]

> The milestone page https://github.com/docker/cli/milestone/25?closed=1
seems to indicate that docker is close to release a 20.03 version.

Actually there are two git repos to look at, regarding the 20.03 docker
milestone, my bad.

For reference, here they are:
- https://github.com/moby/moby/milestone/76
- https://github.com/docker/cli/milestone/25


On Fri, Jul 17, 2020 at 1:08 PM El boulangero 
wrote:

> Hey Reinhard,
>
> glad that you could find a way without patching docker :)
>
> I'd prefer not to patch docker for other packages, especially when it's
> not trivial like this.
>
> The milestone page https://github.com/docker/cli/milestone/25?closed=1
> seems to indicate that docker is close to release a 20.03 version. That
> would be great news, and would solve this kind of problems.
>
> Best,
>
>   Arnaud
>
>
> On Fri, Jul 17, 2020 at 8:27 AM Reinhard Tartler 
> wrote:
>
>> On 7/16/20 10:06 AM, Reinhard Tartler wrote:
>>
>> > In order to get podman 2.0 to build, I had to backport some changes to
>> > the golang-github-docker-docker-dev package.
>>
>> Actually, never mind, I managed to patch podman 2.0 to not require these
>> backports:
>>
>> https://salsa.debian.org/debian/libpod/-/blob/experimental/debian/patches/old-docker-api.patch
>>
>> it's probably not ideal, but at least allows podman 2.0 to compile. I'll
>> let you decide
>> how to proceed with this bug.
>>
>> -rt
>>
>

Bug#942550: Move /usr/sbin/sendmail symlink to mstmp package

[El boulangero]

> msmtp-mta ships a minimal smtp daemon but it is (normally and on purpose)
> disabled by default so there is no daemon listening unless you enable it.

Ah indeed, that was not immediately clear to me. I just installed
msmtp-mta. The service is indeed disabled by default.

Thanks,

  Arnaud

On Fri, Jul 17, 2020 at 2:59 PM Emmanuel Bouthenot 
wrote:

> Hi,
>
> On Thu, Jul 16, 2020 at 09:36:17PM +0700, elboulang...@gmail.com wrote:
> > Is there anything wrong with the approach that Flavio suggests? It
> > also makes sense to me.
> msmtp-mta was created so that msmtp could be installed in parallel of a
> real MTA (see: #396527)
>
> > I'm considering to simply do `ln -sr /usr/bin/msmtp
> > /usr/sbin/sendmail` instead of installing msmtp-mta, because indeed, I
> > don't need a SMTP server, I just want to use msmtp as a drop-in
> > replacement for sendmail.
> That's the goal of msmtp-mta: provides sendmail compatibility without
> having to create symlinks manually.
>
> msmtp-mta ships a minimal smtp daemon but it is (normally and on purpose)
> disabled by
> default so there is no daemon listening unless you enable it.
>
> Regards,
>
> --
> Emmanuel Bouthenot
>   mail: kolter@{openics,debian}.orggpg: 4096R/0x929D42C3
>   xmpp: kol...@im.openics.org  irc: kolter@{freenode,oftc}
>

Bug#965123: docker.io: Please apply some upstream patches for podman 2.0

[El boulangero]

Hey Reinhard,

glad that you could find a way without patching docker :)

I'd prefer not to patch docker for other packages, especially when it's not
trivial like this.

The milestone page https://github.com/docker/cli/milestone/25?closed=1
seems to indicate that docker is close to release a 20.03 version. That
would be great news, and would solve this kind of problems.

Best,

  Arnaud


On Fri, Jul 17, 2020 at 8:27 AM Reinhard Tartler 
wrote:

> On 7/16/20 10:06 AM, Reinhard Tartler wrote:
>
> > In order to get podman 2.0 to build, I had to backport some changes to
> > the golang-github-docker-docker-dev package.
>
> Actually, never mind, I managed to patch podman 2.0 to not require these
> backports:
>
> https://salsa.debian.org/debian/libpod/-/blob/experimental/debian/patches/old-docker-api.patch
>
> it's probably not ideal, but at least allows podman 2.0 to compile. I'll
> let you decide
> how to proceed with this bug.
>
> -rt
>

Bug#955322: RFS: pulseaudio-dlna -- stream audio to DLNA devices and Chromecasts

[Muammar El Khatib]

On Mon, Mar 30, 2020 at 6:22 AM Fabian Wolff  wrote:
>
> Hi Adam and Muammar,
>
> thanks for your quick replies! Adam, thank you for looking over my changes and
> sponsoring the upload.
>
> One more thing: As I said in my original email, I have a Git repository set up
> for this package, but I don't have the necessary permissions to create a
> repository in the "Debian" group on Salsa, so could one of you (or somebody
> else) please create the repository and give me "Maintainer" access to it, so
> that I can push to it?
>
>   https://salsa.debian.org/debian/pulseaudio-dlna

Does it seem you already got access?

https://salsa.debian.org/debian/pulseaudio-dlna/-/commit/61d6ee13c13eb76cb6b70b6b50c2fb5efe04dc7f

Best,

-- 
Muammar El Khatib.
GPG Key = 71246E4A.
https://muammar.me
  ,''`.
 : :' :
 `. `'
   `-

Bug#947078: git-buildpackage: Need to make gbp clone pseudo protocols confgirable

[Ahmed El-Mahmoudy]

Package: git-buildpackage
Version: 0.9.17
Severity: normal

Dear Maintainer,

I have the following entry in ~/.ssh/config:
Host salsa salsa.debian.org
  User git
  Hostname salsa.debian.org
Host github github.com
  User git
  Hostname github.com

Yet, when running gbp clone salsa:group/project.git, gbp fetches from 
the HTTPS URL of salsa instead of the SSH URL. This happened after gbp 
0.9.17 added salsa to its pseudo protocols. So I had to manually comment 
thkse lines in scripts/clone.py to get the repo checked out from SSH 
URL.
I suggest making those pseudo protcols user configurable somehow.


-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#942085: RFS: hijra/0.4.1-2 [RC] -- Hijri Islamic Calendar converting functions for Python

[Ahmed El-Mahmoudy]

On Mon, Nov 11, 2019 at 01:50:18PM -0500, Jeremy Bicha wrote:
> Sorry: TabError: inconsistent use of tabs and spaces in indentation
> (HijriCal.py, line 83)
> dpkg: error processing package python3-hijra (--configure):
>  installed python3-hijra package post-installation script subprocess
> returned error exit status 1
> dpkg: dependency problems prevent configuration of hijra-applet:
>  hijra-applet depends on python3-hijra (= 0.4.1-2); however:
>   Package python3-hijra is not configured yet.

Working on it

> Thank you for adding me to the Salsa team as a Developer. I tried
> pushing a minor change to othman's packaging repo, but the repo
> settings are that only Maintainers can push to the master branch.
> Please allow Developers to push there too.

Done.

> I think there is a good chance that the hijra gnome-shell extension
> will work with the gnome-shell version in Testing. If so, please drop
> the upper gnome-shell dependency limit so that the gnome-shell
> extension will be installable.

Unfortunately, I cannot test this currently
-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#942556: RFS: hijra/0.4.1-2 [RC] -- Hijri Islamic Calendar converting functions for Python

[Ahmed El-Mahmoudy]

On Sat, Nov 02, 2019 at 08:40:28AM +0100, أحمد المحمودي (Ahmed El-Mahmoudy) 
wrote:
> On Tue, Oct 29, 2019 at 06:24:23AM -0400, Jeremy Bicha wrote:
> > I think hijra qualifies for auto-building. My understanding of the
> > preferred process is:
> > 1. First add the required field to debian/control
> 
> Done
---end quoted text---

I also done this for othman package, I hope you would sponsor it too.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#942085: RFS: hijra/0.4.1-2 [RC] -- Hijri Islamic Calendar converting functions for Python

[Ahmed El-Mahmoudy]

On Sat, Nov 02, 2019 at 05:27:35AM -0400, Jeremy Bicha wrote:
> Yes, I will sponsor this for you.
Thanks.

> In this case, I see the new tag has already been pushed so I wouldn't
> worry about it here.

Since you didn't upload yet, I made a couple of changes and pushed a
new tag.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#942085: RFS: hijra/0.4.1-2 [RC] -- Hijri Islamic Calendar converting functions for Python

[Ahmed El-Mahmoudy]

On Tue, Oct 29, 2019 at 06:24:23AM -0400, Jeremy Bicha wrote:
> Please see the second link in this Lintian tag description.
> 
> https://lintian.debian.org/tags/source-only-upload-to-non-free-without-autobuild.html
> 
 
Quoting section 5.10.5 of developers ref.:
"1. Check wehther it is legally allowed and technically possible to 
auto-build the package"

How do I check that it is legally allowed to build the non-free package ?

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#942085: RFS: hijra/0.4.1-2 [RC] -- Hijri Islamic Calendar converting functions for Python

[Ahmed El-Mahmoudy]

On Tue, Oct 29, 2019 at 06:24:23AM -0400, Jeremy Bicha wrote:
> I think hijra qualifies for auto-building. My understanding of the
> preferred process is:
> 1. First add the required field to debian/control

Done

> 2. Do a binary upload of the package.

Can't do binary upload since it adds a new package, and I am not a DD

> 3. Ask for auto-builds to be enabled
> 4. After all that is done, the next upload can be source-only.
> 
> If that sounds good with you, could you make the change and then bump
> the Debian version number? (There is no need to try to re-use the
> tagged version number; there are lots of higher version numbers we can
> use!).
---end quoted text---

I didn't bump the debian version number. Why should I do so ?

If it alright with you, please upload.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#942167: RFS: okasha/0.2.4-4 [RC]

[Ahmed El-Mahmoudy]

Package: sponsorship-requests
Severity: important
 
Hello,

Please sponsor the updated package okasha 0.2.4-4.

It fixes the following RC bug:
#940198 (serious): python3-okasha-examples: missing Breaks+Replaces: 
python-okasha-examples

The latest entry in the Debian changelog is:

okasha (0.2.4-4) unstable; urgency=medium

  * Add Breaks+Replaces: python-okasha-examples (Closes: #940198)
  * py3.diff: add fix for string + utf8 concatenation


As required, I tested the package against unstable's version of lintian and it
it reports:
I: okasha source: testsuite-autopkgtest-missing


To access further information about this package, please visit the 
following URL:
 
   https://mentors.debian.net/package/okasha

Alternatively, it is available on Salsa:
g...@salsa.debian.org:python-team/modules/okasha.git

also, one can download the package with dget using this command:
 
dget -x 
https://mentors.debian.net/debian/pool/non-free/o/okasha/okasha_0.2.4-4.dsc

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#939769: RM: geda-xgsch2pcb -- ROM; Unmaintained by upstream

[Ahmed El-Mahmoudy]

Package: ftp.debian.org
Severity: normal

xgsch2pcb hasn't been maintained by upstream for the last 10 years.

I have contacted upstream, and one of the gED Aupstream developers 
confirmed saying:
 
I think it's currently unmaintained.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#769706: helllo

[Registraduria El Charco - Nariño]

Good day to you sir, My boss said that you should contact him via this email( 
tio...@gmail.com ) that he has some important to discuss with you.

?

?



Confidencialidad: La información contenida en este mensaje de e-mail y sus 
anexos, es confidencial y está reservada para el destinatario únicamente. Si 
usted no es el destinatario o un empleado o agente responsable de enviar este 
mensaje al destinatario final, se le notifica que no está autorizado para 
revisar, retransmitir, imprimir, copiar, usar o distribuir este e-mail o sus 
anexos. Si usted ha recibido este e-mail por error, por favor comuníquelo 
inmediatamente vía e-mail al remitente y tenga la amabilidad de borrarlo de su 
computadora o cualquier otro banco de datos. Muchas gracias.

Confidentiality Notice: The information contained in this email message, 
including any attachment, is confidential and is intended only for the person 
or entity to which it is addressed. If you are neither the intended recipient 
nor the employee or agent responsible for delivering this message to the 
intended recipient, you are hereby notified that you may not review, 
retransmit, convert to hard copy, copy, use or distribute this email message or 
any attachments to it. If you have received this email in error, please contact 
the sender immediately and delete this message from any computer or other data 
bank. Thank you.

Bug#926182: guile-2.2: autoreconf'ed scripts using guile.m4 cannot find guild & guile-config/tools

[Ahmed El-Mahmoudy]

Package: guile-2.2
Version: 2.2.4+1-1
Severity: normal

Building gwave against guile-2.2 fails if gwave runs dh_autoreconf, that 
is bexause the autoreconf'ed configure script fails to find guild 
and guile-config/tools binaries, relevant configure log below:

configure: checking for guile 2.2
configure: found guile 2.2
checking for guile-2.2... /usr/bin/guile-2.2
checking for Guile version >= 2.2... 2.2.4
checking for guild-2.2... no
checking for guile-config-2.2... no
checking for guile-tools-2.2... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for GUILE... yes
configure: error: 'guild' binary not found; please check your guile-2.x 
installation.

The problem is because after autoreconf, the configure script searches 
for guild with the -2.2 suffix, yet the guile-2.2-dev package installs 
guild without that suffix, although guile binary has the -2.2 suffix in 
guile-2.2 package. Yet in /usr/share/aclocal/guile.m4 it says:

# @code{guile} is still not found, signal an error. The suffix, if any,
# that was required to find @code{guile} will be used for @code{guild}
# as well.

Hence,I beleive that that there is an issue with guile-2.2 package. 
Either the guild & guile-config/tools binaries shpuld be insyalled with 
-2.2 suffix (probably installing symlinks with no suffix to the 
respective -2.2 suffixed binaries), or the guile.m4 script needs to be 
fixed.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#922804: makehuman: FTBFS (Could not import extension sphinx.ext.pngmath)

[Muammar El Khatib]

Hi,

On Sun, Feb 24, 2019 at 2:45 PM Andreas Tille  wrote:
>
> Hi,
>
> I plan to fix this in a NMU once I've importet the packaging to Salsa.
>
> Kind regards
>
> Andreas.
>
> --
> http://fam-tille.de


I really appreciate this. I don't have much time recently to work on
it. But I don't want to leave Debian :S I hope I can work more when I
get more stable with my job.

Best,

-- 
Muammar El Khatib.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#919646: makehuman: File base.obj is missing

[Muammar El Khatib]

Hi Vangelis, and Adrian,

On Thu, Feb 7, 2019 at 8:12 AM Adrian Bunk  wrote:
>
> On Fri, Jan 18, 2019 at 10:46:22AM +0200, Vangelis Skarmoutsos wrote:
> > Package: makehuman
> > Version: 1.1.1-1
> > Severity: grave
> > Justification: renders package unusable
> >
> > Dear Maintainer,
> >
> > When trying to start Makehuman by clicking on the gnome's corresponding icon
> > the welcome screen appeared with the message:
> >  "Unable to load obj file: data/3dobjs/base.obj"
> > and nothing more happened.
> > When I clicked on that window, it closed and nothing else appeared.
> >
> > I was expecting the application to start with its full interface.
> >
> > The application has the same behavior if uninstalled (purge) and installed
> > again.
> >
> > Using
> >  $ sudo find / -iname "base.obj"
> > does not find this file on the system.
>
> The file is /usr/share/makehuman/data/3dobjs/base.npz
>
> Is this file present on your sytem?
>
> Does removing+reinstalling of makehuman-data help?

I will have to check this to confirm whether or not the problem is
related to the package actually not including that file.

Adrian, I was thinking to move makehuman to a git repository to ease
team-maintenance. I recently don't have too much time for my Debian
duties.

Does that sound that good for you?

Best,


-- 
Muammar El Khatib.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#866653: RFS: thawab 4.1-1 [UPDATE]

[Ahmed El-Mahmoudy]

On Thu, Nov 29, 2018 at 04:46:10AM -0500, Jeremy Bicha wrote:
> Is the new license finished? I'm curious what it says.
---end quoted text---

Sorry for the late reply.
The Arabic (which is the authoritative) version is done:
https://github.com/ojuba-org/waqf/2.0/AR

I am almost done with the english translation:
https://github.com/ojuba-org/waqf/2.0/EN
but I am not sure my efforts in translation are precise from legal point 
of view.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#866653: RFS: thawab 4.1-1 [UPDATE]

[Ahmed El-Mahmoudy]

as-salamu alaykom,

On Sat, Nov 24, 2018 at 11:14:46AM -0500, Jeremy Bicha wrote:
> I could upload othman today (it will need to go through the NEW queue)
> but I prefer to wait until after you start the autobuild process. That
> way, we will not have this issue again for othman.
---end quoted text---

Thanks for uploading othman, I re-uploaded thawab now.
I didin't do the autobuild thing for 2 reasons:
1. It didn't work with slmodem, although I did get the permission years 
ago !
2. thawab, othman & probably hijra will migrate to a new Waqf version, 
which I beleive is DFSG compliant.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#909822: mkchromecast: Should probably depend on pulseaudio-utils

[Muammar El Khatib]

Hi,

On Fri, Oct 12, 2018 at 4:13 AM Andreas Henriksson  wrote:
>
> Hi,
>
> Chiming in here because I'd like to just suggest an alternative
> that might be more in line with how other packages are layed out
> and thus how users might expect things to work.
>
> On Thu, Oct 11, 2018 at 04:24:16PM -0400, Muammar El Khatib wrote:
> > On Sat, Sep 29, 2018 at 3:33 AM Ruben Undheim
> >  wrote:
> [...]
> > > I get an error saying 'pactl' cannot be found when
> > > starting. Solved it by installing pulseaudio-utils.
> > >
> >
> > The package suggests mkchromecast-pulseaudio:
> [...]
>
> I think I understand how you layed out the package.
> You expect the user to pick a particular special version that suits
> their needs from mkchromecast-* and install that. Then that pulls in the
> common (mkchromecast) package.
>
> If a package has the bulk of the program, but users are not expected to
> directly install it but rather have it pulled in via a dependency then
> usually the package name gets a -common postfix, ie. in your current
> layout you could have named mkchromecast mkchromecast-common instead.
>
> Going back a bit and looking at the bigger picture again I find your
> current layout not how packages in debian normally are layed out.
> Normally I find that the main package (mkchromecast here) instead has
> alternative dependency on the different backends, eg. mkchromecast would:
> Depends: mkchromecast-pulseaudio | mkchromecast-alsa | mkchromecast-gstreamer
>
> (Or in which ever order you prefer, listing the recommended and best
> supported backend as the first alternative.)
>
> (And to avoid circular dependencies, the mkchromecast-* package would
> have to drop or demote the Dependency on mkchromecast to a Recommends.)
>
> This way the users can just pull the package named after the program and
> end up having the recommeded backend pulled in for them.
>
> With this package layout you avoid ever having an uninformed user
> ending up with installing a package and having it 'not working'.
> If they install mkchromecast they get the recommended backend with it.
> If they install a particular mkchromecast-* the recommends will pull
> in the mkchromecast package. (And if they disable installing recommends
> then they are expected to pay attention or they get to keep all their
> broken pieces. eg. apt install mkchromecast mkchromecast-gstreamer would
> given them the non-default backend without pulling in the
> recommended/first alternative dependency.)
>

Your explanation makes lots of sense for me. Just to clarify this layout:

1) mkchromecast-common would contain all needed files to make things
functional meaning the python module itself and things in /usr/bin/.
2) There will be other mkchromecast-* packages e.g.:
mkchromecast-pulseaudio; mkchromecast-alsa, and mkchromecast-gstreamer
and those ones will pull out dependencies to make the package work for
each of those audio servers.  Basically, instead of doing an `apt
install mkchromecast`, users would need to do `apt install
mkchromecast-something`.

Is that what you meant? If that is correct, then I think that the
package `mkchromecast` does not have to be provided at all. I would
like just to confirm these things before I go and change the
packaging.

Thanks for this idea Andreas.

Best,

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#909822: mkchromecast: Should probably depend on pulseaudio-utils

[Muammar El Khatib]

Hi Ruben,

On Sat, Sep 29, 2018 at 3:33 AM Ruben Undheim
 wrote:
>
> Package: mkchromecast
> Version: 0.3.8.1-1
> Severity: normal
>
> Dear Maintainer,
>
> I get an error saying 'pactl' cannot be found when
> starting. Solved it by installing pulseaudio-utils.
>

The package suggests mkchromecast-pulseaudio:


```
Package: mkchromecast-pulseaudio
Version: 0.3.8.1-1
State: not installed
Priority: optional
Section: sound
Maintainer: Muammar El Khatib 
Architecture: all
Uncompressed Size: 16.4 k
Depends: pavucontrol, pulseaudio-utils, pulseaudio, mkchromecast
Description: Pulseaudio dependencies to cast with mkchromecast
 This dependency package contains an informational list of packages
which are considered essential for using mkchromecast together with
pulseaudio sound server. This package also depends on
 the packages on that list.
Homepage: http://mkchromecast.com
Tags: admin::hardware, role::plugin, works-with::audio
```

Taking a closer look at the description of Mkchromecast there is the
following text:

```
 mkchromecast can cast using either pulseaudio or ALSA. The respective
dependencies can be pulled by mkchromecast-pulseaudio and
mkchromecast-alsa dependency packages respectively. For more
 information, please read the README.Debian file shipped in this package.
```

I think this bug should be closed. Let me know what you think.

Best,

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#620507: ITA: eterm -- Enlightened Terminal Emulator

[Muammar El Khatib]

Hi José,

On Mon, Sep 10, 2018 at 1:36 PM Jose Antonio Jimenez Madrid
 wrote:
>
> retitle 620507 ITA: eterm -- Enlightened Terminal Emulator
> owner 620507 !
> thanks
>
>
> Hi,
>
> long time has passed since I tried to adopt this package. After reading
> some documentation I think I am in good shape to
> adopt this package by applying some patches to close several bugs.


Please, feel free to take over Eterm. If you need any help to get it
uploaded on Debian, just let me know.

Best,


-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#907530: dicoweb: Problems after dicoweb installation

[Ahmed El-Mahmoudy]

Package: dicoweb
Version: 2.3-2
Severity: important

Reporting on behalf of  Власенко Михаил Викторович 

> I did a dicoweb installation on a VDS with Debian 9.
> Python Version:  2.7.13
> Django Version:  1.10.7
> The web address for this machine is: https://dict.bible.ru/
> Connect to the web site and look at the debugger log, I can not
> understand on my own what's wrong. 
> Maybe it's some kind of bug in dicoweb? I am confused by the fact
> that the file /usr/share/dicoweb/dicoweb.wsgi is missing. I copied
> it from the old version.
> 
> I zip a copy of the debugger log located in the DicowebLog.html
> file and send as an attachment. 
> Regards.
> 
> ... Michael

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


debuglog.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#906033: qa.debian.org: dmd is failing

[Ahmed El-Mahmoudy]

Package: qa.debian.org
Severity: normal
usertag: udd
user: qa.debian@packages.debian.org
Dear Maintainer,


When I try to access  
https://udd.debian.org/dmd/?aelmahmoudy%40users.sourceforge.net#todo I 
get a 500 Internal Server Error. This only started to happen today. Yhe 
site was working well yesterday.

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

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

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#902385: blacs-pvm-test: depends on removed package blacs-test-common

[Muammar El Khatib]

Hi Ansgar,

On Mon, Jun 25, 2018 at 3:00 PM Ansgar Burchardt  wrote:
>
> Package: blacs-pvm-test
> Version: 1.1-21+b1
> Severity: serious
>
> blacs-pvm-test depends on blacs-test-common which was just removed
> (#886711).
>
> I wonder if blacs-pvm is still useful? pvm was orphaned (#824403) and I
> don't know anyone still using PVM for parallel computations.
>

Given that blacs-test-common was removed and honestly PVM does not
seem to be used for parallel computing, it makes lots of sense to me
that blacs-pvm should be removed, too.  By the way, I have just seen
it's been marked as AUTORM and will be removed anyway. Then, no
actions to take it back into Debian archive might be the right thing
to do.


Best,

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#893861: thawab: Intent to remove from Debian

[Ahmed El-Mahmoudy]

On Thu, May 03, 2018 at 07:49:18AM -0400, Jeremy Bicha wrote:
> If we don't hear back immediately, I will be converting this bug into
> a Debian removal bug for thawab very soon.
---end quoted text---

Sorry for the late reply.
I have filed a bug upstream about this months ago. Still waiting for the 
reply.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#880849: Snowball analyzer missing

[Ahmed El-Mahmoudy]

Package: liblucene3-contrib-java
Severity: normal

Hello,

  Snowball analyzer is missing from lucene3 java packages, althougb upstream
  website mentions that Snowball analyzer as part of the API: 
 
https://lucene.apache.org/core/3_0_3/api/contrib-snowball/org/apache/lucene/analysis/snowball/SnowballAnalyzer.html

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: Digital signature

Bug#879656: RFS: libkal/0.9.0-2

[Ahmed El-Mahmoudy]

Package: sponsorship-requests
Severity: normal

Hello,

I am looking for a sponsor for the updated package libkal/0.9.0-2. Also please 
grant me upload
rights for the package (I am a DM).

* Package name: libkal
  Version : 0.9.0-2
  Upstream Author : Petr Tomasek <toma...@etf.cuni.cz>
* URL : http://www.etf.cuni.cz/~tomasek/pub/my/
* License : LGPL-2+
  Section : libs

It builds those binary packages:

  libkal-dev - library for converting dates between various calendar systems

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/libkal

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/libk/libkal/libkal_0.9.0-2.dsc

The package can be found on Git:
ssh://git.debian.org/git/collab-maint/libkal.git


Changes since the last upload:

libkal (0.9.0-2) unstable; urgency=low

  * debian/rules: simplify rules file
  * Removed debian/libkal-dev.{dirs|install}
  * Add Depends: ${misc:Depends} to libkal-dev
  * Update my email address
  * Bump compat level to 10
  * Update standards version to 4.1.1
  * Changed Vcs-* fields to secure canonical URLs
  * Changed priority to optional
  * Update copyright format & years
  * Switch to 3.0 (quilt) source format
  * Fix spelling errors in package description.
Thanks to Jakub Wilk <jw...@debian.org> (Closes: #801235)


As required, I tested the package against unstable's version of lintian and it
is lintian clean.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: Digital signature

Bug#790803: ITP: neural -- machine-learning for atomistics

[Muammar El Khatib]

Hi,

On Thu, Jul 16, 2015 at 7:53 AM, Andreas Tille <andr...@an3as.eu> wrote:
>
> I think this ITP is relevant for Debian Science and DebiChem.  I guess
> you intend to maintain it in one of these teams.  Please make sure it
> will be added to the according Blends tasks (I'm fine if you tell me to
> what task what binary package should be added).
>
> It would be nice if you would CC the relevant teams in the beginning
> (and sorry if I missed the announcement).
>
> Thanks for this ITP.

I have a Debian package done for Amp¹ that I built inspired by
Graham's previous packaging that I plan to upload after this latest
Debian release.  I think Debian Science is a good fit for it. I am
very interested in this program because I am currently doing my
postdoc in the group where it is developed and I am working on it a
lot. I will start by moving the repo to /git/debian-science/packages/.

Best,

1. https://anonscm.debian.org/git/collab-maint/amp.git/
-- 
Muammar El Khatib.
http://muammar.me

Bug#790803: ITP: Amp -- atomistic machine-learning potentials

[Muammar El Khatib]

Control: retitle 790803 ITP: Amp -- atomistic machine-learning potentials
Control: owner 790803 !

thanks,

I am trying for the third time because for some reason the BTS is not recording
my changes.

--
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#790803: ITP: Amp -- atomistic machine-learning potentials

[Muammar El Khatib]

retitle 790803 ITP: Amp -- atomistic machine-learning potentials
owner 790803 muam...@debian.org
thanks

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#790803: ITA Amp -- atomistic machine-learning potentials

[Muammar El Khatib]

retitle 790803 ITA: Amp -- atomistic machine-learning potentials
owner 790803 !
thanks,


--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org


signature.asc
Description: PGP signature

Bug#798816: add support for splitting gog.com Quake 1 CD tracks

[El Jefe]

I love Quake so this is cool. Go right ahead, but please keep in mind that
my code is very barebones.

On Sat, Apr 22, 2017 at 6:30 AM Alexandre Detiste <
alexandre.deti...@gmail.com> wrote:

> Hi,
>
> I found this nice piece of code of yours:
>https://github.com/libjared/cue-rip-wav/blob/master/cuerip.py
>
> I'm going to merge it into game-data-packager to allow
> to turn ISO images provided by GOG.com into Ogg files.
>
>   477   904c3b60ea72df51529f5f2e7338ccd4 game.cue
>   767725728 f91e5688efd91eefc6d42c6626cb89a4 game.gog
>
> "Resistance is futile you will be assimilated :-)"
>
> BTW this is common usability complaint, see comments here,
> so this should be apppreciated:
>  https://www.youtube.com/watch?v=m0XOKSat57Q
>
> Greets,
>
> Alexandre Detiste
>

Bug#857835: src:linux: hid-chicony on Asus W2000 k+m set: keyboard works, mouse don't

[el es]

Hello Maintainers,

I enabled hid debug=2 in /etc/modprobe.d/hid.conf and then dmesg looks like 
(pasted below inline) :

On Wed, 15 Mar 2017 13:45:38 + el_es  wrote:
> Package: linux-source-3.16
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> My system is
> 
> > uname -a
> Linux george 3.16.0-0.bpo.4-686-pae #1 SMP Debian 3.16.39-1+deb8u1~bpo70+1
> (2017-02-24) i686 GNU/Linux
> (using wheezy-backports)
> 
> I have this set of Keyboard and Mouse wireless devices:
> https://www.asus.com/us/Keyboards-Mice/ASUS-W2000-Chiclet-Wireless-Keyboard-
> and-Mouse-Set/
> with single USB receiver for both.
> 
> It is reported by dmesg like this, when the sets' receiver is plugged into a
> USB port:
> 
> [17303.968026] usb 3-2: new full-speed USB device number 10 using uhci_hcd
> [17304.155093] usb 3-2: New USB device found, idVendor=04f2, idProduct=1123
> [17304.155101] usb 3-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [17304.155107] usb 3-2: Product: Wireless Device
> [17304.155111] usb 3-2: Manufacturer: Chicony
> [17304.162117] input: Chicony Wireless Device as
> /devices/pci:00/:00:1d.1/usb3/3-2/3-2:1.0/0003:04F2:1123.0012/input/input21
> [17304.162409] chicony 0003:04F2:1123.0012: input,hidraw2: USB HID v1.11
> Keyboard [Chicony Wireless Device] on usb-:00:1d.1-2/input0
> [17304.168052] chicony 0003:04F2:1123.0013: usage index exceeded
> [17304.168062] chicony 0003:04F2:1123.0013: item 0 2 2 2 parsing failed
> [17304.168100] chicony: probe of 0003:04F2:1123.0013 failed with error -22
> [17304.171949] chicony 0003:04F2:1123.0014: hiddev0,hidraw3: USB HID v1.11
> Device [Chicony Wireless Device] on usb-:00:1d.1-2/input2
> 
> Hopefully this helps.
> 
After setting hid debug=2 (or =3), on wireless receiver insert:

[19746.836055] usb 5-1: new full-speed USB device number 3 using uhci_hcd
[19747.027055] usb 5-1: New USB device found, idVendor=04f2, idProduct=1123
[19747.027062] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[19747.027067] usb 5-1: Product: Wireless Device
[19747.027072] usb 5-1: Manufacturer: Chicony
[19747.030186] /build/linux-VJL009/linux-3.16.39/drivers/hid/usbhid/hid-core.c: 
HID probe called for ifnum 0
[19747.033918] /build/linux-VJL009/linux-3.16.39/drivers/hid/usbhid/hid-core.c: 
submitting ctrl urb: Set_Report wValue=0x0200 wIndex=0x wLength=1
[19747.034147] input: Chicony Wireless Device as 
/devices/pci:00/:00:1d.3/usb5/5-1/5-1:1.0/0003:04F2:1123.0009/input/input54
[19747.034602] chicony 0003:04F2:1123.0009: input,hidraw1: USB HID v1.11 
Keyboard [Chicony Wireless Device] on usb-:00:1d.3-1/input0
[19747.034750] /build/linux-VJL009/linux-3.16.39/drivers/hid/usbhid/hid-core.c: 
HID probe called for ifnum 1
[19747.040590] chicony 0003:04F2:1123.000A: usage index exceeded
[19747.040598] /build/linux-VJL009/linux-3.16.39/drivers/hid/hid-core.c: 
hid_add_usage failed
[19747.040605] chicony 0003:04F2:1123.000A: item 0 2 2 2 parsing failed
[19747.040639] chicony: probe of 0003:04F2:1123.000A failed with error -22
[19747.040803] /build/linux-VJL009/linux-3.16.39/drivers/hid/usbhid/hid-core.c: 
HID probe called for ifnum 2
[19747.042474] /build/linux-VJL009/linux-3.16.39/drivers/hid/usbhid/hid-core.c: 
submitting ctrl urb: Get_Report wValue=0x0304 wIndex=0x0002 wLength=32
[19747.044455] chicony 0003:04F2:1123.000B: hiddev0,hidraw2: USB HID v1.11 
Device [Chicony Wireless Device] on usb-:00:1d.3-1/input2
[19747.093142] /build/linux-VJL009/linux-3.16.39/drivers/hid/usbhid/hid-core.c: 
submitting ctrl urb: Set_Report wValue=0x0200 wIndex=0x wLength=1

(same happens when inserted  into other USB ports of this machine)

There are FN buttons on this keyboard which don't work as intended either (but 
it's not the biggest problem,
because keyboard is otherwise usable;

- i saw some advice on how to fix those, e.g. 
https://bugzilla.redhat.com/attachment.cgi?id=1053623=diff,

haven't tried that however;

others like https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1064490 seem 
to suggest to increase 

  In /usr/src/linux/include/linux/hid.h

  #define HID_MAX_USAGES 12288 
to something rather more large like 32k or more; 

Haven't tried that either.

also the 'parsing failed' message shows for the keyboard (which would be in 
line with the special keys not working)
but the mouse is only detected as a 'Wireless Device' and not assigned to input 
(hiddev0,hidraw2) ?

I could try recompiling the modules required (not really willing to recompile 
the entire kernel as this is my daily work machine)
with any patches suggested;

Thanks in advance,

Kind Regards
Lukasz Sokol

> 
> 
> -- System Information:
> Debian Release: 7.11
>   APT prefers oldstable
>   APT policy: (500, 'oldstable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.16.0-0.bpo.4-686-pae (SMP w/2 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> 

Bug#854228: Libraries not linked with their deps

[Muammar El Khatib]

Dear all,

On Mon, Mar 20, 2017 at 11:03 PM, Drew Parsons <dpars...@debian.org> wrote:
> Probably the solution we want is to update our scalapack to 2.0.2, and
> remove this blacs package, at least as a separate source package. That
> won't happen for stretch, obviously.

I am sorry for the delay in replying to this report. I am right now
preparing to upload a Debian revision that adds the patch in #848813
for fixing the FTBFS.

Lately, I have had limited time to take care of ScaLAPACK, and I think
it is time to move it to team maintenance. I was thinking of
Debian-science. I have already sent an email to the mailing list.

Regards,
-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#857846: mkchromecast: Documentation incorrect refers to "python mkchromecast.py" invocation

[Muammar El Khatib]

Hi Chris,

On Wed, Mar 15, 2017 at 11:45 AM, Chris Lamb <la...@debian.org> wrote:
> Hi,
>
> The documentation (and help output) refers to running "python
> mkchromecast.py", whilst on Debian we are meant to just use
> /usr/bin/mkchromecast.
>
> I have no strong feelings either way, but I think the command and
> the documentation should at least be consistent. :)

I think your observation is correct. I should modify it to be more
consistent or at least adding a phrase saying that if using the debian
package, then the command is just a plain `mkchromecast`.


Thank you very much for your message :).


Best,

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#852531: mkchromecast-alsa: Depends on obsolete package alsa-base

[Muammar El Khatib]

Hi Jordi,

On Wed, Jan 25, 2017 at 09:44:12AM +0100, Jordi Mallach wrote:
> Package: mkchromecast-alsa
> Version: 0.3.6-3
> Severity: important
>
> Hi Muammar,
>
> Your package depends on alsa-base, which has been an empty, featureless
> package for many years.
>
> Please drop this dependency: what alsa-base did in the past is now done
> by kmod itself and hence you don't need to replace it with other
> dependencies.
>
> My goal is to get rid of alsa-base for stretch, so please upload even if the
> freeze is ongoing, I'll try to get an exception for your change.

Thanks for your report. I will update the dependency to kmod. I hadn't realized
what you are describing in this report since it's been long time I don't use
pure alsa on my laptop.


Regards,

--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#849762: mutt: complains about GPGME

[Muammar El Khatib]

mutt
patch-timeout-neomutt
patch-tls-sni-neomutt
patch-trash-neomutt

To learn more about NeoMutt, visit: http://www.neomutt.org/
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: <neomutt-de...@neomutt.org>


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

Kernel: Linux 4.9.0-rc8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mutt depends on:
ii  libassuan02.4.3-2
ii  libc6 2.24-8
ii  libcomerr21.43.3-1
ii  libgnutls30   3.5.8-1
ii  libgpg-error0 1.26-1
ii  libgpgme111.8.0-3
ii  libgssapi-krb5-2  1.15-1
ii  libidn11  1.33-1
ii  libk5crypto3  1.15-1
ii  libkrb5-3 1.15-1
ii  libncursesw5  6.0+20161126-1
ii  libnotmuch4   0.23.5-1
ii  libsasl2-22.1.27~101-g0780600+dfsg-2
ii  libtinfo5 6.0+20161126-1
ii  libtokyocabinet9  1.4.48-11

Versions of packages mutt recommends:
ii  libsasl2-modules  2.1.27~101-g0780600+dfsg-2
ii  locales   2.24-8
ii  mime-support  3.60

Versions of packages mutt suggests:
ii  aspell  0.60.7~20110707-3+b1
ii  ca-certificates 20161130
ii  gnupg   2.1.17-4
ii  ispell  3.4.00-5
pn  mixmaster   
ii  openssl 1.1.0c-2
ii  postfix [mail-transport-agent]  3.1.4-3
ii  urlview 0.9-20

Versions of packages mutt is related to:
ii  mutt  1.7.1-5

-- no debconf information

--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#828566: Proposed NMU

[Muammar El Khatib]

Dear Sergei,

On Mon, Nov 7, 2016 at 8:48 AM, Sergei Golovan <sgolo...@nes.ru> wrote:
> tags 828566 + patch
> thanks
>
> Hi, Muammar,
>
> I'd like to offer a patch which ports tcltls to the new Openssl 1.1.
> It's already forwarded upstream
> (https://sourceforge.net/p/tls/bugs/66/) though I don't know when it
> (or some other patch) will be accepted. The changes are mostly
> straightforward, the patch retains compatibility with OpenSSL 1.0, and
> the package passes regression tests.
>
> If you don't mind, I could do NMU for this bugfix.
>
> Cheers!

Please go ahead with the NMU. I am sorry for the delay, too much work
right now.

Thank you.

Regards,

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#790803: ITP: amp -- atomistic machine-learning potentials

[Muammar El Khatib]

On 10/24/2016 04:09 AM, Graham Inggs wrote:
>> That would be great!.
> I have sent it, let me know if you didn't receive it.
> 

I have received it correctly.

>> > I forgot to answer that. I would love to team-maintain scalapack in
>> > debian-science!. I do not have too much time for maintaining it  as it
>> > deserves. I will read the wiki of Debian science and request to be added to
>> > the group.
> Thanks!  Would you consider doing the same for blacs-mpi?

Yeap. For blacs libraries as well. I will try to do everything by
Wednesday. If I find any troubles with the transition to team-maintain
scalapack+blacs I will contact you.

Regards,

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#790803: ITP: amp -- atomistic machine-learning potentials

[Muammar El Khatib]

On 10/20/2016 03:28 AM, Graham Inggs wrote:

On 20 October 2016 at 02:50, Muammar El Khatib <muam...@debian.org> wrote:



Are you working on a git repo available in the debian platform?, if so, could 
you
point me out to it?. I will be playing around with amp in the following days and
I could help with the packaging.


No, but I do have a local packaging of neural (before the name changed
to amp) which was working, but since the project changed to amp and
was re-organized, it longer works and I don't know if any of it is
still relevant.  I can mail it to you privately, if you wish.



That would be great!.


While preparing to package amp, with the help of Marcin Dulak and Ask
Hjorth Larson, I did manage to get the prerequisites python-ase, gpaw
and gpaw-setups updated and into the archive.

BTW, I though I recognized your name from somewhere, would you mind
taking a look at #671380 ?



I forgot to answer that. I would love to team-maintain scalapack in 
debian-science!. I do not have too much time for maintaining it  as it 
deserves. I will read the wiki of Debian science and request to be added 
to the group.


Regards,
--
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#790803: ITP: amp -- atomistic machine-learning potentials

[Muammar El Khatib]

Hi Graham,

On Tue, Oct 18, 2016 at 05:33:42PM +0200, Graham Inggs wrote:
> Hi Muammar
>
> Sadly, this fell off my radar. :(


It's ok :).

>
> On 18 October 2016 at 17:00, Muammar El Khatib <muam...@debian.org> wrote:
> > I am interested in participating in the packaging of amp. I recently
> > joined Prof. Peterson's group as postdoctoral research associate at
> > Brown, and thus I will be involved in amp (use/development). I would
> > be glad if you let me know how I can help you with.
>
> I did have a problem with relative imports when running the tests.  I
> ended up repacking the tarball and moving some of the files and
> directories into a directory named amp which seemed to improve things.

I think there are some problems related to those imports, I will take a look at
that as well from here.

>
> Is v0.4.1 the version we should be working on, or can you tag
> something more recent?
>

I discussed with Peterson and Alireza, and there is a new version on the go
(v0.5.0, maybe in a month or something). What we could do is to work on
snapshots from master (that is the development branch). What do you think?.

Are you working on a git repo available in the debian platform?, if so, could 
you
point me out to it?. I will be playing around with amp in the following days and
I could help with the packaging.

Regards,
--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#790803: ITP: amp -- atomistic machine-learning potentials

[Muammar El Khatib]

Dear All,

On Fri, Nov 20, 2015 at 5:17 AM, Graham Inggs <gin...@debian.org> wrote:
> retitle 790803 amp -- atomistic machine-learning potentials
> owner 790803 gin...@debian.org
> thanks
>
> Upstream have relaunched Neural as Amp.
>
> * Package name: amp
>   Version : 0.3
>   Upstream Author : Andrew Peterson, Alireza Khorshidi
> * URL : https://bitbucket.org/andrewpeterson/amp
> * License : GPL-3.0+
>   Programming Lang: Python
>   Description : Atomistic Machine-learning Potentials
> Amp is an open-source package designed to easily bring machine-learning to
> atomistic calculations. This allows one to predict (or really, interpolate)
> calculations on the potential energy surface, by first building up a
> regression representation of a “train set” of atomic images. Amp calculator
> works by first learning from any other calculator (usually quantum
> mechanical calculations) that can provide energy and forces as a function of
> atomic coordinates. In theory, these predictions can take place with
> arbitrary accuracy approaching that of the original calculator.
> .
> Amp is designed to integrate closely with the Atomic Simulation Environment
> (ASE). As such, the interface is in pure python, although several
> compute-heavy parts of the underlying codes also have fortran versions to
> accelerate the calculations. The close integration with ASE means that any
> calculator that works with ASE - including EMT, GPAW, DACAPO, VASP, NWChem,
> and Gaussian - can easily be used as the parent method.
>
> I intend maintaining this package as part of the DebiChem team.
>
> I found there was a packaged named amp in Debian circa 2000; the Audio MPEG
> Player in non-free, but I don't believe this is a problem.
>

I am interested in participating in the packaging of amp. I recently
joined Prof. Peterson's group as postdoctoral research associate at
Brown, and thus I will be involved in amp (use/development). I would
be glad if you let me know how I can help you with.


Regards,
-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#835608: mkchromecast: fails to Open pavucontrol and select the mkchromecast sink.

[Muammar El Khatib]

Hi Cristian,

On Fri, Sep 16, 2016 at 1:53 PM, Cristian Ionescu-Idbohrn
<cristian.ionescu-idbo...@axis.com> wrote:
> Alright, found that myself and installed package 'python-flask'.
> Having done that, progress ;)
>
> Cast media controller status
>
> CastStatus(is_active_input=False, ..., status_text=u'Ready To Cast')
>
>
> Controls:
> =
>
> Volume up: u
> Volume down: d
> Quit the application: q or Ctrl-C
>
> 192.168.x.y - - [16/Sep/2016 13:40:45] "GET /stream HTTP/1.1" 200 -
>
> and sound out the TV speakers.  Fun :)
>

Cool to know it is working now!.

On Fri, Sep 16, 2016 at 2:27 PM, Cristian Ionescu-Idbohrn
<cristian.ionescu-idbo...@axis.com> wrote:
> One thing I noticed is that if I _first_ start mkchromecast and play
> some sound file _after_, the player (in this case mpg123) will bail
> out with:
>
> ,
> | [format.c:295] error: Unable to set up output format! Constraints: 44100, 
> 22050 or 11025Hz.
> | [mpg123.c:695] error: ...in decoding next frame: Unable to set up output 
> format! (code 1)
> `
>
> If I now kill (^C) mkchromecast, I get this trace:
>
> ,
> | 192.168.x.y - - [16/Sep/2016 14:01:07] "GET /stream HTTP/1.1" 200 -
> | Process Process-1:
> | Traceback (most recent call last):
> |   File "/usr/lib/python2.7/multiprocessing/process.py", line 258, in 
> _bootstrap
> | self.run()
> |   File "/usr/lib/python2.7/multiprocessing/process.py", line 114, in run
> | self._target(*self._args, **self._kwargs)
> |   File ".../mkchromecast/audio.py", line 523, in start_app
> | app.run(host= '0.0.0.0')
> |   File "/usr/lib/python2.7/dist-packages/flask/app.py", line 843, in run
> | run_simple(host, port, self, **options)
> |   File "/usr/lib/python2.7/dist-packages/werkzeug/serving.py", line 694, in 
> run_simple
> | inner()
> |   File "/usr/lib/python2.7/dist-packages/werkzeug/serving.py", line 659, in 
> inner
> | srv.serve_forever()
> |   File "/usr/lib/python2.7/dist-packages/werkzeug/serving.py", line 499, in 
> serve_forever
> | HTTPServer.serve_forever(self)
> |   File "/usr/lib/python2.7/SocketServer.py", line 233, in serve_forever
> | self._handle_request_noblock()
> |   File "/usr/lib/python2.7/SocketServer.py", line 292, in 
> _handle_request_noblock
> | self.handle_error(request, client_address)
> |   File "/usr/lib/python2.7/SocketServer.py", line 290, in 
> _handle_request_noblock
> | self.process_request(request, client_address)
> |   File "/usr/lib/python2.7/SocketServer.py", line 318, in process_request
> | self.finish_request(request, client_address)
> |   File "/usr/lib/python2.7/SocketServer.py", line 331, in finish_request
> | self.RequestHandlerClass(request, client_address, self)
> |   File "/usr/lib/python2.7/SocketServer.py", line 654, in __init__
> | self.finish()
> |   File "/usr/lib/python2.7/SocketServer.py", line 713, in finish
> | self.wfile.close()
> |   File "/usr/lib/python2.7/socket.py", line 283, in close
> | self.flush()
> |   File "/usr/lib/python2.7/socket.py", line 307, in flush
> | self._sock.sendall(view[write_offset:write_offset+buffer_size])
> | error: [Errno 32] Broken pipe
> `
>
> The terminal gets messed up and needs to be `reset'.
>

This is because of the https://github.com/joeyespo/py-getch module I
am using to listen to key events. Maybe I should come with my own
solution to avoid this. So, basically this happens when one uses the
`--volume` flag.

> If I first start the player and mkchromecast after, it works fine.
> I can stop and start the player as I please, no apparent troubles.

Thanks for this information. I cannot reproduce it though.

I have added a `--host` flag to specify the ip of the host you want
the google cast device to be connected. Additionally, there is now a
`--source-url` flag that MPD users can pass if they have a httpd local
streaming server or you can pass whatever source-url you want to play
to the google cast device (maybe cool for radio stations).

In the following upload  I will proceed to close this report. I would
like to thank you for all the feedback!.


Cheers,
-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#835608: mkchromecast: fails to Open pavucontrol and select the mkchromecast sink.

[Muammar El Khatib]

Hi Cristian,

On Fri, Sep 16, 2016 at 10:27:57AM +0200, Cristian Ionescu-Idbohrn wrote:
> Muammar,
>
> On Fri, 16 Sep 2016, Muammar El Khatib wrote:
> >
> > I hope you are still interested in this.
>
> Of course.
>

Nice!.

> > I have prepared a page in the wiki that you can check:
> >
> > https://github.com/muammar/mkchromecast/wiki/ALSA
> >
> > I would be glad if you could test it. Note that you have to checkout
> > the `alsa` branch.
>
> I would also be glad to do so, if I could figure out how ~/.asoundrc
> must look like.  Currently, the minimal conf to get sound out the
> audio card I prefer is:
>
> ,[ ~/.asoundrc ]
> | pcm.!default {
> | type plug
> | slave.pcm spdif
> | }
> `
>
> Here are some more details on the sound cards on my system:
>

I have prepared two .asoundrc files (asoundrc1 and asoundrc2). You may want to
download them and try them as your .asoundrc file.

> ,[ cat /proc/asound/cards ]
> |  0 [Live   ]: EMU10K1 - SB Live! 5.1 [SB0060]
> |   SB Live! 5.1 [SB0060] (rev.7, serial:0x80611102) at 
> 0xd000, irq 17

asoundrc1 for the case where this is the right card: hw:0,0 is the device.

> |  1 [PCH]: HDA-Intel - HDA Intel PCH
> |   HDA Intel PCH at 0xf723 irq 29

asoundrc1 for the case where this is the right card: hw:1,0 is the device.

>
> ,[ aplay -l ]
> |  List of PLAYBACK Hardware Devices 
> | card 0: Live [SB Live! 5.1 [SB0060]], device 0: emu10k1 [ADC 
> Capture/Standard PCM Playback]
> |   Subdevices: 32/32
> |   Subdevice #0: subdevice #0
> |   Subdevice #1: subdevice #1
> |   Subdevice #2: subdevice #2
> |   Subdevice #3: subdevice #3
> |   Subdevice #4: subdevice #4
> |   Subdevice #5: subdevice #5
> |   Subdevice #6: subdevice #6
> |   Subdevice #7: subdevice #7
> |   Subdevice #8: subdevice #8
> |   Subdevice #9: subdevice #9
> |   Subdevice #10: subdevice #10
> |   Subdevice #11: subdevice #11
> |   Subdevice #12: subdevice #12
> |   Subdevice #13: subdevice #13
> |   Subdevice #14: subdevice #14
> |   Subdevice #15: subdevice #15
> |   Subdevice #16: subdevice #16
> |   Subdevice #17: subdevice #17
> |   Subdevice #18: subdevice #18
> |   Subdevice #19: subdevice #19
> |   Subdevice #20: subdevice #20
> |   Subdevice #21: subdevice #21
> |   Subdevice #22: subdevice #22
> |   Subdevice #23: subdevice #23
> |   Subdevice #24: subdevice #24
> |   Subdevice #25: subdevice #25
> |   Subdevice #26: subdevice #26
> |   Subdevice #27: subdevice #27
> |   Subdevice #28: subdevice #28
> |   Subdevice #29: subdevice #29
> |   Subdevice #30: subdevice #30
> |   Subdevice #31: subdevice #31
> | card 0: Live [SB Live! 5.1 [SB0060]], device 2: emu10k1 efx [Multichannel 
> Capture/PT Playback]
> |   Subdevices: 8/8
> |   Subdevice #0: subdevice #0
> |   Subdevice #1: subdevice #1
> |   Subdevice #2: subdevice #2
> |   Subdevice #3: subdevice #3
> |   Subdevice #4: subdevice #4
> |   Subdevice #5: subdevice #5
> |   Subdevice #6: subdevice #6
> |   Subdevice #7: subdevice #7
> | card 0: Live [SB Live! 5.1 [SB0060]], device 3: emu10k1 [Multichannel 
> Playback]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 1: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 1: PCH [HDA Intel PCH], device 1: ALC892 Digital [ALC892 Digital]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 2: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 2: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 2: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 3: Controller [USB Audio Controller], device 0: USB Audio [USB Audio]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 4: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
> |   Subdevices: 8/8
> |   Subdevice #0: subdevice #0
> |   Subdevice #1: subdevice #1
> |   Subdevice #2: subdevice #2
> |   Subdevice #3: subdevice #3
> |   Subdevice #4: subdevice #4
> |   Subdevice #5: subdevice #5
> |   Subdevice #6: subdevice #6
> |   Subdevice #7: subdevice #7
> | card 4: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
> |   Subdevices: 8/8
> |   Subdevice #0: subdevice #0
> |   Subdevice #1: subdevice #1
> |   Subdevice #2: subdevice #2
> |   Subdevice #3: subdevice #3
> |   Subdevice #4: subdevice #4
> |   Subdevice #5: subdevice #5
> |   Subdevice #6: subdev

Bug#835608: mkchromecast: fails to Open pavucontrol and select the mkchromecast sink.

[Muammar El Khatib]

Hi Christian,

On Wed, Aug 31, 2016 at 9:13 AM, Cristian Ionescu-Idbohrn
<cristian.ionescu-idbo...@axis.com> wrote:
>
> Could you please heavily comment your proposed configuration so I can
> locate and modify the relevant bits, before testing again?

>
> It did capture a totally silent wav.  And I guess main reason is
> loopback device number.

I hope you are still interested in this. After reading a lot here and
there, I am writing this mail casting ti the chromecast using ALSA
instead of pulseaudio :). It works pretty well so far.  I decided to
uninstall pulseaudio and I gave it a try.

I have prepared a page in the wiki that you can check:

https://github.com/muammar/mkchromecast/wiki/ALSA

I would be glad if you could test it. Note that you have to checkout
the `alsa` branch.

Regarding the two interfaces in your machine, was the chromecast
detected? If yes, I think I can provide a flag where you can specify
the ip of the host.

Regards,
-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#822021: scalapack: Build arch:all+arch:any but is missing build-{arch,indep} targets

[Muammar El Khatib]

Hi Sebastiaan,

On Sun, Sep 11, 2016 at 04:25:26PM +0200, Sebastiaan Couwenberg wrote:
> On Tue, 26 Jul 2016 16:17:49 +0200 (CEST) Santiago Vila  wrote:
> > tags 822021 + patch
> > thanks
> >
> > I also recommend switching to dh, but in the meantime, the attached
> > patch should work.
>
> Muammar, please apply this patch and upload a new scalapack revision to
> unstable as soon as possible.
>
> scalapack binNMUes for the ongoing openmpi transition are failing
> because of this issue, and prevent building its many reverse dependencies.
>

I had already applied this patch:

scalapack (1.8.0-13) unstable; urgency=medium

  * Added missing build-{arch,indep} targets. Thanks to Santiago Vila for
providing a patch. Closes: #822021.
  * hppa architecture switched to openmpi. Closes: #834182.

 -- Muammar El Khatib <muam...@debian.org>  Mon, 05 Sep 2016 23:48:13 +0200

I am waiting for the openmpi upload of today that closes #837062 to proceed.


Cheers,
--
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#835608: mkchromecast: fails to Open pavucontrol and select the mkchromecast sink.

[Muammar El Khatib]

Hi Cristian,

On Sun, Aug 28, 2016 at 12:50:59PM +0200, Cristian Ionescu-Idbohrn wrote:
> On Sun, 28 Aug 2016, Muammar El Khatib wrote:
> >
> > That was the idea. After your report, I realized mkchromecast is
> > mostly useless in systems without pulseaudio right now. I will
> > remove that dependency in next releases.
>
> Great.
>
> > Yesterday, I was already playing with ffmpeg + ALSA to capture
> > audio, but I think it will be a complicated solution to implement
> > (cards' and devices' names may change from system to system).  I had
> > forgotten about GStreamer completely. Reading just a bit about it,
> > it may be a possible solution.
>
> Nice.
>
> I'll be watching this space and be ready to test mkchromecast again
> whenever possible.

Would you mind testing if this procedure makes possible to record your audio
using alsa?

1. Do
modprobe snd-aloop

2. Add the following content to ~/.asoundrc

pcm.!default {
  type asym
  playback.pcm "LoopAndReal"
  #capture.pcm "looprec"
  capture.pcm "hw:0,0"
}

pcm.looprec {
type hw
card "Loopback"
device 1
subdevice 0
}

pcm.LoopAndReal {
  type plug
  slave.pcm mdev
  route_policy "duplicate"
}

pcm.mdev {
  type multi
  slaves.a.pcm pcm.MixReale
  slaves.a.channels 2
  slaves.b.pcm pcm.MixLoopback
  slaves.b.channels 2
  bindings.0.slave a
  bindings.0.channel 0
  bindings.1.slave a
  bindings.1.channel 1
  bindings.2.slave b
  bindings.2.channel 0
  bindings.3.slave b
  bindings.3.channel 1
}

pcm.MixReale {
  type dmix
  ipc_key 1024
  slave {
pcm "hw:0,0"
rate 48000
#rate 44100
periods 128
period_time 0
period_size 1024 # must be power of 2
buffer_size 8192
  }
}

pcm.MixLoopback {
  type dmix
  ipc_key 1025
  slave {
pcm "hw:Loopback,0,0"
rate 48000
#rate 44100
periods 128
period_time 0
period_size 1024 # must be power of 2
buffer_size 8192
  }
}

3. Install ffmpeg, and execute this command while playing anything in your
   computer:

ffmpeg -f alsa -ac 2 -ar 44100 -i hw:0 -t 30 out.wav

Does ffmpeg capture the audio in out.wav?. I tested this in a Virtualbox using
debian with pure alsa (I was lazy, and didn't reconfigure everything in my own
laptop).  I think the procedure above did the trick but sound was crippled
(maybe related to Virtualbox).

Thanks.

--
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#835366: problem still present in 4.7.0-1-amd64

[Muammar El Khatib]

Package: src:linux
Version: 4.7.2-1
Followup-For: Bug #835366

I have upgraded the kernel today, and I modified /etc/default/grub to have
GRUB_CMDLINE_LINUX_DEFAULT="quiet". The computer freezed one hour after
rebooting, and temperature was fine.

I had to put back GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=1",
but the computer's temperature is warmer. It seems this problem hasn't been
fixed yet upstream.

Thanks,

-- Package-specific info:
** Version:
Linux version 4.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20160803 (Debian 5.4.1-1) ) #1 SMP Debian 4.7.2-1 (2016-08-28)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.7.0-1-amd64 
root=UUID=75585e40-e234-4d60-b037-74bd782714e1 ro quiet intel_idle.max_cstate=1

** Tainted: WOE (12800)
 * Taint on warning.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded (currently expected).

** Kernel log:
[6.805132] ACPI: Smart Battery System [SBS0]: Battery Slot [BAT0] (battery 
present)
[6.962896] hfsplus: Filesystem was not cleanly unmounted, running 
fsck.hfsplus is recommended.  mounting read-only.
[6.985462] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: 
(null)
[6.996380] EXT4-fs (sda7): mounted filesystem with ordered data mode. Opts: 
(null)
[7.216554] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Nov 10 
2015 06:38:10 version 7.35.177.61 (r598657) FWID 01-ea662a8c
[7.250198] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 
0x30)
[7.254661] brcmfmac :03:00.0 wlp3s0: renamed from wlan0
[7.851423] Console: switching to colour frame buffer device 320x100
[8.120174] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   11.108385] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   11.108390] Bluetooth: BNEP filters: protocol multicast
[   11.108395] Bluetooth: BNEP socket layer initialized
[   11.216038] vboxdrv: Found 4 processor cores
[   11.232707] vboxdrv: TSC mode is Invariant, tentative frequency 2899983921 Hz
[   11.232710] vboxdrv: Successfully loaded version 5.0.26 (interface 
0x0024)
[   11.437374] VBoxNetFlt: Successfully started.
[   11.439191] VBoxNetAdp: Successfully started.
[   11.441115] VBoxPciLinuxInit
[   11.442319] vboxpci: IOMMU not found (not registered)
[   13.544634] NET: Registered protocol family 4
[   13.547206] NET: Registered protocol family 3
[   13.548567] NET: Registered protocol family 5
[   13.605193] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   13.921411] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   14.429767] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   15.761448] brcmfmac: brcmf_cfg80211_escan_handler: scan not ready, 
bsscfgidx=0
[   15.761504] brcmfmac: brcmf_fweh_event_worker: event handler failed (69)
[   15.761548] brcmfmac: brcmf_cfg80211_escan_handler: scan not ready, 
bsscfgidx=0
[   15.761593] brcmfmac: brcmf_fweh_event_worker: event handler failed (69)
[   15.761636] brcmfmac: brcmf_cfg80211_escan_handler: scan not ready, 
bsscfgidx=0
[   15.761681] brcmfmac: brcmf_fweh_event_worker: event handler failed (69)
[   15.761723] brcmfmac: brcmf_cfg80211_escan_handler: scan not ready, 
bsscfgidx=0
[   15.761769] brcmfmac: brcmf_fweh_event_worker: event handler failed (69)
[   15.761811] brcmfmac: brcmf_cfg80211_escan_handler: scan not ready, 
bsscfgidx=0
[   15.761857] brcmfmac: brcmf_fweh_event_worker: event handler failed (69)
[   15.882858] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   27.738687] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   28.563607] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[   30.680706] [ cut here ]
[   30.680724] WARNING: CPU: 0 PID: 3659 at 
/build/linux-m2Twzh/linux-4.7.2/net/wireless/sme.c:1015 
cfg80211_connect+0x466/0x700 [cfg80211]
[   30.680725] Modules linked in: appletalk(E) ax25(E) ipx(E) p8023(E) p8022(E) 
psnap(E) llc(E) pci_stub(E) vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) 
vboxdrv(OE) bnep(E) msr(E) cpufreq_stats(E) binfmt_misc(E) nls_utf8(E) 
snd_hda_codec_hdmi(E) hfsplus(E) snd_hda_codec_cirrus(E) 
snd_hda_codec_generic(E) intel_rapl(E) x86_pkg_temp_thermal(E) 
intel_powerclamp(E) coretemp(E) joydev(E) iTCO_wdt(E) iTCO_vendor_support(E) 
applesmc(E) input_polldev(E) efi_pstore(E) bcm5974(E) hid_apple(E) btusb(E) 
btrtl(E) btbcm(E) btintel(E) evdev(E) bluetooth(E) kvm_intel(E) kvm(E) 
irqbypass(E) crct10dif_pclmul(E) brcmfmac(E) crc32_pclmul(E) brcmutil(E) 
ghash_clmulni_intel(E) i915(E) pcspkr(E) efivars(E) cfg80211(E) mmc_core(E) 
drm_kms_helper(E) snd_hda_intel(E) rfkill(E) thunderbolt(E) snd_hda_codec(E) 
drm(E) snd_hda_core(E)
[   30.680751]  mei_me(E) lpc_ich(E) snd_hwdep(E) i2c_algo_bit(E) 
intel_pch_thermal(E) snd_pcm(E) snd_timer(E) snd(E) i2c_i801(E) soundcore(E) 
mfd_core(E) mei(E) shpchp(E) sbs(E) sbshc(E) battery(E) acpi_als(E) 
kfifo_buf(E) industrialio(E) apple_bl(E) video(E) ac(E) tpm_tis(E) tpm(E) 
button(E) sg(E) sunrpc(E) 

Bug#835608: mkchromecast: fails to Open pavucontrol and select the mkchromecast sink.

[Muammar El Khatib]

On Sun, Aug 28, 2016 at 11:30:04AM +0200, Cristian Ionescu-Idbohrn wrote:
> On Sat, 27 Aug 2016, Muammar El Khatib wrote:
> >
> > I have now updated README.Debian.
>
> I see you added this:
>
>   Depends: ..., pavucontrol, pulseaudio-utils, pulseaudio
>
> but pulseaudio-utils isn't needed, as it is on the pulseaudio
> dependency list.
>

Thanks for the remark.

> In README.md, it might be a good idea to mention pavucontrol under
> Requirements:, Linux.

I will add it.

>
> > Yes, it assumes that pulseaudio is installed on the host.
>
> Right.  Now that pulseaudio is a dependency makes mkchromecast not
> installable on most of my systems, where pulseaudio is a no-no.
>

That was the idea. After your report, I realized mkchromecast is mostly useless
in systems without pulseaudio right now. I will remove that dependency in next
releases.

> > I may try to find another way for capturing the audio from alsa. But
> > in this sense, I am afraid mkchromecast would work as it does in
> > macOS where all system sound is casted. But let's give it a try.
>
> That will certainly be useful, in my case.
> I'm guessing here, as I lack deep knowledge, but gstreamer might be
> another alternative.  It's dealing with sinks too.  See:
>
>   gstreamer1.0-alsa - GStreamer plugin for ALSA
>   gstreamer1.0-pulseaudio - GStreamer plugin for PulseAudio

Thanks for this info!. Yesterday, I was already playing with ffmpeg + ALSA to
capture audio, but I think it will be a complicated solution to implement
(cards' and devices' names may change from system to system).  I had forgotten
about GStreamer completely. Reading just a bit about it, it may be a possible
solution.

Regards,
--
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#835608: mkchromecast: fails to "Open pavucontrol and select the mkchromecast sink."

[Muammar El Khatib]

Hi Cristian,

On Sat, Aug 27, 2016 at 04:57:01PM +0200, Cristian Ionescu-Idbohrn wrote:
> Package: mkchromecast
> Version: 0.3.5-1
> Severity: important
>
> First time run:
>
> $ LC_ALL=en_US.UTF-8 mkchromecast --debug --encoder-backend ffmpeg
> ('backends: ', ['ffmpeg', 'avconv', 'parec'])
> ('backends: ', ['ffmpeg', 'avconv', 'parec'])
> USER =foo
> PATH =/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> mkchromecast v0.3.5
> :::cast::: sockets method 192.168.98.55
> Creating pulseaudio sink...
> Open pavucontrol and select the mkchromecast sink.
> Traceback (most recent call last):
>   File "/usr/bin/mkchromecast", line 34, in 
> create_sink()
>   File "/usr/share/mkchromecast/mkchromecast/pulseaudio.py", line 28, in 
> create_sink
> stderr=subprocess.PIPE
>   File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
> errread, errwrite)
>   File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
> raise child_exception
> OSError: [Errno 2] No such file or directory
>
> /usr/share/doc/mkchromecast/README.Debian informs:
>
> 3. In order to cast you have to install pavucontrol, and select the
>mkchromecast sink.
>
> But /usr/share/mkchromecast/mkchromecast/pulseaudio.py seems to expect
> commands pactl and pacmd to be available.  Those commands are
> distributed in package pulseaudio-utils, not pavucontrol.
>

I have now updated README.Debian.

> Removing pavucontrol and installing pulseaudio-utils takes me further
> to:
>
> $ LC_ALL=en_US.UTF-8 mkchromecast --debug --encoder-backend ffmpeg
> ('backends: ', ['ffmpeg', 'avconv', 'parec'])
> ('backends: ', ['ffmpeg', 'avconv', 'parec'])
> USER =foo
> PATH =/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> mkchromecast v0.3.5
> :::cast::: sockets method 192.168.98.55
> Creating pulseaudio sink...
> Open pavucontrol and select the mkchromecast sink.
> Starting local streaming server
> [Done]
> (':::audio::: chunk_size: ', 1024)
> Selected backend: ffmpeg
> Selected audio codec: mp3
> Default bitrate used: 192k
> Default sample rate used: 44100Hz
> :::audio::: command ['ffmpeg', '-ac', '2', '-ar', '44100', '-f', 'pulse', 
> '-i', 'mkchromecast.monitor', '-acodec', 'libmp3lame', '-f', 'mp3', '-ac', 
> '2', '-ar', '44100', '-b:a', '192k', 'pipe:']
> PID of main process: 14226
> PID of streaming process: 14233
>  * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
> self.cclist []
> elif len(self.cclist) == 0 and self.tray == False:
> No devices found!
>
> Wouldn't it be a good idea to add pulseaudio-utils to mkchromecast's
> "Depends:" list?  I should also mention, there's _no_ pulseaudio
> server installed on this computer.  I see this in the strace:

You are right. I have added it to the Depends field.

>
> execve("/usr/bin/pulseaudio", ["/usr/bin/pulseaudio", "--start", 
> "--log-target=syslog"], [/* 50 vars */]) = -1 ENOENT (No such file or 
> directory)
>
> Does mkchromecast assume pulseaudio is installed on the host
> mkchromecast is run on?  In that case mkchromecast is unusable for me
> as I don't want to install pulseaudio, for various reasons.

Yes, it assumes that pulseaudio is installed on the host.  What I basically do
is to monitor an output with a null-sink and pipe it to ffmpeg or record it with
parec and then stream it. With pavucontrol you can select the monitor and have
still audio in your host. I may try to find another way for capturing the audio
from alsa. But in this sense, I am afraid mkchromecast would work as it does in
macOS where all system sound is casted. But let's give it a try.

>
> And after that:
>
> pa_context_connect() failed: Connection refused
>
> The other thing I'm wondering about is this:
>
>   http://0.0.0.0:5000/
>
> nmap reports port 5000 being upnp:
>
> PORT STATE SERVICE
> 8008/tcp open  http
> 8009/tcp open  ajp13
>
> PORT STATE SERVICE
> 1900/udp open|filtered upnp
> 5353/udp open|filtered zeroconf
>
> My computer has two interfaces (eth0 and wlan0) connected to two
> _different_ local networks.  Reading `mkchromecast -h', I couldn't
> find an option enabling me to direct the discovery to a specific
> interface/network.  The chromecast device i on the wireless network
> (wlan0) while this computers primary network is wired (eth0).
>

This is a very interesting option to add. I will do my best to come with
a solution.

> I also see some trafic to 224.0.0.251:5353 and 127.0.0.1:5353, which
> would be the wired network, I guess.
>
> None of these packages:
>
> avahi-autoipd - Avahi IPv4LL network address configuration daemon

Bug#835366: linux-image-4.7.0-rc7-amd64-unsigned: Laptop freezes after a couple of hours because of intel cstates

[Muammar El Khatib]

dge 
[Falcon Ridge 4C 2013] [8086:156d] (prog-if 00 [Normal decode])
Physical Slot: 3
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

06:05.0 PCI bridge [0604]: Intel Corporation DSL5520 Thunderbolt 2 Bridge 
[Falcon Ridge 4C 2013] [8086:156d] (prog-if 00 [Normal decode])
Physical Slot: 4
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

06:06.0 PCI bridge [0604]: Intel Corporation DSL5520 Thunderbolt 2 Bridge 
[Falcon Ridge 4C 2013] [8086:156d] (prog-if 00 [Normal decode])
Physical Slot: 5
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

07:00.0 System peripheral [0880]: Intel Corporation DSL5520 Thunderbolt 2 NHI 
[Falcon Ridge 4C 2013] [8086:156c]
Physical Slot: 0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: thunderbolt
Kernel modules: thunderbolt


** USB devices:
Bus 002 Device 002: ID 05ac:8406 Apple, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 05ac:0273 Apple, Inc.
Bus 001 Device 002: ID 05ac:8290 Apple, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


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

Kernel: Linux 4.7.0-rc7-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.7.0-rc7-amd64-unsigned depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.125
ii  kmod22-1.1
ii  linux-base  4.4

Versions of packages linux-image-4.7.0-rc7-amd64-unsigned recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2

Versions of packages linux-image-4.7.0-rc7-amd64-unsigned suggests:
pn  debian-kernel-handbook  
ii  grub-efi2.02~beta2-36
pn  linux-doc-4.7   

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

-- no debconf information

--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#834182: scalapack: Please switch to openmpi for hppa architecture)

[Muammar El Khatib]

Dear Helge,

On Mon, Aug 15, 2016 at 05:03:33PM +0200, Helge Deller wrote:
> Additional info:
> scalapack depends on blacs-mpi, which was today switched over for
> the hppa to openmpi as well.

Yes, I know. I uploaded it a couple of hours ago. I am waiting that it finishes
building in all architectures.

> See BZ #834181: blacs-mpi: Please switch to openmpi for hppa architecture
>

I will upload scalapack tonight :).

Regards,

--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#758528: Bug#833797: cegui-mk2: diff for NMU version 0.8.7-1.2

[Muammar El Khatib]

On Mon, Aug 15, 2016 at 2:30 PM, Mattia Rizzolo <mat...@debian.org> wrote:
> sure thing, done! :)


Thanks Mattia! and sorry for the delay in replying!.

Cheers.

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#758528: Bug#833797: cegui-mk2: diff for NMU version 0.8.7-1.2

[Muammar El Khatib]

Dear Mattia,

On Thu, Aug 11, 2016 at 11:38 AM, Mattia Rizzolo <mat...@debian.org> wrote:
> I've prepared an NMU for cegui-mk2 (versioned as 0.8.7-1.2) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
>
> Regards.

Thanks for the NMU!. I was wondering if you could commit and push
those changes to the git repo?.

Cheers,

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#834400: ITP: mkchromecast -- cast Linux Audio to your Google Cast Devices

[Muammar El Khatib]

Package: wnpp
Severity: wishlist
Owner: Muammar El Khatib <muam...@debian.org>

* Package name: mkchromecast
  Version : 0.3.2
  Upstream Author : Muammar El Khatib <muammarelkha...@gmail.com>
* URL : http://mkchromecast.com/
* License : MIT
  Programming Lang: Python
  Description : cast Linux Audio to your Google Cast Devices

 This is a program to cast your macOS audio, or Linux audio to your Google Cast
 devices. It is written in Python, and it streams via node.js, ffmpeg, or
 avconv.

 mkchromecast is capable of using lossy and lossless audio formats provided
 that ffmpeg or avconv are installed. Additionally, a system tray menu is also
 available.

--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#834358: awesome-extra: vicious.widgets.weather not showing information (only displays N/A)

[Muammar El Khatib]

Package: awesome-extra
Version: 2012061101
Severity: normal

Dear maintainer,

Since a couple of days, the vicious.widgets.weather stop showing and updating
information in my wibox. I proceeded to check
/usr/share/awesome/lib/vicious/widgets/weather.lua but nothing seemed wrong.
Googling a bit about it, I stumbled in this:
https://github.com/Mic92/vicious/pull/18/files. After changing the URL, the
widget is working correctly again.


Regards,

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

Kernel: Linux 4.7.0-rc7-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages awesome-extra depends on:
ii  curl  7.50.1-1

Versions of packages awesome-extra recommends:
ii  awesome  3.5.9-1

awesome-extra suggests no packages.

-- no debconf information

Bug#832287: ITP: tsc -- The Secret Chronicles of Dr. M.

[Muammar El Khatib]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

   Package name: tsc
Version: 2.0.0
Upstream Author: The TSC Contributors
URL: https://github.com/Secretchronicles/TSC
License: GPL-3
Description: The Secret Chronicles of Dr. M.
 TSC is a 2D sidecrolling platform game, with a rich set of graphics, music,
 and an advanced level editor that allows you to create your own levels. The
 level editor allows for in-game scripting so there are no borders apart
 from your imagination.

 The project is a fork of SMC, which is not developed actively anymore. Note
 this is not merely a continuation of SMC, but we have our own goals and
 design principles we are slowly integrating into both the codebase and the
 artwork.

--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#831152: silly: FTBFS with GCC 6: dh_makeshlibs: failing due to earlier errors

[Muammar El Khatib]

Package: libsilly
Version: 0.1.0-7
Followup-For: Bug #831152

Hi Lucas,


I have solved the bug, that was related to the symbols file. Should I upload
a new revision adding to 'Build-Depends' gcc-6 explicitely?. Otherwise, I think
that at build time in the archives, the builder will pick a gcc < 6 that will
the package fails.


Best regards,

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

Kernel: Linux 4.7.0-rc4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsilly depends on:
ii  libc62.23-1
ii  libgcc1  1:6.1.1-9
ii  libjpeg62-turbo  1:1.5.0-1
ii  libpng16-16  1.6.23-1
ii  libstdc++6   6.1.1-9
ii  zlib1g   1:1.2.8.dfsg-2+b1

libsilly recommends no packages.

libsilly suggests no packages.

-- no debconf information

Bug#823142: mutt-patched: First letter of Mailboxes' names is not shown

[Muammar El Khatib]

Package: mutt-patched
Followup-For: Bug #823142

Dear all,

This is a follow-up. I decided to install latest mutt's version available in
experimental (1.6.1-1) and the problem is fixed.  Apparently, patches coming
from NeoMutt has been introduced. As warned in the upgrade¹, I had just to
change in my configuration from $sidebar_delim to $sidebar_divider_char.

Cheers,

1. http://www.neomutt.org/sidebar-intro.html#intro-sidebar-config-changes

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

Kernel: Linux 4.6.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mutt-patched depends on:
ii  libassuan02.4.2-3
ii  libc6 2.22-9
ii  libcomerr21.43-3
ii  libgnutls30   3.4.12-2
ii  libgpg-error0 1.22-2
ii  libgpgme111.6.0-3
ii  libgssapi-krb5-2  1.14.2+dfsg-1
ii  libidn11  1.32-3
ii  libk5crypto3  1.14.2+dfsg-1
ii  libkrb5-3 1.14.2+dfsg-1
ii  libncursesw5  6.0+20160319-1
ii  libsasl2-22.1.26.dfsg1-15
ii  libtinfo5 6.0+20160319-1
ii  libtokyocabinet9  1.4.48-10
ii  mutt  1.6.1-1

mutt-patched recommends no packages.

mutt-patched suggests no packages.

-- no debconf information

Bug#786730: ITP: python-pychromecast -- Python library for communicating with Google Chromecast

[Muammar El Khatib]

Hi Ruben,

On Mon, 25 May 2015 01:59:53 +0200 Ruben Undheim <ruben.undh...@gmail.com> 
wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ruben Undheim <ruben.undh...@gmail.com>
>
> * Package name: python-pychromecast
>   Version : 0.6
>   Upstream Author : Paulus Schoutsen
> * URL : https://github.com/balloob/pychromecast
> * License : MIT
>   Programming Lang: Python
>   Description : Python library for communicating with Google Chromecast
>
>
> This library makes it easy to communicate with a Chromecast device using
> Python.
>
> It currently supports:
>
>  - Auto discovering connected Chromecasts on the network
>  - Start the default media receiver and play any online media
>  - Control playback of current playing media
>  - Implement Google Chromecast api v2
>  - Communicate with apps via channels
>  - Easily extendable to add support for unsupported namespaces
>
>


I was wondering what is the status of your efforts to get python-pychromecast in
the archive?.

Cheers,

--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#823142: mutt-patched: First letter of Mailboxes' names is not shown

[Muammar El Khatib]

On Wed, May 04, 2016 at 09:08:42PM +0200, Stefano Zacchiroli wrote:
> On Sun, May 01, 2016 at 02:00:51PM +0200, Muammar El Khatib wrote:
>
> The same upgrade also broke this setting from my .muttrc:
>
>   # set sidebar_delim_chars="/"
>
> which I had to comment out as it's no longer recognized. But I've no
> idea whether this is related to the first-letter bug or not.
>

I have just tested by commenting this on my .muttrc, but the problem is still
there. :(


Cheers,

--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#823142: mutt-patched: First letter of Mailboxes' names is not shown

[Muammar El Khatib]

On Sun, May 1, 2016 at 2:55 PM, Evgeni Golov <evg...@golov.de> wrote:
>
> Can you please provide your muttrc?


Attached you have it. I hope I have cleaned everything well...

Cheers,

--
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-


muttrc
Description: Binary data

Bug#823142: mutt-patched: First letter of Mailboxes' names is not shown

[Muammar El Khatib]

Package: mutt-patched
Version: 1.6.0-1
Severity: normal

Dear maintainers,


Recently, the first letter of Mailboxes's names is being "stripped" in
mutt-pached. I am sending attached to this bug report a screenshot so that you
can see. This is not an important bug, but it is annoying. I solved this by
adding the following¹:

set sidebar_shortpath=yes

But I lost the nested view of my GMail IMAP folders. According to Ref.¹ it is
a problem with mutt-patched source code.

Regards,

1. 
http://webcache.googleusercontent.com/search?q=cache:qx_UlnwuLqwJ:comments.gmane.org/gmane.mail.mutt.user/43483+=1=en=clnk=us

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

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mutt-patched depends on:
ii  libassuan02.4.2-3
ii  libc6 2.22-7
ii  libcomerr21.43~WIP.2016.03.15-2
ii  libgnutls30   3.4.11-4
ii  libgpg-error0 1.22-1
ii  libgpgme111.6.0-3
ii  libgssapi-krb5-2  1.13.2+dfsg-5
ii  libidn11  1.32-3
ii  libk5crypto3  1.13.2+dfsg-5
ii  libkrb5-3 1.13.2+dfsg-5
ii  libncursesw5  6.0+20160319-1
ii  libsasl2-22.1.26.dfsg1-15
ii  libtinfo5 6.0+20160319-1
ii  libtokyocabinet9  1.4.48-10
ii  mutt  1.6.0-1

mutt-patched recommends no packages.

mutt-patched suggests no packages.

-- no debconf information

--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#812096: smc: FTBFS: configure: error: Package requirements (CEGUI-OPENGL >= 0.7.2) were not met:

[Muammar El Khatib]

On Thu, Apr 21, 2016 at 9:13 PM, Tobias Frost <t...@debian.org> wrote:
> Thanks Muammar,
>

:)

> I have filed the RM.
>
> Kudos for maintaining smc..

Thanks for having filled the RM.

Have a nice day.

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#820307: cegui-mk2: please stop depending on libpng16-dev

[Muammar El Khatib]

Hi Tobias,

On Sat, Apr 16, 2016 at 8:04 AM, Tobias Frost <t...@frost.de> wrote:
> just another remark when you upload the new cegui-mk2:
> Due to liubpng1.6 the inferface of libsilly slightly changed.
> To avoid renaming the libsilly packages (as this is a ABI break and
> would require a SONAME bump), please make sure to add a
> Break against libsilly ( < 0.1.0-6.1)

Thanks for the information. I will add the Break to the new uploads.


Regards,
-- 
Muammar El Khatib.
http://muammar.me

Bug#812096: smc: FTBFS: configure: error: Package requirements (CEGUI-OPENGL >= 0.7.2) were not met:

[Muammar El Khatib]

Hi Tobias,

On Thu, Apr 21, 2016 at 7:58 AM, Tobias Frost <t...@debian.org> wrote:
> Sorry, I overread the "Yes."...

Don't worry.

> As the rest of it confuses me: Does that mean you are OK with filing an
> RM at this point of time?

Yes, I am ok with filling an RM for SMC. Upstream is not developing, I
don't have the time to do such an effort either.

> (We can also file a RM for the binaries alone, but there is no
> guarantee that the source will be retained; an ftp-master might think
> it is cruft and delete it)
>
> Let me know! (libpng1.2 removal, you know...)

Yes, let's proceed to request the RM.


Cheers,

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#812096: smc: FTBFS: configure: error: Package requirements (CEGUI-OPENGL >= 0.7.2) were not met:

[Muammar El Khatib]

Hi Tobias,

On Sun, Apr 17, 2016 at 3:18 PM, Tobias Frost <t...@debian.org> wrote:
> Maybe we should let it go?

Yes. There is other option, because some people has forked SMC. The
project is called TSC: https://github.com/Secretchronicles/TSC/.  But
there is no support for CEGUI 0.8.x yet.

Cheers,


-- 
Muammar El Khatib.
http://muammar.me

Bug#820307: cegui-mk2: please stop depending on libpng16-dev

[Muammar El Khatib]

Hi Gianfranco!

On Thu, Apr 07, 2016 at 09:59:36AM +, Gianfranco Costamagna wrote:
> source: cegui-mk2
> version: 0.8.5-1
>
> severity: serious
>
> Hi Muammar, sorry for this RC bug :) (feel free to downgrade if you don't
> agree with the severity)
>
> I see your package cegui-mk2 has a dependency on the now disappeared
> libpng16-dev (I removed it, to avoid people using it ;) )
>
> libpng16-dev | libpng-dev
>
> I'm not sure about the severity, because e.g. buildds are configured to not
> take in consideration the alternative during the pick of the packages.
>
> So, can you please just remove it?
>
> I can do it, the package is in collab-maint, but I would appreciate a feedback
> from you :)
>


I am working in a new debian revision for cegui. You can of course remove the
dependency if you wish to do it in the git repo. For the moments, I am waiting
for libsilly to build with latest libpng-dev to proceed with a new cegui upload.


Cheers,
--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#820297: silly: FTBFS on several architectures

[Muammar El Khatib]

On Thu, Apr 07, 2016 at 09:50:27AM +0200, Emilio Pozuelo Monfort wrote:
> Source: silly
> Version: 0.1.0-5
> Severity: serious
>
> Your package failed to build on several architectures with missing symbols:
>
> https://buildd.debian.org/status/package.php?p=silly
>
> Emilio

Thanks for the bug report. I have uploaded a new version that should address
this problem. After I check everything is OK I will proceed to close this
report.

Regards,
--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#816224: Depends on faac in non-free

[Muammar El Khatib]

Hi Josh,


On Sun, Feb 28, 2016 at 10:16 PM, Josh Triplett <j...@joshtriplett.org> wrote:
> Package: pulseaudio-dlna
> Version: 0.4.7+git2016024-1
> Severity: serious
>
> pulseaudio-dlna, in main, has a dependency on faac, in non-free.
>
> I'd suggest working with upstream to switch to ffmpeg's aac encoder
> instead; this will also likely improve quality and performance.

That is work in progress: https://github.com/masmu/pulseaudio-dlna/issues/164

In that case, I think I will test also with the ffmpeg-backend branch
that upstream created and see how stable it is in order to close this
bug.

Thanks for reporting.

Regards,
-- 
Muammar El Khatib.
http://muammar.me

Bug#814666: sysv-rc: update-rc.d prints incomplete usage (missing 'defaults')

[El Topo]

Package: sysv-rc
Version: 2.88dsf-59.2
Severity: minor

Dear Maintainer,

update-rc.d prints incomplete usage for itself.

Here's the output of update-rc.d command:

# update-rc.d --help
update-rc.d: error: --help
usage: update-rc.d [-n] [-f]  remove
   update-rc.d [-n]  disable|enable [S|2|3|4|5]
-n: not really
-f: force

The disable|enable API is not stable and might change in the future.



However, this is copied from update-rc.d's manpage:

SYNOPSIS
   update-rc.d [-n] [-f] name remove

   update-rc.d [-n] name defaults

   update-rc.d [-n] name disable|enable [ S|2|3|4|5 ]




As you can see, "update-rc.d [-n] name defaults" is missing from update-rc.d's
usage.


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

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

Versions of packages sysv-rc depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  insserv1.14.0-5.2
ii  startpar   0.59-3
ii  sysvinit-utils 2.88dsf-59.2

Versions of packages sysv-rc recommends:
ii  lsb-base  9.20160110

Versions of packages sysv-rc suggests:
pn  bum  

-- debconf-show failed

Bug#743391: silly: diff for NMU version 0.1.0-3.3

[Muammar El Khatib]

Dear Tobias,

On Fri, Jan 22, 2016 at 11:49:49AM +0100, Tobias Frost wrote:
> Control: tags 743391 + patch
> Control: tags 743391 + pending
>
> Dear maintainer,
>
> (Fixing this also in sid)
>
> I've prepared an NMU for silly (versioned as 0.1.0-3.3) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

Thank you very much for this NMU. Please, go ahead.


Regards,

--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#810972: libcegui-mk2-0.8.4 Python bindings cannot be used to run CEED (mismatching boost python symbols)

[Muammar El Khatib]

Source: cegui-mk2
Followup-For: Bug #810972

Hi,

I can confirm this problem, and I am trying to solve it. I checked the CEGUI's
wiki about CEED¹, and I fail to see what's missing for the moments. Indeed,
trying to import PyCEGUI fails.

Python 2.7.11 (default, Jan 11 2016, 21:04:40)
[GCC 5.3.1 20160101] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import PyCEGUI.so
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>>   ImportError: ./PyCEGUI.so: undefined symbol:
>>>   _ZTIN5boost6python15instance_holderE

I am doing some tests, and apparently the problem is related to linking. In
fact, I changed it for PyCEGUI.so and now the error is the following:

Following problems found:
PyCEGUI was found but PyCEGUIOpenGLRenderer is missing! CEED can't render
embedded CEGUI without it. (exception:
/usr/lib/python2.7/dist-packages/cegui-0.8/PyCEGUIOpenGLRenderer.so: undefined
symbol: _ZN5CEGUI18OpenGLRenderTargetINS_12RenderTargetEED2Ev)
Your environment doesn't meet critical prerequisites! Can't start!

Let me finish patching everything what is needed to upload a new revision soon.

Regards,

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

Kernel: Linux 4.4.0-rc8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

1. http://cegui.org.uk/wiki/CEED#Complete_Install_Notes_for_Ubuntu

--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org

Bug#746427: Python bindings are there with 0.8.4 package

[Muammar El Khatib]

Hi Yohann,

On Thu, Jan 14, 2016 at 11:22 AM, Yohann FERREIRA
<yohann.ferre...@orange.fr> wrote:
> Hi,
>
>
>
> libcegui-mk2-0.8.4 is providing PyCEGUI.so file permitting bindings for
> Python.
>
>
>
> I guess this bug can be marked as fixed with new package?
>
>

You are right. This bug can be closed. Are you proceeding to do it?


Cheers,
-- 
Muammar El Khatib.
http://muammar.me

Bug#737058: This bug is fixed

[Muammar El Khatib]

Hi Yohann,

On Thu, Jan 14, 2016 at 11:18 AM, Yohann FERREIRA
<yohann.ferre...@orange.fr> wrote:
> Hi there,
>
>
>
> As libcegui-mk2-0.8.4 is out in unstable. I guess this one is fixed?
>
>
>
> Best regards,


It is partially fixed. We have to split also the libraries how
suggested, but I wanted first to have it in the archives. Therefore,
the splitting has to be done to close this report.


Regards,

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#732723: cegui-mk2: Please upgrade OGRE dependency to 1.9 when upstream ready

[Muammar El Khatib]

On Fri, Dec 11, 2015 at 05:20:25PM +0100, Tobias Frost wrote:
...
> >
> > But those files were indeed included in the copyright file. See:
> >
> > https://web.archive.org/web/20150907175032/https://ftp-master.debian.
> > org/new/cegui-mk2_0.8.4-2.html
> >
> > Regards,
> >
>
> Hi Muammar,
>
> did you get any response in the meantime?
> Should we reupload?
>

They never replied, so in such a case I suppose that we should reupload. Would
you mind to prepare the upload in the git so that I can see how it is done?. Do
you plan to add you in debian/control file too?.

Cheers,
--
Muammar El Khatib.
http://muammar.me | http://proyectociencia.org