Bug#1053196: Please remove librados-dev build-depends on all 32 bits arch

2024-03-30 Thread Sunil Mohan Adapa

Hi,

Looks like a patch with fix for this issue is already in the repository. 
A release with this fix before April 8th would prevent auto-removal of a 
uwsgi and a large number of dependencies including freedombox from testing.


Thank you for all the contributions,

--
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#862348: fail2ban: fails to filter systemd ssh daemon entries from journal

2024-03-27 Thread Sunil Mohan Adapa

Control: tags -1 - trixie sid
Control: severity -1 normal

On Thu, 11 Jan 2024 00:15:27 +0100 Luca Capello  wrote:
[...]

Alban, 0.9.6-2 is quite an old version and you reported the bug more
than 5 years, can you try on a more up-to-date Debian?


This is no longer a bug on unstable/trixie. I have run the following 
tests to confirm. I created a fresh VM with Debian unstable and 
installed fail2ban. Running `systemctl status fail2ban` shows that 
fail2ban is successfully running. Reboot the machine and fail2ban is 
still running. Started monitoring /var/log/fail2ban.log. Then from the 
host machine connected using SSH client. At the password prompt, entered 
wrong password. For each incorrect password attempt, a message is 
printed in fail2ban.log with the client's IP address. After 5 such 
messages, a ban message was printed and the client was unable to connect 
and connect was refused. A few minutes later, the client was unbanned 
and was able to connect again.


On Debian bookworm, I could confirm that the problem still exists. 
fail2ban fails to start with 'ERROR: Failed during configuration: Have 
not found any log file for sshd jail'. This is because /var/log/auth.log 
does not exist due to journald being the default. Setting backend = 
systemd fixes this issue and I have tested this similar to unstable 
setup. So, if the fix for #770171 is backported to bookworm, then this 
issue can be closed.


When bug #1061776 was merged into this bug, the severity was 
inadvertently raised to 'serious' again. Due to serious severity the 
package was removed from testing and with it the freedombox package 
(which depends on fail2ban). I am setting the serverity back to normal 
as this is not a problem worth removing fail2ban package and its depends 
for. The package is usable when default configuration is modified as in 
case of FreedomBox setups.


--
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1065497: Please allow php-psr-log 3

2024-03-05 Thread Sunil Mohan Adapa

Control: tags -1 patch

On Tue, 5 Mar 2024 14:48:49 +0100 David =?iso-8859-1?Q?Pr=E9vot?= 
 wrote:

Package: php-klogger
Version: 1.2.2-2
Severity: important

Hi James, Sunil,

AFAICT, php-klogger is the only blocker preventing php-psr-log 3 upload
to unstable. php-psr-log 3 is available in experimental since 2021, and
recent php-psr-log will be needed for the php-monolog 3 transition.

Please, test your package with php-psr-log 3 and relax the versioned
dependency if you manage to make your package work with any php-psr-log
version, or upload to experimental a fix to make your packages work with
php-psr-log 3 (so we can easily upload it to unstable in sync with
php-psr-log 3).



I have patch available for making php-klogger depend on php-psr-log >= 3.0.

https://salsa.debian.org/php-team/pear/php-klogger/-/merge_requests/4

However, it does not work with php-psr-log 1.x anymore. So I don't know 
how the two packages can be uploaded together.


Thank you for bug report.

--
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1063968: freedombox: autopkgtest regression with pytest 8

2024-02-15 Thread Sunil Mohan Adapa

Control: tags -1 patch

On Thu, 15 Feb 2024 11:35:26 +0100 roehl...@debian.org wrote:
[...]

Dear maintainer,

your package has a autopkgtest regression with pytest 8.


Thank you for the bug report. We have a patch pending to fix this issue 
with pytest 8 and another with pytest 9[1]. This patch will be part of 
the upcoming bi-weekly release.


1) https://salsa.debian.org/freedombox-team/freedombox/-/merge_requests/2444

--
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1057093: php-imagick's autopkg tests fail

2024-02-13 Thread Sunil Mohan Adapa
autopkg test on sid has succeed for me. Latest ci.debian.org test 
results show that the tests all pass.


Looks like this bug should be closed to allow the package to transition 
to testing.


--
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#921812: mldonkey-server: Add systemd service file for better security

2023-02-06 Thread Sunil Mohan Adapa

Hi Mehdi,

Thank you for considering the patch.

On 1/17/21 04:27, Mehdi Dogguy wrote:
[...]

I have a doubt about which systemd features to enable by default though. I can 
see
thath Fedora/RedHat enabled really a few, as you can see in [1].

For this reason, I'll ask for advice from Michael (systemd's maintainer). 
Michael,
Sunil here is proposing a .service file for mldonkey-server. I am wondering if 
we
should aim for a simplistic approach as in [1] or if we should enable by default
features proposed by Sunil in his patch (see below). What do you think? What 
would
be your recommendation?

[1] 
https://src.fedoraproject.org/rpms/mldonkey/blob/2a45ff06778cadc4d58435ca1e7187396012c6f1/f/mldonkey.service


Debian wiki[1][2] and upstream[3][4] has some resources that could help 
with deciding security sandboxing features.


Let me know if an explanation of the features in mldonkey context would 
be helpful.


Links:

1) https://wiki.debian.org/Teams/pkg-systemd/Packaging
2) https://wiki.debian.org/ServiceSandboxing
3) http://0pointer.net/public/systemd-nluug-2014.pdf
4) 
http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm


Thanks,

--
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

2022-11-12 Thread Sunil Mohan Adapa

On 11/12/22 14:09, Daniel Black wrote:

So what Fedora does is a prep script called at StartPre on their
systemd service.
https://src.fedoraproject.org/rpms/mariadb/blob/rawhide/f/mariadb-prepare-db-dir.sh

Which even recently was seen as bloated
(https://lists.launchpad.net/maria-discuss/msg06376.html).

What could be done is a oneshot
(https://www.redhat.com/sysadmin/systemd-oneshot-service) service
before MariaDB/MySQL that does the installation.
Either installation or startup triggered.

At least on TMPDIR side, the systemd side PrivateTmp is default
(https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateTmp=)
for at least the oneshot service.
The option for loading files into MariaDB was the only reason this
wasn't set in the default MariaDB systemd file.


During today's FreedomBox meet, we have discussed that systemd'd 
PrivateTmp= is a better solution than libpam-tmpdir for FreedomBox at 
least as systemd makes a cleaner mount isolation between processes 
instead of managing directories and permissions.


For this reason, we believe that we can stop using libpam-tmpdir if most 
of the daemons on the system use PrivateTmp=yes. For a while now, 
FreedomBox has been forcefully adding systemd security features to 
daemons that don't enable them. Without upstream blessing, we can only 
do this for smaller applications than something like MariaDB/MySQL due 
the testing effort needed.




How User= systemd directives work with lbpam-tmpdir I'm not sure,
however without a setuid there shouldn't be an invalid TMPDIR env
variable there.


libpam-tmpdir does not seem to effect systemd's process execution. See 
the following session on system with libpam-tmpdir installed:


$ sudo --user mysql /usr/bin/bash -c 'echo TMPDIR=$TMPDIR'
TMPDIR=/tmp/user/119

$ sudo systemd-run --pipe --uid=mysql /usr/bin/bash -c 'echo TMPDIR=$TMPDIR'
Running as unit: run-u30.service
TMPDIR=

$ sudo systemd-run --pipe --property=PrivateTmp=yes --uid=mysql 
/usr/bin/bash -c 'echo TMPDIR=$TMPDIR'

Running as unit: run-u31.service
TMPDIR=

--
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1022994: mariadb-server: Initial DB creation fails with libpam-tmpdir installed

2022-10-28 Thread Sunil Mohan Adapa
Package: mariadb-server
Version: 1:10.6.10-1
Severity: important
Tags: upstream

Dear Maintainer,

This bug has been reported upstream but may need a workaround in Debian.

https://jira.mariadb.org/browse/MDEV-29910

Description
---

On Debian GNU/Linux, when the package libpam-tmpdir is installed,
mysql_install_db script fails during post install setup. As a result, mariadb
daemon fails to start. The following error message is shown:

rm -rf /var/lib/mysql ; mysql_install_db --rpm --cross-bootstrap --user=mysql
--disable-log-bin --skip-test-db

2022-10-28 19:33:00 0 [ERROR] mariadbd: Can't create/write to file
'/tmp/user/0/ib2C7oNS' (Errcode: 13 "Permission denied")
2022-10-28 19:33:00 0 [ERROR] InnoDB: Unable to create temporary file; errno:
13
2022-10-28 19:33:00 0 [ERROR] mariadbd: Can't create/write to file
'/tmp/user/0/ibykVtxz' (Errcode: 13 "Permission denied")
2022-10-28 19:33:00 0 [ERROR] InnoDB: Unable to create temporary file; errno:
13
2022-10-28 19:33:00 0 [ERROR] InnoDB: Database creation was aborted with error
Generic error. You may need to delete the ibdata1 file before trying to start
up again.
2022-10-28 19:33:00 0 [ERROR] Plugin 'InnoDB' init function returned error.
2022-10-28 19:33:00 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE
failed.
2022-10-28 19:33:00 0 [ERROR] Unknown/unsupported storage engine: InnoDB
2022-10-28 19:33:00 0 [ERROR] Aborting

Installation of system tables failed!  Examine the logs in

/var/lib/mysql for more information.

Environment
---

On FreedomBox (a pure blend of Debian), several applications that depend on
mariadb fail to install when running on Debian testing/unstable. This is due to
mariadb not running soon after installation. FreedomBox installs that package
libpam-tmpdir by default. If this package is removed, mariadb server is running
successfully after install.

This bug was reproduced on Debian unstable (as of 2022-10-28) with
mariadb-server package version 1:10.6.10-1+b1.

Workarounds
---

1. If libpam-tmpdir package is removed, the installation and daemon start
   succeed.

2. When the environment variable TMPDIR is set to empty value, the
   mysql_install_db command succeeds. Example:

   rm -rf /var/lib/mysql ; TMPDIR= mysql_install_db --rpm --cross-bootstrap
   --user=mysql --disable-log-bin --skip-test-db

3. When mysql_install_db is not run are root, the problem is not observed.
   Example:

   rm -rf /var/lib/mysql ; mkdir /var/lib/mysql; chown mysql:mysql
   /var/lib/mysql/ ; sudo -u mysql mysql_install_db --rpm --cross-bootstrap
   --user=mysql --disable-log-bin --skip-test-db

Regression
--

This error does not occur on Debian stable (bullseye) where mariadb package
version is 1:10.5.15-0+deb11u1. Hence this is a regression since that version.

Analysis


According to pam-tmpdir: "Many programs use $TMPDIR for storing temporary
files.
Not all of them are good at securing the permissions of those files.
libpam-tmpdir sets $TMPDIR and $TMP for PAM sessions and sets the permissions
quite tight. This helps system security by having an extra layer of security,
making such symlink attacks and other /tmp based attacks harder or impossible".

Errors like the one being reported are typically seen when directories/files
are
created by root user in the $TMPDIR and later a non-root user tries to access
those files without any further permission changes. libpam-tmpdir tries to
ensure that temporary files created by one user are not accidentally accessible
to unauthorized users.

During 10.6.x release cycle a change was introduced that makes this mistake. It
creates files as 'root' and then tries to access them as 'mysql' user. The
problem can be fixed by:

1. Copying the files temporarily created by 'root' user to a location
accessible
   to the 'mysql' user and then setting proper ownership, or by

2. Creating all the temporary files with 'mysql' user to start with.



Bug#910028: [Freedombox-pkg-team] Bug#910028: marked as done (pagekite: Stopped logging to /var/log/pagekite/ when using systemd)

2022-03-07 Thread Sunil Mohan Adapa

On 3/7/22 15:30, Petter Reinholdtsen wrote:

[Sunil Mohan Adapa]

Yes, we can create a README file in /var/log/pagekite to avoid the
confusion it creates. Alternatively, could the confusion have been
avoided if /var/log/pagekite directory was not created at all? I would
guess that people will start looking at centralized logging such as
/var/log/syslog when they don't find service specific logging.


My idea was more to replace the file content in /var/log/pagekite/ with
instructions to look elsewhere, but a README could work too.

I was looking in /var/log/pagekite/ because it was the place to look the
last time I debugged pagekite.  I assume new installations do not have
this directory at all.


We have /var/log/pagekite listed in debian/dirs. New installations might 
be creating this directory unnecessarily.


--
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#910028: [Freedombox-pkg-team] Bug#910028: marked as done (pagekite: Stopped logging to /var/log/pagekite/ when using systemd)

2022-03-07 Thread Sunil Mohan Adapa

On 3/3/22 21:13, Petter Reinholdtsen wrote:

[Sunil Mohan Adapa]

I believe that we should not re-enable logging to /var/log/pagekite.


What about adding a message into /var/log/pagekite/ , if the old log
files exist during package upgrade, stating that the logging now is done
via journald?  It would have saved me some time when I had to debug
pagekite last time.



Yes, we can create a README file in /var/log/pagekite to avoid the 
confusion it creates. Alternatively, could the confusion have been 
avoided if /var/log/pagekite directory was not created at all? I would 
guess that people will start looking at centralized logging such as 
/var/log/syslog when they don't find service specific logging.


--
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#993294: Bug#998903: src:libidn: fails to migrate to testing for too long

2021-11-10 Thread Sunil Mohan Adapa

On 11/10/21 16:25, Simon Josefsson wrote:

James Valleroy via "Discussion list for GNU Internationalized Domain
Name library (Libidn)"  writes:


On 11/10/21 6:40 AM, Simon Josefsson wrote:

James, what do you think?  Is the libidn11-java package important for
you to have in Debian?  My perception was that nobody really used it,
and IDNA2003/StringPrep is old technology so it feels strange that new
code is coming around using.  While I am also upstream of this Java
code, I'm not familiar with how Java stuff is packaged/used in Debian,
and maybe there is another way of doing things that is just as easy for
you.


Hello,

(Adding Sunil who did most of the packaging work for libjxmpp-java.)

libjxmpp-java was packaged as a dependency of jitsi-videobridge.
Specifically for Jitsi we need the -core, -jid, and -util-cache modules.

It looks like libidn is only used for jxmpp-stringprep-libidn module.
Possibly we can disable building this module.


Is it not used by anything else?  If so, I agree it makes sense to
disable it, unless you think it is useful elsewhere.  I could add
libidn11-java back if there is real usage of it, but if it is not needed
for anything particular right now, I would prefer if you disable it
until there is real interest in using it.  When/if that occurs, we can
always add libidn11-java and jxmpp-stringprep-libidn back again.
Hopefully, XMPP will be updated to use something newer than StringPrep
meanwhile.



Simon, thank you for offering to build the library again if needed.

My understanding was that one of the three stringprep implementations is 
needed to use the jxmpp library. They are based on libidn, icu4j and 
rocksxmppprecis. Of these, we have only built the stringprep library 
based on libidn and assumed it to be critical.


However, I dug up a bit more in jitsi-xmpp-extenstions and other 
jitsi-videobridge code. To use the jxmpp-stringprep-libidn library one 
needs to import the class and call setup() on it. This does seem to be 
happening anywhere as far as I can tell. In this case, the jxmpp library 
seems to use a fallback implementation. It appears we can drop building 
the library jxmpp-stringprep-libidn although I can't say for sure 
without going through jitsi and all of its dependencies more thoroughly.


When we progress more on the packaging effort we might know better and 
can then request libidn to build libidn11-java again.


James, let us drop building jxmpp-stringprep-libidn for now and drop 
dependency on libidn11-java.


Thanks,

--
Sunil



Bug#990223: fixed in pcp 5.3.4-1

2021-10-30 Thread Sunil Mohan Adapa
On Sun, 10 Oct 2021 11:50:03 -0700 Sunil Mohan Adapa  
wrote:
On Thu, 07 Oct 2021 23:18:50 + Debian FTP Masters 
 wrote:

> Source: pcp
> Source-Version: 5.3.4-1
> Done: Nathan Scott 
> 

Unfortunately, the solution didn't seem to work. piuparts still failed 
with the latest version[1]. This is presumably because the environment 
under which piuparts has installed the package, systemd was not detected 
and the changes were still made to the configuration file.


We could either drop the changes for non-systemd systems entirely or 
patch the init.d file to pickup a newly environmental file dropped in by 
zeroconf.




Hi Nathan,

My apologies for an incomplete solution earlier. I have proposed a 
different solution that works for machines with systemd and without[1]. 
I would appreciate a review, merge and release with the new fix.


Links:

1) https://github.com/performancecopilot/pcp/pull/1462

Thanks,

--
Sunil



Bug#990223: fixed in pcp 5.3.4-1

2021-10-10 Thread Sunil Mohan Adapa
On Thu, 07 Oct 2021 23:18:50 + Debian FTP Masters 
 wrote:

Source: pcp
Source-Version: 5.3.4-1
Done: Nathan Scott 



Unfortunately, the solution didn't seem to work. piuparts still failed 
with the latest version[1]. This is presumably because the environment 
under which piuparts has installed the package, systemd was not detected 
and the changes were still made to the configuration file.


We could either drop the changes for non-systemd systems entirely or 
patch the init.d file to pickup a newly environmental file dropped in by 
zeroconf.


Links:

1) https://piuparts.debian.org/sid/fail/pcp-zeroconf_5.3.4-1.log

--
Sunil



Bug#794960: tt-rss: Does not start on boot

2021-10-09 Thread Sunil Mohan Adapa

tag 794960 + patch
thanks

On Sat, 08 Aug 2015 11:00:31 -0700 Jeremy Malcolm  
wrote:

[...]

Since I upgraded to Debian 8, the tt-rss daemon no longer starts on
boot.  It appears that when it attempts to start, MySQL is not ready. 
However, I can start it manually.  I can see these errors from systemd:


I am able to reproduce the problem with PostgreSQL 13.0 and tt-rss 
21~git20210204.b4cbc79+dfsg-1 on a Debian Bullseye system (managed by 
FreedomBox). The problem only occurs sometimes. On boot, the service 
shows as failed to start and never retries. FreedomBox uses systemd.


Even though tt-rss.service has Wants= and After= on postgresql.service, 
postgresql is has Type=forking model and I don't believe it notifies 
systemd after startup. Hence after spawning postgresql successfully, 
tt-rss.service is immediately started. However, postgresql may be doing 
house keeping duties like recovering from journal/log on power failure, 
etc. and may not be accepting connections at the moment. If 
postgresql.service starts quickly, tt-rss.service works. Otherwise, it 
fails permanently (for that system boot).


I predict that this bug also happens in other cases. When database is 
being restarted for a security upgrade (say with needsrestart package 
like in case of FreedomBox) and if tt-rss tries to query at that time, 
tt-rss will fail permanently.


The reason for both the bugs is that tt-rss code has exit(101) if db 
connection fails. It does not try again in the next scheduled time after 
waiting 120 seconds.


Both the situations are more prominent in case of slow machine like 
single board computers running on SD cards like in case of FreedomBox.


Solution:

To solve both the problems comprehensively the following service options 
can be introduced:


# Restart the service every 120 seconds always. When tt-rss can't
# connect to a database temporarily, it will exist with exit code 101.
# 120 seconds is the default daemon sleep interval for tt-rss.
[Service]
Restart=always
RestartSec=120s

This essentially introduces a loop around daemon that spawns it every 
120 seconds after it is "done". This is the way the daemon intends to 
run according to its code (barring this bug, of course). So, restarting 
"always" does not seem incorrect.


Merge request available at: 
https://salsa.debian.org/debian/tt-rss/-/merge_requests/3


Another way to do this is to pass options to run it a single time and 
then use a systemd.timer to run it every 120 seconds.


Thanks,

--
Sunil



Bug#990223: pcp-zeroconf: modifies conffiles (policy 10.7.3): /etc/default/pmlogger

2021-09-29 Thread Sunil Mohan Adapa

tag 990223 + patch
thanks

On 9/29/21 4:46 PM, Sunil Mohan Adapa wrote:

On 9/29/21 4:05 PM, Nathan Scott wrote:
[...]


I think this would do for now.  Could you post a patch?  Either here, 
or to

me directly, or p...@groups.io, or a PR on the PCP github repo?  (all the
debian build files are there too).


I will post a properly tested patch on PCP Github soon.



A patch is now available for review on upstream repo:
https://github.com/performancecopilot/pcp/pull/1427

--
Sunil



Bug#990223: pcp-zeroconf: modifies conffiles (policy 10.7.3): /etc/default/pmlogger

2021-09-29 Thread Sunil Mohan Adapa

On 9/29/21 4:05 PM, Nathan Scott wrote:
[...]


I think this would do for now.  Could you post a patch?  Either here, or to
me directly, or p...@groups.io, or a PR on the PCP github repo?  (all the
debian build files are there too).


I will post a properly tested patch on PCP Github soon.




Severity:

Currently, this bug is threatening to remove all of pcp, cockpit and
freedombox from Debian on October 10th. Please consider adopting some
solution to avoid this.


That'd be good - if you can send through that tested solution, I'll
endeavour to get a build uploaded with it next week.



Many thanks in advance.

--
Sunil



Bug#990223: pcp-zeroconf: modifies conffiles (policy 10.7.3): /etc/default/pmlogger

2021-09-29 Thread Sunil Mohan Adapa

On Sun, 5 Sep 2021 16:51:46 +1000 Nathan Scott  wrote:

Hi Petter,

On Sun, Sep 5, 2021 at 4:45 PM Petter Reinholdtsen  wrote:
> [...] This approach is known as multilevel configuration.
>
> I recommend it over modifying conffiles in /etc/.

I'll discuss with other upstream folks and see if we can transition
to this style of solution & for all distros.  It's a fairly major change,
so it won't happen overnight, but I agree it is a good way to tackle
this.



There is a simpler solution. The configuration option in question is an 
environment variable. This can be passed to the daemon by shipping a 
systemd service configuration file in pmlogger packaging.


$ cat /usr/lib/systemd/system/pmlogger.service.d/pcp-zeroconf.conf
[Service]

Environment=PMLOGGER_INTERVAL=10


When the package pcp-zeroconf is removed, the configuration will be 
restored to previous state and this is often desirable. This, however, 
works only on systemd systems.


Handling Dynamic Values:

Alternatively, if the file needs to contain dynamically calculated 
options, pmlogger.postint can generate the file 
/etc/systemd/system/pmlogger.service.d/pcp-zeroconf.conf . This file 
will need to be removed by pmlogger.postrm (for purge).


Test:

I have tested this solution as follows:

(comment out PMLOGGER_INTERVAL in /etc/default/pmlogger)
# systemctl daemon-reload
# systemctl show pmlogger.service | grep Environment
Environment=PMLOGGER_INTERVAL=10

# systemctl restart pmlogger.service
# systemctl status pmlogger.service
(pickup main PID from output)
# cat /proc/{pid}/environ | tr '\0' '\n' | grep PMLOGGER_INTERVAL
PMLOGGER_INTERVAL=10

Non-systemd systems:

In addition to this solution the change in pmlogger.postinst can be 
confined to non-systemd systems:




# increase default pmlogger recording frequency


if [ ! -e /run/systemd ]; then

sed -i 's/^\#\ PMLOGGER_INTERVAL.*/PMLOGGER_INTERVAL=10/g' 
/etc/default/pmlogger



fi


