Re: A package to be removed
On Mon, 2021-11-22 at 08:47 +0200, Tommi Höynälänmaa wrote: > Package theme-d-gnome was scheduled for autoremoval on 2021-11-21 but > it looks like the package has not been removed yet. It looks like the autoremoval was processed: $ apt-cache madison theme-d-gnome theme-d-gnome |0.9.6-3 | https://deb.debian.org/debian unstable/main amd64 Packages theme-d-gnome |0.9.6-3 | https://deb.debian.org/debian unstable/main Sources $ rmadison theme-d-gnome theme-d-gnome | 0.7.5-2 | oldstable | source, all theme-d-gnome | 0.9.5-4 | stable | source, all theme-d-gnome | 0.9.6-3 | unstable | source, all $ w3m -dump https://tracker.debian.org/pkg/theme-d-gnome | grep -A6 versions | tail -n3 • oldstable: 0.7.5-2 • stable: 0.9.5-4 • unstable: 0.9.6-3 > I searched the package at packages.debian.org and the package was > displayed there in testing and unstable distributions. The packages site usually takes longer to update than other sources. > Grep-excuses displays theme-d-gnome as "flagged for removal". It is still in the list of auto-removals hints but not in the autoremoval calculations, so next time the hints are regenerated and then the testing migration runs I expect the excuses will change. https://release.debian.org/britney/hints/auto-removals https://udd.debian.org/cgi-bin/autoremovals.yaml.cgi -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
RFS: qabc/1.7-1 -- minimal GUI for ABC music notation
From: Benoît Rouits To: sub...@bugs.debian.org Subject: RFS: qabc/1.7-1 -- minimal GUI for ABC music notation Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "qabc": * Package name: qabc Version : 1.7-1 Upstream Author : Benoît Rouits * URL : http://brouits.free.fr/qabc/ * License : GPL-3+ * Vcs : https://github.com/be1/qabc Section : sound It builds those binary packages: qabc - minimal GUI for ABC music notation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qabc/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qabc/qabc_1.7-1.dsc Changes since the last upload: qabc (1.7-1) unstable; urgency=medium . * New upstream release. Regards, -- Benoît Rouits
Bug#996653: RFS: dynarmic/5+git20211012.cce7e4e+ds-1 [ITP] -- ARM dynamic recompiler
On Sun, 14 Nov 2021 14:48:33 +0100 Andrea Pappacoda wrote: Control: tags -1 - moreinfo Untagging moreinfo as it should've been removed with the previous message. Is there a good reason for not including 32 bit in the architecture list? FTBFS on arm64: /usr/bin/gmake -f CMakeFiles/cmTC_aa059.dir/build.make CMakeFiles/cmTC_aa059.dir/build gmake[3]: Entering directory '/<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_aa059.dir/CheckSymbolExists.c.o /usr/bin/cc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Wdate-time -D_FORTIFY_SOURCE=2 -o CMakeFiles/cmTC_aa059.dir/CheckSymbolExists.c.o -c /<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c /<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c: In function ‘main’: /<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:7:19: error: ‘__ARM64__’ undeclared (first use in this function) 7 | return ((int*)(&__ARM64__))[argc]; | ^ /<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:7:19: note: each undeclared identifier is reported only once for each function it appears in gmake[3]: *** [CMakeFiles/cmTC_aa059.dir/build.make:78: CMakeFiles/cmTC_aa059.dir/CheckSymbolExists.c.o] Error 1 gmake[3]: Leaving directory '/<>/obj-aarch64-linux-gnu/CMakeFiles/CMakeTmp' gmake[2]: *** [Makefile:127: cmTC_aa059/fast] Error 2
Re: A package to be removed
Hello The removal is OK now. - Tommi OpenPGP_0xBB861FDE40460F83.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1000324: RFS: ghostwriter/2.1.0-1 -- Distraction-free, themeable Markdown editor
Hello Bastian ;-) On Sun, 21 Nov 2021 21:41:39 +0100 Bastian Germann wrote: > Hi Sebastien, > > On Sun, 21 Nov 2021 17:16:05 +0100 Sebastien Chavaux wrote: > > Changes since the last upload: > > > > ghostwriter (2.1.0-1) unstable; urgency=medium > > . > > * New upstream release. > > I will sponsor this as-is as soon as you have updated the salsa repo. > If you do not want to maintain the package in git anymore, please remove the Vcs fields. > > Also, please consider setting the same architecture list as qtwebengine5. > > Thanks, > Bastian > > Thank you first of all. So it's not that I don't want to maintain git / salsa, it's that I'm not comfortable with it, should do a remedial course on it. I will see how to define the same list of architectures as qtwebengine5. I watch this and do it after work. Sincerely, Seb
Re: Source with different examples directories
Marc Haber writes: > I have a package which source tarball containst two examples > directories: > > src/examples > src/c++/examples > > Since both directories contain a Makefile, I would like to install > src/examples to /usr/share/doc/package/examples and src/c++/examples to > /usr/share/doc/package/examples/c++. > > This seems to be beyond dh_installexamples' capabilities. > > What would you suggest? I could override dh_auto_installexamples (does > that one exist?), using dh_installexamples to install > src/examples to /usr/share/doc/package/examples and then manually copy > src/c++/examples to /usr/share/doc/package/examples/c++ > > Is there a less ugly way? Hi, I'd use plain dh_install, maybe even for the part dh_installexamples gets right (for symmetry), and skip dh_installexamples. -- Regards, Feri
Bug#981030: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-4 -- speech recognition scoring toolkit
Hi Bastian, Il sab 23 ott 2021, 11:58 Bastian Germann ha scritto: > Am 23.10.21 um 10:43 schrieb Giulio Paci: > > Since the NMU has already solved the FTBFS, I think I can try to upgrade > > the tool as well. Unfortunately upstream did not add neither a tag nor a > > release to github. I have just asked if it is possible to add them > > (before moving to github upstream used to release tarballs with any new > > release). > > As the last commit is the one changing the version and is from 2018, it > is reasonable to assume that that commit is the release. There is no > activity since then and I do not expect upstream to react to your > request. So please package 2.4.11 regardless of tags. > I have discussed with upstream and they agreed to merge some of the currently open pull requests, as well as tag new versions, so I will package latest version (currently 2.4.12) as soon as I find time. > > I have invited you to https://salsa.debian.org/debian/sctk which also runs > the Salsa CI pipelines to demonstrate the i386 issue. Please use that repo > going forward. I will do. Thank you for setting it up. Build tests on i386 fail with: test17: Vietnamese case conversion Executions complete: Comparing output Removing DIFF tests Removing SLM tests ! TESTS HAVE FAILED ! I checked the issue and found out that the failing tests are test13 and test13b in sclite. The failing test case relies on the assumptions that, when a and b have the same double value: 1) "a < b" is false; 2) "a - b" is 0.0. For some reason the two above assumptions are sometime disattended on i386, and thus the "overlap" function in src/sclite/ctm2ctm.c is not always providing the expected results. The overlap behavior is unstable and varies according to specific flags being used to compile the executable (e.g., enabling debug is often enough to not trigger the failure, but enabling -O3 and -mtune=native generally is enough to trigger the failure again) or the context surrounding the operations (e.g., accessing the memory address of the operands). I guess the main reason for this weird behavior is described in (option -mfpmath): https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/x86-Options.html#x86-Options and in (option -ffloat-store): https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Optimize-Options.html#Optimize-Options
Re: Quoting Hell in Manual Pages, or lintian problem?
Marc Haber writes: > How would I quote backslashes in a manual page correctly? See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966803#14: if you want to *emit* a backslash, use \e. > Currently I have the source: > > with '"' around each argument, each '"' > in the string converted to '\\"' and each '\\' in the string > converted to ''. > > This renders to: > > with '"' around each argument, each '"' > in the string converted to '\"' and each '\' in the string > converted to '\\'. > > which looks reasonable enough. > > However lintian doesn't like this and flags the construct with > "acute-accent-in-manual-page". Is this a bug in Lintian? Lintian is honorably losing against nroff here. I wouldn't dare to correct it either. However, if you want to use single quotes in your manual pages, note that ' as the first character of the line is active, which is bound to catch you when you least expect it. They are extremely quirky anyway, although Debian killed off at least some of that quirkyness on its own turf. I recommend \(oq\e\e\(cq to get two backslashes between (proper) single quotes. Sorry. -- Regards, Feri
Re: Quoting Hell in Manual Pages, or lintian problem?
On Mon, Nov 22, 2021 at 04:31:56PM +0100, wf...@niif.hu wrote: > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966803#14: > if you want to *emit* a backslash, use \e. Thank you very much! Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
