Bug#1075443: rep-gtk uploaded to DELAYED=10
Thank you for your time. You may upload the package to the no delay queue, I will check it when I have free time. On September 10, 2024 11:00:47 AM GMT+01:00, Andreas Tille wrote: >Control: tags -1 pending >Thanks > >Hi Jose, > >your package rep-gtk was showing up in the list of candidates for the >Bug of the Day[1]. I've found the package in Debian team space with >other contributions (Janitor, Helmut Grohne for cross building). Thus I >took the freedom to do some "Team upload" fixing these bugs, fixing the >FTBFS bug and doing some other modernisations that go beyond a simple >NMU. Formally I might probably should have followed the Package Salvage >procedure and file an ITS bug. The fact that there was an RC bug and >the package was in collaborative maintenance space made me believe it is >sensible to simply use DELAYED=10 queue. In case you are not happy >about this just let me know and I'll remove the upload from the >deferred queue. > >Thank you for maintaining rep-gtk > Andreas. > >[1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks > >-- >https://fam-tille.de
Bug#1069152: RM: xorp -- RoQA; FTBFS since 2019, not part of bullseye, bookworm or trixie, popcon 2
I agree. On April 17, 2024 8:00:48 AM GMT+01:00, Helmut Grohne wrote: >Package: ftp.debian.org >Severity: normal >Tags: ftbfs >X-Debbugs-Cc: x...@packages.debian.org, Jose M Calhariz , >Javier Fernandez-Sanguino Pen~a , Mattia Rizzolo > >Control: affects -1 + src:xorp >User: ftp.debian@packages.debian.org >Usertags: remove > >Hi, > >I request removing xorp from unstable for the following reasons: > * FTBFS since 2019 > * No maintainer upload since 2016 > * Not part of bullseye, bookworm or trixie > * Low popcon (2) > * No reverse dependencies > * Requires changes for the /usr-move transition > >Helmut
Bug#1054012: at: defer placement of systemd unit to systemd's pkgconf file
Hi, Can anyone do a NMU? I have no success in finding free time to work on this and I do not want to delay more this fix. Kind regards Jose M Calhariz On 12/8/23 21:22, Chris Hofstaedtler wrote: Hi at Maintainers, Hi Jose, Ansgar, On Sun, Oct 15, 2023 at 11:15:44AM +0200, Helmut Grohne wrote: We want to move files from aliased directories to /usr (see DEP17). The at package is involved, because it ships a systemd unit in /lib. I propose that instead of hard coding this directory, you may defer the placement to systemd's pkgconf file. The advantage of doing so is that a backport of apt to an older release will automatically revert back to /lib and thus honour the file move moratorium that still applies to bookworm. I'm attaching a patch for your convenience. Is there anything we can do to help you out and get Helmut's patch applied? Thanks for considering, Chris
Bug#1055253: amanda: diff for NMU version 1:3.5.1-11.1
Thank you for your work. No need for the delay. Kind regards. Jose M Calhariz On December 3, 2023 1:14:09 PM GMT+00:00, Tobias Frost wrote: >Control: tags 1055253 + patch >Control: tags 1055253 + pending > >Dear maintainer, > >I've prepared an NMU for amanda (versioned as 1:3.5.1-11.1) and >uploaded it to DELAYED/5. Please feel free to tell me if I >should delay it longer. > >Regards. >
Bug#1040416: linux-image-6.1.0-9-amd64: Under heavy load Debian V12 and V11 causes data corruption on XFS filesystems.
Hi On Tue, Nov 07, 2023 at 08:33:58PM +0100, Diederik de Haas wrote: > Control: found -1 6.1~rc3-1~exp1 > Control: found -1 6.1.55-1 > > On Saturday, 4 November 2023 20:35:43 CET Jose M Calhariz wrote: > > > Ok. Please test (when you have time) 6.1.55-1. > > > > Fail : Linux afs31 6.1.0-0-amd64 #1 SMP PREEMPT_DYNAMIC Debian > > 6.1~rc3-1~exp1 (2022-11-02) x86_64 GNU/Linux > > > > Fail : Linux afs31 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 > > (2023-09-29) x86_64 GNU/Linux > > > > Done. I tested even the first 6.1 on Debian. Both of them failed. > > Thanks, updated metadata accordingly. > So now we know it's indeed present in the whole 6.1 series. > > > > Unfortunately there isn't a 6.2 kernel uploaded to the Debian archive and > > > thus not available on snapshot.d.o, but testing 6.3.1-1~exp1 should be > > > useful. > > Please test with with 6.3.1-1~exp1 to make sure it was fixed then (too). > > Unfortunately, the commit list between 6.1 and 6.3.1 is quite large: > me@pc:~/dev/kernel.org/linux$ git log --oneline v6.1..v6.3.1 -- fs/xfs | wc -l > 159 > > If that list was small, I could've suggested to try 'backporting' a couple of > patches, but that avenue seems rather pointless in this case. > > It's probably also useful to verify whether it's also present in the whole > 5.10 series, which should give (even) more data points. > > I think the next step should be to 'forward' this bug report to the upstream > mailing list at linux-...@vger.kernel.org I do not follow closely linux-xfs mailing list, but I think other people already reported problems with 6.1 and are trying to do the effort of delimiting the patch and test a backport to 6.1. Kind regards Jose M Calhariz -- -- Egoista, s. m. Um sujeito mais interessado em si próprio que em mim. -- Ambrose Bierce signature.asc Description: PGP signature
Bug#1040416: linux-image-6.1.0-9-amd64: Under heavy load Debian V12 and V11 causes data corruption on XFS filesystems.
Hi On Thu, Nov 02, 2023 at 07:40:38PM +0100, Diederik de Haas wrote: > > On Thursday, 2 November 2023 18:03:25 CET Jose M Calhariz wrote: > > On Thu, Nov 02, 2023 at 03:37:39PM +0100, Diederik de Haas wrote: > > > On Wednesday, 5 July 2023 19:07:15 CET Jose M Calhariz wrote: > > > > Package: src:linux > > > > Version: 6.1.27-1 > > > > > > Can you try with the latest version in the 6.1.x series to see if the > > > problem is still there? > > > > As I need to setup ASAP the servers in production I do not know if I > > have time in the next days. It works with backports kernels. > > No problem. > > > The latest kernels I tested were: > > Fail : Linux afs31 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.37-1 > > (2023-07-03) x86_64 GNU/Linux > > Ok. Please test (when you have time) 6.1.55-1. Fail : Linux afs31 6.1.0-0-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1~rc3-1~exp1 (2022-11-02) x86_64 GNU/Linux Fail : Linux afs31 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64 GNU/Linux Done. I tested even the first 6.1 on Debian. Both of them failed. > Also verify if it's also present in 6.1~rc3-1~exp1 to make sure it's present > in the whole 6.1 series. > Use https://snapshot.debian.org/binary/linux-image-amd64/ to get it/them. > > If the bug is NOT present in either the latest or the first, then try other > versions till you find the last one that work and the first one that fails. > > > OK : Linux afs31 6.4.0-0.deb12.2-amd64 #1 SMP PREEMPT_DYNAMIC Debian > > 6.4.4-3~bpo12+1 (2023-08-08) x86_64 GNU/Linux > > It was fixed in 6.3.7-1, so it was expected that a later versions also works. > But let's ignore bpo as it likely won't provide useful data points. > > Unfortunately there isn't a 6.2 kernel uploaded to the Debian archive and > thus > not available on snapshot.d.o, but testing 6.3.1-1~exp1 should be useful. > > > The bug is present on Debian v11 too. So is an old bug with fixes on > > kernel 6.2 rc something. > > I'd recommend to focus first on the 6.1 series for now. > If at a later point testing with 5.10 may be useful, we can do that then. Kind regards Jose M Calhariz -- -- A vida feliz, meu Deus, consiste em nos alegrarmos em vos, de vos e por vos signature.asc Description: PGP signature
Bug#1040416: linux-image-6.1.0-9-amd64: Under heavy load Debian V12 and V11 causes data corruption on XFS filesystems.
On Thu, Nov 02, 2023 at 03:37:39PM +0100, Diederik de Haas wrote: > Control: tag -1 moreinfo > > On Wednesday, 5 July 2023 19:07:15 CET Jose M Calhariz wrote: > > Package: src:linux > > Version: 6.1.27-1 > > Can you try with the latest version in the 6.1.x series to see if the problem > is still there? As I need to setup ASAP the servers in production I do not know if I have time in the next days. It works with backports kernels. The latest kernels I tested were: Fail : Linux afs31 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.37-1 (2023-07-03) x86_64 GNU/Linux OK : Linux afs31 6.4.0-0.deb12.2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.4-3~bpo12+1 (2023-08-08) x86_64 GNU/Linux > > > On this hardware I am chasing a data corruption for several months on > > Debian V11 and Debian v12. Now that I was pointed that linux kernel > > had some problems with XFS solved in later 6.3 kernel I can reproduce > > the problem. > > > > It seams the problem went away with current Debian testing kernel: > > > > ii linux-image-6.3.0-1-amd646.3.7-1 amd64Linux 6.3 > > for 64-bit PCs (signed) > > > > Is there anyone willing to backport the XFS fixes into > > linux-image-6.1.0 and linux-image-5.10.0? > > If the problem is still present in the latest 6.1 kernel, then you need to > find > out which patch(es) actually fix the problem. > The easiest way to start with that is to find the last kernel which exhibits > the issue and then the first one where it is fixed. > https://snapshot.debian.org/binary/linux-image-amd64/ should help > with that. The bug is present on Debian v11 too. So is an old bug with fixes on kernel 6.2 rc something. > > When the range has been narrowed, a `git bisect` should identify the specific > commit(s) which fixes the issue. > https://wiki.debian.org/DebianKernel/GitBisect should help with that > > When that/those have been identified, it should be reported to the upstream > kernel so that they can incorporate those fixes in their LTS kernel(s) which > Debian then will pick up automatically. > > HTH -- -- A vida feliz, meu Deus, consiste em nos alegrarmos em vos, de vos e por vos signature.asc Description: PGP signature
Bug#1032391: Under heavy load Debian V12 and V11 causes data corruption on XFS filesystems.
Hi, After some research it was found the problem was not HW related, but related with XFS driver and is present until linux 6.1. So I opened new bug report on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040416 Kind regards Jose M Calhariz -- -- A vida feliz, meu Deus, consiste em nos alegrarmos em vos, de vos e por vos signature.asc Description: PGP signature
Bug#1034348: at: autopkgtest regression on arm64
Hi, I believe my last update fixed the problem can someone double check?
Kind regards
Jose M Calhariz
On July 7, 2023 11:26:22 AM GMT+01:00, Jose M Calhariz
wrote:
>I too think it's a race condition. I made some changes to the test but the
>upload to Debian did not went well.
>
>
>On July 6, 2023 2:12:59 PM GMT+01:00, Vincent Lefevre
>wrote:
>>On 2023-07-05 18:58:13 +0200, Johannes Christ wrote:
>>> Is there another way to reproduce this issue?
>>
>>I'm wondering whether there is a race condition in the test:
>>
>># use at command to schedule a job.
>>echo "echo `date` > ${WORKDIR}/${TMPFILE}" | at now + 1 minute
>>
>>So the file is expected to be created 1 minute later.
>>
>>Then in the script:
>>
>>sleep 2
>>
>>[...]
>>
>>sleep 58
>>
>>if grep -Fq "UTC" $WORKDIR/$TMPFILE
>>
>>[...]
>>
>>So the script waits for 1 minute (and some other fast commands)
>>before checking the existence of the file, which is the wait time
>>given to "at".
>>
>>I can see 2 possible issues:
>>
>>1. The system is a bit slow, and the job execution will take a bit
>>more time.
>>
>>2. Time inaccuracies. What are the guaranties given by the system?
>>
>>--
>>Vincent Lefèvre - Web: <https://www.vinc17.net/>
>>100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
>>Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Bug#1034348: at: autopkgtest regression on arm64
I too think it's a race condition. I made some changes to the test but the
upload to Debian did not went well.
On July 6, 2023 2:12:59 PM GMT+01:00, Vincent Lefevre
wrote:
>On 2023-07-05 18:58:13 +0200, Johannes Christ wrote:
>> Is there another way to reproduce this issue?
>
>I'm wondering whether there is a race condition in the test:
>
># use at command to schedule a job.
>echo "echo `date` > ${WORKDIR}/${TMPFILE}" | at now + 1 minute
>
>So the file is expected to be created 1 minute later.
>
>Then in the script:
>
>sleep 2
>
>[...]
>
>sleep 58
>
>if grep -Fq "UTC" $WORKDIR/$TMPFILE
>
>[...]
>
>So the script waits for 1 minute (and some other fast commands)
>before checking the existence of the file, which is the wait time
>given to "at".
>
>I can see 2 possible issues:
>
>1. The system is a bit slow, and the job execution will take a bit
>more time.
>
>2. Time inaccuracies. What are the guaranties given by the system?
>
>--
>Vincent Lefèvre - Web:
Bug#1033292: Subject:Re: Bug#1033292: unblock: amanda/1:3.5.1-11
Hi,
I have updated the git repository on salsa abount amanda and created a
signed tag. g...@salsa.debian.org:debian/amanda.git
As the debdiff amanda_3.5.1-10_source.changes
amanda_3.5.1-11_source.changes did not work as I expected I am
doing a git diff:
diff --git a/debian/changelog b/debian/changelog
index d4e1821..498f6f9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+amanda (1:3.5.1-11) unstable; urgency=medium
+
+ * d/p/49-fix-CVE-2022-37705_part_2: 48-fix-CVE-2022-37705 broken one use
+case at least, this patch fix it, fixing the following two bugs.
+ * Bug fix: "backups fail with the following summary "FAILED [no
+backup size line]"", thanks to Norman Lyon (Closes: #1032330).
+ * Bug fix: "Amanda is unusable", thanks to Kamil Jonca (Closes:
+#1032884).
+
+ -- Jose M Calhariz Tue, 21 Mar 2023 17:35:47 +
+
amanda (1:3.5.1-10) unstable; urgency=medium
* d/p/48-fix-CVE-2022-37705: Fix CVE-2022-37705.
diff --git a/debian/patches/49-fix-CVE-2022-37705_part_2
b/debian/patches/49-fix-CVE-2022-37705_part_2
new file mode 100644
index 000..74341a6
--- /dev/null
+++ b/debian/patches/49-fix-CVE-2022-37705_part_2
@@ -0,0 +1,24 @@
+Description: Fix the fix for CVE-2022-37705
+Author: pcahyna https://github.com/pcahyna
+
+Index: amanda.git/client-src/runtar.c
+===
+--- amanda.git.orig/client-src/runtar.c2023-03-05 00:10:46.916884175
+
amanda.git/client-src/runtar.c 2023-03-05 00:15:52.189417756 +
+@@ -191,9 +191,13 @@ main(
+ g_str_has_prefix(argv[i],"--newer") ||
+ g_str_has_prefix(argv[i],"--exclude-from") ||
+ g_str_has_prefix(argv[i],"--files-from")) {
+- good_option++;
+- } else if (argv[i][0] != '-') {
+- /* argument values are accounted for here */
++ if (strchr(argv[i], '=')) {
++ good_option++;
++ } else {
++ /* Accept theses options with the following argument */
++ good_option += 2;
++ }
++} else if (argv[i][0] != '-') {
+ good_option++;
+ }
+ }
diff --git a/debian/patches/series b/debian/patches/series
index 92dde9d..2be2df4 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -45,6 +45,7 @@ reproducible-build
##
# Patches to fix CVEs from 2022
48-fix-CVE-2022-37705
+49-fix-CVE-2022-37705_part_2
50-fix-CVE-2022-37704
52-fix-CVE-2022-37704_part_2
56-fix-CVE-2022-37703
I have attached the two patches for CVE-2022-37705 that I use in the
package, the one with the regression and the fix.
Kind regards
Jose M Calhariz
--
--
Ha alguma coisa nos armarios que deixa os esqueletos
inquietos.
-- John Barrymore
Description: Fix CVE-2022-37705
Author: Prajwal T R https://github.com/prajwaltr93
Index: amanda.git/client-src/runtar.c
===
--- amanda.git.orig/client-src/runtar.c 2021-06-20 21:02:56.627301251 +0100
+++ amanda.git/client-src/runtar.c 2023-02-24 12:40:05.041286442 +
@@ -191,9 +191,9 @@ main(
g_str_has_prefix(argv[i],"--newer") ||
g_str_has_prefix(argv[i],"--exclude-from") ||
g_str_has_prefix(argv[i],"--files-from")) {
- /* Accept theses options with the following argument */
- good_option += 2;
+ good_option++;
} else if (argv[i][0] != '-') {
+ /* argument values are accounted for here */
good_option++;
}
}
Description: Fix the fix for CVE-2022-37705
Author: pcahyna https://github.com/pcahyna
Index: amanda.git/client-src/runtar.c
===
--- amanda.git.orig/client-src/runtar.c 2023-03-05 00:10:46.916884175 +
+++ amanda.git/client-src/runtar.c 2023-03-05 00:15:52.189417756 +
@@ -191,9 +191,13 @@ main(
g_str_has_prefix(argv[i],"--newer") ||
g_str_has_prefix(argv[i],"--exclude-from") ||
g_str_has_prefix(argv[i],"--files-from")) {
- good_option++;
- } else if (argv[i][0] != '-') {
- /* argument values are accounted for here */
+ if (strchr(argv[i], '=')) {
+ good_option++;
+ } else {
+ /* Accept theses options with the following argument */
+ good_option += 2;
+ }
+} else if (argv[i][0] != '-') {
good_option++;
}
}
signature.asc
Description: PGP signature
Bug#1033292: unblock: amanda/1:3.5.1-11
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ama...@packages.debian.org, jose.calha...@tecnico.ulisboa.pt,
calha...@debian.org, ns-l...@dsi.ist.utl.pt
Control: affects -1 + src:amanda
Please unblock package amanda
[ Reason ]
The previous version on the fix for CVE-CVE-2022-37705 introduced a
regression that is fixed by this version.
[ Impact ]
Breaks the use of tar, for backups in some setups, on the affected
clients, i.e., the use of package amanda-client. The server can not
backup itself, but can backups clients with good amanda client
software,
[ Tests ]
I manually tested the affected version and the fixed version, using a
VM running testing (bookworm) with a amanda compiled for sid. The
test is to do backup of the server. The detail that breaks or not is
two options in a dumptype that specifies what program to use for
backup. When using traditional and old interface for gnutar it
breaks. When using the new interface it is not affected.
I do not have experience in C language to do a proper review of the
patch that is very simple, but broken in 3.5.1-10.
[ Risks ]
The fix in 3.5.1-10 for the three CVEs are a low risks ones because
user backup is a restricted user. Only people with previliges already
can login as user backup and try to run the setgid binaries. For the
people affected by regression 3.5.1-10 can workaround using an older
version on the affected clients. This bugs does not affect other
packages as amanda-client is a leaf package.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
for name in amanda-client amanda-common amanda-server ; do debdiff
"/var/cache/apt/archives/${name}_1%3a3.5.1-10_amd64.deb"
"/root/${name}_3.5.1-11_amd64.deb" ; done
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Depends: amanda-common (= [-1:3.5.1-10),-] {+1:3.5.1-11),+} libxml-simple-perl,
perl:any, libc6 (>= 2.34), libglib2.0-0 (>= 2.31.8), libreadline8 (>= 6.0)
Version: [-1:3.5.1-10-] {+1:3.5.1-11+}
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Suggests: amanda-server (= [-1:3.5.1-10)-] {+1:3.5.1-11)+} | amanda-client (=
[-1:3.5.1-10)-] {+1:3.5.1-11)+}
Version: [-1:3.5.1-10-] {+1:3.5.1-11+}
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Depends: amanda-common (= [-1:3.5.1-10),-] {+1:3.5.1-11),+} bsd-mailx | mailx,
libjson-perl, perl:any, libc6 (>= 2.34), libcurl4 (>= 7.16.2), libglib2.0-0 (>=
2.31.8)
Installed-Size: [-1076-] {+1077+}
Suggests: amanda-client (= [-1:3.5.1-10),-] {+1:3.5.1-11),+} cpio | mt-st,
gnuplot
Version: [-1:3.5.1-10-] {+1:3.5.1-11+}
unblock amanda/1:3.5.1-11
Bug#1032884: Acknowledgement (amanda-client: Amanda is unusable)
On 3/13/23 13:16, Kamil Jońca wrote: "Debian Bug Tracking System" writes: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1032884: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032884. dpkg -l "amanda*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---== un amanda (no description available) ii amanda-client 1:3.5.1-9+b1 amd64Advanced Maryland Automatic Network Disk Archiver (Client) ii amanda-common 1:3.5.1-9+b1 amd64Advanced Maryland Automatic Network Disk Archiver (Libs) ii amanda-server 1:3.5.1-10 amd64Advanced Maryland Automatic Network Disk Archiver (Server) Work properly, so this is kind a regression. KJ Hi What dumptypes do you use in amanda? I am preparing one update to fix a regression and I would like to know your situation is covered by my fix. Kind regards Jose M Calhariz
Bug#1032884: Acknowledgement (amanda-client: Amanda is unusable)
On 3/15/23 18:29, Kamil Jońca wrote:
Jose M Calhariz writes:
On 3/13/23 13:16, Kamil Jońca wrote:
"Debian Bug Tracking System" writes:
Thank you for filing a new Bug report with Debian.
You can follow progress on this Bug here: 1032884:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032884.
dpkg -l "amanda*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==---==
un amanda (no description available)
ii amanda-client 1:3.5.1-9+b1 amd64Advanced Maryland Automatic
Network Disk Archiver (Client)
ii amanda-common 1:3.5.1-9+b1 amd64Advanced Maryland Automatic
Network Disk Archiver (Libs)
ii amanda-server 1:3.5.1-10 amd64Advanced Maryland Automatic
Network Disk Archiver (Server)
Work properly, so this is kind a regression.
KJ
Hi
What dumptypes do you use in amanda?
--8<---cut here---start->8---
define dumptype gnutar-base {
compress client custom
client-custom-compress "/usr/local/lib/amanda/xz9"
encrypt client
client-encrypt "/usr/local/lib/amanda/encgpg"
index yes
program "GNUTAR"
maxpromoteday 30
}
define dumptype gnutar-local {
gnutar-base
auth "local"
}
define dumptype gnutar-bsdtcp {
gnutar-base
auth "bsdtcp"
}
define dumptype gnutar-bsdtcp-nocomp {
gnutar-bsdtcp
compress none
}
define dumptype gnutar-local-nocomp {
gnutar-local
compress none
}
--8<---cut here---end--->8---
"/usr/local/lib/amanda/xz9" = exec /usr/bin/xz "$@"
"/usr/local/lib/amanda/encgpg" = exec gpg -e (in case of dumping)
Thank you, your problem is known and will be fixed on the next upload.
Kind regards
Jose M Calhariz
Bug#1032330: amanda-client: backups fail with the following summary "FAILED [no backup size line]"
Hi,
I was able to reproduce the problem on my setup. While I search for a
fix you may use another
workaround. The option ``program "GNUTAR"`` is broken but ``program
"APPLICATION" application "amgtar"``
works and you have more control still using tar.
Use man amgtar for more information.
Kind regards
Jose M Calhariz
On 3/4/23 06:17, Norman Lyon wrote:
Package: amanda-client
Version: 1:3.5.1-10
Severity: normal
Dear Maintainer,
* What led up to the situation?
upgrade of amanda-{client,common,server} from 1:3.5.1-9+b1 to 1:3.5.1-10
* What exactly did you do (or not do) that was effective (or
ineffective)?
standard backup with normal package: failed.
* What was the outcome of this action?
runtar completes in sane manner, defaulDailySet1g to stdout; sendbackup
completes; backup works
myUser@mySystem:~$ for f in sendbackup.20230303031033.debug
runtar.20230303031033.debug ; do printf
"==\n/var/log/amanda/client/DailySet1/$f\n==\n" ; sudo cat
/var/log/amanda/client/DailySet1/$f ; done
==
/var/log/amanda/client/DailySet1/sendbackup.20230303031033.debug
==
Fri Mar 03 03:10:33.465231875 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: pid 1448741 ruid 34 euid 34 version 3.5.1: start at Fri Mar 3
03:10:33 2023
Fri Mar 03 03:10:33.465266461 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Version 3.5.1
Fri Mar 03 03:10:33.465782977 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: pid 1448741 ruid 34 euid 34 version 3.5.1: rename at Fri Mar 3
03:10:33 2023
Fri Mar 03 03:10:33.465876561 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Parsed request as: program `GNUTAR'
Fri Mar 03 03:10:33.465885463 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: disk `/boot'
Fri Mar 03 03:10:33.465890405 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: device `/boot'
Fri Mar 03 03:10:33.465894886 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: level 1
Fri Mar 03 03:10:33.465899391 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: since NODATE
Fri Mar 03 03:10:33.465903975 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: options `'
Fri Mar 03 03:10:33.465908806 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: datapath `AMANDA'
Fri Mar 03 03:10:33.465963068 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: start: mySystem:/boot lev 1
Fri Mar 03 03:10:33.465978023 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Spawning "/bin/gzip /bin/gzip --best" in pipeline
Fri Mar 03 03:10:33.466337828 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: gnutar: pid 1448743: /bin/gzip
Fri Mar 03 03:10:33.466360045 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: pid 1448743: /bin/gzip --best
Fri Mar 03 03:10:33.48981 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: doing level 1 dump as listed-incremental from
'/var/lib/amanda/gnutar-lists/mySystem_boot_0' to
'/var/lib/amanda/gnutar-lists/mySystem_boot_1.new'
Fri Mar 03 03:10:33.467301177 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Spawning "/usr/lib/amanda/runtar runtar DailySet1 /bin/tar
--create --file - --directory /boot --one-file-system --listed-incremental
/var/lib/amanda/gnutar-lists/mySystem_boot_1.new --sparse
--ignore-failed-read --totals ." in pipeline
Fri Mar 03 03:10:33.467327842 2023: pid 1448746: thd-0x5643d3686c00:
sendbackup: Dupped file descriptor 3 to 11
Fri Mar 03 03:10:33.467621737 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: gnutar: /usr/lib/amanda/runtar: pid 1448747
Fri Mar 03 03:10:33.467655460 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: shm_ring_link /amanda_shm_control-1448740-0
Fri Mar 03 03:10:33.467707662 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: am_sem_open 0x7fc43646e000 1
Fri Mar 03 03:10:33.467726841 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: am_sem_open 0x7fc43646d000 1
Fri Mar 03 03:10:33.467742817 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: am_sem_open 0x7fc43646c000 1
Fri Mar 03 03:10:33.467765242 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: am_sem_open 0x7fc43646b000 1
Fri Mar 03 03:10:33.467773426 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: shm_ring_producer_set_size
Fri Mar 03 03:10:33.467871033 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Started backup
Fri Mar 03 03:10:33.467934476 2023: pid 1448741: thd-0x5643d36930c0:
sendbackup: fd_to_shm_ring
Fri Mar 03 03:10:33.467941382 2023: pid 1448746: thd-0x5643d3686c00:
sendbackup: Started index creator: "/bin/tar -tf - 2>/dev/null | sed -e
's/^\.//'"
Fri Mar 03 03:10:33.483602083 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: 119: strange(?): runtar: error [runtar invalid option: -]
Fri Mar 03 03:10:33.485632813 2023: pid 1448746: thd-0x5643d3686c00:
sendbackup: Index created successfully
Fri Mar
Bug#1029829: Server connections refused after applying update?
Hi Barry, Can you please open a new bug report for this problem? Kind regards Jose M Calhariz On February 23, 2023 9:40:53 PM GMT+00:00, Barry Trent wrote: >I applied this update to my one remaining buster machine and now it is >refusing to connect to my bullseye-based amanda backup server. > >amcheck and the amanda server are both reporting "Connection refused" when >accessing the updated buster machine. > >-- >Barry A. Trent >952-829-5864, x109 >barry.tr...@atcorp.com >
Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705
Hi, just to tell that I am working on CVE-2022-37705, currently checking if the fix work on my workbench. Kind regards Jose M Calhariz On February 15, 2023 11:10:25 PM GMT+00:00, Amanda Trusted wrote: >Hi Jose, > >Here are the relevant bug fixes - >[0] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37704 >https://www.cve.org/CVERecord?id=CVE-2022-37704 >Fix - https://github.com/zmanda/amanda/pull/197 > >[1] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37705 >https://www.cve.org/CVERecord?id=CVE-2022-37705 >Fix - https://github.com/zmanda/amanda/pull/196 > > >[2] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37703 >https://www.cve.org/CVERecord?id=CVE-2022-37703 >Fix - https://github.com/zmanda/amanda/pull/198 > >These 3 fixes are due for release as part of Amanda 3.5.3 within a week. > >Let us know if there are any other action items for us. > >Regards, > >AmandaTrusted > >Confidentiality Notice | The information transmitted by this email is intended >only for the person or entity to which it is addressed. This email may contain >proprietary, business-confidential and/or privileged material. If you are not >the intended recipient of this message, be aware that any use, review, >re-transmission, distribution, reproduction or any action taken in reliance >upon this message is strictly prohibited. If you received this in error, >please contact the sender and delete the material from all computers.
Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705
Hi, This is my first security update, can I ask what is the procedure or where is documented? Kind regards Jose M Calhariz On January 28, 2023 12:59:09 PM GMT+00:00, Salvatore Bonaccorso wrote: >Source: amanda >Version: 1:3.5.1-9 >Severity: grave >Tags: security upstream >Justification: user security hole >X-Debbugs-Cc: car...@debian.org, Debian Security Team > > >Hi, > >The following vulnerabilities were published for amanda. > >CVE-2022-37704[0], CVE-2022-37705[1]. > >If you fix the vulnerabilities please also make sure to include the >CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > >For further information see: > >[0] https://security-tracker.debian.org/tracker/CVE-2022-37704 >https://www.cve.org/CVERecord?id=CVE-2022-37704 >[1] https://security-tracker.debian.org/tracker/CVE-2022-37705 >https://www.cve.org/CVERecord?id=CVE-2022-37705 >[2] https://github.com/zmanda/amanda/issues/192 > >Please adjust the affected versions in the BTS as needed. > >Regards, >Salvatore
Bug#1023755: logcheck-database: New default rsyslog high-precision timestamp breaks most rules
Hi, can someone do a minimal patch proposing a way to solve this issue? So we can discuss the best way to solve it, before doing the big work of solving it. I am going to check why this is out of my radar. Kind regards Jose M Calhariz On December 4, 2022 4:56:51 AM GMT+00:00, Mathias Gibbens wrote: > I also would like to see this bug fixed, as a server I've got running >bookworm is spamming log events due to the default date format having >changed in rsyslog. > > Jose -- I'd be happy to help out by co-maintaining the logcheck >package. The logcheck repo is in the debian group on salsa, so by >convention technically it's open for any DD to contribute to, but I >don't want to just start doing uploads without first seeing if you >would have any objections. > > Stefan and Richard -- Hopefully we'll be able to get this bug >resolved pretty quickly. If you have patches for a suggested change or >(even better) a script to automate changing all the rule files, please >feel free to add it to this bug report, or open a pull request on >salsa. > >Mathias > > PS -- There might be an email loop, so I've specifically CC'ed Jose >on this email. The current Maintainer email address for logcheck is the >"magic" logch...@packages.debian.org address that will forward messages >to the package's maintainer, but because that's the exact same address >it might be looping/dropping messages. I'm not sure if there's logic in >place to also email "real" addresses listed as Uploaders for a package >or not
Bug#981446: Possible adoption of logcheck
Hi, On Thu, Sep 02, 2021 at 09:55:36PM +0200, Hannes von Haugwitz wrote: > Hi Jose, > > On Mon, Aug 30, 2021 at 07:58:21PM +0100, Jose M Calhariz wrote: > > I am a user of logckeck as I use on all my machines that I sysadmin > > and I maintain some packages on Debian like for example at and amanda. > > > > As now I would like to offer my help to package and fix logcheck as a > > learning experience for a possibility in the future to be the > > maintainer of logcheck. > > This is great news! > > The logcheck VCS repo is in the `debian` group on salsa.debina.org[0]; > so (as DD) you can just start to work on the package. > > Please let me know if you have any questions or want some review. Thank you for accepting me. For now my question is: Who is the upstream that you are using? > > Best regards > > Hannes > > [0] https://salsa.debian.org/debian/logcheck/ > Kind regards Jose M Calhariz -- -- A história sugere que o capitalismo é uma condição necessária para a liberdade política. Evidentemente, não é uma condição suficiente --Milton Friedmann signature.asc Description: PGP signature
Bug#981446: Possible adoption of logcheck
Hi, I am a user of logckeck as I use on all my machines that I sysadmin and I maintain some packages on Debian like for example at and amanda. As now I would like to offer my help to package and fix logcheck as a learning experience for a possibility in the future to be the maintainer of logcheck. Kind regards Jose M Calhariz -- -- Você faria papel de trouxa? A Betty Faria. signature.asc Description: PGP signature
Bug#985421: Adding DEP8 tests for at package
Hi, Now I have the repo full updated and I am preparing a new upstream release of at, with many changes and bug fixes. Do you mind to do a MR at salsa? Kind regards Jose M Calhariz On 17/03/2021 20:57, Utkarsh Gupta wrote: > Source: at > Version: 3.1.23-1.1 > Severity: normal > Tags: patch > > Hello, > > Since at is missing DEP8 tests, I'd like to add them. I wanted to > propose an MR on salsa but the git history isn't in sync with what's > uploaded to the archive, so asking here. > > I've prepared the basic testing script to ensure that there's no > regression. I initially submitted this in Ubuntu but want to get it > merged and uploaded here. > > Attaching the debdiff here for your review. Let me know what you think > about this. Can I proceed with the upload? > > > - u
Bug#972435: amanda: Please add support for TI RPC implementation
Hi, thank you for the patch, I am working to validate that everything works. Kind regards Jose M Calhariz On 21/08/2021 19:04, Aurelien Jarno wrote: > control: tag -1 + ftbfs > control: severity -1 serious > > On 2020-10-18 15:19, Aurelien Jarno wrote: >> Source: amanda >> Version: 1:3.5.1-5 >> Severity: normal >> Tags: patch upstream >> >> Dear maintainer, >> >> The glibc SunRPC implementation has been marked obsolete for some time. >> It will get removed from glibc in version 2.32 that has been released a >> few weeks ago. The TI RPC implementation should be used instead, which >> also brings new features (IPv6, Kerberos support, ...). >> >> You will find attached a patch taken from Fedora to add support for the >> TI RPC implementation in case the SunRPC implementation is not >> available. Would it be possible to apply it to the Debian package so >> that amanda continues to build when the glibc SunRPC gets removed. > Now that rpc support has been removed from glibc 2.31-14, amanda fails > to build from source and needs the patch attached to this bug report to > build. I am therefore increasing the severity. > > Regards, > Aurelien >
Bug#992347: open-iscsi on upgrades fail to finish postinst script
On Wed, Aug 18, 2021 at 10:17:36PM +0530, Ritesh Raj Sarraf wrote: > On Wed, 2021-08-18 at 19:35 +0530, Ritesh Raj Sarraf wrote: > > On Wed, 2021-08-18 at 13:32 +0100, Jose M Calhariz wrote: > > > I was expecting to be easy to collect the info in one or 2 files, but > > > I am wrong. I have 3 targets with multipath for 2 of them and I am > > > not certain what is active. I have multipath active, I am certain of > > > that, because of the device I am mouting: > > > /dev/mapper/mpath-X-part1 > > > > > > So I am expecting you need all files inside /etc/iscsi and some > > > run-time info? > > > > I am asking this information just for the sake of this task, to > > ascertain why it failed in the first 30 seconds. > > > > Since this worked for you, later, when you increased the timeout to 120 > > seconds; there's not much to do I suppose. But yes, from this bug > > report's sake, having that information clarified will be good. Giving that I have seen this bug before with my machines, it is only the first time I am reporting and being the first reporter so I am with you, this is some setting in my site or my machine. With more reasearch with help from the local specialist I found a an extra iSCSI setup to a local appliance that I not longer need. So I remove it from /etc/iscsi. Doing again a: dpkg --configure -a Setting up open-iscsi (2.1.3-5) ... open-iscsi postinst: since the check in preinst some iSCSI sessions have failed. -> will wait 30s for automatic recovery Processing triggers for initramfs-tools (0.140) ... update-initramfs: Generating /boot/initrd.img-5.10.0-8-amd64 This time it succeeds. So this probably is a problem on my machine. May I suggest for you to increase the timeout from 30s to 60 or 120s? Mine reasoning is that my machine boots fast enough for me not investigate more my iSCSI connections, but probably the iSCSI appliance is giving authentication timeout and so the increased need for a longer timeout on open-iscsi postinst. Making the package more robust. We may talk more about this problem and I offer my time and machine to do research on to improve the package if you see benefit on that. But I will not keep the bug open if you want to close it. Kind regards Jose M Calhariz -- -- É difícil dizer o que e impossivel, pois a fantasia de ontem e a esperanca de hoje e a realidade de amanha. -- Robert H. Goddard signature.asc Description: PGP signature
Bug#992347: open-iscsi on upgrades fail to finish postinst script
On Wed, Aug 18, 2021 at 12:54:13PM +0100, Jose M Calhariz wrote: > On Wed, Aug 18, 2021 at 01:57:35PM +0530, Ritesh Raj Sarraf wrote: > > On Tue, 2021-08-17 at 19:02 +0100, Jose M Calhariz wrote: > > > > Did you change/tweak any of the default timeout values ? > > > > > > > > > > Most probably, it is not me that usually setup the iSCSI connections. > > > What values do you want me to look into it and where? > > > > All information should be available under `/etc/iscsi`. > > There will be per target database created under that folder. And those > > will have all the finer session and replacement timeouts defined. They > > are usually generated/updated through the `iscsiadm` utility during > > discovery. > > > > PS: That db may also include CHAP secrets, if you set any. > > > > OK, > > I will send to you the iSCSI setup without secrets and we will put in > the bug report the relevant info. > > Kind regards > Jose M Calhariz > > Hi, I was expecting to be easy to collect the info in one or 2 files, but I am wrong. I have 3 targets with multipath for 2 of them and I am not certain what is active. I have multipath active, I am certain of that, because of the device I am mouting: /dev/mapper/mpath-X-part1 So I am expecting you need all files inside /etc/iscsi and some run-time info? Kind regards Jose M Calhariz -- -- É difícil dizer o que e impossivel, pois a fantasia de ontem e a esperanca de hoje e a realidade de amanha. -- Robert H. Goddard signature.asc Description: PGP signature
Bug#992347: open-iscsi on upgrades fail to finish postinst script
On Wed, Aug 18, 2021 at 01:57:35PM +0530, Ritesh Raj Sarraf wrote: > On Tue, 2021-08-17 at 19:02 +0100, Jose M Calhariz wrote: > > > Did you change/tweak any of the default timeout values ? > > > > > > > Most probably, it is not me that usually setup the iSCSI connections. > > What values do you want me to look into it and where? > > All information should be available under `/etc/iscsi`. > There will be per target database created under that folder. And those > will have all the finer session and replacement timeouts defined. They > are usually generated/updated through the `iscsiadm` utility during > discovery. > > PS: That db may also include CHAP secrets, if you set any. > OK, I will send to you the iSCSI setup without secrets and we will put in the bug report the relevant info. Kind regards Jose M Calhariz -- -- É difícil dizer o que e impossivel, pois a fantasia de ontem e a esperanca de hoje e a realidade de amanha. -- Robert H. Goddard signature.asc Description: PGP signature
Bug#992347: open-iscsi on upgrades fail to finish postinst script
On Tue, Aug 17, 2021 at 11:13:36PM +0530, Ritesh Raj Sarraf wrote: > Hello Jose, Hi > > Good to hear from you. I recollect having met you, in person, at > Debconf Heidelberg or Debconf Capetown. I hope you are doing > good. :-) Yes, I am fine and you? I was in both DebConfs but I remember meeting you in Capetown. > > On Tue, 2021-08-17 at 16:27 +0100, Jose M Calhariz wrote: > > During upgrades of open-iscsi on my environment it fails to run > > postinst with success. I got the following messages: > > > > Setting up open-iscsi (2.1.3-5) ... > > open-iscsi postinst: since the check in preinst some iSCSI sessions > > have > > failed. -> will wait 30s for automatic recovery > > open-iscsi postinst: some sessions are still in failed state -> > > iscsid > > will be restarted regardless, since that may > > actually help with the session recovery. > > dpkg: error processing package open-iscsi (--configure): > > installed open-iscsi package post-installation script subprocess > > returned error exit status 1 > > > > > > I have tried to change the postinst to wait for more time, for > > example > > 120s and it worked, after 40 seconds of wait. > > Hmmm. Usually, the sessions should recover within a couple of seconds. > IIRC, the check is every 5 seconds. > > > Did you change/tweak any of the default timeout values ? > Most probably, it is not me that usually setup the iSCSI connections. What values do you want me to look into it and where? Kind regards Jose M Calhariz -- -- É difícil dizer o que e impossivel, pois a fantasia de ontem e a esperanca de hoje e a realidade de amanha. -- Robert H. Goddard signature.asc Description: PGP signature
Bug#992347: open-iscsi on upgrades fail to finish postinst script
Package: open-iscsi Version: 2.1.3-5 Severity: normal During upgrades of open-iscsi on my environment it fails to run postinst with success. I got the following messages: Setting up open-iscsi (2.1.3-5) ... open-iscsi postinst: since the check in preinst some iSCSI sessions have failed. -> will wait 30s for automatic recovery open-iscsi postinst: some sessions are still in failed state -> iscsid will be restarted regardless, since that may actually help with the session recovery. dpkg: error processing package open-iscsi (--configure): installed open-iscsi package post-installation script subprocess returned error exit status 1 I have tried to change the postinst to wait for more time, for example 120s and it worked, after 40 seconds of wait. Kind regards Jose M Calhariz -- System Information: Debian Release: 11.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_IL:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages open-iscsi depends on: ii debconf [debconf-2.0] 1.5.77 ii libc6 2.31-13 ii libisns0 0.100-3 ii libkmod2 28-1 ii libmount1 2.36.1-8 ii libopeniscsiusr2.1.3-5 ii libssl1.1 1.1.1k-1 ii libsystemd0247.3-6 ii udev 247.3-6 open-iscsi recommends no packages. open-iscsi suggests no packages. -- debconf information: open-iscsi/upgrade_recovery_error: open-iscsi/upgrade_even_with_failed_sessions: open-iscsi/downgrade_and_break_system: open-iscsi/remove_even_with_active_sessions:
Bug#990197: unblock: amanda/3.5.1-6
On 22/06/2021 22:15, Michael Biebl wrote: > Am 22.06.21 um 21:49 schrieb Jose M Calhariz: > >>> My first build was with MAILER only on config and tested on a >>> bullseye >>> server. > > This appears to be correct/sufficient > >>> Then I was point into #475771 and that my change was not complete >>> enough >>> so I > > I don't think you need to set it for MAKE. I think it was done so > mistakenly in the past. > > > If it helps, there is packaging/deb/rules which also sets MAILER only > during ./configure. > So you prefer the following patch and that I upload a 3.5.1-7 with only that change, right? I am learning to do my first unblock request. git show d8821280299fe30c64d98635b546c87318ee47a5 commit d8821280299fe30c64d98635b546c87318ee47a5 Author: Jose M Calhariz Date: Sun Jun 20 21:34:41 2021 +0100 Use command mail instead of Mail. diff --git a/debian/rules b/debian/rules index 6f7e9c7..ad6a1a3 100755 --- a/debian/rules +++ b/debian/rules @@ -41,7 +41,8 @@ confflags = --prefix=/usr \ dh $@ --with autoreconf --parallel override_dh_auto_configure: - LIBS="-lssl" dh_auto_configure -- $(confflags) + # MAILER: Fix for #296022, #475771 and #990080 + MAILER="/usr/bin/mail" LIBS="-lssl" dh_auto_configure -- $(confflags) override_dh_install: sed -i "/dependency_libs/ s/'.*'/''/" `find debian/tmp -name '*.la'`
Bug#990197: unblock: amanda/3.5.1-6
On 22/06/2021 18:08, Jose M Calhariz wrote: > On 22/06/2021 17:53, Michael Biebl wrote: >> Am 22.06.21 um 18:39 schrieb Jose M Calhariz: >>> On 22/06/2021 17:13, Michael Biebl wrote: >>>> Am 22.06.21 um 16:55 schrieb Jose M Calhariz: >>>>> +override_dh_auto_build: >>>>> + # MAILER: Fix for #296022, #475771 and #990080 >>>>> + MAILER="/usr/bin/mail" dh_auto_build >>>> Are you sure this bit is necessary? >>>> Once MAILER has been set by ./configure, the generated Makefiles >>>> should have MAILER set up properly. >>>> >>>> Can you grep over the generate Makefiles if MAILER is set correctly? >>>> >>>> Michael >>>> >>> I have included that diff, because of #475771. So in the past it > was >>> necessary. >>> >>> Doing grep in all Makefiles I am seeing this: >>> >>> DEFAULT_MAILER = /usr/bin/mail >>> MAILER = /usr/bin/mail >>> >>> >>> I can upload a new package with your request, but because of #475771 I >>> prefer amanda/3.5.1-6 as is. It is your call. >> Well, if you drop the override_dh_auto_build bit, does the resulting >> deb work or not? I assume you have tested the patch? >> >> > It works wit both diffs Can you follow #990080 and the thread in > there? Do you want me > > to push my git repo with the commits for both tries? > > > My first build was with MAILER only on config and tested on a > bullseye > server. > > Then I was point into #475771 and that my change was not complete enough > so I > > have done another build and I tested with the extended diff under the > same server. > > > Kind regards > > Jose M Calhariz > > >
Bug#990080: amanda-server: On a minimal installation there is no Mail command available to send email
I requested an opinion on debian-devel and found that it is an old problem that the fix was reverted some time in the past. The new fix is the following: diff -Nru amanda-3.5.1/debian/rules amanda-3.5.1/debian/rules --- amanda-3.5.1/debian/rules 2020-08-02 21:57:24.0 +0100 +++ amanda-3.5.1/debian/rules 2021-06-22 13:10:01.0 +0100 @@ -1,6 +1,6 @@ #!/usr/bin/make -f # Copyright 1998-2011 by Bdale Garbee. License GPL v2 -# 2016-2017 by Jose M Calhariz. License GPL v2 +# 2016-2021 by Jose M Calhariz. License GPL v2 export DH_VERBOSE=1 @@ -41,7 +41,12 @@ dh $@ --with autoreconf --parallel override_dh_auto_configure: - LIBS="-lssl" dh_auto_configure -- $(confflags) + # MAILER: Fix for #296022, #475771 and #990080 + MAILER="/usr/bin/mail" LIBS="-lssl" dh_auto_configure -- $(confflags) + +override_dh_auto_build: + # MAILER: Fix for #296022, #475771 and #990080 + MAILER="/usr/bin/mail" dh_auto_build override_dh_install: sed -i "/dependency_libs/ s/'.*'/''/" `find debian/tmp -name '*.la'` I will try to unblock so it can enter bullseye. Links https://lists.debian.org/debian-devel/2021/06/msg00215.html Kind regards Jose M Calhariz -- -- As pessoas mudam através do que alcançam --Wystan Hugh Auden signature.asc Description: PGP signature
Bug#990197: unblock: amanda/3.5.1-6
On 22/06/2021 17:13, Michael Biebl wrote: > Am 22.06.21 um 16:55 schrieb Jose M Calhariz: >> +override_dh_auto_build: >> + # MAILER: Fix for #296022, #475771 and #990080 >> + MAILER="/usr/bin/mail" dh_auto_build > > Are you sure this bit is necessary? > Once MAILER has been set by ./configure, the generated Makefiles > should have MAILER set up properly. > > Can you grep over the generate Makefiles if MAILER is set correctly? > > Michael > I have included that diff, because of #475771. So in the past it was necessary. Doing grep in all Makefiles I am seeing this: DEFAULT_MAILER = /usr/bin/mail MAILER = /usr/bin/mail I can upload a new package with your request, but because of #475771 I prefer amanda/3.5.1-6 as is. It is your call. Kind regards Jose M Calhariz
Bug#990197: unblock: amanda/3.5.1-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package amanda On a recent minimal install of bullseye I found that amanda software were not able to send emails. With amanda most of the information is communicated by email to the sysadmin and backup operators, so I think this is a bug of level important. (include/attach the debdiff against the package in testing) diff -Nru amanda-3.5.1/debian/rules amanda-3.5.1/debian/rules --- amanda-3.5.1/debian/rules 2020-08-02 21:57:24.0 +0100 +++ amanda-3.5.1/debian/rules 2021-06-22 13:10:01.0 +0100 @@ -1,6 +1,6 @@ #!/usr/bin/make -f # Copyright 1998-2011 by Bdale Garbee. License GPL v2 -# 2016-2017 by Jose M Calhariz. License GPL v2 +# 2016-2021 by Jose M Calhariz. License GPL v2 export DH_VERBOSE=1 @@ -41,7 +41,12 @@ dh $@ --with autoreconf --parallel override_dh_auto_configure: - LIBS="-lssl" dh_auto_configure -- $(confflags) + # MAILER: Fix for #296022, #475771 and #990080 + MAILER="/usr/bin/mail" LIBS="-lssl" dh_auto_configure -- $(confflags) + +override_dh_auto_build: + # MAILER: Fix for #296022, #475771 and #990080 + MAILER="/usr/bin/mail" dh_auto_build override_dh_install: sed -i "/dependency_libs/ s/'.*'/''/" `find debian/tmp -name '*.la'` unblock amanda/3.5.1-6 -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#969376: openafs-client: Openafs cache erros on the logs
Package: openafs-client Version: 1.8.8pre1-1 Followup-For: Bug #969376 I have tried to package 1.8.8pre1 and compiled for bullseye. On my first stress test "test_diff" it runs fine until I stopped the stress test with a ^C. This is a special machine only to run stress tests of afs. So no process are being killed and the errors messages this time were for the killed stress test. [Mon Jun 21 21:55:08 2021] afs: failed to write to CacheItems off 12588820 code -4/80 [Mon Jun 21 21:55:08 2021] afs: disk cache read error in CacheItems slot 71488 off 5719060/32500020 code -4/80 pid 3770 (tar) [Mon Jun 21 21:55:08 2021] afs: Error while alloc'ing cache slot for file 203:536870928.1326742.311043289; failing with an i/o error [Mon Jun 21 21:55:08 2021] afs: failed to store file (0/5) So it was as explained. Kind regards Jose M Calhariz -- System Information: Debian Release: 11.0 Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openafs-client depends on: ii debconf [debconf-2.0] 1.5.75 ii init-system-helpers1.60 ii libc6 2.31-12 ii libcrypt1 1:4.4.18-4 ii libhcrypto4-heimdal7.7.0+dfsg-2 ii libkrb5-26-heimdal 7.7.0+dfsg-2 ii libncurses66.2+20201114-2 ii libroken18-heimdal 7.7.0+dfsg-2 ii libtinfo6 6.2+20201114-2 ii lsb-base 11.1.0 Versions of packages openafs-client recommends: ii lsof 4.93.2+dfsg-1.1 ii openafs-modules-dkms 1.8.8pre1-1 Versions of packages openafs-client suggests: pn openafs-doc ii openafs-krb5 1.8.6-5 -- debconf information: * openafs-client/afsdb: true * openafs-client/fakestat: true * openafs-client/thiscell: dev.ist.utl.pt openafs-client/cell-info: * openafs-client/cachesize: 1300 * openafs-client/dynroot: No * openafs-client/crypt: true * openafs-client/run-client: true
Bug#990080: amanda-server: On a minimal installation there is no Mail command available to send email
Package: amanda-server Version: 1:3.5.1-5+b1 Severity: important Amanda uses command Mailt to send emails and because of that depends on bsd-mailx or mailx. Package mailutils provides mailx but do not implements command Mail. Request for an opinion on mailing-list debian-devel? Kind regards Jose M Calhariz -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages amanda-server depends on: ii amanda-common 1:3.5.1-5+b1 ii bsd-mailx [mailx] 8.1.2-0.20180807cvs-2 ii libc6 2.31-12 ii libcurl4 7.74.0-1.2 ii libglib2.0-0 2.66.8-1 ii libjson-perl 4.03000-1 ii mailutils [mailx] 1:3.10-3+b1 ii perl 5.32.1-4 amanda-server recommends no packages. Versions of packages amanda-server suggests: ii amanda-client 1:3.5.1-5+b1 ii cpio 2.13+dfsg-4 pn gnuplot -- no debconf information
Bug#969376: openafs-client: Openafs cache erros on the logs
No problem, here is the reply to the Debian bug and my coworkers. Kind regards Jose M Calhariz On Thu, Jun 17, 2021 at 08:26:57PM -0500, Andrew Deason wrote: > That's a question for Ben. Can you reply to 969...@bugs.debian.org > instead? (or ask him directly via ka...@mit.edu ). I was replying to you > directly, so the reply-to didn't go to the debian bug, sorry. > > Hi > > Thank you for the follow up. The machine were this error is coming > from have a complicated pattern of access to AFS, that I can not > reproduce so I will try 1.8.8pre1 on that machine. Is an experimental > package for Debian near? I can try to package myself, but I would > prefer a package from the maintainer. > > Kind regards > Jose M Calhariz > > > On Thu, Jun 17, 2021 at 05:39:05PM -0500, Andrew Deason wrote: > > Sorry, I may have accidentally not included you in this reply (not sure > > if you got this?). I didn't mean to exclude you, so just in case, here > > it is directly: > > > > > On Tue, Sep 01, 2020 at 03:43:37PM +0100, Jose M Calhariz wrote: > > > > The an example of errors on the logs are: > > > > > > > > afs: disk cache read error in CacheItems slot 350195 off > > > > 28015620/3520 code -4/80 > > > > afs: Error while alloc'ing cache slot for file 204:536874423.964.4794; > > > > failing with an i/o error > > > > Hi, I'm the person that mentioned this briefly during the AFS workshop > > this week. These messages are not in themselves a problem; they are just > > reporting that we got an error code from the Linux kernel when trying to > > read from the disk cache. > > > > On Tue, 1 Sep 2020 16:07:55 -0700 > > Benjamin Kaduk wrote: > > > > > This error message is supposed to indicate that a read from the cache > > > filesystem got EIO, which in turn is supposed to indicate a physical > > > problem with the drive. That said, I'm not going to jump to conclusions > > > and try to blame your drive, as there are several other things that could > > > be coming into play. > > > > The code logged is -4, which is EINTR (EIO would be -5). The most likely > > trigger of this is a process that got a SIGKILL signal (or other fatal > > signal) while we were reading from the disk cache. Traditionally we > > wouldn't get errors in that case, but Linux started returning errors in > > that situation after some version (possibly depending on the local fs in > > use? but I don't recall exactly). > > > > If you think these messages happen when some other bug or problem is > > happening, that's possible, but the messages themselves are not a > > problem. If you want to avoid the situation that causes these messages, > > you can try to avoid SIGKILL'ing the relevant processes, if you know > > what's causing that. The message you've shown doesn't log the pid, but > > there is already a change in 1.8.8pre1 to log the pid and some other > > information in that log message. > > > > If you want the specific patch to add some more info to that log > > message, it's here (gerrit 14437): > > > > https://git.openafs.org/?p=openafs.git;a=patch;h=5d863b4f6e817b1cc2615265c7747e17a2037ae6 > > > > I know of at least one bug that can be triggered by the log message > > you've mentioned, which is fixed by gerrit 14451 here: > > > > https://git.openafs.org/?p=openafs.git;a=patch;h=c55607d732a65f8acb1dfc6bf93aee0f4409cecf > > > > That's also in 1.8.8pre1, so if it's feasible for you to just try > > 1.8.8pre1, that's probably easiest. The messages will still appear with > > 1.8.8pre1, but they may be more informative, and some other related bugs > > may be fixed. If you are seeing some other problematic behavior with > > 1.8.8pre1, I can take a look if you provide some details. > > > > > > -- > -- > > As pessoas mudam através do que alcançam > > --Wystan Hugh Auden -- -- As pessoas mudam através do que alcançam --Wystan Hugh Auden signature.asc Description: PGP signature
Bug#990020: kafs-client: Under a big load the user app hangs instead of a volume busy message from the kernel.
state:D stack:0 pid:2413908 ppid:2413907 flags:0x4000 [Mon Jun 14 21:09:21 2021] Call Trace: [Mon Jun 14 21:09:21 2021] __schedule+0x282/0x870 [Mon Jun 14 21:09:21 2021] schedule+0x46/0xb0 [Mon Jun 14 21:09:21 2021] schedule_timeout+0xff/0x140 [Mon Jun 14 21:09:21 2021] ? add_wait_queue+0x3a/0x70 [Mon Jun 14 21:09:21 2021] rxrpc_send_data+0xbe5/0xe00 [rxrpc] [Mon Jun 14 21:09:21 2021] ? afs_alloc_call+0x120/0x120 [kafs] [Mon Jun 14 21:09:21 2021] ? wake_up_q+0xa0/0xa0 [Mon Jun 14 21:09:21 2021] ? afs_alloc_call+0x120/0x120 [kafs] [Mon Jun 14 21:09:21 2021] rxrpc_kernel_send_data+0xb3/0x100 [rxrpc] [Mon Jun 14 21:09:21 2021] afs_send_pages+0xa4/0x200 [kafs] [Mon Jun 14 21:09:21 2021] ? afs_alloc_call+0x120/0x120 [kafs] [Mon Jun 14 21:09:21 2021] afs_make_call+0x230/0x410 [kafs] [Mon Jun 14 21:09:21 2021] ? afs_alloc_flat_call+0x93/0x100 [kafs] [Mon Jun 14 21:09:21 2021] afs_wait_for_operation+0x76/0x1e0 [kafs] [Mon Jun 14 21:09:21 2021] afs_store_data+0x17b/0x1f0 [kafs] [Mon Jun 14 21:09:21 2021] afs_write_back_from_locked_page+0x38c/0x6c0 [kafs] [Mon Jun 14 21:09:21 2021] ? clear_page_dirty_for_io+0xd7/0x220 [Mon Jun 14 21:09:21 2021] afs_writepages_region+0x8b/0x2a0 [kafs] [Mon Jun 14 21:09:21 2021] afs_writepages+0x10d/0x140 [kafs] [Mon Jun 14 21:09:21 2021] do_writepages+0x34/0xc0 [Mon Jun 14 21:09:21 2021] __filemap_fdatawrite_range+0xc5/0x100 [Mon Jun 14 21:09:21 2021] file_write_and_wait_range+0x61/0xb0 [Mon Jun 14 21:09:21 2021] afs_release+0x68/0x70 [kafs] [Mon Jun 14 21:09:21 2021] __fput+0x95/0x240 [Mon Jun 14 21:09:21 2021] task_work_run+0x65/0xa0 [Mon Jun 14 21:09:21 2021] exit_to_user_mode_prepare+0x111/0x120 [Mon Jun 14 21:09:21 2021] syscall_exit_to_user_mode+0x28/0x140 [Mon Jun 14 21:09:21 2021] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [Mon Jun 14 21:09:21 2021] RIP: 0033:0x7f39c1e1ad77 [Mon Jun 14 21:09:21 2021] RSP: 002b:7ffdc10482a8 EFLAGS: 0202 ORIG_RAX: 0003 [Mon Jun 14 21:09:21 2021] RAX: RBX: 0352a6b0 RCX: 7f39c1e1ad77 [Mon Jun 14 21:09:21 2021] RDX: 7f39c1ee68a0 RSI: 03516640 RDI: 0003 [Mon Jun 14 21:09:21 2021] RBP: R08: R09: 037e9c30 [Mon Jun 14 21:09:21 2021] R10: 037e9c47 R11: 00000202 R12: 7f39c1ee74a0 [Mon Jun 14 21:09:21 2021] R13: 7ffdc104a2bc R14: R15: Kind regards Jose M Calhariz -- System Information: Debian Release: 11.0 Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kafs-client depends on: ii keyutils 1.6.1-2 ii libc62.31-12 ii libkafs-client0 0.5-2 ii libkeyutils1 1.6.1-2 ii libkrb5-31.18.3-5 kafs-client recommends no packages. kafs-client suggests no packages. -- Configuration Files: /etc/kafs/client.conf changed: includedir /etc/kafs/client.d -- no debconf information
Bug#969376: openafs-client: Openafs cache erros on the logs
Hi On Wed, Sep 30, 2020 at 04:18:27PM +0100, Jose M Calhariz wrote: > Hi, > > any progress on this? There is anything I can do to help? Hi, I collected internal debug messages about this using ClientTracing.py Is there anyone to send this debug messages and try to solve the problem. Kind regards Jose M Calhariz > > > Kind regards > Jose M Calhariz > > > > On Fri, Sep 04, 2020 at 06:12:30PM +0100, Jose M Calhariz wrote: > > Hi, > > > > I have made an update to my private backport. It is better but I still > > see the same errors on the logs. This machine is a VM and no other VM > > or host is reporting IO errors of any kind, that I know off. > > > > It was my first time using gerrit, so can you please check if the > > I have downloaded the correct patches? > > > > ee578e9.diff > > 179a418.diff > > > > There is a way to decode this errors and try to understand better what > > is happening and find a fix? > > > > > > [9.760892] openafs: loading out-of-tree module taints kernel. > > [9.760898] openafs: module license > > 'http://www.openafs.org/dl/license10.html' taints kernel. > > [9.762091] openafs: module verification failed: signature and/or > > required key missing - tainting kernel > > [9.778441] Key type afs_pag registered > > [ 8245.094223] afs: disk cache read error in CacheItems slot 211006 off > > 16880500/19660820 code -4/80 > > [ 8245.094254] afs: disk cache read error in CacheItems slot 211006 off > > 16880500/19660820 code -4/80 > > [ 8245.094277] afs: disk cache read error in CacheItems slot 211006 off > > 16880500/19660820 code -4/80 > > [ 8245.094299] afs: disk cache read error in CacheItems slot 211006 off > > 16880500/19660820 code -4/80 > > [10181.679636] afs: disk cache read error in CacheItems slot 156531 off > > 12522500/19660820 code -4/80 > > [10181.679638] afs: Error while alloc'ing cache slot for file > > 204:536874423.516.5309; failing with an i/o error > > [11438.241843] afs_UFSGetVolSlot: error -4 reading volumeinfo > > [11438.242213] afs_UFSGetVolSlot: error -4 reading volumeinfo > > > > > > Kind regards > > Jose M Calhariz > > > > > > > > > > > > > > On Wed, Sep 02, 2020 at 07:28:50PM +0100, Jose M Calhariz wrote: > > > Hi, > > > > > > I will then update my private backport and see if the things improve. > > > I will report here the results of your sugestion. Thank you. > > > > > > Kind regards > > > Jose M Calhariz > > > > > > On Tue, Sep 01, 2020 at 04:07:55PM -0700, Benjamin Kaduk wrote: > > > > On Tue, Sep 01, 2020 at 03:43:37PM +0100, Jose M Calhariz wrote: > > > > > Package: openafs-client > > > > > Version: 1.8.6-1~dsi10+1 > > > > > Severity: normal > > > > > > > > > > I am using a private backport of openafs from testing. On this > > > > > server I > > > > > am getting multiples strange errors about openafs cache. This server > > > > > is different in that it runs apache to serve personal web pages and > > > > > every > > > > > web page runs under a different openafs user. So is normal for this > > > > > server to be simultaneuous running code under 100 or 200 different > > > > > openafs > > > > > users. > > > > > > > > > > The an example of errors on the logs are: > > > > > > > > > > afs: disk cache read error in CacheItems slot 350195 off > > > > > 28015620/3520 code -4/80 > > > > > afs: Error while alloc'ing cache slot for file > > > > > 204:536874423.964.4794; failing with an i/o error > > > > > > > > > > I am not certain this types of errors are to be ignored and there have > > > > > been reports of problems accessing openafs files. I am using this bug > > > > > report to collect more information about this cache errors and the > > > > > possibility of being an indication of important errors with the > > > > > openafs > > > > > cache code. > > > > > > > > This error message is supposed to indicate that a read from the cache > > > > filesystem got EIO, which in turn is supposed to indicate a physical > > > > problem with the drive. That said, I'm not going to jump to conclusions > > > > and try to blame yo
Bug#968104: openafs-client: Upgrade of openfs-client break until reboot
Hi, I think I found the problem for this bug. I made an apt-get upgrade of a machine running kernel 4.19.0-8-amd64 with many pending updates. I found this squence of events: - the script that cleans the old dkms modules is run, - openafs-client is restarted, - the new dkms modules are built. This means that when openafs-client is restart there is no openafs module. After I run "systemctl stop openafs-client ; systemctl start openafs-client", the OpenAFS is OK again. If you need more details to chase down this bug I can provide the full output of the "apt-get upgrade" Kind regards Jose M Calhariz -- -- As palavras enchem o espaço. Eu prefiro encher a carteira --Andy Warhol signature.asc Description: PGP signature
Bug#969376: openafs-client: Openafs cache erros on the logs
Hi, any progress on this? There is anything I can do to help? Kind regards Jose M Calhariz On Fri, Sep 04, 2020 at 06:12:30PM +0100, Jose M Calhariz wrote: > Hi, > > I have made an update to my private backport. It is better but I still > see the same errors on the logs. This machine is a VM and no other VM > or host is reporting IO errors of any kind, that I know off. > > It was my first time using gerrit, so can you please check if the > I have downloaded the correct patches? > > ee578e9.diff > 179a418.diff > > There is a way to decode this errors and try to understand better what > is happening and find a fix? > > > [9.760892] openafs: loading out-of-tree module taints kernel. > [9.760898] openafs: module license > 'http://www.openafs.org/dl/license10.html' taints kernel. > [9.762091] openafs: module verification failed: signature and/or required > key missing - tainting kernel > [9.778441] Key type afs_pag registered > [ 8245.094223] afs: disk cache read error in CacheItems slot 211006 off > 16880500/19660820 code -4/80 > [ 8245.094254] afs: disk cache read error in CacheItems slot 211006 off > 16880500/19660820 code -4/80 > [ 8245.094277] afs: disk cache read error in CacheItems slot 211006 off > 16880500/19660820 code -4/80 > [ 8245.094299] afs: disk cache read error in CacheItems slot 211006 off > 16880500/19660820 code -4/80 > [10181.679636] afs: disk cache read error in CacheItems slot 156531 off > 12522500/19660820 code -4/80 > [10181.679638] afs: Error while alloc'ing cache slot for file > 204:536874423.516.5309; failing with an i/o error > [11438.241843] afs_UFSGetVolSlot: error -4 reading volumeinfo > [11438.242213] afs_UFSGetVolSlot: error -4 reading volumeinfo > > > Kind regards > Jose M Calhariz > > > > > > > On Wed, Sep 02, 2020 at 07:28:50PM +0100, Jose M Calhariz wrote: > > Hi, > > > > I will then update my private backport and see if the things improve. > > I will report here the results of your sugestion. Thank you. > > > > Kind regards > > Jose M Calhariz > > > > On Tue, Sep 01, 2020 at 04:07:55PM -0700, Benjamin Kaduk wrote: > > > On Tue, Sep 01, 2020 at 03:43:37PM +0100, Jose M Calhariz wrote: > > > > Package: openafs-client > > > > Version: 1.8.6-1~dsi10+1 > > > > Severity: normal > > > > > > > > I am using a private backport of openafs from testing. On this server I > > > > am getting multiples strange errors about openafs cache. This server > > > > is different in that it runs apache to serve personal web pages and > > > > every > > > > web page runs under a different openafs user. So is normal for this > > > > server to be simultaneuous running code under 100 or 200 different > > > > openafs > > > > users. > > > > > > > > The an example of errors on the logs are: > > > > > > > > afs: disk cache read error in CacheItems slot 350195 off > > > > 28015620/3520 code -4/80 > > > > afs: Error while alloc'ing cache slot for file 204:536874423.964.4794; > > > > failing with an i/o error > > > > > > > > I am not certain this types of errors are to be ignored and there have > > > > been reports of problems accessing openafs files. I am using this bug > > > > report to collect more information about this cache errors and the > > > > possibility of being an indication of important errors with the openafs > > > > cache code. > > > > > > This error message is supposed to indicate that a read from the cache > > > filesystem got EIO, which in turn is supposed to indicate a physical > > > problem with the drive. That said, I'm not going to jump to conclusions > > > and try to blame your drive, as there are several other things that could > > > be coming into play. > > > > > > While the log message itself is pretty old, there's been a lot of work > > > recently to more accurately report EIO in error conditions (mostly instead > > > of ENOENT, since returning ENOENT can cause that to get cached at the VFS > > > layer and produce strange user-visible behavior). > > > > > > Having a lot of users present makes me suspect that the credentials used > > > by > > > the kernel to read/write the cache file are not being saved/restored > > > properly, and indeed we recently merged to 1.8.x (not in a release yet) > > > https://gerrit.openafs.org/14082 and https://gerrit.openafs.org/14099 > > > which > > > improve such credentials management. > > > > > > My recommendation would be to try pulling in those two patches to your > > > build before proceeding to try to trace the source of the EIO. > > > > > > Thanks for the report! > > > > > > -Ben > > > > > > > > -- -- Nós trabalhamos com o propósito de tornar nossos produtos obsoletos, antes que outros o façam --Bill Gates signature.asc Description: PGP signature
Bug#958611: at: Build-Depends on deprecated dh-systemd which is going away
Hi, You have my blessing for the NMU. If it helps, you may remove from DELAYED/14 and upload it to normal queue. Kind regards Jose M Calhariz On 29/09/2020 20:03, Michael Biebl wrote: > Control: tags -1 + patch pending > > Hi, > > I've uploaded a minimal fix to DELAYED/14. > Debdiff is attached. > > Please holler, if you want me to cancel the NMU. > > Regards, > Michael
Bug#968104: openafs-client: Upgrade of openfs-client break until reboot
Hi, about this bug report I found more clues about the problem. Now I think it happens when updating the OpenAFS client and a kernel with a new ABI. I had a machine running buster with kernel 4.19.0-10-amd64 with a pending update to ABI 11 and a backport of openafs 1.8.6. This time I "apt install openafs-client openafs-modules-dkms" and later "apt upgrade" and everything was fine and working as expected. I have more machines needing update to v10.6 that I will use to chase down the exact circumstances that OpenAFS may stop working during an upgrade. Kind regards Jose M Calhariz On Sun, Aug 30, 2020 at 05:28:15PM -0700, Benjamin Kaduk wrote: > Hi Jose, > > Sorry that I missed this when it first came in. > A couple notes inline, if you still remember much about the original > report... > > On Sat, Aug 08, 2020 at 06:32:07PM +0100, Jose M Calhariz wrote: > > Package: openafs-client > > Version: 1.8.6-1~dsi10+1 > > Severity: normal > > > > Hi, > > > > I have made a "private backport" of openafs software from bullseye to > > buster. So this means is the first time for me that I am upgrading > > openafs client 1.8.x on live systems. Where in the past this worked > > To clarify: are you upgrading from 1.6.x to 1.8.x, or merely updating from > one 1.8.x version to a newer 1.8.x version? > > > without problems for openafs 1.4 and 1.6, now the openafs client stops > > working and I need to do a reboot. > > > > What I am requesting is that if possible to do a live upgrade of the > > software and the client does not stop working even if it is necessary > > to work with the old software until a reboot. > > What you are requesting is what is supposed to happen, so I'm unpleasantly > surprised to hear that it is not happening. > > Once I hear back about the problematic scenario I can try to reproduce in a > local VM. > > Thanks, > > Ben > -- -- Porque critica o que não entende (Sepultura) signature.asc Description: PGP signature
Bug#969376: openafs-client: Openafs cache erros on the logs
Hi, I have made an update to my private backport. It is better but I still see the same errors on the logs. This machine is a VM and no other VM or host is reporting IO errors of any kind, that I know off. It was my first time using gerrit, so can you please check if the I have downloaded the correct patches? ee578e9.diff 179a418.diff There is a way to decode this errors and try to understand better what is happening and find a fix? [9.760892] openafs: loading out-of-tree module taints kernel. [9.760898] openafs: module license 'http://www.openafs.org/dl/license10.html' taints kernel. [9.762091] openafs: module verification failed: signature and/or required key missing - tainting kernel [9.778441] Key type afs_pag registered [ 8245.094223] afs: disk cache read error in CacheItems slot 211006 off 16880500/19660820 code -4/80 [ 8245.094254] afs: disk cache read error in CacheItems slot 211006 off 16880500/19660820 code -4/80 [ 8245.094277] afs: disk cache read error in CacheItems slot 211006 off 16880500/19660820 code -4/80 [ 8245.094299] afs: disk cache read error in CacheItems slot 211006 off 16880500/19660820 code -4/80 [10181.679636] afs: disk cache read error in CacheItems slot 156531 off 12522500/19660820 code -4/80 [10181.679638] afs: Error while alloc'ing cache slot for file 204:536874423.516.5309; failing with an i/o error [11438.241843] afs_UFSGetVolSlot: error -4 reading volumeinfo [11438.242213] afs_UFSGetVolSlot: error -4 reading volumeinfo Kind regards Jose M Calhariz On Wed, Sep 02, 2020 at 07:28:50PM +0100, Jose M Calhariz wrote: > Hi, > > I will then update my private backport and see if the things improve. > I will report here the results of your sugestion. Thank you. > > Kind regards > Jose M Calhariz > > On Tue, Sep 01, 2020 at 04:07:55PM -0700, Benjamin Kaduk wrote: > > On Tue, Sep 01, 2020 at 03:43:37PM +0100, Jose M Calhariz wrote: > > > Package: openafs-client > > > Version: 1.8.6-1~dsi10+1 > > > Severity: normal > > > > > > I am using a private backport of openafs from testing. On this server I > > > am getting multiples strange errors about openafs cache. This server > > > is different in that it runs apache to serve personal web pages and every > > > web page runs under a different openafs user. So is normal for this > > > server to be simultaneuous running code under 100 or 200 different > > > openafs > > > users. > > > > > > The an example of errors on the logs are: > > > > > > afs: disk cache read error in CacheItems slot 350195 off > > > 28015620/3520 code -4/80 > > > afs: Error while alloc'ing cache slot for file 204:536874423.964.4794; > > > failing with an i/o error > > > > > > I am not certain this types of errors are to be ignored and there have > > > been reports of problems accessing openafs files. I am using this bug > > > report to collect more information about this cache errors and the > > > possibility of being an indication of important errors with the openafs > > > cache code. > > > > This error message is supposed to indicate that a read from the cache > > filesystem got EIO, which in turn is supposed to indicate a physical > > problem with the drive. That said, I'm not going to jump to conclusions > > and try to blame your drive, as there are several other things that could > > be coming into play. > > > > While the log message itself is pretty old, there's been a lot of work > > recently to more accurately report EIO in error conditions (mostly instead > > of ENOENT, since returning ENOENT can cause that to get cached at the VFS > > layer and produce strange user-visible behavior). > > > > Having a lot of users present makes me suspect that the credentials used by > > the kernel to read/write the cache file are not being saved/restored > > properly, and indeed we recently merged to 1.8.x (not in a release yet) > > https://gerrit.openafs.org/14082 and https://gerrit.openafs.org/14099 which > > improve such credentials management. > > > > My recommendation would be to try pulling in those two patches to your > > build before proceeding to try to trace the source of the EIO. > > > > Thanks for the report! > > > > -Ben > > > -- -- A esperança tem que ter a audácia do desespero. --Millôr Fernandes Retirado de http://www.uol.com.br/millor signature.asc Description: PGP signature
Bug#969376: openafs-client: Openafs cache erros on the logs
Hi, I will then update my private backport and see if the things improve. I will report here the results of your sugestion. Thank you. Kind regards Jose M Calhariz On Tue, Sep 01, 2020 at 04:07:55PM -0700, Benjamin Kaduk wrote: > On Tue, Sep 01, 2020 at 03:43:37PM +0100, Jose M Calhariz wrote: > > Package: openafs-client > > Version: 1.8.6-1~dsi10+1 > > Severity: normal > > > > I am using a private backport of openafs from testing. On this server I > > am getting multiples strange errors about openafs cache. This server > > is different in that it runs apache to serve personal web pages and every > > web page runs under a different openafs user. So is normal for this > > server to be simultaneuous running code under 100 or 200 different openafs > > users. > > > > The an example of errors on the logs are: > > > > afs: disk cache read error in CacheItems slot 350195 off 28015620/3520 > > code -4/80 > > afs: Error while alloc'ing cache slot for file 204:536874423.964.4794; > > failing with an i/o error > > > > I am not certain this types of errors are to be ignored and there have > > been reports of problems accessing openafs files. I am using this bug > > report to collect more information about this cache errors and the > > possibility of being an indication of important errors with the openafs > > cache code. > > This error message is supposed to indicate that a read from the cache > filesystem got EIO, which in turn is supposed to indicate a physical > problem with the drive. That said, I'm not going to jump to conclusions > and try to blame your drive, as there are several other things that could > be coming into play. > > While the log message itself is pretty old, there's been a lot of work > recently to more accurately report EIO in error conditions (mostly instead > of ENOENT, since returning ENOENT can cause that to get cached at the VFS > layer and produce strange user-visible behavior). > > Having a lot of users present makes me suspect that the credentials used by > the kernel to read/write the cache file are not being saved/restored > properly, and indeed we recently merged to 1.8.x (not in a release yet) > https://gerrit.openafs.org/14082 and https://gerrit.openafs.org/14099 which > improve such credentials management. > > My recommendation would be to try pulling in those two patches to your > build before proceeding to try to trace the source of the EIO. > > Thanks for the report! > > -Ben > -- -- A modéstia é como a roupa íntima da mulher - existe, mas não deve ser exibida --Roberto Campos signature.asc Description: PGP signature
Bug#969376: openafs-client: Openafs cache erros on the logs
Package: openafs-client Version: 1.8.6-1~dsi10+1 Severity: normal I am using a private backport of openafs from testing. On this server I am getting multiples strange errors about openafs cache. This server is different in that it runs apache to serve personal web pages and every web page runs under a different openafs user. So is normal for this server to be simultaneuous running code under 100 or 200 different openafs users. The an example of errors on the logs are: afs: disk cache read error in CacheItems slot 350195 off 28015620/3520 code -4/80 afs: Error while alloc'ing cache slot for file 204:536874423.964.4794; failing with an i/o error I am not certain this types of errors are to be ignored and there have been reports of problems accessing openafs files. I am using this bug report to collect more information about this cache errors and the possibility of being an indication of important errors with the openafs cache code. Kind regards Jose M Calhariz -- System Information: Debian Release: 10.5 Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_PT.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openafs-client depends on: ii debconf [debconf-2.0] 1.5.71 ii init-system-helpers1.56+nmu1 ii libc6 2.28-10 ii libcom-err21.44.5-1+deb10u3 ii libhcrypto4-heimdal7.5.0+dfsg-3 ii libk5crypto3 1.17-3 ii libkrb5-26-heimdal 7.5.0+dfsg-3 ii libkrb5support01.17-3 ii libncurses66.1+20181013-2+deb10u2 ii libroken18-heimdal 7.5.0+dfsg-3 ii libtinfo6 6.1+20181013-2+deb10u2 ii lsb-base 10.2019051400 Versions of packages openafs-client recommends: ii lsof 4.91+dfsg-1 ii openafs-modules-dkms 1.8.6-1~dsi10+1 Versions of packages openafs-client suggests: pn openafs-doc ii openafs-krb5 1.8.6-1~dsi10+1 -- debconf information: * openafs-client/cachesize: 1400 * openafs-client/fakestat: true openafs-client/cell-info: * openafs-client/crypt: true * openafs-client/thiscell: ist.utl.pt * openafs-client/afsdb: true * openafs-client/run-client: true * openafs-client/dynroot: No
Bug#968104: openafs-client: Upgrade of openfs-client break until reboot
Hi Benjamin, reply inline. On Sun, Aug 30, 2020 at 05:28:15PM -0700, Benjamin Kaduk wrote: > Hi Jose, > > Sorry that I missed this when it first came in. > A couple notes inline, if you still remember much about the original > report... > > On Sat, Aug 08, 2020 at 06:32:07PM +0100, Jose M Calhariz wrote: > > Package: openafs-client > > Version: 1.8.6-1~dsi10+1 > > Severity: normal > > > > Hi, > > > > I have made a "private backport" of openafs software from bullseye to > > buster. So this means is the first time for me that I am upgrading > > openafs client 1.8.x on live systems. Where in the past this worked > > To clarify: are you upgrading from 1.6.x to 1.8.x, or merely updating from > one 1.8.x version to a newer 1.8.x version? I am doing an "apt upgrade" to upgrade openafs-1.8.2 to newer 1.8.6 on Debian 10. In the mix there was an kernel update with a new ABI. Maybe a stand alone upgrade of openafs 1.8.2 to 1.8.6 works as intended. > > > without problems for openafs 1.4 and 1.6, now the openafs client stops > > working and I need to do a reboot. > > > > What I am requesting is that if possible to do a live upgrade of the > > software and the client does not stop working even if it is necessary > > to work with the old software until a reboot. > > What you are requesting is what is supposed to happen, so I'm unpleasantly > surprised to hear that it is not happening. > > Once I hear back about the problematic scenario I can try to reproduce in a > local VM. I have a local openafs cell just for tests where I can do more tests, If you need more information. > > Thanks, > > Ben > Kind regards Jose M Calhariz -- -- Ame muito as pessoas, mas nunca tanto ao ponto de ter medo de perde-las -- Zinder signature.asc Description: PGP signature
Bug#805445: ifupdown: Static IPv6 Default Route is not configured when exists RA and interface is not up
Package: ifupdown Version: 0.8.35 Followup-For: Bug #805445 In our server VLAN there are IPv6 RA. Every method we tried to disable autconf and RA on the clients are not working in buster, being kernel parameter autoconf=0, by sysctl.conf or by options in network/interfaces. This bug is important to us. -- Package-specific info: --- /etc/network/interfaces: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface #allow-hotplug ens3 auto ens3 iface ens3 inet static address XXX.YYY.ZZZ.251/25 gateway XXX.YYY.ZZZ.254 dns-nameserver XXX.YYY.ZZZ.81 XXX.YYY.ZZZ.82 # This is an autoconfigured IPv6 interface iface ens3 inet6 static address :::1::81/64 gateway :::1::1 accept_ra 0 pre-up echo accept_ra pre-up cat /proc/sys/net/ipv6/conf/*/accept_ra autoconf 0 pre-up echo autoconf pre-up cat /proc/sys/net/ipv6/conf/*/autoconf #pre-up echo use_tempaddr #pre-up cat /proc/sys/net/ipv6/conf/*/use_tempaddr pre-up ip a pre-up ip -6 r --- /etc/network/interfaces.d/*: cat: '/etc/network/interfaces.d/*': No such file or directory --- up and down scripts installed: /etc/network/if-down.d: total 0 /etc/network/if-post-down.d: total 0 /etc/network/if-pre-up.d: total 0 /etc/network/if-up.d: total 0 -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ifupdown depends on: ii adduser 3.118 ii iproute2 4.20.0-2 ii libc6 2.28-10 ii lsb-base 10.2019051400 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.4.1-2 Versions of packages ifupdown suggests: pn ppp pn rdnssd -- no debconf information
Bug#968104: openafs-client: Upgrade of openfs-client break until reboot
Package: openafs-client Version: 1.8.6-1~dsi10+1 Severity: normal Hi, I have made a "private backport" of openafs software from bullseye to buster. So this means is the first time for me that I am upgrading openafs client 1.8.x on live systems. Where in the past this worked without problems for openafs 1.4 and 1.6, now the openafs client stops working and I need to do a reboot. What I am requesting is that if possible to do a live upgrade of the software and the client does not stop working even if it is necessary to work with the old software until a reboot. Kind regards Jose M Calhariz -- System Information: Debian Release: 10.5 Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_PT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openafs-client depends on: ii debconf [debconf-2.0] 1.5.71 ii init-system-helpers1.56+nmu1 ii libc6 2.28-10 ii libcom-err21.44.5-1+deb10u3 ii libhcrypto4-heimdal7.5.0+dfsg-3 ii libk5crypto3 1.17-3 ii libkrb5-26-heimdal 7.5.0+dfsg-3 ii libkrb5support01.17-3 ii libncurses66.1+20181013-2+deb10u2 ii libroken18-heimdal 7.5.0+dfsg-3 ii libtinfo6 6.1+20181013-2+deb10u2 ii lsb-base 10.2019051400 Versions of packages openafs-client recommends: ii lsof 4.91+dfsg-1 ii openafs-modules-dkms 1.8.6-1~dsi10+1 Versions of packages openafs-client suggests: pn openafs-doc ii openafs-krb5 1.8.6-1~dsi10+1 -- debconf information: * openafs-client/fakestat: true * openafs-client/thiscell: ist.utl.pt * openafs-client/crypt: true * openafs-client/afsdb: true * openafs-client/cachesize: 1400 * openafs-client/dynroot: No openafs-client/cell-info: * openafs-client/run-client: true
Bug#519716: at: use nice levels starting from 0
On Thu, Jul 25, 2019 at 08:19:20PM +0200, Christoph Berg wrote: > Re: Jose M Calhariz 2019-07-18 <20190718145028.pfd7ib2wwvgy7...@calhariz.com> > > I have been working on a new release of at and took the decision to > > implement your request. Are you still interested in this feature? > > Do you want to review it? > > Hi Jose, > > TBH I can't remember anything about this patch, so please just go > ahead implementing it. > > Christoph > It is now done, you can check the new version of at daemon from http://software.calhariz.com/at or check my blog http://blog.calhariz.com about it. Kind regards Jose M Calhariz -- -- O programa D-Base só deve ser acionado com o Windows fechado. signature.asc Description: PGP signature
Bug#519716: at: use nice levels starting from 0
Hi, I have been working on a new release of at and took the decision to implement your request. Are you still interested in this feature? Do you want to review it? Kind regards Jose M Calhariz -- -- Todo homem se torna a coisa que mais despreza. -- Robert Benchley signature.asc Description: PGP signature
Bug#528671: bad mtime handling of atjobs dir causes delayed execution of jobs
Hi, I am preparing a new release of the at daemon. Are you still interested in this bug? Are you available to review if the fix solved the problem? Kind regards Jose M Calhariz -- -- Modems de 2400, por favor transitar na pista a direita. signature.asc Description: PGP signature
Bug#364975: at command ignores savings time when given UTC time
Hi, I am working in a new release of at daemon and I have incorporated your second patch. Are you interested in reviewing the code and the if fixed the problem? Kind regards Jose M Calhariz -- -- Modems de 2400, por favor transitar na pista a direita. signature.asc Description: PGP signature
Bug#763859: at + Lmod fails after shellshock update
Hi, are you still affected by this problem? Kind regards Jose M Calhariz -- -- Um excêntrico é um homem de tecnologia simples que cria revoluções --Ernst Friedrich Schumacher signature.asc Description: PGP signature
Bug#863045: at: interactively please print parsed time at start
Hi,
as promised is here the patch. This is a draft so you can look into
the new message and say if you aprove it. The code is not optimized,
so I may change it a bit.
Kind regards
Jose M Calhariz
diff --git a/ChangeLog b/ChangeLog
index 2300d1a..b013595 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -199,3 +199,7 @@ at 3.1.22 (2018-07-24):
at 3.1.23 (2018-07-24):
Jose M Calhariz
Finalised script to release software.
+
+at 3.1.24~WIP
+ Jose M Calhariz
+ Print time of new job before the input of the commands, Closes #863045
diff --git a/at.c b/at.c
index 2136e0b..4d88dcb 100644
--- a/at.c
+++ b/at.c
@@ -479,6 +479,11 @@ writefile(time_t runtimer, char queue)
istty = isatty(fileno(stdin));
if (istty) {
+ runtime = localtime(&runtimer);
+
+ strftime(timestr, TIMESIZE, TIMEFORMAT_POSIX, runtime);
+ fprintf(stderr, "at %s\n", timestr);
+
fprintf(stderr, "at> ");
fflush(stderr);
}
--
--
Já que a primeira impressão é a que fica, então use uma
impressora Laser.
signature.asc
Description: PGP signature
Bug#863045: at: interactively please print parsed time at start
On July 17, 2019 5:09:01 AM GMT-03:00, Daniel Shahaf wrote: >Jose M Calhariz wrote on Wed, 17 Jul 2019 02:03 +00:00: >> I am working in a new release of at and I have a draft of this >> feature. If you are interested in beta testing it, I can prepare a >> package for most releases of Debian on i386 ou amd64. > >Thanks for looking into this and for offering to prepare a beta >package! >There'll be no need for a beta package, however; a patch against the >current >stretch or sid package will be sufficient. I should be able to find >time to build >it and give it a test drive. > >Thanks again, > >Daniel I will send a patch from my other email. Kind regards Jose M Calhariz -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#863045: at: interactively please print parsed time at start
Hi, I am working in a new release of at and I have a draft of this feature. If you are interested in beta testing it, I can prepare a package for most releases of Debian on i386 ou amd64. Kind regards Jose M Calhariz -- -- Se quer construir algo do nada, comece amando intensamente seus pensamentos e sua imaginação. Um grande caminho começa com o primeiro passo. O resto fica por conta das circunstancias. signature.asc Description: PGP signature
Bug#885890: at: permissions of /var/spool/cron/atjobs/ are to strict
Hi, I been thinking on your solution but I am not certain that is secure. So for now I think the best solution is to enhance the atq command. If you are interested I accept patches for the at.c code. Kind regards Jose M Calhariz -- -- Se quer construir algo do nada, comece amando intensamente seus pensamentos e sua imaginação. Um grande caminho começa com o primeiro passo. O resto fica por conta das circunstancias. signature.asc Description: PGP signature
Bug#805602: at doesn't understand "at now + 1 second" etc.
Do you still interested in this bug? I would well come a patch on how to handle seconds in the input. I am prepaeing a new release of at and would like to add this feature. Kind regards Jose M Calhariz -- -- Para que ocorra um tiro a queima roupa é necessário que a vítima esteja vestida? signature.asc Description: PGP signature
Bug#792040: [PATCH] Allow seconds in -t option
Hi, Still interested in this bug report? Adding support for seconds to at daemon? I am considering to release a new version of at with your patch and others to support seconds and I am looking for beta testers. Kind regards Jose M Calhariz -- -- Para que ocorra um tiro a queima roupa é necessário que a vítima esteja vestida? signature.asc Description: PGP signature
Bug#929481: Preseed on buster does not use extra repository
Package: installation-reports Boot method: CD Image version: debian-testing-amd64-netinst-20190522-5.iso Date: 2019/05/23 18:40 Machine: KVM/QEMU amd64 Partitions: empty Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[E] Comments/Problems: I think the preseed for buster have changes from stretch and possibly bugs. This time I wanted to test the addition of an extra repository to install software not in Debian. But I can not make the installer add the extra repo for installing the extra package. deb http://www.calhariz.com/deb-ppa stretch main Is a repo with only one deb file. If I use the preseed in www.calhariz.com to install stretch everything goes OK and I have the extra package installed. An almost same file does not work for buster. diff -u stretch/preseed.cfg buster/preseed.cfg --- stretch/preseed.cfg 2019-05-23 19:00:04.867300896 +0200 +++ buster/preseed.cfg 2019-05-23 19:20:06.542149304 +0200 @@ -55,7 +55,7 @@ #d-i passwd/user-default-groups string audio cdrom video # Uncomment this if you don't want to use a network mirror. -d-i apt-setup/use_mirror boolean false +d-i apt-setup/use_mirror boolean true # Select which update services to use; define the mirrors to be used. # Values shown below are the normal defaults. d-i apt-setup/services-select multiselect Kind regards Jose M Calhariz -- -- O que há de novo no windows 98: Sistema de Arquivos A nova FAT do Windows 98 garante que você não precise mais se incomodar com a segurança do seu computador. O novo Scandisk faz com que seus arquivos ocultos não sejam encontrados nem mesmo pelo próprio sistema operacional. No caso de perda de um arquivo importante do sistema, o Windows 98 diagnostica e executa o Format C: automaticamente. Mais de 300 funções do sistema tentarão impedir que você faça seu Winchester se comunicar com outro, seja por cabo externo ou pelo próprio gabinete. hardware-summary.gz Description: application/gzip DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="10 (buster) - installer build 20190522-00:02:51" X_INSTALLATION_MEDIUM=cdrom partman.gz Description: application/gzip status.gz Description: application/gzip syslog.gz Description: application/gzip signature.asc Description: PGP signature
Bug#928031: Preseed on buster have problems
On Fri, Apr 26, 2019 at 06:06:37PM +0100, Jose M Calhariz wrote: > On Fri, Apr 26, 2019 at 05:42:36PM +0200, Cyril Brulebois wrote: > > Thanks for the follow-up. > > > > Jose M Calhariz (2019-04-26): > > > On Fri, Apr 26, 2019 at 03:09:31PM +0200, Cyril Brulebois wrote: > > > > Jose M Calhariz (2019-04-26): > > > > > I am doing this report because I wanted test preseed on buster. > > > > > I found some problems, by order of priority: > > > > > > > > > > - The installation using preseed, ends with an incomplete > > > > > /etc/apt/sources.list that prevents to install more software after > > > > > the instalation. > > > > > > > > Can you please share more details about that? > > > > > > This is the /etc/apt/sources.list that I get when using preseed: > > > > > > # > > > > > > # deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 > > > NETINST 20190411-22:32]/ buster main > > > > > > deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 > > > NETINST 20190411-22:32]/ buster main > > > > This seems consistent with your settings (excerpt from [1]): > > > > # Uncomment this if you don't want to use a network mirror. > > d-i apt-setup/use_mirror boolean false > > # Select which update services to use; define the mirrors to be used. > > # Values shown below are the normal defaults. > > d-i apt-setup/services-select multiselect > > #d-i apt-setup/security_host string security.debian.org > > > > 1. http://web.ist.utl.pt/ist24403/preseed.cfg > > > > since apt-setup/use_mirror=false means the cdrom: URI will be kept and > > no network mirror is to be used? > > My original preseed included references for a modified local mirror of > Debian that the upper management did not authorize to make public the > URL yet. In my defence the original preseed works with stretch and I > am trying to understand why it fails for buster. So one more > question, during instalation of base and tasks, like openssh-server, > where is the sources.list that is being used. It is not in > /target/etc/apt/sources.list I found some interesting bits: Main problem is in my original preseed, I have not updated enough for buster. Done that the installation now goes to the end. The sources.list is still broken, with the same content has previously shown. The same rough preseed works as desired on stretch, minus the replacement of words stretch and buster. So maybe "d-i apt-setup/use_mirror boolean false" have a change in behaviour between stretch and buster. What I want in the end is a sources.list with the repositories from "d-i apt-setup/local[0-9]/repository ..." and not the original mirror from installation. I can explain why in another email. > > > > > > > > - The text installer show a black screen, I need to use "fb=false". > > > > > > > > We would probably need to know more about your hardware here. > > > > > > Right, I missed that I am using virtio as display, my command line is: > > > > > > kvm -m 4096 -localtime -drive file=debian.qcow2,if=virtio > > > -usbdevice tablet -k en-gb -vga virtio -cdrom > > > /srv/software/debian-buster-DI-rc1-amd64-netinst.iso -boot d > > > > Hopefully somebody else will pick up this specific part. > > > > > > Cheers, > > Kind regards > Jose M Calhariz > Kind regards Jose M Calhariz -- -- Uma consciência que já foi comprada uma vez pode ser comprada de novo. -- Norbert Wiener signature.asc Description: PGP signature
Bug#928031: Preseed on buster have problems
On Fri, Apr 26, 2019 at 05:42:36PM +0200, Cyril Brulebois wrote: > Thanks for the follow-up. > > Jose M Calhariz (2019-04-26): > > On Fri, Apr 26, 2019 at 03:09:31PM +0200, Cyril Brulebois wrote: > > > Jose M Calhariz (2019-04-26): > > > > I am doing this report because I wanted test preseed on buster. > > > > I found some problems, by order of priority: > > > > > > > > - The installation using preseed, ends with an incomplete > > > > /etc/apt/sources.list that prevents to install more software after > > > > the instalation. > > > > > > Can you please share more details about that? > > > > This is the /etc/apt/sources.list that I get when using preseed: > > > > # > > > > # deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 > > NETINST 20190411-22:32]/ buster main > > > > deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 > > NETINST 20190411-22:32]/ buster main > > This seems consistent with your settings (excerpt from [1]): > > # Uncomment this if you don't want to use a network mirror. > d-i apt-setup/use_mirror boolean false > # Select which update services to use; define the mirrors to be used. > # Values shown below are the normal defaults. > d-i apt-setup/services-select multiselect > #d-i apt-setup/security_host string security.debian.org > > 1. http://web.ist.utl.pt/ist24403/preseed.cfg > > since apt-setup/use_mirror=false means the cdrom: URI will be kept and > no network mirror is to be used? My original preseed included references for a modified local mirror of Debian that the upper management did not authorize to make public the URL yet. In my defence the original preseed works with stretch and I am trying to understand why it fails for buster. So one more question, during instalation of base and tasks, like openssh-server, where is the sources.list that is being used. It is not in /target/etc/apt/sources.list > > > > > - The text installer show a black screen, I need to use "fb=false". > > > > > > We would probably need to know more about your hardware here. > > > > Right, I missed that I am using virtio as display, my command line is: > > > > kvm -m 4096 -localtime -drive file=debian.qcow2,if=virtio > > -usbdevice tablet -k en-gb -vga virtio -cdrom > > /srv/software/debian-buster-DI-rc1-amd64-netinst.iso -boot d > > Hopefully somebody else will pick up this specific part. > > > Cheers, Kind regards Jose M Calhariz -- -- Uma consciência que já foi comprada uma vez pode ser comprada de novo. -- Norbert Wiener signature.asc Description: PGP signature
Bug#928031: Preseed on buster have problems
On Fri, Apr 26, 2019 at 03:09:31PM +0200, Cyril Brulebois wrote: > Hi Jose, > > Jose M Calhariz (2019-04-26): > > I am doing this report because I wanted test preseed on buster. I > > found some problems, by order of priority: > > > > - The installation using preseed, ends with an incomplete > > /etc/apt/sources.list that prevents to install more software after > > the instalation. > > Can you please share more details about that? This is the /etc/apt/sources.list that I get when using preseed: # # deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 NETINST 20190411-22:32]/ buster main deb cdrom:[Debian GNU/Linux buster-DI-rc1 _Buster_ - Official RC amd64 NETINST 20190411-22:32]/ buster main > > > - The text installer show a black screen, I need to use "fb=false". > > We would probably need to know more about your hardware here. Right, I missed that I am using virtio as display, my command line is: kvm -m 4096 -localtime -drive file=debian.qcow2,if=virtio -usbdevice tablet -k en-gb -vga virtio -cdrom /srv/software/debian-buster-DI-rc1-amd64-netinst.iso -boot d > > > - By default the installer is still calling > > http://$host/d-i/stretch/preseed.cfg instead of > > http://$host/d-i/buster/preseed.cfg > > Good catch, I've just pushed a new preseed upload with this change: > > https://salsa.debian.org/installer-team/preseed/commit/10daa285644dc8061d65da60e28bd11000c893c3 > > I've also noted locally to add this package to a post-release checklist, > so that it has higher chances of getting an update next time. > > > Cheers, Kind regards Jose M Calhariz -- -- Uma consciência que já foi comprada uma vez pode ser comprada de novo. -- Norbert Wiener signature.asc Description: PGP signature
Bug#928031: Preseed on buster have problems
Package: installation-reports Boot method: CD Image version: debian-buster-DI-rc1-amd64-netinst.iso Date: 2019/04/26 12:00 Machine: KVM on Debian stretch Partitions: Used auto partition into 1 big partition for data Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[E] Comments/Problems: I am doing this report because I wanted test preseed on buster. I found some problems, by order of priority: - The installation using preseed, ends with an incomplete /etc/apt/sources.list that prevents to install more software after the instalation. - The text installer show a black screen, I need to use "fb=false". - By default the installer is still calling http://$host/d-i/stretch/preseed.cfg instead of http://$host/d-i/buster/preseed.cfg To perform my tests, and to reproduce the problems I am using the following line on the installer: install fb=false auto url=http://web.ist.utl.pt/ist24403/preseed.cfg Kind regards Jose M Calhariz -- Uma consciência que já foi comprada uma vez pode ser comprada de novo. -- Norbert Wiener hardware-summary.gz Description: application/gzip syslog.gz Description: application/gzip signature.asc Description: PGP signature
Bug#908400: grub-common: grub-install does not work in UEFI mode but a full instalation from Debian CD works
Package: grub-common
Version: 2.02+dfsg1-6
Severity: normal
Tags: d-i
Hi,
I have an Gigabyte H77M-D3H motherboard that supports UEFI mode. The
Debian installer can do a full installation in UEFI mode and boot the
system.
If I change or add another new disk, I did not yet found a way to fix
the boot in UEFI mode unless I do another install using the Debian CD,
stretch or buster. I have followed the instructions in the Debian
Wiki GrubEFIReinstall, but they do not work for me. Looking into
efibootmgr --verbose I do not found anything wrong.
BootCurrent:
Timeout: 5 seconds
BootOrder: ,0002,0006
Boot* debian
HD(1,GPT,087f2227-d0d0-4535-b6cc-402603e182ae,0x800,0x10)/File(\EFI\debian\grubx64.efi)
Boot0002* rEFInd Boot Manager
HD(1,GPT,087f2227-d0d0-4535-b6cc-402603e182ae,0x800,0x10)/File(\EFI\refind\refind_x64.efi)
Boot0006* UEFI: Hitachi HUA721010KLA330
PciRoot(0x0)/Pci(0x1f,0x5)/Ata(0,0,0)/HD(1,GPT,4adac19e-a245-4228-91fc-59bb3560cd52,0x800,0xf3800)AMBO
If I install rEFInd It will not work too. The lastest BIOS from
Gigabyte is a Beta one, so I am using the latest stable. I am tagging
d-i because the fix that exists there may be removed by mistake.
In short:
- CD Debian installer works for UFI mode.
- grub-install or install of rEFInd does not work.
Kind regards
Jose M Calhariz
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/vg100/root-picard / ext3 rw,noatime,errors=remount-ro,data=ordered 0 0
/dev/vg100/usr /usr ext3 rw,noatime,errors=remount-ro,data=ordered 0 0
/dev/mapper/vg141-amanda2 /backup/amanda2 ext4
rw,noatime,stripe=32751,data=ordered 0 0
/dev/mapper/vg141-amanda /backup/amanda ext3 rw,noatime,data=ordered 0 0
/dev/mapper/vg100-srv /srv ext4
rw,noatime,errors=remount-ro,stripe=32681,data=ordered 0 0
/dev/md8 /backup/storebackup xfs rw,noatime,inode64,noquota 0 0
/dev/sda1 /boot/efi vfat
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
/dev/mapper/vg100-vz /srv/vz ext3 rw,noatime,errors=remount-ro,data=ordered 0 0
/dev/mapper/vg100-mccoy--root /fsnet/mccoy/root ext4 rw,noatime,data=ordered 0 0
/dev/mapper/vg100-copernico--home /fsnet/copernico/root/home ext4
rw,noatime,data=ordered 0 0
/dev/mapper/vg100-home /home ext3 rw,noatime,errors=remount-ro,data=ordered 0 0
/dev/mapper/vg100-beverly--Users /fsnet/beverly/root/Users ext4
rw,noatime,data=ordered 0 0
/dev/mapper/vg100-Maildir /home/cal/Maildir ext3
rw,noatime,errors=remount-ro,data=ordered 0 0
/dev/mapper/vg100-web /srv/web ext3 rw,noatime,errors=remount-ro,data=ordered 0 0
/dev/mapper/vg100-var /var ext3 rw,noatime,errors=remount-ro,data=ordered 0 0
/dev/mapper/vg100-hdisk2 /hdisk ext3 rw,noatime,errors=remount-ro,data=ordered
0 0
/dev/mapper/vg100-data--root /fsnet/data/root ext3 rw,noatime,data=ordered 0 0
/dev/mapper/vg100-data--home /fsnet/data/root/home ext3 rw,noatime,data=ordered
0 0
/dev/mapper/vg100-data--chroot /fsnet/data/root/home/chroot ext3
rw,noatime,data=ordered 0 0
/dev/mapper/vg100-data3 /data btrfs rw,noatime,space_cache,subvolid=5,subvol=/
0 0
/dev/mapper/vg100-sd_wii_ios2 /data/consolas/wii/sd_wii_ios2 vfat
rw,noatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,uni_xlate,tz=UTC,errors=remount-ro
0 0
/dev/mapper/vg100-music /data/music ext3 rw,noatime,data=ordered 0 0
/dev/mapper/vg100-virt /data/virt ext3 rw,noatime,data=ordered 0 0
/dev/mapper/vg100-torrent /data/incoming/torrent ext3 rw,noatime,data=ordered 0 0
/dev/mapper/vg100-hdisk /data/hdisk ext3 rw,noatime,data=ordered 0 0
/dev/mapper/vg100-images /data/images ext3 rw,noatime,data=ordered 0 0
/dev/mapper/vg100-sd_wii_ios /data/consolas/wii/sd_wii_ios vfat
rw,noatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,uni_xlate,tz=UTC,errors=remount-ro
0 0
/dev/mapper/vg100-R4I--SDHC /data/consolas/nds/sd_R4I-SDHC vfat
rw,noatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,uni_xlate,tz=UTC,errors=remount-ro
0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/hda
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}&
Bug#907579: mlocate: Please update updatedb.conf with more network and special filesystems
Package: mlocate Version: 0.26-2 Severity: normal Tags: patch The current updatedb.conf lacks many network and special filesystems. Some of them can be very big or probably useless to index. My suggested and sorted list is: PRUNEFS="afs autofs binfmt_misc ceph cgroup cgroup2 cifs coda configfs curlftpfs debugfs devfs devpts devtmpfs ecryptfs ftpfs fuse.ceph fusectl fuse.glusterfs fuse.gvfsd-fuse fuse.mfs fuse.rozofs fusesmb fuse.sshfs hugetlbfs iso9660 lustre lustre_lite mfs mqueue ncpfs nfs NFS nfs4 ocfs ocfs2 proc pstore rpc_pipefs securityfs shfs smbfs sysfs tmpfs tracefs udev udf usbfs" Kind regards Jose M Calhariz -- System Information: Debian Release: 9.5 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mlocate depends on: ii adduser 3.115 ii libc62.24-11+deb9u3 mlocate recommends no packages. mlocate suggests no packages. -- no debconf information
Bug#906107: linux-image-3.16.0-6-amd64: Latests kernel 3.16 on KVM host breaks Linux guest with lastests kernels
On Tue, Aug 14, 2018 at 10:39:12AM +0100, Jose M Calhariz wrote: > Package: src:linux > Version: 3.16.57-2 > Severity: important > > We use OpenNebula on Debian 8 to run KVM guests. Our latest upgrade of the > host and guests broke badly. > The host can not run guests with the latest kernels from Debian 8 and 9. If > we downgrade the kernel on > host or guest the problem is no longer present. > > To localize the root problem, I managed to launch a KVM guest on the command > line using the lastest > Debian live CD and the problem was the same. This is not a problem of > OpenNebula. > > I need help to collect more information about what is going wrong on the > guest and the host. > > Kind regards > Jose M Calhariz > I have made videos of a guest live cd from Debian trying to boot and failing. qemu-system-x86_64 -enable-kvm -machine pc-i440fx-2.1,accel=kvm,usb=off -m 8096 -device cirrus-vga,id=video0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -cpu host -msg timestamp=on -smp 4,sockets=4,cores=1,threads=1 -display vnc=:22 -cdrom ~cal/debian-9.5.0-amd64-xfce-CD-1.iso The most informative have 60MB. There is a recomended place to upload videos? If not, I can upload on my homepage at University. Kind regards Jose M Calhariz -- -- Quem ama puríssima, dourada lhe parece. signature.asc Description: PGP signature
Bug#906107: linux-image-3.16.0-6-amd64: Latests kernel 3.16 on KVM host breaks Linux guest with lastests kernels
Package: src:linux Version: 3.16.57-2 Severity: important We use OpenNebula on Debian 8 to run KVM guests. Our latest upgrade of the host and guests broke badly. The host can not run guests with the latest kernels from Debian 8 and 9. If we downgrade the kernel on host or guest the problem is no longer present. To localize the root problem, I managed to launch a KVM guest on the command line using the lastest Debian live CD and the problem was the same. This is not a problem of OpenNebula. I need help to collect more information about what is going wrong on the guest and the host. Kind regards Jose M Calhariz -- Package-specific info: ** Version: Linux version 3.16.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) ) #1 SMP Debian 3.16.57-2 (2018-07-14) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-6-amd64 root=/dev/mapper/system-root ro quiet ** Tainted: I (2048) * Working around severe firmware bug. ** Kernel log: [ 1176.926137] kvm [12584]: vcpu0 unhandled rdmsr: 0x1c9 [ 1176.926209] kvm [12584]: vcpu0 unhandled rdmsr: 0x1a6 [ 1176.926275] kvm [12584]: vcpu0 unhandled rdmsr: 0x1a7 [ 1176.926341] kvm [12584]: vcpu0 unhandled rdmsr: 0x3f6 ** Model information sys_vendor: Dell Inc. product_name: PowerEdge R410 product_version: chassis_vendor: Dell Inc. chassis_version: bios_vendor: Dell Inc. bios_version: 1.9.0 board_vendor: Dell Inc. board_name: 01V648 board_version: A04 ** Loaded modules: nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack xt_physdev ip_set nfnetlink vhost_net vhost macvtap macvlan tun xt_multiport iptable_filter ip_tables x_tables dm_round_robin ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi rpcsec_gss_krb5 nfsv4 dns_resolver nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc bridge 8021q garp stp mrp llc dm_queue_length dm_multipath scsi_dh intel_powerclamp coretemp kvm_intel ttm drm_kms_helper kvm drm crc32_pclmul ipmi_devintf iTCO_wdt iTCO_vendor_support dcdbas joydev evdev aesni_intel acpi_power_meter serio_raw aes_x86_64 pcspkr ipmi_si lrw lpc_ich gf128mul tpm_tis glue_helper tpm mfd_core ablk_helper cryptd i7core_edac ipmi_msghandler edac_core shpchp processor thermal_sys button xfs libcrc32c dm_mod raid1 md_mod sd_mod crc_t10dif crct10dif_generic hid_generic usbhid hid usb_storage sg sr_mod cdrom mptsas ahci libahci scsi_transport_sas ehci_pci uhci_hcd mptscsih ehci_hcd libata mptbase igb i2c_algo_bit crct10dif_pclmul crct10dif_common i2c_core crc32c_intel dca usbcore ptp psmouse usb_common scsi_mod pps_core bnx2 ** Network interface configuration: (...) Privacy concerns ** Network status: *** IP interfaces and addresses: (...) Privacy concerns *** Device statistics: Inter-| Receive| Transmit face |bytespackets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed eth0.600: 464024832 5969272000 0 0 2853 17974996 97260000 0 0 0 lo: 901381748000 0 0 090138 1748000 0 0 0 eth3: 1783009756 3986650 17260 0 0 30266 71899026 240175000 0 0 0 br0011: 55169743 796451000 0 0 035956 418000 0 0 0 eth2: 14674510167 64522160 17260 0 0 30478 559178254 6193727000 0 0 0 eth0.11: 91505035 1195004000 0 0895144 98536503 364324000 0 0 0 brj600: 14577853219 6342345000 0 0 0 559177990 6193723000 0 0 0 eth1: 0 0000 0 0 00 0000 0 0 0 brj601: 1772277206 299405000 0 0 0 71645058 236327000 0 0 0 eth0: 2119825552 12748932 81 1723081 0 1859406 21539361933 14723412000 0 0 0 *** Protocol statistics: Ip: 8615928 total packets received 1518 with invalid addresses 0 forwarded 0 incoming packets discarded 8002257 incoming packets delivered 7038705 requests sent out 4 fragments received ok 8 fragments created Icmp: 9817 ICMP messages received 0 input ICMP message failed. ICMP input histogram: destination unreachable: 11 echo requests: 9806 9822 ICMP messages sent 0 ICMP messages failed ICMP output histogram: destination unreachable: 16 echo replies: 9806 IcmpMsg: InType3: 11 InType8: 9806 OutType0: 9806 OutType3: 16 Tcp: active connections openings 415 passive
Bug#904596: gpg: Using gpg --edit-card with different --homedir breaks capability to read a Yubikey 4
Package: gpg Version: 2.2.9-1 Severity: normal I am playing with a yubikey 4. For doing experiments I started using gpg from stretch with --homedir poiting to others paths, so I would not change my keys in ~/.gnupg. Just found that if I read my Yubikey with one --homedir I could not read it in another homedir. Upgraded gpg to version from buster and the problem still persist. This feature is important for new users with yubikeys and similars, where is important to play with GPG and the SmarCard until get the desired result. Kind Regards Jose M Calhariz -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gpg depends on: ii gpgconf2.2.9-1 ii libassuan0 2.5.1-2 ii libbz2-1.0 1.0.6-8.1 ii libc6 2.24-11+deb9u3 ii libgcrypt201.8.3-1 ii libgpg-error0 1.26-2 ii libreadline7 7.0-3 ii libsqlite3-0 3.16.2-5+deb9u1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages gpg recommends: ii gnupg 2.2.9-1 gpg suggests no packages. -- no debconf information
Bug#892819: at: improvements to atd.service
I have included your improvements in source code and will be available in a future 3.1.21. Kind regards Jose M Calhariz -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#832368: Using of the meaningless fcntl()
On July 25, 2016 1:35:29 PM GMT+08:00, Hitoshi Ozeki wrote: >On Mon, 25 Jul 2016 03:33:14 +0900 I wrote: >> [wrong] fcntl(fd, F_SETFD, (long) 1); >> [correct] fcntl(fd, F_SETFD, FD_CLOEXEC); > >This "fcntl()" is used to clear the "close-on-exec flag." >I think that we should stop using the meaningless "value 1". > >[wrong] fcntl(fd, F_SETFD, (long) 1); >[correct] fcntl(fd, F_SETFD, 0); Hi, I have checked the documentation on Debian 9 and Open BSD. FD_CLOEXEC have meaning and behavior. This daemon is used on other systems besides Linux, so I will try to implement your first suggestion. Kind regards Jose M Calhariz -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#900053: amanda-server: amstatus wrong display (fix included)
I investigated the source and the latest amstatus was refactored. So the problem you reported is no longer present in 3.5.1 Kind regards Jose M Calhariz On May 25, 2018 5:43:22 PM GMT+08:00, "Heiko Schlittermann (HS12-RIPE)" wrote: >Package: amanda-server >Version: 1:3.3.9-5 >Severity: minor >Tags: patch > >Dear Maintainer, > >the output from amstatus contains a missing size unit and >shows part of the source code instead. > >line 1420 of amstatus should be changed >from >printf "dumping to tape : %3d %20dsunit (%6.2f%%)\n", >to >printf "dumping to tape : %3d %20d$unit (%6.2f%%)\n", -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#894125: amanda-server: error=write error to: Broken pipe
Hi, This error was one shot or happen every day? Have you look into the amanda logs files on server? Have you look into the amanda logs files of the failing clients? Kind regards Jose M Calhariz
Bug#894125: amanda-server: error=write error to: Broken pipe
Please send the logs to my email address. I will look into this night. Kind regards Jose M Calhariz On March 27, 2018 9:39:35 AM GMT+01:00, "Tobias Köck" wrote: >Hi Jose, > >it happens every time after I rebooted the system yesterday. I haven't >updated amanda-server so far. > >I have looked in into the server logs (see output). I haven't yet >looked >into the failing clients. > >I can send you the logs to your personal email if it would help. > >Greetings >Tobias >On 27.03.2018 08:32, Jose M Calhariz wrote: >> Hi, >> >> This error was one shot or happen every day? >> >> Have you look into the amanda logs files on server? >> >> Have you look into the amanda logs files of the failing clients? >> >> Kind regards >> Jose M Calhariz >> >> >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#890894: logcheck-database: Updates for ignore.d.server/ssh for a stretch system
Package: logcheck-database
Version: 1.3.18
Severity: normal
Hi,
I am reviewing the ignore rules for ssh on my machines and found some
updates are needed. This is my first approach for in the end generate
a proper patch to update the file ignore.d.server/ssh.
My proposed updates, not a proper patch:
#Updates for old messages
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[[[:digit:]]+\]: Connection reset
by [:.[:xdigit:]]+ port [[:digit:]]+ \[preauth\]$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[[[:digit:]]+\]: Did not receive
identification string from ([:[:xdigit:].]+|UNKNOWN)+ port [[:digit:]]+$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[[[:digit:]]+\]: Disconnected
from [:[:xdigit:].]+ port [[:digit:]]+ \[preauth\]$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[[[:digit:]]+\]: I(llegal|nvalid)
user [^[:space:]]* from ([:.[:xdigit:]]+|UNKNOWN) port [[:digit:]]+$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[[[:digit:]]+\]: Received
disconnect from [:.[:xdigit:]]+(: | port [[:digit:]]+:)11: \[preauth\]$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[[[:digit:]]+\]: Received
disconnect from [:.[:xdigit:]]+(: | port [[:digit:]]+:)11: (disconnected by
user|Closed due to user request\.) \[preauth\]$
#New messages
#Feb 20 03:32:33 gw1 sshd[7271]: Received disconnect from 60.248.248.148 port
57727:11: Bye Bye [preauth]
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[[[:digit:]]+\]: Received
disconnect from [:.[:xdigit:]]+ port [[:digit:]]+:11: Bye Bye \[preauth\]$
#Feb 19 22:31:10 gw1 sshd[30597]: Unable to negotiate with 195.154.102.221 port
61875: no matching key exchange method found. Their offer:
diffie-hellman-group1-sha1 [preauth]
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[[[:digit:]]+\]: Unable to
negotiate with [:.[:xdigit:]]+ port [[:digit:]]+: no matching key exchange
method found. Their offer: diffie-hellman-group1-sha1 \[preauth\]$
#Feb 19 17:16:14 gw1 sshd[21179]: Unable to negotiate with 134.213.156.122 port
45349: no matching cipher found. Their offer: none [preauth]
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[[[:digit:]]+\]: Unable to
negotiate with [:.[:xdigit:]]+ port [[:digit:]]+: no matching cipher found.
Their offer: none \[preauth\]$
#Feb 19 17:05:36 gw1 sshd[21017]: Received disconnect from 84.200.93.71 port
45442:11: Normal Shutdown, Thank you for playing [preauth]
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ sshd\[[[:digit:]]+\]: Received
disconnect from [:.[:xdigit:]]+ port [[:digit:]]+:11: Normal Shutdown, Thank
you for playing \[preauth\]$
-- System Information:
Debian Release: 9.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500,
'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to
en_GB.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
-- Configuration Files:
/etc/logcheck/cracking.d/kernel [Errno 13] Permission denied:
'/etc/logcheck/cracking.d/kernel'
/etc/logcheck/cracking.d/rlogind [Errno 13] Permission denied:
'/etc/logcheck/cracking.d/rlogind'
/etc/logcheck/cracking.d/rsh [Errno 13] Permission denied:
'/etc/logcheck/cracking.d/rsh'
/etc/logcheck/cracking.d/smartd [Errno 13] Permission denied:
'/etc/logcheck/cracking.d/smartd'
/etc/logcheck/cracking.d/tftpd [Errno 13] Permission denied:
'/etc/logcheck/cracking.d/tftpd'
/etc/logcheck/cracking.d/uucico [Errno 13] Permission denied:
'/etc/logcheck/cracking.d/uucico'
/etc/logcheck/ignore.d.paranoid/bind [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.paranoid/bind'
/etc/logcheck/ignore.d.paranoid/cron [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.paranoid/cron'
/etc/logcheck/ignore.d.paranoid/incron [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.paranoid/incron'
/etc/logcheck/ignore.d.paranoid/logcheck [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.paranoid/logcheck'
/etc/logcheck/ignore.d.paranoid/postfix [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.paranoid/postfix'
/etc/logcheck/ignore.d.paranoid/ppp [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.paranoid/ppp'
/etc/logcheck/ignore.d.paranoid/pureftp [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.paranoid/pureftp'
/etc/logcheck/ignore.d.paranoid/qpopper [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.paranoid/qpopper'
/etc/logcheck/ignore.d.paranoid/squid [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.paranoid/squid'
/etc/logcheck/ignore.d.paranoid/ssh [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.paranoid/ssh'
/etc/logcheck/ignore.d.paranoid/stunnel [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.paranoid/stunnel'
/etc/logcheck/ignore.d.paranoid/sysklogd [Errno 13] Permission denied:
'/etc/logcheck/ignore.d.paranoid/sysklogd'
/etc/logcheck/ignore
Bug#887355: sawfish: diff for NMU version 1:1.11.90-1.1
Please go forward with the nmu.
Kind regards
Jose M Calhariz
On January 15, 2018 12:30:58 PM GMT+00:00, Laurent Bigonville
wrote:
>Package: sawfish
>Version: 1:1.11.90-1
>Severity: normal
>Tags: patch pending
>
>Dear maintainer,
>
>I've prepared an NMU for sawfish (versioned as 1:1.11.90-1.1) and
>uploaded it to DELAYED/10. Please feel free to tell me if I
>should delay it longer.
>
>Regards.
>diff -Nru sawfish-1.11.90/debian/changelog
>sawfish-1.11.90/debian/changelog
>--- sawfish-1.11.90/debian/changelog 2016-04-24 19:09:19.0
>+0200
>+++ sawfish-1.11.90/debian/changelog 2018-01-15 13:27:25.0
>+0100
>@@ -1,3 +1,16 @@
>+sawfish (1:1.11.90-1.1) unstable; urgency=medium
>+
>+ * Non-maintainer upload.
>+ * debian/control: Drop build-dependency against libesd0-dev (Closes:
>+#856089)
>+ * debian/control: Drop build-dependency against libaudiofile-dev
>(Closes:
>+#857673)
>+ * debian/patches/make-build-reproducible: Fix files order in
>tarballs
>+(Closes: #820668)
>+ * Fix FTCBFS: cross.patch (Closes: #864624)
>+
>+ -- Laurent Bigonville Mon, 15 Jan 2018 13:27:25
>+0100
>+
> sawfish (1:1.11.90-1) unstable; urgency=low
>
> * New upstream release.
>diff -Nru sawfish-1.11.90/debian/control sawfish-1.11.90/debian/control
>--- sawfish-1.11.90/debian/control 2016-04-24 19:09:19.0 +0200
>+++ sawfish-1.11.90/debian/control 2018-01-15 11:34:58.0 +0100
>@@ -9,8 +9,6 @@
>debhelper (>= 9.0.0),
>dh-autoreconf,
>gettext (>= 0.10.37),
>- libaudiofile-dev,
>- libesd0-dev,
>libgmp-dev | libgmp3-dev (>= 4.1.4-8),
>libgtk2.0-dev (>= 2.6),
>librep-dev (>= 0.92.5),
>diff -Nru sawfish-1.11.90/debian/patches/cross.patch
>sawfish-1.11.90/debian/patches/cross.patch
>--- sawfish-1.11.90/debian/patches/cross.patch 1970-01-01
>01:00:00.0 +0100
>+++ sawfish-1.11.90/debian/patches/cross.patch 2018-01-15
>13:27:07.0 +0100
>@@ -0,0 +1,123 @@
>+From: Helmut Grohne
>+Subject: use a triplet-prefixed pkg-config for cross compilation
>+
>+Index: sawfish-1.11.90/configure.in
>+===
>+--- sawfish-1.11.90.orig/configure.in
> sawfish-1.11.90/configure.in
>+@@ -59,7 +59,7 @@
>+ AC_HEADER_SYS_WAIT
>+ AC_HEADER_TIME
>+ AC_CHECK_HEADERS(fcntl.h sys/time.h sys/utsname.h)
>+-AC_PATH_PROG(PKG_CONFIG, [pkg-config], [no])
>++PKG_PROG_PKG_CONFIG
>+
>+ dnl Check for X headers, etc
>+ _cppflags="${CPPFLAGS}"
>+@@ -97,7 +97,7 @@
>+
>+ PKG_CHECK_MODULES(libXft, xft >= 1.0
>+,XFT_LIBS="-lXft"
>+- XFT_CFLAGS="`pkg-config --cflags xft`"
>++ XFT_CFLAGS="`$PKG_CONFIG --cflags xft`"
>+AC_DEFINE(HAVE_X11_XFT_XFT_H, 1, [Have xft])
>+,AC_MSG_ERROR([cannot locate libXft]))
>+
>+@@ -106,8 +106,8 @@
>+
>+ PKG_CHECK_MODULES(libX11, x11 >= 1.0
>+,AC_DEFINE(HAVE_X11, 1, [Have X11])
>+- X_LIBS="`pkg-config --libs x11`"
>+- X_CFLAGS="`pkg-config --cflags x11`"
>++ X_LIBS="`$PKG_CONFIG --libs x11`"
>++ X_CFLAGS="`$PKG_CONFIG --cflags x11`"
>+AC_DEFINE(X_DISPLAY_MISSING, 0, [Have x11])
>+,AC_MSG_ERROR([cannot locate libX11]))
>+
>+@@ -206,8 +206,8 @@
>+,AC_DEFINE(HAVE_PANGO_XFT, 1, [Have pangoxft])
>PANGO_MODULES="${PANGO_MODULES} pangoxft" have_pango_xft="yes"
>FONT_LOADER="Pango XFT" AC_SUBST(have_pango_xft)
>+,AC_MSG_WARN([pango xft support not available
>$PANGO_MIN_VER]))
>+
>+-PANGO_LIBS=`pkg-config --libs $PANGO_MODULES`
>+-PANGO_CFLAGS=`pkg-config --cflags $PANGO_MODULES`
>++PANGO_LIBS=`$PKG_CONFIG --libs $PANGO_MODULES`
>++PANGO_CFLAGS=`$PKG_CONFIG --cflags $PANGO_MODULES`
>+
>+ else FONT_LOADER="X.Org"
>+ fi
>+@@ -216,11 +216,11 @@
>+ REP_MIN_VER="0.92.3"
>+
>+ PKG_CHECK_MODULES(LIBREP, librep >= ${REP_MIN_VER}
>+- ,REP_EXECDIR="`pkg-config --variable=repcommonexecdir librep`"
>+- REP_CFLAGS="`pkg-config --cflags librep`"
>+- REP_LIBS="`pkg-config --libs librep`"
>++ ,REP_EXECDIR="`$PKG_CONFIG --variable=repcommonexecdir
>librep`"
>++ REP_CFLAGS="`$PKG_CONFIG --cflags librep`"
>++ REP_LIBS="`$PKG_CONFIG --libs librep`"
Bug#881754: amanda-server: Amanda does not lock while dumping - multiple sessions possible
Hi, your problem was reported by other person to the amanda authors. I think your use case is not the most common. So for most use cases amanda works without problems, so I will downgrade your bug report from grave to normal. I will still chase this problem with the authors to try to find a fix. Kind regards Jose M Calhariz On 14/11/17 19:42, Kamil Jonca wrote: > Package: amanda-server > Version: 1:3.5-2 > Severity: grave > Tags: upstream > Justification: causes non-serious data loss > > (I am not sure if it is upstream) > > I used to make backup two phases. > 1. amdump to holding space, and then > 2. amflush to target disk (vtapes) > I noticed that I can make amflush during amdump - it should not be possible > as can flush incomplete file. > Moreover I can run multiple amflush processes - I supsect, that they destroy > backup files during flush . > KJ > > > -- System Information: > Debian Release: buster/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), > LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages amanda-server depends on: > ii amanda-common 1:3.5-2 > ii bsd-mailx [mailx] 8.1.2-0.20160123cvs-4 > ii libc6 2.24-17 > ii libcurl3 7.56.1-1 > ii libglib2.0-0 2.54.2-1 > ii libjson-perl 2.94-1 > ii libssl1.1 1.1.0g-2 > ii perl 5.26.1-2 > > amanda-server recommends no packages. > > Versions of packages amanda-server suggests: > ii amanda-client 1:3.5-2 > ii cpio 2.11+dfsg-6 > ii gnuplot 5.2.2+dfsg1-2 > ii gnuplot-qt [gnuplot] 5.2.2+dfsg1-2 > > -- no debconf information
Bug#878046: amanda-server: Fails all backups if one or more hosts are down
I am reviewing your bug report. This is a non-deterministic problem that existed for some years. I personally was affected by this, but did not stop amanda from working most of the time. So downgrading the severity from grave to important. On sid there is a new amanda 3.5 that successfully fix this problem. Kind regards Jose M Calhariz On 22/10/17 12:22, Anton Ivanov wrote: > I am OK to wait for the upload > > On 22 October 2017 13:26:56 EEST, Jose M Calhariz wrote: >> That is an old problem of amanda that is solved on v3.5. But the error >> messages are usually different from what you see. >> >> I have been working on a new package that I should upload very shortly, >> to sid and backports. If you are dead on water I >> can provide my working in progress packages for stretch on amd64. >> >> Kind regards >> Jose M Calhariz >> >> On 09/10/17 06:55, Anton Ivanov wrote: >>> Package: amanda-server >>> Version: 1:3.3.9-5 >>> Severity: grave >>> Justification: renders package unusable >>> >>> Dear Maintainer, >>> >>> If one or more backup host is unreachable, the backup of all hosts >> fails. >>> Example - backing up two hosts - smaug and TerriblTerror: >>> >>> If the latter is unreachable >>> >>> TerribleTerror1 /etc lev 0 FAILED [Request to TerribleTerror1 >> failed: Connection timed out] >>> The former (and all other hosts in the backup sequence) fail with: >>> >>> smaug /exports/md0/home/aivanov lev 0 FAILED [Request to smaug >> failed: error sending REQ: write error to: Broken pipe] >>> -- System Information: >>> Debian Release: 9.0 >>> APT prefers stable >>> APT policy: (500, 'stable') >>> Architecture: amd64 (x86_64) >>> >>> Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) >>> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), >> LANGUAGE=en_GB:en (charmap=UTF-8) >>> Shell: /bin/sh linked to /bin/dash >>> Init: systemd (via /run/systemd/system) >>> >>> Versions of packages amanda-server depends on: >>> ii amanda-common 1:3.3.9-5 >>> ii bsd-mailx [mailx] 8.1.2-0.20160123cvs-4 >>> ii libc6 2.24-11+deb9u1 >>> ii libcurl3 7.52.1-5 >>> ii libglib2.0-0 2.50.3-2 >>> ii libssl1.1 1.1.0f-3 >>> ii perl 5.24.1-3 >>> >>> amanda-server recommends no packages. >>> >>> Versions of packages amanda-server suggests: >>> ii amanda-client 1:3.3.9-5 >>> ii cpio 2.11+dfsg-6 >>> ii gnuplot5.0.5+dfsg1-6 >>> ii mt-st 1.3-1 >>> >>> -- no debconf information
Bug#848909: at FTCBFS: unsatisifable Build-Depends: perl
Please do a nmu. Kind regards Jose M Calhariz On October 30, 2017 10:52:13 PM GMT+00:00, "Manuel A. Fernandez Montecelo" wrote: >Hi, > >2016-12-20 19:25 Helmut Grohne: >>Source: at >>Version: 3.1.20-1 >>Tags: patch >>User: helm...@debian.org >>Usertags: rebootstrap >> >>at fails to cross build from source, because its perl dependency is >>unsatisfiable. It requests the host architecture perl, which is >neither >>installable nor executable, even though it really needs a build >>architecture perl. Annotating the perl dependency with :any fixes that >>and makes the cross build succeed. Please consider applying the >attached >>patch. > >This is a nice and simple fix, and at is a quite important, or at least >iconic, package. > >Would it be possible to include this fix in the next upload? > >Would a NMU help? > > >Cheers. >-- >Manuel A. Fernandez Montecelo -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#878045: amanda-server: Fails to format blank virtual tapes
I did not observe this bug in the past, maybe by chance. But I am preparing the new v3.5 where I have labelled new vtapes and S3 tapes. I expect to upload the v3.5 to sid and backports in the new future. Kind regards Jose M Calhariz On 09/10/17 07:07, Anton Ivanov wrote: > Package: amanda-server > Version: 1:3.3.9-5 > Severity: important > > Dear Maintainer, > > Amanda no longer formats completely blank tapes. Tested with > virtual tapes on disk, hence reporting only for virtual tapes. > > The only way to create a new virtual tape at present is to > copy the label file out of an existing virtual tape. This allows amanda > to overwrite it and function correctly. > > $ amlabel AutoSet3 AUTOE05 slot 6 > Reading label... > /usr/lib/amanda/chg-multi: 96: local: 0: bad variable name > Malformed output from changer script -- no output > > Same after copying label file > > $ amlabel AutoSet3 AUTOE05 slot 6 > Reading label... > Volume with label 'AUTOE04' is active and contains data from this > configuration. > Not writing label. > > After copying label file with -f > > $ amlabel -f AutoSet3 AUTOE05 slot 6 > Reading label... > Volume with label 'AUTOE04' is active and contains data from this > configuration. > Consider using 'amrmtape' to remove volume 'AUTOE04' from the catalog. > Writing label 'AUTOE05'... > Checking label... > Success! > > > -- System Information: > Debian Release: 9.0 > APT prefers stable > APT policy: (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), > LANGUAGE=en_GB:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages amanda-server depends on: > ii amanda-common 1:3.3.9-5 > ii bsd-mailx [mailx] 8.1.2-0.20160123cvs-4 > ii libc6 2.24-11+deb9u1 > ii libcurl3 7.52.1-5 > ii libglib2.0-0 2.50.3-2 > ii libssl1.1 1.1.0f-3 > ii perl 5.24.1-3 > > amanda-server recommends no packages. > > Versions of packages amanda-server suggests: > ii amanda-client 1:3.3.9-5 > ii cpio 2.11+dfsg-6 > ii gnuplot5.0.5+dfsg1-6 > ii mt-st 1.3-1 > > -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#878046: amanda-server: Fails all backups if one or more hosts are down
That is an old problem of amanda that is solved on v3.5. But the error messages are usually different from what you see. I have been working on a new package that I should upload very shortly, to sid and backports. If you are dead on water I can provide my working in progress packages for stretch on amd64. Kind regards Jose M Calhariz On 09/10/17 06:55, Anton Ivanov wrote: > Package: amanda-server > Version: 1:3.3.9-5 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > If one or more backup host is unreachable, the backup of all hosts fails. > > Example - backing up two hosts - smaug and TerriblTerror: > > If the latter is unreachable > > TerribleTerror1 /etc lev 0 FAILED [Request to TerribleTerror1 failed: > Connection timed out] > > The former (and all other hosts in the backup sequence) fail with: > > smaug /exports/md0/home/aivanov lev 0 FAILED [Request to smaug failed: > error sending REQ: write error to: Broken pipe] > > -- System Information: > Debian Release: 9.0 > APT prefers stable > APT policy: (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), > LANGUAGE=en_GB:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages amanda-server depends on: > ii amanda-common 1:3.3.9-5 > ii bsd-mailx [mailx] 8.1.2-0.20160123cvs-4 > ii libc6 2.24-11+deb9u1 > ii libcurl3 7.52.1-5 > ii libglib2.0-0 2.50.3-2 > ii libssl1.1 1.1.0f-3 > ii perl 5.24.1-3 > > amanda-server recommends no packages. > > Versions of packages amanda-server suggests: > ii amanda-client 1:3.3.9-5 > ii cpio 2.11+dfsg-6 > ii gnuplot5.0.5+dfsg1-6 > ii mt-st 1.3-1 > > -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#869515: amanda-server: Amanda taper does not respect taperflush criteria
I think the bug you describe is fixed in the new amanda 3.4.x. I am preparing a new package for sid and for stretch-backports. Are you interested in testing it? On 26/07/17 16:18, Winston Sorfleet wrote: > > Tried this in yesterday's cron job, but turning autoflush to "yes" did > not fix the problem. My understanding is that it shouldn't anyways; > autoflush must be set to "yes" if taperflush is greater than 0, but that > wasn't the case. > > On 2017-07-24 11:29 AM, Jose M Calhariz wrote: > > I am not certain that I understand your problem, so beer with me. > > > From advanced.conf: > > On 24/07/17 16:05, Winston Sorfleet wrote: > >> # reserve 30 # percent >> # This means save at least 30% of the > holding disk space for degraded >> # mode backups. >> >> autoflush no >> > # if autoflush is set to yes, then amdump will schedule all dump on >> # > holding disks to be flush to tape during the run. > > Can you turn > "autoflush yes", and check if it solves your problem. > > > Kind regards > >> Jose M Calhariz > > > Kind regards Jose M Calhariz signature.asc Description: OpenPGP digital signature
Bug#869515: amanda-server: Amanda taper does not respect taperflush criteria
I am not certain that I understand your problem, so beer with me. From advanced.conf: On 24/07/17 16:05, Winston Sorfleet wrote: > # reserve 30 # percent > # This means save at least 30% of the holding disk space for degraded > # mode backups. > > autoflush no > # if autoflush is set to yes, then amdump will schedule all dump on > # holding disks to be flush to tape during the run. Can you turn "autoflush yes", and check if it solves your problem. Kind regards Jose M Calhariz signature.asc Description: OpenPGP digital signature
Bug#869515: amanda-server: Amanda taper does not respect taperflush criteria
Hi, Can you please attach your amanda,conf file and a listing of the contents of your holdingdisk? Kind regards Jose M Calhariz On 23/07/17 21:58, Winston Sorfleet wrote: > Package: amanda-server > Version: 1:3.3.9-5 > Severity: normal > Tags: newcomer > > Dear Maintainer, > > Amdump leaves dumps on holding disk despite taperflush being 0 (and thus > anything above 0% capacity of a single volume is supposed to be flushed > to tape). > > E.g. > > /usr/sbin/amdump vtl > > Mailed output at job completion: > > Hostname: flamen > Org : Romanus > Config : vtl > Date: July 20, 2017 > > These dumps were to tapes vtl36, vtl37. > Not using all tapes because taperflush criteria not met. > Run amflush to flush them to tape. > > The next 6 tapes Amanda expects to use are: vtl38, vtl39, vtl40, vtl1, > vtl8, vtl9. > ... > > > FAILURE DUMP SUMMARY: > flamen.romanus.ca / lev 1 partial taper: taperflush criteria not met > > STRANGE DUMP SUMMARY: > forum.romanus.ca / lev 1 STRANGE (see below) > pomerium.romanus.ca / lev 1 STRANGE (see below) > flamen.romanus.ca / lev 1 STRANGE (see below) > flamen.romanus.ca /home lev 0 STRANGE (see below) > > > STATISTICS: > Total Full Incr. Level:# > > Estimate Time (hrs:min) 0:06 > Run Time (hrs:min) 3:10 > Dump Time (hrs:min) 2:02 1:33 0:29 > Output Size (meg)44907.136394.2 8512.8 > Original Size (meg) 57055.043962.113092.9 > Avg Compressed Size (%) 78.7 82.8 65.0 > DLEs Dumped4 1 3 1:3 > Avg Dump Rate (k/s) 6265.9 6672.3 4971.4 > > Tape Time (hrs:min) 1:31 1:26 0:05 > Tape Size (meg) 38608.436394.2 2214.2 > Tape Used (%) 200.0 188.5 11.5 > DLEs Taped 4 1 3 1:3 > Parts Taped 81 74 7 1:7 > Avg Tp Write Rate (k/s) 7247.5 7237.9 7409.6 > > USAGE BY TAPE: > Label Time Size % DLEs Parts > vtl36 0:45 19G 100.0 341 > vtl37 0:45 19G 100.0 140 > > > Expected outcome: > Amtape should completely fill vtl36 and vtl37, and partially fill vtl38. > > Workaround is to manually run amflush afterwards. > > This is likely related to upstream report "Data stuck on holding disk" > https://github.com/zmanda/amanda/issues/69 > > > > -- System Information: > Debian Release: 9.0 > APT prefers stable > APT policy: (900, 'stable'), (800, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), > LANGUAGE=en_CA:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages amanda-server depends on: > ii amanda-common 1:3.3.9-5 > ii bsd-mailx [mailx] 8.1.2-0.20160123cvs-4 > ii libc6 2.24-11 > ii libcurl3 7.52.1-5 > ii libglib2.0-0 2.50.3-2 > ii libssl1.1 1.1.0f-3 > ii perl 5.24.1-3 > > amanda-server recommends no packages. > > Versions of packages amanda-server suggests: > ii amanda-client 1:3.3.9-5 > ii cpio 2.11+dfsg-6 > ii gnuplot5.0.5+dfsg1-6 > ii mt-st 1.3-1 > > -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#770265: gir1.2-ibus-1.0: fails to install in multiarch setting: dpkg-query --listfiles called with ambiguous package name
On 14/07/17 22:41, Jose M Calhariz wrote: > Package: dh-python > Version: 2.20170125 > Followup-For: Bug #770265 > > > This problem prevents a full cross-grade of gnome from i386 to amd64, > leaving a broken gnome. The list of packages pending configure > because of this problem are: > > gir1.2-ibus-1.0:amd64 > gnome-shell > gnome-shell-extensions > gnome-core > chrome-gnome-shell > gnome-session > gnome > network-manager-gnome > gdm3 > > A workaround is to hack the postinst by hand. Just found about DPKG_MAINTSCRIPT_ARCH environment . So the generated code should be: # Automatically added by dh_python3: if which py3compile >/dev/null 2>&1; then py3compile -p gir1.2-ibus-1.0:$DPKG_MAINTSCRIPT_ARCH fi Kind regards Jose M Calhariz signature.asc Description: OpenPGP digital signature
Bug#770265: gir1.2-ibus-1.0: fails to install in multiarch setting: dpkg-query --listfiles called with ambiguous package name
Package: dh-python Version: 2.20170125 Followup-For: Bug #770265 This problem prevents a full cross-grade of gnome from i386 to amd64, leaving a broken gnome. The list of packages pending configure because of this problem are: gir1.2-ibus-1.0:amd64 gnome-shell gnome-shell-extensions gnome-core chrome-gnome-shell gnome-session gnome network-manager-gnome gdm3 A workaround is to hack the postinst by hand. -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dh-python depends on: ii python3 3.5.3-1 dh-python recommends no packages. Versions of packages dh-python suggests: pn libdpkg-perl -- no debconf information
Bug#868213: libmate-menu2:amd64: The Provides and Breaks in this package prevents the crossgrading of Mate from i386 to amd64
Package: libmate-menu2 Version: 1.16.0-2 Severity: normal I have been doing experiments on Crossgrading of Mate and Xorg from i386 to amd64. The crossgrading following the instructions in http://blog.calhariz.com/post/2017/07/12/Crossgrading-a-minimal-install-of-Debian-9 that are an adaptation from the Debian Wiki https://wiki.debian.org/CrossGrading The crossgrade fails with the message: dpkg: dependency problems prevent configuration of libmate-menu2:amd64: libmate-menu2:i386 (1.16.0-2) breaks libmatemenu and is installed. libmate-menu2:amd64 (1.16.0-2) provides libmatemenu. The way to exit from this situation is: dpkg --install --force-breaks /var/cache/apt/archives/libmate-menu2_1.16.0-2_amd64.deb Kind regards Jose M Calhariz -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libmate-menu2:amd64 depends on: ii libc6 2.24-11+deb9u1 ii libglib2.0-0 2.50.3-2 libmate-menu2:amd64 recommends no packages. libmate-menu2:amd64 suggests no packages. -- no debconf information
Bug#865979: at: patch for adding -s option to silence standard messages
Thank you. Your patch seams good and I will add it to the next release of at. Kind regards Jose M Calhariz On 26/06/17 10:34, Paul Slootman wrote: > Package: at > Version: 3.1.20-3 > Severity: wishlist > Tags: patch > > I use at from cronjobs (I can't use cron directly because the cronjob > calculates the time according to sunrise / sunset). I think it's silly > that at always outputs two lines to stderr and that there's no way to > prevent this; I don't need to know the job number and that the script > will be run using /bin/sh, thank you very much; I know that by now. > > I've added an option -s for silent that suppresses these two output > lines. Please consider adding this to the official build. > > Thanks, > Paul Slootman > > -- System Information: > Debian Release: 9.0 > APT prefers oldoldstable > APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.11.3-wurtel-ws (SMP w/8 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > Init: sysvinit (via /sbin/init) > > Versions of packages at depends on: > ii init-system-helpers 1.48 > ii libc62.24-11 > ii libpam-runtime 1.1.8-3.6 > ii libpam0g 1.1.8-3.6 > ii libselinux1 2.6-3+b1 > ii lsb-base 9.20161125 > > Versions of packages at recommends: > ii exim4-daemon-heavy [mail-transport-agent] 4.89-2 > > at suggests no packages. > > -- Configuration Files: > /etc/at.deny [Errno 13] Permission denied: '/etc/at.deny' > > -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#850731: xorp: segfaults at initialization, linker flags
On 20/04/17 22:04, Dhionel Díaz wrote: > On 02/03/17 17:08, Ben Greear wrote: >> Just FYI, I pushed this change plus an additional null check >> in related code. If fixes the crash I was seeing on my Fedora-24 systems, >> and it would appear to be the same bug earlier reported. >> >> Thanks, >> Ben >> >> On 01/10/2017 12:50 PM, Dhionel Díaz wrote: >>> El 10/01/17 a las 15:59, Jose M Calhariz escribió: >>>> Hi, I have contacted the upstream author, Ben Greear, about this >>>> problem. And he requested >>>> if you have a back trace? >>>> >>>>> I would be interested in seeing a backtrace if the user has >>>> it >>>> >>>>> so I could better understand the problem. Maybe the code should >>>> never >>>> >>>>> actually be trying to call these methods if _root is NULL? >>>> Can you help the author? >>>> >>>> Kind regards >>>> Jose M Calhariz >>>> >>>> >>> (...) >>> Hi, attached you will find the requested backtrace. Thanks for your >>> attention. >>> >>> Regards, >>> >> > Hi, I can confirm that the changes have been working properly in our > router all this time. Thanks for your attention. > > Regards, > Thank you for your testing. I have not released a new version to Debian because of the freeze. My plan is to quickly release a new version after the release. Kind regards Jose M Calhariz signature.asc Description: OpenPGP digital signature
Bug#852147: sawfish: Upstream version 1.12.0 available since August 06
On 22/01/17 23:44, Jose A. Ortega Ruiz wrote: > Hi Jose, > > On Sun, Jan 22 2017, Jose M Calhariz wrote: > >> Hi Jose, >> >> Sorry, I did not keep up with the upstream because I was busy studying >> to be a DD. > no problem! hope your studies went well :) Yes, my studies are going well, thank you. > >> I believe there is little difference between the version in stretch >> and the upstream. But if you find any problem with the version in > actually, version 1.12 solves a little glitch in the tiling code (by > yours truly) that nagged me in the previous version. i can patch it > locally, but it'd be nice to see the fix in our debian package too. Can you open a bug report against Debian about this tiling glitch? It will help me to backport sawfish for stretch, for the benefit of stretch users. > > (also, sawfish has been so long outdated in the past that, in my opinion > it'd be really nice to have the latest and greatest these days if at all > possible.) I think the same. I just directed my little free time to other packages with more users. It is always good to know users that care about my packages. :) > >> Debian, please open a bug report and I will update the package via the >> backports. The bug report is important before I can update the >> package via backports. > hmm, i just used reportbug to generate this request, and i see the bug > already filled there: > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852147 This bug report is about the outdated sawfish in Debian. > > or do you mean somewhere else? i actually use sid, and i don't see > 1.12.0 there: should i? i'm just asking because you mention backports: > maybe i'm missing something here? The backports is for users of stable, in this case for stretch. It is freeze time on Debian. When the freeze is over I will upload the latest sawfish into sid. If it takes to much time I will upload it to experimental. > > thanks! > jao Kind regards Jose M Calhariz signature.asc Description: OpenPGP digital signature
Bug#852147: sawfish: Upstream version 1.12.0 available since August 06
Hi Jose, Sorry, I did not keep up with the upstream because I was busy studying to be a DD. I believe there is little difference between the version in stretch and the upstream. But if you find any problem with the version in Debian, please open a bug report and I will update the package via the backports. The bug report is important before I can update the package via backports. Kind regards Jose M Calhariz On 21/01/17 23:10, Jose Antonio Ortega Ruiz wrote: > Package: sawfish > Version: 3:1.12.0-1nano > Severity: normal > > Dear Maintainer, > > I am using the .debs provided upstream by Christian, but it'd be very > nice if sawfish's packages in debian be updated to the latest version, > 1.12.0, so that we don't need to depend on non-official repositories. > > Thanks a lot! > jao > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: 9.0 > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages sawfish depends on: > ii libatk1.0-0 2.22.0-1 > ii libc62.24-9 > ii libcairo21.14.8-1 > ii libfontconfig1 2.11.0-6.7 > ii libfreetype6 2.6.3-3+b1 > ii libgdk-pixbuf2.0-0 2.36.4-1 > ii libglib2.0-0 2.50.2-2 > ii libgmp10 2:6.1.2+dfsg-1 > ii libgtk2.0-0 2.24.31-1 > ii libice6 2:1.0.9-1+b1 > ii libpango-1.0-0 1.40.3-3 > ii libpangocairo-1.0-0 1.40.3-3 > ii libpangoft2-1.0-01.40.3-3 > ii libpangoxft-1.0-01.40.3-3 > ii librep16 3:0.92.6-1nano > ii libsm6 2:1.2.2-1+b1 > ii libx11-6 2:1.6.4-2 > ii libxext6 2:1.3.3-1 > ii libxft2 2.3.2-1 > ii libxinerama1 2:1.1.3-1+b1 > ii libxrandr2 2:1.5.1-1 > ii libxrender1 1:0.9.10-1 > ii libxtst6 2:1.2.3-1 > ii rep 3:0.92.6-1nano > ii rep-gtk 3:0.90.8.3-1nano > ii rxvt-unicode-256color [x-terminal-emulator] 9.22-1+b1 > ii sawfish-data 3:1.12.0-1nano > ii xterm [x-terminal-emulator] 327-2 > > sawfish recommends no packages. > > sawfish suggests no packages. > > -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#364975: Any news about this bug?
Thank you for pointing me out this defect. I will review it at first opportunity. Kind regards Jose M Calhariz On 17/01/17 12:47, Dmitriy Kovalkov wrote: > Any news about this bug? > > Problem exist in > > Last in Arch: > > [kovalkov@localhost ~]$ at -V > at version 3.1.19 > Please report bugs to the Debian bug tracking system ( > http://bugs.debian.org/) > or contact the maintainers (a...@packages.debian.org). > > Last in Ubuntu 16.04: > > apt-cache policy at > at: > Installed: (none) > Candidate: 3.1.18-2ubuntu1 > Version table: > 3.1.18-2ubuntu1 500 > 500 http://ru.archive.ubuntu.com/ubuntu xenial/main amd64 Packages > > Last in Debian 8: > > root@repo:/# at -V > at version 3.1.13 > Please report bugs to the Debian bug tracking system ( > http://bugs.debian.org/) > or contact the maintainers (a...@packages.debian.org). > > --- > Respectfully, Dmitrii Kovalkov > FASTVPS technical department > signature.asc Description: OpenPGP digital signature
Bug#851611: sawfish: Annoying error message "File error: No such file or directory, gnome"
Yes, it is annoying. I will talk with the upstream about it, to find a solution and a workaround. Kind regards Jose M Calhariz On 16/01/17 20:32, Awtul wrote: > Package: sawfish > Version: 1:1.11.90-1 > Severity: important > > Dear Maintainer, > > I get this error message every time I log in Sawfish: > "Error: > (Click to dismiss. Also printed to stderr) > File error: No such file or directory, gnome". > > It's really annoying having to click in the pop-up window on each new log in. > That's why I have set the bug severity to 'important'. > > Regards, Awtul > > --- > > -- System Information: > Debian Release: 9.0 > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores) > Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages sawfish depends on: > ii gnome-terminal [x-terminal-emulator] 3.22.1-1 > ii libatk1.0-0 2.22.0-1 > ii libc6 2.24-8 > ii libcairo2 1.14.8-1 > ii libfontconfig12.11.0-6.7 > ii libfreetype6 2.6.3-3+b1 > ii libgdk-pixbuf2.0-02.36.3-1 > ii libglib2.0-0 2.50.2-2 > ii libgmp10 2:6.1.2+dfsg-1 > ii libgtk2.0-0 2.24.31-1 > ii libice6 2:1.0.9-1+b1 > ii libpango-1.0-01.40.3-3 > ii libpangocairo-1.0-0 1.40.3-3 > ii libpangoft2-1.0-0 1.40.3-3 > ii libpangoxft-1.0-0 1.40.3-3 > ii librep16 0.92.5-3+b1 > ii libsm62:1.2.2-1+b1 > ii libx11-6 2:1.6.4-2 > ii libxext6 2:1.3.3-1 > ii libxft2 2.3.2-1 > ii libxinerama1 2:1.1.3-1+b1 > ii libxrandr22:1.5.1-1 > ii libxrender1 1:0.9.10-1 > ii libxtst6 2:1.2.3-1 > ii lxterminal [x-terminal-emulator] 0.3.0-1 > ii rep 0.92.5-3+b1 > ii rep-gtk 1:0.90.8.2-3 > ii sawfish-data 1:1.11.90-1 > ii terminator [x-terminal-emulator] 1.90-1 > ii terminology [x-terminal-emulator] 0.9.1-1 > ii xterm [x-terminal-emulator] 327-2 > > sawfish recommends no packages. > > Versions of packages sawfish suggests: > ii gnome-control-center 1:3.22.1-1 > ii menu 2.1.47 > ii yelp 3.22.0-1 > > -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#850731: xorp: segfaults at initialization, linker flags
Hi, I have contacted the upstream author, Ben Greear, about this
problem. And he requested
if you have a back trace?
> I would be interested in seeing a backtrace if the user has
it
> so I could better understand the problem. Maybe the code should
never
> actually be trying to call these methods if _root is NULL?
Can you help the author?
Kind regards
Jose M Calhariz
On 09/01/17 18:42, Dhionel Díaz wrote:
> Package: xorp
> Version: 1.8.6~wip.20160715-2
> Severity: important
> Tags: patch
>
> Dear Maintainer,
>
> The xorp initialization process was generating segfaults in
> libxorp_rib.so because of null pointer dereferences. After some
> research, it seems that this was a latent bug that was exposed by an
> optimizer improvement included in gcc 6 ("Value range propagation now
> assumes that the this pointer of C++ member functions is non-null").
>
> The attached patch adds some null pointer checks which seem to solve the
> problem, at least for a multicast routing deployment.
>
> On the other hand, the patch also changes a line in debian/rules in
> order to complete the incorporation of hardened build flags. This is
> required because the SCons build system uses the, perhaps somewhat
> unusual, LINKFLAGS variable name for the linker flags.
>
> Some limited testing has been performed in a production router, I hope
> the patch can be useful.
>
> Regards,
>
>
> -- System Information:
> Debian Release: stretch/sid
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.8.0-2-amd64 (SMP w/1 CPU core)
> Locale: LANG=es_VE.UTF-8, LC_CTYPE=es_VE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages xorp depends on:
> ii adduser 3.115
> ii init-system-helpers 1.46
> ii libc62.24-8
> ii libgcc1 1:6.2.1-5
> ii libncurses5 6.0+20161126-1
> ii libpcap0.8 1.8.1-3
> ii libssl1.11.1.0c-2
> ii libstdc++6 6.2.1-5
> ii libsystemd0 232-8
> ii libtinfo56.0+20161126-1
>
> Versions of packages xorp recommends:
> ii iputils-ping 3:20161105-1
> ii iputils-tracepath 3:20161105-1
> ii traceroute 1:2.1.0-2
>
> xorp suggests no packages.
>
> -- Configuration Files:
> /etc/default/xorp changed [not included]
> /etc/xorp/config.boot changed [not included]
>
> -- no debconf information
>
>
signature.asc
Description: OpenPGP digital signature
Bug#849481: amanda-common: Amanda::Changer::robot::Interface::MTX calls confess but does not use Carp
Thank you for your patch. I will study it and see if it is applicable
to 3.3.9, the version on unstable, and against 3.4.1, the latest from
the authors.
Kind regards
Jose M Calhariz
On 27/12/16 16:54, Will Aoki wrote:
> Package: amanda-common
> Version: 1:3.3.8-1
> Severity: normal
> Tags: patch
>
> I've been getting occasional failures that leave the following in the report:
>
> FAILURE DUMP SUMMARY:
> taper: FATAL Undefined subroutine
> &Amanda::Changer::robot::Interface::MTX::confess called at
> /usr/lib/amanda/perl/Amanda/Changer/robot.pm line 2563.
> backup1.nhmu.utah.edu pool/burp lev 0 FAILED [out of holding space in
> degraded mode]
> backup1.nhmu.utah.edu pool/burp lev 0 FAILED [data write: Broken pipe]
>
> The cause of the failure seems to be a fork failing, but a bug in AMANDA's
> error-handling code is masking the first problem. This module calls confess(),
> but it doesn't use Carp first or otherwise declare &confess.
>
> --- /tmp/robot.pm 2016-12-27 09:41:57.285488949 -0700
> +++ /usr/lib/amanda/perl/Amanda/Changer/robot.pm 2016-12-27
> 09:41:34.045222046 -0700
> @@ -2359,6 +2359,7 @@
> use Amanda::Debug qw( debug warning );
> use Amanda::MainLoop qw( :GIOCondition synchronized make_cb define_steps
> step );
> use Amanda::Device qw( :constants );
> +use Carp;
>
> sub new {
> my $class = shift;
signature.asc
Description: OpenPGP digital signature
Bug#841007: linux-image-4.8.0-rc8-amd64-unsigned: Shutdown when pressing any key on Asus E200 HA
Is to tell that the new 4.9-rc works. Now I can login into the machine. During the weekend I will do a longer review of the kernel in search of regressions. Thank you. Kind regards Jose M Calhariz On 16/11/16 17:01, Santiago Vila wrote: > forcemerge 833016 841007 > thanks > > Hi. > > You will see that both bugs belong to the "src:linux" package, > so it's better not to file duplicates. To tell the BTS that > a certain version has the bug, we have a "found" command. > > I'm merging the bugs with this message. > > BTW: There is a 4.9-rc version in experimental, you might want to give > it a try and say here if there is any improvement. > > Thanks. signature.asc Description: OpenPGP digital signature
Bug#843700: amanda-common: missing dependency on perlapi-*
Hi,
I need help to verify this fix.
On 08/11/16 20:56, Niko Tyni wrote:
> Package: amanda-common
> Version: 1:3.3.9-2
> Severity: serious
> X-Debbugs-Cc: p...@packages.debian.org
>
> This package contains binary Perl modules but doesn't depend on perlapi-*
> (currently perlapi-5.24.1).
>
> Quoting the Debian Perl Policy 4.4.2 ("Binary and Other Architecture
> Dependent Modules"):
>
> Additionally, all binary modules (regardless of their installation
> directory) and any other modules installed into $Config{vendorarch} must
> depend on the expansion of perlapi-$Config{debian_abi} using the Config
> module. If $Config{debian_abi} is empty or not set, $Config{version}
> must be used.
>
> This used to work (since #582220) but seems to have regressed recently
> with 1:3.3.9-1 that switched to dh-style debian/rules, dropping the
> 'dh_perl -a usr/lib/amanda/perl' call. The default dh behaviour doesn't
> know where to look for the private directory (which currently seems to
> be /usr/lib//amanda/perl). Possibly something like
>
> override_dh_perl:
> dh_perl /usr/lib/*/amanda/perl
I think the flag -V is needed, but the generated depends still lack
perlapi-*
Depends: adduser,
bsd-mailx | mailx,
debconf (>= 0.5) | debconf-2.0,
openbsd-inetd | inet-superserver,
update-inetd,
perl (>= 5.24.1~rc3-3),
libc6 (>= 2.15),
libcurl3 (>= 7.16.2),
libglib2.0-0 (>= 2.41.1),
libssl1.1 (>= 1.1.0)
>
> will do the trick.
>
> Note that this is the root cause for #839603 / #839392: if the package had
> had the correct dependencies, it would have been automatically binNMU'd
> by the release team along with the other 600+ packages during the Perl
> 5.24 transition.
>
> Even when this is fixed, partial upgrades of amanda-common from 1:3.3.9-1
> without upgrading perl will be a problem, particularly as Ubuntu has
> made a release with something based on 1:3.3.9-1. It looks like we need
> to add a Breaks on the perl side to make sure broken combinations can't
> happen.
Kind regards
Jose M Calhariz
signature.asc
Description: OpenPGP digital signature
Bug#843852: amanda-common: Cannot run amdump - and report about missing ssl symbols
I investigated this defect and I do not understand what went wrong because a recompile make it work again. This package have a pending upload to fix the build with openssl 1.1.0. Can you downgrade to testing? Kind regards Jose M Calhariz On 10/11/16 08:49, Kamil Jonca wrote: > Package: amanda-common > Version: 1:3.3.9-2 > Severity: grave > Justification: renders package unusable > > amdump ends prematurely with report: > an't load > '/usr/lib/x86_64-linux-gnu/amanda/perl/auto/Amanda/Debug/libDebug.so' for > module Amanda::Debug: /usr/lib/x86_64-linux-gnu/amanda/libamanda-3.3.9.so: > undefined symbol: SSL_library_init at > /usr/lib/x86_64-linux-gnu/perl/5.24/DynaLoader.pm line 187. > at /usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/Debug.pm line 11. > Compilation failed in require at > /usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/Config/FoldingHash.pm line 5. > BEGIN failed--compilation aborted at > /usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/Config/FoldingHash.pm line 5. > Compilation failed in require at > /usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/Config.pm line 753. > BEGIN failed--compilation aborted at > /usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/Config.pm line 753. > Compilation failed in require at /usr/sbin/amdump line 29. > BEGIN failed--compilation aborted at /usr/sbin/amdump line 29. > > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages amanda-common depends on: > ii adduser 3.115 > ii bsd-mailx [mailx] 8.1.2-0.20160123cvs-3 > ii debconf [debconf-2.0] 1.5.59 > ii libc6 2.24-5 > ii libcurl3 7.51.0-1 > ii libglib2.0-0 2.50.2-1 > ii libssl1.0.2 1.0.2j-4 > ii openbsd-inetd [inet-superserver] 0.20140418-2 > pn perl:any > ii update-inetd 4.43 > > amanda-common recommends no packages. > > Versions of packages amanda-common suggests: > ii amanda-client 1:3.3.9-2 > ii amanda-server 1:3.3.9-2 > > -- Configuration Files: > /etc/amandahosts [Errno 13] Permission denied: u'/etc/amandahosts' > > -- debconf information: > amanda-common/merge_amandates: signature.asc Description: OpenPGP digital signature
Bug#841007: linux-image-4.8.0-rc8-amd64-unsigned: Shutdown when pressing any key on Asus E200 HA
On 24/10/16 03:30, Ben Hutchings wrote: > On Sun, 2016-10-16 at 21:22 +0100, Jose M Calhariz wrote: >> Package: src:linux >> Version: 4.8~rc8-1~exp1 >> Severity: important >> >> Dear Maintainer, >> >>* What led up to the situation? >> >> Using a very recent Debian kernel 4.7 or 4.8. The vanilla 4.7.0 from >> kernel.org works. I simply boot the laptop. When the X11 is up and >> ready to input the user name, if I press any key it will shutdown. > [...] > > Is that a clean shutdown (services stopped, filesystems unmounted) or a > dirty shutdown (shuts off almost immediately, fsck reports an error on > the next boot)? > > What happens if you press a key earlier than that? > > Ben. > Yes, it seams to be a clean shutdown. User programs killed, services shutdown, nothing logged. If I press a key earlier, it is just ignored, as expected. Kind regards Jose M Calhariz signature.asc Description: OpenPGP digital signature
Bug#834534: librep: please make the build reproducible
On 17/10/16 21:06, Chris Lamb wrote: > Jose M Calhariz wrote: > >> And collab-maintainer? > I would prefer .dsc if that's not too much trouble for you...? > > > Regards, > Can you download from here? http://blog.calhariz.com/public/sft/sawfish/librep_0.92.6-1.dsc Kind regards Jose M Calhariz signature.asc Description: OpenPGP digital signature