If better approach for non-systemd systems is desired, then we canpatch 
the /etc/init.d/pmlogger (src: src/pmlogger/rc_pmlogger) to read more 
environment files from, say, /etc/pmlogger/*.conf and 
/usr/share/pmlogger/*.conf. Then pcp-zeoconf can install the file 
/etc/pmlogger/pcp-zeroconf.conf.



Severity:

Currently, this bug is threatening to remove all of pcp, cockpit and 
freedombox from Debian on October 10th. Please consider adopting some 
solution to avoid this.


Thanks you for pcp!

--
Sunil



Bug#994256: django-axes: autopkgtest needs update for new version of python-django: warnings changed

2021-09-17 Thread Sunil Mohan Adapa

tags 994256 + pending
thanks

New version of the package is ready for upload and will be uploaded 
after some manual testing.


Thanks,

--
Sunil



Bug#994256: [Freedombox-pkg-team] Bug#994256: django-axes: autopkgtest needs update for new version of python-django: warnings changed

2021-09-17 Thread Sunil Mohan Adapa

On 9/17/21 10:54 AM, Carsten Schoenert wrote:

Hi,

Am Tue, Sep 14, 2021 at 09:18:18PM +0200 schrieb Paul Gevers:
...

Currently this regression is blocking the migration of python-django to
testing [1]. Of course, python-django shouldn't just break your
autopkgtest (or even worse, your package), but it seems to me that the
change in python-django was intended and your package needs to update to
the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from python-django should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.


I did a quick import of the currently most recent version 5.24.0 and did
afterwards a rebuild of this version.

The built of the binary packages and also the autopkgtest works without
further needed adjustments so updating django-axes to a recent version
would be enough to fix this issue.



Thanks! I have also checked for the compatibility of axes code with 
Django 3.2. All the changes need seem to be already in 
place[1][2][3][4]. I will work to update the packaging to newer version.


Links:

1) 
https://github.com/jazzband/django-axes/commit/b4a71de81fd2d1c316c819fff4c68581ada6208d


2) 
https://github.com/jazzband/django-axes/commit/876b6f3dc4377daa6e1d2a1244ea7a86bf952695


3) 
https://github.com/jazzband/django-axes/commit/2e074eebc5752dbedde5f66ece0d9a38bc8694cd


4) 
https://github.com/jazzband/django-axes/commit/4986c240a6ccea6f52c1a18ca08f56ad2d6fa6de#diff-b8833de46a20430033cf627e5843a9a394547e8d6dd62d1a6c05e1f31039244e


--
Sunil



Bug#984760: grub-pc: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)

2021-05-13 Thread Sunil Mohan Adapa
On Thu, 15 Apr 2021 23:00:22 -0700 Sunil Mohan Adapa 
wrote:
> Hi,
> 
> The problem is not limited to amd64. I see this problem on arm64. On a
> FreedomBox arm64 image, on a Raspberry Pi 3B+ (when booted with UEFI
> firmware[1]) when grub efi packages are upgraded, boot fails with the
> error 'symbol `grub_is_lockdown` not found'.
> 
> Links:
> 1) https://github.com/pftf/RPi3
> 

In my case, after uninstalling and reinstalling grub-efi-arm64* and
grub?-common packages, everything worked well. This action installed
additional packages (like shim-signed?) that were not present before.

The problem surfaced after an upgrade, in my case, done using
unattended-upgrades. This may indicate that something that is supposed
to be in Depends: list is in Recommends: list.

-- 
Sunil



Bug#987965: ITP: libjitsi-utils-java -- Set of basic Java utilities used in Jitsi projects

2021-05-02 Thread Sunil Mohan Adapa
Package: wnpp
Severity: wishlist
Owner: Sunil Mohan Adapa 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libjitsi-utils-java
  Version : 1.0
  Upstream Author : 8x8 Inc., Atlassian Pty Ltd
* URL : https://github.com/jitsi/jitsi-utils
* License : Apache-2.0
  Programming Lang: Java
  Description : Set of basic Java utilities used in Jitsi projects

Jitsi Videobridge is an XMPP server component that allows for multiuser video
communication. Unlike the expensive dedicated hardware videobridges, Jitsi
Videobridge does not mix the video channels into a composite video stream, but
only relays the received video channels to all call participants. Therefore,
while it does need to run on a server with good network bandwidth, CPU
horsepower is not that critical for performance.

This library is a necessary component of the Jitsi Videobridge.

This is part of a larger effort to package Jitsi Videobridge in Debian. I
intend to maintain the package as part of the Debian Java team.




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAmCPEBoRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfLmNQ//eQFXd32Howg3bisxb47NsMYLMy6X7Fm+
EgrbJ19MRIV58qOPGfJhqPbkUOnC0n9ttLE9p3wboKJtaWMtAbDemyFyY2XTtHzs
xeRAuWSgWWB4MXzqD84aP0UUAQ3h7JOBGqUuSFB/l45uZ5Qjqf/sJvE195yhygmr
QktAQ+ZCHsP20DpNHVt0VkzxtpwBSa90UIEz6j28h1jJRaWHlRJhJ1GsNGCONDug
yYIjMKU5evIyyX6Py58WhIvBKUnpdzxwwV7kxKFx83JIOoSbFI/3405OyylEN2DN
rf+t6Eld+yoEOghF/PNTgwzmwBpins2WFC7w0ZX2Uq3HvI+hxq1t8HJaJeDmOrow
+sSayNTPvzCyCcEDyvBB26YTo+nAvwMm1ZxW8/fSTkYUXreqpGYErz9uUM9UzoYH
CT2QpnWWWAvgcxozxgYUAvVn1Tkw2xgdAc3anbM9ETWudZWNMjVEbtda09Q3J68u
hzEE09qpN8+uQKjEZlT+luI5m5+JkqlCqyg7/VSJk8zqEb53rUN0+8eLze9fY42c
/5ShxYHp4/hNiM1vRPnIxAS5KJsm+bK/Wbu0VBd0SLh04BhD6A5zzG4LT6DL2wyS
HteVEhlB8Yma94jeghbTssCChCXMvSJJHnpW2zGKU1o06Bi/9zNBzBXpQGIITDVI
3IC2ETkt5LY=
=I9Cf
-END PGP SIGNATURE-



Bug#987898: ITP: libjxmpp-java -- Base library for XMPP based instant messaging and presence

2021-05-01 Thread Sunil Mohan Adapa
Package: wnpp
Severity: wishlist
Owner: Sunil Mohan Adapa 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libjxmpp-java
  Version : 1.0.1
  Upstream Author : Florian Schmaus 
* URL : https://github.com/igniterealtime/jxmpp
* License : Apache-2.0
  Programming Lang: Java
  Description : Base library for XMPP based instant messaging and presence

JXMPP is an Open Source Java base library for XMPP. It provides often used
functionality needed to build an XMPP stack

jxmpp-core: Provides core functionality most software that interacts with XMPP
requires: XmppDateTime, XmppStringUtils, XmppStringPrepUtil.

jxmpp-jid: Provides API that abstracts XMPP JIDs with Java classes, performing
string preparation and validation.

jxmpp-stringprep-libidn: Perform XMPP's StringPrep with the help of libidn.

jxmpp-util-cache: Provides a lightweight and efficient Cache without external
dependencies used by various JXMPP Components.

jxmpp-strings-testframework: A framework to test "XMPP Strings".

This is part of a larger effort to package Jitsi Videobridge in Debian. I
intend to maintain the package as part of the Debian Java team.




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAmCNoMYRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfIK2Q/9GuTF8Z0Doo50tV1s5iB1mdlasR3NQJVZ
PtEF3acvuGo2IIZFgYhH2eHnzUq8IyqS0nwW1fB2fqyuc+fZ1IkytyopxeOokGTh
oC8jBlRcISH9zBrDOK6Po881IKP5fPRxiky3tc2svs9EPy2j3mX9MNUpmT74gZpj
GVhkCeICwHbHqjmJtskpDt5U4/Z3IKmbsACXVMNH/E9uMvA5vXzVLERCZ4rv4J+I
RG3kVymokxYtjpxkN1cPXnuz++Q8yy4pI/nmWUzfOfiJOJfLPlV2tlgW0hmNydNP
3s/t4N5ozKg0WRb+Z4eH8gMa6xhXiKNrBF/QnJswkz9SuMFGsWpfBLYTBaQEytID
NZvbMYlnJxTlvyw9RFvr6805l40BBt801TTpBSD7M0BrQPOPgmBtrsdlaM524zY6
40PLEV4BBYRC7XSftddhV4+UNnn7rcvgUmVVj8JD9pkvqI0KhJT3WXCbLQiYG38G
oqQ6edaaDPriFZ/3QjUdgjQSkjMVkhqNIkgQw6kBlhyEvVlHw4TvTuYs/EzPg1wK
Ngne7reIaNtRHM2xo6hFxgB9wavS5giyJDk5y/VMcrOtOfov/Ub/A0od1bllhcHg
FztKxQtmz5SzaPvniQUlOaxEldBYzF1mHLcyHOai175YDkIWKU05rsHjXUZQcSik
xMurXfCwvVg=
=4NVb
-END PGP SIGNATURE-



Bug#987846: ITP: libcallstats-java -- Library to integrate with callstats.io

2021-04-30 Thread Sunil Mohan Adapa
Package: wnpp
Severity: wishlist
Owner: Sunil Mohan Adapa 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libcallstats-java
  Version : 5.2.0
  Upstream Author : Karthik Budigere , Marcin Nagy

* URL : https://github.com/callstats-io/callstats.java
* License : Expat
  Programming Lang: Java
  Description : Library to integrate with callstats.io

callstats.io is a web service for storing and analying WebRTC call quality
statistics. This library helps Java programs such as jitsi-videobridge and
kurento to publish statistics to the online service.

This is part of a larger effort to package Jitsi Videobridge in Debian. Jitsi
Videobridge has submission of statistics to callstats.io server disable by
default. However, this library appears to be a hard dependency. I intend to
maintain the package as part of the Debian Java team.




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAmCMYGERHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfKqKQ//RguZnNA89pa4rEV+hQtky0Mf6NEGOTZA
XlVgF/1FrnvMlf79riwq6gHJDuC02KYUb1SJZVK14hW4SMN8zlQizWLyxF8XRzSS
Si0WSdqTCaLbcod6zfeNv902ojkYaJL5WEeuxmRp7LdbqeCUv6zVUJA2hMk4TGBV
jxLct+1Vg62qs37BX+/1114evKDNDGmnTCY9FLhk/9YZsW163G5W79pG1NHrUsZg
qtHJKe3jSCFfaj4fiJoU+VhH5FFxKhQ/l3GuatIx/hGTlpI9pPWpnA1cvtbCnu9s
xIu6DljAwhP5bGjx0mSCqJ1q3Fe1NOq3dgrFb4urCZi8cOQb6Ko4SRqGZQYzCZm8
K/ZvG90mp2eJmAFFn9ex8vTaJ6AaPKiOGpropV8rdUpK5byQ3TK7i1upF9nlcvjN
eiHKDW1LwqbKeEW82vzoQwGqPAqFRo4erYqN0sezlsNAIJ5n4ky2au3UovGLEQg/
VNP7y+X6Tac2JWUDCJFTI1S5IfQ1biKeL5L+jzbn1eMqQqG+fJb1MPM8a2KwX1eP
oHVkrFzDohWPGQ2lZ99DHVBW4CfPr4N/Yt1/uZWUopMwur4GgdrxkHSCGmixXe3c
OsdaoyyXTn70auY77I4lSupcYqZ7giGdPde9Mjd6PAnOWxkFNJwh5ETQL0ovltWB
3DFINor9ZNI=
=gTm4
-END PGP SIGNATURE-



Bug#987806: ITP: libminidns-java -- Minimal DNS client library for Android and Java SE

2021-04-29 Thread Sunil Mohan Adapa
Package: wnpp
Severity: wishlist
Owner: Sunil Mohan Adapa 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libminidns-java
  Version : 1.0.0
  Upstream Author : Florian Schmaus  and others
* URL : https://github.com/minidns/minidns
* License : LGPL-2.1+ or Apache-2.0 or WTFPL
  Programming Lang: Java
  Description : Minimal DNS client library for Android and Java SE

MiniDNS can parse resource records (A, , NS, SRV, etc.) and is easy to use
and extend. MiniDNS aims to be secure, modular, light weight and as simple as
possible. It also provides support for DNSSEC and DANE, and is thus useful if
you want to bring DNSSEC close to your application.

It comes with a pluggable cache mechanism, a pre-configured cache and an easy
to use high-level API (minidns-hla) for those who just want to perform a
reliable lookup of a domain name.

This is part of a larger effort to package Jitsi Videobridge in Debian. Jitsi
Videobridge depends on Smack which in turn depends on three DNS libraries. Of
these three DNS libraries only minidns supports DNSSEC. I intend to maintain
the package as part of the Debian Java team.




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAmCLXzQRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfICgg/+NYlxg4mD82085Du01tla/GkGI1OaxM/Z
L2lVNSObnDZJwx8Ts3YPrSqDd2lCmbJfKZhn3Ap4RwqwetTlKg+zKT8Xsqlqx6ue
SiP0iygXm4a1NWtZtZu4beSQ7cG6uVh+DUNhwZ0CDWG7onIOAueNmRUgcZsaTTOD
p6REyVuezQozEHMEiJKAyxEbT49Y5yOSmATJmCl4e9toLiK/ktHAc8XXXuZg69Vy
NELAlFbFS07EyW74LbyEjDABt9OA43LZW9Sf0komOqbJ7QM0opO4g6rFlLzpZiM9
jIK9JDJk6kOr1jaYNLV58CJQ/+YQARYacNTn0iD14G5yMdsK3i2nrqE80W6ofRG/
uHSDFzLpHJA2q8ci4TZkpZzuNbUjirJcJw0vAqGJeZv/NHmOAfBbJfFgWYNFFC4B
xk16ZOQsXipvgtVy+XfKeB/qSgyqhRPhMoePhvbw7d68LlO2ClG1OTgqRrkVUCAX
pMPomMcJNwvgbv+WcQmdY1tkk+tMYm9geH4BfMYO0ACxw2oJCfHeYuTibf3BSYmj
HPYdXFM39EOx3dOUGzr8o68v62pbJLtTLY8AYl0xXvju+W+9UJjgzIEFVUCVAd+F
hLy+0mxbpKQwT1Rm6/XXWZA6wj+lTN1c9voF5UyzCnLI2RKJEXfNwFl1oR1jfHaF
HOn3VEPPK6U=
=AfUX
-END PGP SIGNATURE-



Bug#987804: ITP: libjose4j-java -- Implementation of JSON Web Token (JWT) and the JOSE specification suite

2021-04-29 Thread Sunil Mohan Adapa
Package: wnpp
Severity: wishlist
Owner: Sunil Mohan Adapa 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libjose4j-java
  Version : 0.7.7
  Upstream Author : Brian Campbell 
* URL : https://bitbucket.org/b_c/jose4j/
* License : Apache-2.0
  Programming Lang: Java
  Description : Implementation of JSON Web Token (JWT) and the JOSE
specification suite

The jose.4.j library is a robust and easy to use open source implementation of
JSON Web Token (JWT) and the JOSE specification suite (JWS, JWE, and JWK). It
is written in Java and relies solely on the JCA APIs for cryptography. Please
see https://bitbucket.org/b_c/jose4j/wiki/Home for more info, examples, etc.

This is part of a larger effort to package Jitsi Videobridge in Debian. I
intend to maintain the package as part of the Debian Java team.




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAmCLVLMRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfIbiBAAhgstlO65vB7OX956uZ8JtySEV0KmPt4k
fW3BggkgkuSyIWyGm8f4LGRsx+bIW0uy5VJODuFcUGv56EU9SrXkCEVB/vT1og9d
a9te6RCrVKMUWpgQp4ubnlqUyHUUVXPMmGzOAF0fISU0gniOTPrEuzELMcypN6i/
635SpaGHUg+L/RgdJC39OfmDo8JAUVQTA4SE7wQKMK5/FiIO3EEFtcXlAECxyNjS
fsD879Dx+80mIVSzEMvMeJFt9XLSdLBRNP6BTkOfXBxDHDjbUm2/ri1Tt/SNGNZ1
aI4w2sS9Tw14O3YdGbFRKaGQlxyP+sFJGXBVv/xdsSpbAlbYIB9GqMqnbkL6b81l
15nM2Hy9hr6fk5CwC3uxOj0KittGFucruBdUXpv59py2sa8V5hnWWk1fMDueYbcf
imeJZVL5UQDRdpQO5ktTaD/wk2XGVCYoLI3ksZ618AmHgXR6aTcp6RJ/rZL2cBYQ
F2/dmRHKaxvAWMfR9+b2HSKLYIFmzZEWTP4x9/Fe+SyF0PwpSQ9QL/plmuzY9RhT
iBfjBfJNOeQnQb9O/Ekj4ztCJwe2Gl5lkPoVaWHVyKRuCyBDh6yM7Acdc/1rmzz8
dAvxxZgn6A2u6G7gLUtOt23ATL4z4Oh8vSdsuhGGzWAmKvAvCikTAZJU2QvjXSR6
LnGbwmnjanI=
=HQXm
-END PGP SIGNATURE-



Bug#984760: grub-pc: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)

2021-04-16 Thread Sunil Mohan Adapa
Hi,

The problem is not limited to amd64. I see this problem on arm64. On a
FreedomBox arm64 image, on a Raspberry Pi 3B+ (when booted with UEFI
firmware[1]) when grub efi packages are upgraded, boot fails with the
error 'symbol `grub_is_lockdown` not found'.

Links:
1) https://github.com/pftf/RPi3

Thanks,

-- 
Sunil



Bug#757769: Working on packaging

2021-03-28 Thread Sunil Mohan Adapa
retitle 757769 ITP: jitsi-videobridge -- a WebRTC compatible Selective
Forwarding Unit that allows for multiuser video communication
owner 757769 !
thanks

I am working on packaging Jitsi Videobridge as part of Java Packaging
Team. Jitsi has many dependencies these are now tracked on the wiki:

https://wiki.debian.org/Java/RequestedPackages/Jitsi

Thanks,

-- 
Sunil



OpenPGP_signature
Description: OpenPGP digital signature


Bug#983000: zram-tools: Ship better defaults to suite swap on all hardware

2021-02-17 Thread Sunil Mohan Adapa
Package: zram-tools
Version: 0.3.2.1-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Please consider updating the defaults to make the package suitable for
installation on most Debian machines.

swap-on-zram has the potential to replace conventional swap. Fedora has done
this[1] by default not just for IoT devices but even for desktops. In
FreedomBox, I have proposed to use it as the default swap solution[2].

The current defaults lead to a hard-coded 256MiB of swap space. This is useful
for single board computers with about 512MiB of RAM but not very useful for
other machines. Instead, consider making that 50% of the available RAM. On
systems that don't typically use swap, this will only incur a 0.1% overhead[3].
RAM will not be get pre-allocated for the zram device. It is only allocated
when necessary.

Further, the configuration file /etc/default/zramswap has incorrect description
for PERCENT parameter. It says, "Specifies the amount of RAM that should be
used for zram based on a percentage the total amount of available memory This
takes precedence and overrides SIZE below". The disksize kernel parameter for
the zram device computed using the above configuration option is about the
amount of space available in the newly create block device. The amount of RAM
that the device will consume depends on compression. Typically 1:2 compression
is expected. So, if PERCENT is set to 50% on a 8GiB machine, then 4GiB of swap
space will be available and on an average case that will consume 2GiB of RAM.

What I am proposing is this:

- -# Specifies the amount of RAM that should be used for zram
- -# based on a percentage the total amount of available memory
+# Specifies the size of swap space that should be created with the zram device
+# computed as a percentage of the total amount of available memory.
 # This takes precedence and overrides SIZE below
- -#PERCENT=50
+PERCENT=50

Thank you for packaging and maintaining zram-tools. Also consider systemd-zram-
generator[4].

Links:
1) https://fedoraproject.org/wiki/Changes/SwapOnZRAM
2) https://salsa.debian.org/freedombox-team/freedombox/-/merge_requests/2033
3)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-
guide/blockdev/zram.rst
4) https://github.com/systemd/zram-generator/

- --
Sunil



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

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

Versions of packages zram-tools depends on:
ii  bc  1.07.1-2+b1

zram-tools recommends no packages.

zram-tools suggests no packages.

- -- Configuration Files:
/etc/default/zramswap changed [not included]

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAmAtxbYRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfImUBAArorWb/sGYvZ16N7nMTIK+U/8mciG8LZ7
kF6l3eSweGXjp9eyaP4xjyTAT9JuXfgbey3msR0JR0mjQvAFN2Fp3wNws3h4xC0O
DmrPn2LGczamjX0FZyUs4tDG22zhv7PFPX3NqNtusjZE5WRWxNJrNChl3gBjydW7
QqW7k/vcm2ajpz3csDubVehvIE5qMkK83DFs+/cspQpN7W/B0wgW066mQ9FOGlq5
ozogZKHS6BreDgR7YFxS5EV0HGyG+1umCAAWfMmnY9PK85yGBccWzutcqC81d/xW
PiazkvXWA5U8tlCt+ev8E1OGBwMRxlAq0Vri0rq9+wI0bHHxHCDvOPMtz+p1Yrhh
XzvsocbqqqkmM7VfWova+97zM+QS6RmzwhgfuaALNHtND7F5eeXcZFpbDI+ldr5b
LltQsRBDuHpRFYPPvdy4j4BgN0mbIRgQweLTit3m+iKVXlOtm9TEQlp9E8hXSlg9
2RnBbjhXjFtLhpqoaX1qQZUOGLb8FFTENkWYDljzeP1JjjdpVWGt6/YgMGDTFSX2
mvHdRFSIFKlQR7x99DxMBOcufHmBr75V0j1Rp+S0PWuwYhzwZpHT7yWxFaSghksM
vDVc/ZGJQ+BBBFOXrFHfnlESXqyYelGyubnfU+8xwlRzP7Adpx04s+BxGpdFddgm
LtJEr1/RggI=
=4ibq
-END PGP SIGNATURE-



Bug#932924: tt-rss: Packaging work for new upstream release 21.1

2021-02-05 Thread Sunil Mohan Adapa
On 05/02/21 4:24 pm, Sebastian Reichel wrote:
[...]
> 
> I had some pending work from last year doing some of these changes
> and some additional things. Back then I stopped when reaching the
> gettext part wondering how to be solve it (IIUIC upstream's version
> has some security fixes). Anyways your solution is better than doing
> nothing, so I merged everything together and just uploaded a new
> version.

Just to summarize the situation with php-gettext: the library had a
single security issue with use of eval() when parsing plural expressions
(#976135). In Debian, it now has a proper fix through the implementation
of a plural expression parser instead of using eval(). While there is no
response from upstream for the merge request, tt-rss apparently picked
up the fix in its vendored copy of gettext library. In Debian, tt-rss
uses the Debian package for php-gettext. So, every thing is in good
shape for this security issue.

Other security issues found and fixed in upstream tt-rss (CVE-2020-25787
CVE-2020-25788 CVE-2020-25789) are unrelated to this.

> 
> Your changes all looked sane and I'm mostly busy in the kernel world
> these days and your help is appreciated. If I saw it correctly you are
> not a DD, so I just gave you full permissions to the tt-rss repository.
> Feel free to work directly in the repository without doing pull requests.

Many thanks for permissions to the repository, the recent upload and in
general for tt-rss.

-- 
Sunil



OpenPGP_signature
Description: OpenPGP digital signature


Bug#970633: tt-rss: Packaging work for new upstream release 21.1

2021-02-03 Thread Sunil Mohan Adapa
tag 970633 + patch
tag 932924 + patch
thanks

Hello,

Eagerly looking forward to tt-rss being in good shape for FreedomBox in
Bullseye, I have done the packaging work needed for uploading 21.1
version of tt-rss. Please merge and upload the package into Debian
unstable before the Bullseye Soft Freeze date February 12th. Since this
is a collab-maint package, I assume it would be okay to for others to
upload as well.

* New upstream release based on latest revision 6d8f2221 on 2021-01-29
11:52:21 UTC+0300.
  - Contains security fixes for CVE-2020-25787 CVE-2020-25788
CVE-2020-25789 (Closes: #970633).
* Use latest version of libjs-prototype.
* Refresh patches.
* Ability to update to latest schema version 140.
* Update Debian Standards Version to 4.5.1.
* Update debhelper compatibility to 13 the latest.
* Mark as not requiring root for rules file.
* Add self to list of uploaders.
* Fix various lintian warnings and info messages.
* Document upstream changes since 19.8.
* Add directory for caching feeds.
* Remove the default feed to tt-rss forum to improve privacy. (Closes:
#932924)
* Use material design icons from Debian package.
* Add documentation link in systemd service file.
* Redirect stderr to journal instead of syslog.

Apart from the https://salsa.debian.org/sunilmohan/tt-rss/-/tree/master
branch please also pull in branches
https://salsa.debian.org/sunilmohan/tt-rss/-/tree/pristine-tar and
https://salsa.debian.org/sunilmohan/tt-rss/-/tree/upstream along with
the tags.

I have tested new version as follows:

- DONE: lintian does not show messages with --info --display-info --pedantic
- DONE: SELF_URL_PATH may need a proper value.
- DONE: Prototype JS is working fine (no change since last version)
- DONE: Dojo is loading fine the following pages:
  - DONE: feeds.php
  - DONE: public.php: popup in Feeds -> Bookmarklets -> Share with TTRSS
  - DONE: public.php: forgot password page
  - DONE: public.php: db update page
  - DONE: public.php: subscribe to feed page (possible dead code)
  - DONE: installer: unused in Debian
  - DONE: login_form.php
- DONE: Debian configured DB works
- DONE: Theme looks good, dark theme works
- DONE: Upstream changes files contains changes for 21.1
- DONE: No messages in Apache error log
- DONE: Update service works properly, feeds are updated offline
- DONE: Updates error log is successfully redirected to journal
- DONE: No error messages in journal for updates
- DONE: Material design icons are linked to properly in .deb
- DONE: Material design icons show up in web interface properly
- DONE: Installed DB schema version is 140
  - DONE: Install fresh on MySQL/MariaDB
  - DONE: Install fresh on PostgreSQL
  - DONE: Upgraded from 19.8 on MySQL/MariaDB
  - DONE: Upgraded from 19.8 on PostgreSQL
- DONE: Install fresh on bare Debian works fine
- DONE: With MySQL/MariaDB
- DONE: With PostgreSQL
- DONE: Upgrade from 19.8 on bare Debian work fine
  - DONE: With MySQL
  - DONE: With PostgreSQL
- DONE: Default feed Tiny Tiny RSS Forum is not present by default
  - DONE: On MySQL installation
  - DONE: On PostgreSQL installation
  - DONE: When a new user is created in prefs.

Thanks,

-- 
Sunil



Bug#970501: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

2021-01-29 Thread Sunil Mohan Adapa
tag 970501 + patch
thanks

Hello,

It appears that newer JavaScript versions supported by Rhino cause Dojo
to throw an exception during tests for shrinksafe module. When using an
older JavaScript version 1.7, the error goes away. The attached patch
fixes build and autopkgtest problems.

Please consider applying the patch to ensure that Dojo and its
dependents like tt-rss, used in FreedomBox are available in Bullseye.

Thanks,

-- 
Sunil
>From c92570f765d73aa6c1d717376f81aafa529964c2 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Fri, 29 Jan 2021 17:51:10 -0800
Subject: [PATCH] Fix shrinksafe tests with newer rhino by setting JS version

Signed-off-by: Sunil Mohan Adapa 
---
 .../0004-Fix-shrinksafe-tests-with-new-rhino.patch | 10 ++
 debian/patches/series  |  1 +
 2 files changed, 11 insertions(+)
 create mode 100644 debian/patches/0004-Fix-shrinksafe-tests-with-new-rhino.patch

diff --git a/debian/patches/0004-Fix-shrinksafe-tests-with-new-rhino.patch b/debian/patches/0004-Fix-shrinksafe-tests-with-new-rhino.patch
new file mode 100644
index ..486f939a
--- /dev/null
+++ b/debian/patches/0004-Fix-shrinksafe-tests-with-new-rhino.patch
@@ -0,0 +1,10 @@
+Index: dojo/util/shrinksafe/tests/runner.sh
+===
+--- dojo.orig/util/shrinksafe/tests/runner.sh
 dojo/util/shrinksafe/tests/runner.sh
+@@ -1,4 +1,4 @@
+ #!/bin/sh
+ 
+ cd ../../doh
+-java -classpath ../shrinksafe/js.jar:../shrinksafe/shrinksafe.jar org.mozilla.javascript.tools.shell.Main ../../dojo/dojo.js baseUrl=../../dojo load=doh test=util/shrinksafe/tests/module testUrl=../shrinksafe/tests/module.js
++java -classpath ../shrinksafe/js.jar:../shrinksafe/shrinksafe.jar org.mozilla.javascript.tools.shell.Main -version 170 ../../dojo/dojo.js baseUrl=../../dojo load=doh test=util/shrinksafe/tests/module testUrl=../shrinksafe/tests/module.js
diff --git a/debian/patches/series b/debian/patches/series
index f39e7f29..c75b2155 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 0001-Compatibility-patch-for-newer-rhino.patch
 0002-Do-notrun-test-suite-in-build.patch
 0003-Disable-flash-storage.patch
+0004-Fix-shrinksafe-tests-with-new-rhino.patch
-- 
2.29.2



Bug#970633: tt-rss: CVE-2020-25787 CVE-2020-25788 CVE-2020-25789

2021-01-28 Thread Sunil Mohan Adapa
Dear maintainers,

It appears that updating the package to latest upstream will fix the
security issues. With soft freeze coming up, I was wondering about the
status of tt-rss for Bullseye. It is an important part of FreedomBox and
many users would be affected by its loss.

If time is the issue, I can assist with packaging work and testing. Let
me know.

Thanks,

-- 
Sunil



Bug#979686: mediawiki: Cannot skip installing mariadb & postgresql

2021-01-25 Thread Sunil Mohan Adapa
On Mon, 11 Jan 2021 14:51:38 -0800 Kunal Mehta  wrote:
[...]
> 
> The easiest and most foolproof way would be:
> 
> # apt install mediawiki --no-install-recommends

Joseph has proposed a patch to FreedomBox's MediaWiki app to do just
this. However, using --no-install-recommends is leading us to miss out
some nice-to-have packages from the recommends list. php-gmp, for
example, seems to be used on 32-bit machines for GUID generation and for
finding unused blobs. php-wikidiff2 seems to be better at generating
diffs than its built-in fallback.

So, we will need to explicitly install the recommends list to be safe
about not loosing some functionality. The problem with this is the
handling of updates when a newer version of MediaWiki recommends a
different list.

[...]

I propose a different solution:

What if we add 'sqlite3' into the mix like this: 'default-mysql-server |
virtual-mysql-server | postgresql-contrib | sqlite3'? This way, people
wanting to use sqlite only (including FreedomBox) can run 'apt install
mediawiki php-sqlite3 sqlite3' and get all the other recommends too.
sqlite3 is, strictly speaking, not needed for functioning of MediaWiki
with the sqlite3 DB because the package php-sqlite3 is sufficient.
However, this 1.2MiB package is a (hackish) placeholder to avoid
installing the other databases when installing with recommends. Let me
know if this is acceptable.

Thanks,

-- 
Sunil



Bug#979381: Useless in Debian

2021-01-11 Thread Sunil Mohan Adapa
Hello,

I have filed an RM bug (#979832) against the package and CCed David and
all the uploaders.

Thanks,

-- 
Sunil



Bug#979832: RM: php-db-dataobject -- ROM; unused, no reverse depends

2021-01-11 Thread Sunil Mohan Adapa
Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This package was uploaded as part of effort to get GNU Social into Debian.
There is currently no active interest in uploading GNU social. No other
packages are currently using this library.

Discussion on whether to keep the package as done at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979381

Please remove the package from unstable.

Thanks,

- --
Sunil




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl/8n3gRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfJmFQ/8C9mFuGlfediVXfMWxOTVgUlJMAQr5Evx
iftYUPv/LVQxyjri102sKEVh/RKd+TJL2p8MjzrOy1MnJ+aHbEJeUwvnMXryMnsK
CpKul2Uhs7/JF+06jpYncQfcs4w/VygRIw8G+kySwQF96/T1XkGnnI6qNFWogqFa
Zc8H0Ptq+uRbJ2tQIf3owKno9vi3VcBu85sAs+xywTE1B45G4hS0mUA9K6toBidK
sy32/27rCH1qVO4uQURwpFA11QLim7xfa7LlVbWvOoxXHWf0KbDnmm+Na8gZinrq
tW6KYnRlpC8ZUakczLDQIZDF+BCcqdpdzQqoBIiYvi92YljPqpBq8QKo5sJjDTZL
WTcYVjTgv2qAAgLAxChAfgR2PtAAfB6qrE23wRyIOgzGsSGPUv/imb079lHdUNeK
gF1r++7FsabW27D+JdKPVu2zyEPjV7Ri145hJFxbcXCFnOSAh2sg7AMnZgaSljVW
3XRU8mPWBh1M9LneWAYNr66kj+xpwvIfLUw3Xc0BEyBmuQTpJAjI/1XjeVldqaFH
6iQHXR/orQAY1XESpJQsx3CRSSyJxT/dwn6z5vta9xf9AuwGvUbu89eQgf6qAOUC
czait9AooEJpVk8ROWikufzPLG8cgchLOlJ/7cdW26rHYS5j51njyJdQP8u7OeSO
luY5gewudQs=
=MMk6
-END PGP SIGNATURE-



Bug#979156: [pkg-php-pear] Bug#979156: Useless in Debian

2021-01-11 Thread Sunil Mohan Adapa
On 11/01/21 4:37 am, Guilhem Moulin wrote:
> Control: severity -1 serious
> 
> On Mon, 11 Jan 2021 at 00:58:01 +0100, Guilhem Moulin wrote:
>> On Sun, 03 Jan 2021 at 16:54:41 -0800, Sunil Mohan Adapa wrote:
>>> I will be filing an RM: bug on the package on Jan 10, 2021. I will
>>> wait to see if the other uploaders think it is still needed.
>>
>> Roundcube's test suite which I'm working on now has some tests making
>> use of Net_IDNA2
> 
> On closer look Net_IDNA2 is only used as a fallback when idn_to_{ascii,utf8}()
> do not exist.  Roundcube has a hard dependency on php-intl already, so
> as far as Debian is concerned the part using Net_IDNA2 is dead code.  I
> therefore drop my interest in having php-net-idna2 in Bullseye and
> restore the RC severity :-)
> 
> Appologies for the noise
> 

I filed an RM bug (#979829) and CCed all uploaders and participants of
this bug.

-- 
Sunil



OpenPGP_signature
Description: OpenPGP digital signature


Bug#979829: RM: php-net-idna2 -- ROM; unused, no reverse depends

2021-01-11 Thread Sunil Mohan Adapa
Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This package was uploaded as part of effort to get GNU Social into Debian.
There is currently no active interest in uploading GNU social. No other
packages are currently using this library.

Discussion on whether to keep the package as done at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979156

Please remove the package from unstable.

Thanks,

- --
Sunil




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl/8nDoRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfL0GA/6Atcwno5WTLVNfSaPSD+WWYjgfpCjrHOq
ZAPMHkoBi2c17ZCW94Xi8v8vCzQ9ZE1rSM6ak3nv8mOm4jbzao0S9maD29fc4cAi
djllnKOt44l/PymB0NZ8RllXL0hKHwfQeYXMUhSe3lC+q01DB93db9PtbSFy72QA
Nk1ExLIByy5Qhi5EaSiqvFAzbfk/gZAVJUSnw4MinahhOy6I53Z3vK6P4ce30GKE
4vlbXBRSOieE41Qb0hjToibwqvROXE4iQYPoTR0ctUe+qBwLlheSG1f8QuFtAoc3
HxaIm1wYR1ZVc1Jvx2TJvIKBeCpaLYHT+N5mXSLLUI3kNBn+1j/5aYjTpvsDiLmw
wUQeFsRNT7spu0vFntA4DD7FqBR+5SZodjOpNyixrkVqiwtXG9mbZQXtfI7zZeAm
wdzDsZkNf4zjb14UY51TSEq5+yhbAYyoNI+bdZbd/RKqzhvLaHLnUOrcmzeD8yz2
OfWdgRh917++Dxtn1EYKqYPY5Ej3SPq0558D+U58hPFQpqqibxstBW4Fz42Kmc9A
yfTd0UkRwApO9dgoYMEyK0GAa4rLgqSpqbDoNtoJhTBPiAnaZUNudpzCJyrHOWlO
GIOoMVwx2Y1QQcDyjX4dArTcvJH4+4dyTw8bf6p16+eRsOsf47sntR9RnxxIruAj
J43kqAA7rOs=
=qsVb
-END PGP SIGNATURE-



Bug#979156: [pkg-php-pear] Bug#979156: Useless in Debian

2021-01-10 Thread Sunil Mohan Adapa
Added CC: Rajasekhar Ponakala

On 10/01/21 3:58 pm, Guilhem Moulin wrote:
> Hi all,
> 
> On Sun, 03 Jan 2021 at 16:54:41 -0800, Sunil Mohan Adapa wrote:
>> I will be filing an RM: bug on the package on Jan 10, 2021. I will
>> wait to see if the other uploaders think it is still needed.
> 
> Roundcube's test suite which I'm working on now has some tests making
> use of Net_IDNA2 so I'd like to keep the package around if possible :-)
> I can give a hand and help bringing it up to shape for Bullseye.
> 

I found a migrated repository that seem have to done some work to import
the latest upstream version[1]. Recent most commits incorrectly
overwrote the upstream source with another package's source. Some
reverting and testing should get the package in shape. I can help if needed.

Links:
1) https://salsa.debian.org/php-team/pear/php-net-idna2/

Thanks,

-- 
Sunil



OpenPGP_signature
Description: OpenPGP digital signature


Bug#979156: Useless in Debian

2021-01-03 Thread Sunil Mohan Adapa
On 03/01/21 4:48 pm, David Prévot wrote:
> Hi Sunil,
> 
> Le 03/01/2021 à 20:06, Sunil Mohan Adapa a écrit :
>> On 03/01/21 8:24 am, David Prévot wrote:
> […]
>>> php-net-idna2 was introduced in Debian as part of the gnusocial
>>> packaging effort […]
> 
>>> Unless someone disagree with the above, I intend to ask for removal of
>>> this package soon (so if you read this message years from now, no need
>>> to ask for permission to act on what I’ve failed to…).
> 
>> I see no problem with removing the package. There is currently no active
>> interest in packaging gnusocial. Should I be filing an RM bug?
> 
> No objections on my side, thanks.
> 

Hi David,

I will be filing an RM: bug on the package on Jan 10, 2021. I will wait
to see if the other uploaders think it is still needed.

Thanks,

-- 
Sunil



OpenPGP_signature
Description: OpenPGP digital signature


Bug#979156: Useless in Debian

2021-01-03 Thread Sunil Mohan Adapa
On 03/01/21 8:24 am, David Prévot wrote:
> Package: php-net-idna2
> Severity: serious
> 
> [ Reported by a team member to see the package removed from testing ]
> 
> php-net-idna2 was introduced in Debian as part of the gnusocial
> packaging effort, but its ITP (#782812) has no activity for more than
> three years. Furthermore, php-net-idna2 in Debian seems pretty outdated.
> No packages currently depend on it, so I don’t believe it’s useful to
> keep it around.
> 
> Unless someone disagree with the above, I intend to ask for removal of
> this package soon (so if you read this message years from now, no need
> to ask for permission to act on what I’ve failed to…).
> 
> Thank you Holger for triggering a closer look to this package!
> 

I see no problem with removing the package. There is currently no active
interest in packaging gnusocial. Should I be filing an RM bug?

Thanks,

-- 
Sunil



OpenPGP_signature
Description: OpenPGP digital signature


Bug#977859: ITP: debian-fbx -- Debian FreedomBox Pure Blend Metapackages

2020-12-21 Thread Sunil Mohan Adapa
Package: wnpp
Severity: wishlist
Owner: Sunil Mohan Adapa 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: debian-fbx
  Version : 1
  Upstream Author : FreedomBox packaging team 
* URL : https://salsa.debian.org/blends-team/fbx/
* License : GPL-3+
  Programming Lang: Debian blends framework
  Description : Debian FreedomBox Pure Blend Metapackages

FreedomBox is designed to be your own inexpensive server at home. It runs free
software and offers an increasing number of services ranging from a calendar or
jabber server to a wiki or VPN. A web interface allows you to easily install
and configure your apps. This package provides FreedomBox tasks in tasksel.

The package repository will be at:
https://salsa.debian.org/blends-team/fbx/

This package will be maintained by:
FreedomBox Packaging Team 
Debian Pure Blends Team 

It will be discussed at:
freedombox-pkg-t...@lists.alioth.debian.org
debian-ble...@lists.debian.org




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl/hTBoRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfImhBAAtHbeKUaOib0/cidLVAiwrAGgCTF09fO7
RmqjSQ+lGP08IdMzhlgb3iP0pvtr41eYU2c5h7ZzwbYf110PBeoqbrM6OTB+uyXH
G3lyijiRN9jaxdbkG9Ak754F+VoWXqRgziT4VIQeBOOypTKvOqPP3IqbPUJrASx8
e88RZfe46f9MZkKm/MZI5gn4Li1kvgqOYBEBTl6fO7yXOkxWhEAAWx6/g74dY+MK
q4KBAwLOcrznYQqhtHAfP2Ndv1zWKlCr89rkgdnBNsY9FBp2lgec3PlaZwDrGvxX
HIDT9OxgJMykFjDRT+a4he1Lqzn4ZhHXyrZVC3807YxbUA6lFVbLODIbRoZeAmBZ
7aLdHbxc8Yz3X69xT7U4q2nc6pv/ts6RosZQq0b1nuyNXme72vPOrsUI091Jy3kG
IzJ8piEtPhg77gZcg7gAmwJ7OlTloIky0SC1ckEqv27U9FTsICjOMNuOKPtzJ0yW
muNMEilgBRkHjs5Uk6PDy+7KNgvIMxLfymLiHdZy7OtEZrKq20YWfjyj10Fly2G5
8DUb1irDJMLmT4jDrAVSeM7Ycn9ZA3yLkSz/c8ziNKqI5PyLQ26F+u51XiqyLsLV
iO5yUJhpuamFabUEN8km1YS3IY9BMiAyo2pYdXwlTHHJi5mVMenS+KSKkI2a9G0Z
Ekx6PzxveU4=
=zAr+
-END PGP SIGNATURE-



Bug#977527: freedombox FTBFS: test_homepage_mapping_skip_ci failure

2020-12-19 Thread Sunil Mohan Adapa
tag 977527 + pending
thanks



OpenPGP_signature
Description: OpenPGP digital signature


Bug#976135: Breaks tt-rss

2020-12-02 Thread Sunil Mohan Adapa
tag 976135 + patch
thanks

On Mon, 30 Nov 2020 09:45:48 +0100 Andrey Rahmatullin 
wrote:
[...]
> 
> PHP Fatal error:  Uncaught Error: Call to a member function evaluate() on 
> null in /usr/share/php/php-php-gettext/gettext.php:325

This is a silly error I made in a patch to fix the security issue with
plurals evaluation. I never caught the error as I didn't test
non-English locales. A patch is now available for merge.

https://salsa.debian.org/php-team/pear/php-gettext/-/merge_requests/2

As a workaround to the issue, either use English language until this
issue is fixed or modify the file
/usr/share/php/php-php-gettext/gettext.php line 300

from

if ($this->pluralheader !== NULL) {

to

if ($this->pluralheader === NULL) {

Thanks,

-- 
Sunil



Bug#974989: [Freedombox-pkg-team] Bug#974989: Bug#974989: freedombox: firstboot wizard fails in connection setup (KeyError: 'box_name')

2020-11-17 Thread Sunil Mohan Adapa
On 17/11/20 10:00 am, Petter Reinholdtsen wrote:
> [Dominik George]
>> I installed the freedombox package on a pretty much vanilla Debian
>> installation.
>>
>> The first boot wizard got as far as setting up the connection, and
>> when asked how my router is set up, I chose I do not want to set it up
>> right now. That caused the following exception:
> 
> Just to rule out one cause of error.  Did you select a langauge?
> Perhaps one of the languages have a bug in a format string?

This is likely the issue.

Further, we are also picking up the language preferences set in the
browser by default. So the issue likely happens even before selecting a
language. If so, specifying the list of language priorities in the
browser would help to fix this issue.

-- 
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


Bug#971171: libvirt-dbus: FTBFS: dh_auto_test: error: cd debian/build && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test returned exit code 1

2020-11-05 Thread Sunil Mohan Adapa
tag 971171 + patch
thanks

Dear Maintainers,

In about 5 days, on November 10th, libvirt-dbus will be removed from
testing due to this bug. This shall cause a catastrophic chain reaction
resulting in the removal cockpit and freedombox packages.

The issue already has a fix available, thanks to upstream and Christian
Ehrhardt. The fix is to a test case, so no impact can be expected on the
functioning of the package. Most of this fix is already applied upstream
and should be easy to review as it is just few lines. Since upstream has
not yet tagged a release with this fix, we will need to keep this patch
in Debian. If any further work is needed, such as additional testing, I
can assist.

Please make a release of libvirt-dbus with this fix as soon as possible
and prevent the removal of several popular packages.

Thanks,

-- 
Sunil



Bug#824954: Re:flash-kernel: please provide a way to integrate with GRUB

2020-07-17 Thread Sunil Mohan Adapa
Hello,

For FreedomBox, I experimented with building a single UEFI image for
multiple arm64 boards as described for SUSE[1]. I tested a single UEFI
arm64 image for Rock64, RockPro64 and Raspberry Pi 3B+.

As part this, u-boot will reside on an SPI flash with OS on an eMMC, an
SD card, a USB disk or an NVMe drive. Alternatively, u-boot will reside
on an SD card with OS on a different drive. We can build these tiny
u-boot based firmware images separately or in cases like Raspberry Pi,
provide a build script or provide external references on how to get the
images.

The main OS image will have grub-efi with EFI partition and will not
contain u-boot or u-boot boot script. When u-boot starts from SPI flash
(or SD card), due to distroboot, it will load the DTB file from /dtb of
EFI partition and execute Grub EFI. Grub is responsible for loading the
kernel and initrd while DTB is loaded and passed on to the kernel via
Grub by u-boot. I had to do two hacks to make this happen:

1) Copy /boot/efi/EFI/debian/grubaa64.efi to
/boot/efi/EFI/boot/bootaa64.efi.

2) Copy /usr/lib/linux-image-$(latest)/ to /boot/efi/dtb/. For this I
wrote a small kernel hook script.

flash-kernel could introduce a new 'mode' of operation, say 'efi-dtb',
to help with hack number two. It will have to copy the latest kernel
dtbs recursively to /boot/efi/dtb.

FreedomBox is currently building an image for each of the boards it
supports. Being able to build a single image for all boards of an
architecture is a great simplification. Further more, image will contain
completely free software even for boards like Raspberry Pi (because
non-free firmware need not be shipped by the project).

Links:

1) https://www.suse.com/media/article/UEFI%20on%20Top%20of%20U-Boot.pdf

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#851771: php-gettext: CVE-2016-6175

2020-07-15 Thread Sunil Mohan Adapa
I seem to have attached the wrong set of patches to this bug earlier.
Here are the correct ones. Upstream bug already has the correct set of
patches.

-- 
Sunil
From 0a325e7847daf150885911706926b7b8f5d7a66e Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Wed, 17 Jun 2020 14:07:30 -0700
Subject: [PATCH 1/2] Use custom parser for parsing plural expressions instead
 of eval()

- A simple operator-precedence parser that prioritizes simplicity and
readability. Avoid using eval() for evaluating plural expressions.
  - Fixes CVE-2016-6175.
  - Fixes upstream bug https://bugs.launchpad.net/php-gettext/+bug/1606184
  - Fixes Debian bug https://bugs.debian.org/851771

- Grammar for parsing code is same as the grammar for GNU gettext library:
  http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/plural.y

- Extensive tests for various locales with help from Unicode's plurals rules.
Tests for invalid syntax and expression parsing.

Signed-off-by: Sunil Mohan Adapa 
---
 Makefile  |   4 +-
 gettext.php   |  53 +
 plurals.php   | 461 ++
 tests/PluralsTest.php | 351 
 4 files changed, 823 insertions(+), 46 deletions(-)
 create mode 100644 plurals.php
 create mode 100644 tests/PluralsTest.php

diff --git a/Makefile b/Makefile
index b56394b..eda1408 100644
--- a/Makefile
+++ b/Makefile
@@ -5,6 +5,7 @@ DIST_FILES = \
 	gettext.php \
 	gettext.inc \
 	streams.php \
+	plurals.php \
 	AUTHORS \
 	README  \
 	COPYING \
@@ -18,7 +19,8 @@ DIST_FILES = \
 	examples/locale/de_CH/LC_MESSAGES/messages.mo \
 	examples/update \
 	tests/LocalesTest.php \
-	tests/ParsingTest.php
+	tests/ParsingTest.php \
+	tests/PluralsTest.php
 
 check:
 	phpunit --verbose tests
diff --git a/gettext.php b/gettext.php
index 171d14e..0a121f7 100755
--- a/gettext.php
+++ b/gettext.php
@@ -21,6 +21,8 @@
 
 */
 
