Bug#1053196: Please remove librados-dev build-depends on all 32 bits arch
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
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#1057093: php-imagick's autopkg tests fail
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#1034231: freedombox: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On 11/04/23 19:01, Sunil Mohan Adapa wrote: [...] I will confirm that freedombox is working well as-is in bookworm and close this issue. On a fresh Debian testing VM, I installed the freedombox package (currently version 23.6). As soon as the package was installed, I noticed that the freedombox daemon was running (due to plinth.service). I also found that start/stop scripts has been properly installed by dh_installsystemd in /var/lib/dpkg/info/freedombox.postinst. Hence this bug does not apply to the freedombox package. Closing. Thank you, -- Sunil
Bug#1034231: freedombox: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Thank you for the bug report and bringing the issue to our attention. On 11/04/23 13:07, bi...@debian.org wrote: Package: freedombox Version: 23.6 Severity: serious Tags: sid bookworm User: debhel...@packages.debian.org Usertags: systemd-files-in-usr-bookworm Dear Maintainer, It seems that your package freedombox is shipping files (.service, .socket or .timer) in /usr/lib/systemd/system. We ship many systemd unit files. Only one of the unit files is a .service meant for freedombox itself. Others units are meant for other packages (most of them configuration extensions). These units must not be started/stopped when freedombox package is installed/uninstalled. Hence this issue applies only to a single unit: plinth.service. This is not supported by the version of dh_installsystemd/debhelper currently in unstable and bookworm (See: #1031695). That means that currently your service might not be enabled at boot and/or started as expected. My understanding of the bug is that dh_installsystemd will not discover services listed in /usr/lib and this will not change for bookworm. Long ago, when lintian was issuing a message about moving unit files from /lib to /usr/lib, we have moved the files. We also realized that the services were not being automatically started after installing the package. So, we implemented a workaround to keep the files in /usr/lib but force dh_installsystemd to discover plinth.service. The workaround reads like this: override_dh_installsystemd: # Do not enable or start any service other than FreedomBox service. Use # of --tmpdir is a hack to workaround an issue with dh_installsystemd # (as of debhelper 13.5.2) that still has hardcoded search path of # /lib/systemd/system for searching systemd services. See #987989 and # reversion of its changes. dh_installsystemd --tmpdir=debian/tmp/usr --package=freedombox plinth.service With the freeze currently in effect, debhelper will not be fixed for bookworm. As a result, could you please move these files to /lib/systemd/system instead so they are properly detected by debhelper? As soon as debhelper is supporting (not until bookworm+1 aka Trixie) you will be able to move them back to the newer location. I believe that the freedombox package does not need any changes for bookworm. Could you please confirm that there are no changes planned for dh_installsystemd that would make our workaround not work anymore? I will confirm that freedombox is working well as-is in bookworm and close this issue. [...] Thank you for your contributions, -- Sunil
Bug#998903: src:libidn: fails to migrate to testing for too long
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
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
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#990223: pcp-zeroconf: modifies conffiles (policy 10.7.3): /etc/default/pmlogger
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
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
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
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
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)
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#984760: grub-pc: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
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#970633: tt-rss: Packaging work for new upstream release 21.1
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
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]"
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
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#979381: Useless in Debian
Hello, I have filed an RM bug (#979832) against the package and CCed David and all the uploaders. Thanks, -- Sunil
Bug#979156: [pkg-php-pear] Bug#979156: Useless in Debian
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#979156: Useless in Debian
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
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#977527: freedombox FTBFS: test_homepage_mapping_skip_ci failure
tag 977527 + pending thanks OpenPGP_signature Description: OpenPGP digital signature
Bug#976135: Breaks tt-rss
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#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
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#851771: php-gettext: CVE-2016-6175
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
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
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#962084: Adding buster-backport to apt sources on install seems wrong
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#962084: Adding buster-backport to apt sources on install seems wrong
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#952359: Please apply the patch and upload
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: /<>
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#950249: Patch submitted upstream
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
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
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
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#944364: dpkg: ldconfig is not invoked for Depends or even Pre-Depends
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#935211: python-acme: Please port to Python 3 and/or drop Python 2 package
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)
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#932981: [Freedombox-pkg-team] Bug#932981: Please remove Python 2 support for this package
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#917582: Please prevent autoremoval of freedombox
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#899060: FTBFS: even if tests pass, dh_auto_test fails
Hello, FreedomBox is set to be autoremoved from testing on 2018/10/21 (in about 5 days) due to mod-gnutls which won't transition into testing which in turn due won't migrate to testing due to its dependency on moneysphere. This effects all FreedomBox users. Please consider uploading the monkeysphere package immediately. Thanks, -- Sunil signature.asc Description: OpenPGP digital signature
Bug#899060: FTBFS: even if tests pass, dh_auto_test fails
tags 899060 +patch
thanks
Hello,
The attached patch seems to fix the problem.
It appears that if a socket that socat wants to listen on exists, socat
fails (socat(1)). When socat finishes by itself, ssh-socket will be
unlinked but if it is killed for some reason than socket file is not
unlinked. The attached patch tells socat to remove the socket before
starting its normal activity.
I got the hint towards this when I stopped cleaning the temp home
directory and read the sshd.log after a failure. I was to reproduce the
problem with high success rate before the patch and after the applying
the patch, I can't reproduce it building 10 times. All of the logs on
this bug report (that are not related to OpenSSL pem2openpgp, fixed in
#909700) are similar and should get fixed with this patch. I didn't
investigate why this behavior was not seen earlier (socat changes?
something else?).
I believe this is the last of the unfixed serious issues. I think this
package is set to cause removal issues for other packages in testing.
Please consider uploading this fix, along with other unreleased fixes, soon.
Thank you,
--
Sunil
From fcd96673225bc488494cf6c2979b21e6e1778299 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa
Date: Fri, 12 Oct 2018 13:01:24 -0700
Subject: [PATCH] tests: Ensure that stale sockets don't fail socat (Closes:
#899060)
---
tests/basic | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/basic b/tests/basic
index 9102bb9..3afe008 100755
--- a/tests/basic
+++ b/tests/basic
@@ -63,7 +63,7 @@ ssh_test() {
# start the ssh daemon on the socket
echo "# starting ssh server..."
-socat EXEC:"/usr/sbin/sshd -f ${SSHD_CONFIG} -i -D -e" "UNIX-LISTEN:${SOCKET}" 2> "$TEMPDIR"/sshd.log &
+socat EXEC:"/usr/sbin/sshd -f ${SSHD_CONFIG} -i -D -e" "UNIX-LISTEN:${SOCKET},unlink-early" 2> "$TEMPDIR"/sshd.log &
SSHD_PID="$!"
# wait until the socket is created before continuing
--
2.19.1
signature.asc
Description: OpenPGP digital signature
Bug#907008: mod-gnutls FTBFS: FAIL: test-16_view-status.bash
tag 907008 + patch thanks Hello, As pointed out, cipher suites removed in latest gnutls is causing the test case to fail. The attached patch fixes the failure. It changes the priority string to match the latest default cipher suite. The patch is against upstream code. Thanks, -- Sunil From 45c47fb511257edba59775cb731fdf377553a4ba Mon Sep 17 00:00:00 2001 From: Sunil Mohan Adapa Date: Tue, 18 Sep 2018 09:41:47 -0700 Subject: [PATCH] Fix test 16-view-status by changing priority string From gnutls 3.5.19 release notes: "The ciphers utilizing HMAC-SHA384 and SHA256 have been removed from the default priority strings. They are not necessary for compatibility or other purpose and provide no advantage over their SHA1 counter-parts, as they all depend on the legacy TLS CBC block mode." Pick a new priority string such that the cipher suite matches the default negotiated by gnutls 3.5.19 server and client without explicitly setting a priority string. --- test/tests/16_view-status/gnutls-cli.args | 2 +- test/tests/16_view-status/output | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/test/tests/16_view-status/gnutls-cli.args b/test/tests/16_view-status/gnutls-cli.args index aca8ac0..470925b 100644 --- a/test/tests/16_view-status/gnutls-cli.args +++ b/test/tests/16_view-status/gnutls-cli.args @@ -1,2 +1,2 @@ --x509cafile=authority/x509.pem ---priority=NONE:+VERS-TLS1.2:+AES-128-CBC:+SHA256:+RSA:+COMP-NULL:+SIGN-RSA-SHA256 +--priority=NONE:+VERS-TLS1.2:+ECDHE-RSA:+CURVE-SECP256R1:+AES-256-GCM:+AEAD:+COMP-NULL:+SIGN-RSA-SHA1 diff --git a/test/tests/16_view-status/output b/test/tests/16_view-status/output index 7786244..8bfb45a 100644 --- a/test/tests/16_view-status/output +++ b/test/tests/16_view-status/output @@ -1,5 +1,5 @@ Using TLS:yes -Current TLS session:(TLS1.2)-(RSA)-(AES-128-CBC)-(SHA256) +Current TLS session:(TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM) - Peer has closed the GnuTLS connection -- 2.18.0 signature.asc Description: OpenPGP digital signature
Bug#894874: A patch is available
tag 894874 + patch
thanks
Thanks to Thomas Klute, a patch to fix the problem is now available[1].
I am also attaching a slightly modified patch that I used for testing.
This applies cleanly on the latest version of mod-gnutls in Debian 0.8.2-3.
Please consider making a release with this patch (probably adding
Depends: apache>=2.4.33-1). There is the danger of newer apache2 getting
into testing and breaking all FreedomBox machines.
Links:
1) https://lists.gnupg.org/pipermail/mod_gnutls-devel/2018-April/000206.html
Thank you,
--
Sunil
--- a/include/mod_gnutls.h.in
+++ b/include/mod_gnutls.h.in
@@ -293,6 +293,9 @@
* connections. */
APR_DECLARE_OPTIONAL_FN(int, ssl_proxy_enable, (conn_rec *));
APR_DECLARE_OPTIONAL_FN(int, ssl_engine_disable, (conn_rec *));
+APR_DECLARE_OPTIONAL_FN(int, ssl_engine_set, (conn_rec *,
+ ap_conf_vector_t *,
+ int proxy, int enable));
int ssl_is_https(conn_rec *c);
int ssl_proxy_enable(conn_rec *c);
int ssl_engine_disable(conn_rec *c);
--- a/src/gnutls_hooks.c
+++ b/src/gnutls_hooks.c
@@ -21,6 +21,7 @@
#include "mod_gnutls.h"
#include "gnutls_cache.h"
#include "gnutls_ocsp.h"
+#include "gnutls_util.h"
#include "http_vhost.h"
#include "ap_mpm.h"
#include "mod_status.h"
@@ -788,23 +789,11 @@
static void create_gnutls_handle(conn_rec * c)
{
-/* Get mod_gnutls server configuration */
-mgs_srvconf_rec *sc = (mgs_srvconf_rec *)
-ap_get_module_config(c->base_server->module_config, _module);
-
_gnutls_log(debug_log_fp, "%s: %d\n", __func__, __LINE__);
/* Get connection specific configuration */
-mgs_handle_t *ctxt = (mgs_handle_t *) ap_get_module_config(c->conn_config, _module);
-if (ctxt == NULL)
-{
-ctxt = apr_pcalloc(c->pool, sizeof (*ctxt));
-ap_set_module_config(c->conn_config, _module, ctxt);
-ctxt->is_proxy = GNUTLS_ENABLED_FALSE;
-}
+mgs_handle_t *ctxt = init_gnutls_ctxt(c);
ctxt->enabled = GNUTLS_ENABLED_TRUE;
-ctxt->c = c;
-ctxt->sc = sc;
ctxt->status = 0;
ctxt->input_rc = APR_SUCCESS;
ctxt->input_bb = apr_brigade_create(c->pool, c->bucket_alloc);
--- a/src/gnutls_util.c
+++ b/src/gnutls_util.c
@@ -125,3 +125,28 @@
return rv;
}
+
+
+
+mgs_handle_t *init_gnutls_ctxt(conn_rec *c)
+{
+mgs_handle_t *ctxt = (mgs_handle_t *)
+ap_get_module_config(c->conn_config, _module);
+if (ctxt == NULL)
+{
+ctxt = apr_pcalloc(c->pool, sizeof (*ctxt));
+ap_set_module_config(c->conn_config, _module, ctxt);
+
+/* Get mod_gnutls server configuration */
+mgs_srvconf_rec *sc = (mgs_srvconf_rec *)
+ap_get_module_config(c->base_server->module_config,
+ _module);
+
+/* Set up connection and server references */
+ctxt->c = c;
+ctxt->sc = sc;
+/* Default, unconditionally changed in proxy setup functions */
+ctxt->is_proxy = GNUTLS_ENABLED_FALSE;
+}
+return ctxt;
+}
--- a/src/gnutls_util.h
+++ b/src/gnutls_util.h
@@ -20,6 +20,7 @@
#include
#include
#include
+#include "mod_gnutls.h"
#ifndef __MOD_GNUTLS_UTIL_H__
#define __MOD_GNUTLS_UTIL_H__
@@ -66,4 +67,10 @@
gnutls_datum_t *datum)
__attribute__((nonnull));
+/**
+ * Allocate the connection configuration structure if necessary, set
+ * some defaults.
+ */
+mgs_handle_t *init_gnutls_ctxt(conn_rec *c);
+
#endif /* __MOD_GNUTLS_UTIL_H__ */
--- a/src/mod_gnutls.c
+++ b/src/mod_gnutls.c
@@ -19,11 +19,16 @@
#include "mod_gnutls.h"
#include "gnutls_ocsp.h"
+#include "gnutls_util.h"
#ifdef APLOG_USE_MODULE
APLOG_USE_MODULE(gnutls);
#endif
+int ssl_engine_set(conn_rec *c,
+ ap_conf_vector_t *dir_conf __attribute__((unused)),
+ int proxy, int enable);
+
static void gnutls_hooks(apr_pool_t * p __attribute__((unused)))
{
/* Try Run Post-Config Hook After mod_proxy */
@@ -64,6 +69,7 @@
/* mod_proxy calls these functions */
APR_REGISTER_OPTIONAL_FN(ssl_proxy_enable);
APR_REGISTER_OPTIONAL_FN(ssl_engine_disable);
+APR_REGISTER_OPTIONAL_FN(ssl_engine_set);
/* mod_rewrite calls this function to detect HTTPS */
APR_REGISTER_OPTIONAL_FN(ssl_is_https);
@@ -95,59 +101,55 @@
return 1;
}
-
-
-int ssl_engine_disable(conn_rec *c)
+/**
+ * In Apache versions from 2.4.33 mod_proxy uses this function to set
+ * up its client connections. Note that mod_gnutls does not (yet)
+ * implement per directory configuration for such connections.
+ *
+ * @param c the connection
+ * @param dir_conf per directory configuration, unused for now
+ * @param proxy Is this a proxy connection?
+ * @param enable Should TLS be enabled on this connection?
+ *
+ * @param `true` (1) if successful, `false` (0) otherwise
+ */
+int ssl_engine_set(conn_rec *c,
+ ap_conf_vector_t *dir_conf
Bug#894874: Bumping severity
severity 894874 grave thanks Since this bug seems to affect all builds. -- Sunil signature.asc Description: OpenPGP digital signature
Bug#865938: #865938 python-django-bootstrap-form FTBFS with Django 1.11
Looks like today is the final day to upload the package with fixes. Or else, FreedomBox packages will be auto-removed. -- Sunil
Bug#834281: Bug#835770: Failure is triggered by fix to #834281
On 09/15/2016 12:46 AM, Daniel Kahn Gillmor wrote: [...] > The fix for this problem, is to drop the workaround and correctly fix > #834281, which i've done by sending patches to upstream's test suite at > https://rt.cpan.org/Ticket/Display.html?id=102651 , and i aim to upload > to debian shortly. Thanks for the proper fix. -- Sunil signature.asc Description: OpenPGP digital signature
Bug#835770: Failure is triggered by fix to #834281
Hello, Recently test cases where failing in libgnupg-interface-perl (https://bugs.debian.org/834281) due to gpg binary now defaulting to gpg2 in Debian. It was patched to explicitly use 'gpg1' binary instead of 'gpg'. This is causing the test suite and monkeysphere to use different gpg binaries leading to test case failure. One solution could be to patch the test suite in Debian to use gpg1 instead of gpg until monkeysphere and libgnupg-interface-perl support gpg2. -- Sunil signature.asc Description: OpenPGP digital signature
Bug#837282: pagekite: FTBFS: AttributeError: 'module' object has no attribute 'Handler'
Hello, I have committed a fix for this issue and submitted the patch to upstream also. Upload should happen soon. -- Sunil signature.asc Description: OpenPGP digital signature
Bug#811725: Patch to fix compilation with GCC 6
Hello,
Here is a patch to fix the problem. The fix required is for a single
type conversion issue. I have also written a test program to check that
the patch does not introduce any functionality problem by fixing a
nicely working bug. Both the patch and test program are attached. I
have tried to submit the patch to upstream but the site and repository
seem to be down.
Please try to upload a release with the patch so that repro goes back
into testing. FreedomBox dearly misses it :)
Thank you,
--
Sunil
Description: Fix FTBFS with GCC 6
Fix a minor, possibly unintentional, type casting error to fix a
compilation error with GCC 6. The data being initialized is unsigned
char where as the array is char. The array is being later type
casted to (unsigned char *). So, it is appropriate for the array to
be unsigned char[].
.
Currently the upstream repository and site are unreachable.
Author: Sunil Mohan Adapa <su...@medhas.org>
Bug-Debian: https://bugs.debian.org/811725
Forwarded: <no|not-needed|url proving that it has been forwarded>
Last-Update: 2016-08-30
--- sipxtapi-3.3.0~test17.orig/sipXportLib/src/os/OsEncryption.cpp
+++ sipxtapi-3.3.0~test17/sipXportLib/src/os/OsEncryption.cpp
@@ -55,7 +55,7 @@
// EXTERNAL VARIABLES
// CONSTANTS
-static const char gSalt[] =
+static const unsigned char gSalt[] =
{
(unsigned char)0xc9, (unsigned char)0x36, (unsigned char)0x78, (unsigned char)0x99,
(unsigned char)0x52, (unsigned char)0x3e, (unsigned char)0xea, (unsigned char)0xf2
#include
static const char gSalt1[] =
{
(unsigned char)0xc9, (unsigned char)0x36, (unsigned char)0x78, (unsigned char)0x99,
(unsigned char)0x52, (unsigned char)0x3e, (unsigned char)0xea, (unsigned char)0xf2
};
static const unsigned char gSalt2[] =
{
(unsigned char)0xc9, (unsigned char)0x36, (unsigned char)0x78, (unsigned char)0x99,
(unsigned char)0x52, (unsigned char)0x3e, (unsigned char)0xea, (unsigned char)0xf2
};
int main() {
unsigned char * mSalt1 = (unsigned char *)gSalt1;
unsigned char * mSalt2 = (unsigned char *)gSalt1;
for (int i = 0; i < 8; i++) {
if (mSalt1[i] != mSalt2[i]) {
std::cout << 'Error';
return 1;
}
}
return 0;
}
signature.asc
Description: OpenPGP digital signature
Bug#742429: Patch to install packages using PackageKit
Hello,
Here is an experimental patch to perform package installation using
PackageKit. I have tested it for success and error conditions but there
are corner cases such as inserting devices during package installation
and parallel package installation that I haven't tested. I expect them
to work fine by the way.
One thing to consider about PackageKit is that it does not show progress
dialogs like aptdaemon. But I have left some code in there to collect
progress information that can be used to show progress dialogs if necessary.
--
Sunil
From 7ee652f3fc6b09e1fdf9cba706d562128de2c247 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa <su...@medhas.org>
Date: Wed, 25 May 2016 11:29:58 +0530
Subject: [PATCH] Implement package installation using PackageKit
- Based on code from FreedomBox UI - Plinth. I am the original author
of the code and I here by license it under the same license as
isenkram package: GNU GPL v2 or later.
- When trying to install packages, a dialog is shown to the user asking
for administrator password to allow for package installation.
- PackageKit does not provide package installation progress bars like
aptdaemon. So, use libnotify to show a message at the start and end
of installation.
---
isenkramd | 181 +-
1 file changed, 179 insertions(+), 2 deletions(-)
diff --git a/isenkramd b/isenkramd
index 7eee84d..ac5028d 100755
--- a/isenkramd
+++ b/isenkramd
@@ -40,6 +40,8 @@ gi.require_version('GUdev', '1.0')
from gi.repository import GUdev
gi.require_version('Notify', '0.7')
from gi.repository import Notify
+gi.require_version('PackageKitGlib', '1.0')
+from gi.repository import PackageKitGlib as packagekit
import isenkram.lookup
@@ -49,6 +51,10 @@ from aptdaemon.gtk3widgets import AptErrorDialog, \
AptProgressDialog
import aptdaemon.errors
+
+use_apt_daemon = False
+
+
class AptDaemonGUIClient(object):
"""Provides a graphical interface to aptdaemon."""
@@ -102,6 +108,173 @@ class AptDaemonGUIClient(object):
self.loop.run()
+class PackageException(Exception):
+"""A package operation has failed."""
+
+def __init__(self, error_string=None, error_details=None, *args, **kwargs):
+"""Store packagekit error string and details."""
+super(PackageException, self).__init__(*args, **kwargs)
+
+self.error_string = error_string
+self.error_details = error_details
+
+def __str__(self):
+"""Return the strin representation of the exception."""
+return 'PackageException(error_string="{0}", error_details="{1}")' \
+.format(self.error_string, self.error_details)
+
+
+class PackageKitInstaller(object):
+"""Helper to install packages using PackageKit."""
+
+def __init__(self, package_names):
+"""Initialize transaction object.
+
+Set most values to None until they are sent as progress update.
+"""
+self.package_names = package_names
+
+# Progress
+self.allow_cancel = None
+self.percentage = None
+self.status = None
+self.status_string = None
+self.flags = None
+self.package = None
+self.package_id = None
+self.item_progress = None
+self.role = None
+self.caller_active = None
+self.download_size_remaining = None
+self.speed = None
+
+def get_id(self):
+"""Return a identifier to use as a key in a map of transactions."""
+return frozenset(self.package_names)
+
+def __str__(self):
+"""Return the string representation of the object"""
+return ('Transaction(packages={0}, allow_cancel={1}, status={2}, '
+' percentage={3}, package={4}, item_progress={5})').format(
+self.package_names, self.allow_cancel, self.status_string,
+self.percentage, self.package, self.item_progress)
+
+def notify_and_install(self):
+"""Notify, start installation and then notify success/error."""
+start_notification = Notify.Notification(
+summary='Installing packages',
+body='Instaling packages - {packages}'.format(
+packages=', '.join(self.package_names)))
+start_notification.set_timeout(1)
+start_notification.show()
+
+error = None
+try:
+self.install()
+except PackageException as exception:
+error = exception
+
+start_notification.close()
+if not error:
+final_notification = Notify.Notification(
+summary='Installation successf
Bug#824657: libpam-abl: Fatal system lockout with libpam-abl installed
On 05/19/2016 02:07 PM, Alex Mestiashvili wrote: > Thank you for the report! the upload of the fixed version is in progress. > Thank you for a speedy resolution. -- Sunil signature.asc Description: OpenPGP digital signature
Bug#824657: libpam-abl: Fatal system lockout with libpam-abl installed
Package: libpam-abl Version: 0.6.0-4 Severity: critical Justification: breaks the whole system -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 With latest version of libpam-abl, it is not possible to login to the system. Regular users, root and all users over SSH fail to login. Only SSH key based login works (and it not possible to sudo/su after that). It appears the new package is installing the pam_abl.so module in the wrong location (/usr/lib/security/) instead of earlier version's correct location (/lib//security). I suppose the multiarch patch that was removed needs some work. There are quite a few reports from FreedomBox users regarding this. It would be nice to have a quick resolution to this issue. The following are the relevant logs: fbx@freedombox-vm1:~$ su - fbx Password: su: Module is unknown - From /var/log/auth.log May 18 13:36:44 freedombox-vm1 su[17570]: PAM unable to dlopen(pam_abl.so): /lib/security/pam_abl.so: cannot open shared object file: No such file or directory May 18 13:36:44 freedombox-vm1 su[17570]: PAM adding faulty module: pam_abl.so May 18 13:36:50 freedombox-vm1 su[17570]: pam_authenticate: Module is unknown May 18 13:36:50 freedombox-vm1 su[17570]: FAILED su for fbx by fbx May 18 13:36:50 freedombox-vm1 su[17570]: - /dev/pts/2 fbx:fbx May 18 13:39:01 freedombox-vm1 CRON[19526]: PAM unable to dlopen(pam_abl.so): /lib/security/pam_abl.so: cannot open shared object file: No such file or directory May 18 13:39:01 freedombox-vm1 CRON[19526]: PAM adding faulty module: pam_abl.so - -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXPHMMAAoJEDbDYUQMm8lx+goP/2uiCJELfzP75HWJmzlqiWG8 7I4AzKKfTEG2bcqnMRxV+8/mQS8yMRDFRQafg2fImwpTArsAT4ESMcncx0IDtqdO PeaUyMLzh57MgMTsEnFzyrA+tbFYC5CBEC4flSoThbNG0h3D0N3iE109sdQzxiEm lAm7rYHaN3+dFlZCHXi7KZoSQrsp6868WEKxw5euXOawcnELvVMQmsiuSw5AS787 c9eHo9txAH7KJnFPjjoz4OuzqeE6P5mHu4dghx8JnFehIH2bNkrO2kMRmNAuON7T hp5C1B6YJ5ZLecKnqVXxTCg/aL+3yzjzRWWZcwMwgmVF9J9fAxANnw0hmuNx10EK sGSslkCliTTUOTJPegIYk9+6+aajiBXDHx9/e7eRRkG4EkGIGf48Jmxj2MxKpQEF NzspJMBEgqw8d9zRYxG0FFN9H4KgK/PRvvTFF0WmdQZctZKWuJQKsXaON1i8/MdI omuwNREzZweTdYrh/ErcC1Jzt/USiE8H8kfXnwoYQq1ewvKvkJkdYyPEPvrsnXF2 OMiooYRHrN9pG05zZ+fZZ3h7LlGVKCvbDbb+k6IjA1e6G7Bt5f2nJ0NUsHfbhJ+J ncXj8Lw6/laoV8XKal7nNtR2xBApGPfOs9nllPOWg0kOquAfq0y7K6FCtjVNB4rn lJKWaNVhiqmCcR4ny9CI =Sjkl -END PGP SIGNATURE-
Bug#821484: freedombox-setup: PHP 7.0 Transition
Attached is patch I prepared as discussed. This patch to the postinst script will disable php5 and enable php7.0 module. This rule is applied when upgrading from version less than or equal to 0.9. It is not applied when doing a fresh install. I believe that after applying this patch, we need to make a new release 0.9.1 to fix the php migration issue. I have tested as follows: I have taken a fresh 0.7.2 image and upgraded to latest sid. I can see that php7 is not installed. Then after installing the deb package with this patch included, php7 got installed and freedombox has successfully switch the enabled version of php to php7. I have tested shaarli, tt-rss (reported #824029), roundcube (needs update to 1.2beta for php7 support). -- Sunil From 619a2c55e56a65b87e9f006cc7e3385e52d0d3c3 Mon Sep 17 00:00:00 2001 From: Sunil Mohan Adapa <su...@medhas.org> Date: Wed, 11 May 2016 14:14:45 +0530 Subject: [PATCH] When upgrading from < 0.9 enable php7 When upgrading from a version less then 0.9 and if php5 is enabled (not disabled by user for any reason) then disable php5 and enable php7.0 module (php7.0 conflicts with php5). Hack around the problem that apache maintainer scripts don't allow disabling a module during postinst configure phase. --- debian/freedombox-setup.postinst | 19 +++ 1 file changed, 19 insertions(+) diff --git a/debian/freedombox-setup.postinst b/debian/freedombox-setup.postinst index 5351b6e..533824d 100644 --- a/debian/freedombox-setup.postinst +++ b/debian/freedombox-setup.postinst @@ -20,6 +20,25 @@ if dpkg --compare-versions "$2" le "0.0.23" && rmdir /var/freedombox fi +# Enable php7.0 Apache module when upgrading from olders version to +# 0.9.1 or above +if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then +. /usr/share/apache2/apache2-maintscript-helper + +if dpkg --compare-versions "$2" le-nl "0.9" ; then +if apache2_has_module php5 ; then +# XXX: Hack around maintainer script refusing to disable a +# module during configure +method="$APACHE2_MAINTSCRIPT_METHOD" +APACHE2_MAINTSCRIPT_METHOD="remove" +apache2_invoke dismod php5 +APACHE2_MAINTSCRIPT_METHOD="$method" + +apache2_invoke enmod php7.0 +fi +fi +fi + # Setup motd if [ "$1" = "configure" ] && [ -f /etc/motd ] && [ ! -L /etc/motd ] ; then mkdir -p /etc/update-motd.d -- 2.8.1 signature.asc Description: OpenPGP digital signature
Bug#821484: Bumping severity of PHP 7.0 transition bugs to serious
On 05/07/2016 02:05 AM, James Valleroy wrote: > tags 821484 patch > thanks > > The attached patch will simply switch from PHP 5 to PHP 7.0. > The patch looks correct but insufficient. Here are my notes: - ownCloud depends on php5 but is being removed. - tt-rss seems to work okay with php7. Faced some weird issues during installation, probably unrelated. - Shaarli is still dependent on php5 modules but seems to work with php7. - Roundcube seems to have problem with php7 but upstream supports php7 in 1.2beta (unreleased and not yet available in Debian). - Php7 module is not enabled in freedombox-setup for people upgrading from an earlier version. I have applied the patch and marked that it closes the bug. However, we need to address the issue of enabling php7 module for upgrading users. I propose that we add 'a2enmod php7.0' to post-install. What do you think? -- Sunil signature.asc Description: OpenPGP digital signature
Bug#769328: plinth: no web page when started form boot, work when started from command line
Hello,
I have a good picture of the problem and I have revamped Plinth's Apache
configuration to fix various problems. The pull request is waiting for
review.
https://github.com/freedombox/Plinth/pull/25
The attached patch cleans up Plinth's Apache configuration in
freedombox-setup.
This bug will be fixed in Plinth's upstream and freedombox-setup package.
--
Sunil
From 0078a6a24c5e1961d5cd17f9a9956550818ddcb2 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa su...@medhas.org
Date: Mon, 17 Nov 2014 14:30:48 +0530
Subject: [PATCH] Cleanup Plinth's Apache configuration
- Plinth related SSL redirection is no longer required in fbx.conf.
- Plinth no-longer hijacks default SSL site configuration. Enable
default SSL site configuration to compensate.
- Plinth's deault configuration works just fine, don't disable it.
- The change is need for the latest Plinth's Apache configuration
changes at https://github.com/freedombox/Plinth/pull/25
- Newer version of FreedomBox setup should depend on Plinth 0.4.1.
---
debian/changelog | 6 ++
setup.d/90_apache2 | 12 +---
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 4df0d71..40f4f69 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,11 @@
freedombox-setup (0.3) UNRELEASED; urgency=low
+ [ Sunil Mohan Adapa ]
+ * Cleanup Plinth's Apache configuration. Default SSL site is no
+longer hijacked. Plinth supplied configuration is good enough
+don't interfere.
+
+ [ Petter Reinholdtsen ]
* Adjust debian/tests/test-chroot to build using unstable instead of
testing. We are focusing on unstable for now.
diff --git a/setup.d/90_apache2 b/setup.d/90_apache2
index 3ff6405..10b32f9 100755
--- a/setup.d/90_apache2
+++ b/setup.d/90_apache2
@@ -13,11 +13,6 @@ a2enmod ssl
# disable default site
a2dissite 000-default
-# disable plinth, if plinth-ssl is enabled
-if [ -e /etc/apache2/sites-enabled/plinth-ssl.conf ] ; then
-a2dissite plinth
-fi
-
# setup freedombox site
cat /etc/apache2/sites-available/fbx.conf 'EOF'
VirtualHost *:80
@@ -36,15 +31,10 @@ cat /etc/apache2/sites-available/fbx.conf 'EOF'
Proxy *
Allow from all
/Proxy
-
- ## Send plinth to HTTPS port handled by plinth.conf.
- RewriteEngine on
- ReWriteCond %{REQUEST_URI} ^/plinth
- ReWriteCond %{SERVER_PORT} !^443$
- RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]
/VirtualHost
EOF
a2ensite fbx
+a2ensite default-ssl
echo Done configuring Apache.
--
2.1.1
signature.asc
Description: OpenPGP digital signature
Bug#769328: plinth: no web page when started form boot, work when started from command line
On Thursday 13 November 2014 02:42 AM, Petter Reinholdtsen wrote: Here is some more information collected after booting systemd: root@freedombox:~# systemctl status plinth * plinth.service - LSB: plinth web frontend Thank you for the bug report and the information. The init script seems to be fine and Plinth is running properly. This was the case that I checked in my setup. I should be focusing on accessing it via Apache. If it works from command line then we can only suspect that the --debug option allowed things to work. One thing with --debug option is that ALLOWED_HOSTS option in Django will be disabled. This permits anyone (Apache) trying to access it on addresses other then 127.0.0.1 or localhost. But all this should be reproducible on my setup. So, let me check. -- Sunil signature.asc Description: OpenPGP digital signature
Bug#718624: Possible problem with the patch
Hello, I was interested in the fix that the patch aims to provide. A casual glance revealed a potential problem. +if dpkg --compare-versions $2 lt 2.84-0.2~; then +mkdir -p /var/lib/transmission-daemon/.config/transmission-daemon +chown -R debian-transmission:debian-transmission /var/lib/transmission-daemon/* /var/lib/transmission-daemon/* would not include .config folder. .config folder will end up being owned by 'root' user. After upgrade, the daemon would not be able to write to the settings.json file before exit. So settings modified using RPC or web interface will not be saved on exit. I have not tested this though. Thanks for Transmission, Transmission packaging and the patch. -- Sunil signature.asc Description: OpenPGP digital signature
Bug#745539: freedombox-setup: Incomplete build dependencies
Package: freedombox-setup Severity: serious Justification: fails to build from source (but built successfully in the past) Dear Maintainer, I tried to build the package with debuild and faced the following error. dh_auto_build make[1]: Entering directory `/home/turtle/work/freedombox/freedombox-setup' make -C doc all make[2]: Entering directory `/home/turtle/work/freedombox/freedombox-setup/doc' xmllint --nonet --noout --xinclude --postvalid manual-jessie.xml xmlto --with-dblatex pdf manual-jessie.xml Warning: dblatex not found or not executable. Using default backend... Making portrait pages on a4 paper (210mmx297mm) PassiveTeX is needed for this format, but it is not installed. Please install the passivetex package. make[2]: *** [manual-jessie.pdf] Error 1 make[2]: Leaving directory `/home/turtle/work/freedombox/freedombox-setup/doc' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/turtle/work/freedombox/freedombox-setup' dh_auto_build: make -j1 returned exit code 2 make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1364: dpkg-buildpackage -rfakeroot -D -us -uc failed I suspect xmltex etc. are missing from build dependency list. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages freedombox-setup depends on: ii apache22.4.9-1 ii augeas-tools 1.0.0-1.1 ii avahi-daemon 0.6.31-4 pn avahi-utilsnone ii bridge-utils 1.5-7 pn checkinstall none pn devio none pn dialog none pn dnsmasqnone ii dnsutils 1:9.9.5.dfsg-3 ii dosfstools 3.0.26-2 pn etckeeper none ii firewalld 0.3.9.3-1 pn havegednone ii hostname 3.15 ii htop 1.0.2-3 pn iftop none ii iptables 1.4.21-1 ii iputils-ping 3:20121221-5 ii isc-dhcp-client4.2.4-7 pn libnss-gw-name none ii libnss-mdns0.10-6 pn libnss-myhostname none ii libpython2.7-stdlib [python-argparse] 2.7.6-8 ii locales2.18-4 pn locales-allnone ii lsof 4.86+dfsg-1 pn lua-secnone pn macchanger none pn monkeysphere none ii net-tools 1.60-25 ii ntp1:4.2.6.p5+dfsg-3 ii openssh-server 1:6.6p1-3 ii parted 2.3-20 pn plinth none ii psmisc 22.21-2 ii python-augeas 0.4.1-2 ii python-beautifulsoup 3.2.1-1 ii python-bjsonrpc0.2.0-1 ii python-docutils0.11-3 ii python-lxml3.3.3-1 pn python:any none pn resolvconf none ii ssl-cert 1.0.33 ii sudo 1.8.9p5-1 pn tcpdumpnone pn uaputl none ii vim-tiny 2:7.4.253-1 ii wget 1.15-1 pn zile none Versions of packages freedombox-setup recommends: pn batctl none ii pagekite0.5.6d-3 pn rfkill none pn wireless-tools none freedombox-setup suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745327: python-slip: Missing dependency on python-six
Package: python-slip
Version: 0.6.0-1
Severity: grave
Tags: patch
Justification: renders package unusable
Dear Maintainer,
* What led up to the situation?
I have installed firewalld in FreedomBox and ran the command firewall-cmd
and it resulted in a error the six could not be imported. I believe this could
reproduced on a debootstraped install.
* What exactly did you do (or not do) that was effective (or
ineffective)?
firewall-cmd --state
* What was the outcome of this action?
Traceback (most recent call last):
File /usr/bin/firewall-cmd, line 32, in module
from firewall.client import FirewallClient
File /usr/lib/python2.7/dist-packages/firewall/client.py, line 29, in
module
import slip.dbus
File /usr/lib/python2.7/dist-packages/slip/dbus/__init__.py, line 8, in
module
from . import service
File /usr/lib/python2.7/dist-packages/slip/dbus/service.py, line 30, in
module
from six import with_metaclass
ImportError: No module named six
* What outcome did you expect instead?
I expected the 'firewall-cmd --state' to show the current state of the
firewall daemon.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages python-slip depends on:
ii python 2.7.5-5
python-slip recommends no packages.
python-slip suggests no packages.
-- no debconf information
diff -upr python-slip-0.6.0.old/debian/control python-slip-0.6.0/debian/control
--- python-slip-0.6.0.old/debian/control 2014-03-01 01:44:51.0 +0530
+++ python-slip-0.6.0/debian/control 2014-04-20 19:45:32.411648296 +0530
@@ -15,7 +15,8 @@ Architecture: all
Pre-Depends: ${misc:Pre-Depends}
Depends:
${misc:Depends},
- ${python:Depends}
+ ${python:Depends},
+ python-six
Description: miscellaneous convenience, extension and workaround code for Python
The Simple Library for Python packages contain miscellaneous code for
convenience, extension and workaround purposes.
@@ -28,7 +29,8 @@ Depends:
${python:Depends},
python-slip (= ${source:Version}),
python-dbus,
- python-decorator
+ python-decorator,
+ python-six
Description: convenience functions for dbus services
The Simple Library for Python packages contain miscellaneous code for
convenience, extension and workaround purposes.