+require('plurals.php');
+
 /**
  * Provides a simple gettext replacement that works independently from
  * the system's gettext abilities.
@@ -269,41 +271,6 @@ class gettext_reader {
 }
   }
 
-  /**
-   * Sanitize plural form expression for use in PHP eval call.
-   *
-   * @access private
-   * @return string sanitized plural form expression
-   */
-  function sanitize_plural_expression($expr) {
-// Get rid of disallowed characters.
-$expr = preg_replace('@[^a-zA-Z0-9_:;\(\)\?\|\&=!<>+*/\%-]@', '', $expr);
-
-// Add parenthesis for tertiary '?' operator.
-$expr .= ';';
-$res = '';
-$p = 0;
-for ($i = 0; $i < strlen($expr); $i++) {
-  $ch = $expr[$i];
-  switch ($ch) {
-  case '?':
-$res .= ' ? (';
-$p++;
-break;
-  case ':':
-$res .= ') : (';
-break;
-  case ';':
-$res .= str_repeat( ')', $p) . ';';
-$p = 0;
-break;
-  default:
-$res .= $ch;
-  }
-}
-return $res;
-  }
-
   /**
* Parse full PO header and extract only plural forms line.
*
@@ -330,14 +297,14 @@ class gettext_reader {
 $this->load_tables();
 
 // cache header field for plural forms
-if (! is_string($this->pluralheader)) {
+if ($this->pluralheader !== NULL) {
   if ($this->enable_cache) {
 $header = $this->cache_translations[""];
   } else {
 $header = $this->get_translation_string(0);
   }
   $expr = $this->extract_plural_forms_header_from_po_header($header);
-  $this->pluralheader = $this->sanitize_plural_expression($expr);
+  $this->pluralheader = new PluralHeader($expr);
 }
 return $this->pluralheader;
   }
@@ -354,16 +321,12 @@ class gettext_reader {
   throw new InvalidArgumentException(
 "Select_string only accepts integers: " . $n);
 }
-$string = $this->get_plural_forms();
-$string = str_replace('nplurals',"\$total",$string);
-$string = str_replace("n",$n,$string);
-$string = str_replace('plural',"\$plural",$string);
+$plural_header = $this->get_plural_forms();
+$plural = $plural_header->expression->evaluate($n);
 
-$total = 0;
-$plural = 0;
+if ($plural < 0) $plural = 0;
+if ($plural >= $plural_header->total) $plural = $plural_header->total - 1;
 
-eval("$string");
-if ($plural >= $total) $plural = $total - 1;
 return $plural;
   }
 
diff --git a/plurals.php b/plurals.php
new file mode 100644
index 000..1c6ce12
--- /dev/null
+++ b/plurals.php
@@ -0,0 +1,461 @@
+
+
+   Drop in replacement for native gettext.
+
+   This file is part of PHP-gettext.
+
+   PHP-gettext is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   PHP-gettext is d

Bug#851771: php-gettext: CVE-2016-6175

2020-06-17 Thread Sunil Mohan Adapa
tag 851771 + patch
thanks

Hello,

TT-RSS is an important application for FreedomBox and it continues to
use php-gettext library. TT-RSS is currently not available for testing.
It would be nice to have it back.

To address this, I have implemented a parser for the plurals expressions
instead of using the eval() method as discussed in the upstream bug as
solution. This patch is under the same license as php-gettext (GPLv2 or
higher).

- A simple operator-precedence parser that prioritizes simplicity and
readability. Avoid using eval() for evaluating plural expressions.
  - Fixes CVE-2016-6175.
  - Fixes upstream bug https://bugs.launchpad.net/php-gettext/+bug/1606184
  - Fixes Debian bug https://bugs.debian.org/851771

- Grammar for parsing code is same as the grammar for GNU gettext
library:
http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/plural.y

- Extensive tests for various locales with help from Unicode's plurals
rules. Tests for invalid syntax and expression parsing.

This patch has been submitted upstream at
https://bugs.launchpad.net/php-gettext/+bug/1606184 . Please consider
applying the patch in Debian if the upstream doesn't do so shortly.

Thanks,

-- 
Sunil
From ebe92d9d97dc21b82225c6a7977adf87dd00f799 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 11 Jun 2020 15:00:34 -0700
Subject: [PATCH] Iterate user table in a sorted way, fix tests with latest
 glib

This is primarily to help test cases which assume that the adopted algorithm
prioritizes the users in the exact reverse order they appear in the test
cases (and get inserted into the session in reverse order). With older glib
version, the five users being inserted happened to return the order expected by
the tests. With latest glib, due to a minor tweak in hashing strategy, the
insertion leads to unsorted list leading to failed tests.

In addition, GHashTable makes no guarantees about the stability of items when
iterating multiple times. Since the algorithm is sensitive to order of users, it
is best to return users in an order that is consistent over multiple calls and
stable over insert/remove operations.

This patch maintains a sorted list of user ids and uses it for iteration.

Closes: #22.

Signed-off-by: Sunil Mohan Adapa 
---
 libinfinity/common/inf-user-table.c | 51 -
 1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/libinfinity/common/inf-user-table.c b/libinfinity/common/inf-user-table.c
index 11b06b4..cb44ef5 100644
--- a/libinfinity/common/inf-user-table.c
+++ b/libinfinity/common/inf-user-table.c
@@ -36,15 +36,11 @@
  * users within the session.
  */
 
-typedef struct _InfUserTableForeachUserData InfUserTableForeachUserData;
-struct _InfUserTableForeachUserData {
-  InfUserTableForeachUserFunc func;
-  gpointer user_data;
-};
-
 typedef struct _InfUserTablePrivate InfUserTablePrivate;
 struct _InfUserTablePrivate {
   GHashTable* table;
+  /* To be able to iterate users in sorted order */
+  GSList* user_ids;
   /* TODO: It would be smarter to map the hash table to a helper struct
* which stores the user availability, locality and the InfUser object */
   GSList* availables;
@@ -179,15 +175,11 @@ inf_user_table_lookup_user_by_name_func(gpointer key,
   return FALSE;
 }
 
-static void
-inf_user_table_foreach_user_func(gpointer key,
- gpointer value,
- gpointer user_data)
+static gint
+inf_user_ids_list_sort_compare_func(gconstpointer a,
+gconstpointer b)
 {
-  InfUserTableForeachUserData* data;
-  data = (InfUserTableForeachUserData*)user_data;
-
-  data->func(INF_USER(value), data->user_data);
+  return GPOINTER_TO_UINT(a) - GPOINTER_TO_UINT(b);
 }
 
 static void
@@ -197,6 +189,7 @@ inf_user_table_init(InfUserTable* user_table)
   priv = INF_USER_TABLE_PRIVATE(user_table);
 
   priv->table = g_hash_table_new_full(NULL, NULL, NULL, NULL);
+  priv->user_ids = NULL;
   priv->availables = NULL;
   priv->locals = NULL;
 }
@@ -216,6 +209,9 @@ inf_user_table_dispose(GObject* object)
   g_slist_free(priv->availables);
   priv->availables = NULL;
 
+  g_slist_free(priv->user_ids);
+  priv->user_ids = NULL;
+
   g_hash_table_foreach(
 priv->table,
 inf_user_table_dispose_foreach_func,
@@ -256,6 +252,12 @@ inf_user_table_add_user_handler(InfUserTable* user_table,
   g_hash_table_insert(priv->table, GUINT_TO_POINTER(id), user);
   g_object_ref(user);
 
+  priv->user_ids = g_slist_insert_sorted(
+priv->user_ids,
+GUINT_TO_POINTER(id),
+inf_user_ids_list_sort_compare_func
+  );
+
   g_signal_connect(
 G_OBJECT(user),
 "notify::status",
@@ -314,6 +316,8 @@ inf_user_table_remove_user_handler(InfUserTable* user_table,
 );
   }
 
+  priv->user_ids = g_slist_remove(priv->user_ids, GUINT_TO_POINTER(id));
+
   inf_user_table_unref_user(user_table, user);
   g_assert(g_ha

Bug#935614: libinfinity: FTBFS on all architectures

2020-06-11 Thread Sunil Mohan Adapa
tag 935614 + patch
thanks

Hello,

Thank you for looking into this issue.

The problem is due to reliance on particular ordering when iterating
hash table in tests. The bug is triggered by a minor tweak to hash table
algorithm in glib.

I proposed two patches on the upstream issue to fix the problem. They
are also attached here. They are alternate approaches and any one of
them will fix the problem. If the upstream takes time to fix, please
consider applying one of the patches to Debian as infinoted is currently
not available in Debian/FreedomBox testing.

Thanks,

-- 
Sunil
From ebe92d9d97dc21b82225c6a7977adf87dd00f799 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 11 Jun 2020 15:00:34 -0700
Subject: [PATCH] Iterate user table in a sorted way, fix tests with latest
 glib

This is primarily to help test cases which assume that the adopted algorithm
prioritizes the users in the exact reverse order they appear in the test
cases (and get inserted into the session in reverse order). With older glib
version, the five users being inserted happened to return the order expected by
the tests. With latest glib, due to a minor tweak in hashing strategy, the
insertion leads to unsorted list leading to failed tests.

In addition, GHashTable makes no guarantees about the stability of items when
iterating multiple times. Since the algorithm is sensitive to order of users, it
is best to return users in an order that is consistent over multiple calls and
stable over insert/remove operations.

This patch maintains a sorted list of user ids and uses it for iteration.

Closes: #22.

Signed-off-by: Sunil Mohan Adapa 
---
 libinfinity/common/inf-user-table.c | 51 -
 1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/libinfinity/common/inf-user-table.c b/libinfinity/common/inf-user-table.c
index 11b06b4..cb44ef5 100644
--- a/libinfinity/common/inf-user-table.c
+++ b/libinfinity/common/inf-user-table.c
@@ -36,15 +36,11 @@
  * users within the session.
  */
 
-typedef struct _InfUserTableForeachUserData InfUserTableForeachUserData;
-struct _InfUserTableForeachUserData {
-  InfUserTableForeachUserFunc func;
-  gpointer user_data;
-};
-
 typedef struct _InfUserTablePrivate InfUserTablePrivate;
 struct _InfUserTablePrivate {
   GHashTable* table;
+  /* To be able to iterate users in sorted order */
+  GSList* user_ids;
   /* TODO: It would be smarter to map the hash table to a helper struct
* which stores the user availability, locality and the InfUser object */
   GSList* availables;
@@ -179,15 +175,11 @@ inf_user_table_lookup_user_by_name_func(gpointer key,
   return FALSE;
 }
 
-static void
-inf_user_table_foreach_user_func(gpointer key,
- gpointer value,
- gpointer user_data)
+static gint
+inf_user_ids_list_sort_compare_func(gconstpointer a,
+gconstpointer b)
 {
-  InfUserTableForeachUserData* data;
-  data = (InfUserTableForeachUserData*)user_data;
-
-  data->func(INF_USER(value), data->user_data);
+  return GPOINTER_TO_UINT(a) - GPOINTER_TO_UINT(b);
 }
 
 static void
@@ -197,6 +189,7 @@ inf_user_table_init(InfUserTable* user_table)
   priv = INF_USER_TABLE_PRIVATE(user_table);
 
   priv->table = g_hash_table_new_full(NULL, NULL, NULL, NULL);
+  priv->user_ids = NULL;
   priv->availables = NULL;
   priv->locals = NULL;
 }
@@ -216,6 +209,9 @@ inf_user_table_dispose(GObject* object)
   g_slist_free(priv->availables);
   priv->availables = NULL;
 
+  g_slist_free(priv->user_ids);
+  priv->user_ids = NULL;
+
   g_hash_table_foreach(
 priv->table,
 inf_user_table_dispose_foreach_func,
@@ -256,6 +252,12 @@ inf_user_table_add_user_handler(InfUserTable* user_table,
   g_hash_table_insert(priv->table, GUINT_TO_POINTER(id), user);
   g_object_ref(user);
 
+  priv->user_ids = g_slist_insert_sorted(
+priv->user_ids,
+GUINT_TO_POINTER(id),
+inf_user_ids_list_sort_compare_func
+  );
+
   g_signal_connect(
 G_OBJECT(user),
 "notify::status",
@@ -314,6 +316,8 @@ inf_user_table_remove_user_handler(InfUserTable* user_table,
 );
   }
 
+  priv->user_ids = g_slist_remove(priv->user_ids, GUINT_TO_POINTER(id));
+
   inf_user_table_unref_user(user_table, user);
   g_assert(g_hash_table_lookup(priv->table, GUINT_TO_POINTER(id)) == user);
   g_hash_table_remove(priv->table, GUINT_TO_POINTER(id));
@@ -646,21 +650,22 @@ inf_user_table_foreach_user(InfUserTable* user_table,
 gpointer user_data)
 {
   InfUserTablePrivate* priv;
-  InfUserTableForeachUserData data;
+  InfUser* user;
+  GSList* item;
+
+  guint user_id;
 
   g_return_if_fail(INF_IS_USER_TABLE(user_table));
   g_return_if_fail(func != NULL);
 
   priv = INF_USER_TABLE_PRIVATE(user_table);
 
-  data.func = func;
-  data.user_data = user_data;
-
-  g_hash_table_foreach(
-priv->table,
-inf_user_table_foreac

Bug#962166: RM: freedombox-setup -- ROM; obsolete, transitional, no reverse dependencies

2020-06-04 Thread Sunil Mohan Adapa
Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

freedombox-setup package used to ship a lot of scripts that would perform setup
for a typical FreedomBox system. All of the functionality of these scripts has
since been moved to freedombox package itself and are done in a better way
providing configurability.

freedombox-setup, since Debian Buster, is only a transitional package that
depends on freedombox package. It is not needed for Debian Bullseye.

I am one of the maintainers of the package and I am also part of the FreedomBox
packaging team. Removal of this package has been discussed and agreed upon
within the team.

Please remove the package freedombox-setup from unstable.

Thanks,

- --
Sunil




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl7Yj8wRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfJ1MBAArrgV8kCeib5kcyjBcNls+us2dGV7rxEe
g23HqEAJCDFkFUJgasSWBCC7im2s4x1OW8Rx9A7urmmwVaC7OBuJlW/n0uMulL59
7+m2ApuJFUhPMsV5Y8EvxmVk5ELMS2KHYhiDssM8EsiVQudMWN8mB2zBWtDlyy5V
7FIBDPrNVBaZZS2y5c+KG6XsdbFhGRpcwxM6Fs2IZTx6J/daKh4JGNAN9M4Xk1Jc
FslxfqRVj7+rBbqCZfLiOMPABirNY7QynIYCYQq6QLpY5J8A/4RqRHYORgkV+BrH
SQE9/ilaMqa7wLfDSaOyd7p2vdwBe0tIFwexuj4R/IFrrcM/PeSf++q1D7bifGHJ
B7I0mswiRDooX2JxXymfVMrJwToZ55ePiVw74gzzCxTYuV7lZxpph/r+VoBooSZg
dL3PHEbJiHG+dCeBdzYvJQaPUDD4nDqKb0FcQ6x+l4AEmqIrPBhm9ViYbOG1s+oe
NY+mfBbWVnJFmaabym3rl/z3/3FvX/dZwGD/8k1lcUqABoC/+995qZIcFJ72AYpX
xtDu6Mxept5sSyWuephpR6n4pTTTKy2lj4D1oFProIdjPGt7FOKnSOVzXV+34NcU
LNdp+XbbH9pCNQQO4Fy8psu+duwQ7HSKqAJ265XgTTMhOwRWIvI3Ng2l1ZeDlDqW
pHaYCeA0byc=
=dSK/
-END PGP SIGNATURE-



Bug#962084: Adding buster-backport to apt sources on install seems wrong

2020-06-03 Thread Sunil Mohan Adapa
severity 962084 important
thanks

FreedomBox does not ship the sources file or install it during post
installation phase. It only sets up the file during system configuration
step when first executed. This is similar to how it enables automatic
upgrades, enables a firewall etc. This to my understanding is not a
violation of Debian policy. I am reducing the severity accordingly.

This should allow FreedomBox to migrate to testing bringing unrelated
important fixes.

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#962160: buster-pu: package pagekite/0.5.9.3-2

2020-06-03 Thread Sunil Mohan Adapa
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This update proposes to fix bug #961984. Pagekite shipped certificates
internally which are now expired (as of 2020-05-31). All users of Pagekite are
unable to use the package securely as it can no longer make TLS connections to
frontend servers. This update makes Pagekite use Debian certificate database
instead of internal certificates (by shipping an additional configuration
file). Further information from upstream:
https://pagekite.wordpress.com/2020/05/30/tls-certificate-validation-issues/

The fix has been uploaded to unstable as part of pagekite/1.5.2.200531-1.
Source debdiff is attached. The patch has been tested as follows:

Installed and configured Pagekite on Debian Buster. In logs it shows that it is
unable to connect to the frontend server due TLS connection failures. Upgraded
to Pagkite with fix. Pagekite automatically restarts and connects properly to
the frontend server as per logs. The services on the Pagekite domain become
available after that.

This is an urgent fix that must go into stable-updates because the package
becomes unusable to most users without the fix.

Please let know if you need any more information.

Thanks,

- --
Sunil


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

Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl7Yb5oRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfJEtRAAgQZWqu+XGN6HSgnZzoJdAhHreeHmqqNQ
S55/Du+xKopP0nx9Inup65SkdUwXCbwKqfdOMrgpvApAkMNa05abxcR9SQ8fi+ex
3kaaQm7DoC9tmlFnVe7bDyozHXbkOYoywj+bBbdTMYpQkezrSNNgZv7w14Du3wio
44acL6gqiUUPoG5wsBg664aWVtNpGKO7FQZpLN72FsTeE8XGN5seERIb/Cw6xU9m
S9/1qF5C/HajuZLkkcVPQBXDt+MGc5KS8L3PJiKqyNcxnfZ+x/WFcSfBrXDLoLVJ
Ga1ZMcs8U4gggEzSjgZTYn0oy5kWeRcAofhmTBjecRS64SUcHLM41KZHfir9Gkd+
QrZH8PMJSapzUiORA1ahhE1tvX5VYeHfLXpSts4nK8z+NTIjpuRiT86nN11vOSag
9eN6gh3INiD7RbmBGtOpTkSV6Dv33bP7YQxwIRns0YZ6d73Gocjby14d1NuUwcNQ
shgK2wXt3PwadKYaadBv2YPZIgtJDat/niVb9mMbJJl/EqUxou5vfiOqJzhdXYI0
IHjYBeSAZGJwrmUGO4IwO/SMkMViJwuODsJjVS++Ws4ba4ubeBuWfAWarxcXQwtL
Lhu6aZxTlecPUTLYghWY1jOqe67Xy9nfp6SMNt6hizy9tN9QntInzk2pbbWzi01m
oqSgncIG2A0=
=MHb2
-END PGP SIGNATURE-
diff -Nru pagekite-0.5.9.3/debian/changelog pagekite-0.5.9.3/debian/changelog
--- pagekite-0.5.9.3/debian/changelog   2018-03-30 07:54:06.0 -0700
+++ pagekite-0.5.9.3/debian/changelog   2020-06-03 18:10:32.0 -0700
@@ -1,3 +1,10 @@
+pagekite (0.5.9.3-2+deb10u1) UNRELEASED; urgency=medium
+
+  * Fix issue with expired internal certificates. Use
+Debian certificates instead of internal certificate. (Closes: #961984)
+
+ -- Sunil Mohan Adapa   Wed, 03 Jun 2020 18:10:32 -0700
+
 pagekite (0.5.9.3-2) unstable; urgency=medium
 
   [ Petter Reinholdtsen ]
diff -Nru pagekite-0.5.9.3/debian/control pagekite-0.5.9.3/debian/control
--- pagekite-0.5.9.3/debian/control 2018-03-30 07:54:06.0 -0700
+++ pagekite-0.5.9.3/debian/control 2020-06-03 18:10:32.0 -0700
@@ -23,6 +23,7 @@
 Package: pagekite
 Architecture: all
 Depends: ${misc:Depends}, ${python:Depends}
+ , ca-certificates
  , daemon (>= 0.6)
  , python-socksipychain (>= 2.0.15)
  , python-openssl
diff -Nru pagekite-0.5.9.3/debian/patches/0002-use-debian-certificates.patch 
pagekite-0.5.9.3/debian/patches/0002-use-debian-certificates.patch
--- pagekite-0.5.9.3/debian/patches/0002-use-debian-certificates.patch  
1969-12-31 16:00:00.0 -0800
+++ pagekite-0.5.9.3/debian/patches/0002-use-debian-certificates.patch  
2020-06-03 18:10:32.0 -0700
@@ -0,0 +1,18 @@
+Description: Use Debian certificates instead of internal certificates
+ This is to make Pagekite use certificates shipped by Debian. Otherwise by
+ default, it uses internallly shipped certificates that may be outdated. See:
+ https://pagekite.wordpress.com/2020/05/30/tls-certificate-validation-issues/
+Author: Sunil Mohan Adapa 
+
+--- /dev/null
 b/etc/pagekite.d/90_debian_certs.rc
+@@ -0,0 +1,9 @@
++#
++# This is to make Pagekite use certificates shipped by Debian. Otherwise by
++# default, it uses internallly shipped certificates that may be outdated. See:
++# https://pagekite.wordpress.com/2020/05/30/tls-certificate-validation-issues/
++#
++# If you wish to override this setting, create another file starting with a
++# number higher than 90.
++#
++ca_certs = /etc/ssl/certs/ca-certificates.crt
diff -Nru pagekite-0.5.9.3/debian/patches/series 
pagekite-0.5.9.3/debian/patches/series
--- pagekite-0.5.9.3/debian/patches/series  2018-03-30 07:54:06.0 

Bug#962084: Adding buster-backport to apt sources on install seems wrong

2020-06-03 Thread Sunil Mohan Adapa
On 03/06/20 12:35 am, Christian Ehrhardt wrote:
> Package: plinth
> Version: 20.10
> severity: serious
> 
> Hi,
> running into issues today I realized that the new freedombox 20.10
> places this file on disk:
> $ cat /etc/apt/sources.list.d/freedombox2.list
>   # This file is managed by FreedomBox, do not edit.
>   # Allow carefully selected updates to 'freedombox' from backports.
>   deb http://deb.debian.org/debian buster-backports main
>   deb-src http://deb.debian.org/debian buster-backports main
> 
> IMHO a package should not on-install mess with apt sources. Users just
> don't expect this or the follow on consequences that can happen.
> For example you are pinning python packages from backports which I'd
> expect might lead to quite some dependency hell with other things installed.
> 
> I was facing this in Ubuntu where it is even more wrong and essentially
> breaking `apt update`, but IMHO it is even wrong if not outright
> forbidden by some policy in Debian. I mean adding 'buster-backports' and
> pinning to them in e.g. 'sid' - to me that sounds like calling for trouble.
> 
> I'd ask you to reconsider and remove this behavior. If you want/need to
> keep it then maybe at least consider adding a skip if `dpkg-vendor
> --derives-from Ubuntu` is true. Would that work better for you?

Thank you for the bug report.

We are planning to restrict selection of backports to Debian. A fix
should be available soon[1]]. Pinning of packages should not effect
non-Debian distributions. Packages will be installed from Backports if
available and if only if they are higher version. In all other cases
they will be installed from other sources and pinned priorities won't
effect in any way.

Beyond that we are also planning to make the selection of backports an
explicit step in the user interface (restricted to Debian)[2].

Links:

1) https://salsa.debian.org/freedombox-team/freedombox/-/merge_requests/1824

2) https://salsa.debian.org/freedombox-team/freedombox/-/issues/1855

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#961733: freedombox: Please remove Recommends: haveged

2020-05-28 Thread Sunil Mohan Adapa
On 28/05/20 6:43 am, Chris Hofstaedtler wrote:
> Package: freedombox
> Version: 20.9
> Severity: wishlist
> 
> Dear Maintainer,
> 
> your package currently Recommends: haveged. On modern kernels, so
> whatever will ship in bulleye, the kernel will provide enough entropy,
> so there should be no need for haveged, except in exceptional
> situations.
> 
> Please remove the Recommends: haveged.
> 

Hi Chris,

Thank you for the bug report. Since the report indicates that Buster
will likely still need it, do you see any issue with keeping it for
Bullseye (currently we are testing the same code base for Bullseye and
Buster backports)? Also, any pointers to the behavior of modern kernels
would be nice.

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#959742: closed by Debian FTP Masters (reply to Ondřej Surý ) (Bug#959742: fixed in php-defaults 76)

2020-05-11 Thread Sunil Mohan Adapa
Dear Ondřej,

Many thanks for fixing this.

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#959742: Also affects mediawiki-jobrunner

2020-05-04 Thread Sunil Mohan Adapa
Hello,

In FreedomBox, I tried to workaround[1] this problem by detecting the
version of php package and then append that version to the php command
like this php{version}. This worked and the installed proceeded.

However, the mediawiki-jobrunner service fails again due the same bug as
it runs `/usr/bin/php /var/lib/mediawiki/maintenance/runJobs.php --wait
--maxjobs=50`.

Thanks,

Links:

1) https://salsa.debian.org/freedombox-team/freedombox/-/merge_requests/1785

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#959742: php-defaults: Mismatch between php-cli version and /usr/bin/php version

2020-05-04 Thread Sunil Mohan Adapa
Source: php-defaults
Version: 2:7.3+69
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Problem:

Mediawiki is not installable in testing (via FreedomBox). After running `apt
install mediawiki` running `php /usr/share/mediawiki/maintenance/install.php
...` throws the following error:

  Error: Missing one or more required components of PHP.
  You are missing a required extension to PHP that MediaWiki needs.
  Please install:
   * mbstring 
   * xml 

  PHP Warning: PHP Startup: Unable to load dynamic library 'apc.so' (tried:
/usr/lib/php/20190902/apc.so (/usr/lib/php/20190902/apc.so: undefined symbol:
zif_apcu_store), /usr/lib/php/20190902/apc.so.so
(/usr/lib/php/20190902/apc.so.so: cannot open shared object file: No such file
or directory)) in Unknown on line 0

Expectation:

mediawiki package already has dependency on php-xml and php-mbstring. So, these
packages should be found by the command 'php' and installation should proceed
without error.

Analysis:

It turns out that /usr/bin/php is pointing to PHP version 7.4. However, when
mediawiki depends on php-xml, php-mbstring etc, it is installing all the
libraries for PHP version 7.3, that is, php7.3-xml, php7.3-mbstring. PHP 7.4
would not have been installed on the system normally at all. However, mediawiki
depends on php-apcu which seems to bring in PHP 7.4 (don't know how, but
removing php7.4-common removes php-apcu).

Possible solution:

When all the php-* packages point a version of PHP, that is the version that
command line PHP in /usr/bin/php (and FPM socket, etc.) should point to. This
means that /usr/bin/php should not point to the latest version of PHP but the
version that php-defaults depends on. Then installing a PHP app via apt and
then using it via command line (or FPM) will work without problems.

Install packages on the system:

# dpkg -l mediawiki
ii  mediawiki  1:1.31.7-1   all  website engine for collaborative
work

# dpkg -l php*
ii  php2:7.3+69   all  server-side, HTML-
embedded scripting language (default)
ii  php-apcu   5.1.18+4.0.11-1+b1 amd64APC User Cache for PHP
ii  php-apcu-bc1.0.5-2+b1 amd64APCu Backwards
Compatibility Module
ii  php-common 2:69   all  Common files for PHP
packages
ii  php-curl   2:7.3+69   all  CURL module for PHP
[default]
ii  php-fpm2:7.3+69   all  server-side, HTML-
embedded scripting language (FPM-CGI binary) (default)
ii  php-intl   2:7.3+69   all  Internationalisation
module for PHP [default]
ii  php-mbstring   2:7.3+69   all  MBSTRING module for PHP
[default]
ii  php-sqlite32:7.3+69   all  SQLite3 module for PHP
[default]
ii  php-wikidiff2  1.10.0-1+b1amd64external diff engine for
mediawiki
ii  php-xml2:7.3+69   all  DOM, SimpleXML, WDDX,
XML, and XSL module for PHP [default]
ii  php7.3 7.3.15-3   all  server-side, HTML-
embedded scripting language (metapackage)
ii  php7.3-cli 7.3.15-3   amd64command-line interpreter
for the PHP scripting language
ii  php7.3-common  7.3.15-3   amd64documentation, examples
and common module for PHP
ii  php7.3-curl7.3.15-3   amd64CURL module for PHP
ii  php7.3-fpm 7.3.15-3   amd64server-side, HTML-
embedded scripting language (FPM-CGI binary)
ii  php7.3-intl7.3.15-3   amd64Internationalisation
module for PHP
ii  php7.3-json7.3.15-3   amd64JSON module for PHP
ii  php7.3-mbstring7.3.15-3   amd64MBSTRING module for PHP
ii  php7.3-opcache 7.3.15-3   amd64Zend OpCache module for
PHP
ii  php7.3-readline7.3.15-3   amd64readline module for PHP
ii  php7.3-sqlite3 7.3.15-3   amd64SQLite3 module for PHP
ii  php7.3-xml 7.3.15-3   amd64DOM, SimpleXML, WDDX,
XML, and XSL module for PHP
ii  php7.4-cli 7.4.5-1amd64command-line interpreter
for the PHP scripting language
ii  php7.4-common  7.4.5-1amd64documentation, examples
and common module for PHP
ii  php7.4-json7.4.5-1amd64JSON module for PHP
ii  php7.4-opcache 7.4.5-1amd64Zend OpCache module for
PHP
ii  php7.4-phpdbg  7.4.5-1amd64server-side, HTML-
embedded scripting language (PHPDBG binary)
ii  php7.4-readline7.4.5-1amd64readline module for PHP




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

Kernel: 

Bug#952359: Please apply the patch and upload

2020-03-30 Thread Sunil Mohan Adapa
Hello,

Only a few days remain until the package is removed from testing because
of this bug. As a consequence, libjs-jsxc, which is used in FreedomBox
to provide a web-based XMPP client will also be removed.

Please consider applying the attached simple patch and prevent removal
this package and its reverse dependencies.

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


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

2020-03-10 Thread Sunil Mohan Adapa
tag 952359 + patch
thanks

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

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

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

Thanks,

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

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

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



signature.asc
Description: OpenPGP digital signature


Bug#951440: [Freedombox-pkg-team] Bug#951440: plinth: [INTL:ru] Russian debconf templates translation

2020-02-17 Thread Sunil Mohan Adapa
tags -1 + pending
thanks

Thank you for the patch. I have applied it on master.

Also, the Russian translation for FreedomBox web interface could use
some help, if you are interested[1].

https://hosted.weblate.org/projects/freedombox/plinth/ru/

-- 
Sunil

On 16/02/20 7:59 am, Lev Lamberov wrote:
> Source: plinth
> Severity: wishlist
> Tags: l10n patch
> 
> Dear Maintainer,
> 
> please, find attached the debconf templates translation into Russian.
> 
> Cheers!
> Lev Lamberov
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
> LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> 
> ___
> Freedombox-pkg-team mailing list
> freedombox-pkg-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/freedombox-pkg-team
> 



signature.asc
Description: OpenPGP digital signature


Bug#950249: Patch submitted upstream

2020-02-01 Thread Sunil Mohan Adapa
This bug is due to a gap in Python 3 support for pagekite. I submitted
upstream patches to fix the problem. New or patched versions of
socksipychain and pagekite will be needed.

https://github.com/pagekite/PySocksipyChain/pull/10
https://github.com/pagekite/PyPagekite/pull/75

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#938184: Issue resolved

2020-01-30 Thread Sunil Mohan Adapa
tag 938184 + pending
tag 947812 + pending
tag 948930 + pending
thanks

I have pushed fixes for these issues into the package repository.
Requested an upload.

Thank you,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing

2020-01-04 Thread Sunil Mohan Adapa
On 04/01/20 6:03 am, Martin Pitt wrote:
> Hello,
> 
> Sunil Mohan Adapa [2020-01-01 19:29 -0800]:
>> Debian build servers are unable to build the latest Debian package of pcp
>> uploaded to repositories: 5.0.2-1 [1]. As a consequence, pcp and it's
>> dependencies cockpit and freedombox are at threat of being removed from 
>> Debian
>> testing on January 10, 2020 [2].
>>
>> This is due to incorrect invocation of dh_python2 which is no longer 
>> available
>> on these build machines.
> 
> Right, as the previous upload (rightfully) dropped the py2 build deps. I 
> attach
> a first debdiff, but it doesn't work yet. The package build fails later on 
> with

The attached patch works for me. I have done (on a buster machine):

dpkg-source -x pcp_5.0.2-1.dsc
cd pcp-5.0.2
patch -p1 < ../pcp_5.0.2-1.1.debdiff
sudo apt install python3-all-dev
dpkg-buildpackage -us -uc

After that I did (for building clean on unstable):
cd ..
cowbuilder build pcp_5.0.2-1.1.dsc

Both these builds on stable and unstable worked without any hiccups.

> 
> | === src ===
> | rm -f Makefile.new Makefile.fix; CFLAGS='-fPIC -fno-strict-aliasing 
> -D_GNU_SOURCE  -Wall -O2 -g -DPCP_VERSION=\"5.0.2\" -I../../../src/include 
> -I../../../src/include/pcp' CXXFLAGS='' LDFLAGS=' -Wall 
> -L../../../src/libpcp/src -L../../../src/libpcp_web/src 
> -L../../../src/libpcp_pmda/src ' QT_SELECT=5 /usr/bin/qmake -o Makefile.new 
> CONFIG+=release && sed -e 's/Makefile.new/Makefile/g'  /usr/bin/gawk --posix '$1 == "LIBS" { printf $1; for (i=2;i<=NF;i++) { if 
> ($i~/^-L\//) { save=save " " $i; continue } else if (save!="" && $i~/^-l/) { 
> printf " %s",save; save="" } printf " %s",$i } if (save!="") printf " 
> %s",save; print ""; next } { print }' >Makefile.fix && ( if [ -f Makefile ]; 
> then if diff Makefile Makefile.fix >/dev/null; then :; else rm -f Makefile; 
> mv Makefile.fix Makefile; fi; else mv Makefile.fix Makefile; fi ); rm -f 
> Makefile.new Makefile.fix; /usr/bin/make --no-print-directory -f Makefile
> | rm -f Makefile.new Makefile.fix; CFLAGS='-fPIC -fno-strict-aliasing 
> -D_GNU_SOURCE  -Wall -O2 -g -DPCP_VERSION=\"5.0.2\" -I../../../src/include 
> -I../../../src/include/pcp' CXXFLAGS='' LDFLAGS=' -Wall 
> -L../../../src/libpcp/src -L../../../src/libpcp_web/src 
> -L../../../src/libpcp_pmda/src ' QT_SELECT=5 /usr/bin/qmake -o Makefile.new 
> CONFIG+=release && sed -e 's/Makefile.new/Makefile/g'  /usr/bin/gawk --posix '$1 == "LIBS" { printf $1; for (i=2;i<=NF;i++) { if 
> ($i~/^-L\//) { save=save " " $i; continue } else if (save!="" && $i~/^-l/) { 
> printf " %s",save; save="" } printf " %s",$i } if (save!="") printf " 
> %s",save; print ""; next } { print }' >Makefile.fix && ( if [ -f Makefile ]; 
> then if diff Makefile Makefile.fix >/dev/null; then :; else rm -f Makefile; 
> mv Makefile.fix Makefile; fi; else mv Makefile.fix Makefile; fi ); rm -f 
> Makefile.new Makefile.fix; /usr/bin/make --no-print-directory -f Makefile
> | diff: Makefile: No such file or directory
> | make[5]: Makefile: No such file or directory
> | mv: cannot stat 'Makefile.fix': No such file or directory
> 
> This file doesn't exist anywhere -- apparently src/include/builddefs.install
> builds it, but at this point this is pretty deeply woven into the build 
> system.
> Curiously, resuming the build with "make"  and "dpkg-buildpackage -us -uc -b 
> -nc"
> gets over that, but then in the end it still fails with

I believe the rm commands run during cleanup. I suspect the source is
not conducive to running multiple build/cleanup cycles. The problem
could be pre-existing and does not effect build machines or clean builds
from freshly extracted source. We can treat it as non-critical and leave
it to be dealt later.

> 
> | dpkg-deb: building package 'pcp-import-sar2pcp' in 
> '../pcp-import-sar2pcp_5.0.2-1.1_all.deb'.
> | dpkg-deb: building package 'pcp-import-mrtg2pcp' in 
> '../pcp-import-mrtg2pcp_5.0.2-1.1_all.deb'.
> | dpkg-deb: building package 'pcp-import-iostat2pcp' in 
> '../pcp-import-iostat2pcp_5.0.2-1.1_all.deb'.
> | dpkg-deb: building package 'pcp-doc' in '../pcp-doc_5.0.2-1.1_all.deb'.
> | dpkg-deb: building package 'pcp-import-sheet2pcp' in 
> '../pcp-import-sheet2pcp_5.0.2-1.1_all.deb'.
> | dpkg-deb: building package 'pcp-import-ganglia2pcp' in 
> '../pcp-import-ganglia2pcp_5.0.2-1.1_all.deb'.
> | dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
> exit status 2
> 
> without any apparent error message (the dh

Bug#947916: FTBFS: 5.0.2-1 fails to build from source, not transitioning to testing

2020-01-01 Thread Sunil Mohan Adapa
Source: pcp
Version: 5.0.2-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Debian build servers are unable to build the latest Debian package of pcp
uploaded to repositories: 5.0.2-1 [1]. As a consequence, pcp and it's
dependencies cockpit and freedombox are at threat of being removed from Debian
testing on January 10, 2020 [2].

This is due to incorrect invocation of dh_python2 which is no longer available
on these build machines. This can be fixed by

 * Conditionally invoking dh_python2 such as by if test -x /usr/bin/dh_python2;
then dh_python2 -a --package $(pcp_python2); fi in debian/rules. This may have
unintended effects on machines with dh_python2 installed but configured not to
build python2.

 * Completely dropping support for Python2 in control.master, control.python2,
rules, and fixcontrol.master

1)
https://buildd.debian.org/status/fetch.php?pkg=pcp=amd64=5.0.2-1=1576047957=0
2) http://udd.debian.org/cgi-bin/autoremovals.yaml.cgi



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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl4NY5YRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfKgkBAAprf7QlJNBDDWWzzI/5R1BbPI/zlr4NNV
jnKnj5F0NKWdCJjuJRcb53ukL/2g+u45K8l+YkpB9wJ0VLBhYJTMShNS5UhoQGyp
UdOzSwfBRCfqQCaJPT5YTqN4n+DsM8WOXjoxVzXkYa+GrKhle69MCppSVt6RgTXd
/ZSd+3AeUYgnFeCQKER30ge7kLvfZqPzjS0BkVYWkbWK78oWHmzlZ9FdJ3oUwyY6
r0lx+yVvveCC7FWEHXgRwnWy/3hX6nKM7c4VQ3TBOo0PywBSDd3G3RmBf90ggmy6
VIhqIK4+3UdKP94IvF96PpO+2ACCsIIH+tW7EYjQP2F2ANfg2NVHjsL+eMDdqwyJ
m9k4H8ZQMEWK35XCmi7FgBBRfEgJcsIVyebn2kzf4GNdM3I0ndUoO4ffg5Ac4Cui
uqIENJpPGZJpinXutcULVnYbJ4vpC7Q54D/mFjJV5YEvJj4JQ4dKL4sylMrffMqc
agKlAM5YsyjzLjLE/sYYcu4b0IOldvcqMZFxJaWcJFl5FUSRSlhi8IB1IJ1BmSKN
bH1GadpUYk/l4iyixW/bjj08IRg9ym1CFIAhLVOEO29+526Ilro2KKj4ZVbM3fTm
8jDa3mIdMLQLkWlUK/EqNpDg+s7TGhO3MqzLPVoXf+MCniSeIegDvdzirbFxdQtt
yi2vkee+7SU=
=LiUu
-END PGP SIGNATURE-



Bug#947804: raspi-firmware: raspi3-firmware transitional package should not have Architecture: all

2019-12-30 Thread Sunil Mohan Adapa
Package: raspi-firmware
Version: 1.20190819-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

raspi3-firmware and raspi-firmware packages are not available in testing
currently. Tracker page reports the following problems:

Migration status for raspi-firmware (- to 1.20190819-2): BLOCKED:
Rejected/violates migration policy/introduces a regression
Issues preventing migration:
Updating raspi-firmware introduces new bugs: #941974
uninstallable on arch amd64, autopkgtest delayed there
Additional info:
raspi3-firmware/amd64 unsatisfiable Depends: raspi-firmware
raspi3-firmware/i386 unsatisfiable Depends: raspi-firmware
Cannot be tested by piuparts (not a blocker) - (no link yet)
24 days old (needed 5 days)
Not considered

Since #941974 seems to be closed now, I am lead to believe that the amd64/i386
problems reported above are preventing testing migrations. For raspi3-firmware
transitional package, setting 'Architecture: all' seems to make it available in
all architectures but since raspi-firmware on which it depends is available
only in 'arm64 armhf armel', this seems to cause the problem.

The problem might get fixed by setting 'Architecture: arm64 armhf armel' for
raspi3-firmware transitional package.

PS: #947614 might be referring to the same problem.

Thanks,

- --
Sunil



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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl4KkEMRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfI4nw//W/ocLClFFnlLlEulLPQgaf/7FYLAUSMl
O6v0riToVBVgBzaGWycdBi7C4hATcmAw3lECkR4j+p71N8iT81Z9yzqA840CqclS
lgBtlx8leAamdXwEWt2O42qsJFWRJd9Ga4jW430sMIUOrmGIZFSkXaOWgGViLHjK
SPzs3GP3+NTHqbuDd9VPnjSvck90xQNiui/NKn4LyXFPtEqZEsu0OSteyGnYnN36
V5nMq7bQDiRD3wvgWJfoe335rG/R3loW7Rpnc5lCW0kMO7nS3wVkmNN5p6FLtx5V
tufT9npvhrB80mj42JtELvPNL+ZK13mdkBOJFofohjYbgRi8DSwOAW0Qv8iBqp9c
JbEJqvR1017U9oJ8dSW/hLu8QMnugmHwN/QzrLJeE2KIJ/WOzZ6C67x8JHkC9Km3
a8ub+XlQJMnfSjpElsw+c54zixy/9R9CJIxV/YstjeMS25ucFJRvx4K+/Wzr9tFS
5rs7QN508I/JfFN/8Mx1+nbvXzBel5xS8/us3wuzxO8LA/Ei3zOV52Q689yOT7ek
ovd1U5z6pO4MZAWjDdxd3dcGaUwNDJZJi4RyYM99Awaq9674MuafrxMMsizzMaYU
jqncNFgH+M7JLLcnuZs7G74zRQPzILVzCzYxkce/IEj+gT3QzRpghBanFKvwFYCX
CZsMmQ3EKOY=
=zsXV
-END PGP SIGNATURE-



Bug#947106: python3-augeas: Please upload new version of package 1.0.3

2019-12-20 Thread Sunil Mohan Adapa
Package: python3-augeas
Version: 0.5.0-1
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

The newer version of package available in upstream git repository use cffi
library instead of ctypes to load the C augeas library. This sidesteps the
problem described in #944364. One could also take this opportunity to migrate
the git repository to Salsa (perhaps under the python-team).

I have done the necessary work for the new release, the patches are attached
with following changes:

  * control: Update list of dependencies
  * control: Remove unnecessary python version fields
  * control: Specify that rules file does not require root
  * control: Update standards version to 4.4.1. No changes required.
  * control: Enable autopkgtest-pkg-python
  * control: Update debhelper compatibility level to 12
  * rules: Run tests during build

Thank you,

- --
Sunil



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

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

Versions of packages python3-augeas depends on:
ii  libaugeas0  1.11.0-3
ii  python3 3.7.3-1

python3-augeas recommends no packages.

python3-augeas suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl39hzoRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfJoYA/+NOZEDuYybEq9g1CfHNx23xUINGysjxAp
qNEpuUYWRkvtHHDKjuCtaKeUsim0TQ4tWcbCpv7xNzMIOZY6PuZv75Jm3Kn8hAo7
ocO9c4osIVUhj05+hkaBA5xVXDFnulZDqn63LY69Df6PKN/0k4ov1kLsBpZ/Wle0
cUFynK5018ticnDVTaI/F6Lzu6gOr6+0H4TABW4PV+pRAMHz0l286rRMOFurid5A
MlmQlAug3yyrKwDP7WQiuujTxGisNWJYmIqkfETe/ibExkNNbUaJF73gyrmJu2e/
lIrtG4E+ysJrmGXAR+eoP/HNRczbjnXdwgdexD2A26RTyVB5lSi1kMS0COZRf0PE
/EckOm7hOXtk2IHmNHJJyIwlXTGjuA6kqo9Jnt6gKvWzwRdTaAfLmI4rh8mEIELG
1n5OUKXDNrJUNEQlWzqBNbNV7L876qSLcAHlSc0/1FatFMvGqsosggnmDyCuTkQN
TzM1xuAksbiUfOKUN9z+rsx9sjCwIewDWuoG5oL5NVHWskijTOrcK6Sowo3ukV3D
t1RxCF34nHWpsBy54E4kYOXs+IcUOnU8fztSfbI2M77XGuVUWQeTU3LyryTPMESd
1v1461vorHTa1+WwSEeZ3EQusOCzWWO3CdRdy0uJbTBS7ljqplIMbwo+O0obaOps
CTnyx2IAyig=
=ePp7
-END PGP SIGNATURE-
>From 7f8cb9c9adbb8cc0bf16f394ff0bae23db9f1a8d Mon Sep 17 00:00:00 2001
From: Sandro Tosi 
Date: Fri, 20 Dec 2019 16:30:56 -0800
Subject: [PATCH 01/10] Release 0.5.0-1.1, non-maintainer upload

---
 debian/changelog |  7 +++
 debian/control   | 15 ---
 debian/rules |  3 +--
 3 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 465320f..cabcd63 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+python-augeas (0.5.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937588, #734557
+
+ -- Sandro Tosi   Wed, 16 Oct 2019 22:17:14 -0400
+
 python-augeas (0.5.0-1) unstable; urgency=low
 
   * New upstream release
diff --git a/debian/control b/debian/control
index 2e7be81..f2e571e 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,6 @@ Build-Depends:
  debhelper (>= 9~),
  dh-python,
  libaugeas0 (>= 0.7.2),
- python-all (>= 2.6.5),
  python3-all
 Standards-Version: 3.9.6
 X-Python-Version: >= 2.6
@@ -15,20 +14,6 @@ Homepage: http://augeas.net/
 Vcs-Git: git://anonscm.debian.org/collab-maint/python-augeas.git
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/python-augeas.git
 
-Package: python-augeas
-Architecture: all
-Depends:
- libaugeas0 (>= 0.7.2),
- ${misc:Depends},
- ${python:Depends}
-Description: Python bindings for Augeas
- Augeas is a library and command line tool that focuses
- on the most basic problem in handling Linux configurations
- programmatically: editing actual configuration files in a
- controlled manner.
- .
- This module provides a Python interface to the Augeas API.
-
 Package: python3-augeas
 Architecture: all
 Depends:
diff --git a/debian/rules b/debian/rules
index 9b2702b..94d7f97 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,8 +2,7 @@
 
 export DH_VERBOSE=1
 export PYBUILD_NAME=augeas
-export PYBUILD_DESTDIR_python2=debian/python-augeas/
 export PYBUILD_DESTDIR_python3=debian/python3-augeas/
 
 %:
-   dh $@ --buildsystem=pybuild --with python2,python3
+   dh $@ --buildsystem=pybuild --with python3
-- 
2.20.1

>From 45c94f8f71d8db4bba7bd308fa3bc83e68275758 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Fri, 20 Dec 2019 16:35:38 -0800
Subject: [PATCH 02/10] New upstream version 1.0.3

---
 .gitignore  | 101 +
 .travis.yml |  31 --
 Makefile|   5 +-
 augeas.py => augeas/__init__.py | 192 

Bug#944364: dpkg: ldconfig is not invoked for Depends or even Pre-Depends

2019-12-20 Thread Sunil Mohan Adapa
Control: reassign -1 python3.7
Control: severity -1 important

On Wed, 13 Nov 2019 01:27:11 +0100 Guillem Jover  wrote:
> Control: reassign -1 python3-augeas
> Control: severity -1 serious
> 
> Hi!
> 
> On Sat, 2019-11-09 at 11:06:15 +0100, Jakub Wilk wrote:
> > * Alexander Thomas , 2019-11-08, 15:50:
> > > Traceback (most recent call last):
> > >  File "/usr/lib/the-package/setup-package.py", line 3, in 
> > >from augeas import Augeas
> > >  File "/usr/lib/python2.7/dist-packages/augeas.py", line 78, in 
> > >class Augeas(object):
> > >  File "/usr/lib/python2.7/dist-packages/augeas.py", line 82, in Augeas
> > >_libaugeas = _dlopen("augeas")
> > >  File "/usr/lib/python2.7/dist-packages/augeas.py", line 75, in _dlopen
> > >raise ImportError("Unable to import lib%s!" % args[0])
> > > ImportError: Unable to import libaugeas!
> > 
> > The _dlopen() function uses ctypes.util.find_library(), which is a
> > fundamentally broken API. This is the culprit, not dpkg.
> 
> Ah, thanks for tracking this down! I was not sure whether the ld caching
> logic in glibc might have regressed perhaps.
> 
> > > ldconfig is one of the triggers of libc-bin. It seems that its
> > > invocation is now postponed too late.
> > 
> > ldconfig is declared as a noawait trigger, so dpkg is allowed to configure
> > the triggering package immediately, without waiting for the trigger to be
> > run.
> >
> > This declaration is correct, because running ldconfig shouldn't have any
> > effect on software functionality, unless there's a bug somewhere else.
> 
> Exactly. So I guess this needs to be reassigned first to augeas, which
> I'm doing now. And perhaps cloned or a new bug filed to python too for
> the brokeness in the ctypes.util.find_library() API, but I'd leave that
> to you Jakub, as I've not checked any of that.

Hello,

When reporting this bug, python-augeas was used as an example to
demonstrate the problem when a python library is used by a package that
depends on it. The problem is not specific to pythone-augeas and is
reproducible on other python packages that use
ctypes.util.find_library(). I have tried this with the library
python3-magic which opens its library as follows:
"ctypes.cdll.LoadLibrary(find_library('magic'))"

...
Setting up libpython3.7-stdlib:amd64 (3.7.6-1) ...
Setting up libpython3-stdlib:amd64 (3.7.5-3) ...
Setting up python3.7 (3.7.6-1) ...
Setting up python3 (3.7.5-3) ...
running python rtupdate hooks for python3.7...
running python post-rtupdate hooks for python3.7...
Setting up python3-magic (2:0.4.15-2) ...
Setting up the-package (1.2.3ubuntu1-2-1) ...
Traceback (most recent call last):
  File "/usr/lib/the-package/setup-package.py", line 3, in 
import magic
  File "/usr/lib/python3/dist-packages/magic/__init__.py", line 361, in

add_compat(globals())
  File "/usr/lib/python3/dist-packages/magic/__init__.py", line 325, in
add_compat
from magic import compat
  File "/usr/lib/python3/dist-packages/magic/compat.py", line 61, in

_open = _libraries['magic'].magic_open
  File "/usr/lib/python3.7/ctypes/__init__.py", line 377, in __getattr__
func = self.__getitem__(name)
  File "/usr/lib/python3.7/ctypes/__init__.py", line 382, in __getitem__
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /usr/bin/python3: undefined symbol: magic_open
dpkg: error processing package the-package (--configure):
 installed the-package package post-installation script subprocess
returned error exit status 1
Processing triggers for libc-bin (2.29-6) ...
Errors were encountered while processing:
 the-package
E: Sub-process /usr/bin/dpkg returned an error code (1)

This is either a bug with all python libraries that use ctypes'
find_library() for simply using the method or it is a bug with ctypes
find_library(). I am inclined to think the latter because judging by
ctypes documentation, using find_library() followed by LoadLibrary() is
the expected usage pattern on GNU/Linux. Hence reassigning this bug to
Python.

Also, severity 'serious' does not fit this bug as the affected packages
(and ctypes API) are fully usable expect from within Debian postinst
scripts. Demoting severity to important again.

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#945387: plinth: [INTL:de] updated German debconf translation

2019-11-25 Thread Sunil Mohan Adapa
tag 945387 + pending
thanks

On 23/11/19 1:07 am, Helge Kreutzmann wrote:
> Package: plinth
> Version: 19.21
> Severity: wishlist
> Tags: patch l10n
> 
> Please find the updated German debconf translation for plinth
> attached.
> 
> Please place this file in debian/po/ as de.po for your next upload.
> 
> If you update your template, please use 
> 'msgfmt --statistics '
> to check the po-files for fuzzy or untranslated strings.
> 
> If there are such strings, please contact me so I can update the 
> German translation.

This patch has been merged. Thank you for updating the translation.

-- 
Sunil



Bug#935211: python-acme: Please port to Python 3 and/or drop Python 2 package

2019-10-01 Thread Sunil Mohan Adapa
Hello,

The python-acme package and consequently, all of certbot and FreedomBox,
are set to be autoremoved from Debian testing in just a few days from
now on Sunday, the 6th of October, 2019. Since the fix seems to be
straight forward, can some please look into this and upload the package
without Python2 and python3-ndg-httpsclient?

Gianfranco Costamagna, the patch you have attached seems to be incorrect
and meant for another unrelated package.

Thank you,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#940277: FTBFS with recent PHPUnit (8)

2019-09-26 Thread Sunil Mohan Adapa
tag -1 + pending
thanks

Hello,

Thank you for reporting the bug. I am not sure if we want to keep or
remove the package from testing. I will leave that decision to James
Valleroy.

In case we want to keep it, I have updated the package repository with
the changes need to fix this issue.

https://salsa.debian.org/freedombox-team/php-klogger

I can't upload the package myself. I will look for a sponsor to upload
the package.

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#941015: [Freedombox-pkg-team] Bug#941015: Autopkgtests fail by using the now dropped py2 binary

2019-09-25 Thread Sunil Mohan Adapa
tag 941015 + pending
thanks

On 23/09/19 5:42 am, Christian Ehrhardt wrote:
> Package: django-ranged-response
> Version: 0.2.0-2
> 
> Hi,
> the autopkgtests of django-ranged-response fail since the last upload.
> This is due to the dropped py2 binary as the tests in d/t/control
> still want to install and test it.
> 
> Obvious suggestion is to remove the tests as well, but that is up to you.
> 
> P.S. I also found the same happened to python-django-gravatar2, could
> there be more and all with the same pattern?
> 

Thank you for reporting the bug and for the patch. I had already made
the changes for this in the Debian packaging repository.

g...@salsa.debian.org:freedombox-team/django-ranged-response.git

I will try again to find a sponsor to upload the package. If you are a
DD, please consider uploading from this repository.

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#935831: node-turbolinks: Incorrect symlink to /usr/lib in /usr/share/javascript

2019-08-26 Thread Sunil Mohan Adapa
Package: node-turbolinks
Version: 5.1.1+dfsg-5
Severity: important
Tags: patch

Dear Maintainer,

In the latest version of node-turbolinks (5.1.1+dfsg-5), the files are being
installed in /usr/share instead of /usr/lib. However, the link in the directory
/usr/share/javascript/turbolinks has not been updated to reflect the new path.
Due to this, package users (like FreedomBox) trying to access the library using
the URL http://localhost/javascript/turbolinks/turbolinks.js get an error. This
path is provided by Apache configuration snippet in the javascript-common
package.

Workaround for users is to run:
rm -f /usr/share/javascript/turbolinks/turbolinks.js
ln -rs /usr/share/nodejs/turbolinks/dist/turbolinks.js
/usr/share/javascript/turbolinks/turbolinks.js

The following patch fixes the problem:
https://salsa.debian.org/js-team/node-turbolinks/merge_requests/2

Please consider making a release with the fix soon as major functionality is
broken in FreedomBox.

Thank you for packaging node-turbolinks,

--
Sunil



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From d1b69c2d2055d54a1a113caf17ecbf02be694523 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Mon, 26 Aug 2019 10:50:40 -0700
Subject: [PATCH] Fix incorrect symlink to /usr/lib in /usr/share/javascript

Without the change turbolinks is no longer accessible on
http://localhost/javascript/turbolinks/turbolinks.js . This was possible due to
Apache configuration snippet provided by javascript-common package.

Tests:

- Build package with changes using pbuilder, install and access the URL
  http://localhost/javascript/turbolinks/turbolinks.js

Signed-off-by: Sunil Mohan Adapa 
---
 debian/links | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/links b/debian/links
index 0d266f4..9609ccd 100644
--- a/debian/links
+++ b/debian/links
@@ -1 +1 @@
-usr/lib/nodejs/turbolinks/dist/turbolinks.js 
usr/share/javascript/turbolinks/turbolinks.js
+usr/share/nodejs/turbolinks/dist/turbolinks.js 
usr/share/javascript/turbolinks/turbolinks.js
-- 
2.20.1



Bug#487300: debconf: preseeding values for questions with template of other name (from dbconfig-common)

2019-08-22 Thread Sunil Mohan Adapa
Hello,

This bug due to an assumption that template name would be the same as
the question name in debconf-set-selections. The database get corrupted
as a result requiring the run of fix_db.pl.

The attached patch fixes the problem and ensures that database does not
get corrupted. Please consider applying the patch.

Thank you,

-- 
Sunil
From 13d511b549c08f14706146c8377fcb7863774041 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 22 Aug 2019 21:33:15 -0700
Subject: [PATCH] Fix setting answers when template name is not same as
 question

When setting answers to a questions, question may exist and its template may
exist with a different name. For example, question could be tt-rss/database-type
and template could be dbconfig-common/database-type. In such cases, ensure that
a dummy template is not created with the name of the question.

This fixes database inconsistency introduced otherwise. Closes #487300.

Signed-off-by: Sunil Mohan Adapa 
---
 debconf-set-selections | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/debconf-set-selections b/debconf-set-selections
index 7d99a306..a1b1a783 100755
--- a/debconf-set-selections
+++ b/debconf-set-selections
@@ -116,17 +116,32 @@ sub load_answer {
 	info "Loading answer for '$label'";
 
 	# Set up the template.
-	my $template=Debconf::Template->get($label);
-	if (! $template) {
-		$template=Debconf::Template->new($label, $owner, $type);
-		$template->description("Dummy template");
-		$template->extended_description("This is a fake template used to pre-seed the debconf database. If you are seeing this, something is probably wrong.");
+	my $template;
+	my $question=Debconf::Question->get($label);
+	if ($question) {
+		# Question may already exist and its template may exist with a
+		# different name. For example, question could be
+		# tt-rss/database-type and template could be
+		# dbconfig-common/database-type. Retrieve the template using the
+		# question if it exists.
+		$template=$question->template;
+	}
+	else {
+		# If question does not exist, try to retrieve a template with
+		# same name as the question. If it does not exist, create a
+		# dummy template as a last resort.
+		$template=Debconf::Template->get($label);
+		if (! $template) {
+			$template=Debconf::Template->new($label, $owner, $type);
+			$template->description("Dummy template");
+			$template->extended_description("This is a fake template used to pre-seed the debconf database. If you are seeing this, something is probably wrong.");
+		}
 	}
 	$template->type($type);
 	
 	# The question should already exist, it was created along with the
 	# template. Set it up.
-	my $question=Debconf::Question->get($label);
+	$question=Debconf::Question->get($label);
 	if (! $question) {
 		error("Cannot find a question for $label");
 		return;
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature


Bug#931195: flash-kernel: Add entry for Olimex A64-Olinuxino

2019-08-22 Thread Sunil Mohan Adapa
Hello,

Attached patch proposes new flash-kernel entry for A64 OLinuXino board
with eMMC support.

A64 OLinuXino board from Olimex has three variants with onboard eMMC:
A64-OLinuXino-1Ge16GW, A64-OLinuXino-1Ge4GW and A64-OLinuXino-2Ge8G-IND. In
addition, there are two variants without eMMC. One without eMMC and one
with SPI
flash. This suggests the need for separate device tree for the three eMMC
variants.

The Linux kernel upstream has chosen to create and use a separate device
tree
for the eMMC variants instead of adding eMMC support existing device
tree. These
changes to Linux kernel are queued for Linux 5.4.

https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4=02bb66b347ff8115f53948f86b884e008ba385b9

Thanks,

-- 
Sunil
From ea0be10d5de3b7225c9de0b1244046bf79d1fadc Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 22 Aug 2019 10:17:48 -0700
Subject: [PATCH 2/2] Add entry for Olimex A64-Olinuxino-eMMC

A64 OLinuXino board from Olimex has three variants with onboard eMMC:
A64-OLinuXino-1Ge16GW, A64-OLinuXino-1Ge4GW and A64-OLinuXino-2Ge8G-IND. In
addition, there are two variants without eMMC. One without eMMC and one with SPI
flash. This suggests the need for separate device tree for the three eMMC
variants.

The Linux kernel upstream has chosen to create and use a separate device tree
for the eMMC variants instead of adding eMMC support existing device tree. These
changes to Linux kernel are queued for Linux 5.4.

https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4=02bb66b347ff8115f53948f86b884e008ba385b9

Signed-off-by: Sunil Mohan Adapa 
---
 db/all.db | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/db/all.db b/db/all.db
index d527fa1..e6cafc5 100644
--- a/db/all.db
+++ b/db/all.db
@@ -1302,6 +1302,13 @@ Boot-Script-Path: /boot/boot.scr
 U-Boot-Script-Name: bootscr.uboot-generic
 Required-Packages: u-boot-tools
 
+Machine: Olimex A64-Olinuxino-eMMC
+Kernel-Flavors: arm64
+DTB-Id: allwinner/sun50i-a64-olinuxino-emmc.dtb
+Boot-Script-Path: /boot/boot.scr
+U-Boot-Script-Name: bootscr.uboot-generic
+Required-Packages: u-boot-tools
+
 Machine: Olimex A64 Teres-I
 Kernel-Flavors: arm64
 DTB-Id: sun50i-a64-teres-i.dtb
-- 
2.20.1

From 8ae086aef5f08b8dc2e378764fd4b5ac6dffa9d1 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Wed, 26 Jun 2019 12:27:31 -0700
Subject: [PATCH 1/2] Add entry for Olimex A64-Olinuxino

Signed-off-by: Sunil Mohan Adapa 
---
 db/all.db | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/db/all.db b/db/all.db
index 117a1af..d527fa1 100644
--- a/db/all.db
+++ b/db/all.db
@@ -1295,6 +1295,13 @@ DTB-Id: sun8i-a33-olinuxino.dtb
 U-Boot-Script-Name: bootscr.sunxi
 Required-Packages: u-boot-tools
 
+Machine: Olimex A64-Olinuxino
+Kernel-Flavors: arm64
+DTB-Id: allwinner/sun50i-a64-olinuxino.dtb
+Boot-Script-Path: /boot/boot.scr
+U-Boot-Script-Name: bootscr.uboot-generic
+Required-Packages: u-boot-tools
+
 Machine: Olimex A64 Teres-I
 Kernel-Flavors: arm64
 DTB-Id: sun50i-a64-teres-i.dtb
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature


Bug#935378: lektor: Package the admin UI

2019-08-21 Thread Sunil Mohan Adapa
Package: lektor
Version: 3.1.1-1
Severity: wishlist

Dear Maintainer,

lektor has an administration UI that allows users to edit pages using a CMS
like interface. This is typically accessed by running 'lektor serve', then
visiting http://127.0.0.1:5000/ and clicking on the edit button on the top
right corner of the static page.

Currently, lektor's Debian package does not build the administration interface
present in the directory lektor/admin/. This results in 404 errors generated by
visiting the administrator interface of lektor. Administration interface is
usually built by running 'make build-js' in the root directory. This in-turn
uses 'npm' and several node modules. Most of these node modules seem to be
already packaged for Debian.

Please consider building and packaging the administration UI for lektor as part
of the lektor's Debian package.

Lektor being used by the FreedomBox project and we are considering making it
available for users as a FreedomBox app. Thank you for packaging lektor.

--
Sunil



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

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

Versions of packages lektor depends on:
ii  python33.7.3-1
ii  python3-babel  2.6.0+dfsg.1-1
ii  python3-click  7.0-1
ii  python3-exif   2.1.2-1
ii  python3-flask  1.0.2-3
ii  python3-inifile0.4-1
ii  python3-jinja2 2.10-2
ii  python3-mistune0.8.4-1
ii  python3-pip18.1-5
ii  python3-pkg-resources  40.8.0-1
ii  python3-requests   2.21.0-1
ii  python3-watchdog   0.9.0-1

lektor recommends no packages.

lektor suggests no packages.

-- no debconf information



Bug#931201: radicale: When started with uwsgi log directory is handled incorrectly

2019-08-11 Thread Sunil Mohan Adapa
Hello,

It appears that FreedomBox users who install radicale immediately after
setting up FreedomBox are unable to use radicale[1]. They will need to
upgrade FreedomBox to latest version which contains a workaround to this
problem before radicale can be used.

I wonder if there is a way to make this fix available to Buster users
through stable updates. Perhaps it won't be accepted as it is not a
security update.

Links:

https://salsa.debian.org/freedombox-team/plinth/issues/1619

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#487300: debconf: preseeding values for questions with template of other name (from dbconfig-common)

2019-08-06 Thread Sunil Mohan Adapa
Hello,

In the context of FreedomBox, we are also seeing this problem. This time
it is with the tt-rss package. To reproduce:

# apt install tt-rss
# echo 'tt-rss tt-rss/database-type string pgsql' | debconf-set-selections
# apt purge tt-rss
# echo 'tt-rss tt-rss/database-type string pgsql' | debconf-set-selections
error: Cannot find a question for tt-rss/database-type

Running /usr/share/debconf/fix_db.pl corrects the problem

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#932981: [Freedombox-pkg-team] Bug#932981: Please remove Python 2 support for this package

2019-07-25 Thread Sunil Mohan Adapa
On 25/07/19 5:40 am, Thomas Goirand wrote:
> Source: django-ranged-response
> Version: 0.2.0-1
> Severity: serious
> Tags: patch
> 
> Hi,
> 
> Attached is a patch to remove Python 2 support for this package,
> needed since the upload of Django 2.2 in Sid.
> 
> Please apply and upload.

Thank you for the patch. I have contacted Federico for the upload. The
attached patches make some further changes.

-- 
Sunil
>From bc757ed3b45e5259fb1c55237d6d31d7c72298a1 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 25 Jul 2019 16:38:00 -0700
Subject: [PATCH 3/3] Ensure that test database is not part of final .deb

Signed-off-by: Sunil Mohan Adapa 
---
 debian/patches/0001-complete-the-test-suite.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/patches/0001-complete-the-test-suite.patch b/debian/patches/0001-complete-the-test-suite.patch
index 4c321e5..9763828 100644
--- a/debian/patches/0001-complete-the-test-suite.patch
+++ b/debian/patches/0001-complete-the-test-suite.patch
@@ -8,7 +8,7 @@
 +settings.configure(DATABASES={
 +'default': {
 +'ENGINE': 'django.db.backends.sqlite3',
-+'NAME': 'db.sqlite3',
++'NAME': 'test/db.sqlite3',
 +}
 +})
 --- a/test/test_response.py
-- 
2.20.1

>From 06ab5066a5c71cb6d22240dbcd762981926585b5 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 25 Jul 2019 16:12:26 -0700
Subject: [PATCH 2/3] Update standards version to 4.4.0

No changes are needed.

Signed-off-by: Sunil Mohan Adapa 
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 02657ff..b8deccf 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Build-Depends:
  python3-all,
  python3-django,
  python3-setuptools
-Standards-Version: 4.1.3
+Standards-Version: 4.4.0
 Homepage: https://pypi.python.org/pypi/django-ranged-response/
 Vcs-Browser: https://salsa.debian.org/freedombox-team/django-ranged-response
 Vcs-Git: https://salsa.debian.org/freedombox-team/django-ranged-response.git
-- 
2.20.1

>From 2c5f4e03d9d16a4e32ea53c3406e004bfd70b080 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 25 Jul 2019 15:37:22 -0700
Subject: [PATCH 1/3] Drop auto pkg tests for python2

Signed-off-by: Sunil Mohan Adapa 
---
 debian/tests/control | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/debian/tests/control b/debian/tests/control
index 9bb1757..01e030b 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,5 +1,2 @@
-Test-Command: set -e ; for py in $(pyversions -r 2>/dev/null) ; do cd "$ADTTMP" ; echo "Testing with $py:" ; $py -c "import ranged_response; print ranged_response" ; done
-Depends: python-all, python-django-ranged-response
-
 Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$ADTTMP" ; echo "Testing with $py:" ; $py -c "import ranged_response; print(ranged_response)" ; done
 Depends: python3-all, python3-django-ranged-response
-- 
2.20.1



Bug#931201: radicale: When started with uwsgi log directory is handled incorrectly

2019-06-27 Thread Sunil Mohan Adapa
Source: radicale
Version: 2.1.11-6
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

When the log directory /var/log/radicale does not exit, starting radicale with
uwsgi fails. The problem can be reproduced with `systemctl stop uwsgi; rm -rf
/var/log/radicale; systemctl start uwsgi`. There is code in uwsgi configuration
to create this directory but there is a typo in that code. The first attached
patch fixes it.

Additionally, when radicale is started with uWSGI (and also apparently with
direct daemon start using init script), the log directory /var/log/radicale is
never even used. Due to default radicale configuration, the daemon simply
prints log messages console (which may not be picked up by uWSGI daemon or
start-stop-daemon). The uWSGI general log and uWSGI request log are logged to
/var/log/uwsgi/app/radicale.log.

If the intension is to get rid of log directory, at least for uWSGI, the second
attached patch helps. Otherwise, I suppose a change to radicale default
configuration is needed to make it log to /var/log/radicale. Alternatively,
perhaps uWSGI can capture the console log of radicale and output it as part of
uwsgi app log. Please ignore the second patch in the latter two cases.

Thanks,

- --
Sunil



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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl0VfY0RHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfLoXw/+Pb8A7ihF3+kJvpe0cdl4LeNQ9tACjN76
P4mDq7j8LV9ROsn/j6c7QFiDymtS/WoypB2grch3Ze7GtdLvYlBZKucEaru93SQC
RYhL5wZGxMD1VfwOZElb/pmOyuAJzZl19znBeSODp7Rb61pQeiqmoBR9yyv5YWMb
8k2nOx+36+cgze66I/vVutU21OjrLYFwj/iKWtarLJnMFb4zcClJx/sBOlF4Nmla
ayi0JHNxvNEeuU+fmkzxzHcIVjN0JMzrmIy/5S/2twHt8Lj9FIv2tAVzBBA6Mxhe
mdXRG7GC+hAcz+1AOZuUfTVtqbaWSA+r+DfvQd87rupXwbP2v7bcI51OmpsiNIAI
h5HILcR7F8i05o1c9Mz12gdgjKgL7kIKpvAlxxT5RgwSlyJKjeXJsNVIGB1X6IWq
VqajMHAIWnHCT2wHlgD5RotCaJvI3ALRGc/ahQk9tnNykosh3BKSIXmFPasU4gFf
weM6ThWmLK1LNXZFTlQ8aTKIU+n+ebXBtqvsJA96q6LkH+ypL4j1R8l73sQI4P85
ywLF0R/l/BsAcDgZfg7r1IOSwVbgSVK7PEIKezgGbWb7hhrXsE9wvihBAMb2v7vw
EzMde3+wX8bg/2yFxHG9dpe+j8AOIbSyNbNa1EDuTQyM3vl8PZGmnwjzLZMjygZY
sOo3ZtV1C40=
=vXS2
-END PGP SIGNATURE-
>From 4ed52a100e78ed7ecde459c726a51eabca2a8d0a Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 27 Jun 2019 19:15:47 -0700
Subject: [PATCH 1/2] uwsgi: Fix creation of log directory

Signed-off-by: Sunil Mohan Adapa 
---
 debian/etc/uwsgi/apps-available/radicale.ini | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/etc/uwsgi/apps-available/radicale.ini 
b/debian/etc/uwsgi/apps-available/radicale.ini
index cc9182c..24b0535 100644
--- a/debian/etc/uwsgi/apps-available/radicale.ini
+++ b/debian/etc/uwsgi/apps-available/radicale.ini
@@ -45,7 +45,7 @@ if-not-exists = /var/lib/radicale/collections
 exec-as-root = mkdir -p /var/lib/radicale/collections
 endif =
 if-not-exists = /var/log/radicale
-exec-as-root = mkdir -p /var/lib/radicale
+exec-as-root = mkdir -p /var/log/radicale
 endif =
 exec-as-root = if ! dpkg-statoverride --list /var/lib/radicale >/dev/null 
2>&1; then chown radicale: /var/lib/radicale /var/lib/radicale/collections; 
chmod g-w,o-rwx /var/lib/radicale /var/lib/radicale/collections; fi
 exec-as-root = if ! dpkg-statoverride --list /var/log/radicale >/dev/null 
2>&1; then chown radicale:adm /var/log/radicale; chmod g-w,o-rwx 
/var/log/radicale; fi
-- 
2.20.1

>From aaadffb4dd61cbf04a6fe4a8850fb5326c90ed3e Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 27 Jun 2019 19:17:13 -0700
Subject: [PATCH 2/2] uwsgi: Remove unused handling of /var/log/radicale

Signed-off-by: Sunil Mohan Adapa 
---
 debian/etc/uwsgi/apps-available/radicale.ini | 5 -
 1 file changed, 5 deletions(-)

diff --git a/debian/etc/uwsgi/apps-available/radicale.ini 
b/debian/etc/uwsgi/apps-available/radicale.ini
index 24b0535..eda350c 100644
--- a/debian/etc/uwsgi/apps-available/radicale.ini
+++ b/debian/etc/uwsgi/apps-available/radicale.ini
@@ -9,7 +9,6 @@ plugins = python3
 #plugins = python3,logfile,http
 #https = 
0.0.0.0:443,/etc/ssl/certs/ssl-cert-snakeoil.pem,/etc/ssl/private/ssl-cert-snakeoil.key,HIGH
 #log-format = %(addr) - %(user) [%(ltime)] "%(method) %(uri) %(proto)" 
%(status) %(size) "%(referer)" "%(uagent)"
-#req-logger = file:/var/log/radicale/access.log
 
 # spawn 3 worker processes, growing to 16 as needed
 workers = 16
@@ -44,10 +43,6 @@ umask 027
 if-not-exists = /var/lib/radicale/collections
 exec-as-root = mkdir -p /var/lib/radicale/collections
 endif =
-if-not-exis

Bug#931195: flash-kernel: Add entry for Olimex A64-Olinuxino

2019-06-27 Thread Sunil Mohan Adapa
Package: flash-kernel
Version: 3.99
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Please accept the attached patch to provide support for Olimex A64-Olinuxino.
Most of the system works. Ethernet works with u-boot but not with Linux. I also
can't see the onboard eMMC disk.

Test information follows:

fbx@freedombox:~$ cat /sys/firmware/devicetree/base/model
Olimex A64-Olinuxinofbx@freedombox:~$

fbx@freedombox:~$ uname -a
Linux freedombox 4.19.0-5-arm64 #1 SMP Debian 4.19.37-5 (2019-06-19) aarch64
GNU/Linux

fbx@freedombox:~$ dpkg -l linux-image-4.19.0-5-arm64 u-boot-sunxi flash-kernel
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionArchitecture Description
+++-==-==--=
ii  flash-kernel   3.99   arm64utility to make
certa
ii  linux-image-4.19.0-5-arm64 4.19.37-5  arm64Linux 4.19 for
64-bit
ii  u-boot-sunxi:arm64 2019.01+dfsg-7 arm64A boot loader for
sun

Boot log:

U-Boot SPL 2019.01+dfsg-7 (May 14 2019 - 02:07:44 +)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.0(debug):
NOTICE:  BL31: Built : 23:33:29, Nov 27 2018
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x407fac0, model: Olimex A64-Olinuxino
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
NOTICE:  BL31: PMIC: Detected AXP803 on RSB.
INFO:PMIC: AXP803: Enabling DRIVEVBUS
INFO:PMIC: AXP803: dcdc1 voltage: 3.300V
INFO:PMIC: AXP803: dcdc5 voltage: 1.360V
INFO:PMIC: AXP803: dcdc6 voltage: 1.100V
INFO:PMIC: AXP803: dldo1 voltage: 3.300V
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9


U-Boot 2019.01+dfsg-7 (May 14 2019 - 02:07:44 +) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Olimex A64-Olinuxino
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
Loading Environment from FAT... Unable to use mmc 1:1... In:serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c3
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2226 bytes read in 8 ms (271.5 KiB/s)
## Executing script at 4fc0
18560880 bytes read in 866 ms (20.4 MiB/s)
15864 bytes read in 12 ms (1.3 MiB/s)
25186858 bytes read in 1168 ms (20.6 MiB/s)
Booting Debian 4.19.0-5-arm64 from mmc 0:1...
## Flattened Device Tree blob at 4fa0
   Booting using the fdt blob at 0x4fa0
EHCI failed to shut down host controller.
EHCI failed to shut down host controller.
   Loading Ramdisk to 487fa000, end 49fff22a ... OK
   Loading Device Tree to 487f3000, end 487f9df7 ... OK

Starting kernel ...



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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl0VI/wRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfKP4w/+JkQtC149PiAEbzjl5RFqRMX+SmYb8nlv
9ee4xkN189a73a9GEJqV1h5WNaMAkyZY83CiH7vTmkcoUXWxfTCy++h30uuMQBQQ
uB9NG756GTS7VZ6qR1Q1PXvI8ZaWyIVOizaSK0z+lZNK0YjSwLneOI+SiBdcnExt
wZaHNOK13stbv0NoN+TyQiIz7gCko5VyTBuM3V0gxaNWBlL8ZeOz+j1q5l4LQWOA
IsBXAqjTC7S7RL6N+msmrD0B+LJnEcKr2bvGbIFMui7ancmRi1II34ZsBFA4pXAa
P+91mNQY5XRW4Fq+zuQ/oPmHErKOIeM2ild6cuQRJo5SkKVcWouGKeMBlL/k07XV
c/3iLrQG/JNKfz8IZOm95Wy0nVyvR7Kg3aw3WDmBxnm0gJBr1q1kDncWnSSSFZ/U
6gqewWzyjwjuCyuk5fTkiwq45KkEza5FN8jGnQuB0drKhbOu0VSUk0rZpWPwYrRa
0qe77R0EquRGnSDr7kV+U6JoYEM1B76aTkk3PaXJfip5X5z02U56pi9VpNa5rSFH
4sHlf/L9LEaecuQKHEGHm2P/6/EoGekozHYWmvvpwb/g/HYaOLmmaIdPLPTsZ4dc
aLPRuEoyhYK8ZrblZT4Kdgd8Gi9oEhGZ+LquEm8lsGQ+dw8+4VY7MxwjkOVm2w8p
l0fa3gJHOY8=
=tZGa
-END PGP SIGNATURE-
>From 0d434cc9d93fa1a0a51856c88dcdb19d1d5d164c Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Wed, 26 Jun 2019 12:27:31 -0700
Subject: [PATCH] Add entry for Olimex A64-Olinuxino

Signed-

Bug#928947: u-boot: Add support for Pine64 LTS board

2019-05-13 Thread Sunil Mohan Adapa
On 13/05/19 6:36 pm, Vagrant Cascadian wrote:
[...]
>> U-Boot SPL 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +)
>> DRAM: 2048 MiB
>> Trying to boot from MMC1
>> NOTICE:  BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)
>> NOTICE:  Configuring SPC Controller
>> NOTICE:  BL3-1: v1.0(debug):
>> NOTICE:  BL3-1: Built : 12:32:39, Apr 11 2018
> 
> It looks like you're using the atf-allwinner package (or a custom ATF
> build) instead of arm-trusted-firmware. Both should work ok, but at some
> point atf-allwinner may get deprecated.
> 
> There's a u-boot-install-sunxi64 script that can be used to install
> u-boot, and will prefer firmware binaries from arm-trusted-firmware.

Thanks for the tip. I will make changes to freedom-maker to start using
arm-trusted-firmware instead. We are already using
u-boot-install-sunxi64 script.

Meanwhile, on a built image, I have switched to arm-trusted-firmware and
reran u-boot-install-sunxi64. Here is the fresh boot log:

U-Boot SPL 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.0(debug):
NOTICE:  BL31: Built : 23:33:29, Nov 27 2018
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x407f2a8, model: Pine64 LTS
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
NOTICE:  BL31: PMIC: Detected AXP803 on RSB.
INFO:PMIC: AXP803: dcdc1 voltage: 3.300V
INFO:PMIC: AXP803: dcdc5 voltage: 1.200V
INFO:PMIC: AXP803: dcdc6 voltage: 1.100V
INFO:PMIC: AXP803: dldo1 voltage: 3.300V
INFO:PMIC: AXP803: Enabling DC1SW
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9


U-Boot 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pine64 LTS
DRAM:  2 GiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
Loading Environment from FAT... Card did not respond to voltage select!
In:serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c3
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2226 bytes read in 7 ms (310.5 KiB/s)
## Executing script at 4fc0
18560880 bytes read in 858 ms (20.6 MiB/s)
16053 bytes read in 13 ms (1.2 MiB/s)
25179720 bytes read in 1169 ms (20.5 MiB/s)
Booting Debian 4.19.0-5-arm64 from mmc 0:1...
## Flattened Device Tree blob at 4fa0
   Booting using the fdt blob at 0x4fa0
EHCI failed to shut down host controller.
EHCI failed to shut down host controller.
   Loading Ramdisk to 487fc000, end 49fff648 ... OK
   Loading Device Tree to 487f5000, end 487fbeb4 ... OK

Starting kernel ...

[2.737551] sun50i-de2-bus 100.de2: Error couldn't map SRAM to device

Debian GNU/Linux 10 freedombox ttyS0

freedombox login:

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#928947: u-boot: Add support for Pine64 LTS board

2019-05-13 Thread Sunil Mohan Adapa
On 13/05/19 2:09 pm, Vagrant Cascadian wrote:
> On 2019-05-13, Sunil Mohan Adapa wrote:
>> Source: u-boot
>> Version: 2019.07-rc1+dfsg-4
> ...
>> It would be nice to have support for the Pine64 LTS board which is different
>> from Pine64+ board that is already supported. Upstream u-boot, flash-kernel 
>> and
>> Debian kernel already have support for the board.
> 
> Thanks! Committed to git.
> 
> Would you consider testing against u-boot 2019.01+dfsg-* packages in
> Debian too, so support could be added for buster?

Thank your for merging the patch. I have tested the patch on branch
debian/2019.01+dfsg-6 with the following results. Everything looks good.

Boot Log


U-Boot SPL 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)
NOTICE:  Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):
NOTICE:  BL3-1: Built : 12:32:39, Apr 11 2018
NOTICE:  DT: sun50i-a64-pine64-lts
INFO:Configuring AXP PMIC
INFO:PMIC: DRAM voltage: 1.24V
INFO:PMIC: setup successful
NOTICE:  SCPI: dummy stub handler, implementation level: 00
INFO:BL3-1: Initializing runtime services
INFO:BL3-1: Preparing for EL3 exit to normal world
INFO:BL3-1: Next image address: 0x4a00, SPSR: 0x3c9


U-Boot 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pine64 LTS
DRAM:  2 GiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
Loading Environment from FAT... Card did not respond to voltage select!
In:serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c3
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2226 bytes read in 7 ms (310.5 KiB/s)
## Executing script at 4fc0
18560880 bytes read in 927 ms (19.1 MiB/s)
16053 bytes read in 12 ms (1.3 MiB/s)
25179720 bytes read in 1261 ms (19 MiB/s)
Booting Debian 4.19.0-5-arm64 from mmc 0:1...
## Flattened Device Tree blob at 4fa0
   Booting using the fdt blob at 0x4fa0
EHCI failed to shut down host controller.
EHCI failed to shut down host controller.
   Loading Ramdisk to 487fc000, end 49fff648 ... OK
   Loading Device Tree to 487f5000, end 487fbeb4 ... OK

Starting kernel ...

[2.670794] sun50i-de2-bus 100.de2: Error couldn't map SRAM to device

Debian GNU/Linux 10 freedombox ttyS0

freedombox login:

Board Model
---

root@freedombox:~# cat /sys/firmware/devicetree/base/model
Pine64 LTSroot@freedombox:~#

Package Versions


root@freedombox:~# uname -a
Linux freedombox 4.19.0-5-arm64 #1 SMP Debian 4.19.37-1 (2019-05-05)
aarch64 GNU/Linux

root@freedombox:~# dpkg -l u-boot-sunxi
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionArchitecture Description
+++-==-==--=
ii  u-boot-sunxi:arm64 2019.01+dfsg-6 arm64A boot loader for
sunxi systems

root@freedombox:~# dpkg -l flash-kernel
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  flash-kernel   3.98 arm64utility to make certain
embedded devices bootable

RAM
---

root@freedombox:~# free -m
  totalusedfree  shared  buff/cache
available
Mem:   2001 2491515   8 236
   1667
Swap: 0   0   0

Ethernet Performance


root@freedombox:~# iperf3 -c 10.42.1.1
Connecting to host 10.42.1.1, port 5201
[  5] local 10.42.1.210 port 46178 connected to 10.42.1.1 port 5201
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec   108 MBytes   909 Mbits/sec0369 KBytes

[  5]   1.00-2.00   sec   108 MBytes   903 Mbits/sec0385 KBytes

[  5]   2.00-3.00   sec   107 MBytes   896 Mbits/sec0385 KBytes

[  5]   3.00-4.00   sec   107 MBytes   897 Mbits/sec0420 KBytes

[  5]   4.00-5.00   sec   107 MBytes   896 Mbits/sec0438 KBytes

[  5]   5.00-6.00   sec   106 MBytes   893 Mbits/sec0438 KBytes

[  5]   6.00-7.00   sec   107 MBytes   899 Mbits/sec0563 KBytes

[  5]  

Bug#928947: u-boot: Add support for Pine64 LTS board

2019-05-13 Thread Sunil Mohan Adapa
]   9.00-10.00  sec   107 MBytes   894 Mbits/sec0434 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.00  sec  1.05 GBytes   900 Mbits/sec   18 sender
[  5]   0.00-10.04  sec  1.05 GBytes   895 Mbits/sec  receiver

iperf Done.
root@freedombox:~# iperf3 -c 10.42.1.1 -R
Connecting to host 10.42.1.1, port 5201
Reverse mode, remote host 10.42.1.1 is sending
[  5] local 10.42.1.210 port 49572 connected to 10.42.1.1 port 5201
[ ID] Interval   Transfer Bitrate
[  5]   0.00-1.00   sec  93.7 MBytes   786 Mbits/sec
[  5]   1.00-2.00   sec  91.6 MBytes   768 Mbits/sec
[  5]   2.00-3.00   sec  88.9 MBytes   746 Mbits/sec
[  5]   3.00-4.00   sec  90.5 MBytes   759 Mbits/sec
[  5]   4.00-5.00   sec  90.0 MBytes   755 Mbits/sec
[  5]   5.00-6.00   sec  94.3 MBytes   791 Mbits/sec
[  5]   6.00-7.00   sec  90.4 MBytes   758 Mbits/sec
[  5]   7.00-8.00   sec  90.6 MBytes   760 Mbits/sec
[  5]   8.00-9.00   sec  94.3 MBytes   791 Mbits/sec
[  5]   9.00-10.00  sec  90.1 MBytes   755 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.04  sec   916 MBytes   766 Mbits/sec0 sender
[  5]   0.00-10.00  sec   914 MBytes   767 Mbits/sec  receiver

iperf Done.



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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAlzZxvoRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfKe0A/7Bt+jO8rdHNrC6MqpTe56gYImeJg2HXbO
TeQ0RDop8tV5hKHuaQ7m8GrbgegxlByt4vEbg6Z0DiUcVB1jIrZaG6ZUzvxUVeUO
UbswLX4BKx2hKMFuziAksUEz+/G5l+n8iQobx3St6ixCqClteSu3XIGabv7AgD8a
R1afA3a4OHYuyksM2Oyu2eNx+JHKzOh7Uec+NzFLUiQh4GjOzkJg7GC3CJ42AW6H
rZZcrO3jlBEVUtPo6yTn8c8yd2WXuT+8Z3S7TWWAe9dOoZ8CiXpHkng/M3kv0TvS
Cet1nTET/UEpfYC2zmn9di2Sf+3MXIy8zzj0qOFm3ZYe3Gwh2ZE63vDQK/3vL2LB
Uz93t+MMCtdzYnBCl6YotB/qmm0aslUBhck93PwxV1ZcTBnV1EWWhFdxdl9u90ht
9xY84Y0pse6fYaoslYqNJfRKCdP0ZpQn7guCPEIiTRx6/MCf/3pDkqldocdF5vt4
RLs/v3akcxDYo5WF9mWqBbORtCnsqboIj/6KMGK3OHoBtiR8s1dnbcqssoyC5+rf
h3ivVsm77ZC2Tpa5hLOYU2BcQmwtDUpCdHpDhvWRQkXB8u0KAElieUs8xBuis4oL
Of9tedgi/38VHcOk7ermqoQINrWEXuuRzXEDEFb3RXaN7jYGDk3DcJo0eegI0xym
jTLO5EFsEgc=
=uxbJ
-END PGP SIGNATURE-
>From f8da3c47f7864ea523302e9abd2bb76de89aed37 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Mon, 13 May 2019 12:20:24 -0700
Subject: [PATCH 1/3] Enable pine64-lts target in u-boot-sunxi

Signed-off-by: Sunil Mohan Adapa 
---
 debian/bin/u-boot-install-sunxi64 | 1 +
 debian/targets| 3 +++
 2 files changed, 4 insertions(+)

diff --git a/debian/bin/u-boot-install-sunxi64 
b/debian/bin/u-boot-install-sunxi64
index 5e013aef4d..fca9fc4d1c 100755
--- a/debian/bin/u-boot-install-sunxi64
+++ b/debian/bin/u-boot-install-sunxi64
@@ -6,6 +6,7 @@ if [ -z "$TARGET" ] && [ -f "${dtmodel}" ]; then
case $(cat "${dtmodel}") in
Pinebook) TARGET="/usr/lib/u-boot/pinebook" ;;
Pine64+) TARGET="/usr/lib/u-boot/pine64_plus" ;;
+   "Pine64 LTS") TARGET="/usr/lib/u-boot/pine64-lts" ;;
"Olimex A64-Olinuxino") TARGET="/usr/lib/u-boot/a64-olinuxino/" 
;;
"Olimex A64 Teres-I") TARGET="/usr/lib/u-boot/teres_i/" ;;
"OrangePi Zero Plus2") 
TARGET="/usr/lib/u-boot/orangepi_zero_plus2/" ;;
diff --git a/debian/targets b/debian/targets
index b95ea6af91..d4b27ca69c 100644
--- a/debian/targets
+++ b/debian/targets
@@ -210,6 +210,9 @@ arm64   sunxi   orangepi_zero_plus2 
u-boot.bin spl/sunxi-spl.bin u-boot-nodtb.bin a
 # Vagrant Cascadian 
 arm64  sunxi   pine64_plus     u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pine64-plus.dtb 
arch/arm/dts/sun50i-a64-pine64.dtb
 
+# Sunil Mohan Adapa 
+arm64  sunxi   pine64-lts  u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pine64-lts.dtb 
arch/arm/dts/sun50i-a64-pine64.dtb
+
 # Vagrant Cascadian 
 arm64  sunxi   pinebooku-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pinebook.dtb
 
-- 
2.20.1



Bug#927397: u-boot: Very poor ethernet performance on A20 OLinuXino Lime2 Rev.G2

2019-04-27 Thread Sunil Mohan Adapa
On 27/04/19 2:46 am, Andreas B. Mundt wrote:
> Hi all,
> 
> On Fri, Apr 26, 2019 at 09:54:37AM +0200, Jonas Smedegaard wrote:
>>
>> So a summary of the tests is this:
>>
>> Board, cable mode, patchset \ Measured speed in Mbit/sec
>> rev.G2 1Gbit mode pristine:14 & 722
>> rev.G2 1Gbit mode TX_DELAY=4: 428 & 774
>> rev.C 1Gbit pristine:   1 & 526
>> rev.C 100Mbit pristine:94 &  94
>> rev.C 1Gbit TX_DELAY=4:61 & 141
>> rev.C 100Mbit TX_DELAY=4:  89 &  89
>>
> 
> I tried to reproduce the results for my rev.G2 board (2017), but could
> not reproduce the bad performance.  My results are:

Oops! Forget to mention an important detail. Only about 20% of the
Rev.G2 boards that Olimex tested (out of a large number) were facing
this issue. We were also not able to reproduce the problem on one of the
Rev.G2 boards. However, Olimex assures us that the problem is real. They
mentioned that tolerances ranges of various hardware components could be
the reason for only some boards facing this issue and not all. Setting
TX_DELAY=4 works on 100% of all Rev. G2  boards.

When releasing FreedomBox Pioneer Edition this week, we had to
unfortunately ship with a patched version of u-boot with TX_DELAY=4.

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#845128: u-boot: Olimex Lime 2 Rev C Gigabit Ethernet problem

2019-04-26 Thread Sunil Mohan Adapa
I noticed that a "force master" workaround[1] was introduced into u-boot
in 2016 after some discussion[2] for fixing poor Ethernet performance on
RTL8211C found in Lime2 Rev.C. Later, perhaps inadvertently, this seems
to be removed[3].

Links:

1) https://lists.denx.de/pipermail/u-boot/2016-March/249629.html

2) https://lists.denx.de/pipermail/u-boot/2016-March/248498.html

3)
https://git.denx.de/?p=u-boot.git;a=blobdiff;f=configs/A20-OLinuXino-Lime2_defconfig;h=a4ade72d4a3a8029d6417e7658655d5e91aaa20f;hp=0d38f65c50e91493f6eb9c483fc816a18469e9c9;hb=8728c97eff5bd95f58320f886ae305f17931a374;hpb=c9592e3c5c97981787c0d82f768a6971deb4837d

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#927397: u-boot: Very poor ethernet performance on A20 OLinuXino Lime2 Rev.G2

2019-04-25 Thread Sunil Mohan Adapa
>
> It seems you forgot to attach the mentioned Olimex report.

The report is in the inline section "Report from Olimex team (with
Rev.G2)". I used term 'attached' loosely.

>
> Do I understand you correctly that the attached patch is what Olimex
> propose but that you do *not* recommended to use it as-is because it
> badly affects older boards?

Olimex has kindly provided us the patch so that we can create a fully
working u-boot build for Lime2 Rev.G2 board. They did not imply that the
patch was suitable for other boards as well.

>
> Were your Lime2 boards connected with a cross-over cable or via a switch
> during those tests?

Lime2 was connected to a laptop via a cross-over cable (actually regular
cable but the hardware actually detects cross-over setup and
automatically swaps TX/RX).

[...]

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#927397: u-boot: Very poor ethernet performance on A20 OLinuXino Lime2 Rev.G2

2019-04-25 Thread Sunil Mohan Adapa
The following is the patch Olimex has applied on u-boot for the images
that they build. It is meant to work for all hardware revisions of Lime2.

https://github.com/OLIMEX/OLINUXINO/blob/master/SOFTWARE/A20/A20-build-3.4.103-release-7/a20-phy_1000_100-dram.patch

It does not seem suitable for non-Lime2 boards and may need changes to
before it can be submitted upstream (or Debian).

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#924523: unblock: plinth/19.2

2019-04-24 Thread Sunil Mohan Adapa
On 24/04/19 3:30 am, Sam Hartman wrote:
>>>>>> "Sunil" == Sunil Mohan Adapa  writes:
> 
> Sunil> On 23/04/19 3:44 am, Ivo De Decker wrote:
> >> Hi,
> 
> 
> Sunil> However, there were still issues that we felt needed fixing
> Sunil> for a stable release. Some of these fixes are workarounds for
> Sunil> issues that were not fixed in other packages (such as #919517
> Sunil> and smooth upgrade failures in other packages).
> 
> Sunil> Pretty much all the changes between 19.1 and 19.2 (version
> Sunil> increment is because freedombox is a native package) were
> Sunil> focused on Buster release during which we were not adding
> Sunil> extra features.
> 
> I'm speaking as an individual who has been following freedombox in the
> background for years and who has had to make decisions like what the
> release team does in other projects.  I'm *not* speaking as the DPL even
> a little bit.  And even if you follow my recommendations here, the RT
> might be more conservative than you hope for.
>  
> 
> In order to maximize the number of changes that can get in between 19.1
> and 19.2, I recommend that you spend some time to make the release
> team's job easier.
> 
> 
> I'd recommend going through each commit, explaining why it meets the
> release guidelines.
> 
> If it doesn't and you want to argue for an exception, be clear about why
> that specific change is safe.  As an example, if one of your functional
> tests covers it, say that.
> 
> Your job is to make sure that the release team can easily see in one
> place why the change is worth the risk and that you've thought about it
> explicitly and considered the option of dropping that change.
> 
> And you probably will find changes that it's better to drop.
> Regardless of whether you missed the deadline by hours or whatever,
> we're talking about  this issue now not then.  There's less time between
> now and the buster release than there was back in March, and that means
> the risks are higher.  And so in arguing for a change you need to
> account for that increased risk.
> 
> And because the RT has a lot of work to do you need to make it easy for
> them.  They are going to have to review each change, so you'd better do
> that first:-)
> 
> As an example, from your original bug:
> 
>   - Upgrade changes: Complementary to unattened-upgrades, assist
> non-technical  
> FreedomBox users to automatically upgrade from older versions of
> bind,  
> tt-rss, firewalld, libpam-modules, and openvpn. This helps users
> migrating  
> from Stretch. Another change was to avoid a conffile prompt within
>   
> FreedomBox itself to ease future upgrades.
>   
> 
> This sounds like an important bug: you ran upgrade testing from stretch
> and ran into an issue that impacted users.
> If there's not a bug number, you want one probably.  If there is, make
> sure it's marked important and it's clear why.
> 

Thank you for taking the time to explain how to assist release team with
the process. I didn't do a good job of justifying the changes first time.

No matter the outcome, I regret putting extra burden on release team at
a time when every is working hard for and anticipating Buster.

Below I attempt to review and explain each change between 19.1 and 19.2
so that it may become easier for release team to review each change
individually.

https://salsa.debian.org/freedombox-team/plinth/commits/v19.2

Changes to documentation


- These changes can be considered during full freeze as per freeze policy.

- FreedomBox documentation appears to users directly in the web interface.

- List includes changes to copyright messages and the machine readable
copyright files. These changes have extremely slim chances to break the
functionality and have been tested well.

8ae99fad doc: Fetch manual from wiki
7c01585f debian/copyright: Fix filename for tahoe-lafs logo
0a1a0cd1 debian/copyright: Update copyright for logos
06d1b167 debian/copyright: Add license text for CC-BY-SA-3.0
1e48a64d debian/copyright: Add license text for GPL-2 and GPL-3
f5c85471 debian/copyright: Add license text for public-domain
a4fdf3f7 debian/copyright: Add full text for AGPL-3+
130102e1 debian/copyright: Minor fixes
e4e37992 debian/copyright: Move some more app icons from LICENSES
a1d13029 debian/copyright: Include some URLs dropped from LICENSES
2297defe debian/copyright: Move more app icons from LICENSES
990c2446 debian/copyright: Fix typo in year
f2b45ea1 debian/copyright: Move some app icons from LICENSES
7b0957d7 debian/copyright: Remove unnecessary fields for native package
d4b4d1e2 debian/copyright: Move all license texts to end
4e

Bug#924523: unblock: plinth/19.2

2019-04-23 Thread Sunil Mohan Adapa
On 23/04/19 3:44 am, Ivo De Decker wrote:
> Hi,
> 
> On Wed, Mar 13, 2019 at 03:07:27PM -0700, Sunil Mohan Adapa wrote:
>> Due to incorrect release planning, we missed the full freeze deadline by a 
>> few
>> hours. We assumed packages may transition on 12th March and did our release 
>> few
>> hours after 2019-03-02 00:00 UTC (package was accepted at 20:47:49 UTC). We
>> request you to make an exception and transition FreedomBox release 19.2.
> 
> These changes don't look like they are appropriate during the freeze. Please
> note that 'just missing the full freeze deadline' is not a reason for an
> unblock. Also, note that the soft freeze started 2019-02-12.>
> https://release.debian.org/buster/freeze_policy.html
> 

Thank you for taking the time to review this request.

We did meet the soft freeze date by making several good releases with
several months of effort.

However, there were still issues that we felt needed fixing for a stable
release. Some of these fixes are workarounds for issues that were not
fixed in other packages (such as #919517 and smooth upgrade failures in
other packages).

Pretty much all the changes between 19.1 and 19.2 (version increment is
because freedombox is a native package) were focused on Buster release
during which we were not adding extra features.

I respect the decision to not unblock, but please see if this
information sheds some new light to make the case eligible for
reconsideration.

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#845128: u-boot: Olimex Lime 2 Rev C Gigabit Ethernet problem

2019-04-18 Thread Sunil Mohan Adapa
The issue seems to continue on recent versions of u-boot. However, this
problem does not seem to be present in Rev.G2 of the board (which has
problem with transmit performance as reported in #927397).

I have recently noticed that the receive performance on my Rev.C board
is very poor and that I was using old version of u-boot (U-Boot SPL
2016.03+dfsg1-4). So, I updated to u-boot 2019.01+dfsg-4 available in
unstable. The problem could still be reproduced. Here are the results of
my tests:

root@freedombox:~# iperf3 -c 10.42.1.1 -R
Connecting to host 10.42.1.1, port 5201
Reverse mode, remote host 10.42.1.1 is sending
[  5] local 10.42.1.139 port 48228 connected to 10.42.1.1 port 5201
[ ID] Interval   Transfer Bitrate
[  5]   0.00-1.00   sec   281 KBytes  2.30 Mbits/sec
[  5]   1.00-2.00   sec  60.8 KBytes   498 Kbits/sec
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   3.00-4.00   sec   158 KBytes  1.30 Mbits/sec
[  5]   4.00-5.00   sec   235 KBytes  1.92 Mbits/sec
[  5]   5.00-6.00   sec   110 KBytes   903 Kbits/sec
[  5]   6.00-7.00   sec   228 KBytes  1.86 Mbits/sec
[  5]   7.00-8.00   sec   109 KBytes   892 Kbits/sec
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   9.00-10.00  sec   112 KBytes   916 Kbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.04  sec  1.38 MBytes  1.15 Mbits/sec  188 sender
[  5]   0.00-10.00  sec  1.26 MBytes  1.06 Mbits/sec
receiver

iperf Done.
root@freedombox:~# iperf3 -c 10.42.1.1
Connecting to host 10.42.1.1, port 5201
[  5] local 10.42.1.139 port 48232 connected to 10.42.1.1 port 5201
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.01   sec  65.8 MBytes   545 Mbits/sec0468 KBytes

[  5]   1.01-2.01   sec  67.5 MBytes   567 Mbits/sec0468 KBytes

[  5]   2.01-3.01   sec  66.5 MBytes   556 Mbits/sec0673 KBytes

[  5]   3.01-4.00   sec  67.2 MBytes   570 Mbits/sec0841 KBytes

[  5]   4.00-5.01   sec  53.8 MBytes   450 Mbits/sec0841 KBytes

[  5]   5.01-6.01   sec  65.0 MBytes   545 Mbits/sec0841 KBytes

[  5]   6.01-7.02   sec  46.2 MBytes   384 Mbits/sec0841 KBytes

[  5]   7.02-8.02   sec  66.2 MBytes   556 Mbits/sec0884 KBytes

[  5]   8.02-9.00   sec  68.6 MBytes   583 Mbits/sec0884 KBytes

[  5]   9.00-10.01  sec  63.1 MBytes   525 Mbits/sec0   1.09 MBytes

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.01  sec   630 MBytes   528 Mbits/sec0 sender
[  5]   0.00-10.05  sec   630 MBytes   526 Mbits/sec
receiver

iperf Done.
root@freedombox:~# mii-tool eth0 -A 100BaseTx-FD
restarting autonegotiation...
root@freedombox:~# iperf3 -c 10.42.1.1
Connecting to host 10.42.1.1, port 5201
[  5] local 10.42.1.139 port 48236 connected to 10.42.1.1 port 5201
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec  11.5 MBytes  96.0 Mbits/sec0119 KBytes

[  5]   1.00-2.00   sec  11.2 MBytes  94.4 Mbits/sec0124 KBytes

[  5]   2.00-3.00   sec  11.1 MBytes  92.7 Mbits/sec0139 KBytes

[  5]   3.00-4.00   sec  11.2 MBytes  94.3 Mbits/sec0139 KBytes

[  5]   4.00-5.00   sec  11.2 MBytes  94.4 Mbits/sec0139 KBytes

[  5]   5.00-6.00   sec  11.2 MBytes  93.9 Mbits/sec0139 KBytes

[  5]   6.00-7.00   sec  11.3 MBytes  94.9 Mbits/sec0139 KBytes

[  5]   7.00-8.00   sec  11.2 MBytes  93.8 Mbits/sec0139 KBytes

[  5]   8.00-9.00   sec  11.2 MBytes  93.8 Mbits/sec0139 KBytes

[  5]   9.00-10.00  sec  11.2 MBytes  93.8 Mbits/sec0139 KBytes

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.00  sec   112 MBytes  94.2 Mbits/sec0 sender
[  5]   0.00-10.04  sec   112 MBytes  93.6 Mbits/sec
receiver

iperf Done.
root@freedombox:~# iperf3 -c 10.42.1.1 -R
Connecting to host 10.42.1.1, port 5201
Reverse mode, remote host 10.42.1.1 is sending
[  5] local 10.42.1.139 port 48240 connected to 10.42.1.1 port 5201
[ ID] Interval   Transfer Bitrate
[  5]   0.00-1.00   sec  11.2 MBytes  94.3 Mbits/sec
[  5]   1.00-2.00   sec  11.2 MBytes  93.7 Mbits/sec
[  5]   2.00-3.00   sec  11.2 MBytes  93.7 Mbits/sec
[  5]   3.00-4.00   sec  11.2 MBytes  93.7 Mbits/sec
[  5]   4.00-5.00   sec  11.2 MBytes  93.7 Mbits/sec
[  5]   5.00-6.00   sec  11.2 MBytes  93.7 Mbits/sec
[  5]   6.00-7.00   sec  11.2 MBytes  93.7 Mbits/sec
[  5]   7.00-8.00   sec  11.2 MBytes  93.7 Mbits/sec
[  5]   8.00-9.00   sec  11.2 MBytes  93.7 Mbits/sec
[  5]   9.00-10.00  sec  11.2 MBytes  93.7 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.04  sec   113 MBytes  94.6 Mbits/sec0 sender
[  5]   0.00-10.00  sec   112 

Bug#927397: u-boot: Very poor ethernet performance on A20 OLinuXino Lime2 Rev.G2

2019-04-18 Thread Sunil Mohan Adapa
Source: u-boot
Version: 2019.01+dfsg-4
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Olimex team working with FreedomBox team have noticed a significant slowdown in
Gigabit Ethernet when transmitting. Original report from Olimex team is
attached. This is applicable for hardware Rev.G2 of the A20 OLinuXino Lime2
board.

Olimex team have sent a patch that fixes the issue for Rev.G2 (attached).
Multiple team members from FreedomBox have confirmed that the patch fixes
transmit performance issue for Rev.G2 and yields good transmit/receive
performance. However this patch makes the situation worse for Rev.C (my test
results attached). I believe this issue is separate from #845128 (will post
more information there) which already causes *receive* performance to be bad on
Rev.C.

=
Report from Olimex team (with Rev.G2)
=

Our test shows that speed in TX side is very slow and unstable. The problem is
in the wrong clock delay settings. We corrected this settings in our image and
recommend you to change the TX delay too. You have to change value of
CCM_GMAC_CTRL_TX_CLK_DELAY register on address 0x01c20164 from 0x0006 to
0x1006. This should be changed in the u-boot sources and the image should
be  compiled again.

- --
Tests with original image. Unchaged CCM_GMAC_CTRL_TX_CLK_DELAY value(0006)
- --

=> md.l 0x01c20164 1
01c20164: 0006


admin@freedombox:~$ iperf3 -c 192.168.0.60 -p 2001
Connecting to host 192.168.0.60, port 2001
[  5] local 192.168.0.135 port 57448 connected to 192.168.0.60 port 2001
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec   375 KBytes  3.07 Mbits/sec   32   4.24 KBytes
[  5]   1.00-2.00   sec  1.67 MBytes  14.0 Mbits/sec  147   9.90 KBytes
[  5]   2.00-3.00   sec  4.49 MBytes  37.6 Mbits/sec  261   2.83 KBytes
[  5]   3.00-4.00   sec   669 KBytes  5.48 Mbits/sec   61   5.66 KBytes
[  5]   4.00-5.00   sec  2.78 MBytes  23.3 Mbits/sec  160   1.41 KBytes
[  5]   5.00-6.00   sec   829 KBytes  6.79 Mbits/sec   88   1.41 KBytes
[  5]   6.00-7.00   sec  1.47 MBytes  12.4 Mbits/sec   94   2.83 KBytes
[  5]   7.00-8.00   sec  1.55 MBytes  13.0 Mbits/sec   98   1.41 KBytes
[  5]   8.00-9.00   sec  2.47 MBytes  20.8 Mbits/sec  169   1.41 KBytes
[  5]   9.00-10.00  sec   700 KBytes  5.73 Mbits/sec   44   2.83 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.00  sec  16.9 MBytes  14.2 Mbits/sec  1154 sender
[  5]   0.00-10.00  sec  16.8 MBytes  14.1 Mbits/sec  receiver

iperf Done.
admin@freedombox:~$ iperf3 -c 192.168.0.60 -p 2001 -R
Connecting to host 192.168.0.60, port 2001
Reverse mode, remote host 192.168.0.60 is sending
[  5] local 192.168.0.135 port 57452 connected to 192.168.0.60 port 2001
[ ID] Interval   Transfer Bitrate
[  5]   0.00-1.00   sec  97.1 MBytes   814 Mbits/sec
[  5]   1.00-2.00   sec  98.2 MBytes   824 Mbits/sec
[  5]   2.00-3.00   sec  98.5 MBytes   826 Mbits/sec
[  5]   3.00-4.00   sec  48.6 MBytes   408 Mbits/sec
[  5]   4.00-5.00   sec  98.2 MBytes   824 Mbits/sec
[  5]   5.00-6.00   sec  97.9 MBytes   821 Mbits/sec
[  5]   6.00-7.00   sec  98.2 MBytes   824 Mbits/sec
[  5]   7.00-8.00   sec  97.7 MBytes   820 Mbits/sec
[  5]   8.00-9.00   sec  98.4 MBytes   826 Mbits/sec
[  5]   9.00-10.00  sec  27.5 MBytes   231 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.00  sec   861 MBytes   722 Mbits/sec   58 sender
[  5]   0.00-10.00  sec   860 MBytes   722 Mbits/sec  receiver

iperf Done.


- -
Test with CCM_GMAC_CTRL_TX_CLK_DELAY value set to 1006
- -

=> md.l 0x01c20164 1
01c20164: 1006   


admin@freedombox:~$ iperf3 -c 192.168.0.60 -p 2001
Connecting to host 192.168.0.60, port 2001
[  5] local 192.168.0.135 port 53002 connected to 192.168.0.60 port 2001
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec  47.5 MBytes   398 Mbits/sec0153 KBytes
[  5]   1.00-2.01   sec  53.8 MBytes   448 Mbits/sec0206 KBytes
[  5]   2.01-3.00   sec  32.8 MBytes   277 Mbits/sec1235 KBytes
[  5]   3.00-4.00   sec  67.5 MBytes   567 Mbits/sec0235 KBytes
[  5]   4.00-5.00   sec  56.2 MBytes   471 Mbits/sec0235 KBytes
[  5]   5.00-6.02   sec  48.8 MBytes   400 Mbits/sec0235 KBytes
[  5]   6.02-7.01   sec  47.5 MBytes   402 Mbits/sec0235 KBytes
[  5]   7.01-8.02   sec  48.8 MBytes 

Bug#924523: unblock: plinth/19.2

2019-04-01 Thread Sunil Mohan Adapa
On Wed, 13 Mar 2019 15:07:27 -0700 Sunil Mohan Adapa 
wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Please unblock package plinth
> (binary packages: plinth, freedombox)
> 
> Due to incorrect release planning, we missed the full freeze deadline by a few
> hours. We assumed packages may transition on 12th March and did our release 
> few
> hours after 2019-03-02 00:00 UTC (package was accepted at 20:47:49 UTC). We
> request you to make an exception and transition FreedomBox release 19.2.
> 

Please let us know if any further information will help with this request.

Thank you,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#921812: mldonkey-server: Add systemd service file for better security

2019-02-08 Thread Sunil Mohan Adapa
Package: mldonkey-server
Version: 3.1.6-1+b1
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

It would nice to have a systemd service file for starting/stopping the daemon.
It would avoid problems like #920466 and improve security due various
restrictions that systemd can place. Attached is service file that we have
tested for some simple operations. It lets the log get collected by journald on
systems running systemd allowing for better log rotation too.

Thanks,

- --
Sunil



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

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

Versions of packages mldonkey-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.70
ii  libbz2-1.0 1.0.6-9
ii  libc6  2.28-5
ii  libgcc11:8.2.0-14
ii  libgd3 2.2.5-5
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libpng16-161.6.36-2
ii  libstdc++6 8.2.0-14
ii  lsb-base   10.2018112800
ii  mime-support   3.61
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

mldonkey-server recommends no packages.

mldonkey-server suggests no packages.

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAlxeN80RHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfI/FQ//ehnR13Ji5Up0G/onwHyarHM+Fd5whjmn
+clBJG28zX42ttgvFfbYokpEF6hoa0UeojNCKUayAlZIP+hK4opDv6u6dCABIr7H
hJczQt+sVgumRmzwXtxEQIzgz1cz60CGxSo9QTJprFm5Lq+ZdoaTPczruaOUDMGA
5/6slk4QTiAD8mYwArH1ajGEj0qkea/A5YZjvMXjwpckXGqzwuaoiR6ApelNrZYm
ZPscdPMHW+eLRUkhNXxbGB2KUCCAiRxRwYpbpdzvesYG7m1OCIw2M6X5rcR0uIcA
cBYH2SKkqWo59hy6d5VZ21tGwhdsps4rRK4nFJXYRC64K8IMSOMfRcF6nkgzYugP
QAsfLVrgy3PivkRKsoW572gR+ofEqTPX+Lo/+RBJFUCkSYf1JQBZSRPGBDm7veK7
8jyBNDqckXqhDpXbdEmBEvDfyiMpVfTa4Ec3VT0re75+q7Y2IFY2FEzmHoweAyCy
LrcjahXZjdjM4QSBPpSnkoaPi+1yWHvlAh2thSFsD7ct2cNHn5dzTg/8qgrdMM0y
xAajptd70Cg9j8Twi8U4F/bFV5xxbyjK0GvrDHaGPBeEFt4IClR3BAQRazwZ2mQo
FgDomWH1KsSkkllMfg08pz1voDJWyBNdSAnwASTgQ3rI2UiIwz6HbRr/4psWIUuy
MIQM+kyuXpU=
=H4cX
-END PGP SIGNATURE-
[Unit]
Description=MLDonkey: Multi-protocol, peer-to-peer file sharing server
After=syslog.target network.target
ConditionPathExists=/var/lib/mldonkey/downloads.ini
Documentation=man:mlnet(1) http://mldonkey.sourceforge.net/Main_Page

[Service]
ExecStart=/usr/bin/mlnet
Group=mldonkey
LockPersonality=yes
NoNewPrivileges=yes
PrivateDevices=yes
PrivateMounts=yes
PrivateTmp=yes
PrivateUsers=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectSystem=strict
ReadWritePaths=/var/lib/mldonkey
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictRealtime=yes
StateDirectory=mldonkey
SystemCallArchitectures=native
Type=simple
User=mldonkey
WorkingDirectory=/var/lib/mldonkey

[Install]
WantedBy=multi-user.target


Bug#917582: Please prevent autoremoval of freedombox

2019-02-06 Thread Sunil Mohan Adapa
Hello,

The two bugs #917582 and #917584 are threatening removal of freedombox
from testing. As soft freeze is fast approaching, and once removed, we
won't be able to add freedombox back into buster. Please consider
uploading soon the newer upstream 0.9.0 which will hopefully eliminate
the two bugs.

Thank you,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#919517: firewalld: Failure to start with OpenVPN installed and nftables backend

2019-02-01 Thread Sunil Mohan Adapa
On Wed, 16 Jan 2019 12:27:15 -0800 Sunil Mohan Adapa 
wrote:
[...]
> 
> This is a simple fix with nft rules insertion. This is already fixed in
> upstream about four weeks ago and that patch is attached. In case, upstream
> does not make a release soon, please consider adding this patch to Debian
> packaging due to severity of the issue.
> 

Hello,

It would be really nice to have this upstream commit cherrypicked before
the buster freeze. Once the bug hits, firewalld is unusable on the
system leading to security concerns.

Thanks for all the work,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#920466: mldonkey-server: Init script fails to stop daemon properly

2019-01-25 Thread Sunil Mohan Adapa
Package: mldonkey-server
Version: 3.1.6-1+b1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

As part of adding mldonkey into FreedomBox, we noticed that the mldonkey-server
does not stop properly. This is because start-stop-daemon is asked to stop
based only on the PID file which is owned by non-root user. Making the process
match more specific fixes the problem.

# start-stop-daemon --stop --pidfile /var/run/mldonkey/mlnet.pid
start-stop-daemon: matching only on non-root pidfile
/var/run/mldonkey/mlnet.pid is insecure
# echo $?
2
# start-stop-daemon --stop --pidfile /var/run/mldonkey/mlnet.pid --exec
/usr/bin/mlnet
# echo $?
0

I have created a merge request to fix the issue. Tagging this issue with
'patch'.

https://salsa.debian.org/ocaml-team/mldonkey/merge_requests/1

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

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

Versions of packages mldonkey-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.70
ii  libbz2-1.0 1.0.6-9
ii  libc6  2.28-5
ii  libgcc11:8.2.0-14
ii  libgd3 2.2.5-5
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libpng16-161.6.36-2
ii  libstdc++6 8.2.0-14
ii  lsb-base   10.2018112800
ii  mime-support   3.61
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

mldonkey-server recommends no packages.




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAlxLhiMRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfK/1w/9H/vFfCW/N7EM1DkzWkHoNzKtaW/Xn0Ih
rJzb7fUyq3LFBexILTMHvgz8d/hPoRFuktgY2Thvq8E546bRB4oYfStXfFO+njXd
LkMKEPhyKqTgOfRjCMKVr7QUtBpYN5XBze99esEhIGzg9Al/vZXyBxtz4voFJ2LL
R0p/0FlWCT6fXsy3z0T5Mfm0jV4IyC42bh/1MemzR7ATmvc6mL9/TMXV3vZEdX2A
OMu+XRkJhown5vQVeC32hfJWreb5J93urVPdHXltXZb5tJjvx9X3tfNAK3i/EEx+
5aXktK4/TP8BAj/A2uJ6yxf4vE5HFPxrca8ZrX4qcjstHuaB/yGCru2oWaUzkBD5
0RFn5HOtwXI8NXVP6zTIimVQqkoXzeY8SQsSQBToWkxjJchXQ0u9EiijdZM5nDNJ
qfJVp/qk6okK9MerP2sNwtHAWyxgOa5iqFrifITmLoJfZrmtkkg4VRs1eYpCGHr9
v9E2wCsKfRp2V/tKzASbxk6Oc7P7iEBWMmQTAmuSmK84k2VvQTwjMy+OCOOeIue5
Gqdwz1+BgpIF4baRgIalYIu9iGHfQBErfY3GLgcdjJx+ketfqZHw3VTlLjCipfUt
D/ppP5q4FlHnlb5OraNakVwei1Bdn2wK7UnevjqGcMMYRm5m1YkK3Ci3gUnwz4zv
Ruln29zlUD8=
=5KnO
-END PGP SIGNATURE-



Bug#919809: freedom-maker: please don't depend on pxz which shall be removed for buster

2019-01-22 Thread Sunil Mohan Adapa
tags 919809 + pending
stop

On Sat, 19 Jan 2019 18:42:53 + Holger Levsen  wrote:
> Package: freedom-maker
> Version: 0.22
> Severity: important
> block 919616 by -1
> 
> Dear maintainer,
> 
> freedom-maker currently depends on pxz, however even xz in Stretch now
> supports parallel compression with the -T switch. Therefore I would like
> to remove pxz from Buster, which is only possible if freedom-maker
> (and forensics-extra) drop the depends on pxz. See #919616.
> 
> Thanks for maintaining freedom-maker!
> 

Thank you for reporting this issue and pointing us towards xz -T. A fix
has been merged[1]. The fix will be released on 2019-01-29 as per our
bi-weekly release schedule and will migrate to testing 2-3 days after that.

Links:

1) https://salsa.debian.org/freedombox-team/freedom-maker/merge_requests/166

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature


Bug#656750: [monkeysphere] Bug#656750: monkeysphere: wrongly preserves TMPDIR across accounts

2019-01-16 Thread Sunil Mohan Adapa
tags 656750 + patch
thanks

On Mon, 23 Jan 2012 12:55:58 -0500 Daniel Kahn Gillmor
 wrote:
> On 01/23/2012 12:19 PM, Jameson Graef Rollins wrote:
> > It occurs to me that we already have/use a tmp directory in the
> > monkeysphere authentication directory
> > (/var/lib/monkeysphere/authentication/tmp).  Maybe we should just
> > explicitly set TMPDIR for the monkeysphere user to be that?
> 
> Doing this and documenting it clearly seems like a reasonable approach
> to me.
> 
>   --dkg
> 

The attached patch fixes the problem. Patch sets TMPDIR to
/var/lib/monkeysphere/authentication/tmp only when needed, but I have
tested other cases where temporary directory was being created.

* Need Change

- monkeysphere-host: add_revoker: with key from a remote server and with
  key file.

- monkeysphere-host: publish_key:

- monkeysphere-authentication: add_certifier: with key from remote
  server and with key file.

* No change needed:

- monkeysphere-host: show_key: does not use monkeysphere user.

- monkeysphere-host: revoke_key: does not use monkeysphere user. So any
  temporary directory works.

- monkeysphere: import_subkey: does not use monkeysphere user. Not
  implemented yet.

- monkeysphere: gen_subkey: does not use monkeysphere user.

- monkeysphere-authentication: update_users: Creates files that are fed
to less privileged process via stdin. Could not test properly.

With this change, I am hoping for a new release of monkeysphere suitable
for FreedomBox in buster.

Thanks,

-- 
Sunil
From 34b83f6ee26d527d415f033fd57db6bfe81eed90 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Wed, 16 Jan 2019 16:15:21 -0800
Subject: [PATCH] Better sharing of temp directory across root and monkeysphere
 user

In a couple of cases, monkeysphere commands running as run create a temporary
directory in TMPDIR (provided by environment) and then change the
ownership/permissions on that directory for monkeysphere user to use that
directory.

This works in a normal setup but fails when libpam-tmpdir is installed. This PAM
module causes the tmp directory to be /tmp/user/0/ so that it is harder to for
users to access each other temporary files. This improves security but causes
problem for above situation as the parent directory of the directory to be
shared is not allowed access by other users.

To fix this, explicitly set the TMPDIR to a known location that can be used to
share files across users. /var/lib/monkeysphere/authentication/tmp is a
directory that is already being setup and used for such purposes. Reuse it
instead of created a new one. Apply the fix conservatively only in cases needed.

Closes: #656750.

Signed-off-by: Sunil Mohan Adapa 
---
 src/monkeysphere-host  |  9 +
 src/share/ma/add_certifier | 15 ++-
 src/share/mh/add_revoker   | 13 +++--
 src/share/mh/publish_key   |  1 +
 4 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/src/monkeysphere-host b/src/monkeysphere-host
index 089c2b6..1f47df0 100755
--- a/src/monkeysphere-host
+++ b/src/monkeysphere-host
@@ -30,6 +30,15 @@ MHSHAREDIR="${SYSSHAREDIR}/mh"
 # datadir for host functions
 MHDATADIR="${SYSDATADIR}/host"
 
+# temp directory to enable sharing a temporary directory between root and
+# monkeysphere users. This is needed so that on secure environments with
+# libpam-tmpdir, simply changing ownership/permissions on a directory is not
+# enough to share the directory. Parent directories such as /tmp/user/0 will be
+# inaccessible to monkeysphere user.
+#
+# XXX: Reusing monkeysphere-authentication's tmp directory.
+MHTMPDIR="${SYSDATADIR}/authentication/tmp"
+
 # host pub key files
 HOST_KEY_FILE="${SYSDATADIR}/host_keys.pub.pgp"
 
diff --git a/src/share/ma/add_certifier b/src/share/ma/add_certifier
index bd9885c..498bb68 100644
--- a/src/share/ma/add_certifier
+++ b/src/share/ma/add_certifier
@@ -98,15 +98,28 @@ if [ -f "$keyID" -o "$keyID" = '-' ] ; then
 	log verbose "reading key from file '$keyID'..."
 fi
 
+TMPDIR=$MATMPDIR
+tmpDir=$(msmktempdir)
+trap "rm -rf $tmpDir" EXIT
+
+# fix permissions and ownership on temporary directory which will
+# be used by monkeysphere user
+chmod 0700 "$tmpDir"
+chown "$MONKEYSPHERE_USER":"$MONKEYSPHERE_GROUP" "$tmpDir"
+
 # check the key is ok as monkeysphere user before loading
 log debug "checking keys in file..."
-fingerprint=$(run_as_monkeysphere_user \
+fingerprint=$(run_as_monkeysphere_user /usr/bin/env TMPDIR=$tmpDir \
 	bash -c "$(printf ". %q && list_primary_fingerprints" "${SYSSHAREDIR}/common")" < "$keyID")
 
 if [ $(printf "%s" "$fingerprint" | egrep -c '^[A-F0-9]{40}$') -ne 1 ] ; then
 	failure "There was not exactly one gpg key in the file."
  

Bug#877002: nslcd installation broken: missing ca-certificates.crt

2019-01-16 Thread Sunil Mohan Adapa
On Tue, 8 Jan 2019 17:08:16 -0800 Sunil Mohan Adapa 
wrote:
> severity 877002 important
> tags 877002 + patch
> thanks
> 
> This bug is causing issues with autopkgtests for FreedomBox package.
> Bumping severity as simple install on a minimal machine fails.
> 
> On Wed, 27 Sep 2017 17:32:22 +0200 (CEST) Robert Wolf wrote:
> [...]
> > 
> > 
> > Either must nslcd depends on ca-certificates or nslcd.conf should not 
> > contain 
> > configuration:
> 
> It seems reasonable to add ca-certificates as dependency as the initial
> configuration for nslcd uses the certificates from the package.
> 
> The attached patch adds ca-certificates as dependency. I have tested
> that bug is indeed resolved after building nslcd package with change in
> dependency.
> 
> Please consider uploading a fix for the issue.
> 

It would be nice to have fix for this in time for buster. Please
consider uploading the proposed fix.

Thanks,

-- 
Sunil



Bug#919517: firewalld: Failure to start with OpenVPN installed and nftables backend

2019-01-16 Thread Sunil Mohan Adapa
Package: firewalld
Version: 0.6.3-4
Severity: important
Tags: patch upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Installing and setting up OpenVPN causes firewalld to fail to start when
nftables backend is being used. The bug can be reproduced as follows:

firewall-cmd --zone=internal --add-interface=tun+

shows:

firewalld[459]: ERROR: Failed to apply rules. A firewall reload might solve the
issue if the firewall has been modified using ip*tables or ebtables.
firewalld[459]: ERROR: '/usr/sbin/nft insert rule inet firewalld
raw_PREROUTING_ZONES iifname tun+ goto raw_PRE_internal' failed: Error: syntax
error, un
insert rule inet firewalld raw_PREROUTING_ZONES iifname tun+
goto raw_PRE_internal
   ^

Then adding the rule permanently (as is done during FreedomBox setup of
OpenVPN):

firewall-cmd --zone=internal --add-interface=tun+ --permanent

leads to firewalld not starting properly due to above errors and blocking out
the user from network completely. While this problem is only effecting OpenVPN
there are other problems like functional test suite failing and restoring from
backups (with OpenVPN data) triggering the issue. For FreedomBox this is an RC
issue.

This is a simple fix with nft rules insertion. This is already fixed in
upstream about four weeks ago and that patch is attached. In case, upstream
does not make a release soon, please consider adding this patch to Debian
packaging due to severity of the issue.

Thanks,

- --
Sunil



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

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

Versions of packages firewalld depends on:
ii  dbus 1.12.12-1
ii  gir1.2-glib-2.0  1.58.3-2
ii  init-system-helpers  1.56+nmu1
ii  iptables 1.8.2-3
ii  policykit-1  0.105-23
ii  python3  3.7.1-3
ii  python3-dbus 1.2.8-2+b3
ii  python3-gi   3.30.4-1
ii  python3-slip-dbus0.6.5-2

Versions of packages firewalld recommends:
ii  ebtables  2.0.10.4+snapshot20181205-1
ii  ipset 6.38-1

firewalld suggests no packages.

- -- Configuration Files:
/etc/firewalld/firewalld.conf [Errno 13] Permission denied: 
'/etc/firewalld/firewalld.conf'
/etc/firewalld/lockdown-whitelist.xml [Errno 13] Permission denied: 
'/etc/firewalld/lockdown-whitelist.xml'

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAlw/k6ARHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfLZtQ//TWkFhcuX0tQ9HVZv2ltS5MHcBIDr4yMr
uh4ChkvfZJGID0RJBxknlmwjDUHysw9769FWX7jRmci4C2VMjJIQhNm9nhdNzZ3w
ajh+n7NXL58hF1tZx3QjQ7gdVRVSC83pXqn75L1aFghuIoFAADiDM8DgRuhvIdDP
ufMmNgyBbyQ1G3F37FpcObiiMPBr2ibDakUrHD9VjKZk9xT/cltuBP5GPou3zwj2
S/Gs/Q4QamqeIyWMeioGzoDYGOQxCtuI38s8Cf+jbIPASdHRQ+dlfpjepSxjCBmZ
2yX0dBptStV9HH2mmFJkpKQzOnH6TZTYNj1vvD8eh14tZvV83AC618BvlQZC9Joz
r7VbCAylpQf/Pf4WXTVzk/VV4/jXmtYVkASufk3Xj6wVepy+0Eij/gySJOl3b3C5
DCo0GbKkYMkZZxNFee/mm1be9QfVeeSqCvFEIyoQ/sj6Q3UTXkqXybH08OpUiTWY
Rql1VZGUiezsxEh/6vG9XChZEDS0VFRrWAM/u1aO6JbmeJ7kEYaB0+ddlUYLd71R
Y4F2dPAjr6YCQAoeYowMOj1Q1YbDfPhbUHmrhtkO0F3DEz3lpTspAuVVCSNrrB4c
5dkpzoeGdnvjbHqgb/hYez/5ox6VRtn+I5B07L2nd8iV0X/fvqO35Qy1vjDxkHmL
DrRAV0JFIb0=
=yirT
-END PGP SIGNATURE-
>From 687953defc201a69e77e8b8f9230cdd34df858db Mon Sep 17 00:00:00 2001
From: Eric Garver 
Date: Mon, 17 Dec 2018 12:53:30 -0500
Subject: [PATCH] nftables: Allow interfaces with wildcards

Fixes: rhbz 1644025
(cherry picked from commit aa01eda4c87dd7b5c1f1e884fc7332c6317fed02)
---
 src/firewall/core/nftables.py | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/firewall/core/nftables.py b/src/firewall/core/nftables.py
index a1cb2c47..50303e94 100644
--- a/src/firewall/core/nftables.py
+++ b/src/firewall/core/nftables.py
@@ -475,6 +475,9 @@ class nftables(object):
 "OUTPUT": "oifname",
 }[chain]
 
+if interface[len(interface)-1] == "+":
+interface = interface[:len(interface)-1] + "*"
+
 target = DEFAULT_ZONE_TARGET.format(chain=SHORTCUTS[chain], zone=zone)
 if zone_target == DEFAULT_ZONE_TARGET:
 action = "goto"
@@ -486,10 +489,10 @@ class nftables(object):
 rule = ["add", "rule", family, "%s" % TABLE_NAME, "%s_%s_ZONES" % 
(table, chain)]
 else:
 rule = ["delete", "rule", family, "%s" % TABLE_NAME, "%s_%s_ZONES" 
% (table, chain)]
-if interface == "+":
+if interface == "*":
 rule += [action, "%s_%s" % (table, target)]
 else:
-rule += [opt, interface, action, "%s_%s" % (table, target)]
+rule += [opt, "\"" + interface 

  1   2   3   >